RtpLib - Una librería en Java de los protocolos RTP y RTCP (2008-2009)

INGENIERÍA INFORMÁTICA

Curso Académico 2008/2009

Proyecto de Fin de Carrera

RtpLib:

Una librería en Java de los protocolos RTP y RTCP

Autor: Luis Fernando García Antúnez

Tutor: Luis López Fernández

Cotutor: Micael Gallego Carrillo

II

Agradecimientos

A David, Armando y Ángel,

por compartir estos inolvidables años .

Y a mi familia, por apoyarme incondicionalmente.

III

Resumen

Actualmente estamos viviendo una etapa de desarrollo creciente de Internet

y surgimiento de nuevas tecnologías que proporcionan a los dispositivos

móviles capacidad de transmisión de audio y video. Todas estas tecnologías y

formas de comunicación se basan en protocolos de transmisión de datos

multimedia que debido su complejidad, es común que gran parte del esfuerzo

en la construcción de aplicaciones software sea la implementación de dichos

protocolos. Uno de los protocolos más usados para la comunicación de audio y

video en tiempo real es el protocolo RTP, basado en la transmisión de mensajes

sobre redes IP. En este proyecto se plantea como objetivo la implementación de

una librería del protocolo RTP que permita, de forma flexible, rápida 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 librería implementada en el lenguaje de programación Java,

que permite usar flujos de video/audio basados en RTP. Además, esta librería

ofrece compatibilidad con determinados dispositivos móviles Nokia e

implementación del protocolo de control RTCP, permitiendo mantenimiento de

la conexión. En definitiva una librería fiable, con capacidad de integración en

otros sistemas y facilidad de uso; como prueba de ello, la librería ha sido

probada e integrada satisfactoriamente en la empresa Solaiemes, colaboradora

de la Universidad Rey Juan Carlos.

IV

Indice

1. INTRODUCCIÓN................................................................................................10 1.1 Nuevas formas de comunicación..............................................................12

1.1.1 Un poco de Historia...........................................................................12

1.1.2 Requisitos del transporte de voz y vídeo sobre paquetes en redes....12

1.1.3 Beneficios del vídeo y audio basado en paquetes.............................14

2. OBJETIVOS......................................................................................................15 3. CONTEXTO Y MARCO DE TRABAJO.................................................................17

3.1 Tecnologías de Media...............................................................................17

3.1.1 Conceptos Básicos.............................................................................18

3.1.2 Transmisión de datos.........................................................................20

3.2 Protocolos de señalización.......................................................................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 móviles usados.............................................................27

3.5 Entorno y Herramientas............................................................................28

3.5.1 Lenguaje de Programación: Java.......................................................28

V

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: ESPECIFICACIÓN...........................................................35 4.1.1 Escenarios de uso..............................................................................36

4.2 La sesión 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 sintácticos 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. DESCRIPCIÓN INFORMÁTICA............................................................................52 5.1 Descripción de la metodología empleada.................................................52

5.1.1 El proceso unificado de desarrollo....................................................52

5.2 Planificación.............................................................................................55

5.2.1 Objetivos parciales necesarios para alcanzar el objetivo final..........55

5.2.2 Descripción de las etapas que se seguirán en el desarrollo...............55

5.3 Especificación de requisitos.....................................................................57

5.3.1 Propósito............................................................................................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 Análisis.............................................................................62

5.4.1 Diagramas de colaboración...............................................................63

5.5 Diseño.......................................................................................................66

5.5.1 Decisiones de Diseño........................................................................66

5.5.2 Diagramas de clases de diseño..........................................................69

5.5.3 Implementación.................................................................................74

5.6 Pruebas.....................................................................................................90

5.6.1 Prueba 1: Aplanamiento y Desaplanamiento.....................................90

5.6.2 Prueba 2: Envío y Recepción 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

APÉNDICE A.....................................................................................................104 VLC...............................................................................................................104

X-Lite............................................................................................................105

BIBLIOGRAFÍA...................................................................................................106

VII

Índice de ilustraciones

Ilustración 1..........................................................................................................................26

Ilustración 2..........................................................................................................................28

Ilustración 3..........................................................................................................................32

Ilustración 4..........................................................................................................................33

Ilustración 5..........................................................................................................................34

Ilustración 6..........................................................................................................................39

Ilustración 7..........................................................................................................................45

Ilustración 8..........................................................................................................................48

Ilustración 9..........................................................................................................................50

Ilustración 10........................................................................................................................51

Ilustración 11........................................................................................................................52

Ilustración 12........................................................................................................................52

Ilustración 13........................................................................................................................63

Ilustración 14........................................................................................................................64

Ilustración 15........................................................................................................................65

Ilustración 16........................................................................................................................66

Ilustración 17........................................................................................................................71

Ilustración 18........................................................................................................................71

Ilustración 19........................................................................................................................73

Ilustración 20........................................................................................................................74

Ilustración 21........................................................................................................................79

Ilustración 22........................................................................................................................81

VIII

Ilustración 23........................................................................................................................83

Ilustración 24........................................................................................................................87

Ilustración 25........................................................................................................................88

Ilustración 26........................................................................................................................89

Ilustración 27........................................................................................................................92

Ilustración 28........................................................................................................................93

Ilustración 29........................................................................................................................94

IX

CAPÍTULO 1.

INTRODUCCIÓN

En el ámbito de la programación, una librería (también llamada biblioteca) es una

colección de subrutinas o clases usadas para desarrollar software. Las librerías

contienen código y datos que proveen servicios para programas independientes. Esto

permite que el código y los datos sean compartidos y modificados de forma modular.

El objetivo de este Proyecto de Fin de Carrera es analizar, diseñar e implementar

una librería para el protocolo RTP/RTCP que permita la utilización 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 aplicación utilizado

para la transmisión de información en tiempo real como por ejemplo audio y vídeo

sobre redes IP -Internet-. Está desarrollado por el grupo de trabajo de transporte de

Audio y Vídeo del IETF (Internet Engineering Task Force1). Es frecuentemente usado

junto el protocolo de control RTCP (RTP Control Protocol) y se sitúa 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 envío de datagramas a

través de la red sin que se haya establecido previamente una conexión, a diferencia de

TCP4. Tampoco tiene confirmación, 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 http://www.ietf.org/2 http://es.wikipedia.org/wiki/Capa_de_aplicaci%C3%B3n#Capa_de_aplicaci.C3.B3n_.28Capa_7.293 http://es.wikipedia.org/wiki/UDP4 http://es.wikipedia.org/wiki/TCP

10

CAPITULO 1: INTRODUCCIÓN 11

no hay confirmación de entrega o de recepción, aunque por otra parte ofrece una

latencia muy baja.

Para analizar e implementar la librería 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

ambigüedades. 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 estándar de

Internet. Cada RFC tiene un título y un número 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 amplían. Existen varias categorías, pudiendo ser informativos

(cuando se trata simplemente de valorar por ejemplo la implantación de un protocolo),

propuestas de estándares nuevos, o históricos (cuando quedan obsoletos por versiones

más modernas del protocolo que describen). El protocolo RTP fue publicado por

primera vez como estándar en 1996 como la RFC 18896, y actualizado posteriormente

en 2003 en la RFC 35507, que constituye el estándar de Internet STD 64. Aunque

inicialmente RTP se publicó como protocolo multicast8 (que es el envío de la

información en una red a múltiples destinos simultáneamente), también se ha usado en

varias aplicaciones unicast9 (envío de información desde un único emisor a un único

receptor), siendo el objetivo de esta practica una implementación unicast. La finalidad

de esta librería es ayudar a los programadores a poder desarrollar aplicaciones que

transmitan datos multimedia, como vídeo o audio a través de la red; la librería

desarrollada será usada como librería estática, integrada dentro de LiveServe,

aplicación desarrollada por la empresa Solaiemes utilizada de forma satisfactoria para

5 http://www.rfc-editor.org/6 http://tools.ietf.org/html/rfc18897 http://tools.ietf.org/html/rfc35508 Envío de la información en una red a múltiples destinos simultáneamente9 Envío de información desde un único emisor a un único receptor


la transmisión de datos multimedia en dicha empresa.

1.1 Nuevas formas de comunicación

Internet está cambiando: lo que antes era contenido estático ahora se proporciona

en forma de flujo de vídeo, los textos están están siendo reemplazados por música y

comunicación hablada, y el audio y vídeo interactivos comienzan a ser las formas de

comunicación 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

Después de algunos experimentos, el interés por las conferencias de vídeo

comenzó a cobrar interés en la comunidad Internet a principios de los 90. Además, 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,

compresión y reproducción de audio y vídeo de forma simultánea.

En paralelo, el desarrollo del IP multicast permitía la transmisión 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 sólo incluirá facilidades

para el transporte de media, sino también soporte para la gestión de miembros,

sincronización y calidad de recepción.

1.1.2 Requisitos del transporte de voz y vídeo 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


recibido en lugar de simplemente almacenarlo en un fichero para luego reproducirlo.

En el caso ideal, la reproducción del receptor es inmediata y síncrona, pero en la

realidad tenemos retrasos insalvables en la conexión.

El primer requerimiento es que el protocolo sea capaz de predecir la variación de

tiempo en el transito de información en la red. Por ejemplo, en un sistema de telefonía

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 conversación pueda ser reproducida sin problemas. Sin

embargo, en el caso no ideal, existen retrasos en la comunicación, pero dichas

variaciones en el tiempo de transito pueden ser absorbidas por un buffer intermedio en

el receptor.

Otro requerimiento común en las conexiones de transmisión 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 mayoría de las aplicaciones son

capaces de tolerar ciertas perdidas. En el ejemplo telefónico, perder un paquete sería

perder una quincuagésima parte de un segundo, que, con la apropiada ocultación, no se

nota apenas. Dicha cantidad de perdidas aceptables viene determinado por la

aplicación, el método de codificación y el patrón de perdidas. Estos requerimientos nos

conducen a la elección 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 estándar RTP se construye sobre UDP/IP; además provee

de recuperación de paquetes y detección 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 conexión TCP y adaptar el

ratio de envío. Esta aproximación puede ser realizada cuando no se requiere el retardo

entre los extremos y la aplicación tiene muchos segundos de buffer para controlar la

10 Una frame es una imagen independiente que forma parte de una animación. Aunque la traducción encastellano significa literalmente “fotograma”, también puede aplicarse al sonido.


variación del tiempo de entrega causado por la transmisión TCP y el control de

congestión. Esto no es aceptable para aplicaciones interactivas, que necesitan un

retardo bajo entre extremos, porque la variación de tiempo en transito causada por TCP

es demasiado alta.

1.1.3 Beneficios del vídeo 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 también tiene diferentes

ventajas a destacar. La primera es que usando IP como un portador de servicio para

audio y vídeo en tiempo real se puede proveer de una red convergente y unificada. La

misma red puede ser usada para voz, música, vídeo, correo electrónico, 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 detección de transmisión

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 utilización de IP multicast,

que permite entrega de datos a un potencial numero de receptores enorme. Por ultimo,

y quizá es la mas convincente razón, es que IP puede ofrecer nuevos servicios. Esta

convergencia permite una gran interacción entre vídeo y audio en tiempo real y otras

aplicaciones, permitiendo desarrollar sistemas que no habrían sido posibles con un

sistema no basado en paquetes.

CAPÍTULO 2.

OBJETIVOS

Este Proyecto de Fin de Carrera constituye la finalización a los estudios de

segundo ciclo de la Ingeniería Superior Informática, y como tal el objetivo principal es

enfrentar al alumno al desarrollo completo de un sistema informático. Para ello, se

