RTSP 400 Bad Request on DESCRIBE: Camera URL, Headers, Encoding, and Proxy Troubleshooting

RTSP/1.0 400 Bad Request is a frustrating camera error because it often appears before the stream reaches any media stage. The camera is online. The RTSP port may be reachable. The client sends a request, often DESCRIBE, and the camera rejects it as malformed. Users search for "RTSP 400 Bad Request", "method DESCRIBE failed 400", "camera RTSP bad request", "Axis RTSP DESCRIBE 400", "Dahua RTSP 400 bad request", and "RTSP URL works in VLC but not app" because the error sounds generic but usually points to a very specific request-shape problem.

This is not a decoder failure. It is not RTP packet loss. It is not H.264 SPS/PPS. A 400 Bad Request during DESCRIBE means the camera did not accept the RTSP control request as valid.

RtspInspector is useful here because the raw RTSP request matters: request URI, path, query string, CSeq, headers, authentication header, URL encoding, proxy-injected headers, and the exact method sequence.

What DESCRIBE is supposed to do

In a normal RTSP flow, the client asks the camera to describe the stream:

DESCRIBE rtsp://192.168.1.50:554/stream1 RTSP/1.0
CSeq: 2
Accept: application/sdp

The camera should return SDP:

RTSP/1.0 200 OK
CSeq: 2
Content-Type: application/sdp

If the camera returns 400 Bad Request, it did not like the request. The problem may be the URL path, query parameters, missing or unexpected headers, authentication format, request target, RTSP version, proxy behavior, or vendor-specific syntax.

Wrong stream path

Many cameras use vendor-specific RTSP paths. A path copied from another model may not work.

Examples of common patterns:

/stream1
/live
/h264
/h265
/cam/realmonitor?channel=1&subtype=0
/Streaming/Channels/101
/profile1/media.smp

Some devices return 404 Not Found for a wrong path. Others return 400 Bad Request if the path format is not accepted. A query string with missing parameters can also trigger 400.

If the URL contains ?channel=1&subtype=0, make sure the & is preserved correctly. Shells, config files, YAML, JSON, and web forms can alter special characters if they are not escaped or quoted.

URL encoding and special characters

RTSP URLs often include credentials:

rtsp://user:password@camera/stream

Passwords with @, :, /, ?, #, %, or & can break parsing. A malformed credential section can make the request URI invalid before authentication even begins.

For example:

rtsp://admin:pa@[email protected]/stream1

should use encoded password characters:

rtsp://admin:pa%[email protected]/stream1

When one client works and another fails, compare the actual request sent on the wire, not only the URL shown in the UI.

Missing Accept header

Some cameras are strict about DESCRIBE. They expect:

Accept: application/sdp

If the client omits it or sends unusual values, the camera may reject the request. Other cameras are lenient. This is why compatibility varies across VLC, ffmpeg, surveillance systems, and custom clients.

Strict RTSP servers can also reject unexpected HTTP-style headers. If a reverse proxy injects headers meant for HTTP, the camera may respond with 400.

Reverse proxy and gateway problems

RTSP is not plain HTTP. Putting RTSP through an HTTP reverse proxy can change request lines, headers, connection behavior, and authentication. A camera may reject requests that include browser-like headers, rewritten paths, changed host values, or connection handling that does not match RTSP expectations.

Symptoms:

• Direct LAN RTSP works.
• RTSP through proxy returns 400.
• Web UI through proxy works.
• Camera logs show malformed request.
• Request contains headers not present in the direct client flow.

The fix may require RTSP-aware proxying or a different network design. The diagnostic evidence is the difference between the direct RTSP request and proxied RTSP request.

Authentication can still be involved

Most authentication problems return 401 Unauthorized, but malformed Authorization headers can produce 400. Digest authentication is sensitive to URI, realm, nonce, algorithm, and response value.

If the first unauthenticated DESCRIBE gets a proper 401, but the authenticated retry gets 400, inspect the Authorization header and URI used in Digest calculation.

Common issues:

• URI in Digest header does not match request URI.
• Password special characters were not encoded.
• Client reused stale nonce incorrectly.
• Camera firmware is strict about header formatting.

CSeq and RTSP syntax

RTSP requests should include CSeq. Some cameras reject missing or malformed CSeq headers. Others behave unpredictably if CSeq is duplicated, not numeric, or reset in the middle of a persistent connection.

Check:

• Request line uses RTSP/1.0.
• CSeq exists and increments logically.
• Header lines use correct CRLF format.
• URI is absolute if camera expects absolute URI.
• Request does not mix HTTP and RTSP syntax.

Debug checklist

Use this process:

1. Identify which method receives 400: OPTIONS, DESCRIBE, SETUP, or PLAY.
2. Capture the exact request line and headers.
3. Verify the stream path for the camera brand/model.
4. URL-encode credentials and query parameters.
5. Confirm Accept: application/sdp on DESCRIBE.
6. Compare direct RTSP with proxied RTSP.
7. Inspect Authorization header if 400 appears after 401.
8. Check CSeq and request syntax.
9. Test main stream and sub-stream paths separately.
10. Avoid debugging RTP until DESCRIBE returns SDP.

Final diagnosis

RTSP 400 Bad Request on DESCRIBE is usually a request-format problem: wrong path, malformed URL, bad encoding, strict header expectation, proxy mutation, or malformed authentication retry. The camera is telling you it did not accept the RTSP request shape.

RtspInspector helps by exposing the exact RTSP control messages so the fix can target the URL and request syntax instead of wasting time on playback, codec, or RTP-layer guesses.