H.323 Fast Connect and Versioning
Paul E. Jones
paulej at PACKETIZER.COM
Thu Oct 9 18:41:32 EDT 2003
Sorry for the long delay. I was out of the office last week and spending
time trying to catch up this week... and fighting a horrible cold. The
doctor told me I was a baby for going to see him with a fever of 100.6F, but
I don't feel good :-(
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
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?
----- 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: Wednesday, October 01, 2003 10:01 PM
Subject: Re: H.323 Fast Connect and Versioning
> Thanks for your comment.
> One confirmation.
> > > Why are there issues in Fast Connect only?
> > With regular H.245 capability exchange and the use of OLCs, both sides
> > know the actual capabilities. Version 2 devices should then only send
> > OLC with a version that it knows the remote side can accept.
> > The problem has to do with sending a Fast Connect proposal (channel
> > proposal) for T.38v2 (2002 syntax) to a version 0 device (1998) syntax
> > that device accepting the proposal and, subsequently, sending
> > IFP packets. The version 0 device cannot decode the IFP packets.
> I understand it.
> My question is,
> In Figure D.8 - D.11 in H.323 Annex D, does the same issue happen?
> I think so.
> > In short, there is a potential for sending the wrong ASN.1 PER encoded
> > messages.
> Hiroshi Tamura
More information about the sg16-avd