SMPP v5.0 es compatible con versiones anteriores respecto a la v3.4 y añade señalización de control de congestión, operaciones de mensajería de difusión (broadcast_sm y afines), un estado de mensaje adicional (SKIPPED) y TLV extra. Pese a ello, la v3.4 sigue siendo la interconexión dominante porque está universalmente soportada; la v5.0 solo se usa cuando ambos extremos la implementan.
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
Qué añade la v5.0
La v5.0 es una revisión incremental y compatible de la v3.4. Sus incorporaciones principales son el control de congestión (el SMSC anuncia la carga para que los ESME reduzcan el ritmo antes de ser limitados), una familia de operaciones de difusión para mensajería de tipo cell broadcast, un nuevo estado de mensaje SKIPPED y parámetros opcionales extra. El formato básico de la PDU, el modelo de bind y submit_sm/deliver_sm no cambian, y por eso un ESME v3.4 puede comunicarse con un SMSC v5.0.
| Área | v3.4 | Adición de la v5.0 |
|---|---|---|
| Control de congestión | Ninguno (reaccionar a la limitación de tasa) | congestion_state TLV — proactivo |
| Difusión | No compatible | broadcast_sm / query_broadcast_sm / cancel_broadcast_sm |
| Estados del mensaje | 8 estados | Añade SKIPPED (9) |
| Parámetros opcionales | Conjunto de TLV v3.4 | TLV adicionales |
| interface_version | 0x34 | 0x50 |
Qué permaneció igual
Los fundamentos son idénticos: la cabecera de 16 bytes, la codificación big-endian, los tres tipos de bind, los estados de sesión, el keepalive enquire_link, las disposiciones de campos de submit_sm/deliver_sm y el rango de errores ESME_R* se conservan. Los TLV —introducidos en la v3.4— siguen siendo el mecanismo de extensión. Esta continuidad es deliberada: la v5.0 se diseñó para que las integraciones v3.4 existentes sigan funcionando.
Qué versión usar
Usa la v3.4 salvo que tengas un motivo concreto para usar la v5.0 y ambos extremos la admitan. La v3.4 es el valor por defecto seguro y universal para la interconexión A2P. Recurre a la v5.0 cuando necesites específicamente su señalización de congestión o sus operaciones de difusión y el proveedor confirme el soporte. Confirma siempre la versión negociada a partir del bind_resp (el TLV sc_interface_version) en lugar de asumir que una función está disponible.
Preguntas frecuentes
¿SMPP v5.0 es compatible con versiones anteriores respecto a la v3.4?
Sí. La v5.0 conserva el formato de PDU, el modelo de bind y las operaciones básicas de la v3.4, así que un ESME v3.4 y un SMSC v5.0 pueden interoperar. La versión se declara en interface_version (0x34 frente a 0x50).
¿Por qué sigue siendo la v3.4 la versión más común?
Porque está universalmente implementada y cubre por completo las necesidades de la mensajería A2P. Las incorporaciones de la v5.0 —control de congestión, difusión— son útiles en escenarios concretos pero no imprescindibles para el tráfico MT/MO estándar, así que la mayoría de interconexiones se quedaron en la v3.4.
¿Cuál es la principal ventaja práctica de la v5.0?
El control de congestión proactivo: el TLV congestion_state permite al SMSC anunciar su carga para que un ESME cooperativo reduzca el ritmo antes de encontrarse errores ESME_RTHROTTLED estrictos, logrando un rendimiento más suave bajo presión.
¿Cómo sé qué versión negoció una sesión?
Lee el TLV sc_interface_version devuelto en el bind_resp. No asumas que las funciones de la v5.0 están disponibles solo porque enviaste interface_version 0x50: el SMSC informa de lo que realmente admite.
Especificaciones de la fuente
Las normas publicadas en las que se basa esta página. Se abre en una pestaña nueva.