WebRTC架构简介

1、WebRTC目的

       

       WebRTC（Web Real-Time Communication）项目的最终目的主要是让Web开发者能够基于浏览器（Chrome\FireFox\...）轻易快捷开发出丰富的实时多媒体应用，而无需下载安装任何插件，Web开发者也无需关注多媒体的数字信号处理过程，只需编写简单的Javascript程序即可实现，W3C等组织正在制定Javascript 标准API，目前是WebRTC 1.0版本，Draft状态， 网址；另外WebRTC还希望能够建立一个多互联网浏览器间健壮的实时通信的平台，形成开发者与浏览器厂商良好的生态环境。同时，Google也希望和致力于让WebRTC的技术成为HTML5标准之一，可见Google布局之深远。

2、WebRTC架构图

架构图颜色标识说明：

（1）紫色部分是Web开发者API层；

（2）蓝色实线部分是面向浏览器厂商的API层（也就是红色框标内模块，也是本人专注研究的部分）

（3）蓝色虚线部分浏览器厂商可以自定义实现

3、WebRTC架构组件介绍

(1) Your Web App
Web开发者开发的程序，Web开发者可以基于集成WebRTC的浏览器提供的web API开发基于视频、音频的实时通信应用。

(2) Web API
面向第三方开发者的WebRTC标准API（Javascript），使开发者能够容易地开发出类似于网络视频聊天的web应用，最新的标准化进程可以查看 这里 。

(3) WebRTC Native C++ API
本地C++ API层，使浏览器厂商容易实现WebRTC标准的Web API，抽象地对数字信号过程进行处理。

(4) Transport / Session

传输/会话层

会话层组件采用了libjingle库的部分组件实现，无须使用xmpp/jingle协议

a.  RTP Stack协议栈
Real Time Protocol

b.  STUN/ICE
可以通过STUN和ICE组件来建立不同类型网络间的呼叫连接。

c.  Session Management
一个抽象的会话层，提供会话建立和管理功能。该层协议留给应用开发者自定义实现。

(5) VoiceEngine
音频引擎是包含一系列音频多媒体处理的框架，包括从视频采集卡到网络传输端等整个 解决方案。
PS：VoiceEngine是WebRTC极具价值的技术之一，是Google收购GIPS公司后开源的。在VoIP上，技术业界领先，后面的文章会详细了解

a.  iSAC

Internet Speech Audio Codec

针对VoIP和音频流的宽带和超宽带音频编解码器，是WebRTC音频引擎的默认的编解码器
采样频率：16khz，24khz，32khz；（默认为16khz）
自适应速率为10kbit/s ~ 52kbit/；
自适应包大小：30~60ms；
算法延时：frame + 3ms

b.  iLBC
Internet Low Bitrate Codec
VoIP音频流的窄带语音编解码器
采样频率：8khz；
20ms帧比特率为15.2kbps
30ms帧比特率为13.33kbps
标准由IETF RFC3951和RFC3952定义

c.  NetEQ for Voice

针对音频软件实现的语音信号处理元件

NetEQ算法：自适应抖动控制算法以及语音包丢失隐藏算法。使其能够快速且高解析度地适应不断变化的网络环境，确保音质优美且缓冲延迟最小。

是GIPS公司独步天下的技术，能够有效的处理由于网络抖动和语音包丢失时候对语音质量产生的影响。

PS： NetEQ 也是WebRTC中一个极具价值的技术，对于提高VoIP质量有明显效果，加以AEC\NR\AGC等模块集成使用，效果更好。

d.  Acoustic Echo Canceler (AEC)
回声消除器是一个基于软件的信号处理元件，能实时的去除mic采集到的回声。

e.  Noise Reduction (NR)
噪声抑制也是一个基于软件的信号处理元件，用于消除与相关VoIP的某些类型的背景噪声（嘶嘶声，风扇噪音等等… …）

(6) VideoEngine
WebRTC视频处理引擎
VideoEngine是包含一系列视频处理的整体框架，从摄像头采集视频到视频信息网络传输再到视频显示整个完整过程的解决方案。

a.  VP8
视频图像编解码器，是WebRTC视频引擎的默认的编解码器
VP8适合实时通信应用场景，因为它主要是针对低延时而设计的编解码器。
PS:VPx编解码器是Google收购ON2公司后开源的，VPx现在是WebM项目的一部分，而WebM项目是Google致力于推动的HTML5标准之一

