Крупное обновление системы ведения записей о вызовах CDR в 3CX.

Вслед за вчерашним релизом V20 Update 6 Alpha, мы хотели бы рассказать, как работает появившаяся в этом релизе новая технология CDR. Мы упростили формат CDR, объединив все в одну таблицу: cdr_output. В этом посте мы разберем старую структуру, покажем новый дизайн и расскажем о технических преимуществах нового подхода.

Старая схема: фрагментация данных и медленная работа

Раньше данные CDR в 3CX хранились в четырех таблицах: cl_calls, cl_participants, cl_party_info и cl_segments. В каждой таблице хранились свои элементы вызова: время, участники, маршруты. Чтобы собрать информацию о вызове, приходилось использовать сложные SQL-запросы JOIN. Такая схема с несколькими таблицами нагружала систему и замедляла создание отчетов. Для облачной аналитики или отчетов в реальном времени такая структура не подходит.

Новый подход: cdr_output

Мы переработали этот механизм и создали решение с одной таблицей cdr_output, где собраны все данные о вызовах. Время, участники, маршруты, результаты – все хранится в одной структуре – больше не нужны JOIN-запросы. Однако JOIN используется при получении данных о записях разговорах, которые хранятся в отдельной таблице cdr_recordingsout. 3CX и ранее могла поддерживать тысячи пользователей, а новая компактная архитектура еще лучше ускоряет запросы, адаптируя 3CX к системам облачной аналитики. Качественный пересмотр структур данных обеспечивает точность и производительность решения.

Улучшение 1: Все данные в одной таблице

Раньше: Сложные JOIN-запросы в нескольких таблицах тормозили анализ вызовов.

Теперь: Таблица cdr_output содержит все данные: источник, назначение, время, результат. Плоская и простая структура – BI-аналитикам легко отслеживать прохождение вызовов.

Почему это важно:

  1. Быстрые запросы: Вместо сложных запросов к нескольким таблицам – быстрые запросы к одной. Плавное масштабирование, независимо от объема данных.
  2. Готовность к облаку: Легко интегрируется с “озерами данных” и BI-инструментами – без дополнительной подготовки.
  3. Преимущества для аналитиков: Прохождение вызова понятно и легко отслеживается – экономия вашего времени

Технические преимущества: Индексирование по cdr_id и call_history_id ускоряет работу PostgreSQL, реализуя моментальный поиск даже в больших наборах данных. Сохранение call_history_id в таблице снижает нагрузку на SQL, повышает скорость и уменьшает избыточность данных.

Улучшение 2: Полная история в каждой строке

Раньше: Скудные метаданные не позволяли точно понять – почему вызов не прошел? Каков контекст? Кто кому перевел звонок?

Теперь: Таблица cdr_output содержит широкий набор атрибутов:

  • termination_reason (например, “cancelled”, “dst_participant_terminated”)
  • termination_reason_details (например, “forward_all”, “completed_elsewhere”)
  • creation_method (например, “route_to”, “divert”)
  • creation_forward_reason (например, “polling”, “busy”)
  • continuation_reason (например, “polling”, “forward_all”)

Почему это важно:

  • Полная ясность: Каждая строка – полная история звонка, больше не нужно собирать информацию по частям.
  • Глубокий анализ: Легко рассчитывать KPI, например, процент сброшенных вызовов или статистика очередей.
  • Понятное завершение: Сразу видно, как, почему, когда и кто завершил вызов.

Технические преимущества: Атрибут termination_reason_details позволяет проводить точный анализ (например, с помощью SQL GROUP BY в Grafana или Power BI). Идентификатор cdr_id в стандартном формате GUID (например, 00000000-01db-87c1-1bab-07aa0000000d) позволяет BI-инструментам правильно определять дату/время и порядок вызовов без лишних усилий. Теперь понятно, как вызов начался, проходил и завершился.

Улучшение 3: Понятно, кто кому звонит

