Protokoll och inställningar för SMS-koppling sms-connector-protocol

Översikt overview

SMS kan vara begränsat till att skicka korta textmeddelanden utan formatering, men enkelheten gör det till en värdefull kommunikationskanal.

Det finns två sätt att skicka ett SMS:

I det här dokumentet får du hjälp med att skapa en anslutning mellan Adobe Campaign och en SMPP-leverantör.

SMPP-leverantörer kan ibland avvika från den officiella specifikationen, men SMS-kopplingen i Adobe Campaign erbjuder många alternativ för att anpassa sitt beteende så att det blir kompatibelt med de flesta leverantörer.

SMS-typer sms-types

När du skickar SMS via en SMS-leverantör kommer du att stöta på tre olika typer av SMS:

Du måste skilja mellan bekräftelser (RESP PDU, som ingår i SMPP-protokollet) och SR: SR är en typ av SMS som skickas via nätverket från början till slut, medan en bekräftelse bara är en bekräftelse på att en överföring har lyckats.

Både bekräftelser och SR kan utlösa fel, och om man skiljer mellan dem blir det lättare att felsöka.

Information som medförs av ett sms information-sms

Ett SMS innehåller mer information än text. Här följer en lista över vad du kan förvänta dig i ett SMS:

SMPP-protokoll smpp-protocol

Adobe Campaign Standard stöder SMPP-protokollversion 3.4. Detta är ett utbrett protokoll som tillåter att SMS skickas till en leverantör (SMSC) och tar emot både SMS och kvitton. Mer information finns i SMPP-dokumentation.

Nätverksutrustningen på SMS-tjänstleverantörens sida kallas ofta SMSC.

SMPP-anslutningar smpp-connections

Adobe Campaign ansluter till SMS-tjänstleverantörens nätverksutrustning via TCP. SMPP-protokollet anger permanenta TCP-anslutningar från Adobe Campaign till providern. TCP-anslutningar initieras alltid av Adobe Campaign, även för att ta emot meddelanden.
SMPP öppnar 1 eller 2 TCP-anslutningar, beroende på läge. Alla anslutningar initieras alltid av Adobe Campaign.

SMPP-protokollet kan fungera i två lägen:

SMPP PDU smpp-pdu

SMPP-överföringsenheter ("paket") kallas PDU. A PDU innehåller ett kommando, en status, ett sekvensnummer och data.

Varje PDU måste bekräftas av en SMPP RESP PDU (synkront svar). Förfrågningar kan vara i pipeline: avsändaren kan skicka många kommandon utan att vänta på RESPkallas dock fönstret för det antal begäranden som när som helst kan röras. RESP PDU kan anlända i vilken ordning som helst, oavsett ordningen på PDU:n för initieraren.

I den separerade Sändare+mottagare vilket läge som används beror på vilken typ av meddelande som skickas. Sändaranslutningen används för MT och mottagaranslutningen används för MO och SR. Begäranden och svar för varje typ av meddelande skickas via samma TCP-anslutning.

När du skickar ett MT-meddelande används till exempel sändaranslutningen och RESP som bekräftar att MT också skickas via sändningskanalen. När du tar emot ett flerlägesobjekt (eller ett SR) används mottagaranslutningen för att ta emot flerlägesobjektet och skicka RESP som bekräftar marknadschefen.

I Adobe Campaign Standard är MT och SR-avstämningen inbyggd i MTA, så det finns ingen dedikerad SMS-process.

Slutförd SUBMIT_SM_RESP PDU utlöser statusen för skickat meddelande i den sändande loggen när ett DELIVER_SM (SR) PDU utlöser statusen för mottaget meddelande.

Säkerhetsaspekter security-aspects

Själva protokollet är inte krypterat. De flesta leverantörer implementerar en variant av IP på tillåtelselista så att Adobe Campaign server-IP-adresserna måste deklareras till providern.

Adobe Campaign har stöd för att skicka inloggningar och lösenord under bindningsfasen. Det har även stöd för SMPP över TLS. Det bör noteras att certifikat krävs för att säkerheten ska vara god. Även om SMPP-kopplingen tillåter att certifikatkontroller kringgås, bör den bara användas för testning eftersom TLS utan certifikat ger en betydligt lägre säkerhetsnivå.

Kopplingen använder standardcertifikaten som tillhandahålls av systemet openssl bibliotek. Vanligtvis tillhandahålls det av /etc/ssl/certs på Debian. Den här katalogen tillhandahålls som standard av paketet"ca-certificates", men det kan anpassas.

Information i varje typ av PDU information-pdu

Varje typ av PDU har olika fält som innehåller olika information. Den här PDU:n finns i Specifikation för SMPP 3.4.

Varje avsnitt nedan beskriver både PDU:n och dess synkrona svar (*_RESP PDU). Alla PDU måste bekräftas med en motsvarande RESPär detta en obligatorisk del av specifikationen.

PDU:er kan ha valfria fält. Här beskrivs bara de vanligaste fälten. Se Specifikation för SMPP 3.4 för mer information.

BIND_TRANSMITTER / BIND_RECEIVER / BIND_TRANSCEIVER bind-transmitter

Denna PDU används för att initiera en anslutning till SMSC. Sändare, Mottagare och Mottagare ändrar endast den typ av SMS som får överföras via den här anslutningen:

Anteckningsbara fält i en BIND_* PDU:

BIND_*_RESP har inget specifikt fält, det bekräftar om anslutningen lyckades eller inte.

