Req: Clarification on fast setup

[Jim Toga]

Pete,

My comments are interspersed below....

Regards,
jimt.

At 05:27 PM 9/23/97 +0100, you wrote:
>Jim,
>
>Looking at the fast start stuff, I'm confused about the format of the
>FastCap field and how it is used.  Is the intention to allow multiple
>multiplexCapbility fields in the SETUP?  How would this be used as H.245
>allows only one instance of the field?  Perhaps the encoding below would

Good point, your representation is marginally better.... although I think
simply stating that it is only relevant once per FastCap entry is enough.
I'm not sure that removing the OPTIONAL from Capabilty lends that much.

>describe the intended use better.
>
>FastCap ::= SEQUENCE
>{
>        caps            SEQUENCE OF Capability,
>        multiplexCap    multiplexCapability OPTIONAL,
>        ...
>}
>
>Setup-UUIE ::= SEQUENCE
>{
>        -- deleted fields
>        cryptoTokens            SEQUENCE OF CryptoH323Token OPTIONAL,
>        fastStart               SEQUENCE OF OpenLogicalChannel OPTIONAL,
>        fastCap         FastCap OPTIONAL,
>        canOverlapSend  BOOLEAN
>}
>
>Perhaps the semantics could describe this better if this is the case.
>
>I also have a few questions:
>
>In Glen's text it mentions that the OpenLogicalChannel parameters in the
>SETUP message indicate parameters to be used in the callee to caller
>direction, i.e. the reverse sense to an H.245 OpenLogicalChannel.  As
>the text in H.323 says that these are the parameters "that would
>normally be passed later in the H.245 OpenLogicalChannel" I'm wondering
>if the statement is correct.  If the sense truly is reversed, then this
>should be brought out more in the text in H.323.

The point is that 'normally' one shouldn't radically change their
capabilites from the FastStart mechanism to the regular H.245 cap exchange....

>
>Also, what I am not clear on is if a terminal can receive and transmit
>G.723 and G.729 how it should indicate this in the fast channel mode.

They would simply do this as with H.245 - by including a set of receive and
transmit caps that indicate G.723 and G.729.....?

>Negotiation is important for this as G.723 might be the safer bet, but
>G.729 might be better for delivery of in-band DTMF tones (or simply have
>lower delay).  Also, future codecs that are better tailored to the
>Internet may be developed, and you want to be able to use these as soon
>as possible.  Could you supply an example of this?

I'm really not sure what you're getting at here?  Any codepoints that are
defined in H.245 can be utilized (along with nonStandard...)

>
>How well do you see the scheme working when MCs are involved.  Is it the
>case that MCs will have to use slow start, or have I missed something?

In so far as MCs are callable entities which 'look like' endpoints it works
fine.  As soon as any multipoint operations are commenced, the expectation
at this point, is that H.245 is utilized.

>MCs won't be able to use communicationModeCommand so I guess they won't
>be able to instruct endpoints what to do in any forcible way.  Is this
>correct?  As we have much special text in H.323/H.225 on making MCs
>work, perhaps some text on how MCs and fast start interwork should be
>included.

The original intent of this mechanism was not to provide a seamless
solution in all situations - it was to provide a fast connection sequence
for pt-pt calls.

>
>Perhaps some annotated ladder diagrams would be useful.  I appreciate
>that you haven't had much time though.  As a question to the wider
>community (Dale!), would it be possible to add extra clarifying text of
>this nature in January if it was felt to be useful?
>
>Best regards,
>
>Pete
>=================================
>Pete Cordell
>BT Labs
>E-Mail: pete.cordell at bt-sys.bt.co.uk
>Tel: +44 1473 646436
>Fax: +44 1473 645499
>=================================
>
>

*************************************************************************
***  +1-503-264-8816(voice)             +1-503-264-3485(fax)          ***
***  jtoga at ibeam.intel.com              Intel - Hillsboro, OR.        ***
***  PGP keyID 36 07 86 49 7D 74 DF 57  50 CB BA 32 08 9C 7C 41***
*************************************************************************