Call Logs and CDRs: Read Them to Debug Missed and Dropped Calls

You read call logs and CDRs by pulling the most detailed inbound log for the exact call, then mapping each leg and its last response to find the first failure point. Use the per-leg SIP codes and timestamps to see if routing, target reachability, or a refusal ended the call. Follow the steps below and you’ll finish with a clean call timeline, the right IDs to correlate across systems, and a fix you can test. Plan about 20–30 minutes for the first case, much less for the next ones.

Start here: the fastest path to debug a missed or dropped call

1. Find the exact call in your inbound call logs. Filter by dialed number (the number the caller dialed), caller number, and a tight time window. Open the most detailed view you have. This should show each routing step, not just a single line.

2. Confirm direction and entry number. Note the call direction (inbound), the entry number (the business number the caller reached), and any unique IDs: Call-ID, trace ID, or a platform correlation key. You will use these to match legs across systems later.

3. Write down the final disposition and the last response on each leg. Look for a per-leg outcome such as “180 Ringing,” “200 OK,” “480 Temporarily Unavailable,” or a human-readable reason. Note any failover or overflow the platform tried next. This tells you where the call moved and where it stopped.

4. Retest right away. Place a fresh test call from a different line so caller ID does not trigger spam blocks or contact screening. Try to reproduce the behavior. Keep a live log or dashboard open if your platform has one, and capture the new Call-ID and the same field set.

5. Form a first guess. If you see timeouts on a target line, think device offline or mobile coverage. If you see quick declines, think buyer schedule, caps, or call screening. If you see no per-leg attempt at all, think routing logic or policy block.

Outcome: you now have the call’s timeline, the call IDs that matter, and a first guess at whether routing, target reachability, or a user refusal caused the miss.

Call logs and CDRs: what they show

A CDR (call detail record) is a structured line a system writes for a call with who called, who was called, when it started and ended, and how it ended. It is the billing-grade source of truth. Inbound call logs are often a richer, per-event trail for the same call, with each leg or routing step shown in order.

Key fields you will see and use:

• Caller/ANI (the caller’s phone number).
• Dialed number/DNIS (the number the caller reached).
• Start time, answer time, and end time.
• Ring time (time from routing to answer) and talk time (time you were connected).
• Disposition (how the call ended: answered, busy, no answer, blocked, voicemail).
• Recording link (if you enabled call recording).
• Correlation IDs (Call-ID or a platform key to tie legs together).

Many platforms add per-leg detail in the same expanded log. You might see one row for entry and IVR (interactive voice response, a menu), then one row for each target attempt, then queue, then voicemail. Others collapse attempts into a single row with a nested event list. Either way, the order and timestamps are your map.

SIP (Session Initiation Protocol, the call signaling protocol many systems use) responses may appear as numeric codes per attempt, like 180, 200, 480. Other systems write them as short reasons in plain words. Both are fine as long as the format is consistent within your tool.

Confirm the timezone before you export or compare logs. Set all systems to the same timezone for your review, or use UTC. Many call traces fail because one export is local time and another is UTC, or because daylight saving time switched in one region and not the other. If you route between the United States and South or Southeast Asia, align timezones before you match events.

A quick aside for anyone using CallFlow: the inbound call log shows per-leg outcomes with timestamps and SIP codes, and you can filter by number, buyer, or target.

Trace the call across legs (one clean method)

Use this flow as your mental template. Now map what you see in the log to these steps:

• Entry: the call hits your main number. You get a start time.
• IVR: the caller presses 1 for Sales, and the log shows the DTMF event (key press).
• First target: the platform dials Agent A’s mobile. Healthy legs show 100 Trying, then 180 Ringing. If the agent answers, you see 200 OK and a talk segment. If not, you will see 480/408 and a return to the router.
• Second target: the platform dials Agent B by SIP. Again, look for 180 Ringing and 200 OK if answered, or a failure code if not.
• Queue: if both targets fail or do not answer, the call moves to the queue. You should see a ring or hold timer, then either an agent pickup or a timeout.
• Voicemail: the call lands in voicemail if the queue times out. The log shows a voicemail start and end.

