移动互联网WebRTC及相关技术
摘要
本文描述了一个WebRTC技术的改进设计。通过这种设计，客户端，服务器端以及这两者之间的WebRTC通信得到了改进。HTML5 WebSocket，媒体协商与综合，网络地址转换（NAT）/防火墙穿透，会话初始协议（SIP）信令交互以及P2P通信安全都被用于这种改进的设计。该解决方案解决了WebRTC应用的跨浏览器运行问题，降低了客户端处理能力的可靠性，降低了带宽消耗。有了这个设计，WebRTC也变得更具可扩展性。
关键词: WebRTC技术; 应用模型; 防火墙穿越; 扩展性
1介绍
Web实时通信（WebRTC）[1]是基于Web浏览器的实时音频和视频通信技术。它使开发人员能够使用简单的Web技术快速轻松地开发丰富的实时在线多媒体应用程序，无需安装任何插件。
随着网络带宽和Web浏览器的不断发展，WebRTC将对传统的实时通信产生巨大的影响，逐渐成为主流的实时通信技术。Google已经在Android平台的新版Chrome中提供了对WebRTC的支持。据预测，至少有十亿终端将在2013年支持WebRTC。在CTI调查结果[2]，一个在中国的融合通信论坛，调查中有87％的电信公司正在考虑制作WebRTC部分产品战略; 这些公司中有86.9％认为WebRTC是其整体产品战略的重要组成部分; 其中49％的公司打算在一年内部署WebRTC解决方案。
WebRTC由Global IP Solution Corporation开发，并于2010年被Google收购。在此次收购之后，Google决定向公众开放WebRTC技术。万维网联盟（W3C）和互联网工程任务组（IETF）都已经组建了WebRTC标准化组织,WebRTC标准也得到越来越多的业内制造商的支持。
与传统通信技术相比，WebRTC具有以下优点：
bull;它很容易使用，插件或不同的平台客户端应用程序不需要安装。
bull;它提供了一致的用户体验。
bull;它可以在服务器端快速轻松地升级。
bull;在WebRTC的基础上，网页即时通讯服务可以用JavaScript或HTML开发。
bull;它可以跨操作系统运行，这意味着开发人员不需要为不同的操作系统开发不同的应用程序版本。
bull;开发者可以专注于服务而不是媒体流程。
2 WebRTC标准进展
W3C和IETF负责开发WebRTC标准，但这些组织有不同的目标。W3C WebRTC工作组旨在定义客户端JavaScript APls。借助这些API，Weh应用程序可以完成浏览器之间的点对点或点对多点实时通信。
W3C WebRTC工作组的定义了浏览器之间的协议和媒体格式。它主要关注媒体编解码器，网络传输，网络地址转换（NAT）/防火墙穿越，安全性，私密性等。IETF RTC-Web的关键成员是微软，Google，Skype，雅虎，思科和FT（Orange）。
最初WebRTC标准有三种类型的AP：Net Work Stream RTCPeerConnection和DataChannel。Net Work Stream API用于用户媒体获取RTCPeer连接API用于建立浏览器之间的连接; DataChannel API用于传输除摄像机或麦克风的视频和音频流以外的用户数据。NetWork Stream API TCPeerConnection API都是比DataChannel API开发的更广泛的应用。NetWork Stream API在最近的版本中独立于WebRTC标准。
随着WebRTC标准的成熟，它们得到了支持越来越多的现代浏览器（表1）。调查报告为了验证WebRTC在Web即时通信，浏览器厂商Google和Mozilla以及Mobicents [3]（由Red Hat收购的VoIP中间件平台提供商）Livecome [4]（一种通信服务解决方案提供商）和一些Web开发人员已经开发了自己的WebRTC演示。在WebRTC支持的浏览器中，每个WebRTC演示都可以使用摄像头和麦克风
表1 支持WebRTC的浏览器
|
开发人员 |
支持WebRTC的浏览器 |
|
|
适用于桌面的Chrome 23 ，适用于Android的Chrome测试版 |
|
Mozilla |
Firefox 22 |
|
Opera |
beta Opera 12 |
3 WebRTC应用程序模式
3.1添加WebRTC访问传统音频和视频服务
电信运营商和解决方案提供商将WebRTC作为其传统音频和视频服务的新接入模式。例如，用户访问基于Web浏览器的传统呼叫中心，浏览器成为传统会议系统的新终端。
这种模式的难点在于确保WebRTC与传统应用架构的兼容性。在WebRTC和传统的应用架构之间增加了一个网关设备，以便协调它们之间的差异。例如，在中兴通讯的WebRTC-IMS网关接入解决方案中，WebRTC-IMS网关负责WebRTC与传统IMS网络之间的信令转换，媒体流中继，NAT /防火墙穿越机制转换。
这个解决方案的优点是：
bull;传统音视频服务中增加了浏览器访问模式，不需要开发浏览器端插件。这将大大减少客户端的工作。
bull;WebRTC的媒体处理能力得到加强，通过在传统架构中重用媒体服务器，提升了用户体验。
bull;使用WebRTC访问传统服务时，降低了客户端处理能力的依赖性，减少了网络带宽的消耗。
3.2轻量级实时Web通信
WebRTC的 典 型 应 用 场 景 是 使用 我 们 的bRTC标准的JavaScript API来开发轻量级的网络音频/视频通话和网络音频/视 频 会 议 中 心 。Mobicents SIP Servlet [5]，Conversat.io [6]（现在更名为Talky.io）和Chatdemo [7]等
在这个应用场景中，几乎所有的演示程序都采用了应用程序体系结构设计的方式。其关键在于分解多媒体谈判过程到多个端到端的协商处理，传统媒体服务器实现的音视频处理等功能传输到客户端浏览器端。
一旦获得媒体格式和传输协议由双方移植，两个浏览器可以相互通信，媒体流可以直接发送到另一端，而不是由服务器中继。第三方加入时，第三方UA应与前两方UA展开谈判。在这一步之后，下面的过程和双方之间的沟通是一样的。
这个解决方案非常简单，不需要考虑我的处理。但是，客户端媒体处理压力会越来越重。总之，这个解决方案在很大程度上取决于客户端处理能力，因此在视频会议中不能支持六个以上的用户。
3.3全面的Web实时通信服务
与上述相比，最大的区别是我们在服务器端增加了一个多点控制单元
（MCU）。与上面的解决方案一样，所有的媒体处理都集中在MCU上。此外，MCU还提供一些强化功能，如音频/视频混合。
由于媒体处理被转移到服务器端，因此该方案大大降低了WebRTC应用对客户端处理能力的依赖性，拓展了WebRTC技术的应用范围。
总而言之，最后的解决方案充分利用了二者的优势，可以应用于大规模的应用场景。
4 WebRTC技术解决方案：问题和改进
4.1当前WebRTC应用中的技术问题
WebRTC作为一种发展中的技术和标准，在传播过程中存在很多缺陷，这些缺陷如下：
bull;与传统视频会议服务相比,WebRTC对用户媒体的控制能力不强。这一特点意味着WebRTC不适应复杂会议的要求。
bull;考虑到媒体流在WebRTC中直接相互发送，客户端的处理能力是非常重要的。PC视频会议中不到五方可以，但是这个数字越大，用户的体验就越糟糕。这个问题在移动终端上更糟糕。
bull;巨大的带宽消耗将显着会增加使用WebRTC服务的成本。
bull;在不同的浏览器中，WebRTC APis名称或HT ML5 APis的名称有些不同[8]，[9]。在一个浏览器上成功运行的WebRTC应用程序可能会在另一个浏览器环境中运行时遇到异常。
bull;WebRTC AP可以运行本地媒体文件和设备，这种访问模式可能会对系统造成潜在的威胁[10]。
4.2建议的改进
我们提出了使用WebRTC开发轻量级实时Web通信服务的改进方案。该解决方案解决了跨浏览器运行问题，减少了客户端处理能力和带宽消耗的依赖性，并提高了系统可扩展性（图1）。
图1显示了客户端网元（NE），服务器端网元以及如何在这两方之间进行通信。
图1 轻量级Web实时通信服务的系统体系结构
4.2.1客户端
在客户端，浏览器必须支持WebRTC标准接口，SIP协议栈支持SIP信 号 处 理 。WebRTC软包库基于WebRTC Javascript APis和SIP Stack。其实现：客户端和服务器端之间的双向通信，浏览器之间的媒体和防火墙穿越协商以及运行跨浏览器支持。WebRTC APP完成用户界面显示[11]。
4.2.2服务器端
服务器端包括交互连接建立（ICE）[12]服务器，MCU，Web服务器和信令服务器。ICE服务器与客户端浏览器进行交互并将iceCondidates返回给客户端。MCU综合从各方的浏览器传输的流，并将最终流发送回会话中有关的浏览器。Web服务器为WebRTC APP提供运行环境。信令服务器对来自客户端的SIP请求进行处理，路由和分发，实现用户认证，用户管理，会议控制和记录，会议计费等。在实际部署场景中，上述四个网元可以分别为部署或部署在同一台服务器或几台服务器上。
4.2.3 Clien \Side和Servt#39;t#39;Sidt之间的通信·ICE客户端与ICE服务器之间的通信
通过简单遍历NAT上的UDP（STUN）[13]以及在NAT（TURN）周围使用中继进行遍历[14] proto cols。UDP协议用于消息传输。SIP over WebSocket [15]技术用于客户端和服务器端之间的双向SIP交互。实时传输协议/实时传输控制协议（RTP / RT CP）用于在客户端和服务器端之间传输媒体流。HTTP用于访问Web服务。
在这个框架内，一般的多方视频通信程序可以用下面的步骤描述：
1)用户通过客户端浏览器访问Web服务器提供的服务。
2)客户端浏览器注册到信令服务器，并实现多方点对多点媒体协商。MCU以特定格式接收会议中各方发送的本地音视频流。它为这些流执行混音，混频，然后将合成的流返回给各方。
3)各方本地浏览器接收并显示媒体流。
4)建立多方沟通过程。
4.3关键技术
4.3.1 HTML5 WebSocket
传统的实时通信通常使用轮询或长轮询技术。通过增加客户端请求频率或延长服务器响应时间，开发者可以在一定程度上提高实时服务的用户体验，但基于HTTP的请求-响应模式不能提供真正的实时通信。另外，轮询或长轮询技术增加了客户端带宽消耗和服务器端资源消耗。
为了减少实时通信的延迟并减少带宽消耗，HTML5工作组已经开发了WebSocket通信标准。HTML5 Web Socket通过Web上的单个套接字来定义全双工通信通道，从而显着提高Web通信的实时性。
在客户端和服务器端可以互相通信之前，他们需要完成一个WebSocket握手来建立它们之间的连接。一旦建立连接，就可以在两个方向上双向传输数据。这样，当服务器端进行日期数据更新时，可以直接将这些数据推送到客户端，不需要等待客户端的请求。
在非常强大的实时应用中，例如音频和视频通信，HTML5 WebSocket可以通过减少传输负载，大大提高性能并减少带宽消耗。
4.3.2媒体谈判与综合
在这种改进中，媒体谈判仍然发生在客户端。当会议中有多方参与时，需要将多方协商过程分解为多个端到端的协商过程。期权交易策略见图2和图3。
理论上，多方媒体协商结束后，多方媒体流可以直接相互传递。但是，这种应用模式会产生重大问题。举例来说，在四方会议中，各方需要同时发送三路本地视频流，接收其他三方的视频流。这样，客户端只能支持非常有限的用户数量，并且要占用大量的网络带宽。
因此，在服务器端需要MCU来进行媒体流转换，合成等。本方案引入MCU后，每个客户端只需要发送单向本地视频流，并从MCU接收单向合成视频流。
4.3.3NAT /防火墙穿越
用于Web音视频通讯的交叉局域网环境，用于路由媒体流传输的NAT/防火墙穿越设备。IETF-RTC Web标准规定WebRTC浏览器需要支持ICE框架，服务器端需要提供相应的ICE服务器。
对于遍历方案的选择，同时支持STUN和TURN服务器。STUN服务器完成非对称NAT遍历，TURN服务器完成对称NAT穿越和防火墙穿越。通过STUN和TURN服务器的协同，我们的webRTC媒体流传输得到保证。
4.3.4基于SIP协议的信令交互技术
在W3C WebRTC标准中，客户端和服务器端之间的信令不是标准化的。SIP是一个简单，灵活，可扩展的协议，在业界越来越受欢迎。应该说SIP已经成为下一代通信的虚拟标准。为了完成客户端和服务器端之间的SIP信令交互，我们在客户端采用了
全文共7364字，剩余内容已隐藏，支付完成后下载完整资料
英语原文共 6 页，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[13748]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
