ECSS-10 поддерживает подключение встречных АТС по протоколу IPNET, который представляет собой инкапсуляцию QSIG в IP для работы по сетям передачи данных.

Подключение встречной АТС по одному транку

Для организации подключения потребуется проделать следующие шаги:

1 Создать транспортный пир;

2 Создать точку терминации IPNET;

3 Создать транк IPNET;

4 Настроить маршрутизацию вызовов.

В результате должна получиться такая схема:

Создание транспортного пира

Транспортный протокол (peer), на котором будет работать протокол IPNET, создаётся командой /network/peer/declare. Протокол IPNET работает через сетевой протокол IPv4, транспортный протокол UDP и по умолчанию использует порт 2427. Со стороны ECSS-10 peer должен поднимать слушающий (listen) интерфейс. Нода, на которой будет запущен транспорт, выбирается исходя из архитектуры построения кластера ECSS-10.

В приведённом примере транспортный пир привязывается к ноде core.

$ /network/peer/declare docPeerIPNET udp server core1@ecss10 192.0.2.1 2427
Peer docPeerIPNET successfully created.
CODE

Создание точки терминации IPNET

Точка терминации IPNET связывает между собой транспортный пир ECSS-10 и транк (канал со встречной АТС) IPNET. Точка терминации создаётся командой /sigtran/ipnet/endpoint/declare .

$ /sigtran/ipnet/endpoint/declare docEndpointIPNET docPeerIPNET Peer for documetation
IPNET peer docEndpointIPNET successfully created
CODE

Создание транка IPNET

Транк IPNET описывает параметры соединения со встречной АТС — её IP-адрес и UDP-порт. Транк создаётся и привязывается к определённой виртуальной АТС и определённой группе транков в ней. Транк создаётся командой /sigtran/ipnet/trunk/declare .

$ /sigtran/ipnet/trunk/declare doc.domain.name ipnet.trunks docTrunkIPNET default_routing docEndpointIPNET 192.0.2.20 2427
Trunk docTrunkIPNET successfully created at domain doc.domain.name
CODE

Настройка маршрутизации вызовов

Маршрутизация вызовов через транк IPNET производится аналогично любым другим транкам и описывается в разделе Виртуальная АТС. Маршрутизация телефонных вызовов.

Дополнительные параметры транков IPNET

Как любой другой транк, транк IPNET может принимать настройки пропускной способности, ограничения числа вызовов в единицу времени, а также чёрные и белые списки. Описание настроек приводится в разделе /domain/<DOMAIN>/trunk.

Подключение встречной АТС в режиме отказоустойчивого кластера

Поскольку протокол IPNET не подразумевает собой работу по нескольким IP-адресам, для обеспечения работы протокола IPNET на кластере ECSS-10 потребуется создать виртуальный IP-адрес, который будет активироваться на доступной ноде. Схема работы в этом случае будет выглядеть так:

Транк IPNET настраивается идентично тому, как организуется подключение по одному транку, за исключением того, что транспортный пир назначается на виртуальный IP-адрес. Со стороны встречной АТС в качестве адреса ECSS-10 также указывается её виртуальный IP-адрес.

Для настройки понадобится проделать следующие шаги:

Настройка порта-индикатора готовности IPNET адаптера

Когда адаптер IPNET готов к работе и может принимать и отправлять сигнальные запросы, система сигнализирует об этом, открывая специальный TCP порт-индикатор. Номер порта настраивается в файле /etc/ecss/ecss-core/core[N].config и по умолчанию принимает значение 65531.

{pa_ipnet, [
        {keepalive, {"127.0.0.1", 65531}}
]}
CODE

Обычно менять этот порт не требуется и этот шаг в настройке можно пропустить.


Настройка демона keepalived

Настройка производится через файлы конфигурации /etc/keepalive.d/ecss-core.conf (здесь настраиваются виртуальный IP и проверка работоспособности адаптера IPNET) и /etc/keepalived/keepalived.conf (здесь настраиваются общие параметры протокола VRRP).

Для обеспечения оперативного переключения между рабочими нодами следует использовать протокол VRRP версии 3, т.к. он позволяет осуществлять рассылку сообщений VRRP advertisements с интервалом в 1/100 секунды (сантисекунды) в отличие от протокола VRRP версии 2, который оперируем секундными интервалами. С точки зрения протокола IPNET это важно, т.к. протокол IPNET реализует свои собственные keepalive сообщения. При использовании протокола VRRP версии 2 худшее время переключения виртуального IP-адреса составит четыре секунды при минимальном времени рассылки VRRP advertisements в одну секунду, что может быть недопустимо долго с точки зрения механизма IPNET keepalive и приведёт к разрушению вызова со стороны встречной станции.

