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.

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.

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.

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

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.

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.

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.

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.