2026-06-02

La transmisión RTSP se detiene después de 30 segundos: Keepalive, tiempo de espera de sesión, NAT y cámara inactiva se desconecta

Por qué las transmisiones RTSP se detienen después de 30 segundos, 60 segundos o unos minutos, y cómo depurar solicitudes de mantenimiento de actividad, tiempo de espera de sesión, NAT, silencio RTP y desconexiones de cámara.

Una transmisión RTSP que se inicia correctamente y luego se detiene después de 30 segundos es un problema diferente de una transmisión que nunca se inicia. La autenticación funcionó. El SDP fue devuelto. SETUP y PLAY probablemente tuvieron éxito. Es posible que los medios hayan llegado por un tiempo. Luego, la cámara cerró la sesión, el RTP se detuvo, el reproductor se congeló o se agotó el tiempo de conexión.

Búsquedas como "la transmisión RTSP se detiene después de 30 segundos", "tiempo de espera de mantenimiento de RTSP", "la transmisión de la cámara se desconecta después de un minuto" y "tiempo de espera de la sesión RTSP" generalmente apuntan a un problema de duración de la sesión. Es posible que la transmisión necesite solicitudes de mantenimiento de conexión, que el mapeo NAT expire, que la cámara cierre sesiones RTSP inactivas, que los medios UDP se bloqueen después de un cambio de ruta o que RTCP pueda revelar una pérdida de medios antes de la desconexión.

RTSP Inspector es útil aquí porque la línea de tiempo es importante. Necesita saber qué sucedió en el segundo 0, el segundo 30, el segundo 60 y el momento exacto en que se detuvo la transmisión.

Por qué RTSP puede detenerse después de comenzar

Las causas comunes incluyen:

El cliente no envía RTSP keepalive.
La cámara espera que GET_PARAMETER se mantenga activo.
La cámara espera que "OPCIONES" se mantengan activas.
El tiempo de espera de la sesión RTSP es más corto de lo esperado.
El estado de NAT o firewall caduca.
UDP RTP se detiene mientras RTSP TCP permanece abierto.
La cámara cierra la conexión TCP después del silencio multimedia.
El cliente utilizó una URL de control agregado incorrecta.
El firmware de la cámara tiene un error de limpieza de sesión.
RTCP informa pérdida o fluctuación de paquetes antes de que la transmisión se congele.

La solución depende de qué capa se detuvo primero: control RTSP, medios RTP, retroalimentación RTCP o la ruta TCP/UDP subyacente.

Encabezado y tiempo de espera de la sesión RTSP

Después de SETUP, la cámara normalmente devuelve un encabezado Session:

RTSP/1.0 200 OK
Session: 12345678;timeout=60
Transport: RTP/AVP/TCP;unicast;interleaved=0-1

OPTIONS vs GET_PARAMETER keepalive

Two common keepalive methods are:

OPTIONS rtsp://camera/stream RTSP/1.0
Session: 12345678

GET_PARAMETER rtsp://camera/stream RTSP/1.0
Session: 12345678

When debugging, check:

Aggregate control URL problems

This can create subtle behavior:

NAT and firewall idle timeout

Symptoms:

Camera idle disconnects

Look for:

RTP silence vs RTSP disconnect

Checklist for streams that stop after 30 seconds

Use this process:

A useful report includes:

Final diagnosis

Evidencia reproducible para «La transmisión RTSP se detiene después de 30 segundos: Keepalive, tiempo de espera de sesión, NAT y cámara inactiva se desconecta»

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 «La transmisión RTSP se detiene después de 30 segundos: Keepalive, tiempo de espera de sesión, NAT y cámara inactiva se desconecta», 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.

De la observación a un veredicto por capas

En «La transmisión RTSP se detiene después de 30 segundos: Keepalive, tiempo de espera de sesión, NAT y cámara inactiva se desconecta», escribe primero lo observado y después la interpretación. Una observación puede localizarse en la captura: estado RTSP asociado a CSeq, valor SDP, respuesta Transport, hueco entre secuencias, cambio de SSRC o diferencia entre RTP timestamp y RTCP sender report. «El servidor es lento» o «el codec es incompatible» sigue siendo una hipótesis hasta que una evidencia concreta la explique mejor que las alternativas.

