Contrato de integración de DLR A2P SMS: campos, estados y cambios
Una guía práctica para acordar el formato de los DLR entre proveedores SMS, preservar los códigos originales, correlacionar eventos y probar cambios sin interpretar un informe como prueba automática de recepción en el móvil.
Por qué la semántica de un DLR puede variar
Un informe de entrega (DLR, por sus siglas en inglés) es un evento comunicado por un sistema de la cadena de mensajería. Su significado operativo depende de quién lo genera, qué etapa representa y cómo ese proveedor define sus estados. Por eso, dos sistemas pueden usar etiquetas parecidas sin que sus informes constituyan evidencia equivalente.
Antes de integrar, identifica cada eslabón que interviene —por ejemplo, la plataforma de envío y el proveedor que devuelve el informe— y solicita su documentación técnica vigente. No presupongas que un estado, código o marca temporal tiene el mismo significado en todos los sistemas. La información disponible aquí no permite fijar una lista universal de estados ni sus equivalencias.
- Acuerda qué evento comunica cada proveedor y qué etapa del recorrido pretende representar.
- Registra la definición del estado según la documentación del proveedor, no solo su etiqueta.
- Aclara qué significan las marcas temporales y en qué zona horaria se expresan.
Define un esquema común antes de conectar sistemas
El contrato de datos debe distinguir campos requeridos, opcionales y condicionados a la disponibilidad del proveedor. Para cada campo, especifica nombre, tipo, formato, significado, reglas de ausencia y ejemplos acordados. No conviertas una convención local en requisito universal: valida cada punto con los participantes de la integración.
Como base de negociación, considera un identificador de evento, el identificador de mensaje conocido por el emisor, el estado normalizado, el código y texto originales, el sistema de origen y las marcas temporales disponibles. Añade identificadores de correlación cuando haya traducciones entre sistemas. La evidencia disponible no establece que todos estos campos existan o tengan un formato estándar en todos los DLR.
- Marca como obligatorio solo lo que todos los participantes puedan producir y validar.
- Define si un campo ausente se omite, se representa como nulo o se informa mediante otro mecanismo.
- Especifica formato y zona horaria para cada marca temporal; no deduzcas la hora de recepción a partir de otra marca sin una regla documentada.
- Incluye ejemplos válidos y no válidos en el contrato.
Conserva el estado normalizado y la respuesta original
La normalización facilita el procesamiento común, pero puede ocultar diferencias importantes si reemplaza por completo la respuesta del proveedor. Guarda por separado el estado interno normalizado y el estado, código y texto recibidos originalmente. Conserva también el nombre o identificador del sistema de origen y la versión del mapeo aplicado.
Mantén una tabla de correspondencias explícita, revisada con cada proveedor. Si un código no está documentado o no puede mapearse con seguridad, clasifícalo como desconocido o pendiente de análisis; no lo conviertas automáticamente en éxito o fallo. La normalización debe ser reversible en el sentido operativo: el equipo ha de poder consultar qué valor llegó y qué regla produjo la clasificación.
- No descartes el código original al calcular métricas o actualizar estados internos.
- Documenta cada equivalencia con su fuente, ámbito y fecha de revisión.
- Define una categoría de desconocido y una ruta de revisión para valores nuevos.
- Evita agrupar estados distintos si el proveedor no confirma que representan la misma condición.
Correlaciona cada evento con el envío correcto
Un identificador de mensaje puede ser distinto en diferentes sistemas. El contrato debe explicar qué identificador genera cada participante, dónde se devuelve y cómo se vincula con el identificador conocido por la aplicación que envió el mensaje. Si hay traducción, registra la relación entre los valores en lugar de asumir que son intercambiables.
Define la clave o combinación de claves que tu integración usará para buscar el envío asociado. Especifica qué ocurre si falta un identificador, si no hay coincidencia o si aparecen varias coincidencias. No atribuyas un DLR basándote únicamente en una similitud de datos que no se haya acordado como criterio válido.
- Documenta el recorrido de los identificadores desde el envío hasta el informe.
- Prueba tanto coincidencias válidas como identificadores ausentes, desconocidos y repetidos.
- Conserva los valores de origen y de destino de cada traducción.
- Envía los eventos sin correspondencia a una cola o proceso de investigación, sin asignarlos arbitrariamente.
Gestiona duplicados, retrasos y eventos no reconocidos
Acuerda cómo identificar y tratar eventos repetidos, tardíos o recibidos en un orden distinto al esperado. La evidencia técnica disponible no define una regla universal de deduplicación ni de secuenciación para todos los proveedores. Por tanto, el contrato debe especificar qué datos permiten reconocer una repetición, durante cuánto tiempo se conserva la información necesaria y cómo se resuelven eventos contradictorios.
No sobrescribas un estado anterior solo porque otro evento llegó después: el orden de recepción puede no representar el orden en que ocurrieron los eventos. Determina con cada proveedor qué marcas temporales son relevantes y qué precedencia, si alguna, está documentada. Si no hay una regla verificable, conserva el historial y deriva los casos ambiguos a revisión.
- Define el criterio de duplicado y el efecto de recibirlo más de una vez.
- Registra por separado el momento de recepción local y las marcas temporales comunicadas, si están disponibles.
- Establece cómo manejar estados tardíos, desconocidos, contradictorios y sin correspondencia.
- Haz que la lógica de actualización sea trazable y evita eliminar el historial original.
Prueba el contrato con casos de aceptación acordados
Prepara pruebas conjuntas con ejemplos aprobados por los participantes. El objetivo es comprobar el formato recibido, la validación de campos, el mapeo de estados y la correlación; no demostrar por sí solo que un teléfono recibió el mensaje. La lista de códigos y resultados esperados debe proceder de la documentación y el acuerdo técnico de los proveedores implicados.
Ejecuta las pruebas en un entorno apropiado y registra entrada, resultado esperado, resultado observado y decisión. Si el formato real difiere del contrato o un estado no está documentado, detén la aceptación de esa variante hasta resolver la discrepancia.
- Evento válido con todos los campos acordados.
- Campo opcional ausente y campo obligatorio ausente, cada uno con el comportamiento esperado documentado.
- Estado conocido con código original preservado y mapeo esperado.
- Código o estado desconocido, sin clasificación automática como éxito.
- Evento repetido, tardío, fuera de orden y sin identificador correlacionable.
- Formato con campos añadidos, omitidos, renombrados o con un tipo distinto, según los límites del contrato.
Versiona el contrato y controla los cambios
Trata el formato y el mapeo como un contrato compartido, no como una suposición implícita en el código. Identifica cada versión, conserva el historial de cambios y comunica qué sistemas la aceptan. Antes de desplegar una modificación, determina si afecta la estructura, el tipo de un campo, la semántica de un estado o la correlación.
Acuerda un proceso de notificación, revisión y prueba con cada participante. No declares compatible un cambio solo porque el mensaje sigue siendo sintácticamente válido: una etiqueta sin cambios puede adquirir otro significado, y un campo añadido puede afectar a consumidores que validan estrictamente el formato. La compatibilidad debe comprobarse frente a las reglas concretas de la integración.
- Asigna una versión identificable al contrato y a las tablas de mapeo.
- Evalúa por separado cambios de formato y cambios semánticos.
- Ejecuta los casos de aceptación acordados antes de activar una nueva versión.
- Define cómo comunicar, aceptar o rechazar cambios incompatibles.
Un DLR comunicado no demuestra por sí solo recepción en el terminal
Interpreta el DLR con el alcance que documente su emisor. Un estado comunicado por un eslabón indica lo que ese sistema informa; no debe presentarse automáticamente como confirmación independiente de que el mensaje apareció o fue recibido por el usuario en el terminal. La evidencia disponible no permite afirmar que un estado concreto garantice esa recepción.
En informes operativos, distingue los eventos recibidos de cualquier verificación independiente que exista y describe sus límites. No uses el DLR como prueba de consentimiento, identidad o lectura del mensaje. Si una decisión de negocio depende de la recepción efectiva, define de antemano qué evidencia se considera suficiente y consulta las capacidades documentadas de los sistemas implicados.
- Describe el estado como comunicado por su origen, no como un hecho más amplio de lo que respalda la documentación.
- Separa recepción del DLR, estado normalizado y evidencia independiente disponible.
- Expón los casos desconocidos o ambiguos en métricas e informes, en vez de forzarlos a una categoría concluyente.
Preguntas frecuentes
¿Hay una lista universal de estados DLR que todos los proveedores deban usar?
La información técnica disponible para esta guía no permite establecer una lista universal ni equivalencias entre proveedores. Solicita la documentación de cada participante y acuerda explícitamente los estados y códigos que se mapearán.
¿Debo reemplazar el código original por un estado normalizado?
No. Conserva el código, el texto y el origen originales junto al estado normalizado y la regla de mapeo aplicada. Así puedes investigar discrepancias y revisar el mapeo cuando cambie la documentación.
¿Qué hago con un DLR duplicado o sin correspondencia?
Define por contrato cómo reconocer y registrar duplicados. Para un evento sin correspondencia, conserva los datos recibidos y deriva el caso a investigación; no lo asignes a un envío por una coincidencia no acordada.
¿Un DLR confirma que el SMS llegó al teléfono?
No necesariamente. El DLR comunica el estado informado por un sistema de la cadena y su alcance depende de la definición del emisor. No lo presentes como prueba independiente de recepción en el terminal sin evidencia documentada que lo respalde.
¿Qué debe probarse antes de aceptar un cambio de formato?
Comprueba los campos obligatorios y opcionales, tipos y formatos acordados, preservación de los valores originales, mapeo de estados, correlación y tratamiento de valores desconocidos, repetidos y tardíos. El resultado esperado debe estar documentado por los participantes.
Fuentes consultadas
- SMPP v3.4 Issue 1.2SMPP Developers Forum
- HTTP Semantics (RFC 9110)IETF
- 3GPP specifications by series3GPP
- ITU-T Recommendation E.164International Telecommunication Union
- GSMA Networks resourcesGSMA