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

Flemming Andreasen <> Wed, 05 June 2013 04:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E4F321F85E0 for <>; Tue, 4 Jun 2013 21:44:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oc37bEW8af0E for <>; Tue, 4 Jun 2013 21:44:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 54C5821F9A3C for <>; Tue, 4 Jun 2013 21:44:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3955; q=dns/txt; s=iport; t=1370407486; x=1371617086; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=T5p9FTntbKTVU0fiPpU4ywArT5HlpUKy1tyOfzYTs90=; b=P5gDwjrAgUse9gIjODljVJ8vV9HswBgeouR3bHl1LetID8i4AI0iWahs TkqZPBBPkrB8LbltivHxucNu7dUZwipUnm7AzZVeCnB7j8Sza3HKTniz2 idHc0wAJ5B3PW+W1CIcG5xomYjjl3/ge9SA9kvCqa81YOyiMoeEPVI0w5 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.87,804,1363132800"; d="scan'208";a="218975472"
Received: from ([]) by with ESMTP; 05 Jun 2013 04:44:45 +0000
Received: from Flemmings-MacBook-Pro.local ([]) by (8.14.5/8.14.5) with ESMTP id r554ihAG011480; Wed, 5 Jun 2013 04:44:44 GMT
Message-ID: <>
Date: Wed, 05 Jun 2013 00:44:43 -0400
From: Flemming Andreasen <>
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
To: Bernard Aboba <>
References: <> <> <> <BLU403-EAS336A4AA94CDB5E97170F9A5939F0@phx.gbl>
In-Reply-To: <BLU403-EAS336A4AA94CDB5E97170F9A5939F0@phx.gbl>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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 04:44:51 -0000

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 ?


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