<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META content="MSHTML 5.00.2314.1000" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=823561008-15092003>Paul,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=823561008-15092003></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=823561008-15092003>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)</SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN
class=823561008-15092003>:</SPAN></FONT></DIV>
<UL>
<LI><FONT color=#0000ff face=Arial size=2><SPAN class=823561008-15092003>If
the callee also supports version 2, it should return the version-2 OLC;
</SPAN></FONT></LI>
<LI><FONT color=#0000ff face=Arial size=2><SPAN class=823561008-15092003>if it
supports only version 0 or 1, but understands the version field, it should
return the version-0/1 OLC;</SPAN></FONT></LI>
<LI><FONT color=#0000ff face=Arial size=2><SPAN class=823561008-15092003>if it
does not understand the version field, it should return an OLC without a
version field, which means version 0 by default.</SPAN></FONT></LI></UL>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=823561008-15092003>Do you
think this would work? If yes, we could add some text to Annex D/H.323, as you
proposed.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=823561008-15092003></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=823561008-15092003>Ernst</SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
<DIV><FONT face="Times New Roman" size=2>-----Ursprüngliche
Nachricht-----<BR><B>Von:</B> paulej@PACKETIZER.COM
[mailto:paulej@PACKETIZER.COM]<BR><B>Gesendet am:</B> Freitag, 12. September
2003 22:57<BR><B>An:</B> itu-sg16@external.cisco.com<BR><B>Betreff:</B> Re:
H.323 Fast Connect and Versioning</DIV><BR></FONT>
<DIV><FONT face=Arial>Peter,</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>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.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>Perhaps the right solution is two-fold:</FONT></DIV>
<OL>
<LI><FONT face=Arial>Add a new "syntax2002" field</FONT>
<LI><FONT face=Arial>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.</FONT></LI></OL>
<DIV><FONT face=Arial>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.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>The video codec issue is an interesting one... several
options can be proposed with various capabilities, but they can't be
changed.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>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.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>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.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>Fast Connect certainly has certain advantages over
H.245, but <EM>if</EM> 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.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>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.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>My head hurts...</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>I really hate to break the rules about changing the
attributes of a Fast Connect proposal.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>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).</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>Paul</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<BLOCKQUOTE dir=ltr
style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A href="mailto:PeterP@vegastream.com" title=PeterP@vegastream.com>Peter
Price</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A
href="mailto:paulej@packetizer.com" title=paulej@packetizer.com>'Paul E.
Jones'</A> ; <A href="mailto:itu-sg16@external.cisco.com"
title=itu-sg16@external.cisco.com>itu-sg16@external.cisco.com</A> ; <A
href="mailto:tsg16q14@itu.int" title=tsg16q14@itu.int>tsg16q14@itu.int</A>
</DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Thursday, September 11, 2003 3:53
AM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> RE: H.323 Fast Connect and
Versioning</DIV>
<DIV><FONT face=Arial></FONT><BR></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=460514806-11092003>Paul,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=460514806-11092003></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=460514806-11092003>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.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=460514806-11092003></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=460514806-11092003>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.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=460514806-11092003></SPAN></FONT> </DIV><FONT size=+0><SPAN
class=460514806-11092003>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=460514806-11092003>The thread has suggested two approaches
</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=460514806-11092003>1.
resolve the issue within the Fast Connect proposal (or any subsequent
requestMode/OLC etc)</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=460514806-11092003>2.
resolve the issue by modifying some other part of the standard by
introducing "special cases"</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=460514806-11092003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN
class=460514806-11092003>As an implementor, </SPAN>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 <SPAN class=460514806-11092003>T38FaxProfile </SPAN>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.</FONT></FONT></FONT></SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=460514806-11092003></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=460514806-11092003>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.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=460514806-11092003></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=460514806-11092003>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.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=460514806-11092003></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=460514806-11092003>------------</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=460514806-11092003></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=460514806-11092003>A
slight aside here (but related).</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=460514806-11092003></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=460514806-11092003>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.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=460514806-11092003></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=460514806-11092003>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.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=460514806-11092003></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=460514806-11092003>Perhaps the Fast Connect rule needs some review to
address the specific issue of extensible capabilities.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=460514806-11092003>Have video endpoints already encountered this
problem? </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=460514806-11092003>D</SPAN></FONT><FONT color=#0000ff face=Arial
size=2><SPAN class=460514806-11092003>o any video endpoint implementors have
any relevent comments here?</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=460514806-11092003></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=460514806-11092003>Peter</SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
<DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Paul E. Jones
[mailto:paulej@packetizer.com]<BR><B>Sent:</B> 10 September 2003
23:35<BR><B>To:</B> Peter Price; itu-sg16@external.cisco.com;
tsg16q14@itu.int<BR><B>Subject:</B> Re: H.323 Fast Connect and
Versioning<BR><BR></FONT></DIV>
<DIV><FONT face=Arial>Peter,</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>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.)</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>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.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>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.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>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.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>Paul</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<BLOCKQUOTE dir=ltr
style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A href="mailto:PeterP@vegastream.com" title=PeterP@vegastream.com>Peter
Price</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A
href="mailto:paulej@packetizer.com" title=paulej@packetizer.com>'Paul E.
Jones'</A> ; <A href="mailto:itu-sg16@external.cisco.com"
title=itu-sg16@external.cisco.com>itu-sg16@external.cisco.com</A> ; <A
href="mailto:tsg16q14@itu.int"
title=tsg16q14@itu.int>tsg16q14@itu.int</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Wednesday, September 10, 2003
12:34 PM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> RE: H.323 Fast Connect and
Versioning</DIV>
<DIV><FONT color=#0000ff face=Arial size=2></FONT><BR></DIV>
<DIV><FONT face=Arial>
<DIV><SPAN class=120571215-10092003><FONT color=#0000ff
size=2>Paul,</FONT></SPAN></DIV>
<DIV><SPAN class=120571215-10092003><FONT color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=120571215-10092003><FONT color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=120571215-10092003><FONT color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=120571215-10092003><FONT color=#0000ff
size=2>-------------------------- Part 1 </FONT></SPAN></DIV>
<DIV><SPAN class=120571215-10092003><FONT color=#0000ff size=2>I don't
believe that 5 versions of T38 would result in 5 offered
channels.</FONT></SPAN></DIV>
<DIV><SPAN class=120571215-10092003><FONT color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=120571215-10092003><FONT face=Arial>
<DIV><FONT color=#0000ff><FONT size=2><SPAN class=120571215-10092003>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. </SPAN><SPAN class=120571215-10092003>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.<SPAN class=390145815-10092003> The single
extra bit introduced into the T.38 payload packet by the 2002 ASN.1 is
backwards incompatible.</SPAN></SPAN></FONT></FONT></DIV>
<DIV><FONT color=#0000ff><FONT size=2><SPAN
class=120571215-10092003></SPAN><FONT face=Tahoma><SPAN
class=120571215-10092003><FONT
face=Arial></FONT></SPAN></FONT></FONT></FONT> </DIV><FONT
color=#0000ff size=2>The problem only exists for endpoints that only
know about the 1998 ASN.1 <SPAN class=390145815-10092003>and
</SPAN>are unaware of the <SPAN
class=390145815-10092003>incompatibility </SPAN>- it is important that
they do not think they can accept the offered
channel.</FONT></FONT></SPAN></DIV>
<DIV><SPAN class=120571215-10092003><FONT color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><FONT color=#0000ff><FONT size=2><SPAN
class=120571215-10092003>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). </SPAN><SPAN class=120571215-10092003>Of
course, this does assume that a similar <SPAN
class=390145815-10092003>incompatibilty </SPAN>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.</SPAN></FONT></FONT></DIV>
<DIV><SPAN class=120571215-10092003><FONT color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><FONT color=#0000ff><FONT size=2><SPAN class=120571215-10092003>I
still think adding t38faxV2 (say) to DataApplicationCapability and
DataApplicationMode is the simplest solution<SPAN
class=390145815-10092003>
<DIV><FONT face=Tahoma><FONT color=#0000ff face=Arial size=2><SPAN
class=120571215-10092003><SPAN class=120571215-10092003>[ t38faxV2 would
use the same definitions for t38FaxProtocol and t38FaxProfile - its only
the payload that has changed
]. </SPAN></SPAN></FONT></FONT></SPAN></SPAN><FONT
face=Tahoma><FONT face=Arial><SPAN class=120571215-10092003>This
protects the existing T.38 implementations and avoids the need to break
the rule about modifying Fast
Connect proposals.</SPAN></FONT></FONT></FONT></FONT></DIV></DIV>
<DIV><FONT face=Tahoma><FONT color=#0000ff face=Arial size=2><SPAN
class=120571215-10092003><SPAN
class=120571215-10092003></SPAN></SPAN></FONT></FONT> </DIV>
<DIV><FONT color=#0000ff><FONT size=2><SPAN class=120571215-10092003>The
change in the T.38 payload ASN.1 breaks the fundamental backwards
compatibility that ASN.1 is supposed to <SPAN
class=390145815-10092003>guarantee</SPAN> and thus w</SPAN><FONT
face=Tahoma><FONT face=Arial><SPAN class=120571215-10092003>hatever 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.</SPAN></FONT></FONT></FONT></FONT></DIV>
<DIV><FONT face=Tahoma><FONT color=#0000ff face=Arial size=2><SPAN
class=120571215-10092003></SPAN></FONT></FONT> </DIV>
<DIV><FONT face=Tahoma><SPAN class=120571215-10092003>
<DIV><SPAN class=120571215-10092003><FONT color=#0000ff face=Arial
size=2>-------------------------- Part 2</FONT></SPAN></DIV>
<DIV><SPAN class=120571215-10092003><FONT color=#0000ff face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=120571215-10092003><FONT color=#0000ff face=Arial
size=2>The versioning issue applies to any form of payload,
voice/video/fax/whatever.</FONT></SPAN></DIV>
<DIV><SPAN class=120571215-10092003><FONT color=#0000ff face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=120571215-10092003><FONT color=#0000ff face=Arial
size=2>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<SPAN class=390145815-10092003>'s payload</SPAN> is not
backwards compatible then I would assert that it is a new codec and must
be signalled as a different capability.</FONT></SPAN></DIV>
<DIV><SPAN class=120571215-10092003><FONT color=#0000ff face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=120571215-10092003><SPAN class=390145815-10092003><FONT
color=#0000ff face=Arial size=2>The issue of multiple variations already
exists anyway although not (to my knowledge) with version
numbers.</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=120571215-10092003><SPAN class=390145815-10092003><FONT
color=#0000ff face=Arial size=2>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!
)?</FONT></SPAN></SPAN></DIV>
<DIV><SPAN class=120571215-10092003><SPAN class=390145815-10092003><FONT
color=#0000ff face=Arial size=2></FONT></SPAN></SPAN> </DIV>
<DIV><SPAN class=120571215-10092003><SPAN class=390145815-10092003>
<DIV><SPAN class=120571215-10092003><FONT face=Arial><FONT
color=#0000ff><FONT size=2>I don't see that relaxing the rule about
modifying the version in a Fast Connect channel will help<SPAN
class=390145815-10092003> 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.</SPAN></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=120571215-10092003><FONT color=#0000ff face=Arial
size=2></FONT></SPAN> </DIV></SPAN></SPAN></DIV></SPAN></FONT></DIV>
<DIV><FONT face=Tahoma><FONT face=Arial><SPAN
class=120571215-10092003></SPAN></FONT></FONT><FONT face=Tahoma><SPAN
class=120571215-10092003>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN
class=120571215-10092003>T.38 is the only <SPAN
class=390145815-10092003>codec </SPAN>I am aware of that
actually <SPAN class=390145815-10092003>uses</SPAN> a version
number<SPAN class=390145815-10092003> in this manner</SPAN>. Are
there any others?<SPAN class=390145815-10092003> </SPAN></SPAN><SPAN
class=120571215-10092003>Why was it introduced in T.38?<SPAN
class=390145815-10092003> Perhaps this is a lesson for the future
about the value of introducing of such a field in other
codecs.</SPAN></SPAN></FONT></FONT></FONT></DIV>
<DIV><SPAN class=120571215-10092003><FONT color=#0000ff face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><FONT color=#0000ff face=Arial
size=2>Peter</FONT></SPAN></FONT></DIV></DIV></FONT></DIV>
<BLOCKQUOTE dir=ltr
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
<DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Paul E. Jones
[mailto:paulej@packetizer.com]<BR><B>Sent:</B> 10 September 2003
16:01<BR><B>To:</B> Peter Price; itu-sg16@external.cisco.com;
tsg16q14@itu.int<BR><B>Subject:</B> Re: H.323 Fast Connect and
Versioning<BR><BR></FONT></DIV>
<DIV><FONT face=Arial>Peter,</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>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.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>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.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>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.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>Paul</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<BLOCKQUOTE dir=ltr
style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A href="mailto:PeterP@vegastream.com"
title=PeterP@vegastream.com>Peter Price</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A
href="mailto:'paulej@PACKETIZER.COM'"
title=paulej@PACKETIZER.COM>'paulej@PACKETIZER.COM'</A> ; <A
href="mailto:itu-sg16@external.cisco.com"
title=itu-sg16@external.cisco.com>itu-sg16@external.cisco.com</A>
</DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Wednesday, September 10,
2003 3:23 AM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> RE: H.323 Fast Connect
and Versioning</DIV>
<DIV><BR></DIV>
<DIV>
<DIV><SPAN class=370241707-10092003><FONT color=#0000ff face=Arial
size=2>Paul wrote</FONT></SPAN></DIV>
<DIV><SPAN class=370241707-10092003><FONT color=#0000ff face=Arial
size=2></FONT></SPAN> </DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN
class=370241707-10092003>"</SPAN>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.<SPAN
class=370241707-10092003>"</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN
class=370241707-10092003></SPAN></FONT></FONT></FONT> </DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN
class=370241707-10092003>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.</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN
class=370241707-10092003></SPAN></FONT></FONT></FONT> </DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN
class=370241707-10092003>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.</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN
class=370241707-10092003></SPAN></FONT></FONT></FONT> </DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN
class=370241707-10092003></SPAN></FONT></FONT></FONT> </DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN
class=370241707-10092003>Pete
Price</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN
class=370241707-10092003>Vegastream
Limited</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2></FONT> </DIV></DIV>
<BLOCKQUOTE dir=ltr
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
<DIV align=left class=OutlookMessageHeader dir=ltr><FONT
face=Tahoma size=2>-----Original Message-----<BR><B>From:</B>
paulej@PACKETIZER.COM
[mailto:paulej@PACKETIZER.COM]<BR><B>Sent:</B> 09 September 2003
20:32<BR><B>To:</B> itu-sg16@external.cisco.com<BR><B>Subject:</B>
H.323 Fast Connect and Versioning<BR><BR></FONT></DIV>
<DIV><FONT face=Arial>Folks,</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>Today, I was exchanging e-mail with somebody
over the fax version number issue and the different syntax that is
used (1998 vs 2002).</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>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.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>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.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>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):</FONT></DIV>
<OL>
<LI><FONT face=Arial>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</FONT>
<LI><FONT face=Arial>The calling device must wait for capability
exchange to complete to determine the actual supported version
of the other device</FONT></LI></OL>
<DIV><FONT face=Arial>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.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>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.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>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.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>I'm open to suggestions. Perhaps this
issue is even addressed and I've simply overlooked
it.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>Thanks,</FONT></DIV>
<DIV><FONT face=Arial>Paul</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT
face=Arial></FONT> </DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>