draft-ietf-sipping-nat-scenarios-05.txt   draft-ietf-sipping-nat-scenarios-06.txt 
SIPPING Working Group C. Boulton, Ed. SIPPING Working Group C. Boulton, Ed.
Internet-Draft Ubiquity Software Corporation Internet-Draft Ubiquity Software Corporation
Expires: December 28, 2006 J. Rosenberg Expires: September 3, 2007 J. Rosenberg
Cisco Systems Cisco Systems
G. Camarillo G. Camarillo
Ericsson Ericsson
June 26, 2006 March 2, 2007
Best Current Practices for NAT Traversal for SIP Best Current Practices for NAT Traversal for SIP
draft-ietf-sipping-nat-scenarios-05 draft-ietf-sipping-nat-scenarios-06
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 28, 2006. This Internet-Draft will expire on September 3, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Traversal of the Session Initiation Protocol (SIP) and the sessions Traversal of the Session Initiation Protocol (SIP) and the sessions
it establishes through Network Address Translators (NAT) is a complex it establishes through Network Address Translators (NAT) is a complex
problem. Currently there are many deployment scenarios and traversal problem. Currently there are many deployment scenarios and traversal
mechanisms for media traffic. This document aims to provide concrete mechanisms for media traffic. This document aims to provide concrete
recommendations and a unified method for NAT traversal as well as recommendations and a unified method for NAT traversal as well as
documenting corresponding call flows. documenting corresponding call flows.
skipping to change at page 2, line 27 skipping to change at page 2, line 27
3.2.3. TURN . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.3. TURN . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.4. ICE . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.4. ICE . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.5. Solution Profiles . . . . . . . . . . . . . . . . . . 10 3.2.5. Solution Profiles . . . . . . . . . . . . . . . . . . 10
4. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . . . 11 4. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . . . 11
4.1. Basic NAT SIP Signaling Traversal . . . . . . . . . . . . 11 4.1. Basic NAT SIP Signaling Traversal . . . . . . . . . . . . 11
4.1.1. Registration (Registrar/Proxy Co-Located) . . . . . . 11 4.1.1. Registration (Registrar/Proxy Co-Located) . . . . . . 11
4.1.2. Registration(Registrar/Proxy not Co-Located) . . . . . 15 4.1.2. Registration(Registrar/Proxy not Co-Located) . . . . . 15
4.1.3. Initiating a Session . . . . . . . . . . . . . . . . . 18 4.1.3. Initiating a Session . . . . . . . . . . . . . . . . . 18
4.1.4. Receiving an Invitation to a Session . . . . . . . . . 20 4.1.4. Receiving an Invitation to a Session . . . . . . . . . 20
4.2. Basic NAT Media Traversal . . . . . . . . . . . . . . . . 23 4.2. Basic NAT Media Traversal . . . . . . . . . . . . . . . . 23
4.2.1. Endpoint independent NAT . . . . . . . . . . . . . . . 24 4.2.1. Endpoint Independent NAT . . . . . . . . . . . . . . . 24
4.2.2. Port and Address Dependant NAT . . . . . . . . . . . . 40 4.2.2. Address and Port Dependant NAT . . . . . . . . . . . . 43
4.3. Address independent Port Restricted NAT --> Address 4.3. Address independent Port Restricted NAT --> Address
independent Port Restricted NAT traversal . . . . . . . . 46 independent Port Restricted NAT traversal . . . . . . . . 49
4.4. Internal TURN Usage (Enterprise Deployment) . . . . . . . 46 4.4. Internal TURN Usage (Enterprise Deployment) . . . . . . . 49
5. Intercepting Intermediary (B2BUA) . . . . . . . . . . . . . . 46 5. Intercepting Intermediary (B2BUA) . . . . . . . . . . . . . . 50
6. IPv4-IPv6 Transition . . . . . . . . . . . . . . . . . . . . . 47 6. IPv4-IPv6 Transition . . . . . . . . . . . . . . . . . . . . . 50
6.1. IPv4-IPv6 Transition for SIP Signalling . . . . . . . . . 47 6.1. IPv4-IPv6 Transition for SIP Signaling . . . . . . . . . . 50
6.2. IPv4-IPv6 Transition for Media . . . . . . . . . . . . . . 47 6.2. IPv4-IPv6 Transition for Media . . . . . . . . . . . . . . 50
7. ICE with RTP/TCP . . . . . . . . . . . . . . . . . . . . . . . 50 7. ICE with RTP/TCP . . . . . . . . . . . . . . . . . . . . . . . 53
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 8. ICE Lite . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53
9.1. Normative References . . . . . . . . . . . . . . . . . . . 50 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
9.2. Informative References . . . . . . . . . . . . . . . . . . 52 10.1. Normative References . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53 10.2. Informative References . . . . . . . . . . . . . . . . . . 55
Intellectual Property and Copyright Statements . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
Intellectual Property and Copyright Statements . . . . . . . . . . 57
1. Introduction 1. Introduction
NAT (Network Address Translators) traversal has long been identified NAT (Network Address Translators) traversal has long been identified
as a large problem when considered in the context of the Session as a large problem when considered in the context of the Session
Initiation Protocol (SIP)[1] and it's associated media such as Real Initiation Protocol (SIP)[1] and it's associated media such as Real
Time Protocol (RTP)[2]. The problem is further confused by the Time Protocol (RTP)[2]. The problem is further confused by the
variety of NATs that are available in the market place today and the variety of NATs that are available in the market place today and the
large number of potential deployment scenarios. Detail of different large number of potential deployment scenarios. Detail of different
NAT behaviors can be found in 'NAT Behavioral Requirements for NAT behaviors can be found in 'NAT Behavioral Requirements for
skipping to change at page 7, line 10 skipping to change at page 7, line 10
traversal of the associated media as specified in the Session traversal of the associated media as specified in the Session
Description Payload (SDP) of a SIP offer/answer exchange[5]. The Description Payload (SDP) of a SIP offer/answer exchange[5]. The
following sub-sections outline solutions that enable core SIP following sub-sections outline solutions that enable core SIP
signaling and its associated media to traverse NATs. signaling and its associated media to traverse NATs.
3.1. SIP Signaling 3.1. SIP Signaling
SIP signaling has two areas that result in transactional failure when SIP signaling has two areas that result in transactional failure when
traversing through NAT, as described in section 2 of this document. traversing through NAT, as described in section 2 of this document.
The remaining sub-sections describe appropriate solutions that result The remaining sub-sections describe appropriate solutions that result
in SIP signalling traversal through NAT, regardless of transport in SIP signaling traversal through NAT, regardless of transport
protocol. IT is RECOMMEDED that SIP compliant entities follow the protocol. IT is RECOMMEDED that SIP compliant entities follow the
guidelines presented in this section to enable traversal of SIP guidelines presented in this section to enable traversal of SIP
signaling through NATs. signaling through NATs.
3.1.1. Symmetric Response 3.1.1. Symmetric Response
As described in section 2 of this document, when using an unreliable As described in section 2 of this document, when using an unreliable
transport protocol such as UDP, SIP responses are sent to the IP transport protocol such as UDP, SIP responses are sent to the IP
address and port combination contained in the SIP 'Via' header field address and port combination contained in the SIP 'Via' header field
(or default port for the appropriate transport protocol if not (or default port for the appropriate transport protocol if not
skipping to change at page 9, line 34 skipping to change at page 9, line 34
causes RTCP traffic to break when traversing many NATs due to blocked causes RTCP traffic to break when traversing many NATs due to blocked
ports. To combat this problem a specific address and port need to be ports. To combat this problem a specific address and port need to be
specified in the SDP rather than relying on such assumptions. RFC specified in the SDP rather than relying on such assumptions. RFC
3605 [6] defines an SDP attribute that is included to explicitly 3605 [6] defines an SDP attribute that is included to explicitly
specify transport connection information for RTCP. The address specify transport connection information for RTCP. The address
details can be obtained using any appropriate method including those details can be obtained using any appropriate method including those
detailed previously in this section (e.g. STUN, TURN). detailed previously in this section (e.g. STUN, TURN).
3.2.2. STUN 3.2.2. STUN
Simple Traversal of User Datagram Protocol (UDP) through Network Simple Traversal of Underneath Network Address Translators(NAT) or
Address Translators(NAT) or STUN is defined in RFC 3489bis [10]. STUN is defined in RFC 3489bis [10]. STUN is a lightweight tool kit
STUN is a lightweight tool kit and protocol that provides details of and protocol that provides details of the external IP address/port
the external IP address/port combination used by the NAT device to combination used by the NAT device to represent the internal entity
represent the internal entity on the public facing side of a NAT. On on the public facing side of a NAT. On learning of such an external
learning of such an external representation, a client can use it representation, a client can use it accordingly as the connection
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' [11], STUN
Requirements for Unicast UDP' [11], STUN does work with 'Endpoint does work with 'Endpoint Independent Mapping' but does not work with
Independent Mapping' but does not work with either 'Address Dependent either 'Address Dependent Mapping' or 'Address and Port Dependent
Mapping' or 'Address Dependent and Port Mapping' type NATs. Using Mapping' type NATs. Using STUN with either of the previous two NAT
STUN with either of the previous two NAT mappings to probe for the mappings to probe for the external IP address/port representation
external IP address/port representation will provide a different will provide a different result to that required for traversal by an
result to that required for traversal by an alternative SIP entity. alternative SIP entity. The IP address/port combination deduced for
The IP address/port combination deduced for the STUN server would be the STUN server would be blocked for incoming packets from an
blocked for incoming packets from an alterative SIP entity. alterative SIP entity.
As mentioned in Section 3.1.2, STUN is also used as a peer-to-peer As mentioned in Section 3.1.2, STUN is also used as a peer-to-peer
keep-alive mechanism. keep-alive mechanism.
3.2.3. TURN 3.2.3. TURN
As described in the previous section, the STUN protocol does not work As described in the previous section, the STUN protocol does not work
for UDP traversal through certain identified NAT mappings. for UDP traversal through certain identified NAT mappings.
'Obtaining Relay Addresses from Simple Traversal of UDP Through NAT 'Obtaining Relay Addresses from Simple Traversal of UDP Through NAT
(known as TURN)' is a usage of the STUN protocol for deriving (from a (known as TURN)' is a usage of the STUN protocol for deriving (from a
skipping to change at page 11, line 8 skipping to change at page 11, line 8
3.2.5. Solution Profiles 3.2.5. Solution Profiles
This draft has documented a number of technology solutions for the This draft has documented a number of technology solutions for the
traversal of media through differing NAT deployments. A number of traversal of media through differing NAT deployments. A number of
'profiles' will now be defined that categorize varying levels of 'profiles' will now be defined that categorize varying levels of
support for the technologies described. support for the technologies described.
3.2.5.1. Primary Profile 3.2.5.1. Primary Profile
A client falling into the 'Primary' profile supports ICE in A client falling into the 'Primary' profile supports ICE in
conjunction with STUN, TURN and RFC 3605 [6] for RTCP. ICE is used conjunction with STUN, TURN usage and RFC 3605 [6] for RTCP. ICE is
in all cases and falls back to standard operation when dealing with used in all cases and falls back to standard operation when dealing
non-ICE clients. A client which falls into the 'Primary' profile with non-ICE clients. A client which falls into the 'Primary'
will be maximally interoperable and function in a rich variety of profile will be maximally interoperable and function in a rich
environments including enterprise, consumer and behind all varieties variety of environments including enterprise, consumer and behind all
of NAT. varieties of NAT.
3.2.5.2. Consumer Profile 3.2.5.2. Consumer Profile
A client falling into the 'Consumer' profile supports STUN and RFC A client falling into the 'Consumer' profile supports STUN and RFC
3605 [6] for RTCP. It uses STUN to allocate bindings, and can also 3605 [6] for RTCP. It uses STUN to allocate bindings, and can also
detect when it is in the unfortunate situation of being behind a detect when it is in the unfortunate situation of being behind a
'Symmetric' NAT, although it simply cannot function in this case. 'Symmetric' NAT, although it simply cannot function in this case.
These clients will only work in deployment situations where the These clients will only work in deployment situations where the
access is sufficiently controlled to know definitively that there access is sufficiently controlled to know definitively that there
won't be Symmetric NAT. This is hard to guarantee as users can won't be Symmetric NAT. This is hard to guarantee as users can
always pick up their client and connect via a different access always pick up their client and connect via a different access
network. network.
3.2.5.3. Minimal Profile 3.2.5.3. Minimal Profile
A client falling into the 'Minimal' profile will send/receive RTP A client falling into the 'Minimal' profile will send/receive RTP
form the same IP/port combination. This client requires proprietary from the same IP/port combination. This client requires proprietary
network based solutions to function in any NAT traversal scenario. network based solutions to function in any NAT traversal scenario.
All clients SHOULD support the 'Primary Profile', MUST support the All clients SHOULD support the 'Primary Profile', MUST support the
'Minimal Profile' and MAY support the 'Consumer Profile'. 'Minimal Profile' and MAY support the 'Consumer Profile'.
4. NAT Traversal Scenarios 4. NAT Traversal Scenarios
This section of the document includes detailed NAT traversal This section of the document includes detailed NAT traversal
scenarios for both SIP signaling and the associated media. scenarios for both SIP signaling and the associated media.
skipping to change at page 23, line 38 skipping to change at page 23, line 38
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 reflexive transport address. o The "Map" attribute represents the server reflexive (XOR-MAPPED-
o The "Rel" attribute represents the relayed transport address. ADDRESS STUN attribute) transport address.
o The "Rel" attribute represents the relayed (RELAY-ADDRESS STUN
attribute) transport address.
The meaning of each STUN attribute is extensively explained in the The meaning of each STUN attribute is extensively explained in the
core STUN[10] and TURN usage[12] drafts. core STUN[10] and TURN usage[12] drafts.
A number of ICE SDP attributes have also been included in some of the
examples. Detailed information on individual attributes can be
obtained from the core ICE specification.
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 a following annotation. The first component will contain the
representation of the client responsible for the address. For representation of the client responsible for the address. For
example in the majority of the examples "L" (left client), "R" (right example in the majority of the examples "L" (left client), "R" (right
client), NAT-PUB" (NAT public), PRIV (Private), and "STUN-PUB" (STUN client), NAT-PUB" (NAT public), PRIV (Private), and "STUN-PUB" (STUN
Public) are used. To allow for multiple addresses from the same Public) are used. To allow for multiple addresses from the same
network element, each representation can also be followed by a network element, each representation can also be followed by a
number. These can also be used in combination. For example "L-NAT- number. These can also be used in combination. For example "L-NAT-
PUB-1" would represent a public network address on the left hand side PUB-1" would represent a public network address on the left hand side
NAT while "R-NAT-PUB-1" would represent a public network address in NAT while "R-NAT-PUB-1" would represent a public network address in
the right hand side of the NAT. "L-PRIV-1" would represent a private the right hand side of the NAT. "L-PRIV-1" would represent a private
network address on the left hand side of the NAT while "R-PRIV-1" network address on the left hand side of the NAT while "R-PRIV-1"
represents a private address on the right hand side of the NAT. represents a private address on the right hand side of the NAT.
It should also be noted that during the examples it might be It should also be noted that during the examples it might be
appropriate to signify an explicit part of a transport address. This appropriate to signify an explicit part of a transport address. This
is achieved by adding either the '.address' or '.port' tag on the end is achieved by adding either the '.address' or '.port' tag on the end
of the representation. For example, 'L-PRIV-1.address' and 'L-PRIV- of the representation. For example, 'L-PRIV-1.address' and 'L-PRIV-
1.port'. 1.port'.
4.2.1. Endpoint independent NAT 4.2.1. Endpoint Independent NAT
This section demonstrates an example of a client both initiating and This section demonstrates an example of a client both initiating and
receiving calls behind an 'Endpoint independent' NAT. An example is receiving calls behind an 'Endpoint independent' NAT. An example is
included for both STUN and ICE with ICE being the RECOMMENDED included for both STUN and ICE with ICE being the RECOMMENDED
mechanism for media traversal. mechanism for media traversal.
4.2.1.1. STUN Solution 4.2.1.1. STUN Solution
It is possible to traverse media through an 'Endpoint Independent NAT It is possible to traverse media through an 'Endpoint Independent NAT
using STUN. The remainder of this section provides a simplified using STUN. The remainder of this section provides a simplified
examples of the 'Binding Discovery' STUN usage as defined in [10]. examples of the 'Binding Discovery' STUN usage as defined in [10].
The STUN messages have been simplified and do not include 'Shared The STUN messages have been simplified and do not include 'Shared
Secret' requests used to obtain the temporary username and password. Secret' requests used to obtain the temporary username and password.
[Editors Note: Expand to show full flow in including Auth?.] [Editors Note: Expand to show full flow including Auth?.]
4.2.1.1.1. Initiating Session 4.2.1.1.1. Initiating Session
The following example demonstrates media traversal through a NAT The following example demonstrates media traversal through a NAT with
demonstrating 'Address Independent' NAT behavior using STUN. It is 'Address Independent' properties using the STUN 'Binding Discovery'
assumed in this example that the STUN client and SIP Client are co- usage. It is assumed in this example that the STUN client and SIP
located on the same machine. Note that some SIP signalling messages Client are co-located on the same physical machine. Note that some
have been left out for simplicity. SIP signaling messages have been left out for simplicity.
Client NAT STUN [..] Client NAT STUN [..]
Server Server
| | | | | | | |
|(1) STUN Req | | | |(1) BIND Req | | |
|Src=L-PRIV-1 | | | |Src=L-PRIV-1 | | |
|Dest=STUN-PUB | | | |Dest=STUN-PUB | | |
|----------------->| | | |----------------->| | |
| | | | | | | |
| |(2) STUN Req | | | |(2) BIND Req | |
| |Src=NAT-PUB-1 | | | |Src=NAT-PUB-1 | |
| |Dest=STUN-PUB | | | |Dest=STUN-PUB | |
| |----------------->| | | |----------------->| |
| | | | | | | |
| |(3) STUN Resp | | | |(3) BIND Resp | |
| |<-----------------| | | |<-----------------| |
| |Src=STUN-PUB | | | |Src=STUN-PUB | |
| |Dest=NAT-PUB-1 | | | |Dest=NAT-PUB-1 | |
| |Map=NAT-PUB-1 | | | |Map=NAT-PUB-1 | |
| | | | | | | |
|(4) STUN Resp | | | |(4) BIND Resp | | |
|<-----------------| | | |<-----------------| | |
|Src=STUN-PUB | | | |Src=STUN-PUB | | |
|Dest=L-PRIV-1 | | | |Dest=L-PRIV-1 | | |
|Map=NAT-PUB-1 | | | |XOR=NAT-PUB-1 | | |
| | | | | | | |
|(5) STUN Req | | | |(5) BIND Req | | |
|Src=L-PRIV-2 | | | |Src=L-PRIV-2 | | |
|Dest=STUN-PUB | | | |Dest=STUN-PUB | | |
|----------------->| | | |----------------->| | |
| | | | | | | |
| |(6) STUN Req | | | |(6) BIND Req | |
| |Src=NAT-PUB-2 | | | |Src=NAT-PUB-2 | |
| |Dest=STUN-PUB | | | |Dest=STUN-PUB | |
| |----------------->| | | |----------------->| |
| | | | | | | |
| |(7) STUN Resp | | | |(7) BIND Resp | |
| |<-----------------| | | |<-----------------| |
| |Src=STUN-PUB | | | |Src=STUN-PUB | |
| |Dest=NAT-PUB-2 | | | |Dest=NAT-PUB-2 | |
| |Map=NAT-PUB-2 | | | |Map=NAT-PUB-2 | |
| | | | | | | |
|(8) STUN Resp | | | |(8) BIND Resp | | |
|<-----------------| | | |<-----------------| | |
|Src=STUN-PUB | | | |Src=STUN-PUB | | |
|Dest=L-PRIV-2 | | | |Dest=L-PRIV-2 | | |
|Map=NAT-PUB-2 | | | |Map=NAT-PUB-2 | | |
| | | | | | | |
|(9)SIP INVITE | | | |(9)SIP INVITE | | |
|----------------->| | | |----------------->| | |
| | | | | | | |
| |(10)SIP INVITE | | | |(10)SIP INVITE | |
| |------------------------------------>| | |------------------------------------>|
skipping to change at page 26, line 33 skipping to change at page 26, line 38
|<<<<<<<<<<<<Incoming RTCP sent to NAT-PUB-2<<<<<<<<<<<<<| |<<<<<<<<<<<<Incoming RTCP sent to NAT-PUB-2<<<<<<<<<<<<<|
|========================================================| |========================================================|
| | | | | | | |
|(13)SIP ACK | | | |(13)SIP ACK | | |
|----------------->| | | |----------------->| | |
| | | | | | | |
| |(14) SIP ACK | | | |(14) SIP ACK | |
| |------------------------------------>| | |------------------------------------>|
| | | | | | | |
Figure 18: Address and Port Dependant NAT with STUN - Initiating Figure 18: Endpoint Independent NAT - Initiating
o On deciding to initiate a SIP voice session the client starts a o On deciding to initiate a SIP voice session the client starts a
local STUN client on the interface and port that is to be used for local STUN client on the interface and port that is to be used for
media (send/receive). The STUN client generates a standard STUN media (send/receive). The STUN client generates a standard
request as indicated in (1) from Figure 18 which also highlights 'Binding Discovery' request as indicated in (1) from Figure 18
the source address and port for which the client device wishes to which also highlights the source address and port for which the
obtain a mapping. The STUN request is sent through the NAT client device wishes to obtain a mapping. The 'Binding Discovery'
towards the public internet and STUN server. request is sent through the NAT towards the public internet and
o STUN message (2) traverses the NAT and breaks out onto the public STUN server.
o Message (2) traverses the NAT and breaks out onto the public
internet towards the public STUN server. Note that the source internet towards the public STUN server. Note that the source
address of the STUN requests now represents the public address and address of the 'Binding Discovery' request now represents the
port from the public side of the NAT. public address and port from the public side of the NAT.
o The STUN server receives the request and processes it o The STUN server receives the request and processes it
appropriately. This results in a successful STUN response being appropriately. This results in a successful 'Binding Discovery'
generated and returned (3). The message contains details of the response being generated and returned (3). The message contains
mapped public address (contained in the STUN MAPPED-ADDRESS details of the XOR mapped public address (contained in the STUN
attribute) which is to be used by the originating client to XOR-MAPPED-ADDRESS attribute) which is to be used by the
receive media (see 'Map=NAT-PUB-1' from (3)). originating client to receive media (see 'Map=NAT-PUB-1' from
o The STUN response traverses back through the NAT using the binding (3)).
created by the STUN request and presents the new mapped address to o The 'Binding Discovery' response traverses back through the NAT
the client (4). At this point the process is repeated to obtain a using the path created by the 'Binding Discovery' request and
second mapped address (as shown in (5)-(8)) for an alternative presents the new XOR mapped address to the client (4). At this
local address (Address has changed from "L-PRIV-1" to "L-PRIV-2"). point the process is repeated to obtain a second XOR-mapped
address (as shown in (5)-(8)) for an alternative local address
(Address has changed from "L-PRIV-1" to "L-PRIV-2").
o The client now constructs a SIP INVITE message(9). Note that o The client now constructs a SIP INVITE message(9). Note that
traversal of SIP is not covered in this example and is discussed traversal of SIP is not covered in this example and is discussed
in earlier sections of the document. The INVITE request will use in earlier sections of the document. The INVITE request will use
the addresses it has obtained in the previous STUN transactions to the addresses it has obtained in the previous STUN transactions to
populate the SDP of the SIP INVITE as shown below: populate the SDP of the SIP INVITE as shown below:
v=0 v=0
o=test 2890844526 2890842807 IN IP4 $L-PRIV-1.address o=test 2890844526 2890842807 IN IP4 $L-PRIV-1.address
c=IN IP4 $NAT-PUB-1.address c=IN IP4 $NAT-PUB-1.address
t=0 0 t=0 0
m=audio $NAT-PUB-1.port RTP/AVP 0 m=audio $NAT-PUB-1.port RTP/AVP 0
a=rtcp:$NAT-PUB-2.port a=rtcp:$NAT-PUB-2.port
o Note that the mapped address obtained from the STUN transactions o Note that the XOR-mapped address obtained from the 'Binding
are inserted as the connection address for the SDP (c=NAT-PUB- Discovery' transactions are inserted as the connection address for
1.address). The Primary port for RTP is also inserted in the SDP the SDP (c=NAT-PUB-1.address). The Primary port for RTP is also
(m=audio NAT-PUB-1.port RTP/AVP 0). Finally, the port gained from inserted in the SDP (m=audio NAT-PUB-1.port RTP/AVP 0). Finally,
the additional STUN binding is placed in the RTCP attribute (as the port gained from the additional 'Binding Discovery' is placed
discussed in Section 3.2.1.1) for traversal of RTCP (a=rtcp:NAT- in the RTCP attribute (as discussed in Section 3.2.1.1) for
PUB-2.port). traversal of RTCP (a=rtcp:NAT-PUB-2.port).
o The SIP signalling then traverses the NAT and sets up the SIP o The SIP signaling then traverses the NAT and sets up the SIP
session (10-12). Note that the client transmits media as soon as session (10-12). Note that the client transmits media as soon as
the 200 OK to the INVITE arrives at the client (12). Up until the 200 OK to the INVITE arrives at the client (12). Up until
this point the incoming media and RTCP will not pass through the this point the incoming media and RTCP will not pass through the
NAT as no outbound association has been created with the far end NAT as no outbound association has been created with the far end
client. Two way media communication has now been established. client. Two way media communication has now been established.
4.2.1.1.2. Receiving Session Invitation 4.2.1.1.2. Receiving Session Invitation
Receiving a session for an 'Address and Port dependant' NAT using Receiving a session for an 'Endpoint Independent' NAT using the STUN
STUN is very similar to the example outlined in Section 4.2.1.1.1. 'Binding Discovery' usage is very similar to the example outlined in
Figure 20 illustrates the associated flow of messages. Section 4.2.1.1.1. Figure 20 illustrates the associated flow of
messages.
Client NAT STUN [..] Client NAT STUN [..]
Server Server
| | | (1)SIP INVITE | | | | (1)SIP INVITE |
| |<-----------------|------------------| | |<-----------------|------------------|
| | | | | | | |
|(2) SIP INVITE | | | |(2) SIP INVITE | | |
|<-----------------| | | |<-----------------| | |
| | | | | | | |
|(3) STUN Req | | | |(3) BIND Req | | |
|Src=L-PRIV-1 | | | |Src=L-PRIV-1 | | |
|Dest=STUN-PUB | | | |Dest=STUN-PUB | | |
|----------------->| | | |----------------->| | |
| | | | | | | |
| |(4) STUN Req | | | |(4) BIND Req | |
| |Src=NAT-PUB-1 | | | |Src=NAT-PUB-1 | |
| |Dest=STUN-PUB | | | |Dest=STUN-PUB | |
| |----------------->| | | |----------------->| |
| | | | | | | |
| |(5) STUN Resp | | | |(5) BIND Resp | |
| |<-----------------| | | |<-----------------| |
| |Src=STUN-PUB | | | |Src=STUN-PUB | |
| |Dest=NAT-PUB-1 | | | |Dest=NAT-PUB-1 | |
| |Map=NAT-PUB-1 | | | |Map=NAT-PUB-1 | |
| | | | | | | |
|(6) STUN Resp | | | |(6) BIND Resp | | |
|<-----------------| | | |<-----------------| | |
|Src=STUN-PUB | | | |Src=STUN-PUB | | |
|Dest=L-PRIV-1 | | | |Dest=L-PRIV-1 | | |
|Map=NAT-PUB-1 | | | |Map=NAT-PUB-1 | | |
| | | | | | | |
|(7) STUN Req | | | |(7) BIND Req | | |
|Src=L-PRIV-2 | | | |Src=L-PRIV-2 | | |
|Dest=STUN-PUB | | | |Dest=STUN-PUB | | |
|----------------->| | | |----------------->| | |
| | | | | | | |
| |(8) STUN Req | | | |(8) BIND Req | |
| |Src=NAT-PUB-2 | | | |Src=NAT-PUB-2 | |
| |Dest=STUN-PUB | | | |Dest=STUN-PUB | |
| |----------------->| | | |----------------->| |
| | | | | | | |
| |(9) STUN Resp | | | |(9) BIND Resp | |
| |<-----------------| | | |<-----------------| |
| |Src=STUN-PUB | | | |Src=STUN-PUB | |
| |Dest=NAT-PUB-2 | | | |Dest=NAT-PUB-2 | |
| |Map=NAT-PUB-2 | | | |Map=NAT-PUB-2 | |
| | | | | | | |
|(10) STUN Resp | | | |(10) BIND Resp | | |
|<-----------------| | | |<-----------------| | |
|Src=STUN-PUB | | | |Src=STUN-PUB | | |
|Dest=L-PRIV-2 | | | |Dest=L-PRIV-2 | | |
|Map=NAT-PUB-2 | | | |Map=NAT-PUB-2 | | |
| | | | | | | |
|(11)SIP 200 OK | | | |(11)SIP 200 OK | | |
|----------------->| | | |----------------->| | |
| |(12)SIP 200 OK | | | |(12)SIP 200 OK | |
| |------------------------------------>| | |------------------------------------>|
| | | | | | | |
|========================================================| |========================================================|
|>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>>>| |>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>>>|
|========================================================| |========================================================|
| | | | | | | |
|========================================================| |========================================================|
|<<<<<<<<&gt;><<<Incoming Media sent to L-PRIV-1<<<<<<<<<<<<| |<<<<<<<<&lt;<<<<Incoming Media sent to L-PRIV-1<<<<<<<<<<<<|
|========================================================| |========================================================|
| | | | | | | |
|========================================================| |========================================================|
|>>>>>>>>>>>>Outgoing RTCP sent from L-PRIV-2>>>>>>>>>>>>| |>>>>>>>>>>>>Outgoing RTCP sent from L-PRIV-2>>>>>>>>>>>>|
|========================================================| |========================================================|
| | | | | | | |
|========================================================| |========================================================|
|<<<<<<<<<<<<<Incoming RTCP sent to L-PRIV-2<<<<<<<<<<<<<| |<<<<<<<<<<<<<Incoming RTCP sent to L-PRIV-2<<<<<<<<<<<<<|
|========================================================| |========================================================|
| | | | | | | |
| | |(13)SIP ACK | | | |(13)SIP ACK |
| |<------------------------------------| | |<------------------------------------|
| | | | | | | |
|(14)SIP ACK | | | |(14)SIP ACK | | |
|<-----------------| | | |<-----------------| | |
| | | | | | | |
Figure 20: Restricted NAT with STUN - Receiving Figure 20: Endpoint Independent NAT - Receiving
o On receiving an invitation to a SIP voice session (SIP INVITE o On receiving an invitation to a SIP voice session (SIP INVITE
request) the User Agent starts a local STUN client on the request) the User Agent starts a local STUN client on the
appropriate port on which it is to receive media. The STUN client appropriate port on which it is to receive media. The STUN client
generates a standard STUN request as indicated in (3) from generates a standard 'Binding Discovery' request as indicated in
Figure 20 which also highlights the source address and port for (3) from Figure 20 which also highlights the source address and
which the client device wishes to obtain a mapping. The STUN port for which the client device wishes to obtain a mapping. The
request is sent through the NAT towards the public internet and 'Binding Discovery' request is sent through the NAT towards the
STUN Server. public internet and STUN Server.
o STUN message (4) traverses the NAT and breaks out onto the public o 'Binding Discovery' message (4) traverses the NAT and breaks out
internet towards the public STUN server. Note that the source onto the public internet towards the public STUN server. Note
address of the STUN requests now represents the public address and that the source address of the STUN requests now represents the
port from the public side of the NAT. public address and port from the public side of the NAT.
o The STUN server receives the request and processes it
appropriately. This results in a successful STUN response being
generated and returned (5). The message contains details of the
mapped public address (contained in the STUN MAPPED-ADDRESS
attribute) which is to be used by the originating client to
receive media (see 'Map=NAT-PUB-1' from (5)).
o The STUN response traverses back through the NAT using the binding o The STUN server receives the request and processes it
created by the outgoing STUN request and presents the new mapped appropriately. This results in a successful 'Binding Discovery'
address to the client (6). At this point the process is repeated response being generated and returned (5). The message contains
to obtain a second mapped address (as shown in (7)-(10)) for an details of the mapped public address (contained in the STUN XOR-
alternative local address (local port has now changed and is MAPPED-ADDRESS attribute) which is to be used by the originating
represented by L-PRIV-2 in (7)). client to receive media (see 'Map=NAT-PUB-1' from (5)).
o The 'Binding Discovery' response traverses back through the NAT
using the path created by the outgoing 'Binding Discovery' request
and presents the new XOR-mapped address to the client (6). At
this point the process is repeated to obtain a second XOR-mapped
address (as shown in (7)-(10)) for an alternative local address
(local port has now changed and is represented by L-PRIV-2 in
(7)).
o The client now constructs a SIP 200 OK message (11) in response to o The client now constructs a SIP 200 OK message (11) in response to
the original SIP INVITE requests. Note that traversal of SIP is the original SIP INVITE requests. Note that traversal of SIP is
not covered in this example and is discussed in earlier sections not covered in this example and is discussed in earlier sections
of the document. SIP Provisional responses are also left out for of the document. SIP Provisional responses are also left out for
simplicity. The 200 OK response will use the addresses it has simplicity. The 200 OK response will use the addresses it has
obtained in the previous STUN transactions to populate the SDP of obtained in the previous STUN transactions to populate the SDP of
the SIP 200 OK as shown below: the SIP 200 OK as shown below:
v=0 v=0
o=test 2890844526 2890842807 IN IP4 $L-PRIV-1.address o=test 2890844526 2890842807 IN IP4 $L-PRIV-1.address
c=IN IP4 $NAT-PUB-1.address c=IN IP4 $NAT-PUB-1.address
t=0 0 t=0 0
m=audio $NAT-PUB-1.port RTP/AVP 0 m=audio $NAT-PUB-1.port RTP/AVP 0
a=rtcp:$NAT-PUB-2.port a=rtcp:$NAT-PUB-2.port
o Note that the mapped address obtained from the initial STUN o Note that the XOR-mapped address obtained from the initial
transaction is inserted as the connection address for the SDP 'Binding Discovery' transaction is inserted as the connection
(c=NAT-PUB-1.address). The Primary port for RTP is also inserted address for the SDP (c=NAT-PUB-1.address). The Primary port for
in the SDP (m=audio NAT-PUB-1.port RTP/AVP 0). Finally, the port RTP is also inserted in the SDP (m=audio NAT-PUB-1.port RTP/AVP
gained from the additional binding is placed in the RTCP attribute 0). Finally, the port gained from the additional 'Binding
(as discussed in Section 3.2.1.1) for traversal of RTCP (a=rtcp: Discovery' is placed in the RTCP attribute (as discussed in
NAT-PUB-2.port). Section 3.2.1.1) for traversal of RTCP (a=rtcp:NAT-PUB-2.port).
o The SIP signalling then traverses the NAT and sets up the SIP o The SIP signaling then traverses the NAT and sets up the SIP
session (11-14). Note that the client transmits media as soon as session (11-14). Note that the client transmits media as soon as
the 200 OK to the INVITE is sent to the UAC(11). Up until this the 200 OK to the INVITE is sent to the UAC(11). Up until this
point the incoming media will not pass through the NAT as no point the incoming media will not pass through the NAT as no
outbound association has been created with the far end client. outbound association has been created with the far end client.
Two way media communication has now been established. Two way media communication has now been established.
4.2.1.2. ICE Solution 4.2.1.2. ICE Solution
The preferred solution for media traversal of NAT is using ICE, as The preferred solution for media traversal of NAT is using ICE, as
described in Section 3.2.4, regardless of the NAT type. The described in Section 3.2.4, regardless of the NAT type. The
following examples illustrate the traversal of an 'Endpoint following examples illustrate the traversal of an 'Endpoint
independent' NAT for both an initiating. The example only covers ICE Independent' NAT when initiating. The example only covers ICE in
in association with STUN and TURN usage. association with the 'Binding Discovery' and TURN usage.
4.2.1.2.1. Initiating Session 4.2.1.2.1. Initiating Session
The following example demonstrates an initiating traversal through an The following example demonstrates an initiating traversal through an
'Endpoint independent' NAT using ICE. 'Endpoint independent' NAT using ICE.
[Editors Note: Example needs to be expanded to include more ICE
detail e.g. timers etc.]
L NAT STUN NAT R L NAT STUN NAT R
Server 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=L-NAT-PUB-1 | | | | |Src=L-NAT-PUB-1 | | |
skipping to change at page 35, line 17 skipping to change at page 35, line 22
| | | | | | | | | |
| | | |(36) Bind Res | | | | |(36) Bind Res |
| | | |--------------->| | | | |--------------->|
| | | |Src=L-NAT-PUB-1 | | | | |Src=L-NAT-PUB-1 |
| | | |Dest=R-PRIV-1 | | | | |Dest=R-PRIV-1 |
| | | |Map=R-NAT-PUB-1 | | | | |Map=R-NAT-PUB-1 |
| | | | | | | | | |
|===================================================================| |===================================================================|
|<<<<<<<<<<<<<<<<<<<<<Outgoing RTP sent from <<<<<<<<<<<<<<<<<<<<<<<| |<<<<<<<<<<<<<<<<<<<<<Outgoing RTP sent from <<<<<<<<<<<<<<<<<<<<<<<|
|===================================================================| |===================================================================|
| | | | |
|(37) Bind Req | | | | |(37) Bind Req | | | |
|--------------->| | | | |--------------->| | | |
|Src=L-PRIV-1 | | | |
|Dest=R-NAT-PUB-1| | | |
|USE-CANDIDATE | | | |
| | | | |
| |(38) Bind Req | | |
| |-------------------------------->| |
| |Src=L-NAT-PUB-1 | | |
| |Dest=R-NAT-PUB-1| | |
| |USE-CANDIDATE | | |
| | | | |
| | | |(39) Bind Req |
| | | |--------------->|
| | | |Src=L-NAT-PUB-1 |
| | | |Dest=R-PRIV-1 |
| | | |USE-CANDIDATE |
| | | | |
| | | |(40) Bind Res |
| | | |<---------------|
| | | |Src=R-PRIV-1 |
| | | |Dest=L-NAT-PUB-1|
| | | |Map=L-NAT-PUB-1 |
| | | | |
| | |(41) Bind Res | |
| |<--------------------------------| |
| | |Src=R-NAT-PUB-1 | |
| | |Dest=L-NAT-PUB-1| |
| | |Map=L-NAT-PUB-1 | |
| | | | |
|(42) Bind Res | | | |
|<---------------| | | |
|Src=R-NAT-PUB-1 | | | |
|Dest=L-PRIV-1 | | | |
|Map=L-NAT-PUB-1 | | | |
| | | | |
|(43) Bind Req | | | |
|--------------->| | | |
|Src=L-PRIV-2 | | | | |Src=L-PRIV-2 | | | |
|Dest=R-NAT-PUB-2| | | | |Dest=R-NAT-PUB-2| | | |
| | | | | | | | | |
| |(38) Bind Req | | | | |(44) Bind Req | | |
| |-------------------------------->| | | |-------------------------------->| |
| |Src=L-NAT-PUB-2 | | | | |Src=L-NAT-PUB-2 | | |
| |Dest=R-NAT-PUB-2| | | | |Dest=R-NAT-PUB-2| | |
| | | | | | | | | |
| | | |(39) Bind Req | | | | |(45) Bind Req |
| | | |--------------->| | | | |--------------->|
| | | |Src=L-NAT-PUB-2 | | | | |Src=L-NAT-PUB-2 |
| | | |Dest=R-PRIV-2 | | | | |Dest=R-PRIV-2 |
| | | | | | | | | |
| | | |(40) Bind Res | | | | |(46) Bind Res |
| | | |<---------------| | | | |<---------------|
| | | |Src=R-PRIV-2 | | | | |Src=R-PRIV-2 |
| | | |Dest=L-NAT-PUB-2| | | | |Dest=L-NAT-PUB-2|
| | | |Map=L-NAT-PUB-2 | | | | |Map=L-NAT-PUB-2 |
| | | | | | | | | |
| | |(41) Bind Res | | | | |(47) Bind Res | |
| |<--------------------------------| | | |<--------------------------------| |
| | |Src=R-NAT-PUB-2 | | | | |Src=R-NAT-PUB-2 | |
| | |Dest=L-NAT-PUB-2| | | | |Dest=L-NAT-PUB-2| |
| | |Map=L-NAT-PUB-2 | | | | |Map=L-NAT-PUB-2 | |
| | | | | | | | | |
|(42) Bind Res | | | | |(48) Bind Res | | | |
|<---------------| | | | |<---------------| | | |
|Src=R-NAT-PUB-2 | | | | |Src=R-NAT-PUB-2 | | | |
|Dest=L-PRIV-2 | | | | |Dest=L-PRIV-2 | | | |
|Map=L-NAT-PUB-2 | | | | |Map=L-NAT-PUB-2 | | | |
| | | | | | | | | |
|===================================================================| |===================================================================|
|>>>>>>>>>>>>>>>>>>>>>Outgoing RTCP sent from >>>>>>>>>>>>>>>>>>>>>>| |>>>>>>>>>>>>>>>>>>>>>Outgoing RTCP sent from >>>>>>>>>>>>>>>>>>>>>>|
|===================================================================| |===================================================================|
| | | | | | | | | |
| | | |(43) Bind Req | | | | |(49) Bind Req |
| | | |<---------------| | | | |<---------------|
| | | |Src=R-PRIV-2 | | | | |Src=R-PRIV-2 |
| | | |Dest=L-NAT-PUB-2| | | | |Dest=L-NAT-PUB-2|
| | | | | | | | | |
| | |(44) Bind Req | | | | |(50) Bind Req | |
| |<--------------------------------| | | |<--------------------------------| |
| | |Src=R-NAT-PUB-2 | | | | |Src=R-NAT-PUB-2 | |
| | |Dest=L-NAT-PUB-2| | | | |Dest=L-NAT-PUB-2| |
| | | | | | | | | |
|(45) Bind Req | | | | |(51) Bind Req | | | |
|<---------------| | | | |<---------------| | | |
|Src=R-NAT-PUB-2 | | | | |Src=R-NAT-PUB-2 | | | |
|Dest=L-PRIV-2 | | | | |Dest=L-PRIV-2 | | | |
| | | | | | | | | |
|(46) Bind Res | | | | |(52) Bind Res | | | |
|--------------->| | | | |--------------->| | | |
|Src=L-PRIV-2 | | | | |Src=L-PRIV-2 | | | |
|Dest=R-NAT-PUB-2| | | | |Dest=R-NAT-PUB-2| | | |
|Map=R-NAT-PUB-2 | | | | |Map=R-NAT-PUB-2 | | | |
| | | | | | | | | |
| |(47) Bind Res | | | | |(53) Bind Res | | |
| |-------------------------------->| | | |-------------------------------->| |
| |Src=L-NAT-PUB-2 | | | | |Src=L-NAT-PUB-2 | | |
| |Dest=R-NAT-PUB-2| | | | |Dest=R-NAT-PUB-2| | |
| |Map=R-NAT-PUB-2 | | | | |Map=R-NAT-PUB-2 | | |
| | | | | | | | | |
| | | |(48) Bind Res | | | | |(54) Bind Res |
| | | |--------------->| | | | |--------------->|
| | | |Src=L-NAT-PUB-2 | | | | |Src=L-NAT-PUB-2 |
| | | |Dest=R-PRIV-2 | | | | |Dest=R-PRIV-2 |
| | | |Map=R-NAT-PUB-2 | | | | |Map=R-NAT-PUB-2 |
| | | | | | | | | |
|===================================================================| |===================================================================|
|<<<<<<<<<<<<<<<<<<<<<Outgoing RTCP sent from <<<<<<<<<<<<<<<<<<<<<<| |<<<<<<<<<<<<<<<<<<<<<Outgoing RTCP sent from <<<<<<<<<<<<<<<<<<<<<<|
|===================================================================| |===================================================================|
|(55) Bind Req | | | |
|--------------->| | | |
|Src=L-PRIV-2 | | | |
|Dest=R-NAT-PUB-2| | | |
|USE-CANDIDATE | | | |
| | | | | | | | | |
|(49) SIP INVITE | | | | | |(56) Bind Req | | |
| |-------------------------------->| |
| |Src=L-NAT-PUB-2 | | |
| |Dest=R-NAT-PUB-2| | |
| |USE-CANDIDATE | | |
| | | | |
| | | |(57) Bind Req |
| | | |--------------->|
| | | |Src=L-NAT-PUB-2 |
| | | |Dest=R-PRIV-2 |
| | | |USE-CANDIDATE |
| | | | |
| | | |(58) Bind Res |
| | | |<---------------|
| | | |Src=R-PRIV-2 |
| | | |Dest=L-NAT-PUB-2|
| | | |Map=L-NAT-PUB-2 |
| | | | |
| | |(59) Bind Res | |
| |<--------------------------------| |
| | |Src=R-NAT-PUB-2 | |
| | |Dest=L-NAT-PUB-2| |
| | |Map=L-NAT-PUB-2 | |
| | | | |
|(60) Bind Res | | | |
|<---------------| | | |
|Src=R-NAT-PUB-2 | | | |
|Dest=L-PRIV-2 | | | |
|Map=L-NAT-PUB-2 | | | |
| | | | |
| | | | |
|(61) SIP INVITE | | | |
|------------------------------------------------->| | |------------------------------------------------->| |
| | | | | | | | | |
| | | |(50) SIP INVITE | | | | |(62) SIP INVITE |
| | | |--------------->| | | | |--------------->|
| | | | | | | | | |
| | | |(51) SIP 200 OK | | | | |(63) SIP 200 OK |
| |<-------------------------------------------------| | |<-------------------------------------------------|
| | | | | | | | | |
|(52) SIP 200 OK | | | | |(64) SIP 200 OK | | | |
|<---------------| | | | |<---------------| | | |
| | | | | | | | | |
|(53) SIP ACK | | | | |(65) SIP ACK | | | |
|------------------------------------------------->| | |------------------------------------------------->| |
| | | | | | | | | |
| | | |(54) SIP ACK | | | | |(66) SIP ACK |
| | | |--------------->| | | | |--------------->|
| | | | | | | | | |
Figure 22: Endpoint Independent NAT with ICE Figure 22: Endpoint Independent NAT with ICE
o On deciding to initiate a SIP voice session the SIP client 'L' o On deciding to initiate a SIP voice session the SIP client 'L'
starts a local STUN client. The STUN client generates a standard starts a local STUN client. The STUN client generates a standard
Allocate request as indicated in (1) from Figure 22 which also Allocate request as indicated in (1) from Figure 22 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 STUN 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 Allocate message (2) traverses the NAT and breaks out onto the
o The Allocate message (2) traverses the NAT and breaks out onto the
public internet towards the public STUN server. Note that the public internet towards the public STUN server. Note that the
source address of the Allocate request now represents the public source address of the Allocate request now represents the public
address and port from the public side of the NAT (L-NAT-PUB-1). address and port from the public side of the NAT (L-NAT-PUB-1).
o The STUN server receives the Allocate request and processes o The STUN server receives the Allocate request and processes
appropriately. This results in a successful Allocate response appropriately. This results in a successful Allocate response
being generated and returned (3). The message contains details of being generated and returned (3). The message contains details of
the reflexive address which is to be used by the originating the server reflexive address which is to be used by the
client to receive media (see 'Map=L-NAT-PUB-1') from (3)). It originating client to receive media (see 'Map=L-NAT-PUB-1') from
also contains an appropriate relay address that can be used at the (3)). It also contains an appropriate relayed address that can be
STUN server (see 'Rel=STUN-PUB-2'). used at the STUN server (see 'Rel=STUN-PUB-2').
o The STUN response traverses back through the NAT using the binding o The Allocate response traverses back through the NAT using the
created by the initial Allocate request and presents the new binding created by the initial Allocate request and presents the
mapped address to the client (4). The process is repeated and a new mapped address to the client (4). The process is repeated and
second STUN derived set of address' are obtained, as illustrated a second STUN derived set of address' are obtained, as illustrated
in (5)-(8) in Figure 22. At this point the User Agent behind the in (5)-(8) in Figure 22. At this point the User Agent behind the
NAT has pairs of derived external reflexive and relayed NAT has pairs of derived external server reflexive and relayed
representations. The client would be free to gather any number of representations. The client would be free to gather any number of
external representations using any UNSAF[9] compliant protocol. external representations using any UNSAF[9] compliant protocol.
o The client now constructs a SIP INVITE message (9). The INVITE o The client now constructs a SIP INVITE message (9). The INVITE
request will use the addresses it has obtained in the previous request will use the addresses it has obtained in the previous
STUN/TURN interactions to populate the SDP of the SIP INVITE. STUN/TURN interactions to populate the SDP of the SIP INVITE.
This should be carried out in accordance with the semantics This should be carried out in accordance with the semantics
defined in the ICE specification[16], as shown below in Figure 23 defined in the ICE specification[16], as shown below in Figure 23
(*note - /* signifies line continuation): (*note - /* signifies line continuation):
v=0 v=0
o=test 2890844526 2890842807 IN IP4 $L-PRIV-1 o=test 2890844526 2890842807 IN IP4 $L-PRIV-1
c=IN IP4 $L-PRIV-1.address c=IN IP4 $L-PRIV-1.address
t=0 0 t=0 0
a=ice-pwd:$LPASS a=ice-pwd:$LPASS
a=ice-ufrag:$LUNAME
m=audio $L-PRIV-1.port RTP/AVP 0 m=audio $L-PRIV-1.port RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtcp:$L-PRIV-2.port a=rtcp:$L-PRIV-2.port
a=candidate:$L1 1 UDP 1.0 $L-PRIV-1.address $L-PRIV-1.port a=candidate:$L1 1 UDP 3102938476 $L-PRIV-1.address $L-PRIV-1.port typ local
a=candidate:$L1 2 UDP 1.0 $L-PRIV-2.address $L-PRIV-2.port a=candidate:$L1 2 UDP 3010948635 $L-PRIV-2.address $L-PRIV-2.port typ local
a=candidate:$L2 1 UDP 0.7 $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
a=candidate:$L2 2 UDP 0.7 $L-NAT-PUB-2.address $L-NAT-PUB-2.port /* raddr $L-PRIV-1.address rport $L-PRIV-1.port
a=candidate:$L3 1 UDP 0.3 $STUN-PUB-2.address $STUN-PUB-2.port a=candidate:$L2 2 UDP 2172635342 $L-NAT-PUB-2.address $L-NAT-PUB-2.port typ srflx
a=candidate:$L3 2 UDP 0.3 $STUN-PUB-3.address $STUN-PUB-3.port /* raddr $L-PRIV-1.address rport $L-PRIV-2.port
a=candidate:$L3 1 UDP 1763546473 $STUN-PUB-2.address $STUN-PUB-2.port typ relay
/* raddr $L-PRIV-1.address rport $L-PRIV-1.port
a=candidate:$L3 2 UDP 1109384746 $STUN-PUB-3.address $STUN-PUB-3.port typ relay
/* raddr $L-PRIV-1.address rport $L-PRIV-2.port
Figure 23: ICE SDP Offer Figure 23: ICE SDP Offer
o The SDP has been constructed to include all the available o The SDP has been constructed to include all the available
candidate pairs that have been assembled. The first candidate candidates that have been assembled. The first set of candidates
pair (as identified by $L1) contain two local addresses that have (as identified by Foundation $L1) contain two local addresses that
the highest priority (1.0). 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 connection (c=) and media (m=) lines of the SDP. The second set
'candidate' address pair, as identified by the component-id, of candidates, as identified by Foundation $L2, contains the two
contains the two NAT reflexive addresses obtained from the STUN server reflexive addresses obtained from the STUN server for both
server for both RTP and RTCP traffic (identified by candidate-id RTP and RTCP traffic (identified by candidate-id $L2). This entry
$L2). This entry has been given a priority (0.7) by the client. has been given a priority lower than the pair $L1 by the client.
The third and final candidate pair represents the relayed The third and final set of candidates represents the relayed
addresses (as identified by $L3) obtained from the STUN server. addresses (as identified by $L3) obtained from the STUN server.
This pair has the lowest priority (0.3) and will be used as a last This pair has the lowest priority and will be used as a last
resort. resort if both $L1 or $L2 fail.
o The SIP signalling then traverses the NAT and sets up the SIP o The SIP signaling then traverses the NAT and sets up the SIP
session (9)-(10). On advertising a candidate address, the client session (9)-(10). On advertising a candidate address, the client
should have a local STUN server running on each advertised should have a local STUN server running on each advertised
candidate address. This is for the purpose of responding to candidate address. This is for the purpose of responding to
incoming connectivity checks. incoming STUN connectivity checks.
o On receiving the SIP INVITE request (10) client 'R' also starts o On receiving the SIP INVITE request (10) client 'R' also starts
local STUN servers on appropriate address/port combinations and local STUN servers on appropriate address/port combinations and
gathers potential candidate addresses to be encoded into the SDP. gathers potential candidate addresses to be encoded into the SDP
Steps (11-18) involve client 'R' carrying out the same steps as (as the originating client did). Steps (11-18) involve client 'R'
client 'L'. This involves obtaining local, reflexive and relayed carrying out the same steps as client 'L'. This involves
addresses. Client 'R' is now ready to generate an appropriate obtaining local, server reflexive and relayed addresses. Client
answer in the SIP 200 OK message (19). The example answer follows 'R' is now ready to generate an appropriate answer in the SIP 200
in Figure 23 (*note - /* signifies line continuation): OK message (19). The example answer follows in Figure 23 (*note -
/* signifies line continuation):
v=0 v=0
o=test 3890844516 3890842803 IN IP4 $R-PRIV-1 o=test 3890844516 3890842803 IN IP4 $R-PRIV-1
c=IN IP4 $R-PRIV-1.address c=IN IP4 $R-PRIV-1.address
t=0 0 t=0 0
a=ice-pwd:$RPASS a=ice-pwd:$RPASS
m=audio $R-PRIV-1.port RTP/AVP 0 m=audio $R-PRIV-1.port RTP/AVP 0
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtcp:$R-PRIV-2.port a=rtcp:$R-PRIV-2.port
a=candidate:$L1 1 UDP 1.0 $R-PRIV-1.address $R-PRIV-1.port a=candidate:$L1 1 UDP 3303948573 $R-PRIV-1.address $R-PRIV-1.port typ local
a=candidate:$L1 2 UDP 1.0 $R-PRIV-2.address $R-PRIV-2.port a=candidate:$L1 2 UDP 3184756473 $R-PRIV-2.address $R-PRIV-2.port typ local
a=candidate:$L2 1 UDP 0.7 $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
a=candidate:$L2 2 UDP 0.7 $R-NAT-PUB-2.address $R-NAT-PUB-2.port /* raddr $R-PRIV-1.address rport $R-PRIV-1.port
a=candidate:$L3 1 UDP 0.3 $STUN-PUB-2.address $STUN-PUB-4.port a=candidate:$L2 2 UDP 2605968473 $R-NAT-PUB-2.address $R-NAT-PUB-2.port typ srflx
a=candidate:$L3 2 UDP 0.3 $STUN-PUB-3.address $STUN-PUB-5.port /* raddr $R-PRIV-1.address rport $R-PRIV-1.port
a=candidate:$L3 1 UDP 1453647488 $STUN-PUB-2.address $STUN-PUB-4.port typ relay
/* raddr $R-PRIV-1.address rport $R-PRIV-1.port
a=candidate:$L3 2 UDP 1183948473 $STUN-PUB-3.address $STUN-PUB-5.port typ relay
/* raddr $R-PRIV-1.address rport $R-PRIV-1.port
Figure 24: ICE SDP Answer Figure 24: ICE SDP Answer
o The two clients will now form candidate pairs and the transport o The two clients have now exchanged SDP using offer/answer and can
address check list as specified in ICE. Both 'L' and 'R' will now continue with the ICE processing - User Agent 'L' assuming the
start the check list with the currently active component pair role controlling agent, as specified by ICE. The clients are now
(contained in the 'c=' and 'm=' of the SDP). As illustrated in required to form their Candidate check lists to determine which
(23), client 'L' constructs a STUN Bind request in an attempt to will be used for the media streams. In this example User Agent
validate the connection address received in the SDP of the 200 OK 'L's 'Foundation 1' is paired with User Agent 'R's 'Foundation 1',
(20). As a private address was specified in the active address in User Agent 'L's 'Foundation 2' is paired with User Agent 'R's
the SDP, the Stun Bind request fails to reach its destination 'Foundation 2', and finally User Agent 'L's 'Foundation 3' is
causing a bind failure. Client 'L' now attempts a STUN Bind paired with User Agent 'R's 'Foundation 3'. User Agents 'L' and
request for the first candidate pair in the returned SDP with the 'R' now have a complete candidate check list. Both clients now
highest priority (24). As can be seen from messages (24) to (29), use the algorithm provided in ICE to determine candidate pair
the STUN Bind request is successful and returns a positive outcome priorities and sort into a list of decreasing priorities. In this
for the connectivity check. Client 'L' is now free to steam media example, both User Agent 'L' and 'R' will have lists that firstly
to the candidate pair. Client 'R' also carries out the same set specifies the host address (Foundation $L1), then the server
of binding requests. It firstly (in parallel) tries to contact reflexive address (Foundation $L2) and lastly the relayed address
the active address contained in the SDP (30). Client 'R' now (Foundation $L3). All candidate pairs have an associate state as
attempts a STUN Bind request for the first candidate pair in the specified in ICE. At this stage, all of the candidate pairs for
returned SDP with the highest priority (31). As can be seen from User Agents 'L' and 'R' are initialized to the 'Frozen' state.
messages (31) to (36), the STUN bind request is successful and The User Agents then scan the list and move the candidates to the
returns a positive outcome for the connectivity check. The 'Waiting' state. At this point both clients will periodically,
previously described check confirm on both sides that connectivity starting with the highest candidate pair priority, work there way
can be achieved through appropriate candidates. As part of the down the list issuing STUN checks from the local candidate to the
process in this example, both 'L' and 'R' will now complete the remote candidate (of the candidate pair). As a STUN Check is
same connectivity checks for part 2 of the component named for attempted from each local candidate in the list, the candidate
each candidate for use with RTCP. The connectivity checks for pair state transitions to 'In-Progress'. As illustrated in (23),
part '2' of the candidate component are shown in 'L'(37-42) and client 'L' constructs a STUN connectivity check in an attempt to
'R'(43-48). validate the remote candidate address received in the SDP of the
o The candidates have now been fully verified (Valid status) and as 200 OK (20) for the highest priority in the check list. As a
they are the highest priority, an updated offer (49-50) is now private address was specified in the active address in the SDP,
sent from the offerer (client 'L') to the answerer (client 'R' the STUN connectivity check fails to reach its destination causing
a STUN failure. Client 'L' transitions the state for this
candidate pair to 'Failed'. In the mean time, Client 'L' is
attempting a STUN connectivity check for the second candidate pair
in the returned SDP with the second highest priority (24). As can
be seen from messages (24) to (29), the STUN Bind request is
successful and returns a positive outcome for the connectivity
check. Client 'L' is now free to steam media to the candidate
pair. Client 'R' also carries out the same set of binding
requests. It firstly (in parallel) tries to contact the active
address contained in the SDP (30) which results in failure.
o In the mean time, a successful response to a STUN connectivity
check by User Agent 'R' (27) results in a tentative check in the
reverse direction - this is illustrated by messages (31) to (36).
Once this check has succeeded, User Agent 'R' can transition the
state of the appropriate candidate to 'Succeeded', and media can
be sent (RTP). The previously described check confirm on both
sides (User Agent 'L' and 'R') that connectivity can be achieved
using the appropriate candidate pair. User Agent 'L', as the
controlling client now sends another connectivity check for the
candidate pair, this time including the 'USE-CANDIDATE' attribute
as specified in ICE to signal the chosen candidate. This exchange
is illustrated in messages (37) to (42).
o As part of the process in this example, both 'L' and 'R' will now
complete the same connectivity checks for part 2 of the component
named for the favored 'Foundation' selected for use with RTCP.
The connectivity checks for part '2' of the candidate component
are shown in 'L'(43-48) and 'R'(49-54). Once this has succeeded,
User Agent 'L' as the controlling client sends another
connectivity check for the candidate pair. This time the 'USE-
CANDIDATE' attribute is again specified to signal the chosen
candidate for component '2'.
o The candidates have now been fully verified (and selected) and as
they are the highest priority, an updated offer (61-62) is now
sent from the offerer (client 'L') to the answerer (client 'R')
representing the new active candidates. The new offer would look representing the new active candidates. The new offer would look
as follows: as follows:
v=0 v=0
o=test 2890844526 2890842808 IN IP4 $L-PRIV-1 o=test 2890844526 2890842808 IN IP4 $L-PRIV-1
c=IN IP4 $L-NAT-PUB-1.address c=IN IP4 $L-NAT-PUB-1.address
t=0 0 t=0 0
a=ice-pwd:$LPASS a=ice-pwd:$LPASS
a=ice-ufrag:$LUNAME
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 0.7 $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
a=candidate:$L2 2 UDP 0.7 $L-NAT-PUB-2.address $L-NAT-PUB-2.port /* 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 typ srflx
/* raddr $L-PRIV-1.address rport $L-PRIV-2.port
Figure 25: ICE SDP Updated Offer Figure 25: ICE SDP Updated Offer
o The resulting answer (51-52) 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 3890842803 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
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 0.7 $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
a=candidate:$L2 2 UDP 0.7 $R-NAT-PUB-2.address $R-NAT-PUB-2.port /* 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 typ srflx
/* raddr $R-PRIV-1.address rport $R-PRIV-2.port
Figure 26: ICE SDP Updated Answer Figure 26: ICE SDP Updated Answer
4.2.2. Port and Address Dependant NAT 4.2.2. Address and Port Dependant NAT
4.2.2.1. STUN Failure 4.2.2.1. STUN Failure
This section highlights that while STUN is the preferred mechanism This section highlights that while STUN is the preferred mechanism
for traversal of NAT, it does not solve every case. The use of basic for traversal of NAT, it does not solve every case. The use of basic
STUN on its own will not guarantee traversal through every NAT type, STUN on its own will not guarantee traversal through every NAT type,
hence the recommendation that ICE is the preferred option. hence the recommendation that ICE is the preferred option.
Client PORT/ADDRESS Dependant STUN [..] Client PORT/ADDRESS Dependant STUN [..]
NAT Server NAT Server
| | | | | | | |
|(1) STUN Req | | | |(1) BIND Req | | |
|Src=L-PRIV-1 | | | |Src=L-PRIV-1 | | |
|Dest=STUN-PUB | | | |Dest=STUN-PUB | | |
|----------------->| | | |----------------->| | |
| | | | | | | |
| |(2) STUN Req | | | |(2) BIND Req | |
| |Src=NAT-PUB-1 | | | |Src=NAT-PUB-1 | |
| |Dest=STUN-PUB | | | |Dest=STUN-PUB | |
| |----------------->| | | |----------------->| |
| | | | | | | |
| |(3) STUN Resp | | | |(3) BIND Resp | |
| |<-----------------| | | |<-----------------| |
| |Src=STUN-PUB | | | |Src=STUN-PUB | |
| |Dest=NAT-PUB-1 | | | |Dest=NAT-PUB-1 | |
| |Map=NAT-PUB-1 | | | |Map=NAT-PUB-1 | |
| | | | | | | |
|(4) STUN Resp | | | |(4) BIND Resp | | |
|<-----------------| | | |<-----------------| | |
|Src=STUN-PUB | | | |Src=STUN-PUB | | |
|Dest=L-PRIV-1 | | | |Dest=L-PRIV-1 | | |
|Map=NAT-PUB-1 | | | |Map=NAT-PUB-1 | | |
| | | | | | | |
|(5)SIP INVITE | | | |(5)SIP INVITE | | |
|------------------------------------------------------->| |------------------------------------------------------->|
| | | | | | | |
| | |(6)SIP 200 OK | | | |(6)SIP 200 OK |
| |<------------------------------------| | |<------------------------------------|
skipping to change at page 42, line 10 skipping to change at page 45, line 10
|----------------->| | | |----------------->| | |
| |(9) SIP ACK | | | |(9) SIP ACK | |
| |------------------------------------>| | |------------------------------------>|
| | | | | | | |
Figure 27: Port/Address Dependant NAT with STUN - Failure Figure 27: Port/Address Dependant NAT with STUN - Failure
The example in Figure 27 is conveyed in the context of a client The example in Figure 27 is conveyed in the context of a client
behind the 'Port/Address Dependant' NAT initiating a call. It should behind the 'Port/Address Dependant' NAT initiating a call. It should
be noted that the same problem applies when a client receives a SIP be noted that the same problem applies when a client receives a SIP
invitation and is behind a Port/Address Dependant NAT. invitation and is behind a Port/Address Dependant NAT.
o In Figure 27 the client behind the NAT obtains an external o In Figure 27 the client behind the NAT obtains a server reflexive
representation using standard STUN mechanisms (1)-(4) that have representation using standard STUN mechanisms (1)-(4) that have
been used in previous examples in this document (e.g been used in previous examples in this document (e.g
Section 4.2.1.1.1). Section 4.2.1.1.1).
o The external mapped address (reflexive) obtained is also used in o The external mapped address (server reflexive) obtained is also
the outgoing SDP contained in the SIP INVITE request(5). used in the outgoing SDP contained in the SIP INVITE request(5).
o In this example the client is still able to send media to the o In this example the client is still able to send media to the
external client. The problem occurs when the client outside the external client. The problem occurs when the client outside the
NAT tries to use the reflexive address supplied in the outgoing NAT tries to use the reflexive address supplied in the outgoing
INVITE request to traverse media back through the 'Port/Address INVITE request to traverse media back through the 'Port/Address
Dependent' NAT. Dependent' NAT.
o A 'Port/Address Dependant' NAT has differing rules from the o A 'Port/Address Dependant' NAT has differing rules from the
'Endpoint Independent' type of NAT (as defined in [11]). For any 'Endpoint Independent' type of NAT (as defined in [11]). For any
internal IP address and port combination, data sent to a different internal IP address and port combination, data sent to a different
external destination does not provide the same public mapping at external destination does not provide the same public mapping at
the NAT. In Figure 27 the STUN query produced a valid external the NAT. In Figure 27 the STUN query produced a valid external
mapping or receiving media. This mapping, however, can only be mapping for receiving media. This mapping, however, can only be
used in the context of the original STUN request that was sent to used in the context of the original STUN request that was sent to
the STUN server. Any packets that attempt to use the mapped the STUN server. Any packets that attempt to use the mapped
address, that does not come from the STUN server IP address and address, that do not originate from the STUN server IP address and
optionally port, will be dropped at the NAT. Figure 27 shows the optionally port, will be dropped at the NAT. Figure 27 shows the
media being dropped at the NAT after (7) and before (8). This media being dropped at the NAT after (7) and before (8). This
then leads to one way audio. then leads to one way audio.
4.2.2.2. TURN Usage Solution 4.2.2.2. TURN Usage Solution
As identified in Section 4.2.2.1, STUN provides a useful tool kit for As identified in Section 4.2.2.1, STUN provides a useful tool kit for
the traversal of the majority of NATs but fails with Port/Address the traversal of the majority of NATs but fails with Port/Address
Dependant NAT. This led to the development of the TURN usage Dependant NAT. This led to the development of the TURN usage
solution [12] which uses the STUN toolkit. It allows a client to solution [12] which uses the STUN toolkit. It allows a client to
skipping to change at page 44, line 50 skipping to change at page 47, line 50
| |(14) SIP ACK | | | |(14) SIP ACK | |
| |------------------------------------>| | |------------------------------------>|
| | | | | | | |
Figure 28: Port/Address Dependant NAT with TURN Usage - Success Figure 28: Port/Address Dependant NAT with TURN Usage - Success
o In this example, client 'L' issues a TURN allocate request(1) to o In this example, client 'L' issues a TURN allocate request(1) to
obtained a relay address at the STUN server. The request obtained a relay address at the STUN server. The request
traverses through the 'Port/Address Dependant' NAT and reaches the traverses through the 'Port/Address Dependant' NAT and reaches the
STUN server (2). The STUN server generates an Allocate response STUN server (2). The STUN server generates an Allocate response
(3) that contains both a reflexive address (Map=NAT-PUB-1) of the (3) that contains both a server reflexive address (Map=NAT-PUB-1)
client and also a relayed address (Rel=STUN-PUB-2). The relayed of the client and also a relayed address (Rel=STUN-PUB-2). The
address maps to an address mapping on the STUN server which is relayed address maps to an address mapping on the STUN server
bound to the public pin hole that has been opened on the NAT by which is bound to the public pin hole that has been opened on the
the Allocate request. This results in any traffic sent to the NAT by the Allocate request. This results in any traffic sent to
STUN server relayed address (Rel=STUN-PUB-2) being forwarded to the STUN server relayed address (Rel=STUN-PUB-2) being forwarded
the external representation of the pin hole created by the to the external representation of the pin hole created by the
Allocate request(NAT-PUB-1). Allocate request(NAT-PUB-1).
o The TURN derived address (STUN-PUB-2) arrives back at the o The TURN derived address (STUN-PUB-2) arrives back at the
originating client(4) in an Allocate response. This address can originating client(4) in an Allocate response. This address can
then be used in the SDP for the outgoing SIP INVITE request as then be used in the SDP for the outgoing SIP INVITE request as
shown in the following example (note that the example also shown in the following example (note that the example also
includes client 'L' obtaining a second relay address for use in includes client 'L' obtaining a second relay address for use in
the RTCP attribute (5-8)): the RTCP attribute (5-8)):
o o
v=0 v=0
skipping to change at page 45, line 44 skipping to change at page 48, line 44
o The TURN usage of STUN on its own will work for 'Port/Address o The TURN usage of STUN on its own will work for 'Port/Address
Dependent' and other types of NAT mentioned in this specification Dependent' and other types of NAT mentioned in this specification
but should only be used as a last resort. The relaying of media but should only be used as a last resort. The relaying of media
through an external entity is not an efficient mechanism for NAT through an external entity is not an efficient mechanism for NAT
traversal and comes at a high processing cost. traversal and comes at a high processing cost.
4.2.2.3. ICE Solution 4.2.2.3. ICE Solution
The previous two examples have highlighted the problem with using The previous two examples have highlighted the problem with using
core STUN usage for all forms of NAT traversal and a solution using core STUN usage for all forms of NAT traversal and a solution using
TURN usage for the Port/Address Dependant NAT case. As mentioned TURN usage for the Address/Port Dependant NAT case. As mentioned
previously in this document, the RECOMMENDED mechanism for traversing previously in this document, the RECOMMENDED mechanism for traversing
all varieties of NAT is using ICE, as detailed in Section 3.2.4. ICE all varieties of NAT is using ICE, as detailed in Section 3.2.4. ICE
makes use of core STUN, TURN usage and any other UNSAF[9] compliant makes use of core STUN, TURN usage and any other UNSAF[9] compliant
protocol to provide a list of prioritised addresses that can be used protocol to provide a list of prioritized addresses that can be used
for media traffic. Detailed examples of ICE can be found in for media traffic. Detailed examples of ICE can be found in
Section 4.2.1.2.1. These examples are associated with an 'Endpoint Section 4.2.1.2.1. These examples are associated with an 'Endpoint
Independent' type NAT but can be applied to any NAT type variation, Independent' type NAT but can be applied to any NAT type variation,
including 'Port/Address Dependant' type NAT. The procedures are the including 'Address/Port Dependant' type NAT. The ICE procedures
same and of the list of candidate addresses, a client will choose procedures carried out are the same. For a list of candidate
where to send media dependant on the results of the STUN connectivity addresses, a client will choose where to send media dependant on the
checks on each candidate address and the associated priority (highest results of the STUN connectivity checks and associated priority
priority wins). For more information see the core ICE (highest priority wins). It should be noted that the inclusion of a
specification[16] NAT displaying Address/Port Dependent properties does not
automatically result in relayed media. In fact, ICE processing will
avoid use of media with the exception of two clients which both
happen to be behind a NAT using Address/Port Dependent
characteristics.
[Editors Note: TODO - a detailed example will be included here which Using the example described in Section 4.2.1.2.1, lets change the
includes promotion of a TURN relayed address to the active candidate example so that both clients 'L' and 'R' are behind NATs that have
to traverse a 'Port/Address Dependent' type NAT.] Address/Port Dependant behavior. In this new example, the previously
successful server reflexive STUN connectivity checks would in fact
fail and result in the User Agents attempting their final candidate
pair checks (e.g. $L3 from Figure 23 and Figure 24). The
connectivity checks would be successful and become the favored
candidate pair (signalled by STUN 'USE-CANDIDATE' in a subsequent
STUN connectivity check). The relayed candidates would then be used
in the subsequent SIP offer/answer update.
[Editors Note: Is this enough? Do we need a another full ICE example
of this scenario?]
4.3. Address independent Port Restricted NAT --> Address independent 4.3. Address independent Port Restricted NAT --> Address independent
Port Restricted NAT traversal Port Restricted NAT traversal
[Editors Note: TODO - a detailed example will be included where User [Editors Note: TODO - a detailed example will be included where User
A and B are both behind Address Independent NATs that have Port A and B are both behind Address Independent NATs that have Port
restricted properties. This means that the stun-derived addresses restricted properties. This means that the stun-derived addresses
will work, but each side must send a 'suicide' or 'primer' STUN will work, but each side must send a 'suicide' or 'primer' STUN
packet that creates a permission in the NAT. So, the main thing to packet that creates a permission in the NAT. So, the main thing to
show here is how the first packet from B to A will create a show here is how the first packet from B to A will create a
skipping to change at page 47, line 5 skipping to change at page 50, line 19
the same TURN server. However, when talking to one instance the the same TURN server. However, when talking to one instance the
client gets the public address. When talking to the other instance client gets the public address. When talking to the other instance
it gets a private address inside the NAT. The ice process ends up it gets a private address inside the NAT. The ice process ends up
selecting the public address given out by the TURN server usage.] selecting the public address given out by the TURN server usage.]
5. Intercepting Intermediary (B2BUA) 5. Intercepting Intermediary (B2BUA)
[Editors Note: TODO - a detailed example demonstrating how a B2BUA [Editors Note: TODO - a detailed example demonstrating how a B2BUA
can obtain STUN/TURN addresses for the purpose of allocating to can obtain STUN/TURN addresses for the purpose of allocating to
Clients. This example shows how intermediaries can control the flow Clients. This example shows how intermediaries can control the flow
of media without having to directly access SDP on the signalling of media without having to directly access SDP on the signaling
plane. plane.
6. IPv4-IPv6 Transition 6. IPv4-IPv6 Transition
This section describes how IPv6-only SIP user agents can communicate This section describes how IPv6-only SIP user agents can communicate
with IPv4-only SIP user agents. with IPv4-only SIP user agents.
6.1. IPv4-IPv6 Transition for SIP Signalling 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 [19] detailed description of this type of translation can be found in [19]
6.2. IPv4-IPv6 Transition for Media 6.2. IPv4-IPv6 Transition for Media
Figure 30 shows a network of IPv6 SIP user agents that has a relay Figure 30 shows a network of IPv6 SIP user agents that has a relay
with a pool of public IPv4 addresses. The IPv6 SIP user agents of with a pool of public IPv4 addresses. The IPv6 SIP user agents of
this IPv6 network need to communicate with users on the IPv4 this IPv6 network need to communicate with users on the IPv4
Internet. To do so, the IPv6 SIP user agents use TURN to obtain a Internet. To do so, the IPv6 SIP user agents use the TURN usage to
public IPv4 address from the relay. The mechanism that an IPv6 SIP obtain a public IPv4 address from the relay. The mechanism that an
user agent follows to obtain a public IPv4 address from a relay using IPv6 SIP user agent follows to obtain a public IPv4 address from a
TURN is the same as the one followed by a user agent with a private relay using the TURN usage is the same as the one followed by a user
IPv4 address to obtain a public IPv4 address. The example in agent with a private IPv4 address to obtain a public IPv4 address.
Figure 31 explains how to use TURN to obtain an IPv4 address and how The example in Figure 31 explains how to use the TURN usage to obtain
to use the ANAT semantics [17] of the SDP grouping framework [8] to an IPv4 address and how to use the ANAT semantics [17] of the SDP
provide both IPv4 and IPv6 addresses for a particular media stream. grouping framework [8] to provide both IPv4 and IPv6 addresses for a
particular media stream.
+----------+ +----------+
| / \ | | / \ |
/SIP \ /SIP \
/Phone \ /Phone \
/ \ / \
------------ ------------
IPv4 Network IPv4 Network
192.0.2.0/8 192.0.2.0/8
skipping to change at page 49, line 7 skipping to change at page 52, line 7
| IPv6 | | IPv6 |
| SIP | | SIP |
| user | | user |
| agent| | agent|
+------+ +------+
Figure 30: IPv6-IPv4 transition scenario Figure 30: IPv6-IPv4 transition scenario
IPv6 SIP TURN IPv4 SIP IPv6 SIP TURN IPv4 SIP
User Agent Server User Agent User Agent Server User Agent
| | | | | |
| (1) TURN Allocate | | | (1) STUN Allocate | |
| src=[2001:DB8::1]:30000 | | | src=[2001:DB8::1]:30000 | |
|------------------------------------>| | |------------------------------------>| |
| (2) TURN Resp | | | (2) TURN Resp | |
| map=192.0.2.2:25000 | | | rel=192.0.2.2:25000 | |
| dest=[2001:DB8::1]:30000 | | | dest=[2001:DB8::1]:30000 | |
|<------------------------------------| | |<------------------------------------| |
| (3) SIP INVITE | | | (3) SIP INVITE | |
|------------------------------------------------------->| |------------------------------------------------------->|
| (4) SIP 200 OK | | | (4) SIP 200 OK | |
|<-------------------------------------------------------| |<-------------------------------------------------------|
| | | | | |
|=====================================| | |=====================================| |
|>>>>>>>>>> Outgoing Media >>>>>>>>>>>| | |>>>>>>>>>> Outgoing Media >>>>>>>>>>>| |
|=====================================| | |=====================================| |
skipping to change at page 49, line 40 skipping to change at page 52, line 40
|<<<<<<<<<< Outgoing Media <<<<<<<<<<<| | |<<<<<<<<<< Outgoing Media <<<<<<<<<<<| |
|=====================================| | |=====================================| |
| | | | | |
| (5) SIP ACK | | | (5) SIP ACK | |
|------------------------------------------------------->| |------------------------------------------------------->|
| | | | | |
Figure 31: IPv6-IPv4 translation with TURN Figure 31: IPv6-IPv4 translation with TURN
o The IPv6 SIP user agent obtains a TURN-derived IPv4 address by o The IPv6 SIP user agent obtains a TURN-derived IPv4 address by
issuing a TURN allocate request (1). The TURN server generates a issuing a STUN Allocate request (1). The STUN server generates a
response that contains the public IPv4 address. This IPv4 address response that contains a relayed IPv4 address using the TURN
maps to the IPv6 source address of the TURN allocate request, usage. This IPv4 address maps to the IPv6 source address of the
which the IPv6 address of the SIP user agent. This results in any STUN Allocate request, which the IPv6 address of the SIP user
traffic being sent to the IPv4 address provided by TURN server agent. This results in any traffic being sent to the IPv4 address
(192.0.2.2:25000) will be redirected to the IPv6 address of the provided by STUN server (192.0.2.2:25000) will be redirected to
SIP user agent ([2001:DB8::1]:30000). the IPv6 address of the SIP user agent ([2001:DB8::1]:30000).
o The TURN-derived address (192.0.2.2:25000) arrives back at the o The TURN-derived address (192.0.2.2:25000) arrives back at the
originating user agent (2). This address can then be used in the originating user agent (2). This address can then be used in the
SDP for the outgoing SIP INVITE request. The user agent builds SDP for the outgoing SIP INVITE request. The user agent builds
two media lines, one with its IPv6 address and the other with the two media lines, one with its IPv6 address and the other with the
IPv4 address that was just obtained. The user agent groups both IPv4 address that was just obtained. The user agent groups both
media lines using the ANAT semantics as shown below (note that the media lines using the ANAT semantics as shown below (note that the
RTCP attribute in the IPv4 media line would have been obtained by RTCP attribute in the IPv4 media line would have been obtained by
another TURN-derived address which is not shown in the call flow another TURN-derived address which is not shown in the call flow
for simplicity). for simplicity).
skipping to change at page 50, line 33 skipping to change at page 53, line 33
IPv6 media line by setting its port to zero in the answer and IPv6 media line by setting its port to zero in the answer and
starts sending media to the IPv4 address in the offer. The IPv6 starts sending media to the IPv4 address in the offer. The IPv6
user agent sends media through the relay as well, as shown in user agent sends media through the relay as well, as shown in
Figure 31. Figure 31.
7. ICE with RTP/TCP 7. ICE with RTP/TCP
[Editors Note: TODO - a detailed example will be included on using [Editors Note: TODO - a detailed example will be included on using
ICE with RTP/TCP - as define in [18] ICE with RTP/TCP - as define in [18]
8. Acknowledgments 8. ICE Lite
[Editors Note: TODO - a detailed example will be included on using
ICE with RTP/TCP - as define in [18]
9. Acknowledgments
The authors would like to thank the members of the IETF SIPPING WG The authors would like to thank the members of the IETF SIPPING WG
for their comments and suggestions. Detailed comments were provided for their comments and suggestions. Detailed comments were provided
by Francois Audet, kaiduan xie and Hans Persson. by Francois Audet, kaiduan xie and Hans Persson.
9. References 10. References
9.1. Normative References 10.1. Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", "RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 1889, January 1996. RFC 3550, July 2003.
[3] Handley, M. and V. Jacobson, "SDP: Session Description [3] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[4] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - [4] Tsirtsis, G. and P. Srisuresh, "Network Address Translation -
Protocol Translation (NAT-PT)", RFC 2766, February 2000. Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
skipping to change at page 51, line 32 skipping to change at page 54, line 40
RFC 3327, December 2002. RFC 3327, December 2002.
[8] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, [8] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne,
"Grouping of Media Lines in the Session Description Protocol "Grouping of Media Lines in the Session Description Protocol
(SDP)", RFC 3388, December 2002. (SDP)", RFC 3388, December 2002.
[9] Daigle, L. and IAB, "IAB Considerations for UNilateral Self- [9] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-
Address Fixing (UNSAF) Across Network Address Translation", Address Fixing (UNSAF) Across Network Address Translation",
RFC 3424, November 2002. RFC 3424, November 2002.
[10] Rosenberg, J., "Simple Traversal of UDP Through Network Address [10] Rosenberg, J., "Simple Traversal Underneath Network Address
Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-03 Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-05
(work in progress), March 2006. (work in progress), October 2006.
[11] Audet, F. and C. Jennings, "NAT Behavioral Requirements for [11] Audet, F. and C. Jennings, "NAT Behavioral Requirements for
Unicast UDP", draft-ietf-behave-nat-udp-07 (work in progress), Unicast UDP", draft-ietf-behave-nat-udp-08 (work in progress),
June 2006. October 2006.
[12] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal [12] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal
of UDP Through NAT (STUN)", draft-ietf-behave-turn-00 (work in Underneath NAT (STUN)", draft-ietf-behave-turn-02 (work in
progress), March 2006. progress), October 2006.
[13] Jennings, C. and A. Hawrylyshen, "SIP Conventions for UAs with [13] Jennings, C. and A. Hawrylyshen, "SIP Conventions for UAs with
Outbound Only Connections", draft-jennings-sipping-outbound-01 Outbound Only Connections", draft-jennings-sipping-outbound-01
(work in progress), February 2005. (work in progress), February 2005.
[14] Rosenberg, J., "Obtaining and Using Globally Routable User [14] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-09 (work in progress), June 2006. (SIP)", draft-ietf-sip-gruu-11 (work in progress),
October 2006.
[15] Wing, D., "Symmetric RTP and RTCP Considered Helpful", [15] Wing, D., "Symmetric RTP and RTCP Considered Helpful",
draft-wing-mmusic-symmetric-rtprtcp-01 (work in progress), draft-wing-mmusic-symmetric-rtprtcp-01 (work in progress),
October 2004. October 2004.
[16] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A [16] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for Methodology for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols", draft-ietf-mmusic-ice-08 (work in Offer/Answer Protocols", draft-ietf-mmusic-ice-13 (work in
progress), March 2006. progress), January 2007.
[17] Camarillo, G., "The Alternative Network Address Types Semantics [17] Camarillo, G., "The Alternative Network Address Types Semantics
(ANAT) for theSession Description Protocol (SDP) Grouping (ANAT) for theSession Description Protocol (SDP) Grouping
Framework", draft-ietf-mmusic-anat-02 (work in progress), Framework", draft-ietf-mmusic-anat-02 (work in progress),
October 2004. October 2004.
[18] Rosenberg, J., "TCP Candidates with Interactive Connectivity [18] Rosenberg, J., "TCP Candidates with Interactive Connectivity
Establishment (ICE)", draft-ietf-mmusic-ice-tcp-00 (work in Establishment (ICE)", draft-ietf-mmusic-ice-tcp-02 (work in
progress), March 2006. progress), October 2006.
9.2. Informative References 10.2. Informative References
[19] Camarillo, G., "IPv6 Transcition in the Session Initiation [19] Camarillo, G., "IPv6 Transcition in the Session Initiation
Protocol (SIP)", draft-camarillo-sipping-v6-transition-00 (work Protocol (SIP)", draft-camarillo-sipping-v6-transition-00 (work
in progress), February 2005. in progress), February 2005.
Authors' Addresses Authors' Addresses
Chris Boulton Chris Boulton
Ubiquity Software Corporation Ubiquity Software Corporation
Eastern Business Park Eastern Business Park
skipping to change at page 54, line 5 skipping to change at page 57, line 5
Email: jdrosen@cisco.com Email: jdrosen@cisco.com
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Gonzalo.Camarillo@ericsson.com Email: Gonzalo.Camarillo@ericsson.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 54, line 29 skipping to change at page 57, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 120 change blocks. 
317 lines changed or deleted 467 lines changed or added

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