How to Fix One-Way Audio Issues in VICIdial

What Is One-Way Audio and Why It Happens

One-way audio occurs when one party on a VICIdial call can hear the other, but the reverse direction is silent. The agent hears the customer but the customer cannot hear the agent. Or the customer speaks and the agent hears nothing. The call appears connected — timers run, dispositions can be set — but conversation is impossible. This is distinct from choppy audio (packet loss) or echo, which are separate problems with different fixes.

One-way audio is almost always an RTP (Real-time Transport Protocol) routing problem. SIP signaling successfully establishes the call — both sides agree to connect — but the actual audio packets travel on separate UDP ports and must reach both endpoints. When NAT, firewalls, or incorrect IP addresses block RTP in one direction, you get one-way audio. The fix is always in the network or Asterisk media configuration, not in VICIdial campaign settings.

This guide covers diagnosis and resolution for both customer-side one-way audio (agent hears customer, customer does not hear agent) and agent-side one-way audio (customer hears agent, agent does not hear customer). The direction of the failure tells you which RTP path is broken.

How RTP Audio Flows in VICIdial

Understanding the audio path helps you troubleshoot efficiently. When VICIdial places an outbound call, this is what happens at the media layer:

1. Asterisk on your vicidial server sends SIP INVITE to the carrier with SDP (Session Description Protocol) containing the server's RTP IP and port
2. The carrier connects to the customer's phone and passes the SDP — the customer's phone sends RTP audio to the server's IP:port
3. When an agent answers, Asterisk bridges the customer channel and agent channel
4. The agent's phone receives SDP with RTP destination information and begins sending audio packets
5. For two-way audio, RTP must flow in both directions: customer → server → agent and agent → server → customer

If any step advertises the wrong IP address — especially a private LAN IP instead of the public IP — the remote party sends audio to an unreachable destination. The call connects but audio flows only in the direction where the IP was correct.

NAT Configuration on the VICIdial Server

NAT (Network Address Translation) is the single most common cause of one-way audio in VICIdial. If your vicidial server sits behind a firewall or has a private IP on a cloud instance, Asterisk must be told its public IP so it advertises the correct address in SDP.

externip and localnet in Asterisk

In sip.conf (chan_sip) or via rtp.conf, set externip to your server's public IP address and define localnet for your private subnet. This tells Asterisk to rewrite private IPs in SDP headers with the public IP for any connection outside the local network.

• In /etc/asterisk/sip.conf: externip=YOUR.PUBLIC.IP.ADDR and localnet=192.168.1.0/255.255.255.0
• In /etc/asterisk/rtp.conf: ensure rtpstart and rtpend define the RTP port range (default 10000–20000)
• For PJSIP: set external_media_address and external_signaling_address in pjsip.conf transport section
• After changes, restart Asterisk: asterisk -rx 'core restart now'
• Verify with asterisk -rx 'sip show settings' that externip displays correctly

VICIdial External Server IP Setting

In VICIdial Admin → System Settings, the External Server IP field must match your public IP. This setting affects agent phone registration and WebRTC connections. A mismatch between the Asterisk externip and the VICIdial external IP causes agent-side one-way audio even when customer audio works fine.

If you recently migrated servers or changed hosting providers, this setting is the first thing to verify. Our vicidial setup guide covers initial server configuration including this field.

Firewall and Port Configuration

VoIP requires specific UDP ports to be open. A firewall blocking RTP ports in one direction produces one-way audio that is consistent and reproducible.

Required Ports

• UDP 5060 (SIP signaling) — must be open inbound and outbound
• UDP 10000–20000 (RTP media) — must be open inbound and outbound for the full range
• UDP 4569 (IAX, if used) — open if any trunks use IAX protocol
• TCP 80/443 — for agent web interface and WebRTC (if applicable)
• ICMP — allow for troubleshooting but not required for audio

Cloud Provider Security Groups

