Universidad Politcnica de Madrid

Escuela Tcnica Superior de Ingenieros de Telecomunicacin

DISEO DE UN SISTEMA DE COMUNICACIONES

EN TIEMPO REAL EN LA WEB Y SU
ESCALABILIDAD EN EL CLOUD

TRABAJO FIN DE MSTER

lvaro Alonso Gonzlez

2013

Universidad Politcnica de Madrid

Escuela Tcnica Superior de Ingenieros de Telecomunicacin

Mster Universitario en
Ingeniera de Redes y Servicios Telemticos

TRABAJO FIN DE MSTER

DISEO DE UN SISTEMA DE COMUNICACIONES

EN TIEMPO REAL EN LA WEB Y SU
ESCALABILIDAD EN EL CLOUD

Autor
lvaro Alonso Gonzlez
Director
Joaqun Salvacha Rodrguez
Departamento de Ingeniera de Sistemas Telemticos
2013

Resumen
Los sistemas de videoconferencia han sufrido un gran impulso en los ltimos aos.
El desarrollo de las comunicaciones de datos inalmbricas as como la abundancia de
dispositivos mviles de cada vez mayor potencia y capacidades multimedia ha
propiciado que la popularidad de las comunicaciones en tiempo real a travs de
Internet aumente considerablemente.
Entre estos avances destaca, dentro del marco del estndar HTML5, la irrupcin del
estndar WebRTC, que permite realizar comunicaciones de este tipo directamente
entre navegadores web. Entre sus posibles usos destaca la comunicacin de voz y
vdeo como streaming y videoconferencias y los juegos online.
En este Trabajo Fin de Mster se describe el proyecto Licode, una plataforma para
proveer comunicaciones en tiempo real en la web. Licode est diseado para poder
instalarse en cualquier infraestructura y est puramente orientado al Cloud. De esta
forma podr ofrecerse un servicio escalable y que ahorrar costes gracias a un uso
eficiente de los recursos.
La descripcin del sistema incluye el diseo de su arquitectura y la descripcin de la
funcionalidad de cada uno de los mdulos necesarios. Adems se realiza un anlisis
exhaustivo de la conveniencia de desplegar el sistema en infraestructuras Cloud. Este
anlisis describe las principales ventajas que el Cloud provee al sistema as como los
retos ms importantes a los que hay que enfrentarse para conseguir un despliegue
eficiente y efectivo que haga un uso adecuado de los recursos disponibles en cada caso
y acorde a la demanda de los usuarios.

Abstract
Videoconference systems have experimented an important impulse in the last years.
The improvement of the wireless data communication and the increase of the mobile
devices of much more performance and multimedia capabilities have stimulated the
popularity of the real time communications in Internet.
One of these progresses is, inside de HTML5 standard frame, the irruption of the
WebRTC standard that allows us to make real time communications between web
browsers. Its possible uses are voice and video communications, such as streaming or
videonferencing and online video games.
In this document is described the Licode project, a platform to provide real time
communications in the web. Licode is designed to be installed in any computer or
infrastructure and it is totally oriented to the Cloud. This way it offer a scalable service
that saves costs and makes an efficient use of the available resources in the systems.
The project description includes the design of its architecture and the description of
the functionality of each module. It is also made an exhaustive analysis of the
convenience of deploy the system in Cloud infrastructures. This analysis describes the
main advantages that Cloud provides to the system. Also the more important
challenges that must be faced in order to make an efficient and effective deployment by
making an appropriate use of the available resources and accord to the user demand in
the service.

iii

ndice general

Resumen................................................................................................................................... i
Abstract .................................................................................................................................. iii
Siglas ........................................................................................................................................ x
Agradecimientos .................................................................................................................. xii
1 Introduccin ................................................................................................................... 13
1.1 Objetivos .................................................................................................................. 14
1.2 Estructura del documento..................................................................................... 14
2 Estado del arte ............................................................................................................... 16
2.1 Sistemas de videoconferencia en la Web ............................................................ 16
2.1.1 Adobe Flash Player ......................................................................................... 16
2.1.2 VaaS ................................................................................................................... 16
2.1.3 Google Hangouts ............................................................................................ 17
2.1.4 Big Blue Button ................................................................................................ 17
2.1.5 OpenTok ........................................................................................................... 18
2.2 WebRTC................................................................................................................... 18
2.3 Cloud Computing .................................................................................................. 19
3 Arquitectura ................................................................................................................... 21
3.1 Nuve ......................................................................................................................... 23
3.1.1 MAuth ............................................................................................................... 24
3.1.2 API de cliente ................................................................................................... 25
3.1.3 Servidor ............................................................................................................ 29
3.1.4 La Base de Datos ............................................................................................. 33
3.2 Erizo ......................................................................................................................... 34
3.2.1 Wrapper Node ................................................................................................. 35
3.3 Erizo Controller ...................................................................................................... 37
3.3.1 API de Cliente .................................................................................................. 37
v

3.3.2 Servidor ............................................................................................................ 45

3.4 La configuracin de Licode .................................................................................. 50
4 Despliegue en el Cloud ................................................................................................ 51
4.1 Oportunidades ........................................................................................................ 51
4.1.1 Escalabilidad a la demanda de usuarios ...................................................... 52
4.1.2 Escalabilidad a los requisitos de la sesin ................................................... 53
4.1.3 Flexibilidad geogrfica ................................................................................... 54
4.2 Retos ......................................................................................................................... 55
4.2.1 Caracterizacin del sistema ........................................................................... 55
4.2.2 Escalabilidad hacia arriba .............................................................................. 59
4.2.3 Escalabilidad hacia abajo ............................................................................... 60
4.2.4 Distribucin geogrfica .................................................................................. 61
5 Resultados ...................................................................................................................... 63
5.1 El proyecto de cdigo libre ................................................................................... 63
5.2 La comunidad ......................................................................................................... 64
5.3 Proyectos ................................................................................................................. 64
5.3.1 FI-WARE .......................................................................................................... 64
5.3.2 Telefnica Espaa MSC5 ................................................................................ 64
5.4 Investigacin ........................................................................................................... 65
6 Conclusiones .................................................................................................................. 66
6.1 Trabajo futuro ......................................................................................................... 66
Bibliografa ........................................................................................................................... 69

vi

ndice de figuras
Figura 1. Arquitectura del sistema .................................................................................... 21
Figura 2. Topologas de red ............................................................................................... 35
Figura 3. Ejemplo de intercambio de eventos ................................................................. 44
Figura 4. Varias MCUs ........................................................................................................ 54
Figura 5. Distribucin geogrfica de MCUs .................................................................... 55
Figura 6. Uso de CPU en Streaming ................................................................................. 56
Figura 7. Uso de ancho de banda en Streaming .............................................................. 57
Figura 8. Uso de CPU en Videoconferencia..................................................................... 58
Figura 9. Uso de ancho de banda en Videoconferencia ................................................. 58
Figura 10. Proxy ................................................................................................................... 61

vii

ndice de tablas
Tabla 1. Interfaz Nuve API. Inicializacin ....................................................................... 26
Tabla 2. Interfaz Nuve API. Salas ...................................................................................... 27
Tabla 3. Interfaz Nuve API. Usuarios ............................................................................... 27
Tabla 4. Interfaz Nuve API. Servicios ............................................................................... 28
Tabla 5. Interfaz Nuve API. Tokens .................................................................................. 29
Tabla 6. API REST Nuve ..................................................................................................... 31
Tabla 7. Interfaz Erizo Controller API. Stream ............................................................... 39
Tabla 8. Interfaz Erizo Controller API. Room ................................................................. 41
Tabla 9. Interfaz Erizo Controller API. Event .................................................................. 43
Tabla 10. Configuracin Licode ......................................................................................... 50

ix

Siglas
API

Application Programming Interface

DOM

Document Object Model

DTLS

Datagram Transport Layer Security

GING

Grupo de Internet de Nueva Generacin

HTML

Hiper Text Murkup Lenguage

HTTP

Hiper Text Transport Protocol

HMAC

Hash Message Authentication Code

IaaS

Infraestructure as a Service

ICE

Interactive Connectivity Establishment

IETF

Internet Engineering Task Force

IP

Internet Protocol

JSON

JavaScript Object Notation

MCU

Multipoint Control Unit

NAT

Network Address Transversal

NoSQL

Not only SQL

PaaS

Platform as a Service

REST

Representactional State Transfer

RIA

Rich Internet Application

RPC

Remote Procedure Call

RTCP

Real-time Transport Control Protocol

RTMP

Real-time Transport Message Protocol

RTP

Real-time Trasport Protocol

RTT

Round Trip delay Time

SaaS

Service as a Service
x

SDP

Session Description Protocol

SHA1

Secure Hash Algorithm

SRTP

Secure Real-time Transport Protocol

URL

Uniform Resource Locator

WebRCT

Web Real Time Communications

W3C

World Wide Web Consortium

xi

Agradecimientos
El proyecto Licode ha sido diseado y desarrollado junto a mis compaeros Javier
Cervio y Pedro Rodrguez. Se ha realizado en el marco de desarrollo de proyectos de
investigacin del Grupo de Intenet de Nueva Generacin (GING) bajo la direccin del
Juan Quemada y Joaqun Salvacha.

xii

1 Introduccin
En el Grupo de Internet de Nueva Generacin de la Universidad Politcnica de
Madrid, se ha trabajado en sistemas y aplicaciones de videoconferencia entre mltiples
usuarios desde hace ms de 20 aos.
En un principio, estos programas de videoconferencia eran complejos programas
difciles de instalar y gestionar, especialmente para usuarios sin perfil tcnico. Esto
supona una barrera de entrada que se sumaba a la disponibilidad de ancho de banda y
la potencia de los terminales, en aquel momento, casi exclusivamente ordenadores de
sobremesa.
La videoconferencia ha sufrido un gran impulso en los ltimos aos. El desarrollo
de las comunicaciones de datos inalmbricas as como la abundancia de dispositivos
mviles de cada vez mayor potencia y capacidades multimedia ha propiciado que la
popularidad de las comunicaciones en tiempo real a travs de internet aumente
considerablemente.
Entre estos avances destaca, dentro del marco del estndar HTML5, la irrupcin de
WebRTC. WebRTC es un estndar que est siendo definido en colaboracin entre el
W3C (World Wide Web Consortium) y el IETF (Internet Engineering Task Force) para
permitir la comunicacin en tiempo real directamente entre navegadores. Entre sus
posibles usos destaca la comunicacin de voz y vdeo y los juegos. WebRTC es una
tecnologa inherentemente peer to peer donde nicamente se requiere un servidor Web
para establecer la comunicacin inicialmente mediante el intercambio de los mensajes
de sealizacin.
No obstante, para casos avanzados de videoconferencia tales como: conversaciones
con muchos participantes, clases distribuidas o eventos que necesiten grabacin, es
necesaria la existencia de un nodo central que reciba toda la comunicacin procedente
de los usuarios, la trate de la manera adecuada y la reenve si es necesario. Este
componente central, adems de ser un desarrollo nuevo, requiere que el sistema tenga
cierta inteligencia, sobre todo a la hora de reaccionar frente a cambios dinmicos en la
demanda.

13

1.1 Objetivos
El objetivo planteado en este Trabajo Fin de Mster es el de disear la arquitectura y
funcionalidad de Licode. Licode, diseado e implementado en el marco de desarrollo
de proyectos del Grupo de Investigacin, es una plataforma de comunicaciones en
tiempo real en la web. Estas comunicaciones incluyen servicios de streaming,
videoconferencia entre muchos usuarios y transmisin de datos en tiempo real. Estn
enteramente basadas en el nuevo estndar de la web HTML5 y WebRTC (Web RealTime Communications). Adems gracias a Licode podrn realizarse funcionalidades
avanzadas como grabacin de las sesiones o transcodificacin para la adaptacin a
terminales mviles y tablets.
De esta forma cualquier desarrollador web que quiera incluir comunicaciones de
este tipo en sus servicios y aplicaciones web podr hacerlo de forma rpida y sencilla
utilizando las APIs que Licode ofrece. Pero adems podr controlar totalmente todos
los aspectos relacionados con el servicio ya que tiene la posibilidad de desplegar el
servicio en sus propias infraestructuras.
Por ltimo Licode estar orientado a su despliegue en infraestructuras Cloud de
manera que se pueda aprovechar las grandes ventajas que ofrecen este tipo de
despliegues. Estas ventajas estn relacionadas con la escalabilidad del sistema frente a
cambios dinmicos en la demanda por parte de los usuarios y frente a los distintos
tipos de escenarios que pueden ser necesarios para las diferentes aplicaciones
realizadas con Licode.
Para su diseo y desarrollo deber estudiarse las caractersticas de cada mdulo y
establecer las tecnologas que mejor permiten su implementacin.

