Subject: Re: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, June 17, 2013

From: Flemming Andreasen <[email-masked]>
Date: Tue, 04 Jun 2013 22:21:01 -0400

On 5/31/13 6:46 AM, Emil Ivov wrote:
> Dear chairs,
>
> Could you please also consider the following draft for the interim 
> meeting agenda:
>
> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan
>
Sure, however I could use some clarification here. On one hand, the 
draft falls squarely in the middle of the overall "Plan" discussion we 
have and hence is highly relevant, but at the same time, if I understand 
correctly, the draft is not asking MMUSIC to do anything in terms of 
protocol development. Rather, if this approach is adopted, it would be 
more of an RTCWeb usage document specifying how one could use several 
different mechanisms (and possibly WebRTC APIs) to implement signaling. 
There doesn't seem to be a "mandatory to implement" mechanism for 
guaranteeing interoperability (in contrast to Plan A/B), but rather 
there are references to "app specific signalling" mechanisms, etc. Am I 
missing something here ?

> I apologise if not stating this earlier has introduced any confusion.
>
No worries.

Thanks

-- Flemming

> Regards,
> Emil
>
> On 30.05.13, 21:56, IESG Secretary wrote:
>> Greetings,
>>
>> This is to announce a(nother) virtual interim meeting for the MMUSIC
>> Working Group to take place on Monday, June 17, from 7:00 am - 10:00 am
>> Pacific Time. The goal of this meeting is to come to a resolution on the
>> so-called "Plan A" or "Plan B" approach related to SDP signaling needed
>> by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of "m=" lines or
>> very few "m=" lines and to what extent is there sub-negotation and
>> signaling at the SSRC level).
>>
>> A more detailed agenda and logistics will be sent out separately on the
>> MMUSIC mailing list. For now, people should take a close look at the
>> following two drafts:
>>
>> http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt
>>
>> http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt
>>
>> You may also want to look at
>> http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt
>>
>>
>> Thanks
>>
>> -- Ari & Flemming (MMUSIC co-chairs)
>>
>>
>> PS: Per our previous interim meeting announcement, we tried to schedule
>> a longer and in-person physical interim meeting, however it has proven
>> impossible to find a set of dates where we could get critical mass for
>> such a meeting. Scheduling even a virtual interim before the Berlin IETF
>> has been surprisingly difficult with the above date being the only
>> viable option at this point.
>> _______________________________________________
>> mmusic mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 4 Jun 2013 19:41:17 -0700

Yes, you are missing something. No plan analyzes issues with both Plan A and Plan B and describes how to fix them. As they stand, both Plan A nor Plan B result in O/A exchanges that aren't needed and will break congestion control. Also, neither satisfies the requirements of the RTP usage doc or is compatible with a number of legacy implementations. No  plan offers a solution to these and other issues. 

On Jun 4, 2013, at 7:29 PM, "Flemming Andreasen" <[email-masked]> wrote:

>> Could you please also consider the following draft for the interim meeting agenda:
>> 
> Sure, however I could use some clarification here. On one hand, the draft falls squarely in the middle of the overall "Plan" discussion we have and hence is highly relevant, but at the same time, if I understand correctly, the draft is not asking MMUSIC to do anything in terms of protocol development. Rather, if this approach is adopted, it would be more of an RTCWeb usage document specifying how one could use several different mechanisms (and possibly WebRTC APIs) to implement signaling. There doesn't seem to be a "mandatory to implement" mechanism for guaranteeing interoperability (in contrast to Plan A/B), but rather there are references to "app specific signalling" mechanisms, etc. Am I missing something here ?
> 
>

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 05 Jun 2013 00:44:43 -0400

> Yes, you are missing something. No plan analyzes issues with both Plan A and Plan B and describes how to fix them. As they stand, both Plan A nor Plan B result in O/A exchanges that aren't needed a…
I understand that "no plan" sees issues with Plan A and Plan B as 
currently defined. What I don't understand is what extensions or updates 
to SDP signaling mechanism are being proposed here and hence which part 
of this discussion belongs in MMUSIC as opposed to RTCWeb simply 
specifying how it wants to use a set of current/developing mechanisms 
(or rely on app specific mechanisms, etc.) ? In other words, what does 
"no plan" seek from MMUSIC ?

