Fundamentals
MOS Score Explained: The 1–5 of Call Quality
Every VoIP dashboard shows it: MOS — Mean Opinion Score — a single number, 1 to 5, standing in for 'how good did that call sound?' A 4.2 is a good call; a 3.1 is a complaint waiting to be filed. But MOS is an estimate with a history: born as the average of human listeners rating recordings, now computed by formulas (the E-model) from network measurements. Knowing which MOS your dashboard shows — and what it can't see — is the difference between trusting it and being misled by it.
This guide covers the scale, the estimation machinery (ITU-T G.107), realistic interpretation bands, and the three blind spots that matter operationally.
The scale and what users actually perceive
| MOS | Human verdict | Operational meaning |
|---|---|---|
| 4.3–5.0 | Excellent — transparent quality | Ceiling territory: G.711 on a clean network tops out around 4.4 (the scale's practical max for narrowband) |
| 4.0–4.3 | Good — users don't think about quality | The healthy target for business calls |
| 3.6–4.0 | Fair — slight impairment, acceptable | Users notice if prompted; investigate trends, not incidents |
| 3.1–3.6 | Poor — effort required to listen | Complaints begin; find the impairment factor |
| Below 3.1 | Bad — conversation is work | Active fault; treat as an incident |
How the E-model computes your dashboard number
The E-model (ITU-T G.107) starts from a base quality (the R-factor, 0–100) and subtracts impairments: one for the codec's inherent cost, one for delay's conversational damage, and one — usually decisive — for equipment impairment under loss, which folds in your measured packet loss and the codec's robustness to it (a reason G.729's MOS dives faster than G.711's at the same loss rate: its impairment-per-loss is worse). The R-factor maps to the familiar 1–5 MOS. RTCP reports feed the model real loss/jitter/delay from your actual calls. Two consequences: MOS is comparative (trends and contrasts are more truthful than absolute decimals), and MOS is path-blind (it reports the aggregate, not which hop did it — localization still needs captures at two points).
Use MOS like an operator
- Baseline your network: record typical MOS by path (internal, per site, per provider) during healthy weeks — future anomalies need a 'normal' to be judged against.
- Alert on movement, not absolutes: a site sliding 4.2 → 3.8 over a month is a story; one 3.4 call on a noisy mobile leg is weather.
- Pair every MOS investigation with the components: dashboards that show loss/jitter/delay alongside MOS tell you which impairment to hunt (delay → routing/queueing; loss → congestion/drops; codec impairment → negotiation).
- Segment by codec before concluding: a MOS drop after a codec-policy change may be arithmetic (different impairment factors), not a network regression.
- Remember the ceiling: don't chase 4.8 on narrowband G.711 — the codec's own ceiling (~4.4) forbids it; chase it on wideband paths if the business cares.
Frequently asked questions
- Why do users complain about calls the dashboard scores 4.1?
- MOS models network impairment to speech intelligibility — it does not hear echo (unless severe), hum, static, or an infuriating IVR. Perceptual faults outside the model are real complaints with green dashboards; that's what the noise and echo guides are for.
- Can MOS be gamed by measuring only one direction?
- Dashboards differ: some average both directions, some show the worse, some measure only what RTCP reports they receive. A path with one destroyed direction can look acceptable in a lazy average — always check per-direction stream statistics in a dispute.
- Is a higher MOS codec always better?
- MOS compares quality at a given network condition. G.722/Opus score higher ceilings and sound better; G.729 scores respectably on clean networks and falls off a cliff under loss. Choose for the network you have (see the codec guide), not the brochure number.