Cómo solucionar errores RTP/NDPI de 'escritura desconocida': tipo de carga útil dinámica y asignación de SDP en transmisiones RTSP

Una sesión RTSP puede parecer saludable hasta que el analizador de medios intenta comprender los paquetes RTP. DESCRIBIR devuelve SDP. SETUP tiene éxito. PLAY tiene éxito. Llegan los paquetes RTP. Luego, la aplicación o el clasificador de paquetes informa "escritura desconocida", "carga útil RTP desconocida", "NDPI desconocida", "tipo de carga útil no compatible", "despacketizador no encontrado", "asignación de códec no válido", "no hay decodificador para el tipo de carga 96" o "la secuencia contiene una pista desconocida".

Esos errores generalmente significan que los bytes están presentes pero el analizador no puede asignar un tipo de carga útil RTP al códec y rastrear la definición del SDP. En RTSP, el tipo de carga útil "96" no es automáticamente H.264. Es una identificación dinámica local de sesión. Tienes que leer el SDP.

Respuesta rápida: verifique el SDP antes de culpar al NDPI o a la cámara

Si una captura dice "escritura desconocida" / "RTP" / "NDPI", comience aquí:

1. Busque la respuesta RTSP DESCRIBE.
2. Copie el SDP.
3. Encuentre cada línea de medios m= y sus números de carga útil.
4. Para cada carga útil dinámica (96-127), busque la línea a=rtpmap:<id> correspondiente.
5. Verifique la línea a=fmtp:<id> para ver los parámetros del códec.
6. Compare el byte del tipo de carga útil del paquete RTP con esa asignación SDP.

Si los paquetes RTP usan el tipo de carga útil 96 y SDP dice a=rtpmap:96 H265/90000, un analizador que espera H.264 informará tonterías. Si SDP tiene a=rtpmap:96 vnd.onvif.metadata/90000, la carga útil desconocida no es video en absoluto; son metadatos ONVIF y no deberían interrumpir la reproducción.

Esta es la razón por la que una etiqueta DPI genérica como "NDPI desconocido" no es suficiente. Los motores DPI ven los bytes del paquete. No siempre tienen el contexto del plano de control RTSP necesario para interpretar los ID de carga útil dinámica local de la sesión. Para RTSP, el plano de control y el plano de medios deben leerse juntos.

Este es un problema de interpretación del protocolo. RTSP Inspector es útil porque mantiene juntas las pruebas de SDP y RTP. No se pueden interpretar correctamente los ID de carga útil RTP dinámico sin el SDP que los define.

Tipos de carga útil estática versus dinámica

Algunos tipos de carga útil RTP son estáticos. Otros son dinámicos. Los tipos de carga útil dinámica generalmente se encuentran en el rango 96-127 y deben ser mapeados por SDP.

Ejemplo:

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 a SDP le falta rtpmap, es posible que el cliente no sepa qué despaqueteador usar. Algunas cámaras producen SDP incompleto. Algunos repetidores o proxies alteran el SDP. Algunos clientes analizan sólo pistas comunes e ignoran las pistas de metadatos.

Resultados comunes:

• La carga útil del vídeo llega pero no se decodifica.
• Se ignora la pista de audio.
• El seguimiento de metadatos ONVIF desencadena errores de carga útil desconocidos.
• H.265 se confunde con H.264.
• La velocidad del reloj AAC o el recuento de canales son incorrectos.

El tipo de carga útil cambia entre sesiones.

No codifique los ID de carga dinámica. Una cámara puede asignar diferentes números de carga útil después de reiniciar, cambiar de perfil, actualizar el firmware o cambiar la ruta de transmisión.

Por ejemplo:

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

El tipo de carga útil, la velocidad del reloj, los canales y los parámetros fmtp son importantes.

Seguimientos de metadatos y extensiones de proveedores

Los metadatos ONVIF, superposiciones de análisis, seguimientos de eventos privados y cargas útiles específicas del proveedor pueden aparecer en SDP. Es posible que un reproductor multimedia no sepa qué hacer con ellos.

Esto no es necesariamente una falla en la transmisión. Puede significar que el cliente debería ignorar las pistas no multimedia no compatibles mientras sigue procesando vídeo y audio. Pero si el cliente trata los metadatos desconocidos como fatales, la reproducción puede fallar.

RTSP Inspector debería ayudar a identificar el tipo de pista, el mapeo de carga útil y si las cargas útiles desconocidas son video, audio, metadatos o datos privados.

Lista de verificación de depuración

Utilice este proceso:

1. Capture el SDP devuelto por DESCRIBE.
2. Enumere cada sección de medios m=.
3. Enumere cada tipo de carga útil dinámica.
4. Asigne ID de carga útil con a=rtpmap.
5. Inspeccione a=fmtp para ver la configuración del códec.
6. Compare los valores del tipo de carga útil del paquete RTP con SDP.
7. Compruebe si los ID de carga útil cambian entre sesiones.
8. Separe pistas de vídeo, audio, metadatos y privadas.
9. Confirme que el cliente tenga un despaqueteizador para cada códec requerido.
10. Ignore las pistas opcionales no compatibles solo si la aplicación puede hacerlo de forma segura.

Diagnóstico final

La discrepancia en el tipo de carga dinámica de RTP ocurre cuando el cliente no puede asignar paquetes RTP entrantes al códec o pista correcto. La solución es tratar a SDP como la autoridad para la sesión: analizar rtpmap, analizar fmtp, vincular ID de carga útil por sesión y distinguir las pistas multimedia requeridas de los metadatos opcionales.

RTSP Inspector respalda este flujo de trabajo que prioriza la evidencia al mostrar SDP y RTP uno al lado del otro, de modo que se puedan diagnosticar problemas de carga útil antes de culpar a la cámara, el decodificador o la red.