ViciDial carrier_log No Answer — Diagnosing Failed Outbound Calls

Master the art of troubleshooting "No Answer" call failures in ViciDial by reading carrier_log entries, analyzing Asterisk SIP traces, and identifying root causes in your telephony infrastructure

Prerequisites

Before diving into carrier_log diagnostics, ensure you have:

• A functioning ViciDial installation (v2.12+) with Asterisk 13+ or PJSIP
• SSH/command-line access to your ViciDial server
• MySQL client tools to query the asterisk database
• Familiarity with basic Asterisk and SIP concepts
• Access to /var/log/asterisk/ logs with read permissions
• Knowledge of your carrier's SIP trunk configuration
• Understanding of ViciDial call flow (Vicidial → Asterisk → Carrier → Destination)

Understanding carrier_log and No Answer

What is carrier_log?

The vicidial_carrier_log table is a critical diagnostic table in ViciDial that records every interaction between your Asterisk system and your telephony carrier. Unlike vicidial_log (which tracks agent calls), carrier_log captures the raw SIP signaling outcomes, timeouts, and provider responses.

When a call shows "No Answer" in carrier_log, it means one of these scenarios occurred:

1. The destination phone never rang (pre-answer failure)
2. The destination phone rang but nobody picked up within the timeout window
3. The carrier rejected the call before it reached the destination
4. A SIP timeout occurred during the call attempt

Key carrier_log Fields

SELECT * FROM vicidial_carrier_log WHERE carrier_log_id = 12345\G

Critical fields to examine:

• carrier_log_id: Unique identifier
• call_date: Timestamp of the call attempt
• carrier_id: Which carrier this call used
• phone_number: Dialed destination
• sip_code: The SIP response code (100, 180, 183, 200, 486, 487, 408, 503, etc.)
• sip_hangup_cause: Asterisk hangup cause string
• call_duration: How long the call lasted in seconds
• hangup_source: Where the disconnect originated (asterisk, carrier, bridge, etc.)

Architecture: Call Flow and Where "No Answer" Happens

Agent dials → ViciDial engine → Asterisk dialplan
    ↓
Asterisk creates SIP INVITE → Carrier SIP gateway
    ↓
Carrier routes call → Destination carrier
    ↓
Destination phone receives INVITE → Phone rings
    ↓
200 OK received → Bridge established
    ↓
Call connected / Hangup

"No Answer" failures typically occur at these points:

1. Pre-dial: Carrier rejects INVITE (4xx/5xx before 100 Trying)
2. Ringing: Phone rings (180 Ringing received) but caller hangs up or timeout
3. Timeout: Call exceeds configured timeout without answer (408)
4. Silent failure: INVITE lost, no response received

Step 1: Locate and Query carrier_log Entries

Find the relevant carrier_log record

# SSH into ViciDial server
ssh [email protected]

# Query the database for recent "No Answer" calls
mysql -u cron -p'YOURPASSWORD' asterisk << 'EOF'
SELECT 
    carrier_log_id,
    call_date,
    phone_number,
    sip_code,
    sip_hangup_cause,
    call_duration,
    hangup_source,
    carrier_id
FROM vicidial_carrier_log
WHERE sip_hangup_cause LIKE 'NO_ANSWER%'
    AND call_date >= DATE_SUB(NOW(), INTERVAL 2 HOUR)
ORDER BY call_date DESC
LIMIT 20;
EOF

Examine detailed carrier_log entry

mysql -u cron -p'YOURPASSWORD' asterisk << 'EOF'
SELECT 
    carrier_log_id,
    call_date,
    phone_number,
    session_id,
    sip_code,
    sip_hangup_cause,
    call_duration,
    hangup_source,
    carrier_id,
    tried_count,
    user_only
FROM vicidial_carrier_log
WHERE carrier_log_id = 567890\G
EOF

Example output:

*************************** 1. row ***************************
        carrier_log_id: 567890
            call_date: 2024-01-15 14:23:45
           phone_number: 15551234567
            session_id: 1705338225-4892
              sip_code: 180
      sip_hangup_cause: NO_ANSWER
        call_duration: 22
         hangup_source: asterisk
            carrier_id: 3
          tried_count: 1
           user_only: 0

