Change:
Trying to avoid conflicts with txt files by creating a new pull request for the tie-breaker and role changes.

Discussion:
media stream is considered to be Running, and the state of ICE overall is Running. <del> Once roles are determined for a session, they persist unless ICE is restarted.  An ICE restart causes a new selection of roles and tie- breakers. </del> <ins> Once the roles are determined for a session, they persist througout the lifetime of the session.  The roles can be re-determined as part of an ICE restart (sec-restart), but an ICE agent MUST NOT re- determine the role as part of an ICE restart unless one or more of the following criteria is fulfilled: If the controlling agent is full, and switches to lite, the roles MUST be re-determined if the peer agent is also full. If the ICE restart causes a role conflict, the roles might be re- determined due to the role conflict procedures in sec-role- conflict. NOTE: There are certain 3PCC scenarios where an ICE restart might cause a role conflict. NOTE: The ICE agents needs to inform each other whether they are full or lite before the roles are determined.  The mechanism for that is signalling protocol specific, and outside the scope of the document. An ICE agent MUST be prepared that the peer might re-determine the roles as part of any ICE restart, even if the criteria for doing so are not fulfilled.  This can happen if the peer is compliant with an older version of this specification. </ins> 5.1.3.

The agent MUST include the ICE-CONTROLLED attribute in the request if it is in the controlled role, and MUST include the ICE-CONTROLLING <del> attribute in the request if it is in the controlling role.  The content of either attribute MUST be the tie-breaker that was determined in sec-role.  These attributes are defined fully in sec- </del> <ins> attribute in the request if it is in the controlling role. The content of either attribute are used as tie-breaker values when an ICE role conflict occurs sec-role-conflict. The ICE-CONTROLLED and ICE-CONTROLLING attributes are defined in sec- </ins> ice-newatts. 6.1.2.4.

6.1.3.1. If the STUN transaction generates a 487 (Role Conflict) error <del> response, the agent checks whether it included the ICE-CONTROLLED or ICE-CONTROLLING attribute in the Binding request.  If the request contained the ICE-CONTROLLED attribute, the agent MUST switch to the controlling role if it has not already done so.  If the request contained the ICE-CONTROLLING attribute, the agent MUST switch to the controlled role if it has not already done so.  Once it has switched, the agent MUST enqueue the candidate pair whose check generated the 487 into the triggered check queue.  The state of that pair is set to Waiting.  When the triggered check is sent, it will contain an ICE- CONTROLLING or ICE-CONTROLLED attribute reflecting its new role. Note, however, that the tie-breaker value MUST NOT be reselected. </del> <ins> response, the agent checks whether it included an ICE-CONTROLLED or ICE-CONTROLLING attribute in the associated Binding request.  If the request contained an ICE-CONTROLLED attribute, the agent MUST switch to the controlling role.  If the request contained an ICE-CONTROLLING attribute, the agent MUST switch to the controlled role. Once the agent has switched its role, the agent MUST enqueue the candidate pair whose check generated the 487 into the triggered check queue.  The state of that pair is set to Waiting.  When the triggered check is sent, it will contain an ICE-CONTROLLING or ICE-CONTROLLED attribute reflecting its new role.  The agent MUST NOT change the tie-breaker value. </ins> A change in roles will require an agent to recompute pair priorities (sec-comp-pair-prio), since those priorities are a function of

If the agent is in the controlling role, and the ICE-CONTROLLING attribute is present in the request: <del> If the agent's tie-breaker is larger than or equal to the </del> <ins> If the agent's tie-breaker value is larger than or equal to the </ins> contents of the ICE-CONTROLLING attribute, the agent generates a Binding error response and includes an ERROR-CODE attribute with a value of 487 (Role Conflict) but retains its role. <del> If the agent's tie-breaker is less than the contents of the ICE-CONTROLLING attribute, the agent switches to the controlled role. </del> <ins> If the agent's tie-breaker value is less than the contents of the ICE-CONTROLLING attribute, the agent switches to the controlled role. </ins> If the agent is in the controlled role, and the ICE-CONTROLLED attribute is present in the request: <del> If the agent's tie-breaker is larger than or equal to the </del> <ins> If the agent's tie-breaker value is larger than or equal to the </ins> contents of the ICE-CONTROLLED attribute, the agent switches to the controlling role. <del> If the agent's tie-breaker is less than the contents of the ICE-CONTROLLED attribute, the agent generates a Binding error response and includes an ERROR-CODE attribute with a value of 487 (Role Conflict) but retains its role. </del> <ins> If the agent's tie-breaker value is less than the contents of the ICE-CONTROLLED attribute, the agent generates a Binding error response and includes an ERROR-CODE attribute with a value of 487 (Role Conflict) but retains its role. </ins> If the agent is in the controlled role and the ICE-CONTROLLING attribute was present in the request, or the agent was in the