Divide el flujo en fronteras. Primero se abre TCP. Después se aceptan OPTIONS o DESCRIBE. El SDP debe describir una pista utilizable, control URL, payload type y clock rate. SETUP necesita una respuesta Transport compatible y PLAY una Session válida. Solo entonces se evalúan llegada RTP, orden, tiempo y preparación del decoder. Detente en la primera frontera sin prueba de éxito; no permitas que datos posteriores oculten una ausencia anterior.

Mantén fuente e intervalo constantes en comparaciones. Para UDP frente a TCP interleaved usa la misma ruta y credenciales. Para main stream frente a sub stream conserva cliente y transporte. Al comparar VLC con un VMS, registra métodos, cabeceras y URL reales; una diferencia de control URL, Authorization, Session o keepalive puede explicar el resultado mejor que el nombre del programa.

Matriz de descarte

Empieza con dos hipótesis. Si no llega multimedia, UDP puede estar bloqueado o el servidor puede enviar a otros puertos. TCP interleaved prueba la primera; comparar oferta y respuesta Transport, IP y puertos prueba la segunda. Para imagen dañada, la secuencia RTP separa pérdida de paquetes de inicialización incompleta, mientras que SPS/PPS/VPS antes del primer frame prueba la hipótesis del codec.

Para cada hipótesis anota evidencia a favor y evidencia que podría refutarla. Una afirmación que ninguna captura puede negar es demasiado amplia. «NAT elimina UDP» queda refutado si RTP llega al puerto del cliente. «Faltan parámetros H.264» queda refutado al ver SPS y PPS válidos antes de IDR. Así el informe conserva prioridad y no se convierte en una lista desordenada.

Interpretar el tiempo sin excederse

RTSP CSeq ordena transacciones, RTP sequence ordena paquetes, RTP timestamp expresa tiempo de muestreo y el reloj de captura expresa llegada al punto observado. No son el mismo reloj. Variación de llegada no demuestra drift; un salto timestamp no demuestra pérdida sin secuencia. Para sincronizar audio y vídeo, los RTCP sender reports relacionan relojes RTP distintos con una referencia común.

Paquete final de aceptación

Cierra el caso cuando el arreglo se repita desde una conexión nueva con un solo cambio documentado. El informe debe indicar entradas, última frontera correcta, primera evidencia fallida, cambio, resultado y pruebas pendientes. Adjunta un fragmento pequeño del transcript o estadísticas relevantes. Oculta secretos, pero conserva CSeq, Session saneada, SSRC e intervalo.

Usa la solución de problemas RTSP para reconstruir el flujo y los informes de RTSP Inspector para entregar la frontera al equipo de cámara, red o VMS.

Registro del cambio y prueba de regresión

Convierte el arreglo en un registro repetible. Indica valor anterior y nuevo, lugar de configuración, hora de reconexión y efecto esperado en los paquetes. Con TCP interleaved no basta «ya hay imagen»: la multimedia debe dejar de depender de puertos UDP y aparecer en los canales interleaved negociados. Si cambia el control URL, SETUP debe usar la ruta nueva y PLAY y keepalive deben conservar la misma Session.

Cuando sea seguro, realiza un control negativo. Restaura el valor anterior en un entorno de prueba o compara una captura previa con entradas iguales; debe reaparecer la misma frontera fallida. Así un reinicio casual, una caché o un cambio de red no documentado no se confunde con la solución. En una cámara de producción usa evidencia histórica y no provoques una caída.

Mantén la conexión más tiempo que el keepalive y el timeout de Session. Revisa OPTIONS o GET_PARAMETER y la continuidad de CSeq y Session. Para RTP compara pérdida, duplicados y reordenación en ventanas iguales antes y después. Para codec abre una conexión nueva y espera el primer IDR; un decoder ya iniciado puede ocultar parámetros iniciales ausentes.

Limita la afirmación: «main stream por TCP verificado diez minutos con este cliente» es mejor que «RTSP arreglado». Especifica pista, transporte, codec, cliente y duración. Deja abiertos audio, sub stream o reconexión si no se probaron.

Separa hechos y recomendación. Los hechos son respuestas, paquetes y medidas; la recomendación propone un cambio de cámara, firewall o cliente. Otro equipo debe poder aceptar los hechos aunque elija otra solución. Termina con responsable, siguiente acción y criterio de cierre, y entrega el intervalo mediante la guía de informes RTSP.