Video chat is often described as peer-to-peer — your device talking directly to a stranger's device, with nothing in between. That's true once the call is running, but it raises an obvious question: if neither device knows the other exists yet, how do they find each other at all? That's the signaling server's entire job, and it's worth understanding because it's genuinely simpler than it sounds.
Picture two people trying to meet at a specific restaurant table, except neither has the other's phone number. They need a mutual friend to tell each of them where the other is sitting. That friend's job ends the moment they're introduced — the actual conversation that follows doesn't involve the friend at all. A signaling server plays exactly that role for two devices: it relays just enough information for them to find each other, then steps out of the picture entirely once the direct connection is live.
The signaling server doesn't see or touch any video or audio — it only relays metadata, and specifically two kinds:
A text description of what each device can actually do — which video and audio formats (codecs) it supports, what resolution it can handle, and similar technical capabilities. Both sides need to agree on a compatible format before anything can start.
A list of possible network paths — addresses and ports — that might work to actually reach a given device. Since most devices sit behind a router or firewall, there's no single obvious path, so several candidates get gathered and tested to find one that works.
Once both sides have exchanged this information and a working path is found, the direct connection takes over and the signaling server's role in that specific call is finished.
It's worth being precise about a distinction that's easy to blur: the signaling server and a separate thing called a TURN server do genuinely different jobs, even though both sit somewhere in this overall process. Signaling only ever handles the introduction — metadata, never media. TURN is different: it's a fallback that only gets used in cases where a direct connection genuinely can't be established (certain strict firewalls, for instance), and in those specific cases, it relays the already-encrypted media itself rather than just helping two devices find each other. Most calls never need TURN at all; it exists specifically as backup for the cases where a direct path isn't possible. We cover this distinction, including the one honest exception worth knowing about it, in our guide to how P2P video calling actually works.
Because the signaling server's job ends at the introduction, there's nothing for it to log about your actual conversation — it was never part of it in the first place. This isn't a policy promise that could quietly change; it's a structural fact about what that piece of infrastructure does and doesn't see. For the fuller picture of what Chatzyo specifically does and doesn't collect, see our zero-data philosophy page.
It's a deliberate gap in the standard, not an oversight. WebRTC specifies how the actual connection and media transport work in detail, but leaves the signaling method entirely up to whoever builds the application. That flexibility means signaling can be built with a WebSocket connection, simple HTTP requests, or even something unusual like manually copying a code between two people — the standard doesn't care, as long as the right metadata gets from one side to the other somehow. In practice, WebSocket-based signaling is the most common choice for browser applications, since it keeps a persistent connection open and avoids the inefficiency of repeatedly checking for new messages.
If you notice a brief delay before connecting to someone, it's often the signaling and path-finding process working through exactly the network complexity described above — testing candidate paths to find one that actually works before the call can start. If that process fails entirely, the call simply never begins, which is different from a call that starts and then drops. Our connection errors guide covers what to do if this becomes a frequent or persistent problem.
No. It only ever handles the metadata used to find a path between two devices — never the actual video or audio stream.
Most devices sit behind a router or firewall, which hides their real network address. Without something to introduce two devices first, neither one would have any way to find the other.
New connections can't be started while it's down, since there's no way to introduce two devices to each other. Calls already in progress aren't affected, though, since they're already running directly between the two devices by that point.
A signaling server is a genuinely small, narrowly-scoped piece of the overall picture — it introduces two devices and then gets out of the way. Everything that actually matters about your conversation (the video, the audio, the content) happens entirely outside what it ever touches. It's a good example of how a seemingly complex piece of internet infrastructure can be both essential and, by design, almost entirely uninvolved in the part people actually care about.
It's also a good illustration of a broader pattern worth knowing: privacy in systems like this often comes less from a promise and more from architecture — a piece of infrastructure that simply isn't built to see something can't leak it later, regardless of policy. That's a more durable kind of guarantee than one that depends entirely on a company choosing not to look.
For more on how this fits into the bigger picture, see our guides on how WebRTC actually works and why video chat uses both WebRTC and WebSockets.