РТУ МОА 2.1.0. Практическое руководство администратора (2018 год)

Контроль за ресурсами Системы | 167

9 Контроль за ресурсами Системы

В процессе работы с РТУ МОА возникает необходимость контролировать определенные ресурсы

Системы для того, чтобы избежать исчерпания лицензии или места на жестком диске.

Для контроля за объемом созданных и доступных услуг и объектов используйте страницу Базовая

конфигурация → Лицензии → Данные о использовании объектов.

Для мониторинга места, занимаемого аудиофайлами, используйте страницу Базовая конфигурация →

Сведения о занимаемом месте на диске.

9.1 Данные о использовании объектов

Данная страница содержит информацию об использовании и ограничении на использование объектов

(абонентов, терминалов, шлюзов, доменов и т.п.) и услуг (абонентских и системных сервисов) в домене,

в который выполнен вход, и в его поддоменах. Для домена ROOT количество объектов и услуг

ограничивается лицензией, для всех остальных доменов - профилем домена.

Чтобы отобразить список всех доступных и используемых услуг и объектов в домене, в разделе

Настройки отображения выставьте переключатель на вариант Домен и в раскрывающемся списке

справа выберите необходимый домен или его поддомен.

Чтобы отобразить сводную информацию об использовании определенной услуги или объекта в рамках

домена, в который выполнен вход, и во всех его поддоменах, выставьте переключатель на вариант

Услуга/Базовый объект и выберите необходимый объект или услугу.

Предположим, домены Domain1, Domain2 и mvno1 являются поддоменами домена New_Domain, и при

попытке создания бизнес-абонента в домене New_Domain выдается ошибка, сообщающая, что лимит на

использование бизнес-абонентов превышен. Для проверки данной информации в домене New_Domain

перейдите на страницу Базовая конфигурация → Лицензии → Данные о использовании, выставьте

переключатель на вариант Услуга/Базовый объект, в раскрывающемся списке справа выберите

Бизнес-абоненты и нажмите Показать.

В результате в таблице Сводная информация будут представлены данные об использования объекта

типа Бизнес-абонент в домене New_Domain и во всех его поддоменах (см. рисунок ниже). Данная

информация позволяет оценить, сколько объектов типа Бизнес-абонент выделено каждому из доменов

и сколько учетных записей бизнес-абонентов там действительно создано. В нашем примере на рисунке

видно, что домену mvno1 выделено 20 бизнес-абонентов, но ни одной учетной записи бизнес-абонента

168 |

не создано. Возможно, в данном случае имеет смысл сменить профиль домена mvno1 на профиль,

разрешающий использование меньшего количества бизнес-абонентов. У домена New_Domain, таким

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

которое было уменьшено количество бизнес-абонентов, выделенных поддомену mvno1.

9.2 Сведения о занимаемом месте на диске

Данный раздел позволяет просматривать подробную информацию об объеме, занимаемом на жестком

диске аудиофайлами того или иного типа:

аудиофайлами, используемыми для замены системных аудиофайлов домена пользовательскими,

аудиофайлами записей разговоров домена,

аудиофайлами голосовых сообщений во всех ящиках системной голосовой почты домена.

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

абонентской голосовой почты.

аудиофайлами, использованными во всех поддоменах.

Взаимодействие с RADIUS-сервером | 169

Взаимодействие с RADIUS-сервером

10.1

Общие принципы взаимодействия с RADIUS-сервером

Возможность взаимодействия станции с RADIUS-сервером обеспечивает выполнение трёх задач:

аутентификация регистрационного запроса для регистрации абонента и определения

возможности направления вызовов на этого абонента.

Для решения данной задачи на RADIUS-сервер выполняется отправка пакета аутентификации с

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

авторизация вызова (предоставление определенному пользователю права на совершение вызова

в заданном направлении).

Для решения этой задачи на RADIUS-сервер выполняется отправка авторизационных пакетов с

указанием вызывающего и вызываемого номеров, а также других параметров вызова.

учет вызовов.

Для выполнения данной задачи на RADIUS-сервер отправляются пакеты учета по каждому

созданному участку вызова. Данные пакеты содержат информацию о начале (AccountingStart) и

окончании (AccountingStop) сеанса учета вызова, начале вызова, установлении соединения и

завершении вызова, а также о вызывающем и вызываемом номерах. На основе переданных

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

пользователю системы.

10.2

Первичная настройка Системы для взаимодействия с

RADIUS-сервером

Основные настройки Системы для взаимодействия с RADIUS-сервером выполняются в разделе Базовая

конфигурация → RADIUS. Исключение составляет сервис «Карточная Платформа», для которой

взаимодействие с RADIUS-сервером настраивается на странице Внешние сервисы → Карточная

платформа → RADIUS.

Для настройки взаимодействия Системы с RADIUS-сервером, на странице Базовая конфигурация →

RADIUS выполните следующие действия:

Отметьте флажок Включить.

В секции Адреса сервера:

o в поле Аутентификация укажите IP-адрес и порт, на котором RADIUS-сервер будет

принимать пакеты Access-Request.

o в поле Учет укажите IP-адрес и порт, на котором RADIUS-сервер будет принимать пакеты

Accounting-Request.

В секции Локальные адреса:

o в поле Локальный адрес:порт для аутентификации укажите IP-адрес сервера, на котором

установлен компонент «Абонентская логика» и порт, с которого Система будет отправлять

пакеты Access-Request на RADIUS и на котором будет принимать ответные сообщения.

o в поле Локальный адрес:порт для учета укажите IP-адрес сервера, на котором установлена

логика «ОС» данного домена и порт, с которого Система будет отправлять пакеты

Accounting-Request на RADIUS и на котором будет принимать ответные сообщения.

В секции Параметры передачи RADIUS-пакетов отметьте флажки Отправлять ID вызываемого

абонента и Отправлять ID вызывающего абонента.

170 |

10.3

Аутентификация при регистрации

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

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

На странице Базовая конфигурация → RADIUS отметьте флажок Аутентификация при

регистрации.

В настройках учетной записи абонента или шлюза отметьте флажок RADIUS-аутентификация

[абонента] при регистрации.

При попытке регистрации терминалов данных учетных записей на RADIUS-сервер отправляется запрос

с аутентификационными данными, в которых в качестве атрибута User-Name используется значение

из поля Имя при авторизации, а в качестве атрибута User-Password используется значение поля

Пароль в панели Авторизационные данные для RADIUS (в настройках учетной записи абонента или

шлюза), либо пароль из самого регистрационного запроса, если поле Пароль не заполнено. После

успешного ответа (Access-Accept) со стороны RADIUS-сервера регистрация подтверждается.

См. также Дайджест-аутентификация (Digest authentication).

10.4

Авторизация вызовов на абонентов

Для настройки авторизации вызовов на абонентов домена, вне зависимости от инициатора вызова,

выполните следующие действия:

На странице Базовая конфигурация → RADIUS отметьте флажок Авторизация при вызове.

На странице сервиса «Звонки на внутренние номера» отметьте флажок RADIUS-авторизация

маршрута.

При вызове абонента домена на RADIUS-сервер отправляется запрос на авторизацию доступа Access-

Request.

При успешной авторизации (Access-Accept) соединение с вызываемой стороной может быть

установлено.

10.5 Учет вызовов на абонентов

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

следующие действия:

На странице Базовая конфигурация → RADIUS отметьте флажок Отправлять пакеты учета.

На странице сервиса «Звонки на внутренние номера» отметьте флажок Учет через RADIUS

сервер.

Когда вызываемый абонент домена отвечает на вызов, на RADIUS-сервер отправляется запрос

Accounting-Request, в котором передается атрибут Acct-Status-Type со значением Start.

По окончании вызова на RADIUS-сервер отправляется запрос Accounting-Request, в котором

передается атрибут Acct-Status-Type со значением Stop.

10.6 Авторизация вызовов на сервисы

Для настройки авторизации вызовов на сервисы, вне зависимости от инициатора вызова, выполните

следующие действия:

На странице Базовая конфигурация → RADIUS отметьте флажок Авторизация при вызове.

Взаимодействие с RADIUS-сервером | 171

На странице необходимого сервиса в разделе Общие настройки отметьте флажок RADIUS-

авторизация вызовов на сервис.

При вызове сервиса на RADIUS-сервер отправляется запрос на авторизацию доступа Access-Request.

При успешной авторизации (Access-Accept), соединение с сервисом может быть установлено.

10.7

Учет вызовов на сервисы

Для настройки учета вызовов на сервисы, вне зависимости от инициатора вызова, выполните

следующие действия:

На странице Базовая конфигурация → RADIUS отметьте флажок Отправлять пакеты учета.

На странице необходимого системного сервиса в разделе Общие настройки отметьте флажок

Учет вызовов на сервис через RADIUS-сервер.

Когда вызов поступает на сервис, на RADIUS-сервер отправляется запрос Accounting-Request, в

котором передается атрибут Acct-Status-Type со значением Start.

По окончании вызова на RADIUS-сервер отправляется запрос Accounting-Request, в котором

передается атрибут Acct-Status-Type со значением Stop.

10.8

Авторизация вызовов на шлюз

Для настройки авторизации вызовов на шлюз, вне зависимости от инициатора вызова, выполните

следующие действия:

На странице Базовая конфигурация → RADIUS отметьте флажок Авторизация при вызове.

На странице Маршрутизация → Маршруты в настройках маршрута, ведущего на необходимый

шлюз, отметьте флажок RADIUS-авторизация маршрута.

При вызове на шлюз на RADIUS-сервер отправляется запрос на авторизацию доступа (Access-Request)

к маршруту, ведущему на данный шлюз.

При успешной авторизации (Access-Accept), соединение со шлюзом может быть установлено.

10.9

Учет вызовов на шлюз

Для настройки учета вызовов на шлюз, вне зависимости от инициатора вызова, выполните следующие

действия:

На странице Базовая конфигурация → RADIUS отметьте флажок Отправлять пакеты учета.

На странице Маршрутизация → Маршруты в настройках маршрута, ведущего на необходимый

шлюз, отметьте флажок Учет через RADIUS-сервер.

Когда вызов поступает на шлюз, на RADIUS-сервер отправляется запрос Accounting-Request, в

котором передается атрибут Acct-Status-Type со значением Start.

По окончании вызова на RADIUS-сервер отправляется запрос Accounting-Request, в котором

передается атрибут Acct-Status-Type со значением Stop.

10.10

Учет исходящих вызовов абонентов и шлюзов

Для настройки учета любых исходящих вызовов абонента или шлюза, вне зависимости от направления,

выполните следующие действия:

На странице Базовая конфигурация → RADIUS отметьте флажок Отправлять пакеты учета.

172 |

В настройках учетной записи необходимого абонента или шлюза в разделе Настройки RADIUS

отметьте флажок Учет через RADIUS-сервер.

Когда поступает вызов с данного абонента или шлюза на любое направление, на RADIUS-сервер

отправляется запрос Accounting-Request, в котором передается атрибут Acct-Status-Type со значением

Start.

По окончании вызова на RADIUS-сервер отправляется запрос Accounting-Request, в котором

передается атрибут Acct-Status-Type со значением Stop.

10.11

Учет исходящих вызовов сервисов

Для таких системных сервисов как Системный IVR, Очередь вызовов, Карточная платформа, Прямой

внутрисистемный доступ, Обратный вызов, Служба массового обзвона возможна настройка

взаимодействия с RADIUS-сервером для исходящих вызовов сервиса. Для учета вызовов, совершаемых

сервисом, через RADIUS-сервер выполните следующие действия:

На странице Базовая конфигурация → RADIUS отметьте флажок Отправлять пакеты учета.

В настройках сервиса в разделе Настройки RADIUS для исходящих вызовов отметьте флажок

Учет через RADIUS-сервер.

Когда поступает вызов с данного сервиса на любое направление, на RADIUS-сервер отправляется

запрос Accounting-Request, в котором передается атрибут Acct-Status-Type со значением Start.

По окончании вызова на RADIUS-сервер отправляется запрос Accounting-Request, в котором

передается атрибут Acct-Status-Type со значением Stop.

10.12

Основные RADIUS-атрибуты пакетов авторизации и

учёта вызовов

В пакетах авторизации содержится информация для определения возможности совершения вызова. В

состав пакетов учета входят данные, описывающие созданный участок вызова.

Все атр ибу ты в сообщениях Access-Accep t, Access-Rej ect, Access-Challenge и Accounting-Resp onse от

RADIUS-сервера должны присылаться в формате VSA key=value, например, h323-redirect-

number=2141101.

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

атрибут User-Name. По нему RADIUS-сервер должен определить, разрешено ли конкретному

пользователю системы осуществлять вызов с заданными в пакете авторизации атрибутами. После

получения данных учёта вызова именно с этой учетной записи происходит списание средств за услуги

связи.

Для указания номера вызывающего абонента используется атрибут Calling-Station-Id. Данный атрибут

всегда отображает вызывающий номер вне зависимости от типа используемого ДВО.