A healthy trace has every attempted leg with a clean progress path: 100 Trying, 180 Ringing or 183 Early Media, then 200 OK. The recording and talk time match the 200 OK. A failed attempt shows a non-200 code like 480 Temporarily Unavailable or 408 Request Timeout, followed by the next leg starting within a second or two.

If you traverse multiple systems (your routing platform, then a buyer’s PBX), correlate by the call’s correlation ID when both sides expose it. When IDs differ, align by caller number, dialed number, and start or ring timestamps within a 2–5 second window. This is your call flow audit: each log line must match a step.

Read SIP response codes in a CDR (and what to do)

SIP codes are short numeric results for each attempt. Here is the quick map you will see often:

• 100 Trying: the network accepted your attempt.
• 180 Ringing: the far end is ringing.
• 183 Early Media: progress with audio, but not yet answered.
• 200 OK: answered.
• 486 Busy Here: user is busy.
• 480 Temporarily Unavailable: destination reachable but not available.
• 408 Request Timeout: no response from the device.
• 603 Decline: the user or system refused the call.
• 607 Unwanted: the callee marked the call as unwanted.
• BYE: hangup; the call ended after answer.

For a deeper list and how spam labels tie in, see SIP response codes and spam detection.

Callee refused vs unreachable

Refused means someone or something said “no.” You will see 603 Decline or 607 Unwanted. Actions:

• Check the buyer or agent schedules. Make sure you are not calling outside their set windows.
• Check duplicate-caller or caps. If you cap daily leads, the system may refuse by policy.
• Check spam labeling and screening. If numbers show “Spam Likely,” callee apps may auto-decline. Rotate caller IDs with a clean history, and watch your call pattern.

Unreachable means the device did not pick up the signaling. You will see 480 Temporarily Unavailable or 408 Request Timeout.

• For mobiles, check coverage and device Do Not Disturb. Repeated 480s at certain hours often match DND.
• For SIP softphones, verify registration is stable and NAT keepalives are on. Timeouts often point to lost registration or a blocked port. If you run softphones, review SIP softphone registration basics.
• Add a second target or simultaneous ring to remove the single point of failure.

486 Busy Here is different: the device is online and busy. Add overflow to another target or a short queue so callers do not drop. Use a ring timer of 20–25 seconds per leg to balance speed and reach.

Network or policy rejections

Some failures are not at the device. 403 Forbidden and similar results can come from network or platform policy:

• Platform-level blocks such as closed hours, geo filters by caller state, daily or concurrent caps, or blocklists will often appear as “Blocked by schedule,” “Cap reached,” or a similar non-SIP reason in the log. Treat these as routing decisions, not as carrier failures.
• On forwarded calls, remember the first leg may show 200 OK because your platform answered the caller. The second leg to the target can still fail with any of the codes above. Read per-leg results, not only the overall disposition.

Vendors label codes with slightly different text. Trust the numeric code over any label when both are present.

Where forwarding usually fails (and what the log will show)

Voicemail race on the target line is common. If you ring a mobile for too long, the carrier voicemail can grab the call. The CDR then shows “answered” with very short talk time and no agent audio in the recording. Fix it by using a 20–25 second ring timer per leg and moving to the next attempt before the target voicemail kicks in. If you still need longer reach, use a queue rather than a long single ring.

Ring timers that are too short can also hurt. If you dial a mobile and fail over after five seconds, the radio paging often has not settled yet. Callers hear one or two rings and then a jump. Logs show 480 or 408 on the first leg. Increase timers to 20–25 seconds and retest.

Closed hours or per-target windows stop calls by design. Platform logs show a schedule block and you will see an immediate skip to the next route or voicemail. Make sure the time zone on each target window is what the agent expects, and that holidays are set if your tool supports them.

