Come correggere gli errori RTP/NDPI di \"scrittura sconosciuta\": tipo di payload dinamico e mappatura SDP nei flussi RTSP

Una sessione RTSP può sembrare integra finché il parser multimediale non tenta di comprendere i pacchetti RTP. "DESCRIBE" restituisce SDP. "SETUP" ha avuto successo. "GIOCA" ha successo. Arrivano i pacchetti RTP. Quindi l'applicazione o il classificatore di pacchetti segnala "scrittura sconosciuta", "payload RTP sconosciuto", "NDPI sconosciuto", "tipo di payload non supportato", "depacketizer non trovato", "mappatura codec non valida", "nessun decoder per tipo di payload 96" o "lo stream contiene traccia sconosciuta".

Questi errori di solito indicano che i byte sono presenti ma l'analizzatore non può mappare un tipo di payload RTP sul codec e tenere traccia della definizione da SDP. In RTSP, il tipo di payload "96" non è automaticamente H.264. È un ID dinamico locale della sessione. Devi leggere l'SDP.

Risposta rapida: controlla l'SDP prima di incolpare l'NDPI o la fotocamera

Se un'acquisizione riporta "scrittura sconosciuta" / "RTP" / "NDPI", inizia da qui:

1. Trova la risposta RTSP "DESCRIBE".
2. Copia l'SDP.
3. Trova ogni riga multimediale m= e i relativi numeri di carico utile.
4. Per ogni payload dinamico (96-127), trova la riga a=rtpmap:<id> corrispondente.
5. Controlla la riga a=fmtp:<id> per i parametri del codec.
6. Confronta il byte del tipo di payload del pacchetto RTP con la mappatura SDP.

Se i pacchetti RTP utilizzano il tipo di payload "96" e SDP dice "a=rtpmap:96 H265/90000", un analizzatore che prevede H.264 riporterà un'assurdità. Se SDP ha a=rtpmap:96 vnd.onvif.metadata/90000, il payload sconosciuto non è affatto video; sono metadati ONVIF e non dovrebbero interrompere la riproduzione.

Questo è il motivo per cui un'etichetta DPI generica come "NDPI sconosciuto" non è sufficiente. I motori DPI vedono i byte dei pacchetti. Non sempre dispongono del contesto del piano di controllo RTSP necessario per interpretare gli ID payload dinamici locali della sessione. Per RTSP, il piano di controllo e il piano media devono essere letti insieme.

Questo è un problema di interpretazione del protocollo. RTSP Inspector è utile perché mantiene insieme le prove SDP e RTP. Non è possibile interpretare correttamente gli ID payload RTP dinamici senza l'SDP che li definisce.

Tipi di carico utile statico e dinamico

Alcuni tipi di payload RTP sono statici. Altri sono dinamici. I tipi di carico utile dinamico di solito risiedono nell'intervallo 96-127 e devono essere mappati da SDP.

Esempio:

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 in SDP manca rtpmap, il client potrebbe non sapere quale depacketizzatore utilizzare. Alcune fotocamere producono un SDP incompleto. Alcuni relè o proxy alterano l'SDP. Alcuni client analizzano solo le tracce comuni e ignorano le tracce dei metadati.

Risultati comuni:

• Il payload video arriva ma non viene decodificato.
• La traccia audio viene ignorata.
• La traccia dei metadati ONVIF attiva errori di payload sconosciuti.
• H.265 viene scambiato per H.264.
• La frequenza di clock AAC o il conteggio dei canali sono errati.

Il tipo di carico utile cambia tra le sessioni

Non codificare gli ID payload dinamici. Una telecamera può assegnare numeri di carico utile diversi dopo il riavvio, la modifica del profilo, l'aggiornamento del firmware o la modifica del percorso del flusso.

Per esempio:

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

Il tipo di carico utile, la frequenza di clock, i canali e i parametri FMTP sono tutti importanti.

Tracce di metadati ed estensioni del fornitore

Metadati ONVIF, sovrapposizioni di analisi, tracce di eventi privati ​​e payload specifici del fornitore possono essere visualizzati in SDP. Un lettore multimediale potrebbe non sapere cosa farne.

Questo non è necessariamente un errore di flusso. Potrebbe significare che il client dovrebbe ignorare le tracce non multimediali non supportate mentre continua a elaborare video e audio. Ma se il client considera fatali i metadati sconosciuti, la riproduzione potrebbe non riuscire.

RTSP Inspector dovrebbe aiutare a identificare il tipo di traccia, la mappatura del payload e se i payload sconosciuti sono video, audio, metadati o dati privati.

Elenco di controllo del debug

Utilizza questo processo:

1. Cattura l'SDP restituito da "DESCRIBE".
2. Elenca ogni sezione multimediale m=.
3. Elenca ogni tipo di payload dinamico.
4. Mappa gli ID del payload con "a=rtpmap".
5. Controlla "a=fmtp" per la configurazione del codec.
6. Confronta i valori del tipo di payload del pacchetto RTP con SDP.
7. Controlla se gli ID del payload cambiano tra le sessioni.
8. Separa video, audio, metadati e tracce private.
9. Confermare che il client disponga di un depacketizer per ogni codec richiesto.
10. Ignora le tracce opzionali non supportate solo se l'applicazione può farlo in sicurezza.

Diagnosi finale

La mancata corrispondenza del tipo di payload dinamico RTP si verifica quando il client non riesce a mappare i pacchetti RTP in entrata sul codec o sulla traccia corretti. La soluzione consiste nel considerare SDP come l'autorità per la sessione: analizzare "rtpmap", analizzare "fmtp", associare gli ID del payload per sessione e distinguere le tracce multimediali richieste dai metadati opzionali.

RTSP Inspector supporta questo flusso di lavoro basato sulle prove mostrando SDP e RTP fianco a fianco, in modo che i problemi del carico utile possano essere diagnosticati prima di incolpare la telecamera, il decoder o la rete.