1.2 Estructura del documento

Este documento est dividido en cinco captulos:
1. Introduccin: es el captulo en el que nos encontramos. En l se hace breve
descripcin del problema que quiere resolverse y por lo tanto de los objetivos de
este Trabajo Fin de Mster. Adems se realiza una visin general de la estructura
del documento y sus diferentes captulos.

14

2. Estado del arte: en este captulo se realiza una descripcin del estado actual de
algunas tecnologas, estndares y productos de relevancia o estrechamente
relacionados con el tema que se trata en este Trabajo Fin de Mster.
3. Arquitectura: es el captulo central de este documento. En l se describe a
arquitectura general del sistema y se realiza una descripcin exhaustiva de cada
uno de sus mdulos explicando su diseo, funcionalidad y las relaciones con el
resto.
4. Despliegue en el Cloud: en este captulo se hace una descripcin de la
conveniencia de desplegar un sistema como Licode en una infraestructura
Cloud. Adems se analizan los retos que este despliegue plantea y que se
abordarn como trabajos futuros.
5. Resultados: en este captulo se comentan los resultados que se han obtenido o
piensan obtenerse a partir del desarrollo de Licode. Esto incluye los proyectos
del departamento en que se ha utilizado, las lneas de investigacin surgidas y la
comunidad de software libre creada a su alrededor.
6. Conclusiones: ltimo captulo del documento en el que se explican las
conclusiones del trabajo as como los trabajos futuros a realizar a partir de este
momento.

15

2 Estado del arte

En este captulo se hace una descripcin de algunas de las tecnologas que tienen
relacin con el trabajo realizado y por lo tanto con el proyecto de comunicaciones en
tiempo real en la web Licode.

2.1 Sistemas de videoconferencia en la Web

En esta seccin se analizan algunas tecnologas o servicios existentes para ofrecer
comunicaciones de tiempo real en aplicaciones web.

2.1.1

Adobe Flash Player

Adobe Flash es una plataforma RIA propietaria para aadir funcionalidades

interactivas a las aplicaciones web tales como animaciones, vdeo, audio, etc. Flash
Player tiene soporte para un lenguaje de programacin interpretado conocido
como ActionScript basado en el estndar ECMAScript. Desde su origen ActionScript ha
pasado de ser un lenguaje muy bsico a un lenguaje avanzado con soporte de
programacin

orientada

objetos,

comparable

en

funciones

uso

al

lenguaje JavaScript.
Originalmente creado para mostrar animaciones vectoriales en 2 dimensiones, ha
pasado a utilizarsepara crear aplicaciones Web que incluyen flujo de audio y video e
interactividad. La utilizacin de grficos vectoriales le permite disminuir el ancho de
banda necesario para la transmisin y, por ende, el tiempo de carga de la aplicacin.
Actualmente Flash Player est disponible para las versiones ms recientes de los
navegadores ms populares (Internet Explorer,Mozilla Firefox, Safari, Opera, etc.). El
navegador Google Chrome no lo necesita porque viene incluido dentro de l.

2.1.2

VaaS

Vaas es un servicio de videoconferencia desarrollado por este mismo departamento.

Se trata de un servicio multipunto en la nube basado en Isabelv5 que se apoya en un

16

servidor que de acceso a clientes tanto desde PC fijo/porttil, como desde terminales
mviles.
El servidor de multivideoconferencia es capaz de interconectar PCs con terminales
mviles, con acceso en ambos casos a travs de navegador Web y sin necesidad de
instalar aplicaciones. El sistema tiene las siguientes caractersticas:
1. El servidor se realiza adaptando Isabelv5, el gateway flash y otras tecnologas
asociadas para soportar los siguientes terminales en la videoconferencia:
A. PC con navegador con soporte de video Flash. B. Terminal mvil capaz de emitir
y recibir video en HTML5. C. Terminal mvil tipo iPad capaz de emitir y recibir video
en HTML5.
2. Capacidad para soportar varias multiconferencias simultneas e independientes.
El nmero mximo de participantes se determinar en funcin de las caractersticas del
servidor.
3. El sistema incluye una gestin mnima de multiconferencias.
4. El sistema incluye la gestin de estadsticas de cdecs, uso de CPU, uso de BW,
resolucin, etc.

2.1.3

Google Hangouts

Google Hangouts un servicio de multiconferencia de Google que opera en web. No

obstante tambin tiene disponible aplicaciones mviles aunque en este caso no soporta
multiconferencia.
La versin web soporta hasta diez participantes de manera simultnea en la misma
conversacin. Adems permite compartir vdeos de Youtube en las conversaciones.

2.1.4

Big Blue Button

BigBlueButton es una aplicacin web open source para videoconferencia y elearning o educacin a distancia. Es un programa distribuido bajo licencia GNU y que
ha surgido de la reutilizacin de proyectos varios como Asterisk, Flex SDK, Red5,
MySQL y otros.

17

Pero adems, BigBlueButton ofrece algunas caractersticas adicionales como la

posibilidad de que sus usuarios suban archivos PDF o documentos de texto y hojas de
clculo. Ofrece tres roles en sus videoconferencias
-

Presentador, que puede subir presentaciones y compartir su escritorio.

Espectador, que no tiene autoridad en la videoconferencia y solo puede ver o

chatear.

Moderador, que puede subir presentaciones, compartir su escritorio y aceptar o

expulsar usuarios.

2.1.5

OpenTok

OpenTok provee un API libre que permite a cualquier desarrollador web introducir
caractersticas de chat y vdeo en grupo a sus sitios web. La plataforma est basada en
la tecnologa Adobe Flash y permite a los usuarios realizar sesiones de
videoconferencia con chat y vdeo en vivo de hasta 20 participantes. Permite realizar
invitaciones para usar el servicio a travs de cuentas en las redes sociales Twitter,
Facebook o MySpace.

2.2 WebRTC
WebRTC [A. Bergkvist et al. 2012] [S. Loreto et al. 2012] es un estndar en desarrollo
por el Internet Engineering Task Force (IETF) y el World Wide Web Consortium (W3C)
que pretende definir un framework, protocolos e interfaces de programacin que
proveern comunicaciones interactivas y en tiempo real de audio, video y datos a las
aplicaciones en los navegadores web.
Como se explica en [C. Jennings et al. 2013], la arquitectura en las aplicaciones
WebRTC son peer-to-peer de tal forma que nicamente es necesario un servidor
externo a los navegadores de los clientes para establecer la comunicacin
intercambiando los mensajes de sealizacin al comienzo de la misma. Los APIs de los
que consta el protocolo son los siguientes:
-

GetUserMedia: se utiliza para acceder a los recursos multimedia del usuario

como su cmara o su micrfono. El resultado ser un MediaStream.

18

MediaStream: es un conjunto de pistas de flujos de audio o vdeo con los

recursos multimedia del usuario.

RTCPeerConnection: representa un canal de conexin con otro cliente. Un

cliente aade a un RTCPeerConnection uno o ms MediaStreams para
compartirlos con el otro cliente.

Al aadir uno de estos MediaStreams a la conexin comienza la negociacin con el

otro cliente mediante la cual se negocian ciertos parmetros de la sesin como el
formato de los datos (cdecs de audio y vdeo), la resolucin o el ancho de banda. Esta
negociacin debe realizarse mediante medios externos al protocolo y consiste en el
intercambio de unos mensajes SDP del tipo offer/answer.
El protocolo implementa ICE para poder realizar la conexin en escenarios en los
que los clientes se encuentren tras un NAT. Una vez establecida la conexin el
transporte de datos se realiza sobre SRTP [M. Baugher et al. 2004], la versin segura de
RTP y gracias a RTCP los clientes pueden obtener feedback sobre el estado de la
conexin, las posibles prdidas, etc. Adems para la gestin de claves de SRTP se
utiliza el protocolo DTLS-SRTP, una extensin de DTLS.
En la fecha en que se escribe este documento los navegadores en los que WebRTC
est completamente soportado son Google Chrome y Mozilla Firefox en sus versiones
de escritorio y Google Chrome en su versin para el sistema operativo Android.

2.3 Cloud Computing

Cloud Computing [Mell et al. 2011] es un modelo para proveer acceso bajo demanda
a recursos de computacin como redes, servidores, almacenamiento, aplicaciones y
servicios de forma configurable y a travs de la red.
Las caractersticas del modelo de Cloud Computing son las siguientes:
.

On-demand self-service: Los usuarios pueden disponer de capacidades de

computacin (CPU, ancho de banda, almacenamiento, etc.) segn lo necesiten.

Broad network access: Estas capacidades estn disponibles en la red en diferentes

posiciones y son servidas a travs de mecanismos estndar.

Resource pooling: El Cloud sigue un modelo multi-tenant por el cual pueden

asignarse recursos a diferentes usuarios.

19

Rapid elasticity: Las capacidades pueden ser provistas y liberadas de forma

automtica para adaptarse a la demanda de los usuarios.

Measured service: Los recursos son controlados de forma automtica y

monitorizados y reportados por mecanismos de medida.

Algunos de los proveedores de Infraestructuras Cloud (IaaS) existentes en la fecha

en que se escribe este documento son los siguientes:

Amazon AWS

RackSpace

CloudSigma

Windows Azure

GoGrid

Terremark vCloud

Joyent

20

3 Arquitectura
En esta seccin se explica la arquitectura general de este sistema, Licode. Los
diferentes mdulos que son necesarios para montar un servicio Licode, la funcin y
caractersticas de cada uno de ellos y sus relaciones.
En la Figura 1 puede observarse la arquitectura del sistema.

Figura 1. Arquitectura del sistema

Los mdulos que conforman esta arquitectura son los siguientes:

-

Nuve
Es el mdulo que se encarga de la gestin de los recursos que son necesarios en
una sesin multimedia como salas, usuarios, etc. Consta de una parte servidor
que se arrancar como un proceso Node y que recibir peticiones REST de la
parte cliente que se incorporar como parte de los servidores web de las

21

aplicaciones que utilicen Licode. Para la persistencia de los datos utiliza una
base de datos MongoDB.
-

Erizo
Es la MCU del sistema. Se encarga de redireccionar los flujos multimedia de
unos clientes a otros.

Erizo Controller: Es el controlador de Erizo. Realiza este control a travs de un

wrapper que adapta los diferentes lenguajes de programacin utilizados.
utilizados. Adems dispone de una parte de cliente con la que se comunica a
travs de websockets. Esta parte cliente ser la que los navegadores web cargen
en sus aplicaciones para realizar acciones sobre una sala multimedia controlada
por Erizo Controller.

Como puede observarse en la figura en un servicio Licode puede haber ms de una

MCU (Erizo + Wrapper + Erizo Controller). De esta forma el sistema ser escalable
dependiendo de el nmero de usuarios que lo utilicen. La gestin de todos los Erizos
arrancados la llevar Nuve ya que se comunica con los Erizo Controller a travs de un
bus de mensajes RabbitMQ mediante llamadas a procedimiento remoto (RPC). En cada
uno de los apartados de esta seccin se explican las interfaces de estas llamadas a
procedimiento remoto.
Un ejemplo comn de uso de Licode es el de un usuario conectndose a una sla de
videoconferencia y publicando su video y audio en ella. Para ello cuando desea
conectarse a la sala desde una aplicacin web (Web App) la aplicacin pedir a su
servidor web un token de autenticacin. El servidor web (Server App) utilizando Nuve
Client se lo pedir a Nuve. Nuve lo generar y almacenar en la base de datos. Con
este token de autenticacin y utilizando Erizo Client el navegador web se conectar a
Erizo Controller que validar el token contra Nuve a travs del bus de mensajes (con
una llamada a procedimiento remoto). Si el token es correcto Erizo Controller
configurar Erizo y comenzar a publicar los datos usando la MCU.
Este sera un ejemplo resumido y simplificado de funcionalidad bsica en Licode.
No obstante las posibilidades son mucho ms amplias y complejas. En las secciones
siguientes se explica de manera detallada cada uno de los mdulos de esta arquitectura
y las comunicaciones entre ellos.

22

3.1 Nuve
Nuve es el mdulo que se encarga de gestionar todos los componentes que
intervienen en las sesiones multimedia de Licode. Estos componentes son:
-

Salas
Una sala de videoconferencia es un lugar abstracto donde los clientes publican
sus flujos multimedia o donde acuden a suscribirse a los que otros clientes han
publicado en esa sala. Lo que ocurre en una sala es privado y solo pueden
participar en una sala los clientes con permiso explcito para ello.