Thanks

-- Flemming

> .

---

From: Emil Ivov <[email-masked]>
Date: Wed, 05 Jun 2013 12:37:15 +0200

Hey Flemming,

You are right, there are no specific SDP updates that "No Plan" is 
asking from mmusic.

That said however, the same is pretty much true about Plan A and Plan B. 
They both discuss ways of using SDP and the extensions that might be 
implied to these ways are considered mostly collateral:

Plan A:

   This document describes a *modest*
   set of extensions to SDP which allow it to cleanly handle arbitrary
   numbers of flows while still retaining a large degree of backward
   compatibility with *existing* and non-RTCWEB endpoints.

Plan B:

   Plan B mostly uses *existing* IETF standards, introducing a single new
   draft [I-D.lennox-mmusic-sdp-source-selection] to specify how
   individual media sources can be accepted/rejected at the SSRC level
   via SDP.

I might be off, but it was my understanding that the interim meeting was 
not going to be about these specific extensions (which could possibly be 
specified regardless of which Plan we go for) but mostly about the best 
ways to use SDP with multiple sources. The choices we make could have an 
impact on multiple working groups, which, I assumed, was the main reason 
for having the discussion mmmusic.

In that sense I see "No Plan" as quite related to this discussion.

Am I right in assuming this and if so does the above answer your question?

Emil

-- 
https://jitsi.org

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Jun 2013 12:41:19 -0400

> implied to these ways are considered mostly collateral:

???

AFAIK plans A and B both assume BUNDLE, and use it, and by implication 
impose restrictions on its use. Similarly I think No Plan has the same 
characteristics.

I guess No Plan and Plan B *could* be used without BUNDLE. Is that your 
point? At least I don't see that as the expectation for typical use.

In any case I think these discussions are important context for the 
BUNDLE discussions.

	Thanks,
	Paul

>>> Yes, you are missing something. No plan analyzes issues with both
>>> Plan A and Plan B and describes how to fix them. As they stand, both
>>> Plan A nor Plan B result in O/A exchanges that aren't needed and will
>>> break congestion control. Also, neither satisfies the requirements of
>>> the RTP usage doc or is compatible with a number of legacy
>>> implementations. No  plan offers a solution to these and other issues.
>>>> draft falls squarely in the middle of the overall "Plan" discussion
>>>> we have and hence is highly relevant, but at the same time, if I
>>>> understand correctly, the draft is not asking MMUSIC to do anything
>>>> in terms of protocol development. Rather, if this approach is
>>>> adopted, it would be more of an RTCWeb usage document specifying how
>>>> one could use several different mechanisms (and possibly WebRTC
>>>> APIs) to implement signaling. There doesn't seem to be a "mandatory
>>>> to implement" mechanism for guaranteeing interoperability (in
>>>> contrast to Plan A/B), but rather there are references to "app
>>>> specific signalling" mechanisms, etc. Am I missing something here ?
>>>>
>>>>

---

From: Emil Ivov <[email-masked]>
Date: Wed, 05 Jun 2013 18:57:38 +0200

Hey Paul,

> In any case I think these discussions are important context for the

Bringing this back into context:

* I made a request that No Plan be considered for the agenda of the 
MMUSIC virtual interim.

* Flemming responded to my request asking exactly what it was that No 
Plan was seeking from MMUSIC.

* I responded that while No Plan is mostly a user of MMUSIC products 
(such as SDP and BUNDLE) and while it is unlikely to have major impact 
on these products, on that point it was pretty much in the same boat as 
Plan A and Plan B.

So, my main point was that No Plan should be considered a legitimate 
citizen of the pending virtual interim.

Emil

-- 
https://jitsi.org

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 05 Jun 2013 21:03:23 -0400

