stringtranslate.com

Protocolo de control RTP

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 la 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 en sí.

La función principal de RTCP es proporcionar información sobre la calidad del servicio (QoS) en la distribución de medios mediante el envío periódico de información estadística, como recuentos de octetos y paquetes transmitidos, pérdida de paquetes , variación del retardo de paquetes y tiempo de retardo de ida y vuelta a los participantes en una sesión de transmisión multimedia. Una aplicación puede utilizar esta información para controlar los parámetros de calidad del servicio, tal vez limitando el flujo o utilizando un códec diferente .

Funciones del protocolo

Normalmente, el 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]

El protocolo RTCP en sí no proporciona ningún método de cifrado o autenticación de flujo. Dichos mecanismos pueden implementarse, por ejemplo, con el Protocolo de transporte seguro en tiempo real (SRTP) definido en RFC 3711.

RTCP proporciona funciones básicas que se espera que se implementen en todas las sesiones RTP:

Se espera que todos los participantes envíen informes RTCP, incluso en una sesión de multidifusión que puede involucrar a miles de destinatarios. Este tráfico aumentará proporcionalmente con el número de participantes. Por lo 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 transmisión de informes. El uso del ancho de banda RTCP generalmente no debe superar el 5% del ancho de banda total de la sesión. Además, el 25% del ancho de banda RTCP debe reservarse para fuentes de medios en todo momento, de modo que en conferencias grandes los nuevos participantes puedan recibir los identificadores CNAME de los remitentes sin demora excesiva.

El intervalo de notificación RTCP es aleatorio para evitar una sincronización no deseada de la notificación. El intervalo de notificación RTCP mínimo recomendado por estación es de 5 segundos. Las estaciones no deben transmitir notificaciones RTCP con una frecuencia mayor a una vez cada 5 segundos.

Encabezado del paquete

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 despedida . Además, el protocolo es extensible y permite paquetes RTCP específicos de la aplicación. Una extensión basada en estándares de RTCP es el tipo de paquete de informe extendido introducido por RFC 3611. [3]

Informe del remitente (SR)
El informe del remitente es enviado periódicamente por los remitentes activos en una conferencia 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 utilizando el formato de marca de tiempo del Protocolo de Tiempo de Red (NTP) (que está en segundos relativos a 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 por este Informe del remitente. [2] : 12, 37  La marca de tiempo absoluta permite al receptor sincronizar los mensajes RTP. Es particularmente importante cuando se transmiten tanto audio como video simultáneamente porque las transmisiones de audio y video usan marcas de tiempo relativas independientes.
Informe del receptor (RR)
El informe del receptor está destinado a los participantes pasivos, aquellos que no envían paquetes RTP. El informe informa al remitente y a otros receptores sobre la calidad del servicio.
Descripción de la fuente (SDES)
El mensaje de descripción de la 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 del controlador de la fuente.
Adios (ADIÓS)
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 para el protocolo RTCP.

Escalabilidad en grandes implementaciones

En aplicaciones a gran escala, como 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 de ancho de banda RTCP necesario para controlar la congestión (consulte Funciones del protocolo). Las frecuencias aceptables suelen ser inferiores a una por minuto. Esto ofrece la posibilidad de que el receptor informe de forma inadecuada las estadísticas pertinentes o hace que la evaluación por parte del emisor de 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, polarización 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 desplazar 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 informe sobre la QoS depende, entre otros, de una cantidad 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 aproximadamente 10 segundos de informe. Valores mayores causarían un estado informado diferido en el tiempo y muy inexacto sobre el estado actual de la sesión y cualquier optimización realizada por el remitente podría incluso tener un efecto negativo en las condiciones de la red o de la QoS.

La agregación jerárquica se utiliza con multidifusión específica de origen , donde solo se permite una única fuente, es decir, IPTV . Otro tipo de multidifusión podría ser la multidifusión de cualquier origen , pero no es tan adecuada para aplicaciones a gran escala con una gran cantidad de usuarios.

A partir de junio de 2007 , sólo los sistemas IPTV más modernos utilizan la agregación jerárquica. [ cita requerida ]

Objetivo de retroalimentación

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 de receptor (RR) (consulte RTCP ) y retransmitir paquetes RR resumidos, denominados información resumida del receptor (RSI) [8] a un remitente (en caso de jerarquía de un solo nivel).

Documentos de normas

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.

Referencias

  1. ^ 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 . 
  2. ^ abcdefgh Jacobson, V.; Frederick, R.; Casner, S.; Schulzrinne, H. RTP: un protocolo de transporte para aplicaciones en tiempo real. doi : 10.17487/RFC3550 . RFC 3550.
  3. ^ 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)
  4. ^ Vít Novotný, Dan Komosný, Optimización de retroalimentación RTCP a gran escala , Journal of Networks, Vol.3 (3), marzo de 2008
  5. ^ Protocolo de control en tiempo real y sus mejoras para la Televisión por Protocolo de Internet
  6. ^ KOMOSNY D., NOVOTNY V. Estructura de árbol para multidifusión de origen específico con agregación de retroalimentación, en ICN07 - Sexta conferencia internacional sobre redes. Martinica, 2007 ISBN 0-7695-2805-8 
  7. ^ 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 inalámbricas y móviles. Guadalupe, 2007 ISBN 0-7695-2796-5 
  8. ^ ab J. Ott; J. Chesterfield; E. Schooler. Extensiones RTCP para sesiones de multidifusión de fuente única con retroalimentación de unidifusión . RFC 5760 . 

Lectura adicional