Private WebRTC endpoints are often shielded from the public internet by a network that does the mapping from source to the destination. The mapping facilitates traffic going in or out of the private systems to reach the correct host. This process is called Network Address Translation, or NAT.

While not necessarily restrictive, these interfaces need to be pin-holed to create a public-private pair for media streams to flow from the outside world into the WebRTC browser. This process of gathering candidates and prioritizing them in order to make a successful media connection with the remote peer, as defined in in RFC 8445, is called Interactive Connectivity Establishment, or ICE.

A large percentage of WebRTC calls have network restrictions for calls between parties who are not on the same network. This includes calls from a peer with symmetric public-private pairing (NAT) or calls from a network having additional firewall restrictions such as in universities or office spaces. These can face black video issues (missing feed/no packet reception) or fail at the ICE gathering stage leading to no connection. Such cases can benefit from two main protocols:

1. STUN (Session Traversal Utilities for NAT) for IP discovery to get an external network address.
2. TURN (Traversal Using Relays around NAT) which is used to relay the traffic between peers by means of relaying media through it. This has been an effective way to bypass restrictive firewalls.
   • UDP: preferable 
   • TCP: less preferred as the guaranteed ordered delivery of packets implies overhead

Additionally, there is TURN over TLS:

3. TURNS (Secure Traversal Using Relay around NAT) is used to relay media on a TCP/TLS connection via the TURN server. It passes through a TLS socket to bypass extremely restrictive firewall rules.

This post describes relative performance working with no ICE Servers, a public STUN server, and a self-hosted CoTURN server. The experiments are carried out through multiple restrictive network firewalls, public internet connections, broadband, as well as 4G data connection. The observations are noted at the end of each section.

Without ICE Servers: Blocking network fails to make a media connection

If the peers have a blocking firewall policy and no means of establishing interconnectivity, the media stream will fail to reach remote from local or vice versa leading to either no connection or black remote video.

A successfully ICE candidate pairing:

ICE connection state: new => checking => connected
Connection state: new => connecting => connected
Signaling state: new => have-local-offer => stable
ICE Candidate pair: 66.194.72.49:15695 <=> 129.203.xxx.xxx:28043

An unsuccessful ICE candidate pairing:

ICE connection state: new => checking => disconnected
Connection state: new => connecting => failed
Signaling state: new => have-local-offer => stable
ICE Candidate pair: (not connected)

ICE Terminology

• Trickle ICE: Fastens the connection setup if the endpoints are in the same network. Check from this repo if the TURN server responds to request for ICE.

• ICE Candidate Types 
  • Host: Gathered directly from the local network adapter, host candidates are the internal IP address and port of a computer on a LAN. They can only route between peers on the same subnet.
  • Srflx: server reflexive candidate which is an intermediary address assigned by the STUN server.
  • Prflx: peer reflexive candidate which is alike the srflx however this is gathered directly by the peer usually after the connection has been established ( for example if the existing connection is failing)
  • Relay: IP address used by the TURN server to forward the media between the peers.

• NAT (Network Address Translation) translates public IP to private systems with internal IPs in a local network. Agents such as routers facilitate this mapping. Broadly NAT is of type
  • Symmetric NAT: 1:1 relationship between NAT mapping and L4, i.e., a connection is unique for any unique combination of socket (protocol, local IP and port, destination IP and port)
  • Asymmetric NAT: connection of a protocol, local IP, and port with different destination IP and port. 

STUN: Successful connections in less guarded networks, but not for most enterprise firewalls and network policies

Some ICE Candidates gathered using the STUN server provided by Google.

These work for simple NATing scenarios where private IP is linkedin to a public IP in a network such as Telecom provided networks (4G) or majority of Wifi networks. However, it does not work as well when there is a firewall restriction. Highlighting one such case below:

The configuration for this setup is non SIP, using only Google-provided STUN server.

https://<ip>:8081/index.html#34900, { iceServers: [stun:stun.l.google.com:19302], iceTransportPolicy: all, bundlePolicy: balanced, rtcpMuxPolicy: require, iceCandidatePoolSize: 0, sdpSemantics: "unified-plan", extmapAllowMixed: true }

A use case of WebRTC internals where the WebRTC client was not able to gather enough candidates to establish peer to peer media connection is shared below:

Self-Hosted TURN Server, CoTURN

STUN performs network discovery and hole punching in a best effort to connect local and remote without directly affecting the media streams and steps out of the picture once connection is established. In contrast, a TURN server remains in the media path after the connection has been established, relaying the media packets through itself.

CoTURN is an open-source STUN and TURN-supported ICE Server. It is well contributed by the developer community. It is RFC-compliant and frequently used by VoIP Integrators for their real time communication solutions. 

Setup for CoTURN

Here is a quick overview of installation CoTURN and its usage for a non-SIP communication client: https://webrtc.ventures/2017/08/quick-guide-stunturn-webrtc/. Once the CoTURN service is running, we will need the following adding in our JavaScript WebRTC webpage:

iceServers: [
{ 'url': 'stun: <username>@<serverip>: <port>'},
{ 'url': 'turn: <username>@<serverip>: <port>', 'credential': '<password>'}]

From the WebRTC internal dumps file downloaded and using the tool provided at https://fippo.github.io/webrtc-dump-importer/, we can post analyze the WebRTC session: 

Ensure the ICE Candidate is an active pair by observing the highlighted section of the traces. For example, in the trace the active pair is highlighted in bold:

CoTURN Performance 

TURN’s relay-based ICE candidates are generally prioritized lower than STUN’s reflexive candidates. The QoS metrics for this study, given no firewall restrictions, shows indistinguishable performance for local connections (i.e., within the same region and network). However, TURN performs significantly better than STUN over long distances (i.e., WebRTC peers across continents). With firewalls, TURN is the best proven and widely used methodology to overcome network restriction and establish peer to peer stream.

Performance for peer reflexive candidate on local and relay candidate on remote

About the Author: Altanai Bisht

Here at WebRTC.ventures, we pride ourselves on offering our clients the opportunity to work with extremely bright developers, like Altanai. Don’t trust your custom video solution to just anyone. Trust the experts!