Como corrigir erros RTP / NDPI de 'gravação desconhecida' - tipo de carga útil dinâmica e mapeamento SDP em fluxos RTSP

Uma sessão RTSP pode parecer íntegra até que o analisador de mídia tente entender os pacotes RTP. DESCRIBE retorna SDP. SETUP foi bem-sucedido. PLAY foi bem-sucedido. Chegam pacotes RTP. Em seguida, o aplicativo ou classificador de pacotes relata gravação desconhecida, carga útil RTP desconhecida, NDPI desconhecido, tipo de carga útil não suportado, depacketizer não encontrado, mapeamento de codec inválido, nenhum decodificador para tipo de carga útil 96 ou stream contém trilha desconhecida.

Esses erros geralmente significam que os bytes estão presentes, mas o analisador não pode mapear um tipo de carga RTP para o codec e rastrear a definição do SDP. No RTSP, o tipo de carga 96 não é automaticamente H.264. É um ID dinâmico local da sessão. Você tem que ler o SDP.

Resposta rápida: verifique o SDP antes de culpar o NDPI ou a câmera

Se uma captura disser gravação desconhecida / RTP / NDPI, comece aqui:

1. Encontre a resposta RTSP DESCRIBE.
2. Copie o SDP.
3. Encontre cada linha de mídia m= e seus números de carga útil.
4. Para cada carga dinâmica (96-127), encontre a linha a=rtpmap:<id> correspondente.
5. Verifique a linha a=fmtp:<id> para parâmetros de codec.
6. Compare o byte do tipo de carga útil do pacote RTP com esse mapeamento SDP.

Se os pacotes RTP usarem o tipo de carga 96 e o SDP disser a=rtpmap:96 H265/90000, um analisador que espera H.264 reportará um absurdo. Se o SDP tiver a=rtpmap:96 vnd.onvif.metadata/90000, a carga desconhecida não é vídeo; são metadados ONVIF e não devem interromper a reprodução.

É por isso que um rótulo genérico de DPI como “NDPI desconhecido” não é suficiente. Os mecanismos DPI veem os bytes do pacote. Eles nem sempre têm o contexto do plano de controle RTSP necessário para interpretar IDs de carga dinâmica local da sessão. Para RTSP, o plano de controle e o plano de mídia devem ser lidos juntos.

Este é um problema de interpretação de protocolo. O RTSP Inspector é útil porque mantém as evidências SDP e RTP juntas. Você não pode interpretar corretamente os IDs de carga RTP dinâmicos sem o SDP que os define.

Tipos de carga estática versus dinâmica

Alguns tipos de carga RTP são estáticos. Outros são dinâmicos. Os tipos de carga dinâmica geralmente ficam no intervalo 96-127 e devem ser mapeados pelo SDP.

Exemplo:

m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000

Here, payload type 96 means H.264 for this session. In another stream, payload type 96 could mean H.265, AAC, metadata, or something vendor-specific. The number alone is not enough.

If a client assumes payload type 96 is always H.264, it will eventually fail.

SDP rtpmap is required for dynamic payloads

For dynamic payload types, SDP should include a=rtpmap:

a=rtpmap:96 H264/90000
a=rtpmap:97 MPEG4-GENERIC/48000/2
a=rtpmap:98 H265/90000

Se faltar rtpmap no SDP, o cliente pode não saber qual despacketizer usar. Algumas câmeras produzem SDP incompleto. Alguns relés ou proxies alteram o SDP. Alguns clientes analisam apenas trilhas comuns e ignoram trilhas de metadados.

Resultados comuns:

• A carga útil do vídeo chega, mas não é decodificada.
• A faixa de áudio é ignorada.
• O rastreamento de metadados ONVIF aciona erros de carga útil desconhecidos.
• H.265 é confundido com H.264.
• A taxa de clock AAC ou a contagem de canais estão erradas.

Mudanças no tipo de carga útil entre sessões

Não codifique IDs de carga dinâmica. Uma câmera pode atribuir diferentes números de carga útil após reinicialização, alteração de perfil, atualização de firmware ou alteração de caminho de fluxo.

Por exemplo:

Session A: payload 96 = H264
Session B: payload 96 = H265
Session C: payload 97 = H264, payload 96 = metadata

The correct behavior is to parse SDP per session and bind RTP packet payload IDs to that session's mapping.

H.264 and H.265 confusion

H.264 and H.265 both often use 90 kHz RTP clocks, but their packetization and codec configuration are different. A client using the H.264 depacketizer for H.265 packets will not produce valid video.

Symptoms:

• RTP packets arrive.
• Payload type is dynamic.
• SDP says H265 but client expects H264.
• Decoder reports invalid NAL units.
• Video is black or never starts.

Always check SDP before concluding that the camera "sends bad video."

AAC and MPEG4-GENERIC

Audio tracks can be just as tricky. AAC over RTP often uses MPEG4-GENERIC with parameters such as mode, config, sizeLength, indexLength, and profile-level-id.

If the client ignores fmtp, audio may fail even though packets arrive.

Relevant SDP:

a=rtpmap:97 MPEG4-GENERIC/48000/2
a=fmtp:97 streamtype=5; profile-level-id=1; mode=AAC-hbr; config=...

Tipo de carga útil, taxa de clock, canais e parâmetros de FTP são importantes.

Rastreamentos de metadados e extensões de fornecedores

Metadados ONVIF, sobreposições de análises, rastreamentos de eventos privados e cargas específicas de fornecedores podem aparecer no SDP. Um media player pode não saber o que fazer com eles.

Isso não é necessariamente uma falha de fluxo. Isso pode significar que o cliente deve ignorar faixas que não sejam de mídia não suportadas enquanto ainda processa vídeo e áudio. Mas se o cliente tratar metadados desconhecidos como fatais, a reprodução poderá falhar.

O RTSP Inspector deve ajudar a identificar o tipo de trilha, o mapeamento de carga útil e se as cargas desconhecidas são vídeo, áudio, metadados ou dados privados.

Lista de verificação de depuração

Use este processo:

1. Capture o SDP retornado por DESCRIBE.
2. Liste todas as seções de mídia m=.
3. Liste todos os tipos de carga dinâmica.
4. Mapeie IDs de carga útil com a=rtpmap.
5. Inspecione a=fmtp para configuração do codec.
6. Compare os valores do tipo de carga útil do pacote RTP com o SDP.
7. Verifique se os IDs de carga mudam entre as sessões.
8. Separe vídeo, áudio, metadados e faixas privadas.
9. Confirme se o cliente possui um desempacotador para cada codec necessário.
10. Ignore faixas opcionais não suportadas somente se o aplicativo puder fazer isso com segurança.

Diagnóstico final

A incompatibilidade de tipo de carga dinâmica RTP ocorre quando o cliente não consegue mapear pacotes RTP recebidos para o codec ou trilha correto. A solução é tratar o SDP como a autoridade para a sessão: analisar rtpmap, analisar fmtp, vincular IDs de carga útil por sessão e distinguir as trilhas de mídia necessárias dos metadados opcionais.

O RTSP Inspector oferece suporte a esse fluxo de trabalho baseado em evidências, mostrando SDP e RTP lado a lado, para que problemas de carga útil possam ser diagnosticados antes de culpar a câmera, o decodificador ou a rede.