Protocolo de transporte en tiempo real (RTP)

El Real-time Transport Protocol (RTP) o Protocolo de transporte en tiempo real es un protocolo de red para entregar audio y video a través de redes IP. RTP se utiliza en sistemas de comunicación y entretenimiento que involucran transmisión de medios, como telefonía, aplicaciones de teleconferencia de video que incluyen WebRTC, servicios de televisión y funciones de pulsar para hablar basadas en la web.

RTP generalmente se ejecuta sobre el Protocolo de datagramas de usuario (UDP). RTP se utiliza junto con el Protocolo de control RTP (RTCP). Mientras que RTP transporta los flujos de medios (por ejemplo, audio y video), RTCP se usa para monitorear las estadísticas de transmisión y la calidad del servicio (QoS) y ayuda a la sincronización de múltiples flujos. RTP es una de las bases técnicas de Voz sobre IP y, en este contexto, a menudo se usa junto con un protocolo de señalización como el Protocolo de inicio de sesión (SIP) que establece conexiones a través de la red.

RTP fue desarrollado por el Grupo de trabajo de transporte de audio y video del Grupo de trabajo de ingeniería de Internet (IETF) y se publicó por primera vez en 1996 como RFC 1889, que luego fue reemplazado por RFC 3550 en 2003.

Visión general

RTP está diseñado para la transferencia en tiempo real de extremo a extremo de medios de transmisión. El protocolo proporciona funciones para la compensación de fluctuaciones y la detección de pérdida de paquetes y entrega fuera de servicio, que son comunes especialmente durante las transmisiones UDP en una red IP. RTP permite la transferencia de datos a múltiples destinos a través de multidifusión IP. RTP se considera el estándar principal para el transporte de audio/video en redes IP y se usa con un perfil asociado y un formato de carga útil. El diseño de RTP se basa en el principio arquitectónico conocido como marco de capa de aplicación donde las funciones de protocolo se implementan en la aplicación en lugar de la pila de protocolos del sistema operativo.

Las aplicaciones de transmisión multimedia en tiempo real requieren la entrega oportuna de información y, a menudo, pueden tolerar cierta pérdida de paquetes para lograr este objetivo. Por ejemplo, la pérdida de un paquete en una aplicación de audio puede provocar la pérdida de una fracción de segundo de los datos de audio, lo que puede pasar desapercibido con algoritmos de ocultación de errores adecuados. El Protocolo de control de transmisión (TCP), aunque estandarizado para el uso de RTP, normalmente no se usa en aplicaciones RTP porque TCP favorece la confiabilidad sobre la puntualidad. En cambio, la mayoría de las implementaciones de RTP se basan en el Protocolo de datagramas de usuario (UDP). Otros protocolos de transporte diseñados específicamente para sesiones multimedia son SCTP y DCCP, aunque, a partir de 2012, no tienen un uso generalizado.

RTP fue desarrollado por el grupo de trabajo de transporte de audio/video de la organización de estándares IETF. RTP se usa junto con otros protocolos como H.323 y RTSP. La especificación RTP describe dos protocolos: RTP y RTCP. RTP se usa para la transferencia de datos multimedia, y RTCP se usa para enviar periódicamente información de control y parámetros de QoS.

El protocolo de transferencia de datos, RTP, transporta datos en tiempo real. La información proporcionada por este protocolo incluye marcas de tiempo (para sincronización), números de secuencia (para detección de pérdida de paquetes y reordenación) y el formato de carga útil que indica el formato codificado de los datos. El protocolo de control, RTCP, se utiliza para la retroalimentación de calidad de servicio (QoS) y la sincronización entre los flujos de medios. El ancho de banda del tráfico RTCP en comparación con RTP es pequeño, normalmente alrededor del 5 %.

Las sesiones RTP generalmente se inician entre pares que se comunican mediante un protocolo de señalización, como H.323, el Protocolo de inicio de sesión (SIP), RTSP o Jingle (XMPP). Estos protocolos pueden utilizar el Protocolo de descripción de sesión para especificar los parámetros de las sesiones.

