Segmenti concatenati negli SMS A2P: come verificare il conteggio effettivo prima di inviare traffico

Che cos’è un segmento SMS e perché contare i caratteri non basta

Un segmento è un’unità di invio SMS. Se il testo non entra nel payload disponibile, può essere suddiviso in più parti concatenate che il terminale del destinatario ricompone. Per questo, contare i caratteri visibili non basta: il risultato dipende dal modo in cui vengono codificati e dallo spazio occupato dalle informazioni tecniche che accompagnano il testo.

Il payload TP-UD può contenere solo i dati dell’utente oppure includere un’intestazione. Se è presente un’intestazione, anche la sua lunghezza occupa parte dello spazio disponibile. Nella concatenazione, l’intestazione identifica il messaggio e la posizione di ciascuna parte.

• Non confondere i caratteri Unicode visibili con le unità trasmesse.
• Il conteggio tecnico dei segmenti non determina, da solo, una tariffa commerciale.
• La capacità effettiva dipende dalla codifica e dalla modalità di concatenazione.

GSM 7-bit, caratteri di escape e Unicode

In GSM 7-bit, i caratteri sono rappresentati mediante septet. Tuttavia, non tutti i simboli comunemente descritti come caratteri occupano un solo septet: quelli della tabella di estensione sono rappresentati con una sequenza di escape e ne utilizzano due. Il calcolo deve basarsi sulle unità codificate, non solo sulle posizioni nel testo.

Se un carattere non è presente nelle tabelle GSM pertinenti, il mittente potrebbe dover usare un’altra codifica, come UCS2. Questa rappresenta ogni carattere in unità da 16 bit. Per emoji e altri caratteri fuori dal repertorio GSM, occorre verificare quale codifica seleziona effettivamente il sistema; non è prudente presumere che il messaggio resti in GSM 7-bit.

Anche le tabelle nazionali delle lingue possono influire sulla scelta e sul calcolo. La codifica effettiva dipende dal contenuto, dalla configurazione e dall’implementazione del mittente o della rotta.

• Conta due septet per ogni simbolo GSM 7-bit che richiede una sequenza di escape.
• Verifica il comportamento del codificatore con accenti, simboli, emoji e caratteri insoliti.
• Non presumere un valore predefinito per data_coding in SMPP: la specifica SMPP v3.4 indica che non ne esiste uno.

Come la concatenazione influisce sulla capacità

La concatenazione riserva spazio per un’intestazione UDH, che contiene le informazioni necessarie a ricostruire il messaggio. L’intestazione può includere un riferimento comune, il numero totale delle parti e il numero di sequenza. In GSM 7-bit, può essere necessario anche un riempimento di bit per allineare il testo dopo l’intestazione.

Come riferimento normativo, 3GPP TS 23.040 specifica capacità di 153 caratteri GSM 7-bit o 67 caratteri UCS2 per segmento con l’intestazione standard di concatenazione con riferimento a 8 bit. Per la variante con riferimento a 16 bit, specifica rispettivamente 152 e 66. Si tratta di capacità tecniche di riferimento, non della garanzia che tutte le piattaforme o rotte utilizzino la stessa modalità.

La specifica richiede inoltre che determinate sequenze non vengano divise tra segmenti: i caratteri di escape GSM e i caratteri UCS2 devono rimanere integri. Perciò, una semplice suddivisione in blocchi di caratteri può produrre un calcolo errato.

• Verifica se l’implementazione usa un riferimento di concatenazione a 8 o 16 bit.
• Non usare i limiti di riferimento al posto della verifica dell’intestazione effettiva.
• Distingui la segmentazione tecnica dalle regole di fatturazione concordate con ciascun fornitore.

Un metodo ripetibile per calcolare i segmenti

Per rendere il calcolo ripetibile e verificabile, basalo sul testo esatto che verrà inviato. Un’anteprima può differire dal contenuto trasmesso a causa di sostituzioni, spazi, interruzioni di riga o caratteri aggiunti da un modello.

Segui questa procedura prima della messa in produzione e conserva l’output del calcolo insieme alla richiesta di invio.

• 1. Acquisisci il testo finale esatto, dopo aver applicato personalizzazione e sostituzioni.
• 2. Identifica la codifica e le tabelle effettivamente utilizzate dal codificatore; non dedurle dal solo aspetto del testo.
• 3. Se è GSM 7-bit, conta i septet e considera come due unità i caratteri di estensione. Se è UCS2, conta le unità da 16 bit secondo il codificatore utilizzato.
• 4. Determina la modalità di concatenazione e lo spazio occupato dall’intestazione. Se necessario, considera l’allineamento dei septet.
• 5. Calcola quante parti servono, assicurandoti che le sequenze di escape e i caratteri UCS2 non vengano divisi.
• 6. Salva il risultato insieme a una versione o a un hash del testo, alla configurazione del codificatore e al payload preparato.

