Re: [MMUSIC] 10 BUNDLE questions

"Cullen Jennings (fluffy)" <> Fri, 19 April 2013 16:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E4AB721F88FB for <>; Fri, 19 Apr 2013 09:19:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f1D0Qv1BAnBg for <>; Fri, 19 Apr 2013 09:19:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9B44F21F88D8 for <>; Fri, 19 Apr 2013 09:19:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3749; q=dns/txt; s=iport; t=1366388354; x=1367597954; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Lz/kYTm4qaUY4U7t2xUlVVrBPdFxvWLUFYOkpseM+DA=; b=DVL1d7FZHxSJAqvyDIn/v7dKGyRClTTb2tDj5+CeFlHCLBl8/bV1862U arcw3UNdKNzlCWoaxuRdsukCGjOESc+2Fo3wtC5j1737FvXYp98i0F8Aw j5degCPZYY47SGRqc26+MBU+L6NFWNHfr11l9W8/q8YyG/1LyjhJi5ICK 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAFAOBtcVGtJV2a/2dsb2JhbABQgwbBHIEGFnSCHwEBAQMBaw4FCwIBCA4UJDIlAgQOBQiIBga9UI5yAjEHgmZhA6glgwyCKA
X-IronPort-AV: E=Sophos;i="4.87,510,1363132800"; d="scan'208";a="200856831"
Received: from ([]) by with ESMTP; 19 Apr 2013 16:19:14 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r3JGJEfD021527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Apr 2013 16:19:14 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Fri, 19 Apr 2013 11:19:13 -0500
From: "Cullen Jennings (fluffy)" <>
To: Justin Uberti <>
Thread-Topic: [MMUSIC] 10 BUNDLE questions
Thread-Index: AQHOPRmhAn/HVdjyoE6L992RtT7hTQ==
Date: Fri, 19 Apr 2013 16:19:13 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 16:19:16 -0000

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. 

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

on rtcp-mux, I think it simplifies thing to mandate rtcp-mux. So if far side accepts bundle but rejects rtcp-mux, this is a fail. 

on c=, I can't think of any good reason to require this. Need more thought on this. 

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. 

> 	• 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. 

> 	• 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. 

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


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

agree it should be no

> 	• 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. 

> 		• 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. 

> _______________________________________________

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