«Базовая», «оригинальная» модель голосовых коммуникаций подразумевает, что конечные устройства могут взаимодействовать напрямую, то есть все «участники», как клиенты (телефоны, софтфоны, приложения PBX), так и сервера имеют "реальные" Интернет IP-адреса. В этом случае все участники могут обмениваться медиаданными напрямую, отправляю медиа пакеты (обычно, используя протокол RTP или T.120) непосредственно друг другу.

Как это часто бывает, в реальной жизни ситуация довольно сильно отличается от этой модели, и конечные устройства не могут обмениваться медиа данными напрямую. Сервер CommuniGate Pro решает эту проблему путём автоматического проксирования медиа данных, предписывая конечным устройствам отправлять медиа данные через медиапрокси для их дальнейшей ретрансляции.

Проксирование медиа применяется в следующих случаях:

  • одно конечное устройство находится в локальной сети LAN, а другое в глобальной WAN.

  • одно конечно устройство находится за удалённым NAT, тогда как другое не находится за этим же NAT.

  • одно конечно устройства находится в сети IPv4, а другое находится в сети IPv6.

  • проксирование медиа явно затребовано компонентом Signal.

Проксирование медиа также применяется компонентами SIP и XIMSS в случаях, когда вызов отправляется удалённому участнику.

Прохождение NAT и проксирование медиа потоков

"Базовая", модель коммуникаций подразумевает, что конечные устройства могут взаимодействовать напрямую, то есть, все "участники", как клиенты (телефоны, софтфоны, приложения PBX), так и сервера имеют "реальные" Интернет IP-адреса. В такой ситуации серверу необходимо только установить соединение. Медиаданные и (в случае SIP) управляющие сигналы в течение звонка циркулируют непосредственно между конечными устройствами:

В реальной жизни множество клиентов находится в удалённых локальных сетях ("позади NAT") или в различных локальных сетях и не могут взаимодействовать напрямую. Для коммуникаций в реальном времени, основывающихся на публичных стандартах, CommuniGate Pro поддерживает автоматическое «прохождение NAT».

Ближнее прохождение NAT

Модули SIP и XIMSS CommuniGate Pro определяют запросы на установление сессии, отправленные от одной стороны через NAT другой стороне (запрос от клиента в локальной сети, направляемый участнику в Интернет/WAN и наоборот). В этом случае сервер использует специальный локальный порт сервера (или набор таких портов, в зависимости от используемого медиа протокола) и осуществляет проксирование медиа данных. Сервер изменяет запросы на установление сессии и направляет трафик обеих сторон через такой прокси.

Медиапрокси ретранслирует медиа данные между «плечом LAN» и «плечом WAN» медиасоединения:

Модули SIP и XIMSS CommuniGate Pro определяют запросы на изменения сессии (команду re-INVITE протокола SIP) и запросы на закрытие сессии (команду BYE протокола SIP) и, соответственно, изменяют или удаляют медиапрокси. Для удаления "заброшенных" медиапрокси используется механизм тайм-аутов.

CommuniGate Pro обеспечивает услуги проксирования NAT для:

  • UDP медиа протоколов,

  • RTP медиа протоколов, основывающихся на UDP,

  • TCP медиа протоколов,

  • T.120 медиа протоколов, основывающихся на TCP.

Обратите внимание: если вам необходимо использовать функции проксирования медиа, убедитесь, что данные о конфигурации “LAN” и “NAT” на странице с настройками адреса LAN и NAT заданы корректно.

Обратите внимание: сервер автоматически выполняет медиа проксирование при ретрансляции запросов, приходящих с IPv4 адресов на IPv6 адреса и наоборот.

Дальнее прохождение NAT

SIP и XIMSS модули CommuniGate Pro обладают также возможностями "дальнего" прохождения NAT, обнаруживая запросы, приходящие от клиентов, находящихся за удалёнными межсетевыми экранами или NAT.
Модули добавляют соответствующие заголовки Record-Route и Path к таким запросам и организовывают медиа проксирование, ретранслируя трафик между такими клиентами.

Обратите внимание: современные SIP-клиенты поддерживают различные методы прохождения NAT (STUN и т.д.). Многие из этих реализаций работают неустойчиво, так что часто надёжнее будет просто отключить методы прохождения NAT на стороне клиента и вместо этого воспользоваться имеющимися в CommuniGate Pro возможностями по "дальнему" прохождению NAT.

Обратите внимание: из-за особенностей TCP-протокола и самой концепции межсетевого экрана, в общем случае невозможно открыть TCP-соединение с клиентом, находящимся за дальним NAT (в конфигурациях с "ближним" NAT такие проблемы отсутствуют). Это означает, что клиенты, находящиеся за "дальними" NAT не могут инициировать TCP (T.120) сессии.

Чтобы решить эту проблему, вы можете:

  • всегда инициировать TCP-сессии с клиентов, которые не находятся за дальним межсетевым экраном или NAT (такие клиенты могут принимать приглашения и устанавливать исходящие TCP соединения без каких бы то ни было проблем)
    или

  • использовать дополнительную копию сервера CommuniGate Pro в удалённой сети в качестве решения для ближнего прохождения NAT, избавляясь, тем самым, от необходимости использовать технологию дальнего прохождения NAT на "главном" сервере CommuniGate Pro
    или

  • настроить удалённый межсетевой экран или NAT на ретрансляцию всех входящих TCP-запросов на отдельную рабочую станцию, находящуюся за межсетевым экраном на её T.120 порт (обычно, порт номер 1503).

Услуги Edge

