SIPPING Working Group                                         C. Boulton
Internet-Draft                                         Ubiquity Software
Expires: April 25, 2005                                     J. Rosenberg
                                                           Cisco Systems
                                                        October 25, 2004



            Best Current Practices for NAT Traversal for SIP
                  draft-ietf-sipping-nat-scenarios-01


Status of this Memo


   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any 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 become aware will be disclosed, in accordance with
   RFC 3668.


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."


   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


   This Internet-Draft will expire on April 25, 2005.


Copyright Notice


   Copyright (C) The Internet Society (2004).


Abstract


   Traversal of the Session Initiation Protocol (SIP) and the sessions
   it establishes through Network Address Translators (NAT) is a complex
   problem.  Currently there are many deployment scenarios and traversal
   mechanisms for media traffic.  This document aims to provide concrete
   recommendations and a unified method for NAT traversal as well as
   documenting corresponding call flows.




Boulton & Rosenberg      Expires April 25, 2005                 [Page 1]


Internet-Draft               NAT Scenarios                  October 2004



Table of Contents


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Solution Technology Outline Description  . . . . . . . . . . .  6
     3.1   SIP Signaling  . . . . . . . . . . . . . . . . . . . . . .  7
       3.1.1   Symmetric Response . . . . . . . . . . . . . . . . . .  7
       3.1.2   Connection Re-use  . . . . . . . . . . . . . . . . . .  8
     3.2   Media Traversal  . . . . . . . . . . . . . . . . . . . . .  8
       3.2.1   Symmetric RTP  . . . . . . . . . . . . . . . . . . . .  8
       3.2.2   STUN . . . . . . . . . . . . . . . . . . . . . . . . .  9
       3.2.3   TURN . . . . . . . . . . . . . . . . . . . . . . . . .  9
       3.2.4   ICE  . . . . . . . . . . . . . . . . . . . . . . . . .  9
       3.2.5   RTCP Attribute . . . . . . . . . . . . . . . . . . . . 10
       3.2.6   Solution Profiles  . . . . . . . . . . . . . . . . . . 10
   4.  NAT Traversal Scenarios  . . . . . . . . . . . . . . . . . . . 11
     4.1   Basic NAT SIP Signaling Traversal  . . . . . . . . . . . . 11
       4.1.1   Registration (Registrar/Proxy Co-Located . . . . . . . 11
       4.1.2   Registration(Registrar/Proxy not Co-Located) . . . . . 15
       4.1.3   Initiating a Session . . . . . . . . . . . . . . . . . 16
       4.1.4   Receiving an Invitation to a Session . . . . . . . . . 18
     4.2   Basic NAT Media Traversal  . . . . . . . . . . . . . . . . 21
       4.2.1   Full Cone NAT  . . . . . . . . . . . . . . . . . . . . 21
       4.2.2   Port Restricted Cone NAT . . . . . . . . . . . . . . . 21
       4.2.3   Symmetric NAT  . . . . . . . . . . . . . . . . . . . . 21
     4.3   Advanced NAT media Traversal Using ICE . . . . . . . . . . 22
       4.3.1   Full Cone --> Full Cone traversal  . . . . . . . . . . 22
       4.3.2   Port Restricted Cone --> Port Restricted Cone
               traversal  . . . . . . . . . . . . . . . . . . . . . . 22
       4.3.3   Internal TURN Server (Enterprise Deployment) . . . . . 22
     4.4   Intercepting Intermediary (B2BUA)  . . . . . . . . . . . . 22
     4.5   IPV4/IPV6  . . . . . . . . . . . . . . . . . . . . . . . . 23
   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
   5.1   Normative References . . . . . . . . . . . . . . . . . . . . 23
   5.2   Informative References . . . . . . . . . . . . . . . . . . . 24
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
       Intellectual Property and Copyright Statements . . . . . . . . 25















Boulton & Rosenberg      Expires April 25, 2005                 [Page 2]


Internet-Draft               NAT Scenarios                  October 2004



1.  Introduction


   NAT (Network Address Translators) traversal has long been identified
   as a large problem when considered in the context of the Session
   Initiation Protocol (SIP)[1] and it's associated media such as Real
   Time Protocol (RTP)[2].  The problem is further confused by the
   variety of NATs that are available in the market place today and the
   large number of potential deployment scenarios.  Detail of different
   NAT types can be found in RFC 3489bis [13].


   The IETF has produced many specifications for the traversal of NAT,
   including STUN, ICE, rport, symmetric RTP, TURN, connection reuse,
   SDP attribute for RTCP, and others.  These each represent a part of
   the solution, but none of them gives the overall context for how the
   NAT traversal problem is decomposed and solved through this
   collection of specifications.  This document serves to meet that
   need.


   This document attempts to provide a definitive set of 'Best Common
   Practices' to demonstrate the traversal of SIP and it's associated
   media through NAT devices.  The document does not propose any new
   functionality  but does draw on existing solutions for both core SIP
   signaling and media traversal (as defined in section 3).


   The draft will be split into distinct sections as follows:
   1.  A clear definition of the problem statement
   2.  Description of proposed solutions for both SIP protocol signaling
       and media signaling
   3.  A set of basic and advanced call flow scenarios


2.  Problem Statement


   The traversal of SIP through NAT can be split into two categories
   that both require attention - The core SIP signaling and associated
   media traversal.


   The core SIP signaling has a number of issues when traversing through
   NATs.


   Firstly, the default operation for SIP response generation using
   unreliable protocols such as the Unicast Datagram Protocol (UDP)
   results in responses being generated at the User Agent Server (UAS)
   being sent to the source address, as specified in either the SIP
   'Via' header or the 'received' parameter (as defined in RFC 3261
   [1]).  The port is extracted from the SIP 'Via' header to complete
   the IP address/port combination for returning the SIP response.
   While the destination is correct, the port contained in the SIP 'Via'
   header represents the listening port of the originating client and




Boulton & Rosenberg      Expires April 25, 2005                 [Page 3]


Internet-Draft               NAT Scenarios                  October 2004



   not the port representing the open pin hole on the NAT.  This results
   responses being sent back to the NAT but to a port that is likely not
   open for SIP traffic.  The SIP response will then be dropped at the
   NAT.  This is illustrated in Figure 1 which depicts a SIP response
   being returned to port 5060.



    Private Network                   NAT                      Public Network
                                       |
                                       |
                                       |
     --------     SIP Request          |open port 5650            --------
    |        |----------------------->--->-----------------------|        |
    |        |                         |                         |        |
    | Client |                         |port 5060   SIP Response | Proxy  |
    |        |                         x<------------------------|        |
    |        |                         |                         |        |
     --------                          |                          --------
                                       |
                                       |
                                       |


      Figure 1


   Secondly, when using a reliable, connection orientated transport
   protocol such as TCP, SIP has an inherent mechanism that results in
   SIP responses reusing the connection that was created/used for the
   corresponding transactional request.  The SIP protocol does not
   provide a mechanism that allows new requests generated in the
   opposite direction (Previously occupying the role of UAS for the last
   transaction) to use the existing TCP connection created between the
   client and the server during registration.  This results in the
   registered contact address not being bound to the "connection" in the
   case of TCP.  Requests are then blocked at the NAT, as illustrated in
   Figure 2.  This problem also exists for unreliable transport
   protocols such as UDP where external NAT mappings need to be re-used
   to reach a SIP entity on the private side of the network.















Boulton & Rosenberg      Expires April 25, 2005                 [Page 4]


Internet-Draft               NAT Scenarios                  October 2004



    Private Network                   NAT                      Public Network
                                       |
                                       |
                                       |
     -------- (UAC 8023)       REGISTER/Response       (UAS 5060) --------
    |        |----------------------->---<-----------------------|        |
    |        |                         |                         |        |
    | Client |                         |5060  INVITE   (UAC 8015)| Proxy  |
    |        |                         x<------------------------|        |
    |        |                         |                         |        |
     --------                          |                          --------
                                       |
                                       |
                                       |


      Figure 2



    In figure 2 the original REGISTER request is sent from the client on
   port 8023 and received on port 5060, establishing a reliable
   connection and opening a pin-hole in the NAT.  The generation of a
   new request from the proxy results in a request destined for the
   registered entity (Contact IP address) which is not reachable from
   the public network.  This results in the new SIP request attempting
   to create a connection to a private network address.  This problem
   would be solved if the original connection was re-used.  While this
   problem has been discussed in the context of connection orientated
   protocols such as TCP, the problem exists for SIP signaling using any
   transport protocol.  The solution proposed for this problem in
   section 3 of this document is relevant for all SIP signaling,
   regardless of the transport protocol.


   NAT policy can dictate that connections should be closed after a
   period of inactivity.  This period of inactivity can range
   drastically from a number seconds to hours.  Pure SIP signaling can
   not be relied upon to keep alive connections for a number of reasons.
   Firstly, SIP entities can sometimes have no signaling traffic for
   long periods of time which has the potential to exceed the inactivity
   timer, this can lead to problems where endpoints are not available to
   receive incoming requests as the connection has been closed.
   Secondly, if a low inactivity timer is specified, SIP signaling is
   not appropriate as a keep-alive mechanism as it has the potential to
   add a large amount of traffic to the network which uses up valuable
   resource and also requires processing at a SIP stack, which is also a
   waste of processing resource.


   Media associated with SIP calls also has problems traversing NAT.
   RTP[2]] is on if the most common media transport type used in SIP




