Fallback A2P SMS: cuándo cambiar de ruta y cuándo detener el tráfico para investigar

El fallback A2P SMS es una medida de contención, no una garantía de entrega

El fallback A2P SMS consiste en desviar de forma controlada una parte o la totalidad del tráfico desde una ruta primaria hacia una ruta alternativa cuando existen señales suficientes de degradación. Su propósito es reducir el impacto operativo mientras se valida la causa del problema. No convierte el SMS en un canal con garantía de entrega ni elimina la necesidad de investigar la calidad de la ruta original.

En SMPP, la respuesta a submit_sm confirma el resultado de esa solicitud de protocolo y normalmente devuelve un message_id asignado por el SMSC. No confirma que el mensaje haya llegado al terminal. Para conocer el resultado posterior, el ESME debe solicitar un SMSC Delivery Receipt o consultar el estado cuando esa operación esté disponible.

Por ello, una política de fallback madura debe decidir dos cosas por separado: cuándo es razonable probar otra ruta y cuándo el comportamiento observado exige detener o limitar tráfico para conservar evidencia y evitar daños adicionales.

• Trate el fallback como una acción reversible y acotada.
• Mantenga la investigación activa aunque el tráfico alternativo parezca funcionar.
• No use la aceptación de submit_sm como prueba de entrega al destinatario.
• No interprete una recuperación de sesión SMPP como recuperación completa de la ruta.

Qué puede salir mal con un fallback mal diseñado

Un cambio automático de ruta puede proteger una operación crítica, pero también puede amplificar una incidencia. El caso más delicado aparece cuando el mensaje original ha sido aceptado por el SMSC, permanece en curso o su estado final llega con retraso, y el sistema reenvía el mismo contenido por una segunda ruta. El destinatario puede recibir dos mensajes, dos códigos o comunicaciones contradictorias.

También existe un riesgo de diagnóstico. Si el sistema desvía todo el tráfico demasiado pronto, la degradación de la ruta primaria puede quedar oculta tras resultados agregados. Sin cohortes de control, registros correlacionables y límites de alcance, resulta difícil distinguir un fallo de conectividad, una validación incorrecta del destino, una limitación de capacidad o un problema localizado en un destino u operador.

El coste y la trazabilidad importan igualmente. Cada intento debe poder relacionarse con una única intención de envío y con la ruta usada. Sin esta correlación, no es posible determinar si hubo reintento, duplicado, expiración, rechazo o una entrega tardía del primer intento.

• Duplicados por reenviar antes de conocer el resultado del intento inicial.
• Coste no controlado por multiplicar intentos o abrir fallback global.
• Pérdida de evidencia cuando se mezclan resultados de rutas diferentes.
• Degradaciones persistentes ocultas por desviar tráfico sin aislar la causa.
• Decisiones erróneas si se agrupan todos los destinos en un único indicador.

Clasifique el tráfico antes de definir reintentos

La misma política no sirve para todos los mensajes legítimos. La sensibilidad al tiempo, al contexto y a la duplicación debe formar parte de la decisión. Un OTP puede perder valor rápidamente y un segundo envío puede confundir al usuario o invalidar un flujo de autenticación. Una notificación transaccional urgente puede justificar una ruta alternativa limitada, siempre que la aplicación controle la idempotencia del evento de negocio. Una campaña de marketing consentida suele permitir más prudencia: es preferible esperar, reprogramar o investigar antes que duplicar comunicaciones.

La clasificación debe existir antes del incidente, no durante él. Cada intención de envío debería incluir al menos un tipo de mensaje, un plazo de validez, una política de reintento y una regla explícita sobre si admite o no una segunda ruta.

• OTP: ventana de utilidad corta; evite reenvíos ciegos y controle el ciclo de vida del código.
• Transaccional urgente: aplique fallback solo si el evento de negocio admite idempotencia y el riesgo de duplicado está definido.
• Notificación no crítica: priorice la observación, la reprogramación o el envío diferido frente al reintento inmediato.
• Marketing consentido: no use la urgencia como justificación para multiplicar mensajes; respete la política de contacto aplicable.

Señales que pueden justificar un cambio de ruta

Las señales deben evaluarse por capas. Los errores de protocolo inmediatos pueden exigir una reacción distinta de los resultados finales de entrega. SMPP define command_status para comunicar el éxito o fallo de una solicitud. Entre los errores posibles hay errores de sistema, límites de mensajes excedidos y validaciones de direccionamiento. Un error de TON o NPI de destino no es, por sí mismo, evidencia de que la ruta esté degradada: puede indicar un problema de normalización o de configuración del envío.

La disponibilidad de sesión también debe separarse del rendimiento de entrega. Un bind puede estar activo y, aun así, la ruta puede presentar problemas en submit_sm, en la recepción de DLR o en el tratamiento posterior del mensaje. Del mismo modo, que una sesión se recupere no demuestra que los resultados finales hayan vuelto a niveles operativos aceptables.

Una ausencia de DLR puede ser una señal relevante solo si se interpreta frente a la configuración de receipts, la ventana de observación, el tipo de mensaje y el comportamiento histórico conocido de esa integración. Las notificaciones intermedias no ofrecen una base portátil para un fallback global: su soporte es específico de la implementación del SMSC.

• Errores repetidos de protocolo que afectan a submit_sm o a comandos necesarios para operar.
• Throttling o límites de capacidad que requieren reducir ritmo antes de aumentar rutas.
• Errores de dirección, TON o NPI que deben aislarse como posible problema de validación.
• Pérdida o inestabilidad de sesión, diferenciada de los resultados de envío y entrega.
• Degradación observada de estados finales o de latencia, segmentada por destino y ruta.
• Ausencia anómala de DLR, tras verificar que se solicitaron y que la integración los procesa correctamente.

No confunda estados SMPP con recepción independiente en el terminal

La nomenclatura de estados debe manejarse con precisión. ENROUTE significa que el mensaje está en curso; no es una entrega. DELIVERED es un estado distinto dentro de SMPP. ACCEPTED tampoco debe interpretarse como recepción en el terminal: la especificación lo describe como un mensaje aceptado tras haber sido leído manualmente en nombre del abonado por atención al cliente.

Un DLR es valioso para operar y para correlacionar eventos, pero no debe tratarse como una prueba independiente y uniforme en todos los proveedores. SMPP permite que la información de un delivery receipt se inserte en short_message con un formato específico del proveedor de SMSC. Los códigos de error también pueden depender de la red o del SMSC. La normalización interna debe preservar siempre el valor original junto con una clasificación operativa documentada.

La conclusión práctica es sencilla: no active un reenvío solo porque un mensaje siga ENROUTE, porque el DLR aún no haya llegado en una ventana arbitraria o porque un proveedor use una etiqueta textual que parece definitiva. Use reglas basadas en contexto, tiempo de validez, patrón de incidencia y riesgo de duplicado.

• submit_sm_resp: confirma la respuesta al submit, no la entrega final.
• ENROUTE: estado en curso; no dispare un reenvío por este estado aislado.
• DELIVERED: estado de entrega informado por el ecosistema SMS, no una verificación independiente de lectura humana.
• ACCEPTED: no equivale a recepción en el terminal.
• EXPIRED, UNDELIVERABLE, REJECTED y UNKNOWN: deben conservarse como resultados diferenciados para análisis y decisión.

Diseñe umbrales segmentados, no un único interruptor global

Un umbral global mezcla poblaciones que pueden comportarse de forma distinta. La política debe segmentar, como mínimo, por destino normalizado conforme al plan de numeración aplicable. En el intercambio SMPP, destination_addr, TON y NPI forman parte del contexto técnico que conviene registrar y validar. Cuando la telemetría disponible lo permita, añada ruta, tipo de mensaje, remitente, ventana horaria y clase de error.

