Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8445

Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal

Pages: 100
Proposed Standard
Errata
Obsoletes:  5245
Updated by:  8863
Part 4 of 6 – Pages 53 to 70
First   Prev   Next

Top   ToC   RFC8445 - Page 53   prevText

9. ICE Restarts

An ICE agent MAY restart ICE for existing data streams. An ICE restart causes all previous states of the data streams, excluding the roles of the agents, to be flushed. The only difference between an ICE restart and a brand new data session is that during the restart, data can continue to be sent using existing data sessions, and a new data session always requires the roles to be determined.
Top   ToC   RFC8445 - Page 54
   The following actions can be accomplished only by using an ICE
   restart (the agent MUST use ICE restarts to do so):

   o  Change the destinations of data streams.

   o  Change from a lite implementation to a full implementation.

   o  Change from a full implementation to a lite implementation.

   To restart ICE, an agent MUST change both the password and the
   username fragment for the data stream(s) being restarted.

   When the ICE is restarted, the candidate set for the new ICE session
   might include some, none, or all of the candidates used in the
   current ICE session.

   As described in Section 6.1.1, agents MUST NOT redetermine the roles
   as part as an ICE restart, unless certain criteria that require the
   roles to be redetermined are fulfilled.

10. ICE Option

This section defines a new ICE option, 'ice2'. When an ICE agent includes 'ice2' in a candidate exchange, the ICE option indicates that it is compliant to this specification. For example, the agent will not use the aggressive nomination procedure defined in RFC 5245. In addition, it will ensure that a peer compliant with RFC 5245 does not use aggressive nomination either, as required by Section 14 of RFC 5245 for peers that receive unknown ICE options. An agent compliant to this specification MUST inform the peer about the compliance using the 'ice2' option. NOTE: The encoding of the 'ice2' option, and the message(s) used to carry it to the peer, are protocol specific. The encoding for SDP [RFC4566] is defined in [ICE-SIP-SDP].

11. Keepalives

All endpoints MUST send keepalives for each data session. These keepalives serve the purpose of keeping NAT bindings alive for the data session. The keepalives 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 ICE agent is a full ICE implementation and is communicating with a peer that supports ICE (lite or full).
Top   ToC   RFC8445 - Page 55
   An agent MUST send a keepalive on each candidate pair that is used
   for sending data if no packet has been sent on that pair in the last
   Tr seconds.  Agents SHOULD use a Tr value of 15 seconds.  Agents MAY
   use a bigger value but MUST NOT use a value smaller than 15 seconds.

   Once selected pairs have been produced for a data stream, keepalives
   are only sent on those pairs.

   An agent MUST stop sending keepalives on a data stream if the data
   stream is removed.  If the ICE session is terminated, an agent MUST
   stop sending keepalives on all data streams.

   An agent MAY use another value for Tr, e.g., based on configuration
   or network/NAT characteristics.  For example, 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.

   When 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 it 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 data.  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.

   Agents MUST by default use STUN keepalives.  Individual ICE usages
   and ICE extensions MAY specify usage-/extension-specific keepalives.

12. Data Handling

12.1. Sending Data

An ICE agent MAY send data on any valid pair before selected pairs have been produced for the data stream. Once selected pairs have been produced for a data stream, an agent MUST send data on those pairs only. An agent sends data from the base of the local candidate to the remote candidate. In the case of a local relayed candidate, data is forwarded through the base (located in the TURN server), using the procedures defined in [RFC5766].
Top   ToC   RFC8445 - Page 56
   If the local candidate is a relayed candidate, it is RECOMMENDED that
   an agent creates 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 data stream is:

   o  empty if the state of the checklist for that data 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 data
      stream if the state of the checklist for that data stream is
      Running, and there was a previous selected pair for that component
      due to an ICE restart

   Unless an agent is able to produce a selected pair for each component
   associated with a data stream, the agent MUST NOT continue sending
   data for any component associated with that data stream.

12.1.1. Procedures for Lite Implementations

