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

Paul Kyzivat <> Wed, 05 June 2013 16:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C18E121F9B34 for <>; Wed, 5 Jun 2013 09:41:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.257
X-Spam-Status: No, score=-0.257 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DYFGWPvmblqB for <>; Wed, 5 Jun 2013 09:41:34 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:44:76:96:59:227]) by (Postfix) with ESMTP id 84EE521F9B79 for <>; Wed, 5 Jun 2013 09:41:25 -0700 (PDT)
Received: from ([]) by with comcast id kaaX1l0020bG4ec5CghLtR; Wed, 05 Jun 2013 16:41:20 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id kghL1l00Q3ZTu2S3PghLsY; Wed, 05 Jun 2013 16:41:20 +0000
Message-ID: <>
Date: Wed, 05 Jun 2013 12:41:19 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
References: <> <> <> <BLU403-EAS336A4AA94CDB5E97170F9A5939F0@phx.gbl> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1370450480; bh=WzR+4Fm/sT1OUBx1PBoWqEfPKrjReUWMqKzDCpLrqOQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=UOHqaXmP3C6U7B3e/d8tdM7TwTtuXqIHKbD7xuU+yP/Hhyj192vVFV7NlYN0YggvM wqj+cpfsOj0A/A8zdzE27j9+B5INx3S1V9j1K8tstysB6uOELU09dtRzEbAxXwQXrR 2LvHYjtM2JJbQwkPVBxNN6KO8kt01zimfA8lyPWjz4kaIdTqyJoj9Oflo+1j/L6BRM hpZ2J3rZsLCrK4Pm8mVV5FuFsHXQ3heK0nWR2/434DvIm/OcgwP1eJ62hiduCW5gr8 5gc2GqTMdnqsvhuCgUbtjj+uKvMdenmkq3C3lWyF9uYhsw9gHrgNmVDz+h+mWkUVmM qgMVzUnr/zTyw==
Subject: Re: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, June 17, 2013
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 05 Jun 2013 16:41:38 -0000

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 

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.


> 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" <>
>>> 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:
>>>> 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:
>>>>>> You may also want to look at
>>>>>> 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
>>>> _______________________________________________
>>>> mmusic mailing list
>>> .