Fast Connect & Bi Directional channels

Paul E. Jones paulej at PACKETIZER.COM
Tue Dec 12 23:57:03 EST 2000


Sasha,

Yes, I see your point now.. thanks for clarifying this issue for me.

This makes life more interesting, doesn't it?

So I suppose the question is one of whether we feel we need to provide this
information or whether we do not.  To keep life simpler for the H.245 state
machine, I would guess that we should do something to allow the called
endpoint to return the LCN for the reverse channel.  However, there doesn't
seem to be a real clean place to provide that information.  We could always
do strange things, such as use nonStandard fields or use the
"replacementFor" field in the OLC.reverseLogicalChannelParameters structure.

What's your preference?

I would guess that the proponents of this text (who wanted it for Annex Dv2
primarily) should have something to say regarding this.

Paul

----- Original Message -----
From: "Sasha Ruditsky" <sasha at tlv.radvision.com>
To: "Paul E. Jones" <paulej at packetizer.com>
Cc: <ITU-SG16 at mailbag.cps.intel.com>
Sent: Tuesday, December 12, 2000 3:28 AM
Subject: RE: Fast Connect & Bi Directional channels


> 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
> > ***********************************************
> >
> >
> >
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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