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

[Paul Kyzivat <[e-mail]>]

On 6/5/13 6:37 AM, Emil Ivov wrote:
> 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:

???

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

> 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
>
> On 05.06.13, 06:44, Flemming Andreasen wrote:
>>
>> On 6/4/13 10:41 PM, Bernard Aboba wrote:
>>> 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.
>> 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
>>
>>> On Jun 4, 2013, at 7:29 PM, "Flemming Andreasen" <[e-mail]>
>>> wrote:
>>>
>>>> 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
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>> _______________________________________________
>>>> mmusic mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>> .
>>>
>>
>>
>