Expediting H.245
Paul E. Jones
paulej at PACKETIZER.COM
Thu Jul 27 03:32:37 EDT 2000
Bob,
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?
Paul
----- 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
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
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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