Concurrent or daily caps can surprise you on busy days. Logs show “cap reached” and an overflow to a queue or alternate target. There will be no carrier error for this, because the platform never placed the attempt. If your operation sells calls, this is where a buyer cap or duplicate-caller rule can steer your routing. Review caps when answer rates dip in the afternoon.

SIP softphones not registered or behind NAT tend to show short bursts of “answered with no audio,” one-way audio, or straight timeouts (408/480) on attempted legs. Fix registration, keepalive, and timers, then place two test calls. If you need a checklist, see SIP softphone registration.

Mobile coverage gaps and Do Not Disturb show as repeated 480 or 486 at certain times. To ride through this, add an alternate target or enable a simultaneous ring to a second device. This removes a single point of failure and evens out answer rates. If answered calls still drop, review device battery and OS call settings on the agent phones.

If your forwarded calls are not ringing at all, check the basics in your routing and device. We keep a short guide at forwarded calls not ringing.

Correlate CDRs across systems cleanly

Use a shared ID when you have it. Many systems pass a Call-ID end to end. If both sides log it, that is your primary key. If not, match on dialed number, caller, and start time or ring time within a tight window of 2–5 seconds. Use more than one field so you do not match the wrong call during busy hours.

Align timezones before you compare. Export to UTC from each system if you can. If you must use local time, set both to the same city and watch for daylight saving time changes. Some countries never change clocks, while others shift twice a year. When you route across regions, even a one-hour drift can break a match.

If the buyer runs a PBX, pull their inbound CDR for the same window. Match their inbound leg (caller to their DID) to your outbound forwarding leg (your platform to their DID) by caller number, called number, and time. If your outbound leg shows 180 Ringing and their inbound shows no entry at all, you likely have a routing or carrier block before their PBX. If both show ringing and their side shows 486 Busy, adjust overflow on your side.

If you only have high-level billing CDRs for the past event, run a live test now to capture per-leg outcomes for the same targets. Infer the same pattern for last week’s call by comparing times and destinations. Then fix and monitor going forward.

Fix it, retest, and add guardrails

Apply the fix that matches the last failure you saw:

• Ring timers: use 20–25 seconds per leg so mobiles have time to ring, but not long enough for carrier voicemail to grab.
• Failover: add a second target or enable simultaneous ring to avoid single-device risk. If you need ideas, see failover call forwarding patterns.
• Schedules: set per-target windows correctly, including the right timezone. Confirm with a quick test near open and close.
• Queue and voicemail: route to a short queue with hold music, then to voicemail, so callers do not bounce around.
• SIP devices: fix registration stability, NAT keepalives, and codec timers. Retest until you see clean 180 then 200 in the log.
• Policies and caps: set daily and concurrent caps by target so a surge does not stall calls for one buyer while others are open.

Place two back-to-back test calls after each change. The first should hit the primary path and answer within the timer you set. The second should force your overflow path by making the primary busy or unreachable. Confirm both outcomes in the logs and, if you record, play the first few seconds to verify audio starts right after 200 OK.

Add guardrails so you catch issues early:

• Overflow routes and per-target caps keep calls moving when a device or buyer stalls.
• Scheduled email reports flag drops in answer rate by buyer or target before they bite. A simple daily summary is enough. If your platform has live monitoring, keep it open during peak hours so you can act in real time. You can also review trends in call analytics.
• Document the known-good flow with your timers and paths. Keep a one-page diagram and the field set you always collect (caller, dialed number, start time, disposition, per-leg code, Call-ID). Future audits should match logs to this intent.

If you want per-leg inbound call logs with SIP codes, routing rules, and live call monitoring, you can try CallFlow. You get US toll-free and local numbers plus numbers in several other countries, instant provisioning from a prepaid wallet, and flexible forwarding and routing. Sign up at /register or talk to us at /contact when you are ready to run a real test and watch the logs together.