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

Emil Ivov <emcho@jitsi.org> Fri, 14 June 2013 21:54 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 D3ED821F9A41 for <mmusic@ietfa.amsl.com>; Fri, 14 Jun 2013 14:54:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.525
X-Spam-Level:
X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, 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 KuOnoRFJm2yp for <mmusic@ietfa.amsl.com>; Fri, 14 Jun 2013 14:54:28 -0700 (PDT)
Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 0631E21F9A24 for <mmusic@ietf.org>; Fri, 14 Jun 2013 14:54:27 -0700 (PDT)
Received: by mail-we0-f174.google.com with SMTP id q58so892173wes.5 for <mmusic@ietf.org>; Fri, 14 Jun 2013 14:54: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=0p2IB1P6cKzGPaHMYZLmFb+5TiyOKHN978PvqFtDbs4=; b=PaFD6zu1aF2E6AxAvZbbEusdiDmgGhWvBiRn62YnhsZ/Kj5emciqSlc8kob2v//jCJ 4xvNU8Bre9jh6NwcWnOZyUaMlSwskiLFa6gGVXJzHYh+nh3T/l799vyxZmXLN8iVUWht 2tEykhJWxXn0p6u0k4AdAUCBaowMYCuFRpIodVqk8GHz+DUyCQfryTLYvc38ZYbcFKnE NzMLtu5LBnHuUAiUUJdK+yfFmoyF7fbiDfnVH5BNE6vpsH7x9UzXyYN/HGRhUQheDVth ZPB9GFEaB8vSk3toO7M/CB4bGxOhVxY5f/3cRaxEHuKpS3gzTBcZfmicz5ExpPZJEq/p /N6Q==
X-Received: by 10.180.83.166 with SMTP id r6mr35726wiy.60.1371246867069; Fri, 14 Jun 2013 14:54:27 -0700 (PDT)
Received: from camionet.local ([2a01:e35:8a55:abc0:4d80:ba75:137c:dc46]) by mx.google.com with ESMTPSA id ft10sm6087279wib.7.2013.06.14.14.54.25 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Jun 2013 14:54:26 -0700 (PDT)
Message-ID: <51BB910F.404@jitsi.org>
Date: Fri, 14 Jun 2013 23:54:23 +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> <51BB82C5.3020400@jitsi.org> <51BB880B.1010502@cisco.com>
In-Reply-To: <51BB880B.1010502@cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQkgJ1OZvzEgqsbCrykZeO0wjHRWx+Kt29uercSHyUrtWnK2ikRWmuRql9BvKlxXDbs59HXY
Cc: =?windows-1252?Q?Ari_Ker=E4nen?= <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 21:54:28 -0000

On 14.06.13, 23:15, Flemming Andreasen wrote:
>>> 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?
>>
> I don't believe it is or should be a plan-specific discussion, so no.

Could we then maybe have that discussion scheduled in the agenda, 
please? Right now it seems to only contain points specific to Plan A or 
Plan B.

>>> 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?
>>
> Because "no plan" doesn't seem to be asking MMUSIC to do anything

The thing that No Plan really needs from MMUSIC is to validate the way 
it uses m= lines for multiple RTP flows. If we can make sure that this 
is discussed (independently of how streams will be accepted and 
rejected) then I am fine.

Thanks,
Emil


-- 
https://jitsi.org