RTP

Protocolo de Transferencia en
Tiempo Real
Hctor Sandoval Ormeo
Ingeniera en Redes y Telecomunicaciones
Universidad Arturo Prat

QUE ES RTP?
El Protocolo de Transferencia en Tiempo Real (Real-time Transfer Protocol)
provee un servicio de entrega extremo-a-extremo de servicios de datos,
tales como audio y video interactivo, con caractersticas en tiempo real.
Inicialmente fue diseado para soportar conferencias multimedia
multiparty. sin embargo es usado por diferentes tipos de aplicaciones.
RTP es un estndar especificado por el RFC 1889, Versiones ms
recientes estn en RFC 3550 y RFC 3551.

QUE SIGNIFICA EN
TIEMPO REAL?
La clase de mtodos cuya exactitud no slo depende de si el resultado
es el correcto, sino tambin en el momento en que el resultado es
entregado.
Para hacer las cosas simples veamos un ejemplo. Digamos que quieres
escuchar una cancin. Cuando la estas descargando de un sitio no te
importa si se descarga a la misma velocidad siempre. Solo necesitas una
descarga confiable y preferentemente rpida. Pero que pasa si deseas
escucharla en linea sin descargarla? En este caso no solo estas interesado
en todo el dato sino tambin en la velocidad en la que lo recibes, de otra
forma la cancin pierde su encanto. Aqui es donde necesitas una
transmisin en tiempo real.
Este ejemplo es solo mencionado para mostrar cuan importante es el factor
tiempo en una transmisin de datos. Transmisiones de Tiempo Real son ms
importantes en conferencias multimedia.

RTP NO GARANTIZA
ENTREGA A TIEMPO
RTP por si mismo no provee
de mecanismos que aseguren
la entrega a tiempo o provean
de otra garanta de calidad de
servicio. RTP depende de
capas de servicio inferior,
como UDP y TCP para esto.
Esta dependencia ser ms
clara cuando revisemos la
estructura de paquete de RTP.

ENTONCES PORQUE SE LLAMA

PROTOCOLO DE TIEMPO REAL?
RTP provee funcionalidades convenientes para transportar
contenido en tiempo real, por ejemplo, marcas de tiempo
(timestamp) y mecanismos de control para sincronizar
diferentes flujos con propiedades de sincronizacin.

COMPONENTES DE RTP
Antes de entrar en los detalles de la estructura de RTP debemos
entender que es bsicamente una combinacin de 2 partes:

Real Time Protocol (RTP): Transporta los datos de tiempo real.

Real Time Control Protocol (RTCP): Monitoriza la calidad del

servicio y transporta informacin sobre los participantes.

Ambos juegan un importante papel en la transmisin. Los datos y

los mensajes de control esta separados en la forma de RTP y RTCP.

APLICACIONES DE RTP
Las aplicaciones en las que RTP juega un papel importante pueden ser clasificadas
como sigue:
Conferencias de Audio de Multidifusin simple.
Inicialmente el propietario de una conferencia , digamos el lder de grupo, a travs de
algunos mecanismos de asignacin obtiene una direccin de grupo de multidifusin y un
par de puertos. Uno de los puertos es usado para los datos de audio y el otro es usado
para el control de paquetes (RTCP). Esta direccin y la informacin del puerto es
distribuida a los participantes previstos. Si se desea privacidad, los datos y el control de
paquetes pueden ser encriptados. En cuyo caso la llave de encriptacin tambin debe
ser generada y distribuida.
Cada participante enva los datos de audio en pequeos trozos, digamos de 20
milisegundos, o paquetes.
Cada instancia de la aplicacin de audio, es decir cada participante en la conferencia,
peridicamente emite un reporte de recepcin ademas del nombre de su usuario por el
puerto de control RTCP. Esto ayuda a monitorizar la calidad de la transmisin y adems
determinar cuales son los participantes.

APLICACIONES DE RTP
Audio y Video Conferencia
Si tanto audio como video son usados en
una conferencia, estos son transmitidos
como sesiones separadas de RTP.
Paquetes RTCP son transmitidos por cada
medio usando dos diferentes pares de
puertos UDP y/o direcciones de
multidifusin. El nombre cannico o
CNAME de los participantes individuales
son usados para coincidir las sesiones de
audio y video.
Las sesiones son divididas para que los
participantes puedan escoger solo una de
ellas si lo desean.

APLICACIONES DE RTP
Mezcladores y Traductores
Hasta ahora, hemos asumido que todos los sitios
quieren recibir los datos de medios en el mismo
formato. Sin embargo esto puede no ser siempre
apropiado. Para usuarios que tienen diferentes
anchos de banda o aquellos que se conectan a
travs de un cortafuegos que no permite paquetes
IP se puede necesitar algo de procesamiento extra.
Este se hace en forma de Mezcladores (Mixers) y
Traductores (Translators).

