5.2.2. Address/Port-Dependent NAT
184.108.40.206. STUN Failure
This section highlights that although using STUN techniques is the
preferred mechanism for traversal of NAT, it does not solve every
case. The use of basic STUN on its own will not guarantee traversal
through every NAT type, hence the recommendation that ICE is the
The example in Figure 18 is conveyed in the context of a client
behind the Address/Port-Dependent NAT initiating a call. It should
be noted that the same problem applies when a client receives a SIP
invitation and is behind a Address/Port-Dependent NAT.
o In Figure 18, the client behind the NAT obtains a server reflexive
representation using standard STUN mechanisms (1)-(4) that have
been used in previous examples in this document (e.g.,
o The external mapped address (server reflexive) obtained is also
used in the outgoing SDP contained in the SIP INVITE request (5).
o In this example, the client is still able to send media to the
external client. The problem occurs when the client outside the
NAT tries to use the reflexive address supplied in the outgoing
INVITE request to traverse media back through the Address/
o A Address/Port-Dependent NAT has differing rules from the
Endpoint-Independent type of NAT (as defined in RFC 4787
[RFC4787]). For any internal IP address and port combination,
data sent to a different external destination does not provide the
same public mapping at the NAT. In Figure 18, the STUN query
produced a valid external mapping for receiving media. This
mapping, however, can only be used in the context of the original
STUN request that was sent to the STUN server. Any packets that
attempt to use the mapped address and that do not originate from
the STUN server IP address and optionally port will be dropped at
the NAT. Figure 18 shows the media being dropped at the NAT after
(7) and before (8). This then leads to one-way audio.
220.127.116.11. TURN Solution
As identified in Section 18.104.22.168, STUN provides a useful tool for the
traversal of the majority of NATs but fails with Address/
Port-Dependent NAT. The TURN extensions [RFC5766] address this
scenario. TURN extends STUN to allow a client to request a relayed
address at the TURN server rather than a reflexive representation.
This then introduces a media relay in the path for NAT traversal (as
described in Section 22.214.171.124). The following example explains how
TURN solves the previous failure when using STUN to traverse a
Address/Port-Dependent NAT. It should be noted that TURN works most
effectively when used in conjunction with ICE. Using TURN on its own
results in all media being relayed through a TURN server; this is not
o In this example, client L issues a TURN allocate request (1) to
obtained a relay address at the STUN server. The request
traverses through the Address/Port-Dependent NAT and reaches the
STUN server (2). The STUN server generates an Allocate response
(3) that contains both a server reflexive address (Map=NAT-PUB-1)
of the client and also a relayed address (Rel=STUN-PUB-2). The
relayed address maps to an address mapping on the STUN server that
is bound to the public pinhole that has been opened on the NAT by
the Allocate request. This results in any traffic sent to the
TURN server relayed address (Rel=STUN-PUB-2) being forwarded to
the external representation of the pinhole created by the Allocate
o The TURN derived address (STUN-PUB-2) arrives back at the
originating client (4) in an Allocate response. This address can
then be used in the SDP for the outgoing SIP INVITE request as
shown in the following example (note that the example also
includes client L obtaining a second relay address for use in the
RTCP attribute (5-8)):
o=test 2890844342 2890842164 IN IP4 $L-PRIV-1
c=IN IP4 $STUN-PUB-2.address
m=audio $STUN-PUB-2.port RTP/AVP 0
o On receiving the INVITE request, the User Agent Server (UAS) is
able to stream media and RTCP to the relay address (STUN-PUB-2 and
STUN-PUB-3) at the STUN server. As shown in Figure 19 (between
messages (12) and (13), the media from the UAS is directed to the
relayed address at the STUN server. The STUN server then forwards
the traffic to the open pinholes in the Address/Port-Dependent NAT
(NAT-PUB-1 and NAT-PUB-2). The media traffic is then able to
traverse the Address/Port-Dependent NAT and arrives back at client
o TURN on its own will work for Address/Port-Dependent and other
types of NAT mentioned in this specification but should only be
used as a last resort. The relaying of media through an external
entity is not an efficient mechanism for NAT traversal and comes
at a high processing cost.
126.96.36.199. ICE Solution
The previous two examples have highlighted the problem with using
core STUN for all forms of NAT traversal and a solution using TURN
for the Address/Port-Dependent NAT case. The RECOMMENDED mechanism
for traversing all varieties of NAT is using ICE, as detailed in
Section 188.8.131.52. ICE makes use of core STUN, TURN and any other
mechanism (e.g., NAT-PMP[NAT-PMP], UPnP IGD[UPnP-IGD]) to provide a
list of prioritized addresses that can be used for media traffic.
Detailed examples of ICE can be found in Section 184.108.40.206.1. These
examples are associated with an Endpoint-Independent type NAT but can
be applied to any NAT type variation, including Address/
Port-Dependent type NAT. The ICE procedures carried out are the
same. For a list of candidate addresses, a client will choose where
to send media dependent on the results of the STUN connectivity
checks and associated priority (highest priority wins). It should be
noted that the inclusion of a NAT displaying Address/Port-Dependent
properties does not automatically result in relayed media. In fact,
ICE processing will avoid use of media relay with the exception of
two clients that both happen to be behind a NAT using Address/
Port-Dependent characteristics. The connectivity checks and
associated selection algorithm enable traversal in this case.
Figure 20 and the following description provide a guide as to how
this is achieved using the ICE connectivity checks. This is an
abbreviated example that assumes successful SIP offer/answer exchange
and illustrates the connectivity check flow.
| | |(9)Bind Req |
| | |<-----------------|
| | |Src=R-Priv-1 |
| | |Dest=L-NAT-PUB-1 |
| |(10)Bind Req | |
| |<-----------------| |
| |Src=R-NAT-PUB-1 | |
| |Dest=L-NAT-PUB-1 | |
| | | |
|(11)Bind Req | | |
|<-----------------| | |
|Src=R-NAT-PUB-1 | | |
|Dest=L-PRIV-1 | | |
| | | |
|(12)Bind Resp | | |
|----------------->| | |
|Src=L-PRIV-1 | | |
|Dest=L-NAT-PUB-1 | | |
| | | |
| |(13)Bind Resp | |
| |----------------->| |
| |Src=L-NAT-PUB-1 | |
| |Dest=R-NAT-PUB-1 | |
| | | |
| | |(14)Bind Resp |
| | |----------------->|
| | |Src=L-NAT-PUB-1 |
| | |Dest=R-PRIV-1 |
| | | |
Figure 20: Single Address/Port-Dependent NAT - Success
In this abbreviated example, client R has already received a SIP
INVITE request and is starting its connectivity checks with client L.
Client R generates a connectivity check (1) and sends to client L's
information as presented in the SDP offer. The request arrives at
client L's Address/Port-Dependent NAT and fails to traverse as there
is no NAT binding. This would then move the connectivity check to a
failed state. In the meantime, client L has received the SDP answer
in the SIP request and will also commence connectivity checks. A
check is dispatched (3) to client R. The check is able to traverse
the NAT due to the association set up in the previously failed check
(1). The full Bind request/response is shown in steps (3)-(8). As
part of a candidate pair, client R will now successfully be able to
complete the checks, as illustrated in steps (9)-(14). The result is
a successful pair of candidates that can be used without the need to
relay any media.
In conclusion, the only time media needs to be relayed is a result of
clients both behind Address/Port-Dependent NATs. As you can see from
the example in this section, neither side would be able to complete
connectivity checks with the exception of the Relayed candidates.
6. IPv4-IPv6 Transition
This section describes how IPv6-only SIP User Agents can communicate
with IPv4-only SIP User Agents. While the techniques discussed in
this document primarily contain examples of traversing NATs to allow
communications between hosts in private and public networks, they are
by no means limited to such scenarios. The same NAT traversal
techniques can also be used to establish communication in a
heterogeneous network environment -- e.g., communication between an
IPv4 host and an IPv6 host.
6.1. IPv4-IPv6 Transition for SIP Signaling
IPv4-IPv6 translations at the SIP level usually take place at dual-
stack proxies that have both IPv4 and IPv6 DNS entries. Since these
translations do not involve NATs that are placed in the middle of two
SIP entities, they fall outside the scope of this document. A
detailed description of this type of translation can be found in
7. Security Considerations
There are no security considerations beyond the ones inherited by
The authors would like to thank the members of the IETF SIPPING WG
for their comments and suggestions. Expert review and detailed
contribution including text was provided by Dan Wing, who was
Detailed comments were provided by Vijay Gurbani, Kaiduan Xie, Remi
Denis-Courmont, Hadriel Kaplan, Phillip Matthews, Spencer Dawkins,
and Hans Persson.
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] 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.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer
Model with Session Description Protocol (SDP)",
RFC 3264, June 2002.
[RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation
Protocol (SIP) Extension Header Field for Registering
Non-Adjacent Contacts", RFC 3327, December 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3581] Rosenberg, J. and H. Schulzrinne, "An Extension to the
Session Initiation Protocol (SIP) for Symmetric
Response Routing", RFC 3581, August 2003.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP)
attribute in Session Description Protocol (SDP)",
RFC 3605, October 2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP:
Session Description Protocol", RFC 4566, July 2006.
[RFC4787] Audet, F. and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, January 2007.
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol
(RTCP)", BCP 131, RFC 4961, July 2007.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)",
RFC 5389, October 2008.
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing
Client-Initiated Connections in the Session Initiation
Protocol (SIP)", RFC 5626, October 2009.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data
and Control Packets on a Single Port", RFC 5761,
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal
Using Relays around NAT (TURN): Relay Extensions to
Session Traversal Utilities for NAT (STUN)", RFC 5766,
[RFC5923] Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse
in the Session Initiation Protocol (SIP)", RFC 5923,
9.2. Informative References
[MIDDLEBOXES] Stucker, B. and H. Tschofenig, "Analysis of Middlebox
Interactions for Signaling Protocol Communication
along the Media Path", Work in Progress, July 2010.
[NAT-PMP] Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)",
Work in Progress, April 2008.
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002.
[RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery
Using Session Traversal Utilities for NAT (STUN)",
RFC 5780, May 2010.
[RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R.,
Hawrylyshen, A., and M. Bhatia, "Requirements from
Session Initiation Protocol (SIP) Session Border
Control (SBC) Deployments", RFC 5853, April 2010.
[RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6
Transition in the Session Initiation Protocol (SIP)",
RFC 6157, April 2011.
[UPnP-IGD] UPnP Forum, "Universal Plug and Play Internet Gateway
Device v1.0", 2000,