2026-06-02

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

Depurar errores RTP/NDPI de \"escritura desconocida\" en capturas RTSP asignando tipos de carga útil RTP dinámicos a líneas SDP rtpmap y fmtp. Cubre metadatos H.264, H.265, AAC, ONVIF, ID de carga útil y errores de despacketizador.

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í:

Busque la respuesta RTSP DESCRIBE.
Copie el SDP.
Encuentre cada línea de medios m= y sus números de carga útil.
Para cada carga útil dinámica (96-127), busque la línea a=rtpmap:<id> correspondiente.
Verifique la línea a=fmtp:<id> para ver los parámetros del códec.
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:

Capture el SDP devuelto por DESCRIBE.
Enumere cada sección de medios m=.
Enumere cada tipo de carga útil dinámica.
Asigne ID de carga útil con a=rtpmap.
Inspeccione a=fmtp para ver la configuración del códec.
Compare los valores del tipo de carga útil del paquete RTP con SDP.
Compruebe si los ID de carga útil cambian entre sesiones.
Separe pistas de vídeo, audio, metadatos y privadas.
Confirme que el cliente tenga un despaqueteizador para cada códec requerido.
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.

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

La respuesta directa es que una avería de vídeo no se demuestra con una ventana negra ni con un solo código de estado. Un diagnóstico fiable conecta la petición y la respuesta RTSP, el transporte negociado, una sesión válida y después los números de secuencia RTP, las marcas de tiempo y las señales RTCP. Para «Cómo solucionar errores RTP/NDPI de 'escritura desconocida': tipo de carga útil dinámica y asignación de SDP en transmisiones RTSP», empieza por la capa más cercana al síntoma visible, pero conserva una cronología común para no mezclar un fallo de control con uno de red o decodificación.

Antes de cambiar la cámara, el firewall o el VMS, crea una prueba base pequeña. Anota la URL RTSP sin contraseña, la hora, la ruta, el transporte solicitado, la respuesta del servidor y el instante del primer paquete multimedia. Prueba UDP y TCP interleaved por separado cuando el equipo ofrezca ambos. No cambies ruta, credenciales y transporte a la vez; si el segundo intento funciona, necesitas saber qué variable produjo la diferencia.

Capa	Evidencia que se debe guardar	Pregunta de decisión
RTSP	método, estado, cabeceras, CSeq y Session	¿El servidor aceptó exactamente la operación?
SDP	control, payload type, clock rate y codec	¿El servidor describió la pista esperada?
Transport	client_port, server_port o interleaved	¿Ambos extremos usan el mismo canal?
RTP	SSRC, secuencia, timestamp y marker	¿Las unidades llegan en un orden explicable?
RTCP	sender report, CNAME y BYE	¿Se pueden relacionar reloj, identidad y final?
Decoder	SPS/PPS/VPS y packetization mode	¿El payload recibido permite iniciar el decoder?

Separa «no llega multimedia» de «llega multimedia que no se puede decodificar». Si no aparece RTP después de SETUP y PLAY correctos, revisa UDP, NAT, firewall y una respuesta Transport distinta de la oferta. RTP con huecos de secuencia prueba pérdida o reordenación. Una secuencia continua sin imagen desplaza la investigación hacia payload type, clock rate, límites de cuadro y parámetros H.264 o H.265. Esta frontera es más útil que el mensaje general del reproductor.

¿Cómo se redacta una respuesta que pueda citarse?

Usa tres frases: última operación correcta, primera evidencia que falla y siguiente prueba que separa dos causas. Ejemplo: «DESCRIBE, SETUP y PLAY terminan correctamente; no llega RTP a los puertos anunciados por el cliente; repetir por TCP interleaved separará el bloqueo UDP de una ruta multimedia incorrecta». No atribuyas el fallo a la cámara o a la red sin una respuesta o un paquete que marque ese límite.

¿Qué hace reproducible el caso?

Guarda OPTIONS, DESCRIBE, SETUP y PLAY, el SDP, la respuesta Transport y el identificador Session saneado. Para RTP registra SSRC, primer y último número de secuencia, clock rate, huecos y duración. Indica si VLC u otro VMS funciona, pero úsalo como comparación controlada, no como prueba de que el cliente exitoso interpreta todas las reglas de forma correcta.

¿Cuándo se investiga el servidor y cuándo el cliente?

Mira el servidor si rechaza un método, entrega un control URL inexistente, responde con un transporte incompatible o cambia SSRC o reloj sin transición. Mira el cliente si reutiliza un nonce caducado, pierde Session, solicita UDP sin abrir los puertos o interpreta cada final NAL como final de access unit. Si el límite está entre ambos, conserva paquete y hora en cada afirmación.

¿Cómo se revisa el informe?

Repite desde una conexión nueva y compara las dos cronologías solo hasta la primera diferencia. Elimina contraseñas y valores Authorization completos. Relaciona cada conclusión con CSeq, secuencia o timestamp. Continúa con la guía RTSP relacionada y usa RTSP Inspector para probar un stream RTSP y recoger evidencia de forma local, sin subir el vídeo de la cámara a un servicio público.

Respuesta directa y límite de aceptación