Usuarios
Un usuario es un cliente que se conecta a una sala y publica o se suscribe a los
flujos multimedia que otros usuarios han publicado.

Servicios
Un servicio es una aplicacin que utiliza Nuve para la gestin de los recursos
multimedia necesarios en su funcionamiento. Hay un tipo de servicio llamado
super servicio que tiene una serie de privilegios respecto al resto de servicios
como la capacidad de realizar acciones sobre los recursos de tipo servicio como
crearlos o borrarlos.

Tokens
Un token en una ficha proporcionada por nuve a un cliente para que ste pueda
acceder de manera autenticada a una sala de videoconferencia. Es de un solo uso
y adems nicamente vlido durante un periodo de tiempo determinado.

Las aplicaciones web que utilicen Licode utilizarn por lo tanto Nuve para la
gestin de estos recursos. Dispondrn de un servicio en el que podrn crear salas
multimedia a las que darn acceso a los usuarios mediante un token de sesin.
Para ello utilizarn en sus servidores web un API de cliente de Nuve que acceder a
los recursos mediante un API REST. Las peticiones http debern estar autenticadas
utilizando un protocolo diseado en este departamento especficamente para Nuve. Se
trata de MAuth. Adems para proveer de persistencia al sistema, Nuve utilizar una
base de datos.
A continuacin se explica con detalle cada uno de estos componentes, el protocolo
MAuth, el API de cliente de Nuve, el servidor REST, y la estructura de la base de datos.
Tambin la comunicacin del servidor Nuve con el componente Erizo Controller.
23

3.1.1

MAuth

Como se ha explicado anteriormente MAuth es un protocolo de autenticacin para

los mensajes http que atacarn el API REST de Nuve. De cara a la autenticacin http se
sigue un esquema parecido otros protocolos como OAuth [OAuth] , es decir, una
extensin de la cabecera estndar de autenticacin de http. De una manera parecida a
este protocolo, la cabecera se usa tanto para proporcionar la autenticacin como para
pasar parmetros en los casos que sea necesario.
As un ejemplo de cabecera de autorizacin de http que los servicios deben utilizar
de cara a poder realizar peticiones a Nuve es la siguiente:
Authorization: MAuth realm=http://xxxxx.es,
mauth_signature_method=HMAC_SHA1,
mauth_serviceid=ServiceName,
mauth_signature=jlsa731232=,
mauth_timestamp=1231321321,
mauth_cnonce=123123aadf,
mauth_version=3.1,
mauth_username=user,
mauth_role=participant

A continuacin se explican los parmetros uno a uno:

-

mauth_signature_method: Indica el mtodo usado para firmar la peticin.

Actualmente el nico soportado es HMAC- SHA1. Para la generacin de la
firma se utiliza una clave simtrica que conocen tanto el servicio como Nuve y
que se intercambia a travs de otro canal.

mauth_serviceid: Es un identificador nico de cada servicio, utilizado por Nuve

para conocer la clave con la que debe calcular la firma y, adems, para asociar
con l tanto las salas creadas como los usuarios aadidos.

mauth_signature: La firma generada mediante el mtodo sealado ms arriba.

24

mauth_timestamp: Por defecto, el nmero de segundos desde el uno de enero de

1970. Es obligatorio que sea un entero positivo y debe ser igual o mayor que el
de anteriores peticiones.

mauth_cnonce: Un nmero entero positivo aleatorio que hay que asegurar que
cambie entre peticiones con un mismo timestamp. As se protege frente ataques
de replay.

mauth_version: Nmero de versin actual de la autorizacin. Actualmente se

utiliza 3.1.

Hasta aqu los parmetros obligatorios en cada peticin, los dos siguientes son
especiales ya que nicamente se utilizan en aquellos casos en los que se pretende
solicitar el acceso a una sala para un usuario.
-

mauth_username: Nombre del usuario que se desea que entre en la sala de

conferencia.

mauth_role: Rol que ejercer dicho usuario dentro de la conferencia. Se utilizarn

para diferencian la capacidad de control que tienen sobre el desarrollo de la
conferencia.

La cadena con la que se obtiene la firma variar dependiendo de los parmetros que
se incluyen en la cabecera. As esta cadena ser:
(mauth_serviceid, mauth_timestamp, mauth_cnonce,
[mauth_username, mauth_role])
Por lo tanto cualquier peticin REST que se realice al servidor de Nuve deber ir
autenticado con los parmetros explicados. Como Licode provee a los servicios web un
API de cliente de Nuve la implementacin de este protocolo ya est incluida en el API
y el desarrollador que lo utilice nicamente deber preocuparse de configurar antes de
realizar cualquier peticin las credenciales del servicio que est utilizando como se
explica en el siguiente apartado.

3.1.2

API de cliente

En la fecha en que se escribe este documento, el API de Nuve est escrito en los
lenguajes de programacin Node.js, Python y Ruby. Por lo tanto puede utilizarse en

25

cualquier servidor web que utilice estos lenguajes en su lgica de servicio. Todos ellos
tienen la misma interfaz de atributos y mtodos, que se pasa a explicar a continuacin.
Inicializacin

Como se ha explicado anteriormente antes de empezar a utilizar cualquier recurso

de Nuve, es decir, antes de realizar cualquier peticin mediante los mtodos
proporcionados en el API, es necesario inicializar con una serie de parmetros que se
utilizarn para la autenticacin de los mensajes.

Inicializacin
init (serviceId, serviceKey, nuve_host)

Tabla 1. Interfaz Nuve API. Inicializacin

Los parmetros que utiliza esta funcin son:

serviceID: identificador del servicio para el que se utilizarn los recursos de

Nuve para esta instancia del API.

serviceKey: clave de acceso a Nuve para este servicio. Se utilizar junto con
el campo anterior para la autenticacin en las cabeceras del protocolo MAuth
segn se ha explicado anteriormente.

nuve-host: direccin donde se encuentra corriendo la instancia de Nuve a la

que se tiene que acceder para utilizar el API REST.

Salas

En la Tabla 2 pueden observarse las propiedades y las funciones o mtodos pblicos

que podrn utilizarse sobre un recurso del tipo sala en el API de Nuve y que se
explican a continuacin.

26

Propiedades

Funciones

Room._id

createRoom (name)

Room.name

getRooms ()
getRoom (roomId)
deleteRoom (roomId)

Tabla 2. Interfaz Nuve API. Salas

_id: es el identificador nico de sala en la base de datos.

name: nombre de la sala

createRoom: crea una sala con el nombre especificado en el servicio.

Devuelve un objeto sala con el identificador de la sala en la base de datos.

getRooms: devuelve una lista de las salas disponibles en el servicio.

getRoom: devuelve una sala especificando su identificador en la base de

datos.

deleteRoom: borra una sala especificando su identificador nico en la base

de datos.

Usuarios

En la Tabla 3 pueden observarse las propiedades y las funciones o mtodos pblicos

que podrn utilizarse sobre un recurso del tipo usuario en el API de Nuve y que se
explican a continuacin.
Propiedades

Funciones

User.name

getUsers (roomId)

User.role

Tabla 3. Interfaz Nuve API. Usuarios

name: nombre del usuario en la sala a la que se ha conectado.

27

role: rol con el que el usuario se ha conectado a una sala.

getUsers: devuelve una lista de los usuarios que estn conectados a una sala
especificada mediante su identificador en la base de datos.

Servicios

En la Tabla 4 pueden observarse las propiedades y las funciones o mtodos pblicos

que podrn utilizarse sobre un recurso del tipo servicio en el API de Nuve y que se
explican a continuacin. Cabe destacar que solamente un servicio del tipo super servicio
puede realizar acciones sobre otro servicio.
Propiedades

Funciones

Service_id

createService (name)

Service.name

getServices ()

Service.key

getService (servideId)

Service.rooms

deleteService (serviceId)

Tabla 4. Interfaz Nuve API. Servicios

_id: identificador nico del servicio en la base de datos.

name: nombre del servicio.

key: clave del servicio.

rooms: lista de las salas que se han creado en este servicio.

createService: crea un servicio sin salas especificando su nombre. Devuelve

un objeto servicio con su identificador en la base de datos.

getServices: devuelve una lista con los servicios disponibles.

getService: devuelve un objeto servicio especificando su identificador en la

base de datos.

28

deleteService: borra un servicio especificando su identificador de servicio en

la base de datos.

Tokens

En la Tabla 5 pueden observarse las propiedades y las funciones o mtodos pblicos

que podrn utilizarse sobre un recurso del tipo token en el API de Nuve y que se
explican a continuacin.

Propiedades

Funciones
createToken (roomId, name, role)

Tabla 5. Interfaz Nuve API. Tokens

createToken: crea un token para un usuario especificando la sala a la que va

a conectarse mediante su identificador en la base de datos, el nombre que
tendr el usuario en la sala y el rol que desempear en la sala.

3.1.3

Servidor

Se trata del servidor REST que recoge las peticiones enviadas utilizando el API de
Nuve desde los servidores de las aplicaciones web que usan Licode. Su lgica est
escrita utilizando el lenguaje de programacin Node.js. Antes de explicar la interfaz
REST con la descripcin de las acciones posibles sobre los recursos de Nuve es
necesario hablar de un mdulo fundamental en la gestin de la escalabilidad en
Licode. Este mdulo se llama Cloud Handler debido a su futura relacin con el
despliegue en el Cloud que se explicar en otro captulo de este documento.

Cloud Handler

Como se ha explicado en la introduccin de la arquitectura del sistema cuando el

nmero de usuarios o salas de videoconferencia es muy elevado puede ser necesario
29

arrancar ms de una MCU o mdulo Erizo. Cuando un nuevo usuario se conecte a una
sesin y quiera publicar sus datos multimedia en una sala o suscribirse a otros
existentes en ella pedir a Nuve (a travs del servidor de la aplicacin) un token de
conexin. En ese momento Nuve necesitar saber la ubicacin fsica de la MCU que
est gestionando esa sala, es decir, la direccin IP de la mquina donde la MCU est
corriendo. Para ello se utiliza el mdulo Cloud Handler y la IP servir para que el
cliente sepa dnde se encuentra la sala, es decir, con qu mquina debe establecer una
conexin de websockets como se explicar en la seccin dedicada a Erizo.
As Cloud Handler debe llevar un control de los Erizos (que estarn gestionados por
un Erizo Controller cada uno) disponibles y de las salas que gestiona cada una de ellos.
Para ello cuando se arranque un nuevo Erizo en el sistema ste se lo comunicar a
Cloud Handler a travs de una llamada a procedimiento remoto.
Adems cada Erizo Controller enviar a Cloud Handler un mensaje peridico de
Keep Alive para confirmar que ese Erizo sigue corriendo y disponible para gestionar
salas de videoconferencia.
Por ltimo Cloud Handler dispone de una cola ordenada con los Erizos arrancados
en el sistema segn el nmero de salas que gestiona cada uno. As cuando se cree una
nueva sala sabr a qu Erizo debe asignarla. Cada Erizo Controller enviar a Cloud
Handler un mensaje con informacin acerca de su estado. Este estado incluye
parmetros como el nmero de salas o de usuarios que estn activas en la sesin. Los
mensajes de este tipo se enviarn cuando haya un cambio en el estado y servirn para
que Cloud Handler actualice esta cola segn la prioridad de asignacin de salas. La
informacin de este estado se explicar como ms detalle en el la seccin dedicada a
Erizo Controller.

Interfaz REST

En la Tabla 6 puede observarse una relacin de las acciones REST que pueden
realizarse sobre los recursos de Nuve y su correspondencia con las funciones
explicadas anteriormente para el API de cliente.

30

Recurso

Mtodo

Funcin API Cliente

Sala

POST

createRoom

GET

getRooms

GET: room

getRoom

DELETE :room

deleteRoom

GET

getUsers

GET :user

No soportado

DELETE :user

No soportado

POST

createService

GET

getServices

GET :service

getService

DELETE :service

deleteService

POST

createToken

Usuario

Servicio

Token

Tabla 6. API REST Nuve

Al recibir cualquier peticin en primer lugar el servidor comprueba que el mensaje

