SMPP-аккаунты для клиентов: bind, TPS, DLR и биллинг

Как только технически подготовленный клиент спрашивает «можно ли подключиться по SMPP?», ваша платформа в его глазах перестаёт быть веб-панелью и становится оператором связи. SMPP-аккаунты для клиентов представляют собой возможность, которая привлекает банки, поставщиков OTP, других агрегаторов и любого разработчика, у которого уже есть клиентская библиотека SMPP. И именно здесь небрежная настройка вредит больше всего: клиент без лимита пропускной способности, bind в режиме receiver, который никто не настроил, отчёты о доставке, которые уходят в никуда, журнал операций, который bind обходит стороной. Это руководство служит чек-листом, как сделать всё правильно: от выдачи bind до теста, который вы проводите, прежде чем разрешить клиенту начать работу.

Что такое SMPP-аккаунты для клиентов на самом деле

Через HTTP API клиент отправляет один запрос на каждое сообщение и получает ответ. По SMPP клиент открывает долгоживущую TCP-сессию с вашим SMPP-сервером, один раз проходит аутентификацию с system_id и паролем и передаёт сообщения потоком по этой сессии в виде двоичных пакетов, которые называются PDU. Ваша платформа должна запустить SMPP-сервер (у Smppcube он слушает порт 2775 и показан на странице платформы), принять bind, проверить каждый submit_sm на соответствие аккаунту клиента, поставить его в тот же конвейер, в который поступает трафик из HTTP API, и позже отправить отчёт о доставке обратно по сессии в виде deliver_sm.

Таким образом, SMPP-аккаунт не является отдельным продуктом с собственным биллингом. Это учётные данные в существующем клиентском аккаунте плюс набор ограничений: какие режимы bind, с каких IP-адресов, сколько сессий, с какой скоростью. Учётные данные составляют малую часть. Ограничения и есть аккаунт.

Типы bind и что разрешать

SMPP определяет три режима bind, и в настройках аккаунта должно быть указано, какие из них может использовать клиент:

• Transmitter: только отправка. Клиент отправляет сообщения и получает ответы на отправку (идентификатор сообщения), но больше ничего. Это просто, и именно из-за этого теряются отчёты о доставке: у transmitter нет канала для deliver_sm.
• Receiver: только приём. Клиент получает отчёты о доставке и входящие сообщения (ответы абонентов, если вы направляете их этому клиенту) и не может отправлять.
• Transceiver: и то и другое в одной сессии. Именно такой bind большинство современных клиентских библиотек открывают по умолчанию, и именно его стоит рекомендовать: одна сессия передаёт и отправки, и отчёты о доставке, поэтому рассогласованию взяться неоткуда.

Традиционная схема из одного bind в режиме transmitter и одного в режиме receiver по-прежнему встречается, обычно потому, что так был написан старый клиентский стек. Разрешите её, но учитывайте её как две сессии в лимите аккаунта и убедитесь, что bind в режиме receiver действительно открыт, прежде чем считать, что отчёты о доставке доходят.

Лимиты сессий важнее, чем принято думать. Клиент, который открывает десять bind в режиме transceiver «для резервирования», занимает десять мест в таблице соединений вашего сервера и может передавать в десять раз больше трафика, чем вы планировали. Разумное значение по умолчанию: от двух до четырёх сессий на аккаунт. Клиента, которому нужно больше, стоит перевести на пакет более высокого уровня.

Пропускная способность, окна и ограничение скорости

Пропускная способность в SMPP зависит от двух вещей: сколько PDU клиент может отправить, не дожидаясь подтверждений (окно), и какую скорость вы разрешаете. В руководстве по SMPP и HTTP объясняется, почему один хорошо управляемый bind может передавать сотни сообщений в секунду; здесь же важно то, что на вашей платформе этот поток принимаете вы.

Задайте каждому SMPP-аккаунту лимит в сообщениях в секунду, который следует из договора, а не из возможностей вашего сервера. Клиент, который платит за 10 сообщ./с, получает 10 сообщ./с. Когда он превышает лимит, отвечайте ошибкой ограничения скорости, которую определяет протокол (ESME_RTHROTTLED), а не ставьте излишек молча в очередь. Хорошо написанная клиентская библиотека понимает эту ошибку как сигнал «снизить темп» и сбавляет скорость. Плохо написанная продолжает отправлять с прежним напором, и ваш сервер должен разорвать bind после повторных нарушений и записать в лог причину. Иначе неправильно настроенный цикл повторов одного клиента превратится в задержки для всех.

В настройках аккаунта нужны ещё два числа. Размер окна (для клиентского bind типично от 10 до 20 неподтверждённых PDU; вышестоящие операторы могут разрешать больше) и интервал enquire_link, контрольного сигнала (heartbeat), который поддерживает простаивающую сессию. Сообщите клиенту все три значения при выдаче учётных данных. Самый частый тикет «SMPP не работает» возникает, когда клиентская библиотека настроена на окно, которого ваш сервер не даёт, получает тайм-аут на каждом десятом сообщении и сообщает об этом как о сбое платформы.

Куда уходят отчёты о доставке

Отчёт о доставке (DLR) в SMPP не является ответом на отправку клиента. Он приходит позже, без запроса, в виде deliver_sm на bind клиента в режиме receiver или transceiver, и клиент сопоставляет его с исходным сообщением по идентификатору, который ваш сервер вернул при отправке. Из этого следуют три вывода.

