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