Expediting H.245

Paul E. Jones paulej at PACKETIZER.COM
Thu Jul 27 03:27:10 EDT 2000


RE: Expediting H.245Francois, Paul, et al,

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.

The procedure has been dubbed "Early H.245" and is described in section 8.2.3/H.323v4.

Paul
  ----- Original Message ----- 
  From: Francois Audet 
  To: ITU-SG16 at mailbag.cps.intel.com 
  Sent: Wednesday, July 26, 2000 1:52 PM
  Subject: Re: Expediting H.245


  Actually, I believe the editor (correct me if I'm wrong Paul Jones) did some 
  editorial (I love this word) changes from what was in TD-26a. So Paul Long should 
  really look at the latest and greatest H.323v4. 

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000727/258fa7c0/attachment-0004.html>


More information about the sg16-avd mailing list