Cómo investigar discrepancias de DLR en A2P SMS sin confundir entrega con recepción humana

La pregunta correcta: ¿qué demuestra realmente cada evidencia?

Una investigación de discrepancias DLR A2P SMS empieza separando hechos que suelen aparecer unidos en un único campo de estado. La aceptación del envío, el progreso por la cadena, el estado comunicado por un SMSC y la observación en un terminal no son equivalentes.

En SMPP, un submit_sm_resp correcto indica que el SMSC procesó la operación y asignó un message_id. En una API HTTP ocurre algo comparable cuando se crea o acepta el recurso y se devuelve un identificador. Esto acredita aceptación técnica en ese punto de la cadena, no entrega al destino.

Los estados posteriores llegan de forma asíncrona. En SMPP, un recibo del SMSC puede recibirse mediante deliver_sm o data_sm. Ese DLR expresa el estado mantenido o comunicado por el SMSC. No debe atribuirse automáticamente al terminal, al usuario o a todos los tramos anteriores.

Una observación independiente —por ejemplo, la recepción registrada por un dispositivo de prueba controlado— es evidencia distinta. Puede reforzar o contradecir el DLR, pero tampoco acredita por sí sola la identidad de la persona que usa el dispositivo ni permite generalizar el resultado a toda una ruta.

• Aceptación API o submit_sm_resp: el punto receptor aceptó o procesó la solicitud y devolvió un identificador.
• Estado temporal: informa de progreso, cola o tránsito; no cierra necesariamente el ciclo.
• DLR final: declaración técnica de la cadena según la semántica documentada por la conexión.
• Observación independiente: señal separada obtenida fuera del flujo del DLR; debe documentarse su método y alcance.
• Lectura humana: no puede inferirse universalmente de un DLR SMS.

Por qué DELIVRD no prueba lectura ni identidad

SMPP incluye DELIVERED entre sus estados, pero un DLR tradicional puede emplear un texto cuyo formato es específico del proveedor del SMSC. Por eso deben consultarse la especificación aplicable y la documentación oficial de cada conexión antes de mapear valores como DELIVRD.

3GPP diferencia explícitamente la recepción por la estación móvil de la entrega al usuario. Incluso cuando existe confirmación de la estación móvil, no se demuestra que una persona haya visto, abierto o comprendido el mensaje. SMS tampoco proporciona universalmente un recibo de lectura.

El estado comunicado como delivered puede proceder de la confirmación de un operador ascendente y solo incorporar confirmación del terminal cuando esta se encuentre disponible. La procedencia exacta debe conservarse en cada evento en lugar de transformarla en una afirmación más fuerte.

Tampoco se prueba la identidad humana del receptor. Un destino técnico o dispositivo puede recibir el mensaje sin demostrar quién controla el número, quién sostiene el terminal o quién visualiza el contenido. Un OTP debe tratarse según el diseño de seguridad completo del servicio, no como prueba de identidad basada únicamente en el DLR.

Conviene evitar además una confusión terminológica: el estado SMPP ACCEPTED no significa lectura ordinaria ni aceptación inicial de transporte. La especificación lo describe como lectura manual en nombre del abonado por atención al cliente. La aceptación inicial del envío se registra por separado.

• Escribir «DLR comunicado como DELIVRD» en vez de «usuario alcanzado» cuando no exista evidencia adicional.
• Conservar proveedor, conexión y versión del mapeo que convirtió el valor original en un estado interno.
• No presentar DELIVRD como lectura, identidad, consentimiento ni garantía universal de recepción en el terminal.
• Mantener separados delivered, observación en dispositivo y read cuando un canal admita eventos de lectura.

Modelo mínimo de trazabilidad de extremo a extremo

La correlación fiable necesita un registro por mensaje lógico, por segmento cuando exista concatenación y por evento recibido. Debe conservarse el identificador interno junto con el message_id o identificador asignado por cada SMSC, API o socio. El campo id del DLR SMPP se refiere al identificador que el SMSC asignó al envío original.

No conviene correlacionar exclusivamente por dirección del SMSC. 3GPP advierte que las arquitecturas de resiliencia y balanceo pueden hacer que un informe proceda de una dirección distinta de la usada en el envío original.

Normalice los registros en un esquema común, pero preserve el evento original y su fuente. La normalización facilita consultas; el dato bruto permite auditar errores de parseo y cambios de formato. El destino puede conservarse en una representación normalizada basada en E.164 junto al valor original recibido.

