Protocolo de transporte en tiempo real

RTP. Protocolo de transporte en tiempo real

La transmisión de voz y video por internet tiene el inconveniente de necesitar establecer un flujo de datos constantes. No importa mucho si se pierde algún dato, pero el flujo tiene que ser constante. Este hecho supone un gran reto para una red que, como Internet, no fue creada para transmitir en tiempo real. Para poder hacer esto posible ha habido que crear todo un conjunto de protocolos adicionales conocidos como protocolos de transporte en tiempo real o RTP (Real Time Transport Protocol). Profundicemos en el funcionamiento del protocolo de transporte en tiempo real o RTP.

Internet se creó en un principio para transportar datos que no tenía unas necesidades especiales en cuanto a tiempos de entrega. Lo importante era que absolutamente toda la información que se transmite en un extremo llegue al otro sin perder ni un solo bit. Sin embargo, para determinados tipos de información, como la voz o el vídeo, este extremo no es tan importante como el hecho de que la información sea entregada en el destino sin demora y como un flujo constante de datos. Esto es lo que se conoce como transporte de información en tiempo real.

Aunque el término tiempo real se suele usar también para hacer referencia a los sistemas que ofrecen tiempos de respuesta similares a los de la realidad (por ejemplo, un simulador de vuelo en tiempo real), lo fundamental de los protocolos de transporte de datos en tiempo real es que la información se lleve al destino con la misma cadencia de tiempo con la que se introduce en el origen y con un retardo mínimo. Estos protocolos se utilizan, fundamentalmente, para el transporte de las informaciones de audio y vídeo.

Aplicaciones del protocolo de transporte en tiempo real
Aplicaciones del protocolo de transporte en tiempo real

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.

El protocolo de Internet se basa en un modelo de capas. Los protocolos de la capa de transporte (TCP y UDP) son los responsables de identificar la aplicación de origen y destino de la comunicación dentro de cada terminal, trocear el flujo de datos que sale de la aplicación de origen y asegurarse de que los paquetes se reensamblan en el orden correcto antes de entregar los datos a la aplicación de destino.

El protocolo TCP se utiliza cuando es importante que lo que llegue al destino se corresponda exactamente con lo salió del origen (los datos de una transacción bancaria, por ejemplo). Por su parte, UDP es el protocolo utilizado cuando se necesita transmitir datos en tiempo real, aunque sin garantía de exactitud. No obstante, este protocolo presenta algunos inconvenientes cuando la finalidad es la transmisión de voz o video (por ejemplo, puede entregar los datos desordenados). Para corregir estos inconvenientes se han desarrollado unos protocolos complementarios conocidos como RTP o protocolos de transporte en tiempo real.

El protocolo de transporte en tiempo real. RTP

En los años 90, el IETF creó un grupo de trabajo conocido como Audio-Video Transport Working Group (Grupo de trabajo para el transporte de audio y vídeo). Su finalidad era desarrollar un protocolo que permitiera el transporte de datos en tiempo real. En 1996 se publicaría el estándar RFC1889 que define el conjunto de protocolos RTP y RTCP:

  • RTP se encarga de añadirle a los paquetes UDP el número de secuencia, la marca de tiempo y la identificación del tipo de carga útil que transportan.
  • RTCP (RTP Control Protocol, ‘Protocolo de control RTP’) se encarga de informar al remitente de la calidad de recepción y de la identidad de los interlocutores.

Este estándar quedaría actualizado en 2003 por el RFC3550 y complementado con la RFC3551 y RFC3711.

El protocolo RTP opera encima de UDP. Esto quiere decir que cuando UDP recibe los paquetes se los entrega al protocolo RTP, quien resuelve los posibles problemas que pudieran ocasionar la pérdida de paquetes o el cambio de orden de llegada. Para poder hacer esto, RTP le añade cierta información adicional a los paquetes, como son:

  • Un número de orden. Se utiliza para detectar la pérdida o desorden de los paquetes
  • El momento en el que el paquete salió del origen. Resulta útil para calcular parámetros de calidad como el retardo o las fluctuaciones de retardo (jitter)

