Симулятор SMPP сессии.

Как на самом деле работает сессия SMPP

1. 1 · Связать. Ваше приложение устанавливает TCP-соединение с SMSC и отправляет команду bind_transceiver с system_id и паролем. Пока SMSC не ответит командой command_status 0, никакие другие данные не принимаются.
2. 2 · Отправить. Каждое сообщение представляет собой PDU submit_sm. Ответ содержит message_id — это подтверждение принятия, а не доставки.
3. 3 · Чек. Если вы запросили его, SMSC позже отправит deliver_sm с идентификатором esm_class 0x04 и телом отчёта о доставке, ссылающимся на этот message_id.
4. 4. Оставайтесь в живых. enquire_link каждые 30–60 секунд подтверждает работоспособность сокета. Если вы пропустите этот запрос, SMSC разорвет соединение.
5. 5 · Развязать. Завершите процесс вежливо, чтобы оператор не посчитал это нештатным отключением.

Вопросы, которые задают инженеры

Этот симулятор отправляет настоящие SMS ?

Нет. Ничто на этой странице не устанавливает соединение и не отправляет сообщение куда-либо. Каждый PDU и каждый ответ SMSC вычисляются в вашем браузере на основе введенных вами значений, поэтому одни и те же входные данные всегда приводят к одному и тому же результату. Это обучающий инструмент для протокола, а не инструмент для отправки сообщений.

Что такое привязка (bind) в SMPP ?

Привязка (bind) — это рукопожатие сессии между ESME (вашим приложением) и SMSC (центром обмена сообщениями оператора). bind_transmitter может только отправлять данные, bind_receiver — только получать, а bind_transceiver делает и то, и другое по одному соединению — именно это используется в большинстве интеграций. Никакие другие данные не принимаются в сессии до тех пор, пока привязка не будет успешно завершена.

Что делает функция registered_delivery?

Установка параметра registered_delivery в значение 1 запрашивает у SMSC подтверждение окончательного результата. Это подтверждение поступает позже в виде отдельного PDU deliver_sm содержащего esm_class 0x04 — отчёт о доставке, — который ссылается на message_id, предоставленный вам в submit_sm_resp. Без него вы узнаете только о том, что SMSC принял сообщение, а не о том, что телефон его получил.

Почему моё сообщение разбивается на несколько частей?

Один PDU SMS содержит 160 символов в алфавите GSM-7 или 70 в UCS-2. Более длинный текст объединяется: каждая часть отдает 6 октетов заголовку пользовательских данных, чтобы телефон мог собрать их заново, в результате чего на сегмент приходится 153 или 67 символов. Один арабский символ или один эмодзи заставляет все сообщение соответствовать стандарту UCS-2, поэтому 100-символьное сообщение на арабском языке стоит два сегмента.

В чём разница между submit_sm_resp и отчётом о доставке?

submit_sm_resp — синхронное событие, означающее лишь то, что SMSC принял PDU и присвоил ему message_id. Подтверждение доставки приходит асинхронно, часто через несколько секунд или минут, и сообщает о реальном результате — DELIVRD, UNDELIV, EXPIRED, REJECTD. Рассматривать submit_sm_resp как подтверждение доставки — самая распространенная ошибка при первой интеграции SMPP.

Что такое окно SMPP и почему оно ограничивает мою пропускную способность?

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