Troubleshooting One-Way Audio in ViciDial / Asterisk

Learn to diagnose and resolve one-way audio issues in ViciDial and Asterisk environments, including codec mismatches, RTP problems, and ViciDial-specific configuration errors.

Prerequisites

Before starting this guide, ensure you have:

A working ViciDial installation (3.x or 4.x recommended)
SSH access to your ViciDial server with sudo privileges
Basic understanding of SIP and RTP protocols
Familiarity with Asterisk CLI commands
Access to Asterisk configuration files at /etc/asterisk/
MySQL/MariaDB access to the asterisk database
A test scenario to reproduce the one-way audio issue

Understanding One-Way Audio in ViciDial/Asterisk

One-way audio occurs when call participants can hear one direction of conversation but not the other. In ViciDial environments, this typically manifests as:

Agent hears caller, caller cannot hear agent
Caller hears agent, agent cannot hear caller
One direction is garbled, other direction is clear

The root causes in ViciDial/Asterisk deployments usually involve:

Codec mismatches between endpoints
RTP media path issues (firewall, NAT, port ranges)
SIP signaling vs. media path divergence
ViciDial bridge or transfer configuration errors
Incorrect SIP peer definitions in sip-vicidial.conf
Call recording configuration conflicts
Carrier/trunk misconfigurations

Section 1: Initial Diagnostic Steps

Check Asterisk Version and Core Status

Start by verifying your Asterisk installation is running correctly:

asterisk -rx "core show version"
asterisk -rx "core show license"
asterisk -rx "sip show status"

Expected output shows Asterisk version, licensing info, and active SIP channels. If you see zero channels or connection errors, restart Asterisk:

systemctl restart asterisk
# Wait 15 seconds
asterisk -rx "core show version"

Enable SIP/RTP Debugging

Enable verbose logging to capture the call flow. SSH into your ViciDial server and run:

asterisk -rx "sip set debug on"
asterisk -rx "rtp set debug on"
asterisk -rx "core set verbose 3"

Reproduce the one-way audio issue while these debug logs are active. Monitor the log file in real-time:

tail -f /var/log/asterisk/messages | grep -E "INVITE|SDP|RTP|Media"

Stop debugging after reproducing the issue:

asterisk -rx "sip set debug off"
asterisk -rx "rtp set debug off"

Review Call Logs in ViciDial Database

Query the vicidial_log table to find the call record:

SELECT * FROM vicidial_log 
WHERE call_date >= DATE_SUB(NOW(), INTERVAL 10 MINUTE)
ORDER BY call_date DESC 
LIMIT 1\G

Key fields to examine:

length_in_sec - Call duration
status - Call outcome
recording_id - Whether recording was attempted
user - Agent username
carrier_id - Trunk used for the call

For more detailed call segment information:

SELECT * FROM vicidial_closer_log 
WHERE call_date >= DATE_SUB(NOW(), INTERVAL 10 MINUTE)
ORDER BY call_date DESC 
LIMIT 1\G

Section 2: Codec Troubleshooting

Codec mismatches are the most common cause of one-way audio. ViciDial bridges calls between different endpoints, each with preferred codecs.

Identify Active Codecs

Check which codecs are allowed on your SIP peers:

asterisk -rx "sip show peer AGENTPEER detailed" | grep -i codec
asterisk -rx "sip show peer TRUNKPEER detailed" | grep -i codec

Look for output like:

Codecs (inbound): (ulaw|alaw|gsm)
Codecs (outbound): (ulaw|alaw|gsm)

Review SIP Configuration for Agent Channels

Edit your ViciDial SIP configuration:

nano /etc/asterisk/sip-vicidial.conf

Search for the agent peer definition. A typical configuration looks like:

[6001]
type=peer
host=dynamic
secret=agentpassword
context=from-internal
disallow=all
allow=ulaw
allow=alaw
allow=gsm
dtmfmode=rfc2833
nat=yes
qualify=yes

Ensure your agent device (softphone, desk phone) supports at least one of these codecs. Common issues:

