Diagnosing One-Way Audio on SIP Trunks: A Systematic Troubleshooting Guide

Understanding the One-Way Audio Failure Mode

A VoIP call has two separate legs: signaling (SIP) and media (RTP). SIP sets up the call. RTP carries the audio. These are independent UDP flows. One-way audio occurs when RTP reaches one endpoint correctly but the return path is broken.

The symptom pattern tells you which leg is broken:

• Agent can hear the contact, contact cannot hear the agent: your SBC's RTP egress is reaching the far end, but the far end's RTP cannot reach your SBC. The problem is inbound RTP — firewall blocking, NAT breakage, or incorrect SDP in your SBC's 200 OK.
• Contact can hear the agent, agent cannot hear the contact: the far end is sending RTP to the address in your SDP, but your SBC is not receiving it. The problem is either the SDP c= line containing a private IP (NAT issue) or a firewall blocking inbound UDP on your RTP port range.
• Neither party can hear the other: both RTP legs are broken simultaneously — typically a firewall blocking all UDP inbound, or an SBC that failed to open its media ports.

Step 1: Capture the SDP Exchange

The SDP (Session Description Protocol) body inside the SIP INVITE, 200 OK, and ACK tells you exactly where each party expects to receive audio. Capture it with sngrep:

``bash sngrep -d eth0 port 5060 ``

In the INVITE from your SBC, locate the c= line and the m=audio line: `` c=IN IP4 <your_public_ip> m=audio 16394 RTP/AVP 0 101 ``

If <your_public_ip> is actually a private address (10.x.x.x, 192.168.x.x, 172.16-31.x.x), the far end is sending RTP to an unreachable address. This is the NAT problem described in the firewall and NAT configuration guide. Fix the SBC's ext-rtp-ip setting and the SDP will immediately correct.

In the 200 OK from the far-end carrier, locate the c= line. This is where your SBC should send RTP. If this is a public IP and your SBC is sending to it but the contact hears nothing, the issue is on the far-end network — escalate to the carrier with a packet capture showing you are correctly sending RTP.

Step 2: Verify RTP Is Actually Being Sent

Confirming that SDP contains the right IPs is necessary but not sufficient — the SBC must actually send RTP. Capture UDP on the expected source and destination ports:

``bash tcpdump -n -i eth0 udp portrange 16384-32767 and host <carrier_media_ip> ``

During an active call, you should see continuous bidirectional UDP traffic. If you see outbound packets but no inbound packets, the carrier is not sending RTP — or the carrier's RTP is being blocked by your firewall on the inbound path. If you see nothing outbound, the SBC did not open a media socket — check for SBC license limits (some SBCs cap concurrent channels) or a misconfigured media IP binding.

Step 3: Check Firewall Inbound Rules

The most common cause of contact-cannot-hear-agent (inbound RTP blocked): a firewall that allows outbound UDP on the SIP port but has no explicit rule allowing inbound UDP on the RTP port range.

Confirm with a temporary test: add a permissive inbound rule from the carrier IP range on your full RTP port range (e.g., UDP 10000–20000 from carrier IPs). If audio becomes bidirectional immediately, the firewall was the cause. Then tighten the rule to the specific carrier IP blocks published in the UnlimCall SIP integration documentation.

On a stateful Linux firewall (iptables/nftables), add the rule:

``bash iptables -I INPUT -s <carrier_rtp_ip_block> -p udp --dport 10000:20000 -j ACCEPT ``

On pfSense, add an inbound rule on the WAN interface: Protocol UDP, Source = carrier IP range, Destination = SBC IP, Destination Port = 10000-20000.

Step 4: Check for SIP ALG Mangling

SIP ALG (Application Layer Gateway) on the edge router can rewrite SDP bodies incorrectly, inserting the wrong IP or port into the c= or m= lines. This produces one-way audio that appears randomly — some calls work, others do not — because SIP ALG applies rewriting inconsistently based on internal state.

Verify SIP ALG status and disable it as described in the firewall and NAT configuration guide. After disabling, restart the SBC and place a new test call. If the sngrep capture now shows correct public IPs in SDP without any mangling, SIP ALG was the cause.

Step 5: Verify RTP Port Binding on the SBC

Some SBCs and softswitch platforms bind RTP sockets to the first available interface IP rather than the configured external IP. If the SBC is multi-homed (two network interfaces — common on servers with a management NIC and a VoIP NIC), RTP may bind to the management interface IP, which is either not reachable from the carrier or is a different IP than what was negotiated in SDP.

On FreeSWITCH, verify the bind address: ``xml <param name="rtp-ip" value="<internal_sbc_ip>"/> <param name="ext-rtp-ip" value="<public_ip>"/> ``

rtp-ip is the local interface to bind; ext-rtp-ip is what gets advertised in SDP. These must be set explicitly — do not rely on auto-detection on a multi-homed host.

On Asterisk PJSIP, set media_address=<local_interface_ip> on the endpoint and external_media_address=<public_ip> on the transport.

Step 6: Check for Media Timeout Issues

Some carriers drop the RTP leg after a silence period (typically 20–30 seconds of no RTP packets) while SIP signaling is still active. This produces one-way audio that starts working, then breaks mid-call after a pause. The carrier has torn down the media path without sending a BYE because it detected the RTP stream went silent.

Common triggers: hold music is not sending RTP, auto-attendant prompts where the caller stops speaking, or an SBC that pauses RTP during SDP re-INVITE processing.

The fix is to configure continuous RTP comfort noise (CN) or keep-alive RTP on hold paths. In FreeSWITCH: <param name="rtp-enable-zrtp" value="false"/> plus ensure mod_spandsp generates comfort noise on bridged legs during silence.