SMS API или SMPP: какой способ подключения выбрать?

Это руководство для инженеров и технических руководителей, которые решают, как подключиться к SMS-провайдеру: через HTTP/REST SMS API, через SMPP или обоими способами. Здесь объясняется, чем эти два подхода отличаются на уровне протокола и в эксплуатации, чтобы вы могли выбрать подходящий интерфейс для каждого вида трафика и спланировать миграцию, если первый выбор перестанет вас устраивать.

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

Чем SMS API отличается от SMPP?

REST SMS API отправляет каждое сообщение отдельным HTTPS-запросом и возвращает ID сообщения. SMPP (Short Message Peer-to-Peer) держит одну долгоживущую аутентифицированную сессию и обменивается по ней бинарными сообщениями, которые называются PDU, в обоих направлениях. REST оптимизирован для простоты, SMPP — для стабильных больших объёмов SMS.

Как работает REST SMS API?

Вы отправляете HTTPS-запрос POST с токеном и телом в формате JSON, а провайдер отвечает ID сообщения. Каждый запрос независим, поэтому отправлять можно с любого сервера, из функции или контейнера, не управляя соединением.

Типичная отправка через наш API выглядит так:

curl -X POST https://api.broadnet.me/sms/sendSms \
  -H "Authorization: Bearer $BROADNET_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "senderId": "OmniDemo",
    "destinationNumber": "971500000000",
    "message": "Your OmniDemo code is 482913",
    "messageType": "TEXT"
  }'

В ответ приходит 200 OK с ID сообщения в виде обычного текста. Итоговый статус позже приходит на ваш вебхук как SUBMITTED, SENT, DELIVERED, FAILED или REJECTED. Названия полей и параметры описаны в справочнике по SMS API.

Сильные стороны REST:

• Привычные инструменты: любой язык, любой HTTP-клиент, стандартные коды состояния по RFC 9110.
• Простая защита: TLS везде и токен в заголовке Authorization.
• Массовая отправка без соединений: загрузите файл с получателями одним запросом, не открывая сессию.
• Один API для многих каналов: по той же схеме отправляются шаблоны WhatsApp и карточки RCS.

Ограничения REST: каждое сообщение или пакет требует HTTP-обращения, а лимит запросов в секунду вы встретите раньше любого лимита оператора. Для большинства трафика приложений это не имеет значения.

Как работает SMPP?

SMPP — бинарный протокол, описанный в спецификации SMPP v3.4. Её опубликовал SMPP Developers Forum (позже SMS Forum), и эта версия по-прежнему наиболее распространена. Ваша система, называемая ESME (External Short Message Entity), подключается к SMSC (Short Message Service Centre, центру коротких сообщений) провайдера и открывает сессию, которая называется bind.

Типы bind

• Transmitter (TX) через bind_transmitter: только отправка сообщений.
• Receiver (RX) через bind_receiver: только приём отчётов о доставке и входящих сообщений.
• Transceiver (TRX) через bind_transceiver: и то и другое в одной сессии. Это обычный выбор.

Жизненный цикл сессии

1. Откройте TLS-соединение с хостом и портом, которые указал провайдер.
2. Отправьте bind_transceiver со своими system_id и паролем и дождитесь ответа с command_status 0.
3. Отправляйте сообщения через submit_sm. Каждый submit_sm_resp возвращает message_id.
4. Принимайте отчёты о доставке (DLR) как deliver_sm и отвечайте на каждый через deliver_sm_resp.
5. В простое периодически отправляйте enquire_link, чтобы обе стороны знали, что сессия жива.
6. Закройте сессию через unbind и дождитесь unbind_resp.

Каждый PDU несёт порядковый номер, а ответы возвращают тот же номер: так вы сопоставляете submit_sm_resp с отправленным сообщением. Каждый шаг с нашими настройками описан в документации по SMPP.

Что такое windowing в SMPP и почему это важно?

Windowing означает, что вы отправляете несколько PDU submit_sm, не дожидаясь ответов. Количество PDU без подтверждения, которое разрешено держать в обработке, и есть окно. Именно поэтому SMPP выдерживает более высокую пропускную способность, чем HTTP с одним запросом за раз.

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

Практические правила:

• Используйте размер окна, согласованный с провайдером, и не превышайте его: лишние PDU могут быть отклонены.
• Соблюдайте согласованную скорость на один bind. Если вы получили ESME_RTHROTTLED, снизьте темп и повторите попытку с нарастающей паузой (backoff).
• Отслеживайте неподтверждённые порядковые номера, чтобы после разрыва соединения не потерять информацию о том, какие сообщения приняты.
• Масштабируйтесь числом bind-сессий в пределах согласованного для вашего аккаунта количества, а не всё большим окном.

Лимиты по умолчанию для нашего REST API и SMPP-сессий перечислены в разделе ошибки и лимиты; лимиты вашего аккаунта подтверждаются при подключении доступа.

Чем отличаются отчёты о доставке?

