draft-ietf-mmusic-ice-06.txt   draft-ietf-mmusic-ice-07.txt 
MMUSIC J. Rosenberg MMUSIC J. Rosenberg
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: April 22, 2006 October 19, 2005 Expires: September 7, 2006 March 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-06 draft-ietf-mmusic-ice-07
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 April 22, 2006. This Internet-Draft will expire on September 7, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). 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
(SIP). This protocol is called Interactive Connectivity (SIP). This protocol is called Interactive Connectivity
Establishment (ICE). ICE makes use of existing protocols, such as Establishment (ICE). ICE makes use of the Simple Traversal of UDP
Simple Traversal of UDP Through NAT (STUN) and Traversal Using Relay through NAT (STUN), applying its binding discovery, connectivity
NAT (TURN). ICE makes use of STUN in peer-to-peer cooperative check and relay usages.
fashion, allowing participants to discover, create and verify mutual
connectivity.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . 8 3. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . 8
4. Sending the Initial Offer . . . . . . . . . . . . . . . . . 10 4. Sending the Initial Offer . . . . . . . . . . . . . . . . . 11
5. Receipt of the Offer and Generation of the Answer . . . . . 11 5. Receipt of the Offer and Generation of the Answer . . . . . 11
6. Processing the Answer . . . . . . . . . . . . . . . . . . . 11 6. Processing the Answer . . . . . . . . . . . . . . . . . . . 12
7. Common Procedures . . . . . . . . . . . . . . . . . . . . . 11 7. Common Procedures . . . . . . . . . . . . . . . . . . . . . 12
7.1 Gathering Candidates . . . . . . . . . . . . . . . . . . . 12 7.1 Gathering Candidates . . . . . . . . . . . . . . . . . . . 12
7.2 Prioritizing the Candidates and Choosing an Active One . . 15 7.2 Prioritizing the Candidates and Choosing an Active One . . 16
7.3 Encoding Candidates into SDP . . . . . . . . . . . . . . . 17 7.3 Encoding Candidates into SDP . . . . . . . . . . . . . . . 18
7.4 Forming Candidate Pairs . . . . . . . . . . . . . . . . . 19 7.4 Forming Candidate Pairs . . . . . . . . . . . . . . . . . 21
7.5 Ordering the Candidate Pairs . . . . . . . . . . . . . . . 22 7.5 Ordering the Candidate Pairs . . . . . . . . . . . . . . . 23
7.6 Performing the Connectivity Checks . . . . . . . . . . . . 23 7.6 Performing the Connectivity Checks . . . . . . . . . . . . 26
7.7 Sending a Binding Request for Connectivity Checks . . . . 27 7.7 Sending a Binding Request for Connectivity Checks . . . . 30
7.8 Receiving a Binding Request for Connectivity Checks . . . 29 7.8 Receiving a Binding Request for Connectivity Checks . . . 31
7.9 Promoting a Candidate to Active . . . . . . . . . . . . . 31 7.9 Promoting a Candidate to Active . . . . . . . . . . . . . 33
7.10 Learning New Candidates from Connectivity Checks . . . . 31 7.10 Learning New Candidates from Connectivity Checks . . . . 34
7.10.1 On Receipt of a Binding Request . . . . . . . . . . 32 7.10.1 On Receipt of a Binding Request . . . . . . . . . . 34
7.10.2 On Receipt of a Binding Response . . . . . . . . . . 35 7.10.2 On Receipt of a Binding Response . . . . . . . . . . 38
7.11 Subsequent Offer/Answer Exchanges . . . . . . . . . . . 37 7.11 Subsequent Offer/Answer Exchanges . . . . . . . . . . . 39
7.11.1 Sending of a Subsequent Offer . . . . . . . . . . . 37 7.11.1 Sending of a Subsequent Offer . . . . . . . . . . . 40
7.11.2 Receiving the Offer and Sending an Answer . . . . . 39 7.11.2 Receiving the Offer and Sending an Answer . . . . . 42
7.11.3 Receiving the Answer . . . . . . . . . . . . . . . . 41 7.11.3 Receiving the Answer . . . . . . . . . . . . . . . . 45
7.12 Binding Keepalives . . . . . . . . . . . . . . . . . . . 41 7.12 Binding Keepalives . . . . . . . . . . . . . . . . . . . 45
7.13 Sending Media . . . . . . . . . . . . . . . . . . . . . 42 7.13 Sending Media . . . . . . . . . . . . . . . . . . . . . 46
8. Guidelines for Usage with SIP . . . . . . . . . . . . . . . 43 8. Guidelines for Usage with SIP . . . . . . . . . . . . . . . 49
9. Interactions with Forking . . . . . . . . . . . . . . . . . 44 9. Interactions with Forking . . . . . . . . . . . . . . . . . 51
10. Interactions with Preconditions . . . . . . . . . . . . . . 45 10. Interactions with Preconditions . . . . . . . . . . . . . . 51
11. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 45 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 51
12. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . 68 11.1 Basic Example . . . . . . . . . . . . . . . . . . . . . 53
13. Security Considerations . . . . . . . . . . . . . . . . . . 69 11.2 Advanced Example . . . . . . . . . . . . . . . . . . . . 57
13.1 Attacks on Connectivity Checks . . . . . . . . . . . . . 69 12. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . 77
13.2 Attacks on Address Gathering . . . . . . . . . . . . . . 72 13. Security Considerations . . . . . . . . . . . . . . . . . . 79
13.3 Attacks on the Offer/Answer Exchanges . . . . . . . . . 73 13.1 Attacks on Connectivity Checks . . . . . . . . . . . . . 79
13.4 Insider Attacks . . . . . . . . . . . . . . . . . . . . 73 13.2 Attacks on Address Gathering . . . . . . . . . . . . . . 81
13.4.1 The Voice Hammer Attack . . . . . . . . . . . . . . 73 13.3 Attacks on the Offer/Answer Exchanges . . . . . . . . . 82
13.4.2 STUN Amplification Attack . . . . . . . . . . . . . 74 13.4 Insider Attacks . . . . . . . . . . . . . . . . . . . . 82
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 74 13.4.1 The Voice Hammer Attack . . . . . . . . . . . . . . 82
14.1 candidate Attribute . . . . . . . . . . . . . . . . . . 74 13.4.2 STUN Amplification Attack . . . . . . . . . . . . . 83
14.2 remote-candidate Attribute . . . . . . . . . . . . . . . 75 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 83
15. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 75 14.1 candidate Attribute . . . . . . . . . . . . . . . . . . 83
15.1 Problem Definition . . . . . . . . . . . . . . . . . . . 75 14.2 remote-candidate Attribute . . . . . . . . . . . . . . . 84
15.2 Exit Strategy . . . . . . . . . . . . . . . . . . . . . 76 14.3 ice-pwd Attribute . . . . . . . . . . . . . . . . . . . 84
15.3 Brittleness Introduced by ICE . . . . . . . . . . . . . 76 15. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 85
15.4 Requirements for a Long Term Solution . . . . . . . . . 77 15.1 Problem Definition . . . . . . . . . . . . . . . . . . . 85
15.5 Issues with Existing NAPT Boxes . . . . . . . . . . . . 78 15.2 Exit Strategy . . . . . . . . . . . . . . . . . . . . . 86
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 78 15.3 Brittleness Introduced by ICE . . . . . . . . . . . . . 86
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 78 15.4 Requirements for a Long Term Solution . . . . . . . . . 87
17.1 Normative References . . . . . . . . . . . . . . . . . . 78 15.5 Issues with Existing NAPT Boxes . . . . . . . . . . . . 87
17.2 Informative References . . . . . . . . . . . . . . . . . 79 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 88
Author's Address . . . . . . . . . . . . . . . . . . . . . . 81 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 88
Intellectual Property and Copyright Statements . . . . . . . 82 17.1 Normative References . . . . . . . . . . . . . . . . . . 88
17.2 Informative References . . . . . . . . . . . . . . . . . 89
Author's Address . . . . . . . . . . . . . . . . . . . . . . 91
Intellectual Property and Copyright Statements . . . . . . . 92
1. Introduction 1. Introduction
A multimedia session signaling protocol is a protocol that exchanges RFC 3264 [4] defines a two-phase exchange of Session Descrption
control messages between a pair of agents for the purposes of Protocol (SDP) messages [5] for the purposes of establishment of
establishing the flow of media traffic between them. This media flow multimedia sessions. This offer/answer mechanism is used by
is distinct from the flow of control messages, and may take a protocols such as the Session Initiation Protocol (SIP) [2].
different path through the network. Examples of such protocols are
the Session Initiation Protocol (SIP) [3], the Real Time Streaming
Protocol (RTSP) [17] and the International Telecommunications Union
(ITU) H.323.
These protocols, by nature of their design, are difficult to operate Protocols using offer/answer are difficult to operate through Network
through Network Address Translators (NAT). Because their purpose is Address Translators (NAT). Because their purpose is to establish a
to establish a flow of media packets, they tend to carry IP addresses flow of media packets, they tend to carry IP addresses within their
within their messages, which is known to be problematic through NAT messages, which is known to be problematic through NAT [17]. The
[18]. The protocols also seek to create a media flow directly protocols also seek to create a media flow directly between
between participants, so that there is no application layer participants, so that there is no application layer intermediary
intermediary between them. This is done to reduce media latency, between them. This is done to reduce media latency, decrease packet
decrease packet loss, and reduce the operational costs of deploying loss, and reduce the operational costs of deploying the application.
the application. However, this is difficult to accomplish through However, this is difficult to accomplish through NAT. A full
NAT. A full treatment of the reasons for this is beyond the scope of treatment of the reasons for this is beyond the scope of this
this specification. specification.
Numerous solutions have been proposed for allowing these protocols to Numerous solutions have been proposed for allowing these protocols to
operate through NAT. These include Application Layer Gateways operate through NAT. These include Application Layer Gateways
(ALGs), the Middlebox Control Protocol [20], Simple Traversal of UDP (ALGs), the Middlebox Control Protocol [19], Simple Traversal of UDP
through NAT (STUN) [1], Traversal Using Relay NAT [16], and Realm through NAT (STUN) [16] and its revision [13], the STUN Relay Usage
Specific IP [21] [22] along with session description extensions [14], and Realm Specific IP [20] [21] along with session description
needed to make them work, such as the Session Description Protocol extensions needed to make them work, such as the Session Description
(SDP) [7] attribute for the Real Time Control Protocol (RTCP) [2]. Protocol (SDP) [5] attribute for the Real Time Control Protocol
Unfortunately, these techniques all have pros and cons which make (RTCP) [1]. Unfortunately, these techniques all have pros and cons
each one optimal in some network topologies, but a poor choice in which make each one optimal in some network topologies, but a poor
others. The result is that administrators and implementors are choice in others. The result is that administrators and implementors
making assumptions about the topologies of the networks in which are making assumptions about the topologies of the networks in which
their solutions will be deployed. This introduces complexity and their solutions will be deployed. This introduces complexity and
brittleness into the system. What is needed is a single solution brittleness into the system. What is needed is a single solution
which is flexible enough to work well in all situations. which is flexible enough to work well in all situations.
This specification provides that solution for media streams This specification provides that solution for media streams
established by signaling protocols based on the offer-answer model, established by signaling protocols based on the offer-answer model.
RFC 3264 [5]. It is called Interactive Connectivity Establishment, It is called Interactive Connectivity Establishment, or ICE. ICE
or ICE. ICE makes use of STUN and TURN, but uses them in a specific makes use of STUN and its relay extension, commonly called TURN, but
methodology which avoids many of the pitfalls of using any one alone. uses them in a specific methodology which avoids many of the pitfalls
of using any one alone.
2. Terminology 2. Terminology
Several new terms are introduced in this specification: Several new terms are introduced in this specification:
Agent: As defined in RFC 3264, an agent is the protocol Agent: As defined in RFC 3264, an agent is the protocol
implementation involved in the offer/answer exchange. There are implementation involved in the offer/answer exchange. There are
two agents involved in an offer/answer exchange. two agents involved in an offer/answer exchange.
Peer: From the perspective of one of the agents in a session, its Peer: From the perspective of one of the agents in a session, its
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.
Local Transport Address: A local transport address is a transport Local Transport Address: A local transport address is a transport
address that has been allocated from the operating system on the address that has been allocated from the operating system on the
host. This includes transport addresses obtained through Virtual host. This includes transport addresses obtained through Virtual
Private Networks (VPNs) and transport addresses obtained through Private Networks (VPNs) and transport addresses obtained through
Realm Specific IP (RSIP) [21] (which lives at the operating system Realm Specific IP (RSIP) [20] (which lives at the operating system
level). Transport addresses are typically obtained by binding to level). Transport addresses are typically obtained by binding to
an interface. an interface.
m/c line: The media and connection lines in the SDP, which together m/c line: The media and connection lines in the SDP, which together
hold the transport address used for the receipt of media. hold the transport address used for the receipt of media.
Derived Transport Address: A derived transport address is a transport Derived Transport Address: A derived transport address is a transport
address which is derived from a local transport address. The address which is derived from a local transport address. The
derived transport address is related to the associated local derived transport address is related to the associated local
transport address in that packets sent to the derived transport transport address in that packets sent to the derived transport
address are received on the socket bound to its associated local address are received on the socket bound to its associated local
transport address. Derived addresses are obtained using protocols transport address. Derived addresses are obtained using protocols
like STUN and TURN, and more generally, any UNSAF protocol [23]. like STUN, and more generally, any UNSAF protocol [22].
Reflexive Transport Address: As defined in [13], a transport address
learned by a client which identifies that client as seen by
another host on an IP network, typically a STUN server. When
there is an intervening NAT between the client and the other host,
the reflexive transport address represents the binding allocated
to the client on the public side of the NAT. Reflexive transport
addresses are learned from the MAPPED-ADDRESS attribute in STUN
Binding Responses and Allocate Responses [14], and are a type of
derived transport address.
Server Reflexive Transport Address: A server reflexive transport
address is a reflexive address that is reflected off of a server,
distinct from the peer, whose address is configured or learned by
the client prior to an offer/answer exchange.
Peer Reflexive Transport Address: A peer reflexive transport address
is a reflexive address that is reflected off of the peer. Peer
reflexive transport addresses are learned by connectivity checks.
Relayed Transport Address: A transport address that terminates on a
server, and is forwarded towards the client. The STUN Allocate
Request can be used to obtain a relayed transport address, for
example.
Associated Local Transport Address: When a peer sends a packet to a Associated Local Transport Address: When a peer sends a packet to a
transport address, the associated local transport address is the transport address, the associated local transport address is the
local transport address at which those packets will actually local transport address at which those packets will actually
arrive. For a local transport address, its associated local arrive. For a local transport address, its associated local
transport address is the same as the local transport address transport address is the same as the local transport address
itself. For STUN derived and TURN derived transport addresses, itself. For reflexive and relayed transport addresses, however,
however, they are not the same. The associated local transport they are not the same. The associated local transport address is
address is the one from which the STUN or TURN transport was the one from which the reflexive or relayed transport was derived.
derived.
Peer Derived Transport Address: A peer derived transport address is a
derived transport address learned from a STUN server running
within a peer in a media session.
TURN Derived Transport Address: A derived transport address obtained
from a TURN server.
STUN Derived Transport Address: A derived transport address obtained
from a STUN server whose address has been provisioned or
discovered by the UA. This, by definition, excludes Peer Derived
Transport Addresses.
Candidate: A sequence of transport addresses that form an atomic set Candidate: A sequence of transport addresses that form an atomic set
for usage with a particular media session. Here, atomic means for usage with a particular media session. Here, atomic means
that all of transport addresses in the candidate need to work that all of transport addresses in the candidate need to work
before the candidate will be used for actual media transport. In before the candidate will be used for actual media transport. In
the case of RTP, there can be one or more transport addresses per the case of RTP, there can be one or more transport addresses per
candidate. In the most common case, there are two - one for RTP, candidate. In the most common case, there are two - one for RTP,
and another for RTCP. If the agent doesn't use RTCP, there would and another for RTCP. If the agent doesn't use RTCP, there would
be just one. If Generic Forward Error Correction (FEC) [19] is in be just one. If Generic Forward Error Correction (FEC) [18] is in
use, there may be more than two. The transport addresses that use, there may be more than two. The transport addresses that
compose a candidate are all of the same type - local, STUN compose a candidate are all of the same type - local, server
derived, TURN derived or peer derived. reflexive, peer reflexive or relayed.
Local Candidate: A candidate whose transport addresses are local Local Candidate: A candidate whose transport addresses are local
transport addresses. transport addresses.
STUN Candidate: A candidate whose transport addresses are STUN Server Reflexive Candidate: A candidate whose transport addresses are
derived transport addresses. server reflexive transport addresses.
TURN Candidate: A candidate whose transport addresses are TURN Peer Reflexive Candidate: A candidate whose transport addresses are
derived transport addresses. peer reflexive transport addresses.
Peer Derived Candidate: A candidate whose transport addresses are Relayed Candidate: A candidate whose transport addresses are relayed
peer derived transport addresses. transport addresses.
Generating Candidate: The candidate from which a peer derived Generating Candidate: The candidate from which a peer reflexive
candidate is derived. candidate is derived.
Active Candidate: The candidate that is in use for exchange of media. Active Candidate: The candidate that is in use for exchange of media.
This is the one that an agent places in the m/c line of an offer This is the one that an agent places in the m/c line of an offer
or answer. or answer.
Candidate ID: An identifier for a candidate. Candidate ID: An identifier for a candidate.
Component: When a media stream, and as a consequence, its candidate, Component: When a media stream, and as a consequence, its candidate,
require several IP addresses and ports to work atomically, each of require several IP addresses and ports to work atomically, each of
skipping to change at page 8, line 22 skipping to change at page 9, line 5
if, when they exchange the addresses each has in that realm, they are if, when they exchange the addresses each has in that realm, they are
able to send packets to each other. This includes IPv6 and IPv4 able to send packets to each other. This includes IPv6 and IPv4
realms, which actually use different address spaces, in addition to realms, which actually use different address spaces, in addition to
private networks connected to the public Internet through NAT. private networks connected to the public Internet through NAT.
The key assumption in ICE is that a client cannot know, apriori, The key assumption in ICE is that a client cannot know, apriori,
which address realms it shares with any peer it may wish to which address realms it shares with any peer it may wish to
communicate with. Therefore, in order to communicate, it has to try communicate with. Therefore, in order to communicate, it has to try
connecting to addresses in all of the realms. connecting to addresses in all of the realms.
Agent A TURN,STUN Servers Agent B Agent A STUN Servers Agent B
|(1) Gather Addresses | | |(1) Gather Addresses | |
|-------------------->| | |-------------------->| |
|(2) Offer | | |(2) Offer | |
|------------------------------------------>| |------------------------------------------>|
| |(3) Gather Addresses | | |(3) Gather Addresses |
| |<--------------------| | |<--------------------|
|(4) Answer | | |(4) Answer | |
|<------------------------------------------| |<------------------------------------------|
|(5) STUN Check | | |(5) STUN Check | |
|<------------------------------------------| |<------------------------------------------|
|(6) STUN Check | | |(6) STUN Check | |
|------------------------------------------>| |------------------------------------------>|
|(7) Offer | | |(7) Media | |
|------------------------------------------>|
|(8) Answer | |
|<------------------------------------------|
|(9) Media | |
|<------------------------------------------| |<------------------------------------------|
|(10) Media | | |(8) Media | |
|------------------------------------------>|
|(9) Offer | |
|------------------------------------------>| |------------------------------------------>|
|(10) Answer | |
|<------------------------------------------|
Figure 1 Figure 1
The basic flow of operation for ICE is shown in Figure 1. Before the The basic flow of operation for ICE is shown in Figure 1. Before the
offerer establishes a session, it obtains local transport addresses offerer establishes a session, it obtains local transport addresses
from its operating system on as many interfaces as it has access to. from its operating system on as many interfaces as it has access to.
These interfaces can include IPv4 and IPv6 interfaces, in addition to These interfaces can include IPv4 and IPv6 interfaces, in addition to
Virtual Private Network (VPN) interfaces or ones associated with Virtual Private Network (VPN) interfaces or ones associated with
RSIP. It then obtains transport addresses for the media from each RSIP. It then obtains transport addresses for the media from each
interface. Though the ICE framework can support any type of interface. Though ICE can support any type of transport protocol,
transport protocol, this specification only defines mechanisms for this specification only defines mechanisms for UDP. In addition, the
UDP. In addition, the agent obtains derived transport addresses from agent obtains server reflexive and relayed transport addresses.
each local transport address using protocols such as STUN and TURN. These are usually obtained through a single STUN Allocate request,
These are paced at a fixed rate in order to limit network load and which provides both. These requests are paced at a fixed rate in
avoid NAT overload. The local and derived transport addresses are order to limit network load and avoid NAT overload. The local,
formed into candidates, each of which represents a possible set of server reflexive and relayed transport addresses are formed into
transport addresses that might be viable for a media stream. candidates, each of which represents a possible set of transport
addresses that might be viable for a media stream.
Each candidate is listed in a set of a=candidate attributes in the Each candidate is listed in a set of a=candidate attributes in the
offer. Each candidate is given a priority. Priority is a matter of offer. Each candidate is given a priority. Priority is a matter of
local policy, but typically, lowest priority would be given to local policy, but typically, lowest priority would be given to
transport addresses learned from a TURN server (i.e., TURN derived relayed transport addresses. Each candidate is also assigned a
transport addresses). Each candidate is also assigned a distinct ID, distinct ID, called a candidate ID.
called a candidate ID.
The agent will choose one of its candidates as its active candidate The agent will choose one of its candidates as its active candidate
for inclusion in the connection and media lines in the offer. Media for inclusion in the connection and media lines in the offer. Media
can be sent to this candidate immediately following its validation. can be sent to this candidate immediately following its validation.
Media is not sent without validation in order to avoid denial-of- Media can also be sent to a candidate that is not active but has been
service attacks. In particular, without ICE, an offerer can send an validated. Media is not sent without validation in order to avoid
offer to another agent, and list the IP address and port of a target denial-of-service attacks. In particular, without ICE, an offerer
in the offer. If the agent is an automata that answers a call can send an offer to another agent, and list the IP address and port
automatically, it will do so and then proceed to send media to the of a target in the offer. If the agent is an automata that answers a
target. This provides substantial packet amplifications. ICE fixes call automatically, it will do so and then proceed to send media to
this by using STUN-based validation of addresses. the target. This provides substantial packet amplifications. ICE
fixes this by requiring that an agent never send media packets unless
it has sent a STUN message towards the target of the RTP packets, and
received a reply from that target Section 7.13.
The offer is then sent to the answerer. This specification does not The offer is then sent to the answerer. This specification does not
address the issue of how the signaling messages themselves traverse address the issue of how the signaling messages themselves traverse
NAT. It is assumed that signaling protocol specific mechanisms are NAT. It is assumed that signaling protocol specific mechanisms are
used for that purpose. The answerer follows a similar process as the used for that purpose. The answerer follows a similar process as the
offerer followed; it obtains addresses from local interfaces, obtains offerer followed; it obtains addresses from local interfaces, obtains
derived transport addresses from those, and then groups them into derived transport addresses from those, and then groups them into
candidates for inclusion in a=candidate attributes in the answer. It candidates for inclusion in a=candidate attributes in the answer. It
picks one candidate as its active candidate and places it into the picks one candidate as its active candidate and places it into the
m/c line in the answer. m/c line in the answer.
skipping to change at page 10, line 9 skipping to change at page 10, line 42
of this list, beginning a connectivity check for that transport of this list, beginning a connectivity check for that transport
address pair. At a fixed interval, checks for the next transport address pair. At a fixed interval, checks for the next transport
address on the list begin. This results in a pacing of the address on the list begin. This results in a pacing of the
connectivity checks. These connectivity checks are performed through connectivity checks. These connectivity checks are performed through
peer-to-peer STUN requests, sent from one agent to the other. In peer-to-peer STUN requests, sent from one agent to the other. In
addition to pacing the checks out at regular intervals, the offerer addition to pacing the checks out at regular intervals, the offerer
will generate a connectivity check for a transport address pair when will generate a connectivity check for a transport address pair when
it receives one from its peer. As soon as the active candidate has it receives one from its peer. As soon as the active candidate has
been verified by the STUN checks, media can begin to flow. Once a been verified by the STUN checks, media can begin to flow. Once a
higher priority candidate has been verified by the offerer, it ceases higher priority candidate has been verified by the offerer, it ceases
additional connectivity checks, and sends an updated offer which additional connectivity checks, begins using that candidate for
promotes this higher priority candidate to the m/c-line. That media, and sends an updated offer which promotes this higher priority
candidate is also listed in a=candidate attributes, resulting in candidate to the m/c-line. That candidate is also listed in
periodic STUN keepalives through the duration of the media session. a=candidate attributes, resulting in periodic STUN keepalives through
the duration of the media session.
If an agent receives a STUN connectivity check with a new source IP If an agent receives a STUN connectivity check with a new source IP
address and port, or a response to such a check with a new IP address address and port, or a response to such a check with a new IP address
and port indicated in the MAPPED-ADDRESS attribute, this new address and port indicated in the MAPPED-ADDRESS attribute, this new address
might be a viable candidate for the receipt of media. This happens might be a viable candidate for the receipt of media. This happens
when there is a symmetric NAT between the agents. In such a case, when there is a NAT with an address dependent or address and port
dependent mapping property [37] between the agents. In such a case,
the agents algorithmically construct a new candidate. Like other the agents algorithmically construct a new candidate. Like other
candidates, connectivity checks begin for it, and if they succeed, candidates, connectivity checks begin for it, and if they succeed,
its transport addresses can be used for receipt of media by promoting its transport addresses can be used for receipt of media by promoting
it to the m/c-line. it to the m/c-line.
The gathering of addresses and connectivity checks take time. As a The gathering of addresses and connectivity checks take time. As a
consequence, in order to have no impact on the call setup time or consequence, in order to have minimal impact on the call setup time
post-pickup delay for SIP, these offer/answer exchanges and checks or post-pickup delay for SIP, these offer/answer exchanges and checks
happen while the call is ringing. happen while the call is ringing.
4. Sending the Initial Offer 4. Sending the Initial Offer
When an agent wishes to begin a session by sending an initial offer, When an agent wishes to begin a session by sending an initial offer,
it starts by gathering transport addresses, as described in it starts by gathering transport addresses, as described in
Section 7.1. This will produce a set of candidates, including local Section 7.1. This will produce a set of candidates, including local
ones, STUN-derived ones, and TURN-derived ones. ones, server reflexive ones, and relayed ones.
This process of gathering candidates can actually happen at any time This process of gathering candidates can actually happen at any time
before sending the initial offer. A agent can pre-gather transport before sending the initial offer. A agent can pre-gather transport
addresses, using a user interface cue (such as picking up the phone, addresses, using a user interface cue (such as picking up the phone,
or entry into an address book) as a hint that communications is or entry into an address book) as a hint that communications is
imminent. Doing so eliminates any additional perceivable call setup imminent. Doing so eliminates any additional perceivable call setup
delays due to address gathering. delays due to address gathering.
When it comes time to offer communications, the agent determines a When it comes time to offer communications, the agent determines a
priority for each candidate and identifies the active candidate that priority for each candidate and identifies the active candidate that
will be used for receipt of media, as described in Section 7.2. will be used for receipt of media, as described in Section 7.2.
The next step is to construct the offer message. For each media The next step is to construct the offer message. For each media
stream, it places its candidates into a=candidate attributes in the stream, it places its candidates into a=candidate attributes in the
offer and puts its active candidate into the m/c line. The process offer and puts its active candidate into the m/c line. The process
for doing this is described in Section 7.3. The offer is then sent. for doing this is described in Section 7.3. The offer is then sent.
5. Receipt of the Offer and Generation of the Answer 5. Receipt of the Offer and Generation of the Answer
Upon receipt of the offer message, the agent checks if the offer Upon receipt of the offer message, the agent checks if the offer
contains any a=candidate attributes. If it does, the offerer contains any a=candidate attributes. If the offer does, the offerer
supports ICE. In that case, it starts gathering candidates, as supports ICE. In that case, it starts gathering candidates, as
described in Section 7.1, and prioritizes them as described in described in Section 7.1, and prioritizes them as described in
Section 7.2. This processing is done immediately on receipt of the Section 7.2. This processing is done immediately on receipt of the
offer, to prepare for the case where the user should accept the call, offer, to prepare for the case where the user should accept the call,
or early media needs to be generated. By gathering candidates (and or early media needs to be generated. By gathering candidates (and
performing connectivity checks) while the user is being alerted to performing connectivity checks) while the user is being alerted to
the request for communications, session establishment delays due to the request for communications, session establishment delays are
that gathering can be eliminated. reduced.
The agent then constructs its answer, encoding its candidates into The agent then constructs its answer, encoding its candidates into
a=candidate attributes and including the active one in the m/c-line, a=candidate attributes and including the active one in the m/c-line,
as described in Section 7.3. The agent then forms candidate pairs as as described in Section 7.3. The agent then forms candidate pairs as
described in Section 7.4. These are ordered as described in described in Section 7.4. These are ordered as described in
Section 7.5. The agent then begins connectivity checks, as described Section 7.5. The agent then begins connectivity checks, as described
in Section 7.6. It follows the logic in Section 7.10 on receipt of in Section 7.6. It follows the logic in Section 7.10 on receipt of
Binding Requests and responses to learn new candidates from the Binding Requests and responses to learn new candidates from the
checks themselves. checks themselves.
skipping to change at page 11, line 41 skipping to change at page 12, line 28
There are two possible cases for processing of the answer. If the There are two possible cases for processing of the answer. If the
answerer did not support ICE, the answer will not contain any answerer did not support ICE, the answer will not contain any
a=candidate attributes. As a result, the offerer knows that it a=candidate attributes. As a result, the offerer knows that it
cannot perform its connectivity checks. In this case, it proceeds cannot perform its connectivity checks. In this case, it proceeds
with normal media processing as if ICE was not in use. The with normal media processing as if ICE was not in use. The
procedures for sending media, described in Section 7.13, MUST be procedures for sending media, described in Section 7.13, MUST be
followed however. followed however.
If the answer contains candidates, it implies that the answerer If the answer contains candidates, it implies that the answerer
supports ICE. The agent then forms candidate pairs as described in supports ICE. The offerer then forms candidate pairs as described in
Section 7.4. These are ordered as described in Section 7.5. The Section 7.4. These are ordered as described in Section 7.5. The
agent then begins connectivity checks, as described in Section 7.6. agent then begins connectivity checks, as described in Section 7.6.
It follows the logic in Section 7.10 on receipt of Binding Requests It follows the logic in Section 7.10 on receipt of Binding Requests
and responses to learn new candidates from the checks themselves. and responses to learn new candidates from the checks themselves.
Transmission of media is performed according to the procedures in Transmission of media is performed according to the procedures in
Section 7.13. Section 7.13.
7. Common Procedures 7. Common Procedures
skipping to change at page 12, line 20 skipping to change at page 13, line 7
(Section 4). For answerers, it occurs before sending an answer (Section 4). For answerers, it occurs before sending an answer
(Section 5). (Section 5).
Each candidate has one or more components, each of which is Each candidate has one or more components, each of which is
associated with a sequence number, starting at 1 for the first associated with a sequence number, starting at 1 for the first
component of each candidate, and incrementing by 1 for each component of each candidate, and incrementing by 1 for each
additional component within that candidate. These components additional component within that candidate. These components
represent a set of transport addresses for which connectivity must be represent a set of transport addresses for which connectivity must be
validated. For a particular media stream, all of the candidates validated. For a particular media stream, all of the candidates
SHOULD have the same number of components. The number of components SHOULD have the same number of components. The number of components
that are needed are a function of the type of media stream. that are needed are a function of the type of media stream. All of
the components in a candidate MUST be of the same type - server
reflexive, relayed, or local, and obtained from the same server in
the case of server reflexive or relayed candidates. For local
candidates, each component MUST be obtained from the same interface.
For traditional RTP-based media streams, it is RECOMMENDED that there For traditional RTP-based media streams, it is RECOMMENDED that there
be two components per candidate - one for RTP and one for RTCP. The be two components per candidate - one for RTP and one for RTCP. The
component with the component ID of 1 MUST be RTP, and the one with component with the component ID of 1 MUST be RTP, and the one with
component ID of 2 MUST be RTCP. If an agent doesn't implement RTCP, component ID of 2 MUST be RTCP. If an agent doesn't implement RTCP,
it SHOULD have a single component for the RTP stream (which will have it SHOULD have a single component for the RTP stream (which will have
a component ID of 1 by definition). Each component of a candidate a component ID of 1 by definition). Each component of a candidate
has a single transport address. has a single transport address.
The first step is to gather local candidates. Local candidates are The first step is to gather local candidates. Local candidates are
skipping to change at page 13, line 6 skipping to change at page 13, line 44
for each UDP stream , requiring K*N local transport addresses. for each UDP stream , requiring K*N local transport addresses.
Once the agent has obtained local candidates, it obtains candidates Once the agent has obtained local candidates, it obtains candidates
with derived transport addresses. The process for gathering derived with derived transport addresses. The process for gathering derived
candidates depends on the transport protocol. Procedures are candidates depends on the transport protocol. Procedures are
specified here for UDP. Extensions to ICE that define procedures for specified here for UDP. Extensions to ICE that define procedures for
other transport protocols MUST specify how derived transport other transport protocols MUST specify how derived transport
addresses are gathered. addresses are gathered.
Agents which serve end users directly, such as softphones, Agents which serve end users directly, such as softphones,
hardphones, terminal adapters and so on, MUST implement STUN and hardphones, terminal adapters and so on, MUST implement the STUN
SHOULD use it to obtain STUN candidates. These devices SHOULD Binding Discovery usage and SHOULD use it to obtain server reflexive
implement and SHOULD use TURN to obtain TURN candidates. They MAY candidates. These devices SHOULD implement the STUN Relay usage, and
implement and MAY use other protocols that provide derived transport SHOULD use its Allocate request to obtain both server reflexive and
addresses, such as TEREDO [31]. Usage of STUN and TURN is at SHOULD relayed candidates. They MAY implement and MAY use other protocols
strength to allow for provider variation. If it is not to be used, that provide server reflexive or relayed transport addresses, such as
it is RECOMMENDED that it be implemented and just disabled through TEREDO [33].
configuration, so that it can re-enabled through configuration if
conditions change in the future. The requirement to use the relay Usage is at SHOULD strength to allow
for provider variation. If it is not to be used, it is RECOMMENDED
that it be implemented and just disabled through configuration, so
that it can re-enabled through configuration if conditions change in
the future.
Agents which represent network servers under the control of a service Agents which represent network servers under the control of a service
provider, such as gateways to the telephone network, media servers, provider, such as gateways to the telephone network, media servers,
or conferencing servers that are targeted at deployment only in or conferencing servers that are targeted at deployment only in
networks with public IP addresses MAY use STUN, TURN or other similar networks with public IP addresses MAY use the STUN Binding Discovery
protocols to obtain candidates. usage and relay usage, or other similar protocols to obtain
candidates.
Why would these types of endpoints even bother to implement ICE? Why would these types of endpoints even bother to implement ICE?
The answer is that such an implementation greatly facilitates NAT The answer is that such an implementation greatly facilitates NAT
traversal for clients that connect to it. The ability to process traversal for clients that connect to it. The ability to process
STUN connectivity checks allows for clients to obtain peer-derived STUN connectivity checks allows for clients to obtain peer
transport addresses that can be used by the network server to reflexive transport addresses that can be used by the network
reach them without a relay, even through symmetric NAT. server to reach them without a relay, even through NATs with
Furthermore, implementation of the STUN connectivity checks allows restrictive mapping and filtering policies. Furthermore,
for NAT bindings along the way to be kept open. ICE also provides implementation of the STUN connectivity checks allows for NAT
bindings along the way to be kept open. ICE also provides
numerous security properties that are independent of NAT numerous security properties that are independent of NAT
traversal, and would benefit any multimedia endpoint. See traversal, and would benefit any multimedia endpoint. See
Section 13 for a discussion on these benefits. Section 13 for a discussion on these benefits.
Obtaining STUN, TURN and other derived candidates requires Obtaining derived candidates requires transmission of packets which
transmission of packets which have the effect of creating bindings on have the effect of creating bindings on NAT devices between the
NAT devices between the client and the STUN or TURN servers. client and the STUN servers. Experience has shown that many NAT
Experience has shown that many NAT devices have upper limits on the devices have upper limits on the rate at which they will create new
rate at which they will create new bindings. Furthermore, bindings. Furthermore, transmission of these packets on the network
transmission of these packets on the network makes use of bandwidth makes use of bandwidth and needs to be rate limited by the agent. As
and needs to be rate limited by the agent. As a consequence, a a consequence, a client SHOULD pace its STUN transactions, such that
client SHOULD pace its STUN and TURN transactions, such that the the start of each new transaction occurs at least Ta seconds after
start of each new transaction occurs at least Ta seconds after the the start of the previous transaction. The value of Ta SHOULD be
start of the previous transaction. The value of Ta SHOULD be
configurable, and SHOULD have a default of 50ms. Note that this configurable, and SHOULD have a default of 50ms. Note that this
pacing applies only to the start of a new transaction; pacing of pacing applies only to the start of a new transaction; pacing of
retransmissions within a STUN or TURN transaction is governed by the retransmissions within a STUN transaction is governed by the
retransmission rules defined in those protocols. retransmission rules defined by STUN.
To obtain STUN candidates, the client takes a local UDP candidate, Derived candidates can be obtained from the STUN Binding Discovery
and for each configured STUN server, produces a STUN candidate. It usage or the STUN Relay usage. The latter is preferred since it will
is anticipated that clients may have a multiplicity of STUN servers provide the client with both a server reflexive and a relayed
that it discovers or is configured with in network environments where transport address with a single transaction. It is possible that
there are multiple layers of NAT. To produce the STUN candidate from some STUN servers will only support the Relay usage or only the
the local candidate, it follows the procedures of Section 9 of RFC Binding Discovery usage, in which case a client might be configured
3489 for each local transport address in the local candidate. It with different servers depending on the usage.
obtains a shared secret from the STUN server and then initiates a
Binding Request transaction from each local transport address to that
server. The Binding Response will provide the client with its STUN
derived transport address in the MAPPED-ADDRESS attribute. If the
client had K local candidates, this will produce S*K STUN candidates,
where S is the number of STUN servers.
It is anticipated that clients may have a multiplicity of TURN To obtain both server reflexive and relayed candidates using the STUN
servers configured or discovered in network environments where there Relay Usage, the client takes a local UDP candidate, and for each
are multiple layers of NAT, and that layering is known to the configured STUN server, produces both candidates. It is anticipated
provider of the client. To obtain TURN candidates, for each that clients may have a multiplicity of STUN servers configured or
configured TURN server, the client initiates an Allocate Request discovered in network environments where there are multiple layers of
transaction using the procedures of Section 8 of [16] from each NAT, and that layering is known to the provider of the client. To
transport address of a particular local candidate. The Allocate obtain these candidates, for each configured STUN server, the client
Response will provide the client with its TURN derived transport initiates an Allocate Request transaction using the procedures of
address in the MAPPED-ADDRESS attribute. Once the TURN allocations Section 8.1.2 of [14] from each transport address of a particular
against a particular TURN server succeed from all of the transport local candidate. The Allocate Response will provide the client with
addresses in a particular local candidate, the client SHOULD NOT its server reflexive transport address in the MAPPED-ADDRESS
attempt any further TURN allocations to that particular server from attribute and its relayed transport address in the RELAY-ADDRESS
the transport addresses in any other local candidates. This is to attribute. Once the Allocate requests have given a client a relayed
reduce the number of bindings allocated from the NATs. Only a single transport address for all transport addresses in a relayed candidate,
TURN candidate is needed from a particular TURN server. The order in there is no reason for a client to obtain further relayed candidates
which local candidates are tried against the TURN server is a matter through the same STUN server. Thus, if there are other local
of local policy. candidates from which the client has not yet obtained relayed
transport address, the client SHOULD NOT bother to obtain them.
Instead, it SHOULD use the STUN Binding Discovery usage and obtain
just server reflexive addresses from that STUN server. The order in
which local candidates are tried against the STUN server to obtain
relayed candidates is a matter of local policy.
Since a client will pace its STUN and TURN allocations at a rate of To obtain server reflexice candidates using the STUN Binding
one new transaction every Ta seconds, it will take a certain amount Discovery usage, the client takes a local UDP candidate, and for each
of time for these allocations to occur. It is RECOMMENDED that configured STUN server, produces a server reflexive candidate. To
implementations have a configurable upper bound on the total number produce the server reflexive candidate from the local candidate, it
of such allocations they will perform before generation of their follows the procedures of Section XX of [13] for each local transport
offer or answer. Any allocations not completed at that point SHOULD address in the local candidate. The Binding Response will provide
be abandoned, but MAY continue and be used in an updated offer once the client with its server reflexive transport address in the MAPPED-
they complete. A default value of 10 is RECOMMENDED. Since the ADDRESS attribute. If the client had K local candidates, this will
produce S*K server reflexive candidates, where S is the number of
STUN servers.
Since a client will pace its STUN transactions (both Binding and
Allocate requests) at a total rate of one new transaction every Ta
seconds, it will take a certain amount of time to complete the
address gathering phase. It is RECOMMENDED that implementations have
a configurable upper bound on the total amount of time allotted to
address gathering. Any transactions not completed at that point
SHOULD be abandoned, but MAY continue and be used in an updated offer
once they complete. A default value of 5s is RECOMMENDED. Since the
total number of allocations that could be done (based on the number total number of allocations that could be done (based on the number
of STUN servers, TURN servers and local interfaces) might exceed this of STUN servers and local interfaces) might exceed this value,
value, clients SHOULD prioritize their allocations and perform higher clients SHOULD prioritize their local candidates and STUN servers,
priority ones first. It is RECOMMENDED that STUN allocations be performing transactions from the highest priority local candidates to
prioritized over TURN allocations. the highest priority STUN servers first. A STUN server would
typically be higher priority if it supports the STUN Relay Usage,
since such a server provides two transport addresses with one
transaction.
Once the allocations are complete, any redundant candidates are Once the allocations are complete, any redundant candidates are
discarded. A candidate is redundant if its transport addresses for discarded. Candidate A is redundant with candidate B if the
each component match the transport addresses for each component of transport addresses for each component of each component match, and
another candidate. each component of their associated local candidates match. For
example, consider a set of candidates with a single component. One
candidate is a local candidate, and its one component has a transport
address of 10.0.1.1:4458. A reflexive transport address is derived
from this local transport address, producing a 10.0.1.1:4458. These
two candidates are identical, and also have identical associated
local transport addresses, so they are redundant. However, in a more
complicated case, consider a multi-homed host, with one interface at
192.168.1.1 and another at 10.0.1.1. The 192.168 network is natted,
with its "public" side in another net-10 private network. The client
obtains two local candidates, A and B, with transport addresses of
192.168.1.1:2376 and 10.0.1.1:7266 respectively. A server reflexive
transport address is derived from A through a STUN query, and it
happens to produce 10.0.1.1:7266. Call this candidate C. Candidate C
is not redundant with candidate B, since they have different
associated local transport addresses.
7.2 Prioritizing the Candidates and Choosing an Active One 7.2 Prioritizing the Candidates and Choosing an Active One
The prioritization process takes the set of candidates and associates The prioritization process takes the set of candidates and associates
each with a priority. This priority reflects the desire that the each with a priority. This priority reflects the desire that the
agent has to receive media on that address, and is assigned as a agent has to receive media at that candidate, and is assigned as a
value from 0 to 1 (1 being most preferred). Priorities are ordinal, value from 0 to 1 (1 being most preferred). Priorities are ordinal,
so that their significance is only meaningful relative to other so that their significance is only meaningful relative to other
candidates from that agent for a particular media stream. Candidates candidates from that agent for a particular media stream. Candidates
MAY have the same priority. However, it is RECOMMENDED that each MAY have the same priority. However, it is RECOMMENDED that each
candidate have a distinct priority. Doing so improves the efficiency candidate have a distinct priority. Doing so improves the efficiency
of ICE. of ICE.
This specification makes no normative recommendations on how the This specification makes no normative statements on how the
prioritization is done. However, some useful guidelines are prioritization is done. However, some useful guidelines are
suggested on how such a prioritization can be determined. suggested on how such a prioritization can be determined.
One criteria for choosing one candidate over another is whether or One criteria for choosing one candidate over another is whether or
not that candidate involves the use of a relay. That is, if media is not that candidate involves the use of an intermediary. That is, if
sent to that candidate, will the media first transit a relay before media is sent to that candidate, will the media first transit an
being received. TURN candidates make use of relays (the TURN intermediate server before being received. Relayed candidates are
server), as do any local candidates associated with a VPN server. clearly one type of candidates that involve an intermediary. Another
When media is transited through a relay, it can increase the latency are local candidates associated with a VPN server. When media is
transited through an intermediary, it can increase the latency
between transmission and reception. It can increase the packet between transmission and reception. It can increase the packet
losses, because of the additional router hops that may be taken. It losses, because of the additional router hops that may be taken. It
may increase the cost of providing service, since media will be may increase the cost of providing service, since media will be
routed in and right back out of a relay run by the provider. If routed in and right back out of an intermediary run by the provider.
these concerns are important, candidates with this property can be If these concerns are important, candidates with this property can be
listed with lower priority. listed with lower priority.
Another criteria for choosing one candidate over another is IP Another criteria for choosing one candidate over another is IP
address family. ICE works with both IPv4 and IPv6. It therefore address family. ICE works with both IPv4 and IPv6. It therefore
provides a transition mechanism that allows dual-stack hosts to provides a transition mechanism that allows dual-stack hosts to
prefer connectivity over IPv6, but to fall back to IPv4 in case the prefer connectivity over IPv6, but to fall back to IPv4 in case the
v6 networks are disconnected (due, for example, to a failure in a v6 networks are disconnected (due, for example, to a failure in a
6to4 relay) [26]. It can also help with hosts that have both a 6to4 relay) [25]. It can also help with hosts that have both a
native IPv6 address and a 6to4 address. In such a case, higher native IPv6 address and a 6to4 address. In such a case, higher
priority could be afforded to the native v6 address, followed by the priority could be afforded to the native v6 address, followed by the
6to4 address, followed by a native v4 address. This allows a site to 6to4 address, followed by a native v4 address. This allows a site to
obtain and begin using native v6 addresss immediately, yet still obtain and begin using native v6 addresses immediately, yet still
fallback to 6to4 addresses when communicating with agents in other fallback to 6to4 addresses when communicating with agents in other
sites that do not yet have native v6 connectivity. sites that do not yet have native v6 connectivity.
Another criteria for choosing one candidate over another is security. Another criteria for choosing one candidate over another is security.
If a user is a telecommuter, and therefore connected to their If a user is a telecommuter, and therefore connected to their
corporate network and a local home network, they may prefer their corporate network and a local home network, they may prefer their
voice traffic to be routed over the VPN in order to keep it on the voice traffic to be routed over the VPN in order to keep it on the
corporate network when communicating within the enterprise, but use corporate network when communicating within the enterprise, but use
the local network when communicating with users outside of the the local network when communicating with users outside of the
enterprise. enterprise.
Another criteria for choosing one address over another is topological Another criteria for choosing one address over another is topological
awareness. This is most useful for candidates which make use of awareness. This is most useful for candidates that make use of
relays (including TURN and VPN). In those cases, if an agent has relays. In those cases, if an agent has preconfigured or dynamically
preconfigured or dynamically discovered knowledge of the topological discovered knowledge of the topological proximity of the relays to
proximity of the relays to itself, it can use that to select closer itself, it can use that to select closer relays with higher priority.
relays with higher priority.
There may be transport-specific reasons for preferring one candidate There may be transport-specific reasons for preferring one candidate
over another. In such a case, specifications defining usage of ICE over another. In such a case, specifications defining usage of ICE
with other transport protocols SHOULD document such considerations. with other transport protocols SHOULD document such considerations.
Once the candidates have been prioritized, one may be selected as the Once the candidates have been prioritized, one may be selected as the
active one. This is the candidate that will be used for actual active one. This is the candidate that will be used for actual
exchange of media if and when its validated, until replaced by an exchange of media if and when its validated, until a higher priority
updated offer or answer. The active candidate will also be used to candidate is validated. The active candidate will also be used to
receive media from ICE-unaware peers. As such, it is RECOMMENDED receive media from ICE-unaware peers. As such, it is RECOMMENDED
that one be chosen based on the likelihood of that candidate to work that one be chosen based on the likelihood of that candidate to work
with the peer that is being contacted. Unfortunately, it is with the peer that is being contacted. Unfortunately, it is
difficult to ascertain which candidate that might be. As an example, difficult to ascertain which candidate that might be. As an example,
consider a user within an enterprise. To reach non-ICE capable consider a user within an enterprise. To reach non-ICE capable
agents within the enterprise, a local candidate has to be used, since agents within the enterprise, a local candidate has to be used, since
the enterprise policies may prevent communication between elements the enterprise policies may prevent communication between elements
using a relay on the public network. However, when communicating to using a relay on the public network. However, when communicating to
peers outside of the enterprise, a TURN-based candidate from a peers outside of the enterprise, a relayed candidate from a
publically accessible TURN server is needed. publically accessible STUN server is needed.
Indeed, the difficulty in picking just one address that will work is Indeed, the difficulty in picking just one address that will work is
the whole problem that motivated the development of this 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
the active candidate be a TURN derived candidate from a TURN server the active candidate be a relayed candidate from a STUN server
providing public IP addresses. Furthermore, ICE is only truly providing public IP addresses in response to an Allocate request.
effective when it is supported on both sides of the session. It is Furthermore, ICE is only truly effective when it is supported on both
therefore most prudent to deploy it to close-knit communities as a sides of the session. It is therefore most prudent to deploy it to
whole, rather than piecemeal. In the example above, this would mean close-knit communities as a whole, rather than piecemeal. In the
that ICE would ideally be deployed completely within the enterprise, example above, this would mean that ICE would ideally be deployed
rather than just to parts of it. completely within the enterprise, rather than just to parts of it.
An additional consideration for selection of the active candidate is An additional consideration for selection of the active candidate is
the switching of media stream destinations between the initial offer the switching of media stream destinations between the initial offer
and the subsequent offer. If the active candidate pair in the and the subsequent offer. If the active candidate pair in the
initial offer is be validated, media will flow once that pair is initial offer is being validated, media will flow to that pair once
validated. When the ICE checks complete and yield a higher priority it is validated. When the ICE checks complete and yield a higher
candidate pair, there will be an updated offer/answer exchange that priority candidate pair, media will begin to flow to it (there will
will change the active candidate. This will result in a change in also be an updated offer/answer exchange that changes the active
the destination of the media packets. This may also cause a candidate). This will result in a change in the destination of the
different path for the media packets. That path might have different media packets. This may also cause a different path for the media
delay and jitter characteristics. As a consequence, the jitter packets. That path might have different delay and jitter
buffers may see a glitch, causing possible media artifacts. If these characteristics. As a consequence, the jitter buffers may see a
issues are a concern, the initial offer MAY omit an active candidate. glitch, causing possible media artifacts. If these issues are a
In such a case, an updated offer will need to be sent immediately concern, the initial offer MAY omit an active candidate. In such a
when communicating with an ICE-unaware agent, setting an active case, an updated offer will need to be sent immediately when
candidate. communicating with an ICE-unaware agent, setting an active candidate.
There may be transport-specific reasons for selection of an active There may be transport-specific reasons for selection of an active
candidate. In such a case, specifications defining usage of ICE with candidate. In such a case, specifications defining usage of ICE with
other transport protocols SHOULD document such considerations. other transport protocols SHOULD document such considerations.
7.3 Encoding Candidates into SDP 7.3 Encoding Candidates into SDP
For each candidate for a media stream, the agent includes a series of For each candidate for a media stream, the agent includes a series of
a=candidate attributes as media-level attributes, one for each a=candidate attributes as media-level attributes, one for each
component in the candidate. Each candidate has a unique identifier, component in the candidate. Each candidate has a unique identifier,
called the candidate-id. The candidate-id MUST be chosen randomly called the candidate-id. The candidate-id MUST be chosen randomly
and contain at least 128 bits of randomness (this does not mean that and contain at least 24 bits of randomness (this does not mean that
the candidate-id is 128 bits long; just that it has at least 128 bits the candidate-id is 24 bits long; just that it has at least 24 bits
of randomness). It is chosen only when the candidate is placed into of randomness). It is chosen only when the candidate is placed into
the SDP for the first time; subsequent offers or answers within the the SDP for the first time; subsequent offers or answers within the
same session containing that same candidate MUST use the same same session containing that same candidate MUST use the same
candidate-id used previously. candidate-id used previously. 24 bits is sufficient because the
candidate-id is not providing security (the much more random password
is). It is needed only to prevent a possible simultaneous selection
by two agents within a private network for the useful lifetime of the
software or hardware.
Each component of the candidate has an identifier, called the Each component of the candidate has an identifier, called the
component-id. The component-id is a sequence number. For each component-id. The component-id is a sequence number. For each
candidate, it starts at one, and increments by one for each candidate, it starts at one, and increments by one for each
component. As discussed below, ICE will perform connectivity checks component. As discussed below, ICE will perform connectivity checks
such that, between a pair of candidates, checks only occur between such that, between a pair of candidates, checks only occur between
transport addresses with the same component-id. As a consequence, if transport addresses with the same component-id. As a consequence, if
one candidate has three components, and it is paired with a candidate one candidate has three components, and it is paired with a candidate
that has two, there will only be two transport address pairs and two that has two, there will only be two transport address pairs and two
connectivity checks. connectivity checks.
skipping to change at page 18, line 10 skipping to change at page 19, line 37
The transport, addr and port of the a=candidate attribute (all The transport, addr and port of the a=candidate attribute (all
defined in Section 12) are set to the transport protocol, unicast defined in Section 12) are set to the transport protocol, unicast
address and port of the tranport address. A Fully Qualified Domain address and port of the tranport address. A Fully Qualified Domain
Name (FQDN) for a host MAY be used in place of a unicast address. In Name (FQDN) for a host MAY be used in place of a unicast address. In
that case, when receiving an offer or answer containing an FQDN in an that case, when receiving an offer or answer containing an FQDN in an
a=candidate attribute, the FQDN is looked up in the DNS using an A or a=candidate attribute, the FQDN is looked up in the DNS using an A or
AAAA record, and the resulting IP address is used for the remainder AAAA record, and the resulting IP address is used for the remainder
of ICE processing. The qvalue is set to the priority of the of ICE processing. The qvalue is set to the priority of the
candidate, and MUST be the same for all components of the candidate. candidate, and MUST be the same for all components of the candidate.
Each transport address also includes a password that will be used for
securing the STUN connectivity checks. This password MUST be chosen All of the candidates share a password that is used for securing the
randomly with 128 bits of randomness (though it can be longer than STUN connectivity checks. This password MUST be chosen randomly with
128 bits). Like the candidate-id, it is chosen when the candidate is 128 bits of randomness (though it can be longer than 128 bits). This
placed into an SDP for the first time for a particular session; password is contained in the a=ice-pwd attribute, present as a
subsequent offers and answers within the same session conveying the session level attribute. A new password MUST be selected for each
same candidate MUST use the same password. The converse is true; if new session, and MUST be present with the same value in all
a new offer is generated as part of a new multimedia session, a new subsequent offers and answers from the agent. The converse is true;
password (and candidate-id) would be used even if the transport if a new offer is generated as part of a new multimedia session, a
address from a previous session was being recycled. new password MUST be used even if the transport address from a
previous session was being recycled.
The combination of candidate-id and component-id uniquely identify The combination of candidate-id and component-id uniquely identify
each transport address. As a consequence, each transport address has each transport address. As a consequence, each transport address has
a unique identifier, called the tid. The tid is formed by a unique identifier, called the tid. The tid is formed by
concatenating the candidate-id with the component-id, separated by concatenating the candidate-id with the component-id, separated by
the colon (":"). The tid is not explicitly encoded in the SDP; it is the colon (":"). The tid is not explicitly encoded in the SDP; it is
derived from the candidate-id and component-id, which are present in derived from the candidate-id and component-id, which are present in
the SDP. The usage of the colon as a separator allows the the SDP. The usage of the colon as a separator allows the
candidate-id and component-id to be extracted from the tid, since the candidate-id and component-id to be extracted from the tid, since the
colon is not a valid character for the candidate-id. colon is not a valid character for the candidate-id.
skipping to change at page 19, line 35 skipping to change at page 21, line 15
be prepared for it. Note that this is not a problem specific to ICE; be prepared for it. Note that this is not a problem specific to ICE;
stray packets can arrive at a port at any time for any type of stray packets can arrive at a port at any time for any type of
protocol, especially ones on the public Internet. As such, this protocol, especially ones on the public Internet. As such, this
requirement is just restating a general design guideline for Internet requirement is just restating a general design guideline for Internet
applications - be prepared for unknown packets on any port. applications - be prepared for unknown packets on any port.
The active candidate, if there is one, is placed into the m/c lines The active candidate, if there is one, is placed into the m/c lines
of the SDP. For RTP streams, this is done by placing the RTP address of the SDP. For RTP streams, this is done by placing the RTP address
and port into the c and m lines in the SDP respectively. If the and port into the c and m lines in the SDP respectively. If the
agent is utilizing RTCP, it MUST encode its address and port using agent is utilizing RTCP, it MUST encode its address and port using
the a=rtcp attribute as defined in RFC 3605 [2]. If RTCP is not in the a=rtcp attribute as defined in RFC 3605 [1]. If RTCP is not in
use, the agent MUST signal that using b=RS:0 and b=RR:0 as defined in use, the agent MUST signal that using b=RS:0 and b=RR:0 as defined in
RFC 3556 [8]. RFC 3556 [6].
If there is no active candidate, the agent MUST include an a=inactive If there is no active candidate, the agent MUST include an a=inactive
attribute. The RTP address and port in the m/c-line is attribute. The RTP address and port in the m/c-line is
inconsequential, since it won't be used. inconsequential, since it won't be used.
Encoding of candidates may involve transport protocol specific Encoding of candidates may involve transport protocol specific
considerations. There are none for UDP. However, extensions that considerations. There are none for UDP. However, extensions that
define usage of ICE with other transport protocols SHOULD specify any define usage of ICE with other transport protocols SHOULD specify any
special encoding considerations. special encoding considerations.
Once an offer or answer are sent, an agent MUST be prepared to
receive both STUN and media packets on each candidate. As discussed
in Section 7.13, media packets can be sent to a candidate prior to
its promotion to active.
7.4 Forming Candidate Pairs 7.4 Forming Candidate Pairs
Once the offer/answer exchange has completed, both agents will have a Once the offer/answer exchange has completed, both agents will have a
set of candidates for each media stream. Each agent forms a set of set of candidates for each media stream. Each agent forms a set of
candidate pairs for each media stream by combining each of its candidate pairs for each media stream by combining each of its
candidates with each of the candidates of its peer. Candidates can candidates with each of the candidates of its peer. Candidates can
be paired up only if their transport protocols are identical. If an be paired up only if their transport protocols are identical. If an
offer/answer exchange took place for a session comprised of an audio offer/answer exchange took place for a session comprised of an audio
and a video stream, and each agent had two candidates per media and a video stream, and each agent had two candidates per media
stream, there would be 8 candidate pairs, 4 for audio and 4 for stream, there would be 8 candidate pairs, 4 for audio and 4 for
skipping to change at page 22, line 7 skipping to change at page 23, line 50
that candidate pair and all of its transport address pairs. that candidate pair and all of its transport address pairs.
Similarly, the other agent is said to be the answerer of that Similarly, the other agent is said to be the answerer of that
candidate pair and all of its transport address pairs. As a candidate pair and all of its transport address pairs. As a
consequence, each agent has a particular role, either offerer or consequence, each agent has a particular role, either offerer or
answerer, for each transport address pair. This role is important; answerer, for each transport address pair. This role is important;
when a candidate pair is to be promoted to active, the offerer is the when a candidate pair is to be promoted to active, the offerer is the
one which performs the updated offer. one which performs the updated offer.
7.5 Ordering the Candidate Pairs 7.5 Ordering the Candidate Pairs
For the same reason that the STUN and TURN allocations are paced at a For the same reason that the STUN transactions during address
rate of Ta transactions per second, so too are the connectivity gathering are paced at a rate of Ta transactions per second, so too
checks paced, also at a rate of Ta transactions per second. However, are the connectivity checks paced, also at a rate of Ta transactions
in order to rapidly converge on a valid candidate pair that is per second. However, in order to rapidly converge on a valid
mutually desirable, the candidate pairs are ordered, and the checks candidate pair that is mutually desirable, the candidate pairs are
start with the candidate pair at the top of the list. Rapid ordered, and the checks start with the candidate pair at the top of
convergence of ICE depends on both the offerer and answerer coming to the list. Rapid convergence of ICE depends on both the offerer and
the same conclusion on the ordering of candidate pairs. answerer coming to the same conclusion on the ordering of candidate
pairs.
Recall that when each candidate is encoded into SDP, it contains a Recall that when each candidate is encoded into SDP, it contains a
qvalue between 1 and 0, with 1 being the highest priority. Peer- qvalue between 1 and 0, with 1 being the highest priority. Peer
derived candidates, learned through the procedures described in reflexive candidates, learned through the procedures described in
Section 7.10 also have a priority between 0 and 1. For each media Section 7.10 also have a priority between 0 and 1. For each media
stream, the native candidates are ordered based on their qvalues, stream, the native candidates are ordered based on their qvalues,
with higher q-values coming first. Amongst candidates with the same with higher q-values coming first. Amongst candidates with the same
qvalue, they are ordered based on candidate ID, using lexicographic qvalue, they are ordered based on candidate ID, using reverse
order where C1 is placed before C2, if C2 precedes C1. In other lexicographic order, where C1 is placed before C2, if C2 precedes C1
words, if the qvalues are the same, the candidates are sorted in lexicographically. Lexicographic order can be viewed as a numerical
reverse order. This is actually important; as discussed in ordering where each "digit" is actually a number in numerical base
Section 13, it allows peer-derived candidates to be preferred over 256, with the mapping of characters to numerical value being defined
native ones. The result of these two ordering rules will be an by their ASCII encoding. For example, the candidate with candidate
ordered list of candidates. The first candidate in this list is ID agD is greater than the candidate with ID ad7, and both of those
given a sequence number of 1, the next is given a sequence number of are greater than the candidate with ID zz. Consequently, if these
2, and so on. This same procedure is done for the remote candidates. three candidates had equal q-values, they would be ordered as agD,
The result is that each candidate pair has two sequence numbers, one ad7, zz - reverse of their lexicographic order.
for the native candidate, and one for the remote candidate.
The usage of a reverse lexicographic order is important; as discussed
in Section 13, it allows peer-derived candidates to be preferred over
native ones.
The result of these ordering rules will be an ordered list of
candidates. The first candidate in this list is given a sequence
number of 1, the next is given a sequence number of 2, and so on.
This same procedure is done for the remote candidates. The result is
that each candidate pair has two sequence numbers, one for the native
candidate, and one for the remote candidate.
First, all of the candidate pairs for whom the smaller of the two First, all of the candidate pairs for whom the smaller of the two
sequence numbers equals 1 are taken first. Then, all of those for sequence numbers equals 1 are taken first. Then, all of those for
whom the smaller of the two sequence numbers equals 2 are taken next, whom the smaller of the two sequence numbers equals 2 are taken next,
and so on. Amongst those pairs that share the same value for their and so on. Amongst those pairs that share the same value for their
smaller sequence number, they are ordered by the larger of their two smaller sequence number, they are ordered by the larger of their two
sequence numbers (smallest first). Amongst those pairs that share sequence numbers (smallest first). Amongst those pairs that share
the same value for their smaller sequence number and the same value the same value for their smaller sequence number and the same value
for their larger sequence number, the larger of the two candidate IDs for their larger sequence number, the larger of the two candidate IDs
in each pair are selected, and the pairs are lexicographically in each pair are selected, and the pairs are lexicographically
skipping to change at page 23, line 21 skipping to change at page 25, line 27
--------------------------------------------------------------------- ---------------------------------------------------------------------
1 g9 1.0 1 h8 0.3 1 1 1 h8 1 g9 1.0 1 h8 0.3 1 1 1 h8
2 88 0.8 2 h8 0.3 1 2 1 h8 2 88 0.8 2 h8 0.3 1 2 1 h8
3 g9 1.0 1 65 0.2 2 2 1 g9 3 g9 1.0 1 65 0.2 2 2 1 g9
4 g9 1.0 1 k1 0.1 3 3 1 k1 4 g9 1.0 1 k1 0.1 3 3 1 k1
5 88 0.8 2 65 0.2 2 2 2 88 5 88 0.8 2 65 0.2 2 2 2 88
6 88 0.8 2 k1 0.1 3 3 2 k1 6 88 0.8 2 k1 0.1 3 3 2 k1
This ordering is then modified slightly by taking the candidate pair This ordering is then modified slightly by taking the candidate pair
corresponding to the active candidate, if there is one, and promoting corresponding to the active candidate, if there is one, and promoting
it to the top of the list. This allows the current active candidate it to the top of the list. To find this candidate pair, the agent
to be tested first. As discussed below, media is not sent until the looks for candidate pairs whose native and remote transport addresses
match the native and remote transport addresses in the m/c-line. It
is possible that multiple candidates match; this happens in the case
where an agent obtained the same derived transport address from
different local transport addresses. In such a case, the agent
should pick one of the matching candidates.
Putting the active candidate at the top of the list allows it to be
tested first. As discussed below, media is not sent until the
corresponding candidate is verified, necessitating rapid verification corresponding candidate is verified, necessitating rapid verification
of the active candidate. This modified ordering is called the of the active candidate. This modified ordering is called the
candidate pair check ordering, since it reflects the order in which candidate pair check ordering, since it reflects the order in which
connectivity checks will be done. If there was no active candidate, connectivity checks will be done. If there was no active candidate,
the candidate pair check ordering and the candidate pair priority the candidate pair check ordering and the candidate pair priority
ordering will be identical. ordering will be identical.
Within each candidate pair there will be a set of transport address Within each candidate pair there will be a set of transport address
pairs, one for each component ID. Those pairs are ordered by pairs, one for each component ID. Those pairs are ordered by
component ID. The result is an absolute ordering of all transport component ID. The result is an absolute ordering of all transport
skipping to change at page 23, line 45 skipping to change at page 26, line 13
followed by the order of their component IDs. This ordering is followed by the order of their component IDs. This ordering is
called the transport address pair check ordering. called the transport address pair check ordering.
Ordering of candidates may involve transport protocol specific Ordering of candidates may involve transport protocol specific
considerations. There are none for UDP. However, extensions that considerations. There are none for UDP. However, extensions that
define usage of ICE with other transport protocols SHOULD specify any define usage of ICE with other transport protocols SHOULD specify any
special ordering considerations. special ordering considerations.
7.6 Performing the Connectivity Checks 7.6 Performing the Connectivity Checks
Connectivity checks are performed by sending peer-to-peer STUN Connectivity checks are a STUN usage defined in [13]. They are
Binding Requests. These checks result in a candidate progressing performed by sending peer-to-peer STUN Binding Requests. These
through a state machine that captures the progress of connectivity checks result in a candidate progressing through a state machine that
checks. The specific state machine and the procedures for the captures the progress of connectivity checks. The specific state
connectivity checks are specific to the transport protocol. This machine and the procedures for the connectivity checks are specific
specification defines rules for UDP. Extensions to ICE that describe to the transport protocol. This specification defines rules for UDP.
other transport protocols SHOULD describe the state machine and the Extensions to ICE that describe other transport protocols SHOULD
procedures for connectivity checks. describe the state machine and the procedures for connectivity
checks.
The set of states visited by the offerer and answerer are depicted The set of states visited by the offerer and answerer are depicted
graphically in Figure 4 graphically in Figure 4
| |
|Start |Start
| |
| |
V V
+------------+ +------------+
| | | |
| | | |
| Waiting |----------------+ | Waiting |----------------+
| | | | | |
| | | | | |
+------------+ | +------------+ |
| | | |
| Timer Ta | Get Req | Timer Ta | Get Req
| --------. | ------- | --------. | -------
| Send Req | Send Res, | Send Req Get Req | Send Res,
V | Send Req V ------- | Send Req
Get Res +------------+ Get Req | Get Res +------------+ Send Res, |
------- | | ------- | ------- | | Re-Xmit |
- | | Send Res | - | | Req |
+---------------| Testing |-----------+ | +---------------| Testing |-----------+ |
| | | | | | | | | |
| | | | | | | | | |
| +------------+ | | | +------------+ | |
| | | | | | | |
| | Error | | | | Error | |
| | ----- | | | | ----- | |
Timer Tr | | - | | Timer Tr | | - | |
-------- V V V V -------- V V V V
Send Req +------------+ +------------+ +------------+ Send Req +------------+ +------------+ +------------+
skipping to change at page 25, line 41 skipping to change at page 28, line 11
Binding Request. The USERNAME directly contains the transport Binding Request. The USERNAME directly contains the transport
address pair ID. Requests that are sent by an agent as part of the address pair ID. Requests that are sent by an agent as part of the
processing described here encode the transport address pair in the processing described here encode the transport address pair in the
USERNAME. Binding Responses are matched to their requests using the USERNAME. Binding Responses are matched to their requests using the
STUN transaction ID, and then mapped to the transport address pair STUN transaction ID, and then mapped to the transport address pair
from that. from that.
Every Ta seconds, the agent starts a new connectivity check for a Every Ta seconds, the agent starts a new connectivity check for a
transport address pair. The check is started for the first transport transport address pair. The check is started for the first transport
address pair in the transport address pair check ordered list (which address pair in the transport address pair check ordered list (which
will be the active candidate) that is in the Waiting state. The will be part of the active candidate) that is in the Waiting state.
state machine for this transport address pair is moved to the Testing The state machine for this transport address pair is moved to the
state, and the agent sends a connectivity check using a STUN Binding Testing state, and the agent sends a connectivity check using a STUN
Request, as outlined in Section 7.7. Once a STUN connectivity check Binding Request, as outlined in Section 7.7. Once a STUN
begins, the processing of the check follows the rules for STUN. connectivity check begins, the processing of the check follows the
Specifically, retransmits of STUN requests are done as specified in rules for STUN. Specifically, retransmits of STUN requests are done
RFC 3489, and furthermore, if a transaction fails and needs to be as specified in [13], and furthermore, if a transaction fails and
retried, that retry can happen rapidly, as described below. It needs to be retried, that retry can happen rapidly, as described
doesn't "count" against the rate limit of 1/Ta checks per second. In below. It doesn't "count" against the rate limit of 1/Ta checks per
addition, the keepalives that are generated for a valid pair do not second. In addition, the keepalives that are generated for a valid
count against the rate limit either. The rate limit applies strictly pair do not count against the rate limit either. The rate limit
to the start of connectivity checks by the answerer for a transport applies strictly to the start of connectivity checks for a transport
address pair that has been newly signaled through an offer/answer address pair that has been newly signaled through an offer/answer
exchange. exchange.
In addition, if, while in the Waiting state, an agent receives a In addition, if, while in the Waiting state, an agent receives a
Binding Request matching that transport address pair, and this Binding Request matching that transport address pair, and this
Binding Request generates a successful response, the agent moves into Binding Request generates a successful response, the transport
the Send-Valid state, and sends a connectivity check of its own using address pair moves into the Send-Valid state, and the agent sends a
a STUN Binding Request, as outlined in Section 7.7. If the Binding connectivity check of its own using a STUN Binding Request, as
Request didn't generate a success response, there is no change in outlined in Section 7.7. If the Binding Request didn't generate a
state or generation of a Binding Request. success response, there is no change in state or generation of a
Binding Request.
If, while in the Testing state, the agent receives a successful If, while in the Testing state, the agent receives a successful
response to its STUN request, it moves into the Recv-Valid state. In response to its STUN request, the transport address pair moves into
this state, the agent knows that packets can flow in both directions. the Recv-Valid state. In this state, the agent knows that packets
However, its peer agent doesn't yet know that; all it knows is that can flow in both directions. However, its peer agent doesn't yet
it has been able to receive a packet. Thus, in this state, the agent know that; all it knows is that it has been able to receive a packet.
awaits receipt of the Binding Request sent by its peer, as the Thus, in this state, the agent awaits receipt of the Binding Request
response to that request is what informs its peer that packets can sent by its peer, as the response to that request is what informs its
flow in both directions. peer that packets can flow in both directions.
If, while in the Testing state, the agent receives a Binding Request
matching that transport address pair, and this Binding Request
generates a successful response, the transport address pair moves
into the Send-Valid state. In addition, the agent retransmits a
Binding Request for the transaction in progress. This helps speed up
bidirectional connectivity verification when one agent is behind a
symmetric NAT. If the Binding Request didn't generate a success
response, there is no change in state or generation of a Binding
Request.
If, while in the Send-Valid state, the agent receives a successful If, while in the Send-Valid state, the agent receives a successful
response to its STUN request, it moves to the Valid state. In this response to its STUN request, the transport address pair moves to the
state, the agent knows that packets can flow in each direction. It Valid state. In this state, the agent knows that packets can flow in
also knows that its peer has sent it the STUN Request whose response each direction. It also knows that its peer has sent it the STUN
will demonstrate to the peer that packets can flow in each direction. Request whose response will demonstrate to the peer that packets can
flow in each direction.
If, while in the Recv-Valid state, the agent receives a STUN Binding If, while in the Recv-Valid state, the agent receives a STUN Binding
Request from its peer that results in a successful response, the Request from its peer that results in a successful response, the
agent moves into the Valid state. Receipt of a request whose transport address pair moves into the Valid state. Receipt of a
response was not a successful one does not result in a change in request whose response was not a successful one does not result in a
state. change in state.
In any state, if the STUN transaction results in an error, the state In any state, if the STUN transaction results in an error, the state
machine moves into the invalid state. machine moves into the invalid state. A STUN transaction produces an
"error" based on the processing in Section 7.7, which indicates which
STUN response codes constitute an error as far as ICE processing is
concerned.
If a transport address pair is in the Recv-Valid or Valid state, an If a transport address pair is in the Recv-Valid or Valid state, an
agent MUST generate a new STUN Binding Request transaction every Tr agent MUST generate a new STUN Binding Request transaction every Tr
seconds. This transaction ensures that NAT bindings for the seconds. This transaction ensures that NAT bindings for the
transport address pair remain open while the candidate is under transport address pair remain open while the candidate is under
consideration. The transaction is performed as outlined in consideration. The transaction is performed as outlined in
Section 7.7. These transactions can also be used to keep the Section 7.7. These transactions can also be used to keep the NAT
bindings alive when the candidate is promoted to active, as described bindings alive when the candidate is promoted to active, as described
in Section 7.12. Tr SHOULD be configurable, and SHOULD default to 15 in Section 7.12. Tr SHOULD be configurable, and SHOULD default to 15
seconds. If the transaction results in an error, the state machine seconds. If the transaction results in an error, the state machine
moves to the invalid state. This happens in cases where the NAT moves to the invalid state. This happens in cases where the NAT
bindings expire (e.g., due to binding timeouts or NAT failures). bindings expire (e.g., due to binding timeouts or NAT failures).
The candidate pair itself has a state, which is derived from the The candidate pair itself has a state, which is derived from the
states of its transport address pairs. If at least one of the states of its transport address pairs. If at least one of the
transport address pairs in a candidate pair is in the invalid state, transport address pairs in a candidate pair is in the invalid state,
the state of the candidate pair is considered to be invalid. If the the state of the candidate pair is considered to be invalid. If the
skipping to change at page 27, line 36 skipping to change at page 30, line 20
in the Waiting or Testing states, and at least one is in the Testing in the Waiting or Testing states, and at least one is in the Testing
state, the state of the candidate pair is Testing. Otherwise, the state, the state of the candidate pair is Testing. Otherwise, the
state of the candidate pair is considered Indeterminate. state of the candidate pair is considered Indeterminate.
A candidate itself also has a state. If a candidate is present in at A candidate itself also has a state. If a candidate is present in at
least one valid candidate pair, that candidate is said to be valid. least one valid candidate pair, that candidate is said to be valid.
If all of the candidate pairs containing that candidate are invalid, If all of the candidate pairs containing that candidate are invalid,
the candidate itself is invalid. Otherwise, the candidate's state is the candidate itself is invalid. Otherwise, the candidate's state is
Indeterminate. Indeterminate.
If a native candidate becomes valid, and is more preferred than the
active one, the offerer sends an updated offer with this newly
validated candidate promoted to the m/c-line. This process is
discussed in more detail in Section 7.9.
7.7 Sending a Binding Request for Connectivity Checks 7.7 Sending a Binding Request for Connectivity Checks
An agent performs a Binding Request transaction by sending a STUN An agent performs a connectivity check on a transport address pair by
Binding Request from its native transport address, and sending it to sending a STUN Binding Request from its native transport address, and
the remote transport address. The meaning of "sending from its sending it to the remote transport address. The meaning of "sending
native transport address" depends on the type of transport protocol from its native transport address" depends on the type of transport
and the type of transport address (local, STUN-derived, TURN-derived, protocol and the type of transport address (local, reflexive, or
or peer-derived). This specification defines the meaning for UDP. relayed). This specification defines the meaning for UDP.
Specifications defining other transport protocols must define what Specifications defining other transport protocols must define what
this means for them. this means for them.
For UDP-based local transport addresses, sending from the local For UDP-based local transport addresses, sending from the local
transport address has the meaning one would expect - the request is transport address has the meaning one would expect - the request is
sent such that the source IP address and port For STUN derived UDP sent such that the source IP address and port equal that of the local
transport addresses, it is sent by sending from the local transport transport address. For reflexive ransport addresses, it is sent by
address used to derive that STUN address. For TURN derived UDP sending from the associated local transport address used to derive
transport addresses, it is sent by using TURN mechanisms to send the that reflesive address. For relayed transport addresses, it is sent
request through the TURN server (using the SEND primitive). Sending by using STUN mechanisms to send the request through the STUN relay
the request through the TURN server neccesarily requires that the (using the Send request). Sending the request through the STUN relay
request be sent from the client, using the local transport address server neccesarily requires that the request be sent from the client,
used to derive the TURN transport address. using the local transport address used to derive the relayed
transport address.
The Binding Request sent by the agent MUST contain the USERNAME The Binding Request sent by the agent MUST contain the USERNAME
attribute. This attribute MUST be set to the transport address pair attribute. This attribute MUST be set to the transport address pair
ID of the corresponding transport address pair as seen by its peer. ID of the corresponding transport address pair as seen by its peer.
Thus, for the first transport address pair in Figure 2, if the agent Thus, for the first transport address pair in Figure 2, if the agent
on the left sends the STUN Binding Request, the USERNAME will have on the left sends the STUN Binding Request, the USERNAME will have
the value R:1:L:1. If the agent on the right sends the STUN Binding the value R:1:L:1. If the agent on the right sends the STUN Binding
Request, the USERNAME will have the value L:1:R:1. To be clear, the Request, the USERNAME will have the value L:1:R:1. To be clear, the
USERNAME that is used is NOT the one seen locally, but rather the one USERNAME that is used is NOT the one seen locally, but rather the one
as seen by its peer. The request SHOULD contain the MESSAGE- as seen by its peer. The request SHOULD contain the MESSAGE-
INTEGRITY attribute, computed according to RFC 3489 procedures. The INTEGRITY attribute, computed according to [13]. The key used as
key used as input to the HMAC is the password provided by the peer input to the HMAC is the password provided by the peer for this
for this remote transport address. The Binding Request MUST NOT remote transport address. This password will be identical for all
contain the CHANGE-REQUEST or RESPONSE-ADDRESS attribute. remote transport addresses for the same media stream.
The STUN transaction will generate either a timeout, or a response. The STUN transaction will generate either a timeout, or a response.
If the response is a 420, 500, or 401, the agent should try again as If the response is a 420, 500, or 401, the agent should try again as
described in RFC 3489 (as mentioned above, it need not wait Ta described in [13] (as mentioned above, it need not wait Ta seconds to
seconds to try again). Either initially, or after such a retry, the try again). Either initially, or after such a retry, the STUN
STUN transaction might produce a non-recoverable failure response transaction might produce a non-recoverable failure response (error
(error codes 400, 430, 431, or 600) or a failure result inapplicable codes 400, 430, 431, or 600) or a failure result inapplicable to this
to this usage of STUN and thus unrecoverable (432, 433). If this usage of STUN and thus unrecoverable (432, 433). If this happens, an
happens, an error event is generated into the state machine, and the error event is generated into the state machine, and the transport
transport address pair enters the invalid state. address pair enters the invalid state.
If the STUN transaction times out, the client SHOULD NOT retry. The If the STUN transaction times out, the client SHOULD NOT retry. The
only reason a retry might succeed is if there was severe packet loss only reason a retry might succeed is if there was severe packet loss
during the duration of the check, or the answer was significantly during the duration of the check, or the answer was significantly
delayed, also due to packet loss. However, STUN Binding Request delayed, also due to packet loss. However, STUN Binding Request
transactions run for 9.5 seconds, which is well beyond the typical transactions run for 9.5 seconds, which is well beyond the typical
tolerance for a session establishment. The retries come with a tolerance for a session establishment. The retries come with a
penalty of additional traffic, which can be used to launch DoS penalty of additional traffic, which can be used to launch DoS
attacks Section 13.4.2. The only reason to not follow the SHOULD NOT attacks Section 13.4.2. The only reason to not follow the SHOULD NOT
is if the agent has adjusted the STUN transaction timers to be more is if the agent has adjusted the STUN transaction timers to be more
aggressive. aggressive.
If the Binding Response is a 200, the agent SHOULD check for the If the Binding Response is a 200, the agent SHOULD check for the
MESSAGE-INTEGRITY attribute and verify it, as discussed in RFC 3489. MESSAGE-INTEGRITY attribute and verify it, as discussed in [13].
Indeed, this check SHOULD be done for all responses. This will Indeed, this check SHOULD be done for all responses. This will
result in the response being discarded (eventually leading to a result in the response being discarded (eventually leading to a
timeout), if the integrity check fails. timeout), if the integrity check fails.
7.8 Receiving a Binding Request for Connectivity Checks 7.8 Receiving a Binding Request for Connectivity Checks
As a result of providing a list of candidates in its offer or answer, As a result of providing a list of candidates in its offer or answer,
an agent will receive STUN Binding Request messages. An agent MUST an agent will receive STUN Binding Request messages. An agent MUST
be prepared to receive STUN Binding Requests on each local transport be prepared to receive STUN Binding Requests on each local transport
address from the moment it sends an offer or answer that contains a address from the moment it sends an offer or answer that contains a
candidate with that local transport address. Similarly, it MUST be candidate with that local transport address. Similarly, it MUST be
prepared to receive STUN Binding Requests on a local transport prepared to receive STUN Binding Requests on a local transport
address the moment it sends an offer or answer that contains a STUN address the moment it sends an offer or answer that contains a
or TURN candidate derived from a local candidate containing that reflexive or relayed candidate derived from a local candidate with
local transport address. It can cease listening for STUN messages on that local transport address. It can cease listening for STUN
that local transport address after sending an updated offer or answer messages on that local transport address after sending an updated
which does not include any candidates with transport addresses that offer or answer which does not include any candidates with transport
are equal to or derived from that local transport address. addresses that are equal to or derived from that local transport
address.
The agent does not need to provide STUN service on any other IP
addresses or ports, unlike the STUN usage described in [1]. The need
to run the service on multiple ports is to support receipt of Binding
Requests with the CHANGE-REQUEST attribute. However, that attribute
is not used when STUN is used for connectivity checks. A server
SHOULD reject, with a 400 answer, any STUN requests with a CHANGE-
REQUEST attribute whose value is non-zero. The CHANGED-ADDRESS
attribute in a BindingAnswer is set to the transport address on which
the server is running.
Furthermore, there is no need to support TLS or to be prepared to As discussed in [13], since the username and password for STUN
receive SharedSecret request messages. Those messages are used to requests are exchanged through another mechanism - here, ICE - the
obtain shared secrets to be used with BindingRequests. However, with Shared Secret Request mechanism is not needed and need not be
ICE, these shared secrets are exchanged through the offer/answer implemented by agents that provide the connectivity check usage.
exchange itself.
One of the candidates may be in use as the active candidate. For the One of the candidates may be in use as the active candidate, or may
transport addresses comprising that candidate, the agent will receive become promoted to the active candidate in the next offer/answer
both STUN requests and media packets on its associated local exchange as a consequence of a successful validation. In either
transport addresses. The agent MUST be able to disambiguate them. case, both media and STUN packets will be sent to the transport
In the case of RTP/RTCP, this disambiguation is easy. RTP and RTCP addresses comprising that candidate, causing both to receive on their
packets start with the bits 0b10 (v=2). The first two bits in STUN associated local transport addresses. The agent MUST be able to
are always 0b00. This disambiguation also works for packets sent disambiguate them. This is done trivially by looking for the STUN
using Secure RTP [25], since the RTP header is in the clear. magic cookie as the value of the second 32-bit word in the packet.
Disambiguating STUN with other media stream protocols may be more If present, it identifies a STUN packet.
complicated. However, it can always be possible with arbitrarily
high probabilities by selecting an appropriately random username (see
below).
Processing of the Binding Request proceeds in two steps. The first Processing of the Binding Request proceeds in two steps. The first
is generation of the response, and the second is side-effect is generation of the response, and the second ICE-specific
processing. Generation of the response follows the general processing. Generation of the response follows the general
procedures of RFC 3489. The USERNAME is considered valid if its procedures of [13]. The USERNAME is considered valid if one of the
topmost portion (the part up to, but not including the second colon) candidate IDs sent in an offer or answer is a prefix of the USERNAME
corresponds to a transport address ID known to the agent. The (this will always be the case, even for peer reflexive candidates).
password associated with that transport address ID is used to verify The password associated with that candidate ID is used to verify the
the MESSAGE-INTEGRITY attribute, if one was present in the request. MESSAGE-INTEGRITY attribute, if one was present in the request. If
If the USERNAME was not valid, the agent generates a 430. Otherwise, the USERNAME was not valid, the agent generates a 430. Otherwise,
the success response will include the MAPPED-ADDRESS attribute, which the success response will include the MAPPED-ADDRESS attribute, which
is used for learning new candidates, as described in Section 7.10. is used for learning new candidates, as described in Section 7.10.
The MAPPED-ADDRESS attribute is populated with the source IP address The MAPPED-ADDRESS attribute is populated with the source IP address
and port of the Binding Request. For Binding Requests received over and port of the Binding Request. For Binding Requests received over
TURN-derived transport addresses, this MUST be the source IP address relayed transport addresses, this MUST be the source IP address and
and port of the Binding Request when it arrived at the TURN relay, port of the Binding Request when it arrived at the relay, prior to
prior to forwarding towards the agent. That source transport address forwarding towards the agent. That source transport address will be
will be present in the REMOTE-ADDRESS attribute of a TURN Data present in the REMOTE-ADDRESS attribute of a STUN Data Indication
Indication message, if the Binding Request were delivered through a message, if the Binding Request was delivered through a Data
Data Indication. If the Binding Request was not encapsulated in a Indication. If the Binding Request was not encapsulated in a Data
Data Indication, that source address is equal to the current active Indication, that source address is equal to the current active
destination for the TURN session. destination for the STUN relay session.
The side effect processing involves changes to the state machine for The ICE processing involves changes to the state machine for a
a transport address pair. This processing cannot be done until the transport address pair. This processing cannot be done until the
initial offer/answer exchange has completed. As a consequence, if initial offer/answer exchange has completed. As a consequence, if
the answerer received a Binding Request that generated a success the oferrer received a Binding Request that generated a success
response, but had not yet received the answer to its offer, it waits response, but had not yet received the answer to its offer, it waits
for the answer, and when it arrives, then performs the side effect for the answer, and when it arrives, then performs the ICE
processing. processing.
The agent takes the entire contents of the USERNAME, and compares The agent takes the entire contents of the USERNAME, and compares
them against the transport address pair identifiers as seen by that them against the transport address pair identifiers as seen by that
agent for each transport address pair. If there is no match, nothing agent for each transport address pair. If there is no match, nothing
is done - this should never happen for compliant implementations. If is done - this should never happen for compliant implementations. If
there is a match, the resulting transport address pair is called the there is a match, the resulting transport address pair is called the
matching transport address pair. The state machine for the matching matching transport address pair. The state machine for the matching
transport address pair is then updated based on the receipt of a STUN transport address pair is then updated based on the receipt of a STUN
Binding Request, and the resulting actions described in Section 7.6 Binding Request, and the resulting actions described in Section 7.6
are undertaken. are undertaken.
An agent will continue to receive periodic STUN transactions on a An agent will continue to receive periodic STUN connectivity checks
local transport address as long as it had listed that transport on a local transport address as long as it had listed that transport
address, or one derived from it, in an a=candidate attribute in its address, or one derived from it, in an a=candidate attribute in its
most recent offer or answer, and the state machine indicates that most recent offer or answer, the state machine for that transport
Binding Requests are periodically sent (as is the case for UDP). It address is in the Recv-Valid or Valid states, and the transport
MUST process any such transactions according to this section. It is address is for UDP. Whether STUN keepalives are used for other
possible that a transport address pair that was previously valid may transport protocols is defined by the specifications for that
become invalidated as a result of a subsequent failed STUN transport protocol. The agent processes any such transactions
transaction. according to this section. It is possible that a transport address
pair that was previously valid may become invalidated as a result of
a subsequent failed STUN transaction.
7.9 Promoting a Candidate to Active 7.9 Promoting a Candidate to Active
As a consequence of the connectivity checks, each agent will change As a consequence of the connectivity checks, each agent will change
the states for each transport address pair, and consequently, for the the states for each transport address pair, and consequently, for the
candidate pairs. When a candidate pair becomes valid, and the agent candidate pairs. When a candidate pair becomes valid, and the agent
is in the role of offerer for that candidate pair, the agent follows is in the role of offerer for that candidate pair, the agent follows
the logic in this section. The rules only apply to the offerer of a the logic in this section. The rules only apply to the offerer of a
candidate pair in order to eliminate the possibility of both agents candidate pair in order to eliminate the possibility of both agents
simultaneously offering an update to promote a candidate to active. simultaneously offering an update to promote a candidate to active.
skipping to change at page 31, line 34 skipping to change at page 34, line 4
If this candidate pair is not the first on the candidate pair If this candidate pair is not the first on the candidate pair
priority ordered list or the candidate pair check ordered list, and priority ordered list or the candidate pair check ordered list, and
the wait-state timer has not yet been set, the agent sets this timer the wait-state timer has not yet been set, the agent sets this timer
to Tws seconds. Tws SHOULD be configurable, and SHOULD have a to Tws seconds. Tws SHOULD be configurable, and SHOULD have a
default of 100ms. This timer allows for a higher priority default of 100ms. This timer allows for a higher priority
connectivity check to complete, in the event its STUN Binding Request connectivity check to complete, in the event its STUN Binding Request
was lost or delayed in the network. If, prior to the wait-state was lost or delayed in the network. If, prior to the wait-state
timer firing, another connectivity check completes and a candidate timer firing, another connectivity check completes and a candidate
pair is validated, there is no need to reset or cancel the timer. pair is validated, there is no need to reset or cancel the timer.
Once the timer fires, the agent SHOULD issue an updated offer as Once the timer fires, the agent SHOULD issue an updated offer as
described in Section 7.11.1. described in Section 7.11.1.
In addition, in order to speed up ICE processing, once the agent has
determined the candidate that is to be promoted, it will send and
receive media using that candidate in expectation of an updated
offer. This is discussed in Section 7.13.
7.10 Learning New Candidates from Connectivity Checks 7.10 Learning New Candidates from Connectivity Checks
ICE makes use of candidate addresses learned through protocols like ICE makes use of reflexive addresses, which are addresses that inform
STUN, as described in Section 7.1. These addresses are learned when an agent of its transport address as seen by another host. An
STUN requests are sent to configured STUN servers. However, the initial offer or answer generated by an agent includes server
peer-to-peer STUN connectivity checks can themselves provide reflexive addresses, which are learned from a configured or
additional candidates that ICE can make use of. This happens, for discovered STUN server in the network. However, the connectivity
example, when two agents are separated by a symmetric NAT. When the checks themselves can inform an agent of reflexive addresses, and in
agent behind the symmetric NAT sends a Binding Request to the other particular, ones that are reflexive towards its peer. These are
agent (which can have a public address or be behind any type of NAT called peer reflexive candidates. A new peer reflexive candidate is
except for symmetric), the symmetric NAT will create a new NAT typically observed when two agents are separated by a NAT with the
binding for this Binding Request. Because of the properties of address-dependent or address and port dependent mapping properties
symmetric NAT, that binding can be used be the agent on the public [37]. When the agent behind such a NAT sends a Binding Request to
side of the symmetric NAT to send packets back to the agent behind the other agent (assuming it is reachable), the NAT will create a new
the symmetric NAT. mapping for this Binding Request. Because STUN and the media packets
are sent on the same port, regardless of the filtering properties of
the NAT (whether endpoint independent, address dependent, or address
and port dependent), this reflexive address can be used by the peer
for sending STUN and media packets back towards the agent.
To do this, ICE agents perform additional processing on the receipt To obtain and use these peer reflexive transport addresses, ICE
of STUN Binding Requests and responses, beyond the logic described in agents perform additional processing on the receipt of STUN Binding
Section 7.7 and Section 7.8. This logic is described below. Requests and responses, beyond the logic described in Section 7.7 and
Section 7.8. This logic is described below.
7.10.1 On Receipt of a Binding Request 7.10.1 On Receipt of a Binding Request
When a STUN Binding Request is received which generates a success When a STUN Binding Request is received which generates a success
response, that Binding Request would have been associated with a response, that Binding Request would have been associated with a
matching transport address pair and corresponding candidate pair. matching transport address pair and corresponding candidate pair.
The source IP and port of this Binding Request are compared to the IP The source IP and port of this Binding Request are compared to the IP
address and port of the remote transport address in the matching address and port of the remote transport address in the matching
transport address pair. Note that, in this case, we are comparing transport address pair. Note that, in this case, we are comparing
actual IP addresses and ports - not tids. In addition, if the actual IP addresses and ports - not tids. In addition, if the
Binding Request arrived through a TURN derived transport address, the Binding Request arrived through a relayed transport address, the
source IP and port of this binding request used for the comparison source IP and port of this binding request used for the comparison
are those in the Binding Request when it arrived at the TURN relay, are those in the Binding Request when it arrived at the relay, prior
prior to forwarding towards the agent. That source transport address to forwarding towards the agent. That source transport address will
will be present in the REMOTE-ADDRESS attribute of a TURN Data be present in the REMOTE-ADDRESS attribute of a STUN Data Indication
Indication message, if the Binding Request were delivered through a message, if the Binding Request were delivered through a Data
Data Indication. If the Binding Request was not encapsulated in a Indication. If the Binding Request was not encapsulated in a Data
Data Indication, that source address is equal to the current active Indication, that source address is equal to the current active
destination for the TURN session. destination for the STUN relay session.
The comparison of the source IP and port of the Binding Request and The comparison of the source IP and port of the Binding Request and
the IP address and port of the remote transport address in the the IP address and port of the remote transport address in the
matching transport address pair may not match. One reason this could matching transport address pair may indicate inequality. In that
happen is if there was a NAT between the two agents. If they do not case, the source IP and port of the Binding Request (and again, for
match, the source IP and port of the Binding Request (and again, for relayed transport address, this refers to the source IP address and
TURN derived transport address, this refers to the source IP address port of the packet when it arrived at the relay) are compared to the
and port of the packet when it arrived at the relay) are compared to IP address and ports across the transport address pairs in *all*
the IP address and ports across the transport address pairs in *all*
remote candidates. If there is still no match, it means that the remote candidates. If there is still no match, it means that the
source IP and port might represent another valid remote transport source IP and port might represent another valid remote transport
address. Such a transport address is called a peer-derived transport address - a peer derived one.
address.
To use it, that address needs to be associated with a candidate To use it, that address needs to be associated with a candidate
(called a peer-derived candidate). In this case, however, the (called a peer-derived candidate). In this case, however, the
candidate isn't signaled through an offer/answer exchange; it is candidate isn't signaled through an offer/answer exchange; it is
constructed dynamically from information in the STUN request. Like constructed dynamically from information in the STUN request. Like
all other candidates, the peer-derived candidate has a candidate ID. all other candidates, the peer-derived candidate has a candidate ID.
The candidate ID is derived from the candidate IDs of the matching The candidate ID is derived from the candidate IDs of the matching
candidate pair. In particular, the candidate ID is constructed by candidate pair. In particular, the candidate ID is constructed by
concatenating the remote candidate ID with the native candidate ID concatenating the remote candidate ID with the native candidate ID
(without the colon). (without the colon). The password for the new candidate equals that
of the remote candidate ID in the matching candidate pair.
On receipt of a STUN Binding Request whose source IP and port don't On receipt of a STUN Binding Request whose source IP and port don't
match the transport address in any remote candidate, the agent match the transport address in any remote candidate, the agent
constructs the candidate ID that represents the peer-derived constructs the candidate ID that represents the peer reflexive
candidate, and checks to see if that candidate exists. It may candidate, and checks to see if that candidate exists. It may
already exist if it had been constructed as a consequence of a already exist if it had been constructed as a consequence of a
previous application of this logic on receipt of a Binding Request previous application of this logic on receipt of a Binding Request
for a different transport address pair of the same candidate pair. for a different transport address pair of the same candidate pair.
If there is not yet a peer derived candidate with that candidate ID, If there is not yet a peer reflexive candidate with that candidate
the agent creates it, and assigns it the newly computed candidate ID. ID, the agent creates it, and assigns it the newly computed candidate
The priority of the peer-derived candidate MUST be set to the ID. The priority of the peer-derived candidate MUST be set to the
priority of its generating candidate - the remote candidate in the priority of its generating candidate - the remote candidate in the
matching transport address pair. Note that, at this time, the peer matching transport address pair. Note that, at this time, the peer
derived candidate has no transport addresses in it. derived candidate has no transport addresses in it.
Newly created or not, the agent extracts the component ID from the Newly created or not, the agent extracts the component ID from the
matching transport address pair, and sees if a transport address with matching transport address pair, and sees if a transport address with
that same component ID exists in the peer derived candidate. If not that same component ID exists in the peer reflexive candidate. If
(and it shouldn't), the agent adds a transport address to the peer- not (and it shouldn't), the agent adds a transport address to the
derived candidate. This transport address is equal to the source IP peer reflexive candidate. This transport address is equal to the
address and port from the incoming STUN Binding Request. It is source IP address and port from the incoming STUN Binding Request
assigned the component ID equal to the component ID in the matching (and in the case of a relayed transport address, the one seen by the
transport address pair. This transport address will have a tid, relay). It is assigned the component ID equal to the component ID in
equal to the concatenation of the candidate ID for this new the matching transport address pair. This transport address will
candidate, and the component ID, separated by a colon. have a tid, equal to the concatenation of the candidate ID for this
new candidate, and the component ID, separated by a colon.
The peer-derived candidate becomes usable once the number of The peer reflexive candidate becomes usable once the number of
transport addresses in it equals the transport address pair count of transport addresses in it equals the transport address pair count of
the candidate pair from which it is derived. Initially, the peer- the candidate pair from which it is derived. Initially, the peer
derived candidate will start with a single transport address. More reflexive candidate will start with a single transport address. More
are added as the connectivity checks for the original candidate pair are added as the connectivity checks for the original candidate pair
take place. Once the peer-derived candidate becomes usable, it has take place. Once the peer reflexive candidate becomes usable, it has
to be paired up with native candidates. However, unlike the to be paired up with native candidates. However, unlike the
procedures of Section 7.5, which pair up each remote candidate with procedures of Section 7.5, which pair up each remote candidate with
each native candidate, this peer-derived candidate is only paired up each native candidate, this peer reflexive candidate is only paired
with the native candidate from the candidate pair from which it was up with the native candidate from the candidate pair from which it
derived. This creates a new candidate pair, and a set of new was derived. This creates a new candidate pair, and a set of new
transport address pairs. transport address pairs.
Recall that, for each candidate pair, one agent plays the role of Recall that, for each candidate pair, one agent plays the role of
offerer, and the other of answerer. For peer-derived candidates, the offerer, and the other of answerer. For a peer-reflexive candidate,
agent that receives the STUN request and follows the processing in the role is identical to that of its generating candidate.
this section acts as the answerer.
Figure 5 provides a pictorial representation of the peer derived Figure 5 provides a pictorial representation of the peer reflexive
candidate (the one with id=RL) and its pairing with the native candidate (the one with id=RL) and its pairing with the native
candidate with id L. The candidate with ID R is referred to as the candidate with id L. The candidate with ID R is referred to as the
generating candidate. The peer-derived candidate is effectively an generating candidate. The peer reflexive candidate is effectively an
alternate for that generating candidate, but is only paired with a alternate for that generating candidate, but is only paired with a
specific native candidate. Note that, for a particular generating specific native candidate. Note that, for a particular generating
candidate, there can be many peer derived candidates, up to one for candidate, there can be many peer derived candidates, up to one for
each native candidate. each native candidate.
............. ............. ............. .............
. tid=L:1 . . tid=R:1 . . tid=L:1 . . tid=R:1 .
component. -- . id=L:1:R:1 . -- .component component. -- . id=L:1:R:1 . -- .component
id=1 . | A|------------------------| C| . id=1 id=1 . | A|-------------------------| C| . id=1
. -- -------+ . -- . . -- -------+ . -- .
. . | . .
. . | . . Generating . . | . . Generating
. . | . . Candidate . . | . . Candidate
. . | . .
. . | . .
. tid=L:2 . | . tid=R:2 . . tid=L:2 . | . tid=R:2 .
component. -- . | id=L:2:R:2 . -- .component component. -- . | id=L:2:R:2 . -- .component
id=2 . | B|-------C----------------| D| . id=2 id=2 . | B|-------C-----------------| D| . id=2
. -- -----+ | . -- . . -- -----+ | . -- .
. .| | . .
. .| | . .
. .| | . .
. .| | . .
.............| | ............. .............| | .............
Native | | Remote Native | | Remote
Candidate | | Candidate Candidate | | Candidate
id=L | | id=R id=L | | id=R
| | | |
| |
.| |
| |
| |
| |
| | ............. | | .............
| | . tid=RL:1 . | | . tid=RL:1 .
| | id=L:1:RL:1 . -- .component | | id=L:1:RL:1 . -- .component
| +-----------------| C| . id=1 | +-----------------| C| . id=1
| . -- . | . -- .
| . .
| . . Peer Derived | . . Peer Derived
| . . Candidate | . . Candidate
| . .
| . .
| . tid=RL:2 . | . tid=RL:2 .
| id=L:2:RL:2 . -- .component | id=L:2:RL:2 . -- .component
+-------------------| D| . id=2 +-------------------| D| . id=2
. -- . . -- .
. .
. .
. .
. .
............. .............
Remote Remote
Candidate Candidate
id=RL id=RL
Figure 5 Figure 5
The new transport address pairs have a state machine associated with The new transport address pairs have a state machine associated with
them. The state that is entered, and actions to take as a them. The state that is entered, and actions to take as a
consequence, are specific to the transport protocol. For UDP, the consequence, are specific to the transport protocol. For UDP, the
skipping to change at page 35, line 45 skipping to change at page 38, line 22
candidate pair. This matching is done based on comparison of candidate pair. This matching is done based on comparison of
candidate IDs. The value of the MAPPED-ADDRESS attribute of the candidate IDs. The value of the MAPPED-ADDRESS attribute of the
Binding Response are compared to the IP address and port of the Binding Response are compared to the IP address and port of the
native transport address in the matching transport address pair. native transport address in the matching transport address pair.
Note that, in this case, we are comparing actual IP addresses and Note that, in this case, we are comparing actual IP addresses and
ports - not tids. These may not match if there was a NAT between the ports - not tids. These may not match if there was a NAT between the
two agents. If they do not match, the value of the MAPPED-ADDRESS two agents. If they do not match, the value of the MAPPED-ADDRESS
attribute of the Binding Response are compared to the IP address and attribute of the Binding Response are compared to the IP address and
ports across the transport address pairs in *all* native candidates. ports across the transport address pairs in *all* native candidates.
If there is still no match, it means that the MAPPED-ADDRESS might If there is still no match, it means that the MAPPED-ADDRESS might
represent another valid remote transport address. represent another valid native transport address.
To use it, that address needs to be associated with a candidate. In To use it, that address needs to be associated with a candidate. In
this case, however, the candidate isn't signaled through an offer/ this case, however, the candidate isn't signaled through an offer/
answer exchange; it is constructed dynamically from information in answer exchange; it is constructed dynamically from information in
the STUN response. Such a candidate is called a peer-derived the STUN response. Such a candidate is called a peer reflexive
candidate. Like all other candidates, the peer-derived candidate has candidate. Like all other candidates, the peer reflexive candidate
a candidate ID. The candidate ID is derived from the candidate IDs has a candidate ID. The candidate ID is derived from the candidate
of the matching candidate pair. In particular, the candidate ID is IDs of the matching candidate pair. In particular, the candidate ID
constructed by concatenating the native candidate ID with the remote is constructed by concatenating the native candidate ID with the
candidate ID (without the colon). remote candidate ID (without the colon). The password for the new
candidate equals that of the native candidate ID in the matching
candidate pair.
On receipt of a STUN Binding Response whose MAPPED-ADDRESS didn't On receipt of a STUN Binding Response whose MAPPED-ADDRESS didn't
match the transport address in any native candidate, the agent match the transport address in any native candidate, the agent
constructs the candidate ID that represents the peer-derived constructs the candidate ID that represents the peer reflexive
candidate, and checks to see if that candidate exists. It may candidate, and checks to see if that candidate exists. It may
already exist if it had been constructed as a consequence of a already exist if it had been constructed as a consequence of a
previous application of this logic on receipt of a Binding Response previous application of this logic on receipt of a Binding Response
for a different transport address pair of the same candidate pair. for a different transport address pair of the same candidate pair.
If there is not yet a peer derived candidate with that candidate ID, If there is not yet a peer derived candidate with that candidate ID,
the agent creates it, and assigns it the newly computed candidate ID. the agent creates it, and assigns it the newly computed candidate ID.
The priority of the new candidate MUST be set to the priority of the The priority of the new candidate MUST be set to the priority of the
generating candidate - the native candidate in the matching transport generating candidate - the native candidate in the matching transport
address pair. Note that, at this time, the peer derived candidate address pair. Note that, at this time, the peer derived candidate
has no transport addresses in it. has no transport addresses in it.
Newly created or not, the agent extracts the component ID from the Newly created or not, the agent extracts the component ID from the
matching transport address pair, and sees if a transport address with matching transport address pair, and sees if a transport address with
that same component ID exists in the peer derived candidate. If not that same component ID exists in the peer reflexive candidate. If
(and it shouldn't), the agent adds a transport address to the peer- not (and it shouldn't), the agent adds a transport address to the
derived candidate. This transport address is equal to the MAPPED- peer reflexive candidate. This transport address is equal to the
ADDRESS from the STUN Binding Response. It is assigned the component MAPPED-ADDRESS from the STUN Binding Response. It is assigned the
ID equal to the component ID in the matching transport address pair. component ID equal to the component ID in the matching transport
This transport address will have a tid, equal to the concatenation of address pair. This transport address will have a tid, equal to the
the candidate ID for this new candidate, and the component ID, concatenation of the candidate ID for this new candidate, and the
separated by a colon. component ID, separated by a colon.
The peer-derived candidate becomes usable once the number of The peer-derived candidate becomes usable once the number of
transport addresses in it equals the transport address pair count of transport addresses in it equals the transport address pair count of
candidate pair from which it is derived. Initially, the peer-derived candidate pair from which it is derived. Initially, the peer-derived
candidate will start with a single transport address. More are added candidate will start with a single transport address. More are added
as the connectivity checks for the original candidate pair take as the connectivity checks for the original candidate pair take
place. Once the peer-derived candidate becomes usable, it has to be place. Once the peer-derived candidate becomes usable, it has to be
paired up with remote candidates. However, unlike the procedures of paired up with remote candidates. However, unlike the procedures of
Section 7.5, which pair up each remote candidate with each native Section 7.5, which pair up each remote candidate with each native
candidate, the peer-derived candidate is only paired up with the candidate, the peer-derived candidate is only paired up with the
remote candidate from the matching candidate pair . This creates a remote candidate from the matching candidate pair . This creates a
new candidate pair, and a set of new transport address pairs. new candidate pair, and a set of new transport address pairs.
Recall that, for each candidate pair, one agent plays the role of Recall that, for each candidate pair, one agent plays the role of
offerer, and the other of answerer. For peer-derived candidates, the offerer, and the other of answerer. For a peer-reflexive candidate,
agent that receives the STUN request and follows the processing in the role is identical to that of its generating candidate.
this section acts as the answerer.
The new transport address pairs have a state machine associated with The new transport address pairs have a state machine associated with
them. The state that is entered, and actions to take as a them. The state that is entered, and actions to take as a
consequence, are specific to the transport protocol. For UDP, the consequence, are specific to the transport protocol. For UDP, the
procedures are defined here. Extensions that define processing for procedures are defined here. Extensions that define processing for
other transport protocols SHOULD describe the behavior. other transport protocols SHOULD describe the behavior.
For UDP, the state machine enters the Recv-Valid state. Effectively, For UDP, the state machine enters the Recv-Valid state. Effectively,
the Binding Response just received "counts" as a validation in this the Binding Response just received "counts" as a validation in this
direction, even though it was formally done for a different candidate direction, even though it was formally done for a different candidate
skipping to change at page 37, line 38 skipping to change at page 40, line 16
If there are any aspects of this processing that are specific to the If there are any aspects of this processing that are specific to the
transport protocol, those SHOULD be called out in ICE extensions that transport protocol, those SHOULD be called out in ICE extensions that
define operation with other transport protocols. There are no define operation with other transport protocols. There are no
additional considerations for UDP. additional considerations for UDP.
7.11.1 Sending of a Subsequent Offer 7.11.1 Sending of a Subsequent Offer
The offer MAY contain a new active candidate in the m/c line. This The offer MAY contain a new active candidate in the m/c line. This
candidate SHOULD be the native candidate from the highest candidate candidate SHOULD be the native candidate from the highest candidate
pair in the candidate pair priority ordered list whose state is pair in the candidate pair priority ordered list whose state is
valid. If there are no candidate pairs in this state, the highest Valid. If there are no candidate pairs in this state, the highest
one whose state is partially valid SHOULD be used. If there are no one whose state is Send-Valid or Recv-Valid SHOULD be used. If there
candidate pairs in this state, the candidate pair that is most likely are no candidate pairs in these states, the candidate pair that is
to work with this peer, as described in Section 7.2, SHOULD be used. most likely to work with this peer, as described in Section 7.2,
The candidate is encoded into the m/c line in an updated offer as SHOULD be used. The candidate is encoded into the m/c line in an
described in Section 7.3. updated offer as described in Section 7.3.
If the candidate pair whose native candidate was encoded into the If the candidate pair whose native candidate was encoded into the
m/c-line was valid or partially valid, the agent MUST include an m/c-line was Valid, Send-Valid or Recv-Valid, the agent MUST include
a=remote-candidate attribute into the offer. This attribute MUST an a=remote-candidate attribute into the offer. This attribute MUST
contain the candidate ID of the remote candidate in the candidate contain the candidate ID of the remote candidate in the candidate
pair. It is used by the recipient of the offer in selecting its pair. It is used by the recipient of the offer in selecting its
candidate for the answer. candidate for the answer.
The meaning of a=candidate attributes within a subsequent offer have The meaning of a=candidate attributes within a subsequent offer have
the same meaning as they do in an initial offer. They are a request the same meaning as they do in an initial offer. They are a request
for the peer to attempt (or continue to attempt if the candidate was for the peer to attempt (or continue to attempt if the candidate was
provided previously) a connectivity check using STUN from each of its provided previously) a connectivity check using STUN from each of its
own candidates. When an updated offer is sent, there are several own candidates. When an updated offer is sent, there are several
dispositions regarding the candidates: dispositions regarding the candidates:
retained: A candidate is retained if the candidate ID for the retained: A candidate is retained if the candidate ID for the
candidate is included in the new offer, and matches the candidate candidate is included in the new offer, and matches the candidate
ID for a candidate in the previous offer or answer. In this case, ID for a candidate in the previous offer or answer from the agent.
all of the information about the candidate - its qvalue and In this case, all of the information about the candidate - its
components, and the IP addresses, ports, STUN passwords and qvalue and components, and the IP addresses, ports, and transport
transport protocols of its components, MUST be the same as the protocols of its components, MUST be the same as the previous
previous offer or answer from the agent. If the agent wants to offer or answer from the agent. If the agent wants to change
change them, this is accomplished by changing the candidate ID as them, this is accomplished by changing the candidate ID as well.
well. That will have the effect of removing the old candidate and That will have the effect of removing the old candidate and adding
adding a new one with the updated information. a new one with the updated information.
removed: A candidate is removed if its candidate ID appeared in a removed: A candidate is removed if its candidate ID appeared in a
previous offer or answer, and that candidate ID is not present in previous offer or answer, and that candidate ID is not present in
the new offer. the new offer.
added: A candidate is added if its candidate ID appeared in the new added: A candidate is added if its candidate ID appeared in the new
offer, but was not present in a previous offer or answer from that offer, but was not present in a previous offer or answer from that
agent. agent.
The following rules are used to determine the disposition of the each The following rules are used to determine the disposition of the each
of the current native candidates in the new offer: of the current native candidates in the new offer:
o If a candidate is invalid, and all peer-derived candidates o If a candidate is invalid, and all peer reflexive candidates
generated from it are invalid as well, it SHOULD be removed. generated from it are invalid as well, it SHOULD be removed.
o If the candidate in the m/c-line is valid, all other candidates o If the candidate in the m/c-line is valid, all other candidates
SHOULD be removed. This has the effect of stopping connectivity SHOULD be removed. This has the effect of stopping connectivity
checks of other candidates. This SHOULD would not be followed if checks of other candidates. This SHOULD would not be followed if
an agent wanted to keep a candidate ready for usage should, for an agent wanted to keep a candidate ready for usage should, for
some reason, the active candidate later become invalid. some reason, the active candidate later become invalid.
o If the candidate in the m/c-line is valid, and it is not peer- o If the candidate in the m/c-line is valid, and it is not peer
derived, that candidate MUST be retained. If the candidate in the reflexive, that candidate MUST be retained. If the candidate in
m/c-line is peer-derived, its generating candidate MUST be the m/c-line is peer reflexive, its generating candidate MUST be
retained, even if it is itself invalid. retained, even if it is itself invalid.
o If the candidate in the m/c-line has not been validated, all other o If the candidate in the m/c-line has not been validated, all other
candidates that are not invalid, or candidates for whom their candidates that are not invalid, or candidates for whom their
derived candidates are not invalid, SHOULD be retained. derived candidates are not invalid, SHOULD be retained.
o Peer derived candidates MUST NOT be added; they continue to be o Peer reflexive candidates MUST NOT be added; they continue to be
used as long as their generating candidate was retained. Peer used as long as their generating candidate was retained. Peer
derived candidates are learned exclusively through the STUN derived candidates are learned exclusively through the STUN
connectivity checks. connectivity checks.
A new candidate MAY be added. This can happen when the candidate is A new candidate MAY be added. This can happen when the candidate is
a new one, learned since the previous offer/answer exchange, and it a new one, learned since the previous offer/answer exchange, and it
has a higher priority than the currently active candidate. It can has a higher priority than the currently active candidate. It can
also occur when an agent wishes to restart checks for a transport also occur when an agent wishes to restart checks for a transport
address it had tried previously. Effectively, changing the candidate address it had tried previously. Effectively, changing the candidate
ID value in an updated offer will "restart" connectivity checks for ID value in an updated offer will "restart" connectivity checks for
that candidate. that candidate.
If a candidate is removed, the agent takes the following steps: If a candidate is removed, the agent takes the following steps once
the offer is sent:
1. The agent eliminates any candidate pairs whose native candidate 1. The agent eliminates any candidate pairs whose native candidate
equalled the candidate that was removed. Equality is based on equalled the candidate that was removed. Equality is based on
comparison of candidate IDs. comparison of candidate IDs.
2. The agent eliminates any candidate pairs that had a native 2. The agent eliminates any candidate pairs that had a native
candidate that is a peer derived candidate generated from the candidate that is a peer reflexive candidate generated from the
candidate that was removed. candidate that was removed.
3. The candidate pairs that are eliminated are removed from the 3. The candidate pairs that are eliminated are removed from the
candidate pair priority ordered list and candidate pair check candidate pair priority ordered list and candidate pair check
ordered list. As a consequence of this, if connectivity checks ordered list. As a consequence of this, if connectivity checks
had not yet begun for the candidate pair, they won't. had not yet begun for the candidate pair, they won't.
4. If connectivity checks were already in progress for transport 4. If connectivity checks were already in progress for transport
addresses in that candidate pair, the agent SHOULD immediately addresses in a candidate pair that was removed, the agent SHOULD
terminate them. No further retransmissions take place, and no immediately terminate them. No further retransmissions take
further transactions from that candidate will be made. place, and no further transactions from that candidate will be
made.
5. If the removed candidate was a TURN-derived candidate, the agent 5. If the removed candidate was a relayed candidate, the agent
SHOULD de-allocate its transport addresses from the TURN server. SHOULD de-allocate its transport addresses from the STUN relay if
If a local candidate was removed, and all of its derived it is not using those resources elswhere. If a local candidate
candidates were also removed (including any peer-derived was removed, and all of its derived candidates were also removed
candidates), local operating system resources for each of the (including any peer reflexive candidates), local operating system
transport addresses in the local candidate SHOULD be de- resources for each of the transport addresses in the local
allocated. candidate SHOULD be de-allocated, as long as it is not using
those resources elsewhere. The resources may be in use elsewhere
if they were included in an initial offer which generated
multiple answers (as can happen with SIP forking). In such a
case, a subsequent offer which removes the candidate will not
imply its removal with the other branches; each becomes a
separate offer/answer relationship.
Subsequent offers MUST contain the a=ice-pwd attribute. This SHOULD
have the same value as in previous offers. However, an agent MAY
change it if, for some reason, the agent believes that the password
may have been compromised. Since the same password is applied across
all transport addresses in all candidates for all media streams, a
change in the password impacts all of them. An agent MUST be
prepared to receive connectivity checks that use either the new or
old password until Tpw seconds after it receives the answer. Tpw
SHOULD be configurable, and SHOULD default to 2 seconds.
7.11.2 Receiving the Offer and Sending an Answer 7.11.2 Receiving the Offer and Sending an Answer
To generate the answer, the answerer has to decide which transport To generate the answer, the answerer has to decide which transport
addresses to include in the m/c line, and which to include in addresses to include in the m/c line, and which to include in
candidate attributes. candidate attributes.
The first step in the process is to look for the a=remote-candidate
attribute in the offer. The a=remote-candidate exists to eliminate a
race condition between the updated offer and the response to the STUN
Binding Request that moved a candidate into the Valid state. This
race condition is shown in Figure 6. On receipt of message 5, agent
A can move its transport address pair state machine into the Valid
state. It sends a STUN response to the request (message 6), but this
is lost. Agent A proceeds with an updated offer (message 7), which
is received at agent B. As far as agent B is concerned, the transport
address pair is still in the Send-Valid state. It will move into the
Valid state only on receipt of the STUN response in message 10.
Thus, upon receipt of the offer, agent B cannot determine which
candidate to include in its answer. To eliminate this condition, the
identity of the validated candidate is included in the offer itself.
Note, however, that the answerer will not send media until it has
received this STUN response.
Agent A Network Agent B
|(1) Offer | |
|------------------------------------------>|
|(2) Answer | |
|<------------------------------------------|
|(3) STUN Req. | |
|------------------------------------------>|
|(4) STUN Res. | |
|<------------------------------------------|
|(5) STUN Req. | |
|<------------------------------------------|
|(6) STUN Res. | |
|-------------------->| |
| |Lost |
|(7) Offer | |
|------------------------------------------>|
|(8) Answer | |
|<------------------------------------------|
|(9) STUN Req. | |
|<------------------------------------------|
|(10) STUN Res. | |
|------------------------------------------>|
Figure 6
If the a=remote-candidate attribute is present, the agent examines
the transport addresses in the m/c-line of the offer. It compares
these with the transport addresses in the remote candidates of all
candidate pairs. If there is at least one match, the agent compares
the native candidate ID of each matching pair with the value of the
a=remote-candidate attribute. If there is a match, that candidate
pair is selected. For each transport address pair in that candidate
pair, if the state of the transport address pair is Send-Valid, the
agent considers the state to be Valid just for the purpose of
selecting the m/c-line as discussed in the paragraph below. The
actual state MUST remain Send-Valid. This is necessary to prevent
against DoS attacks.
Rules for choosing transport addresses for the m/c-line are as Rules for choosing transport addresses for the m/c-line are as
follows. The agent examines the transport addresses in the m/c-line follows. The agent examines the transport addresses in the m/c-line
of the offer. It compares these with the transport addresses in the of the offer. It compares these with the transport addresses in the
remote candidates of candidate pairs whose states are Valid. If remote candidates of candidate pairs whose states are Valid. If
there is matching candidate pair in that state, the agent MUST pick there is a matching candidate pair in that state, the pair with the
the native candidate from one of those pairs, and use that candidate highest priority MUST be chosen, and the native candidate from that
as the active one. If none of the matching pairs are in the Valid pair used as the active candidate. If there were no matching
state, the agent checks if there are any matching pairs in the Send- candidate pairs in the Valid state, the candidate that is most likely
Valid state. If there are, the agent looks for the a=remote- to work with this peer, as described in Section 7.2, SHOULD be used.
candidate attribute in the offer. If present, and the candidate ID
listed there is one of the native candidate IDs amongst the matching
pairs, that candidate ID MUST be used as the active one. If the
a=remote-candidate attribute was not present in the offer, or there
were no matching candidate pairs in the Send-Valid state, the
candidate that is most likely to work with this peer, as described in
Section 7.2, SHOULD be used.
The a=remote-candidate exists to eliminate a race condition between
the updated offer and the response to the STUN Binding Request that
moved a candidate into the valid state. If the answer arrives at the
agent prior to the Binding Response, the candidate pair that was
validated by the offer will still be in the Send-Valid state. To
eliminate this condition, the identity of the validated candidate is
included in the offer itself.
Like the offerer, the answer can decide, for each of its candidates, Like the offerer, the answerer can decide, for each of its
whether they are retained or removed. The same rules defined in candidates, whether they are retained or removed. The same rules
Section 7.11.1 for determining their disposition apply to the defined in Section 7.11.1 for determining their disposition apply to
answerer. Similarly, if a candidate is removed, the same rules in the answerer. Similarly, if a candidate is removed, the same rules
Section 7.11.1 regarding removal of canididate pairs and freeing of in Section 7.11.1 regarding removal of canididate pairs and freeing
resources apply. of resources apply.
Once the answer is sent, the answerer will have the set of native and Once the answer is sent, the answerer will have the set of native and
remote candidates before this offer/answer exchange, and the set of remote candidates before this offer/answer exchange, and the set of
native and remote candidates afterwards. The agent then pairs up the native and remote candidates afterwards. A peer derived candidate
native and remote candidates which were added or retained. continues to be used as long as its generating parent continues to be
Furthermore, for candidate pairs containing a peer derived transport used. The agent then pairs up the native and remote candidates which
address, those pairs continue as long as both candidates are were added or retained. This leads to a set of current candidate
retained. A peer derived candidate continues to be used as long as pairs.
its generating parent continues to be used. This leads to a set of
current candidate pairs.
If a candidate pair existed previously, but as a consequence of the If a candidate pair existed previously, but as a consequence of the
offer/answer exchange, either its native or remote candidate has been offer/answer exchange, it no longer exists, the agent takes the
removed, the agent takes the following steps: following steps:
1. The candidate pair is removed from the candidate pair priority 1. The candidate pair is removed from the candidate pair priority
ordered list and candidate pair check ordered list. As a ordered list and candidate pair check ordered list. As a
consequence of this, if connectivity checks had not yet begun for consequence of this, if connectivity checks had not yet begun for
the candidate pair, they won't. the candidate pair, they won't.
2. If connectivity checks were already in progress for that 2. If connectivity checks were already in progress for that
candidate pair, the agent SHOULD immediately terminate any STUN candidate pair, the agent SHOULD immediately terminate any STUN
transactions in progress from that candidate. No further transactions in progress from that candidate. No further
retransmissions take place, and no further transactions from that retransmissions take place, and no further transactions from that
skipping to change at page 41, line 46 skipping to change at page 45, line 31
7.12 Binding Keepalives 7.12 Binding Keepalives
Once a candidate is promoted to active, and media begins flowing, it Once a candidate is promoted to active, and media begins flowing, it
is still necessary to keep the bindings alive at intermediate NATs is still necessary to keep the bindings alive at intermediate NATs
for the duration of the session. Normally, the media stream packets for the duration of the session. Normally, the media stream packets
themselves (e.g., RTP) meet this objective. However, several cases themselves (e.g., RTP) meet this objective. However, several cases
merit further discussion. Firstly, in some RTP usages, such as SIP, merit further discussion. Firstly, in some RTP usages, such as SIP,
the media streams can be "put on hold". This is accomplished by the media streams can be "put on hold". This is accomplished by
using the SDP "sendonly" or "inactive" attributes, as defined in RFC using the SDP "sendonly" or "inactive" attributes, as defined in RFC
3264 [5]. RFC 3264 directs implementations to cease transmission of 3264 [4]. RFC 3264 directs implementations to cease transmission of
media in these cases. However, doing so may cause NAT bindings to media in these cases. However, doing so may cause NAT bindings to
timeout, and media won't be able to come off hold. timeout, and media won't be able to come off hold.
Secondly, some RTP payload formats, such as the payload format for Secondly, some RTP payload formats, such as the payload format for
text conversation [34], may send packets so infrequently that the text conversation [36], may send packets so infrequently that the
interval exceeds the NAT binding timeouts. interval exceeds the NAT binding timeouts.
Thirdly, if silence suppression is in use, long periods of silence Thirdly, if silence suppression is in use, long periods of silence
may cause media transmission to cease sufficiently long for NAT may cause media transmission to cease sufficiently long for NAT
bindings to time out. bindings to time out.
To prevent these problems, ICE implementations MUST continue to list To prevent these problems, ICE implementations MUST continue to list
their active transport addresses in a=candidate lines for UDP-based their active candidate in a=candidate lines for UDP-based media
media streams. As a consequence of this, STUN packets will be streams. As a consequence of this, STUN packets will be transmitted
transmitted periodically independently of the transmission (or lack periodically independently of the transmission (or lack thereof) of
thereof) of media packets. This provides a media independent, RTP media packets. This provides a media independent, RTP independent,
independent, and codec independent solution for keeping the NAT and codec independent solution for keeping the NAT bindings alive.
bindings alive. STUN Binding Requests cannot be used for TCP-based
transports because the media protocol may not provide framing
services to support this. As such, application layer keepalives MUST
be used in this case.
If an ICE implementation is communciating with one that does not If an ICE implementation is communciating with one that does not
support ICE, keepalives MUST still be sent. Indeed, these keepalives support ICE, keepalives MUST still be sent. Indeed, these keepalives
are essential even if neither endpoint implements ICE. As such, this are essential even if neither endpoint implements ICE. As such, this
specification defines keepalive behavior generally, for endpoints specification defines keepalive behavior generally, for endpoints
that support ICE, and those that do not. that support ICE, and those that do not.
All endpoints MUST send keepalives for each media session. These All endpoints MUST send keepalives for each media session. These
keepalives MUST be sent regardless of whether the media stream is keepalives MUST be sent regardless of whether the media stream is
currently inactive, sendonly, recvonly or sendrecv. The keepalive currently inactive, sendonly, recvonly or sendrecv. The keepalive
SHOULD be sent using a format which is supported by its peer. ICE SHOULD be sent using a format which is supported by its peer. ICE
endpoints allow for STUN-based keepalives for UDP streams, and as endpoints allow for STUN-based keepalives for UDP streams, and as
such, STUN keepalives MUST be used when an agent is communicating such, STUN keepalives MUST be used when an agent is communicating
with a peer that supports ICE. An agent can determine that its peer with a peer that supports ICE. An agent can determine that its peer
supports ICE by the presence of the a=candidate attributes for each supports ICE by the presence of the a=candidate attributes for each
media session. If the peer does not support ICE, the choice of a media session. If the peer does not support ICE, the choice of a
packet format for keepalives is a matter of local implementation. A packet format for keepalives is a matter of local implementation. A
format which allows packets to easily be sent in the absence of format which allows packets to easily be sent in the absence of
actual media content is RECOMMENDED. Examples of formats which actual media content is RECOMMENDED. Examples of formats which
readily meet this goal are RTP No-Op [29] and RTP comfort noise [27]. readily meet this goal are RTP No-Op [31] and RTP comfort noise [26].
STUN-based keepalives will be sent periodically every Tr seconds as a STUN-based keepalives will be sent periodically every Tr seconds as a
consequence of the rules in in Section 7.7. If STUN keepalives are consequence of the rules in in Section 7.7. If STUN keepalives are
not in use (because the peer does not support ICE or because of TCP), not in use (because the peer does not support ICE), an agent SHOULD
an agent SHOULD ensure that a media packet is sent every Tr seconds. ensure that a media packet is sent every Tr seconds. If one is not
If one is not sent as a consequence of normal media communications, a sent as a consequence of normal media communications, a keepalive
keepalive packet using one of the formats discussed above SHOULD be packet using one of the formats discussed above SHOULD be sent.
sent.
7.13 Sending Media 7.13 Sending Media
An agent MUST NOT send media packets until the active candidate has When an agent receives an offer and sends an answer, or when it
entered either the Valid or Recv-Valid state. This is to prevent a receives an answer to an offer it sent, it begins connectivity
particularly destructive denial-of-service attack described in checks. These checks will include validation of the active candidate
Section 13.4.1. pair, if there was one. An agent SHOULD NOT send media on the active
candidate pair until that candidate pair has reached the Valid or
Recv-Valid state. This is to help prevent a denial-of-service
attack, described in Section 13. Once the active candidate pair
reaches the Valid or Recv-Valid state, an agent MAY start sending
media to that candidate pair.
It is important to note that an agent always sends media to the However, offer/answer exchanges are used with protocols, like SIP,
address in the m/c-line, not to a validated candidate. To use a which require media to be sent "early", from the answerer to the
candidate, it must be promoted to the m/c-line through an updated offer, prior to completion of the initial offer/answer exchange. It
offer/answer exchange. is highly desirable (and sometimes necessary) for this early media to
use the candidate pair ultimately selected by ICE connectivity
checks. For this reason, ICE provides an early media mechanism that
allows for a candidate pair to be used in one direction prior to its
promotion to active in a subsequent offer/answer exchange. Note
that, with ICE, early media pertains to media sent to a candidate
pair until its promotion to active in a subsequent offer/answer
exchange. This is a broader definition than is used in [29], which
defines early media as media sent prior to acceptance of a call.
When an agent sends media packets, it MUST send them from the same IP As a consequence of the connectivity checks, an agent will change the
address and port it has advertised in the m/c-line. This provides a states for each transport address pair, and consequently, for the
property known as symmetry, which is an essential facet of NAT candidate pairs. When a candidate pair becomes Valid or Recv-Valid,
traversal. and the candidate pair is not equal to the active candidate pair, and
the agent is in the role of answerer for that candidate pair, the
agent checks the position of that pair in the candidate pair priority
ordered list. If it is the first, the agent selects this candidate
pair for early media. If this candidate pair is not the first on the
candidate pair priority ordered list, but is higher priority than the
active candidate pair, and the early media wait-state timer has not
yet been set, the agent sets this timer to Tws seconds. Tws SHOULD
be configurable, and SHOULD have a default of 100ms. This timer
allows for a higher priority connectivity check to complete, in the
event its STUN Binding Request or Response was lost or delayed in the
network. If, prior to the wait-state timer firing, another
connectivity check completes and a candidate pair enters the Valid or
Recv-Valid states, there is no need to reset or cancel the timer.
Once the timer fires, the agent SHOULD select the highest priority
candidate pair in the Valid or Recv-Valid state for which the agent
has the role of answerer, and use that candidate pair for early
media.
In the case of a STUN-derived transport address, this means that the ICE processing will ensure that, under almost all circumstances, the
RTP packets are sent from the local transport address used to obtain candidate pair selected by the answerer for early media will also be
the STUN address. In the case of a TURN-derived transport address, the one selected by the offerer for eventual promotion to active.
this means that media packets are sent through the TURN server (using The early media state implies that the answerer knows that this
the TURN SEND primitive). For local transport addresses, media is candidate pair is to be used, but the offerer doesn't know yet that
sent from that local transport address. it will eventually be validated. It is for this reason that the
candidate pair can be used for early media.
This symmetric behavior MUST be followed by an agent even if its peer If a candidate pair is selected for early media, an agent MAY send
in the session doesn't support ICE. media on that candidate pair, even if it is not the same as the
active candidate pair. However, to deal with cases in which the
offerer and answerer do not agree on the eventual selection of this
candidate for promotion to active (a rare but possible case), the
agent MUST discontinue using the candidate pair for sending media Tlo
seconds after the answer has been reliably delivered. An answer is
considered reliably delivered when the agent receives a confirmation
that is has been delivered. In the case of an answer delivered in a
200 OK to an offer in an INVITE (in the SIP case), the answer is
considered reliably delivered upon receipt of the ACK. Tlo SHOULD be
configurable and SHOULD have a default of 5 seconds. This time
represents the amount of time it should take the offerer to perform
its connectivity checks, arrive at the same conclusion about the
viability of the early candidate, and then generate an updated offer
promoting it to active. If, after Tlo seconds, no updated offer
arrives, the answerer MUST cease using the early candidate. Media
MAY be sent to the active candidate pair if it is in the Valid or
Recv-Valid state.
If an updated offer does arrive prior to the expiration of the timer,
the agent MUST execute the procedures in Section 7.11.2, which will
result in the selection of a candidate for the m/c-line in the
answer. At that point, the procedures of this section SHOULD be
restarted by the answerer. This implies that the active candidate
pair, if Valid or Recv-Valid, will be used. If a higher priority
candidate pair subsequently enters the Valid or Recv-Valid state, it
may end up being used as an early candidate.
To use a candidate pair, whether it is early or active, media is sent
to the IP addresses and ports of the components in the remote
candidate, and sends that media from the IP addresses and ports of
the components in the native candidate. Transport addresses are
paired up based on component ID. For example, if a remote candidate
has two components R1 and R2, and the native candidate has two
components L1 and L2, media packets are sent from L1 to R1 and from
L2 to R2. This provides a property known as symmetry. This
symmetric behavior MUST be followed by an agent even if its peer in
the session doesn't support ICE.
The definition of sending media "from" a particular transport address
depends on the type of transport address. In the case of a server
reflexive transport address, this means that the RTP packets are sent
from the local transport address used to obtain the STUN address. In
the case of a relayed transport address, this means that media
packets are sent through the relay server (for STUN relays, this
would be using the Send request). For local transport addresses,
media is sent from that local transport address. For peer reflexive
transport addresses, media is sent from the local transport address
used to obtain the reflexive address.
ICE has interactions with jitter buffer adaptation mechanisms. An
RTP stream can begin using one candidate, and switch to another one.
The newer candidate may result in RTP packets taking a different path
through the network - one with different delay characteristics. To
signal to the jitter buffers that this change has happened, it is
RECOMMENDED that, when an agent switches transmission of media from
one candidate pair to another, it sets the RTP marker bit.
Furthermore, it is RECOMMENDED that, upon receipt of an RTP packet
with the marker bit set, or upon receipt of a packet with a different
source IP address, that the agent re-adjust its jitter buffers.
8. Guidelines for Usage with SIP 8. Guidelines for Usage with SIP
SIP [3] makes use of the offer/answer model, and is one of the SIP [2] makes use of the offer/answer model, and is one of the
primary targets for usage of ICE. SIP allows for offer/answer primary targets for usage of ICE. SIP allows for offer/answer
exchanges to occur in many different combinations of messages, exchanges to occur in many different combinations of messages,
including INVITE/200 OK and 200 OK/ACK. When support for reliable including INVITE/200 OK and 200 OK/ACK. When support for reliable
provisional responses (RFC 3262 [13]) and UPDATE (RFC 3311 [28]) are provisional responses (RFC 3262 [11]) and UPDATE (RFC 3311 [27]) are
added, additional combinations of messages that can be used for added, additional combinations of messages that can be used for
offer/answer exchanges are added. As such, this section provides offer/answer exchanges are added. As such, this section provides
some guidance on good ways to make use of SIP with ICE. some guidance on good ways to make use of SIP with ICE.
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, along with an updated offer/answer exchange to use between endpoints. These checks start from the answerer on
a validated candidate. These exchanges require time to complete. If generation of its answer, and start from the offerer when it receives
the initial offer/answer exchange were to take place in the INVITE the answer. These checks can take time to complete, and as such, the
and 200 OK response respectively, the connectivity checks and updated selection of messages to use with offers and answers can effect
offer would all occur after the called party answered. This will perceived user latency. Two latency of figures are of particular
result in a potential increase in the post-pickup delay. This delay interest. These are the post-pickup delay and the post-dial delay.
refers to the time between when a user "answers the phone" and when The post-pickup delay refers to the time between when a user "answers
any speech they utter can be delivered to the caller. the phone" and when any speech they utter can be delivered to the
caller. The post-dial delay refers to the time between when a user
enters the destination address for the user, and ringback begins as a
consequence of having succesfully started ringing the phone of the
called party.
To eliminate any increase in post-pickup delay due to ICE, it is To reduce post-dial delays, it is RECOMMENDED that the caller begin
RECOMMENDED that the initial offer/answer exchange take place in an gathering candidates prior to actually sending its initial INVITE.
INVITE and a 18x provisional response. As a consequence, support for This can be started upon user interface cues that a call is pending,
RFC 3262 is RECOMMENDED with ICE. The STUN connectivity checks will such as activity on a keypad or the phone going offhook.
then take place while the called party is being "rung". To deliver
the updated offer prior to the user answering the call, it is
RECOMMENDED that it be delivered with an UPDATE request. This will
allow ICE to have completed prior to the called party even answering
the session invitation.
If RFC 3262 and RFC 3311 are not supported by both agents, tuning can To reduce post-pickup delays, ICE allows for media to be sent from
still take place to reduce post-pickup delays. In particular, the the answerer to the offerer on a candidate pair, prior to its
answerer SHOULD include its answer in an unreliable 18x response. promotion to active. However, this requires the answerer to have
RFC 3261 requires that the same answer also be placed in a 200 OK, generated its answer and sent it. In most cases, it will require
which is delivered reliably. However, placing it in a 18x gives the this answer to be received by the offerer. The reason is that
offerer an early preview of the answer, and allows the connectivity connectivity checks or RTP packets from the answerer to the offerer
checks to all occur prior to the user answering the call. However, will not be forwarded by NATs towards the offerer until the offerer
the updated offer with the highest priority valid candidate promoted has established a permission in the NAT by generating a packet
to the m/c-line cannot occur until after the 200 OK, in which case it towards the answerer.
SHOULD be done with a re-INVITE. Fortunately, if the active
candidates in the initial offer/answer exchange end up being valid
anyway, media can flow as soon as the user answers the call (or even
before hand, if early media is needed). The additional offer/answer
exchange in the re-INVITE would merely improve the situation by using
a higher priority candidate pair.
One of the difficulties in including the answer in the 18x, and then For this reason, if an offer is received in an INVITE request, the
using it for connectivity checks, is that the 18x might be lost. In UAS SHOULD immediately gather its candidates and then generate an
such a case, the STUN connectivity check from the answerer to the answer in a provisional response. When reliable provisional
offerer (UAS to UAC) will pend indefinitely. To prevent this, it is responses are not used, the SDP in the provisional response is not
RECOMMENDED that a SIP UA retransmit its 18x periodically, using the formally the answer; the value in the 200 OK is the actual answer.
same exponential backoff defined in RFC 3262, until such time as a However, RFC 3261 allows for SDP to appear in an unreliable
Binding Response is received for any of the Binding Requests it sent. provisional response, in which case its value has to be identical to
the value placed in the 200 OK. Thus, we refer to the SDP in the
provisional response, even when unreliable, as the answer. To deal
with possible losses of the provisional response, it SHOULD be
retransmitted until some indication of receipt. This indication can
either be through PRACK [11], or through the receipt of a STUN
Binding Request with a correct username and password. Furthermore,
once the answer has been sent, the agent SHOULD begin its
connectivity checks. Once a candidate reaches the Valid or Recv-
Valid state, the UAS has a known-valid path for media packets towards
the UAC. This point is called the connected point in ICE.
Once the UAS reaches the connected point, media can be sent from the
UAS towards the UAC without any additional delays. However, between
the receipt of the INVITE and the connected point, any media that
needs to be sent towards the caller (such as SIP early media [29]
cannot be transmitted. For this reason, implementations MAY choose
to delay alerting the called party until the connected point is
reached. In the case of a PSTN gateway, this would mean that the
setup message into the PSTN is delayed until the connected point.
Doing this increases the post-dial delay, but has the effect of
eliminating 'ghost rings'. Ghost rings are cases where the called
party hears the phone ring, picks up, but hears nothing and cannot be
heard. This technique works without requiring support for, or usage
of, preconditions [7], since its a localized decision. It also has
the benefit of guaranteeing that not a single packet of early media
will get clipped. If an agent chooses to delay local alerting in
this way, it SHOULD generate a 180 response once alerting begins.
A slight variation of this approach is to wait for a connectivity
check to succeed to a higher priority candidate pair than the active
one. This allows for the agent to only ever send media, early or
otherwise, to a single candidate, which will work better with jitter
buffers, at the expense of even greater post-dial delays.
Note that, prior to the promotion of a candidate pair to active, the
offerer will not be able to send using the candidate pair. When used
with SIP, if the initial offer is sent in the INVITE, and the answer
is sent in both the provisional and final 200 OK response, the
offerer will not be able to send media until it sends a re-INVITE and
receives the 200 OK response to that re-INVITE. This can take
several hundred milliseconds. If this latency is an issue (it is
generally not considered an issue for voice systems), reliable
provisional responses [11] MAY be used, in which case an UPDATE [27]
can be used to send an updated offer prior to the call being
answered.
As discussed in Section 13, offer/answer exchanges SHOULD be secured As discussed in Section 13, offer/answer exchanges SHOULD be secured
against eavesdropping and man-in-the-middle attacks. To do that, the against eavesdropping and man-in-the-middle attacks. To do that, the
usage of SIPS is RECOMMENDED when used in concert with ICE. usage of SIPS [2] is RECOMMENDED when used in concert with ICE.
9. Interactions with Forking 9. Interactions with Forking
SIP allows INVITE requests carrying offers to fork, which means that SIP allows INVITE requests carrying offers to fork, which means that
they are delivered to multiple user agents. Each of those user they are delivered to multiple user agents. Each of those user
agents then provides an answer to the offer in the INVITE. The agents then provides an answer to the offer in the INVITE. The
result is that a single offer generated by the UAC produces multiple result is that a single offer generated by the UAC produces multiple
answers. answers.
ICE interacts very well with forking. Indeed, ICE fixes some of the ICE interacts very well with forking. Indeed, ICE fixes some of the
skipping to change at page 45, line 18 skipping to change at page 51, line 32
correlate that traffic with a particular remote UA. When SIP is used correlate that traffic with a particular remote UA. When SIP is used
without ICE, the incoming media traffic cannot be disambiguated without ICE, the incoming media traffic cannot be disambiguated
without an additional offer/answer exchange. without an additional offer/answer exchange.
10. Interactions with Preconditions 10. Interactions with Preconditions
Because ICE involves multiple addresses and pre-session activities, Because ICE involves multiple addresses and pre-session activities,
its interactions with preconditions merits further discussion. its interactions with preconditions merits further discussion.
Quality of Service (QoS) preconditions, which are defined in RFC 3312 Quality of Service (QoS) preconditions, which are defined in RFC 3312
[9] and RFC 4032 [10], apply only to the IP addresses and ports [7] and RFC 4032 [8], apply only to the IP addresses and ports listed
listed in the m/c lines in an offer/answer. If ICE changes the in the m/c lines in an offer/answer. If ICE changes the address and
address and port where media is received, this change is reflected in port where media is received, this change is reflected in the m/c
the m/c lines of a new offer/answer. As such, it appears like any lines of a new offer/answer. As such, it appears like any other re-
other re-INVITE would, and is fully treated in RFC 3312 and 4032, INVITE would, and is fully treated in RFC 3312 and 4032, which
which applies without regard to the fact that the m/c lines are applies without regard to the fact that the m/c lines are changing
changing due to ICE negotiations ocurring "in the background". due to ICE negotiations ocurring "in the background".
However, usage of early candidates with QoS preconditions is NOT
RECOMMENDED, since QoS will only be reserved for the candidate pair
in the m/c-line. An agent SHOULD only send to the active candidate
(once it enters the Valid or Recv-Valid states) if QoS preconditions
are used for a media session.
ICE also has (purposeful) interactions with connectivity ICE also has (purposeful) interactions with connectivity
preconditions [14]. Those interactions are described there. preconditions [30]. Those interactions are described there.
11. Example 11. Examples
This section provides an example ICE call flow. Two agents, L and R, This section provides two examples. One is a very basic example, and
are using ICE. Both agents have a single IPv4 interface, and are the other is more elaborate. A common configuration and setup is
configured with a single TURN and single STUN server each (indeed, used in both cases.
the same one for each). As a consequence, each agent will end up
with three candidates - a local candidate, a TURN-derived candidate, Two agents, L and R, are using ICE. Both agents have a single IPv4
and a STUN-derived candidate. The agents are seeking to communicate interface, and are configured with a single STUN server each (indeed,
using a single RTP-based voice stream. As a consequence, each the same one for each). This STUN server supports both the Binding
candidate has two components - one for RTP and one for RTCP. Agent L Discovery usage and the Relay usage. Agent L is behind a NAT, and
is behind a symmetric NAT, and agent R is on the public Internet. agent R is on the public Internet.
To facilitate understanding, transport addresses are listed in a To facilitate understanding, transport addresses are listed in a
mnemonic form. This form is <entity&rt;-<type&rt;-<seq-no&rt;, where mnemonic form. This form is entity-type-seqno, where entity refers
<entity&rt; refers to the entity whose interface the transport to the entity whose interface the transport address is on, and is one
address is on, and is one of "L", "R", "STUN", "TURN", or "NAT". The of "L", "R", "STUN", or "NAT". The type is either "PUB" for
<type&rt; is either "PUB" for transport addresses that are public, transport addresses that are public, and "PRIV" for transport
and "PRIV" for transport addresses that are private. Finally, <seq- addresses that are private. Finally, seq-no is a sequence number
no&rt; is a sequence number that is different for each transport that is different for each transport address of the same type on a
address of the same type on a particular entity. particular entity.
The STUN server has advertised transport address STUN-PUB-1 for STUN The STUN server has advertised transport address STUN-PUB-1 for both
requests, and the TURN server has advertised transport address TURN- the binding discovery usage and the relay usage.
PUB-1 for TURN allocations.
In addition, candidate IDs are also listed in mnemonic form. Agent L In addition, candidate IDs are also listed in mnemonic form. Agent L
uses candidate ID L1 for its local candidate, L2 for its STUN derived uses candidate ID L1 for its local candidate, L2 for its server
candidate, and L3 for its TURN derived candidate. Agent R uses R1 reflexive candidate, and L3 for its relayed candidate. Agent R uses
for its local candidate and R2 for its TURN derived candidate. The R1 for its local candidate and R2 for its relayed candidate. The
passwords for each transport address are LPASS1 through LPASS6 for password is LPASS for each candidate from agent L, and RPASS for each
agent L, and RPASS1 through RPASS4 for agent R. candidate from agent R.
In example SDP messages, $<token&rt;.IP is used to refer to the value In example SDP messages, $TADDR.IP is used to refer to the value of
of the IP address of the transport address with mnemonic name the IP address of the transport address with mnemonic name "taddr".
"token". Similarly, $<token&rt;.PORT is used to refer to the value Similarly, $TADDR.PORT is used to refer to the value of the port of
of the port of the transport address with mnemonic name "token". the transport address with mnemonic name "TADDR".
In the call flow example in Figure 6, STUN and TURN messages are In the call flow itself, STUN messages are annotated with several
annotated with several attributes. The "S=" attribute indicates the attributes. The "S=" attribute indicates the source transport
source transport address of the message. The "D=" attribute address of the message. The "D=" attribute indicates the destination
indicates the destination transport address of the message. The transport address of the message. The "MA=" attribute is used in
"MA=" attribute is used in STUN Binding Response messages, or STUN STUN Binding Response messages, STUN Binding Response messages
Binding Response messages carried in a TURN SEND or TURN DATA carried in a STUN Send Request or Data Indication, and in a Allocate
message, and refers to the value of the MAPPED-ADDRESS attribute in Response, and refers to the value of the MAPPED-ADDRESS attribute.
the STUN Binding Response. The "RA=" attribute is used in TURN DATA The "RA=" attribute is used in STUN Data Indications, and refers to
messages, and refers to the value of the REMOTE-ADDRESS attribute. the value of the REMOTE-ADDRESS attribute. The "U=" attribute is
The "U=" attribute is used in STUN Binding Requests, and corresponds used in STUN Requests, and corresponds to the STUN USERNAME. The
to the STUN USERNAME. Finally, the "DA=" attribute is used in TURN "DA=" attribute is used in STUN Send requests, and refers to the
SEND messages, and refers to the value of the DESTINATION-ADDRESS value of the DESTINATION-ADDRESS attribute. The "R=" attribute is
attribute. used in Allocate responses, and it indicates the value of the RELAY-
ADDRESS attribute.
The call flow example omits STUN authentication operations. The call flow examples omit STUN authentication operations.
11.1 Basic Example
In this example, the NAT has the address and port independent mapping
property and the address dependent permission property. Neither
agent is using the STUN relay usage, only the binding discovery
usage. As a consequence, agent L will end up with two candidates - a
local candidate and a server reflexive candidate. Agent R will have
one - a local candidate (the reflexive candidate will be identical to
the local one, and thus discarded). The agents are seeking to
communicate using a single RTP-based voice stream. RTCP is not used.
As a consequence, each candidate has one component.
L NAT STUN R L NAT STUN R
| | | | | | | |
| | | | | | | |
| | | | | | | |
|RTP STUN alloc. | | |RTP STUN alloc. | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
|(1) STUN Req | | | |(1) STUN Req | | |
skipping to change at page 47, line 20 skipping to change at page 53, line 50
| |<-------------| | | |<-------------| |
| | | | | | | |
|(4) STUN Res | | | |(4) STUN Res | | |
|S=STUN-PUB-1 | | | |S=STUN-PUB-1 | | |
|D=L-PRIV-1 | | | |D=L-PRIV-1 | | |
|MA=NAT-PUB-1 | | | |MA=NAT-PUB-1 | | |
|<-------------| | | |<-------------| | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
|RTCP STUN alloc. | |
|Ta secs. later| | |
| | | | | | | |
|(5) Offer | | |
|------------------------------------------->|
| | | | | | | |
| | | | | | | |
|(5) STUN Req | | |
|S=L-PRIV-2 | | |
|D=STUN-PUB-1 | | |
|------------->| | |
| | | | | | | |
| | | | | | | |
| |(6) STUN Req | | | | | |RTP STUN alloc.
| |S=NAT-PUB-2 | |
| |D=STUN-PUB-1 | |
| |------------->| |
| | | | | | | |
| |(7) STUN Res | |
| |S=STUN-PUB-1 | |
| |D=NAT-PUB-2 | |
| |MA=NAT-PUB-2 | |
| |<-------------| |
| | | | | | | |
|(8) STUN Res | | |
|S=STUN-PUB-1 | | |
|D=L-PRIV-2 | | |
|MA=NAT-PUB-2 | | |
|<-------------| | |
| | | | | | | |
| | |(6) STUN Req |
| | |S=R-PUB-1 |
| | |D=STUN-PUB-1 |
| | |<-------------|
| | | | | | | |
| | |(7) STUN Res |
| | |S=STUN-PUB-1 |
| | |D=R-PUB-1 |
| | |MA=R-PUB-1 |
| | |------------->|
| | | | | | | |
|RTP TURN alloc. | |
|Ta secs. later| | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
|(9) TURN Req | | | |(8) answer | | |
|<-------------------------------------------|
| | | |
| | | |
|(9) Bind Req | | |
|S=L-PRIV-1 | | | |S=L-PRIV-1 | | |
|D=TURN-PUB-1 | | | |D=R-PUB-1 | | |
|------------->| | | |------------->| | |
| | | | | | | |
| | | | | | | |
| |(10) TURN Req | | | |(10) Bind Req | |
| |S=NAT-PUB-3 | | | |S=NAT-PUB-1 | |
| |D=TURN-PUB-1 | | | |D=R-PUB-1 | |
| |------------->| | | |---------------------------->|
| | | | | | | |
| |(11) TURN Res | | | |(11) Bind Res | |
| |S=TURN-PUB-1 | | | |S=R-PUB-1 | |
| |D=NAT-PUB-3 | | | |D=NAT-PUB-1 | |
| |MA=TURN-PUB-2 | | | |MA=NAT-PUB-1 | |
| |<-------------| | | |<----------------------------|
| | | | | | | |
|(12) TURN Res | | | |(12) Bind Res | | |
|S=TURN-PUB-1 | | | |S=R-PUB-1 | | |
|D=L-PRIV-1 | | | |D=L-PRIV-1 | | |
|MA=TURN-PUB-2 | | | |MA=NAT-PUB-1 | | |
|<-------------| | | |<-------------| | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
|RTCP TURN alloc. | | | | | |
|Ta secs. later| | | |RTP flows | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
|(13) TURN Req | | | | |(13) Bind Req | |
|S=L-PRIV-2 | | | | |S=R-PUB-1 | |
|D=TURN-PUB-1 | | | | |D=NAT-PUB-1 | |
| |<----------------------------|
| | | |
| | | |
|(14) Bind Req | | |
|S=R-PUB-1 | | |
|D=L-PRIV-1 | | |
|<-------------| | |
| | | |
|(15) Bind Res | | |
|S=L-PRIV-1 | | |
|D=R-PUB-1 | | |
|MA=R-PUB-1 | | |
|------------->| | | |------------->| | |
| | | | | | | |
| |(16) Bind Res | |
| |S=NAT-PUB-1 | |
| |D=R-PUB-1 | |
| |MA=R-PUB-1 | |
| |---------------------------->|
| | | | | | | |
| |(14) TURN Req | |
| |S=NAT-PUB-4 | |
| |D=TURN-PUB-1 | |
| |------------->| |
| | | | | | | |
| |(15) TURN Res | |
| |S=TURN-PUB-1 | |
| |D=NAT-PUB-4 | |
| |MA=TURN-PUB-3 | |
| |<-------------| |
| | | | | | | |
|(16) TURN Res | | |
|S=TURN-PUB-1 | | |
|D=L-PRIV-2 | | |
|MA=TURN-PUB-3 | | |
|<-------------| | |
| | | | | | | |
| | | |RTP flows
| | | | | | | |
| | | | | | | |
| | | | | | | |
|(17) Offer | | |
|------------------------------------------->|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | |RTP STUN alloc.
Figure 7
First, agent L obtains a server reflexive transport address for its
RTP packets (messages 1-4). Recall that the NAT has the address and
port independent mapping property. Here, it creates a binding of
NAT-PUB-1 for this UDP request, and this becomes the server reflexive
transport address for RTP, the sole component of its server reflexive
candidate.
With its two candidates, agent L prioritizes them, choosing the local
candidate as highest priority, followed by the server reflexive
candidate. It chooses its server reflexive candidate as the active
candidate, and encodes it into the m/c-line. The resulting offer
(message 5) looks like:
v=0
o=jdoe 2890844526 2890842807 IN IP4 $L-PRIV-1.IP
s=
c=IN IP4 $STUN-PUB-1.IP
t=0 0
a=ice-pwd:$LPASS
m=audio $STUN-PUB-1.PORT RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=candidate $L1 1 UDP 1.0 $L-PRIV-1.IP $L-PRIV-1.PORT
a=candidate $L2 1 UDP 0.7 $NAT-PUB-1.IP $NAT-PUB-1.PORT
This offer is received at agent R. Agent R will gather its server
reflexive transport address (messages 6-7). Since R is not behind a
NAT, this address is identical to its local transport address, and
thus does not represent a separate candidate. It therefore ends up
with a single local candidate with a single component for RTP. Its
resulting answer looks like:
v=0
o=bob 2808844564 2808844564 IN IP4 $R-PUB-1.IP
s=
c=IN IP4 $R-PUB-1.IP
t=0 0
a=ice-pwd:$RPASS
m=audio $R-PUB-1.PORT RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=candidate $R1 1 UDP 1.0 $R-PUB-1.IP $R-PUB-1.PORT
Next, agents L and R form candidate pairs and the transport address
check ordered list. This list will start with the single component
in the currently active candidate pair, L2:1:R1:1. Agent L begins
its connectivity checks (messages 9-12), which succeed, placing the
transport address pair and resulting candidate pair into the Recv-
Valid state. Media can now flow. When agent R receives this request
(message 10), the state of the candidate pair moves to Send-Valid.
Agent R begins its connectivity checks (messages 13-16). When the
check arrives at the NAT (message 13), it is permitted to pass since
a permission was created towards $R-PUB-1 as a consequence of message
10. This check arrives at agent L, which generates a success
response (message 11), and updates the state of the candidate pair to
Valid. This response arrives at agent R, which also updates the
state of the candidate pair to valid. Now, media can flow from agent
R to agent L as well.
11.2 Advanced Example
In this more advanced example, The NAT has address and port dependent
mapping and filtering properties. Both agents use the STUN relay
usage in addition to the binding discovery usage. As a consequence,
agent L will end up with three candidates - a local candidate, a
relayed candidate, and a server reflexive candidate. Agent R will
have two - a local candidate and a relayed candidate (the server
reflexive candidate will equal the local candidate and thus not be
used). The agents are seeking to communicate using a single RTP-
based voice stream, but are using RTCP. As a consequence, each
candidate has two components - one for RTP and one for RTCP.
L NAT STUN R
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | |(18) STUN Req | |RTP Alloc. | | |
| | |S=R-PUB-1 |
| | |D=STUN-PUB-1 |
| | |<-------------|
| | | | | | | |
| | |(19) STUN Res |
| | |S=STUN-PUB-1 |
| | |D=R-PUB-1 |
| | |MA=R-PUB-1 |
| | |------------->|
| | | | | | | |
| | | | | | | |
|(1) Alloc Req | | |
|S=L-PRIV-1 | | |
|D=STUN-PUB-1 | | |
|------------->| | |
| | | | | | | |
| | | |RTCP STUN alloc.
| | | |Ta secs. later
| | | | | | | |
| |(2) Alloc Req | |
| |S=NAT-PUB-1 | |
| |D=STUN-PUB-1 | |
| |------------->| |
| |(3) Alloc Res | |
| |S=STUN-PUB-1 | |
| |D=NAT-PUB-1 | |
| |R=STUN-PUB-2 | |
| |MA=NAT-PUB-1 | |
| |<-------------| |
|(4) Alloc Res | | |
|S=STUN-PUB-1 | | |
|D=L-PRIV-1 | | |
|R=STUN-PUB-2 | | |
|MA=NAT-PUB-1 | | |
|<-------------| | |
| | | | | | | |
| | | | | | | |
| | |(20) STUN Req |
| | |S=R-PUB-2 |
| | |D=STUN-PUB-1 |
| | |<-------------|
| | | | | | | |
| | |(21) STUN Res | |RTCP Alloc. | | |
| | |S=STUN-PUB-1 | |Ta secs. later| | |
| | |D=R-PUB-2 |
| | |MA=R-PUB-2 |
| | |------------->|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | |RTP TURN alloc. |(5) Alloc Req | | |
| | | |Ta secs. later |S=L-PRIV-2 | | |
|D=STUN-PUB-1 | | |
|------------->| | |
| | | | | | | |
| | | | | | | |
| |(6) Alloc Req | |
| |S=NAT-PUB-2 | |
| |D=STUN-PUB-1 | |
| |------------->| |
| |(7) Alloc Res | |
| |S=STUN-PUB-1 | |
| |D=NAT-PUB-2 | |
| |R=STUN-PUB-3 | |
| |MA=NAT-PUB-2 | |
| |<-------------| |
|(8) Alloc Res | | |
|S=STUN-PUB-1 | | |
|D=L-PRIV-2 | | |
|R=STUN-PUB-3 | | |
|MA=NAT-PUB-2 | | |
|<-------------| | |
| | | | | | | |
| | |(22) TURN Req | | | | |
| | | |
| | | |
|(9) Offer | | |
|------------------------------------------->|
| | | |
| | | |
| | | |
| | | |
| | | |RTP Alloc.
| | | |
| | | |
| | | |
| | |(10) Alloc Req|
| | |S=R-PUB-1 | | | |S=R-PUB-1 |
| | |D=TURN-PUB-1 | | | |D=STUN-PUB-1 |
| | |<-------------| | | |<-------------|
| | | | | | |(11) Alloc Res|
| | |(23) TURN Res | | | |S=STUN-PUB-1 |
| | |S=TURN-PUB-1 |
| | |D=R-PUB-1 | | | |D=R-PUB-1 |
| | |MA=TURN-PUB-4 | | | |R=STUN-PUB-4 |
| | |MA=R-PUB-1 |
| | |------------->| | | |------------->|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | |RTCP TURN alloc. | | | |RTCP Alloc.
| | | |Ta secs. later | | | |Ta secs. later
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | |(24) TURN Req | | | |(12) Alloc Req|
| | |S=R-PUB-2 | | | |S=R-PUB-2 |
| | |D=TURN-PUB-1 | | | |D=STUN-PUB-1 |
| | |<-------------| | | |<-------------|
| | | | | | |(13) Alloc Res|
| | |(25) TURN Res | | | |S=STUN-PUB-1 |
| | |S=TURN-PUB-1 |
| | |D=R-PUB-2 | | | |D=R-PUB-2 |
| | |MA=TURN-PUB-5 | | | |R=STUN-PUB-5 |
| | |MA=R-PUB-2 |
| | |------------->| | | |------------->|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
|(26) answer | | | |(14) answer | | |
|<-------------------------------------------| |<-------------------------------------------|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | |Validate | | | |Validate
| | | |TURN-PUB-4 to TURN-PUB-2 | | | |STUN-PUB-4 to STUN-PUB-2
| | | | | | | |
| | | | | | | |
| | |(27) TURN SEND| | | |(15) Send Ind |
| | |S=R-PUB-1 | | | |S=R-PUB-1 |
| | |D=TURN-PUB-1 | | | |D=STUN-PUB-1 |
| | |DA=TURN-PUB-2 | | | |DA=STUN-PUB-2 |
| | |<-------------| | | |<-------------|
| | | | | | | |
| | |STUN Req. | | | |Bind Req. |
| | |S=TURN-PUB-4 | | | |S=STUN-PUB-4 |
| | |D=TURN-PUB-2 | | | |D=STUN-PUB-2 |
| | |U=L3:1:R2:1 | | | |U=L3:1:R2:1 |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | |Discard | | | |Discard |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
|Validate | | | |Validate | | |
|TURN-PUB-2 to TURN-PUB-4 | | |STUN-PUB-2 to STUN-PUB-4 | |
| | | | | | | |
| | | | | | | |
|(28) TURN SEND| | | |(16) Send Ind | | |
|S=L-PRIV-1 | | | |S=L-PRIV-1 | | |
|D=TURN-PUB-1 | | | |D=STUN-PUB-1 | | |
|DA=TURN-PUB-4 | | | |DA=STUN-PUB-4 | | |
|------------->| | | |------------->| | |
| | | | | | | |
| |(29) TURN SEND| | | |(17) Send Ind | |
| |S=NAT-PUB-3 | | | |S=NAT-PUB-1 | |
| |D=TURN-PUB-1 | | | |D=STUN-PUB-1 | |
| |DA=TURN-PUB-4 | | | |DA=STUN-PUB-4 | |
| |------------->| | | |------------->| |
| | | | | | | |
| | |STUN Req. | | | |Bind Req. |
| | |S=TURN-PUB-2 | | | |S=STUN-PUB-2 |
| | |D=TURN-PUB-4 | | | |D=STUN-PUB-4 |
| | |U=R2:1:L3:1 | | | |U=R2:1:L3:1 |
| | | | | | | |
| | | | | | | |
| | |(30) TURN DATA| | | |(18) Data Ind |
| | |S=TURN-PUB-1 | | | |S=STUN-PUB-1 |
| | |D=R-PUB-1 | | | |D=R-PUB-1 |
| | |RA=TURN-PUB-2 | | | |RA=STUN-PUB-2 |
| | |------------->| | | |------------->|
| | |(31) TURN SEND| | | |(19) Send Ind |
| | |S=R-PUB-1 | | | |S=R-PUB-1 |
| | |D=TURN-PUB-1 | | | |D=STUN-PUB-1 |
| | |DA=TURN-PUB-2 | | | |DA=STUN-PUB-2 |
| | |MA=TURN-PUB-2 | | | |MA=STUN-PUB-2 |
| | |<-------------| | | |<-------------|
| | | | | | | |
| | |STUN Res. | | | |Bind Res. |
| | |S=TURN-PUB-4 | | | |S=STUN-PUB-4 |
| | |D=TURN-PUB-2 | | | |D=STUN-PUB-2 |
| | |MA=TURN-PUB-2 | | | |MA=STUN-PUB-2 |
| | | | | | | |
| |(32) TURN DATA| | | |(20) Data Ind | |
| |S=TURN-PUB-1 | | | |S=STUN-PUB-1 | |
| |D=NAT-PUB-3 | | | |D=NAT-PUB-1 | |
| |RA=TURN-PUB-4 | | | |RA=STUN-PUB-4 | |
| |MA=TURN-PUB-2 | | | |MA=STUN-PUB-2 | |
| |<-------------| | | |<-------------| |
|(33) TURN DATA| | | |(21) Data Ind | | |
|S=TURN-PUB-1 | | | |S=STUN-PUB-1 | | |
|D=L-PRIV-1 | | | |D=L-PRIV-1 | | |
|RA=TURN-PUB-4 | | | |RA=STUN-PUB-4 | | |
|MA=TURN-PUB-2 | | | |MA=STUN-PUB-2 | | |
|<-------------| | | |<-------------| | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | |Validate | | | |Validate
| | | |TURN-PUB-4 to TURN-PUB-2 | | | |STUN-PUB-4 to STUN-PUB-2
| | | | | | | |
| | | | | | | |
| | |(34) TURN SEND| | | |(22) Send Ind |
| | |S=R-PUB-1 | | | |S=R-PUB-1 |
| | |D=TURN-PUB-1 | | | |D=STUN-PUB-1 |
| | |DA=TURN-PUB-2 | | | |DA=STUN-PUB-2 |
| | |<-------------| | | |<-------------|
| | | | | | | |
| | |STUN Req. | | | |Bind Req. |
| | |S=TURN-PUB-4 | | | |S=STUN-PUB-4 |
| | |D=TURN-PUB-2 | | | |D=STUN-PUB-2 |
| | |U=L3:1:R2:1 | | | |U=L3:1:R2:1 |
| | | | | | | |
| | | | | | | |
| |(35) TURN DATA| | | |(23) Data Ind | |
| |S=TURN-PUB-1 | | | |S=STUN-PUB-1 | |
| |D=NAT-PUB-3 | | | |D=NAT-PUB-1 | |
| |RA=TURN-PUB-4 | | | |RA=STUN-PUB-4 | |
| |<-------------| | | |<-------------| |
| | | | | | | |
|(36) TURN DATA| | | |(24) Data Ind | | |
|S=TURN-PUB-1 | | | |S=STUN-PUB-1 | | |
|D=L-PRIV-1 | | | |D=L-PRIV-1 | | |
|RA=TURN-PUB-4 | | | |RA=STUN-PUB-4 | | |
|<-------------| | | |<-------------| | |
|(37) TURN SEND| | | |(25) Send Ind | | |
|S=L-PRIV-1 | | | |S=L-PRIV-1 | | |
|D=TURN-PUB-1 | | | |D=STUN-PUB-1 | | |
|DA=TURN-PUB-4 | | | |DA=STUN-PUB-4 | | |
|MA=TURN-PUB-4 | | | |MA=STUN-PUB-4 | | |
|------------->| | | |------------->| | |
| |(38) TURN SEND| | | |(26) Send Ind | |
| |S=NAT-PUB-3 | | | |S=NAT-PUB-1 | |
| |D=TURN-PUB-1 | | | |D=STUN-PUB-1 | |
| |DA=TURN-PUB-4 | | | |DA=STUN-PUB-4 | |
| |MA=TURN-PUB-4 | | | |MA=STUN-PUB-4 | |
| |------------->| | | |------------->| |
| | | | | | | |
| | |STUN Res. | | | |Bind Res. |
| | |S=TURN-PUB-2 | | | |S=STUN-PUB-2 |
| | |D=TURN-PUB-4 | | | |D=STUN-PUB-4 |
| | |MA=TURN-PUB-4 | | | |MA=STUN-PUB-4 |
| | | | | | | |
| | |(39) TURN DATA| | | |(27) Data Ind |
| | |S=TURN-PUB-1 | | | |S=STUN-PUB-1 |
| | |D=R-PUB-1 | | | |D=R-PUB-1 |
| | |RA=TURN-PUB-2 | | | |RA=STUN-PUB-2 |
| | |MA=TURN-PUB-4 | | | |MA=STUN-PUB-4 |
| | |------------->| | | |------------->|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | |Validate | | | |Validate
| | | |TURN-PUB-5 to TURN-PUB-3 | | | |STUN-PUB-5 to STUN-PUB-3
| | | | | | | |
| | | | | | | |
| | |(40) TURN SEND| | | |(28) Send Ind |
| | |S=R-PUB-2 | | | |S=R-PUB-2 |
| | |D=TURN-PUB-1 | | | |D=STUN-PUB-1 |
| | |DA=TURN-PUB-3 | | | |DA=STUN-PUB-3 |
| | |<-------------| | | |<-------------|
| | | | | | | |
| | |STUN Req. | | | |Bind Req. |
| | |S=TURN-PUB-5 | | | |S=STUN-PUB-5 |
| | |D=TURN-PUB-3 | | | |D=STUN-PUB-3 |
| | |U=L3:2:R2:2 | | | |U=L3:2:R2:2 |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | |Discard | | | |Discard |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
|Validate | | | |Validate | | |
|TURN-PUB-3 to TURN-PUB-5 | | |STUN-PUB-3 to STUN-PUB-5 | |
| | | | | | | |
| | | | | | | |
|(41) TURN SEND| | | |(29) Send Ind | | |
|S=L-PRIV-2 | | | |S=L-PRIV-2 | | |
|D=TURN-PUB-1 | | | |D=STUN-PUB-1 | | |
|DA=TURN-PUB-5 | | | |DA=STUN-PUB-5 | | |
|------------->| | | |------------->| | |
| | | | | | | |
| |(42) TURN SEND| | | |(30) Send Ind | |
| |S=NAT-PUB-4 | | | |S=NAT-PUB-2 | |
| |D=TURN-PUB-1 | | | |D=STUN-PUB-1 | |
| |DA=TURN-PUB-5 | | | |DA=STUN-PUB-5 | |
| |------------->| | | |------------->| |
| | | | | | | |
| | |STUN Req. | | | |Bind Req. |
| | |S=TURN-PUB-3 | | | |S=STUN-PUB-3 |
| | |D=TURN-PUB-5 | | | |D=STUN-PUB-5 |
| | |U=R2:2:L3:2 | | | |U=R2:2:L3:2 |
| | | | | | | |
| | | | | | | |
| | |(43) TURN DATA| | | |(31) Data Ind |
| | |S=TURN-PUB-1 | | | |S=STUN-PUB-1 |
| | |D=R-PUB-2 | | | |D=R-PUB-2 |
| | |RA=TURN-PUB-3 | | | |RA=STUN-PUB-3 |
| | |------------->| | | |------------->|
| | |(44) TURN SEND| | | |(32) Send Ind |
| | |S=R-PUB-2 | | | |S=R-PUB-2 |
| | |D=TURN-PUB-1 | | | |D=STUN-PUB-1 |
| | |DA=TURN-PUB-3 | | | |DA=STUN-PUB-3 |
| | |MA=TURN-PUB-3 | | | |MA=STUN-PUB-3 |
| | |<-------------| | | |<-------------|
| | | | | | | |
| | |STUN Res. | | | |Bind Res. |
| | |S=TURN-PUB-5 | | | |S=STUN-PUB-5 |
| | |D=TURN-PUB-3 | | | |D=STUN-PUB-3 |
| | |MA=TURN-PUB-3 | | | |MA=STUN-PUB-3 |
| | | | | | | |
| |(45) TURN DATA| | | |(33) Data Ind | |
| |S=TURN-PUB-1 | | | |S=STUN-PUB-1 | |
| |D=NAT-PUB-4 | | | |D=NAT-PUB-2 | |
| |RA=TURN-PUB-5 | | | |RA=STUN-PUB-5 | |
| |MA=TURN-PUB-3 | | | |MA=STUN-PUB-3 | |
| |<-------------| | | |<-------------| |
|(46) TURN DATA| | | |(34) Data Ind | | |
|S=TURN-PUB-1 | | | |S=STUN-PUB-1 | | |
|D=L-PRIV-2 | | | |D=L-PRIV-2 | | |
|RA=TURN-PUB-5 | | | |RA=STUN-PUB-5 | | |
|MA=TURN-PUB-3 | | | |MA=STUN-PUB-3 | | |
|<-------------| | | |<-------------| | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | |Validate | | | |Validate
| | | |TURN-PUB-5 to TURN-PUB-3 | | | |STUN-PUB-5 to STUN-PUB-3
| | | | | | | |
| | | | | | | |
| | |(47) TURN SEND| | | |(35) Send Ind |
| | |S=R-PUB-2 | | | |S=R-PUB-2 |
| | |D=TURN-PUB-1 | | | |D=STUN-PUB-1 |
| | |DA=TURN-PUB-3 | | | |DA=STUN-PUB-3 |
| | |<-------------| | | |<-------------|
| | | | | | | |
| | |STUN Req. | | | |Bind Req. |
| | |S=TURN-PUB-5 | | | |S=STUN-PUB-5 |
| | |D=TURN-PUB-3 | | | |D=STUN-PUB-3 |
| | |U=L3:2:R2:2 | | | |U=L3:2:R2:2 |
| | | | | | | |
| | | | | | | |
| |(48) TURN DATA| | | |(36) Data Ind | |
| |S=TURN-PUB-1 | | | |S=STUN-PUB-1 | |
| |D=NAT-PUB-4 | | | |D=NAT-PUB-2 | |
| |RA=TURN-PUB-5 | | | |RA=STUN-PUB-5 | |
| |<-------------| | | |<-------------| |
| | | | | | | |
|(49) TURN DATA| | | |(37) Data Ind | | |
|S=TURN-PUB-1 | | | |S=STUN-PUB-1 | | |
|D=L-PRIV-2 | | | |D=L-PRIV-2 | | |
|RA=TURN-PUB-5 | | | |RA=STUN-PUB-5 | | |
|<-------------| | | |<-------------| | |
|(50) TURN SEND| | | |(38) Send Ind | | |
|S=L-PRIV-2 | | | |S=L-PRIV-2 | | |
|D=TURN-PUB-1 | | | |D=STUN-PUB-1 | | |
|DA=TURN-PUB-5 | | | |DA=STUN-PUB-5 | | |
|MA=TURN-PUB-5 | | | |MA=STUN-PUB-5 | | |
|------------->| | | |------------->| | |
| |(51) TURN SEND| | | |(39) Send Ind | |
| |S=NAT-PUB-4 | | | |S=NAT-PUB-2 | |
| |D=TURN-PUB-1 | | | |D=STUN-PUB-1 | |
| |DA=TURN-PUB-5 | | | |DA=STUN-PUB-5 | |
| |MA=TURN-PUB-5 | | | |MA=STUN-PUB-5 | |
| |------------->| | | |------------->| |
| | | | | | | |
| | |STUN Res. | | | |Bind Res. |
| | |S=TURN-PUB-3 | | | |S=STUN-PUB-3 |
| | |D=TURN-PUB-5 | | | |D=STUN-PUB-5 |
| | |MA=TURN-PUB-5 | | | |MA=STUN-PUB-5 |
| | | | | | | |
| | |(52) TURN DATA| | | |(40) Data Ind |
| | |S=TURN-PUB-1 | | | |S=STUN-PUB-1 |
| | |D=R-PUB-2 | | | |D=R-PUB-2 |
| | |RA=TURN-PUB-3 | | | |RA=STUN-PUB-3 |
| | |MA=TURN-PUB-5 | | | |MA=STUN-PUB-5 |
| | |------------->| | | |------------->|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
|RTP flows | | | |RTP flows | | |
| | | | | | | |
| | | | | | | |
|(53) TURN SEND| | | |(41) Send Ind | | |
|S=L-PRIV-1 | | | |S=L-PRIV-1 | | |
|D=TURN-PUB-1 | | | |D=STUN-PUB-1 | | |
|DA=TURN-PUB-4 | | | |DA=STUN-PUB-4 | | |
|------------->| | | |------------->| | |
| | | | | | | |
| |(54) TURN SEND| | | |(42) Send Ind | |
| |S=NAT-PUB-3 | | | |S=NAT-PUB-1 | |
| |D=TURN-PUB-1 | | | |D=STUN-PUB-1 | |
| |DA=TURN-PUB-4 | | | |DA=STUN-PUB-4 | |
| |------------->| | | |------------->| |
| | | | | | | |
| | | | | | | |
| | |RTP | | | |RTP |
| | |S=TURN-PUB-2 | | | |S=STUN-PUB-2 |
| | |D=TURN-PUB-4 | | | |D=STUN-PUB-4 |
| | | | | | | |
| | | | | | | |
| | |(55) TURN DATA| | | |(43) Data Ind |
| | |S=TURN-PUB-1 | | | |S=STUN-PUB-1 |
| | |D=R-PUB-1 | | | |D=R-PUB-1 |
| | |RA=TURN-PUB-2 | | | |RA=STUN-PUB-2 |
| | |------------->| | | |------------->|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | |RTP flows | | | |RTP flows
| | | | | | | |
| | | | | | | |
| | |(56) TURN SEND| | | |(44) Send Ind |
| | |S=R-PUB-1 | | | |S=R-PUB-1 |
| | |D=TURN-PUB-1 | | | |D=STUN-PUB-1 |
| | |DA=TURN-PUB-2 | | | |DA=STUN-PUB-2 |
| | |<-------------| | | |<-------------|
| | | | | | | |
| | | | | | | |
| | |RTP | | | |RTP |
| | |S=TURN-PUB-4 | | | |S=STUN-PUB-4 |
| | |D=TURN-PUB-2 | | | |D=STUN-PUB-2 |
| | | | | | | |
| | | | | | | |
| |(57) TURN DATA| | | |(45) Data Ind | |
| |S=TURN-PUB-1 | | | |S=STUN-PUB-1 | |
| |D=NAT-PUB-3 | | | |D=NAT-PUB-1 | |
| |RA=TURN-PUB-4 | | | |RA=STUN-PUB-4 | |
| |<-------------| | | |<-------------| |
| | | | | | | |
|(58) TURN DATA| | | |(46) Data Ind | | |
|S=TURN-PUB-1 | | | |S=STUN-PUB-1 | | |
|D=L-PRIV-1 | | | |D=L-PRIV-1 | | |
|RA=TURN-PUB-4 | | | |RA=STUN-PUB-4 | | |
|<-------------| | | |<-------------| | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
|Validate | | | |Validate | | |
|L-PRIV-1 to R-PUB-1 | | |L-PRIV-1 to R-PUB-1 | |
| | | | | | | |
| | | | | | | |
|(59) STUN Req.| | | |(47) Bind Req.| | |
|S=L-PRIV-1 | | | |S=L-PRIV-1 | | |
|D=R-PUB-1 | | | |D=R-PUB-1 | | |
|U=R1:1:L1:1 | | | |U=R1:1:L1:1 | | |
|------------->| | | |------------->| | |
| | | | | | | |
| |(60) STUN Req.| | | |(48) Bind Req.| |
| |S=NAT-PUB-5 | | | |S=NAT-PUB-3 | |
| |D=R-PUB-1 | | | |D=R-PUB-1 | |
| |U=R1:1:L1:1 | | | |U=R1:1:L1:1 | |
| |---------------------------->| | |---------------------------->|
| | | | | | | |
| |(61) STUN Res.| | | |(49) Bind Res.| |
| |S=R-PUB-1 | | | |S=R-PUB-1 | |
| |D=NAT-PUB-5 | | | |D=NAT-PUB-3 | |
| |MA=NAT-PUB-5 | | | |MA=NAT-PUB-3 | |
| |<----------------------------| | |<----------------------------|
| | | | | | | |
|(62) STUN Res.| | | |(50) Bind Res.| | |
|S=R-PUB-1 | | | |S=R-PUB-1 | | |
|D=L-PRIV-1 | | | |D=L-PRIV-1 | | |
|MA-NAT-PUB-5 | | | |MA-NAT-PUB-3 | | |
|<-------------| | | |<-------------| | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | |Validate | | | |Validate
| | | |R-PUB-1 to L-PRIV-1 | | | |R-PUB-1 to L-PRIV-1
| | | | | | | |
| | | | | | | |
| |(63) STUN Req.| | | |(51) Bind Req.| |
| |S=R-PUB-1 | | | |S=R-PUB-1 | |
| |D=L-PRIV-1 | | | |D=L-PRIV-1 | |
| |U=L1:1:R1:1 | | | |U=L1:1:R1:1 | |
| |<----------------------------| | |<----------------------------|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| |Discard | | | |Discard | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | |Validate | | | |Validate
| | | |R-PUB-2 to L-PRIV-2 | | | |R-PUB-2 to L-PRIV-2
| | | | | | | |
| | | | | | | |
| |(64) STUN Req.| | | |(52) Bind Req.| |
| |S=R-PUB-2 | | | |S=R-PUB-2 | |
| |D=L-PRIV-2 | | | |D=L-PRIV-2 | |
| |U=L1:2:R1:2 | | | |U=L1:2:R1:2 | |
| |<----------------------------| | |<----------------------------|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| |Discard | | | |Discard | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
|Validate | | | |Validate | | |
|L-PRIV-2 to R-PUB-2 | | |L-PRIV-2 to R-PUB-2 | |
| | | | | | | |
| | | | | | | |
|(65) STUN Req.| | | |(53) Bind Req.| | |
|S=L-PRIV-2 | | | |S=L-PRIV-2 | | |
|D=R-PUB-2 | | | |D=R-PUB-2 | | |
|U=R1:2:L1:2 | | | |U=R1:2:L1:2 | | |
|------------->| | | |------------->| | |
| | | | | | | |
| |(66) STUN Req.| | | |(54) Bind Req.| |
| |S=NAT-PUB-6 | | | |S=NAT-PUB-4 | |
| |D=R-PUB-2 | | | |D=R-PUB-2 | |
| |U=R1:2:L1:2 | | | |U=R1:2:L1:2 | |
| |---------------------------->| | |---------------------------->|
| | | | | | | |
| |(67) STUN Res.| | | |(55) Bind Res.| |
| |S=R-PUB-2 | | | |S=R-PUB-2 | |
| |D=NAT-PUB-6 | | | |D=NAT-PUB-4 | |
| |MA=NAT-PUB-6 | | | |MA=NAT-PUB-4 | |
| |<----------------------------| | |<----------------------------|
| | | | | | | |
|(68) STUN Res.| | | |(56) Bind Res.| | |
|S=R-PUB-2 | | | |S=R-PUB-2 | | |
|D=L-PRIV-2 | | | |D=L-PRIV-2 | | |
|MA=NAT-PUB-6 | | | |MA=NAT-PUB-4 | | |
|<-------------| | | |<-------------| | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | |Validate | | | |Validate
| | | |R-PUB-1 to NAT-PUB-5 | | | |R-PUB-1 to NAT-PUB-3
| | | | | | | |
| | | | | | | |
| |(69) STUN Req.| | | |(57) Bind Req.| |
| |S=R-PUB-1 | | | |S=R-PUB-1 | |
| |D=NAT-PUB-5 | | | |D=NAT-PUB-3 | |
| |U=L1R1:1:R1:1 | | | |U=L1R1:1:R1:1 | |
| |<----------------------------| | |<----------------------------|
| | | | | | | |
|(70) STUN Req.| | | |(58) Bind Req.| | |
|S=R-PUB-1 | | | |S=R-PUB-1 | | |
|D=L-PRIV-1 | | | |D=L-PRIV-1 | | |
|U=L1R1:1:R1:1 | | | |U=L1R1:1:R1:1 | | |
|<-------------| | | |<-------------| | |
| | | | | | | |
|(71) STUN Res.| | | |(59) Bind Res.| | |
|S=L-PRIV-1 | | | |S=L-PRIV-1 | | |
|D=R-PUB-1 | | | |D=R-PUB-1 | | |
|MA=R-PUB-1 | | | |MA=R-PUB-1 | | |
|------------->| | | |------------->| | |
| | | | | | | |
| |(72) STUN Res.| | | |(60) Bind Res.| |
| |S=NAT-PUB-5 | | | |S=NAT-PUB-3 | |
| |D=R-PUB-1 | | | |D=R-PUB-1 | |
| |MA=R-PUB-1 | | | |MA=R-PUB-1 | |
| |---------------------------->| | |---------------------------->|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | |Validate | | | |Validate
| | | |R-PUB-2 to NAT-PUB-6 | | | |R-PUB-2 to NAT-PUB-4
| | | | | | | |
| | | | | | | |
| |(73) STUN Req.| | | |(61) Bind Req.| |
| |S=R-PUB-2 | | | |S=R-PUB-2 | |
| |D=NAT-PUB-6 | | | |D=NAT-PUB-4 | |
| |U=L1R1:2:R1:2 | | | |U=L1R1:2:R1:2 | |
| |<----------------------------| | |<----------------------------|
| | | | | | | |
|(74) STUN Req.| | | |(62) Bind Req.| | |
|S=R-PUB-2 | | | |S=R-PUB-2 | | |
|D=L-PRIV-2 | | | |D=L-PRIV-2 | | |
|U=L1R1:2:R1:2 | | | |U=L1R1:2:R1:2 | | |
|<-------------| | | |<-------------| | |
| | | | | | | |
|(75) STUN Res.| | | |(63) Bind Res.| | |
|S=L-PRIV-2 | | | |S=L-PRIV-2 | | |
|D=R-PUB-2 | | | |D=R-PUB-2 | | |
|MA=R-PUB-2 | | | |MA=R-PUB-2 | | |
|------------->| | | |------------->| | |
| | | | | | | |
| |(76) STUN Res.| | | |(64) Bind Res.| |
| |S=NAT-PUB-6 | | | |S=NAT-PUB-4 | |
| |D=R-PUB-2 | | | |D=R-PUB-2 | |
| |MA=R-PUB-2 | | | |MA=R-PUB-2 | |
| |---------------------------->| | |---------------------------->|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
|(77) Offer | | | |(65) Offer | | |
|------------------------------------------->| |------------------------------------------->|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
|(78) Answer | | | |(66) Answer | | |
|<-------------------------------------------| |<-------------------------------------------|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
Figure 6 Figure 10
First, agent L obtains a STUN derived transport address for its RTP
packets (messages 1-4). Recall that the NAT is symmetric. Here, it
creates a binding of NAT-PUB-1 for this UDP request, and this becomes
the STUN derived transport address for RTP. Agent L repeats this
process for RTCP (messages 5-8) Ta seconds later, and obtains NAT-
PUB-2 as its STUN derived transport address for RTCP. The two
transport addresses are the two components of the STUN derived
candidate that agent L has just obtained.
Next, agent L will allocate a TURN derived transport address for RTP First, agent L obtains both server reflexive and relayed transport
(messages 9-12) and RTCP (messages 13-16). This produces TURN-PUB-2 addresses for its RTP packets, using a STUN Allocate request, which
and TURN-PUB-3 for RTP and RTCP, respectively. will provide it with both types of addresses (messages 1-4). Recall
that the NAT has the address and port dependent mapping property.
Here, it creates a binding of NAT-PUB-1 for this UDP request, and
this becomes the server reflexive transport address for RTP. The
relayed transport address is STUN-PUB-2, allocated by the STUN
server. Agent L repeats this process for RTCP (messages 5-8) Ta
seconds later, and obtains NAT-PUB-2 as its server reflexive
transport address for RTCP and STUN-PUB-3 for its relayed transport
address.
With its three candidates, agent L prioritizes them, choosing the With its three candidates, agent L prioritizes them, choosing the
local candidate as highest priority, followed by the STUN derived local candidate as highest priority, followed by the server reflexive
candidate, followed by the TURN-derived candidate. It chooses its candidate, followed by the relayed candidate. It chooses its relayed
TURN derived candidate as the active candidate, and encodes it into candidate as the active candidate, and encodes it into the m/c-line.
the m/c-line. The resulting offer (message 17) looks like: The resulting offer (message 17) looks like:
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 $TURN-PUB-2.IP c=IN IP4 $STUN-PUB-2.IP
t=0 0 t=0 0
m=audio $TURN-PUB-2.PORT RTP/AVP 0 a=ice-pwd:$LPASS
m=audio $STUN-PUB-2.PORT RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtcp:$TURN-PUB-3.PORT a=rtcp:$STUN-PUB-3.PORT
a=candidate $L1 1 $L-PASS1 UDP 1.0 $L-PRIV-1.IP $L-PRIV-1.PORT a=candidate $L1 1 UDP 1.0 $L-PRIV-1.IP $L-PRIV-1.PORT
a=candidate $L1 2 $L-PASS2 UDP 1.0 $L-PRIV-2.IP $L-PRIV-2.PORT a=candidate $L1 2 UDP 1.0 $L-PRIV-2.IP $L-PRIV-2.PORT
a=candidate $L2 1 $L-PASS3 UDP 0.7 $NAT-PUB-1.IP $NAT-PUB-1.PORT a=candidate $L2 1 UDP 0.7 $NAT-PUB-1.IP $NAT-PUB-1.PORT
a=candidate $L2 2 $L-PASS4 UDP 0.7 $NAT-PUB-2.IP $NAT-PUB-2.PORT a=candidate $L2 2 UDP 0.7 $NAT-PUB-2.IP $NAT-PUB-2.PORT
a=candidate $L3 1 $L-PASS5 UDP 0.3 $TURN-PUB-2.IP $TURN-PUB-2.PORT a=candidate $L3 1 UDP 0.3 $STUN-PUB-2.IP $STUN-PUB-2.PORT
a=candidate $L3 2 $L-PASS6 UDP 0.3 $TURN-PUB-3.IP $TURN-PUB-3.PORT a=candidate $L3 2 UDP 0.3 $STUN-PUB-3.IP $STUN-PUB-3.PORT
This offer is received at agent R. Agent R will gather its STUN This offer is received at agent R. Agent R will gather its server
derived RTP transport address (messages 18-19) and RTCP address reflexive and relayed transport addresses for RTP from an Allocate
(messages 20-21). Since the result of the STUN allocations did not request (messages 10-11). Since the server reflexive transport
provide a new set of transport addresses, there will not be a address matches its local transport address, no separate candidate is
separate candidate for them. Agent R then gathers its TURN derived used for it. The agent then gathers its server reflexive and relayed
RTP transport address (messages 22-23) and TURN derived RTCP transport addresses for RTCP (messages 12-13). It prioritizes the
transport addresses (messages 24-25). Agent R now has two local candidate with higher priority than the relayed candidate, and
candidates. It prioritizes the local candidate with higher priority selects the relayed candidate as the active candidate. Its resulting
than the TURN candidate, and selects the TURN candidate as the active 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 $TURN-PUB-4.IP c=IN IP4 $STUN-PUB-4.IP
t=0 0 t=0 0
m=audio $TURN-PUB-4.PORT RTP/AVP 0 a=ice-pwd:$RPASS
m=audio $STUN-PUB-4.PORT RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtcp:$TURN-PUB-5.PORT a=rtcp:$STUN-PUB-5.PORT
a=candidate $R1 1 $R-PASS1 UDP 1.0 $R-PUB-1.IP $R-PUB-1.PORT a=candidate $R1 1 UDP 1.0 $R-PUB-1.IP $R-PUB-1.PORT
a=candidate $R1 2 $R-PASS2 UDP 1.0 $R-PUB-2.IP $R-PUB-2.PORT a=candidate $R1 2 UDP 1.0 $R-PUB-2.IP $R-PUB-2.PORT
a=candidate $R2 1 $R-PASS3 UDP 0.3 $TURN-PUB-4.IP $TURN-PUB-4.PORT a=candidate $R2 1 UDP 0.3 $STUN-PUB-4.IP $STUN-PUB-4.PORT
a=candidate $R2 2 $R-PASS4 UDP 0.3 $TURN-PUB-5.IP $TURN-PUB-5.PORT a=candidate $R2 2 UDP 0.3 $STUN-PUB-5.IP $STUN-PUB-5.PORT
Next, agents L and R form candidate pairs and the transport address Next, agents L and R form candidate pairs and the transport address
check ordered list. This list will start with the two components in check ordered list. This list will start with the two components in
the currently active candidate pair - TURN. Agent R begins its the currently active candidate pair - relayed candidates. Agent R
checks (message 27). It will check connectivity between the active begins its checks (message 15). It will check connectivity between
candidate pair, starting with the first component, which is the active candidate pair, starting with the first component, which
TURN-PUB-4 for agent R and TURN-PUB-2 for agent L. The state machine is STUN-PUB-4 for agent R and STUN-PUB-2 for agent L. The state
for that transport address pair moves to the Testing state. Since machine for that transport address pair moves to the Testing state.
this is a TURN-derived transport address for agent R, it utilizes the Since this is a relayed transport address for agent R, it utilizes
TURN SEND mechanism to deliver the Binding Request. The DESTINATION- the STUN Send Indication to deliver the Binding Request. The
ADDRESS is TURN-PUB-2. DESTINATION-ADDRESS is STUN-PUB-2.
The TURN server will extract the content of the TURN message, which The STUN server will extract the content of the Send indication,
is a STUN Binding Request, and deliver it to the destination, TURN- which is a STUN Binding Request, and deliver it to the destination,
PUB-4. This request will be sent from the TURN address allocated to STUN-PUB-4. This request will be sent from the relayed address
R, which is TURN-PUB-4. As both interfaces are on the TURN server, allocated to R, which is STUN-PUB-4. As both interfaces are on the
this message is sent to itself (and thus the lack of a message number STUN server, this message is sent to itself (and thus the lack of a
in the sequence diagram above). Note that the USERNAME in the message number in the sequence diagram above). Note that the
Binding Request is L3:1:R2:1, which represents the transport address USERNAME in the Binding Request is L3:1:R2:1, which represents the
pair ID. This message gets discarded by the TURN server since, as of transport address pair ID. This message gets discarded by the STUN
yet, there are no permissions established for the TURN-PUB-2 server since, as of yet, there are no permissions established for the
allocation. However, it did have the side effect of establishing a STUN-PUB-2 allocation. However, it did have the side effect of
permission on the TURN-PUB-4 binding, allowing incoming packets from establishing a permission on the STUN-PUB-4 binding, allowing
TURN-PUB-2. incoming packets from STUN-PUB-2.
Once L gets the offer, it will attempt to validate the first Once L gets the offer, it will attempt to validate the first
transport address pair in the transport address pair check ordered transport address pair in the transport address pair check ordered
list, which will be the active candidate. The state machine for this list, which will be the active candidate. The state machine for this
transport address pair moves into the Testing state. Like agent R transport address pair moves into the Testing state. Like agent R
did, it will use the TURN SEND primitive to send a STUN Binding did, it will use the STUN Send Indication to send a STUN Binding
Request from its TURN derived transport address, TURN-PUB-2, to TURN- Request from its relayed transport address, STUN-PUB-2, to STUN-PUB-4
PUB-4 (message 28). This packet traverses the NAT (message 29) and (message 16). This packet traverses the NAT (message 17) and arrives
arrives at the TURN server. The TURN server will unwrap the contents at the STUN server. The STUN server will unwrap the contents of the
of the packet and send them from TURN-PUB-2 to TURN-PUB-4. It will packet and send them from STUN-PUB-2 to STUN-PUB-4. It will also, as
also, as a consequence, add a permission for TURN-PUB-4. The a consequence, add a permission for STUN-PUB-4. The contents of the
contents of the packet are a STUN Binding Request with USERNAME R2:1: packet are a STUN Binding Request with USERNAME R2:1:L3:1 (note how
L3:1 (note how this is the flip of the USERNAME in the Binding this is the flip of the USERNAME in the Binding Request sent by agent
Request sent by agent R). This is also a packet from the TURN server R). This is also a packet from the STUN server to itself. However,
to itself. However, now, the packet is not discarded, as a now, the packet is not discarded, as a permission had been installed
permission had been installed as a consequence of the "suicide as a consequence of the "suicide packet" from agent R (a suicide
packet" from agent R (a suicide packet is a packet that has no hope packet is a packet that has no hope of traversing a far end NAT, but
of traversing a far end NAT, but serves the purpose of enabling a serves the purpose of enabling a permission in a near end NAT so that
permission in a near end NAT so that a packet from the peer can be a packet from the peer can be returned). Thus, the STUN server will
returned). Thus, the TURN server will relay the received STUN relay the received STUN request towards agent R (message 18). This
request towards agent R (message 30). This is delivered as a TURN is delivered as a STUN Data Indication. Notice how the REMOTE-
DATA Indication. Notice how the REMOTE-ADDRESS is TURN-PUB-2; this ADDRESS is STUN-PUB-2; this is important as it will be used to
is important as it will be used to construct the STUN Binding construct the STUN Binding Response.
Response.
Agent R will receive the DATA Indication, and unwrap its contents to Agent R will receive the Data Indication, and unwrap its contents to
find the Binding Request. The state machine for this transport find the Binding Request. The state machine for this transport
address pair is currently in the Testing state. It therefore moves address pair is currently in the Testing state. It therefore moves
into the Send-Valid state, and it generates a Binding Response. into the Send-Valid state, and it generates a Binding Response.
However, the MAPPED-ADDRESS in the Binding Response is constructed However, the MAPPED-ADDRESS in the Binding Response is constructed
using the source IP address and port that were seen by the TURN using the source IP address and port that were seen by the STUN
server when the Binding Request arrived at TURN-PUB-4, which is the server when the Binding Request arrived at STUN-PUB-4, which is the
looped message between messages 29 and 30. This source address is looped message between messages 17 and 18. This source address is
TURN-PUB-2, which is the value of the REMOTE-ADDRESS attribute in STUN-PUB-2, which is the value of the REMOTE-ADDRESS attribute in
message 30. Thus, the STUN Binding Response will contain TURN-PUB-2 message 18. Thus, the STUN Binding Response will contain STUN-PUB-2
in the MAPPED-ADDRESS, and is to be sent to TURN-PUB-2. To send the in the MAPPED-ADDRESS, and is to be sent to STUN-PUB-2. To send the
response, agent R takes the STUN Binding Response and encapsulates it response, agent R takes the STUN Binding Response and encapsulates it
in a TURN SEND primitive, setting the DESTINATION-ADDRESS to TURN- in a STUN Send indication, setting the DESTINATION-ADDRESS to STUN-
PUB-2. This is shown in message 31. PUB-2. This is shown in message 19.
The TURN server will receive this SEND request, and unwrap its The STUN server will receive this Send Indication, and unwrap its
contents to find the STUN Binding Response. It sends it to the value contents to find the STUN Binding Response. It sends it to the value
of the DESTINATION-ADDRESS attribute, and sends it from the TURN of the DESTINATION-ADDRESS attribute, and sends it from the relayed
address allocated to R, which is TURN-PUB-4. This, once again, address allocated to R, which is STUN-PUB-4. This, once again,
results in a looped message to itself, and it arrives at TURN-PUB-2. results in a looped message to itself, and it arrives at STUN-PUB-2.
Now, however, there is a permission installed for STUN-PUB-4. The
Now, however, there is a permission installed for TURN-PUB-4. The STUN server will therefore forward the packet to agent L. To do so,
TURN server will therefore forward the packet to agent L. To do so, it constructs a STUN Data Indication containing the contents of the
it constructs a TURN DATA Indication containing the contents of the
packet. It sets the REMOTE-ADDRESS to the source transport address packet. It sets the REMOTE-ADDRESS to the source transport address
of the request it received (TURN-PUB-4), and forwards it to agent L of the request it received (STUN-PUB-4), and forwards it to agent L
(message 32). This traverses the NAT (message 33) and arrives at (message 20). This traverses the NAT (message 21) and arrives at
agent L. As a consequence of the receipt of a Binding Response, the agent L. As a consequence of the receipt of a Binding Response, the
state machine for this transport address pair moves to the Recv-Valid state machine for this transport address pair moves to the Recv-Valid
state. The agent also examines the MAPPED-ADDRESS of the STUN state. The agent also examines the MAPPED-ADDRESS of the STUN
response. It is TURN-PUB-2. This is the same as the native response. It is STUN-PUB-2. This is the same as the native
transport address of this transport address pair, and thus doesn't transport address of this transport address pair, and thus doesn't
represent a new transport address that might have been learned. represent a new transport address that might have been learned.
A short while later, agent R will attempt a retransmission of its Because of the receipt of message 18, the transport address pair
STUN Binding Request that was lost (the contents of message 27 that moved from Testing to Send-Valid, causing R to attempt a
were discarded by the TURN server due to lack of permission). This retransmission of its STUN Binding Request that was lost (the
time, however, a permission has been installed and the retransmission contents of message 15 that were discarded by the STUN server due to
will work. So, it sends the Binding Request again (message 34, lack of permission). This time, however, a permission has been
identical to message 27). This is looped by the TURN server to installed and the retransmission will work. So, it sends the Binding
itself again, but this time there is a permission in place when it Request again (message 22, identical to message 15). This is looped
arrives at TURN-PUB-2. As such, the request is forwarded towards by the STUN server to itself again, but this time there is a
agent L this time, in a TURN DATA Indication (message 35). This permission in place when it arrives at STUN-PUB-2. As such, the
traverses the NAT (message 36) and arrives at agent L. Agent L request is forwarded towards agent L this time, in a STUN Data
extracts the contents of the request, which are a STUN Binding Indication (message 23). This traverses the NAT (message 24) and
Request. This causes the state machine to move from Recv-Valid to arrives at agent L. Agent L extracts the contents of the request,
Valid. It generates a STUN Binding Response, and sets the MAPPED- which are a STUN Binding Request. This causes the state machine to
ADDRESS to the value of the REMOTE-ADDRESS in message 36 move from Recv-Valid to Valid. It generates a STUN Binding Response,
(TURN-PUB-4). This Binding Response is sent to TURN-PUB-4, which is and sets the MAPPED-ADDRESS to the value of the REMOTE-ADDRESS in
accomplished through a TURN SEND primitive (message 37). This SEND message 24 (STUN-PUB-4). This Binding Response is sent to
Request traverses the NAT (message 38) and is received by the TURN STUN-PUB-4, which is accomplished through a STUN Send Indication
server. Its contents are decapsulated, and sent to TURN-PUB-4, which (message 25). This Send Indication traverses the NAT (message 26)
is again a loop on the same host. This packet is then sent towards and is received by the STUN server. Its contents are decapsulated,
agent R in a DATA Indication (message 39). The contents of the DATA and sent to STUN-PUB-4, which is again a loop on the same host. This
Indication are extracted, and the agent sees a successful Binding packet is then sent towards agent R in a Data Indication (message
Response. It therefore moves the state machine from the Send-Valid 27). The contents of the DATA Indication are extracted, and the
state to the Valid state. At this point, the transport address pair agent sees a successful Binding Response. It therefore moves the
is in the Valid state for both agents. state machine from the Send-Valid state to the Valid state. At this
point, the transport address pair is in the Valid state for both
agents.
Approximately Ta seconds after agent R sent message 27, agent R will Approximately Ta seconds after agent R sent message 15, agent R will
start checks for the next transport address pair in its transport start checks for the next transport address pair in its transport
address pair check ordered list. This is the second component of the address pair check ordered list. This is the second component of the
same candidate pair, used for RTCP. This sequence, messages 40 same candidate pair, used for RTCP. This sequence, messages 28
through 52, are identical to the ones for RTP, but differ only in the through 40, are identical to the ones for RTP, but differ only in the
specific transport addresses. specific transport addresses.
Once that validation happens, the second transport address pair has Once that validation happens, the second transport address pair has
been validated. The candidate pair moves into the valid state, and been validated. The candidate pair moves into the valid state, and
both candidates are considered valid. The active candidate has now both candidates are considered valid. The active candidate has now
been validated, and media can begin to flow. It will do so through been validated, and media can begin to flow. It will do so through
the TURN server; indeed, it is relayed "twice" through the TURN the STUN server; indeed, it is relayed "twice" through the STUN
server. Even though there is a single TURN server, it is logically server. Even though there is a single STUN server, it is logically
acting as two separate TURN servers. Indeed, had L and R used two acting as two separate STUN servers. Indeed, had L and R used two
separate TURN servers, media would be relayed through both TURN separate STUN servers, media would be relayed through both STUN
servers. servers in a trapezoid configuration.
The actual media flows are shown as well. It is important to note The actual media flows are shown as well. It is important to note
that, since the ICE checks have not yet concluded on the candidate that, since the ICE checks have not yet concluded on the candidate
that will ultimately be used, no TURN Set Active Destinations have that will ultimately be used, no STUN Set Active Destinations have
been sent. As a consequence, media that is sent through the TURN been sent. As a consequence, media that is sent through the STUN
servers has to be sent using TURN Send requests. This introduces servers has to be sent using STUN Send indications. This introduces
some overhead, but is a transient condition. In message 53, agent L some overhead, but is a transient condition. In message 41, agent L
sends an RTP packet to agent R using a SEND request. It is sent to sends an RTP packet to agent R using a Send indication. It is sent
TURN-PUB-4. This traverses the NAT (message 54), and arrives at the to STUN-PUB-4. This traverses the NAT (message 42), and arrives at
TURN server. It is decapsulated, looped to itself, and arrives at the STUN server. It is decapsulated, looped to itself, and arrives
TURN-PUB-4. From there, it is encapsulated in a DATA Indication and at STUN-PUB-4. From there, it is encapsulated in a Data Indication
sent to agent R (message 55). In the reverse direction, agent R will and sent to agent R (message 43). In the reverse direction, agent R
send an RTP packet using a TURN SEND primitive (message 56), and send will send an RTP packet using a STUN Send indication (message 42),
it to TURN-PUB-2. This is received by the TURN server, decapsulated, and send it to STUN-PUB-2. This is received by the STUN server,
and sent to TURN-PUB-2 from TURN-PUB-4. This is again a loop within decapsulated, and sent to STUN-PUB-2 from STUN-PUB-4. This is again
the same host, arriving at TURN-PUB-4. The contents of the packet a loop within the same host, arriving at STUN-PUB-4. The contents of
are sent to agent L through a TURN DATA Indication (message 57), the packet are sent to agent L through a STUN Data Indication
which traverses the NAT (message 58) to arrive at agent R. Since this (message 45), which traverses the NAT (message 46) to arrive at agent
call flow is already long enough, RTCP packet transmission is not L. Since this call flow is already long enough, RTCP packet
shown. transmission is not shown.
Approximately Ta seconds after it sends message 41, agent L goes to Approximately Ta seconds after it sends message 29, agent L goes to
the next transport address pair in its transport address pair check the next transport address pair in its transport address pair check
ordered list that is in the Waiting state. This will be the RTP ordered list that is in the Waiting state. This will be the RTP
candidate for the top priority candidate pair, which is L-PRIV-1 on candidate for the top priority candidate pair, which is L-PRIV-1 on
agent L and R-PUB-1 on agent R. This is a local candidate for each agent L and R-PUB-1 on agent R. This is a local candidate for each
agent. To perform the check, agent R sends a STUN Binding Request agent. To perform the check, agent L sends a STUN Binding Request
from L-PRIV-1 to R-PUB-1 (message 59). Note the USERNAME of from L-PRIV-1 to R-PUB-1 (message 47). Note the USERNAME of
R1:1:L1:1, which identifies this transport address pair. This R1:1:L1:1, which identifies this transport address pair. This
traverses the NAT (message 60). Since the NAT is symmetric and this traverses the NAT (message 48). Since the NAT has the address and
is a new destination IP address, the NAT allocates a new transport port dependent mapping property, and this is a new destination IP
address on its public side, NAT-PUB-5, and places this in the source address, the NAT allocates a new transport address on its public
IP address and port. This packet arrives at agent R. Agent R finds a side, NAT-PUB-3, and places this in the source IP address and port.
matching transport address pair in the Waiting state. The state This packet arrives at agent R. Agent R finds a matching transport
machine transitions to the Send-Valid state. It sends the Binding address pair in the Waiting state. The state machine transitions to
response, with a MAPPED-ADDRESS equal to NAT-PUB-5 (message 61), the Send-Valid state. It sends the Binding response, with a MAPPED-
which traverses the NAT and arrives at agent L (message 62). Agent ADDRESS equal to NAT-PUB-3 (message 49), which traverses the NAT and
R, in addition to sending the response, will also send a Binding arrives at agent L (message 50). Agent R, in addition to sending the
Request. It is important to remember that this Binding Request is response, will also send a Binding Request. It is important to
sent to the remote address in the transport address pair (L-PRIV-1), remember that this Binding Request is sent to the remote address in
and NOT to the source IP address and port of the Binding Request the transport address pair (L-PRIV-1), and NOT to the source IP
(NAT-PUB-5); that will happen later. This attempt is shown in address and port of the Binding Request (NAT-PUB-3); that will happen
message 63. However, since the L-PRIV-1 is private, the packet is later. This attempt is shown in message 51. However, since the
discarded in the network. L-PRIV-1 is private, the packet is discarded in the network.
Now, as a consequence of receiving message 60, agent R will have Now, as a consequence of receiving message 48, agent R will have
constructed a peer-derived candidate. The candidate ID for this constructed a peer-derived candidate. The candidate ID for this
candidate is L1R1, and it initially contains a single transport candidate is L1R1, and it initially contains a single transport
address pair, NAT-PUB-5 and R-PUB-1. However, the candidate isn't address pair, NAT-PUB-3 and R-PUB-1. However, the candidate isn't
yet usable until the other component gets added. Similarly, agent L yet usable until the other component gets added. Similarly, agent L
will have constructed the same peer-derived candidate, with the same will have constructed the same peer-derived candidate, with the same
candidate ID and the same transport address pair. candidate ID and the same transport address pair.
Some Ta seconds after sending message 40, agent R will move to the Some Ta seconds after sending message 28, agent R will move to the
next transport address pair in the transport address pair check next transport address pair in the transport address pair check
ordered list whose state is Waiting. This is the RTCP component of ordered list whose state is Waiting. This is the RTCP component of
the highest priority candidate pair. It will attempt a connectivity the highest priority candidate pair. It will attempt a connectivity
check, from R-PUB-2 to L-PRIV-2 (message 64). Since L-PRIV-1 is check, from R-PUB-2 to L-PRIV-2 (message 52). Since L-PRIV-1 is
private, this message is discarded. private, this message is discarded.
Some Ta seconds after sending message 59, agent L will move to the Some Ta seconds after sending message 47, agent L will move to the
next transport address pair in the transport address pair check next transport address pair in the transport address pair check
ordered list whose state is Waiting. This is the RTCP component of ordered list whose state is Waiting. This is the RTCP component of
the highest priority candidate pair. It will attempt a connectivity the highest priority candidate pair. It will attempt a connectivity
check, from L-PRIV-2 to R-PUB-2 (message 65), which operates nearly check, from L-PRIV-2 to R-PUB-2 (message 53), which operates nearly
identically to messages 59-62, with the exception of the specific identically to messages 47-50, with the exception of the specific
addresses. Here, the NAT will create a new binding for the RTCP, addresses. Here, the NAT will create a new binding for the RTCP,
NAT-PUB-6, and this transport address is new for both participants. NAT-PUB-4, and this transport address is new for both participants.
On receipt of this Binding Request at agent R (message 66), agent R On receipt of this Binding Request at agent R (message 54), agent R
constructs the candidate ID for the peer-derived candidate, L1R1, and constructs the candidate ID for the peer-derived candidate, L1R1, and
finds it already exists. As such, this new transport address is finds it already exists. As such, this new transport address is
added, and the peer-derived candidate becomes complete and usable. added, and the peer-derived candidate becomes complete and usable.
Agent L does the same thing on receipt of message 68. This candidate Agent L does the same thing on receipt of message 56. This candidate
will have the same priority as its generating candidate L1 (1.0), and will have the same priority as its generating candidate L1 (1.0), and
is paired up with R1 (also at priority 1.0). Since L1R1 has the same is paired up with R1 (also at priority 1.0). Since L1R1 has the same
priority as L1 itself, the ordering algorithm in Section 7.5 will use priority as L1 itself, the ordering algorithm in Section 7.5 will use
the reverse lexicographic order of the candidate ID iself to the reverse lexicographic order of the candidate ID iself to
determine order. L1R1 is larger than L1, so that the peer-derived determine order. L1R1 is larger than L1, so that the peer-derived
candidate will come before its generating candidate. As a candidate will come before its generating candidate. As a
consequence, the peer-derived candidate pair will have a higher consequence, the peer-derived candidate pair will have a higher
priority than its generating candidate, and appear just before it in priority than its generating candidate, and appear just before it in
the candidate pair priority ordered list. the candidate pair priority ordered list.
As a consequence, after agent R sends message 67 and completes the As a consequence, after agent R sends message 55 and completes the
peer-derived candidate, it will move the two transport addresses in peer-derived candidate, it will move the two transport addresses in
the peer derived candidate into the Send-Valid state, and send a the peer derived candidate into the Send-Valid state, and send a
Binding Request for each in rapid succession (agent L will have moved Binding Request for each in rapid succession (agent L will have moved
both into the Recv-Valid state upon receipt of message 68). The both into the Recv-Valid state upon receipt of message 56). The
first of these connectivity checks are for the RTP component, from first of these connectivity checks are for the RTP component, from
R-PUB-1 to NAT-PUB-5 (message 69). Note the USERNAME in the STUN R-PUB-1 to NAT-PUB-3 (message 57). Note the USERNAME in the STUN
Binding Request, L1R1:1:R1:1, which identifies the peer-derived Binding Request, L1R1:1:R1:1, which identifies the peer-derived
transport address pair. This will succesfully traverse the NAT and transport address pair. This will succesfully traverse the NAT and
be delivered to agent L (message 70). The receipt of this request be delivered to agent L (message 58). The receipt of this request
moves the state machine for this transport address pair from Recv- moves the state machine for this transport address pair from Recv-
Valid to Valid, and a Binding Response is sent (message 71). This Valid to Valid, and a Binding Response is sent (message 59). This
passes through the NAT and arrives at agent R (message 72). This passes through the NAT and arrives at agent R (message 60). This
causes its state machine to enter the Valid state as well. The causes its state machine to enter the Valid state as well. The
MAPPED-ADDRESS, R-PUB-1, is not new to agent R and thus does not MAPPED-ADDRESS, R-PUB-1, is not new to agent R and thus does not
result in the creation of a new peer-derived candidate. result in the creation of a new peer-derived candidate.
Messages 73 through 76 show the same basic flow for RTCP. Upon Messages 61 through 64 show the same basic flow for RTCP. Upon
receipt of message 76, both transport address pairs are Valid at both receipt of message 64, both transport address pairs are Valid at both
agents, causing the peer derived candidate to become valid. Timer agents, causing the peer derived candidate to become valid. Timer
Tws is set at agent L, and fires without any higher priority Tws is set at agent L, and fires without any higher priority
candidate pairs becoming validated. As such, it now decides to send candidate pairs becoming validated. At agent R, media can now be
an updated offer to promote the peer-derived candidate to active. sent on this candidate pair from answerer (agent R) to offerer (agent
This offer (message 77) looks like: L). Agent L sends an updated offer to promote the peer-derived
candidate to active. This offer (message 65) looks like:
v=0 v=0
o=jdoe 2890844526 2890842808 IN IP4 $L-PRIV-1.IP o=jdoe 2890844526 2890842808 IN IP4 $L-PRIV-1.IP
s= s=
c=IN IP4 $NAT-PUB-5.IP c=IN IP4 $NAT-PUB-3.IP
t=0 0 t=0 0
m=audio $NAT-PUB-5.PORT RTP/AVP 0 a=ice-pwd:$LPASS
m=audio $NAT-PUB-3.PORT RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtcp:$NAT-PUB-6.PORT a=rtcp:$NAT-PUB-4.PORT
a=remote-candidate:R1 a=remote-candidate:R1
a=candidate $L1 1 $L-PASS1 UDP 1.0 $L-PRIV-1.IP $L-PRIV-1.PORT a=candidate $L1 1 UDP 1.0 $L-PRIV-1.IP $L-PRIV-1.PORT
a=candidate $L1 2 $L-PASS2 UDP 1.0 $L-PRIV-2.IP $L-PRIV-2.PORT a=candidate $L1 2 UDP 1.0 $L-PRIV-2.IP $L-PRIV-2.PORT
There are several important things to note in this offer. Firstly, There are several important things to note in this offer. Firstly,
note how the m/c-line now contains NAT-PUB-5 and NAT-PUB-6, the peer note how the m/c-line now contains NAT-PUB-3 and NAT-PUB-4, the peer
derived transport addresses it learned through the ICE processing. derived transport addresses it learned through the ICE processing.
Secondly, note how there remains a candidate encoded into the Secondly, note how there remains a candidate encoded into the
a=candidate attributes. This is candidate L1, NOT candidate L1R1. a=candidate attributes. This is candidate L1, NOT candidate L1R1.
Recall that the peer-derived candidates are never encoded into the Recall that the peer-derived candidates are never encoded into the
SDP. Rather, their generating candidate is encoded. This will cause SDP. Rather, their generating candidate is encoded. This will cause
keepalives to take place for the genreating candidate if valid keepalives to take place for the generating candidate if valid
(though its not) and any of its derived candidates, which is what we (though its not) and any of its derived candidates, which is what we
want. Finally, notice the inclusion of the a=remote-candidate want. Finally, notice the inclusion of the a=remote-candidate
attribute. Since agent L doesn't know whether agent R received attribute. Since agent L doesn't know whether agent R received
messages 72 or 76, it doesnt know whether the state of the candidate messages 60 or 64, it doesnt know whether the state of the candidate
is Recv-Valid or Valid at agent R. So, it has to tell agent R that, is Send-Valid or Valid at agent R. So, it has to tell agent R that,
in case its Recv-Valid, to please use it anyway. in case its Send-Valid, to please use it anyway.
The answer generated by agent R looks like: The answer generated by agent R looks like:
v=0 v=0
o=bob 2808844564 2808844565 IN IP4 $R-PUB-1.IP o=bob 2808844564 2808844565 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:$RPASS
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=rtcp:$R-PUB-2.PORT a=rtcp:$R-PUB-2.PORT
a=candidate $R1 1 $R-PASS1 UDP 1.0 $R-PUB-1.IP $R-PUB-1.PORT a=candidate $R1 1 UDP 1.0 $R-PUB-1.IP $R-PUB-1.PORT
a=candidate $R1 2 $R-PASS2 UDP 1.0 $R-PUB-2.IP $R-PUB-2.PORT a=candidate $R1 2 UDP 1.0 $R-PUB-2.IP $R-PUB-2.PORT
With this, media can now flow directly between endpoints. The With this, media can now flow directly between endpoints. The
removal of the TURN-based candidates from the offer/answer exchange removal of the relayed candidates from the offer/answer exchange will
will cause the TURN allocations to be removed. cause the STUN relay allocations to be removed.
12. Grammar 12. Grammar
This specification defines two new SDP attributes - the "candidate" This specification defines three new SDP attributes - the
and "remote-candidate" attributes. "candidate", "remote-candidate" and "ice-pwd" attributes.
The candidate attribute MUST be present within a media block of the The candidate attribute is a media-level attribute only. It contains
SDP. It contains a transport address for a candidate that can be a transport address for a candidate that can be used for connectivity
used for connectivity checks. There may be multiple candidate checks. There may be multiple candidate attributes in a media block.
attributes in a media block.
The syntax of this attribute is defined using Augmented BNF as The syntax of this attribute is defined using Augmented BNF as
defined in RFC 2234 [11]: defined in RFC 4234 [9]:
candidate-attribute = "candidate" ":" candidate-id SP component-id SP candidate-attribute = "candidate" ":" candidate-id SP component-id SP
password SP
transport SP transport SP
qvalue SP ;qvalue from RFC 3261 qvalue SP ;qvalue from RFC 3261
addr SP ;addr from RFC 3266 addr SP ;addr from RFC 3266
port ;port from RFC 2327 port ;port from RFC 2327
*(SP extension-att-name SP *(SP extension-att-name SP
extension-att-value) extension-att-value)
transport = "UDP" / transport-extension transport = "UDP" / transport-extension
transport-extension = token transport-extension = token
candidate-id = 1*base64-char candidate-id = 1*base64-char
password = 1*base64-char
base64-char = ALPHANUM / DIGIT / "+" / "/" base64-char = ALPHANUM / DIGIT / "+" / "/"
;ALPHANUM from RFC 3261
component-id = 1*DIGIT component-id = 1*DIGIT
extension-att-name = token extension-att-name = byte-string ;from RFC 2327
extension-att-value = token extension-att-value = byte-string
The candidate-id is used to group together the transport addresses The candidate-id is used to group together the transport addresses
for a particular candidate. It MUST be constructed with at least 128 for a particular candidate. It MUST be constructed with at least 24
bits of randomness. It MUST have the same value for all transport bits of randomness. It MUST have the same value for all transport
addresses within the same candidate. It MUST have a different value addresses within the same candidate. It MUST have a different value
for transport addresses within different candidates for the same for transport addresses within different candidates for the same
media stream. The password MUST also be constructed with at least media stream. The candidate-id uses a syntax that is defined to be
128 bits of randomness, and MUST differ for each transport address. equal to the base64 alphabet [3], which allows the candidate-id to be
Both of these use a syntax that is defined to be equal to the base64 generated by performing a base64 encoding of a randomly generated
alphabet [4], which allows the candidate-id and password to be value (note, however, that this does not mean that the candidate-id
generated by performing a base64 encoding of a randomly generated 128 or password is base64 decoded when use in STUN messages). In
bit value (note, however, that this does not mean that the addition, if content is base64 encoded to generate the candidate-id,
candidate-id or password is base64 decoded when use in STUN it MUST NOT be padded with '='. The component-id is a positive
messages). The component-id is a positive integer, which identifies integer, which identifies the specific component of the candidate.
the specific component of the candidate. It MUST start at 1 and MUST It MUST start at 1 and MUST increment by 1 for each component of a
increment by 1 for each component of a particular candidate. particular candidate.
The addr production is taken from [12], allowing for IPv4 addresses, The addr production is taken from [10], allowing for IPv4 addresses,
IPv6 addresses and FQDNs. The port production is taken from RFC 2327 IPv6 addresses and FQDNs. The port production is taken from RFC 2327
[7]. The token production is taken from RFC 3261 [3]. The transport [5]. The token production is taken from RFC 3261 [2]. The transport
production indicates the transport protocol for the candidate. This production indicates the transport protocol for the candidate. This
specification only defines UDP. However, extensibility is provided specification only defines UDP. However, extensibility is provided
to allow for future transport protocols to be used with ICE, such as to allow for future transport protocols to be used with ICE, such as
TCP or the Datagram Congestion Control Protocol (DCCP) [32]. TCP or the Datagram Congestion Control Protocol (DCCP) [34].
The a=candidate attribute can itself be extended. The grammar allows The a=candidate attribute can itself be extended. The grammar allows
for new name/value pairs to be added at the end of the attribute. An for new name/value pairs to be added at the end of the attribute. An
implementation MUST ignore any name/value pairs it doesn't implementation MUST ignore any name/value pairs it doesn't
understand. understand.
The syntax of the "remote-candidate" attribute is defined using The syntax of the "remote-candidate" attribute is defined using
Augmented BNF as defined in RFC 2234 [11]: Augmented BNF as defined in RFC 4234 [9]:
remote-candidate-att = "remote-candidate" ":" candidate-id remote-candidate-att = "remote-candidate" ":" candidate-id
This attribute MUST be present in an offer when the candidate in the This attribute MUST be present in an offer when the candidate in the
m/c-line is part of a candidate pair that is in the valid or m/c-line is part of a candidate pair that is in the valid or
partially valid state. partially valid state.
The syntax of the "ice-pwd" attribute is defined as:
ice-pwd-att = "ice-pwd" ":" password
password = 1*base64-char
The "ice-pwd" attribute MUST appear at the session-level, and is
consequently shared by all candidates for all media streams within
the session. It MUST have at least 128 bits of randomness. Like the
candidate-ID, its syntax is taken from the base64 alphabet, allowing
the password to be generted from a base64 encoding of a 128 bit
value. In addition, if content is base64 encoded to generate the
candidate-id, it MUST NOT be padded with '='.
13. Security Considerations 13. Security Considerations
There are several types of attacks possible in an ICE system. This There are several types of attacks possible in an ICE system. This
section considers these attacks and their countermeasures. section considers these attacks and their countermeasures.
13.1 Attacks on Connectivity Checks 13.1 Attacks on Connectivity Checks
An attacker might also attempt to disrupt the STUN-based connectivity An attacker might attempt to disrupt the STUN-based connectivity
checks. Ultimately, all of these attacks fool an agent into thinking checks. Ultimately, all of these attacks fool an agent into thinking
something incorrect about the results of the connectivity checks. something incorrect about the results of the connectivity checks.
The possible false conclusions an attacker can try and cause are: The possible false conclusions an attacker can try and cause are:
False Invalid An attacker can fool a pair of agents into thinking a False Invalid: An attacker can fool a pair of agents into thinking a
candidate pair is invalid, when it isn't. This can be used to candidate pair is invalid, when it isn't. This can be used to
cause an agent to prefer a different candidate (such as one cause an agent to prefer a different candidate (such as one
injected by the attacker), or to disrupt a call by forcing all injected by the attacker), or to disrupt a call by forcing all
candidates to fail. candidates to fail.
False Valid An attacker can fool a pair of agents into thinking a False Valid: An attacker can fool a pair of agents into thinking a
candidate pair is valid, when it isn't. This can cause an agent candidate pair is valid, when it isn't. This can cause an agent
to proceed with a session, but then not be able to receive any to proceed with a session, but then not be able to receive any
media. media.
False Peer-Derived Candidate An attacker can cause an agent to False Peer-Derived Candidate: An attacker can cause an agent to
discover a new peer-derived candidate, when it shouldn't have. discover a new peer-derived candidate, when it shouldn't have.
This can be used to redirect media streams to a DoS target or to This can be used to redirect media streams to a DoS target or to
the attacker, for eavesdropping or other purposes. the attacker, for eavesdropping or other purposes.
False Valid on False Candidate An attacker has already convinced an False Valid on False Candidate: An attacker has already convinced an
agent that there is a candidate with an address that doesn't agent that there is a candidate with an address that doesn't
actually route to that agent (for example, by injecting a false actually route to that agent (for example, by injecting a false
peer-derived candidate or false STUN-derived candidate). It must peer-derived candidate or false STUN-derived candidate). It must
then launch an attack that forces the agents to believe that this then launch an attack that forces the agents to believe that this
candidate is valid. candidate is valid.
Of the various techniques for creating faked STUN messages described Of the various techniques for creating faked STUN messages described
in RFC 3489, many are not applicable for the connectivity checks. in [13], many are not applicable for the connectivity checks.
Compromises of STUN servers are not much of a concern, since the STUN Compromises of STUN servers are not much of a concern, since the STUN
servers are embedded in endpoints and distributed throughout the servers are embedded in endpoints and distributed throughout the
network. Thus, compromising the STUN server is equivalent to network. Thus, compromising the STUN server is equivalent to
comprimising the endpoint, and if that happens, far more problematic comprimising the endpoint, and if that happens, far more problematic
attacks are possible than those against ICE. Similarly, DNS attacks attacks are possible than those against ICE. Similarly, DNS attacks
are irrelevant since STUN servers are not discovered via DNS, they are irrelevant since STUN servers are not discovered via DNS, they
are signaled via SIP. Injection of fake responses and relaying are signaled via SIP. Injection of fake responses and relaying
modified requests all can be handled in ICE with the countermeasures modified requests all can be handled in ICE with the countermeasures
discussed below. discussed below.
skipping to change at page 72, line 19 skipping to change at page 81, line 33
This attack is very hard to launch unless the attacker themself is This attack is very hard to launch unless the attacker themself is
identified by the fake transport address. This is because it identified by the fake transport address. This is because it
requires the attacker to intercept and replay packets sent by two requires the attacker to intercept and replay packets sent by two
different hosts. If both agents are on different networks (for different hosts. If both agents are on different networks (for
example, across the public Internet), this attack can be hard to example, across the public Internet), this attack can be hard to
coordinate, since it needs to occur against two different endpoints coordinate, since it needs to occur against two different endpoints
on different parts of the network at the same time. on different parts of the network at the same time.
If the attacker themself is identified by the fake transport address, If the attacker themself is identified by the fake transport address,
the attack is easier to coordinate. However, if SRTP is used [25], the attack is easier to coordinate. However, if SRTP is used [24],
the attacker will not be able to play the media packets, they will the attacker will not be able to play the media packets, they will
only be able to discard them, effectively disabling the media stream only be able to discard them, effectively disabling the media stream
for the call. However, this attack requires the agent to disrupt for the call. However, this attack requires the agent to disrupt
packets in order to block the connectivity check from reaching the packets in order to block the connectivity check from reaching the
target. In that case, if the goal is to disrupt the media stream, target. In that case, if the goal is to disrupt the media stream,
its much easier to just disrupt it with the same mechanism, rather its much easier to just disrupt it with the same mechanism, rather
than attack ICE. than attack ICE.
13.2 Attacks on Address Gathering 13.2 Attacks on Address Gathering
ICE endpoints make use of STUN for gathering addresses from a STUN ICE endpoints make use of STUN for gathering addresses from a STUN
server in the network. This is corresponds to the binding server in the network. This is corresponds to the binding
acquisition use case discussed in Section 10.1 of RFC 3489. As a acquisition use case discussed in Section 10.1 of [13]. As a
consequence, the attacks against STUN itself that are described in consequence, the attacks against STUN itself that are described in
Section 12 of RFC 3489 can still be used against the STUN address Section 12 [13] can still be used against the STUN address gathering
gathering operations that occur in ICE. operations that occur in ICE.
However, the additional mechanisms provided by ICE actually However, the additional mechanisms provided by ICE actually
counteract such attacks, making binding acquisition with STUN more counteract such attacks, making binding acquisition with STUN more
secure when combined with ICE than without ICE. secure when combined with ICE than without ICE.
Consider an attacker which is able to provide an agent with a faked Consider an attacker which is able to provide an agent with a faked
MAPPED-ADDRESS in a STUN Binding Request that is used for address MAPPED-ADDRESS in a STUN Binding Request that is used for address
gathering. This is the primary attack primitive described in Section gathering. This is the primary attack primitive described in Section
12 of RFC 3489. This address will be used as a STUN derived 12 of [13]. This address will be used as a STUN derived candidate in
candidate in the ICE exchange. For this candidate to actually be the ICE exchange. For this candidate to actually be used for media,
used for media, the attacker must also attack the connectivity the attacker must also attack the connectivity checks, and in
checks, and in particular, force a false valid on a false candidate. particular, force a false valid on a false candidate. This attack is
This attack is very hard to launch if the false address identifies a very hard to launch if the false address identifies a third party,
third party, and is prevented by SRTP if it identifies the attacker and is prevented by SRTP if it identifies the attacker themself.
themself.
If the attacker elects not to attack the connectivity checks, the If the attacker elects not to attack the connectivity checks, the
worst it can do is prevent the STUN-derived address from being used. worst it can do is prevent the STUN-derived address from being used.
However, if the peer agent has at least one address that is reachable However, if the peer agent has at least one address that is reachable
by the agent under attack, the STUN connectivity checks themselves by the agent under attack, the STUN connectivity checks themselves
will provide a STUN-derived address that can be used for the exchange will provide a STUN-derived address that can be used for the exchange
of media. Peer derived candidates are preferred over the candidate of media. Peer derived candidates are preferred over the candidate
they are generated from for this reason. As such, an attack solely they are generated from for this reason. As such, an attack solely
on the STUN address gathering will normally have no impact on a call on the STUN address gathering will normally have no impact on a call
at all. at all.
13.3 Attacks on the Offer/Answer Exchanges 13.3 Attacks on the Offer/Answer Exchanges
An attacker that can modify or disrupt the offer/answer exchanges An attacker that can modify or disrupt the offer/answer exchanges
themselves can readily launch a variety of attacks with ICE. They themselves can readily launch a variety of attacks with ICE. They
could direct media to a target of a DoS attack, they could insert could direct media to a target of a DoS attack, they could insert
themselves into the media stream, and so on. These are similar to themselves into the media stream, and so on. These are similar to
the general security considerations for offer/answer exchanges, and the general security considerations for offer/answer exchanges, and
the security considerations in RFC 3264 [5] apply. These require the security considerations in RFC 3264 [4] apply. These require
techniques for message integrity and encryption for offers and techniques for message integrity and encryption for offers and
answers, which are satisfied by the SIPS mechanism when SIP is used. answers, which are satisfied by the SIPS mechanism [2] when SIP is
As such, the usage of SIPS with ICE is RECOMMENDED. used. As such, the usage of SIPS with ICE is RECOMMENDED.
13.4 Insider Attacks 13.4 Insider Attacks
In addition to attacks where the attacker is a third party trying to In addition to attacks where the attacker is a third party trying to
insert fake offers, answers or stun messages, there are several insert fake offers, answers or stun messages, there are several
attacks possible with ICE when the attacker is an authenticated and attacks possible with ICE when the attacker is an authenticated and
valid participant in the ICE exchange. valid participant in the ICE exchange.
13.4.1 The Voice Hammer Attack 13.4.1 The Voice Hammer Attack
The voice hammer attack is an amplification attack, of the variety The voice hammer attack is an amplification attack, of the variety
discussed in Section 3 of [30]. In this attack, the attacker discussed in Section 3 of [32]. In this attack, the attacker
initiates sessions to other agents, and includes the IP address and initiates sessions to other agents, and includes the IP address and
port of a DoS target in the m/c-line of their SDP. This causes port of a DoS target in the m/c-line of their SDP. This causes
substantial amplification; a single offer/answer exchange can create substantial amplification; a single offer/answer exchange can create
a continuing flood of media packets, possibly at high rates (consider a continuing flood of media packets, possibly at high rates (consider
video sources). This attack is not speific to ICE, but ICE can help video sources). This attack is not speific to ICE, but ICE can help
provide remediation. provide remediation.
Specifically, if ICE is used, the agent receiving the malicious SDP Specifically, if ICE is used, the agent receiving the malicious SDP
will first peform connectivity checks to the target of media before will first peform connectivity checks to the target of media before
sending it there. If this target is a third party host, the checks sending it there. If this target is a third party host, the checks
skipping to change at page 74, line 29 skipping to change at page 83, line 42
It is impossible to eliminate the amplification, but the volume can It is impossible to eliminate the amplification, but the volume can
be reduced through a variety of heuristics. For example, agents can be reduced through a variety of heuristics. For example, agents can
limit the number of candidates they'll accept in an offer or answer, limit the number of candidates they'll accept in an offer or answer,
they can increase the value of Ta, or exponentially increase Ta as they can increase the value of Ta, or exponentially increase Ta as
time goes on. All of these ultimately trade off the time for the ICE time goes on. All of these ultimately trade off the time for the ICE
exchanges to complete, with the amount of traffic that gets sent. exchanges to complete, with the amount of traffic that gets sent.
14. IANA Considerations 14. IANA Considerations
This specification defines two new SDP attribute per the procedures This specification defines three new SDP attribute per the procedures
of Appendix B of RFC 2327. The required information for the of Appendix B of RFC 2327. The required information for the
registrations are included here. registrations are included here.
14.1 candidate Attribute 14.1 candidate Attribute
Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net. Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net.
Attribute Name: candidate Attribute Name: candidate
Long Form: candidate Long Form: candidate
skipping to change at page 75, line 29 skipping to change at page 84, line 44
attribute. attribute.
Purpose: This attribute is used with Interactive Connectivity Purpose: This attribute is used with Interactive Connectivity
Establishment (ICE), and provides the identity of the remote Establishment (ICE), and provides the identity of the remote
candidate that the offerer wishes the answerer to use in its candidate that the offerer wishes the answerer to use in its
answer. answer.
Appropriate Values: See Section 12 of RFC XXXX [Note to RFC-ed: Appropriate Values: See Section 12 of RFC XXXX [Note to RFC-ed:
please replace XXXX with the RFC number of this specification]. please replace XXXX with the RFC number of this specification].
14.3 ice-pwd Attribute
Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net.
Attribute Name: ice-pwd
Long Form: ice-pwd
Type of Attribute: session level
Charset Considerations: The attribute is not subject to the charset
attribute.
Purpose: This attribute is used with Interactive Connectivity
Establishment (ICE), and provides the password used to protect
STUN connectivity checks.
Appropriate Values: See Section 12 of RFC XXXX [Note to RFC-ed:
please replace XXXX with the RFC number of this specification].
15. IAB Considerations 15. IAB Considerations
The IAB has studied the problem of "Unilateral Self Address Fixing", The IAB has studied the problem of "Unilateral Self Address Fixing",
which is the general process by which a agent attempts to determine which is the general process by which a agent attempts to determine
its address in another realm on the other side of a NAT through a its address in another realm on the other side of a NAT through a
collaborative protocol reflection mechanism [23]. ICE is an example collaborative protocol reflection mechanism [22]. ICE is an example
of a protocol that performs this type of function. Interestingly, of a protocol that performs this type of function. Interestingly,
the process for ICE is not unilateral, but bilateral, and the the process for ICE is not unilateral, but bilateral, and the
difference has a signficant impact on the issues raised by IAB. The difference has a signficant impact on the issues raised by IAB. The
IAB has mandated that any protocols developed for this purpose IAB has mandated that any protocols developed for this purpose
document a specific set of considerations. This section meets those document a specific set of considerations. This section meets those
requirements. requirements.
15.1 Problem Definition 15.1 Problem Definition
From RFC 3424 any UNSAF proposal must provide: From RFC 3424 any UNSAF proposal must provide:
skipping to change at page 77, line 6 skipping to change at page 86, line 44
15.3 Brittleness Introduced by ICE 15.3 Brittleness Introduced by ICE
From RFC3424, any UNSAF proposal must provide: From RFC3424, any UNSAF proposal must provide:
Discussion of specific issues that may render systems more Discussion of specific issues that may render systems more
"brittle". For example, approaches that involve using data at "brittle". For example, approaches that involve using data at
multiple network layers create more dependencies, increase multiple network layers create more dependencies, increase
debugging challenges, and make it harder to transition. debugging challenges, and make it harder to transition.
ICE actually removes brittleness from existing UNSAF mechanisms. In ICE actually removes brittleness from existing UNSAF mechanisms. In
particular, traditional STUN (the usage described in RFC 3489) has particular, traditional STUN (the usage described in [13]) has
several points of brittleness. One of them is the discovery process several points of brittleness. One of them is the discovery process
which requires a agent to try and classify the type of NAT it is which requires a agent to try and classify the type of NAT it is
behind. This process is error-prone. With ICE, that discovery behind. This process is error-prone. With ICE, that discovery
process is simply not used. Rather than unilaterally assessing the process is simply not used. Rather than unilaterally assessing the
validity of the address, its validity is dynamically determined by validity of the address, its validity is dynamically determined by
measuring connectivity to a peer. The process of determining measuring connectivity to a peer. The process of determining
connectivity is very robust. The only potential problem is that connectivity is very robust. The only potential problem is that
bilaterally fixed addresses through STUN can expire if traffic does bilaterally fixed addresses through STUN can expire if traffic does
not keep them alive. However, that is substantially less brittleness not keep them alive. However, that is substantially less brittleness
than the STUN discovery mechanisms. than the STUN discovery mechanisms.
Another point of brittleness in STUN, TURN, and any other unilateral Another point of brittleness in STUN and any other unilateral
mechanism is its absolute reliance on an additional server. ICE mechanism is its absolute reliance on an additional server. ICE
makes use of a server for allocating unilateral addresses, but allows makes use of a server for allocating unilateral addresses, but allows
agents to directly connect if possible. Therefore, in some cases, agents to directly connect if possible. Therefore, in some cases,
the failure of a STUN or TURN server would still allow for a call to the failure of a STUN server would still allow for a call to progress
progress when ICE is used. when ICE is used.
Another point of brittleness in traditional STUN is that it assumes Another point of brittleness in traditional STUN is that it assumes
that the STUN server is on the public Internet. Interestingly, with that the STUN server is on the public Internet. Interestingly, with
ICE, that is not necessary. There can be a multitude of STUN servers ICE, that is not necessary. There can be a multitude of STUN servers
in a variety of address realms. ICE will discover the one that has in a variety of address realms. ICE will discover the one that has
provided a usable address. provided a usable address.
The most troubling point of brittleness in traditional STUN is that The most troubling point of brittleness in traditional STUN is that
it doesn't work in all network topologies. In cases where there is a it doesn't work in all network topologies. In cases where there is a
shared NAT between each agent and the STUN server, traditional STUN shared NAT between each agent and the STUN server, traditional STUN
skipping to change at page 78, line 20 skipping to change at page 88, line 8
existing, deployed NA[P]Ts and experience reports. existing, deployed NA[P]Ts and experience reports.
A number of NAT boxes are now being deployed into the market which A number of NAT boxes are now being deployed into the market which
try and provide "generic" ALG functionality. These generic ALGs hunt try and provide "generic" ALG functionality. These generic ALGs hunt
for IP addresses, either in text or binary form within a packet, and for IP addresses, either in text or binary form within a packet, and
rewrite them if they match a binding. This will interfere with rewrite them if they match a binding. This will interfere with
proper operation of any UNSAF mechanism, including ICE. proper operation of any UNSAF mechanism, including ICE.
16. Acknowledgements 16. Acknowledgements
The authors would like to thank Flemming Andreasen, Dan Wing, Douglas The authors would like to thank Flemming Andreasen, Rohan Mahy, Dean
Otis, Francois Audet and Magnus Westerlund for their comments and Willis, Dan Wing, Douglas Otis, and Francois Audet for their comments
input. and input. A special thanks goes to Magnus Westerlund for doing
several detailed reviews on the various revisions of this
specification. His input led to many substantive improvements in
this document.
17. References 17. References
17.1 Normative References 17.1 Normative References
[1] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN [1] Huitema, C., "Real Time Control Protocol (RTCP) attribute in
- Simple Traversal of User Datagram Protocol (UDP) Through
Network Address Translators (NATs)", RFC 3489, March 2003.
[2] Huitema, C., "Real Time Control Protocol (RTCP) attribute in
Session Description Protocol (SDP)", RFC 3605, October 2003. Session Description Protocol (SDP)", RFC 3605, October 2003.
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[4] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", [3] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
RFC 3548, July 2003. RFC 3548, July 2003.
[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
[6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [5] Handley, M. and V. Jacobson, "SDP: Session Description
January 2004.
[7] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[8] Casner, S., "Session Description Protocol (SDP) Bandwidth [6] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556,
July 2003. July 2003.
[9] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of [7] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of
Resource Management and Session Initiation Protocol (SIP)", Resource Management and Session Initiation Protocol (SIP)",
RFC 3312, October 2002. RFC 3312, October 2002.
[10] Camarillo, G. and P. Kyzivat, "Update to the Session Initiation [8] Camarillo, G. and P. Kyzivat, "Update to the Session Initiation
Protocol (SIP) Preconditions Framework", RFC 4032, March 2005. Protocol (SIP) Preconditions Framework", RFC 4032, March 2005.
[11] Crocker, D. and P. Overell, "Augmented BNF for Syntax [9] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 4234, October 2005.
[12] Olson, S., Camarillo, G., and A. Roach, "Support for IPv6 in [10] Olson, S., Camarillo, G., and A. Roach, "Support for IPv6 in
Session Description Protocol (SDP)", RFC 3266, June 2002. Session Description Protocol (SDP)", RFC 3266, June 2002.
[13] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional [11] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC 3262, Responses in Session Initiation Protocol (SIP)", RFC 3262,
June 2002. June 2002.
[14] Andreasen, F., "Connectivity Preconditions for Session [12] Yon, D., "Connection-Oriented Media Transport in the Session
Description Protocol Media Streams",
draft-ietf-mmusic-connectivity-precon-00 (work in progress),
May 2005.
[15] Yon, D., "Connection-Oriented Media Transport in the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-comedia-10 Description Protocol (SDP)", draft-ietf-mmusic-sdp-comedia-10
(work in progress), November 2004. (work in progress), November 2004.
[16] Rosenberg, J., "Traversal Using Relay NAT (TURN)", [13] Rosenberg, J., "Simple Traversal of UDP Through Network Address
draft-rosenberg-midcom-turn-08 (work in progress), Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-02
September 2005. (work in progress), July 2005.
[14] Rosenberg, J., Mahy, R., and C. Huitema, "Obtaining Relay
Addresses from Simple Traversal of UDP Through NAT (STUN)",
Internet Draft draft-ietf-behave-turn-00.txt, February 2006.
17.2 Informative References 17.2 Informative References
[17] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming [15] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998. Protocol (RTSP)", RFC 2326, April 1998.
[18] Senie, D., "Network Address Translator (NAT)-Friendly [16] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN
- Simple Traversal of User Datagram Protocol (UDP) Through
Network Address Translators (NATs)", RFC 3489, March 2003.
[17] Senie, D., "Network Address Translator (NAT)-Friendly
Application Design Guidelines", RFC 3235, January 2002. Application Design Guidelines", RFC 3235, January 2002.
[19] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for [18] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
Generic Forward Error Correction", RFC 2733, December 1999. Generic Forward Error Correction", RFC 2733, December 1999.
[20] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. [19] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A.
Rayhan, "Middlebox communication architecture and framework", Rayhan, "Middlebox communication architecture and framework",
RFC 3303, August 2002. RFC 3303, August 2002.
[21] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, "Realm [20] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, "Realm
Specific IP: Framework", RFC 3102, October 2001. Specific IP: Framework", RFC 3102, October 2001.
[22] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, "Realm [21] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, "Realm
Specific IP: Protocol Specification", RFC 3103, October 2001. Specific IP: Protocol Specification", RFC 3103, October 2001.
[23] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- [22] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-
Address Fixing (UNSAF) Across Network Address Translation", Address Fixing (UNSAF) Across Network Address Translation",
RFC 3424, November 2002. RFC 3424, November 2002.
[24] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [23] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", "RTP: A Transport Protocol for Real-Time Applications",
RFC 3550, July 2003. RFC 3550, July 2003.
[25] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [24] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[26] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via [25] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
IPv4 Clouds", RFC 3056, February 2001. IPv4 Clouds", RFC 3056, February 2001.
[27] Zopf, R., "Real-time Transport Protocol (RTP) Payload for [26] Zopf, R., "Real-time Transport Protocol (RTP) Payload for
Comfort Noise (CN)", RFC 3389, September 2002. Comfort Noise (CN)", RFC 3389, September 2002.
[28] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE [27] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002. Method", RFC 3311, October 2002.
[29] Andreasen, F., "A No-Op Payload Format for RTP", [28] Bonica, R., Kompella, K., and D. Meyer, "Tracing Requirements
for Generic Tunnels", RFC 3609, September 2003.
[29] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone
Generation in the Session Initiation Protocol (SIP)", RFC 3960,
December 2004.
[30] Andreasen, F., "Connectivity Preconditions for Session
Description Protocol Media Streams",
draf