Comment corriger les erreurs RTP/NDPI  écriture inconnue

Une session RTSP peut sembler saine jusqu'à ce que l'analyseur multimédia essaie de comprendre les paquets RTP. DESCRIBE renvoie SDP. SETUP réussit. « PLAY » réussit. Les paquets RTP arrivent. Ensuite, l'application ou le classificateur de paquets signale « écriture inconnue », « charge utile RTP inconnue », « NDPI inconnu », « type de charge utile non pris en charge », « dépacketizer introuvable », « mappage de codec invalide », « aucun décodeur pour le type de charge utile 96 » ou « le flux contient une piste inconnue ».

Ces erreurs signifient généralement que les octets sont présents, mais que l'analyseur ne peut pas mapper un type de charge utile RTP au codec et suivre la définition de SDP. Dans RTSP, le type de charge utile « 96 » n'est pas automatiquement H.264. Il s'agit d'un identifiant dynamique local de session. Vous devez lire le SDP.

Réponse rapide : vérifiez SDP avant de blâmer NDPI ou la caméra

Si une capture indique « écriture inconnue » / « RTP » / « NDPI », commencez ici :

1. Recherchez la réponse RTSP « DESCRIBE ».
2. Copiez le SDP.
3. Trouvez chaque ligne multimédia m= et ses numéros de charge utile.
4. Pour chaque charge utile dynamique (96-127), recherchez la ligne a=rtpmap:<id> correspondante.
5. Vérifiez la ligne a=fmtp:<id> pour les paramètres du codec.
6. Comparez l'octet de type de charge utile du paquet RTP avec ce mappage SDP.

Si les paquets RTP utilisent le type de charge utile « 96 » et que SDP indique « a=rtpmap:96 H265/90000 », un analyseur attendant H.264 signalera des bêtises. Si SDP a « a=rtpmap:96 vnd.onvif.metadata/90000 », la charge utile inconnue n'est pas du tout une vidéo ; ce sont des métadonnées ONVIF et ne devraient pas arrêter la lecture.

C'est pourquoi une étiquette DPI générique telle que « NDPI inconnu » n'est pas suffisante. Les moteurs DPI voient les octets des paquets. Ils ne disposent pas toujours du contexte de plan de contrôle RTSP nécessaire pour interpréter les ID de charge utile dynamique locale de session. Pour RTSP, le plan de contrôle et le plan média doivent être lus ensemble.

Il s'agit d'un problème d'interprétation du protocole. RTSP Inspector est utile car il conserve les preuves SDP et RTP ensemble. Vous ne pouvez pas interpréter correctement les ID de charge utile RTP dynamiques sans le SDP qui les définit.

Types de charges utiles statiques et dynamiques

Certains types de charge utile RTP sont statiques. D'autres sont dynamiques. Les types de charges utiles dynamiques se situent généralement entre 96 et 127 et doivent être mappés par SDP.

Exemple:

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

Si SDP manque rtpmap, le client peut ne pas savoir quel dépacketizer utiliser. Certaines caméras produisent un SDP incomplet. Certains relais ou proxys modifient le SDP. Certains clients analysent uniquement les pistes communes et ignorent les pistes de métadonnées.

Résultats courants :

• La charge utile vidéo arrive mais n’est pas décodée.
• La piste audio est ignorée.
• Le suivi des métadonnées ONVIF déclenche des erreurs de charge utile inconnues.
• H.265 est confondu avec H.264.
• La fréquence d'horloge AAC ou le nombre de canaux est erroné.

Le type de charge utile change entre les sessions

Ne codez pas en dur les ID de charge utile dynamique. Une caméra peut attribuer différents numéros de charge utile après un redémarrage, un changement de profil, une mise à jour du micrologiciel ou un changement de chemin de flux.

Par exemple:

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=...

Le type de charge utile, la fréquence d’horloge, les canaux et les paramètres fmtp sont tous importants.

Pistes de métadonnées et extensions de fournisseurs

Les métadonnées ONVIF, les superpositions d'analyses, les suivis d'événements privés et les charges utiles spécifiques au fournisseur peuvent apparaître dans SDP. Un lecteur multimédia ne sait peut-être pas quoi en faire.

Il ne s'agit pas nécessairement d'un échec de flux. Cela peut signifier que le client doit ignorer les pistes non multimédias non prises en charge tout en continuant à traiter la vidéo et l'audio. Mais si le client considère les métadonnées inconnues comme fatales, la lecture peut échouer.

RTSP Inspector devrait aider à identifier le type de piste, le mappage des charges utiles et si les charges utiles inconnues sont de la vidéo, de l'audio, des métadonnées ou des données privées.

Liste de contrôle de débogage

Utilisez ce processus :

1. Capturez le SDP renvoyé par DESCRIBE.
2. Répertoriez chaque section multimédia m=.
3. Répertoriez chaque type de charge utile dynamique.
4. Mappez les ID de charge utile avec a=rtpmap.
5. Inspectez a=fmtp pour la configuration du codec.
6. Comparez les valeurs du type de charge utile du paquet RTP avec celles du SDP.
7. Vérifiez si les ID de charge utile changent entre les sessions.
8. Séparez les pistes vidéo, audio, métadonnées et privées.
9. Confirmez que le client dispose d'un dépacketiseur pour chaque codec requis.
10. Ignorez les pistes facultatives non prises en charge uniquement si l'application peut le faire en toute sécurité.

Diagnostic final

Une incompatibilité de type de charge utile dynamique RTP se produit lorsque le client ne peut pas mapper les paquets RTP entrants vers le bon codec ou la bonne piste. Le correctif consiste à traiter SDP comme l'autorité de la session : analyser rtpmap, analyser fmtp, lier les ID de charge utile par session et distinguer les pistes multimédias requises des métadonnées facultatives.

RTSP Inspector prend en charge ce flux de travail axé sur les preuves en affichant côte à côte SDP et RTP, afin que les problèmes de charge utile puissent être diagnostiqués avant de blâmer la caméra, le décodeur ou le réseau.