Support bi-directional channels in annex C fast start

Roni Even roni_e at ACCORD.CO.IL
Fri Sep 8 05:49:09 EDT 2000


Paul,
I have no problem, but since was an offline messages I do not understand
what is not clear. I will prepapre a text for the next meeting but I cannot
be sure it will be enough.

Roni
----- Original Message -----
From: Paul E. Jones <paulej at PACKETIZER.COM>
To: <ITU-SG16 at MAILBAG.INTEL.COM>
Sent: éåí ùéùé 08 ñôèîáø 2000 07:47
Subject: Re: Support bi-directional channels in annex C fast start


> Roni,
>
> If everybody agrees that the text in Annex C is sufficient, then I can
live
> with leaving that text there.  However, as I pointed out below, at least
one
> company is confused about the procedure, so it must not be as clear to
> everybody.  (That particular message circulated around to a number of
people
> before they decided to send it to me.)
>
> What I would like to request is that you examine the Fast Connect section,
> noting that nothing is there for ATM-- that's fine: it rightfully belongs
in
> Annex C.  Then look at Annex C and make sure that all of descriptive text
is
> there to open a VC with Fast Connect.  Perhaps it does not take much
> explanation, but I believe we need something.
>
> We then need a contribution for the upcoming meeting.  Since this is
> clarifying text, I believe it can be brought to the Rapportuer's meeting.
>
> Paul
>
> ----- Original Message -----
> From: "Roni Even" <Roni_e at ACCORD.CO.IL>
> To: <ITU-SG16 at mailbag.cps.intel.com>
> Sent: Thursday, September 07, 2000 6:29 AM
> Subject: Re: Support bi-directional channels in annex C fast start
>
>
> > Paul,
> > I think that the original text was due to APC-1516 from 9902-Mon
submitted
> > by Francois Audet. Any how the current text explains that the
originating
> > side is responsible to open the bi-directional VC and signal it in the
OLC
> > of the fast connect. The procedure is there in annex C and I do not see
> what
> > extra text is needed. I think that we only need to allow this mode in
the
> > fast connect section. Bellow is the text from annex C - C.3.8.2
> >
> > If the bidirectional usage is indicated, the receiving endpoint shall
send
> > an openLogicalChannelAck
> > (or the openLogicalChannel in the case of Fast Connect) and then it must
> > watch for an ATM VC to
> > be opened by the other endpoint. When ATM VC is completed, it may then
use
> > the reverse direction
> > for the media type indicated in the openLogicalChannel command. The
> endpoint
> > that initiates the
> > openLogicalChannel command is the endpoint that shall open the ATM VC.
> >
> > Thanks
> > Roni Even
> > -----Original Message-----
> > From: Roni Even [mailto:Roni_e at ACCORD.CO.IL]
> > Sent: Tuesday, September 05, 2000 10:33 AM
> > To: ITU-SG16 at MAILBAG.INTEL.COM
> > Subject: Re: Support bi-directional channels in annex C fast start
> >
> >
> > Paul,
> > TD14 from 9902-MON clearly states that the change was done to support
fast
> > start. This is the implementer guide for version 2. I am including the
> text
> > as well as attaching the TD. I would think that the problem was not
> putting
> > the extra text in the fast start procedure.
> > IF it is not clear I can add some text to annex C
> > Thanks
> > Roni
> >
> > H.323 Annex C - Indication of ATM capabilities in TransportCapability
> > Description:    Annex C requires that the indication of ATM be indicated
> in
> > the Terminal Capability Set, but it implies that it is done in the
> > capability exchange procedures. While this is valid when fast start is
not
> > used, it is not when fast start procedures are used since they do not
use
> > the capability exchange procedures before setting up the channels. The
> > current wording unfortunately prohibits the use of fast start with Annex
> C.
> > This contribution proposes that the wording be amended to allow for this
> > indication to be provided in fast start as well. More specifically, the
> > current Annex mandates that the Terminal Capability set be used to
> indicate
> > the ATM capabilities. If fast start is used, the TransportCapability
> (where
> > the ATM information is included) is not included. It is however included
> in
> > the OpenLogicalChannel. Annex C shall be amended the text to reflect
this.
> > It shall also be clarified that OpenLogicalChannel is used instead of
> > OpenLogicalChannelAck when fast start is used..This change will be
> reflected
> > in H.323 v3.
> >
> > C.3.6   Transport Capabilities added to
> > TerminalCapabilityTransportCapability Set
> > For operation of H.323 on AAL5, an addition to the
> > TerminalCapabilityTransportCapability set is made in H.245. This
includes
> > transport level capabilities such as support for ATM Transfer Capability
> > (DBR, SBR1, SBR2, SBR3, ABT/DT, ABT/IT, ABR) as defined in
Recommendation
> > I.371. Terminals that do not send this new capability parameter shall
not
> > make use of the new methods described in this Annex. The
> TransportCapability
> > information can be sent as part of the Terminal Capability set exchange
in
> > the capability exchange phase. It is also included in the
> > OpenLogicalChannel.
> > ...
> > C.3.7.1 ATM address
> > The ATM address for an RTP stream shall be given in the mediaChannel
> > subfield of H2250LogicalChannelParameters of the H.245
> OpenLogicalChannelAck
> > message (or the OpenLogicalChannel in the case of fast start). The
> > mediaChannel subfield UnicastAddress or MulticastAddress shall be filled
> > with the 20-octet NSAP-style ATM End System Address.
> > ...
> > C.3.8.2 Bidirectional logical channels
> > If the bidirectional usage is indicated, the receiving endpoint shall
send
> > an OpenLogicalChannelAck (or the OpenLogicalChannel in the case of fast
> > start) and then it must watch for an ATM VC to be opened by the other
> > endpoint. When ATM VC is completed, it may then use the reverse
direction
> > for the media type indicated in the OpenLogicalChannel command. The
> endpoint
> > that initiates the OpenLogicalChannel command is the endpoint that shall
> > open the ATM VC.
> > ...
> >
> >
> > -----Original Message-----
> > From: Paul E. Jones [mailto:paulej at packetizer.com]
> > Sent: Tuesday, September 05, 2000 9:13 AM
> > To: Mailing list for parties associated with ITU-T Study Group 16;
> > Roni_e at ACCORD.CO.IL
> > Subject: Re: Support bi-directional channels in annex C fast start
> >
> >
> > Ron,
> >
> > Here are the facts that led to this:
> >   1) In H.323v3 (which is what the Implementers Guide is correcting), it
> is
> >      illegal to use a bi-directional channel with Fast Connect.
> >   2) Section C.3.8.2 and it's parent section C.3.8 were written with
> >      H.245 signaling in mind-- there was no thought of Fast Connect
> >      here.  The procedure is not defined.
> >
> > With H.323v4, Fast Connect was extended to include bi-directional TCP
> > channels, but nothing has been contributed for bi-directional ATM VCs.
To
> > simply say it is allowed opens a very large hole.
> >
> > I will quote the authors of the e-mail sent to me that prompted my
> proposed
> > correction.  Since it was sent privately, I will withhold their names.
It
> > states:
> >
> > [[ begin quote ]]
> >
> >   We believe that there is a conflict between Annex C and H.323 version
3
> >   WRT the Faststart and the method used to open logical channels. Annex
C
> >   talks about using B-directional OLCs and H.323 V3 claims that only
uni-
> >   directional OLCs are used during Faststart.
> >
> >   ...
> >
> >   Annex C in H.323v3 (C.3.8.2) still allows for bidirectional channels
in
> >   FastStart. It doesn't go into any details, but I can think of two
> >   possibilities:
> >
> >   - It either opens an exception and allows for the reverse channel to
be
> >     specified, or
> >   - It takes advantage of the fact that the *two* unidirectional
channels
> >     (forward and reverse) are sent in the same message and somehow
> > associates
> >     them as being the same SVC (using the SessionID and/or the
> mediaChannel
> >     value).
> >
> > [[ end quote ]]
> >
> > The author of that e-mail definitely pointed out a whole in the
> > specification.  Annex C references bi-directional channels used with
Fast
> > Connect, but that is explicitly illegal in V3.
> >
> > I am not at all opposed to re-inserting this text into H.323v4, but we
> > definitely need some clarifying text that explains how this shall be
used
> in
> > Annex C.  We cannot assume that the readers understand how it works.
> >
> > Would you be willing to draft text for Annex C to be included in the
> decided
> > document in November?
> >
> > Best Regards,
> > Paul
> >
> > ----- Original Message -----
> > From: "Roni Even" <Roni_e at ACCORD.CO.IL>
> > To: <ITU-SG16 at mailbag.cps.intel.com>
> > Sent: Sunday, September 03, 2000 6:03 AM
> > Subject: Support bi-directional channels in annex C fast start
> >
> >
> > > Hi,
> > > During the Portland meeting I had a concern about the change in H.323
V4
> > and
> > > Implementers guide described in APC 1875a item 17 that was added by
the
> > > editor. This change was also added by the editor to the white draft of
> > H.323
> > > V4. The editor pointed out that there is a contradiction between the
> text
> > in
> > > Annex C in paragraph C.3.8.2 and fast start in 8.1.71. concerning the
> use
> > of
> > > bi-directional channels.
> > > I looked at the subject and my suggestion is to keep the text in annex
C
> > and
> > > add to the end of the  first paragraph of 8.1.7.1 "or one
bi-directional
> > > channel logical channel as described in annex C"
> > > Thanks
> > > Roni Even
> > >
> > > ********************************
> > > Roni Even
> > > VP Product Planning
> > > Accord Networks
> > > Phone: +972-3-9251200
> > > Fax: +972-3-9211571
> > > email: roni_e at accord.co.il
> > >
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > 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