RtpLib - Una Librería en Java de Los Protocolos RTP y RTCP (2008-2009)

INGENIERA INFORMTICA Curso Acadmico 2008/2009 Proyecto de Fin de Carrera
RtpLib: Una librera en Java de los protocolos RTP y RTCP
Autor: Luis Fernando Garca Antnez Tutor: Luis Lpez Fernndez Cotutor: Micael Gallego Carrillo
II
Agradecimientos
A David, Armando y ngel, por compartir estos inolvidables aos .
Y a mi familia, por apoyarme incondicionalmente.
III
Resumen Actualmente estamos viviendo una etapa de desarrollo creciente de Internet y surgimiento de nuevas tecnologas que proporcionan a los dispositivos mviles capacidad de transmisin de audio y video. Todas estas tecnologas y formas de comunicacin se basan en protocolos de transmisin de datos multimedia que debido su complejidad, es comn que gran parte del esfuerzo en la construccin de aplicaciones software sea la implementacin de dichos protocolos. Uno de los protocolos ms usados para la comunicacin de audio y video en tiempo real es el protocolo RTP, basado en la transmisin de mensajes sobre redes IP. En este proyecto se plantea como objetivo la implementacin de una librera del protocolo RTP que permita, de forma flexible, rpida y eficiente, el desarrollo de aplicaciones basadas en dicho protocolo por parte de los programadores software. Como resultado de todo el proceso de desarrollo se ha obtenido una librera implementada en el lenguaje de programacin Java, que permite usar flujos de video/audio basados en RTP. Adems, esta librera ofrece compatibilidad con determinados dispositivos mviles Nokia e implementacin del protocolo de control RTCP, permitiendo mantenimiento de la conexin. En definitiva una librera fiable, con capacidad de integracin en otros sistemas y facilidad de uso; como prueba de ello, la librera ha sido probada e integrada satisfactoriamente en la empresa Solaiemes, colaboradora de la Universidad Rey Juan Carlos.
IV
Indice
1. INTRODUCCIN................................................................................................10 1.1 Nuevas formas de comunicacin..............................................................12 1.1.1 Un poco de Historia...........................................................................12 1.1.2 Requisitos del transporte de voz y vdeo sobre paquetes en redes....12 1.1.3 Beneficios del vdeo y audio basado en paquetes.............................14 2. OBJETIVOS......................................................................................................15 3. CONTEXTO Y MARCO DE TRABAJO.................................................................17 3.1 Tecnologas de Media...............................................................................17 3.1.1 Conceptos Bsicos.............................................................................18 3.1.2 Transmisin de datos.........................................................................20 3.2 Protocolos de sealizacin.......................................................................21 3.2.1 SDP....................................................................................................21 3.2.2 RTSP..................................................................................................21 3.2.3 SIP.....................................................................................................22 3.3 Servicios...................................................................................................23 3.3.1 PTT....................................................................................................23 3.3.2 Videollamada.....................................................................................23 3.3.3 VoIP...................................................................................................24 3.4 Aplicaciones.............................................................................................24 3.4.1 X-Lite................................................................................................24 3.4.2 Asterisk..............................................................................................25 3.4.3 Reproductor multimedia VLC...........................................................25 3.4.4 Dispositivos mviles usados.............................................................27 3.5 Entorno y Herramientas............................................................................28 3.5.1 Lenguaje de Programacin: Java.......................................................28
3.5.2 Sistema operativo, Ubuntu 7.04........................................................29 3.5.3 Entorno de desarrollo Eclipse:..........................................................29 3.5.4 Wireshark...........................................................................................30 3.5.5 Gestor de versiones SVN..................................................................31 3.6 Infraestructura del sistema........................................................................32 4. EL PROTOCOLO RTP: ESPECIFICACIN...........................................................35 4.1.1 Escenarios de uso..............................................................................36 4.2 La sesin RTP...........................................................................................37 4.2.1 Mezcladores.......................................................................................37 4.2.2 Multiplexando Sesiones RTP............................................................39 4.3 El protocolo de control de RTP: RTCP....................................................39 4.3.1 Reglas de timing................................................................................40 4.3.2 Intervalo de informe..........................................................................40 4.3.3 Paquetes Compuestos........................................................................41 4.4 Aspectos sintcticos del protocolo RTP/RTCP.........................................42 4.4.1 Formato del tiempo...........................................................................43 4.4.2 Formato de los mensajes RTP...........................................................43 4.4.3 Formato de los mensajes RTCP.........................................................46 5. DESCRIPCIN INFORMTICA............................................................................52 5.1 Descripcin de la metodologa empleada.................................................52 5.1.1 El proceso unificado de desarrollo....................................................52 5.2 Planificacin.............................................................................................55 5.2.1 Objetivos parciales necesarios para alcanzar el objetivo final..........55 5.2.2 Descripcin de las etapas que se seguirn en el desarrollo...............55 5.3 Especificacin de requisitos.....................................................................57 5.3.1 Propsito............................................................................................57 5.3.2 mbito del sistema............................................................................57
VI
5.3.3 Interfaces externos.............................................................................57 5.3.4 Requisitos funcionales.......................................................................58 5.3.5 Requisitos no funcionales..................................................................60 5.3.6 Casos de uso......................................................................................61 5.4 Arquitectura y Anlisis.............................................................................62 5.4.1 Diagramas de colaboracin...............................................................63 5.5 Diseo.......................................................................................................66 5.5.1 Decisiones de Diseo........................................................................66 5.5.2 Diagramas de clases de diseo..........................................................69 5.5.3 Implementacin.................................................................................74 5.6 Pruebas.....................................................................................................90 5.6.1 Prueba 1: Aplanamiento y Desaplanamiento.....................................90 5.6.2 Prueba 2: Envo y Recepcin con los Nokia.....................................91 5.6.3 Prueba 3: Uso del buffer....................................................................93 5.7 API y Tutorial de Uso...............................................................................94 5.7.1 Aplanamiento y desaplanamiento......................................................94 5.7.2 Inicio de sesiones...............................................................................96 5.7.3 Buffers...............................................................................................98 5.7.4 Channels..........................................................................................100 6. CONCLUSIONES Y TRABAJOS FUTUROS.........................................................102 6.1 Conclusiones...........................................................................................102 6.2 Conocimientos adquiridos......................................................................102 6.3 Trabajos Futuros:....................................................................................103
APNDICE A.....................................................................................................104
VLC...............................................................................................................104 X-Lite............................................................................................................105
BIBLIOGRAFA...................................................................................................106
VII
ndice de ilustraciones
Ilustracin 1..........................................................................................................................26 Ilustracin 2..........................................................................................................................28 Ilustracin 3..........................................................................................................................32 Ilustracin 4..........................................................................................................................33 Ilustracin 5..........................................................................................................................34 Ilustracin 6..........................................................................................................................39 Ilustracin 7..........................................................................................................................45 Ilustracin 8..........................................................................................................................48 Ilustracin 9..........................................................................................................................50 Ilustracin 10........................................................................................................................51 Ilustracin 11........................................................................................................................52 Ilustracin 12........................................................................................................................52 Ilustracin 13........................................................................................................................63 Ilustracin 14........................................................................................................................64 Ilustracin 15........................................................................................................................65 Ilustracin 16........................................................................................................................66 Ilustracin 17........................................................................................................................71 Ilustracin 18........................................................................................................................71 Ilustracin 19........................................................................................................................73 Ilustracin 20........................................................................................................................74 Ilustracin 21........................................................................................................................79 Ilustracin 22........................................................................................................................81
VIII
Ilustracin 23........................................................................................................................83 Ilustracin 24........................................................................................................................87 Ilustracin 25........................................................................................................................88 Ilustracin 26........................................................................................................................89 Ilustracin 27........................................................................................................................92 Ilustracin 28........................................................................................................................93 Ilustracin 29........................................................................................................................94
IX
CAPTULO 1.
INTRODUCCIN
En el mbito de la programacin, una librera (tambin llamada biblioteca) es una coleccin de subrutinas o clases usadas para desarrollar software. Las libreras contienen cdigo y datos que proveen servicios para programas independientes. Esto permite que el cdigo y los datos sean compartidos y modificados de forma modular. El objetivo de este Proyecto de Fin de Carrera es analizar, disear e implementar una librera para el protocolo RTP/RTCP que permita la utilizacin de aplicaciones y dispositivos que transmitan datos mediante el protocolo de transporte RTP/RTCP. El protocolo RTP (Real Time Transport) es un protocolo de nivel de aplicacin utilizado para la transmisin de informacin en tiempo real como por ejemplo audio y vdeo sobre redes IP -Internet-. Est desarrollado por el grupo de trabajo de transporte de Audio y Vdeo del IETF (Internet Engineering Task Force1). Es frecuentemente usado junto el protocolo de control RTCP (RTP Control Protocol) y se sita sobre el protocolo UDP en el modelo OSI2. El protocolo UDP3 es un protocolo del nivel de transporte basado en el intercambio de datagramas. Permite el envo de datagramas a travs de la red sin que se haya establecido previamente una conexin, a diferencia de TCP4. Tampoco tiene confirmacin, ni control de flujo; por lo que los paquetes pueden adelantarse unos a otros; y tampoco se sabe si estos han llegado correctamente, ya que
1 2 3 4 http://www.ietf.org/ http://es.wikipedia.org/wiki/Capa_de_aplicaci%C3%B3n#Capa_de_aplicaci.C3.B3n_.28Capa_7.29 http://es.wikipedia.org/wiki/UDP http://es.wikipedia.org/wiki/TCP
10
CAPITULO 1: INTRODUCCIN
11
no hay confirmacin de entrega o de recepcin, aunque por otra parte ofrece una latencia muy baja. Para analizar e implementar la librera del protocolo RTP se tendr que estudiar el documento RFC correspondiente. Las RFC (Request For Comments)5son una serie de notas sobre Internet que comenzaron a publicarse en 1969. Cada una de ellas individualmente es un documento cuyo contenido es una propuesta oficial para un nuevo protocolo de la red Internet (originalmente de ARPANET), que se explica con todo detalle para que en caso de ser aceptado pueda ser implementado sin ambigedades. Cualquiera puede enviar una propuesta de RFC a la IETF, pero es sta la que decide finalmente si el documento se convierte en una RFC o no. Si luego resulta lo suficientemente interesante, puede llegar a convertirse en un estndar de Internet. Cada RFC tiene un ttulo y un nmero asignado, que no puede repetirse ni eliminarse aunque el documento se quede obsoleto. Cada protocolo de los que hoy existen en Internet tiene asociado un RFC que lo define, y posiblemente otros RFC adicionales que lo amplan. Existen varias categoras, pudiendo ser informativos (cuando se trata simplemente de valorar por ejemplo la implantacin de un protocolo), propuestas de estndares nuevos, o histricos (cuando quedan obsoletos por versiones ms modernas del protocolo que describen). El protocolo RTP fue publicado por primera vez como estndar en 1996 como la RFC 18896, y actualizado posteriormente en 2003 en la RFC 35507, que constituye el estndar de Internet STD 64. Aunque inicialmente RTP se public como protocolo multicast8 (que es el envo de la informacin en una red a mltiples destinos simultneamente), tambin se ha usado en varias aplicaciones unicast9 (envo de informacin desde un nico emisor a un nico receptor), siendo el objetivo de esta practica una implementacin unicast. La finalidad de esta librera es ayudar a los programadores a poder desarrollar aplicaciones que transmitan datos multimedia, como vdeo o audio a travs de la red; la librera desarrollada ser usada como librera esttica, integrada dentro de LiveServe, aplicacin desarrollada por la empresa Solaiemes utilizada de forma satisfactoria para
5 6 7 8 9 http://www.rfc-editor.org/ http://tools.ietf.org/html/rfc1889 http://tools.ietf.org/html/rfc3550 Envo de la informacin en una red a mltiples destinos simultneamente Envo de informacin desde un nico emisor a un nico receptor
12
la transmisin de datos multimedia en dicha empresa.
1.1 Nuevas formas de comunicacin

Internet est cambiando: lo que antes era contenido esttico ahora se proporciona en forma de flujo de vdeo, los textos estn estn siendo reemplazados por msica y comunicacin hablada, y el audio y vdeo interactivos comienzan a ser las formas de comunicacin predominantes en Internet. Todos estos cambios van a necesitar nuevas aplicaciones que proporcionen estos servicios, y para desarrollar estas aplicaciones se necesitar de programadores con nuevas aptitudes y que sean capaces de desarrollar tales aplicaciones.
1.1.1 Un poco de Historia

Despus de algunos experimentos, el inters por las conferencias de vdeo comenz a cobrar inters en la comunidad Internet a principios de los 90. Adems, al mismo tiempo, la potencia de los procesadores y las capacidades multimedia de las estaciones de trabajo y los PC's comenzaron a ser suficientes para permitir la captura, compresin y reproduccin de audio y vdeo de forma simultnea. En paralelo, el desarrollo del IP multicast permita la transmisin de datos en tiempo real a cualquier numero de receptores conectados a Internet. Como se ha indicado, RTP fue desarrollado por el IETF en el periodo de 1992 a 1996, poca en la que las herramientas de las conferencias multicast usaban como nico protocolo de transporte y control el RTP; como consecuencia, el RTP no slo incluir facilidades para el transporte de media, sino tambin soporte para la gestin de miembros, sincronizacin y calidad de recepcin.
1.1.2 Requisitos del transporte de voz y vdeo sobre paquetes en redes

Cuando nos referimos a media (audio o video) en tiempo real (streaming), en realidad significa que el receptor est reproduciendo el flujo de media tal y como es
13
recibido en lugar de simplemente almacenarlo en un fichero para luego reproducirlo. En el caso ideal, la reproduccin del receptor es inmediata y sncrona, pero en la realidad tenemos retrasos insalvables en la conexin. El primer requerimiento es que el protocolo sea capaz de predecir la variacin de tiempo en el transito de informacin en la red. Por ejemplo, en un sistema de telefona IP se codifica la voz en 20 frames10 por segundo. La fuente transmitir un paquete cada 20 milisegundos, e idealmente el receptor querr recibir los paquetes con el mismo espacio de tiempo para que la conversacin pueda ser reproducida sin problemas. Sin embargo, en el caso no ideal, existen retrasos en la comunicacin, pero dichas variaciones en el tiempo de transito pueden ser absorbidas por un buffer intermedio en el receptor. Otro requerimiento comn en las conexiones de transmisin de datos, que en el caso de RTP se ha sacrificado en favor de la latencia, es la entrega fiable de los paquetes. La fiabilidad es algo muy deseable y la mayora de las aplicaciones son capaces de tolerar ciertas perdidas. En el ejemplo telefnico, perder un paquete sera perder una quincuagsima parte de un segundo, que, con la apropiada ocultacin, no se nota apenas. Dicha cantidad de perdidas aceptables viene determinado por la aplicacin, el mtodo de codificacin y el patrn de perdidas. Estos requerimientos nos conducen a la eleccin del protocolo de transporte. Est bastante claro que TCP/IP no es aceptable debido a que favorece a la fiabilidad sobre la latencia, y nuestras aplicaciones requieren entrega de paquetes lo antes posible. Un protocolo UDP/IP parece apropiado, ya que los ratios de perdidas son aceptables y proporciona la menor latencia posible. As pues, el estndar RTP se construye sobre UDP/IP; adems provee de recuperacin de paquetes y deteccin de perdidas, para permitir el desarrollo de sistemas robustos gracias al protocolo de control RTCP. A pesar de las limitaciones de TCP para las comunicaciones en tiempo real, algunas comunicaciones lo usan para su transporte, tratando de estimar la tasa de transferencia de la conexin TCP y adaptar el ratio de envo. Esta aproximacin puede ser realizada cuando no se requiere el retardo entre los extremos y la aplicacin tiene muchos segundos de buffer para controlar la
10 Una frame es una imagen independiente que forma parte de una animacin. Aunque la traduccin en castellano significa literalmente fotograma, tambin puede aplicarse al sonido.
14
variacin del tiempo de entrega causado por la transmisin TCP y el control de congestin. Esto no es aceptable para aplicaciones interactivas, que necesitan un retardo bajo entre extremos, porque la variacin de tiempo en transito causada por TCP es demasiado alta.
1.1.3 Beneficios del vdeo y audio basado en paquetes

