H.323 Fast Connect and Versioning

Paul E. Jones paulej at PACKETIZER.COM
Fri Oct 17 03:27:53 EDT 2003


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)
           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)
    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