Asterisk Troubleshooting: One-Way Audio (PJSIP/RTP) Root Causes (Latest Versions)

One-way audio is the most common real-world failure in PJSIP-based Asterisk telecom systems.

In this condition:

• The call connects successfully
• One side can hear audio
• The other side hears silence

Because SIP signaling appears normal, engineers often misdiagnose the issue. In reality, one-way audio is almost always caused by problems in the RTP media path, NAT behavior, or firewall routing.

Understanding SIP vs RTP (Critical Concept)

A phone call has two completely separate network layers:

• SIP signaling → establishes the call (INVITE, 200 OK, ACK)
• RTP media → carries the actual voice packets

One-way audio happens when:

• SIP works correctly
• RTP flows only in one direction

Therefore, fixing one-way audio always requires RTP-level debugging, not SIP debugging alone.

How RTP Audio Normally Flows

During call setup:

1. SIP INVITE contains SDP with IP + RTP port
2. Both endpoints exchange media addresses
3. RTP packets begin flowing directly between endpoints or via Asterisk

If any SDP address or RTP port is unreachable, audio becomes one-way or completely silent.

Most Common Causes of One-Way Audio

1. NAT Incorrectly Advertising Private IP

• SDP shows 192.168.x.x instead of public IP
• Remote endpoint sends RTP to unreachable address

2. Firewall Blocking RTP Ports

• SIP port 5060 open
• RTP range (10000-20000 UDP) closed

3. Missing Symmetric RTP Handling

• Endpoints behind NAT send RTP from different port
• Asterisk must learn real source dynamically

4. Direct Media Misconfiguration

• Endpoints try peer-to-peer RTP
• NAT prevents direct connectivity

Correct NAT Configuration in PJSIP

[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0
local_net=192.168.0.0/16
external_media_address=PUBLIC_IP
external_signaling_address=PUBLIC_IP

These parameters ensure:

• SDP advertises the correct public IP
• Remote RTP packets return successfully

Endpoint NAT-Safety Settings

[phone-endpoint]
type=endpoint
context=from-internal
disallow=all
allow=ulaw,alaw
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes
direct_media=no

These options:

• Enable symmetric RTP learning
• Fix NAT port rewriting
• Force audio through Asterisk for stability

Firewall Rules Required for Audio

sudo ufw allow 5060/udp
sudo ufw allow 10000:20000/udp

Without RTP port access, calls connect but audio fails.

Step-by-Step Debugging Workflow

1. Confirm SIP Works

pjsip set logger on

Ensure INVITE → 200 OK → ACK sequence is complete.

2. Capture RTP Packets Using tcpdump

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

This verifies whether RTP packets are flowing.

3. Analyze in Wireshark

• Check RTP packets in both directions
• Confirm correct public IP in SDP
• Look for packet loss or jitter

Typical Real-World Failure Patterns

Caller Hears Audio, Agent Hears Silence

Cause → firewall blocking inbound RTP to Asterisk.

Agent Hears Audio, Caller Hears Silence

Cause → NAT advertising private IP in SDP.

No Audio Both Directions

Cause → RTP completely blocked or wrong codec negotiation.

Codec Mismatch vs RTP Failure

Sometimes silence is not NAT-related but codec-related:

• No common codec between endpoints
• Transcoding failure

Verify allowed codecs:

allow=ulaw,alaw

MYLINEHUB Production Insight

In MYLINEHUB deployments:

• One-way audio is detected during trunk health validation
• Voice AI RTP pipelines depend on symmetric RTP correctness
• Automatic safeguards prevent campaign dialing when RTP is broken

This ensures reliable AI calling and agent communication in production.

Key Takeaway

One-way audio is never a mystery once RTP fundamentals are understood.

The solution always lies in:

• Correct NAT configuration
• Open RTP firewall ports
• Symmetric RTP handling
• Packet-level verification using tcpdump and Wireshark

Mastering RTP debugging is essential for building stable, enterprise-grade Asterisk telecom systems.