Forwarded Calls Not Ringing: A Practical Troubleshooting Playbook

Troubleshooting forwarded calls not ringing starts with facts, not guesses. If your numbers are on CallFlow and calls aren’t reaching the phones, SIP endpoints, or browser agents you expect, you can isolate the failure with live logs, SIP response codes, and a controlled test path. This playbook shows you how to track a call from the entry point to the exact target and fix the cause fast.

Key takeaways

• Watch real-time call logs while placing a test call; note the target, ring time, and SIP response.
• Map symptoms to SIP codes (486, 480, 408, 603, 607) to decide whether it’s device, routing, or callee preference.
• Check quiet stoppers: schedules, caller-state filters, weights/priorities, call caps, and how long calls are offered to each target.
• Align offer durations so mobile voicemail doesn’t grab calls; standardize across simultaneous ring groups.
• Build a safe test flow and include a backup target later in the routing order so one bad destination never kills your answer rate.

What “forwarded calls not ringing” really looks like

“Forwarded calls not ringing” covers a few repeatable symptoms:

• Never rings any target.
• Calls drop after one ring or very short ring, then fail.
• Goes straight to voicemail (yours or a target’s).
• Rings the wrong target.
• Rings too briefly to be answered by a human.

Distinguish platform-side routing from target-side problems. If the log shows no target attempts, focus on routing rules, caps, and schedules. If the log shows an attempt with a SIP response (486, 480, 408, 603, etc.), focus on the device, carrier settings, and voicemail timing.

Quick triage:

• Scope: Is it all numbers or just one? All targets or a specific device/carrier?
• Timing: New breakage or chronic? Did anything change (new target, schedule, cap, or a device reset)?
• Consistency: Do test calls from a known-good caller ID (ANI) behave differently than public traffic?

Example: A roofing company routes inbound leads to three mobiles and one SIP phone. Two mobiles and the SIP phone ring; one mobile never rings, or rings once and drops. Logs show attempts to that mobile returning 480 Temporarily Unavailable during weekday afternoons only. That points to device/service availability (e.g., cell coverage, device DND/focus) rather than a platform route.

Use real‑time call logs to see where the call died

Open your CallFlow dashboard and watch real-time call logs while making a controlled test call. The goal is to follow the call step-by-step and capture proof before you change anything.

What to look at in the log:

• Call ID: The unique identifier you’ll use to correlate attempts and share with support.
• Entry number: Which business number was dialed.
• Caller state/ANI: Useful if you use geographic filters.
• Route taken: Which campaign/IVR/queue/rule fired.
• Target: The exact destination (phone number, SIP URI, browser agent).
• Ring time: Seconds the target was offered the call.
• Result and SIP response: 180/183 (progress), 200 OK (answered), 486 Busy Here, 480 Temporarily Unavailable, 408 Request Timeout, 603 Declined, 607 Unwanted, etc.

Follow the timeline:

1. Inbound number.
2. IVR or queue (if configured).
3. Routing decision (priority/weighted/round-robin/simultaneous).
4. Target attempt(s) with ring time and SIP response.

Spot patterns:

• Repeated short ring times (e.g., 1–4 seconds) before failure: often a device decline (486) or instant voicemail.
• Same target always failing while others work: a target-specific issue (device DND, expired SIP registration, carrier call screening).
• Specific hour/day: schedule windows or buyer windows are excluding the target.
• Caller-state mismatches: leads from excluded states never attempt a given target.

Capture evidence before changing settings:

• Copy 3–5 failing Call IDs and 1–2 successful ones for comparison.
• Screenshot the route, target list, and the specific SIP responses.
• Note timestamps and caller ANIs.

Run a controlled test:

• Use a known-good mobile to place a call.
• Try the same flow to a “known-good” test destination (e.g., your own mobile or a spare line) to confirm the route is functioning.
• Compare a failing target attempt with a working target attempt taken seconds apart.

If you need a refresher on platform routing and outcomes, see the overview in cloud call forwarding.

Read SIP response codes to narrow the root cause

SIP responses tell you why a target didn’t answer. The code plus the observed ring time usually points to the fix.

Common SIP codes and what to do

