H.323 Fast Connect and Versioning

paulej at PACKETIZER.COM paulej at PACKETIZER.COM
Wed Sep 10 21:29:06 EDT 2003


Tamura-san,

> Are multiple announcements supporting a version possible?
> i.e., two OLCs, one is for version 1 and the other for version 2?
> Or, is it necessary?

Yes, it is possible.  The problem is that a version 0 device would accept
either a version 0,1,2,3, or other version proposal, not knowing that the
ASN.1 is not compatible.  Further, it would return in the OLC in fastStart
"version 2", for example, but not really be v2 compatible.  Thus, even if we
allow multiple proposals, it will not work properly with the currently
deployed gear.  I think we need something new for v2 or higher devices
(different capability, for instance).

> T.38 already havs 0, 1 and 2 version. According to the results of May
meeting,
> Does the future version have to support all versions?
> Or, am I wrong?

Yes, I think that future releases have to support all versions.

> The syntax (1998 and 2002) is within T.38, not H.245.
> If the syntax used is decided before sending T.38 packets,
> I do not think there are issues. If this is the issue,
> we need to clarify it.

The problem is related to Fast Connect.  When a new device send a fastStart
element containing a T.38 with "version 2" specified, for example, the older
device might accept that and return the fastStart element with "version 2"
inside.  The older T.38 device would not change the version number, because
it was not permitted to do so.  When the calling terminal receives the
reply, it may immediately send 2002 syntax, which would fail to decode at
the called end.  That's the problem.  We have to do something to alert the
newer device that the older device is really not V2.

Paul

