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

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 05 June 2013 16:41 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18E121F9B34 for <mmusic@ietfa.amsl.com>; Wed, 5 Jun 2013 09:41:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.257
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYFGWPvmblqB for <mmusic@ietfa.amsl.com>; Wed, 5 Jun 2013 09:41:34 -0700 (PDT)
Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 84EE521F9B79 for <mmusic@ietf.org>; Wed, 5 Jun 2013 09:41:25 -0700 (PDT)
Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta12.westchester.pa.mail.comcast.net with comcast id kaaX1l0020bG4ec5CghLtR; Wed, 05 Jun 2013 16:41:20 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id kghL1l00Q3ZTu2S3PghLsY; Wed, 05 Jun 2013 16:41:20 +0000
Message-ID: <51AF6A2F.7000601@alum.mit.edu>
Date: Wed, 05 Jun 2013 12:41:19 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
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: mmusic@ietf.org
References: <20130530185619.4124.56395.idtracker@ietfa.amsl.com> <51A87F91.2080500@jitsi.org> <51AEA08D.8090103@cisco.com> <BLU403-EAS336A4AA94CDB5E97170F9A5939F0@phx.gbl> <51AEC23B.1010509@cisco.com> <51AF14DB.5020009@jitsi.org>
In-Reply-To: <51AF14DB.5020009@jitsi.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; 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-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=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 
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" <fandreas@cisco.com>
>>> 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
>>>>>> mmusic@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>> _______________________________________________
>>>> mmusic mailing list
>>>> mmusic@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>> .
>>>
>>
>>
>