DEV Community

Moisi Trungu
Moisi Trungu

Posted on • Originally published at flixzone.icu

Troubleshooting One-Way Audio in ViciDial / Asterisk

#devops #linux #sip #voip

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:

  1. Codec mismatches between endpoints
  2. RTP media path issues (firewall, NAT, port ranges)
  3. SIP signaling vs. media path divergence
  4. ViciDial bridge or transfer configuration errors
  5. Incorrect SIP peer definitions in sip-vicidial.conf
  6. Call recording configuration conflicts
  7. 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"
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

Stop debugging after reproducing the issue:

asterisk -rx "sip set debug off"
asterisk -rx "rtp set debug off"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Look for output like:

Codecs (inbound): (ulaw|alaw|gsm)
Codecs (outbound): (ulaw|alaw|gsm)
Enter fullscreen mode Exit fullscreen mode

Review SIP Configuration for Agent Channels

Edit your ViciDial SIP configuration:

nano /etc/asterisk/sip-vicidial.conf
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Verify Codec Negotiation in Call Logs

After running debug, search the logs for codec negotiation:

grep -i "codec" /var/log/asterisk/messages | tail -30
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Default configuration:

[rtp]
rtpstart=10000
rtpend=20000
tos=ef
cos=5
Enter fullscreen mode Exit fullscreen mode

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

sudo ufw status | grep 10000
sudo iptables -L | grep 10000
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Diagnose NAT Issues

One-way audio frequently occurs when:

  1. Agent is behind NAT, trunk is public - Agent can hear trunk (outbound RTP works), trunk can't hear agent (return RTP blocked)
  2. 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
Enter fullscreen mode Exit fullscreen mode

Correct NAT configurations:

For agents behind NAT (typical softphone scenario):

[agentpeer]
nat=yes
directmedia=no
Enter fullscreen mode Exit fullscreen mode

For carrier/trunk behind NAT:

[trunk]
nat=yes
directmedia=no
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Analyze the capture with Wireshark or tshark:

tshark -r rtp_capture.pcap -f 'rtp' -Y 'rtp' | head -20
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Look for bridge commands like:

exten => _X.,1,Bridge(${CALLVAR},${BRIDGEOPTIONS})
Enter fullscreen mode Exit fullscreen mode

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)
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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})
Enter fullscreen mode Exit fullscreen mode

Restart dialplan:

asterisk -rx "dialplan reload"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Expected output:

Context: from-internal
Enter fullscreen mode Exit fullscreen mode

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

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

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Verify Trunk Peer Definition Matches Carrier Config

Find the carrier in sip-vicidial.conf:

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

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
Enter fullscreen mode Exit fullscreen mode

Test Carrier Connectivity

Verify the trunk is registered and reachable:

asterisk -rx "sip show registry"
Enter fullscreen mode Exit fullscreen mode

Expected output shows registered trunks:

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

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"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode 
[agentpeer]
disallow=all
allow=ulaw
allow=alaw
Enter fullscreen mode Exit fullscreen mode

Monitor Active Trunk Calls

Check what calls are currently using trunks:

asterisk -rx "sip show channels" | grep carrier
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

Reproduce the issue, then immediately stop:

asterisk -rx "sip set debug off"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Trunk 200 OK SDP (with mismatched port):

m=audio 15432 RTP/AVP 0
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

Expected output:

Name                          Allocated  Freed      In Use
astobj2                       2097152    0          2097152
cache                         2097152    0          1048576
channel                       524288     0          262144
Enter fullscreen mode Exit fullscreen mode

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

ulimit -n
# Increase if needed:
ulimit -n 65536
Enter fullscreen mode Exit fullscreen mode

Monitor CPU usage during problematic calls:

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

Use Verbose Logging for Dialplan Execution

Enable verbose dialplan logging to see call flow:

asterisk -rx "core set verbose 7"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Solution:

  1. Check NAT settings: asterisk -rx "sip show peer agentpeer" | grep nat
  2. Set nat=yes and directmedia=no for agent peer
  3. 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;
Enter fullscreen mode Exit fullscreen mode

Find the carrier, then check its codec:

