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

It is common for an IP camera to appear correctly in ONVIF discovery while the RTSP URL still fails. The device is visible on the network, the camera name and model are detected, maybe even the profiles are listed, but the actual video stream does not open. Users search for "ONVIF works but RTSP fails", "camera discovered but no RTSP video", or "how to find RTSP URL from ONVIF" because discovery success feels like it should guarantee streaming success.

It does not.

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.

RtspInspector 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.

RtspInspector 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:

1. Confirm the camera's RTSP service is enabled.
2. Confirm the RTSP port, usually 554, is reachable from the client.
3. Get the ONVIF media profile and stream URI.
4. Normalize the RTSP URL for the network path you are actually using.
5. Add credentials carefully and URL-encode special characters.
6. Run RTSP OPTIONS and DESCRIBE.
7. Inspect authentication challenges and responses.
8. Inspect SDP for codec, payload type, clock rate, and track control URLs.
9. Compare UDP and TCP interleaved transport.
10. Confirm RTP packets arrive after PLAY.
11. Check RTP sequence continuity, timestamps, and payload type.
12. 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.

RtspInspector 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.