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@ACCORD.CO.IL] Sent: Tuesday, September 05, 2000 10:33 AM To: ITU-SG16@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@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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
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@ACCORD.CO.IL To: ITU-SG16@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@ACCORD.CO.IL] Sent: Tuesday, September 05, 2000 10:33 AM To: ITU-SG16@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@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:
- In H.323v3 (which is what the Implementers Guide is correcting), it
is
illegal to use a bi-directional channel with Fast Connect.
- 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.comFor help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
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@PACKETIZER.COM To: ITU-SG16@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@ACCORD.CO.IL To: ITU-SG16@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@ACCORD.CO.IL] Sent: Tuesday, September 05, 2000 10:33 AM To: ITU-SG16@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@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:
- In H.323v3 (which is what the Implementers Guide is correcting), it
is
illegal to use a bi-directional channel with Fast Connect.
- 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 somehowassociates 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.comFor help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.comFor help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (3)
-
Paul E. Jones -
Roni Even -
Roni Even