Diagnosing Call Issues with Call Doctor
Call Doctor is a self-service tool that reads a raw call debug log and explains, in plain language, what happened on a call and why. It covers the most common failure patterns automatically — no PBX expertise required to get a useful answer.
Introduction
Every call that passes through your PBX generates a detailed debug log: which trunk it came in on, how the dialplan routed it, whether the destination answered, and — if it failed — the exact cause. Reading that log directly takes PBX experience most people don’t have. Call Doctor parses it for you and returns:
- A plain-language summary of what happened
- Concrete next steps to check
- (For support staff) the technical evidence and full call timeline behind the diagnosis
Use case: A call failed or behaved unexpectedly and you need to know why — before opening a support ticket, or to triage one faster.
Step 1: Capture the call log
- In the RingQ web app, go to Settings > Global.
- Open Call Debug and enable Debug Mode. This clears the current call log and starts a fresh one, so the log you export only contains the call you’re about to reproduce.
- Reproduce the call (place or receive it again) while Debug Mode is on.
- Export the resulting call log, or open the Call Flow Report for that call and copy its raw log text.
ℹ If the issue is intermittent or hard to reproduce, capture Debug Mode continuously during a support window instead of a single attempt, then pull the log covering the affected time range.
Step 2: Open Call Doctor
Go to calldoctor.
You’ll see a single input area — you can either:
- Paste the raw log text directly, or
- Drag and drop the .log/.txt file, or click browse to select it
Two sample buttons (Load failed-call sample / Load successful-call sample) let you try the tool immediately without a log of your own.
Step 3: Choose Customer view or Support view
At the top right, toggle between:
- Customer view — a plain-language summary and a short list of things to check. Safe to share directly with an end customer.
- Support view — adds the technical timeline, the raw evidence Call Doctor based its diagnosis on, and which analysis path produced the answer (rule-based or AI-assisted).
Step 4: Click Analyze call
Call Doctor returns a diagnosis card with a severity badge:
| Badge | Meaning |
|---|---|
| ✅ Healthy call | Call connected and completed normally — no action needed |
| ⚠ Needs attention | Call completed, but something unusual happened (e.g. cancelled early, forwarded to voicemail) |
| 🛑 Problem found | Call failed to connect — a specific cause was identified |
| ℹ Info | No specific issue matched; a general note or AI-assisted best guess is shown instead |
Below the badge, you’ll see:
- What to check (Customer view) or Suggested steps (Support view) — an ordered list of concrete things to verify
- A Call summary panel: from/to numbers, routed destination, domain, start time, and duration
- Other observations from this log (collapsed by default) — secondary findings worth a glance, like background auth attempts unrelated to this specific call
- In Support view only, a Technical timeline — every call event in order (new channel, dialplan match, ringing, answer, hangup, etc.) with timestamps
What Call Doctor already knows how to diagnose
The rule engine recognizes patterns including:
- ACL/firewall blocking a trunk or provider
- No route to the dialed destination
- Codec mismatch between legs
- A call that rang briefly then was cancelled — commonly a forward-to-voicemail or short ring-group timeout
- Normal answered-and-bridged calls
- Auth failures, gateway registration issues, and RTP/media problems scoped to the specific call (so unrelated background traffic in the same log dump doesn’t produce a false diagnosis)
If a log doesn’t match any known pattern, Call Doctor still returns a best-effort AI-assisted read rather than leaving you with nothing — this is flagged clearly in Support view under “Analysis source.”
Tips
💡 If you’re unsure whether a call log actually contains the call in question, check the Call summary panel first — the from/to numbers and start time should match what you expect.
⚠ Call logs can contain other calls’ data if Debug Mode was left on for a while. Call Doctor scopes its checks to the call it identifies as primary, but if a diagnosis looks off, re-capture a log scoped to just the one call.
When to escalate
Call Doctor’s suggested steps are a starting point, not a substitute for support when:
- The suggested steps don’t resolve the issue
- The diagnosis severity is “Info” (no confident match) and the problem is high-stakes or recurring
- Multiple calls show the same failure pattern (may indicate a systemic issue, not a one-off)
When escalating, switch to Support view and share the full page (or the technical timeline + support detail) with your support contact — it gives them the same evidence Call Doctor used, so they don’t have to re-derive it from the raw log.