La respuesta breve a «Cómo solucionar errores RTP/NDPI de 'escritura desconocida': tipo de carga útil dinámica y asignación de SDP en transmisiones RTSP» es: Depurar errores RTP/NDPI de "escritura desconocida" en capturas RTSP asignando tipos de carga útil RTP dinámicos a líneas SDP rtpmap y fmtp. Cubre metadatos H.264, H.265, AAC, ONVIF, ID de carga útil y errores de despacketizador. Trate esa frase como un resultado que debe comprobarse, no como una promesa para cualquier entrada, dispositivo, proyecto o entorno. Un resultado completo registra estado inicial, acción exacta, salida visible y condición que demuestra que la tarea terminó en RTSP Inspector.

Procedimiento basado en evidencia

Empiece con un caso pequeño y repetible antes de cambiar un proyecto completo. Anote versión de la aplicación, sistema operativo, identidad de entrada o dispositivo, ajustes relevantes y resultado esperado. Ejecute una acción deliberada, conserve la primera transición inesperada y compárela con un caso conocido cuando exista. Cambiar varios controles a la vez oculta qué condición creó o corrigió el problema.

Punto de control 1: Cómo solucionar errores RTP/NDPI de 'escritura desconocida': tipo de carga útil dinámica y

Cierre «Cómo solucionar errores RTP/NDPI de 'escritura desconocida': tipo de carga útil dinámica y asignación de SDP en transmisiones RTSP» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.

Punto de control 2: Depurar errores RTP/NDPI de "escritura desconocida" en capturas RTSP asignando tipos de

Para «Depurar errores RTP/NDPI de "escritura desconocida" en capturas RTSP asignando tipos de carga útil RTP dinámicos a líneas SDP rtpmap y fmtp. Cubre m», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.

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

Cierre «Respuesta rápida: verifique el SDP antes de culpar al NDPI o a la cámara» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.

Punto de control 4: Tipos de carga útil estática versus dinámica

Para «Tipos de carga útil estática versus dinámica», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.

Punto de control 5: SDP rtpmap is required for dynamic payloads

Cierre «SDP rtpmap is required for dynamic payloads» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.

Punto de control 6: El tipo de carga útil cambia entre sesiones.

Para «El tipo de carga útil cambia entre sesiones.», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.

Punto de control 7: H.264 and H.265 confusion

Cierre «H.264 and H.265 confusion» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.

Punto de control 8: AAC and MPEG4-GENERIC

Para «AAC and MPEG4-GENERIC», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.

Punto de control 9: Seguimientos de metadatos y extensiones de proveedores

Cierre «Seguimientos de metadatos y extensiones de proveedores» solo cuando el resultado guardado, exportado o reabierto conserve el estado observado. La respuesta temporal de la interfaz orienta, pero la evidencia duradera es más fuerte. Documente cualquier límite pendiente para quien continúe.

Punto de control 10: Lista de verificación de depuración

Para «Lista de verificación de depuración», separe una decisión del producto de un límite del sistema, hardware, archivo fuente, permiso o proceso. Confirme qué capa produjo la evidencia antes de atribuir una causa. Así evita convertir un síntoma cercano en una causa raíz supuestamente probada.

Matriz de aceptación

Punto	Evidencia que conservar	Condición de aprobado
Cómo solucionar errores RTP/NDPI de 'escritura desconocida': tipo de carga útil dinámica y asignación de SDP en transmis	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Depurar errores RTP/NDPI de "escritura desconocida" en capturas RTSP asignando tipos de carga útil RTP dinámicos a lín	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Respuesta rápida: verifique el SDP antes de culpar al NDPI o a la cámara	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Tipos de carga útil estática versus dinámica	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
SDP rtpmap is required for dynamic payloads	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
El tipo de carga útil cambia entre sesiones.	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado

Aislamiento, recuperación y entrega

Deténgase en el primer límite que falla. Conserve fuente, proyecto, sesión o captura, duplíquelo antes de una edición destructiva y cambie una variable por experimento. Repetir un flujo amplio después de varios cambios puede dar otro resultado sin explicar la causa.

Separe ausencia de evidencia de evidencia de ausencia. Una vista vacía puede indicar entrada, alcance, filtro, permiso, dispositivo, intervalo o estado equivocado. Verifique adquisición o importación antes de interpretar el decoder, editor, informe o exportación.

Antes de entregar, reabra el artefacto y revise inicio, punto de decisión y final. Registre versión, plataforma, configuración, expectativa, observación y reproducción mínima. Elimine o redacte datos sensibles y confirme que el destinatario está autorizado.

Preguntas y respuestas

¿Cuál es la forma fiable más rápida de empezar?

Use el caso representativo más pequeño, escriba el resultado esperado y cambie una variable. Confirme el recorrido básico antes de añadir filtros, efectos, ediciones, automatización o una fuente mayor.

¿Qué evidencia debe guardarse?

Conserve identidad de entrada, versión, plataforma, ajustes, acción exacta, primera transición inesperada y salida final. Cierre y reabra cualquier proyecto, sesión, informe o exportación antes de considerarlo duradero.

¿Cuándo debe repetirse el procedimiento?

Repítalo después de cambios relevantes en aplicación, sistema, driver, firmware, modelo, fuente o flujo. Preserve el caso aceptado anterior como referencia sin modificar.

¿Cuándo está listo para entregar?

Cuando otra persona autorizada identifica la entrada, repite la acción, obtiene el mismo resultado, entiende los límites restantes y abre el artefacto sin depender de estado local no documentado.

Guías relacionadas

Estas páginas en el mismo idioma cubren etapas contiguas sin cambiar el propietario canónico del tema: