7. Performing Connectivity Checks This section describes how connectivity checks are performed. An ICE agent MUST be compliant to [RFC5389]. A full implementation acts both as a STUN client and a STUN server, while a lite implementation only acts as a STUN server (as it does not generate connectivity checks). 7.1. STUN Extensions ICE extends STUN with the attributes: PRIORITY, USE-CANDIDATE, ICE- CONTROLLED, and ICE-CONTROLLING. These attributes are formally defined in Section 16.1. This section describes the usage of the attributes. The attributes are only applicable to ICE connectivity checks. 7.1.1. PRIORITY The PRIORITY attribute MUST be included in a Binding request and be set to the value computed by the algorithm in Section 5.1.2 for the local candidate, but with the candidate type preference of peer- reflexive candidates. 7.1.2. USE-CANDIDATE The controlling agent MUST include the USE-CANDIDATE attribute in order to nominate a candidate pair (Section 8.1.1). The controlled agent MUST NOT include the USE-CANDIDATE attribute in a Binding request.
7.1.3. ICE-CONTROLLED and ICE-CONTROLLING The controlling agent MUST include the ICE-CONTROLLING attribute in a Binding request. The controlled agent MUST include the ICE- CONTROLLED attribute in a Binding request. The content of either attribute is used as tiebreaker values when an ICE role conflict occurs (Section 188.8.131.52). 7.2. STUN Client Procedures 7.2.1. Creating Permissions for Relayed Candidates If the connectivity check is being sent using a relayed local candidate, the client MUST create a permission first if it has not already created one previously. It would have created one previously if it had told the TURN server to create a permission for the given relayed candidate towards the IP address of the remote candidate. To create the permission, the ICE agent follows the procedures defined in [RFC5766]. The permission MUST be created towards the IP address of the remote candidate. It is RECOMMENDED that the agent defer creation of a TURN channel until ICE completes, in which case permissions for connectivity checks are normally created using a CreatePermission request. Once established, the agent MUST keep the permission active until ICE concludes. 7.2.2. Forming Credentials A connectivity-check Binding request MUST utilize the STUN short-term credential mechanism. The username for the credential is formed by concatenating the username fragment provided by the peer with the username fragment of the ICE agent sending the request, separated by a colon (":"). The password is equal to the password provided by the peer. For example, consider the case where ICE agent L is the initiating agent and ICE agent R is the responding agent. Agent L included a username fragment of LFRAG for its candidates and a password of LPASS. Agent R provided a username fragment of RFRAG and a password of RPASS. A connectivity check from L to R utilizes the username RFRAG:LFRAG and a password of RPASS. A connectivity check from R to L utilizes the username LFRAG:RFRAG and a password of LPASS. The responses utilize the same usernames and passwords as the requests (note that the USERNAME attribute is not present in the response).
7.2.3. Diffserv Treatment If the agent is using Differentiated Services Code Point (DSCP) markings [RFC2475] in data packets that it will send, the agent SHOULD apply the same markings to Binding requests and responses that it will send. If multiple DSCP markings are used on the data packets, the agent SHOULD choose one of them for use with the connectivity check. 7.2.4. Sending the Request A connectivity check is generated by sending a Binding request from the base associated with a local candidate to a remote candidate. [RFC5389] describes how Binding requests are constructed and generated. Support for backwards compatibility with RFC 3489 MUST NOT be assumed when performing connectivity checks. The FINGERPRINT mechanism MUST be used for connectivity checks. 7.2.5. Processing the Response This section defines additional procedures for processing Binding responses specific to ICE connectivity checks. When a Binding response is received, it is correlated to the corresponding Binding request using the transaction ID [RFC5389], which then associates the response with the candidate pair for which the Binding request was sent. After that, the response is processed according to the procedures for a role conflict, a failure, or a success, according to the procedures below. 184.108.40.206. Role Conflict If the Binding request generates a 487 (Role Conflict) error response (Section 220.127.116.11), and if the ICE agent included an ICE-CONTROLLED attribute in the request, the agent MUST switch to the controlling role. If the agent included an ICE-CONTROLLING attribute in the request, the agent MUST switch to the controlled role. Once the agent has switched its role, the agent MUST add the candidate pair whose check generated the 487 error response to the triggered-check queue associated with the checklist to which the pair belongs, and set the candidate pair state to Waiting. When the triggered connectivity check is later performed, the ICE-CONTROLLING/ ICE-CONTROLLED attribute of the Binding request will indicate the agent's new role. The agent MUST change the tiebreaker value.
NOTE: A role switch requires an agent to recompute pair priorities (Section 18.104.22.168), since the priority values depend on the role. NOTE: A role switch will also impact whether the agent is responsible for nominating candidate pairs, and whether the agent is responsible for initiating the exchange of the updated candidate information with the peer once ICE is concluded. 22.214.171.124. Failure This section describes cases when the candidate pair state is set to Failed. NOTE: When the ICE agent sets the candidate pair state to Failed as a result of a connectivity-check error, the agent does not change the states of other candidate pairs with the same foundation. 126.96.36.199.1. Non-Symmetric Transport Addresses The ICE agent MUST check that the source and destination transport addresses in the Binding request and response are symmetric. That is, the source IP address and port of the response MUST be equal to the destination IP address and port to which the Binding request was sent, and the destination IP address and port of the response MUST be equal to the source IP address and port from which the Binding request was sent. If the addresses are not symmetric, the agent MUST set the candidate pair state to Failed. 188.8.131.52.2. ICMP Error An ICE agent MAY support processing of ICMP errors for connectivity checks. If the agent supports processing of ICMP errors, and if a Binding request generates a hard ICMP error, the agent SHOULD set the state of the candidate pair to Failed. Implementers need to be aware that ICMP errors can be used as a method for Denial-of-Service (DoS) attacks when making a decision on how and if to process ICMP errors. 184.108.40.206.3. Timeout If the Binding request transaction times out, the ICE agent MUST set the candidate pair state to Failed. 220.127.116.11.4. Unrecoverable STUN Response If the Binding request generates a STUN error response that is unrecoverable [RFC5389], the ICE agent SHOULD set the candidate pair state to Failed.
18.104.22.168. Success A connectivity check is considered a success if each of the following criteria is true: o The Binding request generated a success response; and o The source and destination transport addresses in the Binding request and response are symmetric. If a check is considered a success, the ICE agent performs (in order) the actions described in the following sections. 22.214.171.124.1. Discovering Peer-Reflexive Candidates The ICE agent MUST check the mapped address from the STUN response. If the transport address does not match any of the local candidates that the agent knows about, the mapped address represents a new candidate: a peer-reflexive candidate. Like other candidates, a peer-reflexive candidate has a type, base, priority, and foundation. They are computed as follows: o The type is peer reflexive. o The base is the local candidate of the candidate pair from which the Binding request was sent. o The priority is the value of the PRIORITY attribute in the Binding request. o The foundation is described in Section 126.96.36.199. The peer-reflexive candidate is then added to the list of local candidates for the data stream. The username fragment and password are the same as for all other local candidates for that data stream. The ICE agent does not need to pair the peer-reflexive candidate with remote candidates, as a valid pair will be created due to the procedures in Section 188.8.131.52.2. If an agent wishes to pair the peer-reflexive candidate with remote candidates other than the one in the valid pair that will be generated, the agent MAY provide updated candidate information to the peer that includes the peer-reflexive candidate. This will cause the peer-reflexive candidate to be paired with all other remote candidates.
184.108.40.206.2. Constructing a Valid Pair The ICE agent constructs a candidate pair whose local candidate equals the mapped address of the response and whose remote candidate equals the destination address to which the request was sent. This is called a "valid pair". The valid pair might equal the pair that generated the connectivity check, a different pair in the checklist, or a pair currently not in the checklist. The agent maintains a separate list, referred to as the "valid list". There is a valid list for each checklist in the checklist set. The valid list will contain valid pairs. Initially, each valid list is empty. Each valid pair within the valid list has a flag, called the "nominated flag". When a valid pair is added to a valid list, the flag value is set to 'false'. The valid pair will be added to a valid list as follows: 1. If the valid pair equals the pair that generated the check, the pair is added to the valid list associated with the checklist to which the pair belongs; or 2. If the valid pair equals another pair in a checklist, that pair is added to the valid list associated with the checklist of that pair. The pair that generated the check is not added to a valid list; or 3. If the valid pair is not in any checklist, the agent computes the priority for the pair based on the priority of each candidate, using the algorithm in Section 6.1.2. The priority of the local candidate depends on its type. Unless the type is peer reflexive, the priority is equal to the priority signaled for that candidate in the candidate exchange. If the type is peer reflexive, it is equal to the PRIORITY attribute the agent placed in the Binding request that just completed. The priority of the remote candidate is taken from the candidate information of the peer. If the candidate does not appear there, then the check has been a triggered check to a new remote candidate. In that case, the priority is taken as the value of the PRIORITY attribute in the Binding request that triggered the check that just completed. The pair is then added to the valid list.
NOTE: It will be very common that the valid pair will not be in any checklist. Recall that the checklist has pairs whose local candidates are never reflexive; those pairs had their local candidates converted to the base of the reflexive candidates and were then pruned if they were redundant. When the response to the Binding request arrives, the mapped address will be reflexive if there is a NAT between the two. In that case, the valid pair will have a local candidate that doesn't match any of the pairs in the checklist. 220.127.116.11.3. Updating Candidate Pair States The ICE agent sets the states of both the candidate pair that generated the check and the constructed valid pair (which may be different) to Succeeded. The agent MUST set the states for all other Frozen candidate pairs in all checklists with the same foundation to Waiting. NOTE: Within a given checklist, candidate pairs with the same foundations will typically have different component ID values. 18.104.22.168.4. Updating the Nominated Flag If the controlling agent sends a Binding request with the USE- CANDIDATE attribute set, and if the ICE agent receives a successful response to the request, the agent sets the nominated flag of the pair to true. If the request fails (Section 22.214.171.124), the agent MUST remove the candidate pair from the valid list, set the candidate pair state to Failed, and set the checklist state to Failed. If the controlled agent receives a successful response to a Binding request sent by the agent, and that Binding request was triggered by a received Binding request with the USE-CANDIDATE attribute set (Section 126.96.36.199), the agent sets the nominated flag of the pair to true. If the triggered request fails, the agent MUST remove the candidate pair from the valid list, set the candidate pair state to Failed, and set the checklist state to Failed. Once the nominated flag is set for a component of a data stream, it concludes the ICE processing for that component (Section 8). 188.8.131.52. Checklist State Updates Regardless of whether a connectivity check was successful or failed, the completion of the check may require updating of checklist states. For each checklist in the checklist set, if all of the candidate pairs are in either Failed or Succeeded state, and if there is not a valid pair in the valid list for each component of the data stream
associated with the checklist, the state of the checklist is set to Failed. If there is a valid pair for each component in the valid list, the state of the checklist is set to Succeeded. 7.3. STUN Server Procedures An ICE agent (lite or full) MUST be prepared to receive Binding requests on the base of each candidate it included in its most recent candidate exchange. The agent MUST use the short-term credential mechanism (i.e., the MESSAGE-INTEGRITY attribute) to authenticate the request and perform a message integrity check. Likewise, the short-term credential mechanism MUST be used for the response. The agent MUST consider the username to be valid if it consists of two values separated by a colon, where the first value is equal to the username fragment generated by the agent in a candidate exchange for a session in progress. It is possible (and in fact very likely) that the initiating agent will receive a Binding request prior to receiving the candidates from its peer. If this happens, the agent MUST immediately generate a response (including computation of the mapped address as described in Section 184.108.40.206). The agent has sufficient information at this point to generate the response; the password from the peer is not required. Once the answer is received, it MUST proceed with the remaining steps required; namely, see Sections 220.127.116.11, 18.104.22.168, and 22.214.171.124 for full implementations. In cases where multiple STUN requests are received before the answer, this may cause several pairs to be queued up in the triggered-check queue. An agent MUST NOT utilize the ALTERNATE-SERVER mechanism and MUST NOT support the backwards-compatibility mechanisms defined in RFC 5389 (for working with the protocol in RFC 3489). It MUST utilize the FINGERPRINT mechanism. If the agent is using DSCP markings [RFC2475] in its data packets, it SHOULD apply the same markings to Binding responses. The same would apply to any Layer 2 markings the endpoint might be applying to data packets. 7.3.1. Additional Procedures for Full Implementations This subsection defines the additional server procedures applicable to full implementations, when the full implementation accepts the Binding request.
126.96.36.199. Detecting and Repairing Role Conflicts In certain usages of ICE (such as 3PCC), both ICE agents may end up choosing the same role, resulting in a role conflict. The section describes a mechanism for detecting and repairing role conflicts. The usage document MUST specify whether this mechanism is needed. An agent MUST examine the Binding request for either the ICE- CONTROLLING or ICE-CONTROLLED attribute. It MUST follow these procedures: o If the agent is in the controlling role, and the ICE-CONTROLLING attribute is present in the request: * If the agent's tiebreaker value is larger than or equal to the contents of the ICE-CONTROLLING attribute, the agent generates a Binding error response and includes an ERROR-CODE attribute with a value of 487 (Role Conflict) but retains its role. * If the agent's tiebreaker value is less than the contents of the ICE-CONTROLLING attribute, the agent switches to the controlled role. o If the agent is in the controlled role, and the ICE-CONTROLLED attribute is present in the request: * If the agent's tiebreaker value is larger than or equal to the contents of the ICE-CONTROLLED attribute, the agent switches to the controlling role. * If the agent's tiebreaker value is less than the contents of the ICE-CONTROLLED attribute, the agent generates a Binding error response and includes an ERROR-CODE attribute with a value of 487 (Role Conflict) but retains its role. o If the agent is in the controlled role and the ICE-CONTROLLING attribute was present in the request, or if the agent was in the controlling role and the ICE-CONTROLLED attribute was present in the request, there is no conflict. A change in roles will require an agent to recompute pair priorities (Section 188.8.131.52), since those priorities are a function of role. The change in role will also impact whether the agent is responsible for selecting nominated pairs and initiating exchange with updated candidate information upon conclusion of ICE.
The remaining subsections in Section 7.3.1 are followed if the agent generated a successful response to the Binding request, even if the agent changed roles. 184.108.40.206. Computing Mapped Addresses For requests received on a relayed candidate, the source transport address used for STUN processing (namely, generation of the XOR-MAPPED-ADDRESS attribute) is the transport address as seen by the TURN server. That source transport address will be present in the XOR-PEER-ADDRESS attribute of a Data Indication message, if the Binding request was delivered through a Data Indication. If the Binding request was delivered through a ChannelData message, the source transport address is the one that was bound to the channel. 220.127.116.11. Learning Peer-Reflexive Candidates If the source transport address of the request does not match any existing remote candidates, it represents a new peer-reflexive remote candidate. This candidate is constructed as follows: o The type is peer reflexive. o The priority is the value of the PRIORITY attribute in the Binding request. o The foundation is an arbitrary value, different from the foundations of all other remote candidates. If any subsequent candidate exchanges contain this peer-reflexive candidate, it will signal the actual foundation for the candidate. o The component ID is the component ID of the local candidate to which the request was sent. This candidate is added to the list of remote candidates. However, the ICE agent does not pair this candidate with any local candidates. 18.104.22.168. Triggered Checks Next, the agent constructs a pair whose local candidate has the transport address (as seen by the agent) on which the STUN request was received and a remote candidate equal to the source transport address where the request came from (which may be the peer-reflexive remote candidate that was just learned). The local candidate will be either a host candidate (for cases where the request was not received through a relay) or a relayed candidate (for cases where it is received through a relay). The local candidate can never be a server-reflexive candidate. Since both candidates are known to the
agent, it can obtain their priorities and compute the candidate pair priority. This pair is then looked up in the checklist. There can be one of several outcomes: o When the pair is already on the checklist: * If the state of that pair is Succeeded, nothing further is done. * If the state of that pair is In-Progress, the agent cancels the In-Progress transaction. Cancellation means that the agent will not retransmit the Binding requests associated with the connectivity-check transaction, will not treat the lack of response to be a failure, but will wait the duration of the transaction timeout for a response. In addition, the agent MUST enqueue the pair in the triggered checklist associated with the checklist, and set the state of the pair to Waiting, in order to trigger a new connectivity check of the pair. Creating a new connectivity check enables validating In-Progress pairs as soon as possible, without having to wait for retransmissions of the Binding requests associated with the original connectivity-check transaction. * If the state of that pair is Waiting, Frozen, or Failed, the agent MUST enqueue the pair in the triggered checklist associated with the checklist (if not already present), and set the state of the pair to Waiting, in order to trigger a new connectivity check of the pair. Note that a state change of the pair from Failed to Waiting might also trigger a state change of the associated checklist. These steps are done to facilitate rapid completion of ICE when both agents are behind NAT. o If the pair is not already on the checklist: * The pair is inserted into the checklist based on its priority. * Its state is set to Waiting. * The pair is enqueued into the triggered-check queue. When a triggered check is to be sent, it is constructed and processed as described in Section 7.2.4. These procedures require the agent to know the transport address, username fragment, and password for the peer. The username fragment for the remote candidate is equal to the part after the colon of the USERNAME in the Binding request that was just received. Using that username fragment, the agent can check the
candidates received from its peer (there may be more than one in cases of forking) and find this username fragment. The corresponding password is then picked. 22.214.171.124. Updating the Nominated Flag If the controlled agent receives a Binding request with the USE- CANDIDATE attribute set, and if the ICE agent accepts the request, the following action is based on the state of the pair computed in Section 126.96.36.199: o If the state of this pair is Succeeded, it means that the check previously sent by this pair produced a successful response and generated a valid pair (Section 188.8.131.52.2). The agent sets the nominated flag value of the valid pair to true. o If the received Binding request triggered a new check to be enqueued in the triggered-check queue (Section 184.108.40.206), once the check is sent and if it generates a successful response, and generates a valid pair, the agent sets the nominated flag of the pair to true. If the request fails (Section 220.127.116.11), the agent MUST remove the candidate pair from the valid list, set the candidate pair state to Failed, and set the checklist state to Failed. If the controlled agent does not accept the request from the controlling agent, the controlled agent MUST reject the nomination request with an appropriate error code response (e.g., 400) [RFC5389]. Once the nominated flag is set for a component of a data stream, it concludes the ICE processing for that component. See Section 8. 7.3.2. Additional Procedures for Lite Implementations If the controlled agent receives a Binding request with the USE- CANDIDATE attribute set, and if the ICE agent accepts the request, the agent constructs a candidate pair whose local candidate has the transport address on which the request was received, and whose remote candidate is equal to the source transport address of the request that was received. This candidate pair is assigned an arbitrary priority and placed into the valid list of the associated checklist. The agent sets the nominated flag for that pair to true. Once the nominated flag is set for a component of a data stream, it concludes the ICE processing for that component. See Section 8.
8. Concluding ICE Processing This section describes how an ICE agent completes ICE. 8.1. Procedures for Full Implementations Concluding ICE involves nominating pairs by the controlling agent and updating state machinery. 8.1.1. Nominating Pairs Prior to nominating, the controlling agent lets connectivity checks continue until some stopping criterion is met. After that, based on an evaluation criterion, the controlling agent picks a pair among the valid pairs in the valid list for nomination. Once the controlling agent has picked a valid pair for nomination, it repeats the connectivity check that produced this valid pair (by enqueueing the pair that generated the check into the triggered-check queue), this time with the USE-CANDIDATE attribute (Section 18.104.22.168.4). The procedures for the controlled agent are described in Section 22.214.171.124. Eventually, if the nominations succeed, both the controlling and controlled agents will have a single nominated pair in the valid list for each component of the data stream. Once an ICE agent sets the state of the checklist to Completed (when there is a nominated pair for each component of the data stream), that pair becomes the selected pair for that agent and is used for sending and receiving data for that component of the data stream. If an agent is not able to produce selected pairs for each component of a data stream, the agent MUST take proper actions for informing the other agent, e.g., by removing the stream. The exact actions are outside the scope of this specification. The criteria for stopping the connectivity checks and for picking a pair for nomination are outside the scope of this specification. They are a matter of local optimization. The only requirement is that the agent MUST eventually pick one and only one candidate pair and generate a check for that pair with the USE-CANDIDATE attribute set. Once the controlling agent has successfully nominated a candidate pair (Section 126.96.36.199.4), the agent MUST NOT nominate another pair for same component of the data stream within the ICE session. Doing so requires an ICE restart.
A controlling agent that does not support this specification (i.e., it is implemented according to RFC 5245) might nominate more than one candidate pair. This was referred to as "aggressive nomination" in RFC 5245. If more than one candidate pair is nominated by the controlling agent, and if the controlled agent accepts multiple nominations requests, the agents MUST produce the selected pairs and use the pairs with the highest priority. The usage of the 'ice2' ICE option (Section 10) by endpoints supporting this specification is supposed to prevent controlling agents that are implemented according to RFC 5245 from using aggressive nomination. NOTE: In RFC 5245, usage of "aggressive nomination" allowed agents to continuously nominate pairs, before a pair was eventually selected, in order to allow sending of data on those pairs. In this specification, data can always be sent on any valid pair, without nomination. Hence, there is no longer a need for aggressive nomination. 8.1.2. Updating Checklist and ICE States For both a controlling and a controlled agent, when a candidate pair for a component of a data stream gets nominated, it might impact other pairs in the checklist associated with the data stream. It might also impact the state of the checklist: o Once a candidate pair for a component of a data stream has been nominated, and the state of the checklist associated with the data stream is Running, the ICE agent MUST remove all candidate pairs for the same component from the checklist and from the triggered- check queue. If the state of a pair is In-Progress, the agent cancels the In-Progress transaction. Cancellation means that the agent will not retransmit the Binding requests associated with the connectivity-check transaction, will not treat the lack of response to be a failure, but will wait the duration of the transaction timeout for a response. o Once candidate pairs for each component of a data stream have been nominated, and the state of the checklist associated with the data stream is Running, the ICE agent sets the state of the checklist to Completed. o Once a candidate pair for a component of a data stream has been nominated, an agent MUST continue to respond to any Binding request it might still receive for the nominated pair and for any remaining candidate pairs in the checklist associated with the
data stream. As defined in Section 188.8.131.52, when the state of a pair is Succeeded, an agent will no longer generate triggered checks when receiving a Binding request for the pair. Once the state of each checklist in the checklist set is Completed, the agent sets the state of the ICE session to Completed. If the state of a checklist is Failed, ICE has not been able to successfully complete the process for the data stream associated with the checklist. The correct behavior depends on the state of the checklists in the checklist set. If the controlling agent wants to continue the session without the data stream associated with the Failed checklist, and if there are still one or more checklists in Running or Completed mode, the agent can let the ICE processing continue. The agent MUST take proper actions for removing the failed data stream. If the controlling agent does not want to continue the session and MUST terminate the session, the state of the ICE session is set to Failed. If the state of each checklist in the checklist set is Failed, the state of the ICE session is set to Failed. Unless the controlling agent wants to continue the session without the data streams, it MUST terminate the session. 8.2. Procedures for Lite Implementations When ICE concludes, a lite ICE agent can free host candidates that were not used by ICE, as described in Section 8.3. If the peer is a full agent, once the lite agent accepts a nomination request for a candidate pair, the lite agent considers the pair nominated. Once there are nominated pairs for each component of a data stream, the pairs become the selected pairs for the components of the data stream. Once the lite agent has produced selected pairs for all components of all data streams, the ICE session state is set to Completed. If the peer is a lite agent, the agent pairs local candidates with remote candidates that are of the same data stream and have the same component, transport protocol, and IP address family. For each component of each data stream, if there is only one candidate pair, that pair is added to the valid list. If there is more than one pair, it is RECOMMENDED that an agent follow the procedures of RFC 6724 [RFC6724] to select a pair and add it to the valid list.
If all of the components for all data streams had one pair, the state of ICE processing is Completed. Otherwise, the controlling agent MUST send an updated candidate list to reconcile different agents selecting different candidate pairs. ICE processing is complete after and only after the updated candidate exchange is complete. 8.3. Freeing Candidates 8.3.1. Full Implementation Procedures The rules in this section describe when it is safe for an agent to cease sending or receiving checks on a candidate that did not become a selected candidate (i.e., is not associated with a selected pair) and when to free the candidate. Once a checklist has reached the Completed state, the agent SHOULD wait an additional three seconds, and then it can cease responding to checks or generating triggered checks on all local candidates other than the ones that became selected candidates. Once all ICE sessions have ceased using a given local candidate (a candidate may be used by multiple ICE sessions, e.g., in forking scenarios), the agent can free that candidate. The three-second delay handles cases when aggressive nomination is used, and the selected pairs can quickly change after ICE has completed. Freeing of server-reflexive candidates is never explicit; it happens by lack of a keepalive. 8.3.2. Lite Implementation Procedures A lite implementation can free candidates that did not become selected candidates as soon as ICE processing has reached the Completed state for all ICE sessions using those candidates.