Cada timestamp debe incluir su semántica, fuente y relación explícita con UTC mediante Z u offset. No sobrescriba la hora declarada por el proveedor con la de llegada del callback. Mantenga también la observación independiente como un tercer instante. Antes de interpretar una secuencia imposible, descarte relojes desalineados.

• Identificador interno del mensaje lógico e identificador de cada segmento.
• Identificador de solicitud, message_id del SMSC o proveedor e identificador del evento o callback, si existe.
• Timestamp de envío local, timestamp declarado por la fuente, recepción del callback y observación independiente.
• Zona horaria u offset, precisión disponible, sistema de origen y reloj que produjo cada timestamp.
• Proveedor, conexión, ruta declarada, destino original y normalizado, operador observado o declarado y remitente.
• Contenido normalizado o huella controlada, codificación, longitud y número de segmentos, según la política de conservación aplicable.
• Estado y error originales, estado interno normalizado y versión del mapeo aplicado.
• Número de intento, causa del retry, entorno de prueba o producción y exclusiones analíticas.

Taxonomía reproducible de discrepancias

Una etiqueta precisa evita que problemas de observabilidad se atribuyan prematuramente a la ruta. Cada caso debe admitir una regla verificable, una ventana temporal documentada y un estado de investigación.

La taxonomía interna debe distinguir estados temporales, finales y no concluyentes. SMPP define, entre otros, ENROUTE, DELIVERED, EXPIRED, DELETED, UNDELIVERABLE, ACCEPTED, UNKNOWN y REJECTED, pero la semántica efectiva debe verificarse en la documentación de la conexión.

• Ausencia: no existe DLR correlacionable dentro de la ventana observada. No equivale automáticamente a fallo de entrega.
• Duplicidad: se recibe más de una copia del mismo evento o estado. Deduplicar por identificador y ventana temporal antes de agregar.
• Retraso: el DLR llega después del plazo esperado para ese segmento operativo, sin modificar por ello el significado del estado.
• Contradicción: dos fuentes o eventos finales atribuyen resultados incompatibles al mismo mensaje o segmento.
• No correlacionable: existe un DLR, pero su identificador no enlaza de forma segura con el envío original.
• Secuencia inválida: una transición viola la máquina de estados documentada o las horas parecen imposibles.
• Resultado parcial: un mensaje concatenado contiene segmentos correctos y fallidos; no debe ocultarse bajo un único resultado simple.
• Taxonomía desconocida: aparece un estado o código no contemplado en la versión activa del mapeo.

Procedimiento de investigación paso a paso

Primero delimite el incidente sin mezclar poblaciones distintas. Defina inicio y fin, caso de uso, destino, operador, remitente, proveedor, conexión, ruta declarada, tipo de tráfico, codificación y condición exacta de inclusión. Registre también tamaño de muestra y posibles sesgos.

Después valide la observabilidad. Compruebe que el endpoint de callbacks estaba accesible, persistía la solicitud antes de responder, aceptaba el esquema recibido y devolvía una respuesta HTTP válida. Un validador excesivamente rígido puede rechazar campos nuevos. Revise colas, errores de ingestión, almacenamiento, reintentos, deduplicación y sincronización de relojes.

Reconstruya entonces la cronología por mensaje y por segmento: solicitud, respuesta inicial, estados temporales, DLR final, retries técnicos y observación independiente. Compare valores originales y transformados, sin ordenar ciegamente eventos producidos por relojes diferentes.

Por último, asigne el dominio más probable: integración propia, observabilidad, mapeo de estados, conexión del proveedor, ruta declarada, red o destino. Si la evidencia no permite aislarlo, mantenga la clasificación como no determinada en lugar de forzar una causa.

• 1. Congelar alcance, consulta y exclusiones para que el análisis sea reproducible.
• 2. Seleccionar ejemplos representativos y conservar sus registros originales.
• 3. Verificar recepción, respuesta y persistencia de callbacks.
• 4. Reconciliar mensajes pendientes mediante el mecanismo oficial de consulta, si la conexión lo ofrece.
• 5. Correlacionar todos los identificadores sin depender solo del destino o de la dirección del SMSC.
• 6. Revisar timestamps, offsets, desfases de reloj y semántica de cada hora.
• 7. Aplicar la versión correcta del mapeo y comprobar transiciones.
• 8. Separar integración, ruta y destino; documentar incertidumbre y evidencia faltante.

Timeouts, estados temporales y cierre operativo

Un timeout de API, conexión o callback no demuestra que el SMS no se entregó. La operación pudo continuar tras perderse la respuesta. Busque el recibo posterior y, cuando exista soporte oficial, reconcilie mediante una consulta del estado.

