One-way audio and choppy calls — a structured diagnosis walkthrough

"They can hear me but I can't hear them" (or the reverse), or audio that's there but unusable — choppy, robotic, breaks up — is the second-most-asked PBX support question after registration. The root cause is one of four things almost every time: NAT, codec mismatch, MTU/fragmentation, or jitter. This article walks you through the diagnosis in order.

Confirm it's actually an audio problem

Before diving in, rule out signaling-only failures:

• Does the phone ring at all? If no, it's a routing / DID problem, not an audio problem.
• Does the call answer and you hear silence? Audio path is broken.
• Does the call answer and audio works for a moment then breaks? Probably NAT pinhole timeout, jitter, or RTP port range issue.
• Does only one direction work? Classic NAT-in-the-middle symptom.

Step 1 — NAT diagnosis

If one direction of audio works and the other doesn't, NAT is the prime suspect. See SIP behind NAT for the full explanation; the quick summary:

• Your LYLIX PBX has a public IP, so PBX ↔ carrier audio is unaffected.
• Phones in customer locations sit behind a NAT router. The phone's SDP advertises its private IP; without NAT traversal, the PBX tries to send RTP to that private IP and fails.

Quick check in FreePBX®:

• Settings → Asterisk SIP Settings → Chan PJSIP → External Address set to PBX public IP.
• Local Networks includes the customer's office LAN range (e.g., 192.168.1.0/24).
• On the extension itself: NAT mode is set appropriately for the customer location.

Quick check on the phone:

• STUN configured to the carrier's STUN server or a public one (stun.l.google.com:19302 etc.).
• Keep-alive interval ≤ 30 seconds so the NAT pinhole stays open. See SIP trunk drops every 30 minutes for the math.

Step 2 — Codec mismatch

If both endpoints support a codec but the PBX or trunk negotiated to a different one nobody can decode, audio fails — sometimes with silence, sometimes with garbled audio.

Check the codec list in this order:

• Extension codecs — explicitly include ulaw (G.711) as the universal fallback.
• Trunk codecs — match what the carrier supports. Telnyx and Flowroute accept G.711 ulaw and G.722; G.729 needs a licence.
• Global SIP codec order — verify in Settings → Asterisk SIP Settings the codec preference starts with ulaw.

Diagnostic check from the Asterisk CLI:

asterisk -rvvv
pjsip set logger on
<make a test call>
<watch the INVITE / 200 OK SDP>

The SDP m=audio line shows which codecs were offered and the a=rtpmap lines show what was accepted. If you see no shared codecs in the OK response, you have a mismatch.

See Picking SIP codecs for the broader codec strategy.

Step 3 — MTU and fragmentation

RTP packets that exceed the path MTU get fragmented or dropped, which sounds like audio dropouts or robotic distortion. Common at customer sites with PPPoE or VPN tunnels where the MTU isn't 1500.

Quick test from the PBX:

# Replace with the phone's public IP
ping -M do -s 1472 <phone-public-ip>

If 1472 fails but smaller sizes succeed, the path MTU is under 1500. Find the largest size that doesn't fragment, add 28 (IP+ICMP overhead), and that's the path MTU. Set the PBX or phone to use a slightly smaller value (typically 1400 is safe for VPN'd customers).

Step 4 — Jitter and packet loss

Choppy or robotic audio that comes and goes points at jitter or packet loss on the path. Diagnose with an mtr-style trace during the call:

mtr -rwbzc 100 <phone-public-ip>

Looking for:

• Packet loss > 1% on any hop — audio will suffer noticeably above this threshold.
• Jitter (Best vs Worst) > 30 ms on the last few hops — audio will sound choppy even if packet loss is zero.
• Wifi between the phone and the router — a top-five cause we see. Hardwire the phone if at all possible; if not, dedicate a 5 GHz channel and verify signal strength.

For chronic jitter on a specific path, the carrier's recommended Jitter Buffer settings on the trunk can mask it; but that adds latency. Better to fix the underlying network if you can.

Step 5 — RTP port range

Asterisk uses RTP ports 10000–20000 by default. If the PBX's firewall doesn't allow this range inbound, audio breaks even when signaling works.

# Check the configured range
cat /etc/asterisk/rtp.conf | grep -i port
# Should show: rtpstart=10000, rtpend=20000

# Check firewall
iptables -L -n | grep 10000:20000
# (or firewalld / nftables equivalent)

On a LYLIX-hosted PBX, this range is open by default in the distro's firewall. If you customised the firewall, check that RTP didn't get accidentally closed.

Quick reference — symptoms → likely cause

Symptom	Most likely cause
One-way audio (caller hears nothing)	NAT on the caller's side, missing STUN
One-way audio (callee hears nothing)	NAT on callee side, PBX External Address wrong
Audio for a few seconds then silence	NAT pinhole closing — keep-alives
Choppy audio that comes and goes	Jitter / packet loss on path; wifi
Robotic / distorted audio	MTU fragmentation, or codec misdecode
Echo	Volume too high on hybrid; analog gateway gain
Total silence both directions	RTP port blocked by firewall; codec mismatch

When to open a ticket

If you've worked through this checklist and still can't pin down the cause, open a ticket in the PBX/VoIP-relevant department with:

• The specific symptom (one-way which direction, choppy, robotic, silence).
• The pjsip logger output (pjsip set logger on) from a test call that exhibits the issue.
• What you've already verified from the steps above.