Step 2: Correlate with Asterisk Full Logs

Enable verbose SIP logging

First, ensure Asterisk SIP debugging is configured:

# /etc/asterisk/logger.conf
[logfiles]
messages => verbose,debug,notice,warning,error
full => verbose,debug,notice,warning,error,dtmf,fax
sip => verbose,debug,notice,warning,error

Reload logger:

asterisk -rx "logger reload"

Capture SIP trace for the specific call

Use the session_id from carrier_log to find related Asterisk logs:

# Real-time SIP trace (next call)
asterisk -rx "sip set debug on"

# Make test call, then:
asterisk -rx "sip set debug off"

Review /var/log/asterisk/messages

# Search for the session_id from carrier_log
grep "1705338225-4892" /var/log/asterisk/messages | tail -50

# Or search for the phone number
grep "15551234567" /var/log/asterisk/messages | head -100

Example SIP trace showing "No Answer":

[2024-01-15 14:23:45] VERBOSE[31245][C-0000a2d7] app_dial.c: Called SIP/carrier3/15551234567
[2024-01-15 14:23:45] VERBOSE[31245][C-0000a2d7] netsock2.c: == Probation passed - setting RTP source address to 203.0.113.15
[2024-01-15 14:23:46] VERBOSE[31245][C-0000a2d7] pbx.c: > Channel SIP/carrier3-0000a2d8 joined 'simple_bridge' basic-bridge <C-0000a2d7>
[2024-01-15 14:23:46] VERBOSE[31245][C-0000a2d7] app_dial.c: SIP/carrier3-0000a2d8 is ringing
[2024-01-15 14:23:52] VERBOSE[31245][C-0000a2d7] pbx.c: == Spawn extension (from-vicidial, 15551234567, 1) exited non-zero on 'SIP/carrier3-0000a2d8'
[2024-01-15 14:23:52] VERBOSE[31245][C-0000a2d7] app_dial.c: SIP/carrier3-0000a2d8 answered
[2024-01-15 14:24:07] VERBOSE[31245][C-0000a2d7] app_dial.c: Timeout on SIP/carrier3-0000a2d8, checking if we should move on

Step 3: Analyze SIP Response Codes

Common SIP codes in carrier_log

Query for SIP code patterns

mysql -u cron -p'YOURPASSWORD' asterisk << 'EOF'
SELECT 
    sip_code,
    sip_hangup_cause,
    COUNT(*) as count,
    AVG(call_duration) as avg_duration
FROM vicidial_carrier_log
WHERE call_date >= DATE_SUB(NOW(), INTERVAL 24 HOUR)
    AND carrier_id = 3
GROUP BY sip_code, sip_hangup_cause
ORDER BY count DESC;
EOF

No Answer diagnosis:

• 180 + NO_ANSWER + 22 seconds: Phone rang, caller abandoned or timeout hit
• 408 + NO_ANSWER: Carrier didn't respond to INVITE in time
• 100 + NO_ANSWER + <2 sec: Call failed before reaching destination

Step 4: Check Carrier Configuration

Verify SIP carrier is correctly defined

mysql -u cron -p'YOURPASSWORD' asterisk << 'EOF'
SELECT 
    carrier_id,
    carrier_name,
    protocol,
    active,
    port,
    server_ip,
    failover_server_ip
FROM carriers
WHERE carrier_id = 3\G
EOF

Review Asterisk SIP peer configuration

# Find carrier peer definition
grep -A 30 "carrier3" /etc/asterisk/sip-vicidial.conf

Example configuration:

[carrier3]
type=peer
host=sip.carrier.com
port=5060
context=from-vicidial
disallow=all
allow=ulaw,alaw
nat=yes
insecure=port,invite
qualify=yes
qualifyfreq=60
defaultuser=vicidial_account
secret=your_sip_password
dtmfmode=rfc2833
progressinband=yes

Check for common carrier config issues

# Verify carrier is reachable
ping -c 3 sip.carrier.com

# Test SIP connectivity
asterisk -rx "sip show peers" | grep carrier3

