Summary

  • RFC 3611 turned RTCP reporting into an extensible set of typed evidence blocks, but the reporter, measured source, interval, measurement point, thinning rule and unavailable-value convention remain part of every claim.
  • More detailed feedback can improve diagnosis while increasing RTCP cost and confidentiality exposure. An omitted block is not zero, a receiver discard is not network loss, and a quality estimate is not direct proof of human experience.

A thick dossier can still have one witness

Suppose a service review receives an impressive packet of evidence. It includes loss runs, duplicate runs, packet receipt times, a round-trip calculation, jitter, signal level, a quality score and the settings of a de-jitter buffer. The natural reaction is to treat the dossier as the call itself reconstructed in data. RFC 3611 supports no such leap. It defines a way for an RTP participant to send extended reports, not a neutral observer that stands outside the system being measured.

The distinction begins in the wire format. An XR packet carries the SSRC of its originator and may carry zero or more report blocks. Several blocks separately name the SSRC of the source being measured. The witness and the subject are therefore two fields, not one. A receiver can report what it observed about a sender; an intermediary or reporting source can have another role; later reporting-group work makes those roles even more explicit. If a monitoring system retains the metric but drops the reporter identity, it destroys the chain of testimony at ingestion.

RFC 3611 was published on the Standards Track in November 2003. It assigned RTCP packet type 207 and initially defined seven block types: Loss RLE, Duplicate RLE, Packet Receipt Times, Receiver Reference Time, DLRR, Statistics Summary and VoIP Metrics. The framework was deliberately extensible. Type and length fields let a recipient step past a block it does not understand. That compatibility rule has an evidentiary consequence: “not decoded here” is not “measured as zero”. Nor is an XR packet with no relevant block proof that nothing happened.

IANA's registry now contains many later block types. The registry proves that a format has an assignment and a specification. It does not prove that two endpoints negotiated it, implemented it, emitted it or interpreted it with the same corrected rules. Even the original document has verified errata: the receiver-RTT parameter name, the optional SDP colon and a burst-density example all required correction. Protocol history belongs in the evidence version.

The window is part of the number

Loss RLE and Packet Receipt Times reports carry a measured source and sequence bounds. Their apparent detail can still be reduced by thinning, which systematically samples observations to keep a report within a size limit. A run-length trace may therefore be faithful to its declared thinning rule while being incomplete as a packet ledger. A graph that silently expands thinned data into a continuous history invents packets the report never described.

Summary values have a similar boundary. Is the count from the latest reporting interval, from the beginning of the session, or from another signalled period? Is jitter a sample taken at the end of an interval, or a statistic over the whole interval? RFC 6776 later supplied a Measurement Information block with first-session sequence, interval sequence bounds and durations. RFC 6792 distinguished interval, cumulative and sampled metrics. Those refinements do not add decorative metadata; they say what mathematical object the number is.

Two values with the same name can disagree without conflict if their windows differ. Two values can agree and still describe different incidents. RFC 8861 warns that receiving XR and ordinary RTCP blocks in different compound packets reduces their value when the measurement intervals are not synchronized. A dashboard timestamped at ingestion time can make asynchronous reports look simultaneous. The correct comparison key is the measured window, not the moment a collector wrote the row.

Reference-time blocks show why field names are insufficient. Receiver Reference Time and DLRR form a collaborative exchange that permits a participant to calculate round-trip time. DLRR is the delay since a previously received reference-time report. It is not a one-way path delay, a universal clock comparison or proof that media followed the same path. The result depends on the paired exchange and its identities.

Arrival and usefulness are different verdicts

RFC 3611's VoIP Metrics block draws a line that operational scorecards often blur. A lost packet did not arrive. A discarded packet may have arrived and then become unusable because it was too early, too late or outside the receiver's de-jitter-buffer policy. The network and the endpoint can therefore produce different evidence about the same sequence space.

That line changes accountability. Rising discard with stable transport loss can point toward delay variation, buffer adaptation, device load or receiver policy. Rising network loss calls for a different investigation. Neither pattern alone proves what a user heard: concealment, codec behavior, redundancy, frame boundaries and application state can alter the media outcome. RFC 6792 later separated transport-level, end-system and application-level metrics for exactly this reason. A human-quality claim needs an outcome receipt beyond transport telemetry.

Burst and gap metrics are also classifications, not raw reality. Gmin defines the threshold that separates a gap from a burst. RFC 3611 recommends 16 and requires the supplied value to remain nonzero and constant across the session. Change the threshold and the same event sequence can acquire a different summary. A burst-density chart without Gmin, the applicable errata and the interval boundary is a result without its method.

Estimated R factors and MOS values carry further caveats. Some are not defined for every application topology; multicast conversational metrics should be marked unavailable. Many fields use 127 as an unavailable sentinel, while other fields have different ranges or reserved meanings. Converting 127 into an alarming score, a successful score or a missing database default would turn a deliberate state into fabricated measurement. “Unavailable”, “not requested”, “unknown block” and “zero” require separate storage values.

Detail consumes bandwidth and privacy

XR did not repeal RTCP's bandwidth discipline. Extended blocks count toward RTCP traffic. Larger average reports can lengthen the average reporting interval. Applications may cap block size, thin packet observations, select which receivers report and reduce how often they do so. The desire for finer evidence changes the cadence and composition of the evidence channel itself.

This makes reporting policy part of service design. A receiver chosen not to report is not a receiver with perfect quality. A long reporting interval can smooth a short failure. A size cap can preserve a beginning and omit later events, depending on the block rule. Operators should publish the selection and truncation policy alongside the results, particularly when comparing populations or suppliers.

The security section is unusually direct: XR introduces heightened confidentiality concerns because its data are more extensive and more detailed than ordinary RTCP summaries. Packet-level traces can help infer multicast topology. VoIP metrics can expose information about a person or their environment. Encryption and filtering can protect that information, but the RFC notes that they cause loss of monitoring information. A blank dashboard after a privacy change may therefore be evidence that visibility was deliberately reduced, not evidence that quality improved.

The right response is not maximal collection. It is purpose-limited collection with explicit readers, retention and disclosure classes. An operator may legitimately expose aggregate service evidence to one audience and keep packet-level detail inside a narrower incident boundary. What it must not do is convert withheld detail into a claim that no event occurred.

Preserve the report as a bounded claim

A defensible XR record can be small. It names the reporter and measured stream, correlates the session, states the block type and corrected specification version, records interval or cumulative scope, sequence bounds, units, clock, payload context, measurement point, thinning and sentinel interpretation. It notes which requested blocks were absent, which were unknown to the collector, and which were filtered. It then links—without merging—the transport observation, receiver action, decode/playout result and user evidence.

That structure follows a minimum-interoperable principle. Systems can exchange a modest common contract without forcing every endpoint to disclose all local state. Richer local evidence remains possible, but its authority stays attached to the implementation that produced it. Running code creates the observation; a standardized block makes the observation portable; neither grants the collector permission to erase uncertainty.

The achievement of RFC 3611 was not that it created one final score for media truth. It created room for several precise witnesses. The operational failure begins when a platform takes those witnesses out of their windows, collapses their identities and presents their estimates as a verdict. More detail deserves more provenance, not less.

Sources