desarrollará el proyecto prestando especial atención al análisis, diseño e

implementación, además de desarrollar un conjunto de pruebas y una evaluación

objetiva de los resultados obtenidos.

Acerca del sistema, se desea desarrollar una librería para el protocolo de

comunicaciones RTP/RTCP en el lenguaje de programación Java. Dicho protocolo de

comunicación usa paquetes para enviar y recibir datos y mantener estadísticas de

control, por lo que la librería 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 programación Java que permitan que

el programador que use la librería pueda manejar los paquetes de forma cómoda y

sencilla en forma de objetos Java; y por otra parte, la librería también debe estar

diseñada 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 implementación de aplanadores y desaplanadores,

tendiendo en cuenta que las definiciones de aplanamiento y desaplanamiento son11:

• Definición de aplanamiento: proceso por el cual una estructura de datos se

11 Apuntes RedesII: Luis López Fernández

15

CAPÍTULO 2. OBJETIVOS 16

transforma en una secuencia de bits siguiendo un conjunto de reglas de

codificación predefinido.

• Definición de desaplanamiento: proceso por el cual una secuencia de bits se

transforma en una estructura de datos siguiendo un conjunto de reglas de

decodificación predefinido.

Otro objetivo de este proyecto será la implementación de funcionalidades que

permitan recibir y enviar paquetes RTP desde/hasta diferentes nodos de una red. Estas

funcionalidades deberán ser implementadas de forma modular, por lo que recibir o

enviar paquetes RTP no dependerán el uno del otro, esto además de mejorar la

flexibilidad de la librería también permite el fácil desarrollo nuevos módulos.

Además, la librería debe ser capaz de enviar y recibir paquetes, también deberá

encargarse de la gestión del protocolo de control de RTP (RTCP). La librería deberá

almacenar estadísticas y calcular datos importantes para mantener la conexión RTP,

por lo tanto, se implementarán también módulos de envío y recepción de paquetes

RTCP, manteniendo coherentes los datos que se envíen en ellos. Debido a que existen

diferentes peculiaridades con algunos dispositivos móviles con los que se probará la

librería, para realizar las pruebas de forma correcta, se estudiarán dichas peculiaridades

y se procederá a adaptar la librería 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 vídeo 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 vídeo cesa de

enviar paquetes RTP, la librería debe ser capaz de mantener el envío de

paquetes de forma trasparente al destinatario.

• Recuperación cuando se restablezca la conexión, si la conexión vuelve a

establecerse, la librería de nuevo debe realizar el proceso de forma correcta.

• Compatibilidad con diferentes dispositivos móviles y el reproductor VLC.

CAPÍTULO 3.

CONTEXTO Y MARCO DE TRABAJO

3.1 Tecnologías de Media

En el presente documento se habla de archivos y contenido multimedia, y si bien

las nociones básicas de este concepto son ampliamente conocidas, llegado este punto

conviene definir más formalmente algunas de sus características. Un contenido

multimedia es aquel que está compuesto de diversos “medios”, como pueden ser

audio, vídeo, 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

característica hace que un contenido multimedia requiera ser proporcionado y

procesado en unas condiciones temporales estrictas. Por ejemplo cuando se reproduce

un vídeo, si los datos multimedia no pueden ser proporcionados lo suficientemente

rápido pueden producirse pausas y retrasos en la reproducción; por otro lado si los

datos no pueden ser recibidos y procesados lo suficientemente rápido el vídeo se

reproduce a saltos ya que se desechan cuadros como mecanismo para mantener la tasa

de reproducción. A continuación se enumeran los principales elementos que componen

el contenido multimedia, conviene que el lector se familiarice con ellos porque serán

usados a lo largo de todo el documento.

17

CAPÍTULO 3. CONTEXTO Y MARCO DE TRABAJO 18

3.1.1 Conceptos Básicos

• 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 vídeo. Se dice que

las pistas que componen un contenido multimedia están multiplexadas. Al

proceso de extracción de las distintas pistas que componen un contenido

multimedia se le denomina demultiplexación.

• Códec12: Códec es una abreviatura de Compresor-Decompresor. Describe una

especificación desarrollada en software, hardware o una combinación de ambos,

capaz de transformar un archivo con un flujo de datos (stream) o una señal. Los

códecs pueden codificar el flujo o la señal (a menudo para la transmisión, el

almacenaje o el cifrado) y recuperarlo o descifrarlo del mismo modo para la

reproducción o la manipulación en un formato más apropiado para estas

operaciones. Los códecs son usados a menudo en videoconferencias y

emisiones de medios de comunicación.

La mayor parte de códecs provoca pérdidas de información para conseguir un

tamaño lo más pequeño posible del archivo destino. Hay también códecs sin

pérdidas (lossless), pero en la mayor parte de aplicaciones prácticas, para un

aumento casi imperceptible de la calidad no merece la pena un aumento

considerable del tamaño de los datos. La excepción es si los datos sufrirán otros

tratamientos en el futuro. En este caso, una codificación repetida con pérdidas a

la larga dañaría demasiado la calidad. Muchos archivos multimedia contienen

tanto datos de audio como de vídeo, y a menudo alguna referencia que permite

la sincronización del audio y el vídeo. 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 función es realizada por un formato de archivo de

vídeo (contenedor), como .mpg,.avi,.mov,.mp4,.rm,.ogg,.mkv o.tta. Algunos de

estos formatos están limitados a contener streams que se reducen a un pequeño

12 http://es.wikipedia.org/wiki/C%C3%B3dec


juego de códecs, mientras otros son usados para objetivos más generales.

Los distintos codecs se distinguen en función 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 transmisión.

Cada códec está destinado a diferentes tipos de aplicaciones y servicios. Códecs

como MPEG 1 son de gran calidad pero altos requerimientos de ancho de

banda están 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

transmisión 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 telefonía

IP, por ejemplo.

• Contenedor (container o content-type): es la estructura en que los datos son

enviados o almacenados, en el segundo caso irán asociados a una extensión 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 más usemos en las pruebas.

• Transcodificación (transcoding): es el proceso consistente en cambiar el

formato de una pista. Para conseguirlo se usan los códecs (codificadores-

decodificadores), que son programas que incorporan algoritmos capaces de

hacerlo. Cada tipo de códec puede manejar ciertos formatos de entrada y salida.

13 http://en.wikipedia.org/wiki/H.26114 http://en.wikipedia.org/wiki/H.26315 http://es.wikipedia.org/wiki/Flash_Video


3.1.2 Transmisión de datos

3.1.2.1 RTMP

Es un protocolo propietario desarrollado por Adobe Systems para el streaming de

vídeo 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

comunicación persistente en tiempo real. Además, 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 características de protocolo de nivel de transporte

(según el modelo OSI), es transportado, a diferencia de RTMP, usando UDP. El

protocolo UDP no maneja sesiones ni mecanismos que garanticen la recepción de los

paquetes, pero es usado por UDP en lugar de TCP debido a que reduce el tiempo de

envío de los paquetes a través de la red. En aplicaciones de voz y video es más

importante una transmisión rápida que la pérdida de algunos paquetes durante el

recorrido.

3.1.2.3 Descarga Continua

La descarga continua es un tipo de transmisión que utilizan la mayoría de sitios

web de compartición de video (por ejemplo Youtube). Este se basa en la descarga del

media (audio y video) de forma continua antes de comenzar su reproducción. De esta

forma, cuando se ha descargado el suficiente media como para reproducir de forma

suave y sin cortes la reproducción comienza la visualización 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 reproducción en tiempo real, por lo que no es una forma de

video recomendada en la transmisión de eventos en directo o en la comunicación en

tiempo real.

16 http://es.wikipedia.org/wiki/Cortafuegos_(inform%C3%A1tica)17 http://es.wikipedia.org/wiki/Network_Address_Translation


3.2 Protocolos de señalización

3.2.1 SDP

El Session Description Protocol18 (SDP), es un protocolo para describir los

parámetros de inicialización de los flujos multimedia. Fue publicado por el IETF en la

RFC 232719. Es un protocolo textual, y se puede usar en conjunción con RTSP o SIP

para informar al cliente de las características 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. Más

concretamente, un SDP consiste en una cadena de texto donde se informa de las pistas

disponibles, en qué formato se encuentran, y otros parámetros relacionados con el

contenido, como por ejemplo la duración. Con esta información los clientes como por

ejemplo aplicaciones de reproducción de vídeo/audio como VLC o dispositivos

móviles, tendrán constancia de las pistas disponibles y qué formato, pudiendo

seleccionar las que deseen y elegir los códecs adecuados para que la reproducción sea

correcta. Si el reproductor no dispone de ellos, debería desistir. El protocolo SDP será

usado en este proyecto al configurar el reproductor VLC y en la negociación que se

establezca con los dispositivos móviles. En el apéndice se muestra un ejemplo de

fichero SDP para la configuración de la aplicación VLC.

3.2.2 RTSP

RTSP es un protocolo no orientado a conexión, en lugar de esto el servidor

mantiene una sesión asociada a un identificador. En la mayoría de los casos RTSP usa

TCP para datos de control del reproductor y UDP para los datos de audio y vídeo

aunque también puede usar TCP en caso de que sea necesario. En el transcurso de una

sesión RTSP, un cliente puede abrir y cerrar varías conexiones de transporte hacia el

servidor por tal de satisfacer las necesidades del protocolo. De forma intencionada, el

18 http://tools.ietf.org/html/rfc456619 http://www.ietf.org/rfc/rfc2327.txt


protocolo es similar en sintaxis y operación a HTTP de forma que los mecanismos de

expansión añadidos a HTTP pueden, en muchos casos, añadirse 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

más se puede comparar con RTSP es SIP. El objetivo del Session Initiation Protocol20

es la iniciación, modificación y finalización de sesiones interactivas de usuario donde

intervienen elementos multimedia como el vídeo, voz, mensajería instantánea, juegos

online y realidad virtual. Es por tanto un protocolo de control cuya funcionalidad es

similar a RTSP, y además también 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 año

2000 fue aceptado como el protocolo de señalización de 3GPP5 y elemento

permanente de la arquitectura IMS6. SIP es además uno de los protocolos de

señalización para voz sobre IP. SIP funciona en colaboración con otros muchos

protocolos pero sólo interviene en la parte de negociación al establecer, modificar y

finalizar la sesión de comunicación. En un uso normal, las sesiones SIP se apoyan en

el protocolo RTP, que es el verdadero portador para los contenidos de audio y vídeo.

La negociación SIP se usa a menudo en conjunción 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 conexión y el inicio de sesión entre los

dispositivos móviles y la librería RtpLib. Para conseguir esta funcionalidad se ha

utilizado de la librería JSIP, propiedad de la empresa Solaiemes.

20 http://tools.ietf.org/html/rfc3261


3.3 Servicios

3.3.1 PTT

El PTT21 (Push to Talk), se podría traducir como pulsar para hablar, comúnmente

abreviado como PTT o PPH, es un método para hablar en líneas half-duplex de

comunicación, apretando un botón para transmitir y liberándolo para recibir. Este tipo

de comunicación permite llamadas de tipo uno-a-uno o bien uno-a-varios (llamadas de

grupos). El PTT es una característica que está disponible en casi todos los equipos de

radio, ya sean portátiles o móviles, además en ciertos modelos de teléfono móvil.

• PoC (Push over Cellular)22: es una evolución del servicio PTT, que consiste en

incorporar el PTT en los sistemas móviles celulares, permitiendo que sus

usuarios de teléfonos móviles puedan tomar parte en una comunicación

