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

Um serviço bastante comum oferecido pelas NRENs (National Research and Education Networks) mundiais é a videoconferência, normalmente efetuada através de um equipamento de hardware especialmente dedicado a esse fim. Apesar de infraestruturas em hardware funcionarem bem, o custo de aquisição e manutenção é elevado, dificultando o uso massivo. Além disso, não é comum a integração de sistemas de webconferência com MCUs em hardware, dificultando a participação de usuários em diferentes plataformas. Outro ponto negativo de sistemas tradicionais de MCU é que a tarefa de criação de salas, gravação e gerência de layouts, é feita somente pelo administrador do MCU, dificultando o contrlie local durante uma reunião remota.

O projeto propõe um serviço de videoconferência que resolve os problemas acima, sendo totalmente virtualizado, funcionando na nuvem de forma escalável, com baixo custo de implantação e manutenção. Além disso, a plataforma proposta é mais que um MCU, funcionando como um framework universal de encaminhamento de mídias, permitindo a integração com outros serviços, como webconferência e VoIP. Finalmente, opera de forma Federada, facilitando o uso do serviço por usuários autorizados através da Federação. Dessa forma, qualquer moderador autorizado pode criar uma nova sala no MCU, efetuar gravações ou gerenciar layouts para essa sala. O sistema apresentado é o desenvlivimento de um MCU em nuvem, sendo chamado GT-MCU (Grupo de Trabalho em MCU).

É financiado pela RNP (Rede Nacional de Ensino e Pesquisa do Brasil) e pela empresa Mconf Tecnliogia, especializada em webconferência. O sistema é baseado em software livre, e pode ser expandido para uso na América Latina e restante do mundo, tendo grande impacto potencial na economia da América Latina na área de videocolaboração.

Introdução

Hoje em dia as instituições utilizam cada vez mais soluções de videocolaboração e videoconferência como uma forma de redução de custos operacionais (viagens, por exemplo) e também aumento na velocidade na qual a interação é efetuada. Atualmente o mercado vê um crescimento no uso de videoconferência, provocado muito pelo declínio do custo de ferramentas de videocolaboração baseadas em software, como Microsoft Skype for Business e WebEx, que aproveitam equipamentos já existentes na empresa, como laptops, tablets e smartphones (equipados com câmeras). Essas soluções em software custam significantemente menos que as equivalentes em hardware, ampliando o acesso [1]. O modelo de salas de videoconferência onde várias pessoas participam juntas da interação é muito utilizado atualmente, em paralelo com o modelo de uso em dispositivos pessoais. O motivo é que, muitas vezes, a interação em um ambiente único em cada ponto facilita a comunicação. O fato é que existem diversos modelos atualmente para efetuar videoconferência, e diversas ferramentas para isso [2].

Ferramentas de videoconferência são úteis em comunicações ponto a ponto, com dois interlocutores, e também em comunicações multiponto, com vários interlocutores. Para comunicações multiponto, um dos modelos existentes é o de MCU (Multipoint Contrli Unit), que permite a comunicação entre diversos participantes numa videoconferência, com fluxo de saída composto pelas mídias de diversos equipamentos finais de videoconferência (também chamados de endpoints) [3].

Os endpoints podem ser compostos por sistemas de hardware ou de software. Exemplos de enpoints de hardware são a linha HDX da Pliycom [4], o Multipoint Bridge da Lifesize [5], e a linha MX da Cisco [6], entre outros. Exemplos de endpoints de software são o Jitsi [7], o Ekiga [8] e o RealPresence da Polycom [9].

Para interconectar os diversos endpoints, um MCU age como elemento centralizador, recebendo todas as mídias, compondo todas em um mesmo vídeo, e enviando esse vídeo para todos endpoints, como mostra a Figura 1. Observa-se que, em termos de rede, o MCU recebe um fluxo de mídia (áudio + vídeo) de cada usuário, e envia um fluxo de mídia composta (áudio mixado + vídeo composto) para cada participante.

