Universidad Carlos III de Madrid

Escuela Politcnica Superior

Ingeniera Tcnica de Telecomunicaciones: especialidad en Sonido e Imagen

Proyecto Fin de Carrera

UPnP Media Renderer para plataforma OSGi

Autor: Francisco Mota Porta

Tutor: Julio ngel Cano Romero

Julio de 2009

Agradecimientos
Este proyecto fin de carrera supone el fin de una etapa en mi vida, y el comienzo de otra an por
descubrir. Es momento por tanto para la reflexin, echar un vistazo atrs y recuperar aquellos
momentos que han marcado huella. Entre todos ellos aparecen los vividos con compaeros,
profesores y personal de la universidad. Tengo pues que agradecerles a todos ellos el haberme
permitido llegar hasta aqu. En especial, a aquellas personas que con su labor y actitud de proximidad
al otro hacen que el trayecto sea ms ameno y el aprendizaje ms interesante.
Mi primer agradecimiento personalizado es para mi tutor, Julio, por su atencin y dedicacin durante
todo el proceso de elaboracin del presente proyecto. Gracias a sus compaeros de despacho, Javier
y Mario, por sus prcticos consejos. Y tambin a Natividad por habrmelo ofrecido.
Gracias a mis padres, a mis hermanas y a sus respectivas parejas por el respeto, apoyo y cario que
demuestran en todo lo que hago, y en especial en lo que respecta a este proyecto.
A todos mis amigos, gracias por su cario y comprensin durante todo este tiempo que he estado
sumergido en esta labor.
Por ltimo, quiero hacer un agradecimiento especial a dos amigas, Irene y Marina, que se han
convertido en cmplices de mi tiempo en esta universidad y con las que he compartido muchos y muy
buenos momentos.

Resumen
El aumento del equipamiento electrnico de los hogares provoca que las compaas
tecnolgicas (informtica, audiovisuales, telecomunicaciones,...) colaboren unas con otras con el
objetivo de crear nuevos estndares que permitan la interoperabilidad entre estos dispositivos.
Universal Plug and Play (UPnP) es un ejemplo de estos estndares, promovido por el UPnP
Forum. Esta tecnologa define un conjunto de protocolos comunes basados en Internet que los
dispositivos pueden utilizar para agregarse a una red y describirse a s mismos y sus capacidades.
Esto permite que otros dispositivos y personas puedan usarlos sin tener que realizar ninguna
configuracin. Esta interoperabilidad entre diferentes tipos de dispositivos puede resultar realmente
til para nuevos sistemas multimedia integrados en los entornos de red del hogar. En este sentido, el
Foro UPnP especifica una arquitectura para dispositivos audiovisuales, la UPnP AV Architecture. Esta
arquitectura define la interaccin entre un Punto de Control UPnP para audio y video (UPnP AV
Control Point) y un dispositivo UPnP para audio y video (UPnP AV Device).
Un UPnP AV Control Point maneja y coordina la comunicacin entre un dispositivo servidor
de contenido multimedia, denominado MediaServer, y un dispositivo consumidor de contenido
multimedia, denominado MediaRenderer. Esta comunicacin permite a un usuario compartir todo el
contenido multimedia localizado por los dispositivos UPnP MediaServer y reproducirlo en cualquier
dispositivo UPnP MediaRenderer que est agregado a su red UPnP.
A parte de esto, el incremento del uso de dispositivos avanzados como las Pasarelas de
Servicios, para combinar las diferentes redes domsticas y conectarlas con el exterior (a travs de
Internet), estimula el desarrollo software de aplicaciones y servicios para ser ejecutados en estas
pasarelas. La tecnologa OSGi proporciona una plataforma software para el desarrollo de este tipo de
aplicaciones y servicios.
Este proyecto presenta una solucin para un dispositivo software UPnP MediaRenderer
conforme a una aplicacin OSGi.

Abstract
Electronic home equipment increase forces to the technological companies (informatics,
audiovisuals, telecommunications, etc) to collaborate ones each others with the purpose of making
new standards for interoperability among devices.
Universal Plug and Play (UPnP) is an example of these standards. It is promoted by the UPnP
Forum. This technology defines a set of common Internet-based protocols that devices can use to join
a network and describe themselves and their capabilities, which enables other devices and people to
use them without setup or configuration. This interoperability among different kinds of devices can be
really useful for new multimedia systems in home network environments. In this regard, the UPnP
Forum specifies an architecture for audiovisual devices, the UPnP AV Architecture. This architecture
defines the general interactions between an UPnP AV Control Point and an UPnP AV Device.
An UPnP AV Control Point manages and coordinates the communication between a source
device of media content (called MediaServer), and a sink device for that content (called
MediaRenderer). This communication allows users to share all available media content located on
UPnP MediaServers and to render it on whatever UPnP MediaRenderer joined to their UPnP network.
A part from that, the increase use of advanced devices like Service Gateways to combine the
different domestic networks and interconnects them with the outside (thought Internet), promotes
software development of applications and services to be executed in this gateways. The OSGi
technology provides a software platform to develop this kind of applications and services.
This project introduces a solution for an UPnP MediaRenderer software device according to
an OSGi application.

ndice
1. Introduccin........................................................................................................................1
1.1 Motivacin ......................................................................................................................1
1.2 Objetivos del proyecto ....................................................................................................2
1.3 Contenido de la memoria ...............................................................................................2
2. Marco terico......................................................................................................................4
2.1 Universal Plug and Play (UPnP).....................................................................................4
2.1.1 Introduccin .............................................................................................................4
2.1.2 Componentes de una red UPnP..............................................................................5
2.1.3 Protocolos usados por UPnP ..................................................................................7
2.1.4 Fases de la comunicacin UPnP.............................................................................8
2.1.5 Arquitectura UPnP para Audio y Video .................................................................15
2.1.6 UPnP MediaRenderer ...........................................................................................19
2.1.7 Limitaciones de UPnP ...........................................................................................29
2.1.8 Justificacin del uso de UPnP ...............................................................................30
2.2 JMF ..............................................................................................................................30
2.2.1 Introduccin ...........................................................................................................30
2.2.2 Principales clases e interfaces de la librera JMF .................................................32
2.2.3 Player ....................................................................................................................33
2.2.4 Soporte a RTP en la librera JMF ..........................................................................35
2.2.5 Extender la librera JMF ........................................................................................37
2.2.6 Justificacin del uso de JMF .................................................................................37
2.3 OSGi.............................................................................................................................38
2.3.1 Introduccin ...........................................................................................................38
2.3.2 Caractersticas de la especificacin ......................................................................39
2.3.3 Arquitectura software ............................................................................................39
2.3.5 Justificacin del uso de OSGi................................................................................43
2.4 Resumen de la utilizacin de las tecnologas...............................................................43
2.5 Estado del arte .............................................................................................................44
2.5.1 Implementaciones UPnP MediaRenderer .............................................................44
2.5.2 JMF y alternativas .................................................................................................46
2.5.3 Implementaciones software de OSGi ....................................................................48
3. Implementacin ................................................................................................................50
3.1 Anlisis de requisitos....................................................................................................50
3.1.1 Casos de uso ........................................................................................................51
3.2 Herramientas utilizadas ................................................................................................53
3.3 Implementacin de la aplicacin: HomeAV ..................................................................55
3.3.1 Introduccin ...........................................................................................................55
3.3.2 HomeAV ................................................................................................................57
3.3.3 Arquitectura de clases ...........................................................................................58
3.3.4 Diagramas de secuencia .......................................................................................70
3.3.5 Estados de la renderizacin ..................................................................................83
4. Pruebas .............................................................................................................................86
4.1 Introduccin ..................................................................................................................86
4.1.1 Escenario de pruebas ...........................................................................................86
4.1.2 Condiciones de la toma de datos ..........................................................................87
4.2 Caso 1: Fase de Descubrimiento .................................................................................87
4.3 Caso 2: Reproduccin de ficheros de audio y video ....................................................89
5. Conclusiones....................................................................................................................93
5.1 Conclusiones ................................................................................................................93
5.2 Limitaciones .................................................................................................................94
5.3 Lneas futuras de trabajo..............................................................................................95

ANEXOS
ANEXO I: Cidero/Cyberlink..................................................................................................96
1. Introduccin ....................................................................................................................96
2. Implementacin del dispositivo con Cyberlink................................................................96
3. Implementacin de los servicios con Cidero ................................................................101
ANEXO II: Modificaciones en Cidero................................................................................103
1. Introduccin ..................................................................................................................103
2. Primer objetivo: Correcto desarrollo de la comunicacin UPnP...................................103
3. Segundo objetivo: Adaptacin para la integracin en un bundle OSGi........................107
ANEXO III: Diagramas UML ...............................................................................................113
1. Introduccin ..................................................................................................................113
2. Diagrama de Casos de Uso .........................................................................................113
3. Diagrama de Clases .....................................................................................................114
3.1 Introduccin ............................................................................................................114
3.2 Clase ......................................................................................................................114
3.3 Relaciones entre Clases.........................................................................................115
4. Diagrama de Secuencias .............................................................................................117
4.1 Introduccin ............................................................................................................117
4.2 Objeto/Actor ...........................................................................................................118
4.3 Mensaje a Otro Objeto ...........................................................................................118
4.4 Mensaje al Mismo Objeto .......................................................................................118
ANEXO IV: Ficheros de la aplicacin ...............................................................................119
1. Fichero de configuracin ..............................................................................................119
2. Documento descriptor del dispositivo UPnP ................................................................120
ANEXO V: Instrucciones de instalacin...........................................................................121
1. Requerimientos del sistema .........................................................................................121
2. Requerimientos de la aplicacin ..................................................................................121
ANEXO VI: Presupuesto ....................................................................................................122
1. Fases del proyecto .......................................................................................................122
2. Costes ..........................................................................................................................123
ANEXO VII: Bibliografa .....................................................................................................125
ANEXO VIII: Glosario .........................................................................................................129

ndice de figuras
Figura 2.1. Esquema Puntos de Control, Dispositivos y Servicios ....................................................6
Figura 2.2. Ejemplo componentes UPnP .......................................................................................7
Figura 2.3. Esquema de las fases de la comunicacin UPnP ..........................................................8
Figura 2.4. Esquema de la fase de Descubrimiento UPnP ..............................................................9
Figura 2.5. Esquema de la fase de Descripcin de UPnP .............................................................10
Figura 2.6. Esquema del mecanismo de Control de UPnP ............................................................13
Figura 2.7. Esquema del mecanismo de Eventos de UPnP ...........................................................14
Figura 2.8. Esquema del mecanismo de Presentacin de UPnP....................................................15
Figura 2.9. Escenarios AV en la red domstica ............................................................................16
Figura 2.10. Arquitectura AV UPnP .............................................................................................16
Figura 2.11. Diagrama general de interaccin ..............................................................................21
Figura 2.12. Capas de la arquitectura software de JMF ................................................................31
Figura 2.13. Analoga del funcionamiento de JMF ........................................................................32
Figura 2.14. Etapas del procesamiento de un Player ....................................................................33
Figura 2.15. Estados del Player ..................................................................................................34
Figura 2.16. Torre de protocolos para RTP/RTCP ........................................................................35
Figura 2.17. Esquema del proceso de recepcin RTP ..................................................................36
Figura 2.18. Esquema del proceso de transmisin RTP ................................................................36
Figura 2.19. Pasarela de Servicios OSGi (Pasarela Domstica) ....................................................39
Figura 2.20. Capas de la Arquitectura Software de OSGi ..............................................................40
Figura 2.21. Ciclo de vida de un bundle ......................................................................................42
Figura 2.22. Esquema de los Servicios Estndar de OSGi ............................................................43
Figura 3.1. Diagrama de Casos de Uso .......................................................................................51
Figura 3.2. Interfaz Grfica de HomeAV ......................................................................................57
Figura 3.3. Diagrama de Clases de HomeAV ...............................................................................59
Figura 3.4. Diagrama de secuencia del arranque de la aplicacin ..................................................71
Figura 3.5. Diagrama de secuencia de recepcin de solicitud HTTP ..............................................72
Figura 3.6. Diagrama de secuencia de la obtencin del descriptor .................................................73
Figura 3.7. Diagrama de secuencia de la subscripcin a un servicio ..............................................74
Figura 3.8. Diagrama de secuencia de invocacin a una accin ....................................................76
Figura 3.9. Diagrama de secuencia de la accin SetAVTransportURI() (HTTP)...............................77
Figura 3.10. Diagrama de secuencia de la accin Play() (HTTP) ...................................................78
Figura 3.11. Diagrama de secuencia de la accin SetAVTransportURI() (RTP) ...............................79
Figura 3.12. Diagrama de secuencia de la accin Play() (RTP) .....................................................80
Figura 3.13. Diagrama de secuencia de la accin SetNextAVTransportURI() ..................................81
Figura 3.14. Diagrama de secuencia de la notificacin de eventos.................................................82
Figura 3.15. Diagrama de estados de la renderizacin .................................................................84
Figura 4.1. Escenario de pruebas ...............................................................................................86
Figura 4.2. Captura de la consola y la interfaz grfica de HomeAV en la instalacin y arranque del
bundle (Equipo 1)......................................................................................................................88
Figura 4.3. Captura de la Interfaz Grfica de Cidero (Descubrimiento de HomeAV).........................88
Figura 4.4. Captura de la interfaz grfica de Cidero y el panel que provee para el UPnP
MediaRenderer .........................................................................................................................89
Figura I.1. Servidores HTTP del dispositivo .................................................................................97
Figura I.2. Diagrama de Clases de Cyberlink para dispositivos ....................................................100
Figura I.3. Diagrama de Clases de Cidero para servicios de un UPnP MediaRenderer ..................102

ndice de tablas
Tabla 2.1. Acciones del servicio RenderinControl Service .............................................................23
Tabla 2.2. Variables de estado del servicio RenderinControl Service .............................................25
Tabla 2.3. Acciones del servicio ConnectionManager Service .......................................................25
Tabla 2.4. Variables de estado del servicio ConnectionManager Service ........................................26
Tabla 2.5. Acciones del servicio AVTransport Service ..................................................................27
Tabla 2.6. Variables de estado del servicio AVTransport Service ...................................................29
Tabla 2.7. Formatos soportados por JMF ....................................................................................47
Tabla 2.8. Formatos RTP soportados por JMF .............................................................................47
Tabla 3.1. Casos de Uso frente a requisitos ................................................................................53
Tabla 3.2. Composicin del Mdulo raz ......................................................................................60
Tabla 3.3. Composicin del Mdulo UPnP ...................................................................................61
Tabla 3.4. Composicin del Mdulo multimedia ...........................................................................64
Tabla 4.1. Caractersticas de los equipos utilizados......................................................................87
Tabla 4.2. Caractersticas de los ficheros de audio y video utilizados .............................................90
Tabla 4.3. Tiempos de respuesta para la reproduccin (HTTP) .....................................................90
Tabla 4.4. Tiempos de respuesta para la reproduccin (RTP) .......................................................92
Tabla I.1. Parmetros configurables de la clase Device ................................................................98
Tabla VI.1. Costes materiales ..................................................................................................123
Tabla VI.2. Costes de mano de obra .........................................................................................124
Tabla VI.3. Presupuesto total ...................................................................................................124

ndice de cuadros de texto

Cuadro de texto 2.1. XML de descripcin de un dispositivo ...........................................................11
Cuadro de texto 2.2. XML de descripcin de un servicio ...............................................................12
Cuadro de texto 3.1. Mtodo mediaRendererEventReceived() de AVTransportService ....................63
Cuadro de texto 3.2. Mtodo play() de MediaRenderer .................................................................65
Cuadro de texto 3.3. Mtodo createPlayer() de la clase HTTPRenderer .........................................67
Cuadro de texto 3.4. Mtodo initializeRTPSession() de RTPReceiver ............................................69
Cuadro de texto II.1. Mtodo getHostAddress() de [Link]...................105
Cuadro de texto II.2. Mtodo httpGetRequesteReceived() de [Link] .........106
Cuadro de texto II.3. Mtodo receive() de [Link].................107
Cuadro de texto II.4. Mtodo setHost() de [Link] ...............................107
Cuadro de texto II.5. Mtodo parseInputStream(InputStream) de [Link] .......108
Cuadro de texto II.6. Mtodo loadDescription(InputStream) de [Link] ........108
Cuadro de texto II.7. Cdigo modificado del mtodo getSPDNode() de [Link]

.............................................................................................................................................109
Cuadro de texto II.8. Mtodo getSCPDNode(InputStream) de [Link] ........109
Cuadro de texto II.9. Mtodo setServiceDescriptionURL() de [Link] .........110
Cuadro de texto II.10. Mtodo getServiceDescriptionURL() de [Link] .......110
Cuadro de texto II.11. Constructor de la clase abstracta [Link] ............111
Cuadro de texto II.12. Constructor de la clase [Link] ...............................112
Cuadro de texto II.13. Constructor de la clase [Link] ....................112
Cuadro de texto II.14. Constructor de la clase [Link] ........................112
Cuadro de texto IV.1. Fichero de configuracin de HomeAV ([Link]) ..............................119
Cuadro de texto IV.2. Documento XML de descripcin del dispositivo HomeAV ............................120

1. Introduccin

1. Introduccin
Este captulo sirve de introduccin a este proyecto fin de carrera. Primeramente se expondrn
las motivaciones que impulsan su realizacin, presentando los conceptos base del mismo.
Posteriomente, se enumerarn los objetivos marcados para este proceso. Y en ltimo lugar, se
describir la estructura del presente documento.

1.1 Motivacin
La evolucin de los hogares hacia la integracin de sistemas informticos provoca la
proliferacin de mltiples equipos y sistemas electrnicos que ofrecen distintos servicios con el
propsito de facilitar tareas y entretener al usuario de stos. Sin embargo, hasta hace poco estos
dispositivos permanecan aislados sin posibilidad de compartir sus servicios o poder utilizar los de
otros dispositivos. En este sentido, se hace necesario proporcionar tecnologas que permitan
conectarlos entre s y con el exterior a travs de la red domstica, generando servicios ms
avanzados y facilitando la gestin de los mismos. De este forma, se sientan las bases de lo que se ha
venido a definir como el Hogar Digital.
Existen varias iniciativas que pretenden dar soluciones a la conectividad entre dispositivos,
proporcionando tecnologas de comunicacin diferentes y en muchos casos incompatibles. Ejemplo
de ellas son: HomePNA, HomePlug, x10, LonWorks, HAVi (Home Audio Video Interoperability), JINI,
etc.
Con el mismo propsito surgi la tecnologa UPnP (Universal Plug and Play), la cual define un
arquitectura para el descubrimiento automtico y dinmico de dispositivos, y el intercambio de
informacin y datos entre los mismos. Est impulsada por el UPnP Forum y basada en protocolos
estndar de Internet como IP, TCP, UDP, HTTP y XML.
En lo que se refiere a sistemas de entretenimiento digital, ms all de la comunicacin,
resulta tedioso que en la mayora de estos sistemas, para poder reproducir el contenido multimedia
almacenado en un equipo se deba acudir al correspondiente reproductor instalado en el mismo. Para
ello, UPnP especifica una arquitectura, UPnP AV Architecture, con la que el contenido multimedia
localizado por un dispositivo puede ser compartido en la red UPnP y ser reproducido remotamente en
dispositivos reproductores distribuidos por esta. A los dispositivos que proveen el contenido
multimedia se les denomina UPnP MediaServer, mientras que los que los consumen son llamados
UPnP MediaRenderer. La comunicacin entre ambas entidades se realiza por medio de una tercera
entidad coordinadora denomina Punto de Control para Audio y Video (en Ingls AV Control Point),
que adems controla el proceso de reproduccin de forma remota.
Al hilo de esto, parece que el futuro, ya muy presente, del Hogar Digital pasa por la utilizacin
de un elemento que integre las distintas redes domsticas (HomePAN, LonWorks, HAVi, UPnP,...) y
las interconecte con el exterior. Este elemento es conocido como Pasarela Residencial, tambin
como Pasarela Domstica, o de forma ms general Pasarela de Servicios. La Pasarela Residencial
conecta las infraestructuras de telecomunicaciones (datos, control, automatizacin, etc.) de la
vivienda a una red pblica de datos, como por ejemplo Internet, y sirve de plataforma de ejecucin
para las aplicaciones domsticas, todo ello de manera transparente para el usuario.
Debido a la diversidad de tecnologas existentes en los hogares, se hace evidente la
necesidad de un estndar comn que establezca un marco de trabajo sobre el que las compaas
puedan desarrollar servicios y aplicaciones para las pasarelas, sin tener que preocuparse por
aspectos de bajo nivel como tecnologas de red o hardware. En este mbito de necesidad nace OSGi
(Open Services Gateway Initiative) como estndar que define una arquitectura software que se
ejecuta en una pasarela residencial.
En consecuencia, toda aplicacin que se desarrolle para su utilizacin en redes domsticas
debe buscar la compatibilidad con tecnologas como OSGi.

1. Introduccin

Este Proyecto Fin de Carrera trata sobre el desarrollo de una aplicacin Java que conforma
un dispositivo UPnP para la reproduccin de contenido multimedia, de acuerdo a la especificacin
UPnP para dispositivos de audio y video, y para su ejecucin en plataformas de servicios OSGi como
las pasarelas residenciales.

1.2 Objetivos del proyecto

El objetivo final de este proyecto es el desarrollo de un prototipo de dispositivo UPnP
MediaRenderer para su integracin en plataformas OSGi con las siguientes caractersticas generales:
-

Programacin Java: la aplicacin habr de estar programada en Java.

Multiplataforma: se deber buscar una solucin que pueda ser utilizada tanto en
plataformas Windows como Linux.
Control de la renderizacin en remoto conforme al protocolo UPnP.
Compatibilidad IPv6: tendr que poder ser desplegada en escenarios conformes al
protocolo de red de nueva generacin IPv6.
Renderizacin de flujos HTTP, RTP e imgenes: ser capaz de reproducir contenidos de
audio y video obtenidos mediante flujos HTTP o RTP, as como visualizar imgenes.
Soporte a los formatos ms comunes: deber procesar el contenido con los formatos ms
comunes de codificacin ya sea audio, video o imgenes.

Para alcanzar este objetivo se definen los siguientes subobjetivos:

1. Estudiar las tecnologas implicadas para el diseo del prototipo:
a. Estudio de la tecnologa UPnP prestando mayor atencin en la especificacin
para un UPnP MediaRenderer. En este estudio se incluir un anlisis del estado
del arte de este tipo de dispositivos.
b. Estudio de la librera Java que se utilizar para proporcionar la capacidad de
reproduccin multimedia, Java Media Framework (JMF).
c. Estudio de la tecnologa OSGi para el desarrollo de aplicaciones que se integren
en escenarios gestionados por pasarelas de servicios.
2. Analizar los requisitos del sistema en base a las caractersticas generales mencionadas
anteriormente.
3. Construir un prototipo de UPnP MediaRenderer: a partir de los conocimientos obtenidos
en los objetivos previos se podr proceder a la implementacin de la aplicacin.
4. Asegurar el funcionamiento del prototipo en un escenario real y definir las limitaciones
derivadas de su diseo.

1.3 Contenido de la memoria

La presente memoria est estructurada en cinco captulos que resumen todo el proceso para
la consecucin de los objetivos anteriormente planteados. Adems se adjuntan ocho anexos.
Este primer captulo sirve de introduccin al proyecto, exponiendo los motivos de su
realizacin, as como los objetivos que se persiguen.
El segundo captulo conforma el marco terico del proyecto. Se incluyen sendos apartados
dedicados a cada una de las tecnologas sobre las que se fundamenta el desarrollo de la aplicacin:
UPnP, JMF y OSGi. Al final del captulo se incluye un apartado sobre el estado del arte, en el que se
har un breve anlisis de las soluciones de dispositivos UPnP MediaRenderer actuales, se evaluar
la situacin de la biblioteca multimedia JMF, planteando diferentes alternativas que resuelvan sus
limitaciones, y se enunciarn las principales implementaciones software de la plataforma OSGi.
El tercer captulo se hace el estudio sobre la implementacin del sistema. Primeramente se
analizarn los requisitos del mismo definiendo sus casos de uso, y posteriormente se enunciarn las
herramientas que han sido utilizadas en su desarrollo. Por ltimo se presentar el prototipo diseado
definiendo los mdulos en los que se compone, as como los paquetes y clases que lo componen. Se

1. Introduccin

utilizarn diagramas de secuencia de aquellos procesos que definen las principales funcionalidades
de la aplicacin.
El cuarto captulo recoge las pruebas realizadas al sistema en un entorno real de ejecucin, y
en las que se muestran la eficiencia de la aplicacin en los procesos ms importantes.
En el quinto y ltimo captulo se extraern las conclusiones del proyecto, se describirn las
limitaciones detectadas del prototipo y se plantean las posibles lneas de trabajo futuras para el
mismo.
Seguidamente se incluye una seccin de anexos. Unos para ampliar la informacin contenida
en la memoria y otros con los documentos que no tenan un lugar definido en la misma. Entre ellos se
encuentra el presupuesto del proyecto, el manual de instalacin de la aplicacin, y los ficheros de
configuracin y descripcin del dispositivo.

2. Marco terico

2. Marco terico
A lo largo de este captulo se presentarn las bases tericas sobre las que se asienta este
proyecto. Tras dar una visin global de las tecnologas utilizadas en su desarrollo (UPnP, JMF y
OSGi), se realizar un estudio ms detallado de aquellos aspectos que resulten ms importantes para
la implementacin de un prototipo de dispositivo UPnP MediaRenderer y se analizar su presencia en
el mercado.

2.1 Universal Plug and Play (UPnP)

En los prximos subapartados se estudiar la tecnologa UPnP. Se expondrn las bases
conceptuales de sta para posteriormente describir la arquitectura que define, as como los
protocolos sobre los que est basada y las distintas fases de una comunicacin UPnP.
Posteriormente se presentar la arquitectura que define esta tecnologa para dispositivos
audiovisuales, y se enumerarn las limitaciones que presenta. Finalmente se justificar su uso en
este proyecto.

2.1.1 Introduccin
UPnP, de las siglas en ingls Universal Plug and Play, es un protocolo de transmisin de
datos punto a punto para la comunicacin entre aplicaciones. Define una arquitectura software,
abierta y distribuida, que proporciona una forma de conectividad entre distintos equipos
pertenecientes a una red, permitiendo el intercambio de informacin y datos entre los mismos
[UPNPCASADOMO].
Surge a partir del modelo Plug and Play para la conexin de perifricos al PC (Personal
Computer), cuya mxima, enchufar y listo para usar, es extendida a dispositivos inteligentes,
dispositivos mviles, PCs, electrnica de consumo, y aplicaciones software.
Usando el modelo UPnP, un dispositivo puede agregarse dinmicamente a una red,
obtener una direccin IP, anunciar sus servicios, y saber de la existencia de otros dispositivos, todo
esto de forma automtica y transparente para el usuario final.
Varios son los escenarios en los que se puede implementar. Ejemplos de estos son la
automatizacin del hogar, impresoras en red, electrodomsticos para la cocina, o el entretenimiento
digital, como es el caso de este proyecto.
Segn el Foro UPnP [UPNPFORUM] esta tecnologa aporta beneficios tales como:

Independencia de medios (tipos de redes) y dispositivos: Puede funcionar sobre

cualquier medio que soporte el protocolo IP, incluyendo lneas telefnicas o
elctricas, Ethernet, FireWare, Infrarrojos(IR), radio (RF): Wi-Fi, Bluetooh, etc. Esto
hace que su uso sea apropiado para la Domtica.

Independencia de la plataforma y del lenguaje de programacin: Se puede usar

sobre cualquier sistema operativo y utilizando cualquier lenguaje de programacin
para crear productos UPnP. De hecho, UPnP no especifica ninguna API (Aplication
Programming Interface) para aplicaciones, dando libertad a los desarrolladores y
fabricantes de utilizar sistemas operativos y capacidades acordes a las necesidades
de sus clientes.

Tecnologas basadas en Internet: Est desarrollada sobre protocolos comunes de

Internet tales como IP (Internet Protocol), TCP (Transmission Control Protocol), UDP
(User Datagram Protocol), HTTP (Hypertext Protocol) y XML (Extensible Markup
Language)

Interfaz de usuario de control del dispositivo: La arquitectura UPnP permite

presentar una interfaz de usuario en un explorador web a travs de la cual un usuario

2. Marco terico

final podra, dependiendo de las capacidades del dispositivo, controlar a ste en

remoto.

Control por programa de la aplicacin: Un programa puede controlar directamente

un dispositivo UPnP sin necesidad de que ste posea un interfaz de usuario. Este
control puede basarse en la informacin descubierta sobre el dispositivo o a travs de
un conocimiento a priori del tipo de dispositivo.

Protocolos base comunes: Esta tecnologa se fundamenta en protocolos y

procedimientos comunes, con los que los desarrolladores de aplicaciones y
dispositivos estn de acuerdo, asegurando la interoperatividad entre los mltiples
dispositivos existentes en el mercado.

Extensibilidad: Los fabricantes o desarrolladores pueden introducir servicios de

valor aadido a sus productos UPnP, sobre una arquitectura bsica comn.

El Foro UPnP es una asociacin de compaas y personas relacionadas con la industria del
sector tecnolgico, formada en Octubre de 1999, cuyo propsito es promover el desarrollo de
dispositivos de fcil conexin y simplificar su implementacin en redes del hogar y entornos
empresariales. Esto lo logra definiendo y publicando descripciones de Dispositivos y Servicios UPnP,
originalmente denominadas DCPs (Device Control Protocols), de acuerdo a una arquitectura comn
de dispositivo impulsada por Microsoft. [UPNPFORUM]

2.1.2 Componentes de una red UPnP

La arquitectura UPnP define dos nodos principales de comunicacin: los Puntos de Control y
los Dispositivos.
Dispositivos (Device) y Servicios
Un dispositivo UPnP puede ser tanto un dispositivo real (hardware), como una
aplicacin software. Se trata de un contenedor de servicios y/o otros dispositivos. Estos
servicios y dispositivos embebidos tienen como objetivo definir la funcionalidad del dispositivo
que los contiene.
Poniendo como ejemplo de dispositivo contenedor un televisor LCD con reproductor
DVD integrado. Los servicios que contiene podran ser: un servicio de control de la
visualizacin, un servicio de sintonizacin, y un servicio de reloj. A su vez tiene un dispositivo
embebido, el reproductor DVD, con sus propios servicios asociados, como por ejemplo: un
servicio de control de la reproduccin, un servicio de afinamiento, etc. El conjunto de los
servicios y dispositivos integrados define las caractersticas funcionales del televisor combo.
Toda esta informacin se recoge en un documento XML de descripcin, DCPD
(Device Control Protocol Document), que el propio dispositivo debe alojar.
Los servicios conforman la unidad ms pequea de control en una red UPnP.
Proporciona un conjunto de acciones y modela su estado con variables de estado. Siguiendo
con el ejemplo del televisor LCD, una variable de estado del servicio de reloj podra ser la
hora actual, y una accin sera obtener dicha hora.
De forma anloga a la descripcin del dispositivo, esta informacin queda reflejada en
un documento XML de descripcin del servicio denominado SCPD (Service Control Protocol
Definition).
Adems, los cambios de estas variables de estado podran generar eventos
que las entidades subscritas para escucharlos, comnmente los Puntos de Controls, pueden
utilizar para mantener actualizada la informacin de estado del dispositivo controlado.

2. Marco terico

Puntos de Control (Control Point)

Los puntos de control UPnP son controladores de dispositivos UPnP, capaces de
descubrir y comunicarse con ellos. Despus de escuchar los mensajes de descubrimiento de
los dispositivos, pueden obtener la descripcin de los mismos con la lista de servicios
asociados y sus correspondientes descriptores, invocar acciones para controlar su
comportamiento, e incluso subscribirse a la fuente de eventos de estos para poder enterarse
de los cambios en sus variables de estado.
En la siguiente figura se muestra la relacin entre los servicios de los dispositivos y
los puntos de control:

Figura 2.1. Esquema Puntos de Control, Dispositivos y Servicios [AUNADOC]

Puentes (Bridge)
Los puentes UPnP, son entidades de enlace entre la red UPnP y dispositivos que no
pueden pertenecer a sta por carecer de recursos o por no soportar protocolos como TCP/IP,
HTTP o XML. Un ejemplo de escenario con un UPnP Bridge sera el definido en la siguiente
figura.

2. Marco terico

Figura 2.2. Ejemplo componentes UPnP [UPNPPROT]

2.1.3 Protocolos usados por UPnP

Como se coment anteriormente, uno de los principales beneficios de UPnP es que utiliza
protocolos estndares basados en Internet, comnmente utilizados tanto en la propia red Internet
como en redes de rea local. Esto, a parte de asegurar el conocimiento de los mismos por la mayor
parte de desarrolladores de dispositivos, permite establecer la independencia de la arquitectura
respecto del medio donde se implemente.
A continuacin se detallan los protocolos en los que se fundamenta la tecnologa UPnP
[UPnPPROT]:
TCP/IP
Familia de protocolos de Internet sobre el que se asientan el resto de protocolos
utilizados por UPnP y que permiten la conectividad a nivel de red entre los dispositivos. Con
su uso se asegura la anteriormente mencionada interoperabilidad en diferentes medios fsicos
e independencia de las plataformas.
Dentro de la pila de protocolos TCP/IP, se hace uso de los ms comunes. Ejemplo
de estos son: IP (Internet Protocol) como protocolo de red, TCP (Transmission Control
Protocol) como protocolo fiable de transporte, o UDP (User Datagram Protocol) como
protocolo no fiable de transporte.
HTTP, HTTPU, HTTPMU
HTTP supone la autntica base sobre la cual se desarrolla toda la tecnologa UPnP.
No en vano, permite la comunicacin al nivel de aplicacin entre los dispositivos que
conforman la red. HTTPU y HTTPMU son variantes de HTTP utilizados para entregar
mensajes a travs de UDP/IP. En el primer caso de un dispositivo a otro (unicast), y en el
segundo, de un dispositivo al resto que estn disponibles en la red UPnP (multicast).
SSDP (Simple Service Discovery Protocol)
Como su propio nombre indica, define cmo unos servicios de red pueden ser
descubiertos por otras entidades pertenecientes a la misma red utilizando direccionamiento

2. Marco terico

multicast. Define cmo puede un Punto de Control localizar recursos, dispositivos, de inters
en la red, y como puede un dispositivo anunciar su presencia en la misma. UPnP lo utiliza
para la fase de Descubrimiento de dispositivos.
Toma como protocolos base HTTPMU y HTTPU. El primero es utilizado para el envo
de mensajes de bsqueda de dispositivos (utilizado por el Punto de Control) o anuncios de
descubrimiento (utilizado por los dispositivos). El segundo se usa para el envo de los
correpondentes mensajes de respuesta de los dispositivos a los mensajes de bsqueda.
GENA (General Event Notification Architecture)
Provee una arquitectura para el envo y recepcin de mensajes de notificacin
utilizando HTTP sobre TCP/IP y multidifusin sobre UDP (HTTPMU). A su vez, define los
conceptos de subscriptores y editores de notificaciones.
En UPnP, los formatos GENA son usado para los anuncios de presencia enviados a
travs de SSDP comentados anteriormente, as como para proveer la capacidad de informar
de los cambios en los estados de los servicios a travs de eventos. Por tanto, UPnP la utiliza
para la fase de Envo y recepcin de eventos, y en la fase de Descubrimiento.
SOAP (Simple Object Access Protocol)
Define el uso de XML y HTTP para ejecutar llamadas de procedimiento remoto en
entornos descentralizados y distribuidos. Se ha convertido en el estndar para la
comunicacin basada en la tecnologa RPC (Remote Procedure Call) en Internet. Puede
hacer uso de protocolos de seguridad como SSL (Secure Socket Layer) para comunicaciones
ms seguras.
UPnP utiliza este protocolo en la fase de Control de los dispositivos.
XML (Extensible Markup Language)
Es el formato universal para datos estructurados en la Web. Dicho de otra forma, es
una forma de colocar cualquier tipo de datos estructurados, como los presentados en pginas
Web, en un fichero de texto. El uso de XML como un lenguaje esquema, est definido por
W3C.
UPnP lo utiliza para las descripciones de los dispositivos y servicios, y para los
mensajes de control y eventos.

2.1.4 Fases de la comunicacin UPnP