Для указания номера вызываемого абонента используется атрибут Called-Station-Id.

Для указания номера, с которого происходит переадресация, на RADIUS-сервер в составе пакетов

отсылается атрибут h323-redirect-number. В случае, когда пакет содержит атрибут h323-redirect-

number, эффективный номер равен номеру, заданному в этом атрибуте; в остальных случаях он равен

номеру, указанному в Calling-Station-Id.

Эффективный номер - это номер абонента, который владеет вызовом и должен его оплачивать. С

учетом этого номера система учёта и начисления платы выполняет учёт вызова.

Взаимодействие с RADIUS-сервером | 173

Для того чтобы RADIUS-сервер мог определить, к какому сеансу учёта вызова относится конкретная

процедура авторизации, все отправляемые пакеты содержат атрибут h323-conf-id с одинаковым

значением.

При прохождении нескольких вызовов через РТУ, для того чтобы RADIUS-сервер мог определить, что

вызовы являются частью одного сеанса, во всех пакетах отсылается атрибут h323-incoming-conf-id с

одинаковым значением.

Для связи авторизационных пакетов с участком вызова, запрашивающим авторизацию, в

авторизационных пакетах и в пакетах учета вызова отсылается атрибут h323-call-id, содержащий

уникальный идентификатор этого участка вызова.

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

дополнительные атрибуты: xpgk-src-number-in, xpgk-dst-number-in, xpgk-src-number-out, xpgk-dst-

number-out.

В пакетах AccountingStop сеансов учета вызовов содержатся дополнительные атрибуты, описывающие

участок вызова, к которому относится данный сеанс:

h323-call-id - идентификатор вызова.

h323-call-origin - указывает, был ли участок вызова создан системой (значение - originate) или

принят извне (значение answer).

h323-remote-address - адрес, куда был направлен участок вызова.

h323-gw-address - адрес, откуда исходил участок вызова.

h323-setup-time, h323-connect-time, h323-disconnect-time - время создания, соединения и

завершения участка вызова.

acct-output-packets - количество пакетов и байт, переданных на участке вызова.

acct-input-packets - количество пакетов и байт, принятых на участке вызова.

h323-disconnect-cause - причина разъединения участка вызова.

10.13

Авторизация и учет при использовании базовых

сервисов

Пер еадр есация вызова

Сценарий: абонент А вызывает абонента Б, у абонента Б срабатывает переадресация на абонента В.

В данном случае необходимо авторизовать возможность дозвона абонента А до Б и абонента Б до В; на

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

отличается от авторизации обычного вызова наличием атрибута h323-redirect-number со значением,

равным номеру абонента Б, при этом атрибут Calling-Station-Id содержит номер абонента А.

При выполнении данного сценария создаётся два участка вызова: от абонента А и до абонента В.

Данные участки будут различаться тем, что при формировании пакетов учета участка вызова до

абонента В в качестве пользователя системы в атрибут User-name вносится абонент Б, а в качестве

Called-Station-Id вносится номер абонента В. Также пакет содержит атрибут h323-redirect-number, в

который вносится номер абонента Б.

Исключение: данный алгоритм не учитывается при переадресации вызова из ДВО

«Прямой

внутрисистемный доступ» и

«Групповой вызов». В этом случае авторизация выполняется с

авторизационными данными шлюза, представляющего экземпляр сервиса.

Пер евод вызова

174 |

Сценарий: абонент А вызывает абонента Б, Б дозванивается до абонента В, Б кладет трубку. Между

абонентами А и В устанавливается соединение.

В данном случае необходимо авторизовать дозвон от абонента А до Б и от абонента Б до В. При этом

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

от абонента Б до В в авторизационном пакете атрибут xpgk-service-type содержит значение

«CallTransfer».

При данном сценарии выполняется три сеанса учёта вызовов: участок вызова от абонента А, участок

вызова до абонента Б, участок вызова до абонента В. В данных последнего сеанса учета атрибут xpgk-

service-type содержит значение «CallTransfer». При этом сеанс учета по участку вызова до абонента Б

закончится ранее, чем остальные сеансы.

Конференция

Сценарий: абонент А вызывает абонента Б, абонент Б дозванивается до В, Б объединяет всех в

конференцию.

В данном случае всё аналогично сценарию с переводом вызова, за исключением того, что окончание

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

10.14 Авторизация и учет при использовании сложных

сервисов

Cложные сервисы выполняются на сервисной платформе. Для этого при каждом включении такого

сервиса инициируется вызов на сервисную платформу. Поэтому все сложные сервисы представляют

собой набор вызовов, где в качестве инициирующего и терминирующего устройства выступает

сервисная платформа.

Услу га «Следу й за мной»

Сценарий: абонент А вызывает абонента Б, у абонента Б с помощью ДВО «Следуй за мной» настроена

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

В схеме работы услуги «Следуй за мной» выполняется один вызов на сервисную платформу и

несколько вызовов с сервисной платформы. Соответственно, учет вызовов будет отражать и участки

вызова на сервисную платформу.

Взаимодействие с RADIUS-сервером | 175

В данном случае будет осуществлено две процедуры авторизации: вызова от абонента А до абонента Б,

вызова от абонента Б до В. Процесс авторизации вызова от абонента А до Б не будет отличаться от

процесса авторизации обычного вызова. Авторизация вызова с сервисной платформы до абонента В

аналогична авторизации вызова от абонента Б до В, за исключением того, что данные вызова будут

содержать атрибут h323-redirect-number со значением, равным номеру абонента Б, а в атрибуте

Calling-Station-Id будет указано значение номера абонента А.

Для целей учёта вызов будет разделён на четыре сеанса:

Первый сеанс типа «answer», указывающий, что абонент А вызывает абонента Б.

CallingStationId=A

CalledStationId=Б

xpkg-service-type =Call

Второй сеанс типа «originate», указывающий, что вызов передан на обработку ДВО «Следуй за

мной».

CallingStationId=А

176 |

CalledStationId=Номер услуги «Следуй за мной»

В атрибуте xpkg-service-type возможно указать любое значение, указанное на шлюзе к услуге.

Третий сеанс типа «answer», указывающий, что выполняется дозвон от услуги «Следуй за мной» до

абонента В.

CallingStationId=А

CalledStationId=В

h323-redirect-number=Б

xpkg-service-type =Call

Четвертый сеанс типа «originate», указывающий, что происходит дозвон от услуги «Следуй за мной»

до абонента В.

CallingStationId=А

CalledStationId=В

h323-redirect-number=Б

xpkg-service-type =Call

Таким образом, при использовании услуги «Следуй за мной» система учёта и начисления платы

получает информацию для авторизации вызова на каждом направлении и может вести учет всех

создаваемых участков вызова: как участков вызова до конкретного терминирующего оборудования,

так и участков вызова до услуги.

Сер вис «Пр ямой вну тр исистемный досту п»

Сценарий: абонент А вызывает экземпляр сервиса «Прямой внутрисистемный доступ»; с сервиса

осуществляется дозвон на номер Б.

В данном случае будет осуществлено две процедуры авторизации: вызова от абонента А до экземпляра

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

«Прямой внутрисистемный доступ» выполняется переадресация вызова, во второй сессии (то есть

вызов от экземпляра сервиса до абонента Б) в атрибуте h323-redirect-number будет указываться

идентификатор экземпляра сервиса (поле Идентификатор сервиса).

Услу ги «Вир ту альный факс», «Вир ту альная конфер енц-комната», «Установка пар аметр ов

бу дильника», «Установка пар аметр ов пер еадр есации», «Установка пар аметр ов быстр ого

набор а»

При использовании данных услуг формирование RADIUS-пакетов осуществляется как для обычного

вызова до сервиса. При работе услуги «Виртуальная конференц-комната» в случае приглашения

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

имени которого выполняется дозвон.

Услу га «Отпр авить факс чер ез веб-интер фейс»

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

Принцип формирования RADIUS-пакетов аналогичен обычному вызову. Атрибут h323-redirect-

number не заполняется.

Взаимодействие с RADIUS-сервером | 177

Услу ги «Автодозвон» и «Повтор набор а номер а»

Сценарий: абонент А вызывает абонента Б; на номере абонента Б настроена услуга «Автодозвон»; с

данного сервиса осуществляется дозвон на номер В.

Принцип формирования RADIUS-пакетов при работе данных услуг аналогичен сервису «Прямой

внутрисистемный доступ».

Услу га «Автодозвон с обр атным вызовом»

Сценарий: абонент А вызывает абонента Б; на номере абонента Б настроена услуга «Автодозвон»;

данная услуга осуществляет дозвон сначала на номер абонента В, затем на номер абонента А.

Учёт вызова состоит из шести сеансов:

Первый сеанс типа «answer», указывающий, что абонент А вызывает абонента Б.

CallingStationId=A

CalledStationId=Б

xpkg-service-type =Call

Второй сеанс типа «originate», указывающий, что вызов передается на обработку услуги.

CallingStationId=А

CalledStationId=Номер ДВО «Автодозвон с обратным вызовом»

В атрибуте xpkg-service-type возможно внести любое значение, указанное на шлюзе к услуге.

Третий сеанс типа «answer», указывающий, что выполняется дозвон с услуги до абонента В.

CallingStationId=А

CalledStationId=В

h323-redirect-number=Б

xpkg-service-type =Call

Четвертый сеанс типа «originate», указывающий, что выполняется дозвон с услуги до абонента В.

CallingStationId=А

CalledStationId=В

h323-redirect-number=Б

xpkg-service-type =Call

Пятый сеанс типа «answer», указывающий, что выполняется дозвон с услуги до абонента А.

CallingStationId=A

CalledStationId=А

h323-redirect-number=Б

xpkg-service-type =Call

Шестой сеанс типа «originate», указывающий, что выполняется дозвон с услуги до абонента А.

CallingStationId=А

CalledStationId=А

178 |

h323-redirect-number=Б

xpkg-service-type =Call

Услу га «Обр атный вызов»

Сценарий: абонент А набирает номер услуги «Обратный вызов». Экземпляр сервиса осуществляет

обратный вызов с правами абонента А. Абонент А набирает номер абонента Б, после чего происходит

вызов абонента Б с правами абонента А.

Учёт вызова состоит из шести сеансов:

Первый сеанс типа «answer», указывающий, что абонент А вызывает номер Б.

Названия атрибутов и соответствующие им значения аналогичны услуге «Автодозвон с обратным

вызовом».

Второй сеанс типа «originate», указывающий, что вызов передается на обработку услуги. Названия

атрибутов и соответствующие им значения аналогичны услуге «Автодозвон с обратным вызовом».

Третий сеанс типа «answer», указывающий, что выполняется дозвон с услуги на номер абонента А.

CallingStationId=А

CalledStationId=А

h323-redirect-number=Б

xpkg-service-type =Call

Четвертый сеанс типа «originate», указывающий, что выполняется дозвон с услуги на номер абонента

А.

CallingStationId=А

CalledStationId=А

h323-redirect-number=Б

xpkg-service-type =Call

Пятый сеанс типа «answer», указывающий, что выполняется дозвон с услуги на номер абонента В с

правами абонента Д.

CallingStationId=Д

CalledStationId=В

h323-redirect-number=Б

xpkg-service-type =Call

Шестой сеанс типа «originate», указывающий, что выполняется дозвон с услуги на номер абонента В

с правами абонента Д.

CallingStationId=Д

CalledStationId=В

h323-redirect-number=Б

xpkg-service-type =Call

Услу га «Д осту п с пр авами у четной записи»

Взаимодействие с RADIUS-сервером | 179

Сценарий: абонент А вызывает абонента Б; на номере абонента Б настроена услуга «Доступ с правами

учетной записи»; с услуги осуществляется вызов номера абонента В (с правами абонента Д).

Учёт вызова состоит из четырех сеансов:

Первый сеанс типа «answer», указывающий, что абонент А вызывает абонента Б.

Названия атрибутов и соответствующие им значения аналогичны услуге «Автодозвон с обратным

вызовом».

Второй сеанс типа «originate», указывающий, что вызов передается на обработку услуги. Названия

атрибутов и соответствующие им значения аналогичны услуге «Автодозвон с обратным вызовом».

Третий сеанс типа «answer», указывающий, что выполняется вызов с услуги абонента В с правами

абонента Д.

CallingStationId=Д

CalledStationId=В

h323-redirect-number=Б

xpkg-service-type =Call

Четвертый сеанс типа «originate», указывающий, что выполняется вызов абонента В с правами

абонента Д с услуги.

CallingStationId=Д

CalledStationId=В

h323-redirect-number=Б

xpkg-service-type =Call

180 |

Дайджест-аутентификация (Digest

authentication)

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

РТУ МОА поддерживает следующие типы дайджест-аутентификации:

согласно draft-sterman-aaa-sip-01 или draft-sterman-aaa-sip-00,

согласно RFC 4590.

Для аутентификации по draft-sterman-aaa-sip-01 и draft-sterman-aaa-sip-00 выполните следующие

действия:

1. В конфигурационном файле etc/mvts3g/system-1.signaling.conf в секции sip для