UNBIND unbind

Den här PDU:n måste skickas av systemet innan den kopplas från. Det måste vänta på matchningen UNBIND_RESP PDU innan du stänger anslutningen.

Om SMSC konfigureras får anslutningen inte stängas, TCP-anslutningen styrs av Adobe Campaign-anslutningen.

SUBMIT_SM submit-sm

Denna PDU skickar en MT till SMSC. Dess PDU för svar ger ID:t för MT.

Anteckningsbara fält i en SUBMIT_SM PDU:

Adobe Campaign har stöd för följande valfria fält:

SUBMIT_SM_RESP submit-sm-resp

Den här PDU:n kommer att innehålla ID:t för MT:n. Detta är användbart för att matcha det med inkommande SR.

Vissa leverantörer skickar SUBMIT_SM_RESP efter att SR har skickats. För att ta hänsyn till detta väntar Adobe Campaign 30 sekunder innan det svarar Ogiltigt meddelande-ID till en SR med ett okänt ID.

DELIVER_SM delivery-sm

Denna PDU skickas av SMSC till Adobe Campaign. Den innehåller antingen en enkel inloggning eller en SR.

De flesta fält har samma betydelse SUBMIT_SM motpart. Här är en lista med användbara fält:

Adobe Campaign kan läsa meddelande-ID i receipted_message_id valfritt fält med viss konfigurationsinställning.

DELIVER_SM_RESP deliver-sm-resp

Denna PDU skickas av Adobe Campaign för att bekräfta SR och MO.

Adobe Campaign Standard skickar bara DELIVER_SM_RESP när alla bearbetningssteg har slutförts. Detta garanterar att inga SR- eller MO-åtgärder erkänns, även om det fortfarande finns risk för fel i behandlingen.

INQUIRE_LINK enquire-links

Denna PDU används bara för att kontrollera att anslutningen är aktiv. Dess frekvens bör fastställas efter leverantörens behov.

Standardvärdet på 60 sekunder bör matcha de flesta konfigurationer som angetts för det externa kontot.

INQUIRE_LINK_RESP enquire-links-resp

Den här PDU:n bekräftar att anslutningen lever.

Multipart SMS (long SMS) multipart

Multipart SMS, eller lång SMS, är SMS som skickas i flera delar. På grund av tekniska begränsningar i mobilnätverksprotokollet kan ett SMS inte vara större än 140 byte, annars måste det delas. Se SMS-textkodning om du vill veta mer om hur många tecken som får plats i ett SMS.

Varje del av ett långt meddelande är ett individuellt SMS. Dessa delar är oberoende av varandra på nätet och har monterats av den mottagande mobiltelefonen. För att hantera återförsök och anslutningsproblem skickar Adobe Campaign dessa delar i omvänd ordning och begär en SR endast i den första delen av meddelandet, den sista som skickas. Eftersom mobiltelefonen bara visar ett meddelande när den första delen tas emot, kommer nya försök med ytterligare delar inte att skapa dubbletter på mobiltelefonen.

Det maximala antalet SMS per meddelande kan anges per leverans med Högsta antal SMS per meddelande i Leveransmall. Meddelanden som överskrider den här gränsen misslyckas när ett SMS skickas med en för lång felorsak.

Det finns två sätt att skicka långt SMS:

Se beskrivningen av esm_class, short_message och message_payload fälten i SUBMIT_SM PDU för mer information om protokoll och format.

Plattor och fönsterrutor throughput-capping

De flesta leverantörer kräver en genomströmningsgräns för varje SMPP-anslutning. Detta kan uppnås genom att ange ett antal SMS i det externa kontot. Observera att genomströmningsbegränsning inträffar per anslutning. Den totala effektiva genomströmningen är gränsen per anslutning multiplicerad med det totala antalet anslutningar. Detta beskrivs i Samtidiga anslutningar -avsnitt.

För att uppnå maximal genomströmning måste du finjustera det maximala sändningsfönstret. Det sändande fönstret är antalet SUBMIT_SM PDUsom kan skickas utan att vänta på en SUBMIT_SM_RESP. Se Inställning för sändningsfönster för mer information.

SR och felhantering ("Bilaga B") sr-error-management

SMPP-protokollet definierar synkrona standardfel i RESP PDUs, men den definierar inte felkoder för SR. Varje provider använder sina egna felkoder med sin innebörd.

En rekommendation ges i avsnittet i tillägg B i SMPP-protokollspecifikation (sidan 167), men inte de faktiska felkoderna eller deras betydelse.

Adobe Campaign sändningsmeddelandesystem har anpassats till felhanteringen och har använts för att korrekt tillhandahålla fel och deras allvarlighetsgrad (hårdhet, mjuk osv.).

Som nämnts ovan finns det två olika typer av fel:

När en SR tas emot kan status och fel hittas i short_message fält (exempel för implementeringar enligt tillägg B). The short_message fältet i PDU:n kallas ofta textfält eftersom den innehåller text i MT. För SR innehåller den teknisk information plus ett delfält som heter Text. Dessa två fält är olika och short_message innehåller Text fält och annan information.

SR-textfältformat sr-text-field-format

Specifikationen rekommenderar att du använder det här formatet för SR-textfältet. Det är en lista med delfält, avgränsade med kolon, som avgränsar fältnamnet och dess värde. Fältnamn är inte skiftlägeskänsliga.

Exempel på ett SR-textfält som matchar rekommendationen i tillägg B:

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

