Protocolo de transmisión en tiempo real

Este artículo tiene varios problemas. Ayúdenos a mejorarlo o a discutir estos problemas en la página de discusión . ( Aprenda cómo y cuándo eliminar estos mensajes ) Este artículo necesita citas adicionales para su verificación .Por favor, ayude a mejorar este artículo añadiendo citas de fuentes fiables . El material sin fuentes puede ser cuestionado y eliminado. Buscar fuentes:  «Protocolo de transmisión en tiempo real» – noticias  · periódicos  · libros  · académico  · JSTOR ( Septiembre 2013 )( Aprenda cómo y cuándo eliminar este mensaje ) Es posible que este artículo requiera edición de gramática, estilo, cohesión, tono u ortografía .Puedes ayudar editándolo . ( Septiembre de 2024 )( Aprenda cómo y cuándo eliminar este mensaje ) ( Aprenda cómo y cuándo eliminar este mensaje )

El Protocolo de transmisión en tiempo real ( RTSP ) es un protocolo de red a 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 . El 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 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 ).

RTSP fue desarrollado por RealNetworks , Netscape ^[1] y la Universidad de Columbia . ^[2] El primer borrador fue enviado a 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. ^{[3] [4]} Los dos borradores fueron fusionados para su estandarización por el Grupo de Trabajo de Control de Sesiones Multimedia Multipartidistas (MMUSIC WG) del Grupo de Trabajo de Ingeniería de Internet (IETF) y el grupo de trabajo publicó borradores adicionales. ^{[5] [6]} El estándar propuesto para RTSP se publicó como RFC 2326 en 1998. ^[7]
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. ^[8]

La transmisión de datos en tiempo real 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 transmisiones multimedia. Sin embargo, algunos proveedores implementan protocolos de transporte propietarios. El software del servidor RTSP de RealNetworks , por ejemplo, también utiliza el Protocolo de transporte de datos reales (RDT) propietario de RealNetworks .

Aunque 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 un estado; se utiliza un identificador cuando es necesario para realizar un seguimiento de las sesiones simultáneas. Al igual que HTTP, RTSP utiliza TCP para mantener una conexión de extremo a extremo y, si bien la mayoría de los mensajes de control 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 RTSP básicas. También están disponibles algunas solicitudes HTTP típicas , como la solicitud OPTIONS. El número de puerto de la capa de transporte predeterminado es 554 ^[7] tanto para TCP como para UDP ; este último se utiliza raramente para las solicitudes de control.

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

C->S: OPCIONES rtsp://ejemplo.com/media.mp4 RTSP/1.0 Secuencia C: 1 Requerir: juego implícito Proxy-Require: mensajes comprimidosS->C: RTSP/1.0 200 OK Secuencia C: 1 Público: DESCRIBIR, CONFIGURAR, DESMONTAR, REPRODUCIR, PAUSAR

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 uno de los flujos de audio y vídeo. Las URL de los flujos de medios se obtienen directamente de los campos de control SDP o se obtienen añadiendo el campo de control SDP a la URL agregada.

C->S: DESCRIBE rtsp://ejemplo.com/media.mp4 RTSP/1.0 Secuencia C: 2S->C: RTSP/1.0 200 OK Secuencia C: 2 Base de contenido: rtsp://example.com/media.mp4 Tipo de contenido: aplicación/sdp Contenido-Longitud: 460 m=vídeo 0 RTP/AVP 96 a=control:id de flujo=0 a=rango:npt=0-7,741000 a=longitud:npt=7.741000 a=rtpmap:96 MP4V-ES/5544 a=mimetype:string;"vídeo/MP4V-ES" a=AvgBitRate:entero;304018 a=StreamName:string;"pista de vídeo sugerida" m=audio 0 RTP/AVP 97 a=control:id_transmisión=1 a=rango:npt=0-7,712000 a=longitud:npt=7.712000 a=rtpmap:97 mpeg4-genérico/32000/2 a=mimetype:string;"audio/mpeg4-generic" a=AvgBitRate:entero;65790 a=StreamName:string;"pista de audio sugerida"

Una solicitud SETUP especifica cómo se debe transportar un único flujo de medios. Esto se debe hacer antes de enviar una solicitud PLAY. La solicitud contiene la URL del flujo de medios y un especificador de transporte. Este especificador normalmente incluye un puerto local para recibir datos RTP (audio o vídeo) y otro para datos RTCP (metainformación). La respuesta del servidor normalmente confirma los parámetros elegidos y completa las partes faltantes, como los puertos elegidos por el servidor. Cada flujo de medios se debe configurar mediante SETUP antes de que se pueda enviar una solicitud de reproducción global.

