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.
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.
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).
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.
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.
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
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.
Conclusiones sobre el protocolo RTP
El Protocolo de Transporte en Tiempo Real (RTP) es un componente fundamental en las comunicaciones de VoIP, desempeñando un papel crucial en la transmisión de audio y video en tiempo real. RTP se encarga de encapsular y transportar los datos multimedia en paquetes de datos individuales y asegura la sincronización entre los flujos de audio y vídeo, lo que es esencial para una experiencia de llamada natural y fluida. Por otro lado, RTP permite marcar los paquetes de datos con información de prioridad y tipo de servicio, lo que permite conseguir una calidad de voz y vídeo óptima.
RTP es un protocolo flexible que se puede adaptar a diferentes tipos de redes, incluyendo redes IP con diferentes niveles de latencia y ancho de banda. Esto permite realizar llamadas VoIP en una amplia gama de entornos de red, desde conexiones de fibra óptica de alta velocidad hasta redes móviles con menor ancho de banda. Asimismo, RTP puede funcionar en conjunto con otros protocolos de VoIP, como SIP (Session Initiation Protocol) y H.323, para establecer y gestionar llamadas de voz y video.
RTP no solo se limita a las comunicaciones VoIP, sino que también sirve como base para otras aplicaciones multimedia en tiempo real, como videoconferencias, juegos en línea o transmisión de video en vivo. Su capacidad para transportar datos multimedia de manera eficiente y sincronizada lo convierte en un protocolo versátil y ampliamente utilizado.
Por último, este protocolo RTP se complementa con RTCP (Protocolo de Control de Transporte en Tiempo Real), que es el responsable de la monitorización y el mantenimiento de la calidad de la llamada en las comunicaciones multimedia sobre internet.
Más información sobre RTP
En este artículo se ha abordado el funcionamiento del protocolo de transporte en tiempo real, RTP, 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
- Cómo funciona la telefonía IP o VoIP
- RTP: A Transport Protocol for Real-Time Applications
REF: VoIP PG83