Целью процесса маршрутизации является нахождение интерфейса вызываемого абонента для адресации ему вызова.

Входящий вызов из IP-транка или от абонента поступает на входящий интерфейс. Посредством протокола RADIUS (если используется) определяется возможность дальнейшей маршрутизации вызова. Далее в определенном контексте маршрутизации виртуальной АТС, который соответствует входному интерфейсу, выполняется обработка вызова. Проверяются условия отбора вызова (анализ номеров вызываемого, вызывающего абонентов, день недели, время суток) на соответствие одному из правил контекста маршрутизации.
При необходимости производится модификация входных данных вызова и осуществляется маршрутизация по заданным параметрам — на абонента, на внешнее направление, в другой контекст маршрутизации:

если согласно правилу будет определено, что вызов нужно адресовать локальному абоненту или на внешнее направление, то выполняется соответствующая маршрутизация;
если исходящее направление недоступно, то вызов будет переадресован на резервное направление (резервное направление должно быть настроено);
если будет определено, что данных для маршрутизации недостаточно, то возвращается результат, сообщающий о неполноте номера: number_incomplete;
если изменяется текущий контекст, то маршрутизация будет продолжена в указанном контексте, обработка в котором снова будет начинаться с проверки условий отбора вызова;
если вызов был переадресован, то будет произведена повторная маршрутизация для нового вызова (абонент который переадресовывал вызов и абонент куда был переадресован вызов должны иметь между собой маршрут);
если в контексте не нашлось удовлетворяющего требованиям правила, то возвращается ошибка маршрутизации

Общая схема прохождения телефонного вызова через маршрутизацию ECSS-10

Общая схема прохождения телефонного вызова представлена на рисунке 1.

Рисунок 1 — Общая схема прохождения телефонного вызова

Входящий вызов из IP-канала поступает на входящий интерфейс (SIP-транк). Из свойств SIP-транка определяется контекст маршрутизации по умолчанию, и маршрутизация вызова начинается в данном контексте. При входе в контекст маршрутизации проверяется его "план нумерации". Если он отличается от "плана нумерации" контекста, из которого мы пришли, то для абонента А выставляются свойства, заданные в плане нумерации нового контекста. Далее выполняется непосредственно маршрутизация вызова, включающая модификации номеров и свойств абонентов А, Б,
переходы между контекстами маршрутизации (в рамках одного контекста маршрутизации) с возможной сменой планов нумерации.

Маршрутизация продолжается до тех пор, пока не будет найден исходящий маршрут, или будет определено, что маршрута нет, либо количество переходов из одного правило в другое не превысит 1000 итераций.
При выходе на локального абонента ECSS-10 для абонента Б применяются свойства, заданные в плане нумерации контекста маршрутизации, в котором
был найден маршрут. После чего вызов направляется на SIP/Megaco-абонента.

При выходе на набор исходящих транков, если один из транков не доступен, вызов будет направлен на следующий в списке транк. Такой перебор будет выполняться до тех пор, пока есть хотя бы один транк, на который не было попытки направить вызов. При выходе на исходящее направление определяется список транков, входящих в данное направление, и вызов отправляется как на "набор исходящих транков" (описано выше).

Входящий вызов от SIP-абонента поступает на входящий SIP-интерфейс, посредством RADIUS (если данный протокол используется) определяется возможность дальнейшей маршрутизации вызова. Из свойств SIP-абонента определяется контекст маршрутизации по умолчанию, и маршрутизация вызова начинается в данном контексте. Далее маршрутизация отрабатывает точно так же, как в случае вызова с SIP-транка.
Входящий вызов от Megaco-абонента поступает на входящий Megaco-интерфейс. Из свойств Megaco-абонента определяется контекст маршрутизации по умолчанию, и маршрутизация вызова начинается в данном контексте. Далее маршрутизация отрабатывает точно так же, как в случае вызова с SIP-транка.

Рекомендуемая схема построения контекстов маршрутизации для "УПАТС с выходом на город"

В данном разделе рассмотрен пример построения контекстов маршрутизации для виртуальной АТС, которая позиционируется как УПАТС с выходом на город через SIP-транк или через bridge-интерфейс.

