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

Paul Kyzivat <> Fri, 03 May 2013 20:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6574821F9164 for <>; Fri, 3 May 2013 13:25:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RbIbDct9XJx9 for <>; Fri, 3 May 2013 13:25:51 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:48]) by (Postfix) with ESMTP id ACFCB21F8EC2 for <>; Fri, 3 May 2013 13:25:51 -0700 (PDT)
Received: from ([]) by with comcast id XUNQ1l0010EZKEL55YRqqC; Fri, 03 May 2013 20:25:50 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id XYRq1l00X3ZTu2S3MYRqme; Fri, 03 May 2013 20:25:50 +0000
Message-ID: <>
Date: Fri, 03 May 2013 16:25:48 -0400
From: Paul Kyzivat <>
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 <>
References: <>, <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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: "" <>
Subject: Re: [MMUSIC] BUNDLE: Accept m- line, reject bundle
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.