Protocollo e impostazioni del connettore SMS

NOTA

La Protocollo e impostazioni del connettore SMS per Adobe Campaign Classic si trova in page.

In questo documento, tutti i riferimenti ai dettagli relativi al protocollo, ai nomi e ai valori dei campi fanno riferimento al Specifiche di SMPP 3.4.

Panoramica

L’SMS potrebbe essere limitato all’invio di messaggi di testo brevi senza formattazione, ma la sua semplicità lo rende un valido canale di comunicazione.

Esistono due modi principali per inviare un SMS:

  • Mandalo manualmente da un telefono, il modo abituale per comunicare direttamente tra le persone.

  • Invialo da Internet, il modo in cui Adobe Campaign invia i messaggi. Per questo, è necessario un provider di servizi SMS che connetta Internet alla rete mobile.
    Adobe Campaign utilizza il protocollo SMPP per inviare SMS a un provider di servizi.

Questo documento illustra la connessione impostata tra Adobe Campaign e un provider SMPP.

I provider SMPP a volte possono derogare alle specifiche ufficiali, ma il connettore SMS in Adobe Campaign offre molte opzioni per adattare il proprio comportamento in modo che sia compatibile con la maggior parte dei provider.

IMPORTANTE

L'impostazione di una connessione a un nuovo provider potrebbe richiedere alcune competenze tecniche, conoscenza di TCP, binario, rappresentazione esadecimale e codifiche di testo. Sarà inoltre necessaria una collaborazione attiva con il fornitore.

Tipi di SMS

Quando invii SMS di massa tramite un provider di SMS, incontrerai tre diversi tipi di SMS:

  • SMS MT (Mobile Terminated): un SMS inviato da Adobe Campaign ai telefoni cellulari tramite il provider SMPP.

  • SMS MO (origine mobile): un SMS inviato da un dispositivo mobile ad Adobe Campaign tramite il provider SMPP.

  • SMS SR (Status Report) o DR o DLR (Delivery Receipt): una ricevuta di ritorno inviata dal dispositivo mobile ad Adobe Campaign tramite il provider SMPP che indica che l’SMS è stato ricevuto correttamente. Adobe Campaign può anche ricevere SR che indica che il messaggio non può essere consegnato, spesso con una descrizione dell’errore.

È necessario distinguere tra riconoscimenti (PDU RESP, parte del protocollo SMPP) e SR: SR è una sorta di SMS che viene inviato attraverso la rete end-to-end, mentre un riconoscimento è solo una conferma del successo di un singolo trasferimento.

Sia le riconoscenze che l'SR possono attivare gli errori, distinguendo tra i due aiuterà la risoluzione dei problemi.

Informazioni trasportate da un SMS

Un SMS trasporta più informazioni del testo. Ecco un elenco di ciò che ci si aspetta di trovare in un SMS:

  • Il testo, che è limitato a 140 byte, ovvero tra 70 e 160 caratteri a seconda della codifica. Vedi Codifica testo SMS qui di seguito per dettagli e limitazioni.

  • Un indirizzo destinatario, talvolta chiamato ADC o MSISDN. È il numero del cellulare che riceverà l'SMS.

  • Indirizzo mittente, che può essere chiamato oADC o a volte sender id. Può trattarsi di un numero di telefono utilizzato giorno per giorno, un codice breve inviato tramite un provider o un nome. Il nome è una funzione facoltativa, in tal caso non è possibile rispondere all’SMS.

  • Flag che indica se il messaggio è un messaggio Flash. Un messaggio flash è un pop-up che non viene memorizzato in memoria.

  • Flag che indica se un SR è previsto o meno.

  • Una data di validità, dopo la quale non è consentito riprovare alcun dispositivo di rete.

  • A data_coding , che indica la codifica del testo.

Protocollo SMPP

Adobe Campaign Standard supporta il protocollo SMPP versione 3.4. Si tratta di un protocollo diffuso che consente l’invio di SMS a un provider (SMSC) e la ricezione di SMS e ricevute. Per ulteriori informazioni, consulta la sezione Documentazione SMPP.

Le apparecchiature di rete sul lato del provider di servizi SMS sono spesso chiamate SMSC.

Connessioni SMPP

Adobe Campaign si connette all’apparecchiatura di rete del provider di servizi SMS tramite TCP. Il protocollo SMPP imposta le connessioni TCP permanenti da Adobe Campaign al provider. Le connessioni TCP sono sempre iniziate da Adobe Campaign, anche per ricevere messaggi.
SMPP apre 1 o 2 connessioni TCP, a seconda della sua modalità. Tutte le connessioni sono sempre avviate da Adobe Campaign.

Il protocollo SMPP può funzionare in due modalità:

  • Trasmettitore+ricevitore (o TX+RX): per la trasmissione e la ricezione dei messaggi vengono utilizzate due connessioni TCP separate.
  • Transceiver (ABOR TRX): viene utilizzata una singola connessione TCP per la trasmissione e la ricezione dei messaggi.
NOTA

TRX è preferibile per Adobe Campaign Standard in quanto riduce il numero di connessioni e semplifica il recupero delle connessioni in caso di guasto.

PDU SMPP

Le unità di trasmissione SMPP ("pacchetti") sono denominate PDU. A PDU contiene un comando, uno stato, un numero di sequenza e dati.

Ogni PDU deve essere riconosciuta da un SMPP RESP PDU (risposta sincrona). Le richieste possono essere inoltrate: il mittente può inviare molti comandi senza attendere RESP, il numero di richieste che possono essere eseguite in qualsiasi momento è denominato finestra . RESP PDU possono arrivare in qualsiasi ordine, non collegato all'ordine della rispettiva PDU iniziatrice.

Nei separati Trasmettitore+ricevitore la connessione utilizzata dipende dal tipo di messaggio trasmesso. Il collegamento del trasmettitore viene utilizzato per MT e il collegamento del ricevitore viene utilizzato per MO e SR. Le richieste e le risposte per ogni tipo di messaggio vengono inviate tramite la stessa connessione TCP.

Ad esempio, quando si invia un MT, viene utilizzata la connessione del trasmettitore e il RESP che riconosce che il MT viene inviato anche attraverso il canale del trasmettitore. Quando si riceve un MO (o un SR), la connessione del ricevitore viene utilizzata per ricevere il MO e inviare il RESP che riconosce il MO.

In Adobe Campaign Standard, la riconciliazione MT e SR è nativa per l’MTA, quindi non esiste un processo SMS dedicato.

Un successo SUBMIT_SM_RESP PDU attiva lo stato del messaggio "inviato" nel registro di invio mentre un esito positivo DELIVER_SM (SR) PDU attiva lo stato del messaggio "ricevuto".

Aspetti di sicurezza

Il protocollo stesso non è crittografato. La maggior parte dei provider implementa una variante di IP inserire nell'elenco Consentiti, quindi gli indirizzi IP del server Adobe Campaign devono essere dichiarati al provider.

Adobe Campaign supporta il passaggio di un accesso e una password durante la fase di binding. Inoltre supporta SMPP rispetto a TLS. Va notato che i certificati sono necessari per garantire la sicurezza necessaria. Anche se il connettore SMPP consente di bypassare i controlli sui certificati, dovrebbe essere utilizzato solo per i test, perché TLS senza certificati fornisce un livello di sicurezza significativamente inferiore.

Il connettore utilizza i certificati predefiniti forniti dal sistema openssl libreria. Di solito è fornito dal /etc/ssl/certs directory su Debian. Questa directory è fornita dal pacchetto "ca-certificates" per impostazione predefinita, ma può essere personalizzata.

Informazioni in ciascun tipo di PDU

