GT-MCU: MCU escalável e de baixo custo

O objetivo principal deste projeto é a criação de um MCU (Multipoint Control Unit) com os seguintes requisitos:

O problema de um MCU em software é a limitação do número de usuários simultâneos, pois é dependente da máquina. Por outro lado, é de baixo custo, visto que é executado num computador. Existe hoje uma iniciativa de MCU em software chamada “openMCU-ru” , sendo desenvolvida por um grupo na Rússia. A última versão deste software está bastante evoluída, possuindo características bastante similares a um MCU em hardware. A primeira abordagem desse GT será tentar utilizar este software como base para o MCU escalável.

A abordagem inovadora do GT seria criar uma espécie de “gerenciador de escalabilidade” para uma rede de servidores MCU em software, distribuídos em pontos estratégicos do backbone da RNP (que pode eventualmente apresentar uma arquitetura semelhante à do Mconf com seu balanceador de carga). Outra inovação seria a possibilidade de abrir salas de forma federada (CAFe), satisfazendo uma possível demanda dos clientes da RNP.

O foco inicial do GT-MCU será na tentativa de utilizar o openmcu-ru como base para o protótipo do sistema, visto que ele já está bastante evoluído nesse sentido. Serão analisadas também outras possibilidades, como o uso do Kurento e do FreeSwitch.

O diagrama em blocos da figura apresenta os principais módulos do sistema. Os blocos ovais chamados “VM MCU” representam a utilização da estratégia de MCU (que pode ser, por exemplo, o OpenMCU-ru) com algumas modificações efetuadas no âmbito do GT. O objetivo é deixar os mesmos instalados em máquinas virtuais, facilitando a manutenção.

O GT iria criar um bloco chamado “Gerenciador de Escalabilidade” (que pode ser um Balanceador de Carga), que estaria monitorando cada VM MCU (setas “ponto traço” na figura) para saber a quantidade de carga de cada um deles. A sinalização inicial para chamadas do usuário (setas tracejadas na figura) seria feita para o Gerenciador de Escalabilidade, que redirecionaria a chamada para a VM MCU mais adequada para esse usuário, servindo como um “proxy de sinalização” para a VM MCU. Finalmente, na hora de enviar e receber a mídia (áudio, vídeo e conteúdo), o balanceador passaria o endereço e porta da VM MCU, saindo do processo.

Outra abordagem a ser estudada em termos de viabilidade técnica é o Gerenciador de Escalabilidade efetuar um “redirect” da mensagem inicial, fazendo com que o endpoint efetue a sinalização diretamente com a VM MCU, sem passar pelo balanceador.

Figura 1. Arquitetura inicial proposta.