DLR tardíos en A2P SMS: cómo definir una ventana de observación y cerrar mensajes sin perder trazabilidad

Qué es un DLR tardío en una cadena A2P SMS

Un delivery receipt o DLR es un evento de estado relativo a un SMS previamente sometido. En SMPP, cuando se ha solicitado mediante registered_delivery, el SMSC puede enviar ese recibo al ESME a través de deliver_sm. No es la respuesta síncrona a submit_sm ni debe tratarse como tal.

Un DLR tardío es un recibo que llega después del momento que una aplicación, una operación o un equipo de soporte esperaba para tomar una decisión. Puede aparecer porque el ciclo del mensaje atraviesa varios sistemas y porque pueden existir intentos de entrega intermedios. SMPP contempla, por ejemplo, que un intento falle mientras el SMS continúa retenido para nuevos intentos; el soporte concreto de esas notificaciones depende de la implementación del SMSC y del proveedor.

La tardanza del evento no invalida por sí misma el evento. Indica que la decisión operativa de la empresa y el ciclo de notificación de la cadena de entrega no estaban necesariamente sincronizados. Por eso conviene diseñar un cierre operativo reversible en términos de interpretación, pero no destructivo en términos de datos.

• No equipare la respuesta de aceptación del envío con un DLR.
• No trate la ausencia de callback como evidencia automática de fallo final.
• Conserve el evento bruto aunque llegue después del cierre operativo.
• Mantenga separadas la semántica recibida del proveedor y la clasificación interna.

Tres relojes que no deben confundirse

La gestión de DLR tardíos empieza por separar tres controles que responden a preguntas distintas. Si se usan como si fueran el mismo, se producen cierres prematuros, expiraciones mal interpretadas y diagnósticos poco fiables.

El timeout de API determina cuánto espera la aplicación una respuesta técnica a su solicitud. Si expira, la aplicación debe resolver la incertidumbre de esa solicitud con un identificador de correlación, una consulta de estado o una estrategia segura de reintento. No determina cuánto tiempo puede entregarse el SMS ni cuánto tiempo puede llegar un DLR.

El periodo de validez determina hasta cuándo un centro de servicio puede conservar un mensaje para intentar su entrega. En SMPP, validity_period representa la hora de expiración tras la cual el SMSC debe descartar el mensaje si no se ha entregado. En 3GPP, la validez puede expresarse en formatos relativo, absoluto o mejorado. La expiración de validez es un desenlace de red; no debe deducirse simplemente porque no haya llegado un callback.

La ventana de observación del DLR es una política operativa propia. Define durante cuánto tiempo se espera un desenlace para alimentar flujos de negocio, alertas, soporte o informes operativos. No la establece el protocolo y no debe hacerse equivalente al timeout ni copiarse mecánicamente del periodo de validez.

• Timeout de API: límite de espera de una respuesta técnica.
• Validez del mensaje: límite de retención e intentos de entrega en la cadena aplicable.
• Ventana de observación: límite interno para decidir un estado operativo, no para borrar evidencia.
• Periodo de reconciliación: intervalo posterior para recuperar o contrastar eventos faltantes y cambios tardíos.

Por qué «aceptado» o «enviado» no confirma la entrega

Un estado de aceptación o envío debe describirse con precisión. En una semántica de proveedor documentada, sent significa que el operador ascendente más cercano aceptó el mensaje. Eso no equivale a confirmar la entrega en el destino.

Incluso cuando un DLR indique entregado, la comunicación debe conservar el alcance real de la evidencia. La especificación 3GPP distingue entre un mensaje recibido por el SME y un mensaje reenviado por el centro de servicio sin que este pueda confirmar su entrega. Además, la evidencia que un proveedor puede exponer depende de la confirmación disponible desde el operador y, cuando exista, desde el terminal.

Por tanto, un estado delivered debe registrarse como la confirmación de entrega reportada por la cadena disponible, no como prueba universal, independiente o equivalente a lectura por la persona destinataria. La lectura, la comprensión y la realización de una acción en un flujo de negocio son hechos distintos del DLR.

• Aceptado: la solicitud o el mensaje fue admitido en un punto de la cadena.
• Enviado: puede reflejar transferencia o aceptación aguas arriba, según la semántica documentada.
• Entregado: refleja una confirmación reportada, cuyo alcance depende de la evidencia disponible.
• Leído, usado o convertido: requieren señales independientes de la aplicación o del usuario.