В REST провайдер отправляет JSON-событие на ваш вебхук. В SMPP отчёт приходит как PDU deliver_sm в сессии, с установленным битом отчёта в esm_class. Оба способа асинхронные: ни 200 OK, ни submit_sm_resp не означают, что сообщение получено на устройстве.

Спецификация SMPP v3.4 приводит формат текста отчёта как пример, а точный формат оставляет на усмотрение поставщика SMSC, но большинство провайдеров ему следуют:

id:2603121407537573731 sub:001 dlvrd:001 submit date:2610100914 done date:2610100915 stat:DELIVRD err:000 text:Your OmniDemo code

Если ваши системы работают с обоими интерфейсами, приведите состояния SMPP к одной модели статусов. Типичное соответствие:

Две практические разницы важнее формата:

• Подтверждение. SMPP-клиент должен отвечать на каждый deliver_sm. Неподтверждённые отчёты отправляются повторно и могут замедлять bind. Обработчик вебхука по той же причине должен быстро отвечать кодом 2xx.
• Восстановление. Если SMPP-клиент отключён, отчёты ждут следующего bind или могут истечь в очереди провайдера. В REST провайдер может предлагать повторную отправку отчётов за период. Уточните, как это работает в каждом случае.

Подробнее о значении каждого статуса читайте в материале статусы доставки сообщений: что они означают.

Как обрабатывается кодировка?

В обоих интерфейсах нужно выбирать между GSM-7 и Unicode, и оба делят длинные сообщения на части. Различие в том, кто выполняет эту работу.

• REST: вы задаёте в поле вроде messageType значение TEXT или UNICODE, а платформа сама делит длинные сообщения на части. В нашем API есть также POST /sms/identify, чтобы заранее посчитать символы и сегменты.
• SMPP: вы задаёте data_coding (0 для алфавита GSM-7 по умолчанию, 8 для UCS-2) и сами кодируете байты. Для длинных сообщений нужно либо добавить User Data Header к каждой части и установить esm_class в 0x40, либо передать весь текст в поле message_payload, если ваш провайдер это включил.

По 3GPP TS 23.040 одно SMS содержит 140 октетов: 160 символов GSM-7 или 70 символов UCS-2, а при добавлении заголовка — 153 или 67 на часть. Одна арабская буква или эмодзи превращает всё сообщение в Unicode. Ошибки кодировки — самый частый дефект SMPP-интеграции, поэтому тестируйте с арабским текстом, эмодзи и длинными сообщениями. См. наше руководство по ограничениям на длину SMS.

Как сравниваются модели безопасности?

REST опирается на TLS и bearer-токен в каждом запросе. В SMPP v3.4 нет собственного шифрования, а учётные данные передаются в bind, поэтому защита зависит от транспорта и сетевых средств контроля вокруг него.

Для SMPP:

• Используйте TLS (TLS 1.3 описан в RFC 8446) или частный канал; никогда не используйте обычный SMPP через публичный интернет.
• Зарегистрируйте исходные IP-адреса, чтобы подключаться к bind могли только ваши серверы.
• Храните system_id и пароль как секреты, отдельно для каждой среды, и меняйте их при утечке.
• Отслеживайте неудачные bind: они могут говорить об ошибке в настройках или о неправомерном использовании учётных данных.

Для REST:

• Храните токен только на серверах, никогда в мобильных приложениях или коде браузера.
• Избегайте устаревших HTTP-интерфейсов, которые передают имя пользователя и пароль в URL: там они попадают в логи.
• Защищайте вебхук с помощью HTTPS, непредсказуемого пути и строгой проверки тела запроса.

Во что обходится эксплуатация каждого варианта?

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

SMPP-клиенту необходимо:

1. управление соединением с переподключением по схеме backoff с jitter, а не в жёстком цикле;
2. keep-alive и обнаружение «тихих» полуоткрытых соединений;
3. контроль окна и скорости для каждого bind;
4. отслеживание порядковых номеров и сверка после разрывов;
5. подтверждение и хранение отчётов;
6. логика кодировки и склейки длинных сообщений;
7. мониторинг состояния bind, пропускной способности, ошибок ограничения скорости и задержки отчётов.

Зрелые библиотеки с открытым кодом берут на себя протокол, но ваша команда всё равно отвечает за поведение вокруг них, в том числе в ночное окно технических работ у провайдера в 3 часа ночи.

Когда что использовать?

Используйте REST, если у вас нет явной причины добавлять SMPP.

Выбирайте REST SMS API, когда

• вы отправляете OTP, оповещения, уведомления или рассылки из приложений;
• вам нужны WhatsApp, RCS или другие каналы наряду с SMS;
• ваша платформа работает на бессерверных функциях или недолгоживущих контейнерах;
• у вашей команды нет опыта работы с SMPP и нет необходимости его осваивать.

Выбирайте SMPP, когда

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

Как выглядит гибридная схема?

Многие компании используют оба интерфейса в одном аккаунте: REST для мультиканального трафика и трафика приложений, SMPP для массовых SMS. Главная ловушка — получить две разные модели доставки.

• Распределяйте трафик по сценариям, а не случайно: например, OTP и WhatsApp через REST, массовые SMS с выписками через SMPP.
• Нормализуйте статусы из вебхуков и deliver_sm в одну таблицу с ключом по ID сообщения.
• Применяйте единые правила для имён отправителей (Sender ID) в обоих интерфейсах, поскольку регистрация действует независимо от того, каким интерфейсом вы пользуетесь.
• Ведите общую отчётность, чтобы кампания, разделённая между двумя интерфейсами, показывала один результат.

Как перейти с SMS API на SMPP?

Переходите постепенно, оставив работающими оба интерфейса, и измеряйте результат, прежде чем переносить объём.

1. Подтвердите необходимость: задокументируйте объём или пропускную способность, которых REST не обеспечивает.
2. Запросите подключение: сообщите страны назначения, имена отправителей, ожидаемую пиковую пропускную способность и исходные IP-адреса.
3. Выберите зрелую клиентскую библиотеку для вашего стека и оберните её собственным интерфейсом отправки.
4. Сначала реализуйте обработку отчётов и приведите их к той же модели статусов, что и у вебхуков.
5. Проверьте кодировку: GSM-7, арабский текст, эмодзи и многосегментные сообщения на реальных устройствах.
6. Проверьте сбои: оборвите соединение посреди отправки, спровоцируйте ограничение скорости и проверьте сверку.
7. Запустите параллельно: перенесите на SMPP небольшую долю одного вида трафика и сравните доставку и отчёты.
8. Переносите объём поэтапно, сохраняя REST как резервный путь.

Ниже пример конфигурации bind. Хост, порт и лимиты — условные значения; реальные значения вы получите вместе с выданными учётными данными.

host:                 <provided with your bind>
port:                 <TLS port provided with your bind>
bind type:            transceiver
system_id:            <your system_id>
password:             <your password>
system_type:          (empty unless told otherwise)
interface_version:    0x34
source_addr_ton/npi:  5 / 0   (alphanumeric sender ID)
dest_addr_ton/npi:    1 / 1   (international number)
registered_delivery:  1       (request delivery receipts)
data_coding:          0 (GSM-7) or 8 (UCS-2)
enquire_link:         every 30 seconds while idle
window:               as agreed for your account

Пример из практики: региональный ритейлер добавляет SMPP для выписок

«Souq Rafiq» (условный пример) — интернет-магазин в ОАЭ, Египте и Иордании. Он отправляет OTP и уведомления о заказах через REST API, а шаблоны WhatsApp — через тот же API. Ежемесячные выписки по счёту, которые уходят по SMS всей клиентской базе, выросли настолько, что REST-задача занимает больше времени, чем устраивает бизнес.

• Решение: OTP, уведомления о заказах и WhatsApp остаются на REST. Ежемесячные SMS с выписками переносятся на SMPP-bind типа transceiver.
• Подключение: команда регистрирует два исходных IP-адреса, подтверждает имена отправителей по странам и согласовывает пропускную способность и число bind-сессий.
• Разработка: небольшой SMPP-сервис использует библиотеку с открытым кодом, записывает отчёты в ту же таблицу статусов, что и вебхук, и предоставляет тот же внутренний интерфейс отправки, что и REST-путь.
• Тестирование: выписки на арабском подтверждены как UCS-2 с корректной склейкой на нескольких устройствах.
• Запуск: первой переходит одна страна. После сравнения доставки и времени получения отчётов с базовыми показателями REST остальные страны следуют за ней, а REST остаётся резервным путём.

Частые ошибки

• Выбор SMPP ради престижа. Если REST справляется с вашим объёмом, SMPP лишь добавляет работы.
• Окно, равное 1, и последующие претензии к провайдеру из-за низкой пропускной способности.
• Отсутствие подтверждения deliver_sm, из-за чего отчёты отправляются повторно и включается ограничение скорости.
• Переподключение в жёстком цикле после разрыва, что может выглядеть как атака.
• Смешивание short_message и message_payload в одном PDU, что приводит к ошибкам длины.
• Обычный SMPP через интернет, из-за чего раскрываются учётные данные и содержимое сообщений.
• Две модели статусов в гибридной схеме, из-за чего отчёты расходятся.
• Ограничения: в этом руководстве описана распространённая практика. Размеры окон, скорость, TLS-порты и детали отчётов зависят от провайдера и аккаунта; подтверждайте их при подключении.

Как помогает OmniChannels.ai

OmniChannels.ai предлагает оба варианта. REST API по адресу https://api.broadnet.me использует Bearer-токен и охватывает SMS наряду с WhatsApp, RCS, Messenger, Instagram, Telegram, Email и Push, а статусы доставки приходят на ваш вебхук в едином формате. Для SMS больших объёмов SMPP 3.4 bind-сессии по TLS подключаются на уровне аккаунта, с исходными IP-адресами из белого списка, и используют те же SMS-маршруты через прямое подключение BroadNet к операторам. Реселлеры и оптовые партнёры могут получить выделенные bind-сессии. Начните с документации по SMPP или быстрого старта, либо откройте обзор для разработчиков.