rtp y rtcp

RTP
PROTOCOLO PARA APLICACIONES MULTIMEDIALES
Versión 1.01

4. Real-time Transport Control Protocol (RTCP)

RTCP proporciona un stream de control que está asociado con un stream de datos para una aplicación multimedia.

Funciones.

Este stream de control tiene tres funciones principales:

Retroalimenta información sobre el desempeño de la aplicación y de la red
Ofrece una forma de correlacionar y sincronizar diferentes media streams que provienen del mismo emisor
Proporciona una forma de transferir la identidad de un emisor para ser mostrada en la interface de un usuario

La primera función es muy útil para aplicaciones de velocidad adaptativa y le permitiría, por ejemplo, utilizar un esquema de compresión más agresivo para reducir la congestión o enviar un stream de más alta calidad ya que hay poca congestión. Esta característica puede ser útil también para diagnosticar problemas de la red.

La segunda función parece estar ya cubierta con el identificador de fuente de sincronización de RTP (SSRC), pero en realidad no es así. Como se dijo antes, un nodo con varias cámaras pueden tener un SSRC diferente para cada cámara. Adicionalmente, no se requiere que un stream de audio y otro de video provenientes del mismo nodo utilicen el mismo SSRC. Ya que pueden darse colisiones de identificadores de SSRC es posible que se requiera cambiar el valor SSRC de un stream. Para poder manejar este problema, RTCP utiliza el concepto de nombre canónico (CNAME) que es asignado al emisor, este nombre canónico es luego asociado a varios valores SSRC que pueden ser utilizados por dicho emisor utilizando RTCP.

La correlación simple de dos streams es sólo parte del problema de sincronización intermedia. Como, además, diferentes streams pueden tener también relojes diferentes (con diferentes granuladidades y aún diferentes grados de inexactitud) existe la necesidad de definir una forma de sincronizar streams exactamente entre ellos. RTCP maneja este problema.

Tipos de paquetes RTCP

RTCP define varios tipos de paquetes, que incluyen

Reportes de emisor, que permite al emisor activo en una sesión reportar estadísticas de recepción y trasmisión.
Reportes de receptor, que los receptores que no son emisores, utilizan para enviar estadísticas de recepción.
Descripción de fuente, que lleva los CNAMEs y otra información que describe la información de los emisores.
Paquetes de control específicos a la aplicación

Varios paquetes RTCP pueden ser enviados en un mismo mensaje UDP.

En trasmisiones multicast la información de control puede consumir un ancho de banda considerable (2 o 3 personas en audioconferencia consumen cierta cantidad de ancho de banda para información de control, ¿cuánto se consumirá con 1000 personas?). Para manejar este problema RTCP ha establecido un mecanismo para reducir la trasmisión de información de control a medida que ingresan más nodos a la conferencia. El mecanismo es complejo para contarlo en este documento, pero la meta básica es limitar la cantidad de tráfico de RTCP a un pequeño porcentaje del tráfico de datos en RTP (normalmente el 5%). También es recomendado asignar más ancho de banda RTCP a los emisores activos, bajo el supuesto que la mayoría de los participantes desean ver los reportes enviados por ellos, como por ejemplo saber "quién habla".

Una vez un participante sabe cuánto ancho de banda puede consumir con el tráfico de RTCP, la aplicación comienza a enviar reportes periódicos en la tasa adecuada. Los reportes del emisor (sender reports) y los reportes del receptor (receiver reports) difieren en que sólo los primeros incluyen información extra sobre el emisor. Los dos tipos de reportes contienen información sobre los datos que fueron recibidos de todas las fuentes en el periódo de reportes más reciente.

La información extra en un reporte de emisor consta de:

Un timestamp que contiene el tiempo real del día cuando el reporte fue generado
Un timestamp RTP correspondiente al momento en que el reporte fue generado
Un acumulado de los paquetes y bytes enviados por ese emisor desde que comenzó la trasmisión.

Observe que las dos primeras cifras pueden ser utilizadas para habilitar la sincornización de diferentes tipos de streams desde la misma fuente, incluso cuando estos streams utilizan diferentes granularidades de reloj en sus streams de datos RTP, ya que da información suficiente para convertir el tiempo (hora) del día en timestamps RTP.

Tanto los reportes de emisor como de receptor contienen un bloque de datos por fuente que ha sido oida desde el último reporte. Cada bloque contiene las siguientes estadísticas para la fuente en cuestión:

Su SSRC
La fracción de paquetes de datos desde esta fuente que se han perdido desde que el último reporte fue enviado (calculado al comparar el número de paquetes recibidos con el número de paquetes esperados; este último valor puede ser determinado a partir de los números de secuencia RTP).
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 recibido desde esta fuente
Jitter entre arribos estimado para la fuente (calculado por comparar el espacio entre arribos de los paquetes recibidos con el espaciamiento esperado en el tiempo de trasmisión).
Último timestamp real recibido a través de RTCP desde dicha fuente
Retardo desde el último reporte de emisor recibido a través de RTCP para esta fuente.

Como puede imaginar, los receptores de esta información pueden aprender muchas cosas sobre el estado de la sesión. En particular, ellos pueden ver si otros receptores están obteniendo mejor calidad de otro emisor que la que tienen ellos y puede ser un indicio para hacer una reservación de recursos o el síntoma de un problema en la red que debe ser atentido. Además, si un emisor observa que muchos receptores están esperando un alto porcentaje de perdida de paquetes, él podría decidir reducir su rata de envíos o utilizar un esquema de codificación más resistente a las perdidas.

Descripción de la fuente.

El aspecto final a considerar de RTCP es el paquete de descripción de la fuente. Dicho paquete contiene, como mínimo, el SSRC del emisor y el CNAME del emisor. El nombre canónico es derivado de tal forma que todas las aplicaciones que generen media streams que requieran ser sincronizadas (por ejemplo, generación separada de video y audio por el mismo usuario) escogerán el mismo CNAME aunque pueden escoger diferentes SSRC. Esto permite al receptor identificar el media stream que viene del mismo emisor. El formato común de CNAME es de la forma usuario@host, donde host es el nombre completo del dominio donde se encuentra el emisor. Así, una aplicación que sea activada por el usuario que se llama oscar y esta trabajando en el dominio camara2.arcesio.net utilizará oscar@camara2.arcesio.net como su CNAME. El nombre largo y con variable número de bytes utilizado en esta representación podría ser una mala selección para el formato de un SSRC ya que el SSRC siempre se envía con cualquier paquete de datos y debe ser procesado en tiempo real. Al ajustar los CNAMEs con los valores SSRC en mensajes periódicos de RTCP (no en todos) permite utilizar un formato eficiente y compacto para los SSRC.

Otros datos pueden ser incluidos en el paquete de descripción de la fuente, tales como el nombre real y el e-mail del usuario. Estos son utilizados en la interface del usuario para permitir identificar las personas, pero esta información es menos esencial para la operación de RTP que el CNAME.

[Anterior] [Índice] [Siguiente]