WebRTC Signaling Servers: Everything You Need to Know

Before WebRTC signaling server, let’s briefly explain what WebRTC is. WebRTC stands for web real-time communications. It is a powerful technology and an open-source streaming protocol.

WebRTC is HTML5 compatible and it allows you to add real-time communications to your apps to directly communicate between browsers and devices. You can do that without any plugins. It is supported by all major browsers including Safari, Google Chrome, Firefox, and Opera.

I’m sure you’ve heard of WebRTC being used as a peer-to-peer. However, it is also used in WebRTC N2N (multicast or multi-viewer) use cases with media servers such as Ant Media Server. Let’s go over the WebRTC signaling server now.

What is WebRTC Signaling?

WebRTC signaling is a  process of setting up, controlling, and terminating a communication session between peers. In order for two peers to begin connecting to one another, three types of information must be exchanged:

• Session control information determines when to initialize, close, and modify communications sessions. It can be also used in error reporting.
• Network Data reveals where endpoints are located on the Internet (IP address and port) so callers(1. peer) can find callees(2. peer).
• Media Data is required to determine the codecs and media types that the callers and callees have in common. If endpoints attempting to start a communications session have different resolutions and codec configurations, then a successful conversation is unlikely. Signaling that exchanges media configuration information between peers occurs by using an offer and answer in the Session Description Protocol (SDP) format.

What is a WebRTC Server?

A server that provides the functionality required for the proper connection of WebRTC sessions in the cloud or self-hosting in order to make your WebRTC projects work is called a “WebRTC server”.

4 types of WebRTC Servers: 

1. WebRTC application servers
2. WebRTC signaling servers 
3. NAT traversal servers for WebRTC
4. WebRTC media servers

What Is a WebRTC Signaling Server?

A WebRTC signaling server is responsible only for signaling. It:

• Helps peers discover one another.
• Relays SDP offers/answers and ICE candidates.
• Resets or tears down sessions when needed.

Common transports:

• WebSocket – bidirectional, full‑duplex, stays open.
• HTTP long‑polling / HTTP streaming – periodic or continuous requests; simpler to deploy but less efficient.
• SIP over WebSocket – uses SIP messages on top of a WebSocket channel.

Signaling itself is not standardized by WebRTC; any protocol that can relay text or JSON will work.

How Does WebRTC Signaling Work?

The WebRTC signaling server in the diagram helps two peers find and connect to each other. Both peers are linked to that WebRTC signaling server. You may also be connecting in this way while video chatting with your spouse or making some banking works using video communication with your bank.

A and B are connected to the WebRTC signaling server via a  WebSocket connection or sequential HTTP requests.

The communication between A and the WebRTC signaling server is called the offer-answer mechanism, which is part of WebRTC. These messages are SDP messages, not WebRTC. What happens here is that WebRTC creates SDP blobs. These are bits of messages that the peer needs to signal to the other peer in order to connect to a session. It can be done using a WebRTC signaling server.

The connection between peer A and peer B in the diagram is established to send media directly between devices. To get there, peers must first communicate via the WebRTC signal server.

There is no standard signaling protocol for transferring offers and answers. Some commonly used signaling mechanisms:

Long-polling: Web applications, which are using live content, must get events to refresh their state. Unfortunately, servers without browser requests or WebSocket connections cannot update web pages. Long polling which is a Comet like mechanism makes requests to the server in an interval to get events.

HTTP Streaming: The streaming mechanism is a kind of long polling that keeps the connection open indefinitely. Even if an event is transmitted to the client, the connection will not be closed. While this mechanism solves some issues of long polling, it has its own issues. HTTP streaming will not work with some network intermediaries such as some proxies or gateways because intermediaries cache the answer before sending it to the client. In addition, client buffering and framing techniques can be listed as other issues of it.

Sip over WebSocket: In web-based applications usually, two-way communication is enabled by WebSockets. This bidirectional and full-duplex connection starts with the HTTP/HTTPS protocol and upgrades this protocol to WebSocket during the client and server’s handshake. Over this connection text and binary data can be transferred in full-duplex mode. Since the minimum data frame size is two bytes, this connection technique does not consume network traffic when it is idle. Therefore, using specially formatted data can do signaling between peers. SIP over WebSocket is like WebSockets, only instead of using specially formatted messages; one uses SIP messages in notifications. All clients are connected to the server over WebSocket and they make signaling over the servers. 

Connecting peers and starting communication may sound easy. The internet we use does not allow us to connect with peers as easily as we imagined. To establish this connection and communication, we need to go through firewalls and NAT devices.

WHIP and WHEP – REST‑Friendly Signaling for Ingest & Egress

