Hi Paul
Yes, I think that using the same number for the both LCNs of the
bi-directional channel is the best solution for this problem. And I agree
with the text that clarifies this.
Sasha
-----Original Message-----
From: Paul E. Jones [mailto:paulej@PACKETIZER.COM]
Sent: Saturday, December 16, 2000 9:48 AM
To: ITU-SG16(a)mailbag.cps.intel.com
Subject: Re: Fast Connect & Bi Directional channels
Sasha, et al.,
Sorry for the last e-mail on this subject. I had not seen this one, yet.
So, it appears that you agree that for bi-directional channels we can use
the forward LCN as the value of the reverse LCN. I have attached the most
recent documents containing corrections to H.323v4 and H.225.0v4, which
includes a proposal for this item.
Please review the text and give me comments.
Best Regards,
Paul
----- Original Message -----
From: "Sasha Ruditsky" <sasha(a)TLV.RADVISION.COM>
To: <ITU-SG16(a)mailbag.cps.intel.com>
Sent: Thursday, December 14, 2000 2:35 AM
Subject: Re: Fast Connect & Bi Directional channels
> Hi Bob
>
> First of all I disagree that the caller determine the logicalChannelNumber
> for the channels from callee to caller, H.323 in 8.1.7.1 states:
> .....
> When accepting a proposed channel for transmission from called endpoint to
> calling endpoint, the called endpoint shall return the corresponding
> OpenLogicalChannel structure to the calling endpoint, inserting a unique
> forwardLogicalChannelNumber into the OpenLogicalChannel structure ...
> .....
>
> And the standard states nothing about forwardLogicalChannelNumber in the
> proposal for such channel.
>
> So the calling entity allocates forwardLCN for channels transmitted on
which
> it will transmit.
> The caller that wants to associate the accepted OLC with proposed OLC may
do
> this only using dataType parameter and BTW this is one of the reasons why
> this parameter should be never changed by called entity.
> --------------------------------------------------------------------------
--
> ---------------------------------------------------------
> BUT, From the other hand I do agree that making forward and reverse LCN
> equal will work.
> And to be honest this is probably the least ugly solution known till know.
>
> Unfortunately, it will require from the implementation of callee the
> sophisticated LCN allocation mechanism that allows allocation of LCNs
while
> taking into account the fact that some of LCNs were preallocated for bi
> directional channels by the caller.
> Fortunately, as for now, there is just one such LCN possible!
>
> Sasha
>
>
>
> -----Original Message-----
> From: Bob Gilman [mailto:rrg@AVAYA.COM]
> Sent: Wednesday, December 13, 2000 7:43 PM
> To: ITU-SG16(a)mailbag.cps.intel.com
> Subject: Re: Fast Connect & Bi Directional channels
>
>
> Sasha-
> I have the following comments about your four proposals:
> 1. Do we really loose the reverse LCN with this option, or is it
> just the same as the forward LCN? With this latter view, we
> could then invoke H.245 later on the forward and/or the reverse
> channels. This should work because, at the time Fast Connect is
> used, there would be no other channel numbers assigned to interfere.
> I'd hate to lose the uniqueness of the channel numbers within the
> offered/accepted OLCs. Also, this is exactly the same as what we
> do now with unidirectional channels: the caller determines the
> channel numbers for both the forward (calller to callee) and the
> reverse (callee to caller) channels. I don't believe there is any
> restriction in H.245 that requires the forward channel numbers to
> be different from the reverse channel numbers; the asymmetry of the
> commands and responses makes the coding unique.
> 2. I think using the replacementFor field should be avoided because
> this can adversely affect SETs.
> 3. I agree.
> 4. It's tough to add a new field at this stage - especially since it
> would be in H.245!
> What do you think?
> -Bob
> ----------------------------------------------------
> Bob Gilman rrg(a)avaya.com +1 303 538 3868
>
>
> Sasha Ruditsky wrote:
> >
> > 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@packetizer.com]
> > Sent: Wednesday, December 13, 2000 6:57 AM
> > To: Sasha Ruditsky
> > Cc: ITU-SG16(a)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(a)tlv.radvision.com>
> > To: "Paul E. Jones" <paulej(a)packetizer.com>
> > Cc: <ITU-SG16(a)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@packetizer.com]
> > > Sent: Monday, December 11, 2000 11:10 PM
> > > To: Sasha Ruditsky; ITU-SG16(a)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(a)tlv.radvision.com>
> > > To: <ITU-SG16(a)mailbag.cps.intel.com>
> > > Cc: "Orit Levin" <orit(a)radvision.com>; <paulej(a)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(a)radvision.rad.co.il
> > > > ***********************************************
> > > >
> > > >
> > > >
> > >
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv(a)mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
