Observability Overview

You can see everything a call does, in real time and after it hangs up. TeleQuick Voice records each call’s signalling, media quality, and agent behaviour as it happens, then folds it into durable records you can query, chart, and alert on — without you running a metrics pipeline. Every view keys off the same identifier: a call’s sid. The live-ops row, the per-segment trace, the one-row CDR, the quality score, and the traffic tally all hang off that one key, so you can pivot from “what’s ringing right now” to “why did this specific call sound bad” without stitching IDs across systems.

​

What you can see

​

Live call state

While calls are in flight, the engine streams state transitions — initiated, ringing, answered, held, resumed, transferred, cleared — to your operations screens as they happen. Because updates are pushed over the same low-latency transport the media rides, a wallboard reflects the floor within a tick rather than on a polling interval. Each live row tells you the sid, the legs attached (a PSTN caller, a SIP deskphone, a browser softphone, an AI agent), the current state, and — once an AI segment exists — that the call is being handled by an agent. This is the same event stream that later becomes the per-segment trace, so what you watch live and what you query afterwards never disagree.

​

Per-segment traces vs. one-row CDRs

These are two different grains of the same call, and you’ll reach for each in different situations. A call trace captures every lifecycle transition folded per sid. When a call is transferred from an AI agent to a human, the trace shows two segments — the AI leg and the human leg — each with its own timings, so you can see how long the caller spent with the bot before the warm handoff and how the human leg went. This is what powers agent timelines, wrap-up-to-ready analysis, and VDN flow reports. A CDR is the single settled row written when a call clears: start / answer / clear timestamps, total duration, the Q.850 clear reason mapped to a status, the negotiated codec, and the agent handler (if any). It’s the record you export for billing and long-horizon reporting. Both are derived from the same lifecycle events, so a CDR and its trace always tell the same story at their two grains — see Call lifecycle for the transitions they’re built from.

​

Quality: MOS, jitter, and loss

For every call’s media leg, the media plane continuously measures packet loss and jitter and scores an estimated MOS using the ITU-T G.107 E-model. That score lands alongside the call’s other records, so “sort my calls by worst audio quality” is a first-class query, not a forensic exercise. Because the score is computed from the same loss and jitter counters the media plane already tracks per call, it costs nothing extra at call time and is available the moment the call clears. Reading and acting on these numbers is covered in MOS, jitter & packet loss.

​

Per-tenant traffic

The engine attributes bytes and bandwidth to the workspace that generated them, broken down by modality, with voice media counted per-tenant per-call. This rolls up into a Traffic & Bandwidth view so you can answer “which workspace is driving the load right now” and “how has this tenant’s voice traffic trended” from one place. It’s the load-and-cost lens over the same fleet the CDRs describe.

​

Dashboards

Sitting on top of live state, traces, CDRs, quality, and traffic are prebuilt production dashboards: all-calls and call-detail reports, live wallboards, agent timelines, VDN-flow and skill-drill views, and the traffic board. Which ones to watch — and which are polished vs. still filling in — is covered in Production dashboards.

​

When the summary isn’t enough

The records above tell you what happened. When you need to know why — a call that sounds wrong, a transfer that never connected, an agent that talks over the caller — drop down a level:

​

Related