Protocolo hermano del Protocolo de transporte en tiempo real que proporciona información de control
El protocolo de control RTP ( RTCP ) es un protocolo de señalización fuera de banda codificado en binario que funciona junto con el protocolo de transporte en tiempo real (RTP). Su funcionalidad básica y estructura de paquetes se definen en RFC 3550. RTCP proporciona estadísticas e información de control para una sesión RTP. Se asocia con RTP en la entrega y empaquetado de datos multimedia, pero no transporta ningún dato multimedia.
La función principal de RTCP es proporcionar retroalimentación sobre la calidad de servicio (QoS) en la distribución de medios mediante el envío periódico de información estadística, como recuentos de paquetes y octetos transmitidos, pérdida de paquetes , variación del retardo de paquetes y tiempo de retardo de ida y vuelta a los participantes en un Sesión multimedia en streaming. Una aplicación puede usar esta información para controlar los parámetros de calidad del servicio, tal vez limitando el flujo o usando un códec diferente .
Funciones de protocolo
Normalmente, RTP se enviará a través de un puerto UDP par y los mensajes RTCP se enviarán a través del siguiente puerto impar superior. [1]
RTCP en sí no proporciona ningún método de autenticación o cifrado de flujo. Dichos mecanismos pueden implementarse, por ejemplo, con el Protocolo seguro de transporte en tiempo real (SRTP) definido en RFC 3711.
RTCP proporciona funciones básicas que se espera que se implementen en todas las sesiones de RTP:
- La función principal de RTCP es recopilar estadísticas sobre aspectos de calidad de la distribución de medios durante una sesión y transmitir estos datos a la fuente de medios de la sesión y a otros participantes de la sesión. La fuente puede utilizar dicha información para la codificación de medios adaptativos ( códec ) y la detección de fallas de transmisión. Si la sesión se transmite a través de una red de multidifusión, esto permite un control no intrusivo de la calidad de la sesión.
- RTCP proporciona identificadores de punto final canónicos (CNAME) a todos los participantes de la sesión. Aunque se espera que un identificador de origen (SSRC) de un flujo RTP sea único, la vinculación instantánea de los identificadores de origen a los puntos finales puede cambiar durante una sesión. El CNAME establece una identificación única de puntos finales en una instancia de aplicación (uso múltiple de herramientas multimedia) y para el monitoreo de terceros.
- Provisión de funciones de control de sesiones. RTCP es un medio conveniente para llegar a todos los participantes de la sesión, mientras que RTP en sí no lo es. RTP solo se transmite a través de una fuente de medios.
Se espera que todos los participantes envíen informes RTCP, incluso en una sesión de multidifusión en la que pueden participar miles de destinatarios. Dicho tráfico aumentará proporcionalmente con el número de participantes. Por tanto, para evitar la congestión de la red, el protocolo debe incluir la gestión del ancho de banda de la sesión. Esto se logra controlando dinámicamente la frecuencia de las transmisiones de informes. El uso del ancho de banda RTCP generalmente no debe exceder el 5% del ancho de banda total de la sesión. Además, el 25% del ancho de banda RTCP debe reservarse en todo momento para fuentes de medios, de modo que en conferencias grandes los nuevos participantes puedan recibir los identificadores CNAME de los remitentes sin demoras excesivas.
El intervalo de informes RTCP es aleatorio para evitar una sincronización no deseada de los informes. El intervalo mínimo recomendado de informe RTCP por estación es de 5 segundos. Las estaciones no deben transmitir informes RTCP más de una vez cada 5 segundos.
encabezado del paquete
- Versión : (2 bits) Identifica la versión de RTP, que es la misma en los paquetes RTCP que en los paquetes de datos RTP. La versión definida por esta especificación es dos (2). [2]
- P (Relleno) : (1 bits) Indica 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 el número de bytes de relleno que se agregaron (incluido él mismo). [2]
- RC (recuento de informes de recepción) : (5 bits) El número de bloques de informes de recepción contenidos en este paquete. Un valor de cero es válido. [2]
- PT (tipo de paquete) : (8 bits) Contiene una constante para identificar el tipo de paquete RTCP. [2]
- Longitud : (16 bits) Indica la longitud de este paquete RTCP (incluido el encabezado mismo) en unidades de 32 bits menos uno. [2]
- SSRC : (32 bits) El identificador de fuente de sincronización identifica de forma única la fuente de una secuencia. [2]
Tenga en cuenta que se pueden concatenar varios informes en un único paquete RTCP compuesto, cada uno con su propio encabezado de paquete.
Tipos de mensajes
RTCP distingue varios tipos de paquetes: informe del remitente , informe del receptor , descripción de la fuente y adiós . Además, el protocolo es extensible y permite paquetes RTCP específicos de la aplicación. Una extensión de RTCP basada en estándares es el tipo de paquete de informe extendido introducido por RFC 3611. [3]
- Informe del remitente (SR)
- Los remitentes activos en una conferencia envían periódicamente el informe del remitente para informar las estadísticas de transmisión y recepción de todos los paquetes RTP enviados durante el intervalo. El informe del remitente incluye dos marcas de tiempo distintas, una marca de tiempo absoluta, representada mediante el formato de marca de tiempo del Protocolo de tiempo de red (NTP) (que está en segundos en relación con la medianoche UTC del 1 de enero de 1900) y una marca de tiempo RTP que corresponde a la misma hora que la marca de tiempo NTP, pero en las mismas unidades y con el mismo desplazamiento aleatorio que las marcas de tiempo RTP en los paquetes de datos descritos en este Informe del remitente. [2] : 12, 37 La marca de tiempo absoluta permite al receptor sincronizar mensajes RTP. Es particularmente importante cuando tanto el audio como el video se transmiten simultáneamente porque las transmisiones de audio y video utilizan marcas de tiempo relativas independientes.
- Informe del receptor (RR)
- El informe del receptor es para participantes pasivos, aquellos que no envían paquetes RTP. El informe informa al remitente y a otros destinatarios sobre la calidad del servicio.
- Descripción de la fuente (SDES)
- El mensaje de descripción de fuente se utiliza para enviar el elemento CNAME a los participantes de la sesión. También se puede utilizar para proporcionar información adicional como el nombre, la dirección de correo electrónico, el número de teléfono y la dirección del propietario o controlador de la fuente.
- Adios)
- Una fuente envía un mensaje BYE para cerrar una transmisión. Permite que un punto final anuncie que abandona la conferencia. Aunque otras fuentes pueden detectar la ausencia de una fuente, este mensaje es un anuncio directo. También es útil para un mezclador de medios.
- Mensaje específico de la aplicación (APP)
- El mensaje específico de la aplicación proporciona un mecanismo para diseñar extensiones específicas de la aplicación al protocolo RTCP.
Escalabilidad en grandes implementaciones
En aplicaciones a gran escala, como en la televisión por protocolo de Internet (IPTV), pueden producirse retrasos muy largos (de minutos a horas) entre los informes RTCP, debido al mecanismo de control del ancho de banda RTCP necesario para controlar la congestión (consulte Funciones del protocolo). Las frecuencias aceptables suelen ser menos de una por minuto. Esto ofrece la posibilidad de que el receptor informe de manera inapropiada las estadísticas relevantes o haga que la evaluación por parte del remitente de los medios sea inexacta en relación con el estado actual de la sesión. Se han introducido métodos para aliviar los problemas: [4] Filtrado RTCP, sesgo RTCP y agregación jerárquica . [5]
Agregación jerárquica
La agregación jerárquica (o también conocida como jerarquía de retroalimentación RTCP) es una optimización del modelo de retroalimentación RTCP y su objetivo es cambiar aún más el límite de número máximo de usuarios junto con la medición de la calidad de servicio (QoS). [6] [7] El ancho de banda RTCP es constante y ocupa solo el 5% del ancho de banda de la sesión. Por lo tanto, el intervalo de notificación de QoS depende, entre otros, del número de miembros de la sesión y, para sesiones muy grandes, puede llegar a ser muy alto (minutos o incluso horas). [2] Sin embargo, el intervalo aceptable es de unos 10 segundos de informes. Los valores más altos provocarían un estado informado diferido en el tiempo y muy inexacto sobre el estado de la sesión actual y cualquier optimización realizada por el remitente podría incluso tener un efecto negativo en las condiciones de la red o la QoS.
La agregación jerárquica se utiliza con multidifusión específica de fuente donde solo se permite una única fuente, es decir, IPTV . Otro tipo de multidifusión podría ser la multidifusión de cualquier fuente, pero no es tan adecuada para aplicaciones a gran escala con una gran cantidad de usuarios.
En junio de 2007 [update], sólo los sistemas IPTV más modernos utilizan agregación jerárquica. [ cita necesaria ]
Objetivo de comentarios
Feedback Target es un nuevo tipo de miembro que se introdujo por primera vez en el borrador de Internet draft-ietf-avt-rtcpssm-13. [8] El método de Agregación Jerárquica ha ampliado su funcionalidad. La función de este miembro es recibir informes del receptor (RR) (ver RTCP ) y retransmitir paquetes RR resumidos, la llamada información resumida del receptor (RSI) [8] a un remitente (en caso de jerarquía de un solo nivel).
Documentos de normas
- RFC 3550, Estándar 64, RTP: un protocolo de transporte para aplicaciones en tiempo real
Ver también
Notas
- ^ Los bits están ordenados del más significativo al menos significativo; 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 bits depende del medio.
Referencias
- ↑ C. Huitema (octubre de 2003). Atributo del Protocolo de control en tiempo real (RTCP) en el Protocolo de descripción de sesión (SDP) . RFC 3605 .
- ^ abcdefgh Jacobson, V.; Federico, R.; Casner, S.; Schulzrinne, H. RTP: un protocolo de transporte para aplicaciones en tiempo real. doi : 10.17487/RFC3550 . RFC 3550.
- ^ RFC 3611, Informes ampliados del protocolo de control RTP (RTCP XR) , T. Friedman (Ed.), R. Caceres, A. Clark (Ed.), The Internet Society (noviembre de 2003)
- ^ Vít Novotný, Dan Komosný, Optimización de retroalimentación RTCP a gran escala , Journal of Networks, Vol.3 (3), marzo de 2008
- ^
Protocolo de control en tiempo real y sus mejoras para Televisión por Protocolo de Internet
- ^ KOMOSNY D., NOVOTNY V. Estructura de árbol para multidifusión de fuentes específicas con agregación de retroalimentación, en ICN07 - Sexta Conferencia Internacional sobre Redes. Martinica, 2007 ISBN 0-7695-2805-8
- ^ NOVOTNY, V., KOMOSNY, D. Optimización de informes de retroalimentación RTCP a gran escala en ICWMC 2007. ICWMC 2007 - Tercera conferencia internacional sobre comunicaciones móviles e inalámbricas. Guadalupe, 2007 ISBN 0-7695-2796-5
- ^ ab J. Ott; J. Chesterfield; E. Escolar. Extensiones RTCP para sesiones de multidifusión de fuente única con retroalimentación de unidifusión . RFC 5760 .
Otras lecturas