WebRTC à Escala: Como o Mandraki Lida com Chamadas de Grupo Massivas

As chamadas de vídeo em grupo são uma daquelas funcionalidades que aparentam ser simples para os utilizadores, mas que envolvem uma considerável complexidade de engenharia por baixo da superfície. Uma chamada um-para-um é relativamente simples — dois pares trocam media diretamente. Mas, assim que se adiciona um terceiro participante, as decisões arquiteturais multiplicam-se e, quando se chega a cinquenta participantes em várias sessões simultâneas, está-se perante um problema genuinamente difícil de sistemas distribuídos.

Este artigo explica como a arquitetura de media em tempo real do Mandraki é concebida para escala massiva — sem comprometer a cifragem ou a soberania dos dados.

Por que não peer-to-peer

Numa topologia em malha peer-to-peer, cada participante envia o seu fluxo de media diretamente a todos os outros participantes. Para uma chamada com N participantes, cada pessoa envia N-1 fluxos e recebe N-1 fluxos. O número total de ligações é N*(N-1) e a largura de banda de upload de cada participante escala linearmente com o número de participantes.

Isto funciona adequadamente para três ou quatro participantes com boas ligações à Internet. Para além disso, desmorona-se. Um participante com 5 Mbps de upload a enviar um fluxo de vídeo de 1,5 Mbps só consegue servir três pares antes de saturar o seu upload. A utilização de CPU para codificar múltiplos fluxos sobe rapidamente. E as condições de rede entre pares arbitrários de participantes são imprevisíveis.

A topologia em malha é elegante em teoria e impraticável à escala.

A abordagem SFU

Uma Selective Forwarding Unit (SFU) situa-se no centro da topologia da chamada. Cada participante envia um único fluxo de upload para a SFU. A SFU encaminha depois esse fluxo para todos os outros participantes. A largura de banda de upload do participante é constante, independentemente do número de participantes — envia sempre um fluxo. A SFU trata do fan-out.

A parte “seletiva” é importante. A SFU não se limita a difundir todos os fluxos a todos os participantes. Toma decisões inteligentes de encaminhamento com base nas condições de rede, na visibilidade dos participantes e na largura de banda disponível. Se a ligação de download de um participante estiver limitada, a SFU pode encaminhar camadas de menor resolução. Se um participante não estiver atualmente visível na interface (por exemplo, numa chamada grande em que apenas o orador ativo é mostrado em tamanho grande), a SFU pode reduzir ou pausar o encaminhamento do seu fluxo.

Isto é fundamentalmente diferente de uma Multipoint Control Unit (MCU), que descodifica todos os fluxos recebidos, compõe-nos num único fluxo misto, recodifica-o e envia o composto a cada participante. As MCUs consomem CPU de forma intensiva, acrescentam latência de codificação e — criticamente — requerem acesso ao media em texto simples, tornando-as incompatíveis com a cifragem de ponta a ponta.

Uma SFU encaminha pacotes cifrados sem os descodificar. É isto que torna possível a cifragem de ponta a ponta baseada em SFrame numa chamada de grupo. A SFU encaminha texto cifrado.

A arquitetura SFU do Mandraki

O Mandraki utiliza uma biblioteca SFU open-source integrada diretamente na nossa infraestrutura. Em vez de depender de um servidor de media monolítico de terceiros, incorporamos a SFU como uma biblioteca dentro da nossa própria base de código. Isto dá-nos controlo total sobre como se integra com a nossa camada de aplicação, protocolo de sinalização e sistema de autenticação.

A SFU utiliza uma arquitetura multi-worker. Cada worker é um processo nativo separado que lida com o encaminhamento de media efetivo a um desempenho próximo do nativo. A camada de coordenação gere workers, transportes e interfaces com a nossa lógica de aplicação. Esta separação mantém o caminho de media rápido enquanto o caminho de controlo permanece flexível.

A SFU suporta simulcast e SVC (Scalable Video Coding), essenciais para o encaminhamento adaptativo à largura de banda. Os navegadores dos participantes codificam o seu vídeo em múltiplos níveis de qualidade simultaneamente. A SFU seleciona o nível apropriado para cada destinatário com base na largura de banda disponível e no contexto da interface.

Escalar para centenas de sessões

Para implementações em larga escala, a arquitetura é concebida em torno de escalabilidade horizontal com encaminhamento inteligente de sessões.