Ogni tipo di PDU ha campi distinti che contengono diverse informazioni. Queste PDU sono descritte in dettaglio nella sezione Specifiche di SMPP 3.4.

Ogni sezione seguente descrive sia la PDU che la relativa risposta sincrona (*_RESP PDU). Tutte le PDU devono essere riconosciute con un RESP, questa è una parte obbligatoria della specifica.

Le PDU possono disporre di campi facoltativi. Qui sono descritti solo i campi più comuni. Fai riferimento a Specifiche di SMPP 3.4 per ulteriori informazioni.

BIND_TRANSMITTER / BIND_RECEIVER / BIND_TRANSCEIVER

Questa PDU viene utilizzata per avviare una connessione a SMSC. Trasmettitore, Ricevitore e Ricetrasmettitore le modalità cambiano solo il tipo di SMS consentito per essere trasferito su questa connessione, in particolare:

Modalità Tipi di SMS consentiti
Trasmettitore MT
Ricevitore MO + SR
Ricetrasmettitore MT + MO + SR

Campi di rilievo in un BIND_* PDU:

  • system_id: Accesso utilizzato per l’autenticazione. Impostato nell’account esterno.

  • password: Password utilizzata per l'autenticazione. Impostato nell’account esterno.

  • system_type: È necessario impostare un valore specifico per alcuni provider. Impostato nell’account esterno, disponibile in tutte le versioni. Spesso distingue tra diversi tipi di contratti, canali, paesi, ecc.

  • addr_ton e addr_npi: Richiesto da alcuni provider. Impostato da Bind TON e Bind NPI nell’account esterno.

  • indirizzo_intervallo: Richiesto da alcuni provider. Nella maggior parte dei casi, questo è un elenco di codici di scelta rapida consentiti in questa connessione. Impostato nell’account esterno.

BIND_*_RESP non dispone di un campo specifico e conferma se la connessione è riuscita o meno.

SBARCO

Questa PDU deve essere inviata dal sistema prima della disconnessione. Deve attendere la corrispondenza UNBIND_RESP PDU prima di chiudere la connessione.

La conformità a SMSC non deve chiudere la connessione. La connessione TCP è controllata dal connettore Adobe Campaign.

SUBMIT_SM

Questa PDU invia un MT al SMSC. La sua PDU di risposta dà l'ID del MT.

Campi di rilievo in un SUBMIT_SM PDU:

  • service_type: richiesto da alcuni provider. Imposta nelle proprietà di consegna.

  • source_addr_ton e source_addr_npi: indica il tipo di indirizzo di origine trasmesso. Il significato di questi campi è standardizzato, ma poiché alcuni provider lo utilizzano in modo diverso, è necessario chiedere al provider il valore corretto. Impostato nell’account esterno.

  • source_addr: l'indirizzo di origine / oADC del MT. Sarà visualizzato sul cellulare. Set in the external account and the delivery, the value in the delivery takes precedence over the value of the external account.

  • dest_addr_ton and dest_addr_npi: indicates what kind of destination address is transmitted (e.g. local or international format). Il significato di questi campi è standardizzato, ma poiché alcuni provider lo utilizzano in modo diverso, è necessario chiedere al provider il valore corretto. Impostato nell’account esterno.

  • destination_addr: indirizzo del destinatario, numero di telefono o MSISDN.

  • esm_class: utilizzato per indicare se l’UDH è utilizzato o meno nel campo di testo. Abilitato automaticamente dal connettore per SMS suddivisi se il valore message_payload modalità non utilizzata.

  • priority_flag: priorità del messaggio rispetto agli altri. Ciò è legato alla priorità della consegna stessa.

  • valid_period: marca temporale dopo la quale non è necessario riprovare. Impostato nella consegna stessa.

  • registrato_delivery: indica se una SR è richiesta o meno. Adobe Campaign imposta sempre questo flag ad eccezione delle risposte automatiche. Per i messaggi multiparte, il flag viene impostato solo per la prima parte. Tutte le versioni hanno lo stesso comportamento.

  • data_coding: indica la codifica utilizzata nel campo di testo. Consulta la sezione Codifica testo SMS per ulteriori informazioni.

  • short_message: il testo del messaggio. Se viene utilizzato UDH, contiene anche l’intestazione UHD.

Adobe Campaign supporta questi campi facoltativi:

  • dest_addr_subunit: utilizzato per specificare il target dell’SMS: scheda flash, mobile o SIM. Imposta nelle proprietà di consegna.

  • message_payload: se attivato nell’account esterno, i messaggi lunghi saranno inviati in un’unica PDU e il testo sarà trasmesso in questo campo anziché nella short_message campo .

SUBMIT_SM_RESP

Questa PDU conterrà l'ID del MT. Questo è utile per abbinarlo all'SR in ingresso.

IMPORTANTE

Molti provider trasmettono l'ID MT in esadecimale. Assicurati di impostare la Formato ID nella convalida MT impostazione corretta nell’account esterno.

Alcuni provider inviano SUBMIT_SM_RESP dopo l'invio dell'SR. Per tenere conto di tale comportamento, Adobe Campaign attende 30 secondi prima di rispondere ID messaggio non valido a un SR con un ID sconosciuto.

DELIVER_SM

Questa PDU viene inviata da SMSC ad Adobe Campaign. Contiene un MO o un SR.

La maggior parte dei campi hanno lo stesso significato dei loro SUBMIT_SM controparte. Elenco di campi utili:

  • source_addr: indirizzo di origine del MO/SR. Di solito questo è un numero di telefono.

  • destination_addr: codice breve che ha ricevuto il MO o l'SR.

  • esm_class: utilizzato per indicare se la PDU è un MO o un SR.

  • short_message: testo del messaggio. Per SR, questo contiene i dati descritti nell'appendice B della specifica del protocollo SMPP. Vedi Gestione degli errori SR per ulteriori dettagli.

Adobe Campaign è in grado di leggere l'ID del messaggio nel receipted_message_id campo facoltativo con regolazione della configurazione.

DELIVER_SM_RESP

Questa PDU viene inviata da Adobe Campaign per confermare SR e MO.

Adobe Campaign Standard invia solo un DELIVER_SM_RESP una volta completate tutte le fasi di elaborazione. Ciò garantisce che non venga riconosciuta alcuna SR o MO mentre sussiste il rischio di errori di elaborazione.

Questa PDU viene utilizzata solo per verificare che la connessione sia attiva. La sua frequenza deve essere stabilita in base alle esigenze del fornitore.

I 60 secondi predefiniti devono corrispondere alla maggior parte delle configurazioni impostate nell’account esterno.

Questa PDU riconosce che la connessione è attiva.

SMS multiparte (SMS lungo)

Multipart SMS, or long SMS, are SMS that are sent in multiple parts. Due to technical limitations in the mobile network protocol, a SMS cannot be larger than 140 bytes or it will need to be split. Consulta la sezione Codifica testo SMS per ulteriori informazioni sul numero di caratteri che possono essere inclusi in un SMS.

Ogni parte di un messaggio lungo è un singolo SMS. Queste parti viaggiano in modo indipendente sulla rete e sono assemblate dal telefono cellulare ricevente. Per gestire i nuovi tentativi e i problemi di connettività, Adobe Campaign invia queste parti in ordine inverso e richiede un SR solo nella prima parte del messaggio, l’ultima inviata. Poiché il telefono cellulare visualizza un messaggio solo quando viene ricevuta la sua prima parte, i nuovi tentativi su parti aggiuntive non produrranno duplicati sul telefono cellulare.

Il numero massimo di SMS per messaggio può essere impostato per consegna utilizzando il Numero massimo di SMS per messaggio nella Modello di consegna. I messaggi che superano questo limite avranno esito negativo durante l’invio con un motivo di errore SMS troppo lungo.

