Subject: RE: [MMUSIC] video media control draft

From: Orit Levin <[email-masked]>
Date: Mon, 22 Jul 2002 18:53:37 -0400

I would summarize the situation from the standards' perspective:
1. Violently Agreed: Both RTCP (as is + "feedback") and SDP+Offer/Answer are
interim patches for the purpose.
2. Disagreed: Which one is more "architecturally incorrect".
3. Agreed: Definition of a new protocol/approach requires time. Hopefully,
we will start work on it.
	I would like to summarize the situation from the multimedia
implementers perspective:
1. Although the "RTCP based FIR" has been defined since 1996 (as per RFC
2032), it neither hasn't been used for application purposes nor hasn't been
expanded beyond H.261. There are good reasons for this...
2. On the contrary, we know about at least 6 (!) major multimedia vendors
that have been (almost desperately) seeking for an agreed doable solution
since yesterday and, in the meanwhile, are working on proprietary
extensions.
3. I would like to ask (additional) interested vendors that are looking into
this problem to contact me (or my co-authors) directly in order to compile
our preferences and agree on the intermediate solution.

Best Regards,
Orit Levin
Chief Architect
RADVISION Inc.
Tel:  +1.201.689.6330
	Side Bar "SDP Stream State" topic:
I can see the difference in "a data model" between sending a request
implicitly (i.e. using a future state description) and sending a request
explicitly (i.e. using an attribute). I am afraid, I disagree about the
difference in consequences in both cases.
For example, in the "put-on-hold" case, the situation is very similar to the
"reset-state-request" with all the potential fears expressed in the previous
Jonathan's mail.

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