One-Way Audio, Echo and Robotic Voice: What Causes Them

Which fault do you actually have?

Voice-over-IP calls fail in a small number of distinct ways, and each one has a different cause. Identifying the symptom precisely is most of the diagnosis, because the fixes do not overlap: the change that solves choppy audio will do nothing for one-way audio, and the change that solves one-way audio will do nothing for echo.

Symptom	Most likely cause	Where to look first
You hear them, they cannot hear you (or the reverse)	NAT or firewall blocking the return media stream	Router, VPN, microphone permission
Voice sounds robotic, metallic or underwater	Packet loss	Wi-Fi signal strength, network congestion
Audio chops in and out in short gaps	Jitter — packets arriving out of order	Wi-Fi interference, router quality of service
A noticeable delay before the other person replies	Latency, usually routing distance	Network path, server region
You hear your own voice back	Acoustic echo from the far end's speaker	The other person's setup, not yours
Volume is fine but words are indistinct	Codec or bandwidth throttling	Connection speed, provider codec choice

Work down this page to the row that matches. Guessing costs more time than checking.

Why can they hear me but I cannot hear them?

One-way audio is almost always a network address translation problem, not a microphone or speaker problem. A VoIP call sets up its signalling and its audio over separate channels, and one-way audio means the signalling succeeded — that is why the call connected at all — while the audio stream in one direction never found its way back.

Here is the mechanism. Your device sits behind a router that gives it a private address. When the call is established, your device announces where it expects to receive audio. If the router rewrites that address without also holding the corresponding port open, audio sent to you arrives at the router and is discarded, because nothing there knows which device inside the network it belongs to. Your outgoing audio is unaffected, because it opens its own path outward. The result is a call where one side is deaf.

What actually fixes it, in the order worth trying:

1. Switch networks. Move from Wi-Fi to mobile data, or the reverse. If audio returns, the problem is that specific network and you have proved the diagnosis in ten seconds.
2. Turn off any VPN. VPNs are the single most common cause of one-way audio on an otherwise working connection, because the media stream and the signalling can take different paths and only one of them traverses the tunnel.
3. Check the microphone permission if the fault is that they cannot hear you. A denied permission produces silence in one direction that looks exactly like a NAT fault. Confirm the microphone is producing signal with a microphone test before blaming the network.
4. Restart the router. Stale NAT table entries are real, and a restart clears them.
5. On a corporate or hotel network, expect it to be deliberate. Many managed networks block the UDP port ranges that carry voice media while leaving web traffic untouched. There is nothing to fix from your side; use mobile data.

Why does the voice sound robotic or underwater?

Robotic, metallic or underwater audio is packet loss. Voice is sent as a stream of small packets, typically one every 20 milliseconds. When some of them do not arrive, the receiving device has to invent the missing audio — a process called packet loss concealment — and the artefacts of that invention are exactly the metallic warble people describe.

The tolerances are narrow and worth knowing:

• Below 1% loss: unnoticeable.
• 1–3% loss: occasional roughness on consonants.
• Above 3% loss: clearly robotic, and intelligibility starts to drop.
• Above 5% loss: most listeners will ask you to repeat yourself constantly.

The dominant cause on a home connection is Wi-Fi, not the internet connection behind it. Wi-Fi loses packets when the signal is weak, when the channel is congested with neighbouring networks, or when the device is at the edge of range. The most effective single test is to stand next to the router and call again. If the fault clears, the internet service is fine and the wireless link was the problem.

Two practical fixes that work more often than they should: use the 5 GHz band rather than 2.4 GHz where both are available, because 2.4 GHz is shared with microwaves, Bluetooth and every neighbour's network; and stop any large download or video stream on the same connection, because a voice call needs very little bandwidth but needs it consistently, and a saturated uplink starves it.

Why does audio chop in and out?

Choppy audio in short bursts is jitter — variation in the arrival time of packets rather than outright loss. Packets that arrive too late to be played in sequence are discarded, which is heard as clipping at the start or end of words.

Every VoIP client holds a jitter buffer, a small store of audio that lets it smooth out irregular arrivals. A buffer of 30 to 50 milliseconds absorbs normal variation. When jitter exceeds the buffer, packets are dropped and the call chops.

