rfc 5766: проблема, когда оба устройства поддерживают TURN

Я просматривал TURN rfc 5766 и не нашел объяснения проблемы. RFC говорит о ТОЛЬКО 1 устройстве (клиенте), которое поддерживает TURN, а другое устройство не поддерживает TURN. У меня есть определенные сомнения, что оба устройства поддерживают TURN. Я использую протокол SIP. Предполагается, что оба устройства находятся за плохими NAT (т. Е. NAT с ограничением адреса и порта).

Если оба устройства, скажем, устройство A и устройство B, поддерживают TURN,

1. На какой транспортный адрес устройство A будет отправлять данные своего приложения? а. на назначенный ПЕРЕВОДИТЕЛЬНЫЙ АДРЕС. б. на ПЕРЕВЯЗАННЫЙ АДРЕС удаленной стороны.

1. С какого транспортного адреса устройство A будет получать данные приложения? a. С выделенного ПЕРЕНОСИТЕЛЬНОГО АДРЕСА. б. С ПЕРЕВЕДОМОГО АДРЕСА удаленной стороны.

Спасибо и привет


nat stun sip rfc
person user2139084    schedule 24.01.2014    source источник

Ответы (2)


arrow_upward
1
arrow_downward

В RFC говорится о сервере TURN за пределами NAT и о клиенте за NAT, которому необходимо взаимодействовать с другим клиентом, также находящимся за NAT. Идея состоит в том, что каждый клиент подключается к серверу TURN (не обязательно к одному и тому же), получает публичный адрес от сервера и отправляет этот адрес в сообщении SIP (например, в теле SDP) другому клиенту, например

  1. клиент №1 подключится к повороту №1 и получит общедоступный адрес №1
  2. клиент №2 подключится к повороту №2 и получит общедоступный адрес №2
  3. клиент №1 отправляет адрес №1 клиенту №2
  4. клиент # 2 отправляет адрес # 2 клиенту # 1

Если клиент №1 может напрямую связаться с адресом №2 (обычно это так, если у вас нет ограничивающего брандмауэра, а не простого NAT), он отправит пакет на адрес №2 и, таким образом, проложит туннель в свой собственный NAT. Таким образом, возможны не только пакеты от клиента №1 к адресу №2, но и пакеты от адреса №2 к клиенту №1. В результате получается следующий сценарий общения:

client # 1 ‹--- NAT # 1 ---> Turn # 2 (addr # 2)‹ --- NAT # 2 ---> client # 2

Только если прямая связь между клиентом №1 и адресом №2 (или клиентом №2 с адресом №1) невозможна (редко, только если оба находятся за ограничительными брандмауэрами), вам необходимо использовать оба сервера TURN:

client # 1 ‹- FW # 1 ---> Turn # 1 (addr # 1) ‹---> Turn # 2 (addr # 2)‹ --- FW # 2 ---> client # 2

Спасибо selbie @ за указание на то, что обычно достаточно одного сервера TURN.