Во-первых, отчёту нужно куда-то прийти. Если клиент подключён только как transmitter и у него нет открытого bind в режиме receiver, у отчёта нет пути. Определите политику заранее: требуйте bind в режиме transceiver, храните отчёты некоторое время, пока не появится bind в режиме receiver, или предложите webhook в качестве канала отчётов для клиентов, которые не могут держать receiver. Молча отбрасывать отчёты нельзя: это единственный вариант, который обязательно вернётся к вам в виде спора.

Во-вторых, отчёт сначала нужен вам и только потом клиенту. Отчёт оператора нужен платформе, чтобы окончательно провести сообщение в журнале операций, показать статус в консоли клиента и пополнить вашу собственную отчётность о качестве доставки по каждому маршруту. Сохраните его, обновите сообщение и только затем передайте дальше. Архитектура, которая лишь пересылает отчёты в bind и ничего не хранит, не даст ответа, когда клиент скажет: «вы списали с меня деньги за 4 000 сообщений, которые так и не дошли».

В-третьих, отчёты приходят примерно с той же скоростью, с какой шла отправка, и отчёты по рассылке приходят после рассылки. Клиент, который отправил 50 000 сообщений за пять минут, получит 50 000 пакетов deliver_sm в следующие десять. Если его bind в режиме receiver медленно подтверждает приём, ваша исходящая очередь отчётов растёт. Сделайте её очередью с видимой глубиной, а не неограниченным буфером, и настройте оповещения по возрасту записей, чтобы зависший bind клиента появился на вашем дашборде раньше, чем клиент откроет тикет.

Имена отправителя, кодировка и типичные ошибки клиентов

SMPP-аккаунту также нужен свод правил. Какие адреса отправителя (имена отправителя) может использовать клиент, буквенно-цифровые или цифровые, и заменяет ли ваш сервер неизвестное имя или отклоняет его? Какие кодировки данных допустимы (GSM 7-bit или UCS-2 для нелатинских алфавитов) и как делятся длинные сообщения (склейка через UDH, которую клиентская библиотека обычно выполняет сама, но не всегда)? Какой срок действия и какой флаг запроса отчёта о доставке (registered delivery) вы требуете, чтобы отчёты вообще запрашивались?

Эти правила должны храниться в аккаунте и применяться в момент отправки с понятным кодом ошибки, а не так, чтобы сообщение было принято, а потом молча отклонено у оператора. Так же как хороший HTTP API возвращает код 400 с указанием причины, хороший SMPP-сервер отклоняет submit_sm с правильным статусом и даёт клиенту исправить ошибку на своей стороне. Каждое правило, которое вы применяете на своей границе, означает на один спор меньше в будущем.

Биллинг по bind: журнал операций принадлежит аккаунту

Именно эта часть ломается, когда SMPP-сервер пристроен сбоку от платформы, а не встроен в неё. Сообщение, которое поступает по SMPP, должно тарифицироваться и списываться точно так же, как сообщение, поступившее через консоль или HTTP API: тот же тарифный план, тот же баланс, та же маржа, записанная по тому же маршруту. Три режима биллинга из руководства по биллингу (CreditRoute, WalletRoute и AutoRoute) применяются к аккаунту, и bind наследует их. Когда баланс доходит до нуля, SMPP-сервер должен отклонить отправку с соответствующей ошибкой, а не принимать трафик в очередь, за которую никто никогда не заплатит.

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

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

Онбординг клиента: пакет учётных данных

Когда клиенту одобрен доступ по SMPP, отправьте ему один документ, и пусть это каждый раз будет один и тот же документ:

1. Хост, порт и требования к TLS, если TLS терминируется перед SMPP-сервером.
2. system_id и пароль (передаются по каналу, отличному от письма, в котором идёт всё остальное).
3. Разрешённые режимы bind и максимальное число сессий.
4. IP-адреса, с которых вы принимаете bind, и порядок их изменения.
5. Лимит пропускной способности в сообщ./с, размер окна, интервал enquire_link.
6. Разрешённые имена отправителя, правила кодировки, обработка длинных сообщений, обязательный флаг запроса отчёта о доставке (registered delivery).
7. Куда приходят отчёты о доставке и какие коды ошибок клиент должен ожидать и обрабатывать.
8. Тестовый маршрут и тестовые номера, которые нужно использовать до запуска.

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

Тестирование перед запуском

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

Тот же тестовый маршрут пригодится позже, чтобы воспроизвести проблему клиента. Клиент, который сообщает, что «отчёты перестали приходить», может подключиться к тестовому маршруту, отправить одно сообщение и увидеть в консоли, как возвращается отчёт. Так расплывчатый тикет превращается в десятиминутную проверку его bind в режиме receiver.

Когда клиенту не нужен SMPP

Не каждый клиент, который просит SMPP, должен его получить. Маркетинговой команде, которая отправляет рассылки из браузера, bind ни к чему; разработчику, который отправляет 300 OTP в день, лучше подойдёт HTTP API: ему не нужна постоянная сессия, а ошибки в нём понятны человеку. SMPP предназначен для клиентов с объёмом, с уже работающим SMPP-стеком или с требованиями регулирования, по которым нужны прямые отношения на уровне протокола. Все остальные получают API, и нагрузка на вашу поддержку от этого меньше.

Такое предложение убедительно потому, что в его основе одна и та же платформа, а при лицензии на собственном сервере SMPP-сервер входит в комплект и не продаётся как отдельный уровень. Клиент, который начинает с HTTP API и дорастает до SMPP bind, сохраняет свой аккаунт, баланс, тарифный план и отчётность; bind становится ещё одним каналом в омниканальный аккаунт, через который можно передавать также трафик WhatsApp и RCS в том же журнале операций. Именно такую преемственность обычно не может предложить реселлер, который арендует панель, и именно она незаметно удерживает технически подготовленных клиентов.