Why Calls Drop Before Transfer: Diagnosing Carrier, IVR, and Buyer-Side Failures

The call log said 847 connected calls. My buyer said she got 614. That's 233 calls — gone. Not abandoned. Not hung up by callers. Just... missing between my platform and her phone.

I spent four days on this. Four days I'll never get back, staring at SIP traces like they were going to confess something.

The IVR had a conditional branch for callers who pressed something other than 1, 2, or 3. The branch existed. But it didn't route anywhere. Just sat there, doing nothing, while I blamed the carrier. Callers pressed 4 (which wasn't an option, but people do that) and the system just dropped them. Silent disconnect. No error log screaming "hey, you forgot something."

That's the problem with pre-transfer drops. They're quiet failures. Your dashboards show connected calls because the inbound leg connected. But the outbound leg to the buyer never happened. And callers don't complain — they just hear silence and hang up.

This guide covers the three layers where calls die before reaching buyers: carrier-level SIP failures, IVR dead-ends, and buyer-side rejections.

What We're Diagnosing

Calls that:

• Connected (inbound leg shows duration)
• Never reached the buyer (no buyer leg, or 0-second duration)
• Didn't abandon intentionally (caller waited through IVR prompts)

These are pre-transfer drops. The caller did everything right. Your infrastructure failed silently.

Prerequisites

You'll need access to:

• Call detail records (CDRs) with SIP response codes
• Your IVR flow configuration — visual builder or config file
• Basic SIP knowledge — 200 = success, 4xx/5xx = failure

On VeloCalls, CDRs with SIP codes are in the analytics dashboard. On Ringba or CallRail, export raw logs or enable verbose logging.

Layer 1: Carrier-Side SIP Failures

The call leaves your platform. The SIP INVITE goes to the buyer's carrier (Twilio, Telnyx, Bandwidth). Something breaks.

What to look for:

Filter for calls where inbound duration > 30 seconds, outbound duration = 0, and SIP response is 4xx or 5xx.

The fixes:

408/504 timeouts: Increase ring timeout to 45-60 seconds. If your timeout is 20 seconds but the buyer's PBX needs 25 to answer, every call fails.

486 busy: Set concurrency caps per buyer. In VeloCalls routing rules, configure this. If you're pushing 10 calls to a buyer with 5 channels, half fail.

503/500 carrier issues: Build retry logic — wait 5 seconds and try again before escalating. I've seen 503s recover on second attempt 40% of the time.

480 unavailable: Buyer's trunk is offline. Don't retry — escalate to backup buyers immediately.

One thing I learned the hard way: SIP logs show the final response code but not intermediate ones. A 487 (cancelled) might mean you hit your timeout while waiting for the buyer's 100 Trying response. Check your ring timeout against the buyer's typical answer time.

Honestly? I think most call routing platforms bury this diagnostic data too deep. You shouldn't need to export CSVs and run pivot tables to find a misconfigured timeout. But here we are.

Layer 2: IVR Dead-Ends

The caller navigated your IVR. Pressed buttons. Answered questions. Then — nothing. The IVR didn't route them anywhere.

This is the most common pre-transfer failure, and hardest to find because it's your own configuration.

Where to look:

Trace every IVR path. For each, ask: where does this terminate?

Valid terminations: route to buyer, voicemail with callback, overflow queue, graceful hangup with callback promise.

Invalid terminations: branch with no action, timeout with no fallback, input handler with no default case.

Common culprits:

Missing default handlers. IVR asks "Press 1 for sales, 2 for support." Someone presses 7. Or speaks instead of pressing buttons. If you haven't defined those handlers, the call sits there until global timeout — and if global timeout is "disconnect," the call drops.

Fix: Add a catch-all that routes to your most general buyer or overflow queue.

Time-based routing gaps. Your IVR checks business hours and routes during the day. But what's the else branch? I audited a campaign where 23% of calls came after 6pm — all dropped because the after-hours branch routed to nothing.

Fix: After-hours goes to voicemail, 24/7 overflow buyer, or clear callback message. Never empty.

Conditional branches with impossible states. Routing by ZIP code, but ANI lookup fails and ZIP returns null. Your conditions don't handle null. Call drops.

Fix: End conditional chains with a default route. "If none of the above, send to national overflow."

DTMF input loops with no exit. Caller enters ZIP. System says "I didn't recognize that, try again." After 3 attempts, what happens? If no break condition, they're stuck until they hang up.

Fix: Cap retries at 2-3, then route to live agent.

VeloCalls' visual IVR builder highlights paths without termination points in red. Helpful. But even with visual tools, call through the entire flow manually. I've seen validators miss edge cases that real callers hit.

