探索 WebRTC 开发（5）：WebRTC 会话的生命周期

想要学习和提升音视频技术的朋友，快来加入我们的【音视频技术社群】，加入后你就能：

• 1）下载 30+ 个开箱即用的「音视频及渲染 Demo 源代码」
• 2）下载包含 500+ 知识条目的完整版「音视频知识图谱」
• 3）下载包含 200+ 题目的完整版「音视频面试题集锦」
• 4）技术和职业发展咨询 100% 得到回答
• 5）获得简历优化建议和大厂内推

现在加入，送你一张 20 元优惠券：点击领取优惠券

微信扫码也可领取优惠券

---

WebRTC 让你能够在浏览器应用中实现点对点的任意数据、音频或视频通信——或这些的任意组合。在本文中，我们将了解 WebRTC 会话的生命周期，从建立连接一直到在不需要时关闭连接。

本文不会深入介绍建立和处理 WebRTC 连接的实际 API 细节；它总体上回顾了这个过程，并解释了为什么需要每个步骤。有关实际示例和代码的逐步解释，请参阅信令和视频通话。

注意： 此页面目前仍在建设中，部分内容将随着 WebRTC 指南材料的完善而移动到其他页面。请原谅我们的尘土！

建立连接

互联网是巨大的。真的很大。多年前，聪明的人们看到了它的规模、增长速度以及 32 位 IP 地址系统的局限性，意识到在耗尽可用地址之前必须采取行动，因此他们开始设计新的 64 位寻址系统。但后来他们意识到，完成过渡所需的时间将比 32 位地址的使用寿命更长，所以其他聪明的人想出了一个办法，让多台计算机共享同一个 32 位 IP 地址。网络地址转换（NAT）是一个标准，通过处理局域网内设备的入站和出站数据路由，支持这种地址共享，所有这些设备都共享一个广域网（全球）IP 地址。

对于用户来说，问题在于互联网上的每台计算机不再一定拥有唯一的 IP 地址，事实上，当设备从一个网络移动到另一个网络时，或者当其网络的地址被 NAT 和/或 DHCP 改变时，设备的 IP 地址可能会改变。对于试图进行点对点网络通信的开发者来说，这带来了一个难题：如果没有每个用户设备的唯一标识符，就不可能瞬间自动知道如何连接到互联网上的特定设备。即使你知道你想和谁通话，也不一定知道如何联系到他们，甚至不知道他们的地址是什么。

这就像试图通过在邮件上只写 “Michelle” 并将其放入邮箱来给你的朋友 Michelle 寄包裹，而你不知道她的地址。你需要查找她的地址并将其写在包裹上，否则她最终会想知道你为什么又忘了她的生日。

这就是信令的作用。

信令

信令是在两个设备之间发送控制信息的过程，用于确定通信协议、通道、媒体编解码器和格式以及数据传输所需的方法以及任何所需的路由信息。关于 WebRTC 信令过程，最重要的一点是：它在规范中没有定义。

你可能会奇怪，为什么建立 WebRTC 连接的关键步骤在规范中没有定义？答案很简单：由于两个设备无法直接联系对方，而且规范无法预测 WebRTC 的每种可能用例，因此让开发者选择合适的网络技术和消息传递协议更有意义。

特别是，如果开发者已经有了一种方法来连接两个设备，那么要求他们为了 WebRTC 而使用规范定义的另一种方法是没有意义的。由于 WebRTC 并非孤立存在，很可能还有其他连接在起作用，因此如果可以使用现有的信令通道，则避免添加额外的连接通道是有道理的。

为了交换信令信息，你可以选择通过 WebSocket 连接来回发送 JSON 对象，或者通过适当的通道使用 XMPP 或 SIP，或者通过 HTTPS 使用 fetch() 并进行轮询，或者使用任何其他技术组合。你甚至可以将电子邮件作为信令通道。

还值得一提的是，执行信令的通道甚至不需要通过网络。一个对等方可以输出一个数据对象，该对象可以被打印出来，物理携带（步行或通过信鸽）到另一个设备，输入到该设备中，然后该设备输出响应，再以同样的方式返回，直到 WebRTC 对等连接打开。这将是高延迟的，但这是可行的。

信令期间交换的信息

在信令过程中需要交换三种基本信息：

• 用于设置、打开和关闭通信通道以及处理错误的控制消息。
• 设置连接所需的信息：对等方能够相互通信所需的 IP 地址和端口信息。
• 媒体功能协商：对等方能理解哪些编解码器和媒体数据格式？在 WebRTC 会话开始之前，这些需要达成一致。

只有在信令成功完成后，真正的打开 WebRTC 对等连接的过程才能开始。

值得注意的是，信令服务器实际上不需要理解或对通过它交换的数据做任何处理。信令服务器本质上是一个中继：一个共同点，双方都知道他们的信令数据可以通过它传输。服务器不需要以任何方式对此信息做出反应。

信令过程

为了使 WebRTC 会话成为可能，有一系列步骤需要完成：

1. 每个对等方创建一个 RTCPeerConnection 对象，表示他们在 WebRTC 会话中的端点。
2. 每个对等方建立一个 icecandidate 事件的处理程序，该处理程序通过信令通道将这些候选发送给另一个对等方。
3. 每个对等方建立一个 track 事件的处理程序，当远程对等方将轨道添加到流中时会收到该事件。此代码应将轨道连接到其消费者，例如 <video> 元素。
4. 呼叫方创建并与接收对等方共享一个唯一的标识符或令牌，以便信令服务器上的代码能够识别他们之间的通话。此标识符的具体内容和形式由你决定。
5. 每个对等方连接到约定的信令服务器，例如他们都知道如何交换消息的 WebSocket 服务器。
6. 每个对等方告知信令服务器他们希望加入同一个 WebRTC 会话（通过第 4 步建立的令牌识别）。
7. 描述、候选等 —— 更多内容即将呈现

ICE 重启

有时，在 WebRTC 会话的生命周期中，网络条件会发生变化。例如，用户之一可能会从蜂窝网络切换到 Wi-Fi 网络，或者网络可能会变得拥塞。当这种情况发生时，ICE 代理可能会选择执行 ICE 重启。这是一个重新协商网络连接的过程，与初始 ICE 协商完全相同，有一个例外：媒体继续通过原始网络连接传输，直到新的连接建立并运行。然后媒体切换到新的网络连接，旧的连接将关闭。

注意： 不同的浏览器在不同的条件下支持 ICE 重启。例如，并非所有浏览器都会因网络拥塞而执行 ICE 重启。

如果你需要以某种方式更改连接的配置（例如，切换到不同的 ICE 服务器集），你可以在重启 ICE 之前通过调用 RTCPeerConnection.setConfiguration() 并传入更新后的配置对象来进行更改。

要显式触发 ICE 重启，通过调用 RTCPeerConnection.createOffer() 并将 iceRestart 选项设置为 true 来启动重新协商过程。然后像平常一样处理连接过程。这将为 ICE 用户名片段（ufrag）和密码生成新值，这些值将被重新协商过程和结果连接使用。

连接的回答方在检测到 ICE ufrag 和 ICE 密码的新值时将自动开始 ICE 重启。

---

本文转自微信公众号 关键帧Keyframe，推荐您关注来获取音视频、AI 领域的最新技术和产品信息：

微信扫码关注我们

你还可以加入我们的微信群和更多同行朋友来交流和讨论：

微信扫码进群