¿Qué es SMPP? El protocolo del SMS
SMPP sin jerga: binds, ventanas, PDU y la ruta del acuse, y por qué la forma de la sesión importa a volumen.
SMPP es el protocolo con el que una plataforma intercambia mensajes cortos con un centro de mensajes sobre una sesión persistente. Un bind declara la dirección, la sesión lleva una ventana de caudal y los acuses vuelven como PDU. No es una API de petición y respuesta.
Hechos clave
- SMPP es una sesión persistente con una dirección de bind declarada.
- Un bind lleva una asignación de caudal y una ventana de peticiones en vuelo.
- Una PDU tiene una cabecera de 16 bytes y un cuerpo que depende del comando.
- Los acuses llegan de forma asíncrona por la sesión; se emparejan por message ID.
En esta página
Una sesión, no una llamada
SMPP mantiene abierta una conexión entre su plataforma y un centro de mensajes. La plataforma se autentica una vez, declara qué quiere hacer y después envía mensajes y recibe eventos por la misma sesión. El centro no espera una petición nueva para enviar un acuse o un mensaje entrante; empuja una PDU cuando tiene algo que informar.
Esa forma encaja con un flujo constante. El coste por mensaje es bajo porque el estado de la sesión ya está establecido y el canal de acuses ya está abierto. También significa que su cliente es dueño de un estado que un cliente HTTP no tiene: estado del bind, ventana en vuelo, temporización del keep-alive y comportamiento de reconexión.
El bind declara una dirección
Un bind es la sesión autenticada más una dirección. Un bind transmisor envía mensajes. Un bind receptor recibe mensajes originados en el móvil y acuses. Un bind transceptor hace ambas cosas en una sola sesión. El proveedor emite credenciales para cada bind y puede limitar cuántos puede abrir.
Escale añadiendo binds, no empujando un bind por encima de su asignación. Un bind lleva una asignación de caudal y una ventana de peticiones en vuelo. Si su pico necesita más, pida otro bind y reparta el tráfico. Un solo bind forzado por encima de su ventana produce limitación, timeouts y reintentos que parecen un fallo de red pero nacen en el cliente.
Bind, envío, acuse
- Aplicación (ESME)
- bind_transceiver Abrir la sesión
- SMSC
- submit_sm_resp Aceptado para entrega
- Acuse de entrega
Descripción en texto
La aplicación abre un bind y el centro de mensajes responde. La aplicación envía un mensaje corto con submit_sm y recibe submit_sm_resp con un message ID. Más tarde, el centro envía una PDU deliver_sm con el acuse de entrega. La aplicación la confirma con deliver_sm_resp. Un unbind cierra la sesión cuando termina el trabajo.
La ventana es el contrato
La ventana es el número de peticiones que su cliente puede tener en vuelo antes de esperar respuestas. No es una sugerencia. Envíe más de lo que permite la ventana y el centro le limitará; siga reintentando al mismo ritmo y la cola crecerá. Lea el código de respuesta de cada envío, baje el ritmo cuando haya limitación y deje que la ventana se vacíe antes de la siguiente ráfaga.
El tráfico de keep-alive mantiene viva la sesión. Un cliente que nunca envía enquire_link puede quedarse sobre una conexión muerta hasta que falla el primer envío. Un cliente que se reconecta de inmediato tras cada caída puede martillear al proveedor. Use un backoff, limite la tasa de reconexión y alerte cuando el bind lleve caído más de lo que su tráfico tolera.
Una PDU, campo a campo
- command_length
- 53
- command_id
- 0x00000004
- command_status
- 0x00000000
- sequence_number
- 1
- service_type
- source_addr_ton
- 1
- source_addr_npi
- 1
- source_addr
- 12345
- dest_addr_ton
- 1
- dest_addr_npi
- 1
- destination_addr
- 15551234567
- esm_class
- 0x00
- protocol_id
- 0x00
- priority_flag
- 0
- schedule_delivery_time
- validity_period
- registered_delivery
- 0x01
- replace_if_present_flag
- 0x00
- data_coding
- 0x00
- sm_default_msg_id
- 0x00
- sm_length
- 4
- short_message
- 54657374
- Texto
- Test
Descripción en texto
Toda PDU empieza con una longitud de comando de cuatro bytes, un command ID de cuatro bytes, un estado de comando de cuatro bytes y un número de secuencia de cuatro bytes. Después viene el cuerpo. En submit_sm lleva las direcciones de origen y destino, el mensaje corto, la codificación de datos y el indicador de acuse registrado. Los parámetros opcionales viajan como campos etiqueta-longitud-valor.
Un día en la vida de un mensaje
El cliente abre un bind transceptor y lee la respuesta. Envía un mensaje y guarda el message ID de la respuesta. El centro encamina el mensaje a la red de destino. Minutos después llega una PDU deliver_sm con el acuse: el message ID original, un estado y a menudo un código de red. El cliente confirma el acuse y concilia el estado con su propio registro.
Cada paso tiene un modo de fallo. Un bind puede rechazarse por credenciales incorrectas o por una versión de interfaz equivocada. Un envío puede limitarse, rechazarse o aceptarse y fallar después en el acuse. Un acuse puede llegar cuando el código ya caducó. Diseñe el cliente para guardar el message ID, aceptar un acuse tardío y dejar que el estado de la aplicación sea la fuente de verdad sobre lo que hizo el usuario.
Decodifique un acuse antes de depurar una ruta
Pegue un acuse de entrega en el decodificador SMPP y DLR y lea los campos. Compruebe el message ID, el estado, la fecha de finalización y el código de error. Si el estado no es DELIVRD, el código de error, leído contra la tabla de códigos del proveedor, puede indicar si el número, el teléfono o la red rechazaron el mensaje. Hágalo antes de pedir al proveedor que cambie la ruta.
Acuses y depuración
Un acuse es asíncrono. Llega por la sesión como una PDU deliver_sm y su formato depende del centro de mensajes. Las implementaciones nuevas llevan el estado en un campo etiqueta-longitud-valor message_state. Las antiguas ponen un acuse de texto en el campo del mensaje corto, con pares clave-valor como id, stat y err. Analice ambos en lugar de asumir uno.
Empareje por message ID, no por orden de llegada. Dos mensajes enviados con un segundo de diferencia pueden volver en orden inverso, y un reintento puede producir un duplicado. Guarde el ID al enviar, actualice el registro cuando llegue el acuse e ignore un segundo acuse para el mismo ID salvo que su estado sea más reciente. La guía de conexión convierte esto en una secuencia operativa.
Compruebe lo aprendido
-
¿Por qué un segundo bind ayuda más que una tasa de reintento mayor?
Un bind lleva una ventana. Añadir un bind añade capacidad; reintentar contra una ventana llena añade cola y retraso.
-
¿De dónde sale el message ID?
El centro de mensajes lo devuelve en submit_sm_resp. Guárdelo y empareje el acuse posterior por ese ID.
-
¿Qué prueba un acuse de entregado?
Que la red aceptó y entregó el mensaje hacia el teléfono. No prueba que una persona lo leyera.
Las respuestas se muestran a petición. No se puntúa, guarda ni envía nada.
Preguntas frecuentes
¿Necesitamos SMPP para empezar?
¿Qué es un bind?
¿Qué es una PDU?
¿Podemos usar SMPP por internet público?
¿Cómo se gestionan los mensajes largos?
Relacionado
- Conectar por SMPP y HTTP
Llevar una ruta de prueba a producción sin romper binds, ventanas ni acuses: estado del bind, caudal, keep-alive, codificación, callbacks y fallos.
- Paquete de plantillas de RFQ y RFP
Listas de campos para solicitudes de SMS mayorista, eSIM y datos, IoT y conectividad con China, más la lista en línea que se envía como RFQ.
- Informe de muestra de prueba de ruta
Muestra estática anonimizada de un informe de prueba de ruta: qué comprueba una prueba de ruta, cómo se leen los fallos y qué activa una revisión.
Productos relacionados
Póngalo en práctica
Cuéntenos el tráfico, el destino y la medición que necesita; respondemos con el siguiente paso.