Шаг 17. Потоковая статистика и записи разговоров

Система сохраняет информацию обо всех звонках, которые происходили. Каждый звонок внутри системы вне зависимости от того, кто выступает абонентом, обслуживается функциональной ролью B2BUA, причем один звонок обслуживается единственным её экземпляром. Функциональная роль B2BUA трассирует весь воркфлоу каждого звонка. По звонку генерируются десятки CDR-событий (Call Detail Record). Каждое событие имеет большое количество контекстных атрибутов. Вот список основных CDR-событий|:

  • Входящий звонок.

  • Результат маршрутизации в домене.

  • Инициация диалога.

  • Начало вызова форка.

  • Неудачный результат вызова форка.

  • Успешный результат вызова форка.

  • Отмена вызова форка.

  • Отмена входящего вызова.

  • Перехват входящего вызова.

  • Начало диалога.

  • Применение правила записи и правила хранения.

  • Постановка на удержание.

  • Снятие с удержания.

  • Трансляция запроса REFER (перевод на номер и перевод с подменой).

  • Привязка переводящего диалога (перевод с подменой).

  • Привязка подменяющего переведенного диалога (перевод с подменой).

  • Миграция звонка в связи с падением медиа-сервера.

  • Завершение диалога.

  • Падение диалога.

  • Окончание звонка.

Каждое событие в момент генерации отправляется:

  1. в локальный лог-журнал cdr;

  2. в функциональную роль SQ (функциональная роль брокера сообщений для внутренних нужд);

  3. в функциональную роль WSSubscr (функциональная роль брокера сообщений для внешних подписчиков);

  4. в контекстный сценарий звонка.

b2bua_eventing

Лог-журнал CDR

Лог-журнал cdr представляет собой текстовый файл, относящийся к конкретной дате. Каждая строчка содержит событие и его базовые атрибуты. Он служит для быстрого анализа истории администратором, имеющим доступ к файловой системе серверов или к API мониторинга (для скачивания лог-журналов). Этот режим работает даже тогда, когда все остальные не настроены или недоступны. Файлы лог-журналов автоматически разбиваются на порции по 100 МБ и по датам. Они автоматически удаляются системой по истечению короткого периода хранения (2 дня), либо при превышении количества файлов в каталоге (20 файлов).

Функциональные роли SQ, CDR, Mixer и серверы реляционных баз данных CDR-DB

Функциональная роль SQ – брокер внутренних сообщений – получая сообщения гарантирует сохранение их очередности и доставку подписчикам. Резервируется в режиме Active-Passive, однако может разделяться на группы для обработки больших потоков. Каждая такая группа имеет распределенную объектную базу данных для хранения событий до момента их доставки подписчикам очередей. Применяется ограничение на количество элементов в объектной БД – 100 тысяч, после чего устаревающие данные начинают удаляться. Подписчиками очередей SQ являются функциональные роли CDR и Mixer.

Очереди настраиваются в конфигурации. Там же настраиваются их подписчики. Каждая очередь SQ имеет паттерн, определяющий категорию размещаемых в ней сообщений. Каждое сообщение отправляется во все очереди SQ с соответствующим паттерном (вне зависимости от того в каких группах SQ они сконфигурированы). Так, все экземпляры функциональной роли B2B на сайте отправляют свои CDR-события в очередь с паттерном "callevents". Получателем этих сообщений могут выступать экземпляры функциональной роли CDR на этом же сайте.

Функциональная роль CDR производит выборку событий из очередей SQ и переносит их на сервер реляционных баз данных CDR-DB. Резервируется в режиме Active-Passive, может масштабироваться с помощью групп (группы при этом могут конкурировать при выемке событий из одних и тех же очередей, либо разделять работу с разными очередями). Выемка событий производится порциями до 2000 штук. Выбранные события размещаются в собственной распределенной по группе объектной БД, тем самым обеспечивая гарантированную доставку до реляционной CDR-DB.

Функциональная роль CDR получает события только из очередей SQ (на схеме выше для упрощения понимания сути отображено, что поставкой событий занимается также функциональная роль Mixer, однако на деле это также производится посредством функциональной роли SQ, а именно другой ее очереди с другим паттерном). Mixer в свою очередь тоже получает данные из той очереди SQ, куда их размещает CDR. Это три разных очереди с тремя разными паттернами:

sq_cdr_mixer_patterns

