draft-ietf-sipping-nat-scenarios-02.txt   draft-ietf-sipping-nat-scenarios-03.txt 
SIPPING Working Group C. Boulton SIPPING Working Group C. Boulton
Internet-Draft Ubiquity Software Corporation Internet-Draft Ubiquity Software Corporation
Expires: April 4, 2005 J. Rosenberg Expires: April 27, 2006 J. Rosenberg
Cisco Systems Cisco Systems
October 2004 G. Camarillo
Ericsson
October 24, 2005
Best Current Practices for NAT Traversal for SIP Best Current Practices for NAT Traversal for SIP
draft-ietf-sipping-nat-scenarios-02 draft-ietf-sipping-nat-scenarios-03
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
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 April 4, 2005. This Internet-Draft will expire on April 27, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
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
mechanisms for media traffic. This document aims to provide concrete mechanisms for media traffic. This document aims to provide concrete
recommendations and a unified method for NAT traversal as well as recommendations and a unified method for NAT traversal as well as
documenting corresponding call flows. documenting corresponding call flows.
Table of Contents Table of Contents
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 . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.4 ICE . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.4. ICE . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.5 RTCP Attribute . . . . . . . . . . . . . . . . . . . . 10 3.2.5. RTCP Attribute . . . . . . . . . . . . . . . . . . . . 10
3.2.6 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 . . . . . . . . . . . . . . . . . 16
4.1.4 Receiving an Invitation to a Session . . . . . . . . . 18 4.1.4. Receiving an Invitation to a Session . . . . . . . . . 18
4.2 Basic NAT Media Traversal . . . . . . . . . . . . . . . . 21 4.2. Basic NAT Media Traversal . . . . . . . . . . . . . . . . 21
4.2.1 Port Restricted Cone NAT . . . . . . . . . . . . . . . 21 4.2.1. Port Restricted Cone NAT . . . . . . . . . . . . . . . 21
4.2.2 Symmetric NAT . . . . . . . . . . . . . . . . . . . . 33 4.2.2. Symmetric NAT . . . . . . . . . . . . . . . . . . . . 33
4.3 Advanced NAT media Traversal Using ICE . . . . . . . . . . 36 4.3. Advanced NAT media Traversal Using ICE . . . . . . . . . . 38
4.3.1 Full Cone --> Full Cone traversal . . . . . . . . . . 37 4.3.1. Full Cone --> Full Cone traversal . . . . . . . . . . 38
4.3.2 Port Restricted Cone --> Port Restricted Cone 4.3.2. Port Restricted Cone --> Port Restricted Cone
traversal . . . . . . . . . . . . . . . . . . . . . . 37 traversal . . . . . . . . . . . . . . . . . . . . . . 38
4.3.3 Internal TURN Server (Enterprise Deployment) . . . . . 37 4.3.3. Internal TURN Server (Enterprise Deployment) . . . . . 38
4.4 Intercepting Intermediary (B2BUA) . . . . . . . . . . . . 37 4.4. Intercepting Intermediary (B2BUA) . . . . . . . . . . . . 38
4.5 IPV4/IPV6 . . . . . . . . . . . . . . . . . . . . . . . . 37 4.5. IPv4-IPv6 Transition . . . . . . . . . . . . . . . . . . . 38
4.6 ICE with RTP/TCP . . . . . . . . . . . . . . . . . . . . . 37 4.5.1. IPv4-IPv6 Transition for SIP Signalling . . . . . . . 39
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.5.2. IPv4-IPv6 Transition for Media . . . . . . . . . . . . 39
5.1 Normative References . . . . . . . . . . . . . . . . . . . 37 4.6. ICE with RTP/TCP . . . . . . . . . . . . . . . . . . . . . 41
5.2 Informative References . . . . . . . . . . . . . . . . . . 39 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . . . 40 6.1. Normative References . . . . . . . . . . . . . . . . . . . 42
6.2. Informative References . . . . . . . . . . . . . . . . . . 43
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 [14]. NAT types can be found in RFC 3489bis [16].
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, connection reuse,
SDP attribute for RTCP, and others. These each represent a part of SDP attribute for RTCP, and others. These each represent a part of
the solution, but none of them gives the overall context for how the the solution, but none of them gives the overall context for how the
NAT traversal problem is decomposed and solved through this NAT traversal problem is decomposed and solved through this
collection of specifications. This document serves to meet that collection of 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 it's 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
and media signaling and media signaling
3. A set of basic and advanced call flow scenarios 3. A set of basic and advanced call flow scenarios
2. Problem Statement 2. Problem Statement
The traversal of SIP through NAT can be split into two categories The traversal of SIP through NAT can be split into two categories
skipping to change at page 4, line 10 skipping to change at page 4, line 11
[1]). The port is extracted from the SIP 'Via' header to complete [1]). The port is extracted from the SIP 'Via' header to complete
the IP address/port combination for returning the SIP response. the IP address/port combination for returning the SIP response.
While the destination is correct, the port contained in the SIP 'Via' While the destination is correct, the port contained in the SIP 'Via'
header represents the listening port of the originating client and header represents the listening port of the originating client and
not the port representing the open pin hole on the NAT. This results not the port representing the open pin hole on the NAT. This results
in responses being sent back to the NAT but to a port that is likely in responses being sent back to the NAT but to a port that is likely
not open for SIP traffic. The SIP response will then be dropped at not open for SIP traffic. The SIP response will then be dropped at
the NAT. This is illustrated in Figure 1 which depicts a SIP the NAT. This is illustrated in Figure 1 which depicts a SIP
response being returned to port 5060. response being returned to port 5060.
Private Network NAT Public Network Private NAT Public
| 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<------------------------| |
| | | | | | | | | |
-------- | -------- -------- | --------
| |
| |
| |
Figure 1 Figure 1
Secondly, when using a reliable, connection orientated transport Secondly, when using a reliable, connection orientated transport
protocol such as TCP, SIP has an inherent mechanism that results in protocol such as TCP, SIP has an inherent mechanism that results in
SIP responses reusing the connection that was created/used for the SIP responses reusing the connection that was created/used for the
corresponding transactional request. The SIP protocol does not corresponding transactional request. The SIP protocol does not
provide a mechanism that allows new requests generated in the provide a mechanism that allows new requests generated in the reverse
opposite direction (Previously occupying the role of UAS for the last direction of the originating client to use the existing TCP
transaction) to use the existing TCP connection created between the connection created between the client and the server during
client and the server during registration. This results in the registration. This results in the registered contact address not
registered contact address not being bound to the "connection" in the being bound to the "connection" in the case of TCP. Requests are
case of TCP. Requests are then blocked at the NAT, as illustrated in then blocked at the NAT, as illustrated in Figure 2. This problem
Figure 2. This problem also exists for unreliable transport also exists for unreliable transport protocols such as UDP where
protocols such as UDP where external NAT mappings need to be re-used external NAT mappings need to be re-used to reach a SIP entity on the
to reach a SIP entity on the private side of the network. private side of the network.
Private Network NAT Public Network Private NAT Public
| Network | Network
| |
| |
-------- (UAC 8023) REGISTER/Response (UAS 5060) -------- -------- (UAC 8023) REGISTER/Response (UAS 5060) --------
| |----------------------->---<-----------------------| | | |-------------------->---<-----------------------| |
| | | | | | | | | |
| Client | |5060 INVITE (UAC 8015)| Proxy | | Client | |5060 INVITE (UAC 8015)| Proxy |
| | x<------------------------| | | | x<------------------------| |
| | | | | | | | | |
-------- | -------- -------- | --------
| |
| |
| |
Figure 2 Figure 2
skipping to change at page 5, line 41 skipping to change at page 5, line 41
protocols such as TCP, the problem exists for SIP signaling using any protocols such as TCP, the problem exists for SIP signaling using any
transport protocol. The solution proposed for this problem in transport protocol. The solution proposed for this problem in
section 3 of this document is relevant for all SIP signaling, section 3 of this document is relevant for all SIP signaling,
regardless of the transport protocol. regardless of the transport protocol.
NAT policy can dictate that connections should be closed after a NAT policy can dictate that connections should be closed after a
period of inactivity. This period of inactivity can range period of inactivity. This period of inactivity can range
drastically from a number seconds to hours. Pure SIP signaling can drastically from a number seconds to hours. Pure SIP signaling can
not be relied upon to keep alive connections for a number of reasons. not be relied upon to keep alive connections for a number of reasons.
Firstly, SIP entities can sometimes have no signaling traffic for Firstly, SIP entities can sometimes have no signaling traffic for
long periods of time which has the potential to exceed he inactivity long periods of time which has the potential to exceed the inactivity
timer, this can lead to problems where endpoints are not available to timer, and this can lead to problems where endpoints are not
receive incoming requests as the connection has been closed. available to receive incoming requests as the connection has been
Secondly, if a low inactivity timer is specified, SIP signaling is closed. Secondly, if a low inactivity timer is specified, SIP
not appropriate as a keep-alive mechanism as it has the potential to signaling is not appropriate as a keep-alive mechanism as it has the
add a large amount of traffic to the network which uses up valuable potential to add a large amount of traffic to the network which uses
resource and also requires processing at a SIP stack, which is also a up valuable resource and also requires processing at a SIP stack,
waste of processing resource. which is also a waste of processing resources.
Media associated with SIP calls also has problems traversing NAT. Media associated with SIP calls also has problems traversing NAT.
RTP [2]] is on if the most common media transport type used in SIP RTP [2]] is one of the most common media transport types used in SIP
signaling. Negotiation of RTP occurs with a SIP session signaling. Negotiation of RTP occurs with a SIP session
establishment using the Session Description Protocol(SDP) [3] and a establishment using the Session Description Protocol(SDP) [3] and a
SIP offer/answer exchange[4]. During a SIP offer/answer exchange an SIP offer/answer exchange[5]. During a SIP offer/answer exchange an
IP address and port combination are specified by each client in a IP address and port combination are specified by each client in a
session as a means of receiving media such as RTP. The problem session as a means of receiving media such as RTP. The problem
arises when a client advertises it's address to receive media and it arises when a client advertises its address to receive media and it
exists in a private network that is not accessible from outside the exists in a private network that is not accessible from outside the
NAT. Figure 3 illustrates this problem. NAT. Figure 3 illustrates this problem.
NAT Public Network NAT NAT Public Network NAT
| | | |
| | | |
| | | |
-------- | SIP Signaling Session | -------- -------- | SIP Signaling Session | --------
| |----------------------->---<-----------------------| | | |----------------------->---<--------------------| |
| | | | | | | | | | | |
| Client | | | | Client | | Client | | | | Client |
| A |>=========>RTP>=====================>RTP>======X | B | | A |>=====>RTP>==Unknown Address==>X | | B |
| | X=====<RTP<=====================<RTP<=========<| | | | | X<==Unknown Address==<RTP<===<| |
-------- | | -------- -------- | | --------
| | | |
| | | |
| | | |
Figure 3 Figure 3
The connection address representing both clients are not available The connection address representing both clients are not available on
on the public internet and traffic can be sent from both clients the public internet and traffic can be sent from both clients through
through their NATs. The problem occurs when the traffic attempts to their NATs. The problem occurs when the traffic reaches the public
traverse media through the foreign (not local) NAT. The connection internet and is not resolveable. The media traffic fails. The
address extracted from the SDP payload is that of an internal connection address extracted from the SDP payload is that of an
address, and so not resolvable from the public side of the NAT. To internal address, and so not resolvable from the public side of the
complicate the problem further, a number of different NAT topologies NAT. To complicate the problem further, a number of different NAT
with different default behaviors increase the difficulty of proposing topologies with different default behaviors increase the difficulty
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
into two clear solution areas as defined in section 2 of this into two clear solution areas as defined in section 2 of this
document. The traversal of the core protocol signaling and the document. The traversal of the core protocol signaling and the
traversal of the associated media as specified in the Session traversal of the associated media as specified in the Session
Description Payload (SDP) of a SIP offer/answer exchange[4]. The Description Payload (SDP) of a SIP offer/answer exchange[5]. The
following sub-sections outline solutions that enable core SIP following sub-sections outline solutions that enable core SIP
signaling and its associated media to traverse NATs. signaling and its associated media to traverse NATs.
3.1 SIP Signaling 3.1. SIP Signaling
SIP signaling has two areas that result in transactional failure when SIP signaling has two areas that result in transactional failure when
traversing through NAT, as described in section 2 of this document. traversing through NAT, as described in section 2 of this document.
The remaining sub-sections describe appropriate solutions that result The remaining sub-sections describe appropriate solutions that result
in SIP signalling traversal through NAT, regardless of transport in SIP signalling traversal through NAT, regardless of transport
protocol. IT is RECOMMEDED that SIP compliant entities follow the protocol. IT is RECOMMEDED that SIP compliant entities follow the
guidelines presented in this section to enable traversal of SIP guidelines presented in this section to enable traversal of SIP
signaling through NATs. signaling through NATs.
3.1.1 Symmetric Response 3.1.1. Symmetric Response
As described in section 2 of this document, when using an unreliable As described in section 2 of this document, when using an unreliable
transport protocol such as UDP, SIP responses are sent to the IP transport protocol such as UDP, SIP responses are sent to the IP
address and port combination contained in the SIP 'Via' header field address and port combination contained in the SIP 'Via' header field
(or default port for the appropriate transport protocol if not (or default port for the appropriate transport protocol if not
present). This can result in responses being blocked at a NAT. In present). This can result in responses being blocked at a NAT. In
such circumstances, SIP signaling requires a mechanism that will such circumstances, SIP signaling requires a mechanism that will
allow entities to override the basic response generation mechanism in allow entities to override the basic response generation mechanism in
RFC 3261 [1]. Once the SIP response is constructed, the destination RFC 3261 [1]. Once the SIP response is constructed, the destination
is still derived using the mechanisms described in RFC 3261 [1]. The is still derived using the mechanisms described in RFC 3261 [1]. The
port (to which the response will be sent), however, will not equal port (to which the response will be sent), however, will not equal
that specified in the SIP 'Via' header field but will be the port that specified in the SIP 'Via' header field but will be the port
from which the original request was sent. This results in the from which the original request was sent. This results in the pin-
pin-hole opened for the requests traversal of the NAT being reused, hole opened for the requests traversal of the NAT being reused, in a
in a similar manner to that of reliable connection orientated similar manner to that of reliable connection orientated transport
transport protocols such as TCP. Figure 4 illustrates the response protocols such as TCP. Figure 4 illustrates the response traversal
traversal through the open pin hole using this method. through the open pin hole using this method.
Private Network NAT Public Network Private NAT Public
| Network | Network
| |
| |
-------- | -------- -------- | --------
| | | | | | | | | |
| |send/receive | send/receive| | | |send/receive | send/receive| |
| Client |port 5060-----<<->>-------------<<->>-----port 5060| Client | | Client |port 5060-----<<->>---------<<->>-----port 5060| Client |
| A | | | B | | A | | | B |
| | | | | | | | | |
-------- | -------- -------- | --------
| |
| |
| |
Figure 4 Figure 4
The exact functionality for this method of response traversal is The exact functionality for this method of response traversal is
called 'Symmetric Response' and the details are documented in RFC called 'Symmetric Response' and the details are documented in RFC
3581 [5]. Additional requirements are imposed on SIP entities in 3581 [6]. Additional requirements are imposed on SIP entities in
this specification such as listening and sending SIP this specification such as listening and sending SIP requests/
requests/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 3.1.2, The second problem with sip signaling, as defined in Section 2 and
is to allow incoming requests to be properly routed. This is illustrated in Figure 2, is to allow incoming requests to be properly
addressed in [9], which allows the reuse of a TCP connection or UDP routed.
5-tuple for incoming requests. That draft also provides keepalive
mechanisms based on using STUN to the SIP server. Usage of this
specification is RECOMMENDED. This mechanism is not transport
specific and should be used for any transport protocol.
Even if this draft is not used, clients SHOULD use the same IP Guidelines for devices such as User Agents that can only generate
address and port (i.e., socket) for both transmission and receipt of outbound connections through a NAT are documented in 'SIP Conventions
SIP messages. Doing so allows for the vast majority of industry for UAs with Outbound Only Connections'[11]. The document provides
techniques for the reuse of a TCP connection or UDP 5-tuple for
incoming requests. It also provides a keepalive mechanism based on
using STUN to the SIP server. Usage of this specification is
RECOMMENDED. This mechanism is not transport specific and should be
used for any transport protocol.
Even if the previous draft is not used, clients SHOULD use the same
IP address and port (i.e., socket) for both transmission and receipt
of SIP messages. Doing so allows for the vast majority of industry
provided solutions to properly function. 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 as 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
of this section provide the required solution set. of this section provide the required solution set.
3.2.1 Symmetric RTP 3.2.1. Symmetric RTP
The primary problem identified in section 2 of this document is that The primary problem identified in section 2 of this document is that
internal IP address/port combinations can not be reached from the internal IP address/port combinations can not be reached from the
public side of a NAT. In the case of media such as RTP, this will public side of a NAT. In the case of media such as RTP, this will
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 match the information that was conveyed in the SDP. In this case the
the client will ignore the SDP address/port combination and return client will ignore the SDP address/port combination and return RTP to
RTP to the IP address/port combination identified as the source of the IP address/port combination identified as the source of the
the incoming media. This technique is known as 'Symmetric RTP' and incoming media. This technique is known as 'Symmetric RTP' and is
is documented in [12]. 'Symmetric RTP' SHOULD only be used for documented in [14]. '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.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 [8]. It Address Translators(NAT) or STUN is defined in RFC 3489 [10]. It
provides a lightweight protocol that allows entities to probe and provides a lightweight protocol that allows entities to probe and
discover the type of NAT that exist between itself and external discover the type of NAT that exists between itself and external
entities. It also provides details of the external IP address/port entities. It also provides details of the external IP address/port
combination used by the NAT device to represent the internal entity combination used by the NAT device to represent the internal entity
on the public facing side of a NAT. On learning of such an external on the public facing side of a NAT. On learning of such an external
representation, a client can use accordingly as the connection representation, a client can use it accordingly as the connection
address in SDP to provide NAT traversal. STUN only works with Full address in SDP to provide NAT traversal. STUN only works with Full
Cone, Restricted Cone and Port Restricted Cone type NATs. STUN does Cone, Restricted Cone and Port Restricted Cone type NATs. STUN does
not work with Symmetric NATs as the technique used to probe for the not work with Symmetric NATs as the technique used to probe for the
external IP address port representation using a STUN server will external IP address port representation using a STUN server will
provide a different result to that required for traversal by an provide a different result to that required for traversal by an
alternative SIP entity. The IP address/port combination deduced for alternative SIP entity. The IP address/port combination deduced for
the STUN server would be blocked for incoming packets from an the STUN server would be blocked for incoming packets from an
alterative SIP entity. alterative SIP entity.
3.2.3 TURN 3.2.3. TURN
As mentioned in the previous section, the STUN protocol does not work As mentioned in the previous section, the STUN protocol does not work
for UDP traversal through a Symmetric style NAT. Traversal Using for UDP traversal through a Symmetric style NAT. Traversal Using
Relay NAT (TURN) provides the solution for UDP traversal of symmetric Relay NAT (TURN) provides the solution for UDP traversal of symmetric
NAT. TURN is extremely similar to STUN in both syntax and operation. NAT. TURN is extremely similar to STUN in both syntax and operation.
It provides an external address at a TURN server that will act as a It provides an external address at a TURN server that will act as a
relay and guarantee traffic will reach the associated internal relay and guarantee traffic will reach the associated internal
address. The full details of the TURN specification are defined in address. The full details of the TURN specification are defined in
[11]. A TURN service will almost always provide media traffic to a [13]. A TURN service will almost always provide media traffic to a
SIP entity but it is RECOMMENDED that this method only be used as a SIP entity but it is RECOMMENDED that this method only be used as a
last resort and not as a general mechanism for NAT traversal. This last resort and not as a general mechanism for NAT traversal. This
is because using TURN has high performance costs when relaying media is because using TURN has high performance costs when relaying media
traffic. 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[7] 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
accumulated, they are all included in the SDP exchange in a new media accumulated, they are all included in the SDP exchange in a new media
attribute called 'candidate'. Each 'candidate' SDP attribute entry attribute called 'candidate'. Each 'candidate' SDP attribute entry
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 [13]. the ICE methodology are contained in [15].
3.2.5 RTCP Attribute 3.2.5. RTCP Attribute
Normal practice when selecting a port for defining Real Time Control Normal practice when selecting a port for defining Real Time Control
Protocol(RTCP) [2] is for consecutive order numbering (i.e select an Protocol(RTCP) [2] is for consecutive order numbering (i.e select an
incremented port for RTCP from that used for RTP). This assumption incremented port for RTCP from that used for RTP). This assumption
causes RTCP traffic to break when traversing many NATs due to blocked 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 ports. To combat this problem a specific address and port need to be
specified in the SDP rather than relying on such assumptions. RFC specified in the SDP rather than relying on such assumptions. RFC
3605 [5] defines an SDP attribute that is included to explicitly 3605 [6] defines an SDP attribute that is included to explicitly
specify transport connection information for RTCP. The address specify transport connection information for RTCP. The address
details can be obtained using any appropriate method including those details can be obtained using any appropriate method including those
detailed previously in this section (e.g. STUN, TURN). detailed previously in this section (e.g. STUN, TURN).
3.2.6 Solution Profiles 3.2.6. 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.6.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 [5] 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 variety of environments including enterprise, consumer and behind all varieties
NAT. of NAT.
3.2.6.2 Consumer Profile 3.2.6.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 [5] 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.6.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 NAT. The scenarios include traversal for both reliable and un-
un-reliable transport protocols. reliable transport protocols.
[Editors Note: The scenarios are still in early construction and a [Editors Note: The scenarios are still in early construction and a
couple have been included as a hint of direction - All comments couple have been included as a hint of direction - All comments
welcome for next release] 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 | |
|<-----------------| | |<-----------------| |
skipping to change at page 12, line 47 skipping to change at page 12, line 47
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: 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>; connectioId=1
;+sip.instance="<urn:uuid:00000000-0000-0000-0000-000A95A0E120>" ;+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;rport=8050;branch=z9hG4bK;received=192.0.1.2 Via: SIP/2.0/UDP client.example.com:5060
;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
To: Client <sip:client@example.com>;tag=876877 To: Client <sip:client@example.com>;tag=876877
Call-ID: 763hdc73y7dkb37@example.com Call-ID: 763hdc73y7dkb37@example.com
CSeq: 1 REGISTER CSeq: 1 REGISTER
WWW-Authenticate: [not shown] WWW-Authenticate: [not shown]
Content-Length: 0 Content-Length: 0
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 [5] 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
[9]. The connection tuple creation is clearly shown in Figure 5. [11]. 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]
[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 | |
|<-----------------| | |<-----------------| |
skipping to change at page 14, line 29 skipping to change at page 14, line 29
| 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 messages request/responses using a Traversal of SIP REGISTER requests/responses using a reliable,
reliable, connection orientated protocol such as TCP does not require connection orientated protocol such as TCP does not require any
any additional core SIP signaling extensions. SIP responses will additional core SIP signaling extensions. SIP responses will re-use
re-use the connection created for the initial REGISTER request, (1) the connection created for the initial REGISTER request, (1) from
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: 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>; connectioId=1
;+sip.instance="<urn:uuid:00000000-0000-0000-0000-000A95A0E121>" ;+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 of the This example was included to show the inclusion of the connection re-
connection re-use Contact header parameters as defined in the use Contact header parameters as defined in the Connection Re-use
Connection Re-use draft [9]. This creates an association tuple as draft [11]. This creates an association tuple as described in the
described in the previous example for future inbound requests previous example for future inbound requests directed at the newly
directed at the newly created registration binding with the only created registration binding with the only difference that the
difference that the association is with a TCP connection, not a UDP association is with a TCP connection, not a UDP pin hole binding.
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]
4.1.2 Registration(Registrar/Proxy not Co-Located) 4.1.2. Registration(Registrar/Proxy not Co-Located)
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 | | |
skipping to change at page 16, line 5 skipping to change at page 16, line 4
| | |(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 that contained in section 4.1.1.2. This time
the REGISTER request is routed onwards to a separated Registrar. The the REGISTER request is routed onwards to a separated Registrar. The
important message to note is (5) in Figure 7. At this point, the important message to note is (6) in Figure 7. At this point, the
proxy server routes the SIP REGISTER message to the Registrar. The proxy server routes the SIP REGISTER message to the Registrar. The
proxy will create the connection re-use tuple at the same moment as proxy will create the connection re-use tuple at the same moment as
the co-located example but for subsequent messages to arrive at the the co-located example but for subsequent messages to arrive at the
Proxy, the element needs to request to stay in the signaling path. Proxy, the element needs to request to stay in the signaling path.
REGISTER message (5) contains a SIP PATH extension header, as defined The REGISTER message (5) contains a SIP PATH extension header, as
in RFC 3327 [6]. REGISTER message (5) would look as follows: defined in RFC 3327 [7]. 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: 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:sip%3Aclient%40example.com@proxy.example.com;lr>
Contact: <sip:client@client.example.com;transport=tcp>; connectioId=1 Contact: <sip:client@client.example.com;transport=tcp>; connectioId=1
;+sip.instance="<urn:uuid:00000000-0000-0000-0000-000A95A0E121>" ;+sip.instance="<urn:uuid:00000000-0000-0000-0000-00A95A0E121>"
Content-Length: 0 Content-Length: 0
This results in the path header being stored along with the AOR and This results in the Path header being stored along with the AOR and
it's associated binding at the Registrar. The URI contained in the it's associated binding at the Registrar. The URI contained in the
PATH will be inserted as a pre-loaded SIP 'Route' header into any Path header will be inserted as a pre-loaded SIP 'Route' header into
request that arrives at the Registrar and is directed towards the any request that arrives at the Registrar and is directed towards the
associated binding. This guarantees that all requests for the new associated binding. This guarantees that all requests for the new
Registration will be forwarded to the edge proxy. The user part of Registration will be forwarded to the edge proxy. The user part of
the SIP 'Path' header URI that was inserted by the edge proxy the SIP 'Path' header URI that was inserted by the edge proxy
contains an escaped form of the original AOR that was contained in contains an escaped form of the original AOR that was contained in
the REGISTER request. On receiving subsequent requests, the edge the REGISTER request. On receiving subsequent requests, the edge
proxy will examine the user part of the pre-loaded SIP 'route' header proxy will examine the user part of the pre-loaded SIP 'route' header
and extract the original AOR for use in it's connection tuple and extract the original AOR for use in its connection tuple
comparison, as defined in the connection re-use draft [9]. An comparison, as defined in the connection re-use draft [11]. An
example which will build on this scenario (showing an inbound request example which builds on this scenario (showing an inbound request to
to the AOR) is detailed in section 4.1.4.2 of this document. 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 | |
skipping to change at page 18, line 24 skipping to change at page 18, line 24
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 reponses to this request will not automatically pass back through
a NAT and so the SIP 'Via' header 'rport' is included as 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 [5]. 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 registration.
3. [Editors Note: TODO - Expand description of GRUU and connection 3. [Editors Note: TODO - Expand description of GRUU and connection
re-use] re-use]
4.1.3.2 Reliable Transport 4.1.3.2. Reliable Transport
[Editors note: TODO] [Editors note: TODO]
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 the NAT. These scenarios build on the
previous registration scenario from sections 4.1.1 and 4.1.2 in this previous registration scenario from sections 4.1.1 and 4.1.2 in this
document. 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 |
skipping to change at page 19, line 47 skipping to change at page 19, line 47
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 matches the registration binding at the Registrar and the
INVITE request-URI is re-written to the selected onward address. The INVITE request-URI is re-written to the selected onward address. The
proxy then examines the request URI of the INVITE and compares with proxy then examines the request URI of the INVITE and compares with
it's list of current open connections/mappings. It uses the incoming its list of current open connections/mappings. It uses the incoming
AOR to commence the check for associated open connections/mappings. AOR to commence the check for associated open connections/mappings.
Once matched, the proxy checks to see if the unique instance Once matched, the proxy checks to see if the unique instance
identifier (+sip.instance)associated with the binding equals the same identifier (+sip.instance) associated with the binding equals the
instance identifier associated with the binding. If more than one same instance identifier associated with the binding. If more than
results are matched, the lowest 'connectionID' Contact parameter will one result is matched, the lowest 'connectionID' Contact parameter
be used. This is message (2) from Figure 9 and is as follows: will be used. This is 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 connection/mapping associated with
the registration binding. This then allows the original the registration binding. This then allows the original connection/
connection/mapping from the initial registration process to be mapping from the initial registration process to be re-used.
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 4.2.1. Port Restricted Cone 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 a 'Restricted Cone' NAT. The examples have
been included to represent both 'Restricted' and 'Port Restricted' been included to represent both 'Restricted' and 'Port Restricted'
NAT media traversal. An example is included for both STUN and ICE NAT media traversal. An example is included for both STUN and ICE
with ICE being the RECOMENDED method. 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 a 'Restricted Cone NAT'
using STUN. using STUN.
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
'Restricted Cone' NAT using STUN. It is assumed in this example that 'Restricted Cone' NAT using STUN. It is assumed in this example that
the STUN client and SIP Client are co-located on the same machine. the STUN client and SIP Client are co-located on the same machine.
Note that some SIP signalling messages have been left out for Note that some SIP signalling messages have been left out for
simplicity. simplicity.
Client NAT STUN [..] Client NAT STUN [..]
Server Server
| | | | | | | |
skipping to change at page 23, line 39 skipping to change at page 23, line 39
a=rtcp:5608 a=rtcp:5608
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=1.2.3.4).
The Primary port for RTP is also inserted in the SDP (m=audio 5601 The Primary port for RTP is also inserted in the SDP (m=audio 5601
RTP/AVP 0). Finally, the port gained from the additional STUN RTP/AVP 0). Finally, the port gained from the additional STUN
binding is placed in the RTCP attribute (as discussed in binding is placed in the RTCP attribute (as discussed in
Section 3.2.5)for traversal of RTCP (a=rtcp:5608). Section 3.2.5)for traversal of RTCP (a=rtcp:5608).
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 this the 200 OK to the INVITE arrives at the client (12). Up until
point the incoming media will not pass through the NAT as no this 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.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 a 'Restricted Cone' NAT using STUN is very
similar to the example outlined in Section 4.2.1.1.1. Figure 20 similar to the example outlined in Section 4.2.1.1.1. Figure 20
illustrates the associated flow of messages. 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 | | |
skipping to change at page 25, line 20 skipping to change at page 25, line 20
starts a local STUN client. The STUN client generates a standard starts a local STUN client. The STUN client generates a standard
STUN request as indicated in (3) from Figure 20 which also STUN request as indicated in (3) from Figure 20 which also
highlights the source address and port for which the client device highlights the source address and port for which the client device
wishes to obtain a mapping. The STUN request is sent through the wishes to obtain a mapping. The STUN request is sent through the
NAT towards the public internet. NAT towards the public internet.
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
o The STUN server receives the request and processes appropriately. o The STUN server receives the request and processes it
This results in a successful STUN response being generated and appropriately. This results in a successful STUN response being
returned (5). The message contains details of the mapped public generated and returned (5). The message contains details of the
address (contained in the STUN MAPPED-ADDRESS attribute) which is mapped public address (contained in the STUN MAPPED-ADDRESS
to be used by the originating client to receive media (see 'map=' attribute) which is to be used by the originating client to
from (5)). receive media (see 'map=' 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 STUN request and presents the new mapped address to
the client (6). At this point the process is repeated to obtain a the client (6). At this point the process is repeated to obtain a
second mapped address (as shown in (7)-(10)) for an alternative second mapped address (as shown in (7)-(10)) for an alternative
local address (local port has now changed from 5301 to 5302 in local address (local port has now changed from 5301 to 5302 in
(7)). (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). 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 200 OK response will use in earlier sections of the document. The 200 OK response will use
the addresses it has obtained in the previous STUN transactions to the addresses it has obtained in the previous STUN transactions to
skipping to change at page 26, line 12 skipping to change at page 26, line 12
(m=audio 5601 RTP/AVP 0). Finally, the port gained from the (m=audio 5601 RTP/AVP 0). Finally, the port gained from the
additional binding is placed in the RTCP attribute (as discussed additional binding is placed in the RTCP attribute (as discussed
in Section 3.2.5)for traversal of RTCP (a=rtcp:5608). in Section 3.2.5)for traversal of RTCP (a=rtcp:5608).
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. The following examples illustrate the
traversal of a 'Port Restricted Cone' NAT for both an initiating and traversal of a 'Port Restricted Cone' NAT for both an initiating and
receiving client. The example only covers ICE in association with receiving client. The example only covers ICE in association with
STUN and TURN. STUN and TURN.
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 a
'Restricted Cone' NAT using ICE. 'Restricted Cone' NAT using ICE.
Client NAT STUN TURN [..] Client NAT STUN TURN *
Server Server Server Server
| | | | | | | | | |
|(1) STUN Req | | | | |(1) STUN Req | | | |
|src=10.0.1.1:5301 | | | | |src=10.0.1.1:5301 | | | |
|----------------->| | | | |----------------->| | | |
| |(2) STUN Req | | | | |(2) STUN Req | | |
| |src=1.2.3.4:5601 | | | | |src=1.2.3.4:5601 | | |
| |----------------->| | | | |----------------->| | |
| |(3) STUN Resp | | | | |(3) STUN Resp | | |
| |<-----------------| | | | |<-----------------| | |
skipping to change at page 27, line 15 skipping to change at page 27, line 15
| |dest=1.2.3.4:5611 | | | | |dest=1.2.3.4:5611 | | |
|(8) STUN Resp | | | | |(8) STUN Resp | | | |
|<-----------------| | | | |<-----------------| | | |
|map=1.2.3.4:5611 | | | | |map=1.2.3.4:5611 | | | |
|dest=10.0.1.1:5311| | | | |dest=10.0.1.1:5311| | | |
|(9) TURN Allocate | | | | |(9) TURN Allocate | | | |
|src=10.0.1.1:5302 | | | | |src=10.0.1.1:5302 | | | |
|----------------->| | | | |----------------->| | | |
| |(10) TURN Allocate| | | | |(10) TURN Allocate| | |
| |src=1.2.3.4:5608 | | | | |src=1.2.3.4:5608 | | |
| |------------------------------------>| | | |----------------------------------->| |
| |(11) TURN Resp | | | | |(11) TURN Resp | | |
| |<------------------------------------| | | |<-----------------------------------| |
| |map=1.2.3.4:5608 | | | | |map=2.3.4.5:5608 | | |
| |dest=1.2.3.4:5608 | | | | |dest=1.2.3.4:5608 | | |
|(12) TURN Resp | | | | |(12) TURN Resp | | | |
|<-----------------| | | | |<-----------------| | | |
|map=1.2.3.4:5608 | | | | |map=1.2.3.4:5608 | | | |
|dest=10.0.1.1:5302| | | | |dest=10.0.1.1:5302| | | |
|(13) TURN Allocate| | | | |(13) TURN Allocate| | | |
|src=10.0.1.1:5312 | | | | |src=10.0.1.1:5312 | | | |
|----------------->| | | | |----------------->| | | |
| |(14) TURN Allocate| | | | |(14) TURN Allocate| | |
| |src=1.2.3.4:5618 | | | | |src=1.2.3.4:5618 | | |
| |------------------------------------>| | | |----------------------------------->| |
| |(15) TURN Resp | | | | |(15) TURN Resp | | |
| |<------------------------------------| | | |<-----------------------------------| |
| |map=1.2.3.4:5618 | | | | |map=2.3.4.5:5618 | | |
| |dest=1.2.3.4:5618 | | | | |dest=1.2.3.4:5618 | | |
|(16) TURN Resp | | | | |(16) TURN Resp | | | |
|<-----------------| | | | |<-----------------| | | |
|map=1.2.3.4:5618 | | | | |map=1.2.3.4:5618 | | | |
|dest=10.0.1.1:5312| | | | |dest=10.0.1.1:5312| | | |
|(17)SIP INVITE | | | | |(17)SIP INVITE | | | |
|----------------->| | | | |----------------->| | | |
| |(18)SIP INVITE | | | | |(18)SIP INVITE | | |
| |-------------------------------------------->| | |------------------------------------------->|
| | |(19)SIP 200 OK | | | | |(19)SIP 200 OK | |
| |<--------------------------------------------| | |<-------------------------------------------|
|(20)SIP 200 OK | | | | |(20)SIP 200 OK | | | |
|<-----------------| | | | |<-----------------| | | |
|(21)STUN Req | | | | |(21)STUN Req | | | |
|----------------->| | | | |----------------->| | | |
| |(22) STUN Req | | | | |(22) STUN Req | | |
| |-------------------------------------------->| | |------------------------------------------->|
| | |(23)STUN Resp | | | | |(23)STUN Resp | |
| |<--------------------------------------------| | |<-------------------------------------------|
|(24)STUN Resp | | | | |(24)STUN Resp | | | |
|<-----------------| | | | |<-----------------| | | |
|================================================================| |===============================================================|
|>>>>>>>>>>>Outgoing Media sent from 10.1.1.1:5301>>>>>>>>>>>>>>>| |>>>>>>>>>>>Outgoing Media sent from 10.1.1.1:5301>>>>>>>>>>>>>>|
|================================================================| |===============================================================|
| | |(25) STUN Req | | | | |(25) STUN Req | |
| |<--------------------------------------------| | |<-------------------------------------------|
|(26)STUN Req | | | | |(26)STUN Req | | | |
|<-----------------| | | | |<-----------------| | | |
|(27)STUN Resp | | | | |(27)STUN Resp | | | |
|----------------->| | | | |----------------->| | | |
| | |(28)STUN Resp | | | | |(28)STUN Resp | |
| |-------------------------------------------->| | |------------------------------------------->|
|================================================================| |===============================================================|
|<<<<<<<<<<<Incoming Media sent to 1.2.3.4:5601<<<<<<<<<<<<<<<<<<| |<<<<<<<<<<<Incoming Media sent to 1.2.3.4:5601<<<<<<<<<<<<<<<<<|
|================================================================| |===============================================================|
|(29)SIP ACK | | | | |(29)SIP ACK | | | |
|----------------->| | | | |----------------->| | | |
| |(30) SIP ACK | | | | |(30) SIP ACK | | |
| |-------------------------------------------->| | |------------------------------------------->|
| | | | | | | | | |
Figure 22: Restricted NAT with ICE - Initiating Figure 22: Restricted NAT with ICE - Initiating
o On deciding to initiate a SIP voice session the VOIP client starts o On deciding to initiate a SIP voice session the VOIP client starts
a local STUN and TURN client. The STUN client generates a a local STUN and TURN client. The STUN client generates a
standard STUN request as indicated in (1) from Figure 22 which standard STUN request as indicated in (1) from Figure 22 which
also highlights the source address and port for which the client also highlights the source address and port for which the client
device wishes to obtain a mapping. The STUN request is sent device wishes to obtain a mapping. The STUN request is sent
through the NAT towards the public internet. through the NAT towards the public internet.
skipping to change at page 28, line 49 skipping to change at page 28, line 49
o The STUN server receives the request and processes appropriately. o The STUN server receives the request and processes appropriately.
This results in a successful STUN response being generated and This results in a successful STUN response being generated and
returned (3). The message contains details of the mapped public returned (3). The message contains details of the mapped public
address (contained in the STUN MAPPED-ADDRESS attribute) which is address (contained in the STUN MAPPED-ADDRESS attribute) which is
to be used by the originating client to receive media (see 'map=') to be used by the originating client to receive media (see 'map=')
from (3)). 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). The process is repeated and a second STUN derived the client (4). The process is repeated and a second STUN derived
address is obtained, as illustrated in (5)-(8) in Figure 22. address is obtained, as illustrated in (5)-(8) in Figure 22.
While the STUN client is obtaining addresses', the TURN client While the STUN client is obtaining addresses, the TURN client will
will also be attempting to obtain external representations. The also be attempting to obtain external representations. The TURN
TURN Allocate message is constructed in association with the local Allocate message is constructed in association with the local IP
IP address and port combination(9). The TURN Allocate message is address and port combination (9). The TURN Allocate message is
then sent from the client to the external TURN server via the then sent from the client to the external TURN server via the NAT
NAT(10). The TURN server processes the Allocate request and (10). The TURN server processes the Allocate request and returns
returns an appropriate response(11). The response contains the an appropriate response(11). The response contains the 'Mapped-
'Mapped-Address'(defined in STUN specification) attribute which Address'(defined in STUN specification) attribute which contains
contains the external representation that the TURN server will the external representation that the TURN server will provide for
provide for the internal mapping. The TURN response then the internal mapping. The TURN response then traverses back
traverses back through NAT and returns the newly allocated through the NAT and returns the newly allocated external
external representation to the originating client(12).The process representation to the originating client(12).The process is
is repeated and a second TURN derived address is obtained, as repeated and a second TURN derived address is obtained, as
illustrated in (13)-(16) in Figure 22. At this point the client illustrated in (13)-(16) in Figure 22. At this point the client
behind the NAT has a pair of STUN external representations and behind the NAT has a pair of STUN external representations and
TURN equivalents. The client would be free to gather any number TURN equivalents. The client would be free to gather any number
of external representations using any UNSAF[7] compliant protocol. of external representations using any UNSAF[9] compliant protocol.
o The client now constructs a SIP INVITE message(17). The INVITE 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[13], as shown below (*note - /* defined in the ICE specification[15], as shown below in Figure 23
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 10.0.1.1
c=IN IP4 1.2.3.4 c=IN IP4 1.2.3.4
t=0 0 t=0 0
m=audio 5601 RTP/AVP 0 m=audio 5601 RTP/AVP 0
a=candidate:H83jksd 1.0 rtp_uname_frag_1 rtp_pass_1 1.2.3.4 5601 a=candidate:H83jksd 1.0 rtp_uname_frag_1 rtp_pass_1 1.2.3.4 5601
/* rtcp_uname_frag_1 rtcp_pass_1 1.2.3.4 5611 /* rtcp_uname_frag_1 rtcp_pass_1 1.2.3.4 5611
a=candidate:Hye73hd 0.8 rtp_uname_frag_2 rtp_pass_2 1.2.3.4 5608 a=candidate:Hye73hd 0.8 rtp_uname_frag_2 rtp_pass_2 1.2.3.4 5608
/* rtcp_uname_frag_2 rtcp_pass_2 1.2.3.4 5618 /* rtcp_uname_frag_2 rtcp_pass_2 1.2.3.4 5618
a=candidate:H82hjjh 0.5 rtp_uname_frag_3 rtp_pass_3 1.2.3.4 5600 a=candidate:H82hjjh 0.5 rtp_uname_frag_3 rtp_pass_3 1.2.3.4 5600
Figure 23: ICE SDP
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 addresses that have been assembled. The first 'candidate' address
contains the two STUN derived addresses for both RTP and RTCP contains the two STUN derived addresses for both RTP and RTCP
traffic. This entry has been given the highest priority(1.0) by traffic. This entry has been given the highest priority(1.0) by
the client and also inserted as the default address. the client and also inserted as the default address.
o The second 'candidate' address contains the two TURN derived o The second 'candidate' address contains the two TURN derived
addresses for both RTP and RTCP traffic. This entry has been addresses for both RTP and RTCP traffic. This entry has been
given the second highest priority(0.8). given the second highest priority(0.8).
o The third and final 'candidate' address contains a local interface o The third and final 'candidate' address contains a local interface
address that has not been derived externally. This entry has been address that has not been derived externally. This entry has been
skipping to change at page 30, line 20 skipping to change at page 30, line 24
simplicity). On receiving a STUN response, the client is able to simplicity). On receiving a STUN response, the client is able to
stream media to the remote destination(*Note - if further STUN stream media to the remote destination(*Note - if further STUN
connectivity responses are received after the client has started connectivity responses are received after the client has started
streaming media with a higher priority, it will be used instead). streaming media with a higher priority, it will be used instead).
The remote destination will also carry out similar STUN The remote destination will also carry out similar STUN
connectivity checks (25)-(28) which then allows media to be connectivity checks (25)-(28) which then allows media to be
streamed to the client behind the NAT using the advertised streamed to the client behind the NAT using the advertised
connections. Two way audio is now possible between the two connections. Two way audio is now possible between the two
clients. clients.
4.2.1.2.2 Receiving Session Invitation 4.2.1.2.2. Receiving Session Invitation
This example is similar to that described in Section 4.2.1.2.1. The This example is similar to that described in Section 4.2.1.2.1. The
client behind a NAT is receiving the incoming ICE Initiate in a SIP client behind a NAT is receiving the incoming ICE Initiate in a SIP
INVITE request. INVITE request.
Client NAT STUN TURN [..] Client NAT STUN TURN *
Server Server 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=10.0.1.1:5301 | | | |
|----------------->| | | | |----------------->| | | |
| |(4) STUN Req | | | | |(4) STUN Req | | |
| |src=1.2.3.4:5601 | | | | |src=1.2.3.4:5601 | | |
| |----------------->| | | | |----------------->| | |
| |(5) STUN Resp | | | | |(5) STUN Resp | | |
skipping to change at page 31, line 20 skipping to change at page 31, line 23
| |map=1.2.3.4:5611 | | | | |map=1.2.3.4:5611 | | |
| |dest=1.2.3.4:5611 | | | | |dest=1.2.3.4:5611 | | |
|(10) STUN Resp | | | | |(10) STUN Resp | | | |
|<-----------------| | | | |<-----------------| | | |
|map=1.2.3.4:5611 | | | | |map=1.2.3.4:5611 | | | |
|dest=10.0.1.1:5311| | | | |dest=10.0.1.1:5311| | | |
|(11) TURN Allocate| | | | |(11) TURN Allocate| | | |
|src=10.0.1.1:5302 | | | | |src=10.0.1.1:5302 | | | |
|----------------->| | | | |----------------->| | | |
| |(12) TURN Allocate| | | | |(12) TURN Allocate| | |
| |src=1.2.3.4:5608 | | | | |src=2.3.4.5:5608 | | |
| |------------------------------------>| | | |------------------------------------>| |
| |(13) TURN Resp | | | | |(13) TURN Resp | | |
| |<------------------------------------| | | |<------------------------------------| |
| |map=1.2.3.4:5608 | | | | |map=2.3.4.5:5608 | | |
| |dest=1.2.3.4:5608 | | | | |dest=1.2.3.4:5608 | | |
|(14) TURN Resp | | | | |(14) TURN Resp | | | |
|<-----------------| | | | |<-----------------| | | |
|map=1.2.3.4:5608 | | | | |map=1.2.3.4:5608 | | | |
|dest=10.0.1.1:5302| | | | |dest=10.0.1.1:5302| | | |
|(15) TURN Allocate| | | | |(15) TURN Allocate| | | |
|src=10.0.1.1:5312 | | | | |src=10.0.1.1:5312 | | | |
|----------------->| | | | |----------------->| | | |
| |(16) TURN Allocate| | | | |(16) TURN Allocate| | |
| |src=1.2.3.4:5618 | | | | |src=1.2.3.4:5618 | | |
skipping to change at page 31, line 47 skipping to change at page 31, line 50
| |<------------------------------------| | | |<------------------------------------| |
| |map=1.2.3.4:5618 | | | | |map=1.2.3.4:5618 | | |
| |dest=1.2.3.4:5618 | | | | |dest=1.2.3.4:5618 | | |
|(18) TURN Resp | | | | |(18) TURN Resp | | | |
|<-----------------| | | | |<-----------------| | | |
|map=1.2.3.4:5618 | | | | |map=1.2.3.4:5618 | | | |
|dest=10.0.1.1:5312| | | | |dest=10.0.1.1:5312| | | |
|(19)SIP 200 OK | | | | |(19)SIP 200 OK | | | |
|----------------->| | | | |----------------->| | | |
| |(20)SIP 200 OK | | | | |(20)SIP 200 OK | | |
| |-------------------------------------------->| | |------------------------------------------->|
|(21)STUN Req | | | | |(21)STUN Req | | | |
|----------------->| | | | |----------------->| | | |
| |(22) STUN Req | | | | |(22) STUN Req | | |
| |-------------------------------------------->| | |------------------------------------------->|
| | |(23)STUN Resp | | | | |(23)STUN Resp | |
| |<--------------------------------------------| | |<-------------------------------------------|
|(24)STUN Resp | | | | |(24)STUN Resp | | | |
|<-----------------| | | | |<-----------------| | | |
|================================================================| |===============================================================|
|>>>>>>>>>>>Outgoing Media sent from 10.1.1.1:5301>>>>>>>>>>>>>>>| |>>>>>>>>>>>Outgoing Media sent from 10.1.1.1:5301>>>>>>>>>>>>>>|
|================================================================| |===============================================================|
| | |(25) STUN Req | | | | |(25) STUN Req | |
| |<--------------------------------------------| | |<-------------------------------------------|
|(26)STUN Req | | | | |(26)STUN Req | | | |
|<-----------------| | | | |<-----------------| | | |
|(27)STUN Resp | | | | |(27)STUN Resp | | | |
|----------------->| | | | |----------------->| | | |
| | |(28)STUN Resp | | | | |(28)STUN Resp | |
| |-------------------------------------------->| | |------------------------------------------->|
|================================================================| |===============================================================|
|<<<<<<<<<<<Incoming Media sent to 1.2.3.4:5601<<<<<<<<<<<<<<<<<<| |<<<<<<<<<<<Incoming Media sent to 1.2.3.4:5601<<<<<<<<<<<<<<<<<|
|================================================================| |===============================================================|
| | |(29)SIP ACK | | | | |(29)SIP ACK | |
| |<--------------------------------------------| | |<-------------------------------------------|
|(30)SIP ACK | | | | |(30)SIP ACK | | | |
|<-----------------| | | | |<-----------------| | | |
| | | | | | | | | |
Figure 24: Restricted NAT with ICE - Receiving Figure 24: Restricted NAT with ICE - Receiving
o As mentioned previously, this example is similar that described in o As mentioned previously, this example is similar to that described
Section 4.2.1.2.1. For this reason, some of the description may in Section 4.2.1.2.1. For this reason, some of the description
reference the previous example. The scenario starts with the may reference the previous example. The scenario starts with the
client behind the NAT receiving a SIP INVITE(1) request(ICE client behind the NAT receiving a SIP INVITE(1) reques (ICE
initiate message). initiate message).
o On receiving the SIP INVITE the client is able to collect all o On receiving the SIP INVITE the client is able to collect all
possible addresses available for media interaction (e.g. Local possible addresses available for media interaction (e.g. Local
addresses, STUN derived, TURN derived). See detail from addresses, STUN derived, TURN derived). See detail from
Section 4.2.1.2.1 for explanation on accumulating all possible Section 4.2.1.2.1 for explanation on accumulating all possible
media addresses (Steps (3)-(18) in Figure 24). media addresses (Steps (3)-(18) in Figure 24).
o The client will perform connectivity checks on all addresses o The client will perform connectivity checks on all addresses
received in the SIP INVITE message(21)-(24). Note that steps received in the SIP INVITE message(21)-(24). Note that steps
(21)-(24) will be repeated for every address offered in the SIP (21)-(24) will be repeated for every address offered in the SIP
INVITE request. This is not shown in the diagram for simplicity. INVITE request. This is not shown in the diagram for simplicity.
skipping to change at page 32, line 48 skipping to change at page 33, line 4
Section 4.2.1.2.1 for explanation on accumulating all possible Section 4.2.1.2.1 for explanation on accumulating all possible
media addresses (Steps (3)-(18) in Figure 24). media addresses (Steps (3)-(18) in Figure 24).
o The client will perform connectivity checks on all addresses o The client will perform connectivity checks on all addresses
received in the SIP INVITE message(21)-(24). Note that steps received in the SIP INVITE message(21)-(24). Note that steps
(21)-(24) will be repeated for every address offered in the SIP (21)-(24) will be repeated for every address offered in the SIP
INVITE request. This is not shown in the diagram for simplicity. INVITE request. This is not shown in the diagram for simplicity.
On receiving a response to a STUN connectivity check, the client On receiving a response to a STUN connectivity check, the client
will start streaming media(*Note - if further STUN connectivity will start streaming media(*Note - if further STUN connectivity
responses are received after the client has started streaming meda responses are received after the client has started streaming meda
with a higher priority, it will be used instead). with a higher priority, it will be used instead).
o The STUN connectivity checks will then occur in the opposite o The STUN connectivity checks will then occur in the opposite
direction, as illustrated in Section 4.2.1.2.1. A STUN server direction, as illustrated in Section 4.2.1.2.1. A STUN server
running on each advertised address will respond to incoming STUN running on each advertised address will respond to incoming STUN
connectivity requests(25)-(28). connectivity requests(25)-(28).
o Bi-directional audio can now occur between the two clients. o Bi-directional audio can now occur between the two clients.
4.2.2 Symmetric NAT 4.2.2. Symmetric 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 cases. The use of STUN
on its own will not guarantee traversal through every NAT type, hence on its own will not guarantee traversal through every NAT type, hence
the recommendation that ICE be the preffered option. the recommendation that ICE be the prefered option.
Client SYMMETRIC STUN [..] Client SYMMETRIC STUN [..]
NAT Server NAT Server
| | | | | | | |
|(1) STUN Req | | | |(1) STUN Req | | |
|src=10.0.1.1:5301 | | | |src=10.0.1.1:5301 | | |
|----------------->| | | |----------------->| | |
| |(2) STUN Req | | | |(2) STUN Req | |
| |src=1.2.3.4:5601 | | | |src=1.2.3.4:5601 | |
| |----------------->| | | |----------------->| |
skipping to change at page 34, line 34 skipping to change at page 35, line 22
For any internal IP address and port mapping, data sent to For any internal IP address and port mapping, data sent to
different external addresses does not provide the same public different external addresses does not provide the same public
mapping at the NAT. In Figure 25 the STUN query produced a valid mapping at the NAT. In Figure 25 the STUN query produced a valid
external mapping. This mapping, however, can only be used in the external mapping. This mapping, however, can only be used in the
context of the original STUN request that was sent to the STUN context of the original STUN request that was sent to the STUN
server. Any packets that attempt to use the mapped address, that server. Any packets that attempt to use the mapped address, that
does not come from the STUN server IP address and port, will be does not come from the STUN server IP address and port, will be
dropped at the NAT. Figure 25 shows the media being dropped at dropped at the NAT. Figure 25 shows the media being dropped at
the NAT after (8). the NAT after (8).
4.2.2.2 TURN Solution 4.2.2.2. TURN 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 for the
traversal of the majority of NATs but fails with symmetric type NAT. traversal of the majority of NATs but fails with symmetric type NAT.
This led to the development of the TURN solution[11] which introdcues This led to the development of the TURN solution[13] which introduces
a media relay in the path for NAT traversal (as described in a media relay in the path for NAT traversal (as described in
Section 3.2.3). The following example explains how TURN solves the Section 3.2.3). The following example explains how TURN solves the
previous failure when using STUN to traverse a symmetric NAT. previous failure when using STUN to traverse a symmetric NAT.
Client SYMMETRIC TURN [..] Client SYMMETRIC TURN [..]
NAT Server NAT Server
| | | | | | | |
|(1) TURN Allocate | | | |(1) TURN Allocate | | |
|src=10.0.1.1:5301 | | | |src=10.0.1.1:5301 | | |
|----------------->| | | |----------------->| | |
skipping to change at page 35, line 39 skipping to change at page 36, line 46
| | |==================| | | |==================|
|=====================================| | |=====================================| |
|<Incoming Media Sent to 1.2.3.4:5601<| | |<Incoming Media Sent to 1.2.3.4:5601<| |
|=====================================| | |=====================================| |
|(9)SIP ACK | | | |(9)SIP ACK | | |
|----------------->| | | |----------------->| | |
| |(10) SIP ACK | | | |(10) SIP ACK | |
| |------------------------------------>| | |------------------------------------>|
| | | | | | | |
Figure 26: Symmetric NAT with STUN - Failure Figure 26: Symmetric NAT with TURN - Success
o The client obtains a TURN derived address by issuing TURN allocate o The client obtains a TURN derived address by issuing a TURN
request(1). The request traverses through the symmetric NAT and allocate request(1). The request traverses through the symmetric
reaches the TURN server (2). The Turn server generates a response NAT and reaches the TURN server (2). The Turn server generates a
that contains an external representation. The representation maps response that contains an external representation. The
to an address mapping on the TURN server which is bound to the representation maps to an address mapping on the TURN server which
public pin hole in the NAT, opened by the TURN request. This is bound to the public pin hole in the NAT, opened by the TURN
results in any traffic being sent to the TURN server request. This results in any traffic being sent to the TURN
representation (2.3.4.5:5601) will be redirected to the external server representation (2.3.4.5:5601) will be redirected to the
representation of the pin hole created by the TURN external representation of the pin hole created by the TURN
request(1.2.3.4:5601). request(1.2.3.4:5601).
o The TURN derived address (2.3.4.5:5601) arrives back at the o The TURN derived address (2.3.4.5:5601) arrives back at the
originating client(4). This address can then be used in the SDP originating client(4). This address can then be used in the SDP
for the outgoing SIP INVITE request as shown below (note that the for the outgoing SIP INVITE request as shown below (note that the
RTCP attribute would have been obtained by another TURN derived RTCP attribute would have been obtained by another TURN derived
address which is not shown in the call flow for simplicity):- address which is not shown in the call flow for simplicity):
o o
v=0 v=0
o=test 2890844342 2890842164 IN IP4 10.0.1.1 o=test 2890844342 2890842164 IN IP4 10.0.1.1
c=IN IP4 2.3.4.5 c=IN IP4 2.3.4.5
t=0 0 t=0 0
m=audio 5601 RTP/AVP 0 m=audio 5601 RTP/AVP 0
a=rtcp:5608 a=rtcp:5608
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
skipping to change at page 36, line 31 skipping to change at page 37, line 36
Figure 26, the media from the UAS is directed to the TURN derived Figure 26, the media from the UAS is directed to the TURN derived
address at the TURN server. The TURN server then redirects the address at the TURN server. The TURN server then redirects the
traffic to the open pin hole in the symmetric NAT(1.2.3.4:5601). traffic to the open pin hole in the symmetric NAT(1.2.3.4:5601).
The media traffic is then able to traverse the symmetric NAT and The media traffic is then able to traverse the symmetric NAT and
arrives back at the client. arrives back at the client.
o The TURN solution on its own will work for Symmetric and other o The TURN solution on its own will work for Symmetric and other
types of NAT mentioned in this specification but should only be types of NAT mentioned in this specification but should only be
used as a last resort. The relaying of media through an external used as a last resort. The relaying of media through an external
entity is not an efficient mechanism for all NAT traversal. entity is not an efficient mechanism for all NAT traversal.
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 STUN for all forms of NAT traversal and a solution using TURN for the
symmetric NAT case. As mentioned previously in this document, the symmetric NAT case. As mentioned previously in this document, the
RECOMMENDED mechanism for traversing all varieties of NAT is using RECOMMENDED mechanism for traversing all varieties of NAT is using
ICE, as detailed in Section 3.2.4. Ice maked use of STUN, TURN and ICE, as detailed in Section 3.2.4. Ice makes use of STUN, TURN and
any other UNSAF [7] compliant protocol to provide a list of any other UNSAF [9] compliant protocol to provide a list of
prioritised addresses that can be used for media traffic. Detailed prioritised addresses that can be used for media traffic. Detailed
examples of ICE can be found in Section 4.2.1.2.1 and in examples of ICE can be found in Section 4.2.1.2.1 and in
Section 4.2.1.2.2. These examples are associated with a 'Port Section 4.2.1.2.2. These examples are associated with a 'Port
Restricted' type NAT but can be applied to any NAT type variation, Restricted' type NAT but can be applied to any NAT type variation,
including 'Symmetric' type NAT. The procedures are the same and of including 'Symmetric' type NAT. The procedures are the same and of
the list of candidate addresses, a client will choose where to send the list of candidate addresses, a client will choose where to send
media dependant on the results of the STUN connectivity checks on media dependant on the results of the STUN connectivity checks on
each candidate address and the associated priority (highest priority each candidate address and the associated priority (highest priority
wins). For more information see the core ICE specificagtion[13] wins). For more information see the core ICE specification[15]
4.3 Advanced NAT media Traversal Using ICE 4.3. Advanced NAT media Traversal Using ICE
4.3.1 Full Cone --> Full Cone traversal 4.3.1. Full Cone --> Full Cone traversal
4.3.1.1 Without NAT 4.3.1.1. Without NAT
4.3.1.1.1 Initiating Session 4.3.1.1.1. Initiating Session
4.3.1.1.2 Receiving Session Invitation 4.3.1.1.2. Receiving Session Invitation
4.3.1.2 With NAT 4.3.1.2. With NAT
4.3.1.2.1 Initiating Session 4.3.1.2.1. Initiating Session
4.3.1.2.2 Receiving Session Invitation 4.3.1.2.2. Receiving Session Invitation
4.3.2 Port Restricted Cone --> Port Restricted Cone traversal 4.3.2. Port Restricted Cone --> Port Restricted Cone traversal
4.3.2.1 Without NAT 4.3.2.1. Without NAT
4.3.2.1.1 Initiating Session 4.3.2.1.1. Initiating Session
4.3.2.1.2 Receiving Session Invitation 4.3.2.1.2. Receiving Session Invitation
4.3.2.2 With NAT 4.3.2.2. With NAT
4.3.2.2.1 Initiating Session 4.3.2.2.1. Initiating Session
4.3.2.2.2 Receiving Session Invitation 4.3.2.2.2. Receiving Session Invitation
4.3.3 Internal TURN Server (Enterprise Deployment) 4.3.3. Internal TURN Server (Enterprise Deployment)
4.3.3.1 Peer in same Enterprise 4.3.3.1. Peer in same Enterprise
4.3.3.2 Peer in same Enterprise - Separated by NAT 4.3.3.2. Peer in same Enterprise - Separated by NAT
4.3.3.3 Peer outside Enterprise 4.3.3.3. Peer outside Enterprise
4.4 Intercepting Intermediary (B2BUA) 4.4. Intercepting Intermediary (B2BUA)
4.5 IPV4/IPV6 4.5. IPv4-IPv6 Transition
4.6 ICE with RTP/TCP This section describes how IPv6-only SIP user agents can communicate
with IPv4-only SIP user agents.
5. References 4.5.1. IPv4-IPv6 Transition for SIP Signalling
5.1 Normative References IPv4-IPv6 translations at the SIP level usually take place at dual-
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
SIP entities, they fall outside the scope of this document. A
detailed description of this type of translation can be found in [18]
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 4.5.2. IPv4-IPv6 Transition for Media
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Figure 28 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
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
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
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
Figure 29 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
provide both IPv4 and IPv6 addresses for a particular media stream.
+----------+
| / \ |
/SIP \
/Phone \
/ \
------------
IPv4 Network
192.0.2.0/8
+---------+
| |
----------------------| NAT |--------------------------
| |
+---------+
IPv6 Network
++
||
+-----++
| IPv6 |
| SIP |
| user |
| agent|
+------+
Figure 28: IPv6-IPv4 transition scenario
IPv6 SIP TURN IPv4 SIP
User Agent Server User Agent
| | |
| (1) TURN Allocate | |
| src=[2001:DB8::1]:30000 | |
|------------------------------------>| |
| (2) TURN Resp | |
| map=192.0.2.2:25000 | |
| dest=[2001:DB8::1]:30000 | |
|<------------------------------------| |
| (3) SIP INVITE | |
|------------------------------------------------------->|
| (4) SIP 200 OK | |
|<-------------------------------------------------------|
| | |
|=====================================| |
|>>>>>>>>>> Outgoing Media >>>>>>>>>>>| |
|=====================================| |
| |==================|
| |>>>>>> Media >>>>>|
| |==================|
| | |
| |==================|
| |<<<<<< Media <<<<<|
| |==================|
|=====================================| |
|<<<<<<<<<< Outgoing Media <<<<<<<<<<<| |
|=====================================| |
| | |
| (5) SIP ACK | |
|------------------------------------------------------->|
| | |
Figure 29: IPv6-IPv4 translation with TURN
o The IPv6 SIP user agent obtains a TURN-derived IPv4 address by
issuing a TURN allocate request (1). The TURN server generates a
response that contains the public IPv4 address. This IPv4 address
maps to the IPv6 source address of the TURN allocate request,
which the IPv6 address of the SIP user agent. This results in any
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
SIP user agent ([2001:DB8::1]:30000).
o The TURN-derived address (192.0.2.2:25000) arrives back at the
originating user agent (2). This address can then be used in the
SDP for the outgoing SIP INVITE request. The user agent builds
two media lines, one with its IPv6 address and the other with the
IPv4 address that was just obtained. The user agent groups both
media lines using the ANAT semantics as shown below (note that the
RTCP attribute in the IPv4 media line would have been obtained by
another TURN-derived address which is not shown in the call flow
for simplicity).
v=0
o=test 2890844342 2890842164 IN IP6 2001:DB8::1
t=0 0
a=group:ANAT 1 2
m=audio 20000 RTP/AVP 0
c=IN IP6 2001:DB8::1
a=mid:1
m=audio 25000 RTP/AVP 0
c=IN IP4 192.0.2.2
a=rtcp:25001
a=mid:2
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
starts sending media to the IPv4 address in the offer. The IPv6
user agent sends media through the relay as well, as shown in
Figure 29.
4.6. ICE with RTP/TCP
TODO
5. Acknowledgments
The authors would like to thank the members of the IETF SIPPING WG
for their comments and suggestions. Detailed comments were provided
by Francois Audet, kaiduan xie and Hans Persson.
6. References
6.1. Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
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
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [4] Tsirtsis, G. and P. Srisuresh, "Network Address Translation -
Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
[5] Rosenberg, J. and H. Schulzrinne, "An Extension to the Session [6] Rosenberg, J. and H. Schulzrinne, "An Extension to the Session
Initiation Protocol (SIP) for Symmetric Response Routing", Initiation Protocol (SIP) for Symmetric Response Routing",
RFC 3581, August 2003. RFC 3581, August 2003.
[6] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) [7] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
Extension Header Field for Registering Non-Adjacent Contacts", Extension Header Field for Registering Non-Adjacent Contacts",
RFC 3327, December 2002. RFC 3327, December 2002.
[7] Daigle, L. and IAB, "IAB Considerations for UNilateral [8] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne,
Self-Address Fixing (UNSAF) Across Network Address "Grouping of Media Lines in the Session Description Protocol
Translation", RFC 3424, November 2002. (SDP)", RFC 3388, December 2002.
[8] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - [9] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-
Simple Traversal of User Datagram Protocol (UDP) Through Address Fixing (UNSAF) Across Network Address Translation",
RFC 3424, November 2002.
[10] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN
- Simple Traversal of User Datagram Protocol (UDP) Through
Network Address Translators (NATs)", RFC 3489, March 2003. Network Address Translators (NATs)", RFC 3489, March 2003.
[9] Jennings, C. and A. Hawrylyshen, "SIP Conventions for [11] Jennings, C. and A. Hawrylyshen, "SIP Conventions for UAs with
Connection Usage", Outbound Only Connections", draft-jennings-sipping-outbound-01
Internet-Draft draft-jennings-sipping-outbound-00, October (work in progress), February 2005.
2004.
[10] Rosenberg, J., "Obtaining and Using Globally Routable User [12] 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)", Internet-Draft draft-ietf-sip-gruu-02, July 2004. (SIP)", draft-ietf-sip-gruu-03 (work in progress),
February 2005.
[11] Rosenberg, J., "Traversal Using Relay NAT (TURN)", [13] Rosenberg, J., "Traversal Using Relay NAT (TURN)",
Internet-Draft draft-rosenberg-midcom-turn-06, October 2004. draft-rosenberg-midcom-turn-07 (work in progress),
February 2005.
[12] Wing, D., "Symmetric RTP and RTCP Considered Helpful", [14] Wing, D., "Symmetric RTP and RTCP Considered Helpful",
Internet-Draft draft-wing-mmusic-symmetric-rtprtcp-01, October draft-wing-mmusic-symmetric-rtprtcp-01 (work in progress),
2004. October 2004.
[13] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A [15] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for Methodology for Network Address Translator (NAT) Traversal for
Multimedia Session Establishment Protocols", Multimedia Session Establishment Protocols",
Internet-Draft draft-ietf-mmusic-ice-03, October 2004. draft-ietf-mmusic-ice-04 (work in progress), February 2005.
[14] Rosenberg, J., "Simple Traversal of UDP Through Network Address [16] Rosenberg, J., "Simple Traversal of UDP Through Network Address
Translators (NAT) (STUN)", Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-01
Internet-Draft draft-ietf-behave-rfc3489bis-00, October 2004. (work in progress), February 2005.
5.2 Informative References [17] Camarillo, G., "The Alternative Network Address Types Semantics
(ANAT) for theSession Description Protocol (SDP) Grouping
Framework", draft-ietf-mmusic-anat-02 (work in progress),
October 2004.
6.2. Informative References
[18] Camarillo, G., "IPv6 Transcition in the Session Initiation
Protocol (SIP)", draft-camarillo-sipping-v6-transition-00 (work
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
Email: cboulton@ubiquitysoftware.com Email: cboulton@ubiquitysoftware.com
Jonathan Rosenberg Jonathan Rosenberg
Cisco Systems Cisco Systems
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany, NJ 07054 Parsippany, NJ 07054
Email: jdrosen@dynamicsoft.com Email: jdrosen@cisco.com
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: Gonzalo.Camarillo@ericsson.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 40, line 41 skipping to change at page 45, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 185 change blocks. 
338 lines changed or deleted 501 lines changed or added

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