RTSP 400 Bad Request Fix: DESCRIBE fehlgeschlagen, fehlerhafte Kamera-URL und Header-Fehler

„RTSP/1.0 400 Bad Request“ bedeutet, dass die Kamera Ihre RTSP-Anfrage als fehlerhaft abgelehnt hat. Es ist kein Netzwerkproblem. Es ist kein Codec-Problem. Es handelt sich um ein Problem mit dem Anforderungsformat – und es kann behoben werden, sobald Sie die genaue Anforderung sehen, die die Kamera erhalten hat.

Schnelle Antwort: 30-Sekunden-Triage

1. Zuerst mit VLC testen. Wenn VLC funktioniert, erfassen Sie die genaue RTSP-Anfrage, die es sendet. Vergleichen Sie es mit Ihrem scheiternden Kunden.
2. Überprüfen Sie den URL-Pfad. Verschiedene Kameras verwenden völlig unterschiedliche Pfade für denselben RTSP-Stream. Das Kopieren einer URL von einer Kameramarke zu einer anderen ist die häufigste Ursache für 400 Fehler.
3. Check URL encoding. Special characters in passwords break RTSP URL parsing. Encode @ as %40, : as %3A, / as %2F.
4. Auf Proxy-Störungen prüfen. Direktes RTSP zur Kamera funktioniert, aber über einen Proxy werden 400 zurückgegeben? Der Proxy ändert RTSP-Header.

Wenn keine dieser Maßnahmen das Problem behebt, arbeiten Sie die folgenden detaillierten Abschnitte durch.

Stellen Sie zunächst sicher, dass die Kamera erreichbar ist

Überprüfen Sie vor dem Debuggen von RTSP die grundlegende Konnektivität:

# TCP reachability
nc -zv 192.168.1.100 554

# Or with telnet
telnet 192.168.1.100 554

# RTSP OPTIONS — the simplest RTSP request
# If this fails, the camera isn't speaking RTSP

If the port is closed, the problem is network/firewall, not RTSP.

Camera-specific URL formats

The most common cause of 400 errors: using the wrong URL path format for your camera brand. Each manufacturer uses different conventions:

Axis

rtsp://<ip>/axis-media/media.amp
rtsp://<ip>/mpeg4/media.amp
rtsp://<ip>:554/axis-media/media.amp?videocodec=h264

Dahua

rtsp://<user>:<pass>@<ip>:554/cam/realmonitor?channel=1&subtype=0
rtsp://<user>:<pass>@<ip>:554/cam/realmonitor?channel=1&subtype=1

• subtype=0: main stream
• subtype=1: sub stream

Hikvision

rtsp://<user>:<pass>@<ip>:554/Streaming/Channels/101
rtsp://<user>:<pass>@<ip>:554/Streaming/Channels/102

• 101: channel 1, main stream
• 102: channel 1, sub stream
• 201: channel 2, main stream

Generic / ONVIF

rtsp://<ip>:554/stream1
rtsp://<ip>:554/live
rtsp://<ip>:554/h264
rtsp://<ip>:554/h265
rtsp://<ip>:554/profile1/media.smp
rtsp://<ip>/onvif1
rtsp://<ip>/onvif2

Testing with ffmpeg

# Test DESCRIBE only (don't decode)
ffmpeg -rtsp_transport tcp -i "rtsp://user:pass@192.168.1.100:554/stream1" -t 1 -f null -

# Die ausführliche Ausgabe zeigt den genauen RTSP-Austausch
ffmpeg -loglevel debug -rtsp_transport tcp -i "rtsp://..." -t 1 -f null - 2>&1 | grep -E "DESCRIBE|SETUP|response"

URL-Kodierung: der stille 400-Trigger

When a password contains special characters, the RTSP URL becomes ambiguous. The @ separates credentials from the host, so a password containing @ breaks the parsing.

WRONG: rtsp://admin:pa@ss@192.168.1.100/stream1
       parser sees: user=admin, pass=pa, host=ss@192.168.1.100

RIGHT:  rtsp://admin:pa%40ss@192.168.1.100/stream1
       parser sees: user=admin, pass=pa@ss, host=192.168.1.100

Characters that must be encoded in RTSP URLs:

Character	Encoding	Example
@	%40	user@domain → user%40domain
:	%3A	pass:word → pass%3Aword
/	%2F	pass/word → pass%2Fword
?	%3F	in query values
#	%23	in query values
%	%25	literal percent
&	%26	in query values (if not separating parameters)
space	%20	in query values

Config files often add another layer of escaping. A URL in a YAML file may need both YAML escaping AND URL encoding.

Full diagnostic decision tree

