ONVIF vs RTSP vs RTP: Differences, Ports, Security

Updated October 2026: ONVIF is retiring Profile S in favor of Profile T, ONVIF Streaming 26.06 adds SRTP, and ONVIF Profile V brings WebRTC to cloud cameras; new sections on ports and securing RTSP/RTP.

ONVIF vs RTSP vs RTP: the short answer

ONVIF and RTSP are not alternatives: ONVIF finds and configures the camera, RTSP starts and stops its video stream, and RTP carries the video itself. When a VMS adds a camera "over ONVIF," it uses ONVIF to discover the device and ask for its stream address, and the camera answers with an RTSP address. The video then flows as RTP packets, with RTCP reporting on delivery quality alongside.

RTSP vs RTP: RTSP (Real-Time Streaming Protocol, IETF RFC 2326 and RFC 7826) is the control channel — it sends commands such as DESCRIBE, SETUP, PLAY and TEARDOWN on TCP port 554. RTP (Real-time Transport Protocol, IETF RFC 3550) is the transport — it moves the compressed video in packets that each carry a sequence number and a timestamp. Neither one replaces the other; a camera stream uses both.

Which is better, ONVIF or RTSP? For a multi-brand system, add cameras through ONVIF: you get discovery, configuration, PTZ and events, and the video still arrives over RTSP/RTP. Add a camera by its raw RTSP address only when the camera has no ONVIF support or you just need the picture.

At a glance: ONVIF vs RTSP vs RTP, as of October 2026. Ports are the standard defaults (RFC 2326, RFC 7826 §4.2, WS-Discovery); a camera maker can change them.

Why this matters

If you are scoping or running a surveillance system, "ONVIF vs RTSP" sounds like a choice you have to make — and it is not; they are different jobs that run together, and getting that wrong is the root of a surprising number of failures. A stream that plays perfectly on the test bench can stutter or vanish the moment it crosses a firewall, a router, or a VPN, and the reason is almost always a transport decision nobody made on purpose. Understanding the four protocols — what each one does, what it cannot do, and where it breaks — lets you read a camera datasheet without guessing, ask a vendor the right questions, and predict the bandwidth and latency a design will actually deliver. You will not write a line of networking code; you will gain the mental model that separates a system that survives a bad network day from one that only demos well. This is the layer beneath the ingest overview — the wire itself, in detail.

ONVIF vs RTSP vs RTP: who does what

Start by clearing up the question almost every buyer asks: "should I add this camera over ONVIF or over RTSP?" The honest answer is that the two are not competitors — they are different stages of the same conversation, and a typical system uses both at once. Confusing them is like asking whether you should reach a colleague "by phone or by talking" — one is the connection, the other is what travels over it.

Four named technologies move a camera's video into the recording software, and each has exactly one job. The software that ingests and records many camera streams is called a Video Management System (VMS); everything below describes how a camera's video reaches it.