inmediata con uno o más 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 transmisión y gestión del video y audio se utiliza el RTP/RTCP.

3.3.2 Videollamada

También llamada videoconferencia, es la comunicación simultánea y bidireccional

de audio y vídeo, permitiendo mantener reuniones con grupos de personas situadas en

lugares alejados entre sí. Adicionalmente, pueden ofrecerse facilidades telemáticas o

de otro tipo como el intercambio de informaciones gráficas, imágenes fijas,

transmisión de ficheros desde el ordenador, etc. El núcleo tecnológico usado en un

sistema de videoconferencia es la compresión digital de los flujos de audio y vídeo en

tiempo real. Su implementación proporciona importantes beneficios, como el trabajo

colaborativo entre personas geográficamente distantes y una mayor integración entre

grupos de trabajo. Para la transmisión y gestión del audio y video se usa el protocolo

21 http://es.wikipedia.org/wiki/Push_to_talk22 http://en.wikipedia.org/wiki/Push_to_Talk_over_Cellular


RTP/RTCP.

3.3.3 VoIP

Voz sobre Protocolo de Internet, también llamado Voz sobre IP, VozIP, VoIP23 (por

sus siglas en inglés), es un grupo de recursos que hacen posible que la señal de voz

viaje a través de Internet empleando un protocolo IP (Internet Protocol). Esto significa

que se envía la señal de voz en forma digital en paquetes en lugar de enviarla (en

forma digital o analógica) a través de circuitos utilizables sólo para telefonía como una

compañía telefónica convencional o PSTN24 (acrónimo de Public Switched Telephone

Network, Red Telefónica Pública Conmutada). VoIP consigue calidad de servicio

priorizando los paquetes de menor latencia y utilizando compresión de cabeceras

aplicando los estándares RTP/RTCP.

3.4 Aplicaciones

3.4.1 X-Lite

Es un teléfono software gratuito que se usa para el protocolo de iniciación de

sesiones (SIP). X-Lite ha sido desarrollado por CounterPath. Es fácil de usar gracias a

su interfaz gráfica como se puede ver en la ilustración 1. La aplicación X-Lite será

usada en el proyecto para el estudio del protocolo RTP en combinación con el

analizador de redes Wireshark. Mas adelante se describirá la infraestructura diseñada

para realizar dicho cometido siendo el objetivo ser capaces de recibir datos en formato

RTP y comprobar el funcionamiento del protocolo RTP. La configuración de la

aplicación se describirá más adelante en el apéndice.

23 http://es.wikipedia.org/wiki/VoIP24 http://en.wikipedia.org/wiki/Public_switched_telephone_network


3.4.2 Asterisk

Asterisk25 es una aplicación de software libre (bajo licencia GPL) que proporciona

funcionalidades de una central telefónica (PBX26). Como cualquier PBX, se puede

conectar un número determinado de teléfonos para hacer llamadas entre sí e incluso

conectar a un proveedor de VoIP o bien a una RDSI tanto básicos como primarios.

Quizá lo más 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 conexión 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 vídeo, y también los formatos de DVD y VCD8. Además 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

Ilustración 1: Imagen de la aplicación X-Lite


Siempre que se habla de software libre merece la pena hacer al menos un breve

repaso de la historia y evolución del producto. Inicialmente el objetivo del proyecto

VLC era crear un servidor capaz de enviar un flujo de streaming a través 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 popularización,

actualmente desarrolladores de todo el mundo contribuyen a su evolución. En las

primeras etapas el proyecto constaba de dos módulos 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 denominación VLC Media Player. Sus principales

características son:

• Diseño muy modular: además del uso de los módulos existentes facilita la

incorporación de nuevos módulos para soportar más tipos de formatos, códecs o

métodos de streaming. Ofrece la posibilidad de elegir múltiples opciones para la

interfaz, así como entradas y salidas de audio y vídeo, filtros para conseguir

varios efectos, etc. Actualmente hay disponibles más de trescientos módulos

para VLC.

• Disponible para múltiples plataformas: contando con versiones para Windows,

Linux, Mac OS X, BeOS, BSD, Pocket PC y Solaris. Incluso existe una versión

portátil que puede ser almacenada y usada directamente desde una memoria

USB sin necesidad de instalación alguna.

• Utiliza la biblioteca libre libavcódec del proyecto FFmpeg10 para manejar los

muchos formatos que soporta, y emplea la biblioteca de descifrado DVD

libdvdcss para poder reproducir los DVDs cifrados. Además soporta otros

códecs 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 páginas Web sin tener que utilizar un

reproductor de Microsoft o Apple. Desde la versión 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.


• Robustez: VLC es especialmente popular por su robustez, ya que es capaz de

reproducir archivos incompletos o dañados antes de que se hayan descargado

completamente, por ejemplo a través 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, añadir logos, etc.

• Tiene otras funcionalidades peculiares que le pueden hacer atractivo para

muchos usuarios, como por ejemplo reproducir vídeo como si fuera el fondo de

pantalla, reproducción en directo usando una conexión FireWire, etc.

De cara a este proyecto, las capacidades más relevantes que nos pueda ofrecer

VLC son las relacionadas con la recepción de flujos RTP para comprobar durante el

proceso de pruebas la correcta visualización. En cuanto a lo segundo, VLC ofrece la

posibilidad del manejo a través de línea de comandos como alternativa a la interfaz

gráfica, incluyendo el uso de dicho módulo. Esto es fundamental, puesto que si sólo se

ofreciera la interfaz gráfica no sería posible el uso de VLC desde una aplicación en

Java. VLC ofrece una multitud de opciones y parámetros para ejecutarlo a través de

una terminal, usando sus capacidades tanto de reproducción como de servicio

streaming.

3.4.4 Dispositivos móviles usados

Ilustración 2: Logotipo de la aplicación VLC


Nokia N73: Smatphone, tiene en común son otros Nseries y Eseries, sin soporte de

Wi-Fi, capacidad 3G.

Nokia 6110 Navigator: Características similares a Nokia N73.

Ambos dispositivos móviles son capaces de establecer videoconferencias usando

protocolos como RTP/RTCP, SDP y SIP, además de ser compatibles con la

reproducción de videos codificados por los códecs H.261 y H.263. Cabe destacar, que

tras estudiar las trazas mediante el analizador de redes Wireshark, ambos dispositivos

móviles necesitan la recepción de paquetes RTP vacíos para mantener la conexión

RTP. Este flujo de vuelta de paquetes RTP no está en la RFC y no forma parte de la

especificación. A dichos paquetes los llamaremos paquetes dummies, y serán descritos

con mayor profundidad más adelante.

3.5 Entorno y Herramientas

3.5.1 Lenguaje de Programación: Java

El lenguaje de programación elegido ha sido Java, al ser considerado la mejor

opción para este proyecto. Java es un lenguaje multiplataforma, cuyos programas se

pueden ejecutar en cualquier sistema operativo que tenga instalada la máquina virtual

de Java. Tiene ciertas características que le hacen ser adecuado para el problema que se

pretende resolver:

• Simplicidad y alto nivel: es un lenguaje más 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.

• Orientación a objetos: Java es un programa orientado a objetos, en el que la

unidad principal de programación es la clase. Esta característica será útil para,

tal y como se pretende, implementar una librería de carácter modular y

aprovechando las ventajas que nos ofrece la programación orientada a objetos,

como el polimorfismo, la herencia y la encapsulación. Además la orientación a

objetos también facilita la escalabilidad, ya que si es necesario crear varias


sesiones RTP a la vez, esto será posible creando varias instancias de las clases

involucradas en el proceso.

• Orientación a la red: la API de Java proporciona clases que facilitan el uso de

conexiones de red y el envío y recepción de datos a través de las mismas. En

particular, los sockets y los channels.

• Posibilidad de usar línea de comandos: Java permite la ejecución de

programas de forma similar a si lo hiciéramos escribiendo comandos a través de

una consola del sistema operativo.

3.5.2 Sistema operativo, Ubuntu 7.04

Distribución Linux que ofrece un sistema operativo enfocado a computadores

personales. Actualmente es una de las más importantes a nivel mundial, basada en

Debian27 y con los objetivos de facilidad y libertad de uso. La librería 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 programación ha sido Eclipse.

Eclipse es una plataforma de software de código abierto independiente de sistema,

inicialmente diseñado para el desarrollo de aplicación Java. Se ha elegido este entorno

de desarrollo por las facilidades específicas que ofrece para la programación en Java,

como por ejemplo la detección automática de errores, el resaltado de elementos del

lenguaje (palabras reservadas, variables), etc. Estas características facilitan el

desarrollo y posterior comprensión del código 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 técnicas

avanzadas de refactorización y análisis de código. El IDE también hace uso de un

27 http://www.debian.org/index.es.html


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 básica para poder realizar pruebas era poder capturar el tráfico que

se estaba intercambiando a través de la red entre los diferentes elementos. La

herramienta elegida ha sido Wireshark, anteriormente conocida como Ethereal.

Wireshark es una herramienta utilizada para realizar análisis y solucionar

problemas en redes de comunicaciones para desarrollo de software y protocolos, y

también se usa como una herramienta didáctica para educación. Cuenta con todas las

características estándar de un analizador de protocolos:

1. Captura en vivo y capacidad de análisis offline.

2. Multiplataforma.

3. Rico en análisis VoIP.

Incorpora una interfaz gráfica y muchas opciones de organización y filtrado de

información. Así, permite ver todo el tráfico que pasa a través de una red (usualmente

una red Ethernet, aunque es compatible con algunas otras) estableciendo la

configuración en modo promiscuo. También incluye una versión 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 información capturada, a través 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 sesión de TCP, esta

característica lo hace especialmente útil para examinar los mensajes intercambiados a

lo largo de una sesión RTSP.

Wireshark es software libre, y se ejecuta sobre la mayoría 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 análisis


de los mensajes enviados por los dispositivos móviles para averiguar el uso real

que hacen del protocolo, como la confirmación de que la librería implementada

envía y gestiona los mensajes correctamente.

• Comprobar que los flujos de streaming a través de RTP se están creando

correctamente, corroborando que los paquetes UDP están llegando a la

dirección IP y puertos correspondientes.

3.5.5 Gestor de versiones SVN

Subversion (SVN)28 es un software de sistema de control de versiones, diseñado

específicamente para reemplazar a CVS29, el cual posee varias deficiencias.

Una versión, revisión o edición de un producto, es el estado en el se encuentra en

un momento dado en su desarrollo o modificación. Se llama control de versiones a la

gestión de los diversos cambios que se realizan sobre los elementos de algún producto

o una configuración del mismo. Los sistemas de control de versiones facilitan la

administración de las distintas versiones de cada producto desarrollado, así como las

posibles especializaciones realizadas (por ejemplo, para algún cliente específico). El

control de versiones se realiza principalmente en la industria informática para

controlar las distintas versiones del código fuente. Sin embargo, los mismos conceptos

son aplicables a otros ámbitos como documentos, imágenes, sitios web, etcétera.

Es software libre bajo una licencia de tipo Apache/BSD y se le conoce también

como SVN por ser ese el nombre de la herramienta de línea de comandos. Una

característica importante de Subversion es que, a diferencia de CVS, los archivos

28 http://subversion.tigris.org/29 http://ximbiot.com/cvs/cvshome/

Ilustración 3: Logotipo de la aplicación Wireshark


versionados no tienen cada uno un número de revisión independiente. En cambio, todo

el repositorio tiene un único número de versión que identifica un estado común de

todos los archivos del repositorio en cierto punto del tiempo. En este proyecto, SVN se

ha utilizado para coordinación con otros proyectos que dependen del mismo como por

