WebRTC
由W3C和IETF共同标准化的开放技术规范，由Google于2011年开源推动，2021年成为W3C推荐标准，支持浏览器间实时音视频及P2P数据传输，整合ICE、DTLS、SCTP等底层技术
核心事实
时间轴 (近 90 天)
Opus 在 16kbps 至 512kbps 的码率范围内均表现出色，是 WebRTC 实时通话的默认编解码器
前处理环节长期依赖 WebRTC 内置的 AEC/ANS 模块或 RNNoise 等传统算法，面对复杂人声干扰时效果有限
点对点文件传输领域已有 Snapdrop、Wormhole 等基于 WebRTC 的直传工具作为竞争者
使用 TURN 中继时数据实际会经过中继节点，这与纯点对点的宣传存在落差
WebRTC 由 W3C 和 IETF 标准化，允许浏览器之间在无需中间服务器中转数据的情况下直接建立音视频或数据通道
Chrome 内核浏览器默认开启的 WebRTC 会泄露用户真实 IP 而非代理 IP
WebRTC 建立连接时通过 ICE 协议收集本机所有可用网络接口的 IP 地址，该过程发生在 JavaScript 层并绕过浏览器代理设置
WebRTC的工作流程始于PeerConnection的建立，客户端与服务端建立WebRTC连接
WebRTC提供的getUserMedia API能够直接访问用户的媒体设备，实现音频采集
WebRTC连接建立过程包含SDP（Session Description Protocol）交换环节，用于完成媒体协商和网络协商
还有 18 条时间轴事件
全部知识事实 (20)
WebRTC由Google于2011年开源，后被W3C和IETF标准化
80%已验证Opus是2012年IETF标准化的编解码器，支持6kbps到510kbps的可变比特率，基于SILK和CELT混合架构
75%已验证数字人场景中WebRTC端到端延迟通常需要控制在500毫秒以内才能保证自然流畅的交互体验
75%已验证WebRTC在网络条件不佳时会主动丢弃音频包以保持低延迟，而非等待重传
65%已验证WebRTC 的传输延迟通常在 100-500 毫秒之间
65%待验证该AI数字人项目的技术架构包含四个核心模块：Agent智能体、RAG检索增强生成、WebRTC实时通信和Docker容器化部署
95%待验证Luke Curley指出WebRTC的延迟优先策略是硬编码的，开发者无法配置为优先保证数据完整性
90%待验证WebRTC的浏览器实现（主要是Chromium中的libwebrtc）将丢包决策封装在应用层无法触及的底层，JavaScript API层面没有暴露控制丢包行为或触发重传的接口
90%待验证Discord工程团队曾尝试在浏览器端实现WebRTC音频包重传机制，最终结论是技术上做不到
85%待验证OpenAI 在 2024 年底推出的 Realtime API 支持 WebRTC 作为传输层，延迟通常在 200ms 以内
70%部分验证PWA 的三个核心技术组件是 Service Worker、Web App Manifest 和强制性的 HTTPS 连接
65%部分验证提供录音棚声学套装产品，适合不具备声学设计经验的用户快速搭建基础声学处理方案，降低选配门槛
65%待验证WebRTC 在建立连接时会通过 STUN/TURN 服务器进行 NAT 穿透，可能暴露用户真实本地 IP 和公网 IP，即使使用 VPN 或代理
60%待验证Opus 在 16kbps 至 512kbps 的码率范围内均表现出色，是 WebRTC 实时通话的默认编解码器
50%待验证前处理环节长期依赖 WebRTC 内置的 AEC/ANS 模块或 RNNoise 等传统算法，面对复杂人声干扰时效果有限
50%待验证WebRTC 由 W3C 和 IETF 标准化，允许浏览器之间在无需中间服务器中转数据的情况下直接建立音视频或数据通道
50%待验证点对点文件传输领域已有 Snapdrop、Wormhole 等基于 WebRTC 的直传工具作为竞争者
50%待验证使用 TURN 中继时数据实际会经过中继节点，这与纯点对点的宣传存在落差
50%待验证WebRTC 建立连接时通过 ICE 协议收集本机所有可用网络接口的 IP 地址，该过程发生在 JavaScript 层并绕过浏览器代理设置
50%待验证Chrome 内核浏览器默认开启的 WebRTC 会泄露用户真实 IP 而非代理 IP
50%