Ci sono 2 modi per inviare SMS lunghi:

  • UDH: il modo predefinito e consigliato per inviare messaggi lunghi. In questa modalità, il connettore divide il messaggio in più SUBMIT_SM PDUè con informazioni UDH in loro. Questo protocollo è quello utilizzato dagli stessi telefoni cellulari. Questo significa che Adobe Campaign ha il maggior controllo sulla generazione dei messaggi, consentendogli di calcolare esattamente quante parti sono state inviate e come sono state suddivise.

  • message_payload: il modo in cui inviare l'intero messaggio lungo in un unico SUBMIT_SM PDU. Il provider dovrà dividerlo, il che significa che è impossibile per Adobe Campaign sapere esattamente quante parti sono state inviate. Alcuni fornitori richiedono questa modalità, ma consigliamo di utilizzarla solo se non supportano UDH.

Vedi la descrizione del esm_class, short_message e message_payload campi PDU SUBMIT_SM per ulteriori dettagli sul protocollo e i formati.

Limitazione del carico e finestre

La maggior parte dei provider richiede un limite di throughput per ogni connessione SMPP. Questo può essere ottenuto impostando un numero di SMS nell’account esterno. Tieni presente che la limitazione della velocità effettiva avviene per connessione, il throughput effettivo totale corrisponde al limite per connessione moltiplicato per il numero totale di connessioni. Questo è descritto in Connessioni simultanee sezione .

To reach maximum possible throughput, you will need to fine tune the maximum sending window. La finestra di invio è il numero di SUBMIT_SM PDUche può essere inviato senza attendere un SUBMIT_SM_RESP. See the Sending window setting section for more details.

SR e gestione degli errori ("Appendice B")

The SMPP protocol defines standard synchronous errors in RESP PDUs, but it does not define error codes for SR. Ogni provider utilizza i propri codici di errore con il proprio significato.

Una raccomandazione è formulata nella sezione dell'appendice B del Specifiche del protocollo SMPP (pag. 167) ma questo non elenca i codici di errore effettivi né il loro significato.

Per adattarsi alla gestione degli errori, il sistema dei messaggi di broadlog di Adobe Campaign è stato sfruttato per fornire correttamente gli errori e la loro gravità (rigido, morbido, ecc.).

Come accennato in precedenza, esistono due tipi diversi di errori:

  • risposte sincrone nel SUBMIT_SM_RESP che si verifica immediatamente dopo l’invio del messaggio a SMSC
  • le ricevute che possono essere ricevute molto più tardi quando il dispositivo mobile ha ricevuto il messaggio o quando il messaggio è scaduto. In tal caso l'errore si trova in un SR.

Quando viene ricevuta una SR, lo stato e l'errore si trovano nella short_message campo (esempio per le implementazioni conformi all'appendice B). La short_message Il campo della PDU è spesso denominato campo di testo poiché contiene testo in MT. In caso di SR, contiene informazioni tecniche più un sottocampo denominato Testo. Questi 2 campi sono diversi e short_message contiene effettivamente Testo e altre informazioni.

Formato del campo di testo SR

La specifica consiglia di utilizzare questo formato per il campo di testo SR. Si tratta di un elenco di campi secondari, separati da uno spazio con due punti per separare il nome del campo e il relativo valore. I nomi dei campi non fanno distinzione tra maiuscole e minuscole.

Esempio di un campo di testo SR corrispondente alla raccomandazione dell'appendice B:

id:1234567890 sub:001 dlvrd:001 submit date:1608011415 done date:1608011417 stat:DELIVRD err:000 Text:Hello Adobe world

Il campo id è l'ID ricevuto nel SUBMIT_SM_RESP PDU, il riconoscimento del MT.

sub e dlvrd devono contare la quantità di parti consegnate e di messaggi consegnati, ma questo non viene utilizzato da Adobe Campaign in quanto il sistema di log di trasmissione fornisce informazioni migliori e più integrate.

submit date e done date I campi sono marche temporali indicative di quando l’unità MT è stata inviata e quando l’unità SR è stata inviata dal dispositivo mobile. Ci si aspettano alcuni problemi con i fusi orari o anche marche temporali errate date da dispositivi mobili con data impostata non corretta.

Il campo stat è importante in quanto indica lo stato del messaggio. L'unico status importante è DELIVRD, UNDELIV e REJECTD. La DELIVRD lo stato indica un successo, gli altri due indicano un errore. Altri valori sono possibili, ma sono solitamente notifiche intermedie, ad esempio il MT ha raggiunto il gestore di telefonia mobile, ma non il telefono cellulare. Queste notifiche intermedie vengono ignorate da Adobe Campaign.

Il campo error contiene il codice di errore specifico del provider. Il provider deve fornire una tabella dei possibili codici di errore insieme al loro significato per essere in grado di interpretare questo valore.

Infine, il campo di testo in genere contiene l'inizio del testo del MT. Questo viene ignorato da Adobe Campaign e alcuni provider non lo trasmettono per evitare perdite di PII e il consumo di larghezza di banda della rete. Può essere utilizzato durante la risoluzione dei problemi per individuare più facilmente l'SR che corrisponde a un MT di test leggendo questo campo.

Esempio di elaborazione SR in Adobe Campaign Standard Extended generico SMPP

In questo esempio viene visualizzato il caso di un’implementazione successiva alla raccomandazione Appendice B, i valori predefiniti nell’account esterno e un SMS MT riuscito.

id:1234567890 sub:001 dlvrd:001 submit date:1608011415 done date:1608011417 stat:DELIVRD err:000 Text:Hello Adobe world

First, the id extraction regex is applied to extract the ID and reconcile it with the corresponding MT.

Then, the status extraction regex and error code extraction regex are applied to extract these fields and are appended to the string.

The broadlog message is constructed with this information, and the original unaltered string is appended for reference:

SR ExampleProvider DELIVRD 000|MESSAGE=id:1234567890 sub:001 dlvrd:001 submit date:1608011415 done date:1608011417 stat:DELIVRD err:000 Text:Hello Adobe world

The message is then normalized, removing the MESSAGE part to be able to match multiple messages with the same stat and err codes.

SR ExampleProvider DELIVRD 000|#MESSAGE#

Se non è già stato eseguito il provisioning del messaggio nella tabella dei messaggi del registro di trasmissione, verrà creata una nuova voce utilizzando l’intero messaggio come firstText e il messaggio normalizzato. Quindi, il connettore utilizza il successo e error regex per determinare se si è trattato di un successo o di un errore:

  • Se corrisponde al success regex, sarà considerato un successo.

  • If it matches the error regex, the message is qualified as an error.

  • Se nessuno di questi due regex corrisponde, l'SR viene ignorato. Potrebbe trattarsi di una notifica intermedia, che non viene gestita da Adobe Campaign.

Per impostazione predefinita, tutti gli errori vengono forniti come errori soft. Ciò significa che gli errori rigidi devono essere forniti a mano.

Codifica testo SMS

Dovrebbe contatta sempre il provider SMSC in caso di problemi di codifica. Solo i provider SMSC hanno una conoscenza precisa della codifica che supportano e regole speciali che possono essere applicate a causa di limitazioni nella loro piattaforma tecnica.

I messaggi SMS utilizzano una speciale codifica a 7 bit, spesso denominata codifica GSM7.

Nel protocollo SMPP, il testo GSM7 verrà espanso a 8 bit per carattere per facilitare la risoluzione dei problemi. SMSC lo impacchetterà in 7 bit per carattere prima di essere inviato al dispositivo mobile. Ciò significa che short_message Il campo dell’SMS può essere lungo fino a 160 byte nel frame SMPP, mentre è limitato a 140 byte quando viene inviato sulla rete mobile.

