Re: [MMUSIC] Questions about ICE candidates with BUNDLE

I agree - if we're going to avoid duplication of ICE attributes, we should
do the same for the other transport attributes too.

On Tue, Mar 8, 2016 at 11:20 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> On 3/8/16 2:08 PM, Christer Holmberg wrote:
>
>> Hi,
>>
>> Does anyone else have opinions on this? One would assume that the
>>>> folks (Bernard, Martin, Ekr…) representing the other browser vendors
>>>> would have an opinion.
>>>>
>>>> Whatever your opinion is (even if you don’t care), please indicate so
>>>> NOW.
>>>> I want to avoid implementing this change, and then have someone saying
>>>> he/she doesn’t like it...
>>>>
>>>
>>> I have lost track - is the intent to limit this de-duplication to
>>> bundle-only? If it is to apply to m-lines that might be removed from the
>>> bundle then it gets more complicated.
>>>
>>> I guess it couldn't *only* apply to bundle-only - at least one of the
>>> lines in the group can't have that.
>>>
>>
>> It applies to bundled m- lines that contain a previously negotiated
>> *shared* address (not only bundle-only).
>>
>> 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.
>
>         Thanks,
>         Paul
>
>
> Regards,
>>
>> Christer
>>
>>
>> On 05/03/16 16:04, "mmusic on behalf of Christer Holmberg"
>>> <mmusic-bounces@ietf.org on behalf of christer.holmberg@ericsson.com>
>>> 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
>>>> <pthatcher@google.com>
>>>> wrote:
>>>> Sure.
>>>>
>>>> On Thu, Feb 25, 2016 at 1:07 AM, Christer Holmberg
>>>> <christer.holmberg@ericsson.com> 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:pthatcher@google.com]
>>>> Sent: 25 February 2016 08:53
>>>> To: Christer Holmberg <christer.holmberg@ericsson.com>
>>>> Cc: Roman Shpount <roman@telurix.com>; mmusic@ietf.org; Paul Kyzivat
>>>> <pkyzivat@alum.mit.edu>
>>>>
>>>> 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
>>>> <christer.holmberg@ericsson.com> 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; mmusic@ietf.org; Paul Kyzivat
>>>> Subject: Re: [MMUSIC] Questions about ICE candidates with BUNDLE On
>>>> Sat, Feb 20, 2016 at 12:57 PM, Christer Holmberg
>>>> <christer.holmberg@ericsson.com> 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
>>>> mmusic@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>
>>>
>>>
>>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>