Провайдеры телефонии

Провайдеры - сервисные компании, предоставляющие доступ к внешним сетям. Интернет, ТФОП и пр. Чтобы получить доступ к ТФОП, необходимо иметь договор оказания услуг связи с одной из таких компаний. Подключение провайдерами предоставляется по различным каналам и протоколам, например потоки E1, аналоговые линии, SIP, H.323. Платформа работает только с протоколом SIP. Если провайдер может предоставить точку подключения SIP - платформа стыкуется непосредственно к провайдеру. Если нет - необходимы промежуточные узлы - шлюзы. Например из E1 в SIP.

Отталкиваемся, что остальное в домене уже настроено, и пользователи могут звонить друг другу.

В домене необходимо настроить учетную запись провайдера: по ссылке описание всех свойств. Настройка может быть проведена:

В минимальном режиме необходимо настроить:

Остальные поля по мере продвижения рассмотрим ниже.

В случае, если производится подключение в режиме точка-точка, провайдером может быть задан явный порт для клиентской точки подключения. Этот порт должен быть настроен в конфигурации в мастер-домене для экземпляра роли ESG, к которому следует привязать обслуживание учетной записи. По умолчанию в конфигурациях, созданных в мастере конфигураций, для esg назначается порт 5080. В случае если разные подключения требуют много разных портов - это можно решить либо через размножение экземпляров esg, либо использовать в проекте промежуточный шлюз, решающий эту задачу.

Если сервер имеет внешний адрес в сети интернет, то он находится под угрозой. Если с произвольных внешних адресов можно подключиться на SIP-порт микросервиса ESG, то это открытое место для атак. Атаки осуществляются путем перебора учетных записей внешними системами (снифферами). Те посылают INVITE-запросы, подставляя в них различные значения и авторизационные данные. Если система начинает отвечать, сниффер активизируется и начинает интенсивный перебор учетных данных с целью прорваться в номерной план.

Защита от атак обеспечивается пограничным фильтром. Проверка разрешений производится на основании правил пограничного фильтра для входящих извне SIP-запросов. Настройка правил фильтра может быть проведена:

Правилами можно создать черно-белые списки.

В закрытых сетях можно не настраивать пограничный фильтр, или настраивать черные списки.

В открытых сетях следует настраивать белый список, то есть разрешать запросы только с определенных адресов, а последним по приоритету правилом запрещать все остальные запросы. При этом режим запрета следует выставить 'drop', чтобы сервер даже не реагировал на поступающий запрос и не провоцировал внешние снифферы продолжать подбор учетных данных.

Если у правила заполнен только фильтр в поле "адрес", то такой запрос не проходит парсинг, и обрабатывается непосредственно на сокете. Это гораздо эффективнее, чем остальные режимы.

Таким образом, самый производительно-эффективный способ настройки - белый список с разрешающими правилами на ip-адреса и режимом drop для всех остальных.

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

При поступлении входящего звонка (INVITE) на порт микросервиса esg, тот производит проверку разрешений (рассмотрена выше) и привязку к учетной записи.

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

При поступлении INVITE-запроса осуществляется перебор активных учетных записей и проверка условий. Сверяются два поля из запроса с двумя полями из учетной записи. Функция поиска принимает два поля, которые последовательно в 6 этапов подставляются из разных заголовков вплоть до первого обнаружения:

1. Поиск среди учетных записей с регистрацией:

1.1. username и domain берутся из заголовка To. В примере это значения "1234567890" и "172.27.103.90".

1.2. username берется из заголовка To, а domain берется из заголовка From. В примере это значения "1234567890" и "44.55.66.77".

1.3. username и domain берутся из заголовка Contact. В примере это значения "" и "44.55.66.77".

2. Поиск среди учетных записей без регистрации (точка-точка):

2.1. username и domain берутся из заголовка Contact. В примере это значения "" и "44.55.66.77".

2.2. username берется пустым (""), domain из поля Contact. В примере это значения "" и "44.55.66.77".

2.3. username берется из поля To, domain берется из поля From. В примере это значения "1234567890" и "44.55.66.77".

Сама функция поиска сверяет переданные значения:

Если учетная запись не найдена в результате рассмотренного алгоритма, то сервер отвечает '404 Not Found' и в заголовок Reason размещает сообщение "EB2B. Unknown account in contact".

В большинстве случаев не приходится разбираться с подключением провайдера, достаточно завести учетную запись, и звонки начинают проходить.

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

Если учетная запись обнаружилась, то производится сверка сопоставленных с ней адресов с адресом-отправителя пакета INVITE (домен, адрес прокси сервера, результаты ресолва доменного имени, заданные в учетной записи маски адресов). В случае успеха вызов передается в обслуживание - создается второе плечо в сторону микросервиса b2b.

Общая технология сложной настройки:

