fastStart element in all Q.931 messages up to andincludingConnect

Bob Gilman rrg at AVAYA.COM
Fri Nov 3 15:02:25 EST 2000


Paul-
Here's the text from Annex F.  As you can see, the "null" fastStart
closes the channel:
7.3.4 Logical Channel Signaling Messages
The opening of logical channels shall adhere to the FastConnect specifications
of H.323 version 2.  In addition, SET devices shall support reconfiguration of
media streams at any time during a call . Open Logical Channel structures shall
be tunneled in H.225.0 call signaling messages following the procedures defined
in H.225.0 version 2 (1998) and H.323 version 2 (1998) re-using the fastStart
element of the H.225.0 call signaling message.  Open Logical Channel structures
outside the FastConnect procedure shall be used to alter media stream parameters
- to provide a basis for supplementary services.  Such Open Logical Channel
structures shall be interpreted upon reception as follows.
· If the logical channel number matches a currently open logical channel,
the respective channel shall be reconfigured following the principles of
the FastConnect procedure if the dataType component is not "null".  If the
dataType component is "null" - indicating a "NullChannel" - the respective
logical channel shall be considered closed and media transmission on this
logical channel shall cease.
· If the logical channel number does not match a currently open channel, a
new logical channel shall be opened following the princicples of the
FastConnect procedure.

I suppose the rule would be: if you're not a SET, ignore; if you are, react.

(As you know, I'd like to see every endpoint process the subsequent messages
- then the SET wouldn't be so special, and the redirection problem would be
solved.)

-Bob
----------------------------------------------------
Bob Gilman       rrg at avaya.com      +1 303 538 3868


"Paul E. Jones" wrote:
>
> 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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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