北邮移动互联网 大作业 移动互联网WebRTC研究报告

移动互联网WebRTC研究报告

姓名：曹爽

学号：2013210640

班级：2013211124

0 引言

移动互联网是移动通信和传统互联网融合的产物，涉及互联网、移动通信、无线网络、嵌入式系统等方面。当前正在发展的移动互联网技术主要包括移动终端、接入网络、应用服务、安全与隐私保护4个方面的技术。其中移动终端研究包括终端硬件、操作系统、软件平台、应用软件、节能、定位、上下文感知、内容适配和人机交互等；接入网络研究包括无线通信基础理论与技术、蜂窝网络、无线局域网、多跳无线网络、异构无线网络融合、移动性管理与无线资源管理等；应用服务研究包括移动搜索、移动社交网络、移动互联网应用拓展、基于云计算的服务、基于智能手机感知的应用等；安全与隐私保护研究则涉及内容安全、应用安全、无线网络安全、移动终端安全、位置隐私保护等。

移动互联网的研究体系如图1所示。从图中可以归纳出它们的层次结构：移动终端是移动互联网的前提和基础；接入网络保证用户在各种异构网络之间通信的畅通；应用服务是移动互联网的核心, 也是用户的最终目的；安全与隐私保护则贯穿始终，保障用户网络行为的安全。

图1 移动互联网研究体系示意图

本文重点研究应用服务技术中的网页实时通信（WebRTC）技术和相关问题。

1 WebRTC技术简介

网页实时通信（WebRTC）是一种构建在Web浏览器基础上的实时音视频通信技术，它可使支持HTML5的浏览器通过调用JavaScript API开发功能丰富且高质量的实时通信应用，尤其是可使网页具备视频对话或音频对话等实时通信功能。2011年6月29日，Google以GIPS公司的专利技术为基础建立了WebRTC开源项目。自开源以来，WebRTC因其开放、开源且具有极大的使用便利性，受到了业界特别是互联网和通信行业的广泛关注。Google放弃价值不菲的知识产权，意图是令浏览器厂商将该技术直接内嵌到浏览器中，从而将浏览器打造成普适的实时通信平台。这对广大的网络应用开发者深入了解与实时通信相关的音频、视频处理技术，对今后开发新型面向P2P的实时通信Web App，无疑是极大的促进。

WebRTC的标准由Cisco、Mozilla、Voxeo、Ericsson共同完善，WebRTC工作组则主要负责制定WebRTC客户端侧API，并维护相关的接口规范。在Google的大力推动下，目前主流的浏览器，如Firefox、Opera等，都已经支持WebRTC技术。此外，网上已经有许多基于WebRTC的新应用出现，这些应用分别展现了WebRTC技术在基于SIP的VoIP电话、增强现实、图像分割、人脸识别等方面的应用，对于浏览器用户是一种全新的体验。通过对Web浏览器的增强，未来的Web App将更加强大，应用也更加丰富多彩。

2 WebRTC的总体架构

WebRTC的本质是将实时通信应用所需要的音、视频捕获及处理模块、网络传输及会话控制等协议集成到Web浏览器中，从而屏蔽底层硬件实现或操作系统之间的差异。WebRTC的总体架构如图2所示，主要包含3个大类：信令机制、浏览器底层的WebRTC、网页应用（Web App）。信令机制主要用于协调浏览器之间建立连接的过程；浏览器底层的WebRTC包括视频编解码模块、音频编解码模块、传输模块；网页应用是调用WebRTC的JS API实现的网站。下面将逐一介绍这三大类。

图2WebRTC的总体架构

2.1 信令机制

WebRTC信令的作用是：在客户端之间传递控制信息，通过控制信息处理客户端之间的发现、连接建立、连接维护和连接关闭等任务。启动一个WebRTC会话需要以下几个信息：本地客户端的初始化信息；远程客户端的初始化信息；远程参与建立连接的信息，主要是IP和端口。WebRTC未指定信令实现的方法和协

议标准，但所有的WebRTC应用都需要一个机制来交换两个通信终端的初始化媒体信息，即都需要进行JESP信令过程来交换SDP。