http est correctamente autenticado segn MAuth. En caso de que no sea correcto
contestar indicando que es necesaria una autenticacin. En caso correcto pasar a
procesar la peticin.
La mayora de estos procesos de peticin nicamente realizarn la peticin indicada
actualizando la base de datos (cuya estructura se explicar en el siguiente apartado) u
obteniendo datos sobre ella. No obstante hay dos peticiones que deben procesarse
haciendo algunas tareas adicionales. Estas peticiones son la de consultar el nmero de
usuarios en una sala (GET al recurso users) y la de crear un token (POST al recurso
token).
Cuando se realiza una peticin de consulta de usuarios en una sala Nuve debe
consultar al Erizo Controller que est gestionando esa sala cuntos usuarios hay
conectados en ese momento a esa sala. Puesto que, como se ha explicado, puede haber
varios Erizo Controllers en primer lugar debe consultarse el registro de los Erizo
Controllers en Cloud Handler para, una vez conocido el que est gestionando esa sala,
realizar una llamada a procedimiento remoto al Erizo Controller consultando el
nmero de usuarios.

31

Cuando se realiza una peticin de creacin de un token para la conexin de un

usuario a una sala Nuve genera un string codificado en base 64 que tiene la siguiente
estructura:
{tokenId: id, host: erizoController host, signature: signature of the token};

tokenId: es el identificador del token en la base de datos de Nuve.

host: la direccin IP de la mquina en la que se encuentra arrancado el Erizo

que gestiona la sala y al que deber conectarse el cliente. Para saberla Nuve
preguntar a Cloud Handler, que lleva un registro de los Erizos arrancados y
las salas que gestionan. En caso de ser una sala nueva decidir en qu Erizo
debe crearse.

signature: es la concatenacin de los dos campos anteriores cifrada

utilizando el algoritmo de cifrado hash SHA1 con la clave del servicio en
Nuve.

El string con estos tres campos se devuelve en la respuesta REST y el token, con el
resto de parmetros que se explicarn en la subseccin dedicada a la base de datos se
almacena.

Interfaz de llamadas a procedimiento remoto

Como se ha explicado en la introduccin tanto Nuve como Erizo Controller

disponen de una interfaz de llamadas a procedimiento remoto RPC para comunicarse
entre ellos a travs de un bus de mensajes sobre el que se ha implementado esta
funcionalidad.
Los mtodos pblicos de los que dispone Nuve estn divididos en los que estn
directamente relacionados con Nuve y los que guardan relacin con el mdulo Cloud
Handler.

deleteToken: cuando un cliente accede a una sala utilizando un token Erizo

Controller debe validarlo en Nuve. Para ello hace una llamada a esta funcin
que comprueba si el token es vlido y lo elimina de la base de datos para que
no pueda volver a utilizarse. El token ser vlido por lo tanto si no ha sido
utilizado anteriormente y si no ha caducado. En cuanto a la comprobacin

32

del cifrado con la clave de Nuve, se realiza en el propio Erizo Controller

como se explicar ms adelante.

addNewErizoController: cuando un nuevo Erizo Controller es arrancado

ejecuta esta funcin para ser aadido en el registro de Cloud Handler.

keepAlive: mensaje de keep alive para indicar que el Erizo Controller sigue
arrancando y ejecutndose sin ningn problema. Si tras un periodo de
tiempo no se reciben mensajes de este tipo de un Erizo Controller se
eliminar del registro en Cloud Handler.

setInfo: funcin para actualizar el estado de un Erizo Controller con

parmetos como el nmero de usuarios o salas activas.

killMe: en caso de que se reciba un mensaje de keep alive de un Erizo

Controller que no exista en el registro (puede ser debido a que se elimin
porque no responda y al paso de un tiempo ha vuelto a responder) deber
procederse a parar su proceso en la mquina en la que estuviera corriendo.

3.1.4

La Base de Datos

Para la persistencia de los datos en Nuve se utiliza una base de datos MongoDB. Se
trata de una base de datos NoSQL orientada a documentos JSON que est escrita en
C++. Utilizando una librera de Node.js puede accederse a la base de datos que guarda
tablas para los recursos sala, servicio y token. As las entradas de la base de datos de
cada uno de los tipos tienen la siguiente estructura:

room
{name: string, _id: ObjectId}

service
{name: string, key: string, rooms: Array[room], _id: ObjectId}

token
{host: string, userName: string'', room: roomId, role: string, service: serviceId,
creationDate: Date(), _id: ObjectId}

33

3.2 Erizo
Erizo es el mdulo que se encarga de la gestin multimedia de las comunicaciones
en Licode. Es la MCU (Multipoint Control Unit) del sistema. Una MCU [WillebeekLeMair et al. 1994] es un componente software utilizado en sistemas multimedia y de
comunicaciones en tiempo real para actuar como mdulo central entre los clientes o
usuarios. De esta manera, como se observa en la Figura 2, puede convertirse una
topologa en malla en la que todos los usuarios se comunican con todos, en una
topologa en estrella donde la MCU acta de nodo central e interconecta a todos los
clientes. Gracias a esta topologa la MCU realiza las siguientes funciones con sus
consecuentes ventajas para el sistema:
1. Redireccin
En una topologa en malla en la que todos los usuarios se comunican con el
resto, cada usuario debe enviar sus flujos multimedia a todos y cada uno de los
clientes y recibir un flujo de cada uno de ellos. En cambio en una topologa en
estrella la MCU actuando como nodo central recibe los flujos de cada cliente y
los distribuye al resto. Esto se traduce en un ahorro considerable de ancho de
banda ya que cada cliente tiene que enviar una nica vez su flujo multimedia a
la MCU.
2. Composicin
La situacin descrita anteriormente mejora an ms si la MCU no enva a cada
cliente un flujo de datos por cada uno del resto de clientes sino que realiza una
composicin resultando en el envo de un nico flujo resultado de la suma del
resto.
3. Transcodificacin
En determinadas ocasiones los clientes que participan en una sesin multimedia
son de naturalezas muy distintas. Por ello resulta interesante que el nodo central
MCU pueda realizar una transformacin de los flujos multimedia para
adaptarlos a las necesidades de cada cliente. Estas necesidades pueden ser de
varios tipos. En ocasiones el formato de los datos con los que es compatible cada
cliente puede variar (cdecs de audio y vdeo por ejemplo). Tambin puede ser
necesario adaptar las calidades a las necesidades de cada cliente. Esto puede ser
debido a que operen en redes con diferentes capacidades de ancho de banda
(redes 3G, WiFi, wired) o simplemente que por las caractersticas del terminal
34

las calidades necesarias sean diferentes (por ejemplo por el tamao de la

pantalla).
4. Grabacin
En las aplicaciones multimedia es muy frecuente que sea necesario realizar una
grabacin

de

las

sesiones

para

almacenarlas

poder

reproducirlas

posteriormente. Para esto es muy til la presencia de una MCU ya que al recibir
los flujos multimedia de todos los participantes podr realizar la grabacin de la
sesin completa (o de una parte de ella) y almacenarla para su posterior uso.

Figura 2. Topologas de red

Erizo por lo tanto es la MCU [P. Rodrguez et al. 2012] del sistema y desde el punto de
vista de WebRTC se comporta como un cliente ms. Por lo tanto Erizo debe
implementar los protocolos necesarios para establecer una comunicacin WebRTC.
Como se explic a principio del documento estos protocolos son ICE y SRTP (con la
extensin DTLS-SRTP para la gestin de claves).
Erizo est escrito en los lenguajes de programacin C y C++ y puesto que el mdulo
superior (Erizo Controller) que se encarga de controlar a gestin de la MCU est
desarrollado utilizando Node.js, es necesario un wrapper que recubra las clases que
sern accesibles desde fuera (y que son las que se explicarn en este documento).

3.2.1

Wrapper Node

Se trata de un mdulo de recubrimiento del ncleo de la MCU Erizo y su nombre es

Erizo API. Gracias a l las clases de Erizo necesarias sern accesibles desde el mdulo
35

de control Erizo Controller. Est desarrollado utilizando las libreras V8 de C++ que a
partir de clases C++ crean interfaces accesibles desde JavaScript.
Las clases que recubre son las siguientes:
-

WebRtcConnection: permite establecer conexiones con los clientes WebRTC. Por

lo tanto se encarga de procesar los SDPs de los clientes web y de generar los
SDPs locales de la MCU. Adems una vez establecida la conexin recibe y enva
los datos multimedia.

ExternalInput: permite establecer conexiones con otro tipo de fuentes

multimedia como cmaras IP, flujos RTMP, etc.

OneToManyProcessor: acta como multiplexador multimedia recibiendo un fujo

de datos y redirigindolo a otros clientes. Su entrada (publisher) por lo tanto es
un objeto WebRtcConnection o ExternalInput que publica un flujo de audio y/o
vdeo y sus salidas (subscribers) son uno o ms objetos WebRtcConnection que
se suscriben a los flujos multimedia.

OneToManyTranscoder:

su

funcin

es

la

misma

que

la

del

OneToManyProcessor con la diferencia de que es capaz de transcodificar los

flujos de audio y vdeo segn ciertos parmetros como cdec, ancho de banda,
frame rate, etc.

36

3.3 Erizo Controller

Erizo Controller es el mdulo que se encarga de controlar Erizo de acuerdo a las
necesidades de los clientes. Maneja tres conceptos fundamentales:
-

Stream: identifica un flujo local o remoto compuesto de vdeo, audio, datos o

varios de ellos.

Sala: representa una sala de Nuve. Es decir, un espacio virtual donde los clientes
pueden publicar sus streams o suscribirse a otros streams.

Token: representa un token de Nuve. Utilizado por un cliente web para

autenticarse en una sala y poder acceder a los streams publicados en ella as
como publicar los propios.

Por lo tanto Erizo Controller se encarga de gestionar tanto la conexin de los clientes
web a las salas de videoconferencia autenticndolos mediante un token contra Nuve
como el manejo de los streams de los clientes en las salas. Un cliente podr publicar sus
streams en una sala o suscribirse a los que previamente otros clientes han publicado.
Desde un punto de vista de la arquitectura Erizo Controller est colocado por
encima del mdulo Erizo y dispone de un API de cliente (Erizo Client) que los clientes
web utilizarn para comunicarse con l a travs de una conexin de websockets.
A continuacin se explica con detalle cada uno de estos componentes, el API de
cliente de Erizo Controller, el servidor y tambin la comunicacin de ste con el
componente Nuve.

3.3.1

API de Cliente

Se trata de un API escrito en el lenguaje de programacin Javascript que las

aplicaciones web que utilicen Licode debern incluir en sus recursos. Con l se pueden
controlar tres tipos de objetos. Objetos tipo Stream para el control de los fujos
multimedia que se publiquen o a los que se suscriba el cliente. Objetos del tipo Room
que gestionan la conexin a una sala multimedia y objetos de tipo Event para la gestin
de eventos sobre Streams o Rooms.
Para la conexin del navegador del cliente con Erizo Controller se utiliza una
conexin de websockets mediante la que se intercambiarn diferentes tipos de
mensajes. Como se explic al hablar de Nuve cuando el cliente quiera conectarse a una
37

sala en el token de conexin estar incluida la direccin IP de la mquina en la que est

corriendo el Erizo Controller correspondiente. As que ser con esa mquina con la que
se establecer la conexin de websockets.
A continuacin se explica con detalle cada uno de estos tipos de objetos as como la
forma de utilizarlos mediante las propiedades y funciones de cada uno de ellos.

Stream

Un objeto de tipo Stream realiza un recubrimiento ampliado del API MediaStream

de WebRTC que adems incluye algunas caractersticas propias de Licode y Erizo
Controller. Representa por lo tanto un flujo multimedia de audio, vdeo, datos o de una
combinacin de cualquiera de ellos. Este flujo multimedia puede ser local o remoto. En
ambos casos si contiene audio o vdeo podr reproducirse o mostrarse su contenido en
un elemento del DOM html de la pgina web del cliente. Si es local este contenido se
obtendr directamente del hardware del cliente (micrfono y webcam) utilizando el
API GetUserMedia de WebRTC.
Puesto que en cada navegador la implementacin de WebRTC es diferente Erizo
Controller posee un adaptador o wrapper que permite que usando siempre la misma
interfaz del API se utilicen unas u otras implementaciones en funcin del navegador.
Adems la deteccin del navegador en la que est corriendo el cliente se realiza de
forma automtica.
En caso de ser de datos el cliente podr enviar datos a utilizando un Stream local o
leer los datos que hay en los Streams remotos. En la fecha en que se escribe este
documento la implementacin de datos en WebRTC no est finalizada por lo que en
Licode la transmisin de datos se realiza a travs de la propia conexin de websockets
entre el navegador y Erizo Controller.
En la Tabla 7 puede observarse tanto la forma de inicializar un objeto de este tipo
tanto las propiedades y funciones de que dispone y cuya funcin se explica a
continuacin.

38

Inicializacin
Erizo.Stream ({audio: boolean, video: boolean, data: boolean, attributes: JSON})

Propiedades

Funciones

showing

hasAudio ()

room

hasVideo ()

