WebRTC理论入门

开篇导读，这篇是从 https://www.html5rocks.com/en/tutorials/webrtc/basics/ 搬运翻译过来的，属于WebRTC理论入门，感觉属于把webrtc说得比较通透清楚的一篇文章。往后再学习基于操作系统移植的SDK就更轻松了。

WebRTC is a new front in the long war for an open and unencumbered web.——Brendan Eich, inventor of JavaScript

无需插件的实时通讯

想象一下您的手机，电视和计算机可以在一个通用平台上进行通信的世界。想象一下，将视频聊天和对等数据共享添加到您的Web应用程序变得更容易。这就是WebRTC的愿景。

想尝试一下吗？在Google Chrome，Safari，Firefox和Opera的台式机和移动设备上都可以使用WebRTC。一个不错的起点是位于 appr.tc 的简单视频聊天应用程序：

在浏览器中打开 appr.tc .
单击加入以加入聊天室，然后让该应用使用您的网络摄像头。
在新标签页中打开页面末尾显示的URL，或者最好在另一台计算机上打开。

快速入门

如果您尚未使用过getUserMedia API，看看 Capture audio and video in HTML5 还有 simpl.info getUserMedia.
需要了解RTCPeerConnection API，看这个 following example 还有 simpl.info RTCPeerConnection.
要了解WebRTC如何将服务器用于信令以及防火墙和NAT的遍历，看这个例子 appr.tc. 的控制打印日志。
等不及要立即尝试WebRTC？尝试使用20多个 20 demos 演示WebRTC JavaScript API的示例。
您的机器启动WebRTC遇到问题了吗？访问这里吧 WebRTC Troubleshooter.

另外，直接进入WebRTC代码实验室 / WebRTC codelab，这是一个分步指南，介绍了如何构建完整的视频聊天应用程序，包括简单的信令服务器。

短暂的WebRTC简史

网络的最后一项主要挑战是通过语音和视频实现人与人之间的交流：实时通信或简称RTC。在网络应用中，RTC应该与在文本输入中输入文本一样自然。没有它，您在创新和开发新的人际互动方式方面的能力将受到限制。从历史上看，RTC一直是合作性的，而且很复杂，需要昂贵的音频和视频技术才能在内部获得许可或开发。将RTC技术与现有的内容，数据和服务集成在一起非常困难且耗时，尤其是在Web上。

Gmail视频聊天在2008年开始流行，2011年，Google引入了环聊，该环聊使用了Talk（与Gmail一样）。谷歌收购了GIPS，这是一家开发RTC所需的许多组件的公司，例如编解码器和回声消除技术。Google开源了GIPS开发的技术，并与Internet工程任务组（IETF）和万维网联盟（W3C）的相关标准机构合作，以确保行业共识。2011年5月，爱立信构建了WebRTC的第一个实现。

WebRTC为实时，无插件的视频，音频和数据通信实施了开放标准。过去的情况是这样的：

许多Web服务使用RTC，但需要下载，本机应用程序或插件。其中包括Skype，Facebook和环聊。
下载，安装和更新插件很复杂，容易出错，而且很烦人。
插件难以部署，调试，故障排除，测试和维护，并且可能需要许可以及与复杂，昂贵的技术的集成。首先说服人们安装插件通常很困难！

WebRTC项目的指导原则是其API应该是开源的，免费的，标准化的，内置在Web浏览器中的，并且比现有技术更有效。

现在我们去到哪一步了？

WebRTC用于各种应用程序中，例如Google Meet。 WebRTC也已与WebKitGTK +和Qt本机应用程序集成。

WebRTC实现了以下三套API：

MediaStream (也可以叫作 getUserMedia)
RTCPeerConnection
RTCDataChannel

这些API在以下两个规范中定义：

WebRTC
getUserMedia

在移动设备和台式机上的Chrome，Safari，Firefox，Edge和Opera都支持这三种API。

getUserMedia: 有关演示和代码，请参阅 WebRTC samples 或尝试Chris Wilson的惊人示例examples ，这些示例使用getUserMedia作为Web音频的输入。

RTCPeerConnection: 对于一个简单的演示和一个功能齐全的视频聊天应用程序，请查阅 WebRTC samples Peer connection 还有 appr.tc. 这些例子都用到了 adapter.js, 由Google在 WebRTC community 的帮助下维护的JavaScript填充程序，为了抽象各个浏览器之间的差异转变所需要的库。

RTCDataChannel: 要查看实际效果，查阅 WebRTC samples 以检出数据通道演示之一。

WebRTC代码实验室 / WebRTC codelab 展示了如何使用所有这三个API来构建用于视频聊天和文件共享的简单应用程序。

第一个WebRTC

WebRTC应用程序所要做的几件事：

获取流音频，视频或其他数据。
获取网络信息，譬如IP地址和端口，并与其他WebRTC客户端（称为对等端）进行交换以启用连接，即使通过NAT和防火墙。
协调信令通信以报告错误并启动或关闭会话。
交换有关媒体和客户端功能的信息，例如分辨率和编解码器。
交换音频流，视频流或数据流。

为了获取和传递流数据，WebRTC实现了以下API：

MediaStream 可以访问数据流，例如来自用户的摄像头和麦克风的数据流。
RTCPeerConnection 启用具有加密和带宽管理功能的音频或视频呼叫。
RTCDataChannel 启用通用数据的对等通信。

（稍后将详细讨论WebRTC的网络和信令方面。）

`MediaStream` API (通常也称为 `getUserMedia` API)

MediaStream API 表示媒体的同步流。例如，从摄像机和麦克风输入获取的流具有同步的视频和音频轨道。（不要将MediaStreamTrack与<track>元素混淆，这是完全不同的东西。）理解MediaStream API的最简单方法可能是在使用中对其进行查看：

在您的浏览器中，导航到 WebRTC samples getUserMedia.
F12打开控制台
全局范围内，检查 stream 变量。

每个MediaStream都有一个输入（可能是getUserMedia（）生成的MediaStream）和一个输出（可能会传递给视频元素或RTCPeerConnection）。每个MediaStream都有一个标签，例如'Xk7EuLhsuHKbnjLWkW4yYGNJJ8ONsgwHBvLQ'。 getAudioTracks和getVideoTracks方法返回MediaStreamTracks的数组。

对于getUserMedia示例，stream.getAudioTracks返回一个空数组（因为没有音频），并且假设已连接正常的网络摄像头，stream.getVideoTracks返回一个MediaStreamTrack数组，该数组表示来自网络摄像头的流。每个MediaStreamTrack都有一种（“视频”或“音频”），标签（诸如“ FaceTime HD摄像机 ”之类），并代表一个或多个音频或视频通道。在当前的例子情况下，只有一条视频轨道而没有音频，但是很容易联想到多个track的用例，例如从前置摄像头，后置摄像头，麦克风获取视频流的聊天应用程序，以及共享其屏幕的应用程序。

通过设置srcObject attribute属性，可以将MediaStream附加到视频元素。以前是通过将src属性设置为使用URL.createObjectURL创建的对象URL来完成的，但已不建议这样做。

MediaStreamTrack正在积极使用摄像头，该摄像头占用资源并保持摄像头打开和摄像头点亮。当您不再使用轨道时，请确保调用 track.stop 以便可以关闭相机。

getUserMedia也可以用作 Web Audio API 的输入节点：

// Cope with browser differences.
let audioContext;
if (typeof AudioContext === 'function') {audioContext = new AudioContext();
} else if (typeof webkitAudioContext === 'function') {audioContext = new webkitAudioContext(); // eslint-disable-line new-cap
} else {console.log('Sorry! Web Audio not supported.');
}// Create a filter node.
var filterNode = audioContext.createBiquadFilter();
// See https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#BiquadFilterNode-section
filterNode.type = 'highpass';
// Cutoff frequency. For highpass, audio is attenuated below this frequency.
filterNode.frequency.value = 10000;// Create a gain node to change audio volume.
var gainNode = audioContext.createGain();
// Default is 1 (no change). Less than 1 means audio is attenuated
// and vice versa.
gainNode.gain.value = 0.5;navigator.mediaDevices.getUserMedia({audio: true}, (stream) => {// Create an AudioNode from the stream.const mediaStreamSource =audioContext.createMediaStreamSource(stream);mediaStreamSource.connect(filterNode);filterNode.connect(gainNode);// Connect the gain node to the destination. For example, play the sound.gainNode.connect(audioContext.destination);
});

基于Chromium的应用程序和扩展也可以合并getUserMedia。在清单中添加audioCapture和/或videoCapture权限后，仅在安装时即可请求和授予一次权限。此后就不需要请求用户许可访问摄像机或麦克风。只需为getUserMedia（）授予一次权限。第一次，浏览器的信息栏中会显示“允许”按钮。 Chrome于2015年底弃用了对getUserMedia（）的HTTP访问，因为它被归类为功能强大的功能。目的可能是为任何流数据源启用MediaStream，而不仅仅是相机或麦克风。这将使得能够从存储的数据或任意数据源（例如传感器或其他输入）中进行流式传输。

与其他JavaScript API和库结合使用时，getUserMedia（）真正变得生动起来：

Webcam Toy 是一个照相亭应用程序，它使用WebGL向可以在本地共享或保存的照片中添加怪异而奇妙的效果。
FaceKat 是使用 headtrackr.js 构建的面部跟踪游戏。
ASCII Camera 使用Canvas API生成ASCII图像。

约束条件

Constraints 约束条件可用于为getUserMedia设置视频分辨率的值。这也允许支持其他约束，例如长宽比；面向模式（前置或后置摄像头）；帧率，高度和宽度；和 applyConstraints方法。有关示例，请参见WebRTC示例 getUserMedia: select resolution.

陷阱提醒：getUserMedia约束可能会影响共享资源的可用配置。例如，如果通过一个页面标签以640 x 480模式打开相机，另一个页面标签将无法使用约束在高分辨率模式下打开它，因为它只能在一种模式下打开。请注意，这是一个实现细节。可以让第二个标签页在高分辨率模式下重新打开相机，并使用视频处理将第一个标签页的视频轨道缩小为640 x 480，但这尚未实现。

如果请求的分辨率不可用，或设置不允许的约束值将给出DOMException或OverconstrainedError。要查看实际效果，请参阅 WebRTC samples getUserMedia: select resolution

屏幕和标签页捕获

Chrome应用程序还可以通过chrome.tabCapture和chrome.desktopCapture API共享单个浏览器标签或整个桌面的实时视频。（有关演示和更多信息，请参见使用 Screensharing with WebRTC。该文章已有几年历史，但仍然很有趣。）

使用实验性chromeMediaSource约束，也可以将屏幕截图用作Chrome中的MediaStream源。请注意，屏幕捕获需要HTTPS，并且仅应用于开发，因为它是通过本文中介绍的命令行标志启用的，因此只能用于开发。

信令：会话控制，网络和媒体信息

WebRTC使用RTCPeerConnection在浏览器（也称为对等设备）之间通信流数据，但还需要一种机制来协调通信并发送控制消息，此过程被称为信令。WebRTC未指定信令方法和协议。信令不是RTCPeerConnection API的一部分。相反，WebRTC应用程序开发人员可以选择他们喜欢的任何消息协议，例如SIP或XMPP，以及任何适当的全双工（双向）通道进行信令通信。appr.tc 示例使用XHR和Channel API作为信令机制。代码实验室 / codelab 使用 Socket.io running on a Node server.

信令用于交换三种类型的信息：