Casi di test prima di modificare modelli o codificatori

Verifica sia i limiti sia i cambi di codifica. Un messaggio breve può passare a più parti aggiungendo un solo carattere che impone un altro schema; un simbolo di estensione può occupare due septet anche se visivamente corrisponde a una sola posizione.

Usa casi controllati e conserva il testo esatto di ogni test. Non modificare contemporaneamente contenuto, codifica e modalità di concatenazione: altrimenti sarà difficile individuare la causa di una differenza.

• Testo contenente solo caratteri della tabella GSM predefinita.
• Testo con caratteri della tabella di estensione.
• Testo con accenti, simboli o emoji per osservare se cambia la codifica.
• Messaggi vicini ai limiti di una o più parti, con la modalità di riferimento effettivamente configurata.
• Modifiche a interruzioni di riga, spazi e variabili del modello che alterano il testo finale.

Verifica la richiesta accettata e i registri

Il calcolo locale va confrontato con ciò che è stato inviato. In SMPP, controlla il valore di data_coding, il contenuto di short_message o message_payload in base all’implementazione, e l’intestazione UDH o i parametri SAR utilizzati. La specifica SMPP v3.4 definisce sar_msg_ref_num, sar_total_segments e sar_segment_seqnum per comunicare riferimento, numero totale e sequenza; indica che i tre parametri correlati devono essere presenti affinché venga elaborato il riferimento SAR.

Una risposta submit_sm_resp positiva conferma l’esito della richiesta e può restituire un message_id, ma il formato standard non include un campo che confermi il numero di segmenti accettati. L’accettazione, quindi, non sostituisce il confronto con i registri della piattaforma o del fornitore.

Se l’invio avviene tramite un’API HTTP, consulta la documentazione dell’API per sapere che cosa rappresenta la risposta e se espone dettagli sulla segmentazione. Non dare per scontato che una risposta di accettazione comunichi il conteggio tecnico.

• Confronta il testo o il relativo hash, la codifica, l’UDH o i parametri SAR e la risposta di invio.
• Quando disponibile, collega il message_id ai registri successivi.
• Consulta la documentazione dell’API, del fornitore e della rotta per interpretare i campi riportati.
• Non confondere l’accettazione, il DLR e una conferma indipendente della ricezione sul terminale.

Indaga e riconcilia le discrepanze senza dedurre le tariffe

Una differenza tra il calcolo locale e un registro esterno può dipendere dal confronto tra testi diversi, dalla selezione di un’altra codifica, dall’uso di una diversa modalità di concatenazione o da una trasformazione applicata dalla piattaforma. Può anche dipendere dal tipo di dato riportato da ciascun sistema. Per prima cosa, individua che cosa è stato inviato e quale unità sta registrando ciascuna parte.

Tieni separato il conteggio tecnico dei segmenti dalla riconciliazione commerciale. Gli standard tecnici descrivono codifica, payload e concatenazione; non stabiliscono la tariffa applicabile. Per qualsiasi importo, fai riferimento alle condizioni contrattuali e ai registri di fatturazione pertinenti.

• Conserva il testo esatto o il relativo hash e la versione del modello.
• Registra codifica, data_coding, unità calcolate e modalità di concatenazione.
• Salva l’UDH o i parametri SAR, l’esito dell’invio e il message_id.
• Annota i segmenti riportati da ciascun sistema, la loro origine e l’intervallo temporale.
• Esamina una variabile alla volta e documenta la conclusione prima di apportare modifiche in produzione.

Lista di controllo e riferimenti tecnici

Prima di attivare un modello o modificare l’invio, verifica che il calcolo si basi sul testo finale, che la codifica effettiva sia stata identificata e che la modalità di concatenazione corrisponda alla configurazione reale. Ripeti il test quando cambiano contenuto, codificatore, API, sessione SMPP o rotta.

Per i dettagli normativi, consulta 3GPP TS 23.038 per alfabeti e codifica, 3GPP TS 23.040 per la realizzazione tecnica degli SMS e le relative intestazioni, e SMPP v3.4 per data_coding, risposte e parametri SAR.

• Il testo di test corrisponde byte per byte o tramite hash a quello inviato?
• Sono stati verificati GSM 7-bit, i caratteri di escape e gli eventuali passaggi a UCS2?
• Sono state confermate la modalità di concatenazione e la relativa intestazione?
• Sono stati conservati la richiesta, la risposta, l’identificativo e i registri pertinenti?
• La riconciliazione tecnica è mantenuta separata dall’interpretazione delle tariffe?