- From: Byron Campen <docfaraday@gmail.com>
- Date: Thu, 06 Feb 2014 20:40:35 -0800
- To: Kiran Kumar <g.kiranreddy4u@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Gathering is done in parallel, without any throttling, so the
gathering of relayed candidates will not be delayed by host or server
reflexive ones.
Best regards,
Byron Campen
On 2/6/14 8:20 PM, 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.
>
> 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.
>
> [1]
> http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-13
>
> Thanks,
> Kiran.
Received on Friday, 7 February 2014 04:41:05 UTC