Aunque en una red de paquetes tenemos la desventaja de que se plantean retos para permitir la entrega fiable de flujos de media, una red IP tambin tiene diferentes ventajas a destacar. La primera es que usando IP como un portador de servicio para audio y vdeo en tiempo real se puede proveer de una red convergente y unificada. La misma red puede ser usada para voz, msica, vdeo, correo electrnico, acceso web, transferencias de ficheros, juegos...El resultado puede ser muy significativo ahorrando en infraestructuras, desarrollo, soporte y costes de mantenimiento. Un paquete de red unificado permite un multiplexado de la red. Por ejemplo, la deteccin de transmisin de voz puede ser usada para crear paquetes de silencio durante los periodos en los que el interlocutor no hable. Otro importante beneficio es la utilizacin de IP multicast, que permite entrega de datos a un potencial numero de receptores enorme. Por ultimo, y quiz es la mas convincente razn, es que IP puede ofrecer nuevos servicios. Esta convergencia permite una gran interaccin entre vdeo y audio en tiempo real y otras aplicaciones, permitiendo desarrollar sistemas que no habran sido posibles con un sistema no basado en paquetes.
CAPTULO 2.
OBJETIVOS
Este Proyecto de Fin de Carrera constituye la finalizacin a los estudios de segundo ciclo de la Ingeniera Superior Informtica, y como tal el objetivo principal es enfrentar al alumno al desarrollo completo de un sistema informtico. Para ello, se desarrollar el proyecto prestando especial atencin al anlisis, diseo e implementacin, adems de desarrollar un conjunto de pruebas y una evaluacin objetiva de los resultados obtenidos. Acerca del sistema, se desea desarrollar una librera para el protocolo de comunicaciones RTP/RTCP en el lenguaje de programacin Java. Dicho protocolo de comunicacin usa paquetes para enviar y recibir datos y mantener estadsticas de control, por lo que la librera proporcionar herramientas para usar de forma sencilla, eficiente y correcta los paquetes del protocolo; por lo tanto, por una parte se deber implementar una serie de clases en el lenguaje de programacin Java que permitan que el programador que use la librera pueda manejar los paquetes de forma cmoda y sencilla en forma de objetos Java; y por otra parte, la librera tambin debe estar diseada para manejar con igual facilidad los conjuntos de bytes que se reciben para convertirlos en objetos Java (y viceversa, objetos Java en bytes que se puedan enviar por la red). En definitiva, la implementacin de aplanadores y desaplanadores, tendiendo en cuenta que las definiciones de aplanamiento y desaplanamiento son11:
Definicin de aplanamiento: proceso por el cual una estructura de datos se
11 Apuntes RedesII: Luis Lpez Fernndez
15
CAPTULO 2. OBJETIVOS
16
transforma en una secuencia de bits siguiendo un conjunto de reglas de codificacin predefinido.
Definicin de desaplanamiento: proceso por el cual una secuencia de bits se transforma en una estructura de datos siguiendo un conjunto de reglas de decodificacin predefinido.
Otro objetivo de este proyecto ser la implementacin de funcionalidades que permitan recibir y enviar paquetes RTP desde/hasta diferentes nodos de una red. Estas funcionalidades debern ser implementadas de forma modular, por lo que recibir o enviar paquetes RTP no dependern el uno del otro, esto adems de mejorar la flexibilidad de la librera tambin permite el fcil desarrollo nuevos mdulos. Adems, la librera debe ser capaz de enviar y recibir paquetes, tambin deber encargarse de la gestin del protocolo de control de RTP (RTCP). La librera deber almacenar estadsticas y calcular datos importantes para mantener la conexin RTP, por lo tanto, se implementarn tambin mdulos de envo y recepcin de paquetes RTCP, manteniendo coherentes los datos que se enven en ellos. Debido a que existen diferentes peculiaridades con algunos dispositivos mviles con los que se probar la librera, para realizar las pruebas de forma correcta, se estudiarn dichas peculiaridades y se proceder a adaptar la librera para el correcto funcionamiento de esta. Por ultimo, en este Proyecto de Fin de Carrera se define e implementa un buffer, que permitir que se puedan almacenar los paquetes recibidos; los diferentes objetivos que tiene este buffer son:
Absorber retrasos, cuando un flujo (de vdeo o de audio) llega con retraso respecto a otro y se deben sincronizar antes de ser reenviados al receptor final. Simular retrasos, si el flujo de datos debe comenzar con un cierto retraso para sincronizarlo a otros flujos de datos. Correcto funcionamiento ante cortes de media, cuando el flujo de vdeo cesa de enviar paquetes RTP, la librera debe ser capaz de mantener el envo de paquetes de forma trasparente al destinatario. Recuperacin cuando se restablezca la conexin, si la conexin vuelve a establecerse, la librera de nuevo debe realizar el proceso de forma correcta. Compatibilidad con diferentes dispositivos mviles y el reproductor VLC.
CAPTULO 3.
CONTEXTO Y MARCO DE TRABAJO

3.1 Tecnologas de Media
En el presente documento se habla de archivos y contenido multimedia, y si bien las nociones bsicas de este concepto son ampliamente conocidas, llegado este punto conviene definir ms formalmente algunas de sus caractersticas. Un contenido multimedia es aquel que est compuesto de diversos medios, como pueden ser audio, vdeo, texto, etc. Se dice que un contenido multimedia est basado en el tiempo en tanto que cada uno de sus medios cambia significativamente con l. Esta caracterstica hace que un contenido multimedia requiera ser proporcionado y procesado en unas condiciones temporales estrictas. Por ejemplo cuando se reproduce un vdeo, si los datos multimedia no pueden ser proporcionados lo suficientemente rpido pueden producirse pausas y retrasos en la reproduccin; por otro lado si los datos no pueden ser recibidos y procesados lo suficientemente rpido el vdeo se reproduce a saltos ya que se desechan cuadros como mecanismo para mantener la tasa de reproduccin. A continuacin se enumeran los principales elementos que componen el contenido multimedia, conviene que el lector se familiarice con ellos porque sern usados a lo largo de todo el documento.
17
CAPTULO 3. CONTEXTO Y MARCO DE TRABAJO
18
3.1.1 Conceptos Bsicos
Pista (track): Cada uno de los medios de los que se compone un contenido multimedia. Por ejemplo un contenido multimedia correspondiente a una videoconferencia puede contener una pista de audio y otra de vdeo. Se dice que las pistas que componen un contenido multimedia estn multiplexadas. Al proceso de extraccin de las distintas pistas que componen un contenido multimedia se le denomina demultiplexacin. Cdec12: Cdec es una abreviatura de Compresor-Decompresor. Describe una especificacin desarrollada en software, hardware o una combinacin de ambos, capaz de transformar un archivo con un flujo de datos (stream) o una seal. Los cdecs pueden codificar el flujo o la seal (a menudo para la transmisin, el almacenaje o el cifrado) y recuperarlo o descifrarlo del mismo modo para la reproduccin o la manipulacin en un formato ms apropiado para estas operaciones. Los cdecs son usados a menudo en videoconferencias y emisiones de medios de comunicacin. La mayor parte de cdecs provoca prdidas de informacin para conseguir un tamao lo ms pequeo posible del archivo destino. Hay tambin cdecs sin prdidas (lossless), pero en la mayor parte de aplicaciones prcticas, para un aumento casi imperceptible de la calidad no merece la pena un aumento considerable del tamao de los datos. La excepcin es si los datos sufrirn otros tratamientos en el futuro. En este caso, una codificacin repetida con prdidas a la larga daara demasiado la calidad. Muchos archivos multimedia contienen tanto datos de audio como de vdeo, y a menudo alguna referencia que permite la sincronizacin del audio y el vdeo. Cada uno de estos tres flujos de datos puede ser manejado con programas, procesos, o hardware diferentes; pero para que estos streams(flujos) sean tiles para almacenarlos o transmitirlos, deben ser encapsulados juntos. Esta funcin es realizada por un formato de archivo de vdeo (contenedor), como .mpg,.avi,.mov,.mp4,.rm,.ogg,.mkv o.tta. Algunos de estos formatos estn limitados a contener streams que se reducen a un pequeo
12 http://es.wikipedia.org/wiki/C%C3%B3dec
19
juego de cdecs, mientras otros son usados para objetivos ms generales. Los distintos codecs se distinguen en funcin de: 1. La calidad que proporcionan. 2. Su exigencia de recursos de CPU para ser procesados 3. La cantidad de ancho de banda requerida para su transmisin. Cada cdec est destinado a diferentes tipos de aplicaciones y servicios. Cdecs como MPEG 1 son de gran calidad pero altos requerimientos de ancho de banda estn destinados usualmente a aplicaciones que trabajan con almacenamiento local o en dispositivos pticos como CD-ROM o DVD donde el ancho de banda y la capacidad de almacenamiento no son limitantes. En cambio otros formatos como H.26113 y H.26314, usados en este proyecto para la transmisin de datos, se usan para aplicaciones de videoconferencia donde el ancho de banda es un bien escaso; de la misma forma G.723 se usa para producir voz codificada con tasa de bits reducida para aplicaciones de telefona IP, por ejemplo.
Contenedor (container o content-type): es la estructura en que los datos son enviados o almacenados, en el segundo caso irn asociados a una extensin de archivo. Cada tipo de contenedor puede llevar dentro pistas en diferentes formatos, y ser manejado por unas u otras herramientas. Algunos ejemplos de contenedores habituales son AVI, MP3, WAV, MPG o 3GP, entre otros; en nuestro caso, FLV15 ser el que ms usemos en las pruebas. Transcodificacin (transcoding): es el proceso consistente en cambiar el formato de una pista. Para conseguirlo se usan los cdecs (codificadoresdecodificadores), que son programas que incorporan algoritmos capaces de hacerlo. Cada tipo de cdec puede manejar ciertos formatos de entrada y salida.
13 http://en.wikipedia.org/wiki/H.261 14 http://en.wikipedia.org/wiki/H.263 15 http://es.wikipedia.org/wiki/Flash_Video
20
3.1.2 Transmisin de datos
3.1.2.1
RTMP
Es un protocolo propietario desarrollado por Adobe Systems para el streaming de vdeo y audio por Internet entre un reproductor de Flash y un servidor. A diferencia de RTP, est basado en el protocolo de transporte TCP, lo que permite mantener una nica comunicacin persistente en tiempo real. Adems, encapsulado junto con HTTP permite atravesar los Firewalls16 y el NAT17, a diferencia de RTP, que no lo permite.
3.1.2.2
RTP
Aunque RTP tiene algunas caractersticas de protocolo de nivel de transporte (segn el modelo OSI), es transportado, a diferencia de RTMP, usando UDP. El protocolo UDP no maneja sesiones ni mecanismos que garanticen la recepcin de los paquetes, pero es usado por UDP en lugar de TCP debido a que reduce el tiempo de envo de los paquetes a travs de la red. En aplicaciones de voz y video es ms importante una transmisin rpida que la prdida de algunos paquetes durante el recorrido.
3.1.2.3
Descarga Continua
La descarga continua es un tipo de transmisin que utilizan la mayora de sitios web de comparticin de video (por ejemplo Youtube). Este se basa en la descarga del media (audio y video) de forma continua antes de comenzar su reproduccin. De esta forma, cuando se ha descargado el suficiente media como para reproducir de forma suave y sin cortes la reproduccin comienza la visualizacin del media; y al mismo tiempo se continua descargando el resto del media. Esta forma difiere del RTP o RTMP en que no es una reproduccin en tiempo real, por lo que no es una forma de video recomendada en la transmisin de eventos en directo o en la comunicacin en tiempo real.
16 http://es.wikipedia.org/wiki/Cortafuegos_(inform%C3%A1tica) 17 http://es.wikipedia.org/wiki/Network_Address_Translation
21
3.2 Protocolos de sealizacin

3.2.1 SDP
El Session Description Protocol18 (SDP), es un protocolo para describir los
parmetros de inicializacin de los flujos multimedia. Fue publicado por el IETF en la RFC 232719. Es un protocolo textual, y se puede usar en conjuncin con RTSP o SIP para informar al cliente de las caractersticas del flujo de streaming que se va a enviar, tanto en lo referente al contenido como a la manera en que se va a transmitir. Ms concretamente, un SDP consiste en una cadena de texto donde se informa de las pistas disponibles, en qu formato se encuentran, y otros parmetros relacionados con el contenido, como por ejemplo la duracin. Con esta informacin los clientes como por ejemplo aplicaciones de reproduccin de vdeo/audio como VLC o dispositivos mviles, tendrn constancia de las pistas disponibles y qu formato, pudiendo seleccionar las que deseen y elegir los cdecs adecuados para que la reproduccin sea correcta. Si el reproductor no dispone de ellos, debera desistir. El protocolo SDP ser usado en este proyecto al configurar el reproductor VLC y en la negociacin que se establezca con los dispositivos mviles. En el apndice se muestra un ejemplo de fichero SDP para la configuracin de la aplicacin VLC.
3.2.2 RTSP
RTSP es un protocolo no orientado a conexin, en lugar de esto el servidor mantiene una sesin asociada a un identificador. En la mayora de los casos RTSP usa TCP para datos de control del reproductor y UDP para los datos de audio y vdeo aunque tambin puede usar TCP en caso de que sea necesario. En el transcurso de una sesin RTSP, un cliente puede abrir y cerrar varas conexiones de transporte hacia el servidor por tal de satisfacer las necesidades del protocolo. De forma intencionada, el
18 http://tools.ietf.org/html/rfc4566 19 http://www.ietf.org/rfc/rfc2327.txt
22
protocolo es similar en sintaxis y operacin a HTTP de forma que los mecanismos de expansin aadidos a HTTP pueden, en muchos casos, aadirse a RTSP. En este proyecto RTSP no ser utilizado. Habitualmente el media negociado es RTP.
3.2.3 SIP
Dentro del campo de los protocolos para el control de streaming, uno de los que ms se puede comparar con RTSP es SIP. El objetivo del Session Initiation Protocol20 es la iniciacin, modificacin y finalizacin de sesiones interactivas de usuario donde intervienen elementos multimedia como el vdeo, voz, mensajera instantnea, juegos online y realidad virtual. Es por tanto un protocolo de control cuya funcionalidad es similar a RTSP, y adems tambin se parece a este que est basado en texto plano y es similar a HTTP. Es un protocolo desarrollado por el IETF, y en noviembre del ao 2000 fue aceptado como el protocolo de sealizacin de 3GPP5 y elemento permanente de la arquitectura IMS6. SIP es adems uno de los protocolos de sealizacin para voz sobre IP. SIP funciona en colaboracin con otros muchos protocolos pero slo interviene en la parte de negociacin al establecer, modificar y finalizar la sesin de comunicacin. En un uso normal, las sesiones SIP se apoyan en el protocolo RTP, que es el verdadero portador para los contenidos de audio y vdeo. La negociacin SIP se usa a menudo en conjuncin el protocolo SDP para describir el media que se procede a enviar y el media con el que es compatible para recibir. En este proyecto ser usado para establecer la conexin y el inicio de sesin entre los dispositivos mviles y la librera RtpLib. Para conseguir esta funcionalidad se ha utilizado de la librera JSIP, propiedad de la empresa Solaiemes.
20 http://tools.ietf.org/html/rfc3261
23
3.3 Servicios
3.3.1 PTT
El PTT21 (Push to Talk), se podra traducir como pulsar para hablar, comnmente abreviado como PTT o PPH, es un mtodo para hablar en lneas half-duplex de comunicacin, apretando un botn para transmitir y liberndolo para recibir. Este tipo de comunicacin permite llamadas de tipo uno-a-uno o bien uno-a-varios (llamadas de grupos). El PTT es una caracterstica que est disponible en casi todos los equipos de radio, ya sean porttiles o mviles, adems en ciertos modelos de telfono mvil.
PoC (Push over Cellular)22: es una evolucin del servicio PTT, que consiste en incorporar el PTT en los sistemas mviles celulares, permitiendo que sus usuarios de telfonos mviles puedan tomar parte en una comunicacin inmediata con uno o ms suscritos a PoC como si se tratase de un walkie-talkie. Los protocolos que se utilizan para establecer las sesiones PoC son el SIP y el SDP, y para la transmisin y gestin del video y audio se utiliza el RTP/RTCP.
3.3.2 Videollamada
Tambin llamada videoconferencia, es la comunicacin simultnea y bidireccional de audio y vdeo, permitiendo mantener reuniones con grupos de personas situadas en lugares alejados entre s. Adicionalmente, pueden ofrecerse facilidades telemticas o de otro tipo como el intercambio de informaciones grficas, imgenes fijas, transmisin de ficheros desde el ordenador, etc. El ncleo tecnolgico usado en un sistema de videoconferencia es la compresin digital de los flujos de audio y vdeo en tiempo real. Su implementacin proporciona importantes beneficios, como el trabajo colaborativo entre personas geogrficamente distantes y una mayor integracin entre grupos de trabajo. Para la transmisin y gestin del audio y video se usa el protocolo
21 http://es.wikipedia.org/wiki/Push_to_talk 22 http://en.wikipedia.org/wiki/Push_to_Talk_over_Cellular
24
RTP/RTCP.
3.3.3 VoIP
Voz sobre Protocolo de Internet, tambin llamado Voz sobre IP, VozIP, VoIP 23 (por sus siglas en ingls), es un grupo de recursos que hacen posible que la seal de voz viaje a travs de Internet empleando un protocolo IP (Internet Protocol). Esto significa que se enva la seal de voz en forma digital en paquetes en lugar de enviarla (en forma digital o analgica) a travs de circuitos utilizables slo para telefona como una compaa telefnica convencional o PSTN24 (acrnimo de Public Switched Telephone Network, Red Telefnica Pblica Conmutada). VoIP consigue calidad de servicio priorizando los paquetes de menor latencia y utilizando compresin de cabeceras aplicando los estndares RTP/RTCP.
3.4 Aplicaciones
3.4.1 X-Lite
Es un telfono software gratuito que se usa para el protocolo de iniciacin de sesiones (SIP). X-Lite ha sido desarrollado por CounterPath. Es fcil de usar gracias a su interfaz grfica como se puede ver en la ilustracin 1. La aplicacin X-Lite ser usada en el proyecto para el estudio del protocolo RTP en combinacin con el analizador de redes Wireshark. Mas adelante se describir la infraestructura diseada para realizar dicho cometido siendo el objetivo ser capaces de recibir datos en formato RTP y comprobar el funcionamiento del protocolo RTP. La configuracin de la aplicacin se describir ms adelante en el apndice.
23 http://es.wikipedia.org/wiki/VoIP 24 http://en.wikipedia.org/wiki/Public_switched_telephone_network
25
Ilustracin 1: Imagen de la aplicacin X-Lite
3.4.2 Asterisk
Asterisk25 es una aplicacin de software libre (bajo licencia GPL) que proporciona funcionalidades de una central telefnica (PBX26). Como cualquier PBX, se puede conectar un nmero determinado de telfonos para hacer llamadas entre s e incluso conectar a un proveedor de VoIP o bien a una RDSI tanto bsicos como primarios. Quiz lo ms interesante de Asterisk es que soporta muchos protocolos VoIP como pueden ser SIP. Asterisk puede interoperar con terminales IP actuando como un registrador y como gateway entre ambos, es decir, reenviando los paquetes que le llegan de cada lado de la conexin a los otros terminales.
3.4.3 Reproductor multimedia VLC