En realidad, RTP no hace nada para resolver estos problemas, pero los detecta e informa a los protocolos de capas superiores (a la aplicación de VoIP o video) para que puedan tomar las decisiones correspondientes.

Protocolo RTP/RTCP dentro del modelo de capas
Protocolo RTP/RTCP dentro del modelo de capas

El protocolo RTCP se utiliza para el intercambio de información de control (número de paquetes perdidos, retardo, jitter, etc.) entre los distintos participantes de la sesión. Lo veremos más adelante.

En circunstancias normales, el protocolo RTP y RTCP se utilizan conjuntamente, por lo que cuando se asigna un número de puerto a una sesión RTP, también se asigna otro para la sesión RTPCP correspondiente. Generalmente, el número de puerto de la sesión RTP es un número par entre 1.026 y 65.534 (por defecto el 5.004), mientras que el de la sesión RTCP es el número impar correlativo (por defecto el 5.005). No obstante, el uso del protocolo RTCP no es imprescindible para el funcionamiento de la comunicación, por lo que algunas aplicaciones de voz o video le ofrecen al usuario la posibilidad de desactivarlo, aunque esto suponga que no se intercambie información sobre la calidad de la transmisión.

Los protocolos RTP/RTCP pueden ser utilizados tanto para la transmisión de información multimedia unicast (unidifusión) como multicast (multidifusión). Esto quiere decir que pueden utilizarse tanto para transmisiones en las que hay un solo emisor y receptor (unicast), así como para aquellas en las que un mismo emisor transmite simultáneamente para distintos receptores (multicast).

Listado de números de identificación de codecs de RTP
Listado de números de identificación de codecs de RTP

Sistema codec utilizado

Una de las características de RTP es que incluye la identificación del sistema en el que está codificada la información de audio o vídeo que contiene (el sistema codec utilizado en origen). El objetivo es que en el destino se sepa el codec que tienen que emplear para realizar la descodificación.

En un principio, cuando se creó RTP sólo se disponía de un reducido número de codecs, por lo que a cada uno se le asignó un número de identificación de 8 bits (un número entre 0 y 255). No obstante, con el tiempo han ido apareciendo nuevos sistemas de codecs, por lo que 7 bits no parecían ser suficientes para identificarlos a todos ellos.

Para resolver esta situación se ideó el sistema dinámico de asignación de número de codecs. Esto quiere decir que al comienzo de la sesión RTP se acuerda el sistema codec a utilizar y el número de identificación que se le asigna. Por ejemplo, se acuerda que se va a utilizar el codec G729D con el número de tipo 122. Durante el tiempo que dura la sesión, siempre que se haga referencia al número 122 se identificará el sistema G729D. Cuando termina la sesión, el número 122 queda libre para ser utilizado de nuevo.

Los números de codecs del 0 al 95 identifican a sistemas de codificación concretos (conocidos como tipos estáticos), mientras que los números del 96 al 127 se utilizan para las asignaciones dinámicas. El listado de los tipos estáticos está recogido en la RFC1890. Por su parte, para que el sistema de asignación dinámica pueda identificar de forma inequívoca el codec a utilizar, es necesario que exista una lista de nombres de sistemas. Esta lista hace posible que todas las aplicaciones utilicen el mismo nombre para referirse a un codec concreto. Esta lista de nombres de codecs la gestiona el IANA. 

Como las aplicaciones de voz y video no contienen todos los sistemas de codec, es posible que la aplicación del remitente disponga de codecs de los que no dispone la aplicación de destino. El proceso de negociación que incluye el sistema dinámico permite que ambas partes se pongan de acuerdo en el sistema codec a utilizar.

