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
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:54 UTC