What Is a Signaling Server?

A signaling server is the coordination layer that makes WebRTC possible. WebRTC is designed to connect two browsers directly (peer-to-peer), but the peers first need to find each other, exchange connection metadata, and agree on how to connect. That handshake is signaling.

The one-line answer

A signaling server is a server that relays connection-setup messages between two WebRTC peers so they can establish a direct peer-to-peer media connection. Once the direct connection is established, media (audio/video) flows peer-to-peer and the signaling server is no longer needed for that session.

Why WebRTC needs signaling

WebRTC is designed so that, once connected, audio and video flow directly between browsers without passing through a server. But to reach that point, the two browsers need to exchange three things: session descriptions (SDP offers and answers), ICE candidates (network paths), and session control messages (join, leave, mute). A browser cannot send these to another browser it has not yet connected to — that is the chicken-and-egg problem signaling solves.

The signaling server is the meeting point. Both peers connect to it (usually over WebSocket). Peer A sends an "offer" to the server; the server forwards it to Peer B. Peer B sends an "answer" back through the server. They then exchange ICE candidates the same way. Once they have enough candidates, they open a direct WebRTC connection and media flows — the signaling server steps out of the media path.

What a signaling server does

• Relays SDP offers and answers between peers
• Relays ICE candidates (network path candidates)
• Manages rooms and sessions (who is in which call)
• Tracks user presence (who is online, who joined, who left)
• Broadcasts media-state changes (mute, camera on/off)
• Cleans up sessions on disconnect

What a signaling server does NOT do

A signaling server does not touch media. Audio and video packets flow directly between peers (or through a TURN relay if NAT prevents direct connection). The signaling server only handles the connection handshake and session management. This is the key insight: signaling is cheap, media is expensive. A signaling server can handle thousands of concurrent connection setups because it only forwards small JSON messages — never audio/video frames.

What protocol does signaling use?

The WebRTC specification does not mandate a signaling protocol — it is intentionally left to the application. In practice, almost all implementations use WebSocket for real-time bidirectional messaging. Some use Socket.io, some use raw WebSocket, some use Server-Sent Events for downlink and HTTP POST for uplink. The openbnet signaling server uses raw WebSocket with JSON messages.

// Connect to a signaling server
const ws = new WebSocket('wss://openbnet.com/ss/ws?user_id=alice');

// Send an SDP offer to a specific peer
ws.send(JSON.stringify({
  type: 'direct-signal',
  payload: {
    target_user_id: 'bob',
    signal_type: 'offer',
    data: localOffer
  }
}));

// The server forwards it to Bob. Bob's client
// receives it and sends an answer back the same way.

openbnet Signaling Server

openbnet includes a production-ready signaling server as one of its six core APIs. It handles room-based session management, direct signal relay (offer/answer/ICE), media-state broadcasting, user presence tracking, and automatic cleanup on disconnect. You connect a WebSocket, send JSON messages, and the server routes them. You do not run or scale the signaling server yourself.

All guides · Explore openbnet APIs · Developer quickstarts