Paul et al, Pardon my $AU 0.02 ... I thought that it was a fundamental principle that protocols were backward compatible, despite the fact that this is not always so. Making such a change breaks backward compatibility. An existing version 0 called device will respond with the mandatorily unchanged version 3. It is unsafe for the calling device to assume that the called device can handle version 3 if version 3 is not compatible with version 0. The proposed solution does not discriminate between a device that replies with offered version because it can handle it, or because it doesn't know they are incompatible. A existing version 3 calling device (if there is one) may break if it receives a modified faststart response from the called device, being unable to match the accepted faststart against the offered ones. Since this is only an issue for faststart (contained in H.225.0) it seems reasonable to base the solution on H.225.0. Option 1. ========= If you want the behaviour of changing the faststart, as indicated in the email to which this replies, then look at the protocolIdentifier, and introduce the behaviour at a particular value. There would be a magic value of protocolIdentifier which triggers the new behaviour. A called endpoint must follow earlier behaviour for values of protocolIdentifier (in Setup) less than the magic value where changed behaviour is allowed (i.e. must not change the faststart) and must follow later behaviour (set the verion) if protocolIdentifier is equal or greater. This avoids confusing an older calling endpoint. For the calling endpoint, if the protocolIdentifier (in the response e.g. Connect) is less than the magic value, it must limit the version selected to that which was available when that version of H.225.0 was decided, and if equal or greater must use the possibly modified version in the response. This requires that the value of the protocolIdentifier be modified (incremented) to achieve discrimination. Not something which should be done in a change to the IG (IMHO). Option 2. ========= Add an optional element to H.225.0 to carry the possibly modified fastStart (e.g. "modifiedFastStart SEQUENCE OF OCTET STRING OPTIONAL" wherever fastStart appears in a response) to contain the fastStart with the actual version accepted. If a called endpoint adds this to its response and the calling endpoint doesn't understand it, no harm is done because the called EP is a later vintage than the calling EP and presumably understands everything the calling EP could send. A calling EP that doesn't find this element must limit the version used as in option 1, and if it does find this element, must limit the version to that contained therein. (end of options) I feel that Option 1 is cleaner, but Option 2 is more IG-friendly. I also note that option 2 could be retrofitted to earlier versions of H.323 if the option 2 modifiedFastStart element were embedded in a NonStandardParameter of a ClearToken with a "magic" tokenOID, carried in the "tokens" element of the H.225.0 response. In this case, no change to the ASN.1 would be required, and an H.323 v2 EP (say) could indicate that it really does understand some later version of a codec that it normally wouldn't be expected to understand. However, this has a strong kludgy feel to it :). Anyway, since I'm not currently being paid for this, I guess that I should limit my time. Cheers, Douglas Clowes Consultant, Savant Solutions P/L. At 03:27 17/10/2003 -0400, Paul E. Jones wrote:

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