person Steffen Ullrich    schedule 24.01.2014
comment
Спасибо Штеффену Ульриху за помощь, но в предложенном вами решении IP-адрес, на который будут отправляться данные, и IP-адрес, с которого будут получены данные, будут разными. Разве это не контрастирует с полем «соединение» в SIP? Должны ли мы установить 2 поля «соединение», одно для «sendonly», а другое для «recvonly»? - person user2139084; 27.01.2014
comment
Поле соединения в теле SDP только указывает, куда одноранговый узел должен отправлять свои данные. Это будут внешние адреса, предоставленные серверами TURN. То, что каждый из клиентов поддерживает туннель к своему серверу TURN, а сервер TURN будет пересылать данные своему клиенту, не имеет значения для другой стороны и, следовательно, не требует указания в SDP. - person Steffen Ullrich; 27.01.2014
comment
исправление: клиенты не только получают свои данные через сервер TURN, они также отправляют свои данные через него. Таким образом, отправка и получение IP будут одинаковыми с точки зрения партнера. - person Steffen Ullrich; 27.01.2014
comment
Спасибо, Штеффен, за помощь. Если отправка и получение - это один и тот же IP-адрес, тогда должен быть туннель между двумя серверами очереди ... например, если A использует 1.2.3.4, а B использует 5.6.7.8, то A будет отправлять и получать данные от 1.2. 3.4 и B будут делать то же самое с 5.6.7.8. Так что должен быть туннель между 1.2.3.4 и 5.6.7.8 .. Я прав? - person user2139084; 27.01.2014
comment
Я бы не назвал это туннелем. Оба сервера TURN обмениваются данными для своих клиентов, используя общедоступные IP-адреса, как это делали бы сами клиенты SIP, если бы они не находились за NAT. - person Steffen Ullrich; 27.01.2014
comment
Как TURN-сервер узнает о существовании другого TURN-сервера, с которым он может обмениваться данными? Как он получает IP-адрес других серверов? - person user2139084; 27.01.2014
comment
см. шаг №3 и этап №4 в моем ответе - они оба обмениваются общедоступными адресами серверов TURN в своем теле SDP, а не своими частными адресами. И клиент №1 дает команду своей очереди №1 отправить данные в очередь №2, адрес которой он получил от клиента №2. - person Steffen Ullrich; 27.01.2014
comment
Ох :) понял .. Клиент создаст TURN-разрешение для TURN-адреса удаленной стороны, а НЕ для SRV-REFLEXIVE ADDRESS удаленной стороны. - person user2139084; 27.01.2014
comment
Мы не можем настроить оба конечных устройства на использование одних и тех же серверов TURN, поскольку они не зависят от выбора (настраиваются). Теперь, если они используют разные серверы, локальному устройству необходимо создать разрешения на своем сервере TURN. Должен ли он создавать разрешения для удаленного локального IP, удаленного IP-адреса с NAT, а также для удаленного Relayed IP? - person user2139084; 27.01.2014
comment
они используют разные серверы TURN во время обнаружения того, как подключаться друг к другу. Но если клиенту №1 удается подключиться напрямую к серверу TURN однорангового узла (поворот №2 по адресу №2), он автоматически устанавливает обратный туннель через свой NAT, и в этом случае они оба могут использовать один и тот же сервер TURN на повороте №2. - person Steffen Ullrich; 27.01.2014
comment
Спасибо за ответ. В этом случае клиент №2 должен создать разрешения для адреса NAT №1. И есть ли способ, которым мы можем решить использовать один из серверов TURN? И нужно ли нам создавать разрешения для адреса №2 (ретранслируемого адреса клиента №2) на ходу №1? - person user2139084; 27.01.2014
comment
клиент №1 сначала отправляет пакет на поворот №2, который будет отклонен, но открывает обратный туннель через NAT №1. Когда клиент №2 отправляет пакет через поворот №2 клиенту №1, это создает разрешение для клиента №1 отправлять пакеты обратно через поворот №2, и, таким образом, соединение устанавливается. Для поворота №1 не требуется создавать разрешения, потому что данные не проходят через него. Я не знаю, как он выбирает, какой из серверов TURN будет использоваться, но он должен быть определен в ICE, и пока каждый клиент может напрямую подключаться к одноранговому серверу TURN, это не имеет значения. - person Steffen Ullrich; 27.01.2014

arrow_upward
4
arrow_downward

Предположим, есть два сервера TURN. Используется клиентом 1 с IP 1.2.3.4. Другой используется клиентом 2 на IP 5.6.7.8. Оба сервера TURN прослушивают стандартный порт прослушивания 3478.

Допустим, во время сеанса согласования ICE или ICE-подобного клиенту 1 выделен порт 8888 на своем сервере TURN. Клиент 2 выделил порт 9999 на своем сервере TURN.

После отказа ICE, предполагая, что клиенты не могут подключиться напрямую, поток данных между обоими клиентами будет ОДИН из следующих

  • Клиент 1 отправляет пакеты данных (инкапсулированные внутри сообщения TURN) со своего локального порта на порт прослушивания сервера TURN (1.2.3.4:3478). Сервер TURN развернет этот пакет и перешлет сообщение со своего порта ретрансляции (8888) на адрес клиента 2. Данные, отправленные от клиента 2, будут отправлены как есть на порт ретрансляции на сервере TURN, выделенный клиентом 1. ( 1.2.3.4:8888). Когда сервер TURN получает дейтаграммы от клиента 2 на порт ретрансляции, он инкапсулирует пакет в сообщение TURN и пересылает его с порта 3478 на адрес клиента 1.

OR

  • Клиент 2 отправляет пакеты данных (инкапсулированные внутри сообщения TURN) со своего локального порта на порт прослушивания сервера TURN (5.6.7.8:3478). Сервер TURN развернет этот пакет и перешлет сообщение со своего порта ретрансляции (9999) на адрес клиента 1. Данные, отправленные от клиента 1, будут отправлены как есть на порт ретрансляции на сервере TURN, выделенный клиентом 2. ( 5.6.7.8:9999). Когда сервер TURN получает дейтаграммы от клиента 1 на порт ретрансляции, он инкапсулирует пакет в сообщение TURN и пересылает его с порта 3478 на адрес клиента 2.

