H.Chat vs. T.Chat: what is best for H.323?

Toby Nixon tnixon at MICROSOFT.COM
Wed Oct 29 18:05:11 EST 1997


Many of you will recall that at the Sunriver meeting I volunteered as
editor for "H.chat", the carrying of T.140 text chat over H.323. I've
recently found the bandwidth to do some thinking on this, and would like
to raise some issues with the group.

"H.chat", as I understand it, would describe protocols and procedures
for running T.140 "raw" on its own logical channel (negotiated via
H.245), rather than over T.120 using the application protocol entity
described in draft T.134. At first glance, it can appear that running
T.140 directly on a TCP channel is simple and easy to implement, and
that's probably true in the trivial point-to-point case. However, as
soon as you start expanding to multipoint chat (which should be a
requirement for T.140 over H.323), quite a lot of complexity is
introduced, and before long you find that you're duplicating most of the
functionality already provided by T.125 MCS.

> Our primary concern is that if there are two (or more) ways to
> implement T.140 text chatting in H.323 terminals, some implementers
> will do one, and some will do the other. The result will be that at
> least some portion of the users will not be able to engage in T.140
> chats with some other portion of the users. This would not be a
> desirable outcome of our efforts, the goal of which is to replace
> (over time) the variety of incompatible text telephone conventions
> around the would with a single worldwide interoperable standard that
> works over a variety of transports. Furthermore, we fear that if ITU
> defines a "simpler" protocol for one data application, we'll set a
> precedent that could result in demands for similar accommodation of
> other data applications (such as file transfer), further dividing the
> market and reducing interoperability. Why do we want to torpedo T.120
> after putting so much effort into it?  Shouldn't we endeavor to
> specify a single T.140 chat architecture in each H-series system, so
> as to maximize interoperability and minimize the complexity of
> gateways between various H-series systems? T.140 is about the purest
> "data conferencing" application there is; why not use ITU's standard
> data conferencing architecture as a transport?
>
There have been arguments against mandating T.120 by some H.323
implementers in the past, particularly in the context of T.130
discussions. However, the issue there was that some H.323 products, such
as standalone phones, would need NO data capability, and they didn't
want to have to implement T.120 just to participate in T.130 conference
control. However, Microsoft believes that H.323 terminals that implement
T.140 will be more capable devices with adequate resources to implement
T.120 and fully participate in multipoint data conferences; the resource
issue is not compelling.

> It probably makes some sense to be able to carry T.140 directly on an
> H.223 channel in H.324, since H.324 devices are fundamentally
> point-to-point. But this doesn't carry over to H.323 systems, which
> live in a fundamentally multipoint environment. Gateways from H.324 to
> H.323 are going to have to be relatively complex anyway, and a
> commercially successful gateway will require T.120 support. Adapting
> T.140 on H.223 into T.140 on T.120 should not be a significant burden
> to such a system.
>
So what are the compelling motivations for developing a standard for
carrying T.140 directly on an H.323 logical channel opened using H.245,
rather than within the context of T.120? In other words, why do we need
H.chat when we have T.chat?

        -- Toby
> ___________________________________________________________
> Toby Nixon, Program Manager - NetMeeting
> http://www.microsoft.com/netmeeting
> Microsoft Corporation, Applications and Internet Client Group, Redmond
> WA  USA
> +1 (425) 936-2792     Fax: +1 (425) 936-7329
> mailto:tnixon at microsoft.com
>



More information about the sg16-avd mailing list