Why server logs are useless for WebRTC #webrtc #getStats #observability

1 Aug 2026 · 2 min

Watch on YouTube

1:43

In this technical talk, the speaker argues that server‑side logs cannot reliably debug WebRTC calls because the media streams are encrypted with SRTP and often bypass the server entirely, traveling peer‑to‑peer or through TURN relays that merely forward unreadable packets. Traditional deep‑packet‑inspection techniques from the SIP era are therefore ineffective. The speaker outlines three observation points: the server (signaling and metadata), media servers (streams and routes that pass through them), and the client (the only entity that sees the actual media, network conditions, and CPU usage). The client’s getStats API provides the true telemetry needed to understand call performance. Relying solely on server logs results in observing a shadow of the call rather than the call itself, so developers should collect and analyze client‑side statistics for accurate debugging.

Chapters

You cannot debug WebRTC from your servers, and most teams don't figure that out until they're in production, staring at logs that tell them nothing. Here's why. In WebRTC, the media is encrypted with SRTP, and half the time it doesn't even touch your infrastructure. It goes peer-to-peer or through a TURN relay that just forwards packets it can't read. So the old move from the SIP days, deep packet inspection on your server, sniff the traffic, see what's wrong— that's dead. There's nothing to inspect. It's encrypted, or it's not even there. So where does the truth live? On the client. The browser, the app, the SDK on the user's device That's the one place that sees the real media, the real network, the real CPU. GetStats runs there and it knows what actually happened on that call. Think of it as 3 vantage points. Your server sees the signaling and the metadata. Your media server sees the streams, the routes, you know, whatever goes through them. But only the client sees the whole picture, what the specific user went through. If your entire debugging story is server-side logs, you're watching the shadow and not the call. The call is on the client. Go collect it there.