2026-06-02

Transmissões de câmera RTSP multicast e UDP: por que a descoberta funciona, mas a mídia não chega

Como diagnosticar fluxos de câmera RTSP onde a descoberta ONVIF, o controle de tráfego ou a configuração multicast funcionam, mas a mídia RTP nunca chega.

As redes de câmeras geralmente combinam RTSP unicast, RTP multicast, descoberta ONVIF, VLANs, switches PoE, firewalls e NVRs. O sintoma pode ser confuso: "a câmera é descoberta, a URL RTSP é válida, DESCRIBE retorna SDP, mas os pacotes de mídia nunca chegam." Este é um limite de protocolo clássico. A descoberta não é mídia. O controle RTSP não é entrega RTP. Acessibilidade multicast não é o mesmo que acessibilidade unicast.

ONVIF Discovery é uma conversa UDP diferente

A descoberta ONVIF normalmente usa multicast UDP em um endereço e porta de descoberta. Se a descoberta for bem-sucedida, isso prova que pelo menos um caminho de controle no estilo multicast funcionou para a descoberta. Isso não prova que grupos multicast RTP sejam permitidos, unidos, roteados ou encaminhados.

Erros comuns:

assumindo que a descoberta do ONVIF prova o caminho da mídia RTP
testando de uma VLAN diferente do NVR
permitindo TCP 554, mas bloqueando portas de mídia UDP
bloqueando o tráfego do grupo multicast no switch
esquecendo a espionagem IGMP ou o comportamento do questionador
testando o URL direto da câmera enquanto o NVR usa um caminho diferente

O relatório deve nomear o tipo de tráfego: descoberta, controle RTSP, mídia RTP ou feedback RTCP.

Multicast requer associação ao grupo

Para RTP multicast, o receptor deve ingressar no grupo multicast. Switches e roteadores podem precisar do comportamento IGMP para encaminhar o tráfego corretamente. Se o multicast estiver desabilitado, filtrado ou configurado incorretamente, o controle RTSP ainda poderá funcionar enquanto a mídia nunca chega.

Evidência útil:

SDP declara endereço multicast ou transporte unicast
O cabeçalho de transporte SETUP confirma o modo solicitado
interface receptora e VLAN
endereço de grupo multicast
se os pacotes RTP alcançam o ponto de captura
se RTCP aparece
se o modo unicast se comporta de maneira diferente

Se o RTP unicast funcionar e o multicast não, o problema provavelmente é a configuração multicast da rede, não o H.264.

A mídia UDP pode ser bloqueada enquanto o controle TCP funciona

Os firewalls geralmente permitem TCP 554 ou 8554, mas bloqueiam portas UDP. O NAT também pode quebrar a mídia UDP. Isso cria um padrão comum:

A conexão TCP foi bem-sucedida
DESCRIBE foi bem-sucedido
SETUP foi bem-sucedido
PLAY foi bem-sucedido
nenhum RTP chega

Mudar para TCP intercalado é uma comparação útil. Se o TCP intercalado funcionar, o servidor RTSP e o codec provavelmente estão funcionais. O caminho da mídia UDP precisa de atenção.

O que capturar

Para casos multicast e UDP, capture:

Cabeçalhos de solicitação e resposta RTSP
Endereço de mídia SDP e informações de rastreamento
cabeçalho de transporte de SETUP
portas cliente e servidor
grupo multicast
Chegada ou ausência de pacote RTP
Chegada ou ausência de pacote RTCP
mesmo teste sobre TCP intercalado

Essa evidência ajuda a equipe de rede a corrigir roteamento, firewall ou encaminhamento multicast, em vez de solicitar ao fornecedor da câmera que altere as configurações do codec.

Onde o inspetor RTSP se encaixa

O RTSP Inspector foi desenvolvido para evidências de protocolo, não para suposições visuais. Em casos multicast e UDP, seu valor mostra onde o fluxo parou:

a descoberta funcionou, mas o RTSP falhou
O RTSP funcionou mas o RTP nunca chegou
O UDP falhou, mas o TCP intercalado funcionou
grupo multicast foi declarado, mas nenhum pacote chegou ao cliente
O RTP chegou, mas a preparação do codec falhou

São fracassos diferentes. A janela do player não pode diferenciá-los com segurança. Um relatório de protocolo pode.

Evidência reproduzível para “Transmissões de câmera RTSP multicast e UDP: por que a descoberta funciona, mas a mídia não chega”

A resposta direta é que uma tela preta ou um único código não prova a origem da falha. Um diagnóstico confiável liga pedido e resposta RTSP, transporte negociado, sessão válida e depois números de sequência RTP, timestamps e sinais RTCP. Em “Transmissões de câmera RTSP multicast e UDP: por que a descoberta funciona, mas a mídia não chega”, comece pela camada mais próxima do sintoma, mas mantenha uma cronologia comum para não confundir controle, rede e decodificação.

Antes de alterar câmera, firewall ou VMS, crie um teste de referência pequeno. Registre URL RTSP sem senha, horário, caminho, Transport solicitado, resposta do servidor e chegada do primeiro pacote de mídia. Teste UDP e TCP interleaved separadamente quando disponíveis. Não mude caminho, credenciais e transporte juntos; caso a segunda tentativa funcione, será necessário identificar a variável decisiva.