Como se ha comentado anteriormente, la tecnologa UPnP proporciona la capacidad de
comunicacin entre Puntos de Control y Dispositivos. Para ello, y como consecuencia del uso de
protocolos basados en Internet, define un conjunto de servidores HTTP para poder manejar las
distintas fases de la comunicacin.
Son seis las fases o mecanismos posibles que pueden darse durante la comunicacin,
Direccionamiento, Descubrimiento, Descripcin, Control, Eventos y Presentacin. [UPNPDEVARCH]

3 Control

4 Eventing

5 Presentation

2 Description
1 Discovery
0 Addressing

Figura 2.3. Esquema de las fases de la comunicacin UPnP [UPNPEINDHOVEN]

2. Marco terico

Direccionamiento
Ms que una fase de la comunicacin UPnP, el Direccionamiento, se considera el paso previo
al desarrollo de la misma. Se trata de que los dispositivos que integren la red UPnP obtengan una
direccin IP con la que se identifiquen y puedan comunicarse con el resto de miembros. Para ello, el
dispositivo debe disponer de un cliente Dynamic Host Configuration Protocol (DHCP) y buscar un
servidor DHCP disponible en la red que le asigne una IP. De no encontrar ningn servidor, debe
utilizar la funcin de Auto-IP, por la que obtiene una IP por l mismo.
Descubrimiento
Una vez que el dispositivo tiene asignada una IP nica para conectarse a la red, est en
condiciones de pasar a la primera de las fases de la comunicacin UPnP, el Descubrimiento.
Para esta fase se hace uso del mencionado protocolo SSDP. Mediante este portocolo el
dispositivo se agrega a la red. Este proceso le permite anunciar sus servicios a los Puntos de Control
u otros dispositivos. A su vez, a un Punto de Control, le permite la bsqueda de dispositivos en la red.
En los mensajes enviados por el dispositivo, tanto de descubrimiento como los de respuesta,
contienen informacin sobre algunos aspectos esenciales e importantes de los dispositivos y servicios
que anuncia. Cabe destacar, la localizacin, en formato Uniform Resource Locator (URL), del
documento de descripcin del dispositivo o descriptor.

Figura 2.4. Esquema de la fase de Descubrimiento UPnP [UPNPDEVARCH]

2. Marco terico

Descripcin
Despus de que el Punto de Control ya haya descubierto al dispositivo, para que pueda
conocer las capacidades de este, sus servicios y sus dispositivos embebidos, as como poder
interactuar con l, debe obtener su descripcin. Para ello debe recuperar el documento con esta
descripcin, el DCPD, a partir de la URL que, como se coment en el apartado anterior, se especifica
en el mensaje de descubrimiento.

Figura 2.5. Esquema de la fase de Descripcin de UPnP [UPNPDEVARCH]

La descripcin completa del dispositivo est dividida en dos partes lgicas, la descripcin del
dispositivo y las descripciones de los correspondientes servicios asociados a ste.
Documento de descripcin del dispositivo (DCPD)
Contiene informacin acerca del fabricante del dispositivo, informacin de fabricacin, como
nombre y tipo de dispositivo, numero de serie, urls del fabricante, etc. En el mismo
documento se listan los distintos tipos de servicios que implementa el dispositivo. Para cada
uno se incluye datos tales como, el nombre, una URL para su descripcin, una URL para el
mecanismo de Control, y una URL para el mecanismo de Eventos. Adems, incluye una
descripcin de todos los dispositivos embebidos que contiene el dispositivo raz, y una URL
de presentacin del dispositivo (en el apartado de Presentacin se describir su utilidad).

10

2. Marco terico

En el siguiente cuadro de texto se muestra el documente XML tipo para la descripcin

de un dispositivo:
<?xml version="1.0" encoding="utf-8"?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<URLBase>URL base para todas las urls relativas</URLBase>
<device>
<deviceType>urn:schemas-upnp-org:device:TipoDeDispositivo:version</deviceType>
<friendlyName>nombre corto</friendlyName>
<manufacturer>nombre del fabricante</manufacturer>
<manufacturerURL>url del fabricante</manufacturerURL>
<modelDescription>nombre largo y descriptivo del dispositivo</modelDescription>
<modelName>nombre del modelo</modelName>
<modelNumber>numero del modelo</modelNumber>
<modelURL>url al sitio del modelo</modelURL>
<serialNumber>numero de serie del fabricante</serialNumber>
<UDN>identificador unico y universal del dispositivo</UDN>
<UPC>codigo universal del producto</UPC>
<iconList>
<icon>
<mimetype>formato imagen</mimetype>
<width>pixeles horizontales</width>
<height>pixeles verticales</height>
<depth>profundidad del color</depth>
<url>URL de localizacion del icono</url>
</icon>
...
</iconlist>
<serviceList>
<service>
<serviceType>urn:schemas-upnp-org:service:TipoServicio:version</serviceType>
<serviceId>urn:upnp-org:serviceId:IDServicio</serviceId>
<SCPDURL>URL para la descripcion del servicio</SCPDURL>
<controlURL>URL para control</controlURL>
<eventSubURL>URL para eventos</eventSubURL>
</service>
... otros servicios definidos por el Foro UPnP
... otros servicios de valor aadido creados por el fabricante
</serviceList>
<deviceList>
... otros dispositivos embebidos definidos por el Foro UPnP
... otros dispositivos embebidos aadidos por el fabricante
</deviceList>
</device>
</root>

Cuadro de texto 2.1. XML de descripcin de un dispositivo

Documento descriptor del servicio (SCPD)
En este documento se listan las variables de estado que definen el estado del
servicio, as como el conjunto de acciones, con sus respectivos argumentos de entrada o
salida, que estn disponibles para ser invocados por el controlador, el Puntos de Control.

11

2. Marco terico

A continuacin se muestra el documento XML tipo para la descripcin de un servicio:

<?xml version="1.0" encoding="utf-8"?>
<scpd xmlns="urn:schemas-upnp-org:service-1-0>
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<serviceStateTable>
<stateVariable sendEvents="yes"> (yes: si se enva evento cuando cambia)
<name>nombre variable</name>
<dataType>tipo de datos</dataType>
<allowedValueList>
<allowedValue>valor enumerado</allowedValue>
... otros valores definidos por el Foro UPnP
</allowedValueList>
</stateVariable>
<stateVariable sendEvents="no">
<name>nombre variable</name>
<dataType>tipo de datos</dataType>
<defaultValue>valor por defecto</defaultValue>
<allowedValueRange>
<minimum>valor minimo permitido</minimum>
<maximum>valor maximo permitido</maximum>
<step>incremento</step>
</allowedValueRange>
</stateVariable>
... otras variables de estado definidas por el Foro UPnP
... otras variables de estado definidas por el fabricante
</serviceStateTable>
<actionList>
<action>
<name>nombre accion</name>
<argumentList>
<argument>
<name>nombre parametro</name>
<direction>direccion: entrada (in) o salida (out)</direction>
<relatedStateVariable>variable de estado relacionada</relatedStateVariable>
</argument>
... otros argumentos definidos por el Foro UPnP
</action>
... otras acciones definidas por el Foro UPnP
... otras acciones definidas por el fabricante
</actionList>
</scpd>

Cuadro de texto 2.2. XML de descripcin de un servicio

Como se mencion anteriormente y a la vista de las figuras, se tratan de documentos XML,
escritos por el fabricante del dispositivo, con una estructura estndar definida por el Foro UPnP.
Estos descriptores, tanto de dispositivos como de los servicios, son recuperados por el Punto
de Control mediante solicitudes HTTP GET.
Tras esta fase, el Punto de Control ya dispone de la informacin necesaria para poder
proceder con cualquiera de los subsiguientes pasos, Control, Eventos, o Presentacin. Este es el

12

2. Marco terico

motivo por el que en la figura 2.4, estas etapas aparezcan al mismo nivel y justo por encima de la
fase de Descripcin.
Control
Una vez obtenido el conocimiento suficiente sobre el dispositivo y sus servicios, un Punto de
Control puede invocar acciones de entre las que se definen en los servicios. Para ello, enva
mensajes de control a la URL de control del servicio correspondiente (proporcionada en la descripcin
del dispositivo). En respuesta, este servicio genera un mensaje en el que se incluye la respuesta a la
invocacin de la accin, si procede, o cdigos de error.
Los mensajes de control tambin se codifican en XML utilizando el formato que define el
protocolo SOAP descrito en el punto Protocolos usados por UPnP.

Figura 2.6. Esquema del mecanismo de Control de UPnP [UPNPDEVARCH]

Eventos
Al igual que en el mecanismo anterior, tras disponer el Punto de Control de la informacin que
le facilita las descripciones del dispositivo y sus servicio, ya est en condiciones para proceder con el
mecanismo de eventos.
En la etapa de Descripcin se dijo que la descripcin de un servicio incluye una lista de
variables de estado. Algunas de estas variables sufren modificaciones por cambios durante el
desarrollo del programa del propio servicio, o bien como consecuencia de la invocacin de alguna de
las acciones de control definidas para ste.
Si una o ms de estas variables generan eventos cuando son modificadas, entonces, el
dispositivo debe publicar dichas actualizaciones. Para que un Punto de Control pueda escuchar estos
eventos debe haberse subscrito previamente utilizando la URL que se le facilita a tal efecto en la
descripcin del servicio. De esta forma, el Punto de Control, estara enterado de cualquier
modificacin permitindole generar un modelo del estado de este servicio en tiempo de ejecucin.

13

2. Marco terico

Los mensajes de eventos, enviados por los servicios a sus subscriptores, contienen de una a
ms variables de estado y su valor actual. Tambin estos mensajes se expresan en XML, y se
formatean utilizando la arquitectura GENA.

Figura 2.7. Esquema del mecanismo de Eventos de UPnP [UPNPDEVARCH]

Presentacin
Alcanzado el mismo nivel de conocimiento de las capacidades del dispositivo que en los dos
mecanismos anteriores, el Punto de Control puede recuperar una pgina en formato HyperText
Markup Language (HTML) a partir de la URL de presentacin que se incluye en la descripcin del
servicio correspondiente. Esta pgina es obtenida mediante una solicitud HTTP GET. Se carga en un
explorador web y, en funcin de las capacidades de la misma, permite al usuario controlar al
dispositivo y/o visualizar informacin acerca de su estado actual.

14

2. Marco terico

Figura 2.8. Esquema del mecanismo de Presentacin de UPnP [UPNPDEVARCH]

2.1.5 Arquitectura UPnP para Audio y Video

Una vez se han descrito las principales caractersticas de UPnP, los protocolos sobre los que
se construye y las distintas fases de la comunicacin, se dispone del conocimiento necesario para
poder presentar la especificacin de esta tecnologa para escenarios de entretenimiento digital, la
arquitectura UPnP de Audio y Video.
La Arquitectura AV UPnP, en ingls UPnP AV Architecture, define la interaccin entre puntos
de control UPnP y dispositivos UPnP que manejan contenidos audiovisuales. [UPNPAV]
Las principales caractersticas de esta arquitectura son:

La independencia del tipo de dispositivo que se use, del formato de contenido

y del protocolo de transferencia.
Habilita la transmisin del contenido de audio y video directamente entre
dispositivos sin intervencin del Punto de Control.
La escalabilidad, lo que permite dar soporte tanto a dispositivos con recursos
limitados de procesamiento y memoria, como a dispositivos multimedia
avanzados.

La principal ventaja de esta arquitectura, como se representa en la Figura 2.9, es la de crear

un escenario en el que el contenido multimedia (audio, video e imgenes) que pueda estar
almacenado en cualquier dispositivo en red, se comparta y est disponible en toda la red domstica
para que cualquier dispositivo con capacidad de manejarlo lo haga sin tener que saber la procedencia
del mismo.

15

2. Marco terico

Escenario No-UPnP

Escenario UPnP

Figura 2.9. Escenarios AV en la red domstica [UPNPMUSE]

Como se ha visto anteriormente, un punto de control controla las operaciones de uno o ms
dispositivos. Sin embargo, los dispositivos no interaccionan entre s, de tal forma que toda la
coordinacin entre ellos es realizada por el Punto de Control. En la arquitectura para Audio y Video de
UPnP esto cambia.
Un Punto de Control AV (en adelante Control Point) debe interaccionar con dos o ms
dispositivos que actan como fuente y sumidero respectivamente. Aunque coordine y sincronice el
comportamiento de ambos, los dispositivos interaccionan entre s para transferir el contenido
multimedia desde el primero al segundo mediante un protocolo de transferencia fuera de banda. En
esta comunicacin entre dispositivos el Control Point se mantiene al margen.
Por tanto, en la Arquitectura AV de UPnP se ven involucradas tres tipos de entidades:
-

El Control Point (Punto de Control).

El dispositivo que sirve el contenido multimedia, denominado MediaServer.
El dispositivo que consume el contenido multimedia, denominado
MediaRenderer.

Figura 2.10. Arquitectura AV UPnP [UPNPAV]

16

2. Marco terico

AV Control Point
Como se deduce de todo lo dicho anteriormente, un AV Control Point coordina las
operaciones entra las otras dos entidades, normalmente en respuesta a la interaccin del usuario con
la interfaz grfica de ste. La Figura 2.10 muestra esta relacin entre las tres entidades.
UPnP MediaServer
Un MediaServer es cualquier dispositivo UPnP capaz de localizar el contenido multimedia que
est disponible para ser compartido en la red domstica. Su principal propsito es el de permitir que
el Control Point pueda listar este contenido para que el usuario pueda seleccionar el que desea
renderizar.
Como se puede ver en la Figura 2.10, contiene tres servicios principales:
Content Directory Service:
Permite al Control Point enumerar el contenido multimedia que puede ser ofrecido a
la red, y obtener detallada informacin (meta-datos) de cada tem de este contenido, como
por ejemplo el nombre, artista duracin, etc. Adicionalmente, esta informacin puede
identificar el protocolo de transferencia y el formato de datos que son soportados por el
MediaServer para un tem en concreto. El Control Point la utiliza para determinar si un
determinado MediaRenderer es capaz de reproducir ese tem.
Connection Manager Service:
Permite al Control Point manejar las conexiones asociadas al dispositivo. La principal
accin que define es PrepareForConnection(). Tiene carcter opcional y es invocada
por el Control Point para dar la oportunidad al dispositivo de prepararse para la transferencia
del contenido. Cuando es implementada, esta accin habilita al MediaServer a soportar la
transferencia de varios contenidos al mismo tiempo. Para ello genera un identificador de
cada conexin, ConnectioID, que puede ser usado por otro Control Point para averiguar qu
conexiones tiene activas el MediaServer.
As tambin, dependiendo del protocolo de transferencia y el formato del contenido,
su invocacin puede devolver un InstanceID de un AVTransport Service que el Control Point
puede utilizar para controlar el flujo de este contenido (controles comunes como Play,
Pause,). Ya que un mismo MediaServer podra soportar la transferencia de varios
contenidos, este identificador pude ser usado para distinguir varias instancias virtuales del
servicio AVTransport, cada una de las cuales est asociada con la conexin a un
MediaRenderer distinto.
Si el Control Point quiere cerrar una conexin entre MediaServer y MediaRenderer
puede invocar a la accin ConnectionComplete() y as liberarla. Esta accin tambin es
opcional.
Si el servicio no implementa la accin PrepareForConnection() el MediaServer
nicamente soportar la conexin con un MediaRenderer.
AVTrasnport Service:
Permite al Control Point controlar la reproduccin del contenido que est asociado
con este servicio. Esto incluye los controles comunes como Play, Pause, Stop, etc. Acorde a
lo dicho anteriormente, dependiendo del protocolo de transferencia y formatos de contenido
que soporte el MediaServer, se necesitar o no implementar este servicio. En el caso de que
sea necesario, se podrn generar instancias (virtuales) del servicio usando el identificador
InstanceID y cuyo uso ya se ha comentado en la descripcin del anterior servicio.

17

2. Marco terico

Si el MediaServer no soporta ms de una conexin (no implementa la accin

PrepareForConnection() del ConnectionManager Service), los identificadores asociados
a la conexin quedan: ConnectionID = AVTransportID = RcsID = 0.
UPnP MediaRenderer
El MediaRenderer es el dispositivo UPnP capaz de reproducir y presentar el contenido
multimedia que esta disponible en la red domstica. Su principal caracterstica es que permite al
Control Point controlar su renderizacin (Volumen, Mute, Brillo,) y, ms especficamente, podra
controlar la reproduccin mediante acciones comunes como Play, Pause, Stop,..., siempre y cuando
el protocolo de transferencia lo permita.
Tambin en este caso, contiene tres servicios principales (ver Figura 2.10).
Rendering Control Service:
Permite al Control Point controlar cmo se renderiza el contenido. Esto incluye
aspectos como el brillo, contraste, volumen, mute, etc. Este servicio soporta mltiples y
dinmicas instancias para poder mezclar uno o ms tems, como podra ser un mezclador de
audio o una ventana Picture-in-Picture. Estas instancias, asociadas a un InstanceID, son
creadas en la invocacin de la accin PreparaForConnection() del Connection Manager
Service.
Connection Manager Service:
Al igual que en el caso del MediaServer, este servicio es usado para manejar las
conexiones del dispositivo con otro. En el caso del MediaRenderer, la accin principal es
GetProtocolInfo(), la cual permite al Control Point enumerar los protocolos de
transferencia y los formatos de datos que soporta el MediaRenderer, que usar para
averiguar si podr o no reproducir un determinado contenido.
Tambin se implementa la accin PrepareForConnection() con la misma utilidad
que en el caso del MediaServer, incluyendo la generacin de identificadores ConnectionID
para que otro Control Point pueda conocer las conexiones activas que tiene el dispositivo.
De igual modo, dependiendo del protocolo de transferencia y el formato del contenido,
esta accin puede devolver un InstanceID para poder identificar distintas instancias virtuales
del servicio AVTransport Service que permitan al Control Point controlar varios flujos y su
reproduccin.
Por ultimo, a diferencia del MediaServer, tambin la invocacin de esta accin puede
generar un InstanceID del servicio RenderingControl Service. Como se dijo en la descripcin
de este servicio, estos identificadores son usados por el Control Point para el control de la
renderizacin del contenido asociado a cada uno.
Para cerrar una conexin abierta entre el MediaServer y el MediaRenderer el Control
Point invoca, si est implementada, la accin ConnectionComplete().
Si el servicio no implementa la accin PrepareForConnection() el
MediaRenderer nicamente soportar la conexin con un MediaServer.
AVTransport Service:
Su funcionalidad es la misma que la que se define para el caso del MediaServer. Esta
es, la del control del flujo y la reproduccin. Esto incluye las acciones ms comunes, Play,
Pause, Tambin en el caso del MediaRenderer la necesidad de su implementacin est
condicionada al tipo de protocolo de transferencia que se use. En el caso de que se
implemente se podran generar varias instancias del servicio generando sus respectivos
identificadores, InstanceID, tal y como se indica en la descripcin del anterior servicio.

18

2. Marco terico

Se profundizar en las especificaciones de estos servicios asociados a un UPnP

MediaRenderer en el siguiente apartado.
Sobre la implementacin del AVTransport Service:
Como se ha dicho, la implementacin del AVTransport Service es opcional., tanto en el
MediaServer como en el MediaRenderer. Depende principalmente del protocolo de transferencia del
contenido que se use.
Existe una clasificacin bsica de los protocolos en funcin de cmo son entregados los
datos:
-

Pull: la transferencia de datos es iniciada y controlado desde el lado del cliente. HTTP,
para contenido en remoto, y FILE, para contenido en local, son ejemplos de protocolo
Pull.
Push: la transferencia es iniciada y controlado desde el lado del servidor. RTP es un
ejemplo de protocolo Push.

En este sentido, un protocolo del tipo Push implicara su implementacin en el lado del MediaServer.
Mientras que un protocolo del tipo Push implicara su implementacin en el lado del MediaRenderer.
Sobre los identificadores de los servicios:
Si un MediaServer o un MediaRenderer no soporta ms de una conexin (no implementa la
accin PrepareForConnection() del ConnectionManager Service), el identificador de la conexin
tomar el valor: ConnectionID = 0. Consecuentemente slo se crear una nica instancia de cada
servicio AVTranspor Service y RenderingControl Service, cuyos identificadores tomarn los siguiente
valores: AVTransportID = RcsID = 0.

2.1.6 UPnP MediaRenderer

Volviendo a la definicin del apartado anterior, un UPnP MediaRenderer, es el dispositivo de
la arquitectura AV UPnP que permite la renderizacin del contenido multimedia compartido en la red
de un hogar.
El Foro UPnP especifica los tres tipos de servicios asociados a un MediaRenderer
presentados con anterioridad. Estos servicios contienen un conjunto de acciones y variables de
estado que sern utilizados por un UPnP AV Control Point para controlar el proceso de renderizacin
y mantenerse informado sobre el estado de cada uno de ellos.
Puesto que este proyecto trata sobre la implementacin de un prototipo de UPnP
MediaRenderer, y dada su importancia, a continuacin se profundizar en los servicios asociados a
este tipo de dispositivos.
Teora de operaciones
El proceso para que un UPnP MediaRenderer pueda renderizar el contenido multimedia que
dispone los UPnP MediaServers comienza con la ya descrita fase de descubrimiento, en la que el
dispositivo es descubierto por el Control Point.
Tras recuperar el descriptor del dispositivo y el de sus servicios asociados, el Control Point
ya dispone de la informacin necesaria para subscribirse al mecanismo de eventos de los servicios e
invocar las acciones definidas en estos.
Mediante la invocacin de acciones del ConnectionManager Service del dispositivo, el Control
Point prepara la transferencia del contenido.
Tras esto, el usuario por medio del Control Point puede invocar las acciones que le permiten
iniciar la reproduccin y controlarla definidas en el AVTrasnsport Service.

19

2. Marco terico

De la misma forma, puede invocar acciones del RenderingControl Service para controlar
cmo se renderiza el contenido (volumen, brillo,).
El algoritmo que se describe a continuacin define de forma general los posibles procesos de
comunicacin entre las tres entidades que intervienen (Control Point, MediaServer y MediaRenderer).
1. Descubrimiento, usando el mecanismo UPnP de Descubrimiento, de los MediaServers y
MediaRenderers conectados a la red domstica.
2. Localizacin del contenido que se desea reproducir por medio del servicio
ContentDirectory Service del MediaServer, invocando la accin Browse() o Search().
Entre la informacin devuelta de la llamada a cualquiera de ellos figura los protocolos de
transferencia y los formatos de los datos que el MediaServer soporta.
3. Obtencin de los formatos y protocolos soportados por el MediaRenderer invocando el
mtodo GetProtocolInfo() el servicio ConnectioManager Service.
4. Comparacin de los formatos y protocolos entre MediaRenderer y MediaServer. El
Control Point selecciona un protocolo de transferencia y un formato de datos que sean
soportados por ambos.
5. Preparacin de los dispositivos para la comunicacin utilizando la llamada a la accin
PrepareForConnection(), si est implementada, de los respectivos servicios
ConnectionManager Service, obteniendo las instancias necesarias para el manejo de las
conexiones, tal y como se indica en las anteriores descripciones de este servicio.
6. Seleccin del tem deseado de entre los tems que se listan disponibles en el Control
Point. Se utiliza la llamada a la accin SetAVTrasnportURI() del servicio AVTransport
Service para identificar a este contenido.
7. Iniciacin de la transferencia. Se invoca la accin Play() del servicio AVTransport
Service que inicia el proceso de reproduccin. Se pueden invocar otras acciones del
servicio como Stop(), Pause(), Seek(), para el control sobre la reproduccin y el
flujo.
8. Ajuste de caractersticas de la renderizacin: volumen, mute, por medio de la llamada a
acciones del servicio RenderingControl Service, tales como, SetVolume(), SetMute(),
etc.
9. Seleccin el siguiente contenido de forma anloga al paso 6 o bien por medio del
mecanismo que se proporciona en la accin SetNextAVTransportURI().
10. Cierre de la conexin, cuando la sesin sea finalizada, mediante la invocacin, si est
implementada, de la accin ConnectionComplete() de los respectivos servicios
ConnectionManager Service del MediaServer y MediaRenderer.

20

2. Marco terico

En la siguiente figura se muestra un esquema de este algoritmo.

Figura 2.11. Diagrama general de interaccin [UPNPAV]

El significado de las siglas que se utilizan se corresponde con los servicios
anteriormente descritos:
CDS: ContentDirectory Service (del MediaServer)
CM: ConnectionManager Service (del MediaServer y MediaRenderer)
AVT: AVTransport Service (del MediaServer o el MediaRenderer)
RCS: RenderingControl Service (del MediaRenderer)
Servicios de un UPnP MediaRenderer
Un servicio UPnP se caracteriza por contener un conjunto de acciones y un conjunto de
variables de estado.
Las acciones son procesos que un Control Point puede invocar remotamente sobre el
MediaRenderer. Tiene asociados unos argumentos de entrada y/o unos argumentos de salida. Cada
uno de estos argumentos tiene asociada una variable de estado del servicio.

21

2. Marco terico

Las variables de estado permiten modelar en cada momento el estado en el que se

encuentra el servicio, y por extensin el dispositivo que lo contiene. El cambio de valor en algunas de
estas variables provoca la generacin de un evento que es enviado a los subscriptores, generalmente
un Control Point, para que puedan advertir el cambio en el modelo de estado del servicio. Esto
implica que un argumento que modifique el valor de una variable de estado que genera eventos
provoque el envo de un evento para informar del cambio.
Los tres servicios definidos para un UPnP MediaRenderer son, como ya se dijo,
RenderingControl Service, ConnectionManager Service y AVTransport Service.
Entre las variables de estado de estos servicios, existe un conjunto formado por aquellas cuyo
nombre comienza por A_ARG_TYPE_.... Este tipo de variables no provocan el envo de eventos, de
hecho no cambian. Esencialmente su funcin es la de proporcionar informacin del tipo de datos que
contiene el argumento asociado a ella.
Existe una variable de estado especial y definida para los servicios RenderingControl Service
y AVTransport Service. Se trata de la variable LastChange. Su propsito es el de recopilar
informacin sobre cambios que se han producido en variables de estado que no generan eventos
cuando cambian sus valores. Peridicamente la informacin sobre estos cambios es enviada al
Control Point mediante un nico evento asociado a esta variable.
El mecanismo de eventos definido para el envo de eventos por cambios producidos en las
variables de estado, ya sea directamente o indirectamente a travs de la variable LastChange,
permite al Control Point tener permanentemente el modelo del estado en el que se encuentra cada
servicio y por extensin del MediaRenderer.
RenderingControl Service
Este servicio proporciona al Control Point la capacidad de controlar algunos aspectos de la
renderizacin del contenido. Por tanto, le permite modificar caractersticas como el brillo, el contraste
de la imagen o el volumen del audio entre muchas otras.
Las acciones que define este servicio son:
Accin

Descripcin

ListPresets()

[Obligatoria] Devuelve una lista con los presets definidos

SelectPreset()
GetBrightness()
SetBrightness()
GetContrast()
SetContrast()
GetSharpness()
SetSharpness
GetRedVideoGain()
SetRedVideoGain()
GetGreenVideoGain()

[Obligatoria] Reestablece las variables de estado a los valores

definidos por el preset especificado
[Opcional] Devuelve el valor actual de la variable de estado
Brightness
[Opcional] Establece la variable de estado Brightness al valor
especificado
[Opcional] Devuelve el valor actual de la variable de estado
Contrast
[Opcional] Establece la variable de estado Contrast al valor
especificado
[Opcional] Devuelve el valor actual de la variable de estado
Sharpness
[Opcional] Establece la variable de estado Sharpness al valor
especificado
[Opcional] Devuelve el valor actual de la variable de estado
RedVideoGain
[Opcional] Estable la variable de estado RedVideoGain al valor
especificado
[Opcional] Devuelve el valor actual de la variable de estado
GreenVideoGain

Preset: en sistemas audiovisuales un preset es un conjunto de parmetros o variables del sistema que se
memorizan definiendo una configuracin del mismo.

22

2. Marco terico

SetGreenVideoGain()
GetBlueVideoGain()
SetBlueVideoGain()
GetRedVideoBlackLevel()
SetRedVideoBlackLevel
GetGreenVideoBlackLevel()
SetGreenVideoBlackLevel
GetBlueVideoBlackLevel()
SetBlueVideoBlackLevel
GetColorTemperature()
SetColorTemperature()
GetHorizontalKeystone()
SetHorizontalKeystone()
GetVerticalKeystone()
SetVerticalKeystone()
GetMute()
SetMute()
GetVolume()
SetVolume()
GetVolumeDB()
SetVolumeDB()
GetVolumeDBRange()
GetLoudness()
SetLoudness()
GetStateVariables()

SetStateVariables()

[Opcional] Estable la variable de estado GreenVideoGain al

valor especificado
[Opcional] Devuelve el valor actual de la variable de estado
BlueVideoGain
[Opcional] Estable la variable de estado BlueVideoGain al
valor especificado
[Opcional] Devuelve el valor de la variable de estado
RedVideoBlackLevel
[Opcional] Establece la variable de estado
RedVideoBlackLevel
[Opcional] Devuelve el valor de la variable de estado
GreenVideoBlackLevel
[Opcional] Establece la variable de estado
GreenVideoBlackLevel
[Opcional] Devuelve el valor de la variable de estado
BlueVideoBlackLevel
[Opcional] Establece la variable de estado
BlueVideoBlackLevel
[Opcional] Devuelve el valor actual de la variable de estado
ColorTemperature
[Opcional] Establece el valor de la variable de estado
ColorTemperature
[Opcional] Devuelve el valor actual de la variable de estado
HorizontalKeystone
[Opcional] Establece la variable de estado
HorizontalKeystone al valor especificado
[Opcional] Devuelve el valor actual de la variable de estado
VerticalKeystone
[Opcional] Establece la variable de estado VerticalKeystone
al valor especificado
[Opcional] Devuelve el valor actual de la variable de estado Mute
para un determinado canal
[Opcional] Establece la variable de estado Mute al valor
especificado para un canal especfico
[Opcional] Devuelve el valor actual de la variable de estado
Volume para un determinado canal
[Opcional] Establece la variable de estado Volume al valor
especificado para un canal especfico
[Opcional] Devuelve el valor actual de la variable de estado
VolumeDB para un determinado canal
[Opcional] Establece la variable de estado VolumeDB al valor
especificado para un canal concreto
[Opcional] Devuelve el rango vlido, determinado por sus valores
mximo y mnimo, para la variable de estado VolumeDB para un
canal concreto
[Opcional] Devuelve el valor actual de la variable de estado
Loudness para un canal determinado
[Opcional] Establece la variable de estado Loudness al valor
especificado para un canal concreto
[Opcional] Devuelve la coleccin actual de nombres de las
variables de estado de este servicio y sus respectivos valores
[Opcional] Extrae los valores del argumento de entrada
StateVariableValuePairs y la copia a las correspondientes
variables de estado asociadas. Los argumentos
RenderingControlUDN, ServiceType y ServiceID se usan
para comprobar la compatibilidad

Tabla 2.1. Acciones del servicio RenderinControl Service

23

2. Marco terico

A continuacin se muestra una tabla con las variables de estado del servicio
RenderingControl Service y una breve descripcin:
Variable de Estado

Ob/Op

Evento

LastChange

Ob

Si

PresetNameList

Ob

No

Brightness

Op

No

Contrast

Op

No

Sharpness

Op

No

RedVideoGain

Op

No

GreenVideoGain

Op

No

BlueVideoGain

Op

No

RedVideoBlackLevel

Op

No

GreenVideoBlackLevel

Op

No

BlueVideoBlackLevel

Op

No

ColorTemperature

Op

No

HorizontalKeystone

Op

No

VerticalKeystone

Op

No

Mute

Op

No

Volume

Op

No

VolumeDB

Op

No

Loudness

Op

No

A_ARG_TYPE_Channel

Ob

No

A_ARG_TYPE_InstanceID

Ob

No

A_ARG_TYPE_PresetName

Ob

No

A_ARG_TYPE_DeviceUDN

Op

No

A_ARG_TYPE_ServiceType

Op

No

A_ARG_TYPE_ServiceID

Op

No

Descripcin
Recopila informacin sobre cambios que
se han producido en variables de estado
que no generan eventos cuando cambian
sus valores
Contiene una lista de los nombres de
presets vlidos del dispositivo.
Representa el valor del brillo de la imagen
Representa el valor del contraste de la
imagen
Representa el valor del contraste de la
imagen
Representa el valor del control de
ganancia de rojos de la pantalla
Representa el valor del control de
ganancia de verdes de la pantalla
Representa el valor del control de
ganancia de azules de la pantalla
Representa el valor de la intensidad
mnima de salida del rojo de la pantalla
Representa el valor de la intensidad
mnima de salida del verde de la pantalla
Representa el valor de la intensidad
mnima de salida del azul de la pantalla
Representa el valor de la caracterstica de
la pantalla: calidad de color del blanco
Representa el valor del nivel de
compensacin de la distorsin horizontal
de la pantalla
Representa el valor del nivel de
compensacin de la distorsin vertical de
la pantalla
Representa el valor de mute del asociado
a un canal de audio
Representa el valor de volumen del
asociado a un canal de audio
Representa el valor de volumen en la
escala de decibelios del asociado a un
canal de audio
Representa el valor que indica si el
Loudness del sistema de sonido est
activado
Provee informacin de tipo para el
argumento Channel en varias acciones
Provee informacin de tipo para el
argumento InstanceID en varias
acciones
Provee informacin de tipo para el
argumento PresetName en la accin
SelectPreset()
Provee informacin de tipo para el
argumento RenderingControlUDN en
ciertas acciones
Provee informacin de tipo para el
argumento ServiceType
Provee informacin de tipo para el
argumento ServiceID en ciertas
acciones

24

2. Marco terico

A_ARG_TYPE_
StateVariableValuePairs

Op

No

A_ARG_TYPE_
StateVariableList

Op

No

Provee informacin de tipo para el

argumento
StateVariableValuePairs en ciertas
acciones
Provee informacin de tipo para el
argumento StateVariableList en
ciertas acciones

Tabla 2.2. Variables de estado del servicio RenderinControl Service

Ob/Op: implementacin: Obligatoria / Opcional
Evento: si un cambio en su valor provoca el envo de un evento: Si / No
ConnectionManager Service
Este servicio permite al dispositivo prepararse para la conexin entrante y al Control Point
manejar las conexiones asociadas a este.
Las acciones que define este servicio son:
GetProtocolInfo()
PrepareForConnectio()
ConnectionComplete()
GetCurrentConnectionIDs()
GetCurrentConnectionInfo()

[Obligatoria] Devuelve una lista de los protocolos que el servicio

ConnectionManager Service soporta en su estado actual
[Opcional] Permite al dispositivo prepararse para la recepcin
de los datos multimedia, y tambin, si puede o no realizar la
conexin en base al estado actual y el estado de la red
[Opcional] Es usada para informar al dispositivo que una
conexin, previamente abierta, ya no es necesaria
[Obligatoria] Devuelve una lista de identificadores,
ConnectionID, de las conexiones actualmente activas
[Obligatoria] Devuelve informacin relativa a la conexin a la
que hace referencia el argumento ConnectionID

Tabla 2.3. Acciones del servicio ConnectionManager Service

A continuacin se muestra una tabla con las variables de estado del servicio
ConnectionManager Service y una breve descripcin:
Variable de Estado

Ob/Op

Evento

SourceProtocolInfo

Ob

Si

SinkProtocolInfo

Ob

Si

CurrentConnectionIDs

Ob

Si

A_ARG_TYPE_
ConnectionStatus

Ob

No

A_ARG_TYPE_
ConnectionManager

Ob

No

A_ARG_TYPE_Direction

Ob

No

A_ARG_TYPE_ProtocolInfo

Ob

No

Descripcin
Contiene la lista de protocolos que este
servicio soporte para la transmisin del
contenido multimedia
Contiene la lista de protocolos que este
servicio soporte para la recepcin del
contenido multimedia
Contiene una lista de los identificadores
de las conexiones activas
Provee informacin de tipo para el
argumento Status en la accin
GetCurrentConnectionInfo()
Provee informacin de tipo para el
argumento PeerConnectionManager
en las acciones
GetCurrentConnectionInfo() y
PrepareForConnection()
Provee informacin de tipo para el
argumento Direction en la accin
PrepareForConnection()
Provee informacin de tipo para los
argumentos RemoteProtocolInfo en
la accin
GetCurrentConnectionInfo() y
ProtocolInfo en la accin