In caso di problemi di codifica, ecco alcuni aspetti importanti da verificare:

  • Assicurati di sapere quali caratteri appartengono a quale codifica. GSM7 non supporta completamente i segni diacritici (accenti). Specialmente in francese, dove é ed è fanno parte del GSM7, ma ê, o ï no. Lo stesso vale per lo spagnolo.

  • Il C con cedilla (ç) è presente solo in maiuscolo nell'alfabeto GSM7, ma alcuni telefoni lo rendono in minuscolo o in caso "intelligente". La raccomandazione generale è di evitarlo completamente e rimuovere il cedilla o passare a UCS-2.

  • Non utilizzare ASCII in SMS a meno che non sia esplicitamente richiesto dal provider SMSC. Questa codifica spreca spazio perché ha caratteri a 8 bit e una copertura inferiore rispetto a GSM7. Questa codifica può essere necessaria per le reti CDMA utilizzate in Nord America.

  • Latin-1 non è sempre supportato. Verificare la compatibilità con il provider SMSC prima di tentare di utilizzare Latin-1.

  • Le tabelle di spostamento della lingua nazionale non sono supportate dal connettore Adobe Campaign. È necessario utilizzare UCS-2 o altro data_coding invece.

  • UCS-2 e UTF-16 sono spesso mescolati da telefoni. Questo è un problema quando si utilizzano emoji e altri caratteri non presenti in UCS-2.

  • La maggior parte dei telefoni non ha glifi di font per tutti i caratteri UCS-2. Gli smartphone tendono ad essere in grado di visualizzare caratteri rari piuttosto facilmente, ma i telefoni a funzionalità generalmente hanno un supporto limitato a ciò che è utile nella lingua madre del paese in cui sono stati acquistati. Se si desidera utilizzare emoji o ASCII-art, testarlo su un'ampia varietà di telefoni prima di inviare. L’anteprima di Adobe Campaign non simula i glifi mancanti e visualizzerà i simboli disponibili nel browser web.

La data_coding indica la codifica utilizzata. Un problema importante è che il valore 0 indica la codifica SMSC predefinita nella specifica, che in genere si riferisce a GSM7. Controlla con il partner SMSC a quale codifica è associata data_coding = 0 che supporta solo Adobe Campaign. Altro data_coding i valori tendono a seguire le specifiche, ma l'unico modo per essere sicuri è quello di controllare con il provider SMSC.

La dimensione massima di un messaggio dipende dalla relativa codifica. Questa tabella riassume tutte le informazioni pertinenti:

Codifica Codifica_dati normale Dimensioni del messaggio (caratteri) Dimensione della parte per SMS multiparte Caratteri disponibili
GSM7 0 160 152 Set di caratteri di base GSM7 + estensione (i caratteri estesi richiedono 2 caratteri)
Latino-1 3 140 134 ISO-8859-1
UCS-2
UTF-16
8 70 67 Unicode (varia da telefono a telefono)

Parametri dell’account esterno SMPP

Ogni implementazione del protocollo SMPP ha molte varianti. Per migliorare la compatibilità e l'adattabilità, sono disponibili molte impostazioni per modificare il comportamento del connettore SMPP. Questa sezione descrive ogni parametro e i relativi effetti sul connettore.

Parametri generali e ciclo di produzione

Limita le istanze MTA per questo account

È possibile impostare un limite al numero di istanze MTA consentite per la connessione al provider SMPP. Se questa opzione è selezionata, è possibile specificare il numero massimo di MTA utilizzabili.

Questa opzione consente un controllo più preciso del numero di connessioni, vedi Connessioni simultanee.

Se imposti un valore maggiore del numero di MTA in esecuzione, tutti gli MTA verranno eseguiti normalmente: questa opzione è solo un limite e non può generare ulteriori MTA.

If you need to precisely control the number of connections, e.g. provider requirement, it is recommended to always set this option even if the current deployment has the right number of MTAs running. Se successivamente verranno aggiunti ulteriori MTA, il limite di connessione sarà comunque rispettato.

Connection settings

Modalità di connessione SMPP

Imposta la connessione in ricetrasmettitore in modalità o in modalità separata trasmettitore+ricevitore modalità. Quando si passa a separato trasmettitore+ricevitore modalità, impostazioni nella Modalità di connessione SMPP la sezione si applica al trasmettitore e le impostazioni nella Impostazioni di connessione del ricevitore la sezione si applica alla connessione del ricevitore, solo se è stata selezionata la Utilizzare parametri diversi per il ricevitore casella di controllo.

Nome implementazione SMSC

Imposta il nome dell’implementazione SMSC. Deve essere impostato sul nome del provider. Contact the administrator or the deliverability team to know what to add in this field. Il ruolo di questo campo è descritto in Gestione degli errori SR sezione .

Server

Nome DNS o indirizzo IP del server a cui connettersi.

Porta

Porta TCP a cui connettersi.

Account

Accesso della connessione. Trasmesso in system_id campo della PDU BIND.

Password

Password della connessione SMPP. Passato nel campo password della PDU BIND.

Tipo di sistema

Valore passato nel system_id campo della PDU BIND. Alcuni provider hanno bisogno di un valore specifico qui.

Connessioni simultanee

In Adobe Campaign Standard, definisce il numero di connessioni per thread SMS e per processo MTA.
Il numero di processi MTA è determinato dalla distribuzione: di solito ci sono 2 MTA e 1 thread. Il numero di thread può essere modificato nel file config-instance.xml utilizzando l'impostazione smppConnectorThreads. Di solito c'è 1 processo MTA per contenitore e 1 thread per processo MTA.

Formula di connessioni totali per Adobe Campaign Standard:

  • Connessioni totali = Connessioni simultanee * numero di thread * numero di MTA

Le connessioni simultanee sono impostate nell'account esterno, il numero di thread è impostato nel file config-instance.xml (smppConnectorThreads) e il numero di MTA può essere limitato nell'account esterno.

In separato trasmettitore/ricevitore il numero di connessioni di cui sopra rappresenta il numero di trasmettitore/ricevitore coppie che significano che ci sarà il doppio del numero di connessioni in totale.

Abilitare TLS su SMPP

Utilizza TLS per connetterti al provider. La connessione verrà crittografata. La connessione TLS è gestita dalla libreria OpenSSL : tutto ciò che è applicabile a OpenSSL è vero per questa connessione.

Abilita tracce SMPP dettagliate nel file di registro

Questa impostazione esegue il dump di tutto il traffico SMPP nei file di registro. Spesso è necessario regolare i parametri durante la configurazione iniziale. Questa opzione deve essere abilitata per la risoluzione dei problemi relativi al connettore e confrontata con il traffico rilevato dal provider.

Receiver connection setting

Questa sezione è visibile solo in separata trasmettitore+ricevitore modalità.

Utilizzare parametri diversi per il ricevitore

Quando la casella è deselezionata, le stesse impostazioni vengono utilizzate per il trasmettitore e il ricevitore.

Quando la casella è selezionata, le impostazioni nella Impostazioni di connessione la sezione si applica al trasmettitore e alle impostazioni nella Connessione ricevitore le impostazioni verranno applicate al ricevitore.

Server ricevitore, porta, account, password, tipo di sistema

Queste impostazioni si applicano al ricevitore quando trasmettitore+ricevitore modalità. Funzionano come la parte del trasmettitore, vedi sopra per maggiori dettagli.

Impostazioni dei canali SMPP

Consenti traslitterazione caratteri

La traslitterazione è il processo di ricerca di caratteri equivalenti a quelli mancanti. Ad esempio, il carattere francese "ê" (con accento circonflesso) non è presente nella codifica GSM, ma può essere sostituito da "e" senza compromettere la leggibilità.

