IOSOR

IOSOR База знаний

Восстановление DID: работа сообщений не равна статусу «Activated»

Почему статус «Activated» после разблокировки DID не означает полную готовность messaging, и как проверить тракт SMS перед повторным назначением номера.

Неделя восстановления DID: возврат сообщений не равен бейджу Activated.

Ошибка доверия бейджам статуса при восстановлении DID

Когда телефонный номер проходит этап заморозки или восстановления, панель управления часто отображает статус «Activated». Однако изменение статуса на уровне реестра не гарантирует, что обмен SMS работает корректно. Для владельцев white-label CPaaS критически важно отличать базовую регистрацию номера от реальной проходимости сообщений. Если направить трафик клиентов сразу после появления статуса «Activated», есть риск столкнуться с потерей OTP и сбоями вебхуков.

После инцидентов, описанных в материале Инцидент с DID: сбои обмена сообщениями не связаны с наличием, системы автоматического выделения завершают API-рукопожатия раньше, чем обновятся маршрутные таблицы SMS-центров. Чтобы гарантировать стабильность, платформа должна протестировать тракт сообщений до назначения номера пользователям.

Почему «Activated» не гарантирует прохождение SMS-трафика

Статус активности означает только наличие записи номера в вашем аккаунте. Он не подтверждает доставку входящих вебхуков и прохождение исходящих сообщений через фильтры.

  • Молчание входящих вебхуков: Номер принимает SMS, но шлюзы не отправляют POST-запросы на ваш URL.
  • Сбои исходящего канала: Запрос на отправку принимается, но DLR возвращает ошибку.
  • Задержка профилей: Регистрация 10DLC или брендов может отставать от активации самого номера.

Перед возвратом номеров в продакшен сверьтесь с гайдом готовность DID-сообщений до production, чтобы убедиться в правильности привязки профилей и правил маршрутизации.

Протокол проверки: тесты входящих, исходящих и DLR

Безопасное повторное назначение требует трехэтапного цикла проверки:

  1. Синтетический входящий тест: Отправка тестового SMS с контрольного номера для проверки вебхука.
  2. Проверка исходящего канала: Отправка SMS с ожиданием финального статуса DLR (Delivered).
  3. Анализ задержки: Проверка времени доставки перед полным назначением номера клиенту.

Автоматизация этих проверок предотвращает жалобы пользователей и исключает преждевременные списания до того, как наступит Второй месяц DID: полный MRC при смене календаря UTC для долгосрочного использования.

Таблица: Статус в системе и реальное состояние SMS-тракта

Статус системы Входящий Webhook Исходящий SMS Реальное состояние
Activated Сбой Не проверен Небезопасно для Assign
Activated Подтвержден Ожидает DLR Этап тестирования
Activated Подтвержден Доставлено Готов к назначению
Suspended Сбой Заблокирован Заморожен

Финансовые удержания, баланс и лимиты аккаунта

Управление номерами работает по принципу Just-In-Time (JIT) выделения с мгновенным удержанием средств (prepaid hold). При возврате номеров в рабочее состояние баланс системы должен обеспечивать проведение проверок без риска блокировки.

IOSOR использует порог баланса USD 20 prepaid floor для защиты от внезапных остановок сервиса во время проверок. Кроме того, аккаунты, приближающиеся к мягкому аудиту около USD 1,000/month, проходят автоматическую проверку маршрутов для сохранения высокой проходимости сообщений.

Начните работу с IOSOR для безопасного восстановления номеров

Когда заморозка снята и бейдж пишет Activated, не отдавайте номер арендаторам. Отправьте синтетический inbound и ждите webhook. Отправьте один outbound и ждите терминальный DLR. Только потом re-assign. Выгрузите оба доказательства с окном восстановления — один Activated не messaging-back.

Итог IOSOR

Неделя восстановления: messaging-back — проверка пути, не переворот бейджа.

Делайте: inbound webhook и outbound DLR до повторного assign. Не делайте: возвращать арендаторов на Activated после заморозки.

Был ли материал полезен?

Связанные гайды