Mean Opinion Score (MOS) is a numeric measure, from 0 to 5, of perceived voice, video, and audio quality – how good a call or stream sounds to a real user. Versa SD-WAN calculates MOS from live traffic and uses it as an SLA criterion, steering real-time flows onto WAN paths that meet a configured minimum score.
Key takeaways
- MOS rates perceived voice and video call quality on a 0–5 scale.
- Versa VOS computes MOS continuously from live RTP and RTCP traffic.
- SD-WAN traffic steering uses MOS as a per-path SLA parameter.
- A path below the configured MOS threshold is marked SLA-violated.
- Subjective MOS uses human listeners; objective MOS is algorithmic.
On this page: Why it mattersHow it worksTypesMOS & VersaFAQ
Why is MOS important?
Voice and video quality is subjective – a user notices choppy audio or does not – but network teams need a number they can act on. MOS turns that experience into a single figure, 0 to 5, so SLA thresholds and failover can key off it instead of a vague complaint that a call “sounds bad.”
That matters most for real-time traffic, which tolerates almost no delay, jitter, or loss before quality collapses in ways a static latency test would miss. Because MOS is derived from the delay, jitter, and loss a listener actually hears, it catches degradation other SLA parameters miss and lets steering react to whether the call is good, not just whether the link is up.
What is MOS?
MOS expresses perceived audio, video, or voice quality as a single number from 0 through 5, where 5 is the best possible quality and 0 the worst. The scale comes from the Absolute Category Rating (ACR) method: 5 is “Excellent,” 4 “Good,” 3 “Fair,” 2 “Poor,” and 1 “Bad.”
A MOS value is meaningless alone – it is tied to a specific stream, path, and codec, since different codecs tolerate impairment differently. Real-time systems derive MOS from the factors that drive perceived quality: delay (latency), jitter (delay variation), and packet loss. More delay, jitter, or loss pushes the score down; a clean, low-latency path with a high-fidelity codec pushes it toward 5. Because it is derived rather than directly observed, MOS is a proxy engineered to track what a human ear or eye would perceive.
Types of MOS
Two broad approaches produce a MOS. Subjective MOS comes from ITU-T P.800 listening-test panels: real people rate live calls on the five-point ACR scale – accurate but far too slow and costly to run continuously. Objective (estimated) MOS is algorithmic instead: models such as the E-model, PESQ, and POLQA predict a MOS-equivalent score from measurable inputs like codec, loss, jitter, and delay, without a human panel.
Network-derived MOS is the objective variant SD-WAN devices compute: rather than modeling a hypothetical call, it measures an actual live stream, intercepting RTP and RTCP packets to extract jitter, loss, and delay, and calculating MOS continuously – per codec, per path – so the score reflects current conditions, not a one-time estimate.
MOS & Versa
Versa VOS devices calculate MOS continuously for real-time traffic using their AppID engine, which intercepts RTP and RTCP packets and derives jitter, loss, and delay from them – enabled through real-time monitoring, covering roughly 200 codecs. You set an acceptable MOS threshold, 0 to 5, in an SLA profile and associate it with a Layer 2 or Layer 3 forwarding profile; since MOS already accounts for delay, loss, and jitter together, a MOS-based profile skips those parameters separately.
MOS score monitoring must be enabled before a MOS value is available. Path selection is reactive: an idle path is treated as SLA-compliant, assigned MOS 5 by default. When a path’s MOS for a codec falls below threshold, forwarding marks it SLA-violated and moves the flow to the best compliant path, re-evaluating violated paths on a configurable interval.
Frequently asked questions
What does a MOS score of 5 versus 1 actually mean?
5 is the best rating – impairment is imperceptible, matching a clean landline call. 1 is the worst – quality is degraded enough that the call is nearly unusable. Most VoIP deployments target a MOS above 3.5 to 4; scores below that are noticeably poor.
How is MOS calculated without asking real people to listen?
Subjective MOS comes from ITU-T P.800 listening panels – accurate but slow and expensive. Production systems instead use objective, algorithmic estimation: models like PESQ, POLQA, or the E-model predict a MOS-equivalent score from measurable factors such as codec, loss, jitter, and delay.
How does Versa SD-WAN use MOS?
Versa VOS devices compute MOS continuously from live RTP and RTCP traffic and use it as an SLA parameter in policy-based forwarding. When a path’s MOS for a codec drops below threshold, the path is marked SLA-violated and traffic steers to a compliant path instead.
Can MOS be known in advance for a path that has no traffic?
No. MOS-based path selection is reactive – a codec’s MOS on a path is only calculated once traffic actually flows over it. An idle path is treated as SLA-compliant by default and assigned a MOS of 5 until real traffic proves otherwise.
Does the codec affect the MOS score?
Yes. The same network conditions – loss, jitter, delay – can produce different MOS values for different codecs, since some tolerate impairment better than others. Versa VOS supports roughly 200 codecs and calculates MOS per codec, per path, not once per link.
More on MOS
If you want to learn more, these are sources we trust.
| ITU-T P.800: Methods for subjective determination of transmission quality |
|---|
| The ITU-T recommendation that defines the Mean Opinion Score methodology for rating voice quality. |
Related terms
If you’re reading about MOS, these are worth looking at next.
| SD-WAN | Path | Next-Generation Firewall |
|---|---|---|
| The traffic-steering fabric that uses MOS, alongside other SLA metrics, to pick the best path for real-time flows. | The end-to-end route MOS is actually measured against – each path can carry a different MOS per codec. | The AppID-based inspection engine in VOS that intercepts RTP/RTCP traffic and computes MOS as it flows. |