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@bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================

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