It is illegal to change fastStart mid-stream. Period. Finito. We can't change that. It would break some existing implementations. So look at the first one and ignore the others.
(That being said, it would have been useful to allow for making a call to a hunt group, and in-band ringing would be provided until a real person could respond).
-----Original Message----- From: van Schelven, Richard [mailto:Richard.VanSchelven@MARCONI.COM] Sent: Thursday, November 02, 2000 1:57 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: fastStart element in all Q.931 messages up to and including C onnect
Can anybody enlighten me:
- Why would an endpoint change fastStart elements in mid
stream? How would you implement that in real life. 2. Why are things so complicated? Why not have a fastStart element in a Setup and Connect only. All the other things are complicating matters and IMHO unnecessarily.
Faststart is suppose to be fast, clean (simple) and crisp solution.
Ries van Schelven Principal Engineer Marconi 100 Upper Georges Street Dun Laoghaire Co. Dublin Ireland
-----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Thursday, November 02, 2000 7:08 AM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: fastStart element in all Q.931 messages up to and including Connect
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 messagesup to and including
C onnect
Change the should to a shall then: The called endpoint accepts a proposed channelby 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, theydeserve to be taken
out of business.
I completely disagree with your assertion that wemust 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
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com