How to trace one bad call end to end across the log reports

When one call goes wrong and you want to know exactly why, the answer is rarely in a single report. Each report tells you one layer of the story. The skill is following the same call through them in order, so the dial result, the release reason, the carrier view, and the number used all line up into one picture. Once you have done it a few times the path becomes second nature.

You only need one piece of information to start: a lead ID and roughly when the call happened. Get that from an agent complaint, a customer callback, or a suspicious row in the live report.

Step 1: find the call in the Dial Log Report

Open the Dial Log Report for the right date and narrow to your lead. Each row lists the lead ID, the server IP that placed the call, the call date, the extension and Channel, the outbound caller ID, and the SIP hangup cause code with its reason. The SIP code is the headline. A SIP (Session Initiation Protocol) result like 200 means the call was answered, while a 4xx or 5xx code means it failed, and the number tells you roughly why. Note the unique ID on the row — you will use it to match the same call in other reports.

The full field tour lives in how to read the Dial Log Report.

Step 2: read the hangup cause

The SIP code tells you how the dialer saw the end of the call. The Hangup Cause Report tells you how the carrier saw it. Look up your call's Hangup cause here and compare. A normal clearing cause on an answered call is fine. A cause like number unallocated, call rejected, or no circuit available points at the destination or the route, not your dialer. Matching the SIP code against the hangup cause is the heart of the trace — agreement narrows the suspect, disagreement is itself a clue.

If the hangup causes look wrong across the board, read how to read the Hangup Cause Report before you jump to the carrier.

Step 3: cross-check the Carrier Log

Now go to the carrier's own view. The Carrier Log shows every dial attempt and response code leaving the box, including detail the dialer-side reports skip. If your Carrier returned a rejection or a busy circuit on this call, you will see it here in the carrier's words. This is where a dialer problem and a Trunk problem separate: if the dial log shows a clean attempt but the carrier log shows an immediate reject, the issue is downstream of your box.

Step 4: the Caller ID and AMD logs

Two more reports finish the picture. The Caller ID Log breaks calls down by the CID (caller ID) number used, so if your bad call went out on a number that is getting rejected or flagged, you will spot the pattern across recent calls on the same number. The AMD Log shows what Answering Machine Detection decided — useful when a live call was wrongly treated as a machine, or a machine slipped through as a live answer.

• Caller ID Log: confirm the number used and whether that number shows a rising failure rate. See how to read the Caller ID Log Report.
• AMD Log: confirm whether detection mislabeled the call. See how to read the AMD Log Report.

The trace path

flowchart TD
  A[Lead ID and time] --> B[Dial Log Report]
  B --> C[Read SIP hangup code]
  C --> D[Hangup Cause Report]
  D --> E[Carrier Log]
  E --> F{Carrier rejected?}
  F -- Yes --> G[Fix route or carrier]
  F -- No --> H[Caller ID Log and AMD Log]
  H --> I[Cause found]

Done in order, this trace turns a vague "this call was bad" into a precise statement: the dialer dialed cleanly, the carrier rejected with a specific cause, on a specific number. That is a cause you can act on. The wider context is in the VICIdial troubleshooting playbook.

VICIfast keeps all of these reports wired up and the carrier side watched on a managed, hardened VICIdial box, live in under 40 seconds. See our plans and pricing.