ID-fältet är det ID som tas emot i SUBMIT_SM_RESP PDU, MT:s erkännande.

sub och dlvrd ska räkna ut mängden levererade delar och levererade meddelanden, men detta används inte av Adobe Campaign eftersom sändningssystemet ger bättre och mer integrerad information.

submit date och done date fält är indikativa tidsstämplar för när MT skickades och när SR skickades av mobilen. Förvänta dig problem med tidszoner eller till och med fel tidsstämplar från mobiler med felaktig datumuppsättning.

Statusfältet är viktigt eftersom det anger meddelandets status. Den enda viktiga statusen är DELIVRD, UNDELIV och REJECTD. The DELIVRD status anger att det lyckades, de andra två visar ett fel. Andra värden är möjliga, men de är vanligtvis mellanliggande meddelanden, t.ex. att MT nådde mobiltelefonen, men inte mobiltelefonen. Dessa mellanliggande meddelanden ignoreras av Adobe Campaign.

Felfältet innehåller den providerspecifika felkoden. Leverantören måste ge en tabell över möjliga felkoder tillsammans med deras betydelse för att kunna tolka det här värdet.

Slutligen innehåller textfältet vanligtvis början av texten i huvudfältet. Detta ignoreras av Adobe Campaign och vissa leverantörer skickar inte det för att undvika PII-läckage och bandbreddsförbrukning i nätverket. Den kan användas under felsökning för att identifiera SR-matchning av ett test MT enklare genom att läsa det här fältet.

Exempel på SR-bearbetning i Adobe Campaign Standard Extended allmän SMPP sr-processing

I det här exemplet visas fallet med en implementering som följer rekommendationerna i tillägg B, standardvärden i det externa kontot och ett godkänt SMS MT.

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

Först, id extraction regex används för att extrahera ID:t och stämma av det med motsvarande MT.

Sedan status extraction regex och error code extraction regex används för att extrahera dessa fält och läggs till i strängen.

Sändningsmeddelandet skapas med den här informationen och den ursprungliga oförändrade strängen läggs till som referens:

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

Meddelandet normaliseras sedan och MESSAGE-delen tas bort för att kunna matcha flera meddelanden med samma stat- och felkoder.

SR ExampleProvider DELIVRD 000|#MESSAGE#

Om meddelandet inte redan har etablerats i sändningsmeddelandetabellen skapas en ny post med hela meddelandet som firstText och det normaliserade meddelandet. Sedan använder kopplingen framgångarna och error regex för att avgöra om åtgärden lyckades eller misslyckades:

Som standard anges alla fel som mjuka fel. Det innebär att hårda fel måste tillhandahållas manuellt.

SMS-textkodning sms-text-encoding

Du borde kontakta alltid SMSC-leverantören vid kodningsproblem. Det är bara SMSC-leverantörerna som har exakta kunskaper om den kodning de stöder och särskilda regler som kan gälla på grund av begränsningar i deras tekniska plattform.

SMS-meddelanden använder en speciell 7-bitars kodning, som ofta kallas GSM7-kodning.

I SMPP-protokollet kommer GSM7-text att utökas till 8 bitar per tecken för enklare felsökning. SMSC paketerar det i 7 bitar per tecken innan det skickas till mobilen. Det innebär att short_message SMS-fältet kan vara upp till 160 byte långt i SMPP-bildrutan, medan det är begränsat till 140 byte när det skickas via mobilnätet.

I händelse av kodningsproblem finns det några viktiga saker att kontrollera:

The data_coding -fältet anger vilken kodning som används. Ett stort problem är att värdet 0 innebär standard-SMSC-kodning i specifikationen, som vanligtvis hänvisar till GSM7. Kontrollera med SMSC-partnern vilken kodning som är kopplad till data_coding = 0 som endast stöds av Adobe Campaign. Övriga data_coding värdena tenderar att följa specifikationen, men det enda sättet att vara säker är att kontrollera med SMSC-leverantören.

Den största tillåtna storleken för ett meddelande beror på dess kodning. I denna tabell sammanfattas all relevant information:

SMPP:s externa kontoparametrar SMPP-parameters-external

Varje implementering av SMPP-protokollet har många variationer. För att förbättra kompatibilitet och anpassningsbarhet finns det många inställningar som du kan använda för att ändra SMPP-anslutningens beteende. I det här avsnittet beskrivs alla parametrar och dess effekter på kopplingen.

Allmänna parametrar och routning general-parameters-routing

Begränsa MTA-instanser för det här kontot

Det går att ange en gräns för hur många MTA-instanser som tillåts ansluta till SMPP-providern. När det här alternativet är markerat kan du ange hur många MTA som högst får användas.

Det här alternativet ger bättre kontroll över antalet anslutningar, se Samtidiga anslutningar.

Om du anger ett värde som är högre än antalet MTA:er som körs, körs alla MTA:er som vanligt: det här alternativet är bara en gräns och kan inte ange ytterligare MTA:er.

Om du behöver kontrollera exakt antalet anslutningar, t.ex. leverantörskrav, bör du alltid ange det här alternativet även om den aktuella distributionen har rätt antal MTA:er som körs. Om ytterligare MTA läggs till därefter kommer anslutningsgränsen fortfarande att gälla.

Anslutningsinställningar connection-settings

SMPP-anslutningsläge smpp-connection-mode

