Tamura-san,

The problem is not related to D.8-D.11. The problem is only with Fast Connect. The scenario is this: Calling Device Called Device (Version 3) (Version 0) Setup(fastStart(T38Version=3))--------------> <------------------------------------Connect(fastStart(T38Version=3) ^^^ | Responds with incorrect Version----------------------------

Once the Calling Device receives the fastStart message with version 3 advertised, it will transmit UDPTL data with the wrong ASN.1 encoding for the Called Device. The problem is really the fault of the Called Device, because it accepted a version it did not support. However, the reason that a called device would do this is because there is nothing in Annex D/H.323 or Annex B/T.38 that tells the called endpoint not to accept the fastStart proposal or to modify the version to match the actual supported version of the endpoint.

Probably the best solution would be to modify the T.38 and Annex D/H.323 text to allow the following:

Calling Device Called Device (Version 3) (Version 0) Setup(fastStart(T38Version=3))--------------> <------------------------------------Connect(fastStart(T38Version=0) ^^^ | Responds with actual supported Version----------------------------

However, I do not know which devices might break as a result of this. It would only be devices that propose T.38 channels in the Setup message.

Also, note that we have precisely the same problem with SIP, too. The INVITE message and the 200 message looks almost exactly the same. Nowhere, as far as I know, does it say how a SIP device should handle the T.38 version field when replying to an INVITE.

Paul

----- Original Message ----- From: "Hiroshi Tamura" tamura@toda.ricoh.co.jp To: paulej@packetizer.com Cc: PeterP@vegastream.com; itu-sg16@external.cisco.com; tsg16q14@itu.int Sent: Tuesday, October 14, 2003 4:41 AM Subject: Re: H.323 Fast Connect and Versioning

Paul,

...

Anyway, to answer your question... I don't think the procedures

documented

...

in D.8 - D.11 are a problem. In theory, the endpoint that transmits an

OLC

...

would not propose an OLC with a version number included that is not supported by the other side. However, the text does not say that. As

such,

...

I think I will bring a contribution as Rapporteur to have some text

added

...

that makes it very explicit that an endpoint SHALL NOT propose in an OLC version of T.38 not supported by the other endpoint. Does that sound reasonable?

Yes, Reasonable.

But, before that, I'm very sorry for my poor understanding. Why does the problem happen in D.8 - D.11? "version" in T38FaxProfile in DataApplicationCapability in OLC is the same in all cases. Even in voice to fax case, for example, between the caller

with

the version 3 and the called with the version 1, does the called possibly accept (CONNECT) in reponse to SETUP because it does not know our syntax

issue?

Could you please explain to me?

Thanks in advance.

...

I have also had some discussion with people about the various solutions

to

...

Fast Connect. I think one person or another thinks the various ideas

(and I

...

have about 5 now) are insufficient. What has most recently been

proposed is

...

to simply add text that says a called endpoint shall not accept a Fast Connect proposal that includes a T.38 version it does not support. That kind of text should have been in there, as well, but it is not. I

wonder if

...

anybody's equipment would break with such text?

I hope it does not exist. If any, the version 2 implementation before the last meeting may do harm. Also, the above sentence that you suggests is ok for me.

Regards,

Hiroshi Tamura