Se questa casella è deselezionata, la codifica del testo avrà esito negativo se non è in grado di codificare la stringa esattamente come è.

Quando questa casella è selezionata, la codifica del testo tenterà di convertire la stringa in una versione approssimativa, anziché generare un errore. Se alcuni caratteri non hanno un equivalente nella codifica di destinazione, la codifica del testo non riuscirà.

Consulta la sezione Definire una mappatura specifica delle impostazioni di codifica per una spiegazione più generale del processo di codifica.

Archiviare MO in ingresso nel database

Quando abilitato, l’MO in entrata viene memorizzato nella tabella inSMS del database. Puoi eseguire una query su questa tabella utilizzando l’attività query di qualsiasi flusso di lavoro.

Abilitare gli aggiornamenti dei KPI in tempo reale durante l'elaborazione SR

Quando è abilitata, i KPI vengono aggiornati in tempo reale nella pagina di consegna principale al momento della ricezione dell’SR dell’errore.

L'inconveniente può essere a basse prestazioni a causa del contenzioso del database generato. Se disabilitata, le statistiche vengono aggiornate dal syncfromexec flusso di lavoro, in esecuzione ogni 20 minuti.

Numero di origine

Definisce l'indirizzo di origine predefinito per i messaggi. Questa impostazione si applica solo se il numero di origine è stato lasciato vuoto nella consegna.

Per impostazione predefinita, il campo del numero di origine non viene passato, pertanto il provider lo sostituirà al codice breve.

Questo abilita la funzione di sostituzione dell’indirizzo del mittente/oADC.

Short code

Indicates the main short code of the account. Se per questo account vengono utilizzati più codici brevi o se il codice breve è sconosciuto, lasciare vuoto questo campo.

Specifying short code is helpful for two features:

  • The preview will display the short code if no source number is provided. Rifletterà il comportamento reale sul cellulare.

  • L'impostazione di elenco Bloccati della funzione di risposta automatica invia solo all'utente la quarantena per un codice breve specifico.

Origine TON/NPI, destinazione TON/NPI

TON (Type Of Number) and NPI (Numbering Plan Indicator) are described in section 5.2.5 of the SMPP 3.4 specification (page 117). Questi valori devono essere impostati sulle esigenze del provider.

They are transmitted as-is in source_addr_ton, source_addr_npi, dest_addr_ton and dest_addr_npi fields of the SUBMIT_SM PDU.

Tipo di servizio

Questo campo viene trasmesso così come è nella service_type campo SUBMIT_SM PDU. Imposta questo valore in base alle esigenze del provider.

Throughput e timeout

Queste impostazioni controllano tutti gli aspetti temporali del canale SMPP. Alcuni provider richiedono un controllo molto preciso della frequenza dei messaggi, degli intervalli delle finestre e dei tentativi. Queste impostazioni devono essere impostate su valori che corrispondano alla capacità del fornitore e alle condizioni indicate nel contratto.

Finestra di invio

La finestra è il numero di SUBMIT_SM PDUche può essere inviato senza attendere una corrispondenza SUBMIT_SM_RESP.

Example of a transmission with a maximum window of 4:

La finestra consente di aumentare la velocità effettiva quando il collegamento di rete ha una latenza elevata. Il valore della finestra deve essere almeno il numero di SMS/s moltiplicato per la latenza del collegamento in secondi, in modo che il connettore non sia in attesa di un SUBMIT_SM_RESP prima di inviare il messaggio successivo.
Se la finestra è troppo grande, puoi inviare più messaggi duplicati in caso di problemi di connessione. Inoltre, la maggior parte dei provider hanno un limite molto rigoroso per la finestra e rifiutano i messaggi che superano il limite.

Come calcolare la formula ottimale della finestra di invio:

  • Misura la latenza massima tra SUBMIT_SM e SUBMIT_SM_RESP.

  • Moltiplica questo valore in secondi al throughput MT massimo. Questo darà il valore ottimale della finestra di invio.

Esempio: Se hai 300 SMS/s impostato nel throughput massimo di MT e c'è una latenza di 100 ms tra SUBMIT_SM e SUBMIT_SM_RESP in media, il valore ottimale sarebbe 300×0.1 = 30.

Velocità effettiva max MT

Numero massimo di MT al secondo e per connessione. Questa impostazione è rigorosamente applicata e l’MTA non invierà mai i messaggi push più velocemente di questo limite. È utile per i provider che richiedono una limitazione precisa.

Per conoscere il limite di throughput totale, moltiplica questo numero per il numero totale di connessioni come descritto nella formula precedente.

0 significa nessun limite, l'MTA invierà MT il più rapidamente possibile.

Si raccomanda generalmente di mantenere questa impostazione al di sotto di 1000, poiché è impossibile garantire un throughput preciso al di sopra di questo numero, a meno che non sia adeguatamente valutato sull'architettura finale. Se hai bisogno di un throughput superiore a 1000, contatta il tuo provider. Potrebbe essere meglio aumentare il numero di connessioni da superare 1000 MT/s.

Tempo prima della riconnessione

Quando la connessione TCP viene persa, il connettore attenderà questo numero di secondi prima di provare a effettuare una connessione.

Periodo di scadenza del MT

Timeout tra SUBMIT_SM e la sua corrispondenza SUBMIT_SM_RESP. Se la RESP non viene ricevuto in tempo, il messaggio verrà considerato come non riuscito e verranno applicati i criteri di esecuzione di nuovi tentativi globali dell’MTA.

Timeout del binding

Timeout tra il tentativo di connessione TCP e il BIND_*_RESP rispondi. Quando si verifica un timeout, la connessione viene chiusa dal connettore Adobe Campaign e attenderà Tempo prima di riconnettersi prima di riprovare.

enquire_link è un tipo speciale di PDU inviato per mantenere la connessione in vita. Questo periodo è in secondi. Il connettore della campagna invia solo enquire_link quando la connessione è inattiva per risparmiare larghezza di banda. Se non viene ricevuto alcun RESP dopo due volte questo periodo, la connessione verrà considerata morta e verrà attivato un processo di riconnessione.

Specifiche di SMSC

Queste impostazioni sono impostazioni avanzate che adattano il connettore Adobe Campaign alla maggior parte delle peculiarità di implementazione SMPP.

Definire una mappatura specifica delle codifiche

Consulta la sezione Codifica testo SMS per informazioni sulla codifica del testo.

Questa impostazione consente di definire una mappatura di codifica personalizzata, diversa dalla specifica. Sarà in grado di dichiarare un elenco di codifiche, insieme alle loro data_coding valore.

L’MTA tenterà di codificare utilizzando la prima codifica nell’elenco. In caso di errore, tenterà di utilizzare la codifica successiva nell’elenco, ecc. Se non è possibile utilizzare alcuna codifica per codificare il messaggio, si verifica un errore. Una volta trovata la codifica, l’MTA creerà l’ SUBMIT_SM PDU con il testo codificato e data_coding campo impostato con il valore specificato nella tabella.

L’ordine degli elementi nella tabella è importante: le codifiche sono tentativi dall'alto verso il basso. Inserite la codifica più economica o consigliata in cima all’elenco, seguita da codifiche sempre più costose.

Tieni presente che UCS-2 non avrà mai esito negativo in quanto può codificare tutti i caratteri supportati in Adobe Campaign e che la lunghezza massima di un SMS UCS-2 è molto inferiore: Solo 70 caratteri.

È inoltre possibile utilizzare questa impostazione per forzare l’utilizzo di una codifica specifica dichiarando una sola riga nella tabella di mappatura.

La mappatura predefinita utilizzata quando la casella di controllo non è selezionata equivale alla tabella seguente:

