Re: [MMUSIC] Questions about ICE candidates with BUNDLE

[Taylor Brandstetter <[e-mail]>]

Isn't it true that even within the TRANSPORT category, the scenario Ekr
brought up could have unexpected effects? Specifically, the scenario where
the "BUNDLE negotiated m= line" changes between the offer and answer, as a
result of a media section being rejected. For example:

Initial offer:

   a=group:BUNDLE alpha bravo
   m=audio 1111
   a=mid:alpha
   a=fingerprint:foo

   m=video 2222
   a=mid:bravo
   a=fingerprint:bar

Initial answer:

   a=group:BUNDLE alpha bravo
   m=audio 3333
   a=mid:alpha
   a=fingerprint:baz

   m=video 4444
   a=mid:bravo
   a=fingerprint:qux

At this point the BUNDLE negotiated m= line is "alpha", so both endpoints
know what fingerprint to use. Now, what if the initial offerer decides to
change some attributes of the first media section (not described here), and
the answerer rejects it, changing the BUNDLE negotiated m= line?

Offer:

   a=group:BUNDLE alpha bravo
   m=audio 1111
   a=mid:alpha
   a=fingerprint:foo

   m=video 1111
   a=mid:bravo
   a=fingerprint:bar

Answer:

   a=group:BUNDLE bravo
   m=audio 0
   a=mid:alpha
   a=fingerprint:baz

   m=video 3333
   a=mid:bravo
   a=fingerprint:baz

The answerer updated the fingerprint of the second m= section, to try to
use the same DTLS session. But the offerer didn't, because it assumed the
bundled m= line wouldn't change. So it seems like this would be interpreted
as the offerer changing its fingerprint from "foo" to "bar".

If that's the way other people interpret this situation as well, should
there at least be a warning calling out this situation? For example, "If an
offerer desires that a TRANSPORT attribute for a BUNDLE group stays the
same even if the answerer rejects the media section currently associated
with the BUNDLE group, the attribute SHOULD be duplicated within each media
section in the BUNDLE group."

Of course, this would go completely contrary to how the ICE attributes work
(as of recently). Which is why I think whatever rule we decide for the ICE
attributes (be it duplicating them or not duplicating them) should be
generalized for all TRANSPORT attributes.



