VoIP Call Quality Problems: Choppy Audio, Echo, Delay and How to Fix Them

VoIP call quality problems come down to four causes, and each one sounds different: lost packets give choppy audio, packets arriving unevenly give a robotic voice, too much delay makes people talk over each other, and acoustic feedback produces echo. Most of the time the cause sits between your headset and your router, not at your provider. This guide starts from what you hear and works back to the fix.

You’re probably here because…

What causes VoIP call quality problems?

A VoIP call chops your voice into small packets, fifty per second with the most common settings, and sends them one by one across the network. Cisco’s documentation uses a default voice payload of 20 milliseconds per packet, which gives those fifty packets per second. At the far end, the phone or app puts them back in order and plays them.

So everything that can go wrong fits in three questions. Did all the packets arrive? Did they arrive at regular intervals? Did they arrive fast enough? A fourth cause has nothing to do with the internet: sound looping between a speaker and a microphone.

The next question is where it happens. A call crosses seven links, and four of them are on your side.

That map explains a rule you will use all the way down: always test from the nearest link to the farthest. Headset before computer, Wi-Fi before router, router before internet access, provider last. This is not about being polite to the provider. It is the order in which tests cost the least time.

What are the thresholds for good VoIP call quality?

Most numbers quoted on this topic come without a source. Here are the ones you can tie to a document.

Three notes so you read this table correctly.

The references do not all measure the same stretch. The delay in ITU-T Recommendation G.114 is mouth to ear, over the whole call. Microsoft’s targets cover the stretch between your device and the edge of its network. They are stricter because the rest of the path needs headroom. The page is archived, but it is one of the few public grids that give an “optimal” and a “poor” value for each measurement.

150 milliseconds is not a cliff. The G.114 summary only says that 400 milliseconds should not be exceeded for general network planning, and that highly interactive tasks, including many voice calls, can be affected by much lower delays. The three bands (0 to 150, 150 to 400, above) are how Cisco reads it.

An average hides bursts. A 0.5% loss spread across a call is inaudible. The same loss packed into two seconds wipes out a sentence. That is why serious grids give both an average and a maximum.

MOS and the E-model, in two sentences

You will meet two acronyms in quality reports. MOS is a mean opinion score: originally, listeners rate what they hear, using the method in ITU-T Recommendation P.800. The E-model, defined in ITU-T Recommendation G.107 (June 2015 edition in force), computes a rating from the characteristics of the connection (delay, loss, codec) without anyone listening, and Recommendation G.109 turns it into quality categories. When a tool shows you an “estimated MOS,” that calculation is what it runs: useful for comparing two measurements, not the truth about one given call.

Bandwidth is rarely the culprit

If your upload is very thin or heavily shared, it can run short: our VoIP bandwidth calculator does the math with your codec, your call count, Wi-Fi and any VPN. But on a decent business connection, chasing bandwidth is almost always wasted time. For a small office adding seats, our guide to a multi-line phone system for a small business checks whether your connection can carry the number of simultaneous calls you need.

Which symptom, which cause? Troubleshooting by symptom

Here is the overview. Each symptom is covered in detail below, with its tests and its fixes ordered from simplest to most technical.

Two questions to ask before you even look at the map, because they rule out half the leads.

Choppy VoIP calls: where do they come from and how do you fix them?

What you hear. Syllables skip, words go missing, the sentence arrives in pieces. The other party says “you’re breaking up.”

What is happening. Packets are getting lost on the way. Cisco writes that the G.729 codec requires packet loss far less than 1 percent to avoid audible errors, and that ideally there should be none. Recent codecs can conceal a single lost packet, or even rebuild it: Opus includes forward error correction that re-encodes important speech into a later packet (RFC 6716). No trick recovers a burst.

Who is usually responsible.

The test. Repeat the same call on an Ethernet cable, with heavy transfers paused. If the voice is clean again, the fault is in the local network, and you even know which half: Wi-Fi if the cable alone fixes it, congestion if stopping the transfers is what changes everything. Our VoIP speed test measures latency, jitter and speeds in thirty seconds and estimates a MOS, so you have a number before and after.

The fixes, simplest first.

1. 01

   Plug in a cable.

   For any desk that calls several hours a day, it is the safest and cheapest fix.
2. 02

   Move Wi-Fi to 5 GHz and get closer to the access point.

   Microsoft notes that the 2.4 GHz range is often affected by other consumer devices and that 5 GHz is better suited to real-time media, at the cost of more access points.
3. 03

   Move whatever saturates the link.

   Backups and updates at night, file sync throttled during calling hours.
4. 04

   Give voice priority on the router.

   That is Quality of Service, or QoS. See the network settings section below.
