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