<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: Expediting H.245</TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4134.600" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Francois, Paul, et al,</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Well, there were some changes, but publicly 
discussed here-- not strictly my editorial changes :-).  Essentially, the 
same functionality is achieved as described in TD-26a, but with a new field 
"earlyH245Control" in the Setup message, rather than the "h245Control" in the 
H323-UU-PDU.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>The procedure has been dubbed "Early H.245" and is 
described in section 8.2.3/H.323v4.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Paul</FONT></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
  <A title=audet@NORTELNETWORKS.COM 
  href="mailto:audet@NORTELNETWORKS.COM">Francois Audet</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A 
  title=ITU-SG16@mailbag.cps.intel.com 
  href="mailto:ITU-SG16@mailbag.cps.intel.com">ITU-SG16@mailbag.cps.intel.com</A> 
  </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Wednesday, July 26, 2000 1:52 
  PM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> Re: Expediting H.245</DIV>
  <DIV><BR></DIV>
  <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: <A 
  href="mailto:ITU-SG16@MAILBAG.INTEL.COM">ITU-SG16@MAILBAG.INTEL.COM</A></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></BLOCKQUOTE></BODY></HTML>