JSEP是JavaScript会话建立协议，它的过程如下：呼叫方发送请求（Offer）；被呼叫方接受该请求；被呼叫方反馈应答（Answer）；呼叫方接受应答。WebRTC 中定义了一系JS API，从而简化了JSEP的实现过程，浏览器仅需要按照规范调用这些API，即可完成交换请求和应答消息，从而创建会话。

2.2 浏览器底层的WebRTC

浏览器底层的WebRTC包括视频编解码模块、音频编解码模块、传输模块。

2.2.1 音频编解码模块

音频编解码模块的目标是实现从声卡采集到的声音到可供网络传输的数据的框架。具有设备控制、语音编码、加密声音文件、声音处理、声音输出、音量控制、音/视频同步、网络传输与流量控制等功能。它支持iSAC、iLBC、Opus 3种编解码器。

iSAC是一种用于VoIP和流媒体的宽带和超宽带音频编解码器，它采用16kHz 或32kHz的采样频率和12到52kbps的可变比特率。iLBC是一种用于VoIP和流媒体的窄带音频编解码器，它采用8kHz的采样频率，帧大小为20毫秒时的比特率为15.2kbps，30毫秒时的比特率为13.33kbps。Opus是由互联网工程任务组（IETF）开发的有损音频压缩格式，特别适用于网上的交互式实时应用，支持固定比特率和6kbps到510kbps可变比特率，帧大小从2.5毫秒到60毫秒，采样率从8kHz到48kHz。

声音处理针对音频数据进行处理，包括回声消除、自动增益、降噪处理等功能，用来提升声音质量。NetEQ模块继承了自适应抖动缓冲区及错误掩盖功能，可减少网络抖动和分组丢失对话音质量的影响，从而在尽量低的时延下提供高品质的话音通话。回声消除模块实现了基于软件实时去除由于放音被麦克风再次捕获所造成的声学回响。降噪模块主要使用信号处理手段除去各种背景噪声，如VoIP中常见的嘶嘶声或风扇噪声。

2.2.2 视频编解码模块

视频编解码模块是一个实现从摄像头数据采集到网络数据传输，以及从网络传输的数据到屏幕显示的解决框架。视频编解码模块提供视频设备控制、视频编码、加密、图像增强等功能。WebRTC采用VP8编解码技术，VP8是Google开发的视频编解码技术。视频抖动缓冲技术用于降低视频抖动和丢包对视频质量带来的影响。图像增强技术，针对每一帧的图像进行处理，这其中包括用降噪、颜色增强等技术手段来保证更好的视频质量以达到视频图像处理的目的。

视频加密是WebRTC视频处理引擎的一部分，相当于视频应用层面的功能，给点对点的视频双方提供了数据上的安全保证，可以防止Web上视频数据的泄

漏。视频图像处理针对每一帧图像进行处理，包括明暗度检测、颜色增强、降噪处理等功能，用来提升视频质量。

2.2.3 传输模块

传输模块主要包含NAT机制和传输机制。WebRTC建立连接需要NAT，即网络地址转换技术，WebRTC直接采用了Libjingle中关于传输部分的组件，Libjingle 中利用的是ICE这种综合性NAT穿越的框架，如图3所示。ICE综合运用基于UDP 的STUN和基于TCP的TURN协议来实现。使用ICE的应用程序需有一个ICE代理来负责ICE、STUN、TURN以及其它模块的交互，发现本地设备的网络拓扑结构的信息，找到一条路径或者通过该路径通信。每个代理都有一些可以用于与远端主机代理通信的候选传输地址。在网络中，每个代理可以有自己的STUN服务器，也可共用一个。本地计算机收集到所有的候选传输地址之后，将它们按优先级高低进行排序，然后通过信令通道发送给远端计算机。这些候选传输地址作为SDP 请求的属性被传输。当远端计算机收到请求后进行相同的收集过程，并且把自己的候选传输地址作为相应消息发给请求者。这样，每个代理都有一个完整的包含了双方候选传输地址的列表，既可以进行后续数据传输。

图3ICE框架