(Full disclosure: I once spent two hours debugging a "broken" IVR that worked perfectly. The problem was my test phone had Do Not Disturb on. I'm not proud of this.)

Layer 3: Buyer-Side Rejections

The call left your platform. SIP INVITE succeeded. Buyer's system picked up — sort of. Then rejected it.

What to look for:

• Outbound leg shows 5-15 second duration
• SIP response was 200 OK (call "connected")
• No buyer disposition recorded

The buyer's PBX answered the SIP INVITE, started ringing internally, then their agent didn't pick up or their system errored out.

Failure modes:

Buyer ring timeout shorter than yours. Your platform waits 45 seconds. Buyer's PBX waits 20, then disconnects. Call "connected" but nobody answered.

Fix: Set yours slightly shorter than theirs so you escalate before their hangup.

Caller ID rejection. Some buyers reject specific caller IDs — blocked numbers, out-of-area codes, internal spam lists.

Fix: Confirm your outbound caller ID is whitelisted. More common with enterprise buyers.

Network jitter. Call connected, audio started, but packet loss caused drops. Buyer's system detected silence and disconnected as "ghost call."

Fix: Route through different carrier trunk. Twilio to Telnyx might be cleaner than Telnyx to a regional carrier. Your mileage will vary — I've seen the opposite too.

Reading Drop Logs: Workflow

Pull last 7 days and segment:

Step 1: Categorize calls with duration > 30 seconds and no conversion:

• IVR drop (no buyer leg created)
• Carrier fail (buyer leg created, SIP 4xx/5xx)
• Buyer reject (buyer leg created, 200 OK, duration < 15 seconds)
• Normal abandon (caller hung up voluntarily)

Step 2: Drill into biggest segment. If 60% are IVR-layer, audit your IVR. If 80% are timeouts to one buyer, talk to that buyer.

Step 3: Cross-reference with caller journey. For IVR drops: last DTMF input before disconnect. For carrier fails: time-of-day spikes. For buyer rejects: which buyers have highest reject rates.

Step 4: Fix top 3 issues and re-measure for a week.

For tracking downstream impact, JustAnalytics correlates call completion with traffic source quality.

Common Errors

487 Request Terminated but you didn't cancel. Your ring timeout hit. Increase to 40+ seconds.

408 Timeout to one buyer, others fine. That buyer's carrier is slow. Route them lower priority or try alternate trunk.

IVR works in testing, drops in production. You're testing with DTMF. Real callers use voice, press wrong buttons, or have DTMF recognition failures on bad cell connections. Add lenient input handling.

Calls drop at exactly 30 seconds. That's your global no-activity timeout. Caller hit a path with no prompt and sat in silence. Trace which path produces silence.

Buyer reports "ghost calls" — no audio. One-way audio from NAT traversal failure or codec mismatch. Escalate to carrier — enable STUN/TURN, verify G.711 compatibility.

Next Steps

Set up drop alerting. Fire when pre-transfer drops exceed 5% of connected calls. Don't wait for weekly reports.

Build fallback cascades. Every buyer has a backup. Every IVR branch has a default. Every carrier route has retry or escalation.

Audit quarterly. IVR configs drift. Buyers change infrastructure. Schedule quarterly walkthroughs of your entire flow. (I know nobody actually does this. Do it anyway.)

If drops trace to traffic quality — bots generating garbage calls — ClickzProtect filters at the traffic layer before bad clicks become bad calls.

For related reading: fixing low answer rates covers problems that often mask drops, and our IVR abandonment study has vertical benchmarks.

Drop diagnosis isn't glamorous. Nobody's going to high-five you for fixing a timeout config. But when you're paying $40+ per call and 15% vanish before reaching a buyer, finding where they die is the highest-ROI debugging you can do.

Frequently Asked Questions

Why do calls show as connected but never reach the buyer?

Three common causes: the IVR hit a dead-end path with no forward route, the SIP handoff to the buyer's carrier timed out (typically after 30 seconds with no response), or the buyer's system rejected the call with a 4xx/5xx SIP response. Pull your call detail records and filter for calls with duration under 60 seconds that never reached buyer disposition. Check the SIP response codes — 408 means timeout, 486 means buyer busy, 503 means their system was unavailable.

What SIP response codes indicate a carrier-side failure?

Watch for 408 (Request Timeout), 480 (Temporarily Unavailable), 503 (Service Unavailable), and 504 (Gateway Timeout). These mean the call left your platform successfully but failed during carrier handoff or routing. 5xx errors are infrastructure problems on the receiving end. 4xx errors often indicate configuration issues — wrong trunk credentials, exceeded concurrent limits, or the buyer's carrier rejecting the caller ID.

How do I fix IVR paths that cause call drops?

Audit your IVR flow for dead-ends — paths that don't route to a buyer, voicemail, or callback queue. Common culprits: conditional branches with no default fallback, timeout logic that drops instead of escalating, and DTMF input branches missing handlers for invalid entries. Test your IVR by calling every path manually and logging where each one terminates. Add fallback routes on every branch.

What's the difference between a call that drops before transfer and one that drops during transfer?

Before transfer means the call ended while still in your IVR or routing layer — before any SIP INVITE went to the buyer. During transfer means the SIP handoff started but failed mid-connection. The log distinction: pre-transfer drops show your platform as the terminating party with no buyer leg created; mid-transfer drops show a buyer leg that never reached "answered" state. Pre-transfer is usually IVR config. Mid-transfer is usually carrier or buyer infrastructure.

Try VeloCalls for Your Vertical

AI calling + pay-per-call platform built for HVAC, plumbing, roofing, PI lawyers, Medicare brokers, and insurance. Smart routing, real-time bidding, visual IVR builder, AI conversation intelligence. Per-minute pricing — Managed starts at 4¢/min, BYOC at 2¢/min, both drop as you scale.

See pricing → · Book a demo