Re: [MMUSIC] Questions about ICE candidates with BUNDLE

[Taylor Brandstetter <[e-mail]>]

Well, currently draft-mux-attributes says that for TRANSPORT attributes,
"software MUST pick the [attribute value] that's associated with the "m="
line whose information is used for setting up the underlying transport." I
assume this refers to the m= line associated with the answerer BUNDLE-tag.

However, the BUNDLE draft implies that when a shared address is used, the
software should use the offerer's ICE attributes associated with the
offerer BUNDLE-tag, which in some cases (as in the example above) differs
from the answerer BUNDLE-tag. So it seems like there's an inconsistency
between the two drafts for this

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

> Hi Taylor,
>
> You are right, it applies to both TRANSPORT and IDENTICAL. But, based on
> Suhas' response we would not need any changes for TRANSPORT in
> draft-mux-attributes.
>
> Also note that the rules also only apply to bundled m- lines with a shared
> address. m- lines with a unique address must still contain explicit
> attributes, in case the m- line is moved out if the bundle group by the
> answerer.
>
> Regards,
>
> Christer
>
> Sent from my Windows Phone
> ------------------------------
> From: Taylor Brandstetter <[e-mail]>
> Sent: ‎09/‎03/‎2016 20:02
> To: Christer Holmberg <[e-mail]>
> Cc: Suhas Nandakumar <[e-mail]>; Paul Kyzivat
> <[e-mail]>; [e-mail]
>
> Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE
>
> 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
>>
>>
>