Для примера возьмём следующую планируемую схему подключения:

Настройка файла /etc/keepalived/keepalived.conf на нодах (версия keepalived 1.3.9)

Здесь включается протокол VRRP версии 3, а также производятся настройки запуска тестовых скриптов. В целях безопасности для запуска скриптов используется пользователь nobody и выставлен флаг защиты от запуска скриптов, требующих рутовых прав.

Первая нодаВторая нода


global_defs {
    vrrp_version 3
    script_user nobody
    enable_script_security
}

include /etc/keepalived.d/*.conf
CODE 


global_defs {
    vrrp_version 3
    script_user nobody
    enable_script_security
}

include /etc/keepalived.d/*.conf
CODE

Настройка файла /etc/keepalive.d/ecss-core.conf на нодах (версия keepalived 1.3.9)

Здесь настраиваются параметры проверки готовности адаптера IPNET через специальный скрипт /usr/bin/ecss_ipnet_port, который идёт в комплекте поставки ECSS-10.

Виртуальный роутер с идентификатором 66 имеет IP-адрес 192.0.2.10 (это тот самый адрес, на котором будет работать протокол IPNET со стороны ECSS-10), обмен VRRP advertisements между нодами идёт через unicast-адреса каждые 50мс. Интервал VRRP advertisements следует выбирать исходя из величины сетевой задержки между нодами. Выбранный интервал в 50мс позволяет оперативно переключаться при сбое нод и при этом позволяет пережить без ложного срабатывания возрастание сетевой задержки до 150-200мс. В случае, если ноды сильно разнесены географически, может потребоваться немного увеличить этот интервал, исходя из реальных характеристик сети. Однако делать слишком большим этот интервал не следует, т.к. это может повлиять на стабильность сохранения активных вызовов при переключении (см. выше описание защитного keepalive протокола IPNET). Худшее время переключения при отказе мастера или потере пакетов VRRP advertisements в случае проблем на сети составит advert_int x 4.

Первая нода стартует как VRRP Master и имеет более высокий приоритет 101. Интерфейс, на котором будет поднят виртуальный IP-адрес, имеет имя enp2s0.

Вторая нода стартует как VRRP Backup и имеет более низкий приоритет 100. Интерфейс, на котором будет поднят виртуальный IP-адрес, имеет имя eno1.

Первая нодаВторая нода


vrrp_script check_core_ipnet {
    script "/usr/bin/ecss_ipnet_port 65531"
    interval 1
    fall 1
    rise 1
}

vrrp_instance VI_CORE_IPNET {
    state MASTER
    interface enp2s0
    virtual_router_id 66
    priority 101
    advert_int 0.05
    smtp_alert
    preempt_delay 60
    unicast_src_ip 192.0.2.1
    unicast_peer {
         192.0.2.2
    }
    virtual_ipaddress {
        192.0.2.10/32 dev enp2s0 label enp2s0:IPNET
    }
    track_script {
        check_core_ipnet
    }
}
CODE 


vrrp_script check_core_ipnet {
    script "/usr/bin/ecss_ipnet_port 65531"
    interval 1
    fall 1
    rise 1
}

vrrp_instance VI_CORE_IPNET {
    state BACKUP
    interface eno1
    virtual_router_id 66 
    priority 100
    advert_int 0.05
    smtp_alert
    preempt_delay 60
    unicast_src_ip 192.0.2.2
    unicast_peer {
         192.0.2.1
    }
    virtual_ipaddress {
        192.0.2.10/32 dev eno1 label eno1:IPNET
    }
    track_script {
        check_core_ipnet
    }
}
CODE

Настройка транка IPNET

Настройка транка IPNET производится так же, как и в случае подключения встречной АТС по одному транку. Единственным отличием будет процесс добавления транспортного пира — потребуется указать две ноды с виртуальным IP-адресом:

$ /network/peer/declare docPeerIPNET udp server core1@ecss10 192.0.2.10 2427 core2@ecss10 192.0.2.10 2427
Peer docPeerIPNET successfully created.
CODE

Затем процесс настройки транка продолжается с пункта "Создание точки терминации IPNET".