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 for the Curious 的连接章节中，了解 ICE 如何完成各个步骤。

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

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