Draft: draft-ietf-ice-rfc5245bis

Commentary: Tie - breakar , role and ICE restart clarifications submitted again - after problems with previous mergers 
 lgtm , thanks  . 
 LGTM
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.
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.
The agent MUST include the ICE-CONTROLLED attribute in the request if
it is in the controlled role, and MUST include the ICE-CONTROLLING
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-
ice-newatts.
The agent MUST include the ICE-CONTROLLED attribute in the request if
it is in the controlled role, and MUST include the ICE-CONTROLLING
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-
ice-newatts.
If the STUN transaction generates a 487 (Role Conflict) error
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.
If the STUN transaction generates a 487 (Role Conflict) error
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.
If the agent's tie-breaker is larger than or equal to the
contents of the ICE-CONTROLLING attribute, the agent generates
a Binding error response and includes an ERROR-CODE attribute
with a value of 487 (Role Conflict) but retains its role.
If the agent's tie-breaker is less than the contents of the
ICE-CONTROLLING attribute, the agent switches to the controlled
role.
If the agent's tie-breaker is larger than or equal to the
contents of the ICE-CONTROLLED attribute, the agent switches to
the controlling role.
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.
If the agent's tie-breaker value is larger than or equal to the
contents of the ICE-CONTROLLING attribute, the agent generates
a Binding error response and includes an ERROR-CODE attribute
with a value of 487 (Role Conflict) but retains its role.
If the agent's tie-breaker value is less than the contents of
the ICE-CONTROLLING attribute, the agent switches to the
controlled role.
If the agent's tie-breaker value is larger than or equal to the
contents of the ICE-CONTROLLED attribute, the agent switches to
the controlling role.
If the agent's 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.
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 MAY restart ICE processing for an existing media stream.  An
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.
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.
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.
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 ICE was used for a real-
time media stream (e.g.  RTP) or not.
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
network byte order, which contains a random number used for tie-
breaking of role conflicts.
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
network byte order, which contains a random number used for tie-
breaking of role conflicts.
The Binding request contained either the ICE-CONTROLLING or ICE-
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
switch roles.
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
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.
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
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.
The Binding request contained either the ICE-CONTROLLING or ICE-
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
switch roles.