WebRTC Metrics
A comprehensive overview of WebRTC statistics, derived indicators, and observable signals, to better understand call quality, connectivity, and user experience in rtcStats
packetsLost
Total number of RTP packets lost for this SSRC.
Description
Integer
Total number of RTP packets lost for this SSRC. Calculated as defined in RFC3550 section 6.4.1.
This is the metric reported for the outgoing media stream from the remote peer. For the incoming metric see packetsLost.
This affects media quality greatly, so we want its value to be as low as possible.
Interpreting Values
| Range | Description | |-------|-------------| | <1% packet loss | Acceptable. Minor loss is normal on the internet and usually concealed by error correction | | 1-2.5% | Degrading quality. Audio concealment and video error correction are working hard | | 2.5-5% | Noticeable artifacts. Users will hear glitches and see video corruption | | >5% | Severe. Audio becomes choppy, video freezes or shows heavy artifacts |
- The table above does not take into account specific implementations, concealment techniques used or additional algorithms employed
- This represents loss YOUR media experiences on the way to the remote peer - it is the outbound direction
- Calculate loss percentage using
packetsLost / (packetsLost + packetsReceived) * 100
Common Causes
- Your upload path has congestion or packet drops
- Remote peer's download path has issues (last-mile congestion)
- WiFi interference or poor signal strength on your side
- Network between you and the peer is lossy (shared links, overloaded routers)
- Burst loss from WiFi channel switching or brief disconnections
User Experience Impact
- The REMOTE user hears and sees degraded quality from you
- Audio: choppy speech, robotic artifacts, words dropping out
- Video: blocky artifacts, brief freezes, macro-blocking (large colored squares)
- The experience mirrors what you would see with inbound packet loss - but the remote peer is the one suffering
Troubleshooting
- This is loss in the direction YOU send - focus on your upload network quality
- Check your upload bandwidth and whether it is saturated
- Compare with inbound-rtp.packetsLost to determine if loss is symmetric (general network issue) or one-directional (specific path problem)
- If on WiFi, check signal strength and consider switching to wired
- Look for burst patterns - periodic loss often indicates WiFi contention or background traffic spikes
- If using TURN, check if the relay path is introducing loss
See also
- remote-inbound-rtp->packetsLost/s
- remote-inbound-rtp->packetsLost(%)
- remote-inbound-rtp->packetsReportedAsLost
- remote-inbound-rtp->packetsReceived
- WebRTC Statistics Specification

Notes
- Because of how this is estimated, it can be negative if more packets are received than sent