W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2014

Re: ICE priority levels.

From: Harald Alvestrand <harald@alvestrand.no>
Date: Fri, 07 Feb 2014 14:48:38 +0100
Message-ID: <52F4E436.9040008@alvestrand.no>
To: public-webrtc@w3.org
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.
Received on Friday, 7 February 2014 13:49:10 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:38 UTC