draft-ietf-sipping-nat-scenarios-00.txt   draft-ietf-sipping-nat-scenarios-01.txt 
SIPPING Working Group C. Boulton
Internet-Draft Ubiquity Software
Expires: April 25, 2005 J. Rosenberg
Cisco Systems
October 25, 2004
Internet Engineering Task Force SIPPING WG Best Current Practices for NAT Traversal for SIP
Internet Draft J. Rosenberg draft-ietf-sipping-nat-scenarios-01
dynamicsoft
R. Mahy
Cisco
S. Sen
Nortel
draft-ietf-sipping-nat-scenarios-00.txt
June 24, 2002
Expires: December 2002
NAT and Firewall Scenarios and Solutions for SIP
STATUS OF THIS MEMO Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she 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 Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as
Drafts. 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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt.
To view the list Internet-Draft Shadow Directories, see The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 25, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract Abstract
The problem of firewall and nat traversal for SIP is a complex one, Traversal of the Session Initiation Protocol (SIP) and the sessions
due, in part, to the large number of different scenarios and the it establishes through Network Address Translators (NAT) is a complex
multitude of solutions developed to solve them. In this draft, we problem. Currently there are many deployment scenarios and traversal
enumerate the various scenarios which can arise, and for each, point mechanisms for media traffic. This document aims to provide concrete
to some of the existing solutions for that scenario, and present call recommendations and a unified method for NAT traversal as well as
flows and explanations for how it works. documenting corresponding call flows.
Table of Contents Table of Contents
1 Introduction ........................................ 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Scenario I: Residence with single NAT ............... 4 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Solution I: Configuration ........................... 5 3. Solution Technology Outline Description . . . . . . . . . . . 6
2.2 Solution II: Stun in Client ......................... 8 3.1 SIP Signaling . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Not Symmetric NAT ................................... 9 3.1.1 Symmetric Response . . . . . . . . . . . . . . . . . . 7
2.2.1.1 Registration ........................................ 9 3.1.2 Connection Re-use . . . . . . . . . . . . . . . . . . 8
2.2.1.2 Registration: TCP ................................... 9 3.2 Media Traversal . . . . . . . . . . . . . . . . . . . . . 8
2.2.1.3 Registration: STUN .................................. 10 3.2.1 Symmetric RTP . . . . . . . . . . . . . . . . . . . . 8
2.2.1.4 Registration: UDP, no STUN .......................... 10 3.2.2 STUN . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1.5 Initiating a Session ................................ 12 3.2.3 TURN . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1.6 Receiving an Invitation to a Session ................ 15 3.2.4 ICE . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1.7 Media Flow .......................................... 16 3.2.5 RTCP Attribute . . . . . . . . . . . . . . . . . . . . 10
2.2.2 Symmetric NAT ....................................... 18 3.2.6 Solution Profiles . . . . . . . . . . . . . . . . . . 10
2.2.2.1 Registration ........................................ 20 4. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . . . 11
2.2.2.2 Initiating a Session ................................ 21 4.1 Basic NAT SIP Signaling Traversal . . . . . . . . . . . . 11
2.2.2.3 Answering an Invitation to a Session ................ 22 4.1.1 Registration (Registrar/Proxy Co-Located . . . . . . . 11
2.2.2.4 Media Flows ......................................... 25 4.1.2 Registration(Registrar/Proxy not Co-Located) . . . . . 15
2.3 Solution III: STUN in B2BUA ......................... 26 4.1.3 Initiating a Session . . . . . . . . . . . . . . . . . 16
2.3.1 Registration ........................................ 26 4.1.4 Receiving an Invitation to a Session . . . . . . . . . 18
2.3.2 Initiating a Session ................................ 30 4.2 Basic NAT Media Traversal . . . . . . . . . . . . . . . . 21
2.3.3 Receiving an Invitation to a Session ................ 33 4.2.1 Full Cone NAT . . . . . . . . . . . . . . . . . . . . 21
2.4 Solution IV: ALG .................................... 34 4.2.2 Port Restricted Cone NAT . . . . . . . . . . . . . . . 21
3 Uncooperative Enterprise ............................ 37 4.2.3 Symmetric NAT . . . . . . . . . . . . . . . . . . . . 21
4 Cooperative Enterprise .............................. 37 4.3 Advanced NAT media Traversal Using ICE . . . . . . . . . . 22
4.1 Solution I: ALG ..................................... 37 4.3.1 Full Cone --> Full Cone traversal . . . . . . . . . . 22
4.2 Solution II: MIDCOM Firewall and Proxy .............. 40 4.3.2 Port Restricted Cone --> Port Restricted Cone
4.3 Solution III: Internal B2BUAWM ...................... 40 traversal . . . . . . . . . . . . . . . . . . . . . . 22
5 Outsourced Service: Centrex ......................... 43 4.3.3 Internal TURN Server (Enterprise Deployment) . . . . . 22
5.1 Solution I: ALG ..................................... 43 4.4 Intercepting Intermediary (B2BUA) . . . . . . . . . . . . 22
5.2 Solution II: External B2BUAWM ....................... 46 4.5 IPV4/IPV6 . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2.1 Signaling Path ...................................... 47 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2.2 Media Path: The Case for RTP (Media) Proxy .......... 49 5.1 Normative References . . . . . . . . . . . . . . . . . . . . 23
5.3 Solution III: Outsourced MIDCOM ..................... 52 5.2 Informative References . . . . . . . . . . . . . . . . . . . 24
5.4 Solution IV: STUN and TURN .......................... 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
6 Comparing the Approaches ............................ 54 Intellectual Property and Copyright Statements . . . . . . . . 25
7 Changes since draft-rosenberg-sipping-nat-
scenarios-00 ................................................... 56
8 Future Work ......................................... 57
9 Acknowledgements .................................... 57
10 Authors Addresses ................................... 57
11 Normative References ................................ 57
12 Informative References .............................. 58
1 Introduction 1. Introduction
The problem of firewall and NAT traversal is one that receives a very NAT (Network Address Translators) traversal has long been identified
large amount of attention. It is particularly troublesome for as a large problem when considered in the context of the Session
interactive communications, such as those established and managed by Initiation Protocol (SIP)[1] and it's associated media such as Real
SIP [1]. A host of solutions have been proposed and discussed, Time Protocol (RTP)[2]. The problem is further confused by the
including the Simple Traversal of UDP Through NAT (STUN) protocol variety of NATs that are available in the market place today and the
[2], Traversal Using Relay NAT (TURN) [3], SIP ALGs [4] [5] [6], the large number of potential deployment scenarios. Detail of different
MIDCOM protocol [7], SDP extensions for NAT [8], SIP extensions for NAT types can be found in RFC 3489bis [13].
NAT [9], RSIP [10] [11], MGCP controlled firewalls [12], tunnels of
various flavors [13], and even an April Fools RFC, RFC 3093 [14],
which many people have taken quite seriously.
This is further complicated by the variety of scenarios that are The IETF has produced many specifications for the traversal of NAT,
frequently discussed, including service providers, enterprise, including STUN, ICE, rport, symmetric RTP, TURN, connection reuse,
centrex, residential, nats alone, nats and firewalls, firewalls SDP attribute for RTCP, and others. These each represent a part of
alone, and so on. the solution, but none of them gives the overall context for how the
NAT traversal problem is decomposed and solved through this
collection of specifications. This document serves to meet that
need.
All of this is the source of unending confusion. For the novice This document attempts to provide a definitive set of 'Best Common
wishing to understand how to solve the "nat problem", it is a nearly Practices' to demonstrate the traversal of SIP and it's associated
insurmountable hurdle to sort through these drafts and scenarios, to media through NAT devices. The document does not propose any new
put together a coherent view of the options at hand. functionality but does draw on existing solutions for both core SIP
signaling and media traversal (as defined in section 3).
This draft is a first attempt to resolve that problem. We enumerate The draft will be split into distinct sections as follows:
what we believe is a comprehensive set of scenarios that have been 1. A clear definition of the problem statement
discussed, and for each scenario, describe some of the solutions and 2. Description of proposed solutions for both SIP protocol signaling
the drafts that would be needed to make them work. Our solution sets and media signaling
are not complete, as they omit discussion of approaches such as RSIP 3. A set of basic and advanced call flow scenarios
and VPN. Those are coming in a future revision. We have also omitted
a good comparison of the solutions, which will also be present in a
future revision.
The scenarios that are considered include (1) a user behind a 2. Problem Statement
residential NAT/FW using a public service provider's VoIP service
(Section 2), (2) a user within an enterprise that wants to use the
services of a VoIP provider on the public Internet, but whose
enterprise is not supporting the service (Section 3), (3) a user
within an enterprise that is deploying VoIP itself, and is not using
any VoIP provider (Section 4), and (4) a user within an enterprise
that is providing VoIP services, but is doing so by outsourcing the
service to a public provider. This is effectively a Centrex approach.
(Section 5).
2 Scenario I: Residence with single NAT The traversal of SIP through NAT can be split into two categories
that both require attention - The core SIP signaling and associated
media traversal.
In this scenario, a user has a broadband connection to the Internet, The core SIP signaling has a number of issues when traversing through
using a cable modem or DSL, for example. In order to provide NATs.
security, or to run multiple machines, the user has purchased an
off-the-shelf "DSL Router" as they are called. These devices,
manufactured by companies such as Linksys, Netgear, 2wire, and
Netopia, generally include a NAT, simple firewall, DHCP server and
client, and a built in ethernet switch of some sort. The firewall
generally allows all outgoing traffic, but disallows incoming traffic
unless specific port forwarding or a DMZ host has been configured.
The NAT treatment of UDP in these boxes varies. The most common types
appear to be full-cone and restricted cone. See [15] for a definition
of these terms.
The user in this scenario wishes to use a communications service from Firstly, the default operation for SIP response generation using
a retail provider, such as net2phone or deltathree, for example. The unreliable protocols such as the Unicast Datagram Protocol (UDP)
connection between the user and the provider is through the cable results in responses being generated at the User Agent Server (UAS)
modem or DSL, through the public Internet. The user may have multiple being sent to the source address, as specified in either the SIP
PCs in their home accessing this service, but they are not related in 'Via' header or the 'received' parameter (as defined in RFC 3261
any way. This scenario also includes the case where its not a PC, but [1]). The port is extracted from the SIP 'Via' header to complete
a standalone SIP phone. In this case, the provider might be providing the IP address/port combination for returning the SIP response.
some kind of second line VoIP service. While the destination is correct, the port contained in the SIP 'Via'
header represents the listening port of the originating client and
not the port representing the open pin hole on the NAT. This results
responses being sent back to the NAT but to a port that is likely not
open for SIP traffic. The SIP response will then be dropped at the
NAT. This is illustrated in Figure 1 which depicts a SIP response
being returned to port 5060.
This scenario is depicted in Figure 1. Private Network NAT Public Network
|
|
|
-------- SIP Request |open port 5650 --------
| |----------------------->--->-----------------------| |
| | | | |
| Client | |port 5060 SIP Response | Proxy |
| | x<------------------------| |
| | | | |
-------- | --------
|
|
|
2.1 Solution I: Configuration Figure 1
The most simplistic solution for this case is to configure the NAT Secondly, when using a reliable, connection orientated transport
and the PC or softphone to allow for service. protocol such as TCP, SIP has an inherent mechanism that results in
SIP responses reusing the connection that was created/used for the
corresponding transactional request. The SIP protocol does not
provide a mechanism that allows new requests generated in the
opposite direction (Previously occupying the role of UAS for the last
transaction) to use the existing TCP connection created between the
client and the server during registration. This results in the
registered contact address not being bound to the "connection" in the
case of TCP. Requests are then blocked at the NAT, as illustrated in
Figure 2. This problem also exists for unreliable transport
protocols such as UDP where external NAT mappings need to be re-used
to reach a SIP entity on the private side of the network.
Most residential NATs allow the NAT to be configured with a DMZ host. Private Network NAT Public Network
This is a host that will receive all incoming packets that are not |
associated with some kind of outgoing connection established |
previously. The NAT also allows the user to find out the IP address |
that was assigned to them from their cable modem or DSL provider. -------- (UAC 8023) REGISTER/Response (UAS 5060) --------
| |----------------------->---<-----------------------| |
| | | | |
| Client | |5060 INVITE (UAC 8015)| Proxy |
| | x<------------------------| |
| | | | |
-------- | --------
|
|
|
The procedure is then simple: Figure 2
1. Determine the IP address assigned to the user by the cable In figure 2 the original REGISTER request is sent from the client on
or DSL provider, by looking through the residential NAT port 8023 and received on port 5060, establishing a reliable
configuration. Call this the "public address". connection and opening a pin-hole in the NAT. The generation of a
new request from the proxy results in a request destined for the
registered entity (Contact IP address) which is not reachable from
the public network. This results in the new SIP request attempting
to create a connection to a private network address. This problem
would be solved if the original connection was re-used. While this
problem has been discussed in the context of connection orientated
protocols such as TCP, the problem exists for SIP signaling using any
transport protocol. The solution proposed for this problem in
section 3 of this document is relevant for all SIP signaling,
regardless of the transport protocol.
2. Determine the IP address assigned to the phone that the NAT policy can dictate that connections should be closed after a
user wishes to use. This address is on the home LAN, period of inactivity. This period of inactivity can range
assigned by the DHCP server running in the residential NAT. drastically from a number seconds to hours. Pure SIP signaling can
Call this the "phone address". not be relied upon to keep alive connections for a number of reasons.
Firstly, SIP entities can sometimes have no signaling traffic for
long periods of time which has the potential to exceed the inactivity
timer, this can lead to problems where endpoints are not available to
receive incoming requests as the connection has been closed.
Secondly, if a low inactivity timer is specified, SIP signaling is
not appropriate as a keep-alive mechanism as it has the potential to
add a large amount of traffic to the network which uses up valuable
resource and also requires processing at a SIP stack, which is also a
waste of processing resource.
3. Enable the DMZ host configuration on the residential NAT. Media associated with SIP calls also has problems traversing NAT.
Set the DMZ host to be equal to the phone address. This RTP[2]] is on if the most common media transport type used in SIP
means that the phone will receive all incoming traffic. signaling. Negotiation of RTP occurs with a SIP session
establishment using the Session Description Protocol(SDP) [3] and a
SIP offer/answer exchange[4]. During a SIP offer/answer exchange an
IP address and port combination are specified by each client in a
session as a means of receiving media such as RTP. The problem
arises when a client advertises it's address to receive media and it
exists in a private network that is not accessible from outside the
NAT. Figure 3 illustrates this problem.
+--------+ NAT Public Network NAT
|Provider| | |
| Proxy | | |
| |
-------- | SIP Signaling Session | --------
| |----------------------->---<-----------------------| |
| | | | | |
| Client | | | | Client |
| A |>=========>RTP>=====================>RTP>======X | B |
| | X=====<RTP<=====================<RTP<=========<| |
-------- | | --------
| | | |
+---+----+
|
--------+----------
/////// \\\\\\\
/// \\\
|| ||
| Internet |
| | | |
| | | |
|| ||
\\\ ///
\\\\\\\ ///////
---------+---------
| DSL, Cable
+--------+-------+
| Home NAT |
+----------------+
+--------+ +----------+
| | | / \ |
| PC | /SIP \
| | /Phone \
| | / \
+--------+ ------------
Figure 1: Residence with Single NAT
4. Configure the PC softphone or hardphone to use the public
address in all SIP and SDP messages it builds. Many VoIP
clients can be configured in this way.
Thats it! This configuration effectively makes the NAT transparent;
all packets in go to the phone without being natted, and the phone
has the public address that will get routed to it.
Phone Client NAT Provider Provider
(1) INVITE Proxy Gateway
| srcIP = 10.0.1.1 | | |
| srcPort = 5060 | | |
| SDP = 1.2.3.4:8876 | |
|----------------->| | |
| |(2) INVITE | |
| | srcIP = 1.2.3.4 | |
| | srcPort = 9357 | |
| |----------------->| |
| | |(3) INVITE |
| | |----------------->|
| | |(4) 200 OK |
| | |<-----------------|
| | |Resp. to src IP |
| | | and port in via |
| |(5) 200 OK | |
| | dstIP = 1.2.3.4 | |
| | dstPort = 5060 | |
| |<-----------------| |
|(6) 200 OK | | |
| dstIP = 10.0.1.1 | | |
| dstPort = 5060 | | |
|<-----------------| | |
|(7) ACK | | |
|----------------->| | |
| |(8) ACK | |
| |------------------------------------>|
| |(9) RTP | |
| | destIP = 1.2.3.4 | |
| | destPort = 8876 | |
| |<------------------------------------|
|(10) RTP | | |
| destIP = 10.0.1.1 | |
| destPort = 8876 | | |
|<-----------------| | |
Figure 2: Configuration solution
A PC to phone call flow for this case is shown in Figure 2. Since the
PC client is configured with the IP address on the public side of the
NAT (1.2.3.4), that is the address inserted into the SDP of the
INVITE (message 1). When the proxy sends the 200 OK response to the
PC (message 4), it sends it to the source IP address where the
request came from (1.2.3.4), but the port in the Via header (5060).
This is received by the NAT. Since there is no mapping for this, the
IP address is rewritten to the DMZ host's address (10.0.1.1), and
sent there. This is exactly what we want, since the PC is listening
on 5060 for the responses. The media from the gateway to the PC works
in a similar way (line 9). Its sent from the gateway to the IP
address and port in the SDP (1.2.3.4:8876). The NAT receives this.
Since there is no binding, the IP address is rewritten to the DMZ
host (1.2.3.4) and the RTP packets forwarded there.
Receiving calls will work in a similar way. The Contact header in the
registrations from the PC client or hard phone will include the
public address (1.2.3.4), and therefore incoming calls are routed
there.
The benefits of this solution are that it works without additional
software changes. However, the drawbacks are many. It requires
complex configuration which is certainly beyond the capabilities of
most users. Secondly, it only works with a single phone at a time
talking. If a different phone is used, the configuration would need
to change. Third, it will open up the phone to a variety of DoS
attacks, since all other kinds of traffic will be let in towards the
phone.
2.2 Solution II: Stun in Client
The second solution for this scenario is to upgrade the client phone
or PC application to include support for the STUN protocol [2], and
optionally the SDP extensions for NAT [8], SDP extensions for
connection oriented media [16], and SIP extensions for NAT [9]. The
latter three are all optional, as the solution can work without them.
We discuss the pros and cons of having or not having these. This
solution also requires the service provider to deploy the stun server
described in [2].
The stun protocol allows a client to discover whether it is behind a
nat, and what type of nat it is behind. In the case of three of the
four nat types described in [2] (all but the symmetric NAT), stun
will provide the client with its public IP address.
When the client first starts up, the first thing it will do is to use
STUN to determine the type of NAT it is behind. This check need only
be done on startup; the type of NAT will not generally change unless
the user upgrades or replaces their NAT, in which case a boot of the
phone or client would be needed. The procedure on startup is the
discovery procedure that is described in the stun protocol. This
involves messaging exchanges between the stun client and its stun
server. The reader is referred to that document for details.
Once the type of NAT is discovered, operation from there on depends
on the result of the discovery. If the user discovers that they are
not behind any NAT or firewall at all, then no special processing is
required. If, however, they discover that they are behind a NAT, the
processing depends on whether the NAT is symmetric or not.
2.2.1 Not Symmetric NAT
In this scenario, the client has discovered that it is behind a full
cone or restricted cone NAT. This includes the case where there are
multiple NATs (its common for cable modem providers to NAT their
entire networks, so this NAT might exist in addition to the NAT in
the user's home), but the most restrictive type is full cone or
restricted cone.
2.2.1.1 Registration
The first step is for the client to register. Like everything else,
there are several approaches.
The recommended procedure is to use a persistent TCP connection for
the registrations, and to indicate that the connection is to be
reused for incoming requests. If, for some reason, TCP is not
possible, there are two UDP-based solutions. One is to use STUN, and
the other is to use double UDP registrations.
2.2.1.2 Registration: TCP
TCP is the recommended solution because of binding lifetimes. TCP
connections can remain open through a NAT for extended durations
without continuous traffic to refresh them. UDP, on the other hand,
requires data traffic every minute or so to keep the bindings active.
Therefore, if registrations were done over UDP, they would require
registration refreshes every minute or less, which has scalability,
performance and congestion issues.
The trick with registering over TCP is to inform the server that it
should reuse the connection established for registration to send
requests to the UA. One way to accomplish that is through a "double
register" procedure. In this procedure, the UA opens a TCP connection
to the server, and then sends a REGISTER request. The Contact header
contains an arbitrary URI. If the server implements the rport
parameter in the SIP nat extensions [9], the response to the REGISTER
request will contain a filled-in rport and received parameter in the
top Via. These parameters identify the source side of the TCP
connection as seen by the server. The client can then re-register,
removing the Contact that was placed in the first registration, and
adding a new Contact, formed from the IP address and rport in the top
Via of the previous response. Based on the rules for connection reuse
in SIP [1], the server will reuse that connection for sending
requests to the client.
The alternative is to explicitly request for connection reuse.
Requirements for such reuse are documented in [17]. It is expected
that the mechanism resulting from these requirements will replace the
Translate header which was originally proposed in [9].
Persistent TCP connections introduce failover and load balancing
issues. If the client cannot be reached except through the specific
TCP connection open to the client on a specific proxy, incoming calls
must be routed through that proxy. As a result, load balancers will
need to take this into account, explicitly routing a request to that
proxy, if its still available. Fault tolerant solutions will need to
share the TCP connection state to a backup which shares the same IP
address.
2.2.1.3 Registration: STUN
In the event that TCP registrations are not possible, the next best
thing is STUN. The flow for using STUN is shown in Figure 3.
First, the client uses a STUN query to its provider's STUN server.
This will provide it with an IP address and port on which it can
receive messages. The client will use the address and port in the
STUN response (message 4) to receive incoming SIP messages. In order
to do that, it includes this address and port as the Contact header
of a REGISTER message that it sends to its provider's proxy (message
5). This REGISTER will need to use the rport parameter in the Via
header [9] in order for the response to be received by the UA. The UA
will then receive incoming requests through the socket used to
allocate the binding from the STUN server.
The UA will need to refresh the binding learned from STUN by re-
sending the STUN query every minute or so. It will also need to
listen for incoming SIP messages on this address and port.
Fortunately, the stateless nature of the STUN server makes it
relatively inexpensive to refresh the STUN binding, compared to a SIP
REGISTER request.
2.2.1.4 Registration: UDP, no STUN
If STUN is not available, the next best solution is to apply the
double registration procedure of Section 2.2.1 to UDP. The process is
Client NAT Proxy STUN
Server
|(1) STUN Query | | |
|-------------------->| | |
| |(2) STUN Query | |
| |------------------------------------------>|
| |(3) STUN Response | |
| | addr = 1.2.3.4:5678 | |
| |<------------------------------------------|
|(4) STUN Response | | |
| addr = 1.2.3.4:5678 | | |
|<--------------------| | |
|(5) REGISTER | | |
| Contact: 1.2.3.4:5678 | |
|-------------------->| | |
| |(6) REGISTER | |
| | Contact: 1.2.3.4:5678 |
| |-------------------->| |
| |(7) 200 OK | |
| |<--------------------| |
|(8) 200 OK | | |
|<--------------------| | |
Figure 3: Register flow, not symmetric NAT
the same, but instead of opening a TCP connection, a single UDP
socket is used for both registrations, and is then used to receive
incoming SIP requests.
The drawback is that the registration will need to be frequently
refreshed. The rate needs to be often enough to cause the NAT
bindings to remain fresh. This could be as frequently as once every
30 seconds. That produces a substantial amount of messaging traffic.
A 10,000 user system would be generating REGISTER transactions at a
rate of 333 per second, far more than the actual call volume rate for
that many users. Therefore, this solution is better suited to lower
volume systems.
The benefit compared to TCP is, like the STUN solution, if the NAT is
full-cone, the incoming INVITE need not be delivered to the proxy
with which the UA established the binding.
Like TCP, the double registration can be avoid through the use of Figure 3
explicit connection sharing.
2.2.1.5 Initiating a Session The connection address representing both clients are not available
on the public internet and traffic can be sent from both clients
through their NATs. The problem occurs when the traffic attempts to
traverse media through the foreign (not local) NAT. The connection
address extracted from the SDP payload is that of an internal
address, and so not resolvable from the public side of the NAT. To
complicate the problem further, a number of different NAT topologies
with different default behaviors increase the difficulty of proposing
a single solution.
The next operation to consider is how the client makes a call. The 3. Solution Technology Outline Description
flow for this process is shown in Figure 4. We assume the simple case
of a single audio stream. In that case, the client will require two
IP addresses and ports - one to receive RTP, and the other, to
receive RTCP. As a result, it launches two STUN queries (messages 1-4
and message 5-8), resulting in two address/port pairs. Unfortunately,
the RTP and RTCP ports are no longer adjacent. This will require the
SDP in the INVITE constructed by the client to include the address
for RTCP as a separate element. An SDP extension for doing this is
defined in [8]. If this extension is not supported by the client (or
the called party), the result is that RTCP may not be transmitted for
the session. This is bad, but not catastrophic, as the call can
proceed without it.
The client will also need to populate the IP address in the Contact When analyzing issues associated with traversal of SIP through
header of the INVITE. This will generally be the same Contact address existing NAT, it has been identified that the problem can be split
which was registered from the process in Section 2.2.1. This should into two clear solution areas as defined in section 2 of this
always be the value from the Contact header in the response to the document. The traversal of the core protocol signaling and the
REGISTER request. traversal of the associated media as specified in the Session
Description Payload (SDP) of a SIP offer/answer exchange[4]. The
following sub-sections outline solutions that enable core SIP
signaling and its associated media to traverse NATs.
The final component of the INVITE is the support for connection 3.1 SIP Signaling
oriented media [16]. Connection oriented media are media that run
over transports that have the notion of a connection that needs to be
established. Normally, this means TCP. In the case of TCP, if two
parties want to communicate, one needs to initiate the connection,
and the other needs to receive it. Once established, both sides can
send over the connection. To support that, the comedia draft [16]
defines a new SDP attribute, the a=direction attribute. This
attribute can take on the values of passive, active, or both. Passive
means that the participant can only be on the receiving end of the
connection. Active means it must be the initiating side. Both means
that it can do either. Connection oriented operation can also be
applied to RTP over UDP. We call this mode of operation "symmetric
RTP". In symmetric RTP, the active side sends an RTP packet to the
passive side. When the passive side receives this, it sends RTP
packets back to the source address of the RTP packet just received.
Thats it.
Symmetric RTP has the important property that one side (the active SIP signaling has two areas that result in transactional failure when
side) does not need to provide an IP address and port to the peer in traversing through NAT, as described in section 2 of this document.
its SDP, since no packet is sent there. Rather, its sent to the The remaining sub-sections describe appropriate solutions that result
source address of the received RTP packet from the active side. This in SIP signalling traversal through NAT, regardless of transport
means that the active side can be behind a symmetric NAT, and still protocol. IT is RECOMMEDED that SIP compliant entities follow the
send media directly to its peer without use of some kind of network guidelines presented in this section to enable traversal of SIP
intermediary. This is good. However, for it to work, the peer needs signaling through NATs.
to support symmetric RTP. So, even though in the case currently under
consideration, the client is not behind a symmetric NAT, it should
ideally support symmetric RTP just in case its peer is behind a
symmetric NAT.
Therefore, if the client supports the comedia extension applied to 3.1.1 Symmetric Response
RTP, it should include the a=direction:both attribute in its SDP. If
this extension is not supported, things will still work, but the call
may be routed through an intermediary if the peer is behind a NAT.
The Via header contains an IP address as well. This address will As described in section 2 of this document, when using an unreliable
never be used, in fact, except for failure conditions at the proxy. transport protocol such as UDP, SIP responses are sent to the IP
Therefore, the address should contain the same address used in the address and port combination contained in the SIP 'Via' header field
contact header. The SDP o line also has an IP address, used for (or default port for the appropriate transport protocol if not
identification purposes only. Its value is arbitrary, but should be present). This can result in responses being blocked at a NAT. In
the contact address also, to prevent leakage of any private addresses such circumstances, SIP signaling requires a mechanism that will
outside the network. allow entities to override the basic response generation mechanism in
RFC 3261 [1]. Once the SIP response is constructed, the destination
is still derived using the mechanisms described in RFC 3261 [1]. The
port (to which the response will be sent), however, will not equal
that specified in the SIP 'Via' header field but will be the port
from which the original request was sent. This results in the
pin-hole opened for the requests traversal of the NAT being reused,
in a similar manner to that of reliable connection orientated
transport protocols such as TCP. Figure 4 illustrates the response
traversal through the open pin hole using this method.
The outgoing INVITE (message 9) might look like: Private Network NAT Public Network
|
|
|
-------- | --------
| | | | |
| |send/receive | send/receive| |
| Client |port 5060-----<<->>-------------<<->>-----port 5060| Client |
| A | | | B |
| | | | |
-------- | --------
|
|
|
INVITE sip:user@domain SIP/2.0 Figure 4
From: sip:user@school.edu;tag=88asd
To: sip:user@domain
Call-ID: 98asd6asd60099
CSeq: 987769 INVITE
Via: SIP/2.0/TCP 1.2.3.4
Contact: sip:1.2.3.4:5678
Content-Type: application/sdp
Content-Length: ...
v=0 The exact functionality for this method of response traversal is
o=aa 2890844526 2890842807 IN IP4 1.2.3.4 called 'Symmetric Response' and the details are documented in RFC
c=IN IP4 1.2.3.4 3581 [5]. Additional requirements are imposed on SIP entities in
t=0 0 this specification such as listening and sending SIP
m=audio 5679 RTP/AVP 0 requests/responses from the same port.
a=rtcp:5688
a=direction:both
The INVITE goes through the NAT, and is received at the proxy 3.1.2 Connection Re-use
(message 10). The proxy forwards it on, and receives a 2xx response.
This response is passed through the nat (message 11) and arrives at
the client (message 12).
The proxy should have record-routed, in order to ensure that the The second problem with sip signaling, as defined in Section 3.1.2,
messaging flows through it (as its holding the only signaling is to allow incoming requests to be properly routed. This is
Client NAT STUN Proxy addressed in [8], which allows the reuse of a TCP connection or UDP
Server 5-tuple for incoming requests. That draft also provides keepalive
|(1) STUN Query | | | mechanisms based on using STUN to the SIP server. Usage of this
|src=10.0.1.1:5306 | | | specification is RECOMMENDED. This mechanism is not transport
|------------------>| | | specific and should be used for any transport protocol.
| |(2) STUN Query | |
| |src=1.2.3.4:5679 | |
| |------------------>| |
| |(3) STUN Resp. | |
| |addr=1.2.3.4:5679 | |
| |dst=1.2.3.4:5679 | |
| |<------------------| |
|(4) STUN Resp. | | |
|addr=1.2.3.4:5679 | | |
|dst=10.0.1.1:5306 | | |
|<------------------| | |
|(5) STUN Query | | |
|src=10.0.1.1:5307 | | |
|------------------>| | |
| |(6) STUN Query | |
| |src=1.2.3.4:5688 | |
| |------------------>| |
| |(7) STUN Resp. | |
| |addr=1.2.3.4:5688 | |
| |dst=1.2.3.4:5688 | |
| |<------------------| |
|(8) STUN Resp. | | |
|addr=1.2.3.4:5688 | | |
|dst=10.0.1.1:5307 | | |
|<------------------| | |
|(9) INVITE | | |
|rtp=1.2.3.4:5679 | | |
|rtcp=1.2.3.4:5688 | | |
|contact=1.2.3.4:5678 | |
|------------------>| | |
| |(10) INVITE | |
| |rtp=1.2.3.4:5679 | |
| |rtcp=1.2.3.4:5688 | |
| |contact=1.2.3.4:5678 |
| |-------------------------------------->|
| | | |Proxy forwards
| | | | INVITE,
| | | |response
| | | |comes
| |(11) 200 OK | |
| |<--------------------------------------|
|(12) 200 OK | | |
|<------------------| | |
|(13) ACK | | |
|------------------>| | |
| |(14) ACK | |
| |-------------------------------------->|
Figure 4: Initiating a session, not symmetric NAT Even if this draft is not used, clients SHOULD use the same IP
connection to the client). As a result, the ACK should be sent over address and port (i.e., socket) for both transmission and receipt of
that TCP connection to the proxy (the same for UDP; it would be sent SIP messages. Doing so allows for the vast majority of industry
from the same socket, to the same place the REGISTER was sent). provided solutions to properly function.
If symmetric RTP is being used, the SDP in the response will contain 3.2 Media Traversal
an a=direction attribute, in which case the procedures of [16] would
apply. If there is no symmetric RTP in use, the client sends media to
the address(es) provided in the 200 OK. The media should be sent from
the same socket that is being used to receive (the two learned
through STUN), although this is not strictly needed.
2.2.1.6 Receiving an Invitation to a Session This document has already provided guidelines that recommend using
extensions to the core SIP protocol to enable traversal of NATs.
While ultimately not desirable, the additions are relatively straight
forward and provide a simple, universal solution for varying types of
NAT deployment. The issues of media traversal through NATs is not as
straight forward and requires the combination of a number of
traversal methodologies. The technologies outlined in the remainder
of this section provide the required solution set.
The call flow for receiving an invitation to a session is shown in 3.2.1 Symmetric RTP
Figure 5. The flow resembles the one for the outgoing INVITE in many
ways. When the INVITE arrives at the client, it will need to perform
two STUN queries for each media stream (messages 3-6 for the RTP
address and messages 7-10 for the RTCP address in the case of a
single media stream). This is to obtain the addresses to use for
receiving media.
The client also checks for the comedia a=direction attribute The primary problem identified in section 2 of this document is that
(assuming this extension is supported). If it is, the guidelines in internal IP address/port combinations can not be reached from the
[16] are followed to set the direction attribute in the 200 OK. If it public side of a NAT. In the case of media such as RTP, this will
was a=active in the INVITE, this means that the peer is likely behind result in no audio traversing a NAT(as illustrated in Figure 3). To
a symmetric NAT. The direction attribute in the response will then be overcome this problem, a technique called 'Symmetric' RTP can be
a=passive. If the client doesn't support comedia, the attribute is used. This involves an SIP endpoint both sending and receiving RTP
ignored and no direction attribute is placed in the response. traffic from the same IP Address/Port combination. This technique
also requires intelligence by a client on the public internet as it
identifies that incoming media for a particular session does not
match the information that was conveyed in the SDP. In this case
the client will ignore the SDP address/port combination and return
RTP to the IP address/port combination identified as the source of
the incoming media. This technique is known as 'Symmetric RTP' and
is documented in [11]. 'Symmetric RTP' SHOULD only be used for
traversal of RTP through NAT when one of the participants in a media
session definitively knows that it is on the public network.
As with the initiation case, the SDP extensions for RTCP [8] will 3.2.2 STUN
need to be used to explicitly specify the RTCP address. The same
guidlines for selecting the Contact, Via, and o line as described in
the initiation case apply here as well. The result is a 200 OK
response (assuming the call is accepted, of course), which looks like
(message 11):
SIP/2.0 200 OK Simple Traversal of User Datagram Protocol(UDP) through Network
From: sip:user@school.edu;tag=88asd Address Translators(NAT) or STUN is defined in RFC 3489 [7]. It
To: sip:user@domain;tag=99as8a provides a lightweight protocol that allows entities to probe and
Call-ID: 98asd6asd60099 discover the type of NAT that exist between itself and external
CSeq: 987769 INVITE entities. It also provides details of the external IP address/port
Via: SIP/2.0/TCP 1.9.2.2 combination used by the NAT device to represent the internal entity
Via: SIP/2.0/UDP 82.3.4.5 on the public facing side of a NAT. On learning of such an external
Via: SIP/2.0/TCP 1.2.3.4 representation, a client can use accordingly as the connection
Contact: sip:9.8.7.6:7766 address in SDP to provide NAT traversal. STUN only works with Full
Content-Type: application/sdp Cone, Restricted Cone and Port Restricted Cone type NATs. STUN does
Content-Length: ... not work with Symmetric NATs as the technique used to probe for the
external IP address port representation using a STUN server will
provide a different result to that required for traversal by an
alternative SIP entity. The IP address/port combination deduced for
the STUN server would be blocked for incoming packets from an
alterative SIP entity.
v=0 3.2.3 TURN
o=aa 2890844526 2890842807 IN IP4 9.8.7.6
c=IN IP4 9.8.7.6
t=0 0
m=audio 9988 RTP/AVP 0
a=rtcp:8877
a=direction:passive
The client will receive the ACK over the same connection it received As mentioned in the previous section, the STUN protocol does not work
the INVITE, since its proxy will record route. for UDP traversal through a Symmetric style NAT. Traversal Using
Relay NAT (TURN) provides the solution for UDP traversal of symmetric
NAT. TURN is extremely similar to STUN in both syntax and operation.
It provides an external address at a TURN server that will act as a
relay and guarantee traffic will reach the associated internal
address. The full details of the TURN specification are defined in
[10]. A TURN service will almost always provide media traffic to a
SIP entity but it is RECOMMENDED that this method only be used as a
last resort and not as a general mechanism for NAT traversal. This
is because using TURN has high performance costs when relaying media
traffic.
2.2.1.7 Media Flow 3.2.4 ICE
Finally, let us consider the actual flow of media in the examples Interactive Connectivity Establishment (ICE) is the RECOMMENDED
above. The examples had a call placed from user@school, behind a NAT method for traversal of existing NAT if Symmetric RTP is not
with public IP 1.2.3.4, calling user@domain, behind a NAT with public appropriate. ICE is a methodology for using existing technologies
IP 9.8.7.6. user@school used the comedia extensions, with a direction such as STUN and TURN to provide a unified solution. This is
attribute of both, and user@domain answered with a direction of achieved by obtaining as many representative IP address/port
passive. The result is that user@school will act as active, and send combinations as possible using technologies such as STUN/TURN etc.
the first RTP (and RTCP) packet. This will flow through its NAT, the Once the addresses are accumulated, they are all included in the SDP
NAT of user@domain, and then to user@domain. exchange in a new media attribute called 'alt'. Each 'alt' entry has
a preference which is represented in the 'alt' SDP attribute. The
appropriate IP address/port combinations are used in the correct
order. A failure results in the next address being used in the list
of alternatives. The full details of the ICE methodology are
contained in [12].
The flow of the media for this case is shown in Figure 6. The RTCP is 3.2.5 RTCP Attribute
not shown, but would work in an identical fashion.
This flow will work perfectly for full cone, but will not work as Normal practice when selecting a port for defining Real Time Control
written for restricted cone. Thats because NAT 2, assuming its Protocol(RTCP)[2] is for consecutive order numbering (i.e select an
restricted cone, will not allow the RTP packet from user@school incremented port for RTCP from that used for RTP). This assumption
(message 2) in. Thats because user@domain has not yet sent a packet causes RTCP traffic to break when traversing many NATs due to blocked
to 1.2.3.4 yet. Therefore, user@domain needs to "prime" its NAT by ports. To combat this problem a specific address and port need to be
sending a packet to 1.2.3.4:5679 (it will know this address from the specified in the SDP rather than relying on such assumptions. RFC
INVITE it received). Thus, it needs to send a packet even though it 3605 [5] defines an SDP attribute that is included to explicitly
has indicated it wants to be the passive side of the symmetric RTP specify transport connection information for RTCP. The address
connection. The most natural way to accomplish this is to actually details can be obtained using any appropriate method including those
have users behind restricted cone or port restricted cones respond to detailed previously in this section (e.g. STUN, TURN).
a=direction:both with a=direction:both. In that scenario, as
described in [16], both sides send a packet to each other, and one of
the "connections" is then used. Having both sides send packets to
each other is exactly what is needed to allow operation in restricted
cone and port restricted cone nats.
The flow for this case (where both sides indicated a=direction:both) 3.2.6 Solution Profiles
Client NAT STUN Proxy
Server
| |(1) INVITE | |
| |<--------------------------------------|
|(2) INVITE | | |
|<------------------| | |
|(3) STUN Query | | |
|src=10.1.2.3:1928 | | |
|------------------>| | |
| |(4) STUN Query | |
| |src=9.8.7.6:9988 | |
| |------------------>| |
| |(5) STUN Resp. | |
| |addr=9.8.7.6:9988 | |
| |dst=9.8.7.6:9988 | |
| |<------------------| |
|(6) STUN Resp. | | |
|addr=9.8.7.6:9988 | | |
|dst=10.1.2.3:1928 | | |
|<------------------| | |
|(7) STUN Query | | |
|src=10.1.2.3:1929 | | |
|------------------>| | |
| |(8) STUN Query | |
| |src=9.8.7.6:8877 | |
| |------------------>| |
| |(9) STUN Resp. | |
| |addr=9.8.7.6:8877 | |
| |dst=9.8.7.6:8877 | |
| |<------------------| |
|(10) STUN Resp. | | |
|addr=9.8.7.6:8877 | | |
|dst=10.1.2.3:1929 | | |
|<------------------| | |
|(11) 200 OK | | |
|rtp=9.8.7.6:9988 | | |
|rtcp=9.8.7.6:8877 | | |
|contact=9.8.7.6:7766 | |
|------------------>| | |
| |(12) 200 OK | |
| |rtp=9.8.7.6:9988 | |
| |rtcp=9.8.7.6:8877 | |
| |contact=9.8.7.6:7766 |
| |-------------------------------------->|
| | | |200 OK
| | | |forwarded
| | | |upstream
| |(13) ACK | |
| |<--------------------------------------|
|(14) ACK | | |
|<------------------| | |
Figure 5: Incoming INVITE, not Symmetric NAT This draft has documented a number of technology solutions for the
user@school NAT 1 NAT 2 user@domain traversal of media through differing NAT deployments. A number of
|(1) RTP | | | 'profiles' will now be defined that categorize varying levels of
|src=10.0.1.1:5306 | | | support for the technologies described.
|dest=9.8.7.6:9988 | | |
|------------------>| | |
| |(2) RTP | |
| |src=1.2.3.4:5679 | |
| |dest=9.8.7.6:9988 | |
| |------------------>| |
| | |(3) RTP |
| | |src=1.2.3.4:5679 |
| | |dest=10.1.2.3:1928 |
| | |------------------>|
| | |(4) RTP |
| | |src=10.1.2.3:1928 |
| | |dest=1.2.3.4:5679 |
| | |<------------------|
| |(5) RTP | |
| |src=1.2.3.4:5679 | |
| |dest=1.2.3.4:5679 | |
| |<------------------| |
|(6) RTP | | |
|src=1.2.3.4:5679 | | |
|dest=10.0.1.1:5306 | | |
|<------------------| | |
Figure 6: Media flow for residential case, not symmetric NAT 3.2.6.1 Primary Profile
is shown in Figure 7. It is identical to the flow above, but with a A client falling into the 'Primary' profile supports ICE in
reordering of messages. Now, both users send their first packet at conjunction with STUN, TURN and RFC 3605 [5] for RTCP. ICE is used
the same time, causing the NATs to be "primed". In reality, the in all cases and falls back to standard operation when dealing with
packets may not be sent at the same time, so the first few packets non-ICE clients. A client which falls into the 'Primary' profile
from the first sender will be lost until the other user primes their will be maximally interoperable and function in a rich variety of
environments including enterprise, consumer and behind all variety of
NAT. NAT.
Its important to realize that with port restricted cone NAT, the 3.2.6.2 Consumer Profile
priming will only work when the user sends from the same IP address
and port they expect to receive from.
2.2.2 Symmetric NAT
Section 2.2.1 handled the case where the user was in a residence
behind a full cone or restricted cone NAT. In this section, we
consider the case of a symmetric NAT.
user@school NAT 1 NAT 2 user@domain
|(1) RTP | | |
|src=10.0.1.1:5306 | | |
|dest=9.8.7.6:9988 | | |
|------------------>| | |
| |NAT1 primed | |
| |to receive | |
| |from 9.8.7.6:9988 | |
| | |(2) RTP |
| | |src=10.1.2.3:1928 |
| | |dest=1.2.3.4:5679 |
| | |<------------------|
| | |NAT2 primed |
| | |to receive |
| | |from 1.2.3.4:5679 |
| |(3) RTP | |
| |src=1.2.3.4:5679 | |
| |dest=9.8.7.6:9988 | |
| |------------------>| |
| |(4) RTP | |
| |src=1.2.3.4:5679 | |
| |dest=1.2.3.4:5679 | |
| |<------------------| |
| | |(5) RTP |
| | |src=1.2.3.4:5679 |
| | |dest=10.1.2.3:1928 |
| | |------------------>|
|(6) RTP | | |
|src=1.2.3.4:5679 | | |
|dest=10.0.1.1:5306 | | |
|<------------------| | |
Figure 7: Media flow for residential case, priming the NAT
The operation is much like the non-symmetric case. However, instead
of using STUN to determine the addresses, a TURN [3] server is used
to obtain addresses. Like STUN, TURN will provide a publically
routable IP address and port that can be used. However, unlike STUN,
this address and port routes to the TURN server, which forwards the
packets on the same socket the TURN request was received on. This
allows it to operate through more restrictive symmetric NAT. The cost
of this approach is routing of media through the service provider
network, which can substantially increase latency and loss, and also
increases the cost to the provider.
2.2.2.1 Registration
The recommended registration mechanism parallels the procedure for
STUN as described in Section 2.2.1. TCP is still preferred. If UDP is
used, the TURN-based solution is preferred. In that mode, the client
will allocate an address from the TURN server, and then include that
in the Contact header in the REGISTER. In the case of TURN, it is
recommended that a TCP address be allocated from the TURN server.
This will avoid the need to constantly refresh the binding, as would
be the case for UDP. The problem is worse with TURN, since once the
client receives an incoming INVITE, refreshes of the binding would
cause packets to be delivered to the proxy, and therefore they would
need to be complete REGISTER messages themselves in order to be
properly processed. This will result in a serious burden on the proxy
server.
Client NAT Proxy TURN
Server
|(1) TURN Allocate | | |
|-------------------->| | |
| |(2) TURN Allocate | |
| |------------------------------------------>|
| |(3) TURN Response | |
| | addr = 15.1.2.3:5678| |
| |<------------------------------------------|
|(4) TURN Response | | |
| addr = 15.1.2.3:5678| | |
|<--------------------| | |
|(5) REGISTER | | |
| Contact: 15.1.2.3:5678 | |
| Translate: 15.1.2.3:5678 | |
|-------------------->| | |
| |(6) REGISTER | |
| | Contact: 15.1.2.3:5678 |
| | Translate: 15.1.2.3:5678 |
| |-------------------->| |
| |(7) 200 OK | |
| |<--------------------| |
|(8) 200 OK | | |
|<--------------------| | |
Figure 8: Registration for Symmetric NAT
Assuming TCP, the flow for registration is shown in Figure 8. Before
message 1 is sent, there is a standard TCP handshake with the TURN
server, not shown. Then, the client sends a TURN Allocate request
(message 1) to its TURN server. The response (message 4) contains the
address allocated to the client, in this case, 15.1.2.3:5678. So, it
uses that address in a REGISTER message, also sent using TCP, to its
proxy (message 5).
2.2.2.2 Initiating a Session A client falling into the 'Consumer' profile supports STUN and RFC
3605 [5] for RTCP. It uses STUN to allocate bindings, and can also
detect when it is in the unfortunate situation of being behind a
'Symmetric' NAT, although it simply cannot function in this case.
These clients will only work in deployment situations where the
access is sufficiently controlled to know definitively that there
won't be Symmetric NAT. This is hard to guarantee as users can
always pick up their client and connect via a different access
network.
The process for initiating a session parallels that for the non- 3.2.6.3 Minimal Profile
symmetric case in Section 2.2.1. The client will use TURN to allocate
two UDP addresses - one for the RTP, and another for the RTCP. The
INVITE that is constructed will use the SDP extensions for RTCP [8]
to contain the RTCP addresses. The construction of the Via, Contact,
and origin lines in the SDP mirrors that for the non-symmetric case.
The main difference is in the use of comedia. For the symmetric case, A client falling into the 'Minimal' profile will send/receive RTP
support for the comedia draft [16] is strongly recommended. If the form the same IP/port combination. This client requires proprietary
other participant in the call is not behind a NAT, or is behind a network based solutions to function in any NAT traversal scenario.
full cone for restricted cone NAT, the use of the TURN server as
relay can be avoided. This will improve the voice quality and reduce
costs to the provider. In order for its usage to be avoided, the
client includes an a=direction:active attribute in its SDP. Note that
it still includes the addresses it obtained from the TURN server.
These will end up being used if the peer doesn't support comedia, or
is behind a symmetric or port restricted cone NAT.
This usage of a=active differs from the current comedia All clients SHOULD support the 'Primary Profile', MUST support the
draft, which says that if a=active is present, you MUSTNOT 'Minimal Profile' and MAY support the 'Consumer Profile'.
initiate a connection to it. This is not backwards
compatible. The approach described here is. We should work
to get this incorporated into comedia to add backwards
compatibility.
A flow for this case is shown in Figure 9. 4. NAT Traversal Scenarios
The resulting INVITE generated might look like: This section of the document includes detailed NAT traversal
scenarios for both SIP signaling and the associated media.
INVITE sip:user@domain SIP/2.0 4.1 Basic NAT SIP Signaling Traversal
From: sip:user@school.edu;tag=88asd
To: sip:user@domain
Call-ID: 98asd6asd60099
CSeq: 987769 INVITE
Via: SIP/2.0/TCP 15.1.2.3
Contact: sip:15.1.2.3:5678
Content-Type: application/sdp
Content-Length: ...
v=0 The following sub-sections concentrate on SIP signaling traversal of
o=aa 2890844526 2890842807 IN IP4 15.1.2.3 NAT. The scenarios include traversal for both reliable and
c=IN IP4 15.1.2.3 un-reliable transport protocols.
t=0 0
m=audio 5679 RTP/AVP 0
a=rtcp:5688
a=direction:active
2.2.2.3 Answering an Invitation to a Session [Editors Note: The scenarios are still in early construction and a
couple have been included as a hint of direction - All comments
welcome for next release]
The procedure for answering an INVITE mirrors that for the non- 4.1.1 Registration (Registrar/Proxy Co-Located
symmetric case described in Section 2.2.1. However, the RTP and RTCP
ports are obtained from a TURN server, not a STUN server, and the
client should indicate a=direction:active in the response if the
INVITE request indicated passive or both (assuming it supports
symmetric RTP.)
Another difference is the path of the INVITE itself. If TURN was used The set of scenarios in this section document basic signaling
to allocate the registered address, the incoming INVITE will flow traversal of a SIP REGISTER method through a NAT.
from the proxy, through the TURN server, towards the client.
The call flow for this case is shown in Figure 10. Note that the 4.1.1.1 UDP
incoming INVITE, its 200 OK, and the ACK, now all flow through the Client NAT Proxy
TURN server. The initial INVITE from the proxy to the TURN server | | |
(message 1) will actually cause a TCP connection to be first opened |(1) REGISTER | |
from the proxy to the turn server. From this point forward, the |----------------->| |
client should re-register over this TCP connection (rather than the | |(1) REGISTER |
other one it used to send the initial REGISTER, which goes directly | |----------------->|
to the proxy), without the Translate header. Using this connection | |(2) 401 Unauth |
for re-registrations is needed to keep the connection alive. | |<-----------------|
|(2) 401 Unauth | |
|<-----------------| |
|(3) REGISTER | |
|----------------->| |
| |(3) REGISTER |
| |----------------->|
|*************************************|
| Create Connection Re-use Tuple |
|*************************************|
| |(4) 200 OK |
| |<-----------------|
|(4) 200 OK | |
|<-----------------| |
| | |
The 200 OK response sent by the client might look like: Figure 5.
SIP/2.0 200 OK In this example the client sends a SIP REGISTER request through a NAT
From: sip:user@school.edu;tag=88asd which is challenged using the Digest authentication scheme. The
To: sip:user@domain;tag=99as8a client will include an 'rport' parameter as described in section
Call-ID: 98asd6asd60099 3.1.1 of this document for allowing traversal of UDP responses. The
CSeq: 987769 INVITE original request as illustrated in (1) in Figure 5 is a standard
Via: SIP/2.0/TCP 1.9.2.2 REGISTER message:
Via: SIP/2.0/UDP 82.3.4.5
Client NAT TURN Proxy
Server
|(1) TURN Allocate | | |
|src=10.0.1.1:5306 | | |
|------------------>| | |
| |(2) TURN Allocate | |
| |src=15.1.2.3:5679 | |
| |------------------>| |
| |(3) TURN Resp. | |
| |addr=15.1.2.3:5679 | |
| |dst=15.1.2.3:5679 | |
| |<------------------| |
|(4) TURN Resp. | | |
|addr=15.1.2.3:5679 | | |
|dst=10.0.1.1:5306 | | |
|<------------------| | |
|(5) TURN Allocate | | |
|src=10.0.1.1:5307 | | |
|------------------>| | |
| |(6) TURN Allocate | |
| |src=15.1.2.3:5688 | |
| |------------------>| |
| |(7) TURN Resp. | |
| |addr=15.1.2.3:5688 | |
| |dst=15.1.2.3:5688 | |
| |<------------------| |
|(8) TURN Resp. | | |
|addr=15.1.2.3:5688 | | |
|dst=10.0.1.1:5307 | | |
|<------------------| | |
|(9) INVITE | | |
|rtp=15.1.2.3:5679 | | |
|rtcp=15.1.2.3:5688 | | |
|contact=15.1.2.3:5678 | |
|------------------>| | |
| |(10) INVITE | |
| |rtp=15.1.2.3:5679 | |
| |rtcp=15.1.2.3:5688 | |
| |contact=15.1.2.3:5678 |
| |-------------------------------------->|
| | | |Proxy forwards
| | | | INVITE,
| | | |response
| | | |comes
| |(11) 200 OK | |
| |<--------------------------------------|
|(12) 200 OK | | |
|<------------------| | |
|(13) ACK | | |
|------------------>| | |
| |(14) ACK | |
| |-------------------------------------->|
Figure 9: STUN Symmetric, Outgoing INVITE REGISTER sip:proxy.example.com SIP/2.0
Client NAT TURN Proxy Via: SIP/2.0/UDP client.example.com:5060;rport;branch=z9hG4bKyiubjakxbnmzx
Server Max-Forwards: 70
| | |(1) INVITE | Supported: gruu
| | |<------------------| From: Client <sip:client@example.com>;tag=djks8732
| |(2) INVITE | | To: Client <sip:client@example.com>
| |<------------------| | Call-ID: 763hdc73y7dkb37@example.com
|(3) INVITE | | | CSeq: 1 REGISTER
|<------------------| | | Contact: <sip:client@client.example.com>; connectioId=1
|(4) TURN Query | | | ;+sip.instance="<urn:uuid:00000000-0000-0000-0000-000A95A0E120>"
|src=10.1.2.3:1928 | | | Content-Length: 0
|------------------>| | |
| |(5) TURN Query | |
| |src=15.4.5.6:9988 | |
| |------------------>| |
| |(6) TURN Resp. | |
| |addr=15.4.5.6:9988 | |
| |dst=15.4.5.6:9988 | |
| |<------------------| |
|(7) TURN Resp. | | |
|addr=15.4.5.6:9988 | | |
|dst=10.1.2.3:1928 | | |
|<------------------| | |
|(8) TURN Query | | |
|src=10.1.2.3:1929 | | |
|------------------>| | |
| |(9) TURN Query | |
| |src=15.4.5.6:8877 | |
| |------------------>| |
| |(10) TURN Resp. | |
| |addr=15.4.5.6:8877 | |
| |dst=15.4.5.6:8877 | |
| |<------------------| |
|(11) TURN Resp. | | |
|addr=15.4.5.6:8877 | | |
|dst=10.1.2.3:1929 | | |
|<------------------| | |
|(12) 200 OK | | |
|rtp=15.4.5.6:9988 | | |
|rtcp=15.4.5.6:8877 | | |
|contact=15.4.5.6:7766 | |
|------------------>| | |
| |(13) 200 OK | |
| |rtp=15.4.5.6:9988 | |
| |rtcp=15.4.5.6:8877 | |
| |contact=15.4.5.6:7766 |
| |------------------>| |
| | |(14) 200 OK |
| | |rtp=15.4.5.6:9988 |
| | |rtcp=15.4.5.6:8877 |
| | |contact=15.4.5.6:7766
| | |------------------>|
| | | |200 OK
| | | |forwarded
| | | |upstream
| | |(15) ACK |
| | |<------------------|
| |(16) ACK | |
| |<------------------| |
|(17) ACK | | |
|<------------------| | |
Figure 10: Incoming INVITE, Symmetric NAT
Via: SIP/2.0/TCP 15.1.2.3 This proxy now generates a SIP 401 response to challenge for
Contact: sip:15.4.5.6:7766 authentication, as depicted in (2) from Figure 5.:
Content-Type: application/sdp
Content-Length: ...
v=0 SIP/2.0 401 Unauthorized
o=aa 2890844526 2890842807 IN IP4 15.4.5.6 Via: SIP/2.0/UDP client.example.com:5060;rport=8050;branch=z9hG4bKyiubjakxbnmzx;received=192.0.1.2
c=IN IP4 15.4.5.6 From: Client <sip:client@example.com>;tag=djks8732
t=0 0 To: Client <sip:client@example.com>;tag=876877
m=audio 9988 RTP/AVP 0 Call-ID: 763hdc73y7dkb37@example.com
a=rtcp:8877 CSeq: 1 REGISTER
a=direction:active WWW-Authenticate: [not shown]
Content-Length: 0
2.2.2.4 Media Flows The response will be sent to the address appearing in the 'received'
parameter of the SIP 'Via' header (address 192.0.1.2). The response
will not be sent to the port deduced from the SIP 'Via' header, as
per standard SIP operation but will be sent to the value that has
been stamped in the 'rport' parameter of the SIP 'Via' header (port
8050). For the response to successfully traverse the NAT, all of the
conventions defined in RFC 3581 [5] MUST be obeyed. Make note of the
both the 'connectionID' and 'sip.instance' contact header parameters.
They are used to establish a connection re-use tuple as defined in
[8]. The connection tuple creation is clearly shown in Figure 5.
This ensures that any inbound request that causes a registration
lookup will result in the re-use of the connection path established
by the registration. This exonerates the need to manipulate contact
header URI's to represent a globally routable address as perceived on
the public side of a NAT. The subsequent messages defined in (3) and
(4) from Figure 5 use the same mechanics for NAT traversal.
The media flow scenarios depend on the type of NAT each side is [Editors note: Will provide more details on heartbeat mechanism in
behind. next revision]
Consider the case where the caller is behind a full cone NAT, and the [Editors note: Can complete full flows if required on heartbeat
callee is behind a symmetric NAT. In this case, the SDP in the INVITE inclusion]
from the caller will have an a=direction:both attribute. The SDP in
the 200 OK from the callee will have a=direction:active. The callee
will send media to the caller, using a socket different than the one
used to allocate the address from the TURN server. The caller sends
media back to the source address where media from the callee came
from. In this case, even though a TURN address was allocated by the
callee, that address is never used, and the binding will expire at
the TURN server.
TODO: flow for this case 4.1.1.2 Reliable Transport
Client NAT Registrar
| | |
|(1) REGISTER | |
|----------------->| |
| |(1) REGISTER |
| |----------------->|
| |(2) 401 Unauth |
| |<-----------------|
|(2) 401 Unauth | |
|<-----------------| |
|(3) REGISTER | |
|----------------->| |
| |(3) REGISTER |
| |----------------->|
|*************************************|
| Create Connection Re-use Tuple |
|*************************************|
| |(4) 200 OK |
| |<-----------------|
|(4) 200 OK | |
|<-----------------| |
| | |
Consider the case where the caller is behind a restricted cone NAT, Figure 6.
and the callee is behind a symmetric NAT. The caller includes an
a=direction:active attribute in its INVITE. The callee responds with
an a=direction:passive attribute. The caller will send to the address
provided by the callee in the 200 OK. This address is on the TURN
server. This data is received by the callee, which sends data back.
This is forwarded to the TURN server, and then onwards towards the
caller. Thus, an intermediary is included in this case.
TODO: flow for this case Traversal of SIP REGISTER messages request/responses using a
TODO: not sure all these cases are completely sorted out. reliable, connection orientated protocol such as TCP does not require
Setting of active/passive for restricted cone requires more any additional core SIP signaling extensions. SIP responses will
consideration. re-use the connection created for the initial REGISTER request, (1)
from Figure 6:
2.3 Solution III: STUN in B2BUA REGISTER sip:proxy.example.com SIP/2.0
Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKyilassjdshfu
Max-Forwards: 70
Supported: gruu
From: Client <sip:client@example.com>;tag=djks809834
To: Client <sip:client@example.com>
Call-ID: 763hdc783hcnam73@example.com
CSeq: 1 REGISTER
Contact: <sip:client@client.example.com;transport=tcp>; connectioId=1
;+sip.instance="<urn:uuid:00000000-0000-0000-0000-000A95A0E121>"
Content-Length: 0
The solution of Section 2.2 assumed that the client would need to be This example was included to show the inclusion of the of the
upgraded to support at least STUN, and additionally several other SIP connection re-use Contact header parameters as defined in the
extensions. In many cases, this will not be feasible. It is possible Connection Re-use draft[8]. This creates an association tuple as
to deploy the STUN solution in an intermediary, typically run as a described in the previous example for future inbound requests
piece of software that would be run within the residence. It can run directed at the newly created registration binding with the only
on the same machine as the client, or on a separate PC. In SIP difference that the association is with a TCP connection, not a UDP
terminology, this additional server is a "B2BUA", or Back to back pin hole binding.
User Agent. It receives requests from the clients, acts as a STUN
client, obtains addresses for media, modifies the SDP in the INVITEs,
and forwards the requests onwards. Both SIP traffic, and media
traffic, would be routed through it. Unlike the use of an
intermediary in the service provider network (like a TURN server),
the use of an intermediary in the home does not introduce any real
latency or voice quality problems, and there is no cost to the
service provider. There could be cost to the consumer, but we
anticipate that these intermediaries would be given away for free as
part of the service.
We call the B2BUA in the home network that acts as a STUN client a [Editors note: Will provide more details on heartbeat mechanism in
"STUN Agent", just for the sake of having a simple name. Note that next revision]
the STUN agent may also need to implement TURN, in the case that the
agent is behind a symmetric NAT. However, in the flows below, we do
specifically consider this case. The flows from Section 2.2.2 can be
directly applied to the flows below to show this scenario.
The configuration using the STUN Agent is shown in Figure 11. The [Editors note: Can complete full flows on inclusion of heartbeat
clients (PC phones, hardphones) are configured to talk to the STUN mechanism]
agent as their SIP local outbound proxy server, sending it both
registrations and invitations.
When the STUN agent starts up, it discovers whether there is a NAT or 4.1.2 Registration(Registrar/Proxy not Co-Located)
not, and what type of NAT, using the STUN discovery mechanisms [2].
In the event that there is no NAT, the STUN agent merely acts as a
stateless proxy, relaying packets in and out. We consider, from here
on, the case where it has discovered that it is behind a full cone or
restricted cone NAT.
2.3.1 Registration This section demonstrates traversal mechanisms when the Registrar
component is not co-located with the edge proxy element. The
procedures described in this section are identical, regardless of
transport protocol and so only one example will be documented in the
form of TCP.
The first step is for the clients to REGISTER. The flow for this Client NAT Proxy Registrar
+--------+
|Provider|
| Proxy |
| |
+---+----+
|
--------+----------
/////// \\\\\\\
/// \\\
|| || || ||
| Internet | |(1) REGISTER | | |
| | |----------------->| | |
| | | |(1) REGISTER | |
| |----------------->| |
| | |(2) REGISTER |
| | |----------------->|
| | |(3) 401 Unauth |
| | |<-----------------|
| |(4) 401 Unauth | |
| |<-----------------| |
|(4)401 Unauth | | |
|<-----------------| | |
|(5)REGISTER | | |
|----------------->| | |
| |(5)REGISTER | |
| |----------------->| |
| | |(6)REGISTER |
| | |----------------->|
| | |(7)200 OK |
| | |<-----------------|
|********************************************************|
| Create Connection Re-use Tuple |
|********************************************************|
| |(8)200 OK | |
| |<-----------------| |
|(8)200 OK | | |
|<-----------------| | |
|| || || ||
\\\ ///
\\\\\\\ ///////
---------+---------
| DSL, Cable
+--------+-------+
| Home NAT |
+----------------+
+--------+
| STUN |
| Agent |
| |
+--------+
+--------+ +----------+
| | | / \ |
| PC | /SIP \
| | /Phone \
| | / \
+--------+ ------------
Figure 11: STUN Agent Configuration
scenario is shown in Figure 12. First, the client sends a REGISTER
(message 1). This is a normal UDP REGISTER, and therefore the Contact
is likely to reflect an IP address within the home network:
Client STUN NAT Proxy STUN
Agent Server
|(1) REGISTER | | | |
|-------------->| | | |
| |(2) STUN Query | | |
| |src=10.0.1.2:10| | |
| |-------------->| | |
| | |(3) STUN Query | |
| | |src=1.2.3.4:5678 |
| | |------------------------------>|
| | |(4) STUN Response |
| | |addr = 1.2.3.4:5678 |
| | |dst=1.2.3.4:5678 |
| | |<------------------------------|
| |(5) STUN Response | |
| |addr = 1.2.3.4:5678 | |
| |dst=10.0.1.2:10| | |
| |<--------------| | |
| |Contact | | |
| |rewritten | | |
| |(6) REGISTER | | |
| |-------------->| | |
| | |(7) REGISTER | |
| | |-------------->| |
| | |(8) 200 OK | |
| | |<--------------| |
| |(9) 200 OK | | |
| |<--------------| | |
|(10) 200 OK | | | |
|<--------------| | | |
Figure 12: STUN Agent Registration
REGISTER sip:provider.com SIP/2.0
Via: SIP/2.0/UDP 10.0.1.1
From: sip:user@provider.com
To: sip:user@provider.com
Call-ID: 99asdasd98hnn
Contact: sip:user@10.0.1.1:5060
CSeq: 88790 REGISTER
Since the client is using a local outbound proxy, this REGISTER is Figure 7.
sent to the STUN agent. The STUN agent recognizes that this is a
registration, and determines that it needs to obtain an IP address
and port to use in the Contact which can route to it. So, it follows
the procedures that the client itself would have followed from
Section 2.2.1. Specifically, it acts as a STUN client, and sends a
Query request (message 2) to the provider.com STUN server. This goes
through the NAT (message 3), and is reflected off of the STUN server
(message 4) providing the STUN agent with a external IP address and
port that routes to it (message 5). This address is inserted as the
Contact header in a rewritten REGISTER message (message 6) that is
sent to the proxy. This outgoing REGISTER might look like:
REGISTER sip:provider.com SIP/2.0
Via: SIP/2.0/UDP 1.2.3.4:5678
From: sip:user@provider.com
To: sip:user@provider.com
Call-ID: 88sdasdlasd0
Contact: sip:user@1.2.3.4:5678
Translate: sip:user@1.2.3.4:5678
CSeq: 88790 REGISTER
This REGISTER is forwarded through the NAT (message 7), and the 200
OK response from the proxy/registar (message 8) is sent through the
NAT to the STUN agent (message 9). From this 200 OK, the STUN agent
knows whether or not the Translate header was used or not.
Its important to note that the STUN query need only be done for the
first REGISTER request. For subsequent ones, the STUN agent can reuse
the same binding. The binding must be refreshed (if it was used), of
course, but a new one need not be selected for each registration. The
Contact header in each registration from a different client would
have to contain a unique user name in order to disambiguate the
incoming requests from the proxy.
The final step is for the STUN agent to respond to the REGISTER
received from the client. The response contains the original Contact
sent in the REGISTER. The STUN agent also remembers this contact,
effectively acting as a registrar itself. This contact will be used
for incoming INVITE requests. The response sent to the client might
look like:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.1.1
From: sip:user@provider.com
To: sip:user@provider.com
Call-ID: 99asdasd98hnn
Contact: sip:user@10.0.1.1:5060
Expires:3600
CSeq: 88790 REGISTER
In this way, when the STUN agent receives an incoming INVITE with a
request URI of sip:user@1.2.3.4:5678, it knows to rewrite it to
sip:user@10.0.1.1:5060 and proxy the request there.
2.3.2 Initiating a Session
The call flow for initiating a session is shown in Figure 13. The
client formulates a normal INVITE (message 1), without SIP extensions
for NAT [9] or SDP extensions for RTCP [8]. It it is sent to the STUN
Agent as a local outbound proxy. This INVITE might look like:
INVITE sip:user@school.edu SIP/2.0
Via: SIP/2.0/UDP 10.0.1.1
From: sip:user@provider.com
To: sip:user@school.edu
Call-ID: 99asdas88shnn
Contact: sip:user@10.0.1.1:5060
Content-Type: application/sdp
Content-Length: ...
v=0 This scenario builds on that contained in section 4.1.1.2. This time
o=aa 2890844526 2890842807 IN IP4 10.0.1.1 the REGISTER request is routed onwards to a separated Registrar. The
c=IN IP4 10.0.1.1 important message to note is (5) in Figure 7. At this point, the
t=0 0 proy server routes the SIP REGISTER message to the Registrar. The
m=audio 9988 RTP/AVP 0 proxy will create the connection re-use tuple at the same moment as
the co-located example but for subsequent messages to arrive at the
Proxy, the element needs to request to stay in the signaling path.
REGISTER message (5) contains a SIP PATH extension header, as defined
in RFC 3327 [6]. REGISTER message (5) would look as follows:
The STUN Agent needs to do several things. First, it must rewrite the REGISTER sip:registrar.example.com SIP/2.0
Contact header to reference the signaling address bound to Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4njkca8398hadjaa
sip:user@10.0.1.1:5060 from the previous registration process (in Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKyilassjdshfu
this case, sip:user@1.2.3.4:5678). Secondly, it rewrites the SDP to Max-Forwards: 70
include addresses learned from STUN, in much the same way the client Supported: gruu
learned them in Section 2.2.1 (messages 2-5 and message 6-9). It also From: Client <sip:client@example.com>;tag=djks809834
adds its own Via address to the outgoing INVITE (message 10), which To: Client <sip:client@example.com>
might look like: Call-ID: 763hdc783hcnam73@example.com
CSeq: 1 REGISTER
Path: <sip:sip%3Aclient%40example.com@proxy.example.com;lr>
Contact: <sip:client@client.example.com;transport=tcp>; connectioId=1
;+sip.instance="<urn:uuid:00000000-0000-0000-0000-000A95A0E121>"
Content-Length: 0
INVITE sip:user@school.edu SIP/2.0 This results in the path header being stored along with the AOR and
Via: SIP/2.0/TCP 1.2.3.4:5678 it's associated binding at the Registrar. The URI contained in the
Via: SIP/2.0/UDP 10.0.1.1 PATH will be inserted as a pre-loaded SIP 'Route' header into any
From: sip:user@provider.com request that arrives at the Registrar and is directed towards the
To: sip:user@school.edu associated binding. This guarantees that all requests for the new
Call-ID: 99asdas88shnn Registration will be forwarded to the edge proxy. The user part of
Contact: sip:user@1.2.3.4 the SIP 'Path' header URI that was inserted by the edge proxy
Content-Type: application/sdp contains an escaped form of the original AOR that was contained in
Content-Length: ... the REGISTER request. On receiving subsequent requests, the edge
proxy will examine the user part of the pre-loaded SIP 'route' header
and extract the original AOR for use in it's connection tuple
comparison, as defined in the connection re-use draft[8]. An
example which will build on this scenario (showing an inbound request
to the AOR) is detailed in section 4.1.4.2 of this document.
v=0 4.1.3 Initiating a Session
o=aa 2890844526 2890842807 IN IP4 1.2.3.4
c=IN IP4 1.2.3.4
t=0 0
m=audio 5679 RTP/AVP 0
a=rtcp:5688
a=direction:both
There is a subtle error here, in that 1.2.3.4:5678 is the This section covers basic SIP signaling when initiating a call from
UDP address learnt from STUN. This can't be used in the Via behind a NAT.
header sent over a TCP connection.
The 200 OK to this INVITE will be received by the STUN Agent (message 4.1.3.1 UDP
13). This 200 OK need not be rewritten if it does not contain a
direction or rtcp attribute. In that case, media flows out from the
client directly towards the address in the 2xx, and media flows in
first through the intermediary, and then towards the client. Let us
consider the case where the 200 OK does include an a=rtcp attribute:
SIP/2.0 200 OK Initiating a call using UDP.
Via: SIP/2.0/TCP 1.2.3.4:5678
Via: SIP/2.0/UDP 10.0.1.1
From: sip:user@provider.com
To: sip:user@school.edu;tag=909asd
Call-ID: 99asdas88shnn
Contact: sip:user@56.66.77.88
Content-Type: application/sdp
Content-Length: ...
v=0 Client NAT Proxy [..]
o=aa 2890844526 2890842807 IN 56.66.77.88 | | |
c=IN IP4 56.66.77.88 |(1) INVITE | | |
t=0 0 |----------------->| | |
m=audio 56496 RTP/AVP 0 | |(1) INVITE | |
Client STUN Agent NAT STUN Proxy | |----------------->| |
Server | |(2) 407 Unauth | |
|(1) INVITE | | | | | |<-----------------| |
|rtp=10.0.1.1:7460 | | | |(2) 407 Unauth | | |
|-------------->| | | | |<-----------------| | |
| |(2) STUN Query | | | |(3) INVITE | | |
| |src=10.0.1.2:5306 | | | |(3) INVITE | |
| |-------------->| | | | |----------------->| |
| | |(3) STUN Query | | | | |(4) INVITE |
| | |src=1.2.3.4:5679 | | | |---------------->|
| | |-------------->| | | | |(5)180 RINGING |
| | |(4) STUN Resp. | | | | |<----------------|
| | |addr=1.2.3.4:5679 | | |(6)180 RINGING | |
| | |dst=1.2.3.4:5679 | | |<-----------------| |
| | |<--------------| | |(6)180 RINGING | | |
| |(5) STUN Resp. | | | |<-----------------| | |
| |addr=1.2.3.4:5679 | | | | |(7)200 OK |
| |dst=10.0.1.2:5306 | | | | |<----------------|
| |<--------------| | | | |(8)200 OK | |
| |(6) STUN Query | | | | |<-----------------| |
| |src=10.0.1.2:5307 | | |(8)200 OK | | |
| |-------------->| | | |<-----------------| | |
| | |(7) STUN Query | | |(9)ACK | | |
| | |src=1.2.3.4:5688 | |----------------->| | |
| | |-------------->| | | |(9)ACK | |
| | |(8) STUN Resp. | | | |----------------->| |
| | |addr=1.2.3.4:5688 | | | |(10) ACK |
| | |dst=1.2.3.4:5688 | | | |---------------->|
| | |<--------------| | | | |(11) |
| |(9) STUN Resp. | | |
| |addr=1.2.3.4:5688 | |
| |dst=10.0.1.2:5307 | |
| |<--------------| | |
| |(10) INVITE | | |
| |rtp=1.2.3.4:5679 | |
| |rtcp=1.2.3.4:5688 | |
| |contact=1.2.3.4:5678 | |
| |-------------->| | |
| | |(11) INVITE | |
| | |rtp=1.2.3.4:5679 |
| | |rtcp=1.2.3.4:5688 |
| | |contact=1.2.3.4:5678 |
| | |------------------------------>|Proxy
| | | | |forwards
| | | | |INVITE,
| | | | |response
| | | | |comes
| | |(12) 200 OK | |
| | |<------------------------------|
| |(13) 200 OK | | |
| |<--------------| | |
|(14) 200 OK | | | |
|<--------------| | | |
|(15) ACK | | | |
|-------------->| | | |
| |(16) ACK | | |
| |-------------->| | |
| | |(17) ACK | |
| | |------------------------------>|
Figure 13: Initiating a session with a STUN Agent Figure 8.
a=rtcp:36485
Since the client doesn't support the RTCP extensions for SDP, the The initiating client generates an INVITE request that is to be sent
STUN Agent needs to allocate a port pair on the host which it can through the NAT to a Proxy server. The INVITE message is represented
rewrite into this 200 OK before forwarding. No STUN requests are in Figure 8 by (1) and is as follows:
needed to allocate this port pair; its local on the STUN Agent. The
forwarded 200 OK might look like:
SIP/2.0 200 OK INVITE sip:clientB@example.com SIP/2.0
Via: SIP/2.0/UDP 10.0.1.1 Via: SIP/2.0/UDP client.example.com:5060;rport;branch=z9hG4bK74husdHG
From: sip:user@provider.com Max-Forwards: 70
To: sip:user@school.edu;tag=909asd Route: <sip:proxy.example.com;lr>
Call-ID: 99asdas88shnn From: clientA <sip:clientA@example.com>;tag=7skjdf38l
Contact: sip:user@56.66.77.88 To: clientB <sip:clientB@example.com>
Call-ID: 8327468763423@example.com
CSeq: 1 INVITE
Contact: <sip:im_a_gruu@proxy.example.com>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: ... Content-Length: ..
v=0
o=aa 2890844526 2890842807 IN 56.66.77.88
c=IN IP4 10.0.1.2
t=0 0
m=audio 4372 RTP/AVP 0
The media flow for this case is shown in Figure 14. As the flow
shows, both RTP and RTCP in and out flow through the STUN Agent. In
the case of outgoing RTP and RTCP, the media is sent on the sockets
used to send the STUN queries, and addressed to the addresses and
ports from the 200 OK. For incoming RTP and RTCP, its received on the
sockets used for the stun queries, and from there, forwarded out to
the address in the original INVITE from the client. Notice how the
STUN Agent can guarantee that media sent to and from the client has
adjacent RTP and RTCP ports.
2.3.3 Receiving an Invitation to a Session
The call flow for handling an incoming INVITE is shown in Figure 15.
As expected, this is a mirror image of the outgoing INVITE case 13.
We have simplified this flow, however, and assumed that the incoming
INVITE (message 2) did not require the usage of SDP attributes for
RTCP or connection oriented media. As a result, the INVITE can be
passed directly to the client (message 3). The 200 OK returned by the
client (message 4) contains an SDP media address that needs to be
rewritten by the agent.
Media from the caller to the callee will flow first through the STUN
Agent. From there it is forwarded to the callee (using adjacent
RTP/RTCP ports on this leg). However, media from the callee flows
directly to the caller at the address specified in the incoming
INVITE.
2.4 Solution IV: ALG
Another solution for the residential case is to throw away your NAT,
and buy one with an embedded ALG inside. This will allow SIP to work
transparently through it without any additional infrastructure on the
service provider or residence side. It will not require any changes
to the clients either.
The primary drawback to this approach is its impracticality. At the
time of writing, there is only one residential NAT product available
with SIP support. This product is not from a maintstream vendor, and
at the time of writing, it is still missing features that are
generally baseline requirements for such a device. Whilst this will
certainly be corrected in a future product release, its symptomatic
of the bigger problem - the manufacturer of a residential NAT cannot,
and won't, be the expert in all application protocols that would need
ALG support. Similarly, a vendor that specializes in a NAT supporting
a particular ALG, won't be the expert in other general purpose NAT
features, or in other protocols.
Protocols also evolve, so that even if SIP support were added today,
its not clear that this would support the extensions being developed
tomorrow.
A further problem is that there is a large, installed based of
residential NATs that are not SIP aware. It is unlikely that users
would be willing to pay money to buy a new box to support a
particular application. Most users would expect that the provider
would simply "make it work". Asking the user to purchase a new, SIP
enabled ALG is putting the responsibility for making it work into the
wrong hands. This is coupled with the fact that consumers are
generally ignorant of technology, and would not be able to identify
and purchase a NAT that had SIP "ALG" support in it. Certainly, most
providers in existence today are not willing to wait for this massive
upgrade to happen. They need a way to provide service now. Providers
are motivated to change or upgrade equipment that they control (their
own servers, the client software, hardphones) in order to provide
service, but users are not generally motivated to change equipment
for a new application. Therefore, we believe that waiting for SIP ALG
user@provider.com STUN Agent NAT user@school.edu
|(1) RTP | | |
|src=10.0.1.1:9988 | |
|dst=10.0.1.2:4372 | |
|-------------->| | |
| |(2) RTP | |
| |src=10.0.1.2:5306 |
| |dst=56.66.77.88:56496 |
| |-------------->| |
| | |(3) RTP |
| | |src=1.2.3.4:5679
| | |dst=56.66.77.88:56496
| | |-------------->|
|(4) RTCP | | |
|src=10.0.1.1:9989 | |
|dst=10.0.1.2:4373 | |
|-------------->| | |
| |(5) RTCP | |
| |src=10.0.1.2:5307 |
| |dst=56.66.77.88:36485 |
| |-------------->| |
| | |(6) RTCP |
| | |src=1.2.3.4:5688
| | |dst=56.66.77.88:36485
| | |-------------->|
| | |(7) RTP |
| | |src=56.66.77.88:56496
| | |dst=1.2.3.4:5679
| | |<--------------|
| |(8) RTP | |
| |src=56.66.77.88:56496 |
| |dst=10.0.1.2:4372 |
| |<--------------| |
|(9) RTP | | |
|src=10.0.1.2:4372 | |
|dst=10.0.1.1:9988 | |
|<--------------| | |
| | |(10) RTCP |
| | |src=56.66.77.88:36485
| | |dst=1.2.3.4:5688
| | |<--------------|
| |(11) RTCP | |
| |src=56.66.77.88:36485 |
| |dst=10.0.1.2:5307 |
| |<--------------| |
|(12) RTCP | | |
|src=10.0.1.2:4373 | |
|dst=10.0.1.1:9989 | |
|<--------------| | |
Figure 14: Media flow for STUN Agent
Client STUN Agent NAT STUN Proxy
Server
| | |(1) INVITE | |
| | |<------------------------------|
| |(2) INVITE | | |
| |<--------------| | |
|(3) INVITE | | | |
|<--------------| | | |
|(4) 200 OK | | | |
|rtp=10.0.1.1:7612 | | |
|-------------->| | | |
| |(5) STUN Query | | |
| |src=10.1.2.3:1928 | |
| |-------------->| | |
| | |(6) STUN Query | |
| | |src=9.8.7.6:9988 |
| | |-------------->| |
| | |(7) STUN Resp. | |
| | |addr=9.8.7.6:9988 |
| | |dst=9.8.7.6:9988 |
| | |<--------------| |
| |(8) STUN Resp. | | |
| |addr=9.8.7.6:9988 | |
| |dst=10.1.2.3:1928 | |
| |<--------------| | |
| |(9) STUN Query | | |
| |src=10.1.2.3:1929 | |
| |-------------->| | |
| | |(10) STUN Query |
| | |src=9.8.7.6:8877 |
| | |-------------->| |
| | |(11) STUN Resp. |
| | |addr=9.8.7.6:8877 |
| | |dst=9.8.7.6:8877 |
| | |<--------------| |
| |(12) STUN Resp. | |
| |addr=9.8.7.6:8877 | |
| |dst=10.1.2.3:1929 | |
| |<--------------| | |
| |(13) 200 OK | | |
| |rtp=9.8.7.6:9988 | |
| |rtcp=9.8.7.6:8877 | |
| |contact=9.8.7.6:7766 | |
| |-------------->| | |
| | |(14) 200 OK | |
| | |rtp=9.8.7.6:9988 |
| | |rtcp=9.8.7.6:8877 |
| | |contact=9.8.7.6:7766 |
| | |------------------------------>|
| | | | |200 OK
| | | | |forwarded
| | | | |upstream
| | |(15) ACK | |
| | |<------------------------------|
| |(16) ACK | | |
| |<--------------| | |
|(17) ACK | | | |
|<--------------| | | |
Figure 15: Incoming INVITE, STUN Agent
support in residential NATs is an untenable proposition from a
business perspective.
3 Uncooperative Enterprise
The "uncooperative enterprise" case arises when there are users
within an enterprise that wish to access service from a provider on
the public Internet. However, the enterprise uses a firewall or NAT.
The enterprise has not deployed VoIP, and has not added any explicit
configuration to support SIP, nor is there desire to do so.
This case is actually identical to the residential case for the most
part. Nearly all of the solutions for that environment can be used
here, but there are some differences.
First, the configuration trick of Section 2.1 does not work. That
trick required that the user of the VoIP application had
administrative control over the NAT. This is true in the residential
case, but not in the enterprise case.
Secondly, enterprise NATs often include firewall functionality and [SDP not shown]
are more restrictive than the general NAT. At the extreme, they may
even block all UDP traffic in and out. In these cases, there are few
elegant or good solutions. The only workable approaches are the
tunneling and VPN solutions. However, these are risky since they can
introduce security weaknesses into the enterprise, and go against the
enterprise policy that the firewall/NAT is trying to enforce in the
first place.
If the enterprise firewall/NAT is not any more restrictive than the There are a number of points to note with this message:
typical residential NAT (will allow outgoing UDP and TCP), the 1. Firstly, as with the registration example in section 4.1.1.1,
residential solutions all work fine. reponses to this request will not automatically pass back through
a NAT and so the SIP 'Via' header 'rport' is included as
described in the 'Symmetric response' section(3.1.1) and defined
in RFC 3581 [5].
2. Secondly, the contact inserted contains the GRUU previously
obtained from the registration.
3. [Editors Note: TODO - Expand description of GRUU and connection
re-use]
4 Cooperative Enterprise 4.1.3.2 Reliable Transport
In this scenario, there is an enterprise which wishes to deploy SIP [Editors note: TODO]
services. There is no public provider involved at all; the enterprise
takes full control. In this case, the enterprise firewall
administrators do have the ability to manipulate the configuration of
the firewall/NAT if neeeded, or to add and deploy additional elements
inside of the network.
4.1 Solution I: ALG 4.1.4 Receiving an Invitation to a Session
With this solution, the enterprise upgrades their firewall, or This section details sceanrios where a client behind a NAT receives
purchases a new firewall, to run software with an integrated SIP ALG. an inbound request through the NAT. These scenarios build on the
The NAT/Firewall examines each SIP request, and modifies the Contact, previous registration sceanrio from sections 4.1.1 and 4.1.2 in this
session description, and Vias as appropriate. Note that this approach document.
does not work if the SIP messages are hop-by-hop encrypted (using for
example TLS) unless the NAT/Firewall also acts as a SIP proxy server.
Call flows for SIP ALGs have been documented in [6]. 4.1.4.1 Registrar/Proxy Co-located
In addition, the enterprise deploys proxies internal to the The core SIP signaling associated with this call flow is not impacted
enterprise. The NAT is configured with a static mapping or "conduit" directly by the transport protocol and so only one example scenario
for each of these internal SIP servers from public IP addresses is necessary. The example uses UDP and follows on from the
(typically on the well-know SIP port--5060) to their internal IP registration installed in the example from section 4.1.1.1.
addresses. The Enterprise can then advertise these public addresses
in DNS A or SRV records. This configuration is shown in Figure 16.
---------- Client NAT Registrar/Proxy SIP Entity
//// \\\\
|| Public ||
| Internet |
| |
|| || || ||
\\\\ //// |*******************************************************|
---------- | Registration Binding Installed in |
| | | section 4.1.1.1 |
| | |*******************************************************|
1.2.3.4:5060 | | 1.2.3.5:5060 | | | |
+-----=-=------+ | | |(1)INVITE |
| = = | | | |<----------------|
| = = | Enterprise NAT | |(2)INVITE | |
| = = | | |<-----------------| |
+-----=-----=--+ |(2)INVITE | | |
| \ |<-----------------| | |
| |
+----+ +----+
| | | | | | | |
| | | | | | | |
+----+ +----+
Proxy 1 Proxy 2
10.1.1.1 10.1.1.2
:5060 :5060
Figure 16: Enterprise ALG Configuration
Registration is performed entirely inside the enterprise network. SIP
UAs inside the network can communicate with each other directly. SIP
UAs wishing to communicate with the outside world need to go through
the enterprise SIP proxy.
When initiating a session outside the enterprise, the NAT/FW rewrites Figure 9.
portions of the SIP INVITE and offered session description to contain
public IP addresses. The NAT/Firewall also assigns a pairs of public
ports for RTP and RTCP as needed, maps these to the private addresses
and ports included in the original session description, and allows
incoming traffic to these ports from the public internet.
For example, the following INVITE might be rewritten as shown in the The core SIP signaling associated with this call flow is not impacted
next example. directly by the transport protocol and so only one example scenario
is necessary. The example uses UDP and follows on from the
registration installed in section 4.1.1.1. An INVITE request arrives
at the Registrar with a destination pointing to the AOR of that
inserted in section 4.1.1.1. The message is illustrated by (1) in
Figure 9 and looks as follows:
INVITE sip:user@domain SIP/2.0 INVITE sip:client@example.com SIP/2.0
From: sip:user@work.com;tag=88asd Via: SIP/2.0/UDP external.example.com;branch=z9hG4bK74huHJ37d
To: sip:user@domain Max-Forwards: 70
Call-ID: 98asd6asd60099 From: External <sip:External@external.example.com>;tag=7893hd
CSeq: 987769 INVITE To: client <sip:client@example.com>
Via: SIP/2.0/UDP 10.1.1.5 Call-ID: 8793478934897@external.example.com
Via: SIP/2.0/UDP proxy1.work.com;maddr=10.1.1.1 CSeq: 1 INVITE
Record-Route: proxy1.work.com Contact: <sip:external@192.0.1.4>
Contact: sip:10.1.1.5:5060
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: ... Content-Length: ..
v=0 [SDP not shown]
o=aa 2890844526 2890842807 IN IP4 10.1.1.5
c=IN IP4 10.1.1.5
t=0 0
m=audio 17832 RTP/AVP 0
The same example INVITE shown rewritten. The INVITE matches the registration binding at the Registrar and the
INVITE request-URI is re-written to the selcted onward address. The
proxy then examines the request URI of the INVITE and compares with
it's list of current open connections/mappings. It uses the incoming
AOR to commence the check for associated open connections/mappings.
Once matched, the proxy checks to see if the unique instance
identifier (+sip.instance)associated with the binding equals the same
instance identifier associated with the binding. If more than one
results are matched, the lowest 'connectionID' Contact parameter will
be used. This is message (2) from Figure 9 and is as follows:
INVITE sip:user@domain SIP/2.0 INVITE sip:sip:client@client.example.com SIP/2.0
From: sip:user@work.com;tag=88asd Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4kmlds893jhsd
To: sip:user@domain Via: SIP/2.0/UDP external.example.com;branch=z9hG4bK74huHJ37d
Call-ID: 98asd6asd60099 Max-Forwards: 70
CSeq: 987769 INVITE From: External <sip:External@external.example.com>;tag=7893hd
Via: SIP/2.0/UDP 10.1.1.5 To: client <sip:client@example.com>
Via: SIP/2.0/UDP proxy1.work.com;maddr=1.2.3.4:5060 Call-ID: 8793478934897@external.example.com
Record-Route: proxy1.work.com CSeq: 1 INVITE
Contact: sip:1.2.3.6:7843 Contact: <sip:external@192.0.1.4>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: ... Content-Length: ..
v=0
o=aa 2890844526 2890842807 IN IP4 10.1.1.5
c=IN IP4 1.2.3.4
t=0 0
m=audio 5678 RTP/AVP 0
Likwise, when receiving sessions, the NAT/FW rewrites the answered
session description. Note that the NAT/FW should be prepared to
rewrite an offer in a 200, and an answer in an ACK.
4.2 Solution II: MIDCOM Firewall and Proxy
In this approach, the enterprise purchases a firewall/NAT which uses
some type of firewall control protocol such as the protocol being
developed in the MIDCOM Working Group. A SIP proxy inside the network
performs the stateful inspection and ALG rewriting logic that was
imbedded in the firewall in scenario 5.1. The proxy then opens and
closes pinholes in the firewall or creates and destroys NAT mappings
as needed to allow SIP and session media to flow through the
middlebox. This approach is being discussed in depth in the MIDCOM
WG, so we will not elaborate here.
4.3 Solution III: Internal B2BUAWM
In this solution, the enterprise does not need to change their NAT or
firewall to get one with ALG support. Instead, they add an additional
element inside the enterprise, which we call a "Back to Back User
Agent With Media" or B2BUAWM. This element terminates all media and
all SIP traffic in and out of the enterprise. As a result, the
administrator of the firewall can configure the firewall to allow all
traffic in and out from the B2BUAWM. Similarly, if NAT is used, a
static mapping of a single public address to the private address of
the B2BUAWM can be configured (i.e., using basic NAT, not NAPT), or,
a range of ports can be allocated to the B2BUAWM. The media relay
component of the B2BUAWM can also be physically separated, using a
control protocol, like MGCP [18] or MEGACO [19], between them.
Effectively, the B2BUAWM acts as a "DMZ host" for the SIP and media
traffic.
In the example of Figure 17, an enterprise NAT is configured to map
ports 4000 through 4009 from 1.2.3.4 (the public address of the NAT)
-------------
///// \\\\\
// \\
| Public Internet |
| |
| |
\\ //
\\\\\ /////
-------------
1.2.3.4
+------::---=-=-=-=-=------+
| SIP :: = = = = = RTP |
| 5060 :: = = = = = 4000-| NAT
| :: = = = = = 4009 |
+------::---=-=-=-=-=------+
10.1.1.1 :: = = = = =
:: = = = = =
:: = = = = =
:: = = = = =
+---------------+
10.1.1.2 | |
| B2BUA w/Media |
| |
+---------------+
/ : : | : \
/ : : | : \
/ : : | : \
+----+ +----+ +----+
| | | | | |
| | | | | |
+----+ +----+ +----+
UA 1 UA 2 UA 3
10.1.1.5 10.1.1.6 10.1.1.7
Figure 17: B2BUAWM for the Enterprise
to 10.1.1.2 (the private address of the media relay). The NAT is
likewise configured to forward public SIP traffic on port 5060 to the
B2BUA.
The B2BUA will rewrite all Contact and Via headers to appear as if
they are coming from the public or private address of the B2BUA. This
process is pretty much identical to the process that a SIP ALG inside
of a NAT would use.
Proxy/
UA B2BUA NAT Far UA
| | | |
| | | |
| | | |
|--INVITE------->| | |
| c=10.1.1.7 |---INVITE-------->|---------------->|
| m=audio 8238 | c=1.2.3.4 | |
| | m=audio 4002 | 200 OK |
| | | c=6.7.8.9 |
| | | m=audio 17242 |
| |<-----------------|<----------------|
|<-200 OK--------| | |
| c=10.1.1.2 | | |
| m=audio 4002 | | |
| | | |
|--ACK---------->| | |
| |----ACK---------->|---------------->|
| | | |
| | | |
|==RTP / RTCP===>|====RTP / RTCP===>|==RTP / RTCP====>|
| src=10.1.1.7 | src=10.1.1.2 | src=1.2.3.4 |
| dst=10.1.1.2 | dst=6.7.8.9 | dst=6.7.8.9 |
| :4002/3 | :17242/3 | :17242/3 |
| | | |
|<=RTP / RTCP====|<===RTP / RTCP====|<=RTP / RTCP=====|
| src=10.1.1.2 | src=6.7.8.9 | src=6.7.8.9 |
| dst=10.1.1.7 | dst=10.1.1.2 | dst=1.2.3.4 |
| :8238/9 | :4002/3 | :4002/3 |
| | | |
| | | |
|--BYE---------->|----------------->|---------------->|
|----------------|------------------|<-200 OK---------|
Figure 18: Enterprise with B2BUAWM: Outgoing Invite
The B2BUA will allocate pairs of RTP/RTCP ports from its statically
mapped pool, and rewrite the session description and each message, so
that private addresses are translated to public addresses and vice
versa. Figure 18 shows the call flow for an outgoing INVITE, and
Figure 19 shows the call flow for an incoming INVITE.
Proxy/
UA B2BUA NAT Far UA
| |<-----------------|<-INVITE---------|
|<-INVITE--------| | c=6.7.8.9 |
| c=10.1.1.2 | | m=audio 17242 |
| m=audio 4002 | | |
| | | |
|--200 OK------->| | |
| c=10.1.1.7 |---200 OK-------->|---------------->|
| m=audio 8238 | c=1.2.3.4 | |
| | m=audio 4002 | |
| | | |
| |<-----------------|<-ACK------------|
|<-ACK-----------| | |
| | | |
| | | |
|==RTP / RTCP===>|====RTP / RTCP===>|==RTP / RTCP====>|
| src=10.1.1.7 | src=10.1.1.2 | src=1.2.3.4 |
| dst=10.1.1.2 | dst=6.7.8.9 | dst=6.7.8.9 |
| :4002/3 | :17242/3 | :17242/3 |
| | | |
|<=RTP / RTCP====|<===RTP / RTCP====|<=RTP / RTCP=====|
| src=10.1.1.2 | src=6.7.8.9 | src=6.7.8.9 |
| dst=10.1.1.7 | dst=10.1.1.2 | dst=1.2.3.4 |
| :8238/9 | :4002/3 | :4002/3 |
| | | |
Figure 19: Enterprise with B2BUAWM: Incoming Invite
5 Outsourced Service: Centrex
In the outsourced service scenario (also known as Centrex), the
enterprise wishes to deploy the SIP service, but does so by
outsourcing it to a provider in the public Internet.
5.1 Solution I: ALG
In this solution, the enterprise upgrades their firewall/NAT to
include SIP ALG support. Unlike the cooperative enterprise case
above, there is no need to deploy any proxies or additional elements
inside the network (that is the point of Centrex). Clients within the
enterprise register directly with the proxies owned and provided by
the Centrex provider. This means that the ALG needs to rewrite
REGISTER messages, in addition to INVITE/200/ACK messages. This is in
contrast to an ALG deployed to support a cooperative enterprise. In
that scenario, registrations are confined to the enterprise and never
traverse the firewall/NAT.
This configuration is shown in Figure 20. The enterprise only has
clients. These clients are configured with the IP address of the
proxy in the provider's network that they will be using. The
enterprise configures its DNS so that SRV lookups on its domain names
for SIP service (i.e., _sip._udp.enterprise.com) route to the
provider's proxies.
A call flow for a registration, followed by an incoming call, is
shown in Figure 21.
When the clients start up, they send REGISTER requests to this proxy
(message 1). The ALG is responsible for rewriting the Contact in the
registrations. The bindings allocated for the Contact headers are set
with a long lifetime, generally equal to the lifetime of the Expires
header in the request (this lifetime could be modified by a different
expiration in the response).
So, for example, the REGISTER sent by a client (message 1) might look
like:
REGISTER sip:enterprise.com SIP/2.0
From: sip:user12@enterprise.com
To: sip:user12@enterprise.com
Contact: sip:user12@10.0.1.1:5060
CSeq: 86590 REGISTER
Via: SIP/2.0/UDP 10.0.1.1
Call-ID: 9adjasd88
The ALG would rewrite this, and the resulting registration (message
2) might look like:
REGISTER sip:enterprise.com SIP/2.0
From: sip:user12@enterprise.com
To: sip:user12@enterprise.com
...................................................
. .
. +------+ Centrex .
. | | Provider .
. +------+ | Proxy Farm .
. | | | .
. | | | .
. | |-+ .
. +------+ .
. .
. .
.Provider | .
........................|..........................
|
|Provider Access (Internet,
+---------+ private connection)
|Enterpris|
..................|. FW/NAT |.....................
. | w/ ALG | Enterprise .
. +---------+ .
. .
. .
. .
. .
. .
. .
. .
. /\ /\ .
. /\ / \ /\ / \ .
. / \ / \ / \ / \ .
. / \ /Client\ / \ /Client\ .
. /Client\ ---------- /Client\ ---------- .
. ---------- ---------- .
..................................................
Figure 20: Centrex ALG Configuration
Contact: sip:user12@1.2.3.4:8875
CSeq: 86590 REGISTER
Via: SIP/2.0/UDP 1.2.3.4:8875
Call-ID: 9adjasd88
Client Enterprise Proxy
NAT
|(1) REGISTER | |
|contact=10.0.1.1 | |
|-------------------->| |
| |(2) REGISTER |
| |contact=1.2.3.4:8875 |
| |-------------------->|
| |(3) 200 OK |
| |<--------------------|
|(4) 200 OK | |
|<--------------------| |
| | |Call received
| |(5) INVITE |
| |sip:user12@1.2.3.4:8875
| |<--------------------|
|(6) INVITE | |
|sip:user12@10.0.1.1 | |
|<--------------------| |
|(7) 200 OK | |
|-------------------->| |
| |(8) 200 OK |
| |-------------------->|
| |(9) ACK |
| |<--------------------|
|(10) ACK | |
|<--------------------| |
Figure 21: Incoming Call, Centrex ALG
The ALG would remember the association (1.2.3.4:8875, 10.0.1.1:5060)
for one hour (the default registration expiration). This REGISTER
would arrive at the provider proxy, and the registration stored
there.
When an INVITE arrives at the provider proxy for
sip:user12@enterprise.com, the proxy translates this to
sip:user12@1.2.3.4:8875 (message 5), and forwards the INVITE. This
arrives at the ALG. The ALG rewrites the request URI to the
translated address, sip:user12@10.0.1.1, and forwards it to the
client (message 6). The ALG will also need to rewrite the SDP and
Contact in the 2xx (message 7).
5.2 Solution II: External B2BUAWM
In this solution, the service provider uses a "Back to Back User
Agent with Media" instead of a proxy. This can be viewed as an
integration of the proxy and the TURN server into an application
specific solution.
With this solution, there is no need for the enterprise to deploy an
ALG.
There are two main components of the solution - one addressing the
control/signaling path issues, and the other, the media path. The
signaling path component consists of a stateful Signaling Proxy
server exhibiting some distinct behavior to be discussed later. The
media path component consists of a Media Proxy server. In the context
of SIP and RTP, the signaling path component will be a SIP Proxy
server called Back-to-Back-User-Agent (BBUA) and the media path
component is an RTP Proxy, as shown in Figure 22. The signaling and
media proxies interact using some control protocol, which is
transparent to the end users.
5.2.1 Signaling Path
The following prerequisites must be met in order for the solution to
work:
o The solution described here, relies on the principle that
connections from within the Enterprise are allowed out and
that the corresponding responses to those connections are
allowed back in (as in case of Traditional NAT's). This
enables the end points inside the enterprise to maintain a
connection to the Signaling server via a "keep-alive"
mechanism.
o All signaling messages must travel via the Signaling Proxy.
The SIP Signaling Proxy server with whom the UA registered
must be the one through which all incoming (outgoing) calls
are routed to (from) the UA.
o The SIP Signaling Proxy server must be one hop away from the
UA.
o The destination port of the requests at the Signaling Proxy
server is the same as the source port of the corresponding
responses.
In the example configuration shown in Figure 22, the signaling path [SDP not shown]
is established when the SIP UA's register with the corresponding
Proxy/Register (Signaling server). The SIP REGISTER message contains
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . It is a standard SIP INVITE request with no additional functionality.
Service Provider The major difference being that this request will not follow the
address specified in the Request-URI, as standard SIP rules would
enforce but will be sent on the connection/mapping associated with
the registration binding. This then allows the original
connection/mapping from the initial registration process to be
re-used.
+-------+ +-------+ 4.1.4.2 Registrar/Proxy Not Co-located
| SIP | | SIP |
| Proxy |+ + + + + + + + +| Proxy |
| X' | | Y' |
| |\ | |
+-------+ \ +-------+
+ \+---------+ +
+ | | +
+ |RTP Proxy| +
+ ^ ^ ^ | |^ ^ ^ +
+ ^ +---------+ ^ +
. . . + . . ^ . . . . . . . . . . . . . . ^ . + . . .
+ ^ ^ +
+ ^ ^ +
+---------+ +---------+
........|Symmetric|........... .........|Symmetric|........
. | NAT/FW | . . | NAT/FW | .
. +---------+ . . +---------+ .
. + ^ . . ^ + .
. + ^ . . ^ + .
. + ^ . . ^ + .
. + ^ . . ^ + .
. +-------+ . . +-------+ .
. | SIP UA| . . | SIP UA| .
. | X | . . | Y | .
. +-------+ . . +-------+ .
.............................. ............................
Enterprise Enterprise Client NAT Proxy Registrar SIP Entity
| | | | |
|***********************************************************|
| Registrtion Binding Installed in |
| section 4.1.2 |
|***********************************************************|
| | | |(1)INVITE |
| | | |<-------------|
| | |(2)INVITE | |
| | |<-------------| |
| |(3)INVITE | | |
| |<-------------| | |
|(3)INVITE | | | |
|<-------------| | | |
| | | | |
| | | | |
Figure 9.
++++ Control path for media 4.2 Basic NAT Media Traversal
^^^^ Media path
---- Control path between
Signaling and Media Proxies
Figure 22: B2BUAWM Configuration 4.2.1 Full Cone NAT
an extension tag carried in the Proxy-Require header, indicating to 4.2.1.1 STUN Solution
the Proxy that the client is behind a NAT (Note: the client or the
Proxy does not care about the type of NAT, as the same solution
applies to all types). This packet is NAT-ed by the Enterprise NAT
with a new source IP address and port. If the Proxy supports the
extension tag, it creates an association between the IP address and
port from which the packet arrived and the actual address of the
user. The response to the Registration message is sent to this IP
address and port (not to the Contact address in the REGISTER).
Once the signaling path is established, this can be used to send 4.2.1.1.1 Initiating Session
subsequent requests and responses to the user using the above
association stored at the Proxy, i.e., the request is sent (as above)
to the address/port assigned by the NAT instead of to the actual
address of the user. All requests and responses must be routed via
this Signaling Proxy. All requests from the user should carry the
Proxy-require header with the special tag indicating that it is
behind NAT/FW.
The signaling path is always kept open through the NAT using a keep- 4.2.1.1.2 Receiving Session Invitation
alive mechanism. This can be done using REGISTER refreshes as
proposed in [9]. One disadvantage of using the REGISTER method for
this purpose is it forces frequent (at least once every minute),
unnecessary involvement on the part of the Registrar. In this
solution, "keep-alive" is achieved by periodically sending a new
lightweight SIP method from the UA to the Server designed
specifically for this purpose. The new SIP method is called PING and
contains the following mandatory SIP headers: From, To, Via, Proxy-
require, Contact, Call-id, Cseq. The Proxy Server responds to the
PING method with a 200 OK final response. The timeout values in
Firewalls and NAT's are observed to be between 1 to 3 mins and the
"keep-alive" frequency must be higher than this. This keep-alive
mechanism must continue during the call.
The public IP address/port allocated by the NAT is returned to the 4.2.1.2 ICE Solution
Client in the Contact header of 200 OK sent by the Proxy server. This
allows the UA to perform NAT/FW failure detection by - (a) not
receiving 200 OK over a prolonged period of time, and (b) detecting
that the NAT IP address has changed in a received 200 OK. The second
event can serve as an indication that the UA needs to re-register
with the Proxy server to maintain the signaling path open. The NAT
address/port, although sent to the registered UA, is never carried in
SIP messages towards the remote callee. This provides certain amount
of security through IP address hiding.
5.2.2 Media Path: The Case for RTP (Media) Proxy 4.2.1.2.1 Initiating Session
RTP Proxy, as the name suggests, terminates an RTP session on one 4.2.1.2.2 Receiving Session Invitation
side and originates the same session on the other. The UA always
sends (and receives) media to (and from) an assigned address and port
of the RTP proxy. The RTP Proxy can perform NAPT function both on the
source and destination address/port of packets. For a solution using
an RTP Proxy to work, the requirement is that any media stream
traversing the NAT from the private side (e.g., Enterprise) must
always go through the RTP Proxy (and any intra-Enterprise traffic
should be able to bypass the RTP Proxy). Since incoming packets are
received from the same address and port as the outgoing packets are
sent to, a Symmetric NAT will always allow the packets from the RTP
proxy inside the Enterprise for the duration of the session. This
implies that a Full Cone NAT (or any restricted version of it) will
also allow flows to and from the RTP Proxy. This principle can be
generalized to be applicable to any type of application session, not
just RTP/RTCP sessions.
The following are the prerequisites for this solution to work: 4.2.2 Port Restricted Cone NAT
o Any media stream that traverses the NAT from private side to 4.2.2.1 STUN Solution
the public will pass through the RTP Proxy.
o The addresses and ports in the RTP Proxy are assigned either 4.2.2.1.1 Initiating Session
during the call set-up or before it.
o The RTP Proxy should know where to send the received media. 4.2.2.1.2 Receiving Session Invitation
For example, if it is acting as a bridge between two private
endpoints X and Y (X and Y are behind different NAT's), this
implies that the Proxy should be aware of the X's external
address/port before (or at least, as soon as) it starts
receiving media from Y, and vice-versa.
o The send and receive ports of the media in the UA's are 4.2.2.2 ICE Solution
configured to be the same.
Reverting back to our example configuration in Figure 22, let us 4.2.2.2.1 Initiating Session
illustrate using a call flow, how resource allocation in the RTP
Proxy will take place when UA X wants to establish a SIP session with
UA Y (only relevant parts of the call flow is shown). It is assumed
that the signaling paths between the UA's and the Proxy are already
established by the method described in Section 5.2.1. Please refer to
Figure 23 for the address/port allocations at various devices and the
call flow.
1. UA X sends a SIP INVITE message towards UA Y through the 4.2.2.2.2 Receiving Session Invitation
Proxy X' specifying that it wishes to receive media at
(private) IP address, PXA and port, px, i.e., PXA:px.
2. Proxy X' instructs the RTP Proxy to reserve a pair of IP 4.2.3 Symmetric NAT
address/port, one representing each end of the connection.
To UA Y, the remote end of the connection is perceived to
be A:px*, whereas to UA X, this is perceived to be A:py*.
Legends:- 4.2.3.1 STUN Failure
<><> : bi-directional flow
---- : signaling
==== : media
px, px', py*, px*, py', py : ports
PXA, NX, A, NY, PYA : IP addresses
PXA NX A NY PYA 4.2.3.1.1 Initiating Session
+-----+ +-----+ +--------+ +-----+ +-----+
| | | | | | | | | |
| px|<><><| px'|<><><>py* px*|<><>|py' |<><>|py |
| | | | | | | | | |
+-----+ +-----+ +--------+ +-----+ +-----+
UA X NAT Proxy RTP Proxy NAT UA Y 4.2.3.1.2 Receiving Session Invitation
X'
| 1.INVITE | | | | | 4.2.3.2 TURN Solution
|---------->|------>| | | |
| | |------->| | |
| | | 2.Create | |
| | | port bind | |
| | |<-------| | |
| | | |3.INVITE | |
| | |------------------>|-------->|
| | | | | |
|<----------|<------|<------------------|<--------|
| 5. 200 OK | | |4.200 OK | |
| | | | | |
|==========>|===============>| | |
| | 6.RTP | |<=========|<========|
| | | | 6.RTP | |
| | | | | |
|---------->|------>|------------------>|-------->|
|7. ACK | | | | |
| | | | | |
|<=========>|<==============>|<========>|<=======>|
RTP
Figure 23: Call Flow for B2BUAWM 4.2.3.2.1 Initiating Session
Note 1: Due to the presence of the NAT's, the source IP 4.2.3.2.2 Receiving Session Invitation
address/port of the media packets from the UA's are yet
unknown to the RTP Proxy. Note 2: Consecutive port binds
are also created for RTCP sessions corresponding to RTP.
3. Proxy X' forwards the INVITE towards UA Y (perhaps through 4.2.3.3 ICE Solution
Proxy Y') specifying that Y should send media to the RTP
Proxy at A:px* (by modifying the SDP).
4. UA Y responds with a 200 OK specifying that it wishes to 4.2.3.3.1 Initiating Session
receive media at (private) IP address, PYA and port, py,
i.e., PYA:py.
5. When Proxy X' receives the 200 OK, it changes these IP 4.2.3.3.2 Receiving Session Invitation
address and port parameters in SDP specifying X should
transmit media to the RTP Proxy at A:py*, and forwards the
200 OK towards UA X (Note: Proxy X' actually forwards the
message to the external NAT-ed address/port of UA X).
6. When UA X receives the 200 OK, it starts transmitting media 4.3 Advanced NAT media Traversal Using ICE
(e.g., background noise) towards the RTP Proxy. When the
first of these NAT- ed RTP packets reach the RTP Proxy, the
Proxy remembers the source address/port (say, NX, px') of
that packet as the external representation for the media
end point of UA X. Any media received from Y to X should be
sent to this address/port.
Similarly, when the first RTP packet is received from UA Y, 4.3.1 Full Cone --> Full Cone traversal
the RTP Proxy notes down the source IP address/port (say,
NY:py'), which will be used as the destination address to
transmit media received from X to Y.
7. Finally, UA X responds with an ACK message and the call 4.3.1.1 Without NAT
set-up is complete.
Note that, since all signaling is routed via the Proxy, which can 4.3.1.1.1 Initiating Session
determine whether both the UA's are in the same domain, all intra-
Enterprise calls (behind the same NAT) can avoid the trip to the RTP
Proxy. This is one of the key advantages of the Proxy mediating the
address/port of the endpoints of a call.
Once the media path is established through the NAT, keep-alive 4.3.1.1.2 Receiving Session Invitation
messages in the form of periodic RTP packets are sent to keep the
connection alive when the users are in mute (i.e., when no speech
packets are transmitted).
There needs to be some control interaction between the SIP and the 4.3.1.2 With NAT
RTP Proxies to establish the end-to-end sessions. The protocol can be
one of the device control protocols such as MGCP, Megaco etc.
5.3 Solution III: Outsourced MIDCOM 4.3.1.2.1 Initiating Session
In this scenario, the enterprise upgrades its firewall/NAT to a
midcom-enabled one. The centrex provider uses a proxy which can
control the firewall/NAT, opening and closing pinholes as needed.
This scenario avoids the need for a SIP specific ALG. Indeed, if the
enterprise uses other outsourced services, each provider can have a
control connection to the firewall/NAT to ensure that it works for
that particular application. This is one of the benefits of MIDCOM.
This configuration (for a single centrex provider) is shown in Figure 4.3.1.2.2 Receiving Session Invitation
24. It is similar to the ALG configuration 20, but there is a control
relationship between the proxies in the provider network (which act
as midcom agents [7]), and the firewall/NAT in the enterprise (which
is the middlebox).
For this solution to work, the firewall/NAT needs a static rule which 4.3.2 Port Restricted Cone --> Port Restricted Cone traversal
allows all outgoing traffic on UDP port 5060 to the proxies in the
provider network. This rule can be configured, or the proxies in the
provider network can create it when they first connect to the
firewall/NAT.
The basic call flow for a registration and incoming INVITE is shown 4.3.2.1 Without NAT
in Figure 25. The enterprise is using a MIDCOM FW/NAT. The enterprise
has a single public address, 1.2.3.4, which routes to the FW/NAT.
When the REGISTER arrives at the proxy (message 2), the proxy
performs a bind request (message 3), asking for the Contact address,
10.0.1.7:5060, to be translated. The FW/NAT returns with a mapped
address, 1.2.3.4:7765, and this is stored by the proxy to use as the
destination IP/port for sending requests to sip:user@10.0.1.7.
When an incoming INVITE arrives at the proxy (message 7), the R-URI 4.3.2.1.1 Initiating Session
is looked up, and translated to sip:10.0.1.7, but with a destination
address of 1.2.3.4:7765, which is where the request is sent. This
passes through the NAT, translated to 10.0.1.7:5060, and arrives at
the client (message 9). The 200 OK contains an RTP address of
10.0.1.7:8866. When this is received by the proxy (11), it performs
another bind request to the FW/NAT, asking for a pair of addresses on
consecutive ports. The bind response indicates that 1.2.3.4:6544 and
1.2.3.4:6545 will be mapped to 10.0.1.7:8866 and 10.0.1.7:8867
respectively. The proxy rewrites the SDP in the response, and
forwards that upstream.
5.4 Solution IV: STUN and TURN 4.3.2.1.2 Receiving Session Invitation
The operation of a STUN or TURN solution in the centrex case is 4.3.2.2 With NAT
identical to the residential case described in Section 2.2. If the
enterprise uses a firewall/NAT which allows for full-cone operation
...................................................
. .
. +------+ Centrex .
. | | Provider .
. +------+ | Proxy Farm .
. | | | .
. | | | .
. | |-+ .
. +------+ .
. x .
. x .
.Provider x | .
.................x......|..........................
x |
MIDCOM x |Provider Access (Internet,
Control x +---------+ private connection)
xx|Enterpris|
..................|. FW/NAT |.....................
. | MIDCOM | Enterprise .
. +---------+ .
. .
. .
. .
. .
. .
. .
. .
. /\ /\ .
. /\ / \ /\ / \ .
. / \ / \ / \ / \ .
. / \ /Client\ / \ /Client\ .
. /Client\ ---------- /Client\ ---------- .
. ---------- ---------- .
..................................................
Figure 24: Centrex MIDCOM Configuration 4.3.2.2.1 Initiating Session
of UDP, then STUN will get used, and the centrex provider needs to 4.3.2.2.2 Receiving Session Invitation
only deploy STUN servers. If, however, a more restrictive
firewall/NAT, such as symmetric, is used, the centrex provider must
deploy TURN servers as well.
6 Comparing the Approaches 4.3.3 Internal TURN Server (Enterprise Deployment)
Client MIDCOM FW Provider UAC
Proxy
|(1) REGISTER | | |
|m:10.0.1.7 | | |
|--------------->| | |
| |(2) REGISTER | |
| |m:10.0.1.7 | |
| |--------------->| |
| |(3) BIND_REQ | |
| |10.0.1.7:5060 | |
| |<---------------| |
| |(4) BIND_RESP | |
| |1.2.3.4:7765 | |
| |--------------->| |
| |(5) 200 OK | |
| |<---------------| |
|(6) 200 OK | | |
|<---------------| | |
| | |(7) INVITE |
| | |sip:user@enterprise
| | |<---------------|
| |(8) INVITE | |
| |sip:user@10.0.1.7 |
| |dst=1.2.3.4:7765| |
| |<---------------| |
|(9) INVITE | | |
|<---------------| | |
|(10) 200 OK | | |
|m=10.0.1.7 | | |
|rtp=10.0.1.7:8866 | |
|--------------->| | |
| |(11) 200 OK | |
| |m=10.0.1.7 | |
| |rtp=10.0.1.7:8866 |
| |--------------->| |
| |(12) BIND_REQ2 | |
| |10.0.1.7:8866 | |
| |<---------------| |
| |(13) BIND_RESP | |
| |1.2.3.4:6544 | |
| |--------------->| |
| | |(14) 200 OK |
| | |--------------->|
| | |(15) ACK |
| | |<---------------|
| |(16) ACK | |
| |<---------------| |
|(17) ACK | | |
|<---------------| | |
Figure 25: Centrex MIDCOM Solution, Incoming INVITE 4.3.3.1 Peer in same Enterprise
In order to compare the various solutions, it is necessary to
establish criteria by which they will be compared. The following
criteria are considered:
Upgrades Required: Which elements does the solution require to 4.3.3.2 Peer in same Enterprise - Separated by NAT
change? The fewer, the better.
Network Traffic: Does the solution generate additional message 4.3.3.3 Peer outside Enterprise
traffic that otherwise would not occur if there was no NAT?
The less, the better.
Voice Quality: Does the solution impact voice quality? Does it 4.4 Intercepting Intermediary (B2BUA)
increase latency or increase the probability of packet
loss? THe less the impact, the better.
Provider Cost: Does the solution incur substantial incremental 4.5 IPV4/IPV6
cost for the provider? The less the better.
Enterprise Cost: For solutions that target the enterprise, does 5. References
it introduce additional cost for the enterprise? The less,
the better.
User Cost: For solutions that require the end user or the user 5.1 Normative References
agent to change, does it introduce cost to the user? The
less, the better.
Specificity: Does the solution work under very specific [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
conditions? Or, can it work across a wide variety of Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
scenarios and NAT types? The less specific, the better. Session Initiation Protocol", RFC 3261, June 2002.
Application Focus: Is the solution SIP specific, or is it [2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
reusable for other applications? The less specific, the "RTP: A Transport Protocol for Real-Time Applications", RFC
better. 1889, January 1996.
Loss of Robustness: Does the solution take away robustness from [3] Handley, M. and V. Jacobson, "SDP: Session Description
the system, or make it more expensive to implement the same Protocol", RFC 2327, April 1998.
amount of robustness in the absence of NAT? The less the
loss of robustness, the better.
Loss of Scale: Does the solution make it harder to scale up to [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
support a large number of users? The less the loss of Session Description Protocol (SDP)", RFC 3264, June 2002.
scale, the better.
7 Changes since draft-rosenberg-sipping-nat-scenarios-00 [5] Rosenberg, J. and H. Schulzrinne, "An Extension to the Session
Initiation Protocol (SIP) for Symmetric Response Routing", RFC
3581, August 2003.
o Added more discussion on registration approaches. Updated [6] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
(partially) to reflect removal of translate header in favor of Extension Header Field for Registering Non-Adjacent Contacts",
connection sharing. RFC 3327, December 2002.
o Reference updates. [7] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN -
Simple Traversal of User Datagram Protocol (UDP) Through
Network Address Translators (NATs)", RFC 3489, March 2003.
o Added evaluation criteria. [8] Jennings, C. and A. Hawrylyshen, "SIP Conventions for
Connection Usage", draft-jennings-sipping-outbound-00 (work in
progress), October 2004.
8 Future Work [9] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-02 (work in progress), July 2004.
o Update for the latest drafts. [10] Rosenberg, J., "Traversal Using Relay NAT (TURN)",
draft-rosenberg-midcom-turn-05 (work in progress), July 2004.
o Include a subsection at the end of each scenario, weighing the [11] Wing, D., "Symmetric RTP and RTCP Considered Helpful",
pros/cons of each solution based on the criteria. draft-wing-mmusic-symmetric-rtprtcp-01 (work in progress),
October 2004.
o Expand the scope of the solution set to include a broader set [12] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
of solutions. Methodology for Network Address Translator (NAT) Traversal for
Multimedia Session Establishment Protocols",
draft-ietf-mmusic-ice-02 (work in progress), July 2004.
o More details on many of the call flows. [13] Rosenberg, J., "Simple Traversal of UDP Through Network Address
Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-00
(work in progress), October 2004.
o Alignment with UNSAF in terms of criteria and evaluation. 5.2 Informative References
9 Acknowledgements Authors' Addresses
The authors would like to thank Mary Barnes for her comments on this Chris Boulton
draft. Ubiquity Software
Langstone Park
Newport, South Wales NP18 2LH
10 Authors Addresses EMail: cboulton@ubiquitysoftware.com
Jonathan Rosenberg Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
email: jdrosen@dynamicsoft.com
Rohan Mahy
Cisco Systems Cisco Systems
170 West Tasman Dr, MS: SJC-21/3 600 Lanidex Plaza
Phone: +1 408 526 8570 Parsippany, NJ 07054
Email: rohan@cisco.com
Sanjoy Sen
Nortel Networks
sanjoy@nortelnetworks.com
11 Normative References
12 Informative References
[1] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation
protocol," Internet Draft, Internet Engineering Task Force, Feb.
2002. Work in progress.
[2] J. Rosenberg, J. Weinberger, C. Huitema, and R. Mahy, "STUN -
simple traversal of UDP through NATs," Internet Draft, Internet
Engineering Task Force, Apr. 2002. Work in progress.
[3] J. Rosenberg, "Traversal using relay NAT (TURN)," Internet Draft,
Internet Engineering Task Force, Nov. 2001. Work in progress.
[4] B. Biggs, "A SIP application level gateway for network address
translation," Internet Draft, Internet Engineering Task Force, Mar.
2000. Work in progress.
[5] C. Martin and A. Johnston, "SIP through NAT enabled firewall call
flows," Internet Draft, Internet Engineering Task Force, Feb. 2001.
Work in progress.
[6] J. Rosenberg, D. Drew, and H. Schulzrinne, "Getting SIP through
firewalls and NATs," Internet Draft, Internet Engineering Task Force,
Feb. 2000. Work in progress.
[7] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, and A. Rayhan,
"Middlebox communication architecture and framework," Internet Draft,
Internet Engineering Task Force, Mar. 2002. Work in progress.
[8] C. Huitema, "RTCP attribute in SDP," Internet Draft, Internet
Engineering Task Force, Feb. 2002. Work in progress.
[9] J. Rosenberg, J. Weinberger, and H. Schulzrinne, "SIP extensions
for NAT traversal," Internet Draft, Internet Engineering Task Force,
Nov. 2001. Work in progress.
[10] M. Borella, D. Grabelsky, J. Lo, and K. Taniguchi, "Realm
specific IP: protocol specification," RFC 3103, Internet Engineering
Task Force, Oct. 2001.
[11] M. Borella, J. Lo, D. Grabelsky, and G. Montenegro, "Realm
specific IP: framework," RFC 3102, Internet Engineering Task Force,
Oct. 2001.
[12] F. Thernelius, "SIP firewall solution," Internet Draft, Internet
Engineering Task Force, July 2000. Work in progress.
[13] S. Kent and R. Atkinson, "IP encapsulating security payload
(ESP)," RFC 2406, Internet Engineering Task Force, Nov. 1998.
[14] M. Gaynor and S. Bradner, "Firewall enhancement protocol (FEP),"
RFC 3093, Internet Engineering Task Force, Apr. 2001.
[15] J. Rosenberg, J. Weinberger, C. Huitema, and R. Mahy, "STUN - EMail: jdrosen@dynamicsoft.com
simple traversal of UDP through NATs," Internet Draft, Internet
Engineering Task Force, Mar. 2002. Work in progress.
[16] D. Yon, "Connection-oriented media transport in SDP," Internet Intellectual Property Statement
Draft, Internet Engineering Task Force, May 2002. Work in progress.
[17] R. Mahy, "Requirements for connection reuse in the session The IETF takes no position regarding the validity or scope of any
initiation protocol (SIP)," Internet Draft, Internet Engineering Task Intellectual Property Rights or other rights that might be claimed to
Force, June 2002. Work in progress. pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
[18] M. Arango, A. Dugan, I. Elliott, C. Huitema, and S. Pickett, Copies of IPR disclosures made to the IETF Secretariat and any
"Media gateway control protocol (MGCP) version 1.0," RFC 2705, assurances of licenses to be made available, or the result of an
Internet Engineering Task Force, Oct. 1999. attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
[19] F. Cuervo, N. Greene, A. Rayhan, C. Huitema, B. Rosen, and J. The IETF invites any interested party to bring to its attention any
Segers, "Megaco protocol version 1.0," RFC 3015, Internet Engineering copyrights, patents or patent applications, or other proprietary
Task Force, Nov. 2000. rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Full Copyright Statement Disclaimer of Validity
Copyright (c) The Internet Society (2002). All Rights Reserved. This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This document and translations of it may be copied and furnished to Copyright Statement
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
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 (C) The Internet Society (2004). This document is subject
revoked by the Internet Society or its successors or assigns. to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein is provided on an Acknowledgment
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF has been notified of intellectual property rights claimed in Funding for the RFC Editor function is currently provided by the
regard to some or all of the specification contained in this Internet Society.
document. For more information consult the online list of claimed
rights.
 End of changes. 

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