WebRTC 音频数据处理中，期望可以实现音频数据处理及传输，延时低，互动性好，声音平稳无抖动，码率低消耗带宽少等。在数据传输上，WebRTC 采用基于 UDP 的 RTP/RTCP 协议，RTP/RTCP 本身不提供数据的可靠传输及质量保障。公共互联网这种分组交换网络，天然具有数据包传输的丢失、重复、乱序及延时等问题。WebRTC 音频数据处理的这些目标很难同时实现，WebRTC 的音频网络对抗实现中针对不同情况对这些目标进行平衡。
这里更仔细地看一下 WebRTC 音频数据处理管线，并特别关注与音频网络对抗相关的逻辑。
前面在 WebRTC 的音频数据编码及发送控制管线 一文中分析了 WebRTC 的音频数据编码及发送控制相关逻辑，这里再来看一下 WebRTC 的音频数据接收及解码播放过程。
WebRTC 的音频数据接收处理的概念抽象层面的完整流程大体如下：
对于 WebRTC 的音频数据接收处理过程， webrtc::AudioDeviceModule 负责把声音 PCM 数据通过系统接口送进设备播放出来。 webrtc::AudioDeviceModule 内部一般会起专门的播放线程，由播放线程驱动整个解码播放过程。 webrtc::AudioTransport 作为一个适配和胶水模块，它把音频数据播放和 webrtc::AudioProcessing 的音频数据处理及混音等结合起来，它通过 webrtc::AudioMixer 同步获取并混音各个远端音频流，这些混音之后的音频数据除了返回给 webrtc::AudioDeviceModule 用于播放外，还会被送进 webrtc::AudioProcessing ，以作为回声消除的参考信号。 webrtc::AudioMixer::Source / webrtc::AudioReceiveStream 为播放过程提供解码之后的数据。RTCP 反馈在 webrtc::AudioMixer::Source / webrtc::AudioReceiveStream 中会通过 webrtc::Transport 发送出去。 webrtc::Transport 也是一个适配和胶水模块，它通过 cricket::MediaChannel::NetworkInterface 实际将数据包发送网络。 cricket::MediaChannel 从网络中接收音频数据包并送进 webrtc::AudioMixer::Source / webrtc::AudioReceiveStream 。
如果将音频数据接收处理流水线上的适配和胶水模块省掉，音频数据接收处理流水线将可简化为类似下面这样：
webrtc::AudioMixer::Source / webrtc::AudioReceiveStream 是整个过程的中心，其实现位于 webrtc/audio/audio_receive_stream.h / webrtc/audio/audio_receive_stream.cc ，相关的类层次结构如下图：
在 RTC 中，为了实现交互和低延迟，音频数据接收处理不能只做包的重排序和解码，它还要充分考虑网络对抗，如 PLC 及发送 RTCP 反馈等，这也是一个相当复杂的过程。WebRTC 的设计大量采用了控制流与数据流分离的思想，这在 webrtc::AudioReceiveStream 的设计与实现中也有体现。分析 webrtc::AudioReceiveStream 的设计与实现时，也可以从配置及控制，和数据流两个角度来看。
可以对 webrtc::AudioReceiveStream 执行的配置和控制主要有如下这些：
对于数据流，一是从网络中接收到的数据包被送进 webrtc::AudioReceiveStream ；二是播放时， webrtc::AudioDeviceModule 从 webrtc::AudioReceiveStream 获得解码后的数据，并送进播放设备播放出来；三是 webrtc::AudioReceiveStream 发送 RTCP 反馈包给发送端以协助实现拥塞控制，对编码发送过程产生影响。
webrtc::AudioReceiveStream 的实现中，最主要的数据处理流程 —— 音频数据接收、解码及播放过程，及相关模块如下图：
这个图中的箭头表示数据流动的方向，数据在各个模块中处理的先后顺序为自左向右。图中下方红色的框中是与网络对抗密切相关的逻辑。
webrtc::AudioReceiveStream 的实现的数据处理流程中，输入数据为音频网络数据包和对端发来的 RTCP 包，来自于 cricket::MediaChannel ，输出数据为解码后的 PCM 数据，被送给 webrtc::AudioTransport ，以及构造的 RTCP 反馈包，如 TransportCC、RTCP NACK 包，被送给 webrtc::Transport 发出去。
webrtc::AudioReceiveStream 的实现内部，音频网络数据包最终被送进 NetEQ 的缓冲区 webrtc::PacketBuffer 里，播放时 NetEQ 做解码、PLC 等，解码后的数据提供给 webrtc::AudioDeviceModule 。
这里先来看一下， webrtc::AudioReceiveStream 实现的这个数据处理流水线的搭建过程。
webrtc::AudioReceiveStream 实现的数据处理管线是分步骤搭建完成的。我们围绕上面的 webrtc::AudioReceiveStream 数据处理流程图 来看这个过程。
在 webrtc::AudioReceiveStream 对象创建，也就是 webrtc::voe::(anonymous namespace)::ChannelReceive 对象创建时，会创建一些关键对象，并建立部分对象之间的联系，这个调用过程如下：
webrtc::AudioReceiveStream 通过 webrtc::Call 创建，传入 webrtc::AudioReceiveStream::Config，其中包含与 NACK、jitter buffer 最大大小、payload type 与 codec 的映射相关，及 webrtc::Transport 等各种配置。
webrtc::voe::(anonymous namespace)::ChannelReceive 对象的构造函数如下：
webrtc::voe::(anonymous namespace)::ChannelReceive 对象的构造函数的执行过程如下：
图中标为绿色的模块为这个阶段已经接入 webrtc::voe::(anonymous namespace)::ChannelReceive 的模块，标为黄色的则为那些还没有接进来的模块；实线箭头表示这个阶段已经建立的连接，虚线箭头则表示还没有建立的连接。
在 ChannelReceive 的 RegisterReceiverCongestionControlObjects() 函数中， webrtc::PacketRouter 被接进来：
这个操作也发生在 webrtc::AudioReceiveStream 对象创建期间。 ChannelReceive 的 RegisterReceiverCongestionControlObjects() 函数的实现如下：
这里 webrtc::PacketRouter 和 webrtc::ModuleRtpRtcpImpl2 被连接起来，前面图中标号为 5 的这条连接也建立起来了。NetEQ 在需要音频解码器时创建音频解码器，这个过程这里不再赘述。
这样 webrtc::AudioReceiveStream 内部的数据处理管线的状态变为如下图所示：
webrtc::AudioReceiveStream 的生命周期函数 Start() 被调用时， webrtc::AudioReceiveStream 被加进 webrtc::AudioMixer ：
这样 webrtc::AudioReceiveStream 的数据处理管线就此搭建完成。整个音频数据处理管线的状态变为如下图所示：
WebRTC 音频数据接收处理的实现中，保存从网络上接收的音频数据包的缓冲区为 NetEQ 的 webrtc::PacketBuffer ，收到音频数据包并保存进 NetEQ 的 webrtc::PacketBuffer 的过程如下面这样：
播放时， webrtc::AudioDeviceModule 最终会向 NetEQ 请求 PCM 数据，此时 NetEQ 会从 webrtc::PacketBuffer 中取出数据包并解码。网络中传输的音频数据包中包含的音频采样点和 webrtc::AudioDeviceModule 每次请求的音频采样点不一定是完全相同的，比如采样率为 48kHz 的音频， webrtc::AudioDeviceModule 每次请求 10ms 的数据，也就是 480 个采样点，而 OPUS 音频编解码器每个编码帧中包含 20ms 的数据，也就是 960 个采样点，这样 NetEQ 返回 webrtc::AudioDeviceModule 每次请求的采样点之后，可能会有解码音频数据的剩余，这需要一个专门的 PCM 数据缓冲区。这个数据缓冲区为 NetEQ 的 webrtc::SyncBuffer 。
webrtc::AudioDeviceModule 请求播放数据的大体过程如下面这样：
更加仔细地审视 WebRTC 的音频数据处理、编码和发送过程，更完整地将网络对抗考虑进来， WebRTC 的音频数据处理、编码和发送过程，及相关模块如下图：
在 WebRTC 的音频数据处理、编码和发送过程中，编码器对于网络对抗起着巨大的作用。WebRTC 通过一个名为 audio network adapter (ANA) 的模块，根据网络状况，对编码过程进行调节。
pacing 模块平滑地将媒体数据发送到网络，拥塞控制 congestion control 模块通过影响 pacing 模块来影响媒体数据发送的过程，以达到控制拥塞的目的。
由 WebRTC 的音频采集、处理、编码和发送过程，及音频的接收、解码、处理及播放过程，可以粗略梳理出 WebRTC 的音频网络对抗的复杂机制：
没看到 WebRTC 有音频带外 FEC 机制的实现。
参考文章
干货|一文读懂腾讯会议在复杂网络下如何保证高清音频
Done.