tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5245

 
 
 

Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols

Part 3 of 5, p. 51 to 79
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 51 
8.  Concluding ICE Processing

   This section describes how an agent completes ICE.

8.1.  Procedures for Full Implementations

   Concluding ICE involves nominating pairs by the controlling agent and
   updating of state machinery.

8.1.1.  Nominating Pairs

   The controlling agent nominates pairs to be selected by ICE by using
   one of two techniques: regular nomination or aggressive nomination.
   If its peer has a lite implementation, an agent MUST use a regular
   nomination algorithm.  If its peer is using ICE options (present in
   an ice-options attribute from the peer) that the agent does not
   understand, the agent MUST use a regular nomination algorithm.  If
   its peer is a full implementation and isn't using any ICE options or
   is using ICE options understood by the agent, the agent MAY use
   either the aggressive or the regular nomination algorithm.  However,
   the regular algorithm is RECOMMENDED since it provides greater
   stability.

Top      Up      ToC       Page 52 
8.1.1.1.  Regular Nomination

   With regular nomination, the agent lets some number of checks
   complete, each of which omit the USE-CANDIDATE attribute.  Once one
   or more checks complete successfully for a component of a media
   stream, valid pairs are generated and added to the valid list.  The
   agent lets the checks continue until some stopping criterion is met,
   and then picks amongst the valid pairs based on an evaluation
   criterion.  The criteria for stopping the checks and for evaluating
   the valid pairs is entirely a matter of local optimization.

   When the controlling agent selects the valid pair, it repeats the
   check that produced this valid pair (by enqueuing the pair that
   generated the check into the triggered check queue), this time with
   the USE-CANDIDATE attribute.  This check should succeed (since the
   previous did), causing the nominated flag of that and only that pair
   to be set.  Consequently, there will be only a single nominated pair
   in the valid list for each component, and when the state of the check
   list moves to completed, that exact pair is selected by ICE for
   sending and receiving media for that component.

   Regular nomination provides the most flexibility, since the agent has
   control over the stopping and selection criteria for checks.  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 present.  Regular nomination also improves ICE's
   resilience to variations in implementation (see Section 14).  Regular
   nomination is also more stable, allowing both agents to converge on a
   single pair for media without any transient selections, which can
   happen with the aggressive algorithm.  The drawback of regular
   nomination is that it is guaranteed to increase latencies because it
   requires an additional check to be done.

8.1.1.2.  Aggressive Nomination

   With aggressive nomination, the controlling agent includes the USE-
   CANDIDATE attribute in every check it sends.  Once the first check
   for a component succeeds, it will be added to the valid list and have
   its nominated flag set.  When all components have a nominated pair in
   the valid list, media can begin to flow using the highest priority
   nominated pair.  However, because the agent included the USE-
   CANDIDATE attribute in all of its checks, another check may yet
   complete, causing another valid pair to have its nominated flag set.
   ICE always selects the highest-priority nominated candidate pair from
   the valid list as the one used for media.  Consequently, the selected
   pair may actually change briefly as ICE checks complete, resulting in
   a set of transient selections until it stabilizes.

Top      Up      ToC       Page 53 
8.1.2.  Updating States

   For both controlling and controlled agents, the state of ICE
   processing depends on the presence of nominated candidate pairs in
   the valid list and on the state of the check list.  Note that, at any
   time, more than one of the following cases can apply:

   o  If there are no nominated pairs in the valid list for a media
      stream and the state of the check list is Running, ICE processing
      continues.

   o  If there is at least one nominated pair in the valid list for a
      media stream and the state of the check list is Running:

      *  The agent MUST remove all Waiting and Frozen pairs in the check
         list and triggered check queue for the same component as the
         nominated pairs for that media stream.

      *  If an In-Progress pair in the check list is for the same
         component as a nominated pair, the agent SHOULD cease
         retransmissions for its check if its pair priority is lower
         than the lowest-priority nominated pair for that component.

   o  Once there is at least one nominated pair in the valid list for
      every component of at least one media stream and the state of the
      check list is Running:

      *  The agent MUST change the state of processing for its check
         list for that media stream to Completed.

      *  The agent MUST continue to respond to any checks it may still
         receive for that media stream, and MUST perform triggered
         checks if required by the processing of Section 7.2.

      *  The agent MUST continue retransmitting any In-Progress checks
         for that check list.

      *  The agent MAY begin transmitting media for this media stream as
         described in Section 11.1.

   o  Once the state of each check list is Completed:

      *  The agent sets the state of ICE processing overall to
         Completed.

      *  If an agent is controlling, it examines the highest-priority
         nominated candidate pair for each component of each media
         stream.  If any of those candidate pairs differ from the

Top      Up      ToC       Page 54 
         default candidate pairs in the most recent offer/answer
         exchange, the controlling agent MUST generate an updated offer
         as described in Section 9.  If the controlling agent is using
         an aggressive nomination algorithm, this may result in several
         updated offers as the pairs selected for media change.  An
         agent MAY delay sending the offer for a brief interval (one
         second is RECOMMENDED) in order to allow the selected pairs to
         stabilize.

   o  If the state of the check list is Failed, ICE has not been able to
      complete for this media stream.  The correct behavior depends on
      the state of the check lists for other media streams:

      *  If all check lists are Failed, ICE processing overall is
         considered to be in the Failed state, and the agent SHOULD
         consider the session a failure, SHOULD NOT restart ICE, and the
         controlling agent SHOULD terminate the entire session.

      *  If at least one of the check lists for other media streams is
         Completed, the controlling agent SHOULD remove the failed media
         stream from the session in its updated offer.

      *  If none of the check lists for other media streams are
         Completed, but at least one is Running, the agent SHOULD let
         ICE continue.

8.2.  Procedures for Lite Implementations

   Concluding ICE for a lite implementation is relatively
   straightforward.  There are two cases to consider:

      The implementation is lite, and its peer is full.

      The implementation is lite, and its peer is lite.

   The effect of ICE concluding is that the agent can free any allocated
   host candidates that were not utilized by ICE, as described in
   Section 8.3.

8.2.1.  Peer Is Full

   In this case, the agent will receive connectivity checks from its
   peer.  When an agent has received a connectivity check that includes
   the USE-CANDIDATE attribute for each component of a media stream, the
   state of ICE processing for that media stream moves from Running to
   Completed.  When the state of ICE processing for all media streams is
   Completed, the state of ICE processing overall is Completed.

Top      Up      ToC       Page 55 
   The lite implementation will never itself determine that ICE
   processing has failed for a media stream; rather, the full peer will
   make that determination and then remove or restart the failed media
   stream in a subsequent offer.

