Protocolo de mensajería en tiempo real

Las sesiones RTMP pueden cifrarse utilizando cualquiera de los dos métodos siguientes:

• Utilizando mecanismos TLS/SSL estándar de la industria , la sesión RTMP subyacente simplemente se encapsula dentro de una sesión TLS/SSL normal.
• Utilizando RTMPE, que encapsula la sesión RTMP en una capa de cifrado más ligera.

En RTMP Tunneled (RTMPT), los datos RTMP se encapsulan y se 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 equivalentes sin túnel 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 de otro modo, como cuando el cliente está detrás de un cortafuegos 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

POST /open/1 HTTP/1.1

para que se abra una conexión.

Algunos de los tipos de mensajes mostrados anteriormente, como Ping y Establecer ancho de banda cliente/servidor, se consideran mensajes de protocolo RTMP de bajo nivel que no utilizan el formato de codificación AMF. Los mensajes de comando, por otro lado, ya sean AMF0 (tipo de mensaje 0x14) o AMF3 (0x11), utilizan 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 ... } 

El ID de transacción se utiliza para comandos que pueden tener una respuesta. El valor puede ser una cadena de texto, 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 se codifican como cadenas de texto, mientras que los valores pueden ser de 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 flujo de 0x02, lo que implica una cabecera completa (tipo 0), y tienen un tipo de mensaje de 0x04. La cabecera va seguida de seis bytes, que se interpretan de la siguiente manera:

• #0–1 - Tipo de control.
• #2–3 - Segundo parámetro (esto tiene significado en tipos de control específicos)
• #4–5 - Tercer parámetro (igual)

Los dos primeros bytes del cuerpo del mensaje definen el tipo de ping, que aparentemente ^{[ 12 ]} puede tomar seis valores posibles.

• Tipo 0 - Flujo limpio: Se envía cuando se establece la conexión y no contiene más datos.
• Tipo 1 - Borrar el búfer.
• Tipo 2 - Arroyo seco.
• Tipo 3: Tiempo de búfer del cliente. El tercer parámetro contiene el valor en milisegundos.
• Tipo 4 - Reiniciar una transmisión.
• Tipo 6: Hacer ping al cliente desde el servidor. El segundo parámetro es la hora actual.
• Tipo 7: Respuesta Pong del cliente. El segundo parámetro es el momento en que el cliente recibe el Ping.
• Tipo 8 - Solicitud UDP.
• Tipo 9 - Respuesta UDP.
• Tipo 10 - Límite de ancho de banda.
• Tipo 11 - Ancho de banda.
• Tipo 12 - Ancho de banda del acelerador.
• Tipo 13 - Flujo creado.
• Tipo 14 - Transmisión eliminada.
• Tipo 15 - Establecer acceso de lectura.
• Tipo 16 - Establecer acceso de escritura.
• Tipo 17 - Solicitud de metadatos de transmisión.
• Tipo 18 - Respuesta de metadatos de flujo.
• Tipo 19 - Obtener límite de segmento.
• Tipo 20 - Establecer límite de segmento.
• Tipo 21 - Al desconectarse.
• Tipo 22 - Establecer enlace crítico.
• Tipo 23 - Desconectar.
• Tipo 24 - Actualización de hash.
• Tipo 25 - Tiempo de espera agotado para el hash.
• Tipo 26 - Solicitud de hash.
• Tipo 27 - Respuesta Hash.
• Tipo 28 - Comprobar ancho de banda.
• Tipo 29 - Configurar acceso a muestras de audio.
• Tipo 30 - Configurar acceso a muestras de vídeo.
• Tipo 31 - Inicio del acelerador.
• Tipo 32 - Extremo del acelerador.
• Tipo 33 - Notificar DRM.
• Tipo 34 - Sincronización RTMFP.
• Tipo 35 - Consulta IHola.
• Tipo 36 - Reenvío IHola.
• Tipo 37 - Redirigir IHello.
• Tipo 38 - Notificar EOF.
• Tipo 39 - Continuar por proxy.
• Tipo 40 - Eliminar proxy ascendente.
• Tipo 41 - RTMFP Configurar Keepalives.
• Tipo 46 - Segmento no encontrado.

Pong es el nombre que recibe la respuesta a un Ping, con los valores utilizados como se muestra arriba.

Esto se refiere a los mensajes relacionados con la velocidad de bits de subida del cliente y de bajada del servidor. El cuerpo consta de 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: estricto, flexible o dinámico (flexible o estricto).

El valor recibido en los cuatro bytes del cuerpo. Existe un valor predeterminado de 128 bytes, y el mensaje se envía solo cuando se desea realizar un cambio.

Tras 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 extremo (también denominados Chunks en la documentación oficial). Estos se denominan C0-2 para los paquetes enviados por el cliente y S0-2 para los del servidor, respectivamente, y no deben confundirse con los paquetes RTMP, que solo se intercambian una vez completado el protocolo de enlace. Estos paquetes tienen su propia estructura, y C1 contiene un campo que establece la marca de tiempo "epoch". Sin embargo, dado que este valor puede establecerse 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. A continuación, envía directamente C1 sin esperar a recibir primero S0, que contiene 1536 bytes: los cuatro primeros representan la marca de tiempo epoch, los cuatro siguientes son 0 y el resto son aleatorios (y pueden establecerse en 0 en implementaciones de terceros). C2 y S2 son un eco de S1 y C1 respectivamente, con la diferencia de que los últimos cuatro bytes indican la hora en que se recibió el mensaje correspondiente (en lugar de 0). Una vez recibidos C2 y S2, se considera que el protocolo de enlace ha finalizado.

En este punto, el cliente y el servidor pueden negociar una conexión mediante el intercambio de mensajes codificados en AMF . Estos incluyen pares clave-valor relacionados con las variables necesarias para establecer la conexión. Un ejemplo de mensaje del cliente es:

( Invocar ) "conectar" ( ID de transacción ) 1.0 ( Objeto1 ) { app : "muestra" , flashVer : "MAC 10,2,153,2" , swfUrl : null , tcUrl : "rtmpt://127.0.0.1/muestra " , fpad : false , capabilities : 9947.75 , audioCodecs : 3191 , videoCodecs : 252 , videoFunction : 1 , pageUrl : null , objectEncoding : 3.0 }

El servidor Flash Media Server y otras implementaciones utilizan el concepto de "aplicación" para definir conceptualmente un contenedor para audio/vídeo 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 "sample", que es el nombre proporcionado por el servidor Wowza para sus pruebas. La cadena es la misma que devuelve la función flashVerActionScript . y están codificados como doubles y su significado se puede encontrar en la especificación original. Lo mismo ocurre con la variable, que en este caso es la constante autoexplicativa SUPPORT_VID_CLIENT_SEEK . De especial interés es que definirá si el resto de la comunicación utilizará el 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 ActionScript que utilice AMF0 si se solicita. El servidor responde entonces con una secuencia de mensajes ServerBW, ClientBW y SetPacketSize, seguida finalmente de un Invoke, con un mensaje de ejemplo.getversion()audioCodecvideoCodecvideoFunctionobjectEncoding

( Invocar ) "_resultado" ( ID de transacción ) 1.0 ( Objeto1 ) { fmsVer : "FMS/3,5,5,2004" , capabilities : 31.0 , mode : 1.0 } ( Objeto2 ) { level : "estado" , code : "NetConnection.Connect.Success" , description : "Conexión exitosa" , data : ( array ) { version : "3,5,5,2004" }, clientId : 1728724019 , objectEncoding : 3.0 }

Algunos de los valores anteriores se serializan en propiedades de un objeto ActionScript genérico, que luego se pasa al oyente de eventos NetConnection. Esto clientIdestablecerá un número para la sesión que iniciará la conexión. La codificación del objeto debe coincidir con el valor configurado previamente.

Para iniciar una transmisión de video, el cliente envía una llamada a "createStream" seguida de un mensaje de ping, y luego una llamada a "play" con el nombre del archivo como argumento. El servidor responderá con una serie de comandos "onStatus" seguidos de los datos de video encapsulados en mensajes RTMP.

Una vez establecida la conexión, el contenido multimedia se envía 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 transmite los datos AMF dentro de las solicitudes y respuestas HTTP POST. La secuencia de conexión es la siguiente:

POST /fcs/ident2 HTTP / 1.1 Content-Type : application/x-fcs\r\n HTTP/1.0 404 No encontrado 

POST /open/1 HTTP / 1.1 Content-Type : application/x-fcs\r\n HTTP/1.1 200 OK Tipo de contenido: aplicación/x-fcs\r\n 1728724019 

La primera solicitud tiene una /fcs/ident2ruta, y la respuesta correcta es un error 404 Not Found. A continuación, el cliente envía una solicitud /open/1, a la que el servidor debe responder con un 200 ok, añadiendo 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.

POST /idle/1728724019/0 HTTP / 1.1 HTTP/1.1 200 OK 0x01

De ahora en adelante, se /idle/<session id>/<sequence #>trata de una solicitud de sondeo donde el ID de sesión se ha generado y devuelto desde el servidor y la secuencia es simplemente un número que se incrementa en uno para cada solicitud. La respuesta apropiada es un 200 OK, con un entero devuelto en el cuerpo que indica el tiempo del intervalo. Los datos AMF se envían a través de/send/<session id>/<sequence #>

La herramienta de línea de comandos de código abierto RTMP, rtmpdump, está diseñada para reproducir o guardar en disco la transmisión RTMP completa, incluyendo el protocolo RTMPE que Adobe utiliza para el cifrado. RTMPdump funciona 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, incluyendo Windows 98, a partir de la versión 2.2 el software solo funcionará en Windows XP y versiones posteriores (aunque las versiones anteriores siguen siendo totalmente funcionales).