local

hasData ()
init ()
getID ()
close ()
show (elementID, options)
hide ()
sendData (msg)
getAttributes ()
getVideoFrame ()
getVideoFrameURL ()
Tabla 7. Interfaz Erizo Controller API. Stream

Al crear un objeto del tipo Stream debe especificarse si contendr audio, datos y
vdeo. Puede contener cualquier combinacin de estos tres. Adems puede incluirse
una lista de atributos en forma de objeto JSON que se utilizar para lo que cada
desarrollador necesite en sus aplicaciones.

showing: propiedad que indica si el vdeo del Stream est mostrndose en

algn elemento de la web.

room: en caso de que el Stream est siendo publicado en una sala, es el

identificador de esa sala.

local: booleano que indica si el Stream es local.

hasAudio: devuelve un booleano indicando si el Stream tiene audio.

hasVideo: devuelve un booleano indicando si el Stream tiene vdeo.

hasData: devuelve un booleano indicando si el Stream tiene datos.

39

init: accede a la informacin multimedia de cliente, cmara y/o micrfono,

mediante el API GetUserMedia. En este momento se pedir al usuario
permiso para acceder a esa informacin. Solamente puede utilizarse sobre
Streams locales. Si el Stream solamente contiene datos esta funcin no
realiza ninguna accin.

getID: obtiene un identificador nico del Stream.

close: detiene el acceso a la informacin multimedia del cliente. En caso de

que el Stream estuviese siendo publicado deja de hacerse. En caso de que el
Stream fuera de vdeo y estuviera mostrndose en un elemento del DOM
deja de hacerse. Al igual que init solamente puede utilizarse sobre un
Stream local.

show: muestra el vdeo del Stream en el elemento del DOM especificado.

Pueden especificarse algunas opciones como el hecho de mostrar o no el
controlador de volumen en el tag de vdeo.

hide: deja de mostrar un Stream previamente mostrado con show.

sendData: enva un objeto JSON a travs de un Stream de datos.

getAttributes: obtiene la lista de atributos con la que se inicializ el Stream.

Se trata de un objeto JSON.

getVideoFrame: obtiene una captura de un Stream de vdeo en forma de

mapa de bits.

getVideoFrameURL: obtiene una captura de un Stream de vdeo y devuelve

la URL donde se encuentra la imagen.

Room

Un objeto de tipo Room representa un sala multimedia de Licode. Gestiona la

conexin del cliente web con Erizo Controller mediante websockets y la forma en que
publican o se suscriben a Streams los usuarios. Para esta publicacin o suscripcin a
Streams deben realizarse conexiones WebRTC entre el navegador y Erizo por lo que el
40

objeto Room utilizar el API PeerConnection del estndar. Al igual que en el caso del
API GetUserMedia se utiliza un recubrimiento que permite la compatibilidad con
distintos navegadores.
El intercambio de los mensajes de sealizacin se realizan a travs de la conexin de
websockets por lo que el objeto Room se encargar tanto del envo de los mensajes
como de escuchar para la recepcin de las respuestas. La conexin tambin se utilizar
para el envo de objetos JSON a travs de Streams de datos.
En la Tabla 8 puede observarse tanto la forma de inicializar un objeto de este tipo
tanto las propiedades y funciones de que dispone y cuya funcin se explica a
continuacin.

Inicializacin
Erizo.Room ({token: string})

Propiedades

Funciones

roomID

connect ()

state

publish (stream)

localStreams

subscribe (stream)

remoteStreams

unpublish (stream)
unsubscribe (stream)
disconnect ()
getStreamsByAttribute (name, value)
Tabla 8. Interfaz Erizo Controller API. Room

Al crear un objeto de tipo Room deber especificarse el token de conexin a la sala

que se habr obtenido a travs del servidor de la aplicacin web (y ste de Nuve
utilizando el API de cliente). En este token est la informacin sobre el host donde se
encuentra corriendo el Erizo Controller que gestiona la sala.

roomID: identificador nico de la sala.

state: estado en el que se encuentra la sala. Puede ser DISCONNECTED

(desconectado), CONECTING (conectando) o CONNECTED (conectado).

41

localStreams: lista con los objetos de tipo Stream locales publicados en la

sala.

remoteStreams: lista con los objetos de tipo Stream remotos publicados en la

sala.

connect: realiza la conexin con la sala. Esto significa establecer la conexin

de websockets y comenzar a escuchar mensajes.

publish: publica un Stream en la sala. En el caso de Streams de vdeo y/o

audio esto implica crear un objeto PeerConnection, realizar el intercambio de
mensajes de sealizacin y comenzar a enviar el flujo multimedia a Erizo a
travs de la conexin SRTP del estndar.

subscribe: se suscribe a un Stream previamente publicado en la sala. En el

caso de Streams de vdeo y/o audio esto implica crear un objeto
PeerConnection, realizar el intercambio de mensajes de sealizacin y
comenzar a reciir el flujo multimedia a Erizo a travs de la conexin SRTP
del estndar.

unpublish: dejar de enviar los datos a la sala. En caso de audio y/o vdeo
implica cerrar el PeerConnection.

unsubscribe: dejar de recibir los datos de este Stream de la sala. En caso de

audio y/o vdeo implica cerrar el PeerConnection.

disconnect: desconectarse de la sala. Esto implica cerrar la conexin de

websockets, dejar de publicar los Streams que se estuvieran publicando y
dejar de recibir los datos de los Streams a los que se estuviera suscrito.

getStreamsByAttribute: obtiene una lista de Streams remotos con la

coincidencia indicada en los parmetros en funcin de los atributos de los
Streams.

Event

Se trata de un objeto especial que representa eventos sobre otros objetos. La forma
de inicializarlos no es relevante en esta descripcin del API ya que se hace
42

internamente en los objetos de tipo Stream y Room. Por lo tanto lo relevante es la

forma en que se aade un listener a un objeto y los tipos de eventos que pueden
recibirse en ese objeto.
En la Tabla 9 puede observarse tanto la forma agregar un listener a un objeto de tipo
Room o Stream.

Funciones
Room.addEventListener (type, function (evt) { });
Stream.addEventListener (type, function (evt) { });

Tabla 9. Interfaz Erizo Controller API. Event

Los tipos de eventos que pueden lanzarse en un objeto de tipo Room son los
siguientes:

room-connected: indica que la conexin con la sala se ha realizado de forma

correcta. El evento incluye un lista de los streams remotos que actualmente
estn publicados en la sala.

room-disconnected: indica que la desconexin con la sala se ha realizado de

forma correcta.

stream-added: indica que un nuevo Stream ha sido publicado en la sala. El

evento incluye el objeto Stream.

stream-removed: indica que un Stream se ha dejado de publicar en la sala. El

evento incluye el objeto Stream.

Los tipos de eventos que pueden lanzarse en un objeto de tipo Stream son los
siguientes:

access-accepted: indica que el usuario ha aceptado el acceso a sus recursos

multimedia (micrfono y/o cmara).

acces-denied: indica que el usuario ha denegado el acceso a sus recursos

multimedia.
43

stream-data: indica que en este Stream de datos se han publicado nuevos

datos. El evento incluye un campo con el objeto JSON que contiene los datos
publicados.

En la Figura 3 puede observarse un ejemplo de intercambio de eventos entre dos

clientes y Erizo Controller.

Figura 3. Ejemplo de intercambio de eventos

A continuacin se explican las acciones que van realizndose por el cliente y los
eventos que estas acciones lanzan, tanto para l mismo como para otros clientes
conectados a la misma sala.
1. Sobre un Stream local se llama a la funcin init de tal forma que el navegador
pedir acceso a su cmara y /o micrfono. En caso de que el usuario acepte se
recibir sobre ese Stream un evento de tipo access-accepted.
2. Sobre un objeto de tipo Room se llama a la funcin connect con lo que se
establece la conexin con Erizo Controller. En caso de que esta accin tenga xito
se recibir sobre ese objeto un evento de tipo room-connected incluyendo la lista
de Streams remotos que hay publicados en la sala.

44

3. Se realiza la accin de suscribirse a uno de estos Streams remotos que contiene

por ejemplo auido y vdeo. Con ello se crea un PeerConnection y se realiza el
intercambio de mensajes con Erizo Controller. Si la conexin se realiza
correctamente se recibe un evento de tipo stream-subscribed y se comienzan a
recibir los datos de tal forma que el cliente puede mostrar el vdeo recibido en
un elemento de la pgina.
4. Se desea publicar un Stream local y se realizan las mismas acciones que en el
caso de la suscripcin. A todos los clientes conectados a la sala les llegar un
evento del tipo stream-added y podrn suscribirse si lo desean.
5. En caso de que otro cliente deje de publicar un Stream a todos los conectados a
la sala les llegar un evento de tipo stream-removed.
6. Por ltimo se envan datos sobre un Stream de datos con lo que a todos los
clientes que estn suscritos a ese Stream les llegar un evento del tipo stream-data
conteniendo los datos que se han enviado.

Erizo Server Client

Como ltima consideracin sobre el API de cliente de Erizo Controller cabe destacar
que tambin est disponible para utilizarse como una librera de Node.js. De esta forma
puede simularse un cliente que ejecutar en cualquier servidor Node y que puede
conectarse a una sala y realizar las mismas acciones que un cliente web utilizando
exactamente el mismo API.
Esto resulta til por ejemplo para publicar flujos multimedia provenientes de otros
medios que no sean la cmara de un cliente como cmaras IP o para publicar datos en
una sala desde un servidor sin necesidad de arrancar un navegador web.

3.3.2

Servidor

Se trata del servidor que escucha los mensajes enviados por los clientes web que
utilizan el API de cliente de Erizo Controller, los procesa y se comunica con Erizo para
realizar las acciones correspondientes en la MCU. Est escrito en el lenguaje de
programacin Node.js por lo que para realizar esta comunicacin con Erizo Controller
es necesario el wrapper o addon de Node para C++ que se explic anteriormente.
45

Adems Erizo Controller se comunicar con Nuve a travs de un bus de mensajes para
realizar llamadas a procedimiento remoto.
En primer lugar y cuando se arranca un Erizo Controller ste se comunica con Nuve
para notificarle que est preparado para comenzar a gestionar salas multimedia de
Licode. Lo hace ejecutando la llamada a procedimiento remoto addNewErizoController
que se explic en la interfaz RPC de Nuve. En esta llamada le indica a Nuve su
direccin IP y cuando Nuve contesta afirmativamente a la peticin Erizo Controller
comienza a enviar los mensajes de keepalive y a escuchar en el puerto de websockets
mensajes de los clientes.
Es importante destacar que Erizo Controller est preparado para ser arrancado en
mquinas de proveedores de cloud pblicos. Actualmente es compatible con el
proveedor de cloud Amazon EC2 [Amazon]. Al arrancar una mquina de esta forma
Erizo Controller le indicar a Nuve esta circunstancia para que Nuve realice una
llamada al API del proveedor consutando la IP pblica de la mquina en la que est
corriendo el Erizo Controller.
Erizo Controller posee una lista con el registro de las salas multimedia que est
gestionando. Este registro inluye un identificador de la sala, una lista de los Streams
publicados en la sala, una lista de los clientes conectados a la sala (a travs del
identificador de su conexin de websockets) una lista con la correspondencia de
suscripciones a Streams en la sala y un objeto WebRtcController.
Un objeto WebRtcController representa una sala multimedia desde el punto de vista
de Erizo. Por lo tanto se utiliza para realizar las acciones necesarias para gestionar la
MCU utilizando la interfaz del wrapper Node de Erizo. As utiliza los objetos
WebRtcCOnnection, ExternalInput, OneToManyProcessor y OneToManyTranscoder
que se explicaron anteriormente y las acciones sobre ellos.
Los mensajes enviados por los clientes que Erizo Controller puede procesar
escuchando en el puerto de websockets son los siguientes:

token: mensaje recibido cuando un cliente se conecta a una sala enviando

un token de autenticacin. Erizo Controller ejecuta una llamada a
procedimiento remoto contra Nuve para verificar que el token es
efectivamente vlido. En caso afirmativo comprueba si la sala es nueva o ya
exista. Si es nueva la registra en su lista de salas creando el objeto
WebRtcController correspondiente. Por ltimo devuelve al cliente una
confirmacin incluyendo la lista de Streams publicados en la sala (si la sala
es nueva esta lista estar vaca). En caso de que el token no sea correcto
devuelve un mensaje de error al cliente web
websockets.
46

y cierra la conexin de

sendDataStream: mensaje recibido cuando un cliente enva datos a travs

