Как настроить повторную отправку SMS при сбое SMPP-соединения

Настройте отправку пакета enquire_link каждые 30 секунд и обрабатывайте разрыв сессии через автоматический вызов метода bind, чтобы восстанавливать канал связи без потери сообщений в очереди. Надежная доставка сообщений через SMPP-протокол требует постоянного контроля за состоянием соединения между вашим сервером ESME и центром коротких сообщений оператора SMSC. Когда связь прерывается, система фиксирует ошибку, переводит очередь в режим буферизации и выполняет процедуру переподключения за фиксированное время.

Как настроить отправку пакета enquire_link для контроля связи?

Сервер ESME отправляет PDU enquire_link регулярно, чтобы удерживать TCP-соединение активным и вовремя обнаруживать обрывы сети. Технические регламенты предписывают отправлять этот проверочный пакет каждые 15–30 секунд при отсутствии другого трафика. Если ответа на enquire_link не поступает в течение заданного таймаута, соединение считается разорванным.

Параметр таймера задается в конфигурационном файле вашего SMPP-клиента. Например, для сетей МТС интервал составляет 30 секунд, а некоторые шлюзы требуют отправку каждые 15 секунд. Регулярная отправка пакетов enquire_link предотвращает зависание сеанса связи, когда шлюз оператора уже закрыл порт, а приложение продолжает отправлять туда пакеты submit_sm.

Какую стратегию переподключения и очереди сообщений выбрать?

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

Для оценки подходов к обработке очередей при сбоях используйте таблицу ниже.

Как правильно обрабатывать статусы deliver_sm и исключить generic_nack?

Каждое входящее сообщение или отчет о доставке в виде пакета deliver_sm требует обязательного подтверждения от вашего оборудования. Согласно техническим требованиям операторов, на каждый принятый deliver_sm или data_sm ваша система обязана отправить ответ deliver_sm_resp или data_sm_resp со статусом 0 (OK). Использование пакета generic_nack запрещено — при его отправке шлюз SMSC принудительно сбрасывает сессию через отправку unbind.

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

Типичные ошибки при настройке повторной отправки по SMPP

• Отправка пакета generic_nack вместо deliver_sm_resp со статусом 0, что приводит к мгновенному сбросу сессии.
• Отсутствие таймера enquire_link, из-за чего зависшее соединение остается висеть без фиксации обрыва.
• Отправка сообщений submit_sm без ожидания ответа bind_resp, вызывающая переполнение буфера на шлюзе.
• Игнорирование очередей на стороне приложения, приводящее к дублированию отправки одинаковых SMS при сбое сети.
• Отсутствие логирования кодов ошибок SMPP-протокола, усложняющее диагностику сбоев канала связи.