VoIP Call Quality: Diagnosing Jitter, Latency, and Loss

The four numbers that define a call

"The phones sound bad" is not a diagnosis. Voice quality is measurable, and four metrics explain nearly every complaint you will ever get. Learn their thresholds and most tickets stop being subjective.

• One-way latency (mouth-to-ear delay). The time for your voice to reach the other person. ITU-T Recommendation G.114 puts the comfortable ceiling at about 150 milliseconds one way. Up to roughly 400 milliseconds is usable but people start talking over each other; past that, conversation collapses into walkie-talkie turn-taking. This is one-way, not round-trip, so a 250 millisecond ping already spends most of your budget.
• Jitter. The variation in arrival time between packets. Voice tolerates a lot of steady latency but very little variance. Keep jitter under about 30 milliseconds; under 15 is comfortable. Bursty jitter is what the jitter buffer has to absorb, and when it cannot, you get dropouts.
• Packet loss. Voice is real-time, so a lost packet is gone, not retransmitted. Under 1 percent is generally inaudible thanks to packet-loss concealment; 1 to 3 percent produces the clipped-syllable, robotic effect; above 3 percent calls become hard to use.
• MOS (Mean Opinion Score). The 1-to-5 summary of perceived quality, either scored by listeners or estimated from the metrics above by tools like an SBC or probe. G.711 tops out near 4.4. Above 4.0 is good, 3.6 to 4.0 is acceptable, and below roughly 3.6 is where users pick up the phone to complain instead of talk.

The reason these are worth trending rather than spot-checking is that voice degrades gradually. Jitter and loss creep up during the busy hour before anyone files a ticket, and the trend line is your early warning.

Figure: voice metrics drift during peak load, so trending them beats spot checks — the slope warns you before MOS falls below 3.6.

Mark and queue voice end to end

Voice packets are small, frequent, and completely intolerant of waiting behind a file transfer. Quality of Service exists to give them their own express lane, and it has to hold across every hop.

• Mark at the source, trust at the edge. IP phones and softphones tag RTP media with DSCP EF (Expedited Forwarding, value 46) and signaling with CS3 or AF31. Establish a trust boundary at the access switch so it honors those marks from known phones and rewrites everything else — otherwise any endpoint can claim priority.
• Give voice a priority queue. On every WAN and LAN egress point, EF traffic belongs in a low-latency queue (LLQ) that is serviced first. Without it, a single large download can park voice packets behind a full interface buffer and spike latency and jitter instantly.
• Do not lose the marking over Wi-Fi. Wireless maps DSCP to WMM access categories; EF should land in the Voice category (AC_VO). If that mapping is broken, voice competes as best-effort on the air, which is where a lot of "only wireless calls are bad" tickets originate.
• Accept that the public internet ignores you. Your DSCP marks are stripped or ignored the moment traffic hits a commodity internet circuit. QoS only guarantees behavior on links you control, which is exactly why the WAN design underneath your voice matters so much.

That last point is the strongest argument for engineered transport. An SD-WAN fabric can steer voice onto the lowest-loss, lowest-jitter path in real time and fail it over mid-call when a circuit degrades, and a private global network keeps QoS honored end to end instead of hoping the internet cooperates.

Jitter buffers and codec choice

Two knobs at the endpoints shape how the network's imperfections actually sound.

The jitter buffer holds arriving packets briefly so they can be played out evenly despite variable arrival. It is a direct trade-off: a deeper buffer smooths more jitter but adds latency, while a shallow buffer keeps delay low but drops packets that arrive late. Modern endpoints use an adaptive buffer that grows and shrinks with measured jitter, typically operating in the 20-to-50 millisecond range. When you see loss reported at the receiver but the network shows none, late packets discarded by the jitter buffer are usually the culprit.

Codec choice sets the ceiling on quality and the floor on bandwidth:

• G.711 — uncompressed, MOS near 4.4, about 87 kbps per call with IP, UDP, and RTP headers on Ethernet. Best quality, heaviest on the wire. The right default on a healthy LAN or a well-provisioned WAN.
• G.729 — compressed to roughly 8 kbps payload (about 31 kbps with overhead), MOS near 3.9. The classic choice for bandwidth-constrained WAN links, at a modest quality cost and more sensitivity to loss.
• G.722 — wideband "HD voice" at 64 kbps that carries a wider frequency range, noticeably clearer than G.711 when both ends support it.
• Opus — the modern variable-bitrate codec behind most WebRTC and softphone traffic. It flexes from about 6 to 510 kbps, does wideband audio, and is unusually resilient to loss, which makes it a strong fit for internet-transported calls.

The practical rule: use the highest-quality codec your worst link can carry at peak, and size bandwidth for the codec plus overhead, not the raw payload number.

Where call quality actually breaks

In the field, the same handful of causes account for most degradation.

1. Wi-Fi. Wireless is half-duplex and contention-based, so retransmissions, channel congestion, and roaming between access points all inject jitter and loss. Wire deskphones where you can, and where you cannot, treat the wireless design (channel plan, AP density, WMM) as part of the voice project, not an afterthought.
2. Oversubscription and microbursts. A WAN link that averages 40 percent can still hit 100 percent for a few seconds when a backup job or a big sync fires, dropping voice in those windows. Five-minute utilization graphs hide it; you need QoS to protect voice and fast sampling to see the bursts.
3. The commodity internet. Best-effort circuits give no loss or jitter guarantee, and problems often live at a peering or last-mile point neither you nor the ISP watches closely. This is where measured path data, not a status page, settles the argument.
4. LAN faults. Duplex mismatches, a failing cable or optic throwing CRC errors, and undersized switch buffers all show up as loss on exactly one path. These are fast to find once you are looking at interface counters.

Troubleshoot it systematically

Work the problem in order instead of guessing. The goal is to localize the fault to a segment, then fix and verify against the numbers.

1. Characterize the complaint. One direction or both? One site, one subnet, or one codec? Wired or wireless? Every answer eliminates half the search space. Voice problems are frequently one-way, which immediately points at a specific path or queue.
2. Pull the call's own stats. Your SBC, PBX, or CDR records per-call jitter, loss, and MOS. Start there — it tells you which metric failed and at which end before you touch the network.
3. Test the path. Run a continuous path measurement across the suspect segment to capture loss and jitter over time, and take a packet capture at both ends. Compare what the sender transmitted to what the receiver got.
4. Verify QoS survived. Confirm packets are still marked EF at the WAN edge and are actually landing in the priority queue. Broken trust boundaries and lost marks over Wi-Fi are common, quiet failures.
5. Isolate LAN, WAN, ISP, or carrier. Use the path data to assign the loss to a segment, then engage the right owner with evidence rather than a vague report.
6. Fix and confirm. Re-measure after the change. If MOS is back above 4.0 and loss under 1 percent, you are done; if not, you localized the wrong segment.

Continuous synthetic call testing turns this from a fire drill into routine operations — probes place simulated calls around the clock and alert on jitter and loss before users do. That is the core of a mature infrastructure monitoring practice for voice.

Keep calls clear before users notice

Good VoIP quality is not luck. It is the four metrics measured and trended, QoS that holds from handset to far end, jitter buffers and codecs matched to the path, and a troubleshooting method that localizes faults instead of guessing. Get those right and "the phones sound bad" stops being a recurring ticket.

intSignal designs, marks, and monitors voice-grade networks end to end, from QoS policy and SD-WAN path selection to round-the-clock call-quality monitoring. If your calls are dropping syllables and no one can say why, talk to our team and we will find the fault and fix it.