de un Stream de datos. Erizo Controller reenva los datos a todos los clientes
que estn conectados a la sala y suscritos a ese Stream. Lo hace a travs del
websocket correspondiente a ese cliente.

publish: mensaje recibido cuando un cliente desea publicar un Stream en

una sala. En caso de que el Stream sea nicamente de datos Erizo Controller
actualiza el registro de Streams y devuelve una confirmacin al cliente. Si
adems tiene algn componente multimedia ejecuta el mtodo addPublisher
del objeto WebRtcController de la sala correspondiente. Esto servir para
que se aada un nuevo OneToManyProcessor en la MCU con fuente el
Stream que se est publicando. Para ello ser necesario el intercambio de
mensajes SDP de negociacin entre Erizo y el cliente web. Una vez acabado
de forma satisfactoria el proceso devolver un mensaje de confirmacin al
cliente. En ambos casos (tanto habiendo componentes multimedia como no)
si el proceso concluye de forma satisfactoria Erizo Controller enviar un
mensaje a todos los clientes conectados a la sala notificando que hay un
nuevo Stream publicado en la misma.

subscribe: mensaje recibido cuando un cliente se desea suscribir a un

Stream de la sala. Al igual que en el caso de publicar si el Stream contiene
solo datos Erizo Controller simplemente actualizar el registro de Streams.
En caso de que contenga componentes multimedia ejecutar el mtodo
addSubsriber del objeto WebRtcController de la sala. Esto implica aadir un
nuevo destino en el OneToManyProcessor correspondiente al Stream
publicado al que se quiere suscribir el cliente. Si la negociacin concluye de
forma satisfactoria Erizo Controller devolver un mensaje de confirmacin al
cliente.

unpublish: mensaje recibido cuando un cliente quiere dejar de publicar un

Stream en una sala. Erizo Controller actualiza su registro de Streams y en
caso de haber componentes multimedia ejecuta el mtodo removePublisher
del objeto WebRtcController. Esto implica cerrar las conexiones SRTP de
todos los clientes que estaban suscritos a ese Stream y eliminar el objeto
OneToManyProcessor de Erizo. Si todo va bien Erizo Controller devuelve un
mensaje de confirmacin al cliente y enva un mensaje a todos los clientes
conectados a la sala indicando que un Stream ha sido eliminado de la sala
para que realicen las acciones que deseen.

47

unsubscribe: mensaje recibido cuando un cliente quiere dejar de

suscribirse a un Stream en una sala. Erizo Controller actualiza su registro de
Streams y en caso de haber componentes multimedia ejecuta el mtodo
removeSubscriber del objeto WebRtcController. Esto implica cerrar la
conexin SRTP de este cliente. Si todo va bien Erizo Controller devuelve un
mensaje de confirmacin al cliente.

disconnect: mensaje recibido cuando un cliente desea desconectarse de la

sala o cuando se produce un fallo en la conexin de websockets de un
cliente. Erizo Controller elimina los Streams que ese cliente estuviera
publicando y a los que estuviera suscrito cerrando sus conexiones SRTP.
Adems cierra las de el resto de clientes de la sala que estuvieran suscritos a
cualquier Stream publicado por este cliente y notifica a todos los clientes de
la sala que un Stream ha sido eliminado. Por ltimo actualiza el registro de
Streams y en caso de que la sala quedase vaca ya que este fuera el nico
cliente conectado la elimina del registro.

Erizo Controller realiza una monitorizacin del estado de carga del Erizo que
controla. Esta monitorizacin tiene en cuenta el nmero de salas que est gestionando.
El desarrollador que configura el sistema puede configurar unos valores de referencia
de carga. Estos valores son dos, uno indica un nmero de salas nivel de warning y el
otro un nmero de salas lmite. En funcin del nmero de salas que estn activas en el
Erizo que controla el estado de carga ser available, warning o notAvailable.

Un estado available indica que el nmero de salas est por debajo del niver de
warning y que por lo tanto el Erizo puede gestionar ms salas si es necesario.

Un estado warning indica que el nmero de salas est entre en nivel de

warning y el nivel lmite y por lo tanto el Erizo no debera gestionar ms
salas.

Un estado notAvailable indica que el nmero de salas ha sobrepasado el nivel

lmite y por lo tanto el Erizo no va a gestionar ninguna sala ms en ningn
caso.

Este estado se enviar a Nuve (concretamente a Cloud Handler) cada vez que vare
a travs de una llamada a procedimiento remoto. De tal modo que Cloud Handler
tomar las acciones que sean oportunas en funcin del estado de los Erizo Controller
arrancados. Cada vez que se realice una accin que implique crear una sala, o
eliminarla Erizo Controller recalcular su estado y en caso de que vare enviar la
actualizacin a Nuve.
48

Interfaz de llamadas a procedimiento remoto

Al igual que el caso de Nuve Erizo Controller dispone de una interfaz de llamadas a
procedimiento remoto RPC para comunicarse con Nuve a travs de un bus de mensajes
sobre el que se ha implementado esta funcionalidad.
Los mtodos pblicos de los que dispone Erizo Controller son los siguientes:

getUsersInRoom: obtiene los usuarios conectados a una sala determinada

consultando la lista de usuarios.

deleteRoom: elimina una sala con todo lo que ello implica. Cerrar las
conexiones de los clientes que estn publicando o suscritos a Streams de la
sala y notificndolo a los clientes.

49

3.4 La configuracin de Licode

Al ejecutar los diferentes mdulos que hacen falta para el funcionamiento de un
servicio basado en Licode y que se han explicado en esta descripcin de su arquitectura
son necesarios algunos parmetros de configuracin. Estos parmetros son utilizados
por los diferentes mdulos para establecer algunas configuraciones en sus
componentes. Se describen en un fichero de configuracin que ser accesible por todos
ellos.
En la Tabla 10 pueden observarse estos parmetros junto con una pequea
descripcin de su funcionalidad.

Componente

Parmetro

Descripcin

RabbitMQ

host

Host en el que corre el servicio

port

Puerto en el que corre el servicio

dataBaseURL

URL de acceso a la base de datos MongoDB

superServiceID

Identificador del sper servicio de Nuve

superServiceKey

Clave del sper servicio de Nuve

stunServerURL

URL del servidor de STUN de los clientes

warning_n_rooms

Nmero de salas warning en un Erizo

limit_n_rooms

Nmero lmite de salas en un Erizo

interval_time_KA

Tiempo de intervalo de mensajes Keep Alive

name

Proveedor de Cloud donde corren los Erizos

host

Identificador de la zona

accessKey

Clave de acceso al proveedor

secretAccesKey

Clave secreta de acceso al proveedor

Nuve

Erizo Controller

Cloud Provider

Tabla 10. Configuracin Licode

50

4 Despliegue en el Cloud
Como se ha explicado en la seccin anterior, la arquitectura de Licode est muy
orientada a su despliegue en el Cloud. Cuando el nmero de usuarios en el sistema es
elevado es necesario arrancar varias instancias de Erizo o MCUs ya que es este mdulo
el que soporta una mayor carga computacional. Pero adems este nivel de carga puede
variar de forma dinmica durante el transcurso de una sesin multimedia.
Los requisitos de este mdulo casan muy bien con el modelo de Cloud Computing
ya que, de acuerdo con la definicin NIST [P. Mell et al. 2009] provee caractersticas de
On- demand self-service, Broad network access, Resource pooling, Rapid elasticity y Measured
service.
En esta seccin van a analizarse las oportunidades que ofrece el despliegue de una
MCU en una infraestructura Cloud y que podrn aplicarse directamente a una MCU
como Erizo. No obstante este despliegue implica tambin ciertos retos a los que hay
que enfrentarse y que tambin se explicarn en esta seccin.
Cabe destacar que la investigacin realizada al respecto se encuentra ya publicada
en un artculo de investigacin [Alvaro Alonso et al. 2013] presentado en el congreso
internacional CLOUD COMPUTING, International Conference on Cloud Computing,
GRIDs, and Virtualization.

4.1 Oportunidades
Un componente MCU puede requerir diferentes caractersticas de computacin en
funcin del nmero de participantes, las condiciones de la sesin (grabacin,
redireccin, transcodificacin, composicin) y la posicin fsica de los participantes.
Adems estas condiciones pueden variar de forma dinmica durante la sesin
multimedia. En una infraestructura Cloud la sesin va a poder adaptarse de forma
sencilla y dinmica a las variaciones de este tipo de condiciones en funcin de los
requisitos de cada momento.
El modelo definido por NIST y citado previamente ilustra estas ventajas que se
explicarn a continuacin:
.

On-demand self-service: Los usuarios pueden disponer de capacidades de

computacin (CPU, ancho de banda, almacenamiento, etc.) segn lo necesiten.

51

Broad network access: Estas capacidades estn disponibles en la red en diferentes

posiciones y son servidas a travs de mecanismos estndar.

Resource pooling: El Cloud sigue un modelo multi-tenant por el cual pueden

asignarse recursos a diferentes usuarios.

Rapid elasticity: Las capacidades pueden ser provistas y liberadas de forma

automtica para adaptarse a la demanda de los usuarios.

Measured service: Los recursos son controlados de forma automtica y

monitorizados y reportados por mecanismos de medida.

4.1.1

Escalabilidad a la demanda de usuarios

Los sistemas multimedia ofrecen a sus usuarios la posibilidad de unirse a una

conferencia antes y durante la sesin. Ellos pueden adems abandonar la sesin
mientras est en curso. Dependiendo del tipo de sesin esta variacin en el nmero de
usuarios puede ser ms o menos frecuente.
Un alto nmero de usuarios normalmente significa ms ancho de banda, consumo
de memoria y CPU. En otras palabras, una MCU demandar ms o menos capacidades
a su infraestructura de computacin en funcin del nmero de usuarios conectados a
una sesin.
En un entorno tradicional el proveedor debera preparar previamente las mquinas
fsicas que dedicara al sistema y stas deberan ser suficientes para poder asumir los
picos de demanda que se produjeran. No obstante esta solucin implica desperdiciar
una alta cantidad de recursos cuando la demanda por parte de los usuarios sea
pequea.
En un entorno Clod, por el contrario, el proveedor puede proveer de forma
dinmica mquinas virtuales y liberarlas cuando no sean necesarias. Esto se suele
realizar normalmente encendiendo o apagando estas mquinas virtuales. dependiendo
de los recursos necesarios, en relacin a los participantes o usuarios que estn
conectados en cada momento.
Esto puede tambin conseguirse incrementando de forma dinmica el rendimiento
de una nica mquina. Podemos por ejemplo incrementar el nivel de CPU o memoria
de una mquina virtual que ya est corriendo. El ancho de banda disponible a la salida
y a la entrada puede tambin modificarse variando el tamao de las mquinas
virtuales. Por ejemplo Amazon EC2 [Amazon] permite diferentes tipos de mquinas
virtuales con diferentes capacidades de rendimiento.
52

4.1.2

Escalabilidad a los requisitos de la sesin

La operacin de una MCU tambin depende del tipo de sesin que est
gestionando. Cada tipo de funcionalidad o tarea que desarrolle requiere diferentes
capacidades de computacin: redireccionamiento de flujos multimedia, composicin
de vdeos, transcodificacin, grabacin de las sesiones, etc.
Un componente MCU bsico solamente redirecciona flujos de un participante al
resto y requiere bajos niveles de computacin. Sin embargo estos niveles (como el uso
de memoria y CPU) aumentan considerablemente si la MCU realiza tareas avanzadas.
La necesidad de realizar estas tareas puede variar de forma dinmica durante el
transcurso de una sesin dependiendo de factores como el nmero de usuarios, el
tamao de los vdeos generados, los cdecs que manejan los usuarios en sus
dispositivos, etc.
Por ejemplo un alto nmero de usuarios puede forzar a la MCU a realizar una
composicin de vdeos en uno solo a partir de los de un conjunto de usuarios. Por otro
lado en escenarios en los que los usuarios se conectan desde diferentes dispositivos, la
MCU deber adaptar los flujos que enva a cada uno de ellos en funcin de ciertas
caractersticas de los dispositivos como el tamao de la pantalla, la conexin de red,
etc. Por ltimo la MCU puede tener que grabar la sesin multimedia o parte de ella
para realizar una reproduccin posterior.
Entornos virtualizados en sistemas Cloud ayudan a la MCU a adaptarse a las
variaciones de los requisitos de estas funcionalidades. Como en el caso anterior
podemos encender una nueva mquina para realizar nuevas tareas y apagarla cuando
no sea necesaria. O aadir capacidad a las mquinas que ya se encuentran corriendo en
la infraestructura cuando sea necesario.
Otra posibilidad que ofrece el Cloud es la de configurar diferentes tipos de
mquinas virtuales dependiendo de las tareas que vayan a desempear. En la Figura 4
se puede observar un ejemplo en el que la mquina encargada de redireccionar los
flujos multimedia necesita un alto nivel de CPU y memoria. Por otro lado la mquina
encargada de grabar la sesin consumir poca memoria y CPU si recibe un nico flujo
de vdeo con la composicin de la sesin.
Resumiendo, el despliegue de una MCU en una infraestructura Cloud hace que sea
sencillo y dinmico gestionar la configuracin de diferentes tipos de mquinas
virtuales adaptando sus caractersticas a las necesidades del escenario concreto. As
podremos proveer un servicio adaptativo que utilizar de manera eficiente los recursos
disponibles reduciendo constes y mejorando el rendimiento del sistema.

