Articulo de referencia

Protocolo de transporte en tiempo real

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 . RTP se utiliza en sistemas de comunicación y...

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 . RTP se utiliza en sistemas de comunicación y entretenimiento que implican la transmisión de contenido multimedia , como telefonía , aplicaciones de videoconferencia (incluido 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 multimedia (por ejemplo, audio y video), RTCP se utiliza para monitorear las estadísticas de transmisión y la calidad del servicio (QoS), y facilita la sincronización de múltiples flujos. RTP es uno de los fundamentos técnicos de la voz sobre IP y, en este contexto, se usa frecuentemente 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

La investigación sobre audio y video en redes de conmutación de paquetes se remonta a principios de la década de 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 posteriormente 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 extremo a extremo y en tiempo real de contenido multimedia en streaming . 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 y un formato de carga útil asociados. [ 4 ]El diseño de RTP se basa en el principio arquitectónico conocido como enmarcado 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, lo que puede hacerse imperceptible con algoritmos adecuados de ocultación de errores . [ 5 ] El Protocolo de Control de Transmisión (TCP), aunque estandarizado para su uso en RTP, [ 6 ] no se usa normalmente en aplicaciones RTP porque TCP prioriza 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, no eran de 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 que proporciona este protocolo incluye marcas de tiempo (para sincronización), números de secuencia (para la 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 la calidad de servicio (QoS) y la sincronización entre los flujos multimedia. El ancho de banda del tráfico RTCP, en comparación con el RTP, es pequeño, generalmente 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 video pueden usar sesiones RTP separadas, 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 usar UDP con números de puerto en el rango no privilegiado (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) se pueden usar 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 usar 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 , televisión por protocolo de Internet y vídeo profesional sobre IP, incluyendo SMPTE 2022 y SMPTE 2110 .

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 la cabecera RTP genérica. Para cada clase de aplicación (p. ej., 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. [ 18 ] : 71

El perfil define los códecs utilizados para codificar los datos de carga útil y su asignación a los códigos de formato de carga útil en el campo de protocolo Tipo de carga útil (PT) del encabezado RTP. Cada perfil viene 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 vídeo son H.261 , H.263 , H.264 , H.265 y MPEG-1 / MPEG-2 . [ 19 ] 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. [ 20 ]  

Algunos ejemplos de perfiles RTP son:

Encabezado del paquete

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

El encabezado RTP tiene un tamaño mínimo de 12 bytes. Después del encabezado, pueden aparecer extensiones de encabezado opcionales. A continuación, se encuentra la carga útil RTP, cuyo formato viene determinado por la clase de aplicación específica. [ 23 ] Los campos del encabezado son los siguientes:

Versión : 2 bits
Indica la versión del protocolo. La versión actual es 2. [ 24 ]
Relleno  (P) : 1 bit
Se utiliza para indicar si hay bytes de relleno adicionales al final del paquete RTP. El relleno puede utilizarse para completar 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 añadieron (incluido él mismo). [ 16 ] : 12 [ 24 ]
Extensión  (X) : 1 bit
Indica la presencia de un encabezado de extensión entre el encabezado y los datos de la carga útil. El encabezado de extensión es específico de la aplicación o del perfil. [ 24 ]
Contador CSRC  (CC) : 4 bits
Contiene el número de identificadores CSRC (definidos a continuación) que siguen al SSRC (también definido a continuación). [ 16 ] : 12
Marcador  (M) : 1 bit
Señalización utilizada a nivel de aplicación de forma específica para cada perfil. Si está activada, significa que los datos actuales tienen alguna relevancia especial para la aplicación. [ 16 ] : 13
Tipo de carga útil  (PT) : 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 pueden asignarse dinámicamente. [ 25 ]
Número de secuencia : 16 bits
El número de secuencia se incrementa para cada paquete de datos RTP enviado y el receptor lo utiliza para detectar la pérdida de paquetes [ 3 ] y para gestionar la entrega fuera de orden . El valor inicial del número de secuencia debe ser aleatorio para dificultar los ataques de texto plano conocido contra el Protocolo de Transporte en Tiempo Real Seguro . [ 16 ] : 13
Marca de tiempo : 32 bits
Utilizado por el receptor para reproducir las muestras recibidas en el momento y el intervalo adecuados. Cuando hay varias secuencias multimedia presentes, las marcas de tiempo pueden ser independientes en cada secuencia. [ a ] ​​La granularidad de la temporizació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) usaría ese valor como su resolución de reloj. Las secuencias de vídeo suelen usar un  reloj de 90 kHz. La granularidad del reloj es uno de los detalles que se especifican en el perfil RTP para una aplicación. [ 26 ]
SSRC : 32 bits
El identificador de origen de sincronización identifica de forma única el origen de una transmisión. Los orígenes de sincronización dentro de la misma sesión RTP serán únicos. [ 16 ] : 15
CSRC : Variable ( Recuento de CSRC × 32 bits)
Los ID de fuentes contribuyentes enumeran las fuentes que contribuyen a un flujo que se ha generado a partir de múltiples fuentes. [ 16 ] : 15
Extensión de encabezado : Variable ; Existe cuando X=1
Cuando Extension es verdadero, este campo opcional contiene:
ID de encabezado de extensión específico del perfil : 16 bits
un identificador específico del perfil
Longitud del encabezado de extensión : 16 bits
Indica la longitud de la extensión en unidades de 32 bits, excluyendo los 32 bits del encabezado de la extensión.
Datos del encabezado de extensión : Variable
Los datos del encabezado de la 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 la sesión. 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. [ 27 ]

Un emisor RTP captura los datos multimedia, los codifica, los encuadra y los transmite como paquetes RTP con marcas de tiempo apropiadas, marcas de tiempo incrementales y números de secuencia. El emisor 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 según el tipo de carga útil y presenta el flujo a su usuario. [ 27 ]

Documentos de normas

  • RFC 3550 " RTP: Un protocolo de transporte para aplicaciones en tiempo real, " [ 16 ] Estándar de Internet 64. 
  • RFC 3551 " Perfil RTP para conferencias de audio y video con control mínimo " , [ 28 ] Estándar de Internet 65. 
  • RFC 4855 " Registro de tipo de medio de formatos de carga útil RTP " , [ 29 ] Estándar propuesto. 
  • RFC 4856 " Registro de tipo de medio de formatos de carga útil en el perfil RTP para conferencias de audio y video " , [ 30 ] Norma propuesta. 
  • RFC 7656 " Una taxonomía de semántica y mecanismos para fuentes de protocolo de transporte en tiempo real (RTP), " [ 31 ] Informativo. 
  • RFC 3190 " Formato de carga útil RTP para audio DAT de 12 bits y audio muestreado lineal de 20 y 24 bits " , [ 32 ] Estándar propuesto. 
  • RFC 6184 " Formato de carga útil RTP para vídeo H.264 " , [ 33 ] Estándar propuesto. 
  • RFC 3640 " Formato de carga útil RTP para el transporte de flujos elementales MPEG-4 " , [ 34 ] Estándar propuesto. 
  • RFC 6416 " Formato de carga útil RTP para flujos de audio/vídeo MPEG-4 " , [ 35 ] Estándar propuesto. 
  • RFC 2250 " Formato de carga útil RTP para vídeo MPEG1 / MPEG2 " , [ 36 ] Estándar propuesto. 
  • RFC 4175 " Formato de carga útil RTP para vídeo sin comprimir " , [ 37 ] Estándar propuesto. 
  • RFC 6295 " Formato de carga útil RTP para MIDI " , [ 38 ] Estándar propuesto. 
  • RFC 4696 " Una guía de implementación para RTP MIDI " , [ 39 ] Informativo. 
  • RFC 7164 " RTP y segundos intercalares " , [ 40 ] Estándar propuesto. 
  • RFC 7587 " Formato de carga útil RTP para el códec de voz y audio Opus " , [ 41 ] Estándar propuesto. 
  • RFC 7798 " Formato de carga útil RTP para codificación de vídeo de alta eficiencia (HEVC), " [ 42 ] Estándar propuesto. 

Véase también

Notas

  1. RFC 7273 proporciona un medio para señalar la relación entre los relojes de medios de diferentes flujos. 

Referencias

  1. 1 2 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. ^ Daniel Hardy (2002) . Red . Universidad De Boeck. pag. 298 . 
  4. 1 2 3 Perkins 2003 , pág. 55 
  5. 1 2 Perkins 2003 , pág. 46 
  6. J. Lazzaro (julio de 2006). Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport . Network Working Group. doi : 10.17487/RFC4571 . RFC 4571 .Norma propuesta.
  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é hay del protocolo de transmisión de control de flujo (SCTP)?" . Network World . Archivado del original el 30 de agosto de 2014 . Recuperado el 4 de octubre de 2017 .
  10. 1 2 Larry L. Peterson (2007). Redes de computadoras . Morgan Kaufmann. pág . 430. ISBN  978-1-55860-832-0.
  11. 1 2 Perkins 2003 , pág. 56 
  12. Peterson y Davie 2007 , pág. 435 
  13. Begen, A; Kyzivat, P; Perkins, C; Handley, M (enero de 2021). SDP: Protocolo de descripción de sesión . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC8866 . ISSN 2070-1721 . RFC 8866 . Norma propuesta. Sustituye a RFC 4566 . 
  14. Zurawski, Richard (2004). "Protocolos RTP, RTCP y RTSP" . Manual de tecnología de la información industrial . CRC Press. págs. 28-27 . ISBN  978-0-8493-1985-3.
  15. Collins, Daniel (2002). "Transporte de voz mediante IP". Voz sobre IP de nivel operador . McGraw-Hill Professional. 47 págs . ISBN  978-0-07-136326-6.
  16. 1 2 3 4 5 6 7 8 9 H. Schulzrinne; S. Casner; R. Frederick; V. Jacobson (julio de 2003). RTP: Un protocolo de transporte para aplicaciones en tiempo real . Grupo de trabajo de redes. doi : 10.17487/RFC3550 . STD 64. RFC 3550 .Estándar de Internet 64. Actualizado por RFC 8860 , 7160 , 5761 , 5506 , 6051 , 6222 , 7022 , 7164 y 8083. Deja obsoleto el RFC 1889 .  
  17. C. Perkins; M. Westerlund (abril de 2010). Multiplexación de paquetes de datos y control RTP en un solo puerto . Grupo de trabajo de investigación de Internet (IRTF). doi : 10.17487/RFC5761 . ISSN 2070-1721 . RFC 5761 . Estándar propuesto. Actualiza RFC 3550 , 3551. Actualizado por RFC 8858 y 8035 .  
  18. RFC 3550 
  19. Perkins 2003 , pág. 60 
  20. 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.
  21. Perkins 2003 , pág. 367 
  22. Breese, Finley (2010). Comunicación serial sobre RTP/CDP . BoD - Books on Demand. pp. ISBN 978-3-8391-8460-8.
  23. Peterson y Davie 2007 , pág. 430 
  24. 1 2 3 Peterson y Davie 2007 , pág. 431
  25. Perkins 2003 , pág. 59
  26. Peterson, pág. 432
  27. 1 2 Perkins 2003 , págs. 11–13 
  28. H. Schulzrinne; S. Casner (julio de 2003). Perfil RTP para conferencias de audio y video con control mínimo . Grupo de trabajo de redes. doi : 10.17487/RFC3551 . STD 65. RFC 3551 .Estándar de Internet 65. Actualizado por RFC 8860 , 5761 y 7007. Deja obsoleto el RFC 1890 .  
  29. S. Casner (febrero de 2007). Registro de tipo de medio de formatos de carga útil RTP . Grupo de trabajo de red. doi : 10.17487/RFC4855 . RFC 4855 .Norma propuesta. Sustituye a RFC 3555. Actualizada por RFC 8851 .  
  30. S. Casner (marzo de 2007). Registro de tipos de medios de formatos de carga útil en el perfil RTP para conferencias de audio y video . Grupo de trabajo de red. doi : 10.17487/RFC4856 . RFC 4856 .Norma propuesta. Sustituye a RFC 3555 . 
  31. J. Lennox; K. Gross; S. Nandakumar; G. Salgueiro (noviembre de 2015). B. Burman (ed.). Una taxonomía de semántica y mecanismos para fuentes de protocolo de transporte en tiempo real (RTP) . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC7656 . ISSN 2070-1721 . RFC 7656 . Informativo.
  32. K. Kobayashi; A. Ogawa; A. Ogawa; C. Bormann (enero de 2002). Formato de carga útil RTP para audio DAT de 12 bits y audio muestreado lineal de 20 y 24 bits . Grupo de trabajo de redes. doi : 10.17487/RFC3190 . RFC 3190 .Norma propuesta.
  33. Y.-K. Wang; R. Even; T. Kristensen; R. Jesup (mayo de 2011). Formato de carga útil RTP para vídeo H.264 . Grupo de trabajo de ingeniería de Internet (IETF). doi : 10.17487/RFC6184 . RFC 6184 .Norma propuesta. Sustituye a RFC 3984 . 
  34. J. van der Meer; D. Mackie; V. Swaminathan; D. Singer; P. Gentric (noviembre de 2003). Formato de carga útil RTP para el transporte de flujos elementales MPEG-4 . Grupo de trabajo de redes. doi : 10.17487/RFC3640 . RFC 3640 .Norma propuesta. Actualizada por RFC 5691 . 
  35. M. Schmidt; F. de Bont; S. Doehla; J. Kim (octubre de 2011). Formato de carga útil RTP para flujos de audio/vídeo MPEG-4 . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6416 . ISSN 2070-1721 . RFC 6416 . Norma propuesta. Sustituye a RFC 3016 . 
  36. D. Hoffman; G. Fernando; V. Goyal; M. Civanlar (enero de 1998). Formato de carga útil RTP para vídeo MPEG1/MPEG2 . Grupo de trabajo de redes. doi : 10.17487/RFC2250 . RFC 2250 .Norma propuesta. Sustituye a RFC 2038 . 
  37. L. Gharai; C. Perkins (septiembre de 2005). Formato de carga útil RTP para vídeo sin comprimir . Grupo de trabajo de redes. doi : 10.17487/RFC4175 . RFC 4175 .Estándar propuesto. Actualizado por RFC 4421 . 
  38. J. Lazzaro; J. Wawrzynek (junio de 2011). Formato de carga útil RTP para MIDI . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6295 . ISSN 2070-1721 . RFC 6295 . Norma propuesta. Sustituye a RFC 4695 . 
  39. J. Lazzaro; J. Wawrzynek (noviembre de 2006). Una guía de implementación para RTP MIDI . Grupo de trabajo de redes. doi : 10.17487/RFC4696 . RFC 4696 .Informativo.
  40. K. Gross; R. van Brandenburg (marzo de 2014). RTP y segundos intercalares . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC7164 . ISSN 2070-1721 . RFC 7164 . Norma propuesta. Actualiza la RFC 3550 . 
  41. J. Spittka; K. Vos; JM. Valin (junio de 2015). Formato de carga útil RTP para el códec de voz y audio Opus . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC7587 . ISSN 2070-1721 . RFC 7587 . Norma propuesta.
  42. Y.-K. Wang; Y. Sanchez; T. Schierl; S. Wenger; MM Hannuksela (marzo de 2016). Formato de carga útil RTP para codificación de vídeo de alta eficiencia (HEVC) . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC7798 . ISSN 2070-1721 . RFC 7798 . Norma propuesta.
  • 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 de computadoras (4.ª  ed.). Morgan Kaufmann. ISBN 978-0-12-374013-7.

Lecturas adicionales

  • "RTP" . Manual de protocolos de red . Javvin Technologies. 2005. ISBN 978-0-9740945-2-6.
  • Página de RTP de Henning Schulzrinne (incluidas las preguntas frecuentes )
  • GNU ccRTP
  • JRTPLIB, una biblioteca RTP de C++
  • Agregación de medios administrada Archivada el 09/01/2018 en Wayback Machine : Implementación de RTP / RTCP compatible con RFC en .NET C# escrita en código completamente administrado.
  • "RTP" , Redes de banda ancha , Ministerio de Recursos Humanos, India, 2008, archivado del original el 18 de noviembre de 2021.