8.2.2.  Peer Is Lite

   Once the offer/answer exchange has completed, both agents examine
   their candidates and those of its peer.  For each media stream, each
   agent pairs up its own candidates with the candidates of its peer for
   that media stream.  Two candidates are paired up when they are for
   the same component, utilize the same transport protocol (UDP in this
   specification), and are from the same IP address family (IPv4 or
   IPv6).

   o  If there is a single pair per component, that pair is added to the
      Valid list.  If all of the components for a media stream had one
      pair, the state of ICE processing for that media stream is set to
      Completed.  If all media streams are Completed, the state of ICE
      processing is set to Completed overall.  This will always be the
      case for implementations that are IPv4 only.

   o  If there is more than one pair per component:

      *  The agent MUST select a pair based on local policy.  Since this
         case only arises for IPv6, it is RECOMMENDED that an agent
         follow the procedures of RFC 3484 [RFC3484] to select a single
         pair.

      *  The agent adds the selected pair for each component to the
         valid list.  As described in Section 11.1, this will permit
         media to begin flowing.  However, it is possible (and in fact
         likely) that both agents have chosen different pairs.

      *  To reconcile this, the controlling agent MUST send an updated
         offer as described in Section 9.1.3, which will include the
         remote-candidates attribute.

      *  The agent MUST NOT update the state of ICE processing when the
         offer is sent.  If this subsequent offer completes, the
         controlling agent MUST change the state of ICE processing to
         Completed for all media streams, and the state of ICE
         processing overall to Completed.  The states for the controlled
         agent are set based on the logic in Section 9.2.3.

Top      Up      ToC       Page 56 
8.3.  Freeing Candidates

8.3.1.  Full Implementation Procedures

   The procedures in Section 8 require that an agent continue to listen
   for STUN requests and continue to generate triggered checks for a
   media stream, even once processing for that stream completes.  The
   rules in this section describe when it is safe for an agent to cease
   sending or receiving checks on a candidate that was not selected by
   ICE, and then free the candidate.

   When ICE is used with SIP, and an offer is forked to multiple
   recipients, ICE proceeds in parallel and independently with each
   answerer, all using the same local candidates.  Once ICE processing
   has reached the Completed state for all peers for media streams using
   those candidates, the agent SHOULD wait an additional three seconds,
   and then it MAY cease responding to checks or generating triggered
   checks on that candidate.  It MAY free the candidate at that time.
   Freeing of server reflexive candidates is never explicit; it happens
   by lack of a keepalive.  The three-second delay handles cases when
   aggressive nomination is used, and the selected pairs can quickly
   change after ICE has completed.

8.3.2.  Lite Implementation Procedures

   A lite implementation MAY free candidates not selected by ICE as soon
   as ICE processing has reached the Completed state for all peers for
   all media streams using those candidates.

9.  Subsequent Offer/Answer Exchanges

   Either agent MAY generate a subsequent offer at any time allowed by
   RFC 3264 [RFC3264].  The rules in Section 8 will cause the
   controlling agent to send an updated offer at the conclusion of ICE
   processing when ICE has selected different candidate pairs from the
   default pairs.  This section defines rules for construction of
   subsequent offers and answers.

   Should a subsequent offer be rejected, ICE processing continues as if
   the subsequent offer had never been made.

Top      Up      ToC       Page 57 
9.1.  Generating the Offer

9.1.1.  Procedures for All Implementations

9.1.1.1.  ICE Restarts

   An agent MAY restart ICE processing for an existing media stream.  An
   ICE restart, as the name implies, will cause all previous states of
   ICE processing to be flushed and checks to start anew.  The only
   difference between an ICE restart and a brand new media session is
   that, during the restart, media can continue to be sent to the
   previously validated pair.

   An agent MUST restart ICE for a media stream if:

   o  The offer is being generated for the purposes of changing the
      target of the media stream.  In other words, if an agent wants to
      generate an updated offer that, had ICE not been in use, would
      result in a new value for the destination of a media component.

   o  An agent is changing its implementation level.  This typically
      only happens in third party call control use cases, where the
      entity performing the signaling is not the entity receiving the
      media, and it has changed the target of media mid-session to
      another entity that has a different ICE implementation.

   These rules imply that setting the IP address in the c line to
   0.0.0.0 will cause an ICE restart.  Consequently, ICE implementations
   MUST NOT utilize this mechanism for call hold, and instead MUST use
   a=inactive and a=sendonly as described in [RFC3264].

   To restart ICE, an agent MUST change both the ice-pwd and the ice-
   ufrag for the media stream in an offer.  Note that it is permissible
   to use a session-level attribute in one offer, but to provide the
   same ice-pwd or ice-ufrag as a media-level attribute in a subsequent
   offer.  This is not a change in password, just a change in its
   representation, and does not cause an ICE restart.

   An agent sets the rest of the fields in the SDP for this media stream
   as it would in an initial offer of this media stream (see
   Section 4.3).  Consequently, the set of candidates MAY include some,
   none, or all of the previous candidates for that stream and MAY
   include a totally new set of candidates gathered as described in
   Section 4.1.1.

Top      Up      ToC       Page 58 
9.1.1.2.  Removing a Media Stream

   If an agent removes a media stream by setting its port to zero, it
   MUST NOT include any candidate attributes for that media stream and
   SHOULD NOT include any other ICE-related attributes defined in
   Section 15 for that media stream.

9.1.1.3.  Adding a Media Stream

   If an agent wishes to add a new media stream, it sets the fields in
   the SDP for this media stream as if this was an initial offer for
   that media stream (see Section 4.3).  This will cause ICE processing
   to begin for this media stream.

9.1.2.  Procedures for Full Implementations

   This section describes additional procedures for full
   implementations, covering existing media streams.

   The username fragments, password, and implementation level MUST
   remain the same as used previously.  If an agent needs to change one
   of these, it MUST restart ICE for that media stream.

   Additional behavior depends on the state ICE processing for that
   media stream.

9.1.2.1.  Existing Media Streams with ICE Running

   If an agent generates an updated offer including a media stream that
   was previously established, and for which ICE checks are in the
   Running state, the agent follows the procedures defined here.

   An agent MUST include candidate attributes for all local candidates
   it had signaled previously for that media stream.  The properties of
   that candidate as signaled in SDP -- the priority, foundation, type,
   and related transport address -- SHOULD remain the same.  The IP
   address, port, and transport protocol, which fundamentally identify
   that candidate, MUST remain the same (if they change, it would be a
   new candidate).  The component ID MUST remain the same.  The agent
   MAY include additional candidates it did not offer previously, but
   which it has gathered since the last offer/answer exchange, including
   peer reflexive candidates.

   The agent MAY change the default destination for media.  As with
   initial offers, there MUST be a set of candidate attributes in the
   offer matching this default destination.

