Protocolo de transporte en tiempo real
Protocolo para la transmisión de audio y vídeo a través de redes IP
Protocolo de transporte en tiempo real
Protocolo de comunicación
AbreviaturaTiempo estimado de llegada
ObjetivoEntrega de audio y video
Desarrollador(es)Grupo de trabajo sobre transporte de audio y vídeo del IETF
IntroducciónEnero de 1996 ; hace 28 años ( 1996-01 )
Residencia enProtocolo de voz en red [1]
RFC(s)RFC  1889, 3550, 3551
Conjunto de protocolos de Internet
Capa de aplicación
Capa de transporte
Capa de Internet
Link layer

El Protocolo de transporte en tiempo real ( RTP ) es un protocolo de red para la transmisión de audio y vídeo a través de redes IP . El RTP se utiliza en sistemas de comunicación y entretenimiento que implican la transmisión de medios , como telefonía , aplicaciones de videoconferencia (incluido WebRTC) , servicios de televisión y funciones de pulsar para hablar basadas en la web .

El protocolo RTP generalmente se ejecuta sobre el protocolo de datagramas de usuario (UDP). El protocolo RTP se utiliza junto con el protocolo de control RTP (RTCP). Mientras que el protocolo RTP transporta los flujos de medios (por ejemplo, audio y video), el protocolo RTCP se utiliza para monitorear las estadísticas de transmisión y la calidad del servicio (QoS) y ayuda a la sincronización de múltiples flujos. El protocolo RTP es uno de los fundamentos técnicos de la voz sobre IP y, en este contexto, se utiliza a menudo 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 publicado por primera vez en 1996 como RFC  1889, que luego fue reemplazado por RFC  3550 en 2003. [2]

Descripción general

Las investigaciones sobre audio y video a través de redes de conmutación de paquetes se remontan a principios de la década de 1970. El Grupo de Trabajo de Ingeniería de Internet (IETF) publicó 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 (SIP).

RTP está diseñado para la transferencia de medios de transmisión en tiempo real de extremo a extremo . El protocolo proporciona funciones para la compensación de fluctuaciones y la detección de pérdida de paquetes y entrega fuera de orden , 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/video 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 entramado de capa de aplicación donde las funciones del protocolo se implementan en la aplicación en lugar de en 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 resultar en la pérdida de una fracción de segundo de datos de audio, que se puede hacer imperceptible con algoritmos de ocultación de errores adecuados . [5] El Protocolo de Control de Transmisión (TCP), aunque estandarizado para el uso de RTP, [6] no se utiliza normalmente 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 se usaban ampliamente. [9]

El protocolo RTP fue desarrollado por el grupo de trabajo de transporte de audio y video de la organización de estándares IETF. El protocolo RTP se utiliza junto con otros protocolos como H.323 y RTSP . [4] La especificación RTP describe dos protocolos: RTP y RTCP. El protocolo RTP se utiliza para la transferencia de datos multimedia y el protocolo RTCP se utiliza para enviar periódicamente información de control y parámetros de calidad de servicio. [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 detección de pérdida y reordenamiento de paquetes) 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, típicamente alrededor del 5%. [11] [12]

Las sesiones RTP se inician normalmente 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. [13]

Se establece una sesión RTP para cada flujo multimedia. Los flujos de audio y vídeo pueden utilizar sesiones RTP independientes, lo que permite a un receptor recibir selectivamente componentes de un flujo 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 utilizarse cuando se desea un protocolo de transporte fiable. 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 .

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, la información requerida por una aplicación específica del protocolo no se incluye en el encabezado RTP genérico. Para cada clase de aplicación (por ejemplo, audio, vídeo), RTP define un perfil y formatos de carga útil asociados . [10] Cada instancia 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 mapeo a códigos de formato de carga útil en el campo de protocolo Payload Type (PT) del encabezado RTP. Cada perfil está acompañado por 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] El mapeo 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. [19]

Algunos ejemplos de perfiles RTP incluyen:

Encabezado del paquete

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

