WebRTC 会话的生命周期

互联网非常庞大。真的很大。它非常庞大，以至于多年前，聪明的人们看到了它的庞大规模、快速的增长以及32 位 IP 地址系统的局限性，意识到在我们用完地址之前必须做点什么，因此他们开始设计一个新的 64 位地址系统。但他们意识到完成过渡的时间将比 32 位地址的寿命更长，因此其他聪明的人想出了一个让多台计算机共享同一个 32 位 IP 地址的方法。网络地址转换 (NAT) 是一种标准，通过处理进出 LAN 上设备的入站和出站数据路由来支持这种地址共享，所有这些设备都共享单个 WAN（全局）IP 地址。

对于用户来说，问题在于互联网上的每台单独的计算机不再一定具有唯一的 IP 地址，实际上，每个设备的 IP 地址可能会发生变化，不仅在从一个网络移动到另一个网络时会发生变化，而且在网络的地址被NAT 和/或 DHCP 更改时也会发生变化。对于尝试进行点对点网络的开发人员来说，这带来了一个难题：如果没有每个用户设备的唯一标识符，就不可能立即且自动地知道如何连接到互联网上的特定设备。即使您知道要与谁通话，您也不一定知道如何联系他们，甚至不知道他们的地址是什么。

这就像试图将包裹邮寄给你的朋友 Michelle，并在包裹上贴上“Michelle”标签，然后把它扔进邮箱，而你不知道她的地址。你需要查询她的地址并将其包含在包裹上，否则她会想知道你为什么再次忘记她的生日。

这就是信令的用武之地。

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

您可能想知道，为什么建立 WebRTC 连接过程的某些基本内容被排除在规范之外？答案很简单：由于两个设备无法直接联系，而且规范无法预测 WebRTC 的所有可能的用例，因此让开发人员选择合适的网络技术和消息传递协议更有意义。

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

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

还需要注意的是，用于执行信令的通道甚至不需要通过网络。一个对等体可以输出一个数据对象，该数据对象可以打印出来，物理地携带（步行或通过信鸽）到另一个设备，输入到该设备，然后该设备输出一个响应，并通过步行等方式返回，依此类推，直到 WebRTC 对等连接打开。延迟会非常高，但可以做到。

在信令期间交换的信息

信令期间需要交换三种基本类型的信息

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

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

值得注意的是，信令服务器实际上不需要了解或对对等体在信令期间通过它交换的数据进行任何处理。信令服务器本质上是一个中继：一个双方都知道可以将其信令数据传递到它的公共点。服务器不需要对这些信息做出任何反应。

信令过程

为了能够开始 WebRTC 会话，必须发生一系列事情

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

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

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

要显式触发 ICE 重启，请通过调用 RTCPeerConnection.createOffer() 启动重新协商过程，并指定值为 true 的 iceRestart 选项。然后像往常一样处理连接过程。这将生成 ICE 用户名片段 (ufrag) 和密码的新值，这些值将用于重新协商过程和生成的连接。

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