b.  Video Jitter Buffer
视频抖动缓冲器，可以降低由于视频抖动和视频信息包丢失带来的不良影响。

c.  Image enhancements
图像质量增强模块
对网络摄像头采集到的图像进行处理，包括明暗度检测、颜色增强、降噪处理等功能，用来提升视频质量。

底层架构

上图实为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的

MediaStream获取音视频数据流

getUserMedia(constraints,successCallback,errCallback)

navigator上的方法，用于获取用户授权提供的音频视频数据流，三个参数分别为约束对象，成功的回调函数，发送错误的回调函数。

浏览器兼容性

1 2 3 4

const getUserMedia = (navigator.getUserMedia || navigator.webkitGetUserMedia || navigator.mozGetUserMedia || navigator.msGetUserMedia);

上栗子：MediaStream和Canvas实现拍照功能

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

const getUserMedia = (navigator.getUserMedia || navigator.webkitGetUserMedia || navigator.mozGetUserMedia || navigator.msGetUserMedia); let video = document.getElementById( 'video'), canvas = document.getElementById( 'canvas'), ctx = canvas.getContext( '2d'), localStream = null; getUserMedia({ video: true, audio: true},stream=>{ video.src = window.URL.createObjectURL(stream); localStream = stream; },err=>{ console.log( 'get stream failed!'); }); video.addEventListener( 'click',()=>{ if(localStream){ ctx.drawImage(video, 0, 0); document.getElementById( 'img').src = canvas.toDataURL( 'image/png'); } });

RTCPeerConnection实现P2P通信

P2P通信基于UDP传输协议，更加注重传输实时性。P2P建立过程是比较复杂的。主要是交换SDP和ICE信息。

上图所示为利用信令服务器实现P2P通信的流程图，其中还包含了STUN服务器（非WebRTC实现)

P2P通信建立过程

交换SDP

SDP是一种会话描述协议（Session Description Protocol），包含了一系列信息包括会话使用的媒体种类，双方ip和port,带宽，会话属性等。

SDP交换采用Offer/Answer形式。

1. 首先Offer方通过new RTCPeerConnection(config)建立PeerConnection
2. Offer方通过createOffer生成sessionDescription，设置localDescription,并通过信令服务器发送给Answer方
3. Answer方收到offer,发现并没有与之对应的peerConnection,新建peerConnection,并设置remoteDescription
4. Answer方通过createAnswer生成sessionDescripton,设置localDescription,并通过信令服务器发送answer
5. Offer方收到answer,设置remoteDescription
6. SDP交换结束

交换ICE

ICE是一种用于实现NAT/防火墙穿越的协议，可以实现:

1. P2P直接通信
2. 使用STUN服务器实现突破NAT的P2P通信
3. 使用TURN中继服务器实现突破防火墙的中继通信

交换过程：

1. 双方在new RTCPeerConnection(config)建立连接后，当网络候选者可用时，会触发icecandidate事件
2. 在onicecandidate事件处理程序中将candidate通过信令服务器发送给对方
3. 双方在接受到彼此的candidate后，通过addIceCandidate将对方的candidate加入到PeerConnection实例中。

在连接建立前或者建立后调用peerConnection.addStream()方法将本地视频/音频数据流加入到connection当中，当对方接受到视频流时会触发addStream事件，在其处理程序中我们可以接受数据流将其显示。

基于Socket.io和WebRTC的两人视频聊天室

上述过程的信令服务器可以使用WebSocket服务，而Node.js可以方便的实现ws服务，socket.io更是封装了一系列API，可以方便的实现多人视频聊天室，多人视频聊天室有需要注意一些其他诸如SDP冲突问题，这里先以两人通信为例来更深入理解整个过程。

1	//代码较多这里省略

NAT/防火墙穿越技术

之所以将NAT/防火墙单独出来，是因为NAT/防火墙问题是建立端对端通信的一个重要问题

NAT

NAT将连接到公网的全局ip转换为内网ip，实现多个终端通信，防止受到来自外网的攻击，有效节省IPV4数量。WebRTC必须穿越NAT进行通信。ICE可以通过STUN技术穿越NAT。

