原标题：Web-based voice command recognitions
上一次我们将音频buffer转成了图像，这一次，我们将采取这些图像，并使用deeplearn.js训练一个神经网络。结果是一个浏览器上的demo，你可以说出“yes”或者“no”的指令，然后像这样实时的显示出识别结果：
虽然它离完美还差的很远，但却是在网上进行各种音频识别的一个很好的起点。现在让我们深入了解一下这是如何工作的。
快速入门：培训和测试一个指令识别器
下面是如何训练yes/no分类器的方法：
1. 跳转到模型训练页。这会花一点时间来下载训练数据（yes/no）。
2. 点击训练按钮，你会看到一个显示训练进度的图表。一旦你准备好了（会花一点时间，具体时间长短取决于你的硬件），停止训练，并且点击保存权重（文件）按钮。这会下载一个JSON文件。
WebRTC是一个协议，允许人们使用JavaScript在两点之间创建实时通讯。
我们可以用这个结构使两个或更多浏览器之间实现直接交流，而不需要中心服务器。
服务器只需要在连接的时候被使用，因此每个客户端知道如何连接彼此。
我们可以使用这个特性创建什么类型的App呢？例如，直接网络摄像头连接。点对点通话，文件共享，还有更多。
本教程我会介绍一个当你第一次使用的时候，会发出惊呼的App：一个网络摄像头通信App.
我们不会使用原始WebRTC API,然而，我们需要注意很多细节。这就是library的作用，它们做出了很好的抽象，人们可以集中精力创建App而不是将精力花费的底层API上。
其中一个library是PeerJS,它使得实时通信变得非常简单。简单来说就是WebRTC,它的抽象使得结果获取更快，之后你可以学习内部是如何运作的。
建议：当你建立一个App时候使用Bit分享到一个可重复利用的集合中，并且在你所有的项目中同步它们！不妨试一下，可以加快你的工作速度。
多方WebRTC选择3的方案是SFU，它表示选择转发单元。SFU背后的想法与MCU相同。它在中间有一台媒体服务器，所有peers向它发送流，唯一不同的是，它不会做繁重的处理，服务器将其引到其它peers，这样它们可以进行任何所需的处理。
这样服务器不需要能支持那么繁重的处理运算，你可以利用MCU提供的好处，同时避免Mesh hassles和MCU的高代价。
SFU的结构如下图所示：
端到端通信的一个主要问题是，在许多情况下，这些端点并不在公共互联网中，而是位于网络（和端口）地址转换器（NAT）后面的专用地址空间中。随着互联网从DARPA项目发展成为全球范围的网络，很快就会明白IPv4的232地址空间早晚会用尽。
在20世纪90年代，开发了多种策略来延迟IPv4地址耗尽的时间，其中之一就是NAT的设计。NAT将端点的真实IP地址隐藏于世界其他地方，这使得端点之间建立端到端直接连接变得困难。这就是协助框架—包括STUN和TURN（或使用中继NAT穿越）—派上用场的地方。
平均约有30%的P2P会议有一个端点通过TURN服务器连接。如果没有TURN中继服务器的帮助，这些用户将无法进行通信。因此，开发者需要知道TURN服务器是什么，以及为什么它对WebRTC通话的重要性。
ICE和STUN
我周二登录了一次YouTube，注意到右上角有一个新的摄像头图标，并写着“Go Live（New）”，所以我点了一下它试试看会发生什么。事实证明，你现在可以直接从浏览器进行直播。这听起来真的很像WebRC，所以我加载了chrome://webrtc-internals来查看，并确定它就是WebRTC。我们总是对大规模部署很好奇，所以我立即请WebRTC逆向工程大师Philipp “Fippo” Hancke进行更深入的调查。本文剩下的部分就是他对此的分析。— 编辑：chad hart
NAT和点对点通讯：有何问题？
虽然客户端或服务器能够通过NAT /防火墙顺利连接，但这样的操作会对点对点通信造成严重破坏。点对点通信通常由端点应用程序打开，或用主机操作系统上的特定IP端口侦听。之后该端口可以与准备交换数据的另一台主机发信号或进行通信。应用程序中，点对点IP端口发出的指令通常用服务器或其他对等体发现机制来完成，与实际的点对点数据有所区分。示例如下：
什么是NAT？
NAT意为网络地址转换（https://en.wikipedia.org/wiki/Network_address_translation）。它是一种广泛使用的系统，多用于保留IPv4地址，或使本地网络管理员能够控制本地拓扑结构。实际上NAT技术多种多样，在此不多赘述。最常见的NAT设备通过改变通过它的数据包的IP报头信息得以运行。通常情况下NAT技术与防火墙结合完成，大多数家用路由器都如此，这些路由器通常在保证安全性的同时还保留了IPv4的地址空间，可谓一举两得。但正如我们所见，这也可能导致某些程序和协议出现问题，尤其是像WebRTC这样尝试进行点对点连接的。
常见的NAT 或者防火墙场景是私人或受保护的IP端点子网的场景，与公共互联网的环境不同。
WebRTC直播流中，大规模所带来的挑战
1:1 != 1:1,000,000
只要是关于WebRTC的问题，规模有影响。
人们常常有这种想法，如果我能够运行一个1对1的视频通话，那么把它改进成一个三方视频通话也很简单。如果有了三方通话，那么距离四方通话也只有一步之遥了。假如我们已经到了四个人同时通话的地步，既然4和10之间没差多少，所以10个人通话肯定也是一样的。如果我们可以进行10人通话了，那么50人，甚至100人是不是也没问题了？
处理多用户之间的互动通话的做法放在实时广播方面也是正确的。
1对1的广播与1对100不同，当然与1比10,000与1比1,000,000也不同。
