draft-ietf-mmusic-ice-02.txt   draft-ietf-mmusic-ice-03.txt 
MMUSIC J. Rosenberg MMUSIC J. Rosenberg
Internet-Draft dynamicsoft Internet-Draft Cisco Systems
Expires: January 17, 2005 July 19, 2004 Expires: April 25, 2005 October 25, 2004
Interactive Connectivity Establishment (ICE): A Methodology for Interactive Connectivity Establishment (ICE): A Methodology for
Network Address Translator (NAT) Traversal for Multimedia Session Network Address Translator (NAT) Traversal for Multimedia Session
Establishment Protocols Establishment Protocols
draft-ietf-mmusic-ice-02 draft-ietf-mmusic-ice-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
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 35 skipping to change at page 1, line 35
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 January 17, 2005. This Internet-Draft will expire on April 25, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document describes a methodology for Network Address Translator This document describes a methodology for Network Address Translator
(NAT) traversal for multimedia session signaling protocols, such as (NAT) traversal for multimedia session signaling protocols, such as
the Session Initiation Protocol (SIP). This methodology is called the Session Initiation Protocol (SIP). This methodology is called
Interactive Connectivity Establishment (ICE). ICE makes use of Interactive Connectivity Establishment (ICE). ICE makes use of
existing protocols, such as Simple Traversal of UDP Through NAT existing protocols, such as Simple Traversal of UDP Through NAT
(STUN) and Traversal Using Relay NAT (TURN). ICE makes use of STUN (STUN) and Traversal Using Relay NAT (TURN). ICE makes use of STUN
in peer-to-peer cooperative fashion, allowing participants to in peer-to-peer cooperative fashion, allowing participants to
discover, create and verify mutual connectivity. discover, create and verify mutual connectivity.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Multimedia Signaling Protocol Abstraction . . . . . . . . . . 4 2. Multimedia Signaling Protocol Abstraction . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . . 8 4. Overview of ICE . . . . . . . . . . . . . . . . . . . . . . . 7
5. Detailed ICE Algorithm . . . . . . . . . . . . . . . . . . . . 10 5. Detailed ICE Algorithm . . . . . . . . . . . . . . . . . . . . 9
5.1 Initiator Processing . . . . . . . . . . . . . . . . . . . 10 5.1 Initiator Processing . . . . . . . . . . . . . . . . . . . 10
5.1.1 Sending the Initiate Message . . . . . . . . . . . . . 10 5.1.1 Sending the Initiate Message . . . . . . . . . . . . . 10
5.1.2 Processing the Accept . . . . . . . . . . . . . . . . 10 5.1.2 Processing the Accept . . . . . . . . . . . . . . . . 11
5.2 Responder Processing . . . . . . . . . . . . . . . . . . . 11 5.2 Responder Processing . . . . . . . . . . . . . . . . . . . 11
5.2.1 Processing the Initiate Message . . . . . . . . . . . 11 5.2.1 Processing the Initiate Message . . . . . . . . . . . 11
5.3 Common Procedures . . . . . . . . . . . . . . . . . . . . 12 5.3 Common Procedures . . . . . . . . . . . . . . . . . . . . 12
5.3.1 Gathering Transport Addresses . . . . . . . . . . . . 12 5.3.1 Gathering Transport Addresses . . . . . . . . . . . . 12
5.3.2 Enabling STUN on Each Local Transport Address . . . . 13 5.3.2 Enabling STUN on Each Local Transport Address . . . . 14
5.3.3 Prioritizing the Transport Addresses and Choosing 5.3.3 Prioritizing the Transport Addresses and Choosing
a Default . . . . . . . . . . . . . . . . . . . . . . 14 a Default . . . . . . . . . . . . . . . . . . . . . . 16
5.3.4 Sending STUN Connectivity Checks . . . . . . . . . . . 16 5.3.4 Sending STUN Connectivity Checks . . . . . . . . . . . 18
5.3.5 Receiving STUN Requests . . . . . . . . . . . . . . . 21 5.3.5 Receiving STUN Requests . . . . . . . . . . . . . . . 23
6. Running STUN on Derived Transport Addresses . . . . . . . . . 23 5.3.6 Management of Resources . . . . . . . . . . . . . . . 24
6.1 STUN on a TURN Derived Transport Address . . . . . . . . . 23 5.3.7 Binding Keepalives . . . . . . . . . . . . . . . . . . 24
6.2 STUN on a STUN Derived Transport Address . . . . . . . . . 24 6. Running STUN on Derived Transport Addresses . . . . . . . . . 25
7. XML Schema for ICE Messages . . . . . . . . . . . . . . . . . 26 6.1 STUN on a TURN Derived Transport Address . . . . . . . . . 26
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.2 STUN on a STUN Derived Transport Address . . . . . . . . . 28
8.1 Port Restricted . . . . . . . . . . . . . . . . . . . . . 29 7. XML Schema for ICE Messages . . . . . . . . . . . . . . . . . 29
9. Mapping ICE into SIP . . . . . . . . . . . . . . . . . . . . . 32 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
10. Security Considerations . . . . . . . . . . . . . . . . . . 34 9. Mapping ICE into SIP . . . . . . . . . . . . . . . . . . . . . 34
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 35 9.1 Message Mapping . . . . . . . . . . . . . . . . . . . . . 34
12. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 36 9.2 SIP and SDP Specific Security Considerations . . . . . . . 36
12.1 Problem Definition . . . . . . . . . . . . . . . . . . . . 36 9.3 Updates in the Offer/Answer Model . . . . . . . . . . . . 36
12.2 Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 36 10. Security Considerations . . . . . . . . . . . . . . . . . . 36
12.3 Brittleness Introduced by ICE . . . . . . . . . . . . . . 37 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 37
12.4 Requirements for a Long Term Solution . . . . . . . . . . 38 11.1 SDP Attribute Name . . . . . . . . . . . . . . . . . . . . 37
12.5 Issues with Existing NAPT Boxes . . . . . . . . . . . . . 38 11.2 URN Sub-Namespace Registration . . . . . . . . . . . . . . 38
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 11.3 XML Schema Registration . . . . . . . . . . . . . . . . . 39
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 12. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 39
14.1 Normative References . . . . . . . . . . . . . . . . . . . . 40 12.1 Problem Definition . . . . . . . . . . . . . . . . . . . . 40
14.2 Informative References . . . . . . . . . . . . . . . . . . . 40 12.2 Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 40
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 41 12.3 Brittleness Introduced by ICE . . . . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . . . 42 12.4 Requirements for a Long Term Solution . . . . . . . . . . 41
12.5 Issues with Existing NAPT Boxes . . . . . . . . . . . . . 42
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
14.1 Normative References . . . . . . . . . . . . . . . . . . . . 42
14.2 Informative References . . . . . . . . . . . . . . . . . . . 43
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 44
Intellectual Property and Copyright Statements . . . . . . . . 45
1. Introduction 1. Introduction
A multimedia session signaling protocol is a protocol that exchanges A multimedia session signaling protocol is a protocol that exchanges
control messages between a pair of agents for the purposes of control messages between a pair of agents for the purposes of
establishing the flow of media traffic between them. This media flow establishing the flow of media traffic between them. This media flow
is distinct from the flow of control messages, and may take a is distinct from the flow of control messages, and may take a
different path through the network. Examples of such protocols are different path through the network. Examples of such protocols are
the Session Initiation Protocol (SIP) [3], the Real Time Streaming the Session Initiation Protocol (SIP) [3], the Real Time Streaming
Protocol (RTSP) [5] and the International Telecommunications Union Protocol (RTSP) [9] and the International Telecommunications Union
(ITU) H.323. (ITU) H.323.
These protocols, by nature of their design, are difficult to operate These protocols, by nature of their design, are difficult to operate
through Network Address Translators (NAT). Because their purpose in through Network Address Translators (NAT). Because their purpose in
life is to establish a flow of packets, they tend to carry IP life is to establish a flow of packets, they tend to carry IP
addresses within their messages, which is known to be problematic addresses within their messages, which is known to be problematic
through NAT [6]. The protocols also seek to create a media flow through NAT [10]. The protocols also seek to create a media flow
directly between participants, so that there is no application layer directly between participants, so that there is no application layer
intermediary between them. This is done to reduce media latency, intermediary between them. This is done to reduce media latency,
decrease packet loss, and reduce the operational costs of deploying decrease packet loss, and reduce the operational costs of deploying
the application. However, this is difficult to accomplish through the application. However, this is difficult to accomplish through
NAT. A full treatment of the reasons for this is beyond the scope of NAT. A full treatment of the reasons for this is beyond the scope of
this specification. this 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 [7], Simple Traversal of UDP (ALGs), the Middlebox Control Protocol [11], Simple Traversal of UDP
through NAT (STUN) [1], Traversal Using Relay NAT [16], Realm through NAT (STUN) [1], Traversal Using Relay NAT [8], and Realm
Specific IP [8][9], symmetric RTP [10], along with session Specific IP [12][13] along with session description extensions needed
description extensions needed to make them work, such as [2]. to make them work, such as the SDP attribute for RTCP [2].
Unfortunately, these techniques all have pros and cons which make Unfortunately, these techniques all have pros and cons which make
each one optimal in some network topologies, but a poor choice in each one optimal in some network topologies, but a poor choice in
others. The result is that administrators and implementors are others. The result is that administrators and implementors are
making assumptions about the topologies of the networks in which making assumptions about the topologies of the networks in which
their solutions will be deployed. This introduces a lot of their solutions will be deployed. This introduces a lot of
complexity and brittleness into the system. What is needed is a complexity and brittleness into the system. What is needed is a
single solution which is flexible enough to work well in all single solution which is flexible enough to work well in all
situations. situations.
This specification provides that solution. It is called Interactive This specification provides that solution. It is called Interactive
skipping to change at page 5, line 10 skipping to change at page 5, line 10
relay, before finally arriving at the session responder. Assuming relay, before finally arriving at the session responder. Assuming
the session responder wishes to communicate, it generates an accept the session responder wishes to communicate, it generates an accept
message, which is relayed back to the initiator. This message message, which is relayed back to the initiator. This message
contains capabilities and configuration of media streams for the contains capabilities and configuration of media streams for the
responder. As a result, media streams are established between the responder. As a result, media streams are established between the
initiator and responder. The signaling protocol may also support an initiator and responder. The signaling protocol may also support an
operation that allows for termination of the communications session. operation that allows for termination of the communications session.
We refer to this signaling message as a terminate message. We refer to this signaling message as a terminate message.
This abstraction is readily mapped to SIP, RTSP, and H.323, amongst This abstraction is readily mapped to SIP, RTSP, and H.323, amongst
others. For SIP, the initiator is the User Agent Client (UAC), the others. For SIP, the initiator is the the user agent that generates
responder is the User Agent Server (UAS), the initiate message is a an SDP offer [4], the responder is a SIP user agent that generates an
SIP message containing an SDP offer (for example, an INVITE), the SDP answer to the offer, the initiate message is a SIP message
accept message is a SIP message containing an SDP answer (for containing an SDP offer (for example, an INVITE), the accept message
example, a 200 OK), and the terminate message is a BYE. For RTSP, is a SIP message containing an SDP answer (for example, a 200 OK),
the initiator is the RTSP client, the responder is the RTSP server, and the terminate message is a BYE. For RTSP, the initiator is the
the initiate message is a SETUP message, and the accept message is a RTSP client, the responder is the RTSP server, the initiate message
SETUP response. is a SETUP message, and the accept message is a SETUP response.
This specification defines parameters that need to be included in The initiate and accept messages need to contain parameters, defined
these various signaling messages in order to implement the by this specification, for the protocol to operate. The initiate and
functionality described by ICE. Those parameters are represented in accept mesages are therefore defined by this specification as XML
XML for convenience. Any multimedia signaling protocol that uses ICE documents containing the relevant information. Of course, multimedia
will need to define how to map those parameters into its own protocol signaling protocols will not use these XML documents directly.
messages. Section 9 provides such a mapping for SIP. Rather, those protocols will need to define extensions as needed to
show how the initiate, accept and terminate messages map to messages
in the actual protocol, and how every element and attribute in the
XML document for those messages maps into parameters of the actual
protocol. Section 9 provides such a mapping for SIP.
3. Terminology 3. Terminology
Several new terms are introduced in this specification: Several new terms are introduced in this specification:
Session Initiator: A software or hardware entity that, at the request Session Initiator: A software or hardware entity that, at the request
of a user, tries to establish communications with another entity, of a user, tries to establish communications with another entity,
called the session responder. A session initiator is also called called the session responder. A session initiator is also called
an initiator. an initiator.
Initiator: Another term for a session initiator. Initiator: Another term for a session initiator.
Session Responder: A software or hardware entity that receives a Session Responder: A software or hardware entity that receives a
request for establishment of communications from the session request for establishment of communications from the session
initiator, and either accepts or declines the request. A session initiator, and either accepts or declines the request. A session
responder is also called a responder. responder is also called a responder.
Responder: Another term for a session responder. Responder: Another term for a session responder.
Client: Either the initiator or responder. Client: Either the initiator or responder.
Peer: From the perspective of one of the clients in a session, its Peer: From the perspective of one of the clients in a session, its
peer is the other client. Specifically, from the perspective of peer is the other client. Specifically, from the perspective of
the initiator, the peer is the responder. From the perspective of the initiator, the peer is the responder. From the perspective of
the responder, the peer is the initiator. the responder, the peer is the initiator.
Signaling Relay: An intermediary of signaling messages. Examples are Signaling Relay: An intermediary of signaling messages. Examples are
SIP proxies and H.323 Gatekeepers. SIP proxies and H.323 Gatekeepers.
Initiate Message: The signaling message used by an initiator to Initiate Message: The signaling message used by an initiator to
establish communications. It contains capabilities and other establish communications. It contains capabilities and other
information needed by the responder to send media to the information needed by the responder to send media to the
initiator. initiator. For SIP, this is any SIP message that contains an
offer. Usually, this is the initial INVITE.
Accept Message: The signaling message used by a responder to agree to Accept Message: The signaling message used by a responder to agree to
communications. It contains capabilities and other information communications. It contains capabilities and other information
needed by the initiator to send media to the responder. needed by the initiator to send media to the responder. For SIP,
this is any SIP message that contains an answer. Usually, this is
a 200 OK.
Terminate Message The signaling message used by a client to terminate Terminate Message The signaling message used by a client to terminate
the session and associated media streams. the session and associated media streams.
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 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) [8] (which lives at the operating system Realm Specific IP (RSIP) [12] (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.
Usable Local Transport Address: A local transport address created for
the purposes of advertisement to ICE peers.
Associated Local Transport Address: An associated transport address
is a local transport address used solely to obtain a derived
transport address. Associated local transport addresses are never
advertised in ICE messages. However, packets are received on them
when sent to the derived transport address.
Derived Transport Address: A derived transport address is a transport Derived Transport Address: A derived transport address is a transport
address which is associated with, but different from, a local address which is derived from an associated local transport
transport address. The derived transport address is associated address. The derived transport address is related to the
with the local transport address in that packets sent to the associated local transport address in that packets sent to the
derived transport address are received on the socket bound to that derived transport address are received on the socket bound to its
local transport address. Derived addresses are obtained using associated local transport address. Derived addresses are
protocols like STUN and TURN, and more generally, any UNSAF obtained using protocols like STUN and TURN, and more generally,
protocol [11]. any UNSAF protocol [14].
Advertised Transport Addresses: The union of the usable local
transport addresses and the derived transport addresses. These
are the ones used in ICE messages.
Peer Derived Transport Address: A peer derived transport address is a Peer Derived Transport Address: A peer derived transport address is a
derived transport address learned from a STUN server running derived transport address learned from a STUN server running
within a peer in a media session. within a peer in a media session.
TURN Derived Transport Address: A derived transport address obtained TURN Derived Transport Address: A derived transport address obtained
from a TURN server. from a TURN server.
STUN Derived Transport Address: A derived transport address obtained STUN Derived Transport Address: A derived transport address obtained
from a STUN server whose address has been provisioned into the UA. from a STUN server whose address has been provisioned into the UA.
This, by definition, excludes Peer Derived Transport Addresses. This, by definition, excludes Peer Derived Transport Addresses.
Unilateral Allocations: Queries made to a network server which Unilateral Allocations: Queries made to a network server which
provides an UNSAF service. provides an UNSAF service.
Bilateral Allocations: Addresses obtained by using an UNSAF service Bilateral Allocations: Addresses obtained by using an UNSAF service
that actually runs on the peer of the communications session. that actually runs on the peer of the communications session.
Peer derived transport addresses are synonymous with bilateral Peer derived transport addresses are synonymous with bilateral
allocations. allocations.
4. Overview of ICE 4. Overview of ICE
ICE makes the fundamental assumption that clients exist in a network ICE makes the fundamental assumption that clients exist in a network
of segmented connectivity. This segmentation is the result of a of segmented connectivity. This segmentation is the result of a
number of addressing realms in which a client can simultaneously be number of addressing realms in which a client can simultaneously be
skipping to change at page 8, line 22 skipping to change at page 8, 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.
Before the initiator establishes a session, it obtains as many IP Initiator TURN,STUN Servers Responder
address and port combinations in as many address realms as it can. |(1) Gather Addresses | |
These adresses all represent potential points at which the initiator |-------------------->| |
will receive a specific media stream. Any protocol that provides a |(2) Initiate Msg. | |
client with an IP address and port on which it can receive traffic |------------------------------------------>|
can be used. These include STUN, TURN, RSIP, and even a VPN. The | |(3) Gather Addresses |
client also uses any local interface addresses. A dual-stack v4/v6 | |<--------------------|
client will obtain both a v6 and a v4 address/port. The only |(4) Accept Msg. | |
requirement is that, across all of these addresses, the initiator can |<------------------------------------------|
be certain that at least one of them will work for any responder it |(5) STUN Checks | |
might communicate with. Unfortunately, if the initiator communicates |<------------------------------------------|
with a peer that doesn't support ICE, only one address can be |(6) STUN Checks | |
provided to that peer. As such, the client will need to choose one |------------------------------------------>|
default address, which will be used by non-ICE clients. This would |(7) Media | |
typically be a TURN derived transport address, as it is most likely |<------------------------------------------|
to work with unknown non-ICE peers. |(8) Media | |
|------------------------------------------>|
The initiator then runs a STUN server on each of the local transport Figure 2
addresses it has obtained. The initiator will need to be able to
demultiplex STUN messages and media messages received on that IP The basic flow of operation for ICE is shown in Figure 2. Before the
address and port, and process them appropriately. All of these initiator establishes a session, it obtains as many IP address and
addresses are placed into the initiate message, and they are ordered port combinations in as many address realms as it can. These
in terms of preference. Preference is a matter of local policy, but adresses all represent potential points at which the initiator will
typically, lowest preference would be given to transport addresses receive a specific media stream. Any protocol that provides a client
learned from a TURN server (i.e., TURN derived transport addresses). with an IP address and port on which it can receive traffic can be
The initiate message also conveys the STUN username and password used. These include STUN, TURN, RSIP, and even a VPN. The client
which are required to gain access to the STUN server on each address/ also uses any local interface addresses. A dual-stack v4/v6 client
port combination. will obtain both a v6 and a v4 address/port. The only requirement is
that, across all of these addresses, the initiator can be certain
that at least one of them will work for any responder it might
communicate with. Unfortunately, if the initiator communicates with
a peer that doesn't support ICE, only one address can be provided to
that peer. As such, the client will need to choose one default
address, which will be used by non-ICE clients. This would typically
be a TURN derived transport address, as it is most likely to work
with unknown non-ICE peers.
The initiator then runs a STUN server on each the local transport
addresses it has obtained. These include ones that will be
advertised directly through ICE, and so-called associated local
transport addresses, which are not directly advertised; rather, the
transport address derived from them is advertised. The initiator
will need to be able to demultiplex STUN messages and media messages
received on that IP address and port, and process them appropriately.
All of these addresses are placed into the initiate message, and they
are ordered in terms of preference. Preference is a matter of local
policy, but typically, lowest preference would be given to transport
addresses learned from a TURN server (i.e., TURN derived transport
addresses). The initiate message also conveys the one half of the
STUN username and the password which are required to gain access to
the STUN server on each address/port combination.
The initiate message is sent to the responder. This specification The initiate message is sent to the responder. This specification
does not address the issue of how the signaling messages themselves does not address the issue of how the signaling messages themselves
traverse NAT. It is assumed that signaling protocol specific traverse NAT. It is assumed that signaling protocol specific
mechanisms are used for that purpose. The responder follows a mechanisms are used for that purpose. The responder follows a
similar process as the initiator followed; it obtains addresses from similar process as the initiator followed; it obtains addresses from
local interfaces, STUN servers, TURN servers, etc., and it places all local interfaces, STUN servers, TURN servers, etc., and it places all
of them into the accept message. of them, along with the other half of the STUN username and its
password, into the accept message.
Once the responder receives the initiate message, it has a set of Once the responder receives the initiate message, it has a set of
potential addresses it can use to communicate with the initiator. potential addresses it can use to communicate with the initiator.
The initiator will be running a STUN server at each address. The The initiator will be running a STUN server at each address. The
responder sends a STUN request to each address, in parallel. When responder sends a STUN request to each address, in parallel. When
the initiator receives these, it sends a STUN response. If the the initiator receives these, it sends a STUN response. If the
responder receives the STUN response, it knows that it can reach its responder receives the STUN response, it knows that it can reach its
peer at that address. It can then begin to send media to that peer at that address. It can then begin to send media to that
address. As additional STUN responses arrive, the responder will address. As additional STUN responses arrive, the responder will
learn about additional transport addresses which work. If one of learn about additional transport addresses which work. If one of
skipping to change at page 9, line 40 skipping to change at page 9, line 49
request, it takes note of the source IP address and port of that request, it takes note of the source IP address and port of that
request. It compares that transport address to the existing set of request. It compares that transport address to the existing set of
potential addresses. If it's not amongst them, it gets added as potential addresses. If it's not amongst them, it gets added as
another potential address. The incoming STUN message provides the another potential address. The incoming STUN message provides the
client with enough context to associate that transport address with a client with enough context to associate that transport address with a
STUN username, STUN password, and priority, just as if it had been STUN username, STUN password, and priority, just as if it had been
sent in an initiate or accept message. As such, the client begins sent in an initiate or accept message. As such, the client begins
sending STUN messages to it as well, and if those succeed, the sending STUN messages to it as well, and if those succeed, the
address can be used if it has a higher priority. address can be used if it has a higher priority.
After a successful STUN transaction, the client will re-perform the
STUN query periodically to revalidate connectivity. This allows for
recovery from NAT failures, or from route flaps which may cause
packets to suddenly traverse a different NAT. As such, the address
used as the destination for media is the highest priority address to
which connectivity currently exists.
5. Detailed ICE Algorithm 5. Detailed ICE Algorithm
This section describes the detailed processing needed for ICE. This section describes the detailed processing needed for ICE.
5.1 Initiator Processing 5.1 Initiator Processing
5.1.1 Sending the Initiate Message 5.1.1 Sending the Initiate Message
When the initiator wishes to begin communications, it starts by When the initiator wishes to begin communications, it starts by
gathering transport addresses, as described in Section 5.3.1, and gathering transport addresses, as described in Section 5.3.1, and
starting a STUN server on each local transport address, as described starting a STUN server on each local transport address, both usable
in Section 5.3.2. This process can actually happen at any time and associated, as described in Section 5.3.2. This process can
before sending an initiate message. A client can pre-gather actually happen at any time before sending an initiate message. A
transport addresses, using a user interface cue (such as picking up client can pre-gather transport addresses, using a user interface cue
the phone, or entry into an address book) as a hint that (such as picking up the phone, or entry into an address book) as a
communications is imminent. hint that communications is imminent. Doing so eliminates any
additional perceivable call setup delays due to address gathering.
When it comes time to initiate communications, it determines a When it comes time to initiate communications, it determines a
priority for each one and identifies one as a default, as described priority for each one and identifies one as a default, as described
in Section 5.3.3. in Section 5.3.3.
The next step is to construct the initiate message. Section 7 The next step is to construct the initiate message. Section 7
provides the XML schema for the initiate message. The message provides the XML schema for the initiate message. The message
consists of a series of media streams. For each media stream, there consists of a series of media streams. For each media stream, there
is a default address and a list of alternates. The default address is an IPv4 and/or an IPv6 default address, and a list of candidates.
is the one that will be used by responders that don't understand ICE Each candidate has information for RTP and optionally RTCP. RTCP
(for SIP, this is accomplished by mapping the default address into information is optional since, unfortunately, many systems don't
the m and c line in the SDP). The alternates represent addresses support it. If ICE did not indicate that RTCP was not supported,
that the responder should also try. In SIP, these are conveyed with connectivity checks would be made to the RTCP ports and fail,
the new SDP alt parameter. confusing operation and adding unneccesary overhead.
The client then encodes all of its available transport addresses The default address is the one that will be used by responders that
(including the default) as a series of alternate elements. Each don't understand ICE (for SIP, this is accomplished by mapping the
alternate element conveys a transport address for RTP, one for RTCP, default address into the m and c line in the SDP). The candidates
a STUN username fragment and STUN password. The client MUST assign represent addresses that the responder should try using the
each alternate a unique identifier. These identifiers MUST be unique mechanisms of this specification. The list of candidates includes
across all alternates used within the session. This identifier is the defaults. In SIP, the candidates are conveyed with the new SDP
encoded in the "id" attribute of the alternate element. The priority candidate parameter.
for the transport address, as computed above, is included as an
attribute as well. The client then encodes its usable local transport addresses and
derived transport addresses (including the one set as the default) as
a series of candidate elements. Each candidate element conveys a
transport address for RTP, a transport address for RTCP, a STUN
username fragment and STUN password for RTP, and one for RTCP. The
client MUST assign each candidate a unique identifier. These
identifiers MUST be unique across all candidates used within the
session. Though they are not used in this specification, they serve
as a convenient and short handle for each candidate within the
document. Experience has shown that explicit identifiers for
elements in SDP is a good idea. This identifier is encoded in the
"id" attribute of the <candidate> element. The priority for the
transport address, as computed above, is included as an attribute as
well.
Once the initiate message is constructed, it is sent. Once the initiate message is constructed, it is sent.
5.1.2 Processing the Accept 5.1.2 Processing the Accept
There are two possible cases for processing of the Accept message. There are two possible cases for processing of the Accept message.
If the recipient of the Initiate message did not support ICE, the If the recipient of the Initiate message did not support ICE, the
Accept message will only contain the default address information. As Accept message will only contain the default address information. As
a result, the initiator knows that it cannot perform its connectivity a result, the initiator knows that it cannot perform its connectivity
checks. In this case, it SHOULD just send to the transport address checks. In this case, it SHOULD just send to the transport address
listed. However, if local configuration information tells the listed. However, if local configuration information tells the
initiator to try connectivity checks by sending them through the TURN initiator to try connectivity checks by sending them through the TURN
server, this means that packets sent directly to responder may be server, this means that packets sent directly to responder may be
dropped by a local firewall. To deal with this, the initiator SHOULD dropped by a local firewall. To deal with this, the initiator SHOULD
issue a SEND command using this new transport address. The SEND issue a SEND command using this new transport address as the
command contains the media packet to send to the responder. Once destination. The SEND command contains the media packet to send to
this command has been accepted, the initiator SHOULD send all media the responder. Once this command has been accepted, the initiator
packets to the TURN server, which will then forward them towards the SHOULD send all media packets through the TURN server, which will
responder. then forward them towards the responder.
If the Accept message contains alternates, it implies that the If the Accept message contains candidates, it implies that the
responder supported ICE. In that case, the initiator takes each responder supported ICE. In that case, the initiator takes each
transport address, STUN username, STUN password and priority, and candidate transport address, STUN username fragment, STUN password
places them into a list, called the candidate list. It then begins and priority, and places them into a list, called the candidate list.
processing the candidate list as described in Section 5.3.4. That It then begins processing the candidate list as described in Section
processing associates a state with each transport address. As 5.3.4. That processing associates a state with each transport
described there, once a successful STUN query is made to the STUN address. As described there, once a successful STUN query is made to
server at an address, the initiator can begin sending media to that the STUN server at an address, the initiator can begin sending media
address. to that address.
5.2 Responder Processing 5.2 Responder Processing
5.2.1 Processing the Initiate Message 5.2.1 Processing the Initiate Message
Upon receipt of the initiate message, the client starts gathering Upon receipt of the initiate message, the client starts gathering
transport addresses, as described in Section 5.3.1, and starts a STUN transport addresses, as described in Section 5.3.1, and starts a STUN
server on each local transport address, as described in Section server on each local transport address, as described in Section
5.3.2. This processing is done immediately on receipt of the 5.3.2. This processing is done immediately on receipt of the
request, to prepare for the case where the user should accept the request, to prepare for the case where the user should accept the
call, or early media needs to be generated. call, or early media needs to be generated. By gathering addresses
while the user is being alerted to the request for communications,
session establishment delays due to that gathering can be eliminated.
At some point, the responder will decide to accept or reject the At some point, the responder will decide to accept or reject the
communications. A rejection terminates ICE processing, of course. communications. A rejection terminates ICE processing, of course.
In the case of acceptance, the accept message is constructed as In the case of acceptance, the accept message is constructed as
follows. follows.
The client first determines a priority for each transport address it The client first determines a priority for each usable local
has gathered, and identifies one as a default, as described in transport address and derived transport address it has gathered, and
Section 5.3.3. identifies one as a default, as described in Section 5.3.3.
Constructing the accept proceeds identically to the way in which the Constructing the accept message proceeds identically to the way in
initiate message is constructed (Section 5.1.1). which the initiate message is constructed (Section 5.1.1).
The accept is then sent. The accept message is then sent.
5.3 Common Procedures 5.3 Common Procedures
This section discusses procedures that are common between initiator This section discusses procedures that are common between initiator
and responder. and responder.
5.3.1 Gathering Transport Addresses 5.3.1 Gathering Transport Addresses
A client gathers addresses when it believes that communications is A client gathers addresses when it believes that communications is
imminent. For initiators, this occurs before sending an initiate imminent. For initiators, this occurs before sending an initiate
message (Section 5.1.1). For responders, it occurs before sending a message (Section 5.1.1). For responders, it occurs before sending a
accept message (Section 5.2.1). accept message (Section 5.2.1).
There are two types of addresses a client can gather - local There are two types of addresses a client can gather - usable local
transport addresses, and derived transport addresses. Local transport addresses and derived transport addresses. Usable local
transport addresses are obtained by binding to an ephemeral port on transport addresses are obtained by binding to an ephemeral port on
an interface (physical or virtual) on the host. A multi-homed host an interface (physical or virtual) on the host. A multi-homed host
SHOULD attempt to bind on all interfaces for all media streams it SHOULD attempt to bind on all interfaces for all media streams it
wishes to receive. For media streams carried using the Real Time wishes to receive. For media streams carried using the Real Time
Transport Protocol (RTP) [12], the client will need to bind to an Transport Protocol (RTP) [15], the client will need to bind to an
ephemeral port for both RTP and RTCP. ephemeral port for both RTP and RTCP.
The result will be a set of local transport addresses. The client The result will be a set of usable local transport addresses. The
may also have access to servers that provide unilateral self-address client may also have access to servers that provide unilateral
fixing (UNSAF) [11]. Examples of such protocols include STUN, TURN, self-address fixing (UNSAF) [14]. Examples of such protocols include
and TEREDO [15]. All ICE implementations MUST implement STUN and STUN, TURN, and TEREDO [18]. UNSAF protocols work by having the
TURN, but MAY, through configuration, disable the use of STUN or TURN client send, from a specific associated local transport address, some
for unilateral address allocation (STUN is mandatory for the kind of message to a server. The server provides to the client, in
connectivity checks described below). When disabled, it MUST be some kind of response, an additional transport address, called a
possible through user or administrator operation to re-enable. This derived transport address. This derived transport address is derived
allows all implementations to have the breadth of protocol support from the associated local transport address. Here, derivation means
needed to work in all situations, with the flexibility to turn if off that a request sent to the derived transport address might (under
if its not needed. good network conditions) reach the client on its associated local
transport address.
These protocols work by having the client send, from a specific local All ICE implementations SHOULD implement and use STUN and TURN for
transport address, some kind of message to a server. The server unilateral allocation. STUN is an integral part of this
provides to the client, in some kind of response, an additional specification for connectivity checks and will always be present for
transport address, called a derived transport address. This derived that purpose. The usage of TURN and STUN for unilateral allocations
transport address is derived from the local transport address. Here, is at SHOULD strength, and not MUST, since there are many network
derivation means that a request sent to the derived transport address environments, and there will be deployments for which one of these
might (under good network conditions) reach the client on its local will never be used and will impose needless cost. However, one of
the key ideas behind ICE is that network conditions and connectivity
assumptions can, and will change. Just because a client is
communicating with a server on the public network today, doesn't mean
that it won't need to communicate with one behind a NAT tomorrow.
Just because a client is behind a full cone NAT today, doesn't mean
that tomorrow they won't pick up their client and take it to a public
network access point where there is a symmetric NAT. The way to
handle these cases and build a reliable system is for clients to
implement a diverse set of techniques for allocating addresses, so
that at least one of them is almost certainly going to work in any
situation. The combination of TURN, STUN and local address
allocations provide sufficient coverage to handle nearly any NAT
configuration. Implementors should consider very carefully any
assumptions that they make about deployments before electing not to
implement one of these mechanisms for address allocation. In
particular, implementors should consider whether the elements in the
system may be mobile, and connect through different networks with
different connectivity. They should also consider whether endpoints
which are under their control, in terms of location and network
connectivity, would always be under their control. Only in cases
where implementors truly believe that these cases will not require
either TURN or STUN allocations, should those techniques not be
implemented.
For each UNSAF protocol, the client may have access to a multiplicity
of servers. For example, a user connected to a natted cable access
network might have access to a STUN server in the private cable
network and in the public Internet. For each server for each UNSAF
protocol, the client MUST bind to a new local transport address, and
uses it to obtain a single derived transport address for it. This
local IP address and port is called an associated transport address.
These addresses are not advertised to peers in ICE messages; their
derived transport addresses are. As a result of using a different
local transport address for each derived transport address, every
transport address advertised in an ICE message is either a unique
local transport address, or else is derived from a unique local
transport address. transport address.
For each of these protocols, the client may have access to a If a derived transport address is equal to the associated local
multiplicity of servers. For example, a user connected to a natted transport address from which it was derived, the local transport
cable access network might have access to a STUN server in the address SHOULD be promoted to a usable local transport address. It
private cable network and in the public Internet. For each local is preferable to do this than to use a new local transport address;
transport address, the client SHOULD obtain an address from every the UNSAF protocol may have caused pinholes to open in intervening
server for each protocol it supports. The result of this will be a firewalls.
set of derived transport addresses, with each derived address
associated with the local transport address it is derived from. Implementations MAY use other protocols that provide derived
transport addresses, as long as those techniques meet the following
conditions:
1. The technique does not require its peer to know about, or
understand the technique in order to interoperate.
2. The technique can provide the client with an IP address and port
that may be reachable by some peers.
3. The technique allows the client to receive STUN connectivity
checks in addition to media packets on the same IP address and
port.
4. The technique allows the client to send packets to a peer, so
that the peer will see the derived transport address as the
source IP address and port of the packet.
5.3.2 Enabling STUN on Each Local Transport Address 5.3.2 Enabling STUN on Each Local Transport Address
Once the client has obtained a set of transport addresses, it starts Once the client has obtained a set of transport addresses, it starts
a STUN server on each local transport address (including ones used a STUN server on each local transport address, including both
for RTCP). This, by definition, means that the STUN service will be associated local transport addresses and usable transport addresses.
reached for requests sent to the derived addresses. These include ones used for both RTP and RTCP. This, by definition,
means that the STUN service will be reached for requests sent to the
derived addresses.
However, the client does not need to provide STUN service on any However, the client does not need to provide STUN service on any
other IP address or port, unlike the STUN usage described in [1]. other IP address or port, unlike the STUN usage described in [1].
The need to run the service on multiple ports is to support the The need to run the service on multiple ports is to support the
change flags. However, those flags are not needed with ICE, and the change flags. However, those flags are not needed with ICE, and the
server SHOULD reject, with a 400 response, any STUN requests with server SHOULD reject, with a 400 response, any STUN requests with
these flags set. these flags set. The CHANGED-ADDRESS attribute in a BindingResponse
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 Furthermore, there is no need to support TLS or to be prepared to
receive SharedSecret request messages. Those messages are used to receive SharedSecret request messages. Those messages are used to
obtain shared secrets to be used with BindingRequests. However, with obtain shared secrets to be used with BindingRequests. However, with
ICE, usernames and passwords are exchanged in the signaling protocol. ICE, usernames and passwords are exchanged in the signaling protocol.
The client will receive both STUN requests and media packets on each The client will receive both STUN requests and media packets on each
local transport address. The client MUST be able to disambiguate local transport address. The client MUST be able to disambiguate
them. In the case of RTP/RTCP, this disambiguation is easy. RTP and them. In the case of RTP/RTCP, this disambiguation is easy. RTP and
RTCP packets start with the bits 0b10 (v=2). The first two bits in RTCP packets start with the bits 0b10 (v=2). The first two bits in
STUN are always 0b00. This disambiguation also works for packets STUN are always 0b00. This disambiguation also works for packets
sent using Secure RTP [13], since the RTP header is in the clear. sent using Secure RTP [16], since the RTP header is in the clear.
Disambiguating STUN with other media stream protocols may be more Disambiguating STUN with other media stream protocols may be more
complicated. However, it can always be possible with arbitrarily complicated. However, it can always be possible with arbitrarily
high probabilities by selecting an appropriately random username (see high probabilities by selecting an appropriately random username (see
below). below).
The need to run STUN on the same transport address as the media The need to run STUN on the same transport address as the media
stream represents the "ugliest" piece of ICE. However, it is an stream represents the "ugliest" piece of ICE. However, it is an
essential part of the story. By sending STUN requests to the very essential part of the story. By sending STUN requests to the very
same place media is sent, any bindings learned through STUN will be same place media is sent, any bindings learned through STUN will be
useful even when communicating through symmetric NATs. This results useful even when communicating through symmetric NATs. This results
in a substantial increase in the scope of applicability of STUN. in a substantial increase in the scope of applicability of STUN.
For each local transport address where a STUN server is running, the For each transport address advertised in the initiate message, the
client MUST choose a username fragment and a password. The username client MUST choose a username fragment and a password. The username
fragment created by the client will be concatenated with the fragment fragment created by the client (called the local username fragment)
created by its peer. The result will serve as the username provided is concatenated with the fragment created by its peer (called the
by its peer in STUN requests. By creating the username as a remote username fragment) to create the actual username used for
combination of information from each side of a call, it allows a access to the STUN server that will receive packets sent to that
client to correlate the source of the request with a candidate transport address. This username will be present in STUN requests
transport address. This is discussed further below. sent by its peer. By creating the username as a combination of
information from each side of a call, it allows a client to correlate
the source of the request with a candidate transport address. This
is discussed further below.
The username fragment MUST be globally unique, so that no other host The username fragment MUST be globally unique with high probability,
will select a username with the same value. This username fragment and different for each advertised transport address. It SHOULD be
persistently used over time for that particular transport address. A
value computed as the 128 bit hash of the transport address
concatenated with a 128 bit random number selected to identify the
host will meet these requirements. This results in two properties.
First - each transport address can be uniquely identified. Secondly,
no other host will select a username with the same value. The
password MUST be random with at least 128 bits of randomness and is
selected separately for each transport address advertised as part of
a distinct session. This means that RTP and RTCP, which run on
different transport addresses, will get different usernames and
passwords. The password will remain constant during a session with a
peer, but will otherwise vary across sessions. The username fragment
and password will be passed to its peer in an initiate or accept and password will be passed to its peer in an initiate or accept
message. As such, the process described in this section will message. Because the password is conveyed through these signaling
associate, with each local transport address, a username fragment and protocols, those protocols MUST provide facilities for encryption,
password. The client also associates this same username fragment and authentication and message integrity, and those facilities SHOULD be
password with any transport addresses derived from the local used when ICE is employed. As such, the process described in this
transport address. section will associate, with each local transport address, a username
fragment and password. The client also associates this same username
fragment and password with any transport addresses derived from the
local transport address.
The global uniqueness requirement stems from the lack of uniquenes The global uniqueness requirement stems from the lack of uniquenes
afforded by IP addresses. Consider clients A, B, and C. A and B are afforded by IP addresses. Consider clients A, B, and C. A and B are
within private enterprise 1, which is using 10.0.0.0/8. C is within within private enterprise 1, which is using 10.0.0.0/8. C is within
private enterprise 2, which is also using 10.0.0.0/8. As it turns private enterprise 2, which is also using 10.0.0.0/8. As it turns
out, B and C both have IP address 10.0.1.1. A initiates out, B and C both have IP address 10.0.1.1. A initiates
communications to C. C, in its accept message, provides A with its communications to C. C, in its accept message, provides A with its
transport addresses. In this case, thats 10.0.1.1:8866 and 8877. As transport addresses. In this case, thats 10.0.1.1:8866 and 8877. As
it turns out, B is in a session at that same time, and is also using it turns out, B is in a session at that same time, and is also using
10.0.1.1:8866 and 8877. This means that B has a STUN server running 10.0.1.1:8866 and 8877. This means that B has a STUN server running
on those ports, just as C does. A will send a STUN request to on those ports, just as C does. A will send a STUN request to
10.0.1.1:8866 and 8877. However, these do not go to C as expected. 10.0.1.1:8866 and 8877. However, these do not go to C as expected.
Instead, they go to B. If B just replied to them, A would believe it Instead, they go to B. If B just replied to them, A would believe it
has connectivity to C, when in fact it has connectivity to a has connectivity to C, when in fact it has connectivity to a
completely different user, B. To fix this, the STUN username takes completely different user, B. To fix this, the STUN username
on the role of a unique identifier. C provides A with a unique fragment takes on the role of a unique identifier. C provides A with
username. A uses this username in its STUN query to 10.0.1.1:8866. a unique username fragment, and A provides one to C. A uses these
This STUN query arrives at B. However, the username is unknown to B, two fragments to construct the username in its STUN query to
and so the request is rejected. A treats the rejected STUN request 10.0.1.1:8866. This STUN query arrives at B. However, the username
as if there were no connectivity to C (which is actually true). is unknown to B, and so the request is rejected. A treats the
Therefore, the error is avoided. rejected STUN request as if there were no connectivity to C (which is
actually true). Therefore, the error is avoided.
Once the STUN server is started, it MUST run continuously until the An unfortunate consequence of the non-uniqueness of IP addresses is
session is completed. While the server is running, it MUST act as a that, in the above example, B might not even be an ICE client. It
normal STUN server, but MUST only accept STUN requests from clients could be any host, and the port to which the STUN packet is directed
that authenticate, as discussed below in Section 5.3.5 could be any ephemeral port on that host. If there is an application
listening on this socket for packets, and it is not prepared to
handle malformed packets for whatever protocol is in use, the
operation of that application could be effected. Fortunately, since
the ports exchanged in SDP are ephemeral and ususally drawn from the
dynamic or registered range, the odds are good that the port is not
used to run a server on host B, but rather is the client side of some
protocol. This decreases the probability of hitting a port in-use,
due to the transient nature of port usage in this range. However,
the possibility of a problem does exist, and network deployers should
be prepared for it.
Termination of the local STUN servers is discussed in Section 5.3.6.
5.3.3 Prioritizing the Transport Addresses and Choosing a Default 5.3.3 Prioritizing the Transport Addresses and Choosing a Default
The prioritization process takes a list of transport addresses, and The prioritization process takes the list of the advertised transport
associates each with a priority. This priority reflects the desire addresses, and associates each with a priority. This priority
that the UA has to receive media on that address, and is assigned as reflects the desire that the UA has to receive media on that address,
a value from 0 to 1 (1 being most preferred). Priorities are and is assigned as a value from 0 to 1 (1 being most preferred).
ordinal, so that their significance is only relative to other Priorities are ordinal, so that their significance is only relative
transport address priorities in the same list. to other transport address priorities in the same list.
This specification makes no normative recommendations on how the This specification makes no normative recommendations 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 transport address over another is One criteria for choosing one transport address over another is
whether or not that transport address involves the use of a relay. whether or not that transport address involves the use of a relay.
That is, if media is sent to that transport address, will the media That is, if media is sent to that transport address, will the media
first transit a relay before being received. TURN derived transport first transit a relay before being received. TURN derived transport
addresses make use of relays (the TURN server), as to any local addresses make use of relays (the TURN server), as do any local
transport addresses associated with a VPN server. When media is transport addresses associated with a VPN server. When media is
transited through a relay, it can increase the latency between transited through a relay, it can increase the latency between
transmission and reception. It can increase the packet losses, transmission and reception. It can increase the packet losses,
because of the additional router hops that may be taken. It may because of the additional router hops that may be taken. It may
increase the cost of providing service, since media will be routed in increase the cost of providing service, since media will be routed in
and right back out of a relay run by the provider. If these concerns and right back out of a relay run by the provider. If these concerns
are important, transport addresses with this property can be listed are important, transport addresses with this property can be listed
with lower priority. with lower priority.
Another criteria for choosing one address over another is IP address Another criteria for choosing one address over another is IP address
family. ICE works with both IPv4 and IPv6. It therefore provides a family. ICE works with both IPv4 and IPv6. It therefore provides a
transition mechanism that allows dual-stack hosts to prefer transition mechanism that allows dual-stack hosts to prefer
connectivity over IPv6, but to fall back to IPv4 in case the v6 connectivity over IPv6, but to fall back to IPv4 in case the v6
networks are disconnected (due, for example, to a failure in a 6to4 networks are disconnected (due, for example, to a failure in a 6to4
relay) [14]. It can also help with hosts that have both a native relay) [17]. It can also help with hosts that have both a native
IPv6 address and a 6to4 address. In such a case, higher priority IPv6 address and a 6to4 address. In such a case, higher priority
could be afforded to the native v6 address, followed by the 6to4 could be afforded to the native v6 address, followed by the 6to4
address, followed by a native v4 address. This allows a site to 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 addresss immediately, yet still
fallback to 6to4 addresses when communicating with clients in other fallback to 6to4 addresses when communicating with clients 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 address over another is security. Another criteria for choosing one address 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
local network when communicating within the enterprise, but use the corporate network when communicating within the enterprise, but use
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 transport addresses which make awareness. This is most useful for transport addresses which make
use of relays (including TURN and VPN). In those cases, if a client use of relays (including TURN and VPN). In those cases, if a client
has preconfigured or dynamically discovered knowledge of the has preconfigured or dynamically discovered knowledge of the
topological proximity of the relays to itself, it can use that to topological proximity of the relays to itself, it can use that to
select closer relays with higher priority. select closer relays with higher priority.
Once the transport addresses have been prioritized, one is selected Once the transport addresses have been prioritized, one is selected
as the default. This is the address that will be used by a peer that as the default. This is the address that will be used by a peer that
doesn't understand ICE. The default has no relevance when doesn't understand ICE. The default has no relevance when
communicating with an ICE capable peer. As such, it is RECOMMENDED communicating with an ICE capable peer. As such, it is RECOMMENDED
that the default be chosen based on the likelihood of that address that the default be chosen based on the likelihood of that address
being useful when communicating with a peer that doesn't support ICE. being useful when communicating with a peer that doesn't support ICE.
Unfortunately, it is difficult to ascertain which address that might
be. As an example, consider a user within an enterprise. To reach
non-ICE capable clients within the enterprise, a local transport
address has to be used, since the enterprise policies may prevent
communication between elements using a relay on the public network.
However, when communicating to peers outside of the enterprise, a
TURN-based public address is needed.
This will frequently be a TURN derived transport address from a TURN Indeed, the difficulty in picking just one address that will work is
server providing public IP addresses. the whole problem that motivated the development of this
specification in the first place. As such, it is RECOMMENDED that
the default address be a TURN derived transport address from a TURN
server providing public IP addresses. Furthermore, ICE is only truly
effective when it is supported on both sides of the session. It is
therefore most prudent to deploy it to close-knit communities as a
whole, rather than piecemeal. In the example above, this would mean
that ICE would ideally be deployed completely within the enterprise,
rather than just to parts of it.
5.3.4 Sending STUN Connectivity Checks 5.3.4 Sending STUN Connectivity Checks
Once a responder has received an initiate message, or an initiator Once a responder has received an initiate message, or an initiator
has received an accept message, the list of transport addresses is has received an accept message, the list of transport addresses is
extracted from the message. These transport addresses, called the extracted from the message. These transport addresses, called the
remote transport addresses, along with the username fragment, remote transport addresses, along with the username fragment from the
password, and priority from the message are placed into a table, peer (called the remote username fragment), the password from the
called the candidate table. There is a candidate table for RTP for peer (called the remote password), and priority from the peer (called
each media stream, and for RTCP for each media stream. So, if a the remote priority) are placed into a table called the candidate
session is established with audio and video, there would be four table. There is a candidate table for RTP for each media stream, and
tables - audio RTP, audio RTCP, video RTP and video RTCP. for RTCP for each media stream. So, if a session is established with
audio and video, there would be four tables - audio RTP, audio RTCP,
video RTP and video RTCP. An example of a candidate table for RTP
audio is shown below.
The client then takes its own gathered addresses, and creates a Remote Remote Remote Remote
subset called the sourceable addresses. This subset is the set of Transport Username Password Priority
local transport addresses (including VPN and RSIP) and TURN derived Address Fragment
transport addresses. Thus, it excludes STUN derived transport --------------------------------------------------------------------
addresses. The formal definition of this subset is defined below. 10.0.1.1:38746 asd9f8f8== 9asfhfvva9==affahnz 0.4
192.0.2.77:44634 xcyca87sbb f99fhaz0ftrafdgl99d 0.2
Each row in this table is then replicated once for each sourceable Figure 3
transport address. The table has a column for the sourceable The client then creates a new table, called the connection table.
transport address value, and this is populated upon replication. There is a row in this table for each gathered address and remote
That table also has a column called "my username fragment", which is transport address pair. This table has a column for the local
the username fragment that the client created for sourceable transport address, which is equal to the gathered address if it was a
transport address in that row. Each row in this table is called a usable local transport address, else equal to the associated local
candidate. transport address if the gathered address was a derived address.
There is also a column for the remote transport address, the local
username fragment, the remote username fragment, the remote password
and the state. Each row in this table is called a connection, and it
provides information on the connectivity when sending packets from
the local transport address to the remote transport address.
There are four possible states for each connection. These states
are:
Each candidate is associated with a state. The state represents the
current understanding of connectivity to that remote transport
address when packets are sent from that sourceable address. There
are five possible states. These states are:
INIT: No STUN transaction has been completed towards this remote INIT: No STUN transaction has been completed towards this remote
transport address from this sourceable address. transport address from this local transport address.
HANDSHAKING: One or more STUN transactions have failed, but HANDSHAKING: One or more STUN transactions have failed, but
insufficient time has passed since leaving the INIT state to be insufficient time has passed since leaving the INIT state to be
certain that the remote transport address is unreachable from this certain that the remote transport address is unreachable from this
sourceable address. This state is important for connectivity local transport address. This state is important for connectivity
checks made to STUN derived transport addresses through port checks made to STUN derived transport addresses through port
restricted NAT or a TURN derived transport address. restricted NAT.
BAD: All STUN transactions to this remote transport address from this BAD: All STUN transactions to this remote transport address from this
sourceable address have either timed out, or failed with a 600 local transport address have either timed out, or failed with a
response, and a sufficient amount of time has elapsed since the 600 response, and a sufficient amount of time has elapsed since
INIT state to have high confidence that the remote transport the INIT state to have high confidence that the remote transport
address cannot be reached from this sourceable address. address cannot be reached from this local transport address.
GOOD: The last STUN transaction to this remote transport address from GOOD: A STUN transaction to this remote transport address from this
this sourceable address was successful. However, it is not the local transport address was successful.
highest priority candidate, and therefore, is not in use for
media.
When the client first populates the tables from the initiate or When the client first populates the tables from the initiate or
accept message, all of the transport addresses are set to the INIT accept message, all of the connections are set to the INIT state.
state.
Consider the the following example. An initiator sends an initiate Consider the the following example. An initiator sends an initiate
message with one media stream (audio), with two transport addresses, message with one media stream (audio), with two RTP transport
A and B. A is a local transport address, and B is a STUN derived addresses, 10.0.1.1:38746 (which we denote "A" for shorthand) and
transport address (although that fact is not signaled in the 192.0.2.77:44634 (which we denote "B" for shorthand). A is a usable
message). Both of these will have the same username fragment and local transport address, and B is a STUN derived transport address
password, but different priorities. The initiate message is sent to (although that fact is not signaled in the message). The usernames
the responder. The responder has a local transport address, a STUN and passwords for these transport addresses are shown in Figure 3.
derived transport address, and a TURN derived transport address. The initiate message is sent to the responder. The responder has a
Call these X, Y and Z respectively. Thus, it has two sourceable local transport address (10.0.1.76:43443), and a a STUN derived
addresses, X and Z. The table created by the responder would have transport address (192.0.2.64:54766) derived from (10.0.1.76:43444).
four rows. Each of the two transport addresses in the initiate Call these two local transport addresses X and Y respectively. The
message is present twice, once with the responder's local transport connection table created by the responder would have four rows (two
address, and once with its TURN derived address. Such a table might local transport addresses times two remote transport addresses).
look like this: Such a table might look like this:
Remote Srcable User Frag Passwd My-Usr-Frag Priority State Remote Local Remote Local Remote Remote
-------------------------------------------------------------------- Trans. Trans. Username Username Password Priority
A X asd9f8f8== siprulz x-frag 0.4 INIT Address Address Fragment Fragment State
A Z asd9f8f8== siprulz z-frag 0.4 INIT ------------------------------------------------------------------------
B X asd9f8f8== siprulz x-frag 0.2 INIT A X asd9f8f8== 8asd77fa9 9asfhfvva9==affahnz 0.4 INIT
B Z asd9f8f8== siprulz z-frag 0.2 INIT A Y asd9f8f8== zhff8dga^ 9asfhfvva9==affahnz 0.4 INIT
B X xcyca87sbb 8asd77fa9 f99fhaz0ftrafdgl99d 0.2 INIT
B Y xcyca87sbb zhff8dga^ f99fhaz0ftrafdgl99d 0.2 INIT
The client begins a STUN BindingRequest transaction for each The client begins a STUN BindingRequest transaction for each
candidate. This STUN transaction is sent to the IP address and port connection. This STUN transaction is sent to the IP address and port
from the Remote column. It sends the request from the IP address and from the Remote Transport Address column. It sends the request from
port in the sourceable column. For local transport addresses, that the IP address and port in the Local Transport Address column. The
means sending from the locally bound socket. For VPN addresses, that STUN USERNAME attribute MUST be present. It is set to the
means sending from the socket bound to the VPN interface. For TURN concatenation of the remote user fragment with the local user
derived transport addresses, this means using the TURN Send message fragment from the table. Thus, for the candidate with remote
to send a request through the TURN server. This provides the transport address A and local transport address X, the USERNAME would
definition of the sourceable flag: they represent distinct transport be set to "asd9f8f8==8asd77fa9". The BindingRequest SHOULD contain a
addresses that a client can send from. A STUN derived transport
address is not distinct from a local transport address, since a
client cannot send a packet to a particular IP address and port with
different source IP addresses and ports as seen by that recipient
[[REPHRASE]]
The STUN USERNAME attribute MUST be present. It is set to the
concatenation of the user fragment from the table, with the "My User
Fragment" from the candidate. Thus, for the candidate with remote
transport address A and sourceable address X, the USERNAME would be
set to "asd9f8f8==x-frag". The BindingRequest SHOULD contain a
MESSAGE-INTEGRITY attribute, computed using the username in the MESSAGE-INTEGRITY attribute, computed using the username in the
USERNAME attribute, and the password from the password field in the USERNAME attribute, and the password from the password field in the
row. The BindingRequest MUST NOT contain the CHANGE-REQUEST or row. The BindingRequest MUST NOT contain the CHANGE-REQUEST or
RESPONSE-ADDRESS attribute. RESPONSE-ADDRESS attribute.
Each of these STUN transactions will generate either a timeout, or a Each of these STUN transactions will generate either a timeout, or a
response. If the response is an error, but recoverable as described response. If the response is a 420, 500, or 401, the client should
in RFC 3489, the client SHOULD try again using the procedures try again as described in RFC 3489. Either initially, or after such
discussed there. Either initialy, or after retry, the STUN a retry, the STUN transaction will produce a timeout result, a
transaction will produce a timeout result, a success result, or a success result, a fundamentally non-recoverable failure result (error
non-recoverable failure result (error codes 400, 431, or 600). These codes 400, 431, or 600) or a failure result inapplicable to this
correspond to "timeout", "success", and "error" events, respectively. usage of STUN and thus unrecoverable (432, 433), or a 430 error.
These correspond to the "timeout", "success", "error" and
"race-failure" events, respectively. The 430 response code, as
described below, is generated when the server doesn't recognize the
STUN username, presumably because the BindingRequest was sent to the
initiator prior to receipt of the ICE Accept message by the
initiator. It ocurrence is thus a result of a failed race between
the BindingRequest and Accept message. As the state machine below
discusses, the client will retry in this case.
These events are fed into the state machine described in Figure 3. These events are fed into the finite state machine (FSM) described in
This figure shows the transitions between states that occur on the Figure 5. This figure shows the transitions between states that
completion of the STUN BindingRequest transaction. After the occur on the completion of the STUN BindingRequest transaction or
completion of each transaction, the client sets a timer that upon the expiration of timers set by the FSM.
determines when it will do another transaction for that candidate.
The result of that next transaction drives the next transition in the
state machine, and so on. Since timers are set at the entry to each
state, STUN BindingRequest tranasactions will be tried continuously
throughout a call. This is necessary to detect a variety of failure
cases, as discussed below.
.......... race-failure,..........
. . timeout/ timeout/ . . ..........
. . Set Rapid Set . . . . Retry Fires/
+---------+ +---------+ . Retry Timer Retry Timer,. V . . Retry
| | | | . +---------+ . +---------+ .
| | | |<.... | | . | | .
| | .......| |<....
| INIT |......................>| HAND | | INIT |......................>| HAND |
| | timeout/ | SHAKING | | | race-failure, | SHAKING |
| | Set Rapid | | | | timeout/ | |
+---------+ Retry Timer, error/ +---------+ +---------+ Set +---------+
. . Giveup Timer Set . . . . Retry Timer, error, . .
. . Retry . . . . Giveup Timer Giveup . .
error/ . . Timer . . error . . Fires . .
Set . . ............................. . success/ . . ............................. . success
Retry . . . . Set Refresh . . . .
Timer . ...C.............................. . Timer . ...C.............................. .
. . success/ . . . . success . .
. . Set Refresh . . . . . .
V V Timer V V V V V V
+---------+ +---------+ +---------+ +---------+
| | | | | | | |
| | | | | | | |
| BAD |......................>| GOOD | | BAD |. | GOOD |
...>| | success/ | |....... | | | |
. | | Set Refresh | | . | | | |
. +---------+ Timer +---------+ . +---------+ +---------+
. . ^ . ^ .
. . . . . .
....... . . ..........
timeout or ................................ success/
error/ timeout or Set Refresh
Set error/ Timer
Retry Set
Timer Retry
Timer
Figure 3 Figure 5
Starting in the INIT state, if the transaction is successful, the Starting in the INIT state, if the transaction is successful, the
client has verified connectivity to that remote transport address client has verified connectivity to that remote transport address
when sending from that sourceable transport address. This means that when sending from that local transport address. This means that
media packets sent in exactly the same way will get through. As media packets sent in exactly the same way will get through. As
such, the FSM transitions to the GOOD state, and the client sets the such, the FSM transitions to the GOOD state. If, from the INIT
Refresh Timer. This timer is used to continually check that a good state, the STUN transaction times out, the FSM enters the HANDSHAKING
candidate remains good. It is possible for a candidate to cease state. At this point, there are two likely reasons that the STUN
being good if a NAT should fail and recover, resulting in loss of any transaction might have timed out. One reason is that the candidate
bindings it holds, or if an IP route should flap, causing those is simply unreachable. The other reason is that the peer is behind a
packets to be delivered through a new NAT that allocates new port restricted NAT, and so STUN requests from the client cannot get
bindings, or a firewall with different policies. The Retry Timer through until its peer creates a permission by generating its own
value SHOULD be configurable. In order to rapidly recover from STUN request. It may take some time to generate that STUN request,
failures, it is RECOMMENDED that it default to five seconds. [[TODO: as it may depend on a response message getting delivered. It is also
Need to work this number as a function of codec rates as well, possible that the STUN transaction timed out due to a persistent
perhaps apply the RTCP algorithm for its computation.]] network failure, in which case, a retry is in order. As such, the
HANDSHAKING state allows for rapid retry of the STUN transaction
If, from the INIT state, the STUN transaction times out, the FSM until enough time has passed to be certain that the remote transport
enters the HANDSHAKE state. At this point, there are two reasons address is actually unreachable. Thus, upon entering the HANDSHAKING
that the STUN request might have timed out. One reason is that the state, two timers are set. The first, called the Rapid Retry timer,
candidate is simply unreachable. The other reason is that the peer determines how long until the next attempt. This timer SHOULD be
is behind a port restricted NAT, and so STUN requests from the client configurable. It is RECOMMENDED that it default to 50ms. Note that
cannot get through until its peer creates a permission by generating this timer does not mean that a STUN request is repeated every 50ms.
its own STUN request. It may take some time to generate that STUN It means that a new STUN transaction begins 50ms after the completion
request, as it may depend on a response message getting delivered. of the previous one. STUN transactions themselves employ
As such, the HANDSHAKE state allows for rapid retry of the STUN exponentially back off retransmit timers. The second timer, called
transaction until enough time has passed to be certain that the the Giveup Timer, determines how long the client will keep trying
remote transport address is actually unreachable. Thus, upon until it decides that the remote transport address is unreachable.
entering the HANDSHAKE state, two timers are set. The first, called
the Rapid Retry timer, determines how long until the next attempt.
This timer SHOULD be configurable. It is RECOMMENDED that it default This timer SHOULD be configurable. It is RECOMMENDED that it default
to 1 second. The second timer, called the Giveup Timer, determines to 50 seconds. This is a reasonable approximation of the maximum SIP
how long the client will keep trying until it decides that the remote transaction duration.
transport address is unreachable. This timer SHOULD be configurable.
It is RECOMMENDED that it default to 50 seconds. This is a
reasonable approximation of the maximum SIP transaction duration.
If, from the INIT state, the STUN transaction generates an error, the
FSM moves into the BAD state. The retry timer is set. This retry
timer is used to periodically retry, and see if the candidate may now
be reachable. The value of this timer SHOULD be configurable. It is
RECOMMENDED that it default to 1 minute.
If, while in the HANDSHAKE state, the Giveup timer fires, or the STUN
transaction results in an error, the client moves into the BAD state,
and sets the retry timer. The default durations for ths timer are
identical for all entries into the BAD state, and thus it defaults to
1 minute here as well. If, while in the HANDSHAKE state, the Rapid
Retry timer fires, the timer is reset and the client remains in the
HANDSHAKE state.
If, while in the BAD state, the retried transaction is executed and If, from the INIT state the STUN transaction generates a race-failure
fails or results in a timeout, the client resets the timer and event, it means that the peer has not yet completed the initiate/
remains in the BAD state. If the STUN transaction succeeds, it moves accept exchange, and thus the username has not been allocated.
into the GOOD state and sets the refresh timer. The default Another BindingRequest transaction needs to take place to try again.
durations for this timer are the same for all entries into the GOOD Thus, the same retry and giveup timers as in the timeout event are
state, and thus it defaults to 1 second. started.
If while in the GOOD state, the transaction resulting from the If, from the INIT state, the STUN transaction generates an error, the
refresh timer times out or fails, the client moves into the BAD state FSM moves into the BAD state. This state means that the connection
and sets the retry timer. If, however, that transaction succeeds, is definitively unreachable, and it will not be used subsequently in
the client stays in the GOOD state and resets the refresh timer. the session.
As the FSM operates throughout the call, candidates will move their If, while in the HANDSHAKING state, the Giveup timer fires, or the
states around. At any point in time, the client sends media packets STUN transaction results in an error, the client moves into the BAD
(including RTCP) using one of the candidates in the GOOD state. It state. If, while in the HANDSHAKING state, the Rapid Retry timer
is RECOMMENDED that the one with highest priority be used. It fires, a new STUN transaction is started. The output of that
another candidate should change state such that it moves into the transaction will be subsequently fed into the FSM, but upon
GOOD state, and it has a higher priority, the client SHOULD switch to initiation of the retry attempt there is no change in state. If the
that candidate, but SHOULD do so after waiting a small period of time pending BindingRequest transaction succeeds, the FSM moves into the
(10 seconds is RECOMMENDED) to prevent against flapping of candidates GOOD state. This transport connection is viable for communications.
during periods of route flaps in the network.
To send media to a candidate, the client sends media packets (whether Once one of the connections in the connection table enters the GOOD
they are RTP or RTCP or something else) to the remote transport state, the client SHOULD begin using it for communications. It
address, from the sourceable transport address. SHOULD cease any ongoing transactions and terminate FSMs for
connections of lower priority. If, another connection of higher
priority should subsequently enter the GOOD state, the client SHOULD
switch to that one, and once more cease all ongoing transactions and
terminate FSMs for connections of lower priority. It SHOULD perform
this switch after waiting a small period of time (2 seconds is
RECOMMENDED) to prevent against quick changes in transport address as
each of the ongoing connectivity checks completes. If there are
multiple GOOD connections whose priorities are equal and higher than
any other GOOD connection, the client SHOULD pick one randomly and
use that. It SHOULD NOT change to another one of equal priority
later on. Each change in address is likely to cause a change in
transport characteristics, and manifest itself as a "glitch" to the
user.
If, for some reason, there was at least one candidate in the GOOD To send media on a connection, the client sends media packets
state, and due to an FSM transition, none of the candidates are in (whether they are RTP or RTCP or something else) to the remote
the GOOD state, the client SHOULD forcefully transition all of the transport address, from the local transport address.
candidates into the HANDSHAKE state in an attempt to rapidly
reconnect. If none of them succeed, and all of the candidates enter
the BAD state, the client SHOULD terminate the call and alert the
user to the failure [[TODO: Need to work in some good congestion
control here; in cases where timeouts happen due to network
congestion this is probably too agressive]].
5.3.5 Receiving STUN Requests 5.3.5 Receiving STUN Requests
When a client receives a STUN request (presumably after When a client receives a STUN request (presumably after
disambiguating it from a media packet), it follows the logic disambiguating it from a media packet), it follows the logic
described in this section. described in this section.
The client MUST follow the procedures defined in RFC 3489 and verify The client MUST follow the procedures defined in RFC 3489 and verify
that the USERNAME attribute is known to the server. Here, this is that the USERNAME attribute is known to the server. Here, this is
done by taking the USERNAME attribute, and doing a prefix match done by taking the USERNAME attribute, and doing a prefix match
against the "my user fragment" column in the candidate table. If it against the "local username fragment" column in the connection table.
doesn't match any rows, the client generates a 432 response. If it If it doesn't match any rows, the client generates a 400 response.
matches multiple rows, the client checks the suffix of the username If it matches one or more rows, the client checks the suffix of the
against the "user fragment" column. If it doesn't match any rows, username against the "remote username fragment" column in those
the client generates a 432 response. If it does match rows, it will matching rows. If the final result doesn't match any rows, the
match those rows corresponding to the transport addresses that the client generates a 430 response. If the final result matches a
peer could have sent this STUN request from. single row, that row identifies the connection on which the STUN
request was received. The client then proceeds with the processing
Assuming the USERNAME is valid, the client MUST generate a STUN of the request and generation of a response as per RFC 3489.
response per RFC 3489.
Once the response is sent, the client examines the source IP and port Once the response is sent, the client examines the source IP and port
where the request came from. It matches those against the remote where the request came from. It matches those against the remote
transport addresses in the candidate table. If there is no match, transport addresses of the matching connection from the previous
this source address is itself another possible candidate. As with paragraph. If they don't match, and that remote transport address is
other candidates, it must be associated with a STUN username not elsewhere in the table, this source transport address is itself
fragment, password and priority, all normally provided by the peer, another possible candidate. As with other candidates, it must be
along with sourceable transport addresses and their username associated with a STUN remote username fragment, remote password and
fragments. remote priority. These are obtained from the values of these columns
for the matching connection in the table. This candidate is then
paired with each local transport address, and the resulting set of
connections are added to the connection table and verified using STUN
connectivity checks as per Section 5.3.4.
How does the client obtain this other information? The suffix of the When will the source transport address of the BindingRequest not
USERNAME is the key (literally). That suffix was already provided to match an existing candidate remote transport address? This happens
the client in an initiate or accept message, and was used to populate when there is a NAT between the peers which is not on the path
the current candidate table. If it matches an existing value in the between each peer and the UNSAF servers.
table, it means that the STUN request came from the same transport
address as a previously advertised candidate; however, when it showed
up at the client, its source IP address was different than the peer
thought it would be. This will happen when a symmetric NAT exists
between the clients. In this case, the source IP address and port of
the STUN packet now become a viable candidate, since the client
should be able to send messages back to it and reach its peer.
However, this connectivity, like all other connectivity, needs to be 5.3.6 Management of Resources
verified. So, the client needs to find out the user fragment and
password to use in STUN requests. To do that, it takes the suffix of
the USERNAME in the STUN request, and looks it up in the "user frag"
column of the table. If its a match, that is the user fragment
needed as part of the candidate. The password is the value from that
row. The sourceable transport address is also the value from that
row. The priority is also copied from that row.
This new candidate can then be verified by sending STUN requests to The beginning of a multimedia session results in the creation of
it, as described in Section 5.3.4. several resources to support ICE. These include gathered addresses,
both local and derived, along with the local STUN servers that run on
the local addresses. These resources must be maintained and
eventually freed.
It is RECOMMENDED that all gathered addresses be retained for the
duration of the session. Even if they are not used initially, this
allows them to be used later in the session should conditions change,
requiring a signaling operation to update the set of candidate
addresses. Maintaining these resources depends on the type of
resource. For a local transport address, nothing is required. The
socket is maintained until freed by the ICE application. For STUN
derived transport addresses, the bindings in the NAT for that address
need to be maintained. If the derived transport address is used by
the peer for media, the media itself serves to keep the bindings
alive (see Section 5.3.7). A client can determine that a STUN
derived transport address was used for media when the RTP packet
arrives at the associated local transport address. For the other
STUN derived transport addresses, the client SHOULD periodically
generate STUN transactions to the STUN server. Every 20 seconds is
RECOMMENDED.
For TURN derived transport addresses, the bindings in the NAT along
with the mappings in the TURN server need to be maintained. Media
traffic itself can accomplish that. The client will know that its
TURN derived transport address is in use when an RTP packet arrives
at the associated local transport address. For other TURN derived
transport addresses, the TURN keepalive mechanisms SHOULD be used.
Once the STUN servers are started on the local transport addresses,
they MUST run until a valid media packet is detected on that
transport address. Once a media packet is received, it signals that
the peer has completed its connectivity checks and has decided to use
that transport address (or the derived transport address, as the case
may be) for media communications. While the server is running, it
MUST act as a normal STUN server, but MUST only accept STUN requests
from clients that authenticate, as discussed below in Section 5.3.5
5.3.7 Binding Keepalives
Once the STUN connectivity checks complete, STUN packets are no
longer used. However, bindings in intermediate NATs need to be kept
alive so that the media can continue to flow. Doing so is the
responsibility of the media protocol.
In the case of RTP, the RTP packets themselves normally come
sufficiently quickly to keep the bindings alive. However, several
cases merit further discussion. Firstly, in some RTP usages, such as
SIP, the media streams can be "put on hold". This is accomplished by
using the SDP "sendonly" or "inactive" attributes, as defined in RFC
3264 [4]. RFC 3264 directs implementations to cease transmission of
media in these cases. However, doing so may cause NAT bindings to
timeout, and media won't be able to come off hold.
As such, clients SHOULD instead send a media packet periodically,
independent of whether the stream is "sendonly", "recvonly" or
"inactive". At least once every 20 seconds is RECOMMENDED. These
packets can be sent using any of the payload formats listed by the
peer in its SDP. For audio streams, It is RECOMMENDED that
implementations support the RTP payload format for comfort noise [5],
which makes a good choice. For video codecs, a minimally coded frame
is a good choice.
Secondly, some RTP payload formats, such as the payload format for
text conversation [19], may send packets so infrequently that the
interval exceeds the NAT binding timeouts. In such cases, the
implementation should send some any kind of content, if possible. If
the payload type doesn't allow anything meaningful to be sent, even a
malformed RTP packet is superior to nothing at all; the malformed
packet would be rejected by the peer, and have the side effect of
keeping the NAT bindings open.
6. Running STUN on Derived Transport Addresses 6. Running STUN on Derived Transport Addresses
One of the seemingly bizarre operations done during the ICE One of the seemingly bizarre operations done during the ICE
processing is the transmission of a STUN request to a transport processing is the transmission of a STUN request to a transport
address which is obtained through TURN or STUN itself. This actually address which is obtained through TURN or STUN itself. This actually
does work, and in fact, has extremely useful properties. The does work, and in fact, has extremely useful properties. The
subsections below go through the detailed operations that would occur subsections below go through the detailed operations that would occur
at each point to demonstrate correctness and the properties derived at each point to demonstrate correctness and the properties derived
from it. from it. They are tutorial in nature.
6.1 STUN on a TURN Derived Transport Address 6.1 STUN on a TURN Derived Transport Address
Consider a client A that is behind a NAT. It connects to a TURN +----------+
server on the public side of the NAT. To do that, A binds to a local | |192.0.2.1:26524
transport address, say 10.0.1.1:8866, and then sends a TURN request | TURN X
to the TURN server. The NAT translates the net-10 address to | Server |
192.0.2.88:5063. Assume that the TURN server is running on 192.0.2.1 | |
and listening for TURN traffic on port 7764. The TURN server | |
allocates a derived transport address 192.0.2.1:26524 to the client, +----------+
and returns it in the TURN response. Remember that all traffic from 192.0.2.1:7764. ^192.0.2.1:7764
the TURN server to the client is sent from 192.0.2.1:7764 to . .
10.0.1.1:8866. . .192.0.2.88:5063
+----------+
| NAT |
+----------+
TURN . .
Response . . TURN Request
. .
10.0.1.1:8866 V .10.0.1.1:8866
+----------+ +----------+
| | | |
| Client | | Client |
| | | |
| A | | B |
| | | |
+----------+ +----------+
Figure 6
Consider a client A that is behind a NAT, shown in Figure 6. It
connects to a TURN server on the public side of the NAT. To do that,
A binds to a local transport address, say 10.0.1.1:8866, and then
sends a TURN request to the TURN server. The NAT translates the
net-10 address to 192.0.2.88:5063. Assume that the TURN server is
running on 192.0.2.1 and listening for TURN traffic on port 7764.
The TURN server allocates a derived transport address 192.0.2.1:26524
to the client (shown as the X on the TURN server in the diagram), and
returns it in the TURN response. Remember that all traffic from the
TURN server to the client is sent from 192.0.2.1:7764 to
10.0.1.1:8866, including the TURN response.
Now, the client runs a STUN server on 10.0.1.1:8866, and advertises Now, the client runs a STUN server on 10.0.1.1:8866, and advertises
that its server actually runs on 192.0.2.1:26524. Another client, B, that its server actually runs on 192.0.2.1:26524. Another client, B,
sends a STUN request to this server. It sends it from a local sends a STUN request to this server. It sends it from a local
transport address, 192.0.2.77:1296. When it arrives at transport address, 192.0.2.77:1296. When it arrives at
192.0.2.1:26524, the TURN server "locks down" outgoing traffic, so 192.0.2.1:26524, it is discarded since client A has not sent a packet
that data packets received from A are sent to 192.0.2.77:1296. The to 192.0.2.77:1296. Once client A gets client B's accept message, it
STUN request is then forwarded to the client, sent with a source will learn about B's candidate address, and generate a STUN request
address of 192.0.2.1:7764 and a destination address of towards it. This results in a permission being installed in the TURN
192.0.2.88:5063. This passes through the NAT, which rewrites the server, so that packets from 192.0.2.77:1296 will now be accepted.
source address to 10.0.1.1:8866. This arrives at A's STUN server. The next STUN request from client B will therefore succeed. This is
The server observes the source address of 192.0.2.1:7764, and the normal mode of operations for port restricted NAT; as described
generates a STUN response containing this value in the MAPPED-ADDRESS in TURN, the server turns a symmetric NAT into a port restricted one
attribute. The STUN response is sent with a source address fo [8].
10.0.1.1:8866, and a destination of 192.0.2.1:7764. This arrives at
the TURN server, which, because of the lock-down, sends the STUN
response with a source address of 192.0.2.1:26524 and destination of
192.0.2.77:1296, which is B's STUN client.
Now, as far as B is concerned, it has obtained a new STUN derived +----------+
| |192.0.2.1:26524 STUN Request
| TURN X<...............................
| Server | STUN Response .
| |......................... .
| |192.0.2.1:26524 . .
+----------+ . .
192.0.2.1:7764 . ^ 192.0.2.1:7764 . .
. . . .
192.0.2.88:5063 V . 192.0.2.88:5063 . .
+----------+ . .
| NAT | . .
+----------+ . .
192.0.2.1:7764 . ^ 192.0.2.1:7764 . .
. . 192.0.2.77:1296 .
. . . .
10.0.1.1:8866 V . 10.0.1.1:8866 V .192.0.2.77:1296
+----------+ +----------+
| | | |
| Client | | Client |
| | | |
| A | | B |
| | | |
+----------+ +----------+
Figure 7
As shown in Figure 7, client B will retry, sending it STUN request
from 192.0.2.77:1296 to 192.0.2.1:26524. This successful STUN
request is forwarded to the client, sent with a source address of
192.0.2.1:7764 and a destination address of 192.0.2.88:5063. This
passes through the NAT, which rewrites the destination address to
10.0.1.1:8866. This arrives at A's STUN server. The server observes
the source address of 192.0.2.1:7764, and generates a STUN response
containing this value in the MAPPED-ADDRESS attribute. The STUN
response is sent with a source address of 10.0.1.1:8866, and a
destination of 192.0.2.1:7764. This arrives at the TURN server,
which, because of current destination is 192.0.2.1:7764, sends the
STUN response with a source address of 192.0.2.1:26524 and
destination of 192.0.2.77:1296, which is B's STUN client.
Now, as far as A is concerned, it has obtained a new candidate
transport address of 192.0.2.1:7764. And indeed, it has! STUN transport address of 192.0.2.1:7764. And indeed, it has! STUN
derived transport addresses are scoped to the session, so they can derived transport addresses are scoped to the session, so they can
only be used by the peer in the session. Furthermore, that peer has only be used by the peer in the session. Furthermore, that peer has
to send requests from the socket on which the STUN server was to send requests from the socket on which the STUN server was
running. In this case, A is the peer, and its STUN server was on running. In this case, A is the peer, and its STUN server was on
10.0.1.1:8866. If it sends to 192.0.2.1:7764, the packet goes to the 10.0.1.1:8866. If it sends to 192.0.2.1:7764, the packet goes to the
TURN server, and due to lock-down, is forwarded to B, and TURN server, and since the destination address is set to
specifically, is forwarded to the transport address B sent the STUN 192.0.2.77:1296, is forwarded to B, and specifically, is forwarded to
request from. Therefore, the address is indeed a valid STUN derived the transport address B sent the STUN request from. Therefore, the
transport address. address is indeed a valid candidate transport address. Its priority
is derived from the priority of client B's public IP address.
The benefit of this is that it allows two clients to share the same The benefit of this is that it allows two clients to share the same
TURN server for media traffic in both directions. With "normal" TURN TURN server for media traffic in both directions. With "normal" TURN
usage, both clients would obtain a derived address from their own usage, both clients would obtain a derived address from their own
TURN servers. The result is that, for a single call, there are two TURN servers. The result is that, for a single call, there are two
bindings allocated by each side from their respective servers, and bindings allocated by each side from their respective servers, and
all four are used. With ICE, that drops to two bindings allocated all four are used. With ICE, that drops to two bindings allocated
from a single server. Of course, all four bindings are allocated from a single server. Of course, all four bindings are allocated
initially. However, once one of the clients begins receiving media initially. However, once one of the clients begins receiving media
on its STUN derived address, it can deallocate its TURN resources. on its STUN derived address, it can deallocate its TURN resources.
[[TODO: Include a diagram that shows this pictorially.]]
6.2 STUN on a STUN Derived Transport Address 6.2 STUN on a STUN Derived Transport Address
Consider a client A that is behind a NAT. It connects to a STUN Consider a client A that is behind a NAT. It connects to a STUN
server on the public side of the NAT. To do that, A binds to a local server on the public side of the NAT. To do that, A binds to a local
transport address, say 10.0.1.1:8866, and then sends a STUN request transport address, say 10.0.1.1:8866, and then sends a STUN request
to the STUN server. The NAT translates the net-10 address to to the STUN server. The NAT translates the net-10 address to
192.0.2.88:5063. Assume that the STUN server is running on 192.0.2.1 192.0.2.88:5063. Assume that the STUN server is running on 192.0.2.1
and listening for STUN traffic on port 3478, the default STUN port. and listening for STUN traffic on port 3478, the default STUN port.
The STUN server sees a source IP address of 192.0.2.88:5063, and The STUN server sees a source IP address of 192.0.2.88:5063, and
returns that to the client in the STUN response. The NAT forwards returns that to the client in the STUN response. The NAT forwards
the response to the client. the response to the client.
Now, the client runs a STUN server on 10.0.1.1:8866, and advertises Now, the client runs a STUN server on 10.0.1.1:8866, and advertises
that its server actually runs on 192.0.2.88:5063. Another client, B, that its transport address is 192.0.2.88:5063. Another client, B,
sends a STUN request to this address. It sends it from a local sends a STUN request to this address. It sends it from a local
transport address, 192.0.2.77:1296. When it arrives at transport address, 192.0.2.77:1296. When it arrives at
192.0.2.88:5063 (on the NAT), the NAT rewrites the source address to 192.0.2.88:5063 (on the NAT), the NAT rewrites the source address to
10.0.1.1:8866, assuming that it is of the full-cone variety [1], or 10.0.1.1:8866, assuming that it is of the full-cone or restricted
is restricted, and the permission for 192.0.2.77:1296 is open. This variety [1], and the permission for 192.0.2.77:1296 is open. This
arrives at A's STUN server. The server observes the source address arrives at A's local STUN server. The server observes the source
of 192.0.2.77:1296, and generates a STUN response containing this address of 192.0.2.77:1296, and generates a STUN response containing
value in the MAPPED-ADDRESS attribute. The STUN response is sent this value in the MAPPED-ADDRESS attribute. The STUN response is
with a source address of 10.0.1.1:8866, and a destination of sent with a source address of 10.0.1.1:8866, and a destination of
192.0.2.77:1296. This arrives at B's STUN client. 192.0.2.77:1296. This arrives at B's STUN client.
Now, as far as B is concerned, it has obtained a new STUN derived Now, as far as A is concerned, the STUN request had a source
transport address of 192.0.2.77:1296. Of course, this is the same transport address which was already known to A, presumably from an
address as the local transport address, and therefore this derived ICE exchange. As far as B is concerned, the check succeeded, and the
address is not used. However, had there been additonal NATs between address is viable.
B and A's NAT, B would end up seeing the binding allocated by that
outermost NAT. The net result is that STUN requests sent to a STUN
derived address behave as normal STUN would. However, these STUN
requests have the side-effect of creating permissions in the NATs
which see those requests in the public to private direction. This
turns out to be very useful for traversing restricted NATs.
7. XML Schema for ICE Messages 7. XML Schema for ICE Messages
This section contains the XML schema used to define the initiate, This section contains the XML schema used to define the initiate and
accept, and modify messages. Any protocol that uses ICE needs to map accept messages. Any protocol that uses ICE needs to map the
the parameters defined here into its own messages. parameters defined here into its own messages.
Note that STUN allows both the username and password to contain the Note that STUN allows both the username and password to contain the
space character. However, usernames and passwords used with ICE space character. However, usernames and passwords used with ICE
cannot contain the space. cannot contain the space.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:ice" <xs:schema targetNamespace="urn:ietf:params:xml:ns:ice"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="urn:ietf:params:xml:ns:ice" xmlns:tns="urn:ietf:params:xml:ns:ice"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified"> elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace" <xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/> schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:element name="message" type="tns:message"/> <xs:element name="message" type="tns:message"/>
<xs:complexType name="message"> <xs:complexType name="message">
<xs:annotation> <xs:annotation>
<xs:documentation>This is the root element, which holds a <xs:documentation>This is the root element, which holds a
media-streams elements.</xs:documentation> media-streams elements.</xs:documentation>
</xs:annotation> </xs:annotation>
<xs:sequence> <xs:sequence>
skipping to change at page 26, line 43 skipping to change at page 29, line 50
<xs:complexType name="media-streams"> <xs:complexType name="media-streams">
<xs:sequence> <xs:sequence>
<xs:element name="media-stream" minOccurs="0" maxOccurs="unbounded"> <xs:element name="media-stream" minOccurs="0" maxOccurs="unbounded">
<xs:annotation> <xs:annotation>
<xs:documentation>There are zero or more media stream <xs:documentation>There are zero or more media stream
elements. Each defines attributes for a specific media elements. Each defines attributes for a specific media
stream.</xs:documentation> stream.</xs:documentation>
</xs:annotation> </xs:annotation>
<xs:complexType> <xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name="default-address"> <xs:element name="default-addresses">
<xs:annotation>
<xs:documentation>The default address is used for
sending media before connectivity has been
verified.</xs:documentation>
</xs:annotation>
<xs:complexType> <xs:complexType>
<xs:complexContent> <xs:sequence>
<xs:extension base="tns:rtp-info"/> <xs:element name="ipv4-address" type="tns:rtp-info" minOccurs="0"/>
</xs:complexContent> <xs:element name="ipv6-address" type="tns:rtp-info" minOccurs="0"/>
</xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:sequence> <xs:sequence>
<xs:element name="alternate" minOccurs="0" maxOccurs="unbounded"> <xs:element name="candidate" minOccurs="0" maxOccurs="unbounded">
<xs:annotation> <xs:annotation>
<xs:documentation>Each alternate is a <xs:documentation>Each candidate is a possible point
possible point of contact. of media reception.</xs:documentation>
</xs:documentation>
</xs:annotation> </xs:annotation>
<xs:complexType> <xs:complexType>
<xs:complexContent> <xs:complexContent>
<xs:extension base="tns:transport-data"> <xs:extension base="tns:transport-data">
<xs:attribute name="preference" type="xs:double" use="required"/> <xs:attribute name="preference" type="xs:double" use="required"/>
<xs:attribute name="id" type="xs:string" use="required"/> <xs:attribute name="id" type="xs:string" use="required"/>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
skipping to change at page 27, line 38 skipping to change at page 30, line 41
</xs:complexType> </xs:complexType>
<xs:simpleType name="msg-type"> <xs:simpleType name="msg-type">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="initiate"/> <xs:enumeration value="initiate"/>
<xs:enumeration value="accept"/> <xs:enumeration value="accept"/>
<xs:enumeration value="modify"/> <xs:enumeration value="modify"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:complexType name="transport-data"> <xs:complexType name="transport-data">
<xs:sequence> <xs:sequence>
<xs:element name="stun-user-fragment" type="xs:string"/>
<xs:element name="stun-password" type="xs:string"/>
<xs:element name="rtp-address" type="tns:transport-address"/> <xs:element name="rtp-address" type="tns:transport-address"/>
<xs:element name="rtcp-address" type="tns:transport-address"/> <xs:element name="rtcp-address" type="tns:transport-address" minOccurs="0"/>
<xs:element name="rtp-stun-info" type="tns:stun-info"/>
<xs:element name="rtcp-stun-info" type="tns:stun-info" minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<xs:complexType name="transport-address"> <xs:complexType name="transport-address">
<xs:sequence> <xs:sequence>
<xs:element name="ip-address" type="xs:string"/> <xs:element name="ip-address" type="xs:string"/>
<xs:element name="port"> <xs:element name="port">
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:integer"> <xs:restriction base="xs:integer">
<xs:minInclusive value="1"/> <xs:minInclusive value="1"/>
<xs:maxInclusive value="65535"/> <xs:maxInclusive value="65535"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:element> </xs:element>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<xs:complexType name="stun-info">
<xs:sequence>
<xs:element name="username-fragment"/>
<xs:element name="password"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="rtp-info"> <xs:complexType name="rtp-info">
<xs:sequence> <xs:sequence>
<xs:element name="rtp-address" type="tns:transport-address"/> <xs:element name="rtp-address" type="tns:transport-address"/>
<xs:element name="rtcp-address" type="tns:transport-address"/> <xs:element name="rtcp-address" type="tns:transport-address"
minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:schema> </xs:schema>
8. Examples 8. Example
In the examples that follow, messages are labeled with "message name In the example that follows, messages are labeled with "message name
A,B" to mean a message from transport address A to B. For STUN A,B" to mean a message from transport address A to B. For STUN
Requests, this is followed by curly brackets enclosing the username Requests, this is followed by curly brackets enclosing the username
and password. For STUN responses, this is followed by square and password. For STUN responses, this is followed by square
brackets and the value of MAPPED ADDRESS. brackets and the value of MAPPED ADDRESS. The example shows a flow
of two clients where one is behind a full cone NAT, and the other is
on the public Internet.
8.1 Port Restricted A NAT STUN B
|(1) STUN Req P1,STUN-PUBLIC | |
|---------------->| | |
| |(2) STUN Req U, STUN-PUBLIC |
| |---------------->| |
| |(3) STUN Res STUN-PUBLIC, U [U] |
| |<----------------| |
|(4) STUN Res STUN-PUBLIC, P1 [U] | |
|<----------------| | |
|(5) Intitiate {P2,ufrag1A,pass1A,q=0.4} |
|{U,ufrag2A,pass2A,q=0.4} | |
|---------------------------------------------------->|
| | |(6) STUN Req P3,STUN-PUBLIC
| | |<----------------|
| | |(7) STUN Res STUN-PUBLIC,P3 [P3]
| | |---------------->|
|(8) Accept {P3,ufrag1B,pass1B,q=0.4} |
|<----------------------------------------------------|
| |(9) STUN Req P3,P2 |
| |(ufrag1Aufrag1B,pass1A) |
| |<----------------------------------|
| |Timeout | |
| |(10) STUN Req P3,U |
| |(ufrag2Aufrag1B,pass2A) |
| |<----------------------------------|
|(11) STUN Req P3,P1 | |
|(ufrag2Aufrag1B,pass2A) | |
|<----------------| | |
|(12) STUN Res P1,P3 [P3] | |
|---------------->| | |
| |(13) STUN Res U,P3 [P3] |
| |---------------------------------->|
|(14) STUN Req P2,P3 | |
|(ufrag1Bufrag1A,pass1B) | |
|---------------->| | |
| |(15) STUN Req W,P3 |
| |(ufrag1Bufrag1A,pass1B) |
| |---------------------------------->|
| |(16) STUN Res P3,W [W] |
| |<----------------------------------|
|(17) STUN Res P3,P2 [W] | |
|<----------------| | |
|(18) STUN Req P1,P3 | |
|(ufrag1Bufrag2A,pass1B) | |
|---------------->| | |
| |(19) STUN Req U,P3 |
| |(ufrag1Bufrag2A,pass1B) |
| |---------------------------------->|
| |(20) STUN Res P3,U [U] |
| |<----------------------------------|
|(21) STUN Res P3,P1 [U] | |
|<----------------| | |
This section shows a flow of two clients behind port restricted NAT The initiator, client A, binds to a local transport address P1, which
talking to each other. will be used as an associated local transport address. As such, it
sends a STUN request to its STUN server (message 1). This passes
through a NAT, and the NAT maps private address P1 to public address
U (message 2). The STUN server mirrors this public address in the
MAPPED-ADDRESS of the STUN response (message 3), and it is forwarded
to the initiator (message 4). Now, client A has a STUN derived
transport address of U. It also binds to a second local transport
address, P2, which will be a usable local transport address. It
starts STUN servers on both local transport addresses P1 and P2. It
then generates an Initiate request to client B (message 5) which
contains both of the gathered transport addresses P2 and U, along
with username fragments and passwords.
A P.R. NAT STUN+TURN P.R. NAT B Client B is not behind a NAT. It binds to a local transport address
|(1) STUN Req P1,S+T | | | P3, and sends a STUN request to its STUN server (message 6). This is
|----------->| | | | responded to by the STUN server (message 7). The client observes
| |(2) STUN Req U, S+T | | that this address is identical to its local transport address, and
| |----------->| | | therefore that local transport address is, which was targeted for an
| |(3) STUN Res S+T,U [U] | | associated local transport address, is promoted to a usable local
| |<-----------| | | transport address. It then sends an Accept message to client A,
|(4) STUN Res S+T,P1 [U] | | | including this transport address and its username fragment and
|<-----------| | | | password (message 8).
|(5) Intitiate {P1,unameA,passA,q=0.4} | |
|{U,unameA,passA,q=0.3} | | | Once the Accept message is sent, the client can perform its STUN
|-------------------------------------------------->| connectivity checks. B has a single local transport address (P3),
| | | |(6) STUN Req P2,S+T which it matches up with A's two remote transport addresses (P2 and
| | | |<-----------| U). B tries P2 (message 9). This request fails since P2 is a
| | |(7) STUN Req V, S+T | private address. In parallel, B tries U (message 10). Since A's NAT
| | |<-----------| | is full cone, this packet is accepted and is passed to client A
| | |(8) STUN Res S+T,V [V] | (message 11). Client A generates a response (message 12) which is
| | |----------->| | forwarded to client B (message 13). The source transport address in
| | | |(9) STUN Res S+T,P2 [V] the STUN packet, P3, is already known to client A, and thus no new
| | | |----------->| candidates are learned. Client B learns that client A is reachable
|(10) Accept {P2,unameB,passB,q=0.4} | | at transport address U, but not P3. Thus, it can begin sending media
|{V,unameB,passB,q=0.3} | | | to U from local transport address P3.
|<--------------------------------------------------|
|(11) STUN Req P1,P2 | | | Once the Accept message arrives at client A, it can begin its
|(unameBunameA,passB) | | | connectivity checks. It has two local transport addresses P1 and P2,
|----------->| | | | which it combines with client Bs single transport address P3. It
| |Timeout | | | tries to send a STUN packet from P2 to P3 (message 14). Since the
|(12) STUN Req P1,V | | | NAT has not seen source address P2 yet, it maps it to a new public
|(unameBunameA,passB) | | | transport address W, and the STUN request is forwarded to client B
|----------->| | | | (message 15). Client B generates a STUN response (message 16), which
| |(13) STUN Req U,V | | is forwarded back to client A (message 17). Based on this, client A
| |(unameBunameA,passB) | | learns that it can reach P3 from P2. Client B learns a new remote
| |------------------------>| | transport address, W. However, the priority of this address is the
| |Permission open V->U | | same as P2, which is 0.4, and equal to the priority of address U, to
| | | |No success, Retries continue which client B has already connected. Thus, it does not bother to
| | | |(14) STUN Req P2,P1 perform the check (such a check would have succeeded if it had been
| | | |(unameAunameB,passA) done).
| | | |<-----------|
| | | |Timeout | While the P2->P3 check is taking place, client A also sends a STUN
| | | |(15) STUN Req P2,U request from P1 to P3 (message 18). This passes through the NAT,
| | | |(unameAunameB,passA) which maps the source transport address to the same public address it
| | | |<-----------| allocated previously, U. This STUN request arrives at client B
| |(16) STUN Req V,U | | (message 19). It generates a response (message 20), which is
| |(unameAunameB,passA) | | forwarded to client A (message 21). Based on this check, client A
| |<------------------------| | learns that P3 is also reachable from P1. Client B did not learn a
| | | |Permission open U->V new candidate transport address, since U was already known. Now,
| |Passes NAT! | | | client A can send media to P3 from either P1 or P2.
|(17) STUN Req V,P1 | | |
|(unameAunameB,passA) | | |
|<-----------| | | |
|(18) STUN Res P1,V [V] | | |
|----------->| | | |
| |(19) STUN Res U,V [V] | |
| |------------------------>| |
| | | |(20) STUN Res U,P2 [V]
| | | |----------->|
| |Retries continue | |
|(21) STUN Req P1,V | | |
|(unameBunameA,passB) | | |
|----------->| | | |
| |(22) STUN Req U,V | |
| |(unameBunameA,passB) | |
| |------------------------>| |
| | | |Passes NAT! |
| | | |(23) STUN Req U,P2
| | | |(unameBunameA,passB)
| | | |----------->|
| | | |(24) STUN Res P2,U [U]
| | | |<-----------|
| |(25) STUN Res V,U [U] | |
| |<------------------------| |
|(26) STUN Res V,P1 [U] | | |
|<-----------| | | |
|(27) RTP P1,V | | |
|----------->| | | |
| |(28) RTP U,V| | |
| |------------------------>| |
| | | |Passes NAT! |
| | | |(29) RTP U,P2
| | | |----------->|
| | | |(30) RTP P2,U
| | | |<-----------|
| |(31) RTP V,U| | |
| |<------------------------| |
| |Passes NAT! | | |
|(32) RTP V,P1 | | |
|<-----------| | | |
9. Mapping ICE into SIP 9. Mapping ICE into SIP
In this section, we show how to map ICE into SIP. This requires In this section, we show how to map ICE into SIP. This mapping
extensions to SDP. involves three parts. The first is the actual mapping of the ICE
message into SIP and SDP messages, which requires extensions to SDP
documented here. The second are security considerations specific to
SIP. The third is handling of updates in the offer/answer model.
A new SDP attribute is defined to support ICE. It is called "alt". 9.1 Message Mapping
The alt attribute MUST be present within a media block of the SDP.
It contains an alternative IP address and port (or pair of IP A new SDP attribute is defined to support ICE. It is called
addresses and ports in the case of RTP) that the recipient of the SDP "candidate". The candidate attribute MUST be present within a media
can use instead of the ones indicated in the m and c lines. There block of the SDP. It contains a candidate IP address and port (or
MAY be multiple alt attributes in a media block. In that case, each pair of IP addresses and ports in the case of RTP) that the recipient
of them MUST contain a different IP address and port (or a differing of the SDP can use. There MAY be multiple candidate attributes in a
pair of IP address and ports in the case of RTP). media block. In that case, each of them MUST contain a different IP
address and port (or a differing pair of IP address and ports in the
case of RTP).
The syntax of this attribute is: The syntax of this attribute is:
alt-attribute = "alt" ":" id SP qvalue SP candidate-attribute = "candidate" ":" id SP qvalue SP
username SP password SP rtp-user-frag SP rtp-password SP
unicast-address SP port [unicast-address SP port] rtp-unicast-address SP rtp-port [SP rtcp-user-frag
SP rtcp-password [SP rtcp-unicast-address SP
rtcp-port]]
;qvalue from RFC 3261 ;qvalue from RFC 3261
rtp-port = port
rtcp-port = port
rtp-unicast-address = unicast-address
rtcp-unicast-address = unicast-address
;unicast-address, port from RFC 2327 ;unicast-address, port from RFC 2327
username = non-ws-string rtp-user-frag = non-ws-string
password = non-ws-string rtp-password = non-ws-string
rtcp-user-frag = non-ws-string
rtcp-password = non-ws-string
id = token id = token
derived-from = ":" / id
With the addition of the alt attribute, the mapping of the ICE With the addition of the candidate attribute, the mapping of the ICE
messages to SIP/SDP is straightforward. The ICE initiate message messages to SIP/SDP is straightforward. The ICE initiate message
corresponds to a SIP message with an SDP offer. The ICE accept corresponds to a SIP message with an SDP offer. The ICE accept
message corresponds to a SIP message with a SDP answer. The ICE message corresponds to a SIP message with a SDP answer.
modify message corresponds to a SIP INVITE or UPDATE with an offer,
and the ICE modify accept message corresponds to an INVITE or UPDATE
response with an answer.
Each media stream element in an ICE message maps to a media block in Each media stream element in an ICE message maps to either one or two
the SDP. The default address maps to the m and c lines in the SDP. media blocks in the SDP. If the ICE message has only an IPv4 default
If the ICE message indicates an RTCP address and port that are not address or an IPv6 default address, but not both, one media block is
one higher than that of the RTP, the SDP RTCP attribute [2] MUST be used. If both defaults are present, two media blocks are used. Each
used to convey them. default address maps to the m and c lines in the SDP media block. In
particular, the <ip-address> from the <rtp-address> element maps into
the SDP c line. The <port> from the <rtp-address> maps into the port
in the SDP m line. If the ICE message indicates a default RTCP
address whose IP address is not identical to the default RTP address,
and whose port is not one higher than that of the RTP, the SDP RTCP
attribute [2] MUST be used to convey the RTCP transport address.
Each alternate element in an ICE message maps either to an alt Each <candidate> element in an ICE message maps to a candidate
attribute in the SDP, or a new media block, depending on the IP attribute in the SDP. If the IP version of the <candidate> is IPv4,
version of the alternate. For the highest priority IPv6 alternate, it MUST be mapped into the media block containing the default IPv4
it is mapped into a separate media block, using the ANAT grouping address. If the IP version of the <candidate> is IPv6, it MUST be
[4]. Any additional IPv6 addresses are placed as alternates within mapped into the media block containing the default IPv6 address.
this media block. For alternates that are IPv4 addresses, the alt Mapping of each individual candidate is simple. The
attribute is used. The rtp-address element maps to the first <username-fragment> element of the <rtp-stun-info> element maps to
unicast-address and port components of the alt attribute. The the rtp-user-frag component of the candidate attribute. The
rtcp-address element maps to the second unicast-address and port <password> element of the <rtp-stun-info> element maps to the
components of the alt attribute. Note that, if the RTCP address is rtp-password component of the candidate attribute. The <rtp-address>
identical to the RTP address, and the port is one higher, the second element maps to the first unicast-address and port components of the
unicast-address and port MAY be omitted. The preference value from candidate attribute.
the alternate element is mapped to the q-value component of the alt
attribute. The STUN user fragment and password elements map to the If the <rtcp-stun-info> element is present, it means that RTCP is in
user fragment and password components of the alt attribute. use. The rtcp-user-frag and rtcp-password components of the
candidate attribute MUST be present, and MUST be set to the
<username-fragment> and <password> elements of the <rtcp-stun-info>
element, respectively. If the <rtcp-address> element is also
present, its IP address and port information is copied into the
rtcp-unicast-address and rtcp-port components of the candidate
attribute.
The preference attribute from the <candidate> element is mapped to
the q-value component of the candidate attribute. The id attribute
from the <candidate> element is mapped into the id component of the
candidate attribute.
If the mapping process produced both an IPv6 media block (that is, a
media block with an IPv6 address in the c line, and with all IPv6
addresses in the candidate attributes within that block) and an IPv4
media block, these two blocks MUST be grouped using the ANAT grouping
[7].
9.2 SIP and SDP Specific Security Considerations
The SDP messages described here contain usernames and passwords. If
those passwords are transmitted in the clear, it introduces
significant security vulnerabilities, discussed in detail below. In
summary, those vulnerabilities would allow an eavesdropper that can
inject packets, to "steal" the media streams for a call unless secure
media transport (such as SRTP) is used. Even if SRTP is used, an
attacker could disrupt a call and prevent media from flowing. These
attacks, fortunately, can be obviated by providing secure transport
of the SDP. SIP-based implementations of ICE SHOULD use the sips URI
scheme when transporting SDP with ICE information, and MAY use S/MIME
[3].
9.3 Updates in the Offer/Answer Model
ICE itself only considers an initial exchange of messages. However,
the offer/answer model [4] allows for the session to be modified with
subsequent exchanges. How is an updated offer with SDP alternate
attributes to be treated?
If a user agent receives an updated offer with candidate attributes,
it checks to see if it already knows about those candidates. This is
done by comparing the transport address and username fragment with
existing values. If the combination is already known, no additional
action is taken. In particular, if STUN connectivity checks had
already been made, no new ones are performed. However, if a
candidate contains a new transport address or new username fragment,
it is treated as a totally new candidate, and STUN connectivity
checks are performed per Section 5.3.4. If a candidate formerly sent
by the peer no longer appears, that candidate is considered BAD, and
if it was in use previously, it ceases being used, and the next
highest priority connection in the GOOD state is used.
The inclusion of the username fragment in the determination of
whether a candidate is known provides a hook that allows a peer to
request a new set of connectivity checks on an existing transport
address. It can update the username fragment and generate an updated
offer, without changing the transport address.
10. Security Considerations 10. Security Considerations
ICE conveys the STUN username and password within its messages. If STUN itself introduces many security considerations. In particular,
an eavesdropper should see the username and password, the worst they there are attacks whereby an eavesdropper replays STUN packets with a
can do is send STUN requests to the host. Since STUN is a stateless modified source address. These modified packets can cause service
protocol, the attacker can not alter the processing of the call or disruptions and denial-of-service attacks, which are only partially
otherwise disrupt it. They could flood the server with mitigated by the heuristics described in STUN [1].
BindingRequest packets. However, this would be no worse than if the
attacker simply floods the host with any kind of packet.
However, integrity protection of the username and password are more Interestingly, when STUN is used within ICE, these security
important. If an attacker is capable of intercepting the message and weaknesses are mitigated completely, without the need for the
modifying the username or password, they could prevent connectivity heuristics defined in RFC 3489.
from being established between peers, and therefore disrupt the call.
Of course, if the attacker can intercept the message, there are many Consider an attacker that intercepts a STUN packet used for
other ways in which they could do that, such as simply discarding the connectivity checks, and replays it using a faked source address. If
message. Injecting fake messages with incorect usernames and successful, this would fool an endpoint into thinking that this faked
passwords can also disrupt a call, and does not require the source address was a valid destination for media (recall that the
compromise of an intermediate server. A similar attack is possible source transport address of received STUN packets is used as a
by modifying most of the ICE message attributes. To prevent these potential candidate address). However, the recipient of the replayed
kinds of attacks, it is RECOMMENDED that the actual protocols the ICE packet will not just send media to that candidate. It will verify it
maps to make use of security mechanisms that provide message with a STUN connectivity check. This check will be sent to that
integrity protection. faked source address, and if there is no response, the address will
not be used. The attacker cannot answer the STUN request without
access to the username and password, which are exchanged as part of
the signaling. Thus, if the signaling is protected as recommended
above, the attacker cannot obtain the username or password.
If an attacker instead intercepts and replays STUN packets used for
the purposes of unilateral allocation, a similar result occurs. The
target of the attack will be fooled into thinking it has a STUN
derived transport address that it does not. Its peer will perform a
connectivity check to this address, which will fail. The attacker
cannot force this check to succeed without access to the username and
password, which are protected. Thus, this address will not be used.
In the worst case, an attacker can generate enough traffic so that
none of the valid STUN checks or unilateral allocations succeed.
This would result in a service disruption. However, this attack is
no worse than any pure packet flood disruption attack launched
against any other protocol. These attacks cannot be prevented by any
protocol means.
If an attacker could intercept and modify the contents of the
Initiate or Accept messages, they could disrupt the session, divert
the media, and otherwise take control over the session. This attack
is prevented by encryption, authentication and message integrity of
the signaling channel used for ICE.
11. IANA Considerations 11. IANA Considerations
This specification defines one new media attribute: alt. Its syntax 11.1 SDP Attribute Name
is defined in Section 9.
This specification defines one new SDP attribute per the procedures
of Appendix B of RFC 2327. The required information for the
registration is:
Contact Name: Jonathan Rosenberg, jdrosen@jdrosen.net.
Attribute Name: candidate
Long Form: candidiate
Type of Attribute: media level
Charset Considerations: The attribute is not subject the the charset
attribute.
Purpose: This attribute is used with Interactive Connectivity
Establishment (ICE), and provides one of many possible candidate
addresses for communication. These addresses are validated with
an end-to-end connectivity check using Simple Traversal of UDP
with NAT (STUN).
Appropriate Values: See Section 9 of RFC XXXX [Note to RFC-ed: please
replace XXXX with the RFC number of this specification].
11.2 URN Sub-Namespace Registration
This section registers a new XML namespace, per the guidelines in [6]
URI: The URI for this namespace is urn:ietf:params:xml:ns:ice.
Registrant Contact: IETF, MMUSIC working group, (mmusic@ietf.org),
Jonathan Rosenberg (jdrosen@jdrosen.net).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>ICE Namespace</title>
</head>
<body>
<h1>Namespace for ICE Documents</h1>
<h2>urn:ietf:params:xml:ns:ice</h2>
<p>See <a href="[URL of published
RFC]">RFCXXXX</a>. [Note to RFC-ed: please replace XXXX with the RFC
number of this specification.]</p>
</body>
</html>
END
11.3 XML Schema Registration
This section registers an XML schema per the procedures in [6].
URI: urn:ietf:params:xml:schema:ice
Registrant Contact: IETF, MMUSIC working group, (mmusic@ietf.org),
Jonathan Rosenberg (jdrosen@jdrosen.net).
The XML for this schema can be found as the sole content of
Section 7.
12. IAB Considerations 12. 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 client attempts to determine which is the general process by which a client 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 [11]. ICE is an example collaborative protocol reflection mechanism [14]. 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.
12.1 Problem Definition 12.1 Problem Definition
From RFC 3424 any UNSAF proposal must provide: From RFC 3424 any UNSAF proposal must provide:
skipping to change at page 36, line 48 skipping to change at page 40, line 40
Description of an exit strategy/transition plan. The better short Description of an exit strategy/transition plan. The better short
term fixes are the ones that will naturally see less and less use term fixes are the ones that will naturally see less and less use
as the appropriate technology is deployed. as the appropriate technology is deployed.
ICE itself doesn't easily get phased out. However, it is useful even ICE itself doesn't easily get phased out. However, it is useful even
in a globally connected Internet, to serve as a means for detecting in a globally connected Internet, to serve as a means for detecting
whether a router failure has temporarily disrupted connectivity, for whether a router failure has temporarily disrupted connectivity, for
example. However, what ICE does is help phase out other UNSAF example. However, what ICE does is help phase out other UNSAF
mechanisms. ICE effectively selects amongst those mechanisms, mechanisms. ICE effectively selects amongst those mechanisms,
prioritizing ones that are better, and deprioritizing ones that are prioritizing ones that are better, and deprioritizing ones that are
worse. Local IPv6 addresses are always the most preferred. As NATs worse. Local IPv6 addresses can be preferred. As NATs begin to
begin to dissipate as IPv6 is introduced, derived transport addresses dissipate as IPv6 is introduced, derived transport addresses from
from other UNSAF mechanisms simply never get used, because higher other UNSAF mechanisms simply never get used, because higher priority
priority connectivity exists. Therefore, the servers get used less connectivity exists. Therefore, the servers get used less and less,
and less, and can eventually be remove when their usage goes to zero. and can eventually be remove when their usage goes to zero.
Indeed, ICE can assist in the transition from IPv4 to IPv6. It can Indeed, ICE can assist in the transition from IPv4 to IPv6. It can
be used to determine whether to use IPv6 or IPv4 when two dual-stack be used to determine whether to use IPv6 or IPv4 when two dual-stack
hosts communicate with SIP (IPv6 gets used). It can also allow a hosts communicate with SIP (IPv6 gets used). It can also allow a
client in a v6 island to communicate with a v4 host on the other side network with both 6to4 and native v6 connectivity to determine which
of a 6to4 NAT, by allowing the v6 host to address-fix against the v4 address to use when communicating with a peer.
host, and in the process, obtain a v4 address which can be handed to
the v4 client.
12.3 Brittleness Introduced by ICE 12.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 RFC 3489) 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 client to try and classify the type of NAT it is which requires a client 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
skipping to change at page 38, line 4 skipping to change at page 41, line 46
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 client and the STUN server, traditional STUN shared NAT between each client and the STUN server, traditional STUN
may not work. With ICE, that restriction can be lifted. may not work. With ICE, that restriction can be lifted.
Traditional STUN also introduces some security considerations. Traditional STUN also introduces some security considerations.
Fortunately, those security considerations are also mitigated by ICE.
Unfortunately, since ICE still uses network resident STUN servers,
those security considerations still exist.
12.4 Requirements for a Long Term Solution 12.4 Requirements for a Long Term Solution
From RFC 3424, any UNSAF proposal must provide: From RFC 3424, any UNSAF proposal must provide:
Identify requirements for longer term, sound technical solutions Identify requirements for longer term, sound technical solutions
-- contribute to the process of finding the right longer term -- contribute to the process of finding the right longer term
solution. solution.
Our conclusions from STUN remain unchanged. However, we feel ICE Our conclusions from STUN remain unchanged. However, we feel ICE
actually helps because we believe it can be part of the long term actually helps because we believe it can be part of the long term
solution. solution.
12.5 Issues with Existing NAPT Boxes 12.5 Issues with Existing NAPT Boxes
skipping to change at page 39, line 7 skipping to change at page 42, line 28
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.
13. Acknowledgements 13. Acknowledgements
The authors would like to thank Douglas Otis and Francois Audet for The authors would like to thank Douglas Otis, Francois Audet and
their comments and input. Magnus Westerland for their comments and input.
14. References 14. References
14.1 Normative References 14.1 Normative References
[1] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - [1] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN -
Simple Traversal of User Datagram Protocol (UDP) Through Network Simple Traversal of User Datagram Protocol (UDP) Through Network
Address Translators (NATs)", RFC 3489, March 2003. Address Translators (NATs)", RFC 3489, March 2003.
[2] Huitema, C., "Real Time Control Protocol (RTCP) attribute in [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., [3] 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] Camarillo, G., "The Alternative Network Address Types Semantics [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[5] Zopf, R., "Real-time Transport Protocol (RTP) Payload for
Comfort Noise (CN)", RFC 3389, September 2002.
[6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January
2004.
[7] Camarillo, G., "The Alternative Network Address Types Semantics
for the Session Description Protocol Grouping Framework", for the Session Description Protocol Grouping Framework",
draft-ietf-mmusic-anat-01 (work in progress), June 2004. draft-ietf-mmusic-anat-01 (work in progress), June 2004.
[8] Rosenberg, J., "Traversal Using Relay NAT (TURN)",
draft-rosenberg-midcom-turn-05 (work in progress), July 2004.
14.2 Informative References 14.2 Informative References
[5] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming [9] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998. Protocol (RTSP)", RFC 2326, April 1998.
[6] Senie, D., "Network Address Translator (NAT)-Friendly [10] Senie, D., "Network Address Translator (NAT)-Friendly
Application Design Guidelines", RFC 3235, January 2002. Application Design Guidelines", RFC 3235, January 2002.
[7] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. [11] 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.
[8] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm [12] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm
Specific IP: Framework", RFC 3102, October 2001. Specific IP: Framework", RFC 3102, October 2001.
[9] Borella, M., Grabelsky, D., Lo, J. and K. Taniguchi, "Realm [13] 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.
[10] Yon, D., "Connection-Oriented Media Transport in the Session [14] Daigle, L. and IAB, "IAB Considerations for UNilateral
Description Protocol (SDP)", draft-ietf-mmusic-sdp-comedia-07
(work in progress), June 2004.
[11] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002. Translation", RFC 3424, November 2002.
[12] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, [15] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC "RTP: A Transport Protocol for Real-Time Applications", RFC
3550, July 2003. 3550, July 2003.
[13] Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K. [16] Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004. 3711, March 2004.
[14] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via [17] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
IPv4 Clouds", RFC 3056, February 2001. IPv4 Clouds", RFC 3056, February 2001.
[15] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", [18] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs",
draft-huitema-v6ops-teredo-02 (work in progress), June 2004. draft-huitema-v6ops-teredo-02 (work in progress), June 2004.
[16] Rosenberg, J., "Traversal Using Relay NAT (TURN)", [19] Hellstrom, G., "RTP Payload for Text Conversation",
draft-rosenberg-midcom-turn-04 (work in progress), February draft-ietf-avt-rfc2793bis-09 (work in progress), August 2004.
2004.
Author's Address Author's Address
Jonathan Rosenberg Jonathan Rosenberg
dynamicsoft Cisco Systems
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany, NJ 07054 Parsippany, NJ 07054
US US
Phone: +1 973 952-5000 Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com EMail: jdrosen@dynamicsoft.com
URI: http://www.jdrosen.net URI: http://www.jdrosen.net
Intellectual Property Statement Intellectual Property Statement
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/