deliver_sm (command_id 0x00000005) отправляется от SMSC к ESME для доставки либо сообщения от абонента (MO), либо отчёта о доставке (DLR). Его тело повторяет submit_sm. Поле esm_class различает эти два случая: бит 0x04 обозначает отчёт о доставке. ESME обязан всегда отвечать deliver_sm_resp.
bind_transceiverОткрыть и аутентифицировать сессиюbind_transceiver_respСессия принятаsubmit_smОтправить сообщениеsubmit_sm_respПринято, возвращен ID сообщенияdeliver_smПодтверждение доставки или входящее сообщениеdeliver_sm_respПодтвержденоenquire_linkKeepalive в режиме ожидания
Один PDU, две задачи
deliver_sm — это ответная операция SMSC-к-ESME для submit_sm, и она использует ту же структуру тела. Она несёт либо входящее сообщение MO (абонент, написавший на ваш длинный номер или короткий код), либо отчёт о доставке, сообщающий о судьбе ранее отправленного вами сообщения. Ваш bind типа receiver или transceiver обрабатывает и то и другое; вы ветвитесь по esm_class, чтобы корректно их разнести.
Различение MO и DLR по esm_class
Биты типа сообщения в esm_class определяют полезную нагрузку. Обычное сообщение MO имеет очищенные биты типа сообщения esm_class. Отчёт о доставке устанавливает бит 0x04. Когда установлен 0x04, short_message содержит текст отчёта в формате Приложения B (id, stat, err…), а TLV receipted_message_id обычно несёт исходный message_id. Не разбирайте текст отчёта как пользовательский контент.
| esm_class (биты типа сообщения) | Полезная нагрузка |
|---|---|
| 0x00 | Обычное сообщение, отправленное с мобильного устройства (MO) |
| 0x04 | Отчёт о доставке SMSC (DLR) |
| 0x08 | Подтверждение доставки SME |
| 0x10 | Ручное/пользовательское подтверждение SME |
| 0x20 | Прерывание разговора (корейский CDMA) |
| 0x40 | Уведомление о промежуточной доставке |
Всегда отвечайте deliver_sm_resp
На каждый deliver_sm ESME обязан вернуть deliver_sm_resp (0x80000005) с совпадающим sequence_number и ESME_ROK. Если вы не подтверждаете, SMSC считает доставку неудачной, отправляет её повторно и — поскольку неподтверждённые PDU учитываются в окне — может застопорить всю сессию. Подтверждайте оперативно, а тяжёлую обработку выполняйте асинхронно.
SMSC → ESME deliver_sm seq=88 esm_class=0x00 (MO: user text)
ESME → SMSC deliver_sm_resp seq=88 status=ESME_ROK
SMSC → ESME deliver_sm seq=89 esm_class=0x04 (DLR: id:... stat:DELIVRD)
ESME → SMSC deliver_sm_resp seq=89 status=ESME_ROKdata_sm как альтернатива
data_sm (0x00000103) — это более лёгкая, упрощённая операция, способная переносить сообщения MO и отчёты с помощью TLV (в частности message_payload) вместо фиксированного поля short_message. Некоторые сети предпочитают её для интерактивного трафика или трафика в стиле WAP. Поддержка опциональна и зависит от провайдера — уточните перед использованием.
Часто задаваемые вопросы
Как отличить отчёт о доставке от входящего сообщения MO?
Проверьте esm_class в deliver_sm. Если бит типа сообщения 0x04 установлен, это отчёт о доставке, и short_message содержит текст отчёта в формате Приложения B. Если эти биты очищены, это обычное сообщение от абонента.
Что произойдёт, если я не отправлю deliver_sm_resp?
SMSC решит, что доставка не удалась, и отправит deliver_sm повторно. Неподтверждённые PDU также расходуют ваше окно, поэтому отсутствие ответа может застопорить сессию и привести к дублированной обработке MO/DLR.
Совпадают ли поля deliver_sm с полями submit_sm?
Да — deliver_sm повторно использует структуру тела submit_sm (service_type, адресация TON/NPI, esm_class, data_coding, short_message и т. д.). Отличаются только направление и интерпретация полезной нагрузки.
Может ли одно сообщение MO быть конкатенированным?
Да. Длинные входящие сообщения приходят в нескольких PDU deliver_sm с заголовком конкатенации UDH (установлен бит UDHI 0x40 в esm_class) или с TLV SAR. Собирайте их по номеру ссылки и последовательности, как и исходящие сегменты.
Технические характеристики источника
На этой странице представлены опубликованные стандарты, на которых они основаны. (Открывается в новой вкладке)