ejemplo LiveServe u otros que son usados como el modulo de negociación SIP JSIP.

3.6 Infraestructura del sistema

Una vez descritos los protocolos, servicios, aplicaciones y herramientas a utilizar,

podemos definir la infraestructura básica del sistema. Antes de iniciar la

implementación de la librería, además 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 visión mas completa. Con este

objetivo, la infraestructura creada es la que se puede observar en la ilustración 4.

Ilustración 4: Infraestructura del sistema


El dispositivo móvil negociará con Asterisk el inicio de conexión mediante el

protocolo SIP, se definirán el códec a usar y otros parámetros antes de iniciar el flujo

de media; igualmente, Asterisk negociará mediante SIP también con la aplicación X-

Lite, que recibirá el flujo de datos. Una vez iniciada la conexión, Asterisk se limitará a

reenviar los datos que recibe del móvil a X-Lite.

El objetivo de la librería RtpLib a implementar en este proyecto es sustituir la

aplicación X-Lite por la librería RtpLib tal y como se puede observar en la ilustración

5. Sin embargo, la negociación SIP queda fuera de este proyecto, al igual que la

reproducción del media, por lo que se necesitan aplicaciones y librerías adicionales

para cubrir la funcionalidad de la aplicación X-Lite. Para la negociación SIP se usará

una librería implementado en Java llamada JSIP. Como se puede observar en la

ilustración 5 este modulo a su vez se encargará de iniciar una aplicación VLC con la

configuración SDP correcta en base a la negociación SIP. Una vez iniciada la

conexión, Asterisk se limitará a reenviar los datos que recibe del móvil a nuestro

ordenador, la librería RtpLib leerá estos datos y responderá con información de control

RTCP, en el caso de terminales móviles responderá también con paquetes dummy. Al

Ilustración 5: Infraestructura del sistema con la librería RtpLib


mismo tiempo, la librería reenviará los paquetes RTP a la aplicación VLC para

comprobar, mediante su visualización, que la recepción de los datos se realiza de

forma correcta.

CAPÍTULO 4.

EL PROTOCOLO RTP: ESPECIFICACIÓN

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 vídeo

Estos servicios incluyen:

● Identificación del tipo de datos enviados.

● Numeración secuencial de los paquetes enviados.

● Marcado de timestamp de los paquetes enviados.

● Monitorización en el envío.

El protocolo RTP no provee a si mismo de ningún mecanismo para asegurar el

envío a tiempo de los datos ni ninguna otra garantía de calidad de servicio, además

tampoco se garantiza el envío 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 números de secuencia también son usados para determinar la

localización del paquete, como por ejemplo en la codificación de vídeo, sin

descodificar necesariamente los paquetes en secuencia.

RTP está principalmente diseñado para satisfacer las necesidades de conferencias

con multitud de participantes multimedia.

En esta introducción al protocolo RTP se diferenciarán dos partes:

• El protocolo RTP en si mismo, para llevar datos con propiedades características

de el tiempo real.

35

CAPÍTULO 4. EL PROTOCOLO RTP: ESPECIFICACIÓN 36

• El protocolo de control de RTP -el protocolo RTCP- que monitoriza la calidad

de servicio y envía información sobre los participantes en una sesión.

RTP representa un nuevo estilo de protocolo siguiendo los principios del nivel de

aplicación. Con el protocolo RTP se intenta ofrecer una forma maleable de transportar

información requerida por una aplicación.

4.1.1 Escenarios de uso

Las siguientes secciones describirán algunos aspectos de uso del protocolo RTP.

Los ejemplos fueron elegidos para ilustrar las operaciones básicas de una aplicación

usando RTP.

1. Conferencia de audio en multicast: Aunque la sesión multicast no es un

escenario de uso en este proyecto, por motivos históricos antes mencionados, es

interesante tenerlo en cuenta. En una conferencia de audio, la aplicación de

cada uno de los participantes en dicha conferencia envía pequeños trozos de

datos de audio, por ejemplo, 20 ms de duración. 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 codificación del audio que

contiene cada paquete, por lo que cada emisor puede cambiar la codificación

durante la conferencia; para por ejemplo dar cabida a un nuevo participante

que está conectado mediante una conexión de banda estrecha o para reaccionar

frente a la congestión de la red. En Internet, como en otras redes de paquetes,

ocasionalmente se producen perdidas, retrasos y desordenación de paquetes.

Para solucionar estos impedimentos, la cabecera RTP contiene información

sobre el tiempo de reproducción y números 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 reconstrucción de la

secuencia temporal se lleva de forma independiente de cada fuente. El numero

de secuencia también se usa para estimar el numero de paquetes perdidos.

Como en la conferencia puede haber varias personas participando, es útil saber


en cada momento quien está y quien ha dejado la conferencia. Para este

propósito cada instancia de la aplicación de audio que participa en la

conferencia periódicamente envía un paquete de identificación de la fuente.

2. Conferencia de audio y vídeo: Si ambos medias (vídeo 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 vídeo, excepto que el usuario participante

en ambas debería usar el mismo nombre en los paquetes RTCP para cada una de

las sesiones asociadas. Una motivación para dicha separación es permitir que

alguno participantes en la conferencia reciban solamente uno de los medios a

elegir. A pesar de dicha separación, la sincronización se puede lograr usando

información sobre los tiempos contenida en los paquetes RTCP de ambas

sesiones.

4.2 La sesión RTP

Una sesión RTP consiste en un grupo de participantes quienes se están

comunicando mediante dicho protocolo. Un participante puede estar activo en

diferentes sesiones RTP -por ejemplo, una sesión para intercambio de audio y otra para

vídeo. Los puertos de recepción y envío de la información deben ser los mismos. Una

sesión puede ser unicast, donde cada participante está conectado directamente a otro o

a un servidor central que redistribuye los datos. O también puede ser multicast para un

grupo de participantes. Una sesión también 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 codificación, antes de


reenviar el resultado.

Debido a que el timing de los flujos de entrada generalmente no estarán

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 enviarán

posteriormente. Los identificadores SSRC de los paquetes de entrada son copiados al

CSRC de la lista de los paquetes.

Un mezclador tiene una única vista de una sesión: Este ve todas las fuentes como

fuentes de sincronización, mientras que el resto de participantes ven algunos como

fuentes de sincronización y a otras como fuentes de contribución. Un mezclador no

tiene porque usar el mismo SSRC para cada “mitad” de la sesión, pero tiene que enviar

paquetes RTCP con las descripciones de las fuentes (SDES) y paquetes de fin de

conexión (BYE) en ambos lados para todos los identificadores SSRC. De otra forma,

los participantes de una mitad no sabrán 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).

Ilustración 6: Mezclador M ve todas las fuentes como fuentes de sincronización; otros participantes (A, B, X, Y y Z) ven una combinación de fuentes de sincronización y contribución.


4.2.2 Multiplexando Sesiones RTP

Para un procesado eficiente del protocolo, el numero de puntos de puntos de

multiplexión debe ser mínimo. En RTP, dicha multiplexión es provista por la dirección

de transporte de destino (dirección de red y puerto) que es diferente en cada sesión

RTP. Por ejemplo si en una conferencia compuesta de vídeo y audio el media se

codifica de forma separada, cada medio debería ser transportado en sesiones RTP

separadas con su propia dirección de transporte.

Los flujos separados de audio y vídeo no deben ser transportados en una sola

sesión RTP y demultiplexados basándose 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 trasmisión periódica de

paquetes de control a todos los participantes de la sesión, usando el mismo mecanismo

