Why does only one direction sound robotic?

Because loss and transcoding are per-direction, per-leg phenomena. Your uplink may cross the congested path while the downlink is clean, or one leg transcodes and the other doesn't. The capture for each direction tells separate stories — read both.

Is G.729 a bad codec?

No — it is an efficient codec (8 kbps payload) designed for constrained links, with quality that degrades faster under loss than G.711's. On modern broadband the bandwidth saving rarely justifies it on office legs; on genuinely thin links it remains the right tool.

Can a headset cause robot voice?

A failing headset produces distortion, dropouts and crackle — usually constant, not the warbling PLC signature. The capture test settles it: if the network stream is clean, swap the endpoint and listen again.

Troubleshooting · Symptoms

Robotic or Metallic Voice: What's Really Happening

By the VoIP Cost Guide Editorial Team | Last updated: October 2026

'You sound like a robot' is a precise symptom once you know the machinery. When voice packets go missing, the receiver doesn't play silence — it conceals the gap by synthesizing a guess (packet loss concealment, PLC), repeating and warping the last fragments of sound. A little concealment is inaudible. A lot produces exactly that metallic, warbling, robotic effect. The other route to robot-voice is codec damage: aggressive compression or a needless transcode mangling the signal before loss even starts.

So the diagnostic split is: is the capture showing loss (a network problem), or is the audio arriving intact but pre-damaged by encoding (a codec-path problem)?

How to tell loss from codec damage in a capture

Open the bad call's RTP stream analysis. Loss case: lost-packet counters above ~1–2%, jitter spikes, and sequence gaps visible in the stream graph — the receiver genuinely never got the audio and PLC invented the robot voice locally. Codec case: loss near zero, jitter healthy, yet the audio (play it in Wireshark) already sounds robotic — meaning damage happened before or during encoding: a low-bitrate codec (G.729) being asked to carry music-on-hold or a noisy room, a tandem transcode (G.711→G.729→G.711) somewhere in the path, or a faulty DSP/gateway. Check the SDP in the call setup for the negotiated codec on each leg; a call that changes codec families mid-path is being transcoded, and every transcode costs quality that PLC then finishes off.

# RTP stream analysis — the two signatures
Loss case:    Lost: 4.8%   Jitter: 41 ms   -> network fault, fix the path
Codec case:   Lost: 0.0%   Jitter: 2 ms    -> audio damaged before transport
SDP check:    INVITE offers G.711 only -> answer adds G.729 first
              = a transcoding leg exists somewhere. Find it.

Common root causes, in order

Packet loss from congestion or Wi-Fi — by far the most common; work the jitter guide's measurement sequence.
G.729 (or another low-bitrate codec) on a path that doesn't need it — chosen to save bandwidth nobody lacks anymore; its PLC under even 1% loss sounds dramatically worse than G.711's.
Tandem transcoding — provider or SBC converting codecs mid-path, sometimes twice; visible in SDP comparisons between legs.
Music on hold and speakerphone noise through low-bitrate codecs — codecs are tuned for single human speech; hold music through G.729 is nobody's idea of fidelity and is a codec artifact, not a fault.
A failing gateway DSP or phone — robotic audio on one site/phone with perfect network metrics; swap-test the endpoint.

Fix sequence

Capture a bad call and classify it with the loss-vs-codec test above before changing any setting.
If loss: follow the jitter/packet-loss workflow (congestion point, QoS, Wi-Fi) — robot voice is loss wearing a costume.
If codec: align codec lists end-to-end (prefer G.711 on LAN/provider legs with bandwidth to spare; Opus where supported), and remove forced transcoding in SBC/PBX settings.
Re-check music-on-hold expectations after the fix: if hold music still sounds poor on a healthy G.729 leg, that is the codec's nature, not a regression.
Verify with the same caller/callee pair and a capture showing the improved stream statistics.

Frequently asked questions

Why does only one direction sound robotic?: Because loss and transcoding are per-direction, per-leg phenomena. Your uplink may cross the congested path while the downlink is clean, or one leg transcodes and the other doesn't. The capture for each direction tells separate stories — read both.
Is G.729 a bad codec?: No — it is an efficient codec (8 kbps payload) designed for constrained links, with quality that degrades faster under loss than G.711's. On modern broadband the bandwidth saving rarely justifies it on office legs; on genuinely thin links it remains the right tool.
Can a headset cause robot voice?: A failing headset produces distortion, dropouts and crackle — usually constant, not the warbling PLC signature. The capture test settles it: if the network stream is clean, swap the endpoint and listen again.

Sources and further reading

Related guides

Disclaimer: This guide is educational information based on published VoIP standards and professional practice, not engineering advice for your specific system. VoIP pricing, taxes and fees change and vary by provider and location — verify current figures with providers before purchasing. If your phone system supports emergency calling, work with your provider or a qualified VoIP engineer for changes that affect E911.