Release Notes

Функциональные изменения#

  • Улучшена интеграция метрик в портале: дашборды Grafana открываются в более предсказуемом и унифицированном виде.
  • Нормализованы названия дашбордов в меню портала для более понятной навигации.
  • Упрощен пользовательский сценарий работы с метриками: лишние фильтры времени/даты на стороне портала убраны, используется встроенная логика Grafana.
  • Выполнен первый этап нормализации отчетности и биллинга.
  • В отчетности введена явная классификация вызовов (attempt / detection / none|null), что повышает прозрачность и объяснимость начислений.
  • Подготовлен переходный контур для следующего этапа: текущие процессы сохранены, при этом модель данных приведена к более предсказуемому и проверяемому виду.
  • Добавлена экспериментальная интеграция с predial scorer в call-controller (оценка call/do_not_call до дозвона) с fallback-логикой без прерывания обслуживания при ошибке внешнего сервиса.
  • Улучшен сценарий обработки роликов AMD: добавлена автогенерация тишины перед промптами и стабильная ротация роликов в рамках профиля.
  • Реализован механизм “полной контрольной группы” для проверки ошибок второго типа
  • Подготовлен новый комплект публичной документации: выделены архитектурный, технический и пользовательский контуры с единой стартовой страницей навигации.
  • В публичную документацию добавлены и переработаны документы по архитектуре, отказоустойчивости, сайзингу, установке, обновлению, Docker, PostgreSQL, observability, SIP и API.
  • Добавлена документ Руководство по эксплуатации с описанием функциональности решения и справочными данными; документ будет поэтапно расширяться в следующих обновлениях.

Технические изменения#

  • Версия Grafana обновлена до 12.1.1.
  • Усилен подход к авторизации: доступ к Grafana в интеграции с порталом работает по портальной auth-политике.
  • В жизненный цикл дашбордов добавлена поддержка устаревших (deprecated) дашбордов, чтобы сохранять доступ к историческим данным при обновлениях.
  • В текущий релиз добавлен встроенный observability layer для pilot/prod-контуров: metrics, grafana, node_exporter, docker-health-exporter, log2file, мониторинг доступности БД и преднастроенные alert rules.
  • Частично рефакторена модель CDR: удалены лишние поля, детали обработки консолидированы в JSON (scpd_details), добавлены явные результаты интеграционного слоя (action,method, scpd_error, sip_response).
  • Адаптирован переходный слой статистики для биллинга: расчеты опираются на явную классификацию вызовов, а не на набор жестко зашитых значений результатов детекции.
  • Нормализован контракт ответов call-controller: sip_response возвращается только для терминальных действий (drop|connect), для continue поле не передается.
  • Расширен мониторинг call-controller: восстановлены и актуализированы метрики по внутренним сервисам (smartcpd, predial scorer) с разбивкой по результатам, ошибкам и таймингам (включая p50/p99), обновлены панели Grafana.
  • Обновлена и синхронизирована документация API/архитектуры (swagger + flow-документация) в соответствии с фактическим поведением сервиса.
  • Добавлен механизм full_control_group для контроля ошибок детекции на всех шагах обслуживания, а не только в одном LSTM-этапе.
  • Добавлен uuid4 идентификатор X-SCPD-TRACE-ID для каждого вызова.
  • Для opensips модуля exec увеличен размер pipe с 4096 байт до 10 килобайт. Требуется для обновления объемных конфигураций.
  • В поставку добавлена встроенная система исторического хранения логов log2file (включается через setup.sh): поддерживается ротация, хранение за период, поиск и выгрузка логов. При этом сохраняется возможность параллельно использовать docker logs / docker service logs для realtime-диагностики и корпоративные контуры логирования.
  • В поставку добавлен новый setup flow на базе smartcpd-docker-setup.sh и smartcpd-setup.sh: подготовка Docker и Docker Swarm, генерация stack-артефактов, role-specific node setup scripts и deployment теперь выполняются по единой схеме поставки.

