Transmissões de câmera RTSP multicast e UDP: por que a descoberta funciona, mas a mídia não 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.