To fix packet loss on VoIP calls, work in three moves: identify which direction is losing packets (does the far end hear you choppy, or do you hear them?), localize the loss to a network segment with ping, mtr, and RTCP stats, and then apply the fix that matches the cause — QoS marking, smart queue management, wired Ethernet, or a VPN/MTU correction. Rebooting routers and swapping codecs at random rarely works, because packet loss is one symptom with half a dozen distinct causes, and each cause has a different fix.
Below: how to read the symptom’s direction, localize the loss with real tools, and apply the fix that matches the cause. Definitions and acceptable thresholds live in our jitter, latency, and MOS benchmarks — the working shorthand for this guide is that trouble starts near 1 percent loss and calls fall apart past 3. One caveat the averages hide: losing two or more consecutive 20 ms packets is audibly worse than the same percentage spread evenly, so a connection averaging 0.8 percent loss can still sound broken if the loss arrives in bursts.
Read the symptom first: choppy audio has a direction
Voice media rides RTP, and RTP is two independent one-way streams — the mechanics are in our RTP protocol explainer. That means packet loss is directional, and the complaint itself tells you which path to investigate before you touch a terminal:
The far end hears YOU choppy. Loss is on your upstream (send) path. Typical culprits: a saturated uplink or bufferbloat on your router, WiFi on your side, or a VPN eating your upstream. This is the classic call-center pattern — agents sound fine to themselves, customers complain.
You hear THEM choppy. Loss is on your downstream (receive) path: a congested downlink, an ISP or middle-mile path problem, or trouble on the far end’s upstream.
Both directions are bad. The two streams share a congested hop — usually your access link saturated in both directions, or a mid-path problem.
One disambiguation before you go further: one-way audio — total silence in one direction, not choppiness — is usually a NAT or SIP ALG problem, not packet loss. If a direction is completely dead rather than degraded, rule out ALG first; it is a different problem class with a different fix.
What actually causes packet loss, ranked by likelihood
- WiFi. Airtime contention, interference, and retransmit limits. RTP is UDP — there is no retransmission, so every frame WiFi drops is audio gone. If your phones or PBX are on wireless, this is suspect number one.
- Bufferbloat / saturated uplink. Bulk traffic — uploads, backups, video — fills the router’s oversized upload queue, and time-sensitive voice packets get dropped or delayed hundreds of milliseconds. This is the most common cause of “calls only sound bad when someone is uploading.”
- Duplex mismatch. One side of a link negotiates full-duplex, the other half-duplex. The classic pattern: massive loss as soon as utilization rises, clears after a reboot, then comes back.
- ISP or path congestion. Loss that appears only at peak hours points at the ISP or middle-mile path rather than your LAN.
- VPN overhead. Encapsulation adds latency and CPU cost, and it can push packets past the tunnel MTU — fragments then get silently dropped, which looks exactly like random packet loss.
- Failing hardware or cabling. A bad NIC, a damaged cable, or an overloaded switch produces consistent loss on a wired LAN regardless of traffic load.
Localize the loss: ping, mtr, and RTCP without guessing
Start with a long ping. Run ping with 100 or more packets to your carrier’s SIP proxy. This gives you baseline loss and latency to the endpoint that actually matters — not to a speed-test server.
Run mtr and read it correctly. mtr shows per-hop loss along the path, and most people misread it. Three rules:
- Loss shown only at an intermediate hop that does not continue to the final hop is ICMP rate-limiting on that router. It is cosmetic. Ignore it.
- Real loss starts at a hop and persists at an equal or greater percentage through every hop after it, down to the destination.
- If the final hop shows 0 percent loss, the path is clean — whatever the middle hops display.
Run mtr to multiple destinations — your carrier’s SIP proxy plus a couple of anycast IPs like 8.8.8.8 and 1.1.1.1. Loss to everything means your access link or LAN; loss to one destination only means a path problem specific to that route.
Test for bufferbloat. Start a continuous ping, then kick off a large upload. If latency jumps from roughly 10 ms idle to 200 ms or more under load, you have bufferbloat, and your voice packets are dying in that queue. Fix is in the next section.
Read RTCP to get direction, not just presence. Because RTP is two one-way streams, RTCP receiver reports show loss as each endpoint saw it — capture RTCP or read the RTCP stats on your PBX or phones and you know definitively which direction is losing packets, not just that “quality is bad.” RTCP XR, where supported, adds burst metrics and jitter-buffer stats on top.
Capture packets when the tools disagree. Wireshark on the PBX or LAN lets you compare RTP sequence numbers sent against sequence numbers received. If every packet leaves your network in order and the far end still reports gaps, the loss is beyond your edge — and now you can prove it.
Use an echo test to check the round trip. An echo test call reflects your own audio back through the real network path. Asterisk-based systems — including VICIdial builds — ship a built-in echo test application. If the echo comes back clean, your path to the provider is fine in both directions; if it comes back choppy, the impairment is somewhere between your handset and the provider’s media edge.
Fix it: remedies ranked by effort
1. Get voice off WiFi. Wired Ethernet for phones and the PBX. Cheapest fix, biggest single reduction in loss and jitter for wireless deployments. Do this before anything clever.
2. Mark and honor QoS. Voice media should carry DSCP 46 — Expedited Forwarding, defined in RFC 3246 for exactly this: low delay, low loss, low jitter, strict priority. Most IP phones already mark EF by default; the part people skip is configuring the router and switches to actually honor the marking. Call signaling is commonly marked CS3. Be realistic about scope: ISPs generally do not honor DSCP across the public internet, so QoS protects the links you control — your LAN and, critically, your own uplink queue. That is where most of the damage happens anyway.
3. Kill bufferbloat with SQM. Enable smart queue management — CAKE or fq_codel, e.g., OpenWrt’s SQM — shaped to roughly 85 to 95 percent of your measured up and down speeds. Per-flow queuing keeps 20 ms voice packets from waiting behind a bulk upload. CAKE adds shaping, DSCP awareness, and per-host fairness on top of fq_codel. If the ping-under-load test failed, this is your fix.
4. Fix the duplex mismatch. Force or correctly auto-negotiate full duplex on both ends of the suspect link. Setting one side manually while the other auto-negotiates recreates the mismatch.
5. Get voice out of the VPN — or fix the tunnel. Split-tunnel so voice bypasses the VPN (or so only voice rides it), or adjust tunnel MTU/MSS so encapsulated packets stop fragmenting and blackholing. Lower-overhead tunnels (WireGuard, IPsec) behave better for real-time media than TLS-based tunnels.
6. Add codec resilience — as mitigation, not cure. Opus with in-band FEC embeds a redundant low-bitrate copy of the previous frame in the next packet, so single lost packets are reconstructed; in codec testing it remains intelligible at loss levels where G.729 audibly breaks up (roughly 2 to 3 percent and beyond). G.711’s packet loss concealment (ITU-T G.711 Appendix I) papers over occasional single-packet loss. SIPNEX passes G.711 through natively and supports Opus where your system does. But a codec that hides loss does not remove it — fix the network, then let FEC and PLC cover the residue. Full codec trade-offs live in our G.711 vs G.729 comparison.
When it’s the carrier — and how to hand off the evidence
The ownership line is simple: your carrier owns the path from its edge to the PSTN; you own the path from your server to the carrier’s edge. Most packet loss lives on your side of that line — but not all of it.
You have a credible carrier-side case when your evidence points past your edge: a long ping and mtr to the carrier’s SIP proxy show a clean path, your Wireshark capture shows every RTP packet leaving your network in sequence, and RTCP receiver reports still show loss — or the far end still hears gaps.
At that point, escalate with the evidence instead of the complaint: call examples with exact timestamps and numbers, your mtr output to the proxy, and the RTCP loss figures from both directions. Run your PBX’s built-in echo test and note whether the reflected audio is clean. Then ask your carrier to check the RTCP and media stats on their edge for those calls — a carrier that runs its own media infrastructure can read the same directional loss data from their side of the line and tell you whether the impairment is on their edge, on the far-end termination, or pointing back at your access link.
A carrier cannot fix your uplink queue, and you cannot fix their media path. The diagnosis workflow above exists so each side fixes the segment it actually owns — with data, in one pass, instead of a week of ticket ping-pong.
Frequently asked questions
Why do my calls sound choppy to the other side but fine to me?
Because RTP is two independent one-way streams, packet loss is directional. If the far end hears you choppy while their audio reaches you clean, the loss is on your upstream (send) path. The usual causes are a saturated uplink or bufferbloat on your router, phones on WiFi, or a VPN carrying your outbound media. Test it: start a continuous ping to your carrier’s SIP proxy, then start a large upload — if latency spikes from around 10 ms to 200 ms or more, your upload queue is the problem, and smart queue management (CAKE or fq_codel shaped to 85–95 percent of your measured speed) is the fix.
My mtr shows loss at an intermediate hop but 0% at the destination — is that real packet loss?
No. Routers deprioritize ICMP responses directed at themselves, so an intermediate hop can show 20 or 30 percent “loss” while forwarding your actual traffic perfectly. The rule: loss that appears only at one middle hop and does not continue through the hops after it is ICMP rate-limiting, and it is cosmetic. Real loss starts at a hop and persists at an equal or greater percentage all the way to the final hop. If the final hop shows 0 percent loss, the path is clean, whatever the middle rows display.
Does switching codecs fix packet loss?
No — it hides some of it. Opus with in-band FEC reconstructs single lost packets from redundant data in the following packet, and G.711’s packet loss concealment interpolates over occasional gaps, so a loss-resilient codec keeps calls intelligible under loss that would make G.729 break up audibly. But the packets are still being dropped, and burst loss defeats concealment quickly. Treat codec resilience as a buffer while you fix the actual cause — WiFi, bufferbloat, a duplex mismatch, or a path problem — not as the fix itself.
Is one-way audio caused by packet loss?
Almost never. Packet loss degrades audio — gaps, stutter, choppiness — but audio still flows. Total silence in one direction is a signaling or NAT problem: most commonly a router’s SIP ALG rewriting packets, or NAT dropping the media stream because the return path was never established. If one direction is completely dead rather than degraded, disable SIP ALG and check your NAT traversal setup before running any packet loss diagnostics — you would be measuring the wrong problem.
Will enabling QoS on my router stop packet loss?
On the links you control, yes — and that is where most loss happens. Marking voice with DSCP 46 (Expedited Forwarding) and configuring your router and switches to honor it protects voice packets from competing traffic on your LAN and in your uplink queue. What QoS cannot do is influence the public internet: ISPs generally do not honor DSCP markings across their networks, so EF marking does nothing for loss on the ISP path or beyond. Pair QoS with smart queue management on your uplink for the local half, and use mtr evidence to escalate anything past your edge.
Built for high-volume and predictive-dialer traffic, SIPNEX SIP trunks pass G.711 through natively — no transcoding, low PDD, Opus where your system supports it — from an FCC-licensed carrier. We handle the carrier side of the line; you handle the local network — and this guide is how you prove which side the loss is on. If your diagnostics point past your edge, send us the evidence or compare our rates while the mtr is still running.
Keep reading.
The carrier built by operators, for operators.
FCC-licensed carrier with its own STIR/SHAKEN SP certificate. Operator-owned. SIP trunks built for operators who dial at volume.