Re: [MMUSIC] Bundle rejection oddities

[Eric Rescorla <[e-mail]>]

On Thu, Mar 3, 2016 at 7:53 PM, Christer Holmberg <
[e-mail]> wrote:

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

Quite possibly. However, I guess a number of us weren't paying attention
since it came as a surprise to a bunch of us yesterday.



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

Thanks

-Ekr


>
> Regards,
>
> Christer
>
>
> Sent from my Windows Phone
> ------------------------------
> From: Eric Rescorla <[e-mail]>
> Sent: ‎04/‎03/‎2016 02:53
> To: mmusic WG <[e-mail]>
> 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
> this:
>
>    a=group:BUNDLE alpha bravo charlie
>    m=audio 1111
>    a=mid:alpha
>    a=candidate
>
>    m=video 2222
>    a=mid:bravo
>    a=candidate
>
>    m=video 3333
>    a=mid:charlie
>    a=candidate
>
> 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
>    a=mid:alpha
>
>    m=video 4444
>    a=mid:bravo
>    a=candidate
>
>    m=video 4444
>    a=mid:charlie
>
>
> 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
>    a=mid:alpha
>
>    m=video 5555
>    a=mid:bravo
>    a=candidate
>
>    m=video 5555
>    a=mid:charlie
>
>
> 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
>    a=mid:alpha
>
>    m=video 0
>    a=mid:bravo
>
>    m=video 4444
>    a=mid:charlie
>    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.
>
> -Ekr
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>