Anger anslutningen i sändtagare läge eller i separerat läge sändare+mottagare läge. När du växlar till separerad sändare+mottagare läge, inställningar i SMPP-anslutningsläge -avsnittet gäller för sändaren och inställningarna i Anslutningsinställningar för mottagare -avsnittet gäller endast för mottagaranslutningen om du har markerat Använd olika parametrar för mottagaren kryssrutan.

SMSC-implementeringsnamn smsc-implementation-name

Anger namnet på SMSC-implementeringen. Den ska anges med namnet på din leverantör. Kontakta administratören eller leveransgruppen om du vill veta vad du ska lägga till i det här fältet. Fältets roll beskrivs i SR-felhantering -avsnitt.

Server server

DNS-namnet eller IP-adressen för servern som ska anslutas.

Port port

Den TCP-port som anslutningen ska kopplas till.

Konto account

Anslutningens inloggning. Godkänd i system_id BIND PDU-fält.

Lösenord password

Lösenord för SMPP-anslutningen. Lösenordsfältet för BIND PDU har skickats.

Systemtyp system-type

Värdet som skickas i system_id BIND PDU-fält. Vissa leverantörer behöver ett specifikt värde här.

Samtidiga anslutningar simultaneous-connections

I Adobe Campaign Standard definieras antalet anslutningar per SMS-tråd och per MTA-process.
Antalet MTA-processer bestäms av distributionen: vanligtvis finns det 2 MTA och 1 tråd. Antalet trådar kan ändras i filen config-instance.xml med inställningen smppConnectorThreads. Vanligtvis finns det 1 MTA-process per behållare och 1 tråd per MTA-process.

Formel för totala anslutningar för Adobe Campaign Standard:

Samtidiga anslutningar anges i det externa kontot, antalet trådar anges i filen config-instance.xml (smppConnectorThreads) och antalet MTA:er kan begränsas i det externa kontot.

I separerad sändare/mottagare läge representerar antalet anslutningar ovan antalet sändare/mottagare par, vilket innebär att det totala antalet anslutningar blir dubbelt så stort.

Aktivera TLS över SMPP enable-TLS

Använd TLS för att ansluta till providern. Anslutningen kommer att krypteras. TLS-anslutningen hanteras av OpenSSL-biblioteket och allt som gäller OpenSSL kommer att vara sant för den här anslutningen.

Aktivera utförliga SMPP-spår i loggfilen enable-verbose-log-file

Den här inställningen dumpar all SMPP-trafik i loggfiler. Det krävs ofta att du justerar parametrar under den inledande konfigurationen. Detta måste vara aktiverat vid felsökning av anslutningen och jämfört med den trafik som leverantören ser.

Inställning för mottagaranslutning receiver-connection

Det här avsnittet är bara synligt i separerad sändare+mottagare läge.

Använd olika parametrar för mottagaren receiver-parameters

När rutan är avmarkerad används samma inställningar för sändare och mottagare.

När rutan är markerad finns inställningarna i Anslutningsinställningar -avsnittet gäller för sändare och inställningarna i Mottagaranslutning inställningarna gäller för mottagaren.

Mottagarserver, port, konto, lösenord, systemtyp

De här inställningarna gäller för mottagaren i sändare+mottagare läge. De fungerar som sändningsdelen, se ovan för mer information.

SMPP-kanalinställningar smpp-channel-settings

Tillåt teckenomläsning allow-character-transliteration

Translitterering är processen att hitta tecken som är likvärdiga med dem som saknas. Det franska specialtecknet"ê" (e med cirkumflex) saknas till exempel i GSM-kodningen, men det kan ersättas med"e" utan att det försämrar läsbarheten.

När den här rutan är avmarkerad misslyckas textkodningen om strängen inte kan kodas exakt som den är.

När den här rutan är markerad försöker textkodningen att konvertera strängen till en ungefärlig version i stället för att misslyckas. Om vissa tecken inte har någon motsvarighet i målkodningen kommer textkodningen att misslyckas.

Se Definiera en specifik mappning av kodningsinställningen för en mer allmän förklaring av kodningsprocessen.

Lagra inkommande MO i databasen incoming-mo-storing

När det här alternativet är aktiverat lagras inkommande MO i databastabellen inSMS. Tabellen kan frågas med hjälp av frågeaktiviteten i vilket arbetsflöde som helst.

Aktivera KPI-uppdateringar i realtid under SR-bearbetning real-time-kpi

När det här alternativet är aktiverat uppdateras KPI:er i realtid på huvudleveranssidan när fel-SR tas emot.

Nackdelen kan vara låg på grund av den databaskonflikt som genereras. Om det är inaktiverat uppdateras statistiken av syncfromexec arbetsflöde, körs var 20:e minut.

Källnummer source-number

Definierar standardkälladressen för meddelanden. Den här inställningen gäller endast om källnumret inte har angetts i leveransen.

Som standard skickas inte fältet för källnummer, så providern ersätter det för den korta koden.

Detta aktiverar funktionen för åsidosättning av avsändaradress/ADC.

Kort kod short-code

Anger kontots kortnummer. Om flera korta koder används för det här kontot eller om den korta koden är okänd lämnar du det här fältet tomt.

Det kan vara praktiskt att ange kort kod för två funktioner:

Käll-TON/NPI, mål-TON/NPI ton-npi

TON (typ av nummer) och NPI (Numreringsplansindikator) beskrivs i avsnitt 5.2.5 i Specifikation för SMPP 3.4 (sidan 117). Dessa värden ska ställas in efter providerns behov.

De överförs som de är source_addr_ton, source_addr_npi, dest_addr_ton och dest_addr_npi fälten i SUBMIT_SM PDU.

Tjänsttyp service-type

Det här fältet överförs som det är i service_type fält för SUBMIT_SM PDU. Ange detta efter leverantörens behov.

Genomströmning och timeout throughput-timeouts

Dessa inställningar styr alla timingaspekter av SMPP-kanalen. Vissa leverantörer kräver mycket exakt kontroll över meddelandehastighet, fönster och tidsinställningar för nya försök. Dessa inställningar bör anges till värden som matchar leverantörens kapacitet och villkoren som anges i deras kontrakt.

Skickar fönster sending-window

Fönstret är antalet SUBMIT_SM PDUs som kan skickas utan att vänta på matchning SUBMIT_SM_RESP.

Exempel på en överföring med ett maximalt fönster på 4:

Fönstret hjälper till att öka genomströmningen när nätverkslänken har hög latens. Fönstrets värde måste vara minst det antal SMS/s som multipliceras med länkens fördröjning i sekunder så att kopplingen aldrig väntar på en SUBMIT_SM_RESP innan du skickar nästa meddelande.
Om fönstret är för stort kan du skicka fler dubblettmeddelanden om det uppstår anslutningsproblem. Dessutom har de flesta leverantörer en mycket strikt begränsning för fönstret och vägrar att skicka meddelanden som överskrider gränsen.

Så här beräknar du den optimala skicka-fönsterformeln:

Exempel: Om du har 300 SMS/s angivet i maximalt MT-genomströmning och det finns 100 ms latens mellan SUBMIT_SM och SUBMIT_SM_RESP i genomsnitt är det optimala värdet 300×0.1 = 30.

Maximal MT-genomströmning max-mt-throughput

Maximalt antal MT per sekund och anslutning. Den här inställningen används strikt, MTA skickar aldrig meddelanden snabbare än den här gränsen. Det är användbart för leverantörer som kräver exakt begränsning.

Om du vill veta vilken total dataflödesgräns du har multiplicerar du talet med det totala antalet anslutningar enligt formeln ovan.

0 betyder ingen gräns, MTA skickar MT så snabbt som möjligt.

Det rekommenderas i allmänhet att denna inställning hålls under 1000, eftersom det är omöjligt att garantera exakt dataflöde över detta värde om inte korrekt riktmärkning av den slutliga arkitekturen har gjorts. Om du behöver ett dataflöde över 1 000 kontaktar du din leverantör. Det kan vara bättre att öka antalet anslutningar så att de överstiger 1000 MT/s.

Tid före återanslutning time-reconnection

När TCP-anslutningen bryts väntar anslutningen i så många sekunder innan ett anslutningsförsök görs.

MT:s förfalloperiod expiration-period

Timeout mellan SUBMIT_SM och dess matchning SUBMIT_SM_RESP. Om RESP inte tas emot i tid, meddelandet betraktas som misslyckat och en global återförsöksprincip för MTA gäller.

Tidsgräns för bindning bind-timeout

Timeout mellan TCP-anslutningsförsöket och BIND_*_RESP svara. När timeout uppstår stängs anslutningen av Adobe Campaign-anslutningen och den väntar på att anslutas igen innan den försöker igen.

fråge_länkperiod enquire-link-period

enquire_link är en speciell typ av PDU som skickas för att hålla anslutningen vid liv. Perioden är i sekunder. Kampanjkopplingen skickar bara enquire_link när anslutningen är inaktiv för att spara bandbredd. Om inget RESP tas emot efter två gånger den här perioden betraktas anslutningen som död och en återanslutningsprocess utlöses.

SMSC-specifikationer SMSC-specifics

Dessa inställningar är avancerade inställningar som anpassar Adobe Campaign-anslutningen till de flesta SMPP-implementeringsegenskaper.

Definiera en specifik mappning av kodningar encoding-specific-mapping

Se SMS-textkodning om du vill ha mer information om textkodning.

Med den här inställningen kan du definiera en anpassad kodmappning, som skiljer sig från specifikationen. Du kan deklarera en lista med kodningar, tillsammans med deras data_coding värde.

MTA kommer att försöka koda med den första kodningen i listan. Om det inte fungerar kommer det att försöka använda nästa kodning i listan, osv. Om ingen kodning kan användas för att koda meddelandet inträffar ett fel. När kodningen har hittats skapar MTA SUBMIT_SM PDU med den kodade texten och data_coding fältuppsättningen med det värde som anges i tabellen.

Ordningen på objekten i tabellen är viktig: kodningar är försök uppifrån och ned. Du bör placera den billigaste eller mest rekommenderade kodningen högst upp i listan och sedan använda mer och mer kostsamma kodningar.

Observera att UCS-2 aldrig kommer att misslyckas eftersom det kan koda alla tecken som stöds i Adobe Campaign och att den maximala längden för ett UCS-2 SMS är mycket mindre: endast 70 tecken.

Du kan också använda den här inställningen för att tvinga en viss kodning att alltid användas genom att deklarera endast en rad i mappningstabellen.

Standardmappningen som används när kryssrutan inte är markerad motsvarar följande tabell:

Detta innebär att MTA försöker koda meddelandet i GSM. Om det lyckas skickar det den med data_coding anges till 0.

Om meddelandet inte kan kodas i GSM kodas det i UCS-2 och ställs in data_coding till 8.

