Duc*_*ped 5 tcp candidate stun webrtc
我正在通过 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 转发的默认主机）。
首先，根据新的 RFC和针对 DTLS 的所述 RFC的建议更新，STUN 可以通过 NAT 支持 TCP 。综上所述，Chrome 应该仍然支持 TCP 上的 SCTP，而Firefox 仍然没有根据错误 891551。
我也非常怀疑 MEDIA 将永远支持 TCP 连接，并怀疑任何 TCP 连接（中继与否）都只支持 SCTP。
[注意：为了历史起见，我保留了其余答案的完整性，但@adamfisk 发表了一个很好的评论，向我展示了一些勘误表。]
STUN 不能使用TCP超过NAT.
它的RFC在应用程序声明中说了同样多的话。Stun 仅设计用于与UDP. 这就是为什么SCTP需要建立在UDP这样你可以四处走动的原因NATs。（只有 Chrome 提供了 的内部选项TCP）。
NATs如果您希望TCP流量通过它但STUN对您没有帮助，则必须在其中之一上设置端口转发。
关于这些坏消息我很遗憾 ：（
编辑：这只是 STUN 的限制，而不是 SCTP 的限制（因此，如果他们愿意，chrome 对此无能为力）。FireFox 无论如何都不支持 TCP 上的 SCTP。我不是 100% 的 TURN。该RFC似乎是说，TCP是只支持在客户端和服务器，而不是实际的继电器之间的通信。看看这个，Chrome 可以通过 TURN 服务器与 TCP 一起工作，这是 TR Missner 在线程底部声明的。
如果您想将 TCP 与 RTCDataConnection 一起使用，您可能必须在两端都设置端口转发。