A lite implementation MUST NOT send data until it has a valid list that contains a candidate pair for each component of that data stream. Once that happens, the ICE agent MAY begin sending data packets. To do that, it sends data 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 base associated with the candidate pair used for sending data. In case of a relayed candidate, data is sent from the agent and forwarded through the base (located in the TURN server), using the procedures defined in [RFC5766].

12.2. Receiving Data

Even though ICE agents are only allowed to send data using valid candidate pairs (and, once selected pairs have been produced, only on the selected pairs), ICE implementations SHOULD by default be prepared to receive data on any of the candidates provided in the most recent candidate exchange with the peer. ICE usages MAY define rules that differ from this, e.g., by defining that data will not be sent until selected pairs have been produced for a data stream. When an agent receives an RTP packet with a new source or destination IP address for a particular RTP/RTCP data stream, it is RECOMMENDED that the agent readjust its jitter buffers.
Top   ToC   RFC8445 - Page 57
   Section 8.2 of RFC 3550 [RFC3550] describes an algorithm for
   detecting synchronization source (SSRC) collisions and loops.  These
   algorithms are based, in part, on seeing different source transport
   addresses with the same SSRC.  However, when ICE is used, such
   changes will sometimes occur as the data streams switch between
   candidates.  An agent will be able to determine that a data stream is
   from the same peer as a consequence of the STUN exchange that
   proceeds media data transmission.  Thus, if there is a change in the
   source transport address, but the media data packets come from the
   same peer agent, this MUST NOT be treated as an SSRC collision.

13. Extensibility Considerations

This specification makes very specific choices about how both ICE agents in a session coordinate to arrive at the set of candidate pairs that are selected for data. 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 ICE option concept. Each extension or change to ICE is associated with an ICE option. When an agent supports such an extension or change, it provides the ICE option to the peer agent as part of the candidate exchange. 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 nomination procedure described in Section 8 eliminates some of the need for tight coordination by delegating the selection algorithm completely to the controlling agent, and 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. ICE is also extensible to other data streams beyond RTP and for transport protocols beyond UDP. Extensions to ICE for non-RTP data 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   ToC   RFC8445 - Page 58

14. Setting Ta and RTO

14.1. General

During the ICE gathering phase (Section 5.1.1) and while ICE is performing connectivity checks (Section 7), an ICE agent triggers STUN and TURN transactions. These transactions are paced at a rate indicated by Ta, and the retransmission interval for each transaction is calculated based on the retransmission timer for the STUN transactions (RTO) [RFC5389]. This section describes how the Ta and RTO values are computed during the ICE gathering phase and while ICE is performing connectivity checks. NOTE: Previously, in RFC 5245, different formulas were defined for computing Ta and RTO, depending on whether or not ICE was used for a real-time data stream (e.g., RTP). The formulas below 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 it 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 suboptimally, choosing lower- priority pairs over higher-priority pairs.

14.2. Ta

ICE agents SHOULD use a default Ta value, 50 ms, but MAY use another value based on the characteristics of the associated data. If an agent wants to use a Ta value other than the default value, the agent MUST indicate the proposed value to its peer during the establishment of the ICE session. Both agents MUST use the higher value of the proposed values. If an agent does not propose a value, the default value is used for that agent when comparing which value is higher. Regardless of the Ta value chosen for each agent, the combination of all transactions from all agents (if a given implementation runs several concurrent agents) MUST NOT be sent more often than once
Top   ToC   RFC8445 - Page 59
   every 5 ms (as though there were one global Ta value for pacing all
   agents).  See Appendix B.1 for the background of using a value of
   5 ms with ICE.

   NOTE: Appendix C shows examples of required bandwidth, using
   different Ta values.

14.3. RTO