VLC Media Player (inicialmente VideoLan Client, VLC a partir de ahora) es un reproductor y servidor multimedia, distribuido como software libre. Soporta muchos formatos de audio y vdeo, y tambin los formatos de DVD y VCD8. Adems puede funcionar como servidor de streaming, usando varios de los protocolos existentes en la actualidad.
25 http://www.asterisk.org/ 26 http://es.wikipedia.org/wiki/PBX
26
Siempre que se habla de software libre merece la pena hacer al menos un breve repaso de la historia y evolucin del producto. Inicialmente el objetivo del proyecto VLC era crear un servidor capaz de enviar un flujo de streaming a travs de la red. Fue inicialmente desarrollado por estudiantes de la cole Centrale Paris, y liberado bajo licencia GPL9 el 1 de febrero de 2001. Debido a su xito y popularizacin, actualmente desarrolladores de todo el mundo contribuyen a su evolucin. En las primeras etapas el proyecto constaba de dos mdulos bien diferenciados, un reproductor multimedia (VideoLan Client) y un servidor de streaming (VideoLan Server). Finalmente el segundo ha quedado obsoleto y toda la funcionalidad se ha unido en un solo producto, con la denominacin VLC Media Player. Sus principales caractersticas son:
Diseo muy modular: adems del uso de los mdulos existentes facilita la incorporacin de nuevos mdulos para soportar ms tipos de formatos, cdecs o mtodos de streaming. Ofrece la posibilidad de elegir mltiples opciones para la interfaz, as como entradas y salidas de audio y vdeo, filtros para conseguir varios efectos, etc. Actualmente hay disponibles ms de trescientos mdulos para VLC. Disponible para mltiples plataformas: contando con versiones para Windows, Linux, Mac OS X, BeOS, BSD, Pocket PC y Solaris. Incluso existe una versin porttil que puede ser almacenada y usada directamente desde una memoria USB sin necesidad de instalacin alguna. Utiliza la biblioteca libre libavcdec del proyecto FFmpeg10 para manejar los muchos formatos que soporta, y emplea la biblioteca de descifrado DVD libdvdcss para poder reproducir los DVDs cifrados. Adems soporta otros cdecs no incluidos en el proyecto FFmpeg. Dispone de plugins para la Web: en Windows, Linux, y algunas otras plataformas, VLC incluye un plugin Mozilla, que permite ver algunos archivos QuickTime y Windows Media en las pginas Web sin tener que utilizar un reproductor de Microsoft o Apple. Desde la versin 0.8.2 en adelante, VLC incorpora un plugin ActiveX, que permite ver algunos archivos QuickTime y Windows Media en las propias webs, cuando se navega con Internet Explorer.
27
Robustez: VLC es especialmente popular por su robustez, ya que es capaz de reproducir archivos incompletos o daados antes de que se hayan descargado completamente, por ejemplo a travs de programas de intercambio habituales como Emule o BitTorrent. Esto es debido a que es un reproductor basado en paquetes. Capaz de acceder a archivos de imagen .iso y reproducir los archivos multimedia contenidos en su interior, incluso si el sistema operativo no es capaz de trabajar directamente con archivos .iso. Dispone de filtros: usando filtros se pueden obtener multitud de efectos, como distorsionar la imagen, separarla en fragmentos, rotarla, aadir logos, etc. Tiene otras funcionalidades peculiares que le pueden hacer atractivo para muchos usuarios, como por ejemplo reproducir vdeo como si fuera el fondo de pantalla, reproduccin en directo usando una conexin FireWire, etc. De cara a este proyecto, las capacidades ms relevantes que nos pueda ofrecer
VLC son las relacionadas con la recepcin de flujos RTP para comprobar durante el proceso de pruebas la correcta visualizacin. En cuanto a lo segundo, VLC ofrece la posibilidad del manejo a travs de lnea de comandos como alternativa a la interfaz grfica, incluyendo el uso de dicho mdulo. Esto es fundamental, puesto que si slo se ofreciera la interfaz grfica no sera posible el uso de VLC desde una aplicacin en Java. VLC ofrece una multitud de opciones y parmetros para ejecutarlo a travs de una terminal, usando sus capacidades tanto de reproduccin como de servicio streaming.
Ilustracin 2: Logotipo de la aplicacin VLC
3.4.4 Dispositivos mviles usados
28
Nokia N73: Smatphone, tiene en comn son otros Nseries y Eseries, sin soporte de Wi-Fi, capacidad 3G. Nokia 6110 Navigator: Caractersticas similares a Nokia N73. Ambos dispositivos mviles son capaces de establecer videoconferencias usando protocolos como RTP/RTCP, SDP y SIP, adems de ser compatibles con la reproduccin de videos codificados por los cdecs H.261 y H.263. Cabe destacar, que tras estudiar las trazas mediante el analizador de redes Wireshark, ambos dispositivos mviles necesitan la recepcin de paquetes RTP vacos para mantener la conexin RTP. Este flujo de vuelta de paquetes RTP no est en la RFC y no forma parte de la especificacin. A dichos paquetes los llamaremos paquetes dummies, y sern descritos con mayor profundidad ms adelante.
3.5 Entorno y Herramientas

3.5.1 Lenguaje de Programacin: Java
El lenguaje de programacin elegido ha sido Java, al ser considerado la mejor opcin para este proyecto. Java es un lenguaje multiplataforma, cuyos programas se pueden ejecutar en cualquier sistema operativo que tenga instalada la mquina virtual de Java. Tiene ciertas caractersticas que le hacen ser adecuado para el problema que se pretende resolver:
Simplicidad y alto nivel: es un lenguaje ms sencillo que otras opciones como C++, y libera al programador de preocuparse de ciertas tareas de bajo nivel, como por ejemplo el uso de la memoria y el manejo de punteros. Orientacin a objetos: Java es un programa orientado a objetos, en el que la unidad principal de programacin es la clase. Esta caracterstica ser til para, tal y como se pretende, implementar una librera de carcter modular y aprovechando las ventajas que nos ofrece la programacin orientada a objetos, como el polimorfismo, la herencia y la encapsulacin. Adems la orientacin a objetos tambin facilita la escalabilidad, ya que si es necesario crear varias
29
sesiones RTP a la vez, esto ser posible creando varias instancias de las clases involucradas en el proceso.
Orientacin a la red: la API de Java proporciona clases que facilitan el uso de conexiones de red y el envo y recepcin de datos a travs de las mismas. En particular, los sockets y los channels. Posibilidad de usar lnea de comandos: Java permite la ejecucin de programas de forma similar a si lo hiciramos escribiendo comandos a travs de una consola del sistema operativo.
3.5.2 Sistema operativo, Ubuntu 7.04

Distribucin Linux que ofrece un sistema operativo enfocado a computadores personales. Actualmente es una de las ms importantes a nivel mundial, basada en Debian27 y con los objetivos de facilidad y libertad de uso. La librera RTP deber funcionar bajo dicho sistema operativo, por lo tanto el desarrollo como las pruebas han sido llevadas a cabo en dicho sistema operativo.
3.5.3 Entorno de desarrollo Eclipse:

El entorno de desarrollo elegido para las tareas de programacin ha sido Eclipse. Eclipse es una plataforma de software de cdigo abierto independiente de sistema, inicialmente diseado para el desarrollo de aplicacin Java. Se ha elegido este entorno de desarrollo por las facilidades especficas que ofrece para la programacin en Java, como por ejemplo la deteccin automtica de errores, el resaltado de elementos del lenguaje (palabras reservadas, variables), etc. Estas caractersticas facilitan el desarrollo y posterior comprensin del cdigo escrito. El SDK de Eclipse incluye las herramientas de desarrollo de Java, ofreciendo un IDE con un compilador de Java interno y un modelo completo de los archivos fuente de Java. Esto permite tcnicas avanzadas de refactorizacin y anlisis de cdigo. El IDE tambin hace uso de un
27 http://www.debian.org/index.es.html
30
espacio de trabajo, en este caso un grupo de metadatos en un espacio para archivos plano, permitiendo modificaciones externas a los archivos en tanto se refresque el espacio de trabajo correspondiente.
3.5.4 Wireshark
Una necesidad bsica para poder realizar pruebas era poder capturar el trfico que se estaba intercambiando a travs de la red entre los diferentes elementos. La herramienta elegida ha sido Wireshark, anteriormente conocida como Ethereal. Wireshark es una herramienta utilizada para realizar anlisis y solucionar problemas en redes de comunicaciones para desarrollo de software y protocolos, y tambin se usa como una herramienta didctica para educacin. Cuenta con todas las caractersticas estndar de un analizador de protocolos: 1. Captura en vivo y capacidad de anlisis offline. 2. Multiplataforma. 3. Rico en anlisis VoIP. Incorpora una interfaz grfica y muchas opciones de organizacin y filtrado de informacin. As, permite ver todo el trfico que pasa a travs de una red (usualmente una red Ethernet, aunque es compatible con algunas otras) estableciendo la configuracin en modo promiscuo. Tambin incluye una versin basada en texto llamada Tshark. Permite examinar datos de una red viva o de un archivo de captura salvado en disco. Se puede analizar la informacin capturada, a travs de los detalles y sumarios por cada paquete. Wireshark incluye un completo lenguaje para filtrar lo que se desea ver y la habilidad de mostrar el flujo reconstruido de una sesin de TCP, esta caracterstica lo hace especialmente til para examinar los mensajes intercambiados a lo largo de una sesin RTSP. Wireshark es software libre, y se ejecuta sobre la mayora de sistemas operativos Unix y compatibles, incluyendo Linux, Solaris, FreeBSD, NetBSD, OpenBSD, y Mac OS X, as como en Windows. Esta herramienta se usado para dos tareas concretas:
Examinar el intercambio de mensajes RTP/RTCP: Esto incluye tanto el anlisis
31
de los mensajes enviados por los dispositivos mviles para averiguar el uso real que hacen del protocolo, como la confirmacin de que la librera implementada enva y gestiona los mensajes correctamente.
Comprobar que los flujos de streaming a travs de RTP se estn creando correctamente, corroborando que los paquetes UDP estn llegando a la direccin IP y puertos correspondientes.
Ilustracin 3: Logotipo de la aplicacin Wireshark
3.5.5 Gestor de versiones SVN

Subversion (SVN)28 es un software de sistema de control de versiones, diseado especficamente para reemplazar a CVS29, el cual posee varias deficiencias. Una versin, revisin o edicin de un producto, es el estado en el se encuentra en un momento dado en su desarrollo o modificacin. Se llama control de versiones a la gestin de los diversos cambios que se realizan sobre los elementos de algn producto o una configuracin del mismo. Los sistemas de control de versiones facilitan la administracin de las distintas versiones de cada producto desarrollado, as como las posibles especializaciones realizadas (por ejemplo, para algn cliente especfico). El control de versiones se realiza principalmente en la industria informtica para controlar las distintas versiones del cdigo fuente. Sin embargo, los mismos conceptos son aplicables a otros mbitos como documentos, imgenes, sitios web, etctera. Es software libre bajo una licencia de tipo Apache/BSD y se le conoce tambin como SVN por ser ese el nombre de la herramienta de lnea de comandos. Una caracterstica importante de Subversion es que, a diferencia de CVS, los archivos
28 http://subversion.tigris.org/ 29 http://ximbiot.com/cvs/cvshome/
32
versionados no tienen cada uno un nmero de revisin independiente. En cambio, todo el repositorio tiene un nico nmero de versin que identifica un estado comn de todos los archivos del repositorio en cierto punto del tiempo. En este proyecto, SVN se ha utilizado para coordinacin con otros proyectos que dependen del mismo como por ejemplo LiveServe u otros que son usados como el modulo de negociacin SIP JSIP.
3.6 Infraestructura del sistema

Una vez descritos los protocolos, servicios, aplicaciones y herramientas a utilizar, podemos definir la infraestructura bsica del sistema. Antes de iniciar la implementacin de la librera, adems de estudiar la RFC correspondiente, es aconsejable estudiar las trazas mediante el analizador de redes Wireshark para comprobar como se comporta el protocolo y tener una visin mas completa. Con este objetivo, la infraestructura creada es la que se puede observar en la ilustracin 4.
Ilustracin 4: Infraestructura del sistema
33
El dispositivo mvil negociar con Asterisk el inicio de conexin mediante el protocolo SIP, se definirn el cdec a usar y otros parmetros antes de iniciar el flujo de media; igualmente, Asterisk negociar mediante SIP tambin con la aplicacin XLite, que recibir el flujo de datos. Una vez iniciada la conexin, Asterisk se limitar a reenviar los datos que recibe del mvil a X-Lite.
Ilustracin 5: Infraestructura del sistema con la librera RtpLib
El objetivo de la librera RtpLib a implementar en este proyecto es sustituir la aplicacin X-Lite por la librera RtpLib tal y como se puede observar en la ilustracin 5. Sin embargo, la negociacin SIP queda fuera de este proyecto, al igual que la reproduccin del media, por lo que se necesitan aplicaciones y libreras adicionales para cubrir la funcionalidad de la aplicacin X-Lite. Para la negociacin SIP se usar una librera implementado en Java llamada JSIP. Como se puede observar en la ilustracin 5 este modulo a su vez se encargar de iniciar una aplicacin VLC con la configuracin SDP correcta en base a la negociacin SIP. Una vez iniciada la conexin, Asterisk se limitar a reenviar los datos que recibe del mvil a nuestro ordenador, la librera RtpLib leer estos datos y responder con informacin de control RTCP, en el caso de terminales mviles responder tambin con paquetes dummy. Al
34
mismo tiempo, la librera reenviar los paquetes RTP a la aplicacin VLC para comprobar, mediante su visualizacin, que la recepcin de los datos se realiza de forma correcta.
CAPTULO 4.
EL PROTOCOLO RTP: ESPECIFICACIN

El protocolo RTP es un protocolo de transporte en tiempo real (Real-Time Transport Protocol), que provee de un servicio de entrega de datos punto-a-punto en tiempo real, como por ejemplo audio y vdeo Estos servicios incluyen:

Identificacin del tipo de datos enviados. Numeracin secuencial de los paquetes enviados. Marcado de timestamp de los paquetes enviados. Monitorizacin en el envo.
El protocolo RTP no provee a si mismo de ningn mecanismo para asegurar el envo a tiempo de los datos ni ninguna otra garanta de calidad de servicio, adems tampoco se garantiza el envo ordenado de los paquetes. El numero de secuencia incluido en el paquete RTP permite al receptor reconstruir la secuencia de los paquetes enviados, pero estos nmeros de secuencia tambin son usados para determinar la localizacin del paquete, como por ejemplo en la codificacin de vdeo, sin descodificar necesariamente los paquetes en secuencia. RTP est principalmente diseado para satisfacer las necesidades de conferencias con multitud de participantes multimedia. En esta introduccin al protocolo RTP se diferenciarn dos partes:
El protocolo RTP en si mismo, para llevar datos con propiedades caractersticas de el tiempo real.
35
CAPTULO 4. EL PROTOCOLO RTP: ESPECIFICACIN
36
El protocolo de control de RTP -el protocolo RTCP- que monitoriza la calidad de servicio y enva informacin sobre los participantes en una sesin.
RTP representa un nuevo estilo de protocolo siguiendo los principios del nivel de aplicacin. Con el protocolo RTP se intenta ofrecer una forma maleable de transportar informacin requerida por una aplicacin.
4.1.1 Escenarios de uso

Las siguientes secciones describirn algunos aspectos de uso del protocolo RTP. Los ejemplos fueron elegidos para ilustrar las operaciones bsicas de una aplicacin usando RTP. 1. Conferencia de audio en multicast: Aunque la sesin multicast no es un escenario de uso en este proyecto, por motivos histricos antes mencionados, es interesante tenerlo en cuenta. En una conferencia de audio, la aplicacin de cada uno de los participantes en dicha conferencia enva pequeos trozos de datos de audio, por ejemplo, 20 ms de duracin. Cada trozo de datos de audio es precedido por una cabecera RTP; la cabecera RTP y los datos son contenidos en un paquete UDP. La cabecera RTP indica el tipo de codificacin del audio que contiene cada paquete, por lo que cada emisor puede cambiar la codificacin durante la conferencia; para por ejemplo dar cabida a un nuevo participante que est conectado mediante una conexin de banda estrecha o para reaccionar frente a la congestin de la red. En Internet, como en otras redes de paquetes, ocasionalmente se producen perdidas, retrasos y desordenacin de paquetes. Para solucionar estos impedimentos, la cabecera RTP contiene informacin sobre el tiempo de reproduccin y nmeros de secuencia de cada paquete, que permite al receptor reconstruir la secuencia de paquetes enviados, por lo que en este ejemplo, se reproducir un paquete cada 20 ms. Esta reconstruccin de la secuencia temporal se lleva de forma independiente de cada fuente. El numero de secuencia tambin se usa para estimar el numero de paquetes perdidos. Como en la conferencia puede haber varias personas participando, es til saber
37
en cada momento quien est y quien ha dejado la conferencia. Para este propsito cada instancia de la aplicacin de audio que participa en la conferencia peridicamente enva un paquete de identificacin de la fuente. 2. Conferencia de audio y vdeo: Si ambos medias (vdeo y audio) son usados en la conferencia, estos son transmitidos en sesiones RTP diferentes. Esto es, habr paquetes RTP y RTCP transmitidos por medios diferentes usando dos puertos diferentes y/o direcciones multicast. No existe acoplamiento directo en el nivel RTP entre las sesiones de audio y el vdeo, excepto que el usuario participante en ambas debera usar el mismo nombre en los paquetes RTCP para cada una de las sesiones asociadas. Una motivacin para dicha separacin es permitir que alguno participantes en la conferencia reciban solamente uno de los medios a elegir. A pesar de dicha separacin, la sincronizacin se puede lograr usando informacin sobre los tiempos contenida en los paquetes RTCP de ambas sesiones.
4.2 La sesin RTP

