Re: fastStart element in all Q.931 messages up to and including C onnect
RE: fastStart element in all Q.931 messages up to and including ConnectFrancois,
Noted... I'll add that to my list of corrections for H.323v4 unless somebody screams loudly. This should also be inserted into the Implementers Guide, too, I suppose.
Paul
----- Original Message ----- From: Francois Audet To: h323implementors Sent: Tuesday, October 31, 2000 1:32 PM Subject: RE: fastStart element in all Q.931 messages up to and including C onnect
Change the should to a shall then: 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 shall react to the first fastStart element received in a response message to the Setup message and ignore any eventual subsequent fastStart elements. If somebody manages to get it wrong after that, they deserve to be taken out of business.
I completely disagree with your assertion that we must choose either one or many. Currently some implementations send one, others send many, and we don't see interoperability problems.
-----Original Message----- From: Danail Kirov [mailto:DanailK@vertical.com] Sent: Tuesday, October 31, 2000 10:17 AM To: Audet, Francois [SC2:4K02:EXCH]; 'Paul E. Jones'; 'Anatoli Levine'; Paul Long Cc: h323implementors Subject: RE: fastStart element in all Q.931 messages up to and including C onnect
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 Audet
To: 'Anatoli Levine'
Cc: 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.
Francois and Paul - I agree with François' change to "shall react to the first fastStart element", but I would suggest that "ignore" be replaced by "may ignore" for any subsequent fastStart elements. (If a called endpoint changes fastStart elements in mid-stream, then it's the caller's choice whether it reacts or not.) BTW, doesn't this overlap with the redirection problem in which we perhaps should say that the called endpoint "shall" react to any subsequent [different] fastStart element? -Bob ---------------------------------------------------- Bob Gilman rrg@avaya.com +1 303 538 3868
----- Original Message ----- From: Francois Audet To: h323implementors Sent: Tuesday, October 31, 2000 1:32 PM Subject: RE: fastStart element in all Q.931 messages up to and including C onnect
Change the should to a shall then:
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 shall react to the first fastStart element received in a response message to the Setup message and ignore any eventual subsequent fastStart elements.
If somebody manages to get it wrong after that, they deserve to be taken out of business.
I completely disagree with your assertion that we must choose either one or many. Currently some implementations send one, others send many, and we don't see interoperability problems.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Bob,
This opens a whole can of worms. Essentially, I can't agree that fastStart may be modified and re-transmitted. The calling endpoint may have freed resources and certainly may not be prepared to accept the newly modified proposals.
Paul
----- Original Message ----- From: "Bob Gilman" rrg@AVAYA.COM To: ITU-SG16@mailbag.cps.intel.com Sent: Wednesday, November 01, 2000 12:03 PM Subject: Re: fastStart element in all Q.931 messages up to and including Connect
Francois and Paul - I agree with François' change to "shall react to the first fastStart element", but I would suggest that "ignore" be replaced by "may ignore" for any subsequent fastStart elements. (If a called endpoint changes fastStart elements in mid-stream, then it's the caller's choice whether it reacts or not.) BTW, doesn't this overlap with the redirection problem in which we perhaps should say that the called endpoint "shall" react to any subsequent [different] fastStart element?
-Bob
Bob Gilman rrg@avaya.com +1 303 538 3868
----- Original Message ----- From: Francois Audet To: h323implementors Sent: Tuesday, October 31, 2000 1:32 PM Subject: RE: fastStart element in all Q.931 messages up to and
including
C onnect
Change the should to a shall then: 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 shall react to the
first
fastStart element received in a response message to the Setup message and ignore any eventual subsequent
fastStart
elements.
If somebody manages to get it wrong after that, they deserve to be
taken
out of business.
I completely disagree with your assertion that we must choose
either one
or many. Currently some implementations send one, others send many, and we don't see interoperability problems.
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Paul- I see your point - that's why I suggested "may ignore" - but in thinking more about it, that sort of uncertainty ("will he or won't he react to the modified fastStart?") is not good at all. BTW, are SETs an exception to François' rule? Maybe we need to require reaction to each fastStart (unless it's the same as an earlier one). Now that ought to keep us busy! -Bob ---------------------------------------------------- Bob Gilman rrg@avaya.com +1 303 538 3868
"Paul E. Jones" wrote:
Bob,
This opens a whole can of worms. Essentially, I can't agree that fastStart may be modified and re-transmitted. The calling endpoint may have freed resources and certainly may not be prepared to accept the newly modified proposals.
Paul
----- Original Message ----- From: "Bob Gilman" rrg@AVAYA.COM To: ITU-SG16@mailbag.cps.intel.com Sent: Wednesday, November 01, 2000 12:03 PM Subject: Re: fastStart element in all Q.931 messages up to and including Connect
Francois and Paul - I agree with François' change to "shall react to the first fastStart element", but I would suggest that "ignore" be replaced by "may ignore" for any subsequent fastStart elements. (If a called endpoint changes fastStart elements in mid-stream, then it's the caller's choice whether it reacts or not.) BTW, doesn't this overlap with the redirection problem in which we perhaps should say that the called endpoint "shall" react to any subsequent [different] fastStart element?
-Bob
Bob Gilman rrg@avaya.com +1 303 538 3868
----- Original Message ----- From: Francois Audet To: h323implementors Sent: Tuesday, October 31, 2000 1:32 PM Subject: RE: fastStart element in all Q.931 messages up to andincluding
C onnect
Change the should to a shall then: The called endpoint accepts a proposed channel by returningthe
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 shall react to the
first
fastStart element received in a response message to the Setup message and ignore any eventual subsequent
fastStart
elements.
If somebody manages to get it wrong after that, they deserve to betaken
out of business.
I completely disagree with your assertion that we must chooseeither one
or many. Currently some implementations send one, others send many, and we don't see interoperability problems.
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.comFor help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Bob,
To be honest, I'm not sure-- I'd have to go read the text.
If I recall correctly, a SET device may receive multiple (and different) fastStart elements, but I was also thinking that a "NullChannel" specification had to be sent first, which essentially closes the logical channel before re-opening it.
Paul
----- Original Message ----- From: "Bob Gilman" rrg@AVAYA.COM To: ITU-SG16@mailbag.cps.intel.com Sent: Thursday, November 02, 2000 11:15 PM Subject: Re: fastStart element in all Q.931 messages up to and includingConnect
Paul- I see your point - that's why I suggested "may ignore" - but in thinking more about it, that sort of uncertainty ("will he or won't he react to the modified fastStart?") is not good at all. BTW, are SETs an exception to François' rule? Maybe we need to require reaction to each fastStart
(unless
it's the same as an earlier one). Now that ought to keep us busy!
-Bob
Bob Gilman rrg@avaya.com +1 303 538 3868
"Paul E. Jones" wrote:
Bob,
This opens a whole can of worms. Essentially, I can't agree that
fastStart
may be modified and re-transmitted. The calling endpoint may have freed resources and certainly may not be prepared to accept the newly modified proposals.
Paul
----- Original Message ----- From: "Bob Gilman" rrg@AVAYA.COM To: ITU-SG16@mailbag.cps.intel.com Sent: Wednesday, November 01, 2000 12:03 PM Subject: Re: fastStart element in all Q.931 messages up to and including Connect
Francois and Paul - I agree with François' change to "shall react to the first fastStart element", but I would suggest that "ignore" be replaced by "may ignore" for any subsequent fastStart elements. (If a called endpoint changes fastStart elements in mid-stream, then it's the caller's choice whether it reacts or not.) BTW, doesn't this overlap with the redirection problem in which we perhaps should say that the called endpoint "shall" react to any subsequent [different] fastStart element?
-Bob
Bob Gilman rrg@avaya.com +1 303 538 3868
----- Original Message ----- From: Francois Audet To: h323implementors Sent: Tuesday, October 31, 2000 1:32 PM Subject: RE: fastStart element in all Q.931 messages up to andincluding
C onnect
Change the should to a shall then: 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 shall react to
the
first
fastStart element received in a response message to the Setup message and ignore any eventual subsequent
fastStart
elements.
If somebody manages to get it wrong after that, they deserve to
be
taken
out of business.
I completely disagree with your assertion that we must chooseeither one
or many. Currently some implementations send one, others send many, and we don't see interoperability problems.
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.comFor help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.comFor help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Paul- Here's the text from Annex F. As you can see, the "null" fastStart closes the channel: 7.3.4 Logical Channel Signaling Messages The opening of logical channels shall adhere to the FastConnect specifications of H.323 version 2. In addition, SET devices shall support reconfiguration of media streams at any time during a call . Open Logical Channel structures shall be tunneled in H.225.0 call signaling messages following the procedures defined in H.225.0 version 2 (1998) and H.323 version 2 (1998) re-using the fastStart element of the H.225.0 call signaling message. Open Logical Channel structures outside the FastConnect procedure shall be used to alter media stream parameters - to provide a basis for supplementary services. Such Open Logical Channel structures shall be interpreted upon reception as follows. · If the logical channel number matches a currently open logical channel, the respective channel shall be reconfigured following the principles of the FastConnect procedure if the dataType component is not "null". If the dataType component is "null" - indicating a "NullChannel" - the respective logical channel shall be considered closed and media transmission on this logical channel shall cease. · If the logical channel number does not match a currently open channel, a new logical channel shall be opened following the princicples of the FastConnect procedure.
I suppose the rule would be: if you're not a SET, ignore; if you are, react.
(As you know, I'd like to see every endpoint process the subsequent messages - then the SET wouldn't be so special, and the redirection problem would be solved.)
-Bob ---------------------------------------------------- Bob Gilman rrg@avaya.com +1 303 538 3868
"Paul E. Jones" wrote:
Bob,
To be honest, I'm not sure-- I'd have to go read the text.
If I recall correctly, a SET device may receive multiple (and different) fastStart elements, but I was also thinking that a "NullChannel" specification had to be sent first, which essentially closes the logical channel before re-opening it.
Paul
----- Original Message ----- From: "Bob Gilman" rrg@AVAYA.COM To: ITU-SG16@mailbag.cps.intel.com Sent: Thursday, November 02, 2000 11:15 PM Subject: Re: fastStart element in all Q.931 messages up to and includingConnect
Paul- I see your point - that's why I suggested "may ignore" - but in thinking more about it, that sort of uncertainty ("will he or won't he react to the modified fastStart?") is not good at all. BTW, are SETs an exception to François' rule? Maybe we need to require reaction to each fastStart
(unless
it's the same as an earlier one). Now that ought to keep us busy!
-Bob
Bob Gilman rrg@avaya.com +1 303 538 3868
"Paul E. Jones" wrote:
Bob,
This opens a whole can of worms. Essentially, I can't agree that
fastStart
may be modified and re-transmitted. The calling endpoint may have freed resources and certainly may not be prepared to accept the newly modified proposals.
Paul
----- Original Message ----- From: "Bob Gilman" rrg@AVAYA.COM To: ITU-SG16@mailbag.cps.intel.com Sent: Wednesday, November 01, 2000 12:03 PM Subject: Re: fastStart element in all Q.931 messages up to and including Connect
Francois and Paul - I agree with François' change to "shall react to the first fastStart element", but I would suggest that "ignore" be replaced by "may ignore" for any subsequent fastStart elements. (If a called endpoint changes fastStart elements in mid-stream, then it's the caller's choice whether it reacts or not.) BTW, doesn't this overlap with the redirection problem in which we perhaps should say that the called endpoint "shall" react to any subsequent [different] fastStart element?
-Bob
Bob Gilman rrg@avaya.com +1 303 538 3868
----- Original Message ----- From: Francois Audet To: h323implementors Sent: Tuesday, October 31, 2000 1:32 PM Subject: RE: fastStart element in all Q.931 messages up to andincluding
C onnect
Change the should to a shall then: The called endpoint accepts a proposed channel byreturning
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 shall react to
the
first
fastStart element received in a response message to the Setup message and ignore any eventual subsequent
fastStart
elements.
If somebody manages to get it wrong after that, they deserve tobe
taken
out of business.
I completely disagree with your assertion that we must chooseeither one
or many. Currently some implementations send one, others send many, and we don't see interoperability problems.
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.comFor help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.comFor help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.comFor help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Bob,
[snip Annex F section ]
OK.. it seemed pretty clear that fastStart could be sent multiple times to reconfigure the streams.
I suppose the rule would be: if you're not a SET, ignore; if you are,
react.
(As you know, I'd like to see every endpoint process the subsequent
messages
- then the SET wouldn't be so special, and the redirection problem would
be
solved.)
This might be ideal, but we can't even seem to come to an agreement on whether a single reply is required or multiple replies are required for fastStart. Worse, I believe people have implemented it differently, which makes the situation even more difficult.
(I assume you have been observing the "debate" on the H.323 Implementers list.)
Now, what was this about Fast Open again? :-)
Paul
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (2)
-
Bob Gilman -
Paul E. Jones