ICE, STUN and TURN - pvgupta24/Jitsi-Meet-Concepts GitHub Wiki

Introduction

A Public IP Address is an IP address that is globally unique across the Internet. Only one device may be in possession of a public IP address. A Private IP Address is an IP address that is not globally unique and may exist simultaneously on many different devices. A private IP address is never directly connected to the Internet. Devices that possesses a private IP address will be in their own unique IP space. Network Address Translation (NAT) gives private IP addresses access to the Internet. NAT allows a single devices, such as a router, to act as an agent between the Internet (populated with public IP addresses) and a private network (populated with private IP addresses). A NAT device can use a single public IP address to represent many private IP addresses.

Types of NATs

Full Cone NAT (Static NAT)

A full cone NAT (also known as a one to one NAT) is the only type of NAT where the port is permanently open and allows inbound connections from any external host. A full cone NAT maps a public IP address and port to a LAN IP and port. Any external host can send data to the LAN IP through the mapped NAT IP and port. If it tries to send data through a different port it will fail. This type of NAT is also known as port forwarding. This is the least restrictive type of NAT; the only requirement is that the connection comes in on a specific port (the one you opened).

Restricted Cone NAT (Dynamic NAT)

A restricted cone NAT works in the same way as a full cone NAT but applies additional restrictions based on an IP address. The internal client must first have sent packets to IP address (X) before it can receive packets from X. In terms of restrictions the only requirement is that packets come in on the mapped port and from an IP address that the internal client has sent packets to.

Port Restricted Cone NAT (Dynamic NAT)

A port restricted cone NAT acts in exactly the same way as a restricted cone NAT but applies restrictions to ports also. Where a restricted cone NAT will accept connections from any source port a port restricted cone NAT restricts this further by only accepting connections from the IP address and port it sent the outbound request to.

Symmetric NAT

A Symmetric NAT not only translates the IP address from private to public (and vice versa), it also translates ports. There are various rules as to how that translation and mapping occurs, but it’s safe to say that with symmetric NAT, one should never expect that the IP address/port of the source is what the destination will see.

ICE

Interactive Connectivity Establishment (ICE) is a framework that allows WebRTC to overcome the complexities of real-world networking. It’s ICE’s job to find the best path to connect peers. It may be able to do that with a direct connection between the clients, but it also works for clients where a direct connection is not possible (i.e. behind NATs).

STUN

In the case of asymmetric NAT, ICE will use a STUN (Session Traversal Utilities for NAT) server. A STUN server allows clients to discover their public IP address and the type of NAT they are behind. This information is used to establish the media connection. The STUN protocol is defined in RFC 3489. In most cases, a STUN server is only used during the connection setup and once that session has been established, media will flow directly between clients.

STUN

TURN

If a STUN server cannot establish the connection, ICE can turn to TURN. Traversal Using Relay NAT (TURN) is an extension to STUN that allows media traversal over a NAT that does not do the “consistent hole punch” required by STUN traffic. TURN servers are often used in the case of a symmetric NAT. Unlike STUN, a TURN server remains in the media path after the connection has been established. That is why the term “relay” is used to define TURN. A TURN server literally relays the media between the WebRTC peers. Clearly, not having to use TURN is desirable, but not always possible. Every WebRTC solution must be prepared to support both service types and engineered to handle the processing requirements placed upon the TURN server.

TURN

Why STUN doesn't work with a symmetric NAT

While using STUN, the following steps usually take place

  1. Client connects to the STUN server at stun_addr through NAT device. The NAT device translates the source address to natted_addr_1
  2. STUN server tells client the address from which it received the connection, which is natted_addr_1
  3. Client contacts the server at srv_addr through the NAT device, and tells the external system to use natted_addr_1 if it wants to reach the client
  4. External system sends something to the client using natted_addr_1 This will only work if the NAT device uses natted_addr_1 for both the communication to the STUN server and the other external system. A symmetrical NAT device will use a different translation in steps 1 and 3 because the destination address of the traffic is different. Unfortunately, the server has been told to use natted_addr_1 but packets from srv_addr destined to natted_addr_1 will be rejected by the NAT device because of the NAT Address:Port restriction in-place.