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