RTCPeerConnection 如何使用 STUN/TURN 服务器阵列？

Question

我们正在使用提供的 STUN/TURN 服务器列表对 Web RTC 的行为进行一些研究。我找不到任何文档，所以我正在做一些测试，但我希望有人能提供清楚的解释。

按照文档 (https://developer.mozilla.org/en-US/docs/Web/API/RTCIceServer/urls)，我们可以提供任意数量的服务器。

• 但是 RTCPeerConnection 是如何选择要使用的服务器的呢？
• 它是否会尝试第一个，如果失败则尝试第二个，直到一个有效？
• 应该所有服务器都启动并运行，还是连接能够跳过无法访问的服务器？
• 如果第一台服务器能够结束协商，它是否仍然尝试与剩余的服务器进行协商？
• 是否只是更改了候选人名单？

为了提供更多上下文，我们有一个使用 Google Stun 服务器 (stun.l.google.com:19302) 的工作 WebRTC 应用程序，但是我们正在我们自己的 STUN 服务器上进行迁移。我们有一个 API 可以返回 STUN 服务器列表以供使用，但是根据行为我们可能会提供不同的列表。

感谢您的帮助

Answer 1

但是 RTCPeerConnection 是如何选择要使用的服务器的呢？

RTCPeerConnection 不会选择服务器，它会选择一对 ICE 候选者。通过联系服务器生成 ICE 候选者。

它会尝试第一个，如果失败则尝试第二个，直到一个成功？

它联系他们所有人（这个过程称为聚集）。您的 WebRTC 实现可能在建立连接时停止收集。

应该所有服务器都启动并运行，还是连接能够跳过无法访问的服务器？

服务器停机是可以的。 Trickle ICE 允许在所有连接检查均不工作时继续进行连接检查。

如果第一台服务器能够结束协商，它是否仍然尝试与剩余的服务器进行协商？

两个 WebRTC 代理不通过 STUN 服务器进行通信，这个问题有一点细微差别。在 WebRTC 的 connectivity 章节中，了解 ICE 如何执行步骤。

它只是改变候选人名单吗？

是的！对于每个 STUN 服务器，您可能有另一个候选人。这取决于您的 NAT 的行为。您可能在只为您提供一个映射的 NAT 配置后面。不太可能，但仍有可能！