Fast Connect & Bi Directional channels

Paul E. Jones paulej at PACKETIZER.COM
Fri Dec 15 18:36:37 EST 2000


Sasha,

Would you agree with Bob Gilman that we can use the forward LCN proposed in
for OLC as the same value to be used as the reverse LCN?

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: Wednesday, December 13, 2000 5:08 AM
Subject: RE: Fast Connect & Bi Directional channels


> Hi Paul
>
> First of all I want to be completely certain about the value of the
> forwardLogicalChannelNumber in the response to the bi-directional channel
> proposal.
>
>
> If we agree that it should be the same value as in the corresponding field
> from the proposal OLC then following solutions are possible (and no one is
> perfect):
>
> 1 Leave everything as it is.  (Loosing the ReverseLCN as I already
> described).
> 2 Use OLC.reverseLogicalChannelParameters.replacementFor as (RLCN).
> For me it is a little bit ugly, but excelent solution.
> I am almost certain that it breaks nothing in nonSET H.323.
> But it probably may cause problems to SET with multiple fast starts.
> 3 I would really not want to do this through nonStansard fields.
> 4 To add new field:
> OLC.reverseLogicalChannelParameters.reverseLogicalChannelNumber.
> The only problem with this is that we need to change the H.245
> syntax.
> In addition this field is difficult to explain from the H.245 point
> of view.
> (I do not think we've had ever before a precedent of changing H.245
> as a result of
> fast start needs)
>
> I really do not know which one I prefer.
>
> Sasha
>
>
>
> -----Original Message-----
> From: Paul E. Jones [mailto:paulej at packetizer.com]
> Sent: Wednesday, December 13, 2000 6:57 AM
> To: Sasha Ruditsky
> Cc: ITU-SG16 at mailbag.cps.intel.com
> Subject: Re: Fast Connect & Bi Directional channels
>
>
> 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