2026-06-02

Sesión RTSP 454 no encontrada: por qué falla la CONFIGURACIÓN o la REPRODUCCIÓN después de que se inicia la conexión de una cámara

Cómo solucionar errores de sesión no encontrada RTSP 454 en cámaras IP, NVR, ffmpeg, VLC, SETUP, PLAY, ID de sesión, keepalive y sesiones RTSP obsoletas.

"454 Sesión no encontrada" es uno de los errores RTSP que confunde a los usuarios porque se puede acceder claramente a la cámara. La conexión TCP se abrió. Es posible que la URL haya respondido a "OPCIONES" o incluso a "DESCRIBIR". Es posible que la autenticación haya funcionado. Luego, SETUP, PLAY, keepalive o una solicitud posterior falla con 454 Session Not Found.

Los usuarios buscan "sesión RTSP 454 no encontrada", "método ffmpeg PLAY falló 454", "cámara VLC RTSP 454" y "sesión de cámara RTSP no encontrada" cuando una transmisión no falla en el primer paso. Este error generalmente significa que el servidor RTSP no reconoce el ID de sesión utilizado por el cliente, que la sesión expiró, que el cliente envió una solicitud antes de que existiera una sesión o que la ruta de transmisión/URL de control provocó un estado no coincidente.

RTSP Inspector es útil porque 454 no es un problema del decodificador de video. Es evidencia del estado de la sesión RTSP.

Qué significa 454 Sesión no encontrada

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

RTSP/1.0 200 OK
Session: 12345678;timeout=60

Later requests should use that session:

PLAY rtsp://192.168.1.50/stream1 RTSP/1.0
Session: 12345678

Si la cámara no reconoce 12345678, puede devolver:

RTSP/1.0 454 Session Not Found

That can happen because the client used the wrong Session ID, the camera expired it, the camera restarted internally, a proxy lost state, or the request URI does not match the session context.

Common causes

High-probability causes include:

PLAY sent without a successful SETUP.
Client reused a stale Session ID after reconnect.
Camera timed out the session because keepalive was missing.
SETUP succeeded for one track but PLAY used a different aggregate URL.
NVR session state was cleared while the client kept the old session.
Camera returned a Session header with parameters and the client parsed it incorrectly.
Multiple clients exceeded camera session capacity.
Firmware bug after encoder restart or profile switch.
RTSP proxy or relay did not preserve session affinity.

The error is about server-side state, not necessarily wrong credentials.

Session header parsing problems

Some Session headers include parameters:

Session: 12345678;timeout=60

El identificador de sesión es 12345678; timeout=60 es un parámetro. Si un cliente envía el valor completo incorrectamente o elimina la parte incorrecta, la cámara puede rechazar solicitudes posteriores.

Un buen diagnóstico debe preservar exactamente lo que devolvió la cámara y exactamente lo que el cliente envió más tarde.

Configuración de pistas y reproducción agregada

Para transmisiones multipista, el cliente puede enviar solicitudes de "CONFIGURACIÓN" separadas para pistas de video y audio. Entonces puede enviar un PLAY agregado.

El SDP podría contener:

a=control:*
a=control:trackID=1
a=control:trackID=2

If the client chooses the wrong control URL, the camera may create session state for one resource and reject playback on another. This can look like a session error even when authentication and SDP are correct.

Session timeout and keepalive

If 454 appears after 30, 60, or 120 seconds, inspect keepalive. The camera may expire the session if the client does not send OPTIONS or GET_PARAMETER before timeout.

Important questions:

What timeout did the camera advertise?
Did the client send keepalive?
Did keepalive include the correct Session header?
Did the camera return 200 OK?
Did 454 happen immediately after a missed keepalive interval?

If the timing matches the timeout, this is a session lifetime problem.

Reconnect logic can create stale sessions

Some applications reconnect quickly after network loss. If the app keeps old session state after reconnect, it may send requests using a Session ID from the previous TCP connection. Many cameras treat that as invalid.

The correct behavior is usually to run a fresh RTSP sequence:

OPTIONS
DESCRIBE
SETUP
PLAY

Do not assume the camera remembers an old Session ID after a reconnect.

Debug checklist

Use this process:

Find the first 454 Session Not Found.
Identify which RTSP method received it.
Locate the SETUP response that created the session.
Compare the Session ID returned by camera with the Session ID sent by client.
Check whether the Session header included parameters.
Check whether keepalive occurred before timeout.
Check whether RTSP TCP reconnected before 454.
Compare track control URLs and aggregate control URL.
Check whether multiple clients are opening the same camera stream.
Test direct camera vs NVR/proxy path.

Final diagnosis

RTSP 454 Session Not Found means the RTSP server rejected the client's session state. The root cause may be stale Session ID, missing keepalive, wrong control URL, expired session, proxy state loss, or camera firmware behavior. The fix starts with the RTSP method sequence and Session header evidence.

RTSP Inspector helps expose that sequence so the problem can be diagnosed at the RTSP state-machine layer instead of being mistaken for a codec, player, or generic network issue.

Evidencia reproducible para «Sesión RTSP 454 no encontrada: por qué falla la CONFIGURACIÓN o la REPRODUCCIÓN después de que se inicia la conexión de una cámara»

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 «Sesión RTSP 454 no encontrada: por qué falla la CONFIGURACIÓN o la REPRODUCCIÓN después de que se inicia la conexión de una cámara», 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 «Sesión RTSP 454 no encontrada: por qué falla la CONFIGURACIÓN o la REPRODUCCIÓN después de que se inicia la conexión de una cámara», 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.