Исправленные ошибки#

  • Исправлена проблема в разделе интегрированных метрик портала: вместо целевого дашборда открывалась главная страница Grafana.
  • Скорректирован расчет биллинга: обработка результатов вызовов стала более полной и согласованной с новой классификацией.
  • Нормализован API-контракт call-controller (v2): на всем пути обслуживания ответы стали более предсказуемыми, пустые значения больше не передаются и не затирают полезные поля, что повышает консистентность сервисных данных в CDR.
  • Исправлен сбор сервисных метрик smartcpd.
  • Добавлен sip_trace_id — уникальный идентификатор SIP-интеракции в рамках контура SmartCPD для сквозной трассировки вызова.
  • Исправлены таймеры подсчета времени в amd: устранено некорректное вычисление total_analyze_time, из-за которого могло происходить усечение проигрывания роликов.
  • Улучшена стабильность работы SIP-слоя
  • Проведены внутренние оптимизации обработки SIP-сообщений
  • Повышена устойчивость к граничным сценариям в сигнальном взаимодействии
  • Исправлена ошибка прохождения пользовательских заголовков
  • Исправлена ошибка указания количества повторных попыток в профиле amd для результата no_speech
  • Исправлено формирование биллинг отчета при смене лицензий:
    • указываются корректные даты применения тарифов
    • отображается количество попыток, детекций, и тарифицируемые единицы
  • Исправлена автоочистка локальной базы шаблонов Dejavu

Известные проблемы#

  • Недоступна кнопка Сохранить в разделе Редактирование профиля детекции при редактировании профиля:
    • Решение: принудительно изменить значение слайдера Максимальное время ожидания тишины, потом можно вернуть в прежнее значение.
  • Встроенный контур мониторинга и логирования в версии 5.3.0 поставляется как экспериментальная возможность:
    • канал доставки оповещений и фактическая обработка алертов остаются в зоне ответственности эксплуатации/инфраструктуры;
    • состав метрик и алертов может быть расширен в следующих обновлениях.

Совместимость#

  • SmartCPD — минимальная исходная версия 5.2.8. Перед обновлением исходная версия должна быть запущена, миграции БД завершены, работоспособность компонентов проверена.
  • Версии ниже 5.2.8 необходимо сначала обновить до 5.2.8, запустить и проверить по тем же условиям.
  • Поддерживаемые переходы см. в разделе «Обновление до 5.3.0».
  • docker версии 26+
  • containerd версии 1.7+
  • Debian-compatible и RHEL-compatible дистрибутивы Linux с версией ядра 5+, включая Debian 12 и RED OS 8
  • postgresSQL версии 14+

Изменения#

  • Выполняется миграция схемы БД. Перед обновлением рекомендуется выполнить резервное копирование.
  • Обновлены компоненты:
    • billing-server: 0.1.26 -> 0.1.36
    • config-server: 5.2.9 -> 5.3.0
    • db: 5.2.10 -> 5.3.0
    • grafana: 5.2.5 -> 5.3.0
    • metrics: 5.2.4 -> 5.3.0
    • portal: 3.2.1 -> 3.3.3
    • sip: 5.0.8 -> 5.1.2
    • smartcpd-analyzer: 4.3.1 -> 4.3.5
    • smartcpd-engine: 4.4.4 -> 4.5.1
    • docker-health-exporter: новый компонент, 1.0.0
    • log2file: новый компонент, 5.3.0

Обновление до 5.3.0#

Обновление с 5.2.11 и 5.2.12 не поддерживается.

С версий 5.2.8, 5.2.9, 5.2.10#

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

Из-за существенных изменений в структуре отчетности (cdr, stats, billing) процесс обновления БД может занять продолжительное время. Во время обновления БД обработку вызовов следует остановить.

При обновлении до 5.3.0 сервис billing-server выполняет обязательную миграцию схемы и данных БД. На первом этапе после запуска обновленного стека billing-server начинает миграционную процедуру, ожидаемое время до завершения критичной части — до 30 минут.

До завершения этого этапа не следует запускать вызовы через SmartCPD.

Готовность к запуску вызовов определяется по сообщению в логах billing-server:

MIGRATION ROUTINE COMPLETE

После появления данного сообщения необходимо принудительно перезапустить сервис amd:

docker service update --force scpd_amd

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

Дальнейшая миграция продолжается в фоновом режиме. Ориентировочная скорость обработки — около 15 миллионов записей за 30 минут. Этот этап выполняется с ограничением нагрузки на БД, поэтому полное завершение миграции может занять заметное время на крупных инсталляциях.

После завершения фоновой миграции начинается перенос данных из cdr в stats и последующий пересчет биллинга.

На период выполнения миграции возможны задержки:

  • в обновлении данных stats;
  • в расчете и отображении биллинга.

Дата формирования

Backward Руководство пользователя
Powered by Altuera