Boulton & Rosenberg      Expires April 25, 2005                 [Page 5]


Internet-Draft               NAT Scenarios                  October 2004



   signaling.  Negotiation of RTP occurs with a SIP session
   establishment using the Session Description Protocol(SDP) [3] and a
   SIP offer/answer exchange[4].  During a SIP offer/answer exchange an
   IP address and port combination are specified by each client in a
   session as a means of receiving media such as RTP.  The problem
   arises when a client advertises it's address to receive media and it
   exists in a private network  that is not accessible from outside the
   NAT.  Figure 3 illustrates this problem.



                 NAT             Public Network             NAT
                  |                                          |
                  |                                          |
                  |                                          |
     --------     |            SIP Signaling Session         |    --------
    |        |----------------------->---<-----------------------|        |
    |        |    |                                          |   |        |
    | Client |    |                                          |   | Client |
    |   A    |>=========>RTP>=====================>RTP>======X   |   B    |
    |        |    X=====<RTP<=====================<RTP<=========<|        |
     --------     |                                          |     --------
                  |                                          |
                  |                                          |
                  |                                          |


      Figure 3


    The connection address representing both clients are not available
   on the public internet and traffic can be sent from both clients
   through their NATs.  The problem occurs when the traffic attempts to
   traverse media through the foreign (not local) NAT.  The connection
   address extracted from the SDP payload is that of an internal
   address, and so not resolvable from the public side of the NAT.  To
   complicate the problem further, a number of different NAT topologies
   with different default behaviors increase the difficulty of proposing
   a single solution.


