Re: [MMUSIC] 10 BUNDLE questions

Eric Rescorla <> Wed, 24 April 2013 02:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D067E21F93F3 for <>; Tue, 23 Apr 2013 19:17:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UMIz-IubI3Un for <>; Tue, 23 Apr 2013 19:17:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0433621F93F1 for <>; Tue, 23 Apr 2013 19:17:05 -0700 (PDT)
Received: by with SMTP id 6so907090qeb.36 for <>; Tue, 23 Apr 2013 19:17:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=yRRrgaBUckd9N24y5hNMekRxJIb5wgyYF6d+TMb5LK8=; b=SSXPJUkInySEuy/ba8eqqCUYgbk1Y2is32qhlcC9Xg1f2q4uUPygOV8DkFxoCj6ai4 2c8hSJqVSUB8nHCoQC+NSZSH/0NMm9igqFMxxZLAIp5857bmyBwRVdTq5stouSGtbmgO YAxNrSPkUVV0iXl0UTzBkdqaJVIi4FcOJGaOgYWUgHwzgGFDWHYiTVf+31btmsm3538t Oq+ma7Z5gnIMGLonHngNe2FRYQv5LifgNq+I/o6IhXBcZGl2aiqlA3/q7/6c5VfuC7PM GyeWRzOT6JAGB2gP7+Qx3zhrjipFPEgH/MNanFqdCIxAq+09/P1EU/XwfwaIodpV1Vjo HpvA==
X-Received: by with SMTP id c6mr4891365qcw.58.1366769825528; Tue, 23 Apr 2013 19:17:05 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 23 Apr 2013 19:16:25 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <>
From: Eric Rescorla <>
Date: Tue, 23 Apr 2013 19:16:25 -0700
Message-ID: <>
To: Justin Uberti <>
Content-Type: multipart/alternative; boundary="14dae94ee2adf0f83e04db11e530"
X-Gm-Message-State: ALoCoQmGbONgA1JrJhNir07FUcQvAh6jo2eYr1zoSi7+xx77BGbMVjvEAxnm8Wwft7rD7Udx+cP9
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: Wed, 24 Apr 2013 02:17:06 -0000

After reading the thread, here are my proposed answers...

> Can you create a BUNDLE with a single m= line? (assuming yes)


> Can you create multiple BUNDLEs? (assuming yes)


> 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 it's ok for the null port to not be equal.

> From 6.1, list 1 - are conditions 2, 5, 7 really necessary? (MUST
>  use same c=, add rtcp-mux, same a=fingerprint)

I don't know if rtcp-mux is necessary, but it seems stupid not to
have it.

I think we do need to have matching fingerprints because we can
only have one DTLS-SRTP association and it's hard to understand
what the security properties are if the two associations
in principle might have different credentials.

> From 6.1, list 2 - is condition 6 right? Why would we use different
> SDES keys for a single RTP session?

So, I note that this list requires that the other side *support*
bundle not that he accept it. So, there's still some chance
of getting things unbundled, no?

> 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)

So, this seems like an argument for using distinct SDES lines
since then you can just keep the SDES line associated with its
associated m-line.

> If the BUNDLE mids in the answer doesn't match the BUNDLE mids in the
> offer, what happens? (assume fail)

That sounds right to me.

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

I think life would be simpler if this just caused a negotiation
fail if the other side was sad about it.

> If m= lines are rejected, should their mids show up in the BUNDLE
> answer? (assume yes?)

That sounds easiest.

> Is there any way, in a single PeerConnection, to unBUNDLE m= lines
> that were previously BUNDLEd (assume no)

I would say no.

After all, you can always discard those lines and offer new lines.