Expediting H.245

[Bob Gilman]

Paul, Bob, and François-
As you recall, TD-26 met some opposition following Osaka
due to the existing restriction against placing both
fastStart and h245Control fields in the SETUP message.
Paul Jones had suggested a new field (earlyH245) in the
Setup-UUIE to get around this, along with a change to
specify that use of the h245 fields did not terminate
Fast Connect.  In thinking about this (and considering
Pete Cordell's comments), I took a look at what amounts
to moving Fast Connect into the H.245 tunnel.  This
turns out to be as fast as Fast Connect, and it allows
some "compaction" that may be an advantage as well.
What if we add the following new H.245 messages:
a new RequestMessage

        FastOpenChannel         ::= SEQUENCE
        {
                offeredCaps             AlternativeCapabilitySet,
                channelProposal         OpenLogicalChannel,
                                        -- with dataType set to nullData
                ...
        }

a new ResponseMessage

        FastOpenChannelAck      ::= SEQUENCE    -- a response
        {
                channelAccept           OpenLogicalChannel,
                                        -- dataType set to selected capability
                ...
        }

and, for completeness, an additional ResponseMessage

        FastOpenChannelReject   ::= SEQUENCE    -- a response
        {
                reason          OpenLogicalChannelReject,
                ...
        }

A caller would send MSDetermination, TCS, and FastOpenChannel in the initial
SETUP using the h245Control.  The callee would respond with MSDAck, TCS, and
a FastOpenChannelAck to establish the channel.  Since this is all H.245, the
FastOpenChannelAck could be sent in a later message.  Note, however, that the
FastOpenChannel must be preceeded by a TCS because the AlternativeCapabilitySet
is a list of CapabilityTable entry numbers.  Once the TCS exhange and M/S
determination is complete, the FastOpen procedures could be used at any time.
We would need to add a couple of cause codepoints to the
OpenLogicalChannelReject
message to cover cases like "unknown capability" or "empty capability set".
Channels opened via Fast Open would be closed by CloseLogicalChannel requests,
or via use of the replacementFor elements in OLCs or OLCAs.

We would manipulate the OLCs in these messages as is done for Fast Connect
(the forward channel goes from the proposer to the acceptor).  The "compaction"
comes from adding the offeredCaps AlternativeCapabilitySet, so that one OLC
can serve for all the alternative capabilities for a particular session.  This
avoids the packet-size proliferation problem and transport address redundancies
of Fast Connect.

This change is backward compatible in that the new messages should be ignored
when
sent to an older version callee.   The Fast Open caller would know that the
FastOpenChannel was ignored when receiving back the first H.245 message from the
callee.  Similarly, a new version callee would know the caller version upon
receiving the first H.245 message (or a fastStart element).

One other addition to H.245 I believe would be useful is to specify that the
Master/Slave negotiation always be resolved by an endpoint if that endpoint
has not initiated a negotiation (i.e., has not announced a statusDetermination
Number).  In particular, let the receiving terminal declare itself the master
(or the slave) if there's a tie, or let it roll a new random number until it
decides.  That way, we don't get hung up retrying the M/S negotiation.

In summary, the advantages of this scheme maintain the benefits of TD-26a from
Osaka, and improve over Fast Connect as well:
1. fast connection negotiation in one round trip, same as Fast Connect;
2. complete capability exchange (distinguishes future capabilities from
immediate
   requests), better than Fast Connect;
3. backward compatible with earlier versions (the penalty is that a Fast Open
caller
   cannot do Fast Connect - but a Fast Open callee can), avoids TD-26 proplem
with
   simultaneous Fast Connect and H.245;
4. very little change to H.245 ASN.1 - three new messages.

What do you all think?
-Bob
----------------------------------------------------
Bob Gilman       rrg at avaya.com      +1 303 538 3868

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com