Subject: [MMUSIC] draft-even-mmusic-video-media-control-00.txt

From: "Even, Roni" <[email-masked]>
Date: Thu, 18 Jul 2002 09:05:38 +0300

Hi,
I think I would like to put focus on the subject
1. In order to support simple voice activated video switching conference
with end-points that are not conference aware. This is the most basic video
conference. We need to be able to have a clean video switch. This means that
like when you change a channel in your cables, you may see a blank screen
and then you will see the new channel without any artifact. 
2. The process includes a freeze n the receiver and new stream from the new
sender.
3. I think we agree that the freeze is an attribute.
4. From the options I presented for the new streams there were two that are
being discussed.
 4.1 use the RTCP feedback - the current meaning of the RTCP message is an
indication of a QOS problem.
 4.2 Use a new SDP attribute. - the discussion was if that is a stream state
change - I argued that to the receiver it is a change in the state of the
stream he will receive
5. I prefer to use the attribute.
   5.1. It makes the process use the same protocol layer as the freeze -
both will be SDP based
  5.2 it does not change the meaning of the RTCP indication.

Thanks

Roni Even

**********************************************
Roni Even

Polycom Network Systems
Tel: +972-3-9251200
Mobile: +972-55-481099
Fax: +972-3-9211571
Email: [email-masked]

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Joerg Ott <[email-masked]>
Date: Thu, 18 Jul 2002 09:28:14 +0200 (MEST)

> 3. I think we agree that the freeze is an attribute.

Just some random thought for curiosity:

Let me quickly express why I think you need this attribute (or find
out that you don't really need it).

- You use "freeze" to indicate that a receiver shall stop decoding.
- A receiver would (should) do this anyway if it stops receiving packets.
- As long as only valid data is received in the packets, that works fine.
- In a pure IP environment, no sender would packetize send rubbish.
- Can this be different in ISDN where just cannot easily send "no data"
  (expect for video fill patterns) and this, consequently, only
  be an issue for MCUs who need to switch from one source to the next
  and may not be able or willing to packetize only fully decodable
  video frame fragments (e.g. macroblocks, GOBs).
- if the MCU would do proper parsing and packetization of the media
  stream and forward only valid frames or blocks, would this be a non-issue?

Am I missing something here?

>   5.2 it does not change the meaning of the RTCP indication.

As pointed out in a previous mail; what would be the state change in the
next round?  What would be the proper "negotiation" behavior in o/a?
(since both parties would need to agree on this)?

That's why I think it does not fit in SDP.

Joerg