tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6314

 
 
 

NAT Traversal Practices for Client-Server SIP

Part 4 of 4, p. 48 to 60
Prev RFC Part

 


prevText      Top      Up      ToC       Page 48 
5.2.2.  Address/Port-Dependent NAT

5.2.2.1.  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
   preferred option.

Top      Up      ToC       Page 49 
     Client     ADDRESS/PORT-Dependent     STUN                [..]
                         NAT              Server
       |                  |                  |                  |
       |(1) BIND Req      |                  |                  |
       |Src=L-PRIV-1      |                  |                  |
       |Dest=STUN-PUB     |                  |                  |
       |----------------->|                  |                  |
       |                  |(2) BIND Req      |                  |
       |                  |Src=NAT-PUB-1     |                  |
       |                  |Dest=STUN-PUB     |                  |
       |                  |----------------->|                  |
       |                  |                  |                  |
       |                  |(3) BIND Resp     |                  |
       |                  |<-----------------|                  |
       |                  |Src=STUN-PUB      |                  |
       |                  |Dest=NAT-PUB-1    |                  |
       |                  |Map=NAT-PUB-1     |                  |
       |                  |                  |                  |
       |(4) BIND Resp     |                  |                  |
       |<-----------------|                  |                  |
       |Src=STUN-PUB      |                  |                  |
       |Dest=L-PRIV-1     |                  |                  |
       |Map=NAT-PUB-1     |                  |                  |
       |                  |                  |                  |
       |(5)SIP INVITE     |                  |                  |
       |------------------------------------------------------->|
       |                  |                  |                  |
       |                  |                  |(6)SIP 200 OK     |
       |                  |<------------------------------------|
       |                  |                  |                  |
       |(7)SIP 200 OK     |                  |                  |
       |<-----------------|                  |                  |
       |                  |                  |                  |
       |========================================================|
       |>>>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>|
       |========================================================|
       |                  |                  |                  |
       |                  x=====================================|
       |                  xIncoming Media sent to L-PRIV-1<<<<<<|
       |                  x=====================================|
       |                  |                  |                  |
       |(8)SIP ACK        |                  |                  |
       |----------------->|                  |                  |
       |                  |(9) SIP ACK       |                  |
       |                  |------------------------------------>|
       |                  |                  |                  |

         Figure 18: Address/Port-Dependent NAT with STUN - Failure

Top      Up      ToC       Page 50 
   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.,
      Section 5.2.1.1.1).

   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/
      Port-Dependent NAT.

   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.

5.2.2.2.  TURN Solution

   As identified in Section 5.2.2.1, 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 4.2.3.2).  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
   efficient.

Top      Up      ToC       Page 51 
       L        Address/Port-Dependent     TURN                [..]
                         NAT              Server
       |                  |                  |                  |
       |(1) Alloc Req     |                  |                  |
       |Src=L-PRIV-1      |                  |                  |
       |Dest=STUN-PUB-1   |                  |                  |
       |----------------->|                  |                  |
       |                  |                  |                  |
       |                  |(2) Alloc Req     |                  |
       |                  |Src=NAT-PUB-1     |                  |
       |                  |Dest=STUN-PUB-1   |                  |
       |                  |----------------->|                  |
       |                  |                  |                  |
       |                  |(3) Alloc Resp    |                  |
       |                  |<-----------------|                  |
       |                  |Src=STUN-PUB-1    |                  |
       |                  |Dest=NAT-PUB-1    |                  |
       |                  |Map=NAT-PUB-1     |                  |
       |                  |Rel=STUN-PUB-2    |                  |
       |                  |                  |                  |
       |(4) Alloc Resp    |                  |                  |
       |<-----------------|                  |                  |
       |Src=STUN-PUB-1    |                  |                  |
       |Dest=L-PRIV-1     |                  |                  |
       |Map=NAT-PUB-1     |                  |                  |
       |Rel=STUN-PUB-2    |                  |                  |
       |                  |                  |                  |
       |(5) Alloc Req     |                  |                  |
       |Src=L-PRIV-2      |                  |                  |
       |Dest=STUN-PUB-1   |                  |                  |
       |----------------->|                  |                  |
       |                  |                  |                  |
       |                  |(6) Alloc Req     |                  |
       |                  |Src=NAT-PUB-2     |                  |
       |                  |Dest=STUN-PUB-1   |                  |
       |                  |----------------->|                  |
       |                  |                  |                  |
       |                  |(7) Alloc Resp    |                  |
       |                  |<-----------------|                  |
       |                  |Src=STUN-PUB-1    |                  |
       |                  |Dest=NAT-PUB-2    |                  |
       |                  |Map=NAT-PUB-2     |                  |
       |                  |Rel=STUN-PUB-3    |                  |
       |                  |                  |                  |
       |(8) Alloc Resp    |                  |                  |
       |<-----------------|                  |                  |
       |Src=STUN-PUB-1    |                  |                  |
       |Dest=L-PRIV-2     |                  |                  |