• 180 Ringing / 183 Session Progress: The network is indicating ringing or early media. If it gets stuck here and then fails, check downstream target availability and whether a voicemail answered first.
• 200 OK: Answered. If agents report “no audio,” that’s a different path (device/network/media), but the ringing issue is solved.
• 486 Busy Here: The target is busy or declined (Do Not Disturb, call waiting off, or a manual reject). Action: Check DND/call waiting on the device/PBX. Include a backup destination later in the routing order so unanswered or declined calls continue.
• 480 Temporarily Unavailable: Device is offline or unreachable (unregistered SIP phone, phone out of coverage or airplane mode). Action: Verify SIP registration/network, mobile signal, and power settings. Make sure there’s another destination later in the order.
• 408 Request Timeout: No response from the target. Action: Check NAT/firewall for SIP endpoints, verify the phone can receive inbound, and test with a different carrier/device. Keep a backup destination in the order.
• 603 Declined: The callee refused the call (manual decline or policy). Action: Check whether the agent declined or if a local PBX rule rejected unknown callers. If you operate multiple CallFlow numbers, test with a different number to see if caller ID presentation affects treatment.
• 607 Unwanted: The callee or network marked the call unwanted/spam. Action: Review spam flags, blocklists, and caller ID reputation. If you manage multiple numbers, test with a different number to compare outcomes, and confirm consent/opt-in paths.

For deeper background on how 603/607/486 appear in spam/refusal scenarios and what to watch for, read SIP response codes and spam detection.

Reference table:

SIP code	Symptom you’ll see	Likely cause	Next step
180/183	Rings/early media then stops	Downstream timeout, voicemail answered elsewhere	Compare observed ring times; align how long calls are offered; check who answered
200 OK	Answered	N/A	If needed, review recordings/logs for quality
486 Busy Here	Rings once/briefly then fail or fast busy	DND, call waiting off, manual reject	Disable DND, enable call waiting; keep a backup later in the routing order
480 Temp Unavailable	Never rings at target	Device offline/unregistered; no coverage	Fix registration/signal; test alternate device; ensure a backup destination exists
408 Request Timeout	No response	NAT/firewall or network path issue	Check SIP keepalives/NAT; test different network; include a backup in the order
603 Declined	Immediate reject	Callee/PBX policy reject	Adjust local PBX rules; test with a different caller ID you control
607 Unwanted	Immediate reject	Marked as spam/unwanted	Review blocklists and caller ID reputation; test with another number you own

Routing rules that quietly stop ringing

Several rule types can prevent an attempt from ever reaching a target. The live log will show no target attempt, or it will skip a specific destination.

• Schedules/time-of-day windows: If a target is outside its window, it won’t ring. Verify time zones and overlapping windows across targets. A window that ends one minute before another starts will drop calls into a gap. Use a short “always-open” test window to confirm. For best practices, see schedule-based call routing.

• Geographic/caller-state filters: If you restrict a target to specific states, leads from excluded states won’t ring them. Confirm the rule and test with known ANIs from an allowed and a blocked state. Watch that “caller state: unknown” either matches or falls back as you expect.

• Priority and weighted routing: A target with weight 0 will never get traffic; a disabled target won’t be attempted. In round-robin, an offline member may still be in the rotation but fail every time. Check:

  • Priorities are ordered as intended.
  • Weights are nonzero for active targets.
  • Disabled targets are either removed or placed after active ones.
  • Round-robin members are healthy or excluded when offline.

• Simultaneous ring groups: One member’s voicemail can “steal” the call if it answers faster than humans. If a mobile voicemail picks up in ~20–25 seconds and another member needs longer to answer, the voicemail wins. Align how long calls are offered across the group so humans have time to answer before any voicemail.

• IVR menus and call queues: Mis-keyed DTMF mapping can route callers to a dead branch. If your queue wait is too short, callers may be sent to voicemail before agents can answer. Confirm:

  • Each IVR key goes where intended.
  • Queue wait time is long enough for targets to become available.

• Whisper messages: Whispers play to the agent after answer. They shouldn’t prevent ringing, but agents sometimes mistake a whisper for ringing audio. Confirm in the log you have a 200 OK before the whisper plays, and that the ring time precedes the answer.

Caps, queues, and voicemail races

Even with correct routing, counters and timing can quietly stop attempts.

• Daily/concurrent caps per target: If a target hits its daily or concurrent limit, new calls won’t ring that destination. Check counters and confirm your overflow route activates when caps are reached. If you need a refresher on configuring limits and overflows, see daily and concurrent call caps.

• Per-target call windows (buyer windows): Windows outside allowed hours behave like schedules: the platform will skip the target entirely. Confirm the buyer’s timezone and daily windows.

• Queue behavior: Review queue wait time. If your queue wait is too short, callers may be sent to voicemail before agents can answer. Increase the wait or route callers to the next destination or voicemail when appropriate for your workflow.

