Protocolo de control en tiempo real , la enciclopedia libre

Este artículo o sección necesita referencias que aparezcan en una publicación acreditada. Busca fuentes: «Protocolo de control en tiempo real» – noticias · libros · académico · imágenes Este aviso fue puesto el 27 de enero de 2015.

El protocolo de control en tiempo real (en inglés: Real Time Control Protocol) es un protocolo de comunicación que proporciona información de control que está asociado con un flujo de datos para una aplicación multimedia (flujo RTP). Trabaja junto con RTP en el transporte y empaquetado de datos multimedia, pero no transporta ningún dato por sí mismo. Se usa habitualmente para transmitir paquetes de control a los participantes de una sesión multimedia de streaming. La función principal de RTCP es informar de la calidad de servicio proporcionada por RTP. Este protocolo recoge estadísticas de la conexión y también información como por ejemplo bytes enviados, paquetes enviados, paquetes perdidos o Jitter entre otros. Una aplicación puede usar esta información para incrementar la calidad de servicio (QoS), ya sea limitando el flujo o usando un códec de compresión más baja. En resumen. RTCP se usa para informar de la QoS (Quality of Service). RTCP por sí mismo no ofrece ninguna clase de cifrado de flujo o de autenticación. Para tales propósitos se puede usar SRTCP.

Esta función es muy útil para aplicaciones de velocidad adaptativa. Un ejemplo de su utilidad sería reducir la congestión mediante el uso de un esquema de compresión más agresivo o enviar un stream de más alta calidad cuando hay poca congestión. También puede resultar útil para diagnosticar problemas de red.

Aquí es muy importante establecer la diferencia entre el identificador de fuente de sincronización de RTP, el SSRC y el CNAME del RTCP. Por ejemplo, un stream de audio y vídeo procedentes del mismo emisor utilizan diferentes SSRC, puesto que en el caso contrario se podrían dar colisiones de identificadores SSRC. Para solucionar este problema, RTCP utiliza el concepto de nombre canónico (CNAME) que se asigna al emisor. Este CNAME es asociado a varios valores SSRC. Así se garantiza que streams que no tienen el mismo SSRC se puedan sincronizar y ordenar correctamente.

Se transmite en el paquete de descripción de la fuente explicado más adelante en el apartado Tipo de paquetes

RTCP define varios tipos de paquetes que incluyen:

- Informes de emisor: Permiten al emisor activo en una sesión informar sobre estadísticas de recepción y transmisión.

- Informes de receptor: Los utilizan los receptores que no son emisores para enviar estadísticas sobre la recepción.

- Descripción de la fuente: Contiene los CNAMEs y otros datos que describen la información de los emisores.

- Paquetes de control específicos de la aplicación. Varios paquetes RTCP pueden ser enviados en un mismo mensaje UDP.

A continuación explicaremos la importancia de la existencia de estos paquetes. En transmisiones multicast la información de control puede consumir un ancho de banda considerable. Para hacerse cargo de este problema RTCP ha establecido un mecanismo para reducir la transmisión de información de control a medida que ingresan más usuarios, que consiste en limitar la cantidad de tránsito de RTCP en un pequeño porcentaje de tráfico de datos en RTP. Este mecanismo también asigna más ancho de banda RTCP a los emisores activos. Un golpe un participante sabe cuánto ancho de banda puede consumir con el tránsito de RTCP la aplicación empieza a enviar informes periódicos de la tasa adecuada. Los informes de emisor y de receptor contienen información sobre los datos recibidos de todas las fuentes en el periodo de informes más reciente. Lo que los diferencia es que los informes de emisor incluyen información extra sobre el emisor. Tanto los informes de emisor (sender reports) como los de receptor (receiver reports) contienen un bloque de datos por fuente que ha sido escuchada desde el último informe. Cada bloque contiene las siguientes estadísticas para la fuente determinada:

· Su SSRC

· La fracción de paquetes de datos de la fuente que se han perdido desde que fue enviado el último informe.

· Número total de paquetes perdidos con origen en esta fuente desde la primera vez que fue escuchada.

· El número de secuencia más alto recibo desde esta fuente

· Jitter

· Último timestamp (contiene la hora del día en que el informe fue generado) recibido a través de RTCP desde la fuente.

· Retardo desde el último informe de emisor recibido a través de RTCP por la fuente. Los receptores pueden deducir muchas cosas a partir de estas informaciones sobre el estado de la sesión. Por ejemplo, pueden ver si otros receptores están obteniendo mejor calidad de otro emisor que la que ellos disponen. Esto puede ser un indicio para reservar recursos o un síntoma de un problema de la red que debe ser atendido.

Paquete de descripción de la fuente

Este paquete contiene como mínimo el SSRC y el CNAME del emisor. El nombre canónico es derivado, de tal manera que todas las aplicaciones que generan media streams que requieran ser sincronizadas, escogerán el mismo CNAME aunque puedan escoger diferentes SSRC. Esto permite al receptor identificar el media stream que viene del mismo emisor. Se pueden incluir otros datos en este paquete, como por ejemplo el nombre real del usuario y su correo electrónico. Estos son utilizados en la interfícice del usuario para permitir identificar las personas.

Cabecera MAC - Cabecera IP - Cabecera UDP - Cabecera RTCP - Datos

Cabecera RTCP

Versión: 2 bits. Indica la versión RTP, que es la misma en los paquetes RTCP que en los RTP

Padding: 1 bit. Si está activado quiere decir que el paquete contiene algunos bits de padding al final que no forman parte de la información de control. El último byte del padding indica cuántos bytes de padding se tiene que ignorar.

Count: 5 bits. Indica el número de bloques de informes de receptor contenidos en este paquete.

Type: 8 bits. Indica el tipo de paquete RTCP

Length: 16 bits. Indica la longitud del paquete RTCP