Una sesin RTP consiste en un grupo de participantes quienes se estn comunicando mediante dicho protocolo. Un participante puede estar activo en diferentes sesiones RTP -por ejemplo, una sesin para intercambio de audio y otra para vdeo. Los puertos de recepcin y envo de la informacin deben ser los mismos. Una sesin puede ser unicast, donde cada participante est conectado directamente a otro o a un servidor central que redistribuye los datos. O tambin puede ser multicast para un grupo de participantes. Una sesin tambin necesita ser restringida para un espacio de direcciones.
4.2.1 Mezcladores
Un mezclador es un intermediario que recibe paquetes RTP de un grupo de fuentes y los combina en una nica salida, posiblemente cambiando la codificacin, antes de
38
reenviar el resultado. Debido a que el timing de los flujos de entrada generalmente no estarn sincronizados, el mezclador tendr que ajustar el mismo los tiempos para sincronizar el media antes de combinarlo. Un mezclador puede usar buffers para cada media de llegada y ayudar al mantenimiento del timing entre los fijos. El mezclador tiene su propio SSRC, que es insertado en los paquetes generados que se enviarn posteriormente. Los identificadores SSRC de los paquetes de entrada son copiados al CSRC de la lista de los paquetes.
Ilustracin 6: Mezclador M ve todas las fuentes como fuentes de sincronizacin; otros
participantes (A, B, X, Y y Z) ven una combinacin de fuentes de sincronizacin y contribucin. Un mezclador tiene una nica vista de una sesin: Este ve todas las fuentes como fuentes de sincronizacin, mientras que el resto de participantes ven algunos como fuentes de sincronizacin y a otras como fuentes de contribucin. Un mezclador no tiene porque usar el mismo SSRC para cada mitad de la sesin, pero tiene que enviar paquetes RTCP con las descripciones de las fuentes (SDES) y paquetes de fin de conexin (BYE) en ambos lados para todos los identificadores SSRC. De otra forma, los participantes de una mitad no sabrn que SSRC est siendo usado en la otra mitad, y pueden chocar con l. Es importante seguir la pista de los SSRC de cada lado, para detectar configuraciones que puedan crear bucles (por ejemplo, dos mezcladores conectados en paralelo, reenviando paquetes en circulo).
39
4.2.2 Multiplexando Sesiones RTP

Para un procesado eficiente del protocolo, el numero de puntos de puntos de multiplexin debe ser mnimo. En RTP, dicha multiplexin es provista por la direccin de transporte de destino (direccin de red y puerto) que es diferente en cada sesin RTP. Por ejemplo si en una conferencia compuesta de vdeo y audio el media se codifica de forma separada, cada medio debera ser transportado en sesiones RTP separadas con su propia direccin de transporte. Los flujos separados de audio y vdeo no deben ser transportados en una sola sesin RTP y demultiplexados basndose en el tipo del payload o el campo SSRC.
4.3 El protocolo de control de RTP: RTCP

El protocolo de control de RTP (RTCP), est basado en la trasmisin peridica de paquetes de control a todos los participantes de la sesin, usando el mismo mecanismo de distribucin que en el caso de los paquetes de datos; por lo tanto, el protocolo subyacente tiene que proveer de multiplexado entre los paquetes de datos y los de control, por ejemplo, usando puertos diferentes con UDP. RTCP ofrece tres funcionalidades: 1. Proveer informacin de retorno, esta es la funcionalidad primaria, y es una parte integral del rol del protocolo como protocolo de transporte y est relacionado con el flujo, el control de flujo y otros protocolos de transporte. Enviando informes de recepcin a todos los participantes permite que se puedan observar los posibles problemas para evaluar si dichos problemas son locales o remotos. 2. RTCP permite un nivel de transporte persistente para cada fuente RTP llamada nombre cannico (CNAME). El SSRC puede cambiar si se descubre que hay conflicto o si un programa es reiniciado, por lo que los receptores necesitan del CNAME para asociar mltiples flujos de datos desde un participante en un conjunto de sesiones relacionadas entre si; por ejemplo para sincronizar audio y vdeo. La sincronizacin entre medios requiere los
40
timestamps de los campos NTP y RTP incluidos por los emisores, ambos campos, descritos ms en profundidad posteriormente, contienen datos sobre el tiempo de envo y reproduccin respectivamente de cada paquete. 3. Enviando cada participante paquetes de control a todos los dems permite que cada uno pueda observar independientemente el numero de participantes. Este numero es usado para calcular el ratio con el que los paquetes deben ser enviados.
4.3.1 Reglas de timing

El ratio en que cada participante enva paquetes RTCP no est fijado, pero vara segn el tamao de la sesin y el formato del flujo de datos. Normalmente el flujo de paquetes RTCP es un 5% del total de carga de la conexin RTP. Esto se logra reduciendo en el ratio de cada participante tanto como el tamao de la conexin se incremente. En una telephone-party las llamadas normalmente usan RTP, cada participante enviar un informe RTCP cada pocos segundos; en una sesin con miles de participantes -por ejemplo, una estacin de radio por Internet- el intervalo entre los informes RTCP de cada receptor puede ser de minutos. Cada participante decide cuando enviar paquetes RTCP partiendo del hecho de que el conjunto de reglas descritas antes. Es importante seguir estas reglas estrictamente, especialmente para implementaciones que puedan usar sesiones de grandes magnitudes. Si est implementado de forma correcta, RTCP escalar sesiones con cientos de miembros. Si no, la cantidad de trafico crecer linealmente con el numero de miembros y causar una significante congestin en el trafico.
4.3.2 Intervalo de informe

El tiempo medio que cada participante espera entre cada envo de paquetes RTCP se conoce como intervalo de informe. Este se calcula partiendo del hecho que mltiples factores: 1. El ancho de banda asignado a RTCP: Es una fraccin fija de, como se ha
41
comentado, normalmente el 5%. El ancho de la sesin esperado es el ratio de datos por sesin; normalmente este es el bitrate30 de un solo flujo de audio o vdeo, multiplicado por el numero de emisores simultneos. El ancho de banda de la sesin es fijado para toda la duracin de la sesin, y suministrado como un parmetro de la configuracin para la aplicacin RTP cuando esta comienza. La fraccin del ancho de banda de la sesin puede cambiar segn el RTP profile que se est usando. Es importante que todos los miembros de una sesin usen la misma fraccin de tiempo; de otra forma, el estado para algunos miembros puede ser prematuramente cortado. 2. El tamao medio de los paquetes RTCP enviados y recibidos: que incluye no solo los datos RTCP, sino tambin los tamaos de las cabeceras UDP e IP. 3. El numero total de participantes y la fraccin de estos participantes que son emisores: Esto requiere una implementacin para mantener una base de datos de todos los participantes, sabiendo cuando son emisores (es decir, si los paquetes RTP o los paquetes SR de RTCP han sido recibidos de este) y cuando son receptores (si solo han sido recibidos paquetes RR, SDES o APP de RTCP).
4.3.3 Paquetes Compuestos

Cada paquete RTCP comienza con una parte fija similar a la cabecera fija de los paquetes RTP, seguido por unos elementos que puede ser de longitud variable acorde con el tipo de paquete, aunque deben siempre tener un tamao mltiplo de 32 bits. El alineamiento requerido y el campo longitud en la parte fija de cada paquete estn incluidos para conseguir que los paquetes puedan ser apilables. De esta forma, mltiples paquetes RTCP pueden ser concatenados sin intervencin de separadores para formar un paquete RTCP compuesto que ser enviado en un solo paquete de transporte, por ejemplo, UDP. Cada paquete del paquete compuesto debe ser procesado de forma independiente sin requerimientos como el orden o la combinacin de los paquetes. Aun as, existen algunas restricciones a tener en cuenta:
30 En telecomunicacin e informtica, el trmino tasa de bits (en ingls bit rate) define el nmero de bits que se transmiten por unidad de tiempo a travs de un sistema de transmisin digital o entre dos dispositivos digitales. As pues, es la velocidad de transferencia de datos.
42
1. Las estadsticas de recepcin (en paquetes SR y RR) deben ser enviadas con tanta frecuencia como las restricciones de ancho de banda se permita para maximizar la resolucin de las estadsticas, de esta forma cada paquete RTCP compuesto enviado debe incluir un paquete de informe. 2. Los nuevos receptores necesitan recibir el CNAME de una fuente tan pronto como sea posible para identificar la fuente y asociar el media. Por lo que cada paquete RTCP compuesto tiene que tambin incluir el CNAME en un paquete SDES. Los tipos de paquete RTCP son los siguientes:
SR (Sender Report): El informe de envo, sirve para la transmisin y recepcin de estadsticas desde los participantes que actan como emisores activos. RR (Receiver Report): Informe de recepcin, sirve para la recepcin de estadsticas desde los participantes que no actan como emisores activos y en combinacin con el SR para los emisores activos. SDES (Source Description): Paquete que describen las fuentes que participan en la conexin. BYE: Indica el fin de la participacin. APP: Permite especificar funciones de aplicacin.
Estos paquetes se describirn ms adelante con mayor detalle.
4.4 Aspectos sintcticos del protocolo RTP/RTCP

Antes de comenzar la implementacin de un protocolo hay que estudiar los aspectos sintcticos de dicho protocolo. Los aspectos sintcticos tienen que ver con:

Especificacin de los mensajes y de su formato. Especificacin de los mecanismos de codificacin.
Desde el punto de vista de la red, el mensaje es una secuencia de bits. Desde el punto de vista del programador, es conveniente que el mensaje se represente como una estructura de datos sobre el lenguaje informtico correspondiente.
43
Tendiendo en cuenta las definiciones de aplanamiento y desaplanamiento, cuando se desarrolla un protocolo, el emisor ser el que aplane el mensaje, mientras que el receptor recibe los bytes y los desaplana. Para que el esquema funcione, se deben definir e implementar una serie de reglas de codificacin y decodificacin para enviar y recibir paquetes. Aunque Java nos proporciona sistema de aplanamiento y desaplanamiento propios, dichos sistemas solo funcionan entre programas Java. Sin embargo, el propsito del proyecto es que la librera funcione en sistemas abiertos independientes de su plataforma o lenguaje, por ello se debern implementar dichos aplanadores y desaplanadores, de acuerdo a la descripcin que podemos encontrar en las RFC publicadas.
4.4.1 Formato del tiempo

El tiempo absoluto es representado usando el formato de timestamp del protocolo de tiempo en redes (Network Time Protocol31, NTP), que es en segundos relativos desde el segundo 0 del 1 de Enero de 1900. La mxima resolucin del NTP es de 64 bits sin signo con la parte entera en los primeros 32 bits y la parte fraccional en los otros 32. En algunas representaciones es ms apropiado usar una representacin ms compacta, donde solo los 32 bits intermedios de los 64 sern usados; esto es, los 16 bits ltimos de los primeros 32, y los primeros 16 de los ltimos 32 bits, que es la que se usar en el protocolo RTP.
4.4.2 Formato de los mensajes RTP

A continuacin se describir el formato de los mensajes RTP, tanto sus cabeceras fijas como el resto de los campos variables, que nos servir para implementar ms tarde los aplanadores y desaplanadores del protocolo.
4.4.2.1
Cabeceras fijas
A continuacin se describir las cabeceras fijas que llevarn cada uno de los
31 http://support.ntp.org/bin/view/Main/WebHome
44
paquetes RTP.
Ilustracin 7: Las cabeceras fijas de los paquetes RTP.
version (V): 2 bits Este campo identifica la versin del RTP. En este proyecto trabajaremos con la version 2.0, por lo que ser un valor fijo. padding (P): 1 bit Si el bit de padding est activado, el paquete contendr uno o mas octetos adicionales al final del paquete que no formaran parte de los datos tiles del paquete. El padding ser necesario por ejemplo en protocolos con algoritmos de encriptacin con bloques de tamao fijo. extension (X): 1 bit Si el bit de extensin est activado, la cabecera fija deber llevar exactamente una cabecera de extensin, con formato que se definir ms tarde. CSRC count (CC): 4 bits El contador de CSRC contiene el numero de de identificadores CSRC que seguirn a la cabecera fija. marker (M): 1 bit La interpretacin de este campo est definido por el profile. payload type (PT): 7 bits Este campo identifica el formato de los datos que transporta el paquete RTP determinando como debe interpretarlos la aplicacin. sequence number: 16 bits El numero de secuencia se incrementa en uno por cada uno de los paquetes enviados, y debera ser usado por el receptor para detectar paquetes perdidos y
45
restaurar la secuencia de los paquetes. El valor inicial de este campo debera ser aleatorio para evitar fallos de seguridad. Sin embargo, en los dispositivos mviles con los que trabaja los timestamp comienzan con valor cero. timestamp: 32 bits El timestamp refleja el instante de muestreo del primer octeto en el paquete RTP. El instante de muestreo debe ser derivado de la frecuencia de reloj que se incrementa linealmente para permitir la sincronizacin y los clculos del jitter (que se describir mas adelante). La frecuencia de reloj depende del formato de los datos transportados y es especificado estticamente en el profile o en las especificaciones del formato, o puede ser tambin especificado dinmicamente por el payload. Si los paquetes RTP se generan peridicamente, el instante de muestreo viene determinado por el instante de reloj que va a ser usado, no por el reloj de cuando ser ledo. Por ejemplo, para una conexin de audio el timestamp debera incrementarse en uno por cada periodo de muestreo. As, el instante de reproduccin del paquete est determinado por el timestamp y no por el momento de recepcin de paquete. Si una aplicacin de audio lee bloques cubriendo 160 periodos de muestreo desde el dispositivo de entrada, el timestamp debera incrementarse por 160 por cada uno de los bloques, pase lo que pase, siendo el bloque transmitido en un paquete o en forma de silencio. El valor inicial del timestamp debera ser aleatorio, al igual que el del numero de secuencia. Habr muchos paquetes que tendrn igual timestamp si son, por ejemplo, pertenecientes al mismo frame de vdeo. Paquetes consecutivos deberan contener timestamps que no sean montonos si los datos no estn siendo transmitidos en el orden de muestreo (esto ocurre por ejemplo de la interpolacin MPEG), aunque el numero de secuencia si ser transmitido de forma secuencial. Los timestamps de diferentes fuentes deberan avanzar en diferentes ratios de forma diferente y normalmente de forma independiente. Aunque estos timestamp son suficientes para reconstruir el timing de un solo flujo, comparando directamente timestamps de diferentes flujos RTP no es una forma efectiva de sincronizacin. De hecho, cada timestamp est relacionado con el instante de muestreo a partir de una referencia de reloj que representa el momento cuando el dato correspondiente fue muestreado. El reloj de referencia es compartido por todos los media que van a ser sincronizados. El
46
instante de muestreo es elegido como el punto de referencia para el timestamp porque tiene una definicin comn para todos los flujos, independiente de la codificacin u otros procesamientos. SSRC: 32 bits El campo SSRC identifica la fuente. Este identificador debera ser elegido aleatoriamente, con la intencin de que no haya dos fuentes de sincronizacin iguales en la misma sesin RTP. Aunque la probabilidad de que pase algo as es baja, la implementacin debe ser capaz de solucionar dicha eventualidad. CSRC list: 0 to 15 items, 32 bits each La lista CSRC identifica las fuentes que contribuyen para los datos que estn contenidos en el paquete. El numero de identificadores est dado por el campo CC. Si hay ms de 15, solo se podr identificar a 15 de ellos.
4.4.3 Formato de los mensajes RTCP

La especificacin define una importante cantidad de tipos de paquetes RTCP para transportar una gran variedad de informacin
4.4.3.1
SR (Sender Report)
El informe de envo, sirve para la transmisin y recepcin de estadsticas desde los participantes que actan como emisores activos. El paquete consiste en tres secciones, posiblemente seguidas de una cuarta, la extensin del profile. La primera seccin, la cabecera, tiene una longitud de 8 octetos.
47
Ilustracin 8: Cabeceras del paquete RTCP SR
Los campos son los siguientes: version (V): 2 bits Identifica la versin del RTP, que debe ser la misma que la de los paquetes RTCP; en este caso, es la version 2. padding (P): 1 bit Si el bit de padding est activado, este paquete RTCP contendr alguna informacin adicional al final del paquete que no formarn parte de la informacin de control pero que estarn incluidos en el campo de longitud. El ultimo octeto del padding es un contador del numero de octetos que deben ser ignorados, incluido l mismo. reception report count (RC): 5 bits El numero de bloques de informe de recepcin contenidos en el paquete. packet type (PT): 8 bits Contiene la constante 200 para identificar el paquete como un paquete RTCP SR.
48
length: 16 bits La longitud del paquete RTCP en palabras de 32 bits menos uno, incluyendo cabeceras y padding. SSRC: 32bits El identificador de la fuente de sincronizacin para el origen de dicho paquete SR. NTP timestamp: 64 bits Indica el tiempo de reloj cuando dicho informe a sido enviado, por lo que usado en combinacin junto a los timestamps devueltos en los informe de recepcin de otros receptores se podr medir el tiempo de ida y vuelta y realizar las conversiones de timestamp a tiempo real. En algunas implementaciones solo se usa los 32 bits intermedios como se ha comentado previamente. RTP timestamp: 32 bits Corresponde al mismo tiempo del NTP pero en unidades de timestamp de los paquetes RTP. Esta correspondencia ser usada la sincronizacin entre los diferentes medias y para estimar la frecuencia de reloj. sender's packet count: 32 bits El numero total de paquetes RTP transmitidos por el emisor desde el inicio de la transmisin hasta el momento en que el paquete SR fue generado. La cuenta debera comenzar de nuevo si el SSRC de la fuente cambia. sender's octet count: 32 bits El numero total de octetos de payload enviados en los paquetes RTP trasmitidos por el emisor desde el inicio de la conexin. Tambin debera comenzar de nuevo si se cambia el SSRC. La tercera seccin del paquete SR cuenta con uno o mas bloques de informe de recepcin dependiendo del numero de las fuentes. SSRC_n (source identifier): 32 bits El identificador de la fuente al que pertenece la informacin del bloque. fraction lost: 8 bits La fraccin de paquetes RTP perdidos de la fuente SSRC_n desde que el ultimo paquete SR o RR fue enviado. Esta fraccin es definida como el numero de paquetes perdidos entre el numero de partidos enviados. El numero de paquetes perdidos se puede calcular fcilmente gracias a los nmeros de secuencia.
49
cumulative number of packets lost: 24 bits El numero total de paquetes RTP de la fuente SSRC_n que se han perdido desde el comienzo de la recepcin Este numero es definido como el numero de paquetes esperado menos el numero de paquetes recibidos, donde los recibidos incluyen los duplicados. extended highest sequence number received: 32 bits Los ltimos 16 bits contienen el mayor numero de secuencia recibido en un paquete RTP de la fuente SSRC_n, y los 16 bits extienden a los nmeros de secuencia. interarrival jitter: 32 bits Es una estimacin de la varianza estadstica de los paquetes RTP, el calculo del jitter de especificar ms tarde en la implementacin.
4.4.3.2
RR (Receiver Report)
Informe de recepcin, sirve para la recepcin de estadsticas desde los participantes que no actan como emisores activos y en combinacin con el SR para los emisores activos.
Ilustracin 9: Cabeceras del paquete RTCP RR
Los campos son anlogos al SR, cumpliendo las mismas funciones pero en
50
direccin contraria, ya que son datos que enva el receptor de los paquetes al emisor.
4.4.3.3
SDES (Source Description)
El paquete SDES es una estructura de tres niveles compuesta por una cabecera y uno o ms Chunks, cada uno de ellos compuesto de items que describen la fuente de que identifica dicho Chunk.
Ilustracin 10: Cabeceras del paquete RTCP SDES
Cada uno de los items tienen una cabecera fija que identifica su tipo, su longitud del propio y el campo con el contenido. Los tipos pueden ser: CNAME, NAME, EMAIL, PHONE, LOC, TOOL, NOTE y PRIV.
51
4.4.3.4
BYE (Goodbye)
Indica el fin de la participacin. Uno o ms fuentes que no volvern a estar activas.
Ilustracin 11: Cabeceras del paquete RTCP SDES
4.4.3.5
APP (Application-Defined RTCP Packet)
El paquete APP se utiliza de forma experimental o para nuevas aplicaciones que estn siendo desarrolladas, en este caso, se ha usado para usar la tecnologa PTT como paquetes de control de membresa.
Ilustracin 12: Cabeceras del paquete RTCP APP
CAPTULO 5.
DESCRIPCIN INFORMTICA
5.1 Descripcin de la metodologa empleada
Para el desarrollo de este proyecto de ha optado por un modelo de proceso de desarrollo similar al modelo incremental e iterativo.
5.1.1 El proceso unificado de desarrollo

