What a WebRTC signaling server does, explained simply: the offer and answer, finding a network path, STUN and TURN, WHIP and WHEP, and why it matters for live CCTV.
A WebRTC signaling server makes the introduction: it passes the offer, the answer and the possible network routes so two endpoints can connect directly. Once video flows, it steps aside.
WebRTC deliberately leaves signaling undefined. Every system must supply its own, usually over WebSocket.
Signaling, STUN, ICE and TURN are four different jobs: introduce, discover your address, choose the route, and relay only when nothing direct works.
WHIP and WHEP standardise signaling for live streaming, bringing true plug and play.
Because the signaling server never touches the video, WebRTC is ideal for fast, private, on premise live view.
A WebRTC signaling server is the intermediary that lets two WebRTC endpoints swap the details they need to connect directly. It passes messages back and forth until both sides know enough to connect. Then it steps out of the way, and the audio, video or data flows straight between the endpoints.
The thing to understand first is that WebRTC, by design, does not say how signaling should work. The W3C standard defines the browser features and the video transport, and the IETF defines the underlying security, but the introduction is left to each application. This is the single biggest source of confusion for teams building their first live video system. WebRTC gives you everything except the part that introduces the two sides. You supply that.
So a signaling server is not an optional extra. Without one, no WebRTC connection can form at all.
WebRTC (Web Real-Time Communication) is an open standard for live audio, video and data between browsers, apps and servers. It is what lets a video call run in a browser tab with nothing to install, and it is what lets a live camera feed reach a viewer in well under a second.
It needs signaling because of a simple problem. Two devices that want to connect are almost never on the open internet with fixed addresses. They sit behind routers and firewalls. Before sending video, each must answer two questions: "What can you receive?" and "Where can I reach you?" The first is about formats and quality. The second is about network routes. Signaling is the conversation that answers both.
Here is the sequence for a basic connection between a caller and a callee.
The offer. The caller writes an "offer": a short document, in a format called SDP (Session Description Protocol), listing the video and audio it wants to send and receive and the formats it supports. The signaling server passes it to the callee.
The answer. The callee decides what it can support and writes an "answer" in the same format, which travels back through the signaling server. Now both sides agree on what the session will carry.
The routes. At the same time, each side collects possible routes by which the other might reach it, such as a local address or a public one. Each route, called a "candidate", is sent to the other side through the signaling server. This process is called ICE (Interactive Connectivity Establishment).
The connection. Once enough candidates are swapped, ICE tests the routes and picks one that works. The direct connection opens, video starts flowing, and the signaling server is no longer involved.
On a healthy network this takes a fraction of a second. The signaling server only ever sees the setup messages, never the video, which matters for both privacy and scale.
Most explanations blur these together. Here they are, separated.
Signaling: the exchange of session details and routes between the two sides. Defined by the application and carried by your signaling server.
STUN (Session Traversal Utilities for NAT): a lightweight helper a device contacts to learn its own public address, so it can offer that address as a route. It is not the signaling server and carries no video.
TURN (Traversal Using Relays around NAT): a fallback for when a direct route is impossible, such as behind strict corporate firewalls. A TURN server relays the actual video. It costs more to run because it carries real traffic, and it is used only when direct connection fails.
ICE: the process that ties it together, gathering every possible route (direct, STUN discovered and TURN relayed) and testing them to pick the best one that works.
In short: signaling introduces, STUN discovers, ICE chooses and TURN relays only when nothing else works. A production WebRTC system needs a signaling server plus access to STUN and TURN.
Because WebRTC leaves signaling open, teams choose. The most common choice is a WebSocket connection: two way, fast, and friendly to browsers and firewalls, usually carrying simple text messages. Systems that must work with telephone networks often use SIP. Simple applications sometimes send the first offer in an ordinary HTTPS request.
That freedom cuts both ways. WebRTC fits almost any architecture, but there is no shared default, so two independently built WebRTC systems usually cannot talk to each other without first agreeing a signaling scheme. WHIP and WHEP were created to close exactly that gap.
For one to one calls, custom signaling is manageable. For streaming, where one source is published and then delivered to many viewers, the lack of a standard was a real obstacle. Two IETF standards fix it.
WHIP (WebRTC HTTP Ingestion Protocol) standardises how a source, such as an encoder or camera, starts sending a WebRTC stream to a server, using one simple web request to carry the offer and answer.
WHEP (WebRTC HTTP Egress Protocol) does the reverse for playback: it standardises how a viewer starts receiving a stream.
Together they make WebRTC streaming close to plug and play. An encoder that speaks WHIP can publish to any WHIP server, and a player that speaks WHEP can play from any WHEP server, with no custom signaling. That brings WebRTC up to the interoperability that RTSP and RTMP have long offered.
For a two person call, signaling is a setup detail. For live video at scale, it shapes what the whole system can do.
Teams choose WebRTC for speed. Traditional streaming over HLS or MPEG-DASH holds several seconds of video in reserve, which is fine for films but poor for anything live. WebRTC can deliver video from camera to screen in under a second. In security, that is the difference between watching something happen and reviewing it afterwards. Multi second delay, typical of the HLS based cloud viewing many cloud surveillance services rely on, is a real limitation for live monitoring.
Signaling design also matters for privacy and scale. Because the signaling server handles only setup and never sees the video, it stays lightweight and keeps footage out of its hands, which suits on premise and air gapped sites where video must never leave the building. And because video flows directly or through a dedicated media server, signaling never becomes the bottleneck as camera counts grow.
Forgetting TURN. A demo works perfectly at home, then fails for a real user behind a corporate firewall because no relay was set up for when a direct route is impossible.
Treating signaling as an afterthought. Teams bolt on the simplest signaling possible, then struggle when they need reconnection, sign in and scale.
Neglecting security. WebRTC video is always encrypted, but the signaling channel is your responsibility. It must run over a secure connection with proper authentication, or it becomes the weak point.
Visylix is an automated AI video surveillance platform built in India, and live view is where operators feel the difference. Visylix supports WebRTC natively in its own streaming engine, alongside 12 more protocols, including standard WHIP publishing and WHEP playback. Live view arrives in under a second over WebRTC, down to under 200 ms, so operators see events as they happen, not seconds later.
Because Visylix runs on your own infrastructure, both signaling and video stay inside your network, ideal for on premise, edge and fully air gapped sites. Visylix is web first: live view runs in any modern browser with nothing to install at the desk.
Speed matters most when AI is watching. Visylix runs 22 AI analytics built in house, and when one raises an alert, Sudarshan automation can notify the right team, raise an alarm incident in the operator console or talk down an intruder through the camera speaker, while the operator watches it unfold live, in real time, on a wall of up to 36 tiles.
WebRTC is an open standard anyone can use. What decides whether its speed shows up in a real control room is how a platform handles signaling, video and deployment. That is where Visylix was built to excel.
A WebRTC signaling server is the intermediary that passes connection details between two WebRTC endpoints so they can connect directly. It carries the "offer" and "answer" (what each side can send and receive) and the possible network routes. Once the direct connection is open, the video flows between the endpoints, not through the signaling server.
Yes. WebRTC deliberately does not define how two endpoints find each other or agree a session, so some signaling channel is always needed. Only the video itself travels directly between the endpoints once signaling is complete.
WebRTC leaves it to the application. The most common choice is a WebSocket connection carrying simple messages, because it is two way and fast. Some systems use SIP to work with telephone networks, and simple cases can use plain HTTPS. The WHIP and WHEP standards define a simple web based exchange specifically for publishing and playing live streams.
Signaling is the exchange of session details between the two sides, carried by your signaling server. STUN is a helper that tells a device its own public address. TURN relays the actual video when a direct connection is impossible. ICE is the process that gathers and tests the possible routes. Four separate parts, four separate jobs.
The video is peer to peer whenever a direct route exists; the signaling server only makes the introduction. Where a direct route is impossible, a TURN server relays the video, so the connection is no longer strictly peer to peer. The signaling server never carries video in either case.
WebRTC was built for live conversation, so it keeps buffering to a minimum and can deliver video in under a second. HLS and MPEG-DASH hold several seconds of video in reserve to guarantee smooth playback, which suits on demand viewing but adds delay that is poorly suited to live monitoring. That is why serious live video platforms use WebRTC for live view.