A real-time call quality monitoring platform is the nervous system of a modern voice or video product. It watches every packet, every jitter buffer, every codec switch on every device — then compresses that torrent of low-level telemetry into a single, honest answer to one question: “How does the call sound and look, right now, to this human being?” It then rolls those answers up to rooms, meetings, tenants, ISPs, regions and continents, so the platform can react to a bad-weather day on the internet in seconds rather than after the next quarterly review.

Underneath the friendly “Excellent / Good / Poor” badge on the caller’s screen there is a full-blown streaming data platform: a client SDK that samples WebRTC and native stack metrics, a hardened edge that authenticates and rate-limits millions of writers, a durable event backbone, stateful stream-processing jobs that compute MOS, freeze rate, glitch counts and packet-loss bursts on the fly, a time-series and columnar analytics store, an anomaly detection layer, an alerting fabric, and a set of dashboards and APIs that operators, on-call engineers, ML models and customer support all lean on.

Before touching any wire diagram, we need a precise picture of what this system does — and, just as importantly, what it does not. The word “monitoring” is overloaded in this industry, so let us pin down the exact contract this platform is signing with the rest of the product.

2.1 A Working Definition

A real-time call quality monitoring platform is a distributed system that, given a live communication session (audio, video, screen share, streaming) and the endpoints participating in it, guarantees:

• every endpoint’s network, media and device telemetry is captured, normalised and made durable within perceptual real-time,
• an objective and subjective quality score is computed continuously for every participant, every stream and every leg,
• anomalies at any granularity — call, room, tenant, ISP, region, build, codec — are detected and correlated within seconds,
• every score, event and alert is queryable and joinable to business context (customer, plan, region, meeting type) for as long as the business needs it,
• none of this monitoring itself degrades the very calls it is watching.

2.2 What It Is Not

Any product that ships audio or video is one bad packet-loss burst away from an angry tweet. Real-time monitoring is what turns a fragile media pipeline into a business that can promise, and honour, a five-nines conversation experience.

A monitoring platform is only ever as good as the signals it collects. This chapter walks through the three layers of telemetry every serious call platform gathers and shows how they combine into a single perceptual score.

4.1 Transport Layer

These are the raw, unavoidable physics of the internet — sampled directly from the WebRTC/ICE stack or the native SIP/RTP engine every second.

4.2 Media Layer

Above the transport, we care about what the codec is actually producing and what the decoder is actually reconstructing.

4.3 Device & UX Layer

Even a perfect network cannot rescue a call where the microphone is muted at the driver level or the CPU is pinned by a background scan.

• CPU %, thermal state, battery level, power mode.
• Camera / microphone permission state, hardware id, sample rate.
• Join success, join latency, in-call errors, user-submitted post-call rating.

With the signals defined, we can sketch the physical components that carry them from the microphone in someone’s living room to a graph on an engineer’s screen in another hemisphere.

The ingestion pipeline is where most call-monitoring projects live or die. It has to accept a firehose of writes, tolerate arbitrary network weather, avoid double-counting, and stay cheap. This chapter breaks down the moving parts.

6.1 The Client Contract

The SDK is not a naive HTTP poster. It is a small, resilient distributed system in itself:

• Sampling ladder. Non-critical metrics are sampled at 0.1–1 Hz; critical events (join, leave, disconnect, codec switch) are sent immediately.
• Batch & compress. Events are grouped into 1–5 s batches, protobuf-encoded and gzipped before shipping.
• Local ring buffer. If the network is unreachable, the SDK spills to an in-memory or on-disk ring so the last few minutes of pre-crash telemetry survive.
• Idempotency keys. Every batch carries a monotonic sequence per session so the server can safely de-dup on retry.

6.2 The Edge

The edge fleet is a stateless, horizontally-scaled service behind an anycast IP.

6.3 The Bus and the Windows

Downstream of the bus, stream jobs run on the same partitions. Windows are almost always “event-time” with a small allowed lateness, so a mobile client whose radio spent 20 seconds re-connecting still contributes its telemetry to the correct minute.

Once telemetry is flowing, the platform has to answer three questions in real time: is any call bad, is any cohort of calls bad, and is anyone experiencing that badness who deserves to be alerted? Each question is a different detector.

7.1 Per-Call Scoring

The per-call score is a function of transport, media and UX signals combined over a rolling window. A typical, opinionated formula:

call_score = w1 · MOS_audio
           + w2 · f_video_freeze
           + w3 · f_video_framerate
           + w4 · f_screen_legibility
           - p_join_failure
           - p_disconnect

Weights are learnt from post-call user ratings and validated against controlled experiments. The output is bucketed into Excellent / Good / Fair / Poor so humans can reason about it without staring at a decimal.

7.2 Cohort Detection

Aggregating per-call scores by tenant, region, ISP, client build, OS version and codec turns individual bad calls into incidents. A simple z-score against a 28-day baseline catches most real regressions; a Bayesian change-point detector catches the subtler ones.

7.3 Alert Fabric

Alerts are only useful if they wake the right human. The fabric routes each incident along three axes:

• Ownership. Client bug → mobile team; media routing → SFU team; ISP-scoped → network relations.
• Severity. Sev-1 pages instantly; Sev-3 lands quietly in a triage queue.
• Suppression. Duplicate alerts, planned maintenance windows and known-flapping cohorts are collapsed.

Nothing crystallises an architecture like following a single event through it. Let us walk one bad call — a laptop in Berlin joins a Meet call with a Bangalore host, hits a bad Wi-Fi patch three minutes in, recovers, and rates the call two stars — from tap to on-call escalation.

A monitoring platform lives and dies by its non-functional properties. The functional feature list is short; the guarantees are where the engineering happens.

There are a handful of failure modes that every team building this platform meets, usually in year two, and the fix is never a heroic rewrite — it is a small, boring decision made early.

A call-quality platform is never “done”. Its architecture changes shape as the product grows, and the good news is that the evolution is fairly predictable.

If you remember only a handful of things from this walkthrough, remember these — they are the ones that separate a monitoring platform that scales from one that quietly bankrupts a team.

A well-built call-quality monitoring platform is invisible when everything works and priceless the moment something breaks. Build it as if you will one day have to defend every field, every alert and every dashboard to an executive, an auditor and a very tired on-call engineer — because eventually, you will.