Asterisk Troubleshooting: RTP Debugging and Wireshark SIP (Latest Versions)

Many Asterisk call problems are incorrectly blamed on SIP, while the real failure happens in the RTP media layer.

You may see:

• Call connects successfully
• Caller hears silence or one-way audio
• DTMF does not work correctly

These are classic RTP path problems, not SIP signaling issues.

This guide explains how to debug RTP using:

• Asterisk CLI tools
• tcpdump packet capture
• Wireshark SIP + RTP correlation

Understanding SIP vs RTP During a Call

Real call sequence:

1. SIP INVITE establishes call
2. SDP negotiates codec + RTP IP/port
3. RTP packets begin flowing directly

If SIP works but RTP fails, the call connects with no audio.

First Check: RTP Visibility Inside Asterisk

During an active call, run:

asterisk -rvvv
rtp set debug on

You should see:

Got RTP packet from 192.168.1.20:16432

Interpretation:

• If packets appear → RTP is reaching Asterisk
• If nothing appears → firewall/NAT/provider issue

Common One-Way Audio Scenario

Example real production failure:

• Customer hears agent
• Agent hears silence

Root cause usually:

• Wrong external_media_address
• NAT rewriting failure
• Firewall blocking RTP return path

Capturing RTP Packets with tcpdump

Capture only RTP range:

sudo tcpdump -i any -s 0 -w rtp_only.pcap udp portrange 10000-20000

Capture SIP + RTP together:

sudo tcpdump -i any -s 0 -w full_call.pcap udp port 5060 or udp portrange 10000-20000

This allows full reconstruction of the call in Wireshark.

Opening Capture and Correlating SIP with RTP

In Wireshark:

1. Filter: sip
2. Find INVITE → read SDP media IP/port
3. Filter RTP using that port

If RTP packets do not match SDP address, NAT misconfiguration is confirmed.

Firewall-Related RTP Failures

Typical Linux firewall mistake:

sudo ufw allow 5060/udp

SIP opens, but RTP blocked.

Correct rule:

sudo ufw allow 10000:20000/udp

Codec and RTP Payload Mismatch

Sometimes RTP flows correctly, but audio is still silent.

Possible reason:

• Codec mismatch in SDP
• Transcoding module missing
• Wrong payload type negotiation

Real Troubleshooting Flow Used in Production

1. Confirm SIP call success
2. Enable rtp set debug on
3. If unclear → capture with tcpdump
4. Analyze RTP direction in Wireshark
5. Fix NAT/firewall/codec accordingly

Key Takeaway

When a call connects but audio fails, always debug RTP first, not SIP.

Combining Asterisk RTP debug, tcpdump capture, and Wireshark analysis reveals the real root cause in nearly every media failure.