Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6314

NAT Traversal Practices for Client-Server SIP

Pages: 60
Informational
Part 2 of 4 – Pages 12 to 26
First   Prev   Next

Top   ToC   RFC6314 - Page 12   prevText

5. NAT Traversal Scenarios

This section of the document includes detailed NAT traversal scenarios for both SIP signaling and the associated media. Signaling NAT traversal is achieved using [RFC5626].

5.1. Basic NAT SIP Signaling Traversal

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

5.1.1. Registration (Registrar/Edge Proxy Co-Located)

The set of scenarios in this section document basic signaling traversal of a SIP REGISTER method through NATs.
Top   ToC   RFC6314 - Page 13
5.1.1.1. UDP
Registrar/ Bob NAT Edge Proxy | | | |(1) REGISTER | | |----------------->| | | | | | |(1) REGISTER | | |----------------->| | | | |*************************************| | Create Outbound Connection Tuple | |*************************************| | | | | |(2) 200 OK | | |<-----------------| | | | |(2) 200 OK | | |<-----------------| | | | | Figure 5: UDP Registration In this example, the client sends a SIP REGISTER request through a NAT. The client will include an 'rport' parameter as described in Section 4.1.1 of this document for allowing traversal of UDP responses. The original request as illustrated in (1) in Figure 5 is a standard SIP REGISTER message: Message 1: REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP 192.168.1.2;rport;branch=z9hG4bKnashds7 Max-Forwards: 70 From: Bob <sip:bob@example.com>;tag=7F94778B653B To: Bob <sip:bob@example.com> Call-ID: 16CB75F21C70 CSeq: 1 REGISTER Supported: path, outbound Contact: <sip:bob@192.168.1.2 >;reg-id=1 ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>" Content-Length: 0
Top   ToC   RFC6314 - Page 14
   This SIP transaction now generates a SIP 200 OK response, as depicted
   in (2) from Figure 5:

   Message 2:

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP 192.168.1.2;rport=8050;branch=z9hG4bKnashds7;
        received=172.16.3.4
   From: Bob <sip:bob@example.com>;tag=7F94778B653B
   To: Bob <sip:bob@example.com>;tag=6AF99445E44A
   Call-ID: 16CB75F21C70
   CSeq: 1 REGISTER
   Supported: path, outbound
   Require: outbound
   Contact: <sip:bob@192.168.1.2 >;reg-id=1;expires=3600
        ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
   Content-Length: 0

   The response will be sent to the address appearing in the 'received'
   parameter of the SIP 'Via' header (address 172.16.3.4).  The response
   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 [RFC3581] are to be obeyed.  Make
   note of both the 'reg-id' and 'sip.instance' contact header
   parameters.  They are used to establish an outbound connection tuple
   as defined in [RFC5626].  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 reuse of the connection path
   established by the registration.  This removes the need to manipulate
   contact header URIs to represent a globally routable address as
   perceived on the public side of a NAT.
Top   ToC   RFC6314 - Page 15
5.1.1.2. Connection-Oriented Transport
Registrar/ Bob NAT Edge Proxy | | | |(1) REGISTER | | |----------------->| | | | | | |(1) REGISTER | | |----------------->| | | | |*************************************| | Create Outbound Connection Tuple | |*************************************| | | | | |(2) 200 OK | | |<-----------------| | | | |(2) 200 OK | | |<-----------------| | | | | Figure 6 Traversal of SIP REGISTER requests/responses using a reliable, connection-oriented protocol such as TCP does not require any additional core SIP signaling extensions, beyond the procedures defined in [RFC5626]. SIP responses will reuse the connection created for the initial REGISTER request, (1) from Figure 6: Message 1: REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7 Max-Forwards: 70 From: Bob <sip:bob@example.com>;tag=7F94778B653B To: Bob <sip:bob@example.com> Call-ID: 16CB75F21C70 CSeq: 1 REGISTER Supported: path, outbound Contact: <sip:bob@192.168.1.2;transport=tcp>;reg-id=1 ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>" Content-Length: 0
Top   ToC   RFC6314 - Page 16
   Message 2:

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7
   From: Bob <sip:bob@example.com>;tag=7F94778B653B
   To: Bob <sip:bob@example.com>;tag=6AF99445E44A
   Call-ID: 16CB75F21C70
   CSeq: 1 REGISTER
   Supported: path, outbound
   Require: outbound
   Contact: <sip:bob@192.168.1.2;transport=tcp>;reg-id=1;expires=3600
        ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
   Content-Length: 0

   This example was included to show the inclusion of the 'sip.instance'
   contact header parameter as defined in the SIP Outbound specification
   [RFC5626].  This creates an association tuple as described in the
   previous example for future inbound requests directed at the newly
   created registration binding with the only difference that the
   association is with a TCP connection, not a UDP pinhole binding.

