Rapporteur and drafting work for Q.J/16

simao.campos at itu.int simao.campos at itu.int
Thu Oct 30 08:47:19 EST 2003

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

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.


Douglas Clowes
Consultant, Savant Solutions P/L.

At 03:27 17/10/2003 -0400, Paul E. Jones wrote:
>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.
>----- Original Message ----- 
>From: "Hiroshi Tamura" <tamura at toda.ricoh.co.jp>
>To: <paulej at packetizer.com>
>Cc: <PeterP at vegastream.com>; <itu-sg16 at external.cisco.com>;
><tsg16q14 at 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
>> > in D.8 - D.11 are a problem.  In theory, the endpoint that transmits an
>> > 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
>> > I think I will bring a contribution as Rapporteur to have some text
>> > 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
>> 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
>> Could you please explain to me?
>> Thanks in advance.
>> > I have also had some discussion with people about the various solutions
>> > 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

More information about the sg16-avd mailing list