25

2. Marco terico

GetCurrentConnectionInfo()

A_ARG_TYPE_ConnectionID

Ob

No

A_ARG_TYPE_
AVTrasnportID

Ob

No

A_ARG_TYPE_RcsID

Ob

No

Provee informacin de tipo para el

argumento ConnectionID en las
acciones PrepareForConnection(),
ConnectionComplete() y
GetCurrentConnectionInfo()
Provee informacin de tipo para el
argumento AVTrasnport en las
acciones
GetCurrentConnectionInfo() y
PrepareForConnection()
Provee informacin de tipo para el
argumento Rcs en las acciones
GetCurrentConnectionInfo() y
PrepareForConnection()

Tabla 2.4. Variables de estado del servicio ConnectionManager Service

AVTransport Service
Este servicio permite al Control Point controlar el flujo
multimedia que se est renderizando.

y la reproduccin del contenido

Las acciones que define son las siguientes:

SetAVTansportURI()
SetNextAVTrasnportURI()
GetMediaInfo()
GetMediaInfo_Ext()
GetTransportInfo()

GetPositionInfo()

GetDeviceCapabilities()
GetTransportSettings()
Stop()
Play()
Pause()
Record()

Seek()

[Obligatoria] Especifica la URI del recurso que va a ser

controlado a travs de este servicio
[Opcional] Especifica la URI del recurso a ser controlado
cuando finalice la reproduccin en curso
[Obligatoria] Devuelve informacin asociada al recurso
multimedia que est siendo controlado
[Obligatoria] Devuelve la misma informacin que la anterior
accin pero aadiendo la categora de contenido multimedia
[Obligatoria] Devuelve informacin sobre el estado del
transporte y reproduccin del recurso
[Obligatoria] Devuelve informacin sobre el momento de la
reproduccin en que se encuentra el recurso como puede
ser informacin sobre la pista actual, su referencia temporal,
su duracin,
[Obligatoria] Devuelve informacin sobre las capacidades de
procesamiento del dispositivo
[Obligatoria] Devuelve informacin sobre algunos
caractersticas configurables como el modo de reproduccin
o la calidad de la grabacin
[Obligatoria] Para la reproduccin del recurso actual
[Obligatoria] Arranca la reproduccin del recurso actual a
una velocidad determinada y de acuerdo la forma que
indique el modo de reproduccin (CurrentPlayMode)
[Opcional] Pausa la reproduccin en curso, siempre que sta
est en el estado: Playing
[Opcional] Arranca el proceso de grabacin del recurso
actual de acuerdo al modo de calidad especificado
anteriomente
[Obligatoria] Permite la bsqueda dentro del archivo
multimedia de una posicin concreta especificada en el
argumento Target. El argumento Unit define cmo debe
ser interpretado el otro argumento.

Next()

[Obligatoria] Permite avanzar a la siguiente pista

Previous()

[Obligatoria] Permite retroceder a la pista anterior

SetPlayMode()

[Opcional] Establece el modo de reproduccin

26

2. Marco terico

SetRecordQualityMode()
GetCurrentTransportActions()
GetDRMState()
GetStateVariables()

SetStateVariables()

[Opcional] Establece el modo de calidad de la grabacin

[Opcional] Devuelve la variable de estado
CurrentTransportActions
[Opcional] Devuelve informacin sobre el estado actual del
DRM
[Opcional] Devuelve la coleccin actual de nombres de las
variables de estado de este servicio y sus respectivos
valores
[Opcional] Extrae los valores del argumento de entrada
StateVariableValuePairs y la copia a las
correspondientes variables de estado asociadas. Los
argumentos AVTransportUDN, ServiceType y
ServiceID se usan para comprobar la compatibilidad

Tabla 2.5. Acciones del servicio AVTransport Service

La siguiente tabla muestra las variables de estado del servicio AVTransport Service y una
breve descripcin de las mismas:
Variable de Estado

Ob/Op

Evento

TransportState

Ob

No

TransportStatus

Ob

No

CurrentMediaCategory

Ob

No

PlaybackStorageMedium

Ob

No

RecordStorageMedium

Ob

No

PossiblePlaybackStorageMedia

Ob

No

PossibleRecordStorageMedia

Ob

No

CurrentPlayMode

Ob

No

TransportPlaySpeed

Ob

No

RecordMediumWriteStatus

Ob

No

CurrentRecordQualityMode

Ob

No

PossibleRecordQualityModes

Ob

No

NumberOfTracks

Ob

No

Descripcin
Principal variable de estado del
servicio. Define los estados del
transporte (o la renderizacin).
Sirve para informar al Control Point
de posibles fallos durante el control
del recurso, como puede ser fallos
con la red
Indica si el recurso actual es track1
aware o track-unaware
Indica el tipo de medio donde est
almacenado el recurso especificado
Indica el tipo de medio donde
almacenar el recurso en el proceso
de grabacin
Contiene una lista de los posibles
medios de almacenamiento del
contenido multimedia soportados por
el dispositivo para su reproduccin
Contiene una lista de los posibles
medios donde almacenar el
contenido multimedia soportados por
el dispositivo para la grabacin
Indica el modo actual de
reproduccin (Por ejemplo,
aleatoria, repeticion, etc)
Indica la velocidad, relativa a la
normal, de reproduccin
Indica el tipo de proteccin sobre
escritura que tiene el medio donde ha
sido descargado el recurso
Indica el modo de calidad actual con
la que se graba el recurso
Contiene una lista de los posibles
modos de calidad con la que se
puede grabar un recurso
1
Contiene el nmero de pistas
controladas por este servicio

Track-aware/unaware: se clasifica como track-aware al recurso compuesto por varias pistas (5) definidas e
independientes (multiple) (ejemplo: CD), o una nica (single) (ejemplo un fichero de audio mp3). Se entiende por
recurso track-unaware aquel que no identifica pistas distintas por lo que en s mismo conforma una nica unidad
(ejemplo: VHS).

27

2. Marco terico

CurrentTrack

Ob

No

CurrentTrackDuration

Ob

No

CurrentMediaDuration

Ob

No

CurrentTrackMetaData

Ob

No

CurrentTrackURI

Ob

No

AVTransportURI

Ob

No

AVTransportURIMetaData

Ob

No

NextAVTransportURI

Ob

No

NextAVTransportURIMetaData

Ob

No

RelativeTimePosition

Ob

No

AbsoluteTimePosition

Ob

No

RelativeCounterPosition

Ob

No

AbsoluteCounterPosition

Ob

No

CurrentTransportActions

Op

No

LastChange

Ob

Si

DRMState

Op

No

Contiene el numero de secuencia

que identifica a la pista que est
seleccionada
Contiene la duracin de la pista
actual
Contiene la duracin del recurso
multimedia, la suma de duraciones
de cada una de sus pistas,
identificado por el AVTransportURI
2
Contiene los meta-datos asociados
a la pista a la que hace referencia la
variable de estado
CurrentTrackURI
Contiene una referencia, en formato
3
URI , de la pista actual
Contiene una referencia, en formato
URI, del recurso controlado por este
servicio
Contiene los meta-datos asociados al
recuso al que hace referencia la
variable de estado
AVTransportURI
Contiene el valor de la variable
AVTransportURI que para el
prximo recurso a controlar
Contiene los meta-datos asociados al
recuso al que hace referencia la
variable de NextAVTransportURI
Contiene la posicin actual dentro de
la pista, en trminos de tiempo,
medido desde el principio de sta
(para track-aware)
Contiene la posicin actual, en
terminos de tiempo, relativa al
recurso completo y medida desde el
principio de ste
Contiene la posicin actual dentro de
la pista, en trminos de un contador
sin dimensin, medido desde el
principio de sta (para track-aware)
Contiene la posicin actual, en
trminos de un contador sin
dimensin, relativa al recurso
completo y medida desde el principio
de ste
Contiene una lista de las acciones de
control del transporte y la
reproduccin que pueden se
invocadas para el recurso actual (Por
ejemplo, Play(), Pause(), etc)
Recopila informacin sobre cambios
que se han producido en variables de
estado que no generan eventos
cuando cambian sus valores
Usada por las implementaciones del

Pista: es cada uno de los tems o piezas diferentes de que se compone un recurso multimedia. Por ejemplo un
CD de msica es un recurso multimedia formado generalmente por 17 canciones aproximadamente, cada una de
las cuales conforman una pista (track-aware). Un recurso completo puede consistir en una nica pista, como por
ejemplo, un fichero almacenado en disco que contiene una nica cancin o que an conteniendo varias, stas
conforman una nica unidad (track-unaware).
2
Meta-datos: informacin asociada al contenido multimedia, como puede ser el ttulo, el autor, la duracin, el tipo
de contenido,, representada en formato XML.
3
URI (Uniform Resource Identifier): es una cadena corta de caracteres que identifica de forma unvoca un
recurso.

28

2. Marco terico

A_ARG_TYPE_SeekMode

Ob

No

A_ARG_TYPE_SeekTarget

Ob

No

A_ARG_TYPE_InstanceID

Ob

No

A_ARG_TYPE_DeviceUDN

Op

No

A_ARG_TYPE_ServiceType

Op

No

A_ARG_TYPE_ServiceID

Op

No

A_ARG_TYPE_
StateVariableValuePairs

Op

No

A_ARG_TYPE_ StateVariableList

Op

No

servicio que manejan contenidos con

1
control DRM
Provee informacin de tipo para el
argumento Unit en la accin
Seek()
Provee informacin de tipo para el
argumento Target en la accin
Seek()
Provee informacin de tipo para el
argumento InstanceID en varias
acciones
Provee informacin de tipo para el
argumento RenderingControlUDN
en ciertas acciones
Provee informacin de tipo para el
argumento ServiceType
Provee informacin de tipo para el
argumento ServiceID en ciertas
acciones
Provee informacin de tipo para el
argumento
StateVariableValuePairs en
ciertas acciones
Provee informacin de tipo para el
argumento StateVariableList en
ciertas acciones

Tabla 2.6. Variables de estado del servicio AVTransport Service

Estados del Transporte (renderizacin)
De entre estas variables hay que destacar por su importancia en la implementacin de un
MediaRenderer, la variable TransportState. Como se ha dicho, define los estados en los que se
encuentra el transporte del contenido, o interpretado de otra manera, los estados de la renderizacin.
Estos son:
-

NO_MEDIA_PRESENT Sin contenido asociado.

STOPPED Parado.
TRANSITIONING En proceso de transicin.
PLAYING Renderizando el medio.
PAUSED_PLAYBACK Renderizacin pausada.
RECORDING Grabando el medio.
PAUSED_RECORDING Grabacin pausada.

La principal consideracin a tener en cuenta es que si surge un error en cualquier estado de

la renderizacin, se debe volver al estado STOPPED.

2.1.7 Limitaciones de UPnP

Como toda tecnologa, UPnP asume ciertas limitaciones. A continuacin se detallan las ms
destacadas:

Seguridad: UPnP no dispone por defecto de un mecanismo de autenticacin. Sin

embargo, s dispone de DCPs, descripciones de servicios, que incorporan
polticas de seguridad a la arquitectura UPnP. El servicio de seguridad para
dispositivos de UPnP (UPnP DeviceSecurity Service) proporciona los servicios

DRM (Digital Rights Management): mecanismo de proteccin del contenido para la gestin de derechos
digitales.

29

2. Marco terico

necesarios para la autenticacin, autorizacin, prevencin de repeticiones y

privacidad para las acciones SOAP de UPnP. [UPNPSECURITY]

QoS: tampoco UPnP por defecto incorpora polticas que aseguren un buen
servicio acorde al tipo de datos, cantidad y tiempo necesario para ser
transmitidos, especialmente indicadas en transmisiones de voz y video. Aunque,
como en el caso anterior, si provee de DCPs que definen una arquitectura para la
gestin de polticas de calidad de servicio. [UPNPQOS]

En cuanto a la Arquitectura AV de UPnP [UPNPAV]:

- No permite comunicaciones interactivas (Ejemplo: videoconferencia)
- No provee de ningn sistema de proteccin de contenido, tipo DRM, para
la gestin de derechos digitales.
- No proporciona soporte para la reproduccin sincronizada de un medio a
mltiples dispositivos de renderizacin 1 .

2.1.8 Justificacin del uso de UPnP

La realizacin de este proyecto viene motivada por la implementacin de un dispositivo
conforme a la especificacin UPnP para MediaRenderers. Define un conjunto de protocolos para
facilitar la comunicacin entre entidades conectadas en una misma red sin que el usuario tenga que
realizar complicadas configuraciones ni instalar drivers para su uso. Por este hecho, resulta una
tecnologa realmente interesante para su aplicacin en sistemas de entretenimiento en los que
participan varias entidades que permiten compartir el contenido multimedia en la red y el manejo
remoto de su renderizacin.

2.2 JMF
En este apartado se presenta la librera Java para aplicaciones multimedia, Java Media
Framework (JMF). Se describirn las principales clases e interfaces del API que define, con especial
atencin a la clase Player, as como la especificacin que define para el streaming RTP.
Seguidamente se enumerarn las distintas opciones para extender las capacidades de la misma. Y
por ltimo, se justificar su uso en este proyecto.

2.2.1 Introduccin
Java Media Framework 2 (JMF) es una librera Java que extiende a la Java 2 Platform,
Standard Edition (J2SE), proporcionando un entorno de trabajo Java para el desarrollo de
aplicaciones Java y Applets que manejen medios basados en tiempo (time-based media). Los medios
basados en tiempo son medios tales como el audio, el video, MIDI y animaciones que cambian con el
tiempo. [JMF]
Caractersticas principales de JMF en su ltima versin:
-

Programacin Multiplataforma: al estar implementado en Java asume sta

caracterstica del lenguaje.
Estabilidad: proporciona estabilidad al funcionar sobre la Mquina Virtual Java (JVM).
Sencillez: permite realizar tareas multimedia complejas usando unos pocos
comandos.
Manipulacin integral de medios: permite la captacin, procesamiento, reproduccin,
almacenamiento y difusin de medios.

Renderizacin: en el contexto de este proyecto, se refiere a la ltima fase del procesado multimedia en la que
los datos de audio, video o imagen son preparados para poder ser enviados a los respectivos sistemas de sonido
(altavoces) y visualizacin (pantalla).
Renderizar: accin de realizar la renderizacin.
2

Framework: conjunto de libreras software cuyo cdigo provee funcionalidad bsica, pudiendo ser sobrescrito y
especializado por el cdigo del programador. Proporciona un entorno de desarrollo de cdigo.

30

2. Marco terico

Flexibilidad: permite a desarrolladores y proveedores de tecnologa la implementacin

de soluciones personalizadas en base al API existente e integrar fcilmente nuevas
tecnologas en el Framework.
Extensibilidad: permite el desarrollo de plug-ins JMF. Estos son, demultiplexadores,
codecs (codificadores y decodificadores), procesadores de efectos, multiplexadores y
renderizadores.

En la siguiente figura se muestra la arquitectura software de JMF. Como se puede ver, est
basada en una Mquina Virtual Java. Los plug-ins se definen como mdulos que son registrados por
el Framewok para poder ser utilizados.

Figura 2.12. Capas de la arquitectura software de JMF

La Figura 2.13 representa una analoga del esquema de funcionamiento de JMF, similar al
proceso de reproduccin de un DVD. Una fuente de datos encapsula el media stream, flujo de
medios, multiplexado (audio y video), como lo hace un disco DVD. Posteriormente un reproductor
DVD, proporciona el procesamiento, principalmente la decodificacin, y los mecanismos de control.
Por ltimo, este reproductor demultiplexa la seal en una seal de audio y otra seal de video, y las
proporciona a los correspondientes renderizadores, como puede ser una pantalla y unos altavoces.
Tambin, puede transferir la seal procesada para su almacenaje en algn medio de almacenamiento
(cinta, CD, DVD, memoria USB,). O bien, puede ser enviada a travs de la red utilizando un
protocolo de transferencia como RTP (Real-time Transport Protocol). [JMFGUIA]

31

2. Marco terico

Figura 2.13. Analoga del funcionamiento de JMF [JMFGUIA]

Un flujo de medios es el conjunto de datos obtenidos de un fichero (multimedia) local, o
adquiridos de la red, o captados por una cmara o un micrfono. Los flujos de medios suelen
contener mltiples canales de datos llamados pistas. El tipo de pista identifica la clase de datos que
contiene, como audio o video y el formato de la pista define cmo estn estructurados sus datos. El
conjunto de ambas informaciones define el tipo de contenido (Content Type). Por ejemplo: Content
Type = audio/MPEG.
Un flujo de medios puede identificarse por su localizacin y el protocolo usado para acceder
a l. Se usa una URL para localizar un fichero remoto o local. Cuando no se puede usar la URL del
fichero, se usa un localizador de medios que, de forma similar a la URL, proporciona el camino para
identificar la localizacin del flujo de medios.

2.2.2 Principales clases e interfaces de la librera JMF

El API de la librera JMF consiste principalmente en interfaces y clases abstractas que definen
el comportamiento de objetos usados para capturar, procesar, presentar y almacenar medios
basados en tiempo.
A continuacin se presentan algunas de las ms relevantes para la comprensin del
funcionamiento bsico del Framework [JMFGUIA]:
DataSource
Un objeto de este tipo se encarga de encapsular la localizacin, el protocolo
de transferencia y el software necesario para la adquisicin del medio, es decir, del
contenido multimedia.
Se construye a partir de una URL o un localizador de medios definido por la
clase MediaLocator del API.
Los protocolos que usa esta librera para localizar el contenido multimedia
son FILE para el contenido almacenado en local, o HTTP para el contenido que se
encuentra en remoto.
Player y Processor
La funcin principal de un objeto de cualquiera de estos tipos es la de
manejar los datos multimedia obtenidos del DataSource, para su procesamiento y
presentacin. En el siguiente apartado, Fases del tratamiento de medios, se hablar
ms acerca de ellos.

32

2. Marco terico

DataSink
El ltimo paso en el procesado de los datos multimedia puede ser la
renderizacin, el almacenamiento en algn fichero o la transmisin. Para estos dos
ltimos JMF proporciona la clase DataSink. Con un objeto de esta clase se puede
obtener el flujo de medios y almacenarlo en un fichero local, o un fichero remoto o
transmitirlo mediante RTP.
Para la creacin de objetos de cualquiera de estas clases se usa un manejador implementado
por la clase Manager.

2.2.3 Player
Por su importancia en el contexto de este proyecto, a continuacin se describen algunas de
las caractersticas ms importantes de un objeto Player.
Un Player maneja el contenido multimedia de forma integral. Primeramente obtiene los
datos a partir de un DataSource y posteriormente permite su Demultiplexin, Decodificacin, y
Renderizacin. En la siguiente figura se muestra un esquema de este proceso.

Figura 2.14. Etapas del procesamiento de un Player [JMFGUIA]

Es conveniente recordar, que si se tienen diferentes flujos de medios se ha de usar un
Player para la reproduccin de cada uno.
En el proceso que realiza un Player el usuario no puede intervenir. Como consecuencia, no
soporta ningn control sobre el procesamiento que realiza, ni sobre cmo realiza la renderizacin de
los medios.
Provee interfaces de control para el proceso de descarga en cach (CachingControl) y el
control de la ganancia del volumen (GainControl). Por otra parte, dispone de mtodos para
establecer y obtener la tasa de reproduccin y un punto temporal en la reproduccin, y un mtodo
para la obtencin de la duracin del medio.
Proporciona un componente visual que representa la ventana de visualizacin del vdeo, en
caso de que el flujo de medios lo contenga, y que podr ser aadido como componente de la interfaz
grfica del reproductor.

33

2. Marco terico

Estados de un Player
Durante el proceso de reproduccin de un flujo de medios, un Player se puede encontrar en
cualquiera de los siguientes estados mostrados en la siguiente figura:

Figura 2.15. Estados del Player [JMFGUIA]

Unrealized: el Player ha sido instanciado pero an no conoce nada sobre su medio.

Realizing: el Player est procediendo a averiguar los recursos que necesita para la
reproduccin del medio. Adquiere los recursos que necesita al principio, con excepcin de
aquellos que son de uso exclusivo por un Player al mismo tiempo. Tambin es en este
proceso donde se realiza la descarga en local, caching, del medio, en el caso de que el
medio se encuentre en remoto y de estar disponible esta opcin.

Realized: el Player ha acabado el proceso de realizing y ya dispone del conocimiento

acerca de los requerimientos de recursos y la informacin sobre el tipo de medios que va
a presentar. En este momento, ya puede proporcionar los componentes visuales y de
control. Las conexiones a otros objetos en el sistema estn hechas, pero no posee ningn
mecanismo que evitase que otro Player arrancara.

Prefetching: el Player est preparado para presentar su medio. Durante esta fase se
precargan los datos, obteniendo recursos de uso exclusivo, y se prepara para arrancar. El
Prefetching debe repetirse si la presentacin del medio se reposiciona, o se produce un
cambio en la tasa de reproduccin que requiera aadir buffers adicionales o que se den
otros procesos alternativos en el Player.

Prefetched: el Player ya est preparado para ser arrancado.

Started: el Player ya ha arrancado. La referencia temporal de un Player (Base Time) y

el tiempo de reproduccin del medio (Media Time) son mapeados, y su reloj esta ya en
ejecucin.

Cuando el Player alcanza un determinado estado lanza un evento, Tansition Event.

Implementando la interfaz ControllerListener se puede escuchar estos y otros eventos lanzados
por el Player, y as permitir conocer en qu estado se encuentra y responder consecuentemente.
El conocimiento de los distintos estados por los que pasa el Player, as como el mecanismo de
escucha de eventos de transicin entre estados, se hace necesario a la hora de desarrollar cdigo
para la reproduccin de medios con JMF.

34

2. Marco terico

2.2.4 Soporte a RTP en la librera JMF

Streaming: Protocolo RTP
Antes de proceder con el API de JMF para RTP, se presentar brevemente el protocolo RTP.

Figura 2.16. Torre de protocolos para RTP/RTCP

Como se muestra en la figura anterior, RTP (Real Time Protocol) es un protocolo de nivel de
sesin definido sobre el protocolo de transporte UDP para la transmisin de flujos de datos
multimedia en tiempo real sobre la red.
Surgi para dar solucin a las limitaciones del protocolo HTTP para la realizacin de
streaming de audio y video. HTTP no fue diseado para este tipo de comunicaciones, requiriendo una
alta disponibilidad de la red para que la reproduccin resulte aceptable. Por ello, la mayora de las
aplicaciones consumidoras de contenidos alcanzables mediante HTTP realizan un paso previo de
almacenamiento temporal en local, como el anteriormente mencionado caching.
RTCP es un protocolo asociado a RTP para el envo de datos de control. Los paquetes RTCP
pueden contener informacin sobre calidad de servicio, sobre la fuente de los medios a ser
transmitidos, y sobre estadsticas de la sesin RTP. Se envan paquetes de control peridicamente a
todos los participantes de la sesin.
Una sesin RTP se define como una asociacin entre un conjunto de aplicaciones distribuidas
en una red y que se comunican con RTP. Una sesin se identifica por una direccin IP y un par de
puertos, uno para el flujo de datos y el otro para el de control. El de control suele ser el
inmediatamente posterior al de datos.
Especificacin de JMF para RTP
JMF permite la trasmisin y recepcin de flujos RTP a travs de APIs definidos para ello. Esta
especificacin del API para RTP est diseada para poder desarrollar fcilmente soluciones para el
streaming RTP. [JMFGUIA]
Recepcin:
Se pude recibir flujos RTP para su reproduccin local, para guardarlo en un archivo, o
procesarlo.
Los objetos Player y Processor son utilizados para manipular y presentar flujos de medios
RTP como cualquier otro medio almacenado en fichero.

35

2. Marco terico

A continuacin se muestra un esquema del procesado para la recepcin de un flujo RTP:

Figura 2.17. Esquema del proceso de recepcin RTP [JMFGUIA]

Para la recepcin y posterior presentacin de un nico flujo se puede crear un Player a
partir de un localizador de medios del tipo:
rtp://address:port[:ssrc]/content-type/[ttl]
Donde,
address: es la direccin IP utilizada en la sesin
port: es el puerto donde se recibe el flujo de datos
ssrc: es un identificador de la fuente de datos
ttl: time-to-life, es el tiempo de vida por defecto de los paquetes de datos
(Los campos ssrc y ttl son opcionales, y en el caso de ttl se utiliza para multicast).
Para la recepcin de uno o ms flujos se utiliza un manejador de sesin por cada uno de
ellos. Cuando se stos se reciban, se crearn tantos objetos Player como flujos de medios se
quieran presentar.
Transmisin:
Se pueden transmitir flujos de medios RTP almacenados en un archivo, o que hayan sido
capturados por un dispositivo de captura local. Un Processor es el encargado de procesar los datos
para adaptarlos a un formato RTP compatible. Posteriormente, un manejador de sesin se encargar
de crear el flujo a enviar. La siguiente figura muestra un esquema de este proceso.

Figura 2.18. Esquema del proceso de transmisin RTP [JMFGUIA]

Manejador de la sesin RTP
Tanto en la transmisin como en la recepcin, se ha de tener en cuenta que un manejador de
sesin slo puede manejar una nica sesin. Si una aplicacin maneja varias sesiones RTP, deber
crear un manejador de sesin por cada una de ellas.
Para la creacin de manejadores de sesiones el API de JMF define una clase abstracta,
RTPManager. Esta clase proporciona mtodos para la creacin, mantenimiento y cierre de una
sesin RTP. Habilita a una aplicacin a realizar funciones tales como iniciar la participacin en una
sesin o eliminar flujos individuales.
Por lo tanto, un manejador de sesin ha de extender esta clase sobrescribiendo sus mtodos
y aadiendo funcionalidad para controlar el estado de la sesin, los participantes y flujos activos,
manejar los canales de control RTCP, y otras capacidades.

36

2. Marco terico

La implementacin de referencia de la librera JMF, realizada por Sun Microsystems,

proporciona una clase, que extiende de RTPManager, y que asume toda esta funcionalidad. Se trata
de la clase [Link]. Para crear un manejador de sesin RTP basta
con construir una instancia de sta.
Creacin de la conexin
El API define una interfaz, RTPConnector, que permite al programador abstraer al
RTPManager del protocolo de transporte del flujo de datos y control de sobre el que se site RTP.
Implementando esta interfaz se puede enviar flujos RTP desde cualquier subcapa de red a travs de
sockets (puntos terminales de una conexin).
Durante la inicializacin del RTPManager se debe crear y aadir al mismo una
implementacin de la interfaz RTPConnector.
En el caso del emisor, el RTPManager crea el stream RTP para que posteriormente sea
transmitido a la red atravs del socket de salida creado para ello en la implementacin del
RTPConnector.
En el receptor, se espera a recibir un stream en el socket de recepcin creado para ello en la
implementacin del RTPConnector, para posteriormente crear un Player a partir de l.
Eventos RTP
Si se desea averiguar el estado de la sesin, es decir, cundo se incorpora o abandona un
participante, cuando llega un nuevo stream, o cuando se ha producido una colisin, entre otros casos,
se puede hacer uso de un mecanismo de notificacin de eventos RTP que proporciona el API de JMF
para RTP, al igual que ocurre con lo que se coment en apartados anteriores sobre los eventos de los
objetos Controller. Para poder recibirlos, se ha de implementar al apropiado escuchador,
Listener, y registrarlo en el RTPManager.

2.2.5 Extender la librera JMF

La funcionalidad de esta librera puede ser extendida por medio de:

La implementacin de nuevos componentes de procesamiento (plug-ins), tales como

codecs, parsers, effects, que se puedan intercambiar con los ya existentes.

La implementacin directa de algunas de las interfaces que define el API, tales como
Controller, Player, Processor, DataSource o DataSink.

2.2.6 Justificacin del uso de JMF

Al tratarse de un MediaRenderer, se hace necesaria una tecnologa que permita desarrollar
fcilmente cdigo para el procesado del contenido multimedia y su posterior renderizacin. El API de
JMF abarca todo el proceso, desde la obtencin del medio hasta su renderizacin, pasando por una
fase de procesamiento que incluye la decodificacin de los datos.
La aplicacin se ha desarrollado ntegramente en lenguaje Java, por lo que para mantener
una cierta coherencia, se deba usar una librera multimedia que estuviese implementada en este
lenguaje. La librera multimedia y multiplataforma de referencia en Java es, a da de hoy, JMF.
Su sencillez y extensibilidad permite crear cdigo para el tratamiento de medios multimedia
con cierta facilidad y poder extender su funcionalidad de la misma forma.

37

2. Marco terico

2.3 OSGi
En las prximas lneas de este apartado se estudiar la tecnologa OSGi. En primer lugar, se
har una breve introduccin para presentar las bases conceptuales de la misma. A continuacin se
enumerarn las caractersticas de esta especificacin y se describir la arquitectura software que
define. Al igual que en los anteriores apartados del captulo, en ltimo lugar se justificar el uso de la
tecnologa en este proyecto.

2.3.1 Introduccin
La tecnologa OSGi, de las siglas en ingls Open Service Gateway Initiative, especifica una
plataforma basada en Java para el desarrollo de aplicaciones y servicios. Su objetivo es el de
proporcionar una tecnologa que asegure la interoperabilidad entre estas aplicaciones y servicios y su
gestin remota a travs de la red.
Est promovida por la OSGi Alliance. Se trata de una organizacin creada en el ao 1999
para estandarizar los esfuerzos de conexin de un amplio rango de aplicaciones y dispositivos a un
entorno residencial. Est compuesta por compaas expertas en el sector tecnolgico entre las que
se encuentran conocidas compaas de tecnologa mvil, informtica, y desarrollo software. [OSGi]
Define un Framework Java, a travs de un conjunto de APIs, cuya principal aportacin es que
dota de modularidad dinmica a Java. De esta forma, una aplicacin Java puede ser construida a
partir de pequeos mdulos pre-compilados, reutilizables y compartidos por otras aplicaciones, y a su
vez se le proporciona la capacidad de poder ser gestionada dinmica y remotamente.
Est orientada a la capa de aplicacin, lo que permite al desarrollador de un servicio o
aplicacin abstraerse de aspectos subyacentes como el sistema operativo y el hardware de la
plataforma, las tecnologas de red o los protocolos de comunicacin.
En una plataforma de servicios OSGi, todos los servicios disponibles pueden ser utilizados
por las aplicaciones y/o otros servicios. A si mismo, una aplicacin puede exportar a la plataforma
servicios propios para poder tambin ser compartidos.
Los tipos de dispositivos donde se puede desplegar esta plataforma son todos aquellos que
representan los diversos mercados en los que los que los miembros de la alianza desarrollan su
actividad, tales como pasarelas de servicios, operadores de infraestructuras de red, desarrollo
software, automviles, mviles y un largo etctera.
Entre estos dispositivos cabe destacar, por su inters en el contexto de este proyecto, la
Pasarela de Servicios. Tambin llamada Pasarela Residencial o Pasarela Domstica cuando se
refiere al mbito de la vivienda. Este dispositivo conecta toda la infraestructura de telecomunicaciones
(datos, control, automatizacin, entretenimiento) del hogar digital a una red pblica de datos, como
Internet. Entre sus funciones estn las de router, hub, mdem, cortafuegos, y plataforma de ejecucin
de aplicaciones tpicas para el hogar, ya sean de entretenimiento, de vigilancia, de teleasistencia, ecomercio o control domtico. En este sentido, la especificacin OSGi proporciona a la pasarela un
entorno software para el desarrollo de este tipo de servicios y aplicaciones que pueden ser
desplegadas por la red y gestionadas remotamente.
La siguiente figura muestra el escenario tpico en el que una pasarela de servicios es utilizada
para interconectar las redes de una vivienda, y conectada con Internet permitiendo el manejo remoto
de la misma.

38

2. Marco terico

Figura 2.19. Pasarela de Servicios OSGi (Pasarela Domstica)

2.3.2 Caractersticas de la especificacin

Las caractersticas generales de la especificacin OSGi son:

Portable: las APIs de OSGi pueden ser implementados en un gran rango de plataformas
hardware y sistemas operativos, pudindose adaptar a mltiples soluciones en todos los
mbitos.

Segura: incorpora un modelo de seguridad que cubre varios niveles, permitiendo

proporcionar un entorno de ejecucin seguro.

Estndar: ofrece una plataforma comn para todos los fabricantes de dispositivos,
desarrolladores y proveedores de servicios para facilitar el avance de la tecnologa y a su
vez evitar los monopolios.

Abierta: no obliga al uso de ninguna tecnologa determinada. nicamente se deben

desarrollar aplicaciones y servicios compatibles con las APIs definidas.

Escalable: permite a los proveedores de sistemas personalizar y administrar fcilmente

la plataforma.

Dinmica: permite la actualizacin de los componentes software, pudiendo adaptarse a

las necesidades especficas del usuario, y sin tener que reiniciar el sistema.

Fiables: la plataforma debe estar operativa las 24 horas del da.

2.3.3 Arquitectura software

El Framework OSGi proporciona un entorno de ejecucin para aplicaciones y servicios,
programados en Java.

39

2. Marco terico

Figura 2.20. Capas de la Arquitectura Software de OSGi [OSGiAPUNTES]

Como se puede ver en la Figura 2.20, la base de su arquitectura software de OSGi es una
Mquina Virtual Java. Caractersticas del entorno de desarrollo Java, tales como, la seguridad, la
fiabilidad, la apertura, y sobre todo, la independencia de la plataforma, justifican este uso por guardar
perfecta coherencia con los objetivos de esta tecnologa.
Dentro de esta arquitectura software se pueden distinguir dos importantes entidades, los
bundles y los servicios.
Bundle
Los bundles son archivos empaquetadores Java (jar), compuestos por un conjunto de clases
(Java) y otros recursos necesarios para proporcionar funcionalidad a los usuarios finales y exportar
capacidades, denominadas Servicios, para que otros bundles puedan utilizarlos [OSGiSPECIFIC].
Son las entidades OSGi para el despliegue de aplicaciones Java. En este sentido, se pueden
construir una aplicacin en base a los servicios contenidos en el bundle, o bien, se puede integrar una
aplicacin completa dentro de un nico bundle.
Entre el conjunto de clases privadas contenidas en el jar, debe haber una que implemente la
interfaz BundleActivator, definida por el API de OSGi, donde necesariamente se deben
implementar dos mtodos start y stop, llamados al arrancar y terminar el bundle. El mtodo start
es utilizado para registrar servicios y localizar cualquier recurso que use el bundle. El mtodo stop es
utilizado para parar cualquier actividad, hilo de proceso que haya creado el mtodo start.
Dentro del mismo archivo debe incluirse un fichero de texto, denominado MANIFEST, en el
que figuran un conjunto de cabeceras que contienen la informacin que el Framework necesita para
que el bundle se instale y ejecute correctamente. Se describen a continuacin:
Bundle-Activator: Nombre de la clase que implementa la interfaz BundleActivator y que
sirve para iniciar y detener el bundle.
Bundle-Category: Lista de categoras de bundles a las que pertenece este mismo bundle.
Esto permite que los bundles sean listados por su categora.
Bundle-ClassPath: Nombre y localizacin de los ficheros JAR y otros recursos necesarios
para la ejecucin del bundle.
Bundle-ContactAddress: Direccin de contacto del fabricante del bundle.

40

2. Marco terico

Bundle-Copyright: Copyright del bundle

