Hussein,

Reading carefully over your proposed text, I conclude that it is not strictly necessary for the receiver to get OLC before it requests a bigger RSVP reservation. The thing that tells the receiver to do this is _not_ OLC, but is the RSVP advertisement.

So if I'm correct about that (I might not be), then your proposal is really an optimization of the procedure rather than a correction, in that it saves a round-trip by doing some of the RSVP and H.245 stuff in parallel.

However, I'd prefer strongly to keep the example in the appendix simple; there is nothing to prevent implementors from being more clever and saving some time as you suggest. But I think it's simpler for the reader if all the RSVP operations are in a single step, if it will in fact work correctly that way.

So I'd like to keep the example as it was before; the only change I'll make is to use the word "advertise" instead of "request".

If this is wrong, we can fix it in Sunriver.

I hope to see you there.

--Dave L.

At 06:45 PM 8/26/97 -0700, Hussein Salama wrote:

Dave,

I looked at your ReplacementFor document. In RSVP the transmitter first advertizes the reservation parameters, then the receiver requests reservations based on the transmitter's advertizements. Based on that, I suggest the modifications below to the example you gave on page 2.

My understanding is that the example is based on the assumption that both the transmitter and the receiver will reuse the same port numbers of the original channel in the ReplacementFor channel.

Example

Suppose LC 723 is open, carrying G.723.1 audio, and it is desired to switch to G.711 (on LC 711), but the receiver has a capability for only one audio channel. The replacementFor mechanism may be used by the transmitter to effect a seamless mode change as follows:

1. Only for the case of H.323 using RSVP: since the new channel will

require more bandwidth (64 kbps) than the existing channel (6.4 kbps), the transmitter advertizes a larger RSVP bandwidth.

2. The transmitter sends OpenLogicalChannel for the new LC 711,

including the replacementFor parameter, referring to the existing LC 723.

This tells the receiver that LC 711 is a replacement for LC 723, and that LC 711 will never carry traffic simultaneously with LC 723.

3. While continuing to decode G.723.1 from LC 723, the receiver prepares

for a seamless switch to decoding G.711.

Such preparation might include loading appropriate decoder software.

Only for the case of H.323 using RSVP: the receiver requests and receives acknowledgment for a larger RSVP bandwidth reservation.

When the receiver has completed preparations to accept the G.711 audio stream, it responds with OpenLogicalChannelAck for LC 711.

4. The transmitter stops sending G.723 audio on LC 723 and seamlessly

begins sending G.711 audio on LC 711.

5. The transmitter immediately sends CloseLogicalChannel for LC 723, as

this LC is no longer carrying any traffic, and is no longer needed.

6. Only for the case of H.323 using RSVP, if the new channel requires

less bandwidth than the original channel, the transmitter advertizes the smaller RSVP bandwidth after it sends the CloseLogicalChannel message, and the receiver requests a smaller RSVP bandwidth reservation after it receives the CloseLogicalChannel message (does not apply in this example).

Does this sound right?

Hussein

Dave Lindbergh wrote:

...

At 03:48 PM 8/26/97 -0700, Hussein Salama wrote:

...

Dave,

Your APC covers the ReplacementFor function. It seems to me that from an RSVP pont of view, making reservations for ReplacementFor channels is the same as making reservations for new channels. So I see no need for dedicating a section for ReplacementFor channels in the RSVP APC. Is that fine or am I missing something?

If I understand the RSVP method correctly, I think you're right.

As long as nothing special or different needs to be done while using ReplacementFor vs. ordinary LC opening and closing, we don't need to mention it specially. I think this is the case.

The only thing special (which I already mentioned in the RepFor appendix text) is reminding impelementors to increase the RSVP bandwidth _before_ switching to a higher rate channel, or to reduce it _after_ switching to a lower rate channel.

Do you agree?

--Dave L.

---

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

---

-- Hussein Salama Cisco Systems, IOS Development (408) 527-7147 170 W. Tasman Dr., San Jose, CA 95134

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