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-server | billing-server:6.0.3 |
portal-frontend | portal-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 deploySetup автоматически сформирует необходимую конфигурацию; отдельный запуск 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-вызовы работают некорректно.