2026-06-02

Discordancia de canales entrelazados RTSP sobre TCP: corrección de la asignación de canales RTP/RTCP y sin problemas de vídeo

Cómo diagnosticar discordancia de canales entrelazados RTSP sobre TCP, mapeo de canales RTP y RTCP, encabezados de transporte, intercalado = 0-1, sin video y fallas en el análisis de medios de la cámara.

El transporte entrelazado RTSP sobre TCP se utiliza a menudo cuando UDP RTP está bloqueado por firewalls, NAT, VPN o rutas de retransmisión en la nube. Puede hacer que la transmisión de una cámara funcione a través de redes donde UDP fallaría. Pero introduce otra clase de problemas: "la falta de coincidencia de canales entrelazados. La sesión RTSP se conecta. DESCRIBIR devuelve SDP. SETUP tiene éxito. PLAY tiene éxito. Los bytes de medios llegan a la conexión TCP. Luego, el cliente no muestra vídeo ni audio, canal RTP desconocido, fotograma entrelazado con formato incorrecto o paquetes RTCP analizados como RTP." Los usuarios buscan "RTSP sobre TCP intercalado sin video", "no coinciden los canales RTP intercalados", "RTSP intercalado 0-1", "asignación de canales RTSP TCP" y "error de análisis de RTP sobre RTSP" cuando el canal de control funciona pero falla el análisis de medios.

RTSP Inspector es útil aquí porque la evidencia importante se encuentra en el encabezado Transport y los datos entrelazados con marco $ en la conexión RTSP TCP.

¿Qué significa el transporte intercalado?

Con el transporte UDP, el control RTSP utiliza TCP y los medios RTP/RTCP utilizan puertos UDP separados. Con el transporte entrelazado TCP, los paquetes de medios se integran dentro de la conexión TCP RTSP.

La respuesta SETUP puede contener:

Transport: RTP/AVP/TCP;unicast;interleaved=0-1

That means RTP and RTCP for that track should be carried on interleaved channels 0 and 1. Interleaved frames use a $ marker, a channel byte, a length, and then the RTP or RTCP packet.

If the client maps channels incorrectly, it may parse RTP as RTCP, audio as video, or metadata as media.

Multiple tracks create more mappings

A camera with video and audio may return separate SETUP responses:

Video Transport: RTP/AVP/TCP;unicast;interleaved=0-1
Audio Transport: RTP/AVP/TCP;unicast;interleaved=2-3

Ahora el cliente debe mapear:

Canal 0: vídeo RTP
Canal 1: vídeo RTCP
Canal 2: audio RTP
Canal 3: audio RTCP

Si el orden de configuración de audio y video cambia, las suposiciones codificadas se rompen. Si se agrega una pista de metadatos, las asignaciones de canales pueden cambiar nuevamente.

Síntomas comunes

Los problemas de canales entrelazados se ven así:

La sesión RTSP llega a "PLAY" pero el vídeo permanece en negro.
Llegan bytes RTP pero el analizador de carga útil los rechaza.
Los informes del remitente RTCP se analizan como medios.
Los paquetes de audio se envían al despacketizador de vídeo.
Los números de secuencia parecen imposibles.
El tipo de carga útil no coincide con el SDP de esa pista.
El cliente informa "paquete RTP no válido" o "canal entrelazado desconocido".

La red puede estar bien. Es posible que la cámara esté enviando medios. El cliente simplemente está leyendo la asignación de canales incorrecta.

El jefe de transporte es la autoridad.

No infieras la asignación de canales únicamente a partir del orden de las pistas. Utilice el encabezado "Transporte" devuelto por la cámara para cada "CONFIGURACIÓN".

Para cada pista, conserve:

URL de control de seguimiento.
Modo de transporte.
Par de canales entrelazados.
Tipo de carga útil de SDP.
Tipo de medio de SDP.

Luego compare los fotogramas entrelazados entrantes con ese mapeo.

Peculiaridades de la cámara y el proxy

Algunas cámaras se comportan de manera inconsistente:

Ignoran los números de canales entrelazados solicitados y asignan los suyos propios.
Devuelven interleaved=0-1 para múltiples pistas.
Envían RTCP en canales inesperados.
Omiten RTCP.
Un proxy reescribe "Transporte" pero no reescribe marcos multimedia.

