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

Posted 2023-04-15

【中文标题】客户端-服务器 WebRTC 应用程序是不是需要 ICE？

【英文标题】：Is ICE Necessary for Client-Server WebRTC Applications?客户端-服务器 WebRTC 应用程序是否需要 ICE？

【发布时间】：2015-11-24 21:21:55

【问题描述】：

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

Q1：是否还需要使用 STUN 和 TURN 进行 NAT 穿越？如果是这样为什么？ Q2：浏览器中的 WebRTC 是否有任何 hack 可以消除 STUN 和 TURN 的需要？

在我看来：大多数客户端-服务器架构对 NAT 后面的客户端没有任何困难。这里与 webrtc 有什么区别？

【参考方案1】：

是的，对于 WebRTC，ICE 是绝对必须的。

Q1：是否还需要使用 STUN 和 TURN 进行 NAT 穿越 ??如果是为什么？？

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

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

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

您的服务器在这种情况下扮演 TURN 的角色。所以你不需要TURN服务器。

Q2：浏览器中的 WebRTC 是否有任何 hack 可以消除 STUN 和 TURN 的需要？

没有破解。根据场景使用 TURN/STUN。对于您不需要的场景。如果您想建立客户端-客户端连接，那么您将需要 STUN 服务器。

【讨论】：

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

您编写应用程序，您决定谁发送报价。

ICE 适用于提供、回答模型。最终发送提议是发起连接的人。一端发送offer是指向另一端发送会话描述，实际上是ip信息。当另一端收到时，它会生成自己的会话描述，称为应答并将其发送给另一端。之后，冰检查开始。因此，您需要同时访问客户端和服务器端代码。您需要从您的客户端代码向服务器发送报价，并从您的服务器端代码接收此报价并生成并将答案发送回客户端。

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

客户端服务器通信不需要ICE！当两个端点驻留在两个不同的专用网络上时，ICE 是必要的。但是，如果您仍然使用 ICE，那么是的，您需要为客户端和服务器添加候选者以建立连接。

【参考方案2】：

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

【讨论】：

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

你不需要你的MCU来充当轮流。不需要所有额外的机器。您的 MCU 位于公共地址上，因此 ICE（或 ICE-Lite）就足够了。您的信令服务器可以告诉连接到它的每个客户端向您的 MCU 发起握手（即发送报价）。