Раньше: Роли участников были неясно определены. Чтобы понять, кто источник и получатель вызова, требовалось сопоставлять данные из разных таблиц, использовать вложенные операции и множество JOIN-запросов. Все это снижало производительность.

Теперь: Таблица cdr_output устраняет путаницу со сложными JOIN-запросами с помощью четко разделенных полей:

  • source_participant_id (для отслеживания)
  • source_participant_phone_number (например, “+1305305305”)
  • destination_dn_name (например, “Dana White”)
  • Флаги, такие как source_participant_is_incoming и destination_participant_is_already_connected.
Source New Features
Participant New Features
“source_participant_id” “destination_participant_id”
“source_entity_type” “destination_entity_type”
“source_dn_number” “destination_dn_number”
“source_dn_type” “destination_dn_type”
“source_dn_name” “destination_dn_name”
“source_participant_name” “destination_participant_name”
“source_participant_phone_number” “destination_participant_phone_number”
“source_participant_trunk_did” “destination_participant_trunk_did”
“source_participant_is_incoming” “destination_participant_is_incoming”
“source_participant_is_already_connected” “destination_participant_is_already_connected”

Почему это важно:

  • Точное сопоставление: Направление вызова теперь прослеживается от источника к получателю – анализ упростился.
  • Обработка сложных сценариев: Легко отслеживаются потоки в нескольких очередях, двунаправленные транки и многоуровневые переводы в рамках одной схемы.

Технические преимущества: Логические флаги состояния похожи на размерное моделирование в хранилищах данных. Это оптимизирует производительность выражений WHERE. Стандартный формат UUID для идентификаторов участников обеспечивает интеграцию с BI-платформами, сразу показывая все этапы вызова.

Улучшение 4: Точность временных меток

Раньше: Таблица cl_calls предлагала только базовое время начала/окончания; остальные данные были разбросаны по cl_segments.

Теперь: Таблица cdr_output предоставляет три точные временные метки: cdr_started_at, cdr_ended_at, cdr_answered_at.

Почему это важно:

  • Четкие метрики: Точное время от звонка до ответа, до секунды.
  • Простота аналитики: Расчеты в одной таблице заменяют агрегацию данных из нескольких таблиц.

Технические преимущества: Временные метки в формате UTC (+00) обеспечивают согласованность данных в разных регионах — это важно для глобальных облачных развертываний, интегрированных инструментами Snowflake или BigQuery. Идентификатор cdr_id в формате GUID связывает эти метки с этапами вызова, позволяя BI-инструментам “из коробки” понимать последовательность и длительность звонков. Никаких доработок не требуется.

Улучшение 5: Дальнейший рост

Раньше: Структура из нескольких таблиц была негибкой — новые функции приводили к разрастанию схемы.

Теперь: cdr_output – это одна расширяемая таблица: добавьте столбец – система адаптируется сразу.

Почему это важно:

  • Масштабируемость для будущего: Отчетность растет вместе с развитием 3CX – без сложностей, связанных с реляционной структурой.
  • Операционная эффективность: Одну таблицу легче индексировать, реплицировать или разделять — она сразу разработана для облака.

Технические преимущества: Флаги, такие как processed и migrated, упрощают конвейеры данных, обеспечивая отличную интеграцию с Apache Kafka, AWS Athena, Kinesis или Google BigQuery. Связь по call_history_id внутри таблицы ускоряет запросы, связанные с вызовами. Сохраняется высокая производительность и компактность данных.

Следующий шаг – подготовка данных для облака

Мы превратили громоздкую систему CDR в современную, масштабируемую таблицу отчетов о вызовах. Наши тесты показали, что запросы выполняются до 10 раз быстрее — меньше JOIN-запросов, больше полезных данных.

Установка V20 Update 6 Alpha

Чтобы испытать новые функции, обновитесь до V20 Update 6 Alpha.

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