ONVIF: Profiles and Where They Fall Short
- Apr 10
- 4 min read
For those new to the security industry, or those not deeply involved in the technology side, ONVIF is often simplified to mean that “cameras can talk to different systems.” That’s partially true, but it misses the full point. ONVIF defines how devices communicate. It does not guarantee how well they integrate. Understanding that distinction is critical when designing or evaluating a security system.
ONVIF Overview
ONVIF stands for Open Network Video Interface Forum. It is the standard that allows compliant devices and clients to communicate using a common set of interfaces. It is NOT a transport protocol like RTSP. Instead, ONVIF operates at the Application Layer (Layer 7) of the OSI model (See here if you want more information on the OSI model), using standardized web services (SOAP/XML) to define how devices expose functionality such as video streams, events, and configuration.
To summarize, ONVIF:
Defines how to ask for information
Does not guarantee what information will be available
ONVIF Profiles
ONVIF organizes functionality into “profiles,” each of which defines a set of required capabilities. There are currently seven primary profiles:
*- click the hyperlinks if you want to read the official specifications for each Profile.
Access Control Profiles
Video Surveillance Profiles
An ONVIF device or client may support any combination of these profiles. Each profile defines a minimum required feature set, along with optional capabilities that manufacturers may or may not implement. This is where things can get confusing.
Access Control Profiles
Profile A
Profile A defines the ability to configure and manage access control systems. This includes users, credentials, schedules, and access rules.
Profile C
Profile C focuses on access control event and status communication, including door events, alarms, and basic system interaction.
Profile D
Profile D covers communication between edge devices (readers, intercoms, biometric devices) and the access control system. This includes credential exchange and door control signaling.
Video Surveillance Profiles
Profile S
Profile S is the original video streaming profile. It supports basic video streaming, PTZ control, and simple event handling. While still widely deployed, Profile S is gradually being superseded by Profile T in newer systems. ONVIF states on their website that it will be deprecated on March 31, 2027.
Profile G
Profile G adds support for recording and playback. It allows a client to query and retrieve stored video, as well as manage recording behavior.
Profile T
Profile T is the modern, feature-rich video profile. It includes:
H.264 / H.265 video streaming
Advanced imaging controls
Motion and tampering events
Metadata support
Bidirectional audio (media streaming)
This refers to audio streaming only. It does not include call setup or routing, which are handled by protocols such as SIP.
Secure communication via TLS/HTTPS
Profile M
Profile M was introduced to support modern analytics use cases. It expands ONVIF’s ability to handle structured metadata, including:
Object classification
License plates
Facial data
Geolocation
It also supports configuration and transmission of analytics-related events and rules.
ONVIF Add-Ons
In addition to profiles, ONVIF defines Add-Ons, which extend functionality for specific use cases without forming a full profile. One example is the TLS Configuration Add-On, which allows clients to configure secure communication settings on devices. Multiple add-ons exist, and this area continues to evolve.
What ONVIF Does NOT Guarantee
This is the part that is often misunderstood.
ONVIF compliance does not guarantee:
Full feature availability
Consistent behavior across manufacturers
Support for advanced analytics or events
Seamless interoperability in production systems
Profiles define minimum capabilities, not complete implementations. Two devices can both be Profile T compliant and still behave very differently.
Designing Around ONVIF
When designing or updating a system that relies on ONVIF, there are two critical considerations:
Profile Alignment
Ensure that both the client (e.g., VMS) and devices support the profiles required for your intended functionality. If your system depends on analytics metadata, both sides must support Profile M—not just Profile T.
Feature Verification Beyond Profiles
Profile alignment alone is not sufficient. Because Profiles have optional features, it is important to ensure that desired feature sets are enabled for the devices intended for use. It is also possible that event handling may be different between devices and clients, or Metadata may be transmitted but not properly interpreted or exposed by the client. It is best to demo the full feature set in a small lab environment to ensure desired functionality.
Conclusion
ONVIF compliance is not a binary condition, and assuming that an ONVIF-compliant device will fully integrate with an ONVIF-compliant system is a common mistake. Profiles define minimum capabilities, not complete functionality, and even perfectly matched profiles can result in partial or inconsistent behavior. The most reliable approach is to treat ONVIF as a foundation, then validate critical features in the actual system. In practice, ONVIF guarantees you can connect. It does not guarantee you can fully use the device.
Click here to return to the Articles page.
Click here to return to our Home page.
Comments