During the ICE gathering phase, ICE agents SHOULD calculate the RTO value using the following formula: RTO = MAX (500ms, Ta * (Num-Of-Cands)) Num-Of-Cands: the number of server-reflexive and relay candidates For connectivity checks, agents SHOULD calculate the RTO value using the following formula: RTO = MAX (500ms, Ta * N * (Num-Waiting + Num-In-Progress)) N: the total number of connectivity checks to be performed. Num-Waiting: the number of checks in the checklist set in the Waiting state. Num-In-Progress: the number of checks in the checklist set 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. Agents MAY calculate the RTO value using other mechanisms than those described above. Agents MUST NOT use an RTO value smaller than 500 ms.

15. Examples

This section shows two ICE examples: one using IPv4 addresses and one using IPv6 addresses. To facilitate understanding, transport addresses are listed using variables that have mnemonic names. The format of the name is entity-type-seqno: "entity" refers to the entity whose IP address the transport address is on and is one of "L", "R", "STUN", or "NAT". The type is either "PUB" for transport addresses that are public or "PRIV" for transport addresses that are private [RFC1918]. Finally,
Top   ToC   RFC8445 - Page 60
   seq-no is a sequence number that is different for each transport
   address of the same type on a particular entity.  Each variable has
   an IP address and port, denoted by varname.IP and varname.PORT,
   respectively, where varname is the name of the variable.

   In the call flow itself, STUN messages are annotated with several
   attributes.  The "S=" attribute indicates the source transport
   address of the message.  The "D=" attribute indicates the destination
   transport address of the message.  The "MA=" attribute is used in
   STUN Binding response messages and refers to the mapped address.
   "USE-CAND" implies the presence of the USE-CANDIDATE attribute.

   The call flow examples omit STUN authentication operations and focus
   on a single data stream between two full implementations.

15.1. Example with IPv4 Addresses

The example below is using the topology shown in Figure 7. +-------+ |STUN | |Server | +-------+ | +---------------------+ | | | Internet | | | +---------------------+ | | | | +---------+ | | NAT | | +---------+ | | | | | +-----+ +-----+ | L | | R | +-----+ +-----+ Figure 7: Example Topology
Top   ToC   RFC8445 - Page 61
   In the example, ICE agents L and R are full ICE implementations.
   Both agents have a single IPv4 address, and both are configured with
   the same STUN server.  The NAT has an endpoint-independent mapping
   property and an address-dependent filtering property.  The IP
   addresses of the ICE agents, the STUN server, and the NAT are shown
   below:

   ENTITY                   IP Address  Mnemonic name
   --------------------------------------------------
   ICE Agent L:             10.0.1.1    L-PRIV-1
   ICE Agent R:             192.0.2.1   R-PUB-1
   STUN Server:             192.0.2.2   STUN-PUB-1
   NAT (Public):            192.0.2.3   NAT-PUB-1


             L             NAT           STUN             R
             |STUN alloc.   |              |              |
             |(1) STUN Req  |              |              |
             |S=$L-PRIV-1   |              |              |
             |D=$STUN-PUB-1 |              |              |
             |------------->|              |              |
             |              |(2) STUN Req  |              |
             |              |S=$NAT-PUB-1  |              |
             |              |D=$STUN-PUB-1 |              |
             |              |------------->|              |
             |              |(3) STUN Res  |              |
             |              |S=$STUN-PUB-1 |              |
             |              |D=$NAT-PUB-1  |              |
             |              |MA=$NAT-PUB-1 |              |
             |              |<-------------|              |
             |(4) STUN Res  |              |              |
             |S=$STUN-PUB-1 |              |              |
             |D=$L-PRIV-1   |              |              |
             |MA=$NAT-PUB-1 |              |              |
             |<-------------|              |              |
             |(5) L's Candidate Information|              |
             |------------------------------------------->|
             |              |              |              | STUN
             |              |              |              | alloc.
             |              |              |(6) STUN Req  |
             |              |              |S=$R-PUB-1    |
             |              |              |D=$STUN-PUB-1 |
             |              |              |<-------------|
             |              |              |(7) STUN Res  |
             |              |              |S=$STUN-PUB-1 |
             |              |              |D=$R-PUB-1    |
             |              |              |MA=$R-PUB-1   |
             |              |              |------------->|
