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@microsoft.com