Protocolo de transmisión en tiempo real

El protocolo de transmisión en tiempo real (del inglés Real Time Streaming Protocol) establece y controla uno o muchos flujos sincronizados de datos, ya sean de audio o de video. El RTSP actúa como un mando a distancia mediante la red para servidores multimedia.

Descripción

RTSP es un protocolo no orientado a conexión, en lugar de esto el servidor mantiene una sesión asociada a un identificador, en la mayoría de los casos RTSP usa TCP para datos de control del reproductor y UDP para los datos de audio y vídeo aunque también puede usar TCP en caso de que sea necesario. En el transcurso de una sesión RTSP, un cliente puede abrir y cerrar varias conexiones de transporte hacia el servidor con tal de satisfacer las necesidades del protocolo.

De forma intencionada, el protocolo es similar en sintaxis y operación a HTTP de forma que los mecanismos de expansión añadidos a HTTP pueden, en muchos casos, añadirse a RTSP. Sin embargo, RTSP difiere de HTTP en un número significativo de aspectos:

• RTSP introduce nuevos métodos y tiene un identificador de protocolo diferente.
• Un servidor RTSP necesita analizar el estado de la conexión de manera continua, al contrario que HTTP.
• Tanto el servidor como el cliente pueden lanzar peticiones.
• Los datos son transportados por un protocolo diferente.

El protocolo soporta las siguientes operaciones:

Recuperar contenidos multimedia del servidor: El cliente puede solicitar la descripción de una presentación por HTTP o cualquier otro método. Si la presentación es multicast, la descripción contiene los puertos y las direcciones que serán usados. Si la presentación es unicast el cliente es el que proporciona el destino por motivos de seguridad.

Invitación de un servidor multimedia a una conferencia: Un servidor puede ser invitado a unirse a una conferencia existente en lugar de reproducir la presentación o grabar todo o una parte del contenido. Este modo es útil para aplicaciones de enseñanza distribuida dónde diferentes partes de la conferencia van tomando parte en la discusión.

Adición multimedia a una presentación existente: Particularmente para presentaciones en vivo, útil si el servidor puede avisar al cliente sobre los nuevos contenidos disponibles.

Propiedades

RTSP tiene las siguientes propiedades:

• Extensible: nuevos métodos y parámetros pueden ser fácilmente añadidos al RTSP
• Seguro: RTSP reutiliza mecanismos de seguridad web ya sea a los protocolos de transporte (TLS) o dentro del mismo protocolo. Todas las formas de autentificación HTTP ya sea básica o basada en resumen son directamente aplicables.
• Independiente del protocolo de transporte: RTSP puede usar indistintamente protocolos de datagrama no fiables (UDP) o datagramas fiables (RUDP, no muy extendido) o un protocolo fiable orientado a conexión como el TCP, aunque este último protocolo no es común en la transmisión de datos multimedia, ya que TCP puede provocar demoras y retrasos en el audio/vídeo debido a sistemas de control de errores y pérdidas.
• Capacidad multi-servidor: Cada flujo multimedia dentro de una presentación puede residir en servidores diferentes, el cliente automáticamente establece varias sesiones concurrentes de control con los diferentes servidores, la sincronización la lleva a término la capa de transporte.
• Control de dispositivos de grabación: El protocolo puede controlar dispositivos de grabación y reproducción (p.ej cámaras IP RTSP).
• Adecuado para aplicaciones profesionales: RTSP soporta resolución a nivel de frame mediante marcas temporales SMPTE para permitir edición digital.

Peticiones RTSP

Las peticiones RTSP están basadas en peticiones HTTP y generalmente son enviadas del cliente al servidor. A continuación se describen la más típicas:

DESCRIBE

Este método obtiene una descripción de una presentación o del objeto multimedia apuntado por una URL RTSP situada en un servidor. El servidor responde a esta petición con una descripción del recurso solicitado, entre otros datos la descripción contiene una lista de los flujos multimedia que serán necesarios para la reproducción. Esta solicitud/respuesta constituye la fase de inicialización del RTSP.

Ejemplo:

Cliente → Servidor:

DESCRIBE rtsp://unservidor.com/uncontenido (enlace roto disponible en Internet Archive; véase el historial, la primera versión y la última). RTSP/1.0
Accept: application/sdp, application/rtsl, application/ mheg

Servidor → Cliente:

RTSP/1.0 200 OK
Content-Type: application/sdp
Content-Length: 376
i=Descripción del contenido
m=audio 3456 RTP/AVP 0
m=video 2232 RTP/AVP 31

SETUP

Especifica cómo será transportado el flujo de datos, la petición contiene la url del flujo multimedia y una especificación de transporte, esta especificación típicamente incluye un puerto para recibir los datos RTP (audio o vídeo), y otro para los datos RTCP (meta-datos).

El servidor responde confirmando los parámetros escogidos y llena las partes restantes, como los puertos escogidos por el servidor. Cada flujo de datos debe ser configurado con SETUP antes de enviar una petición de PLAY.

Servidor → Cliente:

RTSP/1.0 200 OK
Session: 47112344
Transport: RTP/AVP;unicast;
client_port=4588-4589;server_port=6256-6257

PLAY