SIP-модуль CommuniGate Pro может оказывать "услуги Edge" или ALG ("Application Level Gateway", "шлюз уровня приложений"), предоставляя возможности по прохождению NAT для пользователей, зарегистрированных на других серверах.

SIP-модуль CommuniGate Pro умеет обнаруживать «медиапетли», когда вызов, совершённый из локальной сети LAN проксируется в глобальную сеть WAN, а затем проксируется обратно в ту же локальную сеть. В этом случае медиа проксирование не осуществляется, что позволяет избежать непроизводительных затрат ресурсов сервера и SIP-клиенты получают возможность взаимодействовать напрямую внутри локальной сети, тогда как все необходимое взаимодействие с серверами по регистрации пользователей по-прежнему осуществляется вне локальной сети.

SIP-модуль может обнаруживать намного более сложные случаи зацикливания и отменять медиа проксирования полностью или частично, минимизируя число используемых прокси.

Адреса за NAT

Чтобы обнаружить клиентов за NAT, серверу необходимо знать, какие адреса используются в удалённый сетях, находящихся за этими NATами.
Чтобы настроить “адреса за NAT”, используйте веб-интерфейс администратора. Откройте в области “установки” страницу “сеть”, затем откройте страницу “NAT”.

Если SIP-клиент отправляет запрос в CommuniGate Pro и собственный сетевой адрес клиента, указанный в заголовке запроса, включён в список “адреса за NAT”, в то время как сервер получил этот запрос с другого сетевого адреса, НЕ указанного в списке “адреса за 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-серверов.

Монитор NAT-клиентов

Чтобы позволить другим пользователям осуществлять входящие вызовы клиента SIP, находящегося за NAT, CommuniGate Pro сохраняет «коммуникационный канал» между клиентом и сервером открытым, периодически отправляя фиктивные пакеты этому клиенту.

Уровень журнала

Используйте эту настройку, чтобы указать, какую информацию компонент “монитор NAT-клиентов” должен сохранять в журнале работы сервера. Обычно используется уровень “основное” или уровень “проблемы” (не фатальные ошибки).
Записи, помещённые компонентом монитор NAT-клиентов в системный журнал работы сервера, имеют пометку NATPING.

 

Число клиентов

Используйте эту настройку для указания количества разных NAT-клиентов, работу с которыми сервер может обеспечивать.

 

Проверять клиентов каждые

Используйте эту настройку для указания того, как часто сервер должен отправлять проверочные пакеты для поддержания активности коммуникационного канала.

Проксирование медиа

CommuniGate Pro поддерживает разнообразные коммуникации в реальном времени. Большинство таких протоколов реального времени не может работать через NAT/Firewall, но CommuniGate Pro может действовать как «прокси» для таких протоколов.

Когда клиент локальной сети пытается соединиться с удалённой системой через Интернет (WAN), CommuniGate Pro создаёт медиапрокси — некий коммуникационный порт на своей системе.
Он заставляет клиента соединяться с этим медиапрокси вместо того, чтобы соединяться непосредственно с медиа-портом удалённой системы.
Медиапрокси CommuniGate Pro сам взаимодействует с удалённой системой, ретранслируя все данные, получаемые от клиента из локальной сети на удалённую систему и обратно.

Проксирование медиа создано, чтобы обеспечить возможность обслуживания пользователей, находящихся за удалёнными NAT устройствами.

Проксирование медиа также используется для ретранслирования трафика между IPv4 и IPv6 сетями.

 

Уровень журнала

Используйте эту настройку, чтобы указать какую информацию компонент прокси должен сохранять в журнале работы сервера. Обычно используется уровень “основное” или уровень “проблемы” (не фатальные ошибки). В случае, если в работе компонента “прокси” возникают проблемы, то, возможно, целесообразным будет увеличить детализацию до уровня “подробности” или “всё”: в этом случае в системный журнал будет записываться более подробная информация о работе модуля на уровне протокола или на уровне ссылок.
Записи, помещённые компонентом “медиапрокси” в журнал работы сервера, имеют пометку MEDIAPROXY.
Для медиа прокси может быть создано несколько потоковых пр

окси для каждого медиапотока (например, один прокси для медиапотока аудио, и ещё один — для видеопотока). Записи, помещённые компонентом “прокси” в журнал работы сервера, имеют пометку UDPPROXY или TCPPROXY.

 

Проверять порт источника

Когда эта опция включена, данные медиа, передающиеся по UDP из внешних источников, принимаются в случае прихода с корректного IP-адреса и номера порта.
Если эта опция не задана, проверяется только IP-адрес источника медиа. Это помогает при работе с медиа-устройствами, которые указывают неправильный порт в SDP.

 

UDP TOS Тэг

Если эта опция не установлена в значение выбор ОС, то UDP пакеты с медиа данными получают указанное значение тэга TOS (тип сервиса). Это может быть полезным при задании приоритетов медиа трафика в случае, если ваша сетевая инфраструктура может назначать более высокий приоритет пакетам с указанным значением тэга TOS.

 

Проксировать для клиентов за общим NAT

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

Никогда

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

NAT сервера

Медиапрокси будет построен, если видимые адреса клиентов пересекаются со списком адресов NAT серверов.

Всегда

Медиапрокси для таких клиентов строится всегда.

 

Обратите внимание: некоторые системы NAT имеют несколько публичных адресов. В этом случае сигнальные запросы могут приходить с одного сетевой адреса такой системы, а медиапотоки могут приходить с другого сетевого адреса.
Медиапрокси CommuniGate Pro может поддерживать такие системы NAT, если все их публичные адреса входят в один общий диапазон сетевых адресов, указанный в списке адресов NAT серверов.