For conversational AI to feel natural, it must operate at the speed of human speech. Awkward pauses, clipped interruptions, and delayed barge-in signals that the network is getting in the way. OpenAI's work on OpenAI low-latency voice AI aims to eliminate these friction points for ChatGPT voice, developers using its Realtime API, and interactive workflows. Achieving this at OpenAI’s scale, serving over 900 million weekly active users, demands global reach, rapid connection setup, and consistently low media latency. According to OpenAI News, the company re-engineered its WebRTC infrastructure to overcome limitations with existing models at scale.
The core challenge involved integrating WebRTC, a standard for real-time communication, with OpenAI's massive Kubernetes-based infrastructure. Traditional WebRTC often relies on a one-port-per-session model, which clashes with the dynamic, port-constrained nature of modern cloud deployments. This approach struggles with port exhaustion and requires stable ownership of stateful sessions like ICE and DTLS, issues that become critical when managing millions of concurrent connections.
Rearchitecting for Scale
OpenAI adopted a 'split relay plus transceiver' architecture. This design separates the initial packet handling from the complex WebRTC protocol termination. A lightweight, stateless relay layer handles packet forwarding, while a stateful transceiver service manages the full WebRTC session details.
This separation allows OpenAI to expose a minimal, fixed UDP port surface to the public internet. Packets are then routed efficiently to the specific transceiver instance responsible for that session. The transceiver maintains the ICE connectivity checks, DTLS handshake, and SRTP encryption, presenting a standard WebRTC experience to the client.
Routing with ICE Credentials
A key innovation is using the ICE username fragment (ufrag) for initial packet routing. During session setup, the ufrag is embedded with routing metadata. The relay parses this metadata from the first packet, typically a STUN binding request, to determine the correct transceiver. This enables deterministic routing without requiring external lookup services on the packet path.
The daily brief
Get the free daily brief with the day's AI news, new AI startups and funding rounds every morning.
Join 64,000 other subscribers.
Subsequent DTLS, RTP, and RTCP packets flow directly to the owning transceiver. The relay's session state is intentionally minimal, focused solely on packet forwarding. To enhance resilience, a Redis cache stores established session mappings, allowing for rapid recovery if a relay restarts.
Global Reach and Geo-Steering
The architecture extends globally with geographically distributed relay ingress points. This 'Global Relay' system shortens the initial hop for users worldwide, reducing latency and jitter before traffic even enters OpenAI’s backbone. Geo-steering for signaling ensures that initial connection requests are directed to the nearest available transceiver cluster.
This combination of global relays and geo-steered signaling optimizes both setup and media paths. It ensures that users connect to nearby infrastructure, minimizing the time until they can start speaking. Such advancements are crucial for applications like interactive AI agents and real-time data processing, as highlighted in discussions around voice AI precision.
The relay service itself is implemented in Go, with a deliberately narrow scope to maintain performance and efficiency.
This architectural shift is fundamental for delivering responsive and natural-sounding voice AI at scale.
