Streaming technology has evolved rapidly since the 1990s. As consumer demand for capabilities such as pause, play, rewind, and fast-forward increased, vendors implemented proprietary protocols to address market needs. These proprietary protocols created problems of their own, including vendor lock-in. 

The Open Network Video Interface Forum (ONVIF) standard and Real-Time Streaming Protocol (RTSP) have been essential vendor-neutral solutions to help address media-streaming use cases. RTSP, formalized in 1998 in RFC 2326, enables streaming between two endpoints. ONVIF, established in 2008, provides an open IP-based security and surveillance standard to reduce vendor lock-in and increase interoperability.

Interoperability – the purpose of ONVIF. (Source)

The “ONVIF vs RTSP” comparison is like comparing apples and oranges. One is a standard, while the other is a protocol. Take the analogy of electrical sockets and appliances. ONVIF is like a universal plug or socket standard that will help multiple appliances connect and work together. In contrast, RTSP is the electrical wiring protocol inside the appliance that handles the power flow. 

However, industry professionals may use terms like ‘ONVIF protocol’ and ‘RTSP standard’ in conversations, making distinguishing the differences challenging for those less familiar with them. This article will thoroughly explore the topic of ONVIF vs. RTSP, including use cases, implementation details, and recommendations.

Summary of key ONVIF vs RTSP concepts

The table below summarizes key differences between ONVIF vs RTSP that this article will explore in detail. 

Understanding RTSP

RTSP is an application-layer protocol that facilitates streaming media between two endpoints. It is designed for multiplexing and packetizing multimedia transport streams (such as video, audio, and interactive media). 

Notably, the RTSP protocol does handle the transmission of streaming data. Transport protocols like Real-time Transport Protocol (RTP) and Real-time Control Protocol (RTCP) typically handle data transmission. While RTCP sounds similar to RTSP, it is only used to monitor the quality of the media stream during transmission. For example, RTCP provides feedback metrics like packet loss, jitter, latency, network congestion, etc.

RTSP uses TCP to maintain an end-to-end connection. Like HTTP, most RTSP commands are sent from the client to the server, but some flow in the reverse direction. Unlike HTTP, RTSP is a stateful protocol. This means that the protocol can maintain the state of the streaming session between a client (like a media player) and a server. The state maintenance helps the server keep track of information specific to the session, like the current playback position and stream configurations (resolution, speed, codec type, etc.).

A sequence diagram of dataflows between an RTSP client and servers. (Source)

Common RTSP requests include:

• OPTIONS: This request asks the server which other requests it supports. The server responds with a list of supported requests, like DESCRIBE, SETUP, PLAY, PAUSE, TEARDOWN, etc.
• DESCRIBE: This request asks the server to describe the available media resources. The description returned is typically in the SDP (Session Description Protocol) format, which provides information like the available audio and video tracks, their codec, and network transport options (like RTP over UDP or TCP). This helps the client decide if it can support the media.
• SETUP: This request is made before the PLAY request. Once the client knows the description of the media resources on the server, it sends the SETUP request to specify the transport parameters for the requested stream. This request defines the media stream URL, protocol (like RTP), ports, and delivery mode (unicast or multicast) for the stream.
• PLAY: This causes the media stream to be played. The stream URL to be played needs to be specified (use an aggregate URL to play all media streams). The stream is played from start to end if no range is specified. If the PLAY request is sent after a PAUSE request, it resumes the stream from where it was paused.
• PAUSE: This temporarily halts one or all media streams (depending on the URL input). If a range parameter is present, it specifies when to pause; otherwise, the stream pauses immediately.
• RECORD: This request instructs the server to initiate recording a media stream. The server then saves the media data (audio and video) to a storage medium for later use. This is particularly useful for live streams where the media is streamed as soon as it is generated and not from an existing storage medium.
• ANNOUNCE: This request is like a notification. It can be sent by the client (typically when the client is the stream’s source) or the server. When the server sends the ANNOUNCE request, it typically notifies the client about an update or change in an ongoing session (like server downtimes or stream metadata changes). When the client sends the ANNOUNCE request, it informs the server about the media stream it plans to send (common in live streaming scenarios). The client provides details or codecs, bitrates, and transport options in the SDP format. ANNOUNCE is like a client-side equivalent of the DESCRIBE request.
• TEARDOWN: This request terminates the session. It frees all session-related data on the server.
• GET_PARAMETER: The client uses this information to query various stream-related parameters from the server. These can be parameters like buffer sizes, stream status, current position in a live stream, etc. GET_PARAMETER with no entity body can be used as a ‘ping’ request.
•  SET_PARAMETER: The client uses this request to change stream parameters such as bitrate, volume, and codec options or to enable/disable certain features, such as buffering.

