El protocolo RTCP (Protocolo de Control de Transporte en Tiempo Real) desempeña un papel fundamental en la monitorización y el mantenimiento de la calidad de la llamada en las comunicaciones de VoIP (Voz sobre IP). Aunque los protocolos TCP/IP de internet no fueron creados para la transmisión de datos en tiempo real, en 1996 se crearon el conjunto de protocolos RTP y RTCP que permiten que esto sea posible. Ya tratamos el protocolo RTP en otro artículo (RTP. Protocolo de transporte en tiempo real) y ahora es el turno de profundizar en el protocolo RTCP.

RTCP proporciona información vital sobre la calidad de la red durante una llamada VoIP, permitiendo identificar y abordar problemas potenciales que podrían afectar la experiencia del usuario. Esta información incluye métricas como la pérdida de paquetes, tiempos de transmisión o jitter (variabilidad del retraso en los paquetes). Estos datos permiten al software de los participantes identificar problemas específicos de la red y tomar las medidas correctivas necesarias.

Por ejemplo, los algoritmos de control pueden ajustar dinámicamente la tasa de bits de la transmisión de audio. Esto permite optimizar la calidad de la llamada en función de las condiciones de la red, asegurando una experiencia fluida y adaptable.

RTCP también permite detectar fallos en los dispositivos de los participantes, como la pérdida de la conexión o la caída de un dispositivo. Al identificar estos fallos, se pueden tomar medidas para recuperar la llamada o notificar a los participantes sobre el problema.

Por último, RTCP proporciona información estadística sobre la calidad de la llamada, lo que resulta muy útil para evaluar el rendimiento general de la red VoIP y para identificar áreas que podrían requerir mejoras.

En resumen, el protocolo RTCP juega un papel fundamental en las comunicaciones VoIP al permitir la monitorización de la calidad de la red, la retroalimentación a los participantes, el ajuste dinámico de la tasa de bits, la sincronización de relojes, la detección y recuperación de fallos, y la recopilación de información estadística. Estos aspectos contribuyen a garantizar una experiencia de llamada VoIP fluida, confiable y de alta calidad.

Si fuese necesario, en estos otros artículos puede informarse sobre Cómo funcionan los protocolos de Internet, las Cabeceras de los paquetes de internet y Cómo funciona la telefonía IP o VoIP.

RTCP. Intercambio de información

El protocolo RTCP facilita el intercambio periódico de información entre los participantes de la sesión. La finalidad de RTCP es informar a la fuente del sonido o vídeo de la calidad con la que está llegando al destino. Esta información puede ser utilizada por la aplicación o por el operador del servicio para detectar y corregir posibles problemas.

Una información incluida en RTCP que no se incluye en los paquetes RTP es el nombre CNAME (Canonical Name, ‘Nombre canónico’)  de los participantes de la sesión. RTP utiliza el número SSRC para identificar a los participantes, pero este número puede cambiar de una sesión a otra, o incluso el mismo participante podría generar distintos SSRC en una misma sesión (por ejemplo, cuando emite audio y vídeo simultáneamente). El nombre CNAME es único para cada participante y tiene la forma usuario@host. Este nombre no está relacionado con ninguna dirección de correo electrónico, sino que lo crea automáticamente la aplicación componiendo el nombre del usuario y la identificación del ordenador donde se encuentra. Por ejemplo, juan@192.0.2.89 sería un CNAME. A este nombre también se lo conoce como nombre oficial o nombre único.

Se tienen distintos tipos de paquetes RTCP:

• Informe de emisor (SR, Sender Report). Se utiliza para informar de las estadísticas de los participantes que son emisores activos.
• Informe de receptor (RR, Receiver Report). Se utiliza para informar de las estadísticas de los participantes que son sólo receptores del flujo, no emisores (sólo escuchan).
• Descripción de la fuente (SDES, Source Description). Contiene la descripción de la fuente, incluyendo el nombre CNAME, así como información de carácter personal como el nombre, correo electrónico o número de teléfono del participante.
• Fin (Bye). Indica el final de la participación en la sesión.
• Funciones específicas de la aplicación (APP, Application-Specific Functions). Los paquetes APP permiten enviar información específica de una determinada aplicación o tipo de flujo.

Las especificaciones de RTCP indican que estos paquetes deben enviarse agrupados, de forma que cada grupo incluya, al menos, un paquete de informe (SR o RR) y un paquete SDED. Por tanto, para enviar un paquete de fin de la participación, además habría que incluir, por ejemplo, un paquete SR y otro SDED. Además, el envío de paquetes RTCP debe cumplir otras condiciones como: las estadísticas de recepción (SR o RR) se deben enviar tan frecuentemente como lo permita el ancho de banda, los nuevos receptores deben recibir el CNAME de la fuente tan pronto como sea posible, el intervalo entre paquetes RTCP debe ser mayor de 5 segundos (este intervalo debe ser calculado aleatoriamente por cada participante para evitar que todos lo hagan al mismo tiempo), etc.

