Reflexive connectivity что это
Не установлен маршрут Discord
Появились проблемы с подключением к RTC Discord, не получается общаться голосом во время игры? Мы расскажем, как устранить трудности – разобрали самые распространенные причины!
Что делать?
Для начала определимся, что значит подключение к RTC в Дискорде? Если оно зависает и становится бесконечным – перед вами проблема голосового соединения. В процессе работы Дискорд зависает в попытках подключиться к серверу – поэтому не получается общаться голосом.
Что значит подключение – разобрались. Попробуем устранить возникшую ошибку? Вы можете сделать это самостоятельно!
Что делать, если не установлен маршрут Дискорд и перезагрузка не помогла?
То же касается брандмауэра или фаервола – откройте меню и выберите пункт «Приостановить защиту». Вы сможете запустить работу через несколько минут.
Следующее действие – проверка VPN. Если вы пользуетесь ВПН-подключением, убедитесь, что оно работает через протокол UDP. Другие протоколы Дискорд не поддерживает!
Бесконечное подключение к RTC можно убрать – смените регион:
Дискорд по-прежнему не подключается и показывает бесконечное подключение к RTC? Сделайте следующее:
РТЦ отключено, хотя вы сделали все по инструкции? Придется переустановить программу.
Напоминаем: если вы пользуетесь Дискордом в учебной или рабочей организации, можно попросить помощи администратора. Вероятно, мессенджер попал под блокировку сторонних ресурсов, поэтому вы видите бесконечное подключение к RTC.
Последнее, что мы рекомендуем сделать – откройте сайт https://test.webrtc.org/ в браузере и проверьте, не выскакивают ли ошибки.
Рассказали вам, как убрать подключение к RTC в Дискорде – следуйте нашим инструкциям, чтобы справиться с возникшими трудностями! Можно играть и общаться без ограничений.
Reflexive connectivity test times out #129
Comments
KaptenJansson commented Oct 9, 2015
I’ve not had a chance to debug this yet but if you @jessetane have an idea please take a look.
The text was updated successfully, but these errors were encountered:
jessetane commented Oct 9, 2015
So, on my home network (cheap netgear wifi router with a public ip doing stock nat) it works fine, however when I tether my laptop through my phone (AT&T LTE, at least 2 levels of nat) reflexive times out for me as well. That particular scenario has never worked for me without a relay though so it does not come as a surprise. What does your network setup look like?
KaptenJansson commented Oct 9, 2015
Ow, my comment never made it (I did not hit enter before I left the office it seems:().
I wrote exactly what you wrote, our corp network is behind several NAT’s hence it times out, @andresusanopinto kindly pointed this out.
We do suggest however that instead of reportFatal we should do reportWarning as this is expected lots of networks (corp, mobile etc). I think that applies to the Host candidate test as well, that will not always succeed either. Basically they are informative tests, not «something is wrong with your system» kind of test.
Then we could also change the warning text to «Failed to gather HOST/Server Reflexive Candidates» rather than just displaying «Timed out».
jessetane commented Oct 9, 2015
Got it. First, is there a common scenario when host connectivity would fail? That’s the exact issue that led me here in the first place, and it seems important to me that that scenario would always work. Very interested to know if I’m missing anything with that assumption!
I agree it might be nice to lower the severity level of the failure, but reportWarning still shows the green check next to the failed test for me. I see the suite turns yellowish, but the only way to see which test failed is to open each of them up and read the log, which is sort of annoying.
jessetane commented Oct 9, 2015
One other thing: I’m fairly sure host and reflexive candidates are almost always gathered, even when their respective connectivity tests fail. The failure is most frequently due to unknown configuration or topology problems on the network, so in those situations I’m not sure what else we could log other than basically «it didn’t work».
KaptenJansson commented Oct 23, 2015
I increased the timeout in #130, lets see if that reduces some of throughput and connectivity test «Timed out» failures.
KaptenJansson commented Oct 23, 2015
Also, I’m not sure but I suspect that when creating a peerconnection with a turn server address ( turn:turn:xx.x.x.x.x) the turn server does not provide server reflexive candidates or even the browser filters them out? Will have to do some testing.
WRT to reportWarning() should in my opinion fail but suite turn yellow. And yes it is tricky as it’s environment dependent, which we cannot detect hence we got nothing to compare with to determine if the test result is valid for the particular environment. Tricky 😉
KaptenJansson commented Oct 23, 2015
Ow I missed the fact that the reflexive test ofc uses STUN, nvm my comment about TURN + reflexive candidates 😉
KaptenJansson commented Oct 23, 2015
So maybe we should add a warning that reflexive candidates have been gathered successfully (verifies that the browser has been able to contact the stun server and it has provided candidates) but failed to establish a connection, most likely due to some exotic network config.
Maybe better to consolidate the tests and evaluate the results from all three collectively?
jessetane commented Oct 23, 2015
Also worth bringing up here is the IPv6 test which is a similar situation (fails for most people, but does not necessarily break anything).
Как исправить проблему подключения к RTC Discord
За последние 5-10 лет Discord приобрёл мировую популярность. Умело объединив лучшие функции Twitch, Teamspeak и IRC в одной простой в использовании социальной платформе. На данный момент это удобная коммуникационная платформа для геймеров. Которым необходимо общаться со своими товарищами по команде на более приватном уровне. Тем не менее, не только геймеры обращаются к сервисам Discord. А также компании, ютуберы и другие влиятельные лица в социальных сетях.
Одна из наиболее распространённых проблем, с которыми люди сталкиваются — это проблема подключения RTC. К счастью, проблему не так сложно исправить, и в данной статье мы расскажем вам обо всех методах её решения.
Что такое RTC подключение к Discord?
Прежде чем мы перейдём к тому, как исправить проблему с подключением RTC, вероятно, стоит узнать, что такое RTC.
RTC — это стандарт веб-связи в реальном времени. Который позволяет отправлять и получать как голос, так и видео. RTC был запущен Google в 2011 году. Обеспечивая передачу звука, видео и данных в реальном времени через Интернет. Конечная цель RTC заключалась в том, чтобы позволить разрабатывать приложения для браузеров, мобильных платформ и других устройств. Которые предлагали более богатую и качественную аудио и видеосвязь.
В случае Discord RTC обрабатывается большими серверами. То есть, когда вы подключаетесь к каналу Discord, вы должны проходить через указанные серверы. Иногда возникает проблема с подключением к серверу RTC. Именно тогда Discord предложит вам ошибку подключения к RTC.
К счастью, в девяти случаях из десяти ваша проблема связана с Интернетом и может быть решена с помощью нескольких простых шагов. Однако в других случаях это может быть немного сложнее.
Как исправить проблему подключениея к Discord RTC
Если вы столкнулись с этой конкретной проблемой, не бойтесь, решение обычно довольно простое — в большинстве случаев во всяком случае.
Ниже мы расскажем о наиболее эффективных способах возобновления работы вашего Discord. Мы будем ранжировать их в порядке релевантности и успеха, начиная с наиболее удачного старта.
Перезагрузите Discord и Ваш маршрутизатор
Чтобы не звучать как один из тех специалистов по техподдержке колл-центра, но первый шаг, который вы должны сделать, — это включить и выключить маршрутизатор (и Discord). Это не только сбросит ваше интернет-соединение, но и исправит любые ошибки загрузки Discord, которые могли возникнуть во время открытия Discord.
Этот простой метод почти всегда исправит вашу ошибку подключения Discord RTC. Он также исправит ошибку отсутствия маршрута и ошибки подключения RTC.
Проверьте Свой Брандмауэр
Во-вторых, всегда проверяйте свой брандмауэр Windows / антивирус, чтобы убедиться, что он неправильно блокирует подключение Discord к серверам. Он даже может быть включён в белый список или временно отключён брандмауэром.
Если вы хотите быть на 100% уверены, что проблема не в брандмауэре, попробуйте ненадолго выключить его, а затем подключиться к Discord. Однако это сопряжено с целым рядом собственных потенциальных рисков, которые намного перевешивают проблему подключения RTC.
Убедитесь, что Ваш VPN поддерживает Discord
Для пользователей, использующих службу VPN, дважды проверьте, не блокирует ли VPN Discord. Это довольно распространено, поскольку Discord работает только с VPN, которые имеют UDP (протокол пользовательских дейтаграмм) — сетевой протокол, который передаёт ваши данные через Интернет с вашего устройства на ваш веб-сервер.
Если ваша текущая VPN не имеет UDP.
Свяжитесь с администратором сети
Если вы находитесь в школе или в среде офисного типа, где вам необходимо подключиться к локальному интернет-серверу, узнайте у администратора, заблокирован ли у него Discord. Хотя это маловероятно, это определённо то, что помешает вам подключиться к любому серверу Discord.
Изменить регион голоса
Если Вы являетесь администратором собственного канала Discord, всегда стоит изменить регион голоса в настройках сервера. Вы можете сделать это, перейдя в «Настройки сервера> Регион сервера».
Хотя это не будет работать каждый раз, в нестандартных ситуациях изменение региона может фактически остановить досадные ошибки, такие как ошибка отсутствия маршрута и подключение RTC.
Уменьшить качество обслуживания
По умолчанию в Discord есть функция качества обслуживания, которая может стать проблемой, если у вас нет самого быстрого Интернета в мире. Чтобы отключить эту функцию, просто перейдите в Настройки пользователя> Голос и видео> и снимите флажок «Включить качество обслуживания с высоким приоритетом пакетов».
После этого просто перезапустите Discord и посмотрите, решит ли это вашу проблему.
Как мы уже говорили, в девяти случаях из десяти перезапуск маршрутизатора и приложения Discord должен решить любую из ваших проблем. Однако в более нестандартных ситуациях один из других методов, описанных в этом руководстве, должен быстро вернуть вас к работе.
Заключение
Итак, вот и всё, наше краткое изложение того, как исправить раздражающую ошибку подключения RTC в Discord. Надеюсь, описанные выше методы позволили вам решить проблему. А также вернуться к игре с друзьями и товарищами по команде.
Как отлаживать WebRTC
В Voximplant мы используем WebRTC с момента ее появления: сначала как альтернативу Flash для голосовых и видеозвонков, а затем как полную замену. Технология прошла долгий и болезненный путь развития, только недавно ее стали поддерживать все основные браузеры, есть сложности с передачей экрана, нескольких видеопотоков, а иногда браузер падает просто если выключить и включить видеопоток. Накопленный опыт позволяет переводить для Хабра интересные статьи, и сегодня мы передаем слово Ли Сильвестру из Xirsys, который расскажет про отладку (видео)звонков в Chrome, Firefox, Safari и Edge. Отлаживать WebRTC непросто, у нас даже есть специальные инструкции по снятию логов в популярных браузерах. А что есть у Ли – вы узнаете под катом (спойлер: много всего, включая WireShark).
Темная сторона WebRTC
Работая в Xirsys, я видел несколько действительно крутых приложений, которые использовали WebRTC. Но пока небольшая группа разработчиков создает высокотехнологичные штуки, большая часть программистов не могут даже начать использовать WebRTC. Почему? А все просто. Оно сложное.
Многим из нас знакомо типичное веб-приложение. У такого приложения есть клиент, который отправляет запросы и сервер, который на эти запросы отвечает. Простой, линейный и легко предсказуемый процесс. Если что-то пойдет не так, мы обычно знаем где смотреть логи и что могло случиться. А вот с WebRTC все не так просто.
Асинхронность
Если вы когда-нибудь писали многопоточное приложение, то наверняка знаете о той головной боли, которую доставляет подобная разработка. Рейсы, битая память, — но чаще всего просто баги, которые трудно искать.
WebRTC асинхронно по своей природе. И это совсем не простенькая асинхронность AJAX. Если проводить аналогию, то это несколько одновременно запущенных AJAX запросов, которые пытаются согласовать данные на двух компьютерах. То еще развлечение.
Минное поле обхода NAT
Создание веб-приложений сводится к разработке чего-то, что запускается на сервере и отвечает на запросы. Самое страшное что может случиться — это не открытый в IPTables порт. Лечится за 2 минуты. Чего не скажешь о WebRTC.
Веб-серверы, даже не их софт, а железо — это устройства с публичными IP-адресами. Они сделаны, чтобы быть доступными откуда угодно. А WebRTC сделано, чтобы отправлять и принимать данные с компьютеров пользователей. Которые обычно имеют IP-адреса 192.168.что-нибудь и не горят желанием отвечать на сетевые запросы.
Авторы WebRTC об этом знают, поэтому движок будет перебирать разные способы подключения, в попытке установить связь между двумя не очень предназначенными для такого компьютерами.
Где начинать отладку
В этой статье я рассказываю про основной инструментарий для решения самых популярных проблем. Но перед этим давайте посмотрим, как WebRTC обычно устанавливает подключение.
Как WebRTC устанавливает подключение
Все подключения WebRTC требуют «небольшой помощи» со стороны сигнального протокола. «Небольшая помощь» — это ваш собственный сервер и протокол, с помощью которого звонящий сможет пообщаться с тем, кому звонит, прежде чем установить Peer-to-peer подключение.
WebRTC воспользуется сигнальным протоколом для передачи информации об IP-адресах, возможностях по захвату и воспроизведению голоса и видео, топологии сети, передаваемых данных.
Обычно используется протокол COMET (или SIP — примечание переводчика) и веб-сокеты. WebRTC ничем не ограничивает разработчиков, так что можно использовать что нравится, хоть передавать данные через Notepad и копипасту (делали на одном из воркшопов, работает — снова переводчик). Подключенное к обоим компьютерами сигналирование позволяет начать подключение уже по WebRTC.
Offer и answer
WebRTC подключения используют «offer» и «answer»:
ICE-кандидаты
Но одних возможностей по работе с медиаданными мало. Ведь договаривающиеся стороны еще ничего не сказали о состоянии сети.
Узнать, какие видеокодеки поддерживает браузер и есть ли на ноутбуке камера, можно почти мгновенно. Узнать свой внешний IP-адрес и логику работы NAT занимает время, и обмен информацией о состоянии сети происходит по мере получения этой информации.
Благодаря технологии Trickle ICE (поддерживается не всеми браузерами — примечание переводчика) подключение между двумя WebRTC-устройствами может установиться в любой момент – как только будет найден подходящий «кандидат».
Разработчик должен подписаться на событие onicecandidate (все строчные!) и передавать другой стороне получаемые SDP-пакеты, где их нужно передаваться WebRTC с помощью метода addIceCandidate (а вот здесь, сюрприз, заглавная буква). Работает в обе стороны.
Подключение
Для установки подключения WebRTC использует такие штуки как STUN (Session Traversal Utilities for NAT) и TURN (Traversal Using Relay around NAT). Звучит страшно, но на самом деле всего лишь два сетевых протокола.
STUN-сервер
Первый из двух протоколов чуть сложнее эхо-сервера. Когда участники подключения хотят описать как к ним подключаться, им нужен их публичный IP-адрес. И скорее всего это не будет IP-адрес компьютера, пользовательским устройствам редко выделяют публичные адреса. Целую технологию NAT придумали, чтобы не выделять. Чтобы все-таки узнать свой публичный адрес, браузер делает запрос к STUN серверу. Проходя через NAT, сетевой пакет меняет свой обратный адрес на публичный. Получив пакет с запросом, STUN-сервер копирует обратный адрес пакета в его payload и отправляет пакет обратно. Проходя через NAT в обратную сторону, пакет теряет публичный IP-адрес, но копия этого адреса остается в payload, где ее может прочитать WebRTC.
TURN-сервер
TURN-сервер использует расширение STUN-протокола. Те же пакеты, заголовки, плюс новая штука: command. Сервер является прокси: оба клиента подключаются к нему через UDP-порт allocation и передают через сервер свои данные.
TURN-серверы устроены таким образом, что инициатор подключения имеет больше возможностей, чем другая сторона. Это приводит к интересному эффекту, когда звонок через TURN сервер будет успешным или неуспешным в зависимости от того, кто кому звонит (все вспоминаем скайп — примечание переводчика).
Отладка
Итак, вы дочитали до этого параграфа. Мы с переводчиком рады и помним, что статья об отладке WebRTC. Но все написанное выше — необходимый минимум, без которого можно даже не начинать. А вот если начать, и вы не располагаете нечеловеческим везением, то оно будет ломаться.
Оно будет ломаться множеством разных способов. Первый из них: отсутствие подключения. Вы передали обоим WebRTC настройки STUN и TURN-серверов, помогли им обменяться offer, answer и ICE кандидатами, а видео или голоса нет. С чего начать? С локального воспроизведения проблемы.
Локальная отладка WebRTC
Как я уже писал выше, основная работа WebRTC происходит на стороне браузера. STUN и TURN-серверы невероятно просты, так что большинство проблем случаются в вашем JavaScript-коде, который выполняется в двух браузерах. Sad but true. С другой стороны, если самое интересное происходит локально в браузерах, то у вас есть широкие возможности по отладке!
Первое что надо проверить — это ваше сигналирование. Именно ваш код передает между браузерами конфигурацию аудио с видео (offer, answer) и информацию о сетевых настройках (ice кандидаты). Вам нужно проверить, какие пакеты были отправлены, какие получены и переданы WebRTC:
Session Description Protocol
Пакеты Offer, Answer и ICE-кандидатов создаются WebRTC в текстовом формате SDP. На первый взгляд содержимое пакетов выглядит страшновато, но с небольшой подготовкой можно извлечь из них много пользы во время отладки. Wikipedia неплохо описывает SDP, но для вас я нашел описание получше.
Самое важное поле в 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 в конкретной версии браузера.
Тестирование подключения к устройству
Google предлагает специальное веб-приложение для тестирования WebRTC-подключений на вашем устройстве. Откройте страницу, нажмите кнопку «start» и JavaScript код попробует установить подключение к серверу Google, используя сигналирование, STUN и TURN-серверы Google.
WebRTC Internals
Вы осмотрели все пакеты, проверили код, все выглядит правильно, но не работает? Для таких случаев Google снабдила свой браузер Chrome специальным разделом, который показывает внутренности WebRTC во время установки подключения и немного красивых графиков в случае успешного подключения. Чтобы воспользоваться, откройте в браузере специальную техническую ссылку:
Если у вас уже открыто приложение, использующее WebRTC, то вы сразу увидите кучу технических данных. В противном случае просто откройте еще одну вкладку и в ней что-нибудь, что использует WebRTC. Вкладка отображает все вызовы к объекту RTCPeerConnection и позволяет увидеть в реальном времени как устанавливается подключением.
Настройка ICE
Сверху страницы отображается ICE-строка, которая была использована при инициализации подключения. Если при ее формировании была допущена ошибка, это сразу же будет видно (под «ICE-строкой» автор имеет в виду конфигурацию объекта RTCPeerConnection со списком STUN и TURN-серверов (объект ‘iceServers’) – примечание переводчика). Возможно, там нет списка серверов? Вы должны сконфигурировать объект RTCPeerConnection до того, как сделали первый вызов createOffer или createAnswer.
События RTCPeerConnection
Следующий раздел internals показывает вызовы методов RTCPeerConnection и полученные от объекта события в хронологическом порядке. Ошибки заботливо подсвечиваются красным. Обратите внимание, что подсвеченное красным addIceCandidateFailed часто не является признаком ошибки и подключение может нормально установиться. В случае успешного подключения последним в списке будет событие iceconnectionstatechange с значением complete.
Раздел ‘stats’
Следующий раздел актуален, когда подключение успешно установлено. Он содержит статистику передаваемых данных и сетевые задержки. Два наиболее интересных параметра: ssrc и bweforvideo.
Функция getStats
Часто вы не сможете получить доступ к странице internals. Например, когда проблема случается у вашего пользователя. В таком случае вы можете получить те же данные, что показывает страница internals, вызывая метод getStats у объекта RTCPeerConnection. Этот метод устанавливает функцию обратного вызова, которая будет вызываться WebRTC каждый раз, когда происходит что-нибудь интересное. Вызываемая функция получает объект с теми полями, которые отображает страница internals:
Еще один полезный инструмент – это событие oniceconnectionstatechange объекта RTCPeerConnection. Обработчик события будет получать информацию о прогрессе подключения. Возможные варианты:
Черный прямоугольник вместо видео
Часто случается ситуация, когда подключение установилось, звук передается, а вот вместо видео у одного или обоих участников черный прямоугольник. Чаще всего это случается, если назначить полученный объект с видео HTML-элементу до того, как соединение перейдет в состояние completed.
Как потыкать палочкой снаружи
Кроме самого объекта RTCPeerConnection и отображаемых браузером internals вы можете использовать инструменты анализа сетевых пакетов, такие как Wireshark. Эти инструменты умеют отображать пакеты используемых WebRTC-протоколов. Например, Wireshark покажет вам содержимое STUN-пакетов в главном окне, и их можно отфильтровать, набрав в поле фильтра ключевое слово «stun»:
На что смотреть в ответах серверов? Если вы видите только ответы с типом Binding, это значит поддержку только STUN (рассказ о внешнем IP), и WebRTC сможет предложить только srflx-кандидатов. Если же в ответах есть специфичные для TURN пакеты Allocation и CreatePermission, то у WebRTC будет возможность попробовать подключиться через прокси-сервер. Анализатор пакетов помечает успешные и неуспешные Allocation. Если нет ни одного успешного, то скорее всего переданы неверные параметры доступа к TURN-серверам (которые почти всегда защищают логином и паролем — примечание переводчика).
Если в логе есть пакет CreatePermission Success Response, то можно предположить, что с конфигурацией STUN и TURN все хорошо. А если еще и ChannelBind пакет присутствует, то значит удалось установить подключение к TURN-серверу на высокой скорости.
Проблемы сотовой связи
В моей практике множество WebRTC-решений, устанавливающих подключение по WiFi, не могут подключиться по 3G/4G. Запущенное на мобильном устройстве приложение тяжелее отлаживать: у нас нет такого простого анализатора пакетов как Wireshark, а Safari не умеет показывать WebRTC internals. Логика подсказывает, что если приложение нормально работает по WiFi, то проблема не в самом приложении, а в сотовой связи. Как отладить? Взять ноутбук и подключить к нему 3G донгл. Так у вас появляются анализатор пакетов и удобные логи, с помощью которых можно за разумное время найти корень всех бед.