<!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>Actually, I believe the editor (correct me if I'm wrong Paul Jones) did some </FONT>
<BR><FONT SIZE=2>editorial (I love this word) changes from what was in TD-26a. So Paul Long should </FONT>
<BR><FONT SIZE=2>really look at the latest and greatest H.323v4.</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: Wednesday, July 26, 2000 8:28 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>> This topic was discussed in the Osaka meeting. The need for a faster</FONT>
<BR><FONT SIZE=2>> started H.245 was very apparent for several reasons. The compromised</FONT>
<BR><FONT SIZE=2>> proposal is presented in TD-26a from Osaka. It is the same </FONT>
<BR><FONT SIZE=2>> as your proposal</FONT>
<BR><FONT SIZE=2>> in the number of required messages. It also solves the problems of</FONT>
<BR><FONT SIZE=2>> negotiating particular elements by including full TCS and M/S in the</FONT>
<BR><FONT SIZE=2>> procedure.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Please look at this.</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: Paul Long [<A HREF="mailto:Plong@SMITHMICRO.COM">mailto:Plong@SMITHMICRO.COM</A>]</FONT>
<BR><FONT SIZE=2>> Sent: Wednesday, July 26, 2000 11:00 AM</FONT>
<BR><FONT SIZE=2>> To: ITU-SG16@mailbag.cps.intel.com</FONT>
<BR><FONT SIZE=2>> Subject: Expediting H.245</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Here is a proposal for "expediting" H.245--eliminating explicit</FONT>
<BR><FONT SIZE=2>> establishment of the H.245 control channel, H.323 Phase B. </FONT>
<BR><FONT SIZE=2>> But first, here</FONT>
<BR><FONT SIZE=2>> are the reasons for doing so:</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> - At SuperOp! some people incorrectly assumed that an EP is </FONT>
<BR><FONT SIZE=2>> not required to</FONT>
<BR><FONT SIZE=2>> support H.245 if Fast Connect is performed. However wrong </FONT>
<BR><FONT SIZE=2>> they may be, we</FONT>
<BR><FONT SIZE=2>> all probably believe to some degree that this would be a </FONT>
<BR><FONT SIZE=2>> natural thing to</FONT>
<BR><FONT SIZE=2>> do.</FONT>
<BR><FONT SIZE=2>> - A much-respected colleague at another company said that </FONT>
<BR><FONT SIZE=2>> H.245 is a major</FONT>
<BR><FONT SIZE=2>> encumbrance for large-scale entities.</FONT>
<BR><FONT SIZE=2>> - Some vendors have expressed a desire to use H.245 features, </FONT>
<BR><FONT SIZE=2>> e.g., DTMF and</FONT>
<BR><FONT SIZE=2>> third-party pause, without first having to initiate H.245 </FONT>
<BR><FONT SIZE=2>> procedures, i.e.,</FONT>
<BR><FONT SIZE=2>> TermCap exchange and MSD.</FONT>
<BR><FONT SIZE=2>> - I have heard that SIP-H.323 interworking may eliminate </FONT>
<BR><FONT SIZE=2>> H.245. This may</FONT>
<BR><FONT SIZE=2>> primarily be due to the message-intensive channel establishment phase.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> In order to tempt you into actually reading all of the following</FONT>
<BR><FONT SIZE=2>> explanation, here's the end result. The minimal dialogue necessary to</FONT>
<BR><FONT SIZE=2>> establish a call and the H.245 session in both directions:</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Setup(expedite) --></FONT>
<BR><FONT SIZE=2>> <-- Connect(expedite)</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Here's how it can be done. Add the following ASN.1 component </FONT>
<BR><FONT SIZE=2>> to Setup and</FONT>
<BR><FONT SIZE=2>> all of the possible responses, i.e., Alerting, </FONT>
<BR><FONT SIZE=2>> CallProceeding, Connect,</FONT>
<BR><FONT SIZE=2>> Facility, and Progress:</FONT>
<BR><FONT SIZE=2>> expedite ExpediteH245Tunneling OPTIONAL</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Define this new type:</FONT>
<BR><FONT SIZE=2>> ExpediteH245Tunneling SEQUENCE</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 Setup, the presence of expedite _requests_ an expedited </FONT>
<BR><FONT SIZE=2>> H.245 session;</FONT>
<BR><FONT SIZE=2>> for all the other messages, this _grants_ the request. An EP </FONT>
<BR><FONT SIZE=2>> shall only</FONT>
<BR><FONT SIZE=2>> encode expedite if it also sets h245Tunneling to TRUE in the </FONT>
<BR><FONT SIZE=2>> same message.</FONT>
<BR><FONT SIZE=2>> An expedited H.245 session causes both EPs to treat the H.245 </FONT>
<BR><FONT SIZE=2>> session _as</FONT>
<BR><FONT SIZE=2>> if_ they had already successfully performed the TermCap </FONT>
<BR><FONT SIZE=2>> exchange and MSD</FONT>
<BR><FONT SIZE=2>> before the calling EP transmitted Setup. Once the called EP grants the</FONT>
<BR><FONT SIZE=2>> request, the H.245 state in both EPs is the same as if the TCSs had</FONT>
<BR><FONT SIZE=2>> contained no OPTIONAL components, the protocolIdentifiers </FONT>
<BR><FONT SIZE=2>> were set to the</FONT>
<BR><FONT SIZE=2>> lowest version of H.245 specified by H.323 based on the </FONT>
<BR><FONT SIZE=2>> H.225.0 version, and</FONT>
<BR><FONT SIZE=2>> the result of the MSD is that the calling EP is MASTER [could </FONT>
<BR><FONT SIZE=2>> use any other</FONT>
<BR><FONT SIZE=2>> method for MSD, including the EP with the "greater" IP address is the</FONT>
<BR><FONT SIZE=2>> MASTER].</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> If the called EP accepts at least one Fast Connect channel, all of the</FONT>
<BR><FONT SIZE=2>> accepted channels are inherited as capabilities by both EPs </FONT>
<BR><FONT SIZE=2>> as if they had</FONT>
<BR><FONT SIZE=2>> successfully performed a second TermCap exchange before the called EP</FONT>
<BR><FONT SIZE=2>> responded to Setup. Once the called EP accepts the Fast </FONT>
<BR><FONT SIZE=2>> Connect channel(s),</FONT>
<BR><FONT SIZE=2>> the H.245 state in both EPs is the same as if the TCSs had contained</FONT>
<BR><FONT SIZE=2>> capabilityTables with entries for all Fast Connect OLCs, </FONT>
<BR><FONT SIZE=2>> numbered starting</FONT>
<BR><FONT SIZE=2>> with 0, and single capabilityDescriptors components with a single</FONT>
<BR><FONT SIZE=2>> capabilityDescriptor, numbered 0, containing a simultaneous </FONT>
<BR><FONT SIZE=2>> capability for</FONT>
<BR><FONT SIZE=2>> each unique sessionID value and an alternative capability for </FONT>
<BR><FONT SIZE=2>> each OLC.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> In accordance with procedures already defined in H.245 and </FONT>
<BR><FONT SIZE=2>> H.323, the EPs</FONT>
<BR><FONT SIZE=2>> may subsequently perform the TermCap exchange and MSD at any </FONT>
<BR><FONT SIZE=2>> time and any</FONT>
<BR><FONT SIZE=2>> number of times to update the state of H.245 in the </FONT>
<BR><FONT SIZE=2>> respective EPs. For</FONT>
<BR><FONT SIZE=2>> example, the called EP can initiate the TermCap exchange </FONT>
<BR><FONT SIZE=2>> "again" immediately</FONT>
<BR><FONT SIZE=2>> upon receiving Setup (e.g., in Alerting) to indicate advanced </FONT>
<BR><FONT SIZE=2>> DTMF caps, and</FONT>
<BR><FONT SIZE=2>> the calling EP can start exploiting those caps in the very </FONT>
<BR><FONT SIZE=2>> same message it</FONT>
<BR><FONT SIZE=2>> returns the TCSAck.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Setup(expedite) --></FONT>
<BR><FONT SIZE=2>> <-- Alerting(expedite, TCS w/UserInputCap=dtmf)</FONT>
<BR><FONT SIZE=2>> Facility(TCSAck+Signal="7#0") --></FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Benefits:</FONT>
<BR><FONT SIZE=2>> 1. Very little additional signaling is required (only a new </FONT>
<BR><FONT SIZE=2>> codepoint)--this</FONT>
<BR><FONT SIZE=2>> feature is mostly new interpretation of existing signaling.</FONT>
<BR><FONT SIZE=2>> 2. The backwards-compatibility problems associated with </FONT>
<BR><FONT SIZE=2>> allowing fastStart</FONT>
<BR><FONT SIZE=2>> and h245Control in Setup are avoided.</FONT>
<BR><FONT SIZE=2>> 3. The H.245 session is available to the calling EP in 1 RTD </FONT>
<BR><FONT SIZE=2>> and to the</FONT>
<BR><FONT SIZE=2>> called EP in 0.5 RTDs--the same as media and Fast Connect!</FONT>
<BR><FONT SIZE=2>> 4. Without using Fast Connect, the calling EP can start </FONT>
<BR><FONT SIZE=2>> transmitting media</FONT>
<BR><FONT SIZE=2>> in one less RTD than it could without this new feature. Here are the</FONT>
<BR><FONT SIZE=2>> comparisons:</FONT>
<BR><FONT SIZE=2>> (Feature: calling EP RTDs, called EP RTDs)</FONT>
<BR><FONT SIZE=2>> Fast Connect w/ or w/o Expedite: 1, 0.5</FONT>
<BR><FONT SIZE=2>> Expedite w/o Fast Connect: 2, 2.5</FONT>
<BR><FONT SIZE=2>> Neither: 3, 2.5</FONT>
<BR><FONT SIZE=2>> 5. Perhaps this feature could benefit SIP-H.323 interworking </FONT>
<BR><FONT SIZE=2>> if H.245 with</FONT>
<BR><FONT SIZE=2>> full TCS and MSD is deemed too onerous, i.e., don't allow </FONT>
<BR><FONT SIZE=2>> "real" TCSs and</FONT>
<BR><FONT SIZE=2>> MSDs.</FONT>
<BR><FONT SIZE=2>> 6. Marginally less bandwidth consumption and quicker </FONT>
<BR><FONT SIZE=2>> transmission of initial</FONT>
<BR><FONT SIZE=2>> call-signaling messages (okay, I'm reaching... :-) ).</FONT>
<BR><FONT SIZE=2>> 7. This opens up other possibilities (maybe that's a </FONT>
<BR><FONT SIZE=2>> disadvantage :-) ).</FONT>
<BR><FONT SIZE=2>> That's why I defined H245TunnelingExpedition to be </FONT>
<BR><FONT SIZE=2>> extensible. For example,</FONT>
<BR><FONT SIZE=2>> we could indicate that all TCS and MSD requests will be </FONT>
<BR><FONT SIZE=2>> rejected, so don't</FONT>
<BR><FONT SIZE=2>> bother.</FONT>
<BR><FONT SIZE=2>> 8. Works well with others. :-) I mean that it naturally fits </FONT>
<BR><FONT SIZE=2>> in with Fast</FONT>
<BR><FONT SIZE=2>> Connect and H.245 Tunneling.</FONT>
<BR><FONT SIZE=2>> 9. Easy to understand. Okay, to me at least.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> This is not and may never be a formal contribution. Perhaps </FONT>
<BR><FONT SIZE=2>> just consider it</FONT>
<BR><FONT SIZE=2>> as food for thought.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Paul Long</FONT>
<BR><FONT SIZE=2>> Smith Micro Software, Inc.</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>