Re: [MMUSIC] Questions about ICE candidates with BUNDLE

On 3/8/16 2:47 AM, 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.

	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
>