3.  Solution Technology Outline Description


   When analyzing issues associated with traversal of SIP through
   existing NAT, it has been identified that the problem can be split
   into two clear solution areas as defined in section 2 of this
   document.  The traversal of the core protocol signaling and the
   traversal of the associated media as specified in the Session
   Description Payload (SDP) of a SIP offer/answer exchange[4].  The
   following sub-sections outline solutions that enable core SIP
   signaling and its associated media to traverse NATs.





Boulton & Rosenberg      Expires April 25, 2005                 [Page 6]


Internet-Draft               NAT Scenarios                  October 2004



3.1  SIP Signaling


   SIP signaling has two areas that result in transactional failure when
   traversing through NAT, as described in section 2 of this document.
   The remaining sub-sections describe appropriate solutions that result
   in SIP signalling traversal through NAT, regardless of transport
   protocol.  IT is RECOMMEDED that SIP compliant entities follow the
   guidelines presented in this section to enable traversal of SIP
   signaling through NATs.


3.1.1  Symmetric Response


   As described in section 2 of this document, when using an unreliable
   transport protocol such as UDP, SIP responses are sent to the IP
   address and port combination contained in the SIP 'Via' header field
   (or default port for the appropriate transport protocol if not
   present).  This can result in responses being blocked at a NAT.  In
   such circumstances, SIP signaling requires a mechanism that will
   allow entities to override the basic response generation mechanism in
   RFC 3261 [1].  Once the SIP response is constructed, the destination
   is still derived using the mechanisms described in RFC 3261 [1].  The
   port (to which the response will be sent), however, will not equal
   that specified in the SIP 'Via' header field but will be the port
   from which the original request was sent.  This results in the
   pin-hole opened for the requests traversal of the NAT being reused,
   in a similar manner to that of reliable connection orientated
   transport protocols such as TCP.  Figure 4 illustrates the response
   traversal through the open pin hole using this method.



    Private Network                   NAT                      Public Network
                                       |
                                       |
                                       |
     --------                          |                          --------
    |        |                         |                         |        |
    |        |send/receive             |             send/receive|        |
    | Client |port 5060-----<<->>-------------<<->>-----port 5060| Client |
    |   A    |                         |                         |   B    |
    |        |                         |                         |        |
     --------                          |                          --------
                                       |
                                       |
                                       |


      Figure 4


    The exact functionality for this method of response traversal is




Boulton & Rosenberg      Expires April 25, 2005                 [Page 7]


Internet-Draft               NAT Scenarios                  October 2004



   called 'Symmetric Response' and the details are documented in RFC
   3581 [5].  Additional requirements are imposed on SIP entities in
   this specification such as listening and sending SIP
   requests/responses from the same port.


3.1.2  Connection Re-use


   The second problem with sip signaling, as defined in Section 3.1.2,
   is to allow incoming requests to be properly routed.  This is
   addressed in [8], which allows the reuse of a TCP connection or UDP
   5-tuple for incoming requests.  That draft also provides keepalive
   mechanisms based on using STUN to the SIP server.  Usage of this
   specification is RECOMMENDED.  This mechanism is not transport
   specific and should be used for any transport protocol.


   Even if this draft is not used, clients SHOULD use the same IP
   address and port (i.e., socket) for both transmission and receipt of
   SIP messages.  Doing so allows for the vast majority of industry
   provided solutions to properly function.


3.2  Media Traversal


   This document has already provided guidelines that recommend using
   extensions to the core SIP protocol to enable traversal of NATs.
   While ultimately not desirable, the additions are relatively straight
   forward and provide a simple, universal solution for varying types of
   NAT deployment.  The issues of media traversal through NATs is not as
   straight forward and requires the combination of a number of
   traversal methodologies.  The technologies outlined in the remainder
   of this section provide the required solution set.


3.2.1  Symmetric RTP


   The primary problem identified in section 2 of this document is that
   internal IP address/port combinations can  not be reached from the
   public side of a NAT.  In the case of media such as RTP, this will
   result in no audio traversing a NAT(as illustrated in Figure 3).  To
   overcome this problem, a technique called 'Symmetric' RTP can be
   used.  This involves an SIP endpoint both sending and receiving RTP
   traffic from the same IP Address/Port combination.  This technique
   also requires intelligence by a client on the public internet as it
   identifies that incoming media for a particular session does not
   match the information that was conveyed in the SDP.  In  this case
   the client will ignore the SDP address/port combination and return
   RTP to the IP address/port combination identified as the source of
   the incoming media.  This technique is known as 'Symmetric RTP' and
   is documented in [11].  'Symmetric RTP' SHOULD only be used for
   traversal of RTP through NAT when one of the participants in a media




Boulton & Rosenberg      Expires April 25, 2005                 [Page 8]


Internet-Draft               NAT Scenarios                  October 2004



   session definitively knows that it is on the public network.


3.2.2  STUN


   Simple Traversal of User Datagram Protocol(UDP) through Network
   Address Translators(NAT) or STUN is defined in RFC 3489 [7].  It
   provides a lightweight protocol that allows entities to probe and
   discover the type of NAT that exist between itself and external
   entities.  It also provides details of the external IP address/port
   combination used by the NAT device to represent the internal entity
   on the public facing side of a NAT.  On learning of such an external
   representation, a client can use accordingly as the connection
   address in SDP to provide NAT traversal.  STUN only works with Full
   Cone, Restricted Cone and Port Restricted Cone type NATs.  STUN does
   not work with Symmetric NATs as the technique used to probe for the
   external IP address port representation using a STUN server will
   provide a different result to that required for traversal by an
   alternative SIP entity.  The IP address/port combination deduced for
   the STUN server would be blocked for  incoming packets from an
   alterative SIP entity.


