It seems bullet-prone to me. If the called endpoint may choose to repeat the exact same fastStart element in all subsequent message up to and including Connect, then The calling endpoint may choose to expect the fastStart in Connect only. At the same time the called endpoint is not required to send fastStart in Connect and may choose not to send fastStart in Connect and as a result the calling endpoint may never get fastStart in Connect and fast connect may fail miserably.

Isn't it clear that those are two mutually exclusive choices? 1. The called endpoint is required to include the fastStart element in only one Q.931 message. 2. The called endpoint is required to repeat the exact same fastStart element in all subsequent message up to and including Connect.

There is no middle ground and no mix and matches are allowed, if we want to have bulletproof fast connect procedure. Any correction in the standard must make it clear and definite that it is either choice 1, or choice 2, but not both at the same time.

Danail Kirov

-----Original Message----- From: Francois Audet [mailto:audet@nortelnetworks.com] Sent: Tuesday, October 31, 2000 8:47 AM To: 'Paul E. Jones'; 'Anatoli Levine'; Paul Long Cc: h323implementors Subject: RE: fastStart element in all Q.931 messages up to and including C onnect

I have not problem with your proposed addition.

It seems bullet-proof to me. -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Monday, October 30, 2000 10:34 PM To: Audet, Francois [SC2:4K02:EXCH]; 'Anatoli Levine'; Paul Long Cc: h323implementors Subject: Re: fastStart element in all Q.931 messages up to and including C onnect Francois,

You proposed the following textual changes (see enclosed in <NEW></NEW>):

_____

The called endpoint accepts a proposed channel by returning the corresponding OpenLogicalChannel structure in a Q.931 message sent in response to Setup, up to and including Connect. <NEW>A called endpoint may choose to repeat the exact same fastStart element in all subsequent message up to and including Connect. Calling endpoints should react to the first fastStart element received in a response message to the Setup message and ignore any eventual subsequent fastStart elements.</NEW> _____

I don't have any problem inserting this text into H.323, but I do fear that people will rely on such repetitions and they may not happen. Indeed, I would state that an H.323 entity shall not expect more than one response to Fast Connect. I don't disagree with this text, because I always encourage developers to be very tolerant of "noise" on the wire-- and I consider repetitive data like this to be "noise". :-)

You call these religious arguments... they might be, but we really need closure on this issue. Unlike the MGCP vs H.248 debates, the world can live with two media gateway control protocols. However, I don't want to see vendors split on implementation issues relating to H.323: that's not good for anybody at all. If we don't come to an agreement on it here and now, you know that we'll be correcting it as a customer fumes over interoperability issues later on. I'd much rather see us agree to something than to bring grief upon our customers.

Can everyone live with the above textual changes? Do we need more? Is it well understood that there may be one and only one response containing fastStart?

Paul

----- Original Message -----

From: Francois mailto:audet@nortelnetworks.com Audet To: 'Anatoli mailto:alevine@RADVISION.COM Levine' Cc: h323implementors@imtc.org mailto:h323implementors@imtc.org Sent: Monday, October 30, 2000 5:51 PM Subject: RE: fastStart element in all Q.931 messages up to and including C onnect

I disagree with your claim that the stack which sends multiple Fast Start responses (as long as they are identical) is not compliant with the standard - none of the citations you used claim that ONLY ONE Q.931 message can carry Fast Start information. I believe that the wording should be changed to explicitly allow Fast Start elements to be sent in every Q.931 message up to Connect as long as information in those messages stays the same.

Correct. That was my proposal too. I didn't keep the exact wording I had. Paul Jones probably still has it. These religious arguments over "one" or "many" are getting nowhere. It seems that sending one and sending many are a fait accomplit. Not much we can do about it except tell the implementor about it.