Protocolo de transmisión en tiempo real

El Protocolo de transmisión en tiempo real (RTSP) es un protocolo de red de nivel de aplicación diseñado para multiplexar y empaquetar transmisiones de transporte multimedia (como medios interactivos, video y audio) sobre un protocolo de transporte adecuado. RTSP se utiliza en sistemas de entretenimiento y comunicaciones para controlar servidores de transmisión de medios. El protocolo se utiliza para establecer y controlar sesiones de medios entre puntos finales. Los clientes de los servidores de medios emiten comandos como reproducir, grabar y pausar, para facilitar el control en tiempo real de la transmisión de medios desde el servidor a un cliente (video bajo demanda) o de un cliente al servidor (grabación de voz).

Historia

RTSP fue desarrollado por RealNetworks, Netscape y la Universidad de Columbia. El primer borrador fue presentado al IETF en octubre de 1996 por Netscape y Progressive Networks, después de lo cual Henning Schulzrinne de la Universidad de Columbia presentó "RTSP'" ("RTSP prime") en diciembre de 1996. Los dos borradores fueron combinados para su estandarización por parte del Grupo de Trabajo de Control de Sesión Multimedia Multiparte (MMUSIC WG) del Grupo de Trabajo de Ingeniería de Internet (IETF) y los borradores adicionales fueron publicados por el grupo de trabajo. El estándar propuesto para RTSP se publicó como RFC 2326 en 1998. RTSP 2.0 se publicó como RFC 7826 en 2016 como reemplazo de RTSP 1.0. RTSP 2.0 se basa en RTSP 1.0 pero no es compatible con versiones anteriores salvo en el mecanismo de negociación de la versión básica y sigue siendo un "Estándar propuesto".

RTP

La transmisión de datos de transmisión en sí no es una tarea de RTSP. La mayoría de los servidores RTSP utilizan el Protocolo de transporte en tiempo real (RTP) junto con el Protocolo de control en tiempo real (RTCP) para la entrega de secuencias de medios. Sin embargo, algunos proveedores implementan protocolos de transporte propietarios. El software del servidor RTSP de RealNetworks, por ejemplo, también utilizó RealNetworks' Transporte de datos reales (RDT) patentado.

Directivas de protocolo

Si bien es similar en algunos aspectos a HTTP, RTSP define secuencias de control útiles para controlar la reproducción multimedia. Mientras que HTTP no tiene estado, RTSP tiene estado; se utiliza un identificador cuando es necesario para realizar un seguimiento de las sesiones simultáneas. Al igual que HTTP, RTSP usa TCP para mantener una conexión de extremo a extremo y, aunque la mayoría de los mensajes de control de RTSP son enviados por el cliente al servidor, algunos comandos viajan en la otra dirección (es decir, del servidor al cliente).

Aquí se presentan las solicitudes básicas de RTSP. También están disponibles algunas solicitudes HTTP típicas, como la solicitud OPTIONS. El número de puerto predeterminado de la capa de transporte es 554 tanto para TCP como para UDP; este último rara vez se usa para las solicitudes de control.

OPCIONES

Una solicitud OPTIONS devuelve los tipos de solicitud que el servidor aceptará.

C- títulos: OPTIONS rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 1
Pregunta: juego implícito
Requiere: gzipped-messages

S- títuloC: RTSP/1.0 200 OK
CSeq: 1
Público: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE

DESCRIBE

