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 7.3.1.1).

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.

7.2.5.1.  Role Conflict

   If the Binding request generates a 487 (Role Conflict) error response
   (Section 7.3.1.1), 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 6.1.2.3), 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.

7.2.5.2.  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.

7.2.5.2.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.

7.2.5.2.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.

7.2.5.2.3.  Timeout

   If the Binding request transaction times out, the ICE agent MUST set
   the candidate pair state to Failed.

7.2.5.2.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.

7.2.5.3.  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.

7.2.5.3.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 5.1.1.3.

   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 7.2.5.3.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.

7.2.5.3.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.

7.2.5.3.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.

7.2.5.3.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 7.2.5.2), 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 7.3.1.4), 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).

7.2.5.4.  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 7.3.1.2).  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
   7.3.1.3, 7.3.1.4, and 7.3.1.5 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.

7.3.1.1.  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 6.1.2.3), 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.

7.3.1.2.  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.

7.3.1.3.  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.

7.3.1.4.  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.

7.3.1.5.  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 7.3.1.4:

   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 7.2.5.3.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 7.3.1.4), 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 7.2.5.2), 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 7.2.5.3.4).  The procedures for the controlled agent are
   described in Section 7.3.1.5.

   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 7.2.5.3.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 7.3.1.4, 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.