What is WebRTC Signalling? Signalling is how computers discover other computers to connect to using WebRTC. If you're wondering how WebRTC signalling works, it starts with one client sharing its connection data with another through a signalling server.
Table of contents
WebRTC is an open-source project owned and maintained by Google that much of the internet’s peer-to-peer applications are built.
While WebRTC as a project is open source and can be audited by the public, this does not automatically make every application that uses WebRTC open-source; since the implementation of connection management is left up to the application developer, this makes not every WebRTC signalling server open source.
A peer-to-peer application is one where users’ computers talk directly to each other rather than through a central server. This saves immensely on server infrastructure resources and is a very efficient way for features like real-time video and voice to make it into your favourite internet applications.
The tricky thing for a non-developer or junior developer to understand about WebRTC is that central application servers do play a role, making WebRTC not completely peer-to-peer, while the connections that WebRTC makes are peer-to-peer.
This approach saves immensely on server infrastructure resources and remains one of the most efficient ways to deliver real-time video and voice in modern peer-to-peer WebRTC applications.
To put it plainly, signalling in WebRTC is how computers discover other computers to connect with. WebRTC relies on signalling servers in order to establish connections between peers.
WebRTC leaves it up to the developer to determine which connections get made between peers, and so the process of who connects to who happens on the signalling server, as part of the WebRTC application.
The signalling server determines which computers (clients) get connected to each other, and the procedure by which clients get connected is standardised under WebRTC.
However, the clients themselves are completely unable to connect to each other without having a central signalling server make the connection.
Think of a WebRTC signalling server as a sort of matchmaker.
It’s important to note that WebRTC signalling servers only handle metadata or data about clients.
The signalling server itself does not handle the data streams directly as that is done between the peers. The signalling server handles information like:
Here's a simple WebRTC signalling server example using Node.js and WebSockets. It demonstrates how basic signalling exchanges are handled between two clients — and serves as one of the best WebRTC signalling server examples for beginners.
These are the kinds of things that two connections need to know before they connect. Following our match-maker analogy, this is a little bit like setting up a blind date.
The process that entails signalling in WebRTC is conceptually fairly simple, but the WebRTC signalling protocol actually has quite a bit going on under the hood.
Let’s say that a client wants to use a web app that uses WebRTC; it starts out by sending an offer to that web app's WebRTC signalling server.
It doesn’t matter if the web app has a WebRTC signalling server nodejs implementation, or if it’s implemented in any other framework using other technologies like PHP; the offer is basically only information about that client and some information about how to connect to it.
This initial step forms part of the WebRTC handshake, where peers begin exchanging information using Session Description Protocol (SDP) via the signalling server.
This offer forms the foundation of the WebRTC connection setup, enabling devices to begin a direct peer-to-peer negotiation.
So the signalling server now has the information of at least one client and how to connect to said client.
The signalling server now only needs to pair two or more clients together by exchanging these Session Description Protocol (SDP) offers, and, if the clients accept the offers, they will have all the information they need in order to exchange data directly peer-to-peer.
This initial step forms part of the WebRTC handshake, where peers begin exchanging information using Session Description Protocol (SDP). Curious as to what SDP is in WebRTC? It’s a format used to describe multimedia communication sessions.
To do this, it sends the SDP offer of the first client to potential peers, and when the peer or peers get the initial SDP offer, they store that information locally, generate their own offer containing their information, and send that to the signalling server, who distributes that information back down to the initial client – or as many other clients which want to connect to one another.
Once every client has the SDP offers of all other connecting clients to one another, they can begin to connect peer-to-peer, without the use of any servers!
At this point, the clients know the list of other clients to connect to, but they need a plan for how they will connect.
Not so fast! In the real world, some computers (clients) have firewalls or NATs that prevent their IP addresses from being exposed publicly. This means that the broader internet cannot directly communicate with that computer.
This a serious problem for peer-to-peer applications! How does WebRTC handle these kinds of cases?
If you're building a custom peer-to-peer app, you'll need a signalling server to handle SDP exchanges and NAT traversal. WebRTC doesn’t come with built-in signalling, so you’ll have to set one up using Node.js, WebSockets, or a third-party CPaaS platform like Digital Samba. This simplifies your WebRTC connection setup and helps ensure stable peer-to-peer communication, even in complex network environments.
In a nutshell
ICE stands for Interactive Connectivity Establishment. Think of it as basically meaning “What’s the best way for these clients to connect to each other?”, and STUN and TURN servers are assisting in making these connections happen. STUN is a simple service which provides the public IP of the client as a response.
Clients need to use STUN because they are often behind NAT and they have no idea what their public address is. Mutual communication over the internet cannot be established without knowing each other’s public IP addresses.
Unfortunately, in some cases even knowing each other’s public IP addresses is not enough - symmetric NAT is one such case. For these, WebRTC applications usually have TURN servers as fallbacks to hopefully route around the firewall/NAT of some clients.
When addressing specifically how clients address each other over the network (as in not including media and configuration data like codecs, access to microphone and camera, etc), there are two other servers that come into play. STUN and TURN.
STUN servers are low-latency and handle direct network addressing information between peers. Since they only have this very light-duty task to do, they are preferred as there are very few hardware requirements to run STUN servers. Think of small pings of public-facing dynamic IP addresses between peers for the WebRTC application service to run.
In some cases, these are separate, discrete hardware servers that run in order to handle this part of WebRTC – but due to their low resource requirements, they may be hosted by the same service provider or even on the same hardware as the signalling server itself.
The problem with STUN is that it’s reliant on clear and open public-facing IP network addresses for every peer. Not every peer has that enabled as they may sit behind firewalls or use a NAT configuration that makes them unaddressable directly for WebRTC applications. In these cases, the restrictive NAT or firewall needs to be bypassed or routed around.
TURN servers are typically a fallback method if STUN servers can’t establish a direct connection between all the peers. TURN servers are typically publicly registered and whitelisted third-party servers that NATs and firewalls may accept connections from– but they do have to actually handle forwarding the media streams between the peers.
The handling of this raw data through a TURN server puts additional network bandwidth and cost requirements on the server infrastructure, and it also introduces more latency.
TURN is a fallback method that is preferred to be avoided, but it’s usually a better alternative than no connection at all. Also, it’s not a guarantee that any given firewall or NAT configuration will allow all TURN servers, so it’s up to ICE to look at all possible connection routes and choose the most efficient one.
You can read more in our article STUN vs TURN explained — which breaks down their differences with visuals and use cases.
There is a name for the list of possible connections that each peer can use, and it is called the ICE candidates.
WebRTC is complicated for developers to work with entirely because it functions essentially as a compatibility layer for web browsers to talk to each other, dating back to Web 2.0.
The general trend is that WebRTC will be moved to more of a back-end technology that API services make use of in order to provide Communication Platforms as a Service (CPaaS) to developers.
Utilising these third-party APIs eliminates a huge amount of complexity, security issues, and infrastructure deployment costs for web application developers while also typically providing a much more polished suite of features to their customers that have already been debugged and supported by software engineers who specialise in this specific field of things like live video and audio, peer-to-peer real-time features such as group drawing applications, and much more.
Best of all, these APIs can extend the functionality of these polished and supported feature suites to arbitrary API endpoints, such as web pages, mobile applications, or even third-party software for feature integration purposes.
| Pros | Cons |
|---|---|
| Enables peer-to-peer connections | Complex to implement manually |
| Reduces server load and costs | Requires handling of NAT/firewall issues |
| Open standard with browser support | Needs TURN/STUN servers for fallback |
| High customisability | Security and privacy are the developer’s job |
WebRTC signalling is the essential behind-the-scenes process that powers peer-to-peer connections — but building it from scratch can be complex and resource-intensive.
To simplify development and ensure compliance with European privacy laws, we recommend using an EU-hosted, secure platform like Digital Samba.
Ready to embed video into your app? Try Digital Samba for free or contact us for a personalised demo.
Learn more about Digital Samba’s video API or check out our blog on STUN vs TURN servers.
Yes, even though WebRTC supports peer-to-peer communication, a signalling server is always needed to establish the connection.
STUN helps clients discover their public IP address, while TURN relays traffic when direct connections fail.
Yes, using tools like Node.js and WebSocket libraries. There are many tutorials and open-source examples available.
If the signalling exchange doesn’t succeed, clients cannot connect — no video or data can be shared.
It’s the negotiation phase where peers exchange SDP offers via a signalling server to establish a connection.