Chrome WebRTC DataChannels: рефлексивные кандидаты на сервер ICE-TCP отсутствуют даже при использовании STUN

Question

Я создаю (еще одну) ручную сигнализацию чата WebRTC через DataChannels (CoffeeScript, извините, ребята из JS). Он отлично работает в локальных соединениях, но не через Интернет за NAT (к сожалению, я не мог попробовать NATless пока).

Я не хочу поддерживать сервер TURN, но я в порядке, если только один узел должен быть общедоступным из Интернета, чтобы настройка работала. Поскольку я единственный, у кого есть доступная машина, мне нужно, чтобы я установил 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-forward to).

• Почему в моих предложениях / ответах не отражен кандидат на рефлексивный сервер TCP?
• Хрому не хватает серверно-рефлексивного обнаружения кандидатов ICE-TCP?
• Можно ли вручную добавить рефлексивного кандидата на сервер с учетом общедоступного IP-адреса, сообщенного сервером STUN?

Answer 1

STUN НЕ МОЖЕТ работать с TCP через NAT,

В RFC об этом говорится в заявлении. Stun предназначен только для работы с UDP, Вот почему SCTP должен быть построен на UDP так что вы можете ходить NATs, (Только Chrome дает внутреннюю опцию TCP).

Вам нужно настроить переадресацию портов на одном из NATs если ты хочешь TCP трафик, чтобы пройти через это, но STUN не поможет тебе.

Извините за плохие новости:(

РЕДАКТИРОВАТЬ: Это просто ограничение STUN, а не SCTP(поэтому Chrome ничего не может с этим поделать, если они хотят). FireFox в любом случае НЕ поддерживает SCTP через TCP. Я не 100% на TURN. RFC, кажется, говорит, что TCP поддерживается только для связи между клиентом и сервером, а не для фактической ретрансляции. Проверьте это, Chrome может работать с TCP через сервер TURN с того, что TR Missner сообщает в нижней части потока.

Если вы хотите использовать TCP с RTCDataConnection, вы МОЖЕТЕ настроить переадресацию портов с обеих сторон.

РЕДАКТИРОВАТЬ 2: Ради истории, я оставляю остальную часть моего ответа нетронутым, но хороший комментарий, сделанный @adamfisk, показал мне некоторые ошибки.

Во-первых, STUN может поддерживать TCP поверх nat в соответствии с новым RFC и с предлагаемыми обновлениями для указанного RFC для DTLS. Все это говорит о том, что Chrome должен по-прежнему поддерживать SCTP через TCP, а Firefox по-прежнему не поддерживает ошибку 891551.

Я также очень сомневаюсь, что MEDIA когда-либо будет поддерживать TCP-соединение, и подозреваю, что для любого TCP-соединения (ретранслированного или нет) будет поддерживаться только SCTP.