--- title: "Decodificatore dei rapporti di consegna SMS (DLR)" description: "Decodificate le ricevute di consegna SMPP: codici stat come DELIVRD e UNDELIV, err, date di invio e completamento, latenza ed errori command_status. Gratis." canonical: "https://omnichannels.ai/it/tools/sms-delivery-report-decoder/" language: "it" updated: "2026-10-10" publisher: "BroadNet Technologies" brand: "OmniChannels.ai" --- # Decodificatore dei rapporti di consegna SMS (DLR) Canonical: https://omnichannels.ai/it/tools/sms-delivery-report-decoder/ Language: it Publisher: OmniChannels.ai by BroadNet Technologies Un rapporto di consegna SMPP (DLR) è la ricevuta che un SMSC restituisce in una PDU deliver_sm dopo che avete inviato un SMS. Il suo testo segue lo schema id, sub, dlvrd, data di invio, data di completamento, stat, err e text. Il campo stat contiene l'esito: DELIVRD significa consegnato al telefono; UNDELIV, EXPIRED, DELETED e REJECTD sono fallimenti definitivi; ENROUTE e ACCEPTD sono intermedi. Le date usano YYMMDDhhmm, a volte con i secondi. ## Come decodificare una ricevuta di consegna SMS 1. **Copiate il testo della ricevuta:** Prendete lo short_message della PDU deliver_sm dal vostro client SMPP o dal log dell'SMSC, ad esempio id:… sub:001 dlvrd:001 … stat:DELIVRD err:000. I prefissi dei log vengono ignorati. 2. **Incollatene una per riga:** Incollate una singola ricevuta o centinaia. Potete anche incollare da solo su una riga un valore command_status come 0x00000058 o ESME_RTHROTTLED. 3. **Leggete i campi decodificati:** Ogni ricevuta mostra il significato dello stato, se è definitivo, lo stato del webhook più vicino, date leggibili, latenza di consegna e avvisi per campi mancanti o incoerenti. 4. **Controllate il riepilogo del lotto:** Vedete i conteggi per stat e per stato del webhook, il tasso di consegna e la latenza mediana, poi copiate tutto come JSON per un ticket o una fixture di test. ## Anatomia di una ricevuta di consegna SMPP Quando inviate un SMS con registered_delivery impostato a 1, l'SMSC rimanda poi una PDU deliver_sm su un bind receiver o transceiver. Il bit 0x04 del suo esm_class la contrassegna come ricevuta di consegna anziché come messaggio in entrata, e il suo short_message porta una ricevuta testuale. L'Appendice B della specifica SMPP v3.4 fornisce questo formato come esempio, e quasi ogni SMSC lo segue: id:IIIIIIIIII sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDDDDDD err:E text:…. Poiché l'Appendice B è un esempio e non una regola rigida, le ricevute reali variano: chiavi in minuscolo, spazi aggiuntivi, submit_date con trattino basso, date a 12 cifre con i secondi o text mancante. Questo decodificatore accetta tutte queste varianti e vi dice quali campi mancano. - id: l'ID del messaggio restituito dall'SMSC in submit_sm_resp. Usatelo per associare la ricevuta al vostro messaggio. L'esempio della specifica mostra 10 caratteri, ma molti SMSC usano ID più lunghi, a volte in esadecimale. - sub e dlvrd: il numero di messaggi inizialmente inviati e consegnati, su 3 cifre. Contano soprattutto per le liste di distribuzione; per un singolo SMS sono tipicamente 001 e 001 (o 000). - submit date e done date: quando il messaggio è stato inviato e quando ha raggiunto il suo stato finale, secondo l'orologio dell'SMSC. - stat: lo stato finale o intermedio, come codice di 7 lettere come DELIVRD. - err: un codice di errore di 3 caratteri, specifico della rete o dell'SMSC; 000 significa nessun errore. - text: i primi 20 caratteri del messaggio originale, spesso troncati o vuoti. - I TLV facoltativi possono ripetere questi dati in forma più pulita: receipted_message_id (0x001E), message_state (0x0427) e network_error_code (0x0423). ## Codici stat dei DLR e loro significato SMPP v3.4 definisce otto stati del messaggio. ENROUTE e ACCEPTD sono intermedi; gli altri sono definitivi. La nostra API normalizza ogni canale in sei stati del webhook (SUBMITTED, SENT, DELIVERED, READ, FAILED, REJECTED), e il decodificatore mostra la corrispondenza più vicina per ogni valore di stat. Considerate quella mappatura indicativa: la regola esatta per il vostro account viene confermata durante l'attivazione (onboarding). - DELIVRD (message_state 2): consegnato al telefono. Stato del webhook più vicino: DELIVERED. - ACCEPTD (6): formalmente 'letto manualmente per conto dell'abbonato dal servizio clienti', ma la maggior parte degli SMSC lo invia come ricevuta intermedia 'accettato dalla rete'. Più vicino: SENT. - ENROUTE (1): ancora in transito, ad esempio in coda per un nuovo tentativo. Più vicino: SENT. - UNDELIV (5): non consegnabile, ad esempio un numero non valido o inattivo. Più vicino: FAILED. - EXPIRED (3): il periodo di validità è terminato prima di poter raggiungere il telefono, spesso perché era spento o fuori copertura. Più vicino: FAILED. - DELETED (4): cancellato prima della consegna, ad esempio con cancel_sm. Più vicino: FAILED. - REJECTD (8): rifiutato dalla rete o da un firewall, ad esempio per un Sender ID non registrato o contenuti bloccati. Più vicino: REJECTED. - UNKNOWN (7): l'SMSC non ha uno stato finale. Trattatelo come non confermato, non come un fallimento provato. ## Codici err: perché non esiste un elenco universale Il campo err è largo tre caratteri e la specifica SMPP non ne definisce i valori. 000 significa sempre nessun errore, ma i valori diversi da zero provengono dal fornitore dell'SMSC, dall'operatore o da un aggregatore intermedio. Alcuni SMSC passano le cause di errore GSM MAP (ad esempio, l'errore MAP 1 è abbonato sconosciuto e 27 è abbonato assente), mentre altri mappano tutto sulla propria tabella. Se la ricevuta porta il TLV network_error_code (0x0423), è più affidabile: il suo primo ottetto indica il tipo di rete (3 significa GSM) e i due successivi il codice di errore. Una ricevuta DELIVRD con un err diverso da zero è incoerente e va segnalata al vostro fornitore; il decodificatore la segnala. ## Errori command_status e ricevute di consegna SMPP segnala i problemi in due momenti. Il command_status in submit_sm_resp arriva in millisecondi e dice se l'SMSC ha accettato la vostra richiesta; 0x00000000 (ESME_ROK) significa accettato, non consegnato. La ricevuta di consegna arriva da secondi a giorni dopo e porta l'esito finale. I valori di command_status sono definiti nella sezione 5.1.3 di SMPP v3.4. I più comuni in produzione sono 0x00000058 ESME_RTHROTTLED (avete superato i messaggi al secondo concordati: rallentate e riprovate con backoff esponenziale), 0x00000014 ESME_RMSGQFUL (coda piena: rallentate), 0x0000000A e 0x0000000B (indirizzo di origine o destinazione non valido) e 0x0000000D o 0x0000000E (bind fallito o password errata). I valori da 0x00000400 a 0x000004FF sono riservati agli errori specifici del fornitore dell'SMSC, quindi chiedete al vostro fornitore. ## Date, fusi orari e latenza di consegna Le date delle ricevute usano YYMMDDhhmm, e molti SMSC aggiungono i secondi (YYMMDDhhmmss). La ricevuta non porta alcun fuso orario: l'ora è quella dell'orologio dell'SMSC, di solito UTC. Il decodificatore mostra le date esattamente come scritte e calcola la latenza come data di completamento meno data di invio, che non risente del fuso orario finché entrambe provengono dallo stesso orologio. La latenza è un utile segnale di qualità. Il traffico OTP sano verso un telefono raggiungibile si completa di solito in pochi secondi. Latenze lunghe seguite da EXPIRED indicano telefoni spenti o in roaming, e una data di completamento precedente alla data di invio significa che i due orologi non concordano. Le date al minuto non possono misurare latenze inferiori al minuto, quindi preferite gli SMSC che inviano i secondi. ## Gestire le ricevute in modo affidabile in produzione Rispondete a ogni deliver_sm con deliver_sm_resp, anche se la vostra elaborazione fallisce, altrimenti l'SMSC la reinvia e può limitare il bind. Conservate la ricevuta grezza, poi elaboratela in modo asincrono e idempotente per ID messaggio, perché le ricevute possono arrivare due volte o fuori ordine: un ENROUTE in ritardo non deve mai sovrascrivere un DELIVRD. Se preferite non analizzare affatto le ricevute, la nostra API SMS REST fornisce le stesse informazioni come stati del webhook normalizzati, e le ricevute mancate possono essere reinviate con POST /sms/resendDlr. I bind SMPP su TLS sono disponibili per i mittenti ad alto volume e per i rivenditori. ## Domande sui rapporti di consegna ### Cosa significa stat:DELIVRD in un rapporto di consegna SMS? DELIVRD è lo stato SMPP 'consegnato': l'SMSC ha la conferma che il messaggio ha raggiunto il telefono del destinatario. Non significa che il messaggio sia stato aperto o letto; l'SMS semplice non ha conferme di lettura. Nei nostri webhook corrisponde a DELIVERED. ### Qual è la differenza tra UNDELIV, EXPIRED e REJECTD? UNDELIV significa che la rete non ha potuto consegnare il messaggio, ad esempio perché il numero è non valido o inattivo. EXPIRED significa che i tentativi di consegna sono continuati fino alla fine del periodo di validità, di solito perché il telefono era spento o fuori copertura. REJECTD significa che la rete o un firewall ha rifiutato il messaggio, ad esempio per un Sender ID non registrato o contenuti bloccati. ### Cosa significa ACCEPTD in un DLR SMPP? Nella specifica SMPP v3.4 ACCEPTD significa che il messaggio è stato letto manualmente per conto dell'abbonato dal servizio clienti. In pratica la maggior parte degli SMSC e degli aggregatori lo usa come ricevuta intermedia che significa che la rete ha accettato il messaggio, e segue una ricevuta finale DELIVRD o di fallimento. ### Cos'è l'errore SMPP 0x00000058? 0x00000058 è ESME_RTHROTTLED: avete inviato più messaggi al secondo di quanti il vostro bind ne consenta. È temporaneo. Riducete la frequenza di invio, mantenete una finestra ragionevole di PDU submit_sm in sospeso e riprovate i messaggi rifiutati con backoff esponenziale anziché subito. ### Cosa significa err:000 e dove trovo gli altri codici err? err:000 significa nessun errore. I valori err diversi da zero non sono definiti dalla specifica SMPP; provengono dal fornitore dell'SMSC, dall'operatore o da un aggregatore, e alcuni passano le cause di errore GSM MAP. Chiedete al vostro fornitore la sua tabella degli errori e controllate il TLV network_error_code se presente. ### Che formato di data usa una ricevuta di consegna SMPP? submit date e done date usano YYMMDDhhmm, ad esempio 2610101201 per il 10 ottobre 2026 alle 12:01. Molti SMSC aggiungono i secondi (YYMMDDhhmmss). Non è incluso alcun fuso orario; è l'orologio dell'SMSC, di solito UTC. ### Perché non ho ricevuto un rapporto di consegna? Le cause comuni sono registered_delivery non impostato a 1 in submit_sm, l'uso di un bind solo transmitter senza un bind receiver, una rete di destinazione che non restituisce ricevute o il vostro client che non conferma deliver_sm. Alcune rotte restituiscono solo ricevute intermedie. Per il traffico REST, controllate il vostro endpoint webhook e rinviate le ricevute con /sms/resendDlr. ### Il testo della mia ricevuta viene inviato da qualche parte quando uso questo strumento? No. Il decodificatore funziona interamente nel vostro browser. Nulla di ciò che incollate, compresi ID e testo dei messaggi, viene inviato ai nostri server.