Top   ToC   RFC8445 - Page 62
             |(8) R's Candidate Information|              |
             |<-------------------------------------------|
             |              |         (9) Bind Req        |Begin
             |              |         S=$R-PUB-1          |Connectivity
             |              |         D=$L-PRIV-1         |Checks
             |              |         <-------------------|
             |              |         Dropped             |
             |(10) Bind Req |              |              |
             |S=$L-PRIV-1   |              |              |
             |D=$R-PUB-1    |              |              |
             |------------->|              |              |
             |              |(11) Bind Req |              |
             |              |S=$NAT-PUB-1  |              |
             |              |D=$R-PUB-1    |              |
             |              |---------------------------->|
             |              |(12) Bind Res |              |
             |              |S=$R-PUB-1    |              |
             |              |D=$NAT-PUB-1  |              |
             |              |MA=$NAT-PUB-1 |              |
             |              |<----------------------------|
             |(13) Bind Res |              |              |
             |S=$R-PUB-1    |              |              |
             |D=$L-PRIV-1   |              |              |
             |MA=$NAT-PUB-1 |              |              |
             |<-------------|              |              |
             |Data          |              |              |
             |===========================================>|
             |              |              |              |
             |              |(14) Bind Req |              |
             |              |S=$R-PUB-1    |              |
             |              |D=$NAT-PUB-1  |              |
             |              |<----------------------------|
             |(15) Bind Req |              |              |
             |S=$R-PUB-1    |              |              |
             |D=$L-PRIV-1   |              |              |
             |<-------------|              |              |
             |(16) Bind Res |              |              |
             |S=$L-PRIV-1   |              |              |
             |D=$R-PUB-1    |              |              |
             |MA=$R-PUB-1   |              |              |
             |------------->|              |              |
             |              |(17) Bind Res |              |
             |              |S=$NAT-PUB-1  |              |
             |              |D=$R-PUB-1    |              |
             |              |MA=$R-PUB-1   |              |
             |              |---------------------------->|
             |Data          |              |              |
             |<===========================================|
Top   ToC   RFC8445 - Page 63
             |              |              |              |
                                .......
             |              |              |              |
             |(18) Bind Req |              |              |
             |S=$L-PRIV-1   |              |              |
             |D=$R-PUB-1    |              |              |
             |USE-CAND      |              |              |
             |------------->|              |              |
             |              |(19) Bind Req |              |
             |              |S=$NAT-PUB-1  |              |
             |              |D=$R-PUB-1    |              |
             |              |USE-CAND      |              |
             |              |---------------------------->|
             |              |(20) Bind Res |              |
             |              |S=$R-PUB-1    |              |
             |              |D=$NAT-PUB-1  |              |
             |              |MA=$NAT-PUB-1 |              |
             |              |<----------------------------|
             |(21) Bind Res |              |              |
             |S=$R-PUB-1    |              |              |
             |D=$L-PRIV-1   |              |              |
             |MA=$NAT-PUB-1 |              |              |
             |<-------------|              |              |
             |              |              |              |

                          Figure 8: Example Flow

   Messages 1-4: Agent L gathers a host candidate from its local IP
   address, and from that it sends a STUN Binding request to the STUN
   server.  The request creates a NAT binding.  The NAT public IP
   address of the binding becomes agent L's server-reflexive candidate.

   Message 5: Agent L sends its local candidate information to agent R,
   using the signaling protocol associated with the ICE usage.

   Messages 6-7: Agent R gathers a host candidate from its local IP
   address, and from that it sends a STUN Binding request to the STUN
   server.  Since agent R is not behind a NAT, R's server-reflexive
   candidate will be identical to the host candidate.

   Message 8: Agent R sends its local candidate information to agent L,
   using the signaling protocol associated with the ICE usage.

   Since both agents are full ICE implementations, the initiating agent
   (agent L) becomes the controlling agent.