de distribución 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 información 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 recepción 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 canónico (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 múltiples flujos de datos desde un

participante en un conjunto de sesiones relacionadas entre si; por ejemplo para

sincronizar audio y vídeo. La sincronización entre medios requiere los


timestamps de los campos NTP y RTP incluidos por los emisores, ambos

campos, descritos más en profundidad posteriormente, contienen datos sobre el

tiempo de envío y reproducción respectivamente de cada paquete.

3. Enviando cada participante paquetes de control a todos los demás 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 envía paquetes RTCP no está fijado, pero varía

según el tamaño de la sesión y el formato del flujo de datos. Normalmente el flujo de

paquetes RTCP es un 5% del total de carga de la conexión RTP. Esto se logra

reduciendo en el ratio de cada participante tanto como el tamaño de la conexión se

incremente. En una telephone-party las llamadas normalmente usan RTP, cada

participante enviará un informe RTCP cada pocos segundos; en una sesión con miles

de participantes -por ejemplo, una estación 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 congestión en el trafico.

4.3.2 Intervalo de informe

El tiempo medio que cada participante espera entre cada envío de paquetes RTCP

se conoce como intervalo de informe. Este se calcula partiendo del hecho que

múltiples factores:

1. El ancho de banda asignado a RTCP: Es una fracción fija de, como se ha


comentado, normalmente el 5%. El ancho de la sesión esperado es el ratio de

datos por sesión; normalmente este es el bitrate30 de un solo flujo de audio o

vídeo, multiplicado por el numero de emisores simultáneos. El ancho de banda

de la sesión es fijado para toda la duración de la sesión, y suministrado como un

parámetro de la configuración para la aplicación RTP cuando esta comienza. La

fracción del ancho de banda de la sesión puede cambiar según el RTP profile

que se esté usando. Es importante que todos los miembros de una sesión usen la

misma fracción de tiempo; de otra forma, el estado para algunos miembros

puede ser prematuramente cortado.

2. El tamaño medio de los paquetes RTCP enviados y recibidos: que incluye no

solo los datos RTCP, sino también los tamaños de las cabeceras UDP e IP.

3. El numero total de participantes y la fracción de estos participantes que son

emisores: Esto requiere una implementación 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 tamaño múltiplo de 32 bits. El

alineamiento requerido y el campo longitud en la parte fija de cada paquete están

incluidos para conseguir que los paquetes puedan ser “apilables”. De esta forma,

múltiples paquetes RTCP pueden ser concatenados sin intervención 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 combinación de los

paquetes. Aun así, existen algunas restricciones a tener en cuenta:

30 En telecomunicación e informática, el término tasa de bits (en inglés bit rate) define el número de bits que se transmiten por unidad de tiempo a través de un sistema de transmisión digital o entre dos dispositivos digitales. Así pues, es la velocidad de transferencia de datos.


1. Las estadísticas de recepción (en paquetes SR y RR) deben ser enviadas con

tanta frecuencia como las restricciones de ancho de banda se permita para

maximizar la resolución de las estadísticas, 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 también incluir el CNAME en un paquete

SDES.

Los tipos de paquete RTCP son los siguientes:

• SR (Sender Report): El informe de envío, sirve para la transmisión y recepción

de estadísticas desde los participantes que actúan como emisores activos.

• RR (Receiver Report): Informe de recepción, sirve para la recepción de

estadísticas desde los participantes que no actúan como emisores activos y en

combinación con el SR para los emisores activos.

• SDES (Source Description): Paquete que describen las fuentes que participan

en la conexión.

• BYE: Indica el fin de la participación.

• APP: Permite especificar funciones de aplicación.

Estos paquetes se describirán más adelante con mayor detalle.

4.4 Aspectos sintácticos del protocolo RTP/RTCP

Antes de comenzar la implementación de un protocolo hay que estudiar los

aspectos sintácticos de dicho protocolo.

Los aspectos sintácticos tienen que ver con:

● Especificación de los mensajes y de su formato.

● Especificación de los mecanismos de codificación.

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 informático correspondiente.


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 codificación y decodificación 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 propósito del proyecto es que la librería funcione en sistemas abiertos

independientes de su plataforma o lenguaje, por ello se deberán implementar dichos

aplanadores y desaplanadores, de acuerdo a la descripción 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 máxima resolución 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 más apropiado usar una representación más

compacta, donde solo los 32 bits intermedios de los 64 serán 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 continuación se describirá el formato de los mensajes RTP, tanto sus cabeceras

fijas como el resto de los campos variables, que nos servirá para implementar más

tarde los aplanadores y desaplanadores del protocolo.

4.4.2.1 Cabeceras fijas

A continuación se describirá las cabeceras fijas que llevarán cada uno de los

31 http://support.ntp.org/bin/view/Main/WebHome


paquetes RTP.

version (V): 2 bits

Este campo identifica la versión 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 encriptación

con bloques de tamaño fijo.

extension (X): 1 bit

Si el bit de extensión está activado, la cabecera fija deberá llevar exactamente una

cabecera de extensión, con formato que se definirá más tarde.

CSRC count (CC): 4 bits

El contador de CSRC contiene el numero de de identificadores CSRC que seguirán

a la cabecera fija.

marker (M): 1 bit

La interpretación 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 aplicación.

sequence number: 16 bits

El numero de secuencia se incrementa en uno por cada uno de los paquetes

enviados, y debería ser usado por el receptor para detectar paquetes perdidos y

Ilustración 7: Las cabeceras fijas de los paquetes RTP.


restaurar la secuencia de los paquetes. El valor inicial de este campo debería ser

aleatorio para evitar fallos de seguridad. Sin embargo, en los dispositivos móviles 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 sincronización y los cálculos del jitter (que se

describirá mas adelante). La frecuencia de reloj depende del formato de los datos

transportados y es especificado estáticamente en el profile o en las especificaciones

del formato, o puede ser también especificado dinámicamente por el payload.

Si los paquetes RTP se generan periódicamente, el instante de muestreo viene

determinado por el instante de reloj que va a ser usado, no por el reloj de cuando será

leído. Por ejemplo, para una conexión de audio el timestamp debería incrementarse en

uno por cada periodo de muestreo. Así, el instante de reproducción del paquete está

determinado por el timestamp y no por el momento de recepción de paquete. Si una

aplicación de audio lee bloques cubriendo 160 periodos de muestreo desde el

dispositivo de entrada, el timestamp debería 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 debería ser aleatorio, al igual que el del numero

de secuencia. Habrá muchos paquetes que tendrán igual timestamp si son, por ejemplo,

pertenecientes al mismo frame de vídeo. Paquetes consecutivos deberían contener

timestamps que no sean monótonos si los datos no están siendo transmitidos en el

orden de muestreo (esto ocurre por ejemplo de la interpolación MPEG), aunque el

numero de secuencia si será transmitido de forma secuencial. Los timestamps de

diferentes fuentes deberían 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 sincronización. 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


instante de muestreo es elegido como el punto de referencia para el timestamp porque

tiene una definición común para todos los flujos, independiente de la codificación u

otros procesamientos.

SSRC: 32 bits

El campo SSRC identifica la fuente. Este identificador debería ser elegido

aleatoriamente, con la intención de que no haya dos fuentes de sincronización iguales

en la misma sesión RTP. Aunque la probabilidad de que pase algo así es baja, la

implementación 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 están

contenidos en el paquete. El numero de identificadores está dado por el campo CC. Si

hay más de 15, solo se podrá identificar a 15 de ellos.

4.4.3 Formato de los mensajes RTCP

La especificación define una importante cantidad de tipos de paquetes RTCP para

transportar una gran variedad de información

4.4.3.1 SR (Sender Report)

El informe de envío, sirve para la transmisión y recepción de estadísticas desde

los participantes que actúan como emisores activos. El paquete consiste en tres

secciones, posiblemente seguidas de una cuarta, la extensión del profile. La primera

sección, la cabecera, tiene una longitud de 8 octetos.


Los campos son los siguientes:

version (V): 2 bits

Identifica la versión 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

información adicional al final del paquete que no formarán parte de la información de

control pero que estarán 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 recepción contenidos en el paquete.

packet type (PT): 8 bits

Contiene la constante 200 para identificar el paquete como un paquete RTCP SR.

Ilustración 8: Cabeceras del paquete RTCP SR


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 sincronización 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

combinación junto a los timestamps devueltos en los informe de recepción 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 sincronización 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

transmisión hasta el momento en que el paquete SR fue generado. La cuenta debería

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 conexión. También debería comenzar de nuevo si se

cambia el SSRC. La tercera sección del paquete SR cuenta con uno o mas bloques de

informe de recepción dependiendo del numero de las fuentes.

SSRC_n (source identifier): 32 bits

El identificador de la fuente al que pertenece la información del bloque.

fraction lost: 8 bits

La fracción de paquetes RTP perdidos de la fuente SSRC_n desde que el ultimo

paquete SR o RR fue enviado. Esta fracción es definida como el numero de paquetes

perdidos entre el numero de partidos enviados. El numero de paquetes perdidos se

puede calcular fácilmente gracias a los números de secuencia.


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 recepción 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 números de secuencia.

interarrival jitter: 32 bits

Es una estimación de la varianza estadística de los paquetes RTP, el calculo del

jitter de especificará más tarde en la implementación.

4.4.3.2 RR (Receiver Report)

Informe de recepción, sirve para la recepción de estadísticas desde los participantes

que no actúan como emisores activos y en combinación con el SR para los emisores

activos.

Los campos son análogos al SR, cumpliendo las mismas funciones pero en

Ilustración 9: Cabeceras del paquete RTCP RR


dirección contraria, ya que son datos que envía 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 más Chunks, cada uno de ellos compuesto de items que describen la fuente de

que identifica dicho Chunk.

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.

Ilustración 10: Cabeceras del paquete RTCP SDES


4.4.3.4 BYE (Goodbye)

Indica el fin de la participación. Uno o más fuentes que no volverán a estar activas.

4.4.3.5 APP (Application-Defined RTCP Packet)

El paquete APP se utiliza de forma experimental o para nuevas aplicaciones que

están siendo desarrolladas, en este caso, se ha usado para usar la tecnología PTT como

paquetes de control de membresía.

Ilustración 11: Cabeceras del paquete RTCP SDES

Ilustración 12: Cabeceras del paquete RTCP APP

CAPÍTULO 5.

DESCRIPCIÓN INFORMÁTICA

5.1 Descripción de la metodología 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 través de los proyectos variados en tamaños y

complejidad. Se basa en muchos años de experiencia en el uso de la tecnología

orientada a objetos en el desarrollo de software de misión crítica en una variedad de

industrias por la compañía Rational".32

El proceso unificado de desarrollo guía a los equipos de proyecto33 para saber

como administrar el desarrollo iterativo de un modo controlado. Dicho proceso nace

de la unificación de las tres metodologías de desarrollo basadas en el paradigma

orientado a objetos existentes hasta el momento de su creación:

• OOSE (Object Oriented Software Engineering): Incluye el modelo de casos de

32 El Proceso Unificado de Desarrollo Software: Jacobson, Booch, Rumbaugh33 Un equipo de proyecto es un grupo de especialistas que comparten un objetivo impuesto desde fuera, con

valores y actitudes heterogéneas

52

CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 53

uso, Jacobson, I.

• OOAD (Object Oriented Analysis and Design): Incluye el modelo de diseño,

Booch, G.

• OMT(Object Modeling Technique): Incluye las técnicas de modelado para el

análisis, Rumbaugh, J.

El Proceso Unificado (UP, Unified Process) combina prácticas comúnmente

aceptadas como "buenas prácticas", tales como el ciclo de vida iterativo y desarrollo

dirigido por el riesgo, en una descripción consistente y bien documentada. Un proceso

es orientado por el riesgo cuando intenta identificar y definir estrategias para enfrentar

los riesgos más graves del proyecto, resolviendo primero los puntos más difíciles,

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 características 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 sólo

sirven para especificar los requisitos del sistema, sino también para guiar el

proceso de desarrollo, su diseño, implementación y prueba.

2. Centrado en la arquitectura: El concepto de arquitectura software incluye los

aspectos estáticos y dinámicos más significativos del sistema. La arquitectura es

una vista del diseño completo con las características más importantes resaltadas,

dejando los detalles de lado. Debido a que lo que es significativo depende en

parte de una valoración, que a su vez, se adquiere con la experiencia, el valor de

una arquitectura depende de las personas responsables de su creación.

3. Iterativo e incremental: Es práctico dividir el trabajo en partes más pequeñas

o miniproyectos. Cada miniproyecto es una iteración que resulta en un


incremento. Las iteraciones hacen referencia a pasos en el flujo de trabajo, y los

incrementos, al crecimiento del producto. En cada iteración, los desarrolladores

identifican y especifican los casos de uso relevantes, crean un diseño utilizando

la arquitectura seleccionada como guía, implementan el diseño mediante

componentes, y verifican que los componentes satisfacen los casos de uso. Así,

los beneficios que obtenemos son: reducción de costes y de riesgos y

aceleración del ritmo de desarrollo.


5.2 Planificación

5.2.1 Objetivos parciales necesarios para alcanzar el objetivo final

• Estudio de la RFC: Aspectos sintácticos del protocolo para realizar el

aplanamiento y desaplanamiento de forma correcta. Contexto y semántica del

protocolo, protocolo de control RTCP,.

• Aproximación al desarrollo de aplicaciones Java mediante el entorno de

desarrollo Eclipse.

• Acercamiento al manejo de herramientas de análisis de redes, como Wireshark.

• Estudio del lenguaje Java en el control de hilos.

• Aprendizaje de configuración y manejo de las aplicaciones X-Lite y VLC para

realizar las pruebas.

5.2.2 Descripción de las etapas que se seguirán en el desarrollo

1. Comprensión del sistema a desarrollar: Mediante reuniones con los tutores o

responsables del proyecto, estableciendo las bases del sistema.

2. Requisitos: La especificación de requisitos ya ha sido fijada previamente, por lo

que en este caso se estudiará y comprenderán dichos requisitos.

3. Familiarización e instalación de las herramientas de trabajo: Acercamiento a las

herramientas y plataformas con las que se trabajará; para ello se estudiarán

manuales de dichas herramientas.

4. Diseño e implementación de aplanamiento y desaplanamiento: diseño e

implementación de las clases que ofrecerán dicha funcionalidad.

5. Prueba del aplanamiento y desaplanamiento:

1. Con test programados en Java.

2. Mediante el analizador de redes Wireshark.

6. Diseño e implementación del reenvío de paquetes RTP: diseño e

implementación de los módulos de recepción y envío de paquetes RTP.


7. Prueba de reenvío de paquetes RTP: mediante dos instancias de la aplicación

VLC, la librería simplemente realizará el fordwarding de los paquetes RTP

recibidos a otra aplicación VLC.

8. Diseño e implementación del protocolo de control RTCP:

1. Diseño e implementación de los módulos de recepción y envío de paquetes

RTCP.

2. Obtención y calculo de estadísticas RTCP.

9. Prueba de recepción de datos con móviles Nokia: se comprobará la correcta

visualización y el mantenimiento de la conexión mediante los paquetes dummy

y RTCP.

10. Buffer de paquetes RTP:

1. Diseño e implementación de simulación y absorción de retrasos.

2. Prueba de simulación y absorción de retrasos.

1. Se probará mediante aplicaciones VLC, de forma similar al punto 4.

3. Diseño e implementación de recuperación antes cortes.

1. Prueba con la misma estructura que la anterior prueba.

11. Finalización de la documentación: Se documentará el Javadoc con las

funciones más importantes.

12. Integración: Integración de la librería en la aplicación LiveServe.


5.3 Especificación de requisitos

Este apartado contiene el documento con la especificación de requisitos de la

librería a desarrollar. Dicho documento ha sido estructurado siguiendo las directrices

marcadas por el estándar IEEE Recommended Practice for Software Requirements

Specification ANSI/IEEE 830 1998. Para conseguir estos requisitos se ha realizado un

proceso de documentación basado principalmente en lectura de artículos publicados, y

principalmente, el análisis de la RFC publicada cobre el protocolo RTP. Estos

requisitos nacen de la necesidad de integrar la librería del protocolo RTP en un sistema

mayor, como se ha comentado en la introducción, en la librería LiveServe.

5.3.1 Propósito

El propósito de la especificación de requisitos es aclarar las propiedades,

funcionalidades y restricciones lo que se debe construir. Esta especificación 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 librería que permita el desarrollo de

aplicaciones basadas en la transmisión de flujos de audio y vídeo a través de la red

mediante el protocolo RTP. Esta librería permitirá la recepción, envío y reenvío de

paquetes RTP, el cálculo de estadísticas a partir de los paquetes recibidos y crear flujos

de paquetes RTCP tanto con el emisor como el receptor. Además, la librería

proporcionará un buffer para la reordenación de los paquetes y absorber retrasos.

5.3.3 Interfaces externos

Como el proyecto es una librería del protocolo RTP/RTCP no existirá ninguna


interfaz de usuario, sin embargo, en la API se describirán más adelante como usar la

librería de forma correcta para que se pueda desarrollar con ella.

5.3.4 Requisitos funcionales

Para conseguir los objetivos especificados anteriormente la librería debe cumplir

las distintas funciones explicadas a continuación.

R1. Fácil uso de paquetes/objeto RTP y RTCP: Una vez desaplanados los paquetes, se

construirán objetos que permitan el manejo fácil 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 atención a la RFC 3550 donde encontraremos los aspectos

sintácticos del protocolo.

R2. El protocolo debe ser capaz de predecir la variación de tiempo en el transito de

información en la red: por ejemplo, en un sistema de telefonía 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 conversación pueda ser reproducida sin problemas. Sin embargo, en el caso no

ideal, existen retrasos en la comunicación, 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 también

los campos de las cabeceras UDP.

R4. Control de flujos RTCP.

R4.1. Construir flujos RTCP de vuelta a la fuente RTP, con la información de control

útil para el emisor: teniendo en cuenta las posibles peculiaridades de los emisores

(como por ejemplo alguno de los dispositivos móviles antes mencionados), se debe

poder crear flujos de control a los emisores en una sesión RTP.

R4.2. Recibir y gestionar flujos RTCP de los receptores para ajustar las emisiones a


cada destinatario: análogo al requisito anterior, la librería debe proporcionar gestión

de los flujos de control recibidos tanto por el emisor como por el receptor.

R5. Simular "pausas" o silencios: creando paquetes RTP's vacíos 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 librería debe permitir que se pueda redireccionar un flujo entrante a uno o varios

receptores nuevos de forma transparente.

R8. Añadir un nuevo flujo RTP de salida partiendo de un fordwarding anterior:

De forma análoga al anterior requisito, además de simplemente redireccionar el flujo

entrante, la librería debe proporcionar mecanismos para que los paquetes de los

diferentes flujos de salida puedan ser manipulados, como por ejemplo, los números

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 móviles como el N73, y además, mantenga el ratio que

tenía dicho timestamp.

R8.2. SSRC: En caso de que el desarrollador (el usuario de la librería) opte por un

mezclador, la librería debe modificar el campo de SSRC para mantener en el flujo de

salida el suyo mismo.

R9. Reenvío de paquetes dummy por el canal del flujo RTP: Los paquetes dummy

deben ser paquetes RTP que serán enviados por el mismo canal que el móvil envíe los

datos de vídeo. Estos paquetes no contienen datos y deberán ser enviados cada cierto

tiempo fijo.

R10. Audio y Vídeo de distintas fuentes: Modificar dos flujos independientes de

audio y vídeo para que estén sincronizados entre sí. En este caso se debe modificar el

timestamp para traducir de tiempo real a diferencia de timestamps.

R11. Librería configurable:

R11.1. Arrancar receptor RTP en un socket atado pasado como parámetro.


R12. Scheduler34:El scheduler es un planificador que permite controlar

dinámicamente el flujo RTP. En la librería 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 implementación del scheduler, aquí se indican

con más detalle los requisitos específicos del scheduler:

R12.1. Mantener constante la tasa de envío de paquetes que salen del buffer:

esta temporización debe ser coherente con el timestamp de los paquetes.

R12.2. Mantener el timestamp de salida en el buffer:

modificándolo 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 vídeo: 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 librería se hará sobre el lenguaje de programación Java.

5.3.5 Requisitos no funcionales

R14. Consumo de recursos: El rendimiento de la librería debe ser capaz de mantener

un flujo de salida lo suficientemente alto como el flujo que recibe de entrada. Además,

la librería debe ser capaz de manejar varias fuentes simultáneamente sin limitaciones

de numero (permitir tanto como el protocolo especifica).

R15. Documentación: La librería debe estar documentada en Javadoc para la correcta

utilización de los futuros desarrolladores. Además, se debe proporcionar una buena

API con la que se pueda aprender a como desarrollar de forma fácil.

34 http://en.wikipedia.org/wiki/Scheduling_(computing)


5.3.6 Casos de uso

Los casos de uso, según las especificaciones del protocolo y los requisitos

planteados:

1. Recepción de paquete RTP, desaplanado, modificación de datos, aplanamiento y

reenvío.

2. Análogo al anterior, pero con mantenimiento de información RTCP para emisor

y receptor.

3. Análogo a cualquiera de los dos primeros, pero permitiendo almacenar los

paquetes en un buffer para poder absorber retrasos (o simularlos).


5.4 Arquitectura y Análisis

Para realizar el análisis, prestaremos especial atención a los requisitos que se han

descrito previamente, refinándolos y estructurándolos, con el objetivo de conseguir

una compresión más precisa de los requisitos y una descripción de los mismos más

fácil de mantener y que ayude a estructurar el sistema entero.

El sistema deberá dividirse en funcionalidades diferenciadas.

1. Aplanamiento/desaplanamiento.

2. Gestión de la sesión RTP.

3. Gestión de la sesión 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 más lógico sería usar una clase para cada tipo de mensaje, y beneficiarnos de las

ventajas de la programación orientada a objetos.

Ilustración 13: Clases de análisis: Paquetes


5.4.1 Diagramas de colaboración

Aunque el intercambio de mensajes y las relaciones entre objetos se detallarán de

forma más clara en los diagramas de secuencia, un buen artefacto para describir de

forma superficial el comportamiento del protocolo son los diagramas de colaboración.

5.4.1.1 Fordwarding de paquete RTP

En este caso, como se puede observar en la ilustración 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.

En este caso no se contemplan el caso del envío de paquetes dummy. Los paquetes

dummy son paquetes vacíos de contenido, que enviará la librería a la fuente del media

que lo requieran (en este caso los terminales móviles 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

recomendación de la RFC de que debe ser aleatorio) y mantenerse secuencial por cada

paquete dummy enviado. El envío de estos paquetes dummy será al mismo puerto por

Ilustración 14: Diagrama de colaboración: Reenvío de paquete RTP


el que envía el terminal el flujo de video.

5.4.1.2 Mantenimiento de la sesión RTCP

En este caso, como se puede observar en la ilustración 15, la sesión RTCP recibe

mensajes, los desaplana y actualiza los datos. Según a esos datos (numero de paquetes

perdidos, jitter...) se enviarán paquetes RTCP a las fuentes de la sesión y el receptor.

5.4.1.3 Uso del buffer

En este caso, como se puede observar en la ilustración 16, en lugar de reenviar los

paquetes directamente al receptor, se almacenarán en un buffer. La sesión RTP recibe

los paquetes, los desaplana y los introduce en un buffer. Luego, la misma sesión decide

cuando enviar dichos paquetes, los sacará del buffer y los enviará al receptor.

Ilustración 15: Diagrama de colaboración: Mantenimiento de sesión RTCP


Ilustración 16: Diagrama de colaboración: Uso del buffer


5.5 Diseño

En el diseño modelamos el sistema y encontramos su forma para que soporte todos

los requisitos, así los propósitos serán:

• Adquirir una comprensión en profundidad de los aspectos relacionados con los

requisitos no funcionales y restricciones relacionadas con los lenguajes de

programación.

• Ser capaces de descomponer los trabajos de implementación en partes más

manejables que puedan ser llevadas a cabo por diferentes equipos de desarrollo.

Por otra parte, en la implementación empezamos con el resultado del diseño e

implementación del sistema en términos de componentes, es decir, ficheros de código

fuente, scripts, ficheros de código binario, ejecutables y similares.

5.5.1 Decisiones de Diseño

• 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 más fácil, 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 método

estático y el parámetro size el tamaño que tendrá el objeto ByteBuffer.

También se pueden crear objetos ByteBuffer a partir de arrays de byte con

datos mediante la llamada ByteBuffer.wrap(new byte[]), siendo wrap el

método estático que recibe como parámetro 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


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 232 , tendremos

un numero negativo. Por esta razón, todos los campos de los paquetes

RTP/RTCP serán almacenados en variables que sean más 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 sería

getTimeStamp, un método sin parámetros que devuelve el campo timestamp

del ByteBuffer después de convertirlo a long.

• Reutilización: Otra decisión de implementación es la reutilización del

ByteBuffer. La asignación de memoria es un proceso que consume una

notable cantidad de recursos si se realiza de forma continua y además se

necesita que la aplicación sea rápida como ocurre en este caso. Se recibirán 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, también 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 método marshall que

aplana el objeto Packet que ha llamado dicho método devolviendo un objeto

ByteBuffer con el conjunto de bytes contiendo los datos de dicho paquete. El

método marshall recibe como parámetros 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 parámetro.

• Channels36: Para realizar el envío y recepción 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 fácil y rápida recibir y enviar

paquetes UDP por la red. Además, utilizar canales facilita la implementación

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


se ha visto anteriormente, crear un objeto de tipo Selector y añadirle los canales

que se quiera que “escuche” en caso de que lleguen paquetes RTP. La

configuración de estos canales se detallará en la API.

• PriorityQueue: Los paquetes RTP serán 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, además permitirá

que varios hilos puedan acceder a dicho buffer de forma segura. El buffer

ordenará el los paquetes de acuerdo a la implementación de un Comparator37

(interfaz de Java) por lo que se deberá tener una implementación de dicha

interfaz, dicha implementación es la clase RtpBufferNodeComparator.

• Jitter: Para la implementación del jitter se sigue los cálculos de la RFC del

protocolo RTP. En la implementación se ha optado por un método llamado

estimateJitter, cuya implementación al completo se puede observar en el

texto 1.

Dicho código, calculará el jitter cada vez que se reciba un nuevo paquete RTP, los

parámetros de la función son:

• si: timestamp del paquete recibido.

• ir: ratio timestamp del flujo de datos perteneciente al paquete recibido, aunque

debe ser fijo, aunque calculado dinámicamente por cada paquete recibido para

detectar cambios, como por ejemplo cortes de la conexión, que provocará que el

timestamps de los nuevos paquetes al reiniciado de la conexión 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

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: Estimación del jitter


• 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 diseño

La clase de diseño es un artefacto, una abstracción de una clase o construcción del

sistema que permite describir la estructura del sistema mostrando sus clases, atributos

y métodos.

5.5.2.1 Paquete packets.rtcp:

En este paquete encontraremos la jerarquía de clases para usar de forma sencilla

los objetos que crearemos según recibamos/enviemos paquetes RTCP, además de las

clases que nos permitirán realizar el aplanamiento/desaplanamiento a partir de los

paquetes u objetos.

• Rtcp[TipoRtcp38]ByteBuffer: Su función es proporcionar métodos para que,

a 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 ilustración 17) deberán implementar la clase

