作者：Tsahi Levent-Levi（原文链接）
翻译：刘通
原标题：How WebRTC Works
前文链接：WebRTC是如何工作的1
音频和视频
音频和视频是你在WebRTC中会主要注意到的内容。几乎所有的WebRTC demo和示例中都会展示这些内容。原因很简单—视频非常的直观并且有很高的互动性。
WebRTC中的音频和视频使用编解码器工作。编解码器的功能是压缩和解压音频和视频数据。你可以在WebRTC中使用不同的编解码器，但是在本文中我不会涉及关于编解码器的内容。
音频和视频之所以会吸引人们的兴趣，另外一个原因是它们是以低延迟发送的。如果由于网络问题导致数据包丢失，可能并不值得重新传输它。
WebRTC使用已知的VoIP技术来进行媒体处理，以及将其通过网络发送，而这一切都是通过SRTP（加密并且安全的RTC版本）完成的。WebRTC通过使用以前没有得到广泛应用的SRTP中的特定机制做了一些小更改，所以如果你已经部署了VoIP服务，与WebRTC进行交互会有一点困难。
数据也一样
你也可以使用WebRTC发送任意数据。这通过WebRTC中的数据通道来完成。
当你想要在不通过任何服务器（不过你可能仍然会需要一个TURN服务器来进行中继）的情况下直接地在浏览器之间发送消息时，就会用到数据通道。
NAT穿越
能直接通过浏览器进行通信的确很棒，但这并不总能成功。
互联网是30-40年前在客户端-浏览器模式上建立的。自那之后有所改变。今天绝大多数的用户都在防火墙或者NAT的后面访问互联网。这些设备通常会更改用户设备的IP地址，并将其在打开的网页中屏蔽。屏蔽可以只是这样的，也可以提供一些“保护”措施，其中未经请求的浏览不允许进入用户设备。这种方法的问题在于，WebRTC使用不同的媒介来传输信息和媒体，所以想要理解什么是经过请求的，什么是未经请求的流量是不容易的。
除此之外，有些企业认为在未经审查之前不应该允许任何种类的数据流入或者流出他们的网络。
所以就带来了这些场景：
在左边的那个人，由于STUN请求，他可能真的知道右边那个人的公共IP地址。但是公共IP地址。但是公共IP地址可能只对STUN服务器可见，并且让其他人都只通过一个“小孔”进行连接，但是创建这个小孔还是有可能无法做到。
为了解决这些问题，用户的设备将不能直接与另一个专用网络内的其他设备通信。解决办法是通过公共服务器转发受阻挡的媒体。这也就是TURN服务器的目的：
由于复杂性较高，WebRTC会话将采取以下步骤：
1. 发送一个SDP offer给Web服务器。这个SDP消息简述了设备想要进行交换的媒体通道，以及如何找到它们。
2. 通过web服务器从其他设备处接收SDP应答。记住这里指的其他设备可能是一个媒体服务器。
3. 启动一个称为ICE协商的过程，意在查明设备是否可以直接到达，端到端形式到达，或者是否需要通过TURN服务器进行媒体中继。这个过程最好使用trickle ICE完成，但这是另一个领域范围内的了。
4. 一旦完成，媒体就可以直接在设备之间进行流动了。
所有这些需要在浏览器上使用JS代码异步编程。在服务器端，你可以使用任何想管理的媒体和信令。
通常情况下，开发人员不会直接真滴WebRTC API进行开发，而会使用开源或者商业的第三方框架及模块来为他们完成这项工作。
未完待续……
