此版块是《WebRTC音视频实时互动技术原理、实战与源码分析》一书的问题讨论区。在这里，你可以针对于书中的任何问题向作者提问。

===================================================

《WebRTC音视频实时互动技术原理、实战与源码分析》勘误表

勘误一

a. P3, 1.2节，第三段中的 AVI 应为 AV1.
b. P11, 2.1.3节，第一段中的 AVI 应为 AV1
c. P22，3.2.2 节，第三段中的所有 AVI 应为 AV1
d. P261， 13.5节，第二段中的 AVI 应为 AV1

勘误二

P15，第三段应为：

“从上面的描述中你可以看到，在 WebRTC 架构的四层中，最复杂、最核心的是第三层，即 引擎层，因此，这里我再对引擎层内部的关系做下简要介绍。引擎层包括三部分内容，分别是: 音频引擎、视频引擎以及网络传输。其中 音频引擎 和视频引擎是相对比较独立的。不过，它们 都需要与网络传输层(transport)打交道。也就是说，它们都需要将自己产生的数据通过网络 传输层发送出去;同时，也需要通过网络传输层接收其它端发过来的数据。此外，

音频引擎与 视频引擎由于要进行音视频同步的原因，所以它们之间也存在着关联关系。”

勘误三

P98，表6.2各NAT之间可穿越表应为：

NAT_table.png1848×742

勘误四

P103，6.4.2小节倒数第二应为：

turn_protocal.png1322×854

“因为主机 A 拿到了主机 B 的 Relay 类型的 Candidate，即 RelayB，所以主机 A 可以直接将音视频数据发向 RelayB。TurnServer 从 RelayB 接收到数据后，会将数据 打包成 TURN 消息，经 3478 端口发往主机 B 。主机 B 收数据后，再利用 TurnClient 模块将数据从 TURN 消息中取出，交给其它模块做进一步处理; 同理，主机 B 与主机 A 的操作流程是一样的。TurnServer 从 RelayA 收到数据后，将其打包成 TURN 消息， 也要经过 3478 端口转发给主机 A 。”

勘误五

P114，第一段应为：

“程， 默认情况下 WebRTC 会将 VP8/H264 等编码器编码后的数据再交由 red 模块编码，生成带一些冗余信息的数据包，这样当传输中某个包丢了，就可以通过其他包将其恢复回来，而不用重传丢失的包。了解了上面这些内容后，第 16～18 行代码的含义应该就清楚了，即 PT 值为 124 表示需要使用 red 对之前编码好的数据再进行 red 处理，119 是 PT=124 重传数据 包的 PayloadType。如果用 Wireshark 等抓包工具抓取 WebRTC 媒体数据包时会发现它们都 是 red 包，而在 red 包里装的是 VP8/H264 编码的数据。”

勘误六

P124，代码行号69，内容应为：

69 使用Opus时，每个音频帧的最小间隔为10毫秒，使用带内FEC
70 a=fmtp:111 minptime=10;useinbandfec=1

勘误七

P168，图9.10有误，正确的图如下所示：

勘误八

P175，10.1 节的第一段应为：

“在 WebRTC 中包含多种拥塞控制算法，有 GCC、BBR和 PCC。GCC 根据其实现又可细分为基于发送端的拥塞控制算法 Transport-CC4和基于 接收端 的拥塞控制算法 Goog-REMB。”