Google开源WebRTC框架调研
- 公司开发音视频项目，需要用到webRTC，于是做一番调研了解webRTC工作流程，调研结果如下：
概念
Signaling信令服务器（socket服务器）
用于交换元数据来协调通信的服务器。一般通过socket来实现。
元数据包括：会话控制消息用于打开或关闭通信；错误消息；媒体元数据；密钥数据；网络数据等等。
NAT
网络地址转换(NAT,Network Address Translation)属接入广域网(WAN)技术，是一种将私有（保留）地址转化为合法IP地址的转换技术。
NAT穿越服务器（STUN/TURN）
- STUN：首先在RFC3489中定义，作为一个完整的NAT穿透解决方案，英文全称是Simple Traversal of UDP Through NATs，即简单的用UDP穿透NAT。在新的RFC5389修订中把STUN协议定位于为穿透NAT提供工具，而不是一个完整的解决方案，英文全称是Session Traversal Utilities for NAT，即NAT会话穿透效用。RFC5389与RFC3489除了名称变化外，最大的区别是支持TCP穿透。
- TURN：首先在RFC5766中定义，英文全称是Traversal Using Relays around NAT:Relay Extensions to Session Traversal Utilities for NAT，即使用中继穿透NAT:STUN的扩展。简单的说，TURN与STURN的共同点都是通过修改应用层中的私网地址达到NAT穿透的效果，异同点是TURN是通过两方通讯的“中间人”方式实现穿透。TURN服务指的是中继型NAT遍历服务器，其地址是一个公共ip地址，用于转发数据包给对端浏览器。当2个对等端因为NAT类型而无法建立连接时(当遇到对称型NAT会导致打洞失败)，才需要使用中继服务器。
ICE: 交互式连接建立（Interactive Connectivity Establishment）
ICE是一种标准穿透协议，利用STUN和TURN服务器来帮助端点建立连接。WebRTC当通过信令server交换完sdp, candidate后，之后依靠ICE框架在2端之间建立一个通道。
SDP
SDP是 SessionDescription Protocol的简称，它是一套描述流媒体交互参数的标准协议，即RFC4566。WebRTC使用SDP协议描述会话参数。
PeerConnection
是webRTC的核心类。作用如下：
使用ICE框架来计算对等端之间的最佳路径，并根据需要使用STUN和TURN服务器；
处理所有的SDP消息交换过程（不通过网络本身发送，而是生成他们并处理输入的消息）；
实现ICE以连接媒体通道，如果需要的话，要通过TURN中继；
实时地对音视频数据进行编码和解码；
通过采用自适应的抖动缓冲区，带宽估计，数据丢包隐藏，前向纠错以及其他算法来处理网络问题；
使用诸如回声消除算法来处理本地音频问题。
业务相关
实现实时音视频流程
准备工作：
获取信令服务器地址。用于收发消息。
获取NAT穿越服务器地址，包含STUN地址和TURN地址。用于流媒体传输。
根据业务需求，可选择增加媒体服务器（视频录制，服务端混流等等）。
通讯交互过程：
1、主播A进入房间，通过socket信令服务器发送进入房间的信令。
2、主播A接受socket信令服务器返回的消息，其中包含了服务器分配给自己的id。
3、主播A使用webTRC框架创建本地媒体数据的采集和预览。
4、主播B进入房间，发送进入房间的信令。服务器返回消息，其中包含了已存在直播间A的id。
5、主播B创建本地媒体数据的采集和预览，同时给A创建PeerConnection连接。
6、主播B创建offers消息，其中包含自身的sdp信息，B角色此时为Caller。
7、主播B的sdp创建成功后，先setLocalDescription保存到本地。
8、sdp连接成功，主播B将自己的offer通过socket信令服务器传给A。
9、A收到socket信令服务器offers消息，其中包含了B的所有媒体sdp信息。A的角色变成接受者Receiver。
10、A将B的sdp信息保存本地。
11、A获取到B的offer后，sdp连接成功。A调用 createAnswer 方法创建 answer 消息， 同样，answer 消息中的内容是 A 的 sdp信息。sdp创建成功后，将自己的sdp信息setLocalDescription保存到本地。
12、主播A将自己的answer 通过socket信令服务器传给B。
11、主播B收到A的answer消息，调用setRemoteDescription保存到本地。
13、主播B不断发送IceCandidate候选者信息给主播A。
14、主播A收到信令服务器IceCandidate消息，其中包含主播B的信息，udp地址，socketId等。候选人消息会接受很多次，都保存到RTCPeerConnection中。
12、主播A不断发送IceCandidate候选者信息给主播B。
13、主播B收到信令服务器IceCandidate消息，其中包含主播A的信息，udp地址，socketId等。候选人消息会接受很多次，都保存到RTCPeerConnection中。
14、主播B从接口回调onAddStream中拿到A的流媒体信息，建立连接互相通讯。
15、主播A从接口回调onAddStream中拿到B的流媒体信息，建立连接互相通讯。
问题
- 目前规划的连麦加推流方案为：服务商提供连麦服务，我们用webRTC开源sdk去调用连麦服务，连麦成功后，我们客户端底层混流和推流，再使用服务商的推流服务推给各个终端。
要实现这个方案，需要解决三个问题：
- 首先，每一个连麦服务商都能开放自己的连麦服务器。
- 其次，开源的webRTC框架能对接任何服务商的连麦服务器。
- 最后，需要音视频开发人员编写底层混流和推流功能。