Feature extraction

El modelo dOTM considera una MCU realizando la tarea de replicación de paquetes, la más común entre todas las posibles y que consiste en la recepción de flujos de datos de los participantes que publican y su replicación para enviarlos a los participantes que se suscriben. La idea fundamental de este modelo es dividir esta tarea en procesos independientes de tal forma que en una sesión de videoconferencia en la que todos los participantes publican sus flujos y se suscriben a los del resto, existe un proceso realizando la tarea por cada participante conectado a la sala.

ROOM

Participant A

Participant B

Participant C

Figura 4.1 : Separación de una MCU en procesos.

En la Figura 4.1 podemos ver ilustrado un ejemplo en que una sala con tres participantes conectados queda dividida en tres componentes que reciben paquetes de un participante y los reenvían a los otros dos. Si arrancamos cada uno de estos componentes como un proceso independiente en servidores diferentes tendremos una MCU distribuida. Pero al hablar de replicación de paquetes de los flujos multimedia estamos únicamente hablando de la parte de medios de una MCU y es importante recordar que existen más componentes involucrados: la señalización y el control. Lo que propone el modelo dOTMs es dividir la MCU en tres capas correspondientes a cada uno de los tres componentes, aunque a efectos prácticos la señalización se realiza a través de la capa de control.

El resultado de esta arquitectura para la capa de control puede observarse en la Figura 4.2, con los siguientes componentes:

Participant C

Controller Participant A

Message Bus

Room Controller 1 Room Controller 2 Room Controller 3

Agent A Server A Server B OTM OTM OTM OTM OTM Agent B Participant B

Figura 4.2 : Arquitectura de control de MCU distribuida

• OTM: se trata del componente de replicación de paquetes y nueva unidad atómica de despliegue en la MCU distribuida. Como adelantaba es un proceso independiente a cargo de recibir un flujo multimedia de un único participante y reenviarlo a los demás. Para desempeñar su función, debe ser capaz de intercambiar mensajes de señalización e implementa una pila completa de protocolos para transmisión de medios compatible con la utilizada por los clientes.

• Agent: es el componente encargado de arrancar, parar y gestionar procesos OTM bajo demanda. Un Agent debe ser instanciado en cada servidor en que queramos arrancar estos componentes, es decir, en cada servidor que forme parte del despliegue de MCU distribuida. Los Agents son automáticamente descubiertos en el Controller gracias al bus de mensajes.

• Controller: es la implementación de la capa de control del sistema, encargada de gestionar las salas de videoconferencia. Se trata del punto de entrada y el interfaz de control con

4.2. ARQUITECTURA DE MCU DISTRIBUIDA

los participantes. Así, dirige a los participantes a la sala adecuada y mantiene en memoria información sobre las salas disponibles y los usuarios conectados. El control de cada sala queda delegado a losRoomControllers, un módulo diferenciado pero que forma parte del propio Controller. Para mantener una única conexión para control y señalización, Controller se encargará de reenviar todos los mensajes de señalización entre los participantes y los OTMs correspondientes.

• Room Controller: Como parte de Controller, implementa la gestión del control para una única sala. Room Controller se comunicará con los Agents para pedir nuevos OTMs según sean necesarios por la llegada de nuevos participantes que quieran publicar en la sala. Además, guardará la correspondencia para que los clientes que quieran suscribirse puedan encontrar el OTM adecuado.

Server A Server B

OTM OTM

OTM

OTM OTM

Participant B Participant C Participant A

Participant A Participant B

Figura 4.3 : Arquitectura de medios de MCU distribuida

Por otra parte, la Figura 4.3 muestra el camino de medios de la MCU distribuida. De acuerdo con lo explicado anteriormente, Controller, Room Controllers y Agents no están presentes en esta figura ya que no intervienen en este nivel. Tras una negociación de la conexión exitosa, los OTMs y los participantes de la sesión se comunican directamente intercambiando los paquetes de datos multimedia. En la figura los participantes A, B y C se encuentran en la misma sala de

videoconferencia. Los participantes A y B están publicando sus flujos multimedia utilizando dos OTMs de los servidores A y B respectivamente. Ambos están suscritos para recibir el flujo del otro y un tercer participante C lo está a ambos dos.

El modelo de escalabilidad propuesto en el capítulo anterior sigue siendo válido para esta arquitectura distribuida. Pero como puede observarse ahora tenemos una unidad más de escalabilidad, los OTMs. Por lo tanto la gestión realizada desde Cloud Handler corresponde a instancias del módulo Controller (con la unidad de escalabilidad de sala) y será este módulo el que a su vez se encargue de gestionar Agents (con la unidad de escalabilidad de OTM).

Sin embargo, en el modelo dOTMs no está contemplado cómo deben programarse los recursos entre los Agents disponibles. Cuando hablábamos de distribución de carga entre MCUs monolíticas, las posibilidades eran más limitadas y una caracterización basada en el consumo por número de salas resultaba suficiente ya que una vez asignada una sala, todas las conexiones correspondientes a una sala irían a esa misma MCU. Sin embargo, al ser capaces de repartir conexiones de una misma sala entre varios servidores tenemos que asignar conexiones (en la práctica OTMs) de manera independiente, con lo que las posibilidades se multiplican y el problema es mucho más complejo.