Mike, Hussein, (and all),
Thanks for your comments on the ReplacmentFor text. I'm trying to wrap up a revised contribuiton for SunRiver this week. I would appreciate your thoughts on the following:
At 02:44 PM 8/14/97 +0100, nilsson_m_e@bt-web.bt.co.uk wrote:
I am concerned about adding a FlowControl field to the OpenLogicalChannelAck message. This could make things very complicated in the future when people start to use this for something else, something that was not intended and something that we have not even thought about yet.
I propose to not mention this issue in the ReplacementFor text, since I think it is a generic issue with RSVP support and has nothing to do with ReplacementFor in particular. We can modify the appendix example text in SunRiver (or even after) based on however the group decides to handle this.
From Dave's document REPFR_AP.DOC, concerned with the replacementFor mechanism, the reason for creating this mechanism is quite clear, and it is very useful.
However, I think we should clarify how much flexibility is allowed. In particular, how long can the transmitter wait before sending CloseLogicalChannel for the first channel? Can it delay sending this for sometime, and switch between the two channels?
No, this is not intended to be allowed. It's purely for a one-time mode switch.
in his example is it possible to start with G.723, then send G.711-OpenLogicalChannel with replacementFor=G.723, switch to G.711, then at some later time switch to G.723 again, and then perhaps back to G.711?
No this should not be allowed. I'll clarify both the example appendix and the proposed normative semantics for H.245 on this point.
If we want to allow this then we should clarify this in the proposed appendix, and perhaps change the terminology replacementFor to, say, alternativeTo. If we do not, then we should ensure some strong normative wording is added about sending CloseLogicalChannel immediately after receiving the other OpenLogicalChannelAck, and add a note specifically outlawing this scenario.
I'll propose some text along the lines you suggest. (That we do not want to allow this.)
------------------------------------------------------------------- Dave Lindbergh Email: lindbergh@pictel.com Manager, Technical Standards Group Voice: +1 508 623 4351 PictureTel Corporation Fax: +1 508 749 2804 100 Minuteman Road - M/S 635 H.320: +1 508 437 0265 (twice) Andover MA 01810 USA http://standards.pictel.com PGP fingerprint: C8 3E 28 69 53 0A 4B 87 EF E0 11 CD AC 87 4D CD -------------------------------------------------------------------