Skip to content
  • Fabrice Bellet's avatar
    candidate: ensuring stun priority uniqueness no more needed · f997215d
    Fabrice Bellet authored and Olivier Crête's avatar Olivier Crête committed
    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 7.1.2.1. 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.
    f997215d