параметра external_authorization задать значение no.

2. В разделе Базовая конфигурация → RADIUS отметьте флажки Аутентификация при регистрации

и Цифровая аутентификация и в раскрывающемся списке выберите Draft Sterman 00 или Draft

Sterman 01.

3. В учетной записи абонента в панели Настройки RADIUS отметьте флажок RADIUS-

аутентификация абонента при регистрации.

Аутентификация будет осуществляться следующим образом:

1. Пользователь присылает на модуль управления вызовами запрос на регистрацию SIP REGISTER

без авторизационных данных.

2. В ответ на запрос модуль управления вызовами высылает пользователю пакет SIP 401, в котором

передает так называемый “nonce” - псевдослучайное число, заново генерируемое для каждого

соединения.

3. Пользователь на основе “nonce” и своих авторизационных данных генерирует MD5-хэш (Digest-

Response), который вместе с параметрами, использованными для его генерации, передается в

ответном пакете REGISTER.

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

(логики ОС).

5. Модуль абонентской логики ищет домен (подробнее см. раздел «Определение доменов» в

документе [5]), учетную запись абонента (по номеру, с которого поступил запрос), терминал

абонента (по логину в настройках терминала абонента).

6. Модуль абонентской логики должен сгенерировать идентичный MD5-хэш с использованием

полученных данных и пароля найденного терминала. Если сгенерированный хэш совпадет с

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

7. При удачной аутентификации на RADIUS-сервер отправляется сообщение запроса доступа

Access-Request.

8. После успешного ответа

(Access-Accept) со стороны RADIUS-сервера регистрация

подтверждается.

Для аутентификации по RFC 4590 выполните следующие действия:

1. В конфигурационном файле etc/mvts3g/system-1.signaling.conf в секции sip для

параметра external_authorization задать значение yes.

2. В разделе Базовая конфигурация → RADIUS отметьте флажок Аутентификация при регистрации

и Цифровая аутентификация и в раскрывающемся списке выберите RFC4590.

3. В учетной записи абонента в панели Настройки RADIUS отметьте флажок RADIUS-

аутентификация абонента при регистрации.

Аутентификация будет осуществляться следующим образом:

Дайджест-аутентификация (Digest authentication) | 181

1. Пользователь присылает на модуль управления вызовами запрос на регистрацию SIP REGISTER

без авторизационных данных.

2. Модуль управления вызовами отправляет запрос на модуль абонентской логики.

3. Модуль абонентской логики ищет домен, учетную запись абонента (по номеру, с которого

поступил запрос), терминал абонента (по логину в настройках терминала абонента).

4. На RADIUS-сервер отправляется сообщение запроса доступа Access-Request.

5. RADIUS-сервер генерирует “nonce” и высылает его в ответном сообщении Access-Challenge.

6. Модуль абонентской логики отправляет сообщение с “nonce” на модуль управления вызовами.

7. Модуль управления вызовами высылает оборудованию пользователя пакет SIP 401, в котором

передает “nonce”.

8. Пользователь на основе “nonce” и своих авторизационных данных генерирует MD5-хэш (Digest-

Response), который вместе с параметрами, использованными для его генерации, передается в

ответном сообщении.

9. Модуль абонентской логики переправляет запрос Access-Request на RADIUS-сервер.

10. RADIUS-сервер должен сгенерировать идентичный MD5-хэш с использованием полученных

данных и пароля данного пользователя.

11. Если сгенерированный хэш совпадет с данными, переданными оборудованием пользователя,

аутентификация считается успешной, RADIUS-сервер высылает Access-Accept.

182 |

Особенности вызова абонента, находящегося

за транковым шлюзом

Обработка вызовов, направляемых на абонента, находящегося за транковым шлюзом (т.е. за внешним

шлюзом или шлюзом перехода в РТУ МТТ), зависит от регистрации абонентского устройства

(терминала). Если терминал абонента зарегистрирован, вызов отправляется на номер абонента,

указанный в поле Номер абонента в разделе Общие настройки учетной записи абонента. Если терминал

абонента не зарегистрирован, вызов отправляется на транковый шлюз на номер, указанный в

параметре Внешний номер в настройках терминала. Рассмотрим данную ситуацию на конкретных

примерах.

1. Допустим, абонент имеет номер 1234 и терминал со следующими настройками:

Тип терминала: С регистрацией,

За шлюзом: выбрать необходимый транковый шлюз, например ExternalGW,

Внешний номер: указать номер терминала абонента, например 9876, который подставляется

вместо номера 1234, если вызов проходит через транковый шлюз.

При данных настройках сценарий обработки вызовов будет следующий:

Если терминал абонента зарегистрирован, вызов будет направляться на номер 1234.

Если терминал абонента разрегистрировался (например, истекло время жизни регистрации,

заданное в параметре TTL), вызов уйдет на шлюз ExternalGW на номер 9876, а вызов со шлюза

ExternalGW с номера 9876 поступит с А-номером 1234 и правами абонента 1234.

2. Допустим, абонент имеет номер 1234 и терминал со следующими настройками:

Тип терминала: Без регистрации,

За шлюзом: выбрать необходимый транковый шлюз, например ExternalGW,

Внешний номер: указать номер терминала абонента, например 9876, который подставляется

вместо номера 1234, если вызов проходит через транковый шлюз.

При данных настройках вызовы на номер 1234 будут уходить на шлюз ExternalGW на номер 9876, а

вызовы со шлюза ExternalGW с номера 9876 будут поступать с А-номером 1234 и правами абонента

1234.

Внешняя регистрация шлюза | 183

13 Внешняя регистрация шлюза

В рамках РТУ МОА возможны следующие ситуации, когда требуется настройка внешней регистрации

шлюза.

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

Если необходимо подключить определенный номер

(например,

8312470000) у оператора,

использующего SIP-регистрацию, на странице Шлюзы создайте учетную запись шлюза и настройте

Внешнюю регистрацию:

Отметьте флажок Регистрация на регистраторе,

В поле Имя сервера укажите полное доменное имя внешнего регистратора или его IP-адрес,

который должен использоваться для формирования доменной части SIP-URI в запросах на

регистрацию и вызовах.

В поле Регистр. имя задайте необходимый номер, выделенный оператором (в нашем примере

8312470000).

В раскрывающемся списке А-номер при исходящих вызовах выберите Использовать номер

регистрации.

В поле Пароль задайте пароль для запросов на регистрацию.

В поле Порт задайте порт, используемый на внешнем регистраторе для SIP-запросов, например

5060.

После получения со стороны внешнего регистратора подтверждения того, что регистрация успешно

прошла, все последующие вызовы от данного оператора, направленные на номер, указанный в поле

Регистр. имя, будут поступать в РТУ от имени учетной записи данного шлюза.

Для обработки вызовов, поступающих на указанный номер оператора

(8312470000), возможно

использование нескольких вариантов настройки:

Настроить попадание таких вызовов на сервис, например «Прямой внутрисистемный доступ»

или «Очередь вызовов», создав в разделе Преобразование номеров правило преобразования

входящих Б-номеров в необходимый номер сервиса или выбрав группу алиасов в

раскрывающемся списке Группа алиасов внутренней нумерации (подробнее см. пример 3 в

разделе Организация плана нумерации).

184 |

Если необходимо, чтобы вызов попадал на номер определенного абонента домена, в разделе

Преобразование номеров настройте преобразование входящего Б-номера во внутренний номер

абонента.

Если необходимо настроить маршрутизацию в зависимости от инициатора вызова, в разделе

Преобразование номеров:

o в поле Совпадение по А-номеру укажите необходимый номер инициатора вызова,

o в поле Номер выберите Б-номер входящий.

o с помощью полей Замена и Результат настройте преобразование номера шлюза (в нашем

примере 8312470000) в необходимый внутренний номер.

Для того чтобы предоставить абонентам возможность совершать вызовы на номера данного оператора

с подключенного номера

(8312470000) в качестве А-номера, необходимо создать маршрут на

вышеописанный шлюз и настроить следующие параметры:

В поле Команда выберите вызвать шлюз, в поле Аргумент выберите имя созданной учетной

записи шлюза,

в поле Совпадение Б-номера задайте шаблон номеров оператора, на которые возможно будет

совершить вызов, например ^8312[0-9]{6}$.

в разделе Группы укажите группу, в которую должны входить абоненты, чтобы иметь

возможность звонить на номера данного оператора.

II. Настройка внешней регистрации для преодоления NAT или для работы с динамическим IP-

адресом

Предположим, необходимо настроить сопряжение с внешней станцией таким образом, чтобы А-

номера при вызовах на данную станцию передавались прозрачно, при этом ваша станция имеет

динамический IP-адрес или же находится за NAT.

Для того, чтобы внешней станции были известны реальные IP-адрес и порт вашей станции или адрес и

порт в NAT, необходимо на странице Шлюзы создать учетную запись шлюза и настроить Внешнюю

регистрацию:

Отметьте флажок Регистрация на регистраторе,

В поле Имя сервера укажите полное доменное имя внешнего регистратора или его IP-адрес,

который должен использоваться для формирования доменной части SIP-URI в запросах на

регистрацию и вызовах.

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

формирования номерной части SIP-URI в запросах на регистрацию и вызовах.

В раскрывающемся списке А-номер при исходящих вызовах выберите Передавать прозрачно.

В поле Пароль задайте пароль для запросов на регистрацию.

В поле Порт задайте порт, используемый на внешнем регистраторе для SIP-запросов, например

5060.

186 |

14 Принципы управления медиасоединениями

Используя параметры Политика передачи изменений в кодеках, Политика проксирования и

Переключение на G.711 (в настройках терминала учетной записи абонента/ шлюза), установить

соединение для абонента станции можно при любом сочетании кодеков, а при наличии у инициатора

вызова и вызываемой стороны общего кодека конвертацию можно исключить.

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

списка кодеков из одного участка вызова в другой. Раскрывающийся список имеет следующие

значения:

Передавать изменения типа медиаданных,

Адаптивный режим с ограничением,

Адаптивный режим с расширением,

Передавать все изменения.

При выборе значения данного параметра следует учитывать следующие типовые ситуации:

1. Высока вероятность несовпадения набора кодеков у оборудования собеседников, однако вызов

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

необходимо использовать Адаптивный режим с расширением (рекомендуется).

2. Набор кодеков оборудования собеседников частично совпадает. Вызов должен состояться, однако

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

Адаптивный режим с ограничением.

3. Оборудование собеседников имеет одинаковый набор кодеков. Необходимо избежать конвертации.

В случае несовпадения кодеков вызов будет отклонен. В данном случае необходимо использовать

вариант Передавать все изменения.

4. Оборудование собеседников на этапе согласования меняет медиапараметры кодеков, даже если

оборудование собеседников имеет одинаковый набор кодеков. Максимальная вероятность

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

медиаданных.

Параметр Переключение на G.711 определяет поведение системы при переключении канала на кодек

G.711, т.е. как станция будет интерпретировать попытку оборудования переключиться на этот кодек: как

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

следующие значения:

Как факс

Как голос

Принципы управления медиасоединениями | 187

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

Раскрывающийся список содержит следующие значения:

Проксировать (включается режим полного проксирования, т.е. пропуска через РТУ МОА

медиапотоков

(при создании участков вызова медиапотоки создаются на модулях

проксирования медиа));