Если провайдер с регистрацией указывает в поле domain заголовка To запроса INVITE внешний IP-адрес самого сервера с ESG, и однозначное сопоставление учетной записи провайдера производится по username в заголовке To входящих INVITE-запросов, то следует внести этот адрес в список 'extaddrs' параметров микросервиса ESG в конфигурации (кроме случая, если это единственный адрес сервера, определяемый с помощью STUN запроса).

Важно помнить, что при использовании встроенного SIP-ALG белые адреса будут подменяться на серые, и настройки учетных записей должны это учитывать. В предыдущем случае необходимо внести серый адрес в список 'extaddrs' параметров микросервиса ESG.

Для осуществления исходящего вызова через учетную запись провайдера, его следует в правилах маршрутизации того же домена направить на внешний контур и указать код учетной записи провайдера.

Маршрутизация производится микросервисом b2b. Перед тем как отправить вызов соответствующему учетной записи esg, производится проверка его доступности и доступности учетной записи. Если ее состояние неактивно, если превышен установленный лимит для одновременных сессий - маршрутизация переходит к следующему по приоритету правилу.

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

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

Микросервис esg разделяет два номерных плана - внутренний номерной план и внешний номерной план (ТФОП, или внешней АТС). Между этими номерными планами вероятно есть разница. Например, снаружи 10 значные номера, а внутри 4 значные.

При вызовах через эту границу номера в основном требуют модификации.

Лог журналы, касающиеся работы с учетными записями провайдеров телефонии, ведутся микросервисами esg. Необходимо включить в конфигурации соответствующему экземпляру esg параметр 'log_trn'. Для расширенного логирования необходимо в разделе управления нодами (АРМ администратора мастер-домена - Система - Ноды) выставить режим логирования TRACE или DEBUG.

Лог журналы находятся в каталоге, заданном при установке. По умолчанию это путь '/opt/ERA_INSTANCE_NAME/log' в хосте, и '/var/log/era' в контейнере. Полный путь к каталогу журналов esg может выглядеть так: '/opt/ERA_INSTANCE_NAME/log/esg1@SERVER_ADDR/sip'

В лог журнале 'trn_*.log' можно обнаружить все пакеты (по всем провайдерам). В логе 'erl_*.log' можно обнаружить подробные трассировки процесса регистрации.

В лог журналы размещается активность по всем провайдерам. В режиме отладки может быть удобно завести отдельный экземпляр микросервиса с низким приоритетом (высоким значением параметра 'roleid' в конфигурации), привязать к нему исследуемую учетную запись (установкой значения RoleId в поле учетной записи serveridxs).

Логика esg соответствует режиму b2bua (back-to-back useragent). То есть каждый поступающий вызов формирует диалог и второе плечо. Esg во второе плечо всегда генерирует новый Call-Id.

esg никогда не транслирует REFER в другое плечо, а обрабатывает его локально, создавая новый форк в ту же сторону, с плеча которой пришел запрос REFER. Таким образом гарантируется, что вызов будет направлен в корректный номерной план. Корректный - означает соответствие номеру для перевода вызова. Это же означает, что платформу без дополнительной модификации нельзя настроить на переадресацию вызова с отказом от внутренней обработки.

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

Режим проброса реинвайтов означает, что каждое изменение сессии транслируется сквозь esg в противоположное плечо без изменения SDP.

Режим локальной обработки медиа (поле 'media'=true). Тогда она замыкает на себе все запросы re-INVITE внутри диалога, обрабатывая их локально путем настройки медиа. Для этого используется медиашлюз bgmg, расположенный на том же сервере, что и экземпляр esg. Такой режим может быть полезен, если для подключения к провайдеру необходимо гарантировать отправку медиа-данных с того же адреса, где и сигнальный SIP-трафик, или, например, количество адресов в выделенной vlan-подсети провайдера узко ограничено и не может быть расширено для всех серверов кластера платформы. При использования режима локальной обработки медиа сигнальный трафик может терминироваться на плече (reinvite=false) или с изменением SDP транслироваться в противоположное плечо (reinvite=true).

По умолчанию используется режим reinvite=true и media=false, подходящий для подавляющего большинства инсталляций.

Экземпляры esg, как и других микросервисов, отвечающих за SIP-сигнализацию, поднимают слушателей на всех интерфейсах (0.0.0.0). Порты указываются в конфигурации для каждого отдельного экземпляра микросервиса, но указанные порты относятся ко всем интерфейсам соответствующего сервера. Это означает, что платформу без дополнительной модификации нельзя тонко настроить на прослушивание специфических портов на специфических интерфейсах.

В шаблонных конфигурациях роли esg присваиваются порты 5080, 5081. На этих портах на всех интерфейсах сервера, где исполняется соответствующий экземпляр esg, поднимаются слушатели, также с них происходит отправка UDP-пакетов сигнального протокола.

Существуют случаи, когда определенный провайдер требует от клиента порт 5060. В этой связи следует настраивать порт 5060 для esg. Тогда же может потребоваться изменять также порты и для экземпляров sg. Исключением может являться только ситуация, когда экземпляры esg и sg исполняются на разных серверах. По мере убывания удобства рекомендуются следующие варианты: