7.2.4 从 RTP 到 WebRTC（From RTP to WebRTC）

前三节把 RTP/RTCP 的设计拆解完毕。回头清点，这套 1996 年定型的框架有两个鲜明的时代胎记：它假设 参与者彼此可达——组播会议室里没有 NAT 与防火墙；它也假设 会话由人事先约好——会议地址靠邮件、电话本口口相传。把这两条假设放进 2010 年代的互联网：绝大多数终端躲在 NAT 之后，而打电话的人变成了浏览器里的 JavaScript。WebRTC 的诞生，就是在 不换骨架 的前提下，为 RTP 补齐这两块时代短板。

短板一：彼此可达的假设，败给了 NAT

RTP 的无连接设计在组播世界里潇洒自如，一遇到 NAT 就寸步难行：你的包能出去，外面的包却进不来——"听到 SSRC 就算认识你" 的浪漫，被地址转换挡在门外。

WebRTC 的应对是一套完整的连通性探测体系 ICE（Interactive Connectivity Establishment）：把可能的通信路径——本机地址、经 STUN 服务器探出的 NAT 映射地址、经 TURN 服务器中继的兜底地址——全部收集起来两两探测，选出能通且最优的一条 [9]。STUN 与 TURN 的角色泾渭分明：前者帮你 看清自己在 NAT 后的模样，争取直连；后者在直连无望时 提供一台中立的中继，保证通话无论如何都能建立。代价（中继带宽）与收益（连通率）的权衡，留给了部署者。

短板二：会话约定的方式，交给了应用

传统 VoIP 世界里，SIP 这样的信令协议负责 "找到对方、谈拢参数"。WebRTC 做了一个耐人寻味的决定：信令不定义。规范只约定浏览器两侧的能力与媒体格式如何描述与交换（SDP 的 Offer/Answer 模型），至于这段描述经过 WebSocket、HTTP 还是鸽子传书送达对端，协议栈一概不管 [9]。

这个留白初看像偷懒，实则是深思熟虑的边界划分：信令天然与业务形态绑定——社交应用、在线课堂、远程医疗的会话建立逻辑千差万别，任何一种标准化都会成为另一批人的束缚。把信令还给应用，WebRTC 换来了 "任何网站都能嵌入实时通话" 的普适性。

RTP 的装备升级：加密与复用

骨架未动，装备却全面升级。在 WebRTC 里，SRTP（加密 RTP）是强制要求 [9]——明文 RTP 的时代正式落幕，密钥经 DTLS 握手协商；RTCP 与 RTP 复用同一端口（rtcp-mux），减少 NAT 穿透的战线；Trickle ICE 允许候选地址边收集边交换，不必等齐再开局 [9]。这些增强全部以 profile 扩展、负载规则的形式挂接——RFC 3550 的本体一个字没动。三十年前定下的框架化分层，再一次兑现了它的红利。

小结：天平的一极

回看 7.2 全节，RTP 家族的选择一以贯之：实时性压倒一切，可靠性让位于时效，秩序恢复下放给接收方，网络适应交给反馈环。它是 "可靠性 - 实时性" 天平上最极端的一极——为了毫秒级的互动体验，宁可接受丢包、抖动与一整套补偿机制。

但天平还有另一极。就在 RTP 壮大的同一个年代，另一条技术路线做出了完全相反的选择：既然观众对直播的期待是 "稳定不花屏"，那就抱住 TCP 的可靠性不放，用几秒的延迟换一路安稳——这条路线叫 RTMP，它统治了直播行业整整十年。下一节，我们走进 Flash 时代的这套传奇协议。