Only allow=ulaw is set - But agent phone only supports opus or g729
nat=no - But agent is behind NAT, causing one-way audio
dtmfmode=info - May conflict with certain PBXes

Review Carrier/Trunk Codec Configuration

Check trunk configurations in sip-vicidial.conf or extensions-vicidial.conf:

grep -A 20 "\[carrier\|trunk" /etc/asterisk/sip-vicidial.conf | head -60

Example proper trunk peer definition:

[mycarrier]
type=peer
host=carrier.example.com
secret=carrierpassword
context=from-carrier
disallow=all
allow=ulaw
allow=alaw
fromuser=myaccount
fromdomain=carrier.example.com
insecure=port,invite
qualify=yes
nat=yes

Verify Codec Negotiation in Call Logs

After running debug, search the logs for codec negotiation:

grep -i "codec" /var/log/asterisk/messages | tail -30

Look for messages indicating codec selection or rejection:

[2024-01-15 14:23:45] Peer 'AGENTPEER' is now Reachable
[2024-01-15 14:23:52] Setting RTP codecs based on INVITE: (ulaw|alaw|gsm)
[2024-01-15 14:23:52] Answering call from AGENTPEER with codec ulaw

If you see codec mismatch messages, your trunk and agent don't share compatible codecs. Solution: Add matching codecs to both peer definitions.

Section 3: RTP and Media Path Diagnosis

RTP (Real-time Transport Protocol) carries the actual audio. One-way audio often indicates RTP flowing in only one direction.

Check RTP Port Configuration

Verify RTP port range in asterisk.conf:

grep -i "rtpstart\|rtpend" /etc/asterisk/asterisk.conf

Default configuration:

[rtp]
rtpstart=10000
rtpend=20000
tos=ef
cos=5

Ensure your firewall allows this entire range. Check current firewall rules:

sudo ufw status | grep 10000
sudo iptables -L | grep 10000

If not visible, open the RTP port range:

sudo ufw allow 10000:20000/udp
sudo firewall-cmd --add-port=10000-20000/udp --permanent
sudo firewall-cmd --reload

Diagnose NAT Issues

One-way audio frequently occurs when:

Agent is behind NAT, trunk is public - Agent can hear trunk (outbound RTP works), trunk can't hear agent (return RTP blocked)
Both behind NAT - NAT traversal needed

Check if peers are behind NAT:

asterisk -rx "sip show peer AGENTPEER" | grep -i nat
asterisk -rx "sip show peer CARRIER" | grep -i nat

Correct NAT configurations:

For agents behind NAT (typical softphone scenario):

[agentpeer]
nat=yes
directmedia=no

For carrier/trunk behind NAT:

[trunk]
nat=yes
directmedia=no

Setting directmedia=no forces Asterisk to remain in the media path, preventing direct RTP between endpoints that can't reach each other.

Analyze RTP Packet Flow

Use tcpdump to capture RTP packets during a call:

# Capture RTP from a specific source/destination
sudo tcpdump -i any -n 'udp and portrange 10000-20000' -w rtp_capture.pcap

# In another terminal, reproduce the issue and let it run for 30 seconds
# Then Ctrl+C the tcpdump

Analyze the capture with Wireshark or tshark:

tshark -r rtp_capture.pcap -f 'rtp' -Y 'rtp' | head -20

Look for:

One direction has packets, other has none - Classic one-way audio
Asymmetric packet counts - Unbalanced conversation
Packets with 0 length - Malformed RTP

Check Asterisk RTP Statistics

During an active call, check RTP status:

asterisk -rx "rtp show stats"

Output shows all active RTP streams:

RTP Stats:
  RTP Stream #1: 192.168.1.100:5060 -> 203.0.113.50:5060
    Rx Packets: 1250, Rx Bytes: 75000
    Tx Packets: 0, Tx Bytes: 0
    RTT: 45ms, Jitter: 12ms

If Rx Packets > 0 but Tx Packets = 0 (or vice versa), you have one-way audio. This indicates RTP is flowing inbound but not outbound.