NAT的实现方式有三种，即静态转换Static Nat、动态转换Dynamic Nat和端口多路复用OverLoad。目前用得比较多的就是端口多路复用。

STUN服务器可以是自己搭建的，也可以是直接使用现成的，比如谷歌的stun服务:stun:stun.l.google.com:19302

自己搭建STUN服务器比较简单，这里篇幅有限，省略

配置好STUN服务，以此建立RTCPeerConnection,配置方法就是上面的config对象:

1 2 3 4

const config = { "iceServers":[{ "url": "stun:stun.yourdomain.com:3478"}] } let peer = new RTCPeerConnection(config);

防火墙

对于防火墙，需要依靠TURN服务器来进行通信。起一各TURN服务器监听在某个端口时，需要设置防火墙开发这个端口。搭建TURN服务器也比较简单，在这里也省略。

同样也要配置好config:

1 2 3 4 5

const config = { "iceServers":[ {"url":"stun:stun.yourdomain.com:3478"},{"url":"turn:turn.yourdomain.com:3478","username":"yourid","credential:"yourpassword"}] } let peer = new RTCPeerConnection(config);

RTCDataChannel API

既然可以实现音频视频的实时通信，为何不可以实现文本，文件等数据的传输呢？RTCDataChannel API就提供了这个功能。它通过将数据直接从一个浏览器发送到另一个浏览器，不需要将数据通过服务器来进行中转发送，简化了过程，保证实时性，同时还确保数据的安全私密性。

RTCDataChannel 与RTCPeerConnection API相结合，使用SCTP（流控制传输协议）实现稳定有序的数据传递。其仍然需要信令服务器的参与。以及STUN和TURN服务器来穿越NAT/防火墙。

RTCDataChannel支持两种模式运行：不可信赖模式（类似UDP)和可信赖模式（类似于TCP)。

流程分析

1. 通过config建立RTCPeerConnection
2. 通过peerConnection.createDataChannel(label,dataChannelConfig)获取dataChannel对象
3. 按照上述P2P建立流程完成SDP和ICE信息交换
4. 调用send()方法发送消息
5. 接收方监听message事件，获取数据

1	let dataChannel = peerConnection.createDataChannel( 'dataChannel',{ 'reliable:false'});

详细API可查看WebRTC官网

4、WebRTC核心模块API

(1)、网络传输模块：libjingle

WebRTC重用了libjingle的一些组件，主要是network和transport组件，关于 libjingle的文档资料可以查看这里。

(2)、音频、视频图像处理的主要数据结构

常量\VideoEngine\VoiceEngine

注意：以下所有的方法、类、结构体、枚举常量等都在webrtc命名空间里   

类、结构体、枚举常量	头文件	说明
Structures	common_types.h	Lists the structures common to the VoiceEngine & VideoEngine
Enumerators	common_types.h	List the enumerators common to the  VoiceEngine & VideoEngine
Classes	common_types.h	List the classes common to VoiceEngine & VideoEngine
class VoiceEngine	voe_base.h	How to allocate and release resources for the VoiceEngine using factory methods in the VoiceEngine class. It also lists the APIs which are required to enable file tracing and/or traces as callback messages
class VideoEngine	vie_base.h	How to allocate and release resources for the VideoEngine using factory methods in the VideoEngine class. It also lists the APIs which are required to enable file tracing and/or traces as callback messages

(3)、音频引擎（VoiceEngine）模块 APIs

下表列的是目前在 VoiceEngine中可用的sub APIs

sub-API	头文件	说明
VoEAudioProcessing	voe_audio_processing.h	Adds support for Noise Suppression (NS), Automatic Gain Control (AGC) and Echo Control (EC). Receiving side VAD is also included.
VoEBase	voe_base.h	Enables full duplex VoIP using G.711. NOTE: This API must always be created.
VoECallReport	voe_call_report.h	Adds support for call reports which contains number of dead-or-alive detections, RTT measurements, and Echo metrics.
VoECodec	voe_codec.h	Adds non-default codecs (e.g. iLBC, iSAC, G.722 etc.), Voice Activity Detection (VAD) support.
VoEDTMF	voe_dtmf.h	Adds telephone event transmission, DTMF tone generation and telephone event detection. (Telephone events include DTMF.)
VoEEncryption