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
CAPITULO 1: INTRODUCCIÓN 12
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
CAPITULO 1: INTRODUCCIÓN 13
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.
CAPITULO 1: INTRODUCCIÓN 14
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
CAPÍTULO 3. CONTEXTO Y MARCO DE TRABAJO 19
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
CAPÍTULO 3. CONTEXTO Y MARCO DE TRABAJO 20
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
CAPÍTULO 3. CONTEXTO Y MARCO DE TRABAJO 21
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
CAPÍTULO 3. CONTEXTO Y MARCO DE TRABAJO 22
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
CAPÍTULO 3. CONTEXTO Y MARCO DE TRABAJO 23
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
CAPÍTULO 3. CONTEXTO Y MARCO DE TRABAJO 24
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
CAPÍTULO 3. CONTEXTO Y MARCO DE TRABAJO 25
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
CAPÍTULO 3. CONTEXTO Y MARCO DE TRABAJO 26
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.
CAPÍTULO 3. CONTEXTO Y MARCO DE TRABAJO 27
• 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
CAPÍTULO 3. CONTEXTO Y MARCO DE TRABAJO 28
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
CAPÍTULO 3. CONTEXTO Y MARCO DE TRABAJO 29
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
CAPÍTULO 3. CONTEXTO Y MARCO DE TRABAJO 30
espacio de trabajo, en este caso un grupo de metadatos en un espacio para archivos
plano, permitiendo modificaciones externas a los archivos en tanto se refresque el
espacio de trabajo correspondiente.
3.5.4 Wireshark
Una necesidad 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
CAPÍTULO 3. CONTEXTO Y MARCO DE TRABAJO 31
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
CAPÍTULO 3. CONTEXTO Y MARCO DE TRABAJO 32
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
CAPÍTULO 3. CONTEXTO Y MARCO DE TRABAJO 33
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
CAPÍTULO 3. CONTEXTO Y MARCO DE TRABAJO 34
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
CAPÍTULO 4. EL PROTOCOLO RTP: ESPECIFICACIÓN 37
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
CAPÍTULO 4. EL PROTOCOLO RTP: ESPECIFICACIÓN 38
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.
CAPÍTULO 4. EL PROTOCOLO RTP: ESPECIFICACIÓN 39
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
CAPÍTULO 4. EL PROTOCOLO RTP: ESPECIFICACIÓN 40
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
CAPÍTULO 4. EL PROTOCOLO RTP: ESPECIFICACIÓN 41
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.
CAPÍTULO 4. EL PROTOCOLO RTP: ESPECIFICACIÓN 42
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.
CAPÍTULO 4. EL PROTOCOLO RTP: ESPECIFICACIÓN 43
Tendiendo en cuenta las definiciones de aplanamiento y desaplanamiento, cuando se
desarrolla un protocolo, el emisor será el que aplane el mensaje, mientras que el
receptor recibe los bytes y los desaplana. Para que el esquema funcione, se deben
definir e implementar una serie de reglas de 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
CAPÍTULO 4. EL PROTOCOLO RTP: ESPECIFICACIÓN 44
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.
CAPÍTULO 4. EL PROTOCOLO RTP: ESPECIFICACIÓN 45
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
CAPÍTULO 4. EL PROTOCOLO RTP: ESPECIFICACIÓN 46
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.
CAPÍTULO 4. EL PROTOCOLO RTP: ESPECIFICACIÓN 47
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
CAPÍTULO 4. EL PROTOCOLO RTP: ESPECIFICACIÓN 48
length: 16 bits
La longitud del paquete RTCP en palabras de 32 bits menos uno, incluyendo
cabeceras y padding.
SSRC: 32bits
El identificador de la fuente de 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.
CAPÍTULO 4. EL PROTOCOLO RTP: ESPECIFICACIÓN 49
cumulative number of packets lost: 24 bits
El numero total de paquetes RTP de la fuente SSRC_n que se han perdido desde el
comienzo de la 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
CAPÍTULO 4. EL PROTOCOLO RTP: ESPECIFICACIÓN 50
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
CAPÍTULO 4. EL PROTOCOLO RTP: ESPECIFICACIÓN 51
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
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 54
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.
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 55
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.
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 56
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.
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 57
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
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 58
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
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 59
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.
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 60
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)
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 61
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).
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 62
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
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 63
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
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 64
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
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 65
Ilustración 16: Diagrama de colaboración: Uso del buffer
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 66
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
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 67
ejemplo, en el caso del timestamp, recibimos 32 bits, pero si lo introducimos en
una variable de tipo int, si el timestamp es superior o igual a 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
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 68
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
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 69
• rj: momento temporal en que fue enviado el anterior paquete.
• curj: jitter anterior. Si es la primera que es calculado debe ser cero.
5.5.2 Diagramas de clases de 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
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 70
• 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)
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 71
5.5.2.2 Paquete receivers.rtcp, receivers.rtp y sender
• RtpSession: Por cada flujo de datos RTP que se establezca entre dos nodos de
la red, se creará una RtpSession, clase principal que controlará todo el proceso
de intercambio de datos. Como se puede observar en la 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
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 72
los paquetes cada cierto intervalo de tiempo, definido por el timestamp.
HashMap<Long,MediaSource>: La clase RtpSession, para almacenar las
diferentes fuentes utilizará un HashMap39, que permita acceder de forma 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
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 73
• 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
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 74
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.
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 75
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
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 76
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
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 77
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
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 78
Ilustración 21: Recepción/Envío de RTP
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 79
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
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 80
Ilustración 22: Envío de paquete RTP con buffer
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 81
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.
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 82
Ilustración 23: Recepción de paquetes RTP con buffer
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 83
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.
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 84
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
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 85
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
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 86
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
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 87
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
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 88
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
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 89
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.
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 90
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
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 91
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
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 92
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
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 93
5.6.3 Prueba 3: Uso del buffer
Finalmente, la ultima prueba es comprobar los requisitos 2, 5, 6 y12. La
infraestructura para esta prueba se puede observar en la 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
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 94
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/
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 95
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
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 96
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
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 97
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.
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 98
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
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 99
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
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 100
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
CAPÍTULO 5. DESCRIPCIÓN INFORMÁTICA 101
public static DatagramChannel configureChannel(InetSocketAddress address, boolean blocking) throws IOException {
DatagramChannel channel = DatagramChannel.open();channel.configureBlocking(blocking);DatagramSocket socket = channel.socket();socket.bind(address);socket.setReuseAddress(true);socket.setSendBufferSize(SO_UDP_BUFFER_SIZE);socket.setReceiveBufferSize(SO_UDP_BUFFER_SIZE);return channel;
}
Texto 17: 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