na conferma di consegna (DLR) è un messaggio di stato, restituito dopo l'invio di un SMS, che ne riporta lo stato finale — CONSEGNATO, NON CONSEGNATO, SCADUTO, CANCELLATO, ACCETTATO, SCONOSCIUTO o RIFIUTATO — come definito dallo standard SMPP. Una DLR autentica proviene dall'operatore di destinazione, non dal gateway, quindi indica se il dispositivo ha ricevuto il messaggio e, tramite il campo "err", il motivo della mancata ricezione.
Cos'è una ricevuta di consegna e cosa non è
Nel momento in cui invii un messaggio, ricevi due segnali diversi e confonderli è la causa più comune di interruzioni fantasma. Il primo è la conferma di invio: su SMPP, l'SMSC restituisce un submit_sm_resp con command_status ESME_ROK (0x00000000); su un'API HTTP ricevi un 202 e un ID messaggio. Ciò significa solo che la piattaforma ha accettato il messaggio per l'elaborazione. Il secondo segnale, che arriva in seguito, è la ricevuta di consegna: un report fuori banda di ciò che la rete ha infine fatto con il messaggio. Su SMPP viene restituito come PDU deliver_sm il cui esm_class lo contrassegna come ricevuta; su un'API REST viene consegnato al tuo webhook. Collega il tuo sistema al DLR, non alla risposta di invio: consulta la guida per sviluppatori SMPP per i flag di bind e receipt-request.
Gateway ACK contro un operatore DLR reale
Non tutti i DLR vengono creati nello stesso punto della linea, ed è qui che si cela la qualità del percorso. Un vero DLR a livello di operatore viene generato dalla rete di terminazione dopo che il terminale ha confermato il messaggio breve al livello SS7/MAP o Diameter; l'SMSC dell'operatore mappa tale report a livello di rete nella ricevuta SMPP che ricevi. Un DLR intermedio o di gateway, al contrario, viene sintetizzato da un aggregatore quando passa il messaggio al nodo successivo, prima che l'operatore di terminazione abbia confermato nulla. Su un percorso diretto pulito i due coincidono; su un percorso non standard non coincidono.
Ecco perché i "DLR falsi" sono pericolosi. Un aggregatore di rotte non ufficiali che non riesce a ottenere una ricevuta autentica da un operatore spesso falsifica un DELIVRD al momento del passaggio di consegne, in modo che i suoi dashboard appaiano corretti, anche quando il messaggio è stato silenziosamente scartato a valle, filtrato o terminato dalla SIM box. L'indizio è un tasso di consegna sospettosamente perfetto abbinato a utenti reali che non hanno mai ricevuto il messaggio, oppure una rotta che restituisce UNKNOWN in blocco (l'SMSC non ha uno stato valido perché un hop a valle non ha mai restituito un report reale). Incolla qualsiasi stringa di ricevuta nel decoder DLR per vedere esattamente cosa dichiara una rotta rispetto a come appare una ricevuta autentica da un operatore.
Come i DLR ti vengono restituiti
Esistono due protocolli di trasporto e un'unica sorgente sottostante. Tramite SMPP, la ricezione viene restituita in modo asincrono come PDU deliver_sm sulla sessione associata, con lo stato finale contenuto nel corpo short_message (la classica stringa id:… stat:… err:…) e, nelle implementazioni v5.0 e in molte v3.4, nei TLV message_state e network_error_code. Tramite un'API HTTP, le stesse informazioni vengono inviate tramite POST a un webhook registrato, solitamente in formato JSON. Entrambi derivano in ultima analisi dal report di stato della rete: la specifica 3GPP TS 23.040 definisce l'SMS-STATUS-REPORT e il relativo campo TP-Status, che l'SMSC di destinazione traduce nello stato del messaggio SMPP letto. Il livello SMPP funge da fedele vettore per un report che in realtà nasce sulla rete mobile.
Qualunque sia il mezzo di trasporto, registra gli stessi campi per ogni ricevuta in modo da poter diagnosticare il problema basandoti su schemi ricorrenti anziché su aneddoti:
- L'ID del messaggio, in modo da poter collegare il DLR al submit_sm originale.
- Il valore stat (lo stato finale del messaggio) e il valore err (il codice di errore di rete/operatore).
- L'operatore di destinazione (MCC/MNC), l'ID del mittente e il percorso o l'associazione utilizzati.
- I timestamp di invio e di completamento consentono di misurare la latenza end-to-end e di individuare i modelli SCADUTI.
ID:1a2b3c4d5e sub:001 dlvrd:001 data di invio:2608031200 data di completamento:2608031201 stat:DELIVRD err:000 testo:Il tuo codice BroadNetID:9f8e7d6c5b sub:001 dlvrd:000 data di invio:2608031200 data di completamento:2608031205 stat:UNDELIV err:062 testo:Il tuo codice BroadNetLa diagnosi è contenuta in due campi. Il campo stat indica lo stato finale standardizzato del messaggio (vedi sotto). Il campo err è un codice specifico della rete/operatore: lo stesso messaggio UNDELIV può arrivare con valori di err diversi su operatori diversi, quindi err è significativo solo nel contesto della rete di destinazione. Si noti che questo codice err è distinto dallo stato del comando SMPP che si ottiene con submit_sm_resp (ESME_RINVDSTADR, ESME_RTHROTTLED e simili); i due vengono decodificati in modo diverso. Utilizzare la ricerca dei codici di errore SMPP per i valori di command_status e il decodificatore DLR per la stringa di ricezione.
Il messaggio SMPP afferma, decodificato
SMPP definisce un piccolo insieme chiuso di stati finali, oltre allo stato transitorio ENROUTE che si può osservare prima che un messaggio venga elaborato. I sette stati seguenti sono quelli che terminano il ciclo di vita di un messaggio, con la causa tipica e l'azione che ciascuno dovrebbe innescare. Interpretateli come una distribuzione tra operatore, ID mittente e percorso: un singolo UNDELIV è rumore; un percorso con il 40% di UNDELIV su un operatore indica un problema di percorso.
| Stato DLR (stat) | Cosa significa | causa probabile | Cosa fare |
|---|---|---|---|
| CONSEGNARE | Il telefono ha confermato la ricezione | Il messaggio ha raggiunto il dispositivo | Niente: questo è un successo; verifica a campione con segnalazioni di utenti reali per individuare DELIVRD falsificati |
| ACCETTATO | Accettato per conto dell'abbonato (ad esempio, letto dal servizio clienti) | L'operatore ha contrassegnato la richiesta come accettata senza una vera conferma da parte del telefono. | Consideralo come un successo parziale; indaga su qualsiasi percorso che restituisca ACCEPTD in blocco: spesso maschera la mancata consegna. |
| SCADUTO | Il periodo di validità è scaduto prima della consegna. | Telefono spento o fuori copertura per l'intera finestra temporale, oppure tentativi SMSC esauriti. | Riprova più tardi o prova un altro canale; verifica che il tuo periodo di validità non sia troppo breve. |
| CANCELLATO | Messaggio rimosso presso l'SMSC prima della consegna | Eliminazione manuale/da parte dell'amministratore o rimozione del filtro antispam | Verifica il filtro dei contenuti dell'operatore e le tue policy relative all'ID mittente e ai contenuti. |
| NON DELIZIOSO | Il messaggio non è recapitato | MSISDN non valido o non allocato, nessuna rotta, rifiuto a livello di rete o blocco del firewall. | Convalidare il numero (ricerca HLR), quindi verificare la qualità del percorso e la registrazione dell'ID mittente. |
| RESPINTO | L'operatore ha rifiutato il messaggio | ID mittente non registrato, filtro contenuti, classificazione spam o elenco DND/consenso | Registra l'ID del mittente, correggi il modello e conferma l'adesione per la destinazione |
| SCONOSCIUTO | L'SMSC non ha uno stato valido per il messaggio | Un collegamento a valle non restituiva mai un rapporto reale, spesso un buco nero di percorso grigio. | Metti in discussione il percorso; un percorso diretto e salutare raramente restituisce un risultato SCONOSCIUTO |
Interpretare i DLR come segnale di qualità del percorso
Una volta accettato che solo un DLR a livello di operatore sia affidabile, il feed di ricezione diventa il miglior strumento per valutare la qualità del percorso, superiore a qualsiasi mappa di copertura o presentazione commerciale. I percorsi diretti restituiscono codici di errore specifici e coerenti e un tasso di consegna stabile; i percorsi grigi restituiscono errori generici, una serie di errori UNKNOWN e un tasso di consegna che varia di settimana in settimana, poiché i firewall degli operatori intercettano il traffico e l'aggregatore lo reindirizza silenziosamente. È possibile segmentare la distribuzione DLR terminando l'operatore e l'ID del mittente nel tempo: gli operatori in cui si osserva un aumento di UNDELIV/UNKNOWN o la scomparsa dei dettagli sugli errori sono quelli che utilizzano un percorso in deterioramento. Per i mercati regolamentati del GCC (Emirati Arabi Uniti sotto TDRA, Arabia Saudita sotto CST), gli errori REJECTD concentrati su un singolo ID mittente indicano quasi sempre un problema di registrazione o di approvazione del modello, piuttosto che un guasto di rete.
BroadNet restituisce DLR reali a livello di operatore, non ACK di gateway, su 1,000+ connessioni con operatori in 200+ paesi, con i campi stat ed err esposti per messaggio in modo che la qualità del percorso sia visibile in tempo reale, supportato da un SLA di piattaforma del 99,99% e percorsi A2P diretti mantenuti dal 2003. Esplora l'API SMS o la guida per sviluppatori SMPP.
Domande frequenti
Che cos'è una ricevuta di consegna via SMS?
Una ricevuta di consegna (DLR) è un rapporto di stato restituito dopo l'invio di un SMS, che indica l'esito finale del messaggio: consegnato, non consegnabile, scaduto, rifiutato e così via. Arriva dopo la conferma di invio, come PDU di ricevuta SMPP deliver_sm o come webhook HTTP. Una ricevuta valida proviene dall'operatore di destinazione, non dal gateway, e conferma quindi se il dispositivo mobile ha effettivamente ricevuto il messaggio.
Cosa significa DLR?
DLR sta per "reception receipt" (a volte "report di consegna"). In SMPP, è il report sullo stato del messaggio che l'SMSC restituisce per un messaggio inviato, contenente un campo stat (DELIVRD, UNDELIV, EXPIRED, DELETED, ACCEPTD, UNKNOWN, REJECTD) e un codice di errore specifico dell'operatore. Rappresenta la differenza tra sapere che un messaggio è stato accettato per l'elaborazione e sapere che è stato effettivamente consegnato a un dispositivo.
Perché il mio SMS risulta NON CONSEGNATO / RIFIUTATO?
UNDELIV di solito significa che il messaggio non è riuscito a raggiungere il telefono: un MSISDN non valido o non assegnato, nessuna rotta o un blocco a livello di rete o firewall. REJECTD significa che l'operatore lo ha rifiutato categoricamente, in genere per un ID mittente non registrato, un filtro antispam, una classificazione spam o un elenco DND/consenso. Leggi il campo err e correla gli errori per ID mittente, operatore e rotta per isolare la causa reale.
In che modo un ACK di gateway si differenzia da un DLR dell'operatore?
Una conferma del gateway (submit_sm_resp con ESME_ROK o un HTTP 202) conferma solo che la piattaforma ha accettato il messaggio per l'elaborazione. Un DLR dell'operatore conferma cosa la rete di terminazione ha effettivamente fatto con il messaggio. Gli aggregatori sulle rotte non ufficiali a volte falsificano le ricevute DELIVRD al momento dell'handoff, quindi un DLR proveniente dall'operatore è l'unico segnale affidabile che il terminale ha ricevuto il messaggio.
Riferimenti
- Specifiche SMPP v3.4 e v5.0: formato della ricevuta di consegna, message_state e network_error_code: smpp.org
- 3GPP TS 23.040 — Realizzazione tecnica del servizio di messaggistica breve (SMS-STATUS-REPORT, TP-Status): 3gpp.org
- Strumenti BroadNet: decodificatore DLR e ricerca dei codici di errore SMPP.
- BroadNet: guida per sviluppatori SMPP e API SMS.