Guasto di connettività o degrado della rotta A2P SMS: come isolare la causa con prove concrete

Connettività, accettazione e consegna sono segnali distinti

Un incidente A2P SMS può verificarsi in diversi punti del percorso. La connessione può non riuscire prima dell'invio del messaggio; la piattaforma o l'SMSC possono rifiutarlo; l'invio può essere accettato senza che sia ancora disponibile un risultato finale; oppure può verificarsi un errore dopo l'accettazione. Ogni situazione richiede prove diverse.

In SMPP, una risposta positiva a submit_sm indica che l'SMSC ha accettato il messaggio per l'invio successivo. Da sola, non conferma che il messaggio sia arrivato al telefono. Analogamente, ENQUIRE_LINK ed ENQUIRE_LINK_RESP verificano la connessione applicativa tra ESME e SMSC, non la consegna attraverso la rete mobile.

• Connessione o sessione: verifica se il client riesce a stabilire e mantenere la comunicazione con l'interfaccia.
• Risposta all'invio: determina se la richiesta è stata accettata o rifiutata e registra il motivo disponibile.
• Esito successivo: correla i rapporti di stato con il messaggio originale e verifica quale entità li ha emessi.
• Ricezione da parte dell'utente: non dedurre che una persona abbia letto l'SMS da una risposta di protocollo o da un DLR.

Delimita il percorso e conserva gli identificativi

Prima di modificare rotte o configurazioni, rappresenta il percorso effettivamente seguito dal traffico: applicazione client, integrazione HTTP o sessione SMPP, piattaforma, fornitore e destinazione mobile. Annota in quale punto viene generato ciascun log e chi produce ogni risposta. Le funzionalità interne di un Service Centre possono non essere osservabili tramite un'interfaccia o una specifica: riconosci questo limite nell'analisi.

Conserva timestamp e riferimenti sufficienti a collegare le varie fasi. In SMPP, registra il numero di sequenza della richiesta e della risposta, l'identificativo del messaggio restituito e, se arriva una ricevuta, il riferimento al messaggio originale. Per HTTP, conserva l'eventuale identificativo della richiesta, l'ora, l'endpoint e la risposta. Non presumere che gli identificativi di sistemi diversi siano intercambiabili.

• Registra l'ora di invio e il fuso orario, la destinazione in formato normalizzato, il mittente, il tipo di traffico e la rotta selezionata.
• Salva il codice HTTP o lo stato SMPP, il corpo o i campi di errore pertinenti e l'identificativo di correlazione disponibile.
• Aggiungi l'ora e l'origine di ogni callback o DLR, oltre al riferimento al messaggio.
• Proteggi i dati personali e limita l'accesso ai log in base alle policy applicabili.

Verifica prima l'integrazione

Inizia dal lato che controlli. Per HTTP, distingui gli errori di trasporto dalle risposte HTTP ed esamina il codice, il corpo e le eventuali indicazioni sui nuovi tentativi. Un 503 significa che il server non può soddisfare temporaneamente la richiesta; può essere associato, per esempio, a sovraccarico o manutenzione, e Retry-After può indicare quanto attendere. Un 429 significa che il server ritiene che siano state inviate troppe richieste in un determinato periodo; la risposta può includere anche Retry-After. Un 502 segnala un problema del gateway o del proxy, che ha ricevuto una risposta non valida dal server upstream, ma da solo non indica quale componente abbia originato il problema.

In SMPP, verifica lo stato di bind, le disconnessioni, i timeout, le risposte alle richieste e lo stato della sessione. ESME_RTHROTTLED (0x58) indica che l'ESME ha superato i limiti consentiti su quell'interfaccia. È una prova di limitazione della frequenza su tale interfaccia, non di un degrado su una rotta di destinazione.

Controlla anche la coda locale, la conferma di ricezione dei callback e la logica dei nuovi tentativi. SMPP non garantisce di per sé l'idempotenza. In caso di timeout, il solo segnale potrebbe non bastare a stabilire se l'SMSC abbia elaborato la richiesta. Prima di riprovare, utilizza gli eventuali meccanismi documentati di correlazione e consultazione dello stato; non presumere che sia sempre possibile determinare se l'operazione sia già stata accettata.

• Se la connessione o il bind non riescono, verifica prima le credenziali, la configurazione della sessione, la connettività e i limiti dell'interfaccia.
• Se ricevi rifiuti, raggruppali per codice e conserva le risposte originali prima di modificare i parametri.
• Se compaiono 429 o ESME_RTHROTTLED, confronta il volume e la frequenza delle richieste con i limiti concordati; non classificarli automaticamente come un problema di copertura.
• In caso di 503 o 502, contatta il responsabile del componente che ha risposto e fornisci l'ora, l'identificativo e la risposta osservata.

Cerca schemi ricorrenti in base alla destinazione e agli attributi del traffico

Per indagare un degrado della rotta, cerca differenze ripetibili tra segmenti anziché isolare un singolo messaggio senza contesto. Confronta destinazioni, operatori quando l'informazione è affidabile, mittenti, tipo di traffico, rotta e intervallo temporale. Quando possibile, mantieni costanti gli altri attributi rilevanti: confrontare invii diversi può confondere l'effetto della rotta con variazioni di destinatario, mittente, contenuto o configurazione.

Registra quale segmento presenta il problema e quale usi come confronto. Se un incidente coincide con un operatore di destinazione, è un indizio utile per circoscrivere l'indagine, ma non dimostra che la causa sia la rete di quell'operatore. Verifica che campione e parametri siano confrontabili e richiedi ulteriori prove alle parti che controllano le fasi non visibili.

