📁Руководство системного Администратора

1. Руководство системного администратора КОСКО УПАТС

Сокращенное наименование: АБР 2024 РСА УПАТС

Децимальный номер:

Пермь 2024

Состав документа

Обозначение	Наименование
АБР 2024 РСА УПАТС	Руководство системного администратора УПАТС

Перечень приложений

Обозначение	Наименование
АБР 2024 РСА УПАТС Пр. А СКФ	Приложение А. Структура конфигурационного файла системы УПАТС
АБР 2024 РСА УПАТС Пр. Б АOSМД	Приложение Б. Администрирование КОСКО УПАТС.Мастер-домен
АБР 2024 РСА УПАТС Пр. В АOS	Приложение В. Администрирование КОСКО УПАТС. Продукт Router
АБР 2024 РСА УПАТС Пр. Г МКДOS	Приложение Г. Мониторинг домена КОСКО УПАТС
АБР 2024 РСА УПАТС Пр. Д ММДOS	Приложение Д. Мониторинг Мастер-домена КОСКО УПАТС

Лист изменений

История изменений документа:

Редакция документа	Дата изменения	Автор	Содержание изменения
1.0	27.11.2024	ООО «Академия Бизнес Решений»	Первоначальная версия

Введение

Руководство подготовлено на основе технической документации производителя программного продукта КОСКО УПАТС - ООО «Академия Бизнес Решений». Документ определяет порядок действий системного администратора при выполнении типовых операций администрирования в процессе эксплуатации системы.

Термины и сокращения

Использованные во всех частях документа термины и сокращения трактуются следующим образом:

АТС (Автоматическая телефонная станция)	Система устройств, обеспечивающая автоматическое соединение и поддержание телефонной связи между абонентами АТС, пользующимися специальными конечными устройствами — телефонными аппаратами, факсами и др.
Виртуальный сервер (виртуальная машина, ВМ)	Программное обеспечение, эмулирующее работу отдельного физического сервера с установленной на него операционной системой и прикладным программным обеспечением. На физическом сервере может выполняться множество виртуальных серверов, за счет чего достигается оптимизация использования аппаратных ресурсов физического сервера.
Виртуальный IP (VIP)	IP-адрес, который можно назначить сразу нескольким машинам или сделать вторым адресом для сетевого интерфейса. VIP не привязан к какому-то конкретному физическому интерфейсу, он может быть использован для того, чтобы обеспечить доступ к сервису, который работает на нескольких серверах (например, в кластере). В случае отказа одного сервера, VIP может быть перенесен на другой сервер, обеспечивая непрерывность работы сервиса.
ВКС (видеоконференцсвязь)	Онлайн-технология, которая позволяет двум и более пользователям в разных местах проводить личные встречи без необходимости собираться в одном месте.
Высокая доступность (High Availability, HA)	Свойство системы выполнять требуемую функцию при заданных условиях в данный момент времени или в течение заданного интервала времени.
Дескриптор (от лат. describо – описываю)	Абстракция в приложении для взаимодействия с ресурсами, которыми также управляет база данных или операционная система.
Домен	В контексте КОСКО УПАТС - сущность, определяющая границы группы объектов системы, предоставляющих доступ к функционалу системы. Логика работы системы использует домены и принадлежащие им объекты при реализации функционала и определении доступа для отдельных пользователей.
ИС	Информационная система.
КАФ	Коды абонентских функций (featurecode).
Кластер	Несколько серверов, объединенных специальным программным обеспечением, для реализации отказоустойчивости и/или балансировки нагрузки.
Катастрофоустойчивость (Disaster Recovery, DR)	Способность ИС к восстановлению после катастрофы, то есть устойчивость к воздействию природных катаклизмов, техногенных факторов.
Коммуникационный домен (КД)	Дочерний домен, обеспечивающий работу основных функциональных ролей системы УПАТС.
Маршрутизация	Процесс определения маршрута обработки звонка на основании некоторых условий. Алгоритм сценария определяет маршрут прохождения вызова в зависимости от текущего значения переменных.
Мастер-сервер (master-сервер)	Первый в иерархии серверов УПАТС. Осуществляет обслуживание мастер-домена, управление системой и резервной копией конфигурации
Менеджер управления	Операционная система, с установленной СУВ, управляющая физическими хостами виртуализации, доменами данных, кластерами, виртуальными машинами и предоставляющая администратору интерфейс управления. Менеджер управления устанавливается в режиме Standalone (как сервис на физический сервер) или HostedEngine (как сервис внутри виртуальной машины).
Нода	Элемент кластера, узел, отвечающий за сбор, обработку и передачу информации. В контексте КОСКО УПАТС, нода - процесс операционной системы. В нем работает экземпляр среды исполнения Erlang, которому дано уникальное имя. На одном физическом или виртуальном сервере (адресе) могут быть активны несколько нод.
ОС (Операционная система)	Это комплекс программ, предназначенных для управления ресурсами компьютера и организации взаимодействия с пользователем.
Отказоустойчивость (Fault-Tolerance, FT)	Свойство системы сохранять работоспособность после отказа одного или нескольких компонентов.
Платформа	В данном документе – комплекс ПО КОСКО УПАТС.
Поток Е1	Это общепринятое название цифрового потока передачи данных, генерируемого в соответствии с европейским стандартом PDH. В поток E1 входит 30 каналов для передачи голоса, по 64Кбит/с каждый, и 2 канала для передачи служебной информации (сигнализации), один для передачи данных об устанавливаемых соединениях, другой – для синхронизации оборудования на конечных точках потока.
Ролевое приложение (roleapp)	Дескриптор веб-приложения, которое устанавливается администратором в домен системы и доступно для пользователей домена через веб-интерфейс.
Сайт	В контексте КОСКО УПАТС - группа серверов высокой доступности друг для друга, предоставляющая полный функционал системы. Каждый сайт является независимым и может производить обмен информацией с другими сайтами. На каждом сайте должен обслуживаться хотя бы один домен.
Сервер (физический сервер)	Специализированный компьютер, предназначенный для обеспечения непрерывной работы сетевых сервисов.
Система управления виртуализацией (СУВ)	Это программное обеспечение, которое взаимодействует с виртуальными средами и физическим оборудованием для упрощения управления ресурсами, повышения эффективности анализа данных и оптимизации операций.
ТфОП	Телефонная сеть общего пользования.
УПАТС	Учрежденческо-производственная автоматическая телефонная станция, организованная на базе программного комплекса IP-телефонии.
Хост виртуализации	Физический сервер, использующий технологию виртуализации. Предоставляет вычислительные ресурсы для запуска виртуальным машин.
AD (Active Directory)	Службы каталогов корпорации Microsoft для операционных систем семейства Windows Server.
API (Application Programming Interface)	Программный интерфейс приложения, описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой.
BLF (Busy Lamp Field)	Функция SIP-телефонов, которая позволяет отслеживать текущее состояние линий других абонентов. Различаются три состояния линии: свободна (Idle), идет вызов (Ringing), занята (Connected/Busy). Если линия не зарегистрирована, ее состояние будет показано как «свободна».
CalledID	Набранный номер, для идентификации абонента в системе КОСКО при входящем/исходящем звонках.
CallerID	Номер звонящего, для идентификации абонента в системе КОСКО при входящем/исходящем звонках.
CRUD	Аббревиатура, обозначающая четыре основных операции управления данными: create, read, update, delete/destroy, то есть создание, чтение, обновление и удаление.
DHCP (Dynamic Host Configuration Protocol)	Сетевой протокол, позволяющий сетевым устройствам автоматически получать IP-адрес и другие параметры, необходимые для работы в сети TCP/IP. Данный протокол работает по модели «клиент-сервер». Для автоматической конфигурации компьютер-клиент на этапе конфигурации сетевого устройства обращается к так называемому серверу DHCP и получает от него нужные параметры. Сетевой администратор может задать диапазон адресов, распределяемых сервером среди компьютеров. Это позволяет избежать ручной настройки компьютеров сети и уменьшает количество ошибок.
Docker	Программное обеспечение для автоматизации развёртывания и управления приложениями в средах с поддержкой контейнеризации, контейнеризатор приложений. Позволяет «упаковать» приложение со всем своим окружением и зависимостями в контейнер, который может быть развёрнут на любой Linux-системе с поддержкой контрольных групп в ядре, а также предоставляет набор команд для управления этими контейнерами.
Docker-контейнер	Это виртуальные блоки, служащие для запуска приложений, который представляет собой пакет ПО, содержащий код, системные инструменты, библиотеки, зависимости и файлы конфигурации, необходимые для запуска определённого приложения.
Docker-том	Это файловая система, которая расположена на хост-машине за пределами контейнеров. Тома представляют собой средства для постоянного хранения информации и могут совместно использоваться разными контейнерами. Созданием и управлением томами занимается Docker.
ETCD (etcd)	Программное хранилище "ключ-значение" (key-value) с быстрым доступом, которое используется для хранения всей информации о кластере, например, PostgreSQL. Название etcd не является аббревиатурой и никак не расшифровывается, «etcd» происходит от соглашения об именовании в структуре каталогов Linux: в UNIX все файлы конфигурации системы для одной системы содержатся в папке «/etc»; «d» означает «распределённый».
Erlang	Функциональный язык программирования с сильной динамической типизацией, предназначенный для создания распределённых вычислительных систем. Применяется для создания высоконагруженных телекоммуникационных систем, в том числе – КОСКО УПАТС.
Framework	Набор правил, шаблонов и инструментов, которые используются для построения продуктов или процессов.
HAproxy	Служба, предоставляющая единую точку, к которой подключатся приложения, работающие с базой данных. Контроль за узлами входа в кластер баз данных осуществляет HAproxy на основе информации от Patroni.
Hosted Engine	Утилита/служба, предназначена для управления виртуальной машиной HostedEngine. Т.е. Менеджер управления работает внутри ВМ, запущенной на хостах, управляемых этой службой управления. Основное преимущество Hosted Engine состоит в том, что отсутствует необходимость в отдельном хосте с ролью менеджера управления.
INVITE	Одно из сигнальных сообщений протокола SIP – запрос, который приглашает пользователя принять участие в сеансе связи (служит для установления нового соединения; может содержать параметры для согласования).
IP	Интернет-протокол, набор правил, регулирующих формат данных, отправляемых через интернет или локальную сеть.
IP-АТС	Автоматическая телефонная станция на основе протокола IP.
IP-телефон	Устройство или программа, использующие технологию голосовой связи по интернет-протоколу (VoIP).
IP-телефония	Телефонная связь по протоколу IP.
IVR (Interactive Voice Response)	Система интерактивного голосового меню из предварительно записанных голосовых сообщений, выполняющая функцию маршрутизации звонков внутри колл-центра или УПАТС с использованием информации, вводимой клиентом на клавиатуре телефона с помощью тонального набора.
Keepalived	Программный инструмент для обеспечения высокой доступности и отказоустойчивости сетевых сервисов. Работает на основе протокола VRRP (Virtual Router Redundancy Protocol), который позволяет нескольким серверам обмениваться информацией о состоянии друг друга. В случае отказа одного из серверов, другой сервер может автоматически взять на себя его функции, чтобы пользователи не заметили прерывания в работе сервиса. Keepalived позволяет автоматически переключать виртуальный IP-адрес (VIP) с основного сервера на резервный в случае сбоя, обеспечивая непрерывность работы сервиса. Отказоустойчивость достигается за счёт «плавающего» IP-адреса, который переключается на резервный сервер в случае отказа основного.
Long-hunting (в телефонии)	Метод распределения телефонных звонков от одного номера на группу из нескольких телефонных линий.
MWI (Message Waiting Indicator, индикатор ожидающего сообщения)	Индикация о наличии голосовых сообщений в почтовом ящике.
Meet-Me Conference	Функция, которая позволяет подключить несколько телефонов в одну виртуальную комнату для проведения конференции.
NAT (от англ. Network Address Translation — «преобразование сетевых адресов»)	Механизм в сетях TCP/IP, позволяющий преобразовывать IP-адреса транзитных пакетов.
ODBC (Open Database Connectivity)	Программный интерфейс (API) доступа к базам данных. Цель ODBC — предоставить унифицированные средства взаимодействия прикладной программы (клиента) с сервером — базой данных.
Patroni	Framework, разработанный на языке python, для построения кластера БД Postgres высокой доступности на основе потоковой репликации.
RCO (Recovery Capacity Objective)	Часть нагрузки (с точки зрения производительности), которую должна обеспечивать резервная система.
RPO (Recovery Point Objective)	Количество данных, которое допустимо потерять при аварийном восстановлении.
RTO (Recovery Time Objective)	Время, за которое возможно восстановить ИТ-систему, после катастрофы или отказа.
RTP (Real-time Transport Protocol)	Протокол передачи потоковых медиа данных в реальном времени.
SIP (Session Initiary protocol)	Протокол передачи данных, описывающий способ установления и завершения пользовательского сеанса связи, включающего обмен мультимедийным содержимым.
STUN (сокр. от англ. Session Traversal Utilities for NAT, утилиты обхода сеансов для NAT)	Сетевой протокол, который позволяет клиенту, находящемуся за сервером трансляции адресов (или за несколькими такими серверами), определить свой внешний IP-адрес, способ трансляции адреса и порта во внешней сети, связанный с определённым внутренним номером порта. Эта информация используется для установления соединения UDP между двумя хостами в случае, если они оба находятся за маршрутизатором NAT.
VoIP (Voice over IP)	Технология для организации передачи голоса через IP, в том числе не имеющее отношение к телефонии.
Worker-сервер	Общий термин для рабочих серверов (ВМ) УПАТС, за исключением мастер-сервера.

Подготовка к установке КОСКО УПАТС

Установка УПАТС ПО КОСКО УПАТС, требует наличия среды виртуализации, развертывания виртуальных серверов для установки ролевых серверов и создания конфигурационного файла системы.

Конфигурационный файл системы «по умолчанию» создается во время инсталляции, но производителем рекомендуется создать его на этапе проектирования системы, с последующим импортированием его на сервер master-домена. Такой вариант конфигурирования системы существенно сокращает количество необходимых операций при настройке системы УПАТС.

Количество и вычислительные ресурсы для ВМ определяется исходя из требований к количеству абонентов, сайтов и коммуникационных доменов.

Производитель рекомендует, для количества абонентов до 500 и отсутствия требований по отказоустойчивости (то есть в целях тестирования функционала, разработки интеграций с различными ИС и т.п.), развертывать один коммуникационный домен + мастер-домен, минимальные аппаратные требования: CPU 4 ядра по 2.5GHz, RAM 8Gb, HDD минимально 40G.

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

Программное обеспечение КОСКО УПАТС успешно протестировано в среде наиболее распространенных российских ОС Linux: Альт, РЭД ОС, Астра.

Определена следующая архитектура УПАТС (см. таб. 1):

Таблица 1. Архитектура УПАТС.

п/п	Сайт	Описание сайта	Домен	Описание домена	Количество ВМ
1	MASTER	Мастер-коммуникационный сайт.	ats1.abr95.test	Мастер-домен (МастерКД)	1
2	SLAVE	Коммуникационный сайт.	ats2.abr95.test	Рабочий коммуникационный домен 1-го уровня (КД L1)	1

Порядок первоначальной установки

Установка УПАТС выполняется в следующей последовательности:

• Создание конфигурационного файла

• Подготовка ВМ (серверов)

• Подготовка СУБД

• Установка master-сервера

• Активация системы

• Экспорт конфигурации

• Активация конфигурации

• Установка worker-серверов

Создание конфигурации

Конфигурация – это структура, объединяющая слои инфраструктуры, логики и данных КОСКО УПАТС между собой. На основе активной конфигурации строится и работает весь кластер развернутой системы УПАТС.

Изначально конфигурация разворачивается вместе с мастер-сервером и содержится на диске. Она содержит лишь один сервер с базовым набором функциональных ролей.

Несмотря на автоматическое создание первоначального конфигурационного файла УПАТС (при инсталляции первого сервера системы (master-сервера)), для сложных конфигураций (несколько сайтов и доменов), рекомендуется создавать конфигурационный файл заранее, в одном из текстовых редакторов, в формате JSON.

Конфигурационный файл в формате JSON, расположен в рабочей директории активной роли MIC. Имя файла: cfg.

Пример: /usr/lib/cosco/_workdir/mic@0/cfg

В файле конфигурации хранится описание всей физической и функциональной модели КОСКО УПАТС, а именно:

• описание серверов;

• описание КД;

• описание сайтов;

• описание всех экземпляров ролей;

• описание структуры:

• связь сайтов и КД;

• связь сайтов и серверов;

• связь серверов и ролей.

Все содержимое конфигурационного файла является одним большим объектом (списком пар "ключ: значение"), заключенным в фигурные скобки:

