OpenAI 为了解决大规模实时语音 AI 的低延迟与全球覆盖问题，重构了其 WebRTC 堆栈，采用 relay + transceiver 的分离式架构，保留客户端标准 WebRTC 行为并在内部改变数据包路由；该设计在解决端口耗尽、状态粘性与首跳延迟等部署难题的同时，实现快速连接建立和稳定的媒体往返时延。文章介绍了为何选用 WebRTC、转发器与转接器（transceiver）模型的权衡、在 Kubernetes 环境下的工程挑战、以及全局中继与基于 ICE 证书的路由策略及其性能。
背景与问题
– 目标：为 >9 亿每周活跃用户提供全局覆盖、快速连接和低抖动/丢包的实时语音体验。
– 要点：语音 AI 需要边说边处理（实时转写、推理与生成），任何网络延迟都会显著影响对话自然度。
为何选 WebRTC
– WebRTC 提供标准化的 NAT 穿透（ICE）、加密（DTLS/SRTP）、编解码协商和质量控制（RTCP），减少客户端实现差异。
– 使用成熟开源实现（如 Pion）与浏览器生态，能把精力放在将实时媒体接入模型上而非重做传输层。
架构选择：SFU vs Transceiver
– SFU（Selective Forwarding Unit）：适合多方场景，便于转发、录制与多流管理，但对 1:1、极低延迟场景并非最优。
– Transceiver 模型：边缘服务终止 WebRTC 会话并把媒体转换为内部简化协议，保持会话状态集中（ICE/DTLS/SRTP），后端像普通服务扩展，延迟敏感的 1:1 场景更合适。
在 Kubernetes 上的部署挑战
– 端口耗尽：每会话一端口的传统模型在大并发下需要巨量公网 UDP 端口，不利于云负载均衡、健康检查、安全与自动扩缩容。
– 状态粘性：ICE/DTLS 会话需要稳定的所有权，不能随 Pod 频繁迁移；需要把会话状态固定到负责的转接器。
– 全球路由：要保证第一跳延迟低，需要本地接入并在内部做智能路由。
OpenAI 的解决方案：relay + transceiver
– 架构概念：在边缘保留标准 WebRTC 行为（transceiver 终止会话），内部通过全局中继（relay）转发媒体包与路由决策。
– 路由策略：基于 ICE 凭证做路由，使得客户端与最近接入点快速建立连接，而内部流量可以被引导到合适的后端处理区域以保持低延迟。
– 全局中继与信令：使用地理引导的信令与中继网格来把首跳延迟最小化，同时将端口管理与会话持久化交由转接器处理。
实现与性能要点
– 转接器负责会话握手、密钥管理与 SRTP 加解密，后端服务不直接担当 WebRTC 对等方。
– 中继实现需要在吞吐、抖动处理和路由稳定性之间取得平衡，保持低 RTT 与低丢包率。
总结与经验教训
– 在大规模实时语音场景中，保留客户端标准 WebRTC 行为同时在内部重路由，是兼顾互操作性与工程可运维性的有效路径。
– 把会话状态集中在可控的转接器节点，配合全球中继和基于 ICE 的路由，可缓解端口管理、状态粘性和首跳延迟问题。
参考与影响
– 该设计支撑 ChatGPT Voice、Realtime API 的 WebRTC 终端等产品，适合低延迟、单人会话为主的语音 AI 应用。
把 WebRTC 的客户端互操作性保留在边缘、在内部用智能中继路由，是大规模语音 AI 的务实工程折中。