On 6/5/13 6:37 AM, Emil Ivov wrote:
> That said however, the same is pretty much true about Plan A and Plan 
> B. They both discuss ways of using SDP and the extensions that might 
> be implied to these ways are considered mostly collateral:
>
> Plan A:
>
> I might be off, but it was my understanding that the interim meeting 
> was not going to be about these specific extensions (which could 
> possibly be specified regardless of which Plan we go for) but mostly 
> about the best ways to use SDP with multiple sources. The choices we 
> make could have an impact on multiple working groups, which, I 
> assumed, was the main reason for having the discussion mmmusic.
>
Agree with the latter part. In terms of approaches however, we 
previously had 2 (A and B), each of which seemed reasonably 
self-contained, and while clearly driven by RTCWeb, have broader scope 
than RTCWeb.

> In that sense I see "No Plan" as quite related to this discussion.
I agree it's related, but at the same time, the mechanism proposed seems 
to be tied to RTCWeb in terms of discussing RTCWeb APIs and leaving a 
lot of the machinery unspecified. Examples from the document:
<quote>
    The actual Offer/Answer semantics presented here do not differ
    fundamentally from those proposed by Plan A and Plan B.  The main
    differentiation point of this approach is the fact that the exact
    protocol mechanism is left to WebRTC applications.  Such applications
    or lightweight signalling gateways can then implement either Plan A,
    or Plan B, or an entirely different signalling protocol, depending on
    what best matches their use cases and topology.
</quote>

and

<quote>
    All of the above semantics are best handled and hence should be left
    to applications.  There are numerous existing or emerging solutions,
    some of them developed by the IETF, that already cover this. This
    includes CLUE channels [CLUE], the SIP Event Package For Conference
    State [RFC4575] and its XMPP variant [COIN].  Additional mechanisms,
    undoubtedly many based on JSON, are very likely to emerge in the
    future as WebRTC applications address varying use cases, scenarios
    and topologies.
</quote>

The above may be perfectly reasonable from an RTCWeb point of view, but 
I don't see MMUSIC as the place to make that decision. On the other 
hand, if it's more a matter of coming up with a general framework for 
how to establish/signal sessions that support a multitude of multimedia 
participants in a session subject to certain requirements 
(port-efficient, large number of participants can come and go 
dynamically, per source control of media parameters, etc.) via SDP 
signaling, then MMUSIC probably is the right place. The document should 
probably change a bit in some places then.

> Am I right in assuming this and if so does the above answer your 
I think it's clearly related, however I want to make sure that the scope 
is not limited to RTCWeb and hence does not assume anything RTCWeb 
specific (e.g. APIs, etc. which should not be the subject of MMUSIC 
discussions/documents).

I'd like to hear what other people think about this though (incl. the 
RTCWeb chairs).

Thanks

-- Flemming