Por cierto, una curiosidad: entre los sistemas dinámicos de carga útil, existe uno conocido como RED (Redundant, ‘Redundante’). Este sistema tiene la particularidad de enviar dos copias de cada muestra de sonido. En el resto de sistemas se envía una sola copia, por lo que, si se pierde un paquete, la aplicación de destino rellena lo mejor posible la falta de las muestras. En el caso de RED, cada paquete contiene sus muestras más una copia de las muestras del paquete precedente. Si se pierde un paquete, la aplicación sólo tiene que buscar las muestras perdidas en el paquete siguiente. Por cierto, las muestras redundantes enviadas pueden estar codificadas con un sistema distinto para ahorrar ancho de banda.

Ejemplos de nombres de codec del sistema dinámico
Ejemplos de nombres de codec del sistema dinámico

Mezcladores y traductores

Lo normal es que una comunicación de voz o video se lleve a cabo entre un remitente y un destinatario que utilizan el mismo sistema codec, no obstante, se puede dar la circunstancia de que el remitente y el destinatario no dispongan de codecs comunes. También puede ocurrir que participe más de un destinatario con codecs distintos. En estos casos, el protocolo RTP considera la posibilidad de que existan aplicaciones intermedias que lleven a cabo las conversiones necesarias. Las opciones actuales son dos:

  • Traductor: se trata de una aplicación que realiza una conversión de sistema de codificación. Si los participantes de la comunicación no utilizan el mismo sistema o el mismo ancho de banda, el traductor se encarga de realizar la adaptación.
  • Mezclador: se trata de una aplicación que recoge distintos flujos de sonido de distintas fuentes y los convierte en un flujo único. Un ejemplo de esto sería una audio o videoconferencia, donde cada participante recibe el sonido o la imagen procedente del resto de participantes.
Ejemplo de traductor y mezclador
Ejemplo de traductor y mezclador

Una misma aplicación podría hacer el trabajo del mezclador y traductor. Por ejemplo, si los participantes de una audioconferencia utilizan sistemas de codec distintos, el mezclador/traductor podría realizar las conversiones necesarias para entregar el sonido a cada participante en su propio sistema.

Identificación de los participantes

Para identificar a los distintos participantes que forman parte de una comunicación se utiliza un número de 32 bits. Este número no está relacionado con la dirección IP del remitente, sino que lo genera cada remitente de forma aleatoria. Se supone que, dado que con 32 bits se pueden dar más de 4.000 millones de combinaciones y que el número de participantes es reducido, la probabilidad de que dos participantes generen el mismo número de identificación es extremadamente baja. No obstante, se cuenta con mecanismos de prevención de coincidencias (colisión) para prevenir estos casos.

El número que identifica a cada fuente se conoce como SSRC (Synchronization Source, ‘Origen de sincronización’). Este dato aparece en la cabecera de los paquetes RTP, no obstante, cuando en una audio o videoconferencia intervienen múltiples participantes con un mezclador intermedio, el campo SSRC identifica al mezclador, identificándose cada participante en una lista de campos que se incluye a continuación y que se conoce con el nombre de lista de contribuyentes o CSRC (Contributing Source, ‘Origen de la contribución’).

Formato de los paquetes RTP
Formato de los paquetes RTP

Formato de los paquetes RTP

Los paquetes RTP se componen de una cabecera de 128 bits y de un cuerpo que contiene la información codificada de la voz o video. El contenido del cuerpo se conoce como carga útil o payload. El tamaño del cuerpo puede ser distinto dependiendo del tipo de carga útil utilizada (del tipo de codec), no obstante, siempre debe ser múltiplo de 32 bits.

Determinados tipos de carga útil necesitan incluir más información de control de la que cabe en la cabecera. Para estos casos existen dos alternativas: esta información puede venir incluida como parte de la carga útil (en los primeros n octetos) o se puede utilizar una extensión de la cabecera que se colocará a continuación de la cabecera normal y antes de la carga útil. El formato de la extensión de la cabecera incluye un campo de 16 bits para indicar la longitud de la misma.

