Fast Connect & Bi Directional channels

[Sasha Ruditsky]

Hi Paul

When we open T.120 or any other bi-directional channel through the H.245
then openLogicalChannelAck message carries 2 LCNs:
1st in the forwardLogicalChannelNumber field 
2nd in the reverseLogicalChannelParameters.reverseLogicalChannelNumber field
So when opening the real H.245 channel there is no problem.

With fast start the problem exists because the openLogicalChannel message 
(the response for fast start case) has just one LCN field -- the
forwardLogicalChannelNumber.

It should be decided what should be the value of this field.
Currently standard says nothing about this field specifically.
The H.323 states in 8.1.7.1 : "When accepting a proposed bi-directional
channel for transmission between the calling endpoint and the called
endpoint, the called endpoint shall return the corresponding
OpenLogicalChannel structure to the calling endpoint.". 
In the same section before there is note: "The called endpoint is only
allowed to alter fields in a proposed OpenLogicalChannel structure as
specified in this section".

I believe that from the lawyer point of view the aforementioned means: "the
forwardLogicalChannelNumber" should not be changed.

I do not know if this was exactly the intent, but if it was, it is OK with
me, except the fact that we do not have the reverseLogicalChannelNumber
field for such channel.     
In most cases it does work OK. The only case that may cause problem is
inheritance of such channel by H.245. The reverse direction of the
bi-directional H.245 channel opened in such way will not be able to be a
subject of the H.245 commands and indications. I know no H.245 commands and
indications that is impossible to work without when working with fax
channel. So I do not think that we have specific problem which may affect
fax channels opened in such way.
 
>From other hand the procedure is (a little bit, but) broken. So at least
this should be understood and mentioned in the standard.

----------------------------------------------------------------------------
--------------------------
The possible alternative (of cause if we do agree that the standard is
unclear in this point) is two put the reverseLogicalChannelNumber into the
forwardLogicalChannelNumber field of the accepted bi-directional channel.
This solves the problem, but requires the caller to implement more
complicated mechanism to identify to the proposed OLC for the received
accepted OLC.
 
----------------------------------------------------------------------------
--------------------------
But in any case I just want to be able to implement this so it should be
agreed what is the proper value to be put in this field.

Sasha




-----Original Message-----
From: Paul E. Jones [mailto:paulej at packetizer.com]
Sent: Monday, December 11, 2000 11:10 PM
To: Sasha Ruditsky; ITU-SG16 at mailbag.cps.intel.com
Cc: Orit Levin
Subject: Re: Fast Connect & Bi Directional channels


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 at tlv.radvision.com>
To: <ITU-SG16 at mailbag.cps.intel.com>
Cc: "Orit Levin" <orit at radvision.com>; <paulej at 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:
>
> 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 at radvision.rad.co.il
> ***********************************************
>
>
>