Políticas de QoS en una Plataforma de Trabajo Colaborativo sobre

Políticas de QoS en una Plataforma de Trabajo
Colaborativo sobre Middleware DDS
Jose M. Lopez-Vega1, Javier Povedano-Molina1, Javier Sanchez-Monedero2, Juan M.
Lopez-Soler1
1
Departamento de Teoría de la Señal, Telemática y Comunicaciones, Universidad de Granada.
2
Departamento de Informática y Análisis Numérico. Universidad de Córdoba.
1
{jmlvega, jpovedano, juanma} @ugr.es
2
{i02samoj} @uco.es
Abstract. El proyecto desarrollado propone una nueva aproximación para el
diseño de una herramienta de trabajo colaborativo. En concreto, el sistema
implementado utiliza el paradigma publicación/subscripción, para proporcionar
un servicio de videoconferencia entre distintos puntos finales remotos.
Por tanto, el sistema propuesto es una prueba concepto sobre la viabilidad de
implementar aplicaciones de muchos a muchos con contenidos de audio/vídeo
sobre middleware DDS (Data Distribution Service).
DDS es un estándar de la OMG (Object Management Group) cuyo objetivo es
abstraer al programador de las tareas necesarias para la transmisión fiable de
datos en entornos distribuidos con requisitos de tiempo-real. Este trabajo pone
de manifiesto la utilidad de incorporar las así llamadas políticas de QoS
(Quality of Service), que no son sino la definición de modelos de
comportamiento para las entidades que generan o consumen información.
Keywords: middleware, DDS, calidad de servicio, tiempo real,
videoconferencia, multimedia, audio, video
1
Introducción
La progresiva globalización y deslocalización de las empresas y la dispersión de sus
distintas sedes generan nuevas necesidades para la comunicación de los diferentes
equipos que las conforman. Del mismo modo, las demandas de educación a distancia,
justifican el uso de diferentes plataformas para el trabajo colaborativo.
Algunos ejemplos de estas plataformas los encontramos en aplicaciones como Click
to Meet [1], Isabel [2], Connecta 2000 [3] o Microsoft Office Communication Server
[4]. Dichos sistemas mejoran la productividad en entornos empresariales y
académicos mediante servicios de presencia y comunicación multimedia en tiempo
real.
En este trabajo se presenta el desarrollo de un sistema de trabajo colaborativo. En
concreto, el sistema permite la videoconferencia entre distintos clientes remotos, que
se conectan a una determinada sala virtual donde pueden interactuar con el resto de
participantes (mediante audio, vídeo y mensajes de texto).
Además, el sistema propuesto pretende demostrar la viabilidad de implementar
aplicaciones de streaming de audio/vídeo sobre middleware DDS (Data Distribution
Service) [5]. DDS es un estándar de la OMG (Object Management Group) [6]
diseñado con el fin de abstraer al programador de las tareas necesarias para el envío y
recepción de datos distribuidos. La utilización de middleware DDS permite acortar el
tiempo de desarrollo de aplicaciones de tiempo real, configurando el comportamiento
del mismo mediante un conjunto de políticas de QoS (Quality of Service). Esto es
posible debido a que el middleware facilita una capa adicional que desacopla a la
aplicación de las dificultades inherentes en la comunicación.
Para el intercambio de información, DDS aplica un modelo data-oriented [7] [8].
Dicho modelo se caracteriza por la existencia de una serie de fuentes y consumidores
de información (publicadores y subscriptores respectivamente) que tienen acceso a un
conjunto de datos de interés, conocido como data-space (espacio de datos). En este
caso no importa tanto la procedencia o destino de la información, sino disponer en
cada momento de versiones actualizadas de los datos. Un claro ejemplo de este
modelo lo encontramos en la monitorización de sensores: lo relevante no es la
localización o el número de sensores, sino que el monitor cuente con los valores más
recientes de los parámetros medidos y, por supuesto, que dicha información sea
fiable.
Como se ha comentado con anterioridad, existen en el mercado numerosas soluciones
comerciales y de código abierto que cubren las necesidades de la mayoría de usuarios
existentes (especialmente en el ámbito académico y corporativo). La meta principal
de este trabajo no es, por tanto, aportar nuevas funcionalidades a las disponibles en
otras plataformas existentes, sino desarrollar y evaluar la implantación de este tipo de
sistemas sobre middleware DDS identificando las ventajas que este enfoque
proporciona en términos de modularidad, extensibilidad, escalabilidad, robustez frente
a fallos y en tiempo de desarrollo de aplicaciones, haciendo hincapié en la
incorporación de las políticas adecuadas de QoS que el middleware puede facilitar.
2
Antecedentes y estado del arte en middleware DDS
Una característica importante de las grandes redes de ordenadores actuales, como
Internet, es su heterogeneidad. La heterogeneidad y la estandarización nos permiten,
idealmente, utilizar la mejor combinación de hardware y software, aumentando el
rendimiento de las aplicaciones sin afectar a su interoperabilidad, consiguiendo un
sistema coherente, eficiente y altamente operativo. Pero la práctica demuestra que
cumplir los requerimientos de seguridad, eficiencia, flexibilidad y extensibilidad, en
sistemas distribuidos heterogéneos es altamente complejo. Estas exigencias motivaron
la especificación y desarrollo de CORBA (Common Object Request Broker
Architecture) [9].
Sin embargo, cuando se trata de sistemas distribuidos con requisitos de tiempo real,
CORBA no constituía una solución del todo adecuada, al no estar preparado para
responder a las necesidades de mínimo retardo y determinismo que dichos sistemas
requieren.
Como respuesta a esta necesidad, en Junio de 2004 la OMG finaliza la especificación
de DDS [5] para sistemas de tiempo real. En dicha especificación, se unificaron las
mejores prácticas presentes en los middleware de distribución de datos en tiempo real
desarrollados de forma independiente por las empresas RTI [10] y Thales [11]. Este
hecho fue definido por aquel entonces como “el avance más significativo para
sistemas de tiempo real llevado a cabo por la OMG en los últimos años” [12].
Aunque inicialmente sólo existían las versiones de RTI y Thales, actualmente son
numerosas las implementaciones del estándar DDS de la OMG, algunas de ellas de
código abierto. Entre ellas, destaca RTI Data Distribution Service [13], una
implementación comercial de la capa DCPS (Data-Centric Publish-Subscribe) [5] del
estándar DDS que soporta múltiples arquitecturas (incluyendo entre ellas varios
sistemas empotrados) y múltiples lenguajes (C, C++, C#, Java…). El trabajo
presentado ha sido desarrollado sobre esta implementación del estándar DDS.
3
Arquitectura propuesta
En este apartado se describirá la arquitectura de la solución propuesta, con el fin de
dar al lector una visión general del sistema desarrollado.
El diseño realizado e implementado consiste en un sistema de videoconferencia
aplicando el modelo de publicación-subscripción. La plataforma propuesta permite el
intercambio de vídeo, audio, mensajes de texto y de señalización entre sistemas
remotos mediante middleware DDS. Se ha optado, por tanto, por un modelo
distribuido para el intercambio de información entre los distintos miembros de las
salas de conferencia. Además, para el envío de vídeo se ha implementado módulo que
sirve de puente entre cámaras IP (que trabajan con HTTP) y middleware DDS.
En la figura 1 se presenta la arquitectura propuesta. Como se puede observar, el
sistema desarrollado permite la comunicación distribuida entre sistemas heterogéneos
mediante de middleware DDS. Al aplicar un modelo de publicación-subscripción, los
recursos dejan de estar centralizados en un servidor, para pasar a formar parte del
denominado data-space. Las ventajas de esta aproximación radican en una mayor
escalabilidad y robustez, al no requerir la existencia de nodos centrales para establecer
la comunicación entre los distintos sistemas remotos.
3.1
Tópicos utilizados
Para el intercambio de datos entre las fuentes y los consumidores de información,
DDS define el concepto de tópico. Un tópico es un canal lógico para el intercambio
de información entre los publicadores y subscriptores de un determinado espacio de
datos DDS [5] [14]. Aunque un tópico sólo puede tener un tipo de dato, varios tópicos
pueden corresponder a un mismo tipo.
El sistema de trabajo colaborativo propuesto utiliza tres tipos de tópicos diferentes:



Señalización: El tópico de señalización permite notificar a los
publicadores de problemas en la recepción de los datos. Asimismo, este
tópico se utiliza para la moderación del canal de audio por parte del
administrador de la sala virtual de conferencia.
Vídeo/Audio: Cada sala de conferencia tiene asociado un tópico diferente
para cada nivel de calidad de vídeo y audio. De este modo, los clientes
pueden subscribirse a un nivel de calidad dependiendo de las condiciones
de la red.
BuiltinTopic: Se utilizan para el descubrimiento de participantes en
una sala, así como para gestionar el control de acceso a la misma.
Fig. 1. Arquitectura propuesta
3.2
Descubrimiento de las salas
Antes de poder interactuar con otros usuarios, es necesario acceder a una sala de
conferencia. El sistema desarrollado implementa dos tipos de salas:
 Públicas: Como su nombre indica, estas salas están abiertas y no cuentan con
ningún tipo de control de acceso. Por tanto, podrán ser descubiertas y accedidas
por cualquier usuario.
 Privadas: En su creación se define una lista de usuarios permitidos (diferenciados
por un número de identificación único). Por tanto, sólo los usuarios que se
encuentren en la lista asociada a cada sala podrán descubrirla y acceder a la misma.
En cuanto a la aproximación seguida, se ha mantenido el modelo distribuido en el
descubrimiento de salas. De este modo, al iniciar la búsqueda de salas el sistema
localizará dinámicamente las salas existentes mediante los mecanismos de
descubrimiento facilitados por DDS.
3.3
Moderación del canal de audio. Figura del moderador.
En los sistemas de multiconferencia, varios usuarios pueden intercambiar audio.
Este hecho puede llevar a situaciones conflictivas, al no existir contacto visual directo
entre los usuarios, reduciendo la calidad de la comunicación. Por tanto, al desarrollar
una plataforma de multiconferencia es necesario decidir cómo se va a gestionar el
canal de voz. Entre las alternativas posibles destacamos las siguientes:
 No hacer nada: En este caso, se espera que los usuarios se turnen para evitar
interrupciones. Quizá sea la alternativa menos adecuada, por la carencia de
contacto visual directo.
 Arbitrar un sistema de turnos automático: En este caso, es el propio sistema el que
decide qué usuario tiene derecho a usar el canal de audio cada vez. Aunque mejor
que el anterior, esta aproximación no es excesivamente flexible.
 Sala moderada: Esta aproximación es la que se ha implementado en el sistema que
nos ocupa. En las salas moderadas existe un usuario especial (el moderador) que
puede ceder o retirar la palabra al resto de usuarios. Así, cuando un usuario desea
hablar, solicita el canal de audio al moderador, el cual aceptará o denegará la
solicitud.
4
Políticas de calidad de servicio adecuadas para audio/vídeo
DDS extiende el modelo publicación-subscripción para responder a las necesidades
de aplicaciones de tiempo real con datos críticos. Para ello, proporciona una serie
de mecanismos estandarizados conocidos como políticas de calidad de servicio,
que permiten configurar cómo se produce la comunicación, para así limitar los
recursos utilizados por el middleware con objeto de detectar incompatibilidades en
el sistema y configurar rutinas de gestión de errores.
Además, las políticas de QoS aligeran a la aplicación librándola de ciertas tareas
que pueden ir desde el filtrado de información hasta el almacenamiento temporal
de datos, reduciendo por tanto su complejidad.
Algunas de las políticas de QoS establecen un contrato entre las publicaciones y
subscripciones. En estos casos, únicamente se establecerá la comunicación si las
políticas de QoS configuradas en el DataWriter1 y DataReader2 son
compatibles [5]. La evaluación de la compatibilidad de políticas de QoS se realiza
de forma transparente a la aplicación, mediante a un mecanismo de DCPS
denominado RxO (Request versus Offered). Cuando un DataReader se une a un
data-space, especifica un determinado valor requerido para las políticas QoS que
utilizan RxO. Por otro lado, cuando un DataWriter se une a un data-space
indica un determinado valor ofrecido para las políticas QoS con RxO. Finalmente,
DDS emparejará las entidades que son compatibles entre sí en términos de RxO,
permitiendo que se descubran entre sí.
En el caso de que un DataWriter no pueda satisfacer las políticas de QoS
solicitadas por un DataReader, no se produce el descubrimiento entre ellos y
ambos son notificados de la incidencia.
A continuación se estudiarán las principales políticas de calidad de servicio
incorporadas a nuestra aplicación.
4.1
DEADLINE
DEADLINE fija una separación máxima entre dos actualizaciones del tópico,
separación reflejada mediante el parámetro period. Cuando expira el tiempo
fijado por la política DEADLINE, DDS informa a la aplicación, lo que permite
detectar problemas en el intercambio de datos entre DataWriters y el
DataReaders.
Aunque esta política puede ser cambiada en cualquier momento, es necesario que
los periodos fijados a ambos lados de la comunicación sean compatibles, es decir,
que el periodo configurado en el DataWriter sea menor o igual que el fijado en
el DataReader. Si los periodos son incompatibles, DDS el middleware notificará
de este hecho para que la aplicación active los mecanismos oportunos y no se
establecerá la comunicación.
Esta política es de gran utilidad para el control de sesiones interactivas de audio y
vídeo, al constituir un indicador del estado de congestión de la red o de los
publicadores/subscriptores que envían/procesan dichos flujos multimedia.
De este modo, con una adecuada configuración del valor de máximo retardo entre
dos actualizaciones de una instancia (en el sistema propuesto cada instancia
corresponde a un flujo multimedia) se pueden detectar problemas en la transmisión
y actuar en consecuencia.
4.2
TIME_BASED_FILTER
TIME_BASED_FILTER limita el número de muestras que se entregan a la
aplicación por segundo, estableciendo una separación temporal mínima entre ellas.
Cuando se detectan problemas en el DataWriter de vídeo, el sistema reduce la
tasa de transmisión mediante una reducción en la calidad del stream de vídeo. Si
1
2
Entidad DDS que escribe datos en el data-space.
Entidad DDS que lee datos del data-space.
los problemas se producen en el DataReader de vídeo, se notifica a los
DataWriters mediante un tópico de señalización, con objeto de que reduzcan la
calidad del vídeo emitido de forma remota.
4.3
LIVELINESS
La política LIVELINESS permite a DDS comprobar si un DataWriter sigue
activo y, en caso contrario, notificar a los correspondientes DataReaders.
LIVELINESS ha sido utilizada en el sistema aquí presentado para mantener el
servicio de presencia. Es decir, informa a los clientes de la entrada y salida de
usuarios a una determinada sala de conferencias.
4.4
LIFESPAN
El propósito de esta política es evitar la entrega de muestras con un retardo
asociado excesivo. De este modo, cada muestra de datos escrita por un
DataWriter tiene asociado un tiempo de expiración, a partir del cual no debe ser
entregada a ninguna aplicación. Una vez que la muestra expira, los datos serán
eliminados de las caché de los DataReaders, así como de las cachés de los
servicios de persistencia de datos de DDS.
Esta política permite desestimar aquellos paquetes que tienen un retardo excesivo,
por lo que es especialmente útil aplicaciones de tipo interactivo, donde los
paquetes que tienen un retardo superior a cierto límite dejan de ser válidos y han de
ser eliminados de los búferes.
OWNERSHIP y OWNERSHIP_STRENGTH
4.5
OWNERSHIP establece si cualquier DataWriter puede actualizar los datos de
interés o, por el contrario, sólo podrá llevarlo a cabo un DataWriter concreto.
OWNERSHIP_STRENGTH permite asignar una puntuación a un DataWriter, lo
que determinará si los datos que éste escribe serán entregados.
Estas políticas han sido utilizadas para la gestión del canal de audio.
Concretamente, el usuario con permisos de moderador puede indicar mediante el
tópico de señalización qué usuario tiene la palabra. Según esta información, cada
cliente actualiza el valor de las políticas OWNERSHIP y OWNERSHIP_STRENGTH
para los DataWriters, con lo que únicamente se entregarán los paquetes de
audio que provengan del cliente con el control del canal de audio.
4.6
Otras políticas de interés para la transmisión de audio y vídeo

PARTITION: Esta política de calidad de servicio permite la división lógica
de un dominio. Esta división puede ser utilizada para la implementación de
un multipublicador de vídeo con distintos niveles de calidad.


5
PUBLISH_MODE: Esta política de calidad de servicio está incluida en la
implementación del estándar DDS correspondiente a RTI y permite la
implementación de mecanismos de control de flujo de forma sencilla.
TOPIC_DATA/USER_DATA: Estas políticas de calidad de servicio
permiten la entrega de información adicional durante el descubrimiento de
entidades DDS. Concretamente, han sido utilizadas para comunicar la
identidad del usuario durante el descubrimiento de entidades DDS. Dicha
información ha permitido implementar mecanismos de control de admisión a
las salas de conferencia privadas.
Diseño
En la figura 2 se muestra el diagrama de paquetes correspondiente al sistema
desarrollado.
Fig. 2. Diagrama de paquetes del sistema
Como se aprecia en la figura, los paquetes pueden ser clasificados en cuatro
bloques principales:
 Control del sistema: Engloba los paquetes encargados de las tareas de
control y comunicación entre los distintos módulos que componen el
sistema.
 Comunicación DDS: Engloba los paquetes encargados de la
comunicación DDS, tanto para el intercambio de información de audio,
como vídeo, mensajería y señalización.


6
Puente HTTP/DDS: El sistema implementado cuenta con un puente
HTTP/DDS que permite la comunicación del mismo con una cámara IP
para la obtención de un stream de vídeo.
JSPEEX [15]: Es un módulo que permite la codificación y decodificación
de audio con el codec de voz SPEEX [16].
Implementación
El presente trabajo no se ha limitado al diseño del sistema, sino que se ha llevado a
cabo la implementación del mismo. A continuación se describen aquellos detalles de
la implementación que se consideran especialmente relevantes.
 Descripción IDL de los tipos de datos intercambiados: RTI DDS dispone de la
herramienta rtiddsgen para la generación automatizada de código a partir de un
archivo IDL (Interface Description Language) [17]. IDL es un estándar de la OMG
utilizado en sistemas de computación distribuida para la descripción de los
componentes de las interfaces. IDL permite especificar los datos que se
intercambiarán en un lenguaje neutral, pudiendo generar componentes en diversos
lenguajes, sin que se pierda la interoperabilidad de los mismos.
 Comunicación con cámara IP: El sistema obtiene la señal de vídeo desde una
cámara IP. Concretamente, se ha utilizado una cámara AXIS 207W. Las cámaras
de este fabricante disponen de una API común, denominada VAPIX® [18], que
permite interactuar con las mismas mediante HTTP. De este modo, se pueden
configurar de forma remota lo parámetros del stream de vídeo/audio capturado o
incluso cambiar la posición del eje de la cámara. Con el fin de hacer más flexible la
configuración de la cámara, se ha diseñado un formato XML de configuración,
especificado mediante XML Schema [19].
 Integración de codec de audio SPEEX: Durante la implementación del sistema, se
evaluaron distintas posibilidades para la codificación y decodificación de la señal
de audio transmitida por el sistema. Finalmente, se escogió el codec de voz
SPEEX, que permite alcanzar una calidad elevada para un ancho de banda
reducido. Con el fin de integrar SPEEX se ha utilizado la librería JSPEEX, una
librería escrita en Java (más concretamente, basada en JavaSound [20]) que
implementa la versión 1.0.3 de SPEEX. Durante la implementación fue necesario
realizar algunas modificaciones sobre dicha librería para adecuarla a los
requerimientos del sistema.
7
Conclusiones y trabajo futuro
7.1
Principales contribuciones
Cabe destacar que el sistema propuesto ha sido realizado en el contexto de la
relación que tiene el Departamento de Teoría de la Señal, Telemática y
Comunicaciones de la Universidad de Granada con Real Time Innovations (líder
mundial en la implementación de DDS) [10].
Los resultados del desarrollo de este proyecto fueron parcialmente presentados en
Julio de 2008 en el IX Workshop on Distributed Object Computing for Real-time
and Embedded Systems celebrado en Washington (DC, USA) [21].
El trabajo ha conseguido cumplir los objetivos propuestos con las siguientes
conclusiones:
1. La utilización de middleware DDS efectivamente acorta los tiempos de desarrollo
de aplicaciones que requieren la distribución de datos en tiempo real. Además,
DDS facilita la implementación de servicios como el descubrimiento dinámico de
salas, la moderación del canal de audio o notificación de presencia gracias a la
provisión de un conjunto extenso de políticas de calidad de servicio.
2. La aplicación del modelo de publicación-subscripción para un sistema de
videoconferencia no es sólo viable, sino que además es adecuada. Esta
aproximación, al no requerir de un servidor centralizado para tareas como el
descubrimiento de salas o intercambio de datos, es altamente escalable.
3. Dada la arquitectura modular del sistema desarrollado, el código generado es
altamente reutilizable, por lo que se pueden integrar con un mínimo esfuerzo los
servicios de mensajería, intercambio de audio o vídeo implementados en nuevas
aplicaciones que se desarrollen.
4. La implementación de un puente DDS/HTTP para el acceso a cámaras IP
proporciona una interfaz reutilizable en aplicaciones fuera del ámbito de la
videoconferencia. Por ejemplo, puede servir para implementar sistemas de
videovigilancia que deban gestionar numerosas cámaras distribuidas. Además, la
descripción de los parámetros de las cámaras mediante XML facilita la
reusabilidad del puente.
7.2
Trabajo futuro
Aunque el sistema desarrollado es completamente funcional, podría ser mejorado
en los siguientes aspectos:
 Realización de test analíticos de escalabilidad: Aunque la plataforma
implementada ha sido testeada y cumple la funcionalidad especificada, sería
deseable comprobar hasta qué punto es escalable cuando es utilizada por un
número elevado de usuarios y/o de salas de conferencia. Mayor soporte de codecs
de audio: Actualmente el sistema soporta los codecs µLaw y SPEEX para audio.
Un mayor soporte de codecs lo dotaría de una mayor flexibilidad.
 Mejora del rendimiento alcanzado en audio: Dado que el sistema se ha
implementado sobre Javasound, cuenta con ciertas restricciones de retardo
inevitables. Para mejorar esta situación sería necesario utilizar JNI (Java Native
Interface), método que permite la ejecución de código escrito en un lenguaje
distinto de Java y con el que se podría hacer uso de librerías más eficientes. Esta
aproximación implica, sin embargo, la pérdida de la portabilidad del sistema (al
requerir de librerías específicas para cada plataforma).
 Establecer un método para la autenticación de los usuarios: Actualmente el sistema
ha sido diseñado bajo la premisa de que cada usuario utiliza una identificación
única. Antes de poder aplicar el producto en entornos reales sería necesario
habilitar mecanismos que permitan la obtención de dicho identificador tras un
proceso de autenticación del usuario con un servidor de
 Ampliar el soporte de fuentes de vídeo: El sistema ha sido diseñado para trabajar
con cámaras IP. No obstante, sería interesante ampliar la funcionalidad del mismo
con objeto de soportar cámaras USB, así como ampliar el soporte de codecs de
vídeo.
8
Referencias
[1] RADVISION: Click to meet platform; 2008. Available from: http://www.radvision.com/Products/Desktop/CTMPlatform/.
[2] DIT – UPM: Isabel Plaza - Home; 2008. Available from: http://isabel.dit.upm.es/.
[3] CONNECTA 2000: Connecta 2000 - Videoconferencia Peer-to-peer; 2008.
Available from: http://www.connecta2000.com/.
[4] Microsoft: Página principal de Office Communications server - Microsoft Office
Online;
2008.
Available
from:
http://office.microsoft.com/es-es/communicationsserver/default.aspx/.
[5] OMG: Data-Distribution Service for Real-Time Systems (DDS).v1.2. OMG;
2006. Available from: http://www.omg.org/cgi-bin/doc?formal/07-01-01.pdf.
[6] OMG: Object Management Group; 2009. Available from: http://www.omg.org/.
[7] RTI: Data-Oriented Architecture; 2008. Available from: http://www.rti.com/mk/data-oriented-architecture.html.
[8] Pardo-Castellote G., Farabaugh B., Warren R.: An Introduction to DDS and
Data-Centric Communications; 2005. Available from: http://www.omg.org/news/whitepapers/Intro_To_DDS.pdf.
[9] OMG: Common Object Request Broker Architecture (CORBA/IIOP).v3.1.
OMG; 2008. Available from: http://www.omg.org/spec/CORBA/3.1/.
[10] RTI: Real-Time Innovations (RTI) - World Leader in DDS - Real-time
application integration and low-latency messaging; 2009. Available from:
http://www.rti.com/.
[11] THALES: THALES; 2009. Available from: http://www.thalesgroup.com/Countries/Spain/Pagina_de_inicio/.
[12] Pardo-Castellote G.: OMG Data distribution service: Real-Time
publish/subscribe becomes a standar; 2005. Available from: http://www.rti.com/docs/reprint_rti.pdf.
[13] RTI: Real-Time Innovations Inc. RTI Data Distribution Service. Users’ Manual
(version 4.4); 2009.
[14] Pardo-Castellote G.: OMG Data-Distribution Service: architectural overview;
2003. Available from: http://dx.doi.org/10.1109/ICDCSW.2003.1203555.
[15] JSPEEX Team: JSpeex - Java Implementation of SPEEX; 2005. Available from:
http://sourceforge.net/projects/jspeex/files/.
[16] Xiph OSC: Speex: A free codec for free speech; 2009. Available from: http://www.speex.org/.
[17] OMG: OMG IDL Syntax and Semantics. OMG; 2002. Available from: http://www.omg.org/docs/formal/02-06-07.pdf.
[18] AXIS: Axis Communications - Network Camera Developer pages - API
VAPIX; 2008. Available from: http://www.axis.com/techsup/cam_servers/dev/cam_http_api_2.php.
[19] W3C: XML Schema Part 0: Primer Second Edition. W3C; 2004. Available
from: http://www.w3.org/TR/2004/REC-xmlschema-0-20041028/.
[20] SUN: Java Sound API; 2004. Available from: http://java.sun.com/products/javamedia/sound/.
[21] Lopez-Vega JM, Sanchez-Monedero J, Povedano-Molina J, Lopez-Soler JM.:
QoS Policies for Audio/Video Distribution Over DDS Middleware. In:
Workshop on Distributed Object Computing for Real-time and Embedded
Systems; 2008. Available from: http://www.omg.org/news/meetings/workshops/rt_embedded_2008.htm.