Общая схема построения контекстов маршрутизации представлена на рисунке 2.

Рисунок 2 — Общая схема построения контекстов маршрутизации

В данной виртуальной АТС выделено два плана нумерации: "внутренний план нумерации" и "городской план нумерации". Через внутренний план нумерации проходят все вызовы в рамках данной АТС. Именно в нем выполняется непосредственно маршрутизация вызова. Через городской план нумерации мы позволяем нашим абонентам выходить на город под городскими номерами. Все локальные абоненты, а также транки имеют дефолтный контекст маршрутизации во внутреннем плане нумерации.

Рассмотрим различные комбинации прохождения вызова по данной схеме.

1. Общая схема прохождения

Вызов поступает с локального SIP/Megaco-абонента, направляется в контекст маршрутизации, установленный по умолчанию, во внутреннем плане нумерации. В данном контексте происходит приведение номеров абонентов А, Б к внутреннему формату номеров, по которому выполняется маршрутизация вызовов, выставление свойств этих номеров. Данную фазу маршрутизации назовем "модификация по входу".

Далее, вызов направляется в корневой контекст внутреннего плана нумерации для непосредственного выполнения маршрутизации. Во время маршрутизации не предполагается изменение номеров А, Б, а также их свойств, но возможны переходы между контекстами. Когда маршрутизация обнаружила исходящее направление, она переходит в специальный контекст маршрутизации, который занимается преобразованием номеров и их свойств для выхода на данное направление, установление СОРМ-номеров для абонентов, если это необходимо. Данную фазу назовем "модификация по выходу".
По выходу из данного контекста мы имеем номера А, Б а также их свойства такими, которые понимает сторона Б.

2. Вызов с локального абонента на локального абонента

Вызов приходит с локального SIP/Megaco-абонента. Вызов направляется во внутренний план нумерации, выполняется "модификация по входу" для абонентов А, Б, после выполняется маршрутизация вызова. В ходе маршрутизации было определено, что абонент Б - локальный абонент, абонент данной виртуальной АТС. Поэтому маршрутизация переходит в контекст, предназначенный для модификации номеров при выходе на локальных абонентов, если это необходимо. В данном контексте выполняется модификация, после вызов отправляется на локального абонента.

3. Вызов с локального абонента на город

Вызов приходит с локального SIP/Megaco-абонента. Вызов поступает во внутренний план нумерации, выполняется "модификация по входу" для абонентов А, Б, после выполняется маршрутизация вызова. В ходе маршрутизации было определено, что абонент Б - городской абонент. Поэтому изменяем план нумерации на городской, путем перехода в один из контекстов маршрутизации в городском плане нумерации. При переходе в городской план нумерации для абонента А будут автоматически выставлены свойства "apri", "nai", "ni", "npi", "screening" для городского плана нумерации, а также номер абонента А, если у него прописан номер для городского плана нумерации. Далее, маршрутизация продолжается в городском плане нумерации. Когда маршрутизация определит направление (транк, bridge-интерфейс) вызова, будет выполнен переход в контекст маршрутизации для выхода на данное направление. В данном контексте маршрутизации будет выполнена "модификация по выходу", и вызов будет направлен на SIP-транк или bridge-интерфейс на город.

4. Вызов с города на локального абонента

Вызов поступает с города (SIP-транк или bridge-интерфейс) на локального абонента. Вызов направляется в городской план нумерации, для абонента А автоматически выставляются свойства "apri", "nai", "ni", "npi", "screening", выполняется "модификация по входу". Далее, выполняется маршрутизация вызова. Маршрутизация определяет, что вызов поступил на локального абонента. Поэтому происходит переход в контекст маршрутизации, предназначенный для модификации номеров при выходе на локальных абонентов, если необходимо. В данном контексте выполняется "модификация по выходу", после вызов отправляется на локального абонента. При выходе на локального абонента система по номеру абонента Б в городском плане нумерации выполняет поиск абонента данной АТС, у которой в городском плане нумерации выставлен номер Б, который получили в результате маршрутизации. Если таких абонентов больше чем один, то выбирается абонент, на который был данный номер установлен первым. И вызов направляется на данного абонента. Если абонент не найден, вызов отбивается.

Схема подключения УПАТС к городу через транзитную АТС