{"aliases":

{"paths": \[массив с краткими именованиями файловых путей\],

"pgdb_strings": \[массив с краткими именованиями подключений к базам данных\] } ,

{"sites": \[массив с именами и описаниями сайтов\],

"servers": \[массив с описанием серверов\],

"domains": \[массив с описанием телефонных доменов\],

"roles": \[массив с описанием всех экземпляров ролей во всей системе\],

"structure": \[массив с подробным описанием взаимосвязи сайтов, КД, серверов и ролей\],

"general": \[массив с основными параметрами конфигурации\]}

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

Более подробно о конфигурационном файле см. в разделе 4.9 пояснительной записки к технико-рабочему проекту.

При необходимости изменения структуры УПАТС (ввод дополнительных ВМ, изменение адресации, путей к файлам и БД), предварительно необходимо внести изменения в файл конфигурации.

Файл конфигурации УПАТС приведен в приложении А.

Подготовка серверов

Подготовка серверов:

• установка операционной системы РЭД ОС сервер на ВМ, созданные в среде zVirt (см. раздел 3)

• установка докер-контейнера.

Для установки докер-контейнера выполнить следующие операции:

4.2.1. Обновить список пакетов:

$ sudo apt-get update

4.2.2. Установить служебные пакеты для apt:

$ sudo apt-get install \\

apt-transport-https \\

ca-certificates \\

curl \\

gnupg-agent \\

software-properties-common

4.2.3. Добавить docker’s GPG key:

$ curl -fsSL <https://download.docker.com/linux/debian/gpg> | sudo apt-key add -

4.2.4. Добавить репозиторий docker:

$ sudo add-apt-repository \\

"deb \[arch=amd64\] <https://download.docker.com/linux/debian> \\

$(lsb_release -cs) \\

stable"

4.2.4. Обновить список пакетов:

$ sudo apt-get update

4.2.5. Установить docker engine community:

$ sudo apt-get install docker-ce docker-ce-cli containerd.io

4.2.6. Проверить корректность установки:

$ sudo docker run hello-world

Команда скачает тестовый образ и запустит контейнер. Будет выведено сообщение с тестовой информацией, после чего контейнер остановится. После выполнения команды установка считается завершенной.

Подготовка PostgreSQL

Для высоконагруженных конфигураций КОСКО УПАТС рекомендуется устанавливать кластер серверов БД PostgreSQL.

В настоящем разделе приведен порядок установки кластера серверов БД PostgreSQL для обеспечения работы УПАТС.

4.3.1. Установить ВМ для размещения серверов БД PostgreSQL в среде виртуализации.

4.3.2. Установить кластер ETCD (применяется для сервиса синхронизации и балансировки).

Не рекомендуется устанавливать etcd на тех же машинах, где будет находится patroni и postgresql, так как для etcd очень важна нагрузка на диски.

Для примера, в УПАТС создан кластер ETCD из трех ВМ:

• srv-balancer (10.10.10.9)

• srv-master (10.10.10.17)

4.3.2.1. Выполнить команды:

apt-get update

apt-get install etcd

на каждой ВМ будущего кластера ETCD.

4.3.2.2. Создать пользователя системы (на каждой ноде):

groupadd --system etcd

useradd -s /sbin/nologin --system -g etcd etcd

4.3.2.3. Создать каталог конфигурации и каталог данных (на каждой ноде):

mkdir /opt/etcd

mkdir /etc/etcd

chown -R etcd:etcd /opt/etcd

chmod -R 700 /opt/etcd/

4.3.2.4. Выполнить конфигурацию ETCD на каждой ноде.

Пример:

srv-master (/etc/etcd/etcd.conf):

ETCD_NAME="etcd1"

ETCD_LISTEN_CLIENT_URLS="<http://10.010.010.17:0009,http://100.0.0.1:0009>"

ETCD_ADVERTISE_CLIENT_URLS="<http://10.010.010.17:0009>"

ETCD_LISTEN_PEER_URLS="<http://10.010.010.17:20000>"

ETCD_INITIAL_ADVERTISE_PEER_URLS="<http://10.010.010.17:0000>"

ETCD_INITIAL_CLUSTER_TOKEN="etcd-postgres-cluster"

ETCD_INITIAL_CLUSTER="etcd1=<http://10.010.010.17:0000",etcd2=http://10.010.010.17:0000>"

ETCD_INITIAL_CLUSTER_STATE="new"

ETCD_DATA_DIR="/opt/etcd"

ETCD_ELECTION_TIMEOUT="10000"

ETCD_HEARTBEAT_INTERVAL="2000"

ETCD_INITIAL_ELECTION_TICK_ADVANCE="false"

ETCD_ENABLE_V2="true"

srv-balancer (/etc/etcd/etcd.conf):

ETCD_NAME="etcd2"

ETCD_LISTEN_CLIENT_URLS="<http://10.010.010.9:0009,http://007.0.0.1:0009>"

ETCD_ADVERTISE_CLIENT_URLS="<http://10.010.010.9:0009>"

ETCD_LISTEN_PEER_URLS="<http://10.010.010.9:2000>"

ETCD_INITIAL_ADVERTISE_PEER_URLS="<http://10.010.010.9:2000>"

ETCD_INITIAL_CLUSTER_TOKEN="etcd-postgres-cluster"

ETCD_INITIAL_CLUSTER="etcd1=<http://10.010.002.9:2000",etcd2=http://10.010.002.9:2000>"

ETCD_INITIAL_CLUSTER_STATE="new"

ETCD_DATA_DIR="/opt/etcd"

ETCD_ELECTION_TIMEOUT="10000"

ETCD_HEARTBEAT_INTERVAL="2000"

ETCD_INITIAL_ELECTION_TICK_ADVANCE="false"

ETCD_ENABLE_V2="true"

4.3.2.5. Создать сервис ETCD на каждой ноде.

Пример:

mcedit /etc/systemd/system/etcd.service

\[Unit\]

Description=Etcd Server

Documentation=<https://github.com/etcd-io/etcd>

After=network.target

After=network-online.target

Wants=network-online.target

\[Service\]

User=etcd

Type=notify

#WorkingDirectory=/var/lib/etcd/

WorkingDirectory=/opt/etcd/

EnvironmentFile=-/etc/etcd/etcd.conf

User=etcd

\# set GOMAXPROCS to number of processors

ExecStart=/bin/bash -c "GOMAXPROCS=$(nproc) /usr/local/bin/etcd"

Restart=on-failure

LimitNOFILE=65536

IOSchedulingClass=realtime

IOSchedulingPriority=0

Nice=-20

\[Install\]

WantedBy=multi-user.target

4.3.2.6. Запустить кластер ETCD (на каждой ноде):

systemctl daemon-reload

systemctl enable etcd --now

systemctl start etcd

В файле /etc/etcd/etcd.conf "ETCD_INITIAL_CLUSTER_STATE" следует установить в значение "existing".

4.3.2.7. Проверить статус кластера:

etcdctl member list – вывод перечня нод кластера

etcdctl endpoint status --cluster -w table – какая нода кластера имеет статут лидера

etcdctl endpoint health --cluster -w table – проверка здоровья кластера.

4.3.3. Установка СУДБ Postgresql с Patroni (выполнить на каждой ноде).

4.3.3.1 Установка PostgreSQL и проверка наличие установленных пакетов:

sudo apt install postgresql-15

dpkg -l | grep postgresql

4.3.3.2. Остановка службы PostgreSQ (управлением сервисом PostgreSQL будет заниматься Patroni):

sudo systemctl stop postgresql

sudo systemctl disable postgresql

4.3.3.3. Установка Patroni:

4.3.3.3.1. Установка необходимых пакетов:

sudo apt -y install python3 python3-pip

sudo -H pip install --upgrade testresources

sudo -H pip install --upgrade setuptools

sudo -H pip install psycopg2

sudo -H pip install patroni

sudo -H pip install python-etcd

4.3.3.3.2. Создание файла конфигурации для кластера Patroni /etc/patroni.yml. Конфигурационный файл необходимо создать на всех ВМ с PostgreSQL:

scope: postgres

name: postgresql2

restapi:

listen: 0.0.0.0:0000

connect_address: 10.10.03.007:0000

etcd:

host: revproxy:0000

bootstrap:

dcs:

ttl: 30

loop_wait: 10

retry_timeout: 10

maximum_lag_on_failover: 1048576

postgresql:

use_pg_rewind: true

use_slots: true

parameters:

wal_level: replica

hot_standby: "on"

logging_collector: "on"

max_wal_senders: 5

max_replication_slots: 5

initdb:

\- encoding: UTF8

\- data-checksums

pg_hba:

\- host replication replicator 07.0.0.0/00 trust

\- host replication replicator 10.10.10.100/00 md5

\- host all all 10.10.10.100/00 md5

\- host all all 0.0.0.0/0 md5

users:

admin:

password: 00000000000000000000

options:

\- createrole

\- createdb

postgresql:

listen: 0.0.0.0:0000

connect_address: 10.10.10.007:0000

data_dir: "/data/patroni"

pgpass: /tmp/pgpass

authentication:

replication:

username: replicator

password: 00000000000000000000

superuser:

username: postgres

password: 00000000000000000000

parameters:

unix_socket_directories: '/var/run/postgresql'

tags:

nofailover: false

noloadbalance: false

clonefrom: false

nosync: false

4.3.3.3.3. Проверка конфигурации (на всех ВМ с PostgreSQL):

patroni --validate-config /etc/patroni.yml

4.3.3.3.4. Подготавить директорию для работы PostgreSQL (на всех ВМ с PostgreSQL):

sudo mkdir -p /data/patroni

sudo chown postgres:postgres /data/patroni

sudo chmod 700 /data/patroni

4.3.3.3.5. Создать файл службы для автозапуска Patroni (на всех ВМ с PostgreSQL):

sudo nano /etc/systemd/system/patroni.service

Содержание файла:

\[Unit\]

Description=High availability PostgreSQL Cluster

After=syslog.target network.target

\[Service\]

Type=simple

User=postgres

Group=postgres

ExecStart=/usr/local/bin/patroni /etc/patroni.yml

KillMode=process

TimeoutSec=30

Restart=no

\[Install\]

WantedBy=multi-user.target

4.3.3.3.6. Запустить Patroni, проверить состояние службы (на всех ВМ с PostgreSQL):

sudo systemctl start patroni

sudo systemctl status patroni

4.3.3.4. Установка Haproxy

Пример, на ВМ srv-balancer:

yum -y install haproxy

cp -p /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg-orig

mcedit /etc/haproxy/haproxy.cfg

global

maxconn 100

defaults

log global

mode tcp

retries 2

timeout client 30m

timeout connect 4s

timeout server 30m

timeout check 5s

listen stats

mode http

bind 0:0000

stats enable

stats uri /

listen postgres

bind 0:000

option httpchk

http-check expect status 200

default-server inter 3s fastinter 1s fall 2 rise 2 on-marked-down shutdown-sessions

server postgresql11 srv-postgresql-11:0000 maxconn 100 check port 0000

server postgresql21 srv-postgresql-21:0000 maxconn 100 check port 0000

systelctl enable haproxy –now

4.3.3.5. Установка Keepalived.

Пример, на ВМ srv-balancer:

yum -y install keepalived

cp /etc/keepalived/keepalived.conf /etc/keepalived/keepalived.conf.orig

mcedit /etc/keepalived/keepalived.conf:

global_defs {

router_id ocp_vrrp

enable_script_security

script_user root

}

vrrp_script haproxy_check {

script "/usr/libexec/keepalived/haproxy_check.sh"

interval 5 # check every 5 seconds

weight 2 # add 2 points of prio if OK

}

vrrp_instance VI_1 {

interface enp3s0

virtual_router_id 11

priority 101 # 101 on master, 100 on backup

advert_int 10

state MASTER

virtual_ipaddress {

0.0.0.0

}

track_script {

haproxy_check

}

authentication {

auth_type PASS

auth_pass 0000000

}

}

mkdir -p /usr/libexec/keepalived/

mcedit /usr/libexec/keepalived/haproxy_check.sh:

#!/bin/bash

/bin/kill -0 \`cat /var/run/haproxy.pid\`

chmod 700 /usr/libexec/keepalived/haproxy_check.sh

chmod +x /usr/libexec/keepalived/haproxy_check.sh

systemctl enable keepalived --now

systemctl status keepalived

Установка master-сервера

Установка производиться на ВМ с ОС РЭД ОС сервер. Предварительно должна быть выполнена установка ВМ с БД.

Установка производится с помощью Docker CE.

Установка производится от имени пользователя с правами root.

4.4.1. Создать docker тома для платформы:

$ sudo docker volume create <r_volume_name>

$ sudo docker volume create <r_supv_volume_name>

$ sudo docker volume create <r_var_log_volume_name>

Здесь:

<r_volume_name> – том для рабочей директории платформы;

<r_supv_volume_name> – том для конфигураций supervisord;

<r_var_log_volume_name> – том для логов системы.

Например:

**$ sudo docker volume create Cosco_vol**

**$ sudo docker volume create Cosco_supv_vol**

**$ sudo docker volume create Cosco_var_log_vol**

4.4.2. Загрузить архив образа docker:

**$ sudo docker load -i <image_name.tar.gz>**

Здесь:

<image_name.tar.gz> – имя образа, как правило архив c расширением .tar.gz.

4.4.3. Узнать имя и тэг загруженного образа:

$ sudo docker images –a

REPOSITORY TAG IMAGE ID CREATED SIZE

Cosco 0.3.0 f7df00000006 4 months ago 1.46GB

Здесь:

REPOSITORY – имя образа, как правило соответствует устанавливаемому продукту;

TAG – тэг образа, версия устанавливаемого продукта.

4.4.4. Запустить контейнер:

$ sudo docker run --name <container_name> \\

\--mount ‘type=bind,src=<network_directory>, \\**

dst=<network_directory>,bind-propagation=rshares \\**

\-v <r_volume_name>:/var/lib/cosco \\**

\-v <r_supv_volume_name>:/etc/supervisor/conf.d \\**

**\-v <r_var_log_volume_name>:/var/log/cosco \\**

**\--tmpfs /run:rw,noexec,nosuid,size=4096k**

**\-ditP**

**\--restart unless-stopped**

**\--cap-add=NET_ADMIN**

**\--network host**

**<image_name>:<image_tag>**

Здесь:

<container_name> – имя создаваемого контейнера;

<network_directory> – путь сетевого каталога для хранения общих файлов;

<r_volume_name> – том для рабочей директории платформы;

<r_supv_volume_name> – том для конфигураций supervisor;

<r_var_log_volume_name> – том для логов системы;

<image_name> – имя образа;

<image_tag> – тэг образа.

Например:

**$ sudo docker run --name Cosco \\**

**\--mount ‘type=bind,src=/Cosco_share, \\**

**dst=/Cosco_share,bind-propagation=rshares \\**

**\-v Cosco_vol:/var/lib/cosco \\**

**\-v Cosco_supv_vol:/etc/supervisor/conf.d \\**

**\-v Cosco_var_log_vol:/var/log/cosco \\**

**\--tmpfs /run:rw,noexec,nosuid,size=4096k \\**

**\-ditP \\**

**\--restart unless-stopped \\**

**\--cap-add=NET_ADMIN \\**

**\--network host \\**

**Cosco:2.3.3**

4.4.5. Подключиться к контейнеру выполняя в нем запуск командной оболочки bash:

**docker exec -it <container_name> \\ bash**

Здесь:

<container_name> – имя контейнера.

4.4.6. Инициализировать сервер:

**\# cosco install starttype=firstinit \\**

**srvip=<server_ip> \\**

**srvname=<server_name> \\**

**psk=<psk> \\**

**sqlstr=<db_connstring> \\**

**gendomain=<general_domain>**

Здесь:

firstinit – тип установки системы, константа;

<server_ip> – ip адрес на котором будет поднята ServerShell нода;

<server_name> – имя сервера в конфигурации;

<psk> – private secure key системы;

<db_connstring> – строка подключения к БД PostgreSql;

<general_domain> – главный домен системы.

Например:

**\# cosco install starttype=firstinit \\**

**srvip=0.0.0.0 \\**

**srvname=pbx01 \\**

**psk=123qwe \\**

**sqlstr=host:0.0.0.0,port:0002,login:coscopgadmin,pwd:000000,database:postgres \\**

**gendomain=tester.ru**

Важно! Проверка результата: При выполнении п.4.4.6 - должен содержать сообщение Cosco. Installation success! после выполнения команды.

4.4.7. Отключиться от контейнера:

$ CTRL+d

Активация системы

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

Таблица 1. Параметры лицензии, приобретенной Заказчиком по Договору.

Код лицензии	Название лицензии	Описание	Количество
master	Платформа КОСКО УПАТС	Локально установленный экземпляр системы (по умолчанию - 1)	1
domains	Коммуникационный домен	Количество коммуникационных доменов, имеющих обособленные настройки, учетные записи, абонентскую емкость, внешние линии, голосовые и служебные сценарии	1
devices	SIP устройства	Количество внутренних SIP устройств. Лицензируется количество созданных соединительных линий.	100
siptrunks	SIP-транки	Максимальное количество одновременных разговоров по внешним SIP-линиям	10
sipqueue	Операторы голосовых очередей	Максимальное количество вхождений SIP- устройств в очереди массовых обслуживаний	10
ivrscripts	IVR сценарии	Максимальное количество IVR сценариев (голосовых роботов)	10
svcscripts	Служебные сценарии	Максимальное количество сценариев неголосового обслуживания (получение и анализ данных, отправка во внешние системы, организация дозвонов)	10
webservice_public	Внешний открытый канал	Максимальное количество интеграций с внешними информационными системами	3
webservice_subscr	Канал подписки на события	Максимальное количество сторонних систем, которые могут подписаться на автоматизированное получение событий о звонках из КОСКО УПАТС	1

Для получения файла лицензии, необходимо получить код активации:

Запрос: **GET /rest/v1/master/activationcode HTTP/1.1**

Пример ответа:

**HTTP/1.1 200 OK**

**Content-Type: application/json; charset=utf-8**

**{**

**"code": "000000000000000000000000000000"**

**}**

Файл лицензии создается лицензиаром на основании кода активации, сформированного экземпляром системы.

Файл лицензии передается в шифрованном виде и загружается с помощью API в мастер-домен, либо может быть введен в веб-интерфейсе администрирования Мастер-домена (Управление мастер-доменом -> Общие настройки -> Ввести лицензию)

Загрузка лицензии на сервер осуществляется с помощью запроса, в котором передается JSON-строка с зашифрованным содержимым:

Пример запроса:

**POST /rest/v1/master/license HTTP/1.1**

**Content-Type: application/json; charset=utf-8**

**"…9…000…3FF…9…9…9B2C42"**

Пример ответа:

**HTTP/1.1 200 OK**

**Content-Type: application/json; charset=utf-8**

**{**

**"products": "cosco",**

**"topleveldnpolicy": 1,**

**"dql": {**

**"domains": 2,**

**"sol_pbx": 100,**

**"devices": 100,**

**"siptrunks": 9**

**"ivrscripts": 1,**

**"svcscripts": 1,**

**"webservice_public": 3,**

**"webservice_subscr": 1**

**},**

**"sqf": {**

**"rec": true,**

**"cdr": true,**

**"sel": false**

**}**

**}**

Аутентификация для выполнения запросов API

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

Производит аутентификацию пользователя в домене, создает сессию и устанавливает cookie (RSession) либо возвращает токен (session_token) в ответ на запрос.

В дальнейшем все запросы, содержащие cookie RSession с идентификатором сессии, ассоциируются с этой сессией.

В случае указания session_type, клиент (веб-приложение) получает в ответе токен (session_token), должно его прочитать и запомнить, а затем для работы API-запросов в контексте этой индивидуальной сессии отправлять хедер Authorization: Bearer <session_id>.

Пример запроса:

**POST /rest/v1/iam/sessions HTTP/1.1**

**Content-Type: application/json; charset=utf-8**

**{**

**"domain": "ats1.abr95.test",**

**"login": "00000",**

**"pwd": "00000"**

**}**

Пример ответа:

**HTTP/1.1 204 No Content**

**set-cookie: RSession=0e000011-0008-a000-b00a-e0000e0c0003; Expires=Mon, 19 Apr 2024 12:59:21 GMT; Path=/;**

Импорт конфигурации

Изначально конфигурация разворачивается вместе с мастер-сервером и содержится на диске. Она содержит лишь один сервер с базовым набором функциональных ролей.

Подготовленная в формате JSON конфигурация загружается в систему с помощью API, после чего конфигурация сохраняется в домене, валидируется, и в случае успешной валидации может быть применена.

Пример запроса:

**POST /rest/v1/master/configurations HTTP/1.1**

**Content-Type: application/json; charset=utf-8**

Пример ответа:

**HTTP/1.1 200 OK**

**Content-Type: application/json; charset=utf-8**

**{**

**"id": "e…0-0…0-0…3-c08-e…00…e",**

**"name": "my config",**

**"state": "initial",**

**"content": {**

**"general": {},**

**"aliases": {},**

**"domains": \[\],**

**"sites": \[\],**

**"servers": \[\],**

**"roles": \[\],**

**"structure": \[\]**

**},**

**"opts": {**

**"comment": "",**

**"title": ""**

**},**

**"ext": {**

**"ct": "2000-00-20T00:09:07.03Z"**

**"lwt": "2000-00-20T00:09:07.03Z"**

**}**

**}**

Таблица 2. Описание полей конфигурации.

Спецификация	Описание
Поле: id Режим: inout Тип: uuid По умолчанию: generated	Идентификатор. Может быть задан при создании, иначе генерируется системой.
Поле: name Режим: in Тип: str По умолчанию: empty	Название
Поле: state Режим: inout Тип: str По умолчанию: "initial"	Состояние конфигурации
Поле: content Режим: inout Тип: object По умолчанию: required	Содержание конфигурации: сайты, серверы, домены, функциональные роли, их настройки и связи, общие настройки.
Поле: opts Режим: in Тип: object По умолчанию: empty	Составное поле
Поле: opts.title Режим: in Тип: str По умолчанию: empty	Произвольный заголовок
Поле: opts.comment Режим: in Тип: str По умолчанию: empty	Произвольный комментарий
Поле: ext Режим: inout Тип: object Составное поле	Позволяет расширять состав произвольными ключами и значениями.
Поле: ext.replaced_by_id Режим: out Тип: uuid По умолчанию: generated	Идентификатор конфигурации, которой в момент активации заменена текущая конфигурация, бывшая до этого активной.
Поле: ext.ct Режим: out Тип: date По умолчанию: generated	Время создания объекта в UTC.
Поле: ext.lwt Режим: out Тип: date По умолчанию: generated	Время последней модификации объекта в UTC.
Поле: ext.warnings Режим: out Тип: object По умолчанию: —	Список предупреждений, которые возникли при валидации конфигурации.
Поле: ext.errormsg Режим: out Тип: object По умолчанию: —	Текст об ошибке, которая возникла при валидации конфигурации.
Поле: ext.activate_time Режим: out Тип: date По умолчанию: —	Время активации конфигурации в UTC.
Поле: ext.deactivate_time Режим: out Тип: date По умолчанию: —	Время деактивации конфигурации в UTC.
Поле: ext.version Режим: out Тип: str По умолчанию: —	Версия конфигурации

Для активации созданной (или экспортированной) конфигурации, предварительно требуется провести её валидацию.

Валидация производится функциональной ролью mc с помощью валидатора – сервиса проверки конфигурации.

Валидатор содержит набор проверок и алгоритм прохода по ним. Количество проверок и способ обхода зависит от версии конфигурации.

При создании новой конфигурации либо при изменении валидной(state=valid) или ошибочной(state=error) конфигурации ей выставляется state=initial, таким образом она становится доступной для валидации функциональной ролью mc.

Функциональная роль mc периодически опрашивает доменный центр, получает список конфигураций ожидающих валидации, производит проверку и отправляет результат обратно. Таким образом, валидация происходит всегда автоматически.

Активация конфигурации

Активация новой конфигурации после её валидации осуществляется с помощью запроса на изменение данных конфигурации.

Пример запроса:

PATCH /rest/v1/master/configurations/{configuration_id} HTTP/1.1

Content-Type: application/json; charset=utf-8

{"state":"activating"}

Пример ответа:

**HTTP/1.1 200 OK**

**Content-Type: application/json; charset=utf-8**

**{**

**"id": "eb…d8-01…b-d6…3-c…8-e0d…cd13e",**

**"name": "my config",**

**"state": "** **activating ",**

**"content": {**

**"general": {},**

**"aliases": {},**

**"domains": \[\],**

**"sites": \[\],**

**"servers": \[\],**

**"roles": \[\],**

**"structure": \[\]**

**},**

**"opts": {**

**"comment": "",**

**"title": ""**

**},**

**"ext": {**

**"ct": "2000-00-20T00:09:07.03Z",**

**"lwt": "2000-00-20T00:09:07.03Z"**

**}**

**}**

Установка worker-серверов

Установка производиться на ВМ с ОС РЭД ОС сервер. Предварительно должна быть выполнена установка ВМ с БД.

Установка производится с помощью Docker CE.

Установка производится от имени пользователя с правами root.

4.8.1. Создать docker тома для платформы:

**$ sudo docker volume create <r_volume_name>**

**$ sudo docker volume create <r_supv_volume_name>**

**$ sudo docker volume create <r_var_log_volume_name>**

Здесь:

<r_volume_name> – том для рабочей директории платформы;

<r_supv_volume_name> – том для конфигураций supervisord;

<r_var_log_volume_name> – том для логов системы.

Например:

$ sudo docker volume create Cosco_vol

$ sudo docker volume create Cosco_supv_vol

$ sudo docker volume create Cosco_var_log_vol

4.8.2. Загрузить архив образа docker:

**$ sudo docker load -i <image_name.tar.gz>**

Здесь:

<image_name.tar.gz> – имя образа, как правило архив c расширением .tar.gz.

4.8.3. Узнать имя и тэг загруженного образа:

**$ sudo docker images –a**

REPOSITORY TAG IMAGE ID CREATED SIZE

Cosco 2.0.0 f7df604d5206 4 months ago 1.46GB

Здесь:

REPOSITORY – имя образа, как правило соответствует устанавливаемому продукту;

TAG – тэг образа, версия устанавливаемого продукта.

4.8.4. Запустить контейнер:

**$ sudo docker run --name <container_name> \\**

**\--mount ‘type=bind,src=<network_directory>, \\**

**dst=<network_directory>,bind-propagation=rshares \\**

**\-v <r_volume_name>:/var/lib/cosco \\**

**\-v <r_supv_volume_name>:/etc/supervisor/conf.d \\**

**\-v <r_var_log_volume_name>:/var/log/cosco \\**

**\--tmpfs /run:rw,noexec,nosuid,size=4096k**

**\-ditP**

**\--restart unless-stopped**

**\--cap-add=NET_ADMIN**

**\--network host**

**<image_name>:<image_tag>**

Здесь:

<container_name> – имя создаваемого контейнера;

<network_directory> – путь сетевого каталога для хранения общих файлов;

<r_volume_name> – том для рабочей директории платформы;

<r_supv_volume_name> – том для конфигураций supervisor;

<r_var_log_volume_name> – том для логов системы;

<image_name> – имя образа;

<image_tag> – тэг образа.

Например:

**$ sudo docker run --name Cosco \\**

**\--mount ‘type=bind,src=/Cosco_share, \\**

**dst=/Cosco_share,bind-propagation=rshares \\**

**\-v Cosco_vol:/var/lib/cosco \\**

**\-v Cosco_supv_vol:/etc/supervisor/conf.d \\**

**\-v Cosco_var_log_vol:/var/log/cosco \\**

**\--tmpfs /run:rw,noexec,nosuid,size=4096k \\**

**\-ditP \\**

**\--restart unless-stopped \\**

**\--cap-add=NET_ADMIN \\**

**\--network host \\**

**Cosco:2.0.0**

4.8.5. Подключиться к контейнеру выполняя в нем запуск командной оболочки bash:

**docker exec -it <container_name> \\ bash**

Здесь:

<container_name> – имя контейнера.

4.8.6. Инициализировать сервер:

**\# cosco install starttype=servinit \\**

**srvip=<server_ip> \\**

**srvname=<server_name> \\**

**psk=<psk> \\**

**micnodes=<cfg_parents> \\**

Здесь:

servinit – тип установки системы, константа;

<server_ip> – ip адрес на котором будет поднята ServerShell нода;

<server_name> – имя сервера в конфигурации;

<psk> – private secure key системы;

<cfg_parents> – список конфигурационных нод которые могут обслужить подключение нового сервера.

Например:

**\# cosco install starttype=firstinit \\**

**srvip=0.0.0.0 \\**

**srvname=srv-sip-11 \\**

**psk=00000 \\**

**micnodes=** **[email protected],** **[email protected]**

Важно! Проверка результата: При выполнении п.4.8.6 - должен содержать сообщение Cosco. Installation success! после выполнения команды.

4.8.7. Отключиться от контейнера:

**$ CTRL+d**

Управление обновлением системы

4.9.1. Аутентификация для выполнения запросов API

Выполнить запрос к web-серверу:

**$ curl -c <cookie_file_path> \\**

**\-X POST \\**

**\-H 'Content-Type: application/json' \\**

**\-d '{"domain":"<domain_name>","login":"<login>","pwd":"<pwd>"}' \\**

**<api_prefix>/rest/v1/iam/sessions**

Здесь:

<cookie_file_path> – путь до файла в который будет сохранена сессионная cookie.

<domain_name> – имя домена в котором выполняется аутентификация.

<login> – логин пользователя.

<pwd> – пароль пользователя.

<api_prefix> – префикс URL, в формате http(s)://<host>:<port>. Адрес функциональной роли webserver с включеным API.

Проверка результата подключения:

**$ curl -b <cookie_file_path> \\**

**<api_prefix>/rest/v1/iam/sessions/current**

Здесь:

<cookie_file_path> – путь до файла из которого будет взята сессионная cookie для отправки серверу.

<api_prefix> – префикс URL, в формате http(s)://<host>:<port>. Адрес функциональной роли webserver с включеным API.

Например:

**$ curl -b curl-worker.cookies \\**

**http://****10.10.10.10/rest/v1/iam/sessions/current**

**<response_body>**

Здесь:

<response_body> – данные по текущей сессии.

4.9.2. Вариант получения обновления от внешнего источника.

Загрузить файл обновления:

**$ curl -b <cookie_file_path> \\**

**\-F 'file=@<update_file_path>.zip;filename=<file_name>' \\**

**'<api_prefix>/api/admin/v1/update/upload'**

Здесь:

<file_name> – имя файла обновления с расширением

<update_file_path> – абсолютный путь до файла обновления.

Например:

**curl -b curl-master.cookies \\**

**\-F 'file=@/root/distr/fw_update_1.2.000.zip;filename=fw_update_1.2.000.zip' \\**

**'http:// 10.10.10.10/api/admin/v1/update/upload'**

4.9.3. Вариант обновления с диска (предварительно загружен файл обновления).

Выполнить копирование файла обновления с диска:

**$ curl -b <cookie_file_path> \\**

**'<api_prefix>/api/admin/v1/update/upload?filepath=<update_file_path>'**

Здесь:

<update_file_path> – абсолютный путь до файла обновления.

Например:

**$ curl -b curl-master.cookies \\ '<http://10.10.10.10/api/admin/v1/update/upload?filepath=/home/ceceron/cosco_update/fw_update_1.2.239.zip>'**

4.9.4. Подготовка к обновлению.

Выполнить запрос:

**$ curl -b <cookie_file_path> \\**

**'<api_prefix>/api/admin/v1/update/prepare?filename=<update_filename>'**

Здесь:

Здесь:

<update_filename> – имя файла обновления (0.zip) который будет использован для обновления.

4.9.5. Ожидать состояния state=ready у всех сервисов.

Выполнить запрос получения состояния обновления:

**$ curl -b <cookie_file_path> \\**

**'<api_prefix>/api/admin/v1/update/get_upstate'**

Например:

**$ curl -b curl-master.cookies \\**

**'<http://10.10.10.10/api/admin/v1/update/get_upstate>'**

4.9.6. Применить обновление.

Выполнить запрос:

**$ curl -b <cookie_file_path> \\**

**'<api_prefix>/api/admin/v1/update/apply'**

Например:

**$ curl -b curl-master.cookies \\**

**'<http://10.10.10.10/api/admin/v1/update/apply>'**

Удаление компонентов КОСКО УПАТС

Необходимость удаления компонента комплекса (ВМ какого-либо worker-сервера) в процессе начальной установки может возникнуть по причине ошибочного выбора контейнера, или непланового изменения архитектуры системы.

4.10.1. Узнать имя контейнера:

**$ sudo docker ps -a**

В результате будут отображены все созданные контейнеры, среди них нужно выбрать целевой.

4.10.2. Узнать имена томов используемые контейнером:

**$ sudo docker inspect -f '{{range .Mounts}}{{.Name}}{{printf "\\n"}}{{end}}' <container_name>**

Здесь:

<container_name> – имя контейнера.

Например:

**$ sudo docker inspect -f '{{range .Mounts}}{{.Name}}{{printf "\\n"}}{{end}}' Cosco**

**Cosco_supv_vol**

**Cosco_var_vol**

Здесь:

Cosco_supv_vol – имя тома.

Cosco_var_vol – имя тома.

4.10.3. Узнать имя образа из которого был создан контейнер:

**$ sudo docker inspect --format='{{.Config.Image}}' <container_name>**

Здесь:

<container_name> – имя контейнера.

Например:

**$ sudo docker inspect -f '{{.Config.Image}}' Cosco**

**r/r2:1.9.4**

4.10.4. Остановить контейнер:

**$ sudo docker stop <container_name>**

Здесь:

<container_name> – имя контейнера.

4.10.5. Удалить контейнер:

**$ sudo docker rm <container_name>**

Здесь:

<container_name> – имя контейнера

4.10.6. Удалить тома, используемые контейнером:

**$ sudo docker volume rm <volume_name>**

Здесь:

<volume_name> – имя тома

4.10.7. Удалить образ:

**$ sudo docker rmi <image_name>**

Здесь:

<image_name> – имя образа

4.10.8. Проверить отсутствие контейнера в списке:

**$ sudo docker ps –a**

4.10.9. Проверить отсутствие томов в списке:

**$ sudo docker volume ls**

Конфигурирование в процессе эксплуатации

Необходимость добавления в систему нового сайта, домена, сервера, изменение настроек функциональных ролей может возникнуть в процессе подлкючения к системе нового подразделения (филиала), требующего дополнительных вычислительных ресурсов, модернизации аппаратной платформы, требующей системы и т.п. причин. Изменение конфигурации системы в процессе эксплуатации осуществляется путем выгрузки активной (или архивной) валидной конфигурации, редактирования её в текстовом редакторе, загрузки нового файла конфигурации, его валидации и последующей активации. Данные операции выполняются с помощью REST API КОСКО УПАТС.

Следует учитывать, что конфигурационный файл:

• Управляет структурой и составом аппаратной инфраструктуры (сайты, сервера, сетевые интерфейсы, набором и настройками ролей, связками домен-сайт);

• Всегда только один файл конфигурации является активным;

• ChangeLog изменений конфигурационного файла хранится в БД (роль MDС) и доступно для получения через API запросы.

Структура конфигурационного файла описана в приложении А «Структура конфигурационного файла системы УПАТС».

Подготовительные операции

Все выполняемые операции выполняются на мастер-сервере с учетной записью с правами admin после прохождения аутентификации (п. 4.6).

5.1.1. Получение списка конфигураций

Запрос GET:

**<http://10.10.10.10/rest/v1/master/configurations>**

Пример ответа:

**\[**

**{**

**"ext": {**

**"ct": "2019-07-23T10:09:00.00Z ",**

**"lwt": "2019-07-23T10:09:00.00Z "**

**},**

**"id": "5…9a-0004-0…1-0…4-00…..00",**

**"name": "my config",**

**"opts": {**

**"comment": "simple cfg"**

**},**

**"state": "active"**

**}**

**\]**

Структура ответа - – массив конфигураций:

• id – уникальный идентификатор конфигурации

• name – название

• state – состояние

• initial – инициализация конфигурации (проверка валидности)

• valid – конфигурация проверена и может быть активирована

• active – текущая активная конфигурация (всегда только одна)

• activating – конфигурация в процессе активации

• error – конфигурация содержит ошибку и не может быть активирована

• ext.replaced_by_id – id конфигурации, на которую переехал признак активности.

5.1.2. Получение определенной конфигурации

Запрос GET:

http://10.10.10.10/rest/v1/master/configurations/{id}

Пример:

**GET /rest/v1/master/configurations/5…9a-0004-0…1-0…4-00…..00" HTTP/1.1**

Пример ответа:

**HTTP/1.1 200 OK**

**Content-Type: application/json; charset=utf-8**

**{**

**"id": "5…9a-0004-0…1-0…4-00…..00",**

**"name": "my config",**

**"state": "active",**

**"content": {**

**"general": {},**

**"aliases": {},**

**"domains": \[\],**

**"sites": \[\],**

**"servers": \[\],**

**"roles": \[\],**

**"structure": \[\]**

**},**

**"opts": {**

**"comment": "",**

**"title": ""**

**},**

**"ext": {**

**"ct": "2019-07-23T10:09:57.73Z",**

**"lwt": "2019-07-23T10:09:57.73Z",**

**"version": "3.0",**

**"warnings": "",**

**"errormsg": ""**

**}**

**}**

Полученный ответ копируется в текстовый файл, далее изменение файла конфигурации выполняется в текстовом редакторе, в формате JSON, изменнения вносят в те разделы, которые требуется изменить.

Добавление сайта

Сайт - группа серверов высокой доступности друг для друга, предоставляющая полный функционал системы.

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

Пример (добавление выделено красным):

**{**

**...**

**"sites": \[**

**{**

**"descr": "Main Domain",**

**"domains": \[**

**"td2",**

**"td3",**

**"td4"**

**\],**

**"name": "slave2",**

**"perfmon_tick": 0,**

**"sitetype": "master"**

**},**

**{**

**"ctrl_domains": \[**

**"td3"**

**\],**

**"descr": "Main Domain2",**

**"domains": \[**

**"td_main",**

**"td2",**

**"td3",**

**"td_test",**

**"td5",**

**"td6"**

**\],**

**"name": "central",**

**"perfmon_tick": 0,**

**"sitetype": "communication"**

**}**

**\],**

**...**

**}**

5.2.2. Загрузить новый файл конфигурации в систему:

Пример:

**POST /rest/v1/master/configurations HTTP/1.1**

**Content-Type: application/json; charset=utf-8**

**configuration entity**

где configuration entity – новый текстовый файл конфигурации.

Пример ответа:

**HTTP/1.1 200 OK**

**Content-Type: application/json; charset=utf-8**

**{**

**"id": "00…0-0…b-0003-c0…8-0…0",**

**"name": "my config",**

**"state": "initial",**

**"content": {**

**"general": {},**

**"aliases": {},**

**"domains": \[\],**

**"sites": \[\],**

**"servers": \[\],**

**"roles": \[\],**

**"structure": \[\]**

**},**

**"opts": {**

**"comment": "",**

**"title": ""**

**},**

**"ext": {**

**"ct": "2019-07-23T10:09:57.73Z",**

**"lwt": "2019-07-23T10:09:57.73Z"**

**}**

**}**

5.2.3. Выполнить контроль валидации запросом

**GET /rest/v1/master/configurations/00…0-0…b-0003-c0…8-0…0 HTTP/1.1**

Пример отвтета:

**HTTP/1.1 200 OK**

**Content-Type: application/json; charset=utf-8**

**{**

**"id": "00…0-0…b-0003-c0…8-0…0",**

**"name": "my config",**

**"state": "valid",**

**"content": {**

**"general": {},**

**"aliases": {},**

**"domains": \[\],**

**"sites": \[\],**

**"servers": \[\],**

**"roles": \[\],**

**"structure": \[\]**

**},**

**"opts": {**

**"comment": "",**

**"title": ""**

**},**

**"ext": {**

**"ct": "2019-07-23T10:09:57.73Z",**

**"lwt": "2019-07-23T10:09:57.73Z",**

**"version": "3.0",**

**"warnings": "",**

**"errormsg": ""**

**}**

**}**

Значение "valid" параметра "state" является признаком успешной валидации новой конфигурации.

5.2.4. Выполнить активацию новой конфигурации

Пример запроса:

PATCH /rest/v1/master/configurations/00…0-0…b-0003-c0…8-0…0 HTTP/1.1

Content-Type: application/json; charset=utf-8

{"state":"activating"}

Пример ответа:

**HTTP/1.1 200 OK**

**Content-Type: application/json; charset=utf-8**

**{**

**"id": "00…0-0…b-0003-c0…8-0…0",**

**"name": "my config",**

**"state": "activating",**

**"content": {**

**"general": {},**

**"aliases": {},**

**"domains": \[\],**

**"sites": \[\],**

**"servers": \[\],**

**"roles": \[\],**

**"structure": \[\]**

**},**

**"opts": {**

**"comment": "",**

**"title": ""**

**},**

**"ext": {**

**"ct": "2019-07-23T10:09:57.73Z",**

**"lwt": "2019-09-10T16:06:22.15Z",**

**"version": "3.0",**

**"warnings": "",**

**"errormsg": ""**

**}**

**}**

**"state": "activating" – признак процесса активации.**

Завершение процесса активации контролируется запросом:

**GET /rest/v1/master/configurations/00…0-0…b-0003-c0…8-0…0 HTTP/1.1**

Наличие в ответе значения **"state": "active"** является признаком успешной активации:

**HTTP/1.1 200 OK**

**Content-Type: application/json; charset=utf-8**

**{**

**"id": "00…0-0…b-0003-c0…8-0…0",**

**"name": "my config",**

**"state": "active "**

**….**

**}**

**}**

5.2.5. Создать сервера для нового сайта (см. п. 5.4).

Добавление домена

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

Пример (добавление выделено красным):

{

...

"domains": \[

{

"name": "td_main",

"fqdn": "ceceron.ru"

"descr": "Prod domain"

},

{

"name": "td_test"

"fqdn": "xs0.ceceron.ru",

"descr": "Test domain"

}

\],

...

}

5.3.2. Операция загрузки нового файла конфигурации в систему выполняется аналогично пункту 5.2.2.

5.3.3. Операция валидации нового файла конфигурации в систему выполняется аналогично пункту 5.2.3.

5.3.4. Выполнить активацию новой конфигурации аналигично п.5.2.4.

Добавление сервера

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

Пример (добавление сервера выделено красным):

{

...

"servers": \[

{

"descr": "Central server1. Srv2",

"erlangtcp": 4369,

"ifaces": \[

{

"key": "eth0",

"value": "10.10.10.10"

}

\],

"logiface": "eth0",

"name": "worksrv1",

"recstorepaths": \[

{

"key": "main5",

"value": "alias://paths/h"

},

{

"key": "main4",

"value": "alias://paths/g"

}

\]

},

{

"descr": "admin srv 101 ipshnik. Srv2",

"erlangtcp": 4369,

"ifaces": \[

{

"key": "eth0",

"value": "10.10.10.10"

}

\],

"logiface": "eth0",

"name": "lwm123",

"recstorepaths": \[

{

"key": "main4",

"value": "alias://paths/f"

}

\],

"sitesharepath": "alias://paths/e"

},

{

"descr": "admin srv 000 ipshnik. Srv00000",

"erlangtcp": 0000,

"ifaces": \[

{

"key": "eth0",

"value": "10.10.10.10"

}

\],

"logiface": "eth0",

"name": "lwm101",

"recstorepaths": \[

{

"key": "main4",

"value": "alias://paths/f"

}

\],

"sitesharepath": "alias://paths/e"

}

\],

...

}

5.4.2. Создать функциональные роли для нового сервера (см. п.5.5).

5.4.3. Операция загрузки нового файла конфигурации в систему выполняется аналогично пункту 5.2.2.

5.4.4. Операция валидации нового файла конфигурации в систему выполняется аналогично пункту 5.2.3.

5.4.5. Выполнить активацию новой конфигурации аналигично п.5.2.4.

5.4.6. Выполнить установку нового сервера согласно п.4.8.

Добавление функциональной роли

5.5.1. Добавление функциональных ролей для нового сервера в файл конфигурации выполняется в текстовом редакторе. Один сервер может принадлежать только одному сайту, один экземпляр функциональной роли может принадлежать только одному серверу.

Пример заполнения разделов "roles" и “servers” для новой роли (выделено красным):

{

...

{

"roles": \[

{

"iface": "0000",

"name": "wrpc000",

"roletype": "0000"

},

{}

\]

}

…

"structure": \[

{

"servers": \[

{

"roles": \[

"w2b2bua",

"w2cdr2",

"w2gate",

"w2hunt2",

"w2ic2",

"w2ivr",

"w2mg",

"w2mgc",

"w2rot1",

"w2rot12",

"w2rpci22",

"w2rpco22",

"w2statestore22",

"w2usr1"

\],

"server": "worksrv2"

},

{

"roles": \[

"0000",

"wrpco22",

"wsdc2",

"wstatestore22",

"wstore2",

"wusr1",

"wws1"

\],

...

}

5.5.2. Заполнить параметры в соответствии с типом функциональной роли (см. п.А.7.2 приложения А).

5.5.3. Операция загрузки нового файла конфигурации в систему выполняется аналогично пункту 5.2.2.

5.5.4. Операция валидации нового файла конфигурации в систему выполняется аналогично пункту 5.2.3.

5.5.5. Выполнить активацию новой конфигурации аналигично п.5.2.4.

Добавление резервной функциональной роли

Добавление дополнительных функциональных ролей для нового сервера в файл конфигурации выполняется в текстовом редакторе. Дополнительная функциональная роль работает в режиме active-passive.

5.6.1. Заполнить параметры дополнительных функциональных ролей для нового сервера аналогично п.5.5.1.

5.6.2. Узнать группу и порядок загрузки у резервируемой функциональной роли, из параметров group и order соответственно (см. п.А.7.2 приложения А).

5.6.3. Заполнить параметры в соответствии с типом функциональной роли, указав при этому ту же группу и order в соответствии с желаемым порядком запуска функциональных ролей (см. п.А.7.2 приложения А).

5.6.4. Операция загрузки нового файла конфигурации в систему выполняется аналогично пункту 5.2.2.

5.6.5. Операция валидации нового файла конфигурации в систему выполняется аналогично пункту 5.2.3.

5.6.6. Выполнить активацию новой конфигурации аналигично п.5.2.4.

Распределение функциональной роли на несколько доменов по доменному дереву

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

5.7.1. Внести изменения в функциональную роль, указав обслуживаемые домены, (аналогично п.5.5).

5.7.2. Создать необходимое количество функциональных ролей того же типа, распределив по ним обслуживаемые домены (аналогично п.5.5).

5.7.3. Операция загрузки нового файла конфигурации в систему выполняется аналогично пункту 5.2.2.

5.7.4. Операция валидации нового файла конфигурации в систему выполняется аналогично пункту 5.2.3.

5.7.5. Выполнить активацию новой конфигурации аналигично п.5.2.4.

Изменение сайта

При необходимости внести изменения в конфигурацию сайта, операции выполняются аналогично п.5.2.

Изменение сервера

При необходимости внести изменения в конфигурацию сервера, операции выполняются аналогично п.5.4.

Изменение домена

При необходимости внести изменения в конфигурацию домена, операции выполняются аналогично п.5.3.

Изменение функциональной роли

При необходимости внести изменения в конфигурацию функциональной роли, операции выполняются аналогично п.5.5.

Удаление сайта

Удаление сайта в файле конфигурации выполняется в текстовом редакторе. Предварительно необходимо выполнить удаление или перемещение серверов и функциональных ролей, размещенных в удаляемом сайте (см. п.5.13, п.5.15).

5.12.1. Выполнить удаление соответствующего сайта из раздела «sites» выгруженного конфигурационного файла.

5.12.2. Операция загрузки нового файла конфигурации в систему выполняется аналогично пункту 5.2.2.

5.12.3. Операция валидации нового файла конфигурации в систему выполняется аналогично пункту 5.2.3.

5.12.4. Выполнить активацию новой конфигурации аналигично п.5.2.4.

Удаление сервера

Удаление сервера в файле конфигурации выполняется в текстовом редакторе. Предварительно необходимо выполнить удаление или перемещение и функциональных ролей, размещенных на удаляемом сервера (см. п.5.15).

5.13.1. Выполнить удаление соответствующего сервера из раздела «servers» выгруженного конфигурационного файла.

5.13.2. Операция загрузки нового файла конфигурации в систему выполняется аналогично пункту 5.2.2.

5.13.3. Операция валидации нового файла конфигурации в систему выполняется аналогично пункту 5.2.3.

5.13.4. Выполнить активацию новой конфигурации аналигично п.5.2.4.

Удаление домена

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

5.14.1. Выполнить удаление соответствующего домена из раздела «domains» выгруженного конфигурационного файла.

5.14.2. Операция загрузки нового файла конфигурации в систему выполняется аналогично пункту 5.2.2.

5.14.3. Операция валидации нового файла конфигурации в систему выполняется аналогично пункту 5.2.3.

5.14.4. Выполнить активацию новой конфигурации аналигично п.5.2.4.

Удаление функциональной роли

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

5.15.1. Выполнить удаление требуемой функциональной роли из раздела "roles" требуемого сервера.

5.15.2. Операция загрузки нового файла конфигурации в систему выполняется аналогично пункту 5.2.2.

5.15.3. Операция валидации нового файла конфигурации в систему выполняется аналогично пункту 5.2.3.

5.15.4. Выполнить активацию новой конфигурации аналигично п.5.2.4.

Восстановление предыдущей конфигурации

Активной может быть только одна конфигурация. Восстановить предыдущую конфигурацию – это значит активировать конфигурацию, у которой в поле "replaced_by_id" указан идентификатор текущей активной конфигурации.

5.16.1. Получение списка конфигураций

Запрос GET:

http://10.010.010.07/rest/v1/master/configurations

Ответ:

**\[**

**{**

**"ext": {**

**"ct": "2023-02-07T12:21:52.92Z",**

**"lwt": "2023-02-09T11:23:25.97Z",**

**"replaced_by_id": "000000000000000000000000"**

**},**

**"id": "000000000000000000000000",**

**"name": "autogenerated",**

**"opts": {**

**"comment": "autogenerated by mc"**

**},**

**"state": "valid"**

**},**

**{**

**"ext": {**

**"ct": "2023-02-07T12:25:22.99Z",**

**"lwt": "2023-02-09T11:23:25.64Z"**

**},**

**"id": "000000000000000000000000",**

**"name": "new_cofig_by_SRV",**

**"opts": {**

**"comment": "new_cofig_by_SRV"**

**},**

**"state": "active"**

**},**

**...**

**\]**

Структура ответа - – массив конфигураций:

• id – уникальный идентификатор конфигурации

• name – название

• state – состояние

• initial – инициализация конфигурации (проверка валидности)

• valid – конфигурация проверена и может быть активирована

• active – текущая активная конфигурация (всегда только одна)

• activating – конфигурация в процессе активации

• error – конфигурация содержит ошибку и не может быть активирована

• ext.replaced_by_id – id конфигурации, на которую переехал признак активности.

5.16.2. Выбранную валидную конфигурацию перевести в статус активной:

PATCH /rest/v1/master/configurations/0…58-01…6-2…3-4…9-fca…56f1 HTTP/1.1

Content-Type: application/json; charset=utf-8

{"state":"activating"}

Пример ответа:

**HTTP/1.1 200 OK**

**Content-Type: application/json; charset=utf-8**

**{**

**"id": "000000000000000000000000",**

**"name": "my config",**

**"state": "activating",**

**"content": {**

**"general": {},**

**"aliases": {},**

**"domains": \[\],**

**"sites": \[\],**

**"servers": \[\],**

**"roles": \[\],**

**"structure": \[\]**

**},**

**"opts": {**

**"comment": "",**

**"title": ""**

**},**

**"ext": {**

**"ct": "2019-07-23T10:09:57.73Z",**

**"lwt": "2019-09-10T16:06:22.15Z",**

**"version": "3.0",**

**"warnings": "",**

**"errormsg": ""**

**}**

**}**

**"state": "activating" – признак процесса активации.**

Завершение процесса активации контролируется запросом:

**GET /rest/v1/master/configurations/00…0-0…b-0003-c0…8-0…0 HTTP/1.1**

Наличие в ответе значения "state": "active" является признаком успешной активации:

**HTTP/1.1 200 OK**

**Content-Type: application/json; charset=utf-8**

**{**

**"id": "00…0-0…b-0003-c0…8-0…0",**

**"name": "my config",**

**"state": "active "**

**….**

**}**

**}**

Привязка дерева доменов к сайту

Привязка дерева доменов к сайту выполняется в текстовом редакторе.

5.17.1. Внести изменения в раздел «sites», указав домены в списке обслуживаемых на сайте (см. п. 5.2).

5.17.2. Операция загрузки нового файла конфигурации в систему выполняется аналогично пункту 5.2.2.

5.17.3. Операция валидации нового файла конфигурации в систему выполняется аналогично пункту 5.2.3.

5.17.4. Выполнить активацию новой конфигурации аналигично п.5.2.4.

Администрирование master-домена

Общие сведения

Мастер домен является первичным доменом и корнем слоя данных, из которого разворачиваются остальные (рабочие, коммуникационные) домены. На мастер домен выписывается лицензия, которая потом распределяется на все дочерние коммуникационные домены (КД).

Мастер домен:

• является служебным доменом;

• предназначен для управления доменами L1;

• предназначен для создания дефолтного контекстного сценария;

• позволяет настраивать безопасность SBC ролей SG;

• не обслуживает SIP клиентов;

• всегда работает только на мастер сайте.

Web интерфейс администрирования

После установки КОСКО УПАТС создается пользователь по умолчанию admin с паролем admin. Администрирование мастер-домена осуществляется через Web интерфейс.

Для работы в Web интерфейсе управления КОСКО УПАТС необходимо пройти процедуру

аутентификации. Для этого в адресной строке браузера необходимо ввести IP-адрес или

URL (fqdn) имя Web-сервера для управления.

Рис. 6.1. Страница аутентификации

Для прохождения процедуры аутентификации необходимо заполнить поля:

Таблица 6.1. Поля аутентификации.

Домен	Имя Домена, к которому нужно подключиться. Может быть Мастер доменом или Коммуникационным. После прохождения процедуры аутентификации можно переключаться между всеми КД, доступными пользователю
Логин	Логин пользователя
Пароль	Пароль пользователя

Важно!

Разные Web-серверы настроены на обслуживание различных доменов КОСКО УПАТС. Привязка осуществляется в конфигурационном файле. По умолчанию через Web-сервер можно получить доступ только к тем доменам, которые обслуживаются на текущем Сайте (Сайте, где работает текущий Web-сервер).

В случае 3-х ошибок аутентификации в течении 1 минуты IP адрес источника будет заблокирован на 3 минуты. Если в эти 3 минуты попробовать войти снова, то счетчик времени блокировки сбросится на 3 минуты вне зависимости от корректности введенных значений. Блокировка действует на Web-сервере.

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

Главный экран

Рис. 6.2. Главная страница администрирования

Здесь представлены доступные пользователю приложения - администрирования и

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

Логотип «КОСКО УПАТС» в верхней части страницы является ссылкой, по которой можно перейти в данное окно из любого раздела системы.

В правой верхней части доступна информация о текущем пользователе и активном

домене. При нажатии на кнопку

откроется раскрывающийся список, можно выбрать любой из доступных пользователю доменов (без дополнительной аутентификации).

Домены отбираются по правилам совпадения id, login, password текущего пользователя в доменах системы. Всякий раз, при выборе нового домена, список разделов главной страницы может изменяться, в зависимости от настроенных в новом домене ролей доступа. Если пользователю доступен только один текущий домен, то возможность переключаться между доменами будет заблокирована.

Рис. 6.3. Основной экран WEB приложения Администрирование

В правой верхней части доступна информация о пользователе и активном домене.

Левая часть экранной формы содержит панель навигации, с ее помощью можно перемещаться между разделами/объектами администрирования.

Центральная часть экранной формы содержит таблицу с данными выбранного в левой части раздела.

Внизу слева таблицы располагается кнопка "Фокус на таблице"**

В верхней левой части над таблицей расположено поле для ввода фильтра. Фильтрация позволяет отображать в таблице только те объекты, которые оответствуют критерию фильтра. Фильтр может быть простым (с одним критерием) и сложным (с несколькими критериями, разделенными запятой). При написании фильтра допускается применение масок:

• % - любые символы

• ИЛИ через ; (например, "a;b" означает поиск a или b)

• диапазон чисел 10;50 означает поиск в диапазоне [-inf, 10] ИЛИ [50, +inf]

Примеры применения фильтра можно посмотреть при нажатии на кнопку

справа от поля поиска.

В верхней правой части над таблицей расположены три кнопки «Новый объект», «Экспорт/импорт» и «песочные часы»

Кнопка «Новый объект» позволяет добавить новую запись в текущий раздел.

Кнопка «Экспорт/импорт» дает возможность восстановить данные из ранее сохраненного файла в формате csv (Импорт) или выгрузить данные из таблицы объектов (Экспорт). Здесь же можно посмотреть шаблон для импорта данных (Шаблон).

Историю изменений свойств объектов можно посмотреть по кнопке

Рис. 6.4. История изменений свойств объекта.

Рис. 6.5. Выбор интервала дат для просмотра истории изменения объектов.

В рамках диапазона дат доступны следующие закладки:

• Все - все события в текущем диапазоне

• Добавлено - все новые записи в текущем диапазоне

• Изменено - все записи, которые были изменены в текущем диапазоне

• Удалено - все записи, которые были удалены в текущем диапазоне

• Выбрано - все события по выбранной записи (одной) в текущем диапазоне

Горячие клавиши

При работе с карточкой объекта можно воспользоваться горячими клавишами:

Карточка объекта:

• Ctrl+Enter – Сохранить;

• Ctrl+Shift+Enter - Сохранить как новый;

• Esc - закрытие карточки.

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

Рис. 6.6. Предупрждение о несохраненных данных.

В данном окне действуют следующие горячие клавиши:

• Ctrl+Enter – да;

• Пробел – да;

• Esc - возврат к редактированию карточки.

Во всех приложениях при всплывающих окнах действуют следующие горячие клавиши:

• Ctrl+Enter - нажатие на красную кнопку;

• Esc – отменить.

Разделы администрирования. Пользователи

В этом каталоге настраиваются Пользователи и Администраторы Мастер-домена.

Рис. 6.7. Стартовая страница раздела – общий вид.

Таблица 6.2. Поля, доступные при создании и редактировании записи.

Блок	Название поля	Описание
Основные	Имя	Отображаемое имя пользователя
Логин	Имя пользователя учетной записи для входа в систему
Пароль	Пароль учетной записи
Часовой пояс	Время смещения в формате UTC
Права доступа	Роли доступа	Список ролей доступа. Подробно см. в «Роли и доступные приложения»
Разрешать выполнение операций CRUD сценария	При включении настройки под этим пользователем возможно внесение изменений в настройки домена из компонента сценария Операция. Настройка актуальна для ролей admin и crud.
	Сайты для sitemonitor	Список сайтов мониторинга для роли sitemonitor. Пользователь с этой ролью сможет получать информацию о нагрузке на серверы и роли в рамках указанных сайтов. Названия Сайтов из конфигурационного файла.
	Клонирование пользователя	Копировать пользователя в дочерние домены с текущими правами доступа. Домены появятся в списке доступных доменов на главном экране (справа вверху стрелочка около имени домена). В правилах можно использовать маски: – произвольное количество любых символов $ – произвольное количество любых символов, кроме точки ? – произвольный символ, кроме точки. Домены можно задать по полному.
Комментарий	Комментарии	Возможность указать полезную информацию по учетной записи.

Рис. 6.8. Экранная форма редактирования объекта

Таблица 6.3. Роли и доступные приложения.

Роль	Приложения	Комментарий
admin	Управление мастер-доменом Вебконфигуратор.	Администрирование Мастер-домена, управление файлами конфигурации и разрешение компоненту сценария «Операция» выполнять изменения в настройках домена (требует включения «Разрешать выполнение операций CRUD сценария»).
monitor	Монитор системы	Одновременно с ролью sitemonitor использовать нельзя.
sitemonitor	Монитор сайта	Одновременно с ролью monitor использовать нельзя. Требует заполнение поля «Сайты для sitemonitor».
scripteditor	Редактор сценариев
crud		Специальная роль, позволяющая работать компоненту «Операция» из сценариев (требует включения «Разрешать выполнение операций CRUD сценария»).
lic		Специальная роль, позволяющая делать запрос …/api/admin/v1/lic/<action> в мастер-домене. Action может быть: getcode - получение активационного кода upload - загрузка файла лицензии read, readfile - получение текущей лицензии.
selector	Селекторные совещания	Приложение НЕ доступно в Мастер домене. Если пользователю дать эту Роль и включить «Клонирование», то в других доменах это приложение будет доступно.
stat	Статистика вызовов (CDR)	Приложение НЕ доступно в Мастер домене. Если пользователю дать эту Роль и включить «Клонирование», то в других доменах это приложение будет доступно.

Разделы администрирования. Служебные сценарии

В этом разделе происходит управление существующих служебных сценариев в рамках

данного Домена.

Рис. 6.9. Общий вид раздела.

Таблица 6.4. Поля, доступные при создании и редактировании записи.

Название поля	Описание
Название сценария	Название сценария удобное для восприятия. Возможно использовать русские и английские символы, пробел, цифры.
Код сценария	Буквенно-численный идентификатор сценария в рамках Домена. На него ссылаются записи других объектов. Доступны латинские символы и цифры.
Дата последнего изменения сценария.	Заполняется автоматически при изменении ранее созданного сценария.
Ссылка на сценарий	Открытие сценария на редактирование в новой вкладке браузера.
Уровень логирования	Уровень логирования определяет объем информации, который доступен при получении логов из Мониторинга: Отключено (значение по умолчанию) Только ошибки Ошибки и предупреждения Все события
Комментарии	Возможность указать полезную информацию под записью.

Разделы администрирования. Правила пограничного контроля (SBC)

В данном разделе создаются статические правила для пограничного контроля и

безопасности системы.

При создании правила SBC:

• Правила привязываются к Сайтам;

• На Сайте правило применяется на всех Ролях SG для подключения SIP абонентов;

• На Роли ESG правила только динамические, на роли SG - динамические и статические;

• Срабатывание любого правила является результирующим. Проверка правил происходит последовательно, по приоритету от меньшего к большему.

Рис. 6.11. Общий вид раздела.

Рис. 6.12. Экранная форма создания нового объекта

Таблица 6.5. Поля, доступные при создании и редактировании записи.

Название поля	Описание
Сайт	Название сайта, список через запятую или 0 (все сайты). По умолчанию 0
Действие	Выбор действия, которое будет применяться при срабатывании правила: Разрешить - пакет разрешен правилами пограничного контроля Запретить с кодом 403 - запрос будет отброшен и отправителю будет отправлен ответ SIP с кодом 403 Отбросить без ответа - запрос будет отброшен и инициатор не получит ответ.
Приоритет	Приоритет выбора правила относительно других. Чем меньше число, тем приоритетнее правило.
IP/Mask	IP/Mask фильтрации IP адреса источника запроса (в IP пакете).
Домен	Фильтрация по маске поля Domain в SIP пакете.
Имя пользователя	Фильтрация по маске поля UserName в SIP пакете.
Имя SIP агента (UserAgent)	Фильтрация по маске поля UserAgent в SIP пакете.
Комментарии	Текстовое поле. Возможность указать полезную информацию.

Разделы администрирования. Управление доменами

Дочерние домены L1

В этом каталоге создаются дочерние домены уровня L1. Имя дочерних доменов может быть любым или обязательно содержать имя Мастер-домена. Это определяется в лицензионном ключе параметров topleveldnpolicy (0 - любое имя, 1 - по правилам DNS).

Если любое из следующих условий выполняется, то надо обязательно определять

созданный L1 домен в конфигурационном файле и привязывать его к Сайту:

• Имя L1 не наследуется от имени Мастер-домена;

• Мастер сайт не имеет признак Коммуникационного в конфигурационном файле.

Рис. 6.13. Экранная форма создания нового объекта

Таблица 6.6. Поля, доступные при создании и редактировании записи.

Блок	Название поля	Описание
Основные	Название дочернего КД	Название КД уровня ниже. Правила формирования имени описаны выше.
Базовый продукт	Домен создается по-одному из базовых продуктов: Управлением доменами L2 Router SBC
Лицензии каналов	Внутренние SIP устройства	Максимальное количество одновременно зарегистрированных SIP устройств (поле devices в json лицензий).
Внешние SIP-транки	Максимальное количество линий во внешних SIPтранках (поле siptrunks в json лицензий).
Публичный канал WebService	Максимальное количество подключаемых публичных каналов интеграции WebService (поле webservice_public в json лицензий).
Канал подписки на события WebEventing	Максимальное количество внешних систем, которым разрешено подписываться на события (поле webservice_subscr в json лицензий).
Лицензии сценариев	Сценарии SVC	Максимальное количество созданных SVC сценариев (поле svcscripts в json лицензий)
Сценарии IVR	Максимальное количество созданных IVR сценариев (поле ivrscripts в json лицензий)
Лицензии очередей	SIP операторы очередей	Блок доступен если Базовый продукт = Router или IP-АТС 4/5 класса или Управление доменами L2. Максимальное количество SIP устройств во всех очередях. Если SIP устройство входит в две очереди, то это две лицензии (поле sipqueue в json лицензий).
Лицензии Дочерних КД (если Базовый продукт = Управлением доменами L2)	Дочерних доменов	Максимальное количество дочерних КД, которые можно создать под данным КД (поле domains в json лицензий)
Дочерних КД продукту Router	Максимальное количество дочерних КД c базовым продуктом Router (поле solution_router в json лицензий)
Параметры безопасности	Разрешить использование глобальных переменных	Определяет доступ к типу переменной 'Глобальная общая'. Если запрещено, то распространяется на все дочерние домены
Максимум одновременно запущенных сценариев КД на сайте (-1 = не ограничено)	Ограничивает количество исполняемых сценариев от имени домена на каждом сайте. По умолчанию не ограничено (-1). Не может быть назначено больше, чем выдано родительскому домену
Максимум исполняемых компонент в сценарии (-1 = не ограничено)	Количество исполняемых компонент в каждом запущенном экземпляре сценариев. Вложенные считаются отдельно. При прерывании добавляется 200 компонентов для ветки пост-обработки. Не может быть задано более, чем выдано родительскому домену. По умолчанию не ограничено (-1)
Дополнительная задержка между компонентами сценариев, мс	Усредненный таймаут между выполнениями компонентов сценария. По умолчанию не ограничено (0). Не может быть задано меньше, чем у родительского домена
Максимальная продолжительность экземпляра сценария, сек (-1 = не ограничено)	Продолжительность выполнения сценария в секундах, включая все вложенные сценарии. По умолчанию не ограничено (-1). Не может быть задано больше чем у родительского домена. При превышении дает еще 60 секунд на выполнение ветки пост-обработки
Комментарий	Комментарии	Текстовое поле. Возможность указать полезную информацию к учетной записи

Пользователи дочерних КД

В этом разделе настраиваются пользователи дочерних КД. В раскрывающемся списке нужно выбрать Домен, для Пользователей которого необходимо внести изменения. В списке отображаются все дочерние КД относительно текущего.

Рис. 6.14. Выбор дочернего домена.

После выбора домена появляется форма редактирования Пользователей. В верхней

части окна доступно переключение дочернего домена.

Рис. 6.15. Общий вид раздела.

Рис. 6.16. Экранная форма редактирования объекта

Таблица 6.7. Поля, доступные при создании и редактировании записи.

Блок	Название поля	Описание
Основные	Имя	Отображаемое имя пользователя
Логин	Имя пользователя учетной записи для входа в систему
Пароль	Пароль учетной записи
Часовой пояс	Время смещения в формате UTC
Права доступа	Роли доступа	Список ролей доступа. Подробно в «Роли и доступные приложения»
Разрешать выполнение операций CRUD сценария	При включении настройки под этим пользователем возможно внесение изменений в настройки домена из компонента сценария Операция. Настройка актуальна для ролей admin и crud.
Комментарий	Комментарии	Текстовое поле. Возможность указать полезную информацию к учетной записи

Таблица 6.8. Роли и доступные приложения.

Роль	Приложения	Комментарий
admin	Настройки	Администрирование домена и позволяет работать компоненту «Операция» из сценариев.
monitor	Монитор	Мониторинг домена.
scripteditor	Редактор сценариев	Данная роль позволяет пользователю просматривать и редактировать сценарии.
crud		Специальная роль, позволяющая работать компоненту «Операция» из сценариев.
selector	Селекторные совещания	Веб-приложение селекторных совещаний.
stat	Статистика вызовов (CDR)	Статистика вызовов.

Общие настройки

В данном разделе находится информация по основным настройкам Мастер КД, а также действие «Ввести лицензию» (подробно описано в разделе Ввод кода Лицензии). Создавать и удалять записи в этом каталоге нельзя. Для редактирования поля необходимо на нем два раза кликнуть.

Рис. 6.17. Общий вид раздела.

Таблица 6.8. Описание полей.

Название поля	Описание
Зарезервировано лицензий для МастерКД	Формат json. Указывается количество лицензий, которые могут использоваться в МастерКД для настройки дочерних КД L1 уровня и для SVC сценариев. Основные параметры: domains - Общее количество дочерних доменов solution_router - Router solution_sbc - Bridge solution_submaster - Управление доменами L2 svcscripts - SVC Сценарии Возможны зарезервировать и другие параметры лицензии. Общее количество лицензий, которые выписаны на Мастер зону указаны в Лицензионном договоре, а также можно посмотреть через запрос … /api/monitor/v1/dc/currentload в блоке lictotal. Пример json резервирования лицензий для МастерКД: { "domains": 16, "solution_esb": 3, "solution_router": 10, "solution_sbc": 7, "solution_submaster": 10, "svcscripts": 1 }
Код контекстного служебного сценария	Выбор контекстного служебного сценария, который будет запускаться параллельно с каждой коммутацией. В случае если поле не доступно для редактирования, изменить значение можно чрез api запрос.
Коды перенаправления	Переопределяют стандартные SIP коды срабатывания по типам переадресации По умолчанию применяются: decline – 603, busy – 486, timeout – 408, dnd – 404, 480, error – 0, other – остальные коды. В режиме редактирования необходимо в поле sipcode ввести SIP код ответа (если несколько, то через запятую) и в поле mode указать один из типов переадресации, указанный выше.
Рабочее время	График работы. Подробно по редактированию поля в «Редактирование рабочего времени»

Ввод кода Лицензии

Для ввода кода Лицензии нажмите кнопку «Ввести Лицензию». Введите ранее полученный код и нажмите «Сохранить». Проверить общее количество лицензий можно через запрос …/api/monitor/v1/dc/currentload в блоке lictotal.

Редактирование рабочего времениДля редактирования рабочего времени необходимо кликнуть по таблице раза, выделить нужное время и нажать на кнопку сохранить. Выделенное рабочее время, подсвечивается красным цветом.

Рис. 6.18. Настройка рабочего времени

Администрирование коммуникационного домена. Общие настройки

Аутентификация

Для управления КД необходимо авторизоваться через WS сервер того сайта, где обслуживается данный КД.

Первоначальные учетные записи администратора устанавливаются в родительском домене (Мастер домен).

Для работы в Web интерфейсе управления КОСКО УПАТС необходимо пройти процедуру

аутентификации. Для этого в адресной строке браузера необходимо ввести IP-адрес или

URL (fqdn) имя Web-сервера для управления.

Таблица 7.1. Поля аутентификации.

Домен	Имя Домена, к которому нужно подключиться. Может быть Мастер доменом или Коммуникационным. После прохождения процедуры аутентификации можно переключаться между всеми КД, доступными пользователю
Логин	Логин пользователя
Пароль	Пароль пользователя

В случае 3-х ошибок аутентификации в течении 1 минуты IP адрес источника будет заблокирован на 3 минуты. Если в эти 3 минуты попробовать войти снова, то счетчик времени блокировки сбросится на 3 минуты вне зависимости от корректности введенных значений. Блокировка действует на Web-сервере.

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

Главная страница

Здесь представлены доступные пользователю приложения - администрирования и ролевые. Набор приложений определяется ролями доступа пользователя в текущем домене. При нажатии на область блока приложения производится его запуск в текущем окне. При необходимости приложение можно открыть в новом окне/вкладке средствами браузера.

У пользователя одновременно может быть открыто любое количество приложений. В рамках одной сессии браузера все приложения работают под одной cookie (RCookie). Смена аутентификации в любом окне может привести к ошибкам сохранения данных в другом.

Рис. 7.1. Главная страница администрирования

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

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

Если пользователю доступен только один текущий домен, то возможность переключаться между доменами будет заблокирована.

Основной экран Web приложения «Настройки»

Верхняя часть экранной формы выглядит следующим образом:

Рис. 7.2. Верхняя часть страницы

Кнопка

, расположенная в верхней левой части, и логотип «КОСКО УПАТС» позволяет вернуться на Главную страницу.

В правой верхней части доступна информация о пользователе и активном домене.

Левая часть экранной формы содержит панель навигации.

С ее помощью можно перемещаться между разделами/объектами администрирования.

Центральная часть экранной формы содержит таблицу с данными выбранного в левой части раздела.

Внизу слева таблицы располагается кнопка "Фокус на таблице"

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

В верхней левой части над таблицей расположено поле для ввода фильтра.

Фильтрация позволяет отображать в таблице только те объекты, которые соответствуют критерию фильтра. Фильтр может быть простым (с одним критерием) и сложным (с несколькими критериями, разделенными запятой). При написании фильтра допускается применение масок:

• % - любые символы

• ИЛИ через ; (например, "a;b" означает поиск a или b)

• диапазон чисел 10;50 означает поиск в диапазоне [-inf, 10] ИЛИ [50, +inf]

Примеры применения фильтра можно посмотреть при нажатии на кнопку

справа от поля поиска.

В верхней правой части над таблицей расположены три кнопки «Новый объект», «Экспорт/импорт» и «песочные часы»

Кнопка «Новый объект» позволяет добавить новую запись в текущий раздел.

Кнопка «Экспорт/импорт» дает возможность восстановить данные из ранее сохраненного файла в формате csv (Импорт) или выгрузить данные из таблицы объектов (Экспорт). Здесь же можно посмотреть шаблон для импорта данных (Шаблон).

Историю изменений свойств объектов можно посмотреть по кнопке

Рис. 7.3. История изменений свойств объекта.

Рис. 7.4. Выбор интервала дат для просмотра истории изменения объектов.

В рамках диапазона дат доступны следующие закладки:

• Все - все события в текущем диапазоне

• Добавлено - все новые записи в текущем диапазоне

• Изменено - все записи, которые были изменены в текущем диапазоне

• Удалено - все записи, которые были удалены в текущем диапазоне

• Выбрано - все события по выбранной записи (одной) в текущем диапазоне.

Горячие клавиши

При работе с карточкой объекта можно воспользоваться горячими клавишами:

Карточка объекта:

• Ctrl+Enter – Сохранить;

• Ctrl+Shift+Enter - Сохранить как новый;

• Esc - закрытие карточки.

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

Рис. 7.5. Предупрждение о несохраненных данных.

В данном окне действуют следующие горячие клавиши:

• Ctrl+Enter – да;

• Пробел – да;

• Esc - возврат к редактированию карточки.

Во всех приложениях при всплывающих окнах действуют следующие горячие клавиши:

• Ctrl+Enter - нажатие на красную кнопку;

• Esc – отменить.

Маски и модификации

Правила работы с масками

Маскирование используется в КОСКО УПАТС для возможности меньшим количеством правил описать необходимое поведение системы. Маска выделяет значимые символы анализируемых полей для сравнения и принятия решения. В основном используется при обработке звонков.

При создании правил используется механизм базовых символьных правил, основанный на фиксированном местоположении анализируемых символов.

Базовые символьные правила маскирования

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

0 - любое количество символов

? - любой символ кроме точки

$ - любое количество символов до ближайшей точки

X - один символ

[ ] - перечисление возможных значений. Примеры:

[138] - 1 или 3 или 8

[4-7] - 4 или 5 или 6 или 7

[+15] - + или 1 или 5

[1-46-8] - 1 или 2 или 3 или 4 или 6 или 7 или 8

[0] - символ 0

{} - спецсимволы

{E} - пустое

{F} - значение from (номер источника)

{T} - значение to (номер назначения)

Таблица 7.2. Примеры масок:

Маска	Описание
ХХХ7890	Подходит для любых номеров, где 4~6 символы равны 789
07890	Правило описывает, что в номере есть подряд символы 789, начиная со второй позиции
[+]0	Любой номер, который начинается на
[0]98100	Любой номер, который начинается на 09810
+790[356]0	Любые номера, начинающиеся на +7903, +7905, +7906

Правила работы с модификаторами

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

Использование правил модификации позволяет сократить количество правил, необходимых для обработки полного набора значений входных параметров.

При создании правил модификации могут использоваться два механизма:

• базовые посимвольные правила, основанные на подмене;

• RegEx выражения.

Базовые символьные правила модификаций

Правило выполняется над всеми символами входного значения слева направо.

Х - перенести один символ в результат

0 - любые оставшиеся символы в результат

/X/ - исключение одного символа, можно указать несколько символов (например, /XX/

исключает два символа)

0-9 - добавляет символ в текущую позицию

[символ] - добавляет один символ между [] в результат. Символ может быть любым,

например, 0 или T

T - повторение первоначального номера

{} - спецсимволы

{E} - пустое

{F} - значение from (номер источника)

{T} - значение to (номер назначения)

Таблица 7.3. Примеры модификаций

Первоначальное значение	Правило	Результирующее значение
71234	T	71234
+71234	/X/0	71234
81234	7/X/0	71234
1234	7T	71234
534	712/X/0	71234
9123	/X/XX0	120
9123	120	120
123	099	12399
1005	[0]99	099

RegEx выражения модификации

Используется php RegEx ядро.

К исходному значению применяется шаблон pattern с опциями opts, и обнаруженный (- ые) блок(-и) заменяется(-ются) на шаблон replace. Результат может снова быть подан на следующую операцию RegEx-модификации, и так далее конечное число раз.

Общая структура записи RegEx-модификатора:

/reg/pattern1/substitution1/opts1 /reg/pattern2/sub2/opts2

Здесь:

• reg – константа;

• pattern – выражение;

• substitution - правило выборки;

• options - опции из (могут не указываться):

• g – global;

• i - case-insensitive.

Примеры:

значение: qwerty,qwerty

модификатор: /reg/t/E/g /reg/qwer/a/

результат: aEy,qwerEy

Для выделения номера назначения при получении INVITE пакета от IP-АТС Meridian /

Avaya: /reg/([0-9]+).0/\1/

При формировании шаблонов Pattern и Replace могут применяться все стандартные правила регулярных выражений, включая группы захвата, поиск назад, подстановку именованных групп и т.д.

Управление расписанием активности правил

При создании определенных правил в КОСКО УПАТС возможно задать расписание их срабатывания.

Расписание определяет время в часовом поясе объекта, когда настройка будет активна.

Пример:

По правилам «Маршрутизации» переключать на номер 1XX разрешено только с 10-00

до 18-00

У номера 123 установлен часовой пояс UTC+5

У номера 125 установлен часовой пояс UTC+2

С номера 255 в 17-00 UTC+3 позвонили на номер 123 - переключения не будет, т.к.

локальное время у 123 на момент звонка 19-00

С номера 255 в 18-30 UTC+3 позвонили на номер 125 - переключение будет, т.к.

локальное время у 125 на момент звонка 17-30

Рис. 7.6. Экранная форма создания расписания в формате ручного ввода

Таблица 7.4. Поля управления Расписанием (на примере одного из разделов).

Блок	Название поля	Описание
Расписание	Расписание	Определяет время, когда правило будет Активно: Любое время - активность правила не проверяется по времени. Настройка по умолчанию Рабочие часы - активно в рабочее время. Рабочее время устанавливается в «Общие настройки» и «Рабочее расписание» Вне рабочих часов - активно в нерабочее время Ручной ввод - правила задаются вручную ниже в интервале активности
Интервал активности (если Расписание = Ручной ввод)	Определяет недельное расписание активности правила. Для ввода правила Понедельник с 10 до 14 и с 18 до 20 в строке П выделяются соответствующие интервалы времени.

Расписание используется в следующих разделах:

• «Маршрутизация Выбор вектора»;

• «Маршрутизация Выбор правила»;

• «Правила переадресации»;

• «Правила записей разговоров».

Каналы коммуникаций. Подключение абонентских SIP устройств

Подключение SIP – устройств к УПАТС (IP – АТС КОСКО УПАТС) может осуществляться тремя способами:

• с помощью Web интерфейса администрирования коммуникационного домена (КД);

• с помощью API – запроса «Создание учетной записи sip-пользователя»;

• с помощью служебного сценария (svcscript).

Подключение SIP – устройств к УПАТС с помощью Web интерфейса администрирования КД

Для подключения SIP – устройств с помощью Web интерфейса требуется выполнить следующие операции.

7.7.1.1. Авторизоваться на сервере:

Рис. 7.7. Окно авторизации

Таблица 7.5. Поля авторизации

Домен	Имя Домена, к которому нужно подключиться. Может быть Мастер доменом или Коммуникационным. После прохождения процедуры аутентификации можно переключаться между всеми КД, доступными пользователю
Логин	Логин пользователя
Пароль	Пароль пользователя

7.7.1.2. На главной странице Router открыть приложение администрирования Настройки.

C левой стороны в области Объекты перейти в раздел Каналы коммуникаций - SIP устройства

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

• аппаратные SIP телефоны

• программные SIP телефоны

• WebRTC телефоны

• SIP-FXO, SIP-E1 шлюзы

Рис. 7.8. Общий вид раздела «SIP устройства»

В основной таблице раздела можно отобразить текущее состояние SIP устройств. Изначально столбец Статус скрыт. Для его отображения необходимо поставить галочку слева от записи Статусы (около кнопки Новый объект).

Для обновления статусов в таблице необходимо использовать кнопку обновления, которая находится справа от Статусы или перезагрузить страницу.

Если хоть 1 устройство зарегистрировано под данной учетной записью, статус имеет значение Зарегистрировано. При одном клике на данный статус внутри таблицы открывается окно с информацией о зарегистрированных устройствах.

Пример информации при одном зарегистрированном SIP устройстве:

**{**

**"addr": "10.10.10.10",**

**"expires": 941,**

**"path": \[**

**{**

**"domain": "0.0.0.0",**

**"port": 5060,**

**"proto": "tcp",**

**"user": "r_Q14p9rc"**

**}**

**\],**

**"port": 5063,**

**"proto": "udp"**

**}** 

Описание полей в ответе: Таблица 7.6. Описание полей записи устройства

Название поля	Описание
addr	IP-адрес SIP устройства. Если SIP устройство за NAT, то отображается локальный внутренний адрес устройства
---	---
expires	Оставшееся время жизни регистрации, сек.
---	---
path.domain	IP-адрес пограничной роли SG (SIP Gate) через которую это SIP устройство подключено к КОСКО УПАТС
---	---
path.port	Порт роли SG для приема пакетов от SIP устройства
---	---
path.proto	Внутренний транспортный протокол между SG и B2BUA, всегда = TCP
---	---
path.user	Внутренний идентификатор SIP устройства в хранилище КОСКО УПАТС
---	---
port	Порт SIP устройства
---	---
proto	Транспортный протокол, используемый между SIP устройством и ролью SG
---	---

7.7.1.3. Создать (редактировать) запись SIP – устройства (пользователя).

После нажатия кнопки «+ Новый объект» заполнить поля формы создания объекта:

Рис. 7.9. Форма создания объекта.

Описание полей при создании/редактировании записи:

Таблица 7.7. Описание полей при создании записи.

Блок	Название поля	Описание
Основные	Отображаемое имя	Поле, отображаемое на дисплее телефона (Display Name). Может содержать буквы, цифры, символы и макросы.
Номер	Телефонный номер учетной записи SIP
Количество устройств	Определяет: количество различных SIP устройств, которые могут одновременно быть зарегистрированы под текущей учетной записью количество лицензий devices которые будут зарезервированы под текущую учетную запись Возможные значения: 0 - подключение под этой учетной записью невозможно. Используется для создания номера и использования его для правил маршрутизации, переадресации; 1 - только одно устройство единовременно может быть подключено. Значение по умолчанию 2 и более - позволяет подключить несколько SIP устройств одновременно. При звонке на этот номер будет использоваться SIP Forking на все подключенные устройства.
Аутентификационные данные	Логин	Имя пользователя учетной записи SIP
Пароль	Пароль учетной записи SIP
Настройки вызова	Часовой пояс	Выбор часового пояса для данной учетной записи
Продолжительность вызова	Продолжительность вызова указанного номера в секундах. После достижения происходит переход по обработке “Нет ответа”. Значение по умолчанию = 30 секунд. Максимально допустимое значение 80 секунд, минимальное значение 1 секунда.
Продолжительность разговора	Продолжительность телефонного разговора для указанного номера в секундах. Если опция установлена, то система контролирует длительность разговора (коммутации 2-х абонентов). При достижении порогового значения происходит разрыв связи. В качестве максимального времени разговора А и В выбирается минимальное из значений: ограничение по абоненту A, ограничение по абоненту B. Если никаких ограничений нет, то максимальная длительность разговора – 2 часа (системное ограничение) или значение из лицензионного параметра dlglimit для тестовых лицензий. По умолчанию 0 (не ограничено).
Одновременно Входящих вызовов	Ограничение количества одновременных текущих разговоров для разрешения входящего звонка. Если достигнут указанный лимит, то при попытке звонка на текущий номер будет переход по ветке “Занято” (при этом количество исходящих одновременных вызывов не лимитируется). Возможные значения: -1 - Неограниченно (по умолчанию) 0 - Входящие вызовы запрещены 1 и более - ограничение количества занятых линий для входящего звонка.
MIN время Expires	Минимальное время жизни регистрации учетной записи абонента. Допустимое значение 30 - 3600 секунд. Подставляется в ответ, если expires в запросе меньше данного значения.
MAX время Expires	Максимальное время жизни регистрации учетной записи абонента. Допустимое значение 30 - 86400 секунд. Подставляется в ответ, если expires в запросе больше данного значения
Комментарий	Комментарии	Возможность указать полезную информацию по учетной записи.

После заполнения всех полей новой учетной записи, нажать кнопку «Сохранить» на форме.

Подключение SIP – устройств к УПАТС с помощью API – запроса «Создание учетной записи sip-пользователя»

7.7.2.1. Выполнить аутентификацию для выполнения запросов API.

Например:

**$ curl -c curl-worker.cookies \\**

**\-X POST \\**

**\-H 'Content-Type: application/json' \\**

**\-d '{"domain":"myDomain","login":"myLogin","pwd":"myPwd"}' \\**

**<http://10.10.10.10/rest/v1/iam/sessions>**

Здесь:

curl-worker.cookies - путь до файла в который будет сохранена сессионная cookie

"myDomain" - имя домена в котором выполняется аутентификация;

"myLogin" - логин пользователя

"myPwd" - пароль пользователя

http://10.10.10.10/rest/v1/iam/sessions - префикс URL, в формате http(s)://<host>:<port>. Адрес функциональной роли webserver с включеным API.

7.7.2.2. Выделить лицензии рабочему домену, в котором будут создаваться учетные записи (см. р.8), если они ранее не были выделены.

7.7.2.3. Выполнить аутентификацию для выполнения запросов API в рабочем домене.

7.7.2.4. Зарезервировать лицензии в рабочем домене.

**$ curl -b <cookie_file_path> \\**

**\-X PATCH \\**

**\-H 'Content-Type: application/json' \\**

**\-d '{"key":"licowned","value":<license_content>' \\**

**<api_prefix>/rest/v1/domain/settings/licowned**

Здесь: <license_content> - параметры лицензии.

7.7.2.5. Создать sip-пользователя.

**$ curl -b <cookie_file_path> \\**

**\-X POST \\**

**\-H 'Content-Type: application/json' \\**

**\-d '{"login":"<login>","pwd":"<pwd>","name":"<name>","phonenumber":"<phonenumber>"}' \\**

**<api_prefix>/rest/v1/uc/sipusers**

Здесь:

• <login> – логин sip-пользователя;

• <pwd> – пароль;

• <name> – имя;

• <phonenumber> – телефонный номер.

Например:

**$ curl -b curl-worker.cookies \\**

**\-X POST \\**

**\-H 'Content-Type: application/json' \\**

**\-d '{"login":"sip111","pwd":"pwd111","name":"name111","phonenumber":"111"}' \\**

**<http://10.10.10.10/rest/v1/uc/sipusers>**

**{**

**"devices": \[\],**

**"ext": {**

**"ct": "2019-11-01T11:06:41.45Z",**

**"lwt": "2019-11-01T11:06:41.45Z"**

**},**

**"id": "00000000-0000-0000-0000-000000000000",**

**"iduser": "00000000-0000-0000-0000-000000000000",**

**"lic": {**

**"devices": 123456789**

**},**

**"login": "sip111",**

**"name": "name111",**

**"opts": {**

**"agat_chassis_id": "",**

**"agat_lm_id": "",**

**"agat_port_id": "",**

**"calltimesec": 30,**

**"comment": "",**

**"dlgtimesec": 0,**

**"maxexpires": 3600,**

**"minexpires": 30,**

**"modextin": "",**

**"modextout": "",**

**"title": "",**

**"trunks": -1**

**},**

**"phonenumber": "111",**

**"pwd": "pwd111",**

**"reg": 1,**

**"timezone": "default"**

**}**

Подключение SIP – устройств к УПАТС с помощью служебного сценария (svcscript)

Учитывая необходимость регистрации в УПАТС как большого количества абонентов, так и большого количества SIP – устройств, на практике регистрация осуществляется с помощью специально сосотавленного для этих целей служебного сценария, осуществляющего интеграцию с каталогом Active Directiry (или другим соответсвующим служебным каталогом) для импорта учетных записей пользователей указанной целевой группы пользователей, с одной стороны, и автозагрузку конфигурационного файла на целевой IP – телефон, с другой стороны.

Порядок написания сценария интеграции см. п.9.1.

Каналы коммуникаций. Раздел «SIP провайдеры» Web – интерфейса администрирования УПАТС

Подключение УПАТС к другим системам коммуникаций осуществляется с помощью Web – интерфейса администрирования системы, раздел «SIP провайдеры».

Рис. 7.10. Раздел «SIP провайдеры».

Рис. 7.11. Экранная форма создания нового объекта

Поля, доступные при создании и редактировании записи:

Таблица 7.8. Описание полей при создании записи.

Блок	Название поля	Описание
Основные	Код	Код, который используется для ссылок на этого провайдера из других объектов настройки. Уникальный набор английских букв и цифр.
Активно	Включение/выключение данной учетной записи.
RoleID конфигурации	Идентификатор экземпляра Роли ESG (поле roleid) из конфигурационного файла, которая будет обслуживать это внешнее подключение. Важно: при создании новго подлкючения, предвариетльно требуется редактирование и активация новой версии конфигурационного файла!
Количество линий	Количество линий всего	Максимальное количество соединительных линий, которое может быть одновременно задействовано (количество одновременных SIP диалогов). Это лицензируемый параметр из количества доступных внешних линий КД (параметр siptrunks). При достижении лимита новые звонки (входящие и исходящие) будут отклонены.
Количество исходящих линий	Максимальное количество задействованных соединительных линий (количество одновременных SIP диалогов), которое блокирует использование текущего подключения для новых исходящих звонков. На входящие вызовы параметр не влияет. Должен быть меньше или равен Количество линий всего. Если не задан, то равен Количество линий всего.
Аутентификация	С регистрацией	включено - КОСКО УПАТС регистрируется на удаленной SIPАТС выключено - между КОСКО УПАТС и удаленной SIP-АТС устанавливается доверительное подключение без регистрации.
Имя пользователя	Используется в качестве поля Username. (Подробно в «Выбор SIP провайдера для входящих INVITE»)
Логин	(С регистрацией включено) Логин авторизации
Пароль	(С регистрацией включено) Пароль авторизации
SIP сервер	Домен или IP-адрес удаленного SIP сервера. При необходимости порт задается в настройке «Порт Outbound Proxyсервер».
Подключение	Адрес Outbound Proxyсервер	IP/fqdn адрес Outbound прокси-сервера. Если пусто, то не используется.
Порт Outbound Proxyсервер	Порт удаленной стороны: Outbound Proxy-сервера, если он задан; SIP сервер, если Адрес Outbound Proxy-сервер не задан.
Транспортный протокол	Протокол взаимодействия UDP, TCP, TLS.
Время перерегистрации	Время re-REGISTER timeout в секундах. По умолчанию 3600 сек. (с регистрацией включено).
Дополнительные настройки	Альтернативные адреса провайдера	Если провайдер может присылать SIP и RTP трафик с IP адресов, отличных от SIP сервера и Outbound Proxy-сервера, то их необходимо указать в этом поле. Можно задать несколько значений через запятую. Подробнее в «Альтернативные адреса провайдера».
Альтернативные Outbound Proxyсерверы	Альтернативные Outbound серверы в случае если первичный недоступен. Задаются через запятую в формате rotocol:ip/fqdn:port. Например, tcp:10.0.0.10:5060 или udp:gate3.sys.local:5080. Более подробно в «Альтернативные Outbound Proxy-серверы».
Значение domain в поле From	Используется для исходящих запросов от КОСКО УПАТС. По умолчанию подставляется значение из поля SIP сервер, но некоторые SIP-АТС требуют альтернативного поля. Поля номер источника, номер назначения, DisplayName источника изменяются в разделе «Нормализация номеров внешних линий»
Использовать транслитерацию	включено - все русские буквы в поле DisplayName SIP пакета будут заменены на соответствующие английские (перевод из UTF8 в ASCII); выключено - изменения в DisplayName не вносятся (значение по умолчанию).
Настройки медиа (одна из двух настроек должна быть включена)	Использовать свой Media шлюз	включено - SIP и RTP трафик отправляются с одного IP на сторону провайдера (требуется корректная настройка в конфигурационном файле роли BGMG (boarder gate Media gate) на сервере с ESG из поля RoleID); выключено - RTP трафик будет отправляться на сторону провайдера от MG (MediaGate) роли, ближайшей кинициатору вызова (минимально нагруженный MG на сайте, где был инициирован первичный INVITE пакет).
Прозрачно пробрасывать reINVITE на сторону провайдера	включено - все re-INVITE пакеты прозрачно отправляются на сторону провайдера (обычно используется при связи с другой АТС внутри организации и при режиме работы «Без регистрации»); выключено - re-INVITE не отправляются на сторону SIP провайдера и обрабатываются ролью ESG (обычно используется при подключении к внешним операторам связи и при режиме работы «С регистрацией»).
Проверка доступности	Режим проверки доступности	Используется для проверки доступности SIP провайдера, а также для поддержания NAT сессий. Возможные варианты настройки: Отключено - проверка доступности выключена; Поддержка открытого NAT (пакет rn) - запросы с типом rn, которые используются только для поддержания работы через NAT (не анализируются в качестве доступности внешнего подключения); SIP OPTIONS запрос - Основной режим проверки доступности. Отправляется SIP OPTIONS запрос, на который ожидается SIP 200 OK ответ; SIP REGISTER запрос - Вспомогательный режим проверки доступности ТОЛЬКО в случае, если SIP провайдер не поддерживает SIP OPTIONS и работает в режиме «С регистрацией». Периодически инициируется сессия регистрации, которая обрывается. Анализируется наличие ответа от удаленной стороны; STUN взаимодействие - режим проверки доступности через STUN запрос/ответ
Адрес проверки доступности	IP/DNS:Port сервера для проверки доступности. Обычно равно SIP сервер или Адрес Outbound Proxy-сервер
Пауза между проверкой доступности	Количество секунд между отправками сообщений. Если результат меняется относительно текущего (канал стал недоступен или канал стал доступен), то отправляется еще два сообщения с интервалом 3 сек. каждое. Если все три сообщения вернули одинаковый результат, то канал меняет свое состояние.
Комментарий	Комментарии	Возможность указать полезную информацию под записью.

Внимание!

• Любое изменение учетной записи приведет к прерыванию текущих коммутаций через это подключение и перезапуску этой учетной записи.

• Если провайдер настроен без регистрации, то Имя пользователя может быть либо пустым, либо должно соответствовать тому что пришлет провайдер в поле «Contact: user». Это необходимо для поиска принадлежности входящего INVITE на роль ESG учетной записи SIP провайдера.

• При указании fqdn (доменного имени) в любых настройках SIP провайдера КОСКО УПАТС делает запрос в DNS на разрешение имени только во время первичной регистрации или инициализации учетной записи. Во время работы список не изменяется. Поддерживается множественные IP на одном fqdn имени. Таким образом использовать fqdn имена для перетекания между IP адресами нельзя, а для отказоустойчивости параллельной работы нескольких SIP серверов провайдера можно.

• Обычно поле Значение domain в поле From используется в режиме «Без регистрации» и предоставляет возможность указать домен для исходящих пакетов.

Подключение IP – телефонов к УПАТС

Физическое подлкючение IP – телефона

Рассмотрим подключение IP-телефона к УПАТС КОСКО УПАТС на примере веб-интерфейса модели Yealink T31G.

В веб-интерфейсе телефона необходимо открыь вкладку «Аккаунт» и заполнить необходимые для подключения данные. Их описание приведено в таблице 7

Таблица 7.1. Поля, доступные для редактирования при подключении телефона

Название поля	Описание
Активность линии	Определяет статус активации учетной записи.
---	---
Лейбл	Текст, который будет отображен на телефонном аппарате.
---	---
Отображаемое имя	Имя, отображаемое на дисплее у тех, кому звонят.
---	---
Имя регистрации	Имя пользователя учетной записи SIP (обычно номер телефона).
---	---
Имя пользователя	Пользовательская часть sip-адреса (обычно номер телефона).
---	---
Пароль	Пароль учетной записи SIP.
---	---
Адрес SIP-сервера	Указать домен, в котором было создано SIP устройство. Домен можно видеть в верхнем правом углу при создании SIP устройства.
---	---
Транспорт	Транспортный протокол, используемый между SIP устройством и ролью SG.
---	---
Таймаут сервера	Настраивает период повторной регистрации (в секундах) после неудачной регистрации учетной записи.
---	---
Количество запросов	Количество запросов REGISTER, которое будет отправлено на сервер, прежде чем попытка регистрации будет считаться неудачной.
---	---
Использовать Outbound-сервер	Dключает или выключает отправку телефоном запросов на исходящий прокси-сервер. Включение данной опции обязательно.
---	---
Outbound Proxy Server	Адрес прокси-сервера. Здесь необходимо указать ip-адрес сервера с ролью SG.
---	---
Интервал Proxy	Настраивает период повторной регистрации (в секундах) после неудачной регистрации учетной записи.
---	---

Обработка звонка

IVR сценарии

В этом разделе происходит управление всеми IVR сценариями, существующими в рамках данного Коммуникационного Домена.

Рис. 8.1. Общий вид раздела

Рис. 8.2. Экранная форма создания нового объекта

Таблица 8.1. Поля, доступные при создании и редактировании записи.

Название поля	Описание
Название сценария	Название сценария удобное для восприятия. Возможно использовать русские и английские символы, пробел, цифры
Код сценария	Буквенно-численный идентификатор сценария в рамках Домена. На него ссылаются записи других объектов (например, в «Коды абонентских функций»). Доступны латинские символы и цифры
Дата последнего изменения сценария	Заполняется автоматически при изменении ранее созданного сценария
Ссылка на сценарий	Открытие сценария на редактирование в новой вкладке браузера
Уровень логирования	Уровень логирования определяет объем информации, который доступен при получении логов из «Мониторинга»: Отключено (значение по умолчанию) Только ошибки Ошибки и предупреждения Все события
Комментарии	Возможность указать полезную информацию под записью

Если у текущего пользователя нет роли scripteditor, то при открытии сценария на редактирование в новой вкладке откроется «Главная страница»

Очереди

В данном разделе настраиваются очереди обработки звонков группами операторов (SIP устройствами). Очереди могут обслуживать:

• входящие вызовы с внешних линий;

• входящие вызовы с внутренних линий;

• входящие вызовы от абонентов других доменов;

• входящие вызовы от IVR сценариев дозвона (для организации исходящего КЦ,

прогрессивного/предиктивного обзвона).

Рис. 8.3. Общий вид раздела

Рис. 8.4. Экранная форма создания нового объекта

Таблица 8.2. Поля, доступные при создании и редактировании записи.

Блок	Название поля	Описание
Основные	Код очереди	Код очереди. Данный код используется для ссылок на Очередь из других объектов. Рекомендуется делать равным Номеру очереди
DisplayName	Отображаемое имя при вызове Оператора
Номер очереди	Внутренний номер для вызова очереди. Используется при переводе, маршрутизации, настройке КАФ. Рекомендуется Код очереди делать равным Номеру
Операторы (агенты)	Список операторов (агентов) для обработки заданий очереди. Добавляются записи из раздела SIP устройства
Алгоритмы выбора	Способ выбора оператора очередью	Определяет алгоритм выбора оператора при поступлении звонка. Доступные варианты: Каскадный (по умолчанию) - выбирает из свободных ресурсов ровно в том порядке, как они указаны в списке в поле Операторы (агенты); Случайный - выбирает случайный ресурс из свободных на данный момент; Случайный с учетом приоритетов - выбирает из свободных ресурсов самый приоритетный ресурс, а если их несколько, то выбирает среди них случайным образом.
Способ выбора очереди оператором	Определяет алгоритм выбора очереди оператором, когда оператор освободился и в нескольких его очередях есть ожидающие абоненты на обслуживание. Доступные варианты: SPQ (Strict Priority Queueing) – режим выбора очереди на основании поля Приоритет очереди. Пока очередь с высоким приоритетом (меньшим числом) не будет свободна, более низкоприоритетные очереди не будут обслуживаться. Если несколько очередей имеют одинаковый приоритет, то выбор по максимальному времени ожидания абонента внутри очередей WFQ (Weighted Fair Queueing) – режим выбора очереди на основании поля Вес очереди. В данном случае система случайным образом выбирает следующую очередь в соответствии с весом очереди SPQ+WFQ - режим выбора очереди по алгоритму SPQ, и если несколько очередей выбрано, то между ними выбор по алгоритму WFQ.
Приоритет очереди	Приоритет очереди по сравнению с другими. Чем меньше число, тем более приоритетная очередь
Вес очереди	Вес очереди, чем выше число тем больше вес при обработке алгоритмом WFQ
IVR-сценарии	IVR сценарий приветствия в очереди	Выбор IVR сценария, который будет обслуживать входящий звонок в очередь первым. Используется для голосового приветствия, анализа состояния операторов, выстраивания правильного "каскада" обхода операторов, информирования CRM систем и прочее. Сценарий не обязательный. По завершению сценария будет запущен «IVR сценарий в очереди»
IVR сценарий в очереди	Обязательный сценарий с обязательным поднятием трубки (200 OK). С этим сценарием будет взаимодействовать Клиент при ожидании Оператора. Пока оператор не возьмет трубку и корректно (по компоненту «Стоп») не завершится «IVR сценарий перекоммутации». Клиент будет находиться в этом сценарии.
IVR сценарий прекоммутации	Необязательный сценарий взаимодействия Очереди и оператора перед соединением с Клиентом. Можно использовать для звукового оповещения Оператору, открытию карточки в CRM и т.д. Если сценарий завершился «Положить трубку» или другим компонентом, отличным от «Стоп», то текущий Оператор отказался от обслуживания Клиента и для Клиента продолжится поиск Оператора (при этом Клиент продолжит взаимодействие с «IVR сценарием очереди» без прерывания)
Управление дозвонами до операто ров	Количество одновременно вызываемых номеров в дозвоне	Если есть доступные операторы, то вызов одновременно может быть отправлен нескольким из них
Максимальное количество дозвонов	Если никто из вызываемых операторов не взял трубку, то попытка дозвона считается неуспешной и система может сделать следующую попытку. Количество попыток ограничено текущим параметром. При достижении лимита произойдет отбой или перевод абонента на указанный ниже номер
Номер для переключения при превышении попыток дозвона	Если за установленное количество дозвонов найти оператора не удалось, то абонент может быть переключен на указанный номер. Если номер не указан, то произойдет разрыв соединения.
Продолжительность одного дозвона, сек	Если в течении указанного времени никто из операторов не взял трубку, то дозвон считается неуспешным и операторы могут быть выведено из КЦ параметром ниже.
Время, на которое оператор становится заблокированным при не снятой трубке	Если дозвон завершился при не снятой трубке, то оператор может быть выведен из КЦ на указанное количество секунд.
Управление ожиданием абонента в очереди	Прекращать ожидание при отсутствии доступных операторов	Если включено, то разместить абонента в очереди при отсутствии операторов в КЦ нельзя. Если выключено, то абоненты размещаются в очереди и ожидают обслуживание при отсутствии операторов
Максимальное время ожидания абонента в очереди,сек	По достижению указанного времени считается что абонента не надо более держать в очереди. Он может быть переведен на номер или вызов завершится. По умолчанию 0 - не ограничено.
Номер для переключения при превышении попыток дозвона	Если за установленное количество дозвонов найти оператора не удалось, то абонент может быть переключен на указанный номер. Если номер не указан, то произойдет разрыв соединения.
Постобработка	Включено	Признак включена ли автоматическая постобработка по завершению звонка.
	Время, сек	Продолжительность постобработки по умолчанию.
	Причина	Текстовое поле, которое будет указано в отчетности для анализа нахождения в режиме Постобработка.
Комментарии	Коментарии	Текстовое поле. Возможность указать полезную информацию к учетной записи.

Для перевода любого вызова в очередь необходимо в «Маршрутизации» отправить звонок в «Коды абонентских функций» с типом «Очередь».

Групповые номера

Групповой номер - номер, который содержит в себе несколько других номеров и определяет последовательность их вызова системой. В групповой номер могут входить другие групповые номера и номера из SIP устройства. Номера внутри группового номера объединяются в наборы. Набор - один или несколько равнозначных номеров. Для каждого набора можно определить продолжительность вызова в секундах. По умолчанию продолжительность вызова - 30 секунд.

Рис. 8.5. Экранная форма создания нового объекта.

Таблица 8.3. Поля, доступные при создании и редактировании записи.

Название поля	Описание
Номер	Номер текущего группового номера (номер назначения при обработке правил маршрутизации)
---	---
Тип обхода	Определяет последовательность обхода между наборами: • по очереди - обход последовательно с Набор1 до Набор10 • все одновременно - звонок отправляется на все наборы одновременно • случайный порядок - последовательность наборов определяется случайно
---	---
Подгруппа набора 1 ~ Подгруппа набора 10	Каждый набор определяет один или несколько номеров (через запятую). Все номера в наборе набираются единовременно. В набор могут входить номера SIP устройства и другие групповые номера.
---	---
Продолжительность вызова набора 1 ~ Продолжительность вызова набора 10	Длительность в миллисекундах, в течении которых будет обрабатываться соответствующий набор. Минимальное число 1000, рекомендуемое максимальное 30000. Если не указывать используется дефолтное значение в 30000
---	---
Перехват звонка по групповым номерам	Определяет участвует ли эта группа в логике обработки Коды абонентских функций для типа Перехват звонка по групповым номерам.
---	---
Комментарии	Возможность указать полезную информацию под записью.
---	---

Правила переадресации

В этом каталоге настраиваются правила и виды переадресации по внутренним номерам.

Рис. 8.6. Экранная форма создания нового объекта.

Таблица 8.4. Поля, доступные при создании и редактировании записи.

Блок	Название поля	Описание
Основные	Название	Текстовое поле не обязательное к заполнению. Возможность указать название правила переадресации.
Приоритет	Приоритет правила. Чем меньше значение, тем выше приоритет.
Активно	Переключатель состояния правила: true - включено false - выключено
Тип переадрес ации	Возможность указать в каких случаях переадресовывать звонок: • Безусловная; Нет регистрации; Занято; Нет ответа; Отклонено; Режим DND; Ошибка вызова; Другая причина. Подробнее см. в «Типы переадресаций»
Номера переадресаций	Номер с которого переадрес овать	Указывается номер, который существует в SIP устройствах. Можно задать маску
Номер на который переадрес овать	Указывается номер, на который будет осуществлен вызов. Номер может быть внутренним, внешним, в другом КД, кодом абонентских линий, а также быть в виде правил модификации.
Расписание	Расписание	Определяет время, когда правило будет «Активно»
Интервал активности (если Расписан ие = «Ручной ввод»)	Определяет недельное расписание активности правила. Подробно в п.7.6 «Управление расписанием активности правил»
Комментарий	Комментарии	Возможность указать полезную информацию под записью

Важно: правила переадресации применяются только для вызова внутренних номеров (при срабатывании «Выбор правила» с действием «SIP абонент»).

Таблица 8.5. Типы переадресаций.

Тип	Описание
Безусловная	Абсолютная (безусловная) переадресация. Применяется до вызова номера. Срабатывает всегда вне зависимости от состояний изначально вызываемого абонента. Переводит BLF подписки на конечный номер автоматически.
Нет регистрации	Номер определен в SIP устройства, но ни одно устройство не зарегистрировано. Правило проверяется до коммутации на первоначальный номер.
Занято	Вызываемый номер занят, применяется при SIP коде ответа 486.
Нет ответа	Нет ответа в течении заданного времени вызова (поле «Продолжительность вызова» в SIP устройства) либо получен SIP код ответа 408.
Отклонено	Вызов отклонен. Применяется при SIP коде ответа 603.
Режим DND	На SIP устройстве включен режим DND, применяется по SIP кодам ответа 404 или 480.
Ошибка вызова	По любой ошибке системы (любая нештатная работа).
Другая причина	Пришел не обрабатываемый SIP код ответа.

Важно:

• Перед попыткой вызова SIP абонента проверяются правила с типами «Безусловная», «Нет регистрации». Если они срабатывают, то происходит маршрутизация на поиск номера из поля «Номер на который переадресовать». Для остальных типов переадресации срабатывание происходит после наступления события (SIP ответ с соответствующим кодом);

• Правила маршрутизации при переадресации расчитываются от номера,

на котором установлена переадресация (а не от номера, кто осуществляет вызов);

• При настройке «Безусловной» (абсолютной) переадресации, также BLF у всех подписчиков будут автоматически перенастроены на номер назначения.

Обработка сервиса

Служебные сценарии

В этом разделе происходит управление существующих служебных сценариев в рамках данного Домена.

Рис. 9.1. Общий вид раздела

Рис. 9.2. Экранная форма создания нового объекта.

Таблица 9.1. Поля, доступные при создании и редактировании записи.

Название поля	Описание
Название сценария	Название сценария удобное для восприятия. Возможно использовать русские и английские символы, пробел, цифры.
Код сценария	Буквенно-численный идентификатор сценария в рамках Домена. На него ссылаются записи других объектов. Доступны латинские символы и цифры.
Дата последнего изменения сценария	Заполняется автоматически при изменении ранее созданного сценария.
Ссылка на сценарий	Открытие сценария на редактирование в новой вкладке браузера.
Уровень логирования	Уровень логирования определяет объем информации, который доступен при получении логов из модуля мониторинга: Отключено (значение по умолчанию); Только ошибки; Ошибки и предупреждения; Все события.
Комментарии	Возможность указать полезную информацию под записью.

Важно:

если у текущего пользователя нет роли scripteditor, то при открытии сценария на редактирование, в новой вкладке откроется «Главная страница».

Служебные задачи

В этом разделе настраиваются правила запуска служебных сценариев по расписанию.

Рис. 9.3. Экранная форма создания нового объекта.

Таблица 9.3. Поля, доступные при создании и редактировании записи.

Блок	Название поля	Описание
Основные	Название служебной задачи	Используется для удобной идентификации запускаемой задачи.
Активность	Переключатель состояния задачи (Включена / Выключена).
SVC сценарий для запуска	Выбор служебного сценария для задачи.
Режим запуска	Кратность запуска	Выбор между: • Одноразовый запуск в заданное время • Периодический многократный запуск
Дата первого запуска SVC сценария	Определяет дату и время запуска сценария в UTC.
Дата завершения старта SVC сценария	Определяет дату и время завершения старта сценария при многократном запуске в UTC.
Интервал между запусками SVC сценариями	Только для многократного запуска. Определяет время между запуском сценариев, сек.
Несколько одновременных экземпляров	Только для многократного запуска: включено - допускается одновременное выполнение нескольких экземпляров служебного сценария; выключено - перед стартом нового экземпляра проверяется факт завершения предыдущей копии. Если не завершена, то новый экземпляр не запускается.
Расписание	Только для многократного запуска. Определяет время, когда правило будет активно: Любое время - активность правила не проверяется по времени. Настройка по умолчанию; Рабочие часы - активно в рабочее время настройки домена; Вне рабочие часы - активно в нерабочее время; Ручной ввод - правила задаются вручную. Рабочее время настраивается в разделе «Общие настройки».
Комментарий	Комментарии	Возможность указать полезную информацию под записью.

Ролевые приложения

Общее описание ролевого приложения

В этом разделе настраиваются ролевые приложения и происходит управление ролями доступа пользователей к ролевым приложениям на «Главной странице».

Рис. 9.4. Общий вид раздела.

Рис. 9.5. Экранная форма создания нового объекта.

Таблица 9.4. Поля, доступные при создании и редактировании записи.

Название поля	Описание
Id	Отображение ID Ролевого приложения. Поле только для чтения. Отображается при редактировании записи.
Путь приложения	Уникальный путь в рамках текущего домена. Может содержать только латинские буквы, цифры, символы
Название приложения	Название приложения на «Главной странице».
Права доступа	Указать все права доступа, которые необходимы для доступа к этому приложению.
SVC сценарий обработки запросов	Выбор из раздела «Служебные сценарии» сценария, который будет запускаться при обращении на это ролевое приложение.
Комментарий	Комментарии.

Установка ролевого приложения

1. Создать служебный сценарий

2. Создать RoleApp приложение. Подробнее в «Файл ролевого приложения».

3. Создать новую запись в текущем разделе.

4. Выгрузить zip-архив с RoleApp:

a. получить ID «Ролевого приложения» (после создания открыть карточку на

редактирование и скопировать значение поля id)

b. выгрузить zip-архив используя HTTP метод PUT на URL-адрес <ws_role>/rest/v1/domain/roleapps/<id>/attachment

указав Content-Type = multipart/form-data

5. Проверить корректность загруженного файла

a. выполнить HTTP запрос на тот же адрес методом GET

b. загрузится файл attachment (переименовать в attachment.zip и он должен быть равен первоначально загруженному zip-архиву)

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

Файл ролевого приложения

Ролевое приложение представляет из себя zip-архив, который будет распакован на

сервере при установке.

Архив содержит в себе две значимые части:

• Файл roleapp.json содержит описание приложения;

• Непосредственно web-приложение, выполняемое на стороне браузера.

Пример структуры файлов Ролевого приложения:

├── assets

│ └── img

│ └── desktop.svg

├── css

│ └── jsoneditor.min.css

├── index.html

├── js

│ ├── aes-js.js

│ ├── base64.js

│ ├── jquery-3.1.1.min.js

│ └── jsoneditor.min.js

├── monitor.js

└── roleapp.json

Файл roleapp.json

Должен быть валидным json файлом, размер которого не превышает 10Kb.

Пример json файла:

**{**

**"name": "Roleapp Sample",**

**"description": "Пример ролевого приложения",**

**"order": 5000,**

**"fa-icon": "fa-paw",**

**"iconPath": "assets/desktop.svg"**

**}**

Таблица 9.5. Описание ключей файла roleapp.json.

Название ключа	Описание
name	Название ролевого приложения. Значение поля будет использовано для названия ролевого приложения на Главной странице, если поле «Название приложения» не заполнено. Тип поля – строка. Обязательная переменная.
description	Описание ролевого приложения. Значение будет отображаться на Главной странице в блоке Ролевого приложения. Тип поля – строка. Обязательная переменная.
order	Порядок ролевого приложения при сортировке на Главной странице. Тип поля – число. Необязательная переменная.
iconPath	Путь до иконки в архиве приложения относительно папки ролевого приложения. Иконка будет отображаться на Главной странице. Обязательная переменная.
folder	Подпапка внутри архива в качестве папки с web-документами (по умолчанию используется весь архив от корня). Необязательная переменная. Если указан, то в результате по url установленного приложения будет доступен не корень архива, а указанная подпапка (в url не появляется). Например, если “folder”:”dist”, то index.html должен быть размещен в подпапке dist и файл roleapp.json нельзя будет получить из прямого URL ( /app/appname/roleapp.json ) ├── dist │ └── index.html └── roleapp.json

Маршрутизация

Любой вызов, который поступает в КОСКО УПАТС проходит через Маршрутизацию. Цель маршрутизации - определить где находится Номер В и отправить на него INVITE.

Настройка маршрутизации двухфакторная:

• первым выбирается вектор (настройки раздела «Выбор вектора»);

• затем внутри вектора выбирается результирующее правило (настройки раздела «Выбор правила»);

• если результирующего правило внутри вектора не найдено, то проверяются остальные векторы;

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

Выбор вектора

Данный раздел предназначен для настройки правил выбора вектора.

Рис. 10.1. Общий вид раздела «Выбор вектора».

Рис. 10.2. Экранная форма создания нового объекта.

Таблица 10.1. Поля, доступные при создании и редактировании записи.

Блок	Название поля	Описание
Основные	Название	Текстовое название вектора для визуальной идентификации.
Приоритет	Определяет порядок проверки правил (чем меньше значение, тем выше приоритет).
Вектор	Текстовое поле указания Вектора. Несколько правил могут ссылаться на одно текстовое значение.
Фильтрация (правила написания масок см. п.7.5)	Направление источника	Определяет откуда пришел звонок: 0 - правило для всех направлений; «Внутренние SIP абоненты» - абоненты, определенные в разделе «SIP устройства»; «Внешние SIP операторы» - внешние линии, определенные в разделе «SIP провайдеры»; Другие КД - звонок из другого КД текущей копии КОСКО УПАТС. Может быть: SIP абонент другого КД; внешняя линии другого КД; транзитно через другой КД.
Маска номера источника	Маска для Номера А.
Маска КД источника	Маска имени домена, откуда пришел запрос на маршрутизацию в текущий домен Заполнение поля актуально для «Направление источника = 0 или Другие КД».
Маска оператора SIP телефонии	Маска для фильтрации SIP провайдеры по полю Код Заполнение поля актуально для «Направление источника = 0 или Внешние SIP операторы».
Маска номера назначения	Маска для Номера В.
Расписание	Расписание	Определяет время, когда правило будет Активно.
Интервал активности (если «Расписание = Ручной ввод»)	Определяет недельное расписание активности правила. Подробно см. в п.7.6).
Комментарий	Комментарии	Возможность указать полезную информацию под записью.

Важно: если есть два правила с одинаковым приоритетом, то система обработает случайно только одно из них.

Выбор правила

В текущем разделе создаются правила управления маршрутизацией внутри вектора маршрутизации.

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

Рис. 10.3. Общий вид раздела.

Рис. 10.4. Экранная форма создания нового объекта.

Таблица 10.2. Поля, доступные при создании и редактировании записи.

Блок	Название поля	Описание
Основные	Название	Текстовое название правила для визуальной идентификации.
Вектор	Выбор вектора из созданных в разделе «Выбор вектора». Идентификация происходит по текстовому совпадению.
Приоритет	Определяет порядок проверки правил (чем меньше значение, тем приоритетнее).
Действие	Определяет результирующее действие текущего правила: Внутренний абонент - на номер, определенный в каталогах «SIP устройства» и «Групповые номера»; В другой КД - запрос дальнейшего действия будет отправлен в таблицу маршрутизации домена их поля "КД получателя"; Внешняя линия - вызов будет отправлен на выбранного в поле «Оператор SIP для внешнего звонка» SIP провайдера; Код абонентских функций – дальнейшая обработка звонка по логике, определенной в каталоге "Коды абонентских функций"; Запретить вызов - вызов будет завершен и отправлен инициатору SIP пакет с кодом 403.
КД назначения (Действие = В другой КД .	Указывается имя домена, куда будет отправлен запрос на дальнейшую маршрутизацию. Имя домена вводится текстом. В Домене назначения должно быть создано разрешающее правило в маршрутизации на прием и обработку запроса.
Оператор SIP для внешнего звонка (Действие = Внешняя линия)	Выбор кода внешней линии из раздела «SIP провайдеры».
Фильтрация (правила написания масок в п.7.5)	Направление источника	Определяет откуда пришел звонок: 0- правило для всех направлений; Внутренние SIP абоненты - абоненты, определенные в разделе «SIP устройства»; Внешние SIP операторы - внешние линии, определенные в разделе «SIP провайдеры»; Другие КД - звонок из другого КД текущей копии КОСКО УПАТС. Может быть: SIP абонент другого КД; внешняя линии другого КД; транзитно через другой КД.
Маска номера источника	Маска для Номера А.
Маска КД источника	Маска имени домена, откуда пришел запрос на маршрутизацию в текущий домен Заполнение поля актуально для «Направление источника = 0» или «Другие КД».
Маска оператора SIP телефонии	Маска для фильтрации SIP провайдера по полю «Код». Заполнение поля актуально для направления источника «= 0» или «Внешние SIP операторы».
Маска номера назначения	Маска для Номера В.
Модификация (правила написания модификато ров в п.7.5.3)	Изменение номера источника	Правило позволяет изменить номер источника. Используется ТОЛЬКО при обработке следующими правилами маршрутизации. Данный модификатор изменяет Номер А в INVITE правой стороны (для этого используются «Нормализация кросс-доменных звонков» при звонках между доменами или «Нормализация номеров внешних линий» при звонках на внешнюю линию. По умолчанию – T.
Изменение номера назначения	Модификатор изменяет Номер В, который далее используется для обработки следующими правилами маршрутизации и в поле To INVITE правой стороны. По умолчанию – T.
Расписание	Расписание	Определяет время, когда правило будет Активно.
Интервал активности (если Расписание = Ручной ввод)	Определяет недельное расписание активности правила. Подробно в п.7.6).
Комментарий	Комментарии	Возможность указать полезную информацию под записью.

Важно:

• Если «Действие = Внутренний абонент», но Номер В не определен ни в «SIP Устройства» ни в «Групповые номера», то правило игнорируется и поиск результирующего правила продолжается далее;

• Если «Действие = Внешняя линия», но выбранное подключение недоступно (подробно о доступности в главе «Состояния подключения и режимы проверки доступности» раздела «SIP провайдеры», п.7.8), то правило игнорируется и поиск результирующего правила продолжается далее;

• Если в рамках одного вектора созданы два или более правила с одинаковым приоритетом, то КОСКО УПАТС обработает все из них в случайном порядке до получения первого результирующего. Пример использования - объединение нескольких SIP провайдеров в единый транк с равномерно-случайной нагрузкой исходящих звонков;

• Блок «Фильтрации» идентичен как в разделе «Выбор вектора». Это позволяет вначале

• выбрать вектор по общим правилам, а потом детально сделать правила вызовов и модификаций;

• Правила написания масок и модификаторов подробно описаны в п.7.5.

Коды абонентских функций (featurecode)

Общие сведения

В этом разделе настраиваются правила маршрутизации и применения Кодов абонентских функций. С точки зрения логики обработки звонков, «Коды абонентских функций» являются обычными номерами, которые могут маршрутизироваться по общим правилам маршрутизации между доменами и отличаются только действием в «Выборе правила».

Рис. 10.5. Общий вид раздела.

Рис. 10.6. Экранная форма создания нового объекта.

Таблица 10.3. Поля, доступные при создании и редактировании записи.

Название поля	Описание
Префикс	Префикс номера В (указанная левая часть номера). Производится поиск всех правил, префикс которых соответствует набранному номеру по приоритетам. После применения правила Номер В распадается на: префикс - значение из текущего поля; остаток - Номер В за вычетом префикса.
Приоритет	Приоритет правила. Чем меньше значение, тем выше приоритет. Возможно указание нескольких правил с одинаковым приоритетом. Тогда применяется правило с более длинным префиксом (long-hunting).
Тип	Тип кода абонентской линии: Перехват звонка; Перехват звонка по групповым номерам; Конференция - запуск/вход в конференц-комнату; Сценарий IVR - запуск IVR-сценария по коду; Очередь - перевод звонка в голосовую очередь; Голосовая почта - работа с сообщениями в ящике голосовой почты; Отправка голосовой почты - прием сообщения голосовой почты и размещение его в ящике; Парковка - расположение абонента на парковочном месте; Взятие с парковки - освобождение парковочного места и взятие припаркованного абонента в разговор; Интерком - вызов абонента в режиме громкой связи; Вторжение - вызов абонента с принудительным прерыванием его текущего разговора (постановка на удержание).
Дополнительный параметр	В зависимости от выбранного действия, параметр может быть IVRсценарием, обслуживающим КАФ, дополнительным номером или нести другое значение.
Комментарии	Возможность указать полезную информацию.

Перехват звонка

Перехват звонка с указанием точного номера, с которого необходимо сделать перехват на текущего абонента. В качестве префикса задается featurecode, а остаток определяет абонентский номер перехвата.

Пример:

0 Входящий звонок на абонента А с номером 123. В системе определен FeatureCode 0920

как номер перехвата (префикс = 0920)

0 Абонент B набирает 0920123

0 Звонок с номера 123 перехватывается абонентом В

0 Безопасность (кто кого может перехватывать) решается через правила маршрутизации

(у А должны быть права на набор номера 0920123)

Перехват звонка по групповым номерам

Перехват звонка только с тех номеров, которые объединены с текущим через любой «Групповой номер» с установленным признаком «Участвует в Перехват звонка по групповым номерам». Если звонят несколько номеров, объединенных с перехватывающим, то перехват осуществляется для наиболее долго звонящего. Используется только значение «Префикс» (остаток не используется).

Пример:

**0 Входящий звонок на абонента А с номером 3453. В системе определен FeatureCode**

**0960 как номер группового перехвата (префикс = 0960)**

**0 Абонент B набирает 0960**

**0 Система создает список всех номеров, которые объединены с номером B через**

**«Групповые номера» с признаком «Участвует в Перехват звонка по групповым номерам». В полученном массиве находится номер, который звонит наиболее долго. Этот звонок**

**переводится на абонента B**

**0 Безопасность решается через признак «Участвует в Перехват звонка по групповым**

**номерам в групповых номерах».**

Конференция

Управляет создание неуправляемых конференц-комнат типа meet-me. Префикс определяет featurecode, остаток определяет номер конференц-комнаты. Если конференц-комната не существует, то она создается при первом звонке на нее. Если конференц-комната существует, то абонент добавляется в нее. Конференц-комната удаляется при выходе из нее последнего участника. Длина номера конференц-комнаты может быть любой (определяется правилами маршрутизации до попадания в таблицу КАФ). Права доступа разграничиваются на базе выбора правила.

Пример:

**0 Звонок на номер 099067899876. В системе определен FeatureCode 0990 как номер**

**Конференций (префикс = 0990)**

**0 Номер конференц-комнаты= 67899876**

**0 Если комната создана, то звонящий попадает в нее. Иначе комната создается.**

При необходимости создать “закрытую” комнату для сбора совещаний секретарем

необходимо:

• на базе правил маршрутизации сделать “выделенный” номер для секретаря, куда может позвонить ТОЛЬКО номер секретаря (например, маска назначения =0990{F});

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

• секретарь вызывает последовательно всех участников конференции;

• после сбора всех участников в конференцию секретарь кладет трубку. Комната будет существовать, пока последний участник не выйдет из нее;

• если участник разъединился, то он может попасть в эту конференц-комнату только через секретаря.

Важно: функции секретаря в этом кейсе может выполнять IVR-сценарий.

Сценарий IVR

Переключение на IVR сценарий автоматического обслуживания абонента в голосовом и сервисном режиме. Остаток не используется. В поле Дополнительный параметр выбирается IVR сценарий запуска. Один IVR сценарий можно запускать под разными КАФ. В IVR сценарии можно получить Номер В, по которому он был запущен.

Очередь

Переключение в Очередь обслуживания голосовых вызовов. Идентификация очереди возможна двумя вариантами:

• в поле «Дополнительный параметр» необходимо указать значение из поля «Номер Очереди для идентификации»;

• если «Дополнительный параметр» пуст, то «Номер Очереди» берется как Остаток.

Голосовая почта

Данный featurecode осуществляет переключение на сервис работы с сообщениями, находящимися в голосовом ящике. Алгоритм обслуживания определен скрытым IVR-сценарием и может быть переназначен в рамках домена. Номер голосового ящика вычисляется как Остаток.

На телефоне MWI должен быть настроен как Префикс+Остаток того голосового ящика, который необходимо "мониторить".

Вопросы безопасности решаются в рамках маршрутизации в «Выборе правила».

Пример:

**0 Префикс голосовой почты = 0850**

**0 Сотрудник может звонить только в свой почтовый ящик**

**0 Настроены два правила:**

**00 приоритет 100. Направление источника = Внутренний абонент, Номер А = 0, Номер В**

**\= \[0\]85\[0\]{F}, Действие = КАФ**

**00 приоритет 110. Направление источника = Внутренний абонент, Номер А = 0, Номер В**

**\= \[0\]85\[0\]0, Действие = запретить.**

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

Отправка голосовой почты

Данный featurecode осуществляет переключение на запись (оставление) голосового

сообщения. Алгоритм обслуживания определен скрытым IVR-сценарием и может быть переназначен в рамках домена. Номер почтового ящика вычисляется как Остаток.

Обычно применяют условные «Правила переадресации» для переключения в «Голосовую почту».

Голосовой ящик - номер в рамках домена КОСКО УПАТС, не связанный с номерами SIP устройства. Количество голосовых ящиков не лимитируется.

Пример:

**0 Префикс Отправка голосовой почты = 0860**

**0 Абонент В включил DND режим на SIP-телефоне и настроил правило переадресации по**

**DND на номер 0860123 (звонок от В на 0860123 корректен по правилам маршрутизации)**

**0 Абонент А позвонил на 123 (А может быть внутренним абонентом, кросс-доменом,**

**внешней линией, IVR сценарием)**

**0 Вызов будет переведен на Отправку голосовой почту на ящик 123**

**0 Если В подписан MWI на 0850123 (0850 префикс Голосовой почты), то после приема**

**сообщения от абонента А индикатор будет гореть до момента обработки всех новых**

**писем в ящике 123.**

Безопасность решается на уровне правил маршрутизации.

При помощи правила переадресации можно несколько номеров переводить в один общий голосовой ящик.

Парковка

Данный featurecode осуществляет постановку вызова на парковочное место. Каждое

парковочное место одновременно может обслуживать только одного абонента.

Алгоритм обслуживания определен скрытым IVR-сценарием и может быть переназначен в рамках домена. Номер парковочного места вычисляется как Остаток.

Пример:

**0 В системе определен FeatureCode 0810 как номер Парковки (Префикс = 0810)**

**0 Абонент А разговаривает с Абонентом В**

**0 Абонент А переводит В на номер 08105673**

**0 Если парковочное место пустое, то В будет припаркован на это место и будет**

**слушать музыку пока его кто-то не заберет с этого места**

**0 Если парковочное место занято, то парковки не произойдет и А может попробовать**

**запарковать на другое место или вернуться к разговору с А.**

Взятие с парковки

Данный featurecode осуществляет взятие вызова с парковочного места. Алгоритм обслуживания определен скрытым IVR-сценарием и может быть переназначен в рамках домена. Номер парковочного места вычисляется как Остаток.

Пример:

**0 В системе определен FeatureCode 0820 как номер Взятие с парковки (Префикс = 0820)**

**0 Абонент С набирает номер 08205673**

**0 Если парковочное место занято, то С продолжит разговор с запаркованным абонентом.**

**Парковочное место освободится**

**0 Если парковочное место пустое, то С получит SIP Cancel отбой.**

Интерком

SIP-телефон вызываемой стороны автоматически отвечает на вызов и переводится в

режим громкой связи (функция должна поддерживаться SIP-телефоном и быть включена на нем).

Остаток определяет номер вызываемого абонента в режиме Интерком. После его выделения запускается маршрутизация от А до Остаток и в результате будет вызов в режиме Интерком. В случае срабатывания Правила переадресации происходит блокировка в целях обеспечения безопасности.

Интерком разрешается только применительно к внутреннему SIP-абоненту.

Пример:

**0 В системе определен FeatureCode 0930 как номер Интеркома (Префикс = 0930)**

**0 Абонент А набирает 09301006**

**0 Входящий звонок на абонента B с номером 1006 в режиме интеркома.**

Вторжение

При срабатывании кода «Вторжение» происходит выделение номера (Остаток), по которому нужно сделать звонок, и он направляется на новый цикл поиска правил. Если действие результирующего правила из «Выбор правил» НЕ “Внутренний абонент”, то отправляется обычный вызов. Иначе проверяется текущий статус SIP-абонента:

• абонент свободен - отправляется обычный вызов

• абонент занят - отправляется вызов в режиме Интерком (если у вызываемого абонента (абонент B) достигнуто ограничение «Количество одновременных вызовов» в настройках SIP-устройства, то оно игнорируется). В этом случае тот абонент, с кем разговаривал абонент B ставится на удержание, а абонент B продолжает разговор с абонентом, кто позвонил через вторжение.

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

Пример:

**\* В системе определен FeatureCode 0940 как номер Вторжение (Маска номера назначения**

**\= 094#)**

**\* Абонент А набирает 094#1006**

**\* Система разбирает номер на составляющие части**

**\* Если абонент B с номером 1006 занят (находится в разговоре с абонентом C), то**

**вызов на В выполняется в режиме Интерком. Абонент C ставится на удержание, номер**

**1006 вступает в разговор с абонентом А. На аппарате абонента B (номер 1006) должен**

**поддерживаться режим Интерком**

**\* Абонент B не теряет разговор с абонентом С, он может переключаться между**

**абонентами, соединить А и С, перевести А и/или С на другой номер, создать**

**трехстороннюю конференцию.**

Нормализация номеров

Нормализация кросс-доменных звонков

Этот раздел позволяет управлять номером источника (Номером А) при звонках между КД (при кроссдоменных звонках). Номер назначения (Номер В) меняется в «Маршрутизации».

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

Примеры использования функционала:

• Корректное модификация номера А в случае пересекающейся номерной емкости между КД;

• Корректное модификация номера А в случае переводов звонка;

• Создание глобальной номерной емкости распределенной системы поверх локальных пересекающихся номерных планов различных подразделений (разных КД).

Логика проверки правил:

• первое сработавшее правило является окончательным и останавливает дальнейшую проверку);

• последовательность проверки правил:

• в начале проверяются правила в домене получателя звонка;

• если проверка в КД получателя не дала результата, то проверяется таблица в

• домене источника звонка;

• если проверка в КД источника не дала результата, то проверяется таблица в КД уровня L1, который является родителем по иерархии домена источника звонка.

Рис. 11.1. Экранная форма создания нового объекта.

Таблица 11.1. Поля, доступные при создании и редактировании записи.

Блок	Название поля	Описание
Основные	Приоритет	Определяет порядок проверки правил (чем меньше значение, тем выше приоритет).
Результирующее действие	Действие	Определяет результирующее действие: применить правило - текущее правило модификации Номера А будет применено, дальнейший поиск будет остановлен; закончить проверку - закончить проверку потекущей таблице и перейти к следующей таблице по логике обработки.
Изменение номера источника	Правило изменения Номера А. Подробно в Правила работы с модификаторами. По умолчанию - T
Фильтрация для правила	Направление источника	Определяет откуда пришел звонок: 0 - правило для всех направлений; входящий в текущий КД; исходящий из текущего КД.
Маска номера источника	Маска для поля domain у стороны А
Маска имя пользователя источника	Маска для поля Username у стороны А
Маска номера назначения	Маска для Номер В
Маска ТД назначения	Маска для поля Domain стороны В
Маска имя пользователя назначения	Маска для Username у стороны В
Комментарий	Комментарии	Возможность указать полезную информацию под записью

Подробное описание написание масок фильтрации см. п.7.5.1.

Нормализация номеров внешних линий

Этот раздел предназначен для управления нормализацией основных полей при входящих и исходящих SIP пакетах от SIP провайдеров.

Поля нормализации:

• Номер А;

• Имя отображения А (DisplayName A);

• Номер В.

Примеры использования функционала:

• Если по одной учетной записи SIP провайдера подается несколько номеров, то при

исходящем звонке необходимо корректно подставить один из них (к примеру в

зависимости от номера внутреннего абонента);

• При входящем звонке от SIP провайдера, который подключен к другой IP-АТС компании, необходимо нормализовать номер источника для поддержания

глобальной внутрикорпоративной маршрутизации.

Рис. 11.2. Экранная форма создания нового объекта.

Таблица 11.2. Поля, доступные при создании и редактировании записи.

Блок	Название поля	Описание
Основные	Приоритет	Определяет порядок проверки правил (чем меньше значение, тем выше приоритет).
Оператор SIP телефонии	Выбираем SIP провайдера, для которого будет действовать текущее правило.
Маска по коду оператора SIP телефонии	Маска для указания кода оператора SIP. Применяются «Базовые символьные правила маскирования» (см. раздел 7.5).
Фильтрация для правила	Изменение номера источника	Правило изменения поля Номер А в SIP пакете. По умолчанию «- 0». Подробно см. в п.7.5.3 «Правила работы с модификаторами».
Изменение «Имя Отображения источника»	Правило изменения поля DisplayName в SIP пакете. По умолчанию «- 0». Подробно см. в п.7.5.3 «Правила работы с модификаторами».
Изменение номера назначения	Правило изменения поля Номер В в SIP пакете. По умолчанию «- 0». Подробно см. в п.7.5.3 «Правила работы с модификаторами». Если «Направление источника = входящий с внешней линии», то результат применения модификации попадает в Маршрутизацию как номер А (источника).
Комментарий	Комментарии	Возможность указать полезную информацию под записью.

Важно:

• Рекомендуется во всех правилах использовать ИЛИ выбор по полю «Оператор SIP телефонии» ИЛИ по полю «Маска по коду оператора SIP телефонии»;

• Если для SIP провайдера заданы несколько правил по полю «Оператор SIP

Телефонии» и несколько правил по полю «Маска по коду оператора SIP телефонии», то первыми проверяются все правила по полю «Оператор SIP телефонии» вне зависимости от приоритетов;

• Срабатывание одного правила останавливает дальнейшую проверку и является результирующим. Исключение составляет, если значение поля «Изменение номера назначения» равно «priority=<номер>». Подробно про этот режим в п. 11.3 «Раздельная модификация Номера А и В».

Раздельная модификация Номера А и В

Если стоит задача модификации Номера А (50 номеров) и Номера В (40 номеров) независимо друг от друга, то для решения этой задачи полным перебором необходимо создать 50*40=2000 правил модификаций.

Для упрощения задачи введен режим независимой модификации вначале Номера А и DisplayName, а затем Номера В. Для включения этого режима на первом сработавшем правиле поле Изменение номера назначения должно быть равно priority=X, где X - любое не отрицательное число. В этом случае алгоритм работы будет следующим:

1. Ищется правило по начальным Номер А, DisplayName A, Номер В. Например, найдено правило Rule1 с приоритетом 150, у которого `Изменение номера назначения` равен priority=2000\

2. Из Rule1 применяется модификатор `Изменение номера источника` к Номер А и `Изменение Имя отображения источника` к DisplayName A

3. Ищется новое правило по 0измененному0 из Rule1 Номеру А и DisplayName и *начальному* Номеру В, начиная с приоритета 2000 (указан как значение поля** `Изменение номера назначения` у Rule1). Например, найдено правило Rule2 с приоритетом 2035.**

4. Из Rule2 применяется значение `Изменение номера источника`к начальному номеру В.**

Внешние интеграции

Интеграция с Active Directory

Синхронизация данных между УПАТС КОСКО УПАТС и LDAP выполняется за счет трех служебных сценариев: «Глобальные переменные», «Интеграция с AD», «Генерация Конфигурационных файлов».

Интеграция с системой ВКС

Интеграция по звонкам

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

Интеграция по статусам BLF

Передача статусов присутствия из системы УПАТС КОСКО УПАТС в ВКС Труконф осуществляется с помощью функции BLF. Для этого на УПАТС создается служебная учетная запись sip device с логином trueconf, а далее сервер Труконф с помощью этой учетной записи регистрируется на сервере УПАТС и подписывается на состояние абонентов. Благодаря этому сервер ВКС получает информацию о статусе занятости абонентов УПАТС и отображает данные статусы в клиенте Труконф.

Управление записями разговоров

Правила хранения записей

В этом разделе настраиваются правила хранения записей разговоров.

Рис. 13.1. Экранная форма создания нового объекта.

Таблица 13.1. Поля, доступные при создании и редактировании записи.

Название поля	Описание
Название правила	Произвольное текстовое поле. В дальнейшем данное имя будет использоваться в разделе Правила записей разговоров. Рекомендуются уникальные наименования
Период хранения	Период хранения записи разговора в днях. Минимально 0, дней. Максимально 1850 дней (5 лет). Ноль дней хранения означает удаление во время ближайшей операции. Операция удаления производится 1 раз в день в ночное время (с 1:00 до 4:59 UTC)
Комментарии	Возможность указать полезную информацию

Важно:

• Любая запись разговора закреплена за определенным правилом хранения. Поэтому изменять или удалять правило хранения необходимо с большой осторожностью;

• При удалении правила все закрепленные за данным правилом записи разговоров будут удалены ближайшей операцией;

• При изменении периода хранения в большую сторону, ближайшей операцией

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

• При изменении периода хранения в меньшую сторону, ближайшей операцией производится перерасчет периода хранения записи разговора. Запись разговора будет хранится меньше на количество уменьшенных дней. Если срок хранения уже истек, то запись разговора будет удалена в ближайшую ночь.

Правила записи разговоров

В этом разделе настраиваются правила записи разговоров.

Рис. 13.2. Экранная форма создания нового объекта.

Таблица 13.2. Поля, доступные при создании и редактировании записи.

Блок	Название поля	Описание
Основные	Приоритет	Определяет порядок проверки правил (чем меньше значение, тем выше приоритет)
Записывать	Включено - разговор будет записан и доступен в модуле статистики; Выключено - разговор не будет записан.
Правило хранения	Выпадающий список правил, созданных в разделе «Правила хранения записей» (п.13.1).
Фильтрация	Направление вызова	Определяет направление звонка для данного КД: 0 (Любое направление) - правило для всех Направлений; А и B в текущем КД - звонки между абонентами текущего КД; Входящий звонок в текущий КД - внешние звонки в текущий КД (с внешней линии или из другого КД); Исходящий звонок из текущего КД - звонки из текущего КД наружу (на внешнюю линию или в другой КД).
Маска номера источника	Маска для Номера А
Маска номера назначения	Маска для Номера В
Маска кросс-домена	Маска имени КД при кросс-доменном звонке
Расписание	Расписание	Определяет время, когда правило будет Активно
	Интервал активности (если Расписание = Ручной ввод)	Определяет недельное расписание активности правила. Подробно см в п. 7.6. «Управление расписанием активности правил».
Комментарий	Комментарии	Возможность указать полезную информацию под записью

Сработавшее правило является конечным (проверка подходит ли правило осуществляется по полям блока «Фильтрация»).

Важно:

• Фиксация правил записи и хранения производится после ответа вызываемой стороны. Если в домене номера А или в домене номера В есть правило записи разговора, то запись ведется и закрепляется за правилом хранения;

• Если необходимо включить запись для конференц-комнат (селекторных совещаний) или для IVR-сценариев, то необходимо дополнительно включить параметр record_conf или record_ivr у Ролей в конфигурационном файле КОСКО УПАТС;

• Маски описаны в разделе 7.5.

Настройки коммуникационного домена

Общие настройки

В данном разделе находится информация по текущему КД. Создавать и удалять записи в этом каталоге нельзя. Для редактирования поля необходимо на нем два раза кликнуть.

Рис. 14.1. Общий вид раздела.

Таблица.14.1. Поля, доступные при создании и редактировании записи.

Название поля	Описание
Зарезервировано лицензий для устройств КД	Формат json. Указывается количество лицензий, которые могут использоваться в текущем КД для настройки основных объектов. Основные параметры: devices - количество учетных записей SIP устройств ivrscripts - количество IVR Сценариев sipqueue - количество операторов в очередях КЦ siptrunks - количество линий в SIP операторах svcscripts - количество SVC Сценариев webservice_public - количество Внешних интеграций с типом Публичный канал webservice_subscr - количество Внешних интеграций с типом Событийный канал Eventing Возможны и другие параметры лицензии. Текущие выписанные лицензии от родительского КД можно узнать запросом … /api/monitor/v1/dc/currentload в блоке lictotal конфигурационного файла. Пример json резервирования лицензий для текущего КД: { "devices": 10, "ivrscripts": 5, "sipqueue": 10, "siptrunks": 10, "svcscripts": 5, "webservice_public": 2, "webservice_subscr": 2 }
Рабочий график	Режим графика работы: • 0 - не задан • 1 - ручной ввод в поле Рабочее время • 2 - наследование от родительского домена.
Рабочее время	График работы в случае, если Рабочий график равен 2. Подробнее в п. 14.1.1. «Редактирование рабочего времени»
S3 объектное хранилище	Массив подключений в формате json. Формат и способ задания в п.14.1.2 «S3 объектное хранилище»
Ключ yandex_speechkit	Задается API-ключ для доступа к Yandex Speech Kit сервису.

Редактирование рабочего времени

Для редактирования рабочего времени необходимо кликнуть по таблице 2 раза, выделить нужное время и нажать на кнопку сохранить. Выделенное рабочее время, подсвечивается красным цветом.

Рис. 14.2. Настройка рабочего времени.

S3 объектное хранилище

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

"type":"s3" - константа

"bucket":"...",

"key":"...",

"secret":"...",

"endpoint":"...", - для amazon можно не указывать

"region":"...", - указать при необходимости

"prefix" – определяет относительную папку для размещения записей, если оставить пустым, то будет использоваться - "jrnl_callrec"

Пример:

**\[{**

**"type": "s3",**

**"bucket": "Cosco_ysk",**

**"key": "A.someKey..A",**

**"prefix": "pbx/callrecs",**

**"secret": "K..someSecret.O",**

**}**

**\]**

Пользователи

В этом каталоге настраиваются пользователи и администраторы коммуникационного домена.

Рис. 14.3. Стартовая страница раздела.

Рис. 14.4. Экранная форма редактирования нового объекта.

Таблица 14.2. Поля, доступные при создании и редактировании записи.

Блок	Название поля	Описание
Основные	Имя	Отображаемое имя пользователя
Логин	Имя пользователя учетной записи для входа в систему
Пароль	Пароль учетной записи
Часовой пояс	Время смещения в формате UTC
Права доступа	Роли доступа	Список ролей доступа. Содержит роли для: Ролевых приложений. Список ролей и доступ к приложениям определяется при создании ролевых приложений; Системных Web приложений. Подробно см. в таб. 14.3. Роли системных Web приложений.
	Разрешать выполнение операций CRUD сценария	При включении настройки под этим пользователем возможно внесение изменений в настройки домена из компонента сценария. Настройка актуальна для ролей admin и crud
	Разрешать выполнение операций в API сценарии	При выполнении в сценарии «компонента API» от имени этого пользователя, будет разрешено выполнять методы API с настройками домена.
Комментарий	Комментарии	Текстовое поле. Возможность указать полезную информацию к учетной записи.

Таблица 14.3. Роли системных Web приложений.

Роль	Приложения	Комментарий
admin	Настройки	Администрирование домена и позволяет работать компоненту «Операция» из сценариев
monitor	Монитор	Мониторинг домена
scripteditor	Редактор сценариев
crud		Специальная роль, позволяющая работать компоненту «Операция» из сценариев
selector	Селекторные совещания	Веб-приложение селекторных совещаний.
stat	Статистика вызовов (CDR)	Статистика вызовов.

Рабочее расписание

В данном разделе указываются исключения для рабочего графика работы текущего Домена. Сам рабочий график настраивается в разделе «Общие настройки» в блоке «Рабочий график и Рабочее время».

Рис. 14.5. Экранная форма создания нового объекта.

Таблица.14.4. Поля, доступные при создании и редактировании записи.

Название поля	Описание
Дата	Определяет дату исключения рабочего графика. Формат YYYY-MM-DD
Использовать ежегодно	Определяет многократность запуска: выключено - разовое правило; включено - ежегодное правило. При сохранении, если «Ежегодный» включено, то у даты проставляется нулевой год.
Тип	Указывается тип дня после замены: Нерабочий день - указанный день будет нерабочим Рабочий за день недели - указанный день будет вместо другого дня Согласно настройке - ручная настройка расписания
Замена дня недели	Указывается если необходимо перенести рабочий день: За указанный день - признак дня неделе не меняется; Понедельник - работа в указанный день по Понедельнику; Вторник - работа в указанный день по Вторнику; Среда - работа в указанный день по Среде; Четверг - работа в указанный день по Четвергу; Пятница - работа в указанный день по Пятнице; Суббота - работа в указанный день по Субботе; Воскресенье - работа в указанный день по Воскресенью.
Комментарии	Возможность указать полезную информацию под записью

Важно: Если выбрать «Тип = Согласно настройке», «Замена дня недели = Воскресенье», то в поле «Интервал времени» временной промежуток надо настроить для Воскресенья.

Адресная книга

Этот раздел позволяет управлять адресной книгой в рамках Домена. Данные могут быть синхронизированы с внешними системами учета кадров (например, с AD/LDAP) через служебный сценарий по расписанию, а также могут быть заполнены вручную. Объект используется для:

• Селекторных совещаний;

• DisplayName SIP устройств.

Рис. 14.6. Экранная форма создания нового объекта.

Таблица.14.5. Поля, доступные при создании и редактировании записи.

Блок	Название поля	Описание
Основные	Имя абонента	Основной идентификатор. Может использоваться в качестве «Имя отображения» при звонках с «Основного номера».
Номера телефонов	Основной номер	Основной внутренний номер
Мобильный номер	Мобильные номера абонента
Мобильный номер 2
Мобильный номер 3
Локальный внутренний номер	Локальный номер внутри подразделения / отдела
Публичный внутренний номер	Публичный внутренний номер абонента
Должность	Должность	Наименовании должности
Отдел	Название отдела
Номер офиса/комнаты	Номер офиса или комнаты, где находится сотрудник
Номер офиса/комнаты 2
Номер офиса/комнаты 3
E-mail	E-mail адрес	Почтовые адреса для связи. Поле несет в себе дополнительную информацию об пользователе.
E-mail адрес 2
E-mail адрес 3
Комментарий	Комментарии	Возможность указать полезную информацию под записью.

Важно: при добавлении участников к селекторному совещанию все заполненные номера из адресной книги выпадают списком.

Мониторинг УПАТС

Сущеуствует два типа мониторинга УПАТС КОСКО УПАТС:

• Мониторинг Мастер-домена, позволяющий осуществялть мониторинг всего кластера системы (доступность нод кластера, состояние ролей)

• Мониторинг коммуникационного домена, позволяющий осуществлять мониторинг отдельного домена, а именно состояние звонков, сценариев, регистраций абоненстких устройств (подробнее описано в официальной инструкции по мониторингу коммуникационного домена УПАТС Пр. Д МКДОS - Приложение Д. Мониторинг коммуникационного домена КОСКО УПАТС)

Рассмотрим ключевой способ мониторинга всей системы средством мониторинга мастер-домена.

Более подробно все ключи и методы для мониторинга мастер-домена описаны в официальной инструкции по мониторингу мастер-домена (УПАТС Пр. Г ММДОS Приложение Г. Мониторинг мастер домена КОСКО УПАТС).

Проверка состояния системы

15.1.1 Необходимо произвести авторизацию в мастер-домене ats1.abr95.test

15.1.2 Перейти в приложенеи «Монитор системы»

15.1.3 В поле «Объект» выбрать «Состояние системы», «Метод» - «state» нажать на кнопку «Показать»

15.1.4 При отсутствии предупреждений и ошибок метод вернет пустой результат «[]»

Ошибка недоступности сервера

15.1.5 При недоступности определенного сервера будет выводится сообщение с ключом «unavailable_servers» - в данном случае необходимо убедиться в работоспособности данной виртуальной машины, в корректной работе docker-контейнера с экземпляром КОСКО УПАТС на данном сервере и его сетевой доступности.

Проверить работу корректную работу docker-контейнера и, в случае ошибок, восстановить работоспособность сервиса на сервере можно при помощи данных команд:

15.1.5.1 Для начала нужно убедиться, что запущена служба docker:

**$ systemctl status docker**

Ожидаемый результат:

Служба в состоянии active, в противном случае выполинть запуск службы командой

$ systemctl start docker

15.1.5.2 Получить список всех контейнеров:

**$ sudo docker ps -a**

Ожидаемый результат:

Контейнер Cosco должен иметь STATUS=Up {время работы}

Если контейнер имеет другое значение STATUS, то необходимо выполнить его запуск:

**$ sudo docker start Cosco**

15.1.5.3 После чего вновь проверить статус контейнера (п. 15.1.5.2)

15.1.5.4 Если контейнер запущен необходимо проверить работу сервиса внутри контейнера данной командой:

**$ docker exec –it Cosco status**

Ожидаемый ответ:

Cosco. Status. Result:" Cosco ldaemon:coscodaemon1 RUNNING pid 1782362, uptime 28 days, 20:48:37, где

RUNNING – означает, что сервис КОСКО УПАТС выполняется.

15.1.5.5 Если сообщение отличается, то нужно запустить сервис командой

$ docker exec –it Cosco cosco start

Ошибка ноды на сервере

Так-же возможна ситуация, когда сервер доступен, но конкретная нода сервера неактивна или генерирует ошибки. В данном случае в мониторинге после выполнения запроса из пункта 15.1.3 можно наблюдать сообщение с ключом «inactive_nodes». Система постоянно производит самоанализ и перезапуск проблемных нод автоматически. Как правило это происходит незаметно для пользователей и администратора системы. Но если проблема с нодой наблюдается в течение некоторого времени (более 10 минут) можно выполнить ручной перезапуск проблемной ноды. Это осуществляется при помощи следующего API-запроса из мастер-домена:

https://{server_ip}/api/admin/v1/system/restart?nodes={nodes}&td={master_domain}&login={login}&pwd={password}

где server_ip – адрес сервера УПАТС

nodes – имена нод в том формате, который отдает мониторинг. Если несколько, то через запятую

master_domain – мастер домен системы (ats1.abr95.test)

login – логин польователя мастер домена

password – пароль пользователя мастер домена

Резервное копирование УПАТС

Резервное копирование виртуальных машин, обеспечивающих работу УПАТС осуществляется штатными средствами резервного копирования. Клиенты системы резервного копирования установлены на хосты кластера виртуализации.