draft-ietf-sipping-nat-scenarios-07.txt   draft-ietf-sipping-nat-scenarios-08.txt 
SIPPING Working Group C. Boulton, Ed. SIPPING Working Group C. Boulton, Ed.
Internet-Draft Ubiquity Software Corporation Internet-Draft Avaya
Expires: January 10, 2008 J. Rosenberg Expires: October 27, 2008 J. Rosenberg
Cisco Systems Cisco Systems
G. Camarillo G. Camarillo
Ericsson Ericsson
July 9, 2007 April 25, 2008
Best Current Practices for NAT Traversal for SIP Best Current Practices for NAT Traversal for SIP
draft-ietf-sipping-nat-scenarios-07 draft-ietf-sipping-nat-scenarios-08
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 10, 2008. This Internet-Draft will expire on October 27, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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 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. Re-use of Connections . . . . . . . . . . . . . . . . 8
3.2. Media Traversal . . . . . . . . . . . . . . . . . . . . . 8 3.2. Media Traversal . . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Symmetric RTP . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . 9
3.2.2. STUN . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.2. STUN . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.3. TURN . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.3. TURN . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.4. ICE . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.4. ICE . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.5. Solution Profiles . . . . . . . . . . . . . . . . . . 10 3.2.5. Solution Profiles . . . . . . . . . . . . . . . . . . 11
4. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . . . 11 4. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . . . 12
4.1. Basic NAT SIP Signaling Traversal . . . . . . . . . . . . 11 4.1. Basic NAT SIP Signaling Traversal . . . . . . . . . . . . 12
4.1.1. Registration (Registrar/Proxy Co-Located) . . . . . . 11 4.1.1. Registration (Registrar/Proxy Co-Located) . . . . . . 12
4.1.2. Registration(Registrar/Proxy not Co-Located) . . . . . 15 4.1.2. Registration(Registrar/Proxy not Co-Located) . . . . . 16
4.1.3. Initiating a Session . . . . . . . . . . . . . . . . . 18 4.1.3. Initiating a Session . . . . . . . . . . . . . . . . . 19
4.1.4. Receiving an Invitation to a Session . . . . . . . . . 20 4.1.4. Receiving an Invitation to a Session . . . . . . . . . 21
4.2. Basic NAT Media Traversal . . . . . . . . . . . . . . . . 23 4.2. Basic NAT Media Traversal . . . . . . . . . . . . . . . . 26
4.2.1. Endpoint Independent NAT . . . . . . . . . . . . . . . 24 4.2.1. Endpoint Independent NAT . . . . . . . . . . . . . . . 27
4.2.2. Address and Port Dependant NAT . . . . . . . . . . . . 43 4.2.2. Address and Port Dependant NAT . . . . . . . . . . . . 47
5. IPv4-IPv6 Transition . . . . . . . . . . . . . . . . . . . . . 51 5. IPv4-IPv6 Transition . . . . . . . . . . . . . . . . . . . . . 55
5.1. IPv4-IPv6 Transition for SIP Signaling . . . . . . . . . . 51 5.1. IPv4-IPv6 Transition for SIP Signaling . . . . . . . . . . 55
5.2. IPv4-IPv6 Transition for Media . . . . . . . . . . . . . . 51 5.2. IPv4-IPv6 Transition for Media . . . . . . . . . . . . . . 56
6. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . 54 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 7.1. Normative References . . . . . . . . . . . . . . . . . . . 58
8.1. Normative References . . . . . . . . . . . . . . . . . . . 54 7.2. Informative References . . . . . . . . . . . . . . . . . . 61
8.2. Informative References . . . . . . . . . . . . . . . . . . 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 Intellectual Property and Copyright Statements . . . . . . . . . . 62
Intellectual Property and Copyright Statements . . . . . . . . . . 58
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 complex problem when considered in the context of the Session
Initiation Protocol (SIP)[1] and it's associated media such as Real Initiation Protocol (SIP)[RFC3261] and it's associated media such as
Time Protocol (RTP)[2]. The problem is further confused by the Real Time Protocol (RTP)[RFC3550]. The problem is exacerbated by the
variety of NATs that are available in the market place today and the variety of NATs that are available in the market place today and the
large number of potential deployment scenarios. Detail of different large number of potential deployment scenarios. Detail of different
NAT behaviors can be found in 'NAT Behavioral Requirements for NAT behaviors can be found in 'NAT Behavioral Requirements for
Unicast UDP' [11]. Unicast UDP' [RFC4787].
The IETF has produced many specifications for the traversal of NAT, The IETF has been active on many specifications for the traversal of
including STUN, ICE, rport, symmetric RTP, TURN, SIP Outbound, SDP NAT, including STUN[I-D.ietf-behave-rfc3489bis],
attribute for RTCP, and others. These each represent a part of the ICE[I-D.ietf-mmusic-ice], symmetric response[RFC3581], symmetric
solution, but none of them gives the overall context for how the NAT RTP[RFC4961], TURN[I-D.ietf-behave-turn], SIP
traversal problem is decomposed and solved through this collection of Outbound[I-D.ietf-sip-outbound], SDP attribute for RTCP[RFC3605], and
specifications. This document serves to meet that need. others. These each represent a part of the solution, but none of
them gives the overall context for how the NAT traversal problem is
decomposed and solved through this collection of specifications.
This document serves to meet that need.
This document attempts to provide a definitive set of 'Best Common This document provides a definitive set of 'Best Common Practices' to
Practices' to demonstrate the traversal of SIP and its associated demonstrate the traversal of SIP and its associated media through NAT
media through NAT devices. The document does not propose any new devices. The document does not propose any new functionality but
functionality but does draw on existing solutions for both core SIP does draw on existing solutions for both core SIP signaling and media
signaling and media traversal (as defined in Section 3). traversal (as defined in Section 3).
The draft will be split into distinct sections as follows: The draft is 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 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
that both require attention - The core SIP signaling and associated that both require attention - The core SIP signaling and associated
media traversal. media traversal.
The core SIP signaling has a number of issues when traversing through The core SIP signaling has a number of issues when traversing through
NATs. NATs.
Firstly, the default operation for SIP response generation using Normal SIP response routing over UDP causes the response to be
unreliable protocols such as the Unicast Datagram Protocol (UDP) delivered to the source IP address specified in the topmost Via
results in responses generated at the User Agent Server (UAS) being header, or the "received" parameter of the topmost Via header. The
sent to the source address, as specified in either the SIP 'Via'
header or the 'received' parameter (as defined in RFC 3261 [1]). The
port is extracted from the SIP 'Via' header to complete the IP port is extracted from the SIP 'Via' header to complete the IP
address/port combination for returning the SIP response. While the address/port combination for returning the SIP response. While the
destination for the response is correct, the port contained in the destination for the response is correct, the port contained in the
SIP 'Via' header represents the listening port of the originating SIP 'Via' header represents the listening port of the originating
client and not the port representing the open pin hole on the NAT. client and 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 This results in responses being sent back to the NAT but to a port
that is likely not open for SIP traffic. The SIP response will then that is likely not open for SIP traffic. The SIP response will then
be dropped at the NAT. This is illustrated in Figure 1 which depicts be dropped at the NAT. This is illustrated in Figure 1 which depicts
a SIP response being returned to port 5060. a SIP response being returned to port 5060.
Private NAT Public Private NAT Public
Network | Network Network | Network
| |
| |
-------- SIP Request |open port 5650 -------- -------- SIP Request |open port 10923 --------
| |-------------------->--->-----------------------| | | |-------------------->--->-----------------------| |
| | | | | | | | | |
| Client | |port 5060 SIP Response | Proxy | | Client | |port 5060 SIP Response | Proxy |
| | x<------------------------| | | | x<------------------------| |
| | | | | | | | | |
-------- | -------- -------- | --------
| |
| |
| |
Figure 1 Figure 1: Failed Response
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 reverse provide a mechanism that allows new requests generated in the reverse
direction of the originating client to use the existing TCP direction of the originating client to use, for example, the existing
connection created between the client and the server during TCP connection created between the client and the server during
registration. This results in the registered contact address not registration. This results in the registered contact address not
being bound to the "connection" in the case of TCP. Requests are being bound to the "connection" in the case of TCP. Requests are
then blocked at the NAT, as illustrated in Figure 2. This problem then blocked at the NAT, as illustrated in Figure 2. This problem
also exists for unreliable transport protocols such as UDP where also exists for unreliable transport protocols such as UDP where
external NAT mappings need to be re-used to reach a SIP entity on the external NAT mappings need to be re-used to reach a SIP entity on the
private side of the network. private side of the network.
Private NAT Public Private NAT Public
Network | Network Network | Network
| |
skipping to change at page 5, line 20 skipping to change at page 5, line 20
| |-------------------->---<-----------------------| | | |-------------------->---<-----------------------| |
| | | | | | | | | |
| Client | |5060 INVITE (UAC 8015)| Proxy | | Client | |5060 INVITE (UAC 8015)| Proxy |
| | x<------------------------| | | | x<------------------------| |
| | | | | | | | | |
-------- | -------- -------- | --------
| |
| |
| |
Figure 2 Figure 2: Failed Request
In Figure 2 the original REGISTER request is sent from the client on In Figure 2 the original REGISTER request is sent from the client on
port 8023 and received on port 5060, establishing a reliable port 8023 and received on port 5060, establishing a reliable
connection and opening a pin-hole in the NAT. The generation of a connection and opening a pin-hole in the NAT. The generation of a
new request from the proxy results in a request destined for the new request from the proxy results in a request destined for the
registered entity (Contact IP address) which is not reachable from registered entity (Contact IP address) which is not reachable from
the public network. This results in the new SIP request attempting the public network. This results in the new SIP request attempting
to create a connection to a private network address. This problem to create a connection to a private network address. This problem
would be solved if the original connection was re-used. While this would be solved if the original connection was re-used. While this
problem has been discussed in the context of connection orientated problem has been discussed in the context of connection orientated
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 impact of connection reuse of connection
section 3 of this document is relevant for all SIP signaling, orientated transports (TCP, TLS, etc) is discussed in more detail in
regardless of the transport protocol. the connection reuse specification[I-D.ietf-sip-connect-reuse]. The
approach proposed for this problem in Section 3 of this document is
relevant for all SIP signaling, 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 may vary from a
drastically from a number seconds to hours. Pure SIP signaling can number seconds to hours. SIP signaling can not be relied upon to
not be relied upon to keep alive connections for a number of reasons. keep alive connections for the following two reasons. Firstly, SIP
Firstly, SIP entities can sometimes have no signaling traffic for entities can sometimes have no signaling traffic for long periods of
long periods of time which has the potential to exceed the inactivity time which has the potential to exceed the inactivity timer, and this
timer, and this can lead to problems where endpoints are not can lead to problems where endpoints are not available to receive
available to receive incoming requests as the connection has been incoming requests as the connection has been closed. Secondly, if a
closed. Secondly, if a low inactivity timer is specified, SIP low inactivity timer is specified, SIP signaling is not appropriate
signaling is not appropriate as a keep-alive mechanism as it has the as a keep-alive mechanism as it has the potential to add a large
potential to add a large amount of traffic to the network which uses amount of traffic to the network which uses up valuable resource and
up valuable resource and also requires processing at a SIP stack, also requires processing at a SIP stack, which is also a waste of
which is also a waste of processing resources. 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 one of the most common media transport types used in SIP
signaling. Negotiation of RTP occurs with a SIP session RTP [RFC3550] is one of the most common media transport types used in
establishment using the Session Description Protocol(SDP) [3] and a SIP signaling. Negotiation of RTP occurs with a SIP session
SIP offer/answer exchange[5]. During a SIP offer/answer exchange an establishment using the Session Description Protocol(SDP) [RFC2327]
IP address and port combination are specified by each client in a and a SIP offer/answer exchange[RFC3264]. During a SIP offer/answer
session as a means of receiving media such as RTP. The problem exchange an IP address and port combination are specified by each
arises when a client advertises its address to receive media and it client in a session as a means of receiving media such as RTP. The
exists in a private network that is not accessible from outside the problem arises when a client advertises its address to receive media
NAT. Figure 3 illustrates this problem. and it exists in a private network that is not accessible from
outside the 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>==Unknown Address==>X | | B | | A |>=====>RTP>==Unknown Address==>X | | B |
| | | X<==Unknown Address==<RTP<===<| | | | | X<==Unknown Address==<RTP<===<| |
-------- | | -------- -------- | | --------
| | | |
| | | |
| | | |
Figure 3 Figure 3: Failed Media
The connection address representing both clients are not available on The connection addresses of the clients behind the NATs will
the public internet and traffic can be sent from both clients through nominally contain a private IPv4 or IPv6 address that is not routable
their NATs. The problem occurs when the traffic reaches the public across the public Internet. Exacerbating matters even more would be
internet and is not resolvable. The media traffic fails. The the tendency of Client A to send media to a destination address it
connection address extracted from the SDP payload is that of an received in the signaling confirmation message -- an address that may
internal address, and so not resolvable from the public side of the actually correspond to a host within the private network who is
NAT. To complicate the problem further, a number of different NAT suddenly faced with incoming RTP packets (likewise, Client B may send
topologies with different default behaviors increase the difficulty media to a host within its private network who did not solicit these
of proposing a single solution. packets.) And finally, to complicate the problem even further, a
number of different NAT topologies with different default behaviors
increases the difficulty of arriving at a single approach.
3. Solution Technology Outline Description 3. Solution Technology Outline Description
When analyzing issues associated with traversal of SIP through As mentioned previously, the traversal of SIP through existing NATs
existing NAT, it has been identified that the problem can be split can be divided into two discrete problem areas: getting the core
into two clear solution areas as defined in section 2 of this signaling across the NAT, and enabling media as specified by SDP in a
document. The traversal of the core protocol signaling and the SIP offer/answer exchange to flow between endpoints.
traversal of the associated media as specified in the Session
Description Payload (SDP) of a SIP offer/answer exchange[5]. The
following sub-sections outline solutions that enable core SIP
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 signaling traversal through NAT, regardless of transport in SIP signaling 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 [RFC3261]. Once the SIP response is constructed, the
is still derived using the mechanisms described in RFC 3261 [1]. The destination is still derived using the mechanisms described in RFC
port (to which the response will be sent), however, will not equal 3261 [RFC3261]. The port (to which the response will be sent),
that specified in the SIP 'Via' header field but will be the port however, will not equal that specified in the SIP 'Via' header field
from which the original request was sent. This results in the pin- but will be the port from which the original request was sent. This
hole opened for the requests traversal of the NAT being reused, in a results in the pin-hole opened for the requests traversal of the NAT
similar manner to that of reliable connection orientated transport being reused, in a similar manner to that of reliable connection
protocols such as TCP. Figure 4 illustrates the response traversal orientated transport protocols such as TCP. Figure 4 illustrates the
through the open pin hole using this method. response traversal through the open pin hole using this method.
Private NAT Public Private NAT Public
Network | Network Network | Network
| |
| |
-------- | -------- -------- | --------
| | | | | | | | | |
| |send/receive | send/receive| | | |send request---------------------------------->| |
| Client |port 5060-----<<->>---------<<->>-----port 5060| Client | | Client |<---------------------------------send response| Client |
| A | | | B | | A | | | B |
| | | | | | | | | |
-------- | -------- -------- | --------
| |
| |
| |
Figure 4 Figure 4: Symmetric Response
The exact functionality for this method of response traversal is The outgoing request from Client A opens a pin hole in the NAT.
called 'Symmetric Response' and the details are documented in RFC
3581 [6]. Additional requirements are imposed on SIP entities in
this specification such as listening and sending SIP requests/
responses from the same port.
3.1.2. Connection Re-use Client B would normally respond to the port available in the SIP Via
header, as illustrated in Figure 1. Client B honors the 'rport'
parameter in the SIP Via header and routes the response to port from
which it was sent. The exact functionality for this method of
response traversal is called 'Symmetric Response' and the details are
documented in RFC 3581 [RFC3581]. Additional requirements are
imposed on SIP entities in this specification such as listening and
sending SIP requests/responses from the same port.
3.1.2. Re-use of Connections
The second problem with sip signaling, as defined in Section 2 and The second problem with sip signaling, as defined in Section 2 and
illustrated in Figure 2, is to allow incoming requests to be properly illustrated in Figure 2, is to allow incoming requests to be properly
routed. routed.
Guidelines for devices such as User Agents that can only generate Guidelines for devices such as User Agents that can only generate
outbound connections through a NAT are documented in 'SIP Conventions outbound connections through a NAT are documented in 'SIP Conventions
for UAs with Outbound Only Connections'[13]. The document provides for UAs with Outbound Only Connections'[I-D.ietf-sip-outbound]. The
techniques that use a unique User Agent instance identifier document provides techniques that use a unique User Agent instance
(instance-id) in association with a flow identifier (Reg-id). The identifier (instance-id) in association with a flow identifier
combination of the two identifiers provides a key to a particular (reg-id). The combination of the two identifiers provides a key to a
connections (both UDP and TCP) that are stored in association with particular connections (both UDP and TCP) that are stored in
registration bindings. On receiving an incoming request to a SIP association with registration bindings. On receiving an incoming
Address-Of-Record (AOR), a proxy routes to the associated flow request to a SIP Address-Of-Record (AOR), a proxy/registrar routes to
created by the registration and thus a route through a NAT. It also the associated flow created by the registration and thus a route
provides a keepalive mechanism for clients to keep NAT bindings through a NAT. It also provides a keepalive mechanism for clients to
alive. This is achieved using peer-to-peer STUN multiplexed over the keep NAT bindings alive. This is achieved by multiplexing a relative
SIP signaling connection. Usage of this specification is ping/pong mechanism over the SIP signaling connection (STUN for UDP
RECOMMENDED. This mechanism is not transport specific and should be and CRLF/operating system keepalive for reliable transports like
used for any transport protocol. TCP). Usage of this specification is RECOMMENDED. This mechanism is
not transport specific and should be used for any transport protocol.
Even if the SIP Outbound draft is not used, clients generating SIP Even if the SIP Outbound draft is not used, clients generating SIP
requests SHOULD use the same IP address and port (i.e., socket) for requests SHOULD use the same IP address and port (i.e., socket) for
both transmission and receipt of SIP messages. Doing so allows for both transmission and receipt of SIP messages. Doing so allows for
the vast majority of industry provided solutions to properly the vast majority of industry provided solutions to properly
function. function. Deployments should also consider the mechanism described
in the Connection Reuse[I-D.ietf-sip-connect-reuse] specification for
routing bi-directional messages securely between trusted SIP Proxy
servers.
3.2. Media Traversal 3.2. Media Traversal
This document has already provided guidelines that recommend using This document has already provided guidelines that recommend using
extensions to the core SIP protocol to enable traversal of NATs. extensions to the core SIP protocol to enable traversal of NATs.
While ultimately not desirable, the additions are relatively straight While ultimately not desirable, the additions are relatively straight
forward and provide a simple, universal solution for varying types of forward and provide a simple, universal solution for varying types of
NAT deployment. The issues of media traversal through NATs is not NAT deployment. The issues of media traversal through NATs is not
straight forward and requires the combination of a number of straight forward and requires the combination of a number of
traversal methodologies. The technologies outlined in the remainder traversal methodologies. The technologies outlined in the remainder
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/RTCP
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/RTCP 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 RTCP traffic from the same IP Address/Port combination. This
also requires intelligence by a client on the public internet as it technique is known as 'Symmetric RTP/RTCP' and is documented in RFC
identifies that incoming media for a particular session does not 4961 [RFC4961]. 'Symmetric RTP/RTCP' SHOULD only solely be used for
match the information that was conveyed in the SDP. In this case the
client will ignore the SDP address/port combination and return RTP to
the IP address/port combination identified as the source of the
incoming media. This technique is known as 'Symmetric RTP' and is
documented in [15]. 'Symmetric RTP' SHOULD only be used for
traversal of RTP through NAT when one of the participants in a media traversal of RTP through NAT when one of the participants in a media
session definitively knows that it is on the public network. session definitively knows that it is on the public network.
3.2.1.1. RTCP Attribute 3.2.1.1. RTCP
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) [RFC3550] is for consecutive order numbering (i.e
incremented port for RTCP from that used for RTP). This assumption select an incremented port for RTCP from that used for RTP). This
causes RTCP traffic to break when traversing many NATs due to blocked assumption causes RTCP traffic to break when traversing many NATs due
ports. To combat this problem a specific address and port need to be to blocked ports. To combat this problem a specific address and port
specified in the SDP rather than relying on such assumptions. RFC need to be specified in the SDP rather than relying on such
3605 [6] defines an SDP attribute that is included to explicitly assumptions. RFC 3605 [RFC3605] defines an SDP attribute that is
specify transport connection information for RTCP. The address included to explicitly specify transport connection information for
details can be obtained using any appropriate method including those RTCP so a separate, explicit NAT binding can be set up for the
detailed previously in this section (e.g. STUN, TURN). purpose. The address details can be obtained using any appropriate
method including those detailed in this section (e.g. STUN, TURN,
ICE).
An alternative mechanism defined in [I-D.ietf-avt-rtp-and-rtcp-mux]
specifies 'muxing' both RTP and RTCP on the same IP/PORT combination.
Using this technique eliminates the problem and is RECOMENDED.
3.2.2. STUN 3.2.2. STUN
Simple Traversal of Underneath Network Address Translators(NAT) or Simple Traversal of Underneath Network Address Translators(NAT) or
STUN is defined in RFC 3489bis [10]. STUN is a lightweight tool kit STUN is defined in RFC 3489bis [I-D.ietf-behave-rfc3489bis]. STUN is
and protocol that provides details of the external IP address/port a lightweight tool kit and protocol that provides details of the
combination used by the NAT device to represent the internal entity external IP address/port combination used by the NAT device to
on the public facing side of a NAT. On learning of such an external represent the internal entity on the public facing side of a NAT. On
representation, a client can use it accordingly as the connection learning of such an external representation, a client can use it
address in SDP to provide NAT traversal. Using terminology defined accordingly as the connection address in SDP to provide NAT
in the draft 'NAT Behavioral Requirements for Unicast UDP' [11], STUN traversal. Using terminology defined in the draft 'NAT Behavioral
does work with 'Endpoint Independent Mapping' but does not work with Requirements for Unicast UDP' [RFC4787], STUN does work with
either 'Address Dependent Mapping' or 'Address and Port Dependent 'Endpoint Independent Mapping' but does not work with either 'Address
Mapping' type NATs. Using STUN with either of the previous two NAT Dependent Mapping' or 'Address and Port Dependent Mapping' type NATs.
mappings to probe for the external IP address/port representation Using STUN with either of the previous two NAT mappings to probe for
will provide a different result to that required for traversal by an the external IP address/port representation will provide a different
alternative SIP entity. The IP address/port combination deduced for result to that required for traversal by an alternative SIP entity.
the STUN server would be blocked for incoming packets from an The IP address/port combination deduced for the STUN server would be
alterative SIP entity. blocked for incoming packets from an alterative SIP entity.
As mentioned in Section 3.1.2, STUN is also used as a peer-to-peer As mentioned in Section 3.1.2, STUN is also used as a client-to-
keep-alive mechanism. server keep-alive mechanism to refresh NAT bindings.
3.2.3. TURN 3.2.3. TURN
As described in the previous section, the STUN protocol does not work As described in the Section 3.2.2, the STUN protocol does not work
for UDP traversal through certain identified NAT mappings. for UDP traversal through certain identified NAT mappings.
'Obtaining Relay Addresses from Simple Traversal of UDP Through NAT 'Obtaining Relay Addresses from Simple Traversal of UDP Through NAT
(known as TURN)' is a usage of the STUN protocol for deriving (from a (known as TURN)' is a usage of the STUN protocol for deriving (from a
STUN server) an address that will be used to relay packet towards a STUN server) an address that will be used to relay packet towards a
client. TURN provides an external address (globally routable) at a client. TURN provides an external address (globally routable) at a
STUN server that will act as a media relay which guarantees traffic STUN server that will act as a media relay which guarantees traffic
will reach the associated internal address. The full details of the will reach the associated internal address. The full details of the
TURN specification are defined in [12]. A TURN service will almost TURN specification are defined in [I-D.ietf-behave-turn]. A TURN
always provide media traffic to a SIP entity but it is RECOMMENDED service will almost always provide media traffic to a SIP entity but
that this method only be used as a last resort and not as a general it is RECOMMENDED that this method only be used as a last resort and
mechanism for NAT traversal. This is because using TURN has high not as a general mechanism for NAT traversal. This is because using
performance costs when relaying media traffic and can lead to TURN has high performance costs when relaying media traffic and can
unwanted latency. lead to unwanted latency.
3.2.4. ICE 3.2.4. ICE
Interactive Connectivity Establishment (ICE) is the RECOMMENDED Interactive Connectivity Establishment (ICE) is the RECOMMENDED
method for traversal of existing NAT if Symmetric RTP is not method for traversal of existing NAT if Symmetric RTP is not
appropriate. ICE is a methodology for using existing technologies appropriate. ICE is a methodology for using existing technologies
such as STUN, TURN and any other UNSAF[9] compliant protocol to such as STUN, TURN and any other UNSAF[RFC3424] 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 priority, transport. The appropriate IP address/port combinations
and a unique session ID. The appropriate IP address/port are used in the correct order depending on the specified priority. A
combinations are used in the correct order depending on the specified client compliant to the ICE specification will then locally run
priority. A client compliant to the ICE specification will then instances of STUN servers on all addresses being advertised using
locally run instances of STUN servers on all addresses being ICE. Each instance will undertake connectivity checks to ensure that
advertised using ICE. Each instance will undertake connectivity a client can successfully receive media on the advertised address.
checks to ensure that a client can successfully receive media on the Only connections that pass the relevant connectivity checks are used
advertised address. Only connections that pass the relevant for media exchange. The full details of the ICE methodology are
connectivity checks are used for media exchange. The full details of contained in [I-D.ietf-mmusic-ice].
the ICE methodology are contained in [16].
An extension to ICE is also available for TCP based media
interactions and is documented in 'TCP Candidates with Interactive
Connectivity Establishment (ICE)'[I-D.ietf-mmusic-ice-tcp].
3.2.5. Solution Profiles 3.2.5. Solution Profiles
This draft has documented a number of technology solutions for the This draft has documented a number of technology solutions for the
traversal of media through differing NAT deployments. A number of traversal of media through differing NAT deployments. A number of
'profiles' will now be defined that categorize varying levels of 'profiles' will now be defined that categorize varying levels of
support for the technologies described. support for the technologies described.
3.2.5.1. Primary Profile 3.2.5.1. Primary Profile
A client falling into the 'Primary' profile supports ICE in A client falling into the 'Primary' profile supports ICE in
conjunction with STUN, TURN usage and RFC 3605 [6] for RTCP. ICE is conjunction with STUN, TURN usage and RFC 3605 [RFC3605] and/or
used in all cases and falls back to standard operation when dealing [I-D.ietf-avt-rtp-and-rtcp-mux] for RTCP. ICE is used in all cases
with non-ICE clients. A client which falls into the 'Primary' and falls back to standard operation when dealing with non-ICE
profile will be maximally interoperable and function in a rich clients. A client which falls into the 'Primary' profile will be
variety of environments including enterprise, consumer and behind all maximally interoperable and function in a rich variety of
varieties of NAT. environments including enterprise, consumer and behind all varieties
of NAT.
It is RECOMMENDED that symmetric RTP and symmetric RTCP always be
used for bidirectional RTP media streams.
3.2.5.2. Consumer Profile 3.2.5.2. Consumer Profile
A client falling into the 'Consumer' profile supports STUN and RFC A client falling into the 'Consumer' profile supports STUN and RFC
3605 [6] for RTCP. It uses STUN to allocate bindings, and can also 3605 [RFC3605] and/or [I-D.ietf-avt-rtp-and-rtcp-mux] for RTCP. It
detect when it is in the unfortunate situation of being behind a uses STUN to allocate bindings, and can also detect when it is behind
'Symmetric' NAT, although it simply cannot function in this case. an Address Dependant or Address and Port Dependant NAT, although it
These clients will only work in deployment situations where the simply cannot function in this case. These clients will only work in
access is sufficiently controlled to know definitively that there deployment situations where the access is sufficiently controlled to
won't be Symmetric NAT. This is hard to guarantee as users can know definitively that there won't be Symmetric NAT. This is hard to
always pick up their client and connect via a different access guarantee as users can always pick up their client and connect via a
network. different access network.
It is RECOMMENDED that symmetric RTP and symmetric RTCP always be
used for bidirectional RTP media streams.
3.2.5.3. Minimal Profile 3.2.5.3. Minimal Profile
A client falling into the 'Minimal' profile will send/receive RTP A client falling into the 'Minimal' profile will send/receive RTP/
from the same IP/port combination. This client requires proprietary RTCP from the same IP/port combination. This client requires
network based solutions to function in any NAT traversal scenario. proprietary network based solutions to function in any NAT traversal
scenario.
In summary, the following table provides a representation of the
profiles:
| Primary | Consumer | Minimal |
| Profile | Profile | Profile |
---------+----------+----------+---------+
ICE | Yes | No | No |
---------+----------+----------+---------+
STUN | Yes | Yes | No |
---------+----------+----------+---------+
TURN Use | Yes | No | No |
---------+----------+----------+---------+
RFC3605 | Yes | Yes | No |
---------+----------+----------+---------+
Symm. RTP| Yes | Yes | Yes |
(RFC4961)| | | |
---------+----------+----------+---------+
Figure 5: Profiles
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
skipping to change at page 12, line 28 skipping to change at page 13, line 25
|(2) 401 Unauth | | |(2) 401 Unauth | |
|<-----------------| | |<-----------------| |
| | | | | |
|(3) REGISTER | | |(3) REGISTER | |
|----------------->| | |----------------->| |
| | | | | |
| |(3) REGISTER | | |(3) REGISTER |
| |----------------->| | |----------------->|
| | | | | |
|*************************************| |*************************************|
| Create Connection Re-use Tuple | | Create Outbound Connection Tuple |
|*************************************| |*************************************|
| | | | | |
| |(4) 200 OK | | |(4) 200 OK |
| |<-----------------| | |<-----------------|
| | | | | |
|(4) 200 OK | | |(4) 200 OK | |
|<-----------------| | |<-----------------| |
| | | | | |
Figure 5 Figure 6
In this example the client sends a SIP REGISTER request through a NAT In this example the client sends a SIP REGISTER request through a NAT
which is challenged using the Digest authentication scheme. The which is challenged using the Digest authentication scheme. The
client will include an 'rport' parameter as described in section client will include an 'rport' parameter as described in
3.1.1 of this document for allowing traversal of UDP responses. The Section 3.1.1 of this document for allowing traversal of UDP
original request as illustrated in (1) in Figure 5 is a standard responses. The original request as illustrated in (1) in Figure 6 is
REGISTER message: a standard REGISTER message:
REGISTER sip:proxy.example.com SIP/2.0 REGISTER sip:proxy.example.com SIP/2.0
Via: SIP/2.0/UDP client.example.com:5060;rport;branch=z9hG4bK Via: SIP/2.0/UDP client.example.com:5060;rport;branch=z9hG4bK
Max-Forwards: 70 Max-Forwards: 70
Supported: path,gruu Supported: path,gruu
From: Client <sip:client@example.com>;tag=djks8732 From: Client <sip:client@example.com>;tag=djks8732
To: Client <sip:client@example.com> To: Client <sip:client@example.com>
Call-ID: 763hdc73y7dkb37@example.com Call-ID: 763hdc73y7dkb37@example.com
CSeq: 1 REGISTER CSeq: 1 REGISTER
Contact: <sip:client@client.example.com>;reg-id=1 Contact: <sip:client@client.example.com>;reg-id=1
skipping to change at page 13, line 36 skipping to change at page 14, line 36
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 [6] MUST be obeyed. Make note of the conventions defined in RFC 3581 [RFC3581] MUST be obeyed. Make note
both the 'connectionID' and 'sip.instance' contact header parameters. of both the 'connectionID' and 'sip.instance' contact header
They are used to establish a connection re-use tuple as defined in parameters. They are used to establish an Outbound connection tuple
[13]. The connection tuple creation is clearly shown in Figure 5. as defined in [I-D.ietf-sip-outbound]. The connection tuple creation
This ensures that any inbound request that causes a registration is clearly shown in Figure 5. This ensures that any inbound request
lookup will result in the re-use of the connection path established that causes a registration lookup will result in the re-use of the
by the registration. This exonerates the need to manipulate contact connection path established by the registration. This exonerates the
header URI's to represent a globally routable address as perceived on need to manipulate contact header URI's to represent a globally
the public side of a NAT. The subsequent messages defined in (3) and routable address as perceived on the public side of a NAT. The
(4) from Figure 5 use the same mechanics for NAT traversal. subsequent messages defined in (3) and (4) from Figure 5 use the same
mechanics for NAT traversal.
[Editors note: Will provide more details on heartbeat mechanism in
next revision]
[Editors note: Can complete full flows if required on heartbeat
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 |
| |<-----------------| | |<-----------------|
skipping to change at page 14, line 28 skipping to change at page 15, line 25
|(2) 401 Unauth | | |(2) 401 Unauth | |
|<-----------------| | |<-----------------| |
| | | | | |
|(3) REGISTER | | |(3) REGISTER | |
|----------------->| | |----------------->| |
| | | | | |
| |(3) REGISTER | | |(3) REGISTER |
| |----------------->| | |----------------->|
| | | | | |
|*************************************| |*************************************|
| Create Connection Re-use Tuple | | Create Outbound Connection Tuple |
|*************************************| |*************************************|
| | | | | |
| |(4) 200 OK | | |(4) 200 OK |
| |<-----------------| | |<-----------------|
| | | | | |
|(4) 200 OK | | |(4) 200 OK | |
|<-----------------| | |<-----------------| |
| | | | | |
Figure 6. Figure 6.
skipping to change at page 15, line 18 skipping to change at page 16, line 18
Supported: path,gruu Supported: path,gruu
From: Client <sip:client@example.com>;tag=djks809834 From: Client <sip:client@example.com>;tag=djks809834
To: Client <sip:client@example.com> To: Client <sip:client@example.com>
Call-ID: 763hdc783hcnam73@example.com Call-ID: 763hdc783hcnam73@example.com
CSeq: 1 REGISTER CSeq: 1 REGISTER
Contact: <sip:client@client.example.com;transport=tcp>;reg-id=1 Contact: <sip:client@client.example.com;transport=tcp>;reg-id=1
;+sip.instance="<urn:uuid:00000000-0000-0000-0000-00A95A0E121>" ;+sip.instance="<urn:uuid:00000000-0000-0000-0000-00A95A0E121>"
Content-Length: 0 Content-Length: 0
This example was included to show the inclusion of the connection re- This example was included to show the inclusion of the connection re-
use Contact header parameters as defined in the Connection Re-use use Contact header parameters as defined in the SIP Outbound
draft [13]. This creates an association tuple as described in the specification [I-D.ietf-sip-outbound]. This creates an association
previous example for future inbound requests directed at the newly tuple as described in the previous example for future inbound
created registration binding with the only difference that the requests directed at the newly created registration binding with the
association is with a TCP connection, not a UDP pin hole binding. only difference that the association is with a TCP connection, not a
UDP pin hole binding.
[Editors note: Will provide more details on heartbeat mechanism in
next revision]
[Editors note: Can complete full flows on inclusion of heartbeat
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
skipping to change at page 16, line 38 skipping to change at page 17, line 38
| |(5)REGISTER | | | |(5)REGISTER | |
| |----------------->| | | |----------------->| |
| | | | | | | |
| | |(6)REGISTER | | | |(6)REGISTER |
| | |----------------->| | | |----------------->|
| | | | | | | |
| | |(7)200 OK | | | |(7)200 OK |
| | |<-----------------| | | |<-----------------|
| | | | | | | |
|********************************************************| |********************************************************|
| Create Connection Re-use Tuple | | Create Outbound Connection Tuple |
|********************************************************| |********************************************************|
| | | | | | | |
| |(8)200 OK | | | |(8)200 OK | |
| |<-----------------| | | |<-----------------| |
| | | | | | | |
|(8)200 OK | | | |(8)200 OK | | |
|<-----------------| | | |<-----------------| | |
| | | | | | | |
Figure 7. Figure 7.
This scenario builds on the previous example contained in This scenario builds on the previous example contained in
Section 4.1.1.2. The primary difference being that the REGISTER Section 4.1.1.2. The primary difference being that the REGISTER
request is routed onwards from a Proxy Server to a separated request is routed onwards from a Proxy Server to a separated
Registrar. The important message to note is (6) in Figure 7. The Registrar. The important message to note is (5) in Figure 7. The
Edge proxy, on receiving a REGISTER request that contains a Edge proxy, on receiving a REGISTER request that contains a
'sip.instance' media feature tag, forms a unique flow identifier 'sip.instance' media feature tag, forms a unique flow identifier
token as discussed in [13] . At this point, the proxy server routes token as discussed in [I-D.ietf-sip-outbound]. At this point, the
the SIP REGISTER message to the Registrar. The proxy will create the proxy server routes the SIP REGISTER message to the Registrar. The
connection tuple as described in SIP Outbound at the same moment as proxy will create the connection tuple as described in SIP Outbound
the co-located example, but for subsequent messages to arrive at the at the same moment as the co-located example, but for subsequent
Proxy, the element needs to request to remain in the signaling path. messages to arrive at the Proxy, the element needs to request to
To achieve this the proxy inserts to REGISTER message (5) a SIP PATH remain in the SIP signaling path. To achieve this the proxy inserts
extension header, as defined in RFC 3327 [7]. The previously created to REGISTER message (5) a SIP PATH extension header, as defined in
flow token is inserted in a position within the Path header where it RFC 3327 [RFC3327]. The previously created flow association token is
can easily be retrieved at a later point when receiving messages to inserted in a position within the Path header where it can easily be
be routed to the registration binding. REGISTER message (5) would retrieved at a later point when receiving messages to be routed to
look as follows: the registration binding (in this case the user part of the SIP URI).
The REGISTER message of (5), when proxied in (6) looks 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: path,gruu Supported: path,gruu
From: Client <sip:client@example.com>;tag=djks809834 From: Client <sip:client@example.com>;tag=djks809834
To: Client <sip:client@example.com> To: Client <sip:client@example.com>
Call-ID: 763hdc783hcnam73@example.com Call-ID: 763hdc783hcnam73@example.com
CSeq: 1 REGISTER CSeq: 1 REGISTER
Path: <sip:3HS28o8HAKJSH&&U@proxy.example.com;lr> Path: <sip:3HS28o8HAKJSH&&U@proxy.example.com;lr,ob>
Contact: <sip:client@client.example.com;transport=tcp>; Contact: <sip:client@client.example.com;transport=tcp>;
;+sip.instance="<urn:uuid:00000000-0000-0000-0000-00A95A0E121>";reg-id=1 ;+sip.instance="<urn:uuid:00000000-0000-0000-0000-00A95A0E121>";reg-id=1
Content-Length: 0 Content-Length: 0
This REGISTER request results in the Path header being stored along This REGISTER request results in the Path header being stored along
with the AOR and it's associated binding at the Registrar. The URI with the AOR and it's associated binding at the Registrar. The URI
contained in the Path header will be inserted as a pre-loaded SIP contained in the Path header will be inserted as a pre-loaded SIP
'Route' header into any request that arrives at the Registrar and is 'Route' header into any request that arrives at the Registrar and is
directed towards the associated binding. This guarantees that all directed towards the associated AOR binding. This guarantees that
requests for the new Registration will be forwarded to the Edge all requests for the new registration will be forwarded to the Edge
Proxy. In our example, the user part of the SIP 'Path' header URI Proxy. In our example, the user part of the SIP 'Path' header URI
that was inserted by the Edge Proxy contains the unique token that was inserted by the Edge Proxy contains the unique token
identifying the flow to the client. On receiving subsequent identifying the flow to the client. On receiving subsequent
requests, the edge proxy will examine the user part of the pre-loaded requests, the edge proxy will examine the user part of the pre-loaded
SIP 'route' header and extract the unique flow token for use in its SIP 'route' header and extract the unique flow token for use in its
connection tuple comparison, as defined in the SIP Outbound connection tuple comparison, as defined in the SIP Outbound
specification [13]. An example which builds on this scenario specification [I-D.ietf-sip-outbound]. An example which builds on
(showing an inbound request to the AOR) is detailed in section this scenario (showing an inbound request to the AOR) is detailed in
4.1.4.2 of this document. 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.
skipping to change at page 19, line 32 skipping to change at page 20, line 32
in Figure 8 by (1) and is as follows: in Figure 8 by (1) and is as follows:
INVITE sip:clientB@example.com SIP/2.0 INVITE sip:clientB@example.com SIP/2.0
Via: SIP/2.0/UDP client.example.com:5060;rport;branch=z9hG4bK74husdHG Via: SIP/2.0/UDP client.example.com:5060;rport;branch=z9hG4bK74husdHG
Max-Forwards: 70 Max-Forwards: 70
Route: <sip:proxy.example.com;lr> Route: <sip:proxy.example.com;lr>
From: clientA <sip:clientA@example.com>;tag=7skjdf38l From: clientA <sip:clientA@example.com>;tag=7skjdf38l
To: clientB <sip:clientB@example.com> To: clientB <sip:clientB@example.com>
Call-ID: 8327468763423@example.com Call-ID: 8327468763423@example.com
CSeq: 1 INVITE CSeq: 1 INVITE
Contact:<sip:clientA@example.com;gruu Contact:<sip:clientA@example.com;
;opaque=urn:uuid:ijed7ush-4jan-53120-aee5-e0aecwee6wef;grid=45a> gr=urn:uuid:ijed7ush-4jan-53120-aee5-e0aecwee6wef;grid=45a>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: .. Content-Length: ..
[SDP not shown] [SDP not shown]
There are a number of points to note with this message: There are a number of points to note with this message:
1. Firstly, as with the registration example in Section 4.1.1.1, 1. Firstly, as with the registration example in Section 4.1.1.1,
responses to this request will not automatically pass back responses to this request will not automatically pass back
through a NAT and so the SIP 'Via' header 'rport' is included as through a NAT and so the SIP 'Via' header 'rport' is included as
described in the 'Symmetric response' Section 3.1.1 and defined described in the 'Symmetric response' Section 3.1.1 and defined
in RFC 3581 [6]. in RFC 3581 [RFC3581].
2. Secondly, the contact inserted contains the GRUU previously 2. Secondly, the contact inserted contains the
obtained from the SIP 200 OK response to the registration. Use GRUU[I-D.ietf-sip-gruu] previously obtained from the SIP 200 OK
of the GRUU ensures that any SIP requests within the dialog that response to the registration. Use of the GRUU ensures that any
in the opposite direction will be able to traverse the NAT. This SIP requests within the dialog sent in the opposite direction
occurs using the mechanisms defined in the SIP Outbound will be able to traverse the NAT. This occurs using the
specification[13]. A request arriving at the entity which mechanisms defined in the SIP Outbound
resolves to the GRUU is then able to determine a previously specification[I-D.ietf-sip-outbound]. A request arriving at the
registered connection that will allow the request to traverse the entity which resolves to the GRUU (registrar/proxy) is then able
NAT and reach the intended endpoint. to determine a previously registered connection that will allow
the request to traverse the NAT and reach the intended endpoint.
4.1.3.2. Reliable Transport 4.1.3.2. Reliable Transport
When using a reliable transport such as TCP the call flow and When using a reliable transport such as TCP the call flow and
procedures for traversing a NAT are almost identical to those procedures for traversing a NAT are almost identical to those
described in Section 4.1.3.1. The primary difference when using described in Section 4.1.3.1. The primary difference when using
reliable transport protocols is that Symmetric response[6] are not reliable transport protocols is that Symmetric response[RFC3581] are
required for SIP responses to traverse a NAT. RFC 3261[1] defines not required for SIP responses to traverse a NAT. RFC 3261[RFC3261]
procedures for SIP response messages to be sent back on the same defines procedures for SIP response messages to be sent back on the
connection on which the request arrived. same connection on which the request arrived.
4.1.4. Receiving an Invitation to a Session 4.1.4. Receiving an Invitation to a Session
This section details scenarios where a client behind a NAT receives This section details scenarios where a client behind a NAT receives
an inbound request through a NAT. These scenarios build on the an inbound request through a NAT. These scenarios build on the
previous registration scenario from Section 4.1.1 and Section 4.1.2 previous registration scenario from Section 4.1.1 and Section 4.1.2
in this document. in this document.
4.1.4.1. Registrar/Proxy Co-located 4.1.4.1. Registrar/Proxy Co-located
skipping to change at page 21, line 26 skipping to change at page 22, line 26
| |<-----------------| | | |<-----------------| |
| | | | | | | |
|(2)INVITE | | | |(2)INVITE | | |
|<-----------------| | | |<-----------------| | |
| | | | | | | |
| | | | | | | |
Figure 9. Figure 9.
An INVITE request arrives at the Registrar with a destination An INVITE request arrives at the Registrar with a destination
pointing to the AOR of that inserted in section 4.1.1.1. The message pointing to the AOR of that inserted in Section 4.1.1.1. The message
is illustrated by (1) in Figure 9 and looks as follows: is illustrated by (1) in Figure 9 and looks as follows:
INVITE sip:client@example.com SIP/2.0 INVITE sip:client@example.com SIP/2.0
Via: SIP/2.0/UDP external.example.com;branch=z9hG4bK74huHJ37d Via: SIP/2.0/UDP external.example.com;branch=z9hG4bK74huHJ37d
Max-Forwards: 70 Max-Forwards: 70
From: External <sip:External@external.example.com>;tag=7893hd From: External <sip:External@external.example.com>;tag=7893hd
To: client <sip:client@example.com> To: client <sip:client@example.com>
Call-ID: 8793478934897@external.example.com Call-ID: 8793478934897@external.example.com
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: <sip:external@192.0.1.4> Contact: <sip:external@192.0.1.4>
skipping to change at page 22, line 6 skipping to change at page 23, line 6
installed at the Registrar and the INVITE request-URI is re-written installed at the Registrar and the INVITE request-URI is re-written
to the selected onward address. The proxy then examines the request to the selected onward address. The proxy then examines the request
URI of the INVITE and compares with its list of current open flows. URI of the INVITE and compares with its list of current open flows.
It uses the incoming AOR to commence the check for associated open It uses the incoming AOR to commence the check for associated open
connections/mappings. Once matched, the proxy checks to see if the connections/mappings. Once matched, the proxy checks to see if the
unique instance identifier (+sip.instance) associated with the unique instance identifier (+sip.instance) associated with the
binding equals the same instance identifier associated with the flow. binding equals the same instance identifier associated with the flow.
The request is then dispatched on the appropriate flow. This is The request is then dispatched on the appropriate flow. This is
message (2) from Figure 9 and is as follows: message (2) from Figure 9 and is as follows:
INVITE sip:sip:client@client.example.com SIP/2.0 INVITE sip: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 flow associated with the registration enforce but will be sent on the flow associated with the registration
binding (look-up procedures in RFC 3263 [6] are overridden). This binding (look-up procedures in RFC 3263 [RFC3263] are overridden).
then allows the original connection/mapping from the initial This then allows the original connection/mapping from the initial
registration process to be re-used. registration process to be re-used.
4.1.4.2. Registrar/Proxy Not Co-located 4.1.4.2. Registrar/Proxy Not Co-located
The core SIP signaling associated with this call flow is not impacted
directly by the transport protocol and so only one example scenario
is necessary. The example uses TCP and follows on from the
registration installed in the example from Section 4.1.2.
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 |
| | | |<-------------| | | | |<-------------|
| | | | | | | | | |
skipping to change at page 23, line 25 skipping to change at page 24, line 26
| | |<-------------| | | | |<-------------| |
| | | | | | | | | |
| |(3)INVITE | | | | |(3)INVITE | | |
| |<-------------| | | | |<-------------| | |
| | | | | | | | | |
|(3)INVITE | | | | |(3)INVITE | | | |
|<-------------| | | | |<-------------| | | |
| | | | | | | | | |
| | | | | | | | | |
Figure 9. Figure 10.
An INVITE request arrives at the Registrar with a destination
pointing to the AOR of that inserted in Section 4.1.2. The message
is illustrated by (1) in Figure 10 and looks as follows:
INVITE sip:client@example.com SIP/2.0
Via: SIP/2.0/UDP external.example.com;branch=z9hG4bK74huHJ37d
Max-Forwards: 70
From: External <sip:External@external.example.com>;tag=7893hd
To: client <sip:client@example.com>
Call-ID: 8793478934897@external.example.com
CSeq: 1 INVITE
Contact: <sip:external@192.0.1.4>
Content-Type: application/sdp
Content-Length: ..
[SDP not shown]
The INVITE request matches the registration binding previously
installed at the Registrar and the INVITE request-URI is re-written
to the selected onward address. The Registrar also identifies that a
SIP PATH header was associated with the registration and pushes it
into the INVITE request in the form of a pre-loaded SIP Route header.
It then forwards the request on to the proxy identified in the SIP
Route header as shown in (2) from Figure 10:
INVITE sip:client@client.example.com SIP/2.0
Via: SIP/2.0/TCP registrar.example.com;branch=z9hG4bK74fmljnc
Via: SIP/2.0/UDP external.example.com;branch=z9hG4bK74huHJ37d
Route: <sip:3HS28o8HAKJSH&&U@proxy.example.com;lr,ob>
Max-Forwards: 70
From: External <sip:External@external.example.com>;tag=7893hd
To: client <sip:client@example.com>
Call-ID: 8793478934897@external.example.com
CSeq: 1 INVITE
Contact: <sip:external@192.0.1.4>
Content-Type: application/sdp
Content-Length: ..
[SDP not shown]
The request then arrives at the outbound proxy for the client. The
proxy examines the request URI of the INVITE in conjunction with the
flow token that it previously inserted into the user part of the PATH
header SIP URI (which now appears in the user part of the Route
header in the incoming INVITE). The proxy locates the appropriate
flow and sends the message to the client, as shown in (3) from Figure
10:
INVITE sip:client@client.example.com SIP/2.0
Via: SIP/2.0/TCP proxy.example.com;branch=z9hG4nsi30dncmnl
Via: SIP/2.0/TCP registrar.example.com;branch=z9hG4bK74fmljnc
Via: SIP/2.0/UDP external.example.com;branch=z9hG4bK74huHJ37d
Max-Forwards: 70
From: External <sip:External@external.example.com>;tag=7893hd
To: client <sip:client@example.com>
Call-ID: 8793478934897@external.example.com
CSeq: 1 INVITE
Contact: <sip:external@192.0.1.4>
Content-Type: application/sdp
Content-Length: ..
[SDP not shown]
It is a standard SIP INVITE request with no additional functionality
at the originator. The major difference being that this request will
not follow the address specified in the Request-URI when it reaches
the outbound proxy, as standard SIP rules would enforce but will be
sent on the flow associated with the registration binding as
indicated in the Route header(look-up procedures in RFC 3263
[RFC3263] are overridden). This then allows the original connection/
mapping from the initial registration to the outbound proxy to be re-
used.
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.
In the flow diagrams STUN messages have been annotated for simplicity In the flow diagrams STUN messages have been annotated for simplicity
as follows: as follows:
o The "Src" attribute represents the source transport address of the o The "Src" attribute represents the source transport address of the
message. message.
o The "Dest" attribute represents the destination transport address o The "Dest" attribute represents the destination transport address
of the message. of the message.
o The "Map" attribute represents the server reflexive (XOR-MAPPED- o The "Map" attribute represents the server reflexive (XOR-MAPPED-
ADDRESS STUN attribute) transport address. ADDRESS STUN attribute) transport address.
o The "Rel" attribute represents the relayed (RELAY-ADDRESS STUN o The "Rel" attribute represents the relayed (RELAY-ADDRESS STUN
attribute) transport address. attribute) transport address.
The meaning of each STUN attribute is extensively explained in the The meaning of each STUN attribute is extensively explained in the
core STUN[10] and TURN usage[12] drafts. core STUN[I-D.ietf-behave-rfc3489bis] and TURN
usage[I-D.ietf-behave-turn] drafts.
A number of ICE SDP attributes have also been included in some of the A number of ICE SDP attributes have also been included in some of the
examples. Detailed information on individual attributes can be examples. Detailed information on individual attributes can be
obtained from the core ICE specification. obtained from the core ICE specification[I-D.ietf-mmusic-ice].
The examples also contain a mechanism for representing transport The examples also contain a mechanism for representing transport
addresses. It would be confusing to include representations of addresses. It would be confusing to include representations of
network addresses in the call flows and make them hard to follow. network addresses in the call flows and make them hard to follow.
For this reason network addresses will be represented using the For this reason network addresses will be represented using the
following annotation. The first component will contain the following annotation. The first component will contain the
representation of the client responsible for the address. For representation of the client responsible for the address. For
example in the majority of the examples "L" (left client), "R" (right example in the majority of the examples "L" (left client), "R" (right
client), NAT-PUB" (NAT public), PRIV (Private), and "STUN-PUB" (STUN client), NAT-PUB" (NAT public), PRIV (Private), and "STUN-PUB" (STUN
Public) are used. To allow for multiple addresses from the same Public) are used. To allow for multiple addresses from the same
skipping to change at page 24, line 36 skipping to change at page 27, line 17
4.2.1. Endpoint Independent NAT 4.2.1. Endpoint Independent NAT
This section demonstrates an example of a client both initiating and This section demonstrates an example of a client both initiating and
receiving calls behind an 'Endpoint independent' NAT. An example is receiving calls behind an 'Endpoint independent' NAT. An example is
included for both STUN and ICE with ICE being the RECOMMENDED included for both STUN and ICE with ICE being the RECOMMENDED
mechanism for media traversal. mechanism for media traversal.
4.2.1.1. STUN Solution 4.2.1.1. STUN Solution
It is possible to traverse media through an 'Endpoint Independent NAT It is possible to traverse media through an 'Endpoint Independent NAT
using STUN. The remainder of this section provides a simplified using STUN. The remainder of this section provides simplified
examples of the 'Binding Discovery' STUN usage as defined in [10]. examples of the 'Binding Discovery' STUN usage as defined in
The STUN messages have been simplified and do not include 'Shared [I-D.ietf-behave-rfc3489bis]. The STUN messages have been simplified
Secret' requests used to obtain the temporary username and password. and do not include 'Shared Secret' requests used to obtain the
temporary username and password.
[Editors Note: Expand to show full flow including Auth?.]
4.2.1.1.1. Initiating Session 4.2.1.1.1. Initiating Session
The following example demonstrates media traversal through a NAT with The following example demonstrates media traversal through a NAT with
'Address Independent' properties using the STUN 'Binding Discovery' 'Address Independent' properties using the STUN 'Binding Discovery'
usage. It is assumed in this example that the STUN client and SIP usage. It is assumed in this example that the STUN client and SIP
Client are co-located on the same physical machine. Note that some Client are co-located on the same physical machine. Note that some
SIP signaling messages have been left out for simplicity. SIP signaling messages have been left out for simplicity.
Client NAT STUN [..] Client NAT STUN [..]
skipping to change at page 26, line 38 skipping to change at page 29, line 19
|<<<<<<<<<<<<Incoming RTCP sent to NAT-PUB-2<<<<<<<<<<<<<| |<<<<<<<<<<<<Incoming RTCP sent to NAT-PUB-2<<<<<<<<<<<<<|
|========================================================| |========================================================|
| | | | | | | |
|(13)SIP ACK | | | |(13)SIP ACK | | |
|----------------->| | | |----------------->| | |
| | | | | | | |
| |(14) SIP ACK | | | |(14) SIP ACK | |
| |------------------------------------>| | |------------------------------------>|
| | | | | | | |
Figure 18: Endpoint Independent NAT - Initiating Figure 7: Endpoint Independent NAT - Initiating
o On deciding to initiate a SIP voice session the client starts a o On deciding to initiate a SIP voice session the client starts a
local STUN client on the interface and port that is to be used for local STUN client on the interface and port that is to be used for
media (send/receive). The STUN client generates a standard media (send/receive). The STUN client generates a standard
'Binding Discovery' request as indicated in (1) from Figure 18 'Binding Discovery' request as indicated in (1) from Figure 7
which also highlights the source address and port for which the which also highlights the source address and port for which the
client device wishes to obtain a mapping. The 'Binding Discovery' client device wishes to obtain a mapping. The 'Binding Discovery'
request is sent through the NAT towards the public internet and request is sent through the NAT towards the public internet and
STUN server. STUN server.
o Message (2) traverses the NAT and breaks out onto the public o Message (2) traverses the NAT and breaks out onto the public
internet towards the public STUN server. Note that the source internet towards the public STUN server. Note that the source
address of the 'Binding Discovery' request now represents the address of the 'Binding Discovery' request now represents the
public address and port from the public side of the NAT. public address and port from the public side of the NAT.
o The STUN server receives the request and processes it o The STUN server receives the request and processes it
appropriately. This results in a successful 'Binding Discovery' appropriately. This results in a successful 'Binding Discovery'
response being generated and returned (3). The message contains response being generated and returned (3). The message contains
details of the XOR mapped public address (contained in the STUN details of the XOR mapped public address (contained in the STUN
XOR-MAPPED-ADDRESS attribute) which is to be used by the XOR-MAPPED-ADDRESS attribute) which is to be used by the
originating client to receive media (see 'Map=NAT-PUB-1' from originating client to receive media (see 'Map=NAT-PUB-1' from
(3)). (3)).
o The 'Binding Discovery' response traverses back through the NAT o The 'Binding Discovery' response traverses back through the NAT
using the path created by the 'Binding Discovery' request and using the path created by the 'Binding Discovery' request and
presents the new XOR mapped address to the client (4). At this presents the new XOR mapped address to the client (4). At this
point the process is repeated to obtain a second XOR-mapped point the process is repeated to obtain a second XOR-mapped
address (as shown in (5)-(8)) for an alternative local address address (as shown in (5)-(8)) for an alternative local address
(Address has changed from "L-PRIV-1" to "L-PRIV-2"). (Address has changed from "L-PRIV-1" to "L-PRIV-2") for an RTCP
port.
o The client now constructs a SIP INVITE message(9). Note that o The client now constructs a SIP INVITE message(9). Note that
traversal of SIP is not covered in this example and is discussed traversal of SIP is not covered in this example and is discussed
in earlier sections of the document. The INVITE request will use in earlier sections of the document. The INVITE request will use
the addresses it has obtained in the previous STUN transactions to the addresses it has obtained in the previous STUN transactions to
populate the SDP of the SIP INVITE as shown below: populate the SDP of the SIP INVITE as shown below:
v=0 v=0
o=test 2890844526 2890842807 IN IP4 $L-PRIV-1.address o=test 2890844526 2890842807 IN IP4 $L-PRIV-1.address
c=IN IP4 $NAT-PUB-1.address c=IN IP4 $NAT-PUB-1.address
t=0 0 t=0 0
skipping to change at page 27, line 39 skipping to change at page 30, line 21
a=rtcp:$NAT-PUB-2.port a=rtcp:$NAT-PUB-2.port
o Note that the XOR-mapped address obtained from the 'Binding o Note that the XOR-mapped address obtained from the 'Binding
Discovery' transactions are inserted as the connection address for Discovery' transactions are inserted as the connection address for
the SDP (c=NAT-PUB-1.address). The Primary port for RTP is also the SDP (c=NAT-PUB-1.address). The Primary port for RTP is also
inserted in the SDP (m=audio NAT-PUB-1.port RTP/AVP 0). Finally, inserted in the SDP (m=audio NAT-PUB-1.port RTP/AVP 0). Finally,
the port gained from the additional 'Binding Discovery' is placed the port gained from the additional 'Binding Discovery' is placed
in the RTCP attribute (as discussed in Section 3.2.1.1) for in the RTCP attribute (as discussed in Section 3.2.1.1) for
traversal of RTCP (a=rtcp:NAT-PUB-2.port). traversal of RTCP (a=rtcp:NAT-PUB-2.port).
o The SIP signaling then traverses the NAT and sets up the SIP o The SIP signaling then traverses the NAT and sets up the SIP
session (10-12). Note that the client transmits media as soon as session (9-12). Note that the client transmits media as soon as
the 200 OK to the INVITE arrives at the client (12). Up until the 200 OK to the INVITE arrives at the client (12). Up until
this point the incoming media and RTCP will not pass through the this point the incoming media and RTCP will not pass through the
NAT as no outbound association has been created with the far end NAT as no outbound association has been created with the far end
client. Two way media communication has now been established. client. Two way media communication has now been established.
4.2.1.1.2. Receiving Session Invitation 4.2.1.1.2. Receiving Session Invitation
Receiving a session for an 'Endpoint Independent' NAT using the STUN Receiving a session for an 'Endpoint Independent' NAT using the STUN
'Binding Discovery' usage is very similar to the example outlined in 'Binding Discovery' usage is very similar to the example outlined in
Section 4.2.1.1.1. Figure 20 illustrates the associated flow of Section 4.2.1.1.1. Figure 8 illustrates the associated flow of
messages. 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 29, line 36 skipping to change at page 32, line 21
|<<<<<<<<<<<<<Incoming RTCP sent to L-PRIV-2<<<<<<<<<<<<<| |<<<<<<<<<<<<<Incoming RTCP sent to L-PRIV-2<<<<<<<<<<<<<|
|========================================================| |========================================================|
| | | | | | | |
| | |(13)SIP ACK | | | |(13)SIP ACK |
| |<------------------------------------| | |<------------------------------------|
| | | | | | | |
|(14)SIP ACK | | | |(14)SIP ACK | | |
|<-----------------| | | |<-----------------| | |
| | | | | | | |
Figure 20: Endpoint Independent NAT - Receiving Figure 8: Endpoint Independent NAT - Receiving
o On receiving an invitation to a SIP voice session (SIP INVITE o On receiving an invitation to a SIP voice session (SIP INVITE
request) the User Agent starts a local STUN client on the request) the User Agent starts a local STUN client on the
appropriate port on which it is to receive media. The STUN client appropriate port on which it is to receive media. The STUN client
generates a standard 'Binding Discovery' request as indicated in generates a standard 'Binding Discovery' request as indicated in
(3) from Figure 20 which also highlights the source address and (3) from Figure 8 which also highlights the source address and
port for which the client device wishes to obtain a mapping. The port for which the client device wishes to obtain a mapping. The
'Binding Discovery' request is sent through the NAT towards the 'Binding Discovery' request is sent through the NAT towards the
public internet and STUN Server. public internet and STUN Server.
o 'Binding Discovery' message (4) traverses the NAT and breaks out o 'Binding Discovery' message (4) traverses the NAT and breaks out
onto the public internet towards the public STUN server. Note onto the public internet towards the public STUN server. Note
that the source address of the STUN requests now represents the that the source address of the STUN requests now represents the
public address and port from the public side of the NAT. public address and port from the public side of the NAT.
o The STUN server receives the request and processes it o The STUN server receives the request and processes it
appropriately. This results in a successful 'Binding Discovery' appropriately. This results in a successful 'Binding Discovery'
response being generated and returned (5). The message contains response being generated and returned (5). The message contains
details of the mapped public address (contained in the STUN XOR- details of the mapped public address (contained in the STUN XOR-
MAPPED-ADDRESS attribute) which is to be used by the originating MAPPED-ADDRESS attribute) which is to be used by the originating
client to receive media (see 'Map=NAT-PUB-1' from (5)). client to receive media (see 'Map=NAT-PUB-1' from (5)).
o The 'Binding Discovery' response traverses back through the NAT o The 'Binding Discovery' response traverses back through the NAT
using the path created by the outgoing 'Binding Discovery' request using the path created by the outgoing 'Binding Discovery' request
and presents the new XOR-mapped address to the client (6). At and presents the new XOR-mapped address to the client (6). At
this point the process is repeated to obtain a second XOR-mapped this point the process is repeated to obtain a second XOR-mapped
skipping to change at page 30, line 16 skipping to change at page 32, line 46
appropriately. This results in a successful 'Binding Discovery' appropriately. This results in a successful 'Binding Discovery'
response being generated and returned (5). The message contains response being generated and returned (5). The message contains
details of the mapped public address (contained in the STUN XOR- details of the mapped public address (contained in the STUN XOR-
MAPPED-ADDRESS attribute) which is to be used by the originating MAPPED-ADDRESS attribute) which is to be used by the originating
client to receive media (see 'Map=NAT-PUB-1' from (5)). client to receive media (see 'Map=NAT-PUB-1' from (5)).
o The 'Binding Discovery' response traverses back through the NAT o The 'Binding Discovery' response traverses back through the NAT
using the path created by the outgoing 'Binding Discovery' request using the path created by the outgoing 'Binding Discovery' request
and presents the new XOR-mapped address to the client (6). At and presents the new XOR-mapped address to the client (6). At
this point the process is repeated to obtain a second XOR-mapped this point the process is repeated to obtain a second XOR-mapped
address (as shown in (7)-(10)) for an alternative local address address (as shown in (7)-(10)) for an alternative local address
(local port has now changed and is represented by L-PRIV-2 in (local port has now changed and is represented by L-PRIV-2 in (7))
(7)). for an RTCP port.
o The client now constructs a SIP 200 OK message (11) in response to o The client now constructs a SIP 200 OK message (11) in response to
the original SIP INVITE requests. Note that traversal of SIP is the original SIP INVITE requests. Note that traversal of SIP is
not covered in this example and is discussed in earlier sections not covered in this example and is discussed in earlier sections
of the document. SIP Provisional responses are also left out for of the document. SIP Provisional responses are also left out for
simplicity. The 200 OK response will use the addresses it has simplicity. The 200 OK response will use the addresses it has
obtained in the previous STUN transactions to populate the SDP of obtained in the previous STUN transactions to populate the SDP of
the SIP 200 OK as shown below: the SIP 200 OK as shown below:
v=0 v=0
o=test 2890844526 2890842807 IN IP4 $L-PRIV-1.address o=test 2890844526 2890842807 IN IP4 $L-PRIV-1.address
skipping to change at page 31, line 4 skipping to change at page 33, line 35
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, regardless of the NAT type. The described in Section 3.2.4, regardless of the NAT type. The
following examples illustrate the traversal of an 'Endpoint following examples illustrate the traversal of an 'Endpoint
Independent' NAT when initiating. The example only covers ICE in Independent' NAT when initiating the session. The example only
association with the 'Binding Discovery' and TURN usage. covers ICE in association with the 'Binding Discovery' and TURN
usage.
4.2.1.2.1. Initiating Session 4.2.1.2.1. Initiating Session
The following example demonstrates an initiating traversal through an The following example demonstrates an initiating traversal through an
'Endpoint independent' NAT using ICE. 'Endpoint independent' NAT using ICE.
L NAT STUN NAT R L NAT STUN NAT R
Server Server
| | | | | | | | | |
|(1) Alloc Req | | | | |(1) Alloc Req | | | |
skipping to change at page 38, line 43 skipping to change at page 41, line 28
|(64) SIP 200 OK | | | | |(64) SIP 200 OK | | | |
|<---------------| | | | |<---------------| | | |
| | | | | | | | | |
|(65) SIP ACK | | | | |(65) SIP ACK | | | |
|------------------------------------------------->| | |------------------------------------------------->| |
| | | | | | | | | |
| | | |(66) SIP ACK | | | | |(66) SIP ACK |
| | | |--------------->| | | | |--------------->|
| | | | | | | | | |
Figure 22: Endpoint Independent NAT with ICE Figure 9: Endpoint Independent NAT with ICE
o On deciding to initiate a SIP voice session the SIP client 'L' o On deciding to initiate a SIP voice session the SIP client 'L'
starts a local STUN client. The STUN client generates a standard starts a local STUN client. The STUN client generates a standard
Allocate request as indicated in (1) from Figure 22 which also Allocate request as indicated in (1) from Figure 9 which also
highlights the source address and port combination for which the highlights the source address and port combination for which the
client device wishes to obtain a mapping. The Allocate request is client device wishes to obtain a mapping. The Allocate request is
sent through the NAT towards the public internet. sent through the NAT towards the public internet.
o The Allocate message (2) traverses the NAT and breaks out onto the o The Allocate message (2) traverses the NAT and breaks out onto the
public internet towards the public STUN server. Note that the public internet towards the public STUN server. Note that the
source address of the Allocate request now represents the public source address of the Allocate request now represents the public
address and port from the public side of the NAT (L-NAT-PUB-1). address and port from the public side of the NAT (L-NAT-PUB-1).
o The STUN server receives the Allocate request and processes o The STUN server receives the Allocate request and processes
appropriately. This results in a successful Allocate response appropriately. This results in a successful Allocate response
being generated and returned (3). The message contains details of being generated and returned (3). The message contains details of
the server reflexive address which is to be used by the the server reflexive address which is to be used by the
originating client to receive media (see 'Map=L-NAT-PUB-1') from originating client to receive media (see 'Map=L-NAT-PUB-1') from
(3)). It also contains an appropriate relayed address that can be (3)). It also contains an appropriate relayed address that can be
skipping to change at page 39, line 20 skipping to change at page 42, line 4
appropriately. This results in a successful Allocate response appropriately. This results in a successful Allocate response
being generated and returned (3). The message contains details of being generated and returned (3). The message contains details of
the server reflexive address which is to be used by the the server reflexive address which is to be used by the
originating client to receive media (see 'Map=L-NAT-PUB-1') from originating client to receive media (see 'Map=L-NAT-PUB-1') from
(3)). It also contains an appropriate relayed address that can be (3)). It also contains an appropriate relayed address that can be
used at the STUN server (see 'Rel=STUN-PUB-2'). used at the STUN server (see 'Rel=STUN-PUB-2').
o The Allocate response traverses back through the NAT using the o The Allocate response traverses back through the NAT using the
binding created by the initial Allocate request and presents the binding created by the initial Allocate request and presents the
new mapped address to the client (4). The process is repeated and new mapped address to the client (4). The process is repeated and
a second STUN derived set of address' are obtained, as illustrated a second STUN derived set of address' are obtained, as illustrated
in (5)-(8) in Figure 22. At this point the User Agent behind the in (5)-(8) in Figure 9. At this point the User Agent behind the
NAT has pairs of derived external server reflexive and relayed NAT has pairs of derived external server reflexive and relayed
representations. The client would be free to gather any number of representations. The client would be free to gather any number of
external representations using any UNSAF[9] compliant protocol. external representations using any UNSAF[RFC3424] compliant
protocol.
o The client now constructs a SIP INVITE message (9). The INVITE o The client now constructs a SIP INVITE message (9). The INVITE
request will use the addresses it has obtained in the previous request will use the addresses it has obtained in the previous
STUN/TURN interactions to populate the SDP of the SIP INVITE. STUN/TURN interactions to populate the SDP of the SIP INVITE.
This should be carried out in accordance with the semantics This should be carried out in accordance with the semantics
defined in the ICE specification[16], as shown below in Figure 23 defined in the ICE specification[I-D.ietf-mmusic-ice], as shown
(*note - /* signifies line continuation): below in Figure 10 (*note - 'allOneLine' notation signifies line
continuation):
v=0 v=0
o=test 2890844526 2890842807 IN IP4 $L-PRIV-1 o=test 2890844526 2890842807 IN IP4 $L-PRIV-1
c=IN IP4 $L-PRIV-1.address c=IN IP4 $L-PRIV-1.address
t=0 0 t=0 0
a=ice-pwd:$LPASS a=ice-pwd:$LPASS
a=ice-ufrag:$LUNAME a=ice-ufrag:$LUNAME
m=audio $L-PRIV-1.port RTP/AVP 0 m=audio $L-PRIV-1.port RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtcp:$L-PRIV-2.port a=rtcp:$L-PRIV-2.port
a=candidate:$L1 1 UDP 3102938476 $L-PRIV-1.address $L-PRIV-1.port typ local a=candidate:$L1 1 UDP 3102938476 $L-PRIV-1.address $L-PRIV-1.port typ local
a=candidate:$L1 2 UDP 3010948635 $L-PRIV-2.address $L-PRIV-2.port typ local a=candidate:$L1 2 UDP 3010948635 $L-PRIV-2.address $L-PRIV-2.port typ local
<allOneLine>
a=candidate:$L2 1 UDP 2203948363 $L-NAT-PUB-1.address $L-NAT-PUB-1.port typ srflx a=candidate:$L2 1 UDP 2203948363 $L-NAT-PUB-1.address $L-NAT-PUB-1.port typ srflx
/* raddr $L-PRIV-1.address rport $L-PRIV-1.port raddr $L-PRIV-1.address rport $L-PRIV-1.port
</allOneLine>
<allOneLine>
a=candidate:$L2 2 UDP 2172635342 $L-NAT-PUB-2.address $L-NAT-PUB-2.port typ srflx a=candidate:$L2 2 UDP 2172635342 $L-NAT-PUB-2.address $L-NAT-PUB-2.port typ srflx
/* raddr $L-PRIV-1.address rport $L-PRIV-2.port raddr $L-PRIV-1.address rport $L-PRIV-2.port
</allOneLine>
<allOneLine>
a=candidate:$L3 1 UDP 1763546473 $STUN-PUB-2.address $STUN-PUB-2.port typ relay a=candidate:$L3 1 UDP 1763546473 $STUN-PUB-2.address $STUN-PUB-2.port typ relay
/* raddr $L-PRIV-1.address rport $L-PRIV-1.port raddr $L-PRIV-1.address rport $L-PRIV-1.port
</allOneLine>
<allOneLine>
a=candidate:$L3 2 UDP 1109384746 $STUN-PUB-3.address $STUN-PUB-3.port typ relay a=candidate:$L3 2 UDP 1109384746 $STUN-PUB-3.address $STUN-PUB-3.port typ relay
/* raddr $L-PRIV-1.address rport $L-PRIV-2.port raddr $L-PRIV-1.address rport $L-PRIV-2.port
</allOneLine>
Figure 10: ICE SDP Offer
Figure 23: ICE SDP Offer
o The SDP has been constructed to include all the available o The SDP has been constructed to include all the available
candidates that have been assembled. The first set of candidates candidates that have been assembled. The first set of candidates
(as identified by Foundation $L1) contain two local addresses that (as identified by Foundation $L1) contain two local addresses that
have the highest priority. They are also encoded into the have the highest priority. They are also encoded into the
connection (c=) and media (m=) lines of the SDP. The second set connection (c=) and media (m=) lines of the SDP. The second set
of candidates, as identified by Foundation $L2, contains the two of candidates, as identified by Foundation $L2, contains the two
server reflexive addresses obtained from the STUN server for both server reflexive addresses obtained from the STUN server for both
RTP and RTCP traffic (identified by candidate-id $L2). This entry RTP and RTCP traffic (identified by candidate-id $L2). This entry
has been given a priority lower than the pair $L1 by the client. has been given a priority lower than the pair $L1 by the client.
The third and final set of candidates represents the relayed The third and final set of candidates represents the relayed
skipping to change at page 40, line 29 skipping to change at page 43, line 24
should have a local STUN server running on each advertised should have a local STUN server running on each advertised
candidate address. This is for the purpose of responding to candidate address. This is for the purpose of responding to
incoming STUN connectivity checks. incoming STUN connectivity checks.
o On receiving the SIP INVITE request (10) client 'R' also starts o On receiving the SIP INVITE request (10) client 'R' also starts
local STUN servers on appropriate address/port combinations and local STUN servers on appropriate address/port combinations and
gathers potential candidate addresses to be encoded into the SDP gathers potential candidate addresses to be encoded into the SDP
(as the originating client did). Steps (11-18) involve client 'R' (as the originating client did). Steps (11-18) involve client 'R'
carrying out the same steps as client 'L'. This involves carrying out the same steps as client 'L'. This involves
obtaining local, server reflexive and relayed addresses. Client obtaining local, server reflexive and relayed addresses. Client
'R' is now ready to generate an appropriate answer in the SIP 200 'R' is now ready to generate an appropriate answer in the SIP 200
OK message (19). The example answer follows in Figure 23 (*note - OK message (19). The example answer follows in Figure 10 (*note -
/* signifies line continuation): 'allOneLine' notation signifies line continuation):
v=0 v=0
o=test 3890844516 3890842803 IN IP4 $R-PRIV-1 o=test 3890844516 3890842803 IN IP4 $R-PRIV-1
c=IN IP4 $R-PRIV-1.address c=IN IP4 $R-PRIV-1.address
t=0 0 t=0 0
a=ice-pwd:$RPASS a=ice-pwd:$RPASS
m=audio $R-PRIV-1.port RTP/AVP 0 m=audio $R-PRIV-1.port RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtcp:$R-PRIV-2.port a=rtcp:$R-PRIV-2.port
a=candidate:$L1 1 UDP 3303948573 $R-PRIV-1.address $R-PRIV-1.port typ local a=candidate:$L1 1 UDP 3303948573 $R-PRIV-1.address $R-PRIV-1.port typ local
a=candidate:$L1 2 UDP 3184756473 $R-PRIV-2.address $R-PRIV-2.port typ local a=candidate:$L1 2 UDP 3184756473 $R-PRIV-2.address $R-PRIV-2.port typ local
<allOneLine>
a=candidate:$L2 1 UDP 2984756463 $R-NAT-PUB-1.address $R-NAT-PUB-1.port typ srflx a=candidate:$L2 1 UDP 2984756463 $R-NAT-PUB-1.address $R-NAT-PUB-1.port typ srflx
/* raddr $R-PRIV-1.address rport $R-PRIV-1.port raddr $R-PRIV-1.address rport $R-PRIV-1.port
</allOneLine>
<allOneLine>
a=candidate:$L2 2 UDP 2605968473 $R-NAT-PUB-2.address $R-NAT-PUB-2.port typ srflx a=candidate:$L2 2 UDP 2605968473 $R-NAT-PUB-2.address $R-NAT-PUB-2.port typ srflx
/* raddr $R-PRIV-1.address rport $R-PRIV-1.port raddr $R-PRIV-1.address rport $R-PRIV-1.port
</allOneLine>
<allOneLine>
a=candidate:$L3 1 UDP 1453647488 $STUN-PUB-2.address $STUN-PUB-4.port typ relay a=candidate:$L3 1 UDP 1453647488 $STUN-PUB-2.address $STUN-PUB-4.port typ relay
/* raddr $R-PRIV-1.address rport $R-PRIV-1.port raddr $R-PRIV-1.address rport $R-PRIV-1.port
</allOneLine>
<allOneLine>
a=candidate:$L3 2 UDP 1183948473 $STUN-PUB-3.address $STUN-PUB-5.port typ relay a=candidate:$L3 2 UDP 1183948473 $STUN-PUB-3.address $STUN-PUB-5.port typ relay
/* raddr $R-PRIV-1.address rport $R-PRIV-1.port raddr $R-PRIV-1.address rport $R-PRIV-1.port
Figure 24: ICE SDP Answer </allOneLine>
Figure 11: ICE SDP Answer
o The two clients have now exchanged SDP using offer/answer and can o The two clients have now exchanged SDP using offer/answer and can
now continue with the ICE processing - User Agent 'L' assuming the now continue with the ICE processing - User Agent 'L' assuming the
role controlling agent, as specified by ICE. The clients are now role controlling agent, as specified by ICE. The clients are now
required to form their Candidate check lists to determine which required to form their Candidate check lists to determine which
will be used for the media streams. In this example User Agent will be used for the media streams. In this example User Agent
'L's 'Foundation 1' is paired with User Agent 'R's 'Foundation 1', 'L's 'Foundation 1' is paired with User Agent 'R's 'Foundation 1',
User Agent 'L's 'Foundation 2' is paired with User Agent 'R's User Agent 'L's 'Foundation 2' is paired with User Agent 'R's
'Foundation 2', and finally User Agent 'L's 'Foundation 3' is 'Foundation 2', and finally User Agent 'L's 'Foundation 3' is
paired with User Agent 'R's 'Foundation 3'. User Agents 'L' and paired with User Agent 'R's 'Foundation 3'. User Agents 'L' and
skipping to change at page 41, line 24 skipping to change at page 45, line 4
paired with User Agent 'R's 'Foundation 3'. User Agents 'L' and paired with User Agent 'R's 'Foundation 3'. User Agents 'L' and
'R' now have a complete candidate check list. Both clients now 'R' now have a complete candidate check list. Both clients now
use the algorithm provided in ICE to determine candidate pair use the algorithm provided in ICE to determine candidate pair
priorities and sort into a list of decreasing priorities. In this priorities and sort into a list of decreasing priorities. In this
example, both User Agent 'L' and 'R' will have lists that firstly example, both User Agent 'L' and 'R' will have lists that firstly
specifies the host address (Foundation $L1), then the server specifies the host address (Foundation $L1), then the server
reflexive address (Foundation $L2) and lastly the relayed address reflexive address (Foundation $L2) and lastly the relayed address
(Foundation $L3). All candidate pairs have an associate state as (Foundation $L3). All candidate pairs have an associate state as
specified in ICE. At this stage, all of the candidate pairs for specified in ICE. At this stage, all of the candidate pairs for
User Agents 'L' and 'R' are initialized to the 'Frozen' state. User Agents 'L' and 'R' are initialized to the 'Frozen' state.
The User Agents then scan the list and move the candidates to the The User Agents then scan the list and move the candidates to the
'Waiting' state. At this point both clients will periodically, 'Waiting' state. At this point both clients will periodically,
starting with the highest candidate pair priority, work there way starting with the highest candidate pair priority, work their way
down the list issuing STUN checks from the local candidate to the down the list issuing STUN checks from the local candidate to the
remote candidate (of the candidate pair). As a STUN Check is remote candidate (of the candidate pair). As a STUN Check is
attempted from each local candidate in the list, the candidate attempted from each local candidate in the list, the candidate
pair state transitions to 'In-Progress'. As illustrated in (23), pair state transitions to 'In-Progress'. As illustrated in (23),
client 'L' constructs a STUN connectivity check in an attempt to client 'L' constructs a STUN connectivity check in an attempt to
validate the remote candidate address received in the SDP of the validate the remote candidate address received in the SDP of the
200 OK (20) for the highest priority in the check list. As a 200 OK (20) for the highest priority in the check list. As a
private address was specified in the active address in the SDP, private address was specified in the active address in the SDP,
the STUN connectivity check fails to reach its destination causing the STUN connectivity check fails to reach its destination causing
a STUN failure. Client 'L' transitions the state for this a STUN failure. Client 'L' transitions the state for this
skipping to change at page 42, line 34 skipping to change at page 46, line 14
v=0 v=0
o=test 2890844526 2890842808 IN IP4 $L-PRIV-1 o=test 2890844526 2890842808 IN IP4 $L-PRIV-1
c=IN IP4 $L-NAT-PUB-1.address c=IN IP4 $L-NAT-PUB-1.address
t=0 0 t=0 0
a=ice-pwd:$LPASS a=ice-pwd:$LPASS
a=ice-ufrag:$LUNAME a=ice-ufrag:$LUNAME
m=audio $L-NAT-PUB-1.port RTP/AVP 0 m=audio $L-NAT-PUB-1.port RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtcp:$L-NAT-PUB-2.port a=rtcp:$L-NAT-PUB-2.port
<allOneLine>
a=candidate:$L2 1 UDP 2203948363 $L-NAT-PUB-1.address $L-NAT-PUB-1.port typ srflx a=candidate:$L2 1 UDP 2203948363 $L-NAT-PUB-1.address $L-NAT-PUB-1.port typ srflx
/* raddr $L-PRIV-1.address rport $L-PRIV-1.port raddr $L-PRIV-1.address rport $L-PRIV-1.port
</allOneLine>
<allOneLine>
a=candidate:$L2 2 UDP 2172635342 $L-NAT-PUB-2.address $L-NAT-PUB-2.port typ srflx a=candidate:$L2 2 UDP 2172635342 $L-NAT-PUB-2.address $L-NAT-PUB-2.port typ srflx
/* raddr $L-PRIV-1.address rport $L-PRIV-2.port raddr $L-PRIV-1.address rport $L-PRIV-2.port
</allOneLine>
Figure 25: ICE SDP Updated Offer Figure 12: ICE SDP Updated Offer
o The resulting answer (63-64) for 'R' would look as follows: o The resulting answer (63-64) for 'R' would look as follows:
v=0 v=0
o=test 3890844516 3890842804 IN IP4 $R-PRIV-1 o=test 3890844516 3890842804 IN IP4 $R-PRIV-1
c=IN IP4 $R-PRIV-1.address c=IN IP4 $R-PRIV-1.address
t=0 0 t=0 0
a=ice-pwd:$RPASS a=ice-pwd:$RPASS
a=ice-ufrag:$RUNAME a=ice-ufrag:$RUNAME
m=audio $R-PRIV-1.port RTP/AVP 0 m=audio $R-PRIV-1.port RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtcp:$R-PRIV-2.port a=rtcp:$R-PRIV-2.port
<allOneLine>
a=candidate:$L2 1 UDP 2984756463 $R-NAT-PUB-1.address $R-NAT-PUB-1.port typ srflx a=candidate:$L2 1 UDP 2984756463 $R-NAT-PUB-1.address $R-NAT-PUB-1.port typ srflx
/* raddr $R-PRIV-1.address rport $R-PRIV-1.port raddr $R-PRIV-1.address rport $R-PRIV-1.port
</allOneLine>
<allOneLine>
a=candidate:$L2 2 UDP 2605968473 $R-NAT-PUB-2.address $R-NAT-PUB-2.port typ srflx a=candidate:$L2 2 UDP 2605968473 $R-NAT-PUB-2.address $R-NAT-PUB-2.port typ srflx
/* raddr $R-PRIV-1.address rport $R-PRIV-2.port raddr $R-PRIV-1.address rport $R-PRIV-2.port
</allOneLine>
Figure 26: ICE SDP Updated Answer Figure 13: ICE SDP Updated Answer
4.2.2. Address and Port Dependant NAT 4.2.2. Address and Port Dependant NAT
4.2.2.1. STUN Failure 4.2.2.1. STUN Failure
This section highlights that while STUN is the preferred mechanism This section highlights that while STUN is the preferred mechanism
for traversal of NAT, it does not solve every case. The use of basic for traversal of NAT, it does not solve every case. The use of basic
STUN on its own will not guarantee traversal through every NAT type, STUN on its own will not guarantee traversal through every NAT type,
hence the recommendation that ICE is the preferred option. hence the recommendation that ICE is the preferred option.
skipping to change at page 45, line 4 skipping to change at page 49, line 4
| | | | | | | |
| x=====================================| | x=====================================|
| xIncoming Media sent to L-PRIV-1<<<<<<| | xIncoming Media sent to L-PRIV-1<<<<<<|
| x=====================================| | x=====================================|
| | | | | | | |
|(8)SIP ACK | | | |(8)SIP ACK | | |
|----------------->| | | |----------------->| | |
| |(9) SIP ACK | | | |(9) SIP ACK | |
| |------------------------------------>| | |------------------------------------>|
| | | | | | | |
Figure 27: Port/Address Dependant NAT with STUN - Failure Figure 14: Port/Address Dependant NAT with STUN - Failure
The example in Figure 27 is conveyed in the context of a client The example in Figure 14 is conveyed in the context of a client
behind the 'Port/Address Dependant' NAT initiating a call. It should behind the 'Port/Address Dependant' NAT initiating a call. It should
be noted that the same problem applies when a client receives a SIP be noted that the same problem applies when a client receives a SIP
invitation and is behind a Port/Address Dependant NAT. invitation and is behind a Port/Address Dependant NAT.
o In Figure 27 the client behind the NAT obtains a server reflexive o In Figure 14 the client behind the NAT obtains a server reflexive
representation using standard STUN mechanisms (1)-(4) that have representation using standard STUN mechanisms (1)-(4) that have
been used in previous examples in this document (e.g been used in previous examples in this document (e.g
Section 4.2.1.1.1). Section 4.2.1.1.1).
o The external mapped address (server reflexive) obtained is also o The external mapped address (server reflexive) obtained is also
used in the outgoing SDP contained in the SIP INVITE request(5). used in the outgoing SDP contained in the SIP INVITE request(5).
o In this example the client is still able to send media to the o In this example the client is still able to send media to the
external client. The problem occurs when the client outside the external client. The problem occurs when the client outside the
NAT tries to use the reflexive address supplied in the outgoing NAT tries to use the reflexive address supplied in the outgoing
INVITE request to traverse media back through the 'Port/Address INVITE request to traverse media back through the 'Port/Address
Dependent' NAT. Dependent' NAT.
o A 'Port/Address Dependant' NAT has differing rules from the o A 'Port/Address Dependant' NAT has differing rules from the
'Endpoint Independent' type of NAT (as defined in [11]). For any 'Endpoint Independent' type of NAT (as defined in RFC4787
internal IP address and port combination, data sent to a different [RFC4787]). For any internal IP address and port combination,
external destination does not provide the same public mapping at data sent to a different external destination does not provide the
the NAT. In Figure 27 the STUN query produced a valid external same public mapping at the NAT. In Figure 14 the STUN query
mapping for receiving media. This mapping, however, can only be produced a valid external mapping for receiving media. This
used in the context of the original STUN request that was sent to mapping, however, can only be used in the context of the original
the STUN server. Any packets that attempt to use the mapped STUN request that was sent to the STUN server. Any packets that
address, that do not originate from the STUN server IP address and attempt to use the mapped address, that do not originate from the
optionally port, will be dropped at the NAT. Figure 27 shows the STUN server IP address and optionally port, will be dropped at the
media being dropped at the NAT after (7) and before (8). This NAT. Figure 14 shows the media being dropped at the NAT after (7)
then leads to one way audio. and before (8). This then leads to one way audio.
4.2.2.2. TURN Usage Solution 4.2.2.2. TURN Usage Solution
As identified in Section 4.2.2.1, STUN provides a useful tool kit for As identified in Section 4.2.2.1, STUN provides a useful tool kit for
the traversal of the majority of NATs but fails with Port/Address the traversal of the majority of NATs but fails with Port/Address
Dependant NAT. This led to the development of the TURN usage Dependant NAT. This led to the development of the TURN usage
solution [12] which uses the STUN toolkit. It allows a client to solution [I-D.ietf-behave-turn] which uses the STUN toolkit to create
request a relayed address at the STUN server rather than a reflexive a profile. It allows a client to request a relayed address at the
representation. This then introduces a media relay in the path for STUN server rather than a reflexive representation. This then
NAT traversal (as described in Section 3.2.3). The following example introduces a media relay in the path for NAT traversal (as described
explains how the TURN usage solves the previous failure when using in Section 3.2.3). The following example explains how the TURN usage
STUN to traverse a 'Port/Address Dependant' type NAT. solves the previous failure when using STUN to traverse a 'Port/
Address Dependant' type NAT.
L Port/Address Dependant STUN [..] L Port/Address Dependant STUN [..]
NAT Server NAT Server
| | | | | | | |
|(1) Alloc Req | | | |(1) Alloc Req | | |
|Src=L-PRIV-1 | | | |Src=L-PRIV-1 | | |
|Dest=STUN-PUB-1 | | | |Dest=STUN-PUB-1 | | |
|----------------->| | | |----------------->| | |
| | | | | | | |
| |(2) Alloc Req | | | |(2) Alloc Req | |
skipping to change at page 47, line 44 skipping to change at page 51, line 45
|<<Incoming RTCP Relayed to L-PRIV-2<<| | |<<Incoming RTCP Relayed to L-PRIV-2<<| |
|=====================================| | |=====================================| |
| | | | | | | |
|(13)SIP ACK | | | |(13)SIP ACK | | |
|----------------->| | | |----------------->| | |
| | | | | | | |
| |(14) SIP ACK | | | |(14) SIP ACK | |
| |------------------------------------>| | |------------------------------------>|
| | | | | | | |
Figure 28: Port/Address Dependant NAT with TURN Usage - Success Figure 15: Port/Address Dependant NAT with TURN Usage - Success
o In this example, client 'L' issues a TURN allocate request(1) to o In this example, client 'L' issues a TURN allocate request(1) to
obtained a relay address at the STUN server. The request obtained a relay address at the STUN server. The request
traverses through the 'Port/Address Dependant' NAT and reaches the traverses through the 'Port/Address Dependant' NAT and reaches the
STUN server (2). The STUN server generates an Allocate response STUN server (2). The STUN server generates an Allocate response
(3) that contains both a server reflexive address (Map=NAT-PUB-1) (3) that contains both a server reflexive address (Map=NAT-PUB-1)
of the client and also a relayed address (Rel=STUN-PUB-2). The of the client and also a relayed address (Rel=STUN-PUB-2). The
relayed address maps to an address mapping on the STUN server relayed address maps to an address mapping on the STUN server
which is bound to the public pin hole that has been opened on the which is bound to the public pin hole that has been opened on the
NAT by the Allocate request. This results in any traffic sent to NAT by the Allocate request. This results in any traffic sent to
skipping to change at page 48, line 28 skipping to change at page 52, line 29
v=0 v=0
o=test 2890844342 2890842164 IN IP4 $L-PRIV-1 o=test 2890844342 2890842164 IN IP4 $L-PRIV-1
c=IN IP4 $STUN-PUB-2.address c=IN IP4 $STUN-PUB-2.address
t=0 0 t=0 0
m=audio $STUN-PUB-2.port RTP/AVP 0 m=audio $STUN-PUB-2.port RTP/AVP 0
a=rtcp:$STUN-PUB-3.port a=rtcp:$STUN-PUB-3.port
o On receiving the INVITE request, the UAS is able to stream media o On receiving the INVITE request, the UAS is able to stream media
and RTCP to the relay address (STUN-PUB-2 and STUN-PUB-3) at the and RTCP to the relay address (STUN-PUB-2 and STUN-PUB-3) at the
STUN server. As shown in Figure 28 (between messages (12) and STUN server. As shown in Figure 15 (between messages (12) and
(13), the media from the UAS is directed to the relayed address at (13), the media from the UAS is directed to the relayed address at
the STUN server. The STUN server then forwards the traffic to the the STUN server. The STUN server then forwards the traffic to the
open pin holes in the Port/Address Dependant NAT (NAT-PUB-1 and open pin holes in the Port/Address Dependant NAT (NAT-PUB-1 and
NAT-PUB-2). The media traffic is then able to traverse the 'Port/ NAT-PUB-2). The media traffic is then able to traverse the 'Port/
Address Dependant' NAT and arrives back at client 'L'. Address Dependant' NAT and arrives back at client 'L'.
o The TURN usage of STUN on its own will work for 'Port/Address o The TURN usage of STUN on its own will work for 'Port/Address
Dependent' and other types of NAT mentioned in this specification Dependent' and other types of NAT mentioned in this specification
but should only be used as a last resort. The relaying of media but should only be used as a last resort. The relaying of media
through an external entity is not an efficient mechanism for NAT through an external entity is not an efficient mechanism for NAT
traversal and comes at a high processing cost. traversal and comes at a high processing cost.
4.2.2.3. ICE Solution 4.2.2.3. ICE Solution
The previous two examples have highlighted the problem with using The previous two examples have highlighted the problem with using
core STUN usage for all forms of NAT traversal and a solution using core STUN usage for all forms of NAT traversal and a solution using
TURN usage for the Address/Port Dependant NAT case. As mentioned TURN usage for the Address/Port Dependant NAT case. As mentioned
previously in this document, the RECOMMENDED mechanism for traversing previously in this document, the RECOMMENDED mechanism for traversing
all varieties of NAT is using ICE, as detailed in Section 3.2.4. ICE all varieties of NAT is using ICE, as detailed in Section 3.2.4. ICE
makes use of core STUN, TURN usage and any other UNSAF[9] compliant makes use of core STUN, TURN usage and any other UNSAF[RFC3424]
protocol to provide a list of prioritized addresses that can be used compliant protocol to provide a list of prioritized addresses that
for media traffic. Detailed examples of ICE can be found in can be used for media traffic. Detailed examples of ICE can be found
Section 4.2.1.2.1. These examples are associated with an 'Endpoint in Section 4.2.1.2.1. These examples are associated with an
Independent' type NAT but can be applied to any NAT type variation, 'Endpoint Independent' type NAT but can be applied to any NAT type
including 'Address/Port Dependant' type NAT. The ICE procedures variation, including 'Address/Port Dependant' type NAT. The ICE
procedures carried out are the same. For a list of candidate procedures carried out are the same. For a list of candidate
addresses, a client will choose where to send media dependant on the addresses, a client will choose where to send media dependant on the
results of the STUN connectivity checks and associated priority results of the STUN connectivity checks and associated priority
(highest priority wins). It should be noted that the inclusion of a (highest priority wins). It should be noted that the inclusion of a
NAT displaying Address/Port Dependent properties does not NAT displaying Address/Port Dependent properties does not
automatically result in relayed media. In fact, ICE processing will automatically result in relayed media. In fact, ICE processing will
avoid use of media with the exception of two clients which both avoid use of media with the exception of two clients which both
happen to be behind a NAT using Address/Port Dependent happen to be behind a NAT using Address/Port Dependent
characteristics. The connectivity checks and associated selection characteristics. The connectivity checks and associated selection
algorithm enable traversal in this case. Figure 30 and following algorithm enable traversal in this case. Figure 16 and following
description provide a guide as to how this is achieved using the ICE description provide a guide as to how this is achieved using the ICE
connectivity checks. This is an abbreviated example that assumes connectivity checks. This is an abbreviated example that assumes
successful SIP offer/answer exchange and illustrates the connectivity successful SIP offer/answer exchange and illustrates the connectivity
check flow. check flow.
L Port/Address Dependent Address Independent R L Port/Address Dependent Address Independent R
NAT NAT NAT NAT
|========================================================| |========================================================|
| SIP OFFER/ANSWER EXCHANGE | | SIP OFFER/ANSWER EXCHANGE |
|========================================================| |========================================================|
skipping to change at page 51, line 4 skipping to change at page 55, line 4
| |----------------->| | | |----------------->| |
| |Src=L-NAT-PUB-1 | | | |Src=L-NAT-PUB-1 | |
| |Dest=R-NAT-PUB-1 | | | |Dest=R-NAT-PUB-1 | |
| | | | | | | |
| | |(14)Bind Resp | | | |(14)Bind Resp |
| | |----------------->| | | |----------------->|
| | |Src=R-NAT-PUB-1 | | | |Src=R-NAT-PUB-1 |
| | |Dest=R-PRIV-1 | | | |Dest=R-PRIV-1 |
| | | | | | | |
| |
Figure 30: Single Port/Address Dependant NAT - Success Figure 16: Single Port/Address Dependant NAT - Success
In this abbreviated example, Client R has already received a SIP In this abbreviated example, Client R has already received a SIP
INVITE request and is starting its connectivity checks with Client L. INVITE request and is starting its connectivity checks with Client L.
Client R generates a connectivity check (1) and sends to client L's Client R generates a connectivity check (1) and sends to client L's
information as presented in the SDP offer. The request arrives at information as presented in the SDP offer. The request arrives at
client L's Port/Address dependent NAT and fails to traverse as there client L's Port/Address dependent NAT and fails to traverse as there
is no security association. This would then move the connectivity is no security association. This would then move the connectivity
check to a failed state. In the mean time client L has received the check to a failed state. In the mean time client L has received the
SDP answer in the SIP request and will also commence connectivity SDP answer in the SIP request and will also commence connectivity
checks. A check is dispatched (3) to Client R. The check is able to checks. A check is dispatched (3) to Client R. The check is able to
traverse the NAT due to the association set up in the previously traverse the NAT due to the association set up in the previously
failed check(1). The full Bind request/response is shown in steps failed check(1). The full Bind request/response is shown in steps
(3)-(8). As part of a candidate pair, Client R will now successfully (3)-(8). As part of a candidate pair, Client R will now successfully
be able to complete the checks, as illustrated in steps (9)-(14). be able to complete the checks, as illustrated in steps (9)-(14).
The result is a successful pair of candidates that can be used The result is a successful pair of candidates that can be used
without the need to relay any media. without the need to relay any media.
Using the example described in Section 4.2.1.2.1, lets change the In conclusion, the only time media needs to be relayed is a result of
example so that both clients 'L' and 'R' are both behind NATs that clients both behind Address/Port Dependant NAT type. As you can see
have Address/Port Dependant behavior. from the example in this section, neither side would be able to
complete connectivity checks with the exception of the Relayed
Editors Note: TODO: Expand this to a full example. candidates.
5. IPv4-IPv6 Transition 5. IPv4-IPv6 Transition
This section describes how IPv6-only SIP user agents can communicate This section describes how IPv6-only SIP user agents can communicate
with IPv4-only SIP user agents. with IPv4-only SIP user agents. While the techniques discussed in
this draft primarily contain examples of traversing NATs to allow
communications between hosts in private and public networks, they are
by no means limited to such scenarios. The same NAT traversal
techniques can also be used to establish communication in a
heterogeneous network environment -- e.g., communication between an
IPv4 host and an IPv6 host.
5.1. IPv4-IPv6 Transition for SIP Signaling 5.1. IPv4-IPv6 Transition for SIP Signaling
IPv4-IPv6 translations at the SIP level usually take place at dual- IPv4-IPv6 translations at the SIP level usually take place at dual-
stack proxies that have both IPv4 and IPv6 DNS entries. Since this stack proxies that have both IPv4 and IPv6 DNS entries. Since this
translations do not involve NATs that are placed in the middle of two translations do not involve NATs that are placed in the middle of two
SIP entities, they fall outside the scope of this document. A SIP entities, they fall outside the scope of this document. A
detailed description of this type of translation can be found in [19] detailed description of this type of translation can be found in
[I-D.camarillo-sipping-v6-transition]
5.2. IPv4-IPv6 Transition for Media 5.2. IPv4-IPv6 Transition for Media
Figure 31 shows a network of IPv6 SIP user agents that has a relay Figure 17 shows a network of IPv6 SIP user agents that has a relay
with a pool of public IPv4 addresses. The IPv6 SIP user agents of with a pool of public IPv4 addresses. The IPv6 SIP user agents of
this IPv6 network need to communicate with users on the IPv4 this IPv6 network need to communicate with users on the IPv4
Internet. To do so, the IPv6 SIP user agents use the TURN usage to Internet. To do so, the IPv6 SIP user agents use the TURN usage to
obtain a public IPv4 address from the relay. The mechanism that an 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 IPv6 SIP user agent follows to obtain a public IPv4 address from a
relay using the TURN usage is the same as the one followed by a user relay using the TURN usage is the same as the one followed by a user
agent with a private IPv4 address to obtain a public IPv4 address. agent with a private IPv4 address to obtain a public IPv4 address.
The example in Figure 18 explains how to use the TURN usage to obtain
The example in Figure 32 explains how to use the TURN usage to obtain an IPv4 address and how to use the ANAT semantics
an IPv4 address and how to use the ANAT semantics [17] of the SDP [I-D.ietf-mmusic-anat] of the SDP grouping framework [RFC3388] to
grouping framework [8] to provide both IPv4 and IPv6 addresses for a provide both IPv4 and IPv6 addresses for a particular media stream.
particular media stream.
+----------+ +----------+
| / \ | | / \ |
/SIP \ /SIP \
/Phone \ /Phone \
/ \ / \
------------ ------------
IPv4 Network IPv4 Network
192.0.2.0/8 192.0.2.0/8
skipping to change at page 52, line 35 skipping to change at page 56, line 45
++ ++
|| ||
+-----++ +-----++
| IPv6 | | IPv6 |
| SIP | | SIP |
| user | | user |
| agent| | agent|
+------+ +------+
Figure 31: IPv6-IPv4 transition scenario Figure 17: IPv6-IPv4 transition scenario
IPv6 SIP TURN IPv4 SIP IPv6 SIP TURN IPv4 SIP
User Agent Server User Agent User Agent Server User Agent
| | | | | |
| (1) STUN Allocate | | | (1) STUN Allocate | |
| src=[2001:DB8::1]:30000 | | | src=[2001:DB8::1]:30000 | |
|------------------------------------>| | |------------------------------------>| |
| (2) TURN Resp | | | (2) TURN Resp | |
| rel=192.0.2.2:25000 | | | rel=192.0.2.2:25000 | |
| dest=[2001:DB8::1]:30000 | | | dest=[2001:DB8::1]:30000 | |
|<------------------------------------| | |<------------------------------------| |
skipping to change at page 53, line 37 skipping to change at page 57, line 37
| |<<<<<< Media <<<<<| | |<<<<<< Media <<<<<|
| |==================| | |==================|
|=====================================| | |=====================================| |
|<<<<<<<<<< Outgoing Media <<<<<<<<<<<| | |<<<<<<<<<< Outgoing Media <<<<<<<<<<<| |
|=====================================| | |=====================================| |
| | | | | |
| (5) SIP ACK | | | (5) SIP ACK | |
|------------------------------------------------------->| |------------------------------------------------------->|
| | | | | |
Figure 32: IPv6-IPv4 translation with TURN Figure 18: IPv6-IPv4 translation with TURN
o The IPv6 SIP user agent obtains a TURN-derived IPv4 address by o The IPv6 SIP user agent obtains a TURN-derived IPv4 address by
issuing a STUN Allocate request (1). The STUN server generates a issuing a STUN Allocate request (1). The STUN server generates a
response that contains a relayed IPv4 address using the TURN response that contains a relayed IPv4 address using the TURN
usage. This IPv4 address maps to the IPv6 source address of the usage. This IPv4 address maps to the IPv6 source address of the
STUN Allocate request, which the IPv6 address of the SIP user STUN Allocate request, which the IPv6 address of the SIP user
agent. This results in any traffic being sent to the IPv4 address agent. This results in any traffic being sent to the IPv4 address
provided by STUN server (192.0.2.2:25000) will be redirected to provided by STUN server (192.0.2.2:25000) will be redirected to
the IPv6 address of the SIP user agent ([2001:DB8::1]:30000). 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 o The TURN-derived address (192.0.2.2:25000) arrives back at the
skipping to change at page 54, line 26 skipping to change at page 58, line 26
a=mid:1 a=mid:1
m=audio 25000 RTP/AVP 0 m=audio 25000 RTP/AVP 0
c=IN IP4 192.0.2.2 c=IN IP4 192.0.2.2
a=rtcp:25001 a=rtcp:25001
a=mid:2 a=mid:2
o On receiving the INVITE request, the user agent server rejects the o On receiving the INVITE request, the user agent server rejects the
IPv6 media line by setting its port to zero in the answer and IPv6 media line by setting its port to zero in the answer and
starts sending media to the IPv4 address in the offer. The IPv6 starts sending media to the IPv4 address in the offer. The IPv6
user agent sends media through the relay as well, as shown in user agent sends media through the relay as well, as shown in
Figure 32. Figure 18.
6. Next Steps
What exactly is needed in this draft?. WG input is quickly required
now that ICE has become stable. A comprehensive list is needed that
will satisfy a wide cross section of the community.
o
7. Acknowledgments 6. Acknowledgments
The authors would like to thank the members of the IETF SIPPING WG The authors would like to thank the members of the IETF SIPPING WG
for their comments and suggestions. Detailed comments were provided for their comments and suggestions. Detailed comments were provided
by Francois Audet, kaiduan xie and Hans Persson. by Vijay Gurbani Francois Audet, kaiduan xie, Remi Denis-Courmont,
Hadriel Kaplan and Hans Persson.
8. References 7. References
8.1. Normative References 7.1. Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: A., Peterson, J., Sparks, R., Handley, M., and E.
Session Initiation Protocol", RFC 3261, June 2002. Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
"RTP: A Transport Protocol for Real-Time Applications", STD 64, Protocol (SIP): Locating SIP Servers", RFC 3263,
RFC 3550, July 2003. June 2002.
[3] Handley, M. and V. Jacobson, "SDP: Session Description [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[4] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Protocol Translation (NAT-PT)", RFC 2766, February 2000. Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
Session Description Protocol (SDP)", RFC 3264, June 2002. with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[6] Rosenberg, J. and H. Schulzrinne, "An Extension to the Session [RFC3581] Rosenberg, J. and H. Schulzrinne, "An Extension to the
Initiation Protocol (SIP) for Symmetric Response Routing", Session Initiation Protocol (SIP) for Symmetric Response
RFC 3581, August 2003. Routing", RFC 3581, August 2003.
[7] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol
Extension Header Field for Registering Non-Adjacent Contacts", (SIP) Extension Header Field for Registering Non-Adjacent
RFC 3327, December 2002. Contacts", RFC 3327, December 2002.
[8] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H.
"Grouping of Media Lines in the Session Description Protocol Schulzrinne, "Grouping of Media Lines in the Session
(SDP)", RFC 3388, December 2002. Description Protocol (SDP)", RFC 3388, December 2002.
[9] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Address Fixing (UNSAF) Across Network Address Translation", Self-Address Fixing (UNSAF) Across Network Address
RFC 3424, November 2002. Translation", RFC 3424, November 2002.
[10] Rosenberg, J., Huitema, C., Mahy, R., Matthews, P., and D. [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
Wing, "Session Traversal Utilities for (NAT) (STUN)", in Session Description Protocol (SDP)", RFC 3605,
draft-ietf-behave-rfc3489bis-07 (work in progress), July 2007. October 2003.
[11] Audet, F. and C. Jennings, "NAT Behavioral Requirements for [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
Unicast UDP", draft-ietf-behave-nat-udp-08 (work in progress), (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
October 2006. RFC 4787, January 2007.
[12] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
Underneath NAT (STUN)", draft-ietf-behave-turn-03 (work in BCP 131, RFC 4961, July 2007.
progress), March 2007.
[13] Jennings, C. and A. Hawrylyshen, "SIP Conventions for UAs with [I-D.ietf-sip-connect-reuse]
Outbound Only Connections", draft-jennings-sipping-outbound-01 Mahy, R., Gurbani, V., and B. Tate, "Connection Reuse in
(work in progress), February 2005. the Session Initiation Protocol (SIP)",
draft-ietf-sip-connect-reuse-09 (work in progress),
February 2008.
[14] Rosenberg, J., "Obtaining and Using Globally Routable User [I-D.ietf-behave-rfc3489bis]
Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-15 (work in progress),
February 2008.
[I-D.ietf-behave-turn]
Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)",
draft-ietf-behave-turn-07 (work in progress),
February 2008.
[I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-13 (work in progress), March 2008.
[I-D.ietf-sip-gruu]
Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-14 (work in progress), June 2007. (SIP)", draft-ietf-sip-gruu-15 (work in progress),
October 2007.
[15] Wing, D., "Symmetric RTP and RTCP Considered Helpful", [I-D.ietf-mmusic-ice]
draft-wing-mmusic-symmetric-rtprtcp-01 (work in progress), Rosenberg, J., "Interactive Connectivity Establishment
October 2004. (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[16] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A [I-D.ietf-mmusic-anat]
Protocol for Network Address Translator (NAT) Traversal for Camarillo, G., "The Alternative Network Address Types
Offer/Answer Protocols", draft-ietf-mmusic-ice-16 (work in Semantics (ANAT) for theSession Description Protocol
progress), June 2007. (SDP) Grouping Framework", draft-ietf-mmusic-anat-02 (work
in progress), October 2004.
[17] Camarillo, G., "The Alternative Network Address Types Semantics [I-D.ietf-mmusic-ice-tcp]
(ANAT) for theSession Description Protocol (SDP) Grouping Rosenberg, J., "TCP Candidates with Interactive
Framework", draft-ietf-mmusic-anat-02 (work in progress), Connectivity Establishment (ICE)",
October 2004. draft-ietf-mmusic-ice-tcp-06 (work in progress),
February 2008.
[18] Rosenberg, J., "TCP Candidates with Interactive Connectivity [I-D.ietf-avt-rtp-and-rtcp-mux]
Establishment (ICE", draft-ietf-mmusic-ice-tcp-03 (work in Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
progress), March 2007. Control Packets on a Single Port",
draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress),
August 2007.
8.2. Informative References 7.2. Informative References
[19] Camarillo, G., "IPv6 Transcition in the Session Initiation [I-D.camarillo-sipping-v6-transition]
Protocol (SIP)", draft-camarillo-sipping-v6-transition-00 (work Camarillo, G., "IPv6 Transcition in the Session Initiation
in progress), February 2005. Protocol (SIP)", draft-camarillo-sipping-v6-transition-00
(work in progress), February 2005.
Authors' Addresses Authors' Addresses
Chris Boulton Chris Boulton
Ubiquity Software Corporation Avaya
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@avaya.com
Jonathan Rosenberg Jonathan Rosenberg
Cisco Systems Cisco Systems
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany, NJ 07054 Parsippany, NJ 07054
Email: jdrosen@cisco.com Email: jdrosen@cisco.com
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Gonzalo.Camarillo@ericsson.com Email: Gonzalo.Camarillo@ericsson.com
Full Copyright Statement Full Copyright Statement
skipping to change at page 58, line 7 skipping to change at page 62, line 7
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Gonzalo.Camarillo@ericsson.com Email: Gonzalo.Camarillo@ericsson.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
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, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 58, line 44 skipping to change at line 2726
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 159 change blocks. 
449 lines changed or deleted 624 lines changed or added

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