5. 05

   If a wired, idle line still loses packets, measure the access.

   A line that drops packets with nothing else running has a fault only the internet provider can fix.

A worked example: six calls and one file upload

The fix is not a faster line. With voice priority, the router serves the calls’ 523 kbps first and leaves the rest to the upload, which simply takes longer. On fiber with 100 Mbps of upload the margin is much wider, but the same mechanism comes back as soon as a full backup and several video meetings pile up. Remember the signature: several people affected at the same moment, at a regular time of day means congestion, not an outage.

Robotic or metallic voice: what does VoIP jitter mean?

What you hear. The voice takes on a robot tone, syllables stretch or squeeze, the speaking pace seems to speed up and slow down.

What is happening. All the packets arrive, but not at regular intervals. The receiver keeps a small buffer to even them out. Cisco’s document on delay describes the mechanism: with a buffer set to 40 milliseconds, a packet arriving more than 40 milliseconds late finds the buffer empty and leaves a gap of about the same length. Modern apps grow their buffer when jitter rises, which avoids gaps but adds delay. So you pay for jitter twice: in tone, then in latency.

Microsoft says it plainly on its network preparation page: calls with static that cut out, or voices that sound like robots, could be jitter or packet loss.

Who is usually responsible.

• Competing traffic with no priority. Voice packets wait behind a large transfer, then all go through at once.
• A VPN. Microsoft recommends sending real-time traffic around the tunnel: VPNs are typically not designed for real-time media, add a layer of encryption on top of media that is already encrypted, and can lengthen the route.
• The device itself. A computer with a maxed-out CPU (video meeting, screen share, dozens of tabs) processes audio late. The network is fine, the playback is not.
• Wi-Fi, again, when it has to resend packets.

The test. Turn off the VPN, close heavy apps, and measure jitter before and after with the VoIP speed test. Watch CPU usage during a call too.

The fixes. In order: close whatever loads the device; take the phone app out of the VPN (split tunneling, a request for whoever runs the VPN); go wired; give voice priority on the router.

VoIP echo: who is causing it?

What you hear. Your own voice coming back slightly late. Or the other party complains about theirs.

What is happening. The voice comes out of a speaker or a headset earpiece, and the nearby microphone picks it up and sends it back. The rule that surprises everyone: the person who hears the echo is not the one creating it. If you hear yourself, the leak is at the other end. If they hear themselves, it is at yours.

Delay makes it worse. An immediate return blends into the sound of your own voice; a late return stands out and becomes unbearable. Cisco notes, citing ITU-T Recommendation G.131, that echo cancellers are required once one-way delay exceeds 25 milliseconds, which is the case for practically every IP call. Phones and apps therefore have one. Echo appears when that canceller is overwhelmed.

Who is usually responsible.

The test. Ask the other party to lower their volume or mute for two seconds: if the echo stops, you found it. On your side, the mic test checks voice level, background noise, clipping and echo in twenty seconds, and nothing is uploaded.

The fixes. A closed headset instead of a speaker; a lower listening volume; a single microphone selected in the app’s settings; and if the echo comes from one desk only, a different headset. Choosing one is a guide of its own: how to choose a headset for calls.

VoIP delay and latency: why do you keep talking over each other?

What you hear. The audio is clean, but the conversation never settles. You start a sentence just as the other person starts theirs, you both stop, you both start again. Some call it the walkie-talkie effect.

What is happening. The delay between your mouth and their ear is too long. That delay adds up along the whole path. Cisco lists the pieces: encoding the voice, packetizing it, waiting in device queues, crossing the network, then the jitter buffer on arrival. One of them going wrong is enough.

The references again: up to 150 milliseconds one way is acceptable for most uses; the ITU says 400 milliseconds should not be exceeded for general network planning. Cisco adds that for international calls, one-way delay up to 300 milliseconds is acceptable, especially for satellite transmission.

Who is usually responsible.

• A detour. A VPN that exits in another region, or an unusual network route.
• Distance. A call to the other side of the world starts with delay you cannot remove. Coast to coast is rarely a problem; intercontinental can be.
• An inflated jitter buffer. The app enlarged its buffer to absorb an uneven link: clean audio, but late. Fix the jitter and the latency drops.
• Bluetooth. A wireless headset adds its own processing delay, both ways.
• A satellite link. Low-orbit constellations do far better than old geostationary satellite. Our article on VoIP over Starlink gives real latency, jitter and loss numbers.

The test. Measure ping with and without the VPN. Compare a Bluetooth headset and a wired one on the same call. Call a colleague at the same site: if the delay disappears, it comes from the route, not from your device.

The fixes. Take the phone app out of the VPN; go wired, for the network and for the headset; treat the jitter; and if the route itself is long, ask the provider which region the audio goes through.

One-way audio or a silent call: what should you check?

