Resumen

  • Un SETUP aceptado creaba contexto en el servidor y devolvía un identificador de Session; una descripción SDP o una conexión TCP abierta no constituían esa aceptación.
  • El contexto podía pasar por conexiones de control sucesivas, pero el identificador no reemplazaba la URI, el estado del método, las credenciales ni la comprobación del camino de medios.
  • La continuidad dependía de que el servidor mantuviera el estado y recibiera señales de vida. TEARDOWN, la caducidad u otro final podían convertir el intento siguiente en 454 Session Not Found.

El mando a distancia no era el cable

RTSP apareció en 1998 para controlar audio y vídeo continuos sin obligar a que esos datos viajaran dentro del protocolo de control. Sus órdenes se parecían a HTTP; su memoria, no. Preparar un transporte, comenzar, pausar y terminar una reproducción exigía que el servidor relacionara varias peticiones con un mismo proceso.

RFC 2326 resolvió la cuestión negando que existiera una «conexión RTSP» con vida propia. Había una sesión mantenida por el servidor y rotulada con un identificador. Durante ella, el cliente podía abrir y cerrar varias conexiones fiables.

TCP seguía llevando órdenes y respuestas. Incluso podía transportar medios intercalados. Lo que no hacía era decidir por sí solo cuánto duraba el recuerdo de la operación. Perder el canal impedía enviar el siguiente PAUSE, pero no equivalía a TEARDOWN ni borraba automáticamente los puertos, pistas y estados ya aceptados.

El diseño asignó nombres distintos al camino por el que viajaba una orden y al contexto sobre el cual esa orden producía efectos.

La ficha de una presentación no abría una reproducción

Antes de SETUP, un cliente podía obtener una descripción. RFC 4566 define SDP como formato para expresar tipos de medio, codificaciones, direcciones de transporte y otros metadatos. No es un protocolo de transporte ni crea por sí mismo una sesión de control.

La palabra sesión en SDP puede hacer pensar que el trabajo ya está hecho. Una descripción señala pistas, formatos y referencias de control. No demuestra que el servidor haya reservado recursos para ese cliente, aceptado un transporte o almacenado un estado de reproducción.

SETUP era la frontera. La petición nombraba el recurso y ofrecía parámetros de entrega. Si el servidor encontraba una combinación admisible, escogía el transporte, guardaba el estado y respondía con los parámetros seleccionados. RFC 7826, la revisión de 2016, denomina a ese registro contexto de sesión RTSP.

La respuesta incluía un valor creado por el servidor en Session. SDP decía qué podía haber. SETUP confirmaba qué acababa de aceptar aquella máquina para aquel contexto. Conocer el catálogo no era prueba de reserva.

La segunda referencia señalaba memoria, no contenido

Una URI podía identificar la misma película para muchos clientes. El identificador de Session permitía distinguir dos entregas simultáneas de esa URI, y también reunir varias pistas bajo un control común.

RTSP 1.0 exigía una cadena opaca elegida al azar y de al menos ocho octetos. RTSP 2.0 estableció de 8 a 128 caracteres, generación criptográficamente aleatoria y una recomendación cercana a 128 bits de entropía. La referencia a RFC 4086 fijaba la calidad de aleatoriedad necesaria para dificultar la adivinación.

La propia especificación niega que eso baste contra el secuestro: el valor debe mantenerse confidencial entre cliente, servidor y proxies de confianza. Lo impredecible no se convierte automáticamente en identidad. Tampoco expresa que el usuario haya pagado, que conserve permiso ni que la orden sea válida en el estado actual.

RTSP recurrió al marco de autenticación HTTP para separar esas decisiones. Digest, definido en RFC 7616, tiene desafío, credenciales, nonce y controles de repetición propios. El mismo mensaje podía llevar autenticación y Session porque una capa decía quién intentaba actuar y otra qué estado almacenado debía localizarse.

Saber el identificador no borraba la URI

