Как настроить TON/NPI в SMPP для SMS в Беларуси

TON и NPI в SMPP описывают, как шлюз должен воспринимать адрес отправителя или получателя. Ошибка в этих полях иногда приводит к отклонению сообщения, неверной маршрутизации или неполному DLR. Для МТС, A1 и life:) нельзя без проверки подставлять универсальные значения: итоговая настройка зависит от требований конкретного SMPP-шлюза, формата номера и имени отправителя. В статье разберём поля, порядок проверки и действия при недоставке SMS.

Что означают TON и NPI в SMPP?

TON расшифровывается как Type of Number, то есть тип номера. Поле помогает определить, что передано в адресе: международный номер, национальный номер, короткий код, буквенное имя отправителя или другой формат.

NPI — Numbering Plan Indicator, признак плана нумерации. В большинстве интеграций он связан с тем, по какому плану шлюз должен разобрать адрес. Ошибка появляется, когда приложение отправляет один формат номера, а в параметрах PDU указывает другой тип или план.

Эти поля передаются отдельно для source_addr_ton, source_addr_npi, dest_addr_ton и dest_addr_npi. Первые два относятся к отправителю, вторые два — к получателю. Поэтому одна и та же SMS может иметь корректный TON/NPI для номера клиента, но неверный набор для имени отправителя.

Название оператора само по себе не определяет значения TON и NPI. Для МТС, A1 и life:) нужно учитывать формат, в котором шлюз принимает номера, а также правила конкретного подключения. Поэтому техническое задание провайдера важнее примера из чужой конфигурации.

Как выбрать TON/NPI для номеров МТС, A1 и life:)?

Начните с единого формата телефонных номеров. Если приложение хранит номера по-разному, например часть с плюсом, часть без него, сначала приведите их к согласованному виду. Иначе одна и та же настройка даст разные результаты для разных записей.

Затем запросите у SMPP-провайдера таблицу параметров подключения. В ней должны быть указаны сервер, порт, режим bind, TON/NPI и лимиты отправки. Такая последовательность описана в практической инструкции по SMPP-интеграции от SMSp.by: после подключения рекомендуется отправить тестовые SMS и проверить DLR.

Для теста возьмите номера абонентов разных сетей, включая МТС, A1 и life:), если ваш трафик направляется во все эти сети. Отправьте одинаковое сообщение с одним набором параметров, зафиксируйте submit_sm_resp и итоговый delivery receipt. Затем меняйте только один параметр за раз. Так будет понятно, повлиял ли TON, NPI, формат номера или маршрут.

Не переносите значения из документации другого шлюза. Один провайдер может принимать международный формат номера с определённым TON, а другой требовать собственную комбинацию или рекомендовать значения по умолчанию. Если документация допускает значение «unknown», это тоже следует воспринимать как часть спецификации конкретного подключения, а не как универсальное правило для Беларуси.

Почему ошибка TON/NPI влияет на доставку и DLR?

При отправке приложение сначала передаёт PDU SMPP шлюзу. Шлюз проверяет структуру сообщения, адреса и доступность маршрута. Если адрес не соответствует указанному типу, система может вернуть ошибку сразу на этапе submit_sm. В таком случае SMS до оператора не уйдёт.

Другой сценарий выглядит сложнее: шлюз принимает сообщение, но не может правильно обработать адрес на последующем участке маршрута. Тогда приложение получает принятие от SMPP-сессии, а в DLR приходит статус ошибки или недоставки. Поэтому одного положительного submit_sm_resp недостаточно для проверки результата.

DLR нужно сопоставлять с исходным message_id. Проверьте, что приложение сохраняет идентификатор, разбирает delivery_receipt и не считает сообщение доставленным только потому, что шлюз его принял. Практические правила чтения SMPP-статусов и контроля недоставки разобраны в материале «SMPP-статусы: как читать DLR».

TON/NPI не исправят недоступный телефон, временную перегрузку сети или ограничение маршрута. Если часть SMS доходит, а часть получает одинаковую ошибку, сравните формат адресов и параметры PDU. Если ошибка возникает только у одного направления, передайте провайдеру message_id, время отправки и полный текст статуса.

Как диагностировать ошибку TON/NPI в рабочем подключении?

Диагностику удобнее проводить от уровня приложения к уровню маршрута. Сначала сохраните исходные поля submit_sm: source_addr, destination_addr, source_addr_ton, source_addr_npi, dest_addr_ton и dest_addr_npi. Без этих данных провайдеру трудно отличить ошибку формата от сбоя доставки.

1. Проверьте длину и запись номера получателя. Уберите пробелы, скобки и лишние символы, если такой формат не разрешён спецификацией подключения.
2. Сравните TON/NPI с таблицей провайдера. Отдельно проверьте отправителя и получателя, потому что у них разные поля.
3. Отправьте тест на номера МТС, A1 и life:) с одинаковым текстом и одинаковым sender ID.
4. Сопоставьте submit_sm_resp, message_id и DLR. Запишите, на каком этапе появляется ошибка.
5. После изменения параметров повторите тест на новом сообщении, чтобы не спутать старый DLR с новой попыткой.

Если используется несколько SMPP-подключений под одним логином, заранее уточните правила возврата статусов. В документации одного из провайдеров отмечено, что DLR для сообщений от одного подключения иногда могут прийти на другое. Для бизнеса это выглядит как проблема TON/NPI, хотя причина находится в распределении сессий и обработке идентификаторов.

Типичные ошибки

• Приложение передаёт номер в одном формате, а TON указывает для другого формата.
• Разработчик меняет сразу TON, NPI и sender ID, поэтому не может определить причину сбоя.
• Положительный submit_sm_resp принимают за подтверждение доставки.
• Значения копируют из примера другого SMS-шлюза без сверки с настройками текущего провайдера.
• DLR не связывают с message_id или разбирают только текстовый статус.
• Несколько SMPP-сессий используют общий логин без проверки маршрутизации delivery receipt.

Как оформить настройки для разработчика?

Передайте разработчику не фразу «настроить SMPP для Беларуси», а таблицу параметров. В ней укажите формат номера, допустимый sender ID, значения TON/NPI для source и destination, режим bind, лимит сообщений и правила обработки DLR.

Если система уже отправляет SMS через HTTP API, при переходе на SMPP нельзя просто перенести старые поля без проверки. Меняются формат запроса, управление сессией, обработка ошибок и получение DLR. Для такого сценария полезен разбор миграции с HTTP API на SMPP без потери SMS.