Прямое медиасоединение после CONNECT (после соединения по входящему участку вызова

возможно изменить кодек на этом участке

(при соединении участков вызова

(после

установления соединения) система прекращает проксировать медиапотоки и переключается на

прямое медиасоединение);

Прямое медиасоединение (Система не проксирует медиапотоки).

14.1 Настройка транскодинга в РТУ МОА

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

и эксплуатацию серверного оборудования, используемого для Системы. Кроме того, уменьшение

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

системы.

Настройка типовых сценариев.

1. Трафик проксируется. Конвертация не выполняется, если состав кодеков у оборудования одинаков

(есть совпадения) и не имеется различий в приоритете.

Название параметра

Значение параметра

Настройки инициирующего устройства

Политика проксирования

Проксировать

Использовать только один кодек

Нет

Настройки терминирующего устройства

Политика проксирования

Проксировать

Использовать только один кодек

Нет

2. Трафик проксируется. Конвертация выполняется, если состав кодеков у оборудования одинаков (есть

совпадения) и имеются различия в приоритете.

Название параметра

Значение параметра

Настройки инициирующего устройства

Политика проксирования

Проксировать

188 |

Использовать только один кодек

Да

Настройки терминирующего устройства

Политика проксирования

Проксировать

Использовать только один кодек

Да

3. Трафик проксируется. Конвертация выполняется, если состав кодеков у оборудования разный (нет

совпадений).

Название параметра

Значение параметра

Настройки инициирующего устройства

Политика проксирования

Проксировать

Использовать только один кодек

Да/Нет

Настройки терминирующего устройства

Политика проксирования

Проксировать

Использовать только один кодек

Да/Нет

4. Трафик не проксируется ни при каких условиях.

Название параметра

Значение параметра

Настройки инициирующего устройства

Политика проксирования

Прямое медиасоединение

Настройки терминирующего устройства

Политика проксирования

Прямое медиасоединение

Изменение стилевого оформления интерфейса | 189

Изменение стилевого оформления интерфейса

Данный раздел предполагает наличие у читателя знания языка CSS

(Cascading Sty le Sheets) .

Подр обну ю инфор мацию о языке CSS можно найти здесь: W3C.

Изменение внешнего вида страниц веб-интерфейса осуществляется путем редактирования файлов

каскадных таблиц стилей, имеющих постфикс .css в названии файлов.

Файлы каскадных таблиц страниц, отображаемых администратору, находятся в

каталоге /var/www/web_admin/Styles. Каталог содержит файлы:

LoginPageStyle.css

- стилевое оформление страницы входной регистрации

администратора,

AdminPageStyle.css - стилевое оформление веб-интерфейса администратора.

UserPageStyle.css

- стилевое оформление интерфейса веб-кабинета абонента при

переходе с веб-интерфейса администратора.

Файлы каскадных таблиц стилей страниц, отображаемых абоненту, находятся в

каталоге /var/www/web_user/Styles. Каталог содержит файлы:

UserPageStyle.css - стилевое оформление интерфейса веб-кабинета абонента

LoginPageStyle.css - стилевое оформление страницы входной регистрации абонента.

При

этом

файлы

/var/www/web_admin/Styles/AdminPageStyle.css

/var/www/web_admin/Styles/UserPageStyle.css

/var/www/web_user/Styles/UserPageStyle.css содержат следующие классы CSS,

позволяющие менять стилевое оформление названий разделов в боковом меню интерфейса:

1. navigationTreeNode - все разделы в боковом меню. Задаваемые настройки могут

перекрываться нижеперечисленными классами.

2. navigationTreeLeafNode - конечные элементы, то есть разделы, не имеющие дочерних

разделов (подразделов).

3. navigationTreeParentNodРe - промежуточные элементы, то есть разделы, которые

одновременно являются дочерними по отношению к одним разделам и вышестоящими по

отношению к другим.

4. navigationTreeRootNode

- корневые элементы, то есть разделы, не имеющие

родительских разделов.

5. navigationTreeSelectedNode - выбранный элемент, то есть открытый в данный момент

раздел.

6. .navigationTreeNode:hover,

a.navigationTreeNode:hover, .navigationTreeNode:link:hover,

a.navigationTreeNode:link:hover - раздел, на который в данный момент наведен

курсор.

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

Ctrl+F5.

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

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

интерфейс путем изменения формата страниц. Данный раздел содержит лишь краткую инструкцию по

настройке внешнего вида страниц веб-интерфейса.

190 |

15.1 Настройка внешнего вида баннера

Для того чтобы изменить картинку баннера:

1) откройте соответствующий .css-файл с помощью любого текстового редактора,

2) измените содержимое функции url().

Пример:

До изменения:

.pageHeader .logo {width: 283px; height: 40px; float:left; background:

url(../AdminPageImages/pageHeader_logo.png) no-repeat left; margin-bottom:12px;

}

После изменения:

.pageHeader .logo {width: 283px; height: 40px; float:left; background:

url(../AdminPageImages/bbox_banner_backgnd.png) no-repeat left;

margin-bottom:12px; }

15.2 Настройка внешнего вида нижнего колонтитула

Чтобы изменить вид нижнего колонтитула, необходимо описать класс нижнего колонтитула в

соответствующем .css-файле.

Пример:

.pageFooter .container {background: #f5f5f5; text-align: center; padding: 10px

0;}

Можно изменять либо общий фон колонтитула на конкретный цвет, либо изменять фон на картинку.

Чтобы добавить картинку, необходимо изменить содержимое функции url():

.pageFooter .container {background:

url(../AdminPageImages/bbox_footer_backgnd.png); text-align: center; padding:

10px 0;}

Автонастройка оборудования | 191

Автонастройка оборудования

16.1

Установка и обновление пакета 'Автонастройка'

Автонастройка значительно упрощает администрирование и позволяет легко и быстро

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

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

TFTP-сервер, на котором хранятся конфигурационные файлы всех устройств сети, а также шаблоны

общих настроек, используемые всеми устройствами. При включении устройство получает свой

конфигурационный файл с TFTP-сервера, и его настройка происходит в соответствии с параметрами,

заданными в файле автоматически, а не вручную администратором.

Помимо прочего, механизм автонастройки позволяет при изменении параметров точек доступа (IP-

адресов и портов модулей сигнализации и балансировки нагрузки) осуществлять автоматическое

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

Модуль Auto Provisioning поставляется в пакете rtu-cl-aps. Вместе с пакетом rtu-cl-aps

устанавливается и настраивается TFTP сервер atftpd.

При установке пакета:

Создается каталог /var/lib/rtu-cl-aps, который содержит все конфигурационные файлы.

Соответствующим образом настраивается atftpd.

Запускается утилита ApsInit. Данная утилита предназначена для определения механизма

автонастройки в системе:

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

device.info.

перенос ШОН с жесткого диска в БД, используя данные из файла global.info.

При обновлении пакета:

· Запускается утилита ApsInit, которая:

сравнивает поочередно шаблоны в файле device.info и в БД. Если они различны, то

происходит замена и осуществляется перегенерация всех КФУ, основанных на измененном

шаблоне.

заменяет ШОН в БД, на указанные в global.info и осуществляет перегенерацию всех

КФУ в данном домене.

16.2

Конфигурационные файлы устройств

Работа механизма автонастройки

(Auto Provisioning) основана на существовании шаблонов

конфигурационных файлов (ШКФ) и получении на их основе конфигурационных файлов устройств

(КФУ) с конкретными параметрами конфигурации.

Шаблон конфигурационного файла

- это

«заготовка» файла, в которой реальные значения

конфигурационных параметров заменены так называемыми маркерами.

Маркер

- специальный набор символов, который в процессе автонастройки заменяется на

действительное значение параметра. Например, маркер GkOrProxy имеет вид %GkOrProxy% и в

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

Шаблоны делятся на системные и пользовательские. Системные шаблоны - это шаблоны, которые

поставляются вместе с модулем автонастройки. Системные шаблоны невозможно удалить или

изменить, записав измененный шаблон под тем же именем.

На каждую модель устройства и каждый поддерживаемый моделью устройства протокол сигнализации

имеется один системный шаблон.

192 |

Пользовательские шаблоны - это шаблоны устройств, которые администратор системы создает с нуля

или на основе одного из системных шаблонов.

Пользовательские шаблоны можно удалять и редактировать.

Существуют ШКФ для следующих моделей устройств:

1. Astra6757i,

2. CiscoATA186,

3. Linksys2102,

4. Default - для прочих устройств.

Кроме шаблонов конфигурационных файлов (ШКФ) с модулем автонастройки поставляются шаблоны

общих настроек (ШОН) для моделей устройств. ШОН предназначены для задания параметров, общих

для всех устройств конкретной модели.

В ШОН конкретные значения конфигурационных параметров также заменены маркерами, вместо

которых реальные данные подставляются в процессе автонастройки.

После замены в ШОН маркеров на реальные значения параметров полученная общая часть

конфигурации либо помещается в КФУ каждого из устройств данной модели, либо в отдельный файл

общих настроек (ФОН), если конфигурация устройства задается двумя файлами.

Системные ШКФ помещаются в БД APS в таблицу APSTemplate при установке пакета rtu-cl-aps.

Список системных ШКФ и информация о них находятся в файле

/usr/share/rtu-cl-

aps/device.info, который имеет следующую структуру:

Name:<название шаблона>

ModelName:<модель оборудования. Должно соответствовать имени подкаталога>

LineNumber:<количество линий устройства>

ConfigFilenameTemplate:<формат имени КФУ, например ata%MAC%>

Protocol:<протокол SIP|H323>

TemplateBody:<относительный путь к шаблону>

Структура подкаталогов /usr/share/rtu-cl-aps/<model_name> следующая:

./h323.cfg - ШКФ для устройств, работающих по протоколу Н.323;

./sip.cfg - ШКФ для устройств, работающих по протоколу SIP;

./tools - вспомогательные утилиты генерации КФУ;

./example - примеры конфигурационных файлов от производителя ПО.

ШОН помещаются в БД APS в таблицу APSGlobal при установке пакета rtu-cl-aps.

Список ШОН и информация о них находятся в файле /usr/share/rtu-cl-aps/global.info,

который имеет следующую структуру:

ModelName:<имя модели устройства>

ConfigFilename:<имя ШОН>

TemplateBody:<относительный путь к шаблону>

Генерация ШОН происходит при задании параметров точек входа в веб-интерфейсе.

Перегенерация ШОН осуществляется при:

при изменении параметров точки входа;

при обновлении пакета Auto Provisioning, если ШОН в пакете и в БД отличны друг от друга.

Шаблоны, созданные администратором, помещаются в БД, в таблицу APSTemplate.

Конфигурационные файлы устройств, полученные в результате замены маркеров в шаблонах

реальными значениями параметров, помещаются на локальный диск в каталог /var/lib/rtu-cl-

aps/<DOMAIN_NAME>. Исключение составляют КФУ устройств в домене ROOT, которые

размещаются в каталоге /var/lib/rtu-cl-aps.

Автонастройка оборудования | 193

Перегенерация КФУ происходит в следующих случаях:

при изменении параметров точки входа;

при изменении ШКФ, на основе которого был сгенерирован данный КФУ (в случае с

пользовательским ШКФ - при изменении шаблона через веб-интерфейс, а с системным - при

обновлении пакета);

при изменении значений конфигурационных параметров абонента, который соотнесен с

данным устройством;

при удалении учетной записи абонента, соотнесенного с данным устройством.

16.3

Поддержка доменов

Любое устройство создается в рамках домена. Системные шаблоны конфигурационных файлов

доступны во всех доменах, пользовательские шаблоны - только в том домене, в котором они были

созданы.

Каждый домен может иметь свои точки входа. Точка входа - это параметры подключения к модулям

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

(балансировки нагрузки), которые передаются

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

устройства.

При изменении данных параметров происходит автоматическое обновление всех КФУ и КФМУ в

данном домене.

После создания КФУ и ФОН помещаются на диск в каталог

/var/lib/rtu-cl-

aps/<DOMAIN_NAME>/. Исключение сделано для КФУ, созданных в домене ROOT. КФ устройств

домена ROOT помещаются в каталог /var/lib/rtu-cl-aps/.

Таким образом, для домена, отличного от домена ROOT, в настройках оборудования необходимо

указывать URI по типу tftp://192.168.128.248/<DOMAIN_NAME>/.

16.4

Утилита синхронизации

Утилита синхронизации осуществляет синхронизацию конфигурационных файлов, сгенерированных в

соответствии с шаблонами и настройками абонента. Утилита запускается при установке пакета rtu-

cl-aps.

Вручную утилита может быть запущена командой:

/etc/init.d/rtu-cl-aps start

194 |

Протоколирование компонентов МОА

В данном разделе приводится следующая информация:

пути к журналам управляющих логик.

пути к журналам подсистемы веб-интерфейса.

инструкция по поиску отладочной информации.

настройке автоматического отключения протоколирования компонентов МОА.

17.1

Журналы управляющих логик МОА

Журналы модулей логики

«ОС», логики

«ДВО» и сервера обработки данных хранятся в

каталогах /var/log/mvts3g/rtu-cl-common и /var/log/mvts3g/rtu-cl-common/profile.

Префиксы журналов задаются для каждого модуля в файле /etc/mvts3g/phoenix.conf в параметре

log_pref. Если префикс не задан, вместо него используется название модуля (значение параметра

name). Пример:

Тип журнала

Значение log_pref

Журналы

Журналы основного

sl-1-logic

/var/log/mvts3g/rtu-cl-common/sl-1-logic.log

модуля логики «ОС»

/var/log/mvts3g/rtu-cl-common/sl-1-logic.error.log

/var/log/mvts3g/rtu-cl-common/profile/sl-1-

logic.profiler.txt

/var/log/mvts3g/rtu-cl-common/profile/sl-1-

logic.memory.profiler.txt

/var/log/mvts3g/rtu-cl-common/profile/sl-1-

logic.freememory.profiler.txt

Журналы модуля

sl-1

/var/log/mvts3g/rtu-cl-common/sl-1.log

сопряжения Логики

/var/log/mvts3g/rtu-cl-common/sl-1.error.log

«ОС» с Подсистемой

/var/log/mvts3g/rtu-cl-common/profile/sl-

Коммутации

1.interlayer.profiler.txt

(Interlayer)

/var/log/mvts3g/rtu-cl-common/profile/sl-

1.interlayer.memory.profiler.txt

/var/log/mvts3g/rtu-cl-common/profile/sl-

1.interlayer.freememory.profiler.txt

Журналы модуля

sl-1-license

/var/log/mvts3g/rtu-cl-common/sl-1-license.log

лицензирования

/var/log/mvts3g/rtu-cl-common/sl-1-license.error.log

