Commit f997215d authored by Committed by Olivier CrêteBrowse files
candidate: ensuring stun priority uniqueness no more needed
The uniqueness of candidate priorities is achieved by the iteration on the ip local addresses for local host candidates, and also on their base address for reflexive and relay candidates. Helper function checking its uniqueness at allocation time is not required anyore. The priority of the stun request (prflx_priority) is built from the priority of the local candidate of the pair, according the RFC 5245, section 18.104.22.168. This priority must be identical to a virtual "local candidate of type peer-reflexive that would be learned as a consequence of a check from this local candidate." Outgoing stun requests will come from local candidates of type host or type relayed. The priority uniqueness of local candidates of type host implies the uniqueness of the computed peer-reflexive priority. And relay local candidates cannot produce a peer-reflexive local candidate by design, so we can safely use their unique local priority too in the stun request.
Showing with 21 additions and 73 deletions