WebRTC Server: What Is It and Why You Need One?

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

1. 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

2. 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

3. 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.

4. 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

1. 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

2. 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

3. 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

1. STUN server

2. TURN server

3. 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

1. Signalling Phase

2. 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

Metered TURN servers

1. 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.

2. 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

3. Servers in 12 Regions of the world: Toronto, Miami, San Francisco, Amsterdam, London, Frankfurt, Bangalore, Singapore,Sydney, Seoul

4. Low Latency: less than 50 ms latency, anywhere across the world.

5. Cost-Effective: pay-as-you-go pricing with bandwidth and volume discounts available.

6. Easy Administration: Get usage logs, emails when accounts reach threshold limits, billing records and email and phone support.

7. Standards Compliant: Conforms to RFCs 5389, 5769, 5780, 5766, 6062, 6156, 5245, 5768, 6336, 6544, 5928 over UDP, TCP, TLS, and DTLS.

8. Multi‑Tenancy: Create multiple credentials and separate the usage by customer, or different apps. Get Usage logs, billing records and threshold alerts.

9. Enterprise Reliability: 99.999% Uptime with SLA.

10. Enterprise Scale: With no limit on concurrent traffic or total traffic. Metered TURN Servers provide Enterprise Scalability

11. 5 GB/mo Free: Get 5 GB every month free TURN server usage with the Free Plan

12. Runs on port 80 and 443

13. Support TURNS + SSL to allow connections through deep packet inspection firewalls.

14. Support STUN

15. Supports both TCP and UDP

16. Free Unlimited STUN

Setting Up Metered.ca Server: A Step by Step guide

Account Creating and initial setup

1. go to metered.ca/stun-turn website and create an account by clicking on the "Get Started" Button

2. 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

// Calling the REST API TO fetch the TURN Server Credentials
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

var myPeerConnection = new RTCPeerConnection({
  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.