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@mailbag.intel.com