A OpenAI reconstruiu a sua stack de WebRTC em torno de um relay sem estado que encaminha com base no ufrag ICE

A limitação que forçou a reformulação: o modelo de portas do WebRTC face ao Kubernetes

A equipa da OpenAI enquadra o problema em termos operacionais, não de produto. Servir mais de 900 milhões de utilizadores ativos semanais fez com que o padrão de implementação convencional do WebRTC — uma porta UDP pública por sessão — deixasse de ser compatível com a sua infraestrutura.

E explicam porquê. Com elevada concorrência, uma porta por sessão obriga a expor e gerir intervalos de portas UDP públicas muito extensos. Os balanceadores de carga na cloud e os serviços do Kubernetes não foram concebidos para dezenas de milhares de portas UDP públicas. Essa superfície é difícil de proteger, difícil de auditar e hostil ao autoscaling, já que os pods são constantemente criados, removidos e reagendados, e cada um teria de reservar e anunciar um intervalo de portas estável.

A solução óbvia — uma única porta UDP por servidor com desmultiplexação ao nível da aplicação — resolve o número de portas, mas cria um segundo problema. O ICE e o DTLS têm estado, por isso o processo que criou uma sessão tem de continuar a receber os pacotes dessa sessão. Numa frota com balanceamento de carga, o primeiro pacote ainda pode chegar à instância errada.

Encaminhar com base num campo que já existe no handshake

A resposta da OpenAI separa o encaminhamento de pacotes da terminação do protocolo. Um relay leve em Go, com uma pequena superfície pública, fica colocado à frente de um transceiver com estado que gere a sessão WebRTC completa — verificações de conectividade ICE, o handshake DTLS, as chaves SRTP e o ciclo de vida. O relay nunca desencripta media nem executa máquinas de estado ICE; lê apenas os metadados de pacote suficientes para escolher um destino.

O ponto engenhoso está em onde reside a pista de encaminhamento. Em vez de adicionar um serviço de lookup no caminho crítico, a OpenAI codifica os metadados de encaminhamento no fragmento de nome de utilizador ICE (ufrag), um identificador curto já trocado durante a configuração e replicado nos pedidos de vinculação STUN. O transceiver gera um ufrag do lado do servidor que transporta informação suficiente para identificar o cluster de destino e o transceiver proprietário.

Assim, o primeiro pacote do caminho de media do cliente — normalmente um pedido de vinculação STUN enviado para um VIP de relay partilhado como 203.0.113.10:3478 — é interpretado pelo relay, que decodifica o ufrag e o reencaminha para o transceiver correto. Os pacotes DTLS, RTP e RTCP subsequentes fluem sem nova decodificação. Se um relay reiniciar, o pacote STUN seguinte reconstrói o mapeamento a partir do ufrag; uma cache Redis guarda o mapeamento entre IP do cliente e transceiver, permitindo que a recuperação aconteça ainda mais cedo.

O que o browser nunca chega a notar

Para um engenheiro de frontend, a propriedade definidora deste trabalho é negativa: o cliente não vê nada de novo. A OpenAI é explícita ao afirmar que, do ponto de vista do cliente, nada na sessão WebRTC muda. O transceiver continua a apresentar um fluxo WebRTC normal e continua a gerir todo o estado do protocolo; só o encaminhamento interno mudou.

Para nós, isso significou alterar a forma da nossa implementação de WebRTC sem alterar aquilo que os clientes esperam do próprio WebRTC.Montana Labs

Trata-se de um princípio de design deliberado que classificam como "preservar a semântica do protocolo na periferia". Como os clientes continuam a falar WebRTC padrão, a interoperabilidade entre browsers e dispositivos móveis mantém-se intacta — a equipa consegue remodelar a sua própria infraestrutura sem lançar comportamento de cliente personalizado e sem fragmentar o suporte entre plataformas. A complexidade foi empurrada para uma camada fina de encaminhamento, e não para cada serviço backend nem para o cliente.

O artigo reconhece também o mérito do ecossistema WebRTC em que se baseia, notando que Justin Uberti, um dos arquitetos originais do WebRTC, e Sean DuBois, criador da implementação Pion em Go, são agora colegas na OpenAI. A primeira implementação do transceiver foi um único serviço em Go construído sobre o Pion.

Optar pela opção sensata: sem SFU, sem contornar o kernel

Duas decisões destacam-se pela contenção. Primeiro, a OpenAI rejeitou o SFU (selective forwarding unit) para o qual muitas equipas tendem por defeito. Um SFU faz sentido em chamadas multiparticipante, mas o tráfego da OpenAI é sobretudo 1:1 — um utilizador para um modelo — e sensível à latência em cada interação. O resultado do seu par relay-transceiver, escrevem, confirmou que um design sem SFU era a opção certa por defeito e permitiu que os serviços de inferência escalassem como serviços normais, em vez de atuarem como pares WebRTC.

Segundo, recusaram contornar o kernel. O relay funciona inteiramente em espaço de utilizador, como um processo Go comum, afinado com SO_REUSEPORT para distribuir pacotes entre workers, runtime.LockOSThread para fixar fluxos a núcleos de CPU e obter localidade de cache, e buffers pré-alocados para evitar sobrecarga do garbage collector. Isso foi suficiente para gerir tráfego de media em tempo real à escala global com uma superfície de relay relativamente pequena, por isso mantiveram o design mais simples.

A geografia é acrescentada por camadas: o Global Relay coloca pontos de entrada perto dos utilizadores para encurtar o primeiro salto, e o direcionamento geográfico e por proximidade da Cloudflare encaminha a sinalização para um cluster de transceiver próximo, com o ufrag a garantir que a media ainda chega ao transceiver ancorado.

A conclusão: os metadados de encaminhamento pertencem ao protocolo que já se utiliza

A implicação concreta deste anúncio é que o ufrag ICE pode servir também como router determinístico do primeiro pacote. Ao inserir pistas de encaminhamento num campo que o WebRTC já transporta, a OpenAI conseguiu um encaminhamento fixo por sessão numa frota inteira, sem depender de um serviço de lookup no caminho crítico e sem quebrar o comportamento padrão do cliente.

Para equipas que constroem voz em tempo real sobre WebRTC, a lição reutilizável não é o transceiver ou o relay em si — é a sequência de decisões. Resolver a incompatibilidade de implementação (portas UDP versus Kubernetes) com uma camada fina e sem estado de reencaminhamento, manter as partes complexas com estado num único ponto e recorrer a ferramentas exóticas como contornar o kernel só quando o caso comum o exigir. O percurso da OpenAI sugere que, normalmente, não é preciso.