MEZCLADORES EN RTP
Puede suceder que todos los participantes en una conferencia no tengan el mismo ancho de
banda de conexin. Cmo participan todos simultneamente?
Una solucin es que todos usen un ancho de banda inferior, pero esto conlleva a una reducida
calidad de codificacin de audio.
Existe una solucin ms inteligente en el uso de un retransmisor de nivel RTP llamado
mezclador (mixer). Un mezclador se puede colocar cerca de la zona de bajo ancho de banda.
Este mezclador vuelve a sincronizar los paquetes de audio entrantes para reconstruir los
constantes 20 ms de espaciamiento generado por el remitente, mezcla estos flujos de audio
reconstruidos en un nico flujo, traduce la codificacin de audio a un ancho de banda inferior y
reenva el flujo de paquetes de menor ancho de banda a travs del enlace de baja velocidad.

MEZCLADORES EN RTP
El mezclador pone su propia identificacin como
la fuente (SSRC) del paquete y pone las fuentes
contribuyentes en los campos CSRC.
Los mezcladores tienen otros usos tambin, por
ejemplo agrupar imgenes de video de diferentes
fuentes para generar una nica imagen
compuesta de todas ellas.

TRADUCTORES EN RTP
Un problema ocurre si uno o ms participantes de una conferencia estn detrs
de un cortafuegos el cual no permite un paquete IP conteniendo el mensaje RTP
a pasar. Para esta situacin se utilizan Traductores (Translators).
Dos traductores son instalados, uno en cada lado del cortafuegos, con el de
afuera canalizando todos los paquetes de multidifusin recibidos a travs de
una conexin segura con el traductor dentro del cortafuegos. El traductor dentro
del cortafuegos los enva de nuevo en forma de paquetes de multidifusin a un
grupo de multidifusin restringida dentro del la red interna del sitio.

ESTRUCTURA DE PAQUETE DE RTP

Los datos en tiempo real que estn siendo transferidos

forman la carga RTP. La cabecera RTP contiene
informacin relacionada a la carga, por ejemplo, la fuente,
el tamao, el tipo de codificacin, etc.
Sin embargo el paquete RTP no puede ser transferido por
la red as como as. Para transferirlos usamos un protocolo
llamado UDP (User Datagram Protocol).
Para transferir los paquetes UDP sobre la red IP
necesitamos encapsularlos en un paquete IP.
Incluso para transferir el paquete IP sobre la red fsica
necesitamos enviarlo dentro de otros paquetes

ESTRUCTURA DE LA CABECERA DE RTP

version (V): 2 bits : Este campo identifica la version de RTP. La versin es 2 segn RF 1889.

relleno (P): 1 bit : si el bit de relleno est activado, el paquete contiene uno o ms octetos de relleno adicional al
final que no son parte de la carga. el ltimo octeto del relleno contiene un contador de cuantos octetos de relleno
deben ser ignorados. El relleno puede ser necesario para algunos algoritmos de encriptacin con tamaos de
bloque fijos o para el acarreo de varios paquetes RTP en una unidad de datos de protocolo de capa inferior.

extension (X): 1 bit : si el bit de extensin est activado, la cabecera fija es seguida por exactamente una cabecera
de extension.

recuento CSRC (CC): 4 bits : el conteo CSRC contiene el numero de identificadores CSRC que siguen a la
cabecera fija.

marcador (M): 1 bit : el bit marcador es usado por aplicaciones especificas para sus propios propsitos.

tipo de carga (PT): 7 bits : este campo identifica el formato, por ejemplo la codificacin, de la carga RTP y
determinas interpretacin por la aplicacin. Este campo no est destinado para los medios de multiplexacin
separada.

ESTRUCTURA DE LA CABECERA DE RTP

numero de secuencia: 16 bits : el numero de secuencia se incrementa en uno por cada paquete de
datos enviado, y puede ser usado por el receptor para detectar perdida de paquetes y para restaurar la
secuencia de paquetes. El valor inicial del numero de secuencia es aleatorio, impredecible.

marca de tiempo: 32 bits : la marca de tiempo refleja el instante de muestreo del primer octeto en el
paquete de datos RTP. El instante de muestreo debe ser derivado de un reloj que incremente monotnica
y linealmente en el tiempo para permitir la sincronizacin y los clculos de fluctuacin (jitter).

El campo SSRC identifica la fuente de sincronizacin. Este identificador es elegido aleatoriamente, con la
intencin de que no existan 2 fuentes de sincronizacin dentro de la misma sesin RTP con el mismo
identificador SSRC.

Lista CSRC : de 0 a 15 artculos, 32 bits cada uno : la lista CSRC identifica las fuentes contribuyentes
para la carga contenida en este paquete. El nmero de identificadores es dado por el campo CC. Si hay
ms de 15 fuentes que contribuyen, solo 15 pueden ser identificadas. Los identificadores CSRC son
insertados por los mezcladores, usando los identificadores SSRC de las fuentes que contribuyen.

