SMPP: la guida completa al protocollo.

Cos'è SMPP e dove si colloca

Una sessione SMPP ha sempre due ruoli. ESME (External Short Messaging Entity) è la tua applicazione: una piattaforma per SMS di massa, un servizio OTP, un sistema di allerta. L' SMSC (Centro servizi messaggi brevi), chiamato un MC Il Centro Messaggi (Message Centre), nella versione 5.0, è il nodo operatore o aggregatore che memorizza e inoltra i messaggi da e verso i dispositivi mobili sulla rete mobile. L'ESME si connette all'SMSC; l'SMSC si connette alla rete SS7/mobile core più ampia.

SMPP è la spina dorsale di A2P (Messaggistica da applicazione a persona) — codici di verifica, ricevute, avvisi, marketing — in contrapposizione a P2P Scambio di messaggi (da persona a persona) tra due dispositivi mobili. Il traffico A2P è caratterizzato da un elevato volume di messaggi, generati automaticamente e basati sulla conferma di ricezione, esattamente ciò per cui SMPP è stato progettato.

Perché un protocollo TCP binario invece di HTTP? Una singola connessione SMPP è un socket di lunga durata. Una volta aperta, si evita l'handshake TCP e TLS per ogni messaggio, è possibile avere molti messaggi in transito contemporaneamente (finestra asincrona) e l'SMSC invia le conferme di consegna e i messaggi in entrata direttamente sulla stessa connessione. Con un throughput elevato e costante, questo è notevolmente più efficiente di un'API HTTP richiesta/risposta, motivo per cui gli operatori e i grandi mittenti lo adottano come standard.

Cronologia delle versioni

• SMPP v3.3 — la prima versione ampiamente diffusa; ha introdotto il set di PDU principali, ma è precedente ai TLV (parametri opzionali) e al binding del transceiver.
• SMPP v3.4 — la versione dominante attualmente in produzione. Aggiunte le funzionalità di associazione del transceiver, i parametri TLV opzionali, message_payload e data_sm. Quasi tutte le integrazioni reali che realizzerete utilizzano la versione 3.4.
• SMPP v5.0 — la versione più recente. Rinomina SMSC in MC, aggiunge PDU broadcast (broadcast_sm), segnalazione dello stato di congestione e TLV più standardizzati. L'adozione è limitata; si consiglia di supportare prima la v3.4 e di considerare la v5.0 come opzionale.

Architettura e tipi di collegamento

La topologia è semplice: l'ESME apre una connessione TCP all'SMSC/MC e si autentica con un system_id E passwordLa direzione in cui la sessione può trasportare il traffico viene fissata al momento del binding scegliendo una delle tre opzioni. modalità di collegamentoOgni modalità corrisponde a una diversa PDU di binding.

Un quarto attore è percorsoL'SMSC decide, per ogni messaggio, quale percorso o interconnessione con l'operatore di destinazione segue il messaggio inviato verso il dispositivo di destinazione, e a quale ESME associato appartiene il messaggio in entrata (originato dal dispositivo mobile).

Sul cavo, SMPP funziona su TCP. La porta predefinita registrata presso IANA è 2775 per connessioni semplici. SMPPS — SMPP incapsulato in TLS — non ha una porta standard univoca; i provider lo espongono su una porta a loro scelta (in pratica si utilizzano le porte 3550, 8775 e 2776). Utilizzare sempre la porta crittografata assegnata dal provider per gli ambienti di produzione.

Il ciclo di vita della sessione

Ogni sessione SMPP segue lo stesso schema: apertura TCP, associazione, mantenimento della connessione, scambio di messaggi e ricevute, quindi disassociazione e chiusura. Il diagramma seguente illustra una sessione completa di un transceiver: ogni riga rappresenta una PDU, il blu indica il flusso dalla ESME all'SMSC, il verde il flusso di ritorno.

Due dettagli importanti. Primo, submit_sm_resp restituisce immediatamente e significa solo "accettato per la consegna" — il risultato reale arriva più tardi come deliver_sm ricevuta. In secondo luogo, ogni richiesta PDU ha una corrispondenza _resp che riecheggia il suo sequence_number, ed è così che le risposte asincrone vengono correlate alle richieste.

Anatomia della PDU