El proceso unificado de desarrollo es es un proceso de desarrollo de software configurable que se adapta a travs de los proyectos variados en tamaos y complejidad. Se basa en muchos aos de experiencia en el uso de la tecnologa orientada a objetos en el desarrollo de software de misin crtica en una variedad de industrias por la compaa Rational".32 El proceso unificado de desarrollo gua a los equipos de proyecto33 para saber como administrar el desarrollo iterativo de un modo controlado. Dicho proceso nace de la unificacin de las tres metodologas de desarrollo basadas en el paradigma orientado a objetos existentes hasta el momento de su creacin:
OOSE (Object Oriented Software Engineering): Incluye el modelo de casos de
32 El Proceso Unificado de Desarrollo Software: Jacobson, Booch, Rumbaugh 33 Un equipo de proyecto es un grupo de especialistas que comparten un objetivo impuesto desde fuera, con valores y actitudes heterogneas
52
CAPTULO 5. DESCRIPCIN INFORMTICA
53
uso, Jacobson, I.
OOAD (Object Oriented Analysis and Design): Incluye el modelo de diseo, Booch, G. OMT(Object Modeling Technique): Incluye las tcnicas de modelado para el anlisis, Rumbaugh, J.
El Proceso Unificado (UP, Unified Process) combina prcticas comnmente aceptadas como "buenas prcticas", tales como el ciclo de vida iterativo y desarrollo dirigido por el riesgo, en una descripcin consistente y bien documentada. Un proceso es orientado por el riesgo cuando intenta identificar y definir estrategias para enfrentar los riesgos ms graves del proyecto, resolviendo primero los puntos ms difciles, elaborando planes de contingencia y tratando de anticipar las dificultades. El Proceso Unificado utiliza el Lenguaje Unificado de Modelado (Unified Modeling Language, UML) para preparar todos los esquemas de un sistema software. De hecho UML es una parte esencial de Proceso Unificado (sus desarrollos fueron paralelos). Las principales caractersticas del Proceso Unificado son: 1. Dirigido por casos de uso: Para construir un sistema con xito debemos conocer lo que sus futuros usuarios necesitan y desean. Como usuarios se puede entender no solo a los humanos, sino otros sistemas. Cada una de las interacciones que tiene un usuario con el sistema es un caso de uso. Dichos casos de uso representan los requisitos funcionales. Todos los casos de uso constituyen el modelo de casos de uso. Sin embargo los casos de uso no slo sirven para especificar los requisitos del sistema, sino tambin para guiar el proceso de desarrollo, su diseo, implementacin y prueba. 2. Centrado en la arquitectura: El concepto de arquitectura software incluye los aspectos estticos y dinmicos ms significativos del sistema. La arquitectura es una vista del diseo completo con las caractersticas ms importantes resaltadas, dejando los detalles de lado. Debido a que lo que es significativo depende en parte de una valoracin, que a su vez, se adquiere con la experiencia, el valor de una arquitectura depende de las personas responsables de su creacin. 3. Iterativo e incremental: Es prctico dividir el trabajo en partes ms pequeas o miniproyectos. Cada miniproyecto es una iteracin que resulta en un
54
incremento. Las iteraciones hacen referencia a pasos en el flujo de trabajo, y los incrementos, al crecimiento del producto. En cada iteracin, los desarrolladores identifican y especifican los casos de uso relevantes, crean un diseo utilizando la arquitectura seleccionada como gua, implementan el diseo mediante componentes, y verifican que los componentes satisfacen los casos de uso. As, los beneficios que obtenemos son: reduccin de costes y de riesgos y aceleracin del ritmo de desarrollo.
55
5.2 Planificacin
5.2.1 Objetivos parciales necesarios para alcanzar el objetivo final
Estudio de la RFC: Aspectos sintcticos del protocolo para realizar el aplanamiento y desaplanamiento de forma correcta. Contexto y semntica del protocolo, protocolo de control RTCP,. Aproximacin al desarrollo de aplicaciones Java mediante el entorno de desarrollo Eclipse. Acercamiento al manejo de herramientas de anlisis de redes, como Wireshark. Estudio del lenguaje Java en el control de hilos. Aprendizaje de configuracin y manejo de las aplicaciones X-Lite y VLC para realizar las pruebas.
5.2.2 Descripcin de las etapas que se seguirn en el desarrollo

1. Comprensin del sistema a desarrollar: Mediante reuniones con los tutores o responsables del proyecto, estableciendo las bases del sistema. 2. Requisitos: La especificacin de requisitos ya ha sido fijada previamente, por lo que en este caso se estudiar y comprendern dichos requisitos. 3. Familiarizacin e instalacin de las herramientas de trabajo: Acercamiento a las herramientas y plataformas con las que se trabajar; para ello se estudiarn manuales de dichas herramientas. 4. Diseo e implementacin de aplanamiento y desaplanamiento: diseo e implementacin de las clases que ofrecern dicha funcionalidad. 5. Prueba del aplanamiento y desaplanamiento: 1. Con test programados en Java. 2. Mediante el analizador de redes Wireshark. 6. Diseo e implementacin del reenvo de paquetes RTP: diseo e implementacin de los mdulos de recepcin y envo de paquetes RTP.
56
7. Prueba de reenvo de paquetes RTP: mediante dos instancias de la aplicacin VLC, la librera simplemente realizar el fordwarding de los paquetes RTP recibidos a otra aplicacin VLC. 8. Diseo e implementacin del protocolo de control RTCP: 1. Diseo e implementacin de los mdulos de recepcin y envo de paquetes RTCP. 2. Obtencin y calculo de estadsticas RTCP. 9. Prueba de recepcin de datos con mviles Nokia: se comprobar la correcta visualizacin y el mantenimiento de la conexin mediante los paquetes dummy y RTCP. 10. Buffer de paquetes RTP: 1. Diseo e implementacin de simulacin y absorcin de retrasos. 2. Prueba de simulacin y absorcin de retrasos. 1. Se probar mediante aplicaciones VLC, de forma similar al punto 4. 3. Diseo e implementacin de recuperacin antes cortes. 1. Prueba con la misma estructura que la anterior prueba. 11. Finalizacin de la documentacin: Se documentar el Javadoc con las funciones ms importantes. 12. Integracin: Integracin de la librera en la aplicacin LiveServe.
57
5.3 Especificacin de requisitos

Este apartado contiene el documento con la especificacin de requisitos de la librera a desarrollar. Dicho documento ha sido estructurado siguiendo las directrices marcadas por el estndar IEEE Recommended Practice for Software Requirements Specification ANSI/IEEE 830 1998. Para conseguir estos requisitos se ha realizado un proceso de documentacin basado principalmente en lectura de artculos publicados, y principalmente, el anlisis de la RFC publicada cobre el protocolo RTP. Estos requisitos nacen de la necesidad de integrar la librera del protocolo RTP en un sistema mayor, como se ha comentado en la introduccin, en la librera LiveServe.
5.3.1 Propsito
El propsito de la especificacin de requisitos es aclarar las propiedades, funcionalidades y restricciones lo que se debe construir. Esta especificacin va dirigida a los desarrolladores del producto, evaluadores del proyecto y posibles usuarios finales.
5.3.2 mbito del sistema

El objetivo principal es construir una librera que permita el desarrollo de aplicaciones basadas en la transmisin de flujos de audio y vdeo a travs de la red mediante el protocolo RTP. Esta librera permitir la recepcin, envo y reenvo de paquetes RTP, el clculo de estadsticas a partir de los paquetes recibidos y crear flujos de paquetes RTCP tanto con el emisor como el receptor. Adems, la librera proporcionar un buffer para la reordenacin de los paquetes y absorber retrasos.
5.3.3 Interfaces externos

Como el proyecto es una librera del protocolo RTP/RTCP no existir ninguna
58
interfaz de usuario, sin embargo, en la API se describirn ms adelante como usar la librera de forma correcta para que se pueda desarrollar con ella.
5.3.4 Requisitos funcionales

Para conseguir los objetivos especificados anteriormente la librera debe cumplir las distintas funciones explicadas a continuacin. R1. Fcil uso de paquetes/objeto RTP y RTCP: Una vez desaplanados los paquetes, se construirn objetos que permitan el manejo fcil por parte de los desarrolladores de dichos paquetes y viceversa, es decir, que a partir de objetos de tipo RTP/RTCP se permita aplanar y enviar por la red de forma que el receptor los reciba de forma correcta independientemente de la plataforma. R1.1. Leer/Modificar cualquier campo de un paquete RTP/RTCP: para ello, se debe proporcionar aplanadores y desaplanadores de paquetes RTP/RTCP. Para codificarlo se debe tener especial atencin a la RFC 3550 donde encontraremos los aspectos sintcticos del protocolo. R2. El protocolo debe ser capaz de predecir la variacin de tiempo en el transito de informacin en la red: por ejemplo, en un sistema de telefona IP se codifica la voz en 20 frames por segundo. La fuente transmitir un paquete cada 20 milisegundos, e idealmente el receptor querr recibir los paquetes con el mismo espacio de tiempo para que la conversacin pueda ser reproducida sin problemas. Sin embargo, en el caso no ideal, existen retrasos en la comunicacin, pero dichas variaciones en el tiempo de transito pueden ser absorbidas por un buffer intermedio en el receptor. R3. Reenviar/duplicar paquetes a distintas IP's/puertos: es decir, modificar tambin los campos de las cabeceras UDP. R4. Control de flujos RTCP. R4.1. Construir flujos RTCP de vuelta a la fuente RTP, con la informacin de control til para el emisor: teniendo en cuenta las posibles peculiaridades de los emisores (como por ejemplo alguno de los dispositivos mviles antes mencionados), se debe poder crear flujos de control a los emisores en una sesin RTP. R4.2. Recibir y gestionar flujos RTCP de los receptores para ajustar las emisiones a
59
cada destinatario: anlogo al requisito anterior, la librera debe proporcionar gestin de los flujos de control recibidos tanto por el emisor como por el receptor. R5. Simular "pausas" o silencios: creando paquetes RTP's vacos para los destinatarios. R6. Inyectar a los flujos RTP's salientes flujos "grabados": cuando por ejemplo el emisor del flujo RTP entrante sufre un corte transitorio. R7. Fordwarding de Stream RTP: la librera debe permitir que se pueda redireccionar un flujo entrante a uno o varios receptores nuevos de forma transparente. R8. Aadir un nuevo flujo RTP de salida partiendo de un fordwarding anterior: De forma anloga al anterior requisito, adems de simplemente redireccionar el flujo entrante, la librera debe proporcionar mecanismos para que los paquetes de los diferentes flujos de salida puedan ser manipulados, como por ejemplo, los nmeros de secuencia, el SSRC u otros campos. R8.1. Timestamp: Al flujo de salida se le debe poder configurar el campo timestamp, de forma que el timestamp del flujo saliente comience por cero para proporcionar compatibilidad con algunos mviles como el N73, y adems, mantenga el ratio que tena dicho timestamp. R8.2. SSRC: En caso de que el desarrollador (el usuario de la librera) opte por un mezclador, la librera debe modificar el campo de SSRC para mantener en el flujo de salida el suyo mismo. R9. Reenvo de paquetes dummy por el canal del flujo RTP: Los paquetes dummy deben ser paquetes RTP que sern enviados por el mismo canal que el mvil enve los datos de vdeo. Estos paquetes no contienen datos y debern ser enviados cada cierto tiempo fijo. R10. Audio y Vdeo de distintas fuentes: Modificar dos flujos independientes de audio y vdeo para que estn sincronizados entre s. En este caso se debe modificar el timestamp para traducir de tiempo real a diferencia de timestamps. R11. Librera configurable: R11.1. Arrancar receptor RTP en un socket atado pasado como parmetro.
60
R12. Scheduler34:El
scheduler
es
un
planificador
que
permite
controlar
dinmicamente el flujo RTP. En la librera es un buffer que almacena paquetes RTP entrantes y planifica su salida con el fin de dar transparencia al destinatario, sobre los cambios que se puedan producir en el media. Algunos requisitos mencionados anteriormente son dependientes de la implementacin del scheduler, aqu se indican con ms detalle los requisitos especficos del scheduler: R12.1. Mantener constante la tasa de envo de paquetes que salen del buffer: esta temporizacin debe ser coherente con el timestamp de los paquetes. R12.2. Mantener el timestamp de salida en el buffer: modificndolo si fuera necesario, para ser coherente con un flujo de salida continuo. R12.3. Posibilidad de retrasar el media: en "x" segundos, o "x" paquetes RTP (delays). R12.4. Sincronizar flujos de audio o vdeo: introduciendo delays(retrasos) en uno de los canales RTP. R12.5. Reordenar paquetes RTP: en el caso de que stos llegaran desordenados. R13. Java: El desarrollo de la librera se har sobre el lenguaje de programacin Java.
5.3.5 Requisitos no funcionales

R14. Consumo de recursos: El rendimiento de la librera debe ser capaz de mantener un flujo de salida lo suficientemente alto como el flujo que recibe de entrada. Adems, la librera debe ser capaz de manejar varias fuentes simultneamente sin limitaciones de numero (permitir tanto como el protocolo especifica). R15. Documentacin: La librera debe estar documentada en Javadoc para la correcta utilizacin de los futuros desarrolladores. Adems, se debe proporcionar una buena API con la que se pueda aprender a como desarrollar de forma fcil.
34 http://en.wikipedia.org/wiki/Scheduling_(computing)
61
5.3.6 Casos de uso

Los casos de uso, segn las especificaciones del protocolo y los requisitos planteados: 1. Recepcin de paquete RTP, desaplanado, modificacin de datos, aplanamiento y reenvo. 2. Anlogo al anterior, pero con mantenimiento de informacin RTCP para emisor y receptor. 3. Anlogo a cualquiera de los dos primeros, pero permitiendo almacenar los paquetes en un buffer para poder absorber retrasos (o simularlos).
62
5.4 Arquitectura y Anlisis

Para realizar el anlisis, prestaremos especial atencin a los requisitos que se han descrito previamente, refinndolos y estructurndolos, con el objetivo de conseguir una compresin ms precisa de los requisitos y una descripcin de los mismos ms fcil de mantener y que ayude a estructurar el sistema entero. El sistema deber dividirse en funcionalidades diferenciadas. 1. Aplanamiento/desaplanamiento. 2. Gestin de la sesin RTP. 3. Gestin de la sesin RTCP. 4. Uso del Buffer. As pues, parece claro que tendremos una clase que nos permita aplanar/desaplanar, pero como en el caso de RTCP tenemos varios tipos de paquetes, lo ms lgico sera usar una clase para cada tipo de mensaje, y beneficiarnos de las ventajas de la programacin orientada a objetos.
Ilustracin 13: Clases de anlisis: Paquetes
63
5.4.1 Diagramas de colaboracin

