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

    Информация далее, возможно, будет интересна тем, кто использует астериск, получает на него номер 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. Видео с пошаговой настройкой сервиса.
    Поделиться публикацией
    Похожие публикации
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 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. А так да, возможны накладки.

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