A OpenAI reconstruiu sua stack de WebRTC em torno de um relay stateless que roteia com base no ICE ufrag

A limitação que forçou o redesenho: o modelo de portas do WebRTC versus o Kubernetes

A equipe da OpenAI enquadra o problema em termos operacionais, não de produto. Atender mais de 900 milhões de usuários ativos semanais fez com que o padrão convencional de deploy de WebRTC — uma porta UDP pública por sessão — parasse de caber na infraestrutura deles.

Eles explicam o porquê. Em alta concorrência, uma porta por sessão obriga você a expor e gerenciar faixas enormes de portas UDP públicas. Load balancers de nuvem e serviços do Kubernetes não foram feitos para lidar com 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 pods são constantemente criados, removidos e reagendados, e cada um precisaria reservar e anunciar uma faixa de portas estável.

A solução óbvia — uma única porta UDP por servidor com demultiplexação em nível de aplicação — resolve a quantidade de portas, mas cria um segundo problema. ICE e DTLS são stateful, então o processo que criou uma sessão precisa continuar recebendo os pacotes dessa sessão. Numa frota balanceada por load balancer, o primeiro pacote ainda pode cair na instância errada.

Roteando por um campo que já existe no handshake

A resposta da OpenAI separa o roteamento de pacotes da terminação do protocolo. Um relay leve em Go, com uma superfície pública pequena, fica na frente de um transceiver stateful que é dono da sessão WebRTC completa — checagens de conectividade ICE, handshake DTLS, chaves SRTP e ciclo de vida. O relay nunca descriptografa mídia nem executa máquinas de estado do ICE; ele lê só o metadado de pacote necessário para escolher um destino.

O toque inteligente está em onde a dica de roteamento mora. Em vez de adicionar um serviço de lookup no caminho crítico, a OpenAI codifica metadados de roteamento no username fragment do ICE (ufrag), um identificador curto já trocado durante o setup e ecoado nas requisições de binding do STUN. O transceiver gera um ufrag do lado do servidor que carrega informação suficiente para identificar o cluster de destino e o transceiver responsável.

Assim, o primeiro pacote do caminho de mídia enviado pelo cliente — geralmente uma requisição de binding STUN enviada para um VIP de relay compartilhado, como 203.0.113.10:3478 — é interpretado pelo relay, que decodifica o ufrag e o encaminha para o transceiver correto. Os pacotes seguintes de DTLS, RTP e RTCP fluem sem precisar ser decodificados de novo. Se um relay reinicia, o próximo pacote STUN reconstrói o mapeamento a partir do ufrag; um cache no Redis guarda o mapeamento de IP do cliente para transceiver, permitindo que a recuperação aconteça ainda mais rápido.

O que o navegador nunca percebe

Para um engenheiro de frontend, a característica que define esse trabalho é justamente o que não aparece: o cliente não vê nada de novo. A OpenAI é explícita ao afirmar que, do ponto de vista do cliente, nada muda na sessão WebRTC. O transceiver continua apresentando um fluxo WebRTC normal e continua sendo dono de todo o estado do protocolo; só o roteamento interno mudou.

Para nós, isso significou mudar a forma do nosso deploy de WebRTC sem mudar o que os clientes esperam do próprio WebRTC.Montana Labs

Esse é um princípio de design deliberado que eles chamam de "preservar a semântica do protocolo na borda". Como os clientes continuam falando WebRTC padrão, a interoperabilidade entre navegadores e dispositivos móveis permanece intacta — a equipe consegue remodelar a própria infraestrutura sem lançar comportamento customizado no cliente nem fragmentar o suporte entre plataformas. A complexidade foi empurrada para uma camada fina de roteamento, não para cada serviço de backend e nem para o cliente.

O post também dá crédito ao ecossistema WebRTC sobre o qual se apoia, mencionando que Justin Uberti, um dos arquitetos originais do WebRTC, e Sean DuBois, criador da implementação Pion em Go, hoje são colegas na OpenAI. A primeira implementação do transceiver foi um único serviço em Go construído sobre o Pion.

Escolhendo a opção mais simples: sem SFU, sem kernel bypass

Duas decisões chamam atenção pela contenção. Primeiro, a OpenAI rejeitou o SFU (selective forwarding unit), a opção padrão de muitas equipes. Um SFU faz sentido para chamadas multiparty, mas o tráfego da OpenAI é majoritariamente 1:1 — um usuário para um modelo — e sensível à latência em cada turno. O resultado obtido com relay-mais-transceiver, segundo eles, confirmou que um design sem SFU era o padrão certo e permitiu que os serviços de inferência escalassem como serviços comuns, em vez de agirem como peers de WebRTC.

Segundo, eles recusaram o kernel bypass. O relay roda inteiramente em userspace como um processo Go normal, ajustado com SO_REUSEPORT para distribuir pacotes entre workers, runtime.LockOSThread para fixar fluxos em núcleos de CPU visando localidade de cache, e buffers pré-alocados para evitar overhead de garbage collection. Isso foi suficiente para lidar com tráfego global de mídia em tempo real com uma superfície de relay relativamente pequena, então mantiveram o design mais simples.

A geografia entra em camadas por cima: o Global Relay posiciona pontos de ingresso perto dos usuários para encurtar o primeiro salto, e o roteamento por geografia e proximidade da Cloudflare direciona a sinalização para um cluster de transceiver próximo, com o ufrag garantindo que a mídia ainda chegue ao transceiver ancorado.

A conclusão: metadados de roteamento pertencem ao protocolo que você já usa

A implicação específica desse anúncio é que o ufrag do ICE pode funcionar também como um roteador determinístico de primeiro pacote. Ao embutir dicas de roteamento em um campo que o WebRTC já carrega, a OpenAI conseguiu forwarding preso à sessão em toda a frota sem depender de um lookup no caminho crítico e sem quebrar o comportamento padrão do cliente.

Para equipes construindo voz em tempo real sobre WebRTC, a lição reaproveitável não é o transceiver ou o relay em si — é a sequência. Resolva o descompasso de deploy (portas UDP versus Kubernetes) com uma camada fina de forwarding stateless, mantenha as partes stateful difíceis em um único lugar, e só recorra a ferramentas exóticas como kernel bypass depois que o caso comum de fato exigir. O caminho da OpenAI sugere que, normalmente, não exige.