# OpenAI details a relay architecture for low-latency WebRTC voice > A stateless UDP relay routes sessions to stateful transceivers, shrinking the public port surface while preserving standard WebRTC behavior. Canonical URL: https://www.devobs.io/news/news-openai-global-relay-webrtc-voice/ By: Sofia Reyes Published: 2026-09-06T11:58:54.621Z Updated: 2026-09-06T11:58:54.621Z Event date: 2026-05-04 Section: Infrastructure OpenAI described [a rebuilt WebRTC stack for voice AI](https://openai.com/index/delivering-low-latency-voice-ai-at-scale/) on May 4. The architecture separates a lightweight UDP relay from stateful transceivers that terminate ICE, DTLS, and SRTP sessions. It was designed to keep standard WebRTC clients while avoiding the large public UDP port ranges and brittle session routing that arise when media endpoints run on autoscaled Kubernetes pods. ## Routing happens before a session lookup The relay reads the server-generated ICE username fragment from the first STUN packet. That fragment carries enough routing information to select the cluster and transceiver that owns the session. Later DTLS, RTP, and RTCP packets follow cached flow state, while the transceiver retains the cryptographic and protocol state. If a relay restarts, a later STUN packet can reconstruct the route; Redis can help recover the mapping sooner. OpenAI says the relay remains in user space and parses only the minimum packet metadata. Shared UDP sockets, `SO_REUSEPORT`, pinned read loops, preallocated buffers, and limited copying kept the implementation narrow without kernel-bypass networking. Geographic relay ingress and signaling steering shorten the public-network path before traffic enters OpenAI’s backbone. ## The pattern depends on workload shape The design fits mostly one-to-one, latency-sensitive sessions. A multiparty product may still benefit from an SFU that centralizes forwarding, recording, and participant policy. Engineers considering the relay pattern should first document session ownership, ICE restart behavior, flow expiry, cache failure, packet observability, and failover during pod replacement. The broader lesson is to isolate hot-path routing from stateful protocol termination. A thin forwarding layer can absorb Kubernetes and load-balancer constraints while preserving an interoperable client protocol, provided its recovery behavior is measurable and its routing hint cannot become an unchecked trust signal. ## Source references -