RTSP 401 Unauthorized and 404 Not Found: Diagnosing Camera URL and Authentication Failures

Two RTSP errors appear in support tickets again and again: 401 Unauthorized and 404 Not Found. They sound simple. One looks like a login problem, the other looks like a bad URL. In real camera deployments, both can be more subtle.

A camera may accept the same credentials in the web UI but reject RTSP. A recorder may expose different paths for main stream and sub stream. An ONVIF scan may discover a URL that later changes. A vendor may require a channel number, stream suffix, or profile token. Some cameras also return misleading status codes when the path is too long, the stream is disabled, or an authentication mode is incompatible with the client.

For Google searches, the user query is usually direct: "RTSP 401 unauthorized camera", "RTSP 404 not found", "VLC works but NVR says no signal", or "ONVIF camera RTSP URL not working." A useful article should not pretend there is one magic URL. It should show how to collect evidence.

Start with the RTSP Method That Failed

Do not record only the final error. Record which RTSP method returned it:

• OPTIONS
• DESCRIBE
• SETUP
• PLAY

If OPTIONS fails with 401, authentication or server policy is blocking the session before metadata is requested. If DESCRIBE fails with 401, the camera may accept the connection but reject access to that stream path. If DESCRIBE returns 404, the path usually does not map to a stream profile. If SETUP fails after a successful DESCRIBE, the URL may be valid but the track control path, transport mode, or media profile has a problem.

This distinction matters because the next action changes. Credential fixes will not repair a missing stream path. Changing the URL suffix will not repair a digest-auth mismatch.

Separate Credentials from Stream Path

A clean troubleshooting matrix looks like this:

• same username/password works in camera web UI
• RTSP service is enabled
• RTSP port is open from the client network
• URL path matches the vendor's main stream or sub stream pattern
• stream profile is enabled on the camera
• authentication mode is compatible with the client
• special characters in password are encoded correctly

Password characters are a frequent source of false failures. A password that contains @, :, /, ?, #, or spaces may need URL encoding when embedded in an RTSP URL. A better test is to use a client that sends credentials separately rather than relying on an inline URL.

Why 404 Often Means Profile or Path, Not Network

404 Not Found means the server was reached and understood the request enough to reject the resource. For camera streams, this often points to one of these:

• wrong channel number
• wrong stream suffix
• main stream disabled
• sub stream disabled
• recorder path differs from camera path
• ONVIF profile token changed
• vendor-specific access name required
• stream exists only after enabling RTSP in settings

The most useful evidence is the DESCRIBE request URI and the response status. If the camera returns 404 before SDP, there is no media session yet. Do not jump to RTP loss or codec debugging before confirming that the URL maps to a real stream.

ONVIF Discovery Helps, but It Is Not the Same as Proof

ONVIF discovery can provide stream URIs and profile information, but the discovered RTSP URI still needs to be tested. Some systems expose ONVIF correctly while RTSP authentication or path behavior is different. Others return a URI that is valid only for a profile that later gets disabled or changed.

The diagnostic sequence should be:

1. discover or enter the RTSP URL
2. run OPTIONS and DESCRIBE
3. capture status codes and headers
4. inspect whether SDP is returned
5. only then inspect SETUP, PLAY, RTP, and codec evidence

That ordering prevents an engineer from treating every failure as a "camera offline" issue.

How RtspInspector Should Be Used

RtspInspector is not a player, an ONVIF manager, or a camera discovery product. Its role is to make the RTSP transaction visible enough to explain what happened. For 401 and 404 cases, the useful output is:

• request URI
• failed method
• status code
• authentication boundary
• whether SDP was returned
• whether the failure happened before media negotiation
• recommended next owner: credentials, camera profile, vendor URL format, network port, or stream enablement

That is exactly the evidence a field integrator or video platform engineer needs before escalating to the camera vendor or changing recorder settings blindly.

When a support ticket says "RTSP not working," ask for the method, status code, and SDP boundary. That turns a generic complaint into a fixable case.