5.1.2. Registration(Registrar/Edge 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, so only one example will be documented in the form of TCP.
Top   ToC   RFC6314 - Page 17
      Bob               NAT              Edge Proxy         Registrar
       |                  |                  |                  |
       |(1) REGISTER      |                  |                  |
       |----------------->|                  |                  |
       |                  |                  |                  |
       |                  |(1) REGISTER      |                  |
       |                  |----------------->|                  |
       |                  |                  |                  |
       |                  |                  |(2) REGISTER      |
       |                  |                  |----------------->|
       |                  |                  |                  |
       |*************************************|                  |
       |  Create Outbound Connection Tuple   |                  |
       |*************************************|                  |
       |                  |                  |                  |
       |                  |                  |(3) 200 OK        |
       |                  |                  |<-----------------|
       |                  |(4)200 OK         |                  |
       |                  |<-----------------|                  |
       |                  |                  |                  |
       |(4)200 OK         |                  |                  |
       |<-----------------|                  |                  |
       |                  |                  |                  |

          Figure 7: Registration (Registrar/Proxy Not Co-Located)

   This scenario builds on the previous example in Section 5.1.1.2.  The
   primary difference is that the REGISTER request is routed onwards
   from a proxy server to a separated Registrar.  The important message
   to note is (1) in Figure 7.  The edge proxy, on receiving a REGISTER
   request that contains a 'sip.instance' media feature tag, forms a
   unique flow identifier token as discussed in [RFC5626].  At this
   point, the proxy server routes the SIP REGISTER message to the
   Registrar.  The proxy will create the connection tuple as described
   in SIP Outbound at the same moment as the co-located example, but for
   subsequent messages to arrive at the proxy, the proxy needs to
   indicate its need to remain in the SIP signaling path.  To achieve
   this, the proxy inserts to REGISTER message (2) a SIP 'Path'
   extension header, as defined in RFC 3327 [RFC3327].  The previously
   created flow association token is inserted in a position within the
   Path header where it can easily be retrieved at a later point when
   receiving messages to be routed to the registration binding (in this
   case the user part of the SIP URI).  The REGISTER message of (1)
   includes a SIP 'Route' header for the edge proxy.
Top   ToC   RFC6314 - Page 18
   Message 1:

   REGISTER sip:example.com SIP/2.0
   Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7
   Max-Forwards: 70
   From: Bob <sip:bob@example.com>;tag=7F94778B653B
   To: Bob <sip:bob@example.com>
   Call-ID: 16CB75F21C70
   CSeq: 1 REGISTER
   Supported: path, outbound
   Route: <sip:ep1.example.com;lr>
   Contact: <sip:bob@192.168.1.2;transport=tcp>;reg-id=1
        ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
   Content-Length: 0

   When proxied in (2) looks as follows:

   Message 2:

   REGISTER sip:example.com SIP/2.0
   Via: SIP/2.0/TCP ep1.example.com;branch=z9hG4bKnuiqisi
   Via: SIP/2.0/TCP 192.168.1.2;branch=z9hG4bKnashds7
   Max-Forwards: 69
   From: Bob <sip:bob@example.com>;tag=7F94778B653B
   To: Bob <sip:bob@example.com>
   Call-ID: 16CB75F21C70
   CSeq: 1 REGISTER
   Supported: path, outbound
   Contact: <sip:bob@192.168.1.2;transport=tcp>;reg-id=1
        ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
   Path: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr;ob>
   Content-Length: 0

   This REGISTER request results in the Path header being stored along
   with the AOR and its associated binding at the Registrar.  The URI
   contained in the Path header will be inserted as a pre-loaded SIP
   'Route' header into any request that arrives at the Registrar and is
   directed towards the associated AOR binding.  This all but guarantees
   that all requests for the new registration will be forwarded to the
   edge proxy.  In our example, the user part of the SIP 'Path' header
   URI that was inserted by the edge proxy contains the unique token
   identifying the flow to the client.  On receiving subsequent
   requests, the edge proxy will examine the user part of the pre-loaded
   SIP 'Route' header and extract the unique flow token for use in its
   connection tuple comparison, as defined in the SIP Outbound
   specification [RFC5626].  An example that builds on this scenario
   (showing an inbound request to the AOR) is detailed in
   Section 5.1.4.2 of this document.
Top   ToC   RFC6314 - Page 19

5.1.3. Initiating a Session

This section covers basic SIP signaling when initiating a call from behind a NAT.
5.1.3.1. UDP
Initiating a call using UDP (the edge proxy and authoritative proxy functionality are co-located).
Top   ToC   RFC6314 - Page 20
                                          Edge Proxy/
       Bob                NAT            Auth. Proxy          Alice
        |                  |                  |                 |
        |(1) INVITE        |                  |                 |
        |----------------->|                  |                 |
        |                  |                  |                 |
        |                  |(1) INVITE        |                 |
        |                  |----------------->|                 |
        |                  |                  |                 |
        |                  |                  |(2) INVITE       |
        |                  |                  |---------------->|
        |                  |                  |                 |
        |                  |                  |(3)180 RINGING   |
        |                  |                  |<----------------|
        |                  |                  |                 |
        |                  |(4)180 RINGING    |                 |
        |                  |<-----------------|                 |
        |                  |                  |                 |
        |(4)180 RINGING    |                  |                 |
        |<-----------------|                  |                 |
        |                  |                  |                 |
        |                  |                  |(5)200 OK        |
        |                  |                  |<----------------|
        |                  |                  |                 |
        |                  |(6)200 OK         |                 |
        |                  |<-----------------|                 |
        |                  |                  |                 |
        |(6)200 OK         |                  |                 |
        |<-----------------|                  |                 |
        |                  |                  |                 |
        |(7)ACK            |                  |                 |
        |----------------->|                  |                 |
        |                  |                  |                 |
        |                  |(7)ACK            |                 |
        |                  |----------------->|                 |
        |                  |                  |                 |
        |                  |                  |(8) ACK          |
        |                  |                  |---------------->|
        |                  |                  |                 |

                   Figure 8: Initiating a Session - UDP
Top   ToC   RFC6314 - Page 21
   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:

   Message 1:

   INVITE sip:alice@a.example SIP/2.0
   Via: SIP/2.0/UDP 192.168.1.2;rport;branch=z9hG4bKnashds7
   Max-Forwards: 70
   From: Bob <sip:bob@example.com>;tag=ldw22z
   To: Alice <sip:alice@a.example>
   Call-ID: 95KGsk2V/Eis9LcpBYy3
   CSeq: 1 INVITE
   Supported: outbound
   Route: <sip:ep1.example.com;lr>
   Contact: <sip:bob@192.168.1.2;ob>
   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 5.1.1.1,
       responses to this request will not automatically pass back
       through a NAT, so the SIP 'Via' header 'rport' is included as
       described in the Section 4.1.1 ("Symmetric Response") and defined
       in RFC 3581 [RFC3581].

   2.  Secondly, the 'ob' parameter is added to the 'Contact' header to
       ensure that all subsequent requests are sent to the same flow;
       alternatively, a Globally Routable User Agent URI (GRUU) might
       have been used.  See Section 4.3 of [RFC5626].

   In (2), the proxy inserts itself in the 'Via' header, adds the
   'rport' port number and the 'received' parameter in the previous
   'Via' header, removes the 'Route' header, and inserts a Record-Route
   with a token.
Top   ToC   RFC6314 - Page 22
   Message 2:

 INVITE sip:alice@172.16.1.4 SIP/2.0
 Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4bKnuiqisi
 Via: SIP/2.0/UDP 192.168.1.2;rport=8050;branch=z9hG4bKnashds7;
      received=172.16.3.4
 Max-Forwards: 69
 From: Bob <sip:bob@example.com>;tag=ldw22z
 To: Alice <sip:alice@a.example>
 Call-ID: 95KGsk2V/Eis9LcpBYy3
 CSeq: 1 INVITE
 Supported: outbound
 Record-Route: <sip:3yJEbr1GYZK9cPYk5Snocez6DzO7w+AX@ep1.example.com;lr>
 Contact: <sip:bob@192.168.1.2;ob>
 Content-Type: application/sdp
 Content-Length: ...

 [SDP not shown]

5.1.3.2. Connection-Oriented Transport
When using a reliable transport such as TCP, the call flow and procedures for traversing a NAT are almost identical to those described in Section 5.1.3.1. The primary difference when using reliable transport protocols is that symmetric response [RFC3581] is not required for SIP responses to traverse a NAT. RFC 3261 [RFC3261] defines procedures for SIP response messages to be sent back on the same connection on which the request arrived. See Section 9.5 of [RFC5626] for an example flow of an outgoing call.

5.1.4. Receiving an Invitation to a Session

This section details scenarios where a client behind a NAT receives an inbound request through a NAT. These scenarios build on the previous registration scenario from Sections 5.1.1 and 5.1.2 in this document.
5.1.4.1. Registrar/Proxy Co-Located
The SIP signaling on the interior of the network (behind the user's proxy) is not impacted directly by the transport protocol, so only one example scenario is necessary. The example uses UDP and follows on from the registration installed in the example from Section 5.1.1.1.
Top   ToC   RFC6314 - Page 23
                                           Edge Proxy
        Bob                NAT            Auth. Proxy          Alice
         |                  |                  |                 |
         |*******************************************************|
         |           Registration Binding Installed in           |
         |                    Section 5.1.1.1                    |
         |*******************************************************|
         |                  |                  |                 |
         |                  |                  |(1)INVITE        |
         |                  |                  |<----------------|
         |                  |                  |                 |
         |                  |(2)INVITE         |                 |
         |                  |<-----------------|                 |
         |                  |                  |                 |
         |(2)INVITE         |                  |                 |
         |<-----------------|                  |                 |
         |                  |                  |                 |
         |                  |                  |                 |

              Figure 9: Receiving an Invitation to a Session

   An INVITE request arrives at the authoritative proxy with a
   destination pointing to the AOR of that inserted in Section 5.1.1.1.
   The message is illustrated by (1) in Figure 9 and looks as follows:

   INVITE sip:bob@example.com SIP/2.0
   Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d
   Max-Forwards: 70
   From: External Alice <sip:alice@example.com>;tag=02935
   To: Bob <sip:bob@example.com>
   Call-ID: klmvCxVWGp6MxJp2T2mb
   CSeq: 1 INVITE
   Contact: <sip:alice@172.16.1.4>
   Content-Type: application/sdp
   Content-Length: ..

   [SDP not shown]

   The INVITE request matches the registration binding previously
   installed at the Registrar and the INVITE Request-URI is rewritten to
   the selected onward address.  The proxy then examines the Request-URI
   of the INVITE and compares with its list of connection tuples.  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 instance identifier associated with that
   connection tuple.  The request is then dispatched on the appropriate
   binding.  This is message (2) from Figure 9 and is as follows:
Top   ToC   RFC6314 - Page 24
   INVITE sip:bob@192.168.1.2 SIP/2.0
   Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4kmlds893jhsd
   Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d
   Max-Forwards: 69
   From: Alice <sip:alice@example.com>;tag=02935
   To: client bob <sip:bob@example.com>
   Call-ID: klmvCxVWGp6MxJp2T2mb
   CSeq: 1 INVITE
   Contact: <sip:alice@172.16.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 is that this request will not be forwarded to
   the address specified in the Request-URI, as standard SIP rules would
   enforce, but will be sent on the flow associated with the
   registration binding (lookup procedures in RFC 3263 [RFC3263] are
   overridden by RFC 5626 [RFC5626]).  This then allows the original
   connection/mapping from the initial registration process to be
   reused.

5.1.4.2. Edge Proxy/Authoritative Proxy Not Co-Located
The core SIP signaling associated with this call flow is not impacted directly by the transport protocol, so only one example scenario is necessary. The example uses UDP and follows on from the registration installed in the example from Section 5.1.2.
Top   ToC   RFC6314 - Page 25
    Bob            NAT         Edge Proxy    Auth. Proxy       Alice
     |              |              |              |              |
     |***********************************************************|
     |            Registration Binding Installed in              |
     |                      Section 5.1.2                        |
     |***********************************************************|
     |              |              |              |              |
     |              |              |              |(1)INVITE     |
     |              |              |              |<-------------|
     |              |              |              |              |
     |              |              |(2)INVITE     |              |
     |              |              |<-------------|              |
     |              |              |              |              |
     |              |(3)INVITE     |              |              |
     |              |<-------------|              |              |
     |              |              |              |              |
     |(3)INVITE     |              |              |              |
     |<-------------|              |              |              |
     |              |              |              |              |
     |              |              |              |              |

                 Figure 10: Registrar/Proxy Not Co-located

   An INVITE request arrives at the authoritative proxy with a
   destination pointing to the AOR of that inserted in Section 5.1.2.
   The message is illustrated by (1) in Figure 10 and looks as follows:

   INVITE sip:bob@example.com SIP/2.0
   Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d
   Max-Forwards: 70
   From: Alice <sip:alice@example.com>;tag=02935
   To: Bob <sip:bob@example.com>
   Call-ID: klmvCxVWGp6MxJp2T2mb
   CSeq: 1 INVITE
   Contact: <sip:external@172.16.1.4>
   Content-Type: application/sdp
   Content-Length: ..

   [SDP not shown]

   The INVITE request matches the registration binding previously
   installed at the Registrar and the INVITE Request-URI is rewritten to
   the selected onward address.  The Registrar also identifies that a
   SIP 'Path' header was associated with the registration and pushes it
   into the INVITE request in the form of a pre-loaded SIP Route header.
   It then forwards the request on to the proxy identified in the SIP
   Route header as shown in (2) from Figure 10:
Top   ToC   RFC6314 - Page 26
   INVITE sip:bob@client.example.com SIP/2.0
   Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK74fmljnc
   Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d
   Route: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr;ob>
   Max-Forwards: 69
   From: Alice <sip:alice@example.net>;tag=02935
   To: Bob <sip:Bob@example.com>
   Call-ID: klmvCxVWGp6MxJp2T2mb
   CSeq: 1 INVITE
   Contact: <sip:alice@172.16.1.4>
   Content-Type: application/sdp
   Content-Length: ..

   [SDP not shown]

   The request then arrives at the outbound proxy for the client.  The
   proxy examines the Request-URI of the INVITE in conjunction with the
   flow token that it previously inserted into the user part of the
   'Path' header SIP URI (which now appears in the user part of the
   Route header in the incoming INVITE).  The proxy locates the
   appropriate flow and sends the message to the client, as shown in (3)
   from Figure 10:

 INVITE sip:bob@192.168.1.2 SIP/2.0
 Via: SIP/2.0/UDP ep1.example.com;branch=z9hG4nsi30dncmnl
 Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bK74fmljnc
 Via: SIP/2.0/UDP 172.16.1.4;branch=z9hG4bK74huHJ37d
 Record-Route: <sip:VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@ep1.example.com;lr>
 Max-Forwards: 68
 From: Alice <sip:Alice@example.net>;tag=02935
 To: bob <sip:bob@example.com>
 Call-ID: klmvCxVWGp6MxJp2T2mb
 CSeq: 1 INVITE
 Contact: <sip:alice@172.16.1.4>
 Content-Type: application/sdp
 Content-Length: ..

 [SDP not shown]

   It is a standard SIP INVITE request with no additional functionality
   at the originator.  The major difference is that this request will
   not follow the address specified in the Request-URI when it reaches
   the outbound proxy, as standard SIP rules would enforce, but will be
   sent on the flow associated with the registration binding as
   indicated in the Route header (lookup procedures in RFC 3263
   [RFC3263] are overridden).  This then allows the original connection/
   mapping from the initial registration to the outbound proxy to be
   reused.


(next page on part 3)

Next Section