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 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:

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 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 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

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 genera 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 , 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

Ver también

Notas

  1. ^ 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

  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.; Federico, 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 Televisión por Protocolo de Internet
  6. ^ 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 
  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 móviles e inalámbricas. Guadalupe, 2007 ISBN 0-7695-2796-5 
  8. ^ 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