Back to Blog

How to debug a webrtc-internals dump with AI

Stop scrolling through thousands of getStats lines. Upload a webrtc-internals dump to rtcStats and AI tells you what went wrong on the call in under 30 seconds. Or query it from Claude Code and Cursor over MCP.

Posted by

Debugging a webrtc-internals dump with AI in rtcStats

A user complains the call sounded bad. You pull the dump, open chrome://webrtc-internals, and start scrolling through thousands of getStats() lines looking for the one number that explains it. That is not debugging. That is archaeology.

Guess what? This post has been written with the help of an AI agent (not this specific sentence, but the intent, scaffolding, pieces of the draft, ..). While we're at it 👉 considerable parts of the tech around this text on this website was created with the help of AI.

So does most of the work you are probably doing. Which means we're all also using AI to develop applications - WebRTC applications (obviously). Which is why I'd like to suggest a faster way to debug WebRTC issues: You hand the dump to AI and get the answer.

AI reads the dump so you don't have to.

There are three ways to do it:

  1. Upload a dump and let rtcStats analyze it
  2. Paste raw stats into a chatbot (and why that breaks)
  3. Query rtcStats directly from your IDE over MCP

What is a webrtc-internals dump?

When a WebRTC call goes wrong, Chrome (and Edge, and any Chromium browser) records everything that happened in chrome://webrtc-internals. You expand the failing peer connection, click "Create Dump", and download a JSON file.

That file is the ground truth for the call: every ICE candidate, every SDP negotiation, and a time series of getStats() for every audio and video track. It is also tens of thousands of lines of unformatted JSON. Everything you need to find the root cause is in there. So is everything you don't.

Can you just paste it into ChatGPT or Claude?

You can try. It mostly doesn't work, and it fails in a specific way.

A real webrtc-internals dump is large. Paste it into a general chatbot and one of three things happens:

  • It exceeds the context window and gets truncated, so the model might not see the moment the call actually broke
  • The model loses the timestamp correlation between tracks, so it can't line up "video froze" with "packet loss spiked" - and that correlation is the whole job
  • It hallucinates a confident answer from the fragment it did see

And don't get me started about trying to do this at scale... the costs involved...

Anyways, there's a context-window tax and a real cost associated with it - even if you can get some decent results on a dump file or two. You see, the dump is the right input, but a generic chat window is the wrong reader. You need something that parses the dump into the metrics that matter, keeps the timeline intact, and only then reasons over it.

How rtcStats debugs the dump with AI

Upload a webrtc-internals dump (or an rtcstats dump) to rtcstats.com. In under 30 seconds you get four things, in plain English:

  • Observations - the moments that mattered. The freeze at 2:14, the bitrate that collapsed, the ICE restart you didn't know happened
  • Deductions - what those signals mean for the person on the call. Where all that negativity came from - getting you closer to the root cause
  • Experience Score - how the call actually felt, in a single number out of 100
  • AI Summary - the whole story of the call, written out, so you can paste it into the bug ticket instead of writing it yourself

rtcStats analysis of a webrtc-internals dump: an Experience Score, Observations by severity, and an AI Summary of the callrtcStats analysis of a webrtc-internals dump: an Experience Score, Observations by severity, and an AI Summary of the call

The point is not that AI replaces your judgment. The point is that it does the archaeology for you and hands you the timeline, so you start from "here is what went wrong" instead of from a wall of JSON.

Also note that the way rtcStats yields AI is after baking a ton of hard learned rules over the years by the team who built it - we know WebRTC in and out.

It doesn't replace webrtc-internals. It is the layer above it that does the pattern recognition you were doing by hand.

Debug from Claude Code and Cursor (over MCP)

If you live in your IDE, you don't have to leave it. rtcStats runs a Model Context Protocol (MCP) server - that's the Model Context Protocol, the open standard for connecting AI agents to tools, not a media control plane - so Claude Code, Cursor, or any MCP client can query your analyzed sessions directly:

  • Ask "what went wrong on session X" and get the Observations back in the chat
  • Pull the quota and session list without opening a browser tab
  • Keep the dump out of your context window entirely - rtcStats parses it, your agent reads the answer

That last point is the fix for the context-window tax. The heavy JSON stays server-side. Your coding assistant gets the structured result.

The MCP server is an Enterprise-plan feature. If you're on the free plan or troubleshooting a one-off, the browser upload above does the same analysis - you just read the answer on rtcstats.com instead of in your IDE. See the MCP server page for the endpoint, the tools, and setup.

Do you have to send your data to rtcStats?

No, not all of it, and not by default. The rtcstats collection layer is open source. You run rtcstats-js in your client and rtcstats-server in your own infrastructure, and you decide which sessions get forwarded for analysis - random sample, per-user, per-region, threshold-triggered, or just the one you're debugging right now. You own the data. You send what you want and keep the rest.

For one-off troubleshooting you don't need any of that - just upload the dump file by hand.

Try it on your next bad call

Free plan, no credit card. Every new account runs at full Developer-level analysis for the first month, so you see exactly what the AI does before you commit to anything.

Stop scrolling through getStats output at 11pm. Upload the dump, get the answer.

Start at rtcstats.com.

What's the worst WebRTC call you've ever had to debug from a dump?

Frequently asked questions

Can AI analyze a webrtc-internals dump? Yes. Upload a webrtc-internals dump to rtcStats and it returns Observations, Deductions, an Experience Score, and a plain-English AI Summary of what went wrong on the call, usually in under 30 seconds. You can also query analyzed sessions from Claude Code or Cursor over rtcStats's MCP server.

Why can't I just paste a webrtc-internals dump into ChatGPT? A real dump is tens of thousands of lines of JSON. It usually exceeds the chatbot's context window, loses the timestamp correlation between tracks, and produces a confident but wrong answer. rtcStats parses the dump first, preserves the timeline, and reasons over the structured metrics instead.

How do I read a webrtc-internals dump? Open chrome://webrtc-internals, reproduce the issue, expand the failing peer connection, and download the dump. Then upload it to a tool like rtcStats that parses the JSON, scores the call, and highlights the moments that mattered, rather than reading the raw file by hand.

Can I debug WebRTC from Claude Code or Cursor? Yes. rtcStats exposes an MCP (Model Context Protocol) server, so an MCP client like Claude Code or Cursor can read your analyzed sessions and Observations directly in the IDE, without pasting the raw dump into the model's context window. The MCP server is an Enterprise-plan feature; on the free plan you upload the dump in the browser and read the analysis on rtcstats.com.

Is rtcStats free? There is a free plan with no credit card. Every new account runs at full Developer-level analysis for the first month. The collection layer (rtcstats-js, rtcstats-server) is open source and self-hosted.