Correzione di richieste errate RTSP 400: DESCRIBE non riuscita, URL della fotocamera non valido ed errori di intestazione

"RTSP/1.0 400 Bad Request" significa che la telecamera ha rifiutato la richiesta RTSP in quanto non valida. Non è un problema di rete. Non è un problema di codec. È un problema relativo al formato della richiesta ed è risolvibile una volta visualizzata la richiesta esatta ricevuta dalla fotocamera.

Risposta rapida: triage di 30 secondi

1. Prima prova con VLC. Se VLC funziona, acquisisci l'esatta richiesta RTSP che invia. Confrontalo con il tuo cliente in fallimento.
2. Controlla il percorso dell'URL. Telecamere diverse utilizzano percorsi completamente diversi per lo stesso flusso RTSP. La copia di un URL da una marca di fotocamera a un'altra è la causa numero 1 di 400 errori.
3. Check URL encoding. Special characters in passwords break RTSP URL parsing. Encode @ as %40, : as %3A, / as %2F.
4. Verificare l'interferenza del proxy. L'RTSP diretto alla telecamera funziona ma tramite un proxy restituisce 400? Il proxy sta alterando le intestazioni RTSP.

Se nessuno di questi risolve il problema, procedi con le sezioni dettagliate di seguito.

Primo: verifica che la telecamera sia raggiungibile

Prima di eseguire il debug di RTSP, conferma la connettività di base:

# 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 -

# L'output dettagliato mostra l'esatto scambio RTSP
ffmpeg -loglevel debug -rtsp_transport tcp -i "rtsp://..." -t 1 -f null - 2>&1 | grep -E "DESCRIVI|IMPOSTAZIONE|risposta"

Codifica URL: il trigger silenzioso 400

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

Proxy inverso: la causa nascosta dei 400

RTSP tramite un proxy inverso HTTP è fragile. I proxy progettati per HTTP possono:

1. Iniettare intestazioni specifiche HTTP (Host, X-Forwarded-For, User-Agent)
2. Riscrivere l'URI della richiesta
3. Buffer e altera il comportamento della connessione TCP
4. Interferire con il modello di connessione persistente di RTSP

Sintomi di interferenza proxy:

• RTSP diretto alla telecamera: funziona
• RTSP tramite proxy: 400 Richiesta errata
• I registri della telecamera mostrano "richiesta non valida" con intestazioni aggiuntive non presenti nel flusso diretto

Correzione: ignorare il proxy per il traffico RTSP, utilizzare un proxy compatibile con RTSP o configurare il proxy per passare il traffico RTSP senza modifiche.

Casi limite di autenticazione

La maggior parte dei problemi di autenticazione restituiscono 401, ma un'intestazione di autorizzazione non corretta può restituire 400.

Il modello "funziona al primo tentativo, fallisce al nuovo tentativo":

1. Il client invia DESCRIBE non autenticato
2. La fotocamera restituisce 401 con la sfida Digest (reame, nonce)
3. Il client calcola la risposta Digest
4. Il client invia DESCRIBE autenticato con intestazione di autorizzazione
5. La fotocamera restituisce 400

Ciò accade quando il calcolo della risposta Digest è errato: l'URI utilizzato nel calcolo del Digest non corrisponde all'URI della richiesta effettiva, oppure il nonce era obsoleto oppure i caratteri speciali nella password non erano codificati correttamente prima dell'hashing.

Verifica: confronta l'URI della richiesta nell'intestazione dell'autorizzazione con l'URI della richiesta effettiva in transito. Nell'autenticazione Digest, l'URI fa parte dell'hash: se non corrispondono carattere per carattere (inclusa la codifica), la risposta non è valida.

Quando la fotocamera è semplicemente rotta

Alcune fotocamere hanno implementazioni RTSP difettose. Se hai controllato tutto sopra e ottieni ancora 400:

1. Controlla gli aggiornamenti del firmware
2. Testare con il software client del produttore
3. Prova ONVIF come percorso alternativo di scoperta e streaming
4. Se la fotocamera funziona con la propria app ma non con client RTSP conformi agli standard, lo stack RTSP della fotocamera non è conforme

Segnala un bug al venditore della fotocamera. Includere la richiesta e la risposta RTSP DESCRIBE esatte. Una corretta implementazione RTSP non dovrebbe restituire 400 per una richiesta valida e ben formata indipendentemente dal percorso URL: dovrebbe restituire 404.