Top      Up      ToC       Page 59 
9.1.2.2.  Existing Media Streams with ICE Completed

   If an agent generates an updated offer including a media stream that
   was previously established, and for which ICE checks are in the
   Completed state, the agent follows the procedures defined here.

   The default destination for media (i.e., the values of the IP
   addresses and ports in the m and c lines used for that media stream)
   MUST be the local candidate from the highest-priority nominated pair
   in the valid list for each component.  This "fixes" the default
   destination for media to equal the destination ICE has selected for
   media.

   The agent MUST include candidate attributes for candidates matching
   the default destination for each component of the media stream, and
   MUST NOT include any other candidates.

   In addition, if the agent is controlling, it MUST include the
   a=remote-candidates attribute for each media stream whose check list
   is in the Completed state.  The attribute contains the remote
   candidates from the highest-priority nominated pair in the valid list
   for each component of that media stream.  It is needed to avoid a
   race condition whereby the controlling agent chooses its pairs, but
   the updated offer beats the connectivity checks to the controlled
   agent, which doesn't even know these pairs are valid, let alone
   selected.  See Appendix B.6 for elaboration on this race condition.

9.1.3.  Procedures for Lite Implementations

9.1.3.1.  Existing Media Streams with ICE Running

   This section describes procedures for lite implementations for
   existing streams for which ICE is running.

   A lite implementation MUST include all of its candidates for each
   component of each media stream in an a=candidate attribute in any
   subsequent offer.  These candidates are formed identically to the
   procedures for initial offers, as described in Section 4.2.

   A lite implementation MUST NOT add additional host candidates in a
   subsequent offer.  If an agent needs to offer additional candidates,
   it MUST restart ICE.

   The username fragments, password, and implementation level MUST
   remain the same as used previously.  If an agent needs to change one
   of these, it MUST restart ICE for that media stream.

Top      Up      ToC       Page 60 
9.1.3.2.  Existing Media Streams with ICE Completed

   If ICE has completed for a media stream, the default destination for
   that media stream MUST be set to the remote candidate of the
   candidate pair for that component in the valid list.  For a lite
   implementation, there is always just a single candidate pair in the
   valid list for each component of a media stream.  Additionally, the
   agent MUST include a candidate attribute for each default
   destination.

   Additionally, if the agent is controlling (which only happens when
   both agents are lite), the agent MUST include the a=remote-candidates
   attribute for each media stream.  The attribute contains the remote
   candidates from the candidate pairs in the valid list (one pair for
   each component of each media stream).

9.2.  Receiving the Offer and Generating an Answer

9.2.1.  Procedures for All Implementations

   When receiving a subsequent offer within an existing session, an
   agent MUST reapply the verification procedures in Section 5.1 without
   regard to the results of verification from any previous offer/answer
   exchanges.  Indeed, it is possible that a previous offer/answer
   exchange resulted in ICE not being used, but it is used as a
   consequence of a subsequent exchange.

9.2.1.1.  Detecting ICE Restart

   If the offer contained a change in the a=ice-ufrag or a=ice-pwd
   attributes compared to the previous SDP from the peer, it indicates
   that ICE is restarting for this media stream.  If all media streams
   are restarting, then ICE is restarting overall.

   If ICE is restarting for a media stream:

   o  The agent MUST change the a=ice-ufrag and a=ice-pwd attributes in
      the answer.

   o  The agent MAY change its implementation level in the answer.

   An agent sets the rest of the fields in the SDP for this media stream
   as it would in an initial answer to this media stream (see
   Section 4.3).  Consequently, the set of candidates MAY include some,
   none, or all of the previous candidates for that stream and MAY
   include a totally new set of candidates gathered as described in
   Section 4.1.1.

Top      Up      ToC       Page 61 
9.2.1.2.  New Media Stream

   If the offer contains a new media stream, the agent sets the fields
   in the answer as if it had received an initial offer containing that
   media stream (see Section 4.3).  This will cause ICE processing to
   begin for this media stream.

9.2.1.3.  Removed Media Stream

   If an offer contains a media stream whose port is zero, the agent
   MUST NOT include any candidate attributes for that media stream in
   its answer and SHOULD NOT include any other ICE-related attributes
   defined in Section 15 for that media stream.

9.2.2.  Procedures for Full Implementations

   Unless the agent has detected an ICE restart from the offer, the
   username fragments, password, and implementation level MUST remain
   the same as used previously.  If an agent needs to change one of
   these it MUST restart ICE for that media stream by generating an
   offer; ICE cannot be restarted in an answer.

   Additional behaviors depend on the state of ICE processing for that
   media stream.

9.2.2.1.  Existing Media Streams with ICE Running and no remote-
          candidates

   If ICE is running for a media stream, and the offer for that media
   stream lacked the remote-candidates attribute, the rules for
   construction of the answer are identical to those for the offerer as
   described in Section 9.1.2.1.

9.2.2.2.  Existing Media Streams with ICE Completed and no remote-
          candidates

   If ICE is Completed for a media stream, and the offer for that media
   stream lacked the remote-candidates attribute, the rules for
   construction of the answer are identical to those for the offerer as
   described in Section 9.1.2.2, except that the answerer MUST NOT
   include the a=remote-candidates attribute in the answer.

9.2.2.3.  Existing Media Streams and remote-candidates

   A controlled agent will receive an offer with the a=remote-candidates
   attribute for a media stream when its peer has concluded ICE
   processing for that media stream.  This attribute is present in the
   offer to deal with a race condition between the receipt of the offer,

Top      Up      ToC       Page 62 
   and the receipt of the Binding response that tells the answerer the
   candidate that will be selected by ICE.  See Appendix B.6 for an
   explanation of this race condition.  Consequently, processing of an
   offer with this attribute depends on the winner of the race.

   The agent forms a candidate pair for each component of the media
   stream by:

   o  Setting the remote candidate equal to the offerer's default
      destination for that component (e.g., the contents of the m and c
      lines for RTP, and the a=rtcp attribute for RTCP)

   o  Setting the local candidate equal to the transport address for
      that same component in the a=remote-candidates attribute in the
      offer.

   The agent then sees if each of these candidate pairs is present in
   the valid list.  If a particular pair is not in the valid list, the
   check has "lost" the race.  Call such a pair a "losing pair".

   The agent finds all the pairs in the check list whose remote
   candidates equal the remote candidate in the losing pair:

   o  If none of the pairs are In-Progress, and at least one is Failed,
      it is most likely that a network failure, such as a network
      partition or serious packet loss, has occurred.  The agent SHOULD
      generate an answer for this media stream as if the remote-
      candidates attribute had not been present, and then restart ICE
      for this stream.

   o  If at least one of the pairs is In-Progress, the agent SHOULD wait
      for those checks to complete, and as each completes, redo the
      processing in this section until there are no losing pairs.

   Once there are no losing pairs, the agent can generate the answer.
   It MUST set the default destination for media to the candidates in
   the remote-candidates attribute from the offer (each of which will
   now be the local candidate of a candidate pair in the valid list).
   It MUST include a candidate attribute in the answer for each
   candidate in the remote-candidates attribute in the offer.

