iceConnectionState: проверка Как исправить

Я использую nodejs для приложения видеовызова, где, если пользователь A и пользователь B находятся в разных сетях, то: - iceConnectionState: «проверка» iceGatheringState: «сбор»

и потоковая передача не исходит от удаленного пользователя, но работает, когда оба находятся в одной сети / Wi-Fi.

iceConnectionState: "проверка" iceGatheringState: "сбор"

iceConnectionState: "завершено"


node.js webrtc videochat
person Nitish Kumar    schedule 15.10.2019    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Вы установили ледовые серверы, особенно сервер поворота (или, по крайней мере, сервер оглушения)? Вы должны передать объект конфигурации в RTCPeerConnection-Constructor, который содержит поле iceServers: [{urls: 'stun:some.stun.server.address},...] Поскольку мне кажется, что процесс сбора льда проверяет сгенерированные адреса-кандидаты:

  1. Он проверяет локальный адрес (например, 127.0.0.1), но поскольку он не работает на том же компьютере, происходит сбой.
  2. Он проверяет IP-адрес ОС (например, 192.168.178.13), и это будет работать, если 2 компьютера находятся в одной сети, но в разных сетях, эти локальные IP-адреса не помогают...
  3. Он делает STUN-запрос, спрашивая внешний сервер, с какого IP-адреса исходит этот запрос. Адрес другой, так как NAT выполняет свою работу. Затем он попытается соединиться с этим рефлексивным адресом. Для многих NAT это все равно не сработает, так как входящие запросы без предварительного исходящего подключения к IP будут запрещены
  4. Он делает запрос TURN и направляет весь разговор через сервер ретрансляции. Это должно работать почти в любом случае

Если вы не указали STUN и TURN серверы в своей конфигурации, шаг 3 и for не будут выполняться, потому что не будет рефлексивного адреса от stun-сервера и адреса ретрансляции сервера поворота. Следовательно, сбор льда может закончиться на шаге 2 (и быть полным), но соединения не будет, так как 1. и 2. будут давать сбои в разных сетях

person nasskalte.juni    schedule 17.10.2019
comment
Я использую сервер STUN и TURN. Однако не удалось получить удаленный поток. iceServers = [{ 'urls': [ 'turn:webrtcweb.com:7788', 'stun:webrtcweb.com:7788', ], 'имя пользователя': 'muazkh', 'учетные данные': 'muazkh' }]; - person Nitish Kumar; 17.10.2019
comment
@NitishKumar хорошо, это все усложняет. Насколько вы уверены, что перечисленные серверы работают? Пока указанный домен реагирует на пинг, я провел тест на сервере очереди с этим фрагментом при переполнении стека и этот ледовый тест webrtc и он сказал, что сервер поворота не работает (может проблема с конфигурацией?). Попробуйте свою конфигурацию с общедоступным сервером stun.l.google.com:19302 или любым из этих. - person nasskalte.juni; 19.10.2019
comment
Теперь я использую собственную настройку COTURN (проверено: - webrtc.github. io/samples/src/content/peerconnection/trickle-ice) и сервер stun от Google. Однако я нахожусь на той же стадии. например: - connectionState: подключение и iceConnectionState: проверка того, что я получаю в консоли. Помогите разобраться пожалуйста. где я делаю неправильно - person Nitish Kumar; 20.10.2019
comment
Хорошо, это странно, я был уверен, что это что-то вроде отсутствия рефлексивных (STUN) и ретрансляционных (TURN) адресов. Можете ли вы попытаться зарегистрировать полученные ледяные кандидаты, прежде чем добавлять их в одноранговое соединение (прямо перед вызовом yourRTCPeerConnection.addIceCandidate)? Проверьте, действительно ли вы получаете кандидатов типа relay и host. Вы можете идентифицировать их по их значению-кандидату, строке, которая будет содержать часть type srflx и type relay. - person nasskalte.juni; 21.10.2019
comment
Во время тестирования я получаю ошибку, в свою очередь, сервер: - transport=tcp вернул ошибку с кодом = 701: . Я использовал эту ссылку для настройки: - netways.de/blog/2017/08/16/ - person Nitish Kumar; 21.10.2019
comment
Учебник по ссылке выглядит нормально. Сервер очереди не работает в сети за NAT, я полагаю? Кроме того, в брандмауэре открыты следующие порты?: 1. 3478 (стандартный порт входящего поворота) 2. 49152–65535 (выделенные порты для исходящих соединений поворота ) А тестовая страница не показывала кандидатов не хоста? - person nasskalte.juni; 21.10.2019
comment
Я ценю ваше любезное сотрудничество. Однако я не могу решить проблему с сервером поворота. Я сделал все шаг за шагом. Не могли бы вы порекомендовать какое-либо руководство по настройке сервера TRUN/coTURN. - person Nitish Kumar; 22.10.2019
comment
Хорошо, я желаю вам удачи и надеюсь, что это сработает. Существует не так много хороших источников по установке и администрированию COTURN. Учебник, который вы использовали, как уже было сказано, вполне в порядке. Кроме того, посмотрите на это, и если оно заработает, также взгляните на учетные данные динамического поворота. Возможно, вы уже это знаете, но в целях отладки chrome предлагает обзор соединений webrtc через chrome://webrtc-internals. - person nasskalte.juni; 23.10.2019