1. Introduction
A host behind a NAT may wish to exchange packets with other hosts, some of which may also be behind NATs. To accomplish this, the hosts involved can use "hole punching" techniques (see [RFC5128]) to attempt to discover a direct communication path, that is, a communication path from one host to another that goes through one or more NATs and routers but does not involve any relays.
As described in [RFC5128] and [RFC4787], hole punching techniques will fail if both hosts are behind NATs that are not well-behaved. For example, if both hosts are behind NATs that have "Address-Dependent Mapping" or "Address and Port-Dependent Mapping" as their mapping behavior, hole punching techniques will usually fail.
When a direct communication path cannot be found, it is necessary to use the services of an intermediate host that acts as a packet relay. This relay typically resides in the public Internet and relays packets between the hosts, which are behind NATs.
This specification defines a protocol, called TURN, that allows a host behind a NAT (called a TURN client) to request that another host (called a TURN server) act as a relay. The client can arrange for the server to relay packets to and from certain other hosts (called peers) and can control how the relaying is done. The client does this by obtaining an IP address and port on the server, called the relayed transport address. When a peer sends a packet to the relayed transport address, the server relays the packet to the client. When the client sends a packet to the server, the server relays it to the appropriate peer using the relayed transport address as the source.
A client using TURN must have some way to communicate the relayed transport address to its peers and to learn each peer's IP address and port (more precisely, each peer's server-reflexive transport address, see Section 2). How this is done is out of the scope of the TURN protocol. One way this might be done is for the client and peers to exchange email messages. Another way is for the client and its peers to use a special-purpose "introduction" or "rendezvous" protocol (see [RFC5128] for more details).
If TURN is used with ICE [RFC5245], then the relayed transport address and the IP addresses and ports of peers are included in the candidate information that must be carried by the rendezvous protocol. For example, if TURN and ICE are being used as part of a multimedia solution using SIP [RFC3261], then SIP serves the role of the rendezvous protocol, carrying the candidate information inside the SIP message bodies. If TURN and ICE are used with another rendezvous protocol, then [MMUSIC-ICE-NONSIP] provides guidance on the services that the rendezvous protocol must perform.
Though using a TURN server to achieve communication between two hosts behind NATs is very likely to be successful, it costs the TURN server provider both money and effort, since the server typically requires a high-bandwidth connection to the Internet. Therefore, it is desirable to use a TURN server only when a direct communication path cannot be found. When the client and a peer use ICE to determine the communication path, ICE will use hole punching techniques to search for a direct path first and only use a TURN server when a direct path cannot be found.
TURN was originally invented to support multimedia sessions signaled using SIP. Because SIP supports forking, TURN supports multiple peers per relayed transport address, a feature not supported by other approaches such as SOCKS [RFC1928]. However, care has been taken to ensure that TURN is suitable for other types of applications.
TURN is designed to be one component of a larger ICE NAT traversal solution. Implementers of TURN are urged to investigate ICE and seriously consider using it for their applications. However, it is also possible to use TURN without ICE.
TURN is an extension to the STUN (Session Traversal Utilities for NAT) protocol [RFC5389]. Most (though not all) TURN messages are STUN-formatted messages. Readers of this document should be familiar with STUN.