Top   ToC   RFC8445 - Page 64
   Agents L and R both pair up the candidates.  Both agents initially
   have two pairs.  However, agent L will prune the pair containing its
   server-reflexive candidate, resulting in just one (L1).  At agent L,
   this pair has a local candidate of $L_PRIV_1 and a remote candidate
   of $R_PUB_1.  At agent R, there are two pairs.  The highest-priority
   pair (R1) has a local candidate of $R_PUB_1 and a remote candidate of
   $L_PRIV_1, and the second pair (R2) has a local candidate of $R_PUB_1
   and a remote candidate of $NAT_PUB_1.  The pairs are shown below (the
   pair numbers are for reference purposes only):

                            Pairs
   ENTITY                   Local         Remote     Pair #     Valid
   ------------------------------------------------------------------
   ICE Agent L:             L_PRIV_1      R_PUB_1       L1

   ICE Agent R:             R_PUB_1       L_PRIV_1      R1
                            R_PUB_1       NAT_PUB_1     R2

   Message 9: Agent R initiates a connectivity check for pair #2.  As
   the remote candidate of the pair is the private address of agent L,
   the check will not be successful, as the request cannot be routed
   from R to L, and will be dropped by the network.

   Messages 10-13: Agent L initiates a connectivity check for pair L1.
   The check succeeds, and L creates a new pair (L2).  The local
   candidate of the new pair is $NAT_PUB_1, and the remote candidate is
   $R_PUB_1.  The pair (L2) is added to the valid list of agent L.
   Agent L can now send and receive data on the pair (L2) if it wishes.

                            Pairs
   ENTITY                   Local         Remote     Pair #     Valid
   ------------------------------------------------------------------
   ICE Agent L:             L_PRIV_1      R_PUB_1       L1
                            NAT_PUB_1     R_PUB_1       L2        X

   ICE Agent R:             R_PUB_1       L_PRIV_1      R1
                            R_PUB_1       NAT_PUB_1     R2

   Messages 14-17: When agent R receives the Binding request from agent
   L (message 11), it will initiate a triggered connectivity check.  The
   pair matches one of agent R's existing pairs (R2).  The check
   succeeds, and the pair (R2) is added to the valid list of agent R.
   Agent R can now send and receive data on the pair (R2) if it wishes.
Top   ToC   RFC8445 - Page 65
                            Pairs
   ENTITY                   Local         Remote     Pair #     Valid
   ------------------------------------------------------------------
   ICE Agent L:             L_PRIV_1      R_PUB_1       L1
                            NAT_PUB_1     R_PUB_1       L2        X

   ICE Agent R:             R_PUB_1       L_PRIV_1      R1
                            R_PUB_1       NAT_PUB_1     R2        X

   Messages 18-21: At some point, the controlling agent (agent L)
   decides to nominate a pair (L2) in the valid list.  It performs a
   connectivity check on the pair (L2) and includes the USE-CANDIDATE
   attribute in the Binding request.  As the check succeeds, agent L
   sets the nominated flag value of the pair (L2) to 'true', and agent R
   sets the nominated flag value of the matching pair (R2) to 'true'.
   As there are no more components associated with the stream, the
   nominated pairs become the selected pairs.  Consequently, processing
   for this stream moves into the Completed state.  The ICE process also
   moves into the Completed state.

15.2. Example with IPv6 Addresses

