# SMPP deliver_sm: сообщения MO и отчёты

> deliver_sm (command_id 0x00000005) отправляется от SMSC к ESME для доставки либо сообщения от абонента (MO), либо отчёта о доставке (DLR). Его тело повторяет submit_sm. Поле esm_class различает эти два случая: бит 0x04 обозначает отчёт о доставке. ESME обязан всегда отвечать deliver_sm_resp.

- Канонический URL: https://www.broadnet.me/ru/reference/smpp-deliver-sm
- Язык: ru
- Последнее обновление: 2026-07-18
- Издатель: BroadNet (https://www.broadnet.me)

deliver_sm несёт от SMSC к ESME две вещи: сообщения от абонентов (MO) и отчёты о доставке. Как различить их по esm_class и почему всегда нужно отвечать deliver_sm_resp.

## Один 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 в deliver_sm*

| 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 учитываются в окне — может застопорить всю сессию. Подтверждайте оперативно, а тяжёлую обработку выполняйте асинхронно.

*MO и DLR, оба подтверждены*

```text
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_ROK
```

## data_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. Собирайте их по номеру ссылки и последовательности, как и исходящие сегменты.

## Источники

- [SMPP v3.4 specification — §4.6 deliver_sm](https://smpp.org/SMPP_v3_4_Issue1_2.pdf)
- [SMPP v3.4 specification — Appendix B (receipt format)](https://smpp.org/SMPP_v3_4_Issue1_2.pdf)

## См. также

- [Отчёты о доставке SMPP (формат DLR)](https://www.broadnet.me/ru/reference/smpp-delivery-receipts-dlr)
- [Справочник по submit_sm в SMPP](https://www.broadnet.me/ru/reference/smpp-submit-sm)
- [Декодер DLR (бесплатный инструмент)](https://www.broadnet.me/ru/tools/dlr-decoder)
- [Опциональные параметры TLV в SMPP](https://www.broadnet.me/ru/reference/smpp-tlv-parameters)
- [Двусторонние SMS](https://www.broadnet.me/ru/products/sms-api)