If your vicidial server runs on AWS, Hetzner, DigitalOcean, or similar, the cloud security group is a separate firewall from iptables on the server itself. Both must allow the RTP port range. A common mistake is opening ports in iptables but not in the cloud security group, or vice versa. Check both layers.

For managed vicidial hosting, your provider configures these rules during deployment. Self-hosted operators must verify both the OS firewall and any upstream network firewall.

Carrier-Side One-Way Audio

When the agent hears the customer but the customer cannot hear the agent, the problem is often in the outbound RTP path from your server to the carrier. The carrier received your SIP signaling (call connected) but RTP packets from the agent side are not reaching the customer's phone.

Carrier NAT and SIP ALG

Some SIP carriers sit behind their own NAT or use SIP Application Layer Gateway (ALG) that rewrites SDP incorrectly. If your Asterisk advertises a private IP in SDP and the carrier's ALG fails to rewrite it, the customer's phone sends audio to a private IP that is unreachable.

• Confirm your carrier trunk is configured with the correct external IP in VICIdial Admin → Carriers
• Test with directmedia=no (Asterisk handles all RTP) versus directmedia=yes (endpoints exchange RTP directly)
• Set canreinvite=no on carrier trunks to force Asterisk to stay in the media path — this is the recommended setting for VICIdial
• Contact your carrier if their ALG is rewriting SDP incorrectly — they may need to disable ALG for your trunk IP

Proper SIP carrier configuration prevents most carrier-side audio issues. The canreinvite=no setting is critical — it ensures Asterisk always proxies RTP, which is necessary when NAT is involved.

Agent-Side One-Way Audio

When the customer hears the agent but the agent cannot hear the customer, the inbound RTP path to the agent phone is broken. This affects remote agents more frequently than office-based agents.

Remote Agent NAT Issues

Remote agents connect from home networks behind residential routers. Their phones register to VICIdial via SIP but may advertise a private IP in their SDP. Asterisk sends customer audio to the agent's private IP, which is unreachable from the server.

• Configure agent phones to use SIP keep-alive (NAT keep-alive interval of 15–30 seconds)
• Use the VICIdial web phone (WebRTC) which handles NAT traversal through the browser
• If using hard phones or Zoiper/Bria softphones, enable STUN on the phone with a public STUN server (stun.l.google.com:19302)
• Set the phone's NAT traversal setting to STUN, ICE, or Auto depending on the device
• Ensure the agent's router does not have SIP ALG enabled — it corrupts SIP headers on consumer routers

WebRTC Agent Connections

VICIdial's web phone uses WebRTC, which handles NAT differently than standard SIP phones. WebRTC requires a TURN server when direct peer connection fails. If remote agents using the web phone experience one-way audio, verify that your VICIdial server has a TURN server configured or that the external IP and certificate are correct for WebRTC signaling.

Codec Mismatch and Transcoding

Less common but possible: if the customer endpoint negotiates a codec that the agent phone does not support, Asterisk must transcode. Transcoding failures can produce one-way audio or complete silence. Standardize on ulaw (G.711 μ-law) for US operations.

• In sip.conf, set disallow=all and allow=ulaw on carrier trunks and agent extensions
• Disable unused codecs (alaw, g729, g722) unless specifically required
• Check negotiated codec on active calls: asterisk -rx 'core show channel CHANNELID'
• If transcoding is necessary, ensure Asterisk has codec modules loaded (format_pcm, codec_ulaw, etc.)

Step-by-Step Diagnostic Procedure

