SIPPING J. Rosenberg
Internet-Draft dynamicsoft
Expires: January 17, 2005 G. Camarillo
Ericsson
July 19, 2004
Examples of Network Address Translation (NAT) and Firewall Traversal
for the Session Initiation Protocol (SIP)
draft-rosenberg-sipping-nat-scenarios-03
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
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
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 17, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document contains a set of examples about how to establish
sessions through Network Address Translators (NATs) using the Session
Initiation Protocol (SIP). NAT traversal for SIP is accomplished
using Interactive Connectivity Establishment (ICE), which allows the
media streams to work, in addition to the SIP extension for symmetric
response routing, which allows SIP itself to flow through NAT. The
examples cover a range of network topologies and use cases. This
Rosenberg & Camarillo Expires January 17, 2005 [Page 1]
Internet-Draft ICE July 2004
variability helps to demonstrate that the ICE methodology always
works, and that a common client algorithm, independent of the network
topology and deployment configuration, results in the best
connectivity.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Residential Users . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Full Cone NAT . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Symmetric NAT . . . . . . . . . . . . . . . . . . . . . . 16
3. Basic Enterprise . . . . . . . . . . . . . . . . . . . . . . . 22
3.1 Intra-Enterprise Call . . . . . . . . . . . . . . . . . . 23
3.2 Extra-Enterprise Call . . . . . . . . . . . . . . . . . . 28
3.3 Inter-Enterprise . . . . . . . . . . . . . . . . . . . . . 29
4. Advanced Enterprise . . . . . . . . . . . . . . . . . . . . . 36
5. Centrex . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.1 Intra-Enterprise Call . . . . . . . . . . . . . . . . . . 39
6. An IPv6 Network with a pool of IPv4 addresses . . . . . . . . 46
6.1 Initial Offer Generated by the IPv6 SIP User Agent . . . . 47
6.2 Initial Offer Generated by the Residential User . . . . . 49
7. Security Considerations . . . . . . . . . . . . . . . . . . . 52
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54
10. Informative References . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 55
Intellectual Property and Copyright Statements . . . . . . . . 56
Rosenberg & Camarillo Expires January 17, 2005 [Page 2]
Internet-Draft ICE July 2004
1. Introduction
The Session Initiation Protocol (SIP) [1], without any extensions,
has difficulty in networks that contain Network Address Translators
(NAT). SIP, out of necessity, breaks many of the guidelines
described in RFC 3235 [2]. NAT traversal for SIP is especially
problematic for the media streams, which generally flow from user
agent to user agent.
To remedy this, RFC 3581 [3] defines a SIP extension for symmetric
response routing, which allows SIP itself to traverse NAT. In order
for the media streams to traverse NAT, Interactive Connectivity
Establishment (ICE) [4] is used. ICE describes a methodology for NAT
traversal for multimedia signaling protocols, such as SIP. It also
defines some extensions to the Session Description Protocol (SDP) [5]
for conveying additional data. ICE makes use of several protocols,
namely the Simple Traversal of UDP Through NAT (STUN) [6] and
Traversal Using Relay NAT [7], in order to operate.
This document contains a number of example deployment topologies and
network configurations. For each, it shows how clients compliant to
the above specifications will properly establish communications, and
indeed, will do so using the optimal media path for that scenario.
This document focuses on media streams that are carried over the Real
Time Transport Protocol (RTP) [8]. In all cases, only RTP is shown
and discussed, to simplify the discussion. RTCP related operations
(generally STUN queries parallel to the RTP ones) are omitted.
Rosenberg & Camarillo Expires January 17, 2005 [Page 3]
Internet-Draft ICE July 2004
2. Residential Users
In this scenario, a user has a broadband connection to the Internet,
using a cable modem or DSL, for example. In order to provide
security, or to run multiple machines, the user has purchased an
off-the-shelf "DSL Router" as they are called. These devices,
manufactured by companies such as Linksys, Netgear, 2wire, and
Netopia, generally include a NAT, simple firewall, DHCP server and
client, and a built in ethernet switch of some sort. The firewall
generally allows all outgoing traffic, but disallows incoming traffic
unless specific port forwarding or a DMZ host has been configured.
The NAT treatment of UDP in these boxes varies. The most common
types appear to be full-cone and restricted cone.
The user in this scenario wishes to use a communications service from
a retail provider, such as net2phone or deltathree, for example. The
connection between the user and the provider is through the cable
modem or DSL, through the public Internet. The user may have
multiple PCs in their home accessing this service, but they are not
related in any way. This scenario also includes the case where its
not a PC, but a standalone SIP phone. In this case, the provider
might be providing some kind of second line VoIP service. This
scenario is depicted in Figure 1.
Rosenberg & Camarillo Expires January 17, 2005 [Page 4]
Internet-Draft ICE July 2004
+--------+ +--------+
|Provider| |TURN/ |
| Proxy | | STUN |
| | | Server |
+----+---+ +----+---+
| |
| |
--+-------------+--
/////// \\\\\\\
/// \\\
|| ||
| Internet |
| |
| |
|| ||
\\\ ///
\\\\\\\ ///////
---------+---------
| DSL, Cable
+--------+-------+
| Home NAT |
+----------------+
+--------+ +----------+
| | | / \ |
| PC | /SIP \
| | /Phone \
| | / \
+--------+ ------------
Figure 1: Residence with Single NAT
In this case, the provider administers a SIP proxy and a TURN/STUN
server. This server is running STUN on the default port (3478) and
TURN on port 5556.
2.1 Full Cone NAT
A As NAT STUN+TURN Server
|(1) STUN Bind | |
|s=10.0.1.1:1010 | |
|d=192.0.2.10:3478 | |
|----------------------->| |
| |(2) STUN Bind |
Rosenberg & Camarillo Expires January 17, 2005 [Page 5]
Internet-Draft ICE July 2004
| |s=192.0.2.1:9988 |
| |d=192.0.2.10:3478 |
| |----------------------->|
| |(3) STUN Resp |
| |s=192.0.2.10:3478 |
| |d=192.0.2.1:9988 |
| |M=192.0.2.1:9988 |
| |<-----------------------|
|(4) STUN Resp | |
|s=192.0.2.10:3478 | |
|d=10.0.1.1:1010 | |
|M=192.0.2.1:9988 | |
|<-----------------------| |
|(5) TURN Alloc | |
|s=10.0.1.1:1010 | |
|d=192.0.2.10:5556 | |
|----------------------->| |
| |(6) TURN Alloc |
| |s=192.0.2.1:9988 |
| |d=192.0.2.10:5556 |
| |----------------------->|
| |(7) TURN Resp |
| |s=192.0.2.10:5556 |
| |d=192.0.1.1:9988 |
| |M=192.0.2.10:8076 |
| |<-----------------------|
|(8) TURN Resp | |
|s=192.0.2.10:5556 | |
|d=10.0.1.1:1010 | |
|M=192.0.2.10:8076 | |
|<-----------------------| |
Figure 2: Message sequence for A's Unilateral Allocations
We first consider the case where two such residential users call each
other, and both are using NATs of the full-cone variety. The caller
follows the ICE algorithm. As such, it firsts allocates a pair of
ports on its local interface for RTP and RTCP traffic (10.0.1.1:1010
and 10.0.1.1:1011). As shown in Figure 2, the client issues a STUN
request from the RTP port (message 1), which passes through the NAT
on its way to the STUN server. In the figure, the "s=" indicates the
source transport address of the message, and "d=" indicates the
destination transport address. The NAT translates the 10.0.1.1:1010
to 192.0.2.1:9988, and this request arrives at the STUN server
(message 2). The STUN server copies the source address into the
MAPPED-ADDRESS field in the STUN response (the M= line in message 3),
and this passes through the NAT, back to the client. The client now
Rosenberg & Camarillo Expires January 17, 2005 [Page 6]
Internet-Draft ICE July 2004
has a STUN derived transport address of 192.2.0.1:9988. Thought not
show, the client will follow a similar process to obtain a STUN
derived transport address for RTCP. However, this address will
frequently not occupy an adjacent port to the RTP.
Next, the client follows a similar process to obtain a TURN port for
RTP (messages 5-8). The TURN requests are also sent from the same
local transport address. Note, however, that the TURN derived
transport addresses for RTP (192.0.2.10:8076) and RTCP will be on
adjacent ports. This is because the TURN pre-allocation procedure
was used in the TURN request for the RTP port (message 5).
The client prioritizes these addresses, choosing the local interface
address with priority 1.0, the STUN address with priority 0.8, and
the TURN address with priority 0.4. From this, it generates an offer
that looks like this:
v=0
o=alice 2890844730 2890844731 IN IP4 host.example.com
s=
c=IN IP4 192.0.2.10
t=0 0
m=audio 8076 RTP/AVP 0
a=alt:1 1.0 : user 9kksj== 10.0.1.1 1010
a=alt:2 0.8 : user1 9kksk== 192.0.2.1 9988 192.0.2.1 9990
a=alt:3 0.4 : user2 9kksl== 192.0.2.10 8076
Figure 3: A's Offer
Note how the TURN derived transport address is used in the m and c
lines, since this is the address with the highest probability of
working with a non-ICE peer. That address is also included in the
list of alteratives (with ID 3). Also note that because the STUN
derived transport address for RTP and RTCP were not adjacent, two
transport addresses are provided for alternate 2.
B Bs NAT STUN+TURN Server
|(1) STUN Bind | |
|s=192.168.3.1:23766 | |
|d=192.0.2.10:3478 | |
|----------------------->| |
| |(2) STUN Bind |
| |s=192.0.2.2:10892 |
| |d=192.0.2.10:3478 |
| |----------------------->|
| |(3) STUN Resp |
Rosenberg & Camarillo Expires January 17, 2005 [Page 7]
Internet-Draft ICE July 2004
| |s=192.0.2.10:3478 |
| |d=192.0.2.2:10892 |
| |M=192.0.2.2:10892 |
| |<-----------------------|
|(4) STUN Resp | |
|s=192.0.2.10:3478 | |
|d=192.168.3.1:23766 | |
|M=192.0.2.2:10892 | |
|<-----------------------| |
|(5) TURN Alloc | |
|s=192.168.3.1:23766 | |
|d=192.0.2.10:5556 | |
|----------------------->| |
| |(6) TURN Alloc |
| |s=192.0.2.2:10892 |
| |d=192.0.2.10:5556 |
| |----------------------->|
| |(7) TURN Resp |
| |s=192.0.2.10:5556 |
| |d=192.0.2.2:10892 |
| |M=192.0.2.10:8078 |
| |<-----------------------|
|(8) TURN Resp | |
|s=192.0.2.10:5556 | |
|d=192.168.3.1:23766 | |
|M=192.0.2.10:8078 | |
|<-----------------------| |
Figure 4: Message sequence for B's Unilateral Allocations
This offer arrives at the called party, user B. User B is also
behind a full-cone NAT, and is using the 192.168/16 private address
space internally. It happens to be using the same service provider
as A, and is therefore using the same TURN server, at
192.0.2.10:5556. User B follows the same set of procedures followed
by user A. It uses local interfaces, STUN, and TURN, and obtains a
set of transport addresses that it can use. This process is shown in
Figure 4. This process differs from that of Figure 2 only in the
actual addresses and ports used and obtained.
A As NAT TURN + STUN Server Bs NAT B
| | | |(1) STUN Bind|
| | | |s=192.168.3.1:23766
| | | |d=10.0.1.1:1010
| | | |<------------|
| | |Unreachable | |
Rosenberg & Camarillo Expires January 17, 2005 [Page 8]
Internet-Draft ICE July 2004
| | | |(2) STUN Bind|
| | | |s=192.168.3.1:23766
| | | |d=192.0.2.1:9988
| | | |<------------|
| |(3) STUN Bind| | |
| |s=192.0.2.2:10892 | |
| |d=192.0.2.1:9988 | |
| |<--------------------------| |
|(4) STUN Bind| | | |
|s=192.0.2.2:10892 | | |
|d=10.0.1.1:1010 | | |
|<------------| | | |
|(5) STUN Reply | | |
|s=10.0.1.1:1010 | | |
|d=192.0.2.2:10892 | | |
|M=192.0.2.2:10892 | | |
|------------>| | | |
| |(6) STUN Reply | |
| |s=192.0.2.1:9988 | |
| |d=192.0.2.2:10892 | |
| |M=192.0.2.2:10892 | |
| |-------------------------->| |
| | | |(7) STUN Reply
| | | |s=192.0.2.1:9988
| | | |d=192.168.3.1:23766
| | | |M=192.0.2.2:10892
| | | |------------>|
| | | |(8) STUN Bind|
| | | |s=192.168.3.1:23766
| | | |d=192.0.2.10:8076
| | | |<------------|
| | |(9) STUN Bind| |
| | |s=192.0.2.2:10892 |
| | |d=192.0.2.10:8076 |
| | |<------------| |
| |(10) STUN Bind | |
| |s=192.0.2.10:5556 | |
| |d=192.0.2.1:9988 | |
| |<------------| | |
|(11) STUN Bind | | |
|s=192.0.2.10:5556 | | |
|d=10.0.1.1:1010 | | |
|<------------| | | |
|(12) STUN Reply | | |
|s=10.0.1.1:1010 | | |
|d=192.0.2.10:5556 | | |
|M=192.0.2.10:5556 | | |
|------------>| | | |
Rosenberg & Camarillo Expires January 17, 2005 [Page 9]
Internet-Draft ICE July 2004
| |(13) STUN Reply | |
| |s=192.0.2.1:9988 | |
| |d=192.0.2.10:5556 | |
| |M=192.0.2.10:5556 | |
| |------------>| | |
| | |(14) STUN Reply |
| | |s=192.0.2.10:8076 |
| | |d=192.0.2.2:10892 |
| | |M=192.0.2.10:5556 |
| | |------------>| |
| | | |(15) STUN Reply
| | | |s=192.0.2.10:8076
| | | |d=192.168.3.1:23766
| | | |M=192.0.2.10:5556
| | | |------------>|
Figure 5: B's Connectivity Checks
While B's phone is ringing, B's user agent uses STUN to test
connectivity from its local transport address pair (192.168.3.1:23766
and 192.168.3.1:23767) to the three alternates listed in the offer.
The flow for that is shown in Figure 5. This flow, and the
discussions, only consider the RTP transport addresses. The
procedures would all be identical for RTCP. First, B tests
connectivity to the alternate with ID 1, which is 10.0.1.1:1010. It
does so by attempting to send a STUN request to this address (message
1). Of course, this is a private address, and not in the same
network as B. Therefore, it is unreachable, and no STUN response is
received.
In parallel, B tests connectivity to the alternate with ID 2, which
is 192.0.2.1:9988. To do this, it sends a STUN request to that
address. It sends it with a source address equal to its local
transport address; the same one that it used to send the previous
TURN and STUN packets (192.168.3.1:23766). This request (message 2)
arrives at the NAT. Since the NAT is full cone, and since this
address has an existing binding, the NAT translates the source
address to that existing binding, 192.0.2.2:10892. This request
(message 3) continues onwards to A's NAT. Since A's NAT is also full
cone, the existing binding for 192.0.2.1:9988 is used, and the
destination address is translated to 10.0.1.1:1010 and then forwarded
towards A (message 4). A receives this. It verifies the username
and password, and then generates a response. The response contains a
MAPPED-ADDRESS equal to the source address seen in the STUN request
(192.0.2.2:10892). It passes back through A's NAT (message 5),
through B's NAT (message 6), and back to B (message 7).
B examines the MAPPED-ADDRESS in the STUN response. Its
Rosenberg & Camarillo Expires January 17, 2005 [Page 10]
Internet-Draft ICE July 2004
192.0.2.2:10892. However, this is not a new address. B is already
aware of this address as a result of its initial STUN Binding
requests to the TURN/STUN server (Figure 4). As such, no additional
addresses were learned.
In parallel with the tests against ID 2, B tests connectivity to the
alternate with ID 3. This is the address A allocated through TURN.
Of course, B does not know this. B sends a STUN request to this
address (192.0.2.10:8076), and sends it from the same local transport
address (192.168.3.1:23766) (message 8). The NAT, once again,
translates the source address to 192.0.2.2:10892 (message 9). This
is routed to the TURN server. The TURN server locks down the binding
allocated to A, such that it will now begin relaying packets sent
from A to 192.0.2.2:10892. The TURN server forwards the packet
towards A (message 10). This reaches A's NAT, which translates the
destination address based on the existing binding. The STUN request
is then delivered to A (message 11). A verifies the username and
password, and then generates a STUN response. This response contains
the source address that the request came from. In this case, that
source address is the public transport address of the TURN server
(192.0.2.10:5556). This STUN response is relayed all the way back to
B (messages 12-15).
B examines the MAPPED-ADDRESS in this STUN response. It's
192.0.2.10:5556, which is a new address. As a result, B has now
obtained a peer derived STUN address. It adds this to its list of
transport addresses. Its priority equals that of the address it was
derived from - ID 3 - which has a qvalue of 0.4.
At some point, B picks up, and an answer is generated. The answer
would look like this:
v=0
o=bob 2890844730 289084871 IN IP4 host2.example.com
s=
c=IN IP4 192.0.2.10
t=0 0
m=audio 8078 RTP/AVP 0
a=alt:4 1.0 : peer as88jl 192.168.3.1 23766
a=alt:5 0.8 : peer1 as88kl 192.0.2.2 10892
a=alt:6 0.4 : peer2 as88ll 192.0.2.10 8078
a=alt:7 0.4 3 peer3 as88ml 192.0.2.10 5556
Figure 6: B's Answer
Note how the alternative with ID 7 indicates that it was derived from
Rosenberg & Camarillo Expires January 17, 2005 [Page 11]
Internet-Draft ICE July 2004
the alternate with ID 3. Also, note that the four alternates use
different IDs than the ones from the offer. This is for readability
purposes only. The IDs are scoped to that specific agent, and there
is no requirement that they do not use the same values.
This answer is sent to A. At the same time, B can send audio to A
using the highest priority alternate that connectivity was
established to. That is the alternate with ID 2, A's STUN derived
transport address.
A As NAT TURN + STUN Server Bs NAT B
|(1) STUN Bind| | | |
|s=10.0.1.1:1010 | | |
|d=192.168.3.1:23766 | | |
|------------>| | | |
| |Unreachable | | |
|(2) STUN Bind| | | |
|s=10.0.1.1:1010 | | |
|d=192.0.2.2:10892 | | |
|------------>| | | |
| |(3) STUN Bind| | |
| |s=192.0.2.1:9988 | |
| |d=192.0.2.2:10892 | |
| |-------------------------->| |
| | | |(4) STUN Bind|
| | | |s=192.0.2.1:9988
| | | |d=192.168.3.1:23766
| | | |------------>|
| | | |(5) STUN Reply
| | | |s=192.168.3.1:23766
| | | |d=192.0.2.1:9988
| | | |M=192.0.2.1:9988
| | | |<------------|
| |(6) STUN Reply | |
| |s=192.0.2.2:10892 | |
| |d=192.0.2.1:9988 | |
| |M=192.0.2.1:9988 | |
| |<--------------------------| |
|(7) STUN Reply | | |
|s=192.0.2.2:10892 | | |
|d=10.0.1.1:1010 | | |
|M=192.0.2.1:9988 | | |
|<------------| | | |
|(8) STUN Bind| | | |
|s=10.0.1.1:1010 | | |
|d=192.0.2.10:8078 | | |
|------------>| | | |
Rosenberg & Camarillo Expires January 17, 2005 [Page 12]
Internet-Draft ICE July 2004
| |(9) STUN Bind| | |
| |s=192.0.2.1:9988 | |
| |d=192.0.2.10:8078 | |
| |------------>| | |
| | |(10) STUN Bind |
| | |s=192.0.2.10:5556 |
| | |d=192.0.2.2:10892 |
| | |------------>| |
| | | |(11) STUN Bind
| | | |s=192.0.2.10:5556
| | | |d=192.168.3.1:23766
| | | |------------>|
| | | |(12) STUN Reply
| | | |s=192.168.3.1:23766
| | | |d=192.0.2.10:5556
| | | |M=192.0.2.10:5556
| | | |<------------|
| | |(13) STUN Reply |
| | |s=192.0.2.2:10892 |
| | |d=192.0.2.10:5556 |
| | |M=192.0.2.10:5556 |
| | |<------------| |
| |(14) STUN Reply | |
| |s=192.0.2.10:8078 | |
| |d=192.0.2.1:9988 | |
| |M=192.0.2.10:5556 | |
| |<------------| | |
|(15) STUN Reply | | |
|s=192.0.2.10:8078 | | |
|d=10.0.1.1:1010 | | |
|M=192.0.2.10:5556 | | |
|<------------| | | |
|(16) STUN Bind | | |
|s=10.0.1.1:1010 | | |
|d=192.0.2.10:5556 | | |
|------------>| | | |
| |(17) STUN Bind | |
| |s=192.0.2.1:9988 | |
| |d=192.0.2.10:5556 | |
| |------------>| | |
| | |(18) STUN Bind |
| | |s=192.0.2.10:8076 |
| | |d=192.0.2.2:10892 |
| | |------------>| |
| | | |(19) STUN Bind
| | | |s=192.0.2.10:8076
| | | |d=192.168.3.1:23766
| | | |------------>|
Rosenberg & Camarillo Expires January 17, 2005 [Page 13]
Internet-Draft ICE July 2004
| | | |(20) STUN Reply
| | | |s=192.168.3.1:23766
| | | |d=192.0.2.10:8076
| | | |M=192.0.2.10:8076
| | | |<------------|
| | |(21) STUN Reply |
| | |s=192.0.2.2:10892 |
| | |d=192.0.2.10:8076 |
| | |M=192.0.2.10:8076 |
| | |<------------| |
| |(22) STUN Reply | |
| |s=192.0.2.10:5556 | |
| |d=192.0.2.1:9988 | |
| |M=192.0.2.10:8076 | |
| |<------------| | |
|(23) STUN Reply | | |
|s=192.0.2.10:5556 | | |
|d=10.0.1.1:1010 | | |
|M=192.0.2.10:8076 | | |
|<------------| | | |
Figure 7: A's Connectivity Checks
When the answer arrives at A, A performs similar connectivity checks,
shown in Figure 7. Each connectivity check is a STUN request sent
from its local transport address (10.0.1.1:1010). The first is to
the alternate with ID 4, which is 192.168.3.1:23766. The STUN
request to this address (message 1) fails, since this is an
unreachable private address. The second check is to the alternate
with ID 5 (192.0.2.2:10892), which is the public address for B
obtained as a result of STUN requests to the network server.
Messages 2-7 represent the flow for this case. It is similar to the
sequence in Figure 5 messages 2-7, differing only in the IP
addresses. The result of this check provides a peer derived
transport address of 192.0.2.1:9988. A already knows this address.
The third connectivity check is to the alternate with ID 6
(192.0.2.10:8078). This represents A's TURN derived transport
address. Messages 8-15 represent the check for this address, and
they are also similar to messages 8-15 of Figure 5. This check
provides A with a peer derived transport address of 192.0.2.10:5556.
This represents a new address for A. It has a priority equal to the
address it was derived from, which is 0.4.
The final connectivity check is to the alternate with ID 7
(192.0.2.10 5556). The SDP indicates that this address itself is a
peer derived transport address. It was derived from A's transport
address with ID 3, which is 192.0.2.10:8076, its TURN derived
transport address. Because of that, the STUN request is sent from
Rosenberg & Camarillo Expires January 17, 2005 [Page 14]
Internet-Draft ICE July 2004
the local transport address that 192.0.2.10:8076 was derived from.
This local address is 10.0.1.1:1010. The message sequence for this
check is represented by messages 16-23 of Figure 7. The STUN request
is sent with a source address of 10.0.1.1:1010, to 192.0.2.10:5556.
This is the well-known address of the TURN relay. This message
passes through the NAT, and the source address is translated to A's
public address, 192.0.2.1:9988 (message 17). Note that this same
public address is used for all requests sent from 10.0.1.1:1010
because the NAT is full-cone. This arrives at the TURN server. The
TURN server associates this message (which is just an arbitrary UDP
packet as far as the TURN server is concerned) with the binding
created for A. The peer in this case has been locked down. So, the
packet is forwarded with a source address equal to the binding
allocated to A (192.0.2.10:8076) and a destination address equal to
the locked-down address (192.0.2.2:10892) (message 18). This arrives
at B's NAT, where the destination address is translated to B's
private address, 192.168.3.1:23766 (message 19). This arrives at B,
which notes the source address in the STUN reply (192.0.2.10:8076).
This reply is forwarded back to A (messages 20-23). From this, A
sees a peer derived transport address of 192.0.2.10:8076. However,
it already knows this address.
The result of the connectivity checks is that A determines it has
connectivity to the alternates with IDs 5, 6 and 7. Of these, the
one with ID 5 has the highest priority, and so this one is used to
send media. Of course, A could have been sending media to B during
these tests using the address in the m and c lines, which represents
B's TURN derived transport address. Once the connectivity checks
complete, A can switch to the one with ID 5, which is B's STUN
derived transport address.
The connectivity checks also provided A with a new peer derived
transport address - 192.0.2.10:5556 - with a priority of 0.4.
However, A had received STUN requests on its alternates with IDs 2
and 3. The one with ID 2 (its STUN derived transport address) has
higher priority than 0.4. So, A knows that generating a new ICE
cycle to convey this address would not be useful. Thus, no new offer
is sent. Indeed, since A had received a STUN request from B on its
STUN derived transport address, A knows that its lower priority
derived transport address is no longer needed. So, it is able to
free up the TURN derived transport address a few seconds later. The
same goes for B. Once it receives the STUN request to its TURN
derived transport address (message 11 of Figure 7, it can free its
TURN derived transport address.
In conclusion, the result in this case is that A and B will
communicate with each other using their STUN derived transport
addresses.
Rosenberg & Camarillo Expires January 17, 2005 [Page 15]
Internet-Draft ICE July 2004
2.2 Symmetric NAT
A As NAT STUN+TURN Server
|(1) STUN Bind | |
|s=10.0.1.1:1010 | |
|d=192.0.2.10:3478 | |
|----------------------->| |
| |(2) STUN Bind |
| |s=192.0.2.1:9988 |
| |d=192.0.2.10:3478 |
| |----------------------->|
| |(3) STUN Resp |
| |s=192.0.2.10:3478 |
| |d=192.0.2.1:9988 |
| |M=192.0.2.1:9988 |
| |<-----------------------|
|(4) STUN Resp | |
|s=192.0.2.10:3478 | |
|d=10.0.1.1:1010 | |
|M=192.0.2.1:9988 | |
|<-----------------------| |
|(5) TURN Alloc | |
|s=10.0.1.1:1010 | |
|d=192.0.2.10:5556 | |
|----------------------->| |
| |(6) TURN Alloc |
| |s=192.0.2.1:9991 |
| |d=192.0.2.10:5556 |
| |----------------------->|
| |(7) TURN Resp |
| |s=192.0.2.10:5556 |
| |d=192.0.1.1:9991 |
| |M=192.0.2.10:8076 |
| |<-----------------------|
|(8) TURN Resp | |
|s=192.0.2.10:5556 | |
|d=10.0.1.1:1010 | |
|M=192.0.2.10:8076 | |
|<-----------------------| |
Figure 8: A's Unilateral Allocations
In this case, both residential users have symmetric NATs. The call
starts again with A performing its unilateral allocations, as is
shown in Figure 8. This message sequence is nearly identical to that
of Figure 2. The only difference is that, because the NAT is
Rosenberg & Camarillo Expires January 17, 2005 [Page 16]
Internet-Draft ICE July 2004
symmetric, different bindings are allocated for the two STUN and two
TURN queries. A's discovers an identical set of addresses, however,
and so generates the same offer as in Figure 3.
B Bs NAT STUN+TURN Server
|(1) STUN Bind | |
|s=192.168.3.1:23766 | |
|d=192.0.2.10:3478 | |
|----------------------->| |
| |(2) STUN Bind |
| |s=192.0.2.2:10892 |
| |d=192.0.2.10:3478 |
| |----------------------->|
| |(3) STUN Resp |
| |s=192.0.2.10:3478 |
| |d=192.0.2.2:10892 |
| |M=192.0.2.2:10892 |
| |<-----------------------|
|(4) STUN Resp | |
|s=192.0.2.10:3478 | |
|d=192.168.3.1:23766 | |
|M=192.0.2.2:10892 | |
|<-----------------------| |
|(5) TURN Alloc | |
|s=192.168.3.1:23766 | |
|d=192.0.2.10:5556 | |
|----------------------->| |
| |(6) TURN Alloc |
| |s=192.0.2.2:10894 |
| |d=192.0.2.10:5556 |
| |----------------------->|
| |(7) TURN Resp |
| |s=192.0.2.10:5556 |
| |d=192.0.2.2:10894 |
| |M=192.0.2.10:8078 |
| |<-----------------------|
|(8) TURN Resp | |
|s=192.0.2.10:5556 | |
|d=192.168.3.1:23766 | |
|M=192.0.2.10:8078 | |
|<-----------------------| |
Figure 9: B's Unilateral Allocations
When B receives this offer, it performs its unilateral allocations.
Like A's, these allocations (shown in Figure 9) are almost identical
Rosenberg & Camarillo Expires January 17, 2005 [Page 17]
Internet-Draft ICE July 2004
to those in Figure 4. They differ in the same way - the NAT will
allocate a different binding for each of the two STUN and two TURN
queries. However, the set of derived transport address is the same.
B now begins performing connectivity checks. These are shown in
Figure 10. As in the previous case (Figure 5), the STUN request to
10.0.1.1:1010 fails. However, here, the STUN request to
192.0.2.1:9988 also fails. Thats because this packet arrives at A's
NAT, and the NAT finds that the public transport address
192.0.2.1:9988 has been allocated, however, it was allocated when the
client sent to 192.0.2.10:3478. Here, the source address is not
192.0.2.10:3478, and so the packet is discarded. The STUN request to
192.0.2.10:8076 does work, however. Thats because the TURN server
sends the request from the same IP address and port that it received
the original TURN allocation request on.
A As NAT TURN + STUN Server Bs NAT B
| | | |(1) STUN Bind|
| | | |s=192.168.3.1:23766
| | | |d=10.0.1.1:1010
| | | |<------------|
| | |Unreachable | |
| | | |(2) STUN Bind|
| | | |s=192.168.3.1:23766
| | | |d=192.0.2.1:9988
| | | |<------------|
| |(3) STUN Bind| | |
| |s=192.0.2.2:10896 | |
| |d=192.0.2.1:9988 | |
| |<--------------------------| |
| |Unreachable | | |
| | | |(4) STUN Bind|
| | | |s=192.168.3.1:23766
| | | |d=192.0.2.10:8076
| | | |<------------|
| | |(5) STUN Bind| |
| | |s=192.0.2.2:10897 |
| | |d=192.0.2.10:8076 |
| | |<------------| |
| |(6) STUN Bind| | |
| |s=192.0.2.10:5556 | |
| |d=192.0.2.1:9991 | |
| |<------------| | |
|(7) STUN Bind| | | |
|s=192.0.2.10:5556 | | |
|d=10.0.1.1:1010 | | |
|<------------| | | |
|(8) STUN Reply | | |
Rosenberg & Camarillo Expires January 17, 2005 [Page 18]
Internet-Draft ICE July 2004
|s=10.0.1.1:1010 | | |
|d=192.0.2.10:5556 | | |
|M=192.0.2.10:5556 | | |
|------------>| | | |
| |(9) STUN Reply | |
| |s=192.0.2.1:9991 | |
| |d=192.0.2.10:5556 | |
| |M=192.0.2.10:5556 | |
| |------------>| | |
| | |(10) STUN Reply |
| | |s=192.0.2.10:8076 |
| | |d=192.0.2.2:10897 |
| | |M=192.0.2.10:5556 |
| | |------------>| |
| | | |(11) STUN Reply
| | | |s=192.0.2.10:8076
| | | |d=192.168.3.1:23766
| | | |M=192.0.2.10:5556
| | | |------------>|
Figure 10: B's Connectivity Checks
B's answer to A is the same as in Figure 6. However, B has only
established connectivity to A's TURN derived transport address, and
so it sends media there.
A As NAT TURN + STUN Server Bs NAT B
|(1) STUN Bind| | | |
|s=10.0.1.1:1010 | | |
|d=192.168.3.1:23766 | | |
|------------>| | | |
| |Unreachable | | |
|(2) STUN Bind| | | |
|s=10.0.1.1:1010 | | |
|d=192.0.2.2:10892 | | |
|------------>| | | |
| |(3) STUN Bind| | |
| |s=192.0.2.1:9993 | |
| |d=192.0.2.2:10892 | |
| |-------------------------->| |
| | | |Unreachable |
|(4) STUN Bind| | | |
|s=10.0.1.1:1010 | | |
|d=192.0.2.10:8078 | | |
|------------>| | | |
| |(5) STUN Bind| | |
| |s=192.0.2.1:9994 | |
Rosenberg & Camarillo Expires January 17, 2005 [Page 19]
Internet-Draft ICE July 2004
| |d=192.0.2.10:8078 | |
| |------------>| | |
| | |(6) STUN Bind| |
| | |s=192.0.2.10:5556 |
| | |d=192.0.2.2:10894 |
| | |------------>| |
| | | |(7) STUN Bind|
| | | |s=192.0.2.10:5556
| | | |d=192.168.3.1:23766
| | | |------------>|
| | | |(8) STUN Reply
| | | |s=192.168.3.1:23766
| | | |d=192.0.2.10:5556
| | | |M=192.0.2.10:5556
| | | |<------------|
| | |(9) STUN Reply |
| | |s=192.0.2.2:10894 |
| | |d=192.0.2.10:5556 |
| | |M=192.0.2.10:5556 |
| | |<------------| |
| |(10) STUN Reply | |
| |s=192.0.2.10:8078 | |
| |d=192.0.2.1:9994 | |
| |M=192.0.2.10:5556 | |
| |<------------| | |
|(11) STUN Reply | | |
|s=192.0.2.10:8078 | | |
|d=10.0.1.1:1010 | | |
|M=192.0.2.10:5556 | | |
|<------------| | | |
|(12) STUN Bind | | |
|s=10.0.1.1:1010 | | |
|d=192.0.2.10:5556 | | |
|------------>| | | |
| |(13) STUN Bind | |
| |s=192.0.2.1:9991 | |
| |d=192.0.2.10:5556 | |
| |------------>| | |
| | |(14) STUN Bind |
| | |s=192.0.2.10:8076 |
| | |d=192.0.2.2:10897 |
| | |------------>| |
| | | |(15) STUN Bind
| | | |s=192.0.2.10:8076
| | | |d=192.168.3.1:23766
| | | |------------>|
| | | |(16) STUN Reply
| | | |s=192.168.3.1:23766
Rosenberg & Camarillo Expires January 17, 2005 [Page 20]
Internet-Draft ICE July 2004
| | | |d=192.0.2.10:8076
| | | |M=192.0.2.10:8076
| | | |<------------|
| | |(17) STUN Reply |
| | |s=192.0.2.2:10897 |
| | |d=192.0.2.10:8076 |
| | |M=192.0.2.10:8076 |
| | |<------------| |
| |(18) STUN Reply | |
| |s=192.0.2.10:5556 | |
| |d=192.0.2.1:9991 | |
| |M=192.0.2.10:8076 | |
| |<------------| | |
|(19) STUN Reply | | |
|s=192.0.2.10:5556 | | |
|d=10.0.1.1:1010 | | |
|M=192.0.2.10:8076 | | |
|<------------| | | |
Figure 11: A's Connectivity Checks
When A gets the answer, it too performs its connectivity checks, as
shown in Figure 11. As expected, the connectivity checks to B's
private address and its STUN derived transport addresses fail. The
checks to B's TURN derived transport address succeeds, as does the
check to B's peer derived transport address. Both have a qvalue of
0.4. However, a peer-derived address is always preferred. So, A
will send media to B using 192.0.2.10:5556, which will reach B as a
result of the lock-down on its own TURN binding. As in the full-cone
case, A won't bother to perform another offer with the new peer
derived transport address it learned from message 19
(192.0.2.10:5556), since it knows that this is not of higher priority
than ones that B has already connected to.
Once A connects to B's peer derived address (messages 12 to 19 in
Figure 11), B knows that its equal priority TURN derived transport
address won't be used, so it can free it.
OPEN ISSUE: The same argument can be made about A, in which case
both sides would free their TURN addresses, and nothing works.
Need to come up with a sane prioritization so it doesnt happen.
Rosenberg & Camarillo Expires January 17, 2005 [Page 21]
Internet-Draft ICE July 2004
3. Basic Enterprise
Public Internet
192.0.2.1
+---------+
| |
----------------------| Firewall|--------------------------
| NAT |
10.0.0.0/16 +---------+ DMZ
+---------+ +---------+
| | | TURN/ |
| Proxy | | STUN |
| | | Server |
+---------+ +---------+
...........................................................
+----------+
| / \ |
+---------+ /SIP \ +----------+
| +---------+ /Phone \ | / \ |
| | +---------+ / \ /SIP \
| | | | ------------ /Phone \
+-| | PC | / \
+-| | ------------
+---------+
Enterprise
Figure 12: Enterprise Configuration
In this scenario, shown in Figure 12 there is an enterprise that
wishes to deploy VoIP. The enterprise has a single site, and there
is a firewall/NAT at the border to the public Internet. This NAT is
symmetric. Internally, the enterprise is using 10.0.0.0/16. Behind
the firewall, within the DMZ, is a TURN/STUN server and a SIP proxy.
The firewall has been configured to allow incoming traffic to port
5060 to go to the SIP proxy. It has also allowed incoming UDP
traffic on a specific port range to go to the TURN/STUN server. The
Rosenberg & Camarillo Expires January 17, 2005 [Page 22]
Internet-Draft ICE July 2004
TURN server has an internal address of 10.0.1.10. This port range
contains enough addresses to allow simultaneous conversations to
cover the needs of the enterprise, but no more. External traffic
sent to 192.0.2.1:8000 to 192.0.2.1:9000 is port forwarded to
10.0.1.10:8000 to 10.0.1.10:9000, respectively. That range is
configured on the TURN/STUN server, so that the TURN server allocates
addresses within this range.
Within the enterprise, PCs and hardphones are used for VoIP. All of
them are configured to use the proxy and TURN/STUN server that is run
by the enterprise. Furthermore, all of them are configured to use
the TURN SEND mechanism for doing connectivity checks.
All call flows in this section only indicate RTP. The flows for RTCP
are not shown.
3.1 Intra-Enterprise Call
In this section, we consider calls between two users in the same
enterprise.
A STUN+TURN Server
|(1) STUN Bind |
|s=10.0.1.1:1010 |
|d=10.0.1.10:3478 |
|----------------------->|
|(2) STUN Resp |
|s=10.0.1.10:3478 |
|d=10.0.1.1:1010 |
|M=10.0.1.1:1010 |
|<-----------------------|
|(3) TURN Alloc |
|s=10.0.1.1:1010 |
|d=10.0.1.10:5556 |
|----------------------->|
|(4) TURN Resp |
|s=10.0.1.10:5556 |
|d=10.0.1.1:1010 |
|M=192.0.2.1:8076 |
|<-----------------------|
Figure 13: A's Unilateral Allocations
First, user A performs its unilateral allocations. This is shown in
Figure 13. The STUN allocation does not yield a new address, but the
TURN allocation, of course, does. The TURN address is publically
routable. As a result, the offer from A to B has two addresses, as
Rosenberg & Camarillo Expires January 17, 2005 [Page 23]
Internet-Draft ICE July 2004
shown in Figure 14.
v=0
o=alice 2890844730 2890844731 IN IP4 host.example.com
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 8076 RTP/AVP 0
a=alt:1 1.0 : user 9kksj== 10.0.1.1 1010
a=alt:2 0.5 : user1 9kksk== 192.0.2.1 8076
Figure 14: A's Offer
B receives this offer. It performs its own unilateral allocations,
shown in Figure 15.
B STUN+TURN Server
|(1) STUN Bind |
|s=10.0.1.2:23766 |
|d=10.0.1.10:3478 |
|----------------------->|
|(2) STUN Resp |
|s=10.0.1.10:3478 |
|d=10.0.1.2:23766 |
|M=10.0.1.2:23766 |
|<-----------------------|
|(3) TURN Alloc |
|s=10.0.1.2:23766 |
|d=10.0.1.10:5556 |
|----------------------->|
|(4) TURN Resp |
|s=10.0.1.10:5556 |
|d=10.0.1.2:23766 |
|M=192.0.2.1:8078 |
|<-----------------------|
Figure 15: B's Unilateral Allocations
The STUN derived transport address equals its local transport
address, so no additional addresses are obtained through that route.
TURN provided B with a public address. Next, B performs connectivity
checks against the two alternatives provided by A. These checks are
shown in Figure 16. The connectivity check to the alternate with ID
1, A's local transport address, succeeds, since both users are within
the same address realm. The connectivity to check to the alternate
with ID 2, which is the TURN server address on the public Internet,
Rosenberg & Camarillo Expires January 17, 2005 [Page 24]
Internet-Draft ICE July 2004
fails. This is because the NAT does not support receipt of requests
from internal hosts that are targeted towards internal bindings. As
a result, the STUN request is dropped by the NAT.
Because of its configuration, B also attempts to perform connectivity
checks by sending STUN Bind requests though its TURN relay, using the
TURN SEND command. As described in ICE, these connectivity checks
need to be performed sequentially, not in parallel. B first attempts
a send to deliver a STUN Bind request to A's local transport address
(message 4). This is relayed by the TURN server to A, using the
internal version of B's TURN derived transport address
(10.0.1.10:8078) as the source address (message 5). This is the
address that the NAT will translate 192.0.2.2:8078 into when it
receives packets externally. A replies to this (message 6),
reporting to B a new address, 10.0.1.10:8078. This is received by
the TURN server, causing lock down to occur. The TURN server
forwards this response back to B.
A TURN + STUN Server B NAT
|(1) STUN Bind| | |
|s=10.0.1.2:23766 | |
|d=10.0.1.1:1010 | |
|<--------------------------| |
| | | |
|(2) STUN Reply | |
|s=10.0.1.1:1010 | |
|d=10.0.1.2:23766 | |
|M=10.0.1.2:23766 | |
|-------------------------->| |
| | | |
| | | |
| | |(3) STUN Bind|
| | |s=10.0.1.2:23766
| | |d=192.0.2.1:8076
| | |------------>|
| | | |
| | | |
| | | |
| | | |
| | |Dropped by NAT
| | | |
| | | |
| |(4) TURN Send| |
| |s=10.0.1.2:23766 |
| |d=10.0.1.10:5556 |
| |T=10.0.1.1:1010 |
| |<------------| |
Rosenberg & Camarillo Expires January 17, 2005 [Page 25]
Internet-Draft ICE July 2004
| | | |
| | | |
|(5) STUN Bind| | |
|s=10.0.1.10:8078 | |
|d=10.0.1.1:1010 | |
|<------------| | |
| | | |
|(6) STUN Reply | |
|s=10.0.1.1:1010 | |
|d=10.0.1.10:8078 | |
|M=10.0.1.10:8078 | |
|------------>| | |
| | | |
| |(7) STUN Reply |
| |s=10.0.1.10:5556 |
| |d=10.0.1.2:23766 |
| |M=10.0.1.10:8078 |
| |------------>| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
Figure 16: B's Connectivity Test
Based on this, B generates the answer shown in Figure 17. Since B
has established connectivity to A's local transport address, it
begins sending media there.
v=0
o=bob 2890844730 289084871 IN IP4 host2.example.com
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 8078 RTP/AVP 0
a=alt:4 1.0 : peer as88jl 10.0.1.2 23766
a=alt:6 0.5 1 peer2 asjj8n 10.0.1.10 8078
a=alt:5 0.5 : peer1 as88kl 192.0.2.1 8078
Figure 17: B's Answer
Now, A performs its connectivity checks, shown in Figure 18. First,
it checks for connectivity to B's local transport address (message
1). This connectivity check passes, and does not provide A with a
Rosenberg & Camarillo Expires January 17, 2005 [Page 26]
Internet-Draft ICE July 2004
new address (message 2). Next, A checks for connectivity to
10.0.1.10:8078, the internal version of B's TURN derived transport
address. This connectivity check (messages 3-6) also succeed, and
provide A with a new peer derived transport address (10.0.1.10:5556).
However, this address would have a lower priority (0.5) than that of
one that B has already connected to (A's local transport address),
and so A does not bother with another ICE cycle. The check to B's
public TURN derived transport address fails (message 7). Since A
discovers connectivity to a high priority transport address, it does
not bother to perform its connectivity checks by relaying STUN
messages through its TURN server. Both A and B can now free their
TURN derived addresses, since both have established connectivity to
higher priority addresses. The call proceeds with media flowing
directly between A and B, as desired.
Note, however, that this call flow would not have worked if A
supported ICE, but B didn't. Thats because the default TURN address
will not work for internal clients. In enterprises where this is a
concern, an alternate deployment, described in Section 4, works
properly.
A TURN + STUN Server B NAT
|(1) STUN Bind | | |
|s=10.0.1.1:1010 | | |
|d=10.0.1.2:23766 | | |
|---------------------------------->| |
|(2) STUN Reply | | |
|s=10.0.1.2:23766 | | |
|d=10.0.1.1:1010 | | |
|M=10.0.1.1:1010 | | |
|<----------------------------------| |
|(3) STUN Bind | | |
|s=10.0.1.1:1010 | | |
|d=10.0.1.10:8078 | | |
|---------------->| | |
| |(4) STUN Bind | |
| |s=10.0.1.10:5556 | |
| |d=10.0.1.2:23766 | |
| |---------------->| |
| |(5) STUN Reply | |
| |s=10.0.1.2:23766 | |
| |d=10.0.1.10:5556 | |
| |M=10.0.1.10:5556 | |
| |<----------------| |
|(6) STUN Reply | | |
|s=10.0.1.10:8078 | | |
|d=10.0.1.1:1010 | | |
Rosenberg & Camarillo Expires January 17, 2005 [Page 27]
Internet-Draft ICE July 2004
|M=10.0.1.10:5556 | | |
|<----------------| | |
|(7) STUN Bind | | |
|s=10.0.1.1:1010 | | |
|d=192.0.2.1:8078 | | |
|---------------------------------------------------->|
| | |Dropped by NAT |
Figure 18: A's Connectivity Checks
3.2 Extra-Enterprise Call
In this case, user A within the enterprise calls some user B, not
within the enterprise. B is connected to the Internet through a PSTN
gateway, and as a result, appears as a UA on the public Internet.
Presumably this is some gateway run by a third party termination
provider that is being used by the enterprise. Furthermore, this
gateway does not support ICE at all, and so will ignore the alt
parameters in the SDP.
First, A performs its unilateral allocations. This proceeds
identically as shown in Figure 13. It generates the same offer as
shown in Figure 14. This gets routed to the called party on the
public Internet. This party generates an answer. However, since the
called party does not support ICE, the answer has no alt attributes.
It has a single IP address and port listed in the c and m lines. As
a result, the caller, A, needs to send media there. However, the
enterprise policy prohibits outbound UDP traffic from end user
devices. Thus, A has been configured to ensure outbound media flows
through the TURN server. ICE would normally discover this, and media
would flow that way. However, since ICE is not supported, it needs
to be done explicitly by the client.
To accomplish this, A performs another, separate unilateral
allocation to obtain another TURN address. It does not advertise
this address to the called party. Instead, it issues a TURN SEND
command to the IP address and port in the SDP answer. This send
command contains the first RTP packet to send. From that point
forward, A sends its media packets to the TURN server. The TURN
server will forward those packets to the last address used in a SEND
command, as long as lockdown has not occurred. Here, it will not,
since the address learned from the TURN server is never advertised to
any peers.
Rosenberg & Camarillo Expires January 17, 2005 [Page 28]
Internet-Draft ICE July 2004
3.3 Inter-Enterprise
In this case, a user in one enterprise calls a user in another
enterprise. In this configuration, media needs to flow through the
TURN relays run by both enterprises, since the policies of both
enterprises require this. We assume that B's enterprise is using
192.168/16 internally, and it has an external public IP address of
192.0.2.2. The TURN/STUN server is running on 192.168.1.10, using
port 3478 for STUN and 5556 for TURN. Packets sent to 192.0.2.2:6500
to 192.0.2.2:6600 are forwarded to 192.168.1.10:6500 to
192.168.1.10:6600 respectively.
First, A performs its allocations. These are identical to the ones
in Figure 13. The offer sent by A, as a result, is identical to
Figure 14.
This call is received by B. B performs its allocations, shown in
Figure 19. These are similar to those of Figure 15, differing only
in the addresses used.
B STUN+TURN Server
|(1) STUN Bind |
|s=192.168.1.1:1010 |
|d=192.168.1.10:3478 |
|----------------------->|
|(2) STUN Resp |
|s=192.168.1.10:3478 |
|d=192.168.1.1:1010 |
|M=192.168.1.1:1010 |
|<-----------------------|
|(3) TURN Alloc |
|s=192.168.1.1:1010 |
|d=192.168.1.10:5556 |
|----------------------->|
|(4) TURN Resp |
|s=192.168.1.10:5556 |
|d=192.168.1.1:1010 |
|M=192.0.2.2:6544 |
|<-----------------------|
Figure 19: B's Unilateral Allocations
Next, B performs its connectivity checks, as shown Figure 20. First,
B checks connectivity to A's local transport address (10.0.1.1:1010).
This is unroutable within B's network, and so the STUN request is
dropped by the routers in the network, and the check times out and
fails. In parallel, B checks connectivity to A's TURN derived
Rosenberg & Camarillo Expires January 17, 2005 [Page 29]
Internet-Draft ICE July 2004
transport address (192.0.2.1:8076). It sends a STUN Bind request to
this address (message 2). This arrives at B's firewall/NAT.
However, the firewall function does not allow outbound UDP packets
from internal clients, and so the packet is dropped. This check also
times out and fails. B also begins checking connectivity to A's two
addresses by SENDing the STUN requests through its TURN server.
First, B tries A's local transport address (message 3). This is
relayed by the TURN server to 10.0.1.1:1010, which is dropped by the
routers as well. Finally, B tries A's TURN derived transport address
(message 4). This is successfully relayed all the way to A, as a
result of the static bindings in place in A's and B's NATs. A sees a
source address of 10.0.1.10:5556, which it reports back in the STUN
reply. The STUN request (message 8) to A's TURN server locks down
the binding, and the STUN reply (message 13) locks down the binding
at B's TURN server. Based on the connectivity checks, B has learned
a single new peer derived transport address, 10.0.1.10:5556.
A T+S Srvr A's NAT B's NAT T+S Srvr B
| | | |(1) STUN Bind |
| | | |s=192.168.1.1:1010 |
| | | |d=10.0.1.1:1010 |
| | | |<----------------------|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |Timeout
| | | | | |
| | | | | |
| | | | | |
| | | |(2) STUN Bind |
| | | |s=192.168.1.1:1010 |
| | | |d=192.0.2.1:8076 |
| | | |<----------------------|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | |Dropped by NAT |
| | | | | |
| | | | | |
| | | | |(3) TURN Send
| | | | |s=192.168.1.1:1010
| | | | |d=192.168.1.10:5556
| | | | |T=10.0.1.1:1010
| | | | |<----------|
| | | | | |
Rosenberg & Camarillo Expires January 17, 2005 [Page 30]
Internet-Draft ICE July 2004
| | | | | |
| | | |(4) STUN Bind |
| | | |s=192.168.1.10:6544 |
| | | |d=10.0.1.1:1010 |
| | | |<----------| |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | |Dropped | |
| | | | | |
| | | | | |
| | | | |(5) TURN Send
| | | | |s=192.168.1.1:1010
| | | | |d=192.168.1.10:5556
| | | | |T=192.0.2.1:8076
| | | | |<----------|
| | | | | |
| | | | | |
| | | |(6) STUN Bind |
| | | |s=192.168.1.10:6544 |
| | | |d=192.0.2.1:8076 |
| | | |<----------| |
| | | | | |
| | | | | |
| | |(7) STUN Bind | |
| | |s=192.0.2.2:6544 | |
| | |d=192.0.2.1:8076 | |
| | |<----------| | |
| | | | | |
| | | | | |
| |(8) STUN Bind | | |
| |s=192.0.2.2:6544 | | |
| |d=10.0.1.10:8076 | | |
| |<----------| | | |
| | | | | |
| | | | | |
|(9) STUN Bind | | | |
|s=10.0.1.10:5556 | | | |
|d=10.0.1.1:1010 | | | |
|<----------| | | | |
| | | | | |
|(10) STUN Reply | | | |
|s=10.0.1.1:1010 | | | |
|d=10.0.1.10:5556 | | | |
|M=10.0.1.10:5556 | | | |
|---------->| | | | |
| | | | | |
Rosenberg & Camarillo Expires January 17, 2005 [Page 31]
Internet-Draft ICE July 2004
| |(11) STUN Reply | | |
| |s=10.0.1.10:8076 | | |
| |d=192.0.2.2:6544 | | |
| |M=10.0.1.10:5556 | | |
| |---------->| | | |
| | | | | |
| | |(12) STUN Reply | |
| | |s=192.0.2.1:8076 | |
| | |d=192.0.2.2:6544 | |
| | |M=10.0.1.10:5556 | |
| | |---------->| | |
| | | | | |
| | | |(13) STUN Reply |
| | | |s=192.0.2.1:8076 |
| | | |d=192.168.1.10:6544 |
| | | |M=10.0.1.10:5556 |
| | | |---------->| |
| | | | | |
| | | | |(14) STUN Reply
| | | | |s=192.168.1.10:5556
| | | | |d=192.168.1.1:1010
| | | | |M=10.0.1.10:5556
| | | | |---------->|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
Figure 20: B's Connectivity Test
B's connectivity check showed that the only place where media can be
sent is through its relay. Since the binding has been locked down, B
knows it can just send raw media packets to the relay, which will be
forwarded appropriately. As such, it begins sending media through
the relay pairs. B also generates its answer:
Rosenberg & Camarillo Expires January 17, 2005 [Page 32]
Internet-Draft ICE July 2004
v=0
o=bob 2890844730 289084871 IN IP4 host2.example.com
s=
c=IN IP4 192.0.2.2
t=0 0
m=audio 6544 RTP/AVP 0
a=alt:4 1.0 : peer as88jl 192.168.1.1 1010
a=alt:5 0.5 : peer1 as88kl 192.0.2.2 6544
a=alt:6 0.5 2 peer3 hh8sdl 10.0.1.10 5556
Now, A performs its connectivity checks, which are shown in Figure
22. These checks are similar to those of Figure 20. A's TURN server
relays the STUN request towards B's TURN server because of the
lock-down from B;s connectivity test. A's test reveals connectivity
to 10.0.1.10:5556, which is B's peer derived address. Since
connectivity was established there, A does not bother doing
connectivity checks by SENDing STUN requests through its TURN server.
The media proceeds to flow through both relays.
A T+S Srvr A's NAT B's NAT T+S Srvr B
|(1) STUN Bind | | | |
|s=10.0.1.1:1010 | | | |
|d=192.168.1.1:1010 | | | |
|---------------------->| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
|Dropped | | | | |
| | | | | |
| | | | | |
| | | | | |
|(2) STUN Bind | | | |
|s=10.0.1.1:1010 | | | |
|192.0.2.2:6544 | | | |
|---------------------->| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
|Dropped | | | | |
| | | | | |
| | | | | |
| | | | | |
|(3) STUN Bind | | | |
|s=10.0.1.1:1010 | | | |
|d=10.0.1.10:5556 | | | |
Rosenberg & Camarillo Expires January 17, 2005 [Page 33]
Internet-Draft ICE July 2004
|---------->| | | | |
| | | | | |
| | | | | |
| |(4) STUN Bind | | |
| |s=10.0.1.10:8076 | | |
| |d=192.0.2.2:6544 | | |
| |---------->| | | |
| | | | | |
| | | | | |
| | |(5) STUN Bind | |
| | |s=192.0.2.1:8076 | |
| | |d=192.0.2.2:6544 | |
| | |---------->| | |
| | | | | |
| | | | | |
| | | |(6) STUN Bind |
| | | |s=192.0.2.1:8076 |
| | | |d=192.168.1.10:6544 |
| | | |---------->| |
| | | | | |
| | | | | |
| | | | |(7) STUN Bind
| | | | |s=192.168.1.10:5556
| | | | |d=192.168.1.1:1010
| | | | |---------->|
| | | | | |
| | | | |(8) STUN Reply
| | | | |s=192.168.1.1:1010
| | | | |d=192.168.1.10:5556
| | | | |M=192.168.1.10:5556
| | | | |<----------|
| | | | | |
| | | |(9) STUN Reply |
| | | |s=192.168.1.10:6544 |
| | | |d=192.0.2.1:8076 |
| | | |M=192.168.1.10:5556 |
| | | |<----------| |
| | | | | |
| | |(10) STUN Reply | |
| | |s=192.0.2.2:6544 | |
| | |d=192.0.2.1:8076 | |
| | |M=192.168.1.10:5556 | |
| | |<----------| | |
| | | | | |
| |(11) STUN Reply | | |
| |s=192.0.2.2:6544 | | |
| |d=10.0.1.10:8076 | | |
| |M=192.168.1.10:5556 | | |
Rosenberg & Camarillo Expires January 17, 2005 [Page 34]
Internet-Draft ICE July 2004
| |<----------| | | |
| | | | | |
|(12) STUN Reply | | | |
|s=10.0.1.10:5556 | | | |
|d=10.0.1.1:1010 | | | |
|M=192.168.1.10:5556 | | | |
|<----------| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
Figure 22: A's Connectivity Checks
Rosenberg & Camarillo Expires January 17, 2005 [Page 35]
Internet-Draft ICE July 2004
4. Advanced Enterprise
The network of Section 3 describes a basic enterprise. It requires
the enterprise to configure port forwarding on a range of external
addresses, forwarding them to the internal TURN server. It also
requires that ICE be deployed within the whole enterprise, since the
default address won't work when talking to non-ICE clients within the
enterprise.
A more complex network design can be used in enterprises that refuse
to enable port forwarding/static bindings, and for which a
heterogeneous internal network is expected. The design of this
network is shown in Figure 23
+---------+
| TURN/ |
Public Internet | STUN |
| Server |
+---------+
192.0.2.1
+---------+
| |
----------------------| Firewall|--------------------------
| NAT |
10.0.0.0/16 +---------+ DMZ
+---------+ +---------+
| | | TURN/ |
| Proxy | | STUN |
| | | Server |
+---------+ +---------+
...........................................................
+----------+
| / \ |
+---------+ /SIP \ +----------+
| +---------+ /Phone \ | / \ |
Rosenberg & Camarillo Expires January 17, 2005 [Page 36]
Internet-Draft ICE July 2004
| | +---------+ / \ /SIP \
| | | | ------------ /Phone \
+-| | PC | / \
+-| | ------------
+---------+
Enterprise
Figure 23: Enterprise Configuration
In this network, there are two TURN servers. There is one internal
to the firewall, and one external. Clients only contact the internal
one directly. This TURN server authenticates the client, and then
obtains the public binding by sending a TURN request to the external
TURN server. The external TURN server returns a public address,
which is forwarded to the client by the internal TURN server. The
TURN query from the internal to external server creates a NAT binding
in the enterprise NAT, and therefore, static bindings are no longer
required. Authentication is done by the internal TURN server so that
the external server does not need to contact an internal database;
all database access is kept internal. The external TURN server still
authenticates the TURN query, but the authentication is done using a
configured username and password, configured into both the external
and internal servers. For security, that username and password can
be highly randomized and altered periodically - it is not used by end
users, but rather by network equipment.
TODO: Add call flows.
Rosenberg & Camarillo Expires January 17, 2005 [Page 37]
Internet-Draft ICE July 2004
5. Centrex
In a centrex scenario, a third party provider owns and operates the
SIP and TURN/STUN servers. The enterprise merely changes their
firewall configuration to allow SIP traffic out to port 5060 to the
provider's SIP proxy, and to allow TURN traffic out to port 5556 and
3478, on the provider's TURN/STUN server. The corporate NAT is
symmetric. The TURN/STUN server runs on 192.0.2.10. This scenario
is shown in Figure 24.
Provider Equipment
+---------+ +---------+
| | | TURN/ |
| Proxy | | STUN |
| | | Server |
+---------+ +---------+
Public
Internet
192.0.2.1
+---------+
| |
----------------------| Firewall|--------------------------
| NAT |
10.0.0.0/16 +---------+
+----------+
| / \ |
+---------+ /SIP \ +----------+
| +---------+ /Phone \ | / \ |
| | +---------+ / \ /SIP \
| | | | ------------ /Phone \
+-| | PC | / \
+-| | ------------
+---------+
Enterprise
Rosenberg & Camarillo Expires January 17, 2005 [Page 38]
Internet-Draft ICE July 2004
Figure 24: Centrex Configuration
5.1 Intra-Enterprise Call
In this scenario, user A calls user B. Both are within the
enterprise. First, A performs its unilateral allocations. These are
shown in Figure 25. These yield a STUN derived transport address and
a TURN derived transport address. A sends these in the offer shown
in Figure 26.
A Corp. NAT STUN+TURN Server
|(1) STUN Bind | |
|s=10.0.1.1:1010 | |
|d=192.0.2.10:3478 | |
|----------------------->| |
| |(2) STUN Bind |
| |s=192.0.2.1:9988 |
| |d=192.0.2.10:3478 |
| |----------------------->|
| |(3) STUN Resp |
| |s=192.0.2.10:3478 |
| |d=192.0.2.1:9988 |
| |M=192.0.2.1:9988 |
| |<-----------------------|
|(4) STUN Resp | |
|s=192.0.2.10:3478 | |
|d=10.0.1.1:1010 | |
|M=192.0.2.1:9988 | |
|<-----------------------| |
|(5) TURN Alloc | |
|s=10.0.1.1:1010 | |
|d=192.0.2.10:5556 | |
|----------------------->| |
| |(6) TURN Alloc |
| |s=192.0.2.1:9989 |
| |d=192.0.2.10:5556 |
| |----------------------->|
| |(7) TURN Resp |
| |s=192.0.2.10:5556 |
| |d=192.0.1.1:9989 |
| |M=192.0.2.10:8076 |
| |<-----------------------|
|(8) TURN Resp | |
|s=192.0.2.10:5556 | |
|d=10.0.1.1:1010 | |
|M=192.0.2.10:8076 | |
Rosenberg & Camarillo Expires January 17, 2005 [Page 39]
Internet-Draft ICE July 2004
|<-----------------------| |
Figure 25: A's Unilateral Allocations
v=0
o=alice 2890844730 2890844731 IN IP4 host.example.com
s=
c=IN IP4 192.0.2.10
t=0 0
m=audio 8076 RTP/AVP 0
a=alt:1 1.0 : user 9kksj== 10.0.1.1 1010
a=alt:2 0.5 : user1 9kksk== 192.0.2.1 9988
a=alt:3 0.4 : user2 9kksl== 192.0.2.10 8076
Figure 26: A's Offer
This offer is received by B. B performs its unilateral allocations,
shown in Figure 27. These yield a STUN derived and TURN derived
transport address.
B Corp. NAT STUN+TURN Server
|(1) STUN Bind | |
|s=10.0.1.2:23766 | |
|d=192.0.2.10:3478 | |
|----------------------->| |
| |(2) STUN Bind |
| |s=192.0.2.1:9990 |
| |d=192.0.2.10:3478 |
| |----------------------->|
| |(3) STUN Resp |
| |s=192.0.2.10:3478 |
| |d=192.0.2.1:9990 |
| |M=192.0.2.1:9990 |
| |<-----------------------|
|(4) STUN Resp | |
|s=192.0.2.10:3478 | |
|d=10.0.1.2:23766 | |
|M=192.0.2.1:9990 | |
|<-----------------------| |
|(5) TURN Alloc | |
|s=10.0.1.2:23766 | |
|d=192.0.2.10:5556 | |
|----------------------->| |
| |(6) TURN Alloc |
| |s=192.0.2.1:9991 |
Rosenberg & Camarillo Expires January 17, 2005 [Page 40]
Internet-Draft ICE July 2004
| |d=192.0.2.10:5556 |
| |----------------------->|
| |(7) TURN Resp |
| |s=192.0.2.10:5556 |
| |d=192.0.2.1:9991 |
| |M=192.0.2.10:8078 |
| |<-----------------------|
|(8) TURN Resp | |
|s=192.0.2.10:5556 | |
|d=10.0.1.2:23766 | |
|M=192.0.2.10:8078 | |
|<-----------------------| |
Figure 27: B's Unilateral Allocations
Now, B begins its connectivity checks, as shown in Figure 28. The
first check (message 1), to A's local transport address,
10.0.1.1:1010, succeeds, since A and B are behind the same NAT. The
second check, to A's STUN derived transport address, fails, since the
enterprise NAT won't turn around packets. The third check, to A's
TURN derived transport address, 192.0.2.10:8076, also succeeds, and
yields B a new peer derived transport address, 192.0.2.10:5556.
A B Corp. NAT TURN + STUN Server
|(1) STUN Bind | | |
|s=10.0.1.2:23766| | |
|d=10.0.1.1:1010 | | |
|<---------------| | |
|(2) STUN Reply | | |
|s=10.0.1.1:1010 | | |
|d=10.0.1.2:23766| | |
|M=10.0.1.2:23766| | |
|--------------->| | |
| |(3) STUN Bind | |
| |s=10.0.1.2:23766| |
| |d=192.0.2.1:9988| |
| |--------------->| |
| | |Dropped |
| |(4) STUN Bind | |
| |s=10.0.1.2:23766| |
| |d=192.0.2.10:8076 |
| |--------------->| |
| | |(5) STUN Bind |
| | |s=192.0.2.1:9992|
| | |d=192.0.2.10:8076
| | |--------------->|
| | |(6) STUN Bind |
Rosenberg & Camarillo Expires January 17, 2005 [Page 41]
Internet-Draft ICE July 2004
| | |s=192.0.2.10:5556
| | |d=192.0.2.1:9988|
| | |<---------------|
|(7) STUN Bind | | |
|s=192.0.2.10:5556 | |
|d=10.0.1.1:1010 | | |
|<--------------------------------| |
|(8) STUN Reply | | |
|s=10.0.1.1:1010 | | |
|d=192.0.2.10:5556 | |
|M=192.0.2.10:5556 | |
|-------------------------------->| |
| | |(9) STUN Reply |
| | |s=192.0.2.1:9988|
| | |d=192.0.2.10:5556
| | |M=192.0.2.10:5556
| | |--------------->|
| | |(10) STUN Reply |
| | |s=192.0.2.10:8076
| | |d=192.0.2.1:9992|
| | |M=192.0.2.10:5556
| | |<---------------|
| |(11) STUN Reply | |
| |s=192.0.2.10:8076 |
| |d=10.0.1.2:23766| |
| |M=192.0.2.10:5556 |
| |<---------------| |
Figure 28: B's Connectivity Checks
B can now send media to A directly. It also generates an answer,
shown in Figure 29.
Rosenberg & Camarillo Expires January 17, 2005 [Page 42]
Internet-Draft ICE July 2004
v=0
o=bob 2890844730 289084871 IN IP4 host2.example.com
s=
c=IN IP4 192.0.2.10
t=0 0
m=audio 8078 RTP/AVP 0
a=alt:4 1.0 : peer as88jl 10.0.1.2 23766
a=alt:5 0.8 : peer1 as88kl 192.0.2.1 9990
a=alt:6 0.4 : peer2 as88ll 192.0.2.10 8078
a=alt:7 0.4 : peer3 as88ml 192.0.2.10 5556
Figure 29: B's Answer
This arrives at A. A is able to send media immediately to B using
the default, 192.0.2.10:8078. It also starts its connectivity checks
to find a better choice. These checks are shown in Figure 30. As
expected, the check for connectivity to 10.0.1.2:23766 succeeds,
representing the highest priority address. The check to
192.0.2.1:9990 fails, because the NAT won't turn around internal
packets. The checks to 192.0.2.10:8078 and 192.0.2.10:5556 succeed,
and the former resuls in a peer-derived transport address of
192.0.2.10:5556. However, A knows that B has already connected to a
higher priority address, so it doesn't bother with an additional
offer/answer exchange.
A B Corp. NAT TURN + STUN Server
|(1) STUN Bind | | |
|s=10.0.1.1:1010 | | |
|d=10.0.1.2:23766 | | |
|---------------->| | |
|(2) STUN Reply | | |
|s=10.0.1.2:23766 | | |
|d=10.0.1.1:1010 | | |
|M=10.0.1.1:1010 | | |
|<----------------| | |
|(3) STUN Bind | | |
|s=10.0.1.1:1010 | | |
|d=192.0.2.1:9990 | | |
|---------------------------------->| |
| | |Dropped |
|(4) STUN Bind | | |
|s=10.0.1.1:1010 | | |
|d=192.0.2.10:8078| | |
|---------------------------------->| |
| | |(5) STUN Bind |
| | |s=192.0.2.1:9992 |
| | |d=192.0.2.10:8078|
Rosenberg & Camarillo Expires January 17, 2005 [Page 43]
Internet-Draft ICE July 2004
| | |---------------->|
| | |(6) STUN Bind |
| | |s=192.0.2.10:5556|
| | |d=192.0.2.1:9991 |
| | |<----------------|
| |(7) STUN Bind | |
| |s=192.0.2.10:5556| |
| |d=10.0.1.2:23766 | |
| |<----------------| |
| |(8) STUN Reply | |
| |s=10.0.1.2:23766 | |
| |d=192.0.2.10:5556| |
| |M=192.0.2.10:5556| |
| |---------------->| |
| | |(9) STUN Reply |
| | |s=192.0.2.1:9991 |
| | |d=192.0.2.10:5556|
| | |M=192.0.2.10:5556|
| | |---------------->|
| | |(10) STUN Reply |
| | |s=192.0.2.10:8078|
| | |d=192.0.2.1:9992 |
| | |M=192.0.2.10:5556|
| | |<----------------|
|(11) STUN Reply | | |
|s=192.0.2.10:8078| | |
|d=10.0.1.1:1010 | | |
|M=192.0.2.10:5556| | |
|<----------------------------------| |
|(12) STUN Bind | | |
|s=10.0.1.1:1010 | | |
|d=192.0.2.10:5556| | |
|---------------------------------->| |
| | |(13) STUN Bind |
| | |s=192.0.2.1:9989 |
| | |d=192.0.2.10:5556|
| | |---------------->|
| | |(14) STUN Bind |
| | |s=192.0.2.10:8076|
| | |d=192.0.2.1:9991 |
| | |<----------------|
| |(15) STUN Bind | |
| |s=192.0.2.10:8076| |
| |d=10.0.1.2:23766 | |
| |<----------------| |
| |(16) STUN Reply | |
| |s=10.0.1.2:23766 | |
| |d=192.0.2.10:8076| |
Rosenberg & Camarillo Expires January 17, 2005 [Page 44]
Internet-Draft ICE July 2004
| |M=192.0.2.10:8076| |
| |---------------->| |
| | |(17) STUN Reply |
| | |s=192.0.2.1:9991 |
| | |d=192.0.2.10:8076|
| | |M=192.0.2.10:8076|
| | |---------------->|
| | |(18) STUN Reply |
| | |s=192.0.2.10:5556|
| | |d=192.0.2.1:9989 |
| | |M=192.0.2.10:8076|
| | |<----------------|
|(19) STUN Reply | | |
|s=192.0.2.10:5556| | |
|d=10.0.1.1:1010 | | |
|M=192.0.2.10:8076| | |
|<----------------------------------| |
Figure 30: A's Connectivity Checks
The conclusion is that A and B communicate directly, without using
the provider's relay. They can proceed to de-allocate the TURN
addresses once the call is active.
Rosenberg & Camarillo Expires January 17, 2005 [Page 45]
Internet-Draft ICE July 2004
6. An IPv6 Network with a pool of IPv4 addresses
+----------+
| / \ |
Residential /SIP \
Customer /Phone \
/ \
------------
10.0.0.0/16
+---------+
| |
----------------------| NAT |--------------------------
| |
+---------+
192.0.1.0/16
Public Internet
192.0.0.0/16
+---------+
| |
----------------------| NAT |--------------------------
| |
+---------+
IPv6 Network PREFIX::/96
++
||
+-----++
| IPv6 |
| SIP |
| user |
| agent|
+------+
Figure 31
This example deals with a network of IPv6 SIP user agents that has a
NAT with a pool of public IPv4 addresses, as shown in Figure 31. The
NAT advertises the prefix PREFIX::/96 in the IPv6 network, so all
Rosenberg & Camarillo Expires January 17, 2005 [Page 46]
Internet-Draft ICE July 2004
packets addresses to that PREFIX are routed to the NAT, as described
in RFC 2766 [9]. The IPv6 SIP user agents of this IPv6 network need
to communicate with users on the IPv4 Internet and with residential
users behind a NAT (i.e., with private IPv4 addresses), even if those
residential users do not have access to any STUN or TURN servers. It
is assumed, though, that the residential users can run STUN servers
on their ports.
For a particular session, a given IPv6 SIP user agent can obtain the
services from the NAT. The NAT receives IP packets from the IPv6 SIP
terminal on an IPv6 address and forwards them to the peer's IPv4
address (as seen from the NAT). It also receives packets from the
peer on an IPv4 address and forwards them to the IPv6 address of the
IPv6 SIP user agent.
This scenario is different from the residential user scenario
described in Section 2 because the IPv6 terminal needs to communicate
with the NAT to obtain a public IPv4 address to place in its offer
and answers. This is because residential users would not understand
IPv6 addresses in the SDP. The way the IPv6 SIP user agent obtains
this IPv4 address is outside the scope of this document.
The 3G IP Multimedia Subsystem (IMS) has the characteristics just
described. A solution that allows IPv6 IMS terminals to communicate
with Internet users where the terminals obtain the public IPv4
address from the NAT using session policies is described in [10].
6.1 Initial Offer Generated by the IPv6 SIP User Agent
In this example, an IPv6 SIP user agent sends an offer to a
residential user that is located behind a NAT. Before generating an
offer, the IPv6 SIP user agent obtains a public IPv4 address from the
NAT. The IPv6 SIP user agent groups both addresses (its IPv6 address
and the public IPv4 address that it just obtained) using the IPV
semantics [11] and places them in its offer, which is shown in Figure
32.
v=0
o=bob 280744730 28977631 IN IP6 host.example.com
s=
t=0 0
a=group:IPV 1 2
m=audio 6886 RTP/AVP 0
c=IN IP6 2001:056D::112E:144A:1E24
a=mid:1
m=audio 22334 RTP/AVP 0
c=IN IP4 192.0.0.1
Rosenberg & Camarillo Expires January 17, 2005 [Page 47]
Internet-Draft ICE July 2004
a=mid:2
a=alt:1 1.0 : user 9kksj== 192.0.0.1 22334
Figure 32
When the residential user receives the offer in Figure 32, it uses
STUN to obtain new addresses to place in its answer, as shown in
Figure 33. The IPv6 SIP user agent responds to the residential
user's STUN Bind messages with a STUN reply. This STUN reply carries
a new address (192.0.1.1:2000), which the residential user places in
its answer, shown in Figure 34. The answer indicates that this
address has been derived from the alternative number 1 in the offer.
Since the residential user does not support IPv6, it sets the port
number of the media stream with the IPv6 address to zero.
IPv6 NAT Bs NAT B
| | | |
| | |(1) STUN Bind|
| | |s=10.0.0.1:20000
| | |d=192.0.0.1:22334
| | |<------------|
| |(2) STUN Bind| |
| |s=192.0.1.1:20000 |
| |d=192.0.0.1:22334 |
| |<------------| |
|(3) STUN Bind| | |
|s=PREFIX::192.0.1.1/20000 | |
|d=2001:056D::112E:144A:1E24| |
|<------------| | |
|(4) STUN Reply | |
|s=2001:056D::112E:144A:1E24| |
|d=PREFIX::192.0.1.1/20000 | |
|M=192.0.1.1:20000 | |
|------------>| | |
| | |
| |(5) STUN Reply |
| |s=192.0.0.1:22334 |
| |d=192.0.1.1:20000 |
| |M=192.0.1.1:20000 |
| |------------>| |
| | |(6) STUN Reply
| | |s=192.0.0.1:22334
| | |d=10.0.0.1:20000
| | |M=192.0.1.1:20000
| | |------------>|
| | | |
Rosenberg & Camarillo Expires January 17, 2005 [Page 48]
Internet-Draft ICE July 2004
Figure 33
v=0
o=alice 280756730 28956631 IN IP4 host.example2.com
s=
t=0 0
m=audio 0 RTP/AVP 0
m=audio 20000 RTP/AVP 0
c=IN IP4 10.0.0.1
a=alt:2 1.0 : peer as88jl 10.0.0.1 20000
a=alt:3 0.8 1 peer as88kl 192.0.1.1 20000
Figure 34
When the IPv6 SIP user agent receives the answer, it uses STUN to
check both addresses, 10.0.0.1:20000 and 192.0.1.1:20000. When it
does so, it discovers that 10.0.0.1:20000 is unreachable and that
192.0.1.1:2000 can be used to send media to the peer.
Alternatively, the IPv6 SIP user agent could take advantage of
knowing that its own IPv4 address is public and deduct which peer
address to use without using STUN. If the answer contains an
address which was derived from an alternative in the offer, that
address will have best connectivity. If the answer does not
contain any derived address, it means that the peer has a local
public IPv4 address, which will be the alternative with highest
priority in the answer.
6.2 Initial Offer Generated by the Residential User
In this example, a residential user that is located behind a NAT
sends an offer to the IPv6 SIP user agent. The residential user
places its local IPv4 address in the offer, as shown in Figure 35.
v=0
o=alice 280756730 28956631 IN IP4 host.example2.com
s=
t=0 0
m=audio 20000 RTP/AVP 0
c=IN IP4 10.0.0.1
a=alt:1 1.0 : peer as88jl 10.0.0.1 20000
Figure 35
The IPv6 SIP user agent uses STUN towards 10.0.0.1, which is
unreachable. Consequently, no new addresses are discovered.
Rosenberg & Camarillo Expires January 17, 2005 [Page 49]
Internet-Draft ICE July 2004
Alternatively, the IPv6 SIP user agent can skip using STUN at this
point, since it knows that its NAT provides public IPv4 addresses.
It does not really have any need to discover any new addresses.
The IPv6 SIP user agent places a public IPv4 address that it obtains
from the NAT in its answer, as shown in Figure 36.
v=0
o=bob 280744730 28944631 IN IP6 host.example.com
s=
t=0 0
m=audio 22334 RTP/AVP 0
c=IN IP4 192.0.0.1
a=alt:2 1.0 : user 9kksj== 192.0.0.1 22334
Figure 36
When the residential user receives the answer from the IPv6 SIP user
agent, it uses STUN to discover its IP address as seen by its peer
(192.0.1.1:20000). The call flow is idential to the one shown in
Figure 33. Then, it sends a new offer, which is shown in Figure 37.
v=0
o=alice 280756730 28956632 IN IP4 host.example2.com
s=
t=0 0
m=audio 20000 RTP/AVP 0
c=IN IP4 10.0.0.1
a=alt:1 1.0 : peer as88jl 10.0.0.1 20000
a=alt:3 0.8 2 peer as88kl 192.0.1.1 20000
Figure 37
When the IPv6 SIP user agent receives the offer in Figure 37, it uses
STUN to check both addresses, 10.0.0.1:20000 and 192.0.1.1:20000.
When it does so, it discovers that 10.0.0.1:20000 is unreachable and
that 192.0.1.1:2000 can be used to send media to the peer.
Alternatively, the IPv6 SIP user agent could take advantage of
knowing that its own IPv4 address is public and deduct which peer
address to use without using STUN. If the answer contains an
address which was derived from an alternative in the offer, that
address will have best connectivity. If the answer does not
contain any derived address, it means that the peer has a local
public IPv4 address, which will be the alternative with highest
priority in the answer.
Rosenberg & Camarillo Expires January 17, 2005 [Page 50]
Internet-Draft ICE July 2004
At this point, the IPv6 SIP user agent sends back and answer that
only differs from its previous answer (shown in Figure 36) in the
version number (o= field).
Rosenberg & Camarillo Expires January 17, 2005 [Page 51]
Internet-Draft ICE July 2004
7. Security Considerations
TODO.
Rosenberg & Camarillo Expires January 17, 2005 [Page 52]
Internet-Draft ICE July 2004
8. IANA Considerations
There are no IANA considerations associated with this specification.
Rosenberg & Camarillo Expires January 17, 2005 [Page 53]
Internet-Draft ICE July 2004
9. Acknowledgements
The authors would like to thank Douglas Otis, Karim El Malki and
Francois Audet for their comments and input.
10 Informative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Senie, D., "Network Address Translator (NAT)-Friendly
Application Design Guidelines", RFC 3235, January 2002.
[3] Rosenberg, J. and H. Schulzrinne, "An Extension to the Session
Initiation Protocol (SIP) for Symmetric Response Routing", RFC
3581, August 2003.
[4] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Methodology for Nettwork Address Translator (NAT) Traversal
for the Session Initiation Protocol (SIP)",
draft-rosenberg-sipping-ice-01 (work in progress), July 2003.
[5] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[6] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN -
Simple Traversal of User Datagram Protocol (UDP) Through
Network Address Translators (NATs)", RFC 3489, March 2003.
[7] Rosenberg, J., "Traversal Using Relay NAT (TURN)",
draft-rosenberg-midcom-turn-04 (work in progress), February
2004.
[8] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
3550, July 2003.
[9] Tsirtsis, G. and P. Srisuresh, "Network Address Translation -
Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[10] Malki, K., "IPv6-IPv4 Translators in 3GPP Networks",
draft-elmalki-v6ops-3gpp-translator-00 (work in progress), June
2003.
[11] Camarillo, G. and J. Rosenberg, "The Alternative Semantics for
the Session Description Protocol Grouping Framework",
draft-camarillo-mmusic-alt-02 (work in progress), October 2003.
Rosenberg & Camarillo Expires January 17, 2005 [Page 54]
Internet-Draft ICE July 2004
Authors' Addresses
Jonathan Rosenberg
dynamicsoft
600 Lanidex Plaza
Parsippany, NJ 07054
US
Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com
URI: http://www.jdrosen.net
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: Gonzalo.Camarillo@ericsson.com
Rosenberg & Camarillo Expires January 17, 2005 [Page 55]
Internet-Draft ICE July 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Rosenberg & Camarillo Expires January 17, 2005 [Page 56]