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:
>
> 1. 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 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@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
>