2026-06-02

ONVIF Works but RTSP URL Fails: Finding the Real Camera Stream Path

Why ONVIF discovery can work while the RTSP stream fails, and how to debug camera profiles, media URLs, authentication, transport, and SDP evidence.

An IP camera can answer ONVIF discovery and list profiles while every attempted RTSP URL still returns 401, 404, a SETUP error, or no video. Treat discovery and streaming as separate protocols: extract the profile's media URI, preserve its host/path exactly, then inspect RTSP authentication, DESCRIBE, SDP control URLs, transport negotiation, and RTP arrival. This proves where “ONVIF works but RTSP fails”; ONVIF visibility alone never guarantees that credentials, stream path, or media transport are valid.

ONVIF and RTSP are related in many camera workflows, but they are not the same protocol and they do not prove the same thing. ONVIF can tell you that a camera exists and may provide a media profile. RTSP must still authenticate, describe the stream, negotiate transport, set up RTP tracks, and deliver media packets.

RTSP Inspector focuses on that second half: what actually happens when a specific RTSP URL is used.

What ONVIF proves

ONVIF discovery can prove that:

The camera responds to WS-Discovery.
The camera exposes an ONVIF service endpoint.
The client can reach the camera management interface.
The camera may have one or more media profiles.
The device can report stream URIs through ONVIF media services.

This is useful, but it is not the same as proving the RTSP stream works. ONVIF discovery may use a different port, different authentication behavior, and different service path than RTSP.

A camera can pass ONVIF discovery and still fail RTSP because:

RTSP is disabled in camera settings.
The ONVIF account does not have RTSP permission.
The returned stream URI is incomplete or internal-only.
The RTSP port is blocked by a firewall.
The camera requires TCP interleaved transport but the client tries UDP.
The profile points to H.265 but the client expects H.264.
The NVR channel path is wrong.
The camera returns SDP but sends no RTP packets.

ONVIF stream URI may not be directly usable

Some cameras return an RTSP URI through ONVIF that looks usable but still needs modification. For example:

rtsp://192.168.1.50/Streaming/Channels/101

The real usable URL may need:

A port: :554
Credentials
URL-encoded password characters
A different host if accessed through VPN or NAT
A channel number
A sub-stream path
A vendor-specific query string

Some ONVIF responses return a local LAN address even when the camera is reached through a routed network. If the client runs outside that LAN, the ONVIF URL can be technically correct from the camera's point of view but unreachable from the client's point of view.

ONVIF profile does not guarantee codec support

An ONVIF media profile may refer to a video encoder configuration. That configuration can be H.264, H.265, MJPEG, or another format. A client may successfully receive the RTSP SDP and then fail to decode the media.

The symptom may be:

ONVIF profile appears.
RTSP connection succeeds.
SDP is returned.
RTP packets arrive.
The application still shows black video or "unsupported codec."

This is not an ONVIF discovery problem. It is a codec and media interpretation problem. If the camera is configured for H.265 and the environment expects H.264, the stream may appear broken even though RTSP transport is working.

RTSP Inspector helps by separating the layers:

Did RTSP authenticate?
Did DESCRIBE return SDP?
Which codecs are declared in SDP?
Did SETUP create RTP tracks?
Did PLAY start media delivery?
Are RTP sequence numbers increasing?
Are codec configuration records present?

RTSP transport can fail after ONVIF succeeds

ONVIF often uses HTTP or SOAP over a management port. RTSP media transport uses a different path. Even if the ONVIF request succeeds, RTP over UDP may be blocked.

This is common when:

The client is on another VLAN.
The camera is behind NAT.
A firewall allows TCP 80 or 8899 but blocks RTSP 554.
UDP RTP ports are not forwarded.
The camera sends RTP from unexpected source ports.
Multicast is enabled but IGMP is not configured.

If UDP transport fails, try RTSP over TCP interleaved transport. In TCP interleaved mode, RTSP control and RTP media share the RTSP TCP connection. This is often easier through firewalls, VPNs, and cloud relays.

But the right diagnosis is not "ONVIF failed." The right diagnosis is "ONVIF management succeeded, RTSP transport failed."

Authentication can differ between ONVIF and RTSP

Some cameras use the same credentials for ONVIF and RTSP. Others do not. A user account can have ONVIF permission but not RTSP live-view permission.

You may see:

RTSP/1.0 401 Unauthorized
WWW-Authenticate: Digest realm="IP Camera", nonce="..."

even though ONVIF discovery worked. That means the RTSP service is asking for credentials. If the client sends credentials and the camera continues to return 401, check account permissions, Digest authentication, URL encoding, and channel rights.

NVRs make this more confusing because the ONVIF device may be the NVR, while the RTSP stream path references a camera channel behind the NVR. The account may be allowed to query the NVR but not stream channel 1 main stream.

Main stream and sub-stream confusion

Many cameras expose multiple profiles:

Main stream: high resolution, high bitrate, often H.265.
Sub-stream: lower resolution, lower bitrate, often H.264.
Mobile stream: small frame size and lower frame rate.

ONVIF may return one of these profiles by default. The RTSP URL copied from a forum or vendor PDF may point to another. If the main stream is H.265 but the client supports only H.264, the sub-stream may work while the main stream fails.

Searches like "RTSP main stream not working sub stream works" often belong to this category. The problem is not discovery. It is profile selection, codec selection, bitrate, or transport behavior.

How to debug ONVIF works but RTSP fails

Use a layered checklist:

Confirm the camera's RTSP service is enabled.
Confirm the RTSP port, usually 554, is reachable from the client.
Get the ONVIF media profile and stream URI.
Normalize the RTSP URL for the network path you are actually using.
Add credentials carefully and URL-encode special characters.
Run RTSP OPTIONS and DESCRIBE.
Inspect authentication challenges and responses.
Inspect SDP for codec, payload type, clock rate, and track control URLs.
Compare UDP and TCP interleaved transport.
Confirm RTP packets arrive after PLAY.
Check RTP sequence continuity, timestamps, and payload type.
Test main stream and sub-stream separately.

This checklist prevents a common mistake: treating ONVIF discovery success as proof that media streaming should work automatically.

What the RTSP trace should show

A healthy RTSP flow usually looks like:

OPTIONS rtsp://camera/stream RTSP/1.0
RTSP/1.0 200 OK

DESCRIBE rtsp://camera/stream RTSP/1.0
RTSP/1.0 200 OK
Content-Type: application/sdp

SETUP rtsp://camera/stream/trackID=1 RTSP/1.0
RTSP/1.0 200 OK
Transport: RTP/AVP/TCP;unicast;interleaved=0-1

PLAY rtsp://camera/stream RTSP/1.0
RTSP/1.0 200 OK

If this sequence stops at DESCRIBE, the issue may be URL path, authentication, or SDP generation. If it stops at SETUP, inspect track control URLs and transport. If it reaches PLAY but no RTP arrives, inspect firewall, multicast, UDP ports, or camera media output.

Final diagnosis

When ONVIF works but RTSP fails, the camera is not necessarily broken and the URL is not necessarily wrong. ONVIF proves management visibility. RTSP proves media delivery. The useful diagnosis is to follow the stream from URL to authentication, SDP, transport setup, playback, and RTP evidence.

RTSP Inspector exists for that exact gap. It helps turn a vague "camera discovered but no video" report into a concrete protocol answer: which RTSP step failed, what the camera said, and whether media packets ever arrived.

Treat the ONVIF URI as a verified input, not a permanent truth

The ONVIF Media service can return a URI for a profile at a particular moment. That URI may change after a profile edit, firmware update, camera/NVR migration, or network address change. Preserve the profile token, device boundary, retrieval time, and sanitized URI before comparing it to a manually entered RTSP URL.

Observation	Bounded conclusion	Next check
ONVIF profile retrieved, RTSP `DESCRIBE` is 401	Management access and RTSP stream authorization differ	Capture the RTSP challenge and account/profile policy
ONVIF URI is reachable only on camera LAN	URI is locally valid but not necessarily routable from client	Compare actual host/NAT/VPN boundary without editing path blindly
`DESCRIBE` returns 404	Server was reached but did not expose that resource	Check profile state, camera vs NVR path, channel mapping, RTSP enablement
SDP returns but `SETUP` fails	URI is valid enough for description; track/transport differs	Preserve `a=control`, SETUP URL, and Transport header
PLAY succeeds but no RTP arrives	Control plane is healthy; media path remains unproven	Compare UDP/TCP interleaved and capture point
Sub stream works, main stream fails	ONVIF visibility is not a profile-equivalence proof	Compare each profile's SDP, codec, bitrate, and capacity

The RTSP main stream/sub-stream guide explains that controlled comparison. The important thing is that an ONVIF URI is evidence to test, not a URL that should be guessed, rewritten from a forum, or published with credentials.

Separate camera and NVR ownership in the case record

An ONVIF endpoint can describe an NVR channel while the RTP originates from a relayed camera source. The NVR may terminate ONVIF, RTSP authentication, SDP, and media independently. A direct-camera test and an NVR test are therefore different experiments even when they point at the same physical scene.

Case owner	Evidence to hand off
Camera administrator	Profile token, RTSP enablement, codec/profile state, direct-camera result
NVR administrator	Channel path, channel health, NVR realm/SDP, direct versus relayed result
Network owner	Client/camera/NVR address boundary, selected transport, first media-loss point
Integration team	ONVIF URI handling, RTSP method/status sequence, SDP/track parsing, decoder result

This prevents the common circular escalation where the NVR team says “ONVIF works” and the client team says “RTSP does not” without agreeing on which endpoint supplied which response.

ONVIF-to-RTSP QA workflow

Record the ONVIF endpoint, media profile identifier, and sanitized URI at the time it was returned.
Confirm which device owns the URI: direct camera, NVR, or proxy.
Run one clean RTSP OPTIONS/DESCRIBE sequence and retain the first non-expected response.
If SDP is returned, bind each control URL, codec, and payload mapping to the selected profile.
Compare UDP and TCP interleaved only as a controlled transport test.
Test a second profile only after documenting the first; do not mix main/sub results.

Does ONVIF discovery prove the RTSP port is open?

No. ONVIF management and RTSP can use different ports, services, accounts, and network rules. It proves a management endpoint responded, not that a media session can be set up.

Can RTSP Inspector prove an ONVIF URI is wrong?

It can show that the observed RTSP server rejected the URI at a specific method or that it described a different media session. It cannot prove hidden device configuration without camera/NVR-side evidence.

The useful result is a precise boundary such as “the NVR issued this profile URI, but the NVR returned 404 at DESCRIBE while the direct camera profile returned SDP.” That is actionable without overstating the root cause.

Practical questions

What is the fastest reliable way to start?

Use the smallest representative case, write down the expected result, and change one variable. Confirm the basic path before adding filters, effects, edits, automation, or a larger source. This creates a baseline that can be compared after every later decision.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: