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.
Una conexión de mensajería en producción es un contrato operativo, no solo un endpoint. SMPP añade estado de bind, una ventana de caudal, tráfico de keep-alive y acuses en la sesión. HTTP añade autenticación por petición y callbacks. La guía convierte ambos en una secuencia de prueba a producción.
En esta página
El estado del bind es lo primero que hay que dominar
Un bind es una sesión con una dirección declarada. Un transmisor envía, un receptor acepta mensajes entrantes y acuses, y un transceptor hace ambas cosas. El proveedor emite credenciales para el tipo de bind que necesita, y el cliente debe tratar el bind como estado: abriendo, enlazado, limitado, reconectando o cerrado. Un cliente que da por hecho que el bind siempre está arriba perderá mensajes en la primera caída.
Registre el estado del bind de forma explícita. Anote cada petición y respuesta de bind, la versión de interfaz, el system ID y el código de error. En una caída, reconecte con backoff y no reenvíe los envíos en vuelo hasta saber si el centro los aceptó. El message ID de submit_sm_resp es la única forma fiable de saberlo.
El bind y el primer envío
- Aplicación (ESME)
- bind_transceiver Abrir la sesión
- SMSC
- submit_sm_resp Aceptado para entrega
- Acuse de entrega
Descripción en texto
El cliente envía una petición de bind y recibe una respuesta. Envía un mensaje 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, y el cliente responde con deliver_sm_resp. Un unbind cierra la sesión.
Ventana, heartbeat y codificación
La ventana es el número de peticiones en vuelo que el centro aceptará en un bind. Mantenga el contador por debajo y deje que la ventana se vacíe antes de una ráfaga. Un envío limitado es una señal para bajar el ritmo; reintentar al mismo ritmo llena la cola y convierte un mensaje lento en un atasco. Dimensione el número de binds desde la tasa de pico, no desde la media mensual.
Los intercambios de keep-alive dicen a ambos extremos que la sesión sigue viva. Envíe enquire_link con una cadencia y cierre una sesión que deja de responder. Para la codificación, envíe GSM-7 cuando el contenido lo permita y UCS-2 en caso contrario. Un solo carácter fuera del conjunto GSM-7 cambia todo el mensaje a UCS-2 y puede cambiar el número de segmentos. Pruebe la plantilla exacta, incluidos los valores de las variables.
Acuses de entrega
Un acuse llega de forma asíncrona como una PDU deliver_sm. Lleva el message ID original, un estado como entregado, caducado, no entregado o desconocido, y a menudo un código de red. Empareje por message ID y guarde el estado con el registro del mensaje. No empareje por orden de llegada y no trate un acuse ausente como un mensaje fallido.
Los formatos de acuse difieren. Los centros nuevos usan un campo etiqueta-longitud-valor message_state; los antiguos ponen texto clave-valor en el campo del mensaje corto. Analice ambos. Normalice los estados que necesita su aplicación y guarde el código crudo, para que un caso de soporte se pueda rastrear hasta lo que dijo la red.
Modos de fallo y primera respuesta
| Síntoma | Causa probable | Primera comprobación |
|---|---|---|
| Bind rechazado | Credenciales, tipo de bind o versión de interfaz incorrectos | Lea el código de respuesta del bind y la versión de interfaz |
| Timeouts al alza | Ventana excedida o ruta lenta | Revise las peticiones en vuelo y los códigos de respuesta antes de reintentar |
| Bind abierto, sin respuestas | La sesión está muerta o el cliente dejó el keep-alive | Envíe enquire_link y reconecte con backoff |
| Acuse ausente | El acuse nunca llegó al manejador | Revise el registro de la sesión y el message ID antes de reenviar |
| Caracteres erróneos | Contenido GSM-7 enviado como UCS-2, o al revés | Revise la codificación de datos y el número de segmentos |
| Callback con timeout | El endpoint es lento o inalcanzable | Responda rápido, procese de forma asíncrona, verifique la firma |
El orden de la respuesta importa: observe y después cambie una variable.
De la ruta de prueba a producción
-
Conecte a la ruta de prueba
Use las credenciales de prueba y el tipo de bind que usará en producción. Confirme la respuesta del bind y la versión de interfaz.
-
Envíe las plantillas reales
Pruebe el contenido que va a lanzar, con enlaces, variables y el mensaje más largo. Registre la codificación y el número de segmentos.
-
Lea los acuses
Empareje cada acuse por message ID. Confirme los estados y los códigos de error que recibirá su aplicación.
-
Pruebe el camino de fallo
Envíe a un número inválido, a un teléfono lleno y a un servicio bloqueado. Confirme los estados y el tratamiento de la aplicación.
-
Dimensione la ventana
Ejecute una prueba a tasa de pico y confirme que las peticiones en vuelo siguen bajo la ventana. Añada un bind si no.
-
Active la monitorización
Alerte sobre el estado del bind, la latencia de envío, la latencia de acuse y la mezcla de estados. Nombre a la persona que actúa ante cada alerta.
-
Cambie el tráfico de producción
Mueva primero una cuota pequeña, compare los acuses con la prueba y aumente. Mantenga la ruta de prueba como respaldo.
Autenticación HTTP y callbacks
Una integración HTTP autentica cada petición con la clave emitida en el onboarding. Rote la clave antes de que caduque y mantenga la anterior válida durante el solapamiento. Un envío devuelve una respuesta aceptada con un message ID; el acuse y cualquier mensaje entrante llegan a su URL de callback.
El endpoint de callback debe verificar la firma, responder rápido y procesar el evento después de la respuesta. Un endpoint lento provoca reintentos, y los reintentos provocan duplicados si el manejador no es idempotente. Mantenga el endpoint accesible ante cambios de certificado y DNS, y alerte cuando suba la tasa de fallos del callback. La explicación de SMPP cubre la sesión; la comparación de transportes cubre la elección.
Preguntas frecuentes
¿Qué versión de SMPP deberíamos usar?
¿Cuántos binds necesitamos?
¿El callback debe responder antes de procesar?
¿Y si nunca llega un acuse?
¿Cómo probamos un fallo?
Relacionado
- Manual global de sender ID para A2P
Cómo funcionan los sender ID en los mercados: rutas alfanuméricas, numéricas y de código corto, expectativas de registro y ejemplos de países.
- SMS A2P
SMS de aplicación a persona: el que una aplicación envía a un teléfono, como un código de verificación, por una ruta con remitente registrado.
- DLR
Un recibo de entrega informa del estado que la red móvil asigna a un SMS enviado: entregado, caducado, rechazado o desconocido, entre otros.
Adyacente a lo que ofrecemos
Lo explicamos aquí porque afecta al uso de nuestro servicio.