Camada	Evidência a preservar	Pergunta
RTSP	método, estado, cabeçalhos, CSeq e Session	O servidor aceitou exatamente a operação?
SDP	control, payload type, clock rate e codec	A faixa esperada foi descrita?
Transport	client_port, server_port ou interleaved	Os dois lados usam o mesmo canal?
RTP	SSRC, sequência, timestamp e marker	As unidades chegam em ordem explicável?
RTCP	sender report, CNAME e BYE	Relógio, identidade e fim são rastreáveis?
Decoder	SPS/PPS/VPS e packetization mode	O payload recebido inicializa o decoder?

Separe “nenhuma mídia chegou” de “a mídia chegou, mas não decodifica”. Se RTP falta depois de SETUP e PLAY bem-sucedidos, verifique UDP, NAT, firewall e resposta Transport. Lacunas de sequência provam perda ou reordenação. Uma sequência contínua sem imagem desloca a investigação para payload type, clock rate, limites de frame e parâmetros H.264 ou H.265. Essa fronteira é mais útil que a mensagem genérica do player.

Como escrever uma resposta citável?

Use três frases: última operação bem-sucedida, primeira evidência com falha e próximo teste que separa duas causas. Exemplo: “DESCRIBE, SETUP e PLAY funcionam; nenhum RTP chega às portas anunciadas; um teste TCP interleaved separará bloqueio UDP de caminho de mídia errado”. Não atribua a falha à câmera ou rede sem resposta ou pacote que demonstre o limite.

Quais dados tornam o caso reproduzível?

Preserve OPTIONS, DESCRIBE, SETUP e PLAY, SDP, resposta Transport e Session sem segredos. Para RTP registre SSRC, primeira e última sequência, clock rate, lacunas e duração. Informe se VLC ou outro VMS funciona, mas trate isso como comparação controlada, não como prova de que o cliente bem-sucedido interpreta corretamente todas as regras.

Quando examinar servidor ou cliente?

Examine o servidor quando recusar método, fornecer control URL ausente, responder com transporte incompatível ou mudar SSRC ou relógio sem transição. Examine o cliente quando reutilizar nonce vencido, perder Session, solicitar UDP sem abrir portas ou tratar todo fim de NAL como fim de access unit. Se o problema estiver entre os dois, pacote e horário devem acompanhar cada conclusão.

Como revisar o relatório?

Repita a partir de uma conexão nova e compare as cronologias até a primeira diferença. Remova senhas e valores Authorization completos. Ligue cada conclusão a CSeq, sequência ou timestamp. Siga o guia RTSP relacionado e use RTSP Inspector para testar um stream RTSP e coletar evidências localmente, sem enviar o vídeo para um serviço público.

Resposta direta e limite de aceitação

A resposta curta para “Transmissões de câmera RTSP multicast e UDP: por que a descoberta funciona, mas a mídia não chega” é: Como diagnosticar fluxos de câmera RTSP onde a descoberta ONVIF, o controle de tráfego ou a configuração multicast funcionam, mas a mídia RTP nunca chega. Trate essa frase como um resultado a verificar, não como promessa para qualquer entrada, dispositivo, projeto ou ambiente. Um resultado completo registra estado inicial, ação exata, saída visível e condição que comprova a conclusão da tarefa no RTSP Inspector.

Procedimento orientado por evidências

Comece com um caso pequeno e repetível antes de alterar um projeto completo. Registre versão do aplicativo, sistema operacional, identidade da entrada ou dispositivo, configurações relevantes e resultado esperado. Execute uma ação deliberada, preserve a primeira transição inesperada e compare com um caso conhecido quando possível. Alterar vários controles ao mesmo tempo esconde qual condição criou ou corrigiu o problema.

Ponto de controle 1: Transmissões de câmera RTSP multicast e UDP: por que a descoberta funciona, mas a mídia nã

Quando “Transmissões de câmera RTSP multicast e UDP: por que a descoberta funciona, mas a mídia não chega” for ambíguo, compare um caso bom e outro falho sob condições equivalentes. Marque a primeira diferença significativa, não todos os sintomas posteriores. Esse limite costuma produzir uma solicitação de suporte mais clara e um experimento mais seguro.

Ponto de controle 2: Como diagnosticar fluxos de câmera RTSP onde a descoberta ONVIF, o controle de tráfego ou

Verifique “Como diagnosticar fluxos de câmera RTSP onde a descoberta ONVIF, o controle de tráfego ou a configuração multicast funcionam, mas a mídia RTP nunca ch” com a menor entrada representativa. Mantenha configurações não relacionadas, repita a mesma ação e confira o resultado após reabrir ou reconectar. Uma captura isolada é mais fraca que um registro com entrada, configuração, ação, saída e horário.

Ponto de controle 3: ONVIF Discovery é uma conversa UDP diferente

