Чек-лист интеграции SMPP

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

• Подтвердите версию SMPP — v3.4 для большинства маршрутов, v5.0 там, где провайдер поддерживает состояние перегрузки и расширенные TLV.v5.0 обратно совместима; не предполагайте, что функции доступны, пока bind_resp это не подтвердит.
• Выберите верный тип bind для каждой сессии.transmitter (только MT), receiver (только DLR/MO) или transceiver (оба режима в одной сессии). Предпочитайте transceiver, чтобы вдвое сократить число соединений там, где провайдер это позволяет.
• Установите system_id, password, system_type и address_range точно так, как это было согласовано с провайдером.Несовпадающий address_range незаметно блокирует маршрутизацию MO/DLR на receiver-bind.
• Согласуйте с провайдером в письменном виде число одновременных bind и TPS на bind.Открытие большего числа bind, чем предусмотрено, — самая частая причина throttling или блокировки аккаунта.
• Явно обрабатывайте коды статуса bind_resp — повторяйте попытку при ESME_RALYBND и снижайте темп при ESME_RBINDFAIL.Никогда не зацикливайтесь на неудачном bind; используйте экспоненциальную задержку с jitter.

• Установите source_addr_ton / source_addr_npi и dest_addr_ton / dest_addr_npi корректно для буквенно-цифровых и числовых sender ID.Буквенно-цифровой отправитель → TON 5 (alphanumeric); международный MSISDN → TON 1, NPI 1.
• Выберите верный data_coding: GSM 7-бит (0), 8-бит (4) или UCS-2 (8) для Unicode.Смешивание кодировок без установки data_coding приводит к «кракозябрам» и неверной сегментации.
• Реализуйте конкатенацию длинных сообщений через UDH или необязательные TLV SAR (sar_msg_ref_num, sar_total_segments, sar_segment_seqnum).Выберите один способ и придерживайтесь его; одни маршруты отклоняют UDH, другие — TLV SAR.
• Запрашивайте отчёты о доставке через registered_delivery = 1 только там, где вы их действительно используете.Запрос DLR, которые вы не разбираете, впустую расходует пропускную способность и может вызвать предупреждения со стороны провайдера.
• Соблюдайте семантику validity_period и schedule_delivery_time для вашего сценария использования (OTP = короткий срок действия).Короткоживущие OTP должны нести жёсткий validity_period, чтобы устаревшие сообщения не доставлялись с опозданием.

• message_payload — для полезной нагрузки, превышающей лимит поля short_message.Не заполняйте одновременно short_message и message_payload — провайдеры это отклоняют.
• TLV sar_* — стандартизированная конкатенация без байтов UDH в теле сообщения.
• dest_addr_subunit / source_addr_subunit — там, где маршрут требует этого для маршрутизации на конкретное устройство.
• Передавайте пользовательские метаданные только в согласованных с провайдером TLV.Нестандартные TLV вне согласованного диапазона обычно отбрасываются или вызывают ошибки разбора ниже по цепочке.

Отчёты о доставке приходят в виде PDU deliver_sm и являются основой вашей сверки и отчётности по качеству.

• Разбирайте отчёт из поля short_message в deliver_sm: id, sub, dlvrd, дату отправки, дату завершения, stat, err.Поле `stat` (DELIVRD, UNDELIV, EXPIRED, REJECTD и т. д.) — это ваш конечный статус.
• Сопоставляйте DLR с отправкой по формату message_id провайдера, а не только по тексту отчёта.message_id может возвращаться в шестнадцатеричном виде в submit_resp, но в десятичном — в DLR; нормализуйте оба формата.
• Обрабатывайте промежуточные (не финальные) отчёты отдельно от финальных статусов.Бит 0x04 в esm_class обозначает отчёт о доставке; только финальные значения `stat` должны закрывать сообщение.
• Всегда возвращайте deliver_sm_resp — неподтверждённый DLR отправляется повторно и может остановить окно приёма.Отвечайте незамедлительно, даже если дальнейшая обработка на вашей стороне асинхронна.
• Сопоставляйте коды ошибок оператора с нормализованной таксономией (абонент недоступен, телефон занят, заблокировано как спам, неверный номер).Необработанные коды ошибок различаются по маршрутам; нормализованная таксономия делает качество сравнимым между маршрутами.

• Отправляйте enquire_link по таймеру простоя (обычно 30–60 с) и считайте пропущенный enquire_link_resp признаком мёртвой сессии.Это единственный надёжный способ обнаружить наполовину открытое TCP-соединение.
• Реализуйте окно SMPP: ограничивайте число неподтверждённых PDU и приостанавливайте отправку, когда окно заполнено.Слепая отправка submit_sm сверх окна — именно то, что вызывает ESME_RTHROTTLED.
• Снижайте темп при ESME_RTHROTTLED (0x58), а не повторяйте попытку немедленно.Добавляйте jitter, чтобы штормы переподключений не синхронизировались между воркерами.
• Соблюдайте unbind / unbind_resp для штатного завершения работы; переподключайтесь с задержкой при неожиданных разрывах.

• Используйте SMPP поверх TLS там, где это предлагает провайдер; отключите нешифрованные bind в продакшене.У SMPP нет встроенного шифрования — TLS является контролем на уровне транспорта.
• Проверяйте или закрепляйте (pin) цепочку сертификатов сервера и требуйте TLS 1.2+.Отклоняйте просроченные или самоподписанные сертификаты; не отключайте проверку «чтобы заработало».
• Ограничивайте bind списком разрешённых IP-адресов с обеих сторон.Разрешённый список IP — стандартный контроль оператора и быстрый способ сдержать утечку учётных данных.
• Регулярно меняйте учётные данные SMPP по расписанию и храните их в менеджере секретов, а не в коде.

• Отправьте сообщение на живой тестовый MSISDN на каждом целевом маршруте и подтвердите получение сквозным образом.
• Проверьте прохождение DLR для исходов «доставлено», «не доставлено», «истёк срок действия» и «отклонено».
• Протестируйте длинные (многосегментные) сообщения и контент в Unicode (UCS-2) на каждом маршруте.
• Проведите нагрузочное тестирование на предусмотренном TPS и подтвердите штатное поведение на границе окна/throttle.
• Смоделируйте разрыв соединения посреди окна и подтвердите чистое переподключение без дублирующих отправок.Идемпотентность при повторной попытке предотвращает двойное выставление счёта и дублирующую доставку на телефон.
• Подтвердите мониторинг: состояние bind, заполненность окна, задержка submit/DLR и частота кодов ошибок должны формировать оповещения.