Draft: draft-ietf-ice-rfc5245bis

Commentary: I do n't have time to go through this in detail , but here are a couple of comments .
Protocols establishing multimedia sessions between peers typically
involve exchanging IP addresses and ports for the media sources and
sinks.  However this poses challenges when operated through Network
Address Translators (NATs) RFC3235.  These protocols also seek to
create a media flow directly between participants, so that there is
no application layer intermediary between them.  This is done to
reduce media latency, decrease packet loss, and reduce the
operational costs of deploying the application.  However, this is
difficult to accomplish through NAT.  A full treatment of the reasons
for this is beyond the scope of this specification.
Protocols establishing multimedia sessions between peers typically
involve exchanging IP addresses and ports for the media sources and
sinks.  However this poses challenges when operated through Network
Address Translators (NATs) RFC3235.  These protocols also seek to
create a media flow directly between participants, so that there is
no application layer intermediary between them.  This is done to
reduce media latency, decrease packet loss, and reduce the
operational costs of deploying the application.  However, this is
difficult to accomplish through NATs.  A full treatment of the
reasons for this is beyond the scope of this specification.
address will work, the initiating sends both the candidates to its
peer.
address will work, the initiating agent sends both the candidates to
its peer.
When the agent sends the TURN Allocate request from IP address and
port X:x, the NAT (assuming there is one) will create a binding
X1':x1', mapping this server reflexive candidate to the host
candidate X:x.  Outgoing packets sent from the host candidate will be
translated by the NAT to the server reflexive candidate.  Incoming
packets sent to the server reflexive candidate will be translated by
the NAT to the host candidate and forwarded to the agent.  We call
the host candidate associated with a given server reflexive candidate
the BASE.
Note: "Base" refers to the address an agent sends from for a
particular candidate.  Thus, as a degenerate case host candidates
also have a base, but it's the same as the host candidate.
When the agent sends the TURN Allocate request from IP address and
port X:x, the NAT (assuming there is one) will create a binding
X1':x1', mapping this server reflexive candidate to the host
candidate X:x.  Outgoing packets sent from the host candidate will be
translated by the NAT to the server reflexive candidate.  Incoming
packets sent to the server reflexive candidate will be translated by
the NAT to the host candidate and forwarded to the agent.  The host
candidate associated with a given server reflexive candidate is the
BASE.
Note: "Base" refers to the address an agent sends from for a
particular candidate.  Thus, as a degenerate case, host candidates
also have a base, but it's the same as the host candidate.
It is important to note that the STUN requests are sent to and from
the exact same IP addresses and ports that will be used for media
(e.g., RTP and RTCP).  Consequently, agents demultiplex STUN and RTP/
RTCP using contents of the packets, rather than the port on which
they are received.  Fortunately, this demultiplexing is easy to do,
especially for RTP and RTCP.
Because a STUN Binding request is used for the connectivity check,
the STUN Binding response will contain the agent's translated
transport address on the public side of any NATs between the agent
and its peer.  If this transport address is different from other
candidates the agent already learned, it represents a new candidate,
called a PEER REFLEXIVE CANDIDATE, which then gets tested by ICE just
the same as any other candidate.
It is important to note that the STUN requests are sent to and from
the exact same IP addresses and ports that will be used for media
(e.g., RTP, RTCP, or other protocols).  Consequently, agents
demultiplex STUN and media using the contents of the packets, rather
than the port on which they are received.
Because a STUN Binding request is used for the connectivity check,
the STUN Binding response will contain the agent's translated
transport address on the public side of any NATs between the agent
and its peer.  If this transport address is different from that of
other candidates the agent already learned, it represents a new
candidate, called a PEER REFLEXIVE CANDIDATE, which then gets tested
by ICE just the same as any other candidate.
Each candidate is associated with a property called its FOUNDATION.
Two candidates have the same foundation when they are "similar" -- of
the same type and obtained from the same host candidate and STUN/TURN
server using the same protocol.  Otherwise, their foundation is
different.  A candidate pair has a foundation too, which is just the
concatenation of the foundations of its two candidates.  Initially,
only the candidate pairs with unique foundations are tested.  The
other candidate pairs are marked "frozen".  When the connectivity
checks for a candidate pair succeed, the other candidate pairs with
the same foundation are unfrozen.  This avoids repeated checking of
components that are superficially more attractive but in fact are
likely to fail.
Each candidate is associated with a property called its FOUNDATION.
Two candidates have the same foundation when they are "similar" -- of
the same type and obtained from the same host candidate and STUN/TURN
server using the same protocol.  Otherwise, their foundation is
different.  A candidate pair has a foundation too, which is just the
concatenation of the foundations of its two candidates.  Initially,
only candidate pairs with unique foundations are tested and other
candidate pairs are marked "frozen".  When connectivity checks
succeed for a candidate pair, other candidate pairs with the same
foundation are unfrozen.  This avoids repeated checking of components
that are superficially more attractive but in fact are likely to
fail.
Consequently, ICE assigns one of the agents in the role of the
CONTROLLING AGENT, and the other of the CONTROLLED AGENT.  The
controlling agent gets to nominate which candidate pairs will get
used for media amongst the ones that are valid.
When nominating, the controlling agent lets the checks continue until
at least one valid candidate pair for each media stream is found.
Then, it picks amongst those that are valid, and sends a second STUN
request on its NOMINATED candidate pair, but this time with a flag
set to tell the peer that this pair has been nominated for use.  This
is shown in fig-regular-select.
Once the STUN transaction with the flag completes, both sides cancel
any future checks for that media stream.  ICE will now send media
using this pair.  The pair an ICE agent is using for media is called
the SELECTED PAIR.
Consequently, ICE assigns one of the agents in the role of the
CONTROLLING AGENT, and the other of the CONTROLLED AGENT.  The
controlling agent nominates a candidate pair from the valid candidate
pairs to be used for media.
When nominating, the controlling agent lets the checks continue until
at least one valid candidate pair for each media stream is found and
then chooses a candidate pair from the valid candidate pairs and
sends a STUN request on the selected pair with a flag set to indicate
to the controlled peer that it has nominated the selected pair.  This
is shown in fig-regular-select.
Once the STUN transaction with the flag completes, both sides cancel
any future checks for that media stream and will send and receive
media using this pair.
In order for ICE to be used in a call, both agents need to support
it.  However, certain agents will always be connected to the public
Internet and have a public IP address at which it can receive packets
from any correspondent.  To make it easier for these devices to
support ICE, ICE defines a special type of implementation called LITE
(in contrast to the normal FULL implementation).  A lite
implementation doesn't gather candidates; it includes only host
candidates for any media stream.  Lite agents do not generate
connectivity checks or run the state machines, though they need to be
able to respond to connectivity checks.  When a lite implementation
connects with a full implementation, the full agent takes the role of
the controlling agent, and the lite agent takes on the controlled
role.  When two lite implementations connect, no checks are sent.
In order for ICE to work, both agents need to support it.  However,
certain agents will always be connected to the public Internet and
have a public IP address at which it can receive packets from any
correspondent.  To make it easier for these devices to support ICE,
ICE defines a special type of implementation called LITE (in contrast
to the normal FULL implementation).  Lite agents only use host
candidates and do not generate connectivity checks or run the state
machines, though they need to be able to respond to connectivity
checks.  When a lite implementation connects with a full
implementation, the full agent takes the role of the controlling
agent, and the lite agent takes on the controlled role.  When two
lite implementations connect, no checks are sent.
An agent is the protocol implementation involved in the ICE
candidate exchange.  There are two agents involved in a typical
candidate exchange.
An initiating agent is the protocol implementation involved in the
ICE candidate exchange that initiates the ICE candidate exchange
process.
A receiving agent is the protocol implementation involved in the
ICE candidate exchange that receives and responds to the candidate
exchange process initiated by the Initiator.
An ICE session consists of all ICE-related actions starting with
the candidate gathering, followed by the interactions (candidate
exchange, connectivity checks, nominations and keep-alives)
between the ICE agents until all the candidates are released or
ICE-restart is triggered.
An ICE agent is the protocol implementation involved in the ICE
candidate exchange.  There are two agents involved in a typical
candidate exchange.
An initiating agent is an ICE agent that initiates the ICE
candidate exchange process.
A receiving agent is an ICE agent that receives and responds to
the candidate exchange process initiated by the initiating agent.
A transport address that is a potential point of contact for
receipt of media.  Candidates also have properties -- their type
(server reflexive, relayed, or host), priority,foundation, and
base.
A transport address that is a potential point of contact for
receipt of media.  Candidates also have properties -- their type
(server reflexive, relayed, or host), priority, foundation, and
base.
A candidate obtained by binding to a specific port from an IP
address on the host.  This includes IP addresses on physical
interfaces and logical ones, such as ones obtained through Virtual
Private Networks (VPNs) and Realm Specific IP (RSIP) RFC3102
(which lives at the operating system level).
A candidate whose IP address and port are a binding allocated by a
NAT for an agent when it sent a packet through the NAT to a
server.  Server reflexive candidates can be learned by STUN
servers using the Binding request, or TURN servers, which provides
both a relayed and server reflexive candidate.
A candidate whose IP address and port are a binding allocated by a
NAT for an agent when it sent a STUN Binding request through the
NAT to its peer.
A candidate obtained by sending a TURN Allocate request from a
host candidate to a TURN server.  The relayed candidate is
resident on the TURN server, and the TURN server relays packets
back towards the agent.
The transport address that an agent sends from for a particular
candidate.  For host-, server reflexive- and peer reflexive
candidates the base is the same as the host candidate.  For
relayed candidates the base is the same as the relayed candidate
(i.e., the transport address used by the TURN server to send
from).
An arbitrary string that is the same for two candidates that have
the same type, base IP address, protocol (UDP, TCP, etc.), and
STUN or TURN server.  If any of these are different, then the
foundation will be different.  Two candidate pairs with the same
foundation pairs are likely to have similar network
characteristics.  Foundations are used in the frozen algorithm.
A candidate that an agent has obtained and shared with the peer.
The default destination for a component of a media stream is the
transport address that would be used by an agent that is not ICE
aware.  A default candidate for a component is one whose transport
address matches the default destination for that component.
A pairing containing a local candidate and a remote candidate.
A STUN Binding request transaction for the purposes of verifying
connectivity.  A check is sent from the local candidate to the
remote candidate of a candidate pair.
A candidate obtained by binding to a specific port from an IP
address on the host.  This includes IP addresses on physical
interfaces and logical ones, such as ones obtained through Virtual
Private Networks (VPNs).
A candidate whose IP address and port are a binding allocated by a
NAT for an agent when it sent a packet through the NAT to a
server, such as a STUN server.
A candidate whose IP address and port are a binding allocated by a
NAT for an agent when it sent a packet through the NAT to its
peer.
A candidate obtained from a relay server, such as a TURN server.
The transport address that an agent sends from for a particular
candidate.  For host, server reflexive and peer reflexive
candidates the base is the same as the host candidate.  For
relayed candidates the base is the same as the relayed candidate
(i.e., the transport address used by the TURN server to send
from).
An arbitrary string used in the freezing algorithm to group
similar candidates.  Is the same for two candidates that have the
same type, base IP address, protocol (UDP, TCP, etc.), and STUN or
TURN server.  If any of these are different, then the foundation
will be different.
A candidate that an agent has obtained and may send to its peer.
The default destination for a component of a media stream is the
transport address that would be used by an agent that is not ICE-
aware.  A default candidate for a component is one whose transport
address matches the default destination for that component.
A pair of a local candidate and a remote candidate.
A STUN Binding request for the purposes of verifying connectivity.
A check is sent from the base of the local candidate to the remote
candidate of a candidate pair.
An ordered list of CHECK LISTs.
The ordered list of all check lists.  The order is determined by
each ICE usage.
The ICE agent that is responsible for selecting the final choice
of candidate pairs and signaling them through STUN.  In any
session, one agent is always controlling.  The other is the
controlled agent.
An ICE agent that waits for the controlling agent to select the
final choice of candidate pairs.
The process of picking a valid candidate pair for media traffic by
validating the pair with one STUN request, and then picking it by
sending a second STUN request with a flag indicating its
nomination.
The candidate pair selected by ICE for sending and receiving media
is called the selected pair, and each of its candidates is called
the selected candidate.  Before a pair has been selected, any
valid candidate pair can be used for sending and receiving media
(only one candidate pair at any given time).
The protocol that uses ICE for NAT traversal.  A usage
specification defines the protocol specific details on how the
procedures defined here are applied to that protocol.
As part of ICE processing, both the initiating and responding agents
exchange encoded candidate information as defined by the Usage
Protocol (ICE Usage).  Specifics of encoding mechanism and the
semantics of candidate information exchange is out of scope of this
specification.
However at a higher level, the below diagram captures ICE processing
sequence in the agents (initiator and responder) for exchange of
their respective candidate(s) information.
As shown, the agents involved in the candidate exchange perform (1)
candidate gathering, (2) candidate prioritization, (3) eliminating
redundant candidates, (4) (possibly) choose default candidates, and
then (5) formulate and send the candidates to the Peer ICE agent.
All but the last of these five steps differ for full and lite
implementations.
The ICE agent that nominates a candidate pair.  In any session,
one agent is always controlling.  The other is the controlled
agent.
The ICE agent that waits for the controlling agent to nominate a
candidate pair and selects the candidate nominated by the
controlling side.
The process of the controlling agent indicating to the controlled
agent which candidate pair the controlled agent should use to send
media.
The candidate pair selected by an ICE agent for sending media.
Each of its candidates is called the selected candidate.  Before a
pair has been selected, any valid candidate pair can be used for
sending and receiving media.
The protocol that uses ICE for NAT traversal.  A usage
specification defines the protocol-specific details on how the
procedures defined here are applied to that protocol.
As part of ICE processing, both the initiating and responding agents
exchange encoded candidate information as defined by the Usage
Protocol (ICE Usage).  Specifics of the encoding mechanism and the
semantics of candidate information exchange is out of scope of this
specification.
However at a higher level, the diagram below shows how the ICE agents
(initiator and responder) exchange their respective candidate(s)
information.
As shown, the agents involved in the candidate exchange perform (1)
candidate gathering, (2) candidate prioritization, (3) redundant
candidate elimination, (4) (possibly) default candidate selection,
and (5) sending of the candidates to the peer.  All but the last of
these five steps differ for full and lite implementations.
The first step is to gather host candidates.  Host candidates are
obtained by binding to ports (typically ephemeral) on a IP address
attached to an interface (physical or virtual, including VPN
interfaces) on the host.
For each UDP media stream the agent wishes to use, the agent SHOULD
obtain a candidate for each component of the media stream on each IP
address that the host has, with the exceptions listed below.  The
agent obtains each candidate by binding to a UDP port on the specific
IP address.  A host candidate (and indeed every candidate) is always
associated with a specific component for which it is a candidate.
Host candidates are obtained by binding to ports on an IP address
attached to an interface (physical or virtual, including VPN
interfaces) on the host.
For each component of each media stream the agent wishes to use, the
agent SHOULD obtain a candidate on each IP address that the host has,
with the exceptions listed below.  The agent obtains each candidate
by binding to a UDP port on the specific IP address.  A host
candidate (and indeed every candidate) is always associated with a
specific component for which it is a candidate.
When candidates are obtained, unless the agent knows for sure that
RTP/RTCP multiplexing will be used (i.e. the agent knows that the
other agent also supports, and is willing to use, RTP/RTCP
multiplexing), or unless the agent only supports RTP/RTCP
multiplexing, the agent MUST obtain a separate candidate for RTCP.
If an agent has obtained a candidate for RTCP, and ends up using RTP/
RTCP multiplexing, the agent does not need to perform connectivity
checks on the RTCP candidate.
When candidates are obtained, unless the agent knows for sure that
RTP/RTCP multiplexing will be used (i.e. the agent knows that the
other agent also supports, and is willing to use, RTP/RTCP
multiplexing), or unless the agent only supports RTP/RTCP
multiplexing, the agent MUST obtain a separate candidate for RTCP.
If an agent has obtained a candidate for RTCP, and ends up using RTP/
RTCP multiplexing, the agent does not need to perform connectivity
checks on the RTCP candidate.  Absence of a component ID 2 as such
does not imply use of RTCP/RTP multiplexing, as it could also mean
that RTCP is not used.
IPv4-mapped IPv6 addresses SHOULD NOT be included in the offered
candidates unless the application using ICE does not support IPv4
(i.e., is an IPv6-only application RFC4038).
IPv4-mapped IPv6 addresses SHOULD NOT be included in the address
candidates unless the application using ICE does not support IPv4
(i.e., is an IPv6-only application RFC4038).
Agents SHOULD obtain relayed candidates and SHOULD obtain server
reflexive candidates.  These requirements are at SHOULD strength to
allow for provider variation.  Use of STUN and TURN servers may be
unnecessary in closed networks where agents are never connected to
the public Internet or to endpoints outside of the closed network.
In such cases, a full implementation would be used for agents that
are dual-stack or multihomed, to select a host candidate.  Use of
TURN servers is expensive, and when ICE is being used, they will only
be utilized when both endpoints are behind NATs that perform address
and port dependent mapping.  Consequently, some deployments might
consider this use case to be marginal, and elect not to use TURN
servers.  If an agent does not gather server reflexive or relayed
candidates, it is RECOMMENDED that the functionality be implemented
and just disabled through configuration, so that it can be re-enabled
through configuration if conditions change in the future.
If an agent is gathering both relayed and server reflexive
candidates, it uses a TURN server.  If it is gathering just server
reflexive candidates, it uses a STUN server.
The agent next pairs each host candidate with the STUN or TURN server
with which it is configured or has discovered by some means.  If a
STUN or TURN server is configured, it is RECOMMENDED that a domain
name be configured, and the DNS procedures in RFC5389 (using SRV
records with the "stun" service) be used to discover the STUN server,
and the DNS procedures in RFC5766 (using SRV records with the "turn"
service) be used to discover the TURN server.
This specification only considers usage of a single STUN or TURN
server.  When there are multiple choices for that single STUN or TURN
server (when, for example, they are learned through DNS records and
multiple results are returned), an agent SHOULD use a single STUN or
TURN server (based on its IP address) for all candidates for a
particular session.  This improves the performance of ICE.  The
result is a set of pairs of host candidates with STUN or TURN
servers.  The agent then chooses one pair, and sends a Binding or
Allocate request to the server from that host candidate.  Binding
requests to a STUN server are not authenticated, and any ALTERNATE-
SERVER attribute in a response is ignored.  Agents MUST support the
backwards compatibility mode for the Binding request defined in
RFC5389.  Allocate requests SHOULD be authenticated using a long-term
credential obtained by the client through some other means.
An agent SHOULD gather server reflexive and relayed candidates.
These requirements are at SHOULD strength to allow for provider
variation.  Use of STUN and TURN servers may be unnecessary in
certain networks and use of TURN servers may be expensive, so some
deployments may elect not to use them.  If an agent does not gather
server reflexive or relayed candidates, it is RECOMMENDED that the
functionality be implemented and just disabled through configuration,
so that it can be re-enabled through configuration if conditions
change in the future.
The agent pairs each host candidate with the STUN or TURN servers
with which it is configured or has discovered by some means.  It is
RECOMMENDED that a domain name be configured, and the DNS procedures
in RFC5389 (using SRV records with the "stun" service) be used to
discover the STUN server, and the DNS procedures in RFC5766 (using
SRV records with the "turn" service) be used to discover the TURN
server.
If an IPv6-only agent is in a network that utilizes NAT64 RFC6146 and
DNS64 RFC6147 technologies, it may gather also IPv4 server reflexive
and/or relayed candidates from IPv4-only STUN or TURN servers.
IPv6-only agents SHOULD also utilize IPv6 prefix discovery RFC7050 to
discover the IPv6 prefix used by NAT64 (if any) and generate server
reflexive candidates for each IPv6-only interface accordingly.  The
NAT64 server reflexive candidates are prioritized like IPv4 server
reflexive candidates.
If an IPv6-only agent is in a network that utilizes NAT64 RFC6146 and
DNS64 RFC6147 technologies, it may also gather IPv4 server reflexive
and/or relayed candidates from IPv4-only STUN or TURN servers.
IPv6-only agents SHOULD also utilize IPv6 prefix discovery RFC7050 to
discover the IPv6 prefix used by NAT64 (if any) and generate server
reflexive candidates for each IPv6-only interface accordingly.  The
NAT64 server reflexive candidates are prioritized like IPv4 server
reflexive candidates.
They have the same type (host, relayed, server reflexive, or peer
reflexive).
Their bases have the same IP address (the ports can be different).
For reflexive and relayed candidates, the STUN or TURN servers
used to obtain them have the same IP address.
They were obtained using the same transport protocol (TCP, UDP).
An agent SHOULD compute this priority using the formula in sec-rec-
form and choose its parameters using the guidelines in sec-
guidelines.  If an agent elects to use a different formula, ICE will
take longer to converge since both agents will not be coordinated in
their checks.
An agent SHOULD compute this priority using the formula in sec-rec-
form and choose its parameters using the guidelines in sec-
guidelines.  If an agent elects to use a different formula, ICE may
take longer to converge since both agents will not be coordinated in
their checks.
The type preference MUST be an integer from 0 to 126 inclusive, and
represents the preference for the type of the candidate (where the
types are local, server reflexive, peer reflexive, and relayed).  A
126 is the highest preference, and a 0 is the lowest.  Setting the
value to a 0 means that candidates of this type will only be used as
a last resort.  The type preference MUST be identical for all
candidates of the same type and MUST be different for candidates of
different types.  The type preference for peer reflexive candidates
MUST be higher than that of server reflexive candidates.  Note that
candidates gathered based on the procedures of sec-gathering will
never be peer reflexive candidates; candidates of these type are
learned from the connectivity checks performed by ICE.
The local preference MUST be an integer from 0 to 65535 inclusive.
It represents a preference for the particular IP address from which
the candidate was obtained. 65535 represents the highest preference,
and a zero, the lowest.  When there is only a single IP address, this
value SHOULD be set to 65535.  More generally, if there are multiple
candidates for a particular component for a particular media stream
that have the same type, the local preference MUST be unique for each
one.  In this specification, this only happens for multihomed hosts
or if an agent is using multiple TURN servers.  If a host is
multihomed because it is dual-stack, the local preference should be
set according to the current best practice described in I-D.ietf-ice-
dualstack-fairness.
The component ID is the component ID for the candidate, and MUST be
between 1 and 256 inclusive.
One criterion for selection of the type and local preference values
is the use of a media intermediary, such as a TURN server, a tunnel
service such as VPN server, or NAT.  With a media intermediary, if
media is sent to that candidate, it will first transit the media
intermediary before being received.  Relayed candidates are one type
of candidate that involves a media intermediary.  Another are host
candidates obtained from a VPN interface.  When media is transited
through a media intermediary, it can have a positive or negative
effect on the latency between transmission and reception.  It may or
may not increase the packet losses, because of the additional router
hops that may be taken.  It may increase the cost of providing
service, since media will be routed in and right back out of a media
intermediary run by a provider.  If these concerns are important, the
type preference for relayed candidates must be carefully chosen.  The
RECOMMENDED values are 126 for host candidates, 100 for server
reflexive candidates, 110 for peer reflexive candidates, and 0 for
relayed candidates.
Furthermore, if an agent is multihomed and has multiple IP addresses,
the recommendation in I-D.ietf-ice-dualstack-fairness should be
followed.  If multiple TURN servers are used, local priorities for
the candidates obtained from the TURN servers are chosen in a similar
fashion as for multihomed local candidates: the local preference
value is used to indicate a preference among different servers but
the preference MUST be unique for each one.
Another criterion for selection of preferences is IP address family.
ICE works with both IPv4 and IPv6.  It provides a transition
mechanism that allows dual-stack hosts to prefer connectivity over
IPv6, but to fall back to IPv4 in case the v6 networks are
disconnected.  Implementation should follow the guidelines from I-
D.ietf-ice-dualstack-fairness to avoid excessively delays in the
connectivity check phase if broken paths exist.
Another criterion for selecting preferences is topological awareness.
This is most useful for candidates that make use of intermediaries.
In those cases, if an agent has preconfigured or dynamically
discovered knowledge of the topological proximity of the
intermediaries to itself, it can use that to assign higher local
preferences to candidates obtained from closer intermediaries.
Another criterion for selecting preferences might be security or
privacy.  If a user is a telecommuter, and therefore connected to a
corporate network and a local home network, the user may prefer their
voice traffic to be routed over the VPN or similar tunnel in order to
keep it on the corporate network when communicating within the
enterprise, but use the local network when communicating with users
outside of the enterprise.  In such a case, a VPN address would have
a higher local preference than any other address.
Next, the agent eliminates redundant candidates.  A candidate is
redundant if its transport address equals another candidate, and its
base equals the base of that other candidate.  Note that two
candidates can have the same transport address yet have different
bases, and these would not be considered redundant.  Frequently, a
server reflexive candidate and a host candidate will be redundant
when the agent is not behind a NAT.  The agent SHOULD eliminate the
redundant candidate with the lower priority.
This process is common across the initiating and responding agents.
The type preference MUST be an integer from 0 (lowest preference) to
126 (highest preference) inclusive and MUST be identical for all
candidates of the same type and MUST be different for candidates of
different types.  The type preference for peer reflexive candidates
MUST be higher than that of server reflexive candidates.  Setting the
value to 0 means that candidates of this type will only be used as a
last resort.  Note that candidates gathered based on the procedures
of sec-gathering will never be peer reflexive candidates; candidates
of these type are learned from the connectivity checks performed by
ICE.
The local preference MUST be an integer from 0 (lowest preference) to
65535 (highest preference) inclusive.  When there is only a single IP
address, this value SHOULD be set to 65535.  If there are multiple
candidates for a particular component for a particular media stream
that have the same type, the local preference MUST be unique for each
one.  If an agent is dual-stack, the local preference should be set
according to the current best practice described in I-D.ietf-ice-
dualstack-fairness.
The component ID MUST be an integer between 1 and 256 inclusive.
The RECOMMENDED values for type preferences are 126 for host
candidates, 110 for peer reflexive candidates, 100 for server
reflexive candidates, and 0 for relayed candidates.
If an agent is multihomed and has multiple IP addresses, the
recommendations in I-D.ietf-ice-dualstack-fairness SHOULD be
followed.  If multiple TURN servers are used, local priorities for
the candidates obtained from the TURN servers are chosen in a similar
fashion as for multihomed local candidates: the local preference
value is used to indicate a preference among different servers but
the preference MUST be unique for each one.
When choosing type preferences, agents may take into account factors
such as latency, packet loss, cost, network topology, security,
privacy, and others.
Next, agents (initiating and responding) eliminate redundant
candidates.  Two candidates can have the same transport address yet
have different bases, and these would not be considered redundant.
Frequently, a server reflexive candidate and a host candidate will be
redundant when the agent is not behind a NAT.  A candidate is
redundant if and only if its transport address and base equal those
of another candidate.  The agent SHOULD eliminate the redundant
candidate with the lower priority.
Regardless of the agent being an Initiator or Responder Agent, the
following parameters and their data types needs to be conveyed as
part of the candidate exchange process.  The specifics of syntax for
encoding the candidate information is out of scope of this
specification.
An indicator of the transport protocol for this candidate.
This need not be present if the using protocol will only ever
run over a single transport protocol.  If it runs over more
than one, or if others are anticipated to be used in the
future, this should be present.
This would be present only if the using protocol were utilizing
the concept of components.  If it is, it would be a positive
integer that indicates the component ID for which this is a
candidate.
An encoding of the 32-bit priority value.
The candidate type, as defined in ICE.
The related IP address and port for this candidate, as defined
by ICE.  These MAY be omitted or set to invalid values if the
agent does not want to reveal them, e.g., for privacy reasons.
If ICE lite is used by the using protocol, it needs to convey a
boolean parameter which indicates whether the implementation is
lite or not.
If an agent wants to use other than the default pacing values for
the connectivity checks, it MUST indicate this in the ICE
exchange.
The using protocol has to convey a username fragment and password.
The username fragment MUST contain at least 24 bits of randomness,
and the password MUST contain at least 128 bits of randomness.
In addition to the per-candidate extensions above, the using
protocol should allow for new media-stream or session-level
attributes (ice-options).
Agents (initiating and responding) need the following information
about candidates to be exchanged.  How this information is encoded or
exchanged is out of scope of this specification.  The using protocol
should provide a means for exchanging new, additional information in
the future, including per-candidate information.
The transport protocol of the candidate.  This MAY be omitted
if the using protocol will only ever run over a single
transport protocol.  If it runs over more than one, or if
others are anticipated to be used in the future, this should be
present.
The component ID of the candidate.  This MAY be omitted if the
using protocol does not use the concept of components.
The 32-bit priority of the candidate.
The type of the candidate.
The related IP address and port of the candidate.  These MAY be
omitted or set to invalid values if the agent does not want to
reveal them, e.g., for privacy reasons.
Whether the agent is a lite agent or full agent.
The pacing value for connectivity checks that the agent wishes to
use.  If the agent wishes to use a value other than default, it
MUST include this in the exchange.
Values used to perform connectivity checks.  The username fragment
MUST contain at least 24 bits of randomness, and the password MUST
contain at least 128 bits of randomness.
New media-stream or session-level attributes (ice-options).
STUN connectivity checks between agents are authenticated using the
short-term credential mechanism defined for STUN [RFC5389].  This
mechanism relies on a username and password that are exchanged
through protocol machinery between the client and server.  The
username part of this credential is formed by concatenating a
username fragment from each agent, separated by a colon.  Each agent
also provides a password, used to compute the message integrity for
requests it receives.  The username fragment and password are
exchanged between the peers.  In addition to providing security, the
username provides disambiguation and correlation of checks to media
streams.  See Appendix B.4 for motivation.
If the initiating agent is a lite implementation, it MUST indicate
this when sending its candidates .
ICE provides for extensibility by allowing an agent to include a
series of tokens that identify ICE extensions as part of the
candidate exchange process.
Once an agent has sent its candidate information, that agent MUST be
prepared to receive both STUN and media packets on each candidate.
As discussed in sec-send-media, media packets can be sent to a
candidate prior to its appearance as the default destination for
media.
Once an agent has sent its candidate information, it MUST be prepared
to receive both STUN and media packets on each candidate.  As
discussed in sec-send-media, media packets can be sent to a candidate
prior to its appearance as the default destination for media.
There is one CHECK LIST per in-use media stream resulting from the
candidate exchange.  To form the CHECK LIST for a media stream, the
agent forms candidate pairs, computes a candidate pair priority,
orders the pairs by priority, prunes them, removes lower-priority
candidates and sets their states.  These steps are described in this
section.  If a CHECK LIST is updated (e.g, due to detection of peer
reflexive candidates), the agent will re-perform the steps for the
updated CHECK LIST.
In this state, ICE checks are still in progress for this media
stream.  Check lists are initially set to the Running state.
In this state, ICE checks have produced selected pairs for each
component of the media stream.
In this state, the ICE checks have not completed successfully for
this media stream.
A CHECK LIST with at least one pair that is Waiting is called an
active CHECK LIST, and a CHECK LIST with all pairs Frozen is called a
frozen CHECK LIST.
First, the agent takes each of its candidates for a media stream
(called LOCAL CANDIDATES) and pairs them with the candidates it
received from its peer (called REMOTE CANDIDATES) for that media
stream.  A local candidate is paired with a remote candidate if and
only if the two candidates have the same component ID and have the
same IP address version.  It is possible that some of the local
candidates won't get paired with remote candidates, and some of the
remote candidates won't get paired with local candidates.  This can
happen if one agent doesn't include candidates for the all of the
components for a media stream.  If this happens, the number of
components for that media stream is effectively reduced, and
considered to be equal to the minimum across both agents of the
maximum component ID provided by each agent across all components for
the media stream.
There is one check list for each media stream.  To form a check list,
an agent (initiating and responding) forms candidate pairs, computes
pair priorities, orders pairs by priority, prunes pairs, removes
lower-priority pairs, and sets check list states.  If candidates are
added to a check list (e.g, due to detection of peer reflexive
candidates), the agent will re-perform these steps for the updated
check list.
The check list is neither Completed yet nor Failed yet.  Check
lists are initially set to the Running state.
The check list has a selected candidate pair for each component of
the media stream.
The check list does not have a valid candidate pair for each
component of the media stream and all of the candidate pairs in
the check list are in either the Failed or Succeeded state.  In
other words, at least one component of the check list has
candidate pairs that are all in the Failed state, which means the
component has failed, which means the check list has failed.
Additionally, a check list with at least one pair in the Waiting
state is called "active", while a check list with all pairs in the
frozen state is called "Frozen".
The agent pairs each local candidate with each remote candidate for
the same component of the same media stream with the same IP address
family.  It is possible that some of the local candidates won't get
paired with remote candidates, and some of the remote candidates
won't get paired with local candidates.  This can happen if one agent
doesn't include candidates for the all of the components for a media
stream.  If this happens, the number of components for that media
stream is effectively educed, and considered to be equal to the
minimum across both agents of the maximum component ID provided by
each agent across all components for the media stream.
In order to aid understanding, fig-check-model shows the
relationships between several key concepts -- transport addresses,
candidates, candidate pairs, and CHECK LISTs, in addition to
indicating the main properties of candidates and candidate pairs.
Where G>D?1:0 is an expression whose value is 1 if G is greater than
D, and 0 otherwise.  Once the priority is assigned, the agent sorts
the candidate pairs in decreasing order of priority.  If two pairs
have identical priority, the ordering amongst them is arbitrary.
fig-check-model shows the properties of and relationships between
transport addresses, candidates, candidate pairs, and check lists.
The agent computes a priority for each candidate pair.  Let G be the
priority for the candidate provided by the controlling agent.  Let D
be the priority for the candidate provided by the controlled agent.
The priority for a pair is computed as follows, where G>D?1:0 is an
expression whose value is 1 if G is greater than D, and 0 otherwise.
The agent sorts each check list in decreasing order of candidate pair
priority.  If two pairs have identical priority, the ordering amongst
them is arbitrary.
This sorted list of candidate pairs is used to determine a sequence
of connectivity checks that will be performed.  Each check involves
sending a request from a local candidate to a remote candidate.
Since an agent cannot send requests directly from a reflexive
candidate (server reflexive or peer reflexive), but only from its
base, the agent next goes through the sorted list of candidate pairs.
For each pair where the local candidate is reflexive, the candidate
MUST be replaced by its base.  Once this has been done, the agent
MUST prune the list.  This is done by removing a pair if its local
and remote candidates are identical to the local and remote
candidates of a pair higher up on the priority list.  The result is a
sequence of ordered candidate pairs, called the CHECK LIST for that
media stream.
This sorted list of candidate pairs is used to determine a sequence
of connectivity checks that will be performed.  Each check involves
sending a request from a local candidate to a remote candidate.
Since an agent cannot send requests directly from a reflexive
candidate (server reflexive or peer reflexive), but only from its
base, the agent next goes through the sorted list of candidate pairs.
For each pair where the local candidate is reflexive, the candidate
MUST be replaced by its base.
The agent prunes each check list.  This is done by removing a
candidate pair if it is redundant with a higher priority candidate
pair in the same check list.  Two candidate pairs are redundant if
their local candidates have the same base and their remote candidates
are identical.  The result is a sequence of ordered candidate pairs,
called the check list for that media stream.
A check has not been sent for this pair, but can be sent as soon
as the pair is chosen based on the criteria for selecting for
which candidate pair a check is to be sent.
A check has not been sent for this pair, but the pair is not
Frozen.
As ICE runs, the pairs will move between states as shown in fig-
state-fsm.
The agent sets all of the candidate pairs in the CHECK LIST SET to
the Frozen state.
For each foundation, the candidate pair with the lowest
component ID (in case of multiple such pairs, the pair with the
highest priority) is placed in the Waiting state, unless a
candidate pair associated with the same foundation has already
been put in the Waiting state in one of the other examined
CHECK LISTs.  This will ensure that, within the CHECK LIST SET,
only one pair with a given foundation is initially placed in
the Waiting state, while other pairs with the same foundation
remain in the Frozen state.
NOTE: The procedures above are different from RFC5245, where only
candidate pairs in the first CHECK LIST of the CHECK LIST SET were
initially placed in the Waiting state.
The table in fig-state-initial illustrates how the initial states of
the candidate pairs in the CHECK LIST SET.
ICE processing across the CHECK LIST SET has a state associated with
it.  This state is set to Running while ICE processing is under way.
The state is set to Completed when ICE processing is complete and set
to Failed if it failed without success.
The generation of ordinary and triggered connectivity checks is
govererned by timer Ta.  As soon as the initial states for the
candidate pairs in the CHECK LIST SET have been set, a check is
performed for a candidate pair within the first CHECK LIST in the
Running state, following the procedures in sec-connectivity_check.
After that, whenever Ta fires the next CHECK LIST in the Running
state in the CHECK LIST SET is selected, and a check is performed for
a candidate within that CHECK LIST.  After the last CHECK LIST in the
Running state in the CHECK LIST SET has been processed, the first
CHECK LIST is selected again.  Etc.
NOTE: When timer Ta fires, and the agent processes a CHECK LIST, if
no check is performed for a pair in the CHECK LIST (based on the
rules below), the agent can immediately select the next CHECK LIST in
the Running state, without waiting for timer Ta to expire again.
If there is no candidate pair in the Waiting state, and if there
are one or more pairs in the Frozen state, for each pair in the
Frozen state the the agent checks the foundation associated with
the pair.  For a given foundation, if there is no pair (in any
CHECK LIST in the CHECK LIST SET) in the Waiting or In-Progress
state, the agent performs a connectivity check on the pair and
puts the pair state to In-Prograss.  If, for the same foundation,
there are one or more pairs in the Waiting or In-Progress state,
(in any CHECK LIST in the CHECK LIST SET) the agent does not
perform a connectivity check on the pair.
Once the agent has selected a candidate pair, for which a
connectivity check is to be performed, the agent performs the check
by sending a STUN request from the base associated with the local
candiditate of the pair to the remote candidate of the pair, as
described in sec-send-check.
Based on local policy, an agent MAY choose to terminate perfoming the
connectivity checks for one or more checks lists in the CHECK LIST
SET at any time.  However, only the controlling agent is allowed to
conclude ICE (sec-conclude).
Pairs move between states as shown in fig-state-fsm.
The agent initially places all candidate pairs in the Frozen
state.
For each foundation, the agent sets the state of exactly one
candidate pair to the Waiting state (unfreezing it).  The
candidate pair to unfreeze is choosen by finding the first
candidate pair (ordered by lowest component ID and then highest
priority if component IDs are equal) in the first check list
(ordered by the check list set) that has that foundation.
NOTE: The procedures above are different from RFC5245, where only
candidate pairs in the first check list of were initially placed in
the Waiting state.  Now it applies to candidate pairs in the the
first check list which have that foundation, even if the first check
list to have that foundation is not the first check list in the check
list set.
The table in fig-state-initial illustrates an example.
The ICE agent has a state determined by the state of the check lists.
The state is Completed if all check lists are Completed, Failed if
all check lists are Failed, and Running otherwise.
The generation of ordinary and triggered connectivity checks is
governed by timer Ta.  As soon as the initial states for the
candidate pairs in the check list set have been set, a check is
performed for a candidate pair within the first check list in the
Running state, following the procedures in sec-connectivity_check.
After that, whenever Ta fires the next check list in the Running
state in the check list set is selected, and a check is performed for
a candidate within that check list.  After the last check list in the
Running state in the check list set has been processed, the first
check list is selected again.  Etc.
If the triggered check queue associated with the check list
contains one or more candidate pairs, the agent removes the top
pair from the queue, performs a connectivity check on that pair,
puts the candidate pair state to In-Progress, and aborts the
subsequent steps.
If there is no candidate pair in the Waiting state, and if there
are one or more pairs in the Frozen state, for each pair in the
Frozen state the agent checks the foundation associated with the
pair.  For a given foundation, if there is no pair (in any check
list in the check list set) in the Waiting or In-Progress state,
the agent puts the candidate pair state to Waiting and continues
with the next step.
If this step is reached, no check could be performed for the
selected check list.  So, without waiting for timer Ta to expire
again, select the next check list in the Running state and return
to step #1.  If this happens for every single check list in the
Running state, meaning there are no remaining candidate pairs to
perform connectivity checks for, abort these steps.
Once the agent has selected a candidate pair, for which a
connectivity check is to be performed, the agent performs the check
by sending a STUN request from the base associated with the local
candidate of the pair to the remote candidate of the pair, as
described in sec-send-check.
Based on local policy, an agent MAY choose to terminate performing
the connectivity checks for one or more checks lists in the check
list set at any time.  However, only the controlling agent is allowed
to conclude ICE (sec-conclude).
An ICE agent MUST be compliant to to RFC5389.  A full implementation
acts both as a STUN client and a STUN server, while a lite
implementation only acts as a STUN server (as it does not generate
connectivity checks).
The priority attribute MUST be included in a Binding request and be
set to the value computed by the algorithm in sec-prioritizing for
the local candidate, but with the candidate type preference of peer
reflexive candidates.
The controlling ICE agent MUST include the USE-CANDIDATE attribute in
order to nominate a candidate pair sec-choose-favor.  The controlled
ICE agent MUST NOT include the USE-CANDIDATE attribute in a Binding
request.
Once the ICE agent has switched its role, the agent MUST add the
candidate pair whose check generated the 487 error response to the
TRIGGERED CHECK QUEUE associated with the CHECK LIST to which the
pair belongs, and set the candidate pair state to Waiting.  When the
triggered connectivity check is later performed, the ICE-CONTROLLING/
ICE-CONTROLLED attribute of the Binding request will indicate the
agent's new role.  The ICE agent MUST NOT change the tie-breaker
value.
Once the ICE agent has switched its role, the agent MUST add the
candidate pair whose check generated the 487 error response to the
triggered check queue associated with the check list to which the
pair belongs, and set the candidate pair state to Waiting.  When the
triggered connectivity check is later performed, the ICE-CONTROLLING/
ICE-CONTROLLED attribute of the Binding request will indicate the
agent's new role.  The ICE agent MAY change the tie-breaker value.
If the Binding request generates a STUN error response that is
unrecoverable RFC5389) or times out, the ICE agent SHOULD set the
candidate pair state to Failed.
If the Binding request generates a STUN error response that is
unrecoverable RFC5389 or times out, the ICE agent SHOULD set the
candidate pair state to Failed.
The ICE agent does not need to pair the peer reflexive candidate with
remote candidates, as a valid candiate pair will be created due to
the procedures in sec-valid-cons.  If an ICE agent wishes to pair the
peer reflexive candidate with other remote candidates besides the one
in the valid pair that will be generated, the agent MAY provide
updated candidate information to the peer that includes the peer
reflexive candidate.  This will cause the peer reflexive candidate to
be paired with all other remote candidates.
The base is local candidate of the candidate pair from which the
Binding request was sent.
The foundation is described in sec-computing-foundations.
The ICE agent does not need to pair the peer reflexive candidate with
remote candidates, as a valid candidate pair will be created due to
the procedures in sec-valid-cons.  If an agent wishes to pair the
peer reflexive candidate with remote candidates other than the one in
the valid pair that will be generated, the agent MAY provide updated
candidate information to the peer that includes the peer reflexive
candidate.  This will cause the peer reflexive candidate to be paired
with all other remote candidates.
The agent constructs a candidate pair whose local candidate equals
the mapped address of the response, and whose remote candidate equals
the destination address to which the request was sent.  This is
called a valid pair.
The success of the connectivity check might also cause the state of
other candidate pairs to change.  The ICE agent MUST set the states
for all other Frozen candidate pairs (in each CHECK LIST in the CHECK
LIST SET) with the same foundation to Waiting.
If the ICE agent was a controlling agent, and the agent had included
a USE-CANDIDATE attribute in the Binding request, the valid pair
generated from that check has its nominated flag value set to true.
This flag indicates that this valid pair SHOULD be used for media,
unless the sending agent detects that the candidate pair does not
work.  This concludes the ICE processing for this media stream or all
media streams; see sec-conclude.
An ICE agent MUST NOT select a candidate pair until it has sent a
Binding request, and received the corresponding Binding response,
associated with the candidate pair.
An agent MUST be prepared to receive a Binding request on the base of
each candidate it included in its most recent candidate exchange.
This requirement holds even if the peer is a lite implementation.
The agent sets the states of both the candidate pair that generated
the check and the constructed valid pair (which may be different) to
Succeeded.
The agent MUST set the states for all other Frozen candidate pairs in
all check lists with the same foundation to Waiting.
If the request had included a USE-CANDIDATE attribute in the Binding
request, the controlling agent sets the Nominated Flag of the valid
pair to true.  This concludes the ICE processing for this media
stream; see sec-conclude.
If the response was the result of a triggered check that was sent in
response to a request that itself had the USE-CANDIDATE attribute,
the controlled agent may now set the Nominated Flag for the pair
learned from the original request.  This case is described in sec-up-
fav.
An ICE agent MUST NOT select a candidate pair until it has sent a
Binding request and received the corresponding Binding response
associated with the candidate pair.
An agent (lite or full) MUST be prepared to receive Binding requests
on the base of each candidate it included in its most recent
candidate exchange.
If the agent is using Diffserv Codepoint markings RFC2475 in its
media packets, it SHOULD apply those same markings to its responses
to Binding requests.  The same would apply to any layer 2 markings
the endpoint might be applying to media packets.
This subsection defines the additional server procedures applicable
to full implementations.
Normally, the rules for selection of a role in sec-role will result
in each agent selecting a different role -- one controlling and one
controlled.  However, in unusual call flows, typically utilizing
third party call control, it is possible for both agents to select
the same role.  This section describes procedures for checking for
this case and repairing it.  These procedures apply only to usages of
ICE that require conflict resolution.  The usage document MUST
specify whether this mechanism is needed.
If the agent is using Diffserv Codepoint markings RFC2475 in its
media packets, it SHOULD apply the same markings to Binding
responses.  The same would apply to any layer 2 markings the endpoint
might be applying to media packets.
This subsection defines the additional server procedures applicable
to full implementations, when the full implementation accepts the
Binding request.
In certain usages of ICE (such as third party call control), both
agents may end up choosing the same role, resulting in a role
conflict.  The section describes a mechanism for detecting and
repairing role conflicts.  The usage document MUST specify whether
this mechanism is needed.
A change in roles will require an agent to recompute pair priorities
(sec-comp-pair-prio), since those priorities are a function of
controlling and controlled roles.  The change in role will also
impact whether the agent is responsible for selecting nominated pairs
and initiating exchange with updated candidate information upon
conclusion of ICE.
The remaining sections in sec-add-server-full are followed if the
server generated a successful response to the Binding request, even
if the agent changed roles.
For requests being received on a relayed candidate, the source
transport address used for STUN processing (namely, generation of the
XOR-MAPPED-ADDRESS attribute) is the transport address as seen by the
TURN server.  That source transport address will be present in the
XOR-PEER-ADDRESS attribute of a Data Indication message, if the
Binding request was delivered through a Data Indication.  If the
Binding request was delivered through a ChannelData message, the
source transport address is the one that was bound to the channel.
A change in roles will require an agent to recompute pair priorities
(sec-comp-pair-prio), since those priorities are a function of role.
The change in role will also impact whether the agent is responsible
for selecting nominated pairs and initiating exchange with updated
candidate information upon conclusion of ICE.
The remaining sections in sec-add-server-full are followed if the
agent generated a successful response to the Binding request, even if
the agent changed roles.
For requests received on a relayed candidate, the source transport
address used for STUN processing (namely, generation of the XOR-
MAPPED-ADDRESS attribute) is the transport address as seen by the
TURN server.  That source transport address will be present in the
XOR-PEER-ADDRESS attribute of a Data Indication message, if the
Binding request was delivered through a Data Indication.  If the
Binding request was delivered through a ChannelData message, the
source transport address is the one that was bound to the channel.
The priority of the candidate is set to the PRIORITY attribute
from the request.
The type of the candidate is set to peer reflexive.
The foundation of the candidate is set to an arbitrary value,
different from the foundation for all other remote candidates.  If
any subsequent candidate exchanges contain this peer reflexive
candidate, it will signal the actual foundation for the candidate.
The component ID of this candidate is set to the component ID for
the local candidate to which the request was sent.
The foundation is an arbitrary value, different from the
foundations of all other remote candidates.  If any subsequent
candidate exchanges contain this peer reflexive candidate, it will
signal the actual foundation for the candidate.
The component ID is the component ID of the local candidate to
which the request was sent.
Once the controlling agent has selected a valid pair for nomination,
it repeats the connectivity check that produced this valid pair (by
enqueueing the pair that generated the check into the TRIGGERED CHECK
QUEUE), this time with the USE-CANDIDATE attribute.  The connectivity
check should succeed (since the previous did), causing the nominated
flag value of that and only that pair to be set to true.
Eventually, there will be only a single nominated pair in the VALID
LIST for each component.  Once the state of the CHECK LIST is set to
Completed, that exact pair is selected by ICE for sending and
receiving media for that component.
Once the controlling agent has selected a valid pair for nomination,
it repeats the connectivity check that produced this valid pair (by
enqueueing the pair that generated the check into the triggered check
queue), this time with the USE-CANDIDATE attribute.  The connectivity
check should succeed (since the previous did), causing the nominated
flag value of that and only that pair to be set to true.  However, if
the connectivity check fails sec-client-failure, the controlling
agent MUST remove the candidate pair from the VALID LIST, set the
candidate pair state to Failed and set the CHECK LIST state to
Failed.
Eventually, if the nominations succeed, there will be only a single
nominated pair in the VALID LIST for each component.  Once the state
of the CHECK LIST is set to Completed, that exact pair is selected by
ICE for sending and receiving media for that component.
The controlled agent SHOULD select the candidate pair nominated by
the controlling agent if the controlled agent is receiving Binding
responses associated with that candidate pair.  Before the agent has
received Binding responses associated with the candidate pair, the
agent can send media on any candidate for which it has received
Binding responses.
If more than one candidate pair is nominated by the controlling
agent, the controlled agent SHOULD select the candidate pair with the
highest priority.
If the controlled agent accepts the nomination request from the
controlling agent, the controlled agent MUST select the nominated
candidate pair, if the controlled agent is receiving Binding
responses associated with that candidate pair.  Before the agent has
received Binding responses associated with the candidate pair, the
agent can send media on any candidate for which it has received
Binding responses.
If the controlled agent does not accept the nomination request from
the controlling agent, the controlled agent MUST reject the
nomination request with an appropriate error code response (e.g.,
400) RFC5389, and MUST set the CHECK LIST state to Failed.
If more than one candidate pair is nominated by the controlling
agent, and if the controlled agent accepts multiple nominations
requests, the controlled agent MUST select the candidate pair with
the highest priority.
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 sec-
freeing.
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.
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 as part of subsequent candidate exchange process.
Once the candidate 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).
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.
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 6724 RFC6724 to select a single
pair.
The agent adds the selected pair for each component to the
valid list.  As described in sec-send-media, 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 updated
candidate list which will include the remote-candidates
attribute.
The agent MUST NOT update the state of ICE processing until
after the candidate exchange completes.  Then 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.
When ICE concludes, a lite agent can free host candidates that were
not used by ICE, as described in sec-freeing.
If the peer is a full agent, the lite agent selects a candidate pair
when the full agent nominates it.  When the lite agent has selected a
candidate pair for all components of all media streams, the ICE
session is Completed.
If the peer is a lite agent, the agent pairs local candidates with
remote candidates that are for the same media stream and have the
same component, transport protocol, and IP address family.  For each
component of each media stream, if there is only one candidate pair,
that pair is added to the valid list.  If there is more than one
pair, it is RECOMMENDED that an agent follow the procedures of RFC
6724 RFC6724 to select a pair and add it to the valid list.
If all of the components for all media streams had one pair, the
state of ICE processing is Completed.  Otherwise, the controlling
agent MUST send an updated candidate list to reconcile different
agents selecting different candidate pairs.  ICE processing is
complete after and only after the updated canddiate exchange is
complete.
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.
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.
The candidate(s) 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 candidate information that, had ICE not
been in use, would result in a new value for the destination of a
media component.
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.
To restart ICE, an agent MUST change both the password and the user
name fragment for the media stream when exchanging the candidates.
The new candidate set MAY include some, none, or all of the previous
candidates for that stream and MAY include a totally new set of
candidates.
This section defines a new ICE option, 'ice2'.  The ICE option
indicates that the ICE agent that includes it (in an ice-options
attribute) is compliant to this specification.  For example, the ICE
agent will not use the aggressive nomination procedure defined in
RFC5245.
An ICE agent compliant to this specification MUST inform the peer
about the compliance using the 'ice2' ICE option.
Once a checklist has reached the Completed state, the agent SHOULD
wait an additional three seconds, and then it can cease responding to
checks or generating triggered checks on all local candidates other
than the ones in the selected candidate pairs (one for each
component).  Once all ICE sessions have ceased using a given local
candidate (a candidate may be used by multiple ICE sessions, e.g. in
forking scenarios), the agent can free that candidate.  The three-
second delay handles cases when aggressive nomination is used, and
the selected pairs can quickly change after ICE has completed.
Freeing of server reflexive candidates is never explicit; it happens
by lack of a keepalive.
A lite implementation can free candidates not selected by ICE as soon
as ICE processing has reached the Completed state for all ICE
sessions using those candidates.
An agent MAY restart ICE for existing media streams.  An ICE restart
causes all previous state of the media streams, excluding the roles
of the agents to be flushed.  The only difference between an ICE
restart and a brand new media session is that during the restart,
media can continue to be sent using existing media sessions, and that
a new media session always requires the roles to be determined.
Change the destinations of media streams.
Change from a lite implementation to a full implementation.
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 media stream(s) being restarted.  The new
candidate set MAY include some, none, or all of the previous
candidates.
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 are fulfilled.
This section defines a new ICE option, 'ice2'.  The ICE option
indicates that the ICE agent that includes it in a candidate exchange
is compliant to this specification.  For example, the ICE agent will
not use the aggressive nomination procedure defined in RFC5245.
An ICE agent compliant to this specification MUST inform the peer
about the compliance using the 'ice2' option.
For each candidate pair that an agent is using to send media, if no
packet has been sent on that pair in the last Tr seconds, an agent
MUST send a keepalive on that pair.  Agents SHOULD use a Tr value of
15 seconds.  Agents MUST NOT use a Tr value smaller than 15 seconds.
An agent MUST begin sending keepalives once a candidate pair is
selected or a candidate pair is used to send media, whichever happens
first.  An agent MUST stop sending keepalives once the session
terminates or the media stream is removed.  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.
Procedures for sending media differ for full and lite
implementations.
Agents always send media using a candidate pair, using candidate
pairs in the VALID LIST.  Once a candidate pair has been selected
only that candidate pair (referred to as selected pair) is used for
sending media.  An agent will send media to the remote candidate
(i.e., 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 media.  In case of a relayed
candidate, media is sent from the agent and forwarded through the
base (located in the TURN server), using the procedures defined in
RFC5766.
An agent MAY send media on any valid candidate pair before a
candidate pair is selected.
An agent MUST send media on the selected candidate pair after it is
selected.
An agent sends media from the base of the local candidate to the
remote candidate.  In the case of a local relayed candidate, media is
forwarded through the base (located in the TURN server), using the
procedures defined in RFC5766.
Two agents, L and R, are using ICE.  Both are full-mode ICE
implementations and use aggressive nomination when they are
controlling.  Both agents have a single IPv4 address.  For agent L,
it is 10.0.1.1 in private address space RFC1918, and for agent R,
192.0.2.1 on the public Internet.  Both are configured with the same
STUN server (shown in this example for simplicity, although in
practice the agents do not need to use the same STUN server), which
is listening for STUN Binding requests at an IP address of 192.0.2.2
and port 3478.  TURN servers are not used in this example.  Agent L
is behind a NAT, and agent R is on the public Internet.  The NAT has
an endpoint independent mapping property and an address dependent
filtering property.  The public side of the NAT has an IP address of
192.0.2.3.
Two agents, L and R, are using ICE.  Both are full ICE
implementations.  Both agents have a single IPv4 address.  For agent
L, it is 10.0.1.1 in private address space RFC1918, and for agent R,
192.0.2.1 on the public Internet.  Both are configured with the same
STUN server (shown in this example for simplicity, although in
practice the agents do not need to use the same STUN server), which
is listening for STUN Binding requests at an IP address of 192.0.2.2
and port 3478.  TURN servers are not used in this example.  Agent L
is behind a NAT, and agent R is on the public Internet.  The NAT has
an endpoint independent mapping property and an address dependent
filtering property.  The public side of the NAT has an IP address of
192.0.2.3.
The call flow examples omit STUN authentication operations and RTCP,
and focus on RTP for a single media stream between two full
implementations.
First, agent L obtains a host candidate from its local IP address
(not shown), and from that, sends a STUN Binding request to the STUN
server to get a server reflexive candidate (messages 1-4).  Recall
that the NAT has the address and port independent mapping property.
Here, it creates a binding of NAT-PUB-1 for this UDP request, and
this becomes the server reflexive candidate for RTP.
The call flow examples omit STUN authentication operations, and focus
on a single media stream between two full implementations.
First, agent L obtains a host candidate from its local IP address
(not shown), and from that, sends a STUN Binding request to the STUN
server to get a server reflexive candidate (messages 1-4).  Recall
that the NAT has the address and port independent mapping property.
Here, it creates a binding of NAT-PUB-1 for this UDP request, and
this becomes the server reflexive candidate.
When agent L gets the R's candidates, it performs its one and only
connectivity check (messages 10-13).  It implements the aggressive
nomination algorithm, and thus includes a USE-CANDIDATE attribute in
this check.  Since the check succeeds, agent L creates a new pair,
whose local candidate is from the mapped address in the Binding
response (NAT-PUB-1 from message 13) and whose remote candidate is
the destination of the request (R-PUB-1 from message 10).  This is
added to the VALID LIST.  In addition, it is marked as selected since
the Binding request contained the USE-CANDIDATE attribute.  Since
there is a selected candidate in the VALID LIST for the one component
of this media stream, ICE processing for this stream moves into the
Completed state.  Agent L can now send media if it so chooses.
When agent L gets the R's candidates, it performs its one and only
connectivity check (messages 10-13).  Since the check succeeds, agent
L creates a new pair, whose local candidate is from the mapped
address in the Binding response (NAT-PUB-1 from message 13) and whose
remote candidate is the destination of the request (R-PUB-1 from
message 10).  This is added to the valid list.  Agent L can now send
media if it so chooses.
This specification defines four new attributes, PRIORITY, USE-
CANDIDATE, ICE-CONTROLLED, and ICE-CONTROLLING.
This specification defines four new STUN attributes, PRIORITY, USE-
CANDIDATE, ICE-CONTROLLED, and ICE-CONTROLLING.
TURN traffic is more substantial.  The TURN server will see traffic
volume equal to the STUN volume (indeed, if TURN servers are
deployed, there is no need for a separate STUN server), in addition
to the traffic for the actual media traffic.  The amount of calls
requiring TURN for media relay is highly dependent on network
topologies, and can and will vary over time.  In a network with 100%
behave-compliant NAT, it is exactly zero.  At time of writing, large-
scale consumer deployments were seeing between 5 and 10 percent of
calls requiring TURN servers.  Considering a voice-only deployment
using G.711 (so 80 kbps in each direction), with .2 erlangs during
the busy hour, this is N*3.2 kbps.  For a population of one million
users, this is 3.2 Gbps, assuming a 10% usage of TURN servers.
TURN traffic is more substantial.  The TURN server will see traffic
volume equal to the STUN volume (indeed, if TURN servers are
deployed, there is no need for a separate STUN server), in addition
to the traffic for the actual media.  The amount of calls requiring
TURN for media relay is highly dependent on network topologies, and
can and will vary over time.  In a network with 100% behave-compliant
NAT, it is exactly zero.  At time of writing, large-scale consumer
deployments were seeing between 5 and 10 percent of calls requiring
TURN servers.  Considering a voice-only deployment using G.711 (so 80
kbps in each direction), with .2 erlangs during the busy hour, this
is N*3.2 kbps.  For a population of one million users, this is 3.2
Gbps, assuming a 10% usage of TURN servers.
ICE has built-in features to help deal with these problems.  SIP
servers on the signaling path, typically deployed in the data centers
of the network operator, will see the contents of the candidate
exchanges that convey the ICE parameters.  These parameters include
the type of each candidate (host, server reflexive, or relayed),
along with their related addresses.  Once ICE processing has
completed, an updated candidate exchange takes place, signaling the
selected address (and its type).  This updated re-INVITE is performed
exactly for the purposes of educating network equipment (such as a
diagnostic tool attached to a SIP server) about the results of ICE
processing.
As a consequence, through the logs generated by the SIP server, a
network operator can observe what types of candidates are being used
for each call, and what address was selected by ICE.  This is the
primary information that helps evaluate how ICE is performing.
ICE has built-in features to help deal with these problems.
Signaling servers, typically deployed in the data centers of the
network operator, will see the contents of the candidate exchanges
that convey the ICE parameters.  These parameters include the type of
each candidate (host, server reflexive, or relayed), along with their
related addresses.  Once ICE processing has completed, an updated
candidate exchange takes place, signaling the selected address (and
its type).  This updated signaling is performed exactly for the
purposes of educating network equipment (such as a diagnostic tool
attached to a signaling) about the results of ICE processing.
As a consequence, through the logs generated by a signaling server, a
network operator can observe what types of candidates are being used
for each call, and what address were selected by ICE.  This is the
primary information that helps evaluate how ICE is performing.