Aunque el intercambio de mensajes y las relaciones entre objetos se detallarn de forma ms clara en los diagramas de secuencia, un buen artefacto para describir de forma superficial el comportamiento del protocolo son los diagramas de colaboracin.
5.4.1.1
Fordwarding de paquete RTP
En este caso, como se puede observar en la ilustracin 14, al recibir el paquete desaplanaremos el la cadena de bytes creando un objeto Java, modificaremos campos del paquete en caso de que sea necesarios, se aplanar de nuevo y se reenviar al destino correspondiente.
Ilustracin 14: Diagrama de colaboracin: Reenvo de paquete RTP
En este caso no se contemplan el caso del envo de paquetes dummy. Los paquetes dummy son paquetes vacos de contenido, que enviar la librera a la fuente del media que lo requieran (en este caso los terminales mviles Nokia mencionados anteriormente). Estos paquetes deben ser enviados con un intervalo de tiempo fijo. El numero de secuencia del primer paquete dummy debe ser cero (al contrario de la recomendacin de la RFC de que debe ser aleatorio) y mantenerse secuencial por cada paquete dummy enviado. El envo de estos paquetes dummy ser al mismo puerto por
64
el que enva el terminal el flujo de video. 5.4.1.2 Mantenimiento de la sesin RTCP
En este caso, como se puede observar en la ilustracin 15, la sesin RTCP recibe mensajes, los desaplana y actualiza los datos. Segn a esos datos (numero de paquetes perdidos, jitter...) se enviarn paquetes RTCP a las fuentes de la sesin y el receptor.
Ilustracin 15: Diagrama de colaboracin: Mantenimiento de sesin RTCP
5.4.1.3
Uso del buffer
En este caso, como se puede observar en la ilustracin 16, en lugar de reenviar los paquetes directamente al receptor, se almacenarn en un buffer. La sesin RTP recibe los paquetes, los desaplana y los introduce en un buffer. Luego, la misma sesin decide cuando enviar dichos paquetes, los sacar del buffer y los enviar al receptor.
65
Ilustracin 16: Diagrama de colaboracin: Uso del buffer
66
5.5 Diseo
En el diseo modelamos el sistema y encontramos su forma para que soporte todos los requisitos, as los propsitos sern:
Adquirir una comprensin en profundidad de los aspectos relacionados con los requisitos no funcionales y restricciones relacionadas con los lenguajes de programacin. Ser capaces de descomponer los trabajos de implementacin en partes ms manejables que puedan ser llevadas a cabo por diferentes equipos de desarrollo.
Por otra parte, en la implementacin empezamos con el resultado del diseo e implementacin del sistema en trminos de componentes, es decir, ficheros de cdigo fuente, scripts, ficheros de cdigo binario, ejecutables y similares.
5.5.1 Decisiones de Diseo
ByteBuffer35: Para representar el conjunto de bytes que ser un paquete
RTP/RTCP, se ha decidido usar la clase ByteBuffer que proporciona Java; esta clase nos permite crear objetos a partir de un array de bytes, o asignar memoria, de tal forma que se pueda extraer los campos del conjunto de bytes de forma ms fcil, ya que dicha clase permite acceder a conjuntos de bytes, enteros...Para crear un objeto ByteBuffer se debe llamar realizar la llamada
ByteBuffer.allocateDirect(size), siendo allocateDirect un mtodo
esttico y el parmetro size el tamao que tendr el objeto ByteBuffer. Tambin se pueden crear objetos ByteBuffer a partir de arrays de byte con datos mediante la llamada ByteBuffer.wrap(new byte[]), siendo wrap el mtodo esttico que recibe como parmetro un array de bytes.
Campos sin signo: Java posee diferentes tipos primitivos (int, char, long) pero no posee versiones sin signo para ninguno de ellos; por lo tanto, pueden existir casos que en el desaplanamiento obtengamos un numero negativo; por
35 http://java.sun.com/j2se/1.5.0/docs/api/java/nio/class-use/ByteBuffer.html
67
ejemplo, en el caso del timestamp, recibimos 32 bits, pero si lo introducimos en una variable de tipo int, si el timestamp es superior o igual a 2 32 , tendremos un numero negativo. Por esta razn, todos los campos de los paquetes RTP/RTCP sern almacenados en variables que sean ms grandes que los propios campos. As, en el caso de obtener el campo timestamp del ByteBuffer que contiene la secuencia de bytes con el paquete RTP la llamada sera
getTimeStamp, un mtodo sin parmetros que devuelve el campo timestamp
del ByteBuffer despus de convertirlo a long.
Reutilizacin: Otra decisin de implementacin es la reutilizacin del

ByteBuffer. La asignacin de memoria es un proceso que consume una
notable cantidad de recursos si se realiza de forma continua y adems se necesita que la aplicacin sea rpida como ocurre en este caso. Se recibirn una gran cantidad de paquetes por segundo, y por cada uno de ellos se tendr que asignar memoria, sin embargo, solo tendremos que tener asignada la memoria para el numero de paquetes que tengamos en ese momento (al mismo tiempo que recibimos, tambin enviamos con la misma velocidad), por lo tanto, se puede realizar un pool de ByteBuffer, al igual que en el caso de los threads, y reutilizar la memoria ya asignada para nuevos paquetes. As, cuando queramos aplanar un objeto de tipo Packet, llamaremos al mtodo marshall que aplana el objeto Packet que ha llamado dicho mtodo devolviendo un objeto
ByteBuffer con el conjunto de bytes contiendo los datos de dicho paquete. El
mtodo marshall recibe como parmetros otro ByteBuffer, en caso de que este no sea nulo (ya tenga memoria asignada), en lugar de crear un nuevo
ByteBuffer se proceder a usar este pasado por parmetro.
Channels36: Para realizar el envo y recepcin de los paquetes aplanados se ha decidido usar la clase DatagramChannel, ya que como se ha indicado anteriormente, el protocolo RTP es un protocolo construido sobre UDP, y la clase DatagramChannel permite de forma fcil y rpida recibir y enviar paquetes UDP por la red. Adems, utilizar canales facilita la implementacin por eventos de el modulo que recibir los paquetes RTP, ya que permite como
36 http://java.sun.com/j2se/1.5.0/docs/api/java/nio/channels/DatagramChannel.html
68
se ha visto anteriormente, crear un objeto de tipo Selector y aadirle los canales que se quiera que escuche en caso de que lleguen paquetes RTP. La configuracin de estos canales se detallar en la API.
PriorityQueue: Los paquetes RTP sern almacenados en un buffer, dichos
paquetes pueden ser recibidos desordenados y para cumplir el requisito 12. Para ello, se ha decidido usar la clase PriorityQueue que proporciona Java. Dicha clase, almacenar paquetes RTP y los ordenar correctamente, adems permitir que varios hilos puedan acceder a dicho buffer de forma segura. El buffer ordenar el los paquetes de acuerdo a la implementacin de un Comparator37 (interfaz de Java) por lo que se deber tener una implementacin de dicha interfaz, dicha implementacin es la clase RtpBufferNodeComparator.
Jitter: Para la implementacin del jitter se sigue los clculos de la RFC del protocolo RTP. En la implementacin se ha optado por un mtodo llamado
estimateJitter, cuya implementacin al completo se puede observar en el
texto 1.
public static long estimateJitter(long si, long ri, long sj, long rj, long curJ) { long d = (rj - sj) - (ri - si); return curJ + (Math.abs(d) - curJ) / 16; }
Texto 1: Estimacin del jitter
Dicho cdigo, calcular el jitter cada vez que se reciba un nuevo paquete RTP, los parmetros de la funcin son:

si: timestamp del paquete recibido. ir: ratio timestamp del flujo de datos perteneciente al paquete recibido, aunque
debe ser fijo, aunque calculado dinmicamente por cada paquete recibido para detectar cambios, como por ejemplo cortes de la conexin, que provocar que el timestamps de los nuevos paquetes al reiniciado de la conexin no sean coherentes con los anteriores (recordemos que el timestamp comienzan con valores aleatorios).
sj: timestamp del anterior paquete recibido.
37 http://java.sun.com/j2se/1.5.0/docs/api/java/util/Comparator.html

69
rj: momento temporal en que fue enviado el anterior paquete. curj: jitter anterior. Si es la primera que es calculado debe ser cero.
5.5.2 Diagramas de clases de diseo

La clase de diseo es un artefacto, una abstraccin de una clase o construccin del sistema que permite describir la estructura del sistema mostrando sus clases, atributos y mtodos.
5.5.2.1
Paquete packets.rtcp:
En este paquete encontraremos la jerarqua de clases para usar de forma sencilla los objetos que crearemos segn recibamos/enviemos paquetes RTCP, adems de las clases que nos permitirn realizar el aplanamiento/desaplanamiento a partir de los paquetes u objetos.
Rtcp[TipoRtcp38]ByteBuffer: Su funcin es proporcionar mtodos para que,
partir
de
un
conjunto
de
bytes,
crear
un
objeto
del
tipo
Rtcp[TipoRtcp]Packet, es decir, desaplanar los datos. Todas estas clases
(como se puede observar en la ilustracin 17) debern implementar la clase abstracta RtcpByteBuffer, que servir como la interfaz para el desarrollador de las posibles funcionalidades de un paquete RtcpByteBuffer. Adems, con una interfaz comn, se usarn las ventajas del polimorfismo, ya que cuando se reciba un paquete Rtcp, no ser necesario comprobar que tipo de mensaje es este para poder desaplanarlo y convertirlo en un objeto. Adems, tenemos el caso especial de RtcpRByteBuffer, que ser una clase abstracta ya que tanto los paquetes SR como RR son muy parecidos, por lo que parte de su implementacin ser comn.
38[TipoRtcp]: SR | RR | SDES | APP | BYE
70
Ilustracin 17: Paquete rtplib.packets.rtcp ByteBuffer (desaplanadores)
Rtcp[TipoRtcp]Packet: Clases cuya funcionalidad es representar, en forma
de objeto Java, paquetes de RTCP. Con la jerarqua de clases que se puede observar en la ilustracin 17, para cada paquete, nos permite usar la flexibilidad del polimorfismo y las ventajas de la reutilizacin de cdigo. Al igual que en el caso de las clases RtcpByteBuffer, hay una interfaz que todas implementarn; en esta caso tambin tenemos una clase abstracta RtcpRPacket, que representa la funcionalidad de los paquetes de tipo informe (los receiver y sender report), ya que ambas clases comparten funcionalidades e implementacin.
Chunk: Se usa para crear una serie de componentes de tipo Chunk y facilitar la
utilizacin de los paquetes SDES.
Item: Los objetos Chunk contienen su vez objetos Item, por lo que se decide
crear una clase que permite manejar de forma ms cmoda estos elementos.
Ilustracin 18: Paquete rtplib.packets.rtcp Packet (aplanadores)
71
5.5.2.2
Paquete receivers.rtcp, receivers.rtp y sender
RtpSession: Por cada flujo de datos RTP que se establezca entre dos nodos de
la red, se crear una RtpSession, clase principal que controlar todo el proceso de intercambio de datos. Como se puede observar en la ilustracin 18, esta clase centralizar el funcionamiento de toda la librera. Adems, contendr un mapa hash que permitir acceder ms fcilmente a las fuentes que participan en la conexin.
RtpReceiver: Clase que proporciona la funcionalidad para recibir paquetes
RTP, y actualizar los datos cada vez que se recibe un paquete RTP correspondiente al flujo que est controlando la sesin RTCP.
RtcpSession: Por cada comunicacin de audio/vdeo puede haber tambin
intercambio de datos de control entre los participantes; en ese caso, entre cada nodo se crear una sesin Rtcp desde la que se controlar todos los aspectos del control de la comunicacin. Como se puede observar en la ilustracin 18, la
RtcpSession estar siempre relacionada con la RtpSession, de tal forma que
acceder a los datos de esta para poder realizar la comunicacin, de esta forma conseguimos que los datos estn accesibles desde una sola clase, centralizando el acceso.
RtpReceiver: Anloga a la clase RtpReceiver, se utiliza para recibir los
paquetes Rtcp, y actuar en consecuencia dependiendo el tipo de paquete Rtcp que se reciba.
MediaSource: Clase que mantendr toda la informacin de una fuente de
sincronizacin, principalmente los datos necesarios para mantener estadsticas que se necesiten para crear los paquetes de control. Como varios hilos pueden consultar y cambiar datos de una fuente, ser necesario preservar la coherencia de los objetos MediaSource, por lo que se utilizar el mecanismo de
synchronized de Java para asegurar la coherencia y el acceso nico a cada
fuente.
RtpSender: Al igual que con la clase RtpReceiver contiene la funcionalidad
para recibir los paquetes, esta clase har lo mismo pero enviando los paquetes RTP a los destinatarios correspondientes. Adems, debe encargarse de enviar
72
los paquetes cada cierto intervalo de tiempo, definido por el timestamp.

HashMap<Long,MediaSource>: La clase RtpSession, para almacenar las
diferentes fuentes utilizar un HashMap39, que permita acceder de forma rpida a cada fuente a partir de su identificador. Se ha decidido optar por el uso del HashMap ya que permitir acceder directamente a cada fuente, utilizando de clave hash el identificador de fuente. Dicho HashMap contendr objetos MediaSource, con los datos de las fuentes que forman parte de la conexin.
Ilustracin 19: Paquete rtplib.receivers.rtp, rtplib.receivers.rtcp y rtplib.sender
5.5.2.3
Paquete rtplib.buffer:
RtpBufferList: Como se puede observar en la ilustracin 20, simplemente
contendr dos buffers, uno de audio y otro de vdeo, gestionando el retardo en que deben comenzar cada uno de los flujos e iniciando las configuraciones de ambos buffers.
39 http://java.sun.com/j2se/1.5.0/docs/api/java/util/HashMap.html
73
RtpBuffer: El buffer permitir absorber retrasos y reordenar los paquetes, es
decir, contendr toda la lgica del scheduler, ser una clase que recubrir a la
PriorityQueue y cuando almacenemos o elimines del buffer, se realizar la
misma accin en la PriorityQueue.
RtpBufferNode: El nodo contendr un paquete RTP adems de informacin
necesaria para que el RtpBuffer pueda reordenarlos de forma eficiente.
RtpBufferNodeComparator: Aunque no pertenezca al paquete, esta clase
indicar la forma en que se deben ordenar los paquetes dentro del buffer, implementando el interfaz Comparator40 de Java. La forma de comparar los paquetes ser de la siguiente forma: 1. Si los timestamp son diferentes, ir primero el que menos timestamp tenga. 2. Si no, entonces ir primero el que tenga un numero de secuencia ms bajo.
Ilustracin 20: Paquete rtplib.buffer
40 http://java.sun.com/j2se/1.4.2/docs/api/java/util/Comparator.html
74
5.5.3 Implementacin
En la implementacin empezaremos con el resultado del diseo e
implementaremos el sistema en componentes, es decir, ficheros de cdigo fuente, scripts, ficheros de cdigo binario, ejecutables y similares. Los diagramas de secuencia nos permitirn modelar la interaccin entre los objetos del sistema, ordenados de forma temporal. Adems, es til ya que muestran los objetos que se encuentran en el escenario y la secuencia de mensajes intercambiados entre los objetos para llevar a cabo las funcionalidades descritas previamente.
5.5.3.1
Aplanamiento y desaplanamiento
Una de las partes interesantes de la implementacin de la librera RTP es el aplanamiento y desaplanamiento de los paquetes RTP/RTCP. Para cada uno de los paquetes existentes RTCP se tendr una clase para representar dichos paquetes como objetos Java. Estas clases permitirn la fcil gestin de los paquetes RTP/RTCP, adems de realizar acciones sobre estos. Algunas de estas acciones sern: modificar sus campos, crear nuevos paquetes a partir de un conjunto de bytes y viceversa. El proceso de aplanamiento y desaplanamiento, como hemos visto antes, recae de forma conjunta entre las clases de tipo
ByteBuffer
(RtpByteBuffer,
Rtcp[TipoRtcp]ByteBuffer)
y las clases de tipo paquete (RtpPacket y
Rtcp[TipoRtcp]Packet). En el caso de las clases ByteBuffer, se ha decidido que
estas contengan como estructura de almacenamiento un ByteBuffer, estructura proporcionada por Java que permite usar de forma sencilla un conjunto de bytes. Sin embargo, para utilizar este, tipo de estructuras es necesario asignar memoria antes de usarla, y asignar memoria por cada uno de los paquetes recibidos, como se ha comentado, es ineficiente, por lo que se ha optado, en el caso del desaplanamiento, reutilizar objetos ByteBuffer. Con esta misma filosofa, se ha decidido en la implementacin hacer un uso parecido para el caso de el desaplanamiento y reutilizacin de objetos RTP.
75
public RtpPacket unmarshall(RtpPacket packet){ if(packet == null) packet = new RtpPacket(); packet.setAll(this.getSequenceNumber(), this.getSsrc(), this.getTimeStamp(), this.getM(), this.getPt()); return packet; }
Texto 2: Desaplanamiento
En el texto 2 se puede observar el desaplanamiento de un objeto de la clase

RtpByteBuffer, ByteBuffer,
dicho mtodo crear a partir de los datos que tiene en su objeto/paquete RTP. Los mtodos
getSequenceNumber,
un
getSsrc...obtienen del ByteBuffer el campo respectivo:

public int getSequenceNumber() { return 0x0000FFFF & (int)byteBuffer.getShort(2); }
Texto 3: Obtencin de campo numero de secuencia
En el texto 3 se puede observar como se obtienen los campos de un objeto

