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@avaya.com +1 303 538 3868
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com