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

- Канонический URL: https://www.broadnet.me/ru/guides/smpp-integration-checklist
- Язык: ru
- Издатель: BroadNet (https://www.broadnet.me)
- Markdown-версия страницы, созданная из опубликованной страницы.

Протоколы и API Бесплатный чек-лист

Практический чек-лист для интеграции SMPP v3.4/v5.0: типы bind, необязательные TLV, обработка отчётов о доставке, keepalive enquire_link, throttling, TLS и план тестирования перед выводом в продакшен.

33 пунктов проверки 4 мин чтения Обновлено 14 июля 2026 г.

Прислать PDF на почту

Для разработчиков и инженеров по обмену сообщениями, настраивающих новый bind SMPP.

Содержание

1. 01Настройка сессии и bind
2. 02Отправка сообщений (submit_sm)
3. 03Необязательные параметры (TLV), которые стоит устанавливать
4. 04Обработка отчётов о доставке (DLR)
5. 05Keepalive и управление потоком
6. 06Защита транспорта (TLS)
7. 07План тестирования перед продакшеном

[Все руководства](https://www.broadnet.me/ru/guides)

Коротко

SMPP (Short Message Peer-to-Peer) — это бинарный протокол, который большинство агрегаторов и операторов предоставляют для высокообъёмного A2P-обмена сообщениями. Чистая интеграция — это не столько написание PDU, сколько правильная реализация операционных деталей: выбор верного режима bind, соблюдение ограничений окна и throttle, надёжный разбор отчётов о доставке, поддержание сессии активной и защита транспорта. Двигайтесь сверху вниз — каждая группа пунктов это контрольная точка, которую можно закрыть перед переводом bind в продакшен.

Чек-лист

## Проходите по пунктам и отмечайте выполненное.

Схема SMPP-сессия между вашей платформой и BroadNet

Ваша платформа (ESME)

BroadNet SMSC

Одно постоянное TCP/TLS-соединение

1. `bind_transceiver` Открыть и аутентифицировать сессию
2. `bind_transceiver_resp` Сессия принята
3. `submit_sm` Отправить сообщение
4. `submit_sm_resp` Принято, возвращен ID сообщения
5. `deliver_sm` Подтверждение доставки или входящее сообщение
6. `deliver_sm_resp` Подтверждено
7. `enquire_link` Keepalive в режиме ожидания

01

### Настройка сессии и bind

Выберите верный режим 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.

02

### Отправка сообщений (submit_sm)

- Установите 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, чтобы устаревшие сообщения не доставлялись с опозданием.

03

### Необязательные параметры (TLV), которые стоит устанавливать

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

04

### Обработка отчётов о доставке (DLR)

Отчёты о доставке приходят в виде 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 отправляется повторно и может остановить окно приёма. Отвечайте незамедлительно, даже если дальнейшая обработка на вашей стороне асинхронна.
- Сопоставляйте коды ошибок оператора с нормализованной таксономией (абонент недоступен, телефон занят, заблокировано как спам, неверный номер). Необработанные коды ошибок различаются по маршрутам; нормализованная таксономия делает качество сравнимым между маршрутами.

05

### Keepalive и управление потоком

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

06

### Защита транспорта (TLS)

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

07

### План тестирования перед продакшеном

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

Источники

- [Спецификация SMPP v3.4](https://smpp.org/SMPP_v3_4_Issue1_2.pdf)
- [Спецификация SMPP v5.0](https://smpp.org/SMPP_v5.pdf)
- [3GPP TS 23.040 — техническая реализация SMS](https://www.3gpp.org/dynareport/23040.htm)

Стандарты и документы регуляторов, на которые ссылается это руководство. BroadNet — ассоциированный член GSMA и член MEF, с 2003 года предоставляет обмен сообщениями операторского уровня.

Related

- [Справочник кодов ошибок SMPP (бесплатный инструмент)](https://www.broadnet.me/ru/tools/smpp-error-codes)
- [Декодер DLR (бесплатный инструмент)](https://www.broadnet.me/ru/tools/dlr-decoder)
- [Что такое SMPP?](https://www.broadnet.me/ru/answers/what-is-smpp)
- [Протокол SMPP — подробный разбор](https://www.broadnet.me/ru/answers/smpp-protocol)
- [Документация для разработчиков](https://www.broadnet.me/ru/developers)

Сохраните копию

## Нужна версия в PDF, чтобы поделиться?

Отправьте её себе на почту, чтобы поделиться с командой, — без спама, одно письмо.

Прислать PDF на почту

Получить PDF

## Прислать «Чек-лист интеграции SMPP» на почту.

Мы пришлём вам аккуратный PDF этого чек-листа для печати — чтобы поделиться с командой или приложить к RFP. Инженер по обмену сообщениями свяжется с вами, только если вы попросите, — никакого спама от продаж.

- PDF для печати: одна страница на раздел
- Всё содержимое этой страницы в удобном для отправки виде
- По желанию: звонок с инженером BroadNet

Не хотите оставлять e-mail? Воспользуйтесь кнопкой Печать / сохранить в PDF выше — полный чек-лист есть на этой странице.

Прямая линия · ответ в течение одного рабочего дня

## Прислать «Чек-лист интеграции SMPP»

Укажите, куда его отправить. Мы пришлём PDF на почту и свяжемся с вами, только если вы попросите.

1. 1 Кто
2. 2 Задача
3. 3 Контекст