В данном примере рассмотрим ситуацию, когда УПАТСы для выхода "на город" используют центральную АТС (выход на центральную АТС осуществляются через Bridge).

Рисунок 4 — Схема подключения УПАТС к городу через транзитную АТС

1. Абонент УПАТС #1 звонит в город

Вызов поступает с локального SIP/Megaco-абонента, направляется во внутренний план нумерации, выполняется "модификация по входу" для абонентов А, Б, после чего выполняется маршрутизация вызова. В процессе маршрутизации было определено, что абонент Б - городской абонент. Поэтому изменяем план нумерации на городской, путем перехода в один из контекстов маршрутизации в городском плане нумерации. При переходе в городской план нумерации для абонента А будут автоматически выставлены свойства "apri", "nai", "ni", "npi", "screening" для городского плана нумерации, а также номер абонента А, если у него прописан номер для городского плана нумерации. Далее, маршрутизация продолжается в городском плане нумерации. Когда маршрутизация определит направление вызова (находит bridge-интерфейс), будет выполнен переход в контекст маршрутизации для выхода на данный bridge-интерфейс. В данном контексте маршрутизации будет выполнена "модификация по выходу", в рамках которой номера абонентов А, Б, а также их свойства будут приведены к понятному в "Центральном домене" виду. Далее, вызов направляется в найденный bridge-интерфейс, пройдя через который попадает в "центральный домен" через "Входящий бридж-интерфейс УПАТС #1". В центральном домене вызов направляется в контекст маршрутизации по умолчанию для данного bridge-интерфейса, где могут быть выполнены приведения номеров А, Б, а также их свойств к внутреннему плану нумерации. Также в данном контексте может быть добавлена проверка на корректность номеров А, Б, пришедших с bridge-интерфейса. Далее, на основе модифицированных данных выполняется маршрутизация вызовов, по результатам которой будет найден маршрут до города. После этого вызов переходит в "контекст маршрутизации для модификации номеров и их свойств по выходу на город", где выполняется "модификация по выходу". Вызов поступает в направление до города.

2. С города поступает вызов на абонента УПАТС #1

В центральный домен приходит вызов из "входящего SIP-транка (вызов с города)", попадает в контекст маршрутизации по умолчанию во внутреннем плане нумерации, где происходит модификация номеров А, Б, а также их свойства к внутреннему плану нумерации. Далее, на основе модифицированной информации осуществляется маршрутизация вызова, в процессе которой определяется, что вызов идет на абонента УПАТС #1. Маршрутизация переходит в "контекст для модификации номеров и их свойств по выходу на УПАТС #1", после чего вызов отправляется в бридж до УПАТС #1.

В УПАТС #1 вызов направляется через "Входящий bridge-интерфейс с центрального домена", поступает в контекст маршрутизации в городском плане нумерации, установленный по умолчанию, где происходит модификации номеров А, Б, а также их свойств в "Городскому плану нумерации". Далее, выполняется непосредственная маршрутизация вызова, в результате которой определяется, что абонент Б - локальный абонент данной УПАТС. Поэтому выполняется переход в контекст маршрутизации, предназначенный для модификации номеров при выходе на локальных абонентов, если необходимо. В данном контексте выполняется "модификация по выходу", после чего вызов отправляется на локального абонента. При выходе на локального абонента система по номеру абонента Б в городском плане нумерации выполняет поиск абонента УПАТС #1, у которого в городском плане нумерации выставлен номер Б, который получили в результате маршрутизации. Если таких абонентов больше чем один, то выбирается абонент, на который был данный номер установлен первым. И вызов направляется на данного абонента. Если такой абонент не найден, вызов отбивается.

Реестр российского плана нумерации

РосСвязь на своем сайте предоставляет реестр российских номеров с привязкой к регионам, оператора, за которыми закреплены данные номера. Данная база периодически обновляется, при перераспределении номеров. В рамках релиза 3.14 была сделана возможность на уровне маршрутизации / модификации номеров вызова воспользоваться данной базой. Имеется возможность изменять отображаемое имя абонента А, Б на основе информации из данной базы. Маршрутизировать вызовы на основе оператора/региона / города абонента А, Б.

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

Настройка кеша российского плана нумерации

Для обновления кеша российского плана нумерации был создан systemd-сервис ecss-rf-numbering-plan.service. При запуске сервис скачивает из internet российский план нумерации, разбирает его и записывает во внутреннюю базу номеров. Кодировка текста — UTF-8. После чего сервис останавливается, и сам не запускается. Для того, чтобы сервис автоматически обновлял кеш, есть таймер ecss-rf-numbering-plan.timer. По умолчанию он выключен, но его можно настроить обновлять кеш (например раз в неделю/месяц).

Конфигурация сервиса ecss-rf-numbering-plan.service

Конфигурация сервиса ecss-rf-numbering-plan.service располагается по пути /etc/ecss/ecss-rf-numbering-plan.conf

# Каталог, содержащий планы нумерации
# Path to directory, that contains files with numbering scheme
#PATH_SCHEMES=

# URL-адрес для автоматической загрузки планов нумерации
# URL for downloading numbering schemes
URL_NUMBERING_SCHEME="https://rossvyaz.ru/data"

# Список планов нумерации, требуется только при загрузке
# Names of numbering schemes, used for downloading
#NAMES_NUMBERING_SCHEME=
NAMES_NUMBERING_SCHEME=ABC-3xx.csv,ABC-4xx.csv,ABC-8xx.csv,DEF-9xx.csv

# Путь для записи базы данных
# Path to write database
SQL_DB=/var/lib/ecss/routing/rf-numbering-plan.db

# Путь для записи логов, если не задан логи пишутся только в stdout
# Path to write logs, if not set, then logs write only in stdout.
LOGS=/var/log/ecss/rf-numbering-plan.log

CODE

Если при выполнении должны использоваться уже загруженные планы нумерации, то в PATH_SCHEMES требуется задать путь до каталога с ними. В этом каталоге должны находиться только файлы с планами нумерации!
URL_NUMBERING_SCHEME URL адреса, для загрузки планов.
NAMES_NUMBERING_SCHEME — список название планов нумерации. Названия должны быть перечислены через запятую без пробелов.
Загрузка осуществляется, используя комбинацию URL адреса и названий (пример: https://rossvyaz.ru/data/{ABC-3xx.csv,ABC-4xx.csv,ABC-8xx.csv,DEF-9xx.csv})
LOGS — путь до файла для записи логов. Логи записываются только при работе через systemd-сервис, либо при запуске от root. При повторном запуске логи перетираются. Также все логи пишутся в stdout.

Запуск сервиса по таймеру

Для запуска через таймер также необходимо отредактировать ecss-rf-numbering-plan.timer (/lib/systemd/system/ecss-rf-numbering-plan.timer). В нём необходимо настроить время и период запуска сервиса. По умолчанию для таймера установлено следующее значение: первого числа каждого месяца в 00:00.

Единовременный запуск сервиса из консоли

ecss-rf-numbering-plan [<SQL_DB>] [--scheme <PATH_SCHEMES>]

CODE

Если SQL_DB не указан в конфигурационном файле, то его необходимо передать при запуске.

Особенности при парсинге номеров

При обработке используются следующие правила:

удаляются все лишние пробелы;
вокруг символов ; - | удаляются все пробелы;
все приводится в верхний регистр;
буква "ё" заменяется на "е";
город, г. о. (городской округ), г.п. (городское поселение) -> г.;
область -> обл.;
район/улус -> р-н;
автономный округ, автономная область -> АО;
республика и р-н стоят до названия;
край, обл. и АО - после названия;
полные версии форм организация: ОАО, ООО, ПАО, АО, ЗАО, ФГУП, ФКП, МБУ — приводятся к сокращенному виду.

Также есть список, по которому обрабатываются какие-либо нестандартные значения:

нас.пункт без региона;
несколько регионов/нас.пунктов;
федеральные округа, РФ;
другое гос-во (Байконур/Казахстан );
различные ошибки/опечатки (находил как в названиях нас.пунктов/районов, так и у операторов) и др.

Если после обработки будут обнаружены невалидные значения:

населенный пункт без указания региона;
несколько населенных пунктов или регионов;

То появятся соответствующие сообщения.

Процесс маршрутизации телефонного вызова