abstracta RtcpByteBuffer, que servirá como la interfaz para el desarrollador

de las posibles funcionalidades de un paquete RtcpByteBuffer. Además, con

una interfaz común, se usarán 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. Además, 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

implementación será común.

38[TipoRtcp]: SR | RR | SDES | APP | BYE


• Rtcp[TipoRtcp]Packet: Clases cuya funcionalidad es representar, en forma

de objeto Java, paquetes de RTCP. Con la jerarquía de clases que se puede

observar en la ilustración 17, para cada paquete, nos permite usar la flexibilidad

del polimorfismo y las ventajas de la reutilización de código. Al igual que en el

caso de las clases RtcpByteBuffer, hay una interfaz que todas implementarán;

en esta caso también 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 implementación.

• Chunk: Se usa para crear una serie de componentes de tipo Chunk y facilitar la

utilización 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 más cómoda estos elementos.

Ilustración 18: Paquete rtplib.packets.rtcp Packet (aplanadores)

Ilustración 17: Paquete rtplib.packets.rtcp ByteBuffer (desaplanadores)


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 ilustración 18, esta clase

centralizará el funcionamiento de toda la librería. Además, contendrá un mapa

hash que permitirá acceder más fácilmente a las fuentes que participan en la

conexión.

• 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 sesión RTCP.

