draft-ietf-sipping-nat-scenarios-10.txt   draft-ietf-sipping-nat-scenarios-11.txt 
SIPPING Working Group C. Boulton SIPPING Working Group C. Boulton
Internet-Draft NS-Technologies Internet-Draft NS-Technologies
Intended status: BCP J. Rosenberg Intended status: BCP J. Rosenberg
Expires: August 16, 2010 Skype Expires: December 4, 2010 Skype
G. Camarillo G. Camarillo
Ericsson Ericsson
F. Audet F. Audet
Skype Skype
February 12, 2010 June 2, 2010
Best Current Practices for NAT Traversal for Client-Server SIP Best Current Practices for NAT Traversal for Client-Server SIP
draft-ietf-sipping-nat-scenarios-10 draft-ietf-sipping-nat-scenarios-11
Abstract Abstract
Traversal of the Session Initiation Protocol (SIP) and the sessions Traversal of the Session Initiation Protocol (SIP) and the sessions
it establishes through Network Address Translators (NATs) is a it establishes through Network Address Translators (NATs) is a
complex problem. Currently there are many deployment scenarios and complex problem. Currently there are many deployment scenarios and
traversal mechanisms for media traffic. This document aims to traversal mechanisms for media traffic. This document aims to
provide concrete recommendations and a unified method for NAT provide concrete recommendations and a unified method for NAT
traversal as well as documenting corresponding flows. traversal as well as documenting corresponding flows.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
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 This Internet-Draft will expire on December 4, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 16, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 15 skipping to change at page 2, line 9
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
4. Solution Technology Outline Description . . . . . . . . . . . 10 4. Solution Technology Outline Description . . . . . . . . . . . 10
4.1. SIP Signaling . . . . . . . . . . . . . . . . . . . . . . 10 4.1. SIP Signaling . . . . . . . . . . . . . . . . . . . . . . 10
4.1.1. Symmetric Response . . . . . . . . . . . . . . . . . . 10 4.1.1. Symmetric Response . . . . . . . . . . . . . . . . . . 10
4.1.2. Client Initiated Connections . . . . . . . . . . . . . 11 4.1.2. Client Initiated Connections . . . . . . . . . . . . . 11
4.2. Media Traversal . . . . . . . . . . . . . . . . . . . . . 11 4.2. Media Traversal . . . . . . . . . . . . . . . . . . . . . 11
4.2.1. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . 12 4.2.1. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . 12
4.2.2. RTCP . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2.2. RTCP . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.3. ICE/STUN/TURN . . . . . . . . . . . . . . . . . . . . 12 4.2.3. STUN/TURN/ICE . . . . . . . . . . . . . . . . . . . . 12
5. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . . . 15 5. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . . . 15
5.1. Basic NAT SIP Signaling Traversal . . . . . . . . . . . . 15 5.1. Basic NAT SIP Signaling Traversal . . . . . . . . . . . . 15
5.1.1. Registration (Registrar/Edge Proxy Co-Located) . . . . 15 5.1.1. Registration (Registrar/Edge Proxy Co-Located) . . . . 15
5.1.2. Registration(Registrar/Edge Proxy not Co-Located) . . 18 5.1.2. Registration(Registrar/Edge Proxy not Co-Located) . . 18
5.1.3. Initiating a Session . . . . . . . . . . . . . . . . . 21 5.1.3. Initiating a Session . . . . . . . . . . . . . . . . . 21
5.1.4. Receiving an Invitation to a Session . . . . . . . . . 24 5.1.4. Receiving an Invitation to a Session . . . . . . . . . 24
5.2. Basic NAT Media Traversal . . . . . . . . . . . . . . . . 29 5.2. Basic NAT Media Traversal . . . . . . . . . . . . . . . . 29
5.2.1. Endpoint Independent NAT . . . . . . . . . . . . . . . 30 5.2.1. Endpoint Independent NAT . . . . . . . . . . . . . . . 30
5.2.2. Address/Port-Dependent NAT . . . . . . . . . . . . . . 50 5.2.2. Address/Port-Dependent NAT . . . . . . . . . . . . . . 50
6. IPv4-IPv6 Transition . . . . . . . . . . . . . . . . . . . . . 59 6. IPv4-IPv6 Transition . . . . . . . . . . . . . . . . . . . . . 59
skipping to change at page 3, line 17 skipping to change at page 3, line 17
NAT (Network Address Translators) traversal has long been identified NAT (Network Address Translators) traversal has long been identified
as a complex problem when considered in the context of the Session as a complex problem when considered in the context of the Session
Initiation Protocol (SIP)[RFC3261] and it's associated media such as Initiation Protocol (SIP)[RFC3261] and it's associated media such as
Real Time Protocol (RTP)[RFC3550]. The problem is exacerbated by the Real Time Protocol (RTP)[RFC3550]. The problem is exacerbated by the
variety of NATs that are available in the market place today and the variety of NATs that are available in the market place today and the
large number of potential deployment scenarios. Details of different large number of potential deployment scenarios. Details of different
NATs behavior can be found in 'NAT Behavioral Requirements for NATs behavior can be found in 'NAT Behavioral Requirements for
Unicast UDP' [RFC4787]. Unicast UDP' [RFC4787].
The IETF has been active on many specifications for the traversal of The IETF has been active on many specifications for the traversal of
NATs, including STUN[RFC5389], ICE[I-D.ietf-mmusic-ice], symmetric NATs, including STUN[RFC5389], ICE[RFC5245], symmetric
response[RFC3581], symmetric RTP[RFC4961], response[RFC3581], symmetric RTP[RFC4961], TURN[RFC5766], SIP
TURN[I-D.ietf-behave-turn], SIP Outbound[RFC5626], SDP attribute for Outbound[RFC5626], SDP attribute for RTCP[RFC3605], Multiplexing RTP
RTCP[RFC3605], Multiplexing RTP Data and Control Packets on a Single Data and Control Packets on a Single Port[RFC5761] and others. These
Port[I-D.ietf-avt-rtp-and-rtcp-mux]and others. These each represent each represent a part of the solution, but none of them gives the
a part of the solution, but none of them gives the overall context overall context for how the NATs traversal problem is decomposed and
for how the NATs traversal problem is decomposed and solved through solved through this collection of specifications. This document
this collection of specifications. This document serves to meet that serves to meet that need.
need.
This document provides a definitive set of 'Best Common Practices' to This document provides a definitive set of 'Best Common Practices' to
demonstrate the traversal of SIP and its associated media through NAT demonstrate the traversal of SIP and its associated media through NAT
devices. The document does not propose any new functionality but devices. The document does not propose any new functionality but
does draw on existing solutions for both core SIP signaling and media does draw on existing solutions for both core SIP signaling and media
traversal (as defined in Section 4). traversal (as defined in Section 4).
The best practices described in this document are for traditional The best practices described in this document are for traditional
"client-server"-style SIP. This term refers to the traditional use "client-server"-style SIP. This term refers to the traditional use
of the SIP protocol where User Agents talk to a series of of the SIP protocol where User Agents talk to a series of
skipping to change at page 4, line 9 skipping to change at page 4, line 9
2. Description of proposed solutions for both SIP protocol signaling 2. Description of proposed solutions for both SIP protocol signaling
and media signaling. and media signaling.
3. A set of basic and advanced flow scenarios. 3. A set of basic and advanced flow scenarios.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC4787].
It should be noted that the use of the term 'Endpoint Independent It should be noted that the use of the term 'Endpoint Independent
NAT' in this document refers to a NAT that is both 'Endpoint NAT' in this document refers to a NAT that is both 'Endpoint
Independent Filtering NAT' and 'Endpoint Independent Mapping NAT' per Independent Filtering NAT' and 'Endpoint Independent Mapping NAT' per
RFC 4787 [RFC2119] definition. RFC 4787 [RFC4787] definition.
3. Problem Statement 3. Problem Statement
The traversal of SIP through NATs can be split into two categories The traversal of SIP through NATs can be split into two categories
that both require attention - The core SIP signaling and associated that both require attention - The core SIP signaling and associated
media traversal. This document assumes NATs that do not contain SIP- media traversal. This document assumes NATs that do not contain SIP-
aware Application Layer Gateways(ALG), which makes much of the issues aware Application Layer Gateways(ALG), which makes much of the issues
discussed in the document not applicable. ALGs have limitations (as discussed in the document not applicable. ALGs have limitations (as
per RFC 4787 [RFC4787]/section 7, RFC 3424 [RFC3424], and per RFC 4787 [RFC4787]/section 7, RFC 3424 [RFC3424], and [RFC5245]/
[I-D.ietf-mmusic-ice]/section 18.6) and experience shows they can section 18.6) and experience shows they can have an adverse impact on
have an adverse impact on the functionality of SIP. This includes the functionality of SIP. This includes problems such as requiring
problems such as requiring the media and signaling to traverse the the media and signaling to traverse the same device and not working
same device and not working with encrypted signaling and/or payload. with encrypted signaling and/or payload.
It should also be noted that Session Border Controllers (SBC) doing It should also be noted that Session Border Controllers (SBC) doing
'hosted NAT traversal' also make many of the discussions in this 'hosted NAT traversal' also make many of the discussions in this
document moot. More information can be obtained from document moot. More information can be obtained from [RFC5853] and
[I-D.ietf-sipping-sbc-funcs] and
[I-D.ietf-mmusic-media-path-middleboxes]. [I-D.ietf-mmusic-media-path-middleboxes].
The core SIP signaling has a number of issues when traversing through The core SIP signaling has a number of issues when traversing through
NATs. NATs.
Normal SIP response routing over UDP causes the response to be Normal SIP response routing over UDP causes the response to be
delivered to the source IP address specified in the topmost Via delivered to the source IP address specified in the topmost Via
header, or the "received" parameter of the topmost Via header. The header, or the "received" parameter of the topmost Via header. The
port is extracted from the SIP 'Via' header to complete the IP port is extracted from the SIP 'Via' header to complete the IP
address/port combination for returning the SIP response. While the address/port combination for returning the SIP response. While the
skipping to change at page 12, line 16 skipping to change at page 12, line 16
The primary problem identified in Section 3 of this document is that The primary problem identified in Section 3 of this document is that
internal IP address/port combinations can not be reached from the internal IP address/port combinations can not be reached from the
public side of NATs. In the case of media such as RTP, this will 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 result in no audio traversing NATs (as illustrated in Figure 3). To
overcome this problem, a technique called 'Symmetric RTP/ overcome this problem, a technique called 'Symmetric RTP/
RTCP'[RFC4961] can be used. This involves a SIP endpoint both RTCP'[RFC4961] can be used. This involves a SIP endpoint both
sending and receiving RTP/RTCP traffic from the same IP address/port sending and receiving RTP/RTCP traffic from the same IP address/port
combination. When operating behind a NAT and using the 'latching' combination. When operating behind a NAT and using the 'latching'
technique described in [I-D.ietf-mmusic-media-path-middleboxes], SIP technique described in [I-D.ietf-mmusic-media-path-middleboxes], SIP
user agents SHOULD implement 'Symmetric RTP/RTCP'. This allows user agents MUST implement 'Symmetric RTP/RTCP'. This allows
traversal of RTP across the NAT. traversal of RTP across the NAT.
4.2.2. RTCP 4.2.2. RTCP
Normal practice when selecting a port for defining RTP Control Normal practice when selecting a port for defining RTP Control
Protocol (RTCP) [RFC3550] is for consecutive order numbering (i.e Protocol (RTCP) [RFC3550] is for consecutive order numbering (i.e
select an incremented port for RTCP from that used for RTP). This select an incremented port for RTCP from that used for RTP). This
assumption causes RTCP traffic to break when traversing certain types assumption causes RTCP traffic to break when traversing certain types
of NATs due to various reasons (e.g., already-allocated port, of NATs due to various reasons (e.g., already-allocated port,
randomized port allocation). To combat this problem a specific randomized port allocation). To combat this problem a specific
address and port need to be specified in the SDP rather than relying address and port need to be specified in the SDP rather than relying
on such assumptions. RFC 3605 [RFC3605] defines an SDP attribute on such assumptions. RFC 3605 [RFC3605] defines an SDP attribute
that is included to explicitly specify transport connection that is included to explicitly specify transport connection
information for RTCP so a separate, explicit NAT binding can be set information for RTCP so a separate, explicit NAT binding can be set
up for the purpose. The address details can be obtained using any up for the purpose. The address details can be obtained using any
appropriate method including those detailed in this section (e.g. appropriate method including those detailed in this section (e.g.
STUN, TURN, ICE). STUN, TURN, ICE).
A further enhancement to RFC 3605 [RFC3605] is defined in A further enhancement to RFC 3605 [RFC3605] is defined in [RFC5761]
[I-D.ietf-avt-rtp-and-rtcp-mux] which specifies 'muxing' both RTP and which specifies 'muxing' both RTP and RTCP on the same IP/PORT
RTCP on the same IP/PORT combination. combination.
4.2.3. ICE/STUN/TURN 4.2.3. STUN/TURN/ICE
ICE, STUN and TURN are a suite of 3 inter-related protocols that ICE, STUN and TURN are a suite of 3 inter-related protocols that
combine to provide a complete media traversal solution for NATs. The combine to provide a complete media traversal solution for NATs. The
following sections provide details of each component part. following sections provide details of each component part.
4.2.3.1. STUN 4.2.3.1. STUN
Session Traversal Utilities for NAT or STUN is defined in RFC 5389 Session Traversal Utilities for NAT or STUN is defined in RFC 5389
[RFC5389]. STUN is a lightweight tool kit and protocol that provides [RFC5389]. STUN is a lightweight tool kit and protocol that provides
details of the external IP address/port combination used by the NAT details of the external IP address/port combination used by the NAT
skipping to change at page 13, line 24 skipping to change at page 13, line 24
As mentioned in Section 4.1.2, STUN is also used as a client-to- As mentioned in Section 4.1.2, STUN is also used as a client-to-
server keep-alive mechanism to refresh NAT bindings. server keep-alive mechanism to refresh NAT bindings.
4.2.3.2. TURN 4.2.3.2. TURN
As described in the Section 4.2.3.1, the STUN protocol does not work As described in the Section 4.2.3.1, the STUN protocol does not work
for UDP traversal through certain identified NAT mappings. for UDP traversal through certain identified NAT mappings.
'Traversal Using Relays around NAT' is a usage of the STUN protocol '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 for deriving (from a TURN server) an address that will be used to
relay packets towards a client. TURN provides an external address relay packets towards a client. TURN provides an external address
(globally routable) at a TUREN server that will act as a media relay (globally routable) at a TURN server that will act as a media relay
which attempts to allow traffic to reach the associated internal which attempts to allow traffic to reach the associated internal
address. The full details of the TURN specification are defined in address. The full details of the TURN specification are defined in
[I-D.ietf-behave-turn]. A TURN service will almost always provide [RFC5766]. A TURN service will almost always provide media traffic
media traffic to a SIP entity but it is RECOMMENDED that this method to a SIP entity but it is RECOMMENDED that this method would only be
would only be used as a last resort and not as a general mechanism used as a last resort and not as a general mechanism for NAT
for NAT traversal. This is because using TURN has high performance traversal. This is because using TURN has high performance costs
costs when relaying media traffic and can lead to unwanted latency. when relaying media traffic and can lead to unwanted latency.
4.2.3.3. ICE 4.2.3.3. ICE
Interactive Connectivity Establishment (ICE) is the RECOMMENDED Interactive Connectivity Establishment (ICE) is the RECOMMENDED
method for traversal of existing NATs if Symmetric RTP is not method for traversal of existing NATs if Symmetric RTP and media
sufficient (e.g., there isn't an SBC performing 'latching'). ICE is latching is not sufficient. ICE is a methodology for using existing
a methodology for using existing technologies such as STUN, TURN and technologies such as STUN, TURN and any other UNSAF[RFC3424]
any other UNSAF[RFC3424] compliant protocol to provide a unified compliant protocol to provide a unified solution. This is achieved
solution. This is achieved by obtaining as many representative IP by obtaining as many representative IP address/port combinations as
address/port combinations as possible using technologies such as possible using technologies such as STUN/TURN (*note - an ICE
STUN/TURN (*note - an ICE endpoint can also use other mechanisms endpoint can also use other mechanisms (e.g., NAT-
(e.g., NAT-PMP, UPnP IGD) to learn public IP addresses and ports, and PMP[I-D.cheshire-nat-pmp], UPnP IGD[UPnP-IGD]) to learn public IP
populate a=candidate lines with that information). Once the addresses and ports, and populate a=candidate lines with that
addresses are accumulated, they are all included in the SDP exchange information). Once the addresses are accumulated, they are all
in a new media attribute called 'candidate'. Each 'candidate' SDP included in the SDP exchange in a new media attribute called
attribute entry has detailed connection information including a media 'candidate'. Each 'candidate' SDP attribute entry has detailed
address, priority and transport protocol. The appropriate IP connection information including a media address, priority and
address/port combinations are used in the order specified by the transport protocol. The appropriate IP address/port combinations are
priority. A client compliant to the ICE specification will then used in the order specified by the priority. A client compliant to
locally run STUN servers on all addresses being advertised using ICE. the ICE specification will then locally run STUN servers on all
addresses being advertised using ICE. Each instance will undertake
Each instance will undertake connectivity checks to ensure that a connectivity checks to ensure that a client can successfully receive
client can successfully receive media on the advertised address. media on the advertised address. Only connections that pass the
Only connections that pass the relevant connectivity checks are used relevant connectivity checks are used for media exchange. The full
for media exchange. The full details of the ICE methodology are details of the ICE methodology are contained in [RFC5245].
contained in [I-D.ietf-mmusic-ice].
5. NAT Traversal Scenarios 5. NAT Traversal Scenarios
This section of the document includes detailed NAT traversal This section of the document includes detailed NAT traversal
scenarios for both SIP signaling and the associated media. scenarios for both SIP signaling and the associated media.
Signalling NAT traversal is achieved using [RFC5626]. Signalling NAT traversal is achieved using [RFC5626].
5.1. Basic NAT SIP Signaling Traversal 5.1. Basic NAT SIP Signaling Traversal
The following sub-sections concentrate on SIP signaling traversal of The following sub-sections concentrate on SIP signaling traversal of
skipping to change at page 29, line 31 skipping to change at page 29, line 31
o The "Dest" attribute represents the destination transport address o The "Dest" attribute represents the destination transport address
of the message. of the message.
o The "Map" attribute represents the server reflexive (XOR-MAPPED- o The "Map" attribute represents the server reflexive (XOR-MAPPED-
ADDRESS STUN attribute) transport address. ADDRESS STUN attribute) transport address.
o The "Rel" attribute represents the relayed (RELAY-ADDRESS STUN o The "Rel" attribute represents the relayed (RELAY-ADDRESS STUN
attribute) transport address. attribute) transport address.
The meaning of each STUN attribute is extensively explained in the The meaning of each STUN attribute is extensively explained in the
core STUN[RFC5389] and TURN [I-D.ietf-behave-turn] drafts. core STUN[RFC5389] and TURN [RFC5766] specifications.
A number of ICE SDP attributes have also been included in some of the A number of ICE SDP attributes have also been included in some of the
examples. Detailed information on individual attributes can be examples. Detailed information on individual attributes can be
obtained from the core ICE specification[I-D.ietf-mmusic-ice]. obtained from the core ICE specification[RFC5245].
The examples also contain a mechanism for representing transport The examples also contain a mechanism for representing transport
addresses. It would be confusing to include representations of addresses. It would be confusing to include representations of
network addresses in the call flows and make them hard to follow. network addresses in the call flows and make them hard to follow.
For this reason network addresses will be represented using the For this reason network addresses will be represented using the
following annotation. The first component will contain the following annotation. The first component will contain the
representation of the client responsible for the address. For representation of the client responsible for the address. For
example in the majority of the examples "L" (left client), "R" (right example in the majority of the examples "L" (left client), "R" (right
client), NAT-PUB" (NAT public), PRIV (Private), and "STUN-PUB" (STUN client), NAT-PUB" (NAT public), PRIV (Private), and "STUN-PUB" (STUN
Public) are used. To allow for multiple addresses from the same Public) are used. To allow for multiple addresses from the same
skipping to change at page 30, line 23 skipping to change at page 30, line 23
5.2.1. Endpoint Independent NAT 5.2.1. Endpoint Independent NAT
This section demonstrates an example of a client both initiating and This section demonstrates an example of a client both initiating and
receiving calls behind an 'Endpoint independent' NAT. An example is receiving calls behind an 'Endpoint independent' NAT. An example is
included for both STUN and ICE with ICE being the RECOMMENDED included for both STUN and ICE with ICE being the RECOMMENDED
mechanism for media traversal. mechanism for media traversal.
At this time there is no reliable test to determine if a host is At this time there is no reliable test to determine if a host is
behind an 'endpoint independent filtering' NAT or an 'endpoint behind an 'endpoint independent filtering' NAT or an 'endpoint
independent mapping' NAT [I-D.ietf-behave-nat-behavior-discovery], independent mapping' NAT [RFC5780], and the sort of failure that
and the sort of failure that occurs in this situation is described in occurs in this situation is described in Section 5.2.2.1. For this
Section 5.2.2.1. For this reason, ICE is RECOMMENDED over the reason, ICE is RECOMMENDED over the mechanism described in this
mechanism described in this section. section.
5.2.1.1. STUN Solution 5.2.1.1. STUN Solution
It is possible to traverse media through an 'Endpoint Independent NAT It is possible to traverse media through an 'Endpoint Independent NAT
using STUN. The remainder of this section provides simplified using STUN. The remainder of this section provides simplified
examples of the 'Binding Discovery' STUN as defined in [RFC5389]. examples of the 'Binding Discovery' STUN as defined in [RFC5389].
The STUN messages have been simplified and do not include 'Shared The STUN messages have been simplified and do not include 'Shared
Secret' requests used to obtain the temporary username and password. Secret' requests used to obtain the temporary username and password.
5.2.1.1.1. Initiating Session 5.2.1.1.1. Initiating Session
skipping to change at page 45, line 41 skipping to change at page 45, line 41
(3)). It also contains an appropriate TURN-relayed address that (3)). It also contains an appropriate TURN-relayed address that
can be used at the STUN server (see 'Rel=TURN-PUB-2'). can be used at the STUN server (see 'Rel=TURN-PUB-2').
o The Allocate response traverses back through the NAT using the o The Allocate response traverses back through the NAT using the
binding created by the initial Allocate request and presents the binding created by the initial Allocate request and presents the
new mapped address to the client (4). The process is repeated and new mapped address to the client (4). The process is repeated and
a second STUN derived set of address' are obtained, as illustrated a second STUN derived set of address' are obtained, as illustrated
in (5)-(8) in Figure 13. At this point the User Agent behind the in (5)-(8) in Figure 13. At this point the User Agent behind the
NAT has pairs of derived external server reflexive and relayed NAT has pairs of derived external server reflexive and relayed
representations. The client can also gather IP addresses and representations. The client can also gather IP addresses and
ports via other mechanisms (e.g., NAT-PMP, UPnP IGD)." or similar. ports via other mechanisms (e.g., NAT-PMP[I-D.cheshire-nat-pmp],
UPnP IGD[UPnP-IGD]) or similar.
o The client now constructs a SIP INVITE message (9). The INVITE o The client now constructs a SIP INVITE message (9). The INVITE
request will use the addresses it has obtained in the previous request will use the addresses it has obtained in the previous
STUN/TURN interactions to populate the SDP of the SIP INVITE. STUN/TURN interactions to populate the SDP of the SIP INVITE.
This should be carried out in accordance with the semantics This should be carried out in accordance with the semantics
defined in the ICE specification[I-D.ietf-mmusic-ice], as shown defined in the ICE specification[RFC5245], as shown below in
below in Figure 14: Figure 14:
v=0 v=0
o=test 2890844526 2890842807 IN IP4 $L-PRIV-1 o=test 2890844526 2890842807 IN IP4 $L-PRIV-1
c=IN IP4 $L-PRIV-1.address c=IN IP4 $L-PRIV-1.address
t=0 0 t=0 0
a=ice-pwd:$LPASS a=ice-pwd:$LPASS
a=ice-ufrag:$LUNAME a=ice-ufrag:$LUNAME
m=audio $L-PRIV-1.port RTP/AVP 0 m=audio $L-PRIV-1.port RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtcp:$L-PRIV-2.port a=rtcp:$L-PRIV-2.port
skipping to change at page 52, line 42 skipping to change at page 52, line 42
STUN request that was sent to the STUN server. Any packets that STUN request that was sent to the STUN server. Any packets that
attempt to use the mapped address, that do not originate from the attempt to use the mapped address, that do not originate from the
STUN server IP address and optionally port, will be dropped at the STUN server IP address and optionally port, will be dropped at the
NAT. Figure 18 shows the media being dropped at the NAT after (7) NAT. Figure 18 shows the media being dropped at the NAT after (7)
and before (8). This then leads to one way audio. and before (8). This then leads to one way audio.
5.2.2.2. TURN Solution 5.2.2.2. TURN Solution
As identified in Section 5.2.2.1, STUN provides a useful tool for the As identified in Section 5.2.2.1, STUN provides a useful tool for the
traversal of the majority of NATs but fails with Port/Address traversal of the majority of NATs but fails with Port/Address
Dependent NAT. The TURN extensions [I-D.ietf-behave-turn] address Dependent NAT. The TURN extensions [RFC5766] address this scenario.
this scenario. TURN extends STUN to allow a client to request a TURN extends STUN to allow a client to request a relayed address at
relayed address at the TURN server rather than a reflexive the TURN server rather than a reflexive representation. This then
representation. This then introduces a media relay in the path for introduces a media relay in the path for NAT traversal (as described
NAT traversal (as described in Section 4.2.3.2). The following in Section 4.2.3.2). The following example explains how TURN solves
example explains how TURN solves the previous failure when using STUN the previous failure when using STUN to traverse a 'Port/Address
to traverse a 'Port/Address Dependent' type NAT. It should be noted Dependent' type NAT. It should be noted that TURN works most
that TURN works most effectively when used in conjunction with ICE. effectively when used in conjunction with ICE. Using TURN on its own
Using TURN on its own results in all media being relayed through a results in all media being relayed through a TURN server which is not
TURN server which is not efficient. efficient.
L Port/Address-Dependant TURN [..] L Port/Address-Dependant TURN [..]
NAT Server NAT Server
| | | | | | | |
|(1) Alloc Req | | | |(1) Alloc Req | | |
|Src=L-PRIV-1 | | | |Src=L-PRIV-1 | | |
|Dest=STUN-PUB-1 | | | |Dest=STUN-PUB-1 | | |
|----------------->| | | |----------------->| | |
| | | | | | | |
| |(2) Alloc Req | | | |(2) Alloc Req | |
skipping to change at page 56, line 12 skipping to change at page 56, line 12
entity is not an efficient mechanism for NAT traversal and comes entity is not an efficient mechanism for NAT traversal and comes
at a high processing cost. at a high processing cost.
5.2.2.3. ICE Solution 5.2.2.3. ICE Solution
The previous two examples have highlighted the problem with using The previous two examples have highlighted the problem with using
core STUN for all forms of NAT traversal and a solution using TURN core STUN for all forms of NAT traversal and a solution using TURN
for the Address/Port-Dependent NAT case. The RECOMMENDED mechanism for the Address/Port-Dependent NAT case. The RECOMMENDED mechanism
for traversing all varieties of NAT is using ICE, as detailed in for traversing all varieties of NAT is using ICE, as detailed in
Section 4.2.3.3. ICE makes use of core STUN, TURN and any other Section 4.2.3.3. ICE makes use of core STUN, TURN and any other
mechanism (e.g., NAT-PMP, UPnP IGD) to provide a list of prioritized mechanism (e.g., NAT-PMP[I-D.cheshire-nat-pmp], UPnP IGD[UPnP-IGD])
addresses that can be used for media traffic. Detailed examples of to provide a list of prioritized addresses that can be used for media
ICE can be found in Section 5.2.1.2.1. These examples are associated traffic. Detailed examples of ICE can be found in Section 5.2.1.2.1.
with an 'Endpoint-Independent' type NAT but can be applied to any NAT These examples are associated with an 'Endpoint-Independent' type NAT
type variation, including 'Address/Port-Dependant' type NAT. The ICE but can be applied to any NAT type variation, including 'Address/
procedures carried out are the same. For a list of candidate Port-Dependant' type NAT. The ICE procedures carried out are the
addresses, a client will choose where to send media dependant on the same. For a list of candidate addresses, a client will choose where
results of the STUN connectivity checks and associated priority to send media dependant on the results of the STUN connectivity
(highest priority wins). It should be noted that the inclusion of a checks and associated priority (highest priority wins). It should be
NAT displaying Address/Port-Dependent properties does not noted that the inclusion of a NAT displaying Address/Port-Dependent
automatically result in relayed media. In fact, ICE processing will properties does not automatically result in relayed media. In fact,
avoid use of media relay with the exception of two clients which both ICE processing will avoid use of media relay with the exception of
happen to be behind a NAT using Address/Port-Dependent two clients which both happen to be behind a NAT using Address/
characteristics. The connectivity checks and associated selection Port-Dependent characteristics. The connectivity checks and
algorithm enable traversal in this case. Figure 20 and following associated selection algorithm enable traversal in this case.
description provide a guide as to how this is achieved using the ICE Figure 20 and following description provide a guide as to how this is
connectivity checks. This is an abbreviated example that assumes achieved using the ICE connectivity checks. This is an abbreviated
successful SIP offer/answer exchange and illustrates the connectivity example that assumes successful SIP offer/answer exchange and
check flow. illustrates the connectivity check flow.
L Port/Address-Dependent Endpoint-Independent R L Port/Address-Dependent Endpoint-Independent R
L-NAT R-NAT L-NAT R-NAT
|========================================================| |========================================================|
| SIP OFFER/ANSWER EXCHANGE | | SIP OFFER/ANSWER EXCHANGE |
|========================================================| |========================================================|
| | | | | | | |
| | |(1)Bind Req | | | |(1)Bind Req |
| | |<-----------------| | | |<-----------------|
| | |Src=R=PRIV-1 | | | |Src=R=PRIV-1 |
skipping to change at page 64, line 9 skipping to change at page 64, line 9
supportive throughout. supportive throughout.
Detailed comments were provided by Vijay Gurbani, kaiduan xie, Remi Detailed comments were provided by Vijay Gurbani, kaiduan xie, Remi
Denis-Courmont, Hadriel Kaplan, Phillip Matthews, Spencer Dawkins and Denis-Courmont, Hadriel Kaplan, Phillip Matthews, Spencer Dawkins and
Hans Persson. Hans Persson.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-avt-rtp-and-rtcp-mux]
Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port",
draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress),
August 2007.
[I-D.ietf-behave-turn]
Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)",
draft-ietf-behave-turn-16 (work in progress), July 2009.
[I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-sip-connect-reuse] [I-D.ietf-sip-connect-reuse]
Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in
the Session Initiation Protocol (SIP)", the Session Initiation Protocol (SIP)",
draft-ietf-sip-connect-reuse-14 (work in progress), draft-ietf-sip-connect-reuse-14 (work in progress),
August 2009. August 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263, Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002. June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
skipping to change at page 65, line 27 skipping to change at page 65, line 5
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
BCP 131, RFC 4961, July 2007. BCP 131, RFC 4961, July 2007.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
April 2010.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009. (SIP)", RFC 5626, October 2009.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
11.2. Informative References 11.2. Informative References
[I-D.ietf-behave-nat-behavior-discovery] [I-D.cheshire-nat-pmp]
MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)",
Using STUN", draft-ietf-behave-nat-behavior-discovery-08 draft-cheshire-nat-pmp-03 (work in progress), April 2008.
(work in progress), September 2009.
[I-D.ietf-mmusic-media-path-middleboxes] [I-D.ietf-mmusic-media-path-middleboxes]
Stucker, B. and H. Tschofenig, "Analysis of Middlebox Stucker, B. and H. Tschofenig, "Analysis of Middlebox
Interactions for Signaling Protocol Communication along Interactions for Signaling Protocol Communication along
the Media Path", the Media Path",
draft-ietf-mmusic-media-path-middleboxes-02 (work in draft-ietf-mmusic-media-path-middleboxes-02 (work in
progress), March 2009. progress), March 2009.
[I-D.ietf-sipping-sbc-funcs]
Hautakorpi, J., Camarillo, G., Penfield, B., Hawrylyshen,
A., and M. Bhatia, "Requirements from SIP (Session
Initiation Protocol) Session Border Control Deployments",
draft-ietf-sipping-sbc-funcs-08 (work in progress),
January 2009.
[I-D.ietf-sipping-v6-transition] [I-D.ietf-sipping-v6-transition]
Camarillo, G., "IPv6 Transition in the Session Initiation Camarillo, G., "IPv6 Transition in the Session Initiation
Protocol (SIP)", draft-ietf-sipping-v6-transition-07 (work Protocol (SIP)", draft-ietf-sipping-v6-transition-07 (work
in progress), August 2007. in progress), August 2007.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002. Translation", RFC 3424, November 2002.
[RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery
Using Session Traversal Utilities for NAT (STUN)",
RFC 5780, May 2010.
[RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen,
A., and M. Bhatia, "Requirements from Session Initiation
Protocol (SIP) Session Border Control (SBC) Deployments",
RFC 5853, April 2010.
[UPnP-IGD]
UPnP Forum, "Universal Plug and Play Internet Gateway
Device v1.0", 2000,
<http://www.upnp.org/standardizeddcps/igd.asp>.
Authors' Addresses Authors' Addresses
Chris Boulton Chris Boulton
NS-Technologies NS-Technologies
Email: chris@ns-technologies.com Email: chris@ns-technologies.com
Jonathan Rosenberg Jonathan Rosenberg
Skype Skype
 End of changes. 34 change blocks. 
137 lines changed or deleted 127 lines changed or added

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