问题描述
我们正在使用提供的 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 服务器列表，但根据我们可能会提供不同列表的行为。
感谢您的帮助
解决方法
但是 RTCPeerConnection 如何选择使用的服务器？
RTCPeerConnection 不选择服务器，而是选择一对 ICE 候选对象。通过联系服务器生成 ICE 候选对象。
它是否会尝试第一个，如果失败则尝试第二个直到成功？
它联系他们所有人（这个过程称为聚集）。您的 WebRTC 实施可能在建立连接后停止收集。
所有服务器都应该启动并运行还是连接能够跳过无法访问的服务器？
服务器宕机是可以的。 Trickle ICE 允许在所有连接检查都不起作用的情况下继续进行连接检查。
如果第一台服务器能够结束协商，它还会尝试与其余服务器吗？
两个 WebRTC 代理不通过 STUN 服务器进行通信，这个问题有一点细微差别。在 WebRTC for the Curious 的 connectivity 章节中，查看 ICE 如何完成步骤。
它是否只是改变了候选人名单？
是的！对于每个 STUN 服务器，您可能有另一个候选服务器。这取决于您的 NAT 的行为。您可能使用只提供一个映射的 NAT 配置。不太可能，但仍有可能！