Приоритет SMS в SMPP помогает отделить OTP-коды и другие срочные уведомления от массовой отправки. Для этого задают значение priority_flag, разделяют очереди и заранее решают, как система будет обрабатывать повторные попытки. В статье разберём практическую схему для малого бизнеса: какие сообщения считать срочными, когда нужен отдельный SMPP-сеанс и почему одного поля приоритета недостаточно, если все сообщения уходят через одну перегруженную очередь.
Что означает priority_flag в SMPP?
priority_flag передаётся в команде submit_sm. Поле показывает шлюзу относительную важность сообщения: SMS с более высоким приоритетом можно поставить перед обычными сообщениями в очереди. Так OTP-код, уведомление о входе или сообщение об успешном платеже получает шанс уйти раньше рекламной или сервисной рассылки.
При этом SMPP не гарантирует одинаковое поведение у всех операторов и шлюзов. Одни платформы учитывают несколько уровней приоритета, другие используют только деление на обычные и срочные сообщения, а третьи могут вообще не менять порядок доставки. Поэтому значение priority_flag нужно проверить в документации конкретного SMPP-провайдера и подтвердить тестовой отправкой.
Команда submit_sm становится доступна после запуска SMPP-сессии. Сначала приложение устанавливает соединение и выполняет bind, затем передаёт SMS через submit_sm, получает идентификатор сообщения и отслеживает статус доставки. Такой порядок описан в документации МТС для бизнеса; там же указано, что сервис работает в синхронном и асинхронном режимах.
Какие SMS нужно отправлять с высоким приоритетом?
Срочную очередь лучше формировать по назначению сообщения, а не по отделу, который его создал. В неё обычно попадают сообщения, без которых пользователь не может продолжить действие в системе:
- одноразовый код для входа или подтверждения операции;
- уведомление о смене пароля или подозрительной попытке входа;
- сообщение о результате платежа;
- критическое уведомление, после которого клиенту нужно сразу выполнить действие;
- сервисный статус, который теряет смысл через несколько минут.
В обычной очереди остаются массовые уведомления, напоминания и сообщения, для которых задержка в несколько минут не меняет сценарий. Если клиент получает несколько OTP подряд, приложение должно считать действительным только последний код или явно связывать код с конкретной попыткой. Обработку отправки OTP, DLR и повторов удобно проектировать как отдельный сценарий: как отправить OTP-код через SMPP и обработать DLR.
Как разделить срочные и обычные очереди?
Для небольшого проекта достаточно двух очередей в приложении: urgent для OTP и транзакционных сообщений и normal для остальных SMS. Перед постановкой в очередь программа присваивает сообщению тип, срок актуальности и приоритет. Затем отдельный отправитель выбирает срочную очередь первой, но оставляет обычной очереди гарантированное время обработки.
Простая логика выглядит так:
- Приложение создаёт сообщение и указывает его тип: OTP, транзакционное или обычное.
- Очередь назначает срок актуальности. Просроченный код не нужно отправлять только ради закрытия задачи.
- Отправитель берёт сначала срочные сообщения и передаёт их через
submit_smс повышеннымpriority_flag. - После ответа шлюза система сохраняет идентификатор сообщения и ждёт DLR.
- При временной ошибке приложение делает ограниченное число повторов, а при окончательной ошибке прекращает отправку.
Приоритет лучше назначать на стороне приложения, а не пытаться угадывать назначение SMS по тексту. Так система не перепутает рекламное сообщение со срочным уведомлением, даже если в тексте есть слова «код» или «подтверждение». Для ошибок SMPP и статусов доставки полезно заранее описать отдельные правила автоматической обработки: как обрабатывать ошибки SMPP и DLR.
Когда нужны отдельные SMPP-соединения?
Одна SMPP-сессия подходит для небольшого объёма, если приложение умеет управлять очередями. Отдельное соединение для OTP стоит рассмотреть, когда массовая отправка регулярно занимает весь доступный поток или когда провайдер позволяет закрепить разные лимиты за разными подключениями.
| Схема | Когда подходит | Что проверить |
|---|---|---|
| Одна сессия, две очереди | Небольшой и средний объём, единая точка контроля | Порядок обработки, значение priority_flag, лимит запросов |
| Две SMPP-сессии | OTP должно сохранять отдельный канал при массовой отправке | Лимиты каждой сессии, bind-параметры, правила маршрутизации |
| Два независимых канала | Нужна резервная отправка при недоступности основного подключения | Повторы, защита от дублей, обработка DLR |
Отдельная сессия сама по себе не ускоряет доставку. Если оператор или шлюз ограничивает скорость на уровне аккаунта, два подключения не обойдут этот лимит. Кроме того, два канала усложняют контроль дублей: приложение должно знать, было ли сообщение принято первым маршрутом и нужно ли отправлять его повторно.
В документации МТС для бизнеса приведён пример окна размером 99 и пропускной способности 10 SMS в секунду. Эти параметры нельзя переносить на любой SMPP-шлюз без проверки: размер окна, скорость и режим подтверждений задаёт конкретная платформа. Перед запуском уточните допустимое число незавершённых запросов и порядок обработки ответов.
Как проверить приоритет до запуска?
Тест проводят на двух потоках. В первый одновременно отправляют небольшую серию обычных сообщений, во второй помещают OTP с высоким приоритетом. В журнале фиксируют время постановки в очередь, время отправки submit_sm, ответ шлюза и DLR. Тест показывает, влияет ли приоритет на порядок постановки и насколько быстро система освобождает срочную очередь.
Проверяйте не только успешную доставку. Нужны сценарии временной ошибки, недоступного номера, задержанного DLR и повторной отправки. Для каждой попытки сохраняйте уникальный внутренний идентификатор, чтобы один код не ушёл дважды из-за потерянного ответа.
Кириллица тоже влияет на расчёт очереди: длина сообщения и способ кодирования меняют число SMS-сегментов. Поэтому в тест включают короткий латинский OTP, русский текст и сообщение на несколько частей. Отдельно разобрать кодировки и длину SMS можно в материале как отправлять кириллицу в SMPP.
Типичные ошибки при настройке приоритетов
- Повышают приоритет всем сообщениям, после чего срочная очередь перестаёт выделяться.
- Считают, что
priority_flagгарантирует мгновенную доставку при ограничении скорости у шлюза. - Повторяют SMS после тайм-аута, не проверив, принял ли шлюз предыдущий
submit_sm. - Не задают срок действия OTP и отправляют просроченный код после длительной задержки.
- Не учитывают многосоставные SMS, хотя длинный текст занимает несколько единиц отправки.
- Разделяют очереди, но оставляют один общий блокировщик, который всё равно задерживает OTP за массовой пачкой.
3 шага, которые можно сделать на этой неделе:
- Разделить сообщения на OTP, транзакционные и обычные, затем назначить им разные очереди.
- Проверить в документации SMPP-провайдера, как он трактует
priority_flag, окно запросов и лимит скорости. - Провести параллельный тест с обычными SMS и OTP, записывая
submit_sm, ответы шлюза и DLR.
Если приоритет не даёт ожидаемого результата, причина обычно находится в очереди приложения, лимите соединения или правилах самого шлюза. Тогда схему уточняют на уровне интеграции: задают отдельные SMPP-соединения, ограничивают массовую отправку и оставляют OTP отдельный маршрут с понятной обработкой повторов.
