APC 2009 uploaded

Espen Skjæran (ETO) Espen.Skjaeran at ETO.ERICSSON.SE
Thu Nov 2 10:35:07 EST 2000


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 at PACKETIZER.COM]
> Sent: Thursday, November 02, 2000 7:08 AM
> To: ITU-SG16 at 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 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



More information about the sg16-avd mailing list