> Also, CNG and CED do not use Data-Field in T.38, in which 1998 syntax and
> 2002 syntax are different.
>
> Regards,
> --
> Hiroshi Tamura
>
>
> From: "Paul E. Jones" <paulej at packetizer.com>
> Subject: Re: H.323 Fast Connect and Versioning
> Date: Wed, 10 Sep 2003 18:35:09 -0400
>
> > Peter,
> >
> > I've only seen this problem with fax.  To answer your last question,
> > I've only seen T.38 use this kind of version tag.  However, V.150.1 also
> > has versioning information as part of the object identifier that
> > identifies the capability.  This will be interesting to see if we
> > introduce the same kind of problem there.  In general, it's just not
> > good to advertise the version through an OLC... it's better to perform a
> > full caps exchange.  The trouble is that modem and (to some extent) fax
> > timings are such that we must open channels ASAP... before a caps
> > exchange.  (Actually, we could transmit the termcap set in the Setup
> > message, but few devices support that.)
> >
> > We have had non-compatible payload specifications before and we resolved
> > that by adding new code points.  However, we've been trying to avoid
> > that.  Even so, we could do it again... it's just less desirable.
> >
> > I had another idea.  What we could do is, within the t38faxProtocol
> > SEQUENCE, we could indicate which syntax is to be used.  Older devices
> > would not see this field and would not decode it.  So, when the reply is
> > re-encoded, it would not be present.  So, even if the version was set to
> > "2", the "Syntax2002" field, say, would not be present.  This would mean
> > that the 1998 syntax has to be used.  A newer endpoint would see the
> > field and would properly re-encode it in the reply.  This is a bit of a
> > kludge and works only because of the way the ASN.1 encoding/decoding
> > works with every device I've seen.
> >
> > Another solution to the problem might be to require that endpoint use
> > H.245 tunneling and to advertise their capabilities in the Setup
> > message.  That could allow us to avoid this problem entirely.  I'm just
> > not sure how excited people would be to be forced to use H.245 tunneling
> > every time they use fax, modem, or text relay.
> >
> > Paul
> >
> >
> > ----- Original Message ----- 
> > From: Peter  <mailto:PeterP at vegastream.com> Price
> > To: 'Paul E. Jones' <mailto:paulej at packetizer.com>  ;
> > itu-sg16 at external.cisco.com <mailto:itu-sg16 at external.cisco.com>  ;
> > tsg16q14 at itu.int <mailto:tsg16q14 at itu.int>
> > Sent: Wednesday, September 10, 2003 12:34 PM
> > Subject: RE: H.323 Fast Connect and Versioning
> >
> >
> > Paul,
> >
> > I wrote the first part of this email and then reread yours - I was
> > bogged down in the fax issue but I think you are actually raising a
> > wider issue aren't you?  See part 2 below.
> >
> > -------------------------- Part 1
> > I don't believe that 5 versions of T38 would result in 5 offered
> > channels.
> >
> >
> > The need for the different capability is due to the fact that what you
> > are offering is a payload that is encoded in a different and
> > incompatible way.  ie its a bit like offering G.729 and the sending
> > packets encoded according to G.723.1,  they both represent speech but
> > they are not going to be played out properly.  The single extra bit
> > introduced into the T.38 payload packet by the 2002 ASN.1 is backwards
> > incompatible.
> >
> > The problem only exists for endpoints that only know about the 1998
> > ASN.1 and are unaware of the incompatibility - it is important that they
> > do not think they can accept the offered channel.
> >
> > Once an endpoint is aware of the problem (ie it knows about the 2002
> > ASN.1) then it can handle versions >= V2 (as well as V0 and V1).  Of
> > course, this does assume that a similar incompatibilty does not creep
> > into the payload ASN.1 in future versions - but that's down to careful
> > work in the standard development and editing stage.
> >
> > I still think adding t38faxV2 (say) to DataApplicationCapability and
> > DataApplicationMode is the simplest solution
> > [ t38faxV2 would use the same definitions for t38FaxProtocol and
> > t38FaxProfile - its only the payload that has changed ].  This protects
> > the existing T.38 implementations and avoids the need to break the rule
> > about modifying Fast Connect proposals.
> >
> > The change in the T.38 payload ASN.1 breaks the fundamental backwards
> > compatibility that ASN.1 is supposed to guarantee and thus whatever the
> > final solution there has to be an element of a hack involved - I think
> > that this change would isolate the change and protect the rest of the
> > standard.
> >
> >
> > -------------------------- Part 2
> >
> > The versioning issue applies to any form of payload,
> > voice/video/fax/whatever.
> >
> > The problem is still going to exist in early versions of endpoints that
> > don't understand the consequence of accepting versions that they do not
> > understand fully.  If a new version of a codec's payload is not
> > backwards compatible then I would assert that it is a new codec and must
> > be signalled as a different capability.
> >
> > The issue of multiple variations already exists anyway although not (to
> > my knowledge) with version numbers.
> > Endpoints already offer multiple packet sizes for exactly the reason
> > that you are not supposed to alter the Fast Connect proposal.  What
> > happens when somebody starts to offer g729Extensions and has to offer
> > all the combinations of Annexes because they don't know what the other
> > end can use ( I make that 64 proposals in each direction without adding
> > further annexes! )?
> >
> >
> > I don't see that relaxing the rule about modifying the version in a Fast
> > Connect channel will help resolve the problem of having to offer
> > multiple proposals.  You either have to allow *anything* to be modified
> > or stick to the current rule. Exceptions allowing certain fields to be
> > modified just makes life much more difficult and confusing.
> >
> >
> > T.38 is the only codec I am aware of that actually uses a version number
> > in this manner.  Are there any others? Why was it introduced in T.38?
> > Perhaps this is a lesson for the future about the value of introducing
> > of such a field in other codecs.
> >
> > Peter
> >
> > -----Original Message-----
> > From: Paul E. Jones [mailto:paulej at packetizer.com]
> > Sent: 10 September 2003 16:01
> > To: Peter Price; itu-sg16 at external.cisco.com; tsg16q14 at itu.int
> > Subject: Re: H.323 Fast Connect and Versioning
> >
> >
> > Peter,
> >
> > I think you're on the right track.  We could avoid ASN.1 changes by
> > introducing the new capability as a generic data capability, but a new
> > capability is required here, I think.
> >
> > The problem, as I see it, is that when we use Fast Connect, we can't
> > alert the calling side as to what version the called side actually
> > supports.  This suggests that if we have 5 versions of T.38, the calling
> > side would have to propose a channel for each version independently.
> > That's horrible.  It's only complicated further by the fact that T.38
> > may not be signaled by itself-- it might be part of audio proposals that
> > also include modem, text over IP, VBD, or other media.  It might even be
> > that there are several versions of the modem (V.150.1) protocol
> > advertised.
> >
> > I think the only real solution to this problem is to allow the Fast
> > Connect proposals to be altered by the called endpoint such that they
> > can change the version number.. and nothing else.  H.323 has an explicit
> > statement that says that the proposals can't be modified before
> > returning them, but perhaps this simple exception might resolve these
> > issues.  I think without such, it's going to be terrible complicated.
> >
> > Paul
> >
> >
> > ----- Original Message ----- 
> > From: Peter  <mailto:PeterP at vegastream.com> Price
> > To: 'paulej at PACKETIZER.COM' <mailto:'paulej at PACKETIZER.COM'>  ;
> > itu-sg16 at external.cisco.com <mailto:itu-sg16 at external.cisco.com>
> > Sent: Wednesday, September 10, 2003 3:23 AM
> > Subject: RE: H.323 Fast Connect and Versioning
> >
> > Paul wrote
> >
> > "Perhaps we can require the calling device to not transmit any data
> > until it receives at least one IFP packet from the called side and
> > determines the ASN.1 version used to encode the message."
> >
> > Unfortunately this won't work - although typically the called endpoint
> > will provide the first IFP (Probably a CED) this doesn't work when you
> > poll for a fax - in that case the calling endpoint will probably want to
> > send the first IFP.
> >
> > The only way I can see out of this is to add a new data application
> > (say, t38faxV2) to DataApplicationCapability etc in the H.245 ASN.1.
> > t38fax would use the 1998 ASN.1 and t38faxV2 would use the 2002 ASN.1 -
> > and future carefully checked modifications ;-).  Now there's no problem,
> > a 2002 aware endpoint can offer both versions and a 1998 aware endpoint
> > can only accept the ASN.1 it understands.
> >
> >
> > Pete Price
> > Vegastream Limited
> >
> >
> > -----Original Message-----
> > From: paulej at PACKETIZER.COM [mailto:paulej at PACKETIZER.COM]
> > Sent: 09 September 2003 20:32
> > To: itu-sg16 at external.cisco.com
> > Subject: H.323 Fast Connect and Versioning
> >
> >
> > Folks,
> >
> > Today, I was exchanging e-mail with somebody over the fax version number
> > issue and the different syntax that is used (1998 vs 2002).
> >
> > If we open H.245 and exchange a full set of capabilities, and H.323
> > endpoint could determine the version supported by the other side and
> > open a channel supporting that particular version.  However, I don't
> > think any text is explicitly clear on that.
> >
> > Another scenario-- and one I have more trouble with-- is Fast Connect.
> > If a calling endpoint populates the fastStart element with "version 2"
> > proposals, for example, the called side (say, a version 0 device) might
> > accept the proposal and return the response.  However, it is not allowed
> > to modify the version field.  The reason is that Fast Connect proposals
> > are not ordered in a way such that replies must be ordered the same way.
> > Rather, the calling device determines which proposals are accepted based
> > on characteristics of the proposals returned (e.g., codec type, samples
> > per packet, or other information).  In some cases, a calling endpoint
> > will actually not try to "match" the proposal returned, but just accept
> > it as a proposal and run with it.
> >
> > The problem is that if a calling device proposes version 2 and the
> > called device returns version 2 (but is actually a v0 device), then the
> > wrong syntax will be transmitted on the wire.  Thus, the text needs to
> > state somewhere one of these options (or something similar):
> >
> > 1. The calling device must offer a proposal for each version it
> > wants to potentially use and the called device must accept the first
> > proposal it can accept (in order of the proposals) and the called device
> > must not accept any proposal for a version it does not support
> >
> > 2. The calling device must wait for capability exchange to complete
> > to determine the actual supported version of the other device
> >
> > Alternatively, we could make an allowance for the endpoint to change the
> > version number in the Fast Connect proposal, but I don't think that's a
> > good idea, as it would quite possibly break interoperability with some
> > devices.
> >
> > What would a version 0 device do today if it received a Fast Connect
> > proposal advertising version 2?  Would it accept it?  I suspect so and
> > I'm afraid that we might have some interop problems regardless of the
> > direction we go.
> >
> > Perhaps we can require the calling device to not transmit any data until
> > it receives at least one IFP packet from the called side and determines
> > the ASN.1 version used to encode the message.  As much as we can push
> > onto the shoulders of a v2 device, the better, as I don't think we have
> > any real deployments in the field (yet)... might be wrong, but I think
> > it would be a far less significant impact on that side.
> >
> > I'm open to suggestions.  Perhaps this issue is even addressed and I've
> > simply overlooked it.
> >
> > Thanks,
> > Paul
> >
> >
> >
>



More information about the sg16-avd mailing list