apt-get install git unzip lrzsz nodejs npm automake autoconf libtool nodejs-legacy python-webtest golang –y从http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html下载对应的版本到/usr/lib/jvm目录，然后解压到当前目录：
tar zxf jdk-8u151-linux-x64.tar.gzgetStats是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 />
近几年来，面部识别技术一直在智能手机创新的周围徘徊。随着苹果公司在iPhone X上推出Face ID，人们开始更多的关注面部识别技术。
我们团队向来喜欢实验和探索未来技术的潜力。所以我们与Cristiano一同利用WebRTC做一些关于面部识别的研究和探索。
在这篇文章中，我们会分享Cristiano的一些成果，他学到的东西，以及他对这种技术挑战和局限性的看法。
什么是WebRTC？
WebRTC是一个开源的网络框架，支持浏览器中的实时通信。它包括Web上高质量通信的基础构建模块，如用于语音和视频聊天应用程序的网络，音频和视频组件。
用Cristiano的话来说就是“一种可以通过浏览器调用麦克风，音频和摄像头的方法”。
Cristiano使用WebRTC，Canvas，微软Cognitive Services以及他们的Emotion API来创建了一个原型工具，该工具可以通过网络摄像头在浏览器中通过面部表情来检测情绪。
但是，这并不完美！
原因有两点：
第一点：这就是为什么我这么早就对此发表博客。我提出了3个规范说明，希望这些说明可以消除对Promise.all和“stable”测试的依赖。其实归根到底是用一种与执行rollback略有不同的API，其用于以防闪退的方式设置一个新的端描述。在某种程度上它也是重启ICE的方式，且不会干扰negotiationneeded。
第二点：关键是要编写一次代码，以抽象出该状态机。一旦正确完成操作，那么我们就不必再担心这种复杂性会影响该应用程序的其余部分。可以在应用上方标明“让行端”。现在只需在对等端连接上调用方法，而无需再担心此状态机。
如果您想知道为什么WebRTC无法自动处理此问题，很大一部分原因是有些人想要一个高级API，而其他人想要一个低级API。开发组无法生成适合所有人的“一刀切”产品。具体来说，如果不借助应用程序去解决当前体系结构中的问题，需要WebRTC定义自己的信令通道方式并将其强加给每个人，而这并不能满足大家不同的需求。
好消息是，高级别的API可以跳过这一步进行编写。这篇文章会向大家说明一种编写方法。
为什么要追求完美？
写在前面：如果你不必担心连接状态、闪退问题（信号冲突）、角色（你处于哪一方），就可以在实时WebRTC连接中添加和删除媒体，你会怎么做呢？不受时间和地点限制，你可以很容易地调用pc.addTrack（track，stream），并且你的连接路径只会显示在另一侧，不会有终端连接失败的风险。这是个白日梦？还有很多问题亟待解决？实际上，现在Chrome已经基本完成了协商，上述操作几乎可以运行！但是这样的操作并没有广泛应用，可能是因为“几乎”这两个字。这代表该操作有5%的时间无法工作，并且若Chrome闪退，风险太高了（无法从该操作回滚，只能运用pc.close（））。但API最初的承诺仍然有效。我们只需要一个除Firefox以外的浏览器来实现回滚，并用规范允许的方法修复一些明显的竞赛问题。
这是一种有助于操作的API！
令人惊讶的是，这在两端都有效！到目前为止，我们只是以一种方式发送媒体，但是另一端可以通过调用pc.addTrack（track，stream）以相同的方式发送媒体。这里的协商也是自动进行的。在这种情况下，提供者/应答者的角色只是颠倒了。
你可以继续对你的对等连接对象进行你所需的任何更改，API将在下一次JavaScript tick时根据需要重新协商。你再也不必担心协商问题了！
如果两端在同一时间进行更改，那就另当别论了。
那么，Glare问题呢？
“Glare”是指双方同时互相发送offer，破坏了两端的状态机。他们的线路交叉缠绕在一起。就像你和朋友同时开始说话，“你听说了……吗？啊，你先说吧！”计算机都会持续这样做且永远不会停止。除非这台计算机没有神经网络。
所有操作都无法进行了，只能回到手动协商！ ——等等，让我们看看是否可以修复这个问题。
Rollback解决远程更改问题
Glare是一个应用问题，因为我们可以用多种方法解决它。例如：如果我们使用外数据通道，使所有更改始终仅来自一端，则可以完全避免Glare问题。但我们使用的这个API很难缠，但我们距离解决问题只有一步之遥了。因此，我们使用Rollback来节省时间，旨在达成完美的协商。
礼貌让行
简而言之，我们将使其中一端“礼让”一些，对另一端说“对不起，您先请！”也就是说，其中一端会拒绝收到的offer。我们很幸运，因为这是“rollback”的作用：
人类一直以来都在努力寻找与别人沟通的新方式，但即使我们不断获得进展，像共享文件这种至关重要的事情仍然非常繁琐。我们总是需要将文件上传到服务器上，然后再发回给我们以备后用。所以我们需要面对现实，文件传输并不像发送消息给对方那样简单，总会涉及到一些其他方面的问题。但是，由于WebRTC数据通道所提供的能力，这种情况正在发生变化。在本篇文章中，我希望通过一个简单的点对点连接来建立聊天以及建立基本的文件传输，为你提供一个更清晰的WebRTC数据通道工作方式。
