RTPProtocolo de Transferencia en

Tiempo Real

Hctor Sandoval OrmeoIngeniera 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 RTPAntes 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 RTPLas 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 RTPAudio 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 RTPMezcladores 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 RTPPuede 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 RTPEl 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 RTPUn 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.

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.

ESTRUCTURA DE LA CABECERA DE RTP

SINCRONIZACION EN RTPEl 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.

RTCPEl 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

CONCLUSIONEn 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