RFC 8445
Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal
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.
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).
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].
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.
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.
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
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,
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
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 |
| | |------------->|
|(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 | | |
|<===========================================|
| | | | ....... | | | | |(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.
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.
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
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 | |
|<-------------------------------------------|
|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.
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'.
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.
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)
