# Checklist per l'integrazione SMPP

- URL canonico: https://www.broadnet.me/it/guides/smpp-integration-checklist
- Lingua: it
- Editore: BroadNet (https://www.broadnet.me)
- Versione Markdown della pagina, generata dalla pagina pubblicata.

Protocolli e API Checklist gratuita

Una checklist operativa per integrare SMPP v3.4/v5.0: tipi di bind, TLV opzionali, gestione delle ricevute di consegna, keepalive enquire_link, throttling, TLS e un piano di test pre-produzione.

33 punti di controllo 5 min di lettura Aggiornato il 14 luglio 2026

Inviami il PDF

Per sviluppatori e ingegneri di messaggistica che collegano un nuovo bind SMPP.

Cosa contiene

1. 01Configurazione della sessione e del bind
2. 02Invio dei messaggi (submit_sm)
3. 03Parametri opzionali (TLV) da valutare
4. 04Gestione delle ricevute di consegna (DLR)
5. 05Keepalive e controllo di flusso
6. 06Sicurezza del trasporto (TLS)
7. 07Piano di test pre-produzione

[Sfoglia tutte le guide](https://www.broadnet.me/it/guides)

In breve

L'SMPP (Short Message Peer-to-Peer) è il protocollo binario che la maggior parte di aggregatori e operatori espone per la messaggistica A2P ad alto throughput. Un'integrazione pulita riguarda meno la scrittura di PDU e più il fatto di ottenere corretti i dettagli operativi: scegliere la modalità di bind corretta, rispettare i limiti di finestra e throttle, analizzare in modo affidabile le ricevute di consegna, mantenere attiva la sessione e proteggere il trasporto. Lavori dall'alto verso il basso — ogni gruppo è un checkpoint che può convalidare prima di promuovere un bind in produzione.

La checklist

## Procedi punto per punto e spunta man mano.

Diagramma Una sessione SMPP tra la vostra piattaforma e BroadNet

La vostra piattaforma (ESME)

BroadNet SMSC

Una connessione TCP/TLS persistente

1. `bind_transceiver` Aprire e autenticare la sessione
2. `bind_transceiver_resp` Sessione accettata
3. `submit_sm` Inviare un messaggio
4. `submit_sm_resp` Accettato, ID messaggio restituito
5. `deliver_sm` Ricevuta di consegna o messaggio in entrata
6. `deliver_sm_resp` Confermato
7. `enquire_link` Keepalive durante l'inattività

01

### Configurazione della sessione e del bind

Scelga la modalità di bind corretta per la direzione del suo traffico e confermi la versione di protocollo negoziata prima di inviare anche un solo messaggio.

- Confermi la versione SMPP — v3.4 per la maggior parte delle rotte, v5.0 dove il provider supporta lo stato di congestione e i TLV avanzati. La v5.0 è retrocompatibile; non presuma che le funzioni siano disponibili finché il bind_resp non lo conferma.
- Scelga il tipo di bind corretto per ogni sessione. transmitter (solo MT), receiver (solo DLR/MO), oppure transceiver (entrambi su un'unica sessione). Preferisca il transceiver per dimezzare il numero di connessioni dove il provider lo consente.
- Imposti system_id, password, system_type e address_range esattamente come previsto. Un address_range non corrispondente blocca silenziosamente l'instradamento di MO/DLR sui bind receiver.
- Concordi per iscritto con il provider il numero di bind concorrenti e il TPS per bind. Aprire più bind di quanto previsto è la causa più comune di un account rallentato o disconnesso.
- Gestisca esplicitamente i codici di stato di bind_resp — riprovi su ESME_RALYBND e rallenti su ESME_RBINDFAIL. Non ripeta mai in loop stretto un bind fallito; usi un backoff esponenziale con jitter.

02

### Invio dei messaggi (submit_sm)

- Imposti correttamente source_addr_ton / source_addr_npi e dest_addr_ton / dest_addr_npi per sender ID alfanumerici o numerici. Sender alfanumerico → TON 5 (alfanumerico); MSISDN internazionale → TON 1, NPI 1.
- Scelga il data_coding corretto: GSM a 7 bit (0), 8 bit (4), oppure UCS-2 (8) per Unicode. Mescolare le codifiche senza impostare data_coding causa mojibake e segmentazione errata.
- Implementi la concatenazione dei messaggi lunghi tramite UDH oppure i TLV opzionali SAR (sar_msg_ref_num, sar_total_segments, sar_segment_seqnum). Scelga un metodo e vi rimanga coerente; alcune rotte rifiutano l'UDH, altre rifiutano i TLV SAR.
- Richieda le ricevute di consegna con registered_delivery = 1 solo dove le utilizza effettivamente. Richiedere DLR che non vengono analizzati spreca throughput e può innescare avvisi lato provider.
- Rispetti la semantica di validity_period e schedule_delivery_time per il suo caso d'uso (OTP = validità breve). Gli OTP di breve durata dovrebbero avere un validity_period stretto, così che i messaggi non consegnati in tempo non arrivino in ritardo.

03

### Parametri opzionali (TLV) da valutare

- message_payload — per payload che superano il limite del campo short_message. Non valorizzi contemporaneamente short_message e message_payload; i provider lo rifiutano.
- TLV sar_* — concatenazione basata su standard senza byte UDH nel corpo del messaggio.
- dest_addr_subunit / source_addr_subunit — dove la rotta lo richiede per l'instradamento verso il telefono.
- Trasporti i metadati forniti dal cliente solo in TLV approvati dal provider. I TLV personalizzati al di fuori dell'intervallo concordato vengono comunemente rimossi o causano errori di parsing a valle.

04

### Gestione delle ricevute di consegna (DLR)

Le ricevute di consegna arrivano come PDU deliver_sm e sono la spina dorsale della riconciliazione e del reporting sulla qualità.

- Analizzi la ricevuta dal campo short_message di deliver_sm: id, sub, dlvrd, data di invio, data di completamento, stat, err. Il campo `stat` (DELIVRD, UNDELIV, EXPIRED, REJECTD, ecc.) è il suo stato finale.
- Correli i DLR al proprio invio usando il formato del 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 — normalizzi entrambi.
- Tratti le ricevute intermedie (non finali) separatamente dagli stati finali. Il bit 0x04 di esm_class contrassegna una ricevuta di consegna; solo i valori `stat` finali dovrebbero chiudere un messaggio.
- Restituisca sempre un deliver_sm_resp — un DLR non riconosciuto viene reinviato e può bloccare la finestra. Risponda tempestivamente anche se l'elaborazione a valle è asincrona.
- Mappi i codici di errore dell'operatore su una tassonomia normalizzata (abbonato assente, telefono occupato, bloccato come spam, numero non valido). I codici di errore grezzi variano da rotta a rotta; una tassonomia normalizzata rende confrontabile la qualità tra rotte diverse.

05

### Keepalive e controllo di flusso

- Invii enquire_link su un timer di inattività (comunemente 30–60s) e tratti un enquire_link_resp mancato come sessione morta. È l'unico modo affidabile per rilevare una connessione TCP semiaperta.
- Implementi la finestra SMPP: limiti i PDU in attesa di conferma e sospenda gli invii quando la finestra è piena. Inviare submit_sm oltre la finestra senza controllo è ciò che innesca ESME_RTHROTTLED.
- Rallenti su ESME_RTHROTTLED (0x58) anziché ritentare immediatamente. Aggiunga jitter così che le tempeste di riconnessione non si sincronizzino tra i worker.
- Rispetti unbind / unbind_resp per un arresto controllato; si riconnetta con backoff in caso di disconnessioni impreviste.

06

### Sicurezza del trasporto (TLS)

- Usi SMPP su TLS dove il provider lo offre; disabiliti i bind in chiaro in produzione. L'SMPP non ha cifratura nativa — il TLS è il controllo a livello di trasporto.
- Ancori o validi la catena di certificati del server e imponga TLS 1.2+. Rifiuti certificati scaduti o autofirmati; non disabiliti la verifica 'per farlo funzionare'.
- Limiti i bind a IP di origine inseriti in una lista consentita su entrambi i lati. L'allow-listing degli IP è un controllo operatore standard e un modo rapido per contenere fughe di credenziali.
- Ruoti le credenziali SMPP secondo un piano e le conservi in un secret manager, mai nel codice.

07

### Piano di test pre-produzione

- Invii a un MSISDN di test reale su ciascuna rotta target e confermi la ricezione end-to-end sul telefono.
- Verifichi il round-trip del DLR per gli esiti consegnato, non consegnato, scaduto e respinto.
- Testi messaggi lunghi (multi-segmento) e contenuti Unicode (UCS-2) su ciascuna rotta.
- Esegua un test di carico al TPS previsto e confermi un comportamento controllato al limite di finestra/throttle.
- Simuli una disconnessione a metà finestra e confermi una riconnessione pulita senza invii duplicati. L'idempotenza sul retry previene la doppia fatturazione e la consegna duplicata al telefono.
- Confermi il monitoraggio: stato del bind, occupazione della finestra, latenza submit/DLR e tassi di codici di errore generano tutti degli avvisi.

Riferimenti

- [Specifica SMPP v3.4](https://smpp.org/SMPP_v3_4_Issue1_2.pdf)
- [Specifica SMPP v5.0](https://smpp.org/SMPP_v5.pdf)
- [3GPP TS 23.040 — Realizzazione tecnica dell'SMS](https://www.3gpp.org/dynareport/23040.htm)

Standard e riferimenti normativi citati in questa guida. BroadNet è membro associato della GSMA e membro del MEF e gestisce messaggistica di livello carrier dal 2003.

Related

- [Consultazione codici di errore SMPP (strumento gratuito)](https://www.broadnet.me/it/tools/smpp-error-codes)
- [Decodificatore DLR (strumento gratuito)](https://www.broadnet.me/it/tools/dlr-decoder)
- [Cos'è l'SMPP?](https://www.broadnet.me/it/answers/what-is-smpp)
- [Protocollo SMPP — approfondimento](https://www.broadnet.me/it/answers/smpp-protocol)
- [Documentazione per sviluppatori](https://www.broadnet.me/it/developers)

Conservane una copia

## La vuoi in un PDF da condividere?

Ricevila nella tua casella per condividerla con il team: niente spam, una sola email.

Inviami il PDF

Ottieni il PDF

## Inviami «SMPP Integration Checklist» via email.

Ti invieremo un PDF pulito e stampabile di questa checklist da condividere con il tuo team o conservare per la tua RFP. Un ingegnere di messaggistica ti ricontatterà solo se lo chiedi: niente spam commerciale.

- PDF stampabile, una pagina per sezione
- Tutto il contenuto di questa pagina, pronto da condividere
- Facoltativo: una chiamata con un ingegnere BroadNet

Preferisci non condividere la tua email? Usa Stampa / salva come PDF qui sopra: la checklist completa è in questa pagina.

Linea diretta · risposta entro un giorno lavorativo

## Inviami «SMPP Integration Checklist»

Dicci dove inviarlo. Ti invieremo il PDF via email e ti ricontatteremo solo se lo chiedi.

1. 1 Chi
2. 2 Esigenza
3. 3 Contesto
