Re: [MMUSIC] MMUSIC WG June 17th virtual interim agenda

Emil Ivov <emcho@jitsi.org> Fri, 14 June 2013 20:53 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 71D4521F9A15 for <mmusic@ietfa.amsl.com>; Fri, 14 Jun 2013 13:53:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, 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 tqy2vcMOt5+M for <mmusic@ietfa.amsl.com>; Fri, 14 Jun 2013 13:53:29 -0700 (PDT)
Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id B56A021F99D4 for <mmusic@ietf.org>; Fri, 14 Jun 2013 13:53:28 -0700 (PDT)
Received: by mail-wi0-f182.google.com with SMTP id m6so678809wiv.3 for <mmusic@ietf.org>; Fri, 14 Jun 2013 13:53:27 -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=4XacaDhvvVUjuBVPQDVSZRUUvkY5UVs+t5WuDn9eOIo=; b=BEJLaxeYLwzAtb1rKun/tnbWzlKLwARQs6xueNcPQiF7sae700rFDRvXmmSpRq7Yfz m5e0dAT5iBePrezgvPFbT8WZ2x6R9eZ95zC2cw78xZ1+asqmp9V91AaicwCC1DP1e9Jl jlpH+vUEd/uewgRTXuLVk+osob9z34/4+iWEkw4Ke188QN7LxEYF0GXRMkFQwKw/X0YY 31BfkRvSht5wyPc3Cdg+2A6Phnz6yWnVgkVeQoNotVB+uJ3HAj/XNnBqoGmVJbvJwKt5 gvo+Fxn3ayuy0WgVRKi0n7g1Sas9LpZmRI3E7LrpeYu180mOuvcyXCPNcFP/0xPTbmo1 jHBA==
X-Received: by 10.194.9.101 with SMTP id y5mr2454040wja.86.1371243207636; Fri, 14 Jun 2013 13:53:27 -0700 (PDT)
Received: from camionet.local ([2a01:e35:8a55:abc0:4d80:ba75:137c:dc46]) by mx.google.com with ESMTPSA id b19sm5804869wik.10.2013.06.14.13.53.25 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Jun 2013 13:53:26 -0700 (PDT)
Message-ID: <51BB82C5.3020400@jitsi.org>
Date: Fri, 14 Jun 2013 22:53:25 +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: Flemming Andreasen <fandreas@cisco.com>
References: <51BB5EFE.5090903@ericsson.com> <51BB68B2.3060104@jitsi.org> <51BB6A8C.6090400@ericsson.com> <51BB7012.10208@jitsi.org> <51BB766D.2030301@cisco.com>
In-Reply-To: <51BB766D.2030301@cisco.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQniEq+xyiBAa/t0GrfFIfq1aH/QozUrRn0HrFIfOsnHNwTP4VgovN5gt9Q2qqevCABQXfPT
Cc: Ari Keränen <ari.keranen@ericsson.com>, mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] MMUSIC WG June 17th virtual interim agenda
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: Fri, 14 Jun 2013 20:53:30 -0000

Hey Flemming,

On 14.06.13, 22:00, Flemming Andreasen wrote:
> Hi Emil
>
> Per some of the previous discussion threads (see e.g.
> http://www.ietf.org/mail-archive/web/mmusic/current/msg11019.html),
> there is clearly some ambiguity around exactly what an m-line conveys,
> both with and without bundle. This lack of clarity potentially affects
> all of the different plan proposals as well as as 4566bis,  and as such
> is an entirely reasonable discussion to have in MMUSIC.

OK, so doesn't this mean all plans should be given equal time to discuss 
their take on this issue?

> To the extent
> that resolution of this impacts progress on the Plan A versus Plan B
> discussion, it is also an appropropriate discussion to have next week.

Sorry, I am confused again. No Plan, Plan A and Plan B demonstrate 
versions of SDP that can be used in multi-stream scenarios. Yet, for 
some reason we will only be discussing the validity of Plan A and Plan 
B's approaches.

Could you please explain why that is?

The only explanation I could find was that No Plan's SDP usage was too 
obvious and valid and there wasn't anything to discuss about it.

Just to be clear: we have been using a No Plan-like approach for Jitsi 
video conferencing for quite a long time now. I believe other popular 
vendors of conferencing solutions have been doing the same.

Cheers,
Emil

> What is not appropriate at this time however is to turn that into a
> discussion of choosing "no plan" for RTCWeb since MMUSIC cannot (and
> should not) make that decision (as clarified by the RTCWeb chairs as well).

> Thanks
>
> -- Flemming
>
>
> On 6/14/13 3:33 PM, Emil Ivov wrote:
>>
>>
>> On 14.06.13, 21:10, Ari Keränen wrote:
>>> On 6/14/13 10:02 PM, Emil Ivov wrote:
>>>> On 14.06.13, 20:20, Ari Keränen wrote:
>>>>> Hi all,
>>>>>
>>>>> Given the guidance from the RTCWEB WG chairs that the "no-plan"
>>>>> discussion should essentially happen at the RTCWEB WG, the MMUSIC
>>>>> interim meeting on June 17th will be focused on Plan A and Plan B.
>>>>
>>>> I assume this implies that MMUSIC considers it entirely appropriate to
>>>> use SDP for signalling multiple streams the way No Plan suggests (i.e.
>>>> one m= line can carry as many RTP flows as it likes). So much so, that
>>>> no further discussion is necessary on the subject.
>>>>
>>>> Could you please confirm that I am reading this properly?
>>>
>>> This means that the interim time should be used mainly to discuss plan A
>>> vs plan B merits, not whether RTCWEB should use A/B, or no-plan.
>>
>> Sure. I get this and I find it very reasonable.
>>
>> However, just as Plans A and B, No Plan says: here's an SDP that you
>> can use when doing multiple streams.
>>
>> So, I just want to confirm that we will not be discussing the SDP
>> sides of the proposal in No Plan because they make perfect sense from
>> an MMUSIC point of view and no discussion is really necessary. It'll
>> be up to other working groups to decide whether they'd like to use
>> that particular (and valid) approach.
>>
>> Emil
>>
>>
>
>

-- 
https://jitsi.org