El Protocolo de mensajería en tiempo real ( RTMP ) es un protocolo de comunicación para transmitir audio, vídeo y datos a través de Internet. Desarrollado originalmente como un protocolo propietario por Macromedia para transmisión entre Flash Player y Flash Communication Server, Adobe (que adquirió Macromedia) ha lanzado una versión incompleta de la especificación del protocolo para uso público.
El protocolo RTMP tiene múltiples variaciones:
Si bien la motivación principal para RTMP era ser un protocolo para reproducir vídeo Flash , también se utiliza en algunas otras aplicaciones, como Adobe LiveCycle Data Services ES .
RTMP es un protocolo basado en TCP que mantiene conexiones persistentes y permite una comunicación de baja latencia. Para entregar flujos sin problemas y transmitir la mayor cantidad de información posible, los divide en fragmentos y su tamaño se negocia dinámicamente entre el cliente y el servidor. A veces se mantiene sin cambios; Los tamaños de fragmentos predeterminados son 64 bytes para datos de audio y 128 bytes para datos de vídeo y la mayoría de los demás tipos de datos. A continuación, se pueden entrelazar y multiplexar fragmentos de diferentes flujos a través de una única conexión. Con fragmentos de datos más largos, el protocolo lleva sólo un encabezado de un byte por fragmento, por lo que incurre en muy poca sobrecarga . Sin embargo, en la práctica, los fragmentos individuales no suelen estar entrelazados. En cambio, el entrelazado y la multiplexación se realizan a nivel de paquete, con paquetes RTMP a través de varios canales activos diferentes entrelazados de tal manera que se garantice que cada canal cumpla con su ancho de banda, latencia y otros requisitos de calidad de servicio. Los paquetes entrelazados de esta manera se tratan como indivisibles y no se entrelazan a nivel de fragmento.
El RTMP define varios canales virtuales en los que se pueden enviar y recibir paquetes y que funcionan de forma independiente unos de otros. Por ejemplo, hay un canal para manejar solicitudes y respuestas RPC, un canal para datos de transmisión de video, un canal para datos de transmisión de audio, un canal para mensajes de control fuera de banda (negociación del tamaño de fragmento, etc.), etc. . Durante una sesión RTMP típica, varios canales pueden estar activos simultáneamente en un momento dado. Cuando se codifican datos RTMP, se genera un encabezado de paquete. El encabezado del paquete especifica, entre otras cosas, el ID del canal por el que se enviará, una marca de tiempo de cuándo se generó (si es necesario) y el tamaño de la carga útil del paquete. A este encabezado le sigue el contenido de carga útil real del paquete, que se fragmenta según el tamaño de fragmento acordado actualmente antes de enviarlo a través de la conexión. El encabezado del paquete en sí nunca está fragmentado y su tamaño no cuenta para los datos del primer fragmento del paquete. En otras palabras, sólo la carga útil del paquete real (los datos multimedia) está sujeta a fragmentación.
En un nivel superior, RTMP encapsula audio MP3 o AAC y transmisiones multimedia de video FLV1 , y puede realizar llamadas a procedimientos remotos (RPC) utilizando el formato de mensaje de acción . Cualquier servicio RPC requerido se realiza de forma asincrónica, utilizando un único modelo de solicitud/respuesta de cliente/servidor, de modo que no se requiere comunicación en tiempo real. [ se necesita aclaración ] [2] [3]
Las sesiones RTMP se pueden cifrar mediante cualquiera de dos métodos:
En RTMP Tunneled (RTMPT), los datos RTMP se encapsulan e intercambian a través de HTTP , y los mensajes del cliente (el reproductor multimedia, en este caso) se dirigen al puerto 80 (el predeterminado para HTTP) en el servidor.
Si bien los mensajes en RTMPT son más grandes que los mensajes RTMP sin túnel equivalentes debido a los encabezados HTTP, RTMPT puede facilitar el uso de RTMP en escenarios donde el uso de RTMP sin túnel no sería posible, como cuando el cliente está detrás. un firewall que bloquea el tráfico saliente que no es HTTP ni HTTPS.
El protocolo funciona enviando comandos a través de la URL POST y mensajes AMF a través del cuerpo POST. Un ejemplo es
ENVIAR /abrir/1 HTTP/1.1
para que se abra una conexión.
Adobe ha publicado una especificación para la versión 1.0 del protocolo, con fecha del 21 de diciembre de 2012. [4] La página de inicio web que conduce a esa especificación señala que "Para beneficiar a los clientes que desean proteger su contenido, la especificación RTMP abierta no incluye la especificación exclusiva de Adobe". medidas RTMP seguras". [5]
Un documento que acompaña a la especificación de Adobe otorga una licencia de patente "no exclusiva, libre de regalías, intransferible, no sublicenciable, personal y mundial" para todas las implementaciones del protocolo, con dos restricciones: una prohíbe el uso para interceptar datos de transmisión ("cualquier tecnología que intercepta contenido de video, audio y/o datos para su almacenamiento en cualquier dispositivo o medio"), y otro prohíbe la elusión de "medidas tecnológicas para la protección de contenido de audio, video y/o datos, incluyendo cualquiera de las medidas RTMP seguras de Adobe". . [6]
Stefan Richter, autor de algunos libros sobre Flash , señaló en 2008 que, si bien Adobe es vago en cuanto a qué patentes se aplican a RTMP, la patente estadounidense 7.246.356 parece ser una de ellas. [2]
En 2011, Adobe demandó a Wowza Media Systems alegando, entre otras cosas, infracción de sus patentes RTMP. [7] [8] [9] En 2015, Adobe y Wowza anunciaron que las demandas habían sido resueltas y desestimadas con prejuicio. [10]
Los paquetes se envían a través de una conexión TCP, que se establece primero entre el cliente y el servidor. Contienen un encabezado y un cuerpo que, en el caso de comandos de conexión y control, se codifica mediante el formato de mensaje de acción (AMF). El encabezado se divide en encabezado básico (que se muestra separado del resto, en el diagrama) y encabezado de mensaje fragmentado . El encabezado básico es la única parte constante del paquete y generalmente está compuesto por un único byte compuesto , donde los dos bits más significativos son el tipo de fragmento ( fmt en la especificación) y el resto forma el ID de flujo. Dependiendo del valor del primero, algunos campos del encabezado del mensaje se pueden omitir y su valor derivar de paquetes anteriores, mientras que dependiendo del valor del segundo, el encabezado básico se puede ampliar con uno o dos bytes adicionales (como en el caso del diagrama que tiene tres bytes en total (c)). Si el valor de los seis bits restantes del encabezado básico (BH) (menos significativo) es 0, entonces el BH tiene dos bytes y representa desde el ID de flujo 64 al 319 (64+255); si el valor es 1, entonces el BH tiene tres bytes (con los dos últimos bytes codificados como Little Endian de 16 bits) y representa desde el ID de secuencia 64 hasta 65599 (64+65535); si el valor es 2, entonces BH es un byte y está reservado para mensajes y comandos de control de protocolo de bajo nivel. El encabezado del mensaje fragmentado contiene información de metadatos, como el tamaño del mensaje (medido en bytes), la marca de tiempo delta y el tipo de mensaje . Este último valor es un solo byte y define si el paquete es un paquete de audio, video, comando o RTMP de "bajo nivel", como un Ping RTMP.
A continuación se muestra un ejemplo capturado cuando un cliente flash ejecuta el siguiente código:
var flujo : NetStream = nuevo NetStream ( objeto de conexión ); esto generará el siguiente fragmento:
El paquete comienza con un encabezado básico de un solo byte (0x03) donde los dos bits más significativos (b 00 000011) definen un tipo de encabezado de fragmento de 0 mientras que el resto (b00 000011 ) define un ID de flujo de fragmento de 3. Los cuatro posibles Los valores del tipo de encabezado y su significado son:
El último tipo (b11) siempre se usa en el caso de mensajes agregados donde, en el ejemplo anterior, el segundo mensaje comenzará con una identificación de 0xC3 (b11000011) y significaría que todos los campos del encabezado del mensaje deben derivarse del mensaje con un ID de secuencia de 3 (que sería el mensaje justo encima). Los seis bits menos significativos que forman el ID de flujo pueden tomar valores entre 3 y 63. Algunos valores tienen un significado especial, como 1 que representa un formato de ID extendido, en cuyo caso habrá dos bytes a continuación. Un valor de dos es para mensajes de bajo nivel como Ping y Establecer ancho de banda del cliente.
Los siguientes bytes del encabezado RTMP (incluidos los valores del paquete de ejemplo anterior) se decodifican de la siguiente manera:
El byte de ID del tipo de mensaje define si el paquete contiene datos de audio/vídeo, un objeto remoto o un comando. Algunos valores posibles para son:
Después del encabezado, 0x02 denota una cadena de tamaño 0x000C y valores 0x63 0x72 ... 0x6D (comando "createStream"). A continuación tenemos un 0x00 (número) que es la identificación de la transacción con valor 2.0. El último byte es 0x05 (nulo), lo que significa que no hay argumentos.
Algunos de los tipos de mensajes mostrados anteriormente, como Ping y Establecer ancho de banda del cliente/servidor, se consideran mensajes de protocolo RTMP de bajo nivel que no utilizan el formato de codificación AMF. Por otro lado, los mensajes de comando, ya sean AMF0 (Tipo de mensaje de 0x14) o AMF3 (0x11), usan el formato y tienen la forma general que se muestra a continuación:
(Cadena) <Nombre del comando>(Número) <Id. de transacción>(Mixto) <Argumento> ej. Nulo, cadena, objeto: {clave1:valor1, clave2:valor2...}La identificación de la transacción se utiliza para comandos que pueden tener una respuesta. El valor puede ser una cadena como en el ejemplo anterior o uno o más objetos, cada uno compuesto por un conjunto de pares clave/valor donde las claves siempre están codificadas como cadenas, mientras que los valores pueden ser cualquier tipo de datos AMF, incluidos tipos complejos como matrices.
Los mensajes de control no están codificados en AMF. Comienzan con un ID de transmisión de 0x02 que implica un encabezado completo (tipo 0) y tienen un tipo de mensaje de 0x04. Al encabezado le siguen seis bytes, que se interpretan como tales:
Los primeros dos bytes del cuerpo del mensaje definen el tipo de ping, que aparentemente [11] puede tomar seis valores posibles.
Pong es el nombre de una respuesta a un Ping, con los valores utilizados como se ve arriba.
Esto se relaciona con los mensajes que tienen que ver con la velocidad de bits del cliente en sentido ascendente y del servidor en sentido descendente. El cuerpo está compuesto por cuatro bytes que muestran el valor del ancho de banda, con una posible extensión de un byte que establece el tipo de límite. Este puede tener uno de tres valores posibles que pueden ser: duro, suave o dinámico (ya sea suave o duro).
El valor recibido en los cuatro bytes del cuerpo. Existe un valor predeterminado de 128 bytes y el mensaje se envía sólo cuando se desea realizar un cambio.
Después de establecer una conexión TCP, primero se establece una conexión RTMP, realizando un protocolo de enlace mediante el intercambio de tres paquetes de cada lado (también denominados Chunks en la documentación oficial). En la especificación oficial se hace referencia a estos como C0-2 para los paquetes enviados por el cliente y S0-2 para el lado del servidor respectivamente y no deben confundirse con los paquetes RTMP que se pueden intercambiar solo después de que se completa el protocolo de enlace. Estos paquetes tienen una estructura propia y C1 contiene un campo que establece la marca de tiempo "época", pero como esto se puede establecer en cero, como se hace en implementaciones de terceros, el paquete se puede simplificar. El cliente inicializa la conexión enviando el paquete C0 con un valor constante de 0x03 que representa la versión actual del protocolo. Continúa directamente con C1 sin esperar a que se reciba primero S0, que contiene 1536 bytes, donde los primeros cuatro representan la marca de tiempo de la época, los segundos cuatro son 0 y el resto es aleatorio (y se puede establecer en 0 en terceros). implementaciones). C2 y S2 son un eco de S1 y C1 respectivamente, excepto que los segundos cuatro bytes son la hora en que se recibió el mensaje respectivo (en lugar de 0). Una vez recibidos C2 y S2, el protocolo de enlace se considera completo.
En este punto, el cliente y el servidor pueden negociar una conexión intercambiando mensajes codificados en AMF . Estos incluyen pares clave-valor que se relacionan con variables necesarias para establecer una conexión. Un mensaje de ejemplo del cliente es:
( Invocar ) "conectar" ( ID de transacción ) 1.0 ( Objeto1 ) { aplicación : "muestra" , flashVer : "MAC 10,2,153,2" , swfUrl : nulo , tcUrl : "rtmpt://127.0.0.1/sample" , fpad : falso , capacidades : 9947.75 , audioCodecs : 3191 , videoCodecs : 252 , videoFunction : 1 , pageUrl : nulo , objectEncoding : 3.0 } Flash Media Server y otras implementaciones utilizan el concepto de "aplicación" para definir conceptualmente un contenedor para audio/video y otro contenido, implementado como una carpeta en la raíz del servidor que contiene los archivos multimedia que se transmitirán. La primera variable contiene el nombre de esta aplicación como "muestra", que es el nombre proporcionado por el servidor Wowza para sus pruebas. La flashVercadena es la misma que devuelve la getversion()función Action-script. Los audioCodecy videoCodecestán codificados como dobles y su significado se puede encontrar en la especificación original. Lo mismo ocurre con la videoFunctionvariable, que en este caso es la constante SUPPORT_VID_CLIENT_SEEK que se explica por sí misma. De especial interés es el objectEncodingque definirá si el resto de la comunicación hará uso del formato AMF3 extendido o no. Como la versión 3 es la predeterminada actual, se debe indicar explícitamente al cliente flash en el código Action-script que use AMF0 si así lo solicita. Luego, el servidor responde con una secuencia de mensajes ServerBW, ClientBW y SetPacketSize, seguido finalmente de un Invoke, con un mensaje de ejemplo.
( Invocar ) "_result" ( ID de transacción ) 1.0 ( Objeto1 ) { fmsVer : "FMS/3,5,5,2004" , capacidades : 31.0 , modo : 1.0 } ( Objeto2 ) { nivel : "estado" , código : " NetConnection.Connect.Success" , descripción : "Conexión exitosa" , datos : ( matriz ) { versión : "3,5,5,2004" }, clientId : 1728724019 , objectEncoding : 3.0 } Algunos valores anteriores se serializan en propiedades de un objeto de script de acción genérico, que luego se pasa al detector de eventos NetConnection. Establecerá clientIdun número para la sesión que iniciará la conexión. La codificación del objeto debe coincidir con el valor establecido previamente.
Para iniciar una transmisión de video, el cliente envía una invocación "createStream" seguida de un mensaje ping, seguido de una invocación "reproducir" con el nombre del archivo como argumento. Luego, el servidor responderá con una serie de comandos "onStatus" seguidos de los datos de video encapsulados en mensajes RTMP.
Una vez establecida una conexión, los medios se envían encapsulando el contenido de las etiquetas FLV en mensajes RTMP de tipo 8 y 9 para audio y vídeo, respectivamente.
Esto se refiere a la versión tunelizada HTTP del protocolo. Se comunica a través del puerto 80 y pasa los datos AMF dentro de la solicitud y las respuestas HTTP POST. La secuencia de conexión es la siguiente:
POST /fcs/ident2 HTTP / 1.1 Tipo de contenido : aplicación/x-fcs\r\nHTTP/1.0 404 no encontradoPOST /open/1 HTTP / 1.1 Tipo de contenido : aplicación/x-fcs\r\nHTTP/1.1 200 correctoTipo de contenido: aplicación/x-fcs\r\n 1728724019La primera solicitud tiene una /fcs/ident2ruta y la respuesta correcta es un error 404 No encontrado. Luego, el cliente envía una solicitud /open/1 donde el servidor debe responder con un 200 ok agregando un número aleatorio que se utilizará como identificador de sesión para dicha comunicación. En este ejemplo, se devuelve 1728724019 en el cuerpo de la respuesta.
ENVIAR /idle/1728724019/0 HTTP / 1.1 HTTP/1.1 200 OK 0x01De ahora en adelante, /idle/<session id>/<sequence #>es una solicitud de sondeo en la que la identificación de la sesión se genera y se devuelve desde el servidor y la secuencia es solo un número que se incrementa en uno para cada solicitud. La respuesta adecuada es 200 OK, con un número entero devuelto en el cuerpo que indica el intervalo de tiempo. Los datos AMF se envían a través de/send/<session id>/<sequence #>
RTMP se implementa en estas tres etapas:
La herramienta de línea de comandos del cliente RTMP de código abierto, rtmpdump, está diseñada para reproducir o guardar en el disco la secuencia RTMP completa, incluido el protocolo RTMPE que Adobe utiliza para el cifrado. RTMPdump se ejecuta en Linux, Android, Solaris, Mac OS X y la mayoría de los demás sistemas operativos derivados de Unix, así como en Microsoft Windows. Originalmente compatible con todas las versiones de Windows de 32 bits, incluido Windows 98, a partir de la versión 2.2 el software se ejecutará sólo en Windows XP y superiores (aunque las versiones anteriores siguen siendo completamente funcionales).
Los paquetes del conjunto de software rtmpdump están disponibles en los principales repositorios de código abierto (distribuciones de Linux). Estas incluyen las aplicaciones de interfaz de usuario "rtmpdump", "rtmpsrv" y "rtmpsuck".
El desarrollo de RTMPdump se reinició en octubre de 2009, fuera de Estados Unidos, en el sitio MPlayer . [12] La versión actual presenta una funcionalidad muy mejorada y ha sido reescrita para aprovechar los beneficios del lenguaje de programación C. En particular, la funcionalidad principal se incorporó a una biblioteca (librtmp) que otras aplicaciones pueden utilizar fácilmente. Los desarrolladores de RTMPdump también han escrito soporte para librtmp para MPlayer , FFmpeg , XBMC , cURL , VLC y varios otros proyectos de software de código abierto. El uso de librtmp proporciona a estos proyectos soporte total de RTMP en todas sus variantes sin ningún esfuerzo de desarrollo adicional.
FLVstreamer es una bifurcación de RTMPdump, sin el código, que según Adobe viola la DMCA en los EE. UU. Esto se desarrolló como respuesta al intento de Adobe en 2008 de suprimir RTMPdump. FLVstreamer es un cliente RTMP que guardará una transmisión de contenido de audio o video desde cualquier servidor RTMP en el disco, si el cifrado (RTMPE) no está habilitado en la transmisión.
El contenedor de vídeo Flash en RTMP está limitado al códec H264 en la mayoría de las implementaciones. Por esta razón, The Veovera Software Organization, que incluye Adobe , Google y Veriskope, publicaron la especificación RTMP mejorada, [13] que agrega soporte para los códecs VP9 , H265 y AV1 en el contenedor Flash Video FLV .
{{cite journal}}: Citar diario requiere |journal=( ayuda )