C->S: CONFIGURAR rtsp://ejemplo.com/media.mp4/streamid=0 RTSP/1.0 Secuencia C: 3 Transporte: RTP/AVP;unicast;puerto_cliente=8000-8001S->C: RTSP/1.0 200 OK Secuencia C: 3 Transporte: RTP/AVP; unicast; puerto_cliente=8000-8001; puerto_servidor=9000-9001; ssrc=1234ABCD Sesión: 12345678C->S: CONFIGURAR rtsp://ejemplo.com/media.mp4/streamid=1 RTSP/1.0 Secuencia C: 3 Transporte: RTP/AVP;unicast;puerto_cliente=8002-8003 Sesión: 12345678S->C: RTSP/1.0 200 OK Secuencia C: 3 Transporte: RTP/AVP; unicast; puerto_cliente=8002-8003; puerto_servidor=9002-9003; ssrc=1234ABCD Sesión: 12345678

Una solicitud de REPRODUCCIÓN hará que se reproduzcan una o todas las transmisiones multimedia. Las solicitudes de reproducción se pueden agrupar enviando varias solicitudes de REPRODUCCIÓN. La URL puede ser la URL agregada (para reproducir todas las transmisiones multimedia) o una URL de transmisión multimedia única (para reproducir solo esa transmisión). Se puede especificar un rango. Si no se especifica ningún rango, la transmisión se reproduce desde el principio y hasta el final o, si la transmisión está en pausa, se reanuda en el punto en el que se pausó.

C->S: REPRODUCIR rtsp://ejemplo.com/media.mp4 RTSP/1.0 Secuencia C: 4 Rango: npt=5-20 Sesión: 12345678S->C: RTSP/1.0 200 OK Secuencia C: 4 Sesión: 12345678 Información RTP: url=rtsp://example.com/media.mp4/streamid=0;seq=9810092;rtptime=3450012

Una solicitud PAUSE detiene temporalmente una o todas las transmisiones multimedia, de modo que luego se puedan reanudar con una solicitud PLAY. La solicitud contiene una URL de transmisión multimedia o agregada. Un parámetro de rango en una solicitud PAUSE especifica cuándo hacer una pausa. Cuando se omite el parámetro de rango, la pausa se produce de inmediato y de manera indefinida.

C->S: PAUSA rtsp://ejemplo.com/media.mp4 RTSP/1.0 Secuencia C: 5 Sesión: 12345678S->C: RTSP/1.0 200 OK Secuencia C: 5 Sesión: 12345678

Este método inicia la grabación de un rango de datos multimedia según la descripción de la presentación. La marca de tiempo refleja la hora de inicio y de finalización (UTC). Si no se proporciona ningún rango de tiempo, utilice la hora de inicio o de 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 grabados bajo la URI de solicitud u otra URI. Si el servidor no utiliza la URI de solicitud, la respuesta debe ser 201 y contener una entidad que describa los estados de la solicitud y haga referencia al nuevo recurso, y un encabezado de ubicación.

C->S: GRABAR rtsp://ejemplo.com/media.mp4 RTSP/1.0 Secuencia C: 6 Sesión: 12345678S->C: RTSP/1.0 200 OK Secuencia C: 6 Sesión: 12345678

El método ANNOUNCE tiene dos propósitos:

Cuando se envía desde el cliente al servidor, ANNOUNCE publica la descripción de una presentación o un objeto multimedia identificado por la URL de solicitud en un servidor. Cuando se envía desde el servidor al cliente, ANNOUNCE actualiza la descripción de la sesión en tiempo real. Si se agrega una nueva secuencia multimedia a una presentación (por ejemplo, durante una presentación en vivo), se debe volver a enviar toda la descripción de la presentación, en lugar de solo los componentes adicionales, para que se puedan eliminar los componentes.

C->S: ANUNCIAR rtsp://example.com/media.mp4 RTSP/1.0 Secuencia C: 7 Fecha: 23 de enero de 1997 15:35:06 GMT Sesión: 12345678 Tipo de contenido: aplicación/sdp Contenido-Longitud: 332 v=0 o=mhandley 2890844526 2890845468 EN IP4 126.16.64.4 Seminario s=SDP i=A Seminario sobre el protocolo de descripción de sesiones u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps [email protected] (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 31S->C: RTSP/1.0 200 OK Secuencia C: 7

