Cameras

ONVIF camera won't connect

Fix ONVIF discovery and control failures — VLAN multicast, the Profile S sunset, ONVIF accounts, and clock-skew auth.

Problem summary

ONVIF is the discovery/control layer separate from the RTSP video, so it can fail while the camera still streams. The usual causes are WS-Discovery multicast not crossing a VLAN, a separate ONVIF account, or a clock skew breaking the timestamped auth — and as of 2025 ONVIF has ended Profile S support in favor of Profile T.

Operator snapshotEvidence first

First proof

Confirm the camera is reachable and its RTSP stream plays.

Screen to open

ONVIF Device Manager (Windows) or `onvif-cli`/WS-Discovery scan

Expected signal

You can ping the camera and ffprobe/VLC its RTSP URL.

Stop boundary

If on an isolated VLAN, ensure the NVR is allowed to reach the camera's ONVIF port.

Layer path

1ONVIF is a discovery + control standard, separate from the RTSP video stream — an ONVIF failure can leave the camera streaming fine while the NVR can't add or control it.

2The big 2025 shift: ONVIF announced the end of support for Profile S and recommends Profile T as the replacement, so 'which profile' now matters for new gear.

3WS-Discovery uses link-local multicast (239.255.255.250, UDP/TCP 3702), so it does not cross VLAN/subnet boundaries — cameras on a separate VLAN won't be auto-discovered.

4ONVIF auth is timestamped (WS-UsernameToken), so a clock skew between camera and NVR causes authentication failures — and isolated cameras with no internet drift unless given local NTP.

Runbook

Step-by-step runbook

Start here. Do each check in order, compare it to the expected result, and stop when the evidence explains the failure or the safe stop point applies.

Separate ONVIF from the video stream

Check: Confirm the RTSP stream plays even if ONVIF won't connect.

Expected result: Streaming works; the problem is isolated to ONVIF control/discovery.

If not: If RTSP also fails, fix reachability/credentials first.

Beat the VLAN discovery problem

Check: If the camera is on a separate VLAN, add it by IP + ONVIF port rather than relying on WS-Discovery.

Expected result: The NVR adds the camera manually without multicast discovery.

If not: Alternatively run discovery from a host on the camera's VLAN.

Fix ONVIF auth and time

Check: Enable ONVIF on the camera, set a dedicated ONVIF user, and sync the clock.

Expected result: ONVIF authenticates and the timestamps line up.

If not: For internet-isolated cameras, point them at a local NTP server so the clock can't drift.

Use the profile the camera really supports

Check: Prefer Profile T; confirm the camera's conformance for PTZ/events/audio.

Expected result: Only conformant features are relied upon.

If not: Don't assume a budget 'ONVIF' camera fully implements Profile T.

Allow the NVR through any camera-VLAN firewall

Check: Permit the NVR to reach the camera's ONVIF + RTSP ports across the VLAN.

Expected result: The NVR controls and streams the camera while the camera stays isolated from the internet.

If not: See /cameras/isolate-cameras-on-vlan for the firewall pattern and local NTP.

Decision tree

If: Camera streams (RTSP) but the NVR can't discover it.

Then: WS-Discovery multicast isn't crossing the VLAN.

Action: Add the camera by IP + ONVIF port manually, or run discovery from the camera's VLAN.

If: Discovery finds it but auth fails.

Then: Wrong ONVIF account or clock skew.

Action: Set the dedicated ONVIF user and sync the camera's clock (local NTP for isolated cameras).

If: Connects but PTZ/events/two-way audio don't work.

Then: Partial ONVIF conformance on the camera.

Action: Confirm the camera's real ONVIF profile/conformance; don't assume full Profile T support.

If: Nothing connects and RTSP also fails.

Then: Network/reachability problem, not ONVIF.

Action: Fix IP/PoE/VLAN reachability first; see /cameras/camera-keeps-going-offline.

Safe stop: If on an isolated VLAN, ensure the NVR is allowed to reach the camera's ONVIF port.

Evidence

Evidence table

Symptom	Evidence to collect	Likely layer	Next action
Camera not found by discovery.	Whether camera and discovery host share a subnet.	WS-Discovery multicast / VLAN	Add by IP+port, or discover from the camera's VLAN.
'Authentication failed' on ONVIF.	ONVIF user vs RTSP user; camera-vs-NVR clock.	ONVIF account / clock skew	Use the ONVIF account; sync time (local NTP for isolated cams).
PTZ/events missing though it connects.	The camera's published ONVIF profile/conformance.	Partial conformance	Use only the conformant features; verify on onvif.org.
New camera, unsure which profile.	Profile S vs Profile T support.	Profile lifecycle (S sunset)	Prefer Profile T; treat Profile S as legacy.

Reference

Commands and settings paths

Discover ONVIF devices on the subnet

