RTP Protocolo de transporte en tiempo real

El protocolo RTP (Real-time Transport Protocol), que en español es Protocolo de Transporte en tiempo real surgió con la idea de crear un protocolo específico para la gran demanda de recursos en tiempo real por parte de los usuarios. Algunos de estos recursos son la música, videoconferencia, video, telefonía en Internet y más aplicaciones multimedia

El protocolo RTP se establece en el espacio de usuario y se ejecuta, por lo general, sobre UDP, ya que posee menor retardo que TCP. Por tanto con UDP se gana velocidad a cambio de sacrificar la confiabilidad que TCP ofrece. Debido a ésto, RTP no garantiza la entrega de todos los paquetes, ni la llegada de éstos en el instante adecuado.

La función básica de RTP es multiplexar varios flujos de datos en tiempo real en un solo flujo de paquetes UDP, pudiéndose enviar tanto a un solo destino (unicast) o múltiples destinos (multicast). Los paquetes son numerados de la siguiente manera: se le asigna a cada paquete un número mayor que su antecesor. Esto será útil para que la aplicación conozca si ha fallado algún paquete o no en la transmisión. Si ha fallado, al no tener un control de flujo, de errores, de confirmaciones de recepción ni de solicitud de transmisión, la mejor opción es la interpolación de los datos.

Otra característica muy importante para las aplicaciones de contenido multimedia en tiempo real es el time-stamping (marcación del tiempo). La idea es permitir que el origen asocie una marca de tiempo con la primera muestra de cada paquete. Las marcas de tiempo son relativas al inicio del flujo, por tanto, solo importa las diferencias entre dichas marcas de tiempo. Con este planteamiento, el destino es capaz de almacenar un pequeño buffer e ir reproduciendo cada muestra el número exacto de milisegundos después del inicio del flujo reduciendo los efectos de la fluctuación y sincronizando múltiples flujos entre sí.

RTP sufre vulnerabilidades al igual que otros protocolos. Por ejemplo, un usuario atacante podría autenticar de forma falsa direcciones de red de origen o destino, cambiar el encabezado e incluso cambiar el algoritmo de codificación. Utilizando el protocolo RTP sin su protocolo de control RTCP, los campos CNAME y NAME podría usarse para autenticar a otro usuario. Debido a estas vulnerabilidades entre otras, es importante saber unos cuantos aspectos de seguridad para hacer un uso más responsable del protocolo. RTP es usado actualmente en la telefonía VoIP, llamadas telefónicas a través de Internet. Por tanto, la captura de paquetes RTP es un problema para la integridad de la conversación debido a las vulnerabilidades en seguridad. El tema de vulnerabilidades y agujeros en seguridad está siendo un tema de actualidad debido a los problemas que plantean para los usuarios.

El mínimo contenido funcional de la cabecera de un paquete RTP consta de los siguientes campos, explicados según la RFC propone:

• versión: 2 bits que almacenan el número de versión del protocolo, que va por la segunda, por lo que el valor será siempre 2.

• padding: flag que indica la presencia de relleno al final del paquete. Suele ser común en aplicaciones que necesitan un tamaño fijo de paquete.

• extension: flag que indica que la cabecera se extiende con una cabecera de ampliación.

• contador CSRC: la cabecera RTP puede llevar a continuación una lista de fuentes que contribuyen a la generación del contenido del paquete. Este campo de 4 bits indica cuántas van en la lista anexa, pero sólo lo insertan los mezcladores.

• marker bit: flag cuyo significado depende del contenido que se esté transmitiendo. El propósito general es destacar puntos concretos en la transmisión, como sucede cuando para transmitir un frame se emplean varios paquetes. En este caso el marker bit activado indica que se ha transmitido el último paquete de los que componen el frame.

• tipo de contenido: 7 bits que identifican numéricamente el tipo de contenido que va en el paquete. En este caso, formalmente, es audio MPEG, de sus siglas MPA, que engloba MPEG-1 y MPEG-2. 

• número de secuencia: este campo de 16 bits tiene como función la de indicar el orden de los paquetes en la secuencia, útil para poder ordenarlos y detectar pérdidas. Su valor inicial debe ser aleatorio e impredecible.

• timestamp: 32 bits cuyo valor indica el instante de muestreo del primer octeto del contenido del paquete. El cálculo de este valor depende del tipo de contenido. En el caso de audio MPEG, MPA, la RFC3351 marca que la tasa de reloj sea siempre de 90000 Hz, independientemente de la tasa de muestreo del audio.

• SSRC: identifica con 32 bits la fuente, único para cada fuente distinta en una sesión. Esta aplicación dispone de una sola fuente, por lo que su valor puede ser establecido sin necesidad de tener en cuenta la probabilidad de colisión con los valores de otras fuentes.

Además de esto, enviar audio en formato MP3 requiere una cabecera adicional

específica:

• MBZ: 16 bits que no tienen un uso definido y por tanto, no se van a emplear.
• Fragment Offset: 16 bits que marcan el inicio del frame de audio dentro de los datos del paquete.

 Fuentes:
1. Autor: Gil Cabezas, Jesús ( i62gicaj@uco.es)
2. http://nodejskoans.com