The example below is using the topology shown in Figure 9. +-------+ |STUN | |Server | +-------+ | +---------------------+ | | | Internet | | | +---------------------+ | | | | | | | | | | | | | | +-----+ +-----+ | L | | R | +-----+ +-----+ Figure 9: Example Topology
Top   ToC   RFC8445 - Page 66
   In the example, ICE agents L and R are full ICE implementations.
   Both agents have a single IPv6 address, and both are configured with
   the same STUN server.  The IP addresses of the ICE agents and the
   STUN server are shown below:

   ENTITY                   IP Address  mnemonic name
   --------------------------------------------------
   ICE Agent L:             2001:db8::3   L-PUB-1
   ICE Agent R:             2001:db8::5   R-PUB-1
   STUN Server:             2001:db8::9   STUN-PUB-1


             L                           STUN             R
             |STUN alloc.                  |              |
             |(1) STUN Req                 |              |
             |S=$L-PUB-1                   |              |
             |D=$STUN-PUB-1                |              |
             |---------------------------->|              |
             |(2) STUN Res                 |              |
             | S=$STUN-PUB-1               |              |
             | D=$L-PUB-1                  |              |
             | MA=$L-PUB-1                 |              |
             |<----------------------------|              |
             |(3) L's Candidate Information|              |
             |------------------------------------------->|
             |                             |              | STUN
             |                             |              | alloc.
             |                             |(4) STUN Req  |
             |                             |S=$R-PUB-1    |
             |                             |D=$STUN-PUB-1 |
             |                             |<-------------|
             |                             |(5) STUN Res  |
             |                             |S=$STUN-PUB-1 |
             |                             |D=$R-PUB-1    |
             |                             |MA=$R-PUB-1   |
             |                             |------------->|
             |(6) R's Candidate Information|              |
             |<-------------------------------------------|
             |(7) Bind Req                 |              |
             |S=$L-PUB-1                   |              |
             |D=$R-PUB-1                   |              |
             |------------------------------------------->|
             |(8) Bind Res                 |              |
             |S=$R-PUB-1                   |              |
             |D=$L-PUB-1                   |              |
             |MA=$L-PUB-1                  |              |
             |<-------------------------------------------|
Top   ToC   RFC8445 - Page 67
             |Data                         |              |
             |===========================================>|
             |                             |              |
             |(9) Bind Req                 |              |
             |S=$R-PUB-1                   |              |
             |D=$L-PUB-1                   |              |
             |<-------------------------------------------|
             |(10) Bind Res                |              |
             |S=$L-PUB-1                   |              |
             |D=$R-PUB-1                   |              |
             |MA=$R-PUB-1                  |              |
             |------------------------------------------->|
             |Data                         |              |
             |<===========================================|
             |                             |              |
                                .......
             |                             |              |
             |(11) Bind Req                |              |
             |S=$L-PUB-1                   |              |
             |D=$R-PUB-1                   |              |
             |USE-CAND                     |              |
             |------------------------------------------->|
             |(12) Bind Res                |              |
             |S=$R-PUB-1                   |              |
             |D=$L-PUB-1                   |              |
             |MA=$L-PUB-1                  |              |
             |<-------------------------------------------|
             |              |              |              |

                          Figure 10: Example Flow

   Messages 1-2: Agent L gathers a host candidate from its local IP
   address, and from that it sends a STUN Binding request to the STUN
   server.  Since agent L is not behind a NAT, L's server-reflexive
   candidate will be identical to the host candidate.

   Message 3: Agent L sends its local candidate information to agent R,
   using the signaling protocol associated with the ICE usage.

   Messages 4-5: Agent R gathers a host candidate from its local IP
   address, and from that it sends a STUN Binding request to the STUN
   server.  Since agent R is not behind a NAT, R's server-reflexive
   candidate will be identical to the host candidate.

   Message 6: Agent R sends its local candidate information to agent L,
   using the signaling protocol associated with the ICE usage.
