上篇文章介绍 WebTC 原生demo 在Android 平台下编译方法，本次对原生demo AppRTC 的音视频弱网抗性进行分析，音频测试采用POLQA设备测试不同网络环境下的MOS分变化；视频测试采用自研方法计算卡顿率。弱网条件包括，丢包、延时、带宽限制。

丢包会导致语音卡顿，人耳主观感受就是吐字不清，这对于VoIP通话、在线会议都是不可接受，分析原生demo 在不同丢包率下的MOS分变化。

• 

• 

• 无丢包时，MOS分可以达到4.7分，几乎达到POLQA测试MOS的上限，音质非常好。
• 丢包率在15%时，MOS分已经低于3.5分，音频卡顿较严重。基本就是丢包抗性上限。
• 上下行丢包抗性相同，弱网优化策略大概率相同。

端到端延时，影响用户之间的交流。ITU标准认为，端到端延时超过400ms，人耳就能明显感知到延时。通过POLQA 设备测试原生demo 在不同丢包率下的端到端延时。

• 

• 

• 丢包率为0的情况下，端到端语音延时在400ms左右s满足标准要求，主观感受上优于业界大多数主流产品。
• 丢包率升高，延时同比增大，Jitterbuffer 开始生效，在丢包抗性范围内，延时保持低于400ms，业界同类产品延时基本达到600ms 以上 。

纯音频码率相对较低，基本保持在70kbps左右，如果用户的带宽低于70kbps 那么网络几乎处于不可用状态。限速场景重点验证WebRTC 原生demo的视频码率自适应能力。

• 

• 

• 限速2000kbps时，视频码率在1000kbps左右，说明平稳时期的码率在1000kbps，大概处于480p的水平。
• 随着可用带宽的逐步较少，发送码率也在逐渐降低，大多数情况下没有超过带宽上限。表明带宽探测准确性较高，编码码率范围广，码率适应能力强。

根据公开资料可知，WebRTC 使用的抗丢包技术包括FEC、ARQ。FEC主要采用异或实现N＋１系列FEC算法，丢包恢复能力有限。因此，丢包恢复主要以ARQ为主。抗拥塞主要是Sender Side BWE算法，实现带宽预测、动态码率调整。实际通话中具体采用哪些技术，以SDP协商为主。

视频配置项
a=rtpmap:96 VP8\/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx\/90000
a=fmtp:97 apt=96
冗余策略
a=rtpmap:100 red\/90000
a=rtpmap:101 rtx\/90000
a=fmtp:101 apt=100
a=rtpmap:127 ulpfec\/90000
音频配置
a=rtpmap:111 opus\/48000\/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1

从上述部分SDP协商结果来看，测试demo 默认开启了ARQ 和ulpfec ，拥塞控制算法使用的是 transport-cc (基于发送端码率调节)，视频采用VP8编码、音频采用opus 开启带内FEC策略。

综合测试结果来看，WebRTC的抗丢包能力基本保持在15% 左右，这与国内部分厂商宣传自家产品抗丢包能力达到70%+ 以上，有很大差距。测试demo 对于不同带宽的适应能力，端到端延时控制上，表现的很优秀。

从公开资料来看，WebRTC没有额外强调丢包抗性，重点突出拥塞控制算法的重要性，可以看出官方认为网络丢包，很大程度上是因为产生了拥塞。解决拥塞问题，就能减少丢包、乱序、抖动的发生。国内网络环境复杂多样，导致通话卡顿极易发生。

• 用户网络上下行不对等，上行网络容易产生丢包。
• 部分软件缺乏公平意识，原生GCC算法容易饿死。
• 传输链路设备质量参差不齐，很容易产生随机丢包、连续丢包。

就实时音视频领域而言，WebRTC 提供了一个很不错的平台，在此基础上可以实现 VoIP通话、办公会议，甚至是云游戏。 对于国内场景，还需要提升整体抗丢包能力，具体可参考ARQ实践、FEC实践。

后续会分析WebRTC里面的拥塞控制算法，欢迎订阅个人公众号coding手艺人。