What to do with the result
| R-factor | MOS | G.107 Table B.1 | Typical action |
|---|---|---|---|
| ≥ 90 | ≥ 4.34 | Very satisfied | Nothing. Use as the baseline for alert thresholds. |
| 80–90 | 4.03–4.34 | Satisfied | Normal production range for G.711 or Opus over the public internet. Alert on a drop of more than 0.3 from baseline rather than on the absolute value. |
| 70–80 | 3.60–4.03 | Some users dissatisfied | Find which term dominates: Idd (delay: route, jitter buffer too deep, TURN relay far away) or Ie-eff (loss: Wi-Fi, congestion, SFU overload). A canary from several regions localises it; see how a check works. |
| 60–70 | 3.10–3.60 | Many users dissatisfied | Page someone. Check for one-way audio or a codec fallback (Opus → G.711 without PLC changes Bpl from 25.1 to 4.3). |
| < 60 | < 3.10 | Nearly all dissatisfied | The call is failing. Confirm loss after the jitter buffer rather than raw network loss; raw loss overstates what the listener hears when concealment works. |
How this is worked out
The E-model (ITU-T G.107) sums impairments on a 0–100 transmission rating scale R and maps R to a conversational MOS. This tool implements the current edition, G.107 (06/2015), with the following simplification: the connection is treated as echo-free with all loudness, sidetone and noise parameters at their G.107 defaults, which gives the documented default rating of R = 93.2. Only three terms vary:
- Delay impairment Idd (G.107 eq. 7-27 and 7-28, default delay-sensitivity class with
sT = 1,mT = 100 ms): zero up to 100 ms of one-way delay, thenIdd = 25·[(1 + X⁶)^(1/6) − 3·(1 + (X/3)⁶)^(1/6) + 2]withX = log₂(Ta / 100). At 200 ms this is about 3 points; at 400 ms about 24. - Effective equipment impairment Ie-eff (eq. 7-29):
Ie-eff = Ie + (95 − Ie) · Ppl / (Ppl / BurstR + Bpl).Ieis the codec's impairment at zero loss andBplits packet-loss robustness; both come from G.113 Appendix I (Table I.4 in the 09/2024 edition).BurstR = 1for random loss; larger values make the same loss percentage hurt more. - Advantage factor A (G.107 Table 2): a planner's allowance for situations where users accept lower quality in exchange for access, with upper limits 0 (wired), 5, 10 and 20.
R = 93.2 − Idd − Ie-eff + A, then (G.107 Annex B, eq. B-4): MOS = 1 + 0.035·R + R·(R − 60)·(100 − R)·7·10⁻⁶ for 0 ≤ R ≤ 100, with MOS = 1 below R = 0 and MOS = 4.5 above R = 100. This is why no narrowband call scores above about 4.41: the default R of 93.2 maps to 4.41.
Codec values used (G.113 Appendix I, Table I.4)
| Codec | Packet size | PLC | Ie | Bpl |
|---|---|---|---|---|
| G.711 | 10 ms | none | 0 | 4.3 |
| G.711 | 10 ms | Appendix I / G.711 | 0 | 25.1 |
| G.729A + VAD | 20 ms (2 frames) | native | 11 | 19.0 |
| G.723.1 + VAD | 30 ms | native | 15 | 16.1 |
| GSM-EFR | 20 ms | native | 5 | 10.0 |
| Opus | — | — | No ITU-T planning value. The tool uses the G.711-with-PLC pair (0 / 25.1) as a proxy and flags the result as an estimate. | |
The values are identical in the 2002 Appendix I (Table I.3) and in the current edition, ITU-T G.113 (09/2024) Table I.4, which labels them provisional planning values and adds that in systems with a jitter buffer the applicable packet loss is the loss measured at the output of the jitter buffer. Opus does not appear in Appendix I in either edition.
Estimating one-way delay from RTT
The E-model wants mouth-to-ear delay, which a browser does not report. The helper in the form uses Ta ≈ RTT/2 + jitter-buffer delay + packetization delay. RTT comes from candidate-pair.currentRoundTripTime in the WebRTC statistics; the jitter-buffer term is available as inbound-rtp.jitterBufferDelay / jitterBufferEmittedCount; packetization is the codec frame (20 ms for Opus by default) plus look-ahead and device buffers. The two defaults (40 ms and 25 ms) are assumptions, not measurements, and should be replaced by your stack's values.
Limits and when not to use this
- Narrowband only. Wideband and fullband codecs (Opus at 48 kHz, G.722) use the wideband E-model with a different scale (R₀ = 129 in G.107.1). This tool will under-represent what wideband audio sounds like at zero loss.
- Planning model, not a measurement. The output is MOS-CQE, an estimate for a conversation with the given transmission parameters. It is not the MOS of a particular recording, and it is not what a listening test (ITU-T P.800) would return for that recording.
- Loss must be post-jitter-buffer loss with the right Bpl. G.107 Table 3, Note 5: Bpl must match codec, packet size and concealment. Raw network loss with a PLC-capable codec overstates the impairment.
- Validity ranges (G.107 Table 3 and Annex A): Ta 0–500 ms, Ppl 0–20%, BurstR 1–8, with BurstR above 2 validated only for loss below 2%. The tool warns outside these ranges and still computes.
- Echo, noise and loudness are at defaults. A call with audible echo (TELR below 65 dB) scores lower than this tool shows.
Questions engineers ask
Why does my MOS never go above 4.4?
Because the narrowband E-model's default rating is R = 93.2, which maps to MOS 4.41. The 4.5 ceiling is reached only above R = 100, which the default parameter set cannot produce without an advantage factor.
Which matters more, delay or loss?
Up to 100 ms one-way, delay costs nothing in this model; at 200 ms it costs about 3 points of R; at 400 ms about 24. One percent of random loss costs about 3.6 points with G.711 and PLC, but about 18 points with G.711 without PLC. Codec and concealment usually matter more than the loss figure itself.
Is this the same MOS that Twilio, Zoom or Teams show?
Each vendor computes its own estimate, typically also E-model-based but with their own delay and loss inputs and sometimes their own codec parameters, so the numbers are comparable in shape but not identical. The guide on what a MOS score means covers the differences between MOS-LQO, MOS-CQE and vendor scores.
Method v1, frozen 11 September 2026 · Sources: ITU-T G.107 (06/2015) eq. 7-1, 7-27 to 7-29, Table 1, Table 2, Table 3, Annex B eq. B-4, Table B.1; ITU-T G.113 (09/2024) Appendix I Table I.4 (same values as the 05/2002 Appendix I Table I.3). Codec values reviewed 11 September 2026; next review January 2027.
Sources
- ITU-T Recommendation G.107 (06/2015): The E-model, a computational model for use in transmission planning
- ITU-T Recommendation G.113 (09/2024): Transmission impairments due to speech processing, Appendix I (provisional planning values for Ie and Bpl)
- ITU-T Recommendation G.109: Definition of categories of speech transmission quality (source of Table B.1 bands)
- W3C: Identifiers for WebRTC's Statistics API (
currentRoundTripTime,jitterBufferDelay,packetsLost)