The above requests give you an idea of the use cases of the RTSP protocol. The ONVIF standard specifies RTSP for streaming, which means that any ONVIF-compliant camera will use the RTSP protocol for streaming. However, the standard uses other protocols for other functionalities, like HTTP for device management and SOAP (Simple Object Access Protocol) for device configurations.

Understanding ONVIF

The ONVIF standard focused on interoperability. It defines several profiles, each being a standardized set of features in a video camera or the clients (like network video recorders and video management systems). The table below describes the major profiles defined in the ONVIF standard. 

A camera being ONVIF compliant means it complies with at least one of the profiles. Profile S is the most popular, and most modern IP cameras comply with it. Interestingly, profile S specifies the use of RTSP for streaming, which can contribute to the misuse of the terms ONVIF and RTSP in practice. 

WebRTC vs ONVIF

The ONVIF standard continuously evolves, and a new version is released every 6 months. As of this writing, the latest ONVIF version is 24.06, released in June 2024. This version publishes the WebRTC specification for peer-to-peer video streaming. In some ways, WebRTC is a competitor to RTSP, but their primary use cases differ. WebRTC is used for peer-to-peer video streaming (e.g., without a server, from your camera to your smartphone), whereas RTSP is used for server-to-client media streaming. Of course, if one of the peers is a server, WebRTC can effectively become an alternative to RTSP.

Over time, WebRTC is becoming more popular than RTSP because of the following factors:

• NAT traversal: WebRTC includes mechanisms for Network Address Translation (NAT) traversal, making it ideal for streaming across firewalled networks that RTSP struggles with.
• Ultra-low-latency: The design of WebRTC gives it much lower latency than RTSP
• Built-in security: WebRTC is inherently designed with modern security protocols, including DTLS (Datagram Transport Layer Security) for encryption and SRTP (Secure RTP) for secure media transport.
• Native browser support: WebRTC is natively supported in modern web browsers like Chrome, Safari, and Edge and doesn’t require additional plugins. Conversely, RTSP requires a dedicated client (like VLC) to handle the stream.

The addition of WebRTC in the ONVIF specification will increase its popularity even more.

Important ONVIF vs RTSP recommendations

Engineers designing streaming solutions, such as IP camera systems, should understand the differences between ONVIF and RTSP and how they influence implementation decisions. 

Here are five recommendations to keep in mind for your next project: 

• Understand what “ONVIF” compliance implies- If your camera is ONVIF compliant, chances are high that it supports RTSP protocol. However, if your camera supports RTSP, it doesn’t need to be ONVIF compliant.
• Check ONVIF profiles during camera selection- When choosing an ONVIF-compliant camera, check the profiles it complies with and confirm if they meet your requirements.
• Verify ONVIF versions- ONVIF versions matter. For example, if you choose an ONVIF-compliant camera that was produced about a year ago, chances are that it doesn’t support WebRTC. You may ask the manufacturer if they plan to integrate WebRTC support using a software update.
• Consider using ONVIF profile T to meet cybersecurity requirements- An ONVIF-compliant camera guarantees a certain degree of security. The ONVIF standards include foundational security mechanisms across all profiles. For additional security, especially from the streaming perspective, purchase a camera that is compliant with Profile T (advanced streaming) and can help reduce the risk of camera vulnerabilities. 
• Design for interoperability- For teams concerned with enterprise-grade physical security, ONVIF-compliant cameras can guarantee interoperability and help meet baseline device requirements. 
• Use physical security management software. SecuriThings integrates and centralizes compliance reporting, configuration management, and monitoring across multiple camera brands. It automates firmware upgrades, facilitates device password rotation, and implements device hardening policies. You can learn more by visiting this page.

Conclusion

RTSP is a protocol, and ONVIF is a standard. The terms are often used interchangeably because most ONVIF-compliant cameras only comply with Profile S, which specifies RTSP as the streaming protocol. This implies that most ONVIF-compliant devices use the RTSP protocol. Understanding the “apples vs oranges” nature of the ONVIF vs RTSP discussion enables organizations to make better design and implementation decisions and deliver media streaming and security solutions that address real-world requirements.