RFC 8445
Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal
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.5.1.1.1. 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
following exceptions:
o Addresses from a loopback interface MUST NOT be included in the
candidate addresses.
o Deprecated IPv4-compatible IPv6 addresses [RFC4291] and IPv6 site-
local unicast addresses [RFC3879] MUST NOT be included in the
address candidates.
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
addresses.
5.1.1.2. 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
server.
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.5.1.1.3. 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 reflexive). 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.
5.1.1.4. 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 5.1.2.1 and choose its parameters using the guidelines in Section 5.1.2.2. 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.5.1.2.1. 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 ICE. 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.5.1.2.2. 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 5.1.2.1 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 [RFC6724]. 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 responding agents.
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 candidate. Transport: The transport protocol of the candidate. This MAY be omitted if the using protocol only runs over a single transport protocol. 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 components. 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 reasons. 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 options).
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 parameters. 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 controlled agents.
The rules for determining the role and the impact on behavior are as
follows:
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
is Running.
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
full.
Role conflict: If the ICE restart causes a role conflict, the roles
might be redetermined due to the role conflict procedures in
Section 7.3.1.1.
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
document.
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.
6.1.2.1. 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.
6.1.2.2. 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 link-local addresses. 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.
Figure 5 shows the properties of and relationships between transport addresses, candidates, candidate pairs, and checklists. +--------------------------------------------+ | | | +---------------------+ | | |+----+ +----+ +----+ | +Type | | || IP | |Port| |Tran| | +Priority | | ||Addr| | | | | | +Foundation | | |+----+ +----+ +----+ | +Component ID | | | Transport | +Related Address | | | Addr | | | +---------------------+ +Base | | Candidate | +--------------------------------------------+ * * * ************************************* * * +-------------------------------+ | | | Local Remote | | +----+ +----+ +default? | | |Cand| |Cand| +valid? | | +----+ +----+ +nominated?| | +State | | | | | | Candidate Pair | +-------------------------------+ * * * ************ * * +------------------+ | Candidate Pair | +------------------+ +------------------+ | Candidate Pair | +------------------+ +------------------+ | Candidate Pair | +------------------+ Checklist Figure 5: Conceptual Diagram of a Checklist
6.1.2.3. 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.6.1.2.4. 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.6.1.2.5. 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 amount. 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.6.1.2.6. 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 not Frozen. 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 successful result. Failed: A check has been sent for this pair, and it failed (a response to the check was never received, or a failure response was received). 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.
Pairs move between states as shown in Figure 6. +-----------+ | | | | | Frozen | | | | | +-----------+ | |unfreeze | V +-----------+ +-----------+ | | | | | | perform | | | Waiting |-------->|In-Progress| | | | | | | | | +-----------+ +-----------+ / | // | // | // | / | // | failure // |success // | / | // | // | // | V V +-----------+ +-----------+ | | | | | | | | | Failed | | Succeeded | | | | | | | | | +-----------+ +-----------+ Figure 6: Pair State Finite State Machine (FSM)
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
state.
3. The agent sets all of the checklists in the checklist set to the
Running state.
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.
Table legend:
Each row (m1, m2,...) represents a checklist associated with a
data stream. m1 represents the first checklist in the checklist
set.
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
Frozen state.
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 checklist m1). 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
6.1.4.1. 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.6.1.4.2. 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
steps:
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
subsequent steps.
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
next step.
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
Section 7.2.4.
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 processing. 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).
(page 38 continued on part 3)
