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