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