Re: [MMUSIC] 10 BUNDLE questions

Justin Uberti <> Thu, 04 April 2013 00:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6C69C21F91BF for <>; Wed, 3 Apr 2013 17:05:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.176
X-Spam-Status: No, score=-101.176 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sddy4TuV35+q for <>; Wed, 3 Apr 2013 17:05:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3CA6121F91B8 for <>; Wed, 3 Apr 2013 17:05:56 -0700 (PDT)
Received: by with SMTP id bv4so1159427qab.2 for <>; Wed, 03 Apr 2013 17:05:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=JbQZPfOf23+JAX4M00Jkzb/tWsJPvuUOcAn2sKXt8Zg=; b=PNdvxgjV20QJuNz3is9pWivsIKSmxZXDrhduHY+ay40coGl14t4F06GJ0PMJRe13Le CPcQ5WdIxaUUaoGjee98tJA7FO2xAtzNqwjYNmL35dH8SMaW414cl9avdG7zKB5w86T3 V25RHufoMwOlDcydYnd+NF49nz8Dv4iPJjP7LOEa9P2OEQAQioQUJ3lsVpcV/NAYaZaV sJ5vGapKqulU2J5sUOqwRFhWxo20MaCmrJtoKC/+u8Madd9HPcsHrAxe/7Neb/NJNHEX 3XfgtX4690lskaZCxm/dRPbjbJUzx/c9cET+ffNGGtFV0qptv3KiQG1g2/jqsJ2wgRh5 2HDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=JbQZPfOf23+JAX4M00Jkzb/tWsJPvuUOcAn2sKXt8Zg=; b=hLBF687Ihgc+RVMeLFYaLZ03ChUgAjgRGPZMYL5WZJF119g+AV5LvZb7gLrZH4l8Pb /gxTlW519flwSZ0kMpne7tlbZj4hZ6UMfe7p2OmdCsh3EIq9lnlXsagzO3ahlDARyNIJ /RVHyS2g4gyn7iQ8GyTko6xAJq4PI0JsmgKhqk7+Od6ZjOXSTOu4+IIdvSH+DVCyUuQV ZDP5JeSPoFbSvawFMnZUauGPt6hj4bkLacvsFtHPA5hupzvk7TMrYKAQjk7fGj1ZXeoN X4XCHSvsSf1tCQcc7tapufSe+iclBZY0+VnGoVEo/rB8XdZxHEIOGvExyfFzKQQEiJ5Q GS/w==
X-Received: by with SMTP id z6mr3485426qec.6.1365033955603; Wed, 03 Apr 2013 17:05:55 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 3 Apr 2013 17:05:34 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Justin Uberti <>
Date: Wed, 03 Apr 2013 17:05:34 -0700
Message-ID: <>
To: "Ejzak, Richard P (Richard)" <>
Content-Type: multipart/alternative; boundary="047d7bd6ae8007d8bd04d97dbcbe"
X-Gm-Message-State: ALoCoQm9ExO4BWkFXIbcjyQYIhYxydHiViRhMSBpBAJQKWzEn9x1qnhJfq+AdiXr3TCP5e1nJC2zQA+X50wjrcSvr+kBtSdH8POiw1JaA9DXD2RgejjRPrCS6QQDrBWvsV/RsjyhDpn6an21FIy94nmEbg9ey0zQ/dE8Kf1TMhT5WyU8rUgqKfksWYqSfKLZCzZpKRVDTwc9
Cc: "" <>
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: Thu, 04 Apr 2013 00:05:57 -0000

On Thu, Mar 21, 2013 at 6:52 PM, Ejzak, Richard P (Richard) <> wrote:

>  Hi Justin,****
> I have comments on items 4 and 10 in your original list.****
> ** **
> 4: In 6.1, list 1, if the answerer chooses to bundle and selects the
> 5-tuple from the first m line for the group, then it must also assume the
> use of the c=, rtcp-mux and a=fingerprint (all transport related
> attributes) from that m line for the group.  Then according to the rules,
> the 2nd offer must then include the same value for c=, rtcp-mux and
> a=fingerprint for all m lines in the group.


>  If you relax conditions 2, 5 and 7 for the 1st offer, it would seem a
> little strange and would require extra work to clean up all the m lines in
> the 2nd offer if the 1st offer had different values for c=, rtcp-mux and
> a=fingerprint in all the m lines of the group.  As I see it, it’s easier to
> have this rule from the beginning unless there are some use cases where you
> might want different values for c=, rtcp-mux and a=fingerprint if bundle
> cannot be negotiated.  Do you (or anyone else) see any reason to have this
> capability?  It probably isn’t that important a rule (except for
> convenience) since any middlebox will get straightened out with the 2ndoffer and any peer agreeing to bundle knows to ignore the transport related
> information from the other lines (except as discussed below).

We already need to deal with this for a=candidate, a=crypto and
a=ice-ufrag/pwd, so I don't see why having to also do this for these other
attributes makes things any harder. It's not super important, but it seems
odd to prohibit things that would seem to be mostly unrelated to BUNDLE.

> ****
> ** **
> 10: I think we have to have the ability to unbundle within a
> PeerConnection.  For the error case described (twice) at the mike in
> Orlando, if the first answer comes back asking to bundle but signaling
> different ports, it is because of an intermediary forwarding bundle
> attributes without understanding them while remapping ports.  There seemed
> to be agreement in this case (or at least the opinion was expressed) that
> the offerer needs to detect this condition and send a 2nd offer with
> different ports and without bundle (else the answerer will continue to
> assume bundle while the intermediary will not).  Note that this case
> appears (to the answerer) as if bundle is successfully negotiated but then
> it is immediately removed with the 2nd offer.
> ** u**
> I think we also have the 3pcc use case where a mid-call bundled offer goes
> to a different endpoint that chooses not to bundle.  As long as it removes
> the bundle attributes and returns different ports, why should we disallow
> this?  It only requires an ICE restart.  This will even work with most
> (new) intermediaries except those that choke on seeing the same port in
> multiple m lines.  Which brings me to why I think we also need to be able
> to indicate via the API whether a mid-call offer is to be signaled with the
> same or different ports for a bundle group (as I also requested at the
> mike).

I think this is harder than you say. It's more than an ICE restart, it also
requires re-keying of SRTP (since we now need unique crypto per m-line) and
dealing with the sort-of-BUNDLEd case where we need to be able to receive
BUNDLEd and non-BUNDLEd media potentially simultaneously during the
transition. I'd really like to avoid having to deal with this.

> ****
> ** **
> Richard****
> ** **
> *From:* [] *On
> Behalf Of *Justin Uberti
> *Sent:* Friday, March 15, 2013 3:51 PM
> *To:*
> *Subject:* [MMUSIC] 10 BUNDLE questions****
> ** **
> 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) ****
>    4. From 6.1, list 1 - are conditions 2, 5, 7 really necessary? (MUST
>    use same c=, add rtcp-mux, same a=fingerprint)****
>    5. From 6.1, list 2 - is condition 6 right? Why would we use different
>    SDES keys for a single RTP session?****
>    6. 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)****
>    7. If the BUNDLE mids in the answer doesn't match the BUNDLE mids in
>    the offer, what happens? (assume fail)****
>    8. If you add a m= line to an existing BUNDLE, can the recipient
>    reject that BUNDLEing (assume no)****
>    9. 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?****
>    1. Is there any way, in a single PeerConnection, to unBUNDLE m= lines
>    that were previously BUNDLEd (assume no)****