英语原文共 6 页，剩余内容已隐藏，支付完成后下载完整资料
WebRTC在实时通信和视频会议中的作用
Stefan Stefanescu
研发部
北亚咨询国际
布加勒斯特，罗马尼亚stefan.stefanescu@beia.ro
George Suciu
研发部
北亚咨询国际
布加勒斯特，罗马尼亚
george@beia.ro
CristianBeceanu
研发部
北亚咨询国际
布加勒斯特，罗马尼亚
cristian.beceanu@beia.ro
Marian Ceaparu
研发部
北亚咨询国际
布加勒斯特，罗马尼亚marian.ceaparu@beia.ro
摘要——实时通信（RTC）是一种新的标准和全行业的努力，它扩展了网络浏览模式，允许通过互联网访问社交媒体、聊天、视频会议和电视等领域的信息，以及统一通信。这些系统用户可以使用时间紧迫的云基础设施来查看、记录、评论或编辑视频和音频内容流，以强制服务质量。然而，目前有许多专有的协议和编解码器，不容易实现多点视频会议系统互操作性和可扩展性。WebRTC（Web Real-Time Communication）是一种State-of-the-Art的开放技术，它通过Web浏览器使用JavaScript API（Application Programming Interfaces）实现音频、视频和数据传输的实时通信功能，无需插件。本文旨在介绍基于Web实时通信（WebRTC）的P2P视频会议系统。在本文中，我们提出了一种基于Web的点对点实时通信系统，使用Mozilla Firefox配合ScaleDrone服务，使用户能够通过通信信道使用WebRTC技术、HTML5和使用Node.js服务器地址进行高速数据传输。我们的实验表明，WebRTC是一个能够在Web浏览器内实现可扩展的实时视频会议的构件。
我们还研究了视频会议系统的热成像仪，以识别关于COVID 19危机的体温结果。
索引项——实时，WebRTC，Node.js服务器，HTML5，JavaScript API。
Ⅰ.引言
开放源码的WebRTC使这些系统的用户能够查看视频内容或对其进行录制、评论流，实现网络浏览器之间的实时通信。WebRTC是一种实时通信技术，它集成
了API（应用编程接口）的标准，具有语音和视频等实
时多媒体传输功能（包括代码）可以在没有传统插件组
件的情况下，使用JavaScript代码[1][3]向网络浏览器提供。
最近，在新的平台上实现实时通信服务的情况增多：浏览器嵌入式应用或“网络应用”。在这些应用中，WebRTC受到了极大的关注，因为很多新版本的固有支持这个API的常用浏览器，即Google Chrome和Mozilla Firefox。WebRTC依托于HTML5网络通信，持有Peer Connection、Media Stream和Data Channels等组件API，这些API可以组合在一起，创建对等体之间的P2P直接媒体通信。当前版本的WebRTC API仅设计为支持浏览器与浏览器之间的通信。WebRTC用于“多浏览器”通信本质上并不推荐，特别是对于将媒体负载分散到参与的对等体/浏览器上的会议模式[5]。
WebRTC的方法更像WebSocket，但WebSocket打开了一个与服务器的连接管道，而不是另一个对等体。在大多数情况下，这些技术一起用于信号传递的目的。例如，在聊天应用中，WebSocket客户端首先向服务器发送消息，服务器向接收方发送消息。
WebRTC承诺在用户之间提供安全的直接P2P通信，并且不需要插件。WebRTC保证为用户提供一个简化的、灵活的、低成本的实时通信方式，而不依赖于服务提供商。Flash、Silverlight和Shockwave等插件的一个关键挑战是每次建立连接时都需要下载。插件在执行过程中会出现问题；它们会增加带宽、延迟、执行时间和速度[12]。
最近的研究在以下方面取得了一些令人振奋的进展。WebRTC.Sodhoro Ali Hassan和Giancarlo FortinoSodhoro Ali Hassan和Giancarlo Fortino实现了一种基于无线视频传输的电池恢复系统，采用电池管理方法，并对通信系统中的不同组件进行了延迟适应[15]。Ali Hassan Sodhro等人 [16] 开发了一种基于动态TPC的能量算法，用于WBANs中人体生命体征信号的传输。他们的算法在RSSI稳定性较高的情况下，节省了合理的能量，但与提出的EEA相比，算法有些复杂，功耗较大。
在论文中，我们提出了一种视频会议系统的解决方案，使用了：
- Scaledrone，这是一个推送消息的服务，你在这里创建一个频道；
- WebRTC，用于网站服务器向访问者发送浏览器ID。这个ID是唯一的，浏览器就可以连接到特定的对等浏览器；
- HTML进行编程，系统的核心是JavaScript API。
本文第二节介绍了相关工作，介绍了WebRTC的技术架构和使用的主要协议。然后第三节提供了使用ICE（Interactive Connectivity Establishment）协议进行数据传输的TURN服务器的功能。第四节阐述了利用Scaledrone（一种推送消息服务）和Mozilla Firefox浏览器设计的视频会议应用的实验结果。最后，在第五节中，对实验结果进行了总结。
Ⅱ.相关工作
在WebRTC出现之前，已经有很多的市场上的视频会议系统。最流行的例子是Skype。微软是拥有Skype的公司。Skype使用专有的协议来传输多媒体流，另外，它需要安装一个移动应用程序或桌面来访问电话、信息和视频会议等服务。不过，还是无法将电话与活跃的视频会议整合在一起[16]。
WebRTC架构提供端到端的加密P2P通信，视听内容和数据直接传输。实现了绕过中间的硬件服务器，消除了劫持者等安全难题。这一特殊功能使得WebRTC与Skype等其他RTC的区别在于Skype是专有的，缺乏直接的P2P能力，以及WebRTC中可信的安全功能。
点对点还可以使用户的数据加密，安全，不能泄露。点对点连接之所以可信，是因为它能够绕过所有与插件相关的问题。WebRTC中支持延迟、带宽和内存利用率等因素，以及对匿名性的支持[13]。
2.1.WEBRTC的结构
图1显示了WebRTC的架构。总的来说，WebRTC由三部分组成。
- Web开发者的API层；
- 浏览器开发者的API层；
- 浏览器开发者的定制服务层。
WebRTC（图1）包含语音引擎、视频引擎、视频引擎和视频引擎以及传输和通信的工具。Web浏览器和其他本地应用程序可以通过其C API访问该框架。出于安全和互操作性的原因，Web应用程序不能访问这种低级别的API，因此Web浏览器需要为开发人员提供另一种方式来使用它。标准的方式是通过JavaScript API来实现。Web应用程序可以使用标准化的JavaScript API来访问WebRTC的功能[2][4]。
图1.WebRTC的技术结构
语音引擎是一个主要负责音频的功能 处理。其功能包括音频解码和声音处理。
视频引擎主要涉及视频编解码和图像处理。在视频编解码方面，WebRTC目前采用的是VP8技术，这使得WebRTC能够在较低的元速率环境下提供更高质量的视频图像。在图像处理部分，WebRTC主要包括抖动缓冲和图像增强等功能，以降低摄像机拍摄图像的噪声。
传输功能主要负责对采集到的音视频进行加密、防火墙穿透和传输，采用SRTP（安全实时传输协议）协议进行传输，保证信息发送时的安全性[14]。
最常见的WebRTC梯形模型（见图2），两个浏览器都运行在一个Web应用程序上，从不同的Web Server（或通常在现场的一个共享服务器）下载。对等连接配置的路径直接在浏览器之间流动，不需要服务器的任何干预。信令通过HTTP或WebSockets，通过Web服务器，可以修改，翻译，或根据需要管理信号。在WebRTC中，服务器和浏览器之间的信令没有标准化，因为它是应用程序的一部分。两台Web服务器可以使用标准的信令协议进行通信，如Session initiation protocols（SIP）或Jingle[XEP-0166]。否则，可以使用专有的信令协议[7]。
图2.WebRTC梯形
一个WebRTC网络应用程序使用标准的WebRTC APIs来实现，让它能够正确地实时利用和控制浏览器功能。它必须做更多的事情：
- 获取流媒体音频、视频或其他数据；
- 获取有关网络的信息，如IP地址和端口，并与其他WebRTC客户端（被称为合作伙伴）改变这一点，以允许连接，即使NAT和防火墙；
- 协调信号通信，以报告错误并启动或结束会议；
- 改变有关媒体和客户能力的信息，如分辨率和编解码器。
- 传播流媒体音频、视频或数据[11]。
为了获取和通信流媒体数据，WebRTC是一个很好的选择来实现以下API：
- 媒体流。媒体流：获取数据源，例如用户的摄像头和麦克风。
- RTCPeerConnection：有加密和带宽管理功能的音频或视频通话；
- RTCDataChannel：通用数据的点对点通信。
2.2.关于WEBRTC协议
为了确保不同的实时浏览器实现之间的标准水平的互操作性，互联网工程任务组（IETF）致力于选择最少的音频和视频编解码器。Opus和G.711是必须实现的音频编解码器[8]，VP8和H.264约束基线是视频编解码器[9]。
API是围绕着三个主要概念设计的。PeerConnection，MediaStream和DataChannel。
PeerConnection机制使用交互式连接建立（ICE）协议与NAT的会话穿越工具（STUN）和NAT周围使用中继（TURN）服务器一起，让基于用户数据报协议（UDP）的媒体流穿越NAT盒子和防火墙。ICE允许浏览器发现足够的信息拓扑的网络部署，找到最佳可利用的通信路径。使用ICE还提供了一种安全措施，因为它可以防止网页和未加密的应用程序向主机发送它们不期望接收的数据[6]。
使用RTCPeerConnection和作为流控制传输协议通过UDP的数据报传输层安全（DTLS）构建的底层传输在对等体之间创建数据通道。
这种数据传输是通过SCTP与一些扩展实现的。SCTP对消息的本地支持传输和多流的优先级。SCTP对消息的大小没有任何限制。但是，SCTP的实现只有有限的发送和接收缓冲区，因此，也提供了非原子的发送和接收方式，允许传输大于这些缓冲区的消息。为了确保SCTP数据包的保密性和认证性，它们的发送由DTLS关联保护。这个DTLS关联是在ICE提供的低层传输流上运行的，通常是UDP。
实时通信是一个关键的活动，关于在视频流期间可能导致间歇性丢包的时间。WebRTC音频和视频编解码器已经超越了这一挑战，实现了各种逻辑来恢复数据包丢失或延迟。并同时将数据传输中的时效性和低延迟作为重要因素考虑。WebRTC考虑到这些因素比数据的可靠性更重要。这也是为什么UDP协议比传输控制协议（TCP）更适合传输实时数据的主要原因。TCP提供了一个可靠和有序的数据流。例如，如果一个中间数据包丢失了，那么TCP会对其之后的所有数据包进行缓冲，等待重传，然后再传送数据流进行恢复。同时，UDP没有提供消息传递或出生顺序的保证，没有确认、重传或超时，没有数据包序列号，没有线头阻塞，没有连接状态跟踪、建立或拆分状态机、拥塞控制、内置客户端或网络反馈机制。因此，UDP没有提供可靠性承诺。因此，UDP传输协议，将每个数据包送到目标应用中[12]。
STUN为请求者提供公共IP地址的端点。STUN是一个相对简单的过程，因为一旦STUN为请求者提供了一个可被公众访问的IP地址，它就不再参与对话了（见图3）。
图3.WebRTC协议栈
在端点处于NAT后面的情况下，它只能看得到本地IP地址。同呼叫中的其他端点将不能使用这个IP地址来
连接到端点，因为它可能是一个私有地址或防火墙不允许访问。在这种情况下，这个端点可能需要STUN服务器提供公共IP地址。然后，参
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[259996]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