Informe de emisor. SR

El informe de emisor o SR lo utilizan los participantes de la sesión que son emisores activos de paquetes RTP. Los paquetes SR suelen aprovecharse para adjuntar mensajes RR con información sobre los paquetes RTP que se reciben de otros participantes.

Los paquetes SR tienen cuatro secciones distintas:

• Información de cabecera (32 bits)
• El informe de emisor propiamente dicho (160 bits)
• Un informe de receptor RR (192 bits) por cada fuente emisora que se ha escuchado desde el último informe. Si no se ha recibido nada no se adjuntará ningún RR.
• Determinados perfiles específicos necesitan, además, de una extensión de cabecera que sería añadida al final del paquete.

La cabecera de los paquetes SR dispone de los siguientes campos:

• Versión (V). Se trata de dos bits que indican la versión del protocolo RTP utilizada. La versión actual es la 2.
• Relleno (P, padding). Se trata de un bit para indicar que al final del paquete hay octetos de relleno. El último de estos octetos indica el total de ellos.
• Número de informes de receptor incluidos en el paquete (RC, Reception Report Count). Este campo tiene 5 bits, por lo que el número máximo de RR que se pueden incluir es 31. El mínimo sería cero.
• Tipo de paquete (PT, Packet Type). Son 8 bits que indican el tipo de paquete que se está enviando. En el caso de los paquetes SR tomaría el valor 200.
• Longitud del paquete (length). Indica el número de grupos de 32 bits que forman el paquete RTCP, sin incluir la cabecera. O lo que es lo mismo, número total de grupos menos uno.
• SSRC del remitente de este paquete RTCP.

Los campos correspondientes del informe de emisor son los siguientes:

• Contadores de tiempo NTP (Network Time Protocol, RFC1305). Se trata de un campo de 64 bits que indica el momento en el que se emitió este informe SR. Lo que aquí se indica es el tiempo transcurrido en segundos desde el 1 de enero de 1900 (GMT). Los 32 bits más significativos representan el número de segundos, mientras que los 32 bits menos significativos representan las fracciones de segundos, consiguiéndose una precisión de 200 picosegundos.
• Contador de tiempo RTP (RTP timestamp). Es un contador de tiempo de 32 bits que emplea el mismo formato que los contadores RTP. La inclusión de dos contadores de tiempo en el mismo informe le permite al destinatario sincronizarse mejor con el emisor.
• Conteo de paquetes del emisor. Indica el número total de paquetes RTP transmitidos por el emisor desde el comienzo de la sesión. Por tanto, este conteo de paquetes es acumulativo.
• Conteo de octetos del emisor. Indica el número total de octetos de carga útil (sin incluir cabecera ni relleno) incluidos en los paquetes RTP que ha enviado este emisor desde el comienzo de la sesión.

A la información del emisor le pueden seguir uno o más bloques RR. El incluir estos bloques en el mismo paquete SR ahorra ancho de banda al no tener que enviar paquetes RR independientes con su propia cabecera. No obstante, si no existen bloques RR que transmitir, simplemente se pondrá a cero el campo RC de la cabecera y no se añadirá ningún bloque RR.

Informe de receptor. RR

Todos los participantes que reciben información envían como respuesta los correspondientes informes de receptor RR para mantener informado al emisor de la calidad de recepción. Como hemos visto, en el caso de que el receptor sea también un emisor activo, los bloques RR se podrán incluir al final del paquete SR.

Al igual que los paquetes SR, los RR disponen de su cabecera, con el mismo formato que la de los paquetes SR, y de la posibilidad de añadir una extensión de cabecera. En este caso, el campo PT (tipo de paquete) toma el valor 201.

A continuación de la cabecera se incluyen tantos bloques RR como sean necesarios (con un máximo de 31). El formato de estos bloques es el siguiente:

• SSRC_n. Es el identificador SSRC del emisor de la información cuyos datos de evaluación se envían a continuación.
• Fracción de pérdida. Es un campo de 8 bits que indica el porcentaje de paquetes RTP que se han perdido desde el último informe. El valor indica el numerador de una fracción donde el denominador es 256. Por ejemplo, si el valor incluido es 64, esto indicará que se han perdido 64/256 = 25%.
• Total acumulado de paquetes perdidos. Indica el número total de paquetes RTP perdidos desde el comienzo de la sesión.
• Mayor número de secuencia recibido. Se trata del número de secuencia del último paquete RTP que se ha recibido desde ese emisor. Los 16 bits de menor peso contienen el último número de secuencia recibido, mientras que los 16 bits de mayor peso indican simplemente un conteo cíclico.
• Fluctuación de retardo (interarrival jitter). Se trata de una estimación de la variación del retardo entre dos paquetes RTP. La información se ofrece con las mismas unidades que el contador de tiempo RTP.
• Último conteo SR (LSR, Last SR Timestamp). Si SSRC_n es un emisor activo que ha enviado anteriormente un informe de emisor, en este campo se indican los 32 bits centrales de los 64 que se compone el contador de tiempo NTP incluido en el último informe SR recibido de SSRC_n. La utilidad de este campo es informar que se ha recibido bien su último informe SR.
• Retardo desde el último SR (DLSR, Delay Since Last SR). Si SSRC_n es un emisor activo que ha enviado anteriormente un informe de emisor, en este campo se indica el periodo de tiempo entre la recepción del último informe SR y el envío de este informe RR. Este tiempo se indica en unidades de 1/65.536 segundos.

