H.245 ReplacementFor Appendix

[Dave Lindbergh]

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