9.2.3.  Procedures for Lite Implementations

   If the received offer contains the remote-candidates attribute for a
   media stream, the agent forms a candidate pair for each component of
   the media stream by:

Top      Up      ToC       Page 63 
   o  Setting the remote candidate equal to the offerer's default
      destination for that component (e.g., the contents of the m and c
      lines for RTP, and the a=rtcp attribute for RTCP).

   o  Setting the local candidate equal to the transport address for
      that same component in the a=remote-candidates attribute in the
      offer.

   It then places those candidates into the Valid list for the media
   stream.  The state of ICE processing for that media stream is set to
   Completed.

   Furthermore, if the agent believed it was controlling, but the offer
   contained the remote-candidates attribute, both agents believe they
   are controlling.  In this case, both would have sent updated offers
   around the same time.  However, the signaling protocol carrying the
   offer/answer exchanges will have resolved this glare condition, so
   that one agent is always the 'winner' by having its offer received
   before its peer has sent an offer.  The winner takes the role of
   controlled, so that the loser (the answerer under consideration in
   this section) MUST change its role to controlled.  Consequently, if
   the agent was going to send an updated offer since, based on the
   rules in Section 8.2.2, it was controlling, it no longer needs to.

   Besides the potential role change, change in the Valid list, and
   state changes, the construction of the answer is performed
   identically to the construction of an offer as described in
   Section 9.1.3.

9.3.  Updating the Check and Valid Lists

9.3.1.  Procedures for Full Implementations

9.3.1.1.  ICE Restarts

   The agent MUST remember the highest-priority nominated pairs in the
   Valid list for each component of the media stream, called the
   previous selected pairs, prior to the restart.  The agent will
   continue to send media using these pairs, as described in
   Section 11.1.  Once these destinations are noted, the agent MUST
   flush the valid and check lists, and then recompute the check list
   and its states as described in Section 5.7.

9.3.1.2.  New Media Stream

   If the offer/answer exchange added a new media stream, the agent MUST
   create a new check list for it (and an empty Valid list to start of
   course), as described in Section 5.7.

Top      Up      ToC       Page 64 
9.3.1.3.  Removed Media Stream

   If the offer/answer exchange removed a media stream, or an answer
   rejected an offered media stream, an agent MUST flush the Valid list
   for that media stream.  It MUST terminate any STUN transactions in
   progress for that media stream.  An agent MUST remove the check list
   for that media stream and cancel any pending ordinary checks for it.

9.3.1.4.  ICE Continuing for Existing Media Stream

   The valid list is not affected by an updated offer/answer exchange
   unless ICE is restarting.

   If an agent is in the Running state for that media stream, the check
   list is updated (the check list is irrelevant if the state is
   completed).  To do that, the agent recomputes the check list using
   the procedures described in Section 5.7.  If a pair on the new check
   list was also on the previous check list, and its state was Waiting,
   In-Progress, Succeeded, or Failed, its state is copied over.
   Otherwise, its state is set to Frozen.

   If none of the check lists are active (meaning that the pairs in each
   check list are Frozen), the full-mode agent sets the first pair in
   the check list for the first media stream to Waiting, and then sets
   the state of all other pairs in that check list for the same
   component ID and with the same foundation to Waiting as well.

   Next, the agent goes through each check list, starting with the
   highest-priority pair.  If a pair has a state of Succeeded, and it
   has a component ID of 1, then all Frozen pairs in the same check list
   with the same foundation whose component IDs are not 1 have their
   state set to Waiting.  If, for a particular check list, there are
   pairs for each component of that media stream in the Succeeded state,
   the agent moves the state of all Frozen pairs for the first component
   of all other media streams (and thus in different check lists) with
   the same foundation to Waiting.

9.3.2.  Procedures for Lite Implementations

   If ICE is restarting for a media stream, the agent MUST start a new
   Valid list for that media stream.  It MUST remember the pairs in the
   previous Valid list for each component of the media stream, called
   the previous selected pairs, and continue to send media there as
   described in Section 11.1.  The state of ICE processing for each
   media stream MUST change to Running, and the state of ICE processing
   MUST change to Running.

Top      Up      ToC       Page 65 
10.  Keepalives

   All endpoints MUST send keepalives for each media session.  These
   keepalives serve the purpose of keeping NAT bindings alive for the
   media session.  These keepalives MUST be sent regardless of whether
   the media stream is currently inactive, sendonly, recvonly, or
   sendrecv, and regardless of the presence or value of the bandwidth
   attribute.  These keepalives MUST be sent even if ICE is not being
   utilized for the session at all.  The keepalive SHOULD be sent using
   a format that is supported by its peer.  ICE endpoints allow for
   STUN-based keepalives for UDP streams, and as such, STUN keepalives
   MUST be used when an agent is a full ICE implementation and is
   communicating with a peer that supports ICE (lite or full).  An agent
   can determine that its peer supports ICE by the presence of
   a=candidate attributes for each media session.  If the peer does not
   support ICE, the choice of a packet format for keepalives is a matter
   of local implementation.  A format that allows packets to easily be
   sent in the absence of actual media content is RECOMMENDED.  Examples
   of formats that readily meet this goal are RTP No-Op [NO-OP-RTP], and
   in cases where both sides support it, RTP comfort noise [RFC3389].
   If the peer doesn't support any formats that are particularly well
   suited for keepalives, an agent SHOULD send RTP packets with an
   incorrect version number, or some other form of error that would
   cause them to be discarded by the peer.

   If there has been no packet sent on the candidate pair ICE is using
   for a media component for Tr seconds (where packets include those
   defined for the component (RTP or RTCP) and previous keepalives), an
   agent MUST generate a keepalive on that pair.  Tr SHOULD be
   configurable and SHOULD have a default of 15 seconds.  Tr MUST NOT be
   configured to less than 15 seconds.  Alternatively, if an agent has a
   dynamic way to discover the binding lifetimes of the intervening
   NATs, it can use that value to determine Tr.  Administrators
   deploying ICE in more controlled networking environments SHOULD set
   Tr to the longest duration possible in their environment.

   If STUN is being used for keepalives, a STUN Binding Indication is
   used [RFC5389].  The Indication MUST NOT utilize any authentication
   mechanism.  It SHOULD contain the FINGERPRINT attribute to aid in
   demultiplexing, but SHOULD NOT contain any other attributes.  It is
   used solely to keep the NAT bindings alive.  The Binding Indication
   is sent using the same local and remote candidates that are being
   used for media.  Though Binding Indications are used for keepalives,
   an agent MUST be prepared to receive a connectivity check as well.
   If a connectivity check is received, a response is generated as
   discussed in [RFC5389], but there is no impact on ICE processing
   otherwise.

