RTP/RTCP
Anteriormente (Epígrafe 2.1) se comentó que TCP introduce demasiado retardo por sus
mecanismos de comprobación y retransmisión de paquetes. En el caso de aplicaciones
de voz y vídeo, se requiere de un protocolo que adapte las condiciones de calidad de la
red IP para hacerla más “compatible” con dichas aplicaciones.
Para evitar el retardo innecesario se adopta como protocolo principal de transporte a
UDP, pero como vimos, el mismo no hace nada para evitar la pérdida de paquetes o
siquiera para asegurarse de que los mismos lleguen en el orden adecuado al punto
receptor.
Transporte de información de usuario en tiempo real
Los servicios en tiempo real son sensibles al retraso. La información que transportan
necesita ser entregada a su destino con un tiempo límite de demora, si la demora
introducida por la red es un poco mayor, la información se torna inservible o la calidad de
servicio de la red decae drásticamente.
Una vez que la información es preparada, o sea, que fue hecha la codificación,
compresión y empaquetado, es necesario transportarla sobre la red IP. Es necesario
mover dichos paquetes que contienen información sensible a las demoras, a las pérdidas
y al desorden. Por lo que se requiere de protocolos que garanticen esto.
La IETF ha desarrollado un conjunto de protocolos específicos para servicios multimedia
(Ver siguiente figura), las aplicaciones tendrán que combinar algunos de estos protocolos
para poder brindar estas funcionalidades.
Pila de protocolos para servicios multimedia
En este epígrafe sólo nos referiremos a la parte de transporte de esta pila de protocolos.
El transporte de medios no sólo se encarga de mover los paquetes por la red IP sino que
también adiciona información de control en los paquetes para que cumplan con los
requerimientos para el transporte de información de tiempo real, por ejemplo:
- Caracterización de la carga útil, su identificación, cómo ha sido codificada, su
formato, cuántas tramas por paquete, etc.
- Información de tiempo que posibilite su reconstrucción temporal en el receptor o
los receptores, y la sincronización de diferentes flujos de medios.
- Secuencia de los paquetes que constituyen los flujos de medios, para posibilitar su
reproducción en orden correcto y la detección de paquetes perdidos.
Todo esto posibilita la gestión adecuada de los medios en el receptor
En cierta manera esto supone una forma de “formatear” los paquetes IP y hacerlos aptos
para el transporte de información con requerimientos de tiempo real. Así el protocolo RTP
(Real-Time Transport Protocol) fue concebido para compensar el jitter y la pérdida de
secuencia de los paquetes que introducen las redes IP, pudiendo ser empleado para voz
y vídeo entre dos (unicast) o entre varios (multicast) equipos. A pesar de pertenecer a la
capa de transporte (Arquitectura TCP/IP), no brinda todas las funciones de un protocolo
de transporte; de hecho RTP corre típicamente sobre UDP para utilizar su multiplexado y
servicios de suma de comprobación (checksum).
Igualmente necesario, con funciones de supervisión de la calidad de servicio y otras, está
el protocolo RTCP (RTP Control Protocol), utilizado frecuentemente con RTP.
Por lo tanto, como se muestra en la figura de arriba, para utilizar servicios en tiempo real,
dos protocolos deben ser implementados sobre UDP, el Protocolo de Transporte en
tiempo Real (RTP) para proporcionar el transporte de paquetes de datos en tiempo real y
el Protocolo de Control de RTP (RTCP) para monitorear la QoS que proveen las sesiones
RTP.
RTP trabaja sobre UDP y por lo tanto no hay mucho control de transmisión. Es decir que
el equipo emisor envía la voz hacia el otro extremo con la esperanza de que llegue, pero
no espera recibir confirmación de esto, ni tiene tiempo para hacerlo, pues la voz necesita
ser transmitida en tiempo real. Si un paquete de voz se pierde en el camino, simplemente
se rellenará ese espacio con un silencio, lo que técnicamente se llama ruido confortable
(comfort noise); o repitiendo la anterior trama reproducida.
A pesar de encargarse de casi toda la labor de transportar la voz, RTP no está solo y
tiene un protocolo de apoyo denominado Protocolo de Control de Transporte en Tiempo
Real (RTCP), el cual no es del todo indispensable pero proporciona valiosa ayuda al
momento de transportar la voz de manera óptima, pues proporciona estadísticas e
información de control que le permiten al origen o destino tomar decisiones para mejorar
la transmisión en caso de ser posible. Por lo tanto, los paquetes RTCP se transmiten
periódicamente para comunicar dicha información a los equipos de voz involucrados.
RTP vino a salvar una de las deficiencias existentes en UDP a la hora de transportar
paquetes de voz, la entrega desordenada de paquetes, de ahí que una de las funciones
principales de RTP sea, proveer de un número de secuencia a los paquetes, que permita
a la aplicación receptora determinar el orden y detectar la pérdida de alguna pieza de
información.
Los protocolos RTP y RTCP no ejercen ningún tipo de influencia en las condiciones de la
red IP, no controlan la calidad de servicio, sólo posibilitan que los receptores puedan
“resolver” apropiadamente las “perturbaciones” (jitter, entrega desordenada) a que son
sometidos los paquetes IP con contenidos de tiempo real al atravesar la red.
Los mensajes RTCP son enviados empleando la misma ruta que los paquetes de
RTP. El protocolo de control provee métricas muy útiles sobre los flujos
transmitidos: latencia, variabilidad en la latencia (jitter), pérdida de paquetes, entre
otros. También provee de un identificador estable para la fuente RTP conocido por
CNAME y mantiene el control de los paquetes RTCP intercambiados por las partes en
una sesión con el fin de evitar la congestión por este concepto.
Transporte de medios en VoIP
Protocolo de transporte en tiempo real (RTP)
A nivel de aplicación es importante sincronizar la reproducción de audio de un extremo al
otro, de hecho, es la aplicación en sí la que toma la decisión en cuanto a la mejor manera
de manejar los paquetes, basándose en la información provista por RTP.
Cabecera RTP
Los paquetes RTP están constituidos por dos partes, esto es, una cabecera y un cuerpo.
La cabecera a su vez tiene varios campos que están presentes en todo paquete RTP, y
campos opcionales. La cabecera RTP trasporta información de control relativa al
contenido del cuerpo del paquete, es decir, referente a la información de usuario (audio,
vídeo, etc.), por ejemplo segmentos de conversación de una longitud entre 10 y 30
milisegundos. El formato de esta cabecera es el mostrado en la siguiente figura.
Estructura de la cabecera de un paquete RTP.
El contenido de los campos es el siguiente:
Versión (V): Este campo identifica la versión de RTP utilizada.
Relleno (P, padding): Si este bit está en “1” indica que el paquete contiene uno o
más octetos de relleno adicionales al final, los cuales no son parte de la carga útil. El
último octeto de relleno contiene un total de cuántos octetos de relleno deben ser
ignorados, incluyéndose el mismo. El relleno puede ser necesario por algunos
algoritmos de encriptación con tamaños de bloques fijos o para transportar varios
paquetes RTP en una unidad de dato del protocolo de capa inferior.
Extensión (X): Si este bit es colocado a “1”, al encabezado fijo le sigue una
extensión de cabecera.
Identificadores de fuentes contribuyentes (CSRC, Contributing source
indentifiers): Identifica las fuentes contribuyentes para la carga contenida en el
paquete. Los CSRC son empleados por los mezcladores utilizando los
identificadores SSRC de las fuentes en cuestión.
Conteo CSRC (CC, CSRC Count): Contiene el número de identificadores CSRC
que siguen a la cabecera fija.
Marcador (M, marker): Este bit está colocado para marcar en un flujo de paquetes
determinados eventos relevantes. La interpretación de este campo está definida en
un perfil. Esto permite que eventos significativos como las fronteras de tramas sean
marcadas en el flujo de paquetes.
Tipo de carga (PT, Payload type): Este campo identifica el formato de carga útil
que porta el paquete RTP y su interpretación por la aplicación. En la siguiente tabla
vemos algunos de los valores que toma el campo PT para algunos CODECS de
audio.
Número de secuencia (Sequence number): Se incremente en uno para cada
paquete de datos RTP enviados. Este campo es utilizado por el receptor para
detectar pérdidas de paquetes y restaurar la secuencia de los mismos.
Marca de tiempo (Timestamp): La marca de tiempo refleja el instante de muestreo
del primer octeto de la ventana de información que viaja en el paquete RTP. Este
campo es utilizado por el receptor, para reproducir las muestras con la misma
cadencia con las que fueron obtenidas. Su valor inicial es aleatorio y se utiliza con
propósitos de sincronización y de cálculo del jitter. En audio, el campo “Time Stamp”
se mide en unidades de 125 μs.
Identificador de la fuente de sincronización (SSRC, Synchronization Source
identifier): Identifica a la fuente del flujo de paquetes RTP. Todos los paquetes
enviados por una fuente de sincronización pertenecen al mismo espacio de
temporización y números de secuencia, de forma tal que el receptor pueda
diferenciar distintas fuentes.
Tipos de Carga Útil (PT) en RTP
En la siguiente figura se muestran varios flujos RTP: (a) Una sesión RTP simple con un
transmisor y un receptor. El transmisor se identifica como la fuente de sincronización
(SSRC) del flujo RTP. (b) Flujo RTP múltiple. El transmisor envía el tráfico hacia un host
intermedio, un mezclador. Los flujos son combinados, vueltos a temporizar y enviados al
destino por el mezclador. El mezclador se identifica como la fuente de sincronización del
nuevo flujo RTP, pero los flujos originales se mantienen identificados como fuentes
contribuyentes (CSRC).
Importante:
La cabecera RTP proporciona la información necesaria para
cumplir con las siguientes funciones principales:
Indicación de la secuencia: Mediante esta técnica se
puede detectar la pérdida y el desorden de los
paquetes posibilitando su reordenamiento de ser
necesario.
Sincronismo entre medios: Debido a que paquetes de
un mismo flujo pueden sufrir demoras diferentes, es
necesario llevar información de tiempo para su
sincronización.
Identificación de la carga: Durante una sesión las
condiciones de la red pueden cambiar, y ello obliga a
cambiar el tipo de codificación pues los CODECs
difieren en su capacidad para trabajar en ambientes
distintos.
Identificación de la Trama: Es necesario entregar a los
niveles superiores las tramas en una secuencia
correcta por lo que se debe conocer el inicio y fin de
éstas. Esto se logra si se envía un bit de marca de
trama.
Identificación de la Fuente: Durante una sesión de
multidifusión hay que enviar un identificador único
para cada uno de los usuarios que participan en ésta y
así conocer la procedencia de cada uno de los
paquetes.
Asignación de puertos
Para establecer una sesión RTP, la aplicación define un par particular de direcciones de
destino (una dirección de la red más un par de puertos para RTP y RTCP). En una sesión
multimedia, cada medio se lleva en una sesión separada de RTP, con sus propios
paquetes RTCP que informan la calidad de la recepción para esa sesión. Por ejemplo, el
audio y el video viajarían en sesiones RTP separadas, permitiendo así que un destinatario
seleccione el medio particular que desea recibir.
Con los diversos tipos de esquemas de codificación, los paquetes RTP pueden variar de
tamaño e intervalo. Se deben tener en cuenta los parámetros RTP al planear servicios de
voz. Todos los parámetros combinados de las sesiones de RTP dictan cuánto ancho de
banda es consumido por el tráfico del portador de voz. El tráfico de RTP que lleva el
tráfico de voz es el contribuidor más grande a la carga de la red de VoIP.
Formación de un paquete IP para transporte de Información de usuario
RTCP (Protocolo de control de transporte en tiempo real)
RTCP trabaja mano a mano con RTP. RTP se encarga del envío de los datos, mientras
que RTCP es utilizado para enviar los paquetes de control a los participantes en una
llamada. La función primaria es proveer realimentación de la calidad de servicio provista
por RTP.
Proporciona información útil para lograr la QoS que no se logra con RTP sobre UDP como
latencia, variabilidad en la latencia (jitter), retardo de paquetes, y pérdida de paquetes.
Los paquetes de control RTCP son transmitidos periódicamente por cada participante en
una sesión RTP a los demás participantes. En comunicaciones individuales (unicast) no
es necesario pero es útil. En difusión es imprescindible para conocer cómo reciben los
distintos destinatarios y homogeneizar la calidad. El período de envío de los paquetes
RTCP se adapta al número de fuentes para evitar una avalancha de tráfico de control.
RTCP permite el crecimiento de una sesión desde unos pocos participantes hasta cientos,
de forma automática. No obstante el crecimiento del número de participantes en la sesión,
en aplicaciones de voz, el tráfico de datos permanece aproximadamente constante pues
generalmente no hablan más de dos personas a la vez. Por el contrario, con el
crecimiento del número de participantes, el número de paquetes de control crece de forma
lineal.
El RTCP se utiliza principalmente para detectar situaciones de congestión en la red, y
tomar en su caso, acciones correctoras. Proporciona a los participantes en una sesión
información de la calidad de la transmisión en la red, posibilitando así adaptar las fuentes
al estado de la red. RTCP se basa en la transmisión periódica de paquetes de control a
todos los participantes en la sesión, empleando el mismo mecanismo de distribución que
los paquetes de datos, por lo que debe proveer la multiplexación de paquetes de datos y
paquetes de control RTCP, lo cual hace, mediante el empleo de puertos diferentes del
protocolo UDP a los utilizados por RTP.
RTCP es un protocolo opcional y puede ser deshabilitado a petición del operador, pero es
recomendado mantener las sesiones RTCP para proveer información sobre calidad de
servicio en los puntos terminales de la red.
Tipos de paquetes
Existen cinco tipos de paquetes RTCP, cada uno de ellos posee un formato similar al de
un paquete RTP. Comúnmente estos paquetes son enviados en forma concatenada sin
espaciamiento alguno entre ellos dando lugar a paquetes compuestos que son
manipulados por la capa de transporte como un sólo paquete.
A continuación se muestra una tabla con los distintos tipos de paquetes pertenecientes al
protocolo RTCP, así como su significado:
Tipos de paquetes RTCP
SR: Este reporte es generado por participantes activos, además da información sobre la
calidad de la recepción, sobre la sesión del emisor, sincronización, un contador de
paquetes y número de bytes enviados.
RR: Este reporte es generado por participantes que no están activos. Contienen calidad
de la recepción de los paquetes, incluyendo el número recibido, paquetes perdidos, la
variación del jitter, y datos de tiempo que permite calcular las demoras de la transmisión
SDES: Contiene información de descripción de la fuente.
BYE: Reporta fin de la participación.
APP: Son funciones específicas de las aplicaciones.
Formato de los mensajes SR y RR
En un paquete compuesto, el primero de ellos debe ser un SR ó un RR. El límite, en
cuanto a la cantidad de paquetes, será puesto por los protocolos de las capas inferiores.
Número Tipo de paquete Propósito
En la figura siguiente se observa un ejemplo de paquete compuesto formado por tres
paquetes, uno corresponde con un SR, para que sea válido, el segundo es un SDES, el
cual lleva el CNAME que es imprescindible y por último el paquete BYE. El primer campo
nombrado R es un valor entero de 32 bits que aparece sólo si el paquete se ha
encriptado.
Ejemplo de paquete compuesto RTCP
Unidad de datos del Protocolo de Control de Transporte en tiempo Real.
Seguidamente se presenta un ejemplo de paquete RTCP correspondiente al reporte del
receptor (RR, Receiver Report) enviado por un terminal. Como se puede observar, el
contenido del campo del mensaje muestra parámetros relacionados con la calidad del
servicio como el valor acumulado de paquetes perdidos y el jitter.
1 2 3 4 5 6 7 8 Octetos
V=2 P Reception report count (RC) 1
Packet type (PT)=RR=201 2
3
Length
4
5
6
Synchronization source identifier (SSRC)
7
8
Fraction lost 9
10
cumulative number of packet lost 11
12
13
14
extended highest sequence number received
15
16
17
18
Inter-arrival jitter
19
20
21
22
last SR timestamp (LSR)
23
24
25
26
delay since last SR (DLSR)
27
28
Estructura de un paquete RTCP RR
El significado de los campos del mensaje es el siguiente:
Versión (V): Este campo identifica la versión de RTP utilizada, la cual es la misma
para los paquetes RTCP.
Relleno (P, padding): Si este bit está en 1 indica que el paquete contiene uno o más
octetos de relleno adicionales al final, los cuales no son parte de la carga útil.
Conteo del reporte de recepción (RC, Reception report count): Contiene la
cantidad de bloques de reporte alojados en este paquete.
Tipo de paquete (TP, Packet type): Contiene en este caso la constante 201 que
significa que el paquete RTCP en cuestión es un reporte del receptor.
Longitud: Longitud de este paquete en palabras de 32 bits, menos 1, incluyendo la
cabecera y el relleno.
Identificador de la fuente de sincronización (SSRC, Synchronization source
identifier): Identifica a la fuente de sincronización emisora de este paquete RR.
Pérdida fraccionaria: Este valor es la fracción de los paquetes perdidos desde que
fue enviado el RR anterior. Esta fracción es definida como el número de paquetes
perdidos entre el número de paquetes esperados.
Valor acumulativo de los paquetes perdidos: Este campo contiene la cantidad de
paquetes perdidos desde el comienzo de la recepción.
Número de secuencia máximo extendido: En este campo los 16 bits menos
significativos contienen el número de secuencia máximo recibido de la fuente de
sincronización en un paquete RTP. Los 16 bits más significativos extienden este
número con el correspondiente conteo de ciclos de números de secuencia.
Jitter: Valor estimado de la varianza en el tiempo de llegada entre paquetes RTP,
medidos unidades de marcas de tiempo y expresado como un número entero sin
signo.
Última marca de tiempo del SR (LSR, Last SR timestamp): Contiene los 32 bits
centrales de la marca de tiempo NTP (Network Time Protocol) en el último reporte
del emisor recibido de la fuente de sincronización.
Demora del último reporte del emisor (DLSR, delay since last SR): Es el retardo
expresado en unidades de 1/65536 segundos entre el último paquete SR recibido
desde la fuente de sincronización y el momento de envío de este reporte.
Importante:
RTCP realiza las cuatro funciones siguientes:
1. Proporciona información a la aplicación: La función
primaria es proporcionar información a la aplicación
respecto a la calidad de la distribución de los datos.
Para brindar realimentación acerca de la calidad de
distribución de los datos se relaciona con funciones
de control de flujo y congestión.
2. Identificar la fuente RTP: RTCP lleva un identificador
de nivel de transporte para una fuente RTP
denominado “Nombre Canónico” (CNAME) para
guardar “huellas” de los participantes en una sesión
RTP que son utilizadas por los receptores para asociar
flujos múltiples de un participante en un conjunto de
sesiones RTP. Esto es de gran importancia porque
dentro de la sesión puede ocurrir algún problema que
haga cambiar el SSRC y los receptores requieren del
CNAME para no perder de vista a los participantes.
3. Control del intervalo de transmisión: Para que RTP
pueda aceptar un gran número de participantes en la
sesión, se limita el tráfico de control a un 5% (como
máximo) del tráfico de la sesión global. RTP estipula
que los transmisores activos obtienen un cuarto del
referido porciento ya que alguna de las informaciones
por ellos enviadas (por ejemplo CNAME utilizada para
sincronización) es muy importante para todos los
receptores y los reportes de los transmisores RTCP
resultan ser muy sensibles. La parte restante del
ancho de banda destinada a los paquetes de control
es compartida entre los receptores. Aún para sesiones
pequeñas, las razones más rápidas a las cuales un
participante puede enviar reportes RTCP es de uno
cada cinco segundos. La razón de envío es
aleatorizada por un factor de 0.5 a 1.5 para evitar la
no deseada sincronización entre reportes.
Importante: (Continuación)
4. Llevar información de control de sesión mínima: RTCP
lleva una cantidad de información mínima a todos los
participantes de la sesión. Por ejemplo para mostrar en
pantalla quién está participando en ese momento o
quien entra o sale de la sesión, lo cual es de gran
utilidad cuando el número de participantes varía
constantemente pues entran o salen sin restricción
alguna.
Nota:
Si aún no has realizado el ejercicio -2 del laboratorio #1 este
puede ser un buen momento para hacerlo y comprobar el
funcionamiento de RTP.