# Check registration status
asterisk -rx "sip show registry" | grep carrier3

Example output — look for "Registered":

Host                                                    dnsmgr Username       Reg.Expires Status
sip.carrier.com:5060                                    N      vicidial_acco 3600       Registered

Step 5: Examine Dialplan Execution

Review the dialplan handling outbound calls

cat /etc/asterisk/extensions-vicidial.conf | grep -A 50 "from-vicidial"

Typical outbound dialplan:

[from-vicidial]
exten => _X.,1,NoOp(Outbound call to ${EXTEN})
exten => _X.,n,Set(CHANNEL(hangup_handler_push)=custom-handler,s,1)
exten => _X.,n,Dial(SIP/carrier3/${EXTEN},30,m)
exten => _X.,n,NoOp(Dial result: ${DIALSTATUS})
exten => _X.,n,Hangup()

The critical parameter is the timeout (30 seconds in above example).

Check actual call timeout configuration in ViciDial

mysql -u cron -p'YOURPASSWORD' asterisk << 'EOF'
SELECT 
    campaign_id,
    campaign_name,
    dial_timeout,
    ringback_time
FROM vicidial_campaigns
WHERE campaign_id = 'TESTCAMP'\G
EOF

Step 6: Diagnose Ring Timeout vs Actual No Answer

Determine if destination is actually ringing

Query for calls with 180 Ringing and NO_ANSWER:

mysql -u cron -p'YOURPASSWORD' asterisk << 'EOF'
SELECT 
    carrier_log_id,
    call_date,
    phone_number,
    sip_code,
    call_duration,
    hangup_source
FROM vicidial_carrier_log
WHERE sip_code = 180
    AND sip_hangup_cause = 'NO_ANSWER'
    AND call_date >= DATE_SUB(NOW(), INTERVAL 24 HOUR)
    AND carrier_id = 3
LIMIT 10;
EOF

Interpretation:

• 180 + call_duration 3-5 sec: Destination phone may not be ringing (SIP implementation issue)
• 180 + call_duration 20+ sec: Phone is ringing; customer simply not answering
• 180 + call_duration 30 sec: Timeout hit exactly at dialplan timeout

Check ringback delay vs actual ring detection

# Test call to known answering service
asterisk -rx "sip set debug on"

# From CLI or dialplan, originate test call
asterisk -rx "channel originate SIP/carrier3/15551234567 application playback silence/1"

asterisk -rx "sip set debug off"

# Review messages
tail -200 /var/log/asterisk/messages | grep -E "180|183|200|Called"

Step 7: Investigate Carrier-Side Issues

Check carrier's SIP response headers

Enable full SIP packet capture:

# Install tcpdump if needed
yum install tcpdump -y

# Capture SIP traffic to/from carrier
tcpdump -i any -s 0 -w /tmp/sip_capture.pcap "host sip.carrier.com and port 5060"

# Let it run during a test call, then Ctrl+C

# Analyze with Wireshark or tshark
tshark -r /tmp/sip_capture.pcap -Y "sip.method==INVITE or sip.CSeq.method==INVITE" -V | head -200

Check carrier logs through API or portal

Most carriers provide:

• Web portal CDR access
• API access to call records
• Support email for detailed call traces

Request from carrier:

• INVITE received timestamp
• 180 Ringing timestamp
• Whether call reached destination
• Destination carrier response codes

Test with known phone numbers

# Test with carrier's demo/testing numbers
# Most carriers provide test numbers that:
# - Always answer immediately (instant 200 OK)
# - Simulate no-answer (ring then timeout)
# - Simulate busy tone
# - Simulate invalid number

# Ask your carrier support for test numbers

Step 8: Check ViciDial Agent Timeout Settings

Review call timeout in campaign

mysql -u cron -p'YOURPASSWORD' asterisk << 'EOF'
SELECT 
    campaign_id,
    campaign_name,
    dial_timeout,
    ringback_time,
    answer_detect,
    amd_level
FROM vicidial_campaigns
WHERE active = 'Y'\G
EOF

Check list-level overrides

