Fondamenti di SMPP

SMPP — Short Message Peer-to-Peer — è il protocollo binario e basato su sessione che aggregatori e operatori espongono per la messaggistica A2P ad alto throughput. Mentre un'API REST è comoda e stateless, l'SMPP è una connessione TCP persistente costruita per volume e bassa latenza.

Un ESME (External Short Messaging Entity — la sua parte) apre una sessione verso l'SMSC e scambia PDU (Protocol Data Unit). Il protocollo è compatto ed efficiente, ed è per questo che resta la spina dorsale per i grandi mittenti anche mentre il REST copre l'uso quotidiano.

La versione più diffusa è l'SMPP v3.4; la v5.0 aggiunge la segnalazione dello stato di congestione e parametri avanzati, ma è retrocompatibile. Non dovrebbe mai presumere che una funzione della v5.0 sia disponibile finché la risposta al bind non conferma la versione negoziata.

Prima di inviare qualsiasi cosa, un ESME deve effettuare il bind — autenticarsi e dichiarare un ruolo. Un bind transmitter invia solo messaggi; un bind receiver riceve solo messaggi mobile-originated e ricevute di consegna; un bind transceiver fa entrambe le cose su un'unica connessione.

Il transceiver è di solito preferito perché dimezza il numero di connessioni e semplifica la correlazione tra DLR e invii. Il numero di bind concorrenti e i messaggi al secondo per bind (TPS) sono forniti dal provider e vanno rispettati.

Il bind trasporta un system_id, una password, un system_type e un address_range. Un address_range non corrispondente interrompe silenziosamente l'instradamento di MO e DLR sui bind receiver — un classico bug di integrazione che non produce errori, solo traffico mancante.

Ogni interazione SMPP è un PDU con un'intestazione di comando (lunghezza, command id, status, numero di sequenza) e un corpo. Il fulcro è submit_sm, che trasporta un singolo messaggio in uscita.

Due coppie di campi decidono l'indirizzamento: source_addr con il proprio TON/NPI (type-of-number / numbering-plan-indicator) e dest_addr con il proprio. Un sender ID alfanumerico usa TON 5; un MSISDN internazionale usa TON 1, NPI 1. Se questi valori sono sbagliati, il sender ID viene visualizzato in modo errato oppure il messaggio viene respinto.

Il campo data_coding imposta la codifica — GSM a 7 bit (0), 8 bit (4), oppure UCS-2 (8) per Unicode. I messaggi lunghi vengono concatenati sia con byte UDH nel corpo, sia con i parametri opzionali SAR (sar_msg_ref_num, sar_total_segments, sar_segment_seqnum); scelga un metodo e vi rimanga coerente, perché le rotte differiscono su quale accettano.

L'SMPP utilizza una finestra di trasmissione: un limite al numero di PDU submit_sm inviati prima che arrivino le rispettive risposte. Superare la finestra, o il TPS previsto, genera ESME_RTHROTTLED (0x58). La risposta corretta è rallentare con jitter, non ripetere i tentativi in loop stretto.

Per rilevare una connessione TCP semiaperta, ciascuna parte invia enquire_link su un timer di inattività (comunemente ogni 30–60 secondi) e si attende un enquire_link_resp. Una risposta mancata significa che la sessione è morta e va ristabilita con backoff esponenziale.

L'arresto controllato usa unbind / unbind_resp. Le disconnessioni impreviste dovrebbero attivare una riconnessione con backoff e ritentativi idempotenti, così che una finestra interrotta non causi invii duplicati e doppia fatturazione.

Le ricevute di consegna arrivano come PDU deliver_sm. Il testo della ricevuta nel campo short_message contiene id, sub, dlvrd, data di invio, data di completamento, lo stat finale (DELIVRD, UNDELIV, EXPIRED, REJECTD) e un codice err.

Correli il DLR al proprio invio originale usando il message_id del provider, non solo il testo della ricevuta — il message_id può essere restituito in esadecimale su submit_resp ma in decimale nel DLR, quindi normalizzi entrambi i formati.

Risponda sempre con un deliver_sm_resp. Un DLR non riconosciuto viene reinviato dall'SMSC e può bloccare la finestra di ricezione, quindi confermi tempestivamente anche se l'elaborazione a valle è asincrona.