Top      Up      ToC       Page 66 
   An agent MUST begin the keepalive processing once ICE has selected
   candidates for usage with media, or media begins to flow, whichever
   happens first.  Keepalives end once the session terminates or the
   media stream is removed.

11.  Media Handling

11.1.  Sending Media

   Procedures for sending media differ for full and lite
   implementations.

11.1.1.  Procedures for Full Implementations

   Agents always send media using a candidate pair, called the selected
   candidate pair.  An agent will send media to the remote candidate in
   the selected pair (setting the destination address and port of the
   packet equal to that remote candidate), and will send it from the
   local candidate of the selected pair.  When the local candidate is
   server or peer reflexive, media is originated from the base.  Media
   sent from a relayed candidate is sent from the base through that TURN
   server, using procedures defined in [RFC5766].

   If the local candidate is a relayed candidate, it is RECOMMENDED that
   an agent create a channel on the TURN server towards the remote
   candidate.  This is done using the procedures for channel creation as
   defined in Section 11 of [RFC5766].

   The selected pair for a component of a media stream is:

   o  empty if the state of the check list for that media stream is
      Running, and there is no previous selected pair for that component
      due to an ICE restart

   o  equal to the previous selected pair for a component of a media
      stream if the state of the check list for that media stream is
      Running, and there was a previous selected pair for that component
      due to an ICE restart

   o  equal to the highest-priority nominated pair for that component in
      the valid list if the state of the check list is Completed

   If the selected pair for at least one component of a media stream is
   empty, an agent MUST NOT send media for any component of that media
   stream.  If the selected pair for each component of a media stream
   has a value, an agent MAY send media for all components of that media
   stream.

Top      Up      ToC       Page 67 
   Note that the selected pair for a component of a media stream may not
   equal the default pair for that same component from the most recent
   offer/answer exchange.  When this happens, the selected pair is used
   for media, not the default pair.  When ICE first completes, if the
   selected pairs aren't a match for the default pairs, the controlling
   agent sends an updated offer/answer exchange to remedy this
   disparity.  However, until that updated offer arrives, there will not
   be a match.  Furthermore, in very unusual cases, the default
   candidates in the updated offer/answer will not be a match.

11.1.2.  Procedures for Lite Implementations

   A lite implementation MUST NOT send media until it has a Valid list
   that contains a candidate pair for each component of that media
   stream.  Once that happens, the agent MAY begin sending media
   packets.  To do that, it sends media to the remote candidate in the
   pair (setting the destination address and port of the packet equal to
   that remote candidate), and will send it from the local candidate.

11.1.3.  Procedures for All Implementations

   ICE has interactions with jitter buffer adaptation mechanisms.  An
   RTP stream can begin using one candidate, and switch to another one,
   though this happens rarely with ICE.  The newer candidate may result
   in RTP packets taking a different path through the network -- one
   with different delay characteristics.  As discussed below, agents are
   encouraged to re-adjust jitter buffers when there are changes in
   source or destination address of media packets.  Furthermore, many
   audio codecs use the marker bit to signal the beginning of a
   talkspurt, for the purposes of jitter buffer adaptation.  For such
   codecs, it is RECOMMENDED that the sender set the marker bit
   [RFC3550] when an agent switches transmission of media from one
   candidate pair to another.

11.2.  Receiving Media

   ICE implementations MUST be prepared to receive media on each
   component on any candidates provided for that component in the most
   recent offer/answer exchange (in the case of RTP, this would include
   both RTP and RTCP if candidates were provided for both).

   It is RECOMMENDED that, when an agent receives an RTP packet with a
   new source or destination IP address for a particular media stream,
   that the agent re-adjust its jitter buffers.

   RFC 3550 [RFC3550] describes an algorithm in Section 8.2 for
   detecting synchronization source (SSRC) collisions and loops.  These
   algorithms are based, in part, on seeing different source transport

Top      Up      ToC       Page 68 
   addresses with the same SSRC.  However, when ICE is used, such
   changes will sometimes occur as the media streams switch between
   candidates.  An agent will be able to determine that a media stream
   is from the same peer as a consequence of the STUN exchange that
   proceeds media transmission.  Thus, if there is a change in source
   transport address, but the media packets come from the same peer
   agent, this SHOULD NOT be treated as an SSRC collision.

12.  Usage with SIP

12.1.  Latency Guidelines

   ICE requires a series of STUN-based connectivity checks to take place
   between endpoints.  These checks start from the answerer on
   generation of its answer, and start from the offerer when it receives
   the answer.  These checks can take time to complete, and as such, the
   selection of messages to use with offers and answers can affect
   perceived user latency.  Two latency figures are of particular
   interest.  These are the post-pickup delay and the post-dial delay.
   The post-pickup delay refers to the time between when a user "answers
   the phone" and when any speech they utter can be delivered to the
   caller.  The post-dial delay refers to the time between when a user
   enters the destination address for the user and ringback begins as a
   consequence of having successfully started ringing the phone of the
   called party.

   Two cases can be considered -- one where the offer is present in the
   initial INVITE and one where it is in a response.

12.1.1.  Offer in INVITE

   To reduce post-dial delays, it is RECOMMENDED that the caller begin
   gathering candidates prior to actually sending its initial INVITE.
   This can be started upon user interface cues that a call is pending,
   such as activity on a keypad or the phone going offhook.

   If an offer is received in an INVITE request, the answerer SHOULD
   begin to gather its candidates on receipt of the offer and then
   generate an answer in a provisional response once it has completed
   that process.  ICE requires that a provisional response with an SDP
   be transmitted reliably.  This can be done through the existing
   Provisional Response Acknowledgment (PRACK) mechanism [RFC3262] or
   through an optimization that is specific to ICE.  With this
   optimization, provisional responses containing an SDP answer that
   begins ICE processing for one or more media streams can be sent
   reliably without RFC 3262.  To do this, the agent retransmits the
   provisional response with the exponential backoff timers described in
   RFC 3262.  Retransmits MUST cease on receipt of a STUN Binding

