Приведут ли переговоры ICE между партнерами за двумя симметричными NAT к двум серверам TURN?

Question

Я читаю RFC6577 и RFC8445 , но я чувствую, что есть некоторое расхождение между тем, как TURN может использоваться противкак ICE на самом деле использует relay candidates.

В RFC TURN описано использование одного сервера TURN для передачи данных между клиентом и партнером.transport address на сервере TURN принимает поток данных от клиента через сообщения TURN, тогда как relayed transport address принимает поток данных от одноранговых узлов через UDP.Это звучит замечательно - один сервер TURN и двунаправленный поток данных.

Однако, читая о ICE, я чувствую, что этого никогда не происходит.И вызывающий, и вызываемый абоненты независимо выделяются на двух серверах TURN, а затем отправляют их соответствующие relayed transport addresses друг другу.Больше похоже на I can be reached via this relayed transport address.Затем выполняются проверки подключения, и, таким образом, два сервера TURN в конечном итоге используются здесь, когда данные передаются только в одном направлении через relayed transport address каждого участника, выделенного серверу TURN.

Это правда?

Из RFC TURN говорится следующее:

Клиент может организовать сервер для ретрансляции пакетов на и с некоторых других хостов (называемых одноранговыми узлами) и может управлять аспектами того, как осуществляется ретрансляция.Клиент делает это, получая IP-адрес и порт на сервере, называемый ретранслируемым транспортным адресом.Когда одноранговый узел отправляет пакет на ретранслируемый транспортный адрес, сервер передает пакет клиенту.Когда клиент отправляет пакет данных на сервер, сервер передает его соответствующему узлу, используя ретранслируемый транспортный адрес в качестве источника.

Однако я не вижу сценария, посредством которого посредством согласования ICEданные будут когда-либо проходить через транспортный адрес от клиента к одноранговому узлу.И вызывающий, и вызываемый абоненты независимо размещаются на сервере TURN и отправляют друг другу relayed transport addresses для достижения.

Как правило, TURN может делать двунаправленные данныепоток, но с ICE между двумя симметричными NAT, это не .Это правильно?

Answer 1

Это немного сложно .... терпеть меня.Чтение только RFC TURN недостаточно, вам нужен контекст из RFC 5245 на ICE.

Следующий сценарий является базовым: 1) клиент A выделяет адрес ретранслятора 8.8.8.8: 43739, отправляет его клиенту B 2) клиент B отправляет пакет UDP на 8.8.8.8:43739 3) TURN-серверы упаковывают пакет в сообщение ошеломления, отправляют его клиенту A

Теперь, как вы говоритеобычно клиент B также выделяет свой собственный адрес ретранслятора и отправляет его A. Почему это не используется постоянно (или наполовину)?Приоритеты кандидатов равны в конце концов.Тем не менее, приоритет пары кандидатов , который определяет, какую пару выбрать, включает в себя фактор, который действует как прерыватель связи:

      pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)
Where G>D?1:0 is an expression whose value is 1 if G is greater than
D, and 0 otherwise.

Это означает пару, в которой находятся вызывающие абоненты (предполагая, что это контролирующий агент) Используемый адрес ретрансляции имеет более высокий приоритет, чем пара с адресом ретранслятора вызываемых абонентов.

Кроме того, в игре есть еще один кандидат для порта, который клиент B использует для отправки на порт 8.8.8.8:43739.Обычно это один из локальных кандидатов, и сервер TURN видит (и помещает в индикацию данных) публичный (post-nat) ip клиента B. На клиенте A это будет отображаться как удаленный кандидат srflx, которыйимеет более высокий приоритет, чем ретранслируемый кандидат, и поэтому будет использоваться.

Теперь, если B находится за симметричным NAT (я думаю ), сервер TURN увидит другой порт от клиента B, чемвсе, на что клиент А добавил разрешение.Обычно это означает, что сервер TURN отбросит пакет, и эта пара не будет работать.

Если клиент A не находится за симметричным NAT, базовый процесс будет повторяться в другом направлении.Немного менее приоритетно, но одинаково с точки зрения задержки, так что пользователи не заметят.

Если оба клиента (и теперь мы наконец-то подошли к делу, о котором вы спрашиваете) находятся за симметричным NAT, ни один не будетработа и пара реле-реле будет использоваться.Это довольно редко (вероятно, <1%), и влияние задержки, как правило, незначительно, даже если оба клиента находятся на разных серверах TURN. </p>