Re: [MMUSIC] 10 BUNDLE questions

Paul Kyzivat <> Mon, 22 April 2013 16:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C61521F93BA for <>; Mon, 22 Apr 2013 09:47:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 XaF8tje5NcUk for <>; Mon, 22 Apr 2013 09:47:11 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:24]) by (Postfix) with ESMTP id 4CF7621F93B7 for <>; Mon, 22 Apr 2013 09:47:05 -0700 (PDT)
Received: from ([]) by with comcast id T1pX1l0091YDfWL514n5CT; Mon, 22 Apr 2013 16:47:05 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id T4n51l0093ZTu2S3g4n5TT; Mon, 22 Apr 2013 16:47:05 +0000
Message-ID: <>
Date: Mon, 22 Apr 2013 12:47:04 -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
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1366649225; bh=Eyg/tEU7lXZIH6xsQtLcJx8oBiFDwluukmgfTcf/ZOM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=YsPNG7OWIfy29GQ+XpPBB/WC8r/8Yzfz+/SZCY8TIn8ymgYjHvQrjxkqzGMItR0KA Cg9BNDPdhjp1O8sT7T52v0twLlmYppBo/E2KbQfoDFZmZYe+VYJNEi6XRaYPWbw+0H lrXCHKKtPbiYeSPrSzbrv+dB7sSK8ZWcSzbQ9qpj7KipNHgPNGXjxWd2Dt9l73N6RU ZI7+RlCWnzdQGERTP/L+SdPBTayhJGXoFzVcrhtdzrI8HSIbWRas0h6TbB5yUk4F1/ HeGez5z2sl/RNvu4VltvZlERA0rKunF6ayPu05d43Y7s+LgA3PDSTfQKFzFa3/vB2S 8iVr3cMzRGgiQ==
Subject: Re: [MMUSIC] 10 BUNDLE questions
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: Mon, 22 Apr 2013 16:47:12 -0000

On 4/19/13 12:19 PM, Cullen Jennings (fluffy) wrote:
> On Mar 15, 2013, at 2:51 PM, Justin Uberti <> wrote:
>> The list below is a set of questions (some marked as OPEN ISSUE already) regarding the new BUNDLE proposal. If you agree with my suggested answers, I'm willing to contribute text accordingly.
>> 	• Can you create a BUNDLE with a single m= line? (assuming yes)
> yes, have to to add more later
>> 	• Can you create multiple BUNDLEs? (assuming yes)
> yes but a given m line can only be in one
>> 	• When creating an initial offer, how should we deal with the case where a "null" port is to be used with trickle ICE (since 6.1:1 indicates the ports MUST be different)
> I think we should change bundle to allow the null port
> - it really needs to be all the parameters related to transport / crypto need to be different, or at least as different as they would be required to be if you were not doing bundle. Key thing is if other side does not understand bundle, this looks like an "normal" offer with no bundle.

When you say "null" port, do you mean *zero* port?

There is a technical problem with this. RFC5888, section 9.2, says:

    SIP entities refuse media streams by setting the port to zero in the
    corresponding "m" line. "a=group" lines MUST NOT contain
    identification-tags that correspond to "m" lines with the port set to

This means you can't initially establish a bundle group including 
m-lines with zero ports and then negotiate a non-zero port later. To 
work around this we would either need to use some other port (e.g. 9 - 
discard) to indicate no media is initially to be sent, or else change 
RFC5888. Even then it would be necessary to change allow bundle to allow 
multiple bundled m-lines to have the same port in this case.

>> 	• If m= lines are rejected, should their mids show up in the BUNDLE answer? (assume yes?)
> don't care but we need to be clear should happen.

See above. This is currently specified by 5888. IMO what is specified by 
5888 is unfortunate. I'm undecided whether its better to try to work 
around it or change it.

>> 		• If not, how does remote side indicate BUNDLE support if it rejects the m= lines that are BUNDLEd?
>> 	• Is there any way, in a single PeerConnection, to unBUNDLE m= lines that were previously BUNDLEd (assume no)
> In SIP terminology, I think we would do this with an "INVITE with replaces". If you want to do this, you just start a whole new offer that is not an evolution of the previous set of offer/answers. So basically I am saying not to do this at the bundle level but instead support it at the signaling level.

IMO it would be better to allow bundling to be changed in a subsequent 
O/A, just as anything else it.

>> _______________________________________________
> 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 a subcase of "splitting" a bundle, which I posted on earlier:

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.