Support bi-directional channels in annex C fast start

[Paul E. Jones]

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