Re: [MMUSIC] 10 BUNDLE questions

Harald Alvestrand <> Sun, 17 March 2013 08:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 763E021F877B for <>; Sun, 17 Mar 2013 01:01:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.598
X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j0aIh2Kx4yTW for <>; Sun, 17 Mar 2013 01:01:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5E59521F877A for <>; Sun, 17 Mar 2013 01:01:54 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C4FC39E1BB for <>; Sun, 17 Mar 2013 09:01:53 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ft4C6sphvk7j for <>; Sun, 17 Mar 2013 09:01:52 +0100 (CET)
Received: from [IPv6:2001:470:de0a:27:8470:250e:fe3c:a2a6] (unknown [IPv6:2001:470:de0a:27:8470:250e:fe3c:a2a6]) by (Postfix) with ESMTPSA id D9E3B39E029 for <>; Sun, 17 Mar 2013 09:01:51 +0100 (CET)
Message-ID: <>
Date: Sun, 17 Mar 2013 09:01:51 +0100
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------020706010509070101060305"
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: Sun, 17 Mar 2013 08:01:55 -0000

On 03/15/2013 09: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.
>  1. Can you create a BUNDLE with a single m= line? (assuming yes)
>  2. Can you create multiple BUNDLEs? (assuming yes)
>  3. 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)
Tangential, sort of - when creating an initial offer, when would one 
need to use a null port?
We're creating the offer, if we don't want the m-line, we can omit it 
(This was one of the things that simplified the problem when Christer, 
Cullen and I were discussing this version).

>  1. From 6.1, list 1 - are conditions 2, 5, 7 really necessary? (MUST
>     use same c=, add rtcp-mux, same a=fingerprint)
>  2. From 6.1, list 2 - is condition 6 right? Why would we use
>     different SDES keys for a single RTP session?
Having the same SDES keys for two RTP sessions runs the risk of a 
two-time pad attack, I think (needs some other things to be the same 
too, but I don't think there's a guard against that anywhere). So this 
is a fatal flaw if the negotiation results in non-BUNDLE.

The lists could be better formatted - only 1, 3 and 4 are different 
between the lists, I think it's good to keep the differences between 
"before BUNDLE" and "after BUNDLE" minimal, but one should call out the 

>  1. If you start with a m= line with one SDES config (e.g. 32-bit
>     MAC), and then BUNDLE with another SDES line with a different (non
>     overlapping) SDES config (e.g. 80-bit MAC), what happens? (assume
>     fail)
I assume so too. This should be noted.
>  1. If the BUNDLE mids in the answer doesn't match the BUNDLE mids in
>     the offer, what happens? (assume fail)
I think this violates RFC 5888 section 9.1, so it should be a FAIL.
>  1. If you add a m= line to an existing BUNDLE, can the recipient
>     reject that BUNDLEing (assume no)
>  2. If m= lines are rejected, should their mids show up in the BUNDLE
>     answer? (assume yes?)
>      1. If not, how does remote side indicate BUNDLE support if it
>         rejects the m= lines that are BUNDLEd?
>  3. Is there any way, in a single PeerConnection, to unBUNDLE m= lines
>     that were previously BUNDLEd (assume no)

Syntactically, it's easy (omit the mid from the a=group:bundle line); 
semantically, I think it hurts my mind to think about what should happen 
in the RTP session(s) and when, so let's just outlaw it.

> _______________________________________________
> mmusic mailing list