WebRTC signaling is the mechanism used to coordinate communication between two or more peers before a real-time media session begins. It handles the exchange of session descriptions (SDP offers and answers), ICE candidates for NAT traversal, and any application-level metadata needed to establish a WebRTC connection. The WebRTC specification intentionally leaves signaling out of scope, giving developers the freedom to choose their own transport and protocol.
What Is WebRTC Signaling?
When two browsers (or a browser and a server) want to establish a WebRTC session, they need a way to exchange connection metadata before any audio, video, or data can flow. This pre-connection negotiation process is called signaling. It typically involves three types of information:
- Session descriptions (SDP) — The offer/answer model that describes media capabilities, codecs, and connection parameters.
- ICE candidates — Network addresses and ports that peers can use to establish a direct connection through NATs and firewalls.
- Application-level messages — Custom events like join, leave, mute, or screen-share that your application needs to function.
Without signaling, peers have no way to discover each other or agree on how to communicate. Every WebRTC application — from a simple 1:1 video call to a large-scale conferencing platform — needs a signaling layer.
How WebRTC Signaling Works
The signaling flow in a typical WebRTC session follows these steps: First, the initiating peer creates an SDP offer using RTCPeerConnection.createOffer() and sets it as the local description. This offer is sent to the remote peer through the signaling channel. The remote peer receives the offer, sets it as its remote description, generates an SDP answer with RTCPeerConnection.createAnswer(), and sends it back. Simultaneously, both peers gather ICE candidates and exchange them through the same signaling channel. Once both sides have a complete set of session descriptions and ICE candidates, the direct peer-to-peer media connection is established.
The signaling server itself does not handle any media traffic. It acts purely as a relay for the metadata exchange. Once the peer-to-peer connection is up, the signaling channel can remain open for renegotiation or be closed.
Signaling Transport Protocols
Since WebRTC does not mandate a specific transport for signaling, developers choose based on their application requirements. The three most common transports for browser-based applications are:
XHR (XMLHttpRequest) — Uses HTTP polling or long-polling to exchange messages between the client and signaling server. Simple to implement but adds latency due to the request-response cycle. Best suited for low-frequency signaling scenarios.
SSE (Server-Sent Events) — A one-way channel from server to client over HTTP. Often paired with XHR or fetch for client-to-server messages. Provides lower latency than polling while remaining simpler than WebSocket.
WebSocket — A full-duplex, persistent connection between client and server. The most popular choice for WebRTC signaling because it provides low latency, bidirectional communication, and efficient message framing. Most production WebRTC applications use WebSocket for signaling.
It is also possible to combine transports — for example, using WebSocket for the primary signaling flow and falling back to XHR polling for environments where WebSocket is blocked.
Signaling Protocols for WebRTC
On top of the transport layer, you need a signaling protocol that defines the message format and state machine for session negotiation. The most common choices are:
Proprietary / Custom Protocol — Many WebRTC applications use a custom JSON-based signaling protocol tailored to their specific use case. This is the most flexible approach and the most common in practice. You define your own message types (offer, answer, ice-candidate, join, leave, etc.) and handle them in your application logic.
SIP (Session Initiation Protocol) — A well-established protocol from the telecom world, typically run over WebSocket for browser-based applications (SIP over WebSocket). SIP is a strong choice when interoperating with existing VoIP or telephony infrastructure.
XMPP/Jingle — The Extensible Messaging and Presence Protocol with its Jingle extension provides a standardized way to negotiate peer-to-peer sessions. It is well suited for applications that already use XMPP for messaging and presence.
MQTT — A lightweight publish/subscribe messaging protocol originally designed for IoT. MQTT is gaining traction for WebRTC signaling in scenarios with constrained devices or where a pub/sub architecture is already in place.
How to Choose a Signaling Protocol
The right signaling protocol depends on your use case. If you are building a greenfield WebRTC application with no legacy requirements, a custom JSON-based protocol over WebSocket is the simplest and most flexible option. If you need to interoperate with existing telecom infrastructure, SIP is the natural choice. For applications built on an XMPP messaging backbone, Jingle makes sense. And for IoT or edge computing scenarios, MQTT offers a lightweight alternative.
For a deeper comparison, read our guide: How to Select a Signaling Protocol for Your Next WebRTC Project.
Related WebRTC Concepts
Signaling is closely related to several other WebRTC concepts. Understanding the difference between signaling and transport protocols is fundamental. Once signaling is complete, the actual media is typically routed through a TURN server or an SFU (Selective Forwarding Unit) for group calls. For production deployments, you will also want to understand NAT traversal with ICE, STUN, and TURN.
