<!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.2650.12">
<TITLE>Re: H.245 Terminates Fast Connect</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>From: Paul E. Jones</FONT>
</P>
<P><FONT SIZE=2>Pete,</FONT>
</P>
<P><FONT SIZE=2>We do have one more Rapporteur's meeting, so we can try to introduce some</FONT>
<BR><FONT SIZE=2>corrective text to address this issue and then put that forward as a delayed</FONT>
<BR><FONT SIZE=2>contribution or a Rapporteur's TD (latter preferred if we can come to an</FONT>
<BR><FONT SIZE=2>agreement).</FONT>
</P>
<P><FONT SIZE=2>I may be missing your point in (2), but perhaps this will address the</FONT>
<BR><FONT SIZE=2>question: H.323v2 says that if an endpoint initiates H.245 (tunneled or a</FONT>
<BR><FONT SIZE=2>separate connection) before getting a response to Fast Connect, Fast Connect</FONT>
<BR><FONT SIZE=2>is terminated. However, there is no such rule with H.323v3/4. An H.323v2</FONT>
<BR><FONT SIZE=2>device could initiate a Fast Connect call and then send an H.245 message to</FONT>
<BR><FONT SIZE=2>a V3 device to terminate Fast Connect, but the V3 device would not recognize</FONT>
<BR><FONT SIZE=2>that as a termination of Fast Connect. Thus, we have two devices that are</FONT>
<BR><FONT SIZE=2>out of sync.</FONT>
</P>
<P><FONT SIZE=2>Between two V2 devices, we have a race condition, because one side could</FONT>
<BR><FONT SIZE=2>send an H.245 message to terminate FC, while the other side returns a</FONT>
<BR><FONT SIZE=2>message with fastStart to accept Fast Connect. Again, the two are out of</FONT>
<BR><FONT SIZE=2>sync. This is what we tried to address by removing the text, but we did not</FONT>
<BR><FONT SIZE=2>address the V2/V3 interoperability issue. So, we still have a potential</FONT>
<BR><FONT SIZE=2>problem.</FONT>
</P>
<P><FONT SIZE=2>We could resolve this by simply stating noting the V2 behavior and</FONT>
<BR><FONT SIZE=2>discouraging a V3+ device from sending an H.245 message to a V2 device prior</FONT>
<BR><FONT SIZE=2>to learning whether FC was accepted. As a worst case, if it did send an</FONT>
<BR><FONT SIZE=2>H.245 message, it should assume that it is terminating Fast Connect in the</FONT>
<BR><FONT SIZE=2>V2 device and that a race condition may exist.</FONT>
</P>
<P><FONT SIZE=2>For V3 and V4, FC is not terminated in this way as the text now stands--</FONT>
<BR><FONT SIZE=2>endpoints are free to start H.245 in parallel. In addition, fast connect</FONT>
<BR><FONT SIZE=2>can be explicitly rejected, which gives an endpoint the "go ahead" to do</FONT>
<BR><FONT SIZE=2>logical channel signaling to get audio and video channels open prior to</FONT>
<BR><FONT SIZE=2>CONNECT.</FONT>
</P>
<P><FONT SIZE=2>There may be additional, more complex issues-- I may be over-simplifying the</FONT>
<BR><FONT SIZE=2>interoperability issues here in this reply. It seems simple on the surface,</FONT>
<BR><FONT SIZE=2>but I know that I have heard from more than one vendor that they were not</FONT>
<BR><FONT SIZE=2>happy with these changes. However, I think that if we could add some</FONT>
<BR><FONT SIZE=2>explanatory text to H.323v3/4 to describe the V2 behavior and document the</FONT>
<BR><FONT SIZE=2>issues, I think we can move forward with the text as it is now, but I do not</FONT>
<BR><FONT SIZE=2>want to make that conclusion without others also taking a serious look at</FONT>
<BR><FONT SIZE=2>this issue.</FONT>
</P>
<P><FONT SIZE=2>Paul</FONT>
</P>
<P><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, June 13, 2000 9:39 AM</FONT>
<BR><FONT SIZE=2>Subject: Re: H.245 Terminates Fast Connect</FONT>
</P>
<BR>
<P><FONT SIZE=2>> Paul,</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>> Two things...</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>> 1) What will be the procedure used in Geneva to decide v4. Will we have</FONT>
<BR><FONT SIZE=2>the</FONT>
<BR><FONT SIZE=2>> opportunity to put a delta document in? If we are, the correct (not</FONT>
<BR><FONT SIZE=2>> necessarily sensible!) procedure is to have the white paper as agreed in</FONT>
<BR><FONT SIZE=2>> Osaka, and un-do it (as a result of further information) in Geneva.</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>> 2) Fast start is limited to working on session IDs 1 and 2. As long as</FONT>
<BR><FONT SIZE=2>> H.245 specifies other session IDs with its OLC I believe this can get</FONT>
<BR><FONT SIZE=2>around</FONT>
<BR><FONT SIZE=2>> the alleged race condition. Does this make any sense?</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>> Tech-Know-Ware</FONT>
<BR><FONT SIZE=2>> pete@tech-know-ware.com</FONT>
<BR><FONT SIZE=2>> +44 1473 635863</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 <paulej@PACKETIZER.COM></FONT>
<BR><FONT SIZE=2>> To: <ITU-SG16@mailbag.cps.intel.com></FONT>
<BR><FONT SIZE=2>> Sent: 13 June 2000 11:17</FONT>
<BR><FONT SIZE=2>> Subject: H.245 Terminates Fast Connect</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>> > Folks,</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > As you know, we added some text to the H.323 Implementers Guide (section</FONT>
<BR><FONT SIZE=2>> > 6.1.7) removing the text from 8.2.1/H.323 that used to state:</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > ``The sending of encapsulated H.245 messages or the initiation of the</FONT>
<BR><FONT SIZE=2>> > separate H.245 connection by either endpoint prior to the sending of a</FONT>
<BR><FONT SIZE=2>> Q.931</FONT>
<BR><FONT SIZE=2>> > message containing fastStart by the called endpoint terminates the Fast</FONT>
<BR><FONT SIZE=2>> > Connect procedures.''</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > There was also some further supporting text added to the IG, but removed</FONT>
<BR><FONT SIZE=2>> > before the final agreed document that read (this is somewhat out of date</FONT>
<BR><FONT SIZE=2>> now</FONT>
<BR><FONT SIZE=2>> > that H.323v4 devices that use Fast Connect *shall* tunnel, but text is</FONT>
<BR><FONT SIZE=2>> > necessary for V2 and V3 entities):</FONT>
<BR><FONT SIZE=2>> > ``It is possible to switch to H.245 procedures before the Fast Connect</FONT>
<BR><FONT SIZE=2>> > procedure completes. If h245Tunneling is enabled, the terminating party</FONT>
<BR><FONT SIZE=2>> may</FONT>
<BR><FONT SIZE=2>> > start using tunneling as described in 8.2.1. If H.245 transport address</FONT>
<BR><FONT SIZE=2>> is</FONT>
<BR><FONT SIZE=2>> > included in the Setup message, then the terminating party may start the</FONT>
<BR><FONT SIZE=2>> > switch to H.245 as described in 8.2.3. In either case the Fast Connect</FONT>
<BR><FONT SIZE=2>> > procedure is terminated.''</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > Unfortunately, removing this text (particular the text that was already</FONT>
<BR><FONT SIZE=2>> > existing the H.323) has caused all kinds of grief, as there are</FONT>
<BR><FONT SIZE=2>> > implementations that do, in fact, behave according to this text found in</FONT>
<BR><FONT SIZE=2>> > H.323v2 and H.323v3. I know a few people have discussed reversing this</FONT>
<BR><FONT SIZE=2>> > decision, but no formal proposal has been submitted.</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > We need to have a discussion on this topic. I want to propose that the</FONT>
<BR><FONT SIZE=2>> > H.323v4 white paper *not* have this text removed. If people agree with</FONT>
<BR><FONT SIZE=2>> > that, I will bring a contribution that will propose reinstating this</FONT>
<BR><FONT SIZE=2>text.</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > Part of the reason for its removal is that there is a race condition</FONT>
<BR><FONT SIZE=2>that</FONT>
<BR><FONT SIZE=2>> > can occur. For example, if the caller sends a Setup with fastStart and</FONT>
<BR><FONT SIZE=2>> then</FONT>
<BR><FONT SIZE=2>> > later initiates H.245 while at the same time, the called endpoint</FONT>
<BR><FONT SIZE=2>returns</FONT>
<BR><FONT SIZE=2>> a</FONT>
<BR><FONT SIZE=2>> > message with fastStart, what state is H.245 in?</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > I believe that we can resolve the issues by documenting the fact that a</FONT>
<BR><FONT SIZE=2>> race</FONT>
<BR><FONT SIZE=2>> > condition exists and introducing a few new rules. For example, we could</FONT>
<BR><FONT SIZE=2>> say</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > that if, as in this example above, the calling endpoint initiates H.245</FONT>
<BR><FONT SIZE=2>> and</FONT>
<BR><FONT SIZE=2>> > then gets a fastStart element in a message, the caller shall recognize</FONT>
<BR><FONT SIZE=2>the</FONT>
<BR><FONT SIZE=2>> > fact that Fast Connect was accepted. Hopefully, no logical channel</FONT>
<BR><FONT SIZE=2>> > signaling will have taken place. If it has, the called party should</FONT>
<BR><FONT SIZE=2>> reject</FONT>
<BR><FONT SIZE=2>> > any conflicting channels, so the calling endpoint can recognize that a</FONT>
<BR><FONT SIZE=2>> > rejected channel is the result of Fast Connect being accepted and the</FONT>
<BR><FONT SIZE=2>> > channel is actually open (as per the FC received).</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > I would like to see if we can come to any kind of agreement on this</FONT>
<BR><FONT SIZE=2>issue</FONT>
<BR><FONT SIZE=2>> > and a recommendation for a direction forward.</FONT>
<BR><FONT SIZE=2>> ></FONT>
<BR><FONT SIZE=2>> > Best Regards,</FONT>
<BR><FONT SIZE=2>> > Paul</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>
<P><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>
</P>
</BODY>
</HTML>