Cómo modelar estados internos sin sobrescribir la evidencia

Los callbacks son asíncronos y el estado de un mensaje puede cambiar durante su ciclo de vida. Por ello, el estado bruto de un proveedor no debería ser el único campo que gobierne la operación. Conviene mantener un historial de eventos inmutable y una vista interna calculada para cada mensaje.

Un modelo práctico puede usar pendiente, provisional, final y actualizado tardíamente. Estos nombres describen la postura operativa de la empresa, no sustituyen la semántica original del DLR. El registro debe conservar tanto el evento recibido como la regla con la que se interpretó.

Pendiente puede representar que existe una aceptación técnica o que aún no se ha recibido un desenlace suficiente. Provisional indica que se ha tomado una acción de negocio o soporte bajo una incertidumbre explícita. Final identifica un desenlace recibido y clasificado conforme a las reglas vigentes. Actualizado tardíamente indica que un evento posterior cambió la vista calculada o aportó información relevante tras el cierre operativo.

No conviene reemplazar un estado anterior ni eliminar eventos por parecer redundantes. Guarde la secuencia y calcule la vista actual con reglas versionadas. Así podrá explicar por qué un mensaje fue cerrado en un momento dado y por qué más tarde se actualizó su interpretación.

• Evento bruto: contenido recibido, identificador, fuente y hora de recepción.
• Estado normalizado: traducción controlada de la semántica externa.
• Estado operativo: pendiente, provisional, final o actualizado tardíamente.
• Motivo de transición: regla aplicada, versión de la regla y actor si hubo intervención manual.
• Estado de conciliación: confirmado por eventos recibidos, consultado, pendiente de revisión o con discrepancia.

Definir ventanas según el caso de uso

No existe una duración universal para una ventana de observación. Debe derivarse de la finalidad del mensaje, del impacto de esperar, de la validez configurada, de las señales históricas disponibles y de la capacidad real de reconciliar y atender excepciones.

En OTP, la vigencia funcional del código debe decidirla la lógica de autenticación. El DLR aporta observabilidad y diagnóstico, pero no debe bloquear la expiración del código ni el flujo de autenticación. Defina la ventana para detectar incidencias, orientar reintentos seguros o informar soporte, sin convertirla en la fuente de verdad sobre la vigencia de la credencial.

En notificaciones transaccionales, la ventana puede alinearse con el momento en que el destinatario necesita actuar y con las obligaciones internas de atención. Si al cierre no existe un desenlace, el estado debe comunicar incertidumbre y activar el proceso previsto, no asumir entrega ni fallo definitivo.

En mensajería no urgente, una ventana más amplia puede ser razonable si el objetivo tolera entrega diferida. Aun así, la ventana debe seguir siendo independiente de la retención en redes posteriores: una plataforma puede aplicar su propia validez mientras el mensaje permanece en ella y, una vez transferido al operador, este puede continuar encolándolo durante más tiempo.

• OTP: separar siempre caducidad del código, validez del SMS y seguimiento del DLR.
• Transaccional: definir acciones de soporte o canales alternativos cuando persista la incertidumbre.
• No urgente: tolerar observación más extensa solo si el caso de uso y la política lo justifican.
• Todos los casos: conservar reconciliación posterior al cierre operativo.

Criterios para elegir una ventana de observación

La decisión debe ser documentada y revisable. Evite fijar una cifra única sin observar cómo se comportan los eventos en sus propios destinos, operadores, rutas, tipos de remitente y contenidos legítimos. Los datos históricos sirven para orientar una política; no convierten un patrón pasado en garantía futura.

Analice la distribución de tiempo entre la aceptación inicial, los estados intermedios y los desenlaces recibidos. Segmente el análisis por atributos operativos que estén permitidos y sean necesarios para el servicio, sin usar la segmentación para ocultar problemas ni para enviar tráfico no conforme.

La ventana debe ser coherente con el requisito de servicio. Si una operación necesita decidir antes de que normalmente pueda existir evidencia suficiente, debe diseñar un flujo que admita incertidumbre: por ejemplo, mostrar un estado pendiente, aplicar una verificación adicional o usar un canal alternativo conforme a la política aplicable.

