Re: [MMUSIC] Questions about ICE candidates with BUNDLE

[Peter Thatcher <[e-mail]>]

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?

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 <[e-mail]>
>> *Sent: *‎21/‎02/‎2016 08:21
>> *To: *Christer Holmberg <[e-mail]>
>> *Cc: *Peter Thatcher <[e-mail]>; [e-mail]; Paul
>> Kyzivat <[e-mail]>
>> *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
>>
>>
>>
>>
>>
>
>