# SMPP deliver_sm: mensagens MO e recibos

> O deliver_sm (command_id 0x00000005) é enviado do SMSC para o ESME para entregar quer uma mensagem originada no terminal (MO) quer um relatório de entrega (DLR). O seu corpo espelha o submit_sm. O campo esm_class distingue os dois: o bit 0x04 marca um relatório de entrega. O ESME tem de responder sempre com deliver_sm_resp.

- URL canônico: https://www.broadnet.me/pt/reference/smpp-deliver-sm
- Idioma: pt
- Última atualização: 2026-07-18
- Editor: BroadNet (https://www.broadnet.me)

O deliver_sm transporta duas coisas do SMSC para o ESME: mensagens originadas no terminal (MO) e relatórios de entrega. Como distingui-las com esm_class e porque tem de responder sempre deliver_sm_resp.

## Um PDU, duas funções

O deliver_sm é a contraparte SMSC-para-ESME do submit_sm e partilha a mesma disposição de corpo. Transporta quer uma mensagem MO de entrada (um subscritor a enviar SMS para o seu long number ou short code) quer um relatório de entrega que reporta o destino de uma mensagem que submeteu antes. O seu bind receiver ou transceiver trata de ambos; bifurca com base no esm_class para os encaminhar corretamente.

## Distinguir MO de DLR com o esm_class

Os bits de tipo de mensagem do esm_class identificam o conteúdo. Uma mensagem MO simples tem os bits de tipo de mensagem do esm_class a zero. Um relatório de entrega ativa o bit 0x04. Quando 0x04 está ativo, o short_message contém o texto do recibo do Apêndice B (id, stat, err…) e o TLV receipted_message_id transporta normalmente o message_id original. Não interprete o texto do recibo como conteúdo de utilizador.

*Valores de tipo de mensagem do esm_class no deliver_sm*

| esm_class (bits de tipo de mensagem) | Payload |
|---|---|
| 0x00 | Mensagem normal originada em dispositivo móvel (MO) |
| 0x04 | Relatório de entrega SMSC (DLR) |
| 0x08 | Relatório de entrega do SME |
| 0x10 | Confirmação manual/do utilizador pelo SME |
| 0x20 | Interrupção de conversa (CDMA coreano) |
| 0x40 | Notificação de entrega intermediária |

## Responda sempre com deliver_sm_resp

Para cada deliver_sm o ESME tem de devolver um deliver_sm_resp (0x80000005) com sequence_number correspondente e ESME_ROK. Se não confirmar, o SMSC trata a entrega como falhada, reenvia-a e — porque os PDUs pendentes por confirmar contam contra a janela — pode bloquear toda a sessão. Confirme prontamente e faça o processamento pesado de forma assíncrona.

*MO e DLR ambos confirmados*

```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 como alternativa

O data_sm (0x00000103) é uma operação mais leve e simplificada que pode transportar mensagens MO e recibos usando TLVs (nomeadamente message_payload) em vez do campo fixo short_message. Algumas redes preferem-no para tráfego interativo ou de estilo WAP. O suporte é opcional e específico do fornecedor — confirme antes de depender dele.

## Perguntas frequentes

### Como distingo um relatório de entrega de uma mensagem MO de entrada?

Verifique o esm_class no deliver_sm. Se o bit de tipo de mensagem 0x04 estiver ativo, é um relatório de entrega e o short_message contém o texto do recibo do Apêndice B. Se esses bits estiverem a zero, é uma mensagem normal originada no terminal por um subscritor.

### O que acontece se eu não enviar deliver_sm_resp?

O SMSC assume que a entrega falhou e reenvia o deliver_sm. Os PDUs não confirmados também consomem a sua janela, pelo que não responder pode bloquear a sessão e produzir processamento duplicado de MO/DLR.

### O deliver_sm tem os mesmos campos que o submit_sm?

Sim — o deliver_sm reutiliza a disposição de corpo do submit_sm (service_type, endereçamento TON/NPI, esm_class, data_coding, short_message, e assim por diante). Só diferem a direção e a interpretação do conteúdo.

### Uma única mensagem MO pode ser concatenada?

Sim. Mensagens de entrada longas chegam como vários PDUs deliver_sm com um cabeçalho de concatenação UDH (bit UDHI 0x40 do esm_class ativo) ou TLVs SAR. Remonte-as por número de referência e sequência tal como faria com os segmentos de saída.

## Fontes

- [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)

## Relacionados

- [Relatórios de entrega SMPP (formato DLR)](https://www.broadnet.me/pt/reference/smpp-delivery-receipts-dlr)
- [Referência submit_sm SMPP](https://www.broadnet.me/pt/reference/smpp-submit-sm)
- [Decodificador DLR (ferramenta gratuita)](https://www.broadnet.me/pt/tools/dlr-decoder)
- [Parâmetros opcionais SMPP TLV](https://www.broadnet.me/pt/reference/smpp-tlv-parameters)
- [SMS bidirecional](https://www.broadnet.me/pt/products/sms-api)