Re: ICE priority levels.

     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.