Bundle-Description: Informacin adicional sobre la funcionalidad y servicios del bundle.
Bundle-DocURL: Direccin URL donde se encuentra ms informacin acerca del bundle.
Bundle-Name: Nombre del bundle. Este debe ser corto y sin espacios. Es obligatoria.
Bundle-NativeCode: Especificacin de libreras de cdigo nativo contenidas en el bundle y
usadas por este.
Bundle-BundleRequiredExecutionEnvironment: Entornos de ejecucin requeridos que deben
estar presentes en la plataforma para la ejecucin del bundle.
Bundle-UpdateLocation: Ubicacin que se debe tener en cuenta para la actualizacin del
bundle.
Bundle-Vendor: Nombre del fabricante del bundle.
Bundle-Version: Versin del bundle.
Export-Package: Lista de paquetes que deben ser exportados para ser compartidos con otros
bundles en el Framework. Opcionalmente se puede indicar la versin del paquete.
Import-Package: Lista de paquetes que deben ser importados para la correcta ejecucin del
bundle. Los paquetes importados haber sido exportados previamente de otros bundles.
Opcionalmente se puede poner la versin del paquete que debe ser importado.
DynamicImport-Package: Lista de paquetes que deben ser importados dinmicamente, es
decir, cuando el cdigo en ejecucin lo precise.
Estas cabeceras estn definidas por OSGi y son todas opcionales, excepto Bundle-Name.
Es importante resaltar que el Framework OSGi define un contexto de ejecucin propio para el
bundle y habilita un rea de almacenamiento persistente para los recursos que ste necesita. Es
decir, se ha de utilizar este contexto de ejecucin para poder acceder a recursos, como puede ser un
fichero, que el bundle necesita. Este contexto viene definido por la interfaz BundleContext que
provee el API de OSGi.
Ciclo de vida de un bundle
El sistema de gestin de la plataforma permite que un bundle se descargue, se instale, se
ejecute, se detenga, se desinstale y se actualice, y todo sin tener que reiniciar el sistema.
Por tanto, un bundle puede encontrarse, en alguno de los siguientes estados:

Instalado (INSTALLED): cuando se instala exitosamente en la plataforma y conoce los

recursos que necesita, definidos en el manifiesto.

Inactivo (RESOLVED): todas las clases del bundle, incluidas las importadas, estn
disponibles y, por consiguiente, est preparado para ejecutarse.

Funcionando (STARTING): el bundle ha sido iniciado. Se ha llamado al mtodo start de

la clase que implementa la interfaz BundleActivator del mismo.

Activo (ACTIVE): el bundle se ejecuta exitosamente.

Parndose (STOPPING): el bundle deja de ejecutarse. Se ha llamado al mtodo stop de

la clase que implementa la interfaz BundleActivator del mismo.

41

2. Marco terico

Desinstalado (UNINSTALLED): el bundle ha sido desinstalado

La figura que se muestra a continuacin representa este ciclo de vida.

Figura 2.21. Ciclo de vida de un bundle [OSGiAPUNTES]

Servicio
Un Servicio es un objeto que proporciona funcionalidad. Es registrado por un bundle en el
Framework OSGi pare ser usados por otros bundles.
Como se dijo anteriormente, un bundle puede extender sus capacidades implementando
servicios disponibles en el Framework, y tambin, puede exportarlas registrando servicios para que
otros bundles puedan usarlos.
Para ello, el Framework de OSGi proporciona un Servicio de Registro, OSGi Service Registry,
que habilita a los bundles a:
-

Registrar servicios.
Buscar servicios en el registro.
Recibir notificaciones de cuando un servicio esta registrado o deja de estarlo.

La semntica y sintaxis de un servicio se especifica en un interfaz Java. En l se declaran los

mtodos que ofrece el objeto que representa el servicio. Para que un bundle asuma las capacidades
de este debe implementar sta interfaz. De esta forma, se hace una definicin abstracta de los
servicios, y son los fabricantes y desarrolladores los que los implementan de forma independiente.
Los bundles pueden acceder a los servicios disponibles en el Framework por medio del
BundleContext.
El BundleContext representa el entorno de ejecucin, especfico del bundle, que se crea
cuando ste se instala en el Framework. A travs de este se pueden realizar las mencionadas
operaciones de registro de servicios, obtencin de servicios registrados, as como agregar o eliminar
las suscripciones para la recepcin de eventos asociados a estos servicios.
La especificacin OSGi ha implementado varios Servicios Estndar que pueden ser
implementados por cualquier bundle y registrarlos por estos en el Registro de Servicios.
[OSGiSERVICES]

42

2. Marco terico

Servicios del Framework: para dirigir las operaciones en el Framework OSGi.

Servicios del Sistema: para proveer de funcionalidad comn a prcticamente todos los
sistemas donde se implemente OSGi.
Servicios de Protocolo: para mapear un protocolo externo en un servicio OSGi,
integrndole en la plataforma.
Otros: y otros servicios para funcionalidades especficas.

A continuacin se muestra un esquema de los servicios estndar proporcionados por la

versin 4 de la especificacin:

Figura 2.22. Esquema de los Servicios Estndar de OSGi

Se puede ampliar esta informacin sobre los Servicios Estndar de OSGi en la
documentacin de la especificacin disponible en la web oficial [OSGiSPECIFIC].

2.3.5 Justificacin del uso de OSGi

La especificacin OSGi constituye la tecnologa de un futuro, cada da ms cercano, para
integrar los mltiples servicios y aplicaciones ofrecidos a los consumidores a travs de Internet o
redes mviles. De este modo, servicios como el telecontrol, la video-vigilancia, la telemedicina, la
domtica, o el entretenimiento digital, pueden se gestionados de forma segura, fcil y con
independencia de las tecnologas de red, a travs de una plataforma comn.
La implementacin de esta plataforma como pasarela de servicios en el mbito de la vivienda,
permite la interconexin de mltiples dispositivos hardware y software que hacen uso de estos
servicios y aplicaciones. De esta forma se convierte en el ncleo del futuro Hogar Digital
[OSGiCASADOMO].
Por ello, en el desarrollo de una aplicacin software creada para el entretenimiento digital en
el hogar, es oportuno considerar stas tendencias y buscar la compatibilidad con esta tecnologa. En
consecuencia, la aplicacin se integra en un bundle OSGi, para as poder ser instalada y ejecutada
en pasarelas de servicios conformes con este estndar.

2.4 Resumen de la utilizacin de las tecnologas

OSGi, esencialmente, proporciona el control del ciclo de vida de la aplicacin permitiendo su
ejecucin en dispositivos avanzados para la gestin del hogar digital como las Pasarelas de
Servicios.
UPnP define cmo la aplicacin puede agregarse a una red (UPnP) y cmo puede ser
controlada remotamente usando mensajes XML enviados sobre HTTP. En base a este modelo de

43

2. Marco terico

comunicacin entre dispositivos UPnP, la Arquitectura para Audio y Video de UPnP, proporciona la
capacidad de compartir cualquier contenido multimedia localizado en la red domstica y su
reproduccin por medio de dispositivos de renderizacin distribuidos por la misma red como el
implementado en el presente proyecto. Todo esto controlado por el usuario a travs de un nico
dispositivo, el Control Point.
JMF provee un catlogo de mtodos, clases e interfaces Java con las que poder desarrollar el
cdigo necesario en la aplicacin para manejar el contenido multimedia desde su obtencin hasta su
renderizacin.

2.5 Estado del arte

Tras describir las principales tecnologas sobre las que se fundamenta este proyecto, y
profundizar en los conceptos tericos de la especificacin UPnP para el Media Renderer, se puede
proceder a evaluar la situacin actual de este tipo de dispositivos presentando las soluciones
disponibles en el mercado. Tras esto, se analizar de forma breve el estado de la librera JMF y se
enunciarn posibles alternativas a la misma que puedan salvar sus principales limitaciones. Por
ltimo, se enumerarn algunas de las soluciones software que implementan la plataforma OSGi en la
actualidad.

2.5.1 Implementaciones UPnP MediaRenderer

En la actualidad existen mltiples dispositivos conformes con el estndar UPnP. Se pueden
encontrar varias soluciones software y hardware de AV Control Point y MediaServers.
En cuanto a dispositivos UPnP MediaRenderer existen tambin varias soluciones hardware
pero, sin embargo, no es fcil encontrar una aplicacin software que cumpla la especificacin. Entre
las soluciones obtenidas que la cumplen no se ha encontrado ninguna que reuniese capacidades
tales como multiplataforma, integracin en plataformas OSGi o soporte especfico para IPv6.
Capacidades que por otro lado son marcadas como caractersticas generales del prototipo a
desarrollar, tal y como se mencion en la definicin de objetivos del presente proyecto.
A continuacin se listan las soluciones, software y hardware, que se han encontrado:
Software:

GMediaRender: se trata de una aplicacin de cdigo abierto para nicamente plataformas

Linux. Est implementada en lenguaje C, y basada en la librera multimedia GStreamer y
en la librera Portable SDK for UPnP Devices (libupnp) para el desarrollo de dispositivos
compatibles con UPnP. En la actualidad se encuentra en su versin 0.0.6 de 2007.
[GMRENDER]

MPlayer: es otra aplicacin de cdigo abierto y programada en C. Para la compatibilidad

con UPnP disponde de un componente, an en el estado inicial de su desarrollo,
denomindo UPnP-Control implementado tambin mediante el uso de la librera libupnp.
Al igual que en el caso anterior slo est disponible para las plataformas Linux. Aunque la
versin actual de la aplicacin, la 1.0, es del mismo ao que el de la ejecucin del
presente proyecto, no ocurre lo mismo con el mdulo para UPnP, cuya ltima
actualizacin se remonta al ao 2006. [MPLAYER]

Compre de Coherence: es una aplicacin, tambin de cdigo abierto, que combina un

UPnP Control Point y un UPnP MediaRenderer. Est programada en lenguaje Python y
diseada para ser integrada exclusivamente en el terminal mvil Nokia N800 Internet
Tablet. [COMPERE]

CyberLink PowerCinema: es una aplicacin multimedia avanzada y de cdigo cerrado

para PCs con plataformas Windows. Puede actuar tanto de UPnP MediaServer como de
UPnP MediaRenderer.[POWERCINEMA]

44

2. Marco terico

Hardware:

DLink-DSM 320/520/750, entre otros: se trata de una serie comercial de dispositivos

denominados Media Players inalmbricos, cada uno de los cuales conforman un UPnP
MediaRenderer.

Philips SL300/SL300i/SL400/SL400i, entre otros: se trata de otra serie comercial de

dispositivos completamente anlogos a la anteriormente presentada.

Roku SoundBridge: es un dispositivo reproductor de audio conforme a la especificacin

UPnP para Media Renderers. Dispone de su propio software para el control de la
reproduccin desde un PC. Fuera de Estados unidos, se comercializa por medio de la
marca Pinnacle.

Tambin existe cierta variedad de soluciones que permiten listar el contenido multimedia
compartido en una red UPnP y reproducirlos, pero no permiten ser controlados remotamente y en
algunos casos usan sus propios protocolos de transferencia para obtener el contenido. Se podra
decir que integran la capacidad de un UPnP AV Control Point de listar el contenido de un UPnP
MediaServer en un reproductor multimedia para su reproduccin. En algunos casos, a este tipo de
dispositivo se les denomina UPnP Player. Pero lgicamente no cumplen la especificacin de un UPnP
MediaRenderer.
Ejemplos de este tipo de reproductores son:
Software:

Nero 9.0: esta aplicacin de cdigo cerrado implementa esta capacidad por medio del
mdulo ShowTime. Slo est disponible para plataformas Windows. [NERO]

VLC 1.0: la ltima versin del reproductor de cdigo abierto VLC, pretende incorporar
este tipo de capacidad por medio del mdulo UPnP Player. Est programado en lenguaje
C y disponible para varias plataformas Windows, Linux, Mac, Solaris, etc. [VLC]

XBMC Media Center: es un programa de cdigo abierto y programado en C, que provee

una solucin para compartir el contenido multimedia distribuido en el hogar y su
reproduccin por medio del estndar UPnP. Est disponible para varias plataformas
Windows, Linux y Mac. [XBMC]

Pocket Player: se trata de un software de cdigo cerrado creado para poder listar y
reproducir el contenido multimedia disponible en una red UPnP. Est desarrollado
nicamente para dispositivos limitados, PocketPCs y SmartPhones. [POCKETPLAYER]

Hardware:

Videoconsola Xbox 360: permite la reproduccin de contenido almacenado en UPnP

MediaServers por medio del software anteriormente mencionado XBMC Media Center
para PCs.

Videoconsola PlayStation 3: este dispositivo permite listar el contenido localizable por

UPnP MediaServers y reproducirlo.

Terratec Noxon iRadio: se trata de un dispositivo con la misma capacidad que el caso
anterior pero nicamente para el contenido de audio.

Por otra parte, existen kits de desarrollo para la creacin de dispositivos UPnP. Se tratan de
APIs de programacin que facilitan el desarrollo de este tipo de aplicaciones.
Ejemplos de estos son:

Platinum UPnP SDK [SDKPLATINUM]

45

2. Marco terico

Portable SDK for UPnP Devices (libupnp 1.6.6) [SDKLIBUPNP]: las aplicaciones de
software libre GMediaRender y MPlayer, utilizan esta librera para el desarrollo de sus
capacidades UPnP.

2.5.2 JMF y alternativas

Como se dijo en su descripcin, JMF ha venido siendo hasta estos das la referencia dentro
de las libreras Java para el desarrollo de aplicaciones multimedia.
En el ao 2003, Sun Microsystems, el precursor de esta tecnologa, decidi dejar de dar
soporte a esta librera [JMFOUT]. Sin embargo, se sigue pudiendo descargar la ltima versin del
Framework desde su web oficial y se mantienen todos los recursos, desde documentacin hasta su
seccin dentro del foro general de Sun [JMFFORO]. No en vano, a da de hoy, la participacin en
este foro indica que se sigue utilizando como librera de referencia.
El problema inmediato es el desfase tecnolgico derivado de la continua aparicin de nuevos
formatos de audio y video, que obviamente JMF no soporta.
A continuacin se muestran las tablas de los formatos comunes soportados por JMF
[JMFGUIA].
Formato
Soportado

Tipo de Codec

Formato Contenedor

Requerimiento de
CPU

Cinepack

Video

AVI
QuickTime

Baja

MPEG-1

Video

MPEG

Alta

JPEG

Video

AVI
QuickTime

Alta

H261

Video

AVI

Media

H263

Video

AVI
QuickTime

Media

PCM

Audio

ADPCM (DVI)

Audio

ADPCM (IMA4)

Audio

GSM

Audio

G.711 (u-law)

Audio

Mu-law

Audio

AVI
QuickTime
WAV
AVI
QuickTime
WAV
AVI
QuickTime
WAV

Media

WAV

Baja

AVI
WAV
QuickTime
AVI
WAV
QuickTime

46

Baja

Media

Baja

Baja

2. Marco terico

G.723

Audio

WAV

Media

MPEG Layer 1,2

Audio

MPEG

Alta

Tabla 2.7. Formatos soportados por JMF

RTP
Payload

Tipo de Medio
Audio: G.711 (U-law) 8 kHz

Audio: GSM mono

Audio: G.723 mono

Audio: 4-bit mono DVI 8 kHz

Audio: 4-bit mono DVI 11.025 kHz

16

Audio: 4-bit mono DVI 22.05 kHz

17

Audio: MPEG Layer I, II

14

Video: JPEG ([Link], [Link], [Link])

26

Video: H.261

31

Video: H.263

34

Video: MPEG-I

32
Tabla 2.8. Formatos RTP soportados por JMF

En vista de esta limitacin en cuanto a formatos soportados, se pueden estudiar otras

alternativas Java a JMF. Entre ellas se pueden encontrar las siguientes:
-

Freedom for Media in Java (FMJ) [FMJ]: se trata de una librera multimedia Java basada
en la de JMF. De hecho es compatible con su API. Soporta ms formatos mediante plugins, al igual que JMF, y sobre todo por medio de la utilizacin de envoltorios (wrappers)
para la utilizacin de libreras de codecs nativas como FFMPEG. El problema de esta
librera es que no parece estar completa y su uso no est muy extendido.

Java Media Component (JMC) [JMC]: es una nueva librera de Sun Microsystems para
incorporar capacidades de procesado simple multimedia a las aplicaciones Java. Podra
convertirse en la alternativa, quizs algo ms limitada, de la propia librera JMF. Sin
embargo, an no hay suficiente informacin, y slo se pude conseguir a travs de la
descarga del SDK (Software Development Kit) de JavaFx.

JavaFX: es una tecnologa lanzada recientemente por Sun Microsystems cuya finalidad
es proveer de un conjunto de herramientas para facilitar el desarrollo de aplicaciones web
con capacidades de aplicaciones de escritorio, como las aplicaciones multimedia. Las
clases de JavaFx para el desarrollo de aplicaciones multimedia estn basadas en JMC. El
uso de sta tecnologa podr ser interesante en futuros proyectos. A da de hoy hay cierta
confusin sobre cmo se relacionan las clases Java comunes con la clases JavaFx,
adems su reciente lanzamiento provoca que surjan continuos bugs que debern ser
tratados.

47

2. Marco terico

JVLC: permite la integracin del reproductor nativo VLC en aplicaciones Java a travs de
la librera Java JNA (Java Native Access) para el acceso a cdigo nativo. JVLC provee un
conjunto de mtodos y clases Java que estn vinculados con el cdigo nativo de VLC.
Por tanto es dependiente de la versin de VLC instalada. Desde hace varios meses se
retiraron los sitios web oficiales de esta tecnologa, lo que complica su utilizacin.
Adems, el conjunto de mtodos disponibles para el procesamiento multimedia podran
resultar limitados.

JMF + plug-ins: a pesar de no poder utilizarse el cdigo fuente de la librera JMF por estar
sujeto a una licencia SCSL de Sun [SUNSCSL] que restringe su uso, gracias a la
extensibilidad y modularidad proporcionada por los plug-ins JMF que se pueden integrar
en el Framework, resulta relativamente sencillo ampliar el nmero de codecs soportados.
Esto es lo que se consigue con soluciones como:

Fobs4JMF [FOBS]: plug-in de Fobs que acta como envoltorio de la librera

FFMPEG de codecs, permitiendo dar soporte a formatos como ogg, theora, divx,
xvid, h264, etc.
Jffmpeg [JFFMPEG]: se trata de otro plug-in que envuelve la librera FFMPEG. En
este caso su comportamiento con los ficheros de video no resulta aceptable.
mp3plug-in [MP3PLUG-IN]: plug-in creado por Sun Microsystems para el soporte
del conocido formato de audio MP3 (MPEG-1 Layer 3).

A pesar de las limitaciones mencionadas de JMF, se opt por utilizar esta librera
conjuntamente con plug-ins de codecs, por continuar siendo a da de hoy la librera multimedia Java
de uso ms extendido. Tambin por su extensibilidad a travs de plug-ins, y por toda la
documentacin y soporte a travs de los foros de Sun que an est disponible.

2.5.3 Implementaciones software de OSGi

Existen mltiples implementaciones de la plataforma OSGi en la actualidad. En la lista que se
presenta a continuacin se muestran las ms conocidas de entre las disponibles:
Propietarias

mBedded Server de Prosyst [PROSYST]: en su versin ms actualizada implementa la

especificacin OSGi Release 4. Existen varias ediciones del producto en funcin de los
distintos entornos de desarrollo:
-

mBedded Server Equinox Edition: de cdigo abierto. Basado en el Framework de

OSGi que proporciona Equinox (Eclipse) y al que aade nuevas caractersticas.
Destinado al desarrollo de proyectos de cdigo abierto.

mBedded Server Professional Edition: apropiado para el desarrollo de pequeas

plataformas en dispositivos con recursos limitados.

mBedded Server CLDC Edition: apropiado para la implementacin de la plataforma

en dispositivos, con recursos muy limitados, con Mquinas Virtuales Java
compatibles con la configuracin Connected Limited Device Configuration (CLDC)
(implementa OSGi R3)

Sobre las dos primeras ediciones se especifican tres distintas extensiones:

-

mBS Smart Home Extension: extensin orientada al desarrollo de la plataforma en

pasarelas domsticas.

mBS Telematics Extension: extensin orientada principalmente al desarrollo de

plataformas para el sector automovilstico.

mBS Mobile Extension: extensin orientada al desarrollo de la plataforma en

dispositivos mviles.

48

2. Marco terico

Lotus Expeditor Client Platform de IBM [EXPEDITOR]: esta plataforma implementa la

especificacin OSGi R4. Proporciona una solucin completa y escalable para el
despliegue, mantenimiento y eliminacin de aplicaciones y componentes de aplicaciones
sobre multitud de dispositivos.

De cdigo abierto

mBedded Server Equinox Edition: visto anteriormente.

Knopflerfish de Makewave (anterior Gatespace Telematics AB) [KNOPFLERFISH]: es una

implementacin abierta, en la actualidad del Realease 4 de OSGi, que permite la gestin
de las aplicaciones de una forma ms visual e intuitiva que las otras implementaciones.
En estos momentos se encuentra en su versin 2.3.

Felix de la fundacin Apache [FELIX]: implementa la especificacin OSGi R4. Suministra

un Framework OSGi completo. Actualmente se encuentra en su versin 1.8.

Equinox desarrollado por la comunidad Eclipse [EQUINOX]: implementa la especificacin

OSGi R4. Es el responsable de los desarrollos OSGi de Eclipse. Abarca todos los
sectores donde implementar OSGi (Telefona Mvil, Hogar y Automocin)

Newton Project de Paremus [NEWTON]: es un Framework OSGi distribuido basado en

Service Component Architecture (SCA). Proporciona la capacidad de desplegar y
gestionar dinmicamente servicios y bundles de OSGi y los distribuye entre diferentes
recursos. Actualmente se encuentra en su versin 1.3.2.

49

3. Implementacin

3. Implementacin
En este captulo se aborda el diseo de un UPnP MediaRenderer en base a los criterios
establecidos por las distintas tecnologas que se han ido definiendo en el captulo anterior.
Para facilitar la compresin de este captulo se han utilizado varios diagramas UML que
sintetizan de forma grfica las caractersticas y arquitectura del sistema diseado. En el ANEXO III
se explica la simbologa de estos diagramas.
Como paso previo se analizarn los requisitos del sistema y se expondrn los Casos de Uso
del mismo. Tras esto, se enumerarn las herramientas utilizadas para el proceso y finalmente se
describir la implementacin obtenida.

3.1 Anlisis de requisitos

En primer lugar se ha de analizar los requisitos previos que se cumplirn. En este sentido, se
definieron un conjunto de requisitos, tanto funcionales como no funcionales, que la implementacin
deba cumplir en base a los objetivos marcados al inicio del proyecto. Estos son:
Requisitos funcionales:
1. Compatibilidad con UPnP: la aplicacin ha de cumplir con los protocolos que define el
estndar UPnP. Permitiendo el control de la misma por el Punto de Control o Control
Point e implementando los tres servicios definidos para un UPnP MediaRenderer.
[Obligatorio]
2. Control de la reproduccin: se debe proporcionar soporte para las acciones comunes de
un reproductor multimedia, tales como, Arrancar, Pausar, Ir al siguiente tem, Ir al anterior
tem, Parar, Subir y Bajar el volumen, o Silenciar el audio. [Obligatorio]
3. Visualizacin de imgenes: se debe proporcionar soporte para la visualizacin de
imgenes. [Obligatorio]
4. Reproduccin de flujos RTP de audio y video: se debe proporcionar soporte para el
manejo y reproduccin de flujos RTP de audio y video (streaming RTP). [Obligatorio]
5. Reproduccin de flujos HTTP de audio y video: se debe proporcionar soporte para la
reproduccin de contenido de audio y video obtenido a travs del protocolo HTTP.
[Obligatorio]
Requisitos no funcionales:
1. Compatibilidad con IPv6: la aplicacin debe ser compatible con el protocolo de red IPv6,
para poder ser utilizada en escenarios con redes IPv6. [Obligatorio]
2. Multiplataforma: se ha de buscar una solucin multiplataforma. Principalmente, la
aplicacin ha de poder ser ejecutada en las dos plataformas ms comerciales, Linux y
Windows. [Obligatorio]
3. Integracin en OSGi: la aplicacin debe integrarse en una plataforma OSGi, por lo que ha
de ser conforme con la ltima versin del estndar, OSGi Release 4. [Obligatorio]
4. Reproduccin de los formatos ms comunes: se ha de buscar una solucin que pueda
soportar los formatos de codificacin ms comunes tanto de audio y video como de
imgenes. [Obligatorio]

50

3. Implementacin

5. Extensibilidad: se pretende realizar un diseo que permita extender la funcionalidad de la

aplicacin, ya sea aadiendo plug-ins de codificacin o aadir nuevos servicios UPnP.
[Opcional]

3.1.1 Casos de uso

Tras haber definido los requisitos del sistema se pude generar el Diagrama de Uso del
mismo. Este diagrama pretende representar de forma grfica y sencilla la funcionalidad de la
aplicacin y su interaccin con los actores que intervienen en el proceso.
Se han definido tres actores diferentes:

Control Point (Punto de Control): se trata del Control Point de la arquitectura UPnP para audio
y video. Permite al usuario controlar al MediarRenderer adems de recibir la informacin de
estado de los servicios asociados a ste.

Plataforma OSGi: a travs de la implementacin de la plataforma OSGi se controla el ciclo de

vida de la aplicacin al estar integrada en un bundle, permitiendo que el dispositivo se inicie y
agregue a la red UPnP o que la abandone al parar su ejecucin.

UPnP MediaServer: se trata de los dispositivos MediaServers de UPnP disponibles en la red.

Proporcionan el contenido multimedia que se comparte en la red UPnP para poder ser
renderizado por el MediaRenderer.

Figura 3.1. Diagrama de Casos de Uso

51

3. Implementacin

A continuacin se definen brevemente los casos de uso del diagrama:

1. Agregarse a la red UPnP

Descripcin: La plataforma OSGi controla el ciclo de vida del bundle, y por

consiguiente de la aplicacin. Por tanto, cuando el bundle pasa a estado Active,
inicia el proceso para agregarse a la red UPnP y ser descubierto por el Control
Point.
Actores implicados: Plataforma OSGi, Control Point.
Casos de Uso relacionados:Precondiciones: Postcondiciones: tras el descubrimiento del dispositivo, el Control Point puede
controlar la renderizacin del contenido y recibir informacin del estado de los
servicios asociados a ste.

2. Abandonar la red UPnP

Descripcin: Cuando se para el bundle y va a pasar al estado Resolved de su ciclo de

vida, la aplicacin inicia el proceso para parar todos los hilos de ejecucin relativos a
la renderizacin y abandonar de forma ordenada la red UPnP.
Actores implicados: Plataforma OSGi, Control Point.
Casos de Uso relacionados:Precondiciones: Es necesario que el dispositivo se haya agregado con xito a la red.
Postcondiciones: La aplicacin deja de estar disponible.

3. Generar informacin de estado

Descripcin: UPnP dispone de un mecanismo de eventos para el envo de

informacin al Control Point sobre el estado de los servicios asociados al dispositivo.
La aplicacin genera y enva la informacin necesaria cuando y como la
especificacin UPnP establece. Un proceso de renderizacin incluye el modelado del
estado de los servicios relacionados con este proceso (AVTransport Service y
RenderingControl Service) generando la correspondiente informacin.
Actores implicados: Control Point
Casos de Uso relacionados: Renderizar contenido multimedia
Precondiciones: Es necesario que el dispositivo se haya agregado con xito a la red.
Postcondiciones:-

4. Renderizar contenido multimedia

Descripcin: El usuario, a travs del Control Point, controla la renderizacin del

contenido multimedia localizado por el MediaServer. La aplicacin procesar de
forma distinta este contenido en funcin del tipo que sea: una imagen, o un flujo
HTTP de audio y/o video, o un streaming RTP.
Actores implicados: MediaServer, ControlPoint.
Casos de Uso relacionados: Visualizacin imgenes, reproduccin flujo HTTP,
reproduccin flujo RTP, generar informacin de estado.
Precondiciones: Es necesario que el dispositivo se haya agregado con xito a la red.
Postcondiciones:-

52

3. Implementacin

En la siguiente tabla se muestra la relacin entre los requisitos del sistema y los casos de uso
descritos:
Casos de Uso
Requisitos

Caso 1
Agregarse a la
red UPnP

Compatibilidad con
UPnP
Control de la
reproduccin
Visualizacin de
imgenes
Reproduccin de
flujos RTP
Reproduccin de
flujos HTTP
Compatibilidad con
IPv6
Multiplataforma
Integracin en OSGi
Reproduccin de
formatos comunes
Extensibilidad

Caso 2
Abandonar la
red UPnP

Caso 3
Generar
informacin de
estado

Caso 4
Renderizar
contenido
multimedia

X
X
X
X

X
X

X
X

X
X

Tabla 3.1. Casos de Uso frente a requisitos

3.2 Herramientas utilizadas

Uno de los primeros pasos del desarrollo de un proyecto es definir el entorno de desarrollo en
el que se va a trabajar. A continuacin se enumeran las herramientas que han sido utilizadas durante
todo el proceso de creacin de la aplicacin.
Sistemas Operativos
Los sistemas operativos que se han utilizado para el desarrollo de la aplicacin han sido,
Windows XP en su versin Home Edition y una distribucin GNU/Linux, la Ubuntu versin
8.04. En cada fase de la implementacin el cdigo se ha probado en ambas plataformas.
Programacin
La utilizacin de Java como lenguaje de programacin ha permitido cumplir varios de
los requisitos del sistema descritos con anterioridad. Java es un lenguaje multiplataforma, es
decir, que el cdigo puede ser ejecutado en todas las plataformas que dispongan de Mquina
Virtual Java. Por otra parte, Java soporta el direccionamiento con IPv6, y el desarrollo de
interfaces grficas y manejo de imgenes a travs de paquetes integrados en el API para
varias versiones de la plataforma J2SE (Java Swing, AWT). En este proyecto se han utilizado
las versiones JDK1.6 para Windows y JDK1.7 para Ubuntu.
Como ya se ha comentado cuando se present JMF, sta librera multimedia
proporciona a la aplicacin el procesado de datos multimedia desde su obtencin a su
renderizacin. Permite el control de la reproduccin por medio de una sencilla invocacin de
mtodos que definen acciones comunes de un reproductor, como las mencionadas en los
requisitos y otras ms. Tambin se dijo que JMF posee un API para RTP con el que dar
soporte a la implementacin para abrir sesiones RTP y recibir flujos en este formato.

53

3. Implementacin

En el apartado Estado del Arte del captulo Marco terico, se habl sobre las
limitaciones de JMF respecto de los formatos soportados. Para aumentar el nmero de
formatos soportados se han utilizado los siguientes plug-ins:
-

Fobs4JMF: para formatos de video como, los contenidos en un fichero AVI (divx,
xvid,...), h264, etc.
Jffmpeg: para la decodificacin MP3 (MPEG-1 Layer 3) en contenidos con audio y
video.
mp3plug-in: para la decodificacin MP3 de archivos de audio.

Por otra parte, para incorporar toda la funcionalidad sobre protocolos UPnP, y por
tanto cumplir con la especificacin, se ha utilizado el conjunto de clases Java que provee la
aplicacin Cidero [CIDERO]. Se hablar detalladamente sobre su uso en el apartado
Implementacin de la aplicacin: HomeAV.
Entorno de Desarrollo Integrado
Para la programacin se ha de utilizar un software que integre un conjunto de herramientas
para el desarrollo de programas en Java y que facilite esta tarea (IDE, Integrated
Development Environment). En este caso se ha utilizado un software de cdigo abierto
denominado Eclipse. La versin utilizada es la 3.3.2. [ECLIPSE]
Plataforma OSGi
Uno de los requisitos no funcionales del sistema es su integracin en una plataforma OSGi.
La implementacin del Realease 4 del Framework de OSGi que se ha utilizado es la que
provee la versin mencionada de Eclipse y que lleva el nombre de Equinox en su versin
3.3.0. Aunque para la realizacin de pruebas tambin se ha utilizado la versin 1.8.0 de Felix.
Dispositivos UPnP
Para crear el escenario definido por la arquitectura AV de UPnP se han utilizado los
siguientes dispositivos que cumplen con el estndar:

Control Point la versin 1.5.3 de Cidero. Se trata de una aplicacin de cdigo

abierto cuya librera est basada en la de Cyberlink [CYBERGARAGE] para la
creacin de dispositivos UPnP.

UPnP MediaServer se han utilizado dos aplicaciones: CMGate [CYBERGARAGE],

aplicacin de cdigo abierto y basada en Cyberlink, y la versin 11 del Windows
Media Player [WMP11].

Servidores de streaming RTP

En el momento en el que se realiz este proyecto todos los UPnP MediaServer que
se encontraron facilitaban el acceso a los contenidos multimedia a travs del protocolo HTTP.
En ningn caso tenan capacidad para realizar streaming RTP. Por ello, se utilizaron
aplicaciones no compatibles con UPnP para el envo de flujos RTP (se hace referencia a esto
en el captulo Pruebas). Estos programas son:

JMStudio, aplicacin propiedad de Sun Microsystems que se distribuye junto con la

librera JMF.

RTPTransmite3, clase Java desarrollada por Sun Microsystems. Se trata de un

pequeo programa, basado tambin en la librera JMF, y que permite transmitir y
recibir flujos RTP utilizando sockets UDP [JMFCUSTOMRTP].

54

3. Implementacin

Otras herramientas

Ethereal: es un analizador de protocolos. Se ha utilizado para el anlisis y

monitorizacin de las comunicaciones de red entre los dispositivos UPnP.

Herramientas de edicin de diagramas UML: MaintainJ [MAINTAINJ] en su versin

2.5.3, para generar los diagramas de secuencia, y SDE (Smart Development
Environment) [SDE] en su versin 4.0, para los diagramas de caso de uso y de clase.

3.3 Implementacin de la aplicacin: HomeAV

En este apartado se presenta la aplicacin que ha sido desarrollada. Se har una breve
introduccin en la que se describir el proceso de su implementacin. Posteriomente se enunciarn
las caractersticas funcionales principales de la misma, seguido de una sntesis de su arquitectura de
clases y mtodos. Finalmente, se muestran los diagramas de secuencia de los procesos de mayor
relevancia entre todos los que suceden durante su ejecucin, y un ltimo esquema representando los
distintos estados en los que se puede encontrar el proceso de renderizacin.

3.3.1 Introduccin
En las prximas lneas se describen las fases que han compuesto el proceso de
implementacin de la aplicacin, cada una de las cuales representa una unidad funcional de la
misma. Estas son:
1. Creacin de un dispositivo UPnP y definicin de los servicios asociados a un
MediaRenderer.
El paso previo a la programacin del dispositivo es la creacin de los documentos de texto en
formato XML. Uno como descriptor del dispositivo y los respectivos descriptores de los
servicios asociados al mismo.
Para la programacin, en esta fase se ha utilizado la librera Cyberlink [CYBERGARAGE] que
se distribuye con la aplicacin Cidero. Esta proporciona toda la funcionalidad necesaria para
la creacin de un dispositivo UPnP. Implementa cada uno de los protocolos que especifica el
estndar (SSDP, SOAP,), y por consiguiente, cada una de las fases en la comunicacin
UPnP entre dispositivo y Control Point. Para ello define un conjunto de mtodos y clases
perfectamente estructurado. (Ver ANEXO I sobre Cidero/Cyberlink)
Para la implementacin de los servicios asociados a un UPnP MediaRenderer tambin se ha
utilizado la librera de Cidero. Esta librera, a parte de contener la ya mencionada Cyberlink,
posee un catlogo de mtodos y clases propios que definen perfectamente los servicios que
componen un UPnP MediaRenderer, y sus respectivas acciones y variables de estado. Se
implementaron los servicios: ConnectionManager Service, AVTransport Service y
RenderingControl Service. (Ver ANEXO I sobre Cidero/Cyberlink)
Tambin en esta fase se define la interfaz grfica mnima de la aplicacin utilizando el
paquete Java Swing que ya mencionamos en el apartado Herramientas utilizadas. Esta
interfaz no dispone de botonera, y nicamente servir para poder aadir el componente visual
del video que se vaya a reproducir y algunos parmetros bsicos asociados a la reproduccin
como son el ttulo del medio, la duracin y la referencia temporal de la reproduccin.
2. Reproduccin de contenido multimedia (HTTP)
Una vez conocido y adaptado el cdigo necesario para la comunicacin con el Control Point,
incluyendo el conjunto de acciones de los servicios que pueden ser invocadas, las variables
de estado, y toda la lgica asociada a esto, se procedi a la fase para la implementacin de
las capacidades de reproduccin de contenido multimedia. Para ello, como ya se ha
comentado en varias ocasiones, se ha utilizado el API de JMF. En esta fase se estudi e
implement el cdigo necesario para la reproduccin de contenidos multimedia, audio y video,

55

3. Implementacin

