<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: On TD26 - Fast TCS and M/S negotiation in H.323v4</TITLE>
<META content="text/html; charset=windows-1252" http-equiv=Content-Type>
<META content="MSHTML 5.00.3013.2600" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial>Francois,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial>I agree that the behavior is desirable, but I still argue 
that it will break backward compatibility.  If we can agree with a new 
field "earlyH245" as a special field for SETUP to do essentially the same thing, 
but only for V4, I would be quite happy-- we get the same end result without V3 
and V2 compatibility issues.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial>I do not want to wait until Portland.  The Whitepaper 
drafts are due before then and I hope that that meeting will be focused on only 
critical issues in H.323 and that most of our time will be spent on further 
development of Annexes and perhaps forward thinking on V5 :-)</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial>Paul</FONT></DIV>
<DIV> </DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
  <A href="mailto:audet@NORTELNETWORKS.COM" 
  title=audet@NORTELNETWORKS.COM>Francois Audet</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A 
  href="mailto:ITU-SG16@mailbag.cps.intel.com" 
  title=ITU-SG16@mailbag.cps.intel.com>ITU-SG16@mailbag.cps.intel.com</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Thursday, June 01, 2000 8:33 
  AM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> Re: On TD26 - Fast TCS and M/S 
  negotiation in H.323v4</DIV>
  <DIV><BR></DIV>
  <P><FONT size=2>I fully agree with Orit.</FONT> </P>
  <P><FONT size=2>So far, I haven't heard of anybody that actually implemented 
  clearing the call</FONT> <BR><FONT size=2>if both fastStart and h245Control 
  are present in SETUP. I would argue, it would</FONT> <BR><FONT size=2>be a 
  very bad implementation, regardless of what they interpreted the spec 
  </FONT><BR><FONT size=2>saying.</FONT> </P>
  <P><FONT size=2>This being said, it seems that it will not create any 
  interoperability problems.</FONT> <BR><FONT size=2>The *worst* case scenario 
  (here again, I haven't heard of anybody that </FONT><BR><FONT size=2>actually 
  implemented it that way) is that the call would proceed as fast 
  </FONT><BR><FONT size=2>tunnelling (as per the spec) and ignore the fast 
  start.</FONT> </P>
  <P><FONT size=2>The benefits of doing the fastStart and the fast tunnelling at 
  the same time</FONT> <BR><FONT size=2>far outweight the theoretical backward 
  compatibility problems.</FONT> </P>
  <P><FONT size=2>If anybody wants to revoke the Osaka agreement, contributions 
  in Portland are</FONT> <BR><FONT size=2>welcomed. ;^)</FONT> </P>
  <P><FONT size=2>> -----Original Message-----</FONT> <BR><FONT size=2>> 
  From: Orit Levin [<A 
  href="mailto:orit@RADVISION.COM">mailto:orit@RADVISION.COM</A>]</FONT> 
  <BR><FONT size=2>> Sent: Wednesday, May 31, 2000 8:32 AM</FONT> <BR><FONT 
  size=2>> To: ITU-SG16@MAILBAG.INTEL.COM</FONT> <BR><FONT size=2>> 
  Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4</FONT> 
  <BR><FONT size=2>> </FONT><BR><FONT size=2>> </FONT><BR><FONT 
  size=2>> Hi Paul and all the others!</FONT> <BR><FONT size=2>> Here it 
  is (and it is not surprising for those, participated in Osaka</FONT> <BR><FONT 
  size=2>> meeting).</FONT> <BR><FONT size=2>> I believe, that it is the 
  last moment to clear the confusion </FONT><BR><FONT size=2>> in the 
  least</FONT> <BR><FONT size=2>> harmful way (even on the expense of 
  THEORETICAL H.323v.2 "strict"</FONT> <BR><FONT size=2>> 
  implementations).</FONT> <BR><FONT size=2>> RADVision definitely votes for 
  allowing Fast Connect and </FONT><BR><FONT size=2>> H.245 tunneling 
  in</FONT> <BR><FONT size=2>> Setup, supporting by that TD-26.</FONT> 
  <BR><FONT size=2>> Best Regards,</FONT> <BR><FONT size=2>> Orit 
  Levin</FONT> <BR><FONT size=2>> RADVision Inc.</FONT> <BR><FONT size=2>> 
  575 Corporate Drive Suite 420</FONT> <BR><FONT size=2>> Mahwah, NJ 
  07430</FONT> <BR><FONT size=2>> Tel: 1 201 529 4300  (230)</FONT> 
  <BR><FONT size=2>> Fax: 1 201 529 3516</FONT> <BR><FONT size=2>> 
  www.radvision.com</FONT> <BR><FONT size=2>> orit@radvision.com</FONT> 
  <BR><FONT size=2>> -----Original Message-----</FONT> <BR><FONT size=2>> 
  From: Paul E. Jones <paulej@PACKETIZER.COM></FONT> <BR><FONT size=2>> 
  To: ITU-SG16@MAILBAG.INTEL.COM <ITU-SG16@MAILBAG.INTEL.COM></FONT> 
  <BR><FONT size=2>> Date: Wednesday, May 31, 2000 1:46 AM</FONT> <BR><FONT 
  size=2>> Subject: Re: On TD26 - Fast TCS and M/S negotiation in 
  H.323v4</FONT> <BR><FONT size=2>> </FONT><BR><FONT size=2>> 
  </FONT><BR><FONT size=2>> >Pete,</FONT> <BR><FONT size=2>> 
  ></FONT> <BR><FONT size=2>> >If we could follow such logic, I would 
  agree that this </FONT><BR><FONT size=2>> procedure would be</FONT> 
  <BR><FONT size=2>> >worth perusing.  Unfortunately, the inclusion 
  of fastStart </FONT><BR><FONT size=2>> and tunneled</FONT> <BR><FONT 
  size=2>> >H.245 messages in the SETUP message is not defined.  
  There </FONT><BR><FONT size=2>> is no way to</FONT> <BR><FONT size=2>> 
  >predict how a V2 device will behave when receiving these </FONT><BR><FONT 
  size=2>> messages.  I like</FONT> <BR><FONT size=2>> >the idea, 
  but I'm afraid we will compromise backward compatibility by</FONT> <BR><FONT 
  size=2>> >including it.</FONT> <BR><FONT size=2>> ></FONT> 
  <BR><FONT size=2>> >Let's assume a V2 device does *not* recognize the 
  tunneled </FONT><BR><FONT size=2>> H.245 in SETUP</FONT> <BR><FONT 
  size=2>> >(ignores it), but accepts the Fast Connect proposal.  
  </FONT><BR><FONT size=2>> Assume, also, that in</FONT> <BR><FONT 
  size=2>> >the CONNECT message, the endpoint includes the fastStart 
  </FONT><BR><FONT size=2>> element *and* a</FONT> <BR><FONT size=2>> 
  >tunneled TCS message.  What could the calling endpoint 
  </FONT><BR><FONT size=2>> *safely* assume?</FONT> <BR><FONT size=2>> 
  ></FONT> <BR><FONT size=2>> >Assume that CONNECT was the first 
  message received following </FONT><BR><FONT size=2>> the SETUP if</FONT> 
  <BR><FONT size=2>> >that helps complicate matters further for you. 
  :-)</FONT> <BR><FONT size=2>> ></FONT> <BR><FONT size=2>> >I just 
  need further convincing.</FONT> <BR><FONT size=2>> ></FONT> <BR><FONT 
  size=2>> >Paul</FONT> <BR><FONT size=2>> ></FONT> <BR><FONT 
  size=2>> >----- Original Message -----</FONT> <BR><FONT size=2>> 
  >From: "Pete Cordell" <pete@TECH-KNOW-WARE.COM></FONT> <BR><FONT 
  size=2>> >To: <ITU-SG16@mailbag.cps.intel.com></FONT> <BR><FONT 
  size=2>> >Sent: Tuesday, May 30, 2000 2:40 PM</FONT> <BR><FONT 
  size=2>> >Subject: Re: On TD26 - Fast TCS and M/S negotiation in 
  H.323v4</FONT> <BR><FONT size=2>> ></FONT> <BR><FONT size=2>> 
  ></FONT> <BR><FONT size=2>> >> RE: On TD26 - Fast TCS and M/S 
  negotiation in H.323v4Hi </FONT><BR><FONT size=2>> Paul, Francois,</FONT> 
  <BR><FONT size=2>> >and</FONT> <BR><FONT size=2>> >> 
  others,</FONT> <BR><FONT size=2>> >></FONT> <BR><FONT size=2>> 
  >> I think it is important that we make it work, but as you 
  </FONT><BR><FONT size=2>> say, it has to</FONT> <BR><FONT size=2>> 
  be</FONT> <BR><FONT size=2>> >> reliable and any burden of insuring 
  backwards </FONT><BR><FONT size=2>> compatibility has to be</FONT> 
  <BR><FONT size=2>> >placed</FONT> <BR><FONT size=2>> >> on the 
  newer EP.  In this case it is primarily an issue </FONT><BR><FONT 
  size=2>> for the calling</FONT> <BR><FONT size=2>> >EP.</FONT> 
  <BR><FONT size=2>> >></FONT> <BR><FONT size=2>> >> As I see 
  it, (and I'm sure you'll correct me if I'm not </FONT><BR><FONT size=2>> 
  seeing it right!)</FONT> <BR><FONT size=2>> >> when there is H.245 in 
  the SETUP message, then the called </FONT><BR><FONT size=2>> endpoint 
  can</FONT> <BR><FONT size=2>> >> either ignore the H.245, or accept 
  it.  (It could clear </FONT><BR><FONT size=2>> the call, but</FONT> 
  <BR><FONT size=2>> I'll</FONT> <BR><FONT size=2>> >> ignore that 
  one for the time being.)  There is also the </FONT><BR><FONT size=2>> 
  case where it</FONT> <BR><FONT size=2>> >> decides that the H.245 
  takes precedence over fast start.</FONT> <BR><FONT size=2>> >></FONT> 
  <BR><FONT size=2>> >> Knowing whether fast start has been accepted is 
  fairly </FONT><BR><FONT size=2>> straight forward.</FONT> <BR><FONT 
  size=2>> >></FONT> <BR><FONT size=2>> >> I think the called 
  endpoint has a very good idea of what </FONT><BR><FONT size=2>> decision 
  was</FONT> <BR><FONT size=2>> >taken</FONT> <BR><FONT size=2>> 
  >> with regard to the H.245 based on the reply from the </FONT><BR><FONT 
  size=2>> called endpoint.</FONT> <BR><FONT size=2>> >></FONT> 
  <BR><FONT size=2>> >> - If the reply message in which the fast start 
  information </FONT><BR><FONT size=2>> is contained</FONT> <BR><FONT 
  size=2>> >> contains H.245, then it can assume that the called EP 
  </FONT><BR><FONT size=2>> accepted the H.245.</FONT> <BR><FONT size=2>> 
  >> The H.245 state about which channels are open will be 
  </FONT><BR><FONT size=2>> updated according</FONT> <BR><FONT size=2>> 
  to</FONT> <BR><FONT size=2>> >> the fast start parameters.</FONT> 
  <BR><FONT size=2>> >></FONT> <BR><FONT size=2>> >> - If the 
  reply message in which the fast start information </FONT><BR><FONT size=2>> 
  is contained</FONT> <BR><FONT size=2>> >> contains no H.245, then it 
  has probably ignored the H.245.</FONT> <BR><FONT size=2>> >></FONT> 
  <BR><FONT size=2>> >> --- If H.245 tunneling is enabled, but the 
  calling </FONT><BR><FONT size=2>> endpoint believes that</FONT> <BR><FONT 
  size=2>> >> the called endpoint ignored its H.245 in the SETUP 
  </FONT><BR><FONT size=2>> message, then it can</FONT> <BR><FONT size=2>> 
  >> re-transmit its capability set when it becomes OK to do so 
  </FONT><BR><FONT size=2>> under the</FONT> <BR><FONT size=2>> 
  >normal</FONT> <BR><FONT size=2>> >> fast start/H.245 rules.  
  (It should probably modify the </FONT><BR><FONT size=2>> sequence 
  number</FONT> <BR><FONT size=2>> >> before doing this.)</FONT> 
  <BR><FONT size=2>> >></FONT> <BR><FONT size=2>> >> --- In 
  the case where the called EP actually did accept </FONT><BR><FONT size=2>> 
  the H.245 but did</FONT> <BR><FONT size=2>> >> not reply as expected, 
  the called EP will receive a second </FONT><BR><FONT size=2>> 
  capability</FONT> <BR><FONT size=2>> set.</FONT> <BR><FONT size=2>> 
  >> However, endpoints should be able to handle this as this 
  </FONT><BR><FONT size=2>> is a standard</FONT> <BR><FONT size=2>> 
  >H.245</FONT> <BR><FONT size=2>> >> procedure.</FONT> <BR><FONT 
  size=2>> >></FONT> <BR><FONT size=2>> >> So as long as V4 
  endpoints use this kind of logic then I </FONT><BR><FONT size=2>> think it 
  is safe</FONT> <BR><FONT size=2>> >> for them to combine both H.245 
  and fast start.</FONT> <BR><FONT size=2>> >></FONT> <BR><FONT 
  size=2>> >> Perhaps we should document the above more formally for 
  V4, </FONT><BR><FONT size=2>> and maybe say</FONT> <BR><FONT size=2>> 
  >> that if a V4 EP wants to accept both fast start and H.245 
  </FONT><BR><FONT size=2>> Cap tunnelling</FONT> <BR><FONT size=2>> 
  >at</FONT> <BR><FONT size=2>> >> the same time then it SHALL put 
  the fast start and H.245 </FONT><BR><FONT size=2>> in the same</FONT> 
  <BR><FONT size=2>> >> message.</FONT> <BR><FONT size=2>> 
  >></FONT> <BR><FONT size=2>> >> Does this sound in any way 
  reasonable?</FONT> <BR><FONT size=2>> >></FONT> <BR><FONT size=2>> 
  >> Pete.</FONT> <BR><FONT size=2>> >></FONT> <BR><FONT 
  size=2>> >> =============================================</FONT> 
  <BR><FONT size=2>> >> Pete Cordell</FONT> <BR><FONT size=2>> 
  >> pete@tech-know-ware.com</FONT> <BR><FONT size=2>> >> 
  =============================================</FONT> <BR><FONT size=2>> 
  >></FONT> <BR><FONT size=2>> >> ----- Original Message 
  -----</FONT> <BR><FONT size=2>> >> From: Paul E. Jones</FONT> 
  <BR><FONT size=2>> >> To: Francois Audet ; Mailing list for parties 
  associated </FONT><BR><FONT size=2>> with ITU-T Study</FONT> <BR><FONT 
  size=2>> >> Group 16 ; pete</FONT> <BR><FONT size=2>> >> Cc: 
  Alexander (Sasha) Ruditsky ; Dale Skran</FONT> <BR><FONT size=2>> >> 
  Sent: 30 May 2000 08:20</FONT> <BR><FONT size=2>> >> Subject: Re: On 
  TD26 - Fast TCS and M/S negotiation in H.323v4</FONT> <BR><FONT size=2>> 
  >></FONT> <BR><FONT size=2>> >></FONT> <BR><FONT size=2>> 
  >> Francois,</FONT> <BR><FONT size=2>> >></FONT> <BR><FONT 
  size=2>> >> But the possibility exists that a V2 device may accept 
  </FONT><BR><FONT size=2>> both, reject one</FONT> <BR><FONT size=2>> 
  or</FONT> <BR><FONT size=2>> >> the other, or reject both since a 
  SETUP containing </FONT><BR><FONT size=2>> fastStart and tunneled</FONT> 
  <BR><FONT size=2>> >> H.245 is "illegal".  Heck, a "strict" 
  endpoint may even </FONT><BR><FONT size=2>> drop the call,</FONT> <BR><FONT 
  size=2>> but</FONT> <BR><FONT size=2>> >I</FONT> <BR><FONT 
  size=2>> >> suspect that nobody would go that far.</FONT> <BR><FONT 
  size=2>> >></FONT> <BR><FONT size=2>> >> If fastStart was 
  accepted and the remote end returns the </FONT><BR><FONT size=2>> tunneling 
  flag</FONT> <BR><FONT size=2>> >set</FONT> <BR><FONT size=2>> 
  >> to TRUE, how do you know if it did or did not process the 
  </FONT><BR><FONT size=2>> H.245 message</FONT> <BR><FONT size=2>> 
  in</FONT> <BR><FONT size=2>> >> the SETUP?  I'm not convinced 
  that this procedure is going to make</FONT> <BR><FONT size=2>> 
  >everybody</FONT> <BR><FONT size=2>> >> happy.  (Same could 
  be said if fastStart is not accepted, </FONT><BR><FONT size=2>> I 
  suppose.)</FONT> <BR><FONT size=2>> >></FONT> <BR><FONT size=2>> 
  >> My concern is that this issue is potentially damaging to some</FONT> 
  <BR><FONT size=2>> >> implementations.  If all of the vendors 
  have no problem </FONT><BR><FONT size=2>> with this change,</FONT> 
  <BR><FONT size=2>> >> then I can live with it.  Cisco has no 
  objection, but I </FONT><BR><FONT size=2>> would like to</FONT> <BR><FONT 
  size=2>> >> solicit the input of others-- changes like this, even as 
  </FONT><BR><FONT size=2>> good as they</FONT> <BR><FONT size=2>> 
  are,</FONT> <BR><FONT size=2>> >> could cause serious 
  problems.</FONT> <BR><FONT size=2>> >></FONT> <BR><FONT size=2>> 
  >> It appears that we've already made a similar "mistake" by 
  </FONT><BR><FONT size=2>> allowing H.245</FONT> <BR><FONT size=2>> 
  >> procedures to be done in parallel to fastConnect by </FONT><BR><FONT 
  size=2>> removing the clause</FONT> <BR><FONT size=2>> >that</FONT> 
  <BR><FONT size=2>> >> says that if we start H.245, fast connect is 
  terminated.  </FONT><BR><FONT size=2>> That text was</FONT> <BR><FONT 
  size=2>> >> removed, because there was a race condition that could 
  </FONT><BR><FONT size=2>> occur, which could</FONT> <BR><FONT size=2>> 
  >> result in interoperability problems.  The right solution 
  </FONT><BR><FONT size=2>> probably should</FONT> <BR><FONT size=2>> 
  >> have been to document the race condition and tell people 
  </FONT><BR><FONT size=2>> "don't do that".</FONT> <BR><FONT size=2>> 
  >> However, we made the change and now some manufacturers have 
  serious</FONT> <BR><FONT size=2>> >backward</FONT> <BR><FONT size=2>> 
  >> compatibility problems.  I don't want to make the same 
  </FONT><BR><FONT size=2>> mistake again.</FONT> <BR><FONT size=2>> 
  >></FONT> <BR><FONT size=2>> >> Comments?</FONT> <BR><FONT 
  size=2>> >></FONT> <BR><FONT size=2>> >> Paul</FONT> 
  <BR><FONT size=2>> >></FONT> <BR><FONT size=2>> >> ----- 
  Original Message -----</FONT> <BR><FONT size=2>> >> From: Francois 
  Audet</FONT> <BR><FONT size=2>> >> To: 'Paul E. Jones' ; Mailing list 
  for parties associated </FONT><BR><FONT size=2>> with ITU-T</FONT> 
  <BR><FONT size=2>> Study</FONT> <BR><FONT size=2>> >> Group 16 ; 
  pete</FONT> <BR><FONT size=2>> >> Cc: Alexander (Sasha) Ruditsky ; 
  Dale Skran</FONT> <BR><FONT size=2>> >> Sent: Monday, May 29, 2000 
  11:00 PM</FONT> <BR><FONT size=2>> >> Subject: RE: On TD26 - Fast TCS 
  and M/S negotiation in H.323v4</FONT> <BR><FONT size=2>> >></FONT> 
  <BR><FONT size=2>> >></FONT> <BR><FONT size=2>> >> Yes, a 
  few comments:</FONT> <BR><FONT size=2>> >> 1 It seems that all 
  current implementations that we could think of</FONT> <BR><FONT size=2>> 
  >>   would simply ignore the tunnelling information if the 
  fastStart</FONT> <BR><FONT size=2>> >>   element is 
  present. This means, that there would be no</FONT> <BR><FONT size=2>> 
  >>   interoperability problems. Fast start would be 
  </FONT><BR><FONT size=2>> sucessfull, but not</FONT> <BR><FONT size=2>> 
  >>   tunnelling, which would mean that tunnelling would have 
  to happen</FONT> <BR><FONT size=2>> >>   after the SETUP 
  message, as per H.323v2 and v3.</FONT> <BR><FONT size=2>> >> 2 There 
  is a small possibility that an implementation </FONT><BR><FONT size=2>> 
  would acutally</FONT> <BR><FONT size=2>> >>   give priority 
  to the tunnelling information instead of </FONT><BR><FONT size=2>> the 
  fastStart</FONT> <BR><FONT size=2>> >>   element (v2 and v3 
  don't say what would happen if they </FONT><BR><FONT size=2>> are 
  present,</FONT> <BR><FONT size=2>> they</FONT> <BR><FONT size=2>> 
  >>   just say not to do it). In that particular case, the 
  </FONT><BR><FONT size=2>> fastStart would</FONT> <BR><FONT size=2>> 
  >fail</FONT> <BR><FONT size=2>> >>   but the tunnelling 
  would be successful. So the worst </FONT><BR><FONT size=2>> case scenario 
  is</FONT> <BR><FONT size=2>> >that</FONT> <BR><FONT size=2>> 
  >>   fastStart fails, but "fast tunnelling" is successful. 
  </FONT><BR><FONT size=2>> This doesn't seem</FONT> <BR><FONT size=2>> 
  >to</FONT> <BR><FONT size=2>> >>   me to be a real 
  interoperability problem. In any case, </FONT><BR><FONT size=2>> it seems 
  that</FONT> <BR><FONT size=2>> >case</FONT> <BR><FONT size=2>> 
  >>   1 is much more likely.</FONT> <BR><FONT size=2>> 
  >></FONT> <BR><FONT size=2>> >></FONT> <BR><FONT size=2>> 
  >> > -----Original Message-----</FONT> <BR><FONT size=2>> >> 
  > From: Paul E. Jones [<A 
  href="mailto:paulej@packetizer.com">mailto:paulej@packetizer.com</A>]</FONT> 
  <BR><FONT size=2>> >> > Sent: Monday, May 29, 2000 7:46 PM</FONT> 
  <BR><FONT size=2>> >> > To: Mailing list for parties associated 
  with ITU-T Study</FONT> <BR><FONT size=2>> >> > Group 16; 
  pete</FONT> <BR><FONT size=2>> >> > Cc: Audet, Francois 
  [SC9:4K02:EXCH]; Alexander (Sasha) </FONT><BR><FONT size=2>> Ruditsky; 
  Dale</FONT> <BR><FONT size=2>> >> > Skran</FONT> <BR><FONT 
  size=2>> >> > Subject: Re: On TD26 - Fast TCS and M/S negotiation 
  in H.323v4</FONT> <BR><FONT size=2>> >> ></FONT> <BR><FONT 
  size=2>> >> ></FONT> <BR><FONT size=2>> >> > Pete, 
  Sasha, Francois, Dale, et al,</FONT> <BR><FONT size=2>> >> 
  ></FONT> <BR><FONT size=2>> >> > I have concerns about this 
  document that differ from Pete's.</FONT> <BR><FONT size=2>> >> > 
  However, since</FONT> <BR><FONT size=2>> >> > discussion on this 
  document has started, I thought I might as</FONT> <BR><FONT size=2>> 
  >> > well express</FONT> <BR><FONT size=2>> >> > my 
  concerns now while the material is fresh on people's minds.</FONT> <BR><FONT 
  size=2>> >> ></FONT> <BR><FONT size=2>> >> > The issue 
  has to do with the very first sentence of the</FONT> <BR><FONT size=2>> 
  >> > proposal, which says</FONT> <BR><FONT size=2>> >> > 
  to strike "shall not" and replace it with "may".  So, V2</FONT> <BR><FONT 
  size=2>> >> > devices shall not</FONT> <BR><FONT size=2>> 
  >> > send a fastStart element and an H.245 message in SETUP, 
  but</FONT> <BR><FONT size=2>> >> > V4 may.  This</FONT> 
  <BR><FONT size=2>> >> > seems to be a serious backward 
  compatibility issue.  If a V2</FONT> <BR><FONT size=2>> >> > 
  device were to</FONT> <BR><FONT size=2>> >> > receive a SETUP 
  containing fastStart and an encapsulated</FONT> <BR><FONT size=2>> >> 
  > H.245 message, what</FONT> <BR><FONT size=2>> >> > would it 
  do?  I believe the behavior is not defined.</FONT> <BR><FONT size=2>> 
  >> ></FONT> <BR><FONT size=2>> >> > Would somebody like 
  to comment?</FONT> <BR><FONT size=2>> >> ></FONT> <BR><FONT 
  size=2>> >> > Paul</FONT> <BR><FONT size=2>> >> 
  ></FONT> <BR><FONT size=2>> >> ... cut ...</FONT> <BR><FONT 
  size=2>> >></FONT> <BR><FONT size=2>> >> </FONT><BR><FONT 
  size=2>> 
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~</FONT> 
  <BR><FONT size=2>> >> For help on this mail list, send "HELP 
  ITU-SG16" in a message to</FONT> <BR><FONT size=2>> >> 
  listserv@mailbag.intel.com</FONT> <BR><FONT size=2>> >></FONT> 
  <BR><FONT size=2>> ></FONT> <BR><FONT size=2>> 
  >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~</FONT> 
  <BR><FONT size=2>> >For help on this mail list, send "HELP ITU-SG16" in 
  a message to</FONT> <BR><FONT size=2>> 
  >listserv@mailbag.intel.com</FONT> <BR><FONT size=2>> </FONT><BR><FONT 
  size=2>> 
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~</FONT> 
  <BR><FONT size=2>> For help on this mail list, send "HELP ITU-SG16" in a 
  message to</FONT> <BR><FONT size=2>> listserv@mailbag.intel.com</FONT> 
  <BR><FONT size=2>> </FONT></P></BLOCKQUOTE></BODY></HTML>