Я думаю, что ошибка 701 является более общей ошибкой подключения, которую Trickle ICE использует, чтобы указать, что он не получил ответа на привязку. Запустите stunclient your.stun.ip.address
с инструментами командной строки на www.stunprotocol.org, чтобы узнать, доступна ли ваша служба STUN из внешнего мира. .
STUN технически требует размещения на устройстве с двумя IP-адресами и двумя портами. Обычно это параметр командной строки, указывающий, какие IP-адреса сервер должен прослушивать. Но большинство реализаций серверов могут работать на хосте с одним IP-адресом.
Второй IP-адрес и порт на сервере используются для тестов фильтрации клиентов STUN, чтобы определить, какой тип NAT действует. Клиент отправляет запрос на привязку к основному IP-адресу и порту сервера, но с атрибутом запроса на изменение, чтобы сервер ответил с альтернативного IP-адреса или порта. Чаще всего этот запрос на привязку с атрибутом запроса на изменение не выполняется, поскольку NAT не будет перенаправлять трафик с другого IP/порта.
Тест фильтрации полезен для регистрации типа NAT, на котором работает клиент. Таким образом, неудачные соединения можно отлаживать, а показатели успеха/неудачи можно сопоставить с типом NAT.
Поскольку большинство реализаций ICE будут обмениваться всеми доступными адресами-кандидатами (локальными, сопоставленными и ретрансляционными), тест фильтрации не очень полезен для установления соединения.
Я удивлен, что Trickle ICE выдает ошибку. Я не думал, что WebRTC когда-либо использовал атрибут changer-request. Я только что отследил Wireshark сеанса Trickle ICE до stun.stunprotocol.org. Я не вижу клиента webrtc, устанавливающего атрибут запроса на изменение ни в одном из двух запросов на привязку, которые он делает.
Дополнительные сведения см. в RFC 5780, раздел 3.2.
person
selbie
schedule
21.06.2020