KuberEva Book a call

Home/Documentation/Voice quality

Voice quality: MOS, R-factor & POLQA

"Calls sound bad" is not a defect report. This is how the industry turns perceived audio quality into a number you can set as an acceptance criterion and monitor in production.

MOS: what it is, and what it isn't

Mean Opinion Score is a measure of voice quality on a scale of 1 to 5, where 1 is bad and 5 is excellent. Originally it was exactly what the name says — you played samples to a panel of listeners and averaged their ratings.

Almost nothing labeled MOS today is that. Modern MOS figures come from one of two approaches, and confusing them is the most common mistake in voice quality conversations.

ApproachMethodNotation
Estimated / predicted Compute a quality score from network parameters — latency, jitter, loss, codec — using a model. No audio is analyzed. MOS-CQE
Objective / measured Analyze the actual audio, comparing a degraded sample against a clean reference. MOS-LQO
Subjective Human listeners rate samples under controlled conditions. MOS-LQS

When a vendor dashboard reports "MOS 4.2," it is almost always the first kind — a computed estimate. That is genuinely useful for continuous monitoring at scale, but it is a model output, not a measurement of what your customer heard.

The E-model and the R-factor (ITU-T G.107)

The ITU-T G.107 E-model is the transmission rating model behind nearly every estimated MOS you will encounter. It computes a rating factor, R, from network and codec parameters, and then maps R to an estimated MOS.

R is built by starting from a theoretical maximum and subtracting impairments: delay, equipment impairment for the codec in use, packet loss, echo, and noise. From the resulting R value the model derives not only MOS but also GoB (the minimum percentage of listeners expected to rate the call Good or Better) and PoW (the maximum percentage expected to rate it Poor or Worse).

Fig. 1 — the R-factor scale ITU-T G.107
not recommended poor low medium high best R-factor <50 5060 7080 90100 MOS 2.6–3.13.1–3.6 3.6–4.04.0–4.3 4.3–4.5 A flawless G.711 call lands here — about 4.4 "MOS 4.5 or better" is an acceptance criterion that cannot be met. Set the target relative to the codec's achievable maximum — never to 5.
The scale does not reach 5. The codec itself carries an impairment, so narrowband tops out around 4.4 and POLQA's own maximum is 4.5 narrowband, 4.75 super-wideband. Acceptance criteria written against 5.0 are unachievable by construction.
R-factorQuality bandApprox. MOSUser reaction
90–100Best4.3–4.5Very satisfied
80–90High4.0–4.3Satisfied
70–80Medium3.6–4.0Some users dissatisfied
60–70Low3.1–3.6Many users dissatisfied
50–60Poor2.6–3.1Nearly all users dissatisfied
below 50Not recommended< 2.6Not usable
The ceiling nobody mentions A perfect G.711 call does not score 5.0. The codec itself carries an equipment impairment, so a flawless narrowband call tops out around 4.4. If someone sets an acceptance criterion of "MOS 4.5 or better" on a G.711 path, they have written a target that cannot be met. Set the target relative to the codec's achievable maximum.

POLQA (ITU-T P.863) and PESQ

Where the E-model predicts quality from network conditions, POLQA — Perceptual Objective Listening Quality Analysis, standardized as ITU-T P.863 — measures it from the audio itself.

It is a full-reference method: a clean reference sample is compared with the degraded sample that came out the other end of the network, and the algorithm models how a human ear and brain would perceive the difference, producing a MOS-like score.

POLQA extends the approach of its predecessor PESQ (ITU-T P.862) to wideband audio up to 14 kHz and full-band up to 24 kHz, which lets it handle HD voice codecs and complex delay variation that PESQ could not.

Two useful details:

UseMethodWhy
Continuous production monitoringE-model estimated MOSWorks on every live call from RTP statistics, with no reference needed
Pre-launch acceptance testingPOLQA on synthetic callsMeasures what a listener would actually perceive, reproducibly
Codec or carrier comparisonPOLQAControlled reference makes results comparable across options
Investigating a complaintBothThe estimate localizes the impairment; a reference call confirms severity

The three impairments that matter

Latency

One-way delay, mouth to ear. ITU-T G.114 is the reference: up to about 150 ms is fine for most applications; 150–400 ms is usable but conversation dynamics start to suffer; beyond 400 ms is generally unacceptable. What people experience as "we kept talking over each other" is nearly always delay rather than anything else.

Contributors: propagation, serialization, codec algorithmic delay, jitter buffer depth, and every transcoding step. That last one is why transcoding should be designed out rather than relied on.

Jitter

Variation in packet arrival timing. A jitter buffer smooths it out at the cost of adding delay — which is a direct trade-off, not a free fix. Adaptive buffers manage this dynamically, but a network with high jitter forces a deep buffer, and the deep buffer pushes you toward the latency limits above.

Packet loss

Loss matters less as a raw percentage than as a pattern. Random single-packet loss is largely concealed by packet loss concealment. Bursty loss — several consecutive packets — removes whole syllables and is far more damaging at the same overall percentage. When diagnosing, look at burst distribution, not just the loss figure.

Setting a target you can actually use

A usable quality specification has four parts:

  1. A target, expressed relative to the codec's achievable maximum — for example, estimated MOS ≥ 4.0 on a G.711 path.
  2. A percentile. An average hides everything that matters. Specify the 95th percentile, so the target covers the calls that are actually bad.
  3. A measurement point. Quality measured at the SBC and quality measured at an agent's headset are different numbers, and remote agents on domestic broadband are where most real degradation lives.
  4. A budget for the components — one-way delay, jitter, and loss — agreed separately, so that when the target is missed you know which one to investigate.
Measure the path your calls actually take A lab test between two well-connected endpoints in the same data center proves very little. Measure across the real path: through the SBC, over the WAN or internet segment, to the endpoint types you actually have — including home-worker connections. The difference between the lab result and the real one is usually the entire finding.

Why this matters most during migration

On TDM the circuit works or it does not; quality is not really a variable. Moving to IP introduces a spectrum where the trunk can be entirely operational and the calls unacceptable. Teams that do not establish measurement before cutover end up arguing about anecdotes — and the carrier, quite reasonably, will not act on anecdotes.

Establish a baseline before the migration if there is anything to baseline, set the target as an explicit acceptance criterion, and instrument production from day one.

Related reading

We design the measurement so quality becomes an acceptance criterion, not an argument.

Book a call