我正在构建（又一个）manual signalling WebRTC chat via DataChannels（CoffeeScript，对不起JS家伙）。它可以在本地连接中正常工作，但不能通过NAT后面的互联网（不幸的是我还无法尝试NAT）。
我不想维护TURN服务器，但如果只有一个对等方必须可以从互联网上公开访问才能使设置正常工作。由于我是唯一一个有可达机器的人，我们需要我主持一个TCP连接。在Firefox中没有报告TCP候选者，所以我想还不支持ICE-TCP。
在Chrome上，查看SDP提供/答案，STUN服务器正确识别了对等体的公共IP并添加了每个服务器自反UDP候选者（见下面的第10行），但没有TCP server reflexive candidate，所以连接从不成功。还包括一个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转发的默认主机）。
答案 0 :(得分：4)
STUN 无法 与TCP NAT合作。
它的RFC在申请声明中说了很多。 Stun仅适用于UDP。这就是SCTP需要在UDP上构建的原因，以便您可以绕过NATs。 （只有Chrome提供TCP）的内部选项。
如果您希望NATs流量通过TCP流量，则必须在其中一个STUN上设置端口转发，但{{1}}无法帮助您。
对不起坏消息:(
编辑：这只是STUN的限制，而不是SCTP的限制（因此如果他们想要，Chrome就无法做任何事情）。无论如何，FireFox都不支持TCP上的SCTP。我不是100％在TURN上。 RFC似乎只说TCP支持客户端和服务器之间的通信，而不是实际的中继。 Check this out，Chrome可以通过TURN服务器使用TCP，这可以从T. R. Missner在线程底部说明。
如果要将TCP与RTCDataConnection一起使用，则可能必须在双方都设置端口转发。
EDIT2：从历史的角度来看，我保留了其余的答案，但是@adamfisk发表了一个很好的评论，向我展示了一些勘误。
首先，STUN可以根据new RFC和建议的updates for said RFC for DTLS支持nat上的TCP。所有这些说，Chrome应该仍然支持TCP上的SCTP和Firefox still does not according to bug 891551。
我也非常怀疑MEDIA是否会支持TCP连接，并怀疑任何TCP连接都只支持SCTP（中继或不中继）。