ONVIF and Camera Discovery

What ONVIF is

ONVIF is an open standard that lets cameras and video software from different manufacturers talk to each other. In practice it gives you a small set of SOAP web-service calls a camera will answer: what device this is, what stream profiles it offers, what URL each profile lives at, and what the camera thinks the time is. It is a description protocol. The video itself still arrives over RTSP.

What it is actually good for

The honest value of ONVIF is onboarding speed. Without it, adding a camera means finding its IP address, logging into a vendor web interface, hunting for the RTSP path, and typing it correctly — a path that differs per manufacturer and is easy to get subtly wrong. With ONVIF, software can ask the camera directly:

• Device information — model, firmware, serial. Useful for an inventory and for knowing what you are actually looking at.
• Stream profiles — typically a high-resolution main stream and one or more lower-resolution sub-streams, each with resolution, frame rate and codec.
• Stream URIs — the address for a chosen profile, so nobody has to know a vendor's URL convention.
• Device clock — which lets you detect clock skew, a common and surprisingly damaging misconfiguration in video systems.

The rule that matters: a reported resource is a claim, not a fact

This is the part that catches teams out. A camera will happily return a stream URI that is syntactically perfect and operationally wrong. We have seen a camera advertise a plain rtsp:// address while actually refusing anything but rtsps://, and return the URL decorated with ONVIF negotiation parameters that break the connection when passed through verbatim.

The discipline that follows is simple and worth adopting as a rule:

ONVIF answers which stream you want. The connection you have already proven answers how to reach it.

In other words: take the profile selection from the camera, but take the transport — scheme, host, port, credentials — from a connection you have actually tested. And then open it, and confirm frames arrive, before telling the operator it works. A good onboarding screen shows these as two separate facts: what the camera reports, and what the software actually received.

ONVIF credentials are often not your camera credentials

Many cameras — particularly Dahua-based OEM devices, which is a large slice of the market — maintain a separate user database for ONVIF from the one used for RTSP and the web interface. The same username and password that streams video may simply fail to authenticate over ONVIF, and it is not a typo.

Two consequences: store ONVIF credentials as their own field rather than assuming they match, and never silently retry the RTSP credentials against the ONVIF service. Repeated failed authentication can lock out the very account your video stream depends on.

Discovery does not always work, and that is normal

ONVIF device discovery uses WS-Discovery, which is a UDP multicast probe. That works well on a flat camera VLAN and fails routinely elsewhere — multicast is commonly not forwarded across subnets, is filtered by many managed switches, and does not survive most VPNs or virtualised network stacks. A scan returning nothing usually means the network did not carry the probe, not that the camera lacks ONVIF.

Design for that: always let an operator type an address directly, and treat discovery as a convenience that may find nothing. Software that requires a successful scan to add a camera will fail on a large fraction of real networks.

Treat ONVIF as an enhancement, never a dependency

A useful way to structure this is to separate what your system guarantees from what a camera might offer:

• Generic RTSP — the baseline. Connection, live view, observed resolution and frame rate, recording, alerts, evidence. This must work on any camera that streams, including one with no ONVIF support at all.
• ONVIF — an enhancement. Discovery, model and firmware, advertised profiles, clock skew. Nice to have, frequently absent, and never a prerequisite for the camera to be monitored.
• Vendor-specific features — picture tuning, camera-side analytics, on-camera recording. These belong in the camera's own interface, not reimplemented in your software.

The test is simple: if a camera with no ONVIF at all cannot be fully monitored by your system, ONVIF has stopped being an enhancement and become a dependency. That is a defect.

Where ManasaView fits

ManasaView uses ONVIF exactly this way. Camera setup offers discovery and profile selection when the network and camera allow it, and works entirely without them when they do not. Every stream a camera advertises is verified by a real connection test before it is accepted, and the interface deliberately separates what the camera reported from what ManasaView actually received.

Frequently asked questions

Is ONVIF the same as RTSP?

No. ONVIF is a description and control protocol — it tells software what the camera is and what streams it offers. RTSP is the protocol that carries the video. ONVIF typically hands you an RTSP URL to connect to.

Do I need ONVIF to use an IP camera?

No. Any camera that exposes an RTSP stream can be monitored without ONVIF. ONVIF makes onboarding faster and adds metadata like model and device clock, but well-designed software treats it as optional.

Why does ONVIF discovery find no cameras on my network?

Discovery uses UDP multicast, which is often not forwarded between subnets and is filtered by many switches, VPNs and virtual network stacks. It usually means the probe did not reach the camera, not that the camera lacks ONVIF. Entering the address manually still works.

Why do my camera credentials fail over ONVIF?

Many cameras keep a separate user account list for ONVIF from the one used for RTSP and the web interface. The credentials that stream video may genuinely not be valid for ONVIF, so ONVIF credentials should be stored and entered separately.

Can I trust the stream URL a camera reports?

Treat it as a claim to verify. Cameras return URLs that are syntactically valid but operationally wrong — for example advertising rtsp:// on a device that only accepts rtsps://, or including negotiation parameters that break the connection. Always probe the URL before relying on it.