On Wed, Mar 9, 2016 at 7:28 AM, Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
> Perhaps we would then need to change the text for IDENTICAL, or do you
> think there is a reason to associate them with each m- line?
>
> Regards,
>
> Christer
>
> Sent from my Windows Phone
> ------------------------------
> From: Suhas Nandakumar <[e-mail]>
> Sent: ‎09/‎03/‎2016 17:26
>
> To: Christer Holmberg <[e-mail]>
> Cc: Paul Kyzivat <[e-mail]>; Peter Thatcher
> <[e-mail]>; [e-mail]
> Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE
>
> Hello Christer
>
>  I don't think the mux draft says that independent of the categories.
>
> However for the IDENTICAL category, it does say that the attribute (and
> its associated value) must be repeated across all the m=lines in the
> bundled group. For the rest of the categories , we don't really say
> anything about how the attribute exists in a given m=line but leave it to
> its normal usages.
>
> Thanks
> Suhas
>
>
>
> On Wed, Mar 9, 2016 at 7:21 AM, Christer Holmberg <
> [e-mail]> wrote:
>
>> Hi Suhas,
>>
>> My question is not about the semantics of the categories, but whether
>> there is text saying that all attributes must explicitly be associated with
>> each m- line (no matter the category).
>>
>> Regards,
>>
>> Christer
>>
>> Sent from my Windows Phone
>> ------------------------------
>> From: Suhas Nandakumar <[e-mail]>
>> Sent: ‎09/‎03/‎2016 16:57
>> To: Christer Holmberg <[e-mail]>
>> Cc: Paul Kyzivat <[e-mail]>; Peter Thatcher
>> <[e-mail]>; [e-mail]
>>
>> Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE
>>
>> Hello Christer et al
>>
>>   I am traveling this week and having difficulty in following lot of
>> these discussions. So please bare with me if I am mis-representing the
>> question here ...
>>
>>
>> From the mux spec, the TRANSPORT category implies that no matter if a
>> particular attribute is repeated or has different values across the m=lines
>> , the one to be chose MUST correspond to the BUNDLE negotiated m= line.
>>
>> Thus, if we apply de-duplication in the way Offer/Answer is constructed,
>> as long as the above rule applies when an attribute is selected for its
>> value, things should be OK.
>>
>>
>> Does this answer the question ?
>>
>>
>>
>> On Wed, Mar 9, 2016 at 5:46 AM, Christer Holmberg <
>> [e-mail]> wrote:
>>
>>> Another question is whether this would have an impact on
>>> draft-ietf-mmusic-mux-attributes. Suhas?
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>> -----Original Message-----
>>> From: mmusic [mailto:[e-mail]] On Behalf Of Christer
>>> Holmberg
>>> Sent: March 09, 2016 15:43
>>> To: 'Paul Kyzivat'; Peter Thatcher
>>> Cc: [e-mail]
>>> Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE
>>>
>>> Hi,
>>>
>>> ...
>>>
>>> >> We already specified this for ICE-related attributes, and the
>>> question is whether we should do it also for other attributes that must
>>> share the same value.
>>> >
>>> > OK. At the moment I can't think of any reason not to generalize this.
>>>
>>> One reason would be if nobody gives a **** :)
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>>
>>> >> On 05/03/16 16:04, "mmusic on behalf of Christer Holmberg"
>>> >> <[e-mail] on behalf of [e-mail]>
>>> >> wrote:
>>> >>
>>> >>> Hi,
>>> >>>
>>> >>>> I took a look, and it seems fine to me.
>>> >>>>
>>> >>>> One question that was brought up to me about this is, though is:
>>> >>>> would it make sense to expand this de-duplication rule to all
>>> >>>> transport-level attributes (like a=fingerprint) and not just ICE
>>> >>>> attributes?  We talked about this before, and my response was
>>> >>>> basically "the ICE candidates are my biggest pain point", but now I
>>> >>>> think I'm more in favor of saying all transport-level attributes
>>> >>>> should be de-duplicated.  What does everyone else think?
>>> >>>
>>> >>> I guess it would apply to transport-level attributes AND other
>>> >>> attributes that must have identical values within a bundle group,
>>> >>> i.e. attributes within the TRANSPORT and IDENTICAL categories
>>> [draft-mux-attributes].
>>> >>>
>>> >>> I don't have any strong opinions. If you think it make life easier
>>> >>> for implementers we should definitely consider it :)
>>> >>>
>>> >>> Regards,
>>> >>>
>>> >>> Christer
>>> >>>
>>> >>>
>>> >>> On Fri, Feb 26, 2016 at 1:23 PM, Peter Thatcher
>>> >>> <[e-mail]>
>>> >>> wrote:
>>> >>> Sure.
>>> >>>
>>> >>> On Thu, Feb 25, 2016 at 1:07 AM, Christer Holmberg
>>> >>> <[e-mail]> wrote:
>>> >>> Hi Peter,
>>> >>>
>>> >>> I submitted a new version (-27) of BUNDLE a few days ago. Could you
>>> >>> take a look at the ICE Considerations section, and say whether you
>>> >>> are ok with the text?
>>> >>>
>>> >>> Thanks!
>>> >>>
>>> >>> Regards,
>>> >>>
>>> >>> Christer
>>> >>>
>>> >>> From: Peter Thatcher [mailto:[e-mail]]
>>> >>> Sent: 25 February 2016 08:53
>>> >>> To: Christer Holmberg <[e-mail]>
>>> >>> Cc: Roman Shpount <[e-mail]>; [e-mail]; Paul Kyzivat
>>> >>> <[e-mail]>
>>> >>>
>>> >>> Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE
>>> >>>
>>> >>> That makes sense to me.
>>> >>>
>>> >>> On Sun, Feb 21, 2016 at 2:12 AM, Christer Holmberg
>>> >>> <[e-mail]> wrote:
>>> >>> Hi Roman,
>>> >>>
>>> >>> I didn't check whether some of the ICE attributes were
>>> >>> session-level, but I agree with what you say: the same rule should
>>> >>> apply to all media-level ICE attributes.
>>> >>>
>>> >>> Regards,
>>> >>>
>>> >>> Christer
>>> >>>
>>> >>> Sent from my Windows Phone
>>> >>> ________________________________________
>>> >>> From: Roman Shpount
>>> >>> Sent: ‎21/‎02/‎2016 08:21
>>> >>> To: Christer Holmberg
>>> >>> Cc: Peter Thatcher; [e-mail]; Paul Kyzivat
>>> >>> Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE On
>>> >>> Sat, Feb 20, 2016 at 12:57 PM, Christer Holmberg
>>> >>> <[e-mail]> wrote:
>>> >>>>> Correct, and that's one reason I suggest that we limit the scope
>>> >>>>> to ICE, eventhough we probably could do the same thing for any
>>> >>>>> IDENTICAL and TRANSPORT category attribute.
>>> >>>>
>>> >>> ​> While it would be nice to remove any duplication, the duplication
>>> >>> is particularly painful for ICE candidates, because
>>> >>>> there can be a lot of them, and because they change without any
>>> >>>> offer/answer action (thanks to trickle ICE). ​ So if we just
>>> >>>> covered that candidates, we'd be getting most of the value.
>>> >>>
>>> >>> Assuming the scope is ICE, shouldn't the same still apply also to
>>> >>> other ICE related attributes? I assume the values for the
>>> >>> "remote-candidates", "ice-lite", "ice-mismatch", "ice-ufrag",
>>> >>> "ice-pwd", "ice-pacing" and "ice-options" attributes will be
>>> identical within a BUNDLE group, so...
>>> >>>
>>> >>> "ice-lite" and "ice-options" are session level only candidates, so
>>> >>> they should not be in the m= line BUNDLE or any other type. The same
>>> >>> logic that applies to ICe candidates should apply to other media
>>> >>> level ICE SDP attributes or things will break
>>> >>>
>>> >>> Regards,
>>> >>> _____________
>>> >>> Roman Shpount
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> mmusic mailing list
>>> >>> [e-mail]
>>> >>> https://www.ietf.org/mailman/listinfo/mmusic
>>> >>
>>> >
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>