Una petición de PLAY provocará que el servidor comience a enviar datos de los flujos especificados utilizando los puertos configurados con SETUP.

Ejemplo:

Cliente → Servidor:

PLAY rtsp://unservidor.com/audio (enlace roto disponible en Internet Archive; véase el historial, la primera versión y la última). RTSP/1.0
Session: 12345678

PAUSE

Detiene temporalmente uno o todos los flujos, de manera que puedan ser recuperados con un PLAY posteriormente.

Ejemplo:

Cliente → Servidor:

PAUSE rtsp://unservidor.com/video1 (enlace roto disponible en Internet Archive; véase el historial, la primera versión y la última). RTSP/1.0
Session: 12345678

Servidor → Cliente:

RTSP/1.0 200 OK

TEARDOWN

Detiene la entrega de datos para la URL indicada liberando los recursos asociados.

Ejemplo:

Cliente → Servidor:

TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0
Session: 1234567 

Servidor → Cliente:

RTSP/1.0 200 OK

Sesión RTSP

• El cliente accede a la URL RTSP para colocar el nombre del servidor y el puerto.
• Si el nombre del servidor no está en formato IP, el cliente hace una consulta DNS para obtener la dirección correspondiente.
• El cliente inicia una conexión TCP hacia el servidor.
• Cuando la conexión está establecida correctamente, el cliente envía al servidor una petición OPTIONS. EL servidor devuelve información que puede incluir la versión de RTSP, la fecha, el número de sesión, el nombre del servidor y los métodos soportados.
• El cliente envía una petición DESCRIBE para obtener una descripción de la presentación. El servidor responde con todos los valores de inicialización necesarios para la presentación.
• El cliente envía SETUP para cada flujo de datos que se quiere reproducir. El SETUP especifica los protocolos aceptados para el transporte de los datos.
• El cliente inicializa los programas adecuados requeridos para reproducir la presentación.
• El cliente envía una petición PLAY que informa al servidor que ahora es el momento de comenzar a enviar datos.
• Durante la sesión, el cliente periódicamente hace ping al servidor utilizando peticiones SET_PARAMETER. Aunque la respuesta sea errónea el cliente la ignora informando al cliente que el servidor todavía está activo.
• Cuando la presentación termina o el usuario la para, el cliente envía un SET_PARAMETER que contiene las estadísticas de la sesión.
• El cliente envía TEARDOWN para dar por terminada la conexión con el servidor.

Ejemplo

Lo que se describe abajo es un ejemplo de uso de una sesión RTSP simple para controlar múltiples streams.

El cliente C solicita una presentación a un servidor multimedia M. El video es almacenado en un contenedor de archivos. El cliente ha obtenido un URL RTSP del contenedor de archivos

    C->M: DESCRIBE rtsp://foo/twister RTSP/1.0
          CSeq: 1

    M->C: RTSP/1.0 200 OK
          CSeq: 1
          Content-Type: application/sdp
          Content-Length: 164
          v=0
          o=- 2890844256 2890842807 IN IP4 172.16.2.93
          s=RTSP Session
          i=An Example of RTSP Session Usage
          a=control:rtsp://foo/twister
          t=0 0
          m=audio 0 RTP/AVP 0
          a=control:rtsp://foo/twister/audio
          m=video 0 RTP/AVP 26
          a=control:rtsp://foo/twister/video

    C->M: SETUP rtsp://foo/twister/audio RTSP/1.0
          CSeq: 2
          Transport: RTP/AVP;unicast;client_port=8000-8001

    M->C: RTSP/1.0 200 OK
          CSeq: 2
          Transport: RTP/AVP;unicast;client_port=8000-8001;
                     server_port=9000-9001
          Session: 12345678

    C->M: SETUP rtsp://foo/twister/video RTSP/1.0
          CSeq: 3
          Transport: RTP/AVP;unicast;client_port=8002-8003
          Session: 12345678

    M->C: RTSP/1.0 200 OK
          CSeq: 3
          Transport: RTP/AVP;unicast;client_port=8002-8003;
                     server_port=9004-9005
          Session: 12345678

    C->M: PLAY rtsp://foo/twister RTSP/1.0
          CSeq: 4
          Range: npt=0-
          Session: 12345678

    M->C: RTSP/1.0 200 OK
          CSeq: 4
          Session: 12345678
          RTP-Info: url=rtsp://foo/twister/video;
            seq=9810092;rtptime=3450012

    C->M: PAUSE rtsp://foo/twister/video RTSP/1.0
          CSeq: 5
          Session: 12345678

    M->C: RTSP/1.0 460 Only aggregate operation allowed
          CSeq: 5

    C->M: PAUSE rtsp://foo/twister RTSP/1.0
          CSeq: 6
          Session: 12345678

    M->C: RTSP/1.0 200 OK
          CSeq: 6
          Session: 12345678

    C->M: SETUP rtsp://foo/twister RTSP/1.0
          CSeq: 7
          Transport: RTP/AVP;unicast;client_port=10000

    M->C: RTSP/1.0 459 Aggregate operation not allowed
          CSeq: 7

Enlaces externos

• IETF - Real Time Streaming Protocol

• Datos: Q682598
• Multimedia: Real Time Streaming Protocol / Q682598