• Raggruppa i casi per paese o destinazione, operatore noto, mittente, tipo di traffico OTP/transazionale/marketing, rotta e intervallo temporale.
• Confronta separatamente le percentuali di accettazione, rifiuto e stati finali; non mescolare metriche definite in modo diverso.
• Verifica che i messaggi confrontati abbiano configurazioni equivalenti e che gli intervalli temporali siano coerenti.
• Annota le modifiche di configurazione, volume o comportamento del client che coincidono con l'inizio del problema.

Confronta campioni controllati senza confondere correlazione e causa

Seleziona campioni equivalenti e definisci in anticipo quale segnale confrontare: risposta all'invio, tempo prima di una risposta, arrivo di un callback o stato riportato. Evita di riunire in un'unica cifra eventi che si verificano in fasi diverse. Una differenza osservata tra due segmenti aiuta a formulare ipotesi, ma non stabilisce da sola un rapporto causale.

Quando è sicuro e autorizzato, esegui confronti circoscritti con traffico legittimo e consentito. Non modificare contemporaneamente più variabili: se cambi rotta, mittente e configurazione insieme, sarà più difficile capire cosa abbia modificato il risultato. Coordina i test con i responsabili pertinenti ed evita di generare traffico aggiuntivo non necessario.

• Definisci il gruppo interessato, un gruppo di confronto e il periodo prima di esaminare i risultati.
• Tieni sotto controllo destinazione, mittente, tipo di messaggio, configurazione e condizioni di invio pertinenti.
• Separa le misure di accettazione da quelle di consegna e dichiara i dati mancanti.
• Ripeti il confronto in un altro intervallo se il volume o la composizione del campione possono spiegare la differenza.

Interpreta i DLR in base all'origine e alla portata

Un DLR è un segnale il cui significato dipende da chi lo emette e da come è definito nell'integrazione. Nelle specifiche 3GPP, un rapporto del Service Centre conferma la ricezione da parte del centro, non necessariamente da parte del terminale; un rapporto emesso dalla stazione mobile conferma la ricezione da parte del terminale, non che l'utente abbia letto il messaggio. Prima di usarlo come prova, verifica l'origine del rapporto e lo stato che rappresenta.

Un SMS-STATUS-REPORT informa sullo stato dell'invio, ma non equivale automaticamente a una conferma di ricezione da parte di una persona. Inoltre, può esserci una differenza tra ciò che un'interfaccia chiama «consegnato» e l'evento tecnico che sostiene tale stato. Se l'emittente del DLR o il suo significato non sono chiari, documenta l'incertezza e chiedi chiarimenti al fornitore.

• Correla il rapporto con l'identificativo del messaggio originale e conserva il timestamp.
• Chiedi quale entità genera lo stato, quale evento conferma e quali stati di errore può rappresentare.
• Distingui tra assenza di DLR, ritardo del rapporto e stato di errore; non considerarli equivalenti.
• Non usare un DLR isolato per attribuire il problema alla rete mobile, al fornitore o al terminale.

Albero decisionale per isolare il problema e inoltrarlo

Applica la diagnosi in ordine, dalla prima fase osservabile fino al risultato successivo. Interrompi l'indagine nella prima fase per cui non sono disponibili prove e richiedi i log necessari; non passare da un sintomo d'integrazione a una conclusione sulla rete di destinazione.

Se il servizio è degradato, dai priorità a misure sicure e reversibili: riduci o sospendi il traffico interessato quando c'è il rischio di duplicazioni, abusi o impatti operativi, e segui la procedura concordata per cambiare rotta. Non dare per scontato che esista una rotta alternativa, che offra lo stesso comportamento o che sia autorizzata per quel traffico.

• Nessuna connessione HTTP o bind SMPP: raccogli orari, errori di trasporto, stato della sessione e modifiche recenti; inoltra il problema al team responsabile della connettività o dell'integrazione.
• La sessione è attiva, ma l'invio viene rifiutato: raggruppa codici e risposte. Verifica il formato e i limiti dell'interfaccia; inoltra esempi correlabili.
• Invio accettato, ma risultato assente: verifica i callback, i tempi di attesa e il significato del DLR. Chiedi al fornitore lo stato della fase successiva; l'accettazione non dimostra la consegna.
• I rapporti mostrano errori concentrati in un segmento: verifica che i campioni siano equivalenti e condividi lo schema con il fornitore e le parti di destinazione, senza dichiarare una causa finché non ci sono prove relative a quella fase.
• Risultati contraddittori o identificativi non correlabili: sospendi le conclusioni, controlla gli orologi, i riferimenti e i duplicati, quindi ricostruisci il percorso usando i log originali.

Documenta prove, incertezze e azioni

Un buon rapporto permette a un altro team di ripercorrere il ragionamento senza dare per scontata la causa. Separa fatti osservati, ipotesi e conclusioni; indica quali sistemi hanno fornito ciascun log e quale parte del percorso non è osservabile. Allega un campione piccolo e rappresentativo, proteggendo i dati, anziché limitarti a schermate aggregate prive di identificativi.

Gli standard definiscono limiti e segnali diversi per ogni fase: connessione, accettazione e rapporti di stato. La diagnosi deve tenerne conto e distinguere le osservazioni verificabili dalle ipotesi che richiedono ancora prove.

• Riassumi l'impatto, l'inizio e la fine noti, i segmenti interessati e non interessati e le modifiche recenti.
• Includi timestamp, identificativi, risposte originali e definizione di ogni stato analizzato.
• Etichetta ogni elemento come fatto, ipotesi, dato in sospeso o azione intrapresa.
• Indica chi deve fornire le prove successive e quando verrà riesaminata la diagnosi.