Protocolo de transmisión en tiempo real (RTSP)
El Real Time Streaming Protocol (RTSP) o Protocolo de transmisión en tiempo real es un protocolo de red de nivel de aplicación diseñado para multiplexar y empaquetar flujos de transporte multimedia (como medios interactivos, video y audio) a través de 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 a pedido) o desde 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 se fusionaron para su estandarización por parte de Multiparty Multimedia Session. Control Working Group (MMUSIC WG) del Internet Engineering Task Force (IETF) y otros borradores 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, excepto 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 de servidor RTSP de RealNetworks, por ejemplo, también utilizó Real Data Transport (RDT) propiedad de RealNetworks.
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, mientras que 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 de OPCIONES devuelve los tipos de solicitud que aceptará el servidor.
C->S: OPCIONES rtsp://example.com/media.mp4 RTSP/1.0 CSec: 1 Requerir: juego implícito Proxy-Require: mensajes comprimidos con gzip S->C: RTSP/1.0 200 OK CSec: 1 Público: DESCRIBIR, CONFIGURAR, DESMONTAR, REPRODUCIR, PAUSAR
DESCRIBIR
Una solicitud DESCRIBE incluye una URL RTSP (rtsp://...) y el tipo de datos de respuesta que se pueden manejar. Esta respuesta incluye la descripción de la presentación, normalmente en formato de Protocolo de descripción de sesión (SDP). Entre otras cosas, la descripción de la presentación enumera los flujos de medios controlados con la URL agregada. En el caso típico, hay un flujo de medios para cada flujo de audio y video. Las URL de flujo de medios se obtienen directamente de los campos de control de SDP o se obtienen agregando el campo de control de SDP a la URL agregada.
C->S: DESCRIBE rtsp://example.com/media.mp4 RTSP/1.0 CSec: 2 S->C: RTSP/1.0 200 OK CSec: 2 Base de contenido: rtsp://example.com/media.mp4 Tipo de contenido: aplicación/sdp Longitud del contenido: 460 m=vídeo 0 RTP/AVP 96 a=control:streamid=0 a=rango:npt=0-7.741000 a=longitud:npt=7.741000 a=rtpmap:96 MP4V-ES/5544 a=tipo mime:cadena;"video/MP4V-ES" a = Tasa de bits promedio: entero; 304018 a=StreamName:string;"pista de video sugerida" m=audio 0 RTP/AVP 97 a=control:streamid=1 a=rango:npt=0-7.712000 a=longitud:npt=7.712000 a=rtpmap:97 mpeg4-genérico/32000/2 a=tipo mime:cadena;"audio/mpeg4-genérico" a = Tasa de bits promedio: entero; 65790 a=StreamName:string;"pista de audio sugerida"
CONFIGURACIÓN
Una solicitud SETUP especifica cómo se debe transportar un solo flujo de medios. Esto debe hacerse antes de que se envíe una solicitud de PLAY. La solicitud contiene la URL del flujo de medios y un especificador de transporte. Este especificador generalmente incluye un puerto local para recibir datos RTP (audio o video) y otro para datos RTCP (metainformación). La respuesta del servidor generalmente confirma los parámetros elegidos y completa las partes que faltan, como los puertos elegidos por el servidor. Cada flujo de medios debe configurarse mediante SETUP antes de que se pueda enviar una solicitud de reproducción agregada.
C->S: CONFIGURAR rtsp://example.com/media.mp4/streamid=0 RTSP/1.0 CSec: 3 Transporte: RTP/AVP;unicast;client_port=8000-8001 S->C: RTSP/1.0 200 OK CSec: 3 Transporte: RTP/AVP;unidifusión;puerto_cliente=8000-8001;puerto_servidor=9000-9001;ssrc=1234ABCD Sesión: 12345678 C->S: CONFIGURAR rtsp://example.com/media.mp4/streamid=1 RTSP/1.0 CSec: 3 Transporte: RTP/AVP;unidifusión;puerto_cliente=8002-8003 Sesión: 12345678 S->C: RTSP/1.0 200 OK CSec: 3 Transporte: RTP/AVP;unidifusión;puerto_cliente=8002-8003;puerto_servidor=9002-9003;ssrc=1234ABCD Sesión: 12345678
DESEMPEÑAR
Una solicitud de PLAY hará que se reproduzcan uno o todos los flujos de medios. Las solicitudes de reproducción se pueden apilar enviando varias solicitudes de reproducción. La URL puede ser la URL agregada (para reproducir todos los flujos de medios) o una sola URL de flujo de medios (para reproducir solo ese flujo). Se puede especificar un rango. Si no se especifica un rango, la secuencia se reproduce desde el principio y hasta el final o, si la secuencia está en pausa, se reanuda en el punto en que se detuvo.
C->S: REPRODUCIR rtsp://example.com/media.mp4 RTSP/1.0 CSec: 4 Rango: npt=5-20 Sesión: 12345678 S->C: RTSP/1.0 200 OK CSec: 4 Sesión: 12345678 Información RTP: url=rtsp://example.com/media.mp4/streamid=0;seq=9810092;rtptime=3450012
PAUSA
Una solicitud de PAUSA detiene temporalmente uno o todos los flujos de medios, por lo que luego se puede reanudar con una solicitud de REPRODUCCIÓN. La solicitud contiene una URL agregada o de flujo de medios. Un parámetro de rango en una solicitud de PAUSA especifica cuándo hacer una pausa. Cuando se omite el parámetro de rango, la pausa se produce de forma inmediata e indefinida.
C->S: PAUSA rtsp://example.com/media.mp4 RTSP/1.0 CSec: 5 Sesión: 12345678 S->C: RTSP/1.0 200 OK CSec: 5 Sesión: 12345678
REGISTRO
Este método inicia la grabación de una variedad de datos multimedia de acuerdo con la descripción de la presentación. La marca de tiempo refleja la hora de inicio y finalización (UTC). Si no se proporciona un intervalo de tiempo, utilice la hora de inicio o finalización proporcionada en la descripción de la presentación. Si la sesión ya ha comenzado, comience a grabar inmediatamente. El servidor decide si almacenar los datos registrados bajo el URI de solicitud u otro URI. Si el servidor no usa el URI de solicitud, la respuesta debe ser 201 y contener una entidad que describa los estados de la solicitud y se refiera al nuevo recurso, y un encabezado de ubicación.
C->S: GRABAR rtsp://example.com/media.mp4 RTSP/1.0 CSec: 6 Sesión: 12345678 S->C: RTSP/1.0 200 OK CSec: 6 Sesión: 12345678
ANUNCIAR
El método ANUNCIO tiene dos propósitos:Cuando se envía del cliente al servidor, ANNOUNCE publica la descripción de una presentación u objeto multimedia identificado por la URL de solicitud en un servidor. Cuando se envía del servidor al cliente, ANNOUNCE actualiza la descripción de la sesión en tiempo real. Si se agrega un nuevo flujo de medios a una presentación (p. ej., durante una presentación en vivo), la descripción completa de la presentación debe enviarse nuevamente, en lugar de solo los componentes adicionales, para que los componentes puedan eliminarse.
C->S: ANUNCIAR rtsp://example.com/media.mp4 RTSP/1.0 CSec: 7 Fecha: 23 de enero de 1997 15:35:06 GMT Sesión: 12345678 Tipo de contenido: aplicación/sdp Longitud del contenido: 332 v=0 o=mhandley 2890844526 2890845468 EN IP4 126.16.64.4 Seminario s=SDP i=Un Seminario sobre el protocolo de descripción de sesión u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps e=mjh@isi.edu (Mark Handley) c=EN IP4 224.2.17.12/127 t=2873397496 2873404696 a=recvonly m=audio 3456 RTP/AVP 0 m=vídeo 2232 RTP/AVP 31 S->C: RTSP/1.0 200 OK CSec: 7
DEMOLER
Se utiliza una solicitud de DESMONTAJE para terminar la sesión. Detiene todos los flujos de medios y libera todos los datos relacionados con la sesión en el servidor.
C->S: DESMONTAJE rtsp://example.com/media.mp4 RTSP/1.0 CSec: 8 Sesión: 12345678 S->C: RTSP/1.0 200 OK CSec: 8
GET_PARAMETER
La solicitud GET_PARAMETER recupera el valor de un parámetro de una presentación o flujo especificado en el URI. El contenido de la respuesta y la respuesta se deja a la implementación. GET_PARAMETER sin cuerpo de entidad se puede usar para probar la actividad del cliente o del servidor ("ping").
S->C: GET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0 CSec: 9 Tipo de contenido: texto/parámetros Sesión: 12345678 Longitud del contenido: 15 paquetes_recibidos estar nervioso C->S: RTSP/1.0 200 OK CSec: 9 Longitud del contenido: 46 Tipo de contenido: texto/parámetros paquetes_recibidos: 10 fluctuación: 0.3838
SET_PARAMETER
Este método solicita establecer el valor de un parámetro para una presentación o flujo especificado por el URI.
C->S: ESTABLECER_PARÁMETRO rtsp://example.com/media.mp4 RTSP/1.0 CSec: 10 Longitud del contenido: 20 Tipo de contenido: texto/parámetros barparam: cosas de bar S->C: RTSP/1.0 451 Parámetro no válido CSec: 10 Longitud del contenido: 10 Tipo de contenido: texto/parámetros barparam
REDIRECTO
Una solicitud REDIRECT informa al cliente que debe conectarse a otra ubicación de servidor. Contiene el encabezado obligatorio Ubicación, que indica que el cliente debe emitir solicitudes para esa URL. Puede contener el parámetro Rango, que indica cuándo surte efecto la redirección. Si el cliente desea continuar enviando o recibiendo medios para este URI, DEBE emitir una solicitud de DESMONTAJE para la sesión actual y una CONFIGURACIÓN para la nueva sesión en el host designado.
S->C: REDIRECCIÓN rtsp://example.com/media.mp4 RTSP/1.0 CSec: 11 Ubicación: rtsp://bigserver.com:8001 Rango: reloj=19960213T143205Z-
Datos binarios integrados (entrelazados)
Ciertos diseños de firewall y otras circunstancias pueden obligar a un servidor a intercalar métodos RTSP y transmitir datos. Este intercalado generalmente debe evitarse a menos que sea necesario, ya que complica la operación del cliente y del servidor e impone una sobrecarga adicional. Los datos binarios intercalados DEBERÍAN utilizarse únicamente si RTSP se transmite a través de TCP. Los datos de flujo, como los paquetes RTP, se encapsulan con un signo de dólar ASCII (24 hexadecimal), seguido de un identificador de canal de un byte, seguido de la longitud de los datos binarios encapsulados como un entero binario de dos bytes en orden de bytes de red. Los datos de flujo siguen inmediatamente después, sin CRLF, pero incluidos los encabezados de protocolo de la capa superior. Cada bloque $ contiene exactamente una unidad de datos de protocolo de capa superior, por ejemplo, un paquete RTP.
C->S: CONFIGURAR rtsp://example.com/media.mp4 RTSP/1.0 CSec: 3 Transporte: RTP/AVP/TCP;intercalado=0-1 S->C: RTSP/1.0 200 OK CSec: 3 Fecha: 05 de junio de 1997 18:57:18 GMT Transporte: RTP/AVP/TCP;intercalado=0-1 Sesión: 12345678 C->S: REPRODUCIR rtsp://example.com/media.mp4 RTSP/1.0 CSec: 4 Sesión: 12345678 S->C: RTSP/1.0 200 OK CSec: 4 Sesión: 12345678 Fecha: 05 de junio de 1997 18:59:15 GMT Información RTP: url=rtsp://example.com/media.mp4;seq=232433;rtptime=972948234 S->C: $00{longitud de 2 bytes}{datos de bytes de "longitud", con encabezado RTP} S->C: $00{longitud de 2 bytes}{datos de bytes de "longitud", con encabezado RTP} S->C: $01{longitud de 2 bytes}{paquete RTCP de bytes de "longitud"}
Adaptación de tarifas
RTSP que utiliza 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: servidor de transmisión simple y eficiente con enfoque en el cumplimiento de rfc.
- Cliente y servidor RTSP basado en GStreamer.
- Helix DNA Server: servidor de transmisión de RealNetworks. Viene en versiones de código abierto y patentadas.
- Helix Universal Server: servidor de transmisión comercial RealNetworks para clientes de medios de transmisión RTSP, RTMP, iOS, Silverlight y HTTP
- LIVE555 liveMedia / openRTSP: servidor C++ de código abierto y bibliotecas de cliente utilizadas en clientes conocidos como VLC y mplayer.
- Motion: una aplicación de software de CCTV gratuita para Linux.
- Nimble Streamer es compatible con RTSP pull y anuncia la entrada con la salida de reproducción intercalada de TCP.
- pvServer: anteriormente llamado PacketVideo Streaming Server, este es el producto de servidor de streaming de Alcatel-Lucent.
- QuickTime Streaming Server: el servidor de streaming 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 transmisión.
- Servicios de Windows Media: servidor de transmisión de Microsoft incluido anteriormente con Windows Server que usa RTSP modificado con extensiones de Windows Media
- Wowza Streaming Engine: servidor de transmisión multiformato para RTSP/RTP, RTMP, MPEG-TS, ICY, HTTP (HTTP Live Streaming, HTTP Dynamic Streaming, Smooth Streaming, MPEG-DASH), WebRTC
- YouTube implementó una interfaz web móvil en junio de 2007 que sirve videos a través de este protocolo.
Muchas cámaras de seguridad/CCTV, a menudo llamadas cámaras IP, también admiten transmisión RTSP, especialmente aquellas con perfiles ONVIF G, S, T.
Cliente
- Astra
- cURL (a partir de la versión 7.20.0—9 de febrero de 2010)
- MPEG
- GStreamer
- JetAudio
- LIVE555 liveMedia / openRTSP: servidor C++ de código abierto y bibliotecas de cliente utilizadas en clientes conocidos como VLC y mplayer.
- Reproductor multimedia clasico
- MPlayer
- MythTV a través de Freebox
- Tiempo rapido
- Un jugador verdadero
- skype
- Spotify
- Reproductor de multimedia VLC
- winamp
- reproductor de medios de Windows
- xina
- ZoneMinder
- Motion (software de vigilancia)
Contenido relacionado
Enlazador (informática)
Máquina de estados finitos
Codificación Manchester diferencial