ONVIF Device Manager (Windows) or `onvif-cli`/WS-Discovery scan

Where: From a machine on the SAME subnet/VLAN as the camera.

Expected: The camera appears with its ONVIF service address and profile.

Failure means: Nothing found across a VLAN confirms multicast isn't routing — add by IP instead.

Safe next step: Add the camera manually by IP + ONVIF port, or scan from its VLAN.

Test ONVIF auth + time

ONVIF Device Manager: connect with the ONVIF user; check the device's system time

Where: Against the camera's IP + ONVIF port.

Expected: Auth succeeds and the device time matches the NVR within a few seconds.

Failure means: Auth failure or a large time delta points at the ONVIF account or clock skew.

Safe next step: Set the ONVIF account; sync the camera clock (give isolated cameras local NTP).

Confirm the camera is reachable from the NVR

ping <camera-ip> and ffprobe the RTSP URL

Where: From the NVR (across the VLAN if segmented).

Expected: Ping and RTSP both succeed, proving reachability and a working stream.

Failure means: If blocked, the inter-VLAN firewall or PoE/network is the issue, not ONVIF.

Safe next step: Allow the NVR to reach the camera's ONVIF + RTSP ports; fix reachability first.

Hardware boundary

Hardware and platform boundary

Change only when

Buy cameras that publish ONVIF Profile T conformance (not just 'ONVIF compatible') when you need PTZ, events, or two-way audio through an NVR.

Evidence that matters

Verified Profile T support, a documented ONVIF port/account, a stable RTSP substream, and PoE class within your switch budget.

Evidence that does not matter

Marketing 'ONVIF compatible' labels without a conformance listing — partial implementations are common.

Avoid

Relying on cross-VLAN WS-Discovery (multicast won't route) or leaving isolated cameras without a local NTP source.

Related tool/calculator

Use the linked calculator or tool to turn this runbook into numbers for your exact setup.

Device setup troubleshooter

Last reviewed

2026-06-02 · Reviewed by HomeTechOps. Built from June-2026 research verified against ONVIF.org (Profile T, and the 2025 end-of-support for Profile S) and the WS-Discovery multicast behavior; separates ONVIF control/discovery from the RTSP stream, and ties the cross-VLAN discovery + clock-skew auth failures to the camera-isolation and NTP guidance.

Sources/assumptions

Assumes an NVR/tool adding an ONVIF camera (discovery and/or PTZ/events), separate from the RTSP stream.
WS-Discovery uses link-local multicast that does not route across VLANs/subnets.
'ONVIF compatible' often means partial conformance — verify the camera's profile on ONVIF's conformant-products listing.

Source-backed checks

HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.

Frigate docs: Recommended hardwareUsed for detector inference times, the cameras ≈ (1000 ÷ inference_ms) ÷ detect_fps capacity model, and the current 'Coral no longer recommended for new installs' guidance.Frigate docs: Camera setup (detect vs record streams)Used for the detect-on-substream / record-on-main pattern that drives bandwidth and detector load.FS.com: Understanding PoE standards and wattageUsed for the 802.3af/at/bt source-vs-delivered power figures and the switch total-PoE-budget constraint.ONVIF: Profile TUsed for the Profile T feature set and the 2025 end-of-support for Profile S (Profile T is the recommended replacement).Frigate documentationUsed as the first-party reference for Frigate camera setup, detectors, recording, and configuration.FCC: Home network tipsUsed for router placement, congestion, and baseline home-network troubleshooting guidance.

Diagnostic rule

1. Check the simplest signal first.
2. Change one thing at a time.
3. Prove the stream/reachability before deep config.
4. Stop when the evidence says the risk moved.

FAQ

My NVR can't discover the camera but it streams fine — why?

ONVIF discovery (WS-Discovery) uses link-local multicast (239.255.255.250, port 3702), which does not cross VLAN or subnet boundaries. If the camera is on a separate VLAN, it won't be auto-discovered — add it manually by IP and ONVIF port, or run discovery from a device on the camera's VLAN. The RTSP stream works because you're giving it a routable IP directly.

ONVIF authentication keeps failing — what's wrong?

Two common causes: the camera needs a separate ONVIF user (the RTSP login may not work for ONVIF), and ONVIF auth is timestamped, so a clock skew between camera and NVR fails it. Set/confirm the ONVIF account and sync the camera's clock. Cameras on an internet-isolated VLAN must be given a reachable local NTP server or their clocks drift.

Should I buy 'Profile S' or 'Profile T' cameras now?

Prefer Profile T. ONVIF announced in 2025 that it is ending support for Profile S and recommends Profile T as the replacement (H.264/H.265, imaging, events, metadata, two-way audio). Treat Profile S as legacy, and remember 'ONVIF compatible' marketing isn't the same as a published conformance listing.