Top      Up      ToC       Page 69 
   request for one of the media streams signaled in that SDP (because
   receipt of a Binding request indicates the offerer has received the
   answer) or on transmission of the answer in a 2xx response.  If the
   peer agent is lite, there will never be a STUN Binding request.  In
   such a case, the agent MUST cease retransmitting the 18x after
   sending it four times (ICE will actually work even if the peer never
   receives the 18x; however, experience has shown that sending it is
   important for middleboxes and firewall traversal).  If no Binding
   request is received prior to the last retransmit, the agent does not
   consider the session terminated.  Despite the fact that the
   provisional response will be delivered reliably, the rules for when
   an agent can send an updated offer or answer do not change from those
   specified in RFC 3262.  Specifically, if the INVITE contained an
   offer, the same answer appears in all of the 1xx and in the 2xx
   response to the INVITE.  Only after that 2xx has been sent can an
   updated offer/answer exchange occur.  This optimization SHOULD NOT be
   used if both agents support PRACK.  Note that the optimization is
   very specific to provisional response carrying answers that start ICE
   processing; it is not a general technique for 1xx reliability.

   Alternatively, an agent MAY delay sending an answer until the 200 OK;
   however, this results in a poor user experience and is NOT
   RECOMMENDED.

   Once the answer has been sent, the agent SHOULD begin its
   connectivity checks.  Once candidate pairs for each component of a
   media stream enter the valid list, the answerer can begin sending
   media on that media stream.

   However, prior to this point, any media that needs to be sent towards
   the caller (such as SIP early media [RFC3960]) MUST NOT be
   transmitted.  For this reason, implementations SHOULD delay alerting
   the called party until candidates for each component of each media
   stream have entered the valid list.  In the case of a PSTN gateway,
   this would mean that the setup message into the PSTN is delayed until
   this point.  Doing this increases the post-dial delay, but has the
   effect of eliminating 'ghost rings'.  Ghost rings are cases where the
   called party hears the phone ring, picks up, but hears nothing and
   cannot be heard.  This technique works without requiring support for,
   or usage of, preconditions [RFC3312], since it's a localized
   decision.  It also has the benefit of guaranteeing that not a single
   packet of media will get clipped, so that post-pickup delay is zero.
   If an agent chooses to delay local alerting in this way, it SHOULD
   generate a 180 response once alerting begins.

Top      Up      ToC       Page 70 
12.1.2.  Offer in Response

   In addition to uses where the offer is in an INVITE, and the answer
   is in the provisional and/or 200 OK response, ICE works with cases
   where the offer appears in the response.  In such cases, which are
   common in third party call control [RFC3725], ICE agents SHOULD
   generate their offers in a reliable provisional response (which MUST
   utilize RFC 3262), and not alert the user on receipt of the INVITE.
   The answer will arrive in a PRACK.  This allows for ICE processing to
   take place prior to alerting, so that there is no post-pickup delay,
   at the expense of increased call setup delays.  Once ICE completes,
   the callee can alert the user and then generate a 200 OK when they
   answer.  The 200 OK would contain no SDP, since the offer/answer
   exchange has completed.

   Alternatively, agents MAY place the offer in a 2xx instead (in which
   case the answer comes in the ACK).  When this happens, the callee
   will alert the user on receipt of the INVITE, and the ICE exchanges
   will take place only after the user answers.  This has the effect of
   reducing call setup delay, but can cause substantial post-pickup
   delays and media clipping.

12.2.  SIP Option Tags and Media Feature Tags

   [RFC5768] specifies a SIP option tag and media feature tag for usage
   with ICE.  ICE implementations using SIP SHOULD support this
   specification, which uses a feature tag in registrations to
   facilitate interoperability through signaling intermediaries.

12.3.  Interactions with Forking

   ICE interacts very well with forking.  Indeed, ICE fixes some of the
   problems associated with forking.  Without ICE, when a call forks and
   the caller receives multiple incoming media streams, it cannot
   determine which media stream corresponds to which callee.

   With ICE, this problem is resolved.  The connectivity checks which
   occur prior to transmission of media carry username fragments, which
   in turn are correlated to a specific callee.  Subsequent media
   packets that arrive on the same candidate pair as the connectivity
   check will be associated with that same callee.  Thus, the caller can
   perform this correlation as long as it has received an answer.

12.4.  Interactions with Preconditions

   Quality of Service (QoS) preconditions, which are defined in RFC 3312
   [RFC3312] and RFC 4032 [RFC4032], apply only to the transport
   addresses listed as the default targets for media in an offer/answer.

Top      Up      ToC       Page 71 
   If ICE changes the transport address where media is received, this
   change is reflected in an updated offer that changes the default
   destination for media to match ICE's selection.  As such, it appears
   like any other re-INVITE would, and is fully treated in RFCs 3312 and
   4032, which apply without regard to the fact that the destination for
   media is changing due to ICE negotiations occurring "in the
   background".

   Indeed, an agent SHOULD NOT indicate that QoS preconditions have been
   met until the checks have completed and selected the candidate pairs
   to be used for media.

   ICE also has (purposeful) interactions with connectivity
   preconditions [SDP-PRECON].  Those interactions are described there.
   Note that the procedures described in Section 12.1 describe their own
   type of "preconditions", albeit with less functionality than those
   provided by the explicit preconditions in [SDP-PRECON].

12.5.  Interactions with Third Party Call Control

   ICE works with Flows I, III, and IV as described in [RFC3725].  Flow
   I works without the controller supporting or being aware of ICE.
   Flow IV will work as long as the controller passes along the ICE
   attributes without alteration.  Flow II is fundamentally incompatible
   with ICE; each agent will believe itself to be the answerer and thus
   never generate a re-INVITE.

   The flows for continued operation, as described in Section 7 of RFC
   3725, require additional behavior of ICE implementations to support.
   In particular, if an agent receives a mid-dialog re-INVITE that
   contains no offer, it MUST restart ICE for each media stream and go
   through the process of gathering new candidates.  Furthermore, that
   list of candidates SHOULD include the ones currently being used for
   media.

13.  Relationship with ANAT

   RFC 4091 [RFC4091], the Alternative Network Address Types (ANAT)
   Semantics for the SDP grouping framework, and RFC 4092 [RFC4092], its
   usage with SIP, define a mechanism for indicating that an agent can
   support both IPv4 and IPv6 for a media stream, and it does so by
   including two m lines, one for v4 and one for v6.  This is similar to
   ICE, which allows for an agent to indicate multiple transport
   addresses using the candidate attribute.  However, ANAT relies on
   static selection to pick between choices, rather than a dynamic
   connectivity check used by ICE.

Top      Up      ToC       Page 72 
   This specification deprecates RFC 4091 and RFC 4092.  Instead, agents
   wishing to support dual stack will utilize ICE.

