Сигнализация |
|---|
| ||||||||||
|
|
Версия 6.2 |
|||||||||||||||||||||||||||||||||
|
|
"Базовая", модель коммуникаций подразумевает, что конечные устройства могут взаимодействовать напрямую, то есть, все "участники", как клиенты (телефоны, софтфоны, приложения PBX), так и сервера имеют "реальные" Интернет IP адреса. В такой ситуации Серверу необходимо только установить соединение. Медиа данные и (в случае SIP) управляющие сигналы в течение звонка циркулируют непосредственно между конечными устройствами:
В реальной жизни множество клиентов находится в удалённых локальных сетях ("позади NAT") или в различных локальных сетях и не могут взаимодействовать напрямую. Для коммуникаций в реальном времени, основывающихся на публичных стандартах, CommuniGate Pro поддерживает автоматическое "Прохождение NAT".
Модули SIP и XIMSS CommuniGate Pro определяют запросы на установление сессии, отправленные от одной стороны через NAT другой стороне (запрос от клиента в локальной сети, направляемый участнику в Интернет/WAN и наоборот). В этом случае сервер использует специальный локальный порт сервера (или набор таких портов, в зависимости от используемого медиа протокола) и осуществляет проксирование медиа данных. Сервер изменяет запросы на установление сессии и направляет трафик обоих сторон через такой прокси.
Медиа Прокси ретранслирует медиа данные между "плечом LAN" и "плечом WAN" медиа соединения:
Модули SIP и XIMSS CommuniGate Pro определяют запросы на изменения сессии (команду re-INVITE протокола SIP) и запросы на закрытие сессии (команду BYE протокола SIP) и, соответственно, изменяют или удаляют Медиа Прокси. Для удаления "заброшенных" Медиа Прокси используется механизм тайм-аутов.
CommuniGate Pro обеспечивает услуги проксирования NAT для:Обратите внимание: Если вам необходимо использовать функции Проксирования Медиа, убедитесь, что данные о конфигурации LAN и NAT на странице с настройками Адреса LAN и NAT заданы корректно.
Обратите внимание: Сервер автоматически выполняет Медиа Проксирование при ретрансляции запросов, приходящих с IPv4 адресов на IPv6 адреса и наоборот.
SIP и XIMSS модули CommuniGate Pro обладают также возможностями "дальнего" прохождения NAT, обнаруживая запросы, приходящие от клиентов, находящихся за удалёнными межсетевыми экранами или NAT.
Модули добавляют соответствующие заголовки Record-Route и Path к таким запросам и организовывают Медиа Проксирование, ретранслируя трафик между такими клиентами.
Обратите внимание: современные SIP клиенты поддерживают различные методы прохождения NAT (STUN и т.д.). Многие из этих реализаций работают неустойчиво, так что часто надёжнее будет просто отключить методы прохождения NAT на стороне клиента и вместо этого воспользоваться имеющимися в CommuniGate Pro возможностями по "дальнему" прохождению NAT.
Обратите внимание: из-за особенностей TCP протокола и самой концепции межсетевого экрана, в общем случае невозможно открыть TCP соединение с клиентом, находящимся за дальним NAT (в конфигурациях с "ближним" NAT такие проблемы отсутствуют). Это означает, что клиенты, находящиеся за "дальними" NAT не могут инициировать TCP (T.120) сессии.
Для того, чтобы решить эту проблему, вы можете:SIP Модуль CommuniGate Pro может оказывать "Услуги Edge" или ALG ("Application Level Gateway", "Шлюз Уровня Приложений"), предоставляя возможности по прохождению NAT для пользователей, зарегистрированных на других серверах.
SIP Модуль CommuniGate Pro умеет обнаруживать "медиа петли", когда вызов, совершённый из локальной сети LAN проксируется в глобальную сеть WAN, а затем проксируется обратно в ту же локальную сеть. В этом случае Медиа Проксирование не осуществляется, что позволяет избежать непроизводительных затрат ресурсов сервера и SIP клиенты получают возможность взаимодействовать напрямую внутри локальной сети, тогда как все необходимое взаимодействие с серверами по регистрации пользователей по-прежнему осуществляется вне локальной сети.
SIP модуль может обнаруживать намного более сложные случаи зацикливания и отменять Медиа Проксирования полностью или частично, минимизируя число используемых Прокси.
Для того, чтобы обнаружить клиентов за NAT, Серверу необходимо знать, какие адреса используются в удалённый сетях, находящихся за этими NATами.
Для того, чтобы настроить Адреса за NAT, используйте Веб Интерфейс Администратора. Откройте в области Установки страницу Сеть, затем откройте страницу NAT.
Если SIP клиент отправляет запрос в CommuniGate Pro и собственный сетевой адрес клиента, указанный в заголовке запроса, включён в список Адреса за NAT, в то время как Сервер получил этот запрос с другого сетевого адреса, НЕ указанного в списке Адреса за NAT, то Сервер решает, что клиент находится за NAT.
Некоторые сервера NAT пытаются исполнить функции "Шлюза прикладного уровня для SIP", изменяя адреса IP в передаваемых ими пакетах SIP.
Многие такие сервера NATсовершают ошибки в этих попытках, и серверу CommuniGate Pro стоило бы работать с клиентами за такими серверами NAT, используя стандартную технику Дальнего прохождения NAT, но CommuniGate Pro не может определить, что это необходимо, поскольку адреса IP в их пакетах SIP были изменены.
Вы можете указать адреса IP таких серверов NAT в списке Адреса NAT Серверов: пакеты , приходящие с адресов из этого списка, обрабатываются так же, как если бы они приходили от клиентов "за NAT":
Может возникнуть необходимость отправлять запросы на удалённые сервера SIP (например, шлюзы в ТфОП), расположенные за дальним NAT. Поскольку такие сервера не присылают запросы SIP REGISTER на сервер CommuniGate Pro, нет автоматического способа определить необходимость использования дальнего прохождения NAT.
Включите публичные сетевые адреса таких удалённых серверов SIP в список Адреса NAT Серверов, чтобы уведомить Модуль SIP сервера CommuniGate Pro о необходимости использования техник Дальнего прохождения NAT при работе с этими серверами SIP.
Когда клиенты соединяются с сервером CommuniGate Pro из-за файрвола NAT с несколькими публичными адресами, сигнальные запросы (SIP, XIMSS) и потоки медиа (RTP) могут приходить с разных адресов IP.
Когда клиент использует запросы HTTP для сессий Веб Интерфейса Пользователя или XIMSS, запросы HTTP могут приходить с разных публичных адресов.
В таких ситуациях клиенты могут страдать от потери медиа потоков или прерываний сессий из-за запросов с "неправильного адреса IP".
Во избежание таких проблем, два разных адреса IP такого файрвола могут считаться "тем же" адресом, если они оба входит в один диапазон адресов, добавленный в список Адресов NAT Серверов.
Для того, чтобы позволить другим пользователям осуществлять входящие вызовы клиента SIP, находящегося за NAT, CommuniGate Pro сохраняет "коммуникационный канал" между клиентом и Сервером открытым, периодически отправляя фиктивные пакеты этому клиенту.
CommuniGate Pro поддерживает разнообразные коммуникации в реальном времени. Большинство таких протоколов реального времени не может работать через NAT/Firewall, но CommuniGate Pro может действовать как "прокси" для таких протоколов.
Когда клиент локальной сети пытается соединиться с удалённой системой через Интернет (WAN), CommuniGate Pro создаёт Медиа Прокси - некий коммуникационный порт на своей системе.
Он заставляет клиента соединяться с этим Медиа Прокси вместо того, чтобы соединяться непосредственно с медиа-портом удалённой системы.
Медиа Прокси CommuniGate Pro сам взаимодействует с удалённой системой, ретранслируя все данные, получаемые от клиента из локальной сети на удалённую систему и обратно.
Проксирование Медиа создано для того, чтобы обеспечить возможность обслуживания пользователей, находящихся за удалёнными NAT устройствами.
Проксирование Медиа так же используется для ретранслирования трафика между IPv4 и IPv6 сетями.
Обратите внимание: некоторые системы NAT имеют несколько публичных адресов. В этом случае сигнальные запросы могут приходить с одного сетевой адреса такой системы, а медиа потоки могут приходить с другого сетевого адреса.
Медиа прокси CommuniGate Pro может поддерживать такие системы NAT , если все их публичные адреса входят в один общий диапазон сетевых адресов, указанный в списке Адресов NAT Серверов.