Как работает ICE протокол и зачем он нужен для FAF – Top Supreme Commander
ICE: создание интерактивного соединения
Протокол создания интерактивного соединения (Interactive Connectivity Establishment – ICE) используется для обхода NAT. ICE использует комбинацию методов, включая Утилиту обхода сеанса для NAT (STUN) и Обход посредством ретрансляции NAT (TURN). Наличие транслятора сетевых адресов (NAT) является одной из известных проблем для реализации Передачи голоса по IP (VoIP) и WebRTC.
ICE Примеры
Рассмотрим пример использования протокола инициации сеанса (Session Initiation Protocol – SIP), когда устройство SIP с пользователем Петей находится за NAT / Firewall и хочет зарегистрировать свое нахождение у регистратора SIP, находящегося в общедоступном Интернете. Устройство SIP имеет не маршрутизируемый частный IP-адрес 192.168.0.10. Устройство SIP регистрирует свое нахождение у регистратора как sip:[email protected]:5060. Это сообщает регистратору, что с Петей можно связаться по IP-адресу 192.168.0.10 через порт 5060 (порт SIP по умолчанию). Этот частный IP-адрес не имеет смысла для устройства в общедоступном Интернете, и регистратор не знает, как связаться с Петей.
Второй пример связан с проблемами при отправке мультимедиа в реальном времени (RTP). Аня звонит Пете, а приглашение Ани содержит протокол описания сеанса (SDP) со своим локальным IP-адресом 10.1.1.10 и медиа-портом 1234. Петя принимает приглашение Ани со своим SDP, содержащим его локальный IP-адрес 192.168.0.10 и медиа-порт 1234. Оба этих IP-адреса адреса не имеют смысла вне области частной локальной сети каждого человека, и ни одна из сторон не получит пакеты RTP другой стороны.
На рисунке 1 показано типичное развертывание ICE с двумя Пользовательскими агентами (далее ПА (User Agent) – под пользовательским агентом подразумевается устройство либо программное обеспечение для передачи сообщений), связывающимися посредством SIP (или другой сигнальный протокол, который выполняет обмен предложение/ответ для сообщений в формате протокола SDP). ICE использует SIP, что означает, что прохождение SIP через NAT должно обеспечиваться другим механизмом. ICE позволяет ПА, которые изначально не знают своих топологий, узнавать достаточно информации о топологии для поиска путей связи.
Два ПА находятся за NAT с неизвестными свойствами. Они способны обмениваться сообщениями SDP через обмен предложение/ответ, используемый для настройки медиа-сеансов между ПА через SIP-сервер. В дополнение ICE использует сервер(ы) STUN / TURN, каждый ПА может иметь свой собственный либо они используют один тот же сервер STUN / TURN. Оба ПА имеют список транспортных адресов, которые могут использоваться для связи с другим агентом. ICE используется для обнаружения адресов которые могут соединяться друг с другом, а также методов используемых для их соединения через NAT.
Для выполнения ICE соединения каждому ПА необходимо идентифицировать все адреса-кандидаты, транспортные адреса. Транспортные адреса представляют собой комбинацию IP-адреса и порта для определенного транспортного протокола. Есть три типа кандидатов:
Host Candidate – транспортный адрес, связанный с локальным интерфейсом ПА
Relayed Candidate – транспортный адрес, связанный с сервером TURN (может быть получен только от сервера TURN)
Server Reflexive Candidate – преобразованный адрес на общедоступной стороне NAT (полученный от сервера STUN или сервера TURN)
На рисунке 2 показана связь этих кандидатов с ПА.
После того как ПА1 собрал всех своих кандидатов, он упорядочивает их в порядке приоритета от высшего к низшему и отправляет их ПА2 в атрибутах в сообщении предложения SDP. ПА2 выполняет тот же сбор кандидатов и отправляет ответ SDP со своим списком кандидатов. Каждый ПА берет два списка кандидатов и попарно создает из них пары-кандидаты. Каждый ПА собирает их в контрольные списки и планирует проверки соединения, транзакции в виде запрос/ответ STUN, чтобы узнать какие пары-кандидаты работают. На рисунке 3 показаны компоненты пар-кандидатов, которые составляют контрольный список ПА.
Результатом тестирования обоих агентов является четырехстороннее рукопожатие на тех же самых портах, которые будут использоваться для передачи медиа. На рисунке 4 показана базовая проверка подключения.
ICE назначает одного из агентов в качестве «Контролирующего агента», а другого – в качестве «Контролируемого агента». Контролирующий агент использует действительные пары кандидатов для назначения пары, по которой будет осуществляться передача медиа. Есть два метода назначения, которые можно использовать:
Regular Nomination Постоянное назначение – проверки продолжаются до тех пор, пока не найдется хотя бы одна действительная пара кандидатов. Контролирующий агент выбирает из допустимых пар и отправляет второй запрос STUN для этой пары с флагом сообщающем партнеру, что это тот, который назначен для использования.
Aggressive Nomination Агрессивное назначение – флаг назначения отправляется с каждым запросом STUN, как только первая проверка успешно завершена, обработка ICE для этого медиапотока считается завершенной, и второй запрос STUN не требуется.
На рисунке 5 показан пример обоих вариантов назначения.
Каждая пара кандидатов в контрольном списке имеет связанное с ней состояние. Состояние присваивается агентом ПА после расчета контрольного списка. Есть пять возможных состояний:
Frozen (Заморожено) – Эту пару можно проверить только после перевода в состояние ожидания. Чтобы войти в состояние ожидания, сначала должна пройти другая проверка
In-Progress (Выполняется) – Проверка была отправлена для этой пары, и транзакция в процессе выполнения
Succeeded (Успешно) – Успешный результат проверки пары
Failed (Провалено) – Неудачный результат проверки пары
На рисунке 6 показана диаграмма состояний для пар-кандидатов.
На рисунке 7 показана упрощенная топология, которую мы будем использовать в примере коммуникационного потока ICE. Оба ПА используют ICE и агрессивное назначение, если они контролеры. Оба случая просто используют один и тот же сервер STUN (который не требуется, но показан в этом примере для простоты), который прослушивает запросы привязки STUN. ПА1 находится за NAT, который имеет свойство отображения, независимое от конечной точки, и свойство фильтрации, зависящее от адреса.
На рисунке 8 показан поток для этого примера коммуникационного потока ICE. После получения хоста-кандидата с его локального IP-адреса ПА1 отправляет запрос привязки STUN для получения рефлексивного кандидата (сообщения с 1 по 4). NAT создает привязку для запроса, который становится рефлексивным кандидатом сервера для RTP. Используя сервер рефлексивный кандидат ПА1 отправляет сообщение-предложение на ПА2 (сообщение 5). ПА2 приступает к получению рефлексивного сервер-кандидата (сообщения 6 и 7), который идентичен хосту-кандидату, поскольку он не находится за NAT. Избыточный кандидат отбрасывается, оставляя только хост-кандидат. Поскольку ПА1 начал коммуникацию, он считается контролирующим, а ПА2 – контролируемым. ПА2 пытается проверить подключение, но поскольку он контролируется, он не имеет надлежащих атрибутов для достижения ПА1 через NAT, поэтому запрос отбрасывается (сообщение 9). ПА1, являясь контролирующей стороной, имеет атрибут для прохождения через устройство NAT с его агрессивной проверкой подключения STUN для назначения (сообщения с 10 по 13). После получения запроса привязки STUN с агрессивным назначением, ПА2 выполняет проверку соответствия, используя атрибут из запроса привязки STUN ПА1 для проверки соединения (сообщения с 14 по 16). На этом этапе оба ПА удостоверяются, что соединение является действующим, и оно было назначено для использования в этом медиапотоке. Оба ПА теперь могут отправлять медиа через это соединение.
Итак, ознакомившись с протоколом ICE более подробно можно посмотреть, каким образом клиент FAF использует данный протокол, чтобы обеспечивать игроков наиболее стабильным соединением и создавать комфортные условия для игры.
Автор: MikZZ
Редактор: Vast
Источник:
ICE: Interactive Connectivity Establishment
Вконтакте
Google+
Обзор протоколов STUN, TURN и ICE, их принципы работы с NAT и использование для VoIP – Voxlink
Введение
При работе с IP-телефонией постоянно приходится сталкиваться с разного рода задачами связанными с сетью, т.к. эти области неразрывно связаны. В данной обзорной статье рассматриваются протоколы STUN и ICE, их методы работы с NAT и практическое применение в работе с VoIP.
Протокол STUN
Название протокола – аббревиатура, можно расшифровать как Simple Traversal of UDP tрrough NAT или же по-русски «Простое прохождение UDP через NAT». Почему он нам интересен? Причина проста: как правило, многие устройства, работающие по SIP’у, будь то голосовые шлюзы, ip-телефоны, софтфоны или же сами сервера с телефонии, по большей степени скрыты за NAT’ом. Это обусловлено по большей степени принципами безопасности и грамотной логикой построения сетей. Но периодически из-за этого возникают различные неприятные ситуации с прохождением, например, голосового потока. Для решения подобных проблем и был разработан этот STUN. Его основное назначение – дать возможность различным девайсам (за NAT’ом) узнать их public IP-адрес и найти пробросы портов. Как правило, STUN использует 3478 порт, которому обращается клиент (протокол является клиент-серверным).
Как это работает:
Устройством отправляется запрос к public IP STUN-сервера через маршрутизатор (шлюз), он, в свою очередь, перенаправляет его на STUN-сервер с внешним IP на порт 3478, ну а сервер отвечает устройству через маршрутизатор, сообщая, что запрос был сделан с внешнего IP маршрутизатора с определенного порта. Схема для наглядности:
Схема отправки запроса STUN-серверу и ответВ протоколе STUN реализован механизм, позволяющий определить наличие более одного NAT’a в сети
В дополнение к использованию шифрования протокола с TLS, STUN также имеет встроенные механизмы аутентификации и целостности сообщений через специальные типы пакетов.
Протокол STUN очень плохо работает с симметричным NAT’ом (и сервер и клиент находятся за NAT). Это основная причина разработки протокола TURN
Протокол TURN
Теперь немного о протоколе TURN. Расшифровка названия – Traversal Using Relays around NAT. Предназначается для работы с симметричным NAT’ом. Использует сервер для передачи данных от клиента (как и STUN является клиент-серверным протоколом) любому количеству устройств (пиров).
Принцип работы – грубо говоря, разбиение симметричного NAT на два не симметричных. А теперь немного подробнее:
Клиент с TURN-агентом отправляет сообщение на TURN-сервер для того, чтобы задетектить public IP-адрес (по аналогии со STUN), но вместо этого TURN-сервер посылает свои IP и порт. Клиент, как только получил от TURN-сервера данные, посылает их пиру. По тому же принципу работает и с противоположной стороны. Итогом получаем что голосовой и сегнальный трафик ходит через TURN-сервер (проксирование).
Изобразим этот процесс схематично для большей наглядности:
Схема работы TURNПротокол TURN по сути своей является дополнением протокола STUN.
Протокол ICE
Interactive Connection Establishment (интерактивное установление соединение) – это еще одно дополнение (суб-протокол) к протоколам STUN и TURN. Основное назначение:
- Собрать данные об интерфейсах
- Проверить удаленные сервера STUN
- Проверить удаленные сервера TURN
- Проверить возможность установления соединения
Принцип работы довольно прост и тривиален: протокол последовательно собирает данные о возможности создания локального соединения между устройствами (пирами) по TCP или UDP. Если такой возможности нет, он проверяет возможность использования STUN во внешней сети, если и такой возможности не обнаруживается, ICE проверяет возможность использовать TURN во внешней сети (в том числе и проверяет доступность подключения к нескольким ближайшим TURN-серверам). После окончания сбора информации о структуре окружающей клиента сети, им (клиентом, создающим сессию) отправляется сообщение на TURN-сервер, содержащее полученную архитектуру ближайшей сети, а так же кидает запрос на создание сессии для пира, хранящий пачку IP-адресов, которые знает клиент. Пир соответственно отвечает множественными STUN-сообщениями по каждому из IP. Рано или поздно, хотя бы одно из сообщений прилетит инициатору сессии, проскочив сквозь NAT. Как только клиент ответит на все такие сообщения, у пира появится карта сети по которой будет выбираться самый легкий для прохождения маршрут (этот процесс называется процедура номинирования пар) и выполняться проверка доступности между пиром и клиентом (могут ли они достучаться друг до друга). Приоритезация такая: без STUN – самый высокий приоритет, с использованием STUN – пониже, с TURN’ом – самый низкий. Ну и в конечном итоге, устанавливается соединение.
Логика ICE
Схема работы ICEПротокол ICE не актуален для IPv6
Стоит отметить, что протокол ICE не очень подходит для ряда решений:
- Если у нас большой прак оборудования
- Если мы ведем запись на проксирующем сервере
- Если у нас сложная структура сети с пересекающимися подсетями
- Если очень критично время установки соединения
У протокола ICE есть расширение под названием Trickle ICE реализующее выполнение механизмов протокола асинхронно, что в разы повышает скорость работы ICE-агента.
Вывод
В процессе изучения протоколов пришел для себя к выводу, что хоть ICE и считается довольно сильным протоколом, по сути своей, делающим всю грязную работу за STUN и TURN, его использование не всегда уместно и оправданно, стоит выбирать, каким из трех протоколов пользоваться, в зависимости от ситуации и поставленной задачи.
Interactive Connectivity Establishment (ICE) в Asterisk
Обзор
Если сервер Asterisk (или любой другой VoIP сервер) напрямую доступен из сети Интернет и вызывается SIP софтфоном или устройством, вполне вероятно все будет работать «из коробки».
Тоже самое и с конфигурацией, когда сервер и телефоны находятся в локальной сети.
Если же хост А и хост В находятся за NAT, а и тот, и другой нуждаются в связи друг с другом в режиме реального времени, все может сильно осложнится.
Если сети крайне просты, относительно статичны и NAT доступен для простой настройки, эту проблему можно успешно разрешить пробросом портов или включением режима DMZ.
Однако, если появляются, хотя бы, небольшие сложности, прохождение RTP трафика может стать весьма проблематичным. (это точно, блин)
Расхожие примеры этого: двойной NAT, динамические IP адреса, файерволлы в высоким уровнем запретов, сетевые узлы модифицирующие sip запросы.
Зачастую доступ к конфигурации мешающих прохождению трафика устройств, попросту невозможен. (да, что мне вам рассказывать…)
Проблема является очень распространенной и каждый из VoIP сообщества сталкивался с проблемами, требующими больших трудозатрат для их решения.
Interactive Connectivity Establishment протокол, или ICE, является относительно новым и перспективным решением подобных проблем.
Поддержка ICE добавлена в Asterisk c версии 11.
ICE это стандартизированный механизм для управления медиа потоками в режиме реального времени, между программными агентами запущенными за NAT.
Установление соединений через NAT называют «прохождением NAT».
Для достижения этого протокол ICE использует следующие механизмы:
Совместно с использованием STUN или TURN сервера, ICE найдет способ пройти NAT, если только способ существует.
Настройка ICE поддержки в Asterisk
Включение ICE поддержки
Поддержка ICE в Asterisk включена глобально по умолчанию,
однако ВЫКЛЮЧЕНА в настойках chan_sip и включается в секции [general] глобально, или в настройках пиров для конкретного канала, в конфигурационном файле «sip.conf».
icesupport=yes
Как уже говорилось ICE нуждается в подключении STUN и/или TURN серверов для подбора возможных кандидатов
However, as ICE needs a STUN and/or TURN server to gather usable candidates, они обязательно должны быть настроены, чтобы все заработало.
Т.к. ICE это RTP механизм, настройка производится в файле «rtp.conf».
Настройки будут распространяться на все связи с RTP, т.к. функции расположены в общем [general] разделе
Для указания STUN сервера назначьте опцию ‘stunaddr’ c именем хоста STUN сервера.
Например:
stunaddr=stun.hostname
Список публичных STUN серверов можно найти на VoIP-Info’s STUN странице.
TURN сервер требуется для кандидатов-ретрансляторов и настраивается через ‘turnaddr’ свойство. TURN сервер часто требует аутентификации и опционально настройки могут содержать username и password.
turnaddr=4everyseason.turn.org
turnusername=relayme turnpassword=please
‘Turnport’ используется, если TURN сервер запущен на нестандартном порту. Если пропущено, Asterisk использует стандартный порт: 3478. Успешная конфигурация визуально подтверждается SIP дебагом (sip set debug on).
0:v=0 1:o=root 803380323 803380323 IN IP4 123.123.123.1 2:s=Asterisk PBX 12.1.1 3:c=IN IP4 123.123.123.1 4:t=0 0 5:m=audio 12444 RTP/AVP 0 8 101 6:a=rtpmap:0 PCMU/8000 7:a=rtpmap:8 PCMA/8000 8:a=rtpmap:101 telephone-event/8000 9:a=fmtp:101 0-16 10:a=ptime:20 11:a=maxptime:150 12:a=ice-ufrag:2ab7c3406739799a09fd6eca5bdb9a11 13:a=ice-pwd:15aa3c9900949e9b3991cbaa4b283096 14:a=candidate:Hc0a800f8 1 UDP 2130706431 192.168.0.248 12444 typ host 15:a=candidate:Sc390f435 1 UDP 1694498815 123.123.123.1 12444 typ srflx 16:a=candidate:Hc0a800f8 2 UDP 2130706430 192.168.0.248 12445 typ host 17:a=candidate:Sc390f435 2 UDP 1694498814 123.123.123.1 12446 typ srflx 18:a=sendrecv
В строках с 12-й по 17-ю содержится ICE инфа.
Строки 12 и 13 генерируются автоматически и используются для идентификации конечных точек в сессии ICE.
Строки с 14-й по 17-ю содержат примеры кандидатов.
Строки 15-я и 17-я являются примером обратного адреса сервера кандидата(внешний адрес маршрутизатора), на что указывает «type srflx» маркер в конце строки.
Обратный адрес сервера получается через STUN и указывает на внешний файервол.
Здесь их два, потому что один для RTP, а второй для RTCP пакетов.
На это указывает id , 1 для RTP и 2 для RTCP во втором поле строки кандидатов.
Строки кандидатов отмечены в конце как «typ host» указывают на кандидатов из локальной сети (локальный адрес Asterisk).
stun debug
stun set debug on
STUN Debugging Enabled STUN Packet, msg Binding Response (0101), length: 68 Found STUN Attribute Mapped Address (0001), length 8 Ignoring STUN attribute Mapped Address (0001), length 8 Found STUN Attribute Source Address (0004), length 8 Ignoring STUN attribute Source Address (0004), length 8 Found STUN Attribute Changed Address (0005), length 8 Ignoring STUN attribute Changed Address (0005), length 8 Found STUN Attribute Non-RFC3489 Attribute (8020), length 8 Ignoring STUN attribute Non-RFC3489 Attribute (8020), length 8 Found STUN Attribute Non-RFC3489 Attribute (8022), length 16 Ignoring STUN attribute Non-RFC3489 Attribute (8022), length 16 Dunno what to do with STUN message 0101 (Binding Response) == Using SIP RTP TOS bits 184 == Using SIP RTP CoS mark 5
Отключение ICE
Генерацию списков SDP для ICE можно выключить:
icesupport=no
в [general] разделе «sip.conf» или в настройках пиров. Т.к. ICE управляет RTP потоками, ICE элементы настройки указываются в «rtp.conf» файле. Для выключения поддержки ICE RTP функций, добавьте ту же команду в «rtp.conf».
Настройка Asterisk
networking — Почему WebRTC нуждается в протокол ICE работать?
NAT является ляп, поставить на место , чтобы попытаться сохранить адреса IPv4 до IPv6 становится повсеместным, и она разрывает соединение конца в конец , который является обещание IP. Из — за этого, некоторые вещи не корректно работать через NAT. Существуют различные кладжи для работы вокруг NAT ляп, и ICE является частью этого процесса . Это объясняется в RFC 5245, Interactive Connectivity Создание (ICE): Протокол для сетевых адресов (NAT) Traversal для предложения / Ответ протоколов :
- Введение
RFC 3264 [ RFC3264 ] определяет обмен на два-фазовую Session Description Protocol (SDP) сообщений [ RFC4566 ] в целях создания мультимедийных сессий. Этот механизм предложение / ответ используется протоколами , такими как Session Initiation Protocol (SIP) [ RFC3261 ].
Протоколы , использующие предложение / ответ трудно работать через сеть адресов (NATs). Потому что их цель состоит в том, чтобы создать поток пакетов медиа, они имеют тенденцию нести IP — адреса и порты медиа — источников и поглотителей в пределах своих сообщений, которые , как известно, проблематично через NAT [ RFC3235 ]. Протоколы также стремятся создать поток медиаданного непосредственно между участниками, так что нет никакого прикладного уровня посредника между ними. Это сделано , чтобы уменьшить задержку средств массовой информации, уменьшить потери пакетов, а также снизить эксплуатационные расходы , связанные с развертыванием приложения. Однако это трудно осуществить через NAT. Полное лечение причин этого выходит за рамки данной спецификации.
Многочисленные решения были определены для этих протоколов для работы через NAT. Они включают в себя слой приложений Шлюзов (ALG) протокол управления Middlebox [ RFC3303 ], оригинальный Simple Traversal из UDP через NAT (STUN) [ RFC3489 ] спецификацию и Realm Specific IP [ RFC3102 ] [ RFC3103 ] , а также описание сеанса расширения , необходимые для заставить их работать, например, Session Description Protocol (SDP) [ RFC4566 ] атрибут для протокола управления в реальном времени (RTCP) [ RFC3605]. К сожалению, эти методы все имеют свои плюсы и минусы, которые делают каждый один оптимальный в некоторых сетевых топологий, но плохой выбор в других. Результат является то, что администраторы и разработчики делают предположения о топологии сети, в которой будет размещено их решение. Это вносит сложность и хрупкость в систему. Что нужно, это единственное решение, что является достаточно гибкой, чтобы работать хорошо во всех ситуациях.
Эта спецификация определяет Interactive Connectivity Создания (ICE) в качестве методики для обхода NAT для мультимедийных потоков UDP на основе (хотя ICE может быть расширен , чтобы обрабатывать другие транспортные протоколы, такие как TCP [ ICE-TCP ]) , установленные моделями предложения / ответа. ICE является продолжением модели предложения / ответа, и работает, в том числе множества IP — адресов и портов в SDP предложений и ответах, которые затем испытаны для подключения по равноправным узлам проверки подключения. IP — адрес и порты , включенные в SDP и проверка подключения выполняется с использованием пересмотренной спецификации STUN [ RFC5389], В настоящее время переименован в Session Traversal Utilities для NAT. Новое имя и новая спецификация отражают ее новую роль в качестве инструмента , который используется с другими методами прохождения NAT (а именно ICE) , а не отдельным NAT решением обхода, так как первоначальная спецификация STUN было. ICE также использует Traversal Использование реле вокруг NAT (TURN) [ RFC5766 ], расширение к STUN. Поскольку ICE обмены множественность IP — адресов и портов для каждого мультимедийного потока, она также дает возможность выбора адреса для многосетевых и хостов стеки двух-, и по этой причине она осуждает RFC 4091 [ RFC4091 ] и [ RFC4092 ].
Почему для работы WebRTC необходим протокол ICE?
Насколько я понимаю, протокол ICE используется для обнаружения узлов / устройств от устройства конечного пользователя до «the outside».
Я не понимаю, зачем это нужно. Разве маршрутизация пакетов не является обязанностью сетевых устройств, таких как маршрутизаторы и коммутаторы? Они должны найти кратчайший путь от шлюза до устройства конечного пользователя (на самом деле маршрутизаторы запоминают те маршруты, которые они ранее обнаружили).
Кроме того, протокол NAT используется для преобразования из «internal ip» в «external ip» и наоборот.
Ну вот опять,
Почему другой пользователь должен быть знаком с моей внутренней сетевой настройкой?
Поделиться Источник Elimination 03 октября 2016 в 19:33
2 Ответа
4
NAT — это Клудж, созданный для того, чтобы попытаться сохранить адреса IPv4 до тех пор, пока IPv6 не станет повсеместным, и это нарушает связь end-to-end, которая является обещанием IP. Из-за этого некоторые вещи не работают правильно через NAT. Есть различные kludge для работы вокруг NAT kludge, и ICE является частью этого. Это объясняется в RFC 5245, Interactive Connectivity Establishment (ICE): протокол для обхода транслятора сетевых адресов (NAT) для протоколов предложений / ответов :
- Вступление
RFC 3264 [ RFC3264 ] определяет двухфазный обмен описанием сеанса Протокол (SDP) сообщения [ RFC4566 ] для целей установления мультимедийные сессии. Этот механизм предложения / ответа используется протоколами например, протокол инициирования сеанса (SIP) [ RFC3261 ].
Протоколы, использующие предложение / ответ, трудно работать через сеть Переводчики Адресов (NATs). Потому что их цель состоит в том, чтобы установить поток пакетов media, они, как правило, несут адреса IP и порты из media источников и приемников в их сообщениях, которые, как известно, являются проблематично через NAT [ RFC3235]. Протоколы также стремятся создать a media поток непосредственно между участниками, так что нет посредник прикладного уровня между ними. Это делается для уменьшения media задержка, уменьшение потери пакетов и снижение эксплуатационных расходов развертывания приложения. Тем не менее, это трудно сделать выполнить через NAT. Полная трактовка причин этого есть выходит за рамки данной спецификации.
Были определены многочисленные решения, позволяющие этим протоколам действуйте через NAT. К ним относятся шлюзы прикладного уровня (ALGs), протокол управления Middlebox [RFC3303 ], оригинал простой Обход спецификации UDP-NAT (STUN) [ RFC3489 ] и Realm Специфический IP [ RFC3102 ] [ RFC3103 ] вместе с описанием сеанса расширения, необходимые для их работы, такие как описание сеанса Атрибут протокола (SDP) [ RFC4566 ] для протокола управления в реальном времени (RTCP) [ RFC3605]. К сожалению, все эти методы имеют свои плюсы и минусы. минусы, которые делают каждый из них оптимальным в некоторых сетевых топологиях, но a плохой выбор у других. В результате получается, что администраторы и разработчики делают предположения о топологиях сети, в которых будут развернуты их решения. Это вводит сложность и хрупкость в системе. Нужен единое решение, которое является достаточно гибким, чтобы хорошо работать во всех положения.
Эта спецификация определяет установление интерактивного подключения (ICE) как метод для обхода NAT для потоков UDP на основе media (хотя ICE может быть расширен для обработки других транспортных протоколов, таких как as TCP [ ICE-TCP ]) устанавливается моделью предложения / ответа. ICE — это расширение модели предложения / ответа и работает путем включения множественность адресов и портов IP в предложениях и ответах SDP, которые затем проверяются на подключение по peer-to-peer подключения проверяет. Адреса и порты IP, включенные в SDP и проверки подключения выполняются с использованием пересмотренной спецификации STUN [ RFC5389 ], теперь переименован в утилиты обхода сеансов для NAT. То новое имя и новая спецификация отражают его новую роль как инструмента, который является используется с другими методами обхода NAT (а именно ICE), а не a автономное решение для обхода NAT, как и исходная спецификация STUN был. ICE также использует обход с использованием реле вокруг NAT (TURN) [ RFC5766 ], расширение на STUN. Потому что ICE обменивается кратностью из IP адресов и портов для каждого потока media он также позволяет выбор адреса для многосетевых и двухстековых хостов, а также для этого причина он осуждает RFC 4091 [ RFC4091 ] и [ RFC4092 ].
Поделиться Ron Maupin 03 октября 2016 в 19:47
2
Брандмауэры. Они, как правило, настроены на отказ от любого незапрошенного трафика из всемирной паутины к вам. Они только одобряют, что вы инициируете контакт с сервером, который только тогда разрешен для обратного трафика к вам, и это в значительной степени так. Если ваши друзья не владеют статическим IPs (что мало кто может оправдать), это враждебная среда для однорангового общения.
ICE пытается решить эту проблему, перечисляя адреса и порты, по которым может быть достигнута другая сторона, и пытаясь подключиться к этим адресам, инициируя исходящие запросы на обоих концах, или если все остальное не удается, возвращаясь к связи через сервер TURN, если указано.
Смотрите эту статью WebRTCHacks для получения дополнительной информации о проблеме.
Почему другой пользователь должен быть знаком с моей внутренней сетевой настройкой?
Потому что другой пользователь иногда находится в вашей внутренней сети. например, LAN игр.
Поделиться jib 03 октября 2016 в 22:55
Похожие вопросы:
WebRTC — TURN и ICE функции
Я пытаюсь понять концепцию WebRTC. Как я нашел в некоторых описаниях (например, здесь http://www.innoarchitech.com/content/images/2015/02/webrtc-complete-diagram.png ), есть такой способ…
Получение работы WebRTC (как отладить сбой ICE?)
Я не могу понять, как отлаживать WebRTC. Я продолжаю получать ошибки ‘ICE Failed’, но я сомневаюсь, что это проблема. Вот мой код:…
Расположение серверов WebRTC Ice
В настоящее время у меня есть 2 сервера ice-STUN (от Google) и один сервер TURN (в US). Если я добавлю больше серверов ice (к массиву серверов ice, переданному в одноранговое соединение) из разных…
Необходим ли ICE для клиент-серверных приложений WebRTC?
У меня есть MCU WebRTC ( kurento ), работающий на публичном адресе IP обслуживание некоторых клиентов, которые только отправляют или только получают аудио Таким образом, каждый клиент напрямую…
WebRTC «ICE Failed», ошибка
Итак, я пытаюсь создать веб-приложение webrtc video chat с использованием peer.js . Пока все хорошо, кажется, все работает правильно. Проблема начинается, когда я запускаю свое приложение на своем…
Webrtc добавление кандидата ice к удаленному узлу
Ниже приведен пример кода однорангового соединения webrtc от google webrtc tutorilal. эта ссылка. Я не мог правильно понять, как addIceCandidate() добавляет своего кандидата Ice к своему удаленному…
В WebRTC, какой ICE кандидат создал успешное соединение?
Я хочу знать, какой кандидат ICE создал успешное соединение и используется для передачи данных между сверстниками. Я хочу иметь возможность отличить локальное (хостовое) соединение от рефлексивного…
WebRTC, подключение ICE-кандидатов
Я пытаюсь узнать, как использовать webRTC в приложениях, поэтому я написал пример кода, доступный по следующей ссылке: http://wklej.org/hash/fd599a32e8e / В начале мне нужно сказать, что я не…
Как разработать приложение WebRTC для начинающих?
Я новичок в WebRTC. Я хорошо знаю ICE/STUN/TURN. Я хочу разработать приложение WebRTC, используя мои реализации ICE/STUN/TURN, которые были реализованы в C++. Может ли библиотека C++ использоваться…
Как WebRTC коллег инициировать ICE перезагрузить одновременно
Я довольно новичок в webRTC. Проблема относится к перезапуску ICE. Допустим, есть 2 узла, подключенные с помощью webRTC, и один из них теряет соединение. Теперь одноранговое соединение сначала…
Почему WebRTC нуждается в протоколе ICE?
Вопрос:
Насколько я понимаю, ICE-протокол используется для обнаружения узлов/устройств от конечного пользователя до «снаружи».
Я не понимаю, зачем это нужно. Не является ли маршрутизация пакетов ответственностью сетевых устройств, таких как маршрутизаторы и коммутаторы? Они должны найти кратчайший путь от шлюза до конечного пользователя (на самом деле, маршрутизаторы помнят те маршруты, которые они ранее обнаружили).
Кроме того, протокол NAT используется для преобразования из «внутреннего ip» в «внешний ip» и наоборот.
Итак, снова,
Почему другой пользователь должен быть знаком с моей внутренней настройкой сети?
Лучший ответ:
брандмауэров. Они, как правило, настроены на откат любого нежелательного трафика из всемирной сети. Они только одобряют, что вы инициируете контакт с сервером, которому только тогда разрешен обратный трафик для вас, и это в значительной степени. Если ваши друзья не имеют собственных статических IP-адресов (это мало кто может оправдать), это враждебная среда для одноранговой связи.
ICE пытается решить эту проблему, перечисляя адреса и порты, на которых может быть достигнута другая сторона, и пытается подключиться к этим адресам, инициируя исходящие запросы на обоих концах или если все остальное не работает, возвращается к общению через сервер TURN, если указан.
Подробнее об этой проблеме см. статью WebRTCHacks.
Почему другой пользователь должен быть знаком с моей внутренней настройкой сети?
Потому что другой пользователь иногда находится в вашей внутренней сети. например LAN.
Ответ №1
NAT — это kludge, поставленный на место, чтобы попытаться сохранить адреса IPv4 до тех пор, пока IPv6 не станет повсеместным, и он сломает сквозную связь, которая является обещанием IP. Из-за этого некоторые вещи не работают должным образом через NAT. Существуют различные kludges для работы с NAT kludge, и ICE является частью этого. Это объясняется в RFC 5245, Интерактивное подключение (ICE): Протокол для трансляции сетевых адресов (NAT) для протоколов предложения/ответа:
RFC 3264 RFC3264] определяет двухфазный обмен описанием сеанса Протокол (SDP) [RFC4566] для целей создания мультимедийные сеансы. Этот механизм предложения/ответа используется протоколами таких как протокол инициации сеанса (SIP) [RFC3261].
Протоколы с использованием предложения/ответа с трудом работают через сеть Адресные переводчики (NAT). Поскольку их целью является создание поток пакетов мультимедиа, они, как правило, несут IP-адреса и порты источников и поглотителей в сообщениях, которые, как известно, проблематично через NAT [RFC3235]. Протоколы также направлены на создание поток средств массовой информации непосредственно между участниками, так что нет промежуточный уровень между ними. Это делается для уменьшения латентность мультимедиа, снижение потерь пакетов и снижение эксплуатационных расходов развертывания приложения. Однако это трудно совершать через NAT. Причиной этого является полное рассмотрение выходит за рамки этой спецификации.
Были определены многочисленные решения, позволяющие этим протоколам работать через NAT. К ним относятся шлюзы уровня приложений (ALG), Протокол управления Middlebox [RFC3303], оригинальный Simple Обход UDP через NAT (STUN) [RFC3489] спецификация и область Конкретный IP [RFC3102] [RFC3103] наряду с описанием сессии расширения, необходимые для их работы, такие как описание сеанса Протокол (SDP) [RFC4566] для протокола реального времени (RTCP) [RFC3605]. К сожалению, у этих методов есть плюсы и минусы которые делают каждый из них оптимальным в некоторых сетевых топологиях, но плохой выбор в других. В результате администраторы и разработчики делают предположения о топологиях сетей, в которых их решения будут развернуты. Это вводит сложность и хрупкость в системе. Нужно одно решение, достаточно гибкое, чтобы хорошо работать во всех ситуации.
В этой спецификации определено Интерактивное подключение. (ICE) как метод обхода NAT для медиапотоков на основе UDP (хотя ICE может быть расширен для обработки других транспортных протоколов, таких как как TCP [ICE-TCP], установленный моделью предложения/ответа. ICE — это расширение модели предложения/ответа и работает, включая множественность IP-адресов и портов в предложениях и ответах SDP, которые затем проверяются на подключение путем одноранговой связи чеки. IP-адреса и порты, включенные в SDP и проверки связи выполняются с использованием пересмотренной спецификации STUN [RFC5389], теперь он переименован в Утилиты трассировки сеанса для NAT. новое имя и новая спецификация отражают его новую роль как инструмента, который используется с другими методами обхода NAT (а именно ICE), а не с автономное решение обхода NAT, в качестве исходной спецификации STUN был. ICE также использует Traversal, используя реле вокруг NAT (TURN) [RFC5766], расширение для STUN. Поскольку ICE меняет множественность IP-адресов и портов для каждого медиапотока, это также позволяет выбор адреса для многоходовых и двухстоечных хостов, и для этого причина, по которой он отказывается RFC 4091 [RFC4091] и [ RFC4092].
WebRTC подключение — Веб-технологии для разработчиков
Черновик
Эта страница не завершена.
Теперь, когда мы рассмотрели протоколы по отдельности, мы можем сложить их вместе. Эта статья описывает, как различные связанные с WebRTC протоколы взаимодействуют друг с другом для того, чтобы создать соединение и передать данные и/или медиа между узлами.
Эта страница требует серьёзной переделки для структурной целостности и полноты содержания. Много информации здесь — это хорошо, но организация являет собой путаницу, поскольку сейчас являет собой вид «местности разгрузки»(dumping ground).
Что такое Предложение/Ответ и Канал сигнализации?
К сожалению, WebRTC не может создавать соединения без какого-либо сервера посередине. Мы называем его «каналом сигнализации». Это любого рода канал связи для обмена информацией перед установкой соединения, будь то электронная почта, почтовая открытка или почтовый голубь… Зависит от вас.
Информация, которой мы должны обменяться — это «предложение» и «ответ», которые содержат SDP, упомянутую ниже.
Узел A, тот кто будет инициатором соединения, создаст «предложение». Затем отправит это «предложение» узлу B, используя выбранный «сигнальный канал». Узел B получит «предложение» от «сигнального канала» и создаст «ответ». Затем отправит его обратно узлу A посредством «сигнального канала».
Описания сессии
Конфигурация конечной точки WebRTC-соединения называется «описание сессии»(session description). Описание включает информацию о типе посылаемого медиа, его формате, используемом протоколе передачи, IP-адресе и порте конечной точки, и другую информацию, необходимую для описания конечной точки передачи медиа. Эта информация обменивается и хранится с помощью «протокола описания сессии». Session Description Protocol(SDP). Если вы хотите подробную информацию о формате данных SDP, вы можете найти её в RFC 2327.
Когда пользователь запускает WebRTC вызов другого пользователя, создаётся специальное описание, называемое «предложение»(offer). Это описание включает всю информацию для соединения, о предлагаемой конфигурации вызывающего абонента. Получатель затем откликается «ответом»(answer), являющимся описанием его конца соединения. Таким образом, оба устройства разделяют друг с другом информацию, необходимую для того, чтобы обмениваться медиа данными. Этот обмен обрабатывается с помощью «интерактивного создания подключения». Interactive Connectivity EstablishmentICE. ICE — протокол, который позволяет двум устройствам использовать посредника для обмена «предложениями»(offers) и «ответами»(answers), даже если эти два устройства разделены механизмом «преобразования сетевых адресов». (NAT(Network Address Translation).
Каждый узел, тогда, держит два описания под рукой: локальное описание (local description), описывающее себя и удалённое описание(remote description), описывающее другой конец соединения.
Процесс «предложение/ответ»(offer/answer) выполняется как, когда соединение впервые устанавливается, так и в любой момент, когда формат соединения или другая конфигурация нуждается в изменении. Независимо от того, является ли это новым соединением, или реконфигурированием существующего, это основные шаги, которые должны произойти для обмена «предложением»(offer) и «ответом»(answer). Пропустим ICE-слой на данный момент:
- Вызывающий вызывает
RTCPeerConnection.createOffer()для создания «предложения»(offer) - Вызывающий вызывает
RTCPeerConnection.setLocalDescription()для установки этого «предложения» как локального описания (то есть описания локального конца соединения). - Вызывающий использует сигнальный сервер для передачи «предложения» к требуемому получателю вызова.
- Получатель получает «предложение» и вызывает
RTCPeerConnection.setRemoteDescription()для записи его, как удалённого описания(описания другого конца соединения). - Получатель делает всякую настройку, которую должен сделать для его конца соединения, включая добавления исходящих потоков для соединения.
- Получатель затем создаёт «ответ»(answer) посредством вызова
RTCPeerConnection.createAnswer(). - Получатель вызывает
RTCPeerConnection.setLocalDescription(), чтобы установить «ответ»(answer) в качестве локального описания. Получатель теперь знает конфигурацию обоих концов соединения. - Получатель использует сигнальный сервер для отправки «ответа»(answer) вызывающему.
- Вызывающий получает «ответ»(answer).
- Вызывающий вызывает
RTCPeerConnection.setRemoteDescription()для установки «ответа»(answer) как удалённого описания для его конца соединения. Теперь известна конфигурация обоих узлов. Медиа начинает течь в соответствии с настройками.
Рассматриваемые и текущие описания
Спускаясь на один шаг глубже в процесс, мы находим, что localDescription и remoteDescription, свойства, возвращаемые эти двумя описаниями, не так просты, как выглядят. Потому что во время повторных переговоров(перезаключения) (renegotiation), «предложение»(offer) может быть отклонено, поскольку оно предлагает несовместимый формат. Необходимо, чтобы каждая конечная точка имела возможность предложить новый формат, но не переключаться на него, пока он не принят другим узлом. По этой причине, WebRTC использует «рассматриваемые» и «текущие» «описания».
«Текущее описание»(current description) (которое возвращается свойствами RTCPeerConnection.currentLocalDescription и RTCPeerConnection.currentRemoteDescription) представляет собой описание, в данный момент, фактически используемое соединением. Это самое недавнее соединение, которое обе стороны полностью согласились использовать.
«Рассматриваемое описание»(pending description) (возвращаемое RTCPeerConnection.pendingLocalDescription и RTCPeerConnection.pendingRemoteDescription) указывает на то описание, которое в настоящий момент находится на рассмотрении после вызова setLocalDescription() или setRemoteDescription(), соответственно.
При чтении описания (возвращаемого RTCPeerConnection.localDescription и RTCPeerConnection.remoteDescription), возвращаемым значением является значение pendingLocalDescription/pendingRemoteDescription, если есть рассматриваемое описание (то есть, рассматриваемое описание не null). В противном случае, возвращается текущее описание (currentLocalDescription/currentRemoteDescription).
При изменении описания путём вызова setLocalDescription() или setRemoteDescription(), указанное описание устанавливается как «рассматриваемое описание»(pending description), и WebRTC-слой начинает оценивать, действительно ли это приемлемо. После того, как предложенное описание было согласовано, значение currentLocalDescription или currentRemoteDescription изменяется на «рассматриваемое описание»(pending description), и pending description устанавливается снова в null, указывая, что «отложенного описания»(pending description) не существует.
pendingLocalDescription содержит не только «предложение» или «ответ» на стадии рассмотрения, но и каких-либо ICE-кандидатов, которые уже были собраны с тех пор, как «предложение» или «ответ» были созданы. Подобным образом, pendingRemoteDescription включает любых удалённых ICE-кандидатов, которые были предоставлены вызовами RTCPeerConnection.addIceCandidate().
Смотрите отдельные статьи по этим свойствам и методам для большей конкретики.
Что такое ICE-кандидат?
В дополнение к обмену информацией о медиа(обсуждённой выше в offer/answer и SDP), узлы должны обменяться информацией о сетевом соединении. Об этом известно как о ICE-кандидате и деталях доступных методов, которыми узел может общаться (непосредственно или через TURN-сервер).