При переносе номера между операторами Беларуси приложение продолжает работать с тем же номером, но маршрут доставки и статус SMS нужно проверять по данным оператора связи. Для SMPP-подключения это означает три задачи: передавать номер в корректном формате, не выбирать маршрут только по коду и правильно разбирать DLR. В статье показано, как построить такую обработку, чтобы сообщения для OTP и уведомлений не зависели от старой принадлежности номера.
Почему код номера не показывает текущего оператора?
Первые цифры мобильного номера описывают исходный диапазон нумерации. После переноса абонент сохраняет номер, поэтому его код уже не подтверждает, через какую сеть нужно доставить SMS. Если приложение связывает код с конкретным оператором и выбирает SMPP-маршрут по этой таблице, для портированного номера оно получает устаревший результат.
Практическое правило простое: код страны и формат номера используйте для нормализации, а оператора и маршрут определяйте на стороне SMS-провайдера. Внутри приложения номер лучше хранить в одном стандарте, например с международным кодом страны и без пробелов, скобок и дефисов. Для Беларуси это означает единообразную запись с кодом страны, а не смесь локального и международного формата.
Не стоит удалять ведущий плюс без проверки требований конкретного SMPP-соединения. Один провайдер принимает номер в формате E.164, другой описывает собственные правила передачи TON и NPI. Эти параметры должны быть согласованы в настройках bind и проверены на тестовом номере.
Как передать сообщение на портированный номер через SMPP?
Приложение отправляет SMS на SMPP-соединение так же, как на обычный мобильный номер. Проверка MNP обычно скрыта внутри маршрутизации провайдера: система определяет актуальную сеть назначения и передаёт сообщение дальше. Поэтому разработчик не должен подменять операторский код или строить отдельную логику только для номеров, которые могли быть перенесены.
Полезно разделить процесс на четыре этапа:
- Привести номер к единому формату до постановки сообщения в очередь.
- Присвоить SMS внутренний идентификатор и сохранить связь с бизнес-событием.
- Передать сообщение через SMPP, указав подходящий тип сообщения и параметры доставки.
- Принять submit response и позднее обработать DLR, который относится к этому сообщению.
Если система отправляет OTP, номер и идентификатор попытки должны оставаться связанными между всеми повторными отправками. Иначе приложение не различит первый код, повтор после тайм-аута и сообщение, которое фактически доставили позже. Для разбора такой схемы пригодится материал как отправить OTP-код через SMPP с DLR и повторами.
Какие статусы DLR нужно учитывать?
DLR, или Delivery Receipt, сообщает результат обработки SMS на маршруте. Это отдельное SMPP-сообщение, которое приходит после submit response. Положительный ответ на submit означает, что SMS-протокол принял запрос, но он не подтверждает доставку на телефон. Финальный результат нужно искать в DLR.
Система должна извлекать из DLR как минимум идентификатор сообщения, статус, код ошибки при его наличии и время события. Формат текстового DLR зависит от подключения, поэтому парсер нельзя строить на одной фиксированной строке. Надёжнее сначала определить набор полей, затем привести значения к внутреннему справочнику статусов.
| Событие | Что означает для приложения | Действие |
|---|---|---|
| Принятие submit-запроса | Провайдер получил сообщение и вернул идентификатор | Сохранить ID и не считать SMS доставленной |
| Промежуточный статус | Сообщение ещё проходит маршрут | Оставить запись открытой и ждать финального результата |
| Доставка | Маршрут сообщил о доставке SMS | Закрыть попытку как успешную |
| Ошибка доставки | Сообщение не дошло или маршрут завершил попытку с ошибкой | Записать код, решить вопрос с повтором |
| Истёк срок ожидания | Финальный DLR не пришёл в установленное окно | Отделить тайм-аут от подтверждённой недоставки |
Повтор нельзя запускать при любой ошибке автоматически. Для OTP это может привести к нескольким действующим кодам, а для уведомления создать дубликаты. Политику повторов задают по типу сообщения и причине сбоя. Автоматизацию обработки ошибок и DLR можно сверить с практической схемой обработки ошибок SMPP и DLR.
Как проверить MNP-логику до подключения к боевой отправке?
Тестирование нужно проводить на нескольких сценариях: обычный номер, номер с разными вариантами записи, недоступный телефон и номер, для которого провайдер возвращает ошибку маршрута. Если есть тестовый номер с перенесённой принадлежностью, его добавляют отдельно. Сам факт успешной отправки на один номер не доказывает, что приложение корректно разбирает все DLR.
В тестовом журнале зафиксируйте исходный номер, нормализованное значение, SMPP message ID, время submit, полученный ответ и каждый DLR. Сверьте, что идентификатор из DLR находится в записи именно той попытки, которая создала сообщение. Это особенно важно при параллельной отправке: ответы могут приходить в другом порядке.
До запуска полезно проверить кодировку и длину SMS. Кириллица меняет правила сегментации сообщения, а конкатенированные SMS получают дополнительные параметры, которые также нужно контролировать в SMPP. Для такой проверки подойдёт SMPP-песочница с тестами SMS, DLR и конкатенации.
Как хранить результат доставки в бизнес-системе?
В базе лучше разделить сущность сообщения и сущность попытки отправки. Одно уведомление может получить несколько попыток, если приложение повторило отправку после временной ошибки. У каждой попытки должны быть собственные SMPP message ID, время и финальный статус.
Минимальная схема может выглядеть так:
- внутренний ID уведомления;
- номер в нормализованном формате;
- тип сообщения: OTP, статус заказа или другое уведомление;
- внутренний номер попытки;
- SMPP message ID;
- последний полученный статус DLR;
- код и текст ошибки, если провайдер их передал;
- время отправки и время последнего обновления.
Такой журнал помогает отделить проблему приложения от проблемы маршрута. Если submit проходит, но DLR содержит ошибку, разработчик смотрит параметры маршрутизации и ответ провайдера. Если DLR пришёл, но система не изменила статус, проблема уже в приёме, сопоставлении или парсинге сообщения.
Типичные ошибки при работе с MNP и DLR
- Выбор оператора по коду номера без учёта переноса.
- Смешивание локального и международного формата номера.
- Счёт submit response подтверждением доставки.
- Поиск сообщения только по номеру телефона вместо SMPP message ID.
- Повтор OTP после любого тайм-аута без ограничения числа попыток.
- Удаление исходного DLR после записи короткого статуса без сохранения кода ошибки.
Для технической отправки SMS в Беларуси MNP лучше воспринимать как задачу маршрута провайдера, а DLR — как источник финального результата, который приложение обязано разобрать и связать с конкретной попыткой. На этой основе можно собрать устойчивое SMPP-подключение без таблицы устаревающих операторских кодов.
3 шага, которые можно сделать на этой неделе:
- Привести все номера в базе к одному формату и убрать выбор маршрута по коду.
- Сохранить SMPP message ID для каждой отправки и написать отдельный обработчик DLR.
- Проверить на стенде успешную доставку, ошибку, тайм-аут и конкатенацию SMS.