asterisk -rx "sip show peer [carrier_name] detailed" | grep codec
Enter fullscreen mode Exit fullscreen mode

Solution:

  1. Verify agent allows carrier's codec
  2. Add codec to agent peer: allow=[carrier_codec]
  3. 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
Enter fullscreen mode Exit fullscreen mode

Solution:

  1. Increase RTP port range in asterisk.conf: 
[rtp]
rtpstart=10000
rtpend=30000
Enter fullscreen mode Exit fullscreen mode
  1. Restart Asterisk
  2. 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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Run it:

chmod +x /usr/local/bin/monitor_vicidial_audio.sh
/usr/local/bin/monitor_vicidial_audio.sh &
Enter fullscreen mode Exit fullscreen mode

Troubleshooting

Common Mistakes When Troubleshooting One-Way Audio

Mistake 1: Only reloading SIP without reloading dialplan

# WRONG - Incomplete reload
asterisk -rx "sip reload"

# CORRECT - Both modules
asterisk -rx "sip reload"
asterisk -rx "dialplan reload"
Enter fullscreen mode Exit fullscreen mode

Mistake 2: Not checking both ends of the call

One-way audio is directional. You must check:

  • Agent peer config AND carrier peer config
  • Agent RTP port range AND carrier port range
  • Agent NAT setting AND carrier NAT setting

Mistake 3: Assuming all one-way audio has same root cause

The cause depends on direction:

  • Agent→Caller one-way? Check agent RTP and NAT
  • Caller→Agent one-way? Check carrier RTP and codec
  • Both intermittent? Check jitter and packet loss

Persistent One-Way Audio After Configuration Changes

If one-way audio persists after following this guide:

  1. Full Asterisk restart (not reload): 
systemctl stop asterisk
sleep 5
systemctl start asterisk
Enter fullscreen mode Exit fullscreen mode
  1. Clear SIP cache and registrations: 
asterisk -rx "sip prune realtime all"
asterisk -rx "sip prune peers"
Enter fullscreen mode Exit fullscreen mode
  1. Check for conflicting configurations: 
# Look for duplicate peer definitions
grep -n "^\[" /etc/asterisk/sip-vicidial.conf | grep -E "agentpeer|carrier" | sort
Enter fullscreen mode Exit fullscreen mode

If duplicates exist, remove them.

  1. Verify database consistency: 
-- Check for agents with malformed SIP config
SELECT * FROM vicidial_users 
WHERE phone LIKE '%%' 
AND user_phone_type NOT IN ('SIP', 'IAX2');
Enter fullscreen mode Exit fullscreen mode
  1. Escalation: Capture full trace

If none of above resolves it, capture comprehensive data:

# Set everything to debug
asterisk -rx "sip set debug on"
asterisk -rx "rtp set debug on"
asterisk -rx "core set verbose 10"

# Let it log for 30 seconds during problem call
# Then save logs
cp /var/log/asterisk/messages /tmp/vicidial_audio_debug_$(date +%s).log

# Analyze
grep "INVITE\|200 OK\|ACK\|RTP" /tmp/vicidial_audio_debug_*.log | head -100
Enter fullscreen mode Exit fullscreen mode

Summary

One-way audio in ViciDial/Asterisk environments typically results from codec mismatches, RTP path failures, or configuration errors. Use this systematic approach:

  1. Confirm the issue with database queries and call logs
  2. Enable debugging to see SIP and RTP flows
  3. Check codecs on both agent and carrier peers
  4. Verify RTP connectivity with tcpdump and packet analysis
  5. Review ViciDial-specific bridge and dialplan configurations
  6. Inspect carrier/trunk definitions and registration
  7. Use advanced tools like SDP analysis and RTP statistics
  8. Monitor continuously to prevent recurrence

The most common fixes:

  • Set nat=yes and directmedia=no for peers behind NAT
  • Align codecs between all SIP peers
  • Ensure firewall allows RTP port range
  • Verify bridge options include m, w, and T flags
  • Restart Asterisk (not just reload) after major config changes

With this guide and methodical debugging, you'll resolve even complex one-way audio issues in production ViciDial environments.

Top comments (0)