Release Notes v6.0.3

Перейти к релизу

SmartCPD 6.0.3 — исправляющий релиз линейки 6.0. Его можно установить поверх 6.0.X либо использовать вместо них при переходе с поддерживаемых версий 5.x. Промежуточная установка предыдущих релизов 6.0 не требуется.

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

  • [#25341] Исправлена задержка построения биллинговых отчётов при большом объёме вызовов.

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

В биллинге:

  • Изменена структура хранения данных в БД биллинга для агрегирования суточных данных и корректной обработки поздних поступлений («late arrivals»).
  • Отчёт детализации теперь показывает детализацию вызовов без учёта их покрытия включёнными в абонентскую плату вызовами.
  • Уточнён расчёт потребления абонентской платы и включённых услуг за текущий или последний день тарифного окна: день учитывается только при наличии назначения. Ранее текущий день учитывался независимо от наличия назначения, поскольку закрытие тарифного окна подтверждается только на следующий день.
  • Добавлены дневные агрегации для ускорения построения биллинговых отчётов.
  • Исправлен порядок отображения событий в истории: все операции с лейблами за сутки теперь предшествуют операциям с тарифными окнами; ранее они отображались после них.

Совместимость и обновление#

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

  • SmartCPD 6.0.X, 5.2.12, 5.3.2 (см. процесс обновления).
  • Docker версии 26+.
  • Debian 12, РЕД ОС 8 (проверены для линейки 6.0).
  • PostgreSQL версии 14+.

Состав обновления#

Относительно 6.0.2 обновлены следующие образы:

СервисОбраз:версия
billing-serverbilling-server:6.0.3
portal-frontendportal-frontend:6.0.3

Остальной состав поставки соответствует 6.0.2.

Обновление с версий 6.0.x#

Поддерживаются прямые переходы:

  • 6.0.X → 6.0.3.

Перед обновлением с 6.0.0, 6.0.1 или 6.0.2 необходимо выполнить требования раздела «Обновление 6.0.3», включая обязательное резервное копирование БД либо биллинг-сущностей. При установке с нуля эти действия не требуются.

Выполните deployment из поставки 6.0.3 с автоматической генерацией конфигурации:

./smartcpd-setup.sh deploy

Setup автоматически сформирует необходимую конфигурацию; отдельный запуск generate не требуется. Будут обновлены только затронутые сервисы. При переходе с более ранних релизов 6.0 также применяются изменения промежуточных релизов.

При обновлении с 6.0.0 или 6.0.1 меняются образы сервисов обработки вызовов, что затрагивает трафик. Рекомендуется проводить такое обновление в нерабочее время.

Обновление с версий 5.x#

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

Примеры путей обновления:

  • 5.2.2 → 5.2.8 → 5.2.12 → 6.0.3.
  • 5.3.0 → 5.3.2 → 6.0.3.

При переходе с 5.2.12 или 5.3.2 применяются требования миграции на линейку 6.0; промежуточная установка предыдущих релизов 6.0 не требуется. Порядок обновления и требования к миграции описаны в документе «Обновление SmartCPD».

На каждой промежуточной версии необходимо запустить SmartCPD, дождаться завершения миграций БД и проверить работоспособность компонентов.

Ограничения и особенности#

Миграция данных биллинга при обновлении#

При запуске billing-server после обновления с 6.0.0, 6.0.1 или 6.0.2 выполняется начальная агрегация данных. До завершения миграции healthcheck показывает успешный статус, а все API-запросы возвращают 503 Service Unavailable — это штатное поведение. После завершения миграции автоматически запускаются агрегация и обработка новых записей, API становится доступен. Если перезапустить контейнер до завершения миграции, её промежуточные данные сбрасываются и миграция начинается заново. При установке с нуля этот миграционный проход не требуется.

Длительный первый запуск CDR collector при обновлении с 6.0.0#

При обновлении с 6.0.0 первый запуск cdr-collector может занять существенное время из-за создания индексов: в тестировании на базе примерно 200 млн записей CDR — около 12 минут. Длительность зависит от объёма данных и производительности БД.

Стартовый период healthcheck увеличен до одного часа; контейнер становится healthy после первой успешной проверки. Дождитесь завершения миграций по логам cdr-collector.

Контроль тарифов для облачных назначений#

Для облачных назначений наличие доступного тарифа у тенанта необходимо контролировать вручную, включая создание тенанта, изменение доступности тарифов и окончание срока их действия. При допуске новых вызовов платформа не проверяет наличие тарифа в биллинге и не блокирует вызовы из-за его отсутствия. Если на момент начала вызова не найден применимый тариф ни по назначению вызова, ни по основному назначению default, расчетный факт сохраняется с ошибкой no_effective_tariff, без примененного тарифа и со стоимостью 0. Вызов остается без рассчитанной стоимости; последующее появление тарифа не запускает автоматический пересчет этого факта.

Это ограничение ручного контроля не относится к тарифному покрытию валидной файловой лицензии V3: license-server проверяет, что хотя бы один тариф присутствует, а интервалы тарифов без разрывов покрывают весь срок действия лицензии. При нарушении этого правила лицензия признается невалидной и не предоставляет права на новые вызовы. Если другой действующей лицензии или применимой cloud policy нет, новые вызовы не допускаются. Допуск по cloud policy относится к облачному сценарию и требует ручного контроля тарифов, описанного выше.

Кодировка CSV-файлов разметки#

Загрузка разметки из CSV поддерживает только UTF-8. Файлы в других кодировках, включая Windows-1251, необходимо пересохранить в UTF-8 до отправки; автоматическое перекодирование не поддерживается.

Внешний Audit API#

Внешний Audit API в текущем релизе доступен только на уровне платформы. Tenant-scoped авторизация и получение журнала аудита в контексте клиента пока не поддерживаются.

Timezone приложения и БД#

В SmartCPD 6.0.1 timezone запуска контейнеров (SMARTCPD_TZ) должна совпадать с timezone сервера БД (SMARTCPD_DB_TZ). Setup проверяет это соответствие и отклоняет генерацию или развертывание конфигурации с разными значениями, поэтому установку и изменение конфигурации необходимо выполнять через smartcpd-setup.sh.

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

  • [#25183] Full Control Group. Механизм Full Control Group в данном релизе не работает.
  • [#25373] Метрики дашборда SIP-вызовов. Метрики Unavaialable и SCPD Error в дашборде SIP-вызовы работают некорректно.

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

Powered by Altuera