Section 4: ViciDial-Specific Configuration Issues

Verify Bridge Settings in extensions-vicidial.conf

ViciDial creates bridges between agents and callers using dialplan. Check the bridge configuration:

grep -A 30 "exten => _X.,1," /etc/asterisk/extensions-vicidial.conf | head -50

Look for bridge commands like:

exten => _X.,1,Bridge(${CALLVAR},${BRIDGEOPTIONS})

Common bridge option misconfigurations:

; WRONG - No audio from agent to caller
exten => 6001,1,Bridge(SIP/agentpeer,p)

; CORRECT - Bidirectional audio with proper options
exten => 6001,1,Bridge(SIP/agentpeer,mwT)

Bridge option meanings:

m - Play music on hold while calling
w - Allow attended transfers
T - Allow DTMF transfers
p - Pass through DTMF (may break audio)

Check ViciDial Call Recording Configuration

Call recording sometimes interferes with audio paths. Check recording settings in /etc/asterisk/extensions-vicidial.conf:

grep -i "MixMonitor\|Monitor" /etc/asterisk/extensions-vicidial.conf

Verify the recording directory exists and has proper permissions:

ls -la /var/spool/asterisk/monitor/
# Should output:
# drwxr-xr-x  asterisk asterisk  /var/spool/asterisk/monitor

If recording is interfering, temporarily disable it:

# In extensions-vicidial.conf, comment out MixMonitor lines
# exten => _X.,2,MixMonitor(/var/spool/asterisk/monitor/${MIXMONITOR_FILENAME},${AUDIOHOOKS})

Restart dialplan:

asterisk -rx "dialplan reload"

Retest the call. If audio works with recording disabled, the recording configuration is the issue.

Verify Agent Channel Context

Agents connect via SIP. Verify their context points to proper dialplan:

asterisk -rx "sip show peer 6001" | grep context

Expected output:

Context: from-internal

This context must exist and contain the proper dialplan. Check it:

grep -A 20 "^\[from-internal\]" /etc/asterisk/extensions-vicidial.conf

Should contain logic to route calls to agents or queues.

Check Dialplan Variables Affecting Audio

Some ViciDial dialplan variable misconfigurations cause audio issues:

grep -i "CALLVAR\|BRIDGEOPTIONS\|AUDIOHOOKS" /etc/asterisk/extensions-vicidial.conf | head -20

These variables should be properly set before bridge execution. If missing or malformed, one-way audio results.

Section 5: Carrier and Trunk Issues

One-way audio often originates from carrier/trunk misconfiguration, especially for inbound calls.

Query ViciDial Carrier Configuration

Check configured carriers in the database:

SELECT * FROM vicidial_carrier_list WHERE carrier_active = 'Y'\G

Key fields:

carrier_name - Identifier in config
carrier_tech - Usually SIP
outbound_carrier_id - Used for outbound calls

For more details:

SELECT * FROM vicidial_carrier_log 
WHERE call_date >= DATE_SUB(NOW(), INTERVAL 5 MINUTE)\G

Verify Trunk Peer Definition Matches Carrier Config

Find the carrier in sip-vicidial.conf:

grep -A 30 "^\[carrier_name\]" /etc/asterisk/sip-vicidial.conf

Example proper carrier definition:

[myvoipcarrier]
type=peer
host=sip.carrier.example.com
secret=carrier_auth_secret
fromuser=account_id
fromdomain=sip.carrier.example.com
context=from-carrier
disallow=all
allow=ulaw
nat=yes
directmedia=no
insecure=port,invite
qualify=yes
port=5060

Test Carrier Connectivity

Verify the trunk is registered and reachable:

asterisk -rx "sip show registry"

Expected output shows registered trunks:

Host                            Username    Refresh State       Reg.Expires ID
sip.carrier.com:5060           account_id  105     Registered  3600       0

If status is "Unregistered" or missing, the carrier configuration is incorrect. Check registration credentials:

grep -B 5 -A 15 "^\[myvoipcarrier\]" /etc/asterisk/sip-vicidial.conf | grep -E "fromuser|secret|host"