Логики «ОС»

Журналы основного

sp-1-logic

/var/log/mvts3g/rtu-cl-common/sp-1-logic.log

модуля логики «ДВО»

/var/log/mvts3g/rtu-cl-common/sp-1-logic.error.log

/var/log/mvts3g/rtu-cl-common/profile/sp-1-

logic.profiler.txt*

/var/log/mvts3g/rtu-cl-common/profile/sp-1-

logic.memory.profiler.txt

/var/log/mvts3g/rtu-cl-common/profile/sp-1-

logic.freememory.profiler.txt

Журналы модуля

sp-1

/var/log/mvts3g/rtu-cl-common/sp-1.log

сопряжения Логики

/var/log/mvts3g/rtu-cl-common/sp-1.error.log

«ДВО» с

Протоколирование компонентов МОА | 195

Подсистемой

/var/log/mvts3g/rtu-cl-common/profile/sp-

Коммутации

1.interlayer.profiler.txt

(Interlayer)

/var/log/mvts3g/rtu-cl-common/profile/sp-

1.interlayer.memory.profiler.txt

/var/log/mvts3g/rtu-cl-common/profile/sp-

1.interlayer.freememory.profiler.txt

Журналы модуля

sp-1-license

/var/log/mvts3g/rtu-cl-common/sp-1-license.log

лицензирования

/var/log/mvts3g/rtu-cl-common/sp-1-license.error.log

Логики «ДВО»

Протокольный

не задается

/var/log/mvts3g/rtu-cl-common/sl-1.protocol.log

/var/log/mvts3g/rtu-cl-common/sp-1.protocol.log

Журналы основного

ds-1-logic

/var/log/mvts3g/rtu-cl-common/ds-1-logic.log

модуля сервера

/var/log/mvts3g/rtu-cl-common/ds-1-logic.error.log

обработки данных

/var/log/mvts3g/rtu-cl-common/profile/ds-1-

logic.profiler.txt

/var/log/mvts3g/rtu-cl-common/profile/ds-1-

logic.memory.profiler.txt

/var/log/mvts3g/rtu-cl-common/profile/ds-1-

logic.freememory.profiler.txt

Журналы модуля

ds-1-license

/var/log/mvts3g/rtu-cl-common/ds-1-license.log

лицензирования

/var/log/mvts3g/rtu-cl-common/ds-1-license.error.log

сервера обработки

данных

Ведение вышеперечисленных журналов настраивается в файле /etc/rtu-cl-common/log/log.conf.

17.2

Журналы подсистемы веб-интерфейса МОА

Подсистема веб-интерфейса компонента МОА записывает следующие журналы:

Журналы авторизации и изменения данных на веб-интерфейсе:

- /var/log/mvts3g/rtu-cl-webdb/web_security.log*

- /var/log/mvts3g/rtu-cl-webdb/web_security.error.log*

* настраиваются в файле /etc/rtu-cl-webdb/log/web.log.conf.

Система также производит автовыгрузку журналов действий пользователя на веб-интерфейсе для

МОА. Путь для автовыгрузки определяется в файле autoexport_config.php, через переменную

save_path, по умолчанию в каталог /var/log/centrex.

Журналы авторизации и изменения данных через API:

- /var/log/mvts3g/rtu-cl-webdb/api_security.log*

- /var/log/mvts3g/rtu-cl-webdb/api_security.error.log*

* настраиваются в файле /etc/rtu-cl-webdb/log/api.log.conf.

Журналы утилиты доступа к хранимым хешам:

- /var/log/mvts3g/rtu-cl-webdb/hash-server.log*

- /var/log/mvts3g/rtu-cl-webdb/profile/hash-server.profiler.txt*

- /var/log/mvts3g/rtu-cl-webdb/profile/hash-server.memory.profiler.txt*

* настраиваются в файле /etc/rtu-cl-webdb/log/hash-server.log.conf.

196 |

17.3 Поиск отладочной информации в журналах МОА

Поиск информации для исследования проблемы имеет смысл начинать с журналов Логики «ОС».

Отправной информацией при поиске может служить точное время вызова, а также номера телефонов

на входящем участке вызова.

1. В CDR-записи интересующего вас вызова найдите значения полей

«Идентификатор

конференции»

(conf_id)

«Протокольный

идентификатор

конференции» (protocol_conf_id).

2. Запись о данном вызове в файле /var/log/mvts3g/rtu-cl-common/sl-1-logic.log

будет

иметь

следующий вид:

06.04.2016 16:29:44.435033 0012 INF 8B90C81EFD5BE62B388CCA74B10E6F7C

OnRegisterCall() protocol = Sip

06.04.2016 16:29:44.435071 0012 INF 8B90C81EFD5BE62B388CCA74B10E6F7C

OnRegisterCall() call Id = 9ffb3186fbfb11e5a3c6462c3b9cb401

06.04.2016 16:29:44.435088 0012 INF 8B90C81EFD5BE62B388CCA74B10E6F7C

OnRegisterCall() conference Id = 9ffb3186fbfb11e5a3c6462c3b9cb401

06.04.2016 16:29:44.435105 0012 INF 8B90C81EFD5BE62B388CCA74B10E6F7C

OnRegisterCall() fingerprint = 4732045468146496510

06.04.2016 16:29:44.435154 0012 INF 8B90C81EFD5BE62B388CCA74B10E6F7C

OnRegisterCall() registration Id = 12319968533073860088

06.04.2016 16:29:44.435170 0012 INF 8B90C81EFD5BE62B388CCA74B10E6F7C

OnRegisterCall() external registration Id = NULL

06.04.2016 16:29:44.435221 0012 INF 8B90C81EFD5BE62B388CCA74B10E6F7C

OnRegisterCall() source = 54321

06.04.2016 16:29:44.435297 0012 INF 8B90C81EFD5BE62B388CCA74B10E6F7C

OnRegisterCall() source URL = sip:54321@192.168.229.85:5070

06.04.2016 16:29:44.435316 0012 INF 8B90C81EFD5BE62B388CCA74B10E6F7C

OnRegisterCall() destination = 54322

06.04.2016 16:29:44.435331 0012 INF 8B90C81EFD5BE62B388CCA74B10E6F7C

OnRegisterCall() destination URL = sip:54322@192.168.229.85:5070

06.04.2016 16:29:44.435350 0012 INF 8B90C81EFD5BE62B388CCA74B10E6F7C

OnRegisterCall() P_Served_User =

06.04.2016 16:29:44.435375 0012 INF 8B90C81EFD5BE62B388CCA74B10E6F7C

OnRegisterCall() zone = voip

06.04.2016 16:29:44.436159 0012 INF 8B90C81EFD5BE62B388CCA74B10E6F7C

OnRegisterCall() source IP = 192.168.240.151:52169

06.04.2016 16:29:44.436275 0012 INF 8B90C81EFD5BE62B388CCA74B10E6F7C

OnRegisterCall() CPC code = 0, space None

06.04.2016 16:29:44.436333 0012 INF 8B90C81EFD5BE62B388CCA74B10E6F7C

OnRegisterCall() ts_conf_id = 9ffc0a8efbfb11e5a3c6462c3b9cb401

06.04.2016 16:29:44.436923 0012 DBG 8B90C81EFD5BE62B388CCA74B10E6F7C

RegisterCallHelper.OnRegisterIncomingCall: Domain ROOT found

С помощью значения conf_id (в нашем примере 8B90C81EFD5BE62B388CCA74B10E6F7C)

соберите информацию, относящуюся к данному вызову в отдельный файл:

Протоколирование компонентов МОА | 197

#> grep '8B90C81EFD5BE62B388CCA74B10E6F7C' /var/log/mvts3g/rtu-cl-common/sl-1-

logic.log > logic_8B90C81EFD5BE62B388CCA74B10E6F7C.log

3. С помощью утилиты mvts3g-logexport по значению protocol_conf_id

(в нашем примере

9ffc0a8efbfb11e5a3c6462c3b9cb401) извлеките протокол вызова с идентификатором

voip_conference_id

=9ffc0a8efbfb11e5a3c6462c3b9cb401

из

журнала /var/log/mvts3g/rtu-cl-common/sl-1.protocol.log:

#> /usr/bin/mvts3g-logexport /var/log/mvts3g/rtu-cl-common/sl-1.protocol.log

'9ffc0a8efbfb11e5a3c6462c3b9cb401' > rtu-cl-

core/protocol_9ffc0a8efbfb11e5a3c6462c3b9cb401.log

4. С помощью утилиты mvts3g-logexport извлеките протокол

вызова по значению

9ffc0a8efbfb11e5a3c6462c3b9cb401 из журнала

/var/log/mvts3gtraffic.log с данными

функционирования TS:

#> /usr/bin/mvts3g-logexport /var/log/mvts3g/traffic.log

'9ffc0a8efbfb11e5a3c6462c3b9cb401' >

traffic_9ffc0a8efbfb11e5a3c6462c3b9cb401.log

По такому же принципу анализируются журналы Логики «ДВО» при прохождении вызова через

данный модуль (то есть при применении сервиса):

1. По

значению параметра

«Протокольный идентификатор

конференции» в

файле

/var/log/mvts3g/rtu-cl-common/sp-1-logic.log

находится

соответствующий

«Идентификатор конференции»:

07.04.2016 17:36:14.204469 0012 INF EEAD64136EA9C0D964215E9F42C1DF2A

OnRegisterCall() zone = local

07.04.2016 17:36:14.204492 0012 INF EEAD64136EA9C0D964215E9F42C1DF2A

OnRegisterCall() source IP = string://subscriber-logic

07.04.2016 17:36:14.204555 0012 INF EEAD64136EA9C0D964215E9F42C1DF2A

OnRegisterCall() CPC code = 0, space None

07.04.2016 17:36:14.204572 0012 INF EEAD64136EA9C0D964215E9F42C1DF2A

OnRegisterCall() ts_conf_id = 146bbda6fcce11e5a3c6462c3b9cb401

2. Из данного файла извлекаются все строки, содержащие данный идентификатор конференции

(например, EEAD64136EA9C0D964215E9F42C1DF2A).

3. По значению протокольного идентификатора конференции извлекается информация из

файлов /var/log/mvts3g/rtu-cl-common/sp-1.protocol.log и /var/log/mvts3gtraffic.log с помощью

утилиты mvts3g-logexport аналогично вышеописанным шагам.

Кроме того, для извлечения отладочной информации из журнальных файлов логики «ОС» и логики

«ДВО» можно использовать утилиту infoextractor_l5. Подробнее см. документ [2], раздел Слу жебные

у тилиты РТУ МОА.

17.4

Настройка автоматического отключения

протоколирования

Система автоматически отключает протоколирование компонентов МОА при достижении::

значения таймера LogAliveMinutes, или

пиковых значений нагрузки на сервер.

198 |

17.4.1

Таймер LogAliveMinutes

Протоколирование управляющих логик МОА и сервера обработки данных на всех уровнях, кроме Fatal,

Error, Warning и Info, автоматически прекращается при достижении значения таймера, задаваемого с

помощью параметра LogAliveMinutes в файле /etc/rtu-cl-common/log_alive.conf. Таймер запускается

при любом изменении файла. При перезапуске Логики «ОС», Логики «ДВО» или сервера обработки

данных за время старта таймера принимается фактическое время изменения файла /etc/rtu-cl-

common/log_alive.conf. Значение таймера задается в параметре LogAliveMinutes в минутах. Значение

по умолчанию - 60 минут.

Задавать слишком большое значение параметра не рекомендуется, так как это может привести к

разрастанию журнальных файлов и, как следствие, нехватке места на жестком диске.

17.4.2

Пиковые значения нагрузки на сервер

По умолчанию Система автоматически отключает протоколирование управляющих логик МОА на

уровне Debug при достижении следующих значений:

· 500 регистраций в секунду (RPS);

· 200 новых вызовов в секунду (CPS);

100 тысяч сообщений в очереди на запись в журнальные файлы.

Для изменения данных пороговых значений пропишите следующие параметры в файле /etc/rtu-cl-

common/common.conf:

log_max_rps = 500

log_max_cps = 200

log_max_queue = 100000

Минимальные допустимые значения параметров:

100

(log_max_rps, log_max_cps) и

100000

(log_max_queue).

Максимальные: 1000 (log_max_rps), 300 (log_max_cps) и 300000 (log_max_queue).

Параметры являются общими для Логики

«ОС» и Логики

«ДВО». При их отсутствии в

конфигурационном файле используются значения по умолчанию (см. выше).

Приложения | 199

Приложения

18.1

Приложение А. Формат CDR-записей

«Эффективный» инициатор вызова - учетная запись абонента или шлюза, с правами которой

осуществлялась маршрутизация вызова.

«Эффективный» адресат вызова - учетная запись абонента или шлюза, на которую система должна

отправить вызов в результате маршрутизации.

«Реальный» инициатор вызова - учетная запись абонента или шлюза, представляющая удаленную

сторону участка вызова, инициировавшего дозвон.

