5

我正在通过 DataChannels（CoffeeScript，对不起 JS 家伙）构建（又一个）手动信号 WebRTC 聊天。它在本地连接中工作正常，但不能通过 NAT 后面的互联网（不幸的是我还不能尝试 NATless）。

我不想维护 TURN 服务器，但如果只有一个对等点必须可以从 Internet 公开访问才能使设置正常工作，那我很好。由于我是唯一拥有可访问机器的人，因此我们需要我托管 TCP 连接。在 Firefox 中没有报告 TCP 候选，所以我猜 ICE-TCP 还不支持。

在 Chrome 上，查看 SDP 提供/答案，STUN 服务器正确识别了两个对等方的公共 IP，并添加了每个服务器自反 UDP 候选（见下面的第 10 行），但没有TCP 服务器自反候选，因此连接永远不会成功。还包括一个 TCP 候选（见下面的第 9 行），但它只是一个主机候选。

这是一个示例 SDP 报价（我的公共 IP 是 88.88.88.88）：

01. v=0
02. o=- 7452583715680269460 2 IN IP4 127.0.0.1
03. s=-
04. t=0 0
05. a=msid-semantic: WMS
06. m=application 50816 DTLS/SCTP 5000
07. c=IN IP4 88.88.88.88
08. a=candidate:864190085 1 udp 2122194687 10.10.10.4 50816 typ host generation 0
09. a=candidate:2097250933 1 tcp 1518214911 10.10.10.4 0 typ host generation 0
10. a=candidate:3500406889 1 udp 1685987071 88.88.88.88 50816 typ srflx raddr 10.10.10.4 rport 50816 generation 0
11. a=ice-ufrag:2066nM5kqwFDQMBT
12. a=ice-pwd:thO7oP0H+H1VBHFNfT8SLFiI
13. a=ice-options:google-ice
14. a=fingerprint:sha-256 72:87:BF:AD:03:9C:09:A7:58:0C:3A:DF:.....:B7
15. a=setup:actpass
16. a=mid:data
17. a=sctpmap:5000 webrtc-datachannel 1024

我确信互联网可以通过 NAT 访问我的机器并且端口转发很好（我的机器是 NAT 转发到的默认主机）。

  • 为什么我的报价/答案中没有报告 TCP 服务器自反候选人？
  • Chrome 是否缺少服务器自反 ICE-TCP 候选发现？
  • 给定 STUN 服务器报告的公共 IP，是否可以手动添加服务器自反候选？
4

1 回答 1

5

首先，STUN 可以根据新的 RFC和针对 DTLS 的上述 RFC 的建议更新支持基于 NAT 的 TCP 。综上所述，根据错误 891551 ，Chrome 应该仍然支持 TCP 上的 SCTP，而Firefox 仍然不支持。

我也高度怀疑 MEDIA 是否会支持 TCP 连接，并怀疑任何 TCP 连接（中继或不中继）只支持 SCTP。

[注意：出于历史原因，我将保留我的其余答案不变，但@adamfisk 的一个很好的评论向我展示了一些勘误表。]

原始答案

STUN 不能使用TCP超过NAT.

它的RFC在应用程序声明中说了这么多。Stun 仅适用于UDP. 这就是为什么SCTP需要建立在UDP你可以四处走动的基础上NATs。（只有 Chrome 提供了内部选项TCP）。

NATs如果您希望TCP流量通过它，则必须在其中一个上设置端口转发，但STUN对您没有帮助。

关于这些坏消息我很遗憾 ：（

编辑：这只是 STUN 的限制，而不是 SCTP 的限制（所以如果他们愿意，chrome 无能为力）。FireFox 无论如何都不支持 SCTP over TCP。我不是 100% 的 TURN。RFC似乎说 TCP 仅在客户端和服务器之间的通信中得到支持，而不是实际的中继。看看这个，Chrome 可以通过 TURN 服务器与 TCP 一起工作，TR Missner 在线程底部指出。

如果您想将 TCP 与 RTCDataConnection 一起使用，您可能必须在双方都设置端口转发。

于 2014-05-02T19:32:23.077 回答