• Voicemail races: Mobile voicemail often answers somewhere around 20–25 seconds. If calls are only being offered for 15–20 seconds, humans may not have a chance to answer. If one mobile’s voicemail answers at ~22 seconds, it will often intercept group calls. Practical moves:

  • Standardize devices so their voicemail systems pick up on similar timings.
  • If one device consistently answers too fast, move it later in the routing order or put it on a separate route.
  • Watch observed ring duration in the logs and bias the order toward destinations where humans reliably answer first.

• “Calls drop after one ring” causes:

  • Device declines (SIP 486 Busy Here).
  • Carrier call screening or callee policy rejects (603 Declined).
  • Voicemail immediately connects on a device that is out of service or has conditional forwarding (may appear as 480/486 depending on network).
  • Correlate the SIP code and ring time: one short ring plus 486/603 is almost always a user/device-side action.

Target device and network checks

When the log shows the platform attempted the target and got a specific response, go straight to the device and environment.

Smartphones (iOS/Android):

• Do Not Disturb/Focus mode; “Silence Unknown Callers” (iOS) or similar filters.
• Call-blocking or spam apps intercepting calls.
• Conditional call forwarding active on the device that routes to voicemail or another number.
• Low signal or data saver modes limiting VoIP apps.
• Bluetooth audio routing to a headset in another room.
• Visual voicemail/voicemail system that answers quickly; adjust or extend the greeting pickup delay if your carrier allows it.

Desk phones/SIP endpoints:

• DND key lit; call waiting disabled.
• Registration status: unregistered due to wrong password/expired credentials.
• NAT/firewall changes blocking SIP or RTP; missing keepalives leading to one-way or no ring.
• STUN/ICE disabled when needed by your network; check the phone’s SIP account page.
• Ringer volume or profile accidentally muted.

Browser softphone:

• Agent signed out or inactive session.
• Browser tab not in focus (some browsers throttle background tabs); ensure notifications and sound permissions are granted.
• OS-level focus modes muting notifications or audio devices disconnected.

Buyer/operator PBX environment:

• Local PBX after-hours or holiday mode on.
• Concurrent call limit reached; additional calls rejected with 486.
• Local blacklists or anonymous-call rejection features.

Validate with a control:

• Temporarily forward the same route to a known-good test number you control.
• If the test number rings and answers with 200 OK, the route is sound; focus on the original target’s device/carrier.
• If neither rings, go back to routing, caps, and schedules.

Build a safe test plan and permanent safeguards

You’ll fix issues faster—and avoid breaking a working path—by testing in a narrow, controlled flow.

Step-by-step test flow:

1. Pick one affected business number.
2. Route it to a single known-good target (e.g., your test mobile) with no schedules, geo filters, caps, IVR, or queue. Keep call recording on if your policy allows; it aids correlation.
3. Place a test call while watching the live log. Confirm 180/183 then 200 OK.
4. Swap in the suspect target. Test again and compare SIP responses and ring time.

Add rules back gradually:

• Re-enable schedule windows and verify timezones; place a test call at the edge of the window.
• Re-enable geographic/caller-state filters; test with known ANIs from allowed and blocked states.
• Restore priority/weighted or round-robin rules; verify weights and that disabled targets stay disabled.
• Reapply caps; watch the counters tick and confirm overflow kicks in when limits are hit.

Set failover and overflow:

• Place a backup destination later in the routing order so unanswered or declined calls continue to the next target, then a queue, then voicemail as your policy dictates.
• Use simultaneous ring with a control number during diagnostics so you always have a human fallback while testing.
• For patterns and configuration ideas, see failover call forwarding.

Document and keep evidence:

• Save screenshots of the final, working configuration and note the observed ring duration per target in your logs.
• Keep a few successful Call IDs and a few known-bad Call IDs with timestamps and SIP codes. Future troubleshooting and support tickets will resolve faster.

When to escalate to support:

• You’ve reproduced the issue in a minimal flow and collected:
  • 3–5 Call IDs with timestamps (UTC), caller ANIs, and targets.
  • SIP responses observed and ring times.
  • Notes on device state (DND, registration status) and any local PBX rules.
• Include what you already tried. This avoids a reset of steps and gets you to deeper diagnostics quickly.

Practical wrap-up

Start with the log, not the handset. A live view of the route, target attempt, ring time, and SIP response will tell you whether you’re facing a routing rule, a cap/schedule block, a voicemail race, or a device refusing the call. Standardize offer durations, align group members, and keep a backup destination in the order so one target’s DND or poor coverage never kills your answer rate. If you’re new to CallFlow, you can create a number and run a controlled test route in minutes—no contracts, prepaid wallet, pay only for what you use. When you’re ready, sign up or contact us and we’ll help you run a safe test plan.