Re: [MMUSIC] BUNDLE: Accept m- line, reject bundle

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 03 May 2013 20:25 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 6574821F9164 for <mmusic@ietfa.amsl.com>; Fri, 3 May 2013 13:25:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.162
X-Spam-Level: *
X-Spam-Status: No, score=1.162 tagged_above=-999 required=5 tests=[AWL=1.599, 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 RbIbDct9XJx9 for <mmusic@ietfa.amsl.com>; Fri, 3 May 2013 13:25:51 -0700 (PDT)
Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id ACFCB21F8EC2 for <mmusic@ietf.org>; Fri, 3 May 2013 13:25:51 -0700 (PDT)
Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta05.westchester.pa.mail.comcast.net with comcast id XUNQ1l0010EZKEL55YRqqC; Fri, 03 May 2013 20:25:50 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id XYRq1l00X3ZTu2S3MYRqme; Fri, 03 May 2013 20:25:50 +0000
Message-ID: <51841D4C.7080404@alum.mit.edu>
Date: Fri, 03 May 2013 16:25:48 -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: Christer Holmberg <christer.holmberg@ericsson.com>
References: <7594FB04B1934943A5C02806D1A2204B1C36B4F6@ESESSMB209.ericsson.se>, <5183D141.7060607@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C36B87D@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C36B87D@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367612750; bh=IdID2scVzpR2iP/Sv4/u+0R/dlbkqG8giKpPbVKXad4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Hb3Qf0WoVx6s3t5u3TYf70A0taG9QpCWxTMHgyqX5wulHaYa4J3gtgYhLjHmWptsC yRo8Lk1atmqcaRD4nCljqh7fLxa5KPtA6OT5stJ9ztLIdY0aT+0+pFdfJp5hoe0EI7 OOBWZpEsy/9LagfZ8QRTb1zDw91b6fIkQKctvElLOxmRlDHXiMSH00Y8Zv9V24nH5K wSRZlKnJm1QrCB60ZFytJYTadeWwmzWWDcGDQDRbw+1ugoxmukbeoEb7rLz8RoBGL9 FyNGbdnclcj7jIGjJZskAsUtRvUS0B/ugRI2Oa0WCmcrY8A139gYohrU3mRdj9ShkB /jHKwjYjxRQfw==
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] BUNDLE: Accept m- line, reject 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: Fri, 03 May 2013 20:25:57 -0000

On 5/3/13 4:03 PM, Christer Holmberg wrote:
>
> Hi,
>
>>> Assume the following case:
>>>
>>> 1.An SDP offer contains an m- line associated with a BUNDLE group
>>>
>>> 2.The answerer wants to accept the m- line, but wants to reject it being
>>> in the specific BUNDLE group.
>>>
>>> A few alternatives on how this could be achieved have been presented:
>>>
>>> Alt 1.      The answerer accepts the m- line, but does not associate it
>>> with a BUNDLE group.
>>>
>>> Alt 2.      The answerer accepts the m- line, associates it with a
>>> BUNDLE group, and then sends a new offer which removes the m- line from
>>> the BUNDLE group.
>>>
>>> Alt 3.      The answerer rejects the m- line, and then sends a new offer
>>> which adds the m- line outside a BUNDLE group.
>>>
>>> In my opinion, Alt 1 does not work, at least not if the offer contains
>>> identical port values for the m- lines associated with the BUNDLE group.
>>> It would mean that the m- line is not added to a BUNDLE group, but still
>>> has the same port value (at least at the offerer side) as the m- lines
>>> in the BUNDLE group, which is not allowed.
>>>
>>> So, my suggestion would be to specify that the answerer must use Alt 2
>>> and/or Alt 3.
>>
>> I don't think we should restrict flexibility here when it works and
>> makes sense.
>>
>> I agree that Alt 1 doesn't work *if* the m-line in question shares
>> addr/prot with other m-lines that are also accepted, bundled or not. But
>> the normal first offer won't present that situation. If the addr/port in
>> the m-line in question is unique among all the accepted m-lines, then
>> this should be acceptable.
>>
>> (Note, this is a degenerate case of bundle splitting. There are real use
>> cases for it. If it can be done without a 2nd o/a, then lets allow that.)
>
> I was thinking that, by not allowing it, we could have a general rule saying something like:
>
> "If an m- line in an offer is associated with a BUNDLE group, it MUST be associated with a BUNDLE group in the associated answer, unless the answerer sets the port value to zero."

Is the goal to minimize the number of words in the draft? :-)

I think this would be eliminating a scenario with practical utility.
And allowing it doesn't make the implementation significantly harder.
(The offerer must be prepared for the whole bundle to be rejected. This 
is a variant of that. For the m-lines that are removed from the bundle 
it is as if the bundle had been rejected. For the other m-lines it is as 
if the bundle had been accepted.

	Thanks,
	Paul