On TD26 - Fast TCS and M/S negotiation in H.323v4

[Bob Gilman]

Paul-
Your request (below) is a good one, and I will try to give a little
history (as I saw it).  Anyone please correct me if I get it
wrong or leave something out.

Several considerations by several people (François, Jill Caugherty,
myself, and others before us) led up to this question:
1. H.245 takes a considerable number of sequential messages to
   accomplish the reconfiguration or replacement of a media path.
   This especially true in the Gatekeeper-routed model.  Fast Connect
   avoids this overhead initially, but delays the establishment of
   the H.245 channel for later use.
2. It is desirable to negotiate, or be aware of, FAX capability
   early on without opening a FAX channel.
3. It is desirable to negotiate end-to-end digit handling (or other
   capabilities) prior to opening an H.245 channel, i.e., in the
   presence of fastStart.  It's also desirable to get the startup
   overhead (TCS exchange and M/S negotiation) of H.245 out of the
   way early.
4. FastStart provides a means of passing some (but not all) capabilities
   from the caller to the called endpoint, but it cannot convey the
   equivalent information in the reverse direction.  (The reverse
   information implies establishment of the corresponding channel.)

I had been working on a proposal for repeated fastStart for any end-
point (not just Annex F) that was intended to allow either party to
reconfigure channels.  My scheme used a null-data OLC from the caller
in addition to the normal fastStart offer(s) to indicate that the
caller is willing to do repeated fastStart.  The called party could
then accept fastStart (by returning standard OLCs), and indicate
repeated fastStart by returning the null-data OLC, then offer additional
OLCs with capabilties that could be used later.  François suggested that
the sending of the TCS in the H.245 tunnel in parallel with the fastStart
would be an alternate (and more efficient) way to exchange the caps
(and would have the advantages of getting the overhead of starting
H.245 out of the way).  We documented both ideas in APC-1823 in Osaka.
The idea of repeated fastStart (except for Annex F) met with disfavor
in Osaka (and before - Dave Walker and Pete Cordell pointed out their
earlier contributions with regard to improving H.245 performance APC-1522
and APC-1524).  The idea of overlapping capset exchange and M/S
negotiation with fastStart was adopted, however, as described in TD-26.
This was seen as a less-radical change, but has clearly met with some
resistance due to backward (in)compatibility.  As a result, we seem to
have solved nothing.
I'd like to go back to the original efforts to see what could be done.
It seems that the key to the problem is how to say "we want to do some-
thing new" in a way that is backward compatible with earlier versions.
I had proposed to do this with a "null OLC" (dataType = nullData) in
order that no ASN.1 changes were required.  Jill's contribution suggested
an extension of the DataType to permit the choice of UserInputCapability.
This, or any new capabilty (e.g., "repeatedFastStart" [my personal
favorite], or "terminalCapabilitySet" [François' favorite]) could be added
to the dataType and could then be sent in OLCs with multiplexParameters
= none in a fastStart element.  This should be backward compatible since
the OLCs would be well-formed.  (I will note that this places us in the
interesting position of defining elements in H.245 to be used when we're
not doing H.245.  It's like an American defining a new French word so
it can be incorporated into English.)  The terminalCapabilitySet option
would be very powerful: it could include user capabilities and
maxPendingReplacementFor as well as media capabilities, and it avoids the
problem I tried to solve by separating OLCs into "acceptances" and
"offers" (via placement of the null OLC).
If the called endpoint does not support (or does not recognize) a new
capability, it will not reply with a matching OLC (it can reply with
matching media OLCs to accept standard fastStart); if it does accept a
capability it can reply with the appropriate matching OLC (e.g., one
containing its own capabilty set).  As with standard fastStart, if the
called endpoint does not accept a capability, the originator should
not use it.  I should note that some capabilities such as DTMF digits
We could, of course, extend the OLC forwardLogicalChannel dataType to
include masterSlaveDetermination and masterSlaveDeterminationAck or some
such.  (It would be nice to define the procedures such that the called
party always broke ties, so that the procedure always succeeded.)
But look what this leads to: we're building H.245 into the fastStart
element.  And why would we want to do this?  I claim that the real
incentive is the same as it has always been for fastStart: we want to
speed things up.  FastConnect (which, I understand, we agreed in Osaka
to call FastStart) has the advantage of a single-exchange sequence:
endpoint A proposes and endpoint B accepts.  Both media directions
are handled in parallel, and either endpoint can insure that both
codecs are the same, if they wish.  H.245 procedures have, I believe,
the distinct speed disadvantage of requiring the source end to initiate
and close a logical channel, which then requires the other end (or a
gatekeeper) to request that a channel be opened or closed.  (BTW, the
RequestMode message to do this is not entirely satisfactory since it
can specify a "mode" [e.g., G.729], but not a capability [e.g., G.729
with 2 frames - unless you pick g729AnnexB or a later addition - there
seems to be an inconsistency in the extensions to AudioMode!)  The trick,
I guess, is to update the TCS to include only the exact thing(s) you want
to do now, then hit the endpoint with the RequestMode.  Some of this was
discussed in TD-33a from Osaka.
Anyway, Paul, this has become way too long (no pun intended), so I better
stop.  I hope this helps.
-Bob
----------------------------------------------------
Bob Gilman       rrg at lucent.com      +1 303 538 3868

Paul Long wrote:
>
> Paul,
>
> Unfortunately, I wasn't in Osaka. Would it be asking too much to ask what
> problem this was supposed to fix? Maybe we can come up with a fix that won't
> break something else. That would be the ideal solution.
>
> Paul

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