2.3 模块与API之间的关系

　　在这节，我们将通过WebRTC的工作原理来阐述WebRTC各个组成模块与所封装的JavaScript API之间的关联关系。图2是一个WebRTC的工作原理示意图。在图2中，有两个集成WebRTC的浏览器，一个信令服务器，一个STUN/TURN服务器。浏览器访问基于WebRTC的Web应用。信令服务器对Web应用的信令进行解析。STUN/TURN服务器对Web应用进行NAT或防火墙穿透，以建立两个客户端的通信连接。具体工作流程如下：首先，使用Web应用的双方通过PeerConnection API将呼叫和应答请求发送给信令服务器；然后，STUN/TURN服务器对呼叫双方的防火墙和NAT进行穿透；之后，MediaStream通过音视频引擎对音视频数据进行采集；最后，Web应用将采集到的音视频数据发送到DataChanel，并采用RTP/SRTP协议进行传输。

　　图 2 WebRTC各个组成模块与所封装的JavaScript API之间的关联关系

　　2.4 应用场景

　　WebRTC的音视频应用从连接的客户端的数量角度来区分，可以分为一对一模式和多人模式。同时，WebRTC为了取得快速的发展，其势必对传统网络，例如SIP，XMPP和PSTN网络进行无缝对接。

　　A. 一对一模式

　　该模式是最简单的应用模式。在上文图2中阐述WebRTC模块与API之间关联关系时的例子就是一个一对一模式。该模式的工作原理描述如下。首先，基于WebRTC的Web应用通过Web服务器来进行信令解析。然后，每个浏览器将本地采集到的音视频数据发送给对端浏览器。最后，每个浏览器对本地和对端的多媒体数据进行处理和显示。

　　图 3 一对一模式

　　B. 多人模式

　　相比较于一对一模式，多人模式则更加复杂。该模式与一对一模式不同的是，每个浏览器将本地采集到的音视频数据广播给其余所有浏览器（如图4（a）所示）。由于终端的处理能力，电池续航能力以及网络带宽的限制，WebRTC目前最多能够支持6个人同时进行音视频服务。为摆脱由于终端的有限能力对WebRTC多人模式中人数的限制，目前，有些公司（例如因特尔）为WebRTC的特定应用提供MCU媒体控制单元。MCU负责对不同格式的音视频进行转码和将多人模式中的音视频流整合在一起再广播给每一个终端。基于MCU的多人模式的工作流程，如图4（b）所示。

　　（a）                                   （b）

　　图 4（a）WebRTC原生多人通信模式，（b）基于MCU的多人通信模式。

　　C. WebRTC与现有网络的互通模式

　　由于在WebRTC出现之前，实时通讯业务已经取得了很大的发展。因此，WebRTC应与现有的实时通信业务无缝对接，才能取得快速的发展。为了与传统实时通信业务进行无缝对接，目前，各个厂商根据WebRTC和现有的实时通信业务开发出相应的网关设备，比如对应SIP/XMPP的服务器和PSTN（Public Switched Telephone Network——公共交换电话网络）网关。该网关负责将通过浏览器访问的Web应用和传统客户端访问的现有实时通信应用的信令进行适配，甚至多媒体格式之间的转化。具体的业务逻辑如图5所示。

　　图 5 WebRTC与现有网络的互通模式

　　3. WebRTC的发展与影响

　　3.1 发展

　　首先，Android系统内置的浏览器和个人电脑中主流的Web浏览器（例如Chrome，Firefox和Opera）已经支持WebRTC。根据Dialogic公布的2013年“WebRTC影响调查”报告，在2013年，Android在移动智能终端的市场占有率是69%；Chrome，Firefox和Opera三大主流Web浏览器在个人电脑的市场占有率是39%。另外，其他Web浏览器（比如，Maxthon）也将支持WebRTC。因此，WebRTC将被快速的部署在日常设备（即移动智能终端和个人电脑等）。其次，由于WebRTC的本质是一项基于Web浏览器的实时通信技术，它将最先应用在IM（Instant Messenger——即时通信）领域。由于IM应用通常应用在社交网络，这使得WebRTC可以依靠社交网络所具有的小世界网络特性（即虽然这种网络中大部份的节点彼此并不相连，但绝大部份节点之间经过少数几步就可到达——摘自维基百科）快速的被用户所使用。基于以上两点，WebRTC技术的部署和使用将呈现爆炸式的增长。