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

Emil Ivov <emcho@jitsi.org> Wed, 05 June 2013 16:57 UTC

Return-Path: <emil@sip-communicator.org>
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 545D221F9C27 for <mmusic@ietfa.amsl.com>; Wed, 5 Jun 2013 09:57:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
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 jAKlShVFeFnE for <mmusic@ietfa.amsl.com>; Wed, 5 Jun 2013 09:57:41 -0700 (PDT)
Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id DFCE421F9C0D for <mmusic@ietf.org>; Wed, 5 Jun 2013 09:57:40 -0700 (PDT)
Received: by mail-we0-f182.google.com with SMTP id w58so1532917wes.13 for <mmusic@ietf.org>; Wed, 05 Jun 2013 09:57:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 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=zVKO0bI606Tewurk8DD0oS5f8wGNCpWRZPOwtN/I0vg=; b=OnDJR/UL3vdRZw/DdUFevRDFFnpvaAi7yhfkO/fmIJ5cOfQD4bMRPycJwl0eMNT0VI zXYI3VUrG4J4CxncLzYiWKs8u/+Ts32wY7tU7LnS0ZH9SSpNAIdhuOYuwmLZ+zRi8qGk TOPAJM4u64GxjX5xwKZK9gOLKizklqJg9jJgTWqRuPMjgAbGCA0TfvY4GOl010G1AGjh RrqzTzms2H/0P8ebO6thoU8K8qg6AiFTFnr9EXAbibN1WyyLNg6+IvkQvpaRKif/MJqF Peu72q28QIFA9y/9P0sMZwpkH1d598Y4tUcQf7bj9ufGYgz5WiRvHdg9ruJXo9wpPW2o 01vA==
X-Received: by 10.180.126.101 with SMTP id mx5mr7591664wib.48.1370451460011; Wed, 05 Jun 2013 09:57:40 -0700 (PDT)
Received: from camionet.local ([2a01:e35:2e2c:f600:e8e0:6906:8f54:99d8]) by mx.google.com with ESMTPSA id fb9sm4661594wid.2.2013.06.05.09.57.38 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Jun 2013 09:57:39 -0700 (PDT)
Message-ID: <51AF6E02.1090902@jitsi.org>
Date: Wed, 05 Jun 2013 18:57:38 +0200
From: Emil Ivov <emcho@jitsi.org>
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: Paul Kyzivat <pkyzivat@alum.mit.edu>
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> <51AF6A2F.7000601@alum.mit.edu>
In-Reply-To: <51AF6A2F.7000601@alum.mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQkC475dHsvYte22jdrzYs+5Qiww8DFJ5dXsyAdAo8geR7zjvBuJm7XHc1op9G8YT7+0M/SD
Cc: mmusic@ietf.org
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:57:42 -0000

Hey Paul,

On 05.06.13, 18:41, Paul Kyzivat wrote:
> 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.

Bringing this back into context:

* I made a request that No Plan be considered for the agenda of the 
MMUSIC virtual interim.

* Flemming responded to my request asking exactly what it was that No 
Plan was seeking from MMUSIC.

* I responded that while No Plan is mostly a user of MMUSIC products 
(such as SDP and BUNDLE) and while it is unlikely to have major impact 
on these products, on that point it was pretty much in the same boat as 
Plan A and Plan B.

So, my main point was that No Plan should be considered a legitimate 
citizen of the pending virtual interim.

Emil
>
> 	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
>>>> .
>>>>
>>>
>>>
>>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

-- 
https://jitsi.org