«Реальный» адресат вызова - учетная запись абонента или шлюза, представляющая удаленную сторону

созданного исходящего участка вызова.

Для каждого из них в таблице указывается:

1. Тип - User (для абонента) или Gateway (для шлюза).

2. ID - номер (для абонента) или имя (для шлюза).

3. GUID - внутренний идентификатор этой сущности в БД.

4. Имя - значение поля Пользователь для абонента и Имя для шлюза.

Поле

Тип

Название колонки при

Описание

отображении на веб-

интерфейсе

cdr_id

bigint(20) unsigned

Идентификатор

Уникальный

автоинкрементируемый

идентификатор CDR-записи,

создается БД при записи CDR в

базу.

stamp

bigint(20) unsigned

Идентификатор записи

Уникальный идентификатор

CDR, используемый системой

для предотвращения

дублируемых записей,

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

CDR внутри системы.

conf_id

varchar(40)

Идентификатор

Уникальный идентификатор

конференции

конференции в логике «ОС».

Генерируется логикой «ОС»

при создании конференции.

Объединяет участки вызовов в

рамках одной логики.

Подробнее см. ниже.

protocol_conf_id

varchar(100)

Протокольный

Идентификатор конференции,

идентификатор

передаваемый в сигнальных

конференции

сообщениях из одного участка

вызова в другой. Используется

для связи участков вызова при

прохождении через несколько

модулей системы, а также для

связи CDR-записей с

записанными разговорами и

вызовами в рамках сервиса

200 |

«Очередь вызовов».

Принимается от оборудования

или генерируется ПКомм.

Подробнее см. ниже.

cdr_date

timestamp

Дата создания CDR

Время создания CDR в логике

«ОС». См. ниже.

direction

varchar(40)

Направление

Идентификатор направления

вызова. Однозначно

идентифицирует один из

вызовов (направление) при

нескольких вызовах в рамках

одной конференции.

dvo

varchar(100)

Дополнительные виды

Список услуг, использованных

обслуживания

на протяжении всего вызова.

Значения описаны ниже.

proxy_mode

tinyint(3) unsigned

Режим проксирования

Режим проксирования вызова.

Может принимать два

значения:

no proxy - выполнялось прямое

медиасоединение;

proxy - выполнялось

проксирование мультимедиа.

start_time

datetime

Время старта

Время получения первого

сигнального сообщения,

относящегося к этой

конференции. См. ниже.

connect_time

datetime

Время соединения

Время установления

соединения. См. ниже.

disconnect_time

datetime

Время разъединения

Время разъединения. См. ниже.

disconnect_reason

varchar(100)

Описание кода

Описание причины

разъединения

разъединения. Возможные

причины разъединения можно

посмотреть в веб-интерфейсе

администратора.

disconnect_code

int(10) unsigned

Код разъединения

Код разъединения. Возможные

коды разъединения можно

посмотреть в веб-интерфейсе

администратора. Содержимое

данного поля включает

категорию кода, номера кода в

рамках категории и описание

причины разъединения.

disconnect_initiator

tinyint(3)

Инициатор

Инициатор разъединения

разъединения

может принимать значения:

Подсистема коммутации;

Подсистема коммутации (вх.

участок вызова);

Подсистема коммутации

(исх. участок вызова)

Приложения | 201

Инициатор вызова;

Вызываемая сторона.

elapsed_time

int(10) unsigned

Продолжительность

вызова

соединения, формат зависит от

настроек выгрузки. На веб-

интерфейсе отображается с

округлением до секунд.

route_name

varchar(100)

Имя маршрута

Имя маршрута, по которому

прошел вызов.

originator_id

varchar(100)

Идентификатор

ID «эффективного»

инициатора

инициатора вызова.

originator_guid

varchar(40)

GUID инициатора

GUID «эффективного»

инициатора вызова.

originator_type

varchar(100)

Тип инициатора

Тип «эффективного»

инициатора вызова.

originator_name

varchar(100)

Имя инициатора

Имя «эффективного»

инициатора вызова.

terminator_id

varchar(100)

Идентификатор

ID «эффективного» адресата

терминатора

вызова.

terminator_guid

varchar(40)

GUID терминатора

GUID «эффективного» адресата

вызова.

terminator_type

varchar(100)

Тип терминатора

Тип «эффективного» адресата

вызова.

terminator_name

varchar(100)

Имя терминатора

Имя «эффективного» адресата

вызова.

cpc_in

smallint(5) unsigned

Категория вх. вызова

Идентификатор категории,

принятой во входящем участке

вызова. Значение данного поля

содержит пространство

категорий и номер принятой

категории.

cpc_out

smallint(5) unsigned

Категория исх. вызова

Идентификатор категории,

переданной в исходящий

участок вызова.

Значение данного поля

содержит пространство

категорий и номер принятой

категории.

cpc

smallint(5) unsigned

Категория вызова при

Идентификатор категории,

маршрутизации

используемой при

маршрутизации. Значение

данного поля содержит

пространство категорий и

номер принятой категории.

src_in

varchar(100)

Вх. А-номер

А-номер при приеме

входящего участка вызова в

202 |

систему.

dst_in

varchar(100)

Вх. Б-номер

Б-номер при приеме входящего

участка вызова в систему.

src

varchar(100)

А-номер во внутреннем

Номер совершающего вызов

плане нумерации

абонента во внутреннем плане

нумерации.

dst

varchar(100)

Б-номер во внутреннем

Вызываемый номер во

плане нумерации

внутреннем плане нумерации.

Данный номер используется

для маршрутизации вызова в

качестве Б-номера.

src_out

varchar(100)

Исх. А-номер

А-номер, передаваемый в

исходящий участок вызова.

dst_out

varchar(100)

Исх. Б-номер

Б-номер, передаваемый в

исходящий участок вызова.

effective_src

varchar(100)

Эффективный А-номер

Номер абонента, который

владеет вызовом и должен его

оплачивать. Данный номер

используется в качестве А-

номера при маршрутизации.

domain_id

varchar(100)

Идентификатор домена

Идентификатор домена, в

котором происходила

обработка вызова.

domain_guid

varchar(40)

GUID домена

GUID домена, в котором

происходила обработка вызова.

domain_path

varchar(255)

Иерархическое имя

Иерархический идентификатор

домена

домена. Идентификатор,

полученный перечислением

через точку идентификаторов

всех вышестоящих доменов до

ROOT, начиная с

идентификатора этого домена

вверх.

in_ani_type_of_numb

tinyint(4)

Тип вх. А-номера

Тип А-номера при приеме

входящего участка вызова.

Возможные значения см. ниже.

in_dnis_type_of_num

tinyint(4)

Тип вх. Б-номера

Тип Б-номера при приеме

ber

входящего участка вызова.

Возможные значения см. ниже.

src_ton

tinyint(4)

Тип А-номера

Тип А-номера при

маршрутизации вызова.

Возможные значения см. ниже.

dst_ton

tinyint(4)

Тип Б-номера

Тип Б- номера при

маршрутизации вызова.

Возможные значения см. ниже.

Приложения | 203

out_ani_type_of_num

tinyint(4)

Тип исх. А-номера

Тип А-номера, передаваемый в

ber

исходящий участок вызова.

Возможные значения см. ниже.

out_dnis_type_of_nu

tinyint(4)

Тип исх. Б-номера

Тип Б-номера, передаваемый в

mber

исходящий участок вызова.

Возможные значения см. ниже.

effective_src_ton

tinyint(4)

Тип эффективного А-

Тип номера, использованный в

номера

качестве типа номера

абонента-владельца вызова.

Данный тип номера

используется для

маршрутизации в качестве типа

А-номера. Возможные

значения см. ниже.

remote_originator_id

varchar(100)

Идентификатор

ID «реального» инициатора

удаленного инициатора

вызова.

remote_originator_gui

varchar(40)

GUID удаленного

GUID «реального» инициатора

инициатора

вызова.

remote_originator_na

varchar(100)

Имя удаленного

Имя «реального» инициатора

инициатора

вызова.

remote_originator_typ

varchar(100)

Тип удаленного

Тип «реального» инициатора

инициатора

вызова.

call_id_in

varchar(40)

Идентификатор вх.

Идентификатор входящего

звонка

участка вызова в сигнальных

сообщениях. Генерируется

ПКомм.

in_leg_proto

varchar(8)

Протокол вх. вызова

Тип сигнализации на входящем

участке вызова.

Может принимать значения:

sip, h323 и null для вызовов по

внутреннему протоколу.

in_zone

varchar(100)

Зона вх. вызова

Зона входящего участка

вызова. Определяется ПКомм

на основании локального

сигнального адреса входящего

участка вызова и

конфигурации зон.

call_id_in_proto

varchar(100)

Протокольный

Идентификатор входящего

идентификатор вх.

участка вызова, передаваемый

вызова

в сигнальных сообщениях.

Принимается от удаленной

стороны.

conf_id_ts_in

varchar(100)

Идентификатор вх.

Идентификатор конференции

вызова на TS

на входящем участке вызова в

сигнальных сообщениях.

Генерируется ПКомм.

remote_src_sig_addre

varchar(21)

Удаленный сигнальный

Адрес инициирующей

адрес исх. вызова

стороны, с которого был

204 |

получен сигнальный пакет. IP-

адрес и порт или строка в

случае вызова по внутреннему

протоколу.

local_src_sig_address

varchar(21)

Локальный сигнальный

Адрес интерфейса, на который

адрес исх. вызова

поступил вызов, и порт, на

который принимались

сигнальные пакеты; или строка

в случае внутреннего

протокола.

aux_src_disconnect_c

varchar(100)

Дополнительный код

Дополнительные коды

ode

разъединения исх.

разъединения - причина

вызова

разъединения, полученная или

отправленная в

дополнительных полях

сообщения ПКомм,

завершавшего входящий вызов.

originator_diversion

varchar(100)

Заголовок Diversion вх.

SIP URI или номер,

вызова

определяющий участника

вызова, от имени которого

производилось последнее

перенаправление вызова во

входящем участке вызова.

originator_diversion_r

smallint(4)

Причина

Причина последнего

eason

переадресации вх.

перенаправления во входящем

вызова

участке вызова. Возможные

значения см. ниже.

q931_code

smallint(4)

Код разъединения Q.931

Причина разъединения в виде

кода Q.931.

in_leg_codecs

text

Кодеки вх. вызова

Кодеки, используемые для

передачи медиаинформации во

входящем участке вызова.

src_media_bytes_in

int(10) unsigned

Число байт, полученных

Общее количество байт,

от инициатора

переданных в медиаканале на

входящем участке вызова от

инициирующего устройства до

станции.

src_media_bytes_out

int(10) unsigned

Число байт,

Общее количество байт,

отправленных

переданных в медиаканале на

инициатору

входящем участке вызова от

станции до инициирующего

устройства.

src_media_packets_in

int(10) unsigned

Число медиа-пакетов

Общее количество пакетов,

полученных от

переданных в медиаканале на

инициатора

входящем участке вызова от

инициирующего устройства до

станции.

src_media_packets_o

int(10) unsigned

Число медиа-пакетов

Общее количество пакетов,

отправленных

переданных в медиаканале на

Приложения | 205

инициатору

входящем участке вызова от

станции до инициирующего

устройства.

src_media_packets_la

int(10) unsigned

Число запоздавших

Количество пакетов,

медиа-пакетов во вх.

пришедших с опозданием от

вызове

инициирующего устройства до

станции во входящем участке

вызова.

src_media_packets_lo

int(10) unsigned

Число потерянных

Количество пакетов, не

медиа-пакетов во вх.

дошедших до станции от

вызове

инициирующего устройства во

входящем участке вызова.

src_min_jitter_size

smallint(5) unsigned

Мин. размер джиттера

Минимальный объем джиттера

вх. вызова

на входящем участке вызова.

src_max_jitter_size

smallint(5) unsigned

Макс. размер джиттера

Максимальный объем

вх. вызова

джиттера на исходящем участке

вызова.

remote_src_media_ad

varchar(100)

Удаленный медиа адрес

Адрес, с которого удаленная

dress

исх. вызова

сторона инициатора вызова

отправляла медиапоток. IP-

адрес и порт или строка в

случае вызова по внутреннему

протоколу

local_src_media_addr

varchar(21)

Локальный медиа адрес

Адрес и порт интерфейса, на

ess

исх. вызова

который принимались

медиапакеты. Строка при

использовании внутреннего

протокола.

remote_terminator_gui

varchar(40)

GUID удаленного

GUID «реального» адресата

терминатора

вызова.

remote_terminator_id

varchar(100)

Идентификатор

ID «реального» адресата

удаленного

вызова.

терминатора

remote_terminator_na

varchar(100)

Имя удаленного

Имя «реального» адресата

терминатора

вызова.

remote_terminator_ty

varchar(100)

Тип удаленного

Тип «реального» адресата

терминатора

вызова.

call_id_out

varchar(40)

Идентификатор исх.

Идентификатор исходящего

звонка

участка вызова в логике и

сигнальных сообщениях.

Создается логикой при