Se establece una sesión RTP para cada flujo multimedia. Los flujos de audio y video pueden usar sesiones RTP separadas, lo que permite que un receptor reciba selectivamente componentes de un flujo en particular. El diseño de RTP y RTCP es independiente del protocolo de transporte. Las aplicaciones generalmente usan UDP con números de puerto en el rango sin privilegios (1024 a 65535). El Protocolo de transmisión de control de flujo (SCTP) y el Protocolo de control de congestión de datagramas (DCCP) pueden usarse cuando se desea un protocolo de transporte confiable. La especificación RTP recomienda números de puerto pares para RTP y el uso del siguiente número de puerto impar para la sesión RTCP asociada. Se puede usar un solo puerto para RTP y RTCP en aplicaciones que multiplexan los protocolos.

RTP es utilizado por aplicaciones multimedia en tiempo real, como voz sobre IP, audio sobre IP, WebRTC y televisión con protocolo de Internet.

Perfiles y formatos de carga útil

RTP está diseñado para transportar una multitud de formatos multimedia, lo que permite el desarrollo de nuevos formatos sin revisar el estándar RTP. Para ello, no se incluye en la cabecera RTP genérica la información requerida por una determinada aplicación del protocolo. Para cada clase de aplicación (por ejemplo, audio, video), RTP define un perfil y formatos de carga útil asociados. Cada instanciación de RTP en una aplicación particular requiere un perfil y especificaciones de formato de carga útil.

El perfil define los códecs utilizados para codificar los datos de carga útil y su asignación a códigos de formato de carga útil en el campo de protocolo Tipo de carga útil (PT) del encabezado RTP. Cada perfil va acompañado de varias especificaciones de formato de carga útil, cada una de las cuales describe el transporte de datos codificados particulares. Ejemplos de formatos de carga útil de audio son G.711, G.723, G.726, G.729, GSM, QCELP, MP3 y DTMF, y ejemplos de cargas útiles de video son H.261, H.263, H.264, H.265 y MPEG-1/MPEG-2. La asignación de flujos de audio/video MPEG-4 a paquetes RTP se especifica en RFC 3016, y las cargas útiles de video H.263 se describen en RFC 2429.

Ejemplos de perfiles RTP incluyen:

• El perfil RTP para conferencias de audio y video con control mínimo (RFC 3551) define un conjunto de asignaciones de tipo de carga útil estática y un mecanismo dinámico para mapear entre un formato de carga útil y un valor de PT usando el Protocolo de descripción de sesión (SDP).
• El Protocolo de transporte seguro en tiempo real (SRTP) (RFC 3711) define un perfil RTP que proporciona servicios criptográficos para la transferencia de datos de carga útil.
• El perfil de datos de control experimental para RTP (RTP/CDP) para comunicaciones de máquina a máquina.

Encabezado del paquete

Los paquetes RTP se crean en la capa de aplicación y se entregan a la capa de transporte para su entrega. Cada unidad de datos de medios RTP creada por una aplicación comienza con el encabezado del paquete RTP.

Compensaciones	Octeto	0	1	2	3
Octeto	Un poco	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	dieciséis	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	Versión	PAGS	X	CC	METRO	PT	Secuencia de números
4	32	marca de tiempo
8	64	identificador SSRC
12	96	Identificadores CSRC...
12+4×CC	96+32×CC	ID de encabezado de extensión específico del perfil	Longitud del encabezado de extensión
16+4×CC	128+32×CC	Encabezado de extensión...

El encabezado RTP tiene un tamaño mínimo de 12 bytes. Después del encabezado, pueden estar presentes extensiones de encabezado opcionales. A esto le sigue la carga útil RTP, cuyo formato está determinado por la clase particular de aplicación. Los campos del encabezado son los siguientes:

