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