Re: [MMUSIC] BUNDLE: Splitting a BUNDLE

"Cullen Jennings (fluffy)" <fluffy@cisco.com> Tue, 21 May 2013 14:53 UTC

Return-Path: <fluffy@cisco.com>
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 1E22821F981F for <mmusic@ietfa.amsl.com>; Tue, 21 May 2013 07:53:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.274
X-Spam-Level:
X-Spam-Status: No, score=-110.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 dRlQrgtDbsSc for <mmusic@ietfa.amsl.com>; Tue, 21 May 2013 07:53:09 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id E671A21F93FC for <mmusic@ietf.org>; Tue, 21 May 2013 07:53:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1747; q=dns/txt; s=iport; t=1369147989; x=1370357589; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6jf0DSF7gwiWx3sihjYF+GJI5iWskO8QowV1HdnuZuY=; b=Nf299aTU75rCQncPediwKcFkACqFbCJNOHmcmbKQKl4k8Pz9ZU7mUCIG 39308KGWYa/2i6Az88U0EJ7Y7lhDYi27M9I7RtJRhFSotlkHGP3kV4HMK /uUmWCTRmqHMsz12tWerOOOctDCUaBU8plneG2g/m2Xs9xMcTp+99dI+a 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqsFAK6Jm1GtJV2a/2dsb2JhbABZgwgwwU+BCRZ0giMBAQEDAQEBAWsLBQsCAQgiJCcLJQIEDgUIh38GDLtLBI5nAjEHgnNhA6h4gw+CJg
X-IronPort-AV: E=Sophos;i="4.87,714,1363132800"; d="scan'208";a="213155389"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 21 May 2013 14:53:08 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4LEr8Tp031314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 May 2013 14:53:08 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Tue, 21 May 2013 09:53:08 -0500
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Thread-Topic: [MMUSIC] BUNDLE: Splitting a BUNDLE
Thread-Index: AQHOVjLn86nzEMbNPE6ReEDVN9O7LQ==
Date: Tue, 21 May 2013 14:52:54 +0000
Message-ID: <C5E08FE080ACFD4DAE31E4BDBF944EB113508B39@xmb-aln-x02.cisco.com>
References: <7594FB04B1934943A5C02806D1A2204B1C36F22F@ESESSMB209.ericsson.se> <519103E1.8030200@alum.mit.edu> <201305132353.r4DNrTrr4646686@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C3700A9@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C3700A9@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.20.249.164]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <B27CCD1DE8BA4B45B1BAD1A512C7DBEE@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>
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: Tue, 21 May 2013 14:53:14 -0000

On May 14, 2013, at 6:01 AM, Christer Holmberg <christer.holmberg@ericsson.com> 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 b>
>>> 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.
>> 
>> I agree with Paul here.
> 
> Me too :)
> 
>> Allowing a new group (bundle) to be created in an answer is a much larger deviation from RFC 5888 than allowing an m= line with a zero port to be in a group, and the accept/reject problem can't be solved.
> 
> Note that there are two cases:
> 
> 1) A new bundle is created in the answer
> 
> 2) An m- line is moved from bundle_x in the offer to bundle_y in the answer. bundle_y was also present in the offer, so it is not created by the answerer.
> 
> In my opinion 2) should not be allowed either, as the m- line was not present in bundle_y in the offer.
> 

Agree with you and to say more …

I think that both 1 and 2 should *not* be allowed. There is no use case to drive needing them and it is complicated. That can be done with a new offer if needed. 


> Regards,
> 
> Christer
> 
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic