2026-06-02

RTSP frente a UDP: por qué RTSP se conecta pero el vídeo aparece en negro: RTP bloqueado por firewall, NAT y VPN

Repara RTSP sin video cuando el control se conecta pero UDP RTP está bloqueado. Cubre reglas de firewall, puerto de protocolo RTSP, cruce de NAT, pérdida de VPN RTP, respaldo entrelazado de TCP y puertos de origen UDP de la cámara.

Uno de los problemas RTSP de mayor intención es fácil de describir: "la cámara se conecta, pero no hay vídeo. En muchos casos, el control RTSP funciona sobre TCP, pero los paquetes de medios UDP RTP nunca llegan al cliente. El usuario ve un inicio de sesión exitoso, SDP, tal vez incluso "PLAY 200 OK", y luego un tiempo de espera. Búsquedas como "RTSP se conecta pero no hay video", "RTP UDP cortafuegos bloqueado", "RTSP funciona en LAN, no a través de VPN", "cámara RTSP NAT sin video" y "corrección RTSP TCP intercalada" apuntan a esta división de capas." RTSP no es un flujo de datos. El canal de control y el canal de medios pueden utilizar diferentes rutas de transporte. Si el canal de control funciona y la ruta de medios falla, un reproductor puede mostrar la misma pantalla negra que una falla del códec. La evidencia del paquete es diferente.

RTSP Inspector es útil porque separa el éxito del control RTSP de la entrega de medios RTP.

El control funciona no significa que los medios funcionen

Un flujo UDP RTP normal puede verse así:

El cliente abre la conexión RTSP TCP al puerto 554 de la cámara.
El cliente envía DESCRIBIR.
La cámara devuelve SDP.
El cliente envía SETUP con puertos de cliente UDP.
La cámara devuelve los puertos del servidor UDP.
El cliente envía PLAY.
La cámara envía paquetes RTP a los puertos UDP del cliente.

Si los pasos 1 a 6 se realizan correctamente y el paso 7 falla, la transmisión no es un problema de inicio de sesión RTSP. Es un problema de ruta de los medios.

Cabecera de Transporte revela el plan portuario

La solicitud SETUP puede incluir:

Transport: RTP/AVP;unicast;client_port=50000-50001

The camera may answer:

Transport: RTP/AVP;unicast;client_port=50000-50001;server_port=6970-6971

La cámara debe enviar RTP/RTCP a los puertos UDP del cliente. Los cortafuegos deben permitir ese tráfico. Los dispositivos NAT deben asignarlo correctamente. Las VPN deben llevarlo. De lo contrario, el control RTSP puede parecer saludable mientras los medios están en silencio.

Fallos comunes de firewall y NAT

Las causas comunes incluyen:

El firewall permite TCP 554 pero bloquea el rango de puertos UDP RTP.
NAT reenvía el puerto RTSP pero no los puertos RTP.
La cámara envía RTP desde puertos de origen inesperados.
El cliente anuncia puertos UDP privados a los que la cámara no puede acceder.
VPN permite TCP pero descarta UDP.
El firewall corporativo bloquea los puertos UDP altos.
La cámara está detrás de doble NAT.
Los paquetes RTP regresan a la interfaz incorrecta.

El síntoma visible suele ser "no hay vídeo después de PLAY".

Por qué el TCP entrelazado suele funcionar

RTSP sobre TCP entrelazado transporta RTP y RTCP dentro de la conexión TCP RTSP. Esto evita agujeros UDP separados.

Si el modo UDP falla y el entrelazado TCP funciona, es una fuerte evidencia de que el códec y la cámara probablemente estén bien. Probablemente el problema sea el transporte de medios UDP.

Sin embargo, TCP intercalado tiene sus propios requisitos de análisis, incluido el mapeo de canales. Es una solución alternativa para los problemas de ruta UDP, no una prueba de que todas las capas estén en buen estado.

RTCP puede ayudar a probar el camino

Si RTP está bloqueado pero llega RTCP, o viceversa, inspeccione los pares de puertos. Algunos firewalls manejan las dos direcciones de manera diferente. Los informes del receptor RTCP también pueden mostrar pérdida de paquetes y fluctuaciones si los medios llegan parcialmente.

Registro:

Recuento de paquetes RTP.
Recuento de paquetes RTCP.
IP y puerto de origen RTP.
IP y puerto de destino RTP.
Brechas en los números de secuencia.
Tiempo desde PLAY hasta el primer paquete.

Lista de verificación de depuración

Utilice este flujo de trabajo:

Confirme que RTSP DESCRIBE, SETUP y PLAY sean exitosos.
Inspeccione el encabezado Transport y los puertos UDP cliente/servidor.
Compruebe si los paquetes RTP llegan después de "PLAY".
Compruebe si llegan paquetes RTCP.
Compare la prueba LAN con la prueba VPN/WAN.
Pruebe el transporte entrelazado TCP.
Verifique las reglas del firewall para el rango de puertos UDP RTP.
Verifique el reenvío del puerto NAT y el comportamiento del puerto de origen.
Verifique que el cliente haya anunciado puertos UDP accesibles.
No depures el códec hasta que lleguen las cargas útiles RTP.

Diagnóstico final

Cuando RTSP se conecta pero UDP RTP está bloqueado, se puede acceder perfectamente a la cámara aunque los medios nunca lleguen. La solución está en la accesibilidad del puerto UDP, el comportamiento de NAT, la política de firewall, las reglas de VPN o el cambio a TCP intercalado.

RTSP Inspector ayuda mostrando la secuencia de control RTSP y la evidencia del paquete RTP juntas, de modo que "sin video" se convierte en un diagnóstico de transporte concreto.

Evidencia reproducible para «RTSP frente a UDP: por qué RTSP se conecta pero el vídeo aparece en negro: RTP bloqueado por firewall, NAT y VPN»

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 «RTSP frente a UDP: por qué RTSP se conecta pero el vídeo aparece en negro: RTP bloqueado por firewall, NAT y VPN», 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 «RTSP frente a UDP: por qué RTSP se conecta pero el vídeo aparece en negro: RTP bloqueado por firewall, NAT y VPN» es: Repara RTSP sin video cuando el control se conecta pero UDP RTP está bloqueado. Cubre reglas de firewall, puerto de protocolo RTSP, cruce de NAT, pérdida de VPN RTP, respaldo entrelazado de TCP y puertos de origen UDP 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: RTSP frente a UDP: por qué RTSP se conecta pero el vídeo aparece en negro: RTP bloqueado p

Para «RTSP frente a UDP: por qué RTSP se conecta pero el vídeo aparece en negro: RTP bloqueado por firewall, NAT y VPN», 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: Repara RTSP sin video cuando el control se conecta pero UDP RTP está bloqueado. Cubre regl

Cierre «Repara RTSP sin video cuando el control se conecta pero UDP RTP está bloqueado. Cubre reglas de firewall, puerto de protocolo RTSP, cruce de NAT, pérd» 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: El control funciona no significa que los medios funcionen

Para «El control funciona no significa que los medios funcionen», 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: Cabecera de Transporte revela el plan portuario

Cierre «Cabecera de Transporte revela el plan portuario» 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: Fallos comunes de firewall y NAT

Para «Fallos comunes de firewall y NAT», 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: Por qué el TCP entrelazado suele funcionar

Cierre «Por qué el TCP entrelazado suele funcionar» 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: RTCP puede ayudar a probar el camino

Para «RTCP puede ayudar a probar el camino», 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 de depuración

Cierre «Lista de verificación de depuración» 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 «RTSP frente a UDP: por qué RTSP se conecta pero el vídeo apar

Cierre «Evidencia reproducible para «RTSP frente a UDP: por qué RTSP se conecta pero el vídeo aparece en negro: RTP bloqueado por firewall, NAT y VPN»» 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
RTSP frente a UDP: por qué RTSP se conecta pero el vídeo aparece en negro: RTP bloqueado por firewall, NAT y VPN	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Repara RTSP sin video cuando el control se conecta pero UDP RTP está bloqueado. Cubre reglas de firewall, puerto de prot	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
El control funciona no significa que los medios funcionen	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Cabecera de Transporte revela el plan portuario	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Fallos comunes de firewall y NAT	Estado inicial, una acción y estado resultante	Otra persona reproduce el resultado declarado
Por qué el TCP entrelazado suele funcionar	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: