Для международной отправки SMS через SMPP нужно заранее согласовать формат номера, кодировку сообщения, значения TON/NPI и обработку DLR. Один и тот же запрос может дать разные результаты на разных направлениях: сообщение примут, отклонят или доставят без понятного статуса, если приложение неверно разобрало ответ. В статье разберём рабочую схему подключения, покажем порядок проверки и перечислим ошибки, которые чаще всего мешают доставке из Беларуси на зарубежные номера.
Что нужно подготовить до подключения SMPP?
Сначала составьте список направлений, на которые приложение будет отправлять сообщения. Страна назначения влияет на формат номера, доступные маршруты и содержание отчёта о доставке. Для одного проекта это могут быть только белорусские номера и несколько стран, для другого — пользователи из разных регионов. Не стоит начинать с абстрактного «международного трафика»: перечислите страны и назначение сообщений для каждой из них.
Затем определите тип трафика. Код подтверждения входа, уведомление о статусе заказа и сервисное сообщение требуют разной логики повторной отправки. Для OTP важны короткий срок жизни и защита от повторов, для уведомления о заказе главным становится понятный статус доставки. На стороне SMPP это отражается в параметрах сообщения, обработке ответов и правилах повторной попытки.
Проверьте технические параметры подключения:
- адрес и порт SMPP-сервера;
- логин и пароль для bind;
- тип подключения: transmitter, receiver или transceiver;
- разрешённые IP-адреса, если провайдер использует сетевое ограничение;
- лимит одновременных соединений и скорость отправки;
- формат source_addr и правила для имени отправителя;
- период отправки enquire_link и реакцию на разрыв соединения.
Если сервер доступен только через динамический IP, способ подключения нужно согласовать отдельно. В таком случае пригодится разбор настройки SMPP при динамическом IP в инструкции по подключению SMPP при динамическом IP. Для постоянного высокообъёмного трафика лучше сначала получить тестовые параметры и проверить их на небольшом числе сообщений.
Как выбрать TON и NPI для международного номера?
TON и NPI описывают, как SMS-центр должен трактовать адрес. TON расшифровывается как Type of Number, NPI — Numbering Plan Identification. На практике разработчик задаёт эти поля для source_addr и destination_addr, а SMPP-провайдер использует их при маршрутизации сообщения.
Для международного номера обычно требуется передавать destination_addr в формате E.164: знак «плюс» убирают, остаются код страны и номер абонента. Например, приложение может передать номер как последовательность цифр с кодом страны. Однако конкретное сочетание TON и NPI зависит от интерфейса провайдера. Поэтому нельзя без проверки копировать значения из примера для одного маршрута в другой.
Частая схема выглядит так: для международного назначения используют international TON и ISDN-план нумерации. В библиотеке SMPP эти значения могут называться по-разному, поэтому смотрите не только на имя константы, но и на числовое значение. Для source_addr с буквенным именем отправителя настройки часто отличаются от настроек цифрового номера.
| Поле | Что проверяет разработчик | Типичная причина ошибки |
|---|---|---|
| destination_addr | Код страны, отсутствие лишних символов, полный номер | Передача локального формата вместо международного |
| dest_addr_ton | Соответствие типа номера правилам маршрута | Использование national вместо international |
| dest_addr_npi | План нумерации, согласованный с провайдером | Значение по умолчанию не подходит для направления |
| source_addr | Разрешённый sender ID и его длина | Передача имени, которое не разрешено на маршруте |
Полезно записывать в журнал не только исходный номер, но и нормализованное значение, которое приложение реально отправило в submit_sm. Тогда легко увидеть, где возникла ошибка: при вводе номера, преобразовании формата или сборке PDU.
Как отправлять кириллицу и другие символы?
Кириллица обычно требует отдельной настройки data_coding. Нельзя передавать русскоязычный текст в кодировке, которую получатель или маршрут не ожидает. В результате абонент увидит вопросительные знаки, обрезанное сообщение или набор непонятных символов.
Для UCS-2 приложение формирует текст в нужном формате и передаёт соответствующее значение data_coding. UTF-8 нельзя выбирать автоматически только потому, что его использует веб-приложение: SMPP-маршрут может ожидать другой вариант. До запуска проверьте короткое кириллическое сообщение, латиницу, цифры и символы вроде кавычек или дефиса.
Кодировка влияет и на длину SMS. Если сообщение превышает вместимость одного сегмента, библиотека должна корректно собрать составное SMS, добавить UDH и сохранить порядок частей. При ошибке в UDH получатель получит несколько отдельных сообщений или текст с повреждёнными символами. Практическая схема проверки кодировок и длины разобрана в материале «Как отправлять кириллицу в SMPP: UCS-2, UTF-8 и длина SMS».
Для международного трафика задайте ограничение длины на уровне шаблона. Оставляйте запас под переменные: имя, номер заказа, код или ссылку. Перед отправкой приложение может выполнить тестовую оценку количества сегментов и записать результат в лог вместе с data_coding.
Как обрабатывать DLR и ошибки доставки?
DLR, или delivery receipt, — отчёт, который сообщает состояние сообщения после submit_sm. Ответ о принятии запроса SMPP ещё не означает, что абонент получил SMS. Приложение должно разделять как минимум принятие сообщения системой, попытку доставки и финальный статус.
Сохраните для каждого сообщения собственный идентификатор message_id, который возвращает submit_sm_resp. Затем сопоставляйте его с идентификатором из deliver_sm или другого канала отчётов. На некоторых маршрутах формат идентификатора может отличаться, поэтому в базе и обработчике лучше предусмотреть нормализацию.
| Событие | Что означает | Действие приложения |
|---|---|---|
| submit_sm принят | Провайдер получил запрос | Сохранить message_id и время отправки |
| delivered | Маршрут сообщил о доставке | Закрыть попытку отправки |
| expired | Истёк срок действия сообщения | Не повторять автоматически без правила сценария |
| undeliverable | Доставка невозможна | Зафиксировать причину и проверить номер или маршрут |
| rejected | Запрос отклонён системой или маршрутом | Проверить параметры, sender ID и ограничения |
Статусы DLR нельзя обрабатывать одной веткой «успех или ошибка». Для OTP повтор после временной сетевой ошибки отличается от повторной отправки при недоступном номере. При разборе DLR учитывайте stat, err, message_id и текстовый комментарий, если провайдер его передаёт. Автоматическую обработку SMPP-ошибок и DLR можно сверить с практической схемой обработки ошибок SMPP и DLR.
Какие ошибки чаще всего мешают международной отправке?
- Приложение передаёт номер в локальном формате, хотя маршрут ожидает международную запись.
- TON и NPI заданы одинаково для всех стран без согласования с SMPP-провайдером.
- Кириллица отправляется с неверным data_coding, а тест проводят только на латинском тексте.
- Разработчик считает submit_sm_resp подтверждением доставки абоненту.
- Система повторяет сообщение после любого отрицательного DLR и создаёт дубли.
- Лог не сохраняет message_id, поэтому статус невозможно связать с исходной попыткой.
Для белорусского бизнеса, который отправляет SMS за границу, настройку лучше проверять по отдельным направлениям: номер, TON/NPI, sender ID, кодировка и DLR. Сначала протестируйте один короткий текст и один сценарий, затем добавляйте страны и объём. На этой базе проще подключить технический канал через SMPP, сохранить контроль над статусами и быстро найти ошибку в журнале.
