💾 Archived View for gemini.bortzmeyer.org › rfc-mirror › rfc6314.txt captured on 2023-06-14 at 16:08:28.
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Internet Engineering Task Force (IETF) C. Boulton
Request for Comments: 6314 NS-Technologies
Category: Informational J. Rosenberg
ISSN: 2070-1721 Skype
G. Camarillo
Ericsson
F. Audet
Skype
July 2011
NAT Traversal Practices for Client-Server SIP
Abstract
Traversal of the Session Initiation Protocol (SIP) and the sessions
it establishes through Network Address Translators (NATs) is a
complex problem. Currently, there are many deployment scenarios and
traversal mechanisms for media traffic. This document provides
concrete recommendations and a unified method for NAT traversal as
well as documents corresponding flows.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6314.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Boulton, et al. Informational [Page 1]
RFC 6314 NAT Scenarios July 2011
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Solution Technology Outline Description . . . . . . . . . . . 8
4.1. SIP Signaling . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Symmetric Response . . . . . . . . . . . . . . . . . . 8
4.1.2. Client-Initiated Connections . . . . . . . . . . . . . 9
4.2. Media Traversal . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . 10
4.2.2. RTCP . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.3. STUN/TURN/ICE . . . . . . . . . . . . . . . . . . . . 11
5. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . . . 12
5.1. Basic NAT SIP Signaling Traversal . . . . . . . . . . . . 12
5.1.1. Registration (Registrar/Edge Proxy Co-Located) . . . . 12
5.1.2. Registration(Registrar/Edge Proxy Not Co-Located) . . 16
5.1.3. Initiating a Session . . . . . . . . . . . . . . . . . 19
5.1.4. Receiving an Invitation to a Session . . . . . . . . . 22
5.2. Basic NAT Media Traversal . . . . . . . . . . . . . . . . 27
5.2.1. Endpoint-Independent NAT . . . . . . . . . . . . . . . 28
5.2.2. Address/Port-Dependent NAT . . . . . . . . . . . . . . 48
6. IPv4-IPv6 Transition . . . . . . . . . . . . . . . . . . . . . 57
6.1. IPv4-IPv6 Transition for SIP Signaling . . . . . . . . . . 57
7. Security Considerations . . . . . . . . . . . . . . . . . . . 57
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 57
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
9.1. Normative References . . . . . . . . . . . . . . . . . . . 58
9.2. Informative References . . . . . . . . . . . . . . . . . . 59
Boulton, et al. Informational [Page 2]
RFC 6314 NAT Scenarios July 2011
1. Introduction
NAT (Network Address Translator) traversal has long been identified
as a complex problem when considered in the context of the Session
Initiation Protocol (SIP) [RFC3261] and its associated media such as
the Real-time Transport Protocol (RTP) [RFC3550]. The problem is
exacerbated by the variety of NATs that are available in the
marketplace today and the large number of potential deployment
scenarios. Details of different NATs behavior can be found in "NAT
Behavioral Requirements for Unicast UDP" [RFC4787].
The IETF has been active on many specifications for the traversal of
NATs, including Session Traversal Utilities for NAT (STUN) [RFC5389],
Interactive Connectivity Establishment (ICE) [RFC5245], symmetric
response [RFC3581], symmetric RTP [RFC4961], Traversal Using Relay
NAT (TURN) [RFC5766], SIP Outbound [RFC5626], the Session Description
Protocol (SDP) attribute for RTP Control Protocol (RTCP) [RFC3605],
"Multiplexing RTP Data and Control Packets on a Single Port"
[RFC5761], and others. Each of these represents a part of 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. It should
be noted that this document intentionally does not invoke 'Best
Current Practice' machinery as defined in RFC 2026 [RFC2026].
The document is split into two distinct sections as follows:
o Section 4 provides a definitive set of best common practices to
demonstrate the traversal of SIP and its associated media through
NAT devices.
o Section 5 provides non-normative examples representing
interactions of SIP using various NAT type deployments.
The document does not propose any new functionality but does draw on
existing solutions for both core SIP signaling and media traversal
(as defined in Section 4).
The best practices described in this document are for traditional
"client-server"-style SIP. This term refers to the traditional use
of the SIP protocol where User Agents talk to a series of
intermediaries on a path to connect to a remote User Agent. It seems
likely that other groups using SIP, for example, peer-to-peer SIP
(P2PSIP), will recommend these same practices between a P2PSIP client
and a P2PSIP peer, but will recommend different practices for use
between peers in a peer-to-peer network.
Boulton, et al. Informational [Page 3]
RFC 6314 NAT Scenarios July 2011
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
It should be noted that the use of the term 'Endpoint-Independent
NAT' in this document refers to a NAT that is both Endpoint-
Independent Filtering and Endpoint-Independent Mapping per the
definitions in RFC 4787 [RFC4787].
3. Problem Statement
The traversal of SIP through NATs can be split into two categories
that both require attention: the core SIP signaling and associated
media traversal. This document assumes NATs that do not contain SIP-
aware Application Layer Gateways (ALGs), which makes much of the
issues discussed in the document not applicable. ALGs have
limitations (as per RFC 4787 [RFC4787] Section 7, RFC 3424 [RFC3424],
and [RFC5245] Section 18.6), and experience shows they can have an
adverse impact on the functionality of SIP. This includes problems
such as requiring the media and signaling to traverse the same device
and not working with encrypted signaling and/or payload.
The use of non-TURN-based media intermediaries is not considered in
this document. More information can be obtained from [RFC5853] and
[MIDDLEBOXES].
The core SIP signaling has a number of issues when traversing through
NATs.
SIP response routing over UDP as defined in RFC 3261 [RFC3261]
without extensions causes the response to be delivered to the source
IP address specified in the topmost Via header, or the 'received'
parameter of the topmost 'Via' header. The port is extracted from
the SIP 'Via' header to complete the IP address/port combination for
returning the SIP response. While the destination for the response
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 pinhole on the NAT. This results in 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.
Boulton, et al. Informational [Page 4]
RFC 6314 NAT Scenarios July 2011
Private NAT Public
Network | Network
|
|
-------- SIP Request |open port 10923 --------
| |-------------------->--->-----------------------| |
| | | | |
| Client | |port 5060 SIP Response | Proxy |
| | x<------------------------| |
| | | | |
-------- | --------
|
|
|
Figure 1: Failed Response
Secondly, there are two cases where new requests reuse existing
connections. The first is when using a reliable, connection-oriented
transport 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
reverse direction of the originating client to use, for example, 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. The second case
is when using an unreliable transport protocol such as UDP where
external NAT mappings need to be reused to reach a SIP entity on the
private side of the network.
Private NAT Public
Network | Network
|
|
-------- (UAC 8023) REGISTER/Response (UAS 5060) --------
| |-------------------->---<-----------------------| |
| | | | |
| Client | |5060 INVITE (UAC 8015)| Proxy |
| | x<------------------------| |
| | | | |
-------- | --------
|
|
|
Figure 2: Failed Request
Boulton, et al. Informational [Page 5]
RFC 6314 NAT Scenarios July 2011
In Figure 2, the original REGISTER request is sent from the client on
port 8023 and received by the proxy on port 5060, establishing a
connection and opening a pinhole in the NAT. The generation of a new
request from the proxy results in a request destined for the
registered entity (contact IP address) that 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 were reused. While this problem
has been discussed in the context of connection-oriented protocols
such as TCP, the problem exists for SIP signaling using any transport
protocol. The impact of connection reuse of connection-oriented
transports (TCP, TLS, etc.) is discussed in more detail in the
connection reuse specification [RFC5923]. The approach proposed for
this problem in Section 4 of this document is relevant for all SIP
signaling in conjunction with connection reuse, regardless of the
transport protocol.
NAT policy can dictate that connections should be closed after a
period of inactivity. This period of inactivity may vary from a
number of seconds to hours. SIP signaling cannot be relied upon to
keep connections alive for the following two reasons. Firstly, SIP
entities can sometimes have no signaling traffic for long periods of
time, which has the potential to exceed the inactivity timer, and
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
resources and also requires processing at a SIP stack, which is also
a waste of processing resources.
Media associated with SIP calls also has problems traversing NAT.
RTP [RFC3550] runs over UDP and is one of the most common media
transport types used in SIP signaling. Negotiation of RTP occurs
with a SIP session establishment using the Session Description
Protocol (SDP) [RFC4566] and a SIP offer/answer exchange [RFC3264].
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 its address to receive media and it exists in a private
network that is not accessible from outside the NAT. Figure 3
illustrates this problem.
Boulton, et al. Informational [Page 6]
RFC 6314 NAT Scenarios July 2011
NAT Public Network NAT
| |
| |
| |
-------- | SIP Signaling Session | --------
| |---------------------->Proxy<-------------------| |
| | | | | |
| Client | | | | Client |
| A |>=====>RTP>==Unknown Address==>X | | B |
| | | X<==Unknown Address==<RTP<===<| |
-------- | | --------
| |
| |
| |
Figure 3: Failed Media
The connection addresses of the clients behind the NATs will
nominally contain a private IPv4 address that is not routable across
the public Internet. Exacerbating matters even more would be the
tendency of Client A to send media to a destination address it
received in the signaling confirmation message -- an address that may
actually correspond to a host within the private network who is
suddenly faced with incoming RTP packets (likewise, Client B may send
media to a host within its private network who did not solicit these
packets). Finally, to complicate the problem even further, a number
of different NAT topologies with different default behaviors
increases the difficulty of arriving at a unified approach. This
problem exists for all media transport protocols that might be NATted
(e.g., TCP, UDP, the Stream Control Transmission Protocol (SCTP), the
Datagram Congestion Control Protocol (DCCP)).
In general, the problems associated with NAT traversal can be
categorized as follows.
For signaling:
o Responses do not reuse the NAT mapping and filtering entries
created by the request.
o Inbound requests are filtered out by the NAT because there is no
long-term connection between the client and the proxy.
Boulton, et al. Informational [Page 7]
RFC 6314 NAT Scenarios July 2011
For media:
o Each endpoint has a variety of addresses that can be used to reach
it (e.g., native interface address, public NATted address). In
different situations, a different pair of (local endpoint, remote
endpoint) addresses should be used, and it is not clear when to
use which pair.
o Many NATs filter inbound packets if the local endpoint has not
recently sent an outbound packet to the sender.
o Classic RTCP usage is to run RTCP on the next highest port.
However, NATs do not necessarily preserve port adjacency.
o Classic RTP and RTCP usage is to use different 5-tuples for
traffic in each direction. Though not really a problem, doing
this through NATs is more work than using the same 5-tuple in both
directions.
4. Solution Technology Outline Description
As mentioned previously, the traversal of SIP through existing NATs
can be divided into two discrete problem areas: getting the SIP
signaling across NATs and enabling media as specified by SDP in a SIP
offer/answer exchange to flow between endpoints.
4.1. SIP Signaling
SIP signaling has two areas that result in transactional failure when
traversing through NATs, as described in Section 3 of this document.
The remaining sub-sections describe appropriate solutions that result
in SIP signaling traversal through NATs, regardless of transport
protocol. It is advised that SIP-compliant entities follow the
guidelines presented in this section to enable traversal of SIP
signaling through NATs.
4.1.1. Symmetric Response
As described in Section 3 of this document, when using an unreliable
transport protocol such as UDP, SIP responses are sent to the IP
address and port combination contained in the SIP 'Via' header field
(or default port for the appropriate transport protocol if not
present). Figure 4 illustrates the response traversal through the
open pinhole using Symmetric techniques defined in RFC 3581
[RFC3581].
Boulton, et al. Informational [Page 8]
RFC 6314 NAT Scenarios July 2011
Private NAT Public
Network | Network
|
|
-------- | --------
| | | | |
| |send request---------------------------------->| |
| Client |<---------------------------------send response| SIP |
| A | | | Proxy |
| | | | |
-------- | --------
|
|
|
Figure 4: Symmetric Response
The outgoing request from Client A opens a pinhole in the NAT. The
SIP Proxy would normally respond to the port available in the SIP
'Via' header, as illustrated in Figure 1. The SIP Proxy honors the
'rport' parameter in the SIP 'Via' header and routes the response to
the port from which it was sent. The exact functionality for this
method of response traversal is called 'Symmetric Response', and the
details are documented in RFC 3581 [RFC3581]. Additional
requirements are imposed on SIP entities in RFC 3581 [RFC3581] such
as listening and sending SIP requests/responses from the same port.
4.1.2. Client-Initiated Connections
The second problem with SIP signaling, as defined in Section 3 and
illustrated in Figure 2, is to allow incoming requests to be properly
routed.
Guidelines for devices such as User Agents that can only generate
outbound connections through NATs are documented in "Managing Client-
Initiated Connections in the Session Initiation Protocol (SIP)"
[RFC5626]. The document provides techniques that use a unique User
Agent instance identifier (instance-id) in association with a flow
identifier (reg-id). The combination of the two identifiers provides
a key to a particular connection (both UDP and TCP) that is stored in
association with registration bindings. On receiving an incoming
request to a SIP Address-Of-Record (AOR), a proxy/registrar routes to
the associated flow created by the registration and thus a route
through NATs. It also provides a keep-alive mechanism for clients to
keep NAT bindings alive. This is achieved by multiplexing a ping-
pong mechanism over the SIP signaling connection (STUN for UDP and
Boulton, et al. Informational [Page 9]
RFC 6314 NAT Scenarios July 2011
CRLF/operating system keepalive for reliable transports like TCP).
Usage of [RFC5626] is RECOMMENDED. This mechanism is not transport
specific and should be used for any transport protocol.
Even if the SIP Outbound mechanism is not used, clients generating
SIP requests SHOULD use the same IP address and port (i.e., socket)
for both transmission and receipt of SIP messages. Doing so allows
for the vast majority of industry provided solutions to properly
function (e.g., NAT traversal that is Session Border Control (SBC)
hosted). Deployments should also consider the mechanism described in
the Connection Reuse [RFC5923] specification for routing
bidirectional messages securely between trusted SIP Proxy servers.
4.2. Media Traversal
The issues of media traversal through NATs is not straightforward and
requires the combination of a number of traversal methodologies. The
technologies outlined in the remainder of this section provide the
required solution set.
4.2.1. Symmetric RTP/RTCP
The primary problem identified in Section 3 of this document is that
internal IP address/port combinations cannot be reached from the
public side of NATs. In the case of media such as RTP, this will
result in no audio traversing NATs (as illustrated in Figure 3). To
overcome this problem, a technique called 'Symmetric RTP/RTCP'
[RFC4961] can be used. This involves a SIP endpoint both sending and
receiving RTP/RTCP traffic from the same IP address/port combination.
When operating behind a NAT and using the 'latching' technique
described in [MIDDLEBOXES], SIP User Agents MUST implement Symmetric
RTP/RTCP. This allows traversal of RTP across the NAT.
4.2.2. RTCP
Normal practice when selecting a port for defining RTP Control
Protocol (RTCP) [RFC3550] is for consecutive-order numbering (i.e.,
select an incremented port for RTCP from that used for RTP). This
assumption causes RTCP traffic to break when traversing certain types
of NATs due to various reasons (e.g., already allocated port,
randomized port allocation). To combat this problem, a specific
address and port need to be specified in the SDP rather than relying
on such assumptions. RFC 3605 [RFC3605] defines an SDP attribute
that is included to explicitly specify transport connection
information for RTCP so a separate, explicit NAT binding can be set
up for the purpose. The address details can be obtained using any
appropriate method including those detailed in this section (e.g.,
STUN, TURN, ICE).
Boulton, et al. Informational [Page 10]
RFC 6314 NAT Scenarios July 2011
A further enhancement to RFC 3605 [RFC3605] is defined in [RFC5761],
which specifies 'muxing' both RTP and RTCP on the same IP/PORT
combination.
4.2.3. STUN/TURN/ICE
ICE, STUN, and TURN are a suite of 3 inter-related protocols that
combine to provide a complete media traversal solution for NATs. The
following sections provide details of each component part.
4.2.3.1. STUN
Session Traversal Utilities for NAT or STUN is defined in RFC 5389
[RFC5389]. STUN is a lightweight tool kit and protocol that provides
details of the external IP address/port combination used by the NAT
device to represent the internal entity on the public facing side of
NATs. On learning of such an external representation, a client can
use it accordingly as the connection address in SDP to provide NAT
traversal. Using terminology defined in "NAT Behavioral Requirements
for Unicast UDP" [RFC4787], STUN does work with Endpoint-Independent
Mapping but does not work with either Address-Dependent Mapping or
Address and Port-Dependent Mapping type NATs. Using STUN with either
of the previous two NAT mappings to probe for the external IP
address/port representation 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 RTP
packets from the remote SIP User Agent.
As mentioned in Section 4.1.2, STUN is also used as a client-to-
server keep-alive mechanism to refresh NAT bindings.
4.2.3.2. TURN
As described in Section 4.2.3.1, the STUN protocol does not work for
UDP traversal through certain identified NAT mappings. 'Traversal
Using Relays around NAT' is a usage of the STUN protocol for deriving
(from a TURN server) an address that will be used to relay packets
towards a client. TURN provides an external address (globally
routable) at a TURN server that will act as a media relay that
attempts to allow traffic to reach the associated internal address.
The full details of the TURN specification are defined in [RFC5766].
A TURN service will almost always provide media traffic to a SIP
entity, but it is RECOMMENDED that this method would 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 and can lead to unwanted latency.
Boulton, et al. Informational [Page 11]
RFC 6314 NAT Scenarios July 2011
4.2.3.3. ICE
Interactive Connectivity Establishment (ICE) is the RECOMMENDED
method for traversal of existing NATs if Symmetric RTP and media
latching are not sufficient. ICE is a methodology for using existing
technologies such as STUN, TURN, and any other protocol compliant
with Unilateral Self-Address Fixing (NSAF) [RFC3424] to provide a
unified solution. This is achieved by obtaining as many
representative IP address/port combinations as possible using
technologies such as STUN/TURN (note: an ICE endpoint can also use
other mechanisms (e.g., the NAT Port Mapping Protocol [NAT-PMP],
Universal Plug and Play Internet Gateway Device [UPnP-IGD]) to learn
public IP addresses and ports, and populate a=candidate lines with
that information). Once the addresses are accumulated, they are all
included in the SDP exchange in a new media attribute called
'candidate'. Each candidate SDP attribute entry has detailed
connection information including a media address, priority, and
transport protocol. The appropriate IP address/port combinations are
used in the order specified by the priority. A client compliant to
the ICE specification will then locally run STUN servers on all
addresses being advertised using ICE. Each instance will undertake
connectivity checks to ensure that a client can successfully receive
media on the advertised address. Only connections that pass the
relevant connectivity checks are used for media exchange. The full
details of the ICE methodology are in [RFC5245].
5. NAT Traversal Scenarios
This section of the document includes detailed NAT traversal
scenarios for both SIP signaling and the associated media. Signaling
NAT traversal is achieved using [RFC5626].
5.1. Basic NAT SIP Signaling Traversal
The following sub-sections concentrate on SIP signaling traversal of
NATs. The scenarios include traversal for both reliable and
unreliable transport protocols.
5.1.1. Registration (Registrar/Edge Proxy Co-Located)
The set of scenarios in this section document basic signaling
traversal of a SIP REGISTER method through NATs.
Boulton, et al. Informational [Page 12]
RFC 6314 NAT Scenarios July 2011
5.1.1.1. UDP
Registrar/
Bob NAT Edge Proxy
| | |
|(1) REGISTER | |
|----------------->| |
| | |
| |(1) REGISTER |
| |----------------->|
| | |
|*************************************|
| Create Outbound Connection Tuple |
|*************************************|
| | |
| |(2) 200 OK |
| |<-----------------|
| | |
|(2) 200 OK | |
|<-----------------| |
| | |
Figure 5: UDP Registration
In this example, the client sends a SIP REGISTER request through a
NAT. The client will include an 'rport' parameter as described in
Section 4.1.1 of this document for allowing traversal of UDP
responses. The original request as illustrated in (1) in Figure 5 is
a standard SIP REGISTER message:
Message 1:
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2;rport;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Bob <sip:bob@example.com>;tag=7F94778B653B
To: Bob <sip:bob@example.com>
Call-ID: 16CB75F21C70
CSeq: 1 REGISTER
Supported: path, outbound
Contact: <sip:bob@192.168.1.2 >;reg-id=1
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Length: 0
Boulton, et al. Informational [Page 13]
RFC 6314 NAT Scenarios July 2011
This SIP transaction now generates a SIP 200 OK response, as depicted
in (2) from Figure 5:
Message 2:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.2;rport=8050;branch=z9hG4bKnashds7;
received=172.16.3.4
From: Bob <sip:bob@example.com>;tag=7F94778B653B
To: Bob <sip:bob@example.com>;tag=6AF99445E44A
Call-ID: 16CB75F21C70
CSeq: 1 REGISTER
Supported: path, outbound
Require: outbound
Contact: <sip:bob@192.168.1.2 >;reg-id=1;expires=3600
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Length: 0
The response will be sent to the address appearing in the 'received'
parameter of the SIP 'Via' header (address 172.16.3.4). 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 [RFC3581] are to be obeyed. Make
note of both the 'reg-id' and 'sip.instance' contact header
parameters. They are used to establish an outbound connection tuple
as defined in [RFC5626]. 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 reuse of the connection path
established by the registration. This removes the need to manipulate
contact header URIs to represent a globally routable address as
perceived on the public side of a NAT.
Boulton, et al. Informational [Page 14]
RFC 6314 NAT Scenarios July 2011
5.1.1.2. Connection-Oriented Transport
Registrar/
Bob NAT Edge Proxy
| | |
|(1) REGISTER | |
|----------------->| |
| | |
| |(1) REGISTER |
| |----------------->|
| | |
|*************************************|
| Create Outbound Connection Tuple |
|*************************************|
| | |
| |(2) 200 OK |
| |<-----------------|
| | |
|(2) 200 OK | |
|<-----------------| |
| | |
Figure 6
Traversal of SIP REGISTER requests/responses using a reliable,
connection-oriented protocol such as TCP does not require any
additional core SIP signaling extensions, beyond the procedures
defined in [RFC5626]. SIP responses will reuse the connection
created for the initial REGISTER request, (1) from Figure 6:
Message 1:
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Bob <sip:bob@example.com>;tag=7F94778B653B
To: Bob <sip:bob@example.com>
Call-ID: 16CB75F21C70
CSeq: 1 REGISTER
Supported: path, outbound
Contact: <sip:bob@192.168.1.2;transport=tcp>;reg-id=1
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Length: 0
Boulton, et al. Informational [Page 15]
RFC 6314 NAT Scenarios July 2011
Message 2:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7
From: Bob <sip:bob@example.com>;tag=7F94778B653B
To: Bob <sip:bob@example.com>;tag=6AF99445E44A
Call-ID: 16CB75F21C70
CSeq: 1 REGISTER
Supported: path, outbound
Require: outbound
Contact: <sip:bob@192.168.1.2;transport=tcp>;reg-id=1;expires=3600
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Length: 0
This example was included to show the inclusion of the 'sip.instance'
contact header parameter as defined in the SIP Outbound specification
[RFC5626]. This creates an association tuple as described in the
previous example for future inbound requests directed at the newly
created registration binding with the only difference that the
association is with a TCP connection, not a UDP pinhole binding.
5.1.2. Registration(Registrar/Edge Proxy Not Co-Located)
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, so only one example will be documented in the
form of TCP.
Boulton, et al. Informational [Page 16]
RFC 6314 NAT Scenarios July 2011
Bob NAT Edge Proxy Registrar
| | | |
|(1) REGISTER | | |
|----------------->| | |
| | | |
| |(1) REGISTER | |
| |----------------->| |
| | | |
| | |(2) REGISTER |
| | |----------------->|
| | | |
|*************************************| |
| Create Outbound Connection Tuple | |
|*************************************| |
| | | |
| | |(3) 200 OK |
| | |<-----------------|
| |(4)200 OK | |
| |<-----------------| |
| | | |
|(4)200 OK | | |
|<-----------------| | |
| | | |
Figure 7: Registration (Registrar/Proxy Not Co-Located)
This scenario builds on the previous example in Section 5.1.1.2. The
primary difference is that the REGISTER request is routed onwards
from a proxy server to a separated Registrar. The important message
to note is (1) in Figure 7. The edge proxy, on receiving a REGISTER
request that contains a 'sip.instance' media feature tag, forms a
unique flow identifier token as discussed in [RFC5626]. At this
point, the proxy server routes the SIP REGISTER message to the
Registrar. The proxy will create the connection tuple as described
in SIP Outbound at the same moment as the co-located example, but for
subsequent messages to arrive at the proxy, the proxy needs to
indicate its need to remain in the SIP signaling path. To achieve
this, the proxy inserts to REGISTER message (2) a SIP 'Path'
extension header, as defined in RFC 3327 [RFC3327]. The previously
created flow association token is inserted in a position within the
Path header where it can easily be retrieved at a later point when
receiving messages to be routed to the registration binding (in this
case the user part of the SIP URI). The REGISTER message of (1)
includes a SIP 'Route' header for the edge proxy.
Boulton, et al. Informational [Page 17]
RFC 6314 NAT Scenarios July 2011
Message 1:
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Bob <sip:bob@example.com>;tag=7F94778B653B
To: Bob <sip:bob@example.com>
Call-ID: 16CB75F21C70
CSeq: 1 REGISTER
Supported: path, outbound
Route: <sip:ep1.example.com;lr>
Contact: <sip:bob@192.168.1.2;transport=tcp>;reg-id=1
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Length: 0
When proxied in (2) looks as follows:
Message 2:
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP ep1.example.com;branch=z9hG4bKnuiqisi
Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7
Max-Forwards: 69
From: Bob <sip:bob@example.com>;tag=7F94778B653B
To: Bob <sip:bob@example.com>
Call-ID: 16CB75F21C70
CSeq: 1 REGISTER
Supported: path, outbound
Contact: <sip:bob@192.168.1.2;transport=tcp>;reg-id=1
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Path: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr;ob>
Content-Length: 0
This REGISTER request results in the Path header being stored along
with the AOR and its associated binding at the Registrar. The URI
contained in the Path header will be inserted as a pre-loaded SIP
'Route' header into any request that arrives at the Registrar and is
directed towards the associated AOR binding. This all but guarantees
that all requests for the new registration will be forwarded to the
edge proxy. In our example, the user part of the SIP 'Path' header
URI that was inserted by the edge proxy contains the unique token
identifying the flow to the client. On receiving subsequent
requests, the edge proxy will examine the user part of the pre-loaded
SIP 'Route' header and extract the unique flow token for use in its
connection tuple comparison, as defined in the SIP Outbound
specification [RFC5626]. An example that builds on this scenario
(showing an inbound request to the AOR) is detailed in
Section 5.1.4.2 of this document.
Boulton, et al. Informational [Page 18]
RFC 6314 NAT Scenarios July 2011
5.1.3. Initiating a Session
This section covers basic SIP signaling when initiating a call from
behind a NAT.
5.1.3.1. UDP
Initiating a call using UDP (the edge proxy and authoritative proxy
functionality are co-located).
Boulton, et al. Informational [Page 19]
RFC 6314 NAT Scenarios July 2011
Edge Proxy/
Bob NAT Auth. Proxy Alice
| | | |
|(1) INVITE | | |
|----------------->| | |
| | | |
| |(1) INVITE | |
| |----------------->| |
| | | |
| | |(2) INVITE |
| | |---------------->|
| | | |
| | |(3)180 RINGING |
| | |<----------------|
| | | |
| |(4)180 RINGING | |
| |<-----------------| |
| | | |
|(4)180 RINGING | | |
|<-----------------| | |
| | | |
| | |(5)200 OK |
| | |<----------------|
| | | |
| |(6)200 OK | |
| |<-----------------| |
| | | |
|(6)200 OK | | |
|<-----------------| | |
| | | |
|(7)ACK | | |
|----------------->| | |
| | | |
| |(7)ACK | |
| |----------------->| |
| | | |
| | |(8) ACK |
| | |---------------->|
| | | |
Figure 8: Initiating a Session - UDP
Boulton, et al. Informational [Page 20]
RFC 6314 NAT Scenarios July 2011
The initiating client generates an INVITE request that is to be sent
through the NAT to a proxy server. The INVITE message is represented
in Figure 8 by (1) and is as follows:
Message 1:
INVITE sip:alice@a.example SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2;rport;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Bob <sip:bob@example.com>;tag=ldw22z
To: Alice <sip:alice@a.example>
Call-ID: 95KGsk2V/Eis9LcpBYy3
CSeq: 1 INVITE
Supported: outbound
Route: <sip:ep1.example.com;lr>
Contact: <sip:bob@192.168.1.2;ob>
Content-Type: application/sdp
Content-Length: ...
[SDP not shown]
There are a number of points to note with this message:
1. Firstly, as with the registration example in Section 5.1.1.1,
responses to this request will not automatically pass back
through a NAT, so the SIP 'Via' header 'rport' is included as
described in the Section 4.1.1 ("Symmetric Response") and defined
in RFC 3581 [RFC3581].
2. Secondly, the 'ob' parameter is added to the 'Contact' header to
ensure that all subsequent requests are sent to the same flow;
alternatively, a Globally Routable User Agent URI (GRUU) might
have been used. See Section 4.3 of [RFC5626].
In (2), the proxy inserts itself in the 'Via' header, adds the
'rport' port number and the 'received' parameter in the previous
'Via' header, removes the 'Route' header, and inserts a Record-Route
with a token.
Boulton, et al. Informational [Page 21]
RFC 6314 NAT Scenarios July 2011
Message 2:
INVITE sip:alice@172.16.1.4 SIP/2.0
Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4bKnuiqisi
Via: SIP/2.0/UDP 192.168.1.2;rport=8050;branch=z9hG4bKnashds7;
received=172.16.3.4
Max-Forwards: 69
From: Bob <sip:bob@example.com>;tag=ldw22z
To: Alice <sip:alice@a.example>
Call-ID: 95KGsk2V/Eis9LcpBYy3
CSeq: 1 INVITE
Supported: outbound
Record-Route: <sip:3yJEbr1GYZK9cPYk5Snocez6DzO7w+AX@ep1.example.com;lr>
Contact: <sip:bob@192.168.1.2;ob>
Content-Type: application/sdp
Content-Length: ...
[SDP not shown]
5.1.3.2. Connection-Oriented Transport
When using a reliable transport such as TCP, the call flow and
procedures for traversing a NAT are almost identical to those
described in Section 5.1.3.1. The primary difference when using
reliable transport protocols is that symmetric response [RFC3581] is
not required for SIP responses to traverse a NAT. RFC 3261 [RFC3261]
defines procedures for SIP response messages to be sent back on the
same connection on which the request arrived. See Section 9.5 of
[RFC5626] for an example flow of an outgoing call.
5.1.4. Receiving an Invitation to a Session
This section details scenarios where a client behind a NAT receives
an inbound request through a NAT. These scenarios build on the
previous registration scenario from Sections 5.1.1 and 5.1.2 in this
document.
5.1.4.1. Registrar/Proxy Co-Located
The SIP signaling on the interior of the network (behind the user's
proxy) is not impacted directly by the transport protocol, so only
one example scenario is necessary. The example uses UDP and follows
on from the registration installed in the example from
Section 5.1.1.1.
Boulton, et al. Informational [Page 22]
RFC 6314 NAT Scenarios July 2011
Edge Proxy
Bob NAT Auth. Proxy Alice
| | | |
|*******************************************************|
| Registration Binding Installed in |
| Section 5.1.1.1 |
|*******************************************************|
| | | |
| | |(1)INVITE |
| | |<----------------|
| | | |
| |(2)INVITE | |
| |<-----------------| |
| | | |
|(2)INVITE | | |
|<-----------------| | |
| | | |
| | | |
Figure 9: Receiving an Invitation to a Session
An INVITE request arrives at the authoritative proxy with a
destination pointing to the AOR of that inserted in Section 5.1.1.1.
The message is illustrated by (1) in Figure 9 and looks as follows:
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d
Max-Forwards: 70
From: External Alice <sip:alice@example.com>;tag=02935
To: Bob <sip:bob@example.com>
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE
Contact: <sip:alice@172.16.1.4>
Content-Type: application/sdp
Content-Length: ..
[SDP not shown]
The INVITE request matches the registration binding previously
installed at the Registrar and the INVITE Request-URI is rewritten to
the selected onward address. The proxy then examines the Request-URI
of the INVITE and compares with its list of connection tuples. 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 that
connection tuple. The request is then dispatched on the appropriate
binding. This is message (2) from Figure 9 and is as follows:
Boulton, et al. Informational [Page 23]
RFC 6314 NAT Scenarios July 2011
INVITE sip:bob@192.168.1.2 SIP/2.0
Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4kmlds893jhsd
Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d
Max-Forwards: 69
From: Alice <sip:alice@example.com>;tag=02935
To: client bob <sip:bob@example.com>
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE
Contact: <sip:alice@172.16.1.4>
Content-Type: application/sdp
Content-Length: ..
[SDP not shown]
It is a standard SIP INVITE request with no additional functionality.
The major difference is that this request will not be forwarded to
the address specified in the Request-URI, as standard SIP rules would
enforce, but will be sent on the flow associated with the
registration binding (lookup procedures in RFC 3263 [RFC3263] are
overridden by RFC 5626 [RFC5626]). This then allows the original
connection/mapping from the initial registration process to be
reused.
5.1.4.2. Edge Proxy/Authoritative Proxy Not Co-Located
The core SIP signaling associated with this call flow is not impacted
directly by the transport protocol, so only one example scenario is
necessary. The example uses UDP and follows on from the registration
installed in the example from Section 5.1.2.
Boulton, et al. Informational [Page 24]
RFC 6314 NAT Scenarios July 2011
Bob NAT Edge Proxy Auth. Proxy Alice
| | | | |
|***********************************************************|
| Registration Binding Installed in |
| Section 5.1.2 |
|***********************************************************|
| | | | |
| | | |(1)INVITE |
| | | |<-------------|
| | | | |
| | |(2)INVITE | |
| | |<-------------| |
| | | | |
| |(3)INVITE | | |
| |<-------------| | |
| | | | |
|(3)INVITE | | | |
|<-------------| | | |
| | | | |
| | | | |
Figure 10: Registrar/Proxy Not Co-located
An INVITE request arrives at the authoritative proxy with a
destination pointing to the AOR of that inserted in Section 5.1.2.
The message is illustrated by (1) in Figure 10 and looks as follows:
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d
Max-Forwards: 70
From: Alice <sip:alice@example.com>;tag=02935
To: Bob <sip:bob@example.com>
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE
Contact: <sip:external@172.16.1.4>
Content-Type: application/sdp
Content-Length: ..
[SDP not shown]
The INVITE request matches the registration binding previously
installed at the Registrar and the INVITE Request-URI is rewritten to
the selected onward address. The Registrar also identifies that a
SIP 'Path' header was associated with the registration and pushes it
into the INVITE request in the form of a pre-loaded SIP Route header.
It then forwards the request on to the proxy identified in the SIP
Route header as shown in (2) from Figure 10:
Boulton, et al. Informational [Page 25]
RFC 6314 NAT Scenarios July 2011
INVITE sip:bob@client.example.com SIP/2.0
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK74fmljnc
Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d
Route: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr;ob>
Max-Forwards: 69
From: Alice <sip:alice@example.net>;tag=02935
To: Bob <sip:Bob@example.com>
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE
Contact: <sip:alice@172.16.1.4>
Content-Type: application/sdp
Content-Length: ..
[SDP not shown]
The request then arrives at the outbound proxy for the client. The
proxy examines the Request-URI of the INVITE in conjunction with the
flow token that it previously inserted into the user part of the
'Path' header SIP URI (which now appears in the user part of the
Route header in the incoming INVITE). The proxy locates the
appropriate flow and sends the message to the client, as shown in (3)
from Figure 10:
INVITE sip:bob@192.168.1.2 SIP/2.0
Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4nsi30dncmnl
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK74fmljnc
Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d
Record-Route: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr>
Max-Forwards: 68
From: Alice <sip:Alice@example.net>;tag=02935
To: bob <sip:bob@example.com>
Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE
Contact: <sip:alice@172.16.1.4>
Content-Type: application/sdp
Content-Length: ..
[SDP not shown]
It is a standard SIP INVITE request with no additional functionality
at the originator. The major difference is that this request will
not follow the address specified in the Request-URI when it reaches
the outbound proxy, as standard SIP rules would enforce, but will be
sent on the flow associated with the registration binding as
indicated in the Route header (lookup procedures in RFC 3263
[RFC3263] are overridden). This then allows the original connection/
mapping from the initial registration to the outbound proxy to be
reused.
Boulton, et al. Informational [Page 26]
RFC 6314 NAT Scenarios July 2011
5.2. Basic NAT Media Traversal
This section provides example scenarios to demonstrate basic media
traversal using the techniques outlined earlier in this document.
In the flow diagrams, STUN messages have been annotated for
simplicity as follows:
o The "Src" attribute represents the source transport address of the
message.
o The "Dest" attribute represents the destination transport address
of the message.
o The "Map" attribute represents the server reflexive (XOR-MAPPED-
ADDRESS STUN attribute) transport address.
o The "Rel" attribute represents the relayed (RELAY-ADDRESS STUN
attribute) transport address.
The meaning of each STUN attribute is extensively explained in the
core STUN [RFC5389] and TURN [RFC5766] specifications.
A number of ICE SDP attributes have also been included in some of the
examples. Detailed information on individual attributes can be
obtained from the core ICE specification [RFC5245].
The examples also contain a mechanism for representing transport
addresses. It would be confusing to include representations of
network addresses in the call flows and would make them hard to
follow. For this reason, network addresses will be represented using
the following annotation. The first component will contain the
representation of the client responsible for the address. For
example, in the majority of the examples "L" (left client), "R"
(right client), "NAT-PUB" (NAT public), "PRIV" (Private), and "STUN-
PUB" (STUN public) are used. To allow for multiple addresses from
the same network element, each representation can also be followed by
a number. These can also be used in combination. For example,
"L-NAT-PUB-1" would represent a public network address of the left-
hand side NAT while "R-NAT-PUB-1" would represent a public network
address of the right-hand side of the NAT. "L-PRIV-1" would
represent a private network address of the left-hand side of the NAT
while "R-PRIV-1" represents a private address of the right-hand side
of the NAT.
Boulton, et al. Informational [Page 27]
RFC 6314 NAT Scenarios July 2011
It should also be noted that, during the examples, it might be
appropriate to signify an explicit part of a transport address. This
is achieved by adding either the '.address' or '.port' tag on the end
of the representation -- for example, 'L-PRIV-1.address' and 'L-PRIV-
1.port'.
The use of '