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?
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 -----
To: 'Anatoli
Levine'
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.