--- title: "Decodificador de informes de entrega SMS (DLR)" description: "Decodifique informes de entrega SMPP: códigos stat como DELIVRD y UNDELIV, err, fechas, latencia y errores command_status. Gratis y en su navegador." canonical: "https://omnichannels.ai/es/tools/sms-delivery-report-decoder/" language: "es" updated: "2026-10-10" publisher: "BroadNet Technologies" brand: "OmniChannels.ai" --- # Decodificador de informes de entrega SMS (DLR) Canonical: https://omnichannels.ai/es/tools/sms-delivery-report-decoder/ Language: es Publisher: OmniChannels.ai by BroadNet Technologies Un informe de entrega SMPP (DLR) es la confirmación que un SMSC devuelve en una PDU deliver_sm después de enviar un SMS. Su texto sigue el patrón id, sub, dlvrd, submit date, done date, stat, err y text. El campo stat indica el resultado: DELIVRD significa entregado en el teléfono; UNDELIV, EXPIRED, DELETED y REJECTD son fallos definitivos; ENROUTE y ACCEPTD son intermedios. Las fechas usan AAMMDDhhmm, a veces con segundos. ## Cómo decodificar un informe de entrega SMS 1. **Copie el texto de la confirmación:** Tome el short_message de la PDU deliver_sm desde su cliente SMPP o los registros del SMSC, por ejemplo id:… sub:001 dlvrd:001 … stat:DELIVRD err:000. Los prefijos de registro se ignoran. 2. **Pegue una por línea:** Pegue una sola confirmación o cientos. También puede pegar un valor command_status, como 0x00000058 o ESME_RTHROTTLED, en su propia línea. 3. **Lea los campos decodificados:** Cada confirmación muestra el significado del estado, si es final, el estado de webhook más cercano, fechas legibles, la latencia de entrega y avisos sobre campos ausentes o incoherentes. 4. **Revise el resumen del lote:** Vea los totales por stat y por estado de webhook, la tasa de entrega y la latencia mediana, y copie todo como JSON para un ticket o un caso de prueba. ## Anatomía de un informe de entrega SMPP Cuando envía un SMS con registered_delivery en 1, el SMSC devuelve más tarde una PDU deliver_sm por un bind receptor o transceptor. El bit 0x04 de su esm_class indica que es un informe de entrega y no un mensaje entrante, y su short_message contiene la confirmación en texto. El anexo B de la especificación SMPP v3.4 presenta este formato como ejemplo, y casi todos los SMSC lo siguen: id:IIIIIIIIII sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDDDDDD err:E text:…. Como el anexo B es un ejemplo y no una regla estricta, las confirmaciones reales varían: claves en minúsculas, espacios de más, submit_date con guion bajo, fechas de 12 dígitos con segundos o sin campo text. Este decodificador acepta todas esas variantes e indica qué campos faltan. - id: el identificador que el SMSC devolvió en submit_sm_resp. Sirve para asociar la confirmación con su mensaje. El ejemplo de la especificación muestra 10 caracteres, pero muchos SMSC usan identificadores más largos, a veces en hexadecimal. - sub y dlvrd: el número de mensajes enviados y entregados, con 3 dígitos. Importan sobre todo en listas de distribución; para un SMS individual suelen ser 001 y 001 (o 000). - submit date y done date: cuándo se envió el mensaje y cuándo alcanzó su estado final, según el reloj del SMSC. - stat: el estado final o intermedio, como código de 7 letras, por ejemplo DELIVRD. - err: un código de error de 3 caracteres, propio de la red o del SMSC; 000 significa sin error. - text: los primeros 20 caracteres del mensaje original, a menudo truncados o vacíos. - Algunos TLV opcionales repiten estos datos de forma más limpia: receipted_message_id (0x001E), message_state (0x0427) y network_error_code (0x0423). ## Códigos stat de los DLR y su significado SMPP v3.4 define ocho estados de mensaje. ENROUTE y ACCEPTD son intermedios; los demás son finales. Nuestra API normaliza todos los canales en seis estados de webhook (SUBMITTED, SENT, DELIVERED, READ, FAILED, REJECTED), y el decodificador muestra el equivalente más cercano para cada valor stat. Considere esa correspondencia orientativa: la regla exacta de su cuenta se confirma durante la incorporación. - DELIVRD (message_state 2): entregado en el teléfono. Estado de webhook más cercano: DELIVERED. - ACCEPTD (6): formalmente «leído manualmente por atención al cliente en nombre del abonado», pero la mayoría de los SMSC lo envían como confirmación intermedia de «aceptado por la red». Más cercano: SENT. - ENROUTE (1): aún en tránsito, por ejemplo en cola para un reintento. Más cercano: SENT. - UNDELIV (5): no entregable, por ejemplo un número inválido o inactivo. Más cercano: FAILED. - EXPIRED (3): el periodo de validez terminó antes de alcanzar el teléfono, a menudo apagado o sin cobertura. Más cercano: FAILED. - DELETED (4): eliminado antes de la entrega, por ejemplo con cancel_sm. Más cercano: FAILED. - REJECTD (8): rechazado por la red o por un firewall de SMS, por ejemplo por un ID de remitente no registrado o contenido bloqueado. Más cercano: REJECTED. - UNKNOWN (7): el SMSC no tiene un estado final. Trátelo como no confirmado, no como un fallo comprobado. ## Códigos err: por qué no hay una lista universal El campo err tiene tres caracteres y la especificación SMPP no define sus valores. 000 siempre significa sin error, pero los demás valores provienen del fabricante del SMSC, del operador o de un agregador intermedio. Algunos SMSC transmiten causas de error GSM MAP (por ejemplo, el error MAP 1 es abonado desconocido y el 27 es abonado ausente), mientras que otros usan su propia tabla. Si la confirmación incluye el TLV network_error_code (0x0423), es más fiable: su primer octeto indica el tipo de red (3 significa GSM) y los dos siguientes, el código de error. Una confirmación DELIVRD con err distinto de cero es incoherente y conviene comentarla con su proveedor; el decodificador la señala. ## Errores command_status frente a informes de entrega SMPP informa de los problemas en dos momentos. El command_status de submit_sm_resp llega en milisegundos e indica si el SMSC aceptó su solicitud; 0x00000000 (ESME_ROK) significa aceptado, no entregado. El informe de entrega llega entre segundos y días después y trae el resultado final. Los valores command_status se definen en la sección 5.1.3 de SMPP v3.4. Los más habituales en producción son 0x00000058 ESME_RTHROTTLED (superó los mensajes por segundo acordados: reduzca el ritmo y reintente con backoff exponencial), 0x00000014 ESME_RMSGQFUL (cola llena: espere), 0x0000000A y 0x0000000B (dirección de origen o de destino inválida) y 0x0000000D o 0x0000000E (fallo del bind o contraseña incorrecta). Los valores 0x00000400 a 0x000004FF están reservados para errores propios del fabricante del SMSC: consulte a su proveedor. ## Fechas, zonas horarias y latencia de entrega Las fechas de las confirmaciones usan AAMMDDhhmm, y muchos SMSC añaden los segundos (AAMMDDhhmmss). No se indica zona horaria: la hora es la del reloj del SMSC, normalmente UTC. El decodificador muestra las fechas tal como aparecen y calcula la latencia como done date menos submit date, lo que no depende de la zona horaria mientras ambas vengan del mismo reloj. La latencia es una buena señal de calidad. Un OTP a un teléfono disponible suele completarse en segundos. Latencias largas seguidas de EXPIRED apuntan a teléfonos apagados o en itinerancia, y una done date anterior a la submit date indica relojes desajustados. Las fechas al minuto no permiten medir latencias inferiores a un minuto, así que son preferibles los SMSC que envían segundos. ## Procesar confirmaciones de forma fiable en producción Responda a cada deliver_sm con deliver_sm_resp, aunque su procesamiento falle; de lo contrario, el SMSC lo reenvía y puede limitar el bind. Guarde la confirmación en bruto y procésela de forma asíncrona e idempotente por identificador de mensaje, porque las confirmaciones pueden llegar duplicadas o desordenadas: un ENROUTE tardío nunca debe sobrescribir un DELIVRD. Si prefiere no analizar confirmaciones, nuestra API REST de SMS entrega la misma información como estados de webhook normalizados, y las confirmaciones perdidas pueden reenviarse con POST /sms/resendDlr. Hay binds SMPP sobre TLS disponibles para grandes volúmenes y revendedores. ## Preguntas sobre informes de entrega ### ¿Qué significa stat:DELIVRD en un informe de entrega SMS? DELIVRD es el estado SMPP «entregado»: el SMSC tiene confirmación de que el mensaje llegó al teléfono del destinatario. No significa que se haya abierto o leído; el SMS convencional no tiene confirmación de lectura. En nuestros webhooks corresponde a DELIVERED. ### ¿Qué diferencia hay entre UNDELIV, EXPIRED y REJECTD? UNDELIV significa que la red no pudo entregar el mensaje, por ejemplo porque el número es inválido o está inactivo. EXPIRED significa que los intentos continuaron hasta que terminó el periodo de validez, normalmente porque el teléfono estaba apagado o sin cobertura. REJECTD significa que la red o un firewall rechazó el mensaje, por ejemplo por un ID de remitente no registrado o contenido bloqueado. ### ¿Qué significa ACCEPTD en un DLR de SMPP? En la especificación SMPP v3.4, ACCEPTD significa que atención al cliente leyó el mensaje manualmente en nombre del abonado. En la práctica, la mayoría de los SMSC y agregadores lo usan como confirmación intermedia de que la red aceptó el mensaje, y después llega una confirmación final DELIVRD o de fallo. ### ¿Qué es el error SMPP 0x00000058? 0x00000058 es ESME_RTHROTTLED: envió más mensajes por segundo de los que permite su bind. Es temporal. Reduzca la velocidad de envío, mantenga una ventana razonable de submit_sm pendientes y reintente los mensajes rechazados con backoff exponencial en lugar de hacerlo de inmediato. ### ¿Qué significa err:000 y dónde encuentro los demás códigos err? err:000 significa sin error. Los valores err distintos de cero no los define la especificación SMPP; provienen del fabricante del SMSC, del operador o de un agregador, y algunos reproducen causas de error GSM MAP. Pida a su proveedor su tabla de errores y revise el TLV network_error_code si está presente. ### ¿Qué formato de fecha usa un informe de entrega SMPP? submit date y done date usan AAMMDDhhmm, por ejemplo 2610101201 para el 10 de octubre de 2026 a las 12:01. Muchos SMSC añaden segundos (AAMMDDhhmmss). No se incluye zona horaria: es el reloj del SMSC, normalmente UTC. ### ¿Por qué no recibí un informe de entrega? Causas habituales: registered_delivery no está en 1 en submit_sm, se usa un bind solo transmisor sin bind receptor, la red de destino no devuelve confirmaciones o su cliente no responde a los deliver_sm. Algunas rutas solo devuelven confirmaciones intermedias. Para tráfico REST, revise su webhook y reenvíe las confirmaciones con /sms/resendDlr. ### ¿Se envía a algún sitio el texto de mis confirmaciones? No. El decodificador funciona completamente en su navegador. Nada de lo que pegue, incluidos identificadores o texto de mensajes, se envía a nuestros servidores.