VoIP Call Quality: Jitter, Packet Loss and MOS Explained With 3 Targets

Choppy audio, robotic voices and people talking over each other all come down to three network numbers: delay, jitter and packet loss. VoIP call quality is usually summarised as a MOS score, but the score is only a model built from those three inputs. Measure them directly and you can fix the cause instead of guessing, whether the calls run through your own PBX or a cloud phone system.

Short answer: Aim for one-way delay under 150 ms, jitter under 30 ms and packet loss under 1%. Those keep the E-model R-factor above 80 and MOS around 4.0 or better with G.711. Measure the path with mtr for loss and latency, iperf3 -u with small packets for jitter, and the RTCP statistics on the PBX during real calls; fix problems with QoS on the upload side and by keeping phones off congested Wi-Fi.

The three targets

Metric	Good	Noticeable	Poor	What users hear
One-way delay	under 150 ms	150 to 300 ms	over 300 ms	Talking over each other, awkward pauses
Jitter	under 30 ms	30 to 50 ms	over 50 ms	Choppy or robotic audio
Packet loss	under 1%	1 to 3%	over 3%	Missing syllables, dropouts

The 150 ms delay figure comes from ITU-T G.114. Jitter buffers in phones hide some variation, but they do it by adding delay, so a jittery line also becomes a laggy one.

MOS and R-factor

MOS (Mean Opinion Score) rates quality from 1 (bad) to 5 (excellent). Monitoring tools estimate it with the ITU-T G.107 E-model, which starts from a perfect R-factor, subtracts penalties for delay, loss and the codec, and converts the result to MOS. As a rule of thumb, R 90 or above (MOS about 4.3) is what users call excellent, 80 to 90 (MOS 4.0 to 4.3) is good, 70 to 80 is where some users complain, and below 60 most people are unhappy. G.711 on a clean network tops out around MOS 4.4; compressed codecs such as G.729 start lower.

Measure the path

Run these from the office towards the PBX or provider during business hours, not at night when the line is idle:

# latency and loss per hop over 5 minutes
mtr -rwzbc 300 sip.provider.example

# jitter and loss with voice-sized UDP packets (needs an iperf3 server at the far end)
iperf3 -c 203.0.113.50 -u -b 100k -l 200 -t 60

# on Asterisk, live per-call RTCP statistics
asterisk -rx "pjsip show channelstats"

Loss that appears only on the first hop means the local router or Wi-Fi is the problem. Loss that starts mid-path and continues to the end points to the ISP. Loss on a single middle hop that does not carry through is just that router de-prioritising replies to mtr and can be ignored.

Fix the common causes

• Upload congestion: mark RTP with DSCP EF and SIP with CS3, give them strict priority on the edge router, and shape total upload to about 90% of the real line rate so queueing happens where QoS can act.
• Wi-Fi: put desk phones on wired Ethernet with PoE; on wireless use 5 GHz, WMM enabled and roaming tuned. Bluetooth headsets add their own delay.
• Too many hops: choose a provider or PBX location close to the users; each 1,000 km adds roughly 5 ms of one-way delay in fibre, more with routing detours.
• VPN overhead: tunnels add delay and fragmentation risk; check MTU and consider sending voice outside the tunnel over SRTP.

VoIP call quality at a glance

Official documentation: ITU-T G.107 E-model, ITU-T G.114 one-way delay, RFC 3550: RTP and RTCP.

Related guides: VoIP codec bandwidth · VoIP one-way audio fix · VPN MTU fragmentation.

Frequently asked questions