Re: [rtcweb] Question about ICE-Lite server

[Eric Rescorla <[e-mail]>]

On Sat, Jul 5, 2014 at 9:18 PM, Roman Shpount <[e-mail]> wrote:

> According to RFC 5245: "If its peer has a lite implementation, an agent
> MUST use a regular nomination algorithm." So, this whole problem cannot
> occur.
>

Nice catch. That actually changes things, since Firefox always uses
aggressive nomination and for performance reasons, I'm not excited
about moving to regular nomination. This seems like an argument
for perhaps forbidding ICE-Lite.

I note that this section (8.1.1) actually requires regular nomination in
another situation:

   The controlling agent nominates pairs to be selected by ICE by using
   one of two techniques: regular nomination or aggressive nomination.
   If its peer has a lite implementation, an agent MUST use a regular
   nomination algorithm.  If its peer is using ICE options (present in
   an ice-options attribute from the peer) that the agent does not
   understand, the agent MUST use a regular nomination algorithm.

I note that this has the impact that in the role conflict scenarios
(see appendix B.11) offering half-trickle may throw the other side
into regular nomination (though only if the other side doesn't
support trickle). This is probably an edge case, but I thought I
would point it out.


-Ekr


>  _____________
> Roman Shpount
>
>
> On Fri, Jul 4, 2014 at 9:15 AM, Iñaki Baz Castillo <[e-mail]> wrote:
>
>> Hi,
>>
>> In case of aggressive ICE the controlling agent (let's say: the
>> client), and assuming the client has IPv4 and IPv6 and the ICE-Lite
>> server as well, the server will receive multiple STUN Requests with
>> USE-CANDIDATE and will decide which one to select based on computed
>> candidate-pair priorities (so both the client and server select the
>> same as they follow the same algorithm).
>>
>> Now my question is: let's assume that the server is just provided with
>> local ICE username and password, but knows nothing about the fields in
>> ICE candidates (let's assume that the SDP is negotiated by other
>> entity which does not notify the media server about ICE candidate
>> parameters others than local username and password).
>>
>> So the media server just knows its local ICE username and password,
>> but it receives a ICE Request with USE-CANDIDATE on the IPv4 interface
>> and another on the IPv6 interface.
>>
>> Can the ICE server determine which pair to select (the IPv4 or the
>> IPv6) by just inspecting the PRIORITY attribute in both STUN Requests
>> and select the one with highest value?
>>
>> Or does the server need to assign priority, component and all the ICE
>> stuff to its interfaces and also be provided with the client's and its
>> own ICE candidates?
>>
>> Thanks a lot.
>>
>> --
>> Iñaki Baz Castillo
>> <[e-mail]>
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>