na confirmación de entrega (DLR, por sus siglas en inglés) es un mensaje de estado que se recibe tras enviar un SMS e indica su estado final: ENTREGADO, NO ENTREGADO, EXPIRADO, ELIMINADO, ACEPTADO, DESCONOCIDO o RECHAZADO, según lo define SMPP. Un DLR auténtico proviene del operador de destino, no de la pasarela, por lo que indica si el terminal recibió el mensaje y, mediante su campo de error, el motivo del fallo.
Qué es una confirmación de entrega y qué no lo es.
En el momento en que envías un mensaje, recibes dos señales diferentes, y confundirlas es la causa más común de interrupciones fantasma. La primera es la confirmación de envío: en SMPP, el SMSC devuelve un submit_sm_resp con command_status ESME_ROK (0x00000000); en una API HTTP, recibes un 202 y un ID de mensaje. Esto solo significa que la plataforma aceptó el mensaje para su procesamiento. La segunda señal, que llega más tarde, es la confirmación de entrega: un informe fuera de banda de lo que la red hizo finalmente con el mensaje. En SMPP, regresa como una PDU deliver_sm cuya esm_class la marca como recibo; en una API REST, se entrega a tu webhook. Conecta tu sistema con el DLR, no con la respuesta de envío; consulta la guía para desarrolladores de SMPP para obtener información sobre los indicadores bind y receipt-request.
Confirmación de pasarela frente a un DLR de operador real
No todos los DLR se crean en el mismo punto de la red, y aquí reside la clave de la calidad de la ruta. Un DLR real a nivel de operador se genera en la red de destino después de que el terminal confirme la recepción del mensaje corto en la capa SS7/MAP o Diameter; el SMSC del operador mapea ese informe de la capa de red en el recibo SMPP que usted recibe. Un DLR intermedio o de pasarela, por el contrario, es sintetizado por un agregador cuando entrega el mensaje al siguiente salto, antes de que el operador de destino haya confirmado nada. En una ruta directa sin problemas, ambos coinciden; en una ruta con problemas, no.
Por eso, los DLR falsos son peligrosos. Un agregador de rutas no oficiales que no puede obtener un recibo de operador auténtico suele falsificar un DELIVRD en la transferencia para que sus paneles parezcan correctos, incluso cuando el mensaje se descartó silenciosamente en la red, se filtró o se terminó en el SIM box. La señal de alerta es una tasa de entrega sospechosamente perfecta junto con usuarios reales que nunca recibieron el mensaje, o una ruta que devuelve UNKNOWN en masa (el SMSC no tiene un estado válido porque un salto descendente nunca devolvió un informe real). Pegue cualquier cadena de recibo en el decodificador DLR para ver exactamente qué afirma una ruta en comparación con cómo se ve un recibo de operador auténtico.
Cómo los DLR vuelven a ti
Hay dos transportes y una fuente subyacente. A través de SMPP, la recepción se devuelve de forma asíncrona como una PDU deliver_sm en su sesión vinculada, con el estado final transportado en el cuerpo short_message (la clásica cadena id:… stat:… err:…) y, en v5.0 y muchas implementaciones v3.4, en los TLV message_state y network_error_code. A través de una API HTTP, la misma información se envía mediante POST a un webhook que usted registra, generalmente como JSON. Ambos se derivan en última instancia del propio informe de estado de la red: 3GPP TS 23.040 define el SMS-STATUS-REPORT y su campo TP-Status, que el SMSC de terminación traduce al estado del mensaje SMPP que usted lee. La capa SMPP es un portador fiel de un informe que realmente nace en la red móvil.
Sea cual sea el medio de transporte, registre los mismos campos para cada recibo, de modo que pueda diagnosticar el problema basándose en patrones en lugar de anécdotas:
- El ID del mensaje, para que puedas unir el DLR al submit_sm original.
- El valor stat (el estado final del mensaje) y el valor err (el código de error de la red/operador).
- El operador de destino (MCC/MNC), el ID del remitente y la ruta o enlace utilizado.
- Las marcas de tiempo de fecha de envío y fecha de finalización, para que pueda medir la latencia de extremo a extremo e identificar patrones de EXPIRACIÓN.
id:1a2b3c4d5e sub:001 dlvrd:001 fecha de envío:2608031200 fecha de finalización:2608031201 stat:DELIVRD err:000 texto:Su código BroadNetid:9f8e7d6c5b sub:001 dlvrd:000 fecha de envío:2608031200 fecha de finalización:2608031205 stat:UNDELIV err:062 texto:Su código BroadNetDos campos contienen el diagnóstico. El campo stat es el estado final estandarizado del mensaje (ver más abajo). El campo err es un código específico de la red/operador: el mismo UNDELIV puede llegar con diferentes valores de err en distintos operadores, por lo que err solo tiene sentido en el contexto de su red de destino. Tenga en cuenta que este código err es distinto del estado del comando SMPP que se obtiene en submit_sm_resp (ESME_RINVDSTADR, ESME_RTHROTTLED y similares); ambos se decodifican de forma diferente. Utilice la búsqueda de códigos de error SMPP para los valores de command_status y el decodificador DLR para la cadena de recibo.
El mensaje SMPP indica, decodificado
SMPP define un conjunto pequeño y cerrado de estados finales, además del estado transitorio ENROUTE que puede aparecer antes de que se complete un mensaje. Los siete estados que se muestran a continuación son los que finalizan la vida útil de un mensaje, con su causa típica y la acción que debería desencadenar cada uno. Considérelos como una distribución entre el operador, el ID del remitente y la ruta: un único UNDELIV es ruido; una ruta con un 40 % de UNDELIV en un operador indica un problema de enrutamiento.
| Estado DLR (estadístico) | Qué significa | Causa típica | ¿Qué hacer? |
|---|---|---|---|
| ENTREGADO | El teléfono confirmó la recepción | El mensaje llegó al dispositivo. | Nada: esto es un éxito; verificación aleatoria con informes de usuarios reales para detectar DELIVRD falsificados. |
| ACEPTAR | Aceptado en nombre del suscriptor (por ejemplo, leído por el servicio de atención al cliente). | El operador lo marcó como aceptado sin una confirmación real por parte del terminal. | Considere esto como un éxito parcial; investigue cualquier ruta que devuelva ACCEPTD de forma masiva, ya que a menudo enmascara la falta de entrega. |
| VENCIÓ | El período de validez transcurrió antes de la entrega. | El terminal está apagado o fuera de cobertura durante todo el intervalo de tiempo, o se han agotado los reintentos del SMSC. | Inténtalo de nuevo más tarde o prueba con otro canal; confirma que tu período de validez no sea demasiado corto. |
| ELIMINADO | Mensaje eliminado en el SMSC antes de su entrega. | Eliminación manual/administrativa o eliminación mediante filtro de spam. | Verifique el filtrado de contenido del operador y su política de identificación de remitente/contenido. |
| INDEFINIDO | El mensaje no se puede entregar. | MSISDN no válido o no asignado, sin ruta, rechazo de la capa de red o bloqueo del firewall. | Valide el número (consulta HLR), luego verifique la calidad de la ruta y el registro del ID del remitente. |
| RECHAZADO | El operador rechazó el mensaje. | Identificador de remitente no registrado, filtro de contenido, clasificación de spam o lista de no molestar/consentimiento | Registra el ID del remitente, corrige la plantilla y confirma la suscripción para el destinatario. |
| DESCONOCIDO | El SMSC no tiene un estado válido para el mensaje. | Un salto río abajo nunca devolvía un informe real, a menudo un agujero negro de ruta gris. | Cuestiona la ruta; una ruta directa y saludable rara vez regresa DESCONOCIDA |
Lectura de DLR como señal de calidad de ruta
Una vez que acepta que solo un DLR a nivel de operador es confiable, el feed de recibos se convierte en su mejor instrumento de calidad de ruta, mejor que cualquier mapa de cobertura o presentación de ventas. Las rutas directas devuelven códigos de error específicos y consistentes y una tasa DELIVRD estable; las rutas grises devuelven fallas genéricas, una dispersión de UNKNOWN y una tasa de entrega que fluctúa semana a semana a medida que los firewalls del operador bloquean el tráfico y el agregador redirige silenciosamente. Divida la distribución de DLR terminando el operador y el ID del remitente a lo largo del tiempo: los operadores donde ve un aumento de UNDELIV/UNKNOWN o la desaparición de detalles de error son los que utilizan una ruta degradada. Para los mercados regulados del CCG (EAU bajo el TDRA, Arabia Saudita bajo el CST), REJECTD concentrado en un ID de remitente casi siempre significa una brecha de registro o aprobación de plantilla en lugar de una falla de red.
BroadNet devuelve DLR reales a nivel de operador (no confirmaciones de pasarela) a través de 1,000+ conexiones de operadores en 200+ países, con los campos stat y err expuestos por mensaje para que la calidad de la ruta sea visible en tiempo real, respaldado por un SLA de plataforma del 99,99 % y rutas A2P directas mantenidas desde 2003. Explore la API de SMS o la guía para desarrolladores de SMPP.
Preguntas frecuentes
¿Qué es una confirmación de entrega en SMS?
Una confirmación de entrega (DLR, por sus siglas en inglés) es un informe de estado que se recibe tras enviar un SMS e indica el resultado final del mensaje: entregado, no entregable, caducado, rechazado, etc. Se recibe después de la confirmación de envío, ya sea como una PDU de recibo SMPP deliver_sm o un webhook HTTP. Una confirmación de entrega auténtica proviene del operador de destino, no de la pasarela, por lo que confirma si el terminal recibió realmente el mensaje.
¿Qué significa DLR?
DLR significa confirmación de entrega (a veces "informe de entrega"). En SMPP, es el informe de estado del mensaje que el SMSC devuelve para un mensaje enviado, que incluye un campo de estado (DELIVRD, UNDELIV, EXPIRED, DELETED, ACCEPTD, UNKNOWN, REJECTD) y un código de error específico del operador. Es la diferencia entre saber que un mensaje fue aceptado para su procesamiento y saber que realmente se entregó a un dispositivo.
¿Por qué mi SMS muestra UNELIV / REJECTD?
UNDELIV generalmente significa que el mensaje no pudo llegar al terminal: un MSISDN no válido o no asignado, la ausencia de ruta o un bloqueo de la capa de red o del firewall. REJECTD significa que el operador lo rechazó directamente, normalmente por un ID de remitente no registrado, una coincidencia con el filtro de contenido, una clasificación de spam o una lista de No Molestar/consentimiento. Lea el campo err y correlacione los fallos por ID de remitente, operador y ruta para aislar la causa real.
¿En qué se diferencia un acuse de recibo de pasarela de un DLR de operador?
Un acuse de recibo de pasarela (submit_sm_resp con ESME_ROK o un HTTP 202) solo confirma que la plataforma aceptó el mensaje para su procesamiento. Un DLR del operador confirma qué hizo realmente la red de destino con él. Los agregadores en rutas grises a veces falsifican recibos DELIVRD al transferir el mensaje, por lo que un DLR proporcionado por el operador es la única señal fiable de que el terminal recibió el mensaje.
Referencias
- Especificaciones de SMPP v3.4 y v5.0: formato de confirmación de entrega, message_state y network_error_code: smpp.org
- 3GPP TS 23.040 — realización técnica del Servicio de Mensajes Cortos (SMS-STATUS-REPORT, TP-Status): 3gpp.org
- Herramientas de BroadNet: decodificador DLR y búsqueda de códigos de error SMPP.
- BroadNet: guía para desarrolladores SMPP y API de SMS.