5. ICE Candidate Gathering and Exchange
As part of ICE processing, both the initiating and responding agents
gather candidates, prioritize and eliminate redundant candidates, and
exchange candidate information with the peer as defined by the using
protocol (ICE usage). Specifics of the candidate-encoding mechanism
and the semantics of candidate information exchange is out of scope
of this specification.
5.1. Full Implementation
5.1.1. Gathering Candidates
An ICE agent gathers candidates when it believes that communication
is imminent. An initiating agent can do this based on a user
interface cue or on an explicit request to initiate a session. Every
candidate has a transport address. It also has a type and a base.
Four types are defined and gathered by this specification -- host
candidates, server-reflexive candidates, peer-reflexive candidates,
and relayed candidates. The server-reflexive candidates are gathered
using STUN or TURN, and relayed candidates are obtained through TURN.
Peer-reflexive candidates are obtained in later phases of ICE, as a
consequence of connectivity checks.
The process for gathering candidates at the responding agent is
identical to the process for the initiating agent. It is RECOMMENDED
that the responding agent begin this process immediately on receipt
of the candidate information, prior to alerting the user of the
application associated with the ICE session.
18.104.22.168. Host Candidates
Host candidates are obtained by binding to ports on an IP address
attached to an interface (physical or virtual, including VPN
interfaces) on the host.
For each component of each data stream the ICE agent wishes to use,
the agent SHOULD obtain a candidate on each IP address that the host
has, with the exceptions listed below. The agent obtains each
candidate by binding to a UDP port on the specific IP address. A
host candidate (and indeed every candidate) is always associated with
a specific component for which it is a candidate.
Each component has an ID assigned to it, called the "component ID".
For RTP/RTCP data streams, unless both RTP and RTCP are multiplexed
in the same UDP port (RTP/RTCP multiplexing), the RTP itself has a
component ID of 1, and RTCP has a component ID of 2. In case of RTP/
RTCP multiplexing, a component ID of 1 is used for both RTP and RTCP.
When candidates are obtained, unless the agent knows for sure that
RTP/RTCP multiplexing will be used (i.e., the agent knows that the
other agent also supports, and is willing to use, RTP/RTCP
multiplexing), or unless the agent only supports RTP/RTCP
multiplexing, the agent MUST obtain a separate candidate for RTCP.
If an agent has obtained a candidate for RTCP, and ends up using RTP/
RTCP multiplexing, the agent does not need to perform connectivity
checks on the RTCP candidate. Absence of a component ID 2 as such
does not imply use of RTCP/RTP multiplexing, as it could also mean
that RTCP is not used.
If an agent is using separate candidates for RTP and RTCP, it will
end up with 2*K host candidates if an agent has K IP addresses.
Note that the responding agent, when obtaining its candidates, will
typically know if the other agent supports RTP/RTCP multiplexing, in
which case it will not need to obtain a separate candidate for RTCP.
However, absence of a component ID 2 as such does not imply use of
RTCP/RTP multiplexing, as it could also mean that RTCP is not used.
The use of multiple components, other than for RTP/RTCP streams, is
discouraged as it increases the complexity of ICE processing. If
multiple components are needed, the component IDs SHOULD start with 1
and increase by 1 for each component.
The base for each host candidate is set to the candidate itself.
The host candidates are gathered from all IP addresses with the
o Addresses from a loopback interface MUST NOT be included in the
o Deprecated IPv4-compatible IPv6 addresses [RFC4291] and IPv6 site-
local unicast addresses [RFC3879] MUST NOT be included in the
o IPv4-mapped IPv6 addresses SHOULD NOT be included in the address
candidates unless the application using ICE does not support IPv4
(i.e., it is an IPv6-only application [RFC4038]).
o If gathering one or more host candidates that correspond to an
IPv6 address that was generated using a mechanism that prevents
location tracking [RFC7721], host candidates that correspond to
IPv6 addresses that do allow location tracking, are configured on
the same interface, and are part of the same network prefix MUST
NOT be gathered. Similarly, when host candidates corresponding to
an IPv6 address generated using a mechanism that prevents location
tracking are gathered, then host candidates corresponding to IPv6
link-local addresses [RFC4291] MUST NOT be gathered.
The IPv6 default address selection specification [RFC6724] specifies
that temporary addresses [RFC4941] are to be preferred over permanent
22.214.171.124. Server-Reflexive and Relayed Candidates
An ICE agent SHOULD gather server-reflexive and relayed candidates.
However, use of STUN and TURN servers may be unnecessary in certain
networks and use of TURN servers may be expensive, so some
deployments may elect not to use them. If an agent does not gather
server-reflexive or relayed candidates, it is RECOMMENDED that the
functionality be implemented and just disabled through configuration,
so that it can be re-enabled through configuration if conditions
change in the future.
The agent pairs each host candidate with the STUN or TURN servers
with which it is configured or has discovered by some means. It is
RECOMMENDED that a domain name be configured, the DNS procedures in
[RFC5389] (using SRV records with the "stun" service) be used to
discover the STUN server, and the DNS procedures in [RFC5766] (using
SRV records with the "turn" service) be used to discover the TURN
When multiple STUN or TURN servers are available (or when they are
learned through DNS records and multiple results are returned), the
agent MAY gather candidates for all of them and SHOULD gather
candidates for at least one of them (one STUN server and one TURN
server). It does so by pairing host candidates with STUN or TURN
servers, and for each pair, the agent sends a Binding or Allocate
request to the server from the host candidate. Binding requests to a
STUN server are not authenticated, and any ALTERNATE-SERVER attribute
in a response is ignored. Agents MUST support the backwards-
compatibility mode for the Binding request defined in [RFC5389].
Allocate requests SHOULD be authenticated using a long-term
credential obtained by the client through some other means.
The gathering process is controlled using a timer, Ta. Every time Ta
expires, the agent can generate another new STUN or TURN transaction.
This transaction can be either a retry of a previous transaction that
failed with a recoverable error (such as authentication failure) or a
transaction for a new host candidate and STUN or TURN server pair.
The agent SHOULD NOT generate transactions more frequently than once
per each ta expiration. See Section 14 for guidance on how to set Ta
and the STUN retransmit timer, RTO.
The agent will receive a Binding or Allocate response. A successful
Allocate response will provide the agent with a server-reflexive
candidate (obtained from the mapped address) and a relayed candidate
in the XOR-RELAYED-ADDRESS attribute. If the Allocate request is
rejected because the server lacks resources to fulfill it, the agent
SHOULD instead send a Binding request to obtain a server-reflexive
candidate. A Binding response will provide the agent with only a
server-reflexive candidate (also obtained from the mapped address).
The base of the server-reflexive candidate is the host candidate from
which the Allocate or Binding request was sent. The base of a
relayed candidate is that candidate itself. If a relayed candidate
is identical to a host candidate (which can happen in rare cases),
the relayed candidate MUST be discarded.
If an IPv6-only agent is in a network that utilizes NAT64 [RFC6146]
and DNS64 [RFC6147] technologies, it may also gather IPv4 server-
reflexive and/or relayed candidates from IPv4-only STUN or TURN
servers. IPv6-only agents SHOULD also utilize IPv6 prefix discovery
[RFC7050] to discover the IPv6 prefix used by NAT64 (if any) and
generate server-reflexive candidates for each IPv6-only interface,
accordingly. The NAT64 server-reflexive candidates are prioritized
like IPv4 server-reflexive candidates.
126.96.36.199. Computing Foundations
The ICE agent assigns each candidate a foundation. Two candidates
have the same foundation when all of the following are true:
o They have the same type (host, relayed, server reflexive, or peer
o Their bases have the same IP address (the ports can be different).
o For reflexive and relayed candidates, the STUN or TURN servers
used to obtain them have the same IP address (the IP address used
by the agent to contact the STUN or TURN server).
o They were obtained using the same transport protocol (TCP, UDP).
Similarly, two candidates have different foundations if their types
are different, their bases have different IP addresses, the STUN or
TURN servers used to obtain them have different IP addresses (the IP
addresses used by the agent to contact the STUN or TURN server), or
their transport protocols are different.
188.8.131.52. Keeping Candidates Alive
Once server-reflexive and relayed candidates are allocated, they MUST
be kept alive until ICE processing has completed, as described in
Section 8.3. For server-reflexive candidates learned through a
Binding request, the bindings MUST be kept alive by additional
Binding requests to the server. Refreshes for allocations are done
using the Refresh transaction, as described in [RFC5766]. The
Refresh requests will also refresh the server-reflexive candidate.
Host candidates do not time out, but the candidate addresses may
change or disappear for a number of reasons. An ICE agent SHOULD
monitor the interfaces it uses, invalidate candidates whose base has
gone away, and acquire new candidates as appropriate when new IP
addresses (on new or currently used interfaces) appear.
5.1.2. Prioritizing Candidates
The prioritization process results in the assignment of a priority to
each candidate. Each candidate for a data stream MUST have a unique
priority that MUST be a positive integer between 1 and (2**31 - 1).
This priority will be used by ICE to determine the order of the
connectivity checks and the relative preference for candidates.
Higher-priority values give more priority over lower values.
An ICE agent SHOULD compute this priority using the formula in
Section 184.108.40.206 and choose its parameters using the guidelines in
Section 220.127.116.11. If an agent elects to use a different formula, ICE
may take longer to converge since the agents will not be coordinated
in their checks.
The process for prioritizing candidates is common across the
initiating and the responding agent.
18.104.22.168. Recommended Formula
The recommended formula combines a preference for the candidate type
(server reflexive, peer reflexive, relayed, and host), a preference
for the IP address for which the candidate was obtained, and a
component ID 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 (lowest preference) to
126 (highest preference) inclusive, 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. Setting the
value to 0 means that candidates of this type will only be used as a
last resort. Note that candidates gathered based on the procedures
of Section 5.1.1 will never be peer-reflexive candidates; candidates
of this type are learned from the connectivity checks performed by
The local preference MUST be an integer from 0 (lowest preference) to
65535 (highest preference) inclusive. When there is only a single IP
address, this value SHOULD be set to 65535. If there are multiple
candidates for a particular component for a particular data stream
that have the same type, the local preference MUST be unique for each
one. If an ICE agent is dual stack, the local preference SHOULD be
set according to the current best practice described in [RFC8421].
The component ID MUST be an integer between 1 and 256 inclusive.
22.214.171.124. Guidelines for Choosing Type and Local Preferences
The RECOMMENDED values for type preferences are 126 for host
candidates, 110 for peer-reflexive candidates, 100 for server-
reflexive candidates, and 0 for relayed candidates.
If an ICE agent is multihomed and has multiple IP addresses, the
recommendations in [RFC8421] SHOULD be followed. If multiple TURN
servers are used, local priorities for the candidates obtained from
the TURN servers are chosen in a similar fashion as for multihomed
local candidates: the local preference value is used to indicate a
preference among different servers, but the preference MUST be unique
for each one.
When choosing type preferences, agents may take into account factors
such as latency, packet loss, cost, network topology, security,
privacy, and others.
5.1.3. Eliminating Redundant Candidates
Next, the ICE agents (initiating and responding) eliminate redundant
candidates. Two candidates can have the same transport address yet
different bases, and these would not be considered redundant.
Frequently, a server-reflexive candidate and a host candidate will be
redundant when the agent is not behind a NAT. A candidate is
redundant if and only if its transport address and base equal those
of another candidate. The agent SHOULD eliminate the redundant
candidate with the lower priority.
5.2. Lite Implementation Procedures
Lite implementations only utilize host candidates. For each IP
address, independent of an IP address family, there MUST be zero or
one candidate. With the lite implementation, ICE cannot be used to
dynamically choose amongst candidates. Therefore, including more
than one candidate from a particular IP address family is NOT
RECOMMENDED, since only a connectivity check can truly determine
whether to use one address or the other. Instead, it is RECOMMENDED
that agents that have multiple public IP addresses run full ICE
implementations to ensure the best usage of its addresses.
Each component has an ID assigned to it, called the "component ID".
For RTP/RTCP data streams, unless RTCP is multiplexed in the same
port with RTP, the RTP itself has a component ID of 1 and RTCP a
component ID of 2. If an agent is using RTCP without multiplexing,
it MUST obtain candidates for it. However, absence of a component ID
2 as such does not imply use of RTCP/RTP multiplexing, as it could
also mean that RTCP is not used.
Each candidate is assigned a foundation. The foundation MUST be
different for two candidates allocated from different IP addresses;
otherwise, it MUST be the same. A simple integer that increments for
each IP address will suffice. In addition, each candidate MUST be
assigned a unique priority amongst all candidates for the same data
stream. If the formula in Section 126.96.36.199 is used to calculate the
priority, the type preference value SHOULD be set to 126. If a host
is IPv4 only, the local preference value SHOULD be set to 65535. If
a host is IPv6 or dual stack, the local preference value SHOULD be
set to the precedence value for IP addresses described in RFC 6724
Next, an agent chooses a default candidate for each component of each
data stream. If a host is IPv4 only, there would only be one
candidate for each component of each data stream; therefore, that
candidate is the default. If a host is IPv6 only, the default
candidate would typically be a globally scoped IPv6 address. Dual-
stack hosts SHOULD allow configuration whether IPv4 or IPv6 is used
for the default candidate, and the configuration needs to be based on
which one its administrator believes has a higher chance of success
in the current network environment.
The procedures in this section are common across the initiating and
5.3. Exchanging Candidate Information
ICE agents (initiating and responding) need the following information
about candidates to be exchanged. Each ICE usage MUST define how the
information is exchanged with the using protocol. This section
describes the information that needs to be exchanged.
Candidates: One or more candidates. For each candidate:
Address: The IP address and transport protocol port of the
Transport: The transport protocol of the candidate. This MAY be
omitted if the using protocol only runs over a single transport
Foundation: A sequence of up to 32 characters.
Component ID: The component ID of the candidate. This MAY be
omitted if the using protocol does not use the concept of
Priority: The 32-bit priority of the candidate.
Type: The type of the candidate.
Related Address and Port: The related IP address and port of the
candidate. These MAY be omitted or set to invalid values if
the agent does not want to reveal them, e.g., for privacy
Extensibility Parameters: The using protocol might define means
for adding new per-candidate ICE parameters in the future.
Lite or Full: Whether the agent is a lite agent or full agent.
Connectivity-Check Pacing Value: The pacing value for connectivity
checks that the agent wishes to use. This MAY be omitted if the
agent wishes to use a defined default value.
Username Fragment and Password: Values used to perform connectivity
checks. The values MUST be unguessable, with at least 128 bits of
random number generator output used to generate the password, and
at least 24 bits of output to generate the username fragment.
Extensions: New media-stream or session-level attributes (ICE
If the using protocol is vulnerable to, and able to detect, ICE
mismatch (Section 5.4), a way is needed for the detecting agent to
convey this information to its peer. It is a boolean flag.
The using protocol may (or may not) need to deal with backwards
compatibility with older implementations that do not support ICE. If
a fallback mechanism to non-ICE is supported and is being used, then
presumably the using protocol provides a way of conveying the default
candidate (its IP address and port) in addition to the ICE
Once an agent has sent its candidate information, it MUST be prepared
to receive both STUN and data packets on each candidate. As
discussed in Section 12.1, data packets can be sent to a candidate
prior to its appearance as the default destination for data.
5.4. ICE Mismatch
Certain middleboxes, such as ALGs, can alter signaling information in
ways that break ICE (e.g., by rewriting IP addresses in SDP). This
is referred to as "ICE mismatch". If the using protocol is
vulnerable to ICE mismatch, the responding agent needs to be able to
detect it and inform the peer ICE agent about the ICE mismatch.
Each using protocol needs to define whether the using protocol is
vulnerable to ICE mismatch, how ICE mismatch is detected, and whether
specific actions need to be taken when ICE mismatch is detected.
6. ICE Candidate Processing
Once an ICE agent has gathered its candidates and exchanged
candidates with its peer (Section 5), it will determine its own role.
In addition, full implementations will form checklists and begin
performing connectivity checks with the peer.
6.1. Procedures for Full Implementation
6.1.1. Determining Role
For each session, each ICE agent (initiating and responding) takes on
a role. There are two roles -- controlling and controlled. The
controlling agent is responsible for the choice of the final
candidate pairs used for communications. The sections below describe
in detail the actual procedures followed by controlling and
The rules for determining the role and the impact on behavior are as
Both agents are full: The initiating agent that started the ICE
processing MUST take the controlling role, and the other MUST take
the controlled role. Both agents will form checklists, run the
ICE state machines, and generate connectivity checks. The
controlling agent will execute the logic in Section 8.1 to
nominate pairs that will become (if the connectivity checks
associated with the nominations succeed) the selected pairs, and
then both agents end ICE as described in Section 8.1.2.
One agent full, one lite: The full agent MUST take the controlling
role, and the lite agent MUST take the controlled role. The full
agent will form checklists, run the ICE state machines, and
generate connectivity checks. That agent will execute the logic
in Section 8.1 to nominate pairs that will become (if the
connectivity checks associated with the nominations succeed) the
selected pairs and use the logic in Section 8.1.2 to end ICE. The
lite implementation will just listen for connectivity checks,
receive them and respond to them, and then conclude ICE as
described in Section 8.2. For the lite implementation, the state
of ICE processing for each data stream is considered to be
Running, and the state of ICE overall is Running.
Both lite: The initiating agent that started the ICE processing MUST
take the controlling role, and the other MUST take the controlled
role. In this case, no connectivity checks are ever sent.
Rather, once the candidates are exchanged, each agent performs the
processing described in Section 8 without connectivity checks. It
is possible that both agents will believe they are controlled or
controlling. In the latter case, the conflict is resolved through
glare detection capabilities in the signaling protocol enabling
the candidate exchange. The state of ICE processing for each data
stream is considered to be Running, and the state of ICE overall
Once the roles are determined for a session, they persist throughout
the lifetime of the session. The roles can be redetermined as part
of an ICE restart (Section 9), but an ICE agent MUST NOT redetermine
the role as part of an ICE restart unless one or more of the
following criteria is fulfilled:
Full becomes lite: If the controlling agent is full, and switches to
lite, the roles MUST be redetermined if the peer agent is also
Role conflict: If the ICE restart causes a role conflict, the roles
might be redetermined due to the role conflict procedures in
NOTE: There are certain Third Party Call Control (3PCC) [RFC3725]
scenarios where an ICE restart might cause a role conflict.
NOTE: The agents need to inform each other whether they are full or
lite before the roles are determined. The mechanism for that is
specific to the signaling protocol and outside the scope of the
An agent MUST accept if the peer initiates a redetermination of the
roles even if the criteria for doing so are not fulfilled. This can
happen if the peer is compliant with RFC 5245.
6.1.2. Forming the Checklists
There is one checklist for each data stream. To form a checklist,
initiating and responding ICE agents form candidate pairs, compute
pair priorities, order pairs by priority, prune pairs, remove lower-
priority pairs, and set checklist states. If candidates are added to
a checklist (e.g., due to detection of peer-reflexive candidates),
the agent will re-perform these steps for the updated checklist.
188.8.131.52. Checklist State
Each checklist has a state, which captures the state of ICE checks
for the data stream associated with the checklist. The states are:
Running: The checklist is neither Completed nor Failed yet.
Checklists are initially set to the Running state.
Completed: The checklist contains a nominated pair for each
component of the data stream.
Failed: The checklist does not have a valid pair for each component
of the data stream, and all of the candidate pairs in the
checklist are in either the Failed or the Succeeded state. In
other words, at least one component of the checklist has candidate
pairs that are all in the Failed state, which means the component
has failed, which means the checklist has failed.
184.108.40.206. Forming Candidate Pairs
The ICE agent pairs each local candidate with each remote candidate
for the same component of the same data stream with the same IP
address family. It is possible that some of the local candidates
won't get paired with remote candidates, and some of the remote
candidates won't get paired with local candidates. This can happen
if one agent doesn't include candidates for all of the components for
a data stream. If this happens, the number of components for that
data stream is effectively reduced and is considered to be equal to
the minimum across both agents of the maximum component ID provided
by each agent across all components for the data stream.
In the case of RTP, this would happen when one agent provides
candidates for RTCP, and the other does not. As another example, the
initiating agent can multiplex RTP and RTCP on the same port
[RFC5761]. However, since the initiating agent doesn't know if the
peer agent can perform such multiplexing, it includes candidates for
RTP and RTCP on separate ports. If the peer agent can perform such
multiplexing, it would include just a single component for each
candidate -- for the combined RTP/RTCP mux. ICE would end up acting
as if there was just a single component for this candidate.
With IPv6, it is common for a host to have multiple host candidates
for each interface. To keep the amount of resulting candidate pairs
reasonable and to avoid candidate pairs that are highly unlikely to
work, IPv6 link-local addresses MUST NOT be paired with other than
The candidate pairs whose local and remote candidates are both the
default candidates for a particular component is called the "default
candidate pair" for that component. This is the pair that would be
used to transmit data if both agents had not been ICE aware.
220.127.116.11. Computing Pair Priority and Ordering Pairs
The ICE agent computes a priority for each candidate pair. Let G be
the priority for the candidate provided by the controlling agent.
Let D be the priority for the candidate provided by the controlled
agent. The priority for a pair is computed as follows:
pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)
The agent sorts each checklist in decreasing order of candidate pair
priority. If two pairs have identical priority, the ordering amongst
them is arbitrary.
18.104.22.168. Pruning the Pairs
This sorted list of candidate pairs is used to determine a sequence
of connectivity checks that will be performed. Each check involves
sending a request from a local candidate to a remote candidate.
Since an ICE agent cannot send requests directly from a reflexive
candidate (server reflexive or peer reflexive), but only from its
base, the agent next goes through the sorted list of candidate pairs.
For each pair where the local candidate is reflexive, the candidate
MUST be replaced by its base.
The agent prunes each checklist. This is done by removing a
candidate pair if it is redundant with a higher-priority candidate
pair in the same checklist. Two candidate pairs are redundant if
their local candidates have the same base and their remote candidates
are identical. The result is a sequence of ordered candidate pairs,
called the "checklist" for that data stream.
22.214.171.124. Removing Lower-Priority Pairs
In order to limit the attacks described in Section 19.5.1, an ICE
agent MUST limit the total number of connectivity checks the agent
performs across all checklists in the checklist set. This is done by
limiting the total number of candidate pairs in the checklist set.
The default limit of candidate pairs for the checklist set is 100,
but the value MUST be configurable. The limit is enforced by, within
in each checklist, discarding lower-priority candidate pairs until
the total number of candidate pairs in the checklist set is smaller
than the limit value. The discarding SHOULD be done evenly so that
the number of candidate pairs in each checklist is reduced the same
It is RECOMMENDED that a lower-limit value than the default is picked
when possible, and that the value is set to the maximum number of
plausible candidate pairs that might be created in an actual
deployment configuration. The requirement for configuration is meant
to provide a tool for fixing this value in the field if, once
deployed, it is found to be problematic.
126.96.36.199. Computing Candidate Pair States
Each candidate pair in the checklist has a foundation (the
combination of the foundations of the local and remote candidates in
the pair) and one of the following states:
Waiting: A check has not been sent for this pair, but the pair is
In-Progress: A check has been sent for this pair, but the
transaction is in progress.
Succeeded: A check has been sent for this pair, and it produced a
Failed: A check has been sent for this pair, and it failed (a
response to the check was never received, or a failure response
Frozen: A check for this pair has not been sent, and it cannot be
sent until the pair is unfrozen and moved into the Waiting state.
The initial states for each pair in a checklist are computed by
performing the following sequence of steps:
1. The checklists are placed in an ordered list (the order is
determined by each ICE usage), called the "checklist set".
2. The ICE agent initially places all candidate pairs in the Frozen
3. The agent sets all of the checklists in the checklist set to the
4. For each foundation, the agent sets the state of exactly one
candidate pair to the Waiting state (unfreezing it). The
candidate pair to unfreeze is chosen by finding the first
candidate pair (ordered by the lowest component ID and then the
highest priority if component IDs are equal) in the first
checklist (according to the usage-defined checklist set order)
that has that foundation.
NOTE: The procedures above are different from RFC 5245, where only
candidate pairs in the first checklist were initially placed in the
Waiting state. Now it applies to candidate pairs in the first
checklist that have that foundation, even if the checklist is not the
first one in the checklist set.
The table below illustrates an example.
Each row (m1, m2,...) represents a checklist associated with a
data stream. m1 represents the first checklist in the checklist
Each column (f1, f2,...) represents a foundation. Every candidate
pair within a given column share the same foundation.
f-cp represents a candidate pair in the Frozen state.
w-cp represents a candidate pair in the Waiting state.
1. The agent sets all of the pairs in the checklist set to the
f1 f2 f3 f4 f5
m1 | f-cp f-cp f-cp
m2 | f-cp f-cp f-cp f-cp
m3 | f-cp f-cp
2. For each foundation, the candidate pair with the lowest
component ID is placed in the Waiting state, unless a
candidate pair associated with the same foundation has
already been put in the Waiting state in one of the
other examined checklists in the checklist set.
f1 f2 f3 f4 f5
m1 | w-cp w-cp w-cp
m2 | f-cp f-cp f-cp w-cp
m3 | f-cp w-cp
Table 1: Pair State Example
In the first checklist (m1), the candidate pair for each foundation
is placed in the Waiting state, as no pairs for the same foundations
have yet been placed in the Waiting state.
In the second checklist (m2), the candidate pair for foundation f4 is
placed in the Waiting state. The candidate pair for foundations f1,
f2, and f3 are kept in the Frozen state, as candidate pairs for those
foundations have already been placed in the Waiting state (within
In the third checklist (m3), the candidate pair for foundation f5 is
placed in the Waiting state. The candidate pair for foundation f1 is
kept in the Frozen state, as a candidate pair for that foundation has
already been placed in the Waiting state (within checklist m1).
Once each checklist have been processed, one candidate pair for each
foundation in the checklist set has been placed in the Waiting state.
6.1.3. ICE State
The ICE agent has a state determined by the state of the checklists.
The state is Completed if all checklists are Completed, Failed if all
checklists are Failed, or Running otherwise.
6.1.4. Scheduling Checks
188.8.131.52. Triggered-Check Queue
Once the ICE agent has computed the checklists and created the
checklist set, as described in Section 6.1.2, the agent will begin
performing connectivity checks (ordinary and triggered). For
triggered connectivity checks, the agent maintains a FIFO queue for
each checklist, referred to as the "triggered-check queue", which
contains candidate pairs for which checks are to be sent at the next
available opportunity. The triggered-check queue is initially empty.
184.108.40.206. Performing Connectivity Checks
The generation of ordinary and triggered connectivity checks is
governed by timer Ta. As soon as the initial states for the
candidate pairs in the checklist set have been set, a check is
performed for a candidate pair within the first checklist in the
Running state, following the procedures in Section 7. After that,
whenever Ta fires the next checklist in the Running state in the
checklist set is picked, and a check is performed for a candidate
within that checklist. After the last checklist in the Running state
in the checklist set has been processed, the first checklist is
picked again, etc.
Whenever Ta fires, the ICE agent will perform a check for a candidate
pair within the checklist that was picked by performing the following
1. If the triggered-check queue associated with the checklist
contains one or more candidate pairs, the agent removes the top
pair from the queue, performs a connectivity check on that pair,
puts the candidate pair state to In-Progress, and aborts the
2. If there is no candidate pair in the Waiting state, and if there
are one or more pairs in the Frozen state, the agent checks the
foundation associated with each pair in the Frozen state. For a
given foundation, if there is no pair (in any checklist in the
checklist set) in the Waiting or In-Progress state, the agent
puts the candidate pair state to Waiting and continues with the
3. If there are one or more candidate pairs in the Waiting state,
the agent picks the highest-priority candidate pair (if there are
multiple pairs with the same priority, the pair with the lowest
component ID is picked) in the Waiting state, performs a
connectivity check on that pair, puts the candidate pair state to
In-Progress, and aborts the subsequent steps.
4. If this step is reached, no check could be performed for the
checklist that was picked. So, without waiting for timer Ta to
expire again, select the next checklist in the Running state and
return to step #1. If this happens for every single checklist in
the Running state, meaning there are no remaining candidate pairs
to perform connectivity checks for, abort these steps.
Once the agent has picked a candidate pair for which a connectivity
check is to be performed, the agent starts a check and sends the
Binding request from the base associated with the local candidate of
the pair to the remote candidate of the pair, as described in
Based on local policy, an agent MAY choose to terminate performing
the connectivity checks for one or more checklists in the checklist
set at any time. However, only the controlling agent is allowed to
conclude ICE (Section 8).
To compute the message integrity for the check, the agent uses the
remote username fragment and password learned from the candidate
information obtained from its peer. The local username fragment is
known directly by the agent for its own candidate.
6.2. Lite Implementation Procedures
Lite implementations skip most of the steps in Section 6 except for
verifying the peer's ICE support and determining its role in the ICE
If the lite implementation is the controlling agent (which will only
happen if the peer ICE agent is also a lite implementation), it
selects a candidate pair based on the ones in the candidate exchange
(for IPv4, there is only ever one pair) and then updates the peer
with the new candidate information reflecting that selection, if
needed (it is never needed for an IPv4-only host).