Our MOS scores dropped across all queues after upgrading to the latest Edge firmware.
Before the upgrade, average MOS was 4.2. After, it dropped to 3.7. We rolled back the firmware but MOS didn’t recover. Is the MOS calculation itself affected by firmware version, or did the upgrade change a codec setting?
The firmware likely changed the default jitter buffer depth.
Newer Edge firmware versions use a more aggressive adaptive jitter buffer that reduces latency but increases sensitivity to network jitter. If your WAN has even moderate jitter (>15ms), the smaller buffer causes more packet drops, which tanks the MOS score.
We A/B tested jitter buffer configurations after a firmware update.
| Buffer Setting | Avg MOS | Latency | Jitter Tolerance |
|---|---|---|---|
| Aggressive (new default) | 3.7 | 40ms | 15ms |
| Balanced | 4.0 | 60ms | 30ms |
| Conservative | 4.3 | 80ms | 50ms |
We switched to Balanced as a compromise between quality and latency.
From a compliance perspective, a MOS below 3.5 may violate our SLA with the customer.
Our enterprise contract guarantees ‘toll-quality voice’ which is defined as MOS ≥ 3.8. If the firmware update dropped us below the SLA threshold, we are liable for service credits. Document the timeline of the MOS degradation for the SLA dispute.
Check chrome://webrtc-internals during a live call to see if the jitter values changed.
The googJitterBufferMs stat shows the current buffer depth. If it dropped from 60ms to 20ms after the firmware update, that confirms the buffer configuration changed. You can also check googJitterReceived to see the actual network jitter hitting the agent.
Pro tip! 
Always capture MOS baseline metrics BEFORE any firmware or browser update!
Run the GC voice diagnostics test and screenshot the results. After the update, run it again and compare. Without a baseline, you can’t prove the update caused the degradation. We maintain a monthly MOS baseline log for every Edge in our network. 