Every call TeleQuick Voice carries leaves behind three quality numbers: an estimated MOS (Mean Opinion Score), the interarrival jitter in milliseconds, and the packet-loss percentage. They are computed in the RTP media plane as the call runs — not sampled by an external probe — and folded into the call’s CDR at teardown, keyed by call_sid. This page tells you what each number means, how it is derived, and where the line is between a healthy call and one your customer noticed.

​
What you get, at a glance

MOS

1.0–4.5 estimated listening quality (ITU-T G.107 E-model). Higher is better; a clean G.711 leg tops out near 4.4.

Jitter

RFC 3550 interarrival jitter in ms — how unevenly packets arrived. Lower is better.

Loss

Percentage of expected RTP packets that never arrived. Lower is better.
All three are derived from the same per-packet accounting on the caller’s media leg (loss from sequence-number continuity, jitter from arrival timing), so they move together and explain each other — a MOS drop almost always traces back to a spike in one of the other two.

​
MOS — the E-model estimate

The MOS reported here is not a subjective survey score. It is a computed estimate produced by the ITU-T G.107 E-model: the model derives a transmission-rating factor R, then maps R to an estimated MOS (MOS_CQE). TeleQuick Voice computes it in the media plane specialized for the G.711 codec carried on phone legs. R is built by subtracting impairments from a clean baseline: 
R = R0 − Id − Ie_eff
  • R0 ≈ 93.2 — the baseline for a wired VoIP path (signal/noise, no advantage factor).
  • Ie_eff — the equipment/effective impairment: it folds the codec plus the effect of packet loss. G.711 with packet-loss concealment is loss-robust (a G.113 packet-loss robustness factor of 25.1), so small loss costs little R; loss past a few percent bites hard.
  • Id — the delay/jitter impairment: the engine does not measure one-way mouth-to-ear delay directly, so it approximates delay as a fixed path component plus the jitter-buffer depth (roughly the measured jitter). Beyond the classic 177.3 ms delay knee, Id climbs steeply.
R is then mapped to MOS by the standard E-model cubic and clamped to [1.0, 4.5] — 4.5 is the E-model’s practical ceiling, and because G.711 already spends a little R on codec and fixed delay, the realistic clean-call maximum you will see is about 4.4, not 4.5.
MOS here is an estimate from loss and jitter, not a measured opinion score and not a per-packet PESQ/POLQA analysis. Treat it as a fast, always-on health signal that ranks calls and flags regressions — not as a lab-grade audio-quality verdict.

​
How to read the MOS number

MOSPerceived qualityWhat it means for you
4.3 – 4.4ExcellentEffectively toll-quality; the network is not your problem.
4.0 – 4.3GoodNormal, healthy calls. Most traffic should sit here.
3.6 – 4.0FairUsers notice occasional artifacts; worth watching the trend.
3.1 – 3.6PoorAudible degradation; investigate the trunk / access network.
< 3.1BadComplaints likely. Escalate — usually heavy loss or a saturated path.
The values below are illustrative points from the engine’s own E-model for a G.711 leg, so you can calibrate what a given loss/jitter pair does to MOS:
LossJitter≈ MOS
0%5 ms4.4
1%20 ms4.3
3%40 ms4.1
5%60 ms3.8
10%100 ms3.3

​
Jitter — RFC 3550 interarrival jitter

Jitter is the smoothed variation in packet arrival timing, computed exactly per RFC 3550 §6.4.1. For each packet the engine takes the transit time (arrival clock minus the packet’s RTP timestamp, both in 8 kHz G.711 ticks), takes the absolute change in transit from the previous packet, and folds it into a running estimate with the RFC’s 1/16 gain: 
J += (|D(i-1, i)| − J) / 16
That gives a stable exponential average that reacts to sustained variation but ignores single outliers. It is accumulated in timestamp ticks and reported in milliseconds (ticks ÷ 8 at the 8 kHz clock). Jitter matters because the receive-side buffer has to hold packets long enough to absorb it before playing them out — high jitter forces a deeper buffer (more mouth-to-ear delay, which the E-model then charges against R) or, if the buffer can’t keep up, late packets are dropped and become loss.
JitterRead
< 20 msHealthy. The jitter buffer absorbs it invisibly.
20 – 50 msAcceptable but adds buffering delay; watch on latency-sensitive AI turns.
> 50 msBuffer under pressure; expect late-packet loss and a MOS dip.

