How to read the Carrier Log Report when calls aren't going out

Some mornings the agents log in, the hopper is full, and nothing dials. Or calls fire but every one fails instantly. When the problem looks like it lives between your dialer and the outside world, the Carrier Log Report is the report to open. It shows all dial attempts and the response codes of calls going out from your system, and it lets you download those logs to share with whoever you call for help.

What the carrier side actually is

Your Carrier is the company that hands your calls off to the public phone network. You reach it over a SIP trunk — a signalling path configured as a Trunk in your system. Every attempt that leaves your box rides that trunk and comes back with a SIP response code. The Carrier Log Report collects those attempts and codes in one place so you can see whether the carrier is even accepting your calls.

Reading the attempts

The report's value is the pairing of attempt and response. A row tells you a call was sent and what came back. Group the responses in your head:

• Mostly 200s — calls are leaving fine; your problem is somewhere else, probably the agent side or audio.
• A wall of 503s — the carrier is refusing for capacity reasons; CONGESTION or a SIP 503 Service Unavailable cluster usually means a saturated or down trunk.
• 403 or 401 — authentication or permission rejections; your trunk credentials or your outbound CID (caller ID) are being refused.
• No rows at all for a time window — the dialer never sent anything, so the fault is upstream of the carrier.

That last case is the one people misread most often. If the Carrier Log Report is empty for the window when calls stopped, the carrier never even heard from you — so pointing fingers at the trunk wastes everyone's time. An empty window means the problem is on your side of the handoff: an empty hopper, a paused Campaign, a Dialplan route that no longer matches, or the dialer simply not being told to call. Reading "no rows" as a carrier outage is the classic wrong turn, and this report exists partly to stop you taking it.

A first-response flow

flowchart TD
  A[Calls not going out] --> B{Any rows in Carrier Log?}
  B -->|No rows| C[Problem is upstream: hopper / dialplan]
  B -->|Rows present| D{What response codes?}
  D -->|403 / 401| E[Trunk auth or CID rejected]
  D -->|503 congestion| F[Carrier capacity or trunk down]
  D -->|200| G[Calls leaving; look agent-side]

The download button matters more than it looks. When you open a ticket with your carrier, a CSV of real attempts and codes ends the back-and-forth fast — they can see their own response on their own side and stop blaming your box.

Watch for CHANUNAVAILABLE in the mix too. That tells you the channel could not be created at all — often a trunk that is registered but has no available lines, or a route pointed at a dead DID (direct inward dialing). It is a carrier-adjacent failure even though it looks like a local one.

Where to go next

If the codes here point at how individual calls ended, move to the Dial Log Report for per-call detail, or the Hangup Cause Report to see carrier hangup causes broken down. The troubleshooting playbook lays out which report to reach for first.

Tired of guessing whether the box or the carrier is at fault? VICIfast gives you a hardened, monitored dialer and clean logs from day one. See plans and pricing.