Настройка исходящей связи по регионам с помощью диалплана и базы

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

Сейчас у большинства компаний используются многоканальные номера. Предположим, что часть сотрудников должна выходить на, к примеру, Новгород с одним CallerID, другая часть с вторым, третья – с третьим. При этом офис компании находится в Москве, кроме Новгорода существует ещё множество городов, на которые идут звонки, да и сотрудников в компании немало. При таком раскладе, делать множество маршрутов в FreePBX или же диалплане asterisk нецелесообразно. Особенно, если по какой-то причине нельзя разграничить по внутренним номерам, кто, куда и с каким номером должен выходить. Поэтому здесь лучше всего воспользоваться региональной исходящей маршрутизацией и объединить все возможные маршруты с помощью базы данных.

Шаг 1. Работа с базой данных

Выписка из российского реестра

Для начала нам нужно взять данные из реестра российской системы. Посмотреть, как это сделать, можно в статье: «Региональная маршрутизация».

Создание групп пользователей

Для удобства и минимизирования диалплана, который будем писать в дальнейшем, обратимся к базе данных и создадим таблицу group_ext. По ней будем определять: 1) можно ли внутреннему номеру звонить на междугороднее направление; 2) если можно – из неё возьмём номер группы для дальнейшей маршрутизации.

Для создания таблицы введём команду:

CREATE TABLE group_ext (number varchar(30) NOT NULL, grouping varchar(30) NOT NULL);

Затем подготовим файл для импортирования его в таблицу. Для этого можно либо произвести выгрузку номеров из таблицы (например, для Asterisk Vanilla), либо, при использовании web-интерфейса, воспользоваться соответствующим модулем. Так как реализация данного функционала проводится для дистрибутива VoxDistro, в котором имеется FreePBX 13, воспользуемся модулем Bulk Handler.

Подробнее о работе с модулем Bulk Handler можно прочитать в данной статье.

Затем откроем файл с помощью любого табличного редактора (например, OpenOffice Calc). Здесь потребуется удалить все строки и столбцы, кроме тех, в которых прописаны внутренние номера. В столбце рядом прописываем номера групп. Сохраняем файл с нужными разделителями в формате csv и загружаем его на сервер.

Теперь произведём импорт таблицы. Для этого введём команду:

LOAD DATA INFILE '/tmp/group_ext.csv' INTO TABLE group_ext FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\n';

Должно получиться так, как на скриншоте ниже:

Таблица маршрутизации

Теперь нам потребуется таблица маршрутизации. Она будет создана на основе данных из реестра российской системы и таблицы групп пользователей. Эта таблица будет состоять из полей region, grouping, cid, trunk.

CREATE TABLE out_routes_region (region varchar(255) NOT NULL, grouping varchar(30) NOT NULL, cid varchar(80), trunk varchar(255), KEY region (region), KEY groupping (groupping));

Конечно в статье мы не будем рассматривать маршрутизацию на все регионы, так как даже с учётом того, что были введены группы, файл будет достаточно большим. Для примера возьмём следующие регионы: Санкт-Петербург, Краснодарский Край, Астраханская область, Омская область и Ненецкий Автономный округ.

Заполняем таблицу данными. Лучше всего будет сначала сделать таблицу в табличном редакторе, затем произвести её импорт. Обязательными полями должны быть регион, куда звоним, и группа внутренних номеров. Поля cid и trunk могут принимать и пустые значения. Например, если группе будет разрешено звонить по одним регионам, а по другим нет.

У нас получилась такая таблица:

Теперь перейдём к созданию необходимых запросов.

Шаг 2. Работа с ODBC

О том, как связать Asterisk и ODBC подробно можно посмотреть в данной статье.

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

Всё, что требуется от самого запроса – наличие соответствия внутреннй номер -> группа. Поэтому в func_odbc.conf поместим:

[GROUP]
dsn=asteriskcdrdb
readsql=SELECT grouping FROM group_ext WHERE number='${ARG1}'

Вторым запросом получим регион из таблицы tel_codes. Получать его будем по коду города набранного номера. Для этого пропишем:

[REGION]
dsn=asteriskcdrdb
readsql= SELECT region FROM tel_codes WHERE prefix='${ARG1}' AND ${ARG2} >= num_from AND ${ARG2} <= num_to LIMIT 1

