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

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