La capacidad de soporte también importa. Una ventana corta puede reducir la cola visible, pero aumenta el riesgo de clasificar antes de tiempo. Una ventana amplia reduce ciertos cierres prematuros, pero puede demorar alertas y aumentar mensajes en seguimiento. La política debe declarar este intercambio.

• Comportamiento histórico de DLR por destino, operador, ruta y tipo de tráfico.
• Criticidad y plazo real del caso de uso.
• Periodo de validez configurado y semántica documentada de cada conexión.
• Tasas de eventos tardíos, duplicados, ausentes o fuera de orden.
• Capacidad de consulta, reconciliación, atención de incidencias y comunicación al cliente.
• Requisitos contractuales, regulatorios y de conservación de registros aplicables.

Diseño de una política de cierre y conservación de datos

Una política de cierre define qué ocurre cuando termina la ventana de observación sin un desenlace concluyente, qué eventos pueden modificar la vista posteriormente y quién puede aprobar excepciones. El cierre debe ser una decisión operativa auditable, no la eliminación del mensaje del sistema.

Establezca una taxonomía clara para los casos sin desenlace. Por ejemplo, «cerrado provisionalmente sin DLR final recibido» comunica más que «fallido» cuando no existe un error final reportado. Reserve los estados definitivos para evidencias que realmente soporten esa clasificación.

La política debe indicar quién es propietario de las reglas: operaciones, producto, ingeniería, entrega o un comité conjunto, según el modelo de organización. También debe definir un proceso de cambio: motivo, evaluación de impacto, versión, fecha efectiva, aprobación y plan de reversión.

Documente excepciones previsibles, como incidentes de conectividad de callback, cambios de integración, discrepancias identificadas en conciliación o rutas con semánticas distintas. Una excepción no debe modificar retroactivamente el historial bruto; debe cambiar de forma trazable la interpretación o el tratamiento operativo.

• Identificador interno único del mensaje.
• Identificador devuelto por el proveedor o conexión, cuando exista.
• Identificadores de cuenta, servicio o ruta disponibles y pertinentes.
• Origen, destino y atributos necesarios para correlación, protegidos conforme a la política de datos aplicable.
• Estado inicial, eventos posteriores, payload bruto conservado de forma segura y estado normalizado.
• Hora de solicitud, aceptación, recepción del callback y, cuando esté disponible, hora de finalización indicada por el DLR.
• Regla, versión y motivo de cada transición interna.
• Resultado de consultas de reconciliación y referencia de la incidencia, si la hubo.

DLR duplicados, fuera de orden o contradictorios

La recepción de más de un evento para el mismo mensaje no debe obligar a escoger uno y descartar los demás. Deduplicar para evitar acciones repetidas es útil; borrar duplicados aparentes elimina evidencia que puede ser necesaria para diagnóstico.

Use una clave de idempotencia basada en los identificadores disponibles y en una huella del evento. Si recibe dos eventos equivalentes, puede marcarlos como repetidos en la vista operativa, pero conserve ambos o conserve una referencia verificable al evento original según la política de retención. La idempotencia debe aplicarse especialmente a acciones laterales, como notificaciones, facturación interna o apertura de tickets.

Para eventos fuera de orden, diferencie la hora de recepción del callback y la hora que el DLR, cuando esté disponible, atribuye al desenlace. SMPP define done date como la fecha y hora en que el mensaje alcanzó el estado final. Esa marca puede ayudar a ordenar la evidencia, pero no sustituye la hora en que su sistema la recibió.

Ante contradicciones, no fuerce una conclusión sin una regla explícita. Marque la discrepancia, conserve todos los eventos, aplique una precedencia documentada solo para la vista materializada y, si es necesario, consulte los registros disponibles o escale al responsable de la conexión. Las reglas deben poder evolucionar porque los campos de callback y sus propiedades pueden variar con el tiempo.

• No sobrescriba el último estado sin conservar la secuencia anterior.
• Use procesamiento idempotente para impedir efectos secundarios duplicados.
• Almacene timestamp de recepción y timestamp declarado por el DLR por separado.
• Clasifique conflictos para revisión, en lugar de ocultarlos.
• Versione las reglas de precedencia y pruebe cambios antes de aplicarlos.