Videoconferência (Zoom)

01 · CONTEXTO

Um sistema de muitos para muitos

Uma videoconferência é um sistema de mídia em tempo real em que cada participante envia o seu áudio e o seu vídeo e recebe os dos demais. A pergunta central do projeto é por onde essa mídia passa: direto entre os participantes ou por um intermediário que a distribui.

O whitepaper de segurança da Zoom descreve uma divisão útil para o desenho. A Zoom opera em modo híbrido: serviços web como a configuração de reuniões, a gestão de usuários, as gravações, as transcrições de chat e as gravações de correio de voz ficam hospedados na nuvem, enquanto a mídia da conferência em tempo real é processada em data centers de colocation e de nuvem comercial distribuídos globalmente.

Uma rede distribuída de roteadores de multimídia em software de baixa latência conecta a infraestrutura da Zoom. Por esses Multimedia Routers, os dados de sessão que saem do dispositivo do anfitrião e chegam aos dispositivos dos participantes são roteados dinamicamente entre os endpoints.

02 · DOIS PLANOS

Controle de um lado, mídia do outro

Na preparação da sessão, o cliente da Zoom se conecta por HTTPS a servidores da Zoom para obter as informações da reunião e avaliar o ambiente de rede, como o Multimedia Router apropriado, quais portas estão abertas e se um proxy SSL é usado. Com esses metadados, o cliente decide o melhor método de comunicação em tempo real, tentando conectar-se com as portas UDP e TCP preferidas. Para compatibilidade com proxies SSL corporativos, a conexão também pode ser feita por HTTPS.

1. O cliente se conecta por HTTPS aos servidores da Zoom para obter as informações da reunião e avaliar o ambiente de rede.

2. Entre o que o cliente avalia está o Multimedia Router apropriado, além das portas abertas e do uso de proxy SSL.

3. Com esses metadados, o cliente escolhe o método de comunicação em tempo real, tentando as portas UDP e TCP preferidas.

4. Os dados de sessão que saem do dispositivo do anfitrião e chegam aos participantes são roteados dinamicamente entre os endpoints.

03 · MÍDIA

Mesh e mixer: dois extremos

No mesh, um participante (A) precisa enviar seus fluxos RTP e seus pacotes RTCP a cada um dos outros (B e C), cada um pelo respectivo fluxo de transporte. Se todos fizerem o mesmo, todos têm uma visão conjunta da sessão.

1. O participante A envia seus fluxos RTP e RTCP a B e a C, cada um por seu fluxo de transporte.

2. Se todos fizerem o mesmo, cada participante tem uma visão conjunta da sessão.

3. O custo aparece no enlace do endpoint: em um mesh com N endpoints, N-1 fluxos de pacotes transmitidos atravessam o primeiro enlace a partir dele.

O RFC sobre topologias RTP aponta o custo: em um mesh com N endpoints, N-1 fluxos de pacotes transmitidos atravessam o primeiro enlace a partir do endpoint. A Discord também aponta que o peer-to-peer fica proibitivamente caro à medida que o número de participantes cresce, e canais de grupo grandes exigem uma arquitetura cliente-servidor.

No extremo oposto está o mixer. Em um mixer de áudio, o intermediário precisa decodificar os N fluxos vindos dos endpoints; os fluxos misturados são codificados de novo, empacotados em RTP e enviados. Cada endpoint recebe uma mistura de todas as outras fontes, exceto a sua própria.

Um MCU de comutação de vídeo, por sua vez, encaminha a cada participante um único fluxo de mídia, selecionado entre os fluxos disponíveis.

04 · SFU

Encaminhar sem misturar

No Selective Forwarding Middlebox (SFM), o intermediário seleciona quais partes de um fluxo escalável (ou qual fluxo, no caso de simulcast) encaminhar a cada endpoint receptor. A decisão pode depender de fatores como a taxa de bits disponível e o layout desejado.

O RFC situa o SFM em sistemas de videoconferência recentes, que aproveitam codificação de vídeo escalável e simulcast. Em contraste com os MCUs que transcodificam, os SFMs têm atraso extremamente baixo e oferecem recursos de sistemas de ponta, como layout personalizado, sem processamento de sinal no middlebox.

Os SFMs também são capazes de escalar a um grande número de usuários simultâneos e, por terem atraso muito baixo, podem ser encadeados.

05 · NA PRÁTICA

Um SFU em produção: a voz do Discord

No Discord, o servidor de voz tem um componente de sinalização e um componente de retransmissão de mídia, a selective forwarding unit (SFU). O SFU próprio da Discord é responsável por encaminhar tráfego de áudio e vídeo dentro dos canais.

1. Quando está online, o cliente mantém uma conexão WebSocket com um Gateway e atualiza seu estado de voz por ela.

2. Cada servidor de voz informa periodicamente sua saúde e carga ao sistema de descoberta de serviço.

3. O servidor de Guilds atribui à guilda o servidor de voz menos utilizado da região.

4. O SFU do servidor de voz é responsável por encaminhar o tráfego de áudio e vídeo dentro do canal.

5. Quando usuários ofensores são moderados com mute pelo servidor, seus pacotes de áudio são descartados.

Em termos de atribuição, o cliente online mantém uma conexão WebSocket com um Gateway e atualiza seu estado de voz por ela. Cada servidor de voz informa periodicamente sua saúde e carga, e o servidor de Guilds atribui à guilda o servidor de voz menos utilizado da região. Quando usuários ofensores são moderados com mute pelo servidor, seus pacotes de áudio são descartados.

Rotear a mídia por servidores permite moderação: administradores podem desabilitar áudio e vídeo de participantes que ofendem. Como todo cliente se conecta ao servidor de retransmissão de mídia, a Discord diz que não precisa do ICE. Todos os canais de voz de uma guilda são atribuídos ao mesmo servidor de voz.

Mesmo canais de voz muito grandes têm poucos falantes simultâneos em qualquer momento, e a Discord evita enviar áudio durante períodos de silêncio.

06 · FALHA E ESCALA

Quando o servidor de voz cai

Em caso de falha de infraestrutura, os participantes podem simplesmente se reconectar a um novo servidor de backend. O passo a passo abaixo mostra o que a Discord faz quando um servidor de voz morre.

1. Quando um servidor de voz morre, ele falha no ping periódico e é removido do sistema de descoberta de serviço.

2. O cliente percebe a falha do servidor pela conexão WebSocket de voz cortada.

3. O servidor de Guilds confirma a falha, consulta a descoberta de serviço e atribui um novo servidor de voz à guilda.

4. Todos os clientes são avisados do novo servidor de voz e criam uma conexão WebSocket de voz com ele para iniciar a configuração de mídia.

Quando um servidor de voz morre, ele falha no ping periódico e é removido do sistema de descoberta de serviço. O cliente percebe a falha pela conexão WebSocket de voz cortada. O servidor de Guilds confirma a falha, consulta a descoberta de serviço e atribui um novo servidor de voz à guilda; todos os clientes são avisados e criam uma conexão WebSocket de voz com o novo servidor para iniciar a configuração de mídia.

Sobre a escala, o post da Discord é de 10 de setembro de 2018. Nele, os servidores de Gateway, Guilds e Voice escalam horizontalmente, e a Discord roda mais de 850 servidores de voz em 13 regiões, atendendo mais de 2,6 milhões de usuários de voz simultâneos, com tráfego de saída acima de 220 Gbps.

Vídeo é um problema mais difícil que áudio: comparado ao áudio, exige bem mais CPU e banda. Na época, a Discord via Scalable Video Coding como possível solução para uma experiência de vídeo uniforme.