ONVIF is the concierge. ONVIF — the Open Network Video Interface Forum standard — lets cameras and software from different makers understand each other. Its job here is to find the camera on the network and hand over the address of its video stream. ONVIF does not carry a single frame of video. When you "add a camera as ONVIF," the VMS uses ONVIF to discover the device, authenticate, and ask, "what is the address of your stream?" — and the camera answers with an RTSP address. (The full ONVIF story is in ONVIF explained for engineers; for the commercial overview, see Fora Soft's guide to ONVIF profiles in security systems.)

RTSP is the remote control. Once the VMS has that stream address, it connects with the Real-Time Streaming Protocol and presses buttons: describe yourself, set up the stream, play, stop. RTSP carries the commands, not the pictures. When you "add a camera as RTSP," you skip the ONVIF concierge and type the stream address by hand — which is why RTSP-only setups work but lose ONVIF's discovery, events, and configuration.

RTP is the moving van. The Real-Time Transport Protocol is what actually carries the compressed video across the network, one packet at a time. Everything you see on screen arrived as RTP.

RTCP is the delivery clipboard. The RTP Control Protocol rides alongside RTP, carrying no video — just short reports, in both directions, on how delivery is going: how many packets arrived, how many were lost, how jittery the timing was.

Table 1. The division of labor. "ONVIF vs RTSP" is a false choice — ONVIF sets up the call, RTSP controls it, and RTP carries it. Only RTP moves video.

Figure 1. The four protocols as a relay, not a contest. ONVIF discovers the camera and hands over the stream address; RTSP starts and stops the session; RTP carries the actual compressed video; RTCP reports on delivery quality. Only RTP moves pictures.

RTSP: the remote control

RTSP is best understood through the standard's own words: "RTSP acts as a 'network remote control' for multimedia servers" (IETF RFC 2326, §1.1). It does not move video; it presses buttons on the camera, and the camera responds. It listens on a well-known door, TCP port 554 (RFC 2326, §3.2).

The buttons are a short, named set. Four are required of any RTSP system — OPTIONS, SETUP, PLAY, and TEARDOWN — and two more are in near-universal use, DESCRIBE and PAUSE (RFC 2326, §10). Walk the sequence the way a VMS does it. OPTIONS asks which commands the camera supports. DESCRIBE asks the camera to describe what it offers, and the camera answers with a small text document — a Session Description Protocol (SDP) block — that lists the available streams and, crucially, the codec each one uses. SETUP negotiates how the video will travel (the transport decision, below). PLAY starts the flow. TEARDOWN closes the session cleanly.

One property of RTSP trips up engineers who expect it to behave like a web request: RTSP is stateful. A normal web page is stateless — each request stands alone. RTSP is the opposite: "An RTSP server needs to maintain state by default in almost all cases, as opposed to the stateless nature of HTTP" (RFC 2326, §1.1). The camera remembers, between commands, that it set up a session and is now playing it; it tracks each session through states the standard names INIT, READY, and PLAYING. That memory is why a half-closed RTSP session can leave a camera holding resources, and why a well-built VMS always issues a TEARDOWN rather than just dropping the connection.

A modern note on versions: RTSP 2.0 was published as IETF RFC 7826 in December 2016 and formally obsoletes the 1998 RFC 2326. In practice, the overwhelming majority of cameras in the field still speak RTSP 1.0, so a VMS that ingests real-world hardware is built against RFC 2326 first and treats 2.0 as the exception. The two versions do not mix: RTSP 2.0 "is not backwards compatible other than in the basic version negotiation mechanism" (RFC 7826, §1). Version 2.0 also drops UDP for the commands themselves — it requires TCP or TLS over TCP — and fixes the secure variant, RTSPS, on TCP port 322 (RFC 7826, §2 and §4.2). The protocol's internals — the full grammar, the proxy behavior, the interaction with general streaming infrastructure — belong to the streaming discipline; our Video Streaming section covers the transport theory in depth, while this article keeps the surveillance framing.

RTP: what is actually inside the moving van

When PLAY starts the flow, the video crosses the network as a stream of RTP packets. RTP is defined in IETF RFC 3550, an Internet Standard, and the useful thing to understand is what each packet carries besides the video itself, because those few extra bytes are what make live video survive an imperfect network.

Every RTP packet begins with a fixed 12-byte header (RFC 3550, §5.1). Most of it is bookkeeping, but three fields do the heavy lifting, and each maps directly to a real surveillance problem.

The sequence number is a 16-bit counter that "increments by one for each RTP data packet sent, and may be used by the receiver to detect packet loss and to restore packet sequence" (RFC 3550, §5.1). This is how the VMS knows a packet went missing (a gap in the count) and how it reassembles packets that arrive out of order — both routine events on a busy network.

The timestamp is a 32-bit field that "reflects the sampling instant of the first octet in the RTP data packet" (RFC 3550, §5.1). It is the clock that keeps motion smooth and keeps audio aligned with video. Without it, frames would play at the speed they happened to arrive, not the speed they were captured.

The SSRC (synchronization source) is a 32-bit random identifier for the stream's source. On a camera sending video and audio, each gets its own SSRC, so the VMS can tell the two apart even when they share a connection.

A fourth field, the payload type, names the format inside — for example, which codec the bytes represent — so the receiver knows whether it is holding H.265 or H.264.

Figure 2. Inside one RTP packet. The 12-byte header is small but decisive: the sequence number detects loss and restores order, the timestamp keeps video smooth and synced, and the SSRC identifies the source. The compressed video rides behind it.

How one frame becomes dozens of packets

Here is the part the vendor explainers skip, and it explains a class of real bugs. A single video frame — especially a keyframe, the full picture the codec sends periodically — is far too big to fit in one network packet. A standard Ethernet network moves packets of about 1,500 bytes at a time (the Maximum Transmission Unit, or MTU); after the IP and UDP headers, roughly 1,400 bytes are left for the actual payload. A compressed keyframe from a 4-megapixel camera can be tens of kilobytes. The video has to be cut up.

The rules for cutting it up live in the RTP payload format for each codec: RFC 7798 for H.265/HEVC (March 2016) and RFC 6184 for H.264 (May 2011). Both define the same three structures, named differently. A single NAL unit packet carries one small, self-contained piece of video on its own. An aggregation packet bundles several small pieces into one packet, so the network is not wasted on tiny payloads. A fragmentation unit does the opposite: it splits one large piece across many packets, which is how a big keyframe travels.

Make it concrete. Suppose a keyframe compresses to about 80 KB. At roughly 1,400 bytes of payload per packet, that single frame becomes about 80,000 ÷ 1,400 ≈ 58 RTP packets, each tagged with the next sequence number, all carrying the same timestamp because they belong to the same frame. The VMS collects all 58, checks the sequence numbers for gaps, reassembles them into the whole keyframe, and only then can it be decoded. If even one of those 58 packets is lost on a UDP transport, the entire keyframe can be unusable — which is the technical reason a brief network hiccup shows up as a few seconds of smeared or frozen video, not a single dropped pixel.

RTCP: the quality back-channel everyone forgets

Running quietly alongside the RTP video is its control companion, RTCP, also defined in RFC 3550. It carries no video. Its job is feedback: periodically, the sender and receiver exchange short reports. The camera sends a Sender Report (RTCP packet type 200) describing what it has transmitted and a timestamp that lets the VMS align audio with video; the VMS sends back a Receiver Report (type 201) describing what it received — the fraction of packets lost, the cumulative loss, and the jitter (the variation in packet arrival timing). RFC 3550 defines five report types in all (Sender Report, Receiver Report, Source Description, BYE, and APP).

This back-channel is how a surveillance system knows a stream is degrading before an operator notices a frozen tile. Loss and jitter numbers from RTCP are the raw material for the health dashboards a serious VMS shows — "camera 47 is dropping 4% of packets" is an RTCP fact.

RTCP is deliberately frugal so its reports never crowd out the video. The standard is explicit: "It is RECOMMENDED that the fraction of the session bandwidth added for RTCP be fixed at 5%" (RFC 3550, §6.2), split so that senders use about a quarter of that and receivers three-quarters. To avoid a storm of reports on a large system, the standard also sets a floor on how often any one party reports: "The RECOMMENDED value for a fixed minimum interval is 5 seconds" (RFC 3550, §6.2). For a surveillance fleet this matters: RTCP overhead stays near 5% of the media bandwidth no matter how many cameras you add, so it is a rounding error in capacity planning — but it is the rounding error that tells you the system is healthy.

The decision that defines the stream: UDP, TCP, or HTTP

Everything above is fixed by the standards. The one genuine choice you make is at SETUP: how RTP travels. It is the single most consequential networking decision in a surveillance design, because it decides whether the stream crosses the network at all.

The first option is RTP over UDP, the historical default. UDP is fire-and-forget: it never waits for acknowledgements and never resends a lost packet, which gives the lowest latency. On a clean, managed local network that is exactly right. But UDP RTP uses a pair of dynamically negotiated ports, and a firewall or any Network Address Translation (NAT) — the address-sharing between a private network and the internet — has no fixed rule to let them through. Across the internet, UDP RTP often simply does not arrive.

The second option is RTP interleaved over the RTSP/TCP connection. Here the video is packed into the same TCP connection already carrying the RTSP commands on port 554, so there is only one connection for a firewall to allow, and TCP guarantees every byte arrives in order. RFC 2326 defines the framing exactly: stream data "is encapsulated by an ASCII dollar sign (24 hexadecimal), followed by a one-byte channel identifier, followed by the length of the encapsulated binary data as a binary, two-byte integer" (RFC 2326, §10.12). The cost is latency: when TCP loses a packet it pauses everything to retransmit it — head-of-line blocking — which can turn a brief glitch into a short freeze.

The third option, common in surveillance and skipped by most explainers, is RTP/RTSP tunneled over HTTP(S). The whole RTSP/RTP exchange is wrapped inside ordinary web traffic on port 80 or 443. ONVIF's own streaming specification makes this mode mandatory — "a device shall support media transfer using RTP/RTSP/HTTP/TCP" (ONVIF Streaming Specification 26.06, June 2026, §5.1.1.5) — precisely because it traverses the strict corporate proxies and firewalls that block everything else, at the price of the most overhead. The same specification requires plain RTP over UDP, recommends TCP interleaving, deprecates bare RTP over TCP, and adds an optional RTSP-over-WebSocket mode for browser-based clients (§5.1.1.1–5.1.1.6). ONVIF, in fact, builds all of this on the same IETF protocols: its streaming spec describes "a set of media streaming … options, all based on RTP," with "media control … accomplished over RTSP," and enumerates RTP/UDP, RTP/RTSP/TCP, and RTP/RTSP/HTTP/TCP as transports (ONVIF Streaming Specification).

Table 2. The transport choice at SETUP. Move down the table as the network gets more hostile: UDP on a clean LAN, TCP interleaved across a firewall, HTTP tunneling through a strict proxy. Many VMS platforms try UDP first and fall back automatically.

Figure 3. The same RTP video, three ways to carry it. UDP is fastest but firewall-blocked; TCP interleaving needs only the one RTSP connection; HTTP tunneling passes the strictest proxies. The cleaner the network, the higher up the table you can stay.

The deeper networking behind this choice — why UDP and TCP behave the way they do, and how NAT traversal really works — is streaming-transport territory, covered in TCP vs UDP for streaming and NAT, STUN, TURN, and ICE. Here the rule is enough: the cleaner the network, the higher up Table 2 you can stay.

Is RTSP secure? RTSPS, SRTP and what changed in 2025–2026

Plain RTSP and RTP are not encrypted: anyone on the path can read the commands, the camera password exchange and the video. Two standard fixes exist, and they protect different layers. RTSPS wraps the RTSP commands in TLS, the same encryption that protects HTTPS, on TCP port 322 (RFC 7826, §4.2). SRTP, the Secure Real-time Transport Protocol (IETF RFC 3711), encrypts and authenticates the RTP video packets themselves.

ONVIF ties the two together. A camera that advertises secure RTSP streaming "shall support SRTP as defined in RFC 3711," must exchange the keys through the RTSP session using MIKEY, and must run RTSP over TLS whenever SRTP is used (ONVIF Streaming Specification 26.06, §5.1.1.4 and §8). The June 2026 release (26.06) added SRTP configuration to the ONVIF Core and Streaming specifications, so a VMS can now switch encryption on through the standard interface instead of each maker's web page.

The bigger change for buyers is in the profiles. On October 9, 2025, ONVIF announced it will end support for Profile S, the original streaming profile, because its authentication "is no longer consistent with current cybersecurity recommendations," and named Profile T (introduced in 2018) as the replacement. The June 2026 conformance test tools are the last that let a maker claim Profile S, and they stay valid for nine months; cameras already installed keep working (ONVIF press release, October 2025). In practice, specify Profile T and HTTPS for anything you buy from 2026 on — the ONVIF Profile S, G, T and M decision guide walks through what each one guarantees.

The browser is the other front. ONVIF published a WebRTC specification in June 2024 and has extended it in every release since (ONVIF specification history, 24.06–26.06). In July 2026 it put Profile V, a standard for cloud video surveillance, out as a release candidate: the camera opens a secure outbound connection and streams live video over WebRTC, so it can reach a cloud service or web client without port forwarding or a VPN; ONVIF plans to finalize it by the end of 2026 (SecurityInfoWatch, July 9, 2026). RTSP and RTP stay the workhorse inside the building — over 35,000 products are ONVIF-conformant as of January 2026, and the cameras and recorders among them stream over RTSP/RTP (ONVIF, 2026) — while WebRTC takes over the last hop to a browser. RTP over QUIC, a proposed newer transport, is still an expired IETF draft as of October 2026 and is not something to plan a camera fleet around.

What one camera actually puts on the wire

Tie it together with arithmetic for a single camera, because the numbers make the abstractions concrete. Take a 4-megapixel camera recording continuously in H.265 at an average of 3 Mbps (about half what the same camera would need in H.264). The math runs in three short steps.

First, turn the bitrate into bytes per second:

3 Mbps ÷ 8 = 0.375 megabytes per second = 375,000 bytes/sec

Second, turn bytes into packets, at roughly 1,400 bytes of payload each:

375,000 ÷ 1,400 ≈ 268 RTP packets per second

Third, add the RTCP overhead, fixed near 5% of the media:

3 Mbps × 5% ≈ 0.15 Mbps for RTCP — a rounding error

So one ordinary camera emits on the order of 268 video packets every second, each with its own sequence number, plus a trickle of RTCP reports a few times a minute. Multiply across a 40-camera site and the VMS is reassembling roughly 10,000 packets per second into coherent frames, watching every sequence number for gaps — which is why ingest performance under load, not on a bench, is the real test of a surveillance platform. The bitrate itself — and therefore the storage bill, since a VMS records the stream as-is — is governed by the codec on the camera, the subject of how surveillance storage works.

A common mistake to avoid

The costliest pattern we see is treating the transport as plug-and-play and discovering the gaps in production, and it has four faces. First, leaving the stream on UDP across a firewall, NAT, or the internet: it connects on the bench and fails on site — move to TCP interleaved, or HTTP tunneling, for any link that crosses a firewall. Second, believing "ONVIF" replaces RTSP: ONVIF only sets up the call, and the video still rides RTSP/RTP, so an ONVIF problem and a streaming problem are different problems with different fixes. Third, ignoring RTCP: the loss and jitter reports are the early-warning system, and a VMS that does not surface them is flying blind. Fourth, assuming a lost packet costs one frame: on UDP, losing one fragment of a keyframe can corrupt seconds of video, which is why hostile networks need TCP's reliability despite its latency. None of these is exotic; all four are predictable, and all four are cheaper to design around than to debug after deployment.

FAQ: ONVIF, RTSP and RTP

Is ONVIF the same as RTSP?

No. ONVIF is a standard for finding, configuring and controlling a camera; RTSP is the protocol that starts and stops its video stream. An ONVIF camera hands the VMS an RTSP address, so a typical system uses both.

What is the difference between RTSP and RTP?

RTSP is the remote control: it sends commands such as SETUP, PLAY and TEARDOWN. RTP is the moving van: it carries the compressed video packets. RTSP sets up the session, then RTP moves the pictures.

Does RTSP use TCP or UDP?

RTSP commands normally run on TCP port 554, and RTSP 2.0 (RFC 7826) requires TCP or TLS over TCP. The video carried by RTP can travel over UDP, interleaved inside the RTSP TCP connection, or tunneled through HTTP — UDP on a clean LAN, TCP or HTTP across a firewall.

What ports do ONVIF, RTSP and RTP use?

ONVIF web services run over HTTP (port 80) or HTTPS (443), and ONVIF camera discovery uses WS-Discovery on UDP port 3702; at scale this is covered in camera discovery and onboarding at scale. RTSP uses TCP 554, and RTSPS uses TCP 322. RTP over UDP uses a dynamically negotiated port pair, which is why firewalls block it.

How do I find a camera's RTSP URL?

Ask the camera over ONVIF: the media service's GetStreamUri call returns the RTSP address of each stream profile. Without ONVIF, the address format is set by the maker and listed in its documentation.

Is RTSP secure?

Plain RTSP and RTP are not encrypted. Use RTSPS (RTSP over TLS, port 322) for the commands and SRTP (RFC 3711) for the video; ONVIF Streaming 26.06 (June 2026) defines both for ONVIF cameras.

Is ONVIF Profile S being discontinued?

Yes. ONVIF announced in October 2025 that it is ending Profile S support and recommends Profile T. The June 2026 test tools are the last to allow new Profile S conformance claims; deployed Profile S systems keep working.

Where Fora Soft fits in

Fora Soft has built real-time video, streaming, and computer-vision software since 2005, across 250+ shipped projects, and the wire is where surveillance products quietly succeed or fail under load. The hard part is never one camera on a clean bench; it is a few hundred cameras from several manufacturers, some textbook-conformant and some that mishandle a TEARDOWN or stop sending RTCP, all of which must stream reliably, reconnect after a network blip, and degrade gracefully when packets drop. We build that layer — the RTSP/RTP pull with an automatic UDP-to-TCP-to-HTTP fallback, sequence-number-aware reassembly, and RTCP-driven health monitoring that flags a degrading camera before an operator sees a frozen tile. We lead with how the pipeline behaves on the worst network day — the packet storm, the half-open session — then the feature list, because an ingest layer that survives a bad network beats one that demos well on a quiet LAN. Teams that need this ingest layer built usually come to our video surveillance and VMS development team, and when the streams feed detection or tracking, our computer vision for surveillance engineers take the decoded frames from there. When operators need those feeds in a browser with sub-second delay, our WebRTC development team builds the RTSP-to-WebRTC gateway that the new ONVIF WebRTC work points toward.

The handbook

Fora Soft Video Engineering Handbook

We wrote a seven-volume, 9,000-page series that works through the whole video stack — encoding, delivery, audio and AI — so an engineer who has read it can design and build the ingest layer of a VMS, not only configure one. Volume 2 sits closest to this article: TCP against UDP, NAT traversal and the transport decisions you make at SETUP. Volume 1 explains the H.265 and H.264 keyframes that RTP cuts into dozens of packets, and volume 3 carries the same ideas into real-time delivery, WebRTC and players. Written by Nikolay Sapunov, CEO at Fora Soft.

Browse the handbook on Amazon →7 volumes · Kindle & paperback

See our case studies

References

1. IETF — "RFC 2326: Real Time Streaming Protocol (RTSP)" (RTSP "acts as a 'network remote control' for multimedia servers", §1.1; required methods OPTIONS/SETUP/PLAY/TEARDOWN, §10; default port 554 over TCP or UDP, §3.2; stateful, unlike HTTP, §1.1; interleaved binary framing — $ (24 hex) + one-byte channel + two-byte length, §10.12; client/server state machine INIT/READY/PLAYING, Appendix A). Primary (tier 1). https://www.rfc-editor.org/rfc/rfc2326.txt
2. IETF — "RFC 3550: RTP, A Transport Protocol for Real-Time Applications" (fixed 12-byte header, §5.1; sequence number "increments by one for each RTP data packet sent... to detect packet loss and to restore packet sequence"; timestamp "reflects the sampling instant of the first octet"; SSRC synchronization source; five RTCP packet types SR=200/RR=201/SDES=202/BYE=203/APP=204; "the fraction of the session bandwidth added for RTCP be fixed at 5%", §6.2; "RECOMMENDED value for a fixed minimum interval is 5 seconds", §6.2). Primary (tier 1). https://www.rfc-editor.org/rfc/rfc3550.html
3. IETF — "RFC 7826: Real Time Streaming Protocol Version 2.0" (RTSP 2.0, December 2016; "obsoletes RTSP version 1.0 defined in RFC 2326"; Internet Standards Track; not backward compatible with 1.0, §1; TCP or TLS over TCP mandatory for RTSP messages, "rtspu" unspecified, §2 and §4.2; default port 554 for rtsp and TCP 322 for rtsps, §4.2; most field cameras still implement RTSP 1.0). Primary (tier 1). https://www.rfc-editor.org/rfc/rfc7826.html
4. IETF — "RFC 7798: RTP Payload Format for High Efficiency Video Coding (HEVC)" (March 2016; three packetization structures — single NAL unit packet, aggregation packet (AP), fragmentation unit (FU); APs bundle small NAL units, FUs fragment a NAL unit larger than the MTU across packets). Primary (tier 1). https://www.rfc-editor.org/rfc/rfc7798.txt
5. IETF — "RFC 6184: RTP Payload Format for H.264 Video" (May 2011; analogous packetization — single NAL unit packet, aggregation packets STAP/MTAP, fragmentation units FU-A/FU-B). Primary (tier 1). https://www.rfc-editor.org/rfc/rfc6184.txt
6. ONVIF — "ONVIF Streaming Specification" (media streaming options "all based on RTP [RFC 3550]"; "media control is accomplished over RTSP as defined in RFC 2326"; transport options include RTP/UDP, RTP/RTSP/TCP, and RTP/RTSP/HTTP/TCP; RTCP usage mandated). Primary (tier 1). https://www.onvif.org/specs/stream/ONVIF-Streaming-Spec.pdf
7. ONVIF — "Profile T" (advanced video streaming; introduced 2018; H.264 and H.265 encoding, HTTPS streaming; ONVIF's recommended replacement for Profile S since October 2025). Primary (tier 1). https://www.onvif.org/profiles/profile-t/
8. ITU-T — "H.265: High Efficiency Video Coding (HEVC)" (the codec standard whose compressed bitstream the RTP payload carries; ITU-T H.264/AVC its predecessor). Primary (tier 1). https://www.itu.int/rec/T-REC-H.265
9. OpenEye — "How Does Adding a Camera as ONVIF Differ From RTSP" (operational view: ONVIF discovers and configures the device while RTSP is the stream the VMS plays; adding by RTSP forgoes ONVIF discovery, events, and configuration). Institutional / engineering orientation (tier 5). https://answers.openeye.net/Troubleshooting/Frequently_Asked_Questions/Cameras/How_Does_Adding_a_Camera_as_ONVIF_Differ_From_RTSP
10. Wowza — "RTP vs RTSP: control and transport layers" (updated May 2026; RTSP is the control channel; RTP/RTCP carry media on dynamically negotiated ports; TCP interleaving for firewall traversal; UDP-first with TCP fallback). Vendor engineering (tier 4). https://www.wowza.com/blog/rtp-vs-rtsp-the-difference-between-streamings-control-and-transport-layers
11. ONVIF — "ONVIF Streaming Specification" version 26.06, June 2026 (RTP/UDP required, §5.1.1.1; RTP/TCP deprecated, §5.1.1.2; RTP/RTSP/TCP recommended, §5.1.1.3; RTP/RTSP/HTTP/TCP required, §5.1.1.5; RTSP over WebSocket, §5.1.1.6; SRTP per RFC 3711 with MIKEY key management and TLS for RTSP, §5.1.1.4 and §8; RTCP Sender Reports required for live streaming, §5.1.2.2). Primary (tier 1). https://www.onvif.org/specs/2606/ONVIF-Streaming-Spec-v2606.pdf
12. ONVIF — "ONVIF to End Support for Profile S; Recommends Profile T as Replacement" (press release, October 9, 2025; June 2026 test tools the last to allow Profile S conformance claims, nine-month validity; no effect on deployed systems). Primary (tier 1). https://www.onvif.org/pressrelease/onvif-to-end-support-for-profile-s/
13. ONVIF — "Specification History" (WebRTC specification first published 24.06, June 2024; ICE candidates 24.12; metadata over data channel 25.06; SRTP configuration in Core and Streaming 26.06, June 2026). Primary (tier 1). https://www.onvif.org/profiles/specifications/specification-history/
14. ONVIF — "Building your security future with the growing ecosystem of ONVIF conformant products" (January 29, 2026; more than 35,000 conformant products). Primary (tier 1). https://www.onvif.org/blog/2026/01/29/building-your-security-future-with-the-growing-ecosystem-of-onvif-conformant-products/
15. SecurityInfoWatch — "ONVIF Introduces Draft Cloud Video Surveillance Standard With Profile V" (July 9, 2026; release candidate; WebRTC live streaming over a device-initiated outbound connection; OAuth 2.0 security add-on; final version planned by end of 2026). Trade press (tier 3). https://www.securityinfowatch.com/video-surveillance/news/55389850/onvif-onvif-introduces-draft-cloud-video-surveillance-standard-with-profile-v
16. IETF — "RFC 3711: The Secure Real-time Transport Protocol (SRTP)" (encryption, message authentication and replay protection for RTP and RTCP). Primary (tier 1). https://www.rfc-editor.org/rfc/rfc3711.html
17. IETF — "RTP over QUIC (RoQ)", draft-ietf-avtcore-rtp-over-quic-14 (March 2025; expired Internet-Draft, not an RFC as of October 2026). Primary (tier 1). https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-over-quic/