Encabezado del paquete RTP
CompensacionesOcteto0123
OctetoUn poco [a]012345678910111213141516171819202122232425262728293031
00VersiónPAGincógnitaC.C.METROEnNúmero de secuencia
432Marca de tiempo
864Identificador SSRC
1296Identificadores CSRC
...
12+4×CC96+32×CCID de encabezado de extensión específico del perfilLongitud del encabezado de extensión
16+4×CC128+32×CCEncabezado 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 continuación, se encuentra la carga útil RTP, cuyo formato está determinado por la clase particular de aplicación. [22] Los campos del encabezado son los siguientes:

  • Versión : (2 bits) Indica la versión del protocolo. La versión actual es la 2. [23]
  • P (relleno) : (1 bit) Se utiliza para indicar si hay bytes de relleno adicionales al final del paquete RTP. El relleno se puede utilizar para llenar un bloque de cierto tamaño, por ejemplo, según lo requiera un algoritmo de cifrado. El último byte del relleno contiene la cantidad de bytes de relleno que se agregaron (incluido él mismo). [16] : 12  [23]
  • 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 extensión es específico de la aplicación o del perfil. [23]
  • CC (recuento CSRC) : (4 bits) Contiene la cantidad de identificadores CSRC (definidos a continuación) que siguen al SSRC (también definido a continuación). [16] : 12 
  • M (Marcador) : (1 bit) Señalización utilizada a nivel de aplicación de manera específica para cada perfil. Si está configurado, significa que los datos actuales tienen alguna relevancia especial para la aplicación. [16] : 13 
  • PT (Payload type) : (7 bits) Indica el formato del payload y, por lo tanto, determina su interpretación por parte de la aplicación. Los valores son específicos del perfil y pueden asignarse dinámicamente. [24]
  • Número de secuencia : (16 bits) El número de secuencia se incrementa para cada paquete de datos RTP enviado y el receptor debe usarlo para detectar la pérdida de paquetes [3] y para adaptarse a la entrega fuera de orden . El valor inicial del número de secuencia debe ser aleatorio para dificultar los ataques de texto simple conocido al Protocolo de transporte seguro en tiempo real . [16] : 13 
  • Marca de tiempo : (32 bits) La utiliza el receptor para reproducir las muestras recibidas en el tiempo y el intervalo adecuados. Cuando hay varias transmisiones de medios, las marcas de tiempo pueden ser independientes en cada transmisión. [b] La granularidad de la sincronización 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) utilizaría ese valor como su resolución de reloj. Las transmisiones de video suelen utilizar 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. [25]
  • SSRC : (32 bits) Identificador de fuente de sincronización que identifica de forma única la fuente de una transmisión. Las fuentes de sincronización dentro de la misma sesión RTP serán únicas. [16] : 15 
  • CSRC : (32 bits cada uno, la cantidad de entradas se indica mediante el campo de conteo CSRC ) Los identificadores de fuentes contribuyentes enumeran las fuentes que contribuyen a una secuencia que se ha generado a partir de múltiples fuentes. [16] : 15 
  • Extensión de 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 extensión. [16] : 18 

Diseño de aplicaciones

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 finalización de sesiones. Otros estándares, como H.264, MPEG y H.263, se utilizan para codificar los datos de carga útil según lo especificado por el perfil RTP aplicable. [26]

Un transmisor 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 transmisor 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 los paquetes faltantes y puede reordenarlos. Decodifica los datos multimedia en los paquetes de acuerdo con el tipo de carga útil y presenta la transmisión a su usuario. [26]

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 tipos de medios 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 vídeo H.264
  • RFC 3640, formato de carga útil RTP para el transporte de secuencias elementales MPEG-4
  • RFC 6416, formato de carga útil RTP para transmisiones de audio y video MPEG-4
  • RFC 2250, formato de carga útil RTP para vídeo MPEG1 / MPEG2

Véase también

Notas

  1. ^ Los bits se ordenan de mayor a menor importancia; el desplazamiento de bit 0 es el bit más significativo del primer octeto. Los octetos se transmiten en orden de red . El orden de transmisión de los bits depende del medio.
  2. ^ RFC  7273 proporciona un medio para señalar la relación entre los relojes de medios de diferentes transmisiones.

