# Use RTCP loss and jitter as transport evidence, not image proof > RTP control reports can expose packet loss and interarrival jitter. They help diagnose delivery but do not prove that recorded video is complete or usable for the intended task. - Canonical URL: https://update.dsesecurity.com/updates/use-rtcp-loss-and-jitter-as-transport-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:36:05+00:00 - Modified: 2026-08-25T21:36:17+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Explainer - DSE priority: Advisory - Topics: Networks & Infrastructure, Video Surveillance - Reading time: 2 minutes ## What you need to know RTP control reports can expose packet loss and interarrival jitter. They help diagnose delivery but do not prove that recorded video is complete or usable for the intended task. ## Potentially affected IP video systems using RTP and RTCP between cameras, media services, gateways, clients, or recorders. ## DSE recommendation Collect RTCP metrics at defined endpoints, correlate them with timestamps and recorded clips, and avoid treating a transport statistic as an image-quality acceptance result. ## Article 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](https://www.rfc-editor.org/info/rfc3550/) 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](https://www.rfc-editor.org/info/rfc3550/) – RFC Editor ## Primary reference - Name: RFC 3550 - RTP: A Transport Protocol for Real-Time Applications - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/info/rfc3550/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Use RTCP loss and jitter as transport evidence, not image proof,” DSE Security, https://update.dsesecurity.com/updates/use-rtcp-loss-and-jitter-as-transport-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.