WebRTC的传输模块重用了Libjingle的部分组件，WebRTC技术在浏览器内部集成了一系列的网络传输及会话控制相关协议。传输及会话控制的实现重用了Libjingle项目的部分代码。RTP栈是RTP实时传输协议，该协议为实时媒体应用提供了一个传输音频和视频数据的方案。

现在的WebRTC技术已经直接封装在浏览器中，网页开发者只需要调用WebRTC的API，借助浏览器来实现媒体通信，即不用关心它底层是怎样实现的。

2.3 网页应用（Web App）

网页应用程序是指调用WebRTC的API实现的网站，属于WebRTC的顶层开发。开发者可用WebRTC提供的API，实现网页上的视音频通信。此外也有网页P2P下载功能。

基于WebRTC的实时视音频通信最初的实现仅支持两用户，后来发展成可以

支持3人及以上用户的音视频通信。网络拓扑结构采用全连接的方式，这种方式的优点是组网简单，缺点是代价较高，n个节点需要建立n(n-1)/2个连接。初始化时，每个节点与其他节点通过信令服务器建立连接，如图4所示。

图4基于全连接的WebRTC多用户视音频通信

这方面，Google提供的实例包括如下几种：两用户通信示例为AppRTC和CodeLab，多用户通信示例为SimpleWebRTC和ChatRoom。

网页P2P下载功能则主要基于网页中的P2P模块，包括伙伴关系管理和数据调度。伙伴关系管理是一种节点间的逻辑关系。每当一个节点加入到P2P系统中时，都需要向目录服务器注册。中央服务器保存了各节点的文件索引和存放位置的信息，最后节点连接到文件所有者的节点主机上，与此主机建立连接并传输文件。这些节点之间也会周期性地交换缓存映像，以便更新信息。

数据调度包括父节点选择和数据块选择两方面。每个节点独立地选择它的伙伴，然后通过消息传播机制，告诉它的伙伴它拥有的数据，每一个节点都从它的邻居节点请求缺失的数据块，同时也传递可用的数据块到它的邻居节点。文件被分割为大小相等的数据块并编号，节点在文件下载初期，即节点为新加入网络的节点时，自身没有任何文件分片，会随机产生一个需要下载的文件片的ID号。然后再邻居节点中选择具有该文件分片ID号的一个节点，并向该节点发送请求文件分片。数据调度要解决的问题是确定从哪个伙伴处请求哪个数据块。

应用方面来看，采用P2P技术的网页应用可以提升吞吐量，增强可扩展性。目前支持P2P下载的网页应用有PeerCDN、SwarmCDN、ShareFest等。

3 总结

WebRTC作为一种实时音视频通信技术，用于目前移动终端的实时音视频通信较为合适。目前移动终端的电话/短信业务量照比以前有所减少，而QQ、微信等基于互联网通信的应用则比重上升。这些应用当中可以利用WebRTC技术可以实现多人语音/视频通话、文件P2P传输等功能。此外，在手机浏览器中使用这种技术，也可以实现无需下载插件即可在线播放音视频的功能。

4 参考文献

[1]文军,张思峰,李涛柱. 移动互联网技术发展现状及趋势综述[J]. 通信技

术,2014,09:977-984.

[2]吴吉义,李文娟,黄剑平,章剑林,陈德人. 移动互联网研究综述[J]. 中国科学:信

息科学,2015,01:45-69.

[3]罗军舟,吴文甲,杨明. 移动互联网:终端、网络与服务[J]. 计算机学

报,2011,11:2029-2051.

[4]董振江,李从兵,王蔚,吕达. 移动互联网WebRTC及相关技术[J]. 中兴通讯技

术,2013,06:28-32.

[5]张向辉,黄佳庆,吴康恒,雷志斌. 基于WebRTC的实时视音频通信研究综述[J].

计算机科学,2015,02:1-6+32.

[6]付斌,杨鑫,王松,林鸿. WebRTC技术研究及其应用[J]. 电信科

学,2013,09:108-112.

[7]屈振华,李慧云,张海涛,龙显军. WebRTC技术初探[J]. 电信科

学,2012,10:106-110.