Re: [MMUSIC] BUNDLE: Splitting a BUNDLE

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 13 May 2013 15:16 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 1300021F872E for <mmusic@ietfa.amsl.com>; Mon, 13 May 2013 08:16:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.377
X-Spam-Level:
X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[AWL=0.060, 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 OjZuVpB0qRVK for <mmusic@ietfa.amsl.com>; Mon, 13 May 2013 08:16:51 -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 E5D8321F944C for <mmusic@ietf.org>; Mon, 13 May 2013 08:16:50 -0700 (PDT)
Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta12.westchester.pa.mail.comcast.net with comcast id bPHQ1l00117dt5G5CTGq4f; Mon, 13 May 2013 15:16:50 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id bTGp1l01F3ZTu2S3ZTGqqS; Mon, 13 May 2013 15:16:50 +0000
Message-ID: <519103E1.8030200@alum.mit.edu>
Date: Mon, 13 May 2013 11:16:49 -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: <7594FB04B1934943A5C02806D1A2204B1C36F22F@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C36F22F@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1368458210; bh=uhXwwpLZeTmRWcl/jKES+Nuw2/8KFlIXvsQqEWYO8j8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=SKqfJCyBOOdBt8X9O4dE8ryh/dxS2kXLza763t8Z5/VMXurVEyRiXCiWJ2lZegHxm Zrcw/+NdL9FFbogFAd3hG8REqgUeLITbwCMPYg7mTWebk92j81Z9aLsbWBiZ7GVYoL ee9GY1GQXjwE0td1JtOe1fXOGHzvWcNksNHnsbITRr173FPmX5W4LrosAzux5QVm2I BhcZUA869FPH07Kn7o6V2CTMS6i6+mraL0fAi8cCPqsnQ3Ok4uXEXMgYH/BbRGy7g5 1BSFd9bFAFT1YiGvY1820IVmMn0b9WNk2fX/Gid4r6Ukmn2UD65CDfh87bALDNJ9ax HGQRRzKrE17cQ==
Subject: Re: [MMUSIC] BUNDLE: Splitting a BUNDLE
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: Mon, 13 May 2013 15:16:57 -0000

On 5/13/13 7:58 AM, Christer Holmberg wrote:
> Hi,
>
> We seem to have an agreement that, when an SDP offer contains an m- line
> associated with a bundle group, it is ok to leave that m- line outside
> the bundle group in the SDP Answer.
>
> Now, there has been some discussions about “splitting” a BUNDLE, meaning
> that an m- line in an SDP Answer is added to a DIFFERENT bundle group
> than in the SDP Offer.
>
> Based on the discussions, it seems like people would be ok to NOT allow
> that. If the SDP Answerer wants to put an m- line in another bundle
> group, it needs to first reply to the SDP Offer, and then send a new SDP
> Offer itself, putting the m- line in the bundle group it wants.
>
> In short, is basically means: in an SDP Answer, an m- line must only be
> bundle grouped with the same m- lines (or, a subset of those) as in the
> associated SDP Offer.

Yes, this is the conclusion I reached. I wish it weren't true. But I 
think there must be a mechanism for the new bundle to be rejected, and 
if it is first proposed in the answer then that isn't possible.

IMO this is a rare enough case that suffering another O/A is acceptable.

	Thanks,
	Paul