Implementação multi-instância de SFU. Várias instâncias de SFU correm em diferentes zonas de disponibilidade. Cada instância regista a sua capacidade junto de uma camada de coordenação. Quando é criada uma nova chamada, o sistema seleciona a instância de SFU com mais capacidade disponível. Os participantes da mesma chamada são sempre encaminhados para a mesma instância de SFU, para encaminhamento ótimo de media.

Paralelismo ao nível do worker. Cada processo de SFU lança vários workers nativos — tipicamente equivalentes ao número de núcleos de CPU disponíveis. Cada worker consegue lidar com várias salas de chamada de forma independente. Isto significa que um único servidor SFU com 16 núcleos pode gerir eficientemente dezenas de chamadas simultâneas, cada uma com até 50 participantes.

Encaminhamento adaptativo à largura de banda. Para chamadas com muitos participantes, várias otimizações entram automaticamente em ação. A deteção do orador ativo reduz o número de fluxos de alta qualidade que precisam de ser encaminhados. A seleção de camadas simulcast torna-se mais agressiva, favorecendo camadas inferiores para participantes não visíveis. A alternativa apenas áudio está disponível para participantes com largura de banda gravemente limitada.

Implementação europeia multi-zona. A infraestrutura do Mandraki corre em várias zonas de disponibilidade dentro da UE, em infraestrutura hyperscale europeia. As instâncias de SFU são implementadas próximas dos utilizadores, reduzindo a latência de ida e volta dos pacotes de media. Todo o encaminhamento de media permanece dentro das fronteiras europeias — nenhum media é jamais retransmitido através de infraestrutura fora da UE.

Travessia de NAT

A maior força do WebRTC — a conectividade peer-to-peer direta — é também o seu maior desafio. A maioria dos dispositivos está atrás de firewalls com NAT (Network Address Translation) que impedem ligações diretas de entrada. O WebRTC usa ICE (Interactive Connectivity Establishment) para descobrir um caminho de rede viável, tentando ligação direta, ligação mediada por STUN e retransmissão TURN, por essa ordem.

O Mandraki opera servidores TURN dedicados juntamente com a infraestrutura SFU. O TURN atua como uma retransmissão de último recurso — quando um participante não consegue estabelecer uma ligação direta à SFU (devido a firewalls restritivas, NAT simétrico ou servidores proxy empresariais), o media flui através do servidor TURN. Isto acrescenta alguma latência, mas garante conectividade.

Os servidores TURN suportam UDP e TCP, bem como TLS para ambientes que apenas permitem tráfego HTTPS. Tal como tudo o resto na nossa pilha, correm inteiramente dentro da UE.

Cifragem de ponta a ponta à escala

A arquitetura SFU é especificamente escolhida porque preserva a compatibilidade com a cifragem de ponta a ponta. Utilizando WebRTC Encoded Transforms e o protocolo SFrame (RFC 9605), as tramas de media são cifradas no dispositivo do remetente antes de chegarem à SFU. A SFU encaminha as tramas cifradas para os destinatários, que as decifram localmente.

A SFU nunca tem acesso a media em texto simples. Encaminha texto cifrado. Isto significa que, mesmo à escala — com dezenas de participantes e várias chamadas simultâneas — as garantias de cifragem mantêm-se. Nenhum servidor na nossa infraestrutura vê ou processa áudio ou vídeo não cifrado.

Trata-se de uma escolha arquitetural fundamental. Muitas plataformas reivindicam cifragem, mas utilizam arquiteturas baseadas em MCU que requerem descodificação do lado do servidor. A abordagem SFU do Mandraki significa que a cifragem não é apenas uma funcionalidade — é uma garantia estrutural.

Monitorização e fiabilidade

Os problemas de WebRTC são notoriamente difíceis de diagnosticar. Recolhemos telemetria do lado do cliente, incluindo transições de estado da ligação ICE, tipos de pares de candidatos selecionados, estimativas de tempo de ida e volta, taxas de perda de pacotes e estimativas de largura de banda. Estas métricas são agrupadas em lotes e enviadas para o nosso ponto de telemetria para agregação.

Do lado do servidor, a SFU regista eventos de transporte, ciclo de vida de produtores e consumidores e estimativa de largura de banda. Combinada com a telemetria do lado do cliente, isto fornece uma visão abrangente da qualidade das chamadas que nos permite identificar e resolver problemas de forma sistemática.

A comunicação em tempo real à escala massiva é um desafio profundo de engenharia. Continuamos a investir na infraestrutura de media que torna as chamadas do Mandraki fiáveis, de baixa latência e cifradas de ponta a ponta — tudo dentro de infraestrutura europeia soberana.