Every call that ClutchCall Voice carries leaves three quality numbers: an estimated MOS (Mean Opinion Score), the interarrival jitter in milliseconds, and the packet-loss percentage. The RTP media plane computes them while the call runs. An external probe does not sample them. At teardown, the system folds them into the call’s CDR, keyed by call_sid. This page tells you what each number means and how the system computes it. It also tells you the line between a healthy call and a call your customer noticed.

​
What you get, at a glance

MOS

Estimated listening quality from 1.0 to 4.5 (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. It shows how unevenly packets arrived. Lower is better.

Loss

The percentage of expected RTP packets that never arrived. Lower is better.
All three come from the same per-packet accounting on the caller’s media leg. Loss comes from sequence-number continuity. Jitter comes from arrival timing. Thus the metrics 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 from the ITU-T G.107 E-model. The model derives a transmission-rating factor R, then maps R to an estimated MOS (MOS_CQE). ClutchCall Voice computes it in the media plane, specialized for the G.711 codec on phone legs. The model builds R when it subtracts impairments from a clean baseline:
  • 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). Thus small loss costs little R. Loss past a few percent costs much more.
  • Id. The delay/jitter impairment. The engine does not measure one-way mouth-to-ear delay directly. It approximates delay as a fixed path component plus the jitter-buffer depth (roughly the measured jitter). Past the classic 177.3 ms delay knee, Id climbs steeply.
The standard E-model cubic then maps R to MOS. The result is clamped to [1.0, 4.5]. The value 4.5 is the E-model’s practical ceiling. G.711 already spends some R on codec and fixed delay. Thus the realistic clean-call maximum that you will see is about 4.4, not 4.5.
MOS here is an estimate from loss and jitter. It is 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. Do not treat it 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. Watch the trend.
3.1 – 3.6PoorAudible degradation. Investigate the trunk / access network.
< 3.1BadComplaints are likely. Escalate. The cause is usually heavy loss or a saturated path.
The values below are example points from the engine’s own E-model for a G.711 leg. Use them to 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. The engine computes it exactly per RFC 3550 §6.4.1. For each packet, the engine:
  1. Takes the transit time: the arrival clock minus the packet’s RTP timestamp, both in 8 kHz G.711 ticks.
  2. Takes the absolute change in transit from the previous packet.
  3. Folds that change into a running estimate with the RFC’s 1/16 gain:
This gives a stable exponential average. The average reacts to sustained variation but ignores single outliers. The engine accumulates it in timestamp ticks and reports it in milliseconds (ticks ÷ 8 at the 8 kHz clock). Jitter matters because the receive-side buffer must hold packets long enough to absorb it before playout. High jitter forces a deeper buffer, which adds mouth-to-ear delay. The E-model then charges that delay against R. If the buffer cannot keep up, late packets are dropped and become loss.
JitterRead
< 20 msHealthy. The jitter buffer absorbs it invisibly.
20 – 50 msAcceptable, but it adds buffering delay. Watch it on latency-sensitive AI turns.
> 50 msThe buffer is under pressure. Expect late-packet loss and a MOS dip.

​
Packet loss — sequence continuity

The engine measures loss from RTP sequence-number continuity, not from a timer. It anchors on the first packet’s sequence number. It tracks the highest sequence seen (with the 16-bit wraparound handled). At call close it computes:
Here expected is the span of sequence numbers between the first and last packet. A packet that arrives too late for playout (past the reorder buffer’s depth) counts as lost as well. From the listener’s point of view, that packet never arrived. The engine drops duplicates. Duplicates do not inflate the received count.
LossRead
< 1%Good. G.711 packet-loss concealment hides it.
1 – 3%Noticeable clipping on speech onsets. Concealment works hard.
3 – 5%Clearly audible dropouts. MOS falls below “good.”
> 5%Poor. The cause is usually a congested or lossy access network / trunk.

​
Where the numbers live

The engine computes the three metrics cheaply per packet on the caller’s media leg. When the call clears, it folds them into loss%/jitter_ms/MOS. It writes them to the call’s per-call media quality record (keyed by call_sid) and into the CDR next to the disconnect cause and duration. Thus you can sort, filter, and alert on quality per call, per trunk, or per tenant. You use the same reporting surface that shows call outcomes. You do not need a separate capture step or a packet trace for the common case.
The RTP media plane computes the quality fields. The fields describe the leg that the engine terminates (the PSTN/SIP caller leg). For browser and app legs, the media rides Opus over our QUIC transport. There, 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 find the cause.
1

Read jitter and loss together

One or both always explain a low MOS. 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 is one call or a population

A single bad call usually comes from the far end’s access network. A fleet-wide shift across a trunk or region is on your side: 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

Check the codec and path

Check that the leg negotiated the codec that you expect (see Codecs). A transcoded or mismatched path adds impairment, and the E-model will show it.
4

Pull a trace only if you need packet-level detail

When the aggregate numbers are not 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 loss follows.Provision headroom on the path. Check that QoS/DSCP marking is honored end to end.
Jitter high, loss near zero, MOS still fairA deep buffer absorbs the bursty arrivalThis is acceptable for voice, but the added delay hurts AI turn latency. See below.
Great MOS but callers report echo/robotic audioNot a network metric. This is an echo/AEC or codec issue.MOS does not catch it. Check the leg’s codec and see the one-way/quality troubleshooting page.
MOS 1.0 on many short callsToo few packets to measure, or one-way mediaCheck that two-way RTP flowed at all. See the one-way-audio troubleshooting page.
MOS is a listening-quality estimate from loss and jitter. It does not see echo, gain problems, or a wrong-codec artifact. 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 is not 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 are not enough.

High latency

Diagnose slow turns, which includes the buffering added to absorb jitter.