Fast Connect & Bi Directional channels
Hi
It looks like there is yet another bug in the fast start procedure. It is related to bi-directional channels establishment.
Standard says that in each bi-directional channel proposal there should be unique forwardLogicalChannelNumber. Standard says nothing about the value of this field in the accepted bi-directional OLC.
It is known that bi-directional channels need 2 logical channel numbers (forward and reverse). I see 2 options for the value of forwardLogicalChannelNumber field in the accepted bi-directional OLC:
1. It may be the same value as the forwardLogicalChannelNumber in the corresponding proposal. In this case we do not have the logical channel number for the reverse direction. This works OK till we are in fast start, but after H.245 connection establishment it will be impossible to perform H.245 actions on the reverse direction of the channel.
2. It may be the unique logical channel number that is provided by calling party and identifies the channel -- the reverseLogicalChannelNumber. The problem with this is that caller does not know to which proposal this channel belongs. BTW The same problem exists with the unidirectional channels from callee to caller and the solution is just to find the corresponding proposal, using different channel characteristics.
I personally prefer the second option because it is more correct from the H.245 point of view. But, In any case it should be decided which is the standard one .
Sasha
*********************************************** Alexander(Sasha) Ruditsky RADVision Ltd. 24 Raul Wallenberg St. Tel Aviv 69719 Israel
Tel: +972-3-645-5220 Fax: +972-3-644-2903 Direct: +972-3-645-5273 sasha@radvision.rad.co.il ***********************************************
Sasha,
This logic was borrowed from the way that we open bi-directional T.120 channels, I believe. Either endpoint may signal the opening of a T.120 channel, but only one side provides the LCN. Is this same logic not sufficient?
Paul
----- Original Message ----- From: "Sasha Ruditsky" sasha@tlv.radvision.com To: ITU-SG16@mailbag.cps.intel.com Cc: "Orit Levin" orit@radvision.com; paulej@PACKETIZER.COM Sent: Monday, December 11, 2000 8:04 AM Subject: Fast Connect & Bi Directional channels
Hi
It looks like there is yet another bug in the fast start procedure. It is related to bi-directional channels establishment.
Standard says that in each bi-directional channel proposal there should be unique forwardLogicalChannelNumber. Standard says nothing about the value of this field in the accepted bi-directional OLC.
It is known that bi-directional channels need 2 logical channel numbers (forward and reverse). I see 2 options for the value of forwardLogicalChannelNumber field in the accepted bi-directional OLC:
- It may be the same value as the forwardLogicalChannelNumber in the
corresponding proposal. In this case we do not have the logical channel number for the reverse direction. This works OK till we are in fast start, but after H.245 connection establishment it will be impossible to perform H.245 actions on the reverse direction of the channel.
- It may be the unique logical channel number that is provided by calling
party and identifies the channel -- the reverseLogicalChannelNumber. The problem with this is that caller does not know to which proposal this channel belongs. BTW The same problem exists with the unidirectional channels from callee
to
caller and the solution is just to find the corresponding proposal, using different channel characteristics.
I personally prefer the second option because it is more correct from the H.245 point of view. But, In any case it should be decided which is the standard one .
Sasha
Alexander(Sasha) Ruditsky RADVision Ltd. 24 Raul Wallenberg St. Tel Aviv 69719 Israel
Tel: +972-3-645-5220 Fax: +972-3-644-2903 Direct: +972-3-645-5273 sasha@radvision.rad.co.il
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (2)
-
Paul E. Jones -
Sasha Ruditsky