3.2.3  TURN


   As mentioned in the previous section, the STUN protocol does not work
   for UDP traversal through a Symmetric style NAT.  Traversal Using
   Relay NAT (TURN) provides the solution for UDP traversal of symmetric
   NAT.  TURN is extremely similar to STUN in both syntax and operation.
   It provides an external address at a TURN server that will act as a
   relay and guarantee traffic will reach the associated internal
   address.  The full details of the TURN specification are defined in
   [10].  A TURN service will almost always provide media traffic to a
   SIP entity but it is RECOMMENDED that this method only be used as a
   last resort and not as a general mechanism for NAT traversal.  This
   is because using TURN has high performance costs when relaying media
   traffic.


3.2.4  ICE


   Interactive Connectivity Establishment (ICE) is the RECOMMENDED
   method for traversal of existing NAT if Symmetric RTP is not
   appropriate.  ICE is a methodology for using existing technologies
   such as STUN and TURN to provide a unified solution.  This is
   achieved by obtaining as many representative IP address/port
   combinations as possible using technologies such as STUN/TURN etc.
   Once the addresses are accumulated, they are all included in the SDP
   exchange in a new media attribute called 'alt'.  Each 'alt' entry has
   a preference which is represented in the 'alt' SDP attribute.  The
   appropriate IP address/port combinations are used in the correct




Boulton & Rosenberg      Expires April 25, 2005                 [Page 9]


Internet-Draft               NAT Scenarios                  October 2004



   order.  A failure results in the next address being used in the list
   of alternatives.  The full details of the ICE methodology are
   contained in [12].


3.2.5  RTCP Attribute


   Normal practice when selecting a port for defining Real Time Control
   Protocol(RTCP)[2] is for consecutive order numbering (i.e select an
   incremented port for RTCP from that used for RTP).  This assumption
   causes RTCP traffic to break when traversing many NATs due to blocked
   ports.  To combat this problem a specific address and port need to be
   specified in the SDP rather than relying on such assumptions.  RFC
   3605 [5] defines an SDP attribute that is included to explicitly
   specify transport connection information for RTCP.  The address
   details can be obtained using any appropriate method including those
   detailed previously in this section (e.g.  STUN, TURN).


3.2.6  Solution Profiles


   This draft has documented a number of technology solutions for the
   traversal of media through differing NAT deployments.  A number of
   'profiles' will now be defined that categorize varying levels of
   support for the technologies described.


3.2.6.1  Primary Profile


   A client falling into the 'Primary' profile supports ICE in
   conjunction with STUN, TURN and RFC 3605 [5] for RTCP.  ICE is used
   in all cases and falls back to standard operation when dealing with
   non-ICE clients.  A client which falls into the 'Primary' profile
   will be maximally interoperable and function in  a rich variety of
   environments including enterprise, consumer and behind all variety of
   NAT.


3.2.6.2  Consumer Profile


   A client falling into the 'Consumer' profile supports STUN and RFC
   3605 [5] for RTCP.  It uses STUN to allocate bindings, and can also
   detect when it is in the unfortunate situation of being behind a
   'Symmetric' NAT, although it simply cannot function in this case.
   These clients will only work in deployment situations where the
   access is sufficiently controlled to know definitively that there
   won't be Symmetric NAT.  This is hard to guarantee as users can
   always pick up their client and connect via a different access
   network.







Boulton & Rosenberg      Expires April 25, 2005                [Page 10]


Internet-Draft               NAT Scenarios                  October 2004



3.2.6.3  Minimal Profile


   A client falling into the 'Minimal' profile will send/receive RTP
   form the same IP/port combination.  This client requires proprietary
   network based solutions to  function in any NAT traversal scenario.


   All clients SHOULD support the 'Primary Profile', MUST support the
   'Minimal Profile' and MAY support the 'Consumer Profile'.


4.  NAT Traversal Scenarios


   This section of the document includes detailed NAT traversal
   scenarios for both SIP signaling and the associated media.


4.1  Basic NAT SIP Signaling Traversal


   The following sub-sections concentrate on SIP signaling traversal of
   NAT.  The scenarios include traversal for both reliable and
   un-reliable transport protocols.


   [Editors Note: The scenarios are still in early construction and a
   couple have been included as a hint of direction - All comments
   welcome for next release]


