Re: [MMUSIC] Bundle rejection oddities

[Eric Rescorla <[e-mail]>]

On Fri, Mar 4, 2016 at 8:46 AM, Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
> >>>>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.”
> >>>
> >>>I think the key point here is not that but that the attributes may be
> attached in the
> >>>offer to an m= line which ends up being defunct.
> >
> >> That could e.g. be covered by adding the following sentence to the note:
> >>
> >> "This could happen e.g. if the "m=" line in the offer is rejected and
> moved out
> >>of the bundle group by the answerer."
> >
> > Well, I think the key point here is that you need to take the attributes
> out of the
> > defunct line, which neither this text nor the previous text really
> captures.
>
> The 3rd bullet in the bullet list does say:
>
>       "the answerer only associates ICE-related media-level SDP attributes
> with the "m=" line associated with the
>       answerer BUNDLE-tag."
>
> Perhaps we could add to that statement:
>
> "The answerer MUST NOT associated ICE-related media-level SDP attributes
> with any other "m=" lines within the bundle group."
>
> (And a similar statement to the bullet talking about the offer)
>

No I don't think this is getting at the right point, which is about the
mismatch.

I would add after the third bullet:

   Note that because the ICE parameters apply to the bundle group rather
than
   to a given "m=" line, but only appear within the "m=" section associated
with
   the sender's BUNDLE-tag,, it is possible for the offerer's and answerer's
   ICE parameters to appear within "m=" sections that do not correspond to
   each other, for instance if the answerer rejects the "m=" section
associated
   with the offeror's BUNDLE-tag. It is the responsibility of both sides to
match
   up the ICE parameters appropriately, regardless of which "m=" section of
   the bundle group they appear in.


>>>I'd also like to observe that this paragraph exemplifies an infelicity
> in the current
> >>>draft, which is the overloading of the term "associated", which appears
> three times
> >>>in this paragraph alone with two different meanings. I think it would
> be clearer if
> >>>instead different terms were used. I suggest "member of" for being in a
> bundle group,
> >>>"appears in" or "attached to" for being in a given m= section, and
> "corresponding"
> >>>for "the SDP offer/answer that this answer/offer" goes with
> >>
> >> I agree that "associated" is used in many places. But, I have had to
> change the terminology so many
> >> times already, because every time someone has reviewed the document
> he/she has had ideas on how to modify the terminology.
> >>
> >> The current terminology is what we have been able to agree upon, so I
> do not want to change it again. I really think it's time to ship BUNDLE.
> >
> > I'm happy to have different terminology but not to have the same term
> used for multiple
> > purposes, which is the current situation. I'm sympathetic to editor
> fatigue, but I think
> > having the document be readable is more important.
>
> Just a few comments on your suggestions:
>
> - You suggest saying "member of bundle group". But, I don't think I say
> "associated with bundle group", but "within bundle group". At least that is
> my intention, so please let me know if you've found some places where
> that's not the case.
>

S1.
   The offerer and answerer [RFC3264] use the BUNDLE extension to
   negotiate the BUNDLE addresses, one for the offerer (offerer BUNDLE
   address) and one for the answerer (answerer BUNDLE address), to be
   used for receiving the bundled media associated with a BUNDLE group.

S 5.
   All media associated with a BUNDLE group share a single 5-tuple, i.e.
   in addition to using a single address:port combination all bundled
   media MUST be transported using the same transport-layer protocol


- You suggest saying "attribute appearing in m- line". Such terminology has
> been used in the past, and I was asked to change it, because attributes are
> not part of m- lines.
>

I would recommend the JSEP terminology of "appearing within an m= section"
In any case, the problem is the use of "associated" here. Feel free to use
another term that's not "associated"



> - I do use "corresponding" when I talk about m- lines in offers and
> answers. If we use it "corresponding" also for offers and answers we would
> end up with text like "the corresponding m- line in the corresponding
> answer".
>

Again, the problem is "associated". Feel free to choose another term than
corresponding.

-Ekr





> Regards,
>
> Christer
>
>
>
> From: mmusic [mailto:[e-mail]] 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.
>
> Regards,
>
> Christer
>
>
> 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
> 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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>