Se utiliza una solicitud TEARDOWN para finalizar la sesión. Detiene todas las transmisiones multimedia y libera todos los datos relacionados con la sesión en el servidor.

C->S: DESMONTAJE rtsp://ejemplo.com/media.mp4 RTSP/1.0 Secuencia C: 8 Sesión: 12345678S->C: RTSP/1.0 200 OK Secuencia C: 8

La solicitud GET_PARAMETER recupera el valor de un parámetro de una presentación o transmisión especificada en la URI. El contenido de la respuesta y la respuesta se deja en manos de la implementación. Se puede utilizar GET_PARAMETER sin cuerpo de entidad para probar la actividad del cliente o del servidor ("ping").

S->C: OBTENER_PARÁMETRO rtsp://ejemplo.com/media.mp4 RTSP/1.0 Secuencia C: 9 Tipo de contenido: texto/parámetros Sesión: 12345678 Contenido-Longitud: 15 paquetes_recibidos estar nerviosoC->S: RTSP/1.0 200 OK Secuencia C: 9 Contenido-Longitud: 46 Tipo de contenido: texto/parámetros paquetes_recibidos: 10 fluctuación: 0,3838

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

C->S: ESTABLECER_PARÁMETRO rtsp://ejemplo.com/media.mp4 RTSP/1.0 Secuencia C: 10 Longitud del contenido: 20 Tipo de contenido: texto/parámetros barparam: cosas de barS->C: RTSP/1.0 451 Parámetro no válido Secuencia C: 10 Longitud del contenido: 10 Tipo de contenido: texto/parámetros barraparam

Una solicitud REDIRECT informa al cliente que debe conectarse a otra ubicación de servidor. Contiene el encabezado obligatorio Location, que indica que el cliente debe enviar solicitudes para esa URL. Puede contener el parámetro Range, que indica cuándo entra en vigor la redirección. Si el cliente desea continuar enviando o recibiendo contenido multimedia para esta URI, DEBE enviar una solicitud TEARDOWN para la sesión actual y una solicitud SETUP para la nueva sesión en el host designado.

S->C: REDIRECCIONAR rtsp://ejemplo.com/media.mp4 RTSP/1.0 Secuencia C: 11 Ubicación: rtsp://bigserver.com:8001 Rango: reloj=19960213T143205Z-

Ciertos diseños de cortafuegos y otras circunstancias pueden obligar a un servidor a intercalar métodos RTSP y datos de flujo. Este intercalado se debe evitar generalmente 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 SÓLO DEBEN utilizarse si RTSP se transmite por TCP. Los datos de flujo, como los paquetes RTP, se encapsulan mediante un signo de dólar ASCII (24 hexadecimales), 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 un CRLF, pero incluyendo los encabezados de protocolo de capa superior. Cada bloque $ contiene exactamente una unidad de datos de protocolo de capa superior, por ejemplo, un paquete RTP.

C->S: CONFIGURAR rtsp://ejemplo.com/media.mp4 RTSP/1.0 Secuencia C: 3 Transporte: RTP/AVP/TCP; intercalado=0-1S->C: RTSP/1.0 200 OK Secuencia C: 3 Fecha: 05 de junio de 1997 18:57:18 GMT Transporte: RTP/AVP/TCP; intercalado=0-1 Sesión: 12345678C->S: REPRODUCIR rtsp://ejemplo.com/media.mp4 RTSP/1.0 Secuencia C: 4 Sesión: 12345678S->C: RTSP/1.0 200 OK Secuencia C: 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=972948234S->C: $\000{longitud de 2 bytes}{"longitud" de datos en bytes, con encabezado RTP}S->C: $\000{longitud de 2 bytes}{"longitud" de datos en bytes, con encabezado RTP}S->C: $\001{longitud de 2 bytes}{"longitud" bytes del paquete RTCP}

RTSP sobre HTTP fue definido por Apple en 1999 ^[9] y [1]. Intercala los datos de video y audio RTP en la conexión de comando RTSP (como se define en RFC2326) y luego envía la conexión de comando RTSP a través de un par de conexiones HTTP, una es una conexión GET de larga duración y la otra es una conexión POST de larga duración.

Este método también se utiliza en el estándar de cámara IP ONVIF y se puede combinar con HTTPS para obtener vídeo y audio seguros y encriptados.

Existen varios métodos diferentes para cifrar los mensajes de comando RTSP y los datos de video y audio RTP.

RTSP 2.0 (RFC7826) define varios métodos de cifrado e introduce una nueva URL rtsps:// y muchos de ellos se han incorporado a los clientes y servidores RFC2326 RTSP 1.0.

