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

[Emil Ivov <[e-mail]>]

On 24.07.14, 11:33, Iñaki Baz Castillo wrote:
> 2014-07-24 17:15 GMT+02:00 Emil Ivov <[e-mail]>:
>>> The ICE server should select the request
>>> with highest PRIORITY
>>
>> I am not sure what you mean by ICE server.
>
> The ICE agent receiving the requests.  Imagine a ICE-Lite server which
> is just a "server".

Well ok, but an ICE lite agent doesn't really get to select anything. It 
just has to try and understand what the controlling agent has selected. 
Currently it would do that based on priority but this is suboptimal. 
That's what we are trying to improve.

>>> 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.
>
> I just mean aggressive nomination.
>
>
>
>>> 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.
>
>
> Humm, not :)

Getting multiple USE-CANDIDATES on *different* candidates is simply the 
definition of aggressive nomination. We are not discussing this.

The "second" USE-CANDIDATE that mails in this thread have referred to 
was about the possibility to do a second USE-CANDIDATE on the *same* 
pair as an indication for selecting that candidate. Neither of your 
examples below display this.

> - ICE-Lite servers opens UDP socket in ports 1111 and 2222.
>
> - Client sends:
>
>    ICE-Req-1 USE_CANDIDATE PRIORITY 555  -->  port 1111
> and later:
>    ICE-Req-2 USE_CANDIDATE PRIORITY 666  -->  port 2222
>
> I just mean that in this case the ICE-Lite server must first select
> Req1--1111 pair and then move to Req2--2222 pair.
>
> But in this case:
>
>    ICE-Req-1 USE_CANDIDATE PRIORITY 666  -->  port 1111
> and later:
>    ICE-Req-2 USE_CANDIDATE PRIORITY 555  -->  port 2222
>
> the ICE-Lite server must first select Req1--1111 pair and would NOT
> move to Req1--2222 pair.


The point is that, once the two checks above succeed, the controlling 
agent may choose to send an additional *third* request on *any* of the 
two in order to communicate its desire to use that candidate pair.

This may be the higher priority candidate pair or it may be another one 
(e.g., if it gave a better RTT) and its choice would depend on the 
controlling agent.

Is it clearer now?

Emil

-- 
https://jitsi.org