Friday Quick Fix: Debugging One-Way Audio Issues in 5 Minutes

One-way audio is one of the most common—and frustrating—VoIP problems. You can hear the caller, but they can't hear you (or vice versa). The good news? It's almost always a NAT or firewall issue, and you can usually diagnose it in under 5 minutes.

The 5-Minute Checklist

Minute 1: Identify the Direction

First, determine which way the audio is flowing:
- Caller hears nothing, callee hears fine → Problem is likely on the caller's side (RTP not reaching them)
- Callee hears nothing, caller hears fine → Problem is on the callee's side
- Inconsistent → Could be asymmetric NAT or firewall rules

Minute 2: Check the SDP

Look at the SIP INVITE and 200 OK messages. Find the c= line in the SDP body:

c=IN IP4 192.168.1.100

If you see a private IP (192.168.x.x, 10.x.x.x, 172.16-31.x.x) being sent to an external endpoint, that's your problem. The remote side can't send RTP to a private address.

Minute 3: Verify RTP Ports

Check if RTP ports are open. The m= line shows the port:

m=audio 10000 RTP/AVP 0 8 101

Quick test from your server:

# Check if RTP ports are listening
ss -ulnp | grep -E ':(10000|[1-2][0-9]{4})'

# Or with netstat
netstat -ulnp | grep kamailio

Minute 4: Test RTP Path with tcpdump

Capture RTP traffic to see what's actually happening:

# Capture on the RTP port range
tcpdump -i any -n udp portrange 10000-20000 -c 100

What to look for:
- Packets in both directions → RTP path is working, issue is elsewhere
- Packets only one direction → NAT/firewall blocking return traffic
- No packets at all → Firewall blocking everything, or wrong interface

Minute 5: Quick Fixes

If using dSIPRouter, enable RTP relay in your domain settings. This forces media through the proxy, solving most NAT issues.

Firewall rules - Ensure your RTP port range is open:

# Check current rules
iptables -L -n | grep -E 'udp.*(10000|20000)'

# Open RTP ports if needed
iptables -A INPUT -p udp --dport 10000:20000 -j ACCEPT

NAT settings in Kamailio - Verify force_rport() and fix_nated_sdp() are being called for NATed endpoints.

The Root Causes (90% of Cases)

Private IP in SDP - Endpoint sends internal IP, remote can't route to it
Firewall blocking RTP - SIP (5060) is open, but RTP ports (10000-20000) are blocked
Symmetric NAT - Both sides behind restrictive NAT, need a media relay
RTPProxy/RTPEngine not running - Media relay configured but service is down

Pro Tip

When in doubt, enable media relay. Yes, it adds a tiny bit of latency and uses more server resources, but it solves 90% of one-way audio issues instantly. You can always optimize later once calls are working.

Got a VoIP problem that's driving you crazy? Drop it in the comments—it might become a future Friday Quick Fix.