Re: ICE priority levels.

On 02/07/2014 05:20 AM, Kiran Kumar wrote:
> Hi,
> The following is my suggestion to change the spec regarding ICE
> priority levels.
> According to [1]
> "The application gives the users the opportunity to stop it from
>    exposing the host IP address to the application of the other user."
> This can be achieved by communicating only relay candidates to the
> other peer instead of local and stun candidates.
>
> But according to ICE implementations, it will first gather local
> candidates, then stun and finally turn candidates. In this regard, the
> session establishment time will be increased.

I think this is the sequence in which candidates will be tried, not the
sequence in which they are gathered.

>
> So there should be an API or constraint that should convey the
> priority levels for ICE candidate gathering, so that, if user want to
> hide his ip-address, then TURN candidate gathering should take high
> priority instead of local and stun candidate gathering.

It seems logical that the UpdateIce argument "IceTransports"
(http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCIceTransports)
would have such an effect, if needed.

>
> [1]
> http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-13
>
> Thanks,
> Kiran.


-- 
Surveillance is pervasive. Go Dark.