Другими словами, если был выбран сервер TURN, одна сторона всегда будет отправлять / получать данные через порт 3478 TURN, используя протокол TURN в качестве инкапсулированных сообщений. Другая сторона всегда будет отправлять / получать пакеты (не инкапсулированные) на порт ретрансляции, выделенный другим клиентом. Как он решает, какой сервер TURN выбрать? В ICE это не всегда детерминировано.

В некоторых редких случаях это может быть «ПОВЕРНУТЬ в ПОВЕРНУТЬ». Оба клиента отправляют / получают данные с порта 3478 своего соответствующего сервера TURN. Серверы TURN пересылают данные на назначенный другому клиенту адрес ретрансляции. Это необычно, но может произойти, если все другие проверки кандидатов не пройдут во время согласования ICE.

person selbie    schedule 24.01.2014
comment
Спасибо, Селби, за ответ. У меня были некоторые сомнения. Если оба они находятся за NAT с ограниченным доступом к портам и адресам, обе проверки подключения не пройдут. Тогда оба будут одновременно отправлять мультимедиа на РЕЛЕЙНЫЙ АДРЕС удаленной стороны. Итак, адрес, на который мы отправляем медиа отличается от адреса, откуда мы будем получать медиа ?? тогда должны быть также значительные изменения в сигнализации. - person user2139084; 27.01.2014
comment
@ user2139084 - Если вы используете методологию ICE, они должны сходиться на один и тот же сервер TURN. Сервер TURN действует как NAT с ограничением по IP. Клиент 1 выполнит проверку подключения к общедоступному IP-адресу клиента 2 через реле TURN. Одновременно клиент 2 будет проверять подключение к АДРЕСУ РЕЛЕ порта 2. В конце концов, оба клиента узнают друг о друге. - person selbie; 27.01.2014
comment
Спасибо, Селби, за помощь. Я все еще запутался :) с некоторыми проблемами. Я объясню на примере. Если A находится за NAT 1.1.1.1 и использует сервер TURN 1.2.3.4, а B находится за NAT 2.2.2.2 и использует TURN сервер 5.6.7.8. Теперь предположим, что оба они находятся за NAT с ограничением адресов и портов, поэтому необходима ретрансляция мультимедиа. Теперь A будет отправлять и ожидать данные из 1.2.3.4, а B будет отправлять и ожидать данные из 5.6.7.8. Передача данных может происходить только в том случае, если 2-х ходовые серверы имеют промежуточное соединение. Как это обрабатывается ???? - person user2139084; 27.01.2014
comment
Как им подключиться к одному серверу TURN? Серверы TURN настраиваются на каждом клиенте (см. ICE RFC5245, 20.5 Конфигурация конечной точки) и могут быть предложены их поставщиками VoIP. И я не вижу механизма, указанного в том, как они организуют использование одного и того же сервера TURN. - person Steffen Ullrich; 27.01.2014
comment
Меня беспокоит то, что если оба устройства поддерживают TURN, то к 1. куда A будет отправлять данные? (TURN-сервер A или TURN-сервер B) 2. откуда B будет получать данные? (TURN-сервер A или TURN-сервер B) 3. Куда B будет отправлять данные? (TURN-сервер A или TURN-сервер B) 4. Откуда B будет получать данные (TURN-сервер A или TURN-сервер B) .. Я думаю, это разрешит мои сомнения. - person user2139084; 27.01.2014
comment
@SteffenUllrich - начните с чтения некоторых руководств Розенберга по ICE здесь: jdrosen.net/tutorials.html (Прокрутите вниз до середины страницы, чтобы увидеть два набора учебных слайдов ICE). - person selbie; 27.01.2014
comment
@ user2139084 - То же самое. Рассмотрите возможность чтения руководств по ICE. Свяжите комментарий над этим. - person selbie; 27.01.2014
comment
@selbie - ты прав. В обычном случае они могут разговаривать, используя один и тот же сервер TURN, только если они находятся за каким-то ограниченным брандмауэром, им нужны два сервера TURN. Я соответствующим образом скорректировал свой ответ. - person Steffen Ullrich; 27.01.2014
comment
@SteffenUllrich - бывают странные случаи, когда оба сервера TURN используются в сеансе. Например, когда оба клиента находятся за брандмауэром, работающим только по протоколу HTTP, и единственное соединение, которое у них действительно есть, - это их собственный адрес сервера TURN. - person selbie; 27.01.2014
comment
Да, как с WebRTC за брандмауэрами, где они пытаются использовать TURN через туннель CONNECT или с помощью WebSockets. Страшные штуки :) - person Steffen Ullrich; 27.01.2014