Correção de solicitação incorreta do RTSP 400: DESCRIBE falhou, URL da câmera malformado e erros de cabeçalho

RTSP/1.0 400 Bad Request significa que a câmera rejeitou sua solicitação RTSP como malformada. Não é um problema de rede. Não é um problema de codec. É um problema de formato de solicitação – e pode ser corrigido quando você vê a solicitação exata que a câmera recebeu.

Resposta rápida: triagem de 30 segundos

1. Teste primeiro com o VLC. Se o VLC funcionar, capture a solicitação RTSP exata que ele envia. Compare com o seu cliente com falha.
2. Verifique o caminho do URL. Câmeras diferentes usam caminhos completamente diferentes para o mesmo fluxo RTSP. Copiar um URL de uma marca de câmera para outra é a causa número 1 de 400 erros.
3. Check URL encoding. Special characters in passwords break RTSP URL parsing. Encode @ as %40, : as %3A, / as %2F.
4. Verifique se há interferência de proxy. O RTSP direto para a câmera funciona, mas através de um proxy retorna 400? O proxy está alterando os cabeçalhos RTSP.

Se nada disso resolver o problema, siga as seções detalhadas abaixo.

Primeiro: verifique se a câmera está acessível

Antes de depurar o RTSP, confirme a conectividade 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 -

# A saída detalhada mostra a troca RTSP exata
ffmpeg -loglevel debug -rtsp_transport tcp -i "rtsp://..." -t 1 -f null - 2>&1 | grep -E "DESCREVA|CONFIGURAÇÃO|resposta"

Codificação de URL: o gatilho 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 reverso: a causa 400 oculta

O RTSP por meio de um proxy reverso HTTP é frágil. Os proxies projetados para HTTP podem:

1. Injetar cabeçalhos específicos de HTTP (Host, X-Forwarded-For, User-Agent)
2. Reescreva o URI da solicitação
3. Buffer e alterar o comportamento da conexão TCP
4. Interferir no modelo de conexão persistente do RTSP

Sintomas de interferência de proxy:

• RTSP direto para a câmera: funciona
• RTSP através de proxy: 400 solicitações incorretas
• Os registros da câmera mostram "solicitação malformada" com cabeçalhos extras não presentes no fluxo direto

Correção: Ignore o proxy para tráfego RTSP, use um proxy compatível com RTSP ou configure o proxy para passar o tráfego RTSP sem modificações.

Casos extremos de autenticação

A maioria dos problemas de autenticação retorna 401, mas um cabeçalho de autorização malformado pode retornar 400.

O padrão "funciona na primeira tentativa, falha na nova tentativa":

1. Cliente envia DESCRIBE não autenticado
2. A câmera retorna 401 com o desafio Digest (reino, nonce)
3. O cliente calcula a resposta Digest
4. Cliente envia DESCRIBE autenticado com cabeçalho de autorização
5. Câmera retorna 400

Isso acontece quando o cálculo da resposta Digest está errado — o URI usado no cálculo Digest não corresponde ao URI da solicitação real, ou o nonce estava obsoleto ou os caracteres especiais na senha não foram codificados corretamente antes do hash.

Verificar: Compare o URI da solicitação no cabeçalho de autorização com o URI da solicitação real na transmissão. Na autenticação Digest, o URI faz parte do hash – se eles não corresponderem caractere por caractere (incluindo codificação), a resposta será inválida.

Quando a câmera está quebrada

Algumas câmeras possuem implementações RTSP com bugs. Se você verificou tudo acima e ainda obteve 400:

1. Verifique se há atualizações de firmware
2. Teste com o software cliente do próprio fabricante
3. Experimente o ONVIF como um caminho alternativo de descoberta e streaming
4. Se a câmera funcionar com seu próprio aplicativo, mas não com clientes RTSP compatíveis com os padrões, a pilha RTSP da câmera não será compatível

Registre um bug com o fornecedor da câmera. Inclua a solicitação e resposta exatas do RTSP DESCRIBE. Uma implementação RTSP adequada não deve retornar 400 para uma solicitação válida e bem formada, independentemente do caminho da URL — ela deve retornar 404.