data_coding Codifica
0 GSM
9 UCS-2

This means that the MTA will try to encode the message in GSM. Se ha successo, lo invierà con data_coding impostato su 0.

If the message cannot be encoded in GSM, it will be encoded in UCS-2 and will set data_coding to 8.

Abilita message_payload

Se questa opzione è deselezionata, l’SMS lungo viene suddiviso dall’MTA e inviato in più SUBMIT_SM PDUs con UDH. Il messaggio sarà ricomposto dal cellulare in base ai dati UDH.

Se questa opzione è selezionata, l’SMS lungo verrà inviato in una delle PDU SUBMIT_SM, inserendo il testo nel campo opzionale message_payload . Consulta la sezione Specifiche SMPP per ulteriori dettagli.

If this feature is enabled, Adobe Campaign will be unable to count SMS parts individually: all messages will be counted as sent in one part.

Invia il numero di telefono completo

Quando questa casella di controllo non è selezionata, vengono inviate al provider solo le cifre del numero di telefono (destination_addr campo SUBMIT_SM (campo). Questo è il comportamento predefinito, in quanto l’indicatore del numero internazionale, solitamente un prefisso +, viene sostituito dai campi TON e NPI in SMPP.

Quando la casella di controllo è selezionata, il numero di telefono viene inviato così com'è, senza pre-elaborazione e spazi potenziali, + prefisso o cancelletto/hash/stella segni.

Questa funzione ha anche un effetto sul comportamento della funzione di elenco Bloccati di risposta automatica: se la casella di controllo non è selezionata, ai numeri di telefono inseriti nella tabella di quarantena verrà aggiunto un prefisso + per compensare la rimozione del prefisso + dal numero di telefono da parte del protocollo SMPP stesso.

Ignora controllo certificato TLS

Quando TLS è abilitato, salta tutti i controlli sui certificati.

Quando questa opzione è selezionata, la connessione non è più sicura e non deve essere abilitata in produzione.

Può essere utile a scopo di debug o test.

Bind TON/NPI

TON (Tipo di numero) e NPI (Indicatore del piano di numerazione) descritti al punto 5.2.5 del Specifiche di SMPP 3.4 (pagina 117). Questi valori devono essere impostati in base alle esigenze del provider.

Sono trasmessi così come sono addr_ton e addr_npi campi della PDU BIND.

Intervallo indirizzi

Inviato come nel campo address_range della PDU BIND. Questo valore deve essere impostato su qualsiasi esigenza del provider.

Numero di riconoscimenti ID non valido

Limita il numero di ID messaggio non valido DELIVER_SM_RESP che può essere inviato per un singolo SR.

Deve essere utilizzato solo per la risoluzione dei problemi come soluzione alternativa e impostato su 0 in condizioni normali.

Esempio Fox, quando si imposta su 2:

  • Il provider invia un SR (DELIVER_SM) con ID "1234".

  • Impossibile trovare l'ID "1234" nel database.

  • Il connettore conta 1 ID non valido errore per l'ID, quindi invia DELIVER_SM_RESP con il codice di errore "ID messaggio non valido" (comportamento normale).

  • Il provider prova lo stesso SR con ID "1234".

  • Impossibile trovare l'ID "1234" nel database.

  • Il connettore conta 2 ID non valido errore per l'ID, quindi invia DELIVER_SM_RESP "OK", anche se non è stato elaborato correttamente.

  • Questa funzione è destinata a svuotare i buffer SR sul lato del provider quando un blocco SR non valido è legittimo che i messaggi non possano essere elaborati.

L'impostazione di questo campo su 0 disattiva il meccanismo in cui ID messaggio non valido viene sempre restituito, si tratta di un comportamento normale.

Impostando questo campo su 1, il connettore risponde sempre "OK" anche se l’ID non è valido. Questo valore deve essere impostato su 1 solo sotto controllo, per la risoluzione dei problemi e per il periodo minimo di tempo, ad esempio per recuperare da un problema sul lato del fornitore.

Regex di estrazione dell’ID nell’SR

Il formato SR non è rigorosamente applicato dalla specifica del protocollo SMPP. Si tratta solo di una raccomandazione descritta in Appendice B (pagina 167) del disciplinare. Alcuni implementatori SMPP formattano questo campo in modo diverso, pertanto Adobe Campaign ha bisogno di un modo per estrarre il campo corretto.

Per impostazione predefinita, acquisisce fino a 10 caratteri alfanumerici dopo id:.

Il regex deve avere esattamente un gruppo di cattura con una parte contenuta tra parentesi. Le parentesi devono circondare la parte ID. Il formato regex è PCRE.

Quando regoli questa impostazione, accertati di includere il maggior numero possibile di contesti per evitare falsi attivatori. In presenza di prefissi specifici, ad esempio id: nello standard, includerli nel regex. Utilizza anche il più possibile i delimitatori di parole (\b) per evitare di acquisire testo al centro di una parola.

L'assenza di un contesto sufficiente nel regex può introdurre un piccolo difetto di sicurezza: il contenuto effettivo del messaggio può essere incluso nell'SR. Se incontri solo un formato ID specifico senza contesto, ad esempio un UUID, potrebbe essere l’analisi del contenuto di testo effettivo, ad esempio un UUID incorporato nel campo di testo, invece dell’ID.

Regex applicato per determinare lo stato riuscito/errore

Quando si incontrano messaggi con una combinazione di campi stat/err sconosciuta, questi regex vengono applicati sul campo stat per determinare se l’SR è stato un successo o un errore. L’SR con valori stat che non corrispondono a nessuno di questi regex viene ignorato.

Per impostazione predefinita, i valori stat che iniziano con DELIVad esempio DELIVRD in Appendice B, verrà considerato come consegnato con successo e tutti i valori stat che corrispondono a errori, ad esempio REJECTED, UNDELIV, sono considerati errori.

Formato ID nella convalida MT

Indica il formato dell'ID restituito nella message_id campo SUBMIT_SM_RESP PDU.

  • Non modificare: L’ID viene memorizzato come testo con codifica ASCII nel database. Non si verifica alcuna pre-elaborazione o filtraggio.

  • Numero decimale: L'ID deve essere un numero decimale in formato ASCII. Gli spazi iniziali e finali e gli zeri iniziali vengono rimossi quando si utilizza questa impostazione.

  • Numero esadecimale: L'ID deve essere un numero esadecimale in formato ASCII, senza l'iniziale 0x o h finale. L'ID viene quindi convertito in un numero decimale prima di essere memorizzato nel database.

  • Stringa esadecimale: L’ID deve essere un testo con codifica ASCII che è a sua volta una stringa di byte codificati come esadecimale. Ad esempio, nella PDU troverai 0x34 0x31 0x34 0x32 0x34 0x33, che si traduce in ASCII "414243". Questa stringa viene quindi decodificata come stringa esadecimale di byte e si ottiene "ABC" come risultato: memorizzerai l'ID "ABC" nel database.

Formato ID in SR

Indica il formato dell'ID acquisito dal Extraction regex dell'ID nell'SR. I valori hanno lo stesso significato e lo stesso comportamento del formato in MT sopra.

ID SR o codice di errore nel campo opzionale

If checked, the content of optional fields will be appended to the text processed by regexes above. The text will have the format 0xTAG:VALUE, 0xTAG being the 4-digit hexadecimal value of the tag in upper case e.g. 0x002E.

For example, you might want to capture the ID in the receipted_message_id field. A questo scopo, abilita questa casella di controllo e il seguente testo verrà aggiunto allo stato :

0x001E:05e3299e-8d37-49d0-97c6-8e4fe60c7739

In questo esempio, 0x001E è il tag del campo facoltativo e l’UUID è il valore del campo.

In order to capture this value, you may now set the following regex in the Extraction regex of the ID in the SR field:

\b0x001E:([0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12})\b
IMPORTANTE

You can only capture optional fields that have text (ASCII/UTF-8) values. In particolare, i campi binari non possono essere acquisiti in modo affidabile con il sistema regex corrente.

ID SR o codice di errore nel campo di testo

Se selezionato, il Testo Il campo viene mantenuto durante l'elaborazione del testo dello stato dell'SR.

Questa opzione è utile se il provider inserisce dati importanti in questo campo, come l’ID o lo stato . Di solito questo campo può essere ignorato in modo sicuro, poiché potrebbe contenere testo con una codifica non ASCII e interrompere l’elaborazione regex.

L’abilitazione di questa opzione può presentare un difetto di sicurezza molto piccolo se la Extraction L'espressione regex dell'ID nel campo SR non è sufficientemente specifica. Il contenuto del Testo Il campo può essere analizzato come ID e un autore dell’attacco può usarlo per inserire ID falsi, il che può causare una parziale negazione della situazione del servizio.

ID servizio

Consente di aggiungere un TLV personalizzato. Questo campo imposta la porzione di tag. Il valore può essere personalizzato per consegna nel ID servizio o programma nei parametri avanzati della consegna.

Questa impostazione consente di aggiungere solo un’opzione TLV per messaggio.

NOTA

A partire dalla versione 21.1, è ora possibile aggiungere più di un parametro opzionale. Per ulteriori informazioni, consulta questa sezione.

Risposta automatica inviata al MO

Questa funzione consente di rispondere rapidamente al testo su MO e di gestire l’invio di codice per breve tempo al elenco Bloccati.

La Parola chiave e Codice breve Le colonne definiscono le condizioni per attivare la risposta automatica. Se entrambi i campi corrispondono, viene inviato l’MO e viene attivata l’azione aggiuntiva. Per specificare un carattere jolly, lasciare vuoto il campo . Parola chiave corrisponde alla prima parola alfanumerica nel testo M, ignorando la punteggiatura e gli spazi iniziali. Significa che Parola chiave Il campo non può contenere spazi e deve essere una sola parola.

La Parola chiave è un prefisso. Ad esempio, se specifichi "AD", corrisponderà a "AD", "ADAPT" e "ADOBE". Se si dispone di più parole chiave con un prefisso comune, è necessario prestare attenzione all'ordine in quanto le parole chiave vengono elaborate dall'alto verso il basso.

La Rispondi Il testo da rispondere è column . In questo campo non è disponibile alcuna personalizzazione. Se lasci vuoto questo campo, non verrà risposto alcun messaggio, ma verrà comunque attivata l’azione aggiuntiva.

La Azione aggiuntiva La colonna fornisce un’azione aggiuntiva quando entrambe Parola chiave e Codice breve Il codice breve vuoto corrisponde a tutti i codici brevi. È possibile mettere in quarantena o rimuovere dalla quarantena, il valore nessuna risponde al testo. Se specifichi un Azione aggiuntiva ma lascia la Rispondi campo vuoto, l’azione verrà eseguita ma non verrà inviata alcuna risposta. La quarantena viene applicata solo al codice breve specificato o a tutti i codici brevi se il campo viene lasciato vuoto.

IMPORTANTE

L'impostazione di invio del numero di telefono completo ha un impatto sul comportamento del meccanismo di quarantena di risposta automatica: se l'invio del numero di telefono completo non è controllato, il numero di telefono messo in quarantena sarà preceduto da un segno più ("+") per renderlo compatibile con il formato del numero di telefono internazionale.

Tutte le voci nella tabella vengono elaborate nell’ordine specificato, fino a quando non corrisponde una regola. Se più regole corrispondono a un MO, verrà applicata solo la regola più in alto.

Parametri opzionali di risposta automatica (TLV)

A partire dalla versione 21.1, è possibile aggiungere parametri facoltativi alla risposta automatica MT. Vengono aggiunti come parametri TLV facoltativi al SUBMIT_SM PDU della risposta, come descritto nella sezione 5.3 del Specifiche SMPP(pagina 131).

Per ulteriori informazioni sui parametri facoltativi, consulta questo sezione.

Parametri del modello di consegna SMS

Alcuni parametri possono essere impostati per modello di consegna.

Campo Da

Questo campo è facoltativo. Consente di ignorare l’indirizzo del mittente (oADC). Il contenuto di questo campo viene inserito nella source_addr campo SUBMIT_SM PDU.

Il campo è limitato a 21 caratteri dalla specifica SMPP, ma alcuni provider potrebbero consentire valori più lunghi. Tieni presente che in alcuni paesi possono essere applicate restrizioni molto rigorose, ad esempio lunghezza, contenuto e caratteri consentiti.

Parametri di consegna

Numero massimo di SMS per messaggio

Questa impostazione funziona solo se Payload messaggio è disabilitata. Per ulteriori informazioni, consulta questo page. Se il messaggio richiede più SMS di questo valore, viene attivato un errore.

Il protocollo SMS limita gli SMS a 255 parti, ma alcuni telefoni cellulari hanno problemi a mettere insieme messaggi lunghi con più di 10 parti o giù di lì, il limite dipende dal modello esatto. Ti consigliamo di non passare oltre 5 parti per messaggio.

A causa del funzionamento dei messaggi personalizzati in Adobe Campaign, le dimensioni dei messaggi possono variare. Avere una grande quantità di messaggi lunghi potrebbe aumentare i costi di invio.

Modalità di trasmissione

Questo campo indica il tipo di SMS che desideri trasferire: messaggi normali o flash, memorizzati sul cellulare o sulla scheda SIM.

Questa impostazione viene trasmessa nella dest_addr_subunit campo opzionale nel SUBMIT_SM PDU.

  • Non specificato non invia alcun campo facoltativo nella PDU.

  • Flash imposta il valore su 1. Invia un messaggio Flash che compare sul dispositivo mobile e non viene memorizzato in memoria.

  • Normale imposta il valore su 0. Invia un messaggio normale.

  • Salva su dispositivi mobili imposta il valore su 2. Indica al telefono di memorizzare l’SMS nella memoria interna.

  • Salva sul terminale imposta il valore su 3. Dice al telefono di memorizzare l'SMS nella scheda SIM.

Periodo di validità

Il periodo di validità è trasmesso nel validity_period campo SUBMIT_SM PDU. La data viene sempre formattata come formato ora UTC assoluto (il campo data termina con "00+").

Parametri opzionali SMPP (TLV)

A partire dalla versione 21.1, puoi aggiungere più parametri facoltativi a ogni MT inviato per questa consegna. Questi parametri facoltativi vengono aggiunti al SUBMIT_SM PDU della risposta, come descritto nella sezione 5.3 del Specifiche SMPP(pagina 131).

Ogni riga della tabella rappresenta un parametro facoltativo:

  • Parametro: Descrizione del parametro . Non trasmessa al provider.
  • ID tag: Tag del parametro facoltativo. Deve essere esadecimale valido, in formato 0x1234. Valori non validi causeranno un errore di preparazione della consegna.
  • Valore: Valore del campo facoltativo. Codificato come UTF-8 quando viene trasmesso al provider. Impossibile modificare il formato di codifica, non è possibile inviare valori binari o utilizzare codifiche diverse come UTF-16 o GSM7.

Se un parametro opzionale ha lo stesso ID tag come ID del servizio definito nell’account esterno, prevalgerà il valore definito in questa tabella.

Connettore SMPP

Le frecce rappresentano il flusso di dati.

La cosa più importante da notare qui è che ci sono più thread di connettore SMPP. Questi thread sono tutti identici e condividono la stessa configurazione. Ecco perché il numero di connessioni viene sempre moltiplicato per il numero di thread.

Il numero di thread non può essere modificato dal cliente perché richiede la modifica dei file di configurazione.

Descrizione del comportamento del connettore SMPP

Voci MT, SR e broadlog corrispondenti

In Adobe Campaign, un messaggio è una voce di registro di trasmissione. In Adobe Campaign Standard, i connettori esterni devono solo conoscere la tabella del registro di trasmissione funzionante: nmsBroadLogExec. Un flusso di lavoro ha il compito di copiare le voci del registro di trasmissione alle loro dimensioni di targeting specifiche (nmsBroadLogXXX).

Sfortunatamente, SMPP non consente di inviare un ID insieme a un messaggio: il provider fornisce un ID MT a ogni MT, quindi uno o più SR con lo stesso ID.

L'ID fornito dal provider viene memorizzato nel sProviderId colonna nmsBroadLogExec tabella. SR arriva sempre dopo che il MT è stato inviato e riconosciuto con successo, ma a volte può arrivare fuori ordine, noto in Adobe Campaign come SR eccezionale. Il thread di elaborazione memorizza temporaneamente questi SR nella RAM fino all'arrivo delle informazioni complete.

Quando viene riconosciuto un MT (SUBMIT_SM_RESP), sProviderId viene aggiornato immediatamente nel database.

Ogni SR viene elaborato singolarmente dai thread di elaborazione SMPP. Questo processo è pseudo-sincrono: viene visto come sincrono dall’esterno, ma implementato internamente con implementazioni basate su eventi. L'SR viene riconosciuto solo quando il registro di trasmissione è stato aggiornato correttamente, se si verifica un errore, l'SR viene rifiutato.

Ecco il processo applicato a ciascun SR:

  • L'ID dell'SR viene estratto utilizzando un regex.
  • L'ID viene ricercato in nmsBroadLogExec:sProviderId.
  • Il codice di errore + stato viene estratto dall’SR utilizzando regexes.
  • Il meccanismo dei messaggi del registro di trasmissione viene utilizzato per qualificare l'errore e trovare l'ID del messaggio del registro di trasmissione.
  • Il registro di trasmissione viene aggiornato con tutte le informazioni di cui sopra.
  • La SR è riconosciuta.

La verifica dei passaggi precedenti richiede Abilita tracce SMPP dettagliate per verificare manualmente che tutti i passaggi siano correttamente applicati. Questo è necessario ogni volta che Adobe Campaign è connesso a un nuovo provider SMPP.

Prima di andare in diretta

Questa lista di controllo fornisce un elenco degli elementi da controllare prima di essere live. Una configurazione incompleta può causare molti problemi.

Verifica conflitti di account esterni

Verifica di non disporre di vecchi account esterni SMS. Se l'account di test viene disattivato, correte il rischio che venga riabilitato nel sistema di produzione e generato potenziali conflitti.

Verifica che nessun'altra istanza si connette a questo account. In particolare, assicurati che l’ambiente stage non si connetta all’account. Alcuni provider lo supportano, ma richiede una configurazione molto specifica sia sul lato Adobe Campaign che sulla piattaforma del provider.

Se è necessario avere più account sulla stessa istanza di Adobe Campaign che si connettono allo stesso provider, contatta il provider per assicurarti che distinguano effettivamente le connessioni tra questi account. Disporre di più account con lo stesso accesso richiede una configurazione aggiuntiva.

Abilita tracce SMPP dettagliate durante i controlli

È sempre necessario abilitare tracce SMPP dettagliate durante i controlli.
Anche se non riesci a controllare i registri da solo, sarà più semplice per il supporto aiutarti.

Test dell’SMS

  • Invia SMS con tutti i tipi di caratteri
    Se devi inviare SMS con caratteri non GSM o non ASCII, prova a inviare alcuni messaggi con il maggior numero possibile di caratteri diversi. Se imposti una tabella di mappatura dei caratteri personalizzata, invia almeno un SMS per tutti i possibili
    data_coding values.

  • Verificare che SR sia elaborato correttamente
    L’SMS deve essere contrassegnato come ricevuto nel registro di consegna. Il registro di consegna deve avere esito positivo ed essere simile al seguente: Verifica di aver modificato il nome del provider di consegna. Il registro di consegna non deve mai contenere SR yourProvider stat=DELIVRD err=000|#MESSAGE
    Verifica di aver modificato il nome del provider di consegna. Il registro di consegna non deve mai contenere Generico SR in ambienti di produzione.

  • Verificare che la funzione MO sia elaborata
    Se è necessario elaborare MO (risposte automatiche, archiviazione MO nel database, ecc.) prova a fare alcuni test. Invia qualche SMS per tutte le parole chiave di risposta automatica e controlla se la risposta è abbastanza veloce, non più di pochi secondi.
    Controlla nel registro che Adobe Campaign risponda con successo
    DELIVER_SM_RESP (command_status=0).

Controllare le PDU

Anche se i messaggi sembrano di successo, è importante verificare che le PDU siano formattate correttamente.

Questo passaggio è necessario quando ci si connette a un provider che non era collegato ad Adobe Campaign in precedenza.

DIETRO

Controlla che BIND_* PDUs sono inviate correttamente. La cosa più importante da verificare è che il provider restituisce sempre successo BIND_*_RESP PDUs (command_status = 0).

Controlla che non ci siano troppi BIND_* PDUs. Se ce ne sono troppi, potrebbe indicare che la connessione è instabile. Consulta la sezione Problemi con connessioni instabili per ulteriori informazioni.

Controlla che ENQUIRE_LINK PDUs sono scambiati regolarmente quando la connessione è inattiva.

SUBMIT_SM / DELIVER_SM

Invia un messaggio, quindi cerca nei registri il relativo SUBMIT_SM, SUBMIT_SM_RESP, DELIVER_SM e DELIVER_SM_RESP PDUs.

Con la SUBMIT_SM PDU:

  • Controlla che data_coding è corretto, 0 per impostazione predefinita.
  • Controlla che short_message è codificato correttamente. Prova a decodificarlo utilizzando un convertitore esadecimale che supporta più codifiche.

Con la SUBMIT_SM_RESP PDU:

  • Verificare che sia stato eseguito correttamente, command_status = 0.
  • Verificare che il corpo contenga un ID formattato correttamente seguito da un byte '0'.

Con la DELIVER_SM PDU:

  • Decodificare l'esadecimale short_message campo .
  • Controlla con uno strumento di controllo regex che il regex definito in Extraction L'espressione regex dell'ID nell'SR restituisce esattamente un gruppo di acquisizione e acquisisce l'intero ID nel messaggio.
  • Verifica che l'ID estratto corrisponda a quello in SUBMIT_SM_RESP.
  • Controlla che il regex sia definito in Extraction regex dello stato nell'SR restituisce il contenuto del campo stat.
  • Controlla che il regex sia definito in Extraction Il regex dell'errore nell'SR restituisce il contenuto del campo err.

Con la DELIVER_SM_RESP PDU:

  • Verifica che sia stato inviato rapidamente dopo la ricezione del DELIVER_SM PDU, generalmente inferiore a 1 secondo.
  • Verificare che sia stato eseguito correttamente, command_status = 0.

Chiedi al provider se tutto va bene

Anche se l’SMS ha esito positivo, contatta il provider per vedere se tutto è in ordine.

Disattiva tracce SMPP dettagliate

Una volta completati tutti i controlli, l'ultima cosa è Disattiva tracce SMPP dettagliate per non generare troppi registri. Puoi riabilitarli per la risoluzione dei problemi anche sui sistemi di produzione.

In questa pagina