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@LUCENT.COM To: ITU-SG16@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@avaya.com +1 303 538 3868

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

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

Paul- In trying to think about ways to avoid adding the earlyH245 element to SETUP, I overlooked the fact that it could be used just as well to initiate the Fast Open procedures in a way that was backward compatible. That would permit us to offer both Fast Connect and Fast Open - the called endpoint could accept either one (or would see only the fastStart if it were an older endpoint). The advantage of Fast Open in this case would arise from it's use later on in the call (e.g., to switch to FAX or to redirect audio). -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