53

Figura 4. Varias MCUs

4.1.3

Flexibilidad geogrfica

Otro factor crtico en las aplicaciones de tiempo real que afecta directamente a la
experiencia de usuario es la latencia de las paquetes que viajan entre los usuarios
conectados a una sesin multimedia. La latencia normalmente depende de la distancia
geogrfica entre los clientes. En los escenarios con un dispositivo MCU todos los flujos
multimedia atraviesan la mquina en la que sta est corriendo por lo tanto resulta
crucial la posicin en la que se encuentra.
Gracias a un sistema basado en el Coud podemos correr MCUs en diferentes
localizaciones geogrficas conectando cada una de ellas con los usuarios que estn
utilizando el servicio en cada regin. Por ejemplo, en la fecha en que se escribe este
documento, Amazon EC2 provee centros de datos en North Virginia, Oregon, North
California, Ireland, Singapore, Tokyo, Sydney y Sao Paulo, y Rackspace [Rackspace] en
Texas, Illinois, Vancouver, Hong Kong, London y Slough, UK.
Estos proveedores adems permiten la interconexin de MCUs en diferentes
regiones por lo que pueden ofrecerse sesiones en todo el mundo conectando usuarios a
la MCU ms cercana e interconectando las MCUs entre ellas. En la Figura 5 puede
observarse un ejemplo de esta distribucin.

54

Figura 5. Distribucin geogrfica de MCUs

4.2 Retos
Para realizar un despliegue que aproveche todas las posibilidades que ofrece el
Cloud y que han sido descritas en la seccin anterior es necesario realizar un diseo
minucioso y teniendo en cuenta todas las caractersticas del sistema que manejamos.
En esta seccin se analizan todos los retos que plantea este problema y se esbozan
posibles soluciones que habr que desarrollar con ms detalle en futuros trabajos de
investigacin.
Adems se proponen ciertas soluciones de escalabilidad que se salen de as
aproximaciones generales que suelen plantearse como por ejemplo las expuestas en [L.
M. Vaquero et al. 2011].

4.2.1

Caracterizacin del sistema

Caracterizar el rendimiento de la MCU es el primer paso para conseguir un

despliegue efectivo en el Cloud. Dependiendo de la tarea (transcocificar, grabar, etc.)
que vaya a realizarse en una MCU el hardware y ancho de banda necesario varian
significativamente. Midiendo el rendimiento de los dispositivos en entornos conocidos
y acotaros podemos extrapolar el comportamiento a otros escenarios para aproximar
las caractersticas que sern necesarias en cada momento. As sabremos la cantidad de
CPU, memoria o ancho de banda que sern necesarias en las futuras sesiones.

55

Una vez completada la caracterizacin del sistema es interesante encontrar

relaciones entre los recursos fsicos y recursos de ms alto nivel como el nmero de
usuarios o el nmero de salas activas en la sesin.
Encontrando esta correlacin podremos simplificar el trabajo a la otra de
realizar la monitorizacin y resultar muy til para las tareas que se explicarn en
secciones siguientes, con el escalado horizontal y vertical. Sabiendo la incidencia de
cada nuevo usuario conectado combinado con la monitorizacin continua de los
recursos consumidos por la MCU podremos reaccionar de forma efectiva a los
requisitos y los cambios en la demanda del sistema. Por supuesto esto implica conocer
el efecto que un nuevo usuario conectado tiene sobre las capacidades y requisitos del
sistema completo y cada instancia.
No obstante, hay un reto impuesto por el despliegue de un sistema conocido en el
Cloud. Hay mucha literatura [O. Tickoo et al. 2010] [Y. Koh et al. 2007] escrita en
cuanto a las posibles interferencias entre diferentes mquinas virtuales corriendo en el
mismo host del proveedor as como posibles formas de caracterizar el problema [A. V.
Do et al. 2011]. No obstante en el marco de esta investigacin se asume que estas
interferencias no van a ser relevantes a la hora de la caracterizacin de un sistema de
nuestras caractersticas.
A continuacin se explica un ejemplo de caracterizacin del sistema realizado en el
marco de esta investigacin y utilizando la MCU Erizo corriendo en una mquina del
proveedor Amazon EC2. Se han diseado dos escenarios que son los ms comunes en
sistemas de videoconferencias: un streaming de vdeo en tiempo real y una
videoconferencia multiusuario. En ambos sistemas se ha dealizado una monitorizacin
del consumo de memoria y ancho de banda as como del uso de ancho de banda
entrante y saliente.

Figura 6. Uso de CPU en Streaming

56

Figura 7. Uso de ancho de banda en Streaming

En el primer escenario, streaming en vivo, uno de los clientes est publicando su

flujo de audio y vdeo en la sesin y los clientes que se suscriben a l van aadindose
de forma gradual. En la Figura 6 podemos observar como el uso de CPU en la MCU
aumenta de forma lineal con el incremento de usuarios que se suscriben al streaming.
Esto ocurre porque el estndar WebRTC, como ya se ha explicado, utiliza SRTP para la
transmisin de paquetes y por lo tanto la MCU tiene que desproteger y volver a
proteger los paquetes para realizar la transmisin desde el cliente que publica hacia los
que se suscriben.
Tambin podemos observar en la Figura 7 como el ancho de banda entrante es
constante durante toda la sesin y el saliente aumenta tambin de forma lineal debido
a que cada nuevo cliente conectado implica un nuevo flujo de salida. Acerca de a
memoria utilizada aumenta tambin de forma lineal pero con una variacin mnima
durante la sesin (de unos 10 MB). Finalmente puede observarse una pequea
anomala cuando se conecta el usuario nmero 8 y el nmero 13 que probablemente
sea debida a un error en el rendimiento del cliente que publica los datos, que tambin
corre en una mquina de Amazon EC2.
En el segundo escenario, la videoconferencia multiusuario, cada usuario que se
conecta a la sesin publica su flujo de audio y vdeo y adems se suscribe al resto de
usuarios que estaban conectados previamente. Se ha establecido un lmite de seis
usuarios ya que es el nmero que comnmente se utiliza en este tipo de sesiones.

57

Figura 8. Uso de CPU en Videoconferencia

Figura 9. Uso de ancho de banda en Videoconferencia

En la Figura 8 y la Figura 9 podemos observar como en este caso el consume de

ancho de banda entrante aumenta linealmente con el incremento de usuarios en la
sesin debido al hecho de que cada nuevo usuario publica su flujo en el sistema. Sin
embargo el ancho de banda saliente y el consumo de CPU se incrementan de forma
exponencial debido a que por cada nuevo usuario la MCU debe redirigir el nuevo flujo
al resto de usuarios. Por lo tanto el nmero de flujos de salida aumentar siguiendo la
siguiente ecuacin:

58

N = n (n1)
Donde n es el nmero de usuarios en la sala. El uso de memoria en este escenario
tambin aumenta de forma exponencial pero de nuevo con una variacin insignificante
para este estudio.

4.2.2

Escalabilidad hacia arriba

Cuando los recursos disponibles en una sesin alcanzan su lmite podemos

aprovechar las caractersticas del Cloud aumentando estos recursos para seguir
ofreciendo un servicio con la calidad adecuada. Para ello existen dos tipos de
escalabilidad, horizontal y vertical.
El escalado horizontal consiste en aadir nuevas mquinas virtuales a las ya
arrancadas en el sistema y el escalado vertical en aumentar las caractersticas de las
mquinas que ya estn corriendo.
En una MCU ambos mtodos tienen sus ventajas. Si los nuevos recursos se necesitan
para hacer una nueva tarea en la sesin, como por ejemplo, grabar una sesin
multimedia, la escalabilidad horizontal puede ser ms beneficiosa. Sin embargo si los
recursos se necesitan porque ha habido un incremento del nmero de usuarios en la
sesin puede ser mejor realizar un escalado vertical para que la sesin siga
gestionndose por la misma mquina virtual.
Esto nos dar ms facilidades en caso de que sea necesario escalar hacia abajo en el
futuro como se explicar en el siguiente apartado. Suele ser en general ms
conveniente tener todos los usuarios de una sala en la misma MCU. Sin embargo, no
todos los proveedores de Cloud pblicos ofrecen la posibilidad de realizar un escalado
vertical.
Por lo tanto un primer reto importante relacionado con el escalado es el de elegir
qu tipo va a utilizarse cuando en el sistema se requiere un mayor nivel de recursos
para gestionar una sesin.
Por otro lado ambos tipos de escalado implican una latencia desde que se realiza la
accin de aumentar los recursos hasta que stos estn disponibles para su uso. Para
lograr una buena experiencia de usuarios es fundamental que no haya ningn tipo de
interrupcin en las comunicaciones y por ello es necesario anticiparse a los picos de
demanda que pueda haber en el sistema para actuar en consecuencia con un tiempo
que garantice la transparencia frente al usuario.
59

Una primera aproximacin para solucionar el problema es la de utilizar algoritmos

que, basndose en una monitorizacin del sistema, calculen cundo va a ser necesario
incorporar ms recursos a las mquinas virtuales mediante cualquiera de los dos tipos
de

escalabilidad

explicados

anteriormente.

La

MCU

deber

monitorizar

constantemente el estado del sistema analizando los diferentes factores mostrados

anteriormente. Si establecemos los lmites del sistema y la correlacin con el nmero de
usuarios y salas ser sencillo determinar cuando es necesario aadir recursos al sistema
con la antelacin necesaria. Un ejemplo de un sistema parecido puede observarse en [F.
Galn et al. 2009].
Pero podemos ir un poco ms all y utilizar modelos predictivos para anticiparse a
los cambios en los requisitos de las MCUs basndonos en el anlisis de datos previos.
Con este tipo de modelos podemos analizar patrones de comportamiento del sistema
para predecir lo que suceder en un momento determinado. Estos patrones pueden
obtenerse de dos formas fundamentales. Bien utilizando el comportamiento previo del
propio sistema o el de sistemas similares. La primera opcin es la ptima pero no
siempre podemos disponer de esos datos por lo que puede ser necesario acudir a la
segunda.
En [E. Caron et al. 2010] puede observarse un buen punto de partida en el cual el
problema se resuelve con un algoritmo que predice el uso de recursos utilizando un
matching de patrones.

4.2.3

Escalabilidad hacia abajo

De la misma forma que durante una sesin puede ser necesario incrementar los
recursos disponibles puede ocurrir que en un momento dado un pico de demanda
haya desaparecido y estemos ofreciendo ms recursos de los necesarios. Como se ha
mostrado en la seccin anterior hay diferentes mtodos de incrementar los recursos de
un mdulo MCU. En el caso del escalado hacia abajo ocurre lo mismo peor en sentido
contrario.
Por lo tanto el primer reto que plantea el escalado hacia abajo es similar al caso
anterior. Cuando detectamos que segn la demanda del sistema estamos ofreciendo
ms recursos de los necesarios debemos elegir la mejor forma de disminuirlos.
Podemos realizar un escalado vertical y reducir la capacidad de computacin de las
mquinas que ya estn corriendo o realizar un escalado horizontal reduciendo el
nmero de mquinas arrancadas.

60

Pero en el segundo caso, escalado horizontal hacia abajo, se plantean dificultades

adicionales. Debe tenerse en cuenta que en la mquina que vamos a apagar muy
probablemente est realizndose la gestin de usuarios, flujos y salas multimedia por
lo que deberemos distribuir estos elementos entre el resto de mquinas que seguirn
arrancadas. Esta distribucin no es un problema trivial.

Figura 10. Proxy

