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

Flemming Andreasen <> Thu, 06 June 2013 01:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D42F821F944C for <>; Wed, 5 Jun 2013 18:03:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XcVl5MXaZv47 for <>; Wed, 5 Jun 2013 18:03:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1444521F9425 for <>; Wed, 5 Jun 2013 18:03:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=8302; q=dns/txt; s=iport; t=1370480605; x=1371690205; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Xe0RPFWSZvd/AxUTV3dy6RflDin3TocBiAuyYRix2Ao=; b=aYCqOPu1vIfWv0JyKwL03YungapOSyST0NpAA/oDZ1a2u/hKaZCKdlPh LEVbrngzB5FBJafB+vj9bAJ4yNZKDNMALI2eUtUuJE2A6NOSq+mLoxmmY KUO1zadsvEdI+LrWHMPS2Kszm0V6bOCqL4M6skc0e+jyvQv58lLaLql1N Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.87,810,1363132800"; d="scan'208";a="79832264"
Received: from ([]) by with ESMTP; 06 Jun 2013 01:03:24 +0000
Received: from Flemmings-MacBook-Pro.local ([]) by (8.14.5/8.14.5) with ESMTP id r5613NjP003139; Thu, 6 Jun 2013 01:03:23 GMT
Message-ID: <>
Date: Wed, 05 Jun 2013 21:03:23 -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: Emil Ivov <>
References: <> <> <> <BLU403-EAS336A4AA94CDB5E97170F9A5939F0@phx.gbl> <> <>
In-Reply-To: <>
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: Thu, 06 Jun 2013 01:03:40 -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:
> 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.
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:
    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.


    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.

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 
> question?
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 

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


-- Flemming

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