Definition
ONVIF (Open Network Video Interface Forum) is an open standard in the security industry, based on Web Services, specifying discovery, configuration, and streaming interfaces for IP cameras. ONVIF-compliant cameras can interconnect with NVRs, VMS (Video Management Systems), and video edge analytics devices of different brands. Video edge devices typically support RTSP, ONVIF, and GB28181 simultaneously.
Core Functions
Device discovery (WS-Discovery); device management (network, system, image configuration); media configuration (encoding, resolution, frame rate); streaming media (RTSP address acquisition, PTZ control); event subscription (motion detection, alarms). ONVIF specification has multiple Profiles (such as S, G, T), with different Profiles supporting different feature sets. Video edge analysis devices discover and pull camera video streams through ONVIF, perform AI analysis, and then report events or cascade them to the GB28181 platform.
Comparison with GB28181
GB28181 is a Chinese national standard, focusing on platform cascading and public security networking; ONVIF is an international standard, focusing on device interconnection. Most cameras support ONVIF; public security platforms require GB28181. Video gateways can convert ONVIF devices into GB28181 devices to access national standard platforms.
Profiles and the Media Configuration Tree
After discovery, the media description still has to be fetched
An open video interface splits a camera into groups of services. Discovery only answers "there is a device on the network." The device service gives the vendor, capabilities, and system time. Only the media service lists encoding configurations, resolution, and an address that can be played. If an analytics host or a recorder stops at discovery, it has a name at most and no playable stream. The stream address usually has to be handed to a streaming control protocol to open a session. Miss either step and no picture appears.
Configuration inside the device is a tree: encoding configurations hang under a video source, and those configurations hang on a specific profile. The caller has to use the token the device returned. It cannot invent a channel number. Some cameras have a main stream and a sub-stream configuration on each channel. If an analytics task picks the main stream by mistake, bandwidth and decode load exceed what the edge box was designed for.
Only the matching profile has playback or PTZ
The specification divides functions into profiles. A camera that implements only the live-video profile can be previewed. It may not play back by time, and it may not expose pan-tilt-zoom. Procurement and joint testing should write down whether they need discovery, a live stream, PTZ, or recording search, then check the profiles both sides declare. Seeing the interface name does not mean the function is complete. Event subscription exists on its own as well. Whether motion detection, tamper, and discrete inputs are reported has to be tried item by item in the event service. It cannot be inferred from "the picture is visible."
The conditions for use also include time sync and the account. If device time is wrong, event time and recording time do not meet, and search comes back empty. If the account has only preview rights, the media service can pull a stream while PTZ and configuration changes are refused. The log is easily written up as "device not compatible." Across subnets, the multicast used for discovery often never reaches the far side of a router. Use a known address and open the device service directly.
Accounts, time, and multicast clashes
An easy mistake is to treat multicast discovery as the only method. With port isolation on the switch, or a Layer 3 device in between, the list is empty while the camera is in fact online. Keep a path that adds the device by address. Second, authentication methods disagree. One end sends digest authentication, the other accepts only a different wrapping of username and password, the handshake fails repeatedly, and the symptom is an address that can be reached while the service times out. Third, someone else changes configuration at the same time, the configuration token is invalidated, and the stream address obtained in the previous round is discarded by the device.
Before sending many cameras into a VMS, finish profile, stream, and time on a single device. Convert the protocol when cascading to the upper platform. Do not convert and change the camera encoding at the same time. Mixing absolute and relative PTZ moves makes presets walk farther off over time. Finally, confirm whether the analytics host is pulling the sub-stream or the main stream, so recording and analytics do not fight over the same high-bitrate path.
After a reboot, profiles may return to the factory encoding and every stream-address token is void. If the collector caches the old address and does not read the media service again, it reports connection failures in a row while the camera itself is already online. The power-up sequence should fix discovery, time sync, reading the profile, and pulling the stream as a set order. Do not depend on an address left over from the previous session.