Riferimento al protocollo di messaggistica.
Un riferimento preciso e basato su standard per i protocolli che trasportano gli SMS, scritto per gli ingegneri che li realizzano. Fondato sulle specifiche SMPP v3.4/v5.0 e 3GPP TS 23.038/23.040, con layout di byte reali, tabelle dei campi ed esempi di formato di trasmissione.
65 documenti su 9 protocolli
SMPP
Il protocollo Short Message Peer-to-Peer (SMTP) è un protocollo di sessione binario che i gestori e gli aggregatori mettono a disposizione per la messaggistica A2P ad alta velocità.
- Fondamenti
Panoramica del protocollo SMPP
Che cos'è SMPP, come funziona la sessione ESME↔SMSC, la differenza tra v3.4 e v5.0 e perché resta lo standard per SMS A2P ad alto throughput.
- Formato di trasmissione
Anatomia della PDU SMPP: header e body
Il layout esatto in byte di una PDU SMPP: l'header di 16 byte (command_length, command_id, command_status, sequence_number), il body e come sono codificati i campi.
- Sessione
Operazioni di bind e stati della sessione SMPP
Come si autentica una sessione SMPP: bind_transmitter, bind_receiver e bind_transceiver, i campi system_id/password/system_type, interface_version, gli stati della sessione e l'unbind.
- Operazioni
SMPP submit_sm: ogni campo obbligatorio
Un riferimento completo campo per campo di submit_sm — service_type, TON/NPI, esm_class, data_coding, registered_delivery, validity_period, short_message e gli altri — con i valori che contano davvero.
- Operazioni
SMPP deliver_sm: messaggi MO e ricevute
deliver_sm trasporta due cose dall'SMSC all'ESME: messaggi mobile-originated (MO) e ricevute di consegna. Come distinguerli con esm_class e perché occorre sempre rispondere con deliver_sm_resp.
- Errori
Codici di errore command_status di SMPP
Il campo command_status di SMPP e l'intervallo di errori ESME_R*: cosa significano i codici comuni (ESME_RINVPASWD, ESME_RTHROTTLED, ESME_RMSGQFUL…) e come reagire a ciascuno.
- Formato di trasmissione
Parametri opzionali TLV di SMPP
I parametri opzionali di SMPP usano un formato Tag-Length-Value. Il layout in byte del TLV più i tag comuni: message_payload, receipted_message_id, message_state, user_message_reference e l'insieme sar_* per la concatenazione.
- Operazioni
Formato delle ricevute di consegna SMPP (DLR)
Il formato testuale della ricevuta di consegna dell'Appendice B all'interno di deliver_sm: id, sub, dlvrd, submit date, done date, stat, err e Text — più le parole chiave stat e i relativi numeri message_state.
- Sessione
SMPP enquire_link, windowing e throttling
Come SMPP mantiene attiva una sessione con enquire_link, come la finestra limita le PDU non riscontrate in sospeso e come ESME_RTHROTTLED e il TPS per bind governano il throughput reale.
- Sicurezza
Protezione di SMPP: TLS, autenticazione e allow-list degli IP
SMPP non prevede cifratura nativa. Come proteggere un bind in produzione: SMPP su TLS, autenticazione basata su credenziali e IP, allow-list e igiene delle credenziali.
- Fondamenti
SMPP v3.4 vs v5.0: cosa è cambiato
Le differenze pratiche tra SMPP v3.4 e v5.0: controllo della congestione, operazioni di broadcast, stati del messaggio aggiuntivi e TLV — e perché la v3.4 resta l'interconnessione predefinita.
- Integrazione
Best practice di integrazione SMPP
Come costruire un'integrazione SMPP che resti affidabile in produzione: strategia di bind, disciplina del sequence_number, windowing, retry con backoff, idempotenza, gestione dei DLR e riconnessione.
Codifica SMS
Come viene codificato il testo degli SMS sulla rete: GSM a 7 bit, UCS-2, schemi di codifica dei dati, segmentazione e implicazioni di costo per ogni carattere.
- Set di caratteri
Il set di caratteri GSM-7
L'alfabeto predefinito GSM a 7 bit di GSM 03.38: la tabella base di 128 caratteri, la tabella di estensione basata su escape (| ^ € { } [ ] ~ \ e form-feed) e come funziona il packing a 7 bit.
- Set di caratteri
UCS-2 e SMS Unicode
Come gli SMS trasportano Unicode tramite UCS-2 (a 16 bit): il limite di 70 caratteri per singolo messaggio, 67 per segmento concatenato, cosa impone UCS-2 e l'insidia delle coppie surrogate per le emoji.
- Codifica dati
Il data coding scheme (DCS)
Il byte data-coding scheme che indica alla rete come è codificato un SMS: GSM-7 (0x00), 8-bit (0x04), UCS-2 (0x08), più le classi di messaggio (0/flash fino a 3/SIM) di GSM 03.38.
- Segmentazione
Segmentazione SMS, concatenazione e l'UDH
Come i messaggi SMS lunghi vengono suddivisi e riassemblati: l'User Data Header di 6 byte, i risultanti 153 (GSM-7) e 67 (UCS-2) caratteri per segmento, il numero di riferimento e il sequenziamento dei segmenti.
- Costo
Rilevamento della codifica e costo degli SMS
Come rilevare se un testo è GSM-7 o UCS-2, quali caratteri impongono silenziosamente UCS-2 e come la codifica determina il numero di segmenti — e quindi il costo — di ogni SMS che inviate.
SS7 / MAP
Il sistema di segnalazione n. 7 e il livello MAP trasportano SMS con terminazione mobile, query HLR e gestione della mobilità attraverso le reti centrali preesistenti.
- Fondamenti
Panoramica dello stack SS7: MTP, SCCP, TCAP, MAP, ISUP
Come è stratificato lo stack SS7 — trasporto MTP1-3, indirizzamento SCCP, transazioni TCAP e le user part MAP e ISUP — e quale livello fa cosa per SMS, chiamate e mobilità.
- Trasporto
MTP: il Message Transfer Part (livelli 1-3)
I tre livelli MTP che trasportano SS7: i collegamenti fisici MTP1, il data link con controllo d'errore MTP2 (signal unit MSU/LSSU/FISU) e l'instradamento per point code MTP3 con load-sharing e gestione della rete.
- Indirizzamento
SCCP, Global Title Translation e subsystem number
Come SCCP estende MTP3 con l'indirizzamento a Global Title: il Called/Calling Party Address, la Global Title Translation (GTT), i subsystem number (HLR/VLR/MSC) e le classi connectionless vs connection-oriented.
- Transazioni
TCAP: transazioni, dialoghi e componenti
Come TCAP struttura gli scambi applicativi SS7: il transaction sublayer (Begin/Continue/End/Abort con transaction ID), la dialogue portion (application context) e il component sublayer (Invoke, ReturnResult, ReturnError, Reject).
- MAP
Operazioni MAP: SRI-SM, ForwardSM, UpdateLocation e altre
Le operazioni MAP che fanno funzionare le reti mobili: SendRoutingInfoForSM e MT-ForwardSM per gli SMS, UpdateLocation per il roaming, ProvideSubscriberInfo e AnyTimeInterrogation per la posizione — con i relativi opcode di TS 29.002.
- Consegna SMS
Flusso di consegna MT-SMS su SS7, passo per passo
L'intero percorso dell'SMS mobile-terminated su SS7: SMSC verso HLR con SendRoutingInfoForSM, HLR che restituisce IMSI + MSC servente, SMSC verso MSC con MT-ForwardSM, paging e consegna, e il retry per abbonato assente tramite MWD e AlertServiceCentre.
- Indirizzamento
Point code SS7 e indirizzamento di rete
Come SS7 indirizza i punti di segnalazione: point code ITU-T a 14 bit vs ANSI a 24 bit, la loro struttura zona/rete, l'etichetta di instradamento OPC/DPC/SLS e come i point code si rapportano ai Global Title SCCP.
- Sicurezza
Minacce alla sicurezza SS7 e le categorie GSMA FS.11
Le principali classi di attacco SS7 — tracciamento della posizione, intercettazione SMS/OTP, reindirizzamento delle chiamate e frode — e come GSMA FS.11 categorizza i messaggi MAP (categorie 1/2/3) affinché i firewall di segnalazione possano filtrarli.
- Fondamenti
SS7 vs SIGTRAN: segnalazione TDM su IP
Come SIGTRAN si rapporta all'SS7 classico: lo stesso livello applicativo MTP3/SCCP/TCAP/MAP, ma trasportato su IP con SCTP e M3UA (o SUA) invece dei collegamenti TDM MTP1/MTP2.
SIGTRAN
La segnalazione SS7 viene trasportata su IP — M3UA, SUA e SCTP — il ponte tra la segnalazione TDM e le moderne reti a pacchetto.
- Fondamenti
Panoramica di SIGTRAN: segnalazione SS7 su IP
Che cos'è SIGTRAN: il framework IETF (RFC 2719) per trasportare la segnalazione SS7 su IP, usando il trasporto SCTP e livelli di adattamento (M3UA, SUA, M2PA) che preservano lo stack applicativo MTP3/SCCP/TCAP/MAP.
- Trasporto
SCTP: Stream Control Transmission Protocol
Come funziona SCTP e perché SIGTRAN lo usa: consegna orientata ai messaggi, multi-streaming per evitare il head-of-line blocking, multi-homing per il failover di percorso, il formato dei pacchetti basato su chunk e in cosa differisce da TCP.
- Adattamento
M3UA: livello MTP3-User Adaptation
Come M3UA trasporta SCCP e ISUP su SCTP: i ruoli SG/ASP/AS, routing key e routing context, le classi di messaggio (Transfer, SSNM, ASPSM, ASPTM) e le modalità IPSP vs signalling-gateway.
- Adattamento
Livelli di adattamento M2PA e SUA
Altri due livelli di adattamento SIGTRAN: M2PA (RFC 4165) sostituisce MTP2 per costruire collegamenti STP su IP che eseguono MTP3 completo, e SUA (RFC 3868) trasporta le user part SCCP (TCAP/MAP) direttamente su SCTP, bypassando MTP3.
- Architettura
Architettura di deployment SIGTRAN: SG, ASP, AS
Come si costruisce una rete SIGTRAN: il signalling gateway che fa da ponte tra TDM e IP, gli application server e i loro processi, le associazioni SCTP e le modalità di ridondanza (override, load-share, broadcast) che garantiscono disponibilità di livello carrier.
SIP / VoIP
Il Session Initiation Protocol (SIP) alla base della voce programmabile, del trunking SIP e del controllo delle chiamate VoLTE, oltre allo stack multimediale che lo accompagna.
- Fondamenti
Panoramica del protocollo SIP
Che cos'è SIP e come funziona: un protocollo di segnalazione richiesta/risposta basato su testo (RFC 3261) che instaura, modifica e abbatte sessioni multimediali, i suoi user agent, proxy e registrar e le sue transazioni e dialoghi.
- Richieste
Metodi e richieste SIP
Ogni metodo di richiesta SIP e cosa fa: i sei metodi di base di RFC 3261 (INVITE, ACK, BYE, CANCEL, REGISTER, OPTIONS) e le estensioni comuni (INFO, PRACK, UPDATE, SUBSCRIBE/NOTIFY, REFER, MESSAGE, PUBLISH).
- Risposte
Codici di risposta SIP (1xx-6xx)
Le sei classi di codici di risposta SIP e quelli che contano: 1xx provvisorio (100 Trying, 180 Ringing), 2xx successo (200 OK), 3xx redirezione, 4xx errore del client (404, 486), 5xx errore del server e 6xx global failure.
- Messaggi
Header SIP: Via, From, To, Call-ID, CSeq, Contact
Gli header SIP essenziali e cosa fanno: Via (con il parametro branch) per instradare le risposte, From/To con i tag, Call-ID, CSeq, Contact, Max-Forwards, e come dialoghi e transazioni si identificano da essi.
- Media
SDP: il Session Description Protocol
Come SDP descrive una sessione multimediale all'interno di SIP: la struttura delle righe v=/o=/s=/c=/t=/m=/a=, il modello offer/answer (RFC 3264), la negoziazione dei codec tramite rtpmap e gli attributi di direzione dei media.
- Media
RTP e SRTP: il flusso media
Come fluiscono i media una volta che SIP ha instaurato una chiamata: l'header e il payload RTP, i report di qualità RTCP e la cifratura e autenticazione SRTP con keying tramite SDES o DTLS-SRTP.
- Flusso di chiamata
Flusso di chiamata SIP: da INVITE a BYE
Una chiamata SIP completa passo per passo: INVITE con offerta SDP, 100 Trying, 180 Ringing, 200 OK con risposta SDP, l'ACK a tre vie, i media RTP e l'abbattimento BYE/200 OK — più come CANCEL annulla una chiamata in squillo.
- Distribuzione
SIP trunking e il session border controller
Che cos'è un SIP trunk e il ruolo del session border controller (SBC): NAT traversal con STUN/TURN/ICE, topology hiding tramite B2BUA, sicurezza e controllo di ammissione al confine di rete e transcodifica.
DIAMETER
Il protocollo AAA e di segnalazione alla base della mobilità 4G/5G, delle politiche e della tariffazione (S6a, Gx, Gy), del controllo IMS (Cx / Sh) e della sicurezza del roaming Diameter ai margini IPX.
- Fondamenti
Protocollo di base DIAMETER: RFC 6733 spiegato
Come funziona il protocollo di base DIAMETER secondo RFC 6733: l'header del messaggio da 20 byte, i command code e i flag R/P/E/T, lo scambio di capacità CER/CEA, il watchdog DWR/DWA e la disconnessione DPR/DPA, su SCTP o TCP/TLS.
- Formato del messaggio
AVP DIAMETER, tipi di dato e Result-Code
L'anatomia di un AVP DIAMETER: code, flag V/M/P, length, Vendor-Id opzionale e dati; i tipi di dato di base (Enumerated, Unsigned32, OctetString, Address, Time); gli AVP Grouped; e il modello di errore Result-Code / Experimental-Result.
- Fondamenti
DIAMETER vs RADIUS: perché DIAMETER ha sostituito RADIUS
Perché DIAMETER (RFC 6733) ha soppiantato RADIUS (RFC 2865) per l'AAA di operatore: trasporto affidabile SCTP e failover, negoziazione delle capacità, uno spazio AVP a 32 bit molto più ampio, scoperta dei peer, gestione degli errori più ricca e sicurezza più forte — con una tabella di confronto e note di migrazione.
- Mobilità (HSS)
DIAMETER S6a/S6d: mobilità LTE verso l'HSS
Come la mobilità LTE e la gestione della sottoscrizione girano su DIAMETER S6a (MME↔HSS) e S6d (SGSN↔HSS) secondo 3GPP TS 29.272: ULR/ULA, AIR/AIA, CLR/CLA, PUR/PUA e IDR/IDA, vettori di autenticazione EPS-AKA e le operazioni SS7 MAP che sostituiscono.
- Policy e charging
DIAMETER Gx e Gy: controllo di policy e charging
Come DIAMETER trasporta il Policy and Charging Control: Gx (PCEF↔PCRF, CCR/CCA che installa regole PCC), Gy (charging online verso l'OCS con quota) e Rf (charging offline verso il CDF) — oltre ai ruoli PCRF/PCEF/OCS/OFCS, QoS/QCI e le interfacce Sy/Sd.
- IMS
DIAMETER Cx/Dx e Sh: registrazione IMS e l'HSS
Come la registrazione e l'autenticazione IMS girano su DIAMETER Cx/Dx (S-CSCF/I-CSCF↔HSS) secondo 3GPP TS 29.228/29.229 — UAR/UAA, MAR/MAA, SAR/SAA, LIR/LIA — più l'interfaccia Sh (AS↔HSS) e come queste si legano a SIP REGISTER.
- Sicurezza
Sicurezza del roaming DIAMETER: DRA, DEA e il bordo IPX
Come funzionano l'instradamento DIAMETER e la sicurezza di interconnessione al bordo del roaming: il Diameter Routing Agent (DRA) e il Diameter Edge Agent (DEA), l'instradamento per realm, le classi di minaccia FS.19 (divulgazione di informazioni, tracciamento della posizione, frode), il topology hiding e il filtraggio degli AVP.
Canali di messaggistica
I canali di messaggistica a livello applicativo utilizzati dalle aziende sono: RCS Business Messaging / MaaP, WhatsApp Business Cloud API, MMS (MM1 / MM4 / MM7), mittente verificato e brandizzato e orchestrazione del fallback del canale.
- RCS
RCS Business Messaging e la piattaforma MaaP
Come funziona RCS Business Messaging: il GSMA Universal Profile (RCC.07), l'architettura Messaging-as-a-Platform (RCC.71), gli agenti verificati, la scoperta delle capacità, i flussi MO/MT e gli eventi di fatturazione — e in cosa la RBM agent API differisce da un bind SMPP.
- WhatsApp
WhatsApp Business Platform: Cloud API e template
Come funziona la WhatsApp Business Platform: Cloud API vs On-Premises API, messaggi template (HSM) vs messaggi di sessione, la finestra di assistenza clienti di 24 ore, le categorie marketing/utility/authentication, i webhook, i livelli di qualità del numero e l'opt-in.
- MMS
Architettura MMS: le interfacce MM1, MM4 e MM7
Come funziona l'MMS secondo 3GPP TS 23.140 e OMA MMS: l'MMSC/relay-server, MM1 (handset↔MMSC su WAP/HTTP), MM4 (MMSC↔MMSC su SMTP per l'inter-carrier), MM7 (VASP↔MMSC su SOAP/XML), contenuti MIME/SMIL, limiti di dimensione e MMS A2P.
- Fiducia e branding
Messaggistica con mittente verificato e brandizzato
Come i brand provano la propria identità tra i canali: RCS Verified Sender e agenti business verificati, registrazione del sender-ID GSMA e verifica del brand, e certificati VMC con BIMI per i loghi verificati nell'email — i controlli che combattono spoofing e impersonificazione.
- Matrice decisionale
RCS vs SMS vs WhatsApp: una matrice decisionale dei canali
Un confronto vendor-neutral di RCS, SMS e WhatsApp per la messaggistica business: funzionalità, raggiungibilità e copertura, crittografia end-to-end, conferme di lettura e scrittura, media ricchi, modelli di costo, comportamento di fallback e vincoli normativi — con indicazioni su quando usare quale.
- Orchestrazione
Fallback dei canali e orchestrazione omnicanale
Come la consegna omnicanale mette in cascata i canali: controlli di capacità, fallback RCS→SMS e WhatsApp→SMS, routing least-cost rispetto a best-experience, regole di retry e timeout, e una vista unificata dei delivery receipt che riconcilia lo stato su ogni canale.
- Interattivo
Rich card e messaggistica interattiva
I blocchi costitutivi interattivi di RCS e WhatsApp: rich card e caroselli, risposte e azioni suggerite, pulsanti di risposta rapida e list picker — con esempi di payload JSON per ciascuna piattaforma, più indicazioni di UX e accessibilità.
Numerazione e identità
Il livello di numerazione e identificazione alla base di ogni messaggio e chiamata: codici E.164 / MSISDN, MCC-MNC / PLMN, identità dell'abbonato IMSI / IMEI, ENUM (E.164 → URI) e instradamento per la portabilità del numero mobile.
- Numerazione pubblica
La numerazione E.164 e l'MSISDN spiegati
Come funziona il piano di numerazione internazionale ITU-T E.164: country calling code, national destination code (NDC) e subscriber number, il massimo di 15 cifre, la struttura dell'MSISDN e come normalizzare i numeri in E.164 per la messaggistica A2P.
- Identità di rete
Codici MCC, MNC e PLMN spiegati (E.212)
Come funziona il piano di identificazione ITU-T E.212: il Mobile Country Code (MCC) di 3 cifre e il Mobile Network Code (MNC) di 2–3 cifre che si combinano in una PLMN identity, come identificano la home network, gli intervalli di test e in cosa MCC-MNC differisce dall'NDC dell'MSISDN.
- Identità dell'abbonato
IMSI, IMEI e identità dell'abbonato spiegati
Le identità che distinguono un abbonato da un dispositivo: l'IMSI (MCC+MNC+MSIN, E.212), l'IMEI (TAC+serial), la chiave di autenticazione Ki, le identità temporanee TMSI/GUTI, la SIM/USIM/eSIM (eUICC) e come l'HLR mappa l'MSISDN sull'IMSI.
- Routing dei numeri
ENUM: mappare i numeri E.164 in URI
Come ENUM (IETF RFC 6116) mappa i numeri telefonici E.164 in URI tramite DNS: il dominio e164.arpa a cifre invertite, i record NAPTR con riscrittura regexp e la differenza tra ENUM pubblico (utente) e privato (carrier/infrastruttura) per il routing SIP e VoIP.
- Routing dei numeri
Mobile number portability e routing
Come la mobile number portability (MNP) spezza il legame tra un numero composto e la sua home network: i routing number (RN), All-Call-Query vs Onward Routing, i database MNP e i dip, e come l'HLR/MNP lookup guida il least-cost routing e una consegna affidabile.
API HTTP e webhook
Il livello HTTP/ REST al di sopra dei protocolli di rete: progettazione dell'API di messaggistica REST, consegna webhook e verifica della firma HMAC, stato/payload in entrata, autenticazione e firma, idempotenza, limitazione della velocità ed errori problem+json — basato su standard (RFC 9457, bozze IETF).
- Progettazione API
Progettazione di API di messaggistica REST: risorse, metodi, status code
Come si modella un'API di messaggistica REST basata sugli standard: una collection di messages, i metodi HTTP e la semantica degli status code secondo RFC 9110, invio sincrono vs asincrono (202 Accepted più una callback di stato), content negotiation e versioning su URL vs header — con una tabella di confronto REST vs SMPP.
- Webhook
Consegna e affidabilità dei webhook: retry, ordinamento, dead-letter
L'architettura standard dei webhook/callback e il suo modello di affidabilità: consegna at-least-once, backoff esponenziale con jitter sui retry, timeout di consegna, garanzie di ordinamento, dead-letter queue, consumer idempotenti e salute dell'endpoint / circuit-breaking per proteggere un ricevitore in difficoltà.
- Sicurezza
Verifica della firma dei webhook: HMAC-SHA256 e protezione dal replay
Come verificare che un webhook sia autentico e non manomesso: HMAC-SHA256 sul raw body, gli header di firma e timestamp, la protezione dal replay con una tolleranza di timestamp e un nonce, il confronto a tempo costante per sconfiggere gli attacchi di timing, e la rotazione sicura del segreto con chiavi sovrapposte.
- Webhook
Payload dei webhook di stato (DLR) e in ingresso (MO)
Gli schemi dei payload per le due callback di messaggistica fondamentali: l'evento di stato di consegna (DLR) con il suo id di messaggio, l'enum di stato, la causa di errore e i timestamp, e l'evento di messaggio in ingresso (MO) — più una tassonomia dei tipi di evento e come un DLR HTTP mappa su una ricevuta SMPP deliver_sm.
- Sicurezza
Autenticazione API e firma delle richieste: token, HMAC, OAuth, mTLS
I modi standard per autenticare un'API di messaggistica HTTP: bearer token e API key nell'header Authorization, firma HMAC delle richieste su una canonical request, scoping e rotazione delle chiavi, mutual TLS e OAuth 2.0 client-credentials per l'accesso machine-to-machine.
- Affidabilità
Idempotenza e rate limiting: chiavi, 429, Retry-After, RateLimit
Due pattern HTTP standards-track per client sicuri e ben educati: l'header Idempotency-Key (draft IETF) per una submission exactly-once con finestra di dedup e replay della risposta, e il rate limiting — 429 con Retry-After, gli header RateLimit / RateLimit-Policy (draft IETF), i token bucket e la backpressure lato client.
- Progettazione API
Errori API (problem+json) e paginazione (cursor, Link header)
Due standard che mantengono prevedibile un'API HTTP: RFC 9457 problem+json per errori machine-readable (type, title, status, detail, instance) con una tassonomia retryable-vs-terminal, e la paginazione — cursor vs offset, l'header Link di RFC 8288 per next/prev e i limiti di page size.
Dalle specifiche al cablaggio.
Questi riferimenti descrivono i protocolli che BroadNet utilizza a livello di operatore dal 2003, in 200+ paesi e con 1.000+ connessioni con operatori. Quando sei pronto per l'invio, la documentazione e gli strumenti qui di seguito ti guideranno dalla fase di lettura a quella di invio.