ByteBuffer. Una vez obtenidos todos los campos, se procede a configurar el paquete
mediante el mtodo setAll de la clase RtpPacket o Rtcp[TipoRtcp]Packet como se puede ver en el texto 4.
public void setAll(int sequenceNumber, long ssrc, long timeStamp, int m, int pt) { this.setSequenceNumber(sequenceNumber); this.setSsrc(ssrc); this.setTimestamp(timeStamp); this.setM(m); this.setPT(pt); }
Texto 4: setAll
5.5.3.2
Recepcin y envo de paquetes RTP sin buffer
Como en una sesin RTP se puede recibir de diferentes fuentes, tener un hilo para cada una de las ellas puede ser ineficiente, por lo que se ha optado por una implementacin en forma de eventos. De esta forma, como se puede observar en el texto 5, cada vez que se reciba un paquete RTP se lanzar un evento (no tendremos un
76
hilo bloqueado esperando recibir) que ejecutar el mtodo processReadEvent, el cual enviar el paquete al receptor final. En este caso al no tener buffer, el envo se hace inmediatamente despus de recibir el paquete.
private void processReadEvent(SelectionKey key) throws IOException { DatagramChannel channel = (DatagramChannel) key.channel(); this.buffer.clear(); InetSocketAddress address = (InetSocketAddress) channel.receive(this.buffer); long time = System.currentTimeMillis(); this.buffer.flip(); RtpPacket packet; if (this.buffer != null) { packet = rtpByteBuffer.getPacket(); if (this.haveBuffer) this.rtpSession.put(packet, channel, address,time); else this.rtpSession.send(packet); try { this.rtpSession.updateRtpStatistics(address, packet, time, channel); } catch (IOException e) { // TODO Auto-generated catch block e.printStackTrace(); } }
}
Texto 5: mtodo processReadEvent
Esta implementacin se ha llevado a cabo gracias a la clase Selector41, que permite seleccionar los canales de los cuales queremos escuchar en caso de que se reciba un paquete RTP tal y como se puede observar en el texto 6. De esta forma, tendremos solo un hilo esperando recibir de mltiples canales, no un hilo por canal. El envo de los paquetes dummy se realizar con un hilo, que despertar despus de un intervalo fijo de tiempo (el mismo con el que deben enviarse los dummies) y enviar a todas las fuentes de video de los terminales Nokia un paquete dummy. Para ello, el hilo debe mantener unas estructuras de datos que permita guardar informacin sobre los paquetes enviados para mantener coherente el numero de secuencia. Las fuentes de audio no necesitan paquetes dummy.
41 http://java.sun.com/j2se/1.4.2/docs/api/java/nio/channels/Selector.html
77
private void receive() throws IOException { this.selector = this.rtpSession.getSelector(); while (!this.rtpSession.getEndSession()) { this.selector.select(); for (SelectionKey key : this.selector.selectedKeys()) { if (key.isReadable()) { processReadEvent(key); } } this.selector.selectedKeys().clear(); } }
Texto 6: Recepcin de paquetes
En la ilustracin 21 podemos observar el diagrama de secuencia correspondiente a las llamadas e intercambio de mensajes que se realizan en la recepcin de un paquete RTP. En este diagrama se detalla claramente como el objeto RtpReceiver al recibir un evento lee del canal que ha provocado dicho evento, desaplana el paquete recibido creando un paquete RTP, para inmediatamente aplanar dicho paquete y enviarlo, adems de actualizar datos y estadsticas de la fuente correspondiente que ha enviado el paquete, datos que sern tiles para mantener el flujo de control RTCP.
78
Ilustracin 21: Recepcin/Envo de RTP
79
5.5.3.3
Envo de paquetes RTP con buffer
En el caso de que se utilice un buffer intermedio, tendremos dos hilos de ejecucin, uno que recibir los paquetes RTP y otro que los enviar. En el caso de este ultimo, es necesario que enve paquetes RTP con un ratio determinado, por lo que se ha optado por implementar el sender con un objeto timer42 de Java. Los objetos timer nos permiten coordinar hilos de ejecucin de forma fcil y precisa. En nuestro caso, el mtodo que mejor se adapta a nuestras necesidades es el scheduleAtFixedRate. Como se observa en el texto 7, este mtodo recibe como parmetros un objeto de tipo
TimerTask43 (en este caso una clase interna llamada sender), la fecha cuando se debe
ejecutar por primera vez (en este caso en el instante 0, es decir, cuanto antes) y el periodo de tiempo que debe pasar hasta que vuelva a ejecutarse, que en este caso ser la llamada al mtodo getTimeWait, que proporcionar el ratio de envo con el que deben ser enviados los paquetes. Esta funcionalidad es implementada por la clase
RtpSender.
protected void send() { Timer timer = new Timer(); timer.scheduleAtFixedRate(new sender(this.rtpSession, this.ssrc), 0, this.getTimeWait()); }
Texto 7: Envio de paquetes
En el siguiente diagrama de secuencia que podemos observar en la ilustracin 22, detalla como la clase RtpSender extrae paquetes del buffer que sean del mismo timestamp y los enva al receptor.
42 http://java.sun.com/j2se/1.5.0/docs/api/java/util/Timer.html 43 http://java.sun.com/j2se/1.5.0/docs/api/java/util/TimerTask.html
80
Ilustracin 22: Envo de paquete RTP con buffer
81
5.5.3.4
Recepcin paquetes RTP con buffer
La recepcin de paquetes con buffer ser igual que sin este, la diferencia es que en lugar de enviar el paquete al recibirlo, se introducir en un buffer. En la ilustracin 23 podemos observar como cuando la clase RtpReceiver recibe un paquete RTP lo introduce en la clase RtpBufferList, y esta a su vez en el buffer correspondiente (video o audio) que estar representado por un objeto RtpBuffer. Sin embargo no se encolan almacenan objetos RtpPacket, sino objetos RtpBufferNode, que sern objetos que adems de contener el objeto de tipo RtpPacket, tendrn informacin til para el correcto ordenamiento de los paquetes dentro del buffer. La clase RtpBuffer almacena los objetos RtpBufferNode en la pila PriorityQueue, detallada previamente, y que como se ha comentado, facilita el proceso de ordenacin.
82
Ilustracin 23: Recepcin de paquetes RTP con buffer
83
5.5.3.5
Recepcin de paquetes RTCP
La recepcin de paquetes RTCP ser anloga a la recepcin de paquetes RTP, es decir, por eventos, con la diferencia de que hay diferentes paquetes de tipo RTCP, se deber actuar de forma diferente segn el tipo de paquete RTCP.
5.5.3.6
Recepcin de paquetes SDES RTCP
Los paquetes SDES contienen informacin relevante y til de las fuentes de las que recibimos el flujo de datos RTP. Cuando se recibe un paquete SDES se debe comprobar que los datos de las fuentes son correctos y actualizarlos en caso contrario. Adems, es posible que cuando se reciba un paquete SDES sea la primera vez que tengamos informacin sobre dicha fuente, por lo que quiz haya que crear las estructuras necesarias para dicha fuente. Al igual que en el caso de recepcin de paquetes RTP, se ha optado por una recepcin de paquetes basada en eventos, con la diferencia de que ahora podremos recibir paquetes de diferentes tipos (todos los tipos que hay de paquetes RTCP). As, como se puede observar en el texto 8, cuando se recibe un paquete RTCP se debe comprobar que tipo de paquete es antes de desaplanarlo. La funcin
getPt
que se realiza sobre un objeto
RtcpByteBuffer
nos
permite acceder al tipo de paquete RTCP recibido, devolviendo un entero con el numero correspondiente. A diferencia del mtodo processReadEvent de la versin para la recepcin de paquetes RTP, se tendr que tratar de forma especial el paquete RTCP ya que los paquetes RTCP pueden ser compuestos; es decir, constar de varios paquetes en un solo paquete UDP.
84
private void processReadEvent(SelectionKey key) throws IOException { DatagramChannel channel = (DatagramChannel)key.channel(); this.buf.clear(); channel.receive(this.buf); this.buf.flip(); int pt = 0; if (this.buf != null) { int size = this.buf.limit(); int offset = 0; int length = 0; byte [] buffer; do { pt = RtcpByteBuffer.getPt(offset, this.buf); length=(RtcpByteBuffer.getLength(offset,this.buf)+1)*4; buffer = RtpUtils.get(length, offset, this.buf); this.actionPt(ByteBuffer.wrap(buffer), pt, channel); offset += length; size -= length; } while (size >= 8); } }
Texto 8: Recepcin de paquetes RTCP
Como se puede observar en el texto 8, cuando sabemos que tipo de paquete RTCP se ha recibido se llama al mtodo actionPt, que realizar las acciones oportunas segn el paquete RTCP recibido, tal y como podemos observar en la implementacin de este mtodo que se encuentra en el texto 9.
85
private void actionPt(ByteBuffer rcvByteBuffer, int pt, DatagramChannel channel) { switch (pt) { case RtcpPacket.SR: this.rtcpSession.updateSRStatistics((RtcpSRPacket) this.rtcpSR.getPacket(), channel); break; case RtcpPacket.RR: this.rtcpSession.updateRRStatistics((RtcpRRPacket) this.rtcpRR.getPacket()); break; case RtcpPacket.SDES: this.rtcpSession.setSource((RtcpSDESPacket) this.rtcpSdes.getPacket(), channel); break; case RtcpPacket.BYE: this.rtcpSession.removeSource((RtcpByePacket) this.rtcpBye.getPacket()); this.rtcpSession.setEndSession(true); break; case RtcpPacket.APP: this.rtcpSession.setApp((RtcpAppPacket) this.rtcpApp.getPacket(), channel); break; default: break; } }
Texto 9: Recepcin de paquetes RTCP
Por ultimo cabe sealar la implementacin del desaplanado de los Chunk tal y como se puede observar en el texto 10. Los paquetes SDES contienen a su vez varios
Chunk, por lo que hay que tener especial cuidado al desaplanar estos paquetes y
asegurarse de que son todos convertidos de forma correcta en objetos de tipo Chunk, contenidos a su vez en un objeto de tipo RtcpSDESPacket.

for (Chunk chunk : chunks) { if (!this.sources.containsKey(chunk.getRc())) this.sources.put(chunk.getRc(), new MediaSource(this, chunk.getRc(), isVideo)); }
86
Texto 10: Desaplanamiento de Chunks
En la ilustracin 24 podemos observar el proceso seguido cuando se recibe un paquete RTCP de tipo SDES. Una vez que se ha desaplanado el paquete SDES, en caso de que no exista la fuente descrita por el paquete en la sesin RTP gobernada por la clase RtpSession, se proceder a crear un nuevo MediaSource, si no es as, simplemente se actualizarn datos de dicho MediaSource que representa al flujo de media entrante.
Ilustracin 24: Recepcin paquetes SDES RTCP
5.5.3.7
Recepcin de paquetes SR/RR RTCP
En el caso de la recepcin de paquetes Sender Report o Receiver Report, se actualizarn estadsticas. Como se ve en el texto 11, la implementacin de actualizacin de estadsticas para cuando se ha recibido un paquete SR consiste en actualizar valores de tiempo como el NTP y los timestamps.
87
public void updateSRStatistics(RtcpSRPacket packet, DatagramChannel channel) { long ssrc = packet.getSsrc(); boolean isVideo = channel.equals(this.originChannelV); long lastNtp = packet.getNtpTimeStamp0(); long lastTs = packet.getRtpTimeStamp(); MediaSource media = this.rtpSession.getSource(ssrc, isVideo); long ts = this.calculateTimeStamp(media); media.update(lastNtp, lastTs, ts); }
Texto 11: Actualizacin de estadsticas
Como se puede puede observar en la ilustracin 25, cuando se recibe un paquete RTCP SR/RR tras desaplanarlo se procede a actualizar las estadsticas de la sesin RTCP, cuyos datos estn contenidos en un objeto RtcpSession, y esta a su vez actualizar los datos de los MediaSource.
Ilustracin 25: Recepcin de paquetes SR/RR RTCP
88
5.5.3.8
Recepcin paquete BYE RTCP
Los paquetes BYE informan de que uno de los participantes dejan de formar parte de la conexin, por lo que bsicamente, ser eliminar la fuente de la tabla hash. En la ilustracin 26 se puede observar como cuando el objeto RtcpReceiver recibe un paquete de este tipo elimina la fuente de la sesin RTP, adems de cerrar la conexin con dicha fuente, por lo que se proceder a cerrar el canal por el cual se reciba el flujo de datos.
Ilustracin 26: Recepcin paquetes BYE RTCP
5.5.3.9
Retrasos en el Buffer
Debido a que los medias de vdeo y audio pueden llegar desincronizados, el buffer debe ser capaz de absorber los retrasos y coordinarlos. As, en caso de que el audio sea el retrasado, se deben tirar paquetes de vdeo y almacenar de audio, y viceversa para el caso del vdeo. Para ello utilizaremos un buffer para cada uno de los flujos, y cada uno de los buffers se configurar de forma que al inicio tirar paquetes o los almacenar. Como podemos ver en el texto 15, la configuracin de estos buffer es fcil, ya que
89
dichos retrasos sern pasados por parmetros en el constructor de la sesin RTP. La configuracin de los buffer se detallar en la API.
90
5.6 Pruebas
En este apartado se mostrar las diferentes pruebas realizadas para verificar que la librera cumple los requisitos especificados y el resultado de la implementacin, probando cada construccin, incluyendo tanto construcciones internas como intermedias, as como las versiones finales del sistema a ser entregadas a terceros.
5.6.1 Prueba 1: Aplanamiento y Desaplanamiento

La primera prueba realizada tendr como objetivo comprobar si el aplanamiento y desaplanamiento de todos los paquetes, tanto RTP como RTCP se realiza de forma correcta, siendo una prueba valida para verificar el requisito 1. Como se puede observar en la ilustracin 27, la prueba consistir en crear una sencilla aplicacin Java, con una parte emisora y otra receptora de paquetes UDP. La parte emisora crea objetos RTP y RTCP (numero 1 en la ilustracin 27) de todos sus tipos, aplana dichos objetos convirtindolos en una secuencia de bytes que se enviar de forma local a la misma aplicacin Java, que al recibir el conjunto de bytes (numero 2 en la ilustracin 27) los enviar por la red para permitir el anlisis mediante Wireshark a la parte receptora de la aplicacin/prueba (numero 4 de la ilustracin 27). La parte receptora desaplanar los ByteBuffer y crear el objeto resultante (nmeros 5 y 6 en la ilustracin 27). Se deben comprobar dos detalles: 1. Que los datos del objeto aplanado recibido sean iguales que el enviado 2. Que Wireshark reconozca de forma fiel los paquetes RTP y RTCP. Si la librera supera esta prueba, se puede aceptar con cierta fiabilidad que el aplanamiento y desaplanamiento funcionan de forma correcta, sin embargo, pruebas futuras descritas ms adelante se cerciorarn del correcto funcionamiento de estas funcionalidades. Debido a la peculiaridad comentada en la implementacin de que Java no posee tipos sin signo, tambin se debe comprobar los valores lmite de los campos de cada paquete para que al desaplanarlo no obtengamos nmeros negativos, por lo tanto los campos sern configurados con valores lo suficientemente altos para
91
que sea un nmero negativo en caso de que el desaplanamiento no funcione. Adems, existen paquetes como los Sender Report y Receiver Report que pueden llevar un numero determinado de Report Blocks, por lo que se debe comprobar que se aplanan correctamente un numero alto de dichos bloques.
Ilustracin 27: Prueba 1: Aplanamiento y desaplanamiento de paquetes
5.6.2 Prueba 2: Envo y Recepcin con los Nokia

Como se ha especificado en los requisitos, algunos mviles, como el Nokia N73, necesitan que se les enve determinados paquetes RTP de vuelta (paquetes dummy), por lo que esta prueba verifica si el envo y recepcin desde un dispositivo real funciona, verificando los requisitos 3, 4, 7, 8, 9, 10 y 11: Para comprobar esta funcionalidad, se construy una infraestructura anloga a la que se puede observar en la ilustracin 28, que permitiese una conexin entre la librera y el mvil a travs del Asterisk; una vez que la librera reciba los paquetes RTP, se reenviaban a una aplicacin VLC para comprobar su correcta visualizacin. Adems, con esta infraestructura se permite tambin verificar la prueba anterior de
92
aplanadores y desaplanadores y una nueva funcionalidad, la retro alimentacin de informacin a travs de paquetes RTCP al emisor del flujo (el terminal mvil). Para ello el mvil deba ser configurado para enviar el flujo de datos contra el enlace, en este caso el Asterisk, y a su vez configurar la librera para recibir dicho flujo de datos reenviados por el mismo Asterisk y viceversa, que el propio Asterisk reenve los paquetes tanto RTP (dummies) como los RTCP al mvil. Adems, se debe comprobar que la inclusin de la librera no provoca impedimentos ni fallas de sincrona, por lo que tambin se realizaron pruebas en este mbito.
Ilustracin 28: Prueba 2
93
5.6.3 Prueba 3: Uso del buffer

Finalmente, la ultima prueba es comprobar los requisitos 2, 5, 6 y12. La infraestructura para esta prueba se puede observar en la ilustracin 29; consistir en dos aplicaciones VLC ejecutando de forma local, una enviando vdeo y otra recibiendo. De esta forma, se podr probar si la el scheduler de la librera funciona eficazmente, si ordenamos paquetes de forma correcta y si la librera es capaz de simular y absorber retrasos, en definitiva, probar la funcionalidad del buffer.
Ilustracin 29: Prueba 3
94
5.7 API y Tutorial de Uso

La API en una librera es una parte importante en la descripcin informtica, ya que indicar a los desarrolladores como utilizar de forma correcta y eficiente dicha librera. Para ello se usa una utilidad que proporciona Sun para la generacin de documentacin de APIs en formato HTML a partir del cdigo Java, el conocido Javadoc44. Adems, se detallar ejemplos tiles a continuacin.
5.7.1 Aplanamiento y desaplanamiento

El desarrollador dispone, para aplanar y desaplanar los paquetes dos tipos de clases, las cuales las llamaremos clases ByteBuffer y clases que llamaremos aunque dichas clases no existan como tal en la implementacin. Las clases Packet son RtpPacket y Rtcp[TipoRtcp]Packet. De esta forma, cuando se quiera crear un paquete (conjunto de bytes) a partir de un objeto, estas clases proporcionarn el aplanador correspondiente. Para desaplanar un paquete tendremos que llamar al mtodo marshall que recibe como parmetro un
ByteBuffer (por reutilizacin) y devuelve un ByteBuffer con el conjunto de bytes
Packet,
en el formato definido en la RFC. Un ejemplo se puede observar en el texto 12, donde creamos valores artificiales y mediante el constructor del objeto creamos un objeto
RtpPacket, despus llamamos a la funcin marshall.
Las
clases
de
tipo
ByteBuffer
son
RtpByteBuffer
Rtcp
[TipoRtcp]ByteBuffer. Dichas clases, nos permiten desaplanar un conjunto de bytes
y convertirlos en un objeto mediante el mtodo getPacket que devolver un objeto Java de tipo Packet con los datos contenidos en el ByteBuffer. En el texto 13 se puede observar un ejemplo donde creamos un ByteBuffer, al igual que antes con valores artificiales y llamamos al mtodo getPacket que proporciona el paquete
RtPacket.
44 http://java.sun.com/j2se/javadoc/
95
As, el uso de estas clases ser el siguiente: 1. Desaplanamiento: 1.1. Se recibe un conjunto de bytes (se explica ms adelante como recibe) de una fuente determinada. 1.2. Con dichos bytes, dependiendo de si se ha recibido un paquete RTP o RTCP se crear un paquete de tipo ByteBuffer correspondiente. 1.3. Con el objeto RtpByteBuffer creado, se podr extraer a travs del mtodo
getPacket el objeto de tipo RtpPacket.
ByteBuffer byteBuffer = ByteBuffer.allocateDirect(1024); byteBuffer.put(firstByte); byteBuffer.put(secondByte); byteBuffer.putShort((short) sequenceNumber); byteBuffer.putInt((int) timestamp); byteBuffer.putInt((int) ssrc); byteBuffer.putInt((int) csrcs[0]); byteBuffer.putShort((short) ehpsd); byteBuffer.putShort((short) ehl); byteBuffer.put(ehData); byteBuffer.put(data); byteBuffer.flip(); RtpByteBuffer rtpbb = new RtpByteBuffer(byteBuffer); rtpbb.getPacket();
Texto 12: Desaplanamiento de ByteBuffer
2. Aplanamiento: 2.1. Una vez tengamos un objeto de tipo RtpPacket o Rtcp[TipoRtcp]

Packet, creamos un objeto Java ByteBuffer.
2.2. Utilizamos el mtodo marshall de la clase RtpPacket obteniendo un objeto ByteBuffer con el conjunto de bytes que sern enviados por la red.

int ver = 2; int p = 0; int x = 1; int cc = 1; int m = 0; int pt = 2; int sequenceNumber = 1; long timestamp = 8; long ssrc = 32; long[] csrcs = new long [1]; csrcs[0] = 345; int ehpsd = 23; int ehl = 4; byte[] ehData = new byte [32]; for (int i = 0; i < ehData.length; i++) ehData [i] = (byte) i; byte [] data = new byte[4]; for (int i = 0; i <data.length; i ++) data [i] = (byte) i; byte firstByte = (byte) ((ver << 6) | (p << 5) | (x << 4) | cc); byte secondByte = (byte) ((m << 7) | pt); RtpPacket rtpPacket = new RtpPacket(firstByte, secondByte, sequenceNumber, timestamp, ssrc, csrcs, ehpsd, ehl, ehData, data); ByteBuffer bb = rtpPacket.marshall(null);
96
Texto 13: Aplanamiento de paquete RTP/RTCP
5.7.2 Inicio de sesiones

La sesin RTP ser el ncleo de la librera, servir para aadir nuevas fuentes, sincronizarlas, crear los hilos necesarios e implementar el envo y recepcin de informacin a bajo nivel, ya que se encargar de la gestin de los canales, aunque las clases RtpReceiver, RtcpReceiver, RtpSender y RtcpSender sern las encargadas de la gestin a alto nivel del envi y recepcin de paquetes. Para iniciar una sola sesin de RTP, tendremos que utilizar uso de algunos de los diferentes constructores que existen. El constructor de la clase RtpSession recibe como parmetros obligatorios:

localAddress: la direccin local. inputPortV, inputPortA: puertos en los que la librera recibir el vdeo y
97
audio respectivamente.
outputPortV, outputPortA: puertos en los que la librera enviar el vdeo y
audio.
remotePortV, remotePortA: puertos de la aplicacin emisora desde donde se
enviarn loas paquetes RTP. Estos puertos son necesarios para el envo de paquetes de vuelta, como los paquetes de control RTCP y o los paquetes RTP vacos dummies .
dummyInterval: intervalo de tiempo en milisegundos que pasar entre
paquetes RTP dummy enviados.

dummyPayloadType: tipo del paquete dummy. cname: cadena de caracteres con el nombre cannico que tendr la sesin RTP. haveRtcpSession: variable booleana que indicar si la sesin RTP se iniciar
con control de paquetes (RTCP). Adems, otros constructores podrn tener otras parmetros interesantes como:
delayMillis, delayPackets: retraso con el que tendr que iniciar la emisin
de datos por parte de la librera, en milisegundos o paquetes respectivamente.
isSynchronized: parmetro que indica si ambos flujos (audio y vdeo) deben
ser sincronizados por la librera.
millisVideo, millisAudio: parmetros que indicarn si el flujo de vdeo o
audio llegar a la librera con un retraso respecto al otro flujo. Es decir, si el parmetro millisVideo es positivo, se referir a los milisegundos que se deben almacenar en el buffer para sincronizarse con el flujo de audio. Sin embargo, si el parmetro es negativo, el numero de paquetes correspondientes a dichos milisegundos debern ser tirados al inicio de la conexin (no se almacenarn ni se reenviarn). El clculo para realizar la conversin entre milisegundos a paquetes es descrita ms adelante.
packetsVideo, packetsAudio: anlogo al anterior, pero con paquetes en lugar
de milisegundos. En el texto 14 podemos observar un ejemplo en el que iniciamos una sesin RTP.

public static void main (String args[]) { InetAddress localHost; try { localHost = InetAddress.getByName("localhost"); int inputPortV = 10022; int inputPortA = 10032; int outputPortV = 10024; int outputPortA = 10034; int remotePortV = 10026; int remotePortA = 10016; long millis = 5000; boolean isSynchronized = true; boolean haveRtcpSession = true; RtpSession rtpSession = new RtpSession(localHost, inputPortV, inputPortA, outputPortV, outputPortA, localHost, remotePortV, remotePortA, 1, 1, "", !haveRtcpSession, millis, isSynchronized); rtpSession.start(); } catch (UnknownHostException e) { e.printStackTrace(); } catch (IOException e) { e.printStackTrace(); }
98
Texto 14: Creacin de sesin RTP
5.7.3 Buffers
Los buffers se pueden crear para diferentes propsitos como hemos visto anteriormente, siendo los parmetros de este constructor los siguientes:
capacity: Establece la capacidad mxima que tendr la lista con la que opera
el buffer.
comparator: Objeto que se encargar de ordenar los paquetes dentro del buffer,
ser del tipo Comparator, antes expuesto.
minSize,
maxSize:
tamaos
mximo
mnimos
(usados
para
la
sincronizacin).
ssrc: identificador de los paquetes que almacenar el buffer.
El buffer tendr mtodos para extraer los paquetes del buffer, aunque siempre se extraern los paquetes que sean del mismo instante de reproduccin (timestamp
99
iguales). El buffer al actuar como una cola ordenada, extraer los paquetes con menor timestamp, los mtodos para extraer paquetes e introducir un paquete en el buffer son:
take:
No
recibe
parmetros,
devuelve
una
lista
de
tipo
ArrayList45<RtpPacket>, con los paquetes con menor e igual timestamp del
buffer.
put: Recibe como parmetro un objeto de tipo RtpPacket, que ser el paquete
que se introducir de forma ordenada en el buffer. Adems, la clase buffer ofrece mtodos para poder manejar el contenido. Estos mtodos auxiliares son:
isEmpty: No recibe parmetros, devuelve un tipo primitivo boolean, True si el
buffer est vaco, False en caso contrario.
size: No recibe parmetros, devuelve un tipo primitivo int con el numero de
paquetes en el buffer.
getDiffTs: No recibe parmetros, devuelve un tipo primitivo long con el ratio de del timestamp de los paquetes correspondientes contenidos en el buffer. Se podr configurar en el buffer mediante el mtodo configure de la clase
RtpBufferList. Este mtodo, a su vez, llamar al mtodo configure de la clase RtpBuffer, cuya implementacin se puede observar en el texto 16. De esta forma,
quedar establecido en el buffer cuantos paquetes debe tirar y cuantos debe almacenar al inicio de la conexin. Un ejemplo de configuracin y utilizacin de este buffer se puede observar en los textos 15 y 16.
45 http://java.sun.com/j2se/1.5.0/docs/api/java/util/ArrayList.html

public void configure(int delayVideo, int delayAudio) { long pStore = 0; long pThrow = 0; if (delayVideo > 0) pStore = delayVideo; else pThrow = -delayVideo; this.video.configure(pStore, pThrow); pStore = 0; pThrow = 0; if (delayAudio > 0) pStore = delayAudio; else pThrow = -delayAudio; this.audio.configure(pStore, pThrow); }
100
Texto 15: Configuracin del buffer

public void configure(long pStore, long pThrow) { this.packetStore = pStore; this.packetThrow = pThrow; this.minSize = (int) pStore; }
Texto 16: Configuracin del buffer
5.7.4 Channels
La configuracin de los canales es una parte importante de la librera, pues el correcto y eficiente funcionamiento del envo y recepcin de datos depende de ello. La librera proporciona el mtodo configureChannel que permite configurar un canal listo para recibir y enviar datos. Como se puede observar en el texto 17, este mtodo recibe dos parmetros:
address: objeto Java InetSocketAddress46, contiene toda la informacin
(direccin IP y puerto) que se necesita para que el canal pueda recibir y enviar datos a dicha direccin.
blocking: tipo primitivo boolean que establece si el canal ser bloqueante o
no. Esto es debido a que los canales de recepcin sern no bloqueantes pero los de envo sern bloqueantes.
46 http://java.sun.com/j2se/1.5.0/docs/api/java/net/InetSocketAddress.html
101
public static DatagramChannel configureChannel(InetSocketAddress address, boolean blocking) throws IOException { DatagramChannel channel = DatagramChannel.open(); channel.configureBlocking(blocking); DatagramSocket socket = channel.socket(); socket.bind(address); socket.setReuseAddress(true); socket.setSendBufferSize(SO_UDP_BUFFER_SIZE); socket.setReceiveBufferSize(SO_UDP_BUFFER_SIZE); return channel; }
Texto 17: Configuracin de canales
CAPTULO 6.
CONCLUSIONES Y TRABAJOS FUTUROS

6.1 Conclusiones
Como se ha descrito a lo largo del desarrollo del proyecto, los requisitos y objetivos que se plantearon al inicialmente se han cumplido con xito. Tras la finalizar el proyecto, se puede comprobar el cumplimiento de los objetivos marcados al comienzo del mismo. El resultado: una librera fiable, con capacidad de integracin en otros sistemas y facilidad de uso. Adems, la librera ha sido probada e integrada satisfactoriamente en la empresa Solaiemes, colaboradora de la Universidad Rey Juan Carlos.
6.2 Conocimientos adquiridos

Los conocimientos que he adquirido con la realizacin de este proyecto son los siguientes:
Aprendizaje del lenguaje de programacin Java: algunos aspectos como el control de Threads o la clase ByteBuffer no se conocan con anterioridad. Aprendizaje de realizacin de una librera: La creacin de esta librera ha ayudado a saber como se realiza una librera correctamente. Aprendizaje de implementacin de protocolos: Anlogo al punto anterior, pero en este caso, con protocolos de comunicacin en stream (el RTP).
102
CAPTULO 6. CONCLUSIONES Y TRABAJOS FUTUROS
103
Tecnologa SIP: Al haber usado en las pruebas negociacin SIP para la videollamada, he tenido que aprender algunos aspectos de esta protocolo, como mensajes o la semntica. Configuracin de aplicaciones: Como el VLC o X-Lite.
6.3 Trabajos Futuros:

Durante el desarrollo de la librera, tanto las necesidades descubiertas como las alternativas existentes han hecho posible que se pueda recoger algunas ideas que podran servir de base de futuros proyectos. Algunos de ellos son:
Crear nuevos mdulos, al igual que se han creado los modulo de envo y recepcin de la red, se pueden realizar mdulos de lectura y escritura en ficheros, u otros mdulos que cumplan un patrn productor-consumidor. Integracin de la librera con libreras de cdecs que permitan la fcil codificacin entre diferentes tipos de vdeo o audio.
APNDICE A CONFIGURACIN DE VLC Y X-LITE

VLC
En las pruebas que se utilice la aplicacin VLC, se lanzarn desde la linea de comandos y leern un fichero en formato SDP. Dicho fichero deber llevar datos sobre el emisor, los puertos de escucha y los cdecs. v=0 o=user 0 0 IN IP4 127.0.1.1 s=t=0 0 m=video 10018 RTP/AVP 96 c=IN IP4 127.0.0.1 a=rtpmap:96 H263-1998/90000 a=control:rtsp://127.0.0.1/DestinationFor-RtpSender-2/trackID=0 m=audio 10016 RTP/AVP 97 c=IN IP4 127.0.0.1 a=rtpmap:97 AMR/8000 a=fmtp:97 octet-align=1 a=control:rtsp://127.0.0.1/DestinationFor-RtpSender-2/trackID=1
Texto 18: Configuracin VLC para Prueba 3
104
En este caso, el cdigo es para la Prueba 3, por lo que las direcciones son todas locales, ya que se recibir de la propia maquina. En caso de la instancia emisora, se introducen los parmetros por linea de comandos. /opt/vlc/bin/vlc Shrek3.3gp --sout "#rtp{dst=localhost,port-video=10018,portaudio=10016,octect-align}" -vvv
Texto 19: Parmetros por linea de comando del emisor
X-Lite
La aplicacin X-Lite debe ser configurada de la siguiente forma: Se debe crear al menos una cuenta con los datos necesarios: dichos datos sern: Display Name: nombre del usuario, puede ser cualquiera, a eleccin del usuario. User Name: nombre del usuario que se registrar en la sesin SIP, debe ser proporcionado por el proveedor. Authorization user name: datos proporcionados por el proveedor. Domain: direccin Ip y puerto contra el que se iniciar la aplicacin X-Lite.
BIBLIOGRAFA
[1] Colin Perkins. RTP: Audio and Video for the Internet. Addison-Wesley Professional, 2003
[2] Ivar Jacobson, Grady Rumbaugh, Grady Booch. El proceso unificado de desarrollo. Addison Wesley, 2001
[3] Librera ortp: http://www.linphone.org/index.php/eng/code_review/ortp
[4] Librera JRTPLIB: http://research.edm.uhasselt.be/~jori/page/index.php?n=CS.Jrtplib
106

RtpLib - Una Librería en Java de Los Protocolos RTP y RTCP (2008-2009)

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

RtpLib - Una Librería en Java de Los Protocolos RTP y RTCP (2008-2009)

Cargado por

Copyright:

Formatos disponibles

INGENIERA INFORMTICA Curso Acadmico 2008/2009 Proyecto de Fin de Carrera

RtpLib: Una librera en Java de los protocolos RTP y RTCP

A David, Armando y ngel, por compartir estos inolvidables aos .

Y a mi familia, por apoyarme incondicionalmente.

la transmisin de datos multimedia en dicha empresa.

1.1 Nuevas formas de comunicacin

1.1.1 Un poco de Historia

1.1.2 Requisitos del transporte de voz y vdeo sobre paquetes en redes

1.1.3 Beneficios del vdeo y audio basado en paquetes

Definicin de aplanamiento: proceso por el cual una estructura de datos se

11 Apuntes RedesII: Luis Lpez Fernndez

transforma en una secuencia de bits siguiendo un conjunto de reglas de codificacin predefinido.

CONTEXTO Y MARCO DE TRABAJO

CAPTULO 3. CONTEXTO Y MARCO DE TRABAJO

3.1.1 Conceptos Bsicos

CAPTULO 3. CONTEXTO Y MARCO DE TRABAJO

13 http://en.wikipedia.org/wiki/H.261 14 http://en.wikipedia.org/wiki/H.263 15 http://es.wikipedia.org/wiki/Flash_Video

CAPTULO 3. CONTEXTO Y MARCO DE TRABAJO

3.1.2 Transmisin de datos

CAPTULO 3. CONTEXTO Y MARCO DE TRABAJO

3.2 Protocolos de sealizacin

CAPTULO 3. CONTEXTO Y MARCO DE TRABAJO

CAPTULO 3. CONTEXTO Y MARCO DE TRABAJO

CAPTULO 3. CONTEXTO Y MARCO DE TRABAJO

CAPTULO 3. CONTEXTO Y MARCO DE TRABAJO

Ilustracin 1: Imagen de la aplicacin X-Lite

3.4.3 Reproductor multimedia VLC

CAPTULO 3. CONTEXTO Y MARCO DE TRABAJO

CAPTULO 3. CONTEXTO Y MARCO DE TRABAJO

Ilustracin 2: Logotipo de la aplicacin VLC

3.4.4 Dispositivos mviles usados

CAPTULO 3. CONTEXTO Y MARCO DE TRABAJO

3.5 Entorno y Herramientas

CAPTULO 3. CONTEXTO Y MARCO DE TRABAJO

3.5.2 Sistema operativo, Ubuntu 7.04

3.5.3 Entorno de desarrollo Eclipse:

CAPTULO 3. CONTEXTO Y MARCO DE TRABAJO

Examinar el intercambio de mensajes RTP/RTCP: Esto incluye tanto el anlisis

CAPTULO 3. CONTEXTO Y MARCO DE TRABAJO

Ilustracin 3: Logotipo de la aplicacin Wireshark

3.5.5 Gestor de versiones SVN

CAPTULO 3. CONTEXTO Y MARCO DE TRABAJO

3.6 Infraestructura del sistema

Ilustracin 4: Infraestructura del sistema

CAPTULO 3. CONTEXTO Y MARCO DE TRABAJO

Ilustracin 5: Infraestructura del sistema con la librera RtpLib

CAPTULO 3. CONTEXTO Y MARCO DE TRABAJO

EL PROTOCOLO RTP: ESPECIFICACIN

CAPTULO 4. EL PROTOCOLO RTP: ESPECIFICACIN

4.1.1 Escenarios de uso

CAPTULO 4. EL PROTOCOLO RTP: ESPECIFICACIN

4.2 La sesin RTP

CAPTULO 4. EL PROTOCOLO RTP: ESPECIFICACIN

Ilustracin 6: Mezclador M ve todas las fuentes como fuentes de sincronizacin; otros

CAPTULO 4. EL PROTOCOLO RTP: ESPECIFICACIN

4.2.2 Multiplexando Sesiones RTP

4.3 El protocolo de control de RTP: RTCP

CAPTULO 4. EL PROTOCOLO RTP: ESPECIFICACIN

4.3.1 Reglas de timing

4.3.2 Intervalo de informe

CAPTULO 4. EL PROTOCOLO RTP: ESPECIFICACIN

4.3.3 Paquetes Compuestos

CAPTULO 4. EL PROTOCOLO RTP: ESPECIFICACIN