Uploaded Contributions

[Chip Sharp]

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 at AVAYA.COM>
To: <ITU-SG16 at 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 at 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 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
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 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