16 篇博文 含有标签「WebRTC」

"70% 的 WebRTC bug 与 NAT 有关。" — 业界经验总结

Ch4 SDP 中的 a=ice-ufrag、a=ice-pwd 只是凭证；真正让两个浏览器在 NAT 后面找到彼此、建立 UDP 通道的，是 ICE（Interactive Connectivity Establishment）——RFC 8445 定义的标准算法。

1990 年代 MBONE 多播时代，发送者只需向多播组发一次包，路由器负责复制给所有订阅者。Ron Frederick 在 WebRTC for the Curious — 历史 中回忆：他和同事都是 IP 多播研究者，用 nv 工具向整个 Internet 广播会议视频——一份数据包，数百个子网同时接收。Serge Lachapelle 则描述了另一条演进路线：他创办的 Marratech 最初也依赖多播网络，「服务器可以非常简单，因为网络负责把视频包复制给通话中的每一个人」——但「必须设计网络以适配多播模式」这一致命缺点，最终推动行业从多播转向 SFU（packet shufflers）。

WebRTC 运行在没有多播的公网上。IPv4 地址耗尽催生了 NAT 的大规模部署，每个参与者必须找到与对端通信的具体 IP:Port 路径。从「一对多广播」到「点对点单播」的设计转折，是理解 ICE 存在原因的关键背景。

本章深入 ICE 状态机、Candidate 类型、STUN/TURN 协议细节、Trickle ICE 优化，以及生产环境中最常见的穿透失败排查路径。

配套 Lab：examples/webrtc-lab/docker/coturn/ + client/ch02-p2p-basic/

"Offer/Answer 里那一大段文本，就是整个 WebRTC 会话的「合同」。"

Ch3 信令 负责传递 SDP，但 SDP 本身是什么？Ch2 中 createOffer() 产出的字符串，遵循 RFC 8866 SDP 格式。它描述了：用什么编解码器、用什么 ICE 凭证、用什么 DTLS 指纹、媒体方向是什么。

本章逐行解剖 WebRTC 中的 SDP，理解 Unified Plan、BUNDLE、rtcp-mux，以及 RTCRtpTransceiver 与 m-line 的对应关系。

"WebRTC 只标准化媒体通道，信令 deliberately 留给应用层。" — WebRTC for the Curious

Ch2 我们用手工复制 JSON 完成了 Offer/Answer 和 ICE Candidate 交换——这足以理解原理，但无法支撑生产。Serge Lachapelle 在 Curious 历史访谈中明确提到：IETF 刻意不对信令重新标准化，因为 SIP 等方案已存在，重新标准化只会引发政治斗争且「不会创造有价值贡献」。

因此，每一个 WebRTC 应用都必须实现自己的信令层。本章从设计原则出发，构建一套可扩展的 WebSocket 信令服务器，并讨论生产环境的安全、重连与 Room 状态管理。

配套代码：examples/webrtc-lab/signaling/

"跑通第一个通话，比读完十页 RFC 更有说服力。"

Ch1 我们学会了采集媒体。本章用 RTCPeerConnection 把媒体发给另一个浏览器——第一个完整 P2P 视频通话。

Serge Lachapelle 在 WebRTC for the Curious — 历史 中解释了一个关键设计决策：IETF 刻意不对信令（Signaling）重新标准化，因为 SIP 等方案已存在，"重新标准化只会引发政治斗争"。这意味着 WebRTC 只标准化了媒体通道（SDP、ICE、DTLS、SRTP），而 Offer/Answer 的传递方式完全由应用决定——本章先用「复制粘贴 JSON」理解原理，Ch3 再替换为 WebSocket 信令服务器。

配套代码：examples/webrtc-lab/client/ch02-p2p-basic/

"在建立任何 P2P 连接之前，你得先拿到媒体。"

上一篇 Ch0 架构全景 我们画了协议栈地图。本章从栈顶最直观的入口开始：如何把摄像头、麦克风和屏幕变成浏览器里的 MediaStream。

Serge Lachapelle 在 WebRTC for the Curious — 历史 中回忆：Gmail 语音视频聊天的前身需要分别授权 GIPS 音频、Vidyo 视频、libjingle 网络三个子系统，"每个子系统都有完全不同的 API"。WebRTC 标准化工作的核心目标之一，就是把 媒体采集 这一层统一成开发者今天使用的 navigator.mediaDevices API——让你不必再为每个浏览器插件写一套集成代码。

配套代码：examples/webrtc-lab/client/ch01-media-devices/

"WebRTC 不是某一个 API，而是一整套让浏览器能够安全、低延迟地交换实时媒体的开放标准。"

如果你曾经尝试在网页里做视频通话，大概率遇到过这样的困惑：RTCPeerConnection 的文档能看懂，但 ICE 一直 failed；SDP 里一堆 a=rtpmap 不知道在协商什么；明明本地预览正常，对方却听不到声音。

这些问题的根源，通常不是某个 API 调用错了，而是缺少一张 WebRTC 协议栈的全景地图。

本系列 WebRTC 全景实战 共 16 篇，将从架构认知出发，逐层深入到信令、SDP、ICE、DTLS/SRTP、RTP/RTCP、编解码、拥塞控制、SFU 架构与生产部署，每篇均配套 examples/webrtc-lab 实战代码。本文作为第零章，回答最根本的问题：WebRTC 是什么？它从哪来？它由哪些层组成？