We’ve seen complaints by some of our customers that packet loss we report in our service are sometimes not reasonable.
The way we collect the media metrics is by using WebRTC’s getStats() API, so whatever the browser tells us is what gets collected on our end.
We have noticed that this happens when the service in question processes media on the server side, which means it has its own media engine code that implements SRTP and SRTCP. Since many of the metrics collected by the browser stem from incoming SRTCP packets, a reasonable reason is that the incoming reports are wrong. This isn’t an issue in testRTC but in the system under test, which has to be fixed.
Here are two examples of how that manifests itself in our reports:
When packet losses are above 50% it usually means an unreasonable statistic reported by the service. In this case, over 4000% is plain impossible.
Looking further in the same report, we see this:
The number of packets lost here is in the 1000’s, which makes no sense at all – there aren’t so many packets sent in such short timespans and the intervals here are also suspicious.
Here is another case where the culprit is the media server:
There is an outgoing channel with high packet loss. To know the packet loss on an outgoing channel, the browser relies on incoming SRTCP receiver reports. These are reported by the media server.
Further analysis shows the following:
The unreasonable initial spike at the beginning of the media session indicates a wrong value reported by the media server.