Aktivera message_payload enable-message-payload

När det är avmarkerat delas lång SMS upp av MTA och skickas i flera SUBMIT_SM PDUär med UDH. Meddelandet kommer att disponeras om av mobiltelefonen efter UDH-data.

När det här alternativet är markerat skickas lång SMS i en SUBMIT_SM PDU, vilket placerar texten i det valfria fältet message_payload. Se SMPP-specifikation om du vill ha mer information om detta.

Om den här funktionen är aktiverad kan Adobe Campaign inte räkna SMS-delar individuellt: alla meddelanden räknas som skickade i en del.

Skicka det fullständiga telefonnumret send-full-phone-number

När den här kryssrutan inte är markerad skickas endast siffror i telefonnumret till leverantören (destination_addr fält för SUBMIT_SM fält). Detta är standardbeteendet eftersom den internationella nummerindikatorn, vanligtvis ett ±prefix, ersätts av TON- och NPI-fält i SMPP.

När kryssrutan är markerad skickas telefonnumret i befintligt skick, utan förbearbetning och potentiella mellanslag, + prefix eller nummertecken/hash/star-tecken.

Den här funktionen påverkar också funktionen för automatiskt svar på blockeringslista: när kryssrutan inte är markerad läggs ett ±prefix till i telefonnummer som infogas i karantäntabellen för att kompensera för att ±prefixet tas bort från telefonnumret av själva SMPP-protokollet.

Hoppa över TLS-certifikatkontroll skip-tls

När TLS är aktiverat hoppar du över alla certifikatkontroller.

När det här alternativet är markerat är anslutningen inte längre säker, utan bör inte aktiveras i produktionen.

Den kan vara användbar för felsökning och testning.

Bindning TON/NPI bind-ton-npi

TON (typ av nummer) och NPI (Numreringsplansindikator) som beskrivs i avsnitt 5.2.5 i Specifikation för SMPP 3.4 (sidan 117). Dessa värden ska ställas in efter vad providern behöver.

De överförs som de är addr_ton och addr_npi fält i BIND PDU:n.

Adressintervall address-range

Skickat som det är i fältet address_range i BIND PDU:n. Det här värdet ska ställas in på det som providern behöver.

Ogiltigt antal ID-bekräftelser invalid-id

Begränsar antalet Meddelande-ID är ogiltigt DELIVER_SM_RESP som kan skickas för en enskild SR.

Detta bör endast användas för felsökningssyften som en lösning och anges till 0 under normala förhållanden.

Exempel: När inställningen är 2:

Om du ställer in det här fältet på 0 inaktiveras mekanismen där Meddelande-ID är ogiltigt returneras alltid, detta är normalt beteende.

Om du ställer in det här fältet på 1 kommer kopplingen alltid att svara "OK" även om ID:t är ogiltigt. Detta bör endast anges till 1 under övervakning, för felsökning och under kortast möjliga tid, t.ex. för att återhämta sig från ett problem på leverantörssidan.

Extraheringsregion för ID i SR regex-extraction

SR-formatet används inte strikt av SMPP-protokollspecifikationen. Det är bara en rekommendation som beskrivs i Tillägg B (sidan 167) i specifikationen. Vissa SMPP-implementerare formaterar det här fältet annorlunda, så Adobe Campaign behöver ett sätt att extrahera rätt fält.

Som standard hämtas upp till 10 alfanumeriska tecken efter id:.

Regex måste ha exakt en hämtningsgrupp med en del inom parentes. Parenteser måste omge ID-delen. Regex-formatet är PCRE.

När du justerar den här inställningen måste du ta med så mycket kontext som möjligt för att undvika falska utlösare. Om det finns specifika prefix, till exempel id: i standarden, ta med dem i regex. Använd också så mycket ordavgränsare (\b) som möjligt för att undvika att skriva in text mitt i ett ord.

Om det inte finns tillräckligt med sammanhang i regionen kan det medföra ett litet säkerhetsfel: meddelandets faktiska innehåll kan inkluderas i SR. Om du bara matchar ett specifikt ID-format utan kontext, t.ex. ett UUID, kan det bero på att det faktiska textinnehållet parsas, t.ex. ett UUID som är inbäddat i textfältet, i stället för ID:t.

Regex används för att fastställa status för lyckat/fel regex-applied

När meddelanden med en okänd kombination av stat/fel-fält påträffas, används dessa regex i statusfältet för att avgöra om SR lyckades eller inte. SR med statusvärden som inte matchar någon av dessa regexter ignoreras.

Som standard används de startvärden som börjar med DELIV, t.ex. DELIVRD i Tillägg B, kommer att anses ha levererats och alla statusvärden som matchar fel, t.ex. REJECTED, UNDELIV, betraktas som fel.

ID-format i MT-bekräftelse id-format-mt

Detta anger formatet på det ID som returneras i message_id fält för SUBMIT_SM_RESP PDU.

ID-format i SR id-format-sr

Detta anger formatet för det ID som fångats av Extraction region för ID i SR. Värden har samma innebörd och samma beteende som formatet i MT ovan.

SR ID eller felkod i valfritt fält

Om du markerar det här alternativet läggs innehållet i valfria fält till i texten som bearbetas av regexterna ovan. Texten kommer att ha formatet 0xTAG:VALUE, 0xTAG är det fyrsiffriga hexadecimala värdet av taggen i versaler, t.ex. 0x002E.