SINCRONIZACION EN RTP
El receptor necesita tres datos claves para sincronizar, la fuente de sincronizacin, paquetes en orden y un
muestreo de los paquetes que se obtienen de tres campos de la cabecera.
Fuente de Sincronizacin (SSRC)
El receptor puede recibir datos de varias fuentes. As que para un arreglo adecuado necesita identificar la fuente
de paquetes individuales lo que es posible gracias al campo SSRC.
Numero de Secuencia
No es suficiente identificar la fuente, el orden es importante tambin. El nmero de secuencia se incrementa en
uno por cada paquete de datos RTP enviado, y puede ser usado por el receptor para detectar perdida de
paquetes y para restablecer la secuencia de paquetes. La perdida o la entrega fuera de orden se produce por
problemas en la red.
Marca de Tiempo
Para la entrega de medios no solo el orden de los paquetes sino tambin el muestreo de paquetes individuales es
importante.
Varios paquetes RTP consecutivos pueden tener las mismas marcas de tiempo si son , lgicamente, generadas al
mismo tiempo, por ejemplo pertenecen a la misma trama de video. Paquetes RTP consecutivos pueden contener
marcas de tiempo que no son monotnica si los datos no son transmitidos en el orden en que se tomaron las
muestras, como en el caso de tramas de video MPEG interpolada.(La secuencia de nmeros de los paquetes
seguir siendo monotnca). Por lo tanto el numero de secuencia no es suficiente para la sincronizacin. El
receptor empareja los datos de video con su correspondiente audio usando las marcas de tiempo.

MARCO DE NIVEL DE
APLICACION EN RTP
RTP es un marco protocolo que est deliberadamente incompleto. En determinadas estructuras no
es estricto y puede ser modificado para ajustarse a aplicaciones especificas. RTP es
internacionalmente maleable para proveer de funcionalidades adecuadas. Esta caracterstica es
conocida como Marco de Nivel de Aplicacin y es un aspecto importante de RTP.
As que es necesario un documento de especificacin de perfil por cada aplicacin para especificar
la manera en que RTP es usada, por ejemplo, para definir extensiones o modificaciones a RTP que
son especificas a una particular clase de aplicacin. Los participantes de una sesin RTP deben
acordar un formato en comn. Varios campos de la cabecera pueden ser manipulados de acuerdo a
una aplicacin especifica.
El bit de extension puede ser activado para indicar que la cabecera fija es seguida por otra cabecera
de extensin. Campos extra pueden transportar informacin til extra para el uso de la aplicacin.
La interpretacin del bit marcador es definida por un perfil. Est pensado para permitir eventos
significativos tales como cuadros limites a ser marcados en el flujo de paquetes. Un perfil puede
definir bits marcadores adicionales o especificar que no hay bit marcador cambiando el numero de
bits en el campo tipo de carga.
Un perfil puede adems especificar un mapeo esttico por defecto de cdigos de tipo de carga para
formatos de carga.

RTCP
El Protocolo de Control RTP (RTCP) est basado en la transmisin peridica de paquetes de
control a todos los participantes en la sesin, usando el mismo mecanismo de distribucin
de los paquetes de datos.
Funciones de RTCP
Proporciona informacin sobre la calidad de la distribucin de datos. Diferentes tipos de
paquetes son utilizados.
Transporta un identificador de nivel de transporte persistente para una fuente RTP llamada
nombre cannico o CNAME. El SSRC puede cambiar de vez en cuando pero el CNAME
sigue siendo el mismo. Este es usado para identificar a los participantes durante la sesin.
RTCP ademas contiene informacin extra de los participantes como, por ejemplo, el correo
electrnico.
Al tener cada participante que enviar sus paquetes de control a todos los dems, cada uno
puede independientemente observar el numero de participantes. Este nmero es usado
para calcular la velocidad a la cual los paquetes son enviados. Ms usuarios en una sesin
significa que una fuente individual puede enviar paquetes con menos frecuencia.

TIPOS DE PAQUETES RTCP

SR (Sender report): Para estadsticas de

transmisin y recepcin desde los
participantes que son transmisores activos.

RR (Receiver report): Para informes de

estadsticas de recepcin de los
participantes que no son transmisores
activos.

SDES: Objetos de descripcin de fuentes,

incluyendo el CNAME.

BYE: Fin de participacin.

APP: Funciones especficas de aplicaciones

CONCLUSION
En esta presentacin resumida se ha visto un breve esbozo de lo que es
una sesin multimedia, concretamente como la define el protocolo RTP:
Un conjunto de sesiones concurrentes RTP entre un grupo de
participantes, por ejemplo, una videoconferencia (la cual es una sesin
multimedia) puede contener una sesin RTP de audio y otra sesin RTP
de vdeo.
Pero en general una sesin multimedia involucra ms agentes que a un
solo protocolo, medio o rea. Una definicin ms completa sera:
Una sesin multimedia es el conjunto de acciones e informacin
necesaria para que cualquier nmero de participantes puedan
intercambiar entre ellos y de la manera acordada, cualquier tipo de
contenido multimedia de una o ms fuentes de datos.

BIBLIOGRAFIA

http://www.siptutorial.net/RTP/realtime.html

http://www4.ujaen.es/~jccuevas/data/AATTAA2/
Transparencias/Tema%204%20Comunicaciones
%20Multimedia%20.pdf

http://www.wikipedia.org