Taxonomía de fallos A2P SMS: cómo clasificar rechazos, expiraciones y resultados inciertos

Por qué un único estado de fallido no sirve para operar una ruta

Un estado único de «fallido» simplifica el informe, pero elimina la información necesaria para decidir qué hacer después. No es equivalente que una solicitud SMPP sea rechazada por una dirección de destino inválida, que el SMSC acepte el mensaje pero éste expire durante su periodo de validez, o que el sistema no reciba un DLR interpretable.

La taxonomía de fallos A2P SMS debe permitir comparar resultados entre rutas, proveedores, destinos y ventanas temporales sin sustituir la evidencia técnica original. Su objetivo no es adivinar la causa final de cada mensaje, sino organizar los hechos observables y asociar a cada caso una acción proporcionada.

Una clasificación útil responde a cuatro preguntas: dónde se produjo el resultado, si es final o puede evolucionar, qué evidencia lo respalda y qué acción está permitida. Esta disciplina reduce reintentos innecesarios, evita atribuciones incorrectas y mejora la calidad de las escalaciones técnicas.

• No use «fallido» como causa raíz.
• Mantenga separados el resultado de la solicitud, el estado de entrega y la causa confirmada.
• Diferencie los estados finales de los estados intermedios.
• Conserve siempre el código y texto original recibidos, incluso después de aplicar un mapeo interno.

Principio de evidencia: hechos observables, inferencias y causas confirmadas

La primera regla es separar el hecho técnico de su interpretación. Una respuesta SMPP con command_status de éxito acredita que la operación de protocolo fue aceptada; no confirma que el SMS haya llegado al terminal. Del mismo modo, un DLR con estado DELIVERED es una confirmación recibida a través de la cadena de entrega, no una verificación independiente y universal de lectura o recepción física por parte de una persona.

Los DLR pueden incluir identificador, fecha de envío, fecha de cierre, estado y código de error. Estos campos permiten reconstruir un ciclo de vida, siempre que el identificador pueda asociarse de forma fiable al mensaje original. Sin embargo, el formato concreto de receipts transportados en short_message puede variar según el gateway o SMSC, por lo que el parser debe controlarse por proveedor o ruta.

La ausencia de DLR tampoco demuestra por sí sola una no entrega. Puede deberse a que no se recibió el callback, a que el DLR no se pudo interpretar, a un desfase de conciliación o a una política de reporte de la cadena upstream. Debe clasificarse como incertidumbre hasta obtener evidencia adicional.

• Hecho observable: HTTP response, submit_sm_resp, DLR, callback, consulta de estado o timeout interno.
• Inferencia: «probable congestión», «posible restricción de remitente» o «posible filtrado».
• Causa confirmada: sólo cuando un código, una respuesta documentada o una investigación del proveedor la identifica.
• Nivel de confianza: registre si la clasificación es directa, inferida o pendiente de confirmación.

Las cinco familias operativas de resultado

Una taxonomía mínima y comparable puede organizar los desenlaces en cinco familias. Cada familia debe conservar el estado original, el origen de la evidencia y el nivel de confianza. Las familias no reemplazan los códigos del proveedor: los agrupan para fines de operación, análisis y decisión.

La misma ruta puede producir resultados de varias familias. Por ello, no conviene juzgar una ruta con un único porcentaje agregado sin revisar la composición de los fallos, la evolución temporal y la evidencia disponible.

• Rechazo previo a aceptación: la plataforma local aborta el intento antes de alcanzar el SMSC, o el SMSC rechaza la solicitud. Mantenga ambas situaciones diferenciadas. Ejemplos técnicos posibles: fallo de bind, credenciales inválidas, dirección de origen inválida o dirección de destino inválida.
• Fallo temporal: la evidencia del proveedor lo identifica expresamente como temporal o reintentable. No convierta un error genérico en temporal por conveniencia operativa.
• Fallo final: existe un resultado negativo final para el que la documentación o la evidencia disponible no indica reintento seguro. Un rechazo del SMSC puede pertenecer a esta familia cuando probablemente se repetirá con la misma solicitud.
• Expiración: el mensaje agotó una ventana de validez antes de completarse la entrega. Debe separarse del fallo final porque la duración de validez y el caso de uso son relevantes.
• Resultado incierto: el SMSC pudo haber aceptado el mensaje, pero no existe un DLR recibido e interpretable que permita cerrarlo como entregado, fallido o expirado.

