Use RTCP loss and jitter as transport evidence, not image proof

Bottom line: packet loss and jitter are valuable clues about media delivery, but a healthy-looking RTCP report does not establish focus, exposure, subject detail, archive continuity, or investigative usability. Network and video evidence should be evaluated together.

Source fact: RTP and RTCP expose delivery information without guaranteeing service

RFC 3550 specifies the Real-time Transport Protocol and its control protocol. RTP carries information such as sequence numbers and timestamps. RTCP reception reports include fields for packet-loss information and interarrival jitter. The RFC also makes clear that RTP itself does not reserve resources or guarantee quality of service.

Sequence gaps can indicate missing packets, and changes in arrival timing can help identify unstable delivery. Their operational meaning still depends on where the report was generated, which stream and synchronization source it covers, how the receiver handled loss, and whether the VMS recorded the decoded result.

Source boundary and applicability

RFC 3550 defines protocol behavior; it does not require every camera or VMS to expose RTCP data to operators, prescribe an acceptable loss or jitter threshold, or measure visual task performance. Intermediaries, multicast, retransmission, buffering, transport choice, and implementation details can make observations at two endpoints differ.

Applicability questions

• Which exact camera stream, RTP session, synchronization source, and receiver generated the report?
• Are reports available at the camera, recorder, client, network sensor, or more than one point?
• Does the transport use UDP, TCP interleaving, multicast, or another recovery mechanism?
• What packet loss can the codec conceal, and what loss creates visible or evidentiary damage?
• Can metrics be aligned to the recorded clip using trustworthy time sources?

DSE recommendation: correlate transport telemetry with native recordings

The following steps are DSE recommendations based on the cited source.

Record the monitored endpoint, stream identity, transport, report interval, and field definitions before creating alerts. Establish a normal baseline and stage a controlled impairment in a lab or approved maintenance window. Compare sequence behavior, reported loss, jitter, recorder events, and the native archived clip over the same timestamped interval.

Set operational thresholds from observed task impact and supported vendor behavior, not a borrowed universal percentage. Use RTCP to narrow diagnosis among camera, path, receiver, or congestion conditions. Keep separate acceptance tests for image detail, frame cadence, audio synchronization, and search or export completeness.

Verification and evidence

Retain the RTP/RTCP field mapping, endpoint and stream inventory, time-source record, baseline and impaired telemetry, packet capture where authorized, native clip, recorder logs, visible-impact assessment, and alert-delivery test. Sanitize captures because signaling and media can contain sensitive information.

Official references

• RFC 3550 – RTP: A Transport Protocol for Real-Time Applications – RFC Editor