Du kanske vill hämta ID:t i receipted_message_id fält. Aktivera den här kryssrutan och följande text läggs till i statusen:

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

I det här exemplet är 0x001E taggen för det valfria fältet och UUID är fältets värde.

Om du vill hämta det här värdet kan du nu ange följande region i Extraheringsregex för ID:t i fältet för SR:

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

SR-id eller felkod i textfält

Om du markerar det här alternativet visas Text fältet kommer att behållas under bearbetningen av statustexten för SR.

Detta är användbart om providern placerar viktiga data i det här fältet som ID eller status. Vanligtvis kan det här fältet tas bort eftersom det kan innehålla text som inte är ASCII-kodad och stör regex-bearbetningen.

Om du aktiverar det här alternativet kan ett mycket litet säkerhetsfel uppstå om Extraction Regex för ID:t i fältet SR är inte tillräckligt specifik. Innehållet i Text kan tolkas som ett ID och en angripare kan använda det för att mata in förfalskade ID:n, vilket kan leda till en situation där tjänsten inte kan användas delvis.

Service ID-tagg

Tillåter att en anpassad TLV läggs till. Det här fältet anger taggdelen. Värdet kan anpassas per leverans i Service- eller program-ID värdet i de avancerade parametrarna för leveransen.

Med den här inställningen kan du bara lägga till ett TLV-alternativ per meddelande.

Automatiskt svar skickat till flerlägesobjektet automatic-reply

Med den här funktionen kan du snabbt svara på text till MO och hantera kortkod som skickas till blockeringslista.

The Nyckelord och Kort kod kolumner definierar villkor som utlöser det automatiska svaret. Om båda fälten matchar skickas MO och den ytterligare åtgärden utlöses. Om du vill ange ett jokertecken lämnar du fältet tomt. Nyckelordet matchar det första alfanumeriska ordet i MO-texten, och interpunktion och radavstånd ignoreras. Det betyder att Nyckelord fältet får inte innehålla blanksteg och måste vara ett enda ord.

The Nyckelord inställning är ett prefix. Om du till exempel anger "AD" kommer det att matcha "AD", "ADAPT" och "ADOBE". Om du har flera nyckelord med ett gemensamt prefix måste du vara uppmärksam på ordningen eftersom nyckelorden bearbetas uppifrån och ned.

The Svara kolumn är den text som ska besvaras. Det finns ingen tillgänglig personalisering i det här fältet. Om du lämnar det här fältet tomt kommer inget meddelande att skickas, men den ytterligare åtgärden kommer att utlösas ändå.

The Ytterligare åtgärd kolumn innehåller en extra åtgärd när båda Nyckelord och Kort kod match, empty short code match all short codes. Du kan skicka till karantän eller ta bort från karantän, ange inget svar på texten. Om du anger en Ytterligare åtgärd men lämna Svara fältet är tomt kommer åtgärden att utföras, men inget svar kommer att skickas. Karantän används bara för den angivna korta koden eller för alla korta koder om fältet lämnas tomt.

Alla poster i tabellen bearbetas i den angivna ordningen tills en regel matchar. Om flera regler matchar en flerfunktionsregel tillämpas bara den översta regeln.

Valfria parametrar för automatiskt svar (TLV) automatic-reply-tlv

Från och med version 21.1 kan du lägga till valfria parametrar till MT för automatiskt svar. De läggs till som valfria TLV-parametrar i SUBMIT_SM PDU av svaret, såsom beskrivs i avsnitt 5.3 i SMPP-specifikation(sidan 131).

Mer information om valfria parametrar finns i section.

Mallparametrar för SMS-leverans sms-delivery-template-parameters

Vissa parametrar kan anges per leveransmall.

Från fält from-field

Det här fältet är valfritt. Det tillåter åsidosättande av avsändaradress (oADC). Innehållet i det här fältet placeras i source_addr fält för SUBMIT_SM PDU.

Fältet är begränsat till 21 tecken av SMPP-specifikationen, men vissa leverantörer kan tillåta längre värden. Observera också att mycket strikta begränsningar kan tillämpas i vissa länder, till exempel längd, innehåll och tillåtna tecken.

Leveransparametrar delivery-parameters

Högsta antal SMS per meddelande maximum-sms

Den här inställningen fungerar bara om Meddelandenyttolast inställningen är inaktiverad. Mer information finns i page. Om meddelandet kräver mer SMS än det här värdet utlöses ett fel.

SMS-protokollet begränsar SMS till 255 delar, men vissa mobiltelefoner har problem med att sätta ihop långa meddelanden med mer än 10 delar eller så beror gränsen på den exakta modellen. Vi rekommenderar att du inte går över 5 delar per meddelande.

På grund av hur personaliserade meddelanden fungerar i Adobe Campaign kan meddelandena variera i storlek. Att ha ett stort antal långa meddelanden kan öka sändningskostnaderna.

Överföringsläge transmission-mode

Det här fältet anger vilken typ av SMS du vill överföra: normala meddelanden eller flash-meddelanden som lagras på mobilen eller SIM-kortet.

Den här inställningen överförs i dest_addr_subunit valfritt fält i SUBMIT_SM PDU.

Giltighetsperiod validity-period

Giltighetsperioden överförs i validity_period fält för SUBMIT_SM PDU. Datumet formateras alltid som ett absolut UTC-tidsformat (datumfältet avslutas med "00+").

Tillvalsparametrar för SMPP (TLV) smpp-optional-parameters