Datos que se deben conservar por mensaje

La clasificación será débil si los registros no permiten reconstruir la secuencia. El identificador interno debe coexistir con los identificadores asignados por la plataforma, el proveedor o el SMSC. El DLR debe vincularse al mensaje original sin depender únicamente de un texto de receipt que pueda variar entre implementaciones.

El destino debe almacenarse en formato internacional normalizado conforme a la estructura del plan E.164, separado de los atributos usados para enrutar o segmentar. La normalización no convierte un número en válido, activo, consentido ni entregable; sólo mejora la consistencia del tratamiento de datos y del análisis.

También es importante conservar una clasificación controlada del contenido y del remitente, sin usar esos campos para inferir una causa sin evidencia. Por ejemplo, una diferencia de comportamiento por tipo de remitente puede justificar una investigación, pero no confirma por sí misma una restricción de remitente.

• Identificador interno del intento y del mensaje lógico.
• Identificadores de plataforma, proveedor, SMSC y DLR cuando existan.
• Marcas temporales: creación, aceptación, envío, actualización, recepción del DLR y cierre interno.
• Destino normalizado, país asociado y operador sólo cuando el dato exista con evidencia suficiente.
• Remitente, tipo de remitente y configuración relevante de la solicitud.
• Ruta, proveedor, conexión, versión de parser y versión de mapeo.
• Clase de contenido o caso de uso: OTP, transaccional o marketing legítimo.
• Estado y código originales, texto original, familia normalizada, nivel de confianza y siguiente acción.

Cómo mapear HTTP, SMPP y DLR sin perder información

El mapeo debe ser una capa adicional y reversible. Guarde primero la respuesta original y luego aplique una regla versionada que produzca una categoría operativa. No sobrescriba un código SMPP, un estado HTTP o el texto de un DLR con una etiqueta interna como «número inválido» o «filtrado» si esa causa no está confirmada.

En SMPP, command_status informa del éxito o fallo de una solicitud SMPP. Códigos como ESME_RINVSRCADR, ESME_RINVDSTADR, ESME_RSYSERR, ESME_RBINDFAIL y ESME_RINVPASWD tienen semánticas técnicas distintas y deben permanecer disponibles para diagnóstico. Una respuesta satisfactoria a submit_sm no debe mapearse a «entregado»: debe mapearse, como máximo, a «aceptado por la operación de protocolo» o a un estado intermedio equivalente.

Los estados de entrega también requieren una jerarquía temporal. ENROUTE es intermedio y puede evolucionar, por ejemplo, a DELIVERED o EXPIRED. Un parser no debe cerrar un mensaje de manera irreversible mientras sólo disponga de un estado que puede cambiar.

• Capture: protocolo, endpoint o comando, código, texto, payload original y marca temporal de recepción.
• Aplique una regla con versión, ámbito y fecha de vigencia.
• Defina la precedencia entre actualizaciones: un DLR final válido debe prevalecer sobre un estado intermedio anterior.
• Mantenga los DLR no interpretables en una cola de revisión y clasifíquelos temporalmente como resultado incierto.
• Versione los parsers por proveedor, conexión o ruta cuando el formato de receipt lo requiera.
• Evite depender programáticamente de textos cambiantes de errores específicos; úselos como evidencia diagnóstica conservada.

Clasificación por accionabilidad

La utilidad de una taxonomía se demuestra cuando guía acciones seguras. No todas las categorías autorizan un reintento y no toda incidencia exige detener tráfico. La acción debe depender de la familia, del código original, del caso de uso, de la ventana de validez y de la evidencia acumulada.

Las decisiones deben ejecutarse por reglas explícitas. Un reintento puede ser apropiado cuando el proveedor identifica el resultado como temporal o reintentable; no debe aplicarse de forma automática a rechazos que probablemente producirán el mismo error con la misma solicitud. Si existe incertidumbre, primero concilie el estado antes de generar duplicados.

• Corregir datos o configuración: aplíquelo a evidencias como destino inválido, remitente inválido, error de bind o credenciales incorrectas. Valide antes de volver a enviar.
• Reintentar de forma segura: sólo con evidencia de temporalidad o reintentabilidad, una política de deduplicación y una ventana de validez aún útil.
• Detener o limitar tráfico: ante aumentos sostenidos de rechazos técnicos, fallos de autenticación, errores de sistema o cambios de comportamiento que afecten a una ruta. La medida debe revisarse con datos, no con una atribución automática.
• Escalar al proveedor: cuando haya códigos persistentes, DLR inconsistentes, receipts no interpretables, discrepancias de identificadores o crecimiento de resultados inciertos.
• Mantener en observación y conciliar: para estados intermedios, ausencia de DLR dentro de la ventana definida o conflictos entre fuentes de estado.

Errores ambiguos: cuándo usar «sin causa determinada»

Una categoría «sin causa determinada» es necesaria cuando la evidencia no permite identificar una causa concreta. No es un fallo de análisis: es una forma de impedir que una hipótesis se convierta en un dato operativo. Debe utilizarse, por ejemplo, cuando se recibe un estado genérico de no entrega sin un código que discrimine entre causas posibles.

No asigne automáticamente una no entrega a filtrado de contenido, indisponibilidad del terminal, restricción de remitente, congestión o problema de numeración. Un estado negativo puede cubrir varias causas. La atribución debe esperar a un código específico, una respuesta documentada del proveedor, una evidencia consistente por segmento o una investigación confirmada.

Para que esta categoría sea útil, no debe convertirse en un cajón permanente. Cada caso debe conservar suficientes metadatos para poder reclasificarse si llega un DLR tardío, se actualiza el parser o el proveedor aporta una aclaración.

• Use «sin causa determinada» cuando falte evidencia discriminante.
• No use esa categoría para ocultar errores de parser, pérdida de callbacks o falta de correlación: registre esos problemas por separado.
• Mida su proporción por ruta, proveedor, destino y versión de integración.
• Abra revisión si aumenta de forma sostenida o si se concentra en una misma ruta o formato de DLR.
• Reclasifique sólo mediante una regla versionada y conserve el historial del cambio.

Reglas distintas para OTP, transaccional y marketing legítimo

La categoría de fallo no cambia por el caso de uso, pero la acción sí puede cambiar. Un OTP tiene una utilidad limitada en el tiempo y exige especial cuidado con los reintentos: enviar un código duplicado o tardío puede confundir al destinatario y no resolver el acceso. El sistema debe respetar la validez del código y evitar reintentos cuando ya no aporten valor.

Los mensajes transaccionales pueden tolerar una política de reintento distinta si su contenido sigue siendo válido y si el evento no se duplica de forma perjudicial. El marketing legítimo requiere una disciplina todavía mayor: sólo debe enviarse a destinatarios con la base legal y los permisos aplicables, y un resultado incierto no debe usarse para justificar reenvíos repetidos.

El periodo de validez es parte de la decisión. La expiración indica que el mensaje permaneció pendiente hasta agotar una ventana configurada antes de fallar en la plataforma. Por ello, analice las expiraciones junto con la validez configurada y no sólo como un indicador de calidad de ruta.

• OTP: cierre rápido, deduplicación estricta y reintento sólo si sigue dentro de la validez del código y la política lo permite.
• Transaccional: valide idempotencia, vigencia del evento y riesgo de duplicidad antes de reintentar.
• Marketing legítimo: limite la frecuencia, respete consentimiento y exclusiones aplicables, y no use incertidumbre como motivo para insistir.
• Para todos los casos: documente la política de reintentos, el máximo de intentos y la condición de cierre.