Los umbrales deben combinar volumen mínimo y ventana temporal. Una variación pequeña con pocas observaciones no debería producir un cambio masivo. Del mismo modo, una degradación concentrada en un destino no debe justificar el desvío de países o destinos no afectados. Defina por adelantado qué combinación de señales genera observación, fallback limitado, contención o investigación.

No es prudente fijar valores universales de porcentaje, minutos o número de reintentos sin conocer el comportamiento contractual, técnico y operativo de cada integración. El umbral correcto es el que puede explicarse, probarse y revisarse con los datos disponibles.

• Exija un mínimo de observaciones antes de evaluar una degradación agregada.
• Mida en ventanas temporales definidas y conserve la hora de cada evento.
• Segmente por destino, ruta, tipo de mensaje y, cuando sea relevante, remitente y clase de error.
• Separe errores de validación de destino de indicadores de calidad de ruta.
• Documente el motivo exacto que activa cada transición de estado.

Defina una máquina de estados operativa

Una política de fallback debe poder expresarse como una máquina de estados que un operador pueda auditar. Esto reduce decisiones ambiguas y evita que una automatización pase directamente de una alerta aislada a un desvío masivo. La máquina de estados no sustituye los estados SMPP; organiza la respuesta operativa frente a señales de protocolo, disponibilidad y resultados observados.

Un modelo práctico parte de la ruta primaria en condiciones normales, pasa a observación cuando hay señales iniciales, utiliza fallback limitado cuando hay evidencia suficiente y mantiene una fase explícita de contención e investigación para incidentes persistentes. La recuperación requiere validación gradual, no solo la vuelta de la conectividad.

• Ruta primaria: tráfico normal y monitorización segmentada.
• Observación: alerta abierta, validación de datos, sin desvío o con un alcance mínimo de prueba.
• Fallback limitado: desvío de una cohorte definida, con presupuesto de intentos y controles de duplicado.
• Contención: reducción, pausa o aislamiento del tráfico afectado cuando el riesgo supera el beneficio del reenvío.
• Investigación: análisis de correlaciones, configuración, errores y cambios recientes.
• Recuperación: retorno gradual a la ruta primaria tras criterios verificables de estabilidad.

Controles contra duplicados y reintentos sin contexto

El control principal contra duplicados es separar la intención de negocio del intento técnico. Asigne un identificador interno estable a cada intención de envío y relacione cada intento con la ruta, el momento, el contenido aplicable y el message_id devuelto por cada SMSC. SMPP también contempla user_message_reference como referencia asignada por el ESME, pero la deduplicación entre rutas debe resolverse en la lógica de la aplicación, no suponerse a partir de un único campo de protocolo.

Antes de iniciar fallback, compruebe si el primer intento tiene un resultado final conocido, si sigue dentro de su periodo de validez y si un segundo envío tendría sentido para el usuario. La ventana de espera debe estar ligada a la validez del mensaje. SMPP permite indicar validity_period y prevé que el SMSC descarte el mensaje al expirar si no fue entregado.

La función replace_if_present_flag no resuelve la deduplicación universal. Solo solicita reemplazar un mensaje pendiente y depende de que coincidan source address, destination address y service_type. No debe asumirse que funcionará entre proveedores, SMSC o rutas diferentes.

• Use un ID interno por intención de envío y un ID por intento técnico.
• Guarde el message_id de cada SMSC sin sustituirlo por un identificador genérico.
• Aplique idempotencia en el evento de negocio, no solo en el transporte SMS.
• Defina una ventana de espera antes de considerar un segundo intento.
• No reenvíe automáticamente mensajes cuyo contenido pueda ser inválido, contradictorio o sensible al contexto.
• No trate replace_if_present_flag como un mecanismo de deduplicación entre rutas.