8. An agent MAY restart ICE processing for an existing media stream.  An <del> 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. </del> <ins> ICE restart will cause all previous states, excluding the roles of the agents, 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, and that a new media session always requires the roles to be determined. </ins> An agent MUST restart ICE for a media stream if:

candidates for that stream and MAY include a totally new set of candidates. <ins> As described in sec-role, ICE agents MUST NOT re-determine the roles as part as an ICE restart, unless certain criteria that require the roles to be re-determined is fulfilled. </ins> 9. This section defines a new ICE option, 'ice2'.  The ICE option

All endpoints MUST send keepalives for each media session.  These keepalives serve the purpose of keeping NAT bindings alive for the <del> media 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 agent is a full ICE implementation and is communicating with a peer that supports ICE (lite or full). </del> <ins> media session.  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). 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 I-D.ietf-avt-rtp-no-op, 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. </ins> 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 <del> agent MUST generate a keepalive on that pair.  ICE endpoints SHOULD use a Tr value of 15 seconds, but MAY use another value, 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.  ICE endpoints MUST NOT use a Tr value smaller than 15 seconds. When STUN is being used for keepalives, a STUN Binding Indication is </del> <ins> 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 </ins> 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

13. <ins> During the gathering phase of ICE (sec-gathering) and while ICE is performing connectivity checks (sec-connectivity_check), 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 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 sec-rtp- based MAY be followed to rate-control the ICE exchanges.  For all other streams, the computation in sec-non-rtp MUST be followed. </ins> 13.1. <del> During the ICE gathering phase (sec-gathering) and while ICE is performing connectivity checks (sec-connectivity_check), an 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 the retransmission timer for the STUN transactions (RTO) RFC5389. This section describes how the Ta and RTO values are computed during the ICE gathering pahse and while ICE is performing connectivity checks. NOTE: Previously, in RFC 5245, different formulas were defined for comupting Ta and RTO, depending on whether ICE was used for a real- time media stream (e.g.  RTP) or not. 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 becomes more sensitive to </del> <ins> 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: 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 the candidate information, and the RTP packet size and RTP ptime are those of the most preferred codec for each media stream.  Once the candidate exchange is completed, 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: 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: 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 sec-pacing 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 </ins> 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

13.2. <del> ICE agents SHOULD use the default Ta value, 50 ms, but MAY use another value based on the characteristics of the associated media. ICE agents MUST NOT use a Ta value smaller than 5 ms. If an ICE agent wants to use another Ta value than the default value, the agent MUST indicate the proposed value to its peer during the ICE exchange.  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. NOTE: sec-concheckbw shows examples of required bandwidth, using different Ta values. </del> <ins> 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. </ins> <del> 13.3. </del> <ins> If other Ta value than the default is used, the agent MUST indicate the value it prefers to use in the ICE exchange.  Both agents MUST use the higher out of the two proposed values. </ins> <del> During the ICE gathering phase, ICE agents SHOULD calculate the RTO value using the following formula: </del> <ins> In addition, the retransmission timer for the STUN transactions, RTO, SHOULD be configurable and during the gathering phase, SHOULD have a default of: </ins> <del> For connectivity checks, ICE agents SHOULD calculate the RTO value using the following formula: </del> <ins> where the number of pairs refers to the number of pairs of candidates with STUN or TURN servers. </ins> <del> ICE agents MAY calculate the RTO value using other mechanisms than those described above.  ICE agents MUST NOT use a RTO value smaller than 500 ms. </del> <ins> For connectivity checks, RTO SHOULD be configurable and SHOULD have a default of: </ins> 14.

The ICE-CONTROLLED attribute is present in a Binding request and indicates that the client believes it is currently in the controlled role.  The content of the attribute is a 64-bit unsigned integer in <del> network byte order, which contains a random number used for tie- breaking of role conflicts. </del> <ins> network byte order, which contains a random number.  The number is used for solving role conflicts, when it is referred to as the tie- breaker value.  An ICE agent MUST use the same number for all Binding requests, for all streams, within an ICE session.  The ICE agent MAY change the number when an ICE restart occurs. </ins> The ICE-CONTROLLING attribute is present in a Binding request and indicates that the client believes it is currently in the controlling role.  The content of the attribute is a 64-bit unsigned integer in <del> network byte order, which contains a random number used for tie- breaking of role conflicts. </del> <ins> network byte order, which contains a random number.  The number is used for solving role conflicts, when it is referred to as the tie- breaker value.  An ICE agent MUST use the same number for all Binding requests, for all streams, within an ICE session.  The ICE agent MAY change the number when an ICE restart occurs. </ins> 16.2. This specification defines a single error response code: The Binding request contained either the ICE-CONTROLLING or ICE- <del> CONTROLLED attribute, indicating a role that conflicted with the server.  The server ran a tie-breaker based on the tie-breaker value in the request and determined that the client needs to </del> <ins> CONTROLLED attribute, indicating an ICE role that conflicted with the server.  The server compared the tie-breaker values of the client and the server and determined that the client needs to </ins> switch roles. 17.