[H.323 Mobility:] Usage of H.225 Annex G in H.323 Annex H & a question about BEs
jaakko.sundquist at NOKIA.COM
Thu Jul 27 03:56:25 EDT 2000
This looks quite reasonable to me.
I may have missed it in here, but do you say anything about including both
fastStart and these new fields. Proponents of TD-26 wanted to ensure that
the devices could still take advantage of Fast Connect for those devices
that support the procedure.
However, I'm not sure that I understand exactly what the advantage is over
the combined usage of the existing Fast Connect procedure + Early H.245.
Can you clarify that for me?
----- Original Message -----
From: "Bob Gilman" <rrg at LUCENT.COM>
To: <ITU-SG16 at mailbag.cps.intel.com>
Sent: Wednesday, July 26, 2000 4:47 PM
Subject: Re: Expediting H.245
> 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
> and, for completeness, an additional ResponseMessage
> FastOpenChannelReject ::= SEQUENCE -- a response
> reason OpenLogicalChannelReject,
> A caller would send MSDetermination, TCS, and FastOpenChannel in the
> SETUP using the h245Control. The callee would respond with MSDAck, TCS,
> a FastOpenChannelAck to establish the channel. Since this is all H.245,
> FastOpenChannelAck could be sent in a later message. Note, however, that
> FastOpenChannel must be preceeded by a TCS because the
> 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
> We would need to add a couple of cause codepoints to the
> message to cover cases like "unknown capability" or "empty capability
> Channels opened via Fast Open would be closed by CloseLogicalChannel
> 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
> comes from adding the offeredCaps AlternativeCapabilitySet, so that one
> can serve for all the alternative capabilities for a particular session.
> avoids the packet-size proliferation problem and transport address
> of Fast Connect.
> This change is backward compatible in that the new messages should be
> sent to an older version callee. The Fast Open caller would know that
> FastOpenChannel was ignored when receiving back the first H.245 message
> callee. Similarly, a new version callee would know the caller version
> 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
> Master/Slave negotiation always be resolved by an endpoint if that
> has not initiated a negotiation (i.e., has not announced a
> Number). In particular, let the receiving terminal declare itself the
> (or the slave) if there's a tie, or let it roll a new random number until
> 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
> 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
> requests), better than Fast Connect;
> 3. backward compatible with earlier versions (the penalty is that a Fast
> cannot do Fast Connect - but a Fast Open callee can), avoids TD-26
> simultaneous Fast Connect and H.245;
> 4. very little change to H.245 ASN.1 - three new messages.
> What do you all think?
> 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
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