Tutto ciò che si trova su una connessione SMPP è un PDUOgni PDU inizia con un valore fisso Intestazione di 16 byte di quattro interi a 4 byte (32 bit, big-endian), seguiti da un corpo specifico del comando. Leggi prima l'intestazione e saprai esattamente come leggere il resto.

Il corpo termina con un numero qualsiasi di TLV — parametri opzionali codificati come Tag (2 byte), Lunghezza (2 byte), Valore (Lunghezza byte). I TLV sono il modo in cui la versione 3.4 ha esteso il protocollo senza compromettere le versioni precedenti: message_payload, receipted_message_id, i campi di concatenazione sar_* e molti altri vengono utilizzati come TLV.

IL numero_sequenza è la chiave per la gestione delle finestre. Poiché SMPP è asincrono, un ESME può inviare molte PDU submit_sm — ciascuna con un sequence_number incrementale — prima che arrivino le risposte. Quando le PDU submit_sm_resp tornano, il loro sequence_number indica a quale invio corrisponde ciascuna. Il numero di PDU non confermate consentite in transito è il dimensione della finestra

Riferimento PDU principali

Queste sono le operazioni che utilizzerete effettivamente. Ogni richiesta ha una PDU di risposta il cui command_id è l'ID della richiesta con il bit più significativo impostato (0x80000000), quindi submit_sm 0x00000004 corrisponde a submit_sm_resp 0x80000004.

submit_sm campo per campo

submit_sm è la PDU che invierai più frequentemente. Il suo corpo è una sequenza di parametri obbligatori, seguiti da TLV opzionali. Questi sono i campi che contano nella pratica.

Codifica e concatenazione dei dati

IL data_coding Il campo (lo schema di codifica dei dati, DCS) indica al telefono come interpretare i byte e decide quanti caratteri possono essere contenuti in un SMS.

Un messaggio più lungo di un segmento viene diviso e riassemblato sul telefono utilizzando un UDH (User Data Header) anteposto a ciascuna parte. L'elemento di concatenazione utilizza IEI 0x00 (Riferimento a 8 bit) — un'intestazione di 6 ottetti contenente un numero di riferimento, il numero totale di componenti e l'indice di questo componente. Questi 6 ottetti sono il motivo per cui i limiti per componente si riducono a 153 (GSM a 7 bit) e 67 (UCS-2). Quando si invia un UDH all'interno di short_message, è necessario impostare anche il bit UDHI (0x40) in esm_class.

Esistono due modi per inviare contenuti lunghi: creare autonomamente le parti segmentate UDH (ciascuna un submit_sm con UDHI impostato), oppure consegnare l'intero corpo all'SMSC nel message_payload TLV e lascia che si segmenti. Alcuni SMSC, invece, accettano i TLV sar_msg_ref_num / sar_total_segments / sar_segment_seqnum per descrivere la concatenazione senza un UDH.

Ricevute di consegna (DLR)