​
Packet loss — sequence continuity

Loss is measured from RTP sequence-number continuity, not from a timer. The engine anchors on the first packet’s sequence number, tracks the highest sequence seen (handling the 16-bit wraparound), and at call close computes: 
loss% = 100 × (expected − received) / expected
where expected is the span of sequence numbers between the first and last packet. A packet that arrives too late to be played (past the reorder buffer’s depth) is counted as lost as well — from the listener’s point of view it never showed up. Duplicates are dropped and do not inflate the received count.
LossRead
< 1%Good. G.711 packet-loss concealment hides it.
1 – 3%Noticeable clipping on speech onsets; concealment working hard.
3 – 5%Clearly audible dropouts; MOS falls below “good.”
> 5%Poor. Usually a congested or lossy access network / trunk.

​
Where the numbers live

The three metrics are computed cheaply per-packet on the caller’s media leg, folded into loss%/jitter_ms/MOS at the moment the call clears, written to the call’s per-call media quality record (keyed by call_sid), and carried into the CDR alongside the disconnect cause and duration. That means you can sort, filter, and alert on quality per call, per trunk, or per tenant from the same reporting surface that shows call outcomes — no separate capture step and no packet trace required for the common case.
Quality fields are computed on the RTP media plane and reflect the leg the engine terminates (the PSTN/SIP caller leg). For browser and app legs the media rides Opus over our QUIC transport, where the browser’s own jitter buffer and encoder govern arrival timing; the E-model MOS here is the G.711 telephony-leg estimate.

​
Troubleshooting a low MOS

Start from the MOS, then use jitter and loss to localize the cause.
1

Read jitter and loss together

A low MOS is always explained by one or both. High loss with low jitter points at a lossy link or a policed/rate-limited path. High jitter with loss that appears only under load points at congestion or an undersized receive buffer.
2

Check whether it's one call or a population

A single bad call is usually the far end’s access network. A fleet-wide shift across a trunk or region is yours — a saturated uplink, a flapping path, or a misconfigured trunk. Group the CDR quality fields by trunk and by tenant before you touch anything.
3

Confirm codec and path

Verify the leg negotiated the codec you expect (see Codecs); a transcoded or mismatched path adds impairment the E-model will reflect.
4

Pull a trace only if you need packet-level detail

When the aggregate numbers aren’t enough, capture the SIP/RTP exchange for the specific call_sid — see SIP & RTP debugging.

​
Symptom → cause → fix

SymptomLikely causeFix
MOS ~3.x, loss > 3%, jitter lowLossy or policed access network / trunkCheck the trunk uplink and provider path; loss is the dominant R impairment.
MOS dips only at busy hourCongestion — jitter climbs, then late-packet lossProvision headroom on the path; confirm QoS/DSCP marking is honored end to end.
Jitter high, loss near zero, MOS still fairBursty arrival absorbed by a deep bufferAcceptable for voice, but the added delay hurts AI turn latency — see below.
Great MOS but callers report echo/robotic audioNot a network metric — echo/AEC or codec issueMOS won’t catch it; check the leg’s codec and see one-way/quality troubleshooting.
MOS 1.0 on many short callsToo few packets to measure, or one-way mediaConfirm two-way RTP flowed at all — see one-way-audio troubleshooting.
MOS is a listening-quality estimate from loss and jitter. It does not see echo, gain problems, or a wrong-codec artifact, and there is no acoustic echo cancellation in the media path (the runtime relies on the browser’s AEC and VAD gating). A perfect MOS with a bad-sounding call means the problem isn’t the network — start with One-way & degraded audio.

Observability overview

Everything a call leaves behind — events, CDRs, recordings, traces.

Latency breakdown

Where jitter-buffer depth shows up as turn latency on AI calls.

SIP & RTP debugging

Drop to packet-level captures when the aggregate numbers aren’t enough.

High latency

Diagnose slow turns, including buffering added to absorb jitter.