4.1.1  Registration (Registrar/Proxy Co-Located


   The set of scenarios in this section document basic signaling
   traversal of a SIP REGISTER method through a NAT.


4.1.1.1  UDP






















Boulton & Rosenberg      Expires April 25, 2005                [Page 11]


Internet-Draft               NAT Scenarios                  October 2004



           Client              NAT               Proxy
             |                  |                  |
             |(1) REGISTER      |                  |
             |----------------->|                  |
             |                  |(1) REGISTER      |
             |                  |----------------->|
             |                  |(2) 401 Unauth    |
             |                  |<-----------------|
             |(2) 401 Unauth    |                  |
             |<-----------------|                  |
             |(3) REGISTER      |                  |
             |----------------->|                  |
             |                  |(3) REGISTER      |
             |                  |----------------->|
             |*************************************|
             |    Create Connection Re-use Tuple   |
             |*************************************|
             |                  |(4) 200 OK        |
             |                  |<-----------------|
             |(4) 200 OK        |                  |
             |<-----------------|                  |
             |                  |                  |


     Figure 5.


   In this example the client sends a SIP REGISTER request through a NAT
   which is challenged using the Digest authentication scheme.  The
   client will include an 'rport' parameter as described in section
   3.1.1 of this document for allowing traversal of UDP responses.  The
   original request as illustrated in (1) in Figure 5 is a standard
   REGISTER message:


    REGISTER sip:proxy.example.com SIP/2.0
    Via: SIP/2.0/UDP client.example.com:5060;rport;branch=z9hG4bKyiubjakxbnmzx
    Max-Forwards: 70
    Supported: gruu
    From: Client <sip:client@example.com>;tag=djks8732
    To: Client <sip:client@example.com>
    Call-ID: 763hdc73y7dkb37@example.com
    CSeq: 1 REGISTER
    Contact: <sip:client@client.example.com>; connectioId=1
        ;+sip.instance="<urn:uuid:00000000-0000-0000-0000-000A95A0E120>"
    Content-Length: 0


   This proxy now generates a SIP 401 response to challenge for
   authentication, as depicted in (2) from Figure 5.:






Boulton & Rosenberg      Expires April 25, 2005                [Page 12]


Internet-Draft               NAT Scenarios                  October 2004



    SIP/2.0 401 Unauthorized
    Via: SIP/2.0/UDP client.example.com:5060;rport=8050;branch=z9hG4bKyiubjakxbnmzx;received=192.0.1.2
    From: Client <sip:client@example.com>;tag=djks8732
    To: Client <sip:client@example.com>;tag=876877
    Call-ID: 763hdc73y7dkb37@example.com
    CSeq: 1 REGISTER
    WWW-Authenticate: [not shown]
    Content-Length: 0


   The response will be sent to the address appearing in the 'received'
   parameter of the SIP 'Via' header (address 192.0.1.2).  The response
   will not be sent to the port deduced from the SIP 'Via' header, as
   per standard SIP operation but will be sent to the value that has
   been stamped in the 'rport' parameter of the SIP 'Via' header (port
   8050).  For the response to successfully traverse the NAT, all of the
   conventions defined in RFC 3581 [5] MUST be obeyed.  Make note of the
   both the 'connectionID' and 'sip.instance' contact header parameters.
   They are used to establish a connection re-use tuple as defined in
   [8].  The connection tuple creation is clearly shown in Figure 5.
   This ensures that any inbound request that causes a registration
   lookup will result in the re-use of the connection path established
   by the registration.  This exonerates the need to manipulate contact
   header URI's to represent a globally routable address as perceived on
   the public side of a NAT.  The subsequent messages defined in (3) and
   (4) from Figure 5 use the same mechanics for NAT traversal.


   [Editors note: Will provide more details on heartbeat mechanism in
   next revision]


   [Editors note: Can complete full flows if required on heartbeat
   inclusion]


4.1.1.2  Reliable Transport



















Boulton & Rosenberg      Expires April 25, 2005                [Page 13]


Internet-Draft               NAT Scenarios                  October 2004



           Client              NAT             Registrar
             |                  |                  |
             |(1) REGISTER      |                  |
             |----------------->|                  |
             |                  |(1) REGISTER      |
             |                  |----------------->|
             |                  |(2) 401 Unauth    |
             |                  |<-----------------|
             |(2) 401 Unauth    |                  |
             |<-----------------|                  |
             |(3) REGISTER      |                  |
             |----------------->|                  |
             |                  |(3) REGISTER      |
             |                  |----------------->|
             |*************************************|
             |    Create Connection Re-use Tuple   |
             |*************************************|
             |                  |(4) 200 OK        |
             |                  |<-----------------|
             |(4) 200 OK        |                  |
             |<-----------------|                  |
             |                  |                  |


     Figure 6.


   Traversal of SIP REGISTER messages request/responses using a
   reliable, connection orientated protocol such as TCP does not require
   any additional core SIP signaling extensions.  SIP responses will
   re-use the connection created for the initial REGISTER request, (1)
   from Figure 6:



    REGISTER sip:proxy.example.com SIP/2.0
    Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKyilassjdshfu
    Max-Forwards: 70
    Supported: gruu
    From: Client <sip:client@example.com>;tag=djks809834
    To: Client <sip:client@example.com>
    Call-ID: 763hdc783hcnam73@example.com
    CSeq: 1 REGISTER
    Contact: <sip:client@client.example.com;transport=tcp>; connectioId=1
        ;+sip.instance="<urn:uuid:00000000-0000-0000-0000-000A95A0E121>"
    Content-Length: 0


   This example was included to show the inclusion of the of the
   connection re-use Contact header parameters as defined in the
   Connection Re-use draft[8].  This creates an association tuple as
   described in the previous example for future inbound requests




Boulton & Rosenberg      Expires April 25, 2005                [Page 14]


Internet-Draft               NAT Scenarios                  October 2004



   directed at the  newly created registration binding with the only
   difference that the association is with a TCP connection, not a UDP
   pin hole binding.


   [Editors note: Will provide more details on heartbeat mechanism in
   next revision]


   [Editors note: Can complete full flows on inclusion of heartbeat
   mechanism]


4.1.2  Registration(Registrar/Proxy not Co-Located)


   This section demonstrates traversal mechanisms when the Registrar
   component is not co-located with the edge proxy element.  The
   procedures described in this section are identical, regardless of
   transport protocol and so only one example will be documented in the
   form of TCP.



     Client              NAT               Proxy            Registrar
       |                  |                  |                  |
       |(1) REGISTER      |                  |                  |
       |----------------->|                  |                  |
       |                  |(1) REGISTER      |                  |
       |                  |----------------->|                  |
       |                  |                  |(2) REGISTER      |
       |                  |                  |----------------->|
       |                  |                  |(3) 401 Unauth    |
       |                  |                  |<-----------------|
       |                  |(4) 401 Unauth    |                  |
       |                  |<-----------------|                  |
       |(4)401 Unauth     |                  |                  |
       |<-----------------|                  |                  |
       |(5)REGISTER       |                  |                  |
       |----------------->|                  |                  |
       |                  |(5)REGISTER       |                  |
       |                  |----------------->|                  |
       |                  |                  |(6)REGISTER       |
       |                  |                  |----------------->|
       |                  |                  |(7)200 OK         |
       |                  |                  |<-----------------|
       |********************************************************|
       |             Create Connection Re-use Tuple             |
       |********************************************************|
       |                  |(8)200 OK         |                  |
       |                  |<-----------------|                  |
       |(8)200 OK         |                  |                  |
       |<-----------------|                  |                  |




Boulton & Rosenberg      Expires April 25, 2005                [Page 15]


Internet-Draft               NAT Scenarios                  October 2004



       |                  |                  |                  |


     Figure 7.


   This scenario builds on that contained in section 4.1.1.2.  This time
   the REGISTER request is routed onwards to a separated Registrar.  The
   important message to note is (5) in Figure 7.  At this point, the
   proy server routes the SIP REGISTER message to the Registrar.  The
   proxy will create the connection re-use tuple at the same moment as
   the co-located example but for subsequent messages to arrive at the
   Proxy, the element needs to request to stay in the signaling path.
   REGISTER message (5) contains a SIP PATH extension header, as defined
   in RFC 3327 [6].  REGISTER message (5) would look as follows:



    REGISTER sip:registrar.example.com SIP/2.0
    Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4njkca8398hadjaa
    Via: SIP/2.0/TCP client.example.com:5060;branch=z9hG4bKyilassjdshfu
    Max-Forwards: 70
    Supported: gruu
    From: Client <sip:client@example.com>;tag=djks809834
    To: Client <sip:client@example.com>
    Call-ID: 763hdc783hcnam73@example.com
    CSeq: 1 REGISTER
    Path: <sip:sip%3Aclient%40example.com@proxy.example.com;lr>
    Contact: <sip:client@client.example.com;transport=tcp>; connectioId=1
        ;+sip.instance="<urn:uuid:00000000-0000-0000-0000-000A95A0E121>"
    Content-Length: 0



   This results in the path header being stored along with the AOR and
   it's associated binding at the Registrar.  The URI contained in the
   PATH will be inserted as a pre-loaded SIP 'Route' header into any
   request that arrives at the Registrar and is directed towards the
   associated binding.  This guarantees that all requests for the new
   Registration will be forwarded to the edge proxy.  The user part of
   the SIP 'Path' header URI that was inserted by the edge proxy
   contains an escaped form of the original AOR that was contained in
   the REGISTER request.  On receiving subsequent requests, the edge
   proxy will examine the user part of the pre-loaded SIP 'route' header
   and extract the original AOR for use in it's connection tuple
   comparison, as defined in the connection re-use draft[8].  An
   example which will build on this scenario (showing an inbound request
   to the AOR) is detailed in section 4.1.4.2 of this document.


4.1.3  Initiating a Session


   This section covers basic SIP signaling when initiating a call from




Boulton & Rosenberg      Expires April 25, 2005                [Page 16]


Internet-Draft               NAT Scenarios                  October 2004



   behind a NAT.


4.1.3.1  UDP


   Initiating a call using UDP.




      Client              NAT               Proxy              [..]
        |                  |                  |
        |(1) INVITE        |                  |                 |
        |----------------->|                  |                 |
        |                  |(1) INVITE        |                 |
        |                  |----------------->|                 |
        |                  |(2) 407 Unauth    |                 |
        |                  |<-----------------|                 |
        |(2) 407 Unauth    |                  |                 |
        |<-----------------|                  |                 |
        |(3) INVITE        |                  |                 |
        |                  |(3) INVITE        |                 |
        |                  |----------------->|                 |
        |                  |                  |(4) INVITE       |
        |                  |                  |---------------->|
        |                  |                  |(5)180 RINGING   |
        |                  |                  |<----------------|
        |                  |(6)180 RINGING    |                 |
        |                  |<-----------------|                 |
        |(6)180 RINGING    |                  |                 |
        |<-----------------|                  |                 |
        |                  |                  |(7)200 OK        |
        |                  |                  |<----------------|
        |                  |(8)200 OK         |                 |
        |                  |<-----------------|                 |
        |(8)200 OK         |                  |                 |
        |<-----------------|                  |                 |
        |(9)ACK            |                  |                 |
        |----------------->|                  |                 |
        |                  |(9)ACK            |                 |
        |                  |----------------->|                 |
        |                  |                  |(10) ACK         |
        |                  |                  |---------------->|
        |                  |                  |(11)             |


     Figure 8.


   The initiating client generates an INVITE request that is to be sent
   through the NAT to a Proxy server.  The INVITE message is represented
   in Figure 8 by (1) and is as follows:




Boulton & Rosenberg      Expires April 25, 2005                [Page 17]


Internet-Draft               NAT Scenarios                  October 2004



   INVITE sip:clientB@example.com SIP/2.0
   Via: SIP/2.0/UDP client.example.com:5060;rport;branch=z9hG4bK74husdHG
   Max-Forwards: 70
   Route: <sip:proxy.example.com;lr>
   From: clientA <sip:clientA@example.com>;tag=7skjdf38l
   To: clientB <sip:clientB@example.com>
   Call-ID: 8327468763423@example.com
   CSeq: 1 INVITE
   Contact: <sip:im_a_gruu@proxy.example.com>
   Content-Type: application/sdp
   Content-Length: ..


   [SDP not shown]


   There are a number of points to note with this message:
   1.  Firstly, as with the registration example in section 4.1.1.1,
       reponses to this request will not automatically pass back through
       a NAT and so the SIP 'Via' header 'rport' is included as
       described in the 'Symmetric response' section(3.1.1) and defined
       in RFC 3581 [5].
   2.  Secondly, the contact inserted contains the GRUU previously
       obtained from the registration.
   3.  [Editors Note: TODO - Expand description of GRUU and connection
       re-use]


4.1.3.2  Reliable Transport


   [Editors note: TODO]


4.1.4  Receiving an Invitation to a Session


   This section details sceanrios where a client behind a NAT receives
   an inbound request through the NAT.  These scenarios build on the
   previous registration sceanrio from sections 4.1.1 and 4.1.2 in this
   document.


4.1.4.1  Registrar/Proxy Co-located


   The core SIP signaling associated with this call flow is not impacted
   directly by the transport protocol and so only one example scenario
   is necessary.  The example uses UDP and follows on from the
   registration installed in the example from section 4.1.1.1.










Boulton & Rosenberg      Expires April 25, 2005                [Page 18]


Internet-Draft               NAT Scenarios                  October 2004



       Client              NAT         Registrar/Proxy       SIP Entity
         |                  |                  |                 |
         |*******************************************************|
         |           Registration Binding Installed in           |
         |                    section 4.1.1.1                    |
         |*******************************************************|
         |                  |                  |                 |
         |                  |                  |(1)INVITE        |
         |                  |                  |<----------------|
         |                  |(2)INVITE         |                 |
         |                  |<-----------------|                 |
         |(2)INVITE         |                  |                 |
         |<-----------------|                  |                 |
         |                  |                  |                 |
         |                  |                  |                 |



     Figure 9.


   The core SIP signaling associated with this call flow is not impacted
   directly by the transport protocol and so only one example scenario
   is necessary.  The example uses UDP and follows on from the
   registration installed in section 4.1.1.1.  An INVITE request arrives
   at the Registrar with a destination pointing to the AOR of that
   inserted in section 4.1.1.1.  The message is illustrated by (1) in
   Figure 9 and looks as follows:



   INVITE sip:client@example.com SIP/2.0
   Via: SIP/2.0/UDP external.example.com;branch=z9hG4bK74huHJ37d
   Max-Forwards: 70
   From: External <sip:External@external.example.com>;tag=7893hd
   To: client <sip:client@example.com>
   Call-ID: 8793478934897@external.example.com
   CSeq: 1 INVITE
   Contact: <sip:external@192.0.1.4>
   Content-Type: application/sdp
   Content-Length: ..


   [SDP not shown]


   The INVITE matches the registration binding at the Registrar and the
   INVITE request-URI is re-written to the selcted onward address.  The
   proxy then examines the request URI of the INVITE and compares with
   it's list of current open connections/mappings.  It uses the incoming
   AOR to commence the check for associated open connections/mappings.
   Once matched, the proxy checks to see if the unique instance
   identifier (+sip.instance)associated with the binding equals the same




Boulton & Rosenberg      Expires April 25, 2005                [Page 19]


Internet-Draft               NAT Scenarios                  October 2004



   instance identifier associated with the binding.  If more than one
   results are matched, the lowest 'connectionID' Contact parameter will
   be used.  This is message (2) from Figure 9 and is as follows:



   INVITE sip:sip:client@client.example.com SIP/2.0
   Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4kmlds893jhsd
   Via: SIP/2.0/UDP external.example.com;branch=z9hG4bK74huHJ37d
   Max-Forwards: 70
   From: External <sip:External@external.example.com>;tag=7893hd
   To: client <sip:client@example.com>
   Call-ID: 8793478934897@external.example.com
   CSeq: 1 INVITE
   Contact: <sip:external@192.0.1.4>
   Content-Type: application/sdp
   Content-Length: ..


   [SDP not shown]


   It is a standard SIP INVITE request with no additional functionality.
   The major difference being that this request will not follow the
   address specified in the Request-URI, as standard SIP rules would
   enforce but will be sent on the connection/mapping associated with
   the registration binding.  This then allows the original
   connection/mapping from the initial registration process to be
   re-used.


4.1.4.2  Registrar/Proxy Not Co-located




   Client          NAT    Proxy      Registrar       SIP Entity
     |              |              |              |              |
     |***********************************************************|
     |            Registrtion Binding Installed in               |
     |                      section 4.1.2                        |
     |***********************************************************|
     |              |              |              |(1)INVITE     |
     |              |              |              |<-------------|
     |              |              |(2)INVITE     |              |
     |              |              |<-------------|              |
     |              |(3)INVITE     |              |              |
     |              |<-------------|              |              |
     |(3)INVITE     |              |              |              |
     |<-------------|              |              |              |
     |              |              |              |              |
     |              |              |              |              |





Boulton & Rosenberg      Expires April 25, 2005                [Page 20]


Internet-Draft               NAT Scenarios                  October 2004



     Figure 9.



4.2  Basic NAT Media Traversal


4.2.1  Full Cone NAT


4.2.1.1  STUN Solution


4.2.1.1.1  Initiating Session


4.2.1.1.2  Receiving Session Invitation


4.2.1.2  ICE Solution


4.2.1.2.1  Initiating Session


4.2.1.2.2  Receiving Session Invitation


4.2.2  Port Restricted Cone NAT


4.2.2.1  STUN Solution


4.2.2.1.1  Initiating Session


4.2.2.1.2  Receiving Session Invitation


4.2.2.2  ICE Solution


4.2.2.2.1  Initiating Session


4.2.2.2.2  Receiving Session Invitation


4.2.3  Symmetric NAT


4.2.3.1  STUN Failure


4.2.3.1.1  Initiating Session


4.2.3.1.2  Receiving Session Invitation


4.2.3.2  TURN Solution


4.2.3.2.1  Initiating Session


4.2.3.2.2  Receiving Session Invitation






Boulton & Rosenberg      Expires April 25, 2005                [Page 21]


Internet-Draft               NAT Scenarios                  October 2004



4.2.3.3  ICE Solution


4.2.3.3.1  Initiating Session


4.2.3.3.2  Receiving Session Invitation


4.3  Advanced NAT media Traversal Using ICE


4.3.1  Full Cone --> Full Cone traversal


4.3.1.1  Without NAT


4.3.1.1.1  Initiating Session


4.3.1.1.2  Receiving Session Invitation


4.3.1.2  With NAT


4.3.1.2.1  Initiating Session


4.3.1.2.2  Receiving Session Invitation


4.3.2  Port Restricted Cone --> Port Restricted Cone traversal


4.3.2.1  Without NAT


4.3.2.1.1  Initiating Session


4.3.2.1.2  Receiving Session Invitation


4.3.2.2  With NAT


4.3.2.2.1  Initiating Session


4.3.2.2.2  Receiving Session Invitation


4.3.3  Internal TURN Server (Enterprise Deployment)


4.3.3.1  Peer in same Enterprise


4.3.3.2  Peer in same Enterprise - Separated by NAT


4.3.3.3  Peer outside Enterprise


4.4  Intercepting Intermediary (B2BUA)







Boulton & Rosenberg      Expires April 25, 2005                [Page 22]


Internet-Draft               NAT Scenarios                  October 2004



4.5  IPV4/IPV6


5.  References


5.1  Normative References


   [1]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.


   [2]   Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
         "RTP: A Transport Protocol for Real-Time Applications", RFC
         1889, January 1996.


   [3]   Handley, M. and V. Jacobson, "SDP: Session Description
         Protocol", RFC 2327, April 1998.


   [4]   Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
         Session Description Protocol (SDP)", RFC 3264, June 2002.


   [5]   Rosenberg, J. and H. Schulzrinne, "An Extension to the Session
         Initiation Protocol (SIP) for Symmetric Response Routing", RFC
         3581, August 2003.


   [6]   Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
         Extension Header Field for Registering Non-Adjacent Contacts",
         RFC 3327, December 2002.


   [7]   Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN -
         Simple Traversal of User Datagram Protocol (UDP) Through
         Network Address Translators (NATs)", RFC 3489, March 2003.


   [8]   Jennings, C. and A. Hawrylyshen, "SIP Conventions for
         Connection Usage", draft-jennings-sipping-outbound-00 (work in
         progress), October 2004.


   [9]   Rosenberg, J., "Obtaining and Using Globally Routable User
         Agent (UA) URIs (GRUU) in the  Session Initiation Protocol
         (SIP)", draft-ietf-sip-gruu-02 (work in progress), July 2004.


   [10]  Rosenberg, J., "Traversal Using Relay NAT (TURN)",
         draft-rosenberg-midcom-turn-05 (work in progress), July 2004.


   [11]  Wing, D., "Symmetric RTP and RTCP Considered Helpful",
         draft-wing-mmusic-symmetric-rtprtcp-01 (work in progress),
         October 2004.


   [12]  Rosenberg, J., "Interactive Connectivity Establishment (ICE): A




Boulton & Rosenberg      Expires April 25, 2005                [Page 23]


Internet-Draft               NAT Scenarios                  October 2004



         Methodology for Network  Address Translator (NAT) Traversal for
         Multimedia Session Establishment Protocols",
         draft-ietf-mmusic-ice-02 (work in progress), July 2004.


   [13]  Rosenberg, J., "Simple Traversal of UDP Through Network Address
         Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-00
         (work in progress), October 2004.


5.2  Informative References



Authors' Addresses


   Chris Boulton
   Ubiquity Software
   Langstone Park
   Newport, South Wales  NP18 2LH


   EMail: cboulton@ubiquitysoftware.com



   Jonathan Rosenberg
   Cisco Systems
   600 Lanidex Plaza
   Parsippany, NJ  07054


   EMail: jdrosen@dynamicsoft.com

























Boulton & Rosenberg      Expires April 25, 2005                [Page 24]


Internet-Draft               NAT Scenarios                  October 2004



Intellectual Property Statement


   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.


   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.


   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.



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 (2004).  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


   Funding for the RFC Editor function is currently provided by the
   Internet Society.





Boulton & Rosenberg      Expires April 25, 2005                [Page 25]