Why 'ONVIF' Cameras Still Fail to Integrate

ONVIF is the shared language IP cameras use to talk to recorders and software, but "ONVIF compliant" on a datasheet only promises the minimum feature set of one profile. The video itself travels over RTSP, which fails in its own ways. Most broken integrations trace back to four places: profile mismatch, discovery, transport, and stream settings.

None of those four shows up in a showroom demo. They show up on site, on the third day, when half the cameras go grey in the analytics dashboard while the recorder keeps working fine.

What does "ONVIF compliant" actually promise?

Think of ONVIF as a restaurant menu, not a dish. The standard is split into profiles, and each profile is a fixed set of features that a camera and a client must both support for that set to work. A camera that passes Profile S and a video management system that only speaks Profile M share a name on the box and very little else.

Conformance is claimed per profile, per firmware version. ONVIF lists every product that has a Declaration of Conformance, and that list passed 35,000 conformant products in January 2026. A product that is not on the list is making a marketing claim. "ONVIF compatible" or "supports ONVIF" usually means the vendor implemented part of a profile and never submitted it for testing.

The practical check takes five minutes. Search the model on the ONVIF conformant products list, note which profiles it passed, and compare the firmware version on the list with the one that ships. A camera conformant on firmware 5.1 says nothing about firmware 5.4.

Why is ONVIF retiring its oldest profile, and does it affect you?

On 9 October 2025 ONVIF announced it will end support for Profile S and named Profile T as its successor. The June 2026 release of the conformance test tools is the last one that can certify Profile S. After 31 March 2027, no new product and no new firmware can be submitted for it.

The reason is the login. Profile S requires username token authentication, an older scheme that ONVIF no longer considers consistent with current security practice. Profile T uses digest authentication — it avoids transmitting the password directly, but still needs correct implementation and transport protection — and adds HTTPS for the video stream.

Cameras already installed keep working. ONVIF states that existing Profile S products stay interoperable with each other. What changes is procurement:

• Write "ONVIF Profile T conformant, listed on onvif.org" into the purchase order, not "ONVIF compliant".
• If the project needs H.265 through ONVIF, Profile T is the only way to get it. Profile S never standardised H.265.
• Check each later firmware version's conformance claim. Existing registrations remain, while implementation changes are up to the vendor; new Profile S submissions close after March 2027.

Why does the camera appear in discovery, then vanish?

Discovery works like shouting in a room and listening for who answers. The software sends one multicast message — a single packet addressed to every device on the local network at once — and ONVIF cameras reply with their address. It is convenient, and it stops at the edge of the room.

Multicast does not cross routers by default. Put cameras on their own VLAN (a separate virtual network on the same switches, which is the right design) and the server on another, and discovery finds nothing. Some managed switches also filter multicast they consider unwanted. The installer sees an empty list and concludes the cameras "aren't ONVIF".

The second failure is quieter. A camera answers discovery with the address it believes it has. After the router hands out a new address, or behind NAT (a router translating addresses between networks), that address is wrong, and the software stores it anyway. Everything works until the next reboot.

Treat discovery as a convenience during installation, never as the source of truth. Assign cameras static addresses or DHCP reservations, keep the inventory in a spreadsheet or database, and add cameras to the software by IP.

Why does video freeze once it crosses a firewall?

ONVIF handles setup: what the camera can do, which streams it offers, and where to fetch them. The video itself travels over RTSP, which is only the remote control — play, pause, teardown — while the frames ride on RTP packets beside it.

By default many clients request RTP over UDP on a pair of ports negotiated per stream. On a flat LAN that is fine and gives the lowest delay. Across a router, a firewall, a VPN or a cloud link, those ports are dynamic and often blocked or dropped. Packet loss on UDP shows up as smeared grey blocks until the next full frame arrives.

The alternative is interleaving: sending the video inside the same TCP connection as the RTSP commands, defined in RFC 2326 section 10.12. One port and one connection simplify firewall configuration, provided that connection is allowed, and lost packets get resent instead of smeared. The cost is added delay when the network is poor.

For routed paths or analytics, test RTP over TCP first. UDP can suit local recording where loss and latency are acceptable; select transport after measuring the actual path. Force it explicitly on the client, for example ffprobe -rtsp_transport tcp, rather than trusting the default.

Which stream should analytics read?

Most cameras publish at least two streams. The main stream is full resolution for recording. The sub-stream is small, often 640×360 or 720p, and exists for live grids and for analytics.

Detection models rarely need 4K. Decoding sixty 4K H.265 streams to feed a model that resizes everything to 640 pixels wide is how a server that looked generous on paper runs out of CPU in week one. Point analytics at the sub-stream and size the hardware for that.

The trap is how the client picks a stream. ONVIF identifies streams by a profile token, a name the camera invents. Vendors rename or reorder those tokens after firmware updates, so an integration that stores "the second token" can silently switch to the main stream, or to nothing. Select streams by resolution and codec, re-read the list after every reboot, and log which stream was actually opened.

Why does analytics start late and log the wrong time?

Video compression sends one complete picture, the keyframe, then a run of frames that only describe what changed. A client that connects mid-run sees nothing useful until the next keyframe arrives.

Cameras with "smart" codec modes stretch that gap to save bandwidth, sometimes to several seconds when the scene is still. For recording that is a good trade. For analytics it means every reconnect starts with seconds of blindness, and exported clips begin late. Set the analytics stream to a keyframe every one to two seconds and turn smart codec off on that stream only.

Timestamps fail the same way. RTP timestamps express sampling time in a media clock domain with an initially random offset; they are not wall-clock timestamps. RTCP sender reports can pair them with wall-clock time (RFC 3550). The wall-clock time comes from the camera's own clock, so a camera without clock synchronization can drift; measure the error rather than assume a fixed rate. We covered what that does to evidence in clock drift and timestamp evidence. Point every camera at the same NTP server as the recorder.

What should an integration test cover before rollout?

Run these on one camera of each model before the order is confirmed, not after 120 are mounted on poles:

1. Conformance list — model, profiles, and firmware version match what the supplier will ship.
2. Add by IP — from a different subnet than the camera, with discovery off.
3. Stream selection — the client picks the sub-stream by resolution, and still picks it after a firmware update.
4. Transport — ffprobe -rtsp_transport tcp returns the expected codec and resolution; the stream runs through the real firewall and VPN path.
5. Reconnect — power-cycle the camera and confirm the client resumes without a restart.
6. Keyframe gap — time from connect to first decoded frame is under two seconds.
7. Accounts — a dedicated non-admin user with digest authentication; the admin password never lives in the integration config.
8. Soak — 24 hours with frame-age monitoring, the same check described in SNMP monitoring for CCTV fleets.

Passing these eight checks provides evidence for the tested model, firmware, and network path; repeat affected tests after changes. A camera that fails one is cheaper to reject now than to work around for five years. Storage sizing for the streams you just chose is the next step, covered in CCTV storage sizing.