How does WebRTC decide which TURN Servers to Use

Question

Branching off this question WebRTC - How many STUN/TURN servers do I need to specify?

How does WebRTC determine which TURN servers to use when more than one is provided?

Answer 1

Every Ice candidate is given a priority when it is gathered. It is a mixture of a couple of things and I believe that each platform(Chrome, FireFox, etc.) has their own preferences.

Here is a link to the RFC explaining how priorities are to be generated. Each priority is guaranteed to be unique as the candidate ID should be unique(if the RFC is followed). So, you should never have a tie in priorities. Those with higher priorities are tried first, if a connection cannot be made with them, then the next in line is used.

Quote from the RFC Regarding priority:

When using the formula, an agent computes the priority by determining a preference for each type of candidate (server reflexive, peer
reflexive, relayed, and host), and, when the agent is multihomed,
choosing a preference for its IP addresses. These two preferences
are then combined to compute the priority for a candidate. That
priority is computed using the following formula:

    priority = (2^24)*(type preference) +
               (2^8)*(local preference) +
               (2^0)*(256 - component ID)

The type preference MUST be an integer from 0 to 126 inclusive, and represents the preference for the type of the candidate (where the
types are local, server reflexive, peer reflexive, and relayed). A
126 is the highest preference, and a 0 is the lowest. Setting the
value to a 0 means that candidates of this type will only be used as
a last resort. The type preference MUST be identical for all
candidates of the same type and MUST be different for candidates of
different types. The type preference for peer reflexive candidates
MUST be higher than that of server reflexive candidates. Note that
candidates gathered based on the procedures of Section 4.1.1 will
never be peer reflexive candidates; candidates of these type are
learned from the connectivity checks performed by ICE.

The local preference MUST be an integer from 0 to 65535 inclusive. It represents a preference for the particular IP address from which
the candidate was obtained, in cases where an agent is multihomed.
65535 represents the highest preference, and a zero, the lowest.
When there is only a single IP address, this value SHOULD be set to 65535. More generally, if there are multiple candidates for a particular component for a particular media stream that have the same type, the local preference MUST be unique for each one. In this
specification, this only happens for multihomed hosts. If a host is
multihomed because it is dual stack, the local preference SHOULD be
set equal to the precedence value for IP addresses described in RFC
3484 [RFC3484].

The component ID is the component ID for the candidate, and MUST be between 1 and 256 inclusive.

You can see the turn server ip and port is shown in a relay candidate. The following is derived from the RFC page 82 and webrtc hacks.

a=candidate:2157334355<ID> 2<Component> udp<NetType> 33562367<Prioirty> 180.6.6.6<NAT pub IP> 54278<NAT pub Port> typ relay<Means it needs to be relayed through Turn> raddr 46.2.2.2<Relay address of turn> rport 38135<relay port of turn> generation 0