Re: [MMUSIC] 10 BUNDLE questions

Martin Thomson <> Fri, 19 April 2013 21:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2CCD221F8E8E for <>; Fri, 19 Apr 2013 14:05:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_55=0.6, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nZXJ-p7LBM+3 for <>; Fri, 19 Apr 2013 14:05:55 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::229]) by (Postfix) with ESMTP id 255A121F8E84 for <>; Fri, 19 Apr 2013 14:05:54 -0700 (PDT)
Received: by with SMTP id p43so840855wea.14 for <>; Fri, 19 Apr 2013 14:05:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=UmFP1EaQP285l4tkMbS0eUHffTNyXs9cR3rzNVNKgqo=; b=Axs1ovcdHqP8jdIVSRvHcTK0wSWdyvFYIw9p6zVDrHU6mUzcBbLnGuzln9dnzKmoOu JNbsfPtLIE2DW4QE6sP/KfYTKXEpSkvZ6kz0Xc95erkBbIRG+hf+PbuzmxbBGXT9tB4m dz3Ns51k6w1cyzXJGqxHbaXiieuyZ/LqIMBdz767o7LDAD1zO0aLNbkCC90hCndGo4pK V/TpjLNmtMiO/P/+75G+CjmQcX4XcWuiYvmDTMAXzuXNvqathkmqpDb9WKuaGdqfSuJQ X9opr4PJeZ4A2rpwGeNui19Dxw+yOzK7O/h4PwAEvNLBb43RCmljL8zS0DRSssVqhKAz lwGQ==
MIME-Version: 1.0
X-Received: by with SMTP id s7mr4835058wiy.19.1366405554285; Fri, 19 Apr 2013 14:05:54 -0700 (PDT)
Received: by with HTTP; Fri, 19 Apr 2013 14:05:54 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Fri, 19 Apr 2013 14:05:54 -0700
Message-ID: <>
From: Martin Thomson <>
To: "Cullen Jennings (fluffy)" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Fri, 19 Apr 2013 21:05:56 -0000

This clarifies things for me.  I hope that these are captured effectively.

On 19 April 2013 09:19, Cullen Jennings (fluffy) <> wrote:
> On Mar 15, 2013, at 2:51 PM, Justin Uberti <> wrote:
>>       • From 6.1, list 1 - are conditions 2, 5, 7 really necessary? (MUST use same c=, add rtcp-mux, same a=fingerprint)
> on fingerprint, I don't think this impacts the bundle but it seems like it make simplify the code that matches the fingerprint to the DTLS connection. Be interested in hearing EKR's thoughts.

I'm not EKR, but I don't see any way that having multiple sets of
credentials would be useful.  That implies multiple handshakes.

a=fingerprint pertains to the transport and as such needs to be the same.

You *could* add fingerprints from different lines as alternative valid
(in the same way that two a=fingerprint can be added to a single
line).  Since this is more likely to be mistake than something
intentional, better to require that every block in a bundle have the
same a=fingerprint.

>>       • From 6.1, list 2 - is condition 6 right? Why would we use different SDES keys for a single RTP session?
> This is confusing in what you do in first is this, but once you know what you are doing, you put what you are using which will result in same not different keys. This needs series review from crypto experts.

In theory you can use multiple keys.  And it doesn't have any real
consequences.  That's not necessarily a useful property though.

>>       • 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)
> Lets say can not do that and if you do it, it is a fail.

See above - it's *possible* to have this particular example work.  But
not useful and therefore inadvisable.

I think that a good requirement is that new m= lines are entered into
a bundle when they are added to the session and that bundle can't
change.  That means you can't move m= lines in and out of bundles.
That also keeps the rules with respect to properties constant for any
given m= line.

Sure, you could make a complicated system where this was possible, but
it probably wouldn't interoperate.

>>       • If you add a m= line to an existing BUNDLE, can the recipient reject that BUNDLEing (assume no)
> agree it should be no

On first impressions, I was inclined to agree that it makes no sense
to allow for unbundling on new m= lines, but this is exactly the same
sort of scenario that an initial offer has to deal with.  Offer the
addition of a stream in a bundle, but allow for the fact that peer
might not support bundling.  So, I'm actually inclined to disagree

That said, without a use case, such a capability complicates things.
I'll get to the use case below.

> 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 actually the same sort of problem as the above.  The question
is whether the bundle is negotiated as a whole, or whether answers can
differentiate on per-line basis.  I can appreciate the desire to
simplify, but you have to examine use cases.

Example: Alice offers A and B bundled, Bob accepts the bundling.
Later, Alice adds C to the bundle.  How can Bob get that m= line
routed over a different path?  Do we require that Bob reject the line
and offer the same line, potentially inverted, without bundling in a
subsequent offer?

I'm thinking here about a case where a session escalates from audio to
audio+video and there might be a middlebox involved.  I guess in that
case the middlebox needs to drive the addition.

I can probably live with the simplification, but this needs to be
crystal clear.  A more complete discussion of the implications of this
particular choice would be really helpful.