Top      Up      ToC       Page 52 
       |Map=NAT-PUB-2     |                  |                  |
       |Rel=STUN-PUB-3    |                  |                  |
       |                  |                  |                  |
       |(9)SIP INVITE     |                  |                  |
       |----------------->|                  |                  |
       |                  |                  |                  |
       |                  |(10)SIP INVITE    |                  |
       |                  |------------------------------------>|
       |                  |                  |                  |
       |                  |                  |(11)SIP 200 OK    |
       |                  |<------------------------------------|
       |                  |                  |                  |
       |(12)SIP 200 OK    |                  |                  |
       |<-----------------|                  |                  |
       |                  |                  |                  |
       |========================================================|
       |>>>>>>>>>>>>>Outgoing Media sent from L-PRIV-1>>>>>>>>>>|
       |========================================================|
       |                  |                  |                  |
       |                  |                  |==================|
       |                  |                  |<<<Media Sent to<<|
       |                  |                  |<<<<STUN-PUB-2<<<<|
       |                  |                  |==================|
       |                  |                  |                  |
       |=====================================|                  |
       |<Incoming Media Relayed to L-PRIV-1<<|                  |
       |=====================================|                  |
       |                  |                  |                  |
       |                  |                  |==================|
       |                  |                  |<<<RTCP Sent to<<>|
       |                  |                  |<<<<STUN-PUB-3<<<<|
       |                  |                  |==================|
       |                  |                  |                  |
       |=====================================|                  |
       |<<Incoming RTCP Relayed to L-PRIV-2<<|                  |
       |=====================================|                  |
       |                  |                  |                  |
       |(13)SIP ACK       |                  |                  |
       |----------------->|                  |                  |
       |                  |                  |                  |
       |                  |(14) SIP ACK      |                  |
       |                  |------------------------------------>|
       |                  |                  |                  |

         Figure 19: Address/Port-Dependent NAT with TURN - Success

Top      Up      ToC       Page 53 
   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
      request (NAT-PUB-1).

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

      v=0
      o=test 2890844342 2890842164 IN IP4 $L-PRIV-1
      c=IN IP4 $STUN-PUB-2.address
      t=0 0
      m=audio $STUN-PUB-2.port RTP/AVP 0
      a=rtcp:$STUN-PUB-3.port

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

   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.

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

Top      Up      ToC       Page 54 
   for traversing all varieties of NAT is using ICE, as detailed in
   Section 4.2.3.3.  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 5.2.1.2.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.

Top      Up      ToC       Page 55 
       L      Address/Port-Dependent  Endpoint-Independent      R
                        L-NAT               R-NAT
       |========================================================|
       |               SIP OFFER/ANSWER EXCHANGE                |
       |========================================================|
       |                  |                  |                  |
       |                  |                  |(1)Bind Req       |
       |                  |                  |<-----------------|
       |                  |                  |Src=R=PRIV-1      |
       |                  |                  |Dest=L-NAT-PUB-1  |
       |                  |                  |                  |
       |                  |(2)Bind Req       |                  |
       |                  x<-----------------|                  |
       |                  |Src=R-NAT-PUB-1   |                  |
       |                  |Dest=L-NAT-PUB-1  |                  |
       |                  |                  |                  |
       |(3)Bind Req       |                  |                  |
       |----------------->|                  |                  |
       |Src=L-PRIV-1      |                  |                  |
       |Dest=R-NAT-PUB-1  |                  |                  |
       |                  |                  |                  |
       |                  |(4)Bind Req       |                  |
       |                  |----------------->|                  |
       |                  |Src=L-NAT-PUB-1   |                  |
       |                  |Dest=R-NAT-PUB-1  |                  |
       |                  |                  |                  |
       |                  |                  |(5)Bind Req       |
       |                  |                  |----------------->|
       |                  |                  |Src=L-NAT-PUB-1   |
       |                  |                  |Dest=R-PRIV-1     |
       |                  |                  |                  |
       |                  |                  |(6)Bind Resp      |
       |                  |                  |<-----------------|
       |                  |                  |Src=R-PRIV-1      |
       |                  |                  |Dest=L-NAT-PUB-1  |
       |                  |                  |                  |
       |                  |(7)Bind Resp      |                  |
       |                  |<-----------------|                  |
       |                  |Src=R-NAT-PUB-1   |                  |
       |                  |Dest=L-NAT-PUB-1  |                  |
       |                  |                  |                  |
       |(8)Bind Resp      |                  |                  |
       |<-----------------|                  |                  |
       |Src=R-NAT-PUB-1   |                  |                  |
       |Dest=L-PRIV-1     |                  |                  |
       |                  |                  |                  |

Top      Up      ToC       Page 56 
       |                  |                  |(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.

Top      Up      ToC       Page 57 
   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
   [RFC6157].

7.  Security Considerations

   There are no security considerations beyond the ones inherited by
   reference.

8.  Acknowledgments

   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
   supportive throughout.

   Detailed comments were provided by Vijay Gurbani, Kaiduan Xie, Remi
   Denis-Courmont, Hadriel Kaplan, Phillip Matthews, Spencer Dawkins,
   and Hans Persson.

Top      Up      ToC       Page 58 
9.  References

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,
                  June 2002.

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

Top      Up      ToC       Page 59 
   [RFC5245]      Rosenberg, J., "Interactive Connectivity Establishment
                  (ICE): A Protocol for Network Address Translator (NAT)
                  Traversal for Offer/Answer Protocols", RFC 5245,
                  April 2010.

   [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,
                  April 2010.

   [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,
                  April 2010.

   [RFC5923]      Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse
                  in the Session Initiation Protocol (SIP)", RFC 5923,
                  June 2010.

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.

Top      Up      ToC       Page 60 
   [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,
                  <http://www.upnp.org/specs/gw/igd1/>.

Authors' Addresses

   Chris Boulton
   NS-Technologies

   EMail: chris@ns-technologies.com


   Jonathan Rosenberg
   Skype

   EMail: jdrosen@jdrosen.net


   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   EMail: Gonzalo.Camarillo@ericsson.com


   Francois Audet
   Skype

   EMail: francois.audet@skype.net