Re: [MMUSIC] Questions about ICE candidates with BUNDLE

[Taylor Brandstetter <[e-mail]>]

Could you elaborate? I'm not clear on what you mean by "identical", or how
it addresses my point.

On Thu, Mar 17, 2016 at 1:42 AM, Christer Holmberg <
[e-mail]> wrote:

> Hi Taylor,
>
> When a shared address is use, the ICE attributes etc should be identical.
>
> In any case, we do need to double check that the text is aligned between
> the drafts.
>
> Regards,
>
> Christer
>
> From: Taylor Brandstetter <[e-mail]>
> Date: Wednesday 9 March 2016 at 21:03
> To: Christer Holmberg <[e-mail]>
> Cc: Suhas Nandakumar <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>
>
> Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE
>
> 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
>>>
>>>
>>
>