Re: [MMUSIC] Bundle rejection oddities

Christer Holmberg <> Fri, 04 March 2016 07:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6990F1A1AA3 for <>; Thu, 3 Mar 2016 23:32:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3
X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id imeu_7CTtf2b for <>; Thu, 3 Mar 2016 23:32:07 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E6D891A8A1C for <>; Thu, 3 Mar 2016 23:32:06 -0800 (PST)
X-AuditID: c1b4fb2d-f79836d000006396-56-56d939f481de
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id C8.22.25494.4F939D65; Fri, 4 Mar 2016 08:32:04 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Fri, 4 Mar 2016 08:32:04 +0100
From: Christer Holmberg <>
To: Eric Rescorla <>, mmusic WG <>
Thread-Topic: [MMUSIC] Bundle rejection oddities
Thread-Index: AQHRdbAze3OVqIuh4UG8lpLJiZIPzJ9Ip1fEgAA8meA=
Date: Fri, 4 Mar 2016 07:32:04 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37E59A2EESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGIsWRmVeSWpSXmKPExsUyM2K7hO4Xy5thBl/n61iseH2O3WLq8scs DkweS5b8ZPKY/LiNOYApissmJTUnsyy1SN8ugSvj1pEJ7AXrZjFWTPk/h62B8VwrYxcjJ4eE gInEv1/ToGwxiQv31rN1MXJxCAkcZpTYt/0TlLOIUeJKwx8gh4ODTcBCovufNkiDiICtRE/v EbBmYQF9iXdTHrFDxA0kJlx8ywphW0nM+nQNLM4ioCLxc3YDmM0r4CvxomETC8T8KYwS/c1v GEHmcwr4SVxerQRSwwh00PdTa5hAbGYBcYlbT+YzQRwqILFkz3lmCFtU4uXjf6wQtpLEjw2X WCDq8yX+P5zIBLFLUOLkzCcsExhFZiEZNQtJ2SwkZRBxA4lz2zeyQ9jaEssWvmaGsPUltt+e yYosvoCRfRWjaHFqcXFuupGxXmpRZnJxcX6eXl5qySZGYGwd3PJbdwfj6teOhxgFOBiVeHg3 rLgeJsSaWFZcmXuIUYKDWUmEd73+zTAh3pTEyqrUovz4otKc1OJDjNIcLErivGyfLocJCaQn lqRmp6YWpBbBZJk4OKUaGPO2hSXduOrSX28cu3PPWo4dy5L+H93+MmdDbtSEz0vmn/tvdO+0 jmBfSOKEjPseZZ2zM7emt1xLf7lueuHXBUZa992X/mthdj+hKnnOecVtgTr+Us8ZBkvfnXf8 EF2/8oVT8LUzeo5+z/KaDySIZk9hlLM1lTkuGFChbJerGSZ4qF3e7/RXJSWW4oxEQy3mouJE ALqcG/WpAgAA
Archived-At: <>
Subject: Re: [MMUSIC] Bundle rejection oddities
X-Mailman-Version: 2.1.15
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, 04 Mar 2016 07:32:10 -0000

What about adding the following note to section 11.1:

   “NOTE: The ICE-related media-level SDP attributes might end up being associated with
   with an "m=" line in the answer that does not correspond to the "m=" line
   to which the ICE-related SDP attributes were associated in the associated offer.”



From: mmusic [] On Behalf Of Christer Holmberg
Sent: 4. maaliskuuta 2016 5:53
To: Eric Rescorla; mmusic WG
Subject: Re: [MMUSIC] Bundle rejection oddities

Hi Ekr,

I think I presented exactly the same use-case when it was first suggested to not associate shared candidates with each bundled m- line.

I'll look if I can add some additional text somewhere, to point out that the candidates can be associated with different m- lines in offers and answers, e.g. due to the use-case you described.



Sent from my Windows Phone
From: Eric Rescorla<>
Sent: ‎04/‎03/‎2016 02:53
To: mmusic WG<>
Subject: [MMUSIC] Bundle rejection oddities
Hi folks,

I've been working through the bundle draft and I've come across a sort
of surprising consequence that I wanted to share with the group. Sorry
for the extended example, but I think it's hard to get without that.

Consider the case where an offerer has three m= lines, alpha, bravo,
and charlie. This creates an initial offer that's (schematically) like

   a=group:BUNDLE alpha bravo charlie
   m=audio 1111

   m=video 2222

   m=video 3333

Per 8.2, and because this isn't bundle-only, each m= line has a unique
address and a set of candidates (I'm ignoring the ufrag and ice-pwd
for now).

Assume that the answerer rejects the first m= line, so per 8.3, it
pulls alpha out of the bundle group and sets is port number to 0.  Per
11.2, it only associates candidates with the answerer bundle tag,
which is bravo:

   a=group:BUNDLE bravo charlie
   m=audio 0

   m=video 4444

   m=video 4444

So far so good. Now consider what happens if the offerer does an
ICE restart and (for instance) changes some property about the
second m= line. Per S 11.1 bullet 1, it only uses a shared address
for the second two m= lines and only attaches a candidate to the
second one (bravo). I.e.,

   a=group:BUNDLE bravo charlie
   m=audio 0

   m=video 5555

   m=video 5555

If the answerer decides to reject bravo (leaving only charlie),
it now sets its port to 0 and pulls it out of the bundle group,
giving us:

   a=group:BUNDLE charlie
   m=audio 0

   m=video 0

   m=video 4444
   a=candidate     <-- See here

Note that the candidate here is on the third m= line but it needs to
be paired with the candidates on the second (rejected) m= line from
the offerer. I'm not saying that this is fatal: the logical
interpretation is that the candidates (and other ICE parameters) are
associated with the whole bundle group (and implicitly duplicated) and
just appear with one m= line. However, it is a bit odd and probably
should be called out in the spec lest people get confused.