Я не проверял до карантина, но с переходом на удалённую работу и использования для этого Discord'а заметил некоторые проблемы в работе этого программного обеспечения. Связавшись с их техподдержкой, пробовал разные предложенные варианты для решения проблемы (пропадает рандомно входящий звук в одностороннем порядке), одной из рекомендаций было тестирование служб RTC, необходимых, как вы знаете, для работы подобного софта. Тест вернулся с ошибкой, скрин ответа поддержки ниже.
Я уже оформил подписку на выделенный IP, проблема осталась. Может какие-то порты закрыты..?
Инструкции, ссылку на которые Вы дали, я уже видел и все проделал - ниже скрин отдельного ответа суппорта Дискорд на эту тему ещё неделю назад, до сих пор всё пытаюсь этот вопрос решить. СтОит отметить, что при тесте службы RTC через мобильный интернет, расшаренный на ноутбук по WiFi или напрямую с телефона, - ошибки нет.. также я просил соседа, подключенного к МГТС прогнать тест - ошибки у него также нет..
Я перезапускал всё оборудование, пробовал с разных устройств тесты провести, напрямую и через роутер - результат один;
У меня отключены в системе сервисы дефендеров и файерволов, нет антивируса;
Я не пользуюсь VPN;
Я подключаюсь из дома;
Я менял регион сервера в Дискорде;
Я пробовал отключить и включать QoS;
Скрин консоли из Дискорда также прилагаю - hope it helps :)
Сейчас по совету поддержки Дискорд пробую их Canary версию, и всё равно получаю периодические лаги голосовой связи или её отсутствие, и единственное, что может их вызывать, - неполадки с reflexive connectivity, о которых говорит результат теста.
вот ещё пара полезных ссылок по отладке RTC, которые я нашёл:
ICE allows candidates to represent connections over either TCP or UDP, with UDP generally being preferred (and being more widely supported). Each protocol supports a few types of candidate, with the candidate types defining how the data makes its way from peer to peer.
UDP candidate types
UDP candidates (candidates with their protocol set to udp) can be one of these types:
hostA host candidate is one for which its ip address is the actual, direct IP address of the remote peer.
prflxA peer reflexive candidate is one whose IP address comes from a symmetric NAT between the two peers, usually as an additional candidate during trickle ICE (that is, additional candidate exchanges that occur after primary signaling but before the connection verification phase is finished).
srflxA server reflexive candidate is generated by a STUN/TURN server; the connection's initiator requests a candidate from the STUN server, which forwards the request through the remote peer's NAT, which creates and returns a candidate whose IP address is local to the remote peer. The STUN server then replies to the initiator's request with a candidate whose IP address is unrelated to the remote peer.
relayA relay candidate is generated just like a server reflexive candidate ("srflx"), but using TURN instead of STUN.
Нас интересует тот, который reflexive. В Вашем почтовом обращении указан srflx.
Далее:
Самое важное поле в SDP пакетах ICE кандидатов это typ. Для WebRTC поле может иметь одно из трех значений:
typ host;
typ srflx;
typ relay.
typ host
Тип host задает ICE-кандидат на подключение по локальной сети (WebRTC перебирает несколько кандидатов в надежде установить подключение, заранее неизвестно, какой получится — примечание переводчика). Такое подключение не требует ни STUN, ни TURN-сервера, так как в локальной сети устройства часто могут устанавливать сетевые подключения напрямую. При отладке с локальной сети вам достаточно проверить и отладить передачу host-пакетов и убедиться, что устройства могут отсылать друг другу UDP-пакеты. Хотя бывают исключения, на практике я видел конфигурации сети, при которых браузеру требовался TURN-сервер, чтобы подключиться… к себе.
typ srflx
Комбинация букв «srflx» расшифровывается как «Server Reflexive» и маркирует кандидатов на подключение с использованием внешнего IP-адреса, где для подключения достаточно STUN-сервера (при этом используется технология NAT penetration, которая успешна примерно в 80% случаев — примечание переводчика).
typ relay
«Relay» маркирует подключение через TURN-сервер, которое почти всегда успешно.
Важно помнить, что WebRTC не обязано создать ровно три разных пакета с полем «typ»; как именно выбираются кандидаты – зависит от имплементации WebRTC в конкретной версии браузера.
STUN/TURN используются для прохождения NAT, поэтому не ясно, как информация о такой ошибке может влиять при использовании Вами подключения без роутера напрямую, и при наличии внешнего (public) IP Прошу уточнить дополнительно этот момент у разработчиков, дополнительно проверить соединение при такой схеме подключения.
Дмитрий, разбираемся, спасибо.. глаза начали краснеть :)
Думаю, я должен обратить Ваше внимание на то, что в результате WebRTC теста на ПК, подключенном напрямую через PPPoE - ошибка srflx - "TIMED OUT":
в то время как при подключении через роутер - "Could not connect using reflexive candidates, likely due to the network environment/configuration.":
Таким образом, получается, что напрямую система не может вообще соединиться по этому протоколу с внешним сервисом RTC, а через роутер (Mi R3P Router, 5GHz + Intel AC 9560) пытается использовать typ host с моим IP, но тоже безуспешно.
и проблема как раз в том, что иногда пропадает входящий звук на канале, исходящий передаётся исправно, меня продолжают слышать.
STUN/TURN используются для прохождения NAT, поэтому не ясно, как информация о такой ошибке может влиять при использовании Вами подключения без роутера напрямую, и при наличии внешнего (public) IP Прошу уточнить дополнительно этот момент у разработчиков, дополнительно проверить соединение при такой схеме подключения.
Прошу уточнить:
уточнить у поддержки Дискорд почему они думают, что моя проблема со звуком связана с RTC?
при какой "такой" схеме подключения я должен проверить соединение?
Прошу проверить подключившись без роутера напрямую. Сообщить периодичность и длительность наблюдаемой проблемы. Обозначенные выше логи Canary так же помогут в локализации проблемы.
Проблема
Не работают службы WebRTC Reflexive Connectivity - проверяю через сервис https://test.webrtc.org/
Подключен напрямую через кабель и PPoE, скрин прилагаю; поддержка "ничем не может помочь", "пусть проверяет настройки" без какого-либо уточнения.
Здравствуйте!
Прошу уточнить, когда перестали работать обозначенные службы.
Спасибо за ответ!
Добрый день, Дмитрий.
Я не проверял до карантина, но с переходом на удалённую работу и использования для этого Discord'а заметил некоторые проблемы в работе этого программного обеспечения. Связавшись с их техподдержкой, пробовал разные предложенные варианты для решения проблемы (пропадает рандомно входящий звук в одностороннем порядке), одной из рекомендаций было тестирование служб RTC, необходимых, как вы знаете, для работы подобного софта. Тест вернулся с ошибкой, скрин ответа поддержки ниже.
Я уже оформил подписку на выделенный IP, проблема осталась. Может какие-то порты закрыты..?
Прошу проверить в данный момент. При необходимости выполните рекомендации:
https://support.discordapp.com/hc/ru/articles/115001310031-%D0%9E%D1%88%D0%B8%D0%B1%D0%BA%D0%B8-%D0%B3%D0%BE%D0%BB%D0%BE%D1%81%D0%BE%D0%B2%D0%BE%D0%B3%D0%BE-%D1%81%D0%BE%D0%B5%D0%B4%D0%B8%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F
Сообщите результат.
Спасибо за ответ!
Благодарю за ответ, Дмитрий.
Я проверил ещё раз через - тот же тайм аут на https://test.webrtc.org/
Инструкции, ссылку на которые Вы дали, я уже видел и все проделал - ниже скрин отдельного ответа суппорта Дискорд на эту тему ещё неделю назад, до сих пор всё пытаюсь этот вопрос решить. СтОит отметить, что при тесте службы RTC через мобильный интернет, расшаренный на ноутбук по WiFi или напрямую с телефона, - ошибки нет.. также я просил соседа, подключенного к МГТС прогнать тест - ошибки у него также нет..
Сейчас по совету поддержки Дискорд пробую их Canary версию, и всё равно получаю периодические лаги голосовой связи или её отсутствие, и единственное, что может их вызывать, - неполадки с reflexive connectivity, о которых говорит результат теста.
вот ещё пара полезных ссылок по отладке RTC, которые я нашёл:
ICE and WebRTC: What Is This Sorcery? We Explain... » Temasys.io
Troubleshooting WebRTC Connection Issues
Как отлаживать WebRTC / Блог компании Voximplant / Хабр
Да, попробуем вместе разобраться.
ICE allows candidates to represent connections over either TCP or UDP, with UDP generally being preferred (and being more widely supported). Each protocol supports a few types of candidate, with the candidate types defining how the data makes its way from peer to peer.
UDP candidate types
UDP candidates (candidates with their
protocolset toudp) can be one of these types:hostA host candidate is one for which itsipaddress is the actual, direct IP address of the remote peer.prflxA peer reflexive candidate is one whose IP address comes from a symmetric NAT between the two peers, usually as an additional candidate during trickle ICE (that is, additional candidate exchanges that occur after primary signaling but before the connection verification phase is finished).srflxA server reflexive candidate is generated by a STUN/TURN server; the connection's initiator requests a candidate from the STUN server, which forwards the request through the remote peer's NAT, which creates and returns a candidate whose IP address is local to the remote peer. The STUN server then replies to the initiator's request with a candidate whose IP address is unrelated to the remote peer.relayA relay candidate is generated just like a server reflexive candidate ("srflx"), but using TURN instead of STUN.Нас интересует тот, который reflexive. В Вашем почтовом обращении указан srflx.
Далее:
Самое важное поле в SDP пакетах ICE кандидатов это typ. Для WebRTC поле может иметь одно из трех значений:
typ host
Тип host задает ICE-кандидат на подключение по локальной сети (WebRTC перебирает несколько кандидатов в надежде установить подключение, заранее неизвестно, какой получится — примечание переводчика). Такое подключение не требует ни STUN, ни TURN-сервера, так как в локальной сети устройства часто могут устанавливать сетевые подключения напрямую. При отладке с локальной сети вам достаточно проверить и отладить передачу host-пакетов и убедиться, что устройства могут отсылать друг другу UDP-пакеты. Хотя бывают исключения, на практике я видел конфигурации сети, при которых браузеру требовался TURN-сервер, чтобы подключиться… к себе.
typ srflx
Комбинация букв «srflx» расшифровывается как «Server Reflexive» и маркирует кандидатов на подключение с использованием внешнего IP-адреса, где для подключения достаточно STUN-сервера (при этом используется технология NAT penetration, которая успешна примерно в 80% случаев — примечание переводчика).
typ relay
«Relay» маркирует подключение через TURN-сервер, которое почти всегда успешно.
Важно помнить, что WebRTC не обязано создать ровно три разных пакета с полем «typ»; как именно выбираются кандидаты – зависит от имплементации WebRTC в конкретной версии браузера.
STUN/TURN используются для прохождения NAT, поэтому не ясно, как информация о такой ошибке может влиять при использовании Вами подключения без роутера напрямую, и при наличии внешнего (public) IP
Прошу уточнить дополнительно этот момент у разработчиков, дополнительно проверить соединение при такой схеме подключения.
Спасибо за ответ!
Дмитрий, разбираемся, спасибо.. глаза начали краснеть :)
Думаю, я должен обратить Ваше внимание на то, что в результате WebRTC теста на ПК, подключенном напрямую через PPPoE - ошибка srflx - "TIMED OUT":
в то время как при подключении через роутер - "Could not connect using reflexive candidates, likely due to the network environment/configuration.":
Таким образом, получается, что напрямую система не может вообще соединиться по этому протоколу с внешним сервисом RTC, а через роутер (Mi R3P Router, 5GHz + Intel AC 9560) пытается использовать typ host с моим IP, но тоже безуспешно.
Через chrome://webrtc-internals/ с запущенным в соседней вкладке Дискордом такая картина:
и проблема как раз в том, что иногда пропадает входящий звук на канале, исходящий передаётся исправно, меня продолжают слышать.
Прошу уточнить:
уточнить у поддержки Дискорд почему они думают, что моя проблема со звуком связана с RTC?
при какой "такой" схеме подключения я должен проверить соединение?
Спасибо за терпение!
из последнего..
Прошу проверить подключившись без роутера напрямую. Сообщить периодичность и длительность наблюдаемой проблемы. Обозначенные выше логи Canary так же помогут в локализации проблемы.
Спасибо за ответ!
Здравствуйте!
Уточните, пожалуйста, наблюдается ли проблема?
Спасибо за ответ!
Добрый день, Дмитрий.
Наблюдается пока.. бодаюсь с поддержкой Discord'а - они не могут точно сказать, что из-за WebRTC connectivity это происходит. Пока на холде тикет.
Интересно увидеть ответы. Присылайте, по возможности.
Спасибо за ответ!
За этот месяц не было подобных проблем, юзал canary build.
Спасибо за информацию!