Transporte não correspondente RTSP na resposta do servidor: depuração de respostas de configuração da câmera e incompatibilidade do modo RTP

Como depurar erros de transporte RTSP não correspondentes quando a câmera responde com um modo de transporte RTP diferente, canais intercalados errados, portas ausentes ou resposta SETUP incompatível.

transporte não correspondente rtsp, resposta do servidor, configuração rtsp, cabeçalho de transporte, rtp sobre tcp, udp rtp, diagnóstico rtsp

Algumas falhas de RTSP não retornam um 461 Unsupported Transport limpo. Em vez disso, o cliente relata "transporte não correspondente na resposta do servidor", "cabeçalho de transporte inválido", "servidor respondeu com transporte diferente" ou "incompatibilidade de transporte RTP". Isso geralmente acontece quando uma câmera aceita SETUP, mas responde com um cabeçalho Transport que não corresponde ao que o cliente solicitou ou ao que o cliente pode analisar.

Os usuários procuram por "transporte não correspondente RTSP na resposta do servidor", "transporte não correspondente ffmpeg", "incompatibilidade de transporte RTSP SETUP" e "cabeçalho de transporte da câmera inválido" porque o fluxo pode funcionar em um player e falhar em outro. A câmera não é simplesmente inacessível. A negociação de transporte RTSP é inconsistente.

O RTSP Inspector é útil porque os cabeçalhos de solicitação e resposta devem ser comparados diretamente.

Qual é a aparência de uma troca SETUP correspondente

O cliente solicita TCP intercalado:

Transport: RTP/AVP/TCP;unicast;interleaved=0-1

Server replies with compatible TCP interleaved transport:

Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=12345678

O cliente solicita UDP:

Transport: RTP/AVP;unicast;client_port=50000-50001

Server replies with UDP ports:

Transport: RTP/AVP;unicast;client_port=50000-50001;server_port=6970-6971

Se o servidor alterar o modo de transporte, omitir campos obrigatórios ou retornar valores malformados, os clientes estritos poderão falhar.

Casos comuns de incompatibilidade

Exemplos comuns incluem:

  • O cliente solicita TCP, o servidor responde UDP.
  • O cliente solicita UDP, o servidor responde TCP.
  • O servidor omite interleaved=.
  • O servidor retorna os números de canal errados.
  • O servidor retorna valores client_port diferentes da solicitação.
  • O servidor omite server_port para UDP.
  • O servidor retorna multicast quando o cliente solicita unicast.
  • O servidor retorna diversas alternativas de transporte em um formato não suportado.
  • O proxy reescreve a solicitação, mas não a resposta.

Alguns clientes toleram essas peculiaridades. Outros os rejeitam.

Por que um jogador funciona e outro falha

As implementações de RTSP variam. Um jogador tolerante pode aceitar uma resposta de transporte malformada ou inesperada e continuar. Uma ferramenta mais rigorosa pode falhar porque a resposta viola as suas expectativas.

Isso não significa automaticamente que o cliente estrito esteja errado. Isso significa que o comportamento da câmera ou do proxy deve ser inspecionado.

Para diagnósticos profissionais, preserve:

  • O cabeçalho de Transporte solicitado.
  • A resposta de transporte do servidor.
  • URL de rastreamento.
  • ID da sessão.
  • Se os pacotes RTP chegam depois.

Reescrita de proxy e retransmissão

Retransmissores com reconhecimento de RTSP podem reescrever cabeçalhos de transporte para conectar caminhos UDP e TCP. Se a reescrita estiver incompleta, o cliente downstream verá uma resposta que não corresponde à sua solicitação.

Exemplos:

  • O cliente solicita TCP do relé.
  • O relé solicita UDP da câmera.
  • O relé encaminha acidentalmente a resposta de transporte UDP da câmera downstream.

O cliente relata transporte não correspondente, embora a câmera e o relé tenham feito algo parcialmente válido.

Lista de verificação de depuração

Use este processo:

  1. Capture a solicitação SETUP.
  2. Capture a resposta SETUP.
  3. Compare o protocolo de transporte: UDP, TCP intercalado, multicast.
  4. Compare unicast/multicast.
  5. Compare portas de cliente, portas de servidor e canais intercalados.
  6. Verifique se um proxy/restreamer está no caminho.
  7. Verifique se os pacotes RTP posteriores seguem o mapeamento de resposta.
  8. Compare um jogador tolerante e um cliente estrito usando evidências de pacotes.
  9. Teste o URL direto da câmera, se possível.
  10. Relate o par de transporte exato ao fornecedor.

Diagnóstico final

"Transporte não correspondente na resposta do servidor" significa que a negociação SETUP produziu uma resposta de transporte incompatível ou malformada. A câmera ou o relé podem estar alterando o modo RTP, omitindo campos ou retornando valores que o cliente não pode usar com segurança.

O RTSP Inspector ajuda a tornar visível o par solicitação/resposta de transporte, que é a única maneira confiável de diagnosticar essa classe de falha de RTSP.