一、背景
近年来，直播竞答、网络游戏直播等新的实时音视频通讯场景不断推陈出新，实时音视频应用的爆发，使得WebRTC技术成为了人们关注的焦点。由于WebRTC技术可以帮助用户在没有插件和客户端的情况下，轻松实现网页浏览器之间的实时语音对话和视频对话，加之研发成本相对较低，因此开源的WebRTC技术逐渐在众多领域得到了广泛应用。58集团目前很多业务场景对音视频通话有需求，如IM、金融面审、招聘面试等。因此TEG结合实际业务场景基于WebRTC提供了一套完整的实时音视频通话解决方案，以满足各个业务场景的需求。
二、WebRTC的技术介绍
WebRTC是一个开源项目，旨在使得浏览器能为实时通信（RTC）提供简单的JavaScript接口。说的简单明了一点就是让浏览器提供JS的即时通信接口。这个接口所创立的信道并不是像WebSocket一样，打通一个浏览器与WebSocket服务器之间的通信，而是通过一系列的信令，建立一个浏览器与浏览器之间（peer-to-peer）的信道，这个信道可以发送任何数据，而不需要经过服务器。并且WebRTC通过实现MediaStream，通过浏览器调用设备的摄像头、话筒，使得浏览器之间可以传递音频和视频。
WebRTC技术将语音视频的采集和编解码全部内嵌到了浏览器中，由此大大简化了视频通信所需的成本，即只需要一个支持WebRTC技术的浏览器即可实现视频通信，并且可以跨越不同平台和终端。
上图为WebRTC的底层架构，其用到的技术非常多，包括视频音频处理以及网络传输，防火墙穿越等技术。
WebRTC有三个模块，Voice Engine（音频引擎），Video Engine（视频引擎）和Transport。
- Voice Engine包含iSAC/iLBC Codec（音频编解码器，前者是针对宽带和超宽带，后者是针对窄带），NetEQ for voice（处理网络抖动和语音包丢失），Echo Canceler（回声消除器），Noise Reduction（噪声抑制）；
- Video Engine包含VP8 Codec（视频图像编解码器），Video jitter buffer（视频抖动缓冲器，处理视频抖动和视频信息包丢失），Image enhancements（图像质量增强）;
- Transport包含SRTP（安全的实时传输协议，用以音视频流传输），Multiplexing（多路复用），P2P，STUN+TURN+ICE（用于NAT网络和防火墙穿越的）。除此之外，安全传输可能还会用到DTLS（数据报安全传输），用于加密传输和密钥协商。整个WebRTC通信是基于UDP的。
WebRTC有三个重要的部分：MediaStream、RTCPeerConnection、RTCDataChannel。
- getUserMedia 允许网页浏览器获取摄像头和麦克风的使用权限，并且捕获媒体。通过MediaStream的API能够通过设备的摄像头及话筒获得音视频的同步流。
- RTCPeerConnection 负责管理端到端连接，RTCPeerConnection 是 WebRTC 用于构建点对点之间稳定、高效的流传输的组件。
- RTCDataChannel 允许浏览器分享任意数据，RTCDataChannel 使得浏览器之间（点对点）建立一个高吞吐量、低延时的信道，用于传输任意数据。
MediaStream
MediaStream主要是从设备获取数据流，比如说摄像头和麦克风。
getUserMedia（constraints,successCallback,errCallback），用于获取用户授权提供的音频视频数据流，三个参数分别为约束对象，成功的回调函数，发送错误的回调函数。
RTCPeerConnection
RTCPeerConnection 作为创建点对点连接的 API，是我们实现音视频实时通信的关键。在点对点通信的过程中，需要交换一系列信息，通常这一过程叫做 — 信令（signaling）。在信令阶段需要完成的任务：
- 为每个连接端创建一个 RTCPeerConnection，并添加本地媒体流；
- 获取并交换本地和远程描述：SDP 格式的本地媒体元数据；
- 获取并交换网络信息：潜在的连接端点称为 ICE 候选者。
我们虽然把 WebRTC称之为点对点的连接，但并不意味实现过程中不需要服务器的参与。因为在点对点的信道建立起来之前，二者之间是没有办法通信的。因此在信令阶段，我们需要一个通信服务来帮助我们建立起这个连接。WebRTC本身没有指定信令服务，所以，我们可以使用 XMPP、XHR、Socket等来做信令交换所需的服务。TEG是采用webSocket来做双向通信。
NAT/防火墙穿越技术
建立点对点信道的问题是 NAT 穿越技术。简单来说NAT就是为了解决 IPV4 下的 IP 地址匮乏而出现的一种技术，也就是一个 公网 IP 地址一般都对应 n个内网IP。这样也就会导致不是同一局域网下的浏览器在尝试 WebRTC 连接时，无法直接拿到对方的公网 IP 也就不能进行通信，所以就需要用到 NAT 穿越（也叫打洞）。以下为 NAT 穿越基本流程：
由于 NAT 的行为是非标准化的，在 RTCPeerConnection 中使用 ICE 框架来保证 RTCPeerConnection 能实现 NAT 穿越。
ICE
ICE（Interactive Connectivity Establishment）交互式连接建立，一种综合性的 NAT 穿越技术，是一种框架，可整合各种 NAT 穿越技术如 STUN、TURN（Traversal Using Relaying NAT，中继NAT实现的穿透）。ICE 会先使用 STUN，尝试建立一个基于 UDP 的连接，如失败了就会去 TCP（先尝试 HTTP，然后尝试 HTTPS），若依旧失败 ICE 就会使用一个中继的 TURN 服务器。 在 P2P 连接被创建前，首先必须进行信令处理。为了完成让用户都具有另一端用户的 IP以及其他任何用户想要共享的涉及数据/视频的信息，信令会在用户和信令服务器之间进行多次往返。
信令交换过程：
显而易见，在上述连接的过程中：首先呼叫端（ClientA）需要给 接收端（ClientB） 通过信令服务发送一条名为 offer（SDP） 的信息，接收端在接收到请求后，则通过信令服务返回一条 answer（SDP） 信息给呼叫端。然后在呼叫端和接收端的 ICE 候选信息准备完成后，通过信令服务进行交换，并互相保存对方的信息，这样就完成了一次连接。
SDP 格式的本地媒体元数据的交换：
- v=0
- o=- 9161120045333372658 2 IN IP4 127.0.0.1
- s=-
- t=0 0
- a=group:BUNDLE audio video
- a=msid-semantic: WMS ZJeNpxjV9akPU8igui9Fr4KKKkDvVPLFWTBb
- m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
- c=IN IP4 0.0.0.0
- a=rtcp:9 IN IP4 0.0.0.0
- a=ice-ufrag:wIpU
- a=ice-pwd:x3WCaK1ZwTV9Shs0kmsyQQ6L
- a=ice-options:trickle
- … …
三、音视频通话流程介绍
根据当前业务场景，TEG基于WebRTC进行了二次开发，提供了一套自研 的完整解决方案，从而实现点对点的音视频通话。以下是通过WebRTC进行音视频通话连接的一系列的步骤：
呼叫/接听流程：
主叫方发起通话，首先申请房间号并且加入房间（房间是一个音视频空间，同一房间内的用户可以相互观看对方的实时视频。用房间号来标识一个房间，即在同一个实时音视频应用中间号相同的房间，可以认为是同一个房，房间是实时沟通功能的一个管理单元。），然后通过业务线服务器将房间号发到被叫方，被叫加入房间。此时被叫方可以选择接听或者拒绝，如果选择接听通话，此时主叫和被叫经过一系列信令交换过程完成视频通话。
兼容性：
- iOS: 系统ios11以上支持webRTC，且仅限safari浏览器，微信内置浏览器尚不支持getUserMedia，视频编解码格式为H.264；
- Android: 安卓4.4以上（不含4.4），经测试各大手机厂商自带浏览器均不支持getUserMedia，但微信内置浏览器可以正常运行，部分手机firefox和谷歌浏览器支持；
- PC: Chrome49以上，Firefox55以上，Edge支持，Safari系统11以上支持，IE不支持。
四、总结
WebRTC技术基于UDP，具有不需安装插件或者客户端，开源免费，强大的网络穿透能力，出色的音视频处理技术等优点，但由于兼容性问题，尤其在安卓手机浏览器上的兼容性较差。不过随着5G网络的建设和直播等应用的持续火爆，实时的音视频通话等场景需求十分强劲，在互联网平台音视频直播互动这一领域，WebRTC依然是一个最佳的选择。