Las informaciones que se incluyen en la cabecera de los paquetes RTP son las siguientes:

  • Versión (V). Se trata de dos bits que indican la versión del protocolo RTP utilizado. La versión más reciente actualmente es la 2.
  • Relleno (Padding, P). Se trata de un bit que indica que la carga útil incluye octetos de relleno al final. El último octeto de relleno indica el número total de octetos de relleno existentes. Como el tamaño de la carga útil debe ser múltiplo de 32 bits, el relleno, de haberlo, tendrá un máximo de 24 bits. El bit de relleno se pone a 1 para indicar que existe un relleno.
  • Extensión (X). Se trata de un bit que indica que la cabecera utiliza el formato extendido.
  • Cuenta CSRC (CC). Utiliza 4 bits para indicar el número de identificadores CSRC que se añaden al final de la cabecera fija. Este campo viene a identificar el número de participantes en la comunicación.
  • Marcador (Marker, M). Se trata de un campo de un bit que la RFC1889 deja para que la carga útil lo utilice libremente y que la RFC1890 utiliza para que las aplicaciones que no envían información en los periodos de silencio fijen este bit a uno en el primer paquete después de un periodo de silencio.
  • Tipo de carga útil (Payload Type, PT). Se trata de un campo de 7 bits que contiene el número que identifica el codec utilizado en la carga útil.
  • Número de secuencia (Sequence Number). Se trata de un campo de 16 bits que utiliza el remitente para identificar el orden secuencial de envío de los paquetes. Este número le permite al destinatario detectar la posible pérdida o desorden de los paquetes. El número de secuencia del primer paquete se genera de forma aleatoria, incrementándose en una unidad para cada uno de los paquetes siguientes.
  • Contador de tiempo (Timestamp). Se trata de un campo de 32 bits que indica el instante en el que se generó la primera muestra de la carga útil. El campo muestra un número entero donde cada unidad es equivalente al periodo de la frecuencia de muestreo utilizada o, lo que es lo mismo, al periodo de tiempo de cada muestra. Por ejemplo, si la frecuencia de muestreo es 8.000 Hz, cada unidad representará el equivalente a 0,125 milisegundos (1/8.000). Por otro lado, si cada paquete contiene 5 muestras de voz y el contador de tiempo incluido en el paquete es 31, el siguiente paquete debería mostrar un contador de tiempo igual a 36. Para una frecuencia de 8.000 Hz, esto sería equivalente a indicar que entre la primera muestra del primer paquete y la primera muestra del segundo paquete ha transcurrido un tiempo de 0,625 milisegundos. El contador de tiempo se utiliza para identificar la fluctuación de retardo (jitter).
  • Identificación del origen (Synchronization Source, SSRC). Se trata de un campo de 32 bits que identifica al remitente o a la aplicación intermedia utilizada (mezclador).
  • Lista de contribuyentes (Contributing Source, CSRC). Cuando se utiliza un mezclador, el campo SSRC identifica al mezclador, utilizándose una lista de campos de 32 bits para identificar a cada una de las fuentes de sonido (o vídeo). El número de fuentes de la lista se especifica en el campo CC. Como el campo CC tiene 4 bits, el máximo número de fuentes que permite RTP es 15.

Intercambio de información. RTCP

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.

Tipos de paquetes RTCP
Tipos de paquetes RTCP

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.
Formato de los paquetes SR
Formato de los paquetes SR

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.

Formato de los paquetes RR
Formato de los paquetes RR

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.
Formato de los paquetes SDES
Formato de los paquetes SDES

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.

Tipos de informaciones incluidas en SDES
Tipos de informaciones incluidas en SDES

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.

Formato de los paquetes Bye
Formato de los paquetes Bye

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.

Formato de los paquetes APP
Formato de los paquetes APP

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

Cálculo del retardo de ida y vuelta
Cálculo del retardo de ida y vuelta

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 el protocolo de transporte en tiempo real

Para comprender bien el funcionamiento del protocolo de transporte en tiempo real le será de utilidad consultar estos otros artículos:

REF: VoIP PG83

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *