WebRTC 使用入门详解

文档来源https://webrtc.org/getting-started/media-devices?hl=zh-cn

面向网络的实时通信

借助 WebRTC，您可以为应用添加基于开放标准运行的实时通信功能。它支持在对等设备之间发送视频、语音和通用数据，使开发者能够构建强大的语音和视频通信解决方案。这项技术适用于所有现代浏览器以及所有主要平台的原生客户端。WebRTC 采用的技术是开放网络标准，以常规 JavaScript API 的形式在所有主流浏览器中提供。对于原生客户端（例如 Android 和 iOS 应用），可以使用具备相同功能的库。WebRTC 项目属于开源项目，受 Apple、Google、Microsoft 和 Mozilla 等公司支持。

WebRTC 使用入门

WebRTC（全称 Web Real-Time Communication），即网页即时通信。 是一个支持网页浏览器进行实时语音对话或视频对话的技术方案。从前端技术开发的视角来看，是一组可调用的API标准。

如果您不熟悉基于 API 的 API，那么基于 WebRTC 技术构建的新应用可能会让您应接不暇。在本部分中，我们将通过介绍一些常见的使用场景和代码段来介绍如何开始使用 WebRTC 标准中的各种 API。

WebRTC API

WebRTC 标准概括介绍了两种不同的技术：媒体捕获设备和点对点连接。

媒体捕获设备包括摄像机和麦克风，还包括屏幕捕获设备。对于摄像头和麦克风，我们使用 navigator.mediaDevices.getUserMedia() 来捕获 MediaStreams。对于屏幕录制，我们改为使用 navigator.mediaDevices.getDisplayMedia()。

点对点连接由 RTCPeerConnection 接口处理。这是在 WebRTC 中两个对等方之间建立和控制连接的中心点。

媒体设备使用入门

针对 Web 开发时，WebRTC 标准提供了用于访问连接到计算机或智能手机的相机和麦克风的 API。这些设备通常称为媒体设备，可以通过实现 MediaDevices 接口的 navigator.mediaDevices 对象使用 JavaScript 进行访问。通过此对象，我们可以枚举所有已连接的设备，监听设备的变化（设备连接或断开连接时）以及打开设备以检索媒体流（见下文）。

其最常见的方式是通过 getUserMedia() 函数，该函数会返回一个解析为匹配媒体设备的 MediaStream 的 promise。此函数采用单个 MediaStreamConstraints 对象，用于指定我们的要求。例如，要简单地打开默认麦克风和摄像头，请执行以下操作。

// 使用promise
const constraints = {
    'video': true,
    'audio': true
}
navigator.mediaDevices.getUserMedia(constraints)
    .then(stream => {
        console.log('Got MediaStream:', stream);
    })
    .catch(error => {
        console.error('Error accessing media devices.', error);
    });

// 使用await/async
const openMediaDevices = async (constraints) => {
    return await navigator.mediaDevices.getUserMedia(constraints);
}

try {
    const stream = openMediaDevices({'video':true,'audio':true});
    console.log('Got MediaStream:', stream);
} catch(error) {
    console.error('Error accessing media devices.', error);
}

调用 getUserMedia() 将触发权限请求。如果用户接受该权限，系统会使用包含一个视频和一个音轨的 MediaStream 解析该 promise。如果权限遭拒，系统会抛出 PermissionDeniedError。如果没有连接任何匹配的设备，则会抛出 NotFoundError。

MDN 网络文档中提供了 MediaDevices 接口的完整 API 参考文档

查询媒体设备

在更复杂的应用中，我们很可能需要检查所有连接的摄像头和麦克风，并向用户提供相应的反馈。这可以通过调用 enumerateDevices() 函数来实现。这将返回一个 promise，它可以解析为描述每个已知媒体设备的 MediaDevicesInfo 数组。我们可以用它来呈现界面，让用户选择他们喜欢的那个。每个 MediaDevicesInfo 都包含一个名为 kind 的属性，其值为 audioinput、audiooutput 或 videoinput，指示它是哪种类型的媒体设备。

// promise
function getConnectedDevices(type, callback) {
    navigator.mediaDevices.enumerateDevices()
        .then(devices => {
            const filtered = devices.filter(device => device.kind === type);
            callback(filtered);
        });
}

getConnectedDevices('videoinput', cameras => console.log('Cameras found', cameras));

// async await
async function getConnectedDevices(type) {
    const devices = await navigator.mediaDevices.enumerateDevices();
    return devices.filter(device => device.kind === type)
}

const videoCameras = getConnectedDevices('videoinput');
console.log('Cameras found:', videoCameras);

监听设备更改

大多数计算机都支持在运行时插入各种设备。它可能是通过 USB 连接的摄像头、蓝牙耳机或一组外部扬声器。为了正确支持这一点，Web 应用应监听媒体设备的变化。这可以通过为 devicechange 事件的 navigator.mediaDevices 添加监听器来实现。

// Updates the select element with the provided set of cameras
function updateCameraList(cameras) {
    const listElement = document.querySelector('select#availableCameras');
    listElement.innerHTML = '';
    cameras.map(camera => {
        const cameraOption = document.createElement('option');
        cameraOption.label = camera.label;
        cameraOption.value = camera.deviceId;
    }).forEach(cameraOption => listElement.add(cameraOption));
}

// Fetch an array of devices of a certain type
async function getConnectedDevices(type) {
    const devices = await navigator.mediaDevices.enumerateDevices();
    return devices.filter(device => device.kind === type)
}

// Get the initial set of cameras connected
const videoCameras = getConnectedDevices('videoinput');
updateCameraList(videoCameras);

// Listen for changes to media devices and update the list accordingly
navigator.mediaDevices.addEventListener('devicechange', event => {
    const newCameraList = getConnectedDevices('video');
    updateCameraList(newCameraList);
});

媒体限制

如果约束对象必须实现 MediaStreamConstraints 接口并将其作为参数传递给 getUserMedia()，我们就可以打开符合特定要求的媒体设备。此要求可以非常宽泛（音频和/或视频），也可以非常具体（最低相机分辨率或确切设备 ID）。建议使用 getUserMedia() API 的应用先检查现有设备，然后使用 deviceId 限制条件指定与设备完全匹配的限制条件。如果可能，设备还会根据限制条件进行配置。我们可以对麦克风启用回声消除功能，也可以从摄像头设置视频的特定或最小宽度和高度。

async function getConnectedDevices(type) {
    const devices = await navigator.mediaDevices.enumerateDevices();
    return devices.filter(device => device.kind === type)
}

// Open camera with at least minWidth and minHeight capabilities
async function openCamera(cameraId, minWidth, minHeight) {
    const constraints = {
        'audio': {'echoCancellation': true},
        'video': {
            'deviceId': cameraId,
            'width': {'min': minWidth},
            'height': {'min': minHeight}
            }
        }

    return await navigator.mediaDevices.getUserMedia(constraints);
}

const cameras = getConnectedDevices('videoinput');
if (cameras && cameras.length > 0) {
    // Open first available video camera with a resolution of 1280x720 pixels
    const stream = openCamera(cameras[0].deviceId, 1280, 720);
}

如需查看 MediaStreamConstraints 接口的完整文档，请参阅 MDN 网络文档。

本地播放

媒体设备打开后，如果有 MediaStream，我们可以将其分配给视频或音频元素，以在本地播放流。

async function playVideoFromCamera() {
    try {
        const constraints = {'video': true, 'audio': true};
        const stream = await navigator.mediaDevices.getUserMedia(constraints);
        const videoElement = document.querySelector('video#localVideo');
        videoElement.srcObject = stream;
    } catch(error) {
        console.error('Error opening video camera.', error);
    }
}

与 getUserMedia() 一起使用的典型视频元素所需的 HTML 通常具有 autoplay 和 playsinline 属性。autoplay 属性将使分配给元素的新数据流自动播放。playsinline 属性允许视频在特定移动浏览器中内嵌播放，而不仅仅是全屏播放。此外，我们还建议对直播使用 controls="false"，除非用户应能够暂停这些直播。

<html>
<head><title>Local video playback</video></head>
<body>
    <video id="localVideo" autoplay playsinline controls="false"/>
</body>
</html>

媒体捕获和约束

WebRTC 的媒体部分介绍了如何使用能够捕捉视频和音频的硬件（例如相机和麦克风），以及媒体流的工作原理。此外，还介绍了显示媒体，这是应用可执行屏幕捕获的方式。

媒体设备

您可以通过 navigator.mediaDevices 对象访问和管理浏览器支持的所有摄像头和麦克风。应用可以检索已连接设备的最新列表并监听变化，因为许多相机和微型麦克风可通过 USB 连接，并且可以在应用生命周期内连接和断开连接。由于媒体设备的状态可能会随时发生变化，因此建议应用注册设备更改，以便正确处理更改。

约束条件

访问媒体设备时，建议您提供尽可能详细的限制条件。虽然可以通过简单的约束条件打开默认摄像头和麦克风，但其提供的媒体流可能明显优于应用的最佳流。

具体的约束条件在 MediaTrackConstraint 对象中定义，一个针对音频，另一个针对视频。此对象中的特性类型为 ConstraintLong、ConstraintBoolean、ConstraintDouble 或 ConstraintDOMString。这些对象可以是特定值（例如数字、布尔值或字符串）、范围（具有最小值和最大值的 LongRange 或 DoubleRange）或具有 ideal 或 exact 定义的对象。对于特定值，浏览器将尝试选择尽可能接近的值。对于某个范围，将使用该范围内的最佳值。指定 exact 后，系统将仅返回与约束条件完全匹配的媒体流。

// Camera with a resolution as close to 640x480 as possible
{
    "video": {
        "width": 640,
        "height": 480
    }
}

// Camera with a resolution in the range 640x480 to 1024x768
{
    "video": {
        "width": {
            "min": 640,
            "max": 1024
        },
        "height": {
            "min": 480,
            "max": 768
        }
    }
}

// Camera with the exact resolution of 1024x768
{
    "video": {
        "width": {
            "exact": 1024
        },
        "height": {
            "exact": 768
        }
    }
}

为了确定某个媒体流的特定轨道的实际配置，我们可以调用 MediaStreamTrack.getSettings()，它会返回当前应用的 MediaTrackSettings。

此外，也可以通过对媒体轨道上调用 applyConstraints() 来更新已打开的媒体设备上的轨道约束条件。这样，应用无需重新关闭现有音频流，即可重新配置媒体设备。

显示媒体

想要能够截取和录制屏幕的应用必须使用 Display Media API。函数 getDisplayMedia()（属于 navigator.mediaDevices 的一部分）与 getUserMedia() 类似，用于打开显示内容（或部分内容，如窗口）。返回的 MediaStream 与使用 getUserMedia() 时相同。

getDisplayMedia() 的约束条件与常规视频或音频输入资源的限制不同。

{
    video: {
        cursor: 'always' | 'motion' | 'never',
        displaySurface: 'application' | 'browser' | 'monitor' | 'window'
    }
}

上述代码片段展示了屏幕录制的特殊限制的工作原理。请注意，并非所有支持显示媒体支持的浏览器都支持这些属性。

数据流和轨道

MediaStream 表示媒体内容流，由音频和视频轨道 (MediaStreamTrack) 组成。您可以通过调用 MediaStream.getTracks() 从 MediaStream 检索所有轨道，该方法会返回一组 MediaStreamTrack 对象。

媒体流跟踪

MediaStreamTrack 具有的 kind 属性为 audio 或 video，用于表示其表示的媒体类型。您可以通过切换其 enabled 属性将各个轨道静音。轨道具有布尔属性 remote，它会指示它来自 RTCPeerConnection 而来自远程对等设备。

开始使用对等连接

点对点连接是 WebRTC 规范的一部分，该规范旨在对点一台计算机上的两台应用进行连接，以使用点对点协议进行通信。对等设备之间的通信可以是视频、音频或任意二进制数据（适用于支持 RTCDataChannel API 的客户端）。为了发现两个对等端如何连接，两个客户端都需要提供 ICE Server 配置。这是 STUN 或 TURN 服务器，其作用是向每个客户端提供 ICE 候选对象，然后这些客户端将被传输到远程对等方。这种转移 ICE 候选对象的方式通常称为信号。

ICE的全称是Interactive Connectivity Establishment，即交互式连接建立

STUN的全称是Session Traversal Utilities for NAT，即NAT会话穿越应用程序（原来也叫简单的用UDP穿透NAT，Simple Traversal of User Datagram Protocol (UDP) through Network Address Translators），是一种技术可以让位于NAT后的设备可以查找自己的公网IP。

STUN技术需要一个位于公网的STUN server，它实现了一个基于client-server的协议（该协议见RFC5389），由客户端主动发起连接，STUN server会通知STUN client它的公网IP以及公网端口。在VOIP场景，STUN client可以将公网IP以SIP消息方式通知到另一端，这样即使这个客户度没有向另一个客户度的发送UDP报文，另一端就可以主动向这个客户端发送UDP报文。

STUN在大多数的NAT网络中（完全圆锥型NAT、受限圆锥型NAT和端口受限圆锥型NAT）是没有问题，但是在对称型NAT中不能使用。对称型NAT中，发送端私网的IP端口号和对端的IP端口号是一一对应的，从私网内发送的报文，即使发送IP端口相同但是目标IP和端口不同，也会在NAT中创建不同的映射。因此上面使用STUN server会失效，因为第一次和STUN server建立连接对应的是一个映射(private_ip, private_port, dst_ip1, dst_ip2)，后续和另外一个客户端通信需要建立新的映射才可以！

TURN是另外一个技术，可以用来解决STUN不能解决的问题，通常在STUN不可用的时候可以使用TURN。

TURN全称Traversal Using Relays around NAT，即使用中继穿透NAT，标准见RFC8656。当两个客户端由于对称型NAT原因不能建立连接可以使用一个TURN作为中继，两个客户端分别和TURN server建立连接，TURN server返回它自己的IP和端口给两个客户端，TURN server作为中继，使用UDP协议给两个客户端直接转发报文。

由于TURN会转发报文，会占用服务器带宽，代价会比较大，而且还会引入延迟，因此一般只会在STUN打洞失败的时候才会用。

STUN和TURN介绍完了，最后需要介绍的解决方案是ICE。Interactive Connectivity Establishment，交互式连接建立，它结合了STUN和TURN的优势，去掉了两者的不足。

ICE会同时使用STUN和TURN，它通过这两个技术获得IP地址和端口（被称为candidate），candidate会存在多个，在SIP消息中可以携带多个candidate。接收端收到SIP消息后，会对这些candidate分别做连接检查。检查通过STUN报文发送，可以检查这个地址是否可以工作。

SIP 消息有两类：SIP请求（Request）和SIP响应（Response）。

SIP请求消息（方法Method）	SIP操作
INVITE	会话邀请
ACK	确认会话邀请
CANCEL	取消会话邀请
BYE	结束会话
REGISTER	注册
OPTIONS	查询服务器能力

信令

WebRTC 规范包含用于与 ICE（互联网连接建立）服务器通信的 API，但信令组件并不属于该组件。需要发出信号才能让两个对等网络共享它们之间的连接方式。这通常可以通过基于 HTTP 的常规 Web API（即 REST 服务或其他 RPC 机制）解决，在此过程中，网络应用可在发起对等连接之前中继必要的信息。

以下代码段展示了如何使用虚构信号服务异步发送和接收消息。必要时，本指南的其余示例将使用该方法。

// Set up an asynchronous communication channel that will be
// used during the peer connection setup
const signalingChannel = new SignalingChannel(remoteClientId);
signalingChannel.addEventListener('message', message => {
    // New message from remote client received
});

// Send an asynchronous message to the remote client
signalingChannel.send('Hello!');

信令可以通过许多不同的方式实现，WebRTC 规范不偏好任何特定的解决方案。(前端程序员,可以使用nodejs,websocket技术实现)

启动对等连接

每个对等连接都由一个 RTCPeerConnection 对象处理。此类的构造函数接受单个 RTCConfiguration 对象作为其参数。此对象定义对等连接的设置方式，应包含关于要使用的 ICE 服务器的信息。

每个对等连接都由一个RTCPeerconnection对象处理。此类的构造函数将单个RTCConfiguration对象作为其参数。此对象定义了对等连接的设置方式，并应包含有关要使用的ICE服务器的信息。

一旦创建了RTCPeerConnection连接，我们需要创建SDP提供或应答，这取决于我们是主叫对等体还是接收对等体。一旦创建了SDP提供或应答，就必须通过不同的信道将其发送到远程对等端。将SDP对象传递给远程对等方称为信令，不在Web RTC规范的范围内。

为了从调用端启动对等连接设置，我们创建了一个RTCPeerconnection对象，然后调用createOffer()来创建一个RTCSessionDescription对象。使用setLocalDescription()将此会话描述设置为本地描述，然后通过我们的信令信道发送到接收方。我们还为我们的信号通道设置了一个监听器，以便在从接收端接收到对我们提供的会话描述的回答时使用。

async function makeCall() {
    const configuration = {'iceServers': [{'urls': 'stun:stun.l.google.com:19302'}]}
    const peerConnection = new RTCPeerConnection(configuration);
    signalingChannel.addEventListener('message', async message => {
        if (message.answer) {
            const remoteDesc = new RTCSessionDescription(message.answer);
            await peerConnection.setRemoteDescription(remoteDesc);
        }
    });
    const offer = await peerConnection.createOffer();
    await peerConnection.setLocalDescription(offer);
    signalingChannel.send({'offer': offer});
}

在接收端，我们会等待传入的回应，然后再创建 RTCPeerConnection 实例。完成后，我们使用 setRemoteDescription() 设置收到的回应。接下来，我们调用 createAnswer() 为收到的优惠创建答案。系统会使用 setLocalDescription() 将此答案设置为本地说明，然后通过我们的信令服务器将其发送至发起调用的一方。

const peerConnection = new RTCPeerConnection(configuration);
signalingChannel.addEventListener('message', async message => {
    if (message.offer) {
        peerConnection.setRemoteDescription(new RTCSessionDescription(message.offer));
        const answer = await peerConnection.createAnswer();
        await peerConnection.setLocalDescription(answer);
        signalingChannel.send({'answer': answer});
    }
});

两个对等方同时设置了本地和远程会话说明之后，他们就会了解远程对等方的功能。这并不意味着对等设备之间的连接已准备就绪。为此，我们需要在每个对等端收集 ICE 候选项，并通过信令通道传输给另一个对等方。

ICE 候选字词

两个对等方必须用 WebRTC 交换连接信息，然后才能使用 WebRTC 进行通信。由于网络条件可能因多种因素而发生变化，因此通常使用外部服务来发现连接到对等网络的潜在候选对象。此服务称为 ICE，使用的是 STUN 或 TURN 服务器。STUN 代表用于 NAT 的会话遍历实用程序，通常在大多数 WebRTC 应用中间接使用。

TURN（Traversal using Relay NAT）是一种整合了 STUN 协议的更高级解决方案，大多数基于 WebRTC 的商业服务都使用 TURN 服务器在对等方之间建立连接。WebRTC API 直接支持 STUN 和 TURN，在更完整的术语“互联网连接建立”下收集。创建 WebRTC 连接时，我们通常会在 RTCPeerConnection 对象的配置中提供一个或多个 ICE 服务器。

Trickle ICE

创建 RTCPeerConnection 对象后，底层框架会使用提供的 ICE 服务器收集连接建立的候选对象（ICE 候选对象）。RTCPeerConnection 上的事件 icegatheringstatechange 会指示 ICE 收集的状态为（new、gathering 或 complete）。

虽然对等设备可以等待 ICE 收集完成，但通常要高效地使用“滚动冰”技术，并在发现每个 ICE 候选设备后将其传输到远程对等设备。这将大大缩短对等连接的设置时间，并允许视频通话以更低的延迟开始。

要收集 ICE 候选对象，只需为 icecandidate 事件添加监听器即可。针对该监听器发出的 RTCPeerConnectionIceEvent 将包含 candidate 属性，该属性表示应发送到远程对等端的新候选音频（请参阅信号）。

// Listen for local ICE candidates on the local RTCPeerConnection
peerConnection.addEventListener('icecandidate', event => {
    if (event.candidate) {
        signalingChannel.send({'new-ice-candidate': event.candidate});
    }
});

// Listen for remote ICE candidates and add them to the local RTCPeerConnection
signalingChannel.addEventListener('message', async message => {
    if (message.iceCandidate) {
        try {
            await peerConnection.addIceCandidate(message.iceCandidate);
        } catch (e) {
            console.error('Error adding received ice candidate', e);
        }
    }
});

已建立连接

收到 ICE 候选对象后，我们的对等连接状态最终会变为已连接状态。为了检测这一点，我们在 RTCPeerConnection 中添加一个监听器，用于监听 connectionstatechange 事件。

// Listen for connectionstatechange on the local RTCPeerConnection
peerConnection.addEventListener('connectionstatechange', event => {
    if (peerConnection.connectionState === 'connected') {
        // Peers connected!
    }
});

RTCPeerConnection API 文档

远程数据流使用入门

RTCPeerConnection 连接到远程对等设备后，就可以在它们之间流式传输音频和视频。此时，我们会将从 getUserMedia() 收到的数据流连接到 RTCPeerConnection。媒体流包含至少一个媒体轨道，当我们想将媒体传输到远程对等设备时，它们会分别添加到 RTCPeerConnection 中。

const localStream = await getUserMedia({vide: true, audio: true});
const peerConnection = new RTCPeerConnection(iceConfig);
localStream.getTracks().forEach(track => {
    peerConnection.addTrack(track, localStream);
});

轨道可以在连接到远程对等方之前添加到 RTCPeerConnection，因此最好尽早执行此设置，而不是等待连接完成。

添加远程轨道

为了接收由另一个对等方添加的远程轨道，我们会在本地 RTCPeerConnection 上注册一个监听器，用于监听 track 事件。RTCTrackEvent 包含一个 MediaStream 对象数组，这些对象与对等项的相应本地数据流具有相同的 MediaStream.id 值。在我们的示例中，每个轨道仅与单个数据流相关联。

请注意，尽管 MediaStream ID 在对等端的两端均匹配，但 MediaStreamTrack ID 通常并非如此。

const remoteVideo = document.querySelector('#remoteVideo');

peerConnection.addEventListener('track', async (event) => {
    const [remoteStream] = event.streams;
    remoteVideo.srcObject = remoteStream;
});

数据通道

WebRTC 标准还涵盖用于通过 RTCPeerConnection 发送任意数据的 API。可通过对 RTCPeerConnection 对象调用 createDataChannel() 来完成此操作，该方法会返回 RTCDataChannel 对象。

const peerConnection = new RTCPeerConnection(configuration);
const dataChannel = peerConnection.createDataChannel();

远程对等端可以通过监听 RTCPeerConnection 对象的 datachannel 事件来接收数据通道。收到的事件是 RTCDataChannelEvent 类型，包含一个 channel 属性，该属性表示在对等方之间连接的 RTCDataChannel。

const peerConnection = new RTCPeerConnection(configuration);
peerConnection.addEventListener('datachannel', event => {
    const dataChannel = event.channel;
});

打开和关闭事件

在使用数据通道发送数据之前，客户端需要等到数据通道打开后才能使用它。具体方法是监听 open 事件。同样，当任意一侧关闭频道时，也会发生 close 事件。

const messageBox = document.querySelector('#messageBox');
const sendButton = document.querySelector('#sendButton');
const peerConnection = new RTCPeerConnection(configuration);
const dataChannel = peerConnection.createDataChannel();

// Enable textarea and button when opened
dataChannel.addEventListener('open', event => {
    messageBox.disabled = false;
    messageBox.focus();
    sendButton.disabled = false;
});

// Disable input when closed
dataChannel.addEventListener('close', event => {
    messageBox.disabled = false;
    sendButton.disabled = false;
});

信息

如需在 RTCDataChannel 上发送消息，请使用要发送的数据调用 send() 函数。此函数的 data 参数可以是字符串、Blob、ArrayBuffer 或 ArrayBufferView。

const messageBox = document.querySelector('#messageBox');
const sendButton = document.querySelector('#sendButton');

// Send a simple text message when we click the button
sendButton.addEventListener('click', event => {
    const message = messageBox.textContent;
    dataChannel.send(message);
})

远程对等端将通过监听 message 事件来接收 RTCDataChannel 上发送的消息。

const incomingMessages = document.querySelector('#incomingMessages');

const peerConnection = new RTCPeerConnection(configuration);
const dataChannel = peerConnection.createDataChannel();

// Append new messages to the box of incoming messages
dataChannel.addEventListener('message', event => {
    const message = event.data;
    incomingMessages.textContent += message + '\n';
});

TURN 服务器

对于大多数 WebRTC 应用，服务器在服务器之间中继流量时需要使用服务器，因为客户端之间通常无法建立直接套接字（除非它们位于同一个本地网络中）。解决此问题的常见方法是使用 TURN 服务器。该术语代表围绕 NAT 的遍历使用，是一种用于中继网络流量的协议。

目前，TURN 服务器有多种选择，既可作为自托管应用（例如开源 COTURN 项目），也可作为云端服务使用。

拥有可在线使用的 TURN 服务器后，您只需要正确的 RTCConfiguration 供客户端应用使用。以下代码段展示了 RTCPeerConnection 的示例配置，其中 TURN 服务器的主机名为 my-turn-server.mycompany.com，端口为 19403。配置对象还支持使用 username 和 credentials 属性来保护对服务器的访问。连接到 TURN 服务器时，必须执行这些操作。

const iceConfiguration = {
    iceServers: [
        {
            urls: 'turn:my-turn-server.mycompany.com:19403',
            username: 'optional-username',
            credentials: 'auth-token'
        }
    ]
}

const peerConnection = new RTCPeerConnection(iceConfiguration);

测试 WebRTC 应用

为 WebRTC 应用编写自动化测试时，可以对浏览器启用一些有用的配置，以便更轻松地进行开发和测试。

Chrome

在 Chrome 上运行自动化测试时，以下参数在启动时非常有用：

• --allow-file-access-from-files - 允许访问 file:// 网址的 API
• --disable-translate - 停用翻译弹出窗口
• --use-fake-ui-for-media-stream - 提供虚假媒体流。在 CI 服务器上运行时非常有用。
• --use-file-for-fake-audio-capture= - 提供用于捕获音频的文件。
• --use-file-for-fake-video-capture= - 提供在捕获视频时使用的文件。
• --headless - 在无头模式下运行。在 CI 服务器上运行时非常有用。
• --mute-audio - 将音频输出静音。

Firefox

在 Firefox 上运行自动化测试时，您需要提供一组偏好设置键，这些键将用于已启动的实例。以下是用于 WebRTC 自动化测试示例的配置：

"prefs": {
    "browser.cache.disk.enable": false,
    "browser.cache.disk.capacity": 0,
    "browser.cache.disk.smart_size.enabled": false,
    "browser.cache.disk.smart_size.first_run": false,
    "browser.sessionstore.resume_from_crash": false,
    "browser.startup.page": 0,
    "media.navigator.streams.fake": true,
    "media.navigator.permission.disabled": true,
    "device.storage.enabled": false,
    "media.gstreamer.enabled": false,
    "browser.startup.homepage": "about:blank",
    "browser.startup.firstrunSkipsHomepage": false,
    "extensions.update.enabled": false,
    "app.update.enabled": false,
    "network.http.use-cache": false,
    "browser.shell.checkDefaultBrowser": false
}

统一计划 SDP 格式 - 过渡计划

SDP 描述了媒体会话，网络信息、安全特性、传输策略等，图中的每一个 SDP 属性都在不同的应用场景下发挥着不同的作用，不可小觑。

接下来，我们进一步给出 SDP 的官方定义：SDP(Session Description Protocol) 是一种会话描述协议，基于文本，其本身并不属于传输协议，需要依赖其它的传输协议（比如 SIP 和 HTTP）来交换必要的媒体信息，用于两个会话实体之间的媒体协商。

WebRTC 使用 Offer-Answer 模型交换 SDP，Offer 中有 SDP，Answer 中也有。例如 Alice 和 Bob 通过 WebRTC 通信：

Google 计划在未来几个季度将 Chrome 的 WebRTC 实现从当前的 SDP 格式（称为“Plan B”）过渡到符合标准的格式（“Unified Plan”，并草拟 ietf-rtcweb-jsep）。

该计划包含 5 个阶段，且需要使用一个瞬时 API 功能。

谁会受到影响

在单个 ConnectionConnection 上使用多个音轨或多个视频轨道的用户必须在统一方案下测试其产品，并相应地做出调整。如果调用从非 Chrome 端点发起并由 Chrome 回复，则必须更改优惠形式。进行详细 SDP 解析并关注 msid 属性的人员必须检查其解析代码是否选择了新格式 (a=msid)。是否需要更改以及应用需要如何更改将取决于应用。我们认为，几乎每个按 RTCPeerConnection 使用单个音频轨道和单个视频轨道的应用都不会受到该变更的影响。

API 功能

我们即将为 RTCPeerConnection 的 RTCConfiguration 添加一项新功能：

enum SdpSemantics {
  "plan-b",
  "unified-plan"
};


partial dictionary RTCConfiguration {
   SdpSemantics sdpSemantics;
}

RTCConfiguration 可传递给 RTCPeerConnection 的构造函数，构造的所有优惠和答案都采用统一计划格式。调用 setLocalDescription 和 setRemoteDescription 也会要求 SDP 采用统一计划格式；如果 SDP 采用旧版 Chrome 格式，则系统会忽略除第一个音轨和第一个视频轨道之外的所有音频。

此外，还有一个命令行标记（在 Chrome M71 及更高版本中为 -enable-features=RTCUnifiedPlanByDefault，在较低版本中为 –enable-blink-features=RTCUnifiedPlanByDefault），可用于将此标志的默认值设置为“unified-plan”。

阶段

第 1 阶段：实施统一计划

在此阶段，统一计划是在自 M65 开始推出的一个实验标志后面开发的。在第 2 阶段之前，最明智的做法是使用“–enable-blink-features=RTCUnifiedPlan”使用 Chrome Canary 版进行测试。

第 2 阶段：全面推出 API 功能

在 M69（2018 年 8 月 Beta 版，2018 年 9 月稳定版）中发布

在此阶段，sdpSemantics 标志的默认值为“plan-b”。在第 2 阶段中，具有依赖于 SDP 格式的实现的用户应运行测试，以查看其在应用使用统一计划时能否正常工作。对于支持 Firefox 的应用，我们希望这是非常简单的做法：就像使用 Firefox 一样。

sdpSemantics 标志的默认值可在“chrome://flags”中更改；查找“WebRTC：默认使用统一计划 SDP 语义”功能。

第 3 阶段：切换默认设置

改用 M72（Beta 版，2018 年 12 月，稳定，2019 年 1 月）这一天。

在此阶段，我们将 sdpSemantics 标志的默认值更改为“unified-plan”。发现应用需要更多时间来将 sdpSemantics 标志显式设置为“plan-b”才能恢复之前的行为。

第 4 阶段：抛出“Plan B”（计划 B）

在此阶段，将 sdpSemantics 标志设置为“plan-b”会导致抛出异常。从 M93 开始，它已在 Canary 中抛出异常。从 M96 开始，所有稳定版（包括稳定版）都会抛出异常。

在此阶段，我们提供了弃用试用，允许在未出现异常的情况下使用方案 B，但试用已于 2022 年 5 月 25 日停止运行。

第 5 阶段：从 Chromium 中移除“方案 B”

试用期结束后，方案 B 将从 Chrome 中移除。此时，sdpSemantics 标志会被移除。尝试将其设置为“plan-b”不会抛出异常，但不会再有任何效果。

计划 B 仍然适用于特殊标记或特殊 build，但完整的代码移除过程将于 2022 年下半年完成。

第 6 阶段：弃用并移除 WebRTC 的“方案 B”

方案 B 在 WebRTC 中已标记为已弃用，但仍可用。移除操作应该会在 2023 年生效。

针对统一计划准备应用

如需详细了解方案 B 和统一方案的差异，以及您的应用可能需要如何更新以准备统一方案，请参阅“统一方案”过渡指南 (JavaScript)

对于原生 (C++) 应用，请参阅“将您的原生/移动应用迁移到统一方案”一文