draft-ietf-mmusic-ice-10.txt   draft-ietf-mmusic-ice-11.txt 
MMUSIC J. Rosenberg MMUSIC J. Rosenberg
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: March 4, 2007 August 31, 2006 Expires: April 9, 2007 October 6, 2006
Interactive Connectivity Establishment (ICE): A Methodology for Network Interactive Connectivity Establishment (ICE): A Methodology for Network
Address Translator (NAT) Traversal for Offer/Answer Protocols Address Translator (NAT) Traversal for Offer/Answer Protocols
draft-ietf-mmusic-ice-10 draft-ietf-mmusic-ice-11
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 4, 2007. This Internet-Draft will expire on April 9, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes a protocol for Network Address Translator This document describes a protocol for Network Address Translator
(NAT) traversal for multimedia session signaling protocols based on (NAT) traversal for multimedia session signaling protocols based on
the offer/answer model, such as the Session Initiation Protocol the offer/answer model, such as the Session Initiation Protocol
skipping to change at page 2, line 17 skipping to change at page 2, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Gathering Candidate Addresses . . . . . . . . . . . . . . 6 2.1. Gathering Candidate Addresses . . . . . . . . . . . . . . 6
2.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 8 2.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 8
2.3. Sorting Candidates . . . . . . . . . . . . . . . . . . . . 10 2.3. Sorting Candidates . . . . . . . . . . . . . . . . . . . . 10
2.4. Frozen Candidates . . . . . . . . . . . . . . . . . . . . 10 2.4. Frozen Candidates . . . . . . . . . . . . . . . . . . . . 10
2.5. Security for Checks . . . . . . . . . . . . . . . . . . . 11 2.5. Security for Checks . . . . . . . . . . . . . . . . . . . 11
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 13 4. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 13
4.1. Gathering Candidates . . . . . . . . . . . . . . . . . . . 13 4.1. Gathering Candidates . . . . . . . . . . . . . . . . . . . 13
4.2. Prioritizing Candidates . . . . . . . . . . . . . . . . . 15 4.2. Prioritizing Candidates . . . . . . . . . . . . . . . . . 16
4.3. Choosing In-Use Candidates . . . . . . . . . . . . . . . . 18 4.3. Choosing In-Use Candidates . . . . . . . . . . . . . . . . 18
4.4. Encoding the SDP . . . . . . . . . . . . . . . . . . . . . 19 4.4. Encoding the SDP . . . . . . . . . . . . . . . . . . . . . 18
5. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 20 5. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 20
5.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 20 5.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 20
5.2. Gathering Candidates . . . . . . . . . . . . . . . . . . . 21 5.2. Gathering Candidates . . . . . . . . . . . . . . . . . . . 20
5.3. Prioritizing Candidates . . . . . . . . . . . . . . . . . 21 5.3. Prioritizing Candidates . . . . . . . . . . . . . . . . . 21
5.4. Choosing In Use Candidates . . . . . . . . . . . . . . . . 21 5.4. Choosing In Use Candidates . . . . . . . . . . . . . . . . 21
5.5. Encoding the SDP . . . . . . . . . . . . . . . . . . . . . 21 5.5. Encoding the SDP . . . . . . . . . . . . . . . . . . . . . 21
5.6. Forming the Check List . . . . . . . . . . . . . . . . . . 21 5.6. Forming the Check Lists . . . . . . . . . . . . . . . . . 21
5.7. Performing Periodic Checks . . . . . . . . . . . . . . . . 23 5.7. Performing Periodic Checks . . . . . . . . . . . . . . . . 23
6. Receipt of the Initial Answer . . . . . . . . . . . . . . . . 24 6. Receipt of the Initial Answer . . . . . . . . . . . . . . . . 24
6.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 24 6.1. Verifying ICE Support . . . . . . . . . . . . . . . . . . 24
6.2. Forming the Check List . . . . . . . . . . . . . . . . . . 24 6.2. Forming the Check List . . . . . . . . . . . . . . . . . . 24
6.3. Performing Periodic Checks . . . . . . . . . . . . . . . . 24 6.3. Performing Periodic Checks . . . . . . . . . . . . . . . . 24
7. Connectivity Checks . . . . . . . . . . . . . . . . . . . . . 24 7. Connectivity Checks . . . . . . . . . . . . . . . . . . . . . 24
7.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 24 7.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 24
7.2. Client Discovery of Server . . . . . . . . . . . . . . . . 25 7.2. Client Discovery of Server . . . . . . . . . . . . . . . . 25
7.3. Server Determination of Usage . . . . . . . . . . . . . . 25 7.3. Server Determination of Usage . . . . . . . . . . . . . . 25
7.4. New Requests or Indications . . . . . . . . . . . . . . . 25 7.4. New Requests or Indications . . . . . . . . . . . . . . . 25
skipping to change at page 5, line 17 skipping to change at page 5, line 17
beginning of the ICE process, the agents are ignorant of their own beginning of the ICE process, the agents are ignorant of their own
topologies. In particular, they might or might not be behind a NAT topologies. In particular, they might or might not be behind a NAT
(or multiple tiers of NATs). ICE allows the agents to discover (or multiple tiers of NATs). ICE allows the agents to discover
enough information about their topologies to find a path or paths by enough information about their topologies to find a path or paths by
which they can communicate. which they can communicate.
Figure Figure 1 shows a typical environment for ICE deployment. The Figure Figure 1 shows a typical environment for ICE deployment. The
two endpoints are labelled L and R (for left and right, which helps two endpoints are labelled L and R (for left and right, which helps
visualize call flows). Both L and R are behind NATs -- though as visualize call flows). Both L and R are behind NATs -- though as
mentioned before, they don't know that. The type of NAT and its mentioned before, they don't know that. The type of NAT and its
properties are also unknown. Agents A and B are capable of engaging properties are also unknown. Agents L and R are capable of engaging
in an offer/answer exchange by which they can exchange SDP messages, in an offer/answer exchange by which they can exchange SDP messages,
whose purpose is to set up a media session between A and B. whose purpose is to set up a media session between L and R.
Typically, this exchange will occur through a SIP server. Typically, this exchange will occur through a SIP server.
In addition to the agents, a SIP server and NATs, ICE is typically In addition to the agents, a SIP server and NATs, ICE is typically
used in concert with STUN servers in the network. Each agent can used in concert with STUN servers in the network. Each agent can
have its own STUN server, or they can be the same. have its own STUN server, or they can be the same.
+-------+ +-------+
| SIP | | SIP |
+-------+ | Srvr | +-------+ +-------+ | Srvr | +-------+
| STUN | | | | STUN | | STUN | | | | STUN |
skipping to change at page 9, line 10 skipping to change at page 9, line 10
1. Sort the candidate pairs in priority order. 1. Sort the candidate pairs in priority order.
2. Send checks on each candidate pair in priority order. 2. Send checks on each candidate pair in priority order.
3. Acknowledge checks received from the other agent. 3. Acknowledge checks received from the other agent.
A complete connectivity check for a single candidate pair is a simple A complete connectivity check for a single candidate pair is a simple
4-message handshake: 4-message handshake:
A B L R
- - - -
STUN request -> \ A's STUN request -> \ L's
<- STUN response / check <- STUN response / check
<- STUN request \ B's <- STUN request \ R's
STUN response -> / check STUN response -> / check
Figure 3 Figure 3
As an optimization, as soon as B gets A's check message he As an optimization, as soon as R gets L's check message he
immediately sends his own check message to A on the same candidate immediately sends his own check message to L on the same candidate
pair. This accelerates the process of finding a valid candidate. pair. This accelerates the process of finding a valid candidate.
At the end of this handshake, both A and B know that they can send At the end of this handshake, both L and R know that they can send
(and receive) messages end-to-end in both directions. Note that as (and receive) messages end-to-end in both directions. Note that as
soon as B receives A's STUN response it knows that the B->A path soon as R receives L's STUN response it knows that the R->L path
works and it can start sending media on that path right away, as works and it can start sending media on that path right away, as
shown below. This allows for 'early media' to flow as fast as shown below. This allows for 'early media' to flow as fast as
possible: possible:
A B L R
- - - -
STUN request -> \ A's STUN request -> \ L's
<- STUN response / check <- STUN response / check
<- STUN request \ B's <- STUN request \ R's
STUN response -> / check STUN response -> / check
<- RTP Data <- RTP Data
Figure 4 Figure 4
Once any connectivity check for a candidate for a given media Once any connectivity check for a candidate for a given media
component succeeds, ICE uses that candidate and immediately abandons component succeeds, ICE uses that candidate and immediately abandons
all other connectivity checks for that component. Note that due to all other connectivity checks for that component. Note that due to
race conditions and packet loss, this may mean that the "best" race conditions and packet loss, this may mean that the "best"
candidate isn't selected, but it does guarantee the selection of a candidate isn't selected, but it does guarantee the selection of a
skipping to change at page 12, line 5 skipping to change at page 12, line 5
peer is the other agent. Specifically, from the perspective of peer is the other agent. Specifically, from the perspective of
the offerer, the peer is the answerer. From the perspective of the offerer, the peer is the answerer. From the perspective of
the answerer, the peer is the offerer. the answerer, the peer is the offerer.
Transport Address: The combination of an IP address and port. Transport Address: The combination of an IP address and port.
Candidate: A transport address that is to be tested by ICE procedures Candidate: A transport address that is to be tested by ICE procedures
in order to determine its suitability for usage for receipt of in order to determine its suitability for usage for receipt of
media. media.
Component: A component is a single transport address that is used to
support a media stream. For media streams based on RTP, there are
two components per media stream - one for RTP, and one for RTCP.
Host Candidate: A candidate obtained by binding to a specific port Host Candidate: A candidate obtained by binding to a specific port
from an interface on the host. This includes both physical from an interface on the host. This includes both physical
interfaces and logical ones, such as ones obtained through Virtual interfaces and logical ones, such as ones obtained through Virtual
Private Networks (VPNs) and Realm Specific IP (RSIP) [17] (which Private Networks (VPNs) and Realm Specific IP (RSIP) [17] (which
lives at the operating system level). lives at the operating system level).
Server Reflexive Candidate: A candidate obtained by sending a STUN Server Reflexive Candidate: A candidate obtained by sending a STUN
request from a host candidate to a STUN server, distinct from the request from a host candidate to a STUN server, distinct from the
peer, whose address is configured or learned by the client prior peer, whose address is configured or learned by the client prior
to an offer/answer exchange. to an offer/answer exchange.
skipping to change at page 13, line 42 skipping to change at page 13, line 45
In order to send the initial offer in an offer/answer exchange, an In order to send the initial offer in an offer/answer exchange, an
agent must gather candidates, priorize them, choose ones for agent must gather candidates, priorize them, choose ones for
inclusion in the m/c-line, and then formulate and send the SDP. Each inclusion in the m/c-line, and then formulate and send the SDP. Each
of these steps is described in the subsections below. of these steps is described in the subsections below.
4.1. Gathering Candidates 4.1. Gathering Candidates
An agent gathers candidates when it believes that communications is An agent gathers candidates when it believes that communications is
imminent. An offerer can do this based on a user interface cue, or imminent. An offerer can do this based on a user interface cue, or
based on an explicit request to initiate a session. Every candidate based on an explicit request to initiate a session. Every candidate
is an IP address and port (also known as a transport address). It is a transport address. It also has a type and a base. Three types
also has a type and a base. Three types are defined and gathered by are defined and gathered by this specification - host candidates,
this specification - host candidates, server reflexive candidates, server reflexive candidates, and relayed candidates. The base of a
and relayed candidates. The base of a candidate is candidate that an candidate is the candidate that an agent must send from when using
agent must send from when using that candidate. that candidate.
The first step is to gather host candidates. Host candidates are The first step is to gather host candidates. Host candidates are
obtained by binding to ports (typically ephemeral) on an interface obtained by binding to ports (typically ephemeral) on an interface
(physical or virtual, including VPN interfaces) on the host. The (physical or virtual, including VPN interfaces) on the host. The
process for gathering host candidates depends on the transport process for gathering host candidates depends on the transport
protocol. Procedures are specified here for UDP. protocol. Procedures are specified here for UDP.
For each UDP media stream the agent wishes to use, the agent SHOULD 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 obtain a candidate for each component of the media stream on each
interface that the host has. It obtains each candidate by binding to interface that the host has. It obtains each candidate by binding to
skipping to change at page 16, line 4 skipping to change at page 16, line 9
relayed candidates, the STUN servers used to obtain them have the relayed candidates, the STUN servers used to obtain them have the
same IP address. Similarly, two candidates MUST have different same IP address. Similarly, two candidates MUST have different
foundations if their types are different, their bases have different foundations if their types are different, their bases have different
IP addresses, or the STUN servers used to obtain them have different IP addresses, or the STUN servers used to obtain them have different
IP addresses. IP addresses.
4.2. Prioritizing Candidates 4.2. Prioritizing Candidates
The prioritization process results in the assignment of a priority to The prioritization process results in the assignment of a priority to
each candidate. An agent does this by determining a preference for each candidate. An agent does this by determining a preference for
each type of candidate (server reflexive, per reflexive, relayed and each type of candidate (server reflexive, peer reflexive, relayed and
host), and, when the agent is multihomed, choosing a preference for host), and, when the agent is multihomed, choosing a preference for
its interfaces. These two preferences are then combined to compute its interfaces. These two preferences are then combined to compute
the priority for a candidate. That priority MUST be computed using the priority for a candidate. That priority MUST be computed using
the following formula: the following formula:
priority = 1000*(type preference) + priority = (2^24)*(type preference) +
100*(local preference) + (2^8)*(local preference) +
10*(stream ID) + (2^0)*(256 - component ID)
1*(10 - component ID)
The type preference MUST be an integer from 0 to 9 inclusive, and The type preference MUST be an integer from 0 to 126 inclusive, and
represents the preference for the type of the candidate (where the represents the preference for the type of the candidate (where the
types are local, server reflexive, peer reflexive and relayed). A 9 types are local, server reflexive, peer reflexive and relayed). A
is the highest preference, and a 0 is the lowest. Setting the value 126 is the highest preference, and a 0 is the lowest. Setting the
to a 0 means that candidates of this type will only be used as a last value to a 0 means that candidates of this type will only be used as
resort. The type preference MUST be identical for all candidates of a last resort. The type preference MUST be identical for all
the same type and MUST be different for candidates of different candidates of the same type and MUST be different for candidates of
types. The type preference for peer reflexive candidates MUST be different types. The type preference for peer reflexive candidates
lower than that of server reflexive candidates. Note that candidates MUST be higher than that of server reflexive candidates. Note that
gathered based on the procedures of Section 4.1 will never be peer candidates gathered based on the procedures of Section 4.1 will never
reflexive candidates; candidates of these type are learned from the be peer reflexive candidates; candidates of these type are learned
STUN connectivity checks performed by ICE. The component ID is the from the STUN connectivity checks performed by ICE. The component ID
component ID for the candidate, and MUST be between 1 and 10 is the component ID for the candidate, and MUST be between 1 and 256
inclusive. The stream ID is an integer, starting at 9, that inclusive. The local preference MUST be an integer from 0 to 65535
decrements by one for each media stream in the session. When
signaled in the SDP, the first m-line is the one with stream ID 9,
the next with stream ID 8, the next with stream ID 7, and so on. In
essence, the stream ID indicates the position of that media stream in
the SDP itself. The stream ID MUST be less than or equal to 9, and
therefore ICE only works with multimedia sessions with 10 or fewer
media streams. The local preference MUST be an integer from 0 to 9
inclusive. It represents a preference for the particular interface inclusive. It represents a preference for the particular interface
from which the candidate was obtained, in cases where an agent is from which the candidate was obtained, in cases where an agent is
multihomed. A nine represents the highest preference, and a zero, multihomed. 65535 represents the highest preference, and a zero, the
the lowest. When there is only a single interface, this value SHOULD lowest. When there is only a single interface, this value SHOULD be
be set to nine. Generally speaking, if there are multiple candidates set to 65535. Generally speaking, if there are multiple candidates
for a particular component for a particular media stream which have for a particular component for a particular media stream which have
the same type, the local preference MUST be unique for each one. In the same type, the local preference MUST be unique for each one. In
this specification, this only happens for multi-homed hosts. this specification, this only happens for multi-homed hosts.
These rules guarantee that there is a unique priority for each These rules guarantee that there is a unique priority for each
candidate. This priority will be used by ICE to determine the order candidate. This priority will be used by ICE to determine the order
of the connectivity checks and the relative preference for of the connectivity checks and the relative preference for
candidates. Consequently, what follows are some guidelines for candidates. Consequently, what follows are some guidelines for
selection of these values. selection of these values.
skipping to change at page 17, line 19 skipping to change at page 17, line 15
candidates that involve an intermediary. Another are host candidates candidates that involve an intermediary. Another are host candidates
obtained from a VPN interface. When media is transited through an obtained from a VPN interface. When media is transited through an
intermediary, it can increase the latency between transmission and intermediary, it can increase the latency between transmission and
reception. It can increase the packet losses, because of the reception. It can increase the packet losses, because of the
additional router hops that may be taken. It may increase the cost additional router hops that may be taken. It may increase the cost
of providing service, since media will be routed in and right back of providing service, since media will be routed in and right back
out of an intermediary run by the provider. If these concerns are out of an intermediary run by the provider. If these concerns are
important, the type preference for relayed candidates can be set important, the type preference for relayed candidates can be set
lower than the type preference for reflexive and host candidates. lower than the type preference for reflexive and host candidates.
Indeed, it is RECOMMENDED that in this case, host candidates have a Indeed, it is RECOMMENDED that in this case, host candidates have a
type preference of nine, server reflexive candidates have a type type preference of 126, server reflexive candidates have a type
preference of 5, peer reflexive have a type prefence of 6, and preference of 100, peer reflexive have a type prefence of 110, and
relayed candidates have a type preference of zero. Furthermore, if relayed candidates have a type preference of zero. Furthermore, if
an agent is multi-homed and has multiple interfaces, the local an agent is multi-homed and has multiple interfaces, the local
preference for host candidates from a VPN interface SHOULD have a preference for host candidates from a VPN interface SHOULD have a
priority of 0. priority of 0.
Another criteria for selection of preferences is IP address family. Another criteria for selection of preferences is IP address family.
ICE works with both IPv4 and IPv6. It therefore provides a ICE works with both IPv4 and IPv6. It therefore provides a
transition mechanism that allows dual-stack hosts to prefer transition mechanism that allows dual-stack hosts to prefer
connectivity over IPv6, but to fall back to IPv4 in case the v6 connectivity over IPv6, but to fall back to IPv4 in case the v6
networks are disconnected (due, for example, to a failure in a 6to4 networks are disconnected (due, for example, to a failure in a 6to4
skipping to change at page 18, line 6 skipping to change at page 18, line 5
a VPN interface would have a higher local preference than any other a VPN interface would have a higher local preference than any other
interfaces. interfaces.
Another criteria for selecting preferences is topological awareness. Another criteria for selecting preferences is topological awareness.
This is most useful for candidates that make use of relays. In those This is most useful for candidates that make use of relays. In those
cases, if an agent has preconfigured or dynamically discovered cases, if an agent has preconfigured or dynamically discovered
knowledge of the topological proximity of the relays to itself, it knowledge of the topological proximity of the relays to itself, it
can use that to assign higher local preferences to candidates can use that to assign higher local preferences to candidates
obtained from closer relays. obtained from closer relays.
There may be transport-specific reasons for assigning preferences to
candidates. In such a case, specifications defining usage of ICE
with other transport protocols SHOULD document such considerations.
4.3. Choosing In-Use Candidates 4.3. Choosing In-Use Candidates
A candidate is said to be "in-use" if it appears in the m/c-line of A candidate is said to be "in-use" if it appears in the m/c-line of
an offer or answer. When communicating with an ICE peer, being in- an offer or answer. When communicating with an ICE peer, being in-
use implies that, should these candidates be selected by the ICE use implies that, should these candidates be selected by the ICE
algorithm, bidirectional media can flow and the candidates can be algorithm, bidirectional media can flow and the candidates can be
used. If a candidate is selected by ICE but is not in-use, only used. If a candidate is selected by ICE but is not in-use, only
unidirectional media can flow and only for a brief time; the unidirectional media can flow and only for a brief time; the
candidate must be made in-use through an updated offer/answer candidate must be made in-use through an updated offer/answer
exchange. When communicating with a peer that is not ICE-aware, the exchange. When communicating with a peer that is not ICE-aware, the
skipping to change at page 18, line 48 skipping to change at page 18, line 43
Indeed, the difficulty in picking just one transport address that Indeed, the difficulty in picking just one transport address that
will work is the whole problem that motivated the development of this will work is the whole problem that motivated the development of this
specification in the first place. As such, it is RECOMMENDED that specification in the first place. As such, it is RECOMMENDED that
relayed candidates be selected to be in-use. Furthermore, ICE is relayed candidates be selected to be in-use. Furthermore, ICE is
only truly effective when it is supported on both sides of the only truly effective when it is supported on both sides of the
session. It is therefore most prudent to deploy it to close-knit session. It is therefore most prudent to deploy it to close-knit
communities as a whole, rather than piecemeal. In the example above, communities as a whole, rather than piecemeal. In the example above,
this would mean that ICE would ideally be deployed completely within this would mean that ICE would ideally be deployed completely within
the enterprise, rather than just to parts of it. the enterprise, rather than just to parts of it.
There may be transport-specific reasons for selection of an in-use
candidate. In such a case, specifications defining usage of ICE with
other transport protocols SHOULD document such considerations.
4.4. Encoding the SDP 4.4. Encoding the SDP
The agent includes a single a=candidate media level attribute in the The agent includes a single a=candidate media level attribute in the
SDP for each candidate for that media stream. The a=candidate SDP for each candidate for that media stream. The a=candidate
attribute contains the IP address, port and transport protocol for attribute contains the IP address, port and transport protocol for
that candidate. A Fully Qualified Domain Name (FQDN) for a host MAY that candidate. A Fully Qualified Domain Name (FQDN) for a host MAY
be used in place of a unicast address. In that case, when receiving be used in place of a unicast address. In that case, when receiving
an offer or answer containing an FQDN in an a=candidate attribute, an offer or answer containing an FQDN in an a=candidate attribute,
the FQDN is looked up in the DNS using an A or AAAA record, and the the FQDN is looked up in the DNS using an A or AAAA record, and the
resulting IP address is used for the remainder of ICE processing. resulting IP address is used for the remainder of ICE processing.
skipping to change at page 19, line 15 skipping to change at page 19, line 4
4.4. Encoding the SDP 4.4. Encoding the SDP
The agent includes a single a=candidate media level attribute in the The agent includes a single a=candidate media level attribute in the
SDP for each candidate for that media stream. The a=candidate SDP for each candidate for that media stream. The a=candidate
attribute contains the IP address, port and transport protocol for attribute contains the IP address, port and transport protocol for
that candidate. A Fully Qualified Domain Name (FQDN) for a host MAY that candidate. A Fully Qualified Domain Name (FQDN) for a host MAY
be used in place of a unicast address. In that case, when receiving be used in place of a unicast address. In that case, when receiving
an offer or answer containing an FQDN in an a=candidate attribute, an offer or answer containing an FQDN in an a=candidate attribute,
the FQDN is looked up in the DNS using an A or AAAA record, and the the FQDN is looked up in the DNS using an A or AAAA record, and the
resulting IP address is used for the remainder of ICE processing. resulting IP address is used for the remainder of ICE processing.
The candidate attribute also includes the component ID for that The candidate attribute also includes the component ID for that
candidate. For media streams based on RTP, candidates for the actual candidate. For media streams based on RTP, candidates for the actual
RTP media MUST have a component ID of 1, and candidates for RTCP MUST RTP media MUST have a component ID of 1, and candidates for RTCP MUST
have a component ID of 2. Other types of media streams which require have a component ID of 2. Other types of media streams which require
multiple components MUST develop specifications which define the multiple components MUST develop specifications which define the
mapping of components to component IDs. mapping of components to component IDs, and these component IDs MUST
be between 1 and 256.
The candidate attribute also includes the priority, which is the The candidate attribute also includes the priority, which is the
value determined for the candidate as described in Section 4.2, and value determined for the candidate as described in Section 4.2, and
the foundation, which is the value determined for the candidate as the foundation, which is the value determined for the candidate as
described in Section 4.1. The agent SHOULD include a type for each described in Section 4.1. The agent SHOULD include a type for each
candidate by populating the candidate-types production with the candidate by populating the candidate-types production with the
appropriate value - "host" for host candidates, "srflx" for server appropriate value - "host" for host candidates, "srflx" for server
reflexive candidates, "prflx" for peer reflexive candidates (though reflexive candidates, "prflx" for peer reflexive candidates (though
these never appear in an initial offer/answer exchange), and "relay" these never appear in an initial offer/answer exchange), and "relay"
for relayed candidates. The related address MUST NOT be included if for relayed candidates. The related address MUST NOT be included if
skipping to change at page 20, line 32 skipping to change at page 20, line 23
Once an offer or answer are sent, an agent MUST be prepared to Once an offer or answer are sent, an agent MUST be prepared to
receive both STUN and media packets on each candidate. As discussed receive both STUN and media packets on each candidate. As discussed
in Section 11.1, media packets can be sent to a candidate prior to in Section 11.1, media packets can be sent to a candidate prior to
its appearence in the m/c-line. its appearence in the m/c-line.
5. Receiving the Initial Offer 5. Receiving the Initial Offer
When an agent receives an initial offer, it will check if the offeror When an agent receives an initial offer, it will check if the offeror
supports ICE, gather candidates, prioritize them, choose one for in- supports ICE, gather candidates, prioritize them, choose one for in-
use, encode and send an answer, and then form a check list and begin use, encode and send an answer, and then form the check lists and
connectivity checks. begin connectivity checks.
5.1. Verifying ICE Support 5.1. Verifying ICE Support
The agent will proceed with the ICE procedures defined in this The agent will proceed with the ICE procedures defined in this
specification if the following are both true: specification if the following are both true:
o There is at least one a=candidate attribute for each media stream o There is at least one a=candidate attribute for each media stream
in the SDP it just received. in the SDP it just received.
o For each media stream, at least one of the candidates is a match o For each media stream, at least one of the candidates is a match
skipping to change at page 21, line 29 skipping to change at page 21, line 21
The process for selecting in-use candidates at the answerer is The process for selecting in-use candidates at the answerer is
identical to the process followed by the offerer, as described in identical to the process followed by the offerer, as described in
Section 4.3. Section 4.3.
5.5. Encoding the SDP 5.5. Encoding the SDP
The process for encoding the SDP at the answerer is identical to the The process for encoding the SDP at the answerer is identical to the
process followed by the offerer, as described in Section 4.4. process followed by the offerer, as described in Section 4.4.
5.6. Forming the Check List 5.6. Forming the Check Lists
Next, the agent forms the check list. The check list is a sequence Next, the agent forms the check lists. There is one check list per
in-use media stream resulting from the offer/answer exchange. A
media stream is in-use as long as its port is non-zero (which is used
in RFC 3264 to reject a media stream). Each check list is a sequence
of STUN connectivity checks that are performed by the agent. To form of STUN connectivity checks that are performed by the agent. To form
the check list, the agent forms candidate pairs, computes a candidate the check list for a media stream, the agent forms candidate pairs,
pair priority, orders the pairs by priority, prunes them, and sets computes a candidate pair priority, orders the pairs by priority,
their states. These steps are described in this section. prunes them, and sets their states. These steps are described in
this section.
First, the agent takes each of its candidates (called local First, the agent takes each of its candidates for a media stream
candidates) and pairs them with the candidates it received from its (called local candidates) and pairs them with the candidates it
peer (called remote candidates). A local candidate is paired with a received from its peer (called remote candidates) for that media
remote candidate if and only if the two candidates are for the same stream. A local candidate is paired with a remote candidate if and
media stream, have the same component ID, and have the same IP only if the two candidates have the same component ID and have the
address version. It is possible that some of the local candidates same IP address version. It is possible that some of the local
don't get paired with a remote candidate, and some of the remote candidates don't get paired with a remote candidate, and some of the
candidates don't get paired with local candidates. This can happen remote candidates don't get paired with local candidates. This can
if one agent didn't include candidates for the all of the components happen if one agent didn't include candidates for the all of the
for a media stream. In the case of RTP, for example, this would components for a media stream. In the case of RTP, for example, this
happen when one agent provided candidates for RTCP, and the other did would happen when one agent provided candidates for RTCP, and the
not. If this happens, the number of components for that media stream other did not. If this happens, the number of components for that
is effectively reduced, and considered to be equal to the minimum media stream is effectively reduced, and considered to be equal to
across both agents of the maximum component ID provided by each agent the minimum across both agents of the maximum component ID provided
across all components for the media stream. by each agent across all components for the media stream.
Once the pairs are formed, a candidate pair priority is computed. Once the pairs are formed, a candidate pair priority is computed.
Let O-P be the priority for the candidate provided by the offerer. Let O-P be the priority for the candidate provided by the offerer.
Let A-P be the priority for the candidate provided by the answerer. Let A-P be the priority for the candidate provided by the answerer.
Let O-IP be the IP address (without the port) of the candidate The priority for a pair is computed as:
provided by the offerer. Let SZ be two to the power of 32 for IPv4
candidates, and two to the power of 128 for IPv6 candidates. The
priority for a pair is computed as:
pair priority = 10000*MIN(O-P,A-P) + MAX(O-P,A-P) + O-IP/SZ
OPEN ISSUE: This can be larger than 32 bits. Should consider ways pair priority = 2^32*MIN(O-P,A-P) + 2*MAX(O-P,A-P) + (O-P>A-P:1?0)
of reducing that.
This formula ensures a unique priority for each pair in most cases. Where O-P>A-P:1?0 is an expression whose value is 1 if O-P is greater
One the priority is assigned, the agent sorts the candidate pairs in than A-P, and 0 otherwise. This formula ensures a unique priority
decreasing order of priority. If two pairs have identical priority, for each pair in most cases. One the priority is assigned, the agent
the ordering amongst them is arbitrary. sorts the candidate pairs in decreasing order of 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 This sorted list of candidate pairs is used to determine a sequence
of connectivity checks that will be performed. Each check involves of connectivity checks that will be performed. Each check involves
sending a request from a local candidate to a remote candidate. sending a request from a local candidate to a remote candidate.
Since an agent cannot send requests directly from a reflexive Since an agent cannot send requests directly from a reflexive
candidate, but only from its base, the agent next goes through the candidate, but only from its base, the agent next goes through the
sorted list of candidate pairs. For each pair where the local sorted list of candidate pairs. For each pair where the local
candidate is server reflexive, the server reflexive candidate MUST be candidate is server reflexive, the server reflexive candidate MUST be
replaced by its base. Once this has been done, the agent MUST remove replaced by its base. Once this has been done, the agent MUST remove
redundant pairs. A pair is redundant if its local and remote redundant pairs. A pair is redundant if its local and remote
candidates are identical to the local and remote candidates of a pair candidates are identical to the local and remote candidates of a pair
higher up on the priority list. The result is called the check list, higher up on the priority list. The result is called the check list
and each candidate pair on it is called a check. for that media stream, and each candidate pair on it is called a
check.
Each check is also said to have a foundation, which is merely the Each check is also said to have a foundation, which is merely the
combination of the foundations of the local and remote candidates in combination of the foundations of the local and remote candidates in
the check. the check.
Finally, each check in the check list is associated with a state. Finally, each check in the check list is associated with a state.
There are five potential values that the state can have: This state is assigned once the check list for each media stream has
been computed. There are five potential values that the state can
have:
Waiting: This check has not been performed, and can be performed as Waiting: This check has not been performed, and can be performed as
soon as it is the highest priority Waiting check on the check soon as it is the highest priority Waiting check on the check
list. list.
In-Progress: A request has been sent for this check, but the In-Progress: A request has been sent for this check, but the
transaction is in progress. transaction is in progress.
Succeeded: This check was already done and produced a successful Succeeded: This check was already done and produced a successful
result. result.
Failed: This check was already done and failed, either never Failed: This check was already done and failed, either never
producing any response or producing an unrecoverable failure producing any response or producing an unrecoverable failure
response. response.
Frozen: This check hasn't been performed, and it can't yet be Frozen: This check hasn't been performed, and it can't yet be
performed until some other check succeeds, allowing it to move performed until some other check succeeds, allowing it to move
into the Waiting state. into the Waiting state.
First, the agent sets all of the checks to the Frozen state. Then, First, the agent sets all of the checks in each check list to the
it sets the first check in the check list to Waiting. It then finds Frozen state. Then, it takes the first check in the check list for
all of the other checks for the same media stream and with the same the first media stream (a media stream is the first media stream when
component ID, but different foundations, and sets all of their states it is described by the first m-line in the SDP offer and answer), and
to Waiting. sets its state to Waiting. It then finds all of the other checks in
that check list with the same component ID, but different
foundations, and sets all of their states to Waiting as well. Once
this is done, one of the check lists will have some number of checks
in the Waiting state, and the other check lists will have all of
their checks in the Frozen state. A check list with at least one
check that is not Frozen is called an active check list.
5.7. Performing Periodic Checks 5.7. Performing Periodic Checks
An agent performs two types of checks. The first type are periodic An agent performs two types of checks. The first type are periodic
checks. These checks occur periodically, and involve choosing the checks. These checks occur periodically for each media stream, and
highest priority check in the Waiting state from the check list, and involve choosing the highest priority check in the Waiting state from
performing it. The other type of check is called a triggered check. each check list, and performing it. The other type of check is
This is a check that is performed on receipt of a connectivity check called a triggered check. This is a check that is performed on
from the peer. This section describes how periodic checks are receipt of a connectivity check from the peer. This section
performed. describes how periodic checks are performed.
Once the agent has computed the check list as described in Once the agent has computed the check lists as described in
Section 5.6, it sets a timer that fires every Ta seconds. This is Section 5.6, it sets a timer for each active check list. The timer
the same value used to pace the gathering of candidates, as described fires every Ta/N seconds, where N is the number of active check lists
in Section 4.1. The first timer fires immediately, so that the agent (initially, there is only one active check list). Implementations
performs a connectivity check the moment the offer/answer exchange MAY set the timer to fire less frequently than this. Ta is the same
has been done, followed by the next periodic check Ta seconds later. value used to pace the gathering of candidates, as described in
Section 4.1. The first timer for each active check list fires
immediately, so that the agent performs a connectivity check the
moment the offer/answer exchange has been done, followed by the next
periodic check Ta seconds later.
When the timer fires, the agent MUST find the highest priority check When the timer fires, the agent MUST find the highest priority check
in the check list that is in the Waiting state. The agent then sends in that check list that is in the Waiting state. The agent then
a STUN check from the local candidate of that check to the remote sends a STUN check from the local candidate of that check to the
candidate of that check. The procedures for forming the STUN request remote candidate of that check. The procedures for forming the STUN
for this purpose are described in Section 7.7.1. If none of the request for this purpose are described in Section 7.7.1. If none of
checks in the check list are in the Waiting state, but there are the checks in that check list are in the Waiting state, but there are
checks in the Frozen state, the highest priority check in the Frozen checks in the Frozen state, the highest priority check in the Frozen
state is moved into the Waiting state, and that check is performed. state is moved into the Waiting state, and that check is performed.
When a check is performed, its state is set to In-Progress. If there When a check is performed, its state is set to In-Progress. If there
are no checks in either the Waiting or Frozen state, then timer Ta is are no checks in either the Waiting or Frozen state, then the timer
stopped. for that check list is stopped.
Performing the connectivity check requires the agent to know the Performing the connectivity check requires the agent to know the
username fragment for the local and remote candidates, and the username fragment for the local and remote candidates, and the
password for the remote candidate. For periodic checks, the remote password for the remote candidate. For periodic checks, the remote
username fragment and password are learned directly from the SDP username fragment and password are learned directly from the SDP
received from the peer, and the local username fragment is known by received from the peer, and the local username fragment is known by
the agent. the agent.
6. Receipt of the Initial Answer 6. Receipt of the Initial Answer
skipping to change at page 25, line 15 skipping to change at page 25, line 17
It is fundamental to this STUN usage that the addresses and ports It is fundamental to this STUN usage that the addresses and ports
used for media are the same ones used for the Binding Requests and used for media are the same ones used for the Binding Requests and
responses. Consequently, it will be necessary to demultiplex STUN responses. Consequently, it will be necessary to demultiplex STUN
traffic from whatever the media traffic is. This demultiplexing is traffic from whatever the media traffic is. This demultiplexing is
done using the techniques described in [11]. done using the techniques described in [11].
7.2. Client Discovery of Server 7.2. Client Discovery of Server
The client does not follow the DNS-based procedures defined in [11]. The client does not follow the DNS-based procedures defined in [11].
Rather, the remote candidate of the check to be performed is used as Rather, the remote candidate of the check to be performed is used as
the IP address and port of the STUN server. Note that the STUN the transport address of the STUN server. Note that the STUN server
server is a logical entity, and is not a physically distinct server is a logical entity, and is not a physically distinct server in this
in this usage. usage.
7.3. Server Determination of Usage 7.3. Server Determination of Usage
The server is aware of this usage because it signaled this port The server is aware of this usage because it signaled this port
through the offer/answer exchange. Any STUN packets received on this through the offer/answer exchange. Any STUN packets received on this
port will be for the connectivity check usage. port will be for the connectivity check usage.
7.4. New Requests or Indications 7.4. New Requests or Indications
This usage does not define any new message types. This usage does not define any new message types.
skipping to change at page 26, line 44 skipping to change at page 26, line 45
7.7.2. Processing the Response 7.7.2. Processing the Response
If the STUN transaction generates an unrecoverable failure response If the STUN transaction generates an unrecoverable failure response
or times out, the agent sets the state of the check to Failed. The or times out, the agent sets the state of the check to Failed. The
remainder of this section applies to processing of successful remainder of this section applies to processing of successful
responses (any response from 200 to 299). responses (any response from 200 to 299).
The agent MUST check that the source IP address and port of the The agent MUST check that the source IP address and port of the
response equals the destination IP address and port that the Binding response equals the destination IP address and port that the Binding
Request was sent to, and that the source IP address and port of the Request was sent to, and that the destination IP address and port of
request match the destination IP address and port that the Binding the response match the source IP address and port that the Binding
Response was received on. If these do not match, the agent sets the Request was sent from. If these do not match, the agent sets the
state of the check to Failed. The processing described in the state of the check to Failed. The processing described in the
remainder of this section MUST NOT be performed. remainder of this section MUST NOT be performed.
Otherwise, the source transport address of the response matched the If the check succeeds, processing continues and the agent changes the
destination transport address of the request. The agent changes the
state for this check to Succeeded. Next, the agent sees if the state for this check to Succeeded. Next, the agent sees if the
success of this check can cause other checks to be unfrozen. If the success of this check can cause other checks to be unfrozen. If the
check had a component ID of one, the agent MUST change the states for check had a component ID of one, the agent MUST change the states for
all other Frozen checks for the same media stream and same all other Frozen checks for the same media stream and same
foundation, but different component IDs, to Waiting. If the foundation, but different component IDs, to Waiting. If the
component ID for the check was equal to the number of components for component ID for the check was equal to the number of components for
the media stream, the agent MUST change the state for all other the media stream, the agent MUST change the state for all other
Frozen checks for the first component of different media streams but Frozen checks for the first component of different media streams (and
the same foundation, to Waiting. thus in different check lists) but the same foundation, to Waiting.
Next, the agent checks the mapped address from the STUN response. If Next, the agent checks the mapped address from the STUN response. If
the transport address does not match any of the local candidates that the transport address does not match any of the local candidates that
the agent knows about, the mapped address representes a new peer the agent knows about, the mapped address representes a new peer
reflexive candidate. Its type is equal to peer reflexive. Its base reflexive candidate. Its type is equal to peer reflexive. Its base
is set equal to the candidate from which the STUN check was sent. is set equal to the candidate from which the STUN check was sent.
Its username fragment and password are identical to the candidate Its username fragment and password are identical to the candidate
from which the check was sent. It is assigned the priority value from which the check was sent. It is assigned the priority value
that was placed in the PRIORITY attribute of the request. Its that was placed in the PRIORITY attribute of the request. Its
foundation is selected as described in Section 4.1. The peer foundation is selected as described in Section 4.1. The peer
reflexive candidate is then added to the list of local candidates reflexive candidate is then added to the list of local candidates
known by the agent (though it is not paired with other remote known by the agent (though it is not paired with other remote
candidates at this time). candidates at this time).
In addition, the agent creates a candidate pair whose local candidate In addition, the agent creates a candidate pair whose local candidate
equals the mapped address of the response, and whose remote candidate equals the mapped address of the response, and whose remote candidate
equals the destination address to which the request was sent. This equals the destination address to which the request was sent. This
is called a validated pair, since it has been validated by a STUN is called a validated pair, since it has been validated by a STUN
connectivity check. The agent will know, either from the SDP or connectivity check. It is very important to note that this validated
pair will often not be identical to the check itself; in many cases,
the local candidate (learned through the mapped address in the
response) will be different than the local candidate the request was
sent from. However, the agent will know, either from the SDP or
through the PRIORITY attribute that was present in a STUN request, through the PRIORITY attribute that was present in a STUN request,
the priorities of the local and remote candidates of the validated the priorities of the local and remote candidates of the validated
pair. Based on these priorities, a priority for the validated pair pair. Based on these priorities, a priority for the validated pair
itself is computed if it was not already known, using the algorithm itself is computed if it was not already known, using the algorithm
in Section 5.6, and the pair is added to the valid list. in Section 5.6, and the pair is added to the valid list.
7.8. Server Procedures 7.8. Server Procedures
An agent MUST be prepared to receive a Binding Request on the base of An agent MUST be prepared to receive a Binding Request on the base of
each candidate it included in its most recent offer or answer. each candidate it included in its most recent offer or answer.
Receipt of a Binding Request on an IP address and port that the agent Receipt of a Binding Request on a transport address that the agent
had included in a candidate attribute is an indication that the had included in a candidate attribute is an indication that the
connectivity check usage applies to the request. connectivity check usage applies to the request.
The agent MUST use a short term credential to authenticate the The agent MUST use a short term credential to authenticate the
request and perform a message integrity check. The agent MUST accept request and perform a message integrity check. The agent MUST accept
a credential if the username consists of two values separated by a a credential if the username consists of two values separated by a
colon, where the first value is equal to the username fragment colon, where the first value is equal to the username fragment
generated by the agent in an offer or answer for a session in- generated by the agent in an offer or answer for a session in-
progress, and the password is equal to the password for that username progress, and the password is equal to the password for that username
fragment. It is possible (and in fact very likely) that an offeror fragment. It is possible (and in fact very likely) that an offeror
will receive a Binding Request prior to receiving the answer from its will receive a Binding Request prior to receiving the answer from its
peer. However, the request can be processed without receiving this peer. However, the request can be processed without receiving this
answer, and a response generated. answer, and a response generated.
For requests being received on a relayed candidate, the source IP For requests being received on a relayed candidate, the source
address and port used for STUN processing (namely, generation of the transport address used for STUN processing (namely, generation of the
XOR-MAPPED-ADDRESS attribute) is the IP address and port as seen by XOR-MAPPED-ADDRESS attribute) is the transport address as seen by the
the relay. That source transport address will be present in the relay. That source transport address will be present in the REMOTE-
REMOTE-ADDRESS attribute of a STUN Data Indication message, if the ADDRESS attribute of a STUN Data Indication message, if the Binding
Binding Request was delivered through a Data Indication. If the Request was delivered through a Data Indication. If the Binding
Binding Request was not encapsulated in a Data Indication, that Request was not encapsulated in a Data Indication, that source
source address is equal to the current active destination for the address is equal to the current active destination for the STUN relay
STUN relay session. session.
When the agent receives a STUN Binding Request for which it generates When the agent receives a STUN Binding Request for which it generates
a successful response, the agent checks the source transport address a successful response, the agent checks the source transport address
of the request. If this transport address does not match any of the request. If this transport address does not match any
existing remote candidates, it represents a new peer reflexive remote existing remote candidates, it represents a new peer reflexive remote
candidate. This candidate is given a priority equal to the PRIORITY candidate. This candidate is given a priority equal to the PRIORITY
attribute from the request. The type of the candidate is equal to attribute from the request. The type of the candidate is equal to
peer reflexive. Its foundation is set to an arbitrary value, peer reflexive. Its foundation is set to an arbitrary value,
different from the foundation for all other remote candidates. The different from the foundation for all other remote candidates. The
username fragment for this candidate is equal to the bottom half (the username fragment for this candidate is equal to the bottom half (the
skipping to change at page 32, line 8 skipping to change at page 32, line 12
Construction of the ice-pwd and ice-ufrag are identical to the Construction of the ice-pwd and ice-ufrag are identical to the
procedures followed by the offerer, as described in Section 9.1. procedures followed by the offerer, as described in Section 9.1.
Note that the a=remote-candidates attribute SHOULD NOT be included in Note that the a=remote-candidates attribute SHOULD NOT be included in
the answer, and if included, will just be ignored by the offerer, the answer, and if included, will just be ignored by the offerer,
since it is not used in any processing of the answer. since it is not used in any processing of the answer.
9.3. Updating the Check and Valid Lists 9.3. Updating the Check and Valid Lists
Once the subsequent offer/answer exchange has completed, each agent Once the subsequent offer/answer exchange has completed, each agent
needs to compute the new check list resulting from this exchange, and needs to compute the new check lists resulting from this exchange,
then remove any pairs from the valid list which are no longer usable. and then remove any pairs from the valid list which are no longer
Once these adjustments are made, ICE processing continues using these usable. Once these adjustments are made, ICE processing continues
new lists. using these new lists.
Each agent recomputes the check list using the procedures described Each agent recomputes the check lists using the procedures described
in Section 5.6. If a check on this new check list was also on the in Section 5.6. If a check on the new check lists was also on the
previous check list, and its state was Waiting, In-Progress, previous check lists, and its state was Waiting, In-Progress,
Succeeded or Failed, its state is copied over. If a check on the new Succeeded or Failed, its state is copied over. If a check on the new
check list does not have a state (because its a new check or its check lists does not have a state (because its a new check on an
state was not copied over), and it is for the component with existing check list, or a check on a new check list, or the check was
component ID 1 and for the media stream with stream ID 9, its state on an old check list but its state was not copied over) its state is
is set to Waiting. All other pairs without a state have their state
set to Frozen. set to Frozen.
Next, the agent goes through the check list, starting with the If none of the check lists are active (meaning that the checks in
each check list are Frozen), the agent sets the first check in the
check list for the first media stream to Waiting, and then sets the
state of all other checks in that check list for the same component
ID and with the same foundation to Waiting as well.
Next, the agent goes through each check list, starting with the
highest priority check. If a check has a state of Succeeded, and it highest priority check. If a check has a state of Succeeded, and it
has a component ID of 1, then all Frozen checks for the same media has a component ID of 1, then all Frozen checks in the same check
stream and same foundation whose component IDs are not one, have list with the same foundation whose component IDs are not one, have
their state set to Waiting. If, for a particular media stream, there their state set to Waiting. If, for a particular check list, there
are checks for each component of that media stream in the Succeeded are checks for each component of that media stream in the Succeeded
state, the agent moves the state of all Frozen checks for the first state, the agent moves the state of all Frozen checks for the first
component of all other media streams with the same foundation to component of all other media streams (and thus in different check
Waiting. lists) with the same foundation to Waiting.
If a check was on the old check list, but was not on the new check If a check was on the old check list, but was not on the new check
list, and had a state of In-Progress, the corresponding STUN list, and had a state of In-Progress, the corresponding STUN
transaction is abandoned. No further retransmits will be sent for transaction is abandoned. No further retransmits will be sent for
the STUN request, and any response that might be received is ignored. the STUN request, and any response that might be received is ignored.
Next, the agent prunes the valid list. For each pair on the valid Next, the agent prunes the valid list. For each pair on the valid
list, the agent examines each candidate in the pair. If the list, the agent examines each candidate in the pair. If the
candidate was not peer reflexive, and was not present in the most candidate was not peer reflexive, and was not present in the most
recent offer/answer exchange, the candidate pair is removed from the recent offer/answer exchange, the candidate pair is removed from the
skipping to change at page 35, line 22 skipping to change at page 35, line 29
encouraged to re-adjust jitter buffers when there are changes in encouraged to re-adjust jitter buffers when there are changes in
source or destination address. Furthermore, many audio codecs use source or destination address. Furthermore, many audio codecs use
the marker bit to signal the beginning of a talkspurt, for the the marker bit to signal the beginning of a talkspurt, for the
purposes of jitter buffer adaptation. For such codecs, it is purposes of jitter buffer adaptation. For such codecs, it is
RECOMMENDED that the sender change the marker bit when an agent RECOMMENDED that the sender change the marker bit when an agent
switches transmission of media from one candidate pair to another. switches transmission of media from one candidate pair to another.
11.2. Receiving Media 11.2. Receiving Media
ICE implementations MUST be prepared to receive media on any ICE implementations MUST be prepared to receive media on any
candidates provided in the most recent offer/answer exchange. In candidates provided in the most recent offer/answer exchange.
order to avoid attacks described in Section 15, when an agent
receives a media packet, and it knows its peer supports ICE, it MUST
verify that it has received a check (for which a successful response
was generated) on the same 5-tuple as the received media packet (that
is, the source and destination transport addresses of the media
packet match those of the check). If no such check has succeeded,
the agent MUST silently discard the media packet.
It is RECOMMENDED that, when an agent receives an RTP packet with a It is RECOMMENDED that, when an agent receives an RTP packet with a
new source or destination IP address for a particular media stream, new source or destination IP address for a particular media stream,
that the agent re-adjust its jitter buffers. that the agent re-adjust its jitter buffers.
RFC 3550 [20] describes an algorithm in Section 8.2 for detecting RFC 3550 [20] describes an algorithm in Section 8.2 for detecting
SSRC collisions and loops. These algorithms are based, in part, on SSRC collisions and loops. These algorithms are based, in part, on
seeing different source IP addresses and ports with the same SSRC. seeing different source transport addresses with the same SSRC.
However, when ICE is used, such changes will sometimes occur as the However, when ICE is used, such changes will sometimes occur as the
media streams switch between candidates. An agent will be able to media streams switch between candidates. An agent will be able to
determine that a media stream is from the same peer as a consequence determine that a media stream is from the same peer as a consequence
of the STUN exchange that proceeds media transmission. Thus, if of the STUN exchange that proceeds media transmission. Thus, if
there is a change in source IP address and port, but the media there is a change in source transport address, but the media packets
packets come from the same peer agent, this SHOULD NOT be treated as come from the same peer agent, this SHOULD NOT be treated as an SSRC
an SSRC collision. collision.
12. Usage with SIP 12. Usage with SIP
12.1. Latency Guidelines 12.1. Latency Guidelines
ICE requires a series of STUN-based connectivity checks to take place ICE requires a series of STUN-based connectivity checks to take place
between endpoints. These checks start from the answerer on between endpoints. These checks start from the answerer on
generation of its answer, and start from the offerer when it receives generation of its answer, and start from the offerer when it receives
the answer. These checks can take time to complete, and as such, the the answer. These checks can take time to complete, and as such, the
selection of messages to use with offers and answers can effect selection of messages to use with offers and answers can effect
skipping to change at page 37, line 35 skipping to change at page 37, line 35
the caller receives multiple incoming media streams, it cannot the caller receives multiple incoming media streams, it cannot
determine which media stream corresponds to which callee. determine which media stream corresponds to which callee.
With ICE, this problem is resolved. The connectivity checks which With ICE, this problem is resolved. The connectivity checks which
occur prior to transmission of media carry username fragments, which occur prior to transmission of media carry username fragments, which
in turn are correlated to a specific callee. Subsequent media in turn are correlated to a specific callee. Subsequent media
packets which arrive on the same 5-tuple as the connectivity check packets which arrive on the same 5-tuple as the connectivity check
will be associated with that same callee. Thus, the caller can will be associated with that same callee. Thus, the caller can
perform this correlation as long as it has received an answer. perform this correlation as long as it has received an answer.
Section 11.2 introduces a requirement for agents receiving media;
namely, that media should be discarded until a check has been
received from that peer. Unfortunately, this mechanism doesn't work
well in forking situations where a subset of the recipients are not
ICE-aware. Those recipients will not send checks, and media from
them will be discarded.
OPEN ISSUE: Obviously this is an issue. Need to either remove
this feature of ICE or find a way to make it work better in
forking situations.
12.3. Interactions with Preconditions 12.3. Interactions with Preconditions
Quality of Service (QoS) preconditions, which are defined in RFC 3312 Quality of Service (QoS) preconditions, which are defined in RFC 3312
[6] and RFC 4032 [7], apply only to the IP addresses and ports listed [6] and RFC 4032 [7], apply only to the transport addresses listed in
in the m/c lines in an offer/answer. If ICE changes the address and the m/c lines in an offer/answer. If ICE changes the transport
port where media is received, this change is reflected in the m/c address where media is received, this change is reflected in the m/c
lines of a new offer/answer. As such, it appears like any other re- lines of a new offer/answer. As such, it appears like any other re-
INVITE would, and is fully treated in RFC 3312 and 4032, which apply INVITE would, and is fully treated in RFC 3312 and 4032, which apply
without regard to the fact that the m/c lines are changing due to ICE without regard to the fact that the m/c lines are changing due to ICE
negotiations ocurring "in the background". negotiations ocurring "in the background".
Indeed, an agent SHOULD NOT indicate that Qos preconditions have been Indeed, an agent SHOULD NOT indicate that Qos preconditions have been
met until the ICE checks have completed and selected the candidate met until the ICE checks have completed and selected the candidate
pairs to be used for media. pairs to be used for media.
ICE also has (purposeful) interactions with connectivity ICE also has (purposeful) interactions with connectivity
preconditions [26]. Those interactions are described there. preconditions [26]. Those interactions are described there. Note
that the procedures described in Section 12.1 describe their own type
OPEN ISSUE: Are these preconditions really needed with ICE? ICE of "preconditions", albeit with less functionality than those
provides a connectivity precondition on its own using the provided by the explicit preconditions in [26].
mechanisms described above.
12.4. Interactions with Third Party Call Control 12.4. Interactions with Third Party Call Control
ICE works with Flows I and IV as described in [16]. Flow I works ICE works with Flows I and IV as described in [16]. Flow I works
without the controller supporting or being aware of ICE. Flow IV without the controller supporting or being aware of ICE. Flow IV
will work as long as the controller passes along the ICE attributes will work as long as the controller passes along the ICE attributes
without alteration. Flow III may disrupt ICE processing, since it without alteration. Flow III may disrupt ICE processing, since it
will distort the stream ID values used in the computation of will distort the stream ID values used in the computation of
priorities. When there is but a single media stream, Flow III will priorities. When there is but a single media stream, Flow III will
work as long as the controller passes through the ICE attributes work as long as the controller passes through the ICE attributes
skipping to change at page 43, line 27 skipping to change at page 43, line 21
Figure 9 Figure 9
First, agent L obtains a host candidate from its local interface (not First, agent L obtains a host candidate from its local interface (not
shown), and from that, sends a STUN Binding Request to the STUN shown), and from that, sends a STUN Binding Request to the STUN
server to get a server reflexive candidate (messages 1-4). Recall server to get a server reflexive candidate (messages 1-4). Recall
that the NAT has the address and port independent mapping property. 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 Here, it creates a binding of NAT-PUB-1 for this UDP request, and
this becomes the server reflexive candidate for RTP. this becomes the server reflexive candidate for RTP.
Agent L sets a type preference of 9 for the host candidate and 5 for Agent L sets a type preference of 126 for the host candidate and 100
the server reflexive. The local preference is 9. Based on this, the for the server reflexive. The local preference is 65535. Based on
priority of the host candidate is 9909 and for the server reflexive this, the priority of the host candidate is 2130706178 and for the
candidate is 5909. The host candidate is assigned a foundation of 1, server reflexive candidate is 1694498562. The host candidate is
and the server reflexive, a foundation of 2. It chooses its server assigned a foundation of 1, and the server reflexive, a foundation of
reflexive candidate as the in-use candidate, and encodes it into the 2. It chooses its server reflexive candidate as the in-use
m/c-line. The resulting offer (message 5) looks like (lines folded candidate, and encodes it into the m/c-line. The resulting offer
for clarity): (message 5) looks like (lines folded for clarity):
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP4 $L-PRIV-1.IP o=jdoe 2890844526 2890842807 IN IP4 $L-PRIV-1.IP
s= s=
c=IN IP4 $NAT-PUB-1.IP c=IN IP4 $NAT-PUB-1.IP
t=0 0 t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY a=ice-ufrag:8hhY
m=audio $NAT-PUB-1.PORT RTP/AVP 0 m=audio $NAT-PUB-1.PORT RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 9909 $L-PRIV-1.IP $L-PRIV-1.PORT typ local a=candidate:1 1 UDP 2130706178 $L-PRIV-1.IP $L-PRIV-1.PORT typ local
a=candidate:2 1 UDP 5909 $NAT-PUB-1.IP $NAT-PUB-1.PORT typ srflx raddr a=candidate:2 1 UDP 1694498562 $NAT-PUB-1.IP $NAT-PUB-1.PORT typ srflx raddr
$L-PRIV-1.IP rport $L-PRIV-1.PORT $L-PRIV-1.IP rport $L-PRIV-1.PORT
The offer, with the variables replaced with their values, will look The offer, with the variables replaced with their values, will look
like (lines folded for clarity): like (lines folded for clarity):
v=0 v=0
o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
s= s=
c=IN IP4 192.0.2.3 c=IN IP4 192.0.2.3
t=0 0 t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY a=ice-ufrag:8hhY
m=audio 45664 RTP/AVP 0 m=audio 45664 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 9909 10.0.1.1 8998 typ local a=candidate:1 1 UDP 2130706178 10.0.1.1 8998 typ local
a=candidate:2 1 UDP 5909 192.0.2.3 45664 typ srflx raddr a=candidate:2 1 UDP 1694498562 192.0.2.3 45664 typ srflx raddr
10.0.1.1 rport 8998 10.0.1.1 rport 8998
This offer is received at agent R. Agent R will obtain a host This offer is received at agent R. Agent R will obtain a host
candidate, and from it, obtain a server reflexive candidate (messages candidate, and from it, obtain a server reflexive candidate (messages
6-7). Since R is not behind a NAT, this candidate is identical to 6-7). Since R is not behind a NAT, this candidate is identical to
its host candidate, and they share the same base. It therefore its host candidate, and they share the same base. It therefore
discards this candidate and ends up with a single host candidate. discards this candidate and ends up with a single host candidate.
With identical type and local preferences as L, the priority for this With identical type and local preferences as L, the priority for this
candidate is 9909. It chooses a foundation of 1 for its single candidate is 2130706178. It chooses a foundation of 1 for its single
candidate. Its resulting answer looks like: candidate. Its resulting answer looks like:
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 $R-PUB-1.IP o=bob 2808844564 2808844564 IN IP4 $R-PUB-1.IP
s= s=
c=IN IP4 $R-PUB-1.IP c=IN IP4 $R-PUB-1.IP
t=0 0 t=0 0
a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
a=ice-ufrag:9uB6 a=ice-ufrag:9uB6
m=audio $R-PUB-1.PORT RTP/AVP 0 m=audio $R-PUB-1.PORT RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 9909 $R-PUB-1.IP $R-PUB-1.PORT typ local a=candidate:1 1 UDP 2130706178 $R-PUB-1.IP $R-PUB-1.PORT typ local
With the variables filled in: With the variables filled in:
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 192.0.2.1 o=bob 2808844564 2808844564 IN IP4 192.0.2.1
s= s=
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
t=0 0 t=0 0
a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
a=ice-ufrag:9uB6 a=ice-ufrag:9uB6
m=audio 3478 RTP/AVP 0 m=audio 3478 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 9909 192.0.2.1 3478 typ local a=candidate:1 1 UDP 2130706178 192.0.2.1 3478 typ local
Agents L and R both pair up the candidates. They both initially have Agents L and R both pair up the candidates. They both initially have
two. However, agent L will prune the pair containing its server two. However, agent L will prune the pair containing its server
reflexive candidate, resulting in just one. At agent L, this pair reflexive candidate, resulting in just one. At agent L, this pair
(the check) has a local candidate of $L_PRIV_1 and remote candidate (the check) has a local candidate of $L_PRIV_1 and remote candidate
of $R_PUB_1, and has a candidate pair priority of 99099909.039. At of $R_PUB_1, and has a candidate pair priority of 4.57566E+18 (note
agent R, there are two checks. The highest priority has a local that an implementation would represent this as a 64 bit integer so as
candidate of $R_PUB_1 and remote candidate of $L_PRIV_1 and has a not to lose precision). At agent R, there are two checks. The
priority of 99099909.039, and the second has a local candidate of highest priority has a local candidate of $R_PUB_1 and remote
$R_PUB_1 and remote candidate of $NAT_PUB_1 and priority 59099909.75. candidate of $L_PRIV_1 and has a priority of 4.57566E+18, and the
second has a local candidate of $R_PUB_1 and remote candidate of
$NAT_PUB_1 and priority 3.63891E+18.
Agent R begins its connectivity check (message 9) for the first pair Agent R begins its connectivity check (message 9) for the first pair
(between the two host candidates). The host candidate from agent L (between the two host candidates). The host candidate from agent L
is private and behind a different NAT, and thus this check is is private and behind a different NAT, and thus this check is
discarded. discarded.
When agent L gets the answer, it performs its one and only When agent L gets the answer, it performs its one and only
connectivity check (messages 10-13). This will succeed. This causes connectivity check (messages 10-13). This will succeed. This causes
agent L to create a new pair, whos local candidate is from the mapped agent L to create a new pair, whos local candidate is from the mapped
address in the binding response (NAT-PUB-1 from message 13) and whose address in the binding response (NAT-PUB-1 from message 13) and whose
skipping to change at page 45, line 45 skipping to change at page 45, line 44
v=0 v=0
o=jdoe 2890844528 2890842809 IN IP4 10.0.1.1 o=jdoe 2890844528 2890842809 IN IP4 10.0.1.1
s= s=
c=IN IP4 192.0.2.3 c=IN IP4 192.0.2.3
t=0 0 t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY a=ice-ufrag:8hhY
m=audio 45664 RTP/AVP 0 m=audio 45664 RTP/AVP 0
a=remote-candidates 1 192.0.2.1 3478 a=remote-candidates 1 192.0.2.1 3478
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=candidate:2 1 UDP 5909 192.0.2.3 45664 typ srflx raddr a=candidate:2 1 UDP 1694498562 192.0.2.3 45664 typ srflx raddr
10.0.1.1 rport 8998 10.0.1.1 rport 8998
Agent R can construct the answer. Since the remote-candidates listed Agent R can construct the answer. Since the remote-candidates listed
in the offer match the ones that agent R had already selected for the in the offer match the ones that agent R had already selected for the
m/c-line in the previous answer, there is no change there. Its m/c-line in the previous answer, there is no change there. Its
answer therefore looks like: answer therefore looks like:
v=0 v=0
o=bob 2808844565 2808844566 IN IP4 192.0.2.1 o=bob 2808844565 2808844566 IN IP4 192.0.2.1
s= s=
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
t=0 0 t=0 0
a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
a=ice-ufrag:9uB6 a=ice-ufrag:9uB6
m=audio 3478 RTP/AVP 0 m=audio 3478 RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 9909 192.0.2.1 3478 typ local a=candidate:1 1 UDP 2130706178 192.0.2.1 3478 typ local
Upon receipt of the check from agent L (message 11), agent R will Upon receipt of the check from agent L (message 11), agent R will
generate its triggered check. This check happens to match the next generate its triggered check. This check happens to match the next
one on its check list - from its host candidate to agent L's server one on its check list - from its host candidate to agent L's server
reflexive candidate. This check (messages 16-19) will succeed. reflexive candidate. This check (messages 16-19) will succeed.
Consequently, agent R constructs a new candidate pair using the Consequently, agent R constructs a new candidate pair using the
mapped address from the response as the local candidate (R-PUB-1) and mapped address from the response as the local candidate (R-PUB-1) and
the destination of the request (NAT-PUB-1) as the remote candidate. the destination of the request (NAT-PUB-1) as the remote candidate.
This pair is added to the valid list. Since this pair matches the This pair is added to the valid list. Since this pair matches the
pair in the m/c-lines, agent R can send media as well. pair in the m/c-lines, agent R can send media as well.
 End of changes. 73 change blocks. 
216 lines changed or deleted 209 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/