Tras SETUP, las órdenes relacionadas incluían Session. PLAY o PAUSE podían llegar por una conexión TCP nueva y encontrar el contexto anterior. Aun así, conservaban una URI y debían respetar el estado de la máquina de control.

La agregación muestra por qué. Audio y vídeo pueden compartir una línea temporal y responder a un solo PLAY. Un SETUP posterior puede pedir que otra pista entre en el mismo contexto. Pero RFC 7826 mantiene una URI de control agregado diferente de las URI de cada medio. La necesitan los proxies para encaminar, el servidor para saber sobre qué recurso actuar y los registros para conservar el alcance.

Un índice interno puede hallar el expediente sin definir todas las operaciones permitidas sobre él. Por eso RTSP distingue 454 Session Not Found, un método inválido en el estado presente y una operación agregada aplicada al nivel equivocado.

También protegió la parte ya aceptada. Si fracasa el SETUP que pretendía sumar una pista, RTSP 2.0 exige que sesión, transportes y parámetros previos queden como si la petición fallida nunca hubiese llegado. La ampliación no puede dejar una mitad silenciosa.

Una conexión contenía varias sesiones, una sesión usaba varias conexiones

RTSP 2.0 obliga a admitir conexiones TCP persistentes y transitorias. El cliente puede ejecutar SETUP y PLAY, cerrar el canal y abrir más tarde otro para PAUSE. La pérdida de TCP por caducidad de un NAT no tiene por qué destruir el estado de aplicación.

También puede ocurrir lo contrario: una conexión persistente sirve órdenes de varias sesiones. El socket no identifica la reproducción. Para que el servidor sepa por dónde enviar peticiones hacia el cliente, una sesión no debe usar más de una conexión a la vez. Esa restricción elige el canal vigente, no hace que sus vidas sean idénticas.

El camino de medios seguía separado. SETUP podía negociar RTP sobre UDP o datos intercalados, pero la conectividad real a través de NAT y cortafuegos requería comprobación. RFC 7825 adaptó ICE a medios controlados por RTSP porque un contexto correcto podía coexistir con candidatos que no se alcanzaban. Session identificaba el expediente; ICE y el tráfico mostraban la ruta.

Conservar estado exigía noticias de vida

Los recursos abandonados no podían quedar para siempre. La respuesta SETUP podía anunciar cuánto esperaría el servidor entre órdenes u otras señales; la caducidad predeterminada era de 60 segundos. En RTSP 2.0 el parámetro sólo aparece en respuestas y no cambia durante una sesión establecida.

Cualquier petición RTSP que referenciara el contexto podía renovarlo. Para un keep-alive puro se prefería SET_PARAMETER sin cuerpo. Si RTP estaba en uso, también podían contar los informes RTCP. RFC 3550 define los informes de emisor y receptor; RTSP los relaciona con direcciones, puertos y fuentes del servidor para tomarlos como actividad del lado cliente.

No se trata de una certeza absoluta. Los informes se programan, se pierden y ofrecen garantías estadísticas. Pueden reducir mucho el riesgo de una caducidad falsa sin demostrar que un espectador vio la imagen, que PLAY tuvo un efecto persistente o que la autorización seguía vigente. Mantener un contexto es una inferencia mucho más estrecha que certificar la experiencia.

El cliente podía conservar un número que ya no llegaba a nada

TEARDOWN marcaba el final normal. Aplicado a la URI agregada podía detener el conjunto y destruir el contexto; sobre una pista, cuando era válido, retiraba ese medio y la última retirada terminaba la sesión. El servidor también podía eliminarla por caducidad, redirección terminal o error irrecuperable.

Después, repetir la cadena exacta no devolvía el estado. 454 Session Not Found cubría un identificador ausente, inválido o caducado. La memoria del cliente no imponía memoria al servidor.

El valor opaco nunca fue un recipiente que contuviera la sesión. Era una dirección hacia un registro revocable. La conexión, la URI, el método, la autenticación, la ruta de medios y la señal de vida aportaban pruebas distintas. RTSP sólo funcionaba mientras ninguna fingiera ser todas las demás.