H.323 Fast Connect and Versioning

PeterP at VEGASTREAM.COM PeterP at VEGASTREAM.COM
Thu Sep 11 03:55:54 EDT 2003


Paul,
 
as I said before any solution is likely to be a bit dirty because of the
nature of the problem.  I think your "syntax2002" suggestion is perfectly
valid - it is a smaller more localised change and, especially given the
reluctance to add new code points, is probably a better alternative than
t39faxV2.  It only requires a single change to T38FaxProfile rather than
changes to both DataApplicationCapability and DataApplicationMode.  There is
no danger that the change could affect anything other than T.38 aware
endpoints.
 
On the subject of H245 tunneling, the problem scenario we're discussing is
Fast Connect and I thought that H.323 V4 says that endpoints using Fast
Connect shall use H.245 tunneling!  It doesn't do much for pure T.38
endpoints which don't do any H.245 though.
 
The thread has suggested two approaches 
1. resolve the issue  within the Fast Connect proposal (or any subsequent
requestMode/OLC etc)
2. resolve the issue by modifying some other part of the standard by
introducing "special cases"
 
As an implementor, I would prefer to see a solution within the Fast Connect
proposal rather than force other changes in the standard - the danger of
going that route is you don't know what the downstream consequences are
going to be.  Containing the solution in T38FaxProfile keeps implementation
simpler - you receive a message and you know exactly what you are doing
without having to go looking for other information.  Logically, the tunneled
H245 messages arrive after the Setup message and its easier to process the
Setup completely before starting to look at the H.245.
 
Furthermore, if H.323 endpoints are to remain interoperable with pure T.38
endpoints (are there any?) then the solution *must* be contained within the
Fast Connect proposal.
 
You suggest that "syntax002" is a bit of a kludge.  It probably is but it
does have the advantage of being isolated.  I think that "special cases" in
the standard that may have unforeseen consequences for endpoints that are
not interested in T.38 are very much worse.
 
------------
 
A slight aside here (but related).
 
Your remark about the way that all endpoints appear to decode and re-encode
the Fast Connect proposals implies that the rule for not changing the
proposals is effectively impossible to maintain.
 
I only work with audio endpoints that use the basic audio codecs and T.38 so
until this discussion started hadn't really thought about this issue.  It's
easy to say you musn't change, say, the frame count of G729 but for codecs
that are defined as extensible like T.38 (and all the video codecs) there
will always be a problem when new endpoints offer new features to old
endpoints.
 
Perhaps the Fast Connect rule needs some review to address the specific
issue of extensible capabilities.
Have video endpoints already encountered this problem? 
Do any video endpoint implementors have any relevent comments here?
 
Peter

-----Original Message-----
From: Paul E. Jones [mailto:paulej at packetizer.com]
Sent: 10 September 2003 23:35
To: Peter Price; itu-sg16 at external.cisco.com; tsg16q14 at itu.int
Subject: Re: H.323 Fast Connect and Versioning


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
 
 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20030911/e45bd088/attachment-0004.html>


More information about the sg16-avd mailing list