<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2651.65">
<TITLE>RE: On TD26 - Fast TCS and M/S negotiation in H.323v4</TITLE>
</HEAD>
<BODY>
<P><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 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 would acutally </FONT>
<BR><FONT SIZE=2> give priority to the tunnelling information instead of the fastStart</FONT>
<BR><FONT SIZE=2> element (v2 and v3 don't say what would happen if they are present, they</FONT>
<BR><FONT SIZE=2> just say not to do it). In that particular case, the fastStart would fail</FONT>
<BR><FONT SIZE=2> but the tunnelling would be successful. So the worst case scenario is that</FONT>
<BR><FONT SIZE=2> fastStart fails, but "fast tunnelling" is successful. This doesn't seem to </FONT>
<BR><FONT SIZE=2> me to be a real interoperability problem. In any case, it seems that case</FONT>
<BR><FONT SIZE=2> 1 is much more likely.</FONT>
</P>
<BR>
<P><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) 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>> ----- 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: Saturday, May 20, 2000 1:57 PM</FONT>
<BR><FONT SIZE=2>> Subject: 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>> > I note that TD-26 has been accepted to show how TCS can be </FONT>
<BR><FONT SIZE=2>> conveyed in</FONT>
<BR><FONT SIZE=2>> > parallel with fast start.</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > However, the example shows the use of call proceeding for </FONT>
<BR><FONT SIZE=2>> receiving TCS</FONT>
<BR><FONT SIZE=2>> back</FONT>
<BR><FONT SIZE=2>> > from the remote endpoint. This is not typically an </FONT>
<BR><FONT SIZE=2>> end-to-end message,</FONT>
<BR><FONT SIZE=2>> and</FONT>
<BR><FONT SIZE=2>> > therefore how the procedure works with the gatekeeper </FONT>
<BR><FONT SIZE=2>> routed model needs</FONT>
<BR><FONT SIZE=2>> to</FONT>
<BR><FONT SIZE=2>> > be addressed.</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > Possible solutions are:</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > 1. Refer to the new text that says it is the responsibility of the</FONT>
<BR><FONT SIZE=2>> > gatekeeper to forward any tunnelled message for which none </FONT>
<BR><FONT SIZE=2>> is available</FONT>
<BR><FONT SIZE=2>> > using FACILITY. (There might be some objection from some to using a</FONT>
<BR><FONT SIZE=2>> > facility message this early in the call setup process though.)</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > 2. Restrict the tunnelling (and probably the fast start </FONT>
<BR><FONT SIZE=2>> info) to Alerting,</FONT>
<BR><FONT SIZE=2>> > Connect and Facility, which generally are end-to-end. I </FONT>
<BR><FONT SIZE=2>> believe this is</FONT>
<BR><FONT SIZE=2>> > compatible with the latest procedures for deciding when </FONT>
<BR><FONT SIZE=2>> fast start has</FONT>
<BR><FONT SIZE=2>> been</FONT>
<BR><FONT SIZE=2>> > ignored.</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > Which ever option is chosen, it would also be nice to have </FONT>
<BR><FONT SIZE=2>> a picture for</FONT>
<BR><FONT SIZE=2>> it</FONT>
<BR><FONT SIZE=2>> > also!</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>> > </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>
</P>
</BODY>
</HTML>