fastStart element in all Q.931 messages up to and including C onnect

[Danail Kirov]

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 at 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 at 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 at nortelnetworks.com>  Audet 
To: 'Anatoli <mailto:alevine at RADVISION.COM>  Levine' 
Cc: h323implementors at imtc.org <mailto:h323implementors at 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. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20001031/ded7a418/attachment-0004.html>