Relatórios de remetente RTCP, jitter e perda de pacotes: lendo a integridade do fluxo sem assistir ao vídeo

Quando os engenheiros procuram por “jitter RTSP”, “perda de pacotes RTP” ou “relatório do remetente RTCP”, eles geralmente estão tentando responder a uma pergunta prática: "o fluxo está insalubre ou o player está apenas com dificuldades? A reprodução de vídeo é um sintoma tardio. As evidências RTP e RTCP aparecem mais cedo e são mais fáceis de defender em um caso de suporte." O RTCP é o companheiro de controle do RTP. Ele pode transportar relatórios do remetente, do receptor, contagens de pacotes, informações de tempo e feedback de qualidade. Nem toda câmera expõe um comportamento RTCP rico e nem toda implantação o encaminha corretamente, mas quando o RTCP está presente ele fornece um contexto importante que a reprodução bruta não oferece.

Por que o RTCP é importante no diagnóstico de câmeras

RTP transporta pacotes de mídia. O RTCP ajuda a descrever o funcionamento da sessão de mídia. Para um fluxo de câmera RTSP, a evidência RTCP pode ajudar a responder:

• o remetente está vivo depois de PLAY?
• quantos pacotes RTP o remetente relatou?
• os carimbos de data/hora RTP estão alinhados com o tempo do relógio de parede?
• a entrega de pacotes é estável ou em rajadas?
• há instabilidade visível?
• o RTP continuou enquanto a decodificação do vídeo falhou?
• o caminho da mídia incluía RTCP?

Se o controle RTSP for bem-sucedido e o RTP chegar, mas o vídeo congelar, o RTCP poderá ajudar a separar o tempo da rede da prontidão do codec.

Os relatórios do remetente são evidências de tempo

Um relatório de remetente RTCP pode relacionar um carimbo de data/hora RTP a um valor de tempo absoluto no estilo NTP. Esse relacionamento ajuda os receptores a sincronizar os fluxos e a raciocinar sobre o comportamento do relógio. No diagnóstico, a matemática exata pode ser menos importante do que a existência e a consistência dos relatórios.

Observações úteis:

• o relatório do remetente aparece após o início da mídia
• a contagem de pacotes e octetos aumenta
• O mapeamento de carimbo de data/hora RTP é consistente
• intervalo de relatório é plausível
• os relatórios param quando o RTP para
• os relatórios continuam mesmo quando o decodificador falha

Se o RTCP parar junto com o RTP, o caminho do remetente ou da mídia poderá ser interrompido. Se o RTCP continuar, mas a decodificação do vídeo falhar, inspecione a carga útil e as evidências do codec.

Jitter não é o mesmo que perda de pacotes

Jitter significa que os pacotes chegam com tempo variável. Perda de pacotes significa que faltam pacotes. Ambos podem causar gagueira visível, mas levam a soluções diferentes.

Os números de sequência RTP mostram pacotes ausentes. Os carimbos de data/hora RTP e os horários de chegada mostram variação de tempo. Os relatórios RTCP podem adicionar feedback no nível da sessão. Um relatório adequado não deveria dizer apenas “rede ruim”. Deve dizer se o problema é perda, jitter, entrega intermitente, RTCP bloqueado ou limite de decodificação de codec.

Para câmeras, o jitter pode vir de:

• Variação de uplink Wi-Fi
• codificador de câmera sobrecarregado
• Atraso de encaminhamento NVR
• caminho de switch congestionado
• Caminho VPN ou WAN
• comportamento de buffer do lado do cliente

A perda de pacotes pode vir de:

• UDP cai
• Comportamento de firewall/NAT
• rede sobrecarregada
• pressão do buffer de envio da câmera
• limitações do ponto de captura

As correções são diferentes.

A falta de RTCP também é uma evidência

Algumas implantações bloqueiam o RTCP mesmo quando o RTP flui. Algumas câmeras não enviam RTCP útil. Alguns clientes nunca solicitam ou recebem com clareza. A falta de RTCP não significa automaticamente que o fluxo está interrompido, mas deve ser gravado.

Se o RTP sobre UDP for negociado, inspecione a mídia e controle o tráfego complementar. Se for usado RTSP sobre TCP intercalado, inspecione os metadados do canal intercalado. Um relatório que diz “RTP visível, RTCP ausente” é mais útil do que um campo em branco.

Onde o inspetor RTSP se encaixa

O RTSP Inspector foi desenvolvido para evidência de protocolo, não para visualização passiva. O RTCP pertence à mesma história dos métodos RTSP, SDP, continuidade de sequência RTP, tipo de carga útil, metadados de codec e exportação de relatório.

Para pesquisas pesadas em RTCP, o RTSP Inspector deve ajudar a responder:

• a RTP chegou depois do PLAY?
• os relatórios do remetente RTCP apareceram?
• a contagem de pacotes aumentou?
• o jitter ou as lacunas de sequência se alinharam com falhas visíveis?
• a preparação do codec falhou apesar da entrega de mídia?
• o modo de transporte alterou o perfil de saúde?

Isso dá ao fornecedor de câmeras, engenheiro de rede ou desenvolvedor de VMS um ponto de partida concreto. "O fluxo falha" é um sintoma. "As lacunas na sequência RTP e o jitter aumentaram após PLAY enquanto o controle RTSP permaneceu ativo" é uma evidência.