iOS ice 连接状态上的 WebRTC 卡住答案

【问题标题】：WebRTC on iOS ice connection state stuckiOS ice 连接状态上的 WebRTC 卡住
【发布时间】：2017-08-22 13:41:51
【问题描述】：

我正在开发一个 iOS 应用程序，使用 WebRTC 与 RTCDataChannel 进行点对点数据通信。当两个设备都在同一个 wifi 网络上时，我已经设法让一切正常，但是当我将 1 放在移动网络上时，连接似乎停止了，我不知道出了什么问题。查看来自不同运行的日志，直到它停止为止，一切都是相同的。我不确定此时该怎么做，因为没有错误。我曾发誓这是可行的，但是自从我在本地网络之外进行测试以来已经有很长时间了。这是我的日志输出示例，有什么想法我可能做错了吗？

设备 A

20:07:47.653  Sending SDP offer
20:07:47.653  ICE gathering changed 1
20:07:48.067  ICE gathering changed 2
20:07:48.068  Sending ice: data:0:candidate:3022624816 1 udp 2122260223 192.168.1.4 54049 typ host generation 0
20:07:48.071  Sending ice: data:0:candidate:4205470912 1 tcp 1518280447 192.168.1.4 51226 typ host tcptype passive generation 0
20:07:48.073  Sending ice: data:0:candidate:494278629 1 udp 1686052607 14.---.---.208 54049 typ srflx raddr 192.168.1.4 rport 54049 generation 0
20:08:09.448  Answer from NxblUpoB1F7q
20:08:09.452  SIGNAL STATE CHANGE 0
20:08:09.454  ICE connection changed 1
20:08:09.986  ICE candidate was added 1
20:08:10.335  ICE candidate was added 1
20:08:10.338  ICE candidate was added 1
20:08:10.340  ICE candidate was added 1
20:08:10.342  ICE candidate was added 1
20:08:10.345  ICE candidate was added 1
---- When not on the same network things stop here ----
20:08:10.638  ICE connection changed 2
20:08:10.639  ICE connection changed 3
20:08:10.642  Channel did change state 1
20:08:10.644  Connection active

设备 B

20:08:07.753 Offer from AJcoXH6EtM3etg==
20:08:07.843 SIGNAL STATE CHANGE 3
20:08:07.848 SIGNAL STATE CHANGE 0
20:08:07.851 Sending SDP answer
20:08:07.851 ICE gathering changed 1
20:08:08.245 ICE connection changed 1
20:08:08.245 ICE candidate was added 1
20:08:08.247 ICE candidate was added 1
20:08:08.249 ICE candidate was added 1
20:08:08.378 ICE gathering changed 2
20:08:08.378 Sending ice candidate data:0:candidate:211156821 1 udp 2122260223 192.168.1.5 64361 typ host generation 0
20:08:08.380 Sending ice: data:0:candidate:3923309006 1 udp 2122194687 10.---.---.220 50007 typ host generation 0
20:08:08.381 Sending ice: data:0:candidate:1108738981 1 tcp 1518280447 192.168.1.5 58785 typ host tcptype passive generation 0
20:08:08.383 Sending ice: data:0:candidate:2807762238 1 tcp 1518214911 10.---.---.220 58786 typ host tcptype passive generation 0
20:08:08.384 Sending ice: data:0:candidate:1754331002 1 udp 1685987071 1.---.---.24 29841 typ srflx raddr 10.165.91.220 rport 50007 generation 0
20:08:08.385  Sending ice: data:0:candidate:2781507712 1 udp 1686052607 14.203.230.208 64361 typ srflx raddr 192.168.1.5 rport 64361 generation 0
---- When not on the same network things stop here ----
20:08:09.428 ICE connection changed 2
20:08:09.443 Opened data channel ordered 1 reliable 1
20:08:09.445 Channel did change state 1
20:08:09.446 RTC Connection did change state 3
20:08:09.447  Connection active

【问题讨论】：

刚刚在我的 wifi 网络上做了一个快速测试，我只发送 srflx ice 候选人。这样做会导致设备 A 上的 ice 连接状态更改为失败，而设备 B 运行相同。仅发送主机类型的候选冰会创建一个工作连接。不确定这是否有帮助
您在使用 STUN 和 TURN 服务器吗？，如果对等点不在同一个网络上，您将需要一个 stun 服务器来建立连接（srflx ice 候选者是使用 stun 服务器的候选者）。此外，如果两个对等点都在对称 nat 之后，您将需要一个转接服务器来中继连接（中继冰候选人是使用转接服务器的候选人）。
我只是在使用 STUN 服务器，我认为这已经足够了，因为它以前可以工作。我现在添加了一个 TURN 服务器，它让它再次工作。我想我需要对其他仅限 STUN 的服务进行更多测试，看看它们是否出现同样的问题
我遇到同样的问题有什么解决办法吗？
现在我刚刚使用 TURN 离开了它。我不知道 STUN 是不可能工作还是其他问题

标签： ios webrtc

【解决方案1】：

如果您在对称 NAT 后面使用两个客户端，STUN 将无法处理此问题。因此，您应该使用 TURN 在对称 NAT 后面进行通信。

【讨论】：

我猜我的电话公司改变了他们的 NAT 的工作方式，导致它在没有 TURN 的情况下无法通信。由于它最初是有效的，我没有意识到这一点。我发现 webRTC 在告诉你你做错了什么时非常糟糕。