Jitter is usually a symptom of congestion at the last hop rather than of a long-distance problem. If your router supports quality-of-service rules, prioritising voice traffic solves it directly. If it does not, the practical alternatives are the same as for packet loss: get closer to the access point, move to 5 GHz, or stop competing traffic.

Why do I hear my own voice back?

Echo is acoustic and it originates at the far end. Your voice reaches the other person's speaker, is picked up by their microphone, and is sent back to you. You hear yourself with a delay equal to the round trip.

This has an important consequence that people get wrong constantly: if you hear an echo, the fix is on the other person's device, not yours. Ask them to turn down their speaker volume or put on headphones. That solves it immediately in almost every case.

Genuine electrical echo, caused by impedance mismatch where a VoIP call meets a traditional analogue line, still exists on calls to old landline equipment. It sounds different — a fainter, more metallic reflection — and it is out of everyone's hands except the terminating carrier's. Echo cancellation in the network handles most of it.

Why is there a delay before the other person replies?

A conversational delay is latency, and its floor is set by physics and routing. Light in fibre travels roughly 200 kilometres per millisecond, so a call between London and Sydney has an unavoidable one-way delay of about 85 milliseconds before any equipment touches it.

The thresholds that matter for conversation are well established. The International Telecommunication Union's Recommendation G.114 puts 150 milliseconds one-way as the limit for transparent interactivity, 150–400 milliseconds as acceptable but noticeable, and above 400 milliseconds as unacceptable for normal conversation. The interruptions and talking-over that happen on very long routes are the audible consequence of crossing that threshold.

Little of this is under your control. What is: avoid adding a VPN hop through a distant country, avoid tethering through a second device, and prefer a wired or strong wireless connection, since a weak Wi-Fi link adds retransmission delay on top of the route.

Does the codec matter?

Yes, and it explains a specific complaint: calls where the volume is fine and the connection is fine but voices sound thin or muffled.

A codec is the algorithm that compresses voice for transmission. The two you are most likely to meet:

• G.711 is uncompressed telephone-quality audio, about 87 kbps with overhead. It sounds like a traditional phone call and is what most calls to the public telephone network use, because that network cannot carry anything better.
• Opus is a modern variable-bitrate codec, typically 16–40 kbps for voice, and it can carry a much wider frequency range. Two people on the same app using Opus can sound noticeably clearer than a normal phone call — this is what "HD voice" means in marketing.

The practical limit: a call to an ordinary phone number is capped by the phone network. No app can deliver wideband audio to a landline, because the landline does not support it. When a service advertises HD voice, that applies to app-to-app calls. A call to a real phone number sounds like a phone call, and that is a property of the destination.

For the data implications of each codec, see how much data voice calls use.

A five-minute diagnostic sequence

If you do not want to reason about causes, run this in order and stop when the call is fixed.

1. Test the microphone and speaker in a browser tab with the microphone test. This eliminates hardware and permissions in under a minute, which is where a surprising share of "network problems" actually live.
2. Call the same person on mobile data instead of Wi-Fi, or the reverse. This isolates the network in one step.
3. Disable the VPN, if any.
4. Move within a few metres of the router and call again.
5. Stop other traffic on the connection — a backup, a video stream, a game download.
6. Restart the router, then the device.
7. Call a different country. If one destination is bad and others are fine, the fault is on the terminating route and no amount of local troubleshooting will change it. Report it to the provider with the number, the time and the direction.

Steps 1 to 6 are yours. Step 7 identifies the cases that are not.

Bottom line

VoIP call faults are specific and each has one dominant cause. One-way audio is a NAT, VPN or permission problem — switch networks to confirm it in seconds. Robotic voice is packet loss, and on a home connection the culprit is nearly always Wi-Fi rather than the internet service. Chopping is jitter. Echo comes from the other person's speaker and is fixed at their end. Delay is routing distance and is mostly not fixable at all.

The fastest route to an answer is to change one variable — network, VPN, distance from the router — and see whether the symptom moves with it. A microphone test and a call over mobile data will between them explain the large majority of bad calls before you touch a single router setting.