Как автоматически обрабатывать ошибки SMPP и не терять SMS

Ошибки SMPP показывают, на каком участке сломалась отправка: приложение не прошло проверку, шлюз ограничил скорость, очередь переполнилась или оператор не принял сообщение. В статье разберём ESME_RTHROTTLED, ESME_RINVSRCADR и ESME_RMSGQFUL, покажем порядок диагностики и соберём схему автоматической обработки. После этого можно настроить повторные попытки, контроль очереди и уведомления так, чтобы сбой не превращался в потерю всей рассылки.

Почему одного статуса «не доставлено» недостаточно?

В SMPP результат состоит из нескольких событий. Сначала приложение отправляет запрос шлюзу и получает ответ на операцию. Затем система может принять сообщение в очередь, передать его оператору и вернуть финальный статус доставки через DLR. На каждом этапе возникают свои ошибки, поэтому запись «SMS не ушло» мало помогает разработчику.

Начните с журнала, где для каждого сообщения сохраняются время отправки, идентификатор сообщения, команда SMPP, код ответа и текст ошибки. Идентификатор нужен для связи первоначального ответа с последующим DLR. Без него команда видит отдельные записи и не понимает, что произошло с конкретным SMS.

Для быстрой проверки отправьте тестовое сообщение на несколько номеров и сравните результаты. Если ошибка появляется сразу при отправке, ищите проблему в сессии, адресах или параметрах запроса. Если запрос принят, но DLR сообщает отказ, проверяйте маршрут, содержимое сообщения и ограничения на стороне оператора. Такой подход соответствует базовой диагностике доставки SMS: анализу статусов через API, кодов ошибок и тестовых отправок (Проблемы с доставкой SMS: диагностика и решения).

Что означает ESME_RTHROTTLED и как убрать ограничение скорости?

ESME_RTHROTTLED обычно означает, что приложение отправляет сообщения быстрее, чем разрешает шлюз или текущая SMPP-сессия. Причина появляется при резком запуске рассылки, неправильном расчёте TPS или попытке отправить много сообщений параллельно через один bind.

Повторять такой запрос сразу в плотном цикле не стоит. Приложение усилит нагрузку и получит ещё больше отказов. Сделайте паузу, уменьшите скорость и отправьте сообщение снова через отложенную очередь.

Какая логика повторной отправки подходит для throttling?

1. Зафиксируйте код ESME_RTHROTTLED и исходный message_id.
2. Поставьте сообщение в очередь с задержкой, например на несколько секунд. Точный интервал выбирайте по правилам шлюза.
3. Повторите отправку с увеличенным интервалом, если ограничение сохраняется.
4. Остановите повтор после заданного числа попыток и передайте запись в журнал ошибок.
5. Отдельно считайте принятые шлюзом сообщения и отклонённые запросы.

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

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

Почему появляется ESME_RINVSRCADR?

ESME_RINVSRCADR означает, что шлюз не принял адрес отправителя. В запросе может быть указан источник в неподдерживаемом формате, использовано незарегистрированное значение или передан адрес, который не соответствует настройкам соединения.

Сначала сравните значение source_addr в рабочем и тестовом запросе. Проверьте пробелы, длину, кодировку и тип адреса. Для буквенного отправителя отдельно убедитесь, что система ожидает именно alphanumeric source address, а для цифрового источника проверьте формат номера.

Распространённая ошибка возникает после переноса конфигурации: разработчик меняет отправителя в коде, но забывает обновить настройку шлюза. Ещё один вариант, когда поле заполняется автоматически из названия магазина и получает символы, которые маршрут не принимает.

Что проверить по шагам?

• Посмотреть точное значение source_addr в журнале запроса.
• Сравнить его с параметрами учётной записи SMPP.
• Отправить тест с согласованным источником.
• Проверить, не меняет ли значение промежуточный API-адаптер.
• Если ошибка остаётся, запросить у поставщика допустимый формат source address для этого подключения.

Не маскируйте ESME_RINVSRCADR повторной отправкой того же запроса. Код указывает на постоянную ошибку параметра, поэтому повтор лишь создаст лишние записи в очереди. Сначала исправьте конфигурацию, затем повторите сообщение один раз.

Как исправить ESME_RMSGQFUL и контролировать очередь?

ESME_RMSGQFUL сообщает, что очередь сообщений переполнена. Она может находиться на стороне шлюза или в вашем приложении. Различить эти варианты помогает момент возникновения ошибки: ответ сразу после submit_sm указывает на очередь шлюза, а задержка перед отправкой и рост локального backlog говорят о проблеме в приложении.

Проверьте, сколько сообщений находится в локальной очереди, сколько обработчик отправляет за единицу времени и сколько запросов ждёт ответа. Затем сравните эти показатели с частотой появления ESME_RMSGQFUL. Если приложение складывает сообщения быстрее, чем шлюз их принимает, нужно снизить входной поток или увеличить число разрешённых каналов по согласованию с поставщиком.

Для очереди задайте предельный размер. Когда лимит достигнут, система должна временно остановить приём новых задач или сохранить их в устойчивом хранилище. Молчаливое удаление сообщений создаёт самый неприятный сценарий: бизнес считает рассылку запущенной, а часть клиентов не получает уведомление.

Как построить автоматическую обработку кодов SMPP?

Удобная схема начинается с классификатора ошибок. Приложение получает код, определяет его тип и выбирает действие. Временные ошибки отправляют на повтор, постоянные передают в журнал и уведомляют ответственного, а спорные статусы оставляют для ручной проверки по правилам конкретного шлюза.

У каждой попытки должны быть статус, время, код ответа и причина следующего действия. Повторная отправка обязана иметь лимит. Если система не различает временный отказ и ошибку параметров, она либо перегружает шлюз, либо бесконечно отправляет заведомо некорректное сообщение.

Для DLR используйте отдельный обработчик. Он принимает финальный статус, связывает его с message_id и обновляет запись сообщения. Если DLR не приходит в ожидаемый срок, создайте отдельное состояние «нет подтверждения» и проверьте канал, а не отправляйте SMS вслепую. Практическая схема работы с API, DLR и повторами описана в материале об отправке SMS о доставке через SMPP.

Какие ошибки чаще всего мешают диагностике?

• Разработчик смотрит только на текст исключения и не сохраняет числовой код SMPP.
• Приложение повторяет ESME_RINVSRCADR без изменения параметров.
• После ESME_RTHROTTLED система делает мгновенные повторы в цикле.
• Локальная очередь не имеет лимита и занимает всё доступное место.
• В журнале нет message_id, поэтому ответ шлюза нельзя связать с SMS.
• Команда считает submit_sm подтверждением доставки и не обрабатывает DLR.

Автоматизацию лучше вводить поэтапно. Сначала добавьте полный журнал и классификацию трёх кодов, затем подключите очередь с задержанными повторами, после этого настройте контроль DLR и уведомление о росте ошибок. На площадке smpp.by эти задачи можно связать с настройкой SMPP-шлюза, API-интеграцией и аналитикой трафика, чтобы причина сбоя была видна в данных, а не угадывалась по жалобам клиентов.