A DESCRIBE request includes an RTSP URL (rtsp://...), and the type of reply data that can be handled. Esta respuesta incluye la descripción de la presentación, típicamente en formato del Protocolo de descripción de la sesión (SDP). Entre otras cosas, la descripción de la presentación enumera las secuencias de medios controladas con la URL agregada. En el caso típico, hay un flujo de medios cada uno para audio y vídeo. Las URL de flujo de medios se obtienen directamente de los campos de control SDP o se obtienen mediante el gasto del campo de control SDP a la URL agregada.

C- títulos: DESCRIBE rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 2

S- títuloC: RTSP/1.0 200 OK
CSeq: 2
Content-Base: rtsp://example.com/media.mp4
Tipo de contenido: aplicación/sdp
Índice: 460

m=video 0 RTP/AVP 96
a=control:streamid=0
a=range:npt=0-7.741000
a=length:npt=7.741000
a=rtpmap:96 MP4V-ES/5544
a=mimetipo:string;"video/MP4V-ES"
a=AvgBitRate:integer;304018
a=StreamName:string; "boca de vídeo"
m=audio 0 RTP/AVP 97
a=control:streamid=1
a=range:npt=0-7.712000
a=length:npt=7.712000
a=rtpmap:97 mpeg4-generic/32000/2
a=mimetipo:string;"audio/mpeg4-generic"
a=AvgBitRate:integer;65790
a=StreamName:string;"hite de audio"

CONFIGURACIÓN

Una solicitud de SETUP especifica cómo un solo flujo de medios debe ser transportado. Esto debe hacerse antes de que se envíe una solicitud del PLAY. La solicitud contiene la URL de flujo de medios y un especificador de transporte. Este especificador típicamente incluye un puerto local para recibir datos RTP (audio o video), y otro para datos RTCP (información de datos). La respuesta del servidor generalmente confirma los parámetros elegidos, y llena las partes perdidas, como los puertos elegidos del servidor. Cada flujo multimedia debe configurarse usando SETUP antes de enviar una solicitud de reproducción agregada.

C- títulos: SETUP rtsp://example.com/media.mp4/streamid=0 RTSP/1.0
CSeq: 3
Transporte: RTP/AVP;unicast;client_port=8000-8001

S- títuloC: RTSP/1.0 200 OK
CSeq: 3
Transporte: RTP/AVP;unicast;client_port=8000-8001;server_port=9000-9001;src=1234ABCD
Período de sesiones: 12345678



C- títulos: SETUP rtsp://example.com/media.mp4/streamid=1 RTSP/1.0
CSeq: 3
Transporte: RTP/AVP;unicast;client_port=8002-8003
Período de sesiones: 12345678

S- títuloC: RTSP/1.0 200 OK
CSeq: 3
Transporte: RTP/AVP;unicast;client_port=8002-8003;server_port=9002-9003;src=1234ABCD
Período de sesiones: 12345678

JUGAR

Una solicitud PLAY hará que se jueguen una o todas las corrientes de medios. Las solicitudes de reproducción se pueden apilar enviando múltiples solicitudes PLAY. La URL puede ser la URL agregada (to play all media streams), o una URL única de flujo de medios (to play only that stream). Se puede especificar un rango. Si no se especifica ningún rango, el flujo se reproduce desde el principio y juega hasta el final, o, si el flujo se detiene, se reanuda en el punto en que se detuvo.

C- títulos: PLAY rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 4
Rango: npt=5-20
Período de sesiones: 12345678

S- títuloC: RTSP/1.0 200 OK
CSeq: 4
Período de sesiones: 12345678
RTP-Info: url=rtsp://example.com/media.mp4/streamid=0;seq=9810092;rtptime=3450012

PAUSA

Una solicitud de PAUSE suspende temporalmente una o todas las corrientes de medios, por lo que puede reanudarse más tarde con una solicitud de PLAY. La solicitud contiene una URL de flujo agregado o multimedia. Un parámetro de rango en una solicitud PAUSE especifica cuándo pausar. Cuando se omite el parámetro de rango, la pausa ocurre inmediatamente e indefinidamente.

C- títuloS: PAUSE rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 5
Período de sesiones: 12345678

S- títuloC: RTSP/1.0 200 OK
CSeq: 5
Período de sesiones: 12345678

GRABAR

Este método inicia la grabación de una gama de datos de medios según la descripción de la presentación. El sello de tiempo refleja el tiempo de inicio y final (UTC). Si no se da un intervalo de tiempo, utilice el tiempo de inicio o fin proporcionado en la descripción de la presentación. Si el período de sesiones ya ha comenzado, comience a grabar inmediatamente. El servidor decide si almacenar los datos registrados bajo la solicitud URI u otro URI. Si el servidor no utiliza la solicitud URI, la respuesta debe ser 201 y contener una entidad que describe los estados de la solicitud y se refiere al nuevo recurso, y un encabezado de localización.

C- títulos: RECORD rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 6
Período de sesiones: 12345678

S- títuloC: RTSP/1.0 200 OK
CSeq: 6
Período de sesiones: 12345678

ANUNCIAR

El método ANUNCIO tiene dos propósitos:

Cuando se envía de cliente a servidor, ANNOUNCE publica la descripción de una presentación o objeto multimedia identificado por la URL de solicitud a un servidor. Cuando se envía de servidor a cliente, ANNOUNCE actualiza la descripción de la sesión en tiempo real. Si se añade una nueva secuencia de medios a una presentación (por ejemplo, durante una presentación en vivo), toda la descripción de la presentación debe enviarse de nuevo, en lugar de sólo los componentes adicionales, para que los componentes puedan ser eliminados.

C- títulos: ANNOUNCE rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 7
Fecha: 23 ene 1997 15:35:06 GMT
Período de sesiones: 12345678
Tipo de contenido: aplicación/sdp
Índice: 332

v=0
o=mhandley 2890844526 2890845468 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminario sobre el protocolo de descripción del período de sesiones
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu (Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 3456 RTP/AVP 0
m=video 2232 RTP/AVP 31

S- títuloC: RTSP/1.0 200 OK
CSeq: 7

DESMONTAJE

Se utiliza una solicitud TEARDOWN para terminar la sesión. Detiene todos los flujos de medios y libera todos los datos relacionados de sesión en el servidor.

C- títulos: TEARDOWN rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 8
Período de sesiones: 12345678

S- títuloC: RTSP/1.0 200 OK
CSeq: 8

GET_PARAMETER

La solicitud GET_PARAMETER recupera el valor de un parámetro de una presentación o flujo especificado en la URI. El contenido de la respuesta y la respuesta queda a la aplicación. GET_PARAMETER sin cuerpo de entidad puede ser utilizado para probar la vida del cliente o servidor ("ping").

S- tituladaC: GET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 9
Tipo de contenido: texto/parameters
Período de sesiones: 12345678
Índice: 15

packets_recibido
jitter

C- títulos: RTSP/1.0 200 OK
CSeq: 9
Índice: 46
Tipo de contenido: texto/parameters

packets_recibido: 10
jitter: 0.3838

ESTABLECER_PARÁMETROS

Este método solicita establecer el valor de un parámetro para una presentación o flujo especificado por el URI.

C- títulos: SET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 10
Índice: 20
Tipo de contenido: texto/parametros

barparam: barniz

S- títuloC: RTSP/1.0 451 Parámetro inválido
CSeq: 10
Índice: 10
Tipo de contenido: texto/parametros

barparam

REDIRECCIÓN

Una solicitud REDIRECT informa al cliente que debe conectarse a otra ubicación del servidor. Contiene el encabezado obligatorio Ubicación, lo que indica que el cliente debe emitir solicitudes para esa URL. Puede contener el parámetro Rango, que indica cuando la redirección tiene efecto. Si el cliente quiere seguir enviando o recibiendo medios para esta URI, el cliente DEBE emitir una solicitud TEARDOWN para la sesión actual y un SETUP para la nueva sesión en el host designado.

S- títuloC: REDIRECT rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 11
Ubicación: rtsp://bigserver.com:8001
Rango: reloj=19960213T143205Z-

Datos binarios integrados (entrelazados)

Ciertos diseños de cortafuegos y otras circunstancias pueden obligar a un servidor a entrelazar métodos RTSP y datos de secuencia. Este cruce debe evitarse generalmente a menos que sea necesario, ya que complica el funcionamiento del cliente y del servidor e impone una sobrecarga adicional. Datos binarios entrelazados SHOULD sólo se utilizarán si RTSP se lleva a través de TCP. Los datos de corriente como paquetes RTP son encapsulados por un signo de Dólar ASCII (24 hexadecimal), seguido de un identificador de canales de un byte, seguido de la longitud de los datos binarios encapsulados como un entero binario de dos bytes en orden de byte de red. Los datos de flujo se siguen inmediatamente después, sin un CRLF, pero incluyendo los encabezados de protocolo de capa superior. Cada bloque $ contiene exactamente una unidad de protocolo de capa superior, por ejemplo, un paquete RTP.

C- títulos: SETUP rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 3
Transporte: RTP/AVP/TCP;interleaved=0-1

S- títuloC: RTSP/1.0 200 OK
CSeq: 3
Fecha: 05 de junio de 1997 18:57:18 GMT
Transporte: RTP/AVP/TCP;interleaved=0-1
Período de sesiones: 12345678

C- títulos: PLAY rtsp://example.com/media.mp4 RTSP/1.0
CSeq: 4
Período de sesiones: 12345678

S- títuloC: RTSP/1.0 200 OK
CSeq: 4
Período de sesiones: 12345678
Fecha: 05 de junio de 1997 18:59:15 GMT
RTP-Info: url=rtsp://example.com/media.mp4;seq=232433;rtptime=972948234

S- título: $00{2 byte length}{"length" bytes data, w/RTP header}
S- título: $00{2 byte length}{"length" bytes data, w/RTP header}
S- confíaC: $01{2 byte length}{"length" bytes RTCP packet}

Adaptación de tarifas

RTSP usando RTP y RTCP permite la implementación de la adaptación de velocidad.

Implementaciones

Servidor

• Darwin Streaming Server: Versión de código abierto de QuickTime Streaming Server mantenida por Apple.
• Feng: Lean and mean streaming server with focus on rfc compliance.
• GStreamer basado RTSP Server y cliente.
• Helix DNA Servidor: servidor de streaming de RealNetworks. Viene en sabores de código abierto y patentados.
• Helix Universal Server: RealNetworks servidor de streaming comercial para RTSP, RTMP, iOS, Silverlight y HTTP
• LIVE555 liveMedia / openRTSP: Open source C++ servidor y bibliotecas cliente utilizadas en clientes conocidos como VLC y mplayer.
• Moción: Una aplicación gratuita de software CCTV para Linux.
• Nimble Streamer admite la tirada RTSP y anuncia entrada con la salida de reproducción interconectada TCP.
• pvServer: Antiguamente llamado PacketVideo Streaming Server, este es el producto del servidor de transmisión de Alcatel-Lucent.
• QuickTime Streaming Server: El servidor de transmisión de código cerrado de Apple que se envía con Mac OS X Server.
• VideoLAN: reproductor multimedia de código abierto y servidor de streaming.
• Windows Media Servicios: Microsoft servidor de streaming previamente incluido con Windows Server que utiliza RTSP modificado con extensiones de Windows Media
• Motor de streaming de Wowza: servidor de streaming multiformato para RTSP/RTP, RTMP, MPEG-TS, ICY, HTTP (HTTP Live Streaming, HTTP Dynamic Streaming, Smooth Streaming, MPEG-DASH), WebRTC
• YouTube implementó un frontal web móvil en junio de 2007 que sirve video a través de este protocolo.

Muchas cámaras de seguridad/CCTV, a menudo llamadas cámaras IP, también son compatibles con la transmisión RTSP, especialmente aquellas con perfiles ONVIF G, S, T.

Cliente

• Astra
• cURL (comienzo con la versión 7.20.0-9 February 2010)
• FFmpeg
• GStreamer
• JetAudio
• LIVE555 liveMedia / openRTSP: Open source C++ servidor y bibliotecas cliente utilizadas en clientes conocidos como VLC y mplayer.
• Media Player Classic
• MPlayer
• MythTV vía Freebox
• QuickTime
• RealPlayer
• Skype
• Spotify
• VLC media player
• Winamp
• Windows Media Player
• xine
• ZoneMinder
• Moción (software de vigilancia)