fastStart element in all Q.931 messages up to and including Connect
Paul E. Jones
paulej at PACKETIZER.COM
Thu Nov 2 02:07:56 EST 2000
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 at AVAYA.COM>
To: <ITU-SG16 at 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 at 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 at mailbag.intel.com
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com
More information about the sg16-avd
mailing list