Tiempos de eventos A2P SMS: cómo reconciliar marcas temporales de la plataforma, el proveedor y los DLR
Una guía práctica para registrar, comparar y auditar los tiempos de eventos SMS sin confundir la recepción de un DLR con una confirmación independiente de entrega al terminal.
Por qué pueden diferir las horas registradas
Un envío A2P puede generar registros en varios sistemas: la aplicación o plataforma de origen, el proveedor que recibe el mensaje y los sistemas que emiten o entregan un informe de estado. Cada registro puede corresponder a un momento distinto y usar una fuente de reloj, una zona horaria o una precisión diferentes.
Por eso, dos marcas temporales distintas no prueban por sí solas que haya un error. Para interpretarlas, primero hay que saber qué evento pretende representar cada campo y qué sistema lo generó. La documentación disponible para este artículo no permite atribuir definiciones universales de timestamps o DLR a una especificación concreta; acuerda y documenta esas semánticas con cada proveedor.
- No compares una hora de creación con una hora de recepción como si describieran el mismo evento.
- Registra el sistema de origen y el significado declarado de cada marca temporal.
- Trata la precisión y la semántica de cada campo como propiedades que deben verificarse, no suponerse.
Separa creación, envío, aceptación y recepción del callback
Usa nombres de evento explícitos. Como mínimo, distingue cuándo se creó el registro o la solicitud, cuándo la plataforma intentó enviarla, cuándo recibió una respuesta de aceptación, qué hora de evento declara el proveedor y cuándo llegó el callback a tu sistema. No des por hecho que «aceptado» significa entregado al terminal.
Mantén por separado la hora del evento que informa el proveedor y la hora en que tu plataforma recibió ese informe. La primera es una afirmación del sistema emisor del evento; la segunda documenta la recepción local. Si el proveedor no especifica qué representa su timestamp, consérvalo como dato de origen sin reinterpretarlo.
- Define un diccionario de eventos con nombre, sistema emisor y significado.
- Guarda por separado el timestamp declarado por el proveedor y el timestamp local de recepción.
- No conviertas estados de aceptación o recepción de un informe en una afirmación de entrega al dispositivo.
Normaliza para comparar, pero conserva el dato original
Para facilitar búsquedas y comparaciones entre sistemas, adopta una representación común de hora, por ejemplo UTC, y una convención inequívoca para serializarla. Antes de convertir un valor, identifica su zona horaria o desplazamiento. Si no está disponible, registra esa ausencia: no asumas que la hora corresponde a la zona del servidor o del operador.
La normalización no debe sobrescribir el valor recibido. Conserva el texto o valor original, la zona horaria declarada, la fuente y el valor normalizado derivado. Así podrás revisar conversiones, resolver discrepancias y reconstruir qué informó cada sistema.
- Almacena el valor original sin alteraciones.
- Registra zona horaria o desplazamiento; indica explícitamente cuando sea desconocido.
- Guarda el valor normalizado en un campo independiente y documenta la regla de conversión.
- No inventes precisión: conserva la precisión disponible y señala si se desconoce.
Desfases, precisión desigual, duplicados y eventos fuera de orden
Una marca temporal no basta para diagnosticar un reloj desincronizado. Compara los campos solo cuando conoces su significado y zona horaria, y registra las diferencias observadas como indicios, no como prueba automática de su causa. Si el sistema expone información fiable sobre sincronización o calidad del reloj, guárdala por separado; no la infieras de una secuencia aparentemente extraña.
Los callbacks pueden llegar después de otros eventos o repetirse. Diseña la ingestión para conservar el evento recibido, reconocer posibles duplicados mediante identificadores estables cuando existan y mantener el historial de cambios. Si no hay identificador adecuado, no deduzcas que dos informes son el mismo evento solo porque comparten estado y hora.
- Distingue la hora declarada del evento y la hora de recepción local.
- Registra la precisión declarada o disponible; no añadas fracciones de segundo que no existían.
- Conserva eventos tardíos y fuera de secuencia en vez de descartarlos por llegar después.
- Usa identificadores de mensaje y de evento cuando estén disponibles, y documenta sus límites.
- No elimines duplicados de forma irreversible: conserva evidencia de la deduplicación.
Reglas de reconciliación: precedencia sin falsa certeza
No existe una regla universal respaldada aquí para ordenar todos los eventos A2P SMS por precedencia temporal. Define reglas internas por tipo de evento y por contrato o documentación técnica del proveedor. Una respuesta de aceptación, un evento de estado informado por el proveedor y la recepción del callback deben permanecer como hechos distintos.
Cuando dos fuentes discrepen, evita elegir una sola hora como «la verdadera» sin una justificación documentada. Puedes establecer una hora de referencia operativa para informes, pero conserva todas las observaciones y etiqueta el criterio aplicado. Si el significado o la zona horaria de un dato no están claros, marca la comparación como no concluyente.
- Define precedencia por semántica del evento, no por el nombre genérico del campo.
- Registra la regla aplicada, su versión y las fuentes que participaron.
- Separa el estado calculado por tu plataforma de los estados recibidos de terceros.
- Escala discrepancias no resueltas en lugar de convertirlas en una confirmación de entrega.
Campos mínimos para un registro auditable
Un registro útil debe permitir reconstruir qué se recibió, de quién y cómo se interpretó. El esquema exacto depende de la integración, pero conviene separar los datos de correlación, los datos originales, los tiempos normalizados y las decisiones de conciliación.
Limita el acceso a los datos identificativos y aplica las políticas de retención y seguridad correspondientes a tu organización. La auditabilidad no requiere tratar datos personales más allá de lo necesario para correlacionar y resolver incidencias.
- Identificador interno del mensaje y, si existe, identificador asignado por el proveedor.
- Tipo de evento y estado tal como se recibió, sin perder el valor original.
- Sistema o proveedor de origen y versión o referencia de la interfaz, cuando esté disponible.
- Timestamp original, zona horaria o desplazamiento declarado y precisión disponible.
- Timestamp de recepción local y timestamp normalizado, guardados por separado.
- Identificador del evento o callback, si existe, y resultado de la detección de duplicados.
- Regla de conciliación aplicada, resultado, motivo y momento de la decisión.
- Indicador de incertidumbre cuando el significado, la zona horaria o la secuencia no se puedan establecer.
Ejemplo: DLR tardío y estado final incierto
Supongamos que una plataforma registra el envío y, más tarde, recibe una respuesta de aceptación. Después registra otra transición y finalmente recibe un callback cuyo timestamp declarado parece anterior a la hora local de recepción. La diferencia puede deberse a retraso de transmisión, criterios distintos de timestamp, zona horaria desconocida o relojes desalineados; sin datos adicionales no es posible elegir una causa.
La práctica prudente es conservar ambas horas, asociar el callback al mensaje solo con claves de correlación adecuadas y marcar la secuencia para revisión si contradice las reglas documentadas. El callback acredita que la plataforma recibió un informe con cierto contenido. Sin documentación que establezca su semántica y alcance, no debe presentarse como verificación independiente de que el terminal recibió el SMS.
- Mantén el timestamp declarado del DLR y el timestamp de recepción como campos separados.
- No reordenes ni borres el historial para que parezca cronológico.
- Registra el estado comunicado y cualquier incertidumbre sobre su significado.
- Comunica el resultado como estado informado por el proveedor, no como prueba independiente del terminal.
Pruebas periódicas y límites de una marca temporal
Valida el flujo con pruebas controladas y legítimas en tus propias integraciones. Comprueba que los valores originales se conservan, que la conversión de zona horaria es reproducible, que los eventos tardíos no se pierden y que los duplicados quedan identificados sin borrar el historial. Repite la revisión cuando cambien la interfaz, la configuración o las reglas del proveedor.
Una marca temporal, por sí sola, no demuestra quién recibió el mensaje, que el reloj estuviera sincronizado, que el evento ocurriera exactamente en esa hora ni que el contenido se mostrara en el terminal. Las conclusiones dependen de la definición del evento, la fuente y la evidencia técnica disponible. Documenta esos límites en informes de operación y conciliación.
- Prueba timestamps con y sin zona horaria y verifica que los originales permanecen intactos.
- Incluye casos de callbacks tardíos, repetidos y fuera de secuencia.
- Compara la interpretación local con la documentación vigente de cada integración.
- Audita regularmente diferencias de hora y resultados de conciliación, sin convertirlos en garantías de entrega.
Preguntas frecuentes
¿Un DLR recibido confirma que el SMS llegó al terminal?
La recepción del callback confirma que tu sistema recibió un informe. Su significado depende de la semántica documentada por la fuente y no equivale, por sí sola, a una verificación independiente de recepción en el terminal.
¿Debo guardar todos los timestamps en UTC?
Puedes mantener un campo normalizado en UTC para comparar sistemas, pero conserva también el valor original y la zona horaria o desplazamiento declarado. Si la zona se desconoce, regístralo en vez de asumirla.
¿Qué hora debe prevalecer cuando plataforma y proveedor discrepan?
No hay una precedencia universal aplicable a todos los campos. Define reglas por tipo de evento y por la documentación de la integración, conserva ambas observaciones y etiqueta las discrepancias no resueltas.
¿Cómo trato un callback que llega fuera de orden o duplicado?
Consérvalo con su hora de recepción y su timestamp declarado. Usa identificadores estables para detectar duplicados cuando existan, mantén el historial y no descartes eventos solo porque llegaron tarde.
¿Qué demuestra una diferencia entre dos marcas temporales?
Demuestra que los registros presentan valores distintos; no identifica por sí sola la causa. Puede haber diferencias de semántica, zona horaria, precisión, retraso o reloj. Para atribuir una causa hacen falta datos adicionales.
Fuentes consultadas
- 3GPP specifications3GPP
- ITU-T E.164International Telecommunication Union
- GSMA resourcesGSMA