Экземпляры функциональной роли Mixer являются конкурирующими подписчиками SQ на очередь c паттерном "mixevents", которая наполняется экземплярами функциональной роли CDR на основе CDR-событий, связанных с окончанием звонка. Им последовательно производится:

  1. выемка очередного события,

  2. обнаружение медиа-сервера MG, обслуживавшего связанный с событием звонок,

  3. копирование файлов с сервера MG на локальный диск,

  4. аудио-микширование и упаковка в один файл с помощью встроенного высокопроизводительного приложения rtx_mixer,

  5. размещение результата в файловом хранилище для записей разговоров,

  6. отправка события о завершении упаковки с информацией о пути хранения в очередь SQ c паттерном "mixresult".

Результатом микширования является моно или стерео аудиофайл в кодеке MP3, G.711 или G.610 – кодек и битрейт настраиваются в опциях функциональной роли. Целевая задача по микшированию аудио- (и видео-) требовательна к ресурсам. Легко можно дать такую нагрузку на сайт, что количество трафика, подлежащего микшированию и упаковке, превысит производительность одного сервера. Поэтому функциональная роль Mixer резервируется и масштабируется в режиме Active-Active. В конфигурации плотно нагруженной системы целесообразно для функциональных ролей Mixer предусматривать отдельные серверы, аналогично функциональным ролям MG.

Файловое хранилище для записей разговоров – это внешний сетевой диск, либо S3-хранилище, точка доступа к которому определяется в конфигурации. В случае, если файловое хранилище оказывается недоступным, Mixer продолжает работу, складируя результаты на локальном диске. При восстановлении доступа к хранилищу файлы автоматически переносятся. Поэтому для функциональной роли Mixer помимо производительного процессора важно наличие свободного места на локальном диске.

Реляционная база данных CDR-DB подключается к сайту в конфигурации. Функциональная роль CDR требует PostgreSQL в качестве сервера баз данных (аналогично Domain DB). Может быть настроено несколько точек подключения к ферме серверов баз данных, чтобы обеспечить бесперебойную поставку событий. Ферму серверов баз данных CDR-DB следует располагать на каждом сайте, чтобы итоговая система удовлетворяла требованиям к доступности полного функционала на сайте, а именно обеспечивала сохранение истории событий на сайте в условиях работы без связи с другими сайтами системы.

При старте функциональная роль CDR обеспечивает проверку, создание и обновление структуры CDR-DB на подключенном сервере баз данных. Все CDR-события о звонках сохраняются в базу данных common. Однако на следующих шагах будут рассмотрены и другие события, имеющие отношение к конкретному домену – для таких групп событий функциональная роль CDR создает и поддерживает доменные базы данных в CDR-DB. У каждой БД существует учетная запись для чтения, доступная администратору соответствующего домена (мастер-домена для базы данных common).

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

Работоспособность критических коммуникационных процессов системы не зависит от доступности и производительности CDR-DB. Однако от этого зависит функция сохранения истории событий и смежные с ней функции: доступ к журналам звонков, прослушивание записей разговоров, построение отчетов на основе истории звонков.

В общем случае с учетом резервирования и масштабирования это направление размещения событий можно представить на следующей схеме

sq_cdr_mixer_db

Функциональная роль WSSubscr

Функциональная роль WSSubscr введена для отправки событий внешним подписчикам. Подписка осуществляется через HTTP(s) или WebSocket API функциональной роли WS. Подписка может быть создана только на время, и продлевается. Подписка устанавливает категории и типы интересующих событий, а также фильтр по связанным с событием учетным записям пользователей.

Так например, некоторая внешняя система может произвести две подписки на события callevents:

  1. типы событий dlg_start и dlg_stop в звонках, связанных с пользователем Алисой.

  2. типы событий any (все события категории callevents), связанных с пользователем Борисом.

В результате этого функциональная роль WSSubscr будет уведомлять внешнюю систему о каждом звонке Алисы и Бориса, причем по звонкам Бориса будет отправляться весь ряд событий, а по звонкам Алисы только dlg_start и dlg_stop. При этом, если вдруг произойдет разговор Алисы и Бориса, то события dlg_start и dlg_stop не будут дублироваться.

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

Контекстный сценарий звонка

Рядом с каждым звонком на том же сайте может быть активен сценарий контекста звонка, обрабатывающий все события. Этот сценарий создается администратором мастер-домена. Что может делать сценарий? Всё, что настроил администратор. Например, он может обрабатывать события самостоятельно. Либо инициировать запуск контекстных сценариев в дочерних доменах, а затем пересылать им события. А те в свою очередь создаются администраторами доменов, и могут, например, отправлять события во внешние системы, соблюдая какие-то кастомные протоколы.

Table 1. Используемые термины
Термин Определение

CDR-событие

!

SQ

!

CDR

!

Mixer

!

rtx_mixer

!

CDR-DB

!

История событий на сайте

!

База данных common в CDR-DB

!

Потоковое сохранение событий

!

Партиции таблиц БД (partition)

!

WSSubscr

!

Контекстный сценарий звонка

!