WebRTC是一种标准，其次是一种协议，开发者可以通过follow这个协议来实现和WebRTC的互通。另外它还是一款引擎，因为它前身就是处理音视频的GIPS引擎。另外在这套引擎下还有大量的音视频算法，所以WebRTC也可以说是算法。市面上的实时通信相关的app越来越离不开WebRTC，即使应用的代码框架不相同，但WebRTC还是有很多经典算法值得借鉴，抽象出它的音视频引擎便可以用作PaaS或者SaaS服务。
1. WebRTC的由来
WebRTC的前身是GIPS，而GIPS的发展其实分为两个阶段，第一阶段为Global IP Sound，第二个阶段为Global IP Solution。它在Global IP Sound 阶段是作为音频通信引擎用于各种嵌入式系统设备中，主要负责回声消除、降噪、编解码等基础功能。之后继音频服务又加入了video服务，也就是Global IP Solution阶段，后来在和客户的沟通中他们不断的加入IP通信的协议、RTP协议等，以实现和网络连接的能力。但是由于商业上的不合理和销售策略的失败，最终还是被google以6千多万美元的价格给收购。而从技术的演进来讲，GIPS到WebRTC，其实是对Engine层做了封装，顺便还添加了原先GIPS缺失的网络模块。一般要提供音视频服务必须要有服务器，为了避免这种模式，WebRTC采用了P2P的通信模式。
2. WebRTC的主要模块
由于WebRTC本质上更接近于音视频引擎，所以如果当AV SDK用，会更便捷。当然前提是使用者有相当的经验，能够根据具体的场景定制化参数。音频部分在WebRTC中一共封装了4个模块，ANM（网络模块）、APM、ACM（编解码模块）、ADM，对应的video也有同样的4个模块，所以总共是8个模块。视频相对音频模块，视频部分可以挖掘的空间还很多，容易做出差异化。视频对网络的要求会更高，直播和通信是常见的场景。直播的时候关注的是清晰度，而通信方面更注重流畅度。侧重点的不同，带来了更多的参数调整。比如结合编解码器考虑抗丢包、结合降噪考虑编解码等，以及硬件的适配。
2.1 APM
APM中涵盖功能有AGC、ANS、AEC和DE 。其中AEC和ANS都有回声消除的功能，但是侧重点又有所不同，AEC的NLP算法考虑到了非常多的细节，如果想要研究它的算法，可以好好的看下它的专利说明。
2.1.1 AGC（Automatic Gain Control） 自动增益补偿功能
AGC可以自动调麦克风的收音量，使与会者收到一定的音量水平，不会因发言者与麦克风的距离改变时，声音有忽大忽小声的缺点。AGC主要任务是将非噪声部分调高，噪声部分调低，这里的重点就在于如何区分噪声，等于一个降噪的问题。WebRTC中的AGC是和VAD（Voice Activity Detection 语音动态侦测）放在一起的，VAD采用的是GMM模型，通过统计学的方式来判断当前是否是Voice，然后在结合到AGC上，所有虽然AGC中的参数仍然要调整，但是算法还是不错的，可以直接拿来用。
2.1.2 ANS（Automatic Noise Suppression） 背景噪音抑制功能
ANS可探测出背景固定频率的杂音并消除背景噪音，例如：风扇、空调声自动滤除。呈现出与会者清晰的声音。
2.1.3 AEC（Acoustic Echo Chancellor） 回声消除器
AEC可以消除各种延迟的回声, AEC是对扬声器信号与由它产生的多路径回声的相关性为基础，建立远端信号的语音模型（高斯模型），利用它对回声进行估计，并不断地修改滤波器的系数，使得估计值更加逼近真实的回声。然后，将回声估计值从话筒的输入信号中减去，从而达到消除回声的目的，AEC还将话筒的输入与扬声器过去的值相比较，从而消除延长延迟的多次反射的声学回声。根椐存储器存放的过去的扬声器的输出值的多少，AEC可以消除各种延迟的回声。
通常的回声消除有两种算法，一种是自适应滤波，一种是NLP(Non-Linear hypotheses，非线性处理）。在WebRTC之前其实自适应滤波已经做的足够好了，目前这方面的研究基本上已经停滞，可能在多通道和立体声的回声消除上还有一定的研究价值。NLP则不一样，它还有很多细节值得探讨，这是因为每个声腔的声音设计不同，造成了非线性部分的差异。
但在这种回声消除的方案中，却无法有效处理一些特殊情况，如：两端同时无声、 两端同时说话、较强的背景噪声、扬声器和麦克风以及其他因素引起的信号非线性失真等情况。在有些方案中也采用VAD (Voice ActivityDetection，话音检测），DTD (Double Talk Detection，两端同时有声检测），NLP(Non-Linear ftx)cessor，非线性处理）等模块，但是由于缺乏对这些模块的准确控制，因而也难以达到预期的设想效果。例如：采用基于相关性分析的DTD时，难以处理背景噪声很大的情况，此时，系统会持续误判为DT(Double Talk, 两端同时有声）状态，又如：采用NLP时，难以在有效抑制回声和保持近端语音质量中做出理想的折衷。
因此现有的利用自适应滤波进行回声消除的方法中，缺乏对自适应滤波的准确控制，因而在一些场合下，例如：两端无声，两端同时说话，较强的背景噪声等等时，自适应滤波不能稳定而高效的工作，甚至会系数发散。导致不能有效地消除回声，甚至人为引入噪声。
2.1.4 DE（Delay） 延时估计
DE是延时估计模块，现在几乎所有的延时估计模块的都用的这一套算法。
2.2 ACM
WebRTC的编解码器有ILBC、ISAC 、Opus，ILBC是窄带编码器、ISAC是宽带编码器、Opus是全带的音频和语音统一的编码器。在CPU性能较强且能够接受高带宽的情况下Opus可以做的非常好。
2.3 ANM
ANM做的是带宽估计和拥塞控制，由于现在带宽较大，所以音频方面的带宽估计已经很少有人在做了，视频方面还是比较常见。比较有意思的是音频的带宽估计被写入到了ISAC的代码中。我们知道丢包一般分为两种，随机丢包和bond丢包，拥塞就属于bond丢包的范畴，比如连续丢失多个包或无法发包都算作拥塞。
2.4 ANM
ANM中的PLC（Packet Loss Concealment 语音封包遗失补偿）是一种拉伸快进和慢放的算法，比如要在100毫秒的包中存放200毫秒的数据的时候，PLC就会将包给慢放以实现200毫秒的效果，通过这种方式来应对网络丢包。PLC的优势在于变速不变调。
WebRTC的重点就在于这些模块本身和它们之间的参数配置。但是这也带来了相应的缺点，我们要做面向移动端的功能实例优化、性能实例优化以及一些特殊优化，这也使得调试的次数越来越多。
2.5 WebRTC 应用举例
WebRTC可以用来做SaaS服务，但是需要先考虑要做的是什么类型的SaaS服务。比如对于不是基于Web的音视频通信服务，就还要考虑额客户端进行互通。而不同的行业对此的要求也不一样，像呼叫中心和教育类的通常会直接使用web进行服务。不过WebRTC在多浏览器上的兼容性并不好，视频编解码的支持也有所不同。使用的时候我们要根据服务质量要求和用户特点灵活使用p2p，比如在大部分用户都处于WiFi环境的情况下p2p可能是更好的选择，而对于4g网络p2p效果会差一些。若用户对服务质量要求比较高，个人建议应先着手建立服务器，并部署运维监控负载均衡等能力，让后端服务器出现的问题对用户无感知。应用这些措施应对纯web端的SaaS服务其实还有所不足，有很多细节问题仍需处理。比如用户外接了音频设备，或者某款浏览器的音频通信产品在本机上没有适配好，从而产生回声等各种问题。
如果要提供PaaS平台给厂商使用，在包含SaaS的各种基础服务之外，还需要抽象出一套API，然后再针对各个移动设备做适配，还要根据应用场景提供多种增值功能，提供针对场景的特殊优化和包裁剪等。因为PaaS不同于SaaS它在上层应用上并没有做的过于精细，其主要目标还是为了提供更稳定更高效的通信服务。
感谢声网Agora.io音乐工匠高泽华在“架构师修炼之道——极光开发者沙龙JIGUANG MEETUP”中，进行的《WebRTC架构优化及实践》演讲分享。现在我们对webrtc有了一定的认识，那WebRTC是否会引来一波“白菜价”通信服务热潮呢？欢迎评论～
相关文章：
Webrtc AGC 算法原理初识（一）
Webrtc AGC 算法（二）