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.
bind_transceiverAbrir y autenticar la sesiónbind_transceiver_respSesión aceptadasubmit_smEnviar un mensajesubmit_sm_respAceptado, ID de mensaje devueltodeliver_smConfirmación de entrega o mensaje entrantedeliver_sm_respConfirmadoenquire_linkKeepalive en estado de inactividad
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.
| 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.
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 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.
Especificaciones de la fuente
Las normas publicadas en las que se basa esta página. Se abre en una pestaña nueva.