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@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@avaya.com +1 303 538 3868 Sasha Ruditsky wrote:
starts. point this
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Sasha- Thanks for your reply. Comments below. -Bob Sasha Ruditsky wrote:
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.
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!)
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?)
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
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@TLV.RADVISION.COM> To: <ITU-SG16@mailbag.cps.intel.com> Sent: Thursday, December 14, 2000 2:35 AM Subject: Re: Fast Connect & Bi Directional channels the
Paul, To be perfectly clear, I recommend inserting the text below into the new sentence you added to 8.1.7.2. "The ***called*** endpoint shall use the proposed logical channel number in the forwardlogicalChannelNumber element as the logical channel number of the ***forward and*** reverse channel." Paul Long ipDialog, Inc. -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Saturday, December 16, 2000 1:48 AM To: ITU-SG16@MAILBAG.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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Paul, Agreed. I have changed the text accordingly. Paul ----- Original Message ----- From: "Paul Long" <plong@PACKETIZER.COM> To: <ITU-SG16@mailbag.cps.intel.com> Sent: Sunday, December 17, 2000 12:24 PM Subject: Re: Fast Connect & Bi Directional channels the
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (4)
-
Bob Gilman
-
Paul E. Jones
-
Paul Long
-
Sasha Ruditsky