Potential local bufferbloat
We are observing some delay being built up in the local jitter buffer, causing incoming packets to playout a bit later than expected.
Description
Incoming audio and video in WebRTC get captured and managed by the jitter buffer. Usually, we aim on having media packets stay on the jitter buffer as little time as possible before being played to the user to maintain low latency.
Sometimes this isn’t the case.
What we do here is compute the difference between the incoming RTT and the internal jitter buffer delay. Such a check detects the additional time media packets stay inside the jitter buffer. What we expect is for the jitter buffer delay to correlate in size to the RTT and not be much higher.
In our case, it is the difference between the jitter buffer delay and the incoming RTT. This computation detects the "extra time" packets stay in the jitter buffer. When high RTT, it is normal that the jitter buffer increases accordingly. But if the difference is high, it could indicate that something else delays the pipeline (which is not latency). After a RTT spike, often, the jitter buffer delay takes time to decrease and for audio, this is not good.
What do we do here?
We check if the (jitterBufferDelay - RTT/2) > 150 ms. When we notice a bufferbloat during more than 10 consecutive measures, we mark this as an Observation.
Notes
- Spikes in RTT cause the jitter buffer delay to increase for audio and it doesn’t always decrease quickly. See if this is the case
- Check if there are other media related observations that might indicate a bigger issue