• URL de RTSPS (utilizando la URL rtsps://) : este método utiliza un socket TLS (el puerto predeterminado es el 322) para establecer una conexión cifrada entre el cliente RTSP y el servidor RTSP.
  El video y el audio se pueden enviar de una de dos maneras
  • Vídeo/audio TCP : el vídeo y el audio RTP se envían intercalados con los comandos RTSP a través de la conexión TLS ya cifrada.
  • Vídeo/audio UDP y multidifusión UDP : el vídeo y el audio RTP se cifran mediante el protocolo Secure RTP (SRTP) y se envían en paralelo a la conexión TLS RTSPS.

• RTSP sobre HTTPS : este método intercala los datos de audio y video RTP en la conexión de comando RTSP (tal como se define en RFC2326) y luego envía la conexión de comando RTSP a través de un par de conexiones HTTPS cifradas. Utiliza el puerto 443 de manera predeterminada.

La IANA ha reservado el prefijo URL rtsps:// y el puerto 322 para RTSPS. ^[10] A partir de septiembre de 2024, RTSP sobre HTTPS se ha implementado en varias cámaras IP ONVIF y RTSPS (usando la URL rtsps://) ha sido implementado por cámaras CCTV de Axis y Bosch, ^[11] FFmpeg , GStreamer , MediaMTX ^[12] y SharpRTSP. ^[13]

El RTSP que utiliza RTP y RTCP permite la implementación de la adaptación de velocidad. ^[14]

• Darwin Streaming Server : versión de código abierto de QuickTime Streaming Server mantenida por Apple.
• Servidor y cliente RTSP basados ​​en GStreamer .
• Helix DNA Server : servidor de streaming de RealNetworks . Disponible en versiones de código abierto y de propiedad exclusiva.
• Helix Universal Server : servidor de transmisión comercial de RealNetworks para clientes de transmisión multimedia RTSP, RTMP, iOS, Silverlight y HTTP
• LIVE555 liveMedia / openRTSP : bibliotecas de cliente y servidor C++ de código abierto utilizadas en clientes conocidos como VLC y mplayer .
• Motion: una aplicación de software de CCTV gratuita para Linux.
• Nimble Streamer admite entrada de extracción y anuncio RTSP con salida de reproducción intercalada TCP.
• OvenMediaEngine es un servidor de transmisión de baja latencia de código abierto que admite entrada push RTSP.
• pvServer : anteriormente llamado PacketVideo Streaming Server, este es el producto de servidor de transmisión de Alcatel-Lucent.
• QuickTime Streaming Server : servidor de transmisión de código cerrado de Apple que viene con Mac OS X Server.
• VideoLAN : Reproductor multimedia y servidor de transmisión de código abierto.
• Servicios de Windows Media : servidor de transmisión de Microsoft que anteriormente se incluía con Windows Server y que utiliza RTSP modificado con extensiones de Windows Media
• Wowza Streaming Engine : servidor de transmisión multiformato para RTSP/RTP, RTMP , MPEG-TS , ICY, HTTP ( transmisión en vivo HTTP , transmisión dinámica HTTP , transmisión fluida , MPEG-DASH ), WebRTC
• YouTube implementó una interfaz web móvil en junio de 2007 que ofrece videos a través de este protocolo. ^[15]

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

• Astra
• cURL (a partir de la versión 7.20.0—9 de febrero de 2010 ^[16] )
• FFmpeg ^[17]
• Transmisor G
• JetAudio
• LIVE555 liveMedia / openRTSP : bibliotecas de cliente y servidor C++ de código abierto utilizadas en clientes conocidos como VLC y mplayer .
• Reproductor multimedia clásico
• Reproductor MP
• MythTV a través de Freebox
• QuickTime
• RealPlayer
• Skype
• Spotify
• Reproductor multimedia VLC
• Winamp
• Reproductor de Windows Media
• xina
• Recordatorio de zonas
• Motion (software de vigilancia)

• "Información y actualizaciones del protocolo de transmisión en tiempo real". Archivado desde el original el 6 de marzo de 2007., un repositorio central de información sobre RTSP.
• "Tunelización de RTSP y RTP a través de HTTP". Archivado desde el original el 1 de mayo de 2013., Una solución estándar para ayudar a que RTSP funcione a través de firewalls y servidores proxy web
• "Agregación de medios administrados mediante Rtsp y Rtp". Guía a un desarrollador a través de la implementación de un RtspClient y un RtspServer que cumplan con los estándares.