Quando imposti registered_delivery = 1, l'SMSC in seguito comunica l'esito del messaggio inviandoti un deliver_sm con il bit di ricevuta di consegna impostato in esm_class (0x04Il testo della ricevuta è presente nel campo short_message come stringa di parole chiave predefinita:

id:1a2b3c4d5e sub:001 dlvrd:001 submit date:2607251432 done date:2607251432 stat:DELIVRD err:000 text:Your code is 8

IL id corrisponde al message_id che hai ricevuto in risposta in submit_sm_resp (e anche nel TLV receipted_message_id 0x001E). stat Il campo contiene lo stato finale:

Rispondi sempre a deliver_sm con un deliver_sm_respIn caso contrario, l'SMSC invierà nuovamente la ricevuta e potrebbe limitare la velocità o interrompere la connessione. Si noti che la formattazione della ricevuta non è perfettamente standardizzata: i provider variano leggermente nell'ordine dei campi e nella mappatura dei codici di errore.

Codici di errore/stato del comando

Ogni PDU di risposta contiene un command_status nella sua intestazione — un ESME_R* Codice. Zero significa successo; qualsiasi altro valore indica il motivo del rifiuto della richiesta. Questi sono i codici che incontrerai più frequentemente.

Il registro completo, comprese le gamme di fornitori specifiche per ciascun provider, è consultabile nel Riferimento ai codici di errore SMPP

Throughput, finestratura e limitazione

La velocità di trasmissione in SMPP è misurata in TPS — transazioni (submit_sm) al secondo — ed è regolato da due fattori: la velocità consentita dall'SMSC e il numero di messaggi che mantieni in transito. Poiché SMPP è asincrono, non è necessario attendere ogni submit_sm_resp prima di inviare la PDU successiva. Il numero di invii non confermati che consenti contemporaneamente è il tuo dimensione della finestra (generalmente 10-100). Una finestra più ampia nasconde la latenza di andata e ritorno e aumenta il TPS effettivo, fino al limite massimo dell'SMSC.

• Rispetta l'acceleratore. Quando l'SMSC restituisce ESME_RTHROTTLED (0x58), fai un passo indietro: metti in pausa e riprova con un backoff esponenziale invece di insistere con il bind, che potrebbe causare la disconnessione.
• Mantieniti in vita con una cadenza regolare. Invia il link di richiesta all'incirca ogni 30 secondi quando il server è inattivo; se alcuni messaggi rimangono senza risposta, si presume che il link non funzioni.
• Riconnettiti intenzionalmente. In caso di disconnessione, riconnettersi e riassociare con backoff e jitter; non utilizzare il tight-loop. Monitorare i numeri di sequenza in sospeso per poter riconciliare le ricevute dopo una riconnessione.
• Scalare con i vincoli, con attenzione. Un TPS aggregato più elevato deriva solitamente da più connessioni, ma solo fino al limite autorizzato dal provider per ciascun account.

Esempio di codice

Un esempio illustrativo del flusso di connessione → associazione → invio in pseudocodice in stile Node.js. Le librerie SMPP reali (ad esempio, node-smpp, jSMPP per Java o python-smpplib) gestiscono automaticamente la codifica PDU; questo esempio mostra la struttura della sessione, non l'API di una libreria specifica.

import smpp from "smpp";

// 1. Open a TCP (or TLS) session to the SMSC.
const session = smpp.connect({
  // Host, port and bind credentials come with your test access.
  // Plain SMPP conventionally uses 2775; the TLS port is provided with your account.
  url: process.env.SMPP_URL!,             // e.g. smpp://<host>:2775 (plain) or smpps://<host>:<tls-port>
  auto_enquire_link_period: 30000,        // keepalive every 30s
});

// 2. Bind as a transceiver.
session.bind_transceiver(
  {
    system_id: "YOUR_SYSTEM_ID",
    password:  "YOUR_PASSWORD",
    system_type: "",
  },
  (pdu) => {
    if (pdu.command_status !== 0) {
      throw new Error("bind failed: 0x" + pdu.command_status.toString(16));
    }

    // 3. Submit a Unicode message, asking for a delivery receipt.
    session.submit_sm(
      {
        source_addr_ton: 5,                // alphanumeric Sender ID
        source_addr:      "BroadNet",
        dest_addr_ton:    1,               // international E.164
        destination_addr: "447700900123",
        registered_delivery: 1,            // request a DLR
        data_coding: 8,                    // UCS-2 (Unicode)
        short_message: "Your code is 8123",
      },
      (submitResp) => {
        // submit_sm_resp returns the SMSC message_id.
        console.log("accepted, message_id =", submitResp.message_id);
      }
    );
  }
);

// 4. Receive delivery receipts on the same session.
session.on("deliver_sm", (pdu) => {
  if ((pdu.esm_class & 0x04) === 0x04) {   // delivery-receipt bit
    console.log("DLR:", pdu.short_message.message);
  }
  session.send(pdu.response());            // ALWAYS deliver_sm_resp
});

BroadNet SMPP

BroadNet gestisce un gateway SMSC di livello carrier che accetta connessioni SMPP v3.4 su TLS. Offre: connessione transceiver, elevato numero di transazioni al secondo (TPS) con finestra asincrona, conferme di consegna complete, supporto Unicode e concatenazione, e una connessione con credenziali e accesso IP consentito per raggiungere operatori in tutto il mondo. Si tratta dello stesso protocollo descritto in questa pagina, ma applicato a percorsi reali.

Domande frequenti

Strumenti e documenti correlati