Re: [MMUSIC] Questions about ICE candidates with BUNDLE

[Christer Holmberg <[e-mail]>]

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

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