What you hear. The call connects, the timer runs, but one of you hears nothing. Or nobody hears anybody.

What is happening. A call is two separate things: signaling, which sets the call up, and the audio stream, which carries the voice in each direction. When signaling gets through and audio does not, you get an “answered” call with silence. Twilio’s troubleshooting documentation describes both cases: if the address advertised for receiving audio is a private one, the other side sends sound to a place it cannot reach; and if a firewall or the internet provider blocks the stream, it never arrives.

Start with the obvious. With an app in a browser or on a computer, the most common cause is not the network. A call placed from a browser runs on WebRTC, which needs the user’s consent to open the microphone: our article on VoIP vs WebRTC explains what that changes.

1. 01

   The microphone permission.

   Is the browser or the operating system allowed to use the mic? One accidental “block” is enough to make every call silent in one direction.
2. 02

   The right device.

   Is the app using the mic and output you think it is? A monitor, a webcam or a dock adds audio devices that sometimes take over.
3. 03

   The mute button.

   The one in the app, and the one on the headset.
4. 04

   Another network.

   Repeat the call on a 4G or 5G hotspot. If audio flows both ways, your network is blocking it.

If it is the network: firewall, NAT and SIP ALG. Three suspects. The firewall, which does not let audio streams through. The router’s address translation (NAT), which gets the recipient wrong. And SIP ALG, a feature found on many routers, often enabled by default, that rewrites addresses inside SIP messages to “help” the call get through. The VoIP-Info reference page describes the damage when the rewrite is done badly: one-way audio, because the caller told the other side to send audio to a non-routable address, and incoming calls that stop arriving.

The fix. Disable SIP ALG in the router’s admin page (it sometimes goes by another name, such as “SIP helper” or “SIP passthrough”), reboot, test. Cloud services handle NAT traversal themselves and do not need it. If you run a SIP trunk into an on-premise PBX, ask your carrier for the list of addresses and ports to allow on the firewall. Open nothing more: an overly permissive firewall is how toll fraud and phone system hacking get in.

Dropped VoIP calls: why always at the same moment?

What you hear. The call ends abruptly. No degradation, no choppy audio: a cut.

First question: after how long? Time three drops. The duration tells you where to look.

What the standards say about the router timer. RFC 4787, which sets the expected behavior of a NAT for UDP traffic, requires that a mapping not expire in less than two minutes and recommends a default of five minutes or more. Not every entry-level router complies. RingCentral, for instance, asks in its network requirements for a NAT expiration timeout above five minutes for some desk phones.

The fixes. For fixed-duration drops: disable SIP ALG, raise the router’s UDP timeout, then, if nothing changes, give the provider the exact duration, which they can match to a timer. For drops on the move: stay on one access point during the call, or go wired. For site-wide drops: check how stable the access is, and plan a backup link. A forward to a cell phone, set up ahead of time, is part of that plan: our guide to call forwarding and call transfer explains which type to pick.

Static, a distant voice, low volume: is it the headset?

What you hear. A steady hiss, crackling, a voice that clips as soon as it rises, or on the contrary a faraway voice, as if from the back of a room.

What is happening. This is not the network. Microsoft points it out in its documentation: lower quality devices, or devices with incorrect drivers, produce lower sound quality, and a noisy environment gives muffled or unclear audio. A good network faithfully carries a bad signal.

The test and the fix. The mic test gives a verdict on level, background noise and clipping, and lets you play yourself back. Then check which device the app has selected, and try a colleague’s headset: if the fault stays with the desk, it is the desk; if it follows the headset, it is the headset.

How do you run the diagnosis in ten minutes?

When the symptom is unclear, or there are several, this routine isolates the cause in six moves. You need an Ethernet cable and a phone that can share its connection.

1. 01

   Minute 1: the sound, without the network.

   Run the mic test. A fault here (clipping, hiss, echo) has nothing to do with the internet. Fix it first.
2. 02

   Minutes 2 and 3: three measurements, where you usually call from.

   Run the VoIP speed test and write down latency, jitter and upload speed. Those are your baseline.
3. 03

   Minutes 4 and 5: the same measurements on a cable.

   Plug the device straight into the router, turn off the VPN, test again. If the numbers improve sharply, Wi-Fi or the VPN is the cause.
4. 04

   Minutes 6 and 7: a wired test call.

   Call a number you control, your cell phone for example, and talk for two minutes. Perfect quality: the fault is in your local network. Same fault: it is upstream.
5. 05

   Minutes 8 and 9: the same call on another network.

   A 4G or 5G hotspot. If the fault disappears, it is your internet access or your router. If it persists on two networks, it is your account, your device or the provider.
6. 06

   Minute 10: write down what you found.

   Date, time, symptom, numbers, the result of each attempt. That is the basis of the report you send the provider if it comes to that.