Estos son exactamente los casos en los que una prueba exclusiva para jugadores esconde demasiado. El RTSP sin procesar y la evidencia del marco entrelazado son importantes.

Lista de verificación para la depuración de canales entrelazados

Utilice este flujo de trabajo:

Capture SDP de DESCRIBE.
Identifique cada pista de medios.
Capture cada solicitud y respuesta de SETUP.
Registre los encabezados de "Transporte" y los valores "intercalados =".
Asigne números de canales para rastrear y función RTP/RTCP.
Inspeccione las tramas $ entrantes y los bytes de canal.
Compara los tipos de carga útil de RTP con los de SDP para esa pista.
Compruebe si RTCP aparece en el canal impar esperado.
Compruebe si las asignaciones de canales cambian después de volver a conectarse.
Pruebe UDP solo después de comprender la asignación entrelazada de TCP.

Diagnóstico final

Los problemas entrelazados de RTSP sobre TCP no siempre son problemas de red. Si llegan los medios pero no aparece ningún video, inspeccione el mapeo de canales. El encabezado "Transporte" define qué canal entrelazado transporta cada flujo RTP y RTCP.

RTSP Inspector ayuda a exponer tanto el control RTSP como el encuadre de medios entrelazados, de modo que "RTSP se conecta pero no hay video" puede diagnosticarse como un problema de mapeo de canales en lugar de una suposición de códec o firewall.

Evidencia reproducible para «Discordancia de canales entrelazados RTSP sobre TCP: corrección de la asignación de canales RTP/RTCP y sin problemas de vídeo»

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 «Discordancia de canales entrelazados RTSP sobre TCP: corrección de la asignación de canales RTP/RTCP y sin problemas de vídeo», 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 «Discordancia de canales entrelazados RTSP sobre TCP: corrección de la asignación de canales RTP/RTCP y sin problemas de vídeo» es: Cómo diagnosticar discordancia de canales entrelazados RTSP sobre TCP, mapeo de canales RTP y RTCP, encabezados de transporte, intercalado = 0-1, sin video y fallas en el análisis de medios de la cámara. 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: Discordancia de canales entrelazados RTSP sobre TCP: corrección de la asignación de canale

Para «Discordancia de canales entrelazados RTSP sobre TCP: corrección de la asignación de canales RTP/RTCP y sin problemas de vídeo», 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 2: Cómo diagnosticar discordancia de canales entrelazados RTSP sobre TCP, mapeo de canales RT

Cierre «Cómo diagnosticar discordancia de canales entrelazados RTSP sobre TCP, mapeo de canales RTP y RTCP, encabezados de transporte, intercalado = 0-1, sin » 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 3: ¿Qué significa el transporte intercalado?

Para «¿Qué significa el transporte intercalado?», 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 4: Multiple tracks create more mappings

Cierre «Multiple tracks create more mappings» 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 5: Síntomas comunes

Para «Síntomas comunes», 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 6: El jefe de transporte es la autoridad.

Cierre «El jefe de transporte es la autoridad.» 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 7: Peculiaridades de la cámara y el proxy

Para «Peculiaridades de la cámara y el proxy», 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 8: Lista de verificación para la depuración de canales entrelazados

Cierre «Lista de verificación para la depuración de canales entrelazados» 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 9: Diagnóstico final

Para «Diagnóstico final», 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 10: Evidencia reproducible para «Discordancia de canales entrelazados RTSP sobre TCP: correcci

Cierre «Evidencia reproducible para «Discordancia de canales entrelazados RTSP sobre TCP: corrección de la asignación de canales RTP/RTCP y sin problemas de v» 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.

Matriz de aceptación

Punto	Evidencia que conservar	Condición de aprobado
Discordancia de canales entrelazados RTSP sobre TCP: corrección de la asignación de canales RTP/RTCP y sin problemas de	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Cómo diagnosticar discordancia de canales entrelazados RTSP sobre TCP, mapeo de canales RTP y RTCP, encabezados de trans	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
¿Qué significa el transporte intercalado?	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Multiple tracks create more mappings	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Síntomas comunes	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
El jefe de transporte es la autoridad.	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: