El Protocolo de transporte en tiempo real ( RTP ) es un protocolo de red para entregar audio y vídeo 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 videoconferencia, incluido WebRTC , servicios de televisión y funciones de pulsar para hablar basadas en web .
RTP normalmente 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 utiliza para monitorear las estadísticas de transmisión y la calidad de servicio (QoS) y ayuda a la sincronización de múltiples flujos. RTP es uno de los fundamentos técnicos de la voz sobre IP y, en este contexto, a menudo se utiliza 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 Vídeo 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. [2]
La investigación sobre audio y vídeo a través de redes de conmutación de paquetes se remonta a principios de los años 1970. El Grupo de Trabajo de Ingeniería de Internet (IETF) publicó el RFC 741 en 1977 y comenzó a desarrollar RTP en 1992, [1] y luego desarrollaría el Protocolo de anuncio de sesión (SAP), el Protocolo de descripción de sesión (SDP) y el Protocolo de inicio de sesión ( SORBO).
RTP está diseñado para la transferencia de medios de streaming en tiempo real y de un extremo a otro . El protocolo proporciona funciones para la compensación de fluctuaciones y la detección de pérdida de paquetes y entrega desordenada , 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 . [3] RTP se considera el estándar principal para el transporte de audio/vídeo en redes IP y se utiliza con un perfil asociado y un formato de carga útil. [4] 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 datos de audio, lo que puede hacerse imperceptible con algoritmos de ocultación de errores adecuados . [5] El Protocolo de control de transmisión (TCP), aunque está estandarizado para el uso de RTP, [6] 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). [5] Otros protocolos de transporte diseñados específicamente para sesiones multimedia son SCTP [7] y DCCP , [8] aunque, a partir de 2012 [update], no tenían un uso generalizado. [9]
RTP fue desarrollado por el grupo de trabajo de Transporte de Audio/Video de la organización de estándares IETF. RTP se utiliza junto con otros protocolos como H.323 y RTSP . [4] La especificación RTP describe dos protocolos: RTP y RTCP. RTP se utiliza para la transferencia de datos multimedia y RTCP se utiliza para enviar periódicamente información de control y parámetros de QoS. [10]
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 pérdida de paquetes y detección de reordenamiento) y el formato de carga útil que indica el formato codificado de los datos. [11] 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 el RTP es pequeño, normalmente alrededor del 5%. [11] [12]
Las sesiones RTP generalmente se inician entre pares que se comunican utilizando 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. [13]
Se establece una sesión RTP para cada flujo multimedia. Las transmisiones de audio y video pueden utilizar sesiones RTP separadas, lo que permite a un receptor recibir selectivamente componentes de una transmisión en particular. [14] El diseño de RTP y RTCP es independiente del protocolo de transporte. Las aplicaciones suelen utilizar UDP con números de puerto en el rango sin privilegios (1024 a 65535). [15] 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. [16] : 68 Se puede utilizar un solo puerto para RTP y RTCP en aplicaciones que multiplexan los protocolos. [17]
RTP es utilizado por aplicaciones multimedia en tiempo real como voz sobre IP , audio sobre IP , WebRTC y televisión por protocolo de Internet .
RTP está diseñado para transportar multitud de formatos multimedia, lo que permite el desarrollo de nuevos formatos sin revisar el estándar RTP. Para ello, la información requerida por una aplicación específica del protocolo no se incluye en la cabecera RTP genérica. Para cada clase de aplicación (por ejemplo, audio, vídeo), RTP define un perfil y formatos de carga asociados . [10] Cada creación de instancias de RTP en una aplicación particular requiere un perfil y especificaciones de formato de carga útil. [16] : 71
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. [4] 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 . [18] La asignación de flujos de audio/vídeo MPEG-4 a paquetes RTP se especifica en RFC 3016, y las cargas útiles de vídeo H.263 se describen en RFC 2429. [19]
Ejemplos de perfiles RTP incluyen:
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.
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. [22] Los campos del encabezado son los siguientes:
Una aplicación multimedia funcional requiere otros protocolos y estándares utilizados junto con RTP. Protocolos como SIP, Jingle , RTSP, H.225 y H.245 se utilizan para el inicio, control y terminación de 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. [26]
Un remitente RTP captura los datos multimedia, luego los codifica, los enmarca y los transmite como paquetes RTP con marcas de tiempo apropiadas y marcas de tiempo y números de secuencia crecientes. El remitente establece el campo de tipo de carga útil de acuerdo con la negociación de la conexión y el perfil RTP en uso. El receptor RTP detecta 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. [26]