Archive

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"
>> <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>om>; 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
>>
>