• Versión: (2 bits) Indica la versión del protocolo. La versión actual es la 2.
• P (Relleno): (1 bit) Se utiliza para indicar si hay bytes de relleno adicionales al final del paquete RTP. El relleno se puede usar para llenar un bloque de cierto tamaño, por ejemplo, según lo requiera un algoritmo de cifrado. El último byte del relleno contiene el número de bytes de relleno que se agregaron (incluido él mismo).
• X (Extensión): (1 bit) Indica la presencia de un encabezado de extensión entre el encabezado y los datos de carga útil. El encabezado de la extensión es específico de la aplicación o del perfil.
• CC (recuento CSRC): (4 bits) contiene el número de identificadores CSRC (definidos a continuación) que siguen al SSRC (también definidos a continuación).
• M (Marcador): (1 bit) Señalización utilizada en el nivel de aplicación de una manera específica del perfil. Si está configurado, significa que los datos actuales tienen alguna relevancia especial para la aplicación.
• PT (Tipo de carga útil): (7 bits) Indica el formato de la carga útil y, por lo tanto, determina su interpretación por parte de la aplicación. Los valores son específicos del perfil y se pueden asignar dinámicamente.
• Número de secuencia: (16 bits) El número de secuencia se incrementa para cada paquete de datos RTP enviado y lo utilizará el receptor para detectar la pérdida de paquetes y acomodar la entrega fuera de orden. El valor inicial del número de secuencia debe aleatorizarse para dificultar los ataques de texto sin formato conocido en el protocolo de transporte seguro en tiempo real.
• Marca de tiempo: (32 bits) Utilizado por el receptor para reproducir las muestras recibidas en el tiempo y el intervalo adecuados. Cuando están presentes varios flujos de medios, las marcas de tiempo pueden ser independientes en cada flujo. La granularidad del tiempo es específica de la aplicación. Por ejemplo, una aplicación de audio que muestrea datos una vez cada 125 μs (8 kHz, una frecuencia de muestreo común en telefonía digital) usaría ese valor como su resolución de reloj. Las transmisiones de video generalmente usan un reloj de 90 kHz. La granularidad del reloj es uno de los detalles que se especifica en el perfil RTP para una aplicación.
• SSRC: (32 bits) El identificador de fuente de sincronización identifica de forma única la fuente de un flujo. Las fuentes de sincronización dentro de la misma sesión RTP serán únicas.
• CSRC: (32 bits cada uno, el número de entradas se indica en el campo de recuento de CSRC) Los ID de fuentes contribuyentes enumeran las fuentes contribuyentes a un flujo que se ha generado a partir de múltiples fuentes.
• Extensión del encabezado: (opcional, presencia indicada por el campo Extensión) La primera palabra de 32 bits contiene un identificador específico del perfil (16 bits) y un especificador de longitud (16 bits) que indica la longitud de la extensión en unidades de 32 bits, excluyendo los 32 bits del encabezado de extensión. A continuación se muestran los datos del encabezado de la extensión.

Diseño de aplicaciones

Una aplicación multimedia funcional requiere otros protocolos y estándares utilizados junto con RTP. Se utilizan protocolos como SIP, Jingle, RTSP, H.225 y H.245 para iniciar, controlar y terminar sesiones. Se utilizan otros estándares, como H.264, MPEG y H.263, para codificar los datos de carga útil según lo especificado por el perfil RTP aplicable.

Un remitente RTP captura los datos multimedia, luego los codifica, los enmarca y los transmite como paquetes RTP con marcas de tiempo apropiadas y números de secuencia y marcas de tiempo crecientes. El remitente establece el campo de tipo de carga útil de acuerdo con la negociación de conexión y el perfil RTP en uso. El receptor RTP detecta los paquetes faltantes y puede reordenarlos. Decodifica los datos multimedia en los paquetes según el tipo de carga útil y presenta el flujo a su usuario.

Documentos de normas

• RFC 3550, estándar 64, RTP: un protocolo de transporte para aplicaciones en tiempo real
• RFC 3551, estándar 65, perfil RTP para conferencias de audio y video con control mínimo
• RFC 4855, Registro de tipo de medio de formatos de carga útil RTP
• RFC 4856, Registro de tipos de medios de formatos de carga útil en el perfil RTP para conferencias de audio y video
• RFC 7656, una taxonomía de semántica y mecanismos para fuentes de protocolo de transporte en tiempo real (RTP)

• RFC 3190, formato de carga útil RTP para audio DAT de 12 bits y audio muestreado lineal de 20 y 24 bits
• RFC 6184, formato de carga útil RTP para video H.264
• RFC 3640, formato de carga útil RTP para el transporte de flujos elementales MPEG-4
• RFC 6416, formato de carga útil RTP para flujos de audio/visual MPEG-4
• RFC 2250, formato de carga útil RTP para vídeo MPEG1/MPEG2

• RFC 4175, formato de carga útil RTP para video sin comprimir
• RFC 6295, formato de carga útil RTP para MIDI
• RFC 4696, una guía de implementación para RTP MIDI
• RFC 7587, formato de carga útil RTP para el códec de voz y audio Opus
• RFC 7798, formato de carga útil RTP para codificación de video de alta eficiencia (HEVC)