11 марта 2015 в 13:16

Астериск: маршрутизация по номеру звонящего и коду региона

Информация далее, возможно, будет интересна тем, кто использует астериск, получает на него номер 8-800 и имеет абонентов в офисах, которые расположены в нескольких городах РФ.

Мое решение классической задачи астерискера-телефониста: бизнес хочет, чтобы на звонки Дальнего Востока отвечал офис во Владивостоке, звонки Урала и Сибири — офис в Новосибирске, а на все остальные — офис в Москве.

Можно воспользоваться вариантом, представленным ранее на Хабре в статье, но я решил сделать решение немного более универсальным. Далее детали реализации и видео-инструкция.


Решение такое: вынести работу с определением региона по номеру телефона за рамки диалплана астериска. Т.е. мы реализуем логику определения кода региона по номеру звонящего на стороне AGI-сервера. Астериск не имеет понятия каким образом работает AGI-сервер, где он берет данные, на каком языке он написан, но получает в результате запроса код региона, и уже далее продолжает обрабатывать звонок по диалплану.

Схема работы



Как реализован AGI-сервер?

AGI-сервер — в нашем случае, это nodejs-приложение, которое, получив запрос с номером, обращается в MongoDB, находит соответствие и устанавливает необходимое значение переменной диалплана REGION_CODE.

Какой получается диалплан?

Диалплан использования AGI-сервера получается примерно такой:

[incoming]
exten => 88001234567,1,AGI(agi://localhost:3000,${CALLERID(num)})
exten => 88001234567,n,GotoIf($[${REGION_CODE}=24]?outbound,krasnoyarsk,1:)
exten => 88001234567,n,GotoIf($[${REGION_CODE}=50]?outbound,moscow,1:outbound,other,1)


Для каждого региона необходимо указывать свою проверку?

Если у вас есть офисы в каждом регионе РФ (а их у нас 85), то, вероятно, стоит настроить проверку каждого кода. Но обычно требуется менее детальное деление РФ, поэтому также устанавливается переменная COUNTY_CODE — номер федерального округа (а их у нас всего 9).

Т.е. диалплан может выглядеть следующим образом:

[incoming]
exten => 88001234567,1,AGI(agi://localhost:3000,${CALLERID(num)})
exten => 88001234567,n,GotoIf($[${COUNTY_CODE}=5]?outbound,krasnoyarsk,1:)
exten => 88001234567,n,GotoIf($[${COUNTY_CODE}=1]?outbound,moscow,1:outbound,other,1)


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

Как это можно реализовать в пользовательском интерфейсе?

Например, у меня в пользовательском интерфейсе настройка маршрутизации по номеру звонящего выглядит так



Данные с кодами и названиями можно взять в npm russian-codes и использовать в выпадающих меню.

А откуда данные в MongoDB для AGI-сервера?

Данные, обычно, расположены на сайте Федерального агентства связи в разделе "Открытые данные". Как мы скачиваем и преобразуем в JSON я уже писал на Хабре. Но в текущем формате данных numcap регион указан строкой с названием региона, а не его кодом, что не очень удобно.

Поэтому, используя npm numcap-regions (который в свою очередь использует npm'ы numcap и russian-codes) мы можем получить большой JSON-файл с емкостью операторов РФ с указанием кодов регионов.

А нужно ли обновлять базу с данными по кодам регионов?

Можно загрузить один раз и так и использовать. Но утилиты в указанных npm можно использовать для регулярного обновления данных.

Федеральное агентство связи регулярно вносит изменения в реестр нумерации, поэтому несложно всегда иметь достаточно актуальную базу данных. Хотя, конечно, номера телефонов вряд ли резко сменят регион (а по операторам необходимо провести дополнительную обработку данных). Данные в numcap я обновляю примерно раз в месяц.

Итак, что мне сделать, чтобы у меня заработала маршрутизация по номеру и коду региона?

1. Установить agi-number-archer-app (Установка подробно описана в репозитории agi-number-archer-app, его можно клонировать, записать свои конфиги, скрипты деплоя).

2. Загрузить данные в MongoDB (для загрузки данных воспользуйтесь numcap-regions, использование также описано в репозитории).

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

Вопросы, пожелания, критические замечания приветствуются.

P.S. Видео с пошаговой настройкой сервиса.
Дмитриев Сергей @antirek
карма
51,7
рейтинг 0,0
Пользователь
Похожие публикации
Самое читаемое Разработка

Комментарии (13)

  • 0
    имхо, если решил упрощать dialplan, то надо всю логику по определению направления выносить в скрипт и на выходе только направление получать

    завтра ты временные параметры захочешь добавить, послезавтра мобильщиков отдельно обслуживать
    • +2
      тут дело не в упрощении, а в разделении логики.

      Например, в приведенной выше статье мне не нравится использование odbc-функций, т.к. получается, что астериск «знает» БД. Дальше там в комментариях приводятся скрипты. А скрипты сегодня работают, а завтра что-то поменял и «все сломалось».

      То ли дело отдельный сервис по определению направления, покрытый тестами, который имеет очень простой интерфейс взаимодействия. Диалплан «ведет» звонок, а agi-сервис в нужный момент просто подставляет переменную.
  • +1
    А это актуально? На долго ли? Всё чаще люди пользуются переносом номера от провайдера к провайдеру, то есть какой-то процент будет ошибочным.
    • +1
      Перенос номера возможен только в пределах региона, т.е. смена провайдера не меняет регион.
      За исключением йоты.
    • 0
      1. в России порядка 240 млн.абонентов сотовых операторов (пруф)
      2. еще есть стационарные телефонные сети порядка 40 млн.абонентов (пруф)
      3. услугой по смене сотового оператора с сохранением номера воспользовались чуть более 1 млн.абонентов (данные на сайте ФАС в правой колонке)
      4. не изменяется регион (возьмем, например, правила МТС)

      Поэтому можно сказать, что ошибка неверного определения региона номера звонящего минимальна.

      Вот с определением оператора мобильного номера, вероятность ошибки уже 1/240 — тут да, надо проверять на np.zniis.ru
      • 0
        Вот с определением оператора мобильного номера, вероятность ошибки уже 1/240 — тут да, надо проверять на np.zniis.ru
        А вот это вы делаете как-то в автоматическом режиме?
        У них есть API или всё на самописных скриптах?
        • 0
          Я это не делаю. У ЦНИИС нет API. Раньше можно было дергать запросом, сейчас там повешали капчу. Есть ли еще у кого-то API? Не знаю.
    • +1
      Сотовые операторы периодически перекидывают диапазоны номеров из региона в регион, раз в месяц надо бы обновлять данные, чтобы поддерживать актуальность
      • 0
        Да, данные периодически меняются. При чем не только мобильные операторы, но и Федеральное агентство связи регулярно проводит работу по изменению диапазонов, смены операторов и т.д.
        В репозитории numcap если посмотреть коммиты, то можно увидеть что меняется из месяца в месяц, также есть команды для актуализации данных.

  • +1
    По поводу данных, интересно как Вы преобразовали регионы (там где указана только область и там где указана и область и город). Как отрабатывается в базе поиск регионального офиса, если в выбранном регионе нет выхода? Например звонок из Омска, имеет смысл послать входящий в Новосибирск.
    • 0
      1. Определение региона при преобразовании БД numcap как раз и идет по наличию признака региона: 'область', 'край' и т.д., т.е. если указано «Новосибирск | Новосибирская область» будет установлен код Новосибирской области.

      2. Логику маршрутизации можно построить в астериске по-разному: перечислить коды нужных регионов и отправить их по одному маршруту или воспользоваться номером федерального округа (Омская и Новосибирская области относятся к Сибирскому ФО) и для него указать свой маршрут.
      • +1
        То бишь автоматической таблетки не придумано? Я просто мыслил что-то по аналогии с GeoIP только с учетом стоимости звонка на направление в целом или по ближайшему региону к звонящему.
        Опять же вариант с роумингом — звонок на 8-800, попадаем в Нск, а надо в Мск, так как я тут в коммандировке. А так как роуминг, то и ценник выше будет для таких звонков. Хотя вряд ли мобильный оператор поделится регионом откуда пришел звонок.
        • 0
          Если бы в роуминге ваш номер подменялся на какой-то номер из зоны присутствия, тогда можно было бы сделать по аналогии с GeoIP. А так да, возможны накладки.

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