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

1. In the RingQ web app, go to Settings > Global.
2. 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.
3. Reproduce the call (place or receive it again) while Debug Mode is on.
4. 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:

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.