<!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 6.00.2800.1226" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial>Anatoli,</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>So, I think the first step for T.38 is to add
the syntax2002 field. Following that, we need to go back and more
clearly define versioning issues for all sub-protocols, including T.38, V.150.1,
V.ToIP, V.VBD, etc. All of those will present similar issues.</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="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A title=alevine@radvision.com href="mailto:alevine@radvision.com">Anatoli
Levine</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A title=paulej@PACKETIZER.COM
href="mailto:'paulej@PACKETIZER.COM'">'paulej@PACKETIZER.COM'</A> ; <A
title=itu-sg16@external.cisco.com
href="mailto:itu-sg16@external.cisco.com">itu-sg16@external.cisco.com</A>
</DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Tuesday, September 16, 2003 5:31
PM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> RE: H.323 Fast Connect and
Versioning</DIV>
<DIV><BR></DIV>
<DIV><SPAN class=559573920-16092003><FONT face=Arial color=#0000ff
size=2>Paul,</FONT></SPAN></DIV>
<DIV><SPAN class=559573920-16092003><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=559573920-16092003><FONT face=Arial color=#0000ff
size=2>adding TermCaps into the Setup in the future versions will not
help, as none of the existing applications, which might use V0 syntax, will
put termCaps into the Setup. </FONT></SPAN></DIV>
<DIV><SPAN class=559573920-16092003><FONT face=Arial color=#0000ff
size=2></FONT></SPAN><SPAN class=559573920-16092003><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=559573920-16092003><FONT face=Arial color=#0000ff
size=2>Anatoli</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> <A
href="mailto:paulej@PACKETIZER.COM">paulej@PACKETIZER.COM</A>
[mailto:paulej@PACKETIZER.COM]<BR><B>Sent:</B> Tuesday, September 16, 2003
10:43 AM<BR><B>To:</B> <A
href="mailto:itu-sg16@external.cisco.com">itu-sg16@external.cisco.com</A><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>To address there V0/V2 interop problem, I agree that
something like the syntax2002 would be useful. In fact, to answer your
question about other H.245 fields that are unknown to the other side...
that's precisely how things get quite naturally "dropped out" in the replies
back. It's an indicator to the originator.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>Looking past v2 to the subsequent revisions, what else
might change? Perhaps the syntax will remain unchanged or at least
compatible, but perhaps something else in the procedures might
changes. This is what I'm wondering if we should insert rules into
H.323 (and Annex D would be the candidate for fax) that says that you shall
not accept a proposal in Fast Connect for a version you do not
support?</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>The proper solution to this general problem, in my
opinion, is to advertise termcaps in the Setup (perhaps the
parallelH245Control field), along with Fast Connect, and then use either
H.460.6 to re-negotiate offered channels or use H.245 logical channel
signaling. There's certainly nothing wrong with not using Fast
Connect at all, but it seems to be quite popular and probably something I
would not want to disallow.</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="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A title=PeterP@vegastream.com href="mailto:PeterP@vegastream.com">Peter
Price</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A title=paulej@packetizer.com
href="mailto:paulej@packetizer.com">'Paul E. Jones'</A> ; <A
title=itu-sg16@external.cisco.com
href="mailto:itu-sg16@external.cisco.com">itu-sg16@external.cisco.com</A>
; <A title=tsg16q14@itu.int
href="mailto:tsg16q14@itu.int">tsg16q14@itu.int</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Tuesday, September 16, 2003
5:00 AM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> RE: H.323 Fast Connect and
Versioning</DIV>
<DIV><BR></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=120234207-16092003>Paul,</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=120234207-16092003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=120234207-16092003>I appreciate that Version 3, 4 etc don't exist
yet but the issue we are talking about here is a specific problem caused
by an editorial error when T.38 was first published that has resulted in
an incompatible payload. </SPAN></FONT><FONT face=Arial
color=#0000ff size=2><SPAN class=120234207-16092003>The problem is that
if a V0/V1 endpoint accepts a V2 offer it will not send a payload
that is decodable by the V2 endpoint (and the V2 endpoint will send
undecodable packets to the other endpoint). T.38 is
broken.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=120234207-16092003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=120234207-16092003>At this stage we have to assume that such an
incompatibility would be avoided in future versions. If a future
change to the standard resulted in a new incompatibility with V2 then
again it is effectively a new codec and that future version would have to
be protected in some way from V2 or older versions. Since (nearly)
all the fields are now extensible unless someone decides we need a third
error recovery mechanism it's hard to see how T.38 can be broken
again.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=120234207-16092003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=120234207-16092003>It may well be that the Fast Connect rules should
be reviewed but I do not think this is the scenario that should drive the
thinking. You say that the video options can't be changed but what
happens when your endpoint doesn't understand them (ie can't decode
them). What will the calling endpoint do when it receives a response
that has probably been changed?</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=120234207-16092003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=120234207-16092003>I suspect that this changing of extended options
will be the real issue in the future as this will (should) be where
differences between versions will exist and any modifications to the Fast
Connect rules can usefully address this type of predictable
issue. I still haven't seen any response from video endpoint
implementors who must have encountered this scenario and must have views
on how it should be handled. Maybe they are not looking at this list
and the question needs to be asked on the implementors
list.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=120234207-16092003></SPAN></FONT> </DIV>
<DIV><FONT size=+0><SPAN class=120234207-16092003>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=120234207-16092003>The T.38 problem does not fall into this
category, it is a result of an error in the standard and there is no way
of of trying to anticipate future problems caused by errors (and no point
or gain). The errors won't be the same (I hope) and will almost
certainly require unique solutions.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=120234207-16092003></SPAN></FONT> </DIV><SPAN
class=120234207-16092003>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=120234207-16092003>I am not convinced about your suggestion for
changing Annex D. This is an interoperability issue between new
implementations and old ones. Changing the standard in this way
isn't going to stop existing endpoints accepting the channels [ unless you
have some very interesting paranormal capabilities in your gateway - in
which case why do you need H.323 at all! Or have you have
achieved the ultimate goal - a computer that does what you want it to do,
not what you tell it to do ;-) ]</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=120234207-16092003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2>I still believe that the
syntax2002 suggestion by itself is the best solution for this
problem. </FONT></DIV>
<DIV><FONT face=Arial><FONT color=#0000ff><FONT size=2><SPAN
class=120234207-16092003>1. </SPAN>It allows the calling endpoint to
identify which version of the ASN.1 it should use for both receive and
transmit. </FONT></FONT></FONT></DIV>
<DIV><SPAN class=120234207-16092003><FONT face=Arial color=#0000ff
size=2>2. It does not require any knowledge of the problem in existing
V0/V1 endpoints (a very important factor)</FONT></SPAN></DIV>
<DIV><FONT size=+0><FONT size=+0><FONT face=Arial><FONT
color=#0000ff><FONT size=2><SPAN class=120234207-16092003>3. </SPAN>It is
an isolated change that resolves the current problem and does not have any
consequences for any other application area.
</FONT></FONT></FONT></FONT></FONT></DIV>
<DIV></SPAN><FONT face=Arial color=#0000ff size=2><SPAN
class=120234207-16092003>4. Trying to engineer a solution that can
anticipate the unforeseeable future will continue to make your head
hurt ;-)</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=120234207-16092003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=120234207-16092003>Incidentally, since syntax2002 would be an
extended option in T38FaxProfile it would be covered by Fast Connect
changes that allowed such options to be
dropped.</SPAN></FONT></DIV></SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=120234207-16092003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=120234207-16092003>BTW I agree that not using Fast Connect at all is
the best solution. H.245 tunneling or even an H.245 address in the
Setup message typically allows the media to be established before any
useful data can be transmitted - even a purely electronic IVR system is
going to delay before transmitting a message to us poor slow humans. In
fact, media can be established more quickly because it does not require
any call progress messages - not many endpoints accept Fast Connect in
Facility messages.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=120234207-16092003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=120234207-16092003>Pete</SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Paul E. Jones
[mailto:paulej@packetizer.com]<BR><B>Sent:</B> 12 September 2003
21:53<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>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="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A title=PeterP@vegastream.com
href="mailto:PeterP@vegastream.com">Peter Price</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A
title=paulej@packetizer.com href="mailto:paulej@packetizer.com">'Paul
E. Jones'</A> ; <A title=itu-sg16@external.cisco.com
href="mailto:itu-sg16@external.cisco.com">itu-sg16@external.cisco.com</A>
; <A title=tsg16q14@itu.int
href="mailto: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><FONT face=Arial></FONT><BR></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=460514806-11092003>Paul,</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=460514806-11092003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff 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 face=Arial color=#0000ff size=2><SPAN
class=460514806-11092003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff 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 face=Arial color=#0000ff size=2><SPAN
class=460514806-11092003></SPAN></FONT> </DIV><FONT size=+0><SPAN
class=460514806-11092003>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=460514806-11092003>The thread has suggested two approaches
</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff 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 face=Arial color=#0000ff 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 face=Arial color=#0000ff 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 face=Arial color=#0000ff size=2><SPAN
class=460514806-11092003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff 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 face=Arial color=#0000ff size=2><SPAN
class=460514806-11092003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff 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 face=Arial color=#0000ff size=2><SPAN
class=460514806-11092003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=460514806-11092003>------------</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=460514806-11092003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=460514806-11092003>A slight aside here (but
related).</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=460514806-11092003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff 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 face=Arial color=#0000ff size=2><SPAN
class=460514806-11092003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff 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 face=Arial color=#0000ff size=2><SPAN
class=460514806-11092003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff 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 face=Arial color=#0000ff size=2><SPAN
class=460514806-11092003>Have video endpoints already encountered this
problem? </SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=460514806-11092003>D</SPAN></FONT><FONT face=Arial color=#0000ff
size=2><SPAN class=460514806-11092003>o any video endpoint
implementors have any relevent comments here?</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=460514806-11092003></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=460514806-11092003>Peter</SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader dir=ltr align=left><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="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A title=PeterP@vegastream.com
href="mailto:PeterP@vegastream.com">Peter Price</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A
title=paulej@packetizer.com
href="mailto:paulej@packetizer.com">'Paul E. Jones'</A> ; <A
title=itu-sg16@external.cisco.com
href="mailto:itu-sg16@external.cisco.com">itu-sg16@external.cisco.com</A>
; <A title=tsg16q14@itu.int
href="mailto: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 face=Arial color=#0000ff 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 face=Arial color=#0000ff 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 face=Arial color=#0000ff 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 face=Arial color=#0000ff size=2><SPAN
class=120571215-10092003></SPAN></FONT></FONT> </DIV>
<DIV><FONT face=Tahoma><SPAN class=120571215-10092003>
<DIV><SPAN class=120571215-10092003><FONT face=Arial color=#0000ff
size=2>-------------------------- Part 2</FONT></SPAN></DIV>
<DIV><SPAN class=120571215-10092003><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=120571215-10092003><FONT face=Arial color=#0000ff
size=2>The versioning issue applies to any form of payload,
voice/video/fax/whatever.</FONT></SPAN></DIV>
<DIV><SPAN class=120571215-10092003><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=120571215-10092003><FONT face=Arial color=#0000ff
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 face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=120571215-10092003><SPAN
class=390145815-10092003><FONT face=Arial color=#0000ff 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 face=Arial color=#0000ff
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 face=Arial color=#0000ff
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 face=Arial color=#0000ff
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 face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><FONT face=Arial color=#0000ff
size=2>Peter</FONT></SPAN></FONT></DIV></DIV></FONT></DIV>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader dir=ltr align=left><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="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message -----
</DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A title=PeterP@vegastream.com
href="mailto:PeterP@vegastream.com">Peter Price</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A
title=paulej@PACKETIZER.COM
href="mailto:'paulej@PACKETIZER.COM'">'paulej@PACKETIZER.COM'</A>
; <A title=itu-sg16@external.cisco.com
href="mailto: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 face=Arial
color=#0000ff size=2>Paul wrote</FONT></SPAN></DIV>
<DIV><SPAN class=370241707-10092003><FONT face=Arial
color=#0000ff 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 face=Arial color=#0000ff
size=2></FONT> </DIV></DIV>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader dir=ltr align=left><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></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>