Playout Clock Skew
Measures the timing difference between the sender's and receiver's clocks — an audio-only diagnostic that reveals playout buffer pressure.
Playout Clock Skew
| Property | Value |
|---|---|
| Key | clock_skew_estimate |
| Unit | Parts per million (ppm) |
| Type | Gauge |
| Direction | Receive |
| RFC | RFC 3550 Section 6.4.1 |
What It Measures
Clock skew measures the rate at which the sender's clock and the receiver's clock are diverging from each other. While Clock Drift measures how fast the sender's clock runs relative to a reference, clock skew measures the relative difference between the two endpoints' clocks as it affects media playout.
In simple terms: if the sender generates audio samples at 8,000 per second but the receiver's clock thinks a second is slightly longer, the receiver will consume samples slower than they arrive. Over time, this mismatch creates pressure on the playout buffer — either gradually filling it (if the sender is faster) or draining it (if the sender is slower).
CallMeter estimates clock skew using linear regression over RTCP Sender Report timestamps, comparing the sender's NTP timestamps against the receiver's local clock.
Why It Matters
Clock skew is primarily a concern for audio streams and long-duration calls:
- Buffer overflow — If the sender's clock runs faster, samples accumulate in the receiver's buffer faster than they are played out. Eventually the buffer overflows and samples are discarded.
- Buffer underrun — If the sender's clock runs slower, the receiver drains its buffer faster than new samples arrive, causing brief silence gaps.
- Lip-sync drift — In audio/video calls, different clock skew rates between audio and video streams cause them to gradually desynchronize.
For typical calls under 10 minutes, the impact of clock skew is negligible (a few ppm translates to sub-millisecond drift per minute). For call center monitoring or long-duration conferencing, it can become significant.
How CallMeter Measures It
CallMeter collects RTCP Sender Report timestamps from the remote endpoint and compares them against the local receiver clock. Linear regression over approximately 20 samples produces a skew estimate in parts per million.
Warmup Period and Audio Only
Clock skew estimation requires approximately 60 seconds of RTCP data before the estimate stabilizes. This metric is most meaningful for audio streams where playout timing is critical. For video, frame-level timing is managed differently and clock skew has less direct impact.
Thresholds
This metric does not have standard thresholds. It is a diagnostic value that explains buffer behavior:
| Skew | Impact Over 1 Hour |
|---|---|
| 1 ppm | 3.6ms — negligible |
| 10 ppm | 36ms — within typical jitter buffer range |
| 50 ppm | 180ms — may cause buffer overflow/underrun |
| 100 ppm | 360ms — will cause audible artifacts on long calls |
What Causes High Clock Skew
- Different hardware platforms — When the sender and receiver use hardware with different crystal oscillator qualities, their clocks naturally diverge.
- No clock synchronization — Endpoints without NTP synchronization rely entirely on their hardware clocks, maximizing the chance of skew.
- Virtualized endpoints — VMs with different clock sources or CPU contention patterns produce inconsistent timing.
- Mixed wired/wireless — Some wireless devices use adaptive timing that does not match wired endpoint clocks.
How to Fix It
- Enable NTP on both endpoints. Both sender and receiver should synchronize to the same (or closely peered) NTP servers.
- Use adaptive jitter buffers. Most modern VoIP stacks automatically compensate for small clock skew by adjusting buffer size. Verify this is enabled.
- Monitor on long calls. If your use case involves calls over 30 minutes, track clock skew to predict when buffer pressure becomes problematic.
Related Metrics
- Clock Drift — Measures the sender's hardware clock accuracy independently
- Jitter — Clock skew can manifest as a slow, steady jitter component
- MOS Score — Severe clock skew eventually degrades MOS through buffer-induced artifacts