Lista de verificación de integración SMPP

Elija el modo de bind correcto para la dirección de su tráfico y confirme la versión de protocolo negociada antes de enviar un solo mensaje.

• Confirme la versión de SMPP — v3.4 para la mayoría de las rutas, v5.0 donde el proveedor admita el estado de congestión y TLV mejorados.La v5.0 es compatible hacia atrás; no asuma que las funciones están disponibles hasta que el bind_resp lo confirme.
• Elija el tipo de bind correcto por sesión.transmisor (solo MT), receptor (solo DLR/MO), o transceptor (ambos en una sola sesión). Prefiera el transceptor para reducir a la mitad el número de conexiones donde el proveedor lo permita.
• Configure system_id, password, system_type y address_range exactamente como se aprovisionaron.Un address_range mal configurado bloquea silenciosamente el enrutamiento de MO/DLR en los binds de receptor.
• Acuerde por escrito con el proveedor el número de binds concurrentes y el TPS por bind.Abrir más binds de los aprovisionados es la causa más común de una cuenta limitada (throttled) o suspendida.
• Gestione explícitamente los códigos de estado de bind_resp — reintente ESME_RALYBND y reduzca el ritmo ante ESME_RBINDFAIL.Nunca reintente un bind fallido en bucle continuo; use retroceso exponencial con jitter.

• Configure correctamente source_addr_ton / source_addr_npi y dest_addr_ton / dest_addr_npi para sender ID alfanuméricos frente a numéricos.Remitente alfanumérico → TON 5 (alfanumérico); MSISDN internacional → TON 1, NPI 1.
• Elija el data_coding correcto: GSM de 7 bits (0), 8 bits (4), o UCS-2 (8) para Unicode.Mezclar codificaciones sin configurar data_coding causa mojibake y una segmentación incorrecta.
• Implemente la concatenación de mensajes largos mediante UDH o los TLV opcionales SAR (sar_msg_ref_num, sar_total_segments, sar_segment_seqnum).Elija un método y manténgalo; algunas rutas rechazan UDH, otras rechazan los TLV SAR.
• Solicite confirmaciones de entrega con registered_delivery = 1 solo donde los consuma.Solicitar DLR que no procesa desperdicia rendimiento y puede generar advertencias por parte del proveedor.
• Respete la semántica de validity_period y schedule_delivery_time para su caso de uso (OTP = validez corta).Los OTP de corta duración deben llevar un validity_period ajustado para que los mensajes obsoletos no se entreguen tarde.

• message_payload — para cargas útiles que superan el límite del campo short_message.No rellene a la vez short_message y message_payload; los proveedores lo rechazan.
• TLV sar_* — concatenación basada en estándares sin bytes UDH en el cuerpo.
• dest_addr_subunit / source_addr_subunit — donde la ruta lo requiera para el enrutamiento al terminal.
• Transporte los metadatos proporcionados por el cliente solo en TLV aprobados por el proveedor.Los TLV personalizados fuera del rango acordado suelen eliminarse o provocar errores de análisis más adelante.

Las confirmaciones de entrega llegan como PDU deliver_sm y son la columna vertebral de su conciliación y de los informes de calidad.

• Analice el recibo del campo short_message de deliver_sm: id, sub, dlvrd, fecha de envío, fecha de finalización, stat, err.El campo `stat` (DELIVRD, UNDELIV, EXPIRED, REJECTD, etc.) es su estado terminal.
• Correlacione los DLR con su envío usando el formato de message_id del proveedor, no solo el texto del recibo.El message_id puede devolverse en hexadecimal en submit_resp pero en decimal en el DLR — normalice ambos.
• Trate los recibos intermedios (no finales) por separado de los estados finales.El bit 0x04 de esm_class marca una confirmación de entrega; solo los valores `stat` finales deberían cerrar un mensaje.
• Devuelva siempre un deliver_sm_resp — un DLR no confirmado se reenvía y puede bloquear la ventana.Responda con prontitud aunque el procesamiento posterior sea asíncrono.
• Asigne los códigos de error del operador a una taxonomía normalizada (suscriptor ausente, terminal ocupado, bloqueado como spam, número inválido).Los códigos de error en bruto varían según la ruta; una taxonomía normalizada permite comparar la calidad entre rutas.

• Envíe enquire_link con un temporizador de inactividad (habitualmente 30-60 s) y trate una ausencia de enquire_link_resp como una sesión muerta.Esta es la única forma fiable de detectar una conexión TCP semiabierta.
• Implemente la ventana de SMPP: limite los PDU pendientes sin confirmar y pause los envíos cuando la ventana esté llena.Disparar submit_sm a ciegas más allá de la ventana es lo que provoca ESME_RTHROTTLED.
• Reduzca el ritmo ante ESME_RTHROTTLED (0x58) en lugar de reintentar de inmediato.Añada jitter para que las tormentas de reconexión no se sincronicen entre los procesos worker.
• Respete unbind / unbind_resp para un cierre ordenado; reconéctese con retroceso ante desconexiones inesperadas.

• Use SMPP sobre TLS donde el proveedor lo ofrezca; desactive los binds en texto plano en producción.SMPP no tiene cifrado nativo — TLS es el control de la capa de transporte.
• Fije o valide la cadena de certificados del servidor y exija TLS 1.2 o superior.Rechace certificados caducados o autofirmados; no desactive la verificación 'para que funcione'.
• Restrinja los binds a IP de origen en lista blanca en ambos extremos.La lista blanca de IP es un control estándar del operador y una forma rápida de contener fugas de credenciales.
• Rote las credenciales de SMPP según un calendario y almacénelas en un gestor de secretos, nunca en el código.

• Envíe a un MSISDN de prueba en vivo en cada ruta objetivo y confirme la recepción en el terminal de extremo a extremo.
• Verifique el ciclo completo de DLR para los resultados entregado, no entregado, expirado y rechazado.
• Pruebe mensajes largos (multisegmento) y contenido Unicode (UCS-2) en cada ruta.
• Realice pruebas de carga con su TPS aprovisionado y confirme un comportamiento adecuado en el límite de ventana/throttle.
• Simule una conexión caída a mitad de ventana y confirme una reconexión limpia y sin envíos duplicados.La idempotencia en los reintentos evita la doble facturación y la entrega duplicada al terminal.
• Confirme la monitorización: el estado del bind, la ocupación de la ventana, la latencia de envío/DLR y las tasas de códigos de error generan alertas.