Los errores temporales y estados en tránsito no deben convertirse en fallos finales mientras continúen los intentos del centro de servicio o siga abierta la validez aplicable. Del mismo modo, un pendiente no debe transformarse en delivered para completar un informe.

Defina una ventana de cierre ligada al caso de uso y a la vigencia configurada. En un OTP, la utilidad puede terminar pronto, aunque el estado técnico llegue más tarde. Una notificación no urgente puede admitir otra ventana. La caducidad funcional, el cierre analítico y el estado técnico son campos diferentes.

El TP-Discharge-Time tampoco debe interpretarse siempre como hora de entrega satisfactoria: según el estado, puede representar la entrega, el último intento o la disposición del mensaje por el centro de servicio.

• Conservar el estado técnico original después del cierre operativo.
• Etiquetar «sin DLR al cierre» en vez de reclasificar automáticamente como failed.
• Permitir reconciliaciones tardías sin reescribir silenciosamente informes ya emitidos.
• Versionar la lógica de cierre y explicar su relación con la validez y el caso de uso.

Pruebas sintéticas y tráfico de producción

Las pruebas sintéticas permiten controlar dispositivo, hora, contenido, remitente y método de observación. Son útiles para reproducir problemas y contrastar DLR con recepción observada. Sin embargo, una muestra controlada no reproduce necesariamente la distribución de destinos, terminales, disponibilidad, filtros y perfiles del tráfico real.

El tráfico de producción aporta escala y diversidad, pero suele ofrecer menos control sobre el terminal y no debe utilizarse para inferir lectura o identidad. Además, debe tratarse conforme a las reglas aplicables de consentimiento, finalidad y conservación de registros.

BulkSMSMarket ejecuta comprobaciones internas diarias en rutas, destinos y operadores para observar entrega, consistencia de DLR, latencia, disponibilidad y comportamiento de remitente y contenido. Estas observaciones sirven como señales de calidad, no como garantía universal de recepción o lectura. Las tarjetas numéricas públicas son demostrativas hasta conectar datos contractuales de ruta.

No mezcle pruebas y producción en una sola tasa. Marque aparte el tráfico sintético, los retries técnicos y los mensajes concatenados. Si se comparan fuentes, documente sus diferencias de selección, volumen y método.

• Sintético: más control y mejor reproducibilidad; menor representatividad universal.
• Producción: mayor diversidad; menos certeza sobre lo sucedido en el terminal.
• Usar mensajes legítimos, consentidos y conformes con la normativa aplicable.
• No extrapolar un dispositivo de prueba a una ruta completa sin evidencia suficiente.

Métricas útiles sin crear una falsa certeza

No reduzca aceptación, cobertura de DLR, latencia y resultado a una única puntuación. Son dimensiones distintas. La cobertura de DLR puede definirse como la proporción de mensajes elegibles con al menos un evento correlacionable; debe mantenerse separada de la proporción comunicada como delivered.

Calcule latencia por percentiles y por hitos claramente definidos. Por ejemplo, aceptación a recepción del callback no es lo mismo que submit date a done date. Informe la fuente de ambos extremos, el offset y el tratamiento de valores ausentes.

Antes de agregar, deduplique por identificador de mensaje o evento y ventana temporal. Excluya o marque por separado pruebas, retries y mensajes concatenados para evitar dobles cuentas. En concatenados, mida también segmentos correctos y fallidos.

Construya líneas base segmentadas por destino, operador, remitente, tipo de tráfico, ruta declarada, franja comparable y versión de integración. Analice cambios sostenidos frente a variaciones puntuales. Con poco volumen, muestre tamaño de muestra e incertidumbre en lugar de rankings aparentemente precisos.

Revise periódicamente la calidad de los propios datos: callbacks perdidos, relojes desalineados, campos incompletos, identificadores reutilizados, timestamps futuros, errores de ingestión, saltos imposibles y cambios abruptos de taxonomía.

• Cobertura de DLR: mensajes elegibles con algún DLR correlacionable divididos por mensajes elegibles.
• Consistencia: proporción de eventos que respetan correlación, taxonomía y secuencia definidas.
• Latencia: percentiles por par de hitos y segmento comparable, no solo una media.
• Antigüedad de pendientes: distribución por intervalos desde el hito elegido.
• No correlacionados: proporción y volumen de DLR sin enlace seguro al envío.
• Contradicciones y duplicados: volumen antes y después de deduplicar.
• Panel recomendado: distribución de estados, evolución de percentiles, backlog por antigüedad, cobertura y calidad de datos.
• Nota metodológica visible: fuente, alcance, exclusiones, ventana, muestra, versión del mapeo y limitaciones.