Descripción de la fuente. SDES

Los paquetes SDES facilitan la identificación de los participantes de la sesión mediante el envío del nombre CNAME. No obstante, determinadas aplicaciones requieren intercambiar también otros datos como nombre, correo electrónico o número de teléfono del participante. Los paquetes SDES permiten intercambiar también este tipo de datos.

El formato de los paquetes SDES se compone de una cabecera seguida de tantos bloques de información como sea necesario. La cabecera tiene el mismo formato que la de los campos SR o RR, pero en este caso, el tipo de paquete es el 202 y, en vez de enviarse el campo RC con el número de informes de receptor incluidos, se envía el campo SC (Source Count) indicando el número de bloques de información que se incluyen en este paquete.

Cada bloque de información contiene un valor SSRC o CSRC, seguido por una o más piezas de información. Cada pieza de información se compone de tres campos: tipo de información (8 bits), longitud en octetos del texto de la información (8 bits) y el texto de la información (con el tamaño indicado en el campo anterior, con un máximo de 255 octetos). Por cierto, la estructura de las informaciones SDES se describe en RFC 1889.

Fin de la participación. Bye

El paquete Bye se utiliza para indicar que uno o más participantes dejan de estar activos. Este paquete puede incluir también una cadena de texto con la razón por la que se abandona la sesión.

El formato del paquete Bye se compone de una cabecera, seguida por uno o varios SSRC/CRSC para terminar con un campo de 8 bits que indica la longitud del texto que se incluye a continuación (en octetos) describiendo la razón por la que se abandona la sesión. En la cabecera, el tipo de paquete es el 203 y el campo SC (Source Count) indica el número de SSRC/CRSC incluidos en el paquete.

Funciones específicas de la aplicación. APP

El tipo de paquete APP se utiliza para permitir el desarrollo de nuevas funcionalidades o tipos de paquetes RTP. Los paquetes APP los utilizan libremente las aplicaciones cuando necesitan transmitir alguna información no considerada en ninguno de los tipos de paquetes estándares RTP.

El formato del paquete APP incluye una cabecera, seguida por SSRC/CRSC, el campo nombre (32 bits) y los datos específicos a transmitir. En la cabecera, el tipo de paquete es el 204 y el campo SC o RC se sustituye por el campo subtipo. Tanto el campo nombre como el campo subtipo los definen las aplicaciones para cubrir sus propias necesidades.

Calcular los parámetros de calidad

Los paquetes RTCP contienen la información necesaria para realizar las estimaciones pertinentes de los parámetros de calidad de cada una de las comunicaciones. Los cálculos a realizar y el uso que se le dé a estos resultados dependen de la aplicación concreta de comunicación y del proveedor del servicio. Lo que no cabe duda es que estos resultados pueden utilizarse para tomar decisiones que permitan mejorar la calidad de la comunicación. Por ejemplo, se podría modificar el sistema codec utilizado o su ancho de banda.

Por ejemplo, supongamos que un emisor activo A envía un paquete SR que llega a un receptor B y que éste responde con un paquete RR. El primer paquete incluirá un campo NTP que indica el instante T1 en el que sale de A. Por su lado, el paquete RR incluye el campo DLSR que indica la diferencia de tiempo desde que B recibió el paquete SR (T2) y envió su paquete RR (T3), así como el campo LSR que le sirve a A para relacionar este paquete concreto RR con el paquete concreto SR que él envió.

Cuando el paquete RR llega a A (T4) se puede conocer el retardo de ida y vuelta comprobando los campos anteriores y haciendo el siguiente cálculo:

(T4-T3)+(T2-T1) = T4-(T3-T2)-T1 = T4 – DLSR – NTP

Para calcular la fluctuación de retardo (jitter) se tiene el instante en el que cada paquete RTP sale del remitente y el instante en el que llega al destinatario. Basta con comprobar las desviaciones.

Más información sobre RTCP

En este artículo se ha abordado el funcionamiento del protocolo de control de transporte en tiempo real, RTCP, de una forma resumida. El funcionamiento de internet en general y de la voz sobre IP en particular son ampliamente tratados en este blog en múltiples artículos. Por favor, utilice el buscador de contenidos que tenemos en la cabecera.

Por otro lado, estos son algunos otros artículos que pueden ser de interés:

• VoIP. La telefonía de Internet (Libro web)
• Cómo funcionan los protocolos de Internet
• RTP. Protocolo de transporte en tiempo real

REF: VoIP PG92