<!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>
<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></BODY></HTML>