Key Takeaways

The Asterisk blank audio issue occurs when a call connects successfully, the SIP signaling completes, the call is answered, but one or both parties hear nothing but silence. This is one of the most reported problems in contact center Asterisk deployments running VICIdial, or any SIP-based telephony stack. The call appears active at the SIP layer, yet the RTP (Real-time Transport Protocol) media stream is either missing, misdirected, or blocked entirely.

This guide gives you a structured, field-tested process to identify which layer is broken and apply the correct fix: whether you’re a VoIP engineer, an IT manager maintaining a contact center platform, or a business owner trying to understand why your agents keep reporting dead air on calls.

One-Way Audio vs. Complete Silence: Know the Difference

Before you touch a single configuration file, determine which symptom you’re actually dealing with. The diagnosis path differs significantly.

One-Way Audio

One party hears the other clearly, but the reverse direction is silent. For example, your agent hears the customer but the customer hears nothing. This is the classic signature of a NAT traversal problem or an asymmetric RTP routing failure. The SDP offer/answer negotiated the wrong IP address for one direction of the media stream.

Complete Silence (Both Ways)

Neither party hears anything. This typically points to one of the following:

Understanding this distinction immediately narrows your search to the right configuration section.

Root Causes of Silent Call Audio in Asterisk

After 15+ years deploying and maintaining Asterisk-based systems, from small 10-seat offices to enterprise contact centers handling tens of thousands of daily calls, the DialerKing engineering team has identified these as the primary culprits:

1. NAT Misconfiguration (Most Common)

Asterisk sits behind a router or firewall and doesn’t know its own public IP address. It advertises a private IP in the SDP body of SIP messages. The remote endpoint tries to send RTP to 192.168.x.x, which is unreachable from the public internet. Result: silence.

2. Firewall Blocking RTP Ports

SIP signaling uses port 5060 (TCP/UDP), which most administrators open. But RTP audio travels on a completely separate port range: by default UDP 10000–20000 in Asterisk. If your firewall or security group blocks these ports, the call connects but carries no audio.

3. Codec Mismatch

If Asterisk and the remote endpoint (IP phone, SIP trunk, softphone) cannot agree on a common audio codec, the media stream fails. You may see the call connected in logs but with no audio exchanged. Common mismatches involve G.729, G.711 (ulaw/alaw), and Opus.

4. Canreinvite / Directmedia Set Incorrectly

When canreinvite=yes (or directmedia=yes in PJSIP), Asterisk attempts to remove itself from the media path and let endpoints communicate directly. If those endpoints are behind NAT or otherwise unreachable to each other, the result is one-way or no audio. Asterisk effectively steps aside and the phones can’t find each other.

5. Incorrect externip or externhost

The externip value in sip.conf tells Asterisk what public IP to advertise in SDP. If this is missing, wrong, or has changed (e.g., dynamic IP), Asterisk will give remote endpoints an unroutable address.

6. STUN/ICE Misconfiguration (PJSIP)

In chan_pjsip deployments, improper ICE or STUN settings can cause endpoints to negotiate wrong media addresses, particularly in hybrid environments.

7. Transcoding Failures

Under heavy load, Asterisk may fail to allocate a transcoding channel between two incompatible codecs, dropping the audio silently without throwing an obvious error.

Step-by-Step: How to Diagnose the Asterisk Blank Audio Issue

Work through these steps in order. Most issues are resolved by step 4 or 5.

Step 1: Reproduce the issue and capture a SIP trace

Enable SIP debug logging for the affected call:

asterisk -r
sip set debug on

asterisk -r
sip set debug on

Place a test call and capture the output. Save it to a file for analysis. You’re looking for the SDP section within the 200 OK or INVITE packet, specifically the c= (connection) and m= (media) lines.

Step 2: Check the IP address advertised in SDP

In the SIP trace, find the c=IN IP4 x.x.x.x line in the SDP body. Ask: is this IP address reachable by the remote endpoint?

Step 3: Verify RTP port accessibility

From an external host, run a UDP port check against your Asterisk server’s public IP: nmap -sU -p 10000-10010 YOUR_PUBLIC_IP

Or use a VoIP testing tool. If ports show as filtered, your firewall is blocking RTP. Open UDP 10000–20000 to the Asterisk server.

Step 4: Check codec negotiation in logs

/var/log/asterisk/full , search for the call by timestamp and look for lines like: No compatible codecs, not accepting this offer

or

Codec mismatch: both sides requested incompatible codecs

Codec mismatch: both sides requested incompatible codecs

If present, edit your sip.conf to align the allow= and disallow= directives.

Step 5: Check canreinvite / directmedia value

In your peer or trunk definition, find:

canreinvite=yes

Change to no (or directmedia=no for PJSIP) and reload Asterisk:

asterisk -rx "sip reload"

asterisk -rx "sip reload"

Test the call again.

Step 6: Inspect rtp.conf

Confirm your RTP port range is configured and not accidentally set to a range blocked by your provider or network:

[general]
rtpstart=10000
rtpend=20000

[general]
rtpstart=10000
rtpend=20000

Step 7: Review PJSIP media settings (if applicable)

For chan_pjsip, check your endpoint and transport configuration for ice_support, media_address, and external_media_address. Misconfigured ICE in different environments (AWS, GCP, Azure) is a frequent silent-audio culprit.

Step-by-Step: Fix Guide for Each Root Cause

Fix 1: Resolve NAT-Related Blank Audio

Edit /etc/asterisk/sip.conf under [general]:

[general]
externip=YOUR.PUBLIC.IP.ADDRESS     ; or use externhost= for dynamic IPs
localnet=192.168.0.0/255.255.0.0    ; adjust to your LAN subnet
nat=yes

