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
SETUPcon 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
PLAYhasta el primer paquete.
Lista de verificación de depuración
Utilice este flujo de trabajo:
- Confirme que RTSP
DESCRIBE,SETUPyPLAYsean exitosos. - Inspeccione el encabezado
Transporty 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.