<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o = "urn:schemas-microsoft-com:office:office"><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1264" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Verdana>Terry,</FONT></DIV>
<DIV><FONT face=Verdana></FONT> </DIV>
<DIV><FONT face=Verdana>Well, that's an interesting find.  I didn't even 
know that was there.  So, we have a precedent for this already.  I 
guess we need to make some changes to the Fast Connect procedure to not restrict 
this text.  Either that, or change this Appendix.</FONT></DIV>
<DIV><FONT face=Verdana></FONT> </DIV>
<DIV><FONT face=Verdana>Paul</FONT></DIV>
<DIV><FONT face=Verdana></FONT> </DIV>
<DIV><FONT face=Verdana></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=TLyons@sonusnet.com href="mailto:TLyons@sonusnet.com">Lyons, 
  Terry</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>Cc:</B> <A title=TLyons@sonusnet.com 
  href="mailto:TLyons@sonusnet.com">Lyons, Terry</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Monday, October 13, 2003 2:33 
  PM</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=265110918-13102003>As 
  part of this discussion, Paul Jones wrote:</SPAN></FONT></DIV>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
    <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
    class=265110918-13102003><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></BLOCKQUOTE>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
    <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></SPAN></FONT></BLOCKQUOTE>
  <DIV><SPAN class=265110918-13102003><FONT face=Arial color=#0000ff size=2>1. 
  Sorry about your head.  We appreciate your responsible stewardship of 
  H.323.</FONT></SPAN></DIV>
  <DIV><SPAN class=265110918-13102003><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN> </DIV>
  <DIV><SPAN class=265110918-13102003><FONT face=Arial color=#0000ff size=2>2. 
  There has been text since H.323 V4 that says how to CHANGE the 
  OLCs that are sent back in a Fast Connect response and NOT just by 
  dropping extensions that are not understood.  </FONT></SPAN><SPAN 
  class=265110918-13102003><FONT face=Arial color=#0000ff size=2>Appendix II 
  is admittedly non-normative and could be written more clearly, 
  </FONT></SPAN><SPAN class=265110918-13102003><FONT face=Arial color=#0000ff 
  size=2>but the level of detail suggests that some vendors 
  might implement it:</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
    <DIV><SPAN class=265110918-13102003><FONT face=Arial color=#0000ff 
    size=2><SPAN lang=EN-GB 
    style="mso-bidi-font-size: 12.0pt; mso-fareast-language: EN-GB"><FONT 
    size=3><FONT face="Times New Roman"><FONT color=#000000><SPAN lang=EN-GB 
    style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-language: EN-GB; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; mso-bidi-font-weight: bold; mso-bidi-language: AR-SA">II.8.2<SPAN 
    style="mso-tab-count: 1">             
    </SPAN>Synchronizing RSVP with fast 
    connect</SPAN></FONT></FONT></FONT></SPAN></FONT></SPAN></DIV>
    <DIV><SPAN class=265110918-13102003><FONT face=Arial color=#0000ff 
    size=2><SPAN lang=EN-GB 
    style="mso-bidi-font-size: 12.0pt; mso-fareast-language: EN-GB"><FONT 
    size=3><FONT face="Times New Roman"><FONT face=Arial color=#0000ff 
    size=2></FONT></FONT></FONT></SPAN></FONT></SPAN> </DIV>
    <DIV><SPAN class=265110918-13102003><FONT face=Arial color=#0000ff 
    size=2><SPAN lang=EN-GB 
    style="mso-bidi-font-size: 12.0pt; mso-fareast-language: EN-GB"><FONT 
    size=3><FONT face="Times New Roman"><FONT color=#000000>... A calling 
    endpoint that wishes to use RSVP in a Fast Connect procedure shall send a 
    sequence of prioritized <B>QoSCapability</B> structures in the 
    <B>OpenLogicalChannel</B> structures contained in the <B>fastStart</B> 
    element of the Setup 
  message.<o:p></o:p></FONT></FONT></FONT></SPAN></DIV></BLOCKQUOTE>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
    <DIV><SPAN lang=EN-GB 
    style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-language: EN-GB; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; mso-bidi-language: AR-SA"><FONT 
    color=#000000>Upon receiving the Fast Connect Setup message, the called 
    endpoint shall derive the <B>QOSMode</B> set using the mechanism described 
    in Table II.1. Assuming that the derived set contains a valid 
    (i.e. non-best effort intersection), the called endpoint shall respond 
    to the Setup message from the calling endpoint by <FONT 
    color=#ff0000>sending a <B>fastStart </B>element including only</FONT> the 
    <B>QoSCapabilities</B> indicated in the derived QoS set.<SPAN lang=EN-GB 
    style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-language: EN-GB; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; mso-bidi-language: AR-SA"><SPAN 
    style="mso-spacerun: yes"> </SPAN>The <B>fastStart</B> element shall be 
    sent as soon as possible (e.g. in a Call Proceeding message) to expedite the 
    resource reservation. The calling endpoint's set will be a subset of the 
    list sent by the calling endpoint in the <B>OpenLogicalChannel</B> 
    structures and will, similarly, be a sequence in decreasing order of 
    priority by <B>QOSMode</B>. Each <B>QoSCapability</B> included in the 
    <B>OpenLogicalChannel</B> in the response message indicates an acceptance of 
    the corresponding QOS level by the called endpoint<SPAN 
    class=265110918-13102003> 
  ...</SPAN></SPAN></FONT></SPAN></FONT></SPAN></DIV></BLOCKQUOTE><FONT 
  color=#000080>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
  class=265110918-13102003></SPAN></FONT></DIV><FONT face=Arial><FONT 
  size=2><SPAN class=265110918-13102003>
  <DIV><FONT face=Arial color=#0000ff size=2><SPAN class=265110918-13102003>3. 
  "Synchronized RSVP" involves the idea of suspending call establishment 
  until a requested "delay point" has been reached.  Paul's new extension 
  should address the degree to which its procedures are 
  consistent with II.8/H.323.</SPAN></FONT></DIV>
  <P> </SPAN>- tlyons@sonusnet.com +1 732 625-3003 
  x212</FONT></FONT></FONT> </P>
  <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> Tuesday, September 16, 2003 
  10:43 AM<BR><B>To:</B> itu-sg16@external.cisco.com<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></BODY></HTML>