Referencias

  1. ^ desde Perkins 2003, pág. 6.
  2. ^ Wright, Gavin. "¿Qué es el Protocolo de transporte en tiempo real (RTP)?". TechTarget . Consultado el 10 de noviembre de 2022 .
  3. ^ ab Daniel Hardy (2002). Red . Universidad De Boeck. pag. 298.
  4. ^ abc Perkins 2003, pág. 55
  5. ^ de Perkins 2003, pág. 46
  6. ^ RFC  4571
  7. ^ Farrel, Adrian (2004). Internet y sus protocolos. Morgan Kaufmann. pág. 363. ISBN 978-1-55860-913-6.
  8. ^ Ozaktas, Haldun M.; Levent Onural (2007). TELEVISIÓN TRIDIMENSIONAL. Springer. pág. 356. ISBN 978-3-540-72531-2.
  9. ^ Hogg, Scott. "¿Qué pasa con el protocolo de transmisión de control de flujo (SCTP)?". Network World . Archivado desde el original el 30 de agosto de 2014. Consultado el 4 de octubre de 2017 .
  10. ^ de Larry L. Peterson (2007). Redes informáticas . Morgan Kaufmann. pág. 430. ISBN 978-1-55860-832-0.
  11. ^ de Perkins 2003, pág. 56
  12. ^ Peterson y Davie 2007, pág. 435
  13. ^ RFC  4566: SDP: Protocolo de descripción de sesión , M. Handley, V. Jacobson, C. Perkins, IETF (julio de 2006)
  14. ^ Zurawski, Richard (2004). "Protocolos RTP, RTCP y RTSP". Manual de tecnología de la información industrial . CRC Press. pp. 28–7. ISBN 978-0-8493-1985-3.
  15. ^ Collins, Daniel (2002). "Transporte de voz mediante IP". Voz sobre IP de calidad de operador . McGraw-Hill Professional. pp. 47. ISBN 978-0-07-136326-6.
  16. ^abcdefghi RFC  3550
  17. ^ Multiplexación de paquetes de datos y control RTP en un único puerto. IETF. Abril de 2010. doi : 10.17487/RFC5761 . RFC 5761. Consultado el 21 de noviembre de 2015 .
  18. ^ Perkins 2003, pág. 60
  19. ^ Chou, Philip A.; Mihaela van der Schaar (2007). Multimedia sobre IP y redes inalámbricas . Academic Press. pp. 514. ISBN 978-0-12-088480-3.
  20. ^ Perkins 2003, pág. 367
  21. ^ Breese, Finley (2010). Comunicación serial a través de RTP/CDP . BoD - Libros a pedido. pp. [1]. ISBN 978-3-8391-8460-8.
  22. ^ Peterson y Davie 2007, pág. 430
  23. ^ abc Peterson y Davie 2007, pág. 431
  24. ^ Perkins 2003, pág. 59
  25. ^ Peterson, pág. 432
  26. ^ desde Perkins 2003, págs. 11-13
  • Perkins, Colin (2003). RTP: Audio y vídeo para Internet. Addison-Wesley. ISBN 978-0-672-32249-5.
  • Peterson, Larry L.; Davie, Bruce S. (2007). Redes informáticas (4.ª edición). Morgan Kaufmann. ISBN 978-0-12-374013-7.

Lectura adicional

  • Página RTP de Henning Schulzrinne (incluye preguntas frecuentes)
  • RTP cc de GNU
  • JRTPLIB, una biblioteca RTP de C++
  • Agregación de medios administrados Archivado el 9 de enero de 2018 en Wayback Machine : Implementación de RTP/RTCP compatible con .NET C# RFC escrita en código completamente administrado.
  • "RTP", Broadband Networks , Ministerio de Recursos Humanos, India, 2008, archivado desde el original el 18 de noviembre de 2021
Retrieved from "https://en.wikipedia.org/w/index.php?title=Real-time_Transport_Protocol&oldid=1244244737"