客户端-服务器WebRTC应用程序是否需要使用ICE？

Question

我有一个运行在公共IP地址上的WebRTC MCU(kurento)，为一些只发送或只接收音频的客户提供服务。因此，每个客户端都直接连接到具有公共IP地址的MCU（而不是彼此连接）。

问题1：是否仍需要使用STUN和TURN进行NAT遍历？如果需要，为什么？ 问题2：浏览器中是否存在任何WebRTC黑客，可以省去STUN和TURN的需求？

我的观点是：大多数客户端-服务器架构与NAT后面的客户端没有任何困难。这里WebRTC有什么区别呢？

- Geak RN

Answer 1

是的，ICE技术对于WebRTC来说绝对必要。

问1：是否仍需要使用STUN和TURN进行NAT遍历? 如果是，为什么？

对于您的场景，您不需要使用STUN或TURN。让我解释一下为什么。

在私有网络中的每个客户端都受到某种具有公共IP地址的NAT的保护。外部世界不知道此客户端的私有IP地址，即使他们知道也无法在不知道公共IP地址的情况下与客户端连接。STUN服务器用于收集此公共IP地址。

因此，如果服务器想要启动连接，则需要客户端发送其NAT的公共IP。客户端将使用STUN服务器了解其公共IP并将其发送到服务器。但是，如果客户端启动连接，则无需知道NAT的公共IP。客户端可以向公共服务器发送数据包以发起连接。服务器可以从客户端的数据包中获取客户端的公共IP，然后它们可以连接。因此，不需要STUN。

在这种情况下，您的服务器扮演TURN的角色。因此，您不需要TURN服务器。

问2：是否存在可使浏览器中的WebRTC免除STUN和TURN的方法？

没有什么“hack”。根据不同的场景，会使用TURN/STUN。对于您的场景，您不需要。如果您想要进行客户端之间的连接，则需要STUN服务器。

- Tahlil

---

我应该如何实现客户端以启动webrtc连接？看起来我们无法控制谁在webrtc中启动！ - Geak RN

你编写应用程序，你决定谁发送报价。 - Dr. Alex Gouaillard

ICE使用提供和回答模型。发送提供的一端是发起连接的一方。发送提供意味着将会话描述（实际上是IP信息）发送到另一端。当另一端接收到后，它会生成自己的会话描述，称为回答，并将其发送回另一端。之后开始进行ICE检查。因此，您需要访问客户端和服务器端代码。从客户端代码中，您需要向服务器发送提供，并从服务器端代码中接收此提供并生成并将回答发送回客户端。 - Tahlil

我也对更深入的示例感兴趣，因为我所做的测试总是导致客户端发送STUN请求，即使服务器试图表明它可以直接连接。这可能足以成为另一个问题，因为我没有使用任何现有的服务器。 - Sami Kuhmonen

当进行客户端服务器通信时，不需要使用ICE！只有当两个端点位于两个不同的私有网络上时才需要使用ICE。但是，如果您仍然使用ICE，则需要为客户端和服务器添加候选项以建立连接。 - Tahlil

Answer 2

• ICE是强制性的
• 但使用任何STUN和TURN服务器都不是强制的。
• 由于您正在连接到公共端口上的服务器，因此您永远不需要使用TURN服务器，但取决于客户端所在的NAT /防火墙类型，您可能需要一个STUN服务器。
• 您无需修改浏览器。应用程序决定是否使用STUN服务器。如果在创建peerconnection对象时将“iceservers”参数传递为空，则浏览器中的ICE UA仅会生成主机（本地）候选者。

- Dr. Alex Gouaillard

---

我应该如何在客户端和服务器上配置RTCPearConnetion，以便我的MCU充当TURN？ - Geak RN

你不需要让你的MCU充当转换器。没有必要使用那么多额外的设备。你的MCU正处于公共地址，因此ICE（或ICE-Lite）就足够了。你的信令服务器可以告诉每个连接到它的客户端去启动握手（即发送一个offer）到你的MCU。 - Dr. Alex Gouaillard