<!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.2651.65">
<TITLE>RE: On TD26 - Fast TCS and M/S negotiation in H.323v4</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>This has been discussed at lenght many times.</FONT>
</P>

<P><FONT SIZE=2>Q.931 is in direct conflict with H.225.0 on many points, including</FONT>
<BR><FONT SIZE=2>mundate tasks like clearing a call. DISCONNECT and RELEASE messages</FONT>
<BR><FONT SIZE=2>for example are mandatory in Q.931 and forbitten in H.225.0. That</FONT>
<BR><FONT SIZE=2>is a trivial example. The bottom line, is that there is some sort</FONT>
<BR><FONT SIZE=2>of common understanding that Q.931-like procedures are used, with </FONT>
<BR><FONT SIZE=2>a lot of implied exceptions and divergences. The "call control" </FONT>
<BR><FONT SIZE=2>procedures are not formally described in H.225.0. There was even </FONT>
<BR><FONT SIZE=2>a suggestion to add them to a further version of H.323. Be my guess...</FONT>
</P>

<P><FONT SIZE=2>> -----Original Message-----</FONT>
<BR><FONT SIZE=2>> From: Dave Walker [<A HREF="mailto:drwalker@SS8NETWORKS.COM">mailto:drwalker@SS8NETWORKS.COM</A>]</FONT>
<BR><FONT SIZE=2>> Sent: Thursday, June 01, 2000 11:49 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>> I'm not sure this is correct.  H.323 section 7.3.1 mandates the use of</FONT>
<BR><FONT SIZE=2>> Q.931 Annex D procedures.  In turn, that Annex uses Q.931 clause 5.</FONT>
<BR><FONT SIZE=2>> So *that* is what applies in the absence of any overriding provisions</FONT>
<BR><FONT SIZE=2>> in H.323.  So I think that Q.931/5.8.6.2 *should* apply.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> But to re-iterate what Paul asked earlier, if we had a description of</FONT>
<BR><FONT SIZE=2>> the problem that this was intended to solve, perhaps a less </FONT>
<BR><FONT SIZE=2>> contentious</FONT>
<BR><FONT SIZE=2>> solution could be found.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Regards,</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Dave Walker</FONT>
<BR><FONT SIZE=2>> SS8 Networks</FONT>
<BR><FONT SIZE=2>> Ottawa, Canada</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> > Francois Audet wrote:</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > Except that the section that Paul quotes is in Q.931 and </FONT>
<BR><FONT SIZE=2>> NOT in H.225.0.</FONT>
<BR><FONT SIZE=2>> > It has nothing to do with H.225.0. In fact, it talks about a message</FONT>
<BR><FONT SIZE=2>> > that is not even supported in H.225.0 (i.e., RELEASE).</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > To reiterate: H.323v2 does not describe how an endpoint </FONT>
<BR><FONT SIZE=2>> receiving both</FONT>
<BR><FONT SIZE=2>> > elements shall behave themselves. It just says that the </FONT>
<BR><FONT SIZE=2>> sender shall not</FONT>
<BR><FONT SIZE=2>> > include both since it would cancel fast start. This </FONT>
<BR><FONT SIZE=2>> particular case (wich</FONT>
<BR><FONT SIZE=2>> > apparently is not supported by any implementation) would </FONT>
<BR><FONT SIZE=2>> result (if you</FONT>
<BR><FONT SIZE=2>> > follow the logic of H.323v2) in ignoring fast start and </FONT>
<BR><FONT SIZE=2>> proceeding with</FONT>
<BR><FONT SIZE=2>> > H.245 tunnelling. That is NOT a backward compatibility </FONT>
<BR><FONT SIZE=2>> problem, and it</FONT>
<BR><FONT SIZE=2>> > does't break anything.</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > Rejecting the call with cause value 100 is definitively NOT </FONT>
<BR><FONT SIZE=2>> what H.323v2 says.</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > > In Q.931, the user-user IE is typically optional, so the </FONT>
<BR><FONT SIZE=2>> clause that</FONT>
<BR><FONT SIZE=2>> > > Paul Long's been quoting wouldn't apply.  However, since </FONT>
<BR><FONT SIZE=2>> H.323 makes</FONT>
<BR><FONT SIZE=2>> > > the UUIE mandatory, it *does* apply in the case under discussion.</FONT>
<BR><FONT SIZE=2>> > > I think that the statement contained in TD-26, that it preserves</FONT>
<BR><FONT SIZE=2>> > > backwards compatibility, is completely wrong.  The </FONT>
<BR><FONT SIZE=2>> correct statement</FONT>
<BR><FONT SIZE=2>> > > should have been that it doesn't break implementations </FONT>
<BR><FONT SIZE=2>> known to the</FONT>
<BR><FONT SIZE=2>> > > authors.  I agree with Paul that we should try to develop a better</FONT>
<BR><FONT SIZE=2>> > > solution.</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>
</P>

</BODY>
</HTML>