Fast Connect & Bi Directional channels

Bob Gilman rrg at AVAYA.COM
Thu Dec 14 15:05:36 EST 2000


Sasha-
Thanks for your reply.  Comments below.
-Bob

Sasha Ruditsky wrote:
>
> 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 ...
> .....

You're right.  I missed that.    What do most implementations do now
for unidirectional channels?  Do they pick their own (different) channel
number when they return the chosen OLC; do they always pick '1', say; or
do they return the number supplied by the caller?  Our implementation
picks its own number (always the same, but who's looking), and that seems
to be accepted by most other implementations we've tested with.

>
> And the standard states nothing about forwardLogicalChannelNumber in the
> proposal for such channel.

You're right again.  The statement about unique channel numbers for each offered
OLC is in the paragraph on caller-to-callee channels, and may be assumed to
apply only to them.  Perhaps we need to make this clear as well (I think we send
different channel numbers in all offered OLCs.)  I'd like to know what most
implementations actually do before we make any changes.

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

This applies to the offered callee-to-caller channels because the called
endpoint
may change the (unspecified) forwardLCN to its own choice.  That means that all
proper implementations are using the dataType to make the association, so why
not
make the same assumption for a bidirectional channel (for which, BTW, the OLC
will
contain both forward and reverse logical channel parameters, I presume, since
both
must be given (generally) for both ends.)  This would suggest that the called
party
could change the "forward" LCN to pass back the "reverse" LCN (and the caller
can
use the dataType to recognize this.  I'll bet this will work in most, if not
all,
implementations because it would look like the callee was changing the
forwardLCN
in a reverse OLC, which it normallly can do.  (Murphy's law says the caller
would
think the callee was changing the LCN on a forward-channel OLC and get really
upset!)

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

Well, maybe we just do this and avoid any problems that changing the forwardLCN
would
cause.  (Can we be assured that the callee has no other logical channels up that
might conflict with the offered LCN?)

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

Well, one for each bidirectional media stream, anyway.

>
> Sasha
>
.....
I suppose we should ask Paul Jones (are you listening, Paul) whether or not this
might be handled in the implementors' guide.

-Bob
----------------------------------------------------
Bob Gilman       rrg at avaya.com      +1 303 538 3868

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