mysql -u cron -p'YOURPASSWORD' asterisk << 'EOF'
SELECT 
    list_id,
    list_name,
    dial_timeout,
    ringback_time
FROM vicidial_lists
WHERE list_id = 101\G
EOF

Examine specific lead in vicidial_log

mysql -u cron -p'YOURPASSWORD' asterisk << 'EOF'
SELECT 
    uniqueid,
    lead_id,
    list_id,
    campaign_id,
    status,
    call_date,
    call_duration,
    phone_number
FROM vicidial_log
WHERE lead_id = 98765
    AND call_date >= DATE_SUB(NOW(), INTERVAL 24 HOUR)
ORDER BY call_date DESC\G
EOF

Step 9: Common Causes and Fixes

Issue #1: Timeout Set Too Short

Symptom: Calls consistently showing NO_ANSWER with 180 Ringing, but call_duration is exactly your dial_timeout value (e.g., always 15 seconds).

Root cause: Phone is ringing, but timeout expires before destination has chance to pick up.

Fix:

# Increase dial_timeout in campaign
mysql -u cron -p'YOURPASSWORD' asterisk << 'EOF'
UPDATE vicidial_campaigns 
SET dial_timeout = 45 
WHERE campaign_id = 'TESTCAMP';
EOF

# Verify change
mysql -u cron -p'YOURPASSWORD' asterisk << 'EOF'
SELECT campaign_id, dial_timeout FROM vicidial_campaigns WHERE campaign_id = 'TESTCAMP';
EOF

Issue #2: Carrier Not Routing Calls to Destination

Symptom: SIP code 180 or 183 received, but call_duration is very short (2-5 seconds), then NO_ANSWER.

Root cause: Carrier answered with ringback but didn't complete call to actual destination.

Fix:

1. Contact carrier support with INVITE timestamp from your logs
2. Ask carrier to verify routing rules for your account
3. Check if your CLI (caller ID) is being rejected by destination
4. Test from carrier's test system

Issue #3: No Progress Indication (Silent Failure)

Symptom: SIP code 100 (Trying), NO_ANSWER, call_duration <2 seconds.

Root cause: Call failed at carrier before progressing toward destination.

Fix:

# Check carrier registration status
asterisk -rx "sip show registry"

# Verify carrier peer is available
asterisk -rx "sip show peers" | grep carrier3

# Test carrier connectivity
asterisk -rx "sip show peer carrier3"

# Check ACL rules
mysql -u cron -p'YOURPASSWORD' asterisk << 'EOF'
SELECT * FROM carriers WHERE carrier_id = 3\G
EOF

Issue #4: Destination Network Issues

Symptom: Intermittent NO_ANSWER; sometimes works, sometimes doesn't.

Root cause: Destination carrier or phone system is experiencing packet loss or jitter.

Fix:

# Monitor RTP packet loss
asterisk -rx "rtp show stats"

# Check jitter measurements
asterisk -rx "rtcp show" | grep -A 5 "carrier3"

# Increase RTP payload size if needed
grep -n "maxrtpplayer" /etc/asterisk/rtp.conf

Issue #5: DTMF or Codec Mismatch

Symptom: Call connects, but phone may not be detecting dialed tones or audio issues.

Root cause: Codec incompatibility or DTMF mode mismatch.

Fix:

# Verify codec agreement
# /etc/asterisk/sip-vicidial.conf

[carrier3]
allow=ulaw,alaw
dtmfmode=rfc2833

Test call with codec specification:

asterisk -rx "sip show peer carrier3" | grep -E "Codec|DTMF"

Troubleshooting

Problem: Too many "No Answer" calls suddenly appearing

Steps:

1. Check if carrier is registered:

   asterisk -rx "sip show registry"
   

2. Query for recent changes:

   mysql -u cron -p'YOURPASSWORD' asterisk << 'EOF'
   SELECT * FROM vicidial_campaigns WHERE modified_date >= DATE_SUB(NOW(), INTERVAL 1 HOUR);
   EOF
   

3. Check Asterisk uptime:

   asterisk -rx "core show uptime"
   

4. Review carrier status in last hour:

   grep "carrier3" /var/log/asterisk/messages | tail -100
   