14.  Extensibility Considerations

   This specification makes very specific choices about how both agents
   in a session coordinate to arrive at the set of candidate pairs that
   are selected for media.  It is anticipated that future specifications
   will want to alter these algorithms, whether they are simple changes
   like timer tweaks or larger changes like a revamp of the priority
   algorithm.  When such a change is made, providing interoperability
   between the two agents in a session is critical.

   First, ICE provides the a=ice-options SDP attribute.  Each extension
   or change to ICE is associated with a token.  When an agent
   supporting such an extension or change generates an offer or an
   answer, it MUST include the token for that extension in this
   attribute.  This allows each side to know what the other side is
   doing.  This attribute MUST NOT be present if the agent doesn't
   support any ICE extensions or changes.

   At this time, no IANA registry or registration procedures are defined
   for these option tags.  At time of writing, it is unclear whether ICE
   changes and extensions will be sufficiently common to warrant a
   registry.

   One of the complications in achieving interoperability is that ICE
   relies on a distributed algorithm running on both agents to converge
   on an agreed set of candidate pairs.  If the two agents run different
   algorithms, it can be difficult to guarantee convergence on the same
   candidate pairs.  The regular nomination procedure described in
   Section 8 eliminates some of the tight coordination by delegating the
   selection algorithm completely to the controlling agent.
   Consequently, when a controlling agent is communicating with a peer
   that supports options it doesn't know about, the agent MUST run a
   regular nomination algorithm.  When regular nomination is used, ICE
   will converge perfectly even when both agents use different pair
   prioritization algorithms.  One of the keys to such convergence is
   triggered checks, which ensure that the nominated pair is validated
   by both agents.  Consequently, any future ICE enhancements MUST
   preserve triggered checks.

   ICE is also extensible to other media streams beyond RTP, and for
   transport protocols beyond UDP.  Extensions to ICE for non-RTP media
   streams need to specify how many components they utilize, and assign
   component IDs to them, starting at 1 for the most important component
   ID.  Specifications for new transport protocols must define how, if
   at all, various steps in the ICE processing differ from UDP.

Top      Up      ToC       Page 73 
15.  Grammar

   This specification defines seven new SDP attributes -- the
   "candidate", "remote-candidates", "ice-lite", "ice-mismatch", "ice-
   ufrag", "ice-pwd", and "ice-options" attributes.

15.1.  "candidate" Attribute

   The candidate attribute is a media-level attribute only.  It contains
   a transport address for a candidate that can be used for connectivity
   checks.

   The syntax of this attribute is defined using Augmented BNF as
   defined in RFC 5234 [RFC5234]:

   candidate-attribute   = "candidate" ":" foundation SP component-id SP
                           transport SP
                           priority SP
                           connection-address SP     ;from RFC 4566
                           port         ;port from RFC 4566
                           SP cand-type
                           [SP rel-addr]
                           [SP rel-port]
                           *(SP extension-att-name SP
                                extension-att-value)

   foundation            = 1*32ice-char
   component-id          = 1*5DIGIT
   transport             = "UDP" / transport-extension
   transport-extension   = token              ; from RFC 3261
   priority              = 1*10DIGIT
   cand-type             = "typ" SP candidate-types
   candidate-types       = "host" / "srflx" / "prflx" / "relay" / token
   rel-addr              = "raddr" SP connection-address
   rel-port              = "rport" SP port
   extension-att-name    = byte-string    ;from RFC 4566
   extension-att-value   = byte-string
   ice-char              = ALPHA / DIGIT / "+" / "/"

   This grammar encodes the primary information about a candidate: its
   IP address, port and transport protocol, and its properties: the
   foundation, component ID, priority, type, and related transport
   address:

   <connection-address>:  is taken from RFC 4566 [RFC4566].  It is the
      IP address of the candidate, allowing for IPv4 addresses, IPv6
      addresses, and fully qualified domain names (FQDNs).  When parsing
      this field, an agent can differentiate an IPv4 address and an IPv6

Top      Up      ToC       Page 74 
      address by presence of a colon in its value - the presence of a
      colon indicates IPv6.  An agent MUST ignore candidate lines that
      include candidates with IP address versions that are not supported
      or recognized.  An IP address SHOULD be used, but an FQDN MAY be
      used in place of an IP address.  In that case, when receiving an
      offer or answer containing an FQDN in an a=candidate attribute,
      the FQDN is looked up in the DNS first using an AAAA record
      (assuming the agent supports IPv6), and if no result is found or
      the agent only supports IPv4, using an A.  If the DNS query
      returns more than one IP address, one is chosen, and then used for
      the remainder of ICE processing.

   <port>:  is also taken from RFC 4566 [RFC4566].  It is the port of
      the candidate.

   <transport>:  indicates the transport protocol for the candidate.
      This specification only defines UDP.  However, extensibility is
      provided to allow for future transport protocols to be used with
      ICE, such as TCP or the Datagram Congestion Control Protocol
      (DCCP) [RFC4340].

   <foundation>:  is composed of 1 to 32 <ice-char>s.  It is an
      identifier that is equivalent for two candidates that are of the
      same type, share the same base, and come from the same STUN
      server.  The foundation is used to optimize ICE performance in the
      Frozen algorithm.

   <component-id>:  is a positive integer between 1 and 256 that
      identifies the specific component of the media stream for which
      this is a candidate.  It MUST start at 1 and MUST increment by 1
      for each component of a particular candidate.  For media streams
      based on RTP, candidates for the actual RTP media MUST have a
      component ID of 1, and candidates for RTCP MUST have a component
      ID of 2.  Other types of media streams that require multiple
      components MUST develop specifications that define the mapping of
      components to component IDs.  See Section 14 for additional
      discussion on extending ICE to new media streams.

   <priority>:  is a positive integer between 1 and (2**31 - 1).

   <cand-type>:  encodes the type of candidate.  This specification
      defines the values "host", "srflx", "prflx", and "relay" for host,
      server reflexive, peer reflexive, and relayed candidates,
      respectively.  The set of candidate types is extensible for the
      future.

Top      Up      ToC       Page 75 
   <rel-addr> and <rel-port>:  convey transport addresses related to the
      candidate, useful for diagnostics and other purposes. <rel-addr>
      and <rel-port> MUST be present for server reflexive, peer
      reflexive, and relayed candidates.  If a candidate is server or
      peer reflexive, <rel-addr> and <rel-port> are equal to the base
      for that server or peer reflexive candidate.  If the candidate is
      relayed, <rel-addr> and <rel-port> is equal to the mapped address
      in the Allocate response that provided the client with that
      relayed candidate (see Appendix B.3 for a discussion of its
      purpose).  If the candidate is a host candidate, <rel-addr> and
      <rel-port> MUST be omitted.

   The candidate attribute can itself be extended.  The grammar allows
   for new name/value pairs to be added at the end of the attribute.  An
   implementation MUST ignore any name/value pairs it doesn't
   understand.

15.2.  "remote-candidates" Attribute

   The syntax of the "remote-candidates" attribute is defined using
   Augmented BNF as defined in RFC 5234 [RFC5234].  The remote-
   candidates attribute is a media-level attribute only.

   remote-candidate-att = "remote-candidates" ":" remote-candidate
                           0*(SP remote-candidate)
   remote-candidate = component-ID SP connection-address SP port

   The attribute contains a connection-address and port for each
   component.  The ordering of components is irrelevant.  However, a
   value MUST be present for each component of a media stream.  This
   attribute MUST be included in an offer by a controlling agent for a
   media stream that is Completed, and MUST NOT be included in any other
   case.

