Support bi-directional channels in annex C fast start

[Roni Even]

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