MOS (Mean Opinion Score) is the single-number indicator of perceived VoIP call quality. Your operational target is a MOS typically described as 'toll quality,' the level where users rarely notice any degradation. The ITU-T E-model (G.107) converts measurable network impairments directly into this score, which is why modern monitoring platforms can report it per call without a single human listener.
If your MOS is below 4.0 right now, start here:
- Check packet loss first. Even a small amount of packet loss can noticeably reduce MOS scores. Pull RTCP reports or a short Wireshark capture on an active RTP stream.
- Identify your codec. G.729 codec has a hard ceiling on achievable MOS regardless of network conditions, typically below acceptable toll quality thresholds. If you are running G.729 codec and targeting 4.0+, the codec is the constraint, not the network.
- Measure in both directions. A call that sounds fine to the agent may be degraded for the customer. Bi-directional measurement is the only way to catch asymmetric impairments.
Table of Contents
- How to read MOS numbers in real-world VoIP
- How is MOS calculated for VoIP calls?
- How to measure MOS in practice: tools and operational setup
- What causes MOS to drop on VoIP calls?
- How to improve MOS: a prioritized remediation playbook
- How to report MOS in SLAs and internal dashboards
- Authoritative standards every VoIP team should know
- Key Takeaways
- A practitioner's perspective on MOS and what it actually tells you
- Businessvoip builds MOS targets into every on-site installation
- Useful sources and further reading
How to read MOS numbers in real-world VoIP
A MOS of 4.3 and a MOS of 3.8 are not just numbers on a scale. They translate directly into user behavior and support ticket volume.
| MOS Range | Perceived Quality | Operational Implication |
|---|---|---|
| 4.3–5.0 | Excellent | Users notice no impairment; toll-quality or better |
| 4.0–4.3 | Good (toll quality) | Acceptable for all business use; target threshold |
| 3.5–4.0 | Fair | Noticeable but not disruptive; investigate proactively |
| 3.0–3.5 | Poor | Complaints likely; escalate and remediate promptly |
| Below 3.0 | Bad | Calls effectively unusable; treat as an outage |
The 4.0 threshold is the widely cited operational target for business VoIP, and it holds up in practice. Below 3.5, users start describing calls as "choppy" or "robotic." Below 3.0, many will abandon the call entirely.
One caveat worth internalizing: a notable difference in MOS is generally around half a point for most listeners. A drop from 4.2 to 3.9 will generate complaints. A drop from 4.2 to 4.1 probably will not. This means chasing marginal improvements above 4.0 is rarely worth the engineering effort.
Pro Tip: Set your alerting threshold slightly below the toll quality target to allow early investigation before user complaints increase.
How is MOS calculated for VoIP calls?
There are three distinct paths to a MOS number, and the one your system uses determines how much you can trust the result.
Subjective listening panels (P.800)
The original method: recruit listeners, play them processed audio samples, and average their 1–5 ratings. Accurate, but expensive and slow. No production monitoring system does this in real time. It remains the gold standard for codec evaluation and vendor benchmarking.
Objective lab tests: PESQ and POLQA
PESQ (P.862) compares a known reference signal to a degraded version and outputs a MOS-LQO estimate. POLQA (P.863) is its successor, extending coverage to wideband and super-wideband audio and handling modern codecs more accurately. Both require a reference signal, which means they work in controlled test environments, not live call monitoring.
Use PESQ or POLQA when:
- Evaluating a new codec before deployment
- Running acceptance tests on a new SIP trunk
- Benchmarking endpoint audio quality in the lab
How to measure MOS in practice: tools and operational setup
Choosing the right measurement approach depends on whether you are testing before deployment or monitoring a live environment.
| Method | Tool / Standard | What It Gives You | Best For |
|---|---|---|---|
| Objective lab test | PESQ, POLQA | MOS-LQO from reference vs. degraded signal | Codec evaluation, trunk acceptance |
| In-service E-model | SBC/call manager RTCP XR reports | Per-call MOS estimate from network stats | Continuous production monitoring |
| RTP capture + analysis | Wireshark + RTP stream analysis | Packet loss, jitter, out-of-order packets | Root cause investigation |
| Active test calls | SIPp, VoIP test frameworks | End-to-end MOS under controlled load | Pre-launch stress testing |
| Open-source estimation | PJSIP quality stats, Asterisk RTCP | E-model MOS from open-source PBX logs | Low-cost monitoring in SMB environments |
Monitoring systems use E-model estimates from RTCP and RTCP XR reports because they require no reference audio and can run continuously on every call. RTCP XR (RFC 3611) is the richer variant: it reports jitter, packet loss, and round-trip time per call leg, giving the E-model everything it needs.
Measurement design: what to capture and how often
ETSI guidance recommends taking multiple MOS-LQO samples within a single call, in both directions, and collecting enough measurements to ensure statistical stability. For in-service E-model monitoring, that translates to:
- Sample every call, not just a random subset, if your platform supports it
- Measure both legs (A-to-B and B-to-A) separately
- Log at minimum: codec, timestamp, call duration, source and destination endpoints, MOS value, packet loss %, jitter (ms), and RTT (ms)
- Alert threshold: MOS below 3.8 sustained over more than 5% of calls in a 15-minute window
Operational checklist for MOS monitoring rollout:
- Enable RTCP XR on all SIP endpoints and the SBC
- Configure your call manager or SBC to export RTCP stats to a logging platform (syslog, SNMP, or API)
- Store PCAPs for calls that trigger MOS alerts (retain for 72 hours minimum)
- Set up per-trunk and per-codec MOS dashboards so you can isolate whether a degradation is carrier-side or LAN-side
- Review MOS trends weekly; investigate any codec or trunk showing a rolling average below 3.8
What causes MOS to drop on VoIP calls?
Most MOS degradation traces back to a short list of causes. Knowing which one you are dealing with determines the fix.
- Packet loss is the biggest single driver. Even 1% loss can reduce MOS by 0.3–0.5 points depending on the codec's loss concealment. At 5% loss, most calls are noticeably impaired regardless of codec. Bursty loss is materially worse than the same percentage of random loss because concealment algorithms cannot bridge long gaps. A routing flap that drops 50 consecutive packets is far more damaging than 50 scattered drops across a minute.
- One-way latency above 150 ms starts affecting conversational flow. At 400 ms, users begin talking over each other. The E-model applies a delay penalty that grows nonlinearly above 150 ms.
- Jitter causes the jitter buffer to either underrun (producing gaps) or overflow (causing drops). Jitter above typical buffer thresholds can produce audible artifacts on voice streams.
- Codec choice sets a hard ceiling. G.711 codec has a higher MOS ceiling than G.729 codec, and Opus can achieve even higher MOS under ideal conditions depending on configuration. No amount of network optimization can push a G.729 codec call above its ceiling.
- Transcoding adds latency and introduces additional codec impairment at each conversion point. A call that traverses G.711 codec → G.729 codec → G.711 codec accumulates impairment from both codec stages.
- Endpoint quality matters more than most teams budget for. A cheap headset, a misconfigured echo canceler, or outdated firmware on an IP phone can degrade MOS independently of network conditions.
Detecting each impairment:
- Packet loss: visible in RTCP receiver reports and Wireshark RTP stream analysis (look for sequence number gaps)
- Jitter: reported in RTCP SR/RR and RTCP XR; also visible in Wireshark's RTP stream statistics
- Latency: measure RTT from RTCP or use ICMP/SIP OPTIONS pings to the far-end gateway
- Transcoding: trace the SDP offer/answer exchange in SIP logs to see codec negotiation at each hop
How to improve MOS: a prioritized remediation playbook
Fix in this order. The highest-impact changes come first, and the first two are almost always the right place to start.
1. Eliminate packet loss with QoS
Mark RTP traffic with DSCP EF (Expedited Forwarding, DSCP 46) at the LAN edge. This places voice packets in the priority queue on every QoS-aware switch and router hop. SIP signaling should be marked CS3 (DSCP 24). Without DSCP marking, voice packets compete with bulk data transfers and get dropped during congestion.
On the WAN side, verify your ISP or MPLS provider honors DSCP markings end-to-end. Many do not by default. If you are running voice over a shared internet connection, a WAN shaper or SD-WAN policy that reserves bandwidth for marked voice traffic is worth the investment.
2. Address burst loss sources
Random loss at 0.5–1% is manageable. Burst loss at the same average rate is not. Common burst sources: ISP queuing during peak hours, routing protocol reconvergence, and overloaded NAT devices. Pull a 30-minute PCAP during peak call hours and look for loss clusters. If you see runs of 5+ consecutive lost packets, the cause is almost certainly a queuing or routing issue, not random network noise.
3. Reduce transcoding hops
Align codec policy end-to-end so calls traverse a single codec from endpoint to PSTN gateway. If your IP phones negotiate G.711 codec, your SBC should pass G.711 codec to the SIP trunk rather than transcoding to G.729 codec for bandwidth savings. The MOS penalty from transcoding usually outweighs the bandwidth cost.
4. Tune jitter buffers
Jitter buffer settings need to be adapted to network latency, with typical values chosen to balance delay and packet loss concealment in different environments. Most SBCs and IP phones expose this as a configurable parameter; check the default before assuming it is optimal.
5. Codec strategy
If you need MOS above 3.92 and are currently on G.729 codec, switch to G.711 codec or Opus. The codec ceiling is a hard constraint — network remediation alone cannot overcome it.
| Codec | Max Achievable MOS (ideal network) | Bandwidth per Call | Notes |
|---|---|---|---|
| G.711 codec | ~4.3–4.4 | ~87 kbps (with RTP/UDP/IP) | Wideband quality; standard PSTN equivalent |
| G.729 codec | ~3.92 | — | Low bandwidth; ceiling limits enterprise targets |
| Opus (wideband) | ~4.3 | — | Best quality/bandwidth ratio for SIP trunks |
| G.722 codec | ~4.4 | ~87 kbps | HD voice; requires wideband endpoints throughout |
Pro Tip: Before spending on WAN upgrades, confirm your codec ceiling. If G.729 codec is in use and your target is 4.0+, a codec change costs nothing and solves the problem immediately.
How to report MOS in SLAs and internal dashboards
A MOS number without context is nearly useless for comparison or accountability. ITU-T P.800.2 is explicit: MOS values must be accompanied by metadata describing the measurement method, because scores from different contexts are not directly comparable.
Required metadata for every published MOS value:
- Test method (subjective P.800, PESQ/P.862, POLQA/P.863, or E-model/G.107)
- Codec(s) in use during the measurement
- Sample size (number of calls or test samples)
- Measurement time window (date range, time of day, peak vs. off-peak)
- Direction (A-to-B, B-to-A, or both)
- Endpoint types (IP phone model, softphone, gateway)
- Network conditions at measurement time (if known)
Example SLA language
Automated reporting pipeline checklist:
- Export RTCP XR stats per call to a time-series database (InfluxDB, Prometheus, or equivalent)
- Tag each record with codec, trunk ID, endpoint type, and call direction
- Build dashboards showing MOS distribution (not just average) — a mean of 3.9 can hide a tail of calls at 2.5
- Alert on P10 (10th percentile) MOS, not just the mean, to catch degraded subsets
- Archive raw RTCP data for 90 days minimum to support SLA dispute resolution
Authoritative standards every VoIP team should know
The ITU-T recommendations governing MOS are not suggestions. They define the vocabulary, the math, and the reporting requirements that make quality metrics meaningful across vendors and test environments.
| Recommendation | What It Covers |
|---|---|
| P.800 methodology | MOS terminology: defines MOS-LQO, MOS-CQO, and other variants so scores are labeled correctly |
| P.800 guidance | Interpretation and reporting guidance: mandates metadata and warns against cross-context comparison |
| PESQ | Objective speech quality assessment for narrowband; the basis for lab MOS-LQO estimation |
| POLQA | Successor to PESQ; covers wideband and super-wideband; preferred for HD voice testing |
| G.107 E-model | Converts network impairments to R-factor and MOS; the engine behind in-service monitoring |
The critical caveat from P.800.2 deserves its own emphasis:
This is the reason a vendor claiming "MOS 4.2" in a marketing sheet is meaningless without knowing the codec, test method, and conditions. Always ask for the metadata before accepting a quality claim.
Key Takeaways
A MOS of 4.0 or above is the minimum acceptable threshold for business VoIP, and codec choice, packet loss, and jitter are the three variables that determine whether you can reach it.
| Point | Details |
|---|---|
| Target MOS threshold | Aim for ≥4.0 (toll quality); below 3.5 generates user complaints and support tickets. |
| Codec ceilings are hard limits | G.729 codec caps near 3.92; switch to G.711 codec or Opus before spending on network upgrades. |
| Packet loss is the top impairment | Even 1% loss drops MOS by 0.3–0.5 points; bursty loss is worse than random loss at the same rate. |
| Always report MOS with metadata | Per ITU-T guidance, MOS values without test method, codec, and sample size cannot be compared across sources. |
| Businessvoip on-site design | Businessvoip designs codec policy, QoS, and cabling on-site such that MOS targets are built in from day one. |
A practitioner's perspective on MOS and what it actually tells you
MOS is a useful number, but the VoIP industry has developed a habit of treating it as a verdict when it is really just a starting point. A dashboard showing 4.1 average MOS does not mean your calls are fine. It means the average is 4.1. The 10th percentile might be 2.8, concentrated on one trunk, during peak hours, affecting your highest-value customers. That is the number worth watching.
The other thing that gets underestimated: the gap between what MOS measures and what users actually experience. MOS captures audio degradation on the RTP stream. It does not capture one-way audio from a misconfigured firewall, echo from a cheap headset, or the frustration of a call that connects but drops every 20 minutes. A team that hits 4.0 average MOS and considers the job done is solving the measurable problem while leaving the experiential one untouched.
The codec ceiling insight is the one most teams learn the hard way. Spending weeks tuning QoS policies on a G.729 codec deployment, chasing a 4.0 target that the codec physically cannot reach, is a common and avoidable mistake. Check the ceiling first. If the codec cannot get you there, change the codec. The network work is still worth doing, but do it after you have removed the hard constraint.
For business VoIP deployments, the practical implication is that MOS monitoring should be part of the initial system design, not bolted on after complaints start arriving. Knowing your baseline MOS on day one gives you a reference point for every future change.
Businessvoip builds MOS targets into every on-site installation
Getting above 4.0 MOS and staying there requires more than good intentions on a config sheet. It requires the right codec policy, properly marked QoS at the LAN edge, cabling that does not introduce interference, and an SBC configured to pass audio cleanly without unnecessary transcoding hops. Those are installation decisions, not monitoring decisions, and they are much harder to fix after the fact.
Businessvoip's on-site team in Ontario handles all of it before the first call is made: network assessment, codec selection, DSCP marking, cabling, and SBC configuration, all designed around your specific call volume and infrastructure. The result is a VoIP phone system where MOS targets are built into the architecture rather than chased after deployment. Fixed pricing, lifetime warranty on rented phones, and a local team that actually shows up means you are not troubleshooting call quality alone at 9 AM on a Monday.
If your current system is not hitting 4.0 consistently, or you are planning a new deployment and want quality designed in from the start, get a phone system design consultation with Businessvoip.
Useful sources and further reading
The standards below are the primary references for anyone implementing or auditing VoIP quality measurement. Read them in the order listed if you are building a monitoring program from scratch.
- P.800.2 : Mean opinion score interpretation and reporting
- P.800.1 : Mean opinion score (MOS) terminology
- P.863
- G.107
- P.862
- VoIP MOS Score — What It Is, Good Scores & How to Improve | SIPSymposium
- MOS Scores Explained: The Number Behind Call Quality | VoIP Test
- MOS Score — VoIP Quality Metric