Finds calls where somebody could not hear properly, so a customer can be contacted before they contact us. The analysis is computed from the per-leg RTP counters the PBX writes to PbxCDR.rtpStats. Counters are captured when a bridge tears down and, since 02-09-2026, also at the end of a call that never had a bridge - an IVR, an announcement, voicemail - which produces a single caller leg.

With no access level left to branch on, scope is simply:

Every leg, direction and call carries one of five verdicts. severity is their numeric rank and exists for sorting only - it should never be displayed.

Findings are machine-readable codes plus the measured values behind them - never prose, so the caller can phrase them in the users own language. A healthy call has an empty findings array; “outbound was not measured” is carried by that directions own measured/reason fields and is not a finding.

The bridge is an Asterisk softmix bridge, which writes a frame to every participant on a fixed timer regardless of what anybody contributes - and keeps sending even into a dead address. That makes outbound.packets useless as a quality signal but excellent as a reference: it says what a full-rate stream looks like for this particular leg, whatever its packetisation.

deliveryRatio = inbound.packets / outbound.packets

Healthy legs sit at about 1.0. A phone sending every second frame lands near 0.5. Dead audio is 0. The ratio is independent of packetisation (both 50 pps and 33 pps legs are healthy at ~1.0) and is unaffected by whether the counters were read live or sampled.

Two guards apply: the ratio is only graded on legs with at least 30 seconds of media, and a ratio above 1.1 means the reference itself is unreliable (the leg was not fully bridged for part of its life), in which case loss, jitter and MES decide instead.

inbound and outbound are named from the PBXs point of view, per leg. For a leg whose party is a customers desk phone, inbound is that phones microphone reaching us and outbound is what we sent to that phones speaker.

Each leg carries a party object describing who was on it. Identity comes from the CDRs own caller and callee sections, never from the device on the leg.

phoneInfo is still used for one identity purpose: telling several callee legs apart on a transfer or a group call, where the single callee section cannot describe three legs. Each such leg then falls back to the extension it rang.

Note that a callee leg identifies the extension that was called, not the individual handset that answered it. An extension ringing three phones produces one leg named by extension.

Because parties are named from the CDR, everything that returns them applies the same privacy rules as CDR first - a suppressed number stays suppressed here too.

• The counters describe the PBX-to-party hop only. A problem inside the customers LAN, or beyond the carriers edge, shows up as bad inbound quality here but cannot be localised from this data.
• inbound.lost is cumulative as of the last RTCP report Asterisk generated, so it lags the very end of a call slightly. Use it as a ratio, not an exact count.
• rtt is frequently 0 because it needs usable RTCP timestamps from the far end, and is occasionally wild (65535 s has been observed). Values above 5 s are treated as unknown rather than as a catastrophic finding.
• Recurring problems are only visible by aggregating - see Summary.