Support bi-directional channels in annex C fast start

Paul E. Jones paulej at PACKETIZER.COM
Tue Sep 5 03:12:55 EDT 2000


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



More information about the sg16-avd mailing list