Top   ToC   RFC8445 - Page 68
   Since both agents are full ICE implementations, the initiating agent
   (agent L) becomes the controlling agent.

   Agents L and R both pair up the candidates.  Both agents initially
   have one pair each.  At agent L, the pair (L1) has a local candidate
   of $L_PUB_1 and a remote candidate of $R_PUB_1.  At agent R, the pair
   (R1) has a local candidate of $R_PUB_1 and a remote candidate of
   $L_PUB_1.  The pairs are shown below (the pair numbers are for
   reference purpose only):

                            Pairs
   ENTITY                   Local         Remote     Pair #     Valid
   ------------------------------------------------------------------
   ICE Agent L:             L_PUB_1       R_PUB_1       L1

   ICE Agent R:             R_PUB_1       L_PUB_1       R1

   Messages 7-8: Agent L initiates a connectivity check for pair L1.
   The check succeeds, and the pair (L1) is added to the valid list of
   agent L.  Agent L can now send and receive data on the pair (L1) if
   it wishes.

                            Pairs
   ENTITY                   Local         Remote     Pair #     Valid
   ------------------------------------------------------------------
   ICE Agent L:             L_PUB_1       R_PUB_1       L1         X

   ICE Agent R:             R_PUB_1       L_PUB_1       R1

   Messages 9-10: When agent R receives the Binding request from agent L
   (message 7), it will initiate a triggered connectivity check.  The
   pair matches agent R's existing pair (R1).  The check succeeds, and
   the pair (R1) is added to the valid list of agent R.  Agent R can now
   send and receive data on the pair (R1) if it wishes.

                            Pairs
   ENTITY                   Local         Remote     Pair #     Valid
   ------------------------------------------------------------------
   ICE Agent L:             L_PUB_1       R_PUB_1       L1         X

   ICE Agent R:             R_PUB_1       L_PUB_1       R1         X

   Messages 11-12: At some point, the controlling agent (agent L)
   decides to nominate a pair (L1) in the valid list.  It performs a
   connectivity check on the pair (L1) and includes the USE-CANDIDATE
   attribute in the Binding request.  As the check succeeds, agent L
   sets the nominated flag value of the pair (L1) to 'true', and agent R
   sets the nominated flag value of the matching pair (R1) to 'true'.
Top   ToC   RFC8445 - Page 69
   As there are no more components associated with the stream, the
   nominated pairs become the selected pairs.  Consequently, processing
   for this stream moves into the Completed state.  The ICE process also
   moves into the Completed state.

16. STUN Extensions

16.1. Attributes

This specification defines four STUN attributes: PRIORITY, USE-CANDIDATE, ICE-CONTROLLED, and ICE-CONTROLLING. The PRIORITY attribute indicates the priority that is to be associated with a peer-reflexive candidate, if one will be discovered by this check. It is a 32-bit unsigned integer and has an attribute value of 0x0024. The USE-CANDIDATE attribute indicates that the candidate pair resulting from this check will be used for transmission of data. The attribute has no content (the Length field of the attribute is zero); it serves as a flag. It has an attribute value of 0x0025. The ICE-CONTROLLED attribute is present in a Binding request. The attribute indicates that the client believes it is currently in the controlled role. The content of the attribute is a 64-bit unsigned integer in network byte order, which contains a random number. The number is used for solving role conflicts, when it is referred to as the "tiebreaker value". An ICE agent MUST use the same number for all Binding requests, for all streams, within an ICE session, unless it has received a 487 response, in which case it MUST change the number (Section 7.2.5.1). The agent MAY change the number when an ICE restart occurs. The ICE-CONTROLLING attribute is present in a Binding request. The attribute indicates that the client believes it is currently in the controlling role. The content of the attribute is a 64-bit unsigned integer in network byte order, which contains a random number. As for the ICE-CONTROLLED attribute, the number is used for solving role conflicts. An agent MUST use the same number for all Binding requests, for all streams, within an ICE session, unless it has received a 487 response, in which case it MUST change the number (Section 7.2.5.1). The agent MAY change the number when an ICE restart occurs.
Top   ToC   RFC8445 - Page 70

16.2. New Error-Response Codes

This specification defines a single error-response code: 487 (Role Conflict): The Binding request contained either the ICE- CONTROLLING or ICE-CONTROLLED attribute, indicating an ICE role that conflicted with the server. The remote server compared the tiebreaker values of the client and the server and determined that the client needs to switch roles.


(page 70 continued on part 5)

Next Section