RTSP returns 400 Bad Request
│
├─ Is port 554 reachable?
│  ├─ NO → Fix network/firewall. Not an RTSP issue.
│  └─ YES → Continue
│
├─ Does VLC play the same URL?
│  ├─ YES, VLC works → Capture VLC's exact request. Compare with your client.
│  │   Differences in headers, URI format, or auth will point to the fix.
│  └─ NO, VLC also fails → Problem is in the URL or camera config
│
├─ Check the URL path
│  ├─ Wrong manufacturer format → Use correct format for your camera brand
│  ├─ Query parameters missing → Add required parameters (channel, subtype)
│  └─ Path contains unencoded special chars → URL-encode credentials
│
├─ Check DESCRIBE headers
│  ├─ Missing Accept: application/sdp → Add it
│  ├─ Extra HTTP headers (via proxy) → Remove proxy from RTSP path
│  └─ Malformed Authorization → Fix Digest auth parameters
│
├─ Check CSeq and RTSP syntax
│  ├─ Missing CSeq → Add sequential CSeq header
│  ├─ Wrong RTSP version → Use RTSP/1.0
│  └─ CRLF formatting wrong → Ensure \r\n line endings
│
└─ Still failing?
   ├─ Try ONVIF discovery to get the correct RTSP URL
   ├─ Check camera firmware version (older firmware may have stricter parsing)
   └─ Test with a known-working RTSP client as baseline

Reverse-Proxy: die versteckte 400-Ursache

RTSP über einen HTTP-Reverse-Proxy ist fragil. Für HTTP entwickelte Proxys können:

1. HTTP-spezifische Header einfügen (Host, X-Forwarded-For, User-Agent)
2. Schreiben Sie den Anforderungs-URI neu
3. Puffern und ändern Sie das TCP-Verbindungsverhalten
4. Beeinträchtigung des dauerhaften Verbindungsmodells von RTSP

Symptome einer Proxy-Interferenz:

• RTSP direkt an die Kamera senden: funktioniert
• RTSP über Proxy: 400 Bad Request – Kameraprotokolle zeigen „fehlerhafte Anfrage“ mit zusätzlichen Headern, die im direkten Fluss nicht vorhanden sind

Fix: Umgehen Sie entweder den Proxy für RTSP-Verkehr, verwenden Sie einen RTSP-fähigen Proxy oder konfigurieren Sie den Proxy so, dass er den RTSP-Verkehr unverändert weiterleitet.

Randfälle der Authentifizierung

Die meisten Authentifizierungsprobleme geben 401 zurück, aber ein fehlerhafter Autorisierungsheader kann 400 zurückgeben.

Das Muster „funktioniert beim ersten Versuch, schlägt beim erneuten Versuch fehl“:

1. Der Client sendet unauthentifiziertes DESCRIBE
2. Kamera gibt 401 mit Digest-Challenge zurück (Realm, Nonce)
3. Der Client berechnet die Digest-Antwort
4. Der Client sendet authentifiziertes DESCRIBE mit Autorisierungsheader
5. Die Kamera gibt 400 zurück

Dies geschieht, wenn die Berechnung der Digest-Antwort falsch ist – der in der Digest-Berechnung verwendete URI stimmt nicht mit dem tatsächlichen Anforderungs-URI überein, die Nonce war veraltet oder Sonderzeichen im Passwort wurden vor dem Hashing nicht korrekt codiert.

Prüfen: Vergleichen Sie den Anforderungs-URI im Authorization-Header mit dem tatsächlichen Anforderungs-URI auf der Leitung. Bei der Digest-Authentifizierung ist der URI Teil des Hashs – wenn sie nicht zeichenweise (einschließlich Codierung) übereinstimmen, ist die Antwort ungültig.

Wenn die Kamera einfach kaputt ist

Einige Kameras verfügen über fehlerhafte RTSP-Implementierungen. Wenn Sie alles oben überprüft haben und immer noch 400 erhalten:

1. Suchen Sie nach Firmware-Updates
2. Testen Sie mit der herstellereigenen Client-Software
3. Probieren Sie ONVIF als alternativen Erkennungs- und Streaming-Pfad aus
4. Wenn die Kamera mit ihrer eigenen App, aber nicht mit standardkonformen RTSP-Clients funktioniert, ist der RTSP-Stack der Kamera nicht konform

Melden Sie einen Fehler beim Kamerahersteller. Geben Sie die genaue RTSP DESCRIBE-Anfrage und -Antwort an. Eine ordnungsgemäße RTSP-Implementierung sollte für eine gültige, wohlgeformte Anfrage unabhängig vom URL-Pfad nicht 400 zurückgeben, sondern 404.