Check Carrier Audio Codecs Against Agent Codecs

This is critical. Many carriers only support ulaw. Verify:

asterisk -rx "sip show peer myvoipcarrier detailed" | grep -i codec

If carrier only supports ulaw but your agents are sending gsm, one-way audio occurs during transcoding.

Solution: Align codecs between carrier and agent peers:

[myvoipcarrier]
disallow=all
allow=ulaw
allow=alaw

[agentpeer]
disallow=all
allow=ulaw
allow=alaw

Monitor Active Trunk Calls

Check what calls are currently using trunks:

asterisk -rx "sip show channels" | grep carrier

Shows active channels:

Peer             User/ANR          Call ID              Seq (Tx/Rx)  Lag    Jitter   Time
myvoipcarrier    account_id        [call_id]            102/103      0 ms  0 ms     0:00:15

Section 6: Advanced Debugging Techniques

Capture Full SIP Trace for Single Call

Create a granular SIP trace for one specific call. First, identify an inbound number or agent:

# For agent 6001:
asterisk -rx "sip set debug peer 6001"

# For carrier trunk:
asterisk -rx "sip set debug peer myvoipcarrier"

Reproduce the issue, then immediately stop:

asterisk -rx "sip set debug off"

Extract the trace from logs:

grep "6001\|myvoipcarrier" /var/log/asterisk/messages | grep -E "INVITE|100 Trying|180 Ringing|200 OK|ACK|BYE" > /tmp/sip_trace.log
cat /tmp/sip_trace.log

Look for:

INVITE from agent - SIP setup
200 OK with SDP - Media parameters exchanged
ACK - Confirmation received
RTP port assignment in SDP - Is it the same for both directions?

Parse SDP Offers and Answers

SDP (Session Description Protocol) defines media parameters. A typical problematic SDP exchange:

Agent INVITE SDP:

m=audio 10000 RTP/AVP 0 8 3
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000

Trunk 200 OK SDP (with mismatched port):

m=audio 15432 RTP/AVP 0

The ports differ (10000 vs 15432). If Asterisk doesn't properly manage this bridge, one-way audio results.

Enable Asterisk Memory and Resource Monitoring

One-way audio sometimes indicates resource exhaustion. Monitor during calls:

asterisk -rx "memory show summary"

Expected output:

Name                          Allocated  Freed      In Use
astobj2                       2097152    0          2097152
cache                         2097152    0          1048576
channel                       524288     0          262144

Excessive memory usage indicates a leak. Check file descriptor limits:

ulimit -n
# Increase if needed:
ulimit -n 65536

Monitor CPU usage during problematic calls:

top -p $(pgrep asterisk)
# Should show < 80% CPU for normal operation

Use Verbose Logging for Dialplan Execution

Enable verbose dialplan logging to see call flow:

asterisk -rx "core set verbose 7"

During a call, logs will show:

[2024-01-15 14:35:42] -- <SIP/agentpeer-00000001> executing [6001@from-internal:1] in new stack
[2024-01-15 14:35:42] -- Executing [6001@from-internal:1] Bridge("SIP/agentpeer-00000001", "SIP/trunk")
[2024-01-15 14:35:45] -- SIP/trunk-00000002 answered SIP/agentpeer-00000001

If the bridge fails or doesn't execute, dialplan is the issue.

Section 7: Troubleshooting Checklist

Use this systematic checklist when one-way audio is reported:

Initial Verification

Call actually exists (check vicidial_log)
Asterisk is running (asterisk -rx "core show version")
SIP and RTP are active (asterisk -rx "sip show status")

Audio Path Verification

Agent phone is receiving audio (one-way confirmed)
Caller ID displays correctly (signaling working)
Call duration shows progress (not immediate hangup)

Codec Analysis

Agent phone supports configured codec
Carrier/trunk supports same codec
No codec transcoding required
disallow=all used before allow= statements

Network and RTP