• RtcpSession: Por cada comunicación de audio/vídeo puede haber también

intercambio de datos de control entre los participantes; en ese caso, entre cada

nodo se creará una sesión Rtcp desde la que se controlará todos los aspectos del

control de la comunicación. Como se puede observar en la ilustración 18, la

RtcpSession estará siempre relacionada con la RtpSession, de tal forma que

accederá a los datos de esta para poder realizar la comunicación, de esta forma

conseguimos que los datos estén accesibles desde una sola clase, centralizando

el acceso.

• RtpReceiver: Análoga 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 información de una fuente de

sincronización, principalmente los datos necesarios para mantener estadísticas

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. Además, debe encargarse de enviar


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 rápida 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 conexión.

5.5.2.3 Paquete rtplib.buffer:

RtpBufferList: Como se puede observar en la ilustración 20, simplemente

contendrá dos buffers, uno de audio y otro de vídeo, 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

Ilustración 19: Paquete rtplib.receivers.rtp, rtplib.receivers.rtcp y rtplib.sender


• RtpBuffer: El buffer permitirá absorber retrasos y reordenar los paquetes, es

decir, contendrá toda la lógica del scheduler, será una clase que recubrirá a la

PriorityQueue y cuando almacenemos o elimines del buffer, se realizará la

misma acción en la PriorityQueue.

• RtpBufferNode: El nodo contendrá un paquete RTP además de información

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 más bajo.

40 http://java.sun.com/j2se/1.4.2/docs/api/java/util/Comparator.html

Ilustración 20: Paquete rtplib.buffer


5.5.3 Implementación

En la implementación empezaremos con el resultado del diseño e

implementaremos el sistema en componentes, es decir, ficheros de código fuente,

scripts, ficheros de código binario, ejecutables y similares. Los diagramas de secuencia

nos permitirán modelar la interacción entre los objetos del sistema, ordenados de

forma temporal. Además, 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 implementación de la librería 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 permitirán la fácil gestión de los paquetes RTP/RTCP,

además de realizar acciones sobre estos. Algunas de estas acciones serán: 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, y

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 filosofía, se ha decidido en la

implementación hacer un uso parecido para el caso de el desaplanamiento y

reutilización de objetos RTP.


En el texto 2 se puede observar el desaplanamiento de un objeto de la clase

RtpByteBuffer, dicho método creará a partir de los datos que tiene en su

ByteBuffer, un objeto/paquete RTP. Los métodos getSequenceNumber,

getSsrc...obtienen del ByteBuffer el campo respectivo:

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 método setAll de la clase RtpPacket o Rtcp[TipoRtcp]Packet como

se puede ver en el texto 4.

5.5.3.2 Recepción y envío de paquetes RTP sin buffer

Como en una sesión 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

implementación 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

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

public int getSequenceNumber() {return 0x0000FFFF & (int)byteBuffer.getShort(2);

}

Texto 3: Obtención de campo numero de secuencia

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


hilo bloqueado esperando recibir) que ejecutará el método processReadEvent, el cual

enviará el paquete al receptor final. En este caso al no tener buffer, el envío se hace

inmediatamente después de recibir el paquete.

Esta implementación 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 múltiples canales, no un hilo por canal. El

envío de los paquetes dummy se realizará con un hilo, que despertará después 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 información 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

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 blocke.printStackTrace();

}}

}

Texto 5: método processReadEvent


En la ilustración 21 podemos observar el diagrama de secuencia correspondiente a

las llamadas e intercambio de mensajes que se realizan en la recepción 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,

además de actualizar datos y estadísticas de la fuente correspondiente que ha enviado

el paquete, datos que serán útiles para mantener el flujo de control RTCP.

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: Recepción de paquetes


Ilustración 21: Recepción/Envío de RTP


5.5.3.3 Envío de paquetes RTP con buffer

En el caso de que se utilice un buffer intermedio, tendremos dos hilos de ejecución,

uno que recibirá los paquetes RTP y otro que los enviará. En el caso de este ultimo, es

necesario que envíe 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 ejecución de forma fácil y precisa. En nuestro caso, el

método que mejor se adapta a nuestras necesidades es el scheduleAtFixedRate.

Como se observa en el texto 7, este método recibe como parámetros 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 método getTimeWait, que proporcionará el ratio de envío con el que

deben ser enviados los paquetes. Esta funcionalidad es implementada por la clase

RtpSender.

En el siguiente diagrama de secuencia que podemos observar en la ilustración 22,

detalla como la clase RtpSender extrae paquetes del buffer que sean del mismo

timestamp y los envía al receptor.

42 http://java.sun.com/j2se/1.5.0/docs/api/java/util/Timer.html43 http://java.sun.com/j2se/1.5.0/docs/api/java/util/TimerTask.html

protected void send() {Timer timer = new Timer();timer.scheduleAtFixedRate(new sender(this.rtpSession,

this.ssrc), 0, this.getTimeWait());}

Texto 7: Envio de paquetes


Ilustración 22: Envío de paquete RTP con buffer


5.5.3.4 Recepción paquetes RTP con buffer

La recepción 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 ilustración 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 serán

objetos que además de contener el objeto de tipo RtpPacket, tendrán información ú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 ordenación.


Ilustración 23: Recepción de paquetes RTP con buffer


5.5.3.5 Recepción de paquetes RTCP

La recepción de paquetes RTCP será análoga a la recepción de paquetes RTP, es

decir, por eventos, con la diferencia de que hay diferentes paquetes de tipo RTCP, se

deberá actuar de forma diferente según el tipo de paquete RTCP.

5.5.3.6 Recepción de paquetes SDES RTCP

Los paquetes SDES contienen información 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.

Además, es posible que cuando se reciba un paquete SDES sea la primera vez que

tengamos información sobre dicha fuente, por lo que quizá haya que crear las

estructuras necesarias para dicha fuente. Al igual que en el caso de recepción de

paquetes RTP, se ha optado por una recepción 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 función 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 método processReadEvent de la versión para

la recepción 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.


Como se puede observar en el texto 8, cuando sabemos que tipo de paquete RTCP

se ha recibido se llama al método actionPt, que realizará las acciones oportunas

según el paquete RTCP recibido, tal y como podemos observar en la implementación

de este método que se encuentra en el texto 9.

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: Recepción de paquetes RTCP


Por ultimo cabe señalar la implementación 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.

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: Recepción de paquetes RTCP


En la ilustración 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 sesión RTP gobernada por

la clase RtpSession, se procederá a crear un nuevo MediaSource, si no es así,

simplemente se actualizarán datos de dicho MediaSource que representa al flujo de

media entrante.

5.5.3.7 Recepción de paquetes SR/RR RTCP

En el caso de la recepción de paquetes Sender Report o Receiver Report, se

actualizarán estadísticas. Como se ve en el texto 11, la implementación de

actualización de estadísticas para cuando se ha recibido un paquete SR consiste en

actualizar valores de tiempo como el NTP y los timestamps.

Ilustración 24: Recepción paquetes SDES RTCP

for (Chunk chunk : chunks) {if (!this.sources.containsKey(chunk.getRc()))

this.sources.put(chunk.getRc(), new MediaSource(this, chunk.getRc(), isVideo));

}

Texto 10: Desaplanamiento de Chunks


Como se puede puede observar en la ilustración 25, cuando se recibe un paquete

RTCP SR/RR tras desaplanarlo se procede a actualizar las estadísticas de la sesión

RTCP, cuyos datos están contenidos en un objeto RtcpSession, y esta a su vez

actualizará los datos de los MediaSource.

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: Actualización de estadísticas

Ilustración 25: Recepción de paquetes SR/RR RTCP


5.5.3.8 Recepción paquete BYE RTCP

Los paquetes BYE informan de que uno de los participantes dejan de formar parte

de la conexión, por lo que básicamente, será eliminar la fuente de la tabla hash. En la

ilustración 26 se puede observar como cuando el objeto RtcpReceiver recibe un

paquete de este tipo elimina la fuente de la sesión RTP, además de cerrar la conexión

con dicha fuente, por lo que se procederá a cerrar el canal por el cual se recibía el flujo

de datos.

5.5.3.9 Retrasos en el Buffer

Debido a que los medias de vídeo 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 vídeo y almacenar de audio, y viceversa para el

caso del vídeo. 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 configuración de estos buffer es fácil, ya que

Ilustración 26: Recepción paquetes BYE RTCP


dichos retrasos serán pasados por parámetros en el constructor de la sesión RTP. La

configuración de los buffer se detallará en la API.


5.6 Pruebas

En este apartado se mostrará las diferentes pruebas realizadas para verificar que la

librería cumple los requisitos especificados y el resultado de la implementación,

probando cada construcción, 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 ilustración 27, la prueba consistirá en crear una

sencilla aplicación Java, con una parte emisora y otra receptora de paquetes UDP. La

parte emisora crea objetos RTP y RTCP (numero 1 en la ilustración 27) de todos sus

tipos, aplana dichos objetos convirtiéndolos en una secuencia de bytes que se enviará

de forma local a la misma aplicación Java, que al recibir el conjunto de bytes (numero

2 en la ilustración 27) los enviará por la red para permitir el análisis mediante

Wireshark a la parte receptora de la aplicación/prueba (numero 4 de la ilustración 27).

