A MOS score (Mean Opinion Score) is the average quality rating of a voice or video call on a 1 to 5 scale, where 5 is "Excellent" and 1 is "Bad", as defined in ITU-T P.800. This article covers Mean Opinion Score for call audio, not the military occupational specialty (MOS) codes paired with ASVAB scores. A MOS reaches you one of three ways: listeners rated recordings (MOS-LQS), an algorithm compared degraded audio to a reference (MOS-LQO), or a planning model such as the ITU-T G.107 E-model estimated it from delay, packet loss and codec (MOS-CQE). Monitoring tools show the third kind, which is why a G.711 call tops out at 4.4 and why 3.5 is the usual alarm line.
What is a MOS score?
ITU-T P.800 (08/96), "Methods for subjective determination of transmission quality", defines the scale. In a listening test each subject rates each sample on a five-point absolute category rating (ACR) scale; the experimenter assigns numbers to the words, and the arithmetic mean of those numbers is the mean opinion score.
| Score | Quality of the speech (P.800 Annex B, listening-quality scale) |
|---|---|
| 5 | Excellent |
| 4 | Good |
| 3 | Fair |
| 2 | Poor |
| 1 | Bad |
Two details from P.800 matter later. The scale is a mean of category votes, so a MOS of 4.0 can come from everyone voting "Good" or from half voting "Excellent" and half "Fair"; the mean hides the spread. And P.800 notes that older experiments sometimes scored Excellent = 4 down to Bad = 0, so a historical 3.4 may be today's 4.4.
A MOS is not a percentage, not a network metric and not a property of a codec alone. It is a rating of what listeners heard, or an estimate of what they would have heard, for one combination of codec, network, terminal and listening situation.
What do MOS-LQS, MOS-LQO and MOS-LQE mean?
ITU-T P.800.1 (07/2016), "Mean opinion score (MOS) terminology", exists because "MOS" was being used for three different methods. Its identifiers encode method and situation: LQ listening quality, CQ conversational quality, TQ talking quality; S subjective, O objective, E estimated.
| Identifier | How the score was produced (P.800.1 clause 7) | Where you meet it |
|---|---|---|
| MOS-LQS | Arithmetic mean of subjective judgments on the P.800 five-point ACR scale, collected in a laboratory listening test | Codec standardisation tests |
| MOS-LQO | Calculated by an objective model that predicts a listening-only test result; P.862.1, P.862.2 (PESQ) and P.863 (POLQA) give MOS-LQO | Intrusive test equipment with a reference recording |
| MOS-LQE | Calculated by a network planning model for a listening-only situation | Planning tools |
| MOS-CQE | Network planning model for a conversational situation; "Estimates of conversational quality carried out according to [ITU-T G.107], when transformed to mean opinion score, give results in terms of MOS-CQE" | VoIP monitoring dashboards, RTCP XR, this site's calculator |
P.800.1 adds a bandwidth suffix: N for narrowband (300–3400 Hz), W for wideband (50–7000 Hz), S for super-wideband (20–14000 Hz), F for fullband (10–20000 Hz). A MOS-LQOn and a MOS-LQOw are scored against different references and are not the same scale. The same recommendation says the type of audio (speech, music, mixed) should be reported with the value. The conversational S and O variants (MOS-CQS, MOS-CQO) exist too; what a VoIP dashboard shows as "MOS 4.2" is almost always a MOS-CQE, narrowband, produced by an E-model variant from network counters. No one listened to anything.
Why is 4.4 the maximum MOS for a G.711 call?
Because the E-model caps there by construction. ITU-T G.107 (06/2015) states that with every input parameter at its default value, "the calculation results in a very high quality with a rating factor of R = 93.2". The defaults describe a clean narrowband connection: G.711 coding (Ie = 0), zero delay, zero packet loss. Annex B maps R to an estimated conversational MOS with equation B-4:
For 0 < R < 100: MOSCQE = 1 + 0.035·R + R·(R − 60)·(100 − R)·7·10−6; for R ≤ 0, MOS = 1; for R ≥ 100, MOS = 4.5.
At R = 93.2 the formula gives 4.41. That is the narrowband ceiling: nothing in a G.711 call can push R above the default, because every other term in the model is an impairment that subtracts from it. RFC 3611, which carries R factor (0–100) and MOS (as MOS × 10, 10–50) in RTCP XR VoIP metrics, notes that R = 94 corresponds to "toll quality". Even R = 100 maps to only 4.5.
Wideband audio uses a different scale. The wideband E-model (ITU-T G.107.1) extends the R-scale; G.113 Appendix IV puts the wideband direct channel at R = 129 against the narrowband 93.2 and defines Ie,wb = Ie + 35.8. A wideband call on the extended scale and a G.711 call on the narrowband scale are not comparable numbers; a tool that shows both on one 1 to 5 axis has made an undocumented conversion.
How does the E-model turn delay, loss and codec into a MOS?
G.107 equation 7-1 defines the rating factor as:
R = Ro − Is − Id − Ie-eff + A
Ro is the basic signal-to-noise ratio including circuit and room noise. Is collects impairments that occur simultaneously with the voice signal (loudness, sidetone, quantisation). Id collects delay impairments: talker echo (Idte), listener echo (Idle) and pure absolute delay (Idd). Ie-eff is the effective equipment impairment: codec plus packet loss. A is the advantage factor, a credit for access the user values over quality; G.107 Table 2 caps it at 0 for wireline, 5 for cellular in a building, 10 in a vehicle and 20 for satellite links. Monitoring tools set A = 0.
Codec and packet loss: Ie-eff
Equation 7-29 of G.107:
Ie-eff = Ie + (95 − Ie) · Ppl / (Ppl / BurstR + Bpl)
Ie is the codec's impairment at zero loss, Bpl its packet-loss robustness, Ppl the packet-loss percentage, and BurstR the burst ratio: 1 for random, independent loss, above 1 for bursty loss. Ie and Bpl are looked up in ITU-T G.113 Appendix I, whose values are labelled provisional planning values. The rows most tools use:
| Codec (G.113 Table I.4, 09/2024) | Packet size | PLC | Ie | Bpl |
|---|---|---|---|---|
| G.711 | 10 ms | None | 0 | 4.3 |
| G.711 | 10 ms | G.711 Appendix I concealment | 0 | 25.1 |
| G.729 Annex A + Annex B (VAD) | 20 ms | Native | 11 | 19.0 |
| G.723.1 + Annex A (VAD) | 30 ms | Native | 15 | 16.1 |
| GSM-EFR | 20 ms | Native | 5 | 10.0 |
The G.711 rows show why concealment is not a detail. At 2% random loss, G.711 without concealment gives Ie-eff = 95·2/(2 + 4.3) = 30.2, so R falls from 93.2 to 63.0 and MOS to 3.26. With the Appendix I concealer, Ie-eff = 7.0, R = 86.2, MOS = 4.23: same codec, same loss, a full point apart. G.113 also states that in systems with a jitter buffer "the applicable packet loss is measured at the output of the jitter buffer", so late packets the buffer discards count as lost.
Delay: Idd
G.107 sets Idd = 0 while the one-way delay Ta is at or below the minimum perceivable delay mT, 100 ms in the default delay-sensitivity class (Table 1; the "low" and "very low" classes use 120 and 150 ms, only for users known to be insensitive to delay). Above mT, equation 7-27 grows Idd with the logarithm of Ta/mT:
| One-way delay Ta | Idd (G.107 eq. 7-27, sT = 1, mT = 100 ms) |
|---|---|
| 100 ms | 0 |
| 150 ms | 0.2 |
| 200 ms | 3.0 |
| 300 ms | 14.8 |
| 400 ms | 24.1 |
| 500 ms | 30.6 |
Delay is almost free to 150 ms and expensive after 250 ms. Ta is one-way mouth-to-ear delay, not round trip: a 300 ms RTT on a symmetric path is Ta ≈ 150 ms plus codec, jitter-buffer and playout delay. Feeding RTT into Idd doubles the penalty.
Worked example
A G.729A call with VAD (Ie 11, Bpl 19.0), 2% random loss (BurstR 1), 300 ms one-way delay, echo terms at G.107 defaults (TELR 65 dB, T = Tr = 0, so Idte and Idle are zero) and A = 0:
- Ie-eff = 11 + (95 − 11)·2/(2 + 19.0) = 11 + 8.0 = 19.0
- Idd at 300 ms = 14.8
- R = 93.2 − 14.8 − 19.0 = 59.4
- MOSCQE = 1 + 0.035·59.4 + 59.4·(−0.6)·(40.6)·7·10−6 = 3.07
The same arithmetic, with the G.113 rows above and the delay classes, runs in the E-model MOS calculator on this site. The number it returns is a MOS-CQE on the narrowband scale, and it is only as good as the Ie and Bpl you pick.
What R-factor and MOS values count as good?
G.107 Annex B, Table B.1 ("Provisional guide for the relation between R-value and user satisfaction") is the standard threshold table; the MOS column is the lower limit of each band under equation B-4.
| R (lower limit) | MOSCQE (lower limit) | Good or better (%) | Poor or worse (%) | User satisfaction |
|---|---|---|---|---|
| 90 | 4.34 | 97 | 0 | Very satisfied |
| 80 | 4.03 | 89 | 0 | Satisfied |
| 70 | 3.60 | 73 | 6 | Some users dissatisfied |
| 60 | 3.10 | 50 | 17 | Many users dissatisfied |
| 50 | 2.58 | 27 | 38 | Nearly all users dissatisfied |
The GoB and PoW columns are the part most dashboards drop, and they carry the message: at MOS 3.6 the model expects 6% of listeners to rate the call poor or worse, at MOS 3.1 it expects 17%. A "fair" average is a measurable minority of bad calls.
Vendor thresholds cluster around the 70/3.6 line. Zoom's Phone dashboard uses "a baseline MOS of 3.5", with 3.5 or higher reported as good and below as poor. Twilio's Voice SDK raises a low-mos warning when "Mean Opinion Score (MOS) < 3.5 for 3 out of last 5 samples", and its glossary says quality "becomes unacceptable below a MOS of roughly 3.5".
What do Twilio, Zoom and Teams report as "MOS"?
Three platforms, three different objects behind the same three letters; every number below is from the vendor's own documentation.
| Platform | What the "MOS" is | Threshold logic | Caveats in the vendor's docs |
|---|---|---|---|
| Twilio Voice Insights (JS SDK) | "a measure of the overall network conditions that affect call quality"; the glossary calls it a metascore with jitter, latency and packet loss as the measurable components | low-mos warning: MOS < 3.5 in 3 of the last 5 samples; companion warnings at jitter > 30 ms, RTT > 400 ms, packet loss > 1% | Per-sample estimate of the SDK's leg, not the far end |
| Zoom Phone dashboard | MOS on a 1 to 5 scale, "the main measurement" of call quality, shown per call with bitrate, packet loss, jitter and network delay; the Meetings dashboard bands the same scale as 4.0–5.0 Good, 3.0–4.0 Fair, 2.0–3.0 Poor, 1.0–2.0 Bad | Baseline 3.5: at or above is good, below is poor | "Calls that are less than 30 seconds in length may have a lower MOS than other calls" because momentary loss or jitter skews the whole-call score |
| Microsoft Teams Call Quality Dashboard | "Overall Avg Network MOS" and "Send Listen MOS" measures, plus "Audio Degradation Avg": "Average Network Mean Opinion Score degradation for stream" from network loss and jitter | The Poor/Good audio classifier does not use MOS: a stream with more than 500 packets is Poor if round trip > 500 ms, packet loss rate > 0.1, or jitter > 30 ms; "Degradation is deprecated in the classifier" | A Poor classification "doesn't mean the audio stream was actually of poor quality, nor does it mean the user perceived a quality issue"; Audio Degradation Avg is "Not for use with SATIN or WebRTC/VDI" |
None of these is a MOS-LQS, and none documents which Ie and Bpl table it uses or whether its scale is narrowband or extended. A Twilio 4.1 and a Zoom 4.1 are two formulas fed by two measurement points.
Common mistakes when reading a MOS score
- Averaging over the call. A 20-minute call with 19 clean minutes and one minute of 20% loss averages above 4.2, while the user remembers the minute. Twilio alarms on 3 of 5 consecutive samples and Zoom warns that short calls expose single bursts for the same reason. Keep the per-interval series and alert on the worst window, not the mean.
- Treating MOS as a network metric. MOS is downstream of delay, loss, jitter and codec, and the mapping is non-linear; the G.711 example above shows concealment alone moving the score by a point. Alert on the inputs; report MOS as the summary.
- Comparing narrowband and wideband. A G.711 call cannot exceed 4.41 on the narrowband scale; an Opus wideband call scored with G.107.1 lives on a scale whose direct channel sits at R = 129. A tool that shows "4.6" for one and "4.3" for the other is not saying the first call sounded better.
- Reading an estimate as a measurement. MOS-CQE from an E-model never heard the audio. It cannot see a muted microphone, a clipping gain stage, a failed echo canceller or a transcoding hop. Teams' documentation says as much by refusing to call its Poor classification a perceived problem.
- Ignoring BurstR. Equation 7-29 divides Ppl by BurstR, so 2% loss in bursts impairs more than 2% spread evenly; G.107 Table 3 limits BurstR above 2 to loss under 2%. A tool that assumes random loss reports the optimistic case.
When the standard MOS advice fails
- Opus is absent from G.113. Appendix I lists G.711, G.726, G.728, G.729, G.723.1, GSM codecs and LC3plus, not Opus, the codec RFC 7874 makes mandatory in WebRTC. Any Opus MOS from an E-model tool rests on an Ie/Bpl pair the vendor chose, and Opus's in-band FEC (RFC 6716) recovers some losses before concealment, which the loss term does not model. Treat WebRTC MOS as relative, for trend and alerting, not as an absolute quality claim.
- Short calls. Zoom documents that calls under 30 seconds can score low on a single burst. A 10-second synthetic probe is the same case. Score probes on counters over a fixed window and compare probe to probe.
- Multi-leg calls. An estimate from one leg's RTCP says nothing about a transcoding hop or the PSTN leg. Teams reports per stream, Twilio per SDK leg; the worst leg is the call.
- Non-speech audio. P.800.1 warns that music and mixed content must not be scored with speech-only objective models such as P.863. Hold music, IVR prompts and voice-AI synthesis are not what the scales were calibrated on.
Frequently asked questions
What is a good MOS score for VoIP?
By G.107 Table B.1, R ≥ 80 (MOS ≥ 4.03) is "Satisfied" and R ≥ 70 (MOS ≥ 3.60) still leaves 6% of listeners rating the call poor or worse. Zoom and Twilio both alarm at 3.5. For a narrowband G.711 call, 4.0 to 4.4 is the whole "good" range.
How is MOS calculated from jitter, latency and packet loss?
Through the E-model: packet loss and codec enter as Ie-eff; one-way delay enters as Idd, zero up to 100 ms and growing logarithmically after; R = 93.2 − Idd − Ie-eff with other defaults; MOS comes from equation B-4. Jitter enters indirectly, as the packets the jitter buffer discards (counted as loss) and the delay the buffer adds (counted in Ta).
Does WebRTC report a MOS?
Not natively. The W3C WebRTC Statistics API exposes the inputs (jitter, packets lost, round-trip time, jitter-buffer delay, concealed samples); any MOS shown for a WebRTC call was computed by the application or vendor from those counters. The WebRTC testing guide lists the counters worth asserting on directly.
Sources
- ITU-T P.800 (08/96), Methods for subjective determination of transmission quality, Annex A.4.2.1 and Annex B.4.5 opinion scales.
- ITU-T P.800.1 (07/2016), Mean opinion score (MOS) terminology, clause 7 and Table 1.
- ITU-T G.107 (06/2015), The E-model: a computational model for use in transmission planning, equations 7-1, 7-27, 7-29, Tables 1–3, Annex B equation B-4 and Table B.1.
- ITU-T G.113 (09/2024), Transmission impairments due to speech processing, Appendix I Tables I.1 and I.4, Appendix IV.
- RFC 3611, RTP Control Protocol Extended Reports (RTCP XR), section 4.7 VoIP Metrics Report Block.
- RFC 6716, Definition of the Opus Audio Codec; RFC 7874, WebRTC Audio Codec and Processing Requirements.
- W3C, Identifiers for WebRTC's Statistics API, Candidate Recommendation Draft, 25 September 2025.
- Twilio, Voice Insights SDK events; Twilio glossary, What is Mean Opinion Score.
- Zoom, The Zoom Phone Dashboard; Zoom, Using Zoom Dashboard to troubleshoot network issues.
- Microsoft, Stream classification in Call Quality Dashboard; Microsoft, Dimensions and measures available in CQD.