Firewall allows RTP port range (10000:20000)
No VPN or security appliances blocking RTP
NAT settings correct for peer location
RTP statistics show bidirectional packet flow

ViciDial Configuration

sip-vicidial.conf peers properly defined
extensions-vicidial.conf bridge options correct
Agent context points to proper dialplan
Recording configuration not interfering

Carrier/Trunk Verification

Trunk is registered (sip show registry)
Trunk responds to qualify checks
Trunk codec compatible with agents
Trunk definition syntax correct

Section 8: Common Scenarios and Solutions

Scenario 1: Agent Hears Caller, Caller Cannot Hear Agent

Typical Cause: Agent RTP is not reaching the carrier/external caller.

Diagnosis:

asterisk -rx "rtp show stats"
# Look for stream with Rx packets but 0 Tx packets from agent side

Solution:

Check NAT settings: asterisk -rx "sip show peer agentpeer" | grep nat
Set nat=yes and directmedia=no for agent peer
Reload SIP config: asterisk -rx "sip reload"

Scenario 2: Caller Hears Agent, Agent Cannot Hear Caller

Typical Cause: Caller RTP (from carrier) is not reaching agent.

Diagnosis:

SELECT carrier_id FROM vicidial_log 
WHERE call_date >= DATE_SUB(NOW(), INTERVAL 5 MINUTE) LIMIT 1;

Find the carrier, then check its codec:

asterisk -rx "sip show peer [carrier_name] detailed" | grep codec

Solution:

Verify agent allows carrier's codec
Add codec to agent peer: allow=[carrier_codec]
Ensure directmedia=no on both sides

Scenario 3: Both Directions Have Audio, But Intermittent Cutouts

Typical Cause: Jitter, packet loss, or RTP port exhaustion.

Diagnosis:

# Check for port exhaustion
netstat -an | grep ESTABLISHED | wc -l
# If > 50,000, approaching limit

# Check jitter on active calls
asterisk -rx "rtp show stats" | grep -i jitter

Solution:

Increase RTP port range in asterisk.conf:

[rtp]
rtpstart=10000
rtpend=30000

Restart Asterisk
Investigate network jitter with tcpdump

Section 9: Performance Considerations

Optimize Asterisk for ViciDial Load

For high-call-volume ViciDial environments, optimize Asterisk:

# Edit /etc/asterisk/asterisk.conf
nano /etc/asterisk/asterisk.conf

Add these settings:

[options]
threadpool_initial_size=50
threadpool_max_size=500
cache_record_buffers=128
maxcalls=10000
maxload=0.9
maxfiles=65536

[rtp]
rtpstart=10000
rtpend=30000
tos=ef
cos=5
dtmf_mode=rfc2833_fax

Tune SIP Settings for Reliability

Edit /etc/asterisk/sip.conf:

[general]
# Increase retransmit timers for carrier reliability
retransmission_timer=500
max_retransmissions=6

# Improve scalability
srvlookup=yes
pedantic=no
notifyringing=yes
disallow=all
allow=ulaw
allow=alaw

# NAT settings
localnet=192.168.0.0/255.255.0.0
externip=203.0.113.50

Monitor Call Quality Metrics

Create a monitoring script to track audio issues:

#!/bin/bash
# save as /usr/local/bin/monitor_vicidial_audio.sh

while true; do
    echo "=== $(date) ==="
    
    # Check active calls
    ACTIVE=$(asterisk -rx "core show calls" | grep "active calls" | awk '{print $1}')
    echo "Active calls: $ACTIVE"
    
    # Check codec mismatches
    MISMATCHES=$(grep -c "codec mismatch" /var/log/asterisk/messages)
    echo "Codec mismatches: $MISMATCHES"
    
    # Check RTP errors
    RTP_ERRS=$(grep -c "RTP.*error\|RTP.*timeout" /var/log/asterisk/messages)
    echo "RTP errors: $RTP_ERRS"
    
    sleep 60
done

Run it:

chmod +x /usr/local/bin/monitor_vicidial_audio.sh
/usr/local/bin/monitor_vicidial_audio.sh &