How does WebRTC even know a packet was lost?

1 Aug 2026 · 2 min

Watch on YouTube

1:49

In this brief tutorial, the speaker explains that WebRTC detects packet loss through RTCP receiver reports. The receiver counts incoming packets and periodically sends a report indicating how many packets were expected versus actually received. This "packets lost" metric enables the sender to adapt to network conditions by lowering bitrate, requesting retransmissions, or reducing video resolution. The speaker emphasizes that the loss data is available in the getStats API under the remote inbound RTP statistics, which reflect the receiver's view of the sender's stream. Developers often mistakenly look only at local outbound stats, which show what was sent, not what was received. By inspecting the remote inbound RTP stats, one can accurately diagnose call quality issues.

Chapters

How does WebRTC even know a packet got lost? It's simpler than you think, and almost no developer ever looks at it. When you send media over WebRTC, the receiver keeps count. Every so often, it sends a small report back to the sender that basically says, "You told me that you sent 20 packets, I only got 18. That report is what RTCP is for. And that one number, packets lost, is the whole reason WebRTC can react to a bad network at all. Well, maybe not the only reason. The sender reads that report and adjusts. He lowers the bitrate, asks for retransmit, drops the resolution, There are more advanced techniques, but they work on a similar reporting concept. All of it starts from the receiver telling the sender the truth about what actually arrived, or vice versa. Here's the thing, the data is sitting right there in GET stats under remote inbound RTP. It's the receiver's view of your own outgoing stream. If you only look at your local outbound stats, you're seeing what you try to send, not what the other side actually received. So next time a call go bad and you can't explain why, don't guess. Go read what the other end reported back. It might surprise you.