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@packetizer.com] Sent: Tuesday, September 05, 2000 9:13 AM To: Mailing list for parties associated with ITU-T Study Group 16; Roni_e@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@ACCORD.CO.IL To: ITU-SG16@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@accord.co.il
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com