Re: [MMUSIC] Questions about ICE candidates with BUNDLE

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
>>
>