alojado en otro equipo y obtenido a travs de la red utilizando el protocolo HTTP. Para ello, se
utilizaron los mtodos, clases e interfaces, de entre las que proporciona JMF, para la creacin
del reproductor multimedia (Player), la invocacin de sus controles bsicos (Play(),
Stop(), Pause(), SetVolume(), SetMute(),) asocindolos con las acciones definidas
para ello por los servicios UPnP implementados, AVTransport Service y RenderingControl
Service.
Tambin se crea un mecanismo, basado en generacin y escucha de eventos, para trasladar
informacin acerca del xito de la invocacin de los controles mencionados y del estado en el
que se encuentra el Player a las clases que implementan los servicios UPnP anteriores, y que
necesiten esta informacin para definir su modelo de estado e informar de las modificaciones
en ste al Control Point.
3. Visualizacin de imgenes
En esta fase se aade la capacidad de visualizar imgenes. Para ello se hace uso de los ya
mencionados paquetes, Java Swing y AWT.
Adems, se incorpora la funcionalidad necesaria al mecanismo para el traslado de
informacin a los servicios UPnP que se derive del proceso de visualizacin de imgenes.
4. Recepcin y reproduccin de flujos RTP
Para la recepcin y reproduccin de flujos RTP se vuelve a hacer uso de JMF, en concreto de
la especificacin de la misma para streaming RTP. En este caso se implement un receptor
de streaming RTP que crea sesiones RTP para la recepcin, utilizando sockets UDP. Para
conseguir esto, se han utilizado las clases de un pequeo programa creado por Sun
Microsystems, que tambin se utiliza en las pruebas para la transmisin de flujo RTP, y que
ya se present en el apartado Herramientas del Sistema en la seccin que habla sobre
servidores de streaming RTP.
Las acciones que definen los servicios, al igual que con el flujo HTTP, son asociadas con la
invocacin de los mtodos para la creacin de la sesin RTP (Play()), pausar la transmisin
(Pause()), cerrar la sesin (Stop()), o modificar el volumen (SetVolume() o SetMute()).
Al igual que en la fase anterior, se aade la funcionalidad necesaria el mecanismo de
generacin y escucha de eventos para trasladar la informacin relativa al estado de la sesin
RTP o informar del xito de las invocaciones a los mtodos relacionados con el control de
esta o la renderizacin.
5. Integracin en OSGi
Una vez creado el UPnP MediaRenderer con la funcionalidad requerida y habiendo sido
probado en un escenario UPnP real, se procedi a transformar la aplicacin en un bundle
OSGi para poder ser integrada en una plataforma OSGi. Para ello, se utiliz el API de OSGi
en la versin para el Release 4 de la plataforma.
En cada una de estas fases, el cdigo generado era sometido a un proceso de depuracin
con el que se comprobaba el correcto funcionamiento del sistema. Posteriormente era probado tanto
en un equipo Windows como en un equipo Linux, y utilizando tanto el protocolo IPv4 como IPv6 en las
comunicaciones. Con la realizacin de estas pruebas se aseguraba la independencia del cdigo
respecto de ambas plataformas y la compatibilidad de la aplicacin con ambos protocolos de red.

56

3. Implementacin

3.3.2 HomeAV

Figura 3.2. Interfaz Grfica de HomeAV

En las prximas lneas se presenta el prototipo de UPnP MediaRenderer que se ha diseado.
Se ha pretendido implementar una estructura lgica lo ms sencilla e intuitiva posible que
facilite no slo su compresin sino tambin la integracin de mayores capacidades en un futuro.
Se ha utilizado el Ingls en toda la programacin y para comentar el cdigo. Esto viene
motivado principalmente por el carcter global de las tecnologas en las que se basa la aplicacin, as
como por guardar una mayor coherencia con la utilizacin de libreras Java definidas en este idioma.
Se han declarado algunos mtodos como estticos cuando se ha considerado que se
facilitaba su uso, no teniendo que instanciar las respectivas clases que los contienen para ser
invocados.
Qu es HomeAV?
HomeAV es el nombre con el que se ha bautizado el prototipo. Se trata de una aplicacin que
conforma un dispositivo UPnP MediaRenderer con las siguientes capacidades:
-

Compatibilidad con UPnP, dando soporte a todos los protocolos definidos por el estndar
y permitiendo la comunicacin con los AV Control Point de UPnP que se encuentren en la
red domstica.

Da soporte a la accin SetNextAVTrasnportURI() del servicio AVTransport de un UPnP

MediaRenderer para una reproduccin continua de tems, es decir, sin huecos temporales
entre tem e tem.

Reproduce el contenido multimedia disponible en la red UPnP domstica, obtenido

utilizando el protocolo de transporte HTTP. Este contenido incluye audio y video con los
formatos ms comunes (MPEG, DIVX, AVI, MP3, WAV,...).

Permite el almacenamiento temporal en local (caching) del contenido multimedia

previamente a su renderizacin. nicamente tiene sentido para el contenido, ficheros de
audio y video, obtenido mediante HTTP.

Visualiza imgenes con los formatos ms comunes (JPEG, GIF, PNG, TIFF).

Reproduce el contenido de audio y video disponible en la red UPnP por medio de flujos
RTP, pudiendo abrir dos sesiones para flujos de audio y video respectivamente enviados
a la misma IP pero a puertos contiguos. Soporta los formatos RTP ms comunes de audio
y video (MPEG, JPEG, H623, MPEGAudio, G.723, GSM, DVI,...).

Soporta el protocolo IP de nueva generacin, IPv6.

Integracin en una plataforma OSGi. Un bundle OSGi contendr a la aplicacin para

poder ser desplegada en pasarelas domsticas.

57

3. Implementacin

3.3.3 Arquitectura de clases

En este apartado se describen el conjunto de paquetes y clases que componen HomeAV.
Tambin, por su importancia, se mencionan algunos mtodos definidos en ellas.
En la siguiente figura se muestra el diagrama de clases de HomeAV. Se recomienda
consultar el ANEXO III sobre Diagramas UML para su mejor interpretacin.
Posteriormente, se describen los tres mdulos funcionales en los que se ha subdividido la
aplicacin: Mdulo raz, Mdulo UPnP y Mdulo multimedia. Cada uno de ellos corresponde con cada
uno de los paquetes principales de clases e interfaces Java que aparecen en el diagrama.

58

3. Implementacin

Figura 3.3. Diagrama de Clases de HomeAV

59

3. Implementacin

Mdulo raz
Se trata del mdulo principal. A parte de contener los paquetes de clases [Link] y
[Link] para implementar funcionalidades concretas del sistema, es el que gestiona
la puesta en marcha y el cierre de la aplicacin.
Paquete
homeAV

Clases contenidas
HomeAVActivator
HomeAVMain

Paquetes contenidos
[Link]
[Link]

Interfaces contenidas
Locator

<<Ver los respectivos mdulos>>

Tabla 3.2. Composicin del Mdulo raz

Clases
-

HomeAVActivator es la clase que implementa a la interfaz BundleActivator que

provee el API de OSGi. Define los mtodos para provocar el arranque (start()) y la
parada (stop()) del bundle, los cuales sern usados por la implementacin OSGi para la
gestin del ciclo de vida del bundle.
Implementa la interfaz Locator para declararse como localizador y definir los mtodos
para la obtencin de ficheros que se encuentren dentro del directorio de la aplicacin, es
decir, en el comprimido (.jar) del bundle y a los que se accede por medio del contexto de
ejecucin del mismo. Al llamar al mtodo de arranque de HomeAVMain (start()), se
pasa a s mismo como argumento. De esta forma HomeAVMain puede hacer uso de
estos mtodos.

HomeAVMain es la clase principal de HomeAV. Es utilizada por la anterior clase para

arrancar y cerrar la aplicacin por medio de la invocacin de los respectivos mtodos
start() y destroy().
El primer paso en el arranque es la carga de los ficheros que se necesitan durante el
inicio. Para ello hace uso de la instancia de la clase que implementa Locator, en este
caso HomeAVActivator. Estos ficheros son:
-

[Link]: documento en texto plano con el que se configura los parmetros

de inicio de la aplicacin. (Ver ANEXO IV: Ficheros de la aplicacin)
[Link]: fichero en formato XML con la descripcin UPnP del dispositivo
(aplicacin). Este fichero ser utilizado cuando se inicie la comunicacin UPnP.
(Ver ANEXO IV: Ficheros de la aplicacin)

Se crea una instancia esttica de cada una de las clases principales de cada paquete que
contiene, MediaRenderer ([Link]) y HomeAVMediaRenderer ([Link]),
como consecuencia de su uso en un mtodo esttico. Y adems, en el primer caso,
facilita la invocacin de sus mtodos desde otros mtodos de otras clases que no
pertenecen a su mismo paquete.
-

Locator (interfaz): es utilizada para definir localizadores que permitan obtener los
ficheros que se encuentren dentro del directorio de la aplicacin, es decir, en el
comprimido (.jar) del bundle.

Mdulo UPnP
Este mdulo asume toda la funcionalidad relacionada con la implementacin del protocolo
UPnP definida para un MediaRenderer.

60

3. Implementacin

Paquete
[Link]

Clases contenidas
HomeAVMediaRenderer
AVTransportService
ConnectionManagerService
RenderingControlService

Interfaces contenidas
MediaRendererListener

Paquetes contenidos

Tabla 3.3. Composicin del Mdulo UPnP

Clases
-

HomeAVMediaRenderer: es la clase principal del paquete [Link] y la que

extiende la clase Device de la librera Cyberlink. Se encarga de la instanciacin de los
servicios UPnP del dispositivo, AVTransportService, ConnectionManagerService
y RenderingControlService. Proporciona los mtodos necesarios para la creacin
del UPnP Device y el comienzo (start()) y parada (stop()) de la comunicacin UPnP.
En su constructor, inicializa el dispositivo utilizando el descriptor del mismo y
estableciendo los parmetros de configuracin UPnP iniciales como el puerto HTTP a
utilizar, la direccin IP a utilizar en la comunicacin y el FriendlyName 1 del dispositivo
con los dos ltimos octetos de esta IP (FriendlyName=HomeAV (IP:))
Uno de los pasos ms importantes que realiza esta clase es el de aadir la instancia de
AVTransportService a la lista de escuchadores de la clase MediaRenderer, lo que
permitir informar la servicio del estado en la reproduccin o visualizacin de imgenes y
modelar en consecuencia su estado.

MediaRendererListener (interfaz): es utilizada para definir escuchadores de los

eventos que genere la clase MediaRenderer del paquete [Link].

AVTransportService:
implementa
la
clase
AVTransport
del
paquete
[Link] de Cidero. Por tanto, se trata de la implementacin del servicio
AVTransport Service de UPnP. Esta clase proporciona el conjunto de todos los mtodos
asociados a las acciones de este servicio y que el Control Point invoca para el control del
flujo, la reproduccin o la visualizacin del contenido multimedia.
Como resultado de la invocacin de una accin, actualiza las variables de estado del
servicio relacionadas con dicha accin. Adems, implementa la interfaz
MediaRendererListener,
e
implementa
el
mtodo
que
define
sta,
mediaRendererEventReceived(), para poder enterarse de los eventos generados
por los cambios producidos en el tratamiento del contenido multimedia asociado y
actualizar en consecuencia las variables de estado que sean necesarias. A continuacin
se mustra el cdigo de este mtodo.

FriendlyName: parmetro UPnP que contiene el nombre del dispositivo con el que se va a
publicar en la red.

61

3. Implementacin

