Diagnose the symptom, not the complaint
"The calls are bad" covers half a dozen unrelated faults with different fixes. The fastest route to a solution is to establish precisely what bad sounds like, because each symptom points at a different layer.
Ask three questions before touching anything. Is it every call or only some? Does it affect one direction or both? Does it correlate with time of day? The answers usually narrow the cause to one of the five below before you have opened a single config file.
1. Packet loss — choppy audio and dropped words
Sounds like: words or syllables missing entirely, audio cutting in and out.
Voice cannot be retransmitted usefully. By the time a lost packet could be resent, the moment it belonged to has passed, so every lost packet is a permanent small hole. Even 1% loss is audible on a voice call; 3% makes conversation difficult.
Find it: RTCP carries loss statistics, and Asterisk reports them per channel. Check during a bad call, not after. On the network path, a sustained ping test between the endpoints will usually reveal the same loss.
Fix it: loss is nearly always congestion on a link you control — most often a saturated upload. Prioritise voice with QoS on your own gateway, and set the shaper slightly below your real link rate so the queue forms on your router where you control it. If loss appears only beyond your border, it is your ISP's problem and no local configuration will fix it.
2. Jitter — stuttering and robotic audio
Sounds like: stuttering, warbling, a robotic quality — but the network reports little or no loss.
Jitter is variation in packet arrival timing. Packets all arrive, just unevenly, and the receiver needs a steady stream to reproduce natural speech. The jitter buffer absorbs some of this by delaying playout, but packets arriving too late for their slot get discarded — which sounds identical to loss.
The distinguishing signature is exactly that: audio sounds broken while packet loss reads as near zero. That combination is jitter, not loss.
Fix it: tune the jitter buffer to absorb more variation, accepting a little added latency. But treat that as mitigation — the underlying cause is again usually congestion, and QoS addresses it properly. Wi-Fi is a frequent contributor; moving handsets or the PBX onto wired connections resolves a surprising number of cases.
3. Latency — people talking over each other
Sounds like: audio is perfectly clear, but the conversation keeps colliding. Both parties start speaking at once and then both stop.
Latency does not distort audio at all, which is why people often fail to recognise it as a technical fault and simply find the calls tiring. Beyond roughly 150 ms one way, natural turn-taking breaks down.
Find it: measure round-trip time to the far end. Remember that your jitter buffer is deliberately adding delay too — an oversized buffer can create this problem while solving another.
Fix it: shorten the path. Choose a carrier with a closer point of presence, avoid routing calls through a distant data centre for no reason, and reduce unnecessary transcoding hops, each of which adds delay. If your jitter buffer is set very large, reconsider the trade.
4. Echo — hearing yourself back
Sounds like: the speaker hears their own voice returned a fraction of a second later.
Echo is usually not an IP problem at all. It is either acoustic — the far end's microphone picking up their own speaker, common with speakerphones and headsets at high volume — or hybrid echo introduced where the call meets analogue equipment such as an ATA or a PSTN gateway.
The clue is direction. The person who hears the echo is not the one causing it. The reflection is happening at the other end, so investigate there.
Fix it: for acoustic echo, reduce speaker volume, use a headset, or move the microphone. For hybrid echo at an analogue boundary, echo cancellation on the gateway is the answer, and impedance matching on the analogue side matters more than people expect.
5. One-way or no audio — a NAT problem
Sounds like: the call connects normally and one or both parties hear silence.
This is not a quality problem, it is a routing problem, and it is the most common single fault in VoIP. Signalling and media travel separately: a connected call proves only that SIP worked. The audio is RTP on different ports entirely, and it is usually NAT or a firewall stopping it.
The characteristic cause is a device behind NAT advertising a private address in its SDP, so the far end sends audio to an unroutable destination.
Fix it: set the server's external address and local networks, enable symmetric RTP so Asterisk replies to the address audio actually came from, and open the whole RTP port range on the firewall — not just port 5060. And disable SIP ALG on the router, which causes more of these than it ever solves.
A practical order of investigation
- Is there audio at all? If not, stop — it is NAT or firewall, not quality. Go to cause 5.
- Check loss and jitter from RTCP during a live bad call. Loss present means congestion; loss near zero with bad audio means jitter.
- Check latency if audio is clean but conversation is awkward.
- Check the direction of echo and investigate the opposite end.
- Correlate with time of day. Problems that appear at 09:00 and disappear at 18:00 are congestion, not configuration.
That last point is worth emphasising because it saves the most time. Configuration faults are constant; congestion follows the working day. If quality tracks office hours, stop reading config files and look at link utilisation.
Frequently asked questions
Why do my calls sound choppy?
Packet loss or jitter. If measured loss is significant, it is congestion. If loss is near zero but audio is still broken, it is jitter — packets arriving too late to be played.
Why is there no audio on a connected call?
Signalling succeeded but media did not. Almost always NAT or a closed RTP port range. Opening only port 5060 gives you exactly this symptom.
Who causes echo — me or the other party?
The other party. Echo is generated where the reflection occurs, so if you hear yourself, the problem is at their end or at an analogue boundary near them.
Why is quality fine in the morning and bad in the afternoon?
That pattern is congestion, not configuration. Something is saturating a shared link during busy periods — QoS on your own gateway is the fix.