Провайдеры телефонии
Общее
Провайдеры - сервисные компании, предоставляющие доступ к внешним сетям. Интернет, ТФОП и пр. Чтобы получить доступ к ТФОП, необходимо иметь договор оказания услуг связи с одной из таких компаний. Подключение провайдерами предоставляется по различным каналам и протоколам, например потоки E1, аналоговые линии, SIP, H.323. Платформа работает только с протоколом SIP. Если провайдер может предоставить точку подключения SIP - платформа стыкуется непосредственно к провайдеру. Если нет - необходимы промежуточные узлы - шлюзы. Например из E1 в SIP.
Режимы подключения
Провайдер для подключения по SIP предоставляет: IP-адрес или DNS-имя точки подключения, порт подключения (по умолчанию 5060). Далее в зависимости от способа подключения провайдер может предоставить либо учетные данные - логин, пароль, и опционально номер, либо адрес клиента и подсеть вместе с отдельным подключением. В первом случае осуществляется регистрация клиента с произвольного адреса, во втором случае точка-точка - клиент знает точку сервера, сервер знает точку клиента. Режим с регистрацией позволяет настраивать резервирование узлов платформы - при падении одного, функцию обслуживания подключения к провайдеру возьмет на себя другой.
Примеры
Примеры учетных данных могут выглядеть так:
SIP-сервер: sipnet.ru Учетная запись: 71234567890 Пароль: 3y82lS5
Выделена сеть: 172.27.103.88/29 (172.27.103.89 - шлюз по умолчанию, 172.27.103.90 - оборудование клиента) IP адрес сервера: 44.55.66.77 Порт: 5060 UDP Голос пойдёт c 44.55.66.88 Оба вышеуказанных ip-адреса должны маршрутизироваться через шлюз по умолчанию Кодек: g711a 20мс Факс: transparent DTMF: rfc2833 Диапазон нумерации: 9991234567 - 9991234569 (3 номерf, 50 сессий) Во "From" обязательно должен быть 10-значный номер из выделенного диапазона. От клиента ожидается набор абонентский, т.е. местные номера - 7-значные, зоновые и междугородние - с "8-кой", международная связь закрыта.
Иногда, как во втором случае, может потребоваться предварительная донастройка сети серверов, добавление vlan интерфейса, выданного адреса. С учетом того, что в этом случае медиашлюз может находиться на любом другом сервере - всем серверам, где может оказаться первая точка обработки медиа. А если это невозможно, необходимо настраивать локальный медиашлюз bgmg на сервере esg и работать в режиме с медиа.
Внешняя АТС
В качестве провайдера может выступать любая внешняя АТС, подключающая платформу "снизу", то есть в качестве своего абонента. В этом случае настройка происходит аналогично, и изложенные выше варианты подключения также имеют место. То есть внешняя АТС может быть подключена через регистрацию (на АТС), в режиме точка-точка (производится взаимная настройка адресов). Но если необходимо, чтобы АТС зарегистрировалась на платформе, то в этом случае платформа выступает "провайдером", и подключение производится иным образом - через подключение в качестве абонента.
Настройка учетной записи провайдера.
Отталкиваемся, что остальное в домене уже настроено, и пользователи могут звонить друг другу.
В домене необходимо настроить учетную запись провайдера: по ссылке описание всех свойств. Настройка может быть проведена:
-
Из АРМ администратора домена (Маршрутизация - Провайдеры). В режиме карточки, или в расширенном режиме через JSON (для доступа к специфическим полям).
-
Через Rest API (/rest/v1/uc/providers).
В минимальном режиме необходимо настроить:
-
Имя пользователя (username) - учетное имя,
-
Пароль (pwd) - пароль,
-
Домен (domain) - SIP-сервер или REGISTRAR,
-
Регистрация (reg) - выбрать режим с регистрацией или точка-точка.
-
Локальный домен (localdomain) - доменное имя для подстановки в заголовок FROM исходящих запросов.
-
Количество транков - выданное количество лицензий на количество одновременных сессий. Опционально:
-
Адрес outbound proxy (proxyaddr) - если он отличается от домена;
-
Порт outbound proxy (proxyport) - если порт точки подключения отличается от 5060; Проверить:
-
Протокол (transport) - если он отличается от UDP;
-
Режим пингов (pingmode), Адрес сервера пингов (pingsrv), Интервал пингов, сек (pingtimeout) - если подключение производится через NAТ с временным закреплением порта.
Остальные поля по мере продвижения рассмотрим ниже.
В случае, если производится подключение в режиме точка-точка, провайдером может быть задан явный порт для клиентской точки подключения. Этот порт должен быть настроен в конфигурации в мастер-домене для экземпляра роли ESG, к которому следует привязать обслуживание учетной записи. По умолчанию в конфигурациях, созданных в мастере конфигураций, для esg назначается порт 5080. В случае если разные подключения требуют много разных портов - это можно решить либо через размножение экземпляров esg, либо использовать в проекте промежуточный шлюз, решающий эту задачу.
Привязка к микросервисам
Учетные записи обслуживаются микросервисом esg. Если такой микросервис один, то учетная запись будет обслуживаться на нем. Если их несколько, то будет выбран один случайный из доступных и активных. При настройке в режиме точка-точка, когда экземпляры микросервиса esg разнесены по разным серверам, а клиентский адрес, выданный провайдером, относится только к одному из них, может потребоваться явно привязать учетную запись провайдера к экземпляру микросервиса esg. Это делается в поле "Значение RoleID роли esg (serveridxs)". Подробнее см. esg. Идентификаторы задаются микросервисам в конфигурации.
Все учетные записи провайдеров по всем доменам по умолчанию обслуживаются на одних и тех же экземплярах микросервиса esg. При необходимости можно развести учетные записи по разным экземплярам, но тогда эти экземпляры необходимо размножать в конфигурации (в мастер-домене), присваивая им разные имена и порты, и также прописывать у учетных записей в доменах явные привязки к экземплярам (поле "Значение RoleID роли esg (serveridxs)"). Обычно этого не требуется.
Резервирование возможно только при условии, что в конфигурации настроено несколько экземпляров микросервиса esg, и учетная запись не ограничена использованием только одного из них. В каждый момент времени учетная запись обслуживается не более чем 1 экземпляром esg. При падении сервера с обслуживающим экземпляром в течение нескольких секунд происходит failover на следующий по приоритету экземпляр. При восстановлени более приоритетного - в течение нескольких секунд происходит takeover обратно.
Просмотр состояния регистрации
Состояние учетной записи и ее регистрации доступно:
-
В АРМ администратора домена. (Мониторинг - Провайдеры). Здесь доступен только просмотр состояния. Но этот режим пользуется запросом к API, в теле ответа на который есть также SIP-ответ провайдера.
-
Через HTTP API:
/api/monitor/v1/esg/active?regs=true. Здесь присутствует статус последнего ответа на запрос регистрации, а также тело этого ответа, количество активных сессий.
{
"resultcode": 0,
"resultmsg": "OK",
"data": {
"sites": [
{
"site": "main_site",
"servers": [
{
"srvidx": 1005,
"node": "esg1@192.168.0.112",
"addr": "192.168.0.112",
"online": true,
"regs": [
{
"code": "pbx2",
"d": "test.era-platform.ru",
"user": "provider",
"domain": "test.era-platform.ru",
"port": 5060,
"proto": "udp",
"addrs": [
"test.era-platform.ru",
"192.168.0.112"
],
"regstate": "registered",
"pingstate": "disabled",
"last_response": [
"SIP/2.0 200 OK",
"Via: SIP/2.0/UDP 192.168.0.112:5080;rport=5080;received=192.168.0.112;branch=z9hG4bK4DVwMd-2bcZ6H",
"From: <sip:provider@test.era-platform.ru>;tag=3ZxqYI",
"To: <sip:provider@test.era-platform.ru>;tag=rB2-0GE-3PP1",
"Call-ID: Z76iX6vyAeqyWKi9hEp5DHUJ3le",
"CSeq: 309187570 REGISTER",
"Max-Forwards: 70",
"Content-Length: 0",
"Contact: <sip:provider@192.168.0.112:5080>;expires=3600",
"Supported: path",
"Allow: REGISTER,INVITE,ACK,CANCEL,BYE,REFER,NOTIFY,OPTIONS,INFO,SUBSCRIBE,MESSAGE,UPDATE",
"Date: Wed, 05 Apr 2023 14:02:41 GMT",
"Path: <sip:r_Q4YyzUe@192.168.0.112:5060;transport=tcp;lr>"
],
"onlinetrunkcount": 0
}
]
}
]
}
]
}
}
-
В лог-журнале: Сервер с микросервисом esg, ответственным за обслуживание учетной записи. Папка лог-журналов ноды,
sip/trn_*.log.
09:10:33.045 <0.682.0> Send to udp 192.168.0.112:5060 (ok) REGISTER sip:test.era-platform.ru SIP/2.0 Via: SIP/2.0/UDP 192.168.0.112:5080;rport;branch=z9hG4bK4RfHQ7-aePz3y From: <sip:provider@test.era-platform.ru>;tag=3ZxqYI To: <sip:provider@test.era-platform.ru> Call-ID: Z76iX6vyAeqyWKi9hEp5DHUJ3le CSeq: 309187561 REGISTER Max-Forwards: 70 Content-Length: 0 Route: <sip:192.168.0.112;lr> Contact: <sip:provider@192.168.0.112:5080> Supported: path Expires: 3600 User-Agent: Era 1.8.3 Allow: INVITE,ACK,CANCEL,BYE,REFER,NOTIFY,OPTIONS,INFO,MESSAGE 09:10:33.049 <0.685.0> Recv from udp 192.168.0.112:5060 SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.0.112:5080;rport=5080;received=192.168.0.112;branch=z9hG4bK4RfHQ7-aePz3y From: <sip:provider@test.era-platform.ru>;tag=3ZxqYI To: <sip:provider@test.era-platform.ru>;tag=rB2-0GE-WH5X Call-ID: Z76iX6vyAeqyWKi9hEp5DHUJ3le CSeq: 309187561 REGISTER Max-Forwards: 70 Content-Length: 0 Www-Authenticate: Digest realm="b2b_1006__test.era-platform.ru", nonce="KXapTShGqTzV5d0QAu7ddHRls9s", algorithm=MD5, qop="auth", opaque="1WVpoo" 09:10:33.060 <0.685.0> Send to udp 192.168.0.112:5060 (ok) REGISTER sip:test.era-platform.ru SIP/2.0 Via: SIP/2.0/UDP 192.168.0.112:5080;rport;branch=z9hG4bK2w1opp-10Y8e1 From: <sip:provider@test.era-platform.ru>;tag=3ZxqYI To: <sip:provider@test.era-platform.ru> Call-ID: Z76iX6vyAeqyWKi9hEp5DHUJ3le CSeq: 309187562 REGISTER Max-Forwards: 70 Content-Length: 0 Route: <sip:192.168.0.112;lr> Contact: <sip:provider@192.168.0.112:5080> Supported: path Expires: 3600 Authorization: Digest username="provider", realm="b2b_1006__test.era-platform.ru", nonce="KXapTShGqTzV5d0QAu7ddHRls9s", uri="sip:test.era-platform.ru", response="e1a569e736485e2eed64af1990cf4727", algorithm=MD5, qop=auth, cnonce="auBMkM6dgdpbzM8neoqG1dxmndx", nc=00000001, opaque="1WVpoo" User-Agent: Era 1.8.3 Allow: INVITE,ACK,CANCEL,BYE,REFER,NOTIFY,OPTIONS,INFO,MESSAGE 09:10:33.072 <0.685.0> Recv from udp 192.168.0.112:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.0.112:5080;rport=5080;received=192.168.0.112;branch=z9hG4bK2w1opp-10Y8e1 From: <sip:provider@test.era-platform.ru>;tag=3ZxqYI To: <sip:provider@test.era-platform.ru>;tag=rB2-0GE-QA9Q Call-ID: Z76iX6vyAeqyWKi9hEp5DHUJ3le CSeq: 309187562 REGISTER Max-Forwards: 70 Content-Length: 0 Contact: <sip:provider@192.168.0.112:5080>;expires=3600 Supported: path Allow: REGISTER,INVITE,ACK,CANCEL,BYE,REFER,NOTIFY,OPTIONS,INFO,SUBSCRIBE,MESSAGE,UPDATE Date: Wed, 05 Apr 2023 06:10:33 GMT Path: <sip:r_Q19NAi5@192.168.0.112:5060;transport=tcp;lr>
Отправляемый на адрес провайдера пакет с регистрацией и ответ провайдера, а также все прочие взаимодействия - пинги, инвайты и пр. доступны в исходном виде на всем протяжении активности учетной записи в лог журнале.
Защита от атак
Если сервер имеет внешний адрес в сети интернет, то он находится под угрозой. Если с произвольных внешних адресов можно подключиться на SIP-порт микросервиса ESG, то это открытое место для атак. Атаки осуществляются путем перебора учетных записей внешними системами (снифферами). Те посылают INVITE-запросы, подставляя в них различные значения и авторизационные данные. Если система начинает отвечать, сниффер активизируется и начинает интенсивный перебор учетных данных с целью прорваться в номерной план.
Защита от атак обеспечивается пограничным фильтром. Проверка разрешений производится на основании правил пограничного фильтра для входящих извне SIP-запросов. Настройка правил фильтра может быть проведена:
-
Из АРМ администратора мастер-домена (Маршрутизация - Фильтр). В режиме карточки, или в расширенном режиме через JSON (для доступа к специфическим полям).
-
Через Rest API (/rest/v1/master/borderrules).
Правилами можно создать черно-белые списки.
В закрытых сетях можно не настраивать пограничный фильтр, или настраивать черные списки.
В открытых сетях следует настраивать белый список, то есть разрешать запросы только с определенных адресов, а последним по приоритету правилом запрещать все остальные запросы. При этом режим запрета следует выставить 'drop', чтобы сервер даже не реагировал на поступающий запрос и не провоцировал внешние снифферы продолжать подбор учетных данных.
Если у правила заполнен только фильтр в поле "адрес", то такой запрос не проходит парсинг, и обрабатывается непосредственно на сокете. Это гораздо эффективнее, чем остальные режимы.
Таким образом, самый производительно-эффективный способ настройки - белый список с разрешающими правилами на ip-адреса и режимом drop для всех остальных.
Во всех других случаях настройки фильтров - SIP-запрос проходит через парсинг, и уже после этого проверяются другие фильтры и применяется указанное в правиле действие.
Входящий звонок
При поступлении входящего звонка (INVITE) на порт микросервиса esg, тот производит проверку разрешений (рассмотрена выше) и привязку к учетной записи.
Поиск учетной записи производится среди всех учетных записей провайдеров (во всех доменах), которые в настоящий момент обслуживаются экземпляром esg.
13:26:57.450 <0.1128.0> Recv from udp 44.55.66.77:5060 INVITE sip:1234567890@172.27.103.90:5080;transport=UDP;user=phone SIP/2.0 Via: SIP/2.0/UDP 44.55.66.77:5060;maddr=89.232.125.56;branch=z9hG4bK-14c4dd7e-210137c8-fc50302 From: <sip:8430000000@44.55.66.77:5060;user=phone>;tag=5026-14c4dd7e-1087cebd-14c4dd7e To: <sip:1234567890@172.27.103.90:5080;user=phone> Call-ID: 40bb12f838738e5913c414c4dd7e210137c8da2fa8102e98aa28-0048-5988 CSeq: 1 INVITE User-agent: CS2000_NGSS/9.0 Max-Forwards: 63 Allow: ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY,PRACK Contact: <sip:44.55.66.77:5060;transport=UDP> Supported: 100rel Content-Type: application/sdp Content-Length: 206 v=0 o=PVG 1357911604 1357911604 IN IP4 44.55.66.88 s=- p=+1 6135555555 c=IN IP4 44.55.66.88 t=0 0 m=audio 48970 RTP/AVP 8 13 101 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20
При поступлении 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".
Сама функция поиска сверяет переданные значения:
-
username - соответствие значению учетной записи в поле 'username' или одному из значений в списке из поля 'opts.extusernames'.
-
domain - соответствие значению: либо поля domain учетной записи, либо одному из внешних адресов сервера, где обслуживается текущий esg, либо одному внешнему адресу NAT. Причем поиск сопоставление может вестись как в явном виде, так и через маски (например, '44.55.6?.*'), и через регулярные выражения (например, '/reg/^44[.]55[.]6\\d[.]\d+$').
Если учетная запись не найдена в результате рассмотренного алгоритма, то сервер отвечает '404 Not Found' и в заголовок Reason размещает сообщение "EB2B. Unknown account in contact".
В большинстве случаев не приходится разбираться с подключением провайдера, достаточно завести учетную запись, и звонки начинают проходить.
В сложных случаях, когда входящие вызовы не проходят, и система возвращает указанное сообщение, требуется обратиться к логам, найти там входящий запрос и проанализировать его. Опираясь на рассмотренный алгоритм, выявить причину нестандартного поведения. По итогу дополнить учетную запись настройками. Например,
-
иногда следует добавить в поле 'opts.extusernames' значения username, которые регулярно обнаруживаются в запросе, и напрямую не соответствуют учетной записи;
-
иногда следует добавить в поле 'extaddrs' значения domain, которые регулярно обнаруживаются в запросе, и напрямую не соответствуют учетной записи. Это могут быть конкретные адреса и маски, в т.ч. регулярные выражения.
-
иногда следует добавить в параметр 'extaddrs' микросервиса ESG в конфигурации внешние адреса сервера платформы, которые провайдер указывает в поле domain заголовка To, а также серые адреса из настроек SIP-ALG
Если учетная запись обнаружилась, то производится сверка сопоставленных с ней адресов с адресом-отправителя пакета INVITE (домен, адрес прокси сервера, результаты ресолва доменного имени, заданные в учетной записи маски адресов). В случае успеха вызов передается в обслуживание - создается второе плечо в сторону микросервиса b2b.
Общая технология сложной настройки:
-
проанализировать несколько пакетов INVITE от разных звонков с провайдера;
-
выделить заголовки To, From, Contact, а в их значениях разделить username и domain - получается 6 полей;
-
выделить среди них поля с постоянными значения, четко указывающие на учетную запись провайдера (а не на абонента или учетную запись другого провайдера), и поля с переменными значениями;
-
сопоставить постоянные значения с алгоритмом проверки, приведенным выше.
Если провайдер с регистрацией указывает в поле domain заголовка To запроса INVITE внешний IP-адрес самого сервера с ESG, и однозначное сопоставление учетной записи провайдера производится по username в заголовке To входящих INVITE-запросов, то следует внести этот адрес в список 'extaddrs' параметров микросервиса ESG в конфигурации (кроме случая, если это единственный адрес сервера, определяемый с помощью STUN запроса).
Важно помнить, что при использовании встроенного SIP-ALG белые адреса будут подменяться на серые, и настройки учетных записей должны это учитывать. В предыдущем случае необходимо внести серый адрес в список 'extaddrs' параметров микросервиса ESG.
Исходящий звонок
Для осуществления исходящего вызова через учетную запись провайдера, его следует в правилах маршрутизации того же домена направить на внешний контур и указать код учетной записи провайдера.
Маршрутизация производится микросервисом b2b. Перед тем как отправить вызов соответствующему учетной записи esg, производится проверка его доступности и доступности учетной записи. Если ее состояние неактивно, если превышен установленный лимит для одновременных сессий - маршрутизация переходит к следующему по приоритету правилу.
Если существует несколько правил с одинаковым приоритетом, то последовательность их обхода всякий раз случайна. Этим можно пользоваться для распределения исходящих вызовов по двум или более учетным записям.
Поскольку исходящий вызов приходит на esg изнутри, с микросервиса b2b, то второе плечо отправляется наружу к провайдеру.
Настройка маршрутизации.
Микросервис esg разделяет два номерных плана - внутренний номерной план и внешний номерной план (ТФОП, или внешней АТС). Между этими номерными планами вероятно есть разница. Например, снаружи 10 значные номера, а внутри 4 значные.
При вызовах через эту границу номера в основном требуют модификации.
Правила нормализации (подмена номеров на esg).
Правила нормализации могут привязываться к конкретным учетным записям (по идентификатору) или к группе (через маски для поля code), в том числе правило можно привязать ко всем учетным записям, заполнив поле 'providercode' = "*".
Задача правил нормализации: привести абонента инициатора входящего вызова к внутреннему номерному плану, а абонента инициатора исходящего звонка - к внешнему номерному плану. То есть параметры вызова INVITE, поступившего на ESG, отличаются от параметров вызова INVITE, направляемого далее. Между ними лежит процесс нормализации. В частности, без использования явных правил нормализации вызовы перенаправляются со следующими изменениями:
-
входящие от провайдера вызовы: From username - не изменяется, To username - становится пустым, From domain и To domain - подставляется домен системы, где создана сопоставленная с вызовом учетная запись провайдера.
-
исходящие из системы вызовы: From username - не изменяется, To username - не изменяется, From domain и To domain - домен провайдера, заданный в учетной записи.
Частая операция - создание правила нормализации для исходящего направления учетной записи с регистрацией и подстановки в качестве 'from username' учетного имени. Без этого вызовы проходят с тем номером, который был определен в ходе маршрутизации во внутреннем номерном плане. Особый случай - применение правил представления, заранее подставивших внешний номер для абонента исходя из комплексно настроенной логики.
Таким образом, отдельно настраиваются правила нормализации для входящего направления и для исходящего направления.
Правила нормализации могут быть протестированы в АРМ администратора (Маршрутизация - Тестирование - Подмена).
Маршрут для входящих.
Попадая на b2b, запрос INVITE уже прошел нормализацию и имеет привязку к внутреннему номерному плану. Звонок, поступивший от провайдера, можно аналогично другим звонкам маршрутизировать любым образом. Обычно звонки от провайдеров маршрутизируют:
-
на голосовые сервисы (IVR);
-
в очереди КЦ;
-
на групповые номера;
-
на персональные внутренние номера, если номер выделен как персональный, либо в задачи абонента, имеющего указанный номер, входит ответ на вопросы.
Очевидно, их можно отправлять в другие домены, перенаправлять наружу через других провайдеров или отказывать в обслуживании.
Cледует избегать разрешения набирать добавочные номера (в IVR) и без проверки и дополнительных фильтров отправлять их на различные сервисы.
Маршрут для исходящих.
Чтобы отправить вызов на провайдера, в маршрутизации следует настроить правило с действием 'external' и указанием кода провайдера. Алгоритм поведения был рассмотрен ранее в разделе "Исходящий звонок".
Лог журналы.
Лог журналы, касающиеся работы с учетными записями провайдеров телефонии, ведутся микросервисами 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).
Регистрация
Для провайдеров с регистрацией для отслеживания корректности процесса регистрации можно искать запросы REGISTER, например:
09:10:33.060 <0.685.0> Send to udp 192.168.0.112:5060 (ok) REGISTER sip:test.era-platform.ru SIP/2.0 Via: SIP/2.0/UDP 192.168.0.112:5080;rport;branch=z9hG4bK2w1opp-10Y8e1 From: <sip:provider@test.era-platform.ru>;tag=3ZxqYI To: <sip:provider@test.era-platform.ru> Call-ID: Z76iX6vyAeqyWKi9hEp5DHUJ3le CSeq: 309187562 REGISTER Max-Forwards: 70 Content-Length: 0 Route: <sip:192.168.0.112;lr> Contact: <sip:provider@192.168.0.112:5080> Supported: path Expires: 3600 Authorization: Digest username="provider", realm="b2b_1006__test.era-platform.ru", nonce="KXapTShGqTzV5d0QAu7ddHRls9s", uri="sip:test.era-platform.ru", response="e1a569e736485e2eed64af1990cf4727", algorithm=MD5, qop=auth, cnonce="auBMkM6dgdpbzM8neoqG1dxmndx", nc=00000001, opaque="1WVpoo" User-Agent: Era 1.8.3 Allow: INVITE,ACK,CANCEL,BYE,REFER,NOTIFY,OPTIONS,INFO,MESSAGE 09:10:33.072 <0.685.0> Recv from udp 192.168.0.112:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.0.112:5080;rport=5080;received=192.168.0.112;branch=z9hG4bK2w1opp-10Y8e1 From: <sip:provider@test.era-platform.ru>;tag=3ZxqYI To: <sip:provider@test.era-platform.ru>;tag=rB2-0GE-QA9Q Call-ID: Z76iX6vyAeqyWKi9hEp5DHUJ3le CSeq: 309187562 REGISTER Max-Forwards: 70 Content-Length: 0 Contact: <sip:provider@192.168.0.112:5080>;expires=3600 Supported: path Allow: REGISTER,INVITE,ACK,CANCEL,BYE,REFER,NOTIFY,OPTIONS,INFO,SUBSCRIBE,MESSAGE,UPDATE Date: Wed, 05 Apr 2023 06:10:33 GMT Path: <sip:r_Q19NAi5@192.168.0.112:5060;transport=tcp;lr>
Примеры неудачной регистрации:
-
отправка нескольких запросов REGISTER подряд с растущей паузой между ними и без ответа на них.
-
слово BANNED в строке Recv (например:
15:00:11.042 <0.692.0> Recv from udp 192.168.0.112:5060 BANNED) - означает, что включен пограничный фильтр, но адрес отправителя не внесен в список разрешенных. Если адрес соответствует тому, на который сервер отправлял перед этим REGISTER, то причина в этом.
Звонки
Звонок инициируется запросом INVITE. Для анализа происходящего с пакетами INVITE следует: обнаружить пакет в лог журнале, по Call-Id найти соответствующие ему другие пакеты сессии, найти ответ. В случае отказа платформой в ответе можно обнаружить заголовок Reason, раскрывающий подробности отказа.
Если вызов снаружи не проходит, и не обнаруживается INVITE, то возможны следующие варианты:
-
Обнаружено слово BANNED - проверить адреса провайдера на предмет включения в пограничные фильтры.
-
Учетная запись без регистрации, порт esg отличается от порта, на который шлет запросы провайдер. Например провайдер шлет на 5060, а в платформе esg порт по умолчанию 5080.
-
Можно использовать трассировку пакетов, в этом случае трассировка проходит ниже платформы, в операционной системе, и сможет показать пакеты, которые действительно поступают на сервер. В них можно обнаружить и реальный порт. Можно использовать утилиты tcpdump, tshark.
mkdir pcaps sudo chmod 777 pcaps sudo tshark -i eno1 -f "host 44.55.66.77" -w pcaps/trace.pcap ps ax | grep tshark sudo chmod 775 pcaps/trace.pcap rsync -avrh --progress pcaps/trace.pcap ... sudo rm -r pcaps
tcpdump -i any -nn -w temp.pcap
В любом случае в случае каких-то осложнений с проходом звонка, необходимо анализировать SIP-трафик. Это логи trn на всех микросервисах, обслуживающих SIP: esg, b2b, sg, ivr, conf, prompt.
Диаграмма
В случае, если вызов дошел до b2b, и создался диалог, то его можно обнаружить в АРМ администратора домена (Мониторинг - Звонки).
А при выделении курсором - выполнить действие "Диаграмма". В результате, если включены trn-логи на микросервисах, через которые прошел звонок, на экране отстроится диаграмма последовательности с доступом ко всем пакетам, относящимся к звонку.
Логика esg
Логика 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 полностью заменяет CallId при отправке вызова в другое плечо, отсутствует проблема с паразитными зацикливаниями.
Сетевые интерфейсы и порты
Экземпляры esg, как и других микросервисов, отвечающих за SIP-сигнализацию, поднимают слушателей на всех интерфейсах (0.0.0.0). Порты указываются в конфигурации для каждого отдельного экземпляра микросервиса, но указанные порты относятся ко всем интерфейсам соответствующего сервера. Это означает, что платформу без дополнительной модификации нельзя тонко настроить на прослушивание специфических портов на специфических интерфейсах.
В шаблонных конфигурациях роли esg присваиваются порты 5080, 5081. На этих портах на всех интерфейсах сервера, где исполняется соответствующий экземпляр esg, поднимаются слушатели, также с них происходит отправка UDP-пакетов сигнального протокола.
Существуют случаи, когда определенный провайдер требует от клиента порт 5060. В этой связи следует настраивать порт 5060 для esg. Тогда же может потребоваться изменять также порты и для экземпляров sg. Исключением может являться только ситуация, когда экземпляры esg и sg исполняются на разных серверах. По мере убывания удобства рекомендуются следующие варианты:
-
Изменить требования провайдера, допустив для клиента использование локального порта 5080.
-
Развести экземпляры esg и sg по разным серверам при их достаточном количестве, и использовать 5060 для обоих типов.
-
Смена портов - 506X для esg, 508X для sg. Требует перенастройки всех внутренних устройств, ранее настроенных на подключение к серверу на порт 5060.
Использование bgmg
Показанием к применению bgmg является лишь одна из ситуаций в многосерверной разрвертке платформы:
-
подсеть, к которой относится провайдер, не адресуется с части серверов кластера развернутой платформы (более точно: с части серверов, где исполняются mg);
-
провайдер требует совпадения клиентских адресов для сигнального трафика и медиа-трафика.
Для таких провайдеров необходимо включить режим media=true, reinvite=false. А для обеспечения поддержки этого режима необходимо в конфигурацию добавить по паре экземпляров bgmg на те же серверы, где исполняются esg (которые в соответствие с настройками и размещением учетных записей провайдеров могут их обслуживать)
Работа за NAT
Провайдеры телефонии в подавляющем числе случаев работают с устройствами, подключаемыми из-под NAT. Эти устройства разнообразны, настройки NAT разнообразны, поэтому в целях сокращения количества проблемных ситуаций, отправка звука, как правило, производится на адрес и порт, с которого звук поступает на порт, объявленный провайдером в SDP. Подобное поведение позволяет не замечать проблем с двусторонним прохождением звука.
Если в такой конфигурации наблюдается односторонняя слышимость, то следует настраивать прямой маппинг портов на NAT. Это может потребоваться, если:
-
Производится настройка с внешней АТС или провайдером, не поддерживающей или не настроенной на отправку RTP пакетов на обратный адрес отправителя входящего RTP.
-
Необходимо обеспечить возможность маршрутизировать входящий вызов сразу на внешний номер за той же учетной записью.
Сама платформа всегда перенаправляет пакеты на обратный адрес отправителя входящего трафика. Такой алгоритм показывает свое статистическое превосходство.
SIP-ALG
Особый случай NAT, когда сервер извне доступен по белому адресу, который отсутствует среди локальных интерфейсов.
В этом случае, и возможно в некоторых других случаях, требуется подмена адресов в пакетах - локального (серого) на внешний (белый) в исходящих пакетах, и внешнего (белого) на локальный (серый) во входящих пакетах. Для этого можно использовать настройку SIP-ALG на сетевом раутере, а если это невозможно, то настроить эту опцию в настройках экземпляра esg.
Каждый пакет, проходящий через настроенный таким образом экземпляр, будет подвергаться модификации. Адреса будут подменяться в соответствии с направлением пакета. Для входящих пакетов модификация проводится сразу после SBC-фильтра еще до маршрутизации и нормализации номеров. Для исходящих пакетов модификация проводится после маршрутизации и нормализации непосредственно перед отправкой в сеть.
Настройка SIP-ALG предполагает безусловную подмену 1 к 1 локального (серого) адреса к внешнему (белому) адресу. Таких связок может быть несколько. Например:
"sip_alg": [
{"gray":"172.16.0.14","white":"62.85.127.4"},
{"gray":"172.16.0.15","white":"62.85.127.5"}
]
Подключение провайдера по TLS
Подключение по TLS осуществляется в обе стороны - от платформы к провайдеру, и от провайдера к платформе. Различается процедура настройки учетной записи с регистрацией и учетной записи без регистрации.
Удаленной стороне необходимо подключаться к порту с проверкой сертификата. Это особенно критично для подключений без регистрации, а также для клиентов проверяющих доверенную цепочку. Как правило подключение оборудования осуществляется без передачи SNI сразу на IP-адрес - он либо регистрируется изначально (подключение без регистрации), либо является контактным адресом из запроса на регистрацию (подключение с регистрацией).
Под TLS-подключения (и даже под каждое TLS-подключение) в конфигурации может быть создан отдельный экземпляр ESG на уникальном порте с прописанным в конфигурации для этого экземпляра сертификатом (параметр certdir). По умолчанию при отсутствии параметра certdir и параметра SNI в TLS Client Hello выдается самоподписной сертификат (имеющий проблемы с прохождением проверки подлинности цепочки на клиентской стороне).
Таким образом в системе существует экземпляр ESG, для которого конфигурацией задан актуальный сертификат. Удаленной стороне при этом по запросу может быть передана доверенная цепочка этого сертификата.
|
Настраивая учетную запись провайдера, необходимо привязать ее к вышеупомянутому экземпляру ESG, если их несколько (параметр srvidxs). Обслуживать подключение должен экземпляр, использующий по умолчанию тот сертификат (certdir), доверенная цепочка которого передана провайдеру для настройки TLS подключения. |
В свою очередь, если от провайдера получена доверенная цепочка его сертификата, ее следует разместить в PEM-файле, и прописать макро-путь к нему в параметр учетной записи провайдера certificate_pem. Например, загрузив сертификат на эндпойнт /rest/v1/fs/targets/files/certificates/some.pem, путь к нему можно указать как ':SYNC_DOMAIN_DATA/files/certificates/some.pem'.
| Для успешной проверки платформой доверенной цепочки сертификатов важно, чтобы в качестве домена (или адреса proxy) указывалось то имя, на которое выписан сертификат. Его можно обнаружить в сообщении Server Hello от провайдера из дампа TLS-подключения. |
| Если возникают сложности с проверкой цепочки, то поле 'certificate_pem' можно оставить пустым. Тогда в версиях платформы 1.8.* проверка доверенной цепочки не будет осуществляться. |
Следить за ходом подключения на этапе настройки можно с помощью лог-журналов ESG и трейсов TSHARK, снятых на сервере с ESG с фильтром по айпи адресу удаленной стороны.
При настройке учетной записи без регистрации, внимание стоит обратить также на значение поля 'localdomain'. Туда следует явно размещать доменное имя или адрес, по которому возможно подключение от провайдера. При подключении через NAT нужно провести соответствующие настройки.
|
Чтобы при TLS подключении использовался шифрованный канал передачи медиа-трафика (SRTP), необходимо:
|
Если разные подключения должны использовать разные порты, собственные локальные сертификаты, режимы SRTP, то их следует привязывать к разным экземплярам ESG.