draft-ietf-sipping-nat-scenarios-04.txt   draft-ietf-sipping-nat-scenarios-05.txt 
SIPPING Working Group C. Boulton SIPPING Working Group C. Boulton, Ed.
Internet-Draft Ubiquity Software Corporation Internet-Draft Ubiquity Software Corporation
Expires: September 3, 2006 J. Rosenberg Expires: December 28, 2006 J. Rosenberg
Cisco Systems Cisco Systems
G. Camarillo G. Camarillo
Ericsson Ericsson
March 2, 2006 June 26, 2006
Best Current Practices for NAT Traversal for SIP Best Current Practices for NAT Traversal for SIP
draft-ietf-sipping-nat-scenarios-04 draft-ietf-sipping-nat-scenarios-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 3, 2006. This Internet-Draft will expire on December 28, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
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 (NAT) is a complex it establishes through Network Address Translators (NAT) is a complex
problem. Currently there are many deployment scenarios and traversal problem. Currently there are many deployment scenarios and traversal
skipping to change at page 2, line 17 skipping to change at page 2, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. Solution Technology Outline Description . . . . . . . . . . . 6 3. Solution Technology Outline Description . . . . . . . . . . . 6
3.1. SIP Signaling . . . . . . . . . . . . . . . . . . . . . . 7 3.1. SIP Signaling . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. Symmetric Response . . . . . . . . . . . . . . . . . . 7 3.1.1. Symmetric Response . . . . . . . . . . . . . . . . . . 7
3.1.2. Connection Re-use . . . . . . . . . . . . . . . . . . 8 3.1.2. Connection Re-use . . . . . . . . . . . . . . . . . . 8
3.2. Media Traversal . . . . . . . . . . . . . . . . . . . . . 8 3.2. Media Traversal . . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Symmetric RTP . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Symmetric RTP . . . . . . . . . . . . . . . . . . . . 8
3.2.2. STUN . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.2. STUN . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.3. TURN . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.3. TURN . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.4. ICE . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.4. ICE . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.5. RTCP Attribute . . . . . . . . . . . . . . . . . . . . 10 3.2.5. Solution Profiles . . . . . . . . . . . . . . . . . . 10
3.2.6. Solution Profiles . . . . . . . . . . . . . . . . . . 10
4. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . . . 11 4. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . . . 11
4.1. Basic NAT SIP Signaling Traversal . . . . . . . . . . . . 11 4.1. Basic NAT SIP Signaling Traversal . . . . . . . . . . . . 11
4.1.1. Registration (Registrar/Proxy Co-Located) . . . . . . 11 4.1.1. Registration (Registrar/Proxy Co-Located) . . . . . . 11
4.1.2. Registration(Registrar/Proxy not Co-Located) . . . . . 15 4.1.2. Registration(Registrar/Proxy not Co-Located) . . . . . 15
4.1.3. Initiating a Session . . . . . . . . . . . . . . . . . 16 4.1.3. Initiating a Session . . . . . . . . . . . . . . . . . 18
4.1.4. Receiving an Invitation to a Session . . . . . . . . . 18 4.1.4. Receiving an Invitation to a Session . . . . . . . . . 20
4.2. Basic NAT Media Traversal . . . . . . . . . . . . . . . . 21 4.2. Basic NAT Media Traversal . . . . . . . . . . . . . . . . 23
4.2.1. Port Restricted Cone NAT . . . . . . . . . . . . . . . 21 4.2.1. Endpoint independent NAT . . . . . . . . . . . . . . . 24
4.2.2. Symmetric NAT . . . . . . . . . . . . . . . . . . . . 33 4.2.2. Port and Address Dependant NAT . . . . . . . . . . . . 40
4.3. Advanced NAT media Traversal Using ICE . . . . . . . . . . 38 4.3. Address independent Port Restricted NAT --> Address
4.3.1. Full Cone --> Full Cone traversal . . . . . . . . . . 38 independent Port Restricted NAT traversal . . . . . . . . 46
4.3.2. Port Restricted Cone --> Port Restricted Cone 4.4. Internal TURN Usage (Enterprise Deployment) . . . . . . . 46
traversal . . . . . . . . . . . . . . . . . . . . . . 38 5. Intercepting Intermediary (B2BUA) . . . . . . . . . . . . . . 46
4.3.3. Internal TURN Server (Enterprise Deployment) . . . . . 38 6. IPv4-IPv6 Transition . . . . . . . . . . . . . . . . . . . . . 47
4.4. Intercepting Intermediary (B2BUA) . . . . . . . . . . . . 38 6.1. IPv4-IPv6 Transition for SIP Signalling . . . . . . . . . 47
4.5. IPv4-IPv6 Transition . . . . . . . . . . . . . . . . . . . 38 6.2. IPv4-IPv6 Transition for Media . . . . . . . . . . . . . . 47
4.5.1. IPv4-IPv6 Transition for SIP Signalling . . . . . . . 39 7. ICE with RTP/TCP . . . . . . . . . . . . . . . . . . . . . . . 50
4.5.2. IPv4-IPv6 Transition for Media . . . . . . . . . . . . 39 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50
4.6. ICE with RTP/TCP . . . . . . . . . . . . . . . . . . . . . 41 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 9.1. Normative References . . . . . . . . . . . . . . . . . . . 50
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 9.2. Informative References . . . . . . . . . . . . . . . . . . 52
6.1. Normative References . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2. Informative References . . . . . . . . . . . . . . . . . . 43 Intellectual Property and Copyright Statements . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
Intellectual Property and Copyright Statements . . . . . . . . . . 45
1. Introduction 1. Introduction
NAT (Network Address Translators) traversal has long been identified NAT (Network Address Translators) traversal has long been identified
as a large problem when considered in the context of the Session as a large problem when considered in the context of the Session
Initiation Protocol (SIP)[1] and it's associated media such as Real Initiation Protocol (SIP)[1] and it's associated media such as Real
Time Protocol (RTP)[2]. The problem is further confused by the Time Protocol (RTP)[2]. The problem is further confused 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. Detail of different large number of potential deployment scenarios. Detail of different
NAT types can be found in RFC 3489bis [16]. NAT behaviors can be found in 'NAT Behavioral Requirements for
Unicast UDP' [11].
The IETF has produced many specifications for the traversal of NAT, The IETF has produced many specifications for the traversal of NAT,
including STUN, ICE, rport, symmetric RTP, TURN, connection reuse, including STUN, ICE, rport, symmetric RTP, TURN, SIP Outbound, SDP
SDP attribute for RTCP, and others. These each represent a part of attribute for RTCP, and others. These each represent a part of the
the solution, but none of them gives the overall context for how the solution, but none of them gives the overall context for how the NAT
NAT traversal problem is decomposed and solved through this traversal problem is decomposed and solved through this collection of
collection of specifications. This document serves to meet that specifications. This document serves to meet that need.
need.
This document attempts to provide a definitive set of 'Best Common This document attempts to provide a definitive set of 'Best Common
Practices' to demonstrate the traversal of SIP and its associated Practices' to demonstrate the traversal of SIP and its associated
media through NAT devices. The document does not propose any new media through NAT devices. The document does not propose any new
functionality but does draw on existing solutions for both core SIP functionality but does draw on existing solutions for both core SIP
signaling and media traversal (as defined in Section 3). signaling and media traversal (as defined in Section 3).
The draft will be split into distinct sections as follows: The draft will be split into distinct sections as follows:
1. A clear definition of the problem statement 1. A clear definition of the problem statement
2. Description of proposed solutions for both SIP protocol signaling 2. Description of proposed solutions for both SIP protocol signaling
skipping to change at page 3, line 46 skipping to change at page 3, line 46
The traversal of SIP through NAT can be split into two categories The traversal of SIP through NAT 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. media traversal.
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.
Firstly, the default operation for SIP response generation using Firstly, the default operation for SIP response generation using
unreliable protocols such as the Unicast Datagram Protocol (UDP) unreliable protocols such as the Unicast Datagram Protocol (UDP)
results in responses being generated at the User Agent Server (UAS) results in responses generated at the User Agent Server (UAS) being
being sent to the source address, as specified in either the SIP sent to the source address, as specified in either the SIP 'Via'
'Via' header or the 'received' parameter (as defined in RFC 3261 header or the 'received' parameter (as defined in RFC 3261 [1]). The
[1]). The port is extracted from the SIP 'Via' header to complete port is extracted from the SIP 'Via' header to complete the IP
the IP address/port combination for returning the SIP response. address/port combination for returning the SIP response. While the
While the destination is correct, the port contained in the SIP 'Via' destination is correct, the port contained in the SIP 'Via' header
header represents the listening port of the originating client and represents the listening port of the originating client and not the
not the port representing the open pin hole on the NAT. This results port representing the open pin hole on the NAT. This results in
in responses being sent back to the NAT but to a port that is likely responses being sent back to the NAT but to a port that is likely not
not open for SIP traffic. The SIP response will then be dropped at open for SIP traffic. The SIP response will then be dropped at the
the NAT. This is illustrated in Figure 1 which depicts a SIP NAT. This is illustrated in Figure 1 which depicts a SIP response
response being returned to port 5060. being returned to port 5060.
Private NAT Public Private NAT Public
Network | Network Network | Network
| |
| |
-------- SIP Request |open port 5650 -------- -------- SIP Request |open port 5650 --------
| |-------------------->--->-----------------------| | | |-------------------->--->-----------------------| |
| | | | | | | | | |
| Client | |port 5060 SIP Response | Proxy | | Client | |port 5060 SIP Response | Proxy |
| | x<------------------------| | | | x<------------------------| |
skipping to change at page 6, line 32 skipping to change at page 6, line 32
-------- | | -------- -------- | | --------
| | | |
| | | |
| | | |
Figure 3 Figure 3
The connection address representing both clients are not available on The connection address representing both clients are not available on
the public internet and traffic can be sent from both clients through the public internet and traffic can be sent from both clients through
their NATs. The problem occurs when the traffic reaches the public their NATs. The problem occurs when the traffic reaches the public
internet and is not resolveable. The media traffic fails. The internet and is not resolvable. The media traffic fails. The
connection address extracted from the SDP payload is that of an connection address extracted from the SDP payload is that of an
internal address, and so not resolvable from the public side of the internal address, and so not resolvable from the public side of the
NAT. To complicate the problem further, a number of different NAT NAT. To complicate the problem further, a number of different NAT
topologies with different default behaviors increase the difficulty topologies with different default behaviors increase the difficulty
of proposing a single solution. of proposing a single solution.
3. Solution Technology Outline Description 3. Solution Technology Outline Description
When analyzing issues associated with traversal of SIP through When analyzing issues associated with traversal of SIP through
existing NAT, it has been identified that the problem can be split existing NAT, it has been identified that the problem can be split
skipping to change at page 8, line 17 skipping to change at page 8, line 17
responses from the same port. responses from the same port.
3.1.2. Connection Re-use 3.1.2. Connection Re-use
The second problem with sip signaling, as defined in Section 2 and The second problem with sip signaling, as defined in Section 2 and
illustrated in Figure 2, is to allow incoming requests to be properly illustrated in Figure 2, is to allow incoming requests to be properly
routed. routed.
Guidelines for devices such as User Agents that can only generate Guidelines for devices such as User Agents that can only generate
outbound connections through a NAT are documented in 'SIP Conventions outbound connections through a NAT are documented in 'SIP Conventions
for UAs with Outbound Only Connections'[11]. The document provides for UAs with Outbound Only Connections'[13]. The document provides
techniques for the reuse of a TCP connection or UDP 5-tuple for techniques that use a unique User Agent instance identifier
incoming requests. It also provides a keepalive mechanism based on (instance-id) in association with a flow identifier (Reg-id). The
using STUN to the SIP server. Usage of this specification is combination of the two identifiers provides a key to a particular
connections (both UDP and TCP) that are stored in association with
registration bindings. On receiving an incoming request to a SIP
Address-Of-Record (AOR), a proxy routes to the associated flow
created by the registration and thus a route through a NAT. It also
provides a keepalive mechanism for clients to keep NAT bindings
alive. This is achieved using peer-to-peer STUN multiplexed over the
SIP signaling connection. Usage of this specification is
RECOMMENDED. This mechanism is not transport specific and should be RECOMMENDED. This mechanism is not transport specific and should be
used for any transport protocol. used for any transport protocol.
Even if the previous draft is not used, clients SHOULD use the same Even if the SIP Outbound draft is not used, clients generating SIP
IP address and port (i.e., socket) for both transmission and receipt requests SHOULD use the same IP address and port (i.e., socket) for
of SIP messages. Doing so allows for the vast majority of industry both transmission and receipt of SIP messages. Doing so allows for
provided solutions to properly function. the vast majority of industry provided solutions to properly
function.
3.2. Media Traversal 3.2. Media Traversal
This document has already provided guidelines that recommend using This document has already provided guidelines that recommend using
extensions to the core SIP protocol to enable traversal of NATs. extensions to the core SIP protocol to enable traversal of NATs.
While ultimately not desirable, the additions are relatively straight While ultimately not desirable, the additions are relatively straight
forward and provide a simple, universal solution for varying types of forward and provide a simple, universal solution for varying types of
NAT deployment. The issues of media traversal through NATs is not NAT deployment. The issues of media traversal through NATs is not
straight forward and requires the combination of a number of straight forward and requires the combination of a number of
traversal methodologies. The technologies outlined in the remainder traversal methodologies. The technologies outlined in the remainder
skipping to change at page 9, line 7 skipping to change at page 9, line 15
result in no audio traversing a NAT(as illustrated in Figure 3). To result in no audio traversing a NAT(as illustrated in Figure 3). To
overcome this problem, a technique called 'Symmetric' RTP can be overcome this problem, a technique called 'Symmetric' RTP can be
used. This involves an SIP endpoint both sending and receiving RTP used. This involves an SIP endpoint both sending and receiving RTP
traffic from the same IP Address/Port combination. This technique traffic from the same IP Address/Port combination. This technique
also requires intelligence by a client on the public internet as it also requires intelligence by a client on the public internet as it
identifies that incoming media for a particular session does not identifies that incoming media for a particular session does not
match the information that was conveyed in the SDP. In this case the match the information that was conveyed in the SDP. In this case the
client will ignore the SDP address/port combination and return RTP to client will ignore the SDP address/port combination and return RTP to
the IP address/port combination identified as the source of the the IP address/port combination identified as the source of the
incoming media. This technique is known as 'Symmetric RTP' and is incoming media. This technique is known as 'Symmetric RTP' and is
documented in [14]. 'Symmetric RTP' SHOULD only be used for documented in [15]. 'Symmetric RTP' SHOULD only be used for
traversal of RTP through NAT when one of the participants in a media traversal of RTP through NAT when one of the participants in a media
session definitively knows that it is on the public network. session definitively knows that it is on the public network.
3.2.1.1. RTCP Attribute
Normal practice when selecting a port for defining Real Time Control
Protocol(RTCP) [2] 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 many NATs due to blocked
ports. To combat this problem a specific address and port need to be
specified in the SDP rather than relying on such assumptions. RFC
3605 [6] defines an SDP attribute that is included to explicitly
specify transport connection information for RTCP. The address
details can be obtained using any appropriate method including those
detailed previously in this section (e.g. STUN, TURN).
3.2.2. STUN 3.2.2. STUN
Simple Traversal of User Datagram Protocol(UDP) through Network Simple Traversal of User Datagram Protocol(UDP) through Network
Address Translators(NAT) or STUN is defined in RFC 3489 [10]. It Address Translators(NAT) or STUN is defined in RFC 3489bis [10].
provides a lightweight protocol that allows entities to probe and STUN is a lightweight tool kit and protocol that provides details of
discover the type of NAT that exists between itself and external the external IP address/port combination used by the NAT device to
entities. It also provides details of the external IP address/port represent the internal entity on the public facing side of a NAT. On
combination used by the NAT device to represent the internal entity learning of such an external representation, a client can use it
on the public facing side of a NAT. On learning of such an external accordingly as the connection address in SDP to provide NAT
representation, a client can use it accordingly as the connection traversal. Using terminology defined in the draft 'NAT Behavioral
address in SDP to provide NAT traversal. STUN only works with Full Requirements for Unicast UDP' [11], STUN does work with 'Endpoint
Cone, Restricted Cone and Port Restricted Cone type NATs. STUN does Independent Mapping' but does not work with either 'Address Dependent
not work with Symmetric NATs as the technique used to probe for the Mapping' or 'Address Dependent and Port Mapping' type NATs. Using
external IP address port representation using a STUN server will STUN with either of the previous two NAT mappings to probe for the
provide a different result to that required for traversal by an external IP address/port representation will provide a different
alternative SIP entity. The IP address/port combination deduced for result to that required for traversal by an alternative SIP entity.
the STUN server would be blocked for incoming packets from an The IP address/port combination deduced for the STUN server would be
alterative SIP entity. blocked for incoming packets from an alterative SIP entity.
As mentioned in Section 3.1.2, STUN is also used as a peer-to-peer
keep-alive mechanism.
3.2.3. TURN 3.2.3. TURN
As mentioned in the previous section, the STUN protocol does not work As described in the previous section, the STUN protocol does not work
for UDP traversal through a Symmetric style NAT. Traversal Using for UDP traversal through certain identified NAT mappings.
Relay NAT (TURN) provides the solution for UDP traversal of symmetric 'Obtaining Relay Addresses from Simple Traversal of UDP Through NAT
NAT. TURN is extremely similar to STUN in both syntax and operation. (known as TURN)' is a usage of the STUN protocol for deriving (from a
It provides an external address at a TURN server that will act as a STUN server) an address that will be used to relay packet towards a
relay and guarantee traffic will reach the associated internal client. TURN provides an external address (globally routable) at a
address. The full details of the TURN specification are defined in STUN server that will act as a media relay which guarantees traffic
[13]. A TURN service will almost always provide media traffic to a will reach the associated internal address. The full details of the
SIP entity but it is RECOMMENDED that this method only be used as a TURN specification are defined in [12]. A TURN service will almost
last resort and not as a general mechanism for NAT traversal. This always provide media traffic to a SIP entity but it is RECOMMENDED
is because using TURN has high performance costs when relaying media that this method only be used as a last resort and not as a general
traffic and can lead to unwanted latency. mechanism for NAT traversal. This is because using TURN has high
performance costs when relaying media traffic and can lead to
unwanted latency.
3.2.4. ICE 3.2.4. ICE
Interactive Connectivity Establishment (ICE) is the RECOMMENDED Interactive Connectivity Establishment (ICE) is the RECOMMENDED
method for traversal of existing NAT if Symmetric RTP is not method for traversal of existing NAT if Symmetric RTP is not
appropriate. ICE is a methodology for using existing technologies appropriate. ICE is a methodology for using existing technologies
such as STUN, TURN and any other UNSAF[9] compliant protocol to such as STUN, TURN and any other UNSAF[9] compliant protocol to
provide a unified solution. This is achieved by obtaining as many provide a unified solution. This is achieved by obtaining as many
representative IP address/port combinations as possible using representative IP address/port combinations as possible using
technologies such as STUN/TURN etc. Once the addresses are technologies such as STUN/TURN etc. Once the addresses are
skipping to change at page 10, line 18 skipping to change at page 10, line 44
has detailed connection information including a media addresses has detailed connection information including a media addresses
(including optional RTCP information), priority, username, password (including optional RTCP information), priority, username, password
and a unique session ID. The appropriate IP address/port and a unique session ID. The appropriate IP address/port
combinations are used in the correct order depending on the specified combinations are used in the correct order depending on the specified
priority. A client compliant to the ICE specification will then priority. A client compliant to the ICE specification will then
locally run instances of STUN servers on all addresses being locally run instances of STUN servers on all addresses being
advertised using ICE. Each instance will undertake connectivity advertised using ICE. Each instance will undertake connectivity
checks to ensure that a client can successfully receive media on the checks to ensure that a client can successfully receive media on the
advertised address. Only connections that pass the relevant advertised address. Only connections that pass the relevant
connectivity checks are used for media exchange. The full details of connectivity checks are used for media exchange. The full details of
the ICE methodology are contained in [15]. the ICE methodology are contained in [16].
3.2.5. RTCP Attribute
Normal practice when selecting a port for defining Real Time Control
Protocol(RTCP) [2] 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 many NATs due to blocked
ports. To combat this problem a specific address and port need to be
specified in the SDP rather than relying on such assumptions. RFC
3605 [6] defines an SDP attribute that is included to explicitly
specify transport connection information for RTCP. The address
details can be obtained using any appropriate method including those
detailed previously in this section (e.g. STUN, TURN).
3.2.6. Solution Profiles 3.2.5. Solution Profiles
This draft has documented a number of technology solutions for the This draft has documented a number of technology solutions for the
traversal of media through differing NAT deployments. A number of traversal of media through differing NAT deployments. A number of
'profiles' will now be defined that categorize varying levels of 'profiles' will now be defined that categorize varying levels of
support for the technologies described. support for the technologies described.
3.2.6.1. Primary Profile 3.2.5.1. Primary Profile
A client falling into the 'Primary' profile supports ICE in A client falling into the 'Primary' profile supports ICE in
conjunction with STUN, TURN and RFC 3605 [6] for RTCP. ICE is used conjunction with STUN, TURN and RFC 3605 [6] for RTCP. ICE is used
in all cases and falls back to standard operation when dealing with in all cases and falls back to standard operation when dealing with
non-ICE clients. A client which falls into the 'Primary' profile non-ICE clients. A client which falls into the 'Primary' profile
will be maximally interoperable and function in a rich variety of will be maximally interoperable and function in a rich variety of
environments including enterprise, consumer and behind all varieties environments including enterprise, consumer and behind all varieties
of NAT. of NAT.
3.2.6.2. Consumer Profile 3.2.5.2. Consumer Profile
A client falling into the 'Consumer' profile supports STUN and RFC A client falling into the 'Consumer' profile supports STUN and RFC
3605 [6] for RTCP. It uses STUN to allocate bindings, and can also 3605 [6] for RTCP. It uses STUN to allocate bindings, and can also
detect when it is in the unfortunate situation of being behind a detect when it is in the unfortunate situation of being behind a
'Symmetric' NAT, although it simply cannot function in this case. 'Symmetric' NAT, although it simply cannot function in this case.
These clients will only work in deployment situations where the These clients will only work in deployment situations where the
access is sufficiently controlled to know definitively that there access is sufficiently controlled to know definitively that there
won't be Symmetric NAT. This is hard to guarantee as users can won't be Symmetric NAT. This is hard to guarantee as users can
always pick up their client and connect via a different access always pick up their client and connect via a different access
network. network.
3.2.6.3. Minimal Profile 3.2.5.3. Minimal Profile
A client falling into the 'Minimal' profile will send/receive RTP A client falling into the 'Minimal' profile will send/receive RTP
form the same IP/port combination. This client requires proprietary form the same IP/port combination. This client requires proprietary
network based solutions to function in any NAT traversal scenario. network based solutions to function in any NAT traversal scenario.
All clients SHOULD support the 'Primary Profile', MUST support the All clients SHOULD support the 'Primary Profile', MUST support the
'Minimal Profile' and MAY support the 'Consumer Profile'. 'Minimal Profile' and MAY support the 'Consumer Profile'.
4. NAT Traversal Scenarios 4. 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.
4.1. Basic NAT SIP Signaling Traversal 4.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
NAT. The scenarios include traversal for both reliable and un- NAT. The scenarios include traversal for both reliable and un-
reliable transport protocols. reliable transport protocols.
[Editors Note: The scenarios are still in early construction and a
couple have been included as a hint of direction - All comments
welcome for next release]
4.1.1. Registration (Registrar/Proxy Co-Located) 4.1.1. Registration (Registrar/Proxy Co-Located)
The set of scenarios in this section document basic signaling The set of scenarios in this section document basic signaling
traversal of a SIP REGISTER method through a NAT. traversal of a SIP REGISTER method through a NAT.
4.1.1.1. UDP 4.1.1.1. UDP
Client NAT Proxy Client NAT Proxy
| | | | | |
|(1) REGISTER | | |(1) REGISTER | |
|----------------->| | |----------------->| |
| | |
| |(1) REGISTER | | |(1) REGISTER |
| |----------------->| | |----------------->|
| | |
| |(2) 401 Unauth | | |(2) 401 Unauth |
| |<-----------------| | |<-----------------|
| | |
|(2) 401 Unauth | | |(2) 401 Unauth | |
|<-----------------| | |<-----------------| |
| | |
|(3) REGISTER | | |(3) REGISTER | |
|----------------->| | |----------------->| |
| | |
| |(3) REGISTER | | |(3) REGISTER |
| |----------------->| | |----------------->|
| | |
|*************************************| |*************************************|
| Create Connection Re-use Tuple | | Create Connection Re-use Tuple |
|*************************************| |*************************************|
| | |
| |(4) 200 OK | | |(4) 200 OK |
| |<-----------------| | |<-----------------|
| | |
|(4) 200 OK | | |(4) 200 OK | |
|<-----------------| | |<-----------------| |
| | | | | |
Figure 5.
Figure 5 Figure 5
In this example the client sends a SIP REGISTER request through a NAT In this example the client sends a SIP REGISTER request through a NAT
which is challenged using the Digest authentication scheme. The which is challenged using the Digest authentication scheme. The
client will include an 'rport' parameter as described in section client will include an 'rport' parameter as described in section
3.1.1 of this document for allowing traversal of UDP responses. The 3.1.1 of this document for allowing traversal of UDP responses. The
original request as illustrated in (1) in Figure 5 is a standard original request as illustrated in (1) in Figure 5 is a standard
REGISTER message: REGISTER message:
REGISTER sip:proxy.example.com SIP/2.0 REGISTER sip:proxy.example.com SIP/2.0
Via: SIP/2.0/UDP client.example.com:5060;rport;branch=z9hG4bK Via: SIP/2.0/UDP client.example.com:5060;rport;branch=z9hG4bK
Max-Forwards: 70 Max-Forwards: 70
Supported: gruu Supported: path,gruu
From: Client <sip:client@example.com>;tag=djks8732 From: Client <sip:client@example.com>;tag=djks8732
To: Client <sip:client@example.com> To: Client <sip:client@example.com>
Call-ID: 763hdc73y7dkb37@example.com Call-ID: 763hdc73y7dkb37@example.com
CSeq: 1 REGISTER CSeq: 1 REGISTER
Contact: <sip:client@client.example.com>; connectioId=1 Contact: <sip:client@client.example.com>;reg-id=1
;+sip.instance="<urn:uuid:00000000-0000-0000-0000-00A95A0E120>" ;+sip.instance="<urn:uuid:00000000-0000-0000-0000-00A95A0E120>"
Content-Length: 0 Content-Length: 0
This proxy now generates a SIP 401 response to challenge for This proxy now generates a SIP 401 response to challenge for
authentication, as depicted in (2) from Figure 5: authentication, as depicted in (2) from Figure 5:
SIP/2.0 401 Unauthorized SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP client.example.com:5060 Via: SIP/2.0/UDP client.example.com:5060
;rport=8050;branch=z9hG4bK;received=192.0.1.2 ;rport=8050;branch=z9hG4bK;received=192.0.1.2
From: Client <sip:client@example.com>;tag=djks8732 From: Client <sip:client@example.com>;tag=djks8732
skipping to change at page 13, line 24 skipping to change at page 13, line 39
The response will be sent to the address appearing in the 'received' The response will be sent to the address appearing in the 'received'
parameter of the SIP 'Via' header (address 192.0.1.2). The response parameter of the SIP 'Via' header (address 192.0.1.2). The response
will not be sent to the port deduced from the SIP 'Via' header, as 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 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 been stamped in the 'rport' parameter of the SIP 'Via' header (port
8050). For the response to successfully traverse the NAT, all of the 8050). For the response to successfully traverse the NAT, all of the
conventions defined in RFC 3581 [6] MUST be obeyed. Make note of the conventions defined in RFC 3581 [6] MUST be obeyed. Make note of the
both the 'connectionID' and 'sip.instance' contact header parameters. both the 'connectionID' and 'sip.instance' contact header parameters.
They are used to establish a connection re-use tuple as defined in They are used to establish a connection re-use tuple as defined in
[11]. The connection tuple creation is clearly shown in Figure 5. [13]. The connection tuple creation is clearly shown in Figure 5.
This ensures that any inbound request that causes a registration This ensures that any inbound request that causes a registration
lookup will result in the re-use of the connection path established lookup will result in the re-use of the connection path established
by the registration. This exonerates the need to manipulate contact by the registration. This exonerates the need to manipulate contact
header URI's to represent a globally routable address as perceived on header URI's to represent a globally routable address as perceived on
the public side of a NAT. The subsequent messages defined in (3) and the public side of a NAT. The subsequent messages defined in (3) and
(4) from Figure 5 use the same mechanics for NAT traversal. (4) from Figure 5 use the same mechanics for NAT traversal.
[Editors note: Will provide more details on heartbeat mechanism in [Editors note: Will provide more details on heartbeat mechanism in
next revision] next revision]
skipping to change at page 14, line 4 skipping to change at page 14, line 6
the public side of a NAT. The subsequent messages defined in (3) and the public side of a NAT. The subsequent messages defined in (3) and
(4) from Figure 5 use the same mechanics for NAT traversal. (4) from Figure 5 use the same mechanics for NAT traversal.
[Editors note: Will provide more details on heartbeat mechanism in [Editors note: Will provide more details on heartbeat mechanism in
next revision] next revision]
[Editors note: Can complete full flows if required on heartbeat [Editors note: Can complete full flows if required on heartbeat
inclusion] inclusion]
4.1.1.2. Reliable Transport 4.1.1.2. Reliable Transport
Client NAT Registrar Client NAT Registrar
| | | | | |
|(1) REGISTER | | |(1) REGISTER | |
|----------------->| | |----------------->| |
| | |
| |(1) REGISTER | | |(1) REGISTER |
| |----------------->| | |----------------->|
| | |
| |(2) 401 Unauth | | |(2) 401 Unauth |
| |<-----------------| | |<-----------------|
| | |
|(2) 401 Unauth | | |(2) 401 Unauth | |
|<-----------------| | |<-----------------| |
| | |
|(3) REGISTER | | |(3) REGISTER | |
|----------------->| | |----------------->| |
| | |
| |(3) REGISTER | | |(3) REGISTER |
| |----------------->| | |----------------->|
| | |
|*************************************| |*************************************|
| Create Connection Re-use Tuple | | Create Connection Re-use Tuple |
|*************************************| |*************************************|
| | |
| |(4) 200 OK | | |(4) 200 OK |
| |<-----------------| | |<-----------------|
| | |
|(4) 200 OK | | |(4) 200 OK | |
|<-----------------| | |<-----------------| |
| | | | | |
Figure 6. Figure 6.
Traversal of SIP REGISTER requests/responses using a reliable, Traversal of SIP REGISTER requests/responses using a reliable,
connection orientated protocol such as TCP does not require any connection orientated protocol such as TCP does not require any
additional core SIP signaling extensions. SIP responses will re-use additional core SIP signaling extensions. SIP responses will re-use
the connection created for the initial REGISTER request, (1) from the connection created for the initial REGISTER request, (1) from
Figure 6: Figure 6:
REGISTER sip:proxy.example.com SIP/2.0 REGISTER sip:proxy.example.com SIP/2.0
Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKyilassjdshfu Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKyilassjdshfu
Max-Forwards: 70 Max-Forwards: 70
Supported: gruu Supported: path,gruu
From: Client <sip:client@example.com>;tag=djks809834 From: Client <sip:client@example.com>;tag=djks809834
To: Client <sip:client@example.com> To: Client <sip:client@example.com>
Call-ID: 763hdc783hcnam73@example.com Call-ID: 763hdc783hcnam73@example.com
CSeq: 1 REGISTER CSeq: 1 REGISTER
Contact: <sip:client@client.example.com;transport=tcp>;connectioId=1 Contact: <sip:client@client.example.com;transport=tcp>;reg-id=1
;+sip.instance="<urn:uuid:00000000-0000-0000-0000-00A95A0E121>" ;+sip.instance="<urn:uuid:00000000-0000-0000-0000-00A95A0E121>"
Content-Length: 0 Content-Length: 0
This example was included to show the inclusion of the connection re- This example was included to show the inclusion of the connection re-
use Contact header parameters as defined in the Connection Re-use use Contact header parameters as defined in the Connection Re-use
draft [11]. This creates an association tuple as described in the draft [13]. This creates an association tuple as described in the
previous example for future inbound requests directed at the newly previous example for future inbound requests directed at the newly
created registration binding with the only difference that the created registration binding with the only difference that the
association is with a TCP connection, not a UDP pin hole binding. association is with a TCP connection, not a UDP pin hole binding.
[Editors note: Will provide more details on heartbeat mechanism in [Editors note: Will provide more details on heartbeat mechanism in
next revision] next revision]
[Editors note: Can complete full flows on inclusion of heartbeat [Editors note: Can complete full flows on inclusion of heartbeat
mechanism] mechanism]
skipping to change at page 15, line 25 skipping to change at page 16, line 9
This section demonstrates traversal mechanisms when the Registrar This section demonstrates traversal mechanisms when the Registrar
component is not co-located with the edge proxy element. The component is not co-located with the edge proxy element. The
procedures described in this section are identical, regardless of procedures described in this section are identical, regardless of
transport protocol and so only one example will be documented in the transport protocol and so only one example will be documented in the
form of TCP. form of TCP.
Client NAT Proxy Registrar Client NAT Proxy Registrar
| | | | | | | |
|(1) REGISTER | | | |(1) REGISTER | | |
|----------------->| | | |----------------->| | |
| | | |
| |(1) REGISTER | | | |(1) REGISTER | |
| |----------------->| | | |----------------->| |
| | | |
| | |(2) REGISTER | | | |(2) REGISTER |
| | |----------------->| | | |----------------->|
| | | |
| | |(3) 401 Unauth | | | |(3) 401 Unauth |
| | |<-----------------| | | |<-----------------|
| | | |
| |(4) 401 Unauth | | | |(4) 401 Unauth | |
| |<-----------------| | | |<-----------------| |
| | | |
|(4)401 Unauth | | | |(4)401 Unauth | | |
|<-----------------| | | |<-----------------| | |
| | | |
|(5)REGISTER | | | |(5)REGISTER | | |
|----------------->| | | |----------------->| | |
| | | |
| |(5)REGISTER | | | |(5)REGISTER | |
| |----------------->| | | |----------------->| |
| | | |
| | |(6)REGISTER | | | |(6)REGISTER |
| | |----------------->| | | |----------------->|
| | | |
| | |(7)200 OK | | | |(7)200 OK |
| | |<-----------------| | | |<-----------------|
| | | |
|********************************************************| |********************************************************|
| Create Connection Re-use Tuple | | Create Connection Re-use Tuple |
|********************************************************| |********************************************************|
| | | |
| |(8)200 OK | | | |(8)200 OK | |
| |<-----------------| | | |<-----------------| |
| | | |
|(8)200 OK | | | |(8)200 OK | | |
|<-----------------| | | |<-----------------| | |
| | | | | | | |
Figure 7. Figure 7.
This scenario builds on that contained in section 4.1.1.2. This time This scenario builds on the previous example contained in
the REGISTER request is routed onwards to a separated Registrar. The Section 4.1.1.2. The primary difference being that the REGISTER
important message to note is (6) in Figure 7. At this point, the request is routed onwards from a Proxy Server to a separated
proxy server routes the SIP REGISTER message to the Registrar. The Registrar. The important message to note is (6) in Figure 7. The
proxy will create the connection re-use tuple at the same moment as Edge proxy, on receiving a REGISTER request that contains a
the co-located example but for subsequent messages to arrive at the 'sip.instance' media feature tag, forms a unique flow identifier
Proxy, the element needs to request to stay in the signaling path. token as discussed in [13] . At this point, the proxy server routes
The REGISTER message (5) contains a SIP PATH extension header, as the SIP REGISTER message to the Registrar. The proxy will create the
defined in RFC 3327 [7]. REGISTER message (5) would look as follows: 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 element needs to request to remain in the signaling path.
To achieve this the proxy inserts to REGISTER message (5) a SIP PATH
extension header, as defined in RFC 3327 [7]. The previously created
flow 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. REGISTER message (5) would
look as follows:
REGISTER sip:registrar.example.com SIP/2.0 REGISTER sip:registrar.example.com SIP/2.0
Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4njkca8398hadjaa Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4njkca8398hadjaa
Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKyilassjdshfu Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKyilassjdshfu
Max-Forwards: 70 Max-Forwards: 70
Supported: gruu Supported: path,gruu
From: Client <sip:client@example.com>;tag=djks809834 From: Client <sip:client@example.com>;tag=djks809834
To: Client <sip:client@example.com> To: Client <sip:client@example.com>
Call-ID: 763hdc783hcnam73@example.com Call-ID: 763hdc783hcnam73@example.com
CSeq: 1 REGISTER CSeq: 1 REGISTER
Path: <sip:sip%3Aclient%40example.com@proxy.example.com;lr> Path: <sip:3HS28o8HAKJSH&&U@proxy.example.com;lr>
Contact: <sip:client@client.example.com;transport=tcp>;connectioId=1 Contact: <sip:client@client.example.com;transport=tcp>;
;+sip.instance="<urn:uuid:00000000-0000-0000-0000-00A95A0E121>" ;+sip.instance="<urn:uuid:00000000-0000-0000-0000-00A95A0E121>";reg-id=1
Content-Length: 0 Content-Length: 0
This results in the Path header being stored along with the AOR and This REGISTER request results in the Path header being stored along
it's associated binding at the Registrar. The URI contained in the with the AOR and it's associated binding at the Registrar. The URI
Path header will be inserted as a pre-loaded SIP 'Route' header into contained in the Path header will be inserted as a pre-loaded SIP
any request that arrives at the Registrar and is directed towards the 'Route' header into any request that arrives at the Registrar and is
associated binding. This guarantees that all requests for the new directed towards the associated binding. This guarantees that all
Registration will be forwarded to the edge proxy. The user part of requests for the new Registration will be forwarded to the Edge
the SIP 'Path' header URI that was inserted by the edge proxy Proxy. In our example, the user part of the SIP 'Path' header URI
contains an escaped form of the original AOR that was contained in that was inserted by the Edge Proxy contains the unique token
the REGISTER request. On receiving subsequent requests, the edge identifying the flow to the client. On receiving subsequent
proxy will examine the user part of the pre-loaded SIP 'route' header requests, the edge proxy will examine the user part of the pre-loaded
and extract the original AOR for use in its connection tuple SIP 'route' header and extract the unique flow token for use in its
comparison, as defined in the connection re-use draft [11]. An connection tuple comparison, as defined in the SIP Outbound
example which builds on this scenario (showing an inbound request to specification [13]. An example which builds on this scenario
the AOR) is detailed in section 4.1.4.2 of this document. (showing an inbound request to the AOR) is detailed in section
4.1.4.2 of this document.
4.1.3. Initiating a Session 4.1.3. Initiating a Session
This section covers basic SIP signaling when initiating a call from This section covers basic SIP signaling when initiating a call from
behind a NAT. behind a NAT.
4.1.3.1. UDP 4.1.3.1. UDP
Initiating a call using UDP. Initiating a call using UDP.
Client NAT Proxy [..] Client NAT Proxy [..]
| | | | | |
|(1) INVITE | | | |(1) INVITE | | |
|----------------->| | | |----------------->| | |
| | | |
| |(1) INVITE | | | |(1) INVITE | |
| |----------------->| | | |----------------->| |
| | | |
| |(2) 407 Unauth | | | |(2) 407 Unauth | |
| |<-----------------| | | |<-----------------| |
| | | |
|(2) 407 Unauth | | | |(2) 407 Unauth | | |
|<-----------------| | | |<-----------------| | |
| | | |
|(3) INVITE | | | |(3) INVITE | | |
|----------------->| | |
| | | |
| |(3) INVITE | | | |(3) INVITE | |
| |----------------->| | | |----------------->| |
| | | |
| | |(4) INVITE | | | |(4) INVITE |
| | |---------------->| | | |---------------->|
| | | |
| | |(5)180 RINGING | | | |(5)180 RINGING |
| | |<----------------| | | |<----------------|
| | | |
| |(6)180 RINGING | | | |(6)180 RINGING | |
| |<-----------------| | | |<-----------------| |
| | | |
|(6)180 RINGING | | | |(6)180 RINGING | | |
|<-----------------| | | |<-----------------| | |
| | | |
| | |(7)200 OK | | | |(7)200 OK |
| | |<----------------| | | |<----------------|
| | | |
| |(8)200 OK | | | |(8)200 OK | |
| |<-----------------| | | |<-----------------| |
| | | |
|(8)200 OK | | | |(8)200 OK | | |
|<-----------------| | | |<-----------------| | |
| | | |
|(9)ACK | | | |(9)ACK | | |
|----------------->| | | |----------------->| | |
| | | |
| |(9)ACK | | | |(9)ACK | |
| |----------------->| | | |----------------->| |
| | | |
| | |(10) ACK | | | |(10) ACK |
| | |---------------->| | | |---------------->|
| | |(11) | | | | |
Figure 8. Figure 8.
The initiating client generates an INVITE request that is to be sent The initiating client generates an INVITE request that is to be sent
through the NAT to a Proxy server. The INVITE message is represented through the NAT to a Proxy server. The INVITE message is represented
in Figure 8 by (1) and is as follows: in Figure 8 by (1) and is as follows:
INVITE sip:clientB@example.com SIP/2.0 INVITE sip:clientB@example.com SIP/2.0
Via: SIP/2.0/UDP client.example.com:5060;rport;branch=z9hG4bK74husdHG Via: SIP/2.0/UDP client.example.com:5060;rport;branch=z9hG4bK74husdHG
Max-Forwards: 70 Max-Forwards: 70
Route: <sip:proxy.example.com;lr> Route: <sip:proxy.example.com;lr>
From: clientA <sip:clientA@example.com>;tag=7skjdf38l From: clientA <sip:clientA@example.com>;tag=7skjdf38l
To: clientB <sip:clientB@example.com> To: clientB <sip:clientB@example.com>
Call-ID: 8327468763423@example.com Call-ID: 8327468763423@example.com
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: <sip:im_a_gruu@proxy.example.com> Contact:<sip:clientA@example.com;gruu
;opaque=urn:uuid:ijed7ush-4jan-53120-aee5-e0aecwee6wef;grid=45a>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: .. Content-Length: ..
[SDP not shown] [SDP not shown]
There are a number of points to note with this message: There are a number of points to note with this message:
1. Firstly, as with the registration example in section 4.1.1.1, 1. Firstly, as with the registration example in Section 4.1.1.1,
reponses to this request will not automatically pass back through responses to this request will not automatically pass back
a NAT and so the SIP 'Via' header 'rport' is included as through a NAT and so the SIP 'Via' header 'rport' is included as
described in the 'Symmetric response' section(3.1.1) and defined described in the 'Symmetric response' Section 3.1.1 and defined
in RFC 3581 [6]. in RFC 3581 [6].
2. Secondly, the contact inserted contains the GRUU previously 2. Secondly, the contact inserted contains the GRUU previously
obtained from the registration. obtained from the SIP 200 OK response to the registration. Use
3. [Editors Note: TODO - Expand description of GRUU and connection of the GRUU ensures that any SIP requests within the dialog that
re-use] in the opposite direction will be able to traverse the NAT. This
occurs using the mechanisms defined in the SIP Outbound
specification[13]. A request arriving at the entity which
resolves to the GRUU is then able to determine a previously
registered connection that will allow the request to traverse the
NAT and reach the intended endpoint.
4.1.3.2. Reliable Transport 4.1.3.2. Reliable Transport
[Editors note: TODO] 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 4.1.3.1. The primary difference when using
reliable transport protocols is that Symmetric response[6] are not
required for SIP responses to traverse a NAT. RFC 3261[1] defines
procedures for SIP response messages to be sent back on the same
connection on which the request arrived.
4.1.4. Receiving an Invitation to a Session 4.1.4. Receiving an Invitation to a Session
This section details scenarios where a client behind a NAT receives This section details scenarios where a client behind a NAT receives
an inbound request through the NAT. These scenarios build on the an inbound request through a NAT. These scenarios build on the
previous registration scenario from sections 4.1.1 and 4.1.2 in this previous registration scenario from Section 4.1.1 and Section 4.1.2
document. in this document.
4.1.4.1. Registrar/Proxy Co-located 4.1.4.1. Registrar/Proxy Co-located
The core SIP signaling associated with this call flow is not impacted The core SIP signaling associated with this call flow is not impacted
directly by the transport protocol and so only one example scenario directly by the transport protocol and so only one example scenario
is necessary. The example uses UDP and follows on from the is necessary. The example uses UDP and follows on from the
registration installed in the example from section 4.1.1.1. registration installed in the example from Section 4.1.1.1.
Client NAT Registrar/Proxy SIP Entity Client NAT Registrar/Proxy SIP Entity
| | | | | | | |
|*******************************************************| |*******************************************************|
| Registration Binding Installed in | | Registration Binding Installed in |
| section 4.1.1.1 | | section 4.1.1.1 |
|*******************************************************| |*******************************************************|
| | | | | | | |
| | |(1)INVITE | | | |(1)INVITE |
| | |<----------------| | | |<----------------|
| | | |
| |(2)INVITE | | | |(2)INVITE | |
| |<-----------------| | | |<-----------------| |
| | | |
|(2)INVITE | | | |(2)INVITE | | |
|<-----------------| | | |<-----------------| | |
| | | | | | | |
| | | | | | | |
Figure 9. Figure 9.
The core SIP signaling associated with this call flow is not impacted An INVITE request arrives at the Registrar with a destination
directly by the transport protocol and so only one example scenario pointing to the AOR of that inserted in section 4.1.1.1. The message
is necessary. The example uses UDP and follows on from the is illustrated by (1) in Figure 9 and looks as follows:
registration installed in section 4.1.1.1. An INVITE request arrives
at the Registrar with a destination pointing to the AOR of that
inserted in section 4.1.1.1. The message is illustrated by (1) in
Figure 9 and looks as follows:
INVITE sip:client@example.com SIP/2.0 INVITE sip:client@example.com SIP/2.0
Via: SIP/2.0/UDP external.example.com;branch=z9hG4bK74huHJ37d Via: SIP/2.0/UDP external.example.com;branch=z9hG4bK74huHJ37d
Max-Forwards: 70 Max-Forwards: 70
From: External <sip:External@external.example.com>;tag=7893hd From: External <sip:External@external.example.com>;tag=7893hd
To: client <sip:client@example.com> To: client <sip:client@example.com>
Call-ID: 8793478934897@external.example.com Call-ID: 8793478934897@external.example.com
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: <sip:external@192.0.1.4> Contact: <sip:external@192.0.1.4>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: .. Content-Length: ..
[SDP not shown] [SDP not shown]
The INVITE matches the registration binding at the Registrar and the The INVITE request matches the registration binding previously
INVITE request-URI is re-written to the selected onward address. The installed at the Registrar and the INVITE request-URI is re-written
proxy then examines the request URI of the INVITE and compares with to the selected onward address. The proxy then examines the request
its list of current open connections/mappings. It uses the incoming URI of the INVITE and compares with its list of current open flows.
AOR to commence the check for associated open connections/mappings. It uses the incoming AOR to commence the check for associated open
Once matched, the proxy checks to see if the unique instance connections/mappings. Once matched, the proxy checks to see if the
identifier (+sip.instance) associated with the binding equals the unique instance identifier (+sip.instance) associated with the
same instance identifier associated with the binding. If more than binding equals the same instance identifier associated with the flow.
one result is matched, the lowest 'connectionID' Contact parameter The request is then dispatched on the appropriate flow. This is
will be used. This is message (2) from Figure 9 and is as follows: message (2) from Figure 9 and is as follows:
INVITE sip:sip:client@client.example.com SIP/2.0 INVITE sip:sip:client@client.example.com SIP/2.0
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4kmlds893jhsd Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4kmlds893jhsd
Via: SIP/2.0/UDP external.example.com;branch=z9hG4bK74huHJ37d Via: SIP/2.0/UDP external.example.com;branch=z9hG4bK74huHJ37d
Max-Forwards: 70 Max-Forwards: 70
From: External <sip:External@external.example.com>;tag=7893hd From: External <sip:External@external.example.com>;tag=7893hd
To: client <sip:client@example.com> To: client <sip:client@example.com>
Call-ID: 8793478934897@external.example.com Call-ID: 8793478934897@external.example.com
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: <sip:external@192.0.1.4> Contact: <sip:external@192.0.1.4>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: .. Content-Length: ..
[SDP not shown] [SDP not shown]
It is a standard SIP INVITE request with no additional functionality. It is a standard SIP INVITE request with no additional functionality.
The major difference being that this request will not follow the The major difference being that this request will not follow the
address specified in the Request-URI, as standard SIP rules would address specified in the Request-URI, as standard SIP rules would
enforce but will be sent on the connection/mapping associated with enforce but will be sent on the flow associated with the registration
the registration binding. This then allows the original connection/ binding (look-up procedures in RFC 3263 [6] are overridden). This
mapping from the initial registration process to be re-used. then allows the original connection/mapping from the initial
registration process to be re-used.
4.1.4.2. Registrar/Proxy Not Co-located 4.1.4.2. Registrar/Proxy Not Co-located
Client NAT Proxy Registrar SIP Entity Client NAT Proxy Registrar SIP Entity
| | | | | | | | | |
|***********************************************************| |***********************************************************|
| Registration Binding Installed in | | Registration Binding Installed in |
| section 4.1.2 | | section 4.1.2 |
|***********************************************************| |***********************************************************|
| | | | |
| | | |(1)INVITE | | | | |(1)INVITE |
| | | |<-------------| | | | |<-------------|
| | | | |
| | |(2)INVITE | | | | |(2)INVITE | |
| | |<-------------| | | | |<-------------| |
| | | | |
| |(3)INVITE | | | | |(3)INVITE | | |
| |<-------------| | | | |<-------------| | |
| | | | |
|(3)INVITE | | | | |(3)INVITE | | | |
|<-------------| | | | |<-------------| | | |
| | | | | | | | | |
| | | | | | | | | |
Figure 9. Figure 9.
4.2. Basic NAT Media Traversal 4.2. Basic NAT Media Traversal
This section provides example scenarios to demonstrate basic media This section provides example scenarios to demonstrate basic media
traversal using the techniques outlined earlier in this document. traversal using the techniques outlined earlier in this document.
4.2.1. Port Restricted Cone NAT 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 reflexive transport address.
o The "Rel" attribute represents the relayed transport address.
The meaning of each STUN attribute is extensively explained in the
core STUN[10] and TURN usage[12] drafts.
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 make them hard to follow.
For this reason network addresses will be represented using the
following annotation. The first component will contain the a
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 on the left hand side
NAT while "R-NAT-PUB-1" would represent a public network address in
the right hand side of the NAT. "L-PRIV-1" would represent a private
network address on the left hand side of the NAT while "R-PRIV-1"
represents a private address on the right hand side of the NAT.
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'.
4.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 a 'Restricted Cone' NAT. The examples have receiving calls behind an 'Endpoint independent' NAT. An example is
been included to represent both 'Restricted' and 'Port Restricted' included for both STUN and ICE with ICE being the RECOMMENDED
NAT media traversal. An example is included for both STUN and ICE mechanism for media traversal.
with ICE being the RECOMENDED method.
4.2.1.1. STUN Solution 4.2.1.1. STUN Solution
It is possible to traverse media through a 'Restricted Cone NAT' It is possible to traverse media through an 'Endpoint Independent NAT
using STUN. using STUN. The remainder of this section provides a simplified
examples of the 'Binding Discovery' STUN usage as defined in [10].
The STUN messages have been simplified and do not include 'Shared
Secret' requests used to obtain the temporary username and password.
[Editors Note: Expand to show full flow in including Auth?.]
4.2.1.1.1. Initiating Session 4.2.1.1.1. Initiating Session
The following example demonstrates media traversal through a The following example demonstrates media traversal through a NAT
'Restricted Cone' NAT using STUN. It is assumed in this example that demonstrating 'Address Independent' NAT behavior using STUN. It is
the STUN client and SIP Client are co-located on the same machine. assumed in this example that the STUN client and SIP Client are co-
Note that some SIP signalling messages have been left out for located on the same machine. Note that some SIP signalling messages
simplicity. have been left out for simplicity.
Client NAT STUN [..] Client NAT STUN [..]
Server Server
| | | | | | | |
|(1) STUN Req | | | |(1) STUN Req | | |
|src=10.0.1.1:5301 | | | |Src=L-PRIV-1 | | |
|Dest=STUN-PUB | | |
|----------------->| | | |----------------->| | |
| | | |
| |(2) STUN Req | | | |(2) STUN Req | |
| |src=1.2.3.4:5601 | | | |Src=NAT-PUB-1 | |
| |Dest=STUN-PUB | |
| |----------------->| | | |----------------->| |
| | | |
| |(3) STUN Resp | | | |(3) STUN Resp | |
| |<-----------------| | | |<-----------------| |
| |map=1.2.3.4:5601 | | | |Src=STUN-PUB | |
| |dest=1.2.3.4:5601 | | | |Dest=NAT-PUB-1 | |
| |Map=NAT-PUB-1 | |
| | | |
|(4) STUN Resp | | | |(4) STUN Resp | | |
|<-----------------| | | |<-----------------| | |
|map=1.2.3.4:5601 | | | |Src=STUN-PUB | | |
|dest=10.0.1.1:5301| | | |Dest=L-PRIV-1 | | |
|Map=NAT-PUB-1 | | |
| | | |
|(5) STUN Req | | | |(5) STUN Req | | |
|src=10.0.1.1:5302 | | | |Src=L-PRIV-2 | | |
|Dest=STUN-PUB | | |
|----------------->| | | |----------------->| | |
| | | |
| |(6) STUN Req | | | |(6) STUN Req | |
| |src=1.2.3.4:5608 | | | |Src=NAT-PUB-2 | |
| |Dest=STUN-PUB | |
| |----------------->| | | |----------------->| |
| | | |
| |(7) STUN Resp | | | |(7) STUN Resp | |
| |<-----------------| | | |<-----------------| |
| |map=1.2.3.4:5608 | | | |Src=STUN-PUB | |
| |dest=1.2.3.4:5608 | | | |Dest=NAT-PUB-2 | |
| |Map=NAT-PUB-2 | |
| | | |
|(8) STUN Resp | | | |(8) STUN Resp | | |
|<-----------------| | | |<-----------------| | |
|map=1.2.3.4:5608 | | | |Src=STUN-PUB | | |
|dest=10.0.1.1:5302| | | |Dest=L-PRIV-2 | | |
|Map=NAT-PUB-2 | | |
| | | |
|(9)SIP INVITE | | | |(9)SIP INVITE | | |
|----------------->| | | |----------------->| | |
| | | |
| |(10)SIP INVITE | | | |(10)SIP INVITE | |
| |------------------------------------>| | |------------------------------------>|
| | | |
| | |(11)SIP 200 OK | | | |(11)SIP 200 OK |
| |<------------------------------------| | |<------------------------------------|
| | | |
|(12)SIP 200 OK | | | |(12)SIP 200 OK | | |
|<-----------------| | | |<-----------------| | |
| | | |
|========================================================| |========================================================|
|>>>>>>>>>>>Outgoing Media sent to 1.2.3.4:5601>>>>>>>>>>| |>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>>>|
|========================================================| |========================================================|
| |
|========================================================| |========================================================|
|<<<<<<<<<<<Incoming Media sent to 1.2.3.4:5601<<<<<<<<<<| |<<<<<<<<<<<<Incoming Media sent to NAT-PUB-1<<<<<<<<<<<<|
|========================================================|
| |
|========================================================| |========================================================|
|>>>>>>>>>>>>Outgoing RTCP sent from L-PRIV-2>>>>>>>>>>>>|
|========================================================|
| |
|========================================================|
|<<<<<<<<<<<<Incoming RTCP sent to NAT-PUB-2<<<<<<<<<<<<<|
|========================================================|
| | | |
|(13)SIP ACK | | | |(13)SIP ACK | | |
|----------------->| | | |----------------->| | |
| | | |
| |(14) SIP ACK | | | |(14) SIP ACK | |
| |------------------------------------>| | |------------------------------------>|
| | | | | | | |
Figure 18: Restricted NAT with STUN - Initiating Figure 18: Address and Port Dependant NAT with STUN - Initiating
o On deciding to initiate a SIP voice session the VOIP client starts o On deciding to initiate a SIP voice session the client starts a
a local STUN client. The STUN client generates a standard STUN local STUN client on the interface and port that is to be used for
media (send/receive). The STUN client generates a standard STUN
request as indicated in (1) from Figure 18 which also highlights request as indicated in (1) from Figure 18 which also highlights
the source address and port for which the client device wishes to the source address and port for which the client device wishes to
obtain a mapping. The STUN request is sent through the NAT obtain a mapping. The STUN request is sent through the NAT
towards the public internet. towards the public internet and STUN server.
o STUN message (2) traverses the NAT and breaks out onto the public o STUN message (2) traverses the NAT and breaks out onto the public
internet towards the public STUN server. Note that the source internet towards the public STUN server. Note that the source
address of the STUN requests now represents the public address and address of the STUN requests now represents the public address and
port from the public side of the NAT. port from the public side of the NAT.
o
o The STUN server receives the request and processes it o The STUN server receives the request and processes it
appropriately. This results in a successful STUN response being appropriately. This results in a successful STUN response being
generated and returned (3). The message contains details of the generated and returned (3). The message contains details of the
mapped public address (contained in the STUN MAPPED-ADDRESS mapped public address (contained in the STUN MAPPED-ADDRESS
attribute) which is to be used by the originating client to attribute) which is to be used by the originating client to
receive media (see 'map=' from (3)). receive media (see 'Map=NAT-PUB-1' from (3)).
o The STUN response traverses back through the NAT using the binding o The STUN response traverses back through the NAT using the binding
created by the STUN request and presents the new mapped address to created by the STUN request and presents the new mapped address to
the client (4). At this point the process is repeated to obtain a the client (4). At this point the process is repeated to obtain a
second mapped address (as shown in (5)-(8)) for an alternative second mapped address (as shown in (5)-(8)) for an alternative
local address (local port has now changed from 5301 to 5302 in local address (Address has changed from "L-PRIV-1" to "L-PRIV-2").
(5)).
o The client now constructs a SIP INVITE message(9). Note that o The client now constructs a SIP INVITE message(9). Note that
traversal of SIP is not covered in this example and is discussed traversal of SIP is not covered in this example and is discussed
in earlier sections of the document. The INVITE request will use in earlier sections of the document. The INVITE request will use
the addresses it has obtained in the previous STUN transactions to the addresses it has obtained in the previous STUN transactions to
populate the SDP of the SIP INVITE as shown below: populate the SDP of the SIP INVITE as shown below:
v=0 v=0
o=test 2890844526 2890842807 IN IP4 10.0.1.1 o=test 2890844526 2890842807 IN IP4 $L-PRIV-1.address
c=IN IP4 1.2.3.4 c=IN IP4 $NAT-PUB-1.address
t=0 0 t=0 0
m=audio 5601 RTP/AVP 0 m=audio $NAT-PUB-1.port RTP/AVP 0
a=rtcp:5608 a=rtcp:$NAT-PUB-2.port
o Note that the mapped address obtained from the STUN transactions o Note that the mapped address obtained from the STUN transactions
are inserted as the connection address for the SDP (c=1.2.3.4). are inserted as the connection address for the SDP (c=NAT-PUB-
The Primary port for RTP is also inserted in the SDP (m=audio 5601 1.address). The Primary port for RTP is also inserted in the SDP
RTP/AVP 0). Finally, the port gained from the additional STUN (m=audio NAT-PUB-1.port RTP/AVP 0). Finally, the port gained from
binding is placed in the RTCP attribute (as discussed in the additional STUN binding is placed in the RTCP attribute (as
Section 3.2.5) for traversal of RTCP (a=rtcp:5608). discussed in Section 3.2.1.1) for traversal of RTCP (a=rtcp:NAT-
PUB-2.port).
o The SIP signalling then traverses the NAT and sets up the SIP o The SIP signalling then traverses the NAT and sets up the SIP
session (10-12). Note that the client transmits media as soon as session (10-12). Note that the client transmits media as soon as
the 200 OK to the INVITE arrives at the client (12). Up until the 200 OK to the INVITE arrives at the client (12). Up until
this point the incoming media will not pass through the NAT as no this point the incoming media and RTCP will not pass through the
outbound association has been created with the far end client. NAT as no outbound association has been created with the far end
Two way media communication has now been established. client. Two way media communication has now been established.
4.2.1.1.2. Receiving Session Invitation 4.2.1.1.2. Receiving Session Invitation
Receiving a session for a 'Restricted Cone' NAT using STUN is very Receiving a session for an 'Address and Port dependant' NAT using
similar to the example outlined in Section 4.2.1.1.1. Figure 20 STUN is very similar to the example outlined in Section 4.2.1.1.1.
illustrates the associated flow of messages. Figure 20 illustrates the associated flow of messages.
Client NAT STUN [..] Client NAT STUN [..]
Server Server
| | | (1)SIP INVITE | | | | (1)SIP INVITE |
| |<-----------------|------------------| | |<-----------------|------------------|
| | | |
|(2) SIP INVITE | | | |(2) SIP INVITE | | |
|<-----------------| | | |<-----------------| | |
| | | | | | | |
|(3) STUN Req | | | |(3) STUN Req | | |
|src=10.0.1.1:5301 | | | |Src=L-PRIV-1 | | |
|Dest=STUN-PUB | | |
|----------------->| | | |----------------->| | |
| | | |
| |(4) STUN Req | | | |(4) STUN Req | |
| |src=1.2.3.4:5601 | | | |Src=NAT-PUB-1 | |
| |Dest=STUN-PUB | |
| |----------------->| | | |----------------->| |
| | | |
| |(5) STUN Resp | | | |(5) STUN Resp | |
| |<-----------------| | | |<-----------------| |
| |map=1.2.3.4:5601 | | | |Src=STUN-PUB | |
| |dest=1.2.3.4:5601 | | | |Dest=NAT-PUB-1 | |
| |Map=NAT-PUB-1 | |
| | | |
|(6) STUN Resp | | | |(6) STUN Resp | | |
|<-----------------| | | |<-----------------| | |
|map=1.2.3.4:5601 | | | |Src=STUN-PUB | | |
|dest=10.0.1.1:5301| | | |Dest=L-PRIV-1 | | |
|Map=NAT-PUB-1 | | |
| | | |
|(7) STUN Req | | | |(7) STUN Req | | |
|src=10.0.1.1:5302 | | | |Src=L-PRIV-2 | | |
|Dest=STUN-PUB | | |
|----------------->| | | |----------------->| | |
| | | |
| |(8) STUN Req | | | |(8) STUN Req | |
| |src=1.2.3.4:5608 | | | |Src=NAT-PUB-2 | |
| |Dest=STUN-PUB | |
| |----------------->| | | |----------------->| |
| | | |
| |(9) STUN Resp | | | |(9) STUN Resp | |
| |<-----------------| | | |<-----------------| |
| |map=1.2.3.4:5608 | | | |Src=STUN-PUB | |
| |dest=1.2.3.4:5608 | | | |Dest=NAT-PUB-2 | |
| |Map=NAT-PUB-2 | |
| | | |
|(10) STUN Resp | | | |(10) STUN Resp | | |
|<-----------------| | | |<-----------------| | |
|map=1.2.3.4:5608 | | | |Src=STUN-PUB | | |
|dest=10.0.1.1:5302| | | |Dest=L-PRIV-2 | | |
|Map=NAT-PUB-2 | | |
| | | |
|(11)SIP 200 OK | | | |(11)SIP 200 OK | | |
|----------------->| | | |----------------->| | |
| |(12)SIP 200 OK | | | |(12)SIP 200 OK | |
| |------------------------------------>| | |------------------------------------>|
| | | |
|========================================================| |========================================================|
|>>>>>>>>>>>Outgoing Media sent to 1.2.3.4:5601>>>>>>>>>>| |>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>>>|
|========================================================| |========================================================|
| | | |
|========================================================| |========================================================|
|<<<<<<<<&lt;<<Incoming Media sent to 1.2.3.4:5601<<<<<<<<<<| |<<<<<<<<&gt;><<<Incoming Media sent to L-PRIV-1<<<<<<<<<<<<|
|========================================================| |========================================================|
| | | |
|========================================================|
|>>>>>>>>>>>>Outgoing RTCP sent from L-PRIV-2>>>>>>>>>>>>|
|========================================================|
| | | |
|========================================================|
|<<<<<<<<<<<<<Incoming RTCP sent to L-PRIV-2<<<<<<<<<<<<<|
|========================================================|
| | | |
| | |(13)SIP ACK | | | |(13)SIP ACK |
| |<------------------------------------| | |<------------------------------------|
| | | |
|(14)SIP ACK | | | |(14)SIP ACK | | |
|<-----------------| | | |<-----------------| | |
| | | | | | | |
Figure 20: Restricted NAT with STUN - Receiving Figure 20: Restricted NAT with STUN - Receiving
o On receiving an invitation to a SIP voice session the VOIP client o On receiving an invitation to a SIP voice session (SIP INVITE
starts a local STUN client. The STUN client generates a standard request) the User Agent starts a local STUN client on the
STUN request as indicated in (3) from Figure 20 which also appropriate port on which it is to receive media. The STUN client
highlights the source address and port for which the client device generates a standard STUN request as indicated in (3) from
wishes to obtain a mapping. The STUN request is sent through the Figure 20 which also highlights the source address and port for
NAT towards the public internet. which the client device wishes to obtain a mapping. The STUN
request is sent through the NAT towards the public internet and
STUN Server.
o STUN message (4) traverses the NAT and breaks out onto the public o STUN message (4) traverses the NAT and breaks out onto the public
internet towards the public STUN server. Note that the source internet towards the public STUN server. Note that the source
address of the STUN requests now represents the public address and address of the STUN requests now represents the public address and
port from the public side of the NAT. port from the public side of the NAT.
o
o The STUN server receives the request and processes it o The STUN server receives the request and processes it
appropriately. This results in a successful STUN response being appropriately. This results in a successful STUN response being
generated and returned (5). The message contains details of the generated and returned (5). The message contains details of the
mapped public address (contained in the STUN MAPPED-ADDRESS mapped public address (contained in the STUN MAPPED-ADDRESS
attribute) which is to be used by the originating client to attribute) which is to be used by the originating client to
receive media (see 'map=' from (5)). receive media (see 'Map=NAT-PUB-1' from (5)).
o The STUN response traverses back through the NAT using the binding o The STUN response traverses back through the NAT using the binding
created by the STUN request and presents the new mapped address to created by the outgoing STUN request and presents the new mapped
the client (6). At this point the process is repeated to obtain a address to the client (6). At this point the process is repeated
second mapped address (as shown in (7)-(10)) for an alternative to obtain a second mapped address (as shown in (7)-(10)) for an
local address (local port has now changed from 5301 to 5302 in alternative local address (local port has now changed and is
(7)). represented by L-PRIV-2 in (7)).
o The client now constructs a SIP 200 OK message (11). Note that o The client now constructs a SIP 200 OK message (11) in response to
traversal of SIP is not covered in this example and is discussed the original SIP INVITE requests. Note that traversal of SIP is
in earlier sections of the document. The 200 OK response will use not covered in this example and is discussed in earlier sections
the addresses it has obtained in the previous STUN transactions to of the document. SIP Provisional responses are also left out for
populate the SDP of the SIP INVITE as shown below: simplicity. The 200 OK response will use the addresses it has
obtained in the previous STUN transactions to populate the SDP of
the SIP 200 OK as shown below:
v=0 v=0
o=test 2890844526 2890842807 IN IP4 10.0.1.1 o=test 2890844526 2890842807 IN IP4 $L-PRIV-1.address
c=IN IP4 1.2.3.4 c=IN IP4 $NAT-PUB-1.address
t=0 0 t=0 0
m=audio 5601 RTP/AVP 0 m=audio $NAT-PUB-1.port RTP/AVP 0
a=rtcp:5608 a=rtcp:$NAT-PUB-2.port
o Note that the mapped address obtained from the initial STUN o Note that the mapped address obtained from the initial STUN
transaction is inserted as the connection address for the SDP transaction is inserted as the connection address for the SDP
(c=1.2.3.4). The Primary port for RTP is also inserted in the SDP (c=NAT-PUB-1.address). The Primary port for RTP is also inserted
(m=audio 5601 RTP/AVP 0). Finally, the port gained from the in the SDP (m=audio NAT-PUB-1.port RTP/AVP 0). Finally, the port
additional binding is placed in the RTCP attribute (as discussed gained from the additional binding is placed in the RTCP attribute
in Section 3.2.5) for traversal of RTCP (a=rtcp:5608). (as discussed in Section 3.2.1.1) for traversal of RTCP (a=rtcp:
NAT-PUB-2.port).
o The SIP signalling then traverses the NAT and sets up the SIP o The SIP signalling then traverses the NAT and sets up the SIP
session (11-14). Note that the client transmits media as soon as session (11-14). Note that the client transmits media as soon as
the 200 OK to the INVITE is sent to the UAC(11). Up until this the 200 OK to the INVITE is sent to the UAC(11). Up until this
point the incoming media will not pass through the NAT as no point the incoming media will not pass through the NAT as no
outbound association has been created with the far end client. outbound association has been created with the far end client.
Two way media communication has now been established. Two way media communication has now been established.
4.2.1.2. ICE Solution 4.2.1.2. ICE Solution
The preferred solution for media traversal of NAT is using ICE, as The preferred solution for media traversal of NAT is using ICE, as
described in Section 3.2.4. The following examples illustrate the described in Section 3.2.4, regardless of the NAT type. The
traversal of a 'Port Restricted Cone' NAT for both an initiating and following examples illustrate the traversal of an 'Endpoint
receiving client. The example only covers ICE in association with independent' NAT for both an initiating. The example only covers ICE
STUN and TURN. in association with STUN and TURN usage.
4.2.1.2.1. Initiating Session 4.2.1.2.1. Initiating Session
The following example demonstrates an initiating traversal through a The following example demonstrates an initiating traversal through an
'Restricted Cone' NAT using ICE. 'Endpoint independent' NAT using ICE.
Client NAT STUN TURN * [Editors Note: Example needs to be expanded to include more ICE
Server Server detail e.g. timers etc.]
L NAT STUN NAT R
Server
| | | | |
|(1) Alloc Req | | | |
|Src=L-PRIV-1 | | | |
|Dest=STUN-PUB-1 | | | |
|--------------->| | | |
| | | | |
| |(2) Alloc Req | | |
| |Src=L-NAT-PUB-1 | | |
| |Des=STUN-PUB-1 | | |
| |--------------->| | |
| | | | |
| |(3) Alloc Resp | | |
| |<---------------| | |
| |Src=STUN-PUB-1 | | |
| |Dest=L-NAT-PUB-1| | |
| |Map=L-NAT-PUB-1 | | |
| |Rel=STUN-PUB-2 | | |
| | | | |
|(4) Alloc Resp | | | |
|<---------------| | | |
|Src=STUN-PUB-1 | | | |
|Dest=L-PRIV-1 | | | |
|Map=L-NAT-PUB-1 | | | |
|Rel=STUN-PUB-2 | | | |
| | | | | | | | | |
|(1) STUN Req | | | |
|src=10.0.1.1:5301 | | | |
|----------------->| | | |
| |(2) STUN Req | | |
| |src=1.2.3.4:5601 | | |
| |----------------->| | |
| |(3) STUN Resp | | |
| |<-----------------| | |
| |map=1.2.3.4:5601 | | |
| |dest=1.2.3.4:5601 | | |
|(4) STUN Resp | | | |
|<-----------------| | | |
|map=1.2.3.4:5601 | | | |
|dest=10.0.1.1:5301| | | |
|(5) STUN Req | | | | |(5) STUN Req | | | |
|src=10.0.1.1:5311 | | | | |Src=L-PRIV-2 | | | |
|----------------->| | | | |Dest=STUN-PUB-1 | | | |
| |(6) STUN Req | | | |--------------->| | | |
| |src=1.2.3.4:5611 | | | | | | | |
| |----------------->| | | | |(6) Alloc Req | | |
| |(7) STUN Resp | | | | |Src=L-NAT-PUB-2 | | |
| |<-----------------| | | | |Dest=STUN-PUB-1 | | |
| |map=1.2.3.4:5611 | | | | |--------------->| | |
| |dest=1.2.3.4:5611 | | | | | | | |
|(8) STUN Resp | | | | | |(7) Alloc Resp | | |
|<-----------------| | | | | |<---------------| | |
|map=1.2.3.4:5611 | | | | | |Src=STUN-PUB-1 | | |
|dest=10.0.1.1:5311| | | | | |Dest=NAT-PUB-2 | | |
|(9) TURN Allocate | | | | | |Map=NAT-PUB-2 | | |
|src=10.0.1.1:5302 | | | | | |Rel=STUN-PUB-3 | | |
|----------------->| | | | | | | | |
| |(10) TURN Allocate| | | |(8) Alloc Resp | | | |
| |src=1.2.3.4:5608 | | | |<---------------| | | |
| |----------------------------------->| | |Src=STUN-PUB-1 | | | |
| |(11) TURN Resp | | | |Dest=L-PRIV-2 | | | |
| |<-----------------------------------| | |Map=L-NAT-PUB-2 | | | |
| |map=2.3.4.5:5608 | | | |Rel=STUN-PUB-3 | | | |
| |dest=1.2.3.4:5608 | | | | | | | |
|(12) TURN Resp | | | | |(9) SIP INVITE | | | |
|<-----------------| | | | |------------------------------------------------->| |
|map=2.3.4.5:5608 | | | | | | | | |
|dest=10.0.1.1:5302| | | | | | | |(10) SIP INVITE |
|(13) TURN Allocate| | | | | | | |--------------->|
|src=10.0.1.1:5312 | | | | | | | | |
|----------------->| | | | | | | |(11) Alloc Req |
| |(14) TURN Allocate| | | | | | |<---------------|
| |src=1.2.3.4:5618 | | | | | | |Src=R-PRIV-1 |
| |----------------------------------->| | | | | |Dest=STUN-PUB-1 |
| |(15) TURN Resp | | | | | | | |
| |<-----------------------------------| | | | |(12) Alloc Req | |
| |map=2.3.4.5:5618 | | | | | |<---------------| |
| |dest=1.2.3.4:5618 | | | | | |Src=R-NAT-PUB-1 | |
|(16) TURN Resp | | | | | | |Dest=STUN-PUB-1 | |
|<-----------------| | | | | | | | |
|map=2.3.4.5:5618 | | | | | | |(13) Alloc Res | |
|dest=10.0.1.1:5312| | | | | | |--------------->| |
|(17)SIP INVITE | | | | | | |Src=STUN-PUB-1 | |
|----------------->| | | | | | |Dest=R-NAT-PUB-1| |
| |(18)SIP INVITE | | | | | |Map=R-NAT-PUB-1 | |
| |------------------------------------------->| | | |Rel=STUN-PUB-4 | |
| | |(19)SIP 200 OK | | | | | | |
| |<-------------------------------------------| | | | |(14) Alloc Res |
| | | |--------------->|
| | | |Src=STUN-PUB-1 |
| | | |Dest=R-PRIV-1 |
| | | |Map=R-NAT-PUB-1 |
| | | |Rel=STUN-PUB-4 |
| | | | |
| | | |(15) Alloc Req |
| | | |<---------------|
| | | |Src=R-PRIV-2 |
| | | |Dest=STUN-PUB-1 |
| | | | |
| | |(16) Alloc Req | |
| | |<---------------| |
| | |Src=R-NAT-PUB-2 | |
| | |Dest=STUN-PUB-1 | |
| | | | |
| | |(17) Alloc Res | |
| | |--------------->| |
| | |Src=STUN-PUB-1 | |
| | |Dest=R-NAT-PUB-2| |
| | |Map=R-NAT-PUB-2 | |
| | |Rel=STUN-PUB-5 | |
| | | | |
| | | |(18) Alloc Res |
| | | |--------------->|
| | | |Src=STUN-PUB-1 |
| | | |Dest=R-PRIV-2 |
| | | |Map=R-NAT-PUB-2 |
| | | |Rel=STUN-PUB-5 |
| | | | |
| | | |(19) SIP 200 OK |
| |<-------------------------------------------------|
| | | | |
|(20)SIP 200 OK | | | | |(20)SIP 200 OK | | | |
|<-----------------| | | | |<---------------| | | |
|(21)STUN Req | | | | | | | | |
|----------------->| | | | |(21) SIP ACK | | | |
| |(22) STUN Req | | | |------------------------------------------------->| |
| |------------------------------------------->| | | | | |
| | |(23)STUN Resp | | | | | |(22) SIP ACK |
| |<-------------------------------------------| | | | |--------------->|
|(24)STUN Resp | | | | | | | | |
|<-----------------| | | | |(23) Bind Req | | | |
|===============================================================| |------------------------>x | | |
|>>>>>>>>>>>Outgoing Media sent from 10.1.1.1:5301>>>>>>>>>>>>>>| |Src=L-PRIV-1 | | | |
|===============================================================| |Dest=R-PRIV-1 | | | |
| | |(25) STUN Req | | | | | | |
| |<-------------------------------------------| |(24) Bind Req | | | |
|(26)STUN Req | | | | |--------------->| | | |
|<-----------------| | | | |Src=L-PRIV-1 | | | |
|(27)STUN Resp | | | | |Dest=R-NAT-PUB-1| | | |
|----------------->| | | | | | | | |
| | |(28)STUN Resp | | | |(25) Bind Req | | |
| |------------------------------------------->| | |-------------------------------->| |
|===============================================================| | |Src=L-NAT-PUB-1 | | |
|<<<<<<<<<<<Incoming Media sent to 1.2.3.4:5601<<<<<<<<<<<<<<<<<| | |Dest=R-NAT-PUB-1| | |
|===============================================================| | | | | |
|(29)SIP ACK | | | | | | | |(26) Bind Req |
|----------------->| | | | | | | |--------------->|
| |(30) SIP ACK | | | | | | |Src=L-NAT-PUB-1 |
| |------------------------------------------->| | | | |Dest=R-PRIV-1 |
| | | | |
| | | |(27) Bind Res |
| | | |<---------------|
| | | |Src=R-PRIV-1 |
| | | |Dest=L-NAT-PUB-1|
| | | |Map=L-NAT-PUB-1 |
| | | | |
| | |(28) Bind Res | |
| |<--------------------------------| |
| | |Src=R-NAT-PUB-1 | |
| | |Dest=L-NAT-PUB-1| |
| | |Map=L-NAT-PUB-1 | |
| | | | |
|(29) Bind Res | | | |
|<---------------| | | |
|Src=R-NAT-PUB-1 | | | |
|Dest=L-PRIV-1 | | | |
|Map=L-NAT-PUB-1 | | | |
| | | | |
|===================================================================|
|>>>>>>>>>>>>>>>>>>>>>Outgoing RTP sent from >>>>>>>>>>>>>>>>>>>>>>>|
|===================================================================|
| | | | |
| | | |(30) Bind Req |
| | | x<-----------------------|
| | | |Src=R-PRIV-1 |
| | | |Dest=L-PRIV-1 |
| | | | |
| | | |(31) Bind Req |
| | | |<---------------|
| | | |Src=R-PRIV-1 |
| | | |Dest=L-NAT-PUB-1|
| | | | |
| | |(32) Bind Req | |
| |<--------------------------------| |
| | |Src=R-NAT-PUB-1 | |
| | |Dest=L-NAT-PUB-1| |
| | | | |
|(33) Bind Req | | | |
|<---------------| | | |
|Src=R-NAT-PUB-1 | | | |
|Dest=L-PRIV-1 | | | |
| | | | |
|(34) Bind Res | | | |
|--------------->| | | |
|Src=L-PRIV-1 | | | |
|Dest=R-NAT-PUB-1| | | |
|Map=R-NAT-PUB-1 | | | |
| | | | |
| |(35) Bind Res | | |
| |-------------------------------->| |
| |Src=L-NAT-PUB-1 | | |
| |Dest=R-NAT-PUB-1| | |
| |Map=R-NAT-PUB-1 | | |
| | | | |
| | | |(36) Bind Res |
| | | |--------------->|
| | | |Src=L-NAT-PUB-1 |
| | | |Dest=R-PRIV-1 |
| | | |Map=R-NAT-PUB-1 |
| | | | |
|===================================================================|
|<<<<<<<<<<<<<<<<<<<<<Outgoing RTP sent from <<<<<<<<<<<<<<<<<<<<<<<|
|===================================================================|
| | | | |
|(37) Bind Req | | | |
|--------------->| | | |
|Src=L-PRIV-2 | | | |
|Dest=R-NAT-PUB-2| | | |
| | | | |
| |(38) Bind Req | | |
| |-------------------------------->| |
| |Src=L-NAT-PUB-2 | | |
| |Dest=R-NAT-PUB-2| | |
| | | | |
| | | |(39) Bind Req |
| | | |--------------->|
| | | |Src=L-NAT-PUB-2 |
| | | |Dest=R-PRIV-2 |
| | | | |
| | | |(40) Bind Res |
| | | |<---------------|
| | | |Src=R-PRIV-2 |
| | | |Dest=L-NAT-PUB-2|
| | | |Map=L-NAT-PUB-2 |
| | | | |
| | |(41) Bind Res | |
| |<--------------------------------| |
| | |Src=R-NAT-PUB-2 | |
| | |Dest=L-NAT-PUB-2| |
| | |Map=L-NAT-PUB-2 | |
| | | | |
|(42) Bind Res | | | |
|<---------------| | | |
|Src=R-NAT-PUB-2 | | | |
|Dest=L-PRIV-2 | | | |
|Map=L-NAT-PUB-2 | | | |
| | | | |
|===================================================================|
|>>>>>>>>>>>>>>>>>>>>>Outgoing RTCP sent from >>>>>>>>>>>>>>>>>>>>>>|
|===================================================================|
| | | | |
| | | |(43) Bind Req |
| | | |<---------------|
| | | |Src=R-PRIV-2 |
| | | |Dest=L-NAT-PUB-2|
| | | | |
| | |(44) Bind Req | |
| |<--------------------------------| |
| | |Src=R-NAT-PUB-2 | |
| | |Dest=L-NAT-PUB-2| |
| | | | |
|(45) Bind Req | | | |
|<---------------| | | |
|Src=R-NAT-PUB-2 | | | |
|Dest=L-PRIV-2 | | | |
| | | | |
|(46) Bind Res | | | |
|--------------->| | | |
|Src=L-PRIV-2 | | | |
|Dest=R-NAT-PUB-2| | | |
|Map=R-NAT-PUB-2 | | | |
| | | | |
| |(47) Bind Res | | |
| |-------------------------------->| |
| |Src=L-NAT-PUB-2 | | |
| |Dest=R-NAT-PUB-2| | |
| |Map=R-NAT-PUB-2 | | |
| | | | |
| | | |(48) Bind Res |
| | | |--------------->|
| | | |Src=L-NAT-PUB-2 |
| | | |Dest=R-PRIV-2 |
| | | |Map=R-NAT-PUB-2 |
| | | | |
|===================================================================|
|<<<<<<<<<<<<<<<<<<<<<Outgoing RTCP sent from <<<<<<<<<<<<<<<<<<<<<<|
|===================================================================|
| | | | |
|(49) SIP INVITE | | | |
|------------------------------------------------->| |
| | | | |
| | | |(50) SIP INVITE |
| | | |--------------->|
| | | | |
| | | |(51) SIP 200 OK |
| |<-------------------------------------------------|
| | | | |
|(52) SIP 200 OK | | | |
|<---------------| | | |
| | | | |
|(53) SIP ACK | | | |
|------------------------------------------------->| |
| | | | |
| | | |(54) SIP ACK |
| | | |--------------->|
| | | | | | | | | |
Figure 22: Restricted NAT with ICE - Initiating Figure 22: Endpoint Independent NAT with ICE
o On deciding to initiate a SIP voice session the VOIP client starts o On deciding to initiate a SIP voice session the SIP client 'L'
a local STUN and TURN client. The STUN client generates a starts a local STUN client. The STUN client generates a standard
standard STUN request as indicated in (1) from Figure 22 which Allocate request as indicated in (1) from Figure 22 which also
also highlights the source address and port for which the client highlights the source address and port combination for which the
device wishes to obtain a mapping. The STUN request is sent client device wishes to obtain a mapping. The STUN request is
through the NAT towards the public internet. sent through the NAT towards the public internet.
o STUN message (2) traverses the NAT and breaks out onto the public o Allocate message (2) traverses the NAT and breaks out onto the
internet towards the public STUN server. Note that the source public internet towards the public STUN server. Note that the
address of the STUN requests now represents the public address and source address of the Allocate request now represents the public
port from the public side of the NAT. address and port from the public side of the NAT (L-NAT-PUB-1).
o o The STUN server receives the Allocate request and processes
o The STUN server receives the request and processes appropriately. appropriately. This results in a successful Allocate response
This results in a successful STUN response being generated and being generated and returned (3). The message contains details of
returned (3). The message contains details of the mapped public the reflexive address which is to be used by the originating
address (contained in the STUN MAPPED-ADDRESS attribute) which is client to receive media (see 'Map=L-NAT-PUB-1') from (3)). It
to be used by the originating client to receive media (see 'map=') also contains an appropriate relay address that can be used at the
from (3)). STUN server (see 'Rel=STUN-PUB-2').
o The STUN response traverses back through the NAT using the binding o The STUN response traverses back through the NAT using the binding
created by the STUN request and presents the new mapped address to created by the initial Allocate request and presents the new
the client (4). The process is repeated and a second STUN derived mapped address to the client (4). The process is repeated and a
address is obtained, as illustrated in (5)-(8) in Figure 22. second STUN derived set of address' are obtained, as illustrated
While the STUN client is obtaining addresses, the TURN client will in (5)-(8) in Figure 22. At this point the User Agent behind the
also be attempting to obtain external representations. The TURN NAT has pairs of derived external reflexive and relayed
Allocate message is constructed in association with the local IP representations. The client would be free to gather any number of
address and port combination (9). The TURN Allocate message is external representations using any UNSAF[9] compliant protocol.
then sent from the client to the external TURN server via the NAT o The client now constructs a SIP INVITE message (9). The INVITE
(10). The TURN server processes the Allocate request and returns
an appropriate response(11). The response contains the 'Mapped-
Address'(defined in STUN specification) attribute which contains
the external representation that the TURN server will provide for
the internal mapping. The TURN response then traverses back
through the NAT and returns the newly allocated external
representation to the originating client(12).The process is
repeated and a second TURN derived address is obtained, as
illustrated in (13)-(16) in Figure 22. At this point the client
behind the NAT has a pair of STUN external representations and
TURN equivalents. The client would be free to gather any number
of external representations using any UNSAF[9] compliant protocol.
o The client now constructs a SIP INVITE message (17). 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[15], as shown below in Figure 23 defined in the ICE specification[16], as shown below in Figure 23
(*note - /* signifies line continuation): (*note - /* signifies line continuation):
v=0 v=0
o=test 2890844526 2890842807 IN IP4 10.0.1.1 o=test 2890844526 2890842807 IN IP4 $L-PRIV-1
c=IN IP4 1.2.3.4 c=IN IP4 $L-PRIV-1.address
t=0 0 t=0 0
m=audio 5601 RTP/AVP 0 a=ice-pwd:$LPASS
a=candidate:H83jksd 1.0 rtp_uname_frag_1 rtp_pass_1 1.2.3.4 5601 m=audio $L-PRIV-1.port RTP/AVP 0
/* rtcp_uname_frag_1 rtcp_pass_1 1.2.3.4 5611 a=rtpmap:0 PCMU/8000
a=candidate:Hye73hd 0.8 rtp_uname_frag_2 rtp_pass_2 1.2.3.4 5608 a=rtcp:$L-PRIV-2.port
/* rtcp_uname_frag_2 rtcp_pass_2 1.2.3.4 5618 a=candidate:$L1 1 UDP 1.0 $L-PRIV-1.address $L-PRIV-1.port
a=candidate:H82hjjh 0.5 rtp_uname_frag_3 rtp_pass_3 1.2.3.4 5600 a=candidate:$L1 2 UDP 1.0 $L-PRIV-2.address $L-PRIV-2.port
a=candidate:$L2 1 UDP 0.7 $L-NAT-PUB-1.address $L-NAT-PUB-1.port
a=candidate:$L2 2 UDP 0.7 $L-NAT-PUB-2.address $L-NAT-PUB-2.port
a=candidate:$L3 1 UDP 0.3 $STUN-PUB-2.address $STUN-PUB-2.port
a=candidate:$L3 2 UDP 0.3 $STUN-PUB-3.address $STUN-PUB-3.port
Figure 23: ICE SDP Figure 23: ICE SDP Offer
o The SDP has been constructed to include all the available o The SDP has been constructed to include all the available
addresses that have been assembled. The first 'candidate' address candidate pairs that have been assembled. The first candidate
contains the two STUN derived addresses for both RTP and RTCP pair (as identified by $L1) contain two local addresses that have
traffic. This entry has been given the highest priority (1.0) by the highest priority (1.0). They are also encoded into the
the client and also inserted as the default address. connection (c=) and media (m=) lines of the SDP. The second
o The second 'candidate' address contains the two TURN derived 'candidate' address pair, as identified by the component-id,
addresses for both RTP and RTCP traffic. This entry has been contains the two NAT reflexive addresses obtained from the STUN
given the second highest priority (0.8). server for both RTP and RTCP traffic (identified by candidate-id
o The third and final 'candidate' address contains a local interface $L2). This entry has been given a priority (0.7) by the client.
address that has not been derived externally. This entry has been The third and final candidate pair represents the relayed
given the lowest priority (0.5). addresses (as identified by $L3) obtained from the STUN server.
This pair has the lowest priority (0.3) and will be used as a last
resort.
o The SIP signalling then traverses the NAT and sets up the SIP o The SIP signalling then traverses the NAT and sets up the SIP
session (18)-(20). On advertising a candidate address, the client session (9)-(10). On advertising a candidate address, the client
should have a local STUN server running on each advertised should have a local STUN server running on each advertised
candidate address. This is for the purpose of responding to candidate address. This is for the purpose of responding to
incoming connectivity checks. In this example, after sending the incoming connectivity checks.
INVITE and receiving a 200 OK, the client initiates an outgoing o On receiving the SIP INVITE request (10) client 'R' also starts
STUN connectivity check to the selected remote interfaces local STUN servers on appropriate address/port combinations and
(21)-(24) (*Note - this process will be repeated for every gathers potential candidate addresses to be encoded into the SDP.
advertised address which is not shown in the diagram for Steps (11-18) involve client 'R' carrying out the same steps as
simplicity). On receiving a STUN response, the client is able to client 'L'. This involves obtaining local, reflexive and relayed
stream media to the remote destination (*Note - if further STUN addresses. Client 'R' is now ready to generate an appropriate
connectivity responses are received after the client has started answer in the SIP 200 OK message (19). The example answer follows
streaming media with a higher priority, it will be used instead). in Figure 23 (*note - /* signifies line continuation):
The remote destination will also carry out similar STUN
connectivity checks (25)-(28) which then allows media to be
streamed to the client behind the NAT using the advertised
connections. Two way audio is now possible between the two
clients.
4.2.1.2.2. Receiving Session Invitation v=0
o=test 3890844516 3890842803 IN IP4 $R-PRIV-1
c=IN IP4 $R-PRIV-1.address
t=0 0
a=ice-pwd:$RPASS
m=audio $R-PRIV-1.port RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=rtcp:$R-PRIV-2.port
a=candidate:$L1 1 UDP 1.0 $R-PRIV-1.address $R-PRIV-1.port
a=candidate:$L1 2 UDP 1.0 $R-PRIV-2.address $R-PRIV-2.port
a=candidate:$L2 1 UDP 0.7 $R-NAT-PUB-1.address $R-NAT-PUB-1.port
a=candidate:$L2 2 UDP 0.7 $R-NAT-PUB-2.address $R-NAT-PUB-2.port
a=candidate:$L3 1 UDP 0.3 $STUN-PUB-2.address $STUN-PUB-4.port
a=candidate:$L3 2 UDP 0.3 $STUN-PUB-3.address $STUN-PUB-5.port
This example is similar to that described in Section 4.2.1.2.1. The Figure 24: ICE SDP Answer
client behind a NAT is receiving the incoming ICE Initiate in a SIP
INVITE request.
Client NAT STUN TURN * o The two clients will now form candidate pairs and the transport
Server Server address check list as specified in ICE. Both 'L' and 'R' will
| | | | | start the check list with the currently active component pair
| | |(1)SIP INVITE | | (contained in the 'c=' and 'm=' of the SDP). As illustrated in
| |<-------------------------------------------| (23), client 'L' constructs a STUN Bind request in an attempt to
|(2)SIP INVITE | | | | validate the connection address received in the SDP of the 200 OK
|<-----------------| | | | (20). As a private address was specified in the active address in
| | | | | the SDP, the Stun Bind request fails to reach its destination
|(3) STUN Req | | | | causing a bind failure. Client 'L' now attempts a STUN Bind
|src=10.0.1.1:5301 | | | | request for the first candidate pair in the returned SDP with the
|----------------->| | | | highest priority (24). As can be seen from messages (24) to (29),
| |(4) STUN Req | | | the STUN Bind request is successful and returns a positive outcome
| |src=1.2.3.4:5601 | | | for the connectivity check. Client 'L' is now free to steam media
| |----------------->| | | to the candidate pair. Client 'R' also carries out the same set
| |(5) STUN Resp | | | of binding requests. It firstly (in parallel) tries to contact
| |<-----------------| | | the active address contained in the SDP (30). Client 'R' now
| |map=1.2.3.4:5601 | | | attempts a STUN Bind request for the first candidate pair in the
| |dest=1.2.3.4:5601 | | | returned SDP with the highest priority (31). As can be seen from
|(6) STUN Resp | | | | messages (31) to (36), the STUN bind request is successful and
|<-----------------| | | | returns a positive outcome for the connectivity check. The
|map=1.2.3.4:5601 | | | | previously described check confirm on both sides that connectivity
|dest=10.0.1.1:5301| | | | can be achieved through appropriate candidates. As part of the
|(7) STUN Req | | | | process in this example, both 'L' and 'R' will now complete the
|src=10.0.1.1:5311 | | | | same connectivity checks for part 2 of the component named for
|----------------->| | | | each candidate for use with RTCP. The connectivity checks for
| |(8) STUN Req | | | part '2' of the candidate component are shown in 'L'(37-42) and
| |src=1.2.3.4:5611 | | | 'R'(43-48).
| |----------------->| | | o The candidates have now been fully verified (Valid status) and as
| |(9) STUN Resp | | | they are the highest priority, an updated offer (49-50) is now
| |<-----------------| | | sent from the offerer (client 'L') to the answerer (client 'R'
| |map=1.2.3.4:5611 | | | representing the new active candidates. The new offer would look
| |dest=1.2.3.4:5611 | | | as follows:
|(10) STUN Resp | | | |
|<-----------------| | | |
|map=1.2.3.4:5611 | | | |
|dest=10.0.1.1:5311| | | |
|(11) TURN Allocate| | | |
|src=10.0.1.1:5302 | | | |
|----------------->| | | |
| |(12) TURN Allocate| | |
| |src=1.2.3.4:5608 | | |
| |------------------------------------>| |
| |(13) TURN Resp | | |
| |<------------------------------------| |
| |map=2.3.4.5:5608 | | |
| |dest=1.2.3.4:5608 | | |
|(14) TURN Resp | | | |
|<-----------------| | | |
|map=2.3.4.5:5608 | | | |
|dest=10.0.1.1:5302| | | |
|(15) TURN Allocate| | | |
|src=10.0.1.1:5312 | | | |
|----------------->| | | |
| |(16) TURN Allocate| | |
| |src=1.2.3.4:5618 | | |
| |------------------------------------>| |
| |(17) TURN Resp | | |
| |<------------------------------------| |
| |map=2.3.4.5:5618 | | |
| |dest=1.2.3.4:5618 | | |
|(18) TURN Resp | | | |
|<-----------------| | | |
|map=2.3.4.5:5618 | | | |
|dest=10.0.1.1:5312| | | |
|(19)SIP 200 OK | | | |
|----------------->| | | |
| |(20)SIP 200 OK | | |
| |------------------------------------------->|
|(21)STUN Req | | | |
|----------------->| | | |
| |(22) STUN Req | | |
| |------------------------------------------->|
| | |(23)STUN Resp | |
| |<-------------------------------------------|
|(24)STUN Resp | | | |
|<-----------------| | | |
|===============================================================|
|>>>>>>>>>>>Outgoing Media sent from 10.1.1.1:5301>>>>>>>>>>>>>>|
|===============================================================|
| | |(25) STUN Req | |
| |<-------------------------------------------|
|(26)STUN Req | | | |
|<-----------------| | | |
|(27)STUN Resp | | | |
|----------------->| | | |
| | |(28)STUN Resp | |
| |------------------------------------------->|
|===============================================================|
|<<<<<<<<<<<Incoming Media sent to 1.2.3.4:5601<<<<<<<<<<<<<<<<<|
|===============================================================|
| | |(29)SIP ACK | |
| |<-------------------------------------------|
|(30)SIP ACK | | | |
|<-----------------| | | |
| | | | |
Figure 24: Restricted NAT with ICE - Receiving v=0
o=test 2890844526 2890842808 IN IP4 $L-PRIV-1
c=IN IP4 $L-NAT-PUB-1.address
t=0 0
a=ice-pwd:$LPASS
m=audio $L-NAT-PUB-1.port RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=rtcp:$L-NAT-PUB-2.port
a=candidate:$L2 1 UDP 0.7 $L-NAT-PUB-1.address $L-NAT-PUB-1.port
a=candidate:$L2 2 UDP 0.7 $L-NAT-PUB-2.address $L-NAT-PUB-2.port
o As mentioned previously, this example is similar to that described Figure 25: ICE SDP Updated Offer
in Section 4.2.1.2.1. For this reason, some of the description
may reference the previous example. The scenario starts with the
client behind the NAT receiving a SIP INVITE(1) reques (ICE
initiate message).
o On receiving the SIP INVITE the client is able to collect all
possible addresses available for media interaction (e.g. Local
addresses, STUN derived, TURN derived). See detail from
Section 4.2.1.2.1 for explanation on accumulating all possible
media addresses (Steps (3)-(18) in Figure 24).
o The client will perform connectivity checks on all addresses
received in the SIP INVITE message(21)-(24). Note that steps
(21)-(24) will be repeated for every address offered in the SIP
INVITE request. This is not shown in the diagram for simplicity.
On receiving a response to a STUN connectivity check, the client
will start streaming media (*Note - if further STUN connectivity
responses are received after the client has started streaming meda
with a higher priority, it will be used instead).
o The STUN connectivity checks will then occur in the opposite o The resulting answer (51-52) for 'R' would look as follows:
direction, as illustrated in Section 4.2.1.2.1. A STUN server
running on each advertised address will respond to incoming STUN
connectivity requests(25)-(28).
o Bi-directional audio can now occur between the two clients.
4.2.2. Symmetric NAT v=0
o=test 3890844516 3890842803 IN IP4 $R-PRIV-1
c=IN IP4 $R-PRIV-1.address
t=0 0
a=ice-pwd:$RPASS
m=audio $R-PRIV-1.port RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=rtcp:$R-PRIV-2.port
a=candidate:$L2 1 UDP 0.7 $R-NAT-PUB-1.address $R-NAT-PUB-1.port
a=candidate:$L2 2 UDP 0.7 $R-NAT-PUB-2.address $R-NAT-PUB-2.port
Figure 26: ICE SDP Updated Answer
4.2.2. Port and Address Dependant NAT
4.2.2.1. STUN Failure 4.2.2.1. STUN Failure
This section highlights that while STUN is the preferred mechanism This section highlights that while STUN is the preferred mechanism
for traversal of NAT, it does not solve every cases. The use of STUN for traversal of NAT, it does not solve every case. The use of basic
on its own will not guarantee traversal through every NAT type, hence STUN on its own will not guarantee traversal through every NAT type,
the recommendation that ICE be the prefered option. hence the recommendation that ICE is the preferred option.
Client SYMMETRIC STUN [..] Client PORT/ADDRESS Dependant STUN [..]
NAT Server NAT Server
| | | | | | | |
|(1) STUN Req | | | |(1) STUN Req | | |
|src=10.0.1.1:5301 | | | |Src=L-PRIV-1 | | |
|Dest=STUN-PUB | | |
|----------------->| | | |----------------->| | |
| | | |
| |(2) STUN Req | | | |(2) STUN Req | |
| |src=1.2.3.4:5601 | | | |Src=NAT-PUB-1 | |
| |Dest=STUN-PUB | |
| |----------------->| | | |----------------->| |
| | | |
| |(3) STUN Resp | | | |(3) STUN Resp | |
| |<-----------------| | | |<-----------------| |
| |map=1.2.3.4:5601 | | | |Src=STUN-PUB | |
| |dest=1.2.3.4:5601 | | | |Dest=NAT-PUB-1 | |
| |Map=NAT-PUB-1 | |
| | | |
|(4) STUN Resp | | | |(4) STUN Resp | | |
|<-----------------| | | |<-----------------| | |
|map=1.2.3.4:5601 | | | |Src=STUN-PUB | | |
|dest=10.0.1.1:5301| | | |Dest=L-PRIV-1 | | |
|Map=NAT-PUB-1 | | |
| | | |
|(5)SIP INVITE | | | |(5)SIP INVITE | | |
|----------------->| | | |------------------------------------------------------->|
| |(6)SIP INVITE | | | | | |
| |------------------------------------>| | | |(6)SIP 200 OK |
| | |(7)SIP 200 OK |
| |<------------------------------------| | |<------------------------------------|
|(8)SIP 200 OK | | | | | | |
|(7)SIP 200 OK | | |
|<-----------------| | | |<-----------------| | |
| | | |
|========================================================| |========================================================|
|>>>>>>>>>>>Outgoing Media sent from 10.0.1.1:5301>>>>>>>| |>>>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>|
|========================================================| |========================================================|
| | | |
| x=====================================| | x=====================================|
| xIncoming Media sent to 1.2.3.4:5601<<| | xIncoming Media sent to L-PRIV-1<<<<<<|
| x=====================================| | x=====================================|
|(9)SIP ACK | | | | | | |
|(8)SIP ACK | | |
|----------------->| | | |----------------->| | |
| |(10) SIP ACK | | | |(9) SIP ACK | |
| |------------------------------------>| | |------------------------------------>|
| | | | | | | |
Figure 27: Port/Address Dependant NAT with STUN - Failure
Figure 25: Symmetric NAT with STUN - Failure The example in Figure 27 is conveyed in the context of a client
behind the 'Port/Address Dependant' NAT initiating a call. It should
The example in Figure 25 is conveyed in the context of the client be noted that the same problem applies when a client receives a SIP
behind the Symmetric NAT initiating a call. It should be noted that invitation and is behind a Port/Address Dependant NAT.
the same problem applies when a client receives a SIP invitation and o In Figure 27 the client behind the NAT obtains an external
is behind a Symmetric NAT.
o In Figure 25 the client behind the NAT obtains an external
representation using standard STUN mechanisms (1)-(4) that have representation using standard STUN mechanisms (1)-(4) that have
been used in previous examples in this document (e.g been used in previous examples in this document (e.g
Section 4.2.1.1.1). Section 4.2.1.1.1).
o The external mapped address (reflexive) obtained is also used in
o The external mapped address obtained is also used in the outgoing the outgoing SDP contained in the SIP INVITE request(5).
SDP contained in the SIP INVITE request(5).
o In this example the client is still able to send media to the o In this example the client is still able to send media to the
external client. The problem occurs when the client outside the external client. The problem occurs when the client outside the
NAT tries to use the address supplied in the outgoing INVITE NAT tries to use the reflexive address supplied in the outgoing
request to traverse media back through the Symmetric NAT. INVITE request to traverse media back through the 'Port/Address
o A symmetric NAT has differing rules from the Cone variety of NAT. Dependent' NAT.
For any internal IP address and port mapping, data sent to o A 'Port/Address Dependant' NAT has differing rules from the
different external addresses does not provide the same public 'Endpoint Independent' type of NAT (as defined in [11]). For any
mapping at the NAT. In Figure 25 the STUN query produced a valid internal IP address and port combination, data sent to a different
external mapping. This mapping, however, can only be used in the external destination does not provide the same public mapping at
context of the original STUN request that was sent to the STUN the NAT. In Figure 27 the STUN query produced a valid external
server. Any packets that attempt to use the mapped address, that mapping or receiving media. This mapping, however, can only be
does not come from the STUN server IP address and port, will be used in the context of the original STUN request that was sent to
dropped at the NAT. Figure 25 shows the media being dropped at the STUN server. Any packets that attempt to use the mapped
the NAT after (8). address, that does not come from the STUN server IP address and
optionally port, will be dropped at the NAT. Figure 27 shows the
media being dropped at the NAT after (7) and before (8). This
then leads to one way audio.
4.2.2.2. TURN Solution 4.2.2.2. TURN Usage Solution
As identified in Section 4.2.2.1, STUN provides a useful tool for the As identified in Section 4.2.2.1, STUN provides a useful tool kit for
traversal of the majority of NATs but fails with symmetric type NAT. the traversal of the majority of NATs but fails with Port/Address
This led to the development of the TURN solution[13] which introduces Dependant NAT. This led to the development of the TURN usage
a media relay in the path for NAT traversal (as described in solution [12] which uses the STUN toolkit. It allows a client to
Section 3.2.3). The following example explains how TURN solves the request a relayed address at the STUN server rather than a reflexive
previous failure when using STUN to traverse a symmetric NAT. representation. This then introduces a media relay in the path for
NAT traversal (as described in Section 3.2.3). The following example
explains how the TURN usage solves the previous failure when using
STUN to traverse a 'Port/Address Dependant' type NAT.
Client SYMMETRIC TURN [..] L Port/Address Dependant STUN [..]
NAT Server NAT Server
| | | | | | | |
|(1) TURN Allocate | | | |(1) Alloc Req | | |
|src=10.0.1.1:5301 | | | |Src=L-PRIV-1 | | |
|Dest=STUN-PUB-1 | | |
|----------------->| | | |----------------->| | |
| |(2) TURN Allocate | | | | | |
| |src=1.2.3.4:5601 | | | |(2) Alloc Req | |
| |Src=NAT-PUB-1 | |
| |Dest=STUN-PUB-1 | |
| |----------------->| | | |----------------->| |
| |(3) TURN Resp | | | | | |
| |(3) Alloc Resp | |
| |<-----------------| | | |<-----------------| |
| |map=2.3.4.5:5601 | | | |Src=STUN-PUB-1 | |
| |dest=1.2.3.4:5601 | | | |Dest=NAT-PUB-1 | |
|(4) TURN Resp | | | | |Map=NAT-PUB-1 | |
| |Rel=STUN-PUB-2 | |
| | | |
|(4) Alloc Resp | | |
|<-----------------| | | |<-----------------| | |
|map=2.3.4.5:5601 | | | |Src=STUN-PUB-1 | | |
|dest=10.0.1.1:5301| | | |Dest=L-PRIV-1 | | |
|(5)SIP INVITE | | | |Map=NAT-PUB-1 | | |
|Rel=STUN-PUB-2 | | |
| | | |
|(5) Alloc Req | | |
|Src=L-PRIV-2 | | |
|Dest=STUN-PUB-1 | | |
|----------------->| | | |----------------->| | |
| |(6)SIP INVITE | | | | | |
| |(6) Alloc Req | |
| |Src=NAT-PUB-2 | |
| |Dest=STUN-PUB-1 | |
| |----------------->| |
| | | |
| |(7) Alloc Resp | |
| |<-----------------| |
| |Src=STUN-PUB-1 | |
| |Dest=NAT-PUB-2 | |
| |Map=NAT-PUB-2 | |
| |Rel=STUN-PUB-3 | |
| | | |
|(8) Alloc Resp | | |
|<-----------------| | |
|Src=STUN-PUB-1 | | |
|Dest=L-PRIV-2 | | |
|Map=NAT-PUB-2 | | |
|Rel=STUN-PUB-3 | | |
| | | |
|(9)SIP INVITE | | |
|----------------->| | |
| | | |
| |(10)SIP INVITE | |
| |------------------------------------>| | |------------------------------------>|
| | |(7)SIP 200 OK | | | | |
| | |(11)SIP 200 OK |
| |<------------------------------------| | |<------------------------------------|
|(8)SIP 200 OK | | | | | | |
|(12)SIP 200 OK | | |
|<-----------------| | | |<-----------------| | |
| | | |
|========================================================| |========================================================|
|>>>>>>>>>>>Outgoing Media sent from 10.0.1.1:5301>>>>>>>| |>>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>>|
|========================================================| |========================================================|
| | | |
| | |==================| | | |==================|
| | |<<<Media Sent to<<| | | |<<<Media Sent to<<|
| | |<<< 2.3.4.5:5601<<| | | |<<<<STUN-PUB-2<<<<|
| | |==================| | | |==================|
| | | |
|=====================================| | |=====================================| |
|<Incoming Media Sent to 1.2.3.4:5601<| | |<Incoming Media Relayed to L-PRIV-1<<| |
|=====================================| | |=====================================| |
|(9)SIP ACK | | | | | | |
| | |==================|
| | |<<<RTCP Sent to<<>|
| | |<<<<STUN-PUB-3<<<<|
| | |==================|
| | | |
|=====================================| |
|<<Incoming RTCP Relayed to L-PRIV-2<<| |
|=====================================| |
| | | |
|(13)SIP ACK | | |
|----------------->| | | |----------------->| | |
| |(10) SIP ACK | | | | | |
| |(14) SIP ACK | |
| |------------------------------------>| | |------------------------------------>|
| | | | | | | |
Figure 26: Symmetric NAT with TURN - Success Figure 28: Port/Address Dependant NAT with TURN Usage - Success
o The client obtains a TURN derived address by issuing a TURN o In this example, client 'L' issues a TURN allocate request(1) to
allocate request(1). The request traverses through the symmetric obtained a relay address at the STUN server. The request
NAT and reaches the TURN server (2). The Turn server generates a traverses through the 'Port/Address Dependant' NAT and reaches the
response that contains an external representation. The STUN server (2). The STUN server generates an Allocate response
representation maps to an address mapping on the TURN server which (3) that contains both a reflexive address (Map=NAT-PUB-1) of the
is bound to the public pin hole in the NAT, opened by the TURN client and also a relayed address (Rel=STUN-PUB-2). The relayed
request. This results in any traffic being sent to the TURN address maps to an address mapping on the STUN server which is
server representation (2.3.4.5:5601) will be redirected to the bound to the public pin hole that has been opened on the NAT by
external representation of the pin hole created by the TURN the Allocate request. This results in any traffic sent to the
request(1.2.3.4:5601). STUN server relayed address (Rel=STUN-PUB-2) being forwarded to
o The TURN derived address (2.3.4.5:5601) arrives back at the the external representation of the pin hole created by the
originating client(4). This address can then be used in the SDP Allocate request(NAT-PUB-1).
for the outgoing SIP INVITE request as shown below (note that the o The TURN derived address (STUN-PUB-2) arrives back at the
RTCP attribute would have been obtained by another TURN derived originating client(4) in an Allocate response. This address can
address which is not shown in the call flow for simplicity): then be used in the SDP for the outgoing SIP INVITE request as
shown in the following example (note that the example also
includes client 'L' obtaining a second relay address for use in
the RTCP attribute (5-8)):
o o
v=0 v=0
o=test 2890844342 2890842164 IN IP4 10.0.1.1 o=test 2890844342 2890842164 IN IP4 $L-PRIV-1
c=IN IP4 2.3.4.5 c=IN IP4 $STUN-PUB-2.address
t=0 0 t=0 0
m=audio 5601 RTP/AVP 0 m=audio $STUN-PUB-2.port RTP/AVP 0
a=rtcp:5608 a=rtcp:$STUN-PUB-3.port
o On receiving the INVITE request, the UAS is able to stream media o On receiving the INVITE request, the UAS is able to stream media
to the TURN derived address (2.3.4.5:5601). As shown in and RTCP to the relay address (STUN-PUB-2 and STUN-PUB-3) at the
Figure 26, the media from the UAS is directed to the TURN derived STUN server. As shown in Figure 28 (between messages (12) and
address at the TURN server. The TURN server then redirects the (13), the media from the UAS is directed to the relayed address at
traffic to the open pin hole in the symmetric NAT (1.2.3.4:5601). the STUN server. The STUN server then forwards the traffic to the
The media traffic is then able to traverse the symmetric NAT and open pin holes in the Port/Address Dependant NAT (NAT-PUB-1 and
arrives back at the client. NAT-PUB-2). The media traffic is then able to traverse the 'Port/
o The TURN solution on its own will work for Symmetric and other Address Dependant' NAT and arrives back at client 'L'.
types of NAT mentioned in this specification but should only be o The TURN usage of STUN on its own will work for 'Port/Address
used as a last resort. The relaying of media through an external Dependent' and other types of NAT mentioned in this specification
entity is not an efficient mechanism for all NAT traversal. but should only be used as a last resort. The relaying of media
through an external entity is not an efficient mechanism for NAT
traversal and comes at a high processing cost.
4.2.2.3. ICE Solution 4.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
STUN for all forms of NAT traversal and a solution using TURN for the core STUN usage for all forms of NAT traversal and a solution using
symmetric NAT case. As mentioned previously in this document, the TURN usage for the Port/Address Dependant NAT case. As mentioned
RECOMMENDED mechanism for traversing all varieties of NAT is using previously in this document, the RECOMMENDED mechanism for traversing
ICE, as detailed in Section 3.2.4. Ice makes use of STUN, TURN and all varieties of NAT is using ICE, as detailed in Section 3.2.4. ICE
any other UNSAF [9] compliant protocol to provide a list of makes use of core STUN, TURN usage and any other UNSAF[9] compliant
prioritised addresses that can be used for media traffic. Detailed protocol to provide a list of prioritised addresses that can be used
examples of ICE can be found in Section 4.2.1.2.1 and in for media traffic. Detailed examples of ICE can be found in
Section 4.2.1.2.2. These examples are associated with a 'Port Section 4.2.1.2.1. These examples are associated with an 'Endpoint
Restricted' type NAT but can be applied to any NAT type variation, Independent' type NAT but can be applied to any NAT type variation,
including 'Symmetric' type NAT. The procedures are the same and of including 'Port/Address Dependant' type NAT. The procedures are the
the list of candidate addresses, a client will choose where to send same and of the list of candidate addresses, a client will choose
media dependant on the results of the STUN connectivity checks on where to send media dependant on the results of the STUN connectivity
each candidate address and the associated priority (highest priority checks on each candidate address and the associated priority (highest
wins). For more information see the core ICE specification[15] priority wins). For more information see the core ICE
specification[16]
4.3. Advanced NAT media Traversal Using ICE
4.3.1. Full Cone --> Full Cone traversal
4.3.1.1. Without NAT
4.3.1.1.1. Initiating Session
4.3.1.1.2. Receiving Session Invitation
4.3.1.2. With NAT
4.3.1.2.1. Initiating Session
4.3.1.2.2. Receiving Session Invitation
4.3.2. Port Restricted Cone --> Port Restricted Cone traversal
4.3.2.1. Without NAT
4.3.2.1.1. Initiating Session
4.3.2.1.2. Receiving Session Invitation
4.3.2.2. With NAT
4.3.2.2.1. Initiating Session [Editors Note: TODO - a detailed example will be included here which
includes promotion of a TURN relayed address to the active candidate
to traverse a 'Port/Address Dependent' type NAT.]
4.3.2.2.2. Receiving Session Invitation 4.3. Address independent Port Restricted NAT --> Address independent
Port Restricted NAT traversal
4.3.3. Internal TURN Server (Enterprise Deployment) [Editors Note: TODO - a detailed example will be included where User
A and B are both behind Address Independent NATs that have Port
restricted properties. This means that the stun-derived addresses
will work, but each side must send a 'suicide' or 'primer' STUN
packet that creates a permission in the NAT. So, the main thing to
show here is how the first packet from B to A will create a
permission in B's NAT but gets dropped at A. When A gets the answer
it starts its STUN checks and the packet from A to B creates a
permission in A's NAT and gets through B's NAT because of the
previously installed permission. This now triggers B to resend its
stun request which now works.]
4.3.3.1. Peer in same Enterprise 4.4. Internal TURN Usage (Enterprise Deployment)
4.3.3.2. Peer in same Enterprise - Separated by NAT [Editors Note: TODO - a detailed example will be included for User A
and User B. User A is in an enterprise, which has a address and port
restricted NAT. User B is on the public internet. There is a TURN+
STUN server deployed INSIDE the enterprise NAT. The NAT has a static
set of ports forwarded to the internal TURN server (say, 100 ports).
The TURN server is configured with those ports. So, when user A
talks to the TURN server it gets an address and port on the *public*
side of the NAT, with a preconfigured port forwarding rule. Indeed,
the client is configured with two TURN servers. Both are physically
the same TURN server. However, when talking to one instance the
client gets the public address. When talking to the other instance
it gets a private address inside the NAT. The ice process ends up
selecting the public address given out by the TURN server usage.]
4.3.3.3. Peer outside Enterprise 5. Intercepting Intermediary (B2BUA)
4.4. Intercepting Intermediary (B2BUA) [Editors Note: TODO - a detailed example demonstrating how a B2BUA
can obtain STUN/TURN addresses for the purpose of allocating to
Clients. This example shows how intermediaries can control the flow
of media without having to directly access SDP on the signalling
plane.
4.5. IPv4-IPv6 Transition 6. IPv4-IPv6 Transition
This section describes how IPv6-only SIP user agents can communicate This section describes how IPv6-only SIP user agents can communicate
with IPv4-only SIP user agents. with IPv4-only SIP user agents.
4.5.1. IPv4-IPv6 Transition for SIP Signalling 6.1. IPv4-IPv6 Transition for SIP Signalling
IPv4-IPv6 translations at the SIP level usually take place at dual- IPv4-IPv6 translations at the SIP level usually take place at dual-
stack proxies that have both IPv4 and IPv6 DNS entries. Since this stack proxies that have both IPv4 and IPv6 DNS entries. Since this
translations do not involve NATs that are placed in the middle of two translations do not involve NATs that are placed in the middle of two
SIP entities, they fall outside the scope of this document. A SIP entities, they fall outside the scope of this document. A
detailed description of this type of translation can be found in [18] detailed description of this type of translation can be found in [19]
4.5.2. IPv4-IPv6 Transition for Media 6.2. IPv4-IPv6 Transition for Media
Figure 28 shows a network of IPv6 SIP user agents that has a relay Figure 30 shows a network of IPv6 SIP user agents that has a relay
with a pool of public IPv4 addresses. The IPv6 SIP user agents of with a pool of public IPv4 addresses. The IPv6 SIP user agents of
this IPv6 network need to communicate with users on the IPv4 this IPv6 network need to communicate with users on the IPv4
Internet. To do so, the IPv6 SIP user agents use TURN to obtain a Internet. To do so, the IPv6 SIP user agents use TURN to obtain a
public IPv4 address from the relay. The mechanism that an IPv6 SIP public IPv4 address from the relay. The mechanism that an IPv6 SIP
user agent follows to obtain a public IPv4 address from a relay using user agent follows to obtain a public IPv4 address from a relay using
TURN is the same as the one followed by a user agent with a private TURN is the same as the one followed by a user agent with a private
IPv4 address to obtain a public IPv4 address. The example in IPv4 address to obtain a public IPv4 address. The example in
Figure 29 explains how to use TURN to obtain an IPv4 address and how Figure 31 explains how to use TURN to obtain an IPv4 address and how
to use the ANAT semantics [17] of the SDP grouping framework [8] to to use the ANAT semantics [17] of the SDP grouping framework [8] to
provide both IPv4 and IPv6 addresses for a particular media stream. provide both IPv4 and IPv6 addresses for a particular media stream.
+----------+ +----------+
| / \ | | / \ |
/SIP \ /SIP \
/Phone \ /Phone \
/ \ / \
------------ ------------
skipping to change at page 40, line 6 skipping to change at page 48, line 30
++ ++
|| ||
+-----++ +-----++
| IPv6 | | IPv6 |
| SIP | | SIP |
| user | | user |
| agent| | agent|
+------+ +------+
Figure 28: IPv6-IPv4 transition scenario Figure 30: IPv6-IPv4 transition scenario
IPv6 SIP TURN IPv4 SIP IPv6 SIP TURN IPv4 SIP
User Agent Server User Agent User Agent Server User Agent
| | | | | |
| (1) TURN Allocate | | | (1) TURN Allocate | |
| src=[2001:DB8::1]:30000 | | | src=[2001:DB8::1]:30000 | |
|------------------------------------>| | |------------------------------------>| |
| (2) TURN Resp | | | (2) TURN Resp | |
| map=192.0.2.2:25000 | | | map=192.0.2.2:25000 | |
| dest=[2001:DB8::1]:30000 | | | dest=[2001:DB8::1]:30000 | |
|<------------------------------------| | |<------------------------------------| |
skipping to change at page 40, line 41 skipping to change at page 49, line 37
| |<<<<<< Media <<<<<| | |<<<<<< Media <<<<<|
| |==================| | |==================|
|=====================================| | |=====================================| |
|<<<<<<<<<< Outgoing Media <<<<<<<<<<<| | |<<<<<<<<<< Outgoing Media <<<<<<<<<<<| |
|=====================================| | |=====================================| |
| | | | | |
| (5) SIP ACK | | | (5) SIP ACK | |
|------------------------------------------------------->| |------------------------------------------------------->|
| | | | | |
Figure 29: IPv6-IPv4 translation with TURN Figure 31: IPv6-IPv4 translation with TURN
o The IPv6 SIP user agent obtains a TURN-derived IPv4 address by o The IPv6 SIP user agent obtains a TURN-derived IPv4 address by
issuing a TURN allocate request (1). The TURN server generates a issuing a TURN allocate request (1). The TURN server generates a
response that contains the public IPv4 address. This IPv4 address response that contains the public IPv4 address. This IPv4 address
maps to the IPv6 source address of the TURN allocate request, maps to the IPv6 source address of the TURN allocate request,
which the IPv6 address of the SIP user agent. This results in any which the IPv6 address of the SIP user agent. This results in any
traffic being sent to the IPv4 address provided by TURN server traffic being sent to the IPv4 address provided by TURN server
(192.0.2.2:25000) will be redirected to the IPv6 address of the (192.0.2.2:25000) will be redirected to the IPv6 address of the
SIP user agent ([2001:DB8::1]:30000). SIP user agent ([2001:DB8::1]:30000).
o The TURN-derived address (192.0.2.2:25000) arrives back at the o The TURN-derived address (192.0.2.2:25000) arrives back at the
skipping to change at page 41, line 32 skipping to change at page 50, line 26
a=mid:1 a=mid:1
m=audio 25000 RTP/AVP 0 m=audio 25000 RTP/AVP 0
c=IN IP4 192.0.2.2 c=IN IP4 192.0.2.2
a=rtcp:25001 a=rtcp:25001
a=mid:2 a=mid:2
o On receiving the INVITE request, the user agent server rejects the o On receiving the INVITE request, the user agent server rejects the
IPv6 media line by setting its port to zero in the answer and IPv6 media line by setting its port to zero in the answer and
starts sending media to the IPv4 address in the offer. The IPv6 starts sending media to the IPv4 address in the offer. The IPv6
user agent sends media through the relay as well, as shown in user agent sends media through the relay as well, as shown in
Figure 29. Figure 31.
4.6. ICE with RTP/TCP 7. ICE with RTP/TCP
TODO [Editors Note: TODO - a detailed example will be included on using
ICE with RTP/TCP - as define in [18]
5. Acknowledgments 8. Acknowledgments
The authors would like to thank the members of the IETF SIPPING WG The authors would like to thank the members of the IETF SIPPING WG
for their comments and suggestions. Detailed comments were provided for their comments and suggestions. Detailed comments were provided
by Francois Audet, kaiduan xie and Hans Persson. by Francois Audet, kaiduan xie and Hans Persson.
6. References 9. References
6.1. Normative References 9.1. Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", "RTP: A Transport Protocol for Real-Time Applications",
RFC 1889, January 1996. RFC 1889, January 1996.
[3] Handley, M. and V. Jacobson, "SDP: Session Description [3] Handley, M. and V. Jacobson, "SDP: Session Description
skipping to change at page 42, line 40 skipping to change at page 51, line 32
RFC 3327, December 2002. RFC 3327, December 2002.
[8] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, [8] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne,
"Grouping of Media Lines in the Session Description Protocol "Grouping of Media Lines in the Session Description Protocol
(SDP)", RFC 3388, December 2002. (SDP)", RFC 3388, December 2002.
[9] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- [9] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-
Address Fixing (UNSAF) Across Network Address Translation", Address Fixing (UNSAF) Across Network Address Translation",
RFC 3424, November 2002. RFC 3424, November 2002.
[10] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN [10] Rosenberg, J., "Simple Traversal of UDP Through Network Address
- Simple Traversal of User Datagram Protocol (UDP) Through Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-03
Network Address Translators (NATs)", RFC 3489, March 2003. (work in progress), March 2006.
[11] Jennings, C. and A. Hawrylyshen, "SIP Conventions for UAs with [11] Audet, F. and C. Jennings, "NAT Behavioral Requirements for
Unicast UDP", draft-ietf-behave-nat-udp-07 (work in progress),
June 2006.
[12] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal
of UDP Through NAT (STUN)", draft-ietf-behave-turn-00 (work in
progress), March 2006.
[13] Jennings, C. and A. Hawrylyshen, "SIP Conventions for UAs with
Outbound Only Connections", draft-jennings-sipping-outbound-01 Outbound Only Connections", draft-jennings-sipping-outbound-01
(work in progress), February 2005. (work in progress), February 2005.
[12] Rosenberg, J., "Obtaining and Using Globally Routable User [14] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-06 (work in progress), (SIP)", draft-ietf-sip-gruu-09 (work in progress), June 2006.
October 2005.
[13] Rosenberg, J., "Traversal Using Relay NAT (TURN)",
draft-rosenberg-midcom-turn-08 (work in progress),
September 2005.
[14] Wing, D., "Symmetric RTP and RTCP Considered Helpful", [15] Wing, D., "Symmetric RTP and RTCP Considered Helpful",
draft-wing-mmusic-symmetric-rtprtcp-01 (work in progress), draft-wing-mmusic-symmetric-rtprtcp-01 (work in progress),
October 2004. October 2004.
[15] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A [16] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for Methodology for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols", draft-ietf-mmusic-ice-06 (work in Offer/Answer Protocols", draft-ietf-mmusic-ice-08 (work in
progress), October 2005. progress), March 2006.
[16] Rosenberg, J., "Simple Traversal of UDP Through Network Address
Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-02
(work in progress), July 2005.
[17] Camarillo, G., "The Alternative Network Address Types Semantics [17] Camarillo, G., "The Alternative Network Address Types Semantics
(ANAT) for theSession Description Protocol (SDP) Grouping (ANAT) for theSession Description Protocol (SDP) Grouping
Framework", draft-ietf-mmusic-anat-02 (work in progress), Framework", draft-ietf-mmusic-anat-02 (work in progress),
October 2004. October 2004.
6.2. Informative References [18] Rosenberg, J., "TCP Candidates with Interactive Connectivity
Establishment (ICE)", draft-ietf-mmusic-ice-tcp-00 (work in
progress), March 2006.
[18] Camarillo, G., "IPv6 Transcition in the Session Initiation 9.2. Informative References
[19] Camarillo, G., "IPv6 Transcition in the Session Initiation
Protocol (SIP)", draft-camarillo-sipping-v6-transition-00 (work Protocol (SIP)", draft-camarillo-sipping-v6-transition-00 (work
in progress), February 2005. in progress), February 2005.
Authors' Addresses Authors' Addresses
Chris Boulton Chris Boulton
Ubiquity Software Corporation Ubiquity Software Corporation
Eastern Business Park Eastern Business Park
St Mellons St Mellons
Cardiff, South Wales CF3 5EA Cardiff, South Wales CF3 5EA
 End of changes. 258 change blocks. 
744 lines changed or deleted 1138 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/