Re: [MMUSIC] 10 BUNDLE questions

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 24 April 2013 13:44 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 1DCB521F89B2 for <mmusic@ietfa.amsl.com>; Wed, 24 Apr 2013 06:44:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.011
X-Spam-Level:
X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_55=0.6, 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 rVzxGRZ-jXHZ for <mmusic@ietfa.amsl.com>; Wed, 24 Apr 2013 06:44:29 -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 30FBC21F8976 for <mmusic@ietf.org>; Wed, 24 Apr 2013 06:44:28 -0700 (PDT)
Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta12.westchester.pa.mail.comcast.net with comcast id Tpi71l0081ei1Bg5CpkTKM; Wed, 24 Apr 2013 13:44:27 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id TpkT1l00Q3ZTu2S3kpkThn; Wed, 24 Apr 2013 13:44:27 +0000
Message-ID: <5177E1BB.3010708@alum.mit.edu>
Date: Wed, 24 Apr 2013 09:44:27 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: mmusic@ietf.org
References: <CAOJ7v-0tr6_HAPwOnLD_De-LkNCsj1EfLhZL=G_B=k5tz9Hkwg@mail.gmail.com> <C5E08FE080ACFD4DAE31E4BDBF944EB11348F0AF@xmb-aln-x02.cisco.com> <CABkgnnU1XW4vgC3rW-2DB15yMgc4GkhwQvYOuxmvBE4+9k0pDA@mail.gmail.com> <C5E08FE080ACFD4DAE31E4BDBF944EB113494A47@xmb-aln-x02.cisco.com>
In-Reply-To: <C5E08FE080ACFD4DAE31E4BDBF944EB113494A47@xmb-aln-x02.cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366811068; bh=/bVF59iiXBDE0AHd9+wGIrRLj4zvt5oJm7cGQRuvH5o=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rnbGmuGs+rGzL1BL9u8oRK+icQ8RfFpg3wMIftVR/ckCfG/404A5WThnf83eNQFv2 J1Duf7FTQY/Gb7xVGxVTVuHagMwJ2ObPDLXVLmVU1abD3OosQPxw0WYog/Lexh+C7W i8z1dcwrOB5ycbbcf7gUIJ2NnUJFNF7huIkzf52xq6ePQUFKa2S2TdB0dBPRpKULXE bVjeRjOjSUN2wXncJLQ7F5BuVAYBwnItnEz2qLBcQr6fsgaYnASlqhBZftR936djcm pNb7umZCwgsGKoNWQ7xD1/SEMW8KV+olYZT1ZfLXpz9FzpfHJ86YFjLM4wz5HphOla jYNivyZtB4fqg==
Subject: Re: [MMUSIC] 10 BUNDLE questions
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, 24 Apr 2013 13:44:30 -0000

On 4/22/13 11:25 AM, Cullen Jennings (fluffy) wrote:

[snip]

>>> Also imagine case where
>>>
>>> Alice offers A, B, and C and offers to bundle them all
>>>
>>> Bob wants to accept A and B in a bundle and C separate
>>>
>>> When I talked to Justin this, I was convinced we don't want to bother to support this as it complicated gathering ports for future offers. So what it comes down to the device receive the offer can either accept the bundle or not. (and separate accept or reject each m line in the bundle but can't refactor the bundling).
>>
>> This is actually the same sort of problem as the above.  The question
>> is whether the bundle is negotiated as a whole, or whether answers can
>> differentiate on per-line basis.  I can appreciate the desire to
>> simplify, but you have to examine use cases.
>>
>> Example: Alice offers A and B bundled, Bob accepts the bundling.
>> Later, Alice adds C to the bundle.  How can Bob get that m= line
>> routed over a different path?  Do we require that Bob reject the line
>> and offer the same line, potentially inverted, without bundling in a
>> subsequent offer?
>>
>> I'm thinking here about a case where a session escalates from audio to
>> audio+video and there might be a middlebox involved.  I guess in that
>> case the middlebox needs to drive the addition.
>>
>> I can probably live with the simplification, but this needs to be
>> crystal clear.  A more complete discussion of the implications of this
>> particular choice would be really helpful.
>
> +1 on we need to be crystal clear.
>
> I think I am leaning towards once a bundle is set up, a new update to it can offer things in the bundle or not it the bundle. And if offered in the bundle, the answer can choose to put it in the bundle or not. But I want to avoid all things like the answer can move a m-line from one one bundle to another bundle or something like that. It's too complicated and I don't see the need for it.

This is a subcase of "splitting" a bundle, which I posted on earlier:

http://www.ietf.org/mail-archive/web/mmusic/current/msg10683.html

IMO it *must* be permissible to accomplish this in some way.
For the case of splitting one bundle into two bundles, I concluded that 
it will take another O/A. Just leaving some of the proposed bundle 
candidates out of single bundle seems to be acceptable to 5888. I see no 
reason to circumvent that for bundle groups.

The second o/a I proposed for splitting a bundle would not be allowed by 
what the two of you are proposing. There are real use cases for this, 
where the offerer processes all the streams at a single network access 
point, but the other endpoint processes them at multiple access points.

	Thanks,
	Paul