What a WebRTC signaling server does: the SDP offer and answer, the ICE candidate exchange, how STUN and TURN differ, plus WHIP and WHEP for streaming.
A WebRTC signaling server relays the initial session information, the SDP offer and answer and the ICE candidates, so two endpoints can find each other and negotiate a direct connection. Once media flows, the signaling server is out of the path.
WebRTC deliberately does not define the signaling protocol. Every deployment must supply one, most commonly over WebSocket, and there is no interoperable default.
Signaling, STUN, ICE, and TURN are four different jobs. Signaling introduces the peers, STUN helps a peer learn its public address, ICE selects the working path, and TURN relays media only when no direct path exists.
WHIP and WHEP standardize WebRTC signaling for streaming ingest and playback, bringing plug-and-play interoperability that custom signaling never offered.
Because the signaling server never touches the media, WebRTC suits low-latency, privacy-sensitive, and on-premise video, where sub-second live view is the practical goal.
A WebRTC signaling server is the intermediary that lets two WebRTC endpoints exchange the connection information they need to establish a direct peer connection. It relays session descriptions and network candidates between the two sides until they have enough information to connect. Once the direct media path is open, the signaling server steps out of the way and the audio, video, or data flows between the endpoints, not through the server.
The important thing to understand up front is that WebRTC, by design, does not specify how signaling should work. The W3C WebRTC specification defines the browser APIs and the media transport, and the IETF defines the underlying transport and security, but the signaling channel is left to the application. That is a deliberate choice, and it is the single most common source of confusion for people building their first real-time application. WebRTC gives you everything except the part that introduces the two peers to each other. You have to supply that yourself.
So a signaling server is not an optional performance add-on. Without one, two WebRTC endpoints have no way to discover each other or negotiate a session, and no connection can form at all.
WebRTC, short for Web Real-Time Communication, is an open standard that enables real-time audio, video, and data exchange directly between endpoints such as browsers, mobile apps, and servers. It is what allows a video call to run inside a browser tab with no plugin, and it is increasingly what allows a live camera feed to reach a viewer in well under a second.
The reason WebRTC needs signaling comes down to a simple problem. Two devices that want to connect are almost never sitting on the open internet with fixed, publicly reachable addresses. They are behind routers, firewalls, and network address translation. Before they can send media to each other, they each need to answer two questions. What can you receive, and where can I reach you? The first question is about media capabilities, such as which codecs and resolutions each side supports. The second is about network reachability, such as which IP addresses and ports might work. Signaling is the conversation that answers both.
The signaling exchange is often described in the abstract, so here is the concrete sequence for a basic connection between two peers, which we will call the caller and the callee.
First, the caller creates an offer. This offer is a Session Description Protocol document, usually just called SDP, that lists the media the caller wants to send and receive and the codecs it supports. The caller sends this offer to the signaling server, which relays it to the callee.
Second, the callee receives the offer, decides what it can support, and creates an answer. The answer is another SDP document describing the agreed media. The callee sends the answer back through the signaling server to the caller. At this point both sides know what media the session will carry. This is the offer and answer exchange.
Third, in parallel, each side gathers network candidates. A candidate is a possible route by which the other side might reach it, such as a local network address or a public address discovered through a helper server. As each candidate is found, it is sent to the other peer through the signaling server. This is the ICE candidate exchange, named for Interactive Connectivity Establishment, the IETF framework that governs it.
Fourth, once the two sides have exchanged enough candidates, ICE tests the possible paths and selects one that works. The direct peer connection forms, media begins to flow, and the signaling server is no longer in the media path.
The whole exchange usually takes a fraction of a second on a healthy network. The signaling server touches only the setup messages, never the media itself, which is a key point for both privacy and scale.
This is where most explanations blur together, so it is worth separating the roles cleanly.
Signaling is the exchange of session descriptions and candidates between the two peers. It is application-defined and it is what your signaling server carries.
STUN, short for Session Traversal Utilities for NAT, is a lightweight helper that lets an endpoint discover its own public-facing address so it can offer that address as a candidate. A STUN server is contacted by the endpoint directly. It is not the signaling server, and it does not relay media.
TURN, short for Traversal Using Relays around NAT, is a fallback for the cases where a direct peer-to-peer path cannot be established, which happens with strict corporate firewalls and some carrier networks. A TURN server relays the actual media on behalf of the peers. It is more expensive to run because it carries real traffic, and it is used only when a direct connection fails.
ICE is the framework that ties STUN and TURN together. It gathers all the candidate paths, including direct, STUN-discovered, and TURN-relayed, and systematically tests them to pick the best one that works.
The clean way to hold these apart: signaling introduces the peers, STUN helps a peer learn its own address, ICE picks the working path, and TURN relays media only when nothing direct is possible. A production WebRTC deployment typically needs a signaling server and access to STUN and TURN, and they are different components with different jobs.
Because WebRTC leaves signaling undefined, teams are free to choose. In practice, the most common transport is a WebSocket connection, because it is bidirectional, low latency, and works cleanly through browsers and firewalls. Some systems layer a messaging format such as JSON on top. Others reuse established session protocols such as SIP, which is common where WebRTC has to interoperate with existing telephony. Simple applications sometimes even exchange the initial offer through an ordinary HTTPS request.
There is no single correct answer, and that flexibility is a double-edged sword. It means WebRTC fits into almost any architecture, and it also means there is no interoperable default, so two independently built WebRTC systems will usually not talk to each other without agreeing on a signaling scheme first. That interoperability gap is exactly the problem that WHIP and WHEP were created to solve.
For one-to-one calls, custom signaling is manageable. For streaming, where one source is ingested and then delivered to many viewers, the lack of a standard signaling method was a real obstacle. Two IETF specifications now address this.
WHIP, the WebRTC HTTP Ingestion Protocol, standardizes how a media source establishes a WebRTC session with a server for ingest. It uses a single, simple HTTP exchange to carry the SDP offer and answer, which means an encoder or camera can start a WebRTC stream without a bespoke signaling implementation.
WHEP, the WebRTC HTTP Egress Protocol, does the mirror image for playback. It standardizes how a viewer establishes a WebRTC session to receive a stream, again using a simple HTTP-based signaling exchange.
Together, WHIP and WHEP turn WebRTC signaling for streaming into something close to plug and play. An encoder that speaks WHIP can publish to any server that speaks WHIP, and a player that speaks WHEP can subscribe to any server that speaks WHEP, without either side hand-rolling a signaling protocol. For live video platforms, this standardization is a significant step, because it brings WebRTC ingest and playback into line with the interoperability that older protocols such as RTSP and RTMP have long offered.
For a two-person call, signaling is a setup detail. For live video at scale, the signaling architecture shapes what the whole system can do.
The reason people reach for WebRTC in video is latency. Traditional streaming over HLS or MPEG-DASH buffers several seconds of video to deliver smoothly, which is fine for on-demand viewing but poor for anything interactive or operational. WebRTC was built for conversational latency, which means the delay from capture to display can be under a second. For video surveillance, that difference is the gap between watching something happen and reviewing it after the fact. Multi-second latency, typical of the HLS-based cloud viewing that many video-surveillance-as-a-service products rely on, is a genuine limitation for live monitoring.
Signaling is what makes that low-latency path possible, and its design has real consequences. Because the signaling server only handles setup and never the media, it can be lightweight and it never sees the video content, which matters for privacy and for on-premise and air-gapped deployments where video must never leave the building. And because the media flows peer to peer or through a purpose-built media server rather than through the signaling layer, the signaling server is not the bottleneck when stream counts grow.
A few issues catch almost every team building with WebRTC for the first time.
Forgetting TURN is the classic one. A demo works perfectly on a home network, then fails for a real user behind a corporate firewall, because no TURN relay was provisioned for the cases where a direct path is impossible.
Treating signaling as an afterthought is another. Because WebRTC does not provide it, some teams bolt on the simplest possible signaling and then struggle when they need reconnection, authentication, or scale.
Underestimating security is a third. The media in WebRTC is always encrypted, but the signaling channel is your responsibility, and it carries the session setup. It needs to run over a secure transport and it needs authentication, or it becomes the weak point.
Visylix supports WebRTC natively as one of more than a dozen streaming protocols in its first-party engine, including standardized WHIP ingest and WHEP playback. Live view uses WebRTC to deliver sub-second latency in internal testing, with a published benchmark planned, so operators watch events as they happen rather than several seconds late.
Because Visylix runs as software on the customer own infrastructure, the signaling and media paths stay inside the customer environment, which suits on-premise, edge, and air-gapped deployments where video cannot leave the premises. The point of mentioning this is not that WebRTC is unique to Visylix, since it is an open standard available to anyone, but that how a platform implements signaling, media handling, and deployment topology is what determines whether the theoretical low latency of WebRTC actually shows up in an operational surveillance environment.
A WebRTC signaling server is the intermediary that relays connection information, specifically the SDP offer and answer and the ICE network candidates, between two WebRTC endpoints so they can establish a direct peer connection. It handles only the setup messages. Once the direct media path is open, the audio and video flow between the endpoints, not through the signaling server.
Yes. WebRTC does not define a signaling mechanism of its own, so two endpoints have no built-in way to discover each other or negotiate a session. A signaling server, or at least some signaling channel, is required for any WebRTC connection to form. Only the media itself travels peer to peer once signaling is complete.
WebRTC leaves this to the application. The most common choice is a WebSocket connection carrying a simple JSON message format, because it is bidirectional and low latency. Some systems use SIP for telephony interoperability, and simple cases can even use plain HTTPS. The WHIP and WHEP specifications standardize an HTTP-based signaling exchange specifically for streaming ingest and playback.
Signaling is the exchange of session descriptions and candidates between peers and is carried by your signaling server. STUN is a helper that lets an endpoint discover its own public address. TURN relays the actual media when a direct connection cannot be established. ICE is the framework that gathers and tests candidate paths. They are separate components with separate roles.
The media in WebRTC is peer to peer whenever a direct path can be established, and the signaling server only handles the initial introduction, not the media. In networks where a direct path is impossible, a TURN server relays the media, so the connection is no longer strictly peer to peer. The signaling server itself never carries media in either case.
WebRTC was designed for conversational, real-time communication, so it minimizes buffering and can deliver video with sub-second latency. HLS and MPEG-DASH buffer several seconds of video to guarantee smooth playback, which suits on-demand viewing but adds delay that is poorly suited to live monitoring. This is why real-time video systems favor WebRTC for live view.