WHIP (WebRTC‑HTTP Ingestion Protocol) and WHEP (WebRTC‑HTTP Egress Protocol) are lightweight drafts from the IETF that wrap traditional WebRTC signaling in simple, one‑shot HTTP requests—perfect for cloud and CDN workflows.

Why they matter

• Firewall‑friendly: Pure HTTPS means no need for persistent WebSocket ports.
• CDN‑ready: Fits easily behind load balancers; endpoints can be stateless.
• Complementary: WHIP/WHEP replace custom signaling for ingest/egress, while internal viewer chat or data channels can still use WebSockets.

Most modern media servers—including Ant Media Server—already expose WHIP/WHEP endpoints, letting you ingest from OBS or FFmpeg over WebRTC and deliver playback without extra plugins.

So How Does a WebRTC Signaling Mechanism Deal with Internet Issues?

WebRTC Signaling uses a protocol known as ICE which collects, exchanges, and then attempts to connect a session using ICE candidates. ICE candidates are potential addresses that can get peers to connect with each other. With three methods, ICE can calculate the fastest and easiest NAT traversal route for a packet to reach its destination peer.

1. Method: UDP Connection

Establishing a UDP connection using the IP address obtained from a device’s operating system and network card. This will inevitably fail on devices behind NATs. That’s why this option is ignored.

2. Method: a STUN Server

STUN servers are the most used method in WebRTC signaling. In short, it works like this. A STUN server checks the IP address and port for incoming requests and then sends that address to the peer in response. This allows the application to present a publicly accessible address and then forward it via the signaling mechanism to another WebRTC peer.

3. Method: a TURN Server.

The last method used by ICE is a TURN relay server. TURN servers are used to stream audio, video, and other real-time data between peers. It does not share signal information as it enables real-time data exchange between peers. TURN servers have public addresses, so peers can connect to them even if they are behind NATs and firewalls.

We got detailed information about signaling and the WebRTC signaling servers. As we mentioned at the beginning of the blog post, WebRTC is not only used for peer-to-peer connections. In N2N scenarios, more than a WebRTC signaling server is needed. One of WebRTC servers is a WebRTC media server.

Why WebRTC Media Servers Are Required for N2N WebRTC Streams?

In some N2N scenarios, 1 person can broadcast to more than one person, or multiple people can broadcast to multiple people. You can think of examples such as webinars you attend, and social media live streams.

When streaming WebRTC media content to a large audience, you must use a media server. This is because we do not want to establish P2P connections for every user. A scenario like this would consume a lot of resources and is not very realistic. Let’s give an example.

Let’s say you want to stream a 2 Mbps video using WebRTC and broadcast a great conference to 200 audiences. Without a media server, the device you use to reach each viewer will need to use a 400 Mbps uplink connection. Imagine how difficult it would be to create such a setup.

In such cases, the solution is to use a media server such as Ant Media Server. The broadcaster’s device sends the media content to the media server, which in turn sends that content to the viewers’ device. The best feature of the media server is not only that it can send broadcasts to N people, but also that the media server handles the transcoding and encoding, even repackaging the WebRTC stream to other protocols, scaling it, and even adding the adaptive streaming feature to keep the audience happy. The media server can also act as a WebRTC signaling server. Ant Media Server can do all of these and more. 🙂

Ant Media has been serving more than 1525 customers in 120+ countries all around the world. Customers from different segment such as education, live auctions, radio and TV broadcasts, service providers, government agencies, and gaming companies enhance their business by using Ant Media Server and benefiting from its capabilities.

Frequently Asked Questions (FAQ)

Do I always need a signaling server? 
Yes. Even for pure peer‑to‑peer calls, some channel must exchange SDP offers/answers and ICE candidates. After negotiation, media can flow directly, but signaling is mandatory during setup.

What happens if I skip TURN?
Without TURN, calls that sit behind strict symmetric NATs or corporate firewalls may fail. TURN is a relay‑of‑last‑resort—use it as a fallback, not the default, but have it ready in production. 

When should I use WHIP vs. WHEP?
Use WHIP for ingest—pushing a live WebRTC stream from an encoder to a media server or CDN. Use WHEP for egress—pulling that stream from the server to a viewer’s browser or native player. 

Does signaling add latency to my stream?
Only during the initial handshake (usually a few hundred ms). Once the peer connection is established, signaling traffic is negligible and does not affect media latency. 

Is WebRTC secure by default?
Yes. Browsers require DTLS‑SRTP for encryption, and modern deployments run over HTTPS/WSS. Still, validate certificates on TURN and media servers and keep your STUN/TURN credentials safe.