Как проверить доставку SMS в SMPP и найти источник задержки

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

Какие этапы доставки SMS нужно сравнить?

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

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

Записывайте идентификатор сообщения, адрес получателя в маскированном виде, ответ шлюза и статус доставки. Не смешивайте несколько попыток отправки в одну запись: каждой попытке нужен собственный идентификатор или номер попытки. Так проще заметить повторную отправку и сопоставить события.

Как отличить задержку интеграции от задержки на маршруте?

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

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

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

Статус «доставлено» означает, что система получила соответствующее подтверждение в цепочке доставки. Он не подтверждает, что человек прочитал сообщение. Для проверки фактического появления SMS на устройстве проведите отдельный тест на контрольном номере.

Как провести проверку на тестовом номере?

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

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

При разборе инцидента различайте временные и постоянные ошибки. Кратковременный сбой соединения или превышение лимита может требовать повторной попытки после паузы. Неверная конфигурация или ошибка формата сообщения требует исправления причины: автоматические повторы её не устранят.

Какие ошибки мешают найти причину?

• Считать ответ шлюза подтверждением доставки на телефон. Это подтверждение приёма запроса, а не финального результата.
• Сравнивать время в системах с разными часовыми поясами. Сведите события к единому времени.
• Повторно отправлять SMS при каждой задержке. Сначала проверьте статус исходной попытки, чтобы не создать дубль.
• Снимать всю очередь после обрыва связи. Ограничьте скорость восстановления и следите за ответами шлюза.
• Хранить только итоговый статус. Записывайте промежуточные события и идентификатор сообщения.

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

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