Un cliente que est participando en una sesin est enviando y recibiendo varios
flujos multimedia desde y hacia la MCU. Si esta MCU va a ser apagada es necesario
redirigir estos flujos a otra MCU y esta redireccin debe realizarse de forma
transparente para el usuario. Adems para optimizar el uso de recursos debe realizarse
una correcta distribucin de los usuarios y las salas de videoconferencia procurando
agrupar estos en las mismas MCUs.
Una posible solucin a este problema, mostrado en la Figura 10, es la de incluir un
proxy entre los clientes y el mdulo MCU. De esta forma cuando una mquina va a ser
apagada el proxy comenzar a duplicar los flujos entre la antigua MCU y la nueva.
Cuando los flujos estn preparados el proxy cambiar en envo y recepcin al cliente de
la antigua MCU a la nueva y en ese momento podr apagarse la antigua.

4.2.4

Distribucin geogrfica

De la mano de la flexibilidad que da la distribucin geogrfica permitida por los

proveedores de Cloud viene el reto de localizar de forma ptima las instancias de
MCUs para obtener el mejor servicio posible. a decisin puede ser trivial cuando todos
los usuarios estn localizados en el mismo continente o zona del proveedor de Cloud.
61

Pero decidir cmo actuar cuando los usuarios estn distribuidos en distintos lugares
puede determinar la calidad de la sesin.
Para tomar esta decisin debe tenerse en cuenta el nmero de usuarios en cada
regin geogrfica pero tambin a calidad de sus conexiones. Para caracterizar las
conexiones entre las regiones es interesante realizar medidas de ancho de banda, jitter,
prdidas de paquetes y RTT. Probando la conexin de cada usuario con las diferentes
regiones podemos decidir dnde la calidad ser mejor.
Como puede comprobarse en [J. Cervino et al. 2011] las conexiones de red entre
instancias de Amazon en diferentes regiones rinden mejor que las conexiones de
Internet medias. Debe tenerse esto en cuenta a la hora de realizar el diseo y
despliegue del sistema.

62

5 Resultados
En esta seccin se realiza una descripcin de los diferentes resultados obtenidos o
que se van a obtener en relacin a Licode. Esto incluye desarrollo de proyectos del
departamento y el grupo de investigacin, lneas de investigacin y la comunidad
creada en torno al proyecto.
El sitio web en el que se encuentra publicada toda la informacin al respecto del
proyecto es
http://lynckia.com/licode

5.1 El proyecto de cdigo libre

Licode es un proyecto de cdigo libre publicado en la pgina del grupo de
investigacin GING en la plataforma GitHub. Puede encontrarse en:
https://github.com/ging/licode
Algunos datos en la fecha en que se escribe este documento en esta plataforma son
los siguientes:

76 stars

19 forks

496 commits

3 pull requests

8 branches

Por lo tanto cualquier persona puede descargarse la plataforma, instalarla en su

propia mquina en unos minutos y ofrecer un servicio de comunicaciones en tiempo
real en la web. La informacin para realizar esta instalacin se encuentra en
http://lynckia.com/licode/install.html

63

5.2 La comunidad
En torno al proyecto de cdigo libre se ha creado una comunidad de usuarios que
cada da se descargan el proyecto y utilizan con diferentes fines realizando por tanto
pruebas en diferentes entornos y con distintos casos de uso. Se ha creado una lista de
correo para consultar y discutir temas relacionados con Licode. Cualquier
desarrollador interesado en el proyecto puede suscribirse a esta lista de correo y
participar en ella en:
lynckia@googlegroups.com
Algunos datos acerca de esta lista son los siguientes:

87 miembros

Ms de 50 discusiones

4/5 mensajes diarios

5.3 Proyectos
El proyecto Licode se est utilizando en algunos proyectos de investigacin del
departamento. En el momento en que se escribe este documento son los siguientes:

5.3.1

FI-WARE

FI-WARE (Plataforma central del Internet del futuro, del ingls Future Internet Core
Platform) es un proyecto europeo que se

dedica a la creacin de una nueva

infraestructura de servicios basada en componentes bsicos genricos y reutilizables

denominados Capacitadores Generales (Generic Enablers, GE) para la Internet del
Futuro.

5.3.2

Telefnica Espaa MSC5

El proyecto MSC5 es un proyecto realizado por el grupo de investigacin GING

para Telefnica Espaa en el mbito de innovacin. Consiste en el desarrollo de un

64

servicio multi dispositivo de televisin social, videovigilancia, teleasistencia y juegos

que funcionar utilizando el nuevo estndar de comunicaciones web HTML5 WebRTC.

5.4 Investigacin
Durante este ao se ha realizado una contribucin publicando un artculo [Alvaro
Alonso et al. 2013] en el congreso internacional IARIA CLOUD COMPUTING 2013.
The Fourth International Conference on Cloud Computing, GRIDs, and Virtualization.
En esta contribucin se realiza el anlisis descrito en la seccin 4 de este documento,
en relacin a los retos y oportunidades que plantea el despliegue del componente Erizo
en una infraestructura Cloud.
Adems fruto del trabajo realizado hasta el momento surgen ms lneas de
investigacin relacionadas con este despliegue que se explicarn a continuacin en la
seccin dedicada a trabajos futuros.
Durante este periodo tambin se ha realizado una contribucin relacionada con el
campo de la videoconferencia en la web junto a Pedro Rodrguez, Joaqun Salvacha y
Javier Cervio. En concreto acerca de un algoritmo de calidad de servicio en la
plataforma VaaS explicada en el Estado del Arte de este documento. La contribucin
va

publicarse

en

el

congreso

internacional

WCCIT'13

World Congress on Computer and Information Technologies, en concreto en

ICMMP'2013 - The 2013 International Conference on Multi Media Processing.

65

6 Conclusiones
Licode es un proyecto software que provee comunicaciones en tiempo real en los
navegadores de tal forma que puede instalarse en cualquier infraestructura orientado a
ser escalable en el Cloud. Por lo tanto cumple los requisitos previstos en este Trabajo
Fin de Mster. Como resultado del trabajo y en colaboracin con los compaeros del
grupo se han cumplido los siguientes objetivos:
-

Se ha diseado una arquitectura del sistema orientada al Cloud que permite

proveer servicios avanzados de comunicaciones en tiempo real en los
navegadores web tales como videoconferencia entre muchos usuarios, streaming
en tiempo real, juegos online, etc.

Se ha desarrollado cada uno de los mdulos utilizando las tecnologas ms

adecuadas para cada uno de los casos.

Se ha realizado un trabajo en equipo y en grupos de desarrollo de proyectos

adecundose a los requisitos concretos de cada uno de ellos y a los plazos
establecidos.

Se ha publicado el proyecto como cdigo libre consiguiendo crear una

comunidad en torno a l que proporcione feedback y mejore el rendimiento y
funcionalidades del sistema.

Se ha realizado un estudio de investigacin en torno al despliegue del sistema en

infraestructuras Cloud que adems se enfoca a la continuacin con nuevas vas
de investigacin.

6.1 Trabajo futuro

En cuanto al lado tcnico del sistema, el trabajo futuro consiste en ampliar y
evolucionar las funcionalidades y capacidades del sistema aadiendo tareas de
grabacin y mezcla de vdeos en el mdulo Erizo. Esto implica tambin realizar
mejoras en el resto de mdulos del sistema para ser compatibles y ofrecer distintos
servicios a los usuarios.

66

En relacin al despliegue del sistema en el Cloud el primer paso es continuar con el

trabajo de investigacin proponiendo algoritmos de escalado y monitorizacin as
como modelos predictivos. Adems estas nuevas capacidades se irn incluyendo en el
sistema una vez estn probadas y preparadas para su despliegue.
En este trabajo se incluye tambin el diseo y despliegue de proxies entre los
clientes y las MCUs para realizar de forma efectiva las tareas de escalado hacia abajo.
Gracias a todo esto se conseguir un despliegue efectivo que ahorre costes y haga un
consumo eficiente de los recursos.
Por otro lado el trabajo futuro incluye el mantenimiento de la comunidad y la
incorporacin de nuevas funcionalidades a la arquitectura general como la posibilidad
de realizar comunicaciones peer to peer.
Adems se pretende que el sistema Licode sea un toolkit webRTC de tal forma que
puedan desarrollarse mdulos externos compatibles para realizar tareas como
procesamiento de datos, realidad aumentada, etc.

67

Bibliografa
[Alvaro Alonso et al. 2013] Alvaro Alonso, Pedro Rodr iguez, Joaquin Salvachua, Javier
Cervio. Deploying a Multipoint Control Unit in the Cloud- Opportunities and
Challenges. 2013, CLOUD COMPUTING, International Conf. on Cloud Computing,
GRIDs, and Virtualization.
[Amazon] Amazon AWS. http://aws.amazon.com [retrieved: March, 2013].
[A. Bergkvist et al. 2012] A. Bergkvist, D. C. Burnett, C. Jennings, and A. Narayanan,
Webrtc 1.0: Real-time communication between browsers, W3C, Working Draft WD,
August 2012, http://www.w3.org/TR/webrtc/ [retrieved: March, 2013].
[A. V. Do et al. 2011] A. V. Do, J. Chen, C. Wang, Y. C. Lee, A. Zomaya, and B. B. Zhou,
Profiling applications for virtual machine placement in clouds, in Cloud Computing
(CLOUD), 2011 IEEE International Conference on, July 2011, pp. 660 667.
[C. Jennings et al. 2013] Cullen Jennings, Ted Hardie and Magnus Westerlund, Real
Time Communications fot the Web2 IEEE Communications Magazine. Abril 2013.
[E. Caron et al. 2010] E. Caron, F. Desprez, and A. Muresan, Forecasting for grid and
cloud computing on-demand resources based on pattern matching, in Cloud
Computing Technology and Science (CloudCom), 2010 IEEE Second International
Conference, December 2010, pp. 456 463.
[F. Galn et al. 2009] F. Galn, A. Sampaio, L. Rodero-Merino, I. Loy, V. Gil, and L. M.
Va- quero, Service specification in cloud environments based on extensions to open
standards, in Proceedings of the Fourth International ICST Conference on
COMmunication System softWAre and middlewaRE, ser. COMSWARE 09, New York,
NY, USA, 2009, pp. 19:119:12.
[J. Cervino et al. 2011] J. Cervino, P. Rodriguez, I. Trajkovska, A. Mozo, and J.
Salvachua, Testing a cloud provider network for hybrid p2p and cloud streaming
architectures, in Cloud Computing (CLOUD), 2011 IEEE International Conference,
July 2011, pp. 356 363.
[L. M. Vaquero et al. 2011] L. M. Vaquero, L. Rodero-Merino, and R. Buyya,
Dynamically scaling applications in the cloud, SIGCOMM Comput. Commun. Rev.
vol 41, num 1, January 2011, pp. 45 52.

69

[M. Baugher et al. 2004] M. Baugher, D. McGrew, M. Naslund, E. Carrara, and K.

Norrman, The secure real-time transport protocol (srtp), Internet Engineering Task
Force, March 2004, updated by RFC 5506.
[Mell et al. 2011] Peter Mell and Timothy Grance. The NIST Definition of Cloud
Computing ( Draft ) Recommendations of the National Institute of Standards and Technology.
NIST Special Publication, vol. 145, no. 6, page 7, 2011.
[OAuth] OAuth: http://oauth.net/
[O. Tickoo et al. 2010] O. Tickoo, R. Iyer, R. Illikkal, and D. Newell, Modeling virtual
machine performance: challenges and approaches, SIGMETRICS Per- form. Eval. Rev.
January, 2010, vol. 37, no. 3, pp. 55 60.
[P. Mell et al. 2009] P. Mell and T. Grance, The NIST Definition of Cloud Computing, http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf [retrieved:
March, 2013], 2009.
[P. Rodrguez et al. 2012] P. Rodriguez, J. Cervino, I. Trajkovska, and J. Salvachua,
Advanced videoconferencing services based on webrtc, IADIS International
Conferences Web Based Communities and Social Media 2012 and Collaborative
Technologies 2012, pp. 180184.
[Rackspace] Rackspace. http://www.rackspace.com [retrieved: March, 2013].
[S. Loreto et al. 2012] S. Loreto and S. Romano, Real-time communications in the web:
Issues, achievements, and ongoing standardization efforts, september- october, 2012,
Internet Computing, IEEE, vol. 16, no. 5, pp. 68 73.
[Willebeek-LeMair et al. 1994] M. Willebeek-LeMair, D. Kandlur, and Z.-Y. Shae, On
multipoint control units for videoconferencing, in Local Computer Networks, 1994.
Proceedings., 19th Conference, 1994, pp. 356 364.
[Y. Koh et al. 2007] Y. Koh, R. Knauerhase, P. Brett, M. Bowman, Z. Wen, and C. Pu,
An analysis of performance interference effects in virtual environments, in
Performance Analysis of Systems Software, 2007. ISPASS 2007. IEEE International
Symposium, April 2007.

70