会话控制消息：初始化或关闭通讯并报告错误。
网络配置：对于外部世界，您的计算机的IP地址和端口是什么？
多媒体功能配置：您的浏览器及其要与之通信的浏览器可以处理哪些编解码器和分辨率？

在开始对等流传输之前，必须成功完成通过信令进行的信息交换。例如，假设爱丽丝Alice想与鲍勃Bob进行交流。这是来自 W3C WebRTC spec 的代码示例，该示例显示了实际的信令过程。该代码假定存在在createSignalingChannel方法中创建的某种信令机制。

// handles JSON.stringify/parse
const signaling = new SignalingChannel();
const constraints = {audio: true, video: true};
const configuration = {iceServers: [{urls: 'stuns:stun.example.org'}]};
const pc = new RTCPeerConnection(configuration);// Send any ice candidates to the other peer.
pc.onicecandidate = ({candidate}) => signaling.send({candidate});// Let the "negotiationneeded" event trigger offer generation.
pc.onnegotiationneeded = async () => {try {await pc.setLocalDescription(await pc.createOffer());// Send the offer to the other peer.signaling.send({desc: pc.localDescription});} catch (err) {console.error(err);}
};// Once remote track media arrives, show it in remote video element.
pc.ontrack = (event) => {// Don't set srcObject again if it is already set.if (remoteView.srcObject) return;remoteView.srcObject = event.streams[0];
};// Call start() to initiate.
async function start() {try {// Get local stream, show it in self-view, and add it to be sent.const stream =await navigator.mediaDevices.getUserMedia(constraints);stream.getTracks().forEach((track) =>pc.addTrack(track, stream));selfView.srcObject = stream;} catch (err) {console.error(err);}
}signaling.onmessage = async ({desc, candidate}) => {try {if (desc) {// If you get an offer, you need to reply with an answer.if (desc.type === 'offer') {await pc.setRemoteDescription(desc);const stream =await navigator.mediaDevices.getUserMedia(constraints);stream.getTracks().forEach((track) =>pc.addTrack(track, stream));await pc.setLocalDescription(await pc.createAnswer());signaling.send({desc: pc.localDescription});} else if (desc.type === 'answer') {await pc.setRemoteDescription(desc);} else {console.log('Unsupported SDP type.');}} else if (candidate) {await pc.addIceCandidate(candidate);}} catch (err) {console.error(err);}
};

首先，爱丽丝Alice和鲍勃Bob交换网络信息。（寻找候选者 是指使用 ICE framework 框架寻找网络接口和端口的过程。）

爱丽丝Alice 创建一个RTCPeerConnection对象并添加onicecandidate处理程序，该处理程序在网络候选项可用时回调执行。
爱丽丝Alice将序列化的候选数据发送给鲍勃Bob，通过先前使用的任何信令通道（例如WebSocket或其他某种机制）
当鲍勃Bob从爱丽丝Alice获得候选消息时，他调用addIceCandidate将候选信息，添加到自身RTCPeerConnection对象中的远程对等描述中（setRemoteDescription）。

WebRTC客户端（在本示例中也称为对等方，或Alice和Bob）还需要确定并交换本地和远程音频和视频媒体信息，例如解析度和编解码器功能。通过使用会话描述协议（SDP）交换 offer 和 answer，可以发出交换媒体配置信息的信号：

爱丽丝Alice执行 RTCPeerConnection createOffer() 方法。方法返回的对象传递给RTCSessionDescription——Alice的本地会话描述。
在回调中，Alice使用setLocalDescription设置本地描述，然后通过其信令通道将此会话描述发送给Bob。请注意，直到调用setLocalDescription为止，RTCPeerConnection才开始收集候选对象。这已编入JSEP IETF draft中。
鲍勃Bob使用setRemoteDescription将爱丽丝Alice发送给他的描述设置为远程描述。
鲍勃Bob执行 RTCPeerConnection createAnswer() 方法，将他从爱丽丝那里得到的远程描述传递给它(RTCPeerConnection)，以便可以生成与她兼容的本地会话。createAnswer() 的回调会回传 RTCSessionDescription对象，鲍勃Bob将其设置为本地描述，并将其发送给爱丽丝Alice。
当爱丽丝获得鲍勃的会话描述时，她使用setRemoteDescription将其设置为远程描述。
Ping!

提示：确保不再使用RTCPeerConnection后调用close()来允许RTCPeerConnection被垃圾回收。否则，线程和连接将保持活动状态。可能会在WebRTC中泄漏大量资源！

RTCSessionDescription是符合SDP会话描述协议的对象。序列化后，SDP描述符大致如下所示：

v=0
o=- 3883943731 1 IN IP4 127.0.0.1
s=
t=0 0
a=group:BUNDLE audio video
m=audio 1 RTP/SAVPF 103 104 0 8 106 105 13 126
// ...
a=ssrc:2223794119 label:H4fjnMzxy3dPIgQ7HxuCTLb4wLLLeRHnFxh810

网络和媒体信息的获取和交换可以同时进行，但必须先完成两个过程，然后才能开始对等方之间的音频和视频流传输。

先前描述的 offer/answer 架构称为JavaScript会话建立协议，或JSEP。（有一个出色的动画 Ericsson's demo video 解释了爱立信首个WebRTC实施的演示视频中的信令和流传输过程。）

信令过程成功完成后，数据可以在呼叫者和被呼叫者之间直接点对点流式传输——或者，如果失败，则通过中间中继服务器（稍后会详细介绍）。流化是RTCPeerConnection的主要工作内容。

RTCPeerConnection

RTCPeerConnection是WebRTC组件，用于处理对等端之间的流数据的稳定和高效的通信。以下是WebRTC架构图，显示了RTCPeerConnection的角色。您会注意到，绿色部分很复杂！

从JavaScript的角度来看，从该图中可以理解的主要事情是RTCPeerConnection使Web开发人员免受潜在的各种复杂问题的困扰。

WebRTC使用的编解码器和协议进行了大量工作，即使在不可靠的网络上也可以进行实时通信：

隐藏丢包
回声消除
带宽适应性
动态抖动缓冲
自动增益控制
降噪抑制
影像清理

先前的W3C代码从信令角度展示了WebRTC的简化示例，以下是两个有效的WebRTC应用程序的演练。第一个是演示RTCPeerConnection的简单示例，第二个是功能全面的视频聊天客户端。

RTCPeerConnection without servers

以下代码摘自WebRTC示例对等连接WebRTC samples Peer connection，在同一个网页上具有本地和远程RTCPeerConnection（以及本地和远程视频）。这在现实当中并没有什么用处—呼叫者和被呼叫者在同一页面上，但这确实使RTCPeerConnection API的工作原理更加清晰，因为页面上的RTCPeerConnection对象可以直接交换数据和消息，而不必使用中间信令机制。在此示例中，pc1代表本地对等方（呼叫方），而pc2代表远程对等方（被呼叫方）。

1、创建一个新的 RTCPeerConnection 并从 getUserMedia 获取添加多媒体流

// Servers is an optional configuration file. (See TURN and STUN discussion later.)
pc1 = new RTCPeerConnection(servers);
// ...
localStream.getTracks().forEach((track) => {pc1.addTrack(track, localStream);
});

2、创建一个offer，并将其设置为pc1的本地描述和pc2的远程描述。这可以直接在代码中完成，而无需使用信令，因为调用方和被调用方都在同一页面上：

pc1.setLocalDescription(desc).then(() => {onSetLocalSuccess(pc1);},onSetSessionDescriptionError);trace('pc2 setRemoteDescription start');pc2.setRemoteDescription(desc).then(() => {onSetRemoteSuccess(pc2);},onSetSessionDescriptionError);

3、创建pc2，并添加来自pc1的流后，将其显示在视频元素中：

pc2 = new RTCPeerConnection(servers);
pc2.ontrack = gotRemoteStream;
//...
function gotRemoteStream(e){vid2.srcObject = e.stream;
}

`RTCPeerConnection` API plus servers

在现实世界中，WebRTC需要服务器（无论多么简单），因此可能发生以下情况：

用户彼此发现并交换现实世界的详细信息，例如姓名。
WebRTC客户端应用程序（对等）交换网络信息。
对等方交换有关媒体的数据，例如视频格式和分辨率。
WebRTC客户端应用程序穿透 NAT网关NAT gateways 和防火墙。

换句话说，WebRTC需要四种类型的服务器端功能：

用户发现和交流
发信号
NAT / 防火墙的穿透
对等通信失败时，失败尝试的中继服务器和转发服务器

NAT穿透，端对端对等网络，以及为用户发现和信令构建服务器应用程序的要求不在本文讨论范围之内。可以说，ICE框架使用 STUN 协议及其扩展名TURN来使RTCPeerConnection能够应对NAT遍历和其他网络问题。ICE是用于连接对等方（例如两个视频聊天客户端）的框架。最初，ICE尝试通过UDP以尽可能短的延迟直接连接对等方。在此过程中，STUN服务器只有一个任务：使NAT后面的对等方能够找到其公共地址和端口。有关STUN和TURN的更多信息，请参阅（我翻译的——构建WebRTC应用程序所需的后端服务。原文—— Build the backend services needed for a WebRTC app.）

如果UDP失败，则ICE尝试使用TCP。如果直接连接失败——特别是由于企业NAT穿越和防火墙——ICE使用中间（中继）TURN服务器。换句话说，ICE首先将STUN与UDP结合使用以直接连接对等方，然后，如果失败，则回退到TURN中继中转服务器。finding candidates 是指查找网络接口和端口的过程。

WebRTC工程师Justin Uberti在 2013 Google I/O WebRTC presentation. 演讲中提供了有关ICE，STUN和TURN的更多信息。（演示幻灯片 slides 提供了TURN和STUN服务器实现的示例。）

appr.tc 上的视频聊天演示是尝试WebRTC（使用STUN服务器完成信令和NAT /防火墙穿越）的一个好地方。该应用程序使用adapter.js 来隔离应用程序的规格更改和前缀差异。该代码在其记录中刻意冗长。检查控制台以了解事件的顺序。以下是该代码的详细演练。

如果您觉得这有点莫名其妙，那么您可能更喜欢（我翻译的）WebRTC代码实验室 /（原链接）WebRTC codelab。
本分步指南介绍了如何构建完整的视频聊天应用程序，包括在节点服务器上运行的简单信令服务器。

网络拓扑

目前实施的WebRTC仅支持一对一通信，但可以用于更复杂的网络场景中，例如与多个对等点，每个对等点直接相互通信或通过多点控制单元进行通信 Multipoint Control Unit 简称MCU——可以处理大量参与者并进行选择性流转发以及音频和视频混合或录制的服务器。

许多现有的WebRTC应用程序仅演示了网络浏览器之间的通信，但是网关服务器可以使在浏览器上运行的WebRTC应用与设备进行交互，例如电话（也称为PSTN）和VOIP系统。2012年5月，Doangbango Telecom开源了使用WebRTC和WebSocket构建的 sipml5 SIP 客户端，该客户端（以及其他潜在用途）允许在iOS和Android上运行的浏览器与应用之间进行视频通话。在Google I / O上，Tethr和Tropo在一个公文包中演示了一个灾难通信框架，该框架使用OpenBTS单元通过WebRTC启用功能电话和计算机之间的通信。没有承运人的电话通讯！（原文 a framework for disaster communications in a briefcase using an OpenBTS cell to enable communications between feature phones and computers through WebRTC.）

`RTCDataChannel` API

除了音频和视频，WebRTC还支持其他类型数据的实时通信。RTCDataChannel API支持低延迟和高吞吐量的对等交换任意数据。有关单页演示，以及要了解如何构建简单的文件传输应用程序，请分别参见 WebRTC samples 和 WebRTC codelab。该API有很多潜在的用例，包括：

游戏
远程桌面应用
实时文本聊天
文件传输
分散网络

该API具有多项功能，可充分利用RTCPeerConnection并实现强大而灵活的对等通信：

利用RTCPeerConnection进行会话设置
具有优先级的多个同时通道
可靠和不可靠的交付语义
内置安全性（DTLS）和拥塞控制
能够使用或不使用音频或视频

语法故意设计成类似于WebSocket，带有send 方法和 message 事件：

const localConnection = new RTCPeerConnection(servers);
const remoteConnection = new RTCPeerConnection(servers);
const sendChannel = localConnection.createDataChannel('sendDataChannel');remoteConnection.ondatachannel = (event) => {receiveChannel = event.channel;receiveChannel.onmessage = onReceiveMessage;receiveChannel.onopen = onReceiveChannelStateChange;receiveChannel.onclose = onReceiveChannelStateChange;
};function onReceiveMessage(event) {document.querySelector("textarea#send").value = event.data;
}document.querySelector("button#send").onclick = () => {var data = document.querySelector("textarea#send").value;sendChannel.send(data);
};

通信是直接在浏览器之间进行的，因此即使在打孔穿透防火墙和NAT失败时需要中继（TURN）服务器，RTCDataChannel也可以比WebSocket快得多。RTCDataChannel在Chrome，Safari，Firefox，Opera和Samsung Internet中可用。Cube Slam 游戏使用API传达游戏状态。扮演朋友或扮演熊！通过RTCDataChannel和peerCDN进行共享的创新平台Sharefest支持的文件共享，使人一目了然WebRTC如何实现对等内容分发。有关RTCDataChannel的更多信息，请查看IETF的协议规范草案 —— draft protocol spec

安全性

实时通信应用程序或插件可能会以几种方式危及安全性。例如：

未加密的媒体或数据可能在浏览器之间或浏览器与服务器之间被截获。
应用可能会在用户不知情的情况下录制和分发视频或音频。
恶意软件或病毒可能与明显无害的插件或应用程序一起安装。

WebRTC具有避免这些问题的几种功能：

WebRTC实施使用安全协议，例如 DTLS 和 SRTP.
加密对于所有WebRTC组件都是必需的，包括信令机制。
WebRTC不是插件。它的组件在浏览器沙箱中运行，而不是在单独的进程中运行。组件不需要单独安装，并且只要更新浏览器就可以更新。
必须明确授予对摄像头和麦克风的访问权限，并且在运行摄像头或麦克风时，用户界面会清楚地显示这一点。

有关流媒体安全性的完整讨论不在本文讨论范围之内。有关更多信息，请参阅IETF提出的WebRTC安全体系结构提案—— Proposed WebRTC Security Architecture。

开发者工具 Developer tools

正在进行的会话的WebRTC统计信息可在以下位置找到（在空白标签输入以下url）：

chrome://webrtc-internals in Chrome
opera://webrtc-internals in Opera
about:webrtc in Firefox

获取更多 Learn more

Justin Uberti's WebRTC session at Google I/O 2012
Alan B. Johnston and Daniel C. Burnett maintain a WebRTC book now in its third edition in print and eBook formats at webrtcbook.com.
webrtc.org is home to all things WebRTC, including demos, documentation, and discussion.
discuss-webrtc is a Google Group for technical WebRTC discussion.
@webrtc
Google Developers Talk documentation provides more information about NAT traversal, STUN, relay servers, and candidate gathering.
WebRTC on GitHub
Stack Overflow is a good place to look for answers and ask questions about WebRTC.
Native APIs for RTCPeerConnection are also available at documentation on webrtc.org.