Which network settings improve call quality?

Six settings come up in every hard case. The first two need no configuration at all.

An honest caveat about voice priority: it works inside your network and at its exit, where your upload is contested. Microsoft notes that the marking is not preserved across the public internet. QoS will not repair a line that loses packets at the internet provider; it stops your own traffic from getting in its own way, which is the most common situation.

And a word about codecs. You usually have no say: the app or the carrier picks one. Two things are still worth knowing. Low-bitrate codecs such as G.729 save bandwidth but cope less well with loss. And each conversion from one codec to another along the route costs a little quality and delay. If a provider proposes a codec change as the cure, ask what it gains and what it gives up.

Which troubleshooting mistakes waste the most time?

Six reflexes show up in almost every investigation that stalls. None of them is absurd: they are just taken in the wrong order.

When is the provider at fault, and how do you report it?

The provider is the cause when the fault survives a wired test with no other traffic and a second network; when it hits every site at once; or when it only concerns one destination, one country or one terminating carrier. In those cases nothing on your network will change it.

Before you write, make sure you are knocking on the right door. Each link has an owner.

Support teams fix quickly what they can find in their logs. For that they need a precise time and phone numbers. “Quality has been bad for a week” cannot be found anywhere. Here is the report to copy.

Subject: call quality fault, [symptom], on [date]

1. Exact date and time of the call, with time zone: … 2. Direction (inbound or outbound), calling number and called number: … 3. Symptom as heard, and on which side: choppy audio, robotic voice, echo, delay, one-way audio, drop after … seconds. 4. Frequency: a single call, several a day, every call, always to the same destination. 5. Who is affected: one desk, one site, every site. 6. Device and app: computer or phone, operating system, browser or app and its version, headset used. 7. Connection: Wi-Fi or wired, internet provider, VPN on or off. 8. Measurements taken: latency … ms, jitter … ms, upload … Mbps, at … (time). 9. Tests already run: wired call (result), call on another network (result), SIP ALG disabled (yes or no), different headset (result). 10. What I am asking for: an analysis of this call in your logs, and the segment where the degradation appears.

Three calls documented this way are worth more than thirty complaints. And if support answers that everything looks normal on their side, you have what you need to ask which segment they looked at.

How do you keep the problems from coming back?

Once the fault is fixed, three habits save you from repeating the investigation in six months.

1. 01

   Keep your baseline numbers.

   Latency, jitter, upload speed, on a day when everything works. Without a baseline, a single measurement tells you nothing.
2. 02

   Measure at peak hours, not just in the morning.

   Congestion shows at 11 a.m. and 3 p.m., not at 8. Microsoft advises measuring over a full week to see the peaks.
3. 03

   Log every change.

   New router, new VPN, an office move, a new headset model. Most degradations have a birth date.

For a team split between the office and home, add an equipment rule: a wired or dongle headset and an Ethernet cable in the welcome box. The rest of a remote desk is covered in our guide to a phone system for remote teams. Our article on the softphone covers what a calling app needs on a device, and the VoIP for sales teams comparison covers choosing the service.

What about Skipcall?

Skipcall is a cloud phone system for teams that make calls: you call from the web app or the mobile app, with one number per user, from $25 per seat per month for the Business VoIP plan. Everything above applies to it as it does to any calling app: headset, Wi-Fi, voice priority, VPN and SIP ALG are settings on your side.

Two things are specific to Skipcall. The three free tools used in this guide (VoIP speed test, bandwidth calculator, mic test) work without an account and are useful whoever your provider is. And calls can be recorded and transcribed: replaying a degraded call lets you give support the exact time and the nature of the fault.

What Skipcall does not do, to be clear: no auto attendant, no call queues, no inbound call routing. If your fault involves an on-premise PBX or a trunk, the NAT and SIP ALG sections still apply, but the carrier behind that trunk is the one to work with.

What to remember

• Start from the symptom. Missing words: packet loss. Robot voice: jitter. Talking over each other: latency. Hearing yourself: echo, and the cause is on the other side. Audio in one direction: a blocked stream. A drop at a fixed duration: a timer.
• Test from nearest to farthest. Headset, device, Wi-Fi, router, internet access, provider.
• Five fixes cover most cases: Ethernet, wired headset, 5 GHz Wi-Fi, voice priority, SIP ALG off.
• The references have a source: 150 then 400 ms of one-way delay (ITU-T G.114), loss far below 1% (Cisco), jitter poor above 30 ms (Microsoft), 87.2 kbps per G.711 call (Cisco).
• Ten minutes is enough to know whether the fault is yours: one cable, three measurements, a second network.
• Your provider needs facts: a time, two numbers, a symptom, measurements and the list of what you already tried.