Quando “ONVIF Discovery é uma conversa UDP diferente” for ambíguo, compare um caso bom e outro falho sob condições equivalentes. Marque a primeira diferença significativa, não todos os sintomas posteriores. Esse limite costuma produzir uma solicitação de suporte mais clara e um experimento mais seguro.

Ponto de controle 4: Multicast requer associação ao grupo

Verifique “Multicast requer associação ao grupo” com a menor entrada representativa. Mantenha configurações não relacionadas, repita a mesma ação e confira o resultado após reabrir ou reconectar. Uma captura isolada é mais fraca que um registro com entrada, configuração, ação, saída e horário.

Ponto de controle 5: A mídia UDP pode ser bloqueada enquanto o controle TCP funciona

Quando “A mídia UDP pode ser bloqueada enquanto o controle TCP funciona” for ambíguo, compare um caso bom e outro falho sob condições equivalentes. Marque a primeira diferença significativa, não todos os sintomas posteriores. Esse limite costuma produzir uma solicitação de suporte mais clara e um experimento mais seguro.

Ponto de controle 6: O que capturar

Verifique “O que capturar” com a menor entrada representativa. Mantenha configurações não relacionadas, repita a mesma ação e confira o resultado após reabrir ou reconectar. Uma captura isolada é mais fraca que um registro com entrada, configuração, ação, saída e horário.

Ponto de controle 7: Onde o inspetor RTSP se encaixa

Quando “Onde o inspetor RTSP se encaixa” for ambíguo, compare um caso bom e outro falho sob condições equivalentes. Marque a primeira diferença significativa, não todos os sintomas posteriores. Esse limite costuma produzir uma solicitação de suporte mais clara e um experimento mais seguro.

Ponto de controle 8: Evidência reproduzível para “Transmissões de câmera RTSP multicast e UDP: por que a descob

Verifique “Evidência reproduzível para “Transmissões de câmera RTSP multicast e UDP: por que a descoberta funciona, mas a mídia não chega”” com a menor entrada representativa. Mantenha configurações não relacionadas, repita a mesma ação e confira o resultado após reabrir ou reconectar. Uma captura isolada é mais fraca que um registro com entrada, configuração, ação, saída e horário.

Ponto de controle 9: Como escrever uma resposta citável?

Quando “Como escrever uma resposta citável?” for ambíguo, compare um caso bom e outro falho sob condições equivalentes. Marque a primeira diferença significativa, não todos os sintomas posteriores. Esse limite costuma produzir uma solicitação de suporte mais clara e um experimento mais seguro.

Ponto de controle 10: Quais dados tornam o caso reproduzível?

Verifique “Quais dados tornam o caso reproduzível?” com a menor entrada representativa. Mantenha configurações não relacionadas, repita a mesma ação e confira o resultado após reabrir ou reconectar. Uma captura isolada é mais fraca que um registro com entrada, configuração, ação, saída e horário.

Matriz de aceitação

Ponto	Evidência a manter	Condição de aprovação
Transmissões de câmera RTSP multicast e UDP: por que a descoberta funciona, mas a mídia não chega	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
Como diagnosticar fluxos de câmera RTSP onde a descoberta ONVIF, o controle de tráfego ou a configuração multicast funci	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
ONVIF Discovery é uma conversa UDP diferente	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
Multicast requer associação ao grupo	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
A mídia UDP pode ser bloqueada enquanto o controle TCP funciona	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
O que capturar	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado

Isolamento, recuperação e entrega

Pare no primeiro limite que falhar. Preserve fonte, projeto, sessão ou captura, duplique antes de edição destrutiva e altere uma variável por experimento. Repetir um fluxo amplo depois de várias mudanças pode gerar outro resultado sem explicar o motivo.

Separe ausência de evidência de evidência de ausência. Uma tela vazia pode indicar entrada, escopo, filtro, permissão, dispositivo, intervalo ou estado incorreto. Verifique aquisição ou importação antes de interpretar decoder, editor, relatório ou exportação.

Antes da entrega, reabra o artefato e examine início, ponto de decisão e final. Registre versão, plataforma, configuração, expectativa, observação e reprodução mínima. Remova ou oculte dados sensíveis e confirme a autorização do destinatário.

Perguntas e respostas

Qual é a maneira confiável mais rápida de começar?

Use o menor caso representativo, escreva o resultado esperado e altere uma variável. Confirme o caminho básico antes de adicionar filtros, efeitos, edições, automação ou uma fonte maior.

Quais evidências devem ser salvas?

Mantenha identidade da entrada, versão, plataforma, configurações, ação exata, primeira transição inesperada e saída final. Feche e reabra projeto, sessão, relatório ou exportação antes de tratá-lo como durável.

Quando o procedimento deve ser repetido?

Repita após mudanças relevantes no aplicativo, sistema, driver, firmware, modelo, fonte ou fluxo. Preserve o caso aceito anterior como referência sem alterações.

Quando a tarefa está pronta para entrega?

Quando outra pessoa autorizada identifica a entrada, repete a ação, vê o mesmo resultado, entende os limites restantes e abre o artefato sem depender de estado local não documentado.

Guias relacionados

Estas páginas no mesmo idioma cobrem etapas próximas sem alterar o proprietário canônico deste assunto: