Chrome WebRTC DataChannels:即使使用 STUN 也缺少 ICE-TCP 服务器自反候选 [英] Chrome WebRTC DataChannels: ICE-TCP server reflexive candidates missing even with STUN

问题描述

我正在构建(又一个)通过 DataChannels 手动发送 WebRTC 聊天信号(CoffeeScript，抱歉 JS伙计们).它在本地连接中可以正常工作，但不能通过 NAT 后的 Internet 连接(不幸的是，我还不能尝试 NATless).

I'm building (yet another) manual signalling WebRTC chat via DataChannels (CoffeeScript, sorry JS guys). It works fine in local connections, but not over the internet behind a NAT (unfortunately I couldn't try NATless yet).

我不想维护 TURN 服务器，但如果只有一个对等点必须可以从 Internet 公开访问才能使设置工作，我也可以.因为我是唯一一个拥有可访问机器的人，所以我们需要我主持一个 TCP 连接.在 Firefox 中没有报告 TCP 候选，所以我猜 ICE-TCP 尚不支持.

I don't want to maintain a TURN server, but I'm fine if only one peer must be publicly-reachable from the internet for the setup to work. Since I'm the only one with a reachable machine, we need me to host a TCP connection. In Firefox there are no TCP candidates reported so I guess ICE-TCP is not yet supported.

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

On Chrome, looking at the SDP offers/answers, the STUN servers correctly identified both peer's public IPs and added each server reflexive UDP candidate (see line 10 below) but there is no TCP server reflexive candidate, so the connection never succeeds. There is also a TCP candidate included (see line 9 below) but it's just a host candidate.

以下是 SDP 报价示例(我的公共 IP 是 88.88.88.88):

Here's a sample SDP offer (my public IP is 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 转发的默认主机).

I'm sure the internet can reach my machine via NAT and port forwarding is fine (my machine is the default host to NAT-forward to).

• 为什么我的提议/答案中没有报告 TCP 服务器自反候选?
• Chrome 是否缺少服务器自反 ICE-TCP 候选发现?
• 是否可以根据 STUN 服务器报告的公共 IP 手动添加服务器自反候选?

推荐答案

首先，根据 新的 RFC 和提议的 更新表示 DTLS 的 RFC.综上所述，Chrome 应该仍然支持 TCP 上的 SCTP 并且 Firefox 仍然没有根据错误 891551.

First, STUN can support TCP over a NAT in accordance with the new RFC and with the proposed updates for said RFC for DTLS. All this said, Chrome should still support SCTP over TCP and Firefox still does not according to bug 891551.

我也非常怀疑 MEDIA 是否会支持 TCP 连接，并怀疑任何 TCP 连接(中继与否)都将只支持 SCTP.

I also highly doubt that MEDIA will ever support a TCP connection and suspect that only SCTP will be supported for any TCP connection(relayed or not).

[注意:为了历史起见，我保留其余答案不变，但很好 @adamfisk 发表的评论，向我展示了一些勘误表.]

[Note: For history sake, I am keeping the rest of my answer intact but a good comment made by @adamfisk, showed me some errata.]

STUN 不能通过 NAT 使用 TCP.

它的 RFC 在申请声明中说了同样多的话.Stun 仅设计用于 UDP.这就是为什么SCTP 需要建立在UDP 之上，以便您可以绕过NAT.(只有 Chrome 提供了 TCP 的内部选项).

Its RFC says as much in the application statement. Stun is only designed to work with UDP. This is why SCTP needs to be on built on UDP so that you can go around NATs. (Only Chrome gives the internal option of TCP).

如果您希望 TCP 流量通过它，则必须在 NAT 之一上设置端口转发，但 STUN 不会帮助你.

You will have to set up port forwarding on one of the NATs if you want TCP traffic to go through it but STUN will not help you.

对不起，坏消息:(

这只是 STUN 的限制，而不是 SCTP 的限制(因此，如果他们愿意，chrome 对此无能为力).FireFox 无论如何都不支持 TCP 上的 SCTP.我不是 100% 的 TURN.RFC 好像是说只有在客户端和服务器之间的通信中才支持 TCP，不是真正的继电器.看看这个，Chrome 可以通过 TURN 服务器与 TCP 一起工作，正如 TR Missner 在线程底部所说的那样.

This is simply a limitation of STUN, not of SCTP(so chrome could do nothing about it if they wanted to). FireFox does NOT support SCTP over TCP anyways. I am not 100% on TURN. The RFC seems to say that TCP is support only in the communication between the client and the server, not the actual relay. Check this out, Chrome may work with TCP through a TURN server from what T. R. Missner states at the bottom of the thread.

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

You MAY have to have port forwarding set up on both sides if you want to use TCP with an RTCDataConnection.

这篇关于Chrome WebRTC DataChannels:即使使用 STUN 也缺少 ICE-TCP 服务器自反候选的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！