WebRTC相关技术
简介
WebRTC的诞生，就是基于浏览器的多媒体即时通信。而且 WebRTC 能够实现：实时双向音视频、主流浏览器支持、开发者容易入手、使用范围广且技术开源成熟等条件，且具有毫秒级的延迟特性。
而且，它在浏览器端有成熟的 API ，我们无需多少代码就可以满足无客户端视频通话的目的。可以说，WebRTC 是将前端技术和音视频嫁接起来最佳的媒介
建立连接流程
WebRTC建立连接的流程如下：
A 为caller（呼叫端），B为callee（被呼叫端）。
- 首先 A 呼叫 B ，呼叫之前我们一般通过WebSocket等协议，让对方能收到信息。
- B 接受应答，A 和 B 双方开始创建RTCPeerConnection，用来关联 A 和 B 的 SDP 会话信息。getUserMedia() API获取支持的本地视频和音频流。
- A 调用 CreateOffer 创建信令，同时通过 setLocalDescription 方法在本地实例 PeerConnection 中存储一份。
- 调用信令服务器将 A 的SDP转发给B。
- B 接收到 A 的 SDP 后调用 setRemoteDescription ，将其储存在初始化好的 PeerConnection 实例中。
- B 同时调用 createAnswer 创建应答 SDP ，并调用 setLocalDescription 储存在自己本地 PeerConnection 实例中）。
- B 继续将自己创建的应答 SDP 通过服务器转发给 A。
- A 调用 setRemoteDescription 将 B 的 SDP 储存在本地 PeerConnection 实例。
- 在会话的同时，从图中我们可以发现有个 ice candidate ，这个信息就是 ICE（Interactive Connectivity Establishment）候选信息，A 发给 B 的 B 储存，B 发给 A 的 A 储存，直至候选完成。找到较好的可用传输路径。
- 开始流媒体传输，一旦连接建立完成并完成参数协商，端点将开始相互发送音视频数据媒体流。
- 关闭连接：当连接结束后需要关闭连接，释放资源。
需要注意的是，WebRTC连接需要一个信令服务器来协商连接设置和媒体流交换，但是建立连接的过程并不需要实际的服务器，可以通过P2P的方式直接建立连接。可以搭建作为中转服务器为无法直连的客户提供转发服务。
STUN服务
STUN（Session Traversal Utilities for NAT，NAT会话穿越应用程序）是一种网络协议，它允许位于NAT（或多重NAT）后的客户端找出自己的公网地址，查出自己位于哪种类型的NAT之后以及NAT为某一个本地端口所绑定的Internet端端口。这些信息被用来在两个同时处于NAT路由器之后的主机之间创建UDP通信。该协议由RFC 5389定义。
这个服务主要是一个打洞服务，让nat后的主机能够相互直连通信。
TURN服务
TURN的全称为Traversal Using Relays around NAT，是STUN/RFC5389的一个拓展，主要添加了Relay功能。如果终端在NAT之后， 那么在特定的情景下，有可能使得终端无法和其对等端（peer）进行直接的通信，这时就需要公网的服务器作为一个中继， 对来往的数据进行转发。这个转发的协议就被定义为TURN。
这个服务虽然和STUN配套使用，当常常单独部署。用于打洞失败的场景，帮助用户转发流量。使nat后的用户可用成功连接。