OpenAI在推出实时语音和视频功能时，遇到了一个不大不小的基础设施难题：WebRTC。这个为浏览器实时通信设计的技术栈，在面对OpenAI的规模和需求时，暴露出了不少问题。本文分析OpenAI遇到的WebRTC困境，以及这对整个实时AI通信领域意味着什么。

什么是WebRTC

WebRTC（Web Real-Time Communication）是一套支持浏览器和移动应用进行实时音视频通信的开放标准。它被广泛用于视频会议、直播、在线教育等场景。Zoom、Google Meet、Discord等产品的底层通信都依赖WebRTC或其变体。

当OpenAI推出GPT-4o的实时语音功能时，选择了WebRTC作为客户端与服务端之间的实时音频传输方案。这个选择看起来很自然——WebRTC是浏览器原生支持的、成熟的实时通信方案。但在实际落地过程中，问题逐渐暴露。

OpenAI遇到的WebRTC问题

1. 延迟和抖动

AI实时语音对话对延迟的要求比普通视频会议更高。用户说完一句话后，期望AI能在几百毫秒内开始响应。但WebRTC的网络自适应机制（如抖动缓冲区、丢包重传）在某些场景下反而增加了延迟。

2. NAT穿透问题

WebRTC需要通过ICE（Interactive Connectivity Establishment）框架来处理NAT穿透。在复杂的网络环境（如企业防火墙、运营商级NAT）下，连接建立的成功率和速度都不够理想。

3. 服务端扩展

传统的WebRTC架构中，SFU（Selective Forwarding Unit）或MCU（Multipoint Control Unit）负责媒体流的转发和混合。当需要处理海量并发的AI语音会话时，服务端的扩展成本和复杂度急剧上升。

4. 浏览器差异

虽然WebRTC是W3C标准，但不同浏览器的实现细节存在差异。Chrome、Firefox、Safari在编解码器支持、API行为等方面的不同，给跨平台兼容性带来了额外工作。

替代方案探讨

有开发者提出了几种可能的替代方案：

• WebSocket + 自定义音频流：绕过WebRTC的复杂性，直接通过WebSocket传输PCM或Opus编码的音频数据。实现简单，但需要自行处理网络自适应。
• Media over QUIC (MoQ)：IETF正在标准化的新一代媒体传输协议，基于QUIC协议，目标是替代WebRTC用于大规模实时媒体分发。这也是那篇HN文章的讨论重点。
• gRPC Streaming：Google的gRPC框架支持双向流式传输，可以用于音频数据的实时传输，但浏览器端支持有限。
• 专有协议：像Discord那样，开发针对特定场景优化的专有协议。

对站长和开发者的启示

如果你在开发涉及实时AI语音交互的应用，以下几点建议：

1. 评估实际需求：如果你的应用不需要浏览器端实时音频，WebSocket方案可能更简单可靠。
2. 关注MoQ进展：Media over QUIC是未来方向，但目前标准化和实现都还不成熟。
3. 做好降级方案：即使使用WebRTC，也要准备WebSocket降级方案，确保在WebRTC连接失败时用户仍有基本体验。
4. 测试真实网络环境：在开发环境中的低延迟网络下测试没问题，不代表在用户的4G/WiFi环境下表现良好。

实时AI通信的未来

随着AI语音交互、AI视频通话等功能的普及，实时AI通信基础设施的需求会越来越大。WebRTC虽然是目前最成熟的选择，但确实需要演进才能满足AI场景的特殊需求。

OpenAI遇到的这些问题，其实也是整个行业需要解决的。未来可能会出现专门为AI实时交互优化的通信框架，或者WebRTC本身会针对AI场景进行扩展。

来源：

• moq.dev – OpenAI’s WebRTC Problem

OpenAI在推出实时语音和视频功能时，遇到了一个不大不小的基础设施难题：WebRTC。这个为浏览器实时通信设计的技术栈，在面对OpenAI的规模和需求时，暴露出了不少问题。本文分析OpenAI遇到的WebRTC困境，以及这对整个实时AI通信领域意味着什么。

什么是WebRTC

WebRTC（Web Real-Time Communication）是一套支持浏览器和移动应用进行实时音视频通信的开放标准。它被广泛用于视频会议、直播、在线教育等场景。Zoom、Google Meet、Discord等产品的底层通信都依赖WebRTC或其变体。

当OpenAI推出GPT-4o的实时语音功能时，选择了WebRTC作为客户端与服务端之间的实时音频传输方案。这个选择看起来很自然——WebRTC是浏览器原生支持的、成熟的实时通信方案。但在实际落地过程中，问题逐渐暴露。

OpenAI遇到的WebRTC问题

1. 延迟和抖动

AI实时语音对话对延迟的要求比普通视频会议更高。用户说完一句话后，期望AI能在几百毫秒内开始响应。但WebRTC的网络自适应机制（如抖动缓冲区、丢包重传）在某些场景下反而增加了延迟。

2. NAT穿透问题

WebRTC需要通过ICE（Interactive Connectivity Establishment）框架来处理NAT穿透。在复杂的网络环境（如企业防火墙、运营商级NAT）下，连接建立的成功率和速度都不够理想。

3. 服务端扩展

传统的WebRTC架构中，SFU（Selective Forwarding Unit）或MCU（Multipoint Control Unit）负责媒体流的转发和混合。当需要处理海量并发的AI语音会话时，服务端的扩展成本和复杂度急剧上升。

4. 浏览器差异

虽然WebRTC是W3C标准，但不同浏览器的实现细节存在差异。Chrome、Firefox、Safari在编解码器支持、API行为等方面的不同，给跨平台兼容性带来了额外工作。

替代方案探讨

有开发者提出了几种可能的替代方案：

• WebSocket + 自定义音频流：绕过WebRTC的复杂性，直接通过WebSocket传输PCM或Opus编码的音频数据。实现简单，但需要自行处理网络自适应。
• Media over QUIC (MoQ)：IETF正在标准化的新一代媒体传输协议，基于QUIC协议，目标是替代WebRTC用于大规模实时媒体分发。这也是那篇HN文章的讨论重点。
• gRPC Streaming：Google的gRPC框架支持双向流式传输，可以用于音频数据的实时传输，但浏览器端支持有限。
• 专有协议：像Discord那样，开发针对特定场景优化的专有协议。

对站长和开发者的启示

如果你在开发涉及实时AI语音交互的应用，以下几点建议：

1. 评估实际需求：如果你的应用不需要浏览器端实时音频，WebSocket方案可能更简单可靠。
2. 关注MoQ进展：Media over QUIC是未来方向，但目前标准化和实现都还不成熟。
3. 做好降级方案：即使使用WebRTC，也要准备WebSocket降级方案，确保在WebRTC连接失败时用户仍有基本体验。
4. 测试真实网络环境：在开发环境中的低延迟网络下测试没问题，不代表在用户的4G/WiFi环境下表现良好。

实时AI通信的未来

随着AI语音交互、AI视频通话等功能的普及，实时AI通信基础设施的需求会越来越大。WebRTC虽然是目前最成熟的选择，但确实需要演进才能满足AI场景的特殊需求。

OpenAI遇到的这些问题，其实也是整个行业需要解决的。未来可能会出现专门为AI实时交互优化的通信框架，或者WebRTC本身会针对AI场景进行扩展。

来源：

• moq.dev – OpenAI’s WebRTC Problem