15.3.  "ice-lite" and "ice-mismatch" Attributes

   The syntax of the "ice-lite" and "ice-mismatch" attributes, both of
   which are flags, is:

   ice-lite               = "ice-lite"
   ice-mismatch           = "ice-mismatch"

   "ice-lite" is a session-level attribute only, and indicates that an
   agent is a lite implementation. "ice-mismatch" is a media-level
   attribute only, and when present in an answer, indicates that the
   offer arrived with a default destination for a media component that
   didn't have a corresponding candidate attribute.

Top      Up      ToC       Page 76 
15.4.  "ice-ufrag" and "ice-pwd" Attributes

   The "ice-ufrag" and "ice-pwd" attributes convey the username fragment
   and password used by ICE for message integrity.  Their syntax is:

   ice-pwd-att           = "ice-pwd" ":" password
   ice-ufrag-att         = "ice-ufrag" ":" ufrag
   password              = 22*256ice-char
   ufrag                 = 4*256ice-char

   The "ice-pwd" and "ice-ufrag" attributes can appear at either the
   session-level or media-level.  When present in both, the value in the
   media-level takes precedence.  Thus, the value at the session-level
   is effectively a default that applies to all media streams, unless
   overridden by a media-level value.  Whether present at the session or
   media-level, there MUST be an ice-pwd and ice-ufrag attribute for
   each media stream.  If two media streams have identical ice-ufrag's,
   they MUST have identical ice-pwd's.

   The ice-ufrag and ice-pwd attributes MUST be chosen randomly at the
   beginning of a session.  The ice-ufrag attribute MUST contain at
   least 24 bits of randomness, and the ice-pwd attribute MUST contain
   at least 128 bits of randomness.  This means that the ice-ufrag
   attribute will be at least 4 characters long, and the ice-pwd at
   least 22 characters long, since the grammar for these attributes
   allows for 6 bits of randomness per character.  The attributes MAY be
   longer than 4 and 22 characters, respectively, of course, up to 256
   characters.  The upper limit allows for buffer sizing in
   implementations.  Its large upper limit allows for increased amounts
   of randomness to be added over time.

15.5.  "ice-options" Attribute

   The "ice-options" attribute is a session-level attribute.  It
   contains a series of tokens that identify the options supported by
   the agent.  Its grammar is:

   ice-options           = "ice-options" ":" ice-option-tag
                             0*(SP ice-option-tag)
   ice-option-tag        = 1*ice-char

16.  Setting Ta and RTO

   During the gathering phase of ICE (Section 4.1.1) and while ICE is
   performing connectivity checks (Section 7), an agent sends STUN and
   TURN transactions.  These transactions are paced at a rate of one
   every Ta milliseconds, and utilize a specific RTO.  This section
   describes how the values of Ta and RTO are computed.  This

Top      Up      ToC       Page 77 
   computation depends on whether ICE is being used with a real-time
   media stream (such as RTP) or something else.  When ICE is used for a
   stream with a known maximum bandwidth, the computation in
   Section 16.1 MAY be followed to rate-control the ICE exchanges.  For
   all other streams, the computation in Section 16.2 MUST be followed.

16.1.  RTP Media Streams

   The values of RTO and Ta change during the lifetime of ICE
   processing.  One set of values applies during the gathering phase,
   and the other, for connectivity checks.

   The value of Ta SHOULD be configurable, and SHOULD have a default of:

   For each media stream i:

    Ta_i = (stun_packet_size / rtp_packet_size) * rtp_ptime

                           1
     Ta = MAX (20ms, ------------------- )
                           k
                         ----
                         \        1
                          >    ------
                         /       Ta_i
                         ----
                          i=1

   where k is the number of media streams.  During the gathering phase,
   Ta is computed based on the number of media streams the agent has
   indicated in its offer or answer, and the RTP packet size and RTP
   ptime are those of the most preferred codec for each media stream.
   Once an offer and answer have been exchanged, the agent recomputes Ta
   to pace the connectivity checks.  In that case, the value of Ta is
   based on the number of media streams that will actually be used in
   the session, and the RTP packet size and RTP ptime are those of the
   most preferred codec with which the agent will send.

   In addition, the retransmission timer for the STUN transactions, RTO,
   defined in [RFC5389], SHOULD be configurable and during the gathering
   phase, SHOULD have a default of:

     RTO = MAX (100ms, Ta * (number of pairs))

   where the number of pairs refers to the number of pairs of candidates
   with STUN or TURN servers.

Top      Up      ToC       Page 78 
   For connectivity checks, RTO SHOULD be configurable and SHOULD have a
   default of:

     RTO = MAX (100ms, Ta*N * (Num-Waiting + Num-In-Progress))

   where Num-Waiting is the number of checks in the check list in the
   Waiting state, and Num-In-Progress is the number of checks in the In-
   Progress state.  Note that the RTO will be different for each
   transaction as the number of checks in the Waiting and In-Progress
   states change.

   These formulas are aimed at causing STUN transactions to be paced at
   the same rate as media.  This ensures that ICE will work properly
   under the same network conditions needed to support the media as
   well.  See Appendix B.1 for additional discussion and motivations.
   Because of this pacing, it will take a certain amount of time to
   obtain all of the server reflexive and relayed candidates.
   Implementations should be aware of the time required to do this, and
   if the application requires a time budget, limit the number of
   candidates that are gathered.

   The formulas result in a behavior whereby an agent will send its
   first packet for every single connectivity check before performing a
   retransmit.  This can be seen in the formulas for the RTO (which
   represents the retransmit interval).  Those formulas scale with N,
   the number of checks to be performed.  As a result of this, ICE
   maintains a nicely constant rate, but becomes more sensitive to
   packet loss.  The loss of the first single packet for any
   connectivity check is likely to cause that pair to take a long time
   to be validated, and instead, a lower-priority check (but one for
   which there was no packet loss) is much more likely to complete
   first.  This results in ICE performing sub-optimally, choosing lower-
   priority pairs over higher-priority pairs.  Implementors should be
   aware of this consequence, but still should utilize the timer values
   described here.

16.2.  Non-RTP Sessions

   In cases where ICE is used to establish some kind of session that is
   not real time, and has no fixed rate associated with it that is known
   to work on the network in which ICE is deployed, Ta and RTO revert to
   more conservative values.  Ta SHOULD be configurable, SHOULD have a
   default of 500 ms, and MUST NOT be configurable to be less than 500
   ms.

   In addition, the retransmission timer for the STUN transactions, RTO,
   SHOULD be configurable and during the gathering phase, SHOULD have a
   default of:

Top      Up      ToC       Page 79 
     RTO = MAX (500ms, Ta * (number of pairs))

   where the number of pairs refers to the number of pairs of candidates
   with STUN or TURN servers.

   For connectivity checks, RTO SHOULD be configurable and SHOULD have a
   default of:

     RTO = MAX (500ms, Ta*N * (Num-Waiting + Num-In-Progress))



(page 79 continued on part 4)

Next RFC Part