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

The PRIORITY attribute is only for determining priority for peer-reflexive
candidates. Using it to change priority for other types of candidates would
be a significant change in semantics; I don't want to go there.

On Thu, Jul 24, 2014 at 11:46 AM, Emil Ivov <emcho@jitsi.org> wrote:

>
>
> On 24.07.14, 11:33, Iñaki Baz Castillo wrote:
>
>> 2014-07-24 17:15 GMT+02:00 Emil Ivov <emcho@jitsi.org>:
>>
>>> 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
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>