>>> Plan A nor Plan B result in O/A exchanges that aren't needed and 
>>> will break congestion control. Also, neither satisfies the 
>>> requirements of the RTP usage doc or is compatible with a number of 
>>> legacy implementations. No  plan offers a solution to these and 
>>> other issues.
>>>> adopted, it would be more of an RTCWeb usage document specifying 
>>>> how one could use several different mechanisms (and possibly WebRTC

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 6 Jun 2013 12:46:20 +0700

On Jun 5, 2013, at 9:41 AM, Bernard Aboba <[email-masked]> wrote:

> As they stand, both Plan A nor Plan B result in O/A exchanges that aren't needed and will break congestion control

Bernard - that's a pretty strong statement. Uh, you want to explain how either plan A or B break congestion control?

---

From: Emil Ivov <[email-masked]>
Date: Thu, 6 Jun 2013 09:06:20 +0200

Hey Flemming,

Just to be clear, are you saying all this because you believe No Plan
should NOT be on the agenda of the mmusic interim meeting?

Emil

On Thu, Jun 6, 2013 at 3:03 AM, Flemming Andreasen <[email-masked]> wrote:
>> You are right, there are no specific SDP updates that "No Plan" is asking
>> from mmusic.
>>
>> They both discuss ways of using SDP and the extensions that might be implied
>> to these ways are considered mostly collateral:
>>
>> Plan A:
>>
>> specified regardless of which Plan we go for) but mostly about the best ways
>> to use SDP with multiple sources. The choices we make could have an impact
>> on multiple working groups, which, I assumed, was the main reason for having
>> the discussion mmmusic.
>>
> Agree with the latter part. In terms of approaches however, we previously
> had 2 (A and B), each of which seemed reasonably self-contained, and while
> clearly driven by RTCWeb, have broader scope than RTCWeb.
>
>
> I agree it's related, but at the same time, the mechanism proposed seems to
> be tied to RTCWeb in terms of discussing RTCWeb APIs and leaving a lot of
> the machinery unspecified. Examples from the document:
> <quote>
> The above may be perfectly reasonable from an RTCWeb point of view, but I
> don't see MMUSIC as the place to make that decision. On the other hand, if
> it's more a matter of coming up with a general framework for how to
> establish/signal sessions that support a multitude of multimedia
> participants in a session subject to certain requirements (port-efficient,
> large number of participants can come and go dynamically, per source control
> of media parameters, etc.) via SDP signaling, then MMUSIC probably is the
> right place. The document should probably change a bit in some places then.
>
>
> I think it's clearly related, however I want to make sure that the scope is
> not limited to RTCWeb and hence does not assume anything RTCWeb specific
> (e.g. APIs, etc. which should not be the subject of MMUSIC
> discussions/documents).
>
> I'd like to hear what other people think about this though (incl. the RTCWeb
> chairs).
>
> Thanks
>
> -- Flemming
>
>
>> Emil
>>
>>>> Yes, you are missing something. No plan analyzes issues with both Plan A
>>>> and Plan B and describes how to fix them. As they stand, both Plan A nor
>>>> Plan B result in O/A exchanges that aren't needed and will break congestion
>>>> control. Also, neither satisfies the requirements of the RTP usage doc or is
>>>> compatible with a number of legacy implementations. No  plan offers a
>>>> solution to these and other issues.
>>>
>>>>> draft falls squarely in the middle of the overall "Plan" discussion we have
>>>>> and hence is highly relevant, but at the same time, if I understand
>>>>> protocol development. Rather, if this approach is adopted, it would be more
>>>>> of an RTCWeb usage document specifying how one could use several different
>>>>> mechanisms (and possibly WebRTC APIs) to implement signaling. There doesn't
>>>>> seem to be a "mandatory to implement" mechanism for guaranteeing
>>>>> interoperability (in contrast to Plan A/B), but rather there are references
>>>>> to "app specific signalling" mechanisms, etc. Am I missing something here ?
>>>>>
>>>>>

-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
[email-masked]                        PHONE: +33.1.77.62.43.30
http://jitsi.org                       FAX:   +33.1.77.62.47.31

---

From: Kevin Dempsey <[email-masked]>
Date: Thu, 6 Jun 2013 13:40:50 +0100

Am i right in saying that what No Plan needs MMUSIC to say is that for
BUNDLE to be usable the applications must use some method to determine
which m- line a RTP stream is to be matched to? That method can be anything
the applications at both ends can agree upon. That can include SSRC
signalling within the SDP, unique PTs across m- lines, or even custom SIP
headers etc.

In the RTCWEB case, the signalling is already application specific. So that
signalling path could be used by such application.

On 6 June 2013 08:06, Emil Ivov <[email-masked]> wrote:

> asking
> implied
> ways
> to
> (port-efficient,
> is
> RTCWeb
> Plan A
> we have
> >>>>>>> Working Group to take place on Monday, June 17, from 7:00 am -
> 10:00
> >>>>>>> am
> >>>>>>> Pacific Time. The goal of this meeting is to come to a resolution
> on
> >>>>>>> the
> >>>>>>> by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of "m="
> lines
> >>>>>>> or

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 06 Jun 2013 08:58:07 -0400

> should NOT be on the agenda of the mmusic interim meeting?
No. I think it should, but I'm trying to get some clarity around what 
decisions and discussions belong to and should be handled by the RTCWeb 
group versus what belongs in the MMUSIC group.

-- Flemming

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 6 Jun 2013 12:31:39 -0700

In a highly congested environment, signaling will also be likely to be disrupted.   Therefore if signaling is necessary for a sender to reduce the sending rate (e.g. for example, in order to reduce resolution or framerate), then that rate reduction would itself be disrupted by congestion, preventing the sender from reducing rate, and thereby potentially resulting in congestive collapse. 
 
The solution to this, which has been widely implemented, is to enable rate reductions (such as removal of simulcast or layered streams) without a dependency on signaling.  This is possible because the initial O/A exchange focuses on negotiating the *envelope* of acceptable resolutions, frame rates, streams, etc. rather than attempting to control what is actually being sent in realtime.  As a result, the sender can reduce rate very quickly by dropping streams, with no signaling dependency.
 
It would appear to me that both Plan A and Plan B use signaling not just to control the envelope of acceptable configurations, but to determine what is actually being sent at a given moment.   If an O/A exchange is required for a sender to drop a stream, rapid adaptation (including congestion control) is hampered. 

> Subject: Congestion controll 
> From: [email-masked]
> Date: Thu, 6 Jun 2013 12:46:20 +0700
> CC: [email-masked]; [email-masked]; [email-masked]
> To: [email-masked]
> 
>

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 8 Jun 2013 11:44:10 +0700

I think everyone is on board with the fact that RTP represents what you would call an envelope from a congestion point of view. Exactly what can be changed inside that envelope and how might be a question and but that seems a very different one than the plan A / plan B discussion. Regardless of what happens with envelopes and congestion control, both plan A and B don't change and work with that answer. 

more inline … 

> In a highly congested environment, signaling will also be likely to be disrupted.   Therefore if signaling is necessary for a sender to reduce the sending rate (e.g. for example, in order to reduce…

Sure, I agree. I would say it as when we need to reduce the sending rate rapidly due to significant congestion, relying on round trips of signaling to do this may be too slow. 

> The solution to this, which has been widely implemented, is to enable rate reductions (such as removal of simulcast or layered streams) without a dependency on signaling.  This is possible because…

Of course. Agree

>  
> It would appear to me that both Plan A and Plan B use signaling not just to control the envelope of acceptable configurations, but to determine what is actually being sent at a given moment.

This is the part I strongly disagree with. I think both plan A and B allow any type of control that is acceptable in RTP / SDP for this including the use of RTCP. I can't see how plan A / B have anything to do with this. 

>   If an O/A exchange is required for a sender to drop a stream, rapid adaptation (including congestion control) is hampered. 

No O/A is request to stop sending RTP packets on a given stream. Plan A / B have nothing to do with that one way or another.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Jun 2013 09:52:34 -0700

> This is the part I strongly disagree with. I think both plan A and B allow any type of control that is acceptable in RTP / SDP for this including the use of RTCP. I can't see how plan A / B have an…

I think that this is the part that is getting confused.  This is not a
complaint against plan A or B.  I suspect that this is instead a
(wholly valid) concern with the the idea of using a=imageattr for
*setting* resolutions, which limits the ability of a sender to react
to congestion signals.  I agree with Cullen that this is separable
from A/B discussions.

---

From: Emil Ivov <[email-masked]>
Date: Mon, 10 Jun 2013 19:10:06 +0200

On 10.06.13, 18:52, Martin Thomson wrote:
> complaint against plan A or B.

It is indeed a problem with both of them and it is also mentioned in the 
No Plan draft.

Emil

> I suspect that this is instead a

-- 
https://jitsi.org

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Jun 2013 10:19:22 -0700

On 10 June 2013 10:10, Emil Ivov <[email-masked]> wrote:
> It is indeed a problem with both of them and it is also mentioned in the No
> Plan draft.

Well then you've assumed something about Plan A/B that is incorrect.
Neither plan constrains usage in a way that would prevent senders from
responding to congestion signals.  The fine-grained control that you
report as being problematic doesn't prevent senders from sending fewer
bits.

Is it possible that you have assumed that the existence of an m-line
or a=ssrc implies that the sender is obligated to send?  It doesn't.

The only possible problem is the use of a=imageattr in the examples of
Plan B, which might (might) overconstrain a sender, but Plan B doesn't
mandate anything regarding that in text.  Assuming anything there
would be a real stretch.

---

From: Emil Ivov <[email-masked]>
Date: Mon, 10 Jun 2013 20:12:02 +0200

> Well then you've assumed something about Plan A/B that is incorrect.

I am not following. Could you please point me to the specific
assumption that you have in mind?

> report as being problematic doesn't prevent senders from sending fewer

No, not explicitly at least. However, the more senders respond to
congestion signals the more they end up with inconsistencies between
what's been requested from the remote SDP, what the local application
would like to happen and what is actually happening. Such situations
would be much harder to control when all you've got is the remote SDP.

> or a=ssrc implies that the sender is obligated to send?

Nope.

Emil

> It doesn't.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 10 Jun 2013 12:16:37 -0700

Cullen said: 

 " No O/A is request to stop sending RTP packets on a given stream. " [BA]  So you're saying that you don't expect a=sendrecv/recvonly/sendonly to be used in Plan A to control streams described by individual m lines?    I had assumed that the O/A behavior described in RFC 3264 Sections 5.1 and 6.1 would apply in Plan A.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Jun 2013 13:16:58 -0700

> assumption that you have in mind?

Um, your argument in this thread?

Also, Section 1:

   Finally, both Plan A and Plan B, also create expectations that fine
   grained control of FEC, layering and RTX flows will always be
   implemented through Offer/Answer, which would not necessarily the
   best way to handle this in congested situations.

That draws a line from control of FEC/layering, etc... with O/A to
congestion control.

> would be much harder to control when all you've got is the remote SDP.

I really don't think that is a valid argument.  As you observe
congestion, you alter what you send.  Preferably toward sending fewer
bits.  That might result in sending nothing at all for some streams
(which would be one value for "fewer bits").

SDP describes the envelope within which you operate, that's all.
Neither plan A nor plan B expressly state that SDP is expressing
constraints on how a sender might alter their behavior in response to
congestion signals.

Think of it this way: I will simulate 100% packet loss to satisfy a
need to alleviate congestion, if there are no other options available.
 After all, that's what happens if I let congestion worsen.  There is
nothing an API, or SDP, can do to stop me from doing that.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Jun 2013 13:26:24 -0700

On 10 June 2013 12:16, Bernard Aboba <[email-masked]> wrote:
> " No O/A is request to stop sending RTP packets on a given stream. "

With my Fluffy-filter on, I read that as saying: "No O/A is *required*
to stop sending RTP packets..."

> [BA]  So you're saying that you don't expect a=sendrecv/recvonly/sendonly to
> be used in Plan A to control streams described by individual m lines?    I
> had assumed that the O/A behavior described in RFC 3264 Sections 5.1 and 6.1
> would apply in Plan A.

I didn't infer anything like that.  I think that there is a distinct
difference between negotiating the possible existence of a stream and
requiring the existence of a stream.  When you use a=sendonly/etc...
you open the possibility of receiving the stream, which in most cases
will be fulfilled.  In a congestion scenario, the sender can (and
should) stop sending.

After all, the envelope established by SDP never excludes the
possibility that zero packets arrive.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 11 Jun 2013 15:00:37 +0900

> to stop sending RTP packets..."

yes, that is what I meant - sorry

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 11 Jun 2013 15:10:49 +0900

On Jun 11, 2013, at 4:16 AM, Bernard Aboba <[email-masked]> wrote:

> [BA]  So you're saying that you don't expect a=sendrecv/recvonly/sendonly to be used in Plan A to control streams described by individual m lines?    I had assumed that the O/A behavior described in RFC 3264 Sections 5.1 and 6.1 would apply in Plan A.  
>  

Bernard - do you really think the "a=sendrecv/recvonly/sendonly " is how we do congestion control for VoIP? I don't think that is the approach that WeRTC will take to congestion control. Of course "a=sendrecv/recvonly/sendonly  are part of SDP but they are not how anyone other than you has proposed to do congestion control. I think you would agree they would be a pretty non optimal way to do congestion control.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 11 Jun 2013 03:05:28 -0700

VoIP typically doesn't use layered coding or simulcast. Also, earlier there was a discussion of using signaling vs. Magnus' codec operation point to control resolution, which in the case of spatial scaling would involve addition or removal of layers - and as I recall, signaling won.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Jun 2013 11:16:11 -0700

On 11 June 2013 03:05, Bernard Aboba <[email-masked]> wrote:
> Also, earlier there was a discussion of using signaling vs. Magnus' codec operation point to control resolution, which in the case of spatial scaling would involve addition or removal of layers - and as I recall, signaling won.

I wasn't there for that discussion, but I can imagine that that
conclusion might have been not representative for a number of reasons.
 When you talk about "addition", then I believe that signaling is
necessary (unless that was already allowed in the session description
somehow).  However, removal isn't so clear cut.  "Removal" might be a
permanent thing, in which case, an argument could be made for
signaling.  Where "removal" is just stopping transmission due to
congestion (or other transient conditions), then I don't think that
that signaling is appropriate.

The objections to COP might also have been influenced by the IPR
declarations on the document.

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 12 Jun 2013 18:00:32 -0400

Greetings

Below you will find the WebEx information for joining the MMUSIC Virtual 
Interim meeting on June 17, 2013 from 7 am to 10 am Pacific Time. If you 
have not used WebEx before, you may want to join 5 minutes early.

Thanks

-- Flemming

Topic: MMUSIC Virtual Interim
Date: Monday, June 17, 2013
Time: 10:00 am, Eastern Daylight Time (New York, GMT-04:00)
Meeting Number: 201 541 762
Password: mmusic

-------------------------------------------------------
To join the meeting online(Now from mobile devices!)
-------------------------------------------------------
1. Go to 
https://ciscosales.webex.com/ciscosales/j.php?ED=229251857&UID=2458&PW=NMDA5Mzg5NzVj&RT=MiMxMQ%3D%3D 

2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: mmusic
4. Click "Join".
5. If the meeting includes a teleconference, follow the instructions 
that appear on your screen.

-------------------------------------------------------
To join the audio conference only
-------------------------------------------------------
To receive a call back, provide your phone number when you join the 
meeting, or call the number below and enter the access code.
Call-in toll-free number (US/Canada): +1-866-432-9903
Call-in toll number (US/Canada): +1-408-525-6800
Global call-in numbers: 
https://ciscosales.webex.com/ciscosales/globalcallin.php?serviceType=MC&ED=229251857&tollFree=1 

Toll-free dialing restrictions: 
http://www.webex.com/pdf/tollfree_restrictions.pdf

Access code:201 541 762

CCP:+14085256800x201541762#

IMPORTANT NOTICE: This WebEx service includes a feature that allows 
audio and any documents and other materials exchanged or viewed during 
the session to be recorded. By joining this session, you automatically 
consent to such recordings. If you do not consent to the recording, 
discuss your concerns with the meeting host prior to the start of the 
recording or do not join the session. Please note that any such 
recordings may be subject to discovery in the event of litigation.

-------- Original Message --------
Subject: 	MMUSIC Working Group Virtual Interim Meeting, June 17, 2013
Date: 	Thu, 30 May 2013 11:56:19 -0700
From: 	IESG Secretary <[email-masked]>
Reply-To: 	<[email-masked]>
To: 	IETF Announcement List <[email-masked]>
CC: 	<[email-masked]>

Greetings,

Thanks