Diagnóstico de fluxo de câmera RTSP: um fluxo de trabalho sistemático para solução de problemas, da DESCRIÇÃO à reprodução
Os problemas da câmera RTSP geralmente seguem um padrão: a camada de conexão, a camada de controle ou a camada de mídia. Este fluxo de trabalho de diagnóstico mostra quais evidências coletar, qual estágio do protocolo está falhando e como ler SDP, RTP e RTCP para identificar a falha exata.
As falhas da câmera RTSP não precisam de suposições. O protocolo é dividido em camadas: "conexão (TCP/TLS), controle (DESCRIBE/SETUP/PLAY) e mídia (RTP/RTCP). Quando o fluxo é interrompido, uma dessas camadas é o problema. Seu trabalho é descobrir qual."
O modelo de três camadas
Cada problema RTSP se enquadra em um dos três grupos. Comece aqui antes de mergulhar em códigos de erro específicos:
Camada 1 — Conexão: O cliente consegue alcançar a câmera? Handshake TCP, negociação TLS, filtragem de portas, roteamento VPN. Se telnet camera-ip 554 não conectar, nada mais importa.
Camada 2 — Controle: A conexão funciona, mas os comandos RTSP falham. DESCREVER retorna 400/404/401. SETUP retorna 461. PLAY retorna 453. O plano de controle tem problemas em nível de protocolo: formato de URL, autenticação, negociação de transporte, gerenciamento de sessão.
Camada 3 — Mídia: O controle funciona perfeitamente, mas o vídeo/áudio está quebrado. Os pacotes RTP chegam, mas não podem ser decodificados. Desvio de carimbos de data/hora. Os quadros estão corrompidos. RTCP relata perda. O plano de mídia tem problemas de carga útil, codec ou qualidade de rede.
Tabela de triagem rápida
| Symptom | Camada Provável | Verifique primeiro |
|---|---|---|
| "Ligação recusada" | Camada 1 | Porta 554 acessível? Bloqueio de firewall? |
| 400 solicitação incorreta em DESCRIBE | Camada 2 | Formato de URL RTSP, codificação, cabeçalhos de proxy |
| 401 Não autorizado | Camada 2 | Parâmetros de autenticação resumidos, nome de usuário/senha |
| 461 Transporte Não Suportado | Camada 2 | Transporte UDP vs TCP, cabeçalho SETUP |
| DESCREVER OK, CONFIGURAÇÃO OK, sem vídeo | Camada 3 | Tipo de carga útil RTP, mapeamento de codec |
| O vídeo é reproduzido e depois congela | Camada 3 | Perda de pacotes, keepalive, tempo limite da sessão |
| Áudio e vídeo se distanciam | Camada 3 | Carimbo de data e hora RTP, incompatibilidade de taxa de clock |
As evidências que você deve coletar
Antes de diagnosticar qualquer problema de RTSP, capture estas cinco evidências:
- A resposta DESCRIBE completa — o SDP informa quais faixas existem, quais codecs estão em uso e quais tipos de carga útil estão atribuídos.
- A solicitação e resposta SETUP — O cabeçalho de transporte mostra UDP vs TCP, portas do cliente e IDs de canais intercalados.
- A resposta PLAY — Confirma que a sessão está ativa e o RTP está fluindo.
- Amostras de pacotes RTP — Byte do tipo de carga útil, números de sequência, carimbos de data/hora, SSRC.
- Relatórios de remetente/receptor RTCP — Contagens de perda de pacotes, jitter, atraso entre chegadas.
Sem isso, você está adivinhando. Com eles, o fracasso geralmente é óbvio.
Guias detalhados por erro
- Solicitação incorreta do RTSP 400: DESCRIBE URL com falha e malformado
- Transporte não suportado RTSP 461: falha na configuração
- Fragmentação H.264 FU-A: perda de pacotes RTP e remontagem NAL
- Incompatibilidade de tipo de carga dinâmica RTP: mapeamento de SDP e codec
- RTSP UDP RTP bloqueado: Firewall, NAT e VPN
- Desvio de carimbo de data/hora RTP: taxa de clock e sincronização de áudio/vídeo
- Tempo limite da sessão RTSP e Keepalive
- Relatórios de remetente RTCP: análise de instabilidade e perda de pacotes
Quando escalar
Se todas as três camadas forem verificadas - o TCP se conecta, os comandos RTSP são bem-sucedidos, os pacotes RTP chegam com tipos de carga corretos e carimbos de data e hora estáveis - mas o vídeo ainda parece errado, o problema provavelmente está no decodificador ou na camada de aplicativo, não no transporte RTSP. Nesse ponto, capture um PCAP curto, exporte alguns segundos de RTP e entregue-o à equipe de decodificação.