/**
* This method is called when an event is generated by the
* 'MediaRenderer' instance that this listener is registered
* with.
*/
@Override
public void mediaRendererEventReceived(String type) {
// TODO Auto-generated method stub
if([Link]("StartEvent")){
if(!getStateVariableValue("TransportState").equals(AVTransport.STATE_PLAY
ING))
updateStateVariable("TransportState", AVTransport.STATE_PLAYING );
}
else if([Link]("EndOfMediaEvent")){
if([Link]){
setNextPlayback();
}else{
[Link]("--- EndOfMediaEvent ---. No next
playback");
uri = null;
uriMetaData = null;
//Update the state variables
setURIRelatedStateVariables(INIT_URI,
INIT_URIMETADATA, INIT_TIME);
updateStateVariable("TransportState",
AVTransport.STATE_STOPPED );
}
}
else if([Link]("ControllerErrorEventFromPlayer")){
uri = null;
uriMetaData = null;
if(nextURI != null)
nextURI = null;
if(nextURIMetaData != null)
nextURIMetaData = null;
//Update the state variables
setURIRelatedStateVariables(INIT_URI, INIT_URIMETADATA,
INIT_TIME);
updateStateVariable("TransportState",
AVTransport.STATE_STOPPED );
}
else if([Link]("ControllerErrorEventFromPlayerNextURI")){
nextURI = null;
nextURIMetaData = null;
}
else if([Link]("SeekFailedEvent")){
uri = null;
uriMetaData = null;
if(nextURI != null)
nextURI = null;
if(nextURIMetaData != null)
nextURIMetaData = null;
//Update the state variables
setURIRelatedStateVariables(INIT_URI, INIT_URIMETADATA,
INIT_TIME);
updateStateVariable("TransportState",
AVTransport.STATE_STOPPED );
}

62

3. Implementacin

else if([Link]("ControllerErrorEventFromRTPPlayer")){
uri = null;
uriMetaData = null;
//Update the state variables
setURIRelatedStateVariables(INIT_URI, INIT_URIMETADATA,
INIT_TIME);
updateStateVariable("TransportState",
AVTransport.STATE_STOPPED );
}
else if([Link]("ByeEvent")){
[Link]("--- ByeEvent ---");
uri = null;
uriMetaData = null;
//Update the state variables
setURIRelatedStateVariables(INIT_URI, INIT_URIMETADATA,
INIT_TIME);
updateStateVariable("TransportState",
AVTransport.STATE_STOPPED );
}
else if([Link]("ImageClosedEvent")){
if([Link]){
setNextPlayback();
}else{
[Link]("--- ImageCloseEvent ---");
uri = null;
uriMetaData = null;
//Update the state variables
setURIRelatedStateVariables(INIT_URI,
INIT_URIMETADATA, "-");
updateStateVariable("TransportState",
AVTransport.STATE_STOPPED );
}
}
}

Cuadro de texto 3.1. Mtodo mediaRendererEventReceived() de AVTransportService

Las acciones relacionadas con la reproduccin que estn implementadas son las usuales
del AVTransport Service: Play(), Stop(), Pause(), Seek() y SetPlayMode() para
definir el modo de reproduccin (NORMAL, REPEAT_ONE o REPEAT_ALL). Tambin se
da soporte para la invocacin de la accin Seek(), para buscar un punto temporal en la
reproduccin de un fichero multimedia obtenido mediante HTTP. Las acciones Next() y
Previous() no producen ningn efecto en la reproduccin en HomeAV (en el captulo
Conclusiones se justificar el motivo). Los mtodos asociados a cada accin de este
tipo, invocan a los respectivos mtodos de la clase MediaRenderer del paquete
[Link] donde se procesa el contenido. Para esas invocaciones no es necesario
haber creado una instancia de la clase MediaRenderer ya que, como se dijo en la
descripcin del Mdulo raz, se utiliza la que se cre en HomeAVMain declarada como
esttica.
La accin SetAVTransportURI() es la primera en invocarse para el comienzo de una
nueva renderizacin. Establece la URI del recurso multimedia que va a ser renderizado, y
en la cual se indica el protocolo de transporte con el que se va a transferir el contenido.
Su invocacin va seguida de la invocacin de la accin Play(). HomeAV utiliza la
primera para la creacin del Player en el caso de flujos HTTP de audio y/o video, o
para la creacin de la sesin RTP en el caso de que se trate de una URL para un flujo
RTP. La segunda es utilizada para arrancar el Player, o para crear el display de una
imagen, o para iniciar la sesin RTP, segn proceda.
Cuando se present HomeAV en pginas anteriores, se indic que una de sus cualidades
es soportar la accin SetNextAVTransportURI() de este servicio. Esta accin es

63

3. Implementacin

invocada por el Control Point durante la renderizacin del contenido actual, precisamente
para que cuando este finalice pueda inmediatamente empezar la renderizacin del
siguiente. sta accin es realmente til para aquellos recursos que necesiten ser
almacenados en local previamente a su renderizacin, en este caso los que se obtienen a
travs de la red mediante HTTP. El mtodo de AVTransportService asociado a esta
accin invoca al mtodo de MediaRenderer, prepareNextPlayback(), encargado
de preparar la prxima reproduccin.
-

ConnectionManagerService: implementa a la clase ConnectionManager del

paquete [Link] de Cidero. Por tanto, se trata de la implementacin del
servicio ConnectionManager Service de UPnP. Implementa mtodos para las acciones
que el Control Point invoca para la obtencin de informacin sobre los protocolos y
formatos soportados por el UPnP MediaRenderer, y la informacin sobre los
identificadores de los servicios y de la conexin.
Una de las decisiones que se tom fue la de no implementar la lgica de las acciones del
servicio, PrepareForConnection() y ConnectionComplete() (en el captulo
Conclusiones se justificar el motivo). El resto de acciones del servicio s son
implementadas.

RenderingControlService: implementa a la clase RenderingControl del paquete

[Link] de Cidero. Por tanto, se trata de la implementacin del servicio
RenderingControl Service de UPnP. Implementa mtodos para las acciones que el
Control Point invoca para el manejo de algunas caractersticas de la renderizacin. En
concreto, las que son obligatorias y las asociadas al control del volumen y el mute. Al
igual que en la clase AVTransportService, estos mtodos asociados a cada accin de
este tipo, invocan a los respectivos mtodos de la clase MediaRenderer del paquete
[Link] para actuar sobre estas caractersticas del reproductor.

Mdulo multimedia
Este mdulo asume toda la funcionalidad relacionada con el tratamiento de contenido
multimedia para su reproduccin o visualizacin. Contiene los paquetes de especificacin
[Link], [Link] y [Link].
Paquete
[Link]

Clases contenidas
MediaRenderer
MediaRendererFrame
MediaClock
MediaRendererListenerList

Paquetes contenidos
[Link]
[Link]

[Link]

Interfaces cont.

HTTPRenderer
ImageFrame
[Link]
ImageRenderer
RTPReceiver
[Link]
[Link]
RTPSocketAdapter
[Link]
[Link]

Tabla 3.4. Composicin del Mdulo multimedia

Clases
-

MediaRenderer: es la clase principal del paquete [Link]. Controla la

renderizacin del contenido multimedia. Clasifica el contenido multimedia a renderizar a
fin de invocar los mtodos adecuados de los manejadores de la renderizacin especficos

64

3. Implementacin

de cada tipo (Audio/Video HTTP, Imagen, Flujo RTP). Para ello, crea las instancias de los
estos manejadores (HTTPRenderer, ImageRenderer y RTPReceiver). Con esto se
pretende que cuando un mtodo de la clase AVTransportService, relativo a una
accin, llame al mtodo de esta clase que la implementa sobre la renderizacin, ste
invoque al mtodo correspondiente de la subclase manejadora que procesa el tipo
concreto de contenido asociado. Sirva como ejemplo de ello el mtodo play() de esta
clase que se muestra a continuacin.
/**
* Start the playback.
* @return uriFor or FAILURE if no success
*/
public int play(){
if(uriFor == HTTP_AV_URI){
if(startAtSpecificTime){
if([Link]( startAtSpecificTime,
startTime))
[Link]("Starting player at specific
time");
startAtSpecificTime = false;
startTime = null;
}
if([Link]())
return uriFor;
else
return FAILURE;
}else if(uriFor == HTTP_IMAGE_URI){
if(startAtSpecificTime){
startAtSpecificTime = false;
startTime = null;
[Link]("Impossible to start at specific time.
The uri is for an image");
}
if([Link](uri, getTitleString()))
return uriFor;
else
return FAILURE;
}else{
if(startAtSpecificTime){
startAtSpecificTime = false;
startTime = null;
[Link]("Impossible to start at specific time a
RTP session");
}
if([Link]())
return uriFor;
else
return FAILURE;
}
}

Cuadro de texto 3.2. Mtodo play() de MediaRenderer

De acuerdo con la lgica descrita en la clase AVTransportService, este mtodo
play() se invoca en el mtodo actionPlay() de esa clase haciendo que el Player
que haba sido creado antes pase a estado Realize, o creando el display para visualizar
una imagen, o iniciando la sesin RTP, segn sea el tipo de contenido asociado que se
pretende renderizar.
Para dar soporte a la invocacin de la accin SetNextAVTrasnportURI(), como se
dijo, esta clase provee el mtodo prepareNextPlayback(). Este mtodo, conforme a
lo dicho anteriormente, identifica el tipo de contenido que se va a renderizar permitiendo

65

3. Implementacin

resolver con xito esta invocacin nicamente si se trata de audio o video obtenido
mediante HTTP.
Otra de las funcionalidades que asume esta clase es la de recoger los eventos generados
por las clases manejadoras. Para ello, provee tres mtodos, uno por cada tipo de
manejador, que son invocados por estos cuando se genera un evento en la
renderizacin, ya sea del Player en ejecucin, o respecto de la sesin RTP, o por el
cierre de la ventana de visualizacin de la imagen, en funcin del manejador que se est
utilizando
para
esa
renderizacin.
Estos
mtodos
son
httpRendererEventReceived(),
imageRendererEventReceived()
y
rtpReceiverEventReceived().
Posteriormente, notifica estos eventos a los escuchadores registrados de la clase, en
este caso AVTransportService, por medio de la invocacin del mtodo de estos
escuchadores notifyRendererEvent().
A partir de todo lo anterior, se puede decir, que MediaRenderer, hace las funciones de
filtro entre las instrucciones de la clase AVTransportService y las subclases
manejadoras de tipos concretos de contenidos. Y, a su vez, permite que todos los
posibles eventos generados por estas subclases puedan ser trasladados de forma
coherente a la misma clase, AVTransportService.
-

MediaRendererFrame: proporciona la interfaz grfica de HomeAV. Consiste

nicamente en una ventana que incluye dos etiquetas, una para aadir el ttulo del medio
y otra para aadir la referencia temporal de la reproduccin y la duracin. Adems, si el
contenido asociado tiene componente visual, ste se aadir tambin a la ventana
principal.

MediaClock: esta clase es utilizada para crear la referencia temporal de la reproduccin

obtenida del Player (si existe) que est en ejecucin. Y crea la cadena de texto con esta
referencia y la duracin que se aadir a la ventana principal.

MediaRendererListenerList: esta clase extiende de Vector y es usada por la clase

MediaRenderer para la crear una lista de los escuchadores de eventos generados por
ella.

Paquetes contenidos
1. [Link]: contiene el conjunto de mtodos y clases para la reproduccin de
audio y video obtenido de la red utilizando HTTP como protocolo de transporte.
Clases:
-

HTTPRenderer: provee el conjunto de mtodos necesarios para la creacin y control de

una instancia de la clase Player de la librera JMF para el contenido que es obtenido por
HTTP. Entre los controles disponibles estn aquellos que permiten la variacin del
volumen y el mute mediante la invocacin de mtodos. Implementa la interfaz
escuchadora ControllerListener para poder enterarse de los eventos producidos
por el Player durante su existencia y actuar en consecuencia. Esto incluye la invocacin
de uno de sus mtodos para la notificacin de estos eventos a la clase MediaRenderer
y que sta pueda as difundirlos, de ser necesario, a sus escuchadores de eventos
(AVTransportService).
El mtodo ms importante de esta clase es createPlayer(). Este mtodo es usado
para la creacin del Player, ya sea para preparar la reproduccin del contenido entrante
en respuesta a la invocacin de la accin SetAVTransportURI() o para preparar la del
prximo recurso en respuesta a la accin SetNextAVTransportURI(). En el primer
caso, simplemente se crea el Player que posteriormente se realizar (pasar al estado

66

3. Implementacin

Realice) cuando el Control Point invoque la accin Play() del servicio AVTransport
Service. En el segundo caso, se crea un Player en estado Realize, estando el actual
Player en ejecucin, con lo que el contenido del siguiente recurso ya se habr
descargado, y el nuevo Player arrancar cuando el actual llegue al final de la
reproduccin y se cierre.
/**
* Create a Player instance from a specific URL.
* @param uri
* @param isForNextPlayback 'true'->create a Player for next resource
* @return
'true' if success
*/
public boolean createPlayer(String uri, boolean isForNextPlayback){
DataSource ds = null;
Player localPlayer = null;
MediaLocator ml = new MediaLocator(uri);
if(ml != null){
try{
localPlayer = [Link](ml);
[Link](this);
if(isForNextPlayback){
playerForNextURI = localPlayer;
localPlayer = null;
[Link]();
return true;
}else{
player = localPlayer;
localPlayer = null;
return true;
}
}
catch (Exception e){
[Link]("An error occurs creating the player");
[Link]();
[Link]();
localPlayer = null;
return false;
}
}else{
[Link]("There is no player for this URI");
return false;
}
}

Cuadro de texto 3.3. Mtodo createPlayer() de la clase HTTPRenderer

La reproduccin para cuando se llega al final del medio o por la invocacin de la accin
Stop() del servicio, por parte del Control Point. Esta invocacin supone la llamada al
mtodo stop() de MediaRenderer que provoca, no slo lo dicho anteriormente sino
tambin la cancelacin y cierre del proceso que prepara la siguiente reproduccin.
2. [Link]: contiene el conjunto de mtodos y clases para la visualizacin
de imgenes.
Clases:
-

ImageRenderer: es la clase manejadora de imgenes. Contiene el conjunto de mtodos

necesarios para crear, actualizar y cerrar el display (ventana) donde se visualizar la
imagen. Como la clase anteriormente vista, incluye un mtodo para notificar un evento al
MediaRenderer. En este caso slo cuando la ventana de la imagen se cierre.

67

3. Implementacin

El display con la imagen se crea a partir de la invocacin de la accin Play(). Cuando

se llega al mtodo play() de la clase MediaRenderer, sta verifica que la URI
identifica una imagen, e invoca al mtodo createImageDisplay() que crea la ventana
de visualizacin. Este mtodo tambin es invocado durante una presentacin de
imgenes, en la que el Control Point (en el caso de Cidero) invoca la accin Play()
cada vez que se quiere cambiar la imagen por otra. En este caso, el mtodo no crea una
nueva ventana sino que elimina la etiqueta (JLabel) anterior y aade una nuevo donde
pinta la nueva imagen.
La ventana se cerrar en respuesta a la accin Stop() o si se pulsa el botn que por
defecto provee para ello el frame.
-

ImageFrame: clase que proporciona la ventana donde se visualiza la imagen. La imagen

se pinta en un componente JLabel que ser aadido a esta ventana junto con otra
etiqueta en la que se incluye el ttulo de la imagen.

[Link]: clase interna de ImageFrame. Proporciona el componente

JLabel donde se va a pintar la imagen. Su mtodo principal, paintComponent(), es el
encargado de pintar la imagen.

3. [Link]: contiene el conjunto de mtodos y clases para el manejo de una

sesin RTP y la reproduccin de los flujos de audio y video de sta.
Clases:
-

RTPReceiver: se trata de la clase que maneja la recepcin de flujos RTP. Fue creada en
base a la clase AVReceive3 que provee Sun Microsystems.
Implementa varias clases escuchadoras de eventos:
-

ReceiveStreamListener, para los eventos que genere el flujo RTP asociado a

la sesin. En HomeAV interesan nicamente los generados cuando llega un
nuevo flujo de un participante de la sesin, para crear un nuevo Player para
ste, y cuando finaliza, para cerrarlo y cerrar la sesin.

SessionListener, para los eventos asociados con el estado de la sesin. En

HomeAV interesa nicamente el evento generado cuando se incorpora un nuevo
participante a la sesin.

ControllerListener, para enterarse de los eventos relacionados con el/los

Player que reproducen los flujos RTP y actuar en consecuencia.

La creacin de una sesin RTP comienza con la invocacin de la accin

SetAVTransportURI(), lo que provoca que se invoque el mtodo
createPlayback() de MediaRenderer. ste hace la llamada al mtodo
createRTPSessionLabel() de esta clase. En l se crea una etiqueta con los
datos necesarios para abrir una sesin RTP, estos son: direccin IP, puerto y ttl. En
caso de que HomeAV est configurado para la apertura de dos sesiones, una para
audio y otra para video, se crear una segunda etiqueta con las mimos parmetros
anteriores excepto el puerto que consistir en dos nmeros ms que el valor para la
primera sesin.
Posteriormente, en respuesta a la accin Play(), se invoca el mtodo play() de
MediaRenderer. ste mtodo llama al mtodo initializeRTPSession() de esta
clase. En ste se crea un manejador RTP por cada sesin a abrir, RTPManager,
utilizando una instancia de la clase RTPSocketAdapter para crear la conexin y
utilizando los parmetros anteriormente descritos.

68

3. Implementacin

/** Initialize the RTP session.

* This method creates and initialize a 'RTPManager' instance for
* every 'SessionLabel' instance using a 'RTPSocketAdapter'instance.
public boolean initializeRTPSession() {
try {
mgrs = new RTPManager[[Link]];
instances = new Vector<Instance>();
// Open the RTP sessions
for (int i = 0; i < [Link]; i++) {
// Parse the session addresses.
[Link]("RTP session: Open RTP session for: addr:
" + sessions[i].addr + " port: " + sessions[i].port +
" ttl: " + sessions[i].ttl);
mgrs[i] = (RTPManager) [Link]();
mgrs[i].addSessionListener(this);
mgrs[i].addReceiveStreamListener(this);
// Initialize the RTPManager with the RTPSocketAdapter
mgrs[i].initialize(new
RTPSocketAdapter([Link](sessions[i].add
r), sessions[i].port, sessions[i].ttl));
BufferControl bc =
(BufferControl)mgrs[i].getControl("[Link]
.BufferControl");
if (bc != null)
[Link](350);
}
} catch (Exception e){
[Link]("RTP session: Cannot create the RTP Session:
" + [Link]());
return false;
}
isRTPReceiverAlive = true;
prefetchEventSent = false;
startEventSent = false;
controllerErrorEventSent = false;
remotePayloadEventSent = false;
return true;
}

Cuadro de texto 3.4. Mtodo initializeRTPSession() de RTPReceiver

Una vez que se configura la conexin la sesin ya esta abierta. Se ha de esperar a que
se reciba el evento de llegada de un flujo por medio del mtodo que define la clase
escuchadora correspondiente de las comentadas en lneas anteriores y entonces crear el
Player que lo manejar. Esto ocurrir por cada uno de los flujos de cada sesin abierta.
A partir de aqu, se podr actuar sobre la reproduccin invocando los controles usuales
comentados que proporciona cada Player, y escuchar sus eventos para actuar en
consecuencia.
La conexin, y por tanto la sesin se cerrar, como resultado de la invocacin del mtodo
Stop() o bien cuando se reciba un evento del flujo que as lo indique(ByeEvent).
RTPReceiver contiene dos clases internas:
-

SessionLabel: para crear instancias que definen la etiqueta con los parmetros
de la sesin y que ser utilizada para crear la sesin RTP.

Instance: esta clase es utilizada para manejar cada Player de la sesin.

Asocia cada Player con el flujo que reproduce. Una instancia de esta clase est
compuesta por un Player y su flujo correspondiente. Esto supone que se haya
que crear tantas instancias de ella como flujos a reproducir, en este caso dos (de
audio y de video).

69

3. Implementacin

RTPSocketAdapter: es la clase que define las conexiones de la sesin RTP. Fue

adaptada de la clase del mismo nombre que provee Sun Microsystems. nicamente se
modific la forma de obtener la IP local donde se abrirn los sockets. Implementa a la
interfaz RTPConnector que provee JMF, para crear conexiones basadas en sockets
UDP. Estos sockets sern utilizados por el RTPManager para enviar y recibir mensajes
de control RTCP, y recibir el flujo RTP.
Posee dos clases internas:
-

SockInputStream: define una fuente de flujo de entrada, el que se recibe.

Utilizada por el RTPManager tanto para RTP como para RTCP.

SockOutputStream: define una fuente de flujo de salida, el que se enva.

Utilizada en este caso por el RTPManager para RTCP.

3.3.4 Diagramas de secuencia

A fin de poder comprender mejor el funcionamiento de la aplicacin, se han creado los
siguientes diagramas UML de secuencia de los principales procesos de la misma. Se recomienda
consultar el ANEXO III: Diagramas UML donde se describe la simbologa utilizada.
Estos diagramas muestran de forma esquemtica la secuencia de invocacin de mtodos que
realiza el sistema para la implementacin de una funcionalidad. Se han incluido las clases de Cidero y
Cyberlink que se han considerado ms importantes para su comprensin.
Los principales procesos, por su importancia en el diseo de la aplicacin, son:
1.
2.
3.
4.
5.

Arranque de la aplicacin.
Recepcin de mensajes de solicitud HTTP.
Obtencin del documento descriptor.
Proceso de subscripcin a un servicio (Eventing).
Proceso de invocacin de una accin:
a. SetAVTransportURI(): reproduccin HTTP.
b. Play(): reproduccin HTTP.
c. SetAVTransportURI(): streaming RTP.
d. Play(): streaming RTP.
e. SetNextAVTransportURI().
6. Proceso de notificacin de eventos.

70

3. Implementacin

1. Arranque de la Aplicacin:

Figura 3.4. Diagrama de secuencia del arranque de la aplicacin

La secuencia comienza con la invocacin del mtodo start() de arranque de la aplicacin.
En este, como se ya se dijo con anterioridad, se crean las instancias de la clase que implementa el
dispositivo UPnP, HomeAVMediaRenderer, y la clase que implementa la funcionalidad de la
renderizacin, MediaRenderer. Estas clases a su vez crear y configurar las instancias de las
respectivas clases que las contiene a fin de estar disponibles para su cuando se requiera.
Continuando la ejecucin del mtodo start(), la siguiente instruccin es la invocacin al
mtodo del mismo nombre, start(), de HomeAVMediaRenderer. Como consecuencia, se
desencadena todo el proceso de inicializacin y anuncio del dispositivo. Este proceso implica la

71

3. Implementacin

creacin de la lista de servidores HTTP y sockets para la bsqueda SSDP, en este caso con un nico
elemento ya que HomeAV usa una sola interfaz de red para la comunicacin. Adems se crea el hilo
Advertiser encargado del envo de mensajes de anuncio peridicos a la red, tal y como define el
estndar UPnP.
Por tanto, cuando un Control Point recibe un mensaje de anuncio del dispositivo, ya puede
obtener la informacin de su descripcin a partir de la URL que se especifica en el mensaje SSDP
recibido. Si un dispositivo no es descubierto tras este mensaje de anuncio, normalmente porque el
Control Point haya arrancado posteriormente, recibir un mensaje SSDPSearch de ste y proceder
a enviarle una respuesta SSDP con la URL de su descriptor.
El servidor HTTP, por medio de un socket HTTP, ser el que reciba todos los mensajes de
solicitud que enve el Control Point utilizando este protocolo. Entre estos mensajes estn la solicitud
del descriptor del dispositivo, las solicitudes de subscripcin y las invocaciones de las acciones (Ms
informacin en ANEXO I: Cidero/Cyberlink).
2. Recepcin de mensajes de solicitud HTTP:

Figura 3.5. Diagrama de secuencia de recepcin de solicitud HTTP

Como se ha dicho, la recepcin de solicitudes es gestionada por el mismo hilo de ejecucin
del servidor HTTP. Esto supone que el proceso sea anlogo para cada uno de los tres casos
mencionados anteriormente.
Se recibe una solicitud en el socket HTTP. El servidor informa de ello a los escuchadores de
solicitudes http (HTTPRequestListener), en este caso la clase Device, que por herencia figura en
el diagrama como su clase derivada (HomeAVMediaRenderer). Esto provoca la invocacin del
mtodo httpRequestReceived(). En este mtodo se comprueba de que tipo de solicitud se trata:
para la obtencin de un descriptor o para la invocacin de una accin o un mensaje de
alta/cancelacin/renovacin de la subscripcin al servicio (Eventing).

72

3. Implementacin

3. Obtencin del documento descriptor:

Figura 3.6. Diagrama de secuencia de la obtencin del descriptor

Una vez que el dispositivo ya ha sido descubierto, el Control Point puede obtener el descriptor
del mismo a travs de la URL facilitada en el mensaje SSDP de descubrimiento.
Tras ser recibido el mensaje de solicitud y clasificado por su tipo, se invoca al mtodo
httpGetRequestReceived() de Device (por medio de su clase derivada de HomeAV,
HomeAVMediaRenderer). Este mtodo se encarga de obtener el contenido del descriptor para ser
enviado en un mensaje HTTPResponse de respuesta.

73

3. Implementacin

4. Subscripcin a un servicio:

Figura 3.7. Diagrama de secuencia de la subscripcin a un servicio

74

3. Implementacin

Tras la obtencin por parte del Control Point del descriptor del dispositivo y, a partir de las
URLs que figuran en este, los de los servicios, ya dispones de la informacin necesaria para solicitar
la subscripcin a un servicio para la recepcin de los eventos generados en este por cambios en su
modelo de estado.
Una vez que se comprueba que se trata de una solicitud relacionada con la subscripcin a un
servicio, se invoca al correspondiente mtodo, deviceEventSubscriptionReceived() de
Device (HomeAVMediaRenderer). En ste se comprueba el tipo de solicitud de subscripcin de
que se trata, esto es: para una nueva subscripcin, para cancelarla o para renovarla. El caso del
diagrama es para la primera opcin.
Al ser una nueva subscripcin, se invoca al correspondiente mtodo de Device tambin,
deviceEventNewSubscriptionReceived(). El algoritmo de este mtodo procesa la solicitud
configurando los parmetros necesarios conforme a la especificacin del protocolo GENA y que
sern incluidos en el mensaje de respuesta. Tras esto, este mensaje se enva al Control Point e
inmediatamente despus se le notifican las variables de estado del servicio con sus valores actuales.

75

3. Implementacin

5. Proceso de invocacin de una accin: Reproduccin HTTP:

Figura 3.8. Diagrama de secuencia de invocacin a una accin

76

3. Implementacin

En el diagrama anterior se muestra el proceso de invocacin de una accin, en este caso

SetAVTransportURI(). Desde que se comprueba que el mensaje de solicitud HTTP recibido es
del tipo SOAP, se ejecuta una serie de invocaciones de mtodos anidados de la clase Device, que
van clasificando el tipo de solicitud SOAP recibida (Query o Action) y comprobando que sta es
correcta. Cuando la ejecucin alcanza el mtodo deviceActionControlReceived(), ya se ha
verificado que se trata de una accin y se crea una instancia de Action a partir del nombre de la
accin solicitada y sus argumentos.
Esta instancia es usada para avisar a los escuchadores de acciones (ActionListener) de
la solicitud. Esto provoca la invocacin del mtodo actionControlReceived() de la clase
escuchadora, cualquiera que extienda de AbstractService,en este caso AVTransportService.
Este mtodo posee un algoritmo, que en este caso realiza una llamada al mtodo del servicio que la
extiende que tiene el mismo nombre que la accin.
Se proceder de forma anloga para cualquier otra accin del resto de servicios
implementados, RenderingControl Service y ConnectionManager Service.
-

SetAVTrasnportURI(): reproduccin HTTP.

Figura 3.9. Diagrama de secuencia de la accin SetAVTransportURI() (HTTP)

77

3. Implementacin

En este diagrama se muestra la implementacin en HomeAV de la accin

SetAVTransportURI() para el caso en el que se va a reproducir audio o video obtenido en remoto
mediante HTTP. En primer lugar se obtienen los argumentos de entrada de la accin, en este caso la
URI que localiza al contenido y un cadena de texto con informacin de meta-datos del mismo.
A partir de los meta-datos se obtiene la duracin y el ttulo fichero, que sern almacenan en
sendas variables de la clase MediaRenderer y que posteriormente sern recuperadas para ser
aadidos en la ventana de la aplicacin.
Con la URI como argumento de entrada se invoca al mtodo createPlayback() de
MediaRenderer para que se proceda con la creacin de la renderizacin. El algoritmo de ste
mtodo identifica el tipo de contenido asociado que se va a tratar a partir de la URI, es decir, si es
audio/video obtenido mediante HTTP, o es una imagen, o es una URI para la creacin de una sesin
RTP. En funcin de esto invoca el mtodo de las correspondientes subclases manejadoras para que
continen el proceso especfico requerido. Este diagrama trata sobre el primer caso, por lo que se
invoca al mtodo createPlayer() de la subclase HTTPRenderer, que simplemente crea el
Player asociado al contenido que se desea reproducir. Cuando acaba este proceso, se continua la
ejecucin del mtodo actionSetAVTransportURI() que actualiza las variables de estado
asociadas la URI y a los meta-datos.
-

Play(): reproduccin HTTP.

Figura 3.10. Diagrama de secuencia de la accin Play() (HTTP)

Como ya se ha explicado, seguidamente a la invocacin de SetAVTrasnportURI(), el
Control Point invoca la accin Play(). En su implementacin se llama al mtodo del mismo nombre
de la clase manejadora MediaRenderer. Como en el apartado anterior, aqu tambin se proceder
de forma distinta en funcin del tipo de contenido asociado, llamando al mtodo que corresponde de
su subclase manejadora. En este caso se invoca al mtodo realizePlayer() de HTTPRenderer.
Este mtodo inicia al Player creado anteriormente, permitiendo que vaya pasando por los distintos
estados hasta comenzar la reproduccin. Cuando vuelve la ejecucin al mtodo de la accin,
actionPlay(), se actualiza la variable de estado TransportState al valor TRANSITIONING,

78

3. Implementacin

indicando un estado intermedio hasta que comience la reproduccin. Cambiar a estado PLAYING
cuando se reciba el evento del Player que indique que ha alcanzado el estado Started y ya
comienza la reproduccin.
-

SetAVTransportURI(): streaming RTP.

Figura 3.11. Diagrama de secuencia de la accin SetAVTransportURI() (RTP)

De forma anloga al caso HTTP, se procede con la implementacin de la accin
SetAVTransportURI() para streaming RTP. A diferencia del anterior, en este caso se invoca al
mtodo createSession() de la correspondiente subclase manejadora, RTPReceiver. A partir de
la URI obtenida como argumento de la accin, se crea la sesin o sesiones RTP en funcin de si se
va a recibir audio y video, y si est configurado para ello el parmetro correspondiente del archivo de
configuracin. En este proceso simplemente se crean las etiquetas de la/s sesiones con lo datos de
cada una (IP, puerto y ttl).

79

3. Implementacin

Play(): streaming RTP.

Figura 3.12. Diagrama de secuencia de la accin Play() (RTP)

En la invocacin de la accin Play() tambin se procede de forma anloga al caso HTTP.
En el mtodo play() de MediaRenderer se invoca al mtodo initializeRTPSession() de la
correspondiente subclase manejadora, RTPReceiver. El algoritmo de este mtodo crea la/s
sesiones RTP a partir de la informacin de las etiquetas creadas en el anterior proceso, creando un
manejador de RTP para cada una.
Un manejador RTP es creado utilizando un objeto RTPSocketAdapter, con el que crear y
abrir las conexiones. Hecho esto, la ejecucin vuelve al mtodo actionPlay() donde, como en el
caso anterior, se actualiza la variable de estado TransportState al estado TRANSITIONING hasta
que, tras recibir el/los flujos RTP con el contenido, se creen los objetos Player asociados y enven
el correspondiente evento indicando que han alcanzado el estado Started. En este momento se
cambiar el estado de la renderizacin a PLAYING.

80

3. Implementacin

SetNextAVTransportURI():

Figura 3.13. Diagrama de secuencia de la accin SetNextAVTransportURI()

Como se ha dicho cuando se expusieron las caractersticas de HomeAV en este captulo, la
aplicacin est configurada para que un Player pueda realizar caching, es decir, el almacenamiento
local del contenido previo a su reproduccin. Esto est disponible y resulte til, cuando se va a
renderizar audio y video obtenido mediante el protocolo de transporte HTTP (ver apartado sobre
streaming y protocolo RTP en el captulo Marco terico).
La accin SetNextAVTransportURI() esta realmente indicada para este proceso, ya que
permite que mientras un Player est en ejecucin reproduciendo un medio, se cree otro que inicie
el proceso de descarga. Para el mayor nmero de casos de uso de la aplicacin (reproduccin de
audio MP3, secuencias de video,), se consigue que una vez finalizado la primera reproduccin est
ya disponible el segundo Player para iniciar la siguiente de inmediato.
El mtodo perpareNextPlayback() de MediaRenderer recibe la URI del siguiente
recurso
en
su
invocacin
en
el
mtodo
que
implementa
la
accin
actionSetNextAVTransportURI(). A partir de su URI determina si el procedimiento es aplicable
al contenido. Una vez confirmado que se trata de audio o video la que se accede mediante HTTP, se
procede a llamar al mtodo createPlayer() de la correspondiente subclase manejadora
HTTPRenderer. Se trata del mismo mtodo invocado en la implementacin de la accin
SetAVTransporURI(), pero en este caso el algoritmo no slo crea el Player, sino que lo inicia
hasta que alcance el estado de Realized en el que ya se ha completado la descarga del contenido.

81

3. Implementacin

6. Proceso de notificacin de eventos:

Figura 3.14. Diagrama de secuencia de la notificacin de eventos

El diagrama anterior corresponde a un ejemplo de uno de los procesos ms importantes de la
aplicacin. Se trata de la hacer llegar a la implementacin del servicio AVTransport Service una serie
de eventos, relacionados con la renderizacin, que le sirvan para modelar su estado, principalmente
actualizando alguna variable de estado. En este caso se informa al servicio de que el Player para
audio/video HTTP ha alcanzado el estado Started y comienza la reproduccin. En consecuencia, se
actualizar la variable de estado TransportState al valor PLAYING.
Primeramente, los eventos son escuchados en las respectivas subclases manejadoras
HTTPRenderer, ImageRenderer, o RTPReceiver que implementan distintas interfaces
escuchadoras de eventos como se dijo cuando se habl de la estructura de clases de HomeAV.
Posteriormente se invoca al mtodo de la clase MediaRenderer definido para los eventos de la
subclase en cuestin, en este caso httpRendererEventReceived(), cuyo algoritmo permite la
actualizacin de sus propias variables conforme a la nueva situacin, y llama el mtodo
notifyRendererEvent(), que notifica el evento a todos los escuchadores de eventos de la clase
por
medio
de
la
invocacin
del
correspondiente
mtodo
del
escuchador
mediaRendererEventReceived(). En realidad slo hay un escuchador, AVTransportService,
que utiliza este mtodo para actualizar las variables de estado del servicio, principalmente la variable
TransportState.
As pues, los eventos que recibe un escuchador de eventos de MediaRenderer son:
-

StartEvent proviene de un Player creado en la clase RTPReceiver o en la clase

HTTPRenderer, cuando ste alcanza el estado Started y comienza la reproduccin.

82

3. Implementacin

EndOfMediaEvent proviene del Player creado en la clase HTTPRenderer, cuando

alcanza el final del medio.

ByeEvent proviene de la clase RTPReceiver, cuando llega el evento del mismo

nombre generado por el flujo recibido cuando este finaliza.

ImageCloseEvent proviene de la clase ImageRenderer, y se genera cuando el

usuario cierra la ventana de visualizacin de la imagen

Eventos relacionados con errores producidos en la ejecucin de un Player:

-

Errores correspondientes a un Player creado en la clase HTTPRenderer:

ControllerErrorEventFromPlayer (problema en el Player usado en la
reproduccin
actual),
ControllerErrorEventFromPlayerNextURI
(problema en el Player creado para la siguiente reproduccin),
SeekFailedEvent (problema al establecer un punto concreto temporal en el
medio para reproducir desde ah)

Errores correspondientes a un Player creado en la clase RTPReceiver:

ControllerErrorEventFromRTPPlayer (problema en alguno de los dos
Player o el Player que est siendo usado para la reproduccin de un flujo
RTP).

3.3.5 Estados de la renderizacin

Una de las tareas ms importantes del desarrollo de HomeAV ha sido la definicin de las
transiciones a los distintos estados de la renderizacin. Esto se hace imprescindible ya que el Control
Point debe conocer en todo momento el estado en que se encuentra el dispositivo.
Como se dijo en el captulo Marco terico, el servicio AVTransport Serivce provee una
variable de estado, TransportState, para definir el estado en que se encuentre el transporte del
contenido multimedia. En HomeAV estos estados se interpretan como los estados de la
renderizacin.
Las modificaciones en esta variable vienen determinadas por la invocacin y ejecucin de
alguna de las acciones del servicio que controlan la renderizacin (SetAVTransportURI(),
Play(), Stop(),).
En el apartado anterior se comentaron alguna de estas modificaciones. A continuacin se
estudiar con ms detalle los distintos estados, y por tanto, valores de la variable en los que se puede
encontrar la renderizacin en HomeAV.
Considerando los tres tipos de contenidos que se pueden manejar (audio/video obtenido
mediante HTTP, imgenes, o flujo RTP), la invocacin de un mtodo modificar de una u otra forma
el valor de la variable de estado.
Estos valores son:

STOPPED Parado (Estado por defecto).

TRANSITINING En proceso de transicin entre estados. Este estado slo tiene

sentido cuando se est utilizando un Player, ya que ste ha de pasar por varios
estados antes de empezar la reproduccin (ver apartado sobre JMF del captulo
Marco Terico).

PLAYING Renderizando. Esto es, si existe un Player y est en estado Started

(reproduciendo). Si se trata de la visualizacin de una imagen, se considera que se
encuentra en este estado cuando se est mostrando la imagen.

83

3. Implementacin

PAUSED_PLAYBACK La renderizacin esta pausada como consecuencia de la

invocacin de la accin Pause().

Acorde a la especificacin UPnP para el servicio AVTrasnport Service y asumiendo ciertas

limitaciones que se mencionan en el captulo Conclusiones, se defini el siguiente diagrama de
estados:

Figura 3.15. Diagrama de estados de la renderizacin

Los caracteres escritos en color azul son variaciones introducidas en las causas que generan
las transiciones entre estados y son acordes al comportamiento de la aplicacin.
El estado por defecto en HomeAV es STOPPED. La variable TransportState toma este
valor desde el inicio y siempre que ocurra alguno de los siguientes casos:
-

Si se recibe un evento del tipo EndOfMediaEvent del Player (caso HTTP),

indicando que se ha alcanzado el final del fichero de audio/video, y siempre
que no est programada una prxima reproduccin.

Si se recibe un evento del tipo ByeEvent del flujo RTP indicando el fin de la
sesin.

Si se recibe un evento de cierre de la imagen (ImageClosedEvent).

Siempre que ocurra un error. Ya sea en la invocacin de las acciones

SetAVTransportURI() o Play(), o como resultado de la recepcin de un
evento provocado por un fallo en el Player que est en ejecucin.

Si se ha invocado la accin Stop() para parar la reproduccin.

84

3. Implementacin

Se pasa al estado TRANSITIONING en tres supuestos:

-

Se ha invocado la accin Play() para el comienzo de una nueva

reproduccin de contenido obtenido mediante HTTP. Esto es como
consecuencia del tiempo que tarda el Player desde su creacin hasta que
alcanza el estado Started.

Se ha invocado la accin Play() para la creacin de una sesin RTP, como

consecuencia del tiempo que transcurre desde la creacin de la sesin hasta
que es recibido el/los streams, y se crean los correspondientes Player.

Se ha invocado la accin Seek() mientras se est reproduciendo el medio.

Slo disponible para reproducciones de audio y video con HTTP como
protocolo de transporte. De esta forma se mantiene el estado en este valor
hasta que se alcanza el punto deseado en el archivo y se arranca de nuevo
la reproduccin.

Se alcanza el estado PLAYING cuando ocurre uno de los siguientes casos:

-

Se recibe un evento del Player advirtiendo que ya ha alcanzado el estado

Started y que por tanto se puede pasar del estado TRANSITIONING al
PLAYING. Esto es vlido tanto para el Player de la reproduccin basada en
HTTP, como los posibles Player asociados a los respectivos flujos RTP.

Se invoca la accin Play() para la visualizacin de una imagen. En este

caso no se pasa por el estado TRANSITIONING ya que no se ha de hacer
ningn proceso previo que consuma tiempo.

Se pasa al estado PAUSE_PLAYBACK como consecuencia de la invocacin de la accin

Pause(). Y consecuentemente, vuelve la estado PLAYING si se invoca la accin Play().

85

4. Pruebas

4. Pruebas
En este captulo se recogen las pruebas realizadas a la aplicacin con el objeto de valorar la
respuesta del sistema en un escenario real de ejecucin y presentar datos de su eficiencia.

4.1 Introduccin
Los objetivos que se persiguen con estas pruebas son:
-

Mostrar y valorar el tiempo de respuesta de la aplicacin (HomeAV) comprendido

entre su arranque y su descubrimiento en el Control Point.

Mostrar y valorar el tiempo de repuesta de la aplicacin (HomeAV) comprendido

entre la solicitud de reproduccin de un recurso multimedia y la confirmacin del
xito de la misma.

4.1.1 Escenario de pruebas

En la siguiente figura se muestra el escenario sobre el que se realizaron las pruebas de la
aplicacin.

Figura 4.1. Escenario de pruebas

Donde,
MR: UPnP MediaRenderer (consumidor de contenidos multimedia)
MS: UPnP MediaServer (servidor de contenido multimedia)
CP: UPnP AV Control Point (controlador de los dispositivos AV UPnP)

86

4. Pruebas

Caractersticas del escenario:

El escenario est compuesto por cuatro equipos (PCs) conectados a un router por medio de
cables Ethernet de 100Mbps. Cada uno de ellos, est configurado con una IP nica en la red UPnP
creada. Las caractersticas de los equipos son:
Equipo 1

RAM
512MB

Procesador
1.60GHz

Sistema Operativo
Windows XP HE

Equipo 2

RAM
256MB

Procesador
851MHz

Sistema Operativo
Windows XP Prof

Equipo 3

RAM
630MB

Procesador
800MHz

Sistema Operativo
Windows XP Prof

Equipo 4

RAM
256MB

Procesador
800MHz

Sistema Operativo
Ubuntu 8.04

Tabla 4.1. Caractersticas de los equipos utilizados

Un equipo puede contener uno o ms dispositivos UPnP, tal y como se muestra en la figura.
Las aplicaciones UPnP utilizadas que integran estos dispositivos son las que se presentaron
en el apartado de Herramientas del Sistema del anterior captulo.
La red UPnP resultante permite al Control Point (Cidero) listar el contenido de cada uno de los
MediaServer (Windows Media Player, CyberMediaGate) presentes y seleccionar el MediaRenderer
(HomeAV) donde reproducir los tems.

4.1.2 Condiciones de la toma de datos

A continuacin se enumeran las condiciones que se establecieron en la toma de datos de las
pruebas:

Se considerarn nulos los retardos de transmisin, ya que el propsito de estas pruebas no

incluye la valoracin ni del tipo ni del estado de la red.
El HomeAV utilizado para la toma de datos es el que se dispone en el equipo Windows
(Equipo 1).
La implementacin OSGi utilizada es Equinox de Eclipse 3.3.2.
Aunque se realizaron varias pruebas con IPv6, en las que aqu se analizan se utiliz un
escenario IPv4.
Los resultados obtenidos de dichas pruebas tendrn un carcter orientativo, ya que en todos
los procesos intervienen mltiples factores asociados a las capacidades de computacin de
los equipos que intervienen.

4.2 Caso 1: Fase de Descubrimiento

Se trata de una simple prueba con la que se pretende mostrar la sencillez y rapidez con la
que el dispositivo HomeAV se agrega a la red UPnP.
El dato evaluado es el tiempo transcurrido entre la invocacin del comando start del
Framework OSGi y la recepcin de la solicitud por parte del Control Point del documento descriptor
de HomeAV.
Procedimiento:
Lo primero es instalar el bundle HomeAV-bundle-1.0.0_win.jar en la implementacin de la
plataforma que se utiliza (Equinox).

87

4. Pruebas

Una vez instalado y obtenido el identificador que le asigna el Framework se puede proceder al
arranque del bundle por medio del comando start, lo que provocar el inicio del proceso de
descubrimiento del dispositivo y la visualizacin de su interfaz grfica.
Al final del proceso de descubrimiento, Cidero visualizar un icono con el FriendlyName de
HomeAV en el rea de su interfaz grfica en la que se muestran los MediaRenderers.

Figura 4.2. Captura de la consola y la interfaz grfica de HomeAV en la instalacin y arranque del
bundle (Equipo 1)

Figura 4.3. Captura de la Interfaz Grfica de Cidero (Descubrimiento de HomeAV)

88

4. Pruebas

Resultados:
El valor promedio obtenido es: 1,610 segundos
Es decir, con tan solo invocar un comando (start), y en poco ms de un segundo y medio,
el dispositivo HomeAV se configura y pasa a formar parte de la red UPnP de forma automtica y
transparente para el usuario. A partir de este momento, la aplicacin puede ser utilizada por ste a
travs de la interfaz grfica del Control Point.

4.3 Caso 2: Reproduccin de ficheros de audio y video

En esta prueba se analizarn los valores obtenidos del tiempo que transcurre entre la
pulsacin del botn Play del panel que provee Cidero para el control de HomeAV, y la confirmacin
de que la reproduccin ha comenzado, esto es, la recepcin en Cidero del evento generado por el
cambio de valor de la ya estudiada variable TransportState a PLAYING.

Figura 4.4. Captura de la interfaz grfica de Cidero y el panel que provee para el UPnP
MediaRenderer

89

4. Pruebas

1. Contenido obtenido por medio del protocolo HTTP:

Para esta prueba se utilizaron los siguientes tipos de fichero de audio y video:

Tipo

Extensin

Tamao
(kB)

Duracin
(seg)

Tasa de bits
media (kbps)

.mpg

5783

86

538

Audio: MPEG-1
Video: MPEG-1

Audio: MPEG-1 Layer 3 (MP3)

Video: DIVX

.avi

8212

79

832

Audio: MPEG-1 Layer 3 (MP3)

Video: DIVX

.avi

42938

1246

276

4 Audio: MPEG-1 Layer 3 (MP3)

.mp3

5623

240

128

5 Audio: WAV

.wav

27.619

160

1411

Tabla 4.2. Caractersticas de los ficheros de audio y video utilizados

Resultados:
A continuacin se muestra una tabla con los valores obtenidos. Como se puede comprobar se
ha realizado dos casos de estudio: con caching habilitado y con caching deshabilitado.
Fichero

Tiempo de respuesta (seg)

(caching habilitado)

Tiempo de respuesta (seg)

(caching deshabilitado)

1,933

1,272

4,416

2,113

16,694

4,786

1,071

0,941

0,922

0,792

Tabla 4.3. Tiempos de respuesta para la reproduccin (HTTP)

Era previsible que los datos que se obtuviesen cuando el caching estuviese deshabilitado
fueran a ser menores que en el caso de estar habilitado.
Teniendo habilitada la opcin de caching, la diferencia se acenta cuanto mayor sea el
tamao del fichero a almacenar. A esto hay que sumar la diferencia de tratamiento de los datos en
funcin del codec utilizado. Los codecs implementados por la librera JMF permiten el inicio de la
reproduccin antes de la descarga completa del fichero, como ocurre con los formatos MPEG y WAV.
Sin embargo, en los formatos manejados por codecs del plug-in de Fobs, como DIVX, se ha de
descargar el fichero completo previamente.
En el caso de deshabilitar el proceso de caching, las variaciones entre los valores obtenidos
estn directamente relacionadas con la tasa media de bits del fichero y la calidad que proporciona el
formato de codificacin. As es como, por ejemplo, se pude explicar que con el fichero 2 se obtenga
un valor inferior al 3 utilizando el mismo codec. En el primer caso se tiene una tasa de bits
considerablemente superior haciendo que en poco tiempo el buffer del codec posea la cantidad

90

4. Pruebas

suficiente de datos para iniciar la decodificacin. Un ejemplo del segundo racionamiento sera la
diferencia entre los dos primeros. MPEG-1 es un formato de menor calidad que DIVX (basado en
MPEG-4) por lo que su decodificacin resulta menos costosa. A esto hay que aadir el factor de la
eficiencia del plug-in que implementa el codec, con la consecuente influencia en el resultado.
En cuanto a los ficheros de audio, su marcada diferencia con los que contienen video es
como consecuencia de las caractersticas propias de la codificacin de audio, cuyo proceso est
basado en algoritmos ms simples. Entre los dos formatos analizados la diferencia entre ambos es
debida principalmente a que en el formato WAV, al contrario que en el MP3, los datos no han sido
comprimidos, por lo que en su decodificacin no se ha de realizar un proceso de descompresin de
los mismos.
Resumiendo, los valores de los tiempos de respuesta de la aplicacin relativos al comienzo
de la reproduccin son dependientes de las caractersticas del fichero (tasa de bists, codec,...) para
las dos configuraciones estudiadas, con caching habilitado y con caching deshabilitado. La
desventaja clara de la primera sobre la segunda se suple con un uso ms eficiente de la red y una
mejor reproduccin. En otras palabras, la reproduccin del medio no se ver afectada como
consecuencia de los posibles problemas derivados del uso de HTTP como protocolo streaming (caso
de caching deshabilitado), principalmente asociados a la ocupacin de la red.
2. Contenido enviado mediante flujos RTP:
Como ya se dijo en el apartado Herramientas utilizadas del captulo anterior, no se encontr
ninguna implementacin de un UPnP MediaServer que proporcionase URLs para flujos RTP, por lo
que se decidi adaptar el cdigo de HomeAV para la prueba y as poder utilizar un Servidor RTP de
los disponibles en el mercado. En concreto, para esta prueba se hizo uso de la aplicacin JMStudio,
distribuida junto con la librera JMF.
La adaptacin del cdigo de la aplicacin consisti simplemente en no utilizar la URI que se
recibe como argumento de entrada de la accin SetAVTransportURI() de la implementacin del
servicio AVTransport Service, y utilizar una definida especficamente para representar una sesin
RTP. sta es del tipo que se defini en el apartado sobre la especificacin de JMF para RTP del
captulo Marco terico (Ejemplo: rtp://[Link]:1238/video/1).
Se utiliz el mismo fichero de video MPEG anterior (1), el cual fue transcodificado por la
propia aplicacin JMStudio al formato definido en cada muestra.
Estos formatos son comnmente utilizados en aplicaciones que envan y/o reciben flujos RTP,
como aplicaciones de videoconferencia. Como ya se dijo en el marco terico, RTP est diseado para
obtener un mejor comportamiento en la transmisin de flujos multimedia bajo condiciones de
ocupacin de red en las que HTTP no resulta efectivo por sus caractersticas.
Los valores se medirn habiendo comenzado la transmisin de los flujos previamente a la
pulsacin del botn Play de Cidero, para no considerar los retardos introducidos por el servidor en el
inicio de su envo.
Resultados:
Los datos obtenidos se resumen en la siguiente tabla, en la que se especifica tambin el
formato RTP del contenido transmitido.
Formato RTP

Tiempo de respuesta (seg)

Video: MPEG (320x176 pxeles)

Audio: MPEG (44100 Hz)

1,592

Video: JPEG (320x176 pxeles)

Audio: MPEG (44100 Hz)

1,242

91

4. Pruebas

Video: H263 (320x176 pxeles)

Audio: G.723 (8000 Hz)

1,272

Audio: GSM (8000 Hz)

1,061

Audio: MPEG (44100 Hz)

1,098

Audio: G.723 (8000 Hz)

1,052

Audio: DVI (8000 Hz)

1,082

Tabla 4.4. Tiempos de respuesta para la reproduccin (RTP)

Observando la tabla se comprueba que los resultados obtenidos no difieren en exceso unos
de otros. S hay una marcada diferencia entre los valores relativos a un flujo nico de audio y los
relativos a dos flujos, uno de video y otro de audio, que como se dijo en el anlisis anterior, es
consecuencia de la mayor complejidad del proceso de decodificacin del video que retrasa el inicio de
la reproduccin.
En el caso de los flujos de video, la diferencia obtenida al usar MPEG es consecuencia de un
proceso ms complejo de decodificacin que en el caso de JPEG. H263, a pesar de que su
implementacin est basada en un algoritmo an ms complejo, consigue un valor bajo ya que fue
especficamente diseado para RTP, permitiendo que se inicie antes la reproduccin.
El resto de valores son tan prximos que no se puede establecer una relacin directa entre
estos y los formatos o procedimientos de decodificacin utilizados.
En conclusin, la aplicacin en poco ms de un segundo desde la pulsacin del Play en el
Control Point puede iniciar la reproduccin de un flujo de audio y/o video RTP.

92

5. Conclusiones

5. Conclusiones
En este captulo se recogen las conclusiones obtenidas de la realizacin de este proyecto.
En primer lugar se detalla el grado de cumplimiento de los objetivos planteados. Tras esto, se
exponen las limitaciones que surgieron en el desarrollo del prototipo y, por ltimo, se enuncian las
posibles lneas futuras de trabajo para este tipo de dispositivos.

5.1 Conclusiones
Como objetivo general de este proyecto se marc el desarrollo de un prototipo UPnP
MediaRenderer que se integrase en plataformas OSGi.
En el apartado sobre el estado de arte del captulo Marco terico, se analizaron las actuales
soluciones UPnP MediaRenderer. A partir del contenido de este anlisis se concluye que no existe
una solucin que reuna todas las capacidades que se definieron como requisitos para el prototipo
desarrollado.
El resultado es una aplicacin Java para plataformas Windows y Linux, que permite la
renderizacin de contenido multimedia (audio, video e imgenes), completamente conforme al
estndar UPnP para este tipo de dispositivos. Gracias a esto, puede ser controlada remotamente por
medio de acciones, entre las que se incluyen las ms comunes de un reproductor. Adems, es
compatible con IPv6, y se integra en un bundle OSGi para su utilizacin en plataformas de servicios
basadas en esta tecnologa.
Por medio del uso de Java Media Framework (JMF), se consiguieron las capacidades para la
reproduccin de contenidos multimedia obtenidos a partir de flujos HTTP o RTP, con los formatos
ms comunes. A s mismo, gracias a los paquetes Java AWT y Swing, se pudo dar soporte a la
visualizacin de imgenes, tambin en este caso, con los formatos ms comunes.
A continuacin se analiza el cumplimiento de los subobjetivos especficos del proyecto,
expuestos en la introduccin del mismo:
1. Estudio de las tecnologas implicadas para el diseo del prototipo: se comenz con la
tecnologa UPnP para la implementacin de un protocolo de comunicacin entre
dispositivos, poniendo un mayor nfasis en aquellos aspectos ms directamente
relacionados con los dispositivos UPnP MediaRenderers. Tambin se presentaron los
conceptos ms interesantes de JMF como librera Java para el desarrollo de aplicaciones
multimedia, para posteriormente dar una visin general de la Especificacin OSGi que
define las bases para integrar una aplicacin en plataformas de servicios avanzados
como las Pasarelas de Servicios. Por ltimo, se analiz el estado del arte, no slo del
UPnP MediaRenderer, sino tambin por su inters, de la librera JMF presentando
posibles alternativas que resuelvan sus limitaciones.
2. Anlisis de los requisitos del sistema en base a las caractersticas deseadas del prototipo:
en este sentido se definieron los requerimientos de la aplicacin y a partir de estos se
obtuvo el diagrama de Casos de Uso del sistema. Finalmente, se enumeraron las
herramientas que han sido utilizadas en todo el proceso tanto de desarrollo como de
pruebas del prototipo.
3. Construccin de un prototipo de UPnP MediaRenderer: tras haber adquirido los
conocimientos tericos necesario y analizar los requisitos, se paso al desarrollo del
prototipo de dispositivo UPnP MediaRenderer. Se comenz definiendo los diferentes
mdulos en los que se dividira para posteriormente presentar las clases Java
implementadas contenidas en el paquete que conforma cada mdulo. Y para finalizar se
incluy un anlisis de los diagramas de Secuencia ms importantes del funcionamiento
de la aplicacin.

93

5. Conclusiones

4. Comprobacin del correcto funcionamiento del prototipo en un escenario real y definicin

de las limitaciones derivadas de su diseo: se realizaron varias pruebas en escenarios
reales comprobando principalmente la correcta comunicacin del dispositivo con el
Control Point y el correcto procesamiento de la renderizacin. Se tomaron varias medidas
de tiempos de respuesta de la aplicacin para su valoracin en esta memoria y as poder
mostrar la eficiencia de la misma.
A nivel personal, opt por la realizacin de este proyecto por estar enfocado principalmente al
entretenimiento digital en el hogar. Las tecnologas aplicadas a este tipo de ocio evolucionan a un
ritmo vertiginoso y era la oportunidad de introducirme en el desarrollo de aplicaciones basadas en
ellas. En este caso ha sido UPnP. Es fascinante la facilidad con la que un usuario puede disponer de
una red de contenidos multimedia compartidos en la que se puede contralar su reproduccin en
dispositivos remotos desde un nico dispositivo controlador.
A parte de esto, la implementacin de la aplicacin me ha servido para descubrir y aprender
el manejo de herramientas realmente tiles para su desarrollo como es el caso de Eclipse, y adquirir
nuevos conocimientos informticos relacionados con la programacin.

5.2 Limitaciones
Durante el desarrollo del proyecto se tuvieron que tomar decisiones y trabajar sobre
problemas concretos surgidos de la integracin de las distintas tecnologas en la aplicacin. En
consecuencia, se tuvieron que asumir ciertas limitaciones, que a continuacin se enuncian:
-

Publicacin por una nica interfaz: aunque la mquina sobre la que se ejecuta la aplicacin
tenga ms de una interfaz activada, sta se anunciar nicamente por una interfaz de red.
Como se dijo, la IP que se utilizar para la comunicacin se establece en el arranque del
dispositivo, obtenida de la interfaz identificada por el parmetro interfaceNumber del
archivo de configuracin (Ms informacin en ANEXO IV: Ficheros de la Aplicacin).

No soporte para listas de reproduccin: la aplicacin fue diseada para la reproduccin de

tems que conformasen un nico fichero de audio, video o imagen, no permitiendo el manejo
de listas de reproduccin. En este sentido, las acciones del servicio AVTransport Service:
Next() y Previous() se han implementado sin funcionalidad, y la accin Seek() se limita
a la bsqueda de un punto temporal en un fichero, ya que su funcionalidad en la perspectiva
de un UPnP MediaRenderer que no reproduce listas no resulta interesante.

Manejo de un nico tem al mismo tiempo: el prototipo obtenido no implementa las acciones
opcionales PrepareForConnection() ni ConnectionComplete() del correspondiente
servicio ConnectionManager Service, no pudiendo mantener ms de una conexin
simultneamente que le permitiese manejar varios tems al mismo tiempo.

Libreras Nativas (Linux): en el caso de plataformas Linux las libreras nativas de JMF no
pueden ser empaquetadas en el .jar del bundle, ya que, al contrario que en Windows, no
pueden ser accedidas en tiempo de ejecucin en esa localizacin. En este caso, se hace
necesario copiar el directorio con estas libreras en una ruta que posteriormente pueda ser
aadida a travs de la exportacin de la variable del sistema LD_LIBRARY_PATH (Ms
informacin en ANEXO V: Instrucciones de instalacin).

Consumo de CPU: bien es sabido que las aplicaciones multimedia consumen gran cantidad
de recursos de procesamiento. En el caso de aplicaciones programadas en Java, como en
este caso, los requerimientos de estos recursos son mayores, principalmente como
consecuencia del uso de la Mquina Virtual Java. Estos requerimientos hacen inviable
trasladar la aplicacin a dispositivos limitados como dispositivos mviles, al no poseer JVM,
sino CVM o KVM las cuales no dan soporte a aplicaciones J2SE.

94

5. Conclusiones

5.3 Lneas futuras de trabajo

En cuanto a las posibles mejoras que se podran realizar sobre el prototipo, stas estaran
principalmente encaminadas a la resolucin de algunas de las limitaciones expuestas anteriormente,
aunque tambin se podran aadir ms. Ejemplo de estas futuras lneas de trabajo seran:
1. Permitir que el dispositivo se anunciase por todas las interfaces de red habilitadas de la
mquina en la que se ejecute. De esta forma podra se descubierto por cualquier Control
Point conectado a cualquiera de las subredes a las que tiene acceso. Posiblemente, esta
capacidad implicara tambin la utilizacin de Control Point capaces de discernir si la URL del
documento de descripcin del dispositivo que recibe en los paquetes SSDP multicast, es
alcanzable o no en base a la IP que contiene.
2. Permitir establecer mltiples conexiones para la reproduccin de varios tems al mismo
tiempo.
Esto
implicara
la
implementacin
de
los
mencionados
mtodo
PrepareForConnection() y ConnectionComplete() del servicio ConnectionManager
Service, adems de crear la lgica necesaria en las respectivas clases que implementan los
servicios AVTransport Service y RenderingControl Service para poder manejar varias
instancias de los mismos.
3. Aadir funcionalidad para el manejo de listas de reproduccin. En este caso, las acciones
Next() y Previous() si que seran tiles, y la accin Seek() podra asumir mayores
capacidades, como saltar varias pistas adelante o detrs dentro de la lista de reproduccin.
4. Aadir funcionalidad para streaming RTSP (Real Time Streaming Protocol) conforme a la
especificacin de la arquitectura UPnP para audio y video.
5. Aadir o crear nuevos plug-ins de codecs que puedan ser utilizados por la aplicacin para la
reproduccin de nuevos formatos.
6. Estudiar nuevas alternativas a JMF que resuelvan las limitaciones derivadas de sta librera,
principalmente en cuestin de consumo de recursos del sistema, soporte de formatos de
codificacin o restricciones en su desarrollo por no estar sujeta licencias de cdigo abierto.
Esto podra implicar el uso de tcnicas para el procesado multimedia programadas en otro
lenguaje.
7. Importar el prototipo de UPnP MediaRenderer a dispositivos limitados como PDAs,
SmartPhones, PocketPCs, etc. Para ello se podra hacer uso de plataformas como J2ME,
para el desarrollo de aplicaciones Java en este tipo de dispositivos.
8. Incorporar polticas de seguridad mediante la implementacin de nuevos servicios UPnP
como el definido por el Foro UPnP DeviceSecurity Service [UPNPSECURITY].
9. Incorporar polticas de calidad de servicio mediante la implementacin de servicios UPnP.
Para ello, el Foro UPnP especifica una arquitectura para le gestin de calidad de servicio
[UPNPQOS].

95

ANEXO I: Cidero/Cyberlink

ANEXO I: Cidero/Cyberlink
El contenido de este anexo sirve de gua para la implementacin de un dispositivo UPnP
MediaRenderer mediante la utilizacin de la librera de clases Java de la aplicacin Cidero.

1. Introduccin
Cidero es una implementacin de cdigo abierto, del ao 2004, basada en la librera
Cyberlink, que integra varias aplicaciones conformes a UPnP tales como un AV Control Point, un
UPnP MediaServer para acceder a estaciones de radio en Internet, y un UPnP Bridge para poder
utilizar dispositivos No-UPnP, principalmente reproductores multimedia, dentro de la red UPnP.
Su cdigo fuente contiene mtodos y clases que hacen, ayudndose de Cyberlink, ms
sencilla la implementacin de los servicios UPnP asociados a un MediaRenderer o un MediaServer
que crearlos a partir de la propia librera Cyberlink.
Por tanto, en este proyecto se ha utilizado Cidero para mltiples usos:

Como aplicacin AV Control Point en el escenario de trabajo y pruebas.

La librera Cyberlink que contiene para el desarrollo del dispositivo UPnP.

Mtodos y clases de sus propios paquetes para la implementacin de los

servicios asociados al UPnP MediaRenderer.

2. Implementacin del dispositivo con Cyberlink

Se trata de un catlogo de mtodos, clases e interfaces para la creacin de dispositivos y
Puntos de Control UPnP. Soporta todos los protocolos y mecanismos que define la especificacin.
Forma parte del dominio personal Cybergarage creado por Satoshi Konno en el ao 2002, aunque
desde entonces el cdigo ha sido corregido y actualizado en varias ocasiones. La versin utilizada en
este proyecto es la que se distribuye con Cidero, la 1.3.2.
Apoyado en la compatibilidad de Java, soporta IPv4 e IPv6 por defecto. Para poder
seleccionar alguna de las versiones del protocolo IP a utilizar por defecto se ha de invocar al siguiente
mtodo:
[Link](UPnP.USE_ONLY_IPV6_ADDR), para IPv6
o
[Link](UPnP.USE_ONLY_IPV4_ADDR), para IPv4
En el caso de IPv6 se hace necesario definir el alcance de la red donde se va a agregar el
dispositivo o Punto de Control, ya que el direccionamiento multicast depende de ello. Esto afecta
directamente a la direccin IPv6 multicast a utilizar en SSDP. Por defecto el alcance que define
Cyberlink es local. Para modificarlo se usa el siguiente mtodo:
[Link](UPnP.USE_IPV6_SITE_LOCAL_SCOPE)
(Site Local: alcance para una red domstica)
A continuacin se comentarn aquellos aspectos de la lgica de la librera que resultan
interesantes con este proyecto y que estn orientados a crear un dispositivo UPnP.
Paquetes de la librera

[Link]: para la creacin y configuracin de los servidores HTTP

necesarios en la comunicacin, as como los mensajes tipo de solicitud y respuesta
HTTP, y toda la funcionalidad asociada a este protocolo.

96

ANEXO I: Cidero/Cyberlink

[Link]: para la configuracin de los parmetros de red.

[Link]: para la implementacin del protocolo SOAP para la

invocacin remota de acciones.

[Link] (ssdp, control, eventos, dispositivos y servicios): cubre toda la

lgica para la creacin de puntos de control, dispositivos y servicios, adems de la
implementacin de los mecanismos de descubrimiento (SSDP), de control (SOAP) y
eventos (GENA) que especifica UPnP.

[Link]: contiene un conjunto de clases e interfaces que son

utilizadas como herramientas para la implementacin del cdigo del resto de paquetes.

[Link]: para dar soporte al tratamiento, anlisis y generacin de

documentos en formato XML que se utilizan para la creacin de mensajes en varios de
los protocolos UPnP, as como los descriptores de dispositivos y servicios.

Descripcin de la funcionalidad
Descripcin del dispositivo y servicios contenidos
El paso previo a la implementacin del dispositivo es la creacin de los documentos XML
descriptores tanto del dispositivo como de los servicios que contiene. Estos ficheros sern
cargados al inicio de la comunicacin para estar disponibles en la peticin de los mismos por
parte del Punto de Control durante el proceso de descubrimiento.
El campo URLBase del descriptor del dispositivo no debe figurar en este ya que es generado
automticamente cuando se recibe la peticin del Punto de Control para obtener este documento.
Inicio y abandono
Para el inicio de la comunicacin, la clase Device define el mtodo start(). La invocacin
de este mtodo desencadena la creacin de un servidor HTTP por interfaz, para poder recibir los
mensajes de los distintos protocolos UPnP (SOAP, GENA y HTTP GET para la obtencin de los
descriptores) y dos sockets, uno unicast y otro multicast, para el protocolo SSDP. Esto supone
que desde este momento coexisten varios hilos de ejecucin para el envo de peticiones, la
recepcin de los mensajes y la generacin de las correspondientes respuestas conforme a lo
especificado para cada protocolo mencionado.

Figura I.1. Servidores HTTP del dispositivo

Este proceso conlleva la carga de los descriptores del dispositivo y servicios para estar
disponibles para su obtencin por el Punto de Control.

97

ANEXO I: Cidero/Cyberlink

Los parmetros mostrados por la siguiente tabla son configurables por medio de mtodos de
Device:
Parmetro
HTTP port

Valor por defecto

4004

Mtodo
setHTTPPort()

Description
URI

/[Link]

setDescriptionURI()

Lease time

1800

setLeaseTime()

Descripcin
Puerto para abrir la conexin
del servidor HTTP
URI, localizador, donde se
encuentra el descriptor del
dispositivo
Tiempo en segundos durante
el cual un anuncio SSDP es
vlido. Pasado ste y si no se
ha recibido otro mensaje, el
Punto de Control entiende
que el dispositivo no est
disponible

Tabla I.1. Parmetros configurables de la clase Device

Cada vez que se recibe una solicitud HTTP enviada por el Punto de Control, se clasifica
segn sea una solicitud HTTP GET para la obtencin del descriptor, una solicitud SOAP para la
invocacin de una accin de un servicio o una solicitud de Subscripcin al mecanismo de eventos
(GENA) de algn servicio. Esto se realiza en el mtodo httpRequestReceived() de Device.
Notificacin
Tras esto, el mtodo contina su ejecucin realizando el proceso de anuncio enviando
mensajes ALIVE, siguiendo las pautas que dicta el protocolo SSDP. Se anuncia tanto para el
dispositivo, como los dispositivos embebidos y servicios que contiene.
Para el abandono de la red UPnP, se ha de invocar al mtodo stop() de la misma clase. Su
invocacin provoca el envo de la correspondiente notificacin al Punto de Control con un
mensaje BYEBYE acorde al protocolo SSDP. Igualmente que el anuncio, se notifica para el
dispositivo as como para los dispositivos embebidos y servicios que contiene.
Dispositivos embebidos
Como ya se mencion en el apartado del captulo Marco Terico que haca referencia a
UPnP, un dispositivo poda contener otros dispositivos embebidos. Para obtener la lista de
dispositivos embebidos la clase Device proporciona el mtodo getDeviceList(). Se puede
buscar un dispositivo embebido por nombre o por UDN (Unique Device Name), usando el mtodo
getDevice() de la misma clase.
Servicio
Para obtener una lista de los servicios contenidos por el dispositivo se utiliza el mtodo
getServiceList() de la clase Device. De cada servicio se puede obtener la lista de variables
de estado y acciones asociadas. Se usa el mtodo getServiceStateTable() para el primer
caso, y getActionList() para el segundo. Ambos mtodos definidos en la clase Device.
Se puede buscar un servicio por medio de su identificador, invocando el mtodo
getService(). Y se puede buscar una accin o una variable de estado de un servicio por su
nombre invocando getAction() y getStateVariable() respectivamente. Todos estos
mtodos se encuentran en la clase Device.
Control
Para enterarse de cundo se ha recibido una solicitud de invocacin de una accin, se ha de
implementar la interfaz ActionListener. Este escuchador debe implementar el mtodo

98

ANEXO I: Cidero/Cyberlink

actionControlReceived() de esta interfaz. Este mtodo contiene la accin que se desea

invocar y un parmetro con la lista de argumentos de entrada. Estos argumentos tienen los
valores que el Punto de Control establece.
En respuesta, se establecen los argumentos de salida de la accin y se devuelve true
cuanto la peticin resulta exitosa. Sin embargo, si no resulta as, se devuelve el valor false lo que
provoca que se devuelva una respuesta UPnPError al Punto de Control. Esta respuesta
automtica consta del mensaje INVALID_ACTION que define SOAP. Adems, se utiliza el
mtodo setStatus() de la clase StateVariable para devolver otros errores UPnP.
Tambin Cyberlink da soporte para la implementacin del mecanismo de control, Query for
variable, para preguntar el valor de una variable de estado de un servicio, pero como se dijo en el
apartado del marco terico que habla sobre UPnP, ste mecanismo fue deprecado por el Foro
UPnP. Si se desea averiguar que mtodos y clases define Cyberlink para este mecanismo, se
puede consultar en la gua de programacin de esta librera que se encuentra disponible en la
web de Cybergarage [CYBERGARAGE].
Se usa el mtodo setActionListener() de Action para aadirse como escuchador de la
accin.
Eventos
El Punto de Control puede subscribirse para la recepcin de eventos del dispositivo. Es el
dispositivo y no el Punto de Control quien maneja los mensajes de subscripcin automticamente.
Cuando dispositivo recibe un mensaje de subscripcin de un Punto de Control, ste es incluido
por el dispositivo en la lista su lista de subscriptores, mientras que si el mensaje es para borrar
una subscripcin es borrado de esta lista. A su vez, el dispositivo tambin maneja los mensajes
que recibe peridicamente para renovar esta subscripcin, tal y como especifica el estndar
UPnP para este mecanismo de eventos.
Para que el dispositivo establezca o actualice el valor de una variable de estado, se debe
utilizar el mtodo setValue() de la clase StateVariable. Si las modificaciones de esta
variable de estado deben ser informadas mediante este mecanismo de eventos, se enviar el
correspondiente evento a los subscriptores.
Es importante comentar que en Ciberlink, la lista de dispositivos embebidos, la lista servicios
asociados, la lista de acciones y la lista de variables de estado de estos servicios, se generan a partir
de los documentos descriptores del dispositivo y servicios del mismo.

99

ANEXO I: Cidero/Cyberlink

En la siguiente figura se muestra el Diagrama de Clases de Cyberlink para la creacin de

dispositivos UPnP.

Figura I.2. Diagrama de Clases de Cyberlink para dispositivos

Entre la clase Device y la interfaz ActionListener existe una relacin de dependencia. Se
trata de una relacin dbil, ms incluso que una Asociacin, establecida simplemente porque la
primera hace uso de un objeto de la segunda. En este caso Device hace uso de ActionListener
para aadir un escuchador, que quiere enterarse de cuando se recibe una accin, a la lista de
escuchadores que tiene cada accin de cada servicio.
El resto de relaciones son de composicin, es decir, que un objeto de la clase base est
constituida por uno o varios objetos de la otra. El tiempo de vida de estos objetos est condicionado
al tiempo de vida del que los incluye. Como ejemplo, un dispositivo (Device) est compuesto por 1 o
ms dispositivos, y por uno o ms servicios (Service), y estos dispositivos embebidos y servicios
asociados slo existen mientras exista el dispositivo que los contiene.
Para ms informacin sobre el uso de la librera Cyberlink para la implementacin de un Punto de
Control se recomienda consultar la gua de programacin de Cyberlink [CYBERGARAGE].

100

ANEXO I: Cidero/Cyberlink

3. Implementacin de los servicios con Cidero

Como ya se ha dicho, de entre el conjunto mtodos y clases que define Cidero, en base a
Cyberlink, existen cuatro clases que resultan realmente tiles para implementar los servicios
asociados a un UPnP MediaRenderer y un UPnP MediaServer.
Puesto que este proyecto versa sobre el diseo de un MediaRenderer, se ver el caso para la
implementacin de los servicios asociados a este tipo de dispositivo UPnP.
El paquete [Link] de Cidero contiene el conjunto de clases e interfaces
relacionadas con la funcionalidad UPnP. En l figuran las cuatro clases necesarias para definir los
servicios UPnP del MediaRenderer: RenderingControl, ConectionManager y AVTransport
que extienden a la clase abstracta AbstractService.
Creacin de un servicio
AbstractService es la clase base para toda clase que implemente un servicio especfico
en Cidero. Extiende la funcionalidad de la clase Service de la librera CiberLink.
Desde la perspectiva de un dispositivo, esta clase permite un mapeo automtico entre la
llegada de la invocacin de una accin UPnP y un mtodo con el mismo nombre de esa accin
definido en la clase derivada. Para ello se utiliza el mtodo actionControlReceived() de
AbastractService, en el que se procesa esta invocacin y se llama al correspondiente mtodo.
Implementacin de los servicios para un UPnP MediaRenderer
Las clases RenderingControl, ConnectionManage y AVTransport son las clases
base para la implementacin de los servicios de un UPnP MediaRenderer. Definen, entre otros, los
mtodos que implementan las acciones con el mismo nombre que la accin implementada. Algunos
de estos mtodos se definen sin funcionalidad, nicamente devuelven un false para indicar que esa
accin no es soportada. De esta forma, el programador que quiera implementar esa accin deber
crear sus propias clases derivadas de stas e implementar dichas acciones sobrescribiendo estos
mtodos.
Para las acciones soportadas, sus respectivos mtodos manejan los argumentos de entrada y
salida de la accin, as como actualizan los valores de las variables de estado que se vean
modificadas por ellos. Las clases derivadas debern considerar sta lgica para las
implementaciones de las que acciones que no estn implementadas en la clase base y lo realicen del
mismo modo, por coherencia con el conjunto de mtodos y para cumplir con la especificacin.
El formato que tiene el nombre de estos mtodos es:
action<Nombre de la accin>()
Cuando se crea una instancia de un servicio especfico se utiliza el mtodo
initializeStateVariables(), sobrescrito en la clase derivada de AbstractService, para
inicializar los valores de las variables de estado del servicio correspondiente.
En la siguiente figura se muestra el Diagrama de Clases de Cidero con las relaciones entre las
clases mencionadas. De entre los mtodos mostrados de las clases RenderingControl,
ConnectionManager y AVTransport, se pueden observar aquellos que implementan las acciones.

101

ANEXO I: Cidero/Cyberlink

Figura I.3. Diagrama de Clases de Cidero para servicios de un UPnP MediaRenderer

La relacin que se define entre la clase abstracta AbstractService y las clases Service y
Device es una Asociacin. Estos es, un objeto de AbstractService tiene asociado un objeto
Device y un objeto Service. Pero en este caso, el ciclo de vida de los objetos asociados es
independiente del ciclo de vida del objeto que los usa. En el primer caso esta asociacin es utilizada
para obtener el dispositivo al que est asociado el servicio en concreto y en el segundo lugar permite
el uso de mtodos de la clase Service necesarios para implementar la funcionalidad de este
servicio.
AbstractService implementa la interfaz ActionListener. En la creacin de una
instancia de la clase, sta se aade a la lista de escuchadores de cada accin del servicio que la
extiende invocando directamente el mtodo setActionListener() de Action.

102

ANEXO II: Modificaciones en Cidero

ANEXO II: Modificaciones en Cidero

En las prximas lneas se recogen aquellas modificaciones y adaptaciones, sobre las clases
de la librera proporcionada por la aplicacin Cidero, que fueron necesarias para el correcto
funcionamiento del prototipo de UPnP MediaRenderer diseado.

1. Introduccin
Como ya se ha dicho en varias ocasiones en la implementacin de HomeAV se ha hecho uso
del catlogo de mtodos y clases Java que provee la aplicacin Cidero.
Durante el proceso de pruebas realizadas para evaluar la comunicacin entre HomeAV
(UPnP MediaRenderer) y el Control Point, se han ido obteniendo distintos errores que han obligado a
modificar algunos del los mtodos de estas clases.
Las modificaciones realizadas buscan dos objetivos:
1. El correcto desarrollo de la comunicacin UPnP tanto en redes IPv4 como IPv6.
2. La adaptacin de las clases a las condiciones que se derivan de la integracin del UPnP
MediaRenderer en un bundle OSGi.

2. Primer objetivo: Correcto desarrollo de la comunicacin UPnP

Para alcanzar este objetivo se tuvo que modificar la lgica para la obtencin de la direccin IP
local donde se ejecuta la aplicacin que se entiende como la IP del dispositivo (HomeAV) usada en la
comunicacin.
El principal escoyo que se encontr fue durante las pruebas de la aplicacin, cuando el
equipo tena activas varias interfaces de red de las que nicamente una conectaba con la subred en
la que se encontraba el Control Point. La lgica implementada para el descubrimiento le permita a la
aplicacin enviar paquetes SSDP multicast por todas las interfaces activas y conteniendo en cada
paquete la URL para obtener el descriptor del dispositivo formada con la IP de la interfaz
correspondiente.
En este caso, y tanto con IPv4 como IPv6, surga un error en Cidero cuando reciba estos
anuncios SSDP, ya que seleccionaba el ltimo en llegar para obtener la URL que le permitiese
acceder al documento descriptor, sin tener en cuenta si se trataba de una URL formada con una IP
perteneciente a su subred u otra IP perteneciente a otras de las subredes a las que el MediaRenderer
estaba conectado
Adems de esto, surgieron ms problemas cuando la comunicacin se haca en escenarios
IPv6, como se describe a continuacin:
-

En primer lugar, uno de los fallos detectados deriva de la propia J2SE, al no entender que
la direccin de la interfaz loopback fe80::1 es precisamente de este tipo, permitiendo la
utilizacin de la misma para la configuracin de la comunicacin del dispositivo en su
inicio. Esto se comprob en el mtodo getHostAddress() de la clase
[Link], cuando se hace uso del mtodo
isLoopbackAddress() de [Link].

En segundo lugar, el problema surgi cuando el dispositivo utilizaba direcciones vlidas

IPv6 para enlace local (en Ingls: link local) en las que se aade tras la propia direccin
un identificador numrico de la interfaz a la que est asociada y que resulta necesario
para su uso. En este caso, el error aparece al no tener, dispositivo y Control Point, el
mismo identificador de red. La URL del descriptor del dispositivo contiene una
identificador que corresponde con la interfaz del UPnP MediaRenderer por la que se
envi el paquete SSDP multicast, Cidero no comprueba este identificador, y mucho
menos lo cambia por el suyo, por lo que no puede recuperar el documento.

103

ANEXO II: Modificaciones en Cidero

Por todo ello, se decidi que el dispositivo se anunciase por una sola interfaz, formndose
una nica URL para recuperar su documento descriptor. Como se ver en la descripcin de la
primera modificacin, la IP utilizada sera pues con la que se configurasen los sockets SSDP y
servidores HTTP conformes al protocolo UPnP. Por tanto, toda la comunicacin, bajo la perspectiva
de este dispositivo (HomeAV), va a estar basada en la utilizacin de dicha IP.
Modificacin 1
Se modific el mtodo que provee Cyberlink para la obtencin de las IPs locales
getHostAddress() de la clase [Link]. Lo nico que
se hizo fue aadir el cdigo que quita el identificador de interfaz IPv6 de la direccin IPv6
obtenida. Se hizo necesario esto en el caso en el que se ejecutaba el cdigo en la plataforma
Linux, ya que se aade este identificador y debe ser quitado para que el resto de mtodos de
la aplicacin que usen esta IP la puedan reconocer como vlida.
Con la direccin IP obtenida de este mtodo se crea:
-

El servidor HTTP utilizado para la implementacin de los protocolos SOAP para el control,
GENA para los eventos, y HTTP GET para la obtencin del descriptor del dispositivo.

El socket para la recepcin de los mensajes SSDP de bsqueda de dispositivos que

manda el Control Point.

Como se ver en las descripciones de las siguiente modificaciones, ste mtodo va a ser
invocado cada vez que se necesite obtener la IP local del dispositivo que est usando en la
comunicacin, en vez del mtodo getLocalAddress() de [Link] con el que
se podran producir errores derivados de lo expuesto anteriormente (principalmente que
obtenga una IP de loopback como la mencionada fe80::1).

104

ANEXO II: Modificaciones en Cidero

En el siguiente cuadro de texto se muestra el cdigo de este mtodo ya modificado.

public final static String getHostAddress(int n){
if (hasAssignedInterface() == true){
return getInterface();
}
int hostAddrCnt = 0;
try {
Enumeration nis = [Link]();
while ([Link]()){
NetworkInterface ni =
(NetworkInterface)[Link]();
Enumeration addrs = [Link]();
while ([Link]()) {
InetAddress addr =
(InetAddress)[Link]();
if (isUsableAddress(addr) == false)
continue;
if (hostAddrCnt < n) {
hostAddrCnt++;
continue;
}
String host = [Link]();
if(isIPv6Address(host)){
if(isGlobalScopeAddress ((Inet6Address)addr)){
int index=[Link]('%');
if(index > 0){
host=[Link](0,
index);
}
}
}
return host;
}
}
}
catch(Exception e){};
return "";
}

Cuadro de texto II.1. Mtodo getHostAddress() de [Link]

Modificacin 2
Se actualiz el cdigo de la clase Device del paquete [Link] a
la versin que se incluye en la aplicacin CMGate del mismo creador que la librera. Esta
versin corrige algunos fallos de la anterior y adems aade mayor funcionalidad. Lo ms
interesante para HomeAV y por tanto lo que indujo a hacer este cambio fue la modificacin de
los mtodos announce() y byebye() utilizados en la fase de descubrimiento (que utiliza el
protocolo SSDP), para que se cierren los sockets SSDP tras el envo de cada notificacin.
Adems, se modific el cdigo del mtodo httpGetRequestReceived() en
aquellas sentencias en las que se obtena la direccin local del dispositivo (HomeAV)
mediante un procedimiento que implicaba la invocacin al mencionado mtodo
getLocalAddress() de [Link]. Obviamente, se utiliza la llamada al mtodo
getHostAddress() de HostInterface, tal y como se advirti anteriormente.

105

ANEXO II: Modificaciones en Cidero

private void httpGetRequestReceived( HTTPRequest httpReq )

{
/**This method is invoked when the Control Point sends a HTTP-GET
request to obtain the Device description file or the Service
description files
*/
String uri = [Link]();
if (uri == null) {
[Link]();
return;
}
Device embDev;
Service embService;
byte fileByte[] = new byte[0];
if (isDescriptionURI(uri) == true) {
String localAddr = [Link](0); //before
-> [Link]();
fileByte = getDescriptionData(localAddr);
}else if ((embDev = getDeviceByDescriptionURI(uri)) != null) {
String localAddr = [Link](0); //before
-> [Link]();
fileByte = [Link](localAddr);
} else if ((embService = getServiceBySCPDURL(uri)) != null) {
fileByte = [Link]();
} else {
[Link]();
return;
}
HTTPResponse httpRes = new HTTPResponse();
if ([Link](uri) == true)
[Link](XML.CONTENT_TYPE);
[Link]([Link]);
[Link](fileByte);
[Link](httpRes);
}

Cuadro de texto II.2. Mtodo httpGetRequesteReceived() de

[Link]
Modificacin 3
Se modific el mtodo receive() de las clases HTTPUSocket y HTTPMUSocket
del paquete [Link]. Se modifica la invocacin a los respectivos
mtodos setLocalAddress() de ambas clases. Previamente se estableca la IP local de la
forma que se viene diciendo, invocando al mtodo getLocalAddress() de la clase
[Link]. Con esta modificacin, la direccin local se establecer a partir de la
obtenida en la llamada al mtodo getHostAddress() de HostInterface, como en el
anterior caso.
Aunque el mtodo receive() de HTTPUSocket no es invocado en la perspectiva
del MediaRenderer, se decidi modificarlo tambin por coherencia entre ambas clases.

106

ANEXO II: Modificaciones en Cidero

public SSDPPacket receive(){

byte ssdvRecvBuf[] = new byte[SSDP.RECV_MESSAGE_BUFSIZE];
SSDPPacket recvPacket = new SSDPPacket(ssdvRecvBuf,
[Link]);
[Link]([Link](0));
//before->(getLocalAddress());
try {
[Link]([Link]());
[Link]([Link]());
}
catch (Exception e) {
//[Link](e);
}
return recvPacket;
}

Cuadro de texto II.3. Mtodo receive() de [Link]

Modificacin 4
En este caso se modific el mtodo setHost() de la clase
[Link]. nicamente se aadi un condicionante para el
caso en que se obtengan direcciones IPv6 en un formato en el que la IP no est contenida
entre dos corchetes (ejemplo: 2001::1). Esto ocurra con las direcciones IPv6 cuando se
ejecutaba en el equipo Windows, y se hacen necesarios estos caracteres para formar
correctamente el campo HOST de los mensajes HTTP. Con el nuevo cdigo estos caracteres
se aadirn.
public void setHost(String host, int port)
{
String hostAddr = host;
if (HostInterface.isIPv6Address(host) == true){
if(!([Link]("[") && [Link]("]")))
hostAddr = "[" + host + "]";
}
setHeader([Link], hostAddr + ":" + [Link](port));
}

Cuadro de texto II.4. Mtodo setHost() de [Link]

3. Segundo objetivo: Adaptacin para la integracin en un bundle OSGi

Como se coment en el captulo Marco Terico, el Framework de OSGi provee de un
contexto de ejecucin propio al bundle. Para acceder a los recursos, como archivos, del bundle se ha
de utilizar este contexto.
Los mtodos definidos en Cidero y Cyberlink para recuperar estos descriptores se basan en
la creacin de un objeto File a partir de la ruta relativa del fichero. Sin embargo, esto no es aplicable
cuando se integra la aplicacin en un bundle por lo dicho anteriormente.
Sabiendo esto, se implement en HomeAV la lgica necesaria para poder acceder a los
documentos descriptores del dispositivo y servicios alojados en el bundle. Como resultado se utilizar
el contexto del bundle para acceder a estos recursos, obteniendo la URL de cada descriptor. A partir
de esta URL se abrir una conexin para recuperar un flujo de entrada (InputStream) con los datos
contenidos en cada fichero.
Por tanto, se dispondr de un flujo de entrada por cada descriptor en vez de un objeto File.
En consecuencia se tuvo que realizar algunas modificaciones en las clases relacionadas con el
manejo de estos descriptores, entre las que se incluyen clases de Cidero y clases de la librera
Ciberlink.

107

ANEXO II: Modificaciones en Cidero

Modificacin 5
Es la principal modificacin realizada. Se trata de la creacin del mtodo
parseInputStream() en la clase [Link] utilizada para la
recuperacin de la informacin de los documentos XML. Est basado en el mtodo de la
misma clase parse(File descriptionFile). El flujo de entrada se analiza directamente
y tras esto se cierra.
////////////////////////////////////////////////
//
parse (InputStream)
////////////////////////////////////////////////
public Node parseInputStream(InputStream inStream) throws
ParserException{
try{
InputStream inputStrm = inStream;
Node root = parse(inputStrm);
[Link]();
return root;
} catch (Exception e) {
[Link]("ERROR");
return null;
}
}

Cuadro de texto II.5. Mtodo parseInputStream(InputStream) de

[Link]
Modificacin 6
Se aade el mtodo loadDescription(InputStream descStream) a la clase
[Link].
Se
basa
en
el
mtodo
anlogo
loadDescriptionFile(File file). Permite cargar el descriptor del servicio a partir del
flujo de entrada de su contenido. Utiliza el mtodo visto anteriormente para recuperar la
informacin del documento.
Este
mtodo
es
utilizado
en
el
[Link] de HomeAV.

constructor

de

public boolean loadDescription(InputStream descStream)

throws InvalidDescriptionException {
try { Parser parser = [Link]();
rootNode = [Link](descStream);
if (rootNode == null)
throw new InvalidDescriptionException(
Description.NOROOT_EXCEPTION);
deviceNode = [Link](Device.ELEM_NAME);
if (deviceNode == null)
throw new InvalidDescriptionException(
Description.NOROOTDEVICE_EXCEPTION);
} catch (ParserException e) {
throw new InvalidDescriptionException(e);
}if (initializeLoadedDescription() == false)
return false;
setDescriptionFile(null);
return true;
}

Cuadro de texto II.6. Mtodo loadDescription(InputStream) de

[Link]

108

la

clase

ANEXO II: Modificaciones en Cidero

Modificacin 7
Se modific el mtodo getSCPDNode() de [Link]
utilizado, en varias clases de Ciberlink, para poder recuperar informacin del documento XML
de descripcin de un servicio. Con la modificacin se busca poder obtener esta informacin a
partir de un flujo de entrada que, como se coment, es lo que obtenemos al acceder a un
fichero descriptor contenido en el bundle. Para ello se tuvieron que crear varios mtodos:
- getSCPDNode(InputStream inputStrm)
- getServiceDescriptionInputStream()
- setServiceDescriptionURL()
, adems de una variable servDescrpURL.
Para que el cdigo del mtodo mantuviese su misma funcionalidad se hizo que se
tratase la excepcin del Parser, lanzado al no poder obtener el descriptor de la forma usual
por
no
acceder
al
contexto
del
bundle,
y
se
invocase
al
mtodo
getSCPDNode(InputStream) creado para este caso.
A continuacin se muestra el cdigo modificado del mtodo getSCPDNode():
try {
scpdNode = getSCPDNode(new File(newScpdURLStr));;
}
catch (Exception e4) {
if(e4 instanceof ParserException){
try{//(OSGI)
scpdNode = getSCPDNode(
getServiceDescriptionInputStream();
}
catch(Exception e){
[Link]("Impossible to parse the
Service description file");
[Link](e);
}
}else
[Link](e4);
}

Cuadro de texto II.7. Cdigo modificado del mtodo getSPDNode() de

[Link]
El primero de los mtodos creados, getSCPDNode(InputStream input Strm),
es una variacin de otro de la misma clase, getSCPDNode(File file), para el caso en
que se quiera obtener la informacin del descriptos a parte de un flujo de entrada. Para ello,
har uso del mtodo ya comentado parseInputStream().
private Node getSCPDNode(InputStream inputStrm) throws ParserException{
Parser parser = [Link]();
return [Link](inputStrm);
}

Cuadro de texto II.8. Mtodo getSCPDNode(InputStream) de

[Link]
Los otros dos mtodos aadidos son, setServiceDescriptionURL() y
getServiceDescriptionInputStream(), y una variable, servDescrptURL. La variable
guarda la URL del descriptor del servicio que corresponda y es utilizado en los dos mtodos
anteriores. En el primer caso para establecer el valor de esta variable, y en el segundo para
abrir una conexin con esta URL y recuperar un flujo de entrada con los datos contenidos en
el fichero.

109

ANEXO II: Modificaciones en Cidero

El mtodo setServiceDescriptionURL() es invocado y por tanto establecida la

URL, en el constructor de la clase [Link], creado
especficamente para ello y que del que se hablar en el siguiente apartado de
modificaciones. Mientras, el otro mtodo getServiceDescriptionInputStream(), como
ya se ha visto, es utilizado en el mtodo getSCPDNode().
public void setServiceDescriptionURL(URL servDescrptURL){
[Link]("Service description URL: " + servDescrptURL);
[Link] = servDescrptURL;
}

Cuadro de texto II.9. Mtodo setServiceDescriptionURL() de

[Link]
private InputStream getServiceDescriptionInputStream(){
InputStream is = null;
try {
is = [Link]();
} catch (IOException e) {
// TODO Auto-generated catch block
[Link]("An error occurs opening the stream");
}
return is;
}

Cuadro de texto II.10. Mtodo getServiceDescriptionURL() de

[Link]
Modificacin 8
Las ltimas modificaciones afectan a las clases de Cidero utilizadas por HomeAV.
En primer lugar, se cre un nuevo constructor en la clase abstracta
[Link]. Las diferencias respecto del otro constructor ya definido
son:
1. Posee un argumento de entrada ms, la URL del descriptor del servicio.
2. Invoca al mtodo setServiceDescriptorURL(), visto anteriormente, para pasar esta
URL y que as se pueda recuperar cuando se invoque el otro mtodo,
getServiceDescriptorInputStream(), de la clase Service.

110

ANEXO II: Modificaciones en Cidero

/**
* Constructor (OSGI). Setup all the action/query listeners for
*
this service,using the CLink device service with the same name as * this
service
* @param
CLink device object, Service description URL
* @exception Throws InvalidDescriptionException if device has no
*
matching service
*/
public AbstractService( Device device, URL servDescrptURL )
throws InvalidDescriptionException
{
// Get underlying Cybergarage service object for this service
//and install actionControlReceived() 'dispatcher' method below for
// all actions
[Link] = device;
ServiceList serviceList = [Link]();
if (serviceList == null)
{
[Link]("Null service list in service constructor");
throw new InvalidDescriptionException("Null device service
list");
}
int n;
for (n = 0; n < [Link](); n++)
{
Service service = [Link](n);
[Link]("ServiceType = "+[Link]());
[Link]("ServiceId = " + [Link]());
if( [Link](getServiceType()) )
{
[Link](servDescrptURL);
[Link]("Matching service found ");
[Link] = service;
[Link]( this );
[Link]( this );
ActionList actionList = [Link]();
for (int j = 0; j < [Link](); j++)
{
Action action = [Link]( j );
[Link]( this );
}
break;
}else{
[Link]("Not a matching service ");
}
}
if (n == [Link]())
{
throw new InvalidDescriptionException("Device doesn't
support service '" + getServiceType() );
}
// If this service is being instantiated on the *device* side
//)initialize state variables
if( [Link]() == [Link] )
initializeStateVariables();
}

Cuadro de texto II.11. Constructor de la clase abstracta [Link]

De entre las clases de Cidero que implementan servicios
y que extienden a
AbstractService, se modificaron las que corresponden con los servicios asociados a un UPnP
MediaRenderer:
- [Link]
- [Link]
- [Link]

111

ANEXO II: Modificaciones en Cidero

La modificacin slo consisti en la creacin de un nuevo constructor, para cada una, que
tuviese tambin este argumento de entrada, URL, y que llamase al constructor anterior de la clase
base. A su vez, estos constructores sern llamados en los constructores de las respectivas clases de
HomeAV que las extienden (AVTransportService, ConnectionManagerService y
RenderingControlService).
/**
* Constructor (OSGI)
* @param device, servDescrptURL
* @throws InvalidDescriptionException
*/
public AVTransport( Device device, URL servDescrptURL ) throws
InvalidDescriptionException{
super( device, servDescrptURL );
[Link]("Entered AVTransport base class constructor");
[Link]("Leaving AVTransport constructor");
}

Cuadro de texto II.12. Constructor de la clase [Link]

/**
* Constructor (OSGI)
* @param device, servDescrptURL
* @throws InvalidDescriptionException
*/
public ConnectionManager( Device device, URL servDescrptURL)
throws InvalidDescriptionException{
super( device, servDescrptURL );
[Link]("Entered ConnectionManager base class constructor");
[Link]("Leaving ConnectionManager constructor");
}

Cuadro de texto II.13. Constructor de la clase [Link]

/**
* Constructor (OSGI)
* @param device, servDescrptURL
* @throws InvalidDescriptionException
*/
public RenderingControl( Device device, URL servDescrptURL )throws
InvalidDescriptionException{
super( device, servDescrptURL );
[Link]("Entered RenderingControl base class constructor");
[Link]("Leaving RenderingControl constructor");
}

Cuadro de texto II.14. Constructor de la clase [Link]

112

ANEXO III: Diagramas UML

ANEXO III: Diagramas UML

Este anexo es un breve tutorial sobre UML para la descripcin de los diagramas de este
lenguaje que han sido utilizados en la elaboracin del presente proyecto.

1. Introduccin
El Lenguaje de Modelamiento Unificado (UML: Unified Modeling Language) es un lenguaje
grfico para visualizar, especificar y documentar cada una de las partes que comprende el desarrollo
de software. [UMLTUTORIAL]
A continuacin se describe el formato de los tres tipos de diagramas UML que se pueden
encontrar en varios apartados de la memoria:
-

Diagrama de Casos de Uso.

Diagrama de Clases.
Diagrama de Secuencias.

2. Diagrama de Casos de Uso

Este diagrama pretende representar de forma grfica y sencilla la funcionalidad de un sistema
y su interaccin con los actores que intervienen. A continuacin se describen las distintas entidades
que figuran en el diagrama, as como sus posibles relaciones:
-

Actores: son entidades externas al sistema pero que demandan o provocan una
funcionalidad de este. Pueden se tanto personas como organizaciones o como otros
sistemas.

Casos de uso: expresa una unidad coherente de funcionalidad del sistema. Es decir, algo
que el sistema realiza.

Relaciones entre los casos de uso:

-

Inclusin (include): una instancia del Caso de Uso origen incluye tambin el
comportamiento descrito por el Caso de Uso destino.

Extensin (extend): El caso de uso origen extiende el comportamiento del caso

de uso destino. Es una especificacin de la funcionalidad que describe el caso de
destino.

Herencia: El caso de uso origen hereda la especificacin del caso de uso destino
y posiblemente la modifica y/o ampla.

113

ANEXO III: Diagramas UML

3. Diagrama de Clases
3.1 Introduccin
Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el
sistema, las cuales pueden ser asociativas, de herencia, de uso y de contenimiento.
Un diagrama de clases esta compuesto por los siguientes elementos:

Clases: atributos, mtodos y visibilidad.

Relaciones: Herencia, Composicin, Agregacin, Asociacin y Uso.

3.2 Clase
Es la unidad bsica que encapsula toda la informacin de un Objeto (un objeto es una
instancia de una clase). A travs de ella podemos modelar el entorno en estudio (una Casa, un Auto,
una Cuenta Corriente, etc.).
En UML, una clase es representada por un rectngulo que posee tres divisiones:

En donde:

Superior: Contiene el nombre de la Clase

Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase
(pueden ser private, protected o public).
Inferior: Contiene los mtodos u operaciones, los cuales son la forma como interacta el
objeto con su entorno (dependiendo de la visibilidad: private, protected o public).

Ejemplo:
Una Cuenta Corriente que posee como caracterstica:
-

Balance

Puede realizar las operaciones de:

-

Depositar
Girar
Balance

El diseo asociado es:

Atributos y Mtodos de una Clase:

114

ANEXO III: Diagramas UML

Atributos:
Los atributos o caractersticas de una Clase pueden ser de tres tipos, los que definen el grado
de comunicacin y visibilidad de ellos con el entorno, estos son:

public (+): Indica que el atributo ser visible tanto dentro como fuera de la clase, es decir, es
accsesible desde todos lados.
private (-): Indica que el atributo slo ser accesible desde dentro de la clase (slo sus
mtodos lo pueden accesar).
protected (#): Indica que el atributo no ser accesible desde fuera de la clase, pero si podr
ser accesado por mtodos de la clase adems de las subclases que se deriven (ver
herencia).
Mtodos:

Los mtodos u operaciones de una clase son la forma en como sta interacta con su
entorno, stos pueden tener las caractersticas:

public (+): Indica que el mtodo ser visible tanto dentro como fuera de la clase, es decir, es
accesible desde todos lados.
private (-): Indica que el mtodo slo ser accesible desde dentro de la clase (slo otros
mtodos de la clase lo pueden accesar).
protected (#): Indica que el mtodo no ser accesible desde fuera de la clase, pero si podr
serlo por mtodos de la clase adems de mtodos de las subclases que se deriven.

3.3 Relaciones entre Clases:

Ahora ya definido el concepto de Clase, es necesario explicar como se pueden interrelacionar
dos o ms clases (cada uno con caractersticas y objetivos diferentes).
Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la
cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada extremo de
la relacin y stas pueden ser:

uno o muchos: 1..* (1..n)

0 o muchos: 0..* (0..n)
nmero fijo: m (m denota el nmero).
Herencia (Especializacin/Generalizacin):

Indica que una subclase hereda los mtodos y atributos especificados por una Super Clase,
por ende la Subclase adems de poseer sus propios mtodos y atributos, poseer las caractersticas
y atributos visibles de la Super Clase (public y protected), ejemplo:

115

ANEXO III: Diagramas UML

En la figura se especifica que Auto y Camin heredan de Vehculo, es decir, Auto posee las
Caractersticas de Vehculo (Precio, VelMax, etc) adems posee algo particular que es Descapotable,
en cambio Camin tambin hereda las caractersticas de Vehiculo (Precio, VelMax, etc.) pero posee
como particularidad propia Acoplado, Tara y Carga.
Cabe destacar que fuera de este entorno, lo nico "visible" es el mtodo Caractersticas
aplicable a instancias de Vehculo, Auto y Camin, pues tiene definicin publica, en cambio atributos
como Descapotable no son visibles por ser privados.
Agregacin:
Para modelar objetos complejos, n bastan los tipos de datos bsicos que proveen los
lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son
instancias de clases definidas por el desarrollador de la aplicacin, tenemos dos posibilidades:

Por Valor: Es un tipo de relacin esttica, en donde el tiempo de vida del objeto incluido esta
condicionado por el tiempo de vida del que lo incluye. Este tipo de relacin es comnmente
llamada Composicin (el Objeto base se construye a partir del objeto incluido, es decir, es
"parte/todo").
Por Referencia: Es un tipo de relacin dinmica, en donde el tiempo de vida del objeto
incluido es independiente del que lo incluye. Este tipo de relacin es comnmente llamada
Agregacin (el objeto base utiliza al incluido para su funcionamiento).
Un Ejemplo es el siguiente:

En donde se destaca que:

-

Un Almacen posee Clientes y Cuentas (los rombos van en el objeto que

posee las referencias).

116

ANEXO III: Diagramas UML

Cuando se destruye el Objeto Almacen tambin son destruidos los objetos

Cuenta asociados, en cambio no son afectados los objetos Cliente
asociados.
La composicin (por Valor) se destaca por un rombo relleno.
La agregacin (por Referencia) se destaca por un rombo transparente.

La flecha en este tipo de relacin indica la navegabilidad del objeto referenciado. Cuando no
existe este tipo de particularidad la flecha se elimina.
Asociacin:
La relacin entre clases conocida como Asociacin, permite asociar objetos que colaboran
entre si. Cabe destacar que no es una relacin fuerte, es decir, el tiempo de vida de un objeto no
depende del otro.
Ejemplo:

Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una orden de
compra solo puede tener asociado un cliente.
Dependencia o Instanciacin (uso):
Representa un tipo de relacin muy particular, en la que una clase es instanciada (su
instanciacin es dependiente de otro objeto/clase). Se denota por una flecha punteada.
El uso ms particular de este tipo de relacin es para denotar la dependencia que tiene una
clase de otra, como por ejemplo una aplicacin grafica que instancia una ventana (la creacin del
Objeto Ventana esta condicionado a la instanciacin proveniente desde el objeto Aplicacion):

Cabe destacar que el objeto creado (en este caso la Ventana grfica) no se almacena dentro
del objeto que lo crea (en este caso la Aplicacin).

4. Diagrama de Secuencias
4.1 Introduccin
El diagrama de interaccin, representa la forma en como un Cliente (Actor) u Objetos (Clases)
se comunican entre si en peticin a un evento. Esto implica recorrer toda la secuencia de llamadas,
de donde se obtienen las responsabilidades claramente.
Dicho diagrama puede ser obtenido de dos partes, desde el Diagrama Esttico de Clases o el
de Casos de Uso (son diferentes).
Los componentes de un diagrama de interaccin son:

Un Objeto o Actor.
Mensaje de un objeto a otro objeto.
Mensaje de un objeto a s mismo.

117

ANEXO III: Diagramas UML

4.2 Objeto/Actor:

El rectngulo representa una instancia de un Objeto en particular, y la lnea punteada se

utiliza para representar las llamadas a mtodos del objeto de forma secuencial.
4.3 Mensaje a Otro Objeto:

Se representa por una flecha entre un objeto y otro, representa la llamada de un mtodo
(operacin) de un objeto en particular. La lnea discontinua indica el final de la ejecucin del mtodo.
Esta lnea aparece en el caso de que dentro del mtodo se hagan llamadas a otros mtodos, los
cuales se muestran en el diagrama justo por debajo de su llamada y antes de sta.
.
4.4 Mensaje al Mismo Objeto:

No solo se pueden realizar llamadas a mtodos de objetos externos, tambin es posible

visualizar llamadas a mtodos desde el mismo objeto en estudio. Si el color de la lnea es rojo, el
mtodo est definido como privado (slo puede ser invocado dentro de la clase). De la misma manera
que en el aparatado anterior, la lnea continua indica el final de la ejecucin del mtodo.
En la siguiente figura se muestranlos smbolos + y -. El primero indica que el mtodo est
comprimido, es decir, invoca a otros mtodos del anlisis pero que no son mostrados. El siguiente
indica que el mtodo esta expandido, por lo que se muestran los mtodos que invoca justo debajo y
antes del smbolo correspondiente de final de mtodo.

118

ANEXO IV: Ficheros de la aplicacin

ANEXO IV: Ficheros de la aplicacin

En este anexo se muestran los ficheros que son utilizados por la aplicacin durante su
ejecucin.

1. Fichero de configuracin
Se trata del fichero que utiliza HomeAV en su inicio para la configuracin de algunos
parmetros que modelan algunas funciones del mismo.
# HomeAV UPnP MediaRenderer
# This configuration file provides five parameters to configure some
# application's characteristics.
#
#
#
#
#
#
#
#
#
#
#

sessionIPv6 -> enables|disables IPv6 network addressing

seconRTPSession -> allows to create a second RTP session based on the first one.
HomeAV create just one RTP session by default. This variable
allows to create a second one with the following parameters:
address = the same as the first RTP session
port = [(the same as the first RTP session) + 2]
interfaceNumber -> network interface identifier to get the IP address to be used
nextAutoTransition -> enables|disables the 'setNextAVTransportURI' action
to implement gapless multi-track playbacks
cachingEnabled -> enables|disables to cache the resource to local disk during the
playback

#--------------------------------------------------------------------------# Allowed values:

# sessionIPv6 = no | yes
# secondRTPSession = no | yes
# interfaceNumber = 0 | 1 | ... (a positive integer)
# nextAutoTransition = yes | no
# cachingEnabled = yes | no
#--------------------------------------------------------------------------sessionIPv6=no
secondRTPSession=no
interfaceNumber=0
nextAutoTransition=yes
cachingEnabled=yes

Cuadro de texto IV.1. Fichero de configuracin de HomeAV ([Link])

El significado de estos parmetros es:
-

sessionIPv6: habilita o deshabilita el direccionamiento IPv6 para cuando la comunicacin

se realice en redes IPv6. Su valor por defecto es no.
seconRTPSession: para determinar si se desea o no que la aplicacin cree una nica
sesin RTP para un nico flujo, o bien, se creen dos sesiones para dos flujos. En tal caso, los
parmetros de la segunda sesin sern los mismos que la primera (IP, puerto y ttl) excepto
que el puerto ser dos unidades superior al de la primera. Esta opcin es indicada cuando se
van a recibir dos flujos RTP, uno de audio y otro de video. Su valor por defecto es no.
interfaceNumber: este parmetro numrico identifica la interfaz de red que se desea
utilizar para la comunicacin. Su valor por defecto es 0, con el que se obtendr la primera
direccin IP vlida de la primera interfaz de red habilitada.
nextAutoTransition: con este parmetro se indica si se desea o no que est disponible la
accin SetNextAVTransportURI() del servicio AVTransport Service. Gracias a sta
HomeAV puede preparar la siguiente reproduccin para que cuando acabe la que est en
proceso no haya espacios en blanco entre ambas. Slo utilizada en caso de reproducciones
de contenido de audio y/o video obtenido mediante HTTP. Su valor por defecto yes.
cachingEnabled: habilita o deshabilita la opcin de caching del Player, por la cual, un
fichero puede ser descargado localmente y de forma temporal previamente a su
reproduccin. Esta opcin es utilizada en el proceso de reproduccin de contenido de audio
y/o video obtenido mediante HTTP.

119

ANEXO IV: Ficheros de la aplicacin

2. Documento descriptor del dispositivo UPnP

A continuacin se muestra el documento XML de descripcin del dispositivo HomeAV. Por su
extensin, no se muestran los correspondientes descriptores de los servicios contenidos,
RenderinControl Service, ConnectionManager Service y AVTransport Service. La informacin sobre
las acciones implementadas se mencionan en la descripcin sobre las clases Java correspondientes
descritas en el apartado sobre HomeAV en el capitulo Implementacin.
Todos estos documentos sern solicitados por el AV Control Point para crear el modelo del
dispositivo UPnP MediaRenderer (HomeAV), pero tambin son utilizados por la propia aplicacin para
obtener, entre otras cosas, la lista de servicios contenidos, as como la lista de sus correspondientes
acciones o variables de estado definidas.
Documento XML de descripcin del dispositivo HomeAV (DCPD):
<?xml version="1.0" encoding="utf-8"?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<device>
viceType>urn:schemas-upnp-org:device:MediaRenderer:1</deviceType>
<friendlyName></friendlyName>
<manufacturer></manufacturer>
<manufacturerURL></manufacturerURL>
<modelDescription>Renders audio video files and images from UPnP
MediaServers</modelDescription>
<modelName>HomeAV UPnP Renderer</modelName>
<modelNumber>1.0</modelNumber>
<modelURL></modelURL>
<UDN></UDN>
<serviceList>
<service>
<serviceType>urn:schemas-upnp-org:service:AVTransport:1</serviceType>
<serviceId>urn:upnp-org:serviceId:urn:schemas-upnporg:service:AVTransport</serviceId>
<SCPDURL>/service/[Link]</SCPDURL>
<controlURL>/service/AVTransport_control</controlURL>
<eventSubURL>/service/AVTransport_event</eventSubURL>
</service>
<service>
<serviceType>urn:schemas-upnp-org:service:RenderingControl:1</serviceType>
<serviceId>urn:upnp-org:serviceId:urn:schemas-upnporg:service:RenderingControl</serviceId>
<SCPDURL>/service/[Link]</SCPDURL>
<controlURL>/service/RenderingControl_control</controlURL>
<eventSubURL>/service/RenderingControl_event</eventSubURL>
</service>
<service>
<serviceType>urn:schemas-upnp-org:service:ConnectionManager:1</serviceType>
<serviceId>urn:upnp-org:serviceId:urn:schemas-upnporg:service:ConnectionManager</serviceId>
<SCPDURL>/service/[Link]</SCPDURL>
<controlURL>/service/ConnectionManager_control</controlURL>
<eventSubURL>/service/ConnectionManager_event</eventSubURL>
</service>
</serviceList>
</device>
</root>

Cuadro de texto IV.2. Documento XML de descripcin del dispositivo HomeAV

120

ANEXO V: Instrucciones de instalacin

ANEXO V: Instrucciones de instalacin

En este anexo se enumeran los pasos necesarios pasta la puesta en marcha de la aplicacin.
Es necesario advertir que esta aplicacin no fue desarrollada para su distribucin ni
comercializacin, por lo que no se han considerado los aspectos restrictivos al respecto que marca la
licencia SCSL de Sun Microsystems [SUNSCSL] para JMF.

1. Requerimientos del sistema

A continuacin se enumeran los requerimientos previos del sistema y en base a los cuales la
aplicacin ha sido desarrollada y probada:

Hardware: PC con un mnimo de 256MB de RAM y procesador de 800MHz.

Sistemas Operativos: plataformas Windows y Linux de 32 bits. Los sistemas operativos

utilizados han sido: Windows XP y Linux Ubuntu 8.04.

UPnP: debe estar habilitado UPnP en el sistema operativo y configurado el cortafuegos para
que permita su uso.

JVM: la aplicacin est programada en Java y ha sido empaquetada en un bundle, creando

un fichero JAR (Java ARChive), por lo que se hace necesario tener instalada una JVM
(Mquina Virtual Java). Las versiones utilizadas son:
- JDK 1.6 para Windows [JDK1.6].
- JDK 1.7 para Linux [JDK1.7].

Implementacin OSGi: una vez instalada la JVM, se ha de obtener una implementacin del
Framework de OSGi. Las que se muestran a continuacin (de software libre) son sobre las
que la aplicacin ha sido probada:
- Equinox 3.3.0 de Eclipse [EQUINOX]
- Felix 1.8.0 de Apache [FELIX]

2. Requerimientos de la aplicacin
Sin JMF instalada en el equipo:
Copiar el fichero de propiedades de JMF, [Link], que se distribuye con el bundle en el
mismo directorio que el .jar de la implementacin OSGi correspondiente.
Para plataformas Linux, se hace necesario exportar la variable del sistema
LD_LIBRARY_PATH aadiendo la ruta del directorio natives, con las libreras nativas de
JMF, que se distribuye con el bundle. Otra solucin, sera copiar estas libreras al directorio
donde se encuentren las libreras del sistema, normalmente usr/lib.
Con JMF instalada en el equipo:
Se han de instalar los plug-ins de codecs de los que hace uso la aplicacin:
- Fobs4JMF v0.4.1 [FOBS]
- MP3 plug-in de Sun [MP3PLUGIN]
- JFFMPEG v 1.1.0[JFFMPEG]
Para este proceso seguir los pasos que se indican en las respectivas webs, con un matiz
respecto de las instrucciones para Jffmpeg: obviar las referencias a las libreras nativas .so
y .dll.
Tras esto, y una vez aadido los plug-in al registro, sustituir el [Link] contenido en el
directorio donde se encuentra el .jar de la librera JMF, y sustituirlo por el que se distribuye
con el bundle.
Una vez realizado esto, ya se puede controlar el ciclo de vida del bundle en el Framework OSGi
por medio de los correspondientes comandos install, start, stop y uninstall.

121

ANEXO VI: Presupuesto

ANEXO VI: Presupuesto

Este anexo contiene una breve descripcin de las fases de ejecucin del proyecto y una
memoria resumida de los costes y gastos generados de la realizacin del mismo.

1. Fases del proyecto

En las prximas lneas se enumeran las tareas que se han realizado agrupadas en las
distintas fases que definen la consecucin de este proyecto:
Fase 1: Estudios previos: Marco Terico
En esta fase se adquirieron los conocimientos tericos necesarios para el desarrollo
de la aplicacin. Las tareas realizadas son:
-

Estudio de la tecnologa UPnP.

Estudio de la Arquitectura AV UPnP, con especial atencin al UPnP
MediaRenderer.
Anlisis de las soluciones de UPnP MediaRenderer disponibles en el mercado
actual.
Estudio de la librera multimedia JMF para su utilizacin en el tratamiento del
contenido multimedia.
Anlisis del paquete Java AWT y Java Swing para la creacin de interfaces
grficas y visualizacin de imgenes.
Estudio de la tecnologa OSGi y el API que define la plataforma.

Duracin = 320 horas.

Fase 2: Diseo del prototipo
En esta fase se realiz la implementacin propiamente dicha del dispositivo UPnP
MediaRenderer en base a los conocimientos adquiridos en la fase previa. Las tareas que se
definen suponen la implementacin de cada una de las unidades funcionales de la aplicacin.
Estas son:
-

Anlisis de requisitos del sistema y definicin de las herramientas a utilizar.

Diseo e Implementacin del dispositivo UPnP y la definicin de los servicios
asociados a un UPnP MediaRenderer.
Modificacin de las libreras de Cidero/Cyberlink.
Diseo e implementacin de la funcionalidad para la reproduccin de contenido
de audio y video obtenido mediante el protocolo HTTP.
Diseo e implementacin de la funcionalidad para la visualizacin de imgenes.
Diseo e implementacin de la funcionalidad para la reproduccin de flujos RTP
de audio y video.
Integracin de la aplicacin en un bundle OSGi.

Duracin = 410 horas.

Fase 3: Pruebas del prototipo:
Una vez obtenido el prototipo de UPnP MediaRenderer integrado en OSGi, se realiz
una fase de pruebas para comprobar el correcto funcionamiento de la aplicacin en los
posibles escenarios.
-

Pruebas de funcionalidad en las que se comprueba la respuesta de la aplicacin

en un escenario real.
Pruebas en escenarios IPv6 para comprobar la compatibilidad con este protocolo
de red.
Pruebas en escenarios con ms de un Control Point.

122

ANEXO VI: Presupuesto

Anlisis de los tiempos de respuesta de la aplicacin para la fase de

descubrimiento UPnP y la reproduccin de ficheros de audio y video.

Duracin = 65 horas.
Fase 4: Elaboracin de la documentacin.
Duracin = 280 horas.

2. Costes
Para la elaboracin del presupuesto se han considerado aquellos costes que estn
relacionados con la utilizacin de bienes materiales y los que provienen de la mano de obra para la
realizacin del proyecto.
Costes materiales
Son los derivados de la creacin del entorno de trabajo donde se ha desarrollado y probado
la aplicacin, incluyendo los costes indirectos estimados por el consumo energtico, material fungible
y comunicaciones.
Se han considerado nicamente los equipos que han sido necesarios en este proceso aunque
se hayan utilizado un nmero mayor para las pruebas.

Concepto
2 Ordenadores Personales
(Windows XP HE/Prof)
1 Ordenador Personal
(Linux Ubuntu)
1 Router
(Wi-Fi + 4 puertos Ethernet)

Precio ()

Periodo de
Amortizacin
(meses)

Periodo de
uso (meses)

Importe
()

1.400

36

10

388,89

500

36

10

138,89

60

36

10

16,67

Costes indirectos

460

TOTAL

1.004,45

Tabla VI.1. Costes materiales

Costes de mano de obra:
Cumpliendo una normativa europea, los colegios profesionales han dejado de publicar
baremos orientativos de los honorarios. Como consecuencia, la cifra utilizada que define el sueldo por
hora de un Ingeniero Tcnico de Telecomunicaciones es una estimacin deducida de la informacin
obtenida en webs de empleo [WEBEMPLEO].

123

ANEXO VI: Presupuesto

En este proyecto ha intervenido un nico Ingeniero Tcnico de Telecomunicaciones para

realizar el conjunto de tareas definidas en las distintas fases del proyecto. Por tanto, el coste derivado
de la mano de obra es:
Responsable
Ingeniero Tcnico de
Telecomunicaciones

Horas

/Hora

Importe ()

1075

40

43.000

Tabla VI.2. Costes de mano de obra

Presupuesto total:
En la siguiente tabla se resume el presupuesto total para la realizacin del proyecto:
Concepto

Importe ()

Costes materiales

1.004,45

Costes de mano de obra

43.000

Total base imponible

44.004,45

IVA (16%)

7.040,71
TOTAL

51.045,16
Tabla VI.3. Presupuesto total

124

ANEXO VII: Bibliografa

ANEXO VII: Bibliografa

[AUNADOC]: Documento de la fundacin AUNA sobre tecnologas para interconexin de Home
Networks
[Link]
[BARKIDSUPM]: Documento de presentacin del proyecto BarkIDS realizado por la Universidad
Politcnica de Madrid
[Link]
[CIDERO]: Sitio web oficial del proyecto Cidero
[Link]
[CYBERGARAGE]: Sitio web oficial del dominio CyberGarage
[Link]
[COITTDOC]: Nota informativa del COITT (Colegio
Telecomunicaciones) sobre el baremo de honorarios
[Link]

Oficial

de

Ingenieros

Tcnicos

[COMPERE]: Pgina web de la aplicacin Compre

[Link]
[ECLIPSE]: Sitio web oficial del proyecto Eclipse
[Link]
[EQUINOX]: Sitio web oficial del proyecto Equinox
[Link]
[EXPEDITOR]: Pgina web oficial de IBM para Lotus Expeditor
[Link]
[FELIX]: Sitio web del proyecto Felix
[Link]
[FMJ]: Sitio web oficial del proyecto FMJ
[Link]
[FOBS]: Sitio web oficial del proyecto FOBS de Omnividea (codec plug-in JMF)
[Link]
[GMRENDER]: Sitio web oficial de la aplicacin GMediaRender
[Link]
[JAVAFX]:
Sitio web oficial de Sun Microsystems para JavaFx
[Link]
Documento JavaFx y JMC redactado por la conferencia JavaOne de Sun Microsystems
[Link]
Documento JavaFx, JMC y estado actual de la librera JMF redactado por la conferencia
JavaOne de Sun Microsystems
[Link]
[JDK1.6]: Sitio web oficial de Sun Microsystems para la versin 6 de la Java SE
[Link]
[JDK1.7]: Sitio web sobre el proyecto de desarrollo de la versin 7 de la Java SE
[Link]

125

de

ANEXO VII: Bibliografa

[JFFMPEG]: Sitio web oficial del proyecto Jffmepg (codec plug-in JMF)
[Link]
[JMC]:
Documento JavaFx y JMC redactado por la conferencia JavaOne de Sun Microsystems
[Link]
Documento JavaFx, JMC y estado actual de la librera JMF redactado por la conferencia
JavaOne de Sun Microsystems
[Link]
[JMF]: Sitio web oficial de Sun Microsystems para JMF
[Link]
[JMFCUSTOMRTP]: Pgina web de Sun Microsystems para la solucin RTPConnector
[Link]
[JMFFORO]: Seccin para JMF del Foro de Sun Microsystems
[Link]
[JMFGUIA]: Gua oficial del API de JMF
[Link]
[JMFOUT]: Documento JavaFx, JMC y estado actual de la librera JMF redactado por la conferencia
JavaOne de Sun Microsystems
[Link]
[JVLC]:
Sitio web oficial del proyecto VideoLan para JVLC
[Link]
Sitio web del proyecto JVLC
[Link]
[KNOPFLERFISH]: Sitio web del proyecto Knopflerfish
[Link]
[MAINTAINJ]: Sitio web oficial de la aplicacin MaintainJ
[Link]
[MPLAYER]: Sitio web oficial de la aplicacin MPlayer
[Link]
[MP3PLUG-IN]: Pgina web de Sun Microsystems para el MP3 codec plug-in de JMF
[Link]
[NERO]: Pgina web de la aplicacin Nero9
[Link]
[NEWTON]: Sitio web oficial del proyecto Newton
[Link]
[OSGi]: Sitio web oficial de OSGi
[Link]
[OSGiAPUNTES]: Apuntes de la asignatura Presentacin Multiplataforma del tercer curso de
Ingeniera Tcnica de Telecomunicaciones (esp. Sonido e Imagen) de la Universidad Carlos III de
Madrid (curso 2007/2008)
[OSGiCASADOMO]: Documento informativo sobre OSGi de la revista digital CASADOMO
[Link]

126

ANEXO VII: Bibliografa

[OSGiSERVICES]: Seccin del sitio oficial de OSGi sobre la tecnologa

[Link]
[OSGiSPECIFIC]: Pgina web del sitio oficial de OSGi para la descarga de los documentos de la
especificacin 4 de la plataforma
[Link]
[POCKETPLAYER]: Pgina web de la aplicacin Pocket Player 4
[Link]
[POWERCINEMA]: Pgina web de la aplicacin PowerCinema 6
[Link]
[PROSYST]: Sitio web oficial del proyecto PROSYST
[Link]
[SDE]: Pgina web oficial para la aplicacin Smart Development Environment (SDE)
[Link]
[SDKPLATINUM]: Sitio web de Platinum (UPnP SDK)
[Link]
[SDKLIBUPNP]: Pgina web de libupnp (UPnP SDK)
[Link]
[SUNSCSL]: Licencia SCSL de Sun Microsystems
[Link]
[UMLTUTORIAL]: Tutorial web sobre UML
[Link]
[UPNPAV]: Seccin del sitio web oficial del Foro UPnP para la arquitectura UPnP AV Architecture
[Link]
[UPNPCASADOMO]: Documento informativo sobre UPnP de la revista digital CASADOMO
[Link]
[UPNPDEVARCH]: Documento tcnico sobre la arquitectura de dispositivo de UPnP
[Link]
[UPNPEINDHOVEN]: Documento sobre UPnP de la universidad de Eindhoven University of
Technology
[Link]
[UPNPFORUM]: Sitio web oficial del Foro UPnP
[Link]
[UPNPMUSE]: Documento sobre UPnP titulado The Home Entertainment System based on UPnP
AV Framework de la universidad KyungpookNational University.
[UPNPPROT]: Documento tcnico sobre la tecnologa UPnP realizado por Microsoft
[Link]
[UPNPQOS]: Seccin del sitio oficial del Foro UPnP sobre la especificacin para la calidad de servicio
(QoS)
[Link]
[UPNPSECURITY]: Seccin del sitio oficial del Foro UPnP sobre la especificacin para seguridad
[Link]

127

ANEXO VII: Bibliografa

[VLC]: Sitio web oficial de VideoLan (aplicacin VLC)

[Link]
[WEBEMPLEO]: Sitio web de empleo para autnomos
[Link]
[WMP11: Sitio web oficial de Microsoft para la aplicacin Windows Media Player 11
[Link]
[XBMC]: Sitio web oficial de XBMC Media Center
[Link]

128

ANEXO VIII: Glosario

ANEXO VIII: Glosario

ADPCM
API
AVI
AWT
bps
CD
CPU
DCP
DCPD
CVM
DHCP
DNS
DVD
DVI
FMJ
GENA
GIF
GNU
GSM
GUI
HAVi
HomePNA
HTML
HTTP
HTTPMU
HTTPU
IANA
ID
IDE
IMA
IP
IPv4
IPv6
JAR
JDK
JINI
JMC
JMF
JNA
JPEG
JVM
JVLC
J2ME
J2SE
KVM
LCD
MPEG
MP3
OSGi

Modulacin por codificacin de impulsos diferencial adaptativa (Adaptive

Differential Pulse Code Modulation)
Interfaz de programacin de aplicaciones (Application Programming Interface)
Entrelazado de audio y video (Audio Video Interleave)
Herramientas Abstractas de Ventana (Abstract Window Toolkit)
Bits por segundo
Disco compacto (Compact Disc)
Unidad central de procesamiento (Central Processing Unit)
Protocolo de control de dispositivos (Device Control Protocol)
Documento del protocolo de control de dispositivos (Device Control Protocol
Document)
Mquina virtual compacta (Compact Virtual Machine)
Protocolo de configuracin dinmica de equipos (Dynamic Host Configuration
Protocol)
Sistemas de nombres de dominio (Domain Name System)
Disco digital verstil (Digital Versatile Disc)
Interfaz visual digital (Digital Visual Interface)
Libertad para el multimedia en Java (Freedom for Media in Java)
Arquitectura de notificacin de eventos generales (General Event Notification
Architecture)
Formato de intercambio de grficos (Graphics Interchange Format)
GNU no es Unix (GNUs Not Unix) (acrnimo recursivo)
Sistema global para comunicaciones mviles (Global System for Mobile
communications)
Interfaz grfica de usuario (Graphical User Interface)
Interoperabilidad audiovisual en el hogar (Home Audio Video Interoperability)
Alianza para la redes telefnicas del hogar (Home Phoneline Networking
Alliance)
Lenguaje de marcacin de hipertexto (HyperText Markup Language)
Protocolo de transferencia de hipertexto (HyperText Transfer Protocol)
Transmisin mltiple HTTP (HTTP Multicast)
Transmisin nica HTTP (HTTP Unicast)
Autoridad para la asignacin de nmeros de Internet (Internet Assigned
Numbers Authority)
Identificador (IDentifier)
Entorno de desarrollo integrado (Integrated Development Environment)
Multiplexado inverso sobre ATM (Inverse Multiplexing over ATM)
Protocolo de Internet (Internet Protocol)
Versin 4 del protocolo de Internet (IP version 4)
Versin 6 del protocolo de Internet (IP version 6)
Archivo Java (Java ARchive)
Kit de desarrollo Java (Java Development Kit)
Infraestructura de red inteligente Java (Java Intelligent Network Infraestructure)
Componente Multimedia de Java (Java Media Component)
Entorno de trabajo multimedia Java (Java Multimedia Framework)
Acceso nativo de Java (Java Native Access)
Grupo de expertos en empalme de imgenes (Joint Photographers Experts
Group)
Mquina virtual Java (Java Virtual Machine)
Java VLC
Java 2 edicin micro (Java 2 Micro Edition)
Java 2 edicin estndar (Java 2 Standard Edition)
Mquina virtual basada en el kernel (Kernel-based Virtual Machine)
Pantalla de cristal lquido (Liquid Crystal Display)
Grupo de expertos en imgenes en movimiento (Moving Picture Experts
Group)
MPEG-1 capa 3 (MPEG-1 Layer 3)
Iniciativa de pasarela para sistemas abiertos (Open System Gateway Initiative)

129

ANEXO VIII: Glosario

PC
PCM
PDA
PNG
RAM
RGB
RPC
RTP
RTCP
RTSP
SCPD
SCSL
SDK
SID
SOAP
SSDP
SSL
SUN
TCP
TIFF
TTL
UDP
UML
UPC
UPnP
URI
URL
URN
USB
USN
UUID
VLC
WAV
XML
XP

Ordenador personal (Personal Computer)

Modulacin por impulsos modificados (Pulse Code Modulation)
Asistente Digital Personal (Personal Digital Assistant)
Grficos porttiles de red (Portable Network Graphics)
Memoria de acceso aleatorio (Random Access Memory)
Rojo Verde Azul (Red Green Blue)
Llamada de procedimiento remoto (Remote Procedure Call)
Protocolo de transporte en tiempo real (Real-Time Transport Protocol )
Protocolo de control en tiempo real (Real Time Control Protocol)
Protocolo de transferencia de flujos en tiempo real (Real Time Streaming
Protocol)
Definicin del protocolo de control de servicio (Service Control Protocol
Definition)
Licencia para cdigo fuente de la comunidad Sun (Sun Community Source License)

Kit de desarrollo estndar (Standard Development Kit)

Identificador de la subscripcin (Subscription IDentifier)
Protocolo de acceso sencillo a objetos (Simple Object Access Protocol)
Protocolo de descubrimiento sencillo de servicios (Simple Service Discovery
Protocol)
Capa de seguridad del socket (Secure Socket Layer)
Red universitaria de Standford (Stanford University Network)
Protocolo de control de transmisin (Transmission Control Protocol)
Formato de archivo de imgenes con etiquetas (Tagged Image File Format)
Tiempo de vida (Time-To-Live)
Protocolo de datagramas de usuario (User Datagram Protocol)
Lenguaje unificado de modelado (Unified Model Language)
Cdigo de producto universal (Universal Product Code)
Conectar y usar universal (Universal Plug and Play)
Identificador de recurso uniforme (Uniform Resource Identifier )
Localizador de recurso uniforme (Uniform Resource Locator)
Nombre de recurso uniforme (Uniform Resource Name)
Bus serie universal (Universal Serial Bus)
Nombre de serie nico (Unique Serial Name)
Identificador nico universal (Universal Unique IDentifier)
Cliente VideoLan (VideoLan Client)
Formato de audio de forma de onda (Waveform Audio Format)
Lenguaje de marcado extensible (eXtended Markup Language)
Programacin extrema (Extreme Programming)

130