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@avaya.com +1 303 538 3868
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com