List of Free Stun and Turn Servers | Open Relay Project

What is a Turn Server?

WebRTC Applications require a server to function for tasks like relaying traffic between peer devices, this is because if the devices are on different networks (As is the case most of the time), a direct socket connection is not possible

The common way to solve this is a TURN server (Traversal Relay NAT) and it is a protocol for relaying traffic.

There are currently several options for TURN servers available online, one of the reliable and free option is the https://openrelayproject.org

Open Relay Project: Free Publicly available TURN Servers?

Provides a free, production ready TURN server to the public.

In the TURN server you need the RTCConfiguration for your client application to use it.

The code snippet below illustrates a sample config for a RTCPeerConnection where server we are using is a free server from the https://openrelayproject.org and the hostnamewe have is openrelay.metered.ca:80 and it is running on port 80.

The configuration object accepts a username nad credentials for secure access to the server.

The OpenRelayProject has provided us with the credentials:

username: "openrelayproject",
credential: "openrelayproject"

const iceConfiguration = {
    iceServers: [
        {
            urls: 'turn:openrelay.metered.ca:80',
            username: 'openrelayproject',
            credentials: 'openrelayproject'
        }
    ]
}

const peerConnection = new RTCPeerConnection(iceConfiguration);

Public Turn Stun Server list

If you need a Public Stun Turn server, the Open Relay project is the Only available free production ready service there is.

You can use the Open relay project in any webRTC application that you are building.

Here are some of the features of the Open Relay Project:
Runs on port 80 and 443

Tested to bypass most firewall rules
Enterprise grade reliability (99.999% uptime)
Support TURNS + SSL to allow connections through deep packet inspection firewalls.
Support STUN
Supports both TCP and UDP
Dynamic routing to the nearest server
Production Ready

What is a STUN Server?

STUN is a set of methods, and a network protocol for transversal of NAT gateways to relay traffic.

STUN is used by other protocols as well such as ICE and SIP and WebRTC.

It lets host devices to discover the presence of NAT and find out the public IP and port number that the NAT has allocated to the UDP to remote hosts.

This protocol requires assistance from a STUN server located in the opposite side of NAT.

Open Relay Project also provides STUN servers along with the Turn servers

STUN is not a self sufficient NAT transversal solution in all the scenarios.

STUN works along with other methods in NAT Transversal most notably TURN Traversal Using Relay NAT and Interactive Connectivity Establishment ICE

STUN works with three types of NAT: full cone NAT, restricted cone NAT and port restricted cone NAT.

STUN does not work with symmetric NAT which is found in most organizations and large enterprises as well as large networks.

This is because the IP address of the STUN server is different from that of the endpoint. In this case TURN server is required.

What is WebRTC?

WebRTC is a technology that enable web applications to exchange video, audio and other data across the internet using a standared set of protocols

Using WebRTC web browsers can also exchange arbitary data without requiring an intermediary.

The set of standards of WebRTC enables people to do video conferencing and data transfers across the web without installing any software.

WebRTC consists of several interconnected protocols which work together to achieve this

What is Signalling?

WebRTC specification includes APIs for communicating with other servers and devices using the ICE Internet Connectivity Establishment Server, but it does not include a way to signal the server.

Signalling is not a part of the WebRTC API and Signalling is required in order to exchange information between devices as to how to connect each other

Signalling can be implemented in many different ways and WebRTC specification does not prefer any single way.

example code for Signalling

const signalingWay = SignalingChannel(remoteClientId);


signalingWay.addEventListner('message', message => {
     cosole.log('message recieved from client', message)
})

Conclusion

If you are building a webRTC application a central requirement is of having a TURN server.

You can creatre your own TURN server but that is expensive and requires a lot of effort

You can also consider OpenRelayProject.Org they provide a free TURN server that is production ready