Solución de solicitud incorrecta RTSP 400: DESCRIBE fallida, URL de cámara mal formada y errores de encabezado

RTSP/1.0 400 Bad Request significa que la cámara rechazó su solicitud RTSP por considerarla mal formada. No es un problema de red. No es un problema de códec. Es un problema de formato de solicitud y se puede solucionar una vez que vea la solicitud exacta que recibió la cámara.

Respuesta rápida: clasificación en 30 segundos

1. Pruebe primero con VLC. Si VLC funciona, capture la solicitud RTSP exacta que envía. Compárelo con su cliente fallido.
2. Compruebe la ruta URL. Diferentes cámaras utilizan rutas completamente diferentes para la misma transmisión RTSP. Copiar una URL de una marca de cámara a otra es la causa número uno de errores 400.
3. Check URL encoding. Special characters in passwords break RTSP URL parsing. Encode @ as %40, : as %3A, / as %2F.
4. Compruebe si hay interferencias de proxy. El RTSP directo a la cámara funciona pero a través de un proxy devuelve 400? El proxy está alterando los encabezados RTSP.

Si ninguno de estos soluciona el problema, consulte las secciones detalladas a continuación.

Primero: verifique que la cámara sea accesible

Antes de depurar RTSP, confirme la conectividad básica:

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

# La salida detallada muestra el intercambio RTSP exacto
ffmpeg -loglevel debug -rtsp_transport tcp -i "rtsp://..." -t 1 -f null - 2>&1 | grep -E "DESCRIBIR|CONFIGURAR|respuesta"

Codificación de URL: el activador silencioso 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 oculta 400

RTSP a través de un proxy inverso HTTP es frágil. Los servidores proxy diseñados para HTTP pueden:

1. Inyecte encabezados específicos de HTTP (Host, X-Forwarded-For, User-Agent)
2. Reescribe el URI de solicitud
3. Almacenar en buffer y alterar el comportamiento de la conexión TCP
4. Interferir con el modelo de conexión persistente de RTSP

Síntomas de interferencia de proxy:

• RTSP directo a la cámara: funciona
• RTSP a través de proxy: 400 Solicitud incorrecta
• Los registros de la cámara muestran una "solicitud con formato incorrecto" con encabezados adicionales que no están presentes en el flujo directo

Solución: Omita el proxy para el tráfico RTSP, utilice un proxy compatible con RTSP o configure el proxy para que pase el tráfico RTSP sin modificaciones.

Casos extremos de autenticación

La mayoría de los problemas de autenticación devuelven 401, pero un encabezado de autorización con formato incorrecto puede devolver 400.

El patrón "funciona en el primer intento, falla al reintentar":

1. El cliente envía DESCRIBIR no autenticado
2. La cámara devuelve 401 con el desafío Digest (reino, nonce)
3. El cliente calcula la respuesta del resumen
4. El cliente envía DESCRIBE autenticado con el encabezado de Autorización
5. La cámara devuelve 400

Esto sucede cuando el cálculo de la respuesta del resumen es incorrecto: el URI utilizado en el cálculo del resumen no coincide con el URI de la solicitud real, o el nonce estaba obsoleto, o los caracteres especiales en la contraseña no estaban codificados correctamente antes del hash.

Compruebe: Compare el URI de solicitud en el encabezado de Autorización con el URI de solicitud real en el cable. En la autenticación implícita, el URI es parte del hash; si no coinciden carácter por carácter (incluida la codificación), la respuesta no es válida.

Cuando la cámara simplemente está rota

Algunas cámaras tienen implementaciones RTSP defectuosas. Si has marcado todo lo anterior y aún obtienes 400:

1. Buscar actualizaciones de firmware
2. Prueba con el software cliente del propio fabricante.
3. Pruebe ONVIF como ruta alternativa de descubrimiento y transmisión
4. Si la cámara funciona con su propia aplicación pero no con clientes RTSP que cumplen con los estándares, la pila RTSP de la cámara no es compatible

Presente un error al proveedor de la cámara. Incluya la solicitud y respuesta RTSP DESCRIBIR exactas. Una implementación RTSP adecuada no debería devolver 400 para una solicitud válida y bien formada, independientemente de la ruta URL; debería devolver 404.