Теперь последний запрос. С помощью него выведем CallerID, который должен быть у определённой группы, и имя транка.

[ROUTING]
dsn=asteriskcdrdb
readsql=SELECT cid, trunk FROM out_routes_region WHERE region='${ARG1}' AND grouping=${ARG2}

Осталось только применить изменения в файле func_odbc.conf.

Шаг 3. Диалплан

На текущем моменте можно перейти к прописыванию диалплана – файл extensions_custom.conf (для FreePBX и подобных дистрибутивов).

Обычно у вызовов в город логика совершенно другая, поэтому региональную маршрутизацию делают только под междугородние направления. Так и в примере: городские вызовы не будут входить в региональную маршрутизацию – только междугородние. В дитрибутиве VoxDistro маршрут на междугородние направления заранее создан, поэтому остаётся 2 пути: либо удалять его полностью, либо оверрайдить. Мы воспользуемся вторым способом.

Для этого в extensions_override_freepbx.conf в нужном контексте сделаем ссылку на контекст из файла extension_custom.conf. Затем перейдём к прописыванию нового контекста.

[out-region-routes]
exten => _8[3-58]XXXXXXXXX,1,Set(NUMBER=${EXTEN})
same  => n,Set(GROUP=${ODBC_GROUP(${CALLERID(num)})})
same  => n,GotoIf($["${GROUP}" != ""]?region:hangup)
same  => n(hangup),Playback(custom/not_routing)
same  => n,Hangup()
same  => n(region),Set(PREF=${NUMBER:1:3})
same  => n,Set(NUM=${NUMBER:4:7})
same  => n,Set(RES=${ODBC_REGION("${PREF}","${NUM}")})
same  => n,Set(REGION=${POP(RES,|)})
same  => n,Set(ARRAY(CID,TRUNK)=${ODBC_ROUTING(${REGION},${GROUP})})
same  => n,GotoIf($["${CID}" != ""] | $["${TRUNK}" != ""]?out:hangup)
same  => n(out),Set(CALLERID(all)=${CID})
same  => n,Dial(SIP/${TRUNK}/${EXTEN})
same  => n,Hangup()

Рассмотрим, что прописано в диалплане.

Номер, на который звоним, заносим в переменную ${NUMBER}. Затем по номеру звонящего, проверяем группу, в которой он находится. Если группа пуста – проигрываем сообщение о завершении вызова и отбиваем вызов. Если не пуста, то на данном этапе для внутреннего номера никаких ограничений нет, и мы перенаправляем вызов дальше.

Номер, на который звоним, разбиваем на две составляющие – код города и сам номер. По этим данным в таблице tel_codes находим регион, на который звоним. Из полученного региона убираем всё с конца до разделителя “|” – этим получаем окончательный вариант региона.

Затем по региону и группе находим внешний номер и имя транка. С найденного внешнего номера будем звонить на этот регион, поэтому номер подставляем в переменную ${CALLERID(all)}, тем самым меняя и ${CALLERID(num)}, и ${CALLERID(name)}. После этого отправляем вызов на полученный транк с номером, на который звоним.

Для проверки данного функционала рассмотрим три вызова.

Вызов 1

В первом вызове мы будем звонить с номера 0008.

Из лога видно, что 0008 состоит в группе 1 и звонит на номер г. Санкт-Петербурга. Так как группа для данного номера есть, звонить ему по этим направлениям можно. Остаётся только проверить, что не запрещены звонки именно на г. Санкт – Петербург. Но и туда этому внутреннему номеру звонить можно. Поэтому звонок проходит с нужного номера через нужный транк.

Вызов 2

В этом вызове будем звонить с номера 0011.

Из лога видно, что номер 0011 находится во второй группе, поэтому здесь наш вызов идёт дальше. Затем определяем, что звоним в Астраханскую область. После этого видим отбой, так как номерам из второй группы звонить в данный регион нельзя.

Вызов 3

Теперь позвоним с номера 2234.

Здесь ситуация достаточно проста – номера 2234 нет ни в одной из созданных групп. Поэтому вызов будет отбит сразу.

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