1. Determine direction: Can the agent hear the customer, can the customer hear the agent, or is it intermittent?
2. Check externip: Run asterisk -rx 'sip show settings' and verify the external IP matches your public IP
3. Test RTP flow: During an active call, run asterisk -rx 'rtp show stats' and check for TX/RX packet counts on both channels — one direction showing zero packets confirms the broken path
4. Capture SIP traffic: Use sngrep or tcpdump on port 5060 to inspect SDP headers — look for private IPs (10.x, 172.x, 192.168.x) in c= lines sent to external parties
5. Test without the carrier: Have two agents call each other internally — if internal calls have two-way audio, the issue is carrier or PSTN related
6. Test with a single carrier: Disable all carrier trunks except one and test — isolates carrier-specific ALG or NAT issues
7. Check firewall logs: Look for dropped UDP packets on RTP ports during an active call
8. Verify VICIdial external IP: Admin → System Settings → External Server IP matches public IP

The sngrep tool is invaluable for one-way audio diagnosis. Install it (yum install sngrep or apt install sngrep), run it during a test call, and inspect the SDP offer/answer exchange. The c= line in SDP shows the IP address each party expects to receive audio on.

Common Scenarios and Quick Fixes

Just Migrated to a New Server

After any server migration, update externip in Asterisk, External Server IP in VICIdial, and firewall rules on the new host. IP addresses change with migrations, and stale configuration is the immediate suspect. Also update your SIP carrier trunks if they whitelist source IPs.

Only Remote Agents Affected

Disable SIP ALG on agent routers, configure STUN on agent phones, or switch remote agents to the VICIdial web phone. Office agents on the same LAN as the server do not traverse NAT, which is why they work fine while remote agents do not.

Only One Carrier Affected

The carrier may have SIP ALG or NAT issues on their end. Set canreinvite=no on that specific trunk. If the problem persists, contact the carrier with sngrep captures showing the SDP exchange. Compare with a working carrier's SDP to identify differences.

Intermittent One-Way Audio

Intermittent issues suggest RTP timeout or firewall session timeout. Some firewalls close UDP pinholes after 30–60 seconds of perceived inactivity. Ensure RTP keep-alive is enabled and firewall connection tracking timeouts for UDP are set to at least 120 seconds. This can also manifest as calls dropping after a minute or two.

Advanced Configuration Fixes

Symmetric RTP and ICE

Enable symmetric RTP in Asterisk so it sends audio back to the source IP:port from which it receives RTP, rather than strictly following the SDP address. For chan_sip, this is the default behavior when nat=yes is set on the peer. For PJSIP, enable rtp_symmetric and force_rport on endpoint configurations.

SIP Qualify and Keep-Alive

Set qualify=yes on carrier trunks and agent extensions in sip.conf. This sends periodic OPTIONS pings that keep NAT pinholes open on firewalls between the server and endpoints. Set qualifyfreq=60 or lower for agents behind aggressive NAT.

MTU and Fragmentation

Oversized packets that exceed the network MTU get fragmented or dropped, causing audio loss. If your server uses a VPN or GRE tunnel, reduce MTU to 1400 on the tunnel interface. This is a rare cause but worth checking if all other diagnostics are clean.

Preventing One-Way Audio Recurrence

After fixing the immediate issue, add these practices to your operational checklist.

• Include a two-way audio test in your post-deployment verification for any server or carrier change
• Document your working externip, firewall rules, and carrier trunk settings in a runbook
• Monitor for one-way audio complaints in agent feedback channels — they often surface before metrics do
• Test remote agent audio weekly with agents on different ISPs and router brands
• Keep Asterisk and VICIdial updated — media handling improvements are included in most releases
• Use canreinvite=no on all carrier trunks as a default policy

Conclusion

One-way audio in VICIdial is a solvable network problem. In 90% of cases, the fix is correcting externip/localnet settings, opening RTP firewall ports, or setting canreinvite=no on carrier trunks. The direction of the audio failure — agent-to-customer or customer-to-agent — narrows the broken RTP path quickly. Use sngrep to inspect SDP during test calls, and verify both OS and cloud firewalls allow the full RTP port range.

For persistent audio issues across multiple carriers or remote agent populations, professional vicidial support can perform packet captures and Asterisk configuration audits that resolve problems in a single session. Proper vicidial server configuration from the start prevents most audio issues from ever appearing.