# SMPP deliver_sm: mensajes MO y confirmaciones de entrega

> deliver_sm (command_id 0x00000005) se envía del SMSC al ESME para entregar un mensaje originado en móvil (MO) o una confirmación de entrega (DLR). Su cuerpo refleja el de submit_sm. El campo esm_class distingue ambos: el bit 0x04 marca una confirmación de entrega. El ESME siempre debe responder con deliver_sm_resp.

- URL canónica: https://www.broadnet.me/es/reference/smpp-deliver-sm
- Idioma: es
- Última actualización: 2026-07-18
- Editor: BroadNet (https://www.broadnet.me)

deliver_sm transporta dos cosas del SMSC al ESME: mensajes originados en móvil (MO) y confirmaciones de entrega. Cómo distinguirlos con esm_class y por qué siempre debes responder deliver_sm_resp.

## Una PDU, dos funciones

deliver_sm es la contrapartida del SMSC al ESME de submit_sm y comparte la misma disposición del cuerpo. Transporta un mensaje MO de entrada (un abonado que escribe a tu número largo o código corto) o una confirmación de entrega que informa del destino de un mensaje que enviaste antes. Tu bind receiver o transceiver gestiona ambos; te ramificas según esm_class para enrutarlos correctamente.

## Distinguir MO de DLR con esm_class

Los bits de tipo de mensaje de esm_class identifican la carga. Un mensaje MO normal tiene los bits de tipo de mensaje de esm_class a cero. Una confirmación de entrega activa el bit 0x04. Cuando 0x04 está activo, short_message contiene el texto de acuse del Apéndice B (id, stat, err…) y el TLV receipted_message_id suele transportar el message_id original. No analices el texto del acuse como contenido de usuario.

*Valores del tipo de mensaje de esm_class en deliver_sm*

| esm_class (bits de tipo de mensaje) | Payload |
|---|---|
| 0x00 | Mensaje normal originado en el móvil (MO) |
| 0x04 | Confirmación de entrega SMSC (DLR) |
| 0x08 | Acuse de recibo de entrega SME |
| 0x10 | Acuse manual/de usuario del SME |
| 0x20 | Interrupción de la conversación (CDMA coreano) |
| 0x40 | Notificación de entrega intermedia |

## Responde siempre con deliver_sm_resp

Por cada deliver_sm, el ESME debe devolver un deliver_sm_resp (0x80000005) con el mismo sequence_number y ESME_ROK. Si no confirmas, el SMSC trata la entrega como fallida, la reenvía y —dado que las PDU pendientes sin confirmar cuentan contra la ventana— puede bloquear toda la sesión. Confirma con prontitud y realiza el procesamiento pesado de forma asíncrona.

*MO y 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

data_sm (0x00000103) es una operación más ligera y simplificada que puede transportar mensajes MO y acuses usando TLV (en particular message_payload) en lugar del campo fijo short_message. Algunas redes lo prefieren para tráfico interactivo o de estilo WAP. Su compatibilidad es opcional y depende del proveedor: confírmalo antes de depender de él.

## Preguntas frecuentes

### ¿Cómo distingo una confirmación de entrega de un mensaje MO de entrada?

Comprueba esm_class en el deliver_sm. Si el bit de tipo de mensaje 0x04 está activo, es una confirmación de entrega y short_message contiene el texto de acuse del Apéndice B. Si esos bits están a cero, es un mensaje normal originado en móvil de un abonado.

### ¿Qué ocurre si no envío deliver_sm_resp?

El SMSC asume que la entrega falló y reenvía el deliver_sm. Las PDU sin confirmar también consumen tu ventana, así que no responder puede bloquear la sesión y provocar procesamiento duplicado de MO/DLR.

### ¿deliver_sm tiene los mismos campos que submit_sm?

Sí: deliver_sm reutiliza la disposición del cuerpo de submit_sm (service_type, direccionamiento TON/NPI, esm_class, data_coding, short_message, etc.). Solo cambian la dirección y la interpretación de la carga.

### ¿Puede concatenarse un único mensaje MO?

Sí. Los mensajes de entrada largos llegan como varias PDU deliver_sm con una cabecera de concatenación UDH (bit UDHI 0x40 de esm_class activo) o con TLV SAR. Reensámblalos por número de referencia y secuencia igual que harías con los segmentos de salida.

## Fuentes

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

## Relacionado

- [Confirmaciones de entrega SMPP (formato DLR)](https://www.broadnet.me/es/reference/smpp-delivery-receipts-dlr)
- [Referencia SMPP submit_sm](https://www.broadnet.me/es/reference/smpp-submit-sm)
- [Decodificador DLR (herramienta gratuita)](https://www.broadnet.me/es/tools/dlr-decoder)
- [Parámetros opcionales SMPP TLV](https://www.broadnet.me/es/reference/smpp-tlv-parameters)
- [SMS bidireccional](https://www.broadnet.me/es/products/sms-api)