Protocolo de transmisión en tiempo real (RTSP)

format_list_bulleted Contenido keyboard_arrow_down
ImprimirCitar

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

Más resultados...
Te puede interesar
Tamaño del texto:
undoredo
format_boldformat_italicformat_underlinedstrikethrough_ssuperscriptsubscriptlink
save
cancelcheck_circle