Los paquetes del conjunto de software rtmpdump están disponibles en los principales repositorios de código abierto (distribuciones Linux). Estos incluyen las aplicaciones de interfaz "rtmpdump", "rtmpsrv" y "rtmpsuck".

El desarrollo de RTMPdump se reinició en octubre de 2009, fuera de Estados Unidos, en el sitio de MPlayer . ^{[ 13 ]} La versión actual presenta una funcionalidad notablemente mejorada y se ha reescrito para aprovechar las ventajas del lenguaje de programación C. En particular, la funcionalidad principal se integró en una biblioteca (librtmp) que otras aplicaciones pueden utilizar fácilmente. Los desarrolladores de RTMPdump también han creado soporte para librtmp para MPlayer , FFmpeg , XBMC , cURL , VLC y otros proyectos de software de código abierto. El uso de librtmp proporciona a estos proyectos soporte completo para 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, infringe la DMCA en Estados Unidos. Se desarrolló como respuesta al intento de Adobe en 2008 de suprimir RTMPdump. FLVstreamer es un cliente RTMP que guarda en disco una transmisión de audio o vídeo desde cualquier servidor RTMP, siempre que el cifrado (RTMPE) no esté habilitado.

RTMP utiliza internamente su propio "ID de códec" de cuatro bits en lugar del estándar FourCC para identificar el conjunto de códecs que admite. Los ID de códec de audio y vídeo se consideran en espacios de nombres diferentes, por lo que usar el mismo valor no causa ningún conflicto: por ejemplo, en el estándar base de Adobe, el códec de audio 7 es G.711A y el códec de vídeo 7 es H.264.

En China, Kingsoft Cloud asignó H.265 al códec de vídeo "12" en 2018, una práctica que pronto fue adoptada por otros actores de la industria como Bilibili . En 2020, Xia Chu de ZLMediaKit asignó Opus al códec de audio 13. ^{[ 14 ]}

E-RTMP ha dejado obsoletas todas las adiciones ad hoc al campo de ID codificado. E-RTMP no reutiliza los ID 12 y 13, lo que lo hace compatible con las extensiones ad hoc chinas.

El RTMP mejorado (E-RTMP) es una mejora de las especificaciones del Protocolo de Mensajería en Tiempo Real (RTMP) y FLV , que moderniza los flujos de trabajo de transmisión manteniendo la compatibilidad con la infraestructura RTMP existente. ^{[ 2 ]} Desarrollado como una especificación abierta, E-RTMP fue publicado por la Organización de Software Veovera, con contribuciones de Adobe , Google , Twitch y otros.

Las mejoras introducidas en E-RTMP incluyen:

• Nuevos formatos de encabezado de audio y video FLV, que se indican mediante partes reservadas de los formatos de encabezado originales.
  • Los encabezados antiguos usaban enteros de cuatro bits para identificar los tipos de códec, lo que limitaba la extensibilidad. El nuevo formato usa números FourCC para identificar los nuevos códecs. Las opciones estándar incluyen AC-3 , E-AC-3 , Opus y FLAC para audio, y VP8 , VP9 , ​​HEVC y AV1 con capacidades HDR para video, aunque se puede usar cualquier códec con un identificador FourCC acordado.
  • Los nuevos encabezados incluyen marcas de tiempo con precisión de nanosegundos para una mejor sincronización con los formatos multimedia modernos.
  • Los nuevos encabezados incluyen la capacidad de describir una configuración multipista, lo que permite el procesamiento simultáneo de audio, vídeo y metadatos dentro de una única secuencia.
  • El nuevo encabezado de audio puede describir configuraciones de audio multicanal, lo que resulta más flexible.
  • El nuevo encabezado de vídeo utiliza tipos de paquetes en lugar de tipos de tramas. Uno de estos tipos VideoPacketType.Metadatapermite escribir cualquier metadato de vídeo en formato de mensaje de acción (AMF). (AMF se utiliza en el protocolo RTMP original en la capa de mensajería, no como parte del flujo de vídeo FLV).
• Anuncio de nuevas funcionalidades de códecs en formato FourCC.
• Nuevos campos para onMetaData, un mecanismo de metadatos existente en RTMP (el uso actual de AMF).
• Una función de solicitud de reconexión para mejorar la estabilidad y la resistencia de la conexión en los flujos de trabajo de transmisión de contenido.

E-RTMP mejora las capacidades de RTMP al tiempo que garantiza la interoperabilidad con las implementaciones de RTMP existentes. Por ejemplo, un decodificador antiguo no sabría cómo decodificar tramas que contengan encabezados reservados ("nuevos"), pero aun así podría reenviarlas correctamente.

Debido a que muchos cambios en E-RTMP se realizan en la capa de formato FLV, E-RTMP también incluye una extensión al formato de archivo FLV que se puede usar independientemente de E-RTMP. ffmpeg llama a este formato "FLV mejorado". ^{[ 15 ]}