Words taken from RE-TURN RTCWEB draft
- TURN [RFC 5766] is a protocol used to provide connectivity between users behind NAT or to obscure the identity of the participants by concealing their IP addresses.
- The TURN server typically sits in the public internet.
- The problem is direct UDP transmissions are not permitted between clients on the internal networks and external IP addresses in many enterprises. It is not ideal to use TURN-TCP or TURN-TLS for media because of latency.
- In the current WebRTC implementations, TURN can only be used on a single-hop basis.
- Using only the enterprise’s TURN server reveals the user information. Less security here.
- Using only the application’s TURN server may be blocked by the network administrator or may require using TURN-TCP or TURN-TLS. Less connectivity here.
- For security and connectivity, Recursively Encapsulated TURN (Re-TURN) is introduced. Multiple TURN servers are used to route the traffic.
- The browser allocates a port on the border TURN server (TURN proxy) and runs STUN and TURN over this allocations. So the TURN is recursively encapsulated.
- Only the browser needs to implement the Re-TURN and not the TURN proxy or the Application TURN server.
TURN is abbreviation for Traversal Using Relays around NAT. It is a control protocol that allows the host behind a NAT to exchange packets with its peers using the relay. It is specified in the RFC . The following are few words about this protocol:
- TURN is part of the ICE (Interactive Connectivity Establishment) but it can be used without ICE.
- TURN is designed to solve the communication problem when both the client and its peer are behind respective NAT where the hole punching techniques (discovering direct communication path) may fail. In other words TURN is used when a direct communication path between the client and the pair can NOT be found.
- The public TURN server sits between the two hosts that are behind NAT and relays the packets between them.
- TURN is client-server protocol. The client is called TURN client and the server is called TURN server.
- The TURN client obtains (using the TURN protocol -Allocate transaction) on the TURN server what is called relayed transport address (IP address and port).
- The client sends CreatePermissions request to the TURN server to create permissions (permissions to validate the peer-server communication).
- The TURN server sees the messages coming from the client as it is coming from a transport address on NAT. This address is called client’s server-reflexive transport address.
- The NAT forwards packets coming to the client’s server-reflexive transport to the client’s host transport address (private address).
- The TURN server receives the application data from the client, make the relayed transport address as the source of the packets and relays them to the peer using UDP datagrams.
- The peer sends the application data in UDP packets to the client’s relayed transport address on the relay server. Then the server checks the permissions and on validation it relays the data to the client.
- A way to communicate the relayed transport address and peers addresses (server-reflexive transport addresses) is needed (out of scope of the TURN protocol).
- In VOIP, if TURN is used with ICE, then the client puts its obtained relayed transport address as an ICE candidate (among other candidates) in the SDP carried by the rendezvous protocol like SIP. When the other peers receives the SIP request, they will know how to reach the client.
- The TURN messages (encapsulation of the application data) contains an indication of the peer the client is communicating with so the client can use a single relayed transport address to communicate with multiple peers. This is when the the rendezvous protocol (e.g. SIP) supports forking.
- Using TURN is expensive so when TURN is used with ICE, the ICE uses hole punching techniques first to discover the direct path. If the direct path is not found, then TURN is used.
- Using TURN makes the communication no longer peer to peer communication.