Problem: Only specific carrier has "No Answer" issues

Steps:

1. Compare working vs. non-working carrier:

   mysql -u cron -p'YOURPASSWORD' asterisk << 'EOF'
   SELECT carrier_id, COUNT(*) as total, 
       SUM(CASE WHEN sip_hangup_cause='NO_ANSWER' THEN 1 ELSE 0 END) as no_answer_count
   FROM vicidial_carrier_log
   WHERE call_date >= DATE_SUB(NOW(), INTERVAL 24 HOUR)
   GROUP BY carrier_id
   ORDER BY no_answer_count DESC;
   EOF
   

2. Test failover:

   # Temporarily disable primary carrier
   mysql -u cron -p'YOURPASSWORD' asterisk << 'EOF'
   UPDATE carriers SET active='N' WHERE carrier_id=3;
   EOF
   
   # Make test calls to see if secondary carrier works
   # Then re-enable
   mysql -u cron -p'YOURPASSWORD' asterisk << 'EOF'
   UPDATE carriers SET active='Y' WHERE carrier_id=3;
   EOF
   

3. Check carrier-specific dialplan:

   grep "carrier3\|Dial.*carrier3" /etc/asterisk/extensions-vicidial.conf
   

Problem: "No Answer" but agent claims phone rang at destination

Steps:

1. Get destination phone's call logs

2. Correlate timestamps between:

   • Your carrier_log call_date
   • Destination's received call timestamp
   • Timezone differences

3. Request detailed CDR from destination carrier

4. Check if CLI (caller ID) is being blocked:

   mysql -u cron -p'YOURPASSWORD' asterisk << 'EOF'
   SELECT * FROM vicidial_caller_id_log WHERE call_date >= DATE_SUB(NOW(), INTERVAL 24 HOUR) LIMIT 5;
   EOF
   

Problem: Intermittent "No Answer" on specific numbers

Steps:

1. Find pattern in failed numbers:

   mysql -u cron -p'YOURPASSWORD' asterisk << 'EOF'
   SELECT 
       phone_number,
       COUNT(*) as attempts,
       SUM(CASE WHEN sip_hangup_cause='NO_ANSWER' THEN 1 ELSE 0 END) as no_answers
   FROM vicidial_carrier_log
   WHERE call_date >= DATE_SUB(NOW(), INTERVAL 7 DAYS)
   GROUP BY phone_number
   HAVING no_answers > 3
   ORDER BY no_answers DESC;
   EOF
   

2. Check if specific area codes/exchanges are problematic

3. Test with different CLI origination

4. Contact destination carrier about those specific numbers

Summary

Diagnosing "No Answer" issues in ViciDial's carrier_log requires a systematic approach:

1. Identify the carrier_log record — Query vicidial_carrier_log for specific failed call
2. Note the SIP code — Understand what the carrier responded with
3. Check call duration — Short duration = pre-answer failure; Long = ringing timeout
4. Correlate with Asterisk logs — Use session_id to find detailed SIP traces in /var/log/asterisk/messages
5. Verify carrier configuration — Ensure SIP peer is active, registered, and accessible
6. Test with known numbers — Use carrier-provided test numbers to isolate issues
7. Adjust timeout settings — Increase dial_timeout if phones legitimately need more time to ring
8. Escalate to carrier — Provide detailed CDR, timestamps, and SIP traces for investigation

Key ViciDial tables for carrier_log analysis:

• vicidial_carrier_log — Raw call attempt records
• vicidial_log — Agent-facing call records (may not match carrier_log)
• vicidial_campaigns — Campaign timeout settings
• carriers — Carrier configuration and status
• vicidial_lists — List-level overrides

Most common root causes:

• Timeout set too short (45+ seconds recommended for most destinations)
• Carrier not routing calls (contact carrier support)
• Carrier registration issues (verify with sip show registry)
• Destination network problems (verify destination carrier status)
• CLI being rejected (check vicidial_caller_id_log)

By methodically working through these steps, you can pinpoint whether "No Answer" failures originate from your Asterisk/ViciDial configuration, your carrier's SIP implementation, or the destination phone/network — and take appropriate corrective action.