[general]
externip=YOUR.PUBLIC.IP.ADDRESS     ; or use externhost= for dynamic IPs
localnet=192.168.0.0/255.255.0.0    ; adjust to your LAN subnet
nat=yes

Then reload:
asterisk -rx "sip reload"

Then reload:
asterisk -rx "sip reload"

For PJSIP (pjsip.conf), set on your transport:
[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0
external_media_address=YOUR.PUBLIC.IP
external_signaling_address=YOUR.PUBLIC.IP
local_net=192.168.0.0/24

For PJSIP (pjsip.conf), set on your transport:
[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0
external_media_address=YOUR.PUBLIC.IP
external_signaling_address=YOUR.PUBLIC.IP
local_net=192.168.0.0/24

Fix 2: Open Firewall RTP Ports

On iptables:

iptables -A INPUT -p udp --dport 10000:20000 -j ACCEPT
iptables -A OUTPUT -p udp --sport 10000:20000 -j ACCEPT

iptables -A INPUT -p udp --dport 10000:20000 -j ACCEPT
iptables -A OUTPUT -p udp --sport 10000:20000 -j ACCEPT

On firewalld:
firewall-cmd --permanent --add-port=10000-20000/udp
firewall-cmd --reload

On firewalld:
firewall-cmd --permanent --add-port=10000-20000/udp
firewall-cmd --reload

On AWS Security Groups or GCP Firewall Rules, add a custom UDP inbound rule for port range 10000–20000 sourced from 0.0.0.0/0 (or restrict to your SIP trunk provider’s IP range for better security).

Fix 3: Align Codec Configuration

In sip.conf, for a peer or trunk definition:

[mytrunk]
type=peer
disallow=all
allow=ulaw
allow=alaw
allow=g729

[mytrunk]
type=peer
disallow=all
allow=ulaw
allow=alaw
allow=g729

Ensure the codecs listed match what your provider supports. G.729 requires a licensed codec module in Asterisk unless you’re using a passthrough-only mode.

Fix 4: Disable Direct Media / canreinvite

[mytrunk]
canreinvite=no
; or for newer Asterisk versions:
directmedia=no

[mytrunk]
canreinvite=no
; or for newer Asterisk versions:
directmedia=no

This forces Asterisk to stay in the media path, proxying RTP between endpoints. Slightly higher CPU usage, but eliminates NAT-related direct-media failures entirely.

Fix 5: Fix PJSIP Media Address for Deployments

[my-endpoint]
type=endpoint
...
media_address=YOUR.PRIVATE.IP    ; bind media to this interface

[my-endpoint]
type=endpoint
...
media_address=YOUR.PRIVATE.IP    ; bind media to this interface

And on transport:

external_media_address=YOUR.PUBLIC.IP

external_media_address=YOUR.PUBLIC.IP

Real-World Example: Contact Center NAT Audio Failure 

A contact center client operating a 120-seat VICIdial deployment migrated their Asterisk server from a co-located data center to AWS EC2. After the migration, agents could connect calls and hear the customer briefly, then audio dropped to complete silence within 2–3 seconds.

Root cause: The EC2 instance had a private IP of 10.0.1.45 and a public Elastic IP of 54.x.x.x. The original sip.conf had no externip set (it wasn’t needed in the co-location environment where the server had a direct public IP). On AWS, Asterisk was advertising 10.0.1.45 in SDP. The SIP trunk provider accepted it momentarily due to the existing session state, then timed out the media stream.

Fix applied:

Total downtime to resolution: under 15 minutes. All 120 agent seats were restored to full audio quality.

sip.conf and rtp.conf Configuration Reference {#config-reference}
Recommended sip.conf [general] Block for NAT Environments
[general]
bindport=5060
bindaddr=0.0.0.0
externip=YOUR.PUBLIC.IP.ADDRESS
localnet=192.168.1.0/255.255.255.0
nat=yes
canreinvite=no
qualify=yes
videosupport=no
disallow=all
allow=ulaw
allow=alaw

sip.conf and rtp.conf Configuration Reference {#config-reference}
Recommended sip.conf [general] Block for NAT Environments
[general]
bindport=5060
bindaddr=0.0.0.0
externip=YOUR.PUBLIC.IP.ADDRESS
localnet=192.168.1.0/255.255.255.0
nat=yes
canreinvite=no
qualify=yes
videosupport=no
disallow=all
allow=ulaw
allow=alaw

Recommended rtp.conf
[general]
rtpstart=10000
rtpend=20000
strictrtp=yes
probation=4

Recommended rtp.conf
[general]
rtpstart=10000
rtpend=20000
strictrtp=yes
probation=4

Frequently Asked Questions

Conclusion

The Asterisk blank audio issue is almost never caused by a defect in Asterisk itself, it’s an environment and configuration problem, and it’s fixable. The overwhelming majority of silent call audio cases in contact centers trace back to four things: NAT misconfiguration, RTP port blockage, incorrect canreinvite settings, and codec mismatches. Work through the diagnostic steps in order, check your SDP output first, and verify your firewall rules before digging deeper into codec or PJSIP settings.

Whether you’re running a 5-seat VICIdial system or a 500-seat enterprise contact center on Asterisk, these same principles apply. The key is structured diagnosis, not guesswork.

If you’ve worked through this guide and the issue persists, or if you’d prefer an expert to review your configuration directly, the DialerKing engineering team is available to help. With 15+ years of hands-on experience deploying and maintaining Asterisk, VICIdial, and IVR solutions, we’ve resolved every variant of this problem across dozens of environments.

Contact DialerKing to speak with a senior VoIP engineer about your deployment.