<!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.1106" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<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></BODY></HTML>