H.323 Fast Connect and Versioning

[Paul E. Jones]

Ernst,
 
This is where I don't think the rules are perfectly clear.  Is an H.323
entity even obligated to look at the version field of the T.38 proposal
in Fast Connect? It's quite likely that it would return the version 2
proposal without regard to the fact that it does not support version 2.
If those rules were explicitly stated, I'd feel better about it, but I
don't believe they are.
 
We may need an addition to Annex D/H.323 or T.38 on this point.  What do
you think?
 
Paul
 

----- Original Message ----- 
From: Horvath Ernst <mailto:ernst.horvath at siemens.com>  
To: 'paulej at PACKETIZER.COM' <mailto:'paulej at PACKETIZER.COM'>  
Cc: itu-sg16 at external.cisco.com <mailto:itu-sg16 at external.cisco.com>  
Sent: Monday, September 15, 2003 4:35 AM
Subject: AW: H.323 Fast Connect and Versioning

Paul,
 
I don't want to dig into the general problem of versioning, but for the
T.38 case a recent corrigendum to T.38 (see attached file) might help.
If the caller includes a fastStart with two OLCs - the first (preferred)
one for version 2, the second one for version 0 or 1 - then, according
to fast connect rules, the callee has to select one of them (or none, if
it does not supprt T.38 fax at all):

*	If the callee also supports version 2, it should return the
version-2 OLC; 

*	if it supports only version 0 or 1, but understands the version
field, it should return the version-0/1 OLC; 

*	if it does not understand the version field, it should return an
OLC without a version field, which means version 0 by default.

Do you think this would work? If yes, we could add some text to Annex
D/H.323, as you proposed.
 
Ernst

-----Ursprüngliche Nachricht-----
Von: paulej at PACKETIZER.COM [mailto:paulej at PACKETIZER.COM]
Gesendet am: Freitag, 12. September 2003 22:57
An: itu-sg16 at external.cisco.com
Betreff: Re: H.323 Fast Connect and Versioning

Peter,
 
The danger with adding the codepoint for "syntax2002" is that it does
not necessarily encompass all of the rules for version 2, 3, etc.  Since
those future versions do not exist, it presents us with certain
problems.
 
Perhaps the right solution is two-fold:

1.	Add a new "syntax2002" field 

2.	Allow the called endpoint to modify the version number field in
the Fast Connect proposal.  It could *not* change it if the calling
device is version 0 or not using the new "syntax2002" field, but we
could add a rule that says that if the calling device included
"syntax2002", it also means that the called device may change the
version number in the reply to indicate the actual supported version.

If we do (2), then we need to change the language in H.323 to say that
parameters shall not be changed, unless explicitly allowed by the
particular "controlling media profile document".  For T.38, that would
be Annex D/H.323.  For V.150.1, that would be Annex P/H.323.
 
The video codec issue is an interesting one... several options can be
proposed with various capabilities, but they can't be changed.
 
There is an implementation approach that could be used to solve these
kinds of issues, but some folks don't like it.  That is: don't use Fast
Connect at all-- just do termcap exchange and only open media channels
and ring the remote phone once caps are exchanged and media is opened.
Regardless of whether H.245 is tunneled or on a separate connection, the
exchange of all required messages can be done in about 3 TCP packets per
side.
 
As for the requirement that H.245 tunneling be used with Fast Connect---
yes, the requirement is there, but folks ignore that like they do other
requirements in the standard ;-)  The wording might be "must support
tunneling", which does not mean it has to be used.
 
Fast Connect certainly has certain advantages over H.245, but if we had
never introduced Fast Connect in the first place, I suspect nobody would
think something is missing.  Most likely, folks would have engineered
their products to send TCS right away, would not have alerted the user
until media was established, etc.  They would have optimized their code
to send TCS,MSDet,OLC in the first outgoing message, replied with
TCS,TCSAck,MSDet,OLCAck,OLC in the reply TCP packet, and then
TCSAck,OLCAck in the sender's second TCP packet.  In the rare case where
the proposed OLC is not acceptable, it would require an extra exchange
of messages, but certainly no worse than Fast Connect today.
 
I'm actually working on a new extension to H.323 to allowing the calling
endpoint to explicitly request that the call establishment be delayed
until a certain point (e.g., bi-directional media channels are opened).
The calling side can control when it lets the call proceed.  Likewise,
the called side can control it by not acknowledging that the requested
"delay point" has been reached.  This might be the better way to handle
T.38.... except that, as you point out, there are Fast Connect-only T.38
devices.
 
My head hurts...
 
I really hate to break the rules about changing the attributes of a Fast
Connect proposal.
 
Here's another thought:  What if we add text to Annex D/H.323 that says
that if the proposed version is not supported, then it shall not accept
the proposal.  If it wants to offer a "counter proposal", it has two
means: H.245 signaling or H.460.6 (Extended Fast Connect).
 
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: Thursday, September 11, 2003 3:53 AM
Subject: RE: H.323 Fast Connect and Versioning


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 Price <mailto:PeterP at vegastream.com>  
To: 'Paul  <mailto:paulej at packetizer.com> E. Jones' ;
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 Price <mailto:PeterP at vegastream.com>  
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/20030915/3339dea1/attachment-0004.html>