WebRTC or Web Real Time Communications, is an open source project that lets browser based applications or web applications communicate using video and audio media
Many use cases are there for video and audio communication but WebRTC can be used to potentially transmit any type of data between devices.
Basic Principles and protocols
1. P2P Communication
Using WebRTC devices can establish direct connections between peer devices.
Having a direct connection negates the need for a server between devices, this could be cheaper and less resources are required
2. Media Streaming
WebRTC uses advanced codecs to enable high quality media streaming
The WebRTC technology supports real time audio and video streaming
SRTP: The Secure Real Time Transport Protocol ensures that the audio and video media streams are secure encrypted.
3. Signaling
You need signalling for setting up, controlling and ending a communication session
WebRTC itself does not specify a signalling protocol, thus you can choose form a variety of signalling protocols such as WebSocket, SIP or any other
4. NAT Traversal
WebRTC handles network address translation (NAT) traversal using STUN ( Session Traversal Utilities for NAT ) or TURN ( Traversal Using Relays around NAT) servers
Generally you need a TURN server for NAT traversal, if you are looking for a TURN server we suggest going for Metered Global TURN server service
5. Security
The data is end-to-end encrypted in webrtc using protocols such as as DTLS (Datagram Transport Layer Security) and SRTP ( Secure Real time Transport Protocol)
Thus webrtc is completely secure and private
Core Problem: Direct Peer to Peer Communication (Why do we need WebRTC servers)
NAT Traversal issues
Network Address Translation is a protocol that is used by routers and NAT devices to route multiple devices that have private IP addresses though a single public IP address or few public IP addresses
NAT was introduced to conserve limited number of public IP addresses and introduce an additional layer of security and internal network structure.
Types of NAT
There are different types and kinds of NATs available, depending on how they allow external traffic to flow to the internal networks
Full Cone NAT: This just maps a internal private IP and port number to an external public IP and port number. Any external device can send data to the internal device by sending the data to the external mapped public IP address and port number
Restricted Cone NAT: This is similar to the full cone NAT but it only allows external devices to send data to internal device if the internal device has first send the data to that external device
Port Restricted Cone NAT: This is similar to the restricred cone NAT but more restrictive, here the external device can send the data to the internal device only if the internal device has send the data to that external device first and the external device can only send the data on the prot nummber from which it forst recieved the data from.
Symmetric NAT: Symmetric NAT is the most difficult to traverse, here each request from an internal device (internal IP) is mapped to a different source public IP address and port number. Thus if the same device sends data to different addresses then different source external IP and port number is used thus it is practically impossible to use STUN to discover a devices static public IP address and port number
How NAT Affects Peer-to-Peer Connection
NAT makes it diffcult to establish peer to peer connection because the NAT maskes the private IP addresses of the devices that are behind it with a single or few public IP addresses. Here are some of the reasons NAT imapcts peer to peer connections
Address Translation: NAT changes the private IP address of the internal devices to a different public IP address and port number.As a result the private IP address and port number are hidden from the local network
Connection Requests: For a P2P connection both the devices need to know the public IP address and port number of each other, the NAT obcuscates this thus it is difficult to make a direct connection
Inbound connection blocking: NAT and firewall rules obstructs inbound connection attempts. This is because hackers often try to establish connection from their devices to the devices they wish to hack so it is a safety features. That is why to establish connection you need a TURN server
WebRTC Server: The Solution
A webrtc server is an important component of webrtc framework, it is designed to facilitate real time communication between devices and applications
While webrtc can enable direct p2p communication, often this fails due to NAT restrictions and firewall rules.
The WebRTC server handle tasks such as relaying data when direct connection is not possible
There are primaraly three types of webrtc servers
STUN server
TURN server
Signalling server
Each of these servers play an important role in the webrtc ecosystem. You can learn more about these servers below. The most important among these is the TURN server, If you are looking for one you can consider Metered.ca
NAT Traversal Techniques
To overcome the NAT connectivity challenges, several techniques are used, here are some of the popular ones.
STUN ( Session Traversal Utilities for NAT) :
As we have already seed NAT obfuscates the internal IP address and port number of devices that are behind it. The STUN server helps discover the IP address and port number of the devices. So, that the devices can connect with each other
How stun works is by: A client device sends a request to a STUN server when relies back to the client device with the device’s public IP address and port number.
TURN ( Traversal Using Relays Around NAT)
TURN servers relay traffic through themselves thus no matter how strict the NAT is, it is always possible to traverse it with TURN server
This methods effective solves the NAT problem but may create issues such as latency if the server is geographically remotely located then your users that is why you need a globally located turn servers so that no matter where your users are they get less than 50 ms latency. One such service is Metered TURN servers
ICE (Inteactive connectivity establishment)
ICE combines STUN and TURN to find the best path possible, it first tries to establish a connection using STUN which fails most of the time then it attempts to connect using TURN servers
How ICE works step by step process
Let us understand how ICE works using an example: Let us consider there are 2 devices and these devices are located behind different NATs and these devices want to do video calling
Signalling Phase
Both the devices use a signaling server to exchange their network information. The webRTC does not specify any particular signalling protocol to use.
2. Connecting through STUN
Each device tries to discover what their public IP and port number is using the STUN server, they can then share these details with each other using the signalling server and then connect to each other
3. Connection Attempt
The devices try to connect to each other, this often fails because of stricter NAT and firewall rules that do not allow external devices to connect to devices that are behind the NAT
4. TURN fallback:
If the direct connection fails then peers try to connect through a TURN server to relay the traffic to each other
Metered.ca: The Global TURN Server solution
API: TURN server management with powerful API. You can do things like Add/ Remove credentials via the API, Retrieve Per User / Credentials and User metrics via the API, Enable/ Disable credentials via the API, Retrive Usage data by date via the API.
Global Geo-Location targeting: Automatically directs traffic to the nearest servers, for lowest possible latency and highest quality performance. less than 50 ms latency anywhere around the world
Servers in 12 Regions of the world: Toronto, Miami, San Francisco, Amsterdam, London, Frankfurt, Bangalore, Singapore,Sydney, Seoul
Low Latency: less than 50 ms latency, anywhere across the world.
Cost-Effective: pay-as-you-go pricing with bandwidth and volume discounts available.
Easy Administration: Get usage logs, emails when accounts reach threshold limits, billing records and email and phone support.
Standards Compliant: Conforms to RFCs 5389, 5769, 5780, 5766, 6062, 6156, 5245, 5768, 6336, 6544, 5928 over UDP, TCP, TLS, and DTLS.
Multi‑Tenancy: Create multiple credentials and separate the usage by customer, or different apps. Get Usage logs, billing records and threshold alerts.
Enterprise Reliability: 99.999% Uptime with SLA.
Enterprise Scale: With no limit on concurrent traffic or total traffic. Metered TURN Servers provide Enterprise Scalability
5 GB/mo Free: Get 5 GB every month free TURN server usage with the Free Plan
Runs on port 80 and 443
Support TURNS + SSL to allow connections through deep packet inspection firewalls.
Support STUN
Supports both TCP and UDP
Free Unlimited STUN
Setting Up Metered.ca Server: A Step by Step guide
Account Creating and initial setup
go to metered.ca/stun-turn website and create an account by clicking on the “Get Started” Button
There are some tutorials that you can look at and then you can also test the turn servers as well
3. then you can choose the turn server region, there is the Global region which automatically routes the traffic to the nearest turn server to the user or use can choose from a specific region as well
4. Next you can create your first turn server credential, all the turn server creds also contain stun servers in the ICE array as well
5. Click on the “Add Credential” button and optionally specify a label to the credential or click on the “click here to generate your first credential” button to create a credential
6. then click on the instructions button to get the instructions on how to use the credentials in your application
You can use both the ICE server array or the api in your webrtc application
Using API
const response =
await fetch(“https://helloworld.metered.live/api/v1/turn/credentials?apiKey=c9837191de8e5a13bdae2c1fa8cfb204d853“);
// Saving the response in the iceServers array
const iceServers = await response.json();
// Using the iceServers array in the RTCPeerConnection method
var myPeerConnection = new RTCPeerConnection({
iceServers: iceServers
});
Using ICEServer Array
iceServers: [
{
urls: “stun:stun.relay.metered.ca:80“,
},
{
urls: “turn:global.relay.metered.ca:80“,
username: “3325c6e81a4c30238a4213b9“,
credential: “taDRAoRlvjITUVe3“,
},
{
urls: “turn:global.relay.metered.ca:80?transport=tcp“,
username: “3325c6e81a4c30238a4213b9“,
credential: “taDRAoRlvjITUVe3“,
},
{
urls: “turn:global.relay.metered.ca:443“,
username: “3325c6e81a4c30238a4213b9“,
credential: “taDRAoRlvjITUVe3“,
},
{
urls: “turns:global.relay.metered.ca:443?transport=tcp“,
username: “3325c6e81a4c30238a4213b9“,
credential: “taDRAoRlvjITUVe3“,
},
],
});
Thus you can either use the ICE server array or the API to access TURN server credentials
Using the API there is a lot of stuff that you can do,
creating credentials
deleting credentials
enabling /disabling credentials
Getting usage data
Getting usage data by user
Getting usage data by date
and much more
for a complete list of what you can do refer to the documentation here: https://www.metered.ca/docs/turn-rest-api/get-credential
Thus we have learned in this article what are webrtc servers and why they are needed. We also learned how we can use webrtc servers to further our communication goals.
