Asterisk RTCP statistics: channel, direction and call-quality evidence

Bind every statistic to one surviving PJSIP channel

Asterisk 22 documents CHANNEL(rtcp,statistic,media_type) under the PJSIP channel technology. The value belongs to the channel on which the function is evaluated; it is not automatically the peer channel, bridge, linked call or customer conversation. Record channel name, unique ID, linked ID, endpoint, bridge membership and evaluation time with every result.

An empty value can mean the requested item is unavailable on that channel, not that the network had zero loss or jitter. Keep an absent value, a numeric zero and a completed summary as different states.

Choose the stream and field deliberately

The function defaults to audio when media type is omitted and can also target video. Individual fields include transmitted and received packet counts, jitter, loss, round-trip time and synchronization-source identifiers. Summary selectors return semicolon-delimited groups rather than a stable business record.

Persist the requested media type and field names alongside the values. Do not compare an audio result with a video incident, a current counter with a final summary or an SSRC from a later stream without preserving the transition.

Keep local observations and remote reports separate

Asterisk distinguishes statistics it derives from the RTP stream it receives from values the remote endpoint reports in RTCP sender or receiver reports. The MES implementation describes local values as Asterisk observations of incoming media and remote values as evidence about outgoing media derived from the peer reports.

Remote values depend on the peer sending RTCP and calculating its statistics. Missing, delayed or differently calculated reports are not proof that the outgoing stream was clean, while a local received-stream result does not describe what the other endpoint received.

Treat MES as a network-derived score, not MOS

Asterisk calls the value Media Experience Score because a true Mean Opinion Score depends on human perception. MES combines round-trip time, jitter and packet loss; it does not inspect speech content, intelligibility, echo, clipping, gain, acoustic coupling, device behavior or user judgement.

Use txmes, rxmes and their local or remote summaries only with their documented direction and evidence source. A favorable score does not prove acceptable audio, and an unfavorable score does not identify the link, device or queue that produced the impairment.

Map bridge technology before interpreting coverage

Asterisk bridge documentation distinguishes core, native local and remote native media paths. In a remote native bridge, often called direct media for SIP, packets flow between devices outside Asterisk. Asterisk can then retain call state without observing the complete media stream needed for a PBX-side quality conclusion.

Record initial and final SDP, re-INVITEs or UPDATEs, direct-media policy and actual packet path. A pre-bridge counter, one leg with media or a signaling-complete call does not prove that Asterisk measured the conversation after topology changed.

Correlate stats with packets and an authorized listening test

Preserve the same call segment across channel statistics, bounded packet evidence, endpoint counters, network telemetry and the reported audible symptom. Align timestamps and directions before comparing values. Packet capture loss, endpoint receive loss and Asterisk channel loss are different observations.

Correct the earliest demonstrated mismatch and repeat the same authorized route and media pattern. Remove temporary logging and captures, protect identifiers and media, and retain only approved measurements. This guide is documentation-derived; no PBX, channel, stream, packet or call was tested.

Capture RTP context beside RTCP statistics

Use the PJSIP RTP context guide to bind RTCP counters to the same channel leg, audio or video stream, bridge phase and address interval.