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

Emil Ivov <> Wed, 05 June 2013 10:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EC31121F99AA for <>; Wed, 5 Jun 2013 03:37:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Lz4Q-83speH8 for <>; Wed, 5 Jun 2013 03:37:20 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::22d]) by (Postfix) with ESMTP id 8305121F9996 for <>; Wed, 5 Jun 2013 03:37:19 -0700 (PDT)
Received: by with SMTP id n12so1191862wgh.24 for <>; Wed, 05 Jun 2013 03:37:18 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=DLsorpt4oCkn/ovTm8umEuBt+fJ95sygBKe99Wi82l4=; b=fFsrB3LCRdmXc13cb9l+rZwASwMdsIi8OZspI+BhS+83+uSuoQbcqXY95xB7HZMmB2 qDysdaMNIslbGxN/F3JLa4jiTC/T/F34fZgLIrp+oGhZP/MRdag+tI7CnI5mqZHYSHMF kZRME92jx9zT+m1r5wKVns9p53AjWUf22T44uArDl9KfEwyUdiqZaJtAFGD4mAXPY1M0 3+x18I6CRDw1rl0IbdtWfjR7gP5gWyDZ3UsIsz4859ErT+o5tifgcB6hqZO1C4YY8WFZ heYGeifJQfOHa6iZNTPy56xfh3uZ2PPvLX7OUmplZJ4pExtxvOIDr4FGSC0fPZIckbMW GzrQ==
X-Received: by with SMTP id bu6mr5851708wib.34.1370428638333; Wed, 05 Jun 2013 03:37:18 -0700 (PDT)
Received: from camionet.local ( []) by with ESMTPSA id q13sm9422256wie.8.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Jun 2013 03:37:17 -0700 (PDT)
Message-ID: <>
Date: Wed, 05 Jun 2013 12:37:15 +0200
From: Emil Ivov <>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Flemming Andreasen <>
References: <> <> <> <BLU403-EAS336A4AA94CDB5E97170F9A5939F0@phx.gbl> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQkxES6Ao6qvCty/FQGO4kI4ai25NQZXIz1JweT1+C4l020XjxDawZZbzq1GcfoS4M8nHuWG
Cc: Ari Keranen <>, "" <>
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 10:37:21 -0000

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?


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
>> .