draft-ietf-sipping-nat-scenarios-09.txt   draft-ietf-sipping-nat-scenarios-10.txt 
SIPPING Working Group C. Boulton, Ed. SIPPING Working Group C. Boulton
Internet-Draft Avaya Internet-Draft NS-Technologies
Intended status: BCP J. Rosenberg Intended status: BCP J. Rosenberg
Expires: March 21, 2009 Cisco Systems Expires: August 16, 2010 Skype
G. Camarillo G. Camarillo
Ericsson Ericsson
F. Audet F. Audet
Nortel Skype
September 17, 2008 February 12, 2010
Best Current Practices for NAT Traversal for Client-Server SIP Best Current Practices for NAT Traversal for Client-Server SIP
draft-ietf-sipping-nat-scenarios-09 draft-ietf-sipping-nat-scenarios-10
Abstract
Traversal of the Session Initiation Protocol (SIP) and the sessions
it establishes through Network Address Translators (NATs) is a
complex problem. Currently there are many deployment scenarios and
traversal mechanisms for media traffic. This document aims to
provide concrete recommendations and a unified method for NAT
traversal as well as documenting corresponding flows.
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 21, 2009. This Internet-Draft will expire on August 16, 2010.
Abstract Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Traversal of the Session Initiation Protocol (SIP) and the sessions This document is subject to BCP 78 and the IETF Trust's Legal
it establishes through Network Address Translators (NATs) is a Provisions Relating to IETF Documents
complex problem. Currently there are many deployment scenarios and (http://trustee.ietf.org/license-info) in effect on the date of
traversal mechanisms for media traffic. This document aims to publication of this document. Please review these documents
provide concrete recommendations and a unified method for NAT carefully, as they describe your rights and restrictions with respect
traversal as well as documenting corresponding flows. to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
4. Solution Technology Outline Description . . . . . . . . . . . 7 4. Solution Technology Outline Description . . . . . . . . . . . 10
4.1. SIP Signaling . . . . . . . . . . . . . . . . . . . . . . 8 4.1. SIP Signaling . . . . . . . . . . . . . . . . . . . . . . 10
4.1.1. Symmetric Response . . . . . . . . . . . . . . . . . . 8 4.1.1. Symmetric Response . . . . . . . . . . . . . . . . . . 10
4.1.2. Client Initiated Connections . . . . . . . . . . . . . 9 4.1.2. Client Initiated Connections . . . . . . . . . . . . . 11
4.2. Media Traversal . . . . . . . . . . . . . . . . . . . . . 9 4.2. Media Traversal . . . . . . . . . . . . . . . . . . . . . 11
4.2.1. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . 10 4.2.1. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . 12
4.2.2. RTCP . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.2. RTCP . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.3. ICE/STUN/TURN . . . . . . . . . . . . . . . . . . . . 10 4.2.3. ICE/STUN/TURN . . . . . . . . . . . . . . . . . . . . 12
5. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . . . 12 5. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . . . 15
5.1. Basic NAT SIP Signaling Traversal . . . . . . . . . . . . 12 5.1. Basic NAT SIP Signaling Traversal . . . . . . . . . . . . 15
5.1.1. Registration (Registrar/Edge Proxy Co-Located) . . . . 12 5.1.1. Registration (Registrar/Edge Proxy Co-Located) . . . . 15
5.1.2. Registration(Registrar/Edge Proxy not Co-Located) . . 16 5.1.2. Registration(Registrar/Edge Proxy not Co-Located) . . 18
5.1.3. Initiating a Session . . . . . . . . . . . . . . . . . 19 5.1.3. Initiating a Session . . . . . . . . . . . . . . . . . 21
5.1.4. Receiving an Invitation to a Session . . . . . . . . . 22 5.1.4. Receiving an Invitation to a Session . . . . . . . . . 24
5.2. Basic NAT Media Traversal . . . . . . . . . . . . . . . . 26 5.2. Basic NAT Media Traversal . . . . . . . . . . . . . . . . 29
5.2.1. Endpoint Independent NAT . . . . . . . . . . . . . . . 27 5.2.1. Endpoint Independent NAT . . . . . . . . . . . . . . . 30
5.2.2. Address and Port Dependant NAT . . . . . . . . . . . . 46 5.2.2. Address/Port-Dependent NAT . . . . . . . . . . . . . . 50
6. IPv4-IPv6 Transition . . . . . . . . . . . . . . . . . . . . . 54 6. IPv4-IPv6 Transition . . . . . . . . . . . . . . . . . . . . . 59
6.1. IPv4-IPv6 Transition for SIP Signaling . . . . . . . . . . 54 6.1. IPv4-IPv6 Transition for SIP Signaling . . . . . . . . . . 59
6.2. IPv4-IPv6 Transition for Media . . . . . . . . . . . . . . 55 7. Security Considerations . . . . . . . . . . . . . . . . . . . 60
7. Security Considerations . . . . . . . . . . . . . . . . . . . 56 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 9. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 62
9. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 57 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 63
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 57 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57 11.1. Normative References . . . . . . . . . . . . . . . . . . . 64
11.1. Normative References . . . . . . . . . . . . . . . . . . . 57 11.2. Informative References . . . . . . . . . . . . . . . . . . 65
11.2. Informative References . . . . . . . . . . . . . . . . . . 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60
Intellectual Property and Copyright Statements . . . . . . . . . . 61
1. Introduction 1. Introduction
NAT (Network Address Translators) traversal has long been identified NAT (Network Address Translators) traversal has long been identified
as a complex problem when considered in the context of the Session as a complex problem when considered in the context of the Session
Initiation Protocol (SIP)[RFC3261] and it's associated media such as Initiation Protocol (SIP)[RFC3261] and it's associated media such as
Real Time Protocol (RTP)[RFC3550]. The problem is exacerbated by the Real Time Protocol (RTP)[RFC3550]. The problem is exacerbated by the
variety of NATs that are available in the market place today and the variety of NATs that are available in the market place today and the
large number of potential deployment scenarios. Details of different large number of potential deployment scenarios. Details of different
NATs behavior can be found in 'NAT Behavioral Requirements for NATs behavior can be found in 'NAT Behavioral Requirements for
Unicast UDP' [RFC4787]. Unicast UDP' [RFC4787].
The IETF has been active on many specifications for the traversal of The IETF has been active on many specifications for the traversal of
NATs, including STUN[I-D.ietf-behave-rfc3489bis], NATs, including STUN[RFC5389], ICE[I-D.ietf-mmusic-ice], symmetric
ICE[I-D.ietf-mmusic-ice], symmetric response[RFC3581], symmetric response[RFC3581], symmetric RTP[RFC4961],
RTP[RFC4961], TURN[I-D.ietf-behave-turn], SIP TURN[I-D.ietf-behave-turn], SIP Outbound[RFC5626], SDP attribute for
Outbound[I-D.ietf-sip-outbound], SDP attribute for RTCP[RFC3605], and RTCP[RFC3605], Multiplexing RTP Data and Control Packets on a Single
others. These each represent a part of the solution, but none of Port[I-D.ietf-avt-rtp-and-rtcp-mux]and others. These each represent
them gives the overall context for how the NATs traversal problem is a part of the solution, but none of them gives the overall context
decomposed and solved through this collection of specifications. for how the NATs traversal problem is decomposed and solved through
This document serves to meet that need. this collection of specifications. This document serves to meet that
need.
This document provides a definitive set of 'Best Common Practices' to This document provides a definitive set of 'Best Common Practices' to
demonstrate the traversal of SIP and its associated media through NAT demonstrate the traversal of SIP and its associated media through NAT
devices. The document does not propose any new functionality but devices. The document does not propose any new functionality but
does draw on existing solutions for both core SIP signaling and media does draw on existing solutions for both core SIP signaling and media
traversal (as defined in Section 4). traversal (as defined in Section 4).
The best practices described in this document are for traditional The best practices described in this document are for traditional
"client- server"-style SIP. It seems likely that other groups using "client-server"-style SIP. This term refers to the traditional use
SIP, for example P2PSIP, will recommend these same practices between of the SIP protocol where User Agents talk to a series of
a P2PSIP client and a P2PSIP peer, but will recommend different intermediaries on a path to connect to a remote User Agent. It seems
practices for use between peers in a peer-to-peer network. likely that other groups using SIP, for example "Peer-to-Peer-
SIP(P2PSIP), will recommend these same practices between a P2PSIP
client and a P2PSIP peer, but will recommend different practices for
use between peers in a peer-to-peer network.
The draft is 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 flow scenarios. 3. A set of basic and advanced flow scenarios.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
It should be noted that the use of the term 'Endpoint Independent
NAT' in this document refers to a NAT that is both 'Endpoint
Independent Filtering NAT' and 'Endpoint Independent Mapping NAT' per
RFC 4787 [RFC2119] definition.
3. Problem Statement 3. Problem Statement
The traversal of SIP through NATs can be split into two categories The traversal of SIP through NATs can be split into two categories
that both require attention - The core SIP signaling and associated that both require attention - The core SIP signaling and associated
media traversal. This document assumes NATs that do not contain SIP- media traversal. This document assumes NATs that do not contain SIP-
aware Application Layer Gateways (ALG). Some NATs that are available aware Application Layer Gateways(ALG), which makes much of the issues
today contain such behavior that which makes much of the issues discussed in the document not applicable. ALGs have limitations (as
discussed in the document not applicable. It should also be noted per RFC 4787 [RFC4787]/section 7, RFC 3424 [RFC3424], and
that Session Border Controllers (SBC) doing 'hosted NAT traversal' [I-D.ietf-mmusic-ice]/section 18.6) and experience shows they can
also makes many of the discussions in this document moot. More have an adverse impact on the functionality of SIP. This includes
information can be obtained from [I-D.ietf-sipping-sbc-funcs] and problems such as requiring the media and signaling to traverse the
same device and not working with encrypted signaling and/or payload.
It should also be noted that Session Border Controllers (SBC) doing
'hosted NAT traversal' also make many of the discussions in this
document moot. More information can be obtained from
[I-D.ietf-sipping-sbc-funcs] and
[I-D.ietf-mmusic-media-path-middleboxes]. [I-D.ietf-mmusic-media-path-middleboxes].
The core SIP signaling has a number of issues when traversing through The core SIP signaling has a number of issues when traversing through
NATs. NATs.
Normal SIP response routing over UDP causes the response to be Normal SIP response routing over UDP causes the response to be
delivered to the source IP address specified in the topmost Via delivered to the source IP address specified in the topmost Via
header, or the "received" parameter of the topmost Via header. The header, or the "received" parameter of the topmost Via header. The
port is extracted from the SIP 'Via' header to complete the IP port is extracted from the SIP 'Via' header to complete the IP
address/port combination for returning the SIP response. While the address/port combination for returning the SIP response. While the
skipping to change at page 5, line 38 skipping to change at page 7, line 8
| | x<------------------------| | | | x<------------------------| |
| | | | | | | | | |
-------- | -------- -------- | --------
| |
| |
| |
Figure 2: Failed Request 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 connection and port 8023 and received by the proxy on port 5060, establishing a
opening a pin-hole in the NAT. The generation of a new request from connection and opening a pin-hole in the NAT. The generation of a
the proxy results in a request destined for the registered entity new request from the proxy results in a request destined for the
(Contact IP address) which is not reachable from the public network. registered entity (Contact IP address) which is not reachable from
This results in the new SIP request attempting to create a connection the public network. This results in the new SIP request attempting
to a private network address. This problem would be solved if the to create a connection to a private network address. This problem
original connection was re-used. While this problem has been would be solved if the original connection was re-used. While this
discussed in the context of connection orientated protocols such as problem has been discussed in the context of connection orientated
TCP, the problem exists for SIP signaling using any transport protocols such as TCP, the problem exists for SIP signaling using any
protocol. The impact of connection reuse of connection orientated transport protocol. The impact of connection reuse of connection
transports (TCP, TLS, etc) is discussed in more detail in the orientated transports (TCP, TLS, etc) is discussed in more detail in
connection reuse specification[I-D.ietf-sip-connect-reuse]. The the connection reuse specification[I-D.ietf-sip-connect-reuse]. The
approach proposed for this problem in Section 4 of this document is approach proposed for this problem in Section 4 of this document is
relevant for all SIP signaling in conjunction with connection reuse, relevant for all SIP signaling in conjunction with connection reuse,
regardless of the transport protocol. regardless of the transport protocol.
NAT policy can dictate that connections should be closed after a NAT policy can dictate that connections should be closed after a
period of inactivity. This period of inactivity may vary from a period of inactivity. This period of inactivity may vary from a
number seconds to hours. SIP signaling can not be relied upon to number seconds to hours. SIP signaling can not be relied upon to
keep alive connections for the following two reasons. Firstly, SIP keep alive connections for the following two reasons. Firstly, SIP
entities can sometimes have no signaling traffic for long periods of entities can sometimes have no signaling traffic for long periods of
time which has the potential to exceed the inactivity timer, and this time which has the potential to exceed the inactivity timer, and this
skipping to change at page 6, line 37 skipping to change at page 8, line 10
media such as RTP. The problem arises when a client advertises its media such as RTP. The problem arises when a client advertises its
address to receive media and it exists in a private network that is address to receive media and it exists in a private network that is
not accessible from outside the NAT. Figure 3 illustrates this not accessible from outside the NAT. Figure 3 illustrates this
problem. problem.
NAT Public Network NAT NAT Public Network NAT
| | | |
| | | |
| | | |
-------- | SIP Signaling Session | -------- -------- | SIP Signaling Session | --------
| |----------------------->---<--------------------| | | |---------------------->Proxy<-------------------| |
| | | | | | | | | | | |
| 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: Failed Media Figure 3: Failed Media
The connection addresses of the clients behind the NATs will The connection addresses of the clients behind the NATs will
nominally contain a private IPv4 or IPv6 address that is not routable nominally contain a private IPv4 address that is not routable across
across the public Internet. Exacerbating matters even more would be the public Internet. Exacerbating matters even more would be the
the tendency of Client A to send media to a destination address it tendency of Client A to send media to a destination address it
received in the signaling confirmation message -- an address that may received in the signaling confirmation message -- an address that may
actually correspond to a host within the private network who is actually correspond to a host within the private network who is
suddenly faced with incoming RTP packets (likewise, Client B may send suddenly faced with incoming RTP packets (likewise, Client B may send
media to a host within its private network who did not solicit these media to a host within its private network who did not solicit these
packets.) And finally, to complicate the problem even further, a packets.) And finally, to complicate the problem even further, a
number of different NAT topologies with different default behaviors number of different NAT topologies with different default behaviors
increases the difficulty of arriving at a unified approach. This increases the difficulty of arriving at a unified approach. This
problem exists for all media transport protocols that might be NATted problem exists for all media transport protocols that might be NATted
(e.g., TCP, UDP, SCTP, DCCP). (e.g., TCP, UDP, SCTP, DCCP).
skipping to change at page 7, line 21 skipping to change at page 8, line 40
packets.) And finally, to complicate the problem even further, a packets.) And finally, to complicate the problem even further, a
number of different NAT topologies with different default behaviors number of different NAT topologies with different default behaviors
increases the difficulty of arriving at a unified approach. This increases the difficulty of arriving at a unified approach. This
problem exists for all media transport protocols that might be NATted problem exists for all media transport protocols that might be NATted
(e.g., TCP, UDP, SCTP, DCCP). (e.g., TCP, UDP, SCTP, DCCP).
In general the problems associated with NAT traversal can be In general the problems associated with NAT traversal can be
categorized as follows. categorized as follows.
For signaling: For signaling:
o Responses do not re-use the NAT mapping and filtering entries o Responses do not re-use the NAT mapping and filtering entries
created by the request. created by the request.
o Inbound requests are filtered out by the NAT because there is no o Inbound requests are filtered out by the NAT because there is no
long-term connection between the client and the proxy. long-term connection between the client and the proxy.
For media: For media:
o Each endpoint has a variety of addresses. In different
situations, a different pair of (local endpoint, remote endpoint) o Each endpoint has a variety of addresses that can be used to reach
addresses should be used, and it is not clear when to use which it (e.g., native interface address, public NATted address). In
pair. different situations, a different pair of (local endpoint, remote
endpoint) addresses should be used, and it is not clear when to
use which pair.
o Many NATs filter inbound packets if the local endpoint has not o Many NATs filter inbound packets if the local endpoint has not
recently sent an outbound packet to the sender [same problem as recently sent an outbound packet to the sender.
second one under signaling].
o Classic RTCP usage is to run RTCP on the next highest port. o Classic RTCP usage is to run RTCP on the next highest port.
However, NATs do not necessarily preserve port adjacency. However, NATs do not necessarily preserve port adjacency.
o Classic RTP and RTCP usage is to use different 5-tuples for o Classic RTP and RTCP usage is to use different 5-tuples for
traffic in each direction. Though not really a problem, doing traffic in each direction. Though not really a problem, doing
this through NATs is more work than using the same 5-tuple in both this through NATs is more work than using the same 5-tuple in both
directions. directions.
4. Solution Technology Outline Description 4. Solution Technology Outline Description
As mentioned previously, the traversal of SIP through existing NATs As mentioned previously, the traversal of SIP through existing NATs
can be divided into two discrete problem areas: getting the core can be divided into two discrete problem areas: getting the SIP
signaling across NATs, and enabling media as specified by SDP in a signaling across NATs, and enabling media as specified by SDP in a
SIP offer/answer exchange to flow between endpoints. SIP offer/answer exchange to flow between endpoints.
4.1. SIP Signaling 4.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 NATs, as described in Section 3 of this document. traversing through NATs, as described in Section 3 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 NATs, regardless of transport in SIP signaling traversal through NATs, regardless of transport
protocol. It is RECOMMENDED that SIP compliant entities follow the protocol. It is RECOMMENDED 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.
4.1.1. Symmetric Response 4.1.1. Symmetric Response
As described in Section 3 of this document, when using an unreliable As described in Section 3 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 NATs. In present). Figure 4 illustrates the response traversal through the
such circumstances, SIP signaling requires a mechanism that will open pin hole using Symmetric techniques defined in RFC 3581
allow entities to override the basic response generation mechanism in [RFC3581].
RFC 3261 [RFC3261]. Once the SIP response is constructed, the
destination is still derived using the mechanisms described in RFC
3261 [RFC3261]. The port (to which the response will be sent),
however, will not equal that specified in the SIP 'Via' header field
but will be the port from which the original request was sent. This
results in the pin-hole opened for the requests traversal of the NAT
being reused, in a similar manner to that of reliable connection
orientated transport protocols such as TCP. Figure 4 illustrates the
response traversal through the open pin hole using this method.
Private NAT Public Private NAT Public
Network | Network Network | Network
| |
| |
-------- | -------- -------- | --------
| | | | | | | | | |
| |send request---------------------------------->| | | |send request---------------------------------->| |
| Client |<---------------------------------send response| Client | | Client |<---------------------------------send response| SIP |
| A | | | B | | A | | | Proxy |
| | | | | | | | | |
-------- | -------- -------- | --------
| |
| |
| |
Figure 4: Symmetric Response Figure 4: Symmetric Response
The outgoing request from Client A opens a pin hole in the NAT. The outgoing request from Client A opens a pin hole in the NAT. The
SIP Proxy would normally respond to the port available in the SIP Via
Client B would normally respond to the port available in the SIP Via header, as illustrated in Figure 1. The SIP Proxy honours the
header, as illustrated in Figure 1. Client B honors the 'rport' 'rport' parameter in the SIP Via header and routes the response to
parameter in the SIP Via header and routes the response to port from port from which it was sent. The exact functionality for this method
which it was sent. The exact functionality for this method of of response traversal is called 'Symmetric Response' and the details
response traversal is called 'Symmetric Response' and the details are are documented in RFC 3581 [RFC3581]. Additional requirements are
documented in RFC 3581 [RFC3581]. Additional requirements are
imposed on SIP entities in RFC 3581 [RFC3581] such as listening and imposed on SIP entities in RFC 3581 [RFC3581] such as listening and
sending SIP requests/responses from the same port. sending SIP requests/responses from the same port.
4.1.2. Client Initiated Connections 4.1.2. Client Initiated Connections
The second problem with SIP signaling, as defined in Section 3 and The second problem with SIP signaling, as defined in Section 3 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 NATs are documented in 'Managing Client outbound connections through NATs are documented in 'Managing Client
Initiated Connections in the Session Initiation Initiated Connections in the Session Initiation
Protocol(SIP)'[I-D.ietf-sip-outbound]. The document provides Protocol(SIP)'[RFC5626]. The document provides techniques that use a
techniques that use a unique User Agent instance identifier unique User Agent instance identifier (instance-id) in association
(instance-id) in association with a flow identifier (reg-id). The with a flow identifier (reg-id). The combination of the two
combination of the two identifiers provides a key to a particular identifiers provides a key to a particular connection (both UDP and
connection (both UDP and TCP) that is stored in association with TCP) that is stored in association with registration bindings. On
registration bindings. On receiving an incoming request to a SIP receiving an incoming request to a SIP Address-Of-Record (AOR), a
Address-Of-Record (AOR), a proxy/registrar routes to the associated proxy/registrar routes to the associated flow created by the
flow created by the registration and thus a route through NATs. It registration and thus a route through NATs. It also provides a
also provides a keepalive mechanism for clients to keep NATs bindings keepalive mechanism for clients to keep NATs bindings alive. This is
alive. This is achieved by multiplexing a ping/pong mechanism over achieved by multiplexing a ping/pong mechanism over the SIP signaling
the SIP signaling connection (STUN for UDP and CRLF/operating system connection (STUN for UDP and CRLF/operating system keepalive for
keepalive for reliable transports like TCP). Usage of reliable transports like TCP). Usage of [RFC5626] is RECOMMENDED.
[I-D.ietf-sip-outbound] is RECOMMENDED. This mechanism is not This mechanism is not transport specific and should be used for any
transport specific and should be used for any transport protocol. 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. Deployments should also consider the mechanism described function(e.g., SBC hosted NAT traversal). Deployments should also
in the Connection Reuse[I-D.ietf-sip-connect-reuse] specification for consider the mechanism described in the Connection
routing bi-directional messages securely between trusted SIP Proxy Reuse[I-D.ietf-sip-connect-reuse] specification for routing bi-
servers. directional messages securely between trusted SIP Proxy servers.
4.2. Media Traversal 4.2. Media Traversal
The issues of media traversal through NATs is not straight forward The issues of media traversal through NATs is not straight forward
and requires the combination of a number of traversal methodologies. and requires the combination of a number of traversal methodologies.
The technologies outlined in the remainder of this section provide The technologies outlined in the remainder of this section provide
the required solution set. the required solution set.
4.2.1. Symmetric RTP/RTCP 4.2.1. Symmetric RTP/RTCP
The primary problem identified in Section 3 of this document is that The primary problem identified in Section 3 of this document is that
internal IP address/port combinations can not be reached from the internal IP address/port combinations can not be reached from the
public side of NATs. In the case of media such as RTP, this will public side of NATs. In the case of media such as RTP, this will
result in no audio traversing NATs (as illustrated in Figure 3). To result in no audio traversing NATs (as illustrated in Figure 3). To
overcome this problem, a technique called 'Symmetric RTP/ overcome this problem, a technique called 'Symmetric RTP/
RTCP'[RFC4961] can be used. This involves a SIP endpoint both RTCP'[RFC4961] can be used. This involves a SIP endpoint both
sending and receiving RTP/RTCP traffic from the same IP address/port sending and receiving RTP/RTCP traffic from the same IP address/port
combination. 'Symmetric RTP/RTCP' SHOULD only be used for traversal combination. When operating behind a NAT and using the 'latching'
of RTP through NATs when one of the participants in a media session technique described in [I-D.ietf-mmusic-media-path-middleboxes], SIP
definitively knows that it is on the public network and is using a user agents SHOULD implement 'Symmetric RTP/RTCP'. This allows
'latching' technique as described in traversal of RTP across the NAT.
[I-D.ietf-mmusic-media-path-middleboxes]. Symmetric RTP/RTCP is
important for everything that might want to traverse a NAT or speak
with an endpoint that is behind a NAT - even if the remote endpoint
is an SBC performing 'hosted NAT traversal'.
4.2.2. RTCP 4.2.2. RTCP
Normal practice when selecting a port for defining RTP Control Normal practice when selecting a port for defining RTP Control
Protocol (RTCP) [RFC3550] is for consecutive order numbering (i.e Protocol (RTCP) [RFC3550] is for consecutive order numbering (i.e
select an incremented port for RTCP from that used for RTP). This select an incremented port for RTCP from that used for RTP). This
assumption causes RTCP traffic to break when traversing certain types assumption causes RTCP traffic to break when traversing certain types
of NATs due to blocked ports. To combat this problem a specific of NATs due to various reasons (e.g., already-allocated port,
randomized port allocation). To combat this problem a specific
address and port need to be specified in the SDP rather than relying address and port need to be specified in the SDP rather than relying
on such assumptions. RFC 3605 [RFC3605] defines an SDP attribute on such assumptions. RFC 3605 [RFC3605] defines an SDP attribute
that is included to explicitly specify transport connection that is included to explicitly specify transport connection
information for RTCP so a separate, explicit NAT binding can be set information for RTCP so a separate, explicit NAT binding can be set
up for the purpose. The address details can be obtained using any up for the purpose. The address details can be obtained using any
appropriate method including those detailed in this section (e.g. appropriate method including those detailed in this section (e.g.
STUN, TURN, ICE). STUN, TURN, ICE).
The use of RFC 3605 [RFC3605] MUST be supported. An alternative A further enhancement to RFC 3605 [RFC3605] is defined in
mechanism defined in [I-D.ietf-avt-rtp-and-rtcp-mux] specifies [I-D.ietf-avt-rtp-and-rtcp-mux] which specifies 'muxing' both RTP and
'muxing' both RTP and RTCP on the same IP/PORT combination. Using RTCP on the same IP/PORT combination.
this technique eliminates the problem but is still immature.
4.2.3. ICE/STUN/TURN 4.2.3. ICE/STUN/TURN
ICE, STUN and TURN are a suite of 3 inter-related protocols that ICE, STUN and TURN are a suite of 3 inter-related protocols that
combine to provide a complete media traversal solution for NATs. The combine to provide a complete media traversal solution for NATs. The
following sections provide details of each component part. following sections provide details of each component part.
4.2.3.1. STUN 4.2.3.1. STUN
Session Traversal Utilities for NAT or STUN is defined in RFC 3489bis Session Traversal Utilities for NAT or STUN is defined in RFC 5389
[I-D.ietf-behave-rfc3489bis]. STUN is a lightweight tool kit and [RFC5389]. STUN is a lightweight tool kit and protocol that provides
protocol that provides details of the external IP address/port details of the external IP address/port combination used by the NAT
combination used by the NAT device to represent the internal entity device to represent the internal entity on the public facing side of
on the public facing side of NATs. On learning of such an external NATs. On learning of such an external representation, a client can
representation, a client can use it accordingly as the connection use it accordingly as the connection address in SDP to provide NAT
address in SDP to provide NAT traversal. Using terminology defined traversal. Using terminology defined in the draft 'NAT Behavioral
in the draft 'NAT Behavioral Requirements for Unicast UDP' [RFC4787], Requirements for Unicast UDP' [RFC4787], STUN does work with
STUN does work with 'Endpoint Independent Mapping' but does not work 'Endpoint Independent Mapping' but does not work with either 'Address
with either 'Address Dependent Mapping' or 'Address and Port Dependent Mapping' or 'Address and Port Dependent Mapping' type NATs.
Dependent Mapping' type NATs. Using STUN with either of the previous Using STUN with either of the previous two NATs mappings to probe for
two NATs mappings to probe for the external IP address/port the external IP address/port representation will provide a different
representation will provide a different result to that required for result to that required for traversal by an alternative SIP entity.
traversal by an alternative SIP entity. The IP address/port The IP address/port combination deduced for the STUN server would be
combination deduced for the STUN server would be blocked for incoming blocked for RTP packets from the remote SIP user agent.
packets from an alterative SIP entity.
As mentioned in Section 4.1.2, STUN is also used as a client-to- As mentioned in Section 4.1.2, STUN is also used as a client-to-
server keep-alive mechanism to refresh NAT bindings. server keep-alive mechanism to refresh NAT bindings.
4.2.3.2. TURN 4.2.3.2. TURN
As described in the Section 4.2.3.1, the STUN protocol does not work As described in the Section 4.2.3.1, the STUN protocol does not work
for UDP traversal through certain identified NAT mappings. for UDP traversal through certain identified NAT mappings.
'Traversal Using Relays around NAT' is a usage of the STUN protocol 'Traversal Using Relays around NAT' is a usage of the STUN protocol
for deriving (from a TURN server) an address that will be used to for deriving (from a TURN server) an address that will be used to
relay packets towards a client. TURN provides an external address relay packets towards a client. TURN provides an external address
(globally routable) at a STUN server that will act as a media relay (globally routable) at a TUREN server that will act as a media relay
which attempts to allow traffic to reach the associated internal which attempts to allow traffic to reach the associated internal
address. The full details of the TURN specification are defined in address. The full details of the TURN specification are defined in
[I-D.ietf-behave-turn]. A TURN service will almost always provide [I-D.ietf-behave-turn]. A TURN service will almost always provide
media traffic to a SIP entity but it is RECOMMENDED that this method media traffic to a SIP entity but it is RECOMMENDED that this method
would only be used as a last resort and not as a general mechanism would only be used as a last resort and not as a general mechanism
for NAT traversal. This is because using TURN has high performance for NAT traversal. This is because using TURN has high performance
costs when relaying media traffic and can lead to unwanted latency. costs when relaying media traffic and can lead to unwanted latency.
4.2.3.3. ICE 4.2.3.3. ICE
Interactive Connectivity Establishment (ICE) is the RECOMMENDED Interactive Connectivity Establishment (ICE) is the RECOMMENDED
method for traversal of existing NATs if Symmetric RTP is not method for traversal of existing NATs if Symmetric RTP is not
appropriate. ICE is a methodology for using existing technologies sufficient (e.g., there isn't an SBC performing 'latching'). ICE is
such as STUN, TURN and any other UNSAF[RFC3424] compliant protocol to a methodology for using existing technologies such as STUN, TURN and
provide a unified solution. This is achieved by obtaining as many any other UNSAF[RFC3424] compliant protocol to provide a unified
representative IP address/port combinations as possible using solution. This is achieved by obtaining as many representative IP
technologies such as STUN/TURN (*note - an ICE endpoint can also use address/port combinations as possible using technologies such as
non-IETF mechanisms (e.g., NAT-PMP, UPnP IGD) to learn public IP STUN/TURN (*note - an ICE endpoint can also use other mechanisms
addresses and ports, and populate a=candidate lines with that (e.g., NAT-PMP, UPnP IGD) to learn public IP addresses and ports, and
information). Once the addresses are accumulated, they are all populate a=candidate lines with that information). Once the
included in the SDP exchange in a new media attribute called addresses are accumulated, they are all included in the SDP exchange
'candidate'. Each 'candidate' SDP attribute entry has detailed in a new media attribute called 'candidate'. Each 'candidate' SDP
connection information including a media address, priority and attribute entry has detailed connection information including a media
transport protocol. The appropriate IP address/port combinations are address, priority and transport protocol. The appropriate IP
used in the order specified by the priority. A client compliant to address/port combinations are used in the order specified by the
the ICE specification will then locally run STUN servers on all priority. A client compliant to the ICE specification will then
addresses being advertised using ICE. Each instance will undertake locally run STUN servers on all addresses being advertised using ICE.
connectivity checks to ensure that a client can successfully receive
media on the advertised address. Only connections that pass the Each instance will undertake connectivity checks to ensure that a
relevant connectivity checks are used for media exchange. The full client can successfully receive media on the advertised address.
details of the ICE methodology are contained in Only connections that pass the relevant connectivity checks are used
[I-D.ietf-mmusic-ice]. for media exchange. The full details of the ICE methodology are
contained in [I-D.ietf-mmusic-ice].
5. NAT Traversal Scenarios 5. NAT Traversal Scenarios
This section of the document includes detailed NAT traversal This section of the document includes detailed NAT traversal
scenarios for both SIP signaling and the associated media. scenarios for both SIP signaling and the associated media.
Signalling NAT traversal is achieved using [I-D.ietf-sip-outbound]. Signalling NAT traversal is achieved using [RFC5626].
5.1. Basic NAT SIP Signaling Traversal 5.1. Basic NAT SIP Signaling Traversal
The following sub-sections concentrate on SIP signaling traversal of The following sub-sections concentrate on SIP signaling traversal of
NATs. The scenarios include traversal for both reliable and un- NATs. The scenarios include traversal for both reliable and un-
reliable transport protocols. reliable transport protocols.
5.1.1. Registration (Registrar/Edge Proxy Co-Located) 5.1.1. Registration (Registrar/Edge Proxy Co-Located)
The set of scenarios in this section document basic signaling The set of scenarios in this section document basic signaling
skipping to change at page 13, line 30 skipping to change at page 15, line 50
|(2) 200 OK | | |(2) 200 OK | |
|<-----------------| | |<-----------------| |
| | | | | |
Figure 5: UDP Registration Figure 5: UDP Registration
In this example the client sends a SIP REGISTER request through a In this example the client sends a SIP REGISTER request through a
NAT. The client will include an 'rport' parameter as described in NAT. The client will include an 'rport' parameter as described in
Section 4.1.1 of this document for allowing traversal of UDP Section 4.1.1 of this document for allowing traversal of UDP
responses. The original request as illustrated in (1) in Figure 5 is responses. The original request as illustrated in (1) in Figure 5 is
a standard REGISTER message: a standard SIP REGISTER message:
Message 1: Message 1:
REGISTER sip:example.com SIP/2.0 REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2;rport;branch=z9hG4bKnashds7 Via: SIP/2.0/UDP 192.168.1.2;rport;branch=z9hG4bKnashds7
Max-Forwards: 70 Max-Forwards: 70
From: Bob <sip:bob@example.com>;tag=7F94778B653B From: Bob <sip:bob@example.com>;tag=7F94778B653B
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
Call-ID: 16CB75F21C70 Call-ID: 16CB75F21C70
CSeq: 1 REGISTER CSeq: 1 REGISTER
skipping to change at page 14, line 27 skipping to change at page 16, line 46
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 172.16.3.4). The response parameter of the SIP 'Via' header (address 172.16.3.4). The response
will not be sent to the port deduced from the SIP 'Via' header, as 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 [RFC3581] MUST be obeyed. Make note conventions defined in RFC 3581 [RFC3581] MUST be obeyed. Make note
of both the 'reg-id' and 'sip.instance' contact header parameters. of both the 'reg-id' and 'sip.instance' contact header parameters.
They are used to establish an Outbound connection tuple as defined in They are used to establish an Outbound connection tuple as defined in
[I-D.ietf-sip-outbound]. The connection tuple creation is clearly [RFC5626]. The connection tuple creation is clearly shown in
shown in Figure 5. This ensures that any inbound request that causes Figure 5. This ensures that any inbound request that causes a
a registration lookup will result in the re-use of the connection registration lookup will result in the re-use of the connection path
path established by the registration. This exonerates the need to established by the registration. This exonerates the need to
manipulate contact header URIs to represent a globally routable manipulate contact header URIs to represent a globally routable
address as perceived on the public side of a NAT. address as perceived on the public side of a NAT.
5.1.1.2. Connection Oriented Transport 5.1.1.2. Connection Oriented Transport
Registrar/ Registrar/
Bob NAT Edge Proxy Bob NAT Edge Proxy
| | | | | |
|(1) REGISTER | | |(1) REGISTER | |
|----------------->| | |----------------->| |
| | | | | |
| |(1) REGISTER | | |(1) REGISTER |
| |----------------->| | |----------------->|
| | | | | |
|*************************************| |*************************************|
skipping to change at page 15, line 29 skipping to change at page 17, line 33
| | | | | |
|(2) 200 OK | | |(2) 200 OK | |
|<-----------------| | |<-----------------| |
| | | | | |
Figure 6 Figure 6
Traversal of SIP REGISTER requests/responses using a reliable, Traversal of SIP REGISTER requests/responses using a reliable,
connection orientated protocol such as TCP does not require any connection orientated protocol such as TCP does not require any
additional core SIP signaling extensions, beyond the procedures additional core SIP signaling extensions, beyond the procedures
defined in [I-D.ietf-sip-outbound]. SIP responses will re-use the defined in [RFC5626]. SIP responses will re-use the connection
connection created for the initial REGISTER request, (1) from created for the initial REGISTER request, (1) from Figure 6:
Figure 6:
Message 1: Message 1:
REGISTER sip:example.com SIP/2.0 REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7 Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7
Max-Forwards: 70 Max-Forwards: 70
From: Bob <sip:bob@example.com>;tag=7F94778B653B From: Bob <sip:bob@example.com>;tag=7F94778B653B
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
Call-ID: 16CB75F21C70 Call-ID: 16CB75F21C70
CSeq: 1 REGISTER CSeq: 1 REGISTER
skipping to change at page 16, line 19 skipping to change at page 18, line 23
Call-ID: 16CB75F21C70 Call-ID: 16CB75F21C70
CSeq: 1 REGISTER CSeq: 1 REGISTER
Supported: path, outbound Supported: path, outbound
Require: outbound Require: outbound
Contact: <sip:bob@192.168.1.2;transport=tcp>;reg-id=1;expires=3600 Contact: <sip:bob@192.168.1.2;transport=tcp>;reg-id=1;expires=3600
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>" ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Length: 0 Content-Length: 0
This example was included to show the inclusion of the +sip.instance This example was included to show the inclusion of the +sip.instance
Contact header parameter as defined in the SIP Outbound specification Contact header parameter as defined in the SIP Outbound specification
[I-D.ietf-sip-outbound]. This creates an association tuple as [RFC5626]. This creates an association tuple as described in the
described in the previous example for future inbound requests previous example for future inbound requests directed at the newly
directed at the newly created registration binding with the only created registration binding with the only difference that the
difference that the association is with a TCP connection, not a UDP association is with a TCP connection, not a UDP pin hole binding.
pin hole binding.
5.1.2. Registration(Registrar/Edge Proxy not Co-Located) 5.1.2. Registration(Registrar/Edge 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.
Bob NAT Edge Proxy Registrar Bob NAT Edge Proxy Registrar
| | | | | | | |
|(1) REGISTER | | | |(1) REGISTER | | |
|----------------->| | | |----------------->| | |
| | | | | | | |
| |(1) REGISTER | | | |(1) REGISTER | |
| |----------------->| | | |----------------->| |
| | | | | | | |
| | |(2) REGISTER | | | |(2) REGISTER |
| | |----------------->| | | |----------------->|
| | | | | | | |
|********************************************************| |*************************************| |
| Create Outbound Connection Tuple | | Create Outbound Connection Tuple | |
|********************************************************| |*************************************| |
| | | | | | | |
| | |(3) 200 OK | | | |(3) 200 OK |
| | |<-----------------| | | |<-----------------|
| |(4)200 OK | | | |(4)200 OK | |
| |<-----------------| | | |<-----------------| |
| | | | | | | |
|(4)200 OK | | | |(4)200 OK | | |
|<-----------------| | | |<-----------------| | |
| | | | | | | |
Figure 7: Registration(Registrar/Proxy not Co-Located) Figure 7: Registration(Registrar/Proxy not Co-Located)
This scenario builds on the previous example contained in This scenario builds on the previous example contained in
Section 5.1.1.2. The primary difference being that the REGISTER Section 5.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 (1) in Figure 7. The Registrar. The important message to note is (1) 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 [I-D.ietf-sip-outbound]. At this point, the token as discussed in [RFC5626]. At this point, the proxy server
proxy server routes the SIP REGISTER message to the Registrar. The routes the SIP REGISTER message to the Registrar. The proxy will
proxy will create the connection tuple as described in SIP Outbound create the connection tuple as described in SIP Outbound at the same
at the same moment as the co-located example, but for subsequent moment as the co-located example, but for subsequent messages to
messages to arrive at the Proxy, the proxy needs to indicate its need arrive at the Proxy, the proxy needs to indicate its need to remain
to remain in the SIP signaling path. To achieve this the proxy in the SIP signaling path. To achieve this the proxy inserts to
inserts to REGISTER message (2) a SIP PATH extension header, as REGISTER message (2) a SIP PATH extension header, as defined in RFC
defined in RFC 3327 [RFC3327]. The previously created flow 3327 [RFC3327]. The previously created flow association token is
association token is inserted in a position within the Path header inserted in a position within the Path header where it can easily be
where it can easily be retrieved at a later point when receiving retrieved at a later point when receiving messages to be routed to
messages to be routed to the registration binding (in this case the the registration binding (in this case the user part of the SIP URI).
user part of the SIP URI). The REGISTER message of (1) includes a The REGISTER message of (1) includes a SIP Route header for the edge
SIP Route header for the edge proxy. proxy.
Message 1: Message 1:
REGISTER sip:example.com SIP/2.0 REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7 Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7
Max-Forwards: 70 Max-Forwards: 70
From: Bob <sip:bob@example.com>;tag=7F94778B653B From: Bob <sip:bob@example.com>;tag=7F94778B653B
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
Call-ID: 16CB75F21C70 Call-ID: 16CB75F21C70
CSeq: 1 REGISTER CSeq: 1 REGISTER
skipping to change at page 18, line 48 skipping to change at page 20, line 48
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 AOR binding. This all but guarantees directed towards the associated AOR binding. This all but guarantees
that all requests for the new registration will be forwarded to the that all requests for the new registration will be forwarded to the
Edge Proxy. In our example, the user part of the SIP 'Path' header Edge Proxy. In our example, the user part of the SIP 'Path' header
URI that was inserted by the Edge Proxy contains the unique token URI 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 [I-D.ietf-sip-outbound]. An example which builds on specification [RFC5626]. An example which builds on this scenario
this scenario (showing an inbound request to the AOR) is detailed in (showing an inbound request to the AOR) is detailed in
Section 5.1.4.2 of this document. Section 5.1.4.2 of this document.
5.1.3. Initiating a Session 5.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.
5.1.3.1. UDP 5.1.3.1. UDP
Initiating a call using UDP (the Edge Proxy and Authoritative Proxy Initiating a call using UDP (the Edge Proxy and Authoritative Proxy
funcationality are co-located). functionality are co-located).
Edge Proxy/ Edge Proxy/
Bob NAT Auth. Proxy Alice Bob NAT Auth. Proxy Alice
| | | | | | | |
|(1) INVITE | | | |(1) INVITE | | |
|----------------->| | | |----------------->| | |
| | | | | | | |
| |(1) INVITE | | | |(1) INVITE | |
| |----------------->| | | |----------------->| |
| | | | | | | |
skipping to change at page 21, line 21 skipping to change at page 23, line 21
CSeq: 1 INVITE CSeq: 1 INVITE
Supported: outbound Supported: outbound
Route: <sip:ep1.example.com;lr> Route: <sip:ep1.example.com;lr>
Contact: <sip:bob@192.168.1.2;ob> Contact: <sip:bob@192.168.1.2;ob>
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 5.1.1.1, 1. Firstly, as with the registration example in Section 5.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 4.1.1 and defined described in the 'Symmetric response' Section 4.1.1 and defined
in RFC 3581 [RFC3581]. in RFC 3581 [RFC3581].
2. Secondly, the contact inserted contains to ensure that all new 2. Secondly, the contact inserted contains to ensure that all new
requests will be sent to the same flow. Alternatively, a GRUU requests will be sent to the same flow. Alternatively, a GRUU
might have been used. See 4.3/[I-D.ietf-sip-outbound]. might have been used. See 4.3/[RFC5626].
In (2), the proxy inserts itself in the Via, adds the rport port In (2), the proxy inserts itself in the Via, adds the rport port
number in the previous Via header, adds the received parameter in the number in the previous Via header, adds the received parameter in the
previous Via, removes the Route header, and inserts a Record-Route previous Via, removes the Route header, and inserts a Record-Route
with a token. with a token.
Message 2: Message 2:
INVITE sip:alice@172.16.1.4 SIP/2.0 INVITE sip:alice@172.16.1.4 SIP/2.0
Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4bKnuiqisi Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4bKnuiqisi
skipping to change at page 22, line 16 skipping to change at page 24, line 31
5.1.3.2. Connection-oriented Transport 5.1.3.2. Connection-oriented 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 5.1.3.1. The primary difference when using described in Section 5.1.3.1. The primary difference when using
reliable transport protocols is that Symmetric response[RFC3581] are reliable transport protocols is that Symmetric response[RFC3581] are
not required for SIP responses to traverse a NAT. RFC 3261[RFC3261] not required for SIP responses to traverse a NAT. RFC 3261[RFC3261]
defines procedures for SIP response messages to be sent back on the defines procedures for SIP response messages to be sent back on the
same connection on which the request arrived. See section 9.5/ same connection on which the request arrived. See section 9.5/
[I-D.ietf-sip-outbound] for an example call flow of an outgoing call. [RFC5626] for an example call flow of an outgoing call.
5.1.4. Receiving an Invitation to a Session 5.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 5.1.1 and Section 5.1.2 previous registration scenario from Section 5.1.1 and Section 5.1.2
in this document. in this document.
5.1.4.1. Registrar/Proxy Co-located 5.1.4.1. Registrar/Proxy Co-located
skipping to change at page 23, line 26 skipping to change at page 25, line 46
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: <sip:alice@172.16.1.4> Contact: <sip:alice@172.16.1.4>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: .. Content-Length: ..
[SDP not shown] [SDP not shown]
The INVITE request matches the registration binding previously The INVITE request matches the registration binding previously
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 connection tuples.
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 that
The request is then dispatched on the appropriate flow. This is connection tuple. The request is then dispatched on the appropriate
message (2) from Figure 9 and is as follows: binding. This is message (2) from Figure 9 and is as follows:
INVITE sip:bob@192.168.1.2 SIP/2.0 INVITE sip:bob@192.168.1.2 SIP/2.0
Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4kmlds893jhsd Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4kmlds893jhsd
Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d
Max-Forwards: 69 Max-Forwards: 69
From: Alice <sip:alice@example.com>;tag=02935 From: Alice <sip:alice@example.com>;tag=02935
To: client bob <sip:bob@example.com> To: client bob <sip:bob@example.com>
Call-ID: klmvCxVWGp6MxJp2T2mb Call-ID: klmvCxVWGp6MxJp2T2mb
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: <sip:alice@172.16.1.4> Contact: <sip:alice@172.16.1.4>
skipping to change at page 26, line 38 skipping to change at page 29, line 17
mapping from the initial registration to the outbound proxy to be re- mapping from the initial registration to the outbound proxy to be re-
used. used.
5.2. Basic NAT Media Traversal 5.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[I-D.ietf-behave-rfc3489bis] and TURN [I-D.ietf-behave-turn] core STUN[RFC5389] and TURN [I-D.ietf-behave-turn] drafts.
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[I-D.ietf-mmusic-ice]. 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
skipping to change at page 27, line 38 skipping to change at page 30, line 21
The use of '$' signifies variable parts in example SIP messages. The use of '$' signifies variable parts in example SIP messages.
5.2.1. Endpoint Independent NAT 5.2.1. Endpoint Independent NAT
This section demonstrates an example of a client both initiating and This section demonstrates an example of a client both initiating and
receiving calls behind an 'Endpoint independent' NAT. An example is receiving calls behind an 'Endpoint independent' NAT. An example is
included for both STUN and ICE with ICE being the RECOMMENDED included for both STUN and ICE with ICE being the RECOMMENDED
mechanism for media traversal. mechanism for media traversal.
At this time there is no reliable test to determine if a host is
behind an 'endpoint independent filtering' NAT or an 'endpoint
independent mapping' NAT [I-D.ietf-behave-nat-behavior-discovery],
and the sort of failure that occurs in this situation is described in
Section 5.2.2.1. For this reason, ICE is RECOMMENDED over the
mechanism described in this section.
5.2.1.1. STUN Solution 5.2.1.1. STUN Solution
It is possible to traverse media through an 'Endpoint Independent NAT It is possible to traverse media through an 'Endpoint Independent NAT
using STUN. The remainder of this section provides simplified using STUN. The remainder of this section provides simplified
examples of the 'Binding Discovery' STUN as defined in examples of the 'Binding Discovery' STUN as defined in [RFC5389].
[I-D.ietf-behave-rfc3489bis]. The STUN messages have been simplified The STUN messages have been simplified and do not include 'Shared
and do not include 'Shared Secret' requests used to obtain the Secret' requests used to obtain the temporary username and password.
temporary username and password.
5.2.1.1.1. Initiating Session 5.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' 'Endpoint-Independent Mapping' properties using the STUN 'Binding
usage. It is assumed in this example that the STUN client and SIP Discovery' usage. It is assumed in this example that the STUN client
Client are co-located on the same physical machine. Note that some and SIP Client are co-located on the same physical machine. Note
SIP signaling messages have been left out for simplicity. that some SIP signaling messages have been left out for simplicity.
Client NAT STUN [..] Client NAT STUN [..]
Server Server
| | | | | | | |
|(1) BIND Req | | | |(1) BIND Req | | |
|Src=L-PRIV-1 | | | |Src=L-PRIV-1 | | |
|Dest=STUN-PUB | | | |Dest=STUN-PUB | | |
|----------------->| | | |----------------->| | |
| | | | | | | |
| |(2) BIND Req | | | |(2) BIND Req | |
skipping to change at page 34, line 14 skipping to change at page 37, line 15
will not pass through the NAT as no outbound association has been will not pass through the NAT as no outbound association has been
created with the far end client. Two way media communication has created with the far end client. Two way media communication has
now been established. now been established.
5.2.1.2. ICE Solution 5.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 4.2.3.3, regardless of the NAT type. The described in Section 4.2.3.3, 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 session. The example only Independent' NAT when initiating the session. The example only
covers ICE in association with the 'Binding Discovery' and TURN. covers ICE in association with the 'Binding Discovery' and TURN. It
is worth noting that the TURN server provides both STUN functions(to
learn your public mapping) and TURN functions (media relaying). It
is also worth noting that in example described in Section 5.2.1.2.1,
that both SIP clients 'L' and 'R' are contacting the same TURN
server. This is not necessary for ICE, STUN, TURN to function; all
that is necessary is that the STUN and TURN server(s) be in the same
addressing domain - that is accessible on the Internet.
5.2.1.2.1. Initiating Session 5.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 TURN NAT R L NAT STUN NAT R
Server Server
| | | | | | | | | |
|(1) Alloc Req | | | | |(1) Alloc Req | | | |
|Src=L-PRIV-1 | | | | |Src=L-PRIV-1 | | | |
|Dest=TURN-PUB-1 | | | | |Dest=TURN-PUB-1 | | | |
|--------------->| | | | |--------------->| | | |
| | | | | | | | | |
| |(2) Alloc Req | | | | |(2) Alloc Req | | |
| |Src=L-NAT-PUB-1 | | | | |Src=L-NAT-PUB-1 | | |
| |Dest=TURN-PUB-1 | | | | |Dest=TURN-PUB-1 | | |
skipping to change at page 42, line 4 skipping to change at page 45, line 11
| | | | | | | | | |
|(64) SIP 200 OK | | | | |(64) SIP 200 OK | | | |
|<---------------| | | | |<---------------| | | |
| | | | | | | | | |
|(65) SIP ACK | | | | |(65) SIP ACK | | | |
|------------------------------------------------->| | |------------------------------------------------->| |
| | | | | | | | | |
| | | |(66) SIP ACK | | | | |(66) SIP ACK |
| | | |--------------->| | | | |--------------->|
| | | | | | | | | |
Figure 13: Endpoint Independent NAT with ICE Figure 13: 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 TURN starts a local STUN client. The STUN client generates a TURN
Allocate request as indicated in (1) from Figure 13 which also Allocate request as indicated in (1) from Figure 13 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 to the public internet o The Allocate message (2) traverses the NAT to the public internet
towards the public TURN server. Note that the source address of towards the public TURN server. Note that the source address of
the Allocate request now represents the public address and port the Allocate request now represents the public address and port
from the public side of the NAT (L-NAT-PUB-1). from the public side of the NAT (L-NAT-PUB-1).
o The TURN server receives the Allocate request and processes it o The TURN server receives the Allocate request and processes it
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 TURN-relayed address that (3)). It also contains an appropriate TURN-relayed address that
can be used at the STUN server (see 'Rel=TURN-PUB-2'). can be used at the STUN server (see 'Rel=TURN-PUB-2').
o The Allocate response traverses back through the NAT using the o The Allocate response traverses back through the NAT using the
binding created by the initial Allocate request and presents the binding created by the initial Allocate request and presents the
new mapped address to the client (4). The process is repeated and new mapped address to the client (4). The process is repeated and
a second STUN derived set of address' are obtained, as illustrated a second STUN derived set of address' are obtained, as illustrated
in (5)-(8) in Figure 13. At this point the User Agent behind the in (5)-(8) in Figure 13. At this point the User Agent behind the
NAT has pairs of derived external server reflexive and relayed NAT has pairs of derived external server reflexive and relayed
representations. The client would be free to gather any number of representations. The client can also gather IP addresses and
external representations using any UNSAF[RFC3424] compliant ports via other mechanisms (e.g., NAT-PMP, UPnP IGD)." or similar.
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[I-D.ietf-mmusic-ice], as shown defined in the ICE specification[I-D.ietf-mmusic-ice], as shown
below in Figure 14: below in Figure 14:
v=0 v=0
o=test 2890844526 2890842807 IN IP4 $L-PRIV-1 o=test 2890844526 2890842807 IN IP4 $L-PRIV-1
c=IN IP4 $L-PRIV-1.address c=IN IP4 $L-PRIV-1.address
skipping to change at page 43, line 27 skipping to change at page 46, line 27
typ host typ host
a=candidate:$L2 1 UDP 1694498815 $L-NAT-PUB-1.address $L-NAT-PUB-1.port a=candidate:$L2 1 UDP 1694498815 $L-NAT-PUB-1.address $L-NAT-PUB-1.port
typ srflx raddr $L-PRIV-1.address rport $L-PRIV-1.port typ srflx raddr $L-PRIV-1.address rport $L-PRIV-1.port
a=candidate:$L2 2 UDP 1694498814 $L-NAT-PUB-2.address $L-NAT-PUB-2.port a=candidate:$L2 2 UDP 1694498814 $L-NAT-PUB-2.address $L-NAT-PUB-2.port
typ srflx raddr $L-PRIV-1.address rport $L-PRIV-2.port typ srflx raddr $L-PRIV-1.address rport $L-PRIV-2.port
a=candidate:$L3 1 UDP 16777215 $STUN-PUB-2.address $STUN-PUB-2.port a=candidate:$L3 1 UDP 16777215 $STUN-PUB-2.address $STUN-PUB-2.port
typ relay raddr $L-PRIV-1.address rport $L-PRIV-1.port typ relay raddr $L-PRIV-1.address rport $L-PRIV-1.port
a=candidate:$L3 2 UDP 16777214 $STUN-PUB-3.address $STUN-PUB-3.port a=candidate:$L3 2 UDP 16777214 $STUN-PUB-3.address $STUN-PUB-3.port
typ relay raddr $L-PRIV-1.address rport $L-PRIV-2.port typ relay raddr $L-PRIV-1.address rport $L-PRIV-2.port
Figure 14: ICE SDP Offer Figure 14: 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.
skipping to change at page 44, line 29 skipping to change at page 47, line 31
typ host typ host
a=candidate:$L2 1 UDP 1694498815 $R-NAT-PUB-1.address $R-NAT-PUB-1.port a=candidate:$L2 1 UDP 1694498815 $R-NAT-PUB-1.address $R-NAT-PUB-1.port
typ srflx raddr $R-PRIV-1.address rport $R-PRIV-1.port typ srflx raddr $R-PRIV-1.address rport $R-PRIV-1.port
a=candidate:$L2 2 UDP 1694498814 $R-NAT-PUB-2.address $R-NAT-PUB-2.port a=candidate:$L2 2 UDP 1694498814 $R-NAT-PUB-2.address $R-NAT-PUB-2.port
typ srflx raddr $R-PRIV-1.address rport $R-PRIV-1.port typ srflx raddr $R-PRIV-1.address rport $R-PRIV-1.port
a=candidate:$L3 1 UDP 16777215 $STUN-PUB-2.address $STUN-PUB-4.port a=candidate:$L3 1 UDP 16777215 $STUN-PUB-2.address $STUN-PUB-4.port
typ relay raddr $R-PRIV-1.address rport $R-PRIV-1.port typ relay raddr $R-PRIV-1.address rport $R-PRIV-1.port
a=candidate:$L3 2 UDP 16777214 $STUN-PUB-3.address $STUN-PUB-5.port a=candidate:$L3 2 UDP 16777214 $STUN-PUB-3.address $STUN-PUB-5.port
typ relay raddr $R-PRIV-1.address rport $R-PRIV-1.port typ relay raddr $R-PRIV-1.address rport $R-PRIV-1.port
Figure 15: ICE SDP Answer Figure 15: 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 46, line 19 skipping to change at page 49, line 25
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
a=candidate:$L2 1 UDP 2203948363 $L-NAT-PUB-1.address $L-NAT-PUB-1.port 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 typ srflx raddr $L-PRIV-1.address rport $L-PRIV-1.port
a=candidate:$L2 2 UDP 2172635342 $L-NAT-PUB-2.address $L-NAT-PUB-2.port 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 typ srflx raddr $L-PRIV-1.address rport $L-PRIV-2.port
Figure 16: ICE SDP Updated Offer Figure 16: 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
a=candidate:$L2 1 UDP 2984756463 $R-NAT-PUB-1.address $R-NAT-PUB-1.port 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 typ srflx raddr $R-PRIV-1.address rport $R-PRIV-1.port
a=candidate:$L2 2 UDP 2605968473 $R-NAT-PUB-2.address $R-NAT-PUB-2.port 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 typ srflx raddr $R-PRIV-1.address rport $R-PRIV-2.port
Figure 17: ICE SDP Updated Answer Figure 17: ICE SDP Updated Answer
5.2.2. Address and Port Dependant NAT 5.2.2. Address/Port-Dependent NAT
5.2.2.1. STUN Failure 5.2.2.1. STUN Failure
This section highlights that while using STUN techniques is the This section highlights that while using STUN techniques is the
preferred mechanism for traversal of NAT, it does not solve every preferred mechanism for traversal of NAT, it does not solve every
case. The use of basic STUN on its own will not guarantee traversal case. The use of basic STUN on its own will not guarantee traversal
through every NAT type, hence the recommendation that ICE is the through every NAT type, hence the recommendation that ICE is the
preferred option. preferred option.
Client PORT/ADDRESS-Dependant STUN [..] Client PORT/ADDRESS-Dependant STUN [..]
skipping to change at page 48, line 36 skipping to change at page 52, line 40
produced a valid external mapping for receiving media. This produced a valid external mapping for receiving media. This
mapping, however, can only be used in the context of the original mapping, however, can only be used in the context of the original
STUN request that was sent to the STUN server. Any packets that STUN request that was sent to the STUN server. Any packets that
attempt to use the mapped address, that do not originate from the attempt to use the mapped address, that do not originate from the
STUN server IP address and optionally port, will be dropped at the STUN server IP address and optionally port, will be dropped at the
NAT. Figure 18 shows the media being dropped at the NAT after (7) NAT. Figure 18 shows the media being dropped at the NAT after (7)
and before (8). This then leads to one way audio. and before (8). This then leads to one way audio.
5.2.2.2. TURN Solution 5.2.2.2. TURN Solution
As identified in Section Section 5.2.2.1, STUN provides a useful tool As identified in Section 5.2.2.1, STUN provides a useful tool for the
for the traversal of the majority of NATs but fails with Port/Address traversal of the majority of NATs but fails with Port/Address
Dependent NAT. The TURN extensions [I-D.ietf-behave-turn] address Dependent NAT. The TURN extensions [I-D.ietf-behave-turn] address
this scenario. TURN extends STUN to allow a client to request a this scenario. TURN extends STUN to allow a client to request a
relayed address at the TURN server rather than a reflexive relayed address at the TURN server rather than a reflexive
representation. This then introduces a media relay in the path for representation. This then introduces a media relay in the path for
NAT traversal (as described in Section 4.2.3.2). The following NAT traversal (as described in Section 4.2.3.2). The following
example explains how TURN solves the previous failure when using STUN example explains how TURN solves the previous failure when using STUN
to traverse a 'Port/ Address Dependent' type NAT. to traverse a 'Port/Address Dependent' type NAT. It should be noted
that TURN works most effectively when used in conjunction with ICE.
Using TURN on its own results in all media being relayed through a
TURN server which is not efficient.
L Port/Address-Dependant STUN [..] L Port/Address-Dependant TURN [..]
NAT Server NAT Server
| | | | | | | |
|(1) Alloc Req | | | |(1) Alloc Req | | |
|Src=L-PRIV-1 | | | |Src=L-PRIV-1 | | |
|Dest=STUN-PUB-1 | | | |Dest=STUN-PUB-1 | | |
|----------------->| | | |----------------->| | |
| | | | | | | |
| |(2) Alloc Req | | | |(2) Alloc Req | |
| |Src=NAT-PUB-1 | | | |Src=NAT-PUB-1 | |
| |Dest=STUN-PUB-1 | | | |Dest=STUN-PUB-1 | |
skipping to change at page 51, line 46 skipping to change at page 56, line 12
entity is not an efficient mechanism for NAT traversal and comes entity is not an efficient mechanism for NAT traversal and comes
at a high processing cost. at a high processing cost.
5.2.2.3. ICE Solution 5.2.2.3. ICE Solution
The previous two examples have highlighted the problem with using The previous two examples have highlighted the problem with using
core STUN for all forms of NAT traversal and a solution using TURN core STUN for all forms of NAT traversal and a solution using TURN
for the Address/Port-Dependent NAT case. The RECOMMENDED mechanism for the Address/Port-Dependent NAT case. The RECOMMENDED mechanism
for traversing all varieties of NAT is using ICE, as detailed in for traversing all varieties of NAT is using ICE, as detailed in
Section 4.2.3.3. ICE makes use of core STUN, TURN and any other Section 4.2.3.3. ICE makes use of core STUN, TURN and any other
UNSAF[RFC3424] compliant protocol to provide a list of prioritized mechanism (e.g., NAT-PMP, UPnP IGD) to provide a list of prioritized
addresses that can be used for media traffic. Detailed examples of addresses that can be used for media traffic. Detailed examples of
ICE can be found in Section 5.2.1.2.1. These examples are associated ICE can be found in Section 5.2.1.2.1. These examples are associated
with an 'Endpoint-Independent' type NAT but can be applied to any NAT with an 'Endpoint-Independent' type NAT but can be applied to any NAT
type variation, including 'Address/Port-Dependant' type NAT. The ICE type 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
skipping to change at page 55, line 5 skipping to change at page 60, line 5
6.1. IPv4-IPv6 Transition for SIP Signaling 6.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 detailed description of this type of translation can be found in
[I-D.ietf-sipping-v6-transition] [I-D.ietf-sipping-v6-transition]
6.2. IPv4-IPv6 Transition for Media
Figure 21 shows a network of IPv6 SIP user agents that has a relay
with a pool of public IPv4 addresses. The IPv6 SIP user agents of
this IPv6 network need to communicate with users on the IPv4
Internet. To do so, the IPv6 SIP user agents use TURN to obtain a
set of public IPv4 address and port pairs from the relay (for RTP and
RTCP). The mechanism that an IPv6 SIP user agent follows to obtain
public IPv4 address and port pairs from a relay using TURN is the
same as the one followed by a user agent with a private IPv4 address
to obtain public IPv4 address and port pairs. The example below
explains how a UA in an IPv6-only network can use ICE
[I-D.ietf-mmusic-ice] to communicate with a SIP Phone in an IPv4-only
network. Note that no server reflective addresses are used in this
example.
+----------+
| / \ |
/SIP \
/Phone \
/ \
------------
| |
| |
192.0.2.2:25000 | | 192.0.2.2:25123
RTP RTCP
+-------------+
| TURN Server |
+-------------+
IPv4 Network | |
+---------+
| |
----------------------| NAT |---------------------
| |
+---------+
IPv6 Network | |
| |
| |
[2001:DB8::1]:30000 RTP RTCP [2001:DB8::1]:30001
+----------+
| IPv6 SIP |
| UA |
+----------+
Figure 21: IPv6-IPv4 transition scenario
The IPv6 UA obtains a TURN-derived IPv4 address and port pair for its
RTP port and another one for its RTCP port by issuing 2 TURN Allocate
requests. The TURN server generates responses containing relayed
IPv4 addressee and port pairs for both RTP and RTCP ports. These
IPv4 addresses and port pairs map to the IPv6 source addressee and
port pairs. The result of any UDP packets sent to the IPv4 address
and port pairs provided by the TURN server (i.e., 192.0.2.2:25000 for
RTP and 192.0.2.2:25123 for RTCP) with be redirected to the IPv6 IP
address and port pairs of the SIP UA (i.e., [2001:DB8::1]:30000 for
RTP and [2001:DB8::1]:30001 for RTCP).
When the UA builds the original Offer, it includes 2 candidates: one
for the host IPv6 address and another for the relay IPv4 address.
When computing the priority for the candidate, we will use a type
preference of 126 for the host address candidate, and of 0 for the
relay address candidate, a local preference of 65535 for both
candidates, and a component ID of 1 for RTP and 2 for RTCP for both
candidates. This will generate a priority of 2130706431 for the host
address, and of 16777215 for the relay address. The default
candidate is the relay address candidate. The Offer will look as
follows.
v=0
o=test 2890844342 2890842164 IN IP6 2001:DB8::1
c=IN IP4 192.0.2.2
t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 25000 RTP/AVP 0
a=rtcp:25123
a=candidate:1 1 UDP 2130706431 [2001:DB8::1] 30000 typ host
a=candidate:1 2 UDP 2130706430 [2001:DB8::1] 30001 typ host
a=candidate:2 1 UDP 16777215 192.0.2.2 25000 typ relay
raddr [2001:DB8::1] rport 30000
a=candidate:2 2 UDP 16777214 192.0.2.2 25123 typ relay
raddr [2001:DB8::1] rport 30001
The Offer is sent in an INVITE request which gets routed to the IPv4-
only UA, which will choose the IPv4 candidate as per normal ICE
procedures.
7. Security Considerations 7. Security Considerations
There are no Security Considerations beyond the ones inherited by There are no Security Considerations beyond the ones inherited by
reference. reference.
8. IANA Considerations 8. IANA Considerations
There are no IANA Considerations. There are no IANA Considerations.
9. IAB Considerations 9. IAB Considerations
There are no IAB considerations. There are no IAB considerations.
10. Acknowledgments 10. 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. Expert review and contribution for their comments and suggestions. Expert review and detailed
was provided by Francois Audet. contribution including text was provided by Dan Wing who was
supportive throughout.
Detailed comments were provided by Vijay Gurbani, kaiduan xie, Remi Detailed comments were provided by Vijay Gurbani, kaiduan xie, Remi
Denis-Courmont, Hadriel Kaplan, Phillip Matthews, Dan Wing, Spencer Denis-Courmont, Hadriel Kaplan, Phillip Matthews, Spencer Dawkins and
Dawkins and Hans Persson. Hans Persson.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-avt-rtp-and-rtcp-mux]
Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port",
draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress),
August 2007.
[I-D.ietf-behave-turn]
Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)",
draft-ietf-behave-turn-16 (work in progress), July 2009.
[I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-sip-connect-reuse]
Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in
the Session Initiation Protocol (SIP)",
draft-ietf-sip-connect-reuse-14 (work in progress),
August 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263, Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002. June 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3581] Rosenberg, J. and H. Schulzrinne, "An Extension to the
Session Initiation Protocol (SIP) for Symmetric Response
Routing", RFC 3581, August 2003.
[RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol
(SIP) Extension Header Field for Registering Non-Adjacent (SIP) Extension Header Field for Registering Non-Adjacent
Contacts", RFC 3327, December 2002. Contacts", RFC 3327, December 2002.
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Schulzrinne, "Grouping of Media Lines in the Session Jacobson, "RTP: A Transport Protocol for Real-Time
Description Protocol (SDP)", RFC 3388, December 2002. Applications", STD 64, RFC 3550, July 2003.
[RFC3581] Rosenberg, J. and H. Schulzrinne, "An Extension to the
Session Initiation Protocol (SIP) for Symmetric Response
Routing", RFC 3581, August 2003.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605, in Session Description Protocol (SDP)", RFC 3605,
October 2003. October 2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
BCP 131, RFC 4961, July 2007. BCP 131, RFC 4961, July 2007.
[I-D.ietf-sip-connect-reuse] [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
Mahy, R., Gurbani, V., and B. Tate, "Connection Reuse in "Session Traversal Utilities for NAT (STUN)", RFC 5389,
the Session Initiation Protocol (SIP)", October 2008.
draft-ietf-sip-connect-reuse-11 (work in progress),
July 2008.
[I-D.ietf-behave-rfc3489bis]
Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-18 (work in progress),
July 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-09 (work in progress), July 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-15 (work in progress), June 2008.
[I-D.ietf-sip-gruu]
Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-15 (work in progress),
October 2007.
[I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-avt-rtp-and-rtcp-mux] [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Initiated Connections in the Session Initiation Protocol
Control Packets on a Single Port", (SIP)", RFC 5626, October 2009.
draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress),
August 2007.
11.2. Informative References 11.2. Informative References
[I-D.ietf-sipping-sbc-funcs] [I-D.ietf-behave-nat-behavior-discovery]
Hautakorpi, J., Camarillo, G., Penfield, B., Hawrylyshen, MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery
A., and M. Bhatia, "Requirements from SIP (Session Using STUN", draft-ietf-behave-nat-behavior-discovery-08
Initiation Protocol) Session Border Control Deployments", (work in progress), September 2009.
draft-ietf-sipping-sbc-funcs-06 (work in progress),
June 2008.
[I-D.ietf-mmusic-media-path-middleboxes] [I-D.ietf-mmusic-media-path-middleboxes]
Stucker, B. and H. Tschofenig, "Analysis of Middlebox Stucker, B. and H. Tschofenig, "Analysis of Middlebox
Interactions for Signaling Protocol Communication along Interactions for Signaling Protocol Communication along
the Media Path", the Media Path",
draft-ietf-mmusic-media-path-middleboxes-01 (work in draft-ietf-mmusic-media-path-middleboxes-02 (work in
progress), July 2008. progress), March 2009.
[I-D.ietf-sipping-sbc-funcs]
Hautakorpi, J., Camarillo, G., Penfield, B., Hawrylyshen,
A., and M. Bhatia, "Requirements from SIP (Session
Initiation Protocol) Session Border Control Deployments",
draft-ietf-sipping-sbc-funcs-08 (work in progress),
January 2009.
[I-D.ietf-sipping-v6-transition] [I-D.ietf-sipping-v6-transition]
Camarillo, G., "IPv6 Transition in the Session Initiation Camarillo, G., "IPv6 Transition in the Session Initiation
Protocol (SIP)", draft-ietf-sipping-v6-transition-07 (work Protocol (SIP)", draft-ietf-sipping-v6-transition-07 (work
in progress), August 2007. in progress), August 2007.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002. Translation", RFC 3424, November 2002.
Authors' Addresses Authors' Addresses
Chris Boulton Chris Boulton
Avaya NS-Technologies
Eastern Business Park
St Mellons
Cardiff, South Wales CF3 5EA
Email: cboulton@avaya.com Email: chris@ns-technologies.com
Jonathan Rosenberg Jonathan Rosenberg
Cisco Systems Skype
600 Lanidex Plaza
Parsippany, NJ 07054
Email: jdrosen@cisco.com Email: jdrosen@jdrosen.net
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
Francois Audet Francois Audet
Nortel Skype
4655 Great America Parkway
Santa Clara CA 95054
US
Email: audet@nortel.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any Email: francois.audet@skype.net
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 94 change blocks. 
449 lines changed or deleted 351 lines changed or added

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