La parte receptora desaplanará los ByteBuffer y creará el objeto resultante (números

5 y 6 en la ilustración 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 librería supera esta prueba, se puede aceptar con cierta fiabilidad que el

aplanamiento y desaplanamiento funcionan de forma correcta, sin embargo, pruebas

futuras descritas más adelante se cerciorarán del correcto funcionamiento de estas

funcionalidades. Debido a la peculiaridad comentada en la implementación de que

Java no posee tipos sin signo, también se debe comprobar los valores límite de los

campos de cada paquete para que al desaplanarlo no obtengamos números negativos,

por lo tanto los campos serán configurados con valores lo suficientemente altos para


que sea un número negativo en caso de que el desaplanamiento no funcione. Además,

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.

5.6.2 Prueba 2: Envío y Recepción con los Nokia

Como se ha especificado en los requisitos, algunos móviles, como el Nokia N73,

necesitan que se les envíe determinados paquetes RTP de vuelta (paquetes dummy),

por lo que esta prueba verifica si el envío y recepción desde un dispositivo real

funciona, verificando los requisitos 3, 4, 7, 8, 9, 10 y 11:

Para comprobar esta funcionalidad, se construyó una infraestructura análoga a la

que se puede observar en la ilustración 28, que permitiese una conexión entre la

librería y el móvil a través del Asterisk; una vez que la librería recibía los paquetes

RTP, se reenviaban a una aplicación VLC para comprobar su correcta visualización.

Además, con esta infraestructura se permite también verificar la prueba anterior de

Ilustración 27: Prueba 1: Aplanamiento y desaplanamiento de paquetes


aplanadores y desaplanadores y una nueva funcionalidad, la retro alimentación de

información a través de paquetes RTCP al emisor del flujo (el terminal móvil). Para

ello el móvil debía ser configurado para enviar el flujo de datos contra el enlace, en

este caso el Asterisk, y a su vez configurar la librería para recibir dicho flujo de datos

reenviados por el mismo Asterisk y viceversa, que el propio Asterisk reenvíe los

paquetes tanto RTP (dummies) como los RTCP al móvil. Además, se debe comprobar

que la inclusión de la librería no provoca impedimentos ni fallas de sincronía, por lo

que también se realizaron pruebas en este ámbito.

Ilustración 28: Prueba 2


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 ilustración 29; consistirá en

dos aplicaciones VLC ejecutando de forma local, una enviando vídeo y otra

recibiendo. De esta forma, se podrá probar si la el scheduler de la librería funciona

eficazmente, si ordenamos paquetes de forma correcta y si la librería es capaz de

simular y absorber retrasos, en definitiva, probar la funcionalidad del buffer.

Ilustración 29: Prueba 3


5.7 API y Tutorial de Uso

La API en una librería es una parte importante en la descripción informática, ya

que indicará a los desarrolladores como utilizar de forma correcta y eficiente dicha

librería. Para ello se usa una utilidad que proporciona Sun para la generación de

documentación de APIs en formato HTML a partir del código Java, el conocido

Javadoc44. Además, se detallará ejemplos útiles a continuación.

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 Packet,

aunque dichas clases no existan como tal en la implementación.

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 proporcionarán el aplanador correspondiente. Para desaplanar un paquete

tendremos que llamar al método marshall que recibe como parámetro un

ByteBuffer (por reutilización) y devuelve un ByteBuffer con el conjunto de bytes

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, después llamamos a la función marshall.

Las clases de tipo ByteBuffer son RtpByteBuffer y Rtcp

[TipoRtcp]ByteBuffer. Dichas clases, nos permiten desaplanar un conjunto de bytes

y convertirlos en un objeto mediante el método 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 método getPacket que proporciona el paquete

RtPacket.

44 http://java.sun.com/j2se/javadoc/


Así, el uso de estas clases será el siguiente:

1. Desaplanamiento:

1.1. Se recibe un conjunto de bytes (se explica más 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 través del método

getPacket el objeto de tipo RtpPacket.

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 método marshall de la clase RtpPacket obteniendo un

objeto ByteBuffer con el conjunto de bytes que serán enviados por la red.

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


5.7.2 Inicio de sesiones

La sesión RTP será el “núcleo” de la librería, servirá para añadir nuevas fuentes,

sincronizarlas, crear los hilos necesarios e implementará el envío y recepción de

información a bajo nivel, ya que se encargará de la gestión de los canales, aunque las

clases RtpReceiver, RtcpReceiver, RtpSender y RtcpSender serán las encargadas

de la gestión a alto nivel del envió y recepción de paquetes. Para iniciar una sola

sesión de RTP, tendremos que utilizar uso de algunos de los diferentes constructores

que existen. El constructor de la clase RtpSession recibe como parámetros

obligatorios:

• localAddress: la dirección local.

• inputPortV, inputPortA: puertos en los que la librería recibirá el vídeo y

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);

Texto 13: Aplanamiento de paquete RTP/RTCP


audio respectivamente.

• outputPortV, outputPortA: puertos en los que la librería enviará el vídeo y

audio.

• remotePortV, remotePortA: puertos de la aplicación emisora desde donde se

enviarán loas paquetes RTP. Estos puertos son necesarios para el envío de

paquetes de vuelta, como los paquetes de control RTCP y o los paquetes RTP

vacíos 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 canónico que tendrá la sesión RTP.

• haveRtcpSession: variable booleana que indicará si la sesión RTP se iniciará

con control de paquetes (RTCP).

Además, otros constructores podrán tener otras parámetros interesantes como:

• delayMillis, delayPackets: retraso con el que tendrá que iniciar la emisión

de datos por parte de la librería, en milisegundos o paquetes respectivamente.

• isSynchronized: parámetro que indica si ambos flujos (audio y vídeo) deben

ser sincronizados por la librería.

• millisVideo, millisAudio: parámetros que indicarán si el flujo de vídeo o

audio llegará a la librería con un retraso respecto al otro flujo. Es decir, si el

parámetro 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 parámetro es negativo, el numero de paquetes correspondientes a dichos

milisegundos deberán ser tirados al inicio de la conexión (no se almacenarán ni

se reenviarán). El cálculo para realizar la conversión entre milisegundos a

paquetes es descrita más adelante.

• packetsVideo, packetsAudio: análogo al anterior, pero con paquetes en lugar

de milisegundos.

En el texto 14 podemos observar un ejemplo en el que iniciamos una sesión RTP.


5.7.3 Buffers

Los buffers se pueden crear para diferentes propósitos como hemos visto

anteriormente, siendo los parámetros de este constructor los siguientes:

• capacity: Establece la capacidad máxima 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: tamaños máximo y mínimos (usados para la

sincronización).

• ssrc: identificador de los paquetes que almacenará el buffer.

El buffer tendrá métodos para extraer los paquetes del buffer, aunque siempre se

extraerán los paquetes que sean del mismo instante de reproducción (timestamp

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();

}}

Texto 14: Creación de sesión RTP


iguales). El buffer al actuar como una cola ordenada, extraerá los paquetes con menor

timestamp, los métodos para extraer paquetes e introducir un paquete en el buffer son:

• take: No recibe parámetros, devuelve una lista de tipo

ArrayList45<RtpPacket>, con los paquetes con menor e igual timestamp del

buffer.

• put: Recibe como parámetro un objeto de tipo RtpPacket, que será el paquete

que se introducirá de forma ordenada en el buffer.

Además, la clase buffer ofrece métodos para poder manejar el contenido. Estos

métodos auxiliares son:

• isEmpty: No recibe parámetros, devuelve un tipo primitivo boolean, True si el

buffer está vacío, False en caso contrario.

• size: No recibe parámetros, devuelve un tipo primitivo int con el numero de

paquetes en el buffer.

• getDiffTs: No recibe parámetros, 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 método configure de la clase

RtpBufferList. Este método, a su vez, llamará al método configure de la clase

RtpBuffer, cuya implementación 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 conexión. Un ejemplo de configuración y utilización 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


5.7.4 Channels

La configuración de los canales es una parte importante de la librería, pues el

correcto y eficiente funcionamiento del envío y recepción de datos depende de ello. La

librería proporciona el método configureChannel que permite configurar un canal

listo para recibir y enviar datos. Como se puede observar en el texto 17, este método

recibe dos parámetros:

• address: objeto Java InetSocketAddress46, contiene toda la información

(dirección IP y puerto) que se necesita para que el canal pueda recibir y enviar

datos a dicha dirección.

• blocking: tipo primitivo boolean que establece si el canal será bloqueante o

no. Esto es debido a que los canales de recepción serán no bloqueantes pero los

de envío serán bloqueantes.

46 http://java.sun.com/j2se/1.5.0/docs/api/java/net/InetSocketAddress.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);

}

Texto 15: Configuración del buffer

public void configure(long pStore, long pThrow) {this.packetStore = pStore;this.packetThrow = pThrow;this.minSize = (int) pStore;

}

Texto 16: Configuración del buffer


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: Configuración de canales

CAPÍTULO 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 librería fiable, con capacidad de integración en

otros sistemas y facilidad de uso. Además, la librería 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 realización de este proyecto son los

siguientes:

• Aprendizaje del lenguaje de programación Java: algunos aspectos como el

control de Threads o la clase ByteBuffer no se conocían con anterioridad.

• Aprendizaje de realización de una librería: La creación de esta librería ha

ayudado a saber como se realiza una librería correctamente.

• Aprendizaje de implementación de protocolos: Análogo al punto anterior, pero

en este caso, con protocolos de comunicación en stream (el RTP).

102

CAPÍTULO 6. CONCLUSIONES Y TRABAJOS FUTUROS 103

• Tecnología SIP: Al haber usado en las pruebas negociación SIP para la

videollamada, he tenido que aprender algunos aspectos de esta protocolo, como

mensajes o la semántica.

• Configuración de aplicaciones: Como el VLC o X-Lite.

6.3 Trabajos Futuros:

Durante el desarrollo de la librería, tanto las necesidades descubiertas como las

alternativas existentes han hecho posible que se pueda recoger algunas ideas que

podrían servir de base de futuros proyectos.

Algunos de ellos son:

• Crear nuevos módulos, al igual que se han creado los modulo de envío y

recepción de la red, se pueden realizar módulos de lectura y escritura en

ficheros, u otros módulos que cumplan un patrón productor-consumidor.

• Integración de la librería con librerías de códecs que permitan la fácil

codificación entre diferentes tipos de vídeo o audio.

APÉNDICE A

CONFIGURACIÓN DE VLC Y X-LITE

VLC

En las pruebas que se utilice la aplicación VLC, se lanzarán desde la linea de

comandos y leerán un fichero en formato SDP. Dicho fichero deberá llevar datos sobre

el emisor, los puertos de escucha y los códecs.

104

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: Configuración VLC para Prueba 3

En este caso, el código 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 parámetros por linea de

comandos.

X-Lite

La aplicación X-Lite debe ser configurada de la siguiente forma:

Se debe crear al menos una cuenta con los datos necesarios: dichos datos serán:

Display Name: nombre del usuario, puede ser cualquiera, a elección del usuario.

User Name: nombre del usuario que se registrará en la sesión SIP, debe ser

proporcionado por el proveedor.

Authorization user name: datos proporcionados por el proveedor.

Domain: dirección Ip y puerto contra el que se iniciará la aplicación X-Lite.

/opt/vlc/bin/vlc Shrek3.3gp --sout "#rtp{dst=localhost,port-video=10018,port-

audio=10016,octect-align}" -vvv

Texto 19: Parámetros por linea de comando del emisor

BIBLIOGRAFÍA

[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] Librería ortp:

http://www.linphone.org/index.php/eng/code_review/ortp

[4] Librería JRTPLIB:

http://research.edm.uhasselt.be/~jori/page/index.php?n=CS.Jrtplib

106

http://research.edm.uhasselt.be/~jori/page/index.php?n=CS.Jrtplib

http://es.wikipedia.org/wiki/Plataforma_Java

http://www.linphone.org/index.php/eng/code_review/ortp

http://es.wikipedia.org/wiki/Plataforma_Java

Documents

RtpLib - Una librería en Java de los protocolos RTP y RTCP (2008-2009)