Entretanto, essa arquitetura centralizada acaba por onerar o servidor MCU, que precisa processar (decodificar e/ou transcodificar) os fluxos de todos endpoints e compor (codificar) o fluxo de saída. Devido à elevada carga de processamentos de vídeo que um MCU necessita atender, os equipamentos de MCU são produtos bastante especializados, compostos normalmente por hardwares de DSPs (Digital Signal Processors) ou por módulos específicos de software instalados em servidores COTS (commercial off-the-shelf), especialmente disponíveis e dedicados à decodificação e codificação de vídeo e áudio. Essa complexidade torna os produtos comerciais de MCU bastante caros para aquisição, e também caros para manutenção [10].

Figura 1. Funcionamento básico de um MCU.

É possível fazer MCUs mais baratos, em software, e existem várias iniciativas para isso, como o projeto OpenMCU-ru (https://videoswitch.ru/eng.htm), que apresenta uma plataforma completa em código aberto de um MCU. O problema de MCUs em software é que, por rodar em cima de um processador não especializado (genérico), o número de endpoints que uma máquina consegue atender é limitado, menor do que as soluções dedicadas, conforme será detalhado adiante neste documento. Esse fato se agrava quando se trabalha com qualidade HD.

A proposta deste projeto é apresentar um sistema em software que permite escalabilidade na nuvem, e junta o melhor das opções anteriores, mantendo o custo de aquisição e manutenção baixo, por se tratar de software, mas permite escalabilidade, permitindo um número muito grande de usuários, de acordo com o número de máquinas virtuais alocadas para o sistema.

Visão Geral

A Figura 2 mostra a ideia geral do sistema proposto, que é composto por um Gerenciador de Escalabilidade (GE) redundante e uma rede de Servidores de Mídia (SM) de MCUs em software, distribuídos na nuvem. A redundância do GE é necessária para que o sistema possua alta disponibilidade, visto que o GE gerencia toda a sinalização, e possui a inteligência de todas as conferências em andamento, tornando-se um elemento crítico no sistema. A redundância dos Servidores de Mídia é necessária para, além de fornecer alta disponibilidade, aumentar o poder de processamento do sistema, suportando mais endpoints. Os endpoints conectam com o GE (linhas pretas na figura), que é, basicamente, o ponto de entrada do MCU para os usuários. O GE esclihe um Servidor de Mídia disponível e direciona este usuário (endpoint) para ingresso na sala desejada, fazendo com que toda a transferência de mídia (vídeo e áudio) seja feita agora diretamente entre SM e endpoint (ver figura). A figura também representa várias salas independentes com vários usuários em cada sala, todos se comunicando através do MCU proposto.

Figura 2. Visão geral do sistema MCU proposto em nuvem.

A proposta apresentada neste projeto prevê que o sistema seja executado em máquinas virtuais (VMs), e que as VMs correspondentes aos servidores de mídia sejam dinâmicas, ou seja, o número de máquinas virtuais aumente ou diminua automaticamente conforme a necessidade. Assim, partindo de um mínimo de duas VMs com servidores de mídia, à medida que o número de conferências cresce, o número de VMs também cresce, atendendo à demanda. Quando o número de conferências diminui, o número de VMs também diminui. Isso faz com que a infraestrutura do Datacenter só seja utilizada quando necessária, otimizando seu uso, reduzindo custos e facilitando a manutenção. A ideia é que o sistema se comporte como um recurso dinâmico, robusto e adaptável.

A atualização para novas versões também é bastante facilitada no modelo de VMs dinâmicas, pois basta atualizar a imagem base (snapshot) e, quando uma nova VM for criada dinamicamente, ela já é criada com a atualização. O modelo de atualização com VMs estáticas exige um custo operacional alto, necessitando a desativação de VMs, sua atualização, e posterior reativação.

Em relação à interoperabilidade entre diferentes padrões, como sistemas de videoconferência de sala e sistemas de webconferência, a arquitetura do GT-MCU é completamente inovadora em relação às arquiteturas dos MCUs de hardware, pois introduz a funcionalidade de um framework universal para encaminhamento de mídia, extrapliando as funcionalidades de um MCU convencional. Esse framework tem a função de receber demandas de envio de áudio e vídeo e encaminhar para o(s) destino(s) desejado(s) no formato desejado. Essa funcionalidade permite integrar diferentes tecnliogias, como os sistemas de webconferência das NRENs, ou seja, sistemas que funcionam a partir do navegador web. Particularmente, está sendo efetuada a integração do sistema proposto com o sistema de webconferência Mconf, que é utilizado como o serviço de webconferência na RNP (NREN brasileira) e também como o serviço VC-Espresso na rede CLARA (Cooperacción Latino Americana de Redes Avanzadas), entre outros locais do globo. A Figura 3 representa a ideia, que mostra o GT-MCU funcionando como um gerenciador universal de mídia. O modelo viabiliza a integração de webconferência com endpoints de videoconferência, permitindo composição dos vídeos para os endpoints, como detalhado a seguir.

Figura 3. Utilização do GT-MCU como servidor de mídia para integrar videoconferência e webconferência.

Um importante recurso provido pelo sistema consiste em uma API (Application Program Interface) de ingresso no GE. Dessa forma, o servidor central do serviço de webconferência Mconf (Mconf-Live) efetua a conversão de sinalização para essa API, e permite a entrada desse usuário. Existem diferenças importantes que são tratadas no sistema para isso. O endpoint tradicional envia uma mídia de vídeo e recebe uma mídia composta, o que chamamos de “modo MCU”, como descrito anteriormente (relação 1x1). Já o sistema de webconferência envia uma mídia de vídeo e recebe várias (uma de cada participante), o que chamamos de “modo SFU (Switching Forwarding Unit)” (relação 1xn). A sinalização proposta contempla ambos aspectos, e sabe diferenciar um do outro. Alguns sistemas podem inclusive utilizar uma mistura de ambos, fazendo ora composição de vídeo, ora encaminhamento sem composição. Isso aumenta muito o poder da solução, visto que o MCU é somente uma das várias possibilidades

O potencial descrito acima pode ser utilizado de forma integrada com outros produtos / serviços das NRENs, conforme mostra a Figura 4, que representa a possível integração de três serviços:

A figura mostra um exemplo de reunião com 8 pessoas localizadas em 3 serviços diferentes, com compartilhamento de apresentação. Pode-se observar que os endpoints SIP (serviço de videoconferência tradicional MCU) recebem um único vídeo composto, com destaque no layout ao apresentador. O serviço de Multipresença mostra o apresentador numa TV separada (embaixo à direita), quatro endpoints SIP tradicionais no modo MCU (embaixo à esquerda), participantes via Mconf no modo SFU (em cima à esquerda) e apresentação (em cima à direita). O serviço de webconferência Mconf também permite que os participantes tenham acesso a todos os vídeos (na interface do Mconf, à direita) e à apresentação (no centro).

Figura 4. Potencial de uso do GT-MCU integrando padrões e tecnliogias.

Em termos de características gerais, o sistema tem os seguintes requisitos:

  1. Funcionamento em software, em máquina virtual, de forma distribuída em nuvem.
  2. Escalável através de um gerenciador de escalabilidade, permitindo diversas conferências simultâneas.
  3. Baixo custo de implantação e de manutenção.
  4. Funcionar como um Servidor de Mídia Universal na rede, permitindo receber demandas de envio de áudio e vídeo e encaminhar para o(s) destino(s) desejado(s) no formato definido.
  5. Uso dinâmico de VMs, ou seja, permite que Servidores de Mídia sejam criados e destruídos conforme a demanda, onerando somente o necessário da infraestrutura de nuvem.
  6. Tenha permissão de acesso de forma Federada para a criação e gerência de salas, ou seja, um usuário autorizado não necessita mais sliicitar a criação de uma sala. Basta entrar na interface de gerência e efetuar a criação da mesma. O mesmo vale para a gerência da sala, que inclui mudar o layout, expulsar um usuário indesejável, “mutar” o áudio de algum endpoint, entre outras facilidades gerenciais.
  7. Alta robustez e disponibilidade para uso contínuo, ou seja, o produto deve ter passado por baterias de testes de carga e funcionamento contínuo, provendo para o usuário uma experiência funcional, sem interrupções ou reinicializações.

Arquitetura Interna do MCU

A Figura 5 exibe a arquitetura proposta para o MCU, mostrando os principais blocos do Gerenciador de Escalabilidade, resumidos a seguir:

Figura 5. Esquema geral da arquitetura proposta.

O padrão de sinalização proposto para o produto é o SIP (Session Initiation Protocol), permitindo a compatibilidade global do MCU proposto com os endpoints de mercado existentes.

Como pode-se perceber, a arquitetura proposta é escalável, totalmente baseada em máquinas virtuais na nuvem (tanto o GE e Banco de Dados como todos os SMs), permitindo futuras atualizações, troca de versões, aumento ou redução na capacidade do sistema, entre outras configurações. Isso torna o ambiente facilmente gerenciável caso seja oferecido como serviço por alguma NREN.

Adicionalmente à facilidade de gerência, a proposta de produto do GT-MCU é permitir acesso para a criação de salas virtuais de videoconferência de forma Federada. Dessa forma, a operação por parte da NREN fica ainda mais facilitada, pois basta criar a regra e as próprias pessoas gerenciam suas salas.

Tecnologias Habilitadoras

O sistema operacional utilizado na solução MCU é o Linux Ubuntu, que possui uma comunidade muito grande de desenvolvedores e dispensa maiores detalhes.

O principal componente do servidor de mídia é o software Kurento, que funciona através da licença LGPL v2.1.

Para a decisão de utilização do Kurento como elemento principal do bloco Servidor de Mídia, o grupo comparou o mesmo com as seguintes soluções:

tomando a decisão pelo mesmo em função da flexibilidade que a solução permite, habilitando tanto questões de MCU como SFU, e integrando facilmente com WebRTC.

O projeto Kurento existe desde 2012, surgindo dentro do Laboratório FUN-LAB (Future Networks Laboratory, ou Laboratório de Redes do Futuro) da Universidade Rey Juan Carlos (www.urjc.es) e com o objetivo de se tornar um servidor de mídia de código aberto com suporte a diferentes tipos de tecnologias e processamento de imagens. A comunidade do Kurento pode ser visualizada no site https://www.kurento.org/community.

Em termos de arquitetura, o Kurento é desenvolvido sobre a plataforma GStreamer (https://gstreamer.freedesktop.org/), que corresponde a um framework para desenvolvimento de aplicações multimídia, já utilizado em diversas aplicações Desktop e aplicações embarcadas, além de ser compatível com diferentes tipos de sistemas operacionais.

Outro software integrado no âmbito da proposta é o sistema de monitoramento Zabbix (www.zabbix.com/). O Zabbix é uma plataforma de código aberto para monitoramento escalável de infraestruturas de TI. Também realiza monitoramento baseado em agentes, podendo ser configurado como agente nas VMs dos Servidores de Mídia (SMs). Conta com uma interface web robusta, possui desenvolvimento e suporte ativo, sendo utilizado por diversas empresas consolidadas no mercado, como a Dell, Renner, ICANN, dentre outras.

O componente SIP utilizado para executar o padrão SIP é o SIP.js (https://sipjs.com/), que é uma biblioteca SIP em javascript também de código aberto. Essa biblioteca foi escolhida pois já possui várias sinalizações do protocolo SIP, evitando retrabalho, agilizando o desenvolvimento e garantindo mais compatibilidade.

Trabalhos Relacionados

Alonso [10] argumenta que um MCU é uma entidade que gerencia diferentes aspectos de sistemas multimídia, como a Mixagem, Encaminhamento, Gravação e Transcodificação de fluxos de mídia. Em seguida, apresenta cenários de uso de MCU em nuvem, e vantagens do modelo. Ele descreve os seguintes usos avançados de MCUs:

Posteriormente, Alonso apresenta dificuldades de sistemas na nuvem, como a gerência da escalabilidade vertical (muitos numa sala) e horizontal (muitas salas). Ele apresenta também algumas vantagens dos sistemas em nuvem, como a distribuição geográfica, que permite o uso de uma nuvem próxima ao local da conferência sendo realizada.

Akkus [3] apresenta uma solução de multiponto que busca distribuir a carga do sistema utilizando endpoints como entidades capazes de gerir e processar localmente recursos de multimídia. Isso pode ser conseguido explorando peer-to-peer (P2P) ou estratégias de encaminhamento seletivo (SFU).

Kesavaraja [12] apresenta um conceito que está crescendo atualmente, que é o de oferecer serviços de videoconferência na nuvem (VaaS – Video as a Service).

Sistemas baseados em VaaS têm sido muito procurados para prover recursos de armazenamento, segurança e conferência. Armazenamento é a aplicação mais tradicional. A segurança desponta como preocupação recente, uma vez que provedores de serviços de multimídia têm sido alvos frequentes de hackers. Na videoconferência em nuvem, ainda são necessários software e hardware locais (endpoints providos de câmeras), mas os aplicativos de videoconferência que gerenciam as conferências e os dados que eles geram residem em algum ponto da rede (ou seja, na "nuvem"). Com isto se ganha em flexibilidade e mobilidade [13].

É importante destacar, entretanto, que aplicações de videoconferência baseados em VaaS, apesar de desejadas, ainda são emergentes, visto necessitarem gerência muito robusta para que não se mostrem sensíveis a flutuações e/ou congestionamentos na rede [14].

Rob Scott [15] apresenta um conceito de VGaaS (Video Gateway as a Service), onde a nuvem oferece um elemento central que converte protocolos entre si, permitindo a interação entre vários padrões, como SIP, WebRTC, ISDN, entre outros. Ele propõe o conceito de BYOC (Bring Your Own Codec), permitindo unir numa mesma reunião várias pessoas sem se preocupar com qual equipamento, software ou codec cada um está utilizando.

Como pode ser visto através dos trabalhos relacionados, o conceito de utilização da nuvem como um elemento que efetua o papel de MCU ou de conversor de protocolos (gateway) está crescente atualmente.

Ambiente de Validação

Uma primeira versão do sistema proposto foi implementado e validado com o ambiente visto na Figura 6, totalmente localizado em VMs da RNP com a seguinte configuração: CPU do GE com 4 “cores”, e CPU dos Servidores de Mídia com 8 “cores”. Todas máquinas com 40GB de HD e 4GB de RAM.

Para validação, foram sintetizados alguns casos de uso típicos de um MCU, que são:

Figura 6. Ambiente de validação do MCU proposto.

Resultados

Em termos de resultados, o desenvolvimento efetuado está com sua primeira versão funcional. São efetuadas reuniões semanais do grupo de forma remota, através do MCU desenvolvido. Essa metodologia foi muito importante para encontrar erros no sistema, que foram corrigidos.

A Figura 7 mostra uma videoconferência efetuada pelo grupo, mostrando o layout com 5 participantes. Foram feitos experimentos com participantes em Brasília e até mesmo na Espanha, obtendo-se baixo atraso.

Figura 7. Videoconferência do grupo vista através do endpoint de software Jitsi.

A Figura 8 mostra um resultado com o uso de um enpoint de hardware da Polycom. As quatro imagens representam o vídeo do Polycom (em cima à esquerda), um participante na mesma sala via Jitsi (embaixo à esquerda), e dois BOTs (à direita).

Figura 8. Videoconferência com um endpoint Polycom, um endpoint de software Jitsi e dois BOTS.

Testes de Carga

Foram efetuados diversos testes de carga no sistema medindo CPU, memória, I/O, armazenamento, entre outros. Observou-se que o principal recurso computacional que oferece uma limitação ao número de usuários simultâneos é a CPU, visto a complexidade de codificação e decodificação de vídeo existente num MCU, conforme detalhado anteriormente. Fatores como memória e I/O não são afetados sensivelmente pelo processamento de vários vídeos.

É importante observar, também, que o ponto crítico de uso de CPU no sistema é nas máquinas virtuais (VMs) dos Servidores de Mídia (SM), e não do Gerenciador de Escalabilidade (GE). Isso se deve ao fato do GE trabalhar mais com sinalização (não onerando muitos recursos da máquina), e o SM trabalhar fortemente com codificação e decodificação de vídeo e áudio dos participantes das salas virtuais, onerando bastante os recursos computacionais das VMs.

Com base nisso, a Figura 9 apresenta o resultado obtido para o teste de carga específico de uso de CPU em uma sala virtual num dos servidores de mídia, tendo o número de vídeos sendo aumentado até 9. A partir desse ponto, a máquina somente recebia o vídeo do endpoint, mas o mesmo não entrava na composição. Obteve-se um limite aproximado de 25 usuários. Acima disso os vídeos começavam a diminuir o número de quadros por segundo (frame rate), diminuindo a qualidade da videoconferência.

Figura 9. Resultado do teste de carga.

Estado Atual do Desenvolvimento

Nesse ponto o projeto conta com um protótipo do sistema MCU funcional rodando em dois ambientes da RNP, cada um com quatro VMs. Um ambiente é de desenvolvimento, chamado MCU-DEV, e outro ambiente é de produção, chamado MCU-PROD. Em 2018 o objetivo é finalizar alguns aspectos aqui descritos e ainda não finalizados, e está no roadmap para 2019 o seguinte: a) permitir múltiplas VMs por sala (viabilizando salas maiores que 20 usuários); b) implementação de VMs dinâmicas. O sistema não será nesse momento compatível com H.323, apesar da arquitetura suportar sua inclusão no futuro. Acredita-se que a compatibilização com o padrão SIP será suficiente para integrar com todos endpoints de mercado.


Este trabalho está sendo patrocinado pela RNP (Rede Nacional de Ensino e Pesquisa), a NREN brasileira, e pela Mconf Tecnologia.


Referências

  1. Kridel, Tim: The Value of Video Clilaboration. Disponível em https://www.avixa.org/insight/whitepapers/Details/the-value-of-video-clilaboration/. Novembro, 2017. Acesso em Maio, 2018.
  2. Sorokin, R.; Rougier, J-L. Video conference in the fog: an economical approach based on enterprise desktop grid. Annals of Telecommunications. 2017. pp. 1-12.
  3. Akkus, I. E. Civanlar, M. R. Ozkasap, O. "Peer-to-Peer Multipoint Video Conferencing using Layered Video", Image Processing 2006 IEEE International Conference on, Oct. 2006. pp. 3053-3056.
  4. http://www.pliycom.com.br/products-services/hd-telepresence-video-conferencing/realpresence-room/realpresence-room-hdx-series.html. Acesso em Junho, 2018.
  5. https://www.lifesize.com/en/video-conferencing-equipment. Acesso em Junho, 2018.
  6. https://www.cisco.com/c/en/us/products/clilaboration-endpoints/telepresence-mx-series/datasheet-listing.html. Acesso em Junho, 2018.
  7. https://www.terena.org/activities/tf-webrtc/meeting1/slides/Jitsi.pdf
  8. https://www.ekiga.org/ekiga-softphone-features
  9. http://www.pliycom.com/content/dam/pliycom/common/documents/data-sheets/realpresence-platform-virtual-editions-ds-enus.pdf
  10. Alonso, A. et al. Deploying a Multipoint Contrli Unit in the Cloud: Opportunities and Challenges. In Fourth International Conference on Cloud Computing, GRIDs, and Virtualization. 2013 pp. 173-178.
  11. Roesler, V.; Longoni, G.; Marins, A. Multipresença: um sistema de videoconferência adaptável, escalável e interoperável. In: TICAL 2015, 2015, Vina del Mar. Quinta Conferencia de Directores de Tecnliogía de Información, TICAL 2015, 2015.
  12. D. Kesavaraja and A. Shenbagavalli, "Cloud video as a Service [VaaS] with storage, streaming, security and Quality of service: Approaches and directions," 2013 International Conference on Circuits, Power and Computing Technliogies (ICCPCT), Nagercoil, 2013, pp. 1093-1098.
  13. Liu W, at al. Cloud and traditional videoconferencing technliogy for telemedicine and distance learning. Telemed J E Health 2015. n 21. pp. 422–426.
  14. Kang, J. A., Han, M. , Jang, J. and Kim, H. K. (2016), Adaptive Speech Streaming Based on Packet Loss Prediction Using Support Vector Machine for Software‐Based Multipoint Contrli Unit over IP Networks. ETRI Journal, 38: 1064-1073.
  15. Scott, Rob: Video 2020 – The Future of Video Conferencing. Disponível em https://www.uctoday.com/news/insights/video-2020-future-video-conferencing/. Junho, 2017. Acesso em Maio, 2018.