约30%的情况下Kurento WebRTC连接失败

我花了好几天的时间来寻找一个连接问题，但没有任何运气。我正在尝试与Kurento实现一个相对简单的one2one调用

下面您将看到Kurento的调试日志，其中记录了一个可以建立连接的案例和一个连接失败的案例

如果您需要更多的日志（例如客户机、信令服务器、tcpdump或Kuranto的跟踪日志，请告诉我，我会提供！）

非常感谢任何帮助或新的输入

问题描述：

在大约30%的情况下，无法建立WebRTC连接。不幸的是，当连接可以建立时，我缺少任何类型的模式，当连接不能建立时，它看起来完全是随机的。我在同一个网络中，使用相同的设备，使用相同的TURN服务器，使用相同的信令协议，但在30%的情况下无法建立连接

当我在本地运行应用程序时，它似乎工作得更可靠，几乎100%的时间都可以建立连接（或者甚至100%的时间，我已经测试过很多次了，我迷失了方向）。我使用docker在本地设置基础设施，并在不同的网络中运行不同的容器（TURN、Kuranto、信令），以模拟生产部署

我们在开发和生产环境中经历了相同的行为。在我们的开发环境中，我们完全没有防火墙，所以这似乎不是问题所在

我试图找到问题的原因：

大多数情况下，我一直在比较有效案例和无效案例的日志，但我没有发现它们之间有任何显著的差异，从而指出问题所在

我已经通过TURN服务器（使用Firefox和force_中继标志）和Kurento直接测试了WebRTC连接，但在这两种情况下，连接都会在约30%的情况下失败

我尝试过过滤所有不是中继候选的ICE候选

我已经嗅探了我们的信令服务器（它也控制Kurento）和Kurento之间的通信量，以查看所交换的JSON RPS消息中的任何差异，但它们看起来基本相同

我已经使用这个工具测试了我们的眩晕和转身服务器：我得到了看起来正确的服务器反射和中继候选

我已经嗅到了成功和不成功连接的客户端的流量，但可以发现显著的差异

我简化了Kurento媒体管道（没有录音，没有集线器），但行为是一样的

我使用过不同的浏览器（Chrome、Firefox和本机iOS实现），但行为是相同的

Kurento调试可以建立连接的案例日志：

无法建立连接的情况下的Kurento调试日志：

---

查看您的跟踪，您的工作案例选择候选10，然后选择候选7，非工作案例只选择候选10

kurento_logs_webrtc_working.txt

New candidate pair selected, local: 'candidate:10 1 UDP 335544831 10.10.36.134 50589 typ relay raddr 172.19.0.2 rport 9', remote: 'candidate:3993072200 1 UDP 41885695 10.10.36.134 53894 typ relay', stream_id: '1', component_id: 1
...
New candidate pair selected, local: 'candidate:7 1 UDP 1677722111 10.10.36.131 46842 typ srflx raddr 172.19.0.2 rport 46842', remote: 'candidate:266015763 1 UDP 2122260223 10.10.1.57 55125 typ host', stream_id: '1', component_id: 1

new candidate pair selected, local: 'candidate:10 1 UDP 335544831 10.10.36.134 51280 typ relay raddr 172.19.0.2 rport 9', remote: 'candidate:3993072200 1 UDP 41885695 10.10.36.134 51287 typ relay', stream_id: '1', component_id: 1

kurento\u日志\u webrtc\u NOT\u working.txt

New candidate pair selected, local: 'candidate:10 1 UDP 335544831 10.10.36.134 50589 typ relay raddr 172.19.0.2 rport 9', remote: 'candidate:3993072200 1 UDP 41885695 10.10.36.134 53894 typ relay', stream_id: '1', component_id: 1
...
New candidate pair selected, local: 'candidate:7 1 UDP 1677722111 10.10.36.131 46842 typ srflx raddr 172.19.0.2 rport 46842', remote: 'candidate:266015763 1 UDP 2122260223 10.10.1.57 55125 typ host', stream_id: '1', component_id: 1

new candidate pair selected, local: 'candidate:10 1 UDP 335544831 10.10.36.134 51280 typ relay raddr 172.19.0.2 rport 9', remote: 'candidate:3993072200 1 UDP 41885695 10.10.36.134 51287 typ relay', stream_id: '1', component_id: 1

我的第一个想法是，您正在使用旧的候选者，但端口已更改。更改浏览器可能会更改候选编号，我不希望它们在两次运行之间具有确定性，因此我不得不查看两次

与日志有一个细微的区别-在出现

候选项266015763

后，非工作

IceComponentStateChanged

变为

connecting

。我不知道这是否重要

一般说明：

在过去，当我们遇到两类问题时：

• 客户端我们失去了ICE候选人——一些候选人在我们准备好之前就被发送了，所以我们需要让他们排队。IIRC SDP报价中可能有一些候选人（或答案，抱歉，已经有一段时间了），因此您的听众需要在开始之前做好准备
• 我们发送的是旧的候选者-信号服务器中使用了错误的replay元素向客户端提供候选者，这些元素不再有效

我建议您使用Chrome来帮助。在webrtc内部可以看到ICE候选问题，因为您可以看到状态机遍历其状态。在我们的工作案例中有更多的转换，而不是破碎的案例

为三个ice事件添加客户端侦听器也很有帮助：

this.peer.peerConnection.oniceconnectionstatechange = this.logloglog.bind(this, this.peer.peerConnection);
this.peer.peerConnection.onicegatheringstatechange = this.logloglog.bind(this, this.peer.peerConnection);
this.peer.peerConnection.onsignalingstatechange = this.logloglog.bind(this, this.peer.peerConnection);

这可以让你看到谈判的进展情况，但基本上就是谈判中的情况

最后请注意，这是我在日志部分使用的

/etc/default/kurento媒体服务器
：


# ICE debug logging: uncomment to enable in KMS and in the 3rd-party library 'libnice'
# - Note: This can get very verbose, log size will explode in the long term
#export GST_DEBUG="$GST_DEBUG,kmsiceniceagent:5,kmswebrtcsession:5,webrtcendpoint:4"
export G_MESSAGES_DEBUG="libnice,libnice-stun"
export NICE_DEBUG="$G_MESSAGES_DEBUG"

我不记得它们是否比您使用的更好，但我将把它抛在脑后。
经过几天的调试，几乎发疯，我们终于找到了问题的原因：

我们使用Socket.IO的Swift客户端和Socket.IO的Java Netty Socket.IO服务器实现。客户端（iOS）正在使用长轮询与服务器（Java）通信。事实证明，Netty Socket.IO服务器正在对Swift Socket.IO客户端的长轮询负载进行URL解码，但Swift Socket.IO客户端实际上并没有对其进行URL编码。这意味着服务器上从Swift Socket.IO客户端发送的每个“+”都被替换为“”（一个空格）。为什么这是一个问题？因为客户的SDP报价包含一个ufrag，它可以包含一个加号！因此，如果SDP包含一个“+”，它将在服务器上被替换为一个空格，这会导致击晕失败，因为无法验证消息的完整性。
非常感谢您阅读了所有这些内容。事实上，我们今天找到了约三分之一连接失败的原因。我会很快发布答案。你发布答案了吗？很荣幸能找到答案。我做了一个变通，在失败时重试，这可能需要一段时间