Från och med version 21.1 kan du lägga till flera valfria parametrar till varje MT som skickas för den här leveransen. Dessa valfria parametrar läggs till i SUBMIT_SM PDU av svaret, såsom beskrivs i avsnitt 5.3 i SMPP-specifikation(sidan 131).

Varje rad i tabellen representerar en valfri parameter:

Om någon valfri parameter har samma Tagg-ID som Service Tag-ID som definieras i det externa kontot gäller det värde som definieras i den här tabellen.

SMPP-anslutning ACS-SMPP-connector

Pilar representerar dataflöde.

Det viktigaste att notera här är att det finns flera SMPP-kopplingstrådar. Alla trådarna är identiska och har samma konfiguration. Därför multipliceras alltid antalet anslutningar med antalet trådar.

Antalet trådar kan inte ändras av kunden eftersom det kräver att konfigurationsfilerna ändras.

Beskrivning av SMPP-anslutarens beteende behavior-smpp-connector

Matchande MT-, SR- och broadcast-poster matching-mt-sr

I Adobe Campaign är ett meddelande ett utskick. I Adobe Campaign Standard behöver externa kontakter bara känna till den fungerande sändningstabellen: nmsBroadLogExec. Ett arbetsflöde hanterar kopiering av utskicksposter tillbaka till deras specifika måldimensioner (nmsBroadLogXXX).

Tyvärr tillåter inte SMPP att ett ID skickas tillsammans med ett meddelande: providern ger ett MT ID till varje MT och tillhandahåller sedan ett eller flera SR med samma ID.

Det ID som anges av providern lagras i sProviderId kolumn för nmsBroadLogExec tabell. SR anländer alltid efter det att MT har skickats och bekräftats, men kan ibland komma i fel ordning, vilket i Adobe Campaign kallas för utestående SR. Bearbetningstråden lagrar dessa SR tillfälligt i RAM tills den fullständiga informationen kommer.

När en MT bekräftas (SUBMIT_SM_RESP), sProviderId uppdateras omedelbart i databasen.

Varje SR bearbetas individuellt av SMPP-processtrådar. Den här processen är pseudosynkron: den ses som synkron utifrån, men implementeras internt med händelsestyrda implementeringar. SR bekräftas endast när sändningsloggen har uppdaterats, om ett fel påträffas, avvisas SR.

Här följer processen som används för varje SR:

Om du vill kontrollera ovanstående steg måste du Aktivera utförliga SMPP-spår om du vill kontrollera att alla steg används korrekt manuellt. Detta krävs varje gång Adobe Campaign är anslutet till en ny SMPP-leverantör.

Innan du publicerar checklist

Den här checklistan innehåller en lista med saker som du bör kontrollera innan du publicerar. En ofullständig konfiguration kan leda till många problem.

Kontrollera om det finns externa kontokonflikter external-account-conflict

Kontrollera att du inte har gamla SMS-externa konton. Om du lämnar testkontot inaktiverat riskerar du att det återaktiveras i produktionssystemet och skapar potentiella konflikter.

Kontrollera att ingen annan instans ansluter till det här kontot. Kontrollera särskilt att scenmiljön inte ansluter till kontot. En del leverantörer stöder detta, men det kräver mycket specifik konfiguration både på Adobe Campaign-sidan och på leverantörens plattform.

Om du behöver ha flera konton på samma Adobe Campaign-instans som ansluter till samma leverantör, kontaktar du leverantören för att se till att de verkligen särskiljer anslutningar mellan dessa konton. Om du har flera konton med samma inloggning krävs extra konfiguration.

Aktivera utförliga SMPP-spår under kontroller enable-verbose

Du bör alltid aktivera utförliga SMPP-spår under kontroller.
Även om du inte kan kontrollera loggarna själv är det enklare för supporten att hjälpa dig.

Testa ditt SMS test

Kontrollera PDU:er check-pdus

Även om meddelandena ser bra ut är det viktigt att kontrollera att PDU:er är korrekt formaterade.

Det här steget är nödvändigt när du ansluter till en leverantör som inte var ansluten till Adobe Campaign tidigare.

BIND bind

Kontrollera att BIND_* PDUs skickas korrekt. Det viktigaste att kontrollera är att providern alltid returnerar lyckad BIND_*_RESP PDUs (command_status = 0).

Kontrollera att det inte finns för många BIND_* PDUs. Om de är för många kan det tyda på att anslutningen är instabil. Se Problem med instabila anslutningar för mer information.

INQUIRE_LINK enquire-link-pdus

Kontrollera att ENQUIRE_LINK PDUUtbyts regelbundet när anslutningen är inaktiv.

SUBMIT_SM / DELIVER_SM submit-sm-deliver-sm

Skicka ett meddelande och sök sedan i loggarna efter dess motsvarande SUBMIT_SM, SUBMIT_SM_RESP, DELIVER_SM och DELIVER_SM_RESP PDUs.

Med SUBMIT_SM PDU:

Med SUBMIT_SM_RESP PDU:

Med DELIVER_SM PDU:

Med DELIVER_SM_RESP PDU:

Fråga leverantören om allt är OK provider

Även om ditt SMS fungerar som det ska kan du kontakta leverantören för att se om allt är i ordning.

Inaktivera utförliga SMPP-spår disable-verbose

När alla kontroller är slutförda är det sista du behöver Inaktivera utförliga SMPP-spår för att inte generera för många loggar. Du kan återaktivera dem för felsökning även i produktionssystem.