<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: Expediting H.245</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>Me too. </FONT>
</P>
<P><FONT SIZE=2>Unless it really improves anything, I think these last minute changes to the </FONT>
<BR><FONT SIZE=2>White document are pretty dangerous.</FONT>
</P>
<P><FONT SIZE=2>> -----Original Message-----</FONT>
<BR><FONT SIZE=2>> From: Callaghan, Robert [<A HREF="mailto:Robert.Callaghan@ICN.SIEMENS.COM">mailto:Robert.Callaghan@ICN.SIEMENS.COM</A>]</FONT>
<BR><FONT SIZE=2>> Sent: Thursday, July 27, 2000 10:49 AM</FONT>
<BR><FONT SIZE=2>> To: ITU-SG16@MAILBAG.INTEL.COM</FONT>
<BR><FONT SIZE=2>> Subject: Re: Expediting H.245</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Paul,</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Actually I like the procedure for early H.245 tunneling that </FONT>
<BR><FONT SIZE=2>> is in H.323 v4.</FONT>
<BR><FONT SIZE=2>> It allows for an incremental addition to the Fast Connect </FONT>
<BR><FONT SIZE=2>> procedure of v4</FONT>
<BR><FONT SIZE=2>> with a reasonable migration path. The additional field in SETUP that</FONT>
<BR><FONT SIZE=2>> eliminates the conflict with the requirements of V2 is </FONT>
<BR><FONT SIZE=2>> minimal. I see no</FONT>
<BR><FONT SIZE=2>> need to create a new procedure that then requires administration or</FONT>
<BR><FONT SIZE=2>> negotiation.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Bob</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> ------------------------------------------------------------------</FONT>
<BR><FONT SIZE=2>> Robert Callaghan</FONT>
<BR><FONT SIZE=2>> Siemens Enterprise Networks</FONT>
<BR><FONT SIZE=2>> Tel: +1.561.923.1756 Fax: +1.561.923.1403</FONT>
<BR><FONT SIZE=2>> Email: Robert.Callaghan@ICN.Siemens.com</FONT>
<BR><FONT SIZE=2>> ------------------------------------------------------------------</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> -----Original Message-----</FONT>
<BR><FONT SIZE=2>> From: Bob Gilman [<A HREF="mailto:rrg@LUCENT.COM">mailto:rrg@LUCENT.COM</A>]</FONT>
<BR><FONT SIZE=2>> Sent: Thursday, July 27, 2000 12:52 PM</FONT>
<BR><FONT SIZE=2>> To: ITU-SG16@mailbag.cps.intel.com</FONT>
<BR><FONT SIZE=2>> Subject: Re: Expediting H.245</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Paul-</FONT>
<BR><FONT SIZE=2>> I didn't say anything about the possiblity of offering</FONT>
<BR><FONT SIZE=2>> both Fast Connect and Fast Open. It seems to me that</FONT>
<BR><FONT SIZE=2>> doing so would present the same problems that TD-26</FONT>
<BR><FONT SIZE=2>> encountered: we'd need a new tunnel to hide H.245 in the</FONT>
<BR><FONT SIZE=2>> SETUP message and we'd need to abandon the statement that</FONT>
<BR><FONT SIZE=2>> starting H.245 terminated Fast Connect (or use the same</FONT>
<BR><FONT SIZE=2>> tunnel to continue to hide H.245). The only reason</FONT>
<BR><FONT SIZE=2>> to offer Fast Connect from an endpoint that supports</FONT>
<BR><FONT SIZE=2>> Fast Open is to work with earlier-version endpoints -</FONT>
<BR><FONT SIZE=2>> and they're the ones that can't tolerate starting H.245</FONT>
<BR><FONT SIZE=2>> before Fast Connect is completed.</FONT>
<BR><FONT SIZE=2>> I'd rather specify that an endpoint could offer either</FONT>
<BR><FONT SIZE=2>> Fast Connect or Fast Open (or accept the one offered)</FONT>
<BR><FONT SIZE=2>> at its option. The question is: how does a calling</FONT>
<BR><FONT SIZE=2>> endpoint know which to do? It could be done by out-of-</FONT>
<BR><FONT SIZE=2>> band means (administration), but it could also be done</FONT>
<BR><FONT SIZE=2>> by looking at the RAS protocolIdentifier which requires</FONT>
<BR><FONT SIZE=2>> a relationship between H.225.0 and H.245 versions. Isn't</FONT>
<BR><FONT SIZE=2>> that usually the case anyway?</FONT>
<BR><FONT SIZE=2>> Again, the advantages of Fast Open over Fast Connect and</FONT>
<BR><FONT SIZE=2>> early H.245 include:</FONT>
<BR><FONT SIZE=2>> 1. More compact messaging;</FONT>
<BR><FONT SIZE=2>> - multiple caps, one OLC;</FONT>
<BR><FONT SIZE=2>> 2. can be used anytime, not just call establishment;</FONT>
<BR><FONT SIZE=2>> - no need to switch from one protocol to another,</FONT>
<BR><FONT SIZE=2>> or from one tunnel to another, especially going</FONT>
<BR><FONT SIZE=2>> forward;</FONT>
<BR><FONT SIZE=2>> - uses current cap set;</FONT>
<BR><FONT SIZE=2>> - just as fast as Fast Connect;</FONT>
<BR><FONT SIZE=2>> 3. backward compatible with Fast Connect;</FONT>
<BR><FONT SIZE=2>> - Fast Open "callee" can accept Fast Start from an</FONT>
<BR><FONT SIZE=2>> earlier version, knows not to use Fast Open;</FONT>
<BR><FONT SIZE=2>> - but Fast Open caller should not offer Both Fast Open</FONT>
<BR><FONT SIZE=2>> and Fast Connect - needs to know which to do;</FONT>
<BR><FONT SIZE=2>> - processing is very similar to Fast Connect;</FONT>
<BR><FONT SIZE=2>> - no need to modify historical H.225.0 restrictions.</FONT>
<BR><FONT SIZE=2>> - Fast Open offered to older version endpoint results</FONT>
<BR><FONT SIZE=2>> in H.245 operation.</FONT>
<BR><FONT SIZE=2>> The problem of backward compatibility is a sticky one, given</FONT>
<BR><FONT SIZE=2>> the existing restrictions on simultaneous operation and early</FONT>
<BR><FONT SIZE=2>> switching to H.245. The sooner we remove these restrictions</FONT>
<BR><FONT SIZE=2>> from H.225.0, the better off we will be, but I think we've</FONT>
<BR><FONT SIZE=2>> actually backed ourselves into a corner, unless we effectively</FONT>
<BR><FONT SIZE=2>> change v2. I would note that the cases for which TD-26 would</FONT>
<BR><FONT SIZE=2>> work would also work for simultaneous Fast Connect and Fast</FONT>
<BR><FONT SIZE=2>> Open - but there's no way around the fact that some v2 endpoints</FONT>
<BR><FONT SIZE=2>> will object in either case.</FONT>
<BR><FONT SIZE=2>> -Bob</FONT>
<BR><FONT SIZE=2>> ----------------------------------------------------</FONT>
<BR><FONT SIZE=2>> Bob Gilman rrg@avaya.com +1 303 538 3868</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> "Paul E. Jones" wrote:</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > Bob,</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > This looks quite reasonable to me.</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > I may have missed it in here, but do you say anything about </FONT>
<BR><FONT SIZE=2>> including both</FONT>
<BR><FONT SIZE=2>> > fastStart and these new fields. Proponents of TD-26 wanted </FONT>
<BR><FONT SIZE=2>> to ensure that</FONT>
<BR><FONT SIZE=2>> > the devices could still take advantage of Fast Connect for </FONT>
<BR><FONT SIZE=2>> those devices</FONT>
<BR><FONT SIZE=2>> > that support the procedure.</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > However, I'm not sure that I understand exactly what the </FONT>
<BR><FONT SIZE=2>> advantage is over</FONT>
<BR><FONT SIZE=2>> > the combined usage of the existing Fast Connect procedure + </FONT>
<BR><FONT SIZE=2>> Early H.245.</FONT>
<BR><FONT SIZE=2>> > Can you clarify that for me?</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > Paul</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>
</BODY>
</HTML>