Expediting H.245

Paul Long Plong at SMITHMICRO.COM
Wed Jul 26 10:59:50 EDT 2000


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



More information about the sg16-avd mailing list