第 9 部分回顾 · 控制面与媒体面如何合拢
第 9 部分把前八部分焊成一个整体——Call 是媒体中枢、RtpTransportControllerSend 是发送侧神经中枢、BitrateAllocator 分带宽、媒体引擎提供编解码、BaseChannel 缝合 SDP 与媒体。这一章串起这条主线，并给出「一个包的一生」全景。
第 9 部分回顾 · 控制面与媒体面如何合拢
第 9 部分是收束章——前八部分讲的是一个个子系统（协商、ICE、DTLS、RTP、拥塞控制、视频、音频、数据通道），这一部分讲它们怎么被组织成一次完整通话。
五个角色
第 9 部分的五章，是“一次通话”这台机器的骨架：
| 角色 | 是什么 | 位置 |
|---|---|---|
Call | 媒体面中枢：所有收发流的工厂 + 容器 + 协调者 | worker 线程 |
RtpTransportControllerSend | 发送侧神经中枢：GoogCC + pacer + PacketRouter + 反馈适配 | 通话级单例 |
BitrateAllocator | 把总带宽分给各流（音频优先） | Call 持有 |
| 媒体引擎 | 提供编解码器、建媒体通道 | media/engine/ |
BaseChannel | 缝合 SDP 协商与媒体 | 跨 worker/network 线程 |
一句话串起来：PeerConnection（控制面）协商出“发什么”，BaseChannel 把它落到媒体引擎建的通道，Call 据此建收发流，RtpTransportControllerSend 统一管这些流的拥塞控制 + 发送节奏，BitrateAllocator 把带宽分给它们。 这就是一次通话媒体面的完整骨架——控制面（第 1 部分）谈定，媒体面（第 6/7 部分）执行，而第 9 部分这几个角色是把两者接起来、并让多条流协调共享资源的中间层。
一个视频包的一生（全景）
用第 9 部分的骨架，把前八部分串成“一个视频包从摄像头到对端屏幕”的全景——这是本教程走到这里，你应该能看懂的整条链：
这条链里，几乎每一部分都出场了：采集编码（6） → 打包（4） → pacing(5/9) → 加密（3） → ICE 路径（2） → 网络 → 解密（3） → 解复用（4/9） → jitter buffer(6) → 解码（6） → 渲染，外加反馈闭环调码率（4/5）。第 9 部分的 Call / BaseChannel / RtpTransportControllerSend，就是让这条链上的每个环节各就各位、协同运转的组织者。
我们完成了什么
走到这里，本教程覆盖了 WebRTC 的核心引擎（第 0~9 部分）：
从“什么是 WebRTC”到“一次通话怎么被组织起来”，我们已经贯通了主干——会话怎么谈成（1）、连接怎么建立（2）、怎么加密（3）、媒体怎么打包传输（4）、怎么应对带宽变化（5）、视频（6）和音频（7）管线、数据通道（8），以及这一切怎么被 Call 组织成一次通话（9）。这是 WebRTC 的主体骨架。
接下来的部分，转向支撑这套引擎的基础设施与工程实践：第 10 部分看引擎底下的 rtc_base（线程、任务队列、时间、缓冲这些到处被用到的地基），第 11 部分看怎么观测和调试一次通话，第 12 部分看平台集成（Android/iOS/桌面采集）。骨架已经立起来了，后面是让它在真实世界里跑稳的血肉。
小结与下一部分
第 9 部分把前八部分焊成整体：Call（媒体中枢）、RtpTransportControllerSend（发送侧神经中枢）、BitrateAllocator（分带宽）、媒体引擎（供编解码）、BaseChannel（缝合 SDP 与媒体）——五个角色让协商、传输、编解码协同成一次通话。我们也用“一个视频包的一生”把整条链串了起来。
WebRTC 的核心引擎到此讲完。下一部分，深入引擎底下那层到处都在用的地基。👉 第 10 部分 · 基础设施 rtc_base。
参考资料
- [1] 本部分各章：Call、RtpTransportControllerSend、BitrateAllocator、媒体引擎、媒体通道。
- [2] libwebrtc 源码.
call/、media/engine/、pc/channel.cc全景。 - [3] WebRTC 官方架构图
g3doc/（印证本章的分层视角）。