формировании участка вызова.

out_leg_proto

varchar(8)

Протокол исх. вызова

Тип сигнализации на

исходящем участке вызова.

Может принимать значения:

sip, h323 и null для вызовов по

внутреннему протоколу.

206 |

out_zone

varchar(100)

Зона исх. вызова

Зона исходящего участка

вызова. Определяется на этапе

создания участка вызова.

call_id_out_proto

varchar(100)

Протокольный

Протокольный идентификатор

идентификатор исх.

исходящего участка вызова в

вызова

сигнальных сообщениях.

Создается логикой «ОС».

conf_id_ts_out

varchar(100)

Идентификатор исх.

Идентификатор конференции в

вызова на TS

исходящем участке вызова в

сигнальных сообщениях.

Создается логикой «ОС».

remote_dst_sig_addre

varchar(21)

Удаленный сигнальный

Адрес вызываемой стороны, на

адрес вх. вызова

который посылались

сигнальные пакеты. IP-адрес и

порт или строка в случае

вызова по внутреннему

протоколу.

local_dst_sig_address

varchar(21)

Локальный сигнальный

Адрес интерфейса, на котором

адрес вх. вызова

был создан вызов, и порт, с

которого отправлялись

сигнальные пакеты. Строка при

использовании внутреннего

протокола.

aux_dst_disconnect_c

varchar(100)

Дополнительный код

Дополнительные коды

ode

разъединения вх. вызова

разъединения - причина

разъединения, полученная или

отправленная в

дополнительных полях

сообщения ПКомм,

завершавшего исходящий

вызов.

terminator_diversion

varchar(100)

Заголовок Diversion исх.

SIP URI или номер участника

вызова

вызова, от имени которого

производилось последнее

перенаправление вызова.

terminator

smallint(4)

Причина

Причина последнего

_diversion_reason

переадресации исх.

перенаправления вызова в

вызова

исходящем вызове.

out_leg_codecs

text

Кодеки исх. вызова

Кодеки, используемые для

передачи медиаинформации в

исходящем участке вызова.

dst_media_bytes_in

int(10) unsigned

Число байт, полученных

Общее количество байт,

от терминатора

переданных в медиаканале на

исходящем участке вызова от

вызываемого устройства до

станции

dst_media_bytes_out

int(10) unsigned

Число байт,

Общее количество байт,

отправленных

переданных в медиаканале на

терминатору

исходящем участке вызова от

Приложения | 207

станции до вызываемого

устройства.

dst_media_packets_in

int(10) unsigned

Число медиа-пакетов

Общее количество пакетов,

полученных от

переданных в медиаканале на

терминатора

исходящем участке вызова от

вызываемого устройства до

станции.

dst_media_packets_o

int(10) unsigned

Число медиа-пакетов

Общее количество пакетов,

отправленных

переданных в медиаканале на

терминатору

исходящем участке вызова от

станции до вызываемого

устройства.

dst_media_packets_la

int(10) unsigned

Число запоздавших

Количество пакетов,

медиа-пакетов на исх.

пришедших от вызываемого

леге

устройства до станции с

опозданием в исходящем

участке вызова.

dst_media_packets_lo

int(10) unsigned

Число потерянных

Количество пакетов, не

медиа-пакетов на исх.

дошедших до станции от

леге

вызываемого устройства в

исходящем участке вызова.

dst_min_jitter_size

smallint(5) unsigned

Мин размер джиттера

Минимальный размер

исх. лега

джиттера на исходящем участке

вызова.

dst_max_jitter_size

smallint(5) unsigned

Макс размер джиттера

Максимальный размер

исх. лега

джиттера на исходящем участке

вызова.

remote_dst_media_ad

varchar(100)

Удаленный медиа адрес

Адрес, с которого удаленная

dress

вх. вызова

сторона адресата вызова

отправляла медиапоток. IP-

адрес и порт или строка в

случае вызова по внутреннему

протоколу

local_dst_media_addr

varchar(21)

Локальный медиа адрес

Адрес интерфейса, с которого

ess

вх. вызова

отправлялись медиапакеты. IP-

адрес и порт или строка при

использовании внутреннего

протокола.

user_disconnect_cod

smallint(4)

Причина разъединения

Причина разъединения для

отображения в веб-кабинета

абонента.

Может принимать значения:

- Удачный звонок;

- Занято;

- Нет ответа;

- Другое.

originator_terminal_id

smallint(5)

Идентификатор

Идентификатор абонентского

терминала инициатора

терминала инициатора вызова.

208 |

terminator_terminal_id

smallint(5)

Идентификатор

Идентификатор абонентского

терминала терминатора

терминала вызываемой

стороны.

billing_src

varchar(100)

А-номер для биллинга

Номер вызывающего абонента,

использующийся для целей

учета и биллинга

billing_dst

varchar(100)

Б-номер для биллинга

Номер вызываемого абонента,

использующийся для целей

учета и биллинга

effective_billing_src

varchar(100)

Эффективный А-номер

В случае вызова без

для биллинга

переадресации совпадает с

полем А-номер для биллинга

инициатора вызова. В случае

переадресации совпадает с

полем А-номер для биллинга

абонента, совершившего

переадресацию

signaling_node_id

varchar(50)

Модуль управления

Название модуля управления

вызовами

вызовами (signaling node), на

который поступил вызов.

Смысл таких сущностей, как идентификатор конференции и протокольный идентификатор

конференции можно рассмотреть на примере ниже. CDR-записи, формируемые при использовании

абонентом А ДВО «Автодозвон» для вызова абонента В.

Идентификато

Протокольный

Вх. А-

Исх. А-

Вх. Б-

Исх. Б-

Идентиф

р конференции

идентификатор

номер

икатор

конференции

инициато

терминат

ра

ора

8A2C5C44A6B

1bb87a9ae53511e

19A28B46CE2F

1a3c600e052c7b5

99F0368BB

E3A9DF280225

1bb87a9ae53511e

AutoRedi

GWAuto

C335E0AB78C

1a3c600e052c7b5

al+1 +B

Dial

D955768B8

У приведенных в примере CDR-записей разные идентификаторы конференции (они одинаковые для

участков вызовов внутри одной Логики), но одинаковые протокольные идентификаторы конференции

(одинаковые для всех участков одного вызова).

Значение времени хранится в БД в стандарте UTC, при выгрузке и отображении CDR-записи на веб-

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

сделаны выгрузка или отображение.

Поле Причина переадресации вх. вызова может принимать значения:

unknown

user-busy

no-answer

Приложения | 209

unavailable

unconditional

time-of-day

do-not-disturb

deflection

follow-me

out-of-service

away

Поля, содержащие тип номера, могут принимать значения:

Unknown

International

National

NetworkSpecific

Subscriber

Abbreviated

Поле Дополнительные виды обслуживания может содержать (через «;»):

CallWaiting - ожидающий вызов;

CallTransfer - перевод вызова;

Conference - трехсторонняя или многосторонняя конференция;

ForwardUnconditional - безусловная переадресация;

ForwardNoAnswer - переадресация по неответу;

ForwardBusy - переадресация по занятости;

ForwardUnavailable - переадресация по недоступности;

CallDeflection - переадресация средствами телефона;

ForwardSubscriberService - ДВО «Переадресация вызова»;

PickUp - ДВО «Перехват вызова»;

CallReplacing - перехват вызова (как через ДВО «Перехват вызова», так и средствами телефона);

PersonalIVRDialMe - вызов абонента с использованием сценария IVR;

MultiTerminalCall - ДВО «Многотерминальность».

Примеры CDR-записей

Базовый вызов

Абонент А вызывает абонента В.

Вх.

Эфф

А-

Б-

Исх.

Вх. Б-

Исх.

Дополни

Код

Иден

А-

екти

номер

А-

номер

Б-

т. виды

разъе

тифи

вный

номер

катор

210 |

номе

А-

номе

обслужи

дине

иниц

удале

терм

удале

номе

вания

ния

иатор

нного

инато

нного

иниц

ра

терм

иатор

инато

ра

[TS],

[SIP]

BYE

receiv

Абонент А вызывает шлюз GW. На шлюзе выполняется преобразование Б-номера: 8 заменяется на 7,

тип - на International.

Вх. А-

Эффе

А-

Б-

Исх.

Вх. Б-

Исх.

Допол

Идент

Тип

Код

номер

ктивн

номер

А-

номер

Б-

нит.

ифика

вх. Б-

исх.

разъе

ый А-

номер

виды

тор

номер

Б-

динен

номер

обслу

удале

номер

ия

жива

нного

ния

иници

терми

атора

натор

81234

712345

Interna

[TS],

tional

[SIP]

BYE

receive

Переадресация

Абонент А вызывает абонента В. Выполняется безусловная переадресация на абонента С.

Вх. А-

Эффе

А-

Б-

Исх.

Вх. Б-

Исх.

Допол

Код

Идент

номер

ктивн

номер

А-

номер

Б-

нит.

разъе

ифика

ый А-

номер

виды

динен

тор

номер

обслу

ия

иници

удале

терми

удале

жива

атора

нного

натор

нного

ния

иници

терми

атора

натор

[TS],

[SIP]

BYE

receive

Forwar

[TS],

dUnco

Приложения | 211

ndition

[SIP]

BYE

receive

Абонент А вызывает абонента В. Выполняется переадресация по занятости на абонента С.

Вх. А-

Эффе

А-

Б-

Исх.

Вх. Б-

Исх.

Допол

Код

Идент

номер

ктивн

номер

А-

номер

Б-

нит.

разъе

ифика

ый А-

номер

виды

динен

тор

номер

обслу

ия

иници

удале

терми

удале

жива

атора

нного

натор

нного

ния

иници

терми

атора

натор

[TS],

[SIP]

BYE

receive

Forwar

[TS],

dBusy

[SIP]

BYE

receive

Перевод вызова

Абонент А вызывает абонента В, В переводит вызов на С.

Вх. А-

Эффе

А-

Б-

Исх.

Вх. Б-

Исх.

Допол

Код

Идент

номер

ктивн

номер

А-

номер

Б-

нит.

разъе

ифика

ый А-

номер

виды

динен

тор

номер

обслу

ия

иници

удале

терми

удале

жива

атора

нного

натор

нного

ния

иници

терми

атора

натор

[TS],

[SIP]

BYE

receive

CallTra

[TS],

nsfer

212 |

[SIP]

BYE

receive

Абонент А вызывает абонента В, А переводит вызов на С.

Вх. А-

Эффе

А-

Б-

Исх.

Вх. Б-

Исх.

Допол

Код

Идент

номер

ктивн

номер

А-

номер

Б-

нит.

разъе

ифика

ый А-

номер

виды

динен

тор

номер

обслу

ия

иници

удале

терми

удале

жива

атора

нного

натор

нного

ния

иници

терми

атора

натор

[TS],

[SIP]

BYE

receive

CallTra

[TS],

nsfer

[SIP]

BYE

receive

Абонент А вызывает абонента В, В переводит вызов на С и объединяет всех в конференцию.

Вх. А-

Эффе

А-

Б-

Исх.

Вх. Б-

Исх.

Допол

Код

Идент

номер

ктивн

номер

А-

номер

Б-

нит.

разъе

ифика

ый А-

номер

виды

динен

тор

номер

обслу

ия

иници

удале

терми

удале

жива

атора

нного

натор

нного

ния

иници

терми

атора

натор

[TS],

[SIP]

BYE

receive

CallTra

[TS],

nsfer;C

[SIP]

Приложения | 213

onferen

BYE

receive

Ожидание вызова

Абонент B разговаривает, абонент А вызывает В, срабатывает уведомление о входящем вызове,

абонент В нажимает комбинацию клавиш *#, чтобы принять новый вызов.

Вх. А-

Эффе

А-

Б-

Исх.

Вх. Б-

Исх.

Допол

Код

Идент

номер

ктивн

номер

А-

номер

Б-

нит.

разъе

ифика

ый А-

номер

виды

динен

тор

номер

обслу

ия

иници

удале

терми

удале

жива

атора

нного

натор

нного

ния

иници

терми

атора

натор

CallWa

[TS],

iting

[SIP]

BYE

receive

Абонент B разговаривает, абонент А вызывает В, срабатывает уведомление о входящем вызове,

участники объединяются в конференцию нажатием *2.

Вх. А-

Эффе

А-

Б-

Исх.

Вх. Б-

Исх.

Допол

Код

Идент

номер

ктивн

номер

А-

номер

Б-

нит.

разъе

ифика

ый А-

номер

виды

динен

тор

номер

обслу

ия

иници

удале

терми

удале

жива

атора

нного

натор

нного

ния

иници

терми

атора

натор

CallWa

[TS],

iting;C

onferen

[SIP]

BYE

receive

Абонент B разговаривает, абонент А вызывает В, срабатывает уведомление о входящем вызове, В

отклоняет входящий вызов, нажав *1.

Вх. А-

Эффе

А-

Б-

Исх.

Вх. Б-

Исх.

Допол

Код

Идент

номер

ктивн

номер

А-

номер

Б-

