Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis

[Emil Ivov <[e-mail]>]

On Thu, Jul 24, 2014 at 11:08 AM, Iñaki Baz Castillo <[e-mail]> wrote:
> 2014-07-24 16:48 GMT+02:00 Emil Ivov <[e-mail]>:
>> Well, if you are going to resend it at all then you don't even need to
>> change priority. The simple fact that you are re-confirming it should
>> be enough of an indication.
>
> I don't think it should work.

It wouldn't work with existing implementations. The point is to define
the spec in a way that makes it work in future implementations.

> The ICE server should select the request
> with highest PRIORITY

I am not sure what you mean by ICE server.

> regardless it receives later a new one with less
> PRIORITY. This is clear in the RFC. And this is because it is supposed
> that both peers agree on selecting the request-response with higher
> PRIORITY, regardless which one arrives before.

This is not true for regular nomination where the nominated candidate
is chosen solely based on the USE-CANDIDATE option.

The point is to create an unambiguous

> This makes sense. Let's assume requests come in this order:
>
> 1)
>
>    Req1-good-connection PRIORITY: 9000  -->
>    Req2-bad-connection PRIORITY: 1000  -->
>
> should the server chose Req2? not at all.
>
> 2)
>
>    Req2-bad-connection PRIORITY: 1000  -->
>    Req1-good-connection PRIORITY: 9000  -->
>
> server should choose Req1 once it arrives.

I think you are confusing multiple received USE-CANDIDATE options for
*different* candidate pairs (which is what happens with aggressive
nomination) with receiving a second USE-CANDIDATE option for *the
same* candidate pair.

Emil


-- 
https://jitsi.org