作为Google开源的技术，WebRTC并不是一个可以拿来就用并且性能很好的产品，需要工程师们对其进行较多的改善。本文主要来谈一谈WebRTC的优缺点。
WebRTC的优点：
1. 方便。对于用户来说，在WebRTC出现之前想要进行实时通信就需要安装插件和客户端，但是对于很多用户来说，插件的下载、软件的安装和更新这些操作是复杂而且容易出现问题的，现在WebRTC技术内置于浏览器中，用户不需要使用任何插件或者软件就能通过浏览器来实现实时通信。对于开发者来说，在Google将WebRTC开源之前，浏览器之间实现通信的技术是掌握在大企业手中，这项技术的开发是一个很困难的任务，现在开发者使用简单的HTML标签和JavaScript API就能够实现Web音/视频通信的功能。
2. 免费。虽然WebRTC技术已经较为成熟，其集成了最佳的音/视频引擎，十分先进的codec，但是Google对于这些技术不收取任何费用。
3. 强大的打洞能力。WebRTC技术包含了使用STUN、ICE、TURN、RTP-over-TCP的关键NAT和防火墙穿透技术，并支持代理。
WebRTC的缺点：
getStats是WebRTC一个非常重要的API，用来向开发者和用户导出WebRTC运行时状态信息，包括网络数据接收和发送状态、P2P客户端媒体数据采集和渲染状态等[1]。这些信息对于监控WebRTC运行状态、排除程序错误等非常重要。<br />
本文首先描述W3C定义的getStats标准，然后展示如何在JS层调用getStats，最后深入分析WebRTC源代码中getStats的实现。全文从标准到实现，全方位透彻展示getStats的细节。<br />
getStats的标准由W3C定义，其接口很简单，但是却返回丰富的WebRTC运行时信息。其返回信息的主要内容如下[2]：<br />
另外还有一些杂项统计，如DataChannel度量，网络接口度量，证书统计等等。在众多信息中，有一些反映WebRTC运行状态的核心度量，包括往返时间RTT，丢包率和接收端延迟等，分别表述如下：<br />
通过以上分析可知，getStats的返回信息包含WebRTC数据管线的各个阶段的统计信息，从数据采集、编码到发送，再到数据接收、解码和渲染。这为监控WebRTC应用的运行状态提供第一手数据。<br />
前两天收到一个经过处理的webRTC源码，主要包含AEC，NS，AGC，VAD四项主要功能。要将其编译成一个ARM平台下库供Android APP使用。
怎么说呢，相当坑，源码好像是从GitHub上翻出来了，大牛精简抽离后，x86下可至今编译，但ARM下就需要下点功夫了。改起来相当累啊，耗时一个半工作日搞定，成果如下，请品鉴。
configure时为了好看，连接符可能不太标准。ANDROID_NDK的需自行设定。仅有脚本还不行，源码中还需做些微修改，这里就不再上传了，都是基本的编译问题，很简单。
在刚刚落幕的 WWDC17 上，苹果为我们带来了一个不小的惊喜 —— 其浏览器内核WebKit将正式支持 WebRTC，而未来基于 WebKit 内核的苹果浏览器，比如macOS High Sierra、iOS 11 中的 Safari 浏览器和Safari 技术预览版 32，都将使用到 WebRTC 技术。
适逢我也正在倒腾一些 WebRTC 的东西，万事开头难，搞事情最怕的就是开始的拦路虎，编译环境、demo 工程、Server 如何部署，这三个问题（尤其是最后一个）想必会浇灭很多朋友的热情之火。经过近两周的不懈奋斗，我总算把这几头拦路虎一一解决，今天我就在这里把这一套开箱即用的 WebRTC 开发环境分享给大家。
注意：这里我假设大家具备 Docker 的基本使用能力，如不具备，请自行搜索相关教程。
平台UBUNTU16.04
sudo apt-get install build-essential
1、安装ninja
mkdir -p ~/ninja && cd ~/ninja
git clone https://github.com/martine/ninja
cd ninja
python ./bootstrap.py
技术上来说，从IP摄像头实现在线广播并不需要WebRTC。IP摄像头本身就是服务器，可以自行连接路由器并传输视频内容。既然这样，我们为什么还需要WebRTC？
有两个原因：
1.随着观看以太网广播的观众增加，他们会逐步感受到带宽的不足，然后是摄像头资源，如果观众持续增加的话；
2.如上面提到的，一个IP摄像头就是一个服务器。但是它使用什么协议传输视频到浏览器或者移动设备？一个使用HTTP的摄像头很有可能基于HTTP传输视频帧或者JPEG图像。但是，HTTP流并不完全适用于实时视频传输。对于请求式视频，它确实工作良好，但是仅限于互动性和延迟要求不高的场合。确实，如果你在线观看一部电影，延迟5-10秒确实不太重要。好吧，除非你在和其他人同时观看：“oh，不，杰克谋杀了她！”爱丽丝给鲍勃发送信息10s之后，鲍勃才看到了这一幕悲剧。
另外一个选项是RTSP/RTP加上H.264。但是这种情况下浏览器需要安装一个视频播放插件，例如VLC或者QuickTime。这类插件将会接受并播放视频，就像播放器一样。但我们需要真实的基于浏览器的流，不需要任何附加的工具。
好，现在让我们“sniff”我们的IP摄像头，学习一下它到底向浏览器发送了什么。我们采用D-Link DCS 7010L来做测试：