нит.

разъе

ифика

ый А-

номер

виды

динен

тор

номер

обслу

ия

иници

удале

терми

удале

атора

нного

214 |

жива

иници

натор

терми

ния

атора

натор

CallWa

[SIP],

iting;C

487

onferen

Reques

Termin

ated

«Следуй за мной»

Абонент А вызывает В, у В настроено ДВО «Следуй за мной» сначала на абонента С, потом на D.

FlwMe - номер ДВО «Следуй за мной»

Вх. А-

Эффек

А-

Б-

Исх.

Вх.

Исх.

Дополн

Код

Иде

номер

тивны

номер

А-

Б-

ит.

разъедине

нти

й А-

номе

виды

ния

фик

номер

обслуж

атор

ивания

ини

удал

терм

удал

циат

енно

инат

енно

ора

го

ора

го

ини

терм

циат

инат

ора

[centrex],

239

FollowM e:

Killing legs

[TS],

10 -

[SIP] BYE

received

FlwM

[TS],

10 -

[SIP] BYE

received

FlwM e

FlwM

Forward

[TS],

10 -

Subscrib

[SIP] BYE

erService

received

Перехват вызова

Абонент А вызывает абонента В, абонент C перехватывает вызов, используя ДВО «Перехват вызова».

PickUp - номер ДВО «Перехват вызова»

Вх. А-

Эффе

А-

Б-

Исх.

Вх. Б-

Исх.

Допол

Код

Идент

номер

ктивн

номер

А-

номер

Б-

нит.

разъе

ифика

номер

виды

тор

Приложения | 215

ый А-

обслу

динен

иници

удале

терми

удале

номер

жива

ия

атора

нного

натор

нного

ния

иници

терми

атора

натор

PickU

[TS],

GwPic

kUp

[SIP]

BYE

receive

PickU

[cent

rex],

Pick

CallRe

[TS],

p lacing

[SIP]

BYE

receive

Автодозвон

Абонент А использует ДВО «Автодозвон» для вызова абонента B.

AutoDial - номер доступа к ДВО «Автодозвон».

Вх. А-

Эффе

А-

Б-

Исх.

Вх. Б-

Исх.

Допол

Код

Идент

номер

ктивн

номер

А-

номер

Б-

нит.

разъе

ифика

ый А-

номер

виды

динен

тор

номер

обслу

ия

иници

удале

терми

удале

жива

атора

нного

натор

нного

ния

иници

терми

атора

натор

[TS],

[SIP]

BYE

receive

AutoD

[TS],

GwAu

ial+B

toDial

[SIP]

BYE

receive

216 |

18.2

Приложение Б. Сценарии передачи КПВ

Для настройки передачи КПВ необходимо перейти в раздел Настройки оборудования → Профили

терминалов и задать параметры профиля терминала, используемого абонентом или шлюзом. При этом

возможны следующие сценарии:

1. Чтобы включить воспроизведение КПВ со стороны оборудования вызываемого абонента,

необходимо сделать следующее:

В настройка профиля терминала вызывающего абонента для параметра Эмулировать КПВ

выбрать значение Да

(является показателем того, что вызывающему абоненту может

проигрываться КПВ сторонними средствами

- станцией или оборудованием вызываемого

абонента).

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

сообщение вызывающему до соединения выбрать От вызываемого.

Требования к используемому оборудованию:

Оборудование вызываемого абонента должно поддерживать воспроизведение собственных

аудиофайлов (КПВ). В этом случае на РТУ отправляются сигнальные сообщения 180 Ringing или

183 Session Progress с указанием SDP (список кодеков, которые используются для воспроизведения

аудиофайлов оборудованием). Если оборудование вызываемого абонента пришлет 180 Ringing или

183 Session Progress без SDP, то проиграется КПВ станции.

2. Чтобы включить проигрывание КПВ только со стороны станции, необходимо сделать следующее:

В настройка профиля терминала вызывающего абонента для параметра Эмулировать КПВ

выбрать значение Да.

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

сообщение вызывающему до соединения выбрать Не передавать.

Требования к используемому оборудованию:

Оборудование вызываемого абонента должно поддерживать сигнальные сообщения 180 Ringing или

183 Session Progress

- только после получения сообщения станция начнет проигрывать КПВ

вызывающему абоненту.

3. Чтобы включить воспроизведение КПВ только со стороны оборудования вызывающего абонента,

необходимо выполнить следующее:

В настройка профиля терминала вызывающего абонента для параметра Эмулировать КПВ

выбрать значение Нет.

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

сообщение вызывающему до соединения можно выбрать любое значение.

Требования к используемому оборудованию:

Оборудование вызываемого абонента должно поддерживать сигнальные сообщения 180 Ringing или

183 Session Progress. После получения сообщения станция начнет проигрывать КПВ вызывающей

стороне. Оборудование вызывающего абонента должно поддерживать воспроизведение собственных

аудиофайлов (КПВ) по получении от станции сообщения 180 Ringing без SDP.

4. Если оборудование вызываемого абонента сначала присылает сигнальное сообщение 18х с SDP, а

потом присылает сообщение 18х без SDP, это приводит к тому, что сначала проигрывается КПВ от

Приложения | 217

вызываемого абонента, а потом КПВ от станции или наоборот. Для того чтобы зафиксировать

параметры сессии по первому сообщению, выполните следующее:

В настройка профиля терминала (раздел Настройки оборудования → Профили терминалов)

вызываемого абонента для параметра Игнорировать повторные сообщения SIP 18x с SDP выбрать

значение Да.

5. Если оборудование вызываемого шлюза проигрывает КПВ до отправки сообщения 18х с SDP или

вовсе не отправляет данное сообщение, то чтобы включить проигрывание КПВ вызывающей

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

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

вызывающему до соединения выбрать значение Всегда от вызываемого.

18.3

Приложение В. Регулярные выражения

Регулярные выражения являются мощным инструментом для задания критериев поиска информации

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

поиска состоят из произвольных буквенно-цифровых символов и, так называемых метасимволов.

18.3.1

Метасимволы

Метасимвол

Описание

Соответствие символам

соответствие любому символу

[]

соответствие любому символу, заключенному в скобки

Соответствие расположению

соответствие началу строки

соответствие концу строки

Соответствие количеству символов

0 или 1 повторение предшествующего выражения

0 или более повторений предшествующего выражения

1 или более повторений предшествующего выражения

{x}

x повторений предшествующего выражения

{x,}

x или более повторений предшествующего выражения

{x,y}

не менее x повторений, но не более y повторений

предшествующего выражения

Вариация

218 |

Метасимвол

Описание

соответствие выражению до или после метасимвола

Группировка

( )

логическая группировка

Для того, чтобы метасимвол рассматривался как обычный символ, перед ним необходимо поставить

символ обратной черты “\” (т.н. экранирование).

18.3.2

Использование регулярных выражений для поиска

Предположим, вы хотите найти CDR-записи вызовов, в которых участвовали номера, начинающиеся на

“7495123”, “7495124” или “7495125” и оканчивающиеся на любые четыре цифры. В данном случае при

поиске используйте следующее регулярное выражение:

^7495(123|124|125).{4}$

В результате поиска система отобразит записи, содержащие номера

74951231234,

74951243333,

74951254567, 74951255678 и т.д

Предположим, вы хотите найти записи, содержащие номера, начинающиеся на “7495” и

оканчивающиеся на 1 или 2 или 3. В данном случае при поиске используйте следующее регулярное

выражение.

^7495.*[123]$

В результате поиска система отобразит записи, содержащие номера 74951111111, 749500002, 74951234563

и т.д.

Предположим, вы ищете записи, содержащие номера, начинающиеся на "345", за которыми следует не

менее одной, но не более шести цифр. В данном случае при поиске используйте следующее

регулярное выражение.

^345.{1,6}$

В результате поиска система отобразит записи, содержащие номера 3450, 3451111, 345888888 и т.д

18.3.3 Использование регулярных выражения для

преобразования номеров

Основной целью преобразования является приведение телефонных номеров к определенному

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

странице соответствующего правила

(например, Маршрутизация

- Начальные преобразования)

отметить флажок Рег.выр.

Приложения | 219

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

Описание полей в зависимости от метода приводится в таблице ниже:

Вариант

Поле

Назначение

Формат выражения

Префикс

Указывает число начальных

Простой набор символов

(цифр и

цифр номера (префикс) для

знаков * или #)

поиска

Пример: 88312

Регулярные

Совпадение

Регулярное выражение,

Выражение обязательно должно

выражения

определяющее правило

начинаться со знака ^ и заканчиваться

поиска номера

знаком $

Пример: ^(.*)$

Префикс

Удалить

Определяет число позиций с

1 или 2-значное число

начала номера, которые

Пример: 4

следует удалить

Регулярные

Замена

Регулярное выражение

Выражение обязательно должно

выражения

определяет ту часть номера,

начинаться со знака ^ и заканчиваться

которая будет заменена тем,

знаком $

что указано в поле

Пример: ^8831(.*)$

«Результат». При помощи

скобок можно создавать

группы в номере, для

дальнейшего использования в

поле «Результат».

Префикс

Добавить

Указывает, какой префикс

Простой набор символов

(цифр и

нужно добавить перед

знаков * или #) или пустое поле (не

номером оставшимся после

добавлять ничего).

преобразования

Пример: 99

Регулярные

Результат

Указывает, что нужно

Простой набор символов

(цифр и

выражения

вставить вместо

знаков * или #) и / или порядковые

первоначального номера.

номера логических групп вида $1, $2,

При помощи группы,

$3 или ${1}, ${2}, ${3} и т.п.

определённых в поле

Пример: 99$1

«Замена» скобками, можно

вставить часть

первоначального номера.

Таким образом, метод на основе префиксов предполагает использование простого набора цифр.

Например, для создания правила, при котором у всех номеров, начинающихся на 88312, необходимо

220 |

удалить первые 4 цифры и добавить префикс 99, в поле Префикс укажите 88312, в поле Удалить

укажите 4, а в поле Добавить укажите 99.

Регулярные выражения предполагают использование метасимволов и логических группировок и

позволяют создавать более сложные правила преобразования. Логические группировки используются

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

Результат номер группировки обозначается цифрами, начиная с единицы, и имеет вид $1, $2 т.п.

Выражения вида ${1} используются для указания группы, если после нее требуется добавление новых

символов, например, выражение ${1}34 означает, что после первой группы необходимо добавить

выражение "34".

Примеры использования регулярных выражений для преобразования номеров:

Задача:

Удалить из номера 123456789 префикс 1234

Поле Совпадение: ^ 1 2 3 4 5 6 7 8 9

Поле Замена: ^ 1 2 3 4 ( . * )

Поле Результат:

(удалить префикс 1234, предшествующий первой группе, составляющей остальную

часть номер а)

Пример преобразования:

123456789 ® 56789

Задача:

Заменить префикс 1234# в номере 1234#1234567 на префикс 0000#

Поле Совпадение: ^ 1 2 3 4 [ # ] 1 2 3 4 5 6 7 8 9

Поле Замена: ^ 1 2 3 4 [ # ] ( . * )

Поле Результат: 0 0 0 0 [ # ] $ 1

(заменить префикс 1234#, предшествующий первой группе, составляющей

остальну ю часть номер а, на пр ефикс 0000#)

Пример преобразования:

1234#1234567 ® 0000#1234567

Приложения | 221

Задача:

Ко всем номерам добавлять префикс 0000#

Поле Совпадение: ^ ( . * )

Поле Замена: ^ ( . * )

Поле Результат:

0000#$1

( весь номер опр еделить как гр у ппу под номер ом 1, вставить пр ефикс 0000# пер ед

группой под номером 1)

Примеры преобразования:

1234567 ® 0000#1234567

7654321 ® 0000#7654321 и т.д.

Задача:

У любых номеров, начинающихся с 1 или 7, удалять первые три цифры префикса и

заменять его цифрой 6

Поле Совпадение: ^ ( 1 | 7 ) . * $

Поле Замена: ^ . . . ( . * )

Поле Результат:

(удалить первые 3 символа, остальное использовать как группу под номером 1,

добавить 6 перед данной группой)

Примеры преобразования:

1234567 ® 64567

7654321 ® 64321 и т.д.

Задача:

У всех номеров, состоящих ровно из 10 цифр, заменить префикс 12 на префикс 87,

удалить любые символы на 5 и 6 позиции в оставшейся части номера.

Поле Совпадение: ^ [ 0 - 9 ] { 1 0 } $

Поле Замена: ^ 1 2 ( . . ) ( . . ) ( . * )

Поле Результат:

( в 10-значном номер е, начинающемся на 12, заменить пр ефикс 12 на 87 пер ед пер вой

группой из двух символов, удалить вторую группу, состоящую из 2 символов,

вставить тр етью гр у ппу , состоящу ю из оставшейся части номер а)

Примеры преобразования:

1234567899 ® 87347899

1233445566 ® 87335566 и т.д.

РТУ МОА 2.1.0. Практическое руководство администратора (2018 год) - часть 4