Support bi-directional channels in annex C fast start

Roni Even Roni_e at ACCORD.CO.IL
Tue Sep 5 04:33:08 EDT 2000

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

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


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

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

  - 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
    them as being the same SVC (using the SessionID and/or the mediaChannel

[[ 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,

----- Original Message -----
From: "Roni Even" <Roni_e at ACCORD.CO.IL>
To: <ITU-SG16 at>
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
> 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
> V4. The editor pointed out that there is a contradiction between the text
> Annex C in paragraph C.3.8.2 and fast start in 8.1.71. concerning the use
> bi-directional channels.
> I looked at the subject and my suggestion is to keep the text in annex C
> add to the end of the  first paragraph of "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
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at

-------------- next part --------------
A non-text attachment was scrubbed...
Type: application/octet-stream
Size: 27641 bytes
Desc: not available
URL: <>

More information about the sg16-avd mailing list