WebRTC troubleshooting: diagnose the symptom, not the tool
When a WebRTC call goes wrong, you search the symptom. These guides take each common symptom, explain what causes it, and show which metrics tell you what actually happened.
A user complains the call sounded bad, or the video froze, or it would not connect at all. You do not have a stack trace. You have a vague sentence and a webrtc-internals dump with thousands of metrics in it.
These guides are organized the way you actually debug: by the symptom. Each one takes a single symptom, explains what causes it, tells you which getStats() metrics to read and what healthy versus unhealthy looks like, and shows how rtcStats surfaces the answer so you are not scrolling timelines by hand.
| Symptom | You hear or see | Start here |
|---|---|---|
| Jitter | Audio warbling, choppy speech | WebRTC jitter |
| Packet loss | Gaps, artifacts, dropouts | WebRTC packet loss |
| ICE failure | Call never connects | WebRTC ICE failed |
| Freeze | Video stalls or sticks | WebRTC video freezing |
| Choppy audio | Robotic, breaking speech | WebRTC choppy audio |
Let rtcStats do this for you
Every guide here is a manual playbook: pull the dump, find the right metrics, line up the timelines, and reason about the cause. rtcStats does all of that for you. Upload a webrtc-internals or rtcstats dump and it reads the whole call, flags the moments that mattered as Observations, tells you what they mean for the user as Deductions, scores how the call actually felt with an Experience Score, and writes the plain-English story as an AI Summary, in under 30 seconds.
Stop scrolling getStats output looking for the one number that explains the bad call. Upload a dump and get the answer, free.
