Draft: draft-ietf-ice-rfc5245bis

Commentary: Some minor comments , this all seems correct to me though .
In a typical ICE deployment, we have two endpoints (known as ICE
AGENTS) that want to communicate.  They are able to communicate
indirectly via some signaling protocol (such as SIP), by which they
can exchange ICE candidates.  Note that ICE is not intended for NAT
traversal for the signaling protocol, which is assumed to be provided
via another mechanism.  At the beginning of the ICE process, the
agents are ignorant of their own topologies.  In particular, they
might or might not be behind a NAT (or multiple tiers of NATs).  ICE
allows the agents to discover enough information about their
topologies to potentially find one or more paths by which they can
communicate.
In a typical ICE deployment, there are two endpoints (ICE agents)
that want to communicate.  Note that ICE is not intended for NAT
traversal for the signaling protocol, which is assumed to be provided
via another mechanism.  ICE assumes that the agents are able to
communicate via some signaling protocol.  At the beginning of the ICE
process, the agents are ignorant of their own topologies.  In
particular, the agents may or may not be behind NATs (or multiple
tiers of NATs).  ICE allows the agents to discover enough information
about their topologies to potentially find one or more paths by which
they can communicate.
fig-ice-ref-arch shows a typical environment for ICE deployment.  The
two endpoints are labelled L and R (for left and right, which helps
visualize call flows).  Both L and R are behind their own respective
NATs though they may not be aware of it.  The type of NAT and its
properties are also unknown.  Agents L and R are capable of engaging
in an candidate exchange process, whose purpose is to set up a media
session between L and R.  Typically, this exchange will occur through
a signaling (e.g., SIP) server.
fig-ice-ref-arch shows a typical environment for ICE deployment.  The
two endpoints are labelled L and R (for left and right, which helps
visualize call flows).  Both L and R are behind their own respective
NATs though they may not be aware of it.  The type of NAT and its
properties are also unknown.  Agents L and R are capable of engaging
in an candidate exchange process, whose purpose is to set up a media
session between L and R.  Typically, this exchange will occur through
a signaling server (e.g., SIP proxy).
If an agent is multihomed, it obtains a candidate from each IP
address.  Depending on the location of the PEER (the other agent in
the session) on the IP network relative to the agent, the agent may
be reachable by the peer through one or more of those IP addresses.
Consider, for example, an agent that has a local IP address on a
private net 10 network (I1), and a second connected to the public
Internet (I2).  A candidate from I1 will be directly reachable when
communicating with a peer on the same private net 10 network, while a
candidate from I2 will be directly reachable when communicating with
a peer on the public Internet.  Rather than trying to guess which IP
address will work, the initiating agent sends both the candidates to
its peer.
If an agent is multihomed, it obtains a candidate from each IP
address.  Depending on the location of the peer agent on the IP
network relative to the agent, the agent may be reachable by the peer
through one or more of those IP addresses.  Consider, for example, an
agent that has a local IP address on a private net 10 network (I1),
and a second connected to the public Internet (I2).  A candidate from
I1 will be directly reachable when communicating with a peer on the
same private net 10 network, while a candidate from I2 will be
directly reachable when communicating with a peer on the public
Internet.  Rather than trying to guess which IP address will work,
the initiating agent sends both the candidates to its peer.
Once L has gathered all of its candidates, it orders them in highest
to lowest-priority and sends them to R over the signaling channel.
When R receives the candidates from L, it performs the same gathering
process and responds with its own list of candidates.  At the end of
this process, each agent has a complete list of both its candidates
and its peer's candidates.  It pairs them up, resulting in CANDIDATE
PAIRS.  To see which pairs work, each agent schedules a series of
CHECKS.  Each check is a STUN request/response transaction that the
client will perform on a particular candidate pair by sending a STUN
request from the local candidate to the remote candidate.
Once L has gathered all of its candidates, it orders them in highest
to lowest-priority and sends them to R over the signaling channel.
When R receives the candidates from L, it performs the same gathering
process and responds with its own list of candidates.  At the end of
this process, each agent has a complete list of both its candidates
and its peer's candidates.  It pairs them up, resulting in candidate
pairs.  To see which pairs work, each agent schedules a series of
connectivity checks.  Each check is a STUN request/response
transaction that the client will perform on a particular candidate
pair by sending a STUN request from the local candidate to the remote
candidate.
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.
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 (peer reflexive candidate), which then gets tested by ICE
just the same as any other candidate.
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.
When nominating, the controlling agent lets the checks continue until
at least one valid candidate pair for each media stream is found and
then picks a candidate pair from the valid candidate pairs and sends
a STUN request on the pair, using an attribute to indicate to the
controlled peer that it has nominated the pair.  This is shown in
fig-regular-select.
Once the controlled agent receives the STUN request with the
attribute, it will check (unless the check has already been done) the
same pair.  If the transactions above succeed, the agents will set
the nominated flag for the pairs, and will cancel any future checks
for that component of the media stream.  Once an agent has set the
nominated flag for each component of a media stream, the pairs become
the selected pairs.  After that, only the selected pairs will be used
for sending and receiving media associated with that media stream.
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.
If a valid candidate pair has its nominated flag set, it means
that it may be selected by ICE for sending and receiving 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 ICE agent that waits for the controlling agent to nominate a
candidate pair.
The process of the controlling agent indicating to the controlled
agent which candidate pair the agents should use for sending and
receiving media.
Once the nomination of a candidate pair has succeeded, the
candidate pair has become nominated, and has its nominated flag
set.
The candidate pair used for sending and receiving media for a
component of a media stream is referred to as the selected pair.
Before selected pairs have been produced for a media stream, any
valid candidate pair associated with a component of a media stream
can be used for sending and receiving media for the component.
Once there are nominated pairs for each component of a media
stream, the nominated pairs become the selected pairs for the
media stream.  The candidates associated with the selected pairs
are referred to as selected candidates.
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.
ICE agents (initiating and responding) need the following information
about candidates to be exchanged.  Each ICE usage MUST define how the
information is exchanged with the using protocol.  This section
describes the information that needs to be exchanged.
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 transport protocol of the candidate.  This MAY be omitted
if the using protocol only runs over a single transport
protocol.
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.
The pacing value for connectivity checks that the agent wishes to
use.  This MAY be omitted if the agent wishes to use a defined
default value.
The Initiating Agent which started the ICE processing MUST take
the controlling role, and the other MUST take the controlled role.
Both agents will form check lists, run the ICE state machines, and
generate connectivity checks.  The controlling agent will execute
the logic in sec-conclude-full to nominate pairs that will be
selected by ICE, and then both agents end ICE as described in sec-
conc-state.
The full agent MUST take the controlling role, and the lite agent
MUST take the controlled role.  The full agent will form check
lists, run the ICE state machines, and generate connectivity
checks.  That agent will execute the logic in sec-conclude-full to
nominate pairs that will be selected by ICE, and use the logic in
sec-conc-state to end ICE.  The lite implementation will just
listen for connectivity checks, receive them and respond to them,
and then conclude ICE as described in sec-lite-conclude.  For the
lite implementation, the state of ICE processing for each media
stream is considered to be Running, and the state of ICE overall
is Running.
The Initiating Agent which started the ICE processing MUST take
the controlling role, and the other MUST take the controlled role.
Both agents will form check lists, run the ICE state machines, and
generate connectivity checks.  The controlling agent will execute
the logic in sec-conclude-full to nominate pairs that will become
(if the connectivity checks associated with the nominations
succeed) the selected pairs, and then both agents end ICE as
described in sec-conc-state.
The full agent MUST take the controlling role, and the lite agent
MUST take the controlled role.  The full agent will form check
lists, run the ICE state machines, and generate connectivity
checks.  That agent will execute the logic in sec-conclude-full to
nominate pairs that will become (if the connectivity checks
associated with the nominations succeed) the selected pairs, and
use the logic in sec-conc-state to end ICE.  The lite
implementation will just listen for connectivity checks, receive
them and respond to them, and then conclude ICE as described in
sec-lite-conclude.  For the lite implementation, the state of ICE
processing for each media stream is considered to be Running, and
the state of ICE overall is Running.
The check list has a selected candidate pair for each component of
the media stream.
The check list contains a nominated pair for each component of the
media stream.
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.
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 picked, 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 picked again.  Etc.
If there are one or more candidate pairs in the Waiting state, the
agent selects the highest-priority candidate pair (if there are
multiple pairs with the same priority, the pair with the lowest
component ID is selected) in the Waiting state, performs a
connectivity check on that pair, puts the candidate pair par state
to In-Progress, and abort the subsequent steps.
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.
If there are one or more candidate pairs in the Waiting state, the
agent picks the highest-priority candidate pair (if there are
multiple pairs with the same priority, the pair with the lowest
component ID is picked) in the Waiting state, performs a
connectivity check on that pair, puts the candidate pair par state
to In-Progress, and abort the subsequent steps.
If this step is reached, no check could be performed for the
picked 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 picked 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.
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.
If the controlling agent sends a Binding request with the USE-
CANDIDATE attribute set, and if the agent receives a successful
response to the request, the agent sets the Nominated Flag of the
pair to true.  If the request fails sec-client-failure, the 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.
If the controlled agent receives a successful response to a Binding
request sent by the agent, and that Binding request was triggered by
a received Binding request with the USE-CANDIDATE attribute set sec-
triggered, the agent sets the Nominated Flag of the pair to true.  If
the triggered request fails, the 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.
When a triggered check is to be sent, it is constructed and processed
as described in sec-send-check.  These procedures require the agent
to know the transport address, username fragment, and password for
the peer.  The username fragment for the remote candidate is equal to
the part after the colon of the USERNAME in the Binding request that
was just received.  Using that username fragment, the agent can check
the candidates received from its peer (there may be more than one in
cases of forking), and find this username fragment.  The
corresponding password is then selected.
If the state of this pair is Succeeded, it means that the check
generated by this pair produced a successful response.  This would
have caused the agent to construct a valid pair when that success
response was received (see sec-valid-cons).  The agent now sets
the nominated flag value of the valid pair to true.  This may end
ICE processing for this media stream; see sec-conclude.
If the state of this pair is In-Progress, and if its check
produces a successful result, the resulting valid pair has its
nominated flag set when the response arrives.  This may end ICE
processing for this media stream when it arrives; see sec-
conclude.
If the check that was just received contained a USE-CANDIDATE
attribute, the agent constructs a candidate pair whose local
candidate is equal to the transport address on which the request was
received, and whose remote candidate is equal to the source transport
address of the request that was received.  This candidate pair is
assigned an arbitrary priority, and placed into a list of valid
candidates called the valid list.  The agent sets the nominated flag
for that pair to true.  ICE processing is considered complete for a
media stream if the valid list contains a candidate pair for each
component.
When a triggered check is to be sent, it is constructed and processed
as described in sec-send-check.  These procedures require the agent
to know the transport address, username fragment, and password for
the peer.  The username fragment for the remote candidate is equal to
the part after the colon of the USERNAME in the Binding request that
was just received.  Using that username fragment, the agent can check
the candidates received from its peer (there may be more than one in
cases of forking), and find this username fragment.  The
corresponding password is then picked.
If the state of this pair is Succeeded, it means that the check
previously sent by this pair produced a successful response, and
generated a valid pair (sec-valid-cons).  The agent sets the
nominated flag value of the pair to true.
If the received Binding request triggered a new check to be enqued
in the triggered check queue (sec-triggered), once the check is
sent and if it generates a successful response, and generates a
valid pair, the agent sets the nominated flag of the pair to true.
If the request fails sec-client-failure, the 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.
If the controlled agent does not accept the request from the
controlling agent, the controlled agent MUST reject the nomination
request with an appropriate error code response (e.g., 400) RFC5389.
If the controlled agent receives a Binding request with the USE-
CANDIDATE attribute set, and if the agent accepts the request, the
agent constructs a candidate pair whose local candidate is equal to
the transport address on which the request was received, and whose
remote candidate is equal to the source transport address of the
request that was received.  This candidate pair is assigned an
arbitrary priority, and placed into a list of valid candidates called
the valid list.  The agent sets the nominated flag for that pair to
true.
Prior to nominating, the agent let connectivity quecks continue until
some stopping criterion is met.  After that, based on an evaluation
criterion, the agent selects a pair among the valid pairs in the
valid list for nomination.
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 criterion details for stopping the connectivity checks and for
selecting a pair for nomiation, are outside the scope of this
specification.  They are a matter of local optimization.  The only
requirement is that the agent MUST eventually pick one and only one
candidate pair and generate a check for that pair with the USE-
CANDIDATE attribute present.
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.
NOTE: A controlling agent that does not support this specification
(i.e. it is implemented according to RFC 5245) might nominate more
than one candidate pair.  This was referred to as aggressive
nomination in RFC 5245.  The usage of the 'ice2' ice option by
endpoints supporting this specifcation should prevent such
controlling agents from using aggressive nomination.
Prior to nominating, the controlling agent let connectivity checks
continue until some stopping criterion is met.  After that, based on
an evaluation criterion, the controlling agent picks a pair among the
valid pairs in the valid list for nomination.
Once the controlling agent has picked 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 sec-up-fav.
Eventually, if the nominations succeed, both the controlling and
controlled agents will have a single nominated pair in the valid list
for each component of the media stream.  Once an agent sets the state
of the check list is set to Completed (when there is a nominated pair
for each component of the media stream), that pair becomes the
selected pair for that agent, and is used for sending and receiving
media for that component of the media stream.
If an agent is not able to produce selected pairs for a media stream,
the agent MUST take proper actions for informing the other agent, and
e.g.,removing the stream.  The exact actions are outside the sope of
this specification.
The criterion details for stopping the connectivity checks and for
selecting a pair for nomination, are outside the scope of this
specification.  They are a matter of local optimization.  The only
requirement is that the agent MUST eventually pick one and only one
candidate pair and generate a check for that pair with the USE-
CANDIDATE attribute set.
If more than one candidate pair is nominated by the controlling
agent, and if the controlled agent accepts multiple nominations
requests, the agents MUST produce the selected pairs using the pairs
with the highest priority.
NOTE: A controlling agent that does not support this specification
(i.e. it is implemented according to RFC 5245) might nominate more
than one candidate pair.  This was referred to as aggressive
nomination in RFC 5245.  The usage of the 'ice2' ice option by
endpoints supporting this specification should prevent such
controlling agents from using aggressive nomination.
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 full agent, once the lite agent accepts a nomination
request for a candidate pair, the lite agent considers the pair
nominated.  Once there are nominated pairs for each component of a
media stream, the pairs become the selected pairs for the components
of the media stream.  Once the lite agent has produced selected pairs
for all components of all media streams, the ICE session state is set
to Completed.
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.
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 candidate exchange is
complete.
The procedures in sec-conclude require that an agent continue to
listen for STUN requests and continue to generate triggered checks
for a media stream, even once processing for that stream completes.
The rules in this section describe when it is safe for an agent to
cease sending or receiving checks on a candidate that was not
selected by ICE, and then free the candidate.
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.
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.
The procedures in sec-conclude require that an agent continue to
listen for STUN requests and continue to generate triggered checks
for a media stream, even once processing for that stream completes.
The rules in this section describe when it is safe for an agent to
cease sending or receiving checks on a candidate that did not become
a selected candidate (is not associated with a selected pair), and
then free the candidate.
Once a check list 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 that became selected candidates.  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.
A lite implementation can free candidates that did not become
selected candidates as soon as ICE processing has reached the
Completed state for all ICE sessions using those candidates.
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.
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.
Once selected pairs have been produced for a media stream, keepalives
are only sent on those pairs.
An agent MUST stop sending keepalives on a media stream if the media
stream is removed.  If the ICE session is terminated, an agent MUST
stop sending keepalives on all media streams.
An agent MAY use another value for Tr, e.g. based on configuration or
network/NAT characteristics.  For example, if an agent has a dynamic
way to discover the binding lifetimes of the intervening NATs, it can
use that value to determine Tr.  Administrators deploying ICE in more
controlled networking environments SHOULD set Tr to the longest
duration possible in their environment.
An agent MUST begin the keepalive processing once ICE has selected
candidates for usage with media, or media begins to flow, whichever
happens first.  Keepalives end once the session terminates or the
media stream is removed.
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 MAY send media on any valid candidate pair before selected
pairs have been produced for the media stream.
Once selected pairs have been produced for a media stream, an agent
MUST send media on those pairs.
Unless an agent is able to produce a selected pair for all components
associated with a media stream, the agent MUST NOT continue sending
media for any component associated with that media stream.
Unless an agent is able to produce a selected pair for each component
associated with a media stream, the agent MUST NOT continue sending
media for any component associated with that media stream.
Even though ICE agents are only allowed to send media using valid
candidate pairs (and, once a candidate pair has been selected, only
on the selected pair) ICE implementations SHOULD by default be
prepared to receive media on any of the candidates provided in the
most recent candidate exchange with the peer.  Specific ICE usages
MAY define rules that differs from this, e.g., by defining that media
must not be sent until selected pairs have been procduced for each
component associated with that media.
Even though ICE agents are only allowed to send media using valid
candidate pairs (and, once selected pairs have been produced, only on
the selected pairs) ICE implementations SHOULD by default be prepared
to receive media on any of the candidates provided in the most recent
candidate exchange with the peer.  Specific ICE usages MAY define
rules that differs from this, e.g., by defining that media must not
be sent until selected pairs have been produced for a media stream.
ICE itself doesn't easily get phased out.  However, it is useful even
in a globally connected Internet, to serve as a means for detecting
whether a router failure has temporarily disrupted connectivity, for
example.  ICE also helps prevent certain security attacks that have
nothing to do with NAT.  However, what ICE does is help phase out
other UNSAF mechanisms.  ICE effectively selects amongst those
mechanisms, prioritizing ones that are better, and deprioritizing
ones that are worse.  Local IPv6 addresses can be preferred.  As NATs
begin to dissipate as IPv6 is introduced, server reflexive and
relayed candidates (both forms of UNSAF addresses) simply never get
used, because higher-priority connectivity exists to the native host
candidates.  Therefore, the servers get used less and less, and can
eventually be remove when their usage goes to zero.
ICE itself doesn't easily get phased out.  However, it is useful even
in a globally connected Internet, to serve as a means for detecting
whether a router failure has temporarily disrupted connectivity, for
example.  ICE also helps prevent certain security attacks that have
nothing to do with NAT.  However, what ICE does is help phase out
other UNSAF mechanisms.  ICE effectively picks amongst those
mechanisms, prioritizing ones that are better, and deprioritizing
ones that are worse.  Local IPv6 addresses can be preferred.  As NATs
begin to dissipate as IPv6 is introduced, server reflexive and
relayed candidates (both forms of UNSAF addresses) simply never get
used, because higher-priority connectivity exists to the native host
candidates.  Therefore, the servers get used less and less, and can
eventually be remove when their usage goes to zero.