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:

Det här dokumentet leder dig genom uppkopplingen 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 Classic 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-dokumentationen.

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. En 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å RESP. Antalet förfrågningar som skickas när som helst kallas för fönstret. RESP PDU kan komma fram i vilken ordning som helst, oberoende av ordningen för motsvarande initierar-PDU.

I det separerade läget Transmitter+receiver beror anslutningen 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.

Om du till exempel skickar en MT används sändaranslutningen och RESP som bekräftar att MT också skickas via sändarkanalen. När du tar emot ett flerlägesobjekt (eller ett SR) används mottagaranslutningen för att ta emot flerlägesobjektet och för att skicka RESP som godkänner flerfunktionsadressen.

I Adobe Campaign Classic, för att länka SR med motsvarande MT, returneras ett ID av SMSC med stegen SUBMIT_SM_RESP och DELIVER_SM. Identifieraren lagras i fältet providerId i tabellen nms::providerMsgId och är länkad till broadLogId och deliveryId. Denna matchningsåtgärd utförs av SMS-processen när den skriver till databasen.

Ett SUBMIT_SM_RESP PDU som lyckades utlöser statusen för det skickade meddelandet i den avsändande loggen medan ett DELIVER_SM (SR) PDU som lyckades utlöser statusen för det mottagna meddelandet.

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 de standardcertifikat som tillhandahålls av systembiblioteket openssl. Vanligtvis tillhandahålls den av katalogen /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 beskrivs i SMPP 3.4-specifikationen.

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

PDU:er kan ha valfria fält. Här beskrivs bara de vanligaste fälten. Mer information finns i SMPP 3.4-specifikationen.

BIND_TRANSMITTER / BIND_RECEIVER / BIND_TRANSCEIVER

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

Noterbara 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å matchande UNBIND_RESP PDU innan anslutningen stängs.

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 Ogiltigt meddelande-ID besvaras i ett 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 som motsvarande SUBMIT_SM. Här är en lista med användbara fält:

Adobe Campaign kan läsa meddelande-ID i det valfria fältet receipted_message_id med en viss konfiguration.

DELIVER_SM_RESP deliver-sm-resp

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

Adobe Campaign Classic godkänner SR och MO när de har infogats i databasen. Vissa bearbetningsfel kan inträffa även om en DELIVER_SM_RESP PDU har skickats. Den här begränsningen orsakas av Adobe Campaign Classic programvaruarkitektur.

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. Mer information om hur många tecken som får plats i ett SMS finns i avsnittet SMS-textkodning.

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 inställningen Maximalt antal SMS per meddelande i leveransmallen. 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:

Mer information om protokoll och format finns i beskrivningen av fälten esm_class, short_message och message_payload i PDU:n SUBMIT_SM.

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 avsnittet Samtidiga anslutningar.

För att uppnå maximal genomströmning måste du finjustera det maximala sändningsfönstret. Det skickade fönstret är antalet SUBMIT_SM PDU som kan skickas utan att vänta på en SUBMIT_SM_RESP. Mer information finns i avsnittet Skicka fönsterinställning.

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

SMPP-protokollet definierar synkrona standardfel i RESP PDU, men 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-protokollspecifikationen (sidan 167), men den innehåller 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 finns status och fel i fältet short_message (exempel för implementeringar som överensstämmer med tillägg B). Fältet short_message i PDU:n kallas ofta textfält eftersom det innehåller text i MT. Om det är SR innehåller den teknisk information plus ett underfält med namnet Text. Dessa två fält är olika och short_message innehåller faktiskt fältet Text och annan information.

Adobe Campaign Classic-anslutningar (utom Extended SMPP) använder ett hårdkodat beteende som är beroende av den valda providern. Allmän SMPP skiljer bara mellan lyckade och misslyckade utan detaljer. Leveransloggen kan innehålla viss information som inte är garanterad.

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 togs emot i SUBMIT_SM_RESP PDU, MT:ns bekräftelse.

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

Fälten submit date och done date ä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. Statusen DELIVRD indikerar att det lyckades, de andra två indikerar 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 Classic 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 tillämpas regex id extraction för att extrahera ID:t och stämma av det med motsvarande MT.

Därefter tillämpas regex status extraction och error code extraction regex 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. Kopplingen använder sedan framgångarna och error regex för att avgöra om det var ett lyckat eller misslyckat:

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 bör alltid kontakta SMSC-providern vid kodningsproblem. Endast SMSC-leverantörerna har kunskap 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 fältet short_message i SMS:et kan vara upp till 160 byte långt i SMPP-bildrutan, medan det är begränsat till 140 byte när det skickas till det mobila nätverket.

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

Fältet data_coding 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 associerad med data_coding = 0 som endast stöds av Adobe Campaign. Andra data_coding-värden följer ofta specifikationen, men det enda sättet att vara säker är att kontrollera med SMSC-providern.

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

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 avsnittet SR-felhantering.

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. Skickades i fältet system_id i BIND PDU:n.

Lösenord password

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

Systemtyp system-type

Värdet skickades i fältet system_id i BIND PDU:n. Vissa leverantörer behöver ett specifikt värde här.

Antal MTA-underordnade anslutningar number-mta-child

I Adobe Campaign Classic definieras antalet anslutningar per underordnad MTA.

Adobe Campaign Classic Extended SMPP-kontakten kan styra antalet anslutningar per MTA-underordnad. För att styra den globala gränsen för anslutningar måste du begränsa antalet MTA-underordnade processer, vilket ofta innebär att du måste ha en dedikerad mellanleverantörsplattform för SMS.

För Adobe Campaign Classic kan det finnas ett annat antal mottagar- och sändaranslutningar:

Som tidigare nämnts öppnar Adobe Campaign Classic SMS-processen fler sändaranslutningar om autosvar är aktiverat. Dessa extra anslutningar används för att skicka de automatiska svaren.

Om du ställer in automatiska svar kommer SMS-processen att öppna sändare-/mottagarpar, vilket ökar antalet sändaranslutningar. Om du inte har konfigurerat något automatiskt svar öppnas bara mottagaranslutningar.

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.

I Adobe Campaign Classic finns loggutdata i MTA-loggen för MT-relaterad trafik och i SMS-loggen för MO- och SR-relaterad trafik.

Inställning för mottagaranslutning receiver-connection

Det här avsnittet är bara synligt i läget sändare+mottagare som separerats.

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 gäller inställningarna i avsnittet Anslutningsinställningar för sändaren och inställningarna i inställningarna för Mottagaranslutningen för mottagaren.

Mottagarserver, port, konto, lösenord, systemtyp

De här inställningarna gäller för mottagaren i läget sändare+mottagare. 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.

Adobe Campaign Classic lagrar alltid alla flerlägesobjekt i InSMS-databasen så det här alternativet är inte tillgängligt.

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 statistik av arbetsflödet syncfromexec, som körs var 20:e minut.

Adobe Campaign Classic har en helt annan mekanism för nyckeltal, så det här alternativet är inte tillgängligt.

Source 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:

Source TON/NPI, mål-TON/NPI ton-npi

TON (Number Type of Number) och NPI (Numbering Plan Indicator) beskrivs i avsnitt 5.2.5 i SMPP 3.4-specifikationen (sidan 117). Dessa värden ska ställas in efter providerns behov.

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

Tjänsttyp service-type

Det här fältet överförs som det är i fältet service_type i 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 PDU som kan skickas utan att vänta på matchande 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 antalet SMS/s multiplicerat med länkens latens
i sekunder så att kopplingen aldrig väntar på en SUBMIT_SM_RESP innan nästa meddelande skickas.
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 angett 300 SMS/s i maximalt MT-dataflöde och det finns 100 ms latens mellan SUBMIT_SM och SUBMIT_SM_RESP i genomsnitt, blir 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 en exakt dataström över detta antal om inte den slutliga arkitekturen är korrekt refererad och särskilt begärd SMPP-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 matchande SUBMIT_SM_RESP. Om RESP inte tas emot i tid kommer meddelandet att betraktas som misslyckat och en global återförsöksprincip för MTA kommer att gälla.

Tidsgräns för bindning bind-timeout

Timeout mellan TCP-anslutningsförsöket och svaret på BIND_*_RESP. 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

Mer information om textkodning finns i avsnittet SMS-textkodning.

Med den här inställningen kan du definiera en anpassad kodmappning, som skiljer sig från specifikationen. Du kan deklarera en lista över 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 hittas skapar MTA SUBMIT_SM PDU med den kodade texten och fältet data_coding 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 skickas det med data_coding inställt på 0.

Om meddelandet inte kan kodas i GSM kodas det i UCS-2 och anges till data_coding till 8.

Aktivera message_payload enable-message-payload

Om alternativet inte är markerat delas lång SMS upp av MTA och skickas i flera SUBMIT_SM PDU 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. Mer information om detta finns i SMPP-specifikationen.

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 providern (destination_addr i fältet SUBMIT_SM). 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.

Du kan välja mellan tre olika värden för certifikatverifieringen:

Bindning TON/NPI bind-ton-npi

TON (Number Type of Number) och NPI (Numbering Plan Indicator) som beskrivs i avsnitt 5.2.5 i SMPP 3.4-specifikationen (sidan 117). Dessa värden ska ställas in efter vad providern behöver.

De överförs som de är i fälten addr_ton och addr_npi 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 som ä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 inställd på 0 under normala förhållanden.

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

Om du anger värdet 0 för det här fältet inaktiveras mekanismen där Meddelande-ID ogiltigt alltid returneras. Detta är normalt.

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 Bilaga 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 tio 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, inkluderar du 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 kommer lägesvärden som börjar med DELIV, t.ex. DELIVRD i Bilaga B, att betraktas som levererade 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 för det ID som returneras i fältet message_id i SUBMIT_SM_RESP PDU.

ID-format i SR id-format-sr

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

SR ID eller felkod i det valfria fältet

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

Du kanske vill hämta ID:t i fältet receipted_message_id. 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ältet

Om det här alternativet är markerat behålls fältet Text 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 ID:ts Extraction-region i SR-fältet inte är tillräckligt specifik. Innehållet i fältet Text kan tolkas som ett ID och en angripare kan använda det för att mata in smidda ID:n, vilket kan leda till en situation där tjänsten inte kan användas alls.

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 värdet för tjänst- eller program-ID 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.

Kolumnerna Nyckelord och Kort kod 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 innebär att fältet Nyckelord inte får innehålla blanksteg och måste vara ett enda ord.

Inställningen Nyckelord ä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.

Kolumnen Svar ä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å.

Kolumnen Ytterligare åtgärd innehåller en extra åtgärd när både Nyckelord och Kort kod matchar, tom kod matchar alla korta koder. 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åter fältet Svar vara tomt körs åtgärden, men inget svar 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.

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 fältet source_addr i 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 inställningen Meddelandenyttolast är inaktiverad. 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 det valfria fältet dest_addr_subunit i SUBMIT_SM PDU.

Giltighetsperiod validity-period

Giltighetsperioden överförs i fältet validity_period i SUBMIT_SM PDU. Datumet formateras alltid som ett absolut UTC-tidsformat, datumfältet avslutas med "0+".

Utökad allmän SMPP-anslutning acc-extended-connector

Pilar representerar dataflöden.

När leveransdelar skickas visar MTA-barnen MTA. Antalet underordnade MTA-processer är dynamiskt och beror på en konfiguration i serverConf.xml. Varje underordnad MTA instansierar kopplingen CSmppConnectorWorker som ansluter till SMPP-providern. Anslutningar hålls aktiva så länge som MTA-barnet hålls vid liv, som även kan konfigureras i serverConf.xml.

SMS-processen behandlar endast SR, den ansluter till providern och låter anslutningen vara öppen. Processen återansluter var 10:e minut för att läsa in nya inställningar, vilket är en normal åtgärd.

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

En mellanliggande tabell nmsProviderMsgId används för att lagra MT- och SR-data temporärt innan den verkställs asynkront i utsändningsloggen.

Tabellen nmsProviderMsgId har tre grupper med kolumner:

När både MT och SR är klara bör du ha fullständiga rader, med både sändningsinformation och statusinformation.

Här är iMsgId länkad till tabellen nmsBroadLogMsg, vilket anger det fullständiga status-/felmeddelandet.

SMS-processen söker efter hela rader varje minut och bearbetar dem sedan asynkront:

Genomströmning och parallella anslutningar

Varje MTA-underordnad skapar en konfigurerbar mängd anslutningar, så om du begränsar antalet MTA-underordnade kommer antalet anslutningar att begränsas. Eftersom korrelationen mellan de underordnade MTA-processerna och trafiken är korrelerad kan detta styras något, men ändå lite oförutsägbart.

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.

Om du har 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 Adobe kundtjänst 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 har skickats korrekt. Det viktigaste att kontrollera är att providern alltid returnerar BIND_*_RESP PDUs (command_status = 0).

Kontrollera att det inte finns för många BIND_* PDUs. Om det finns för många av dem kan det tyda på att anslutningen är instabil. Mer information finns i avsnittet Problem med instabila anslutningar.

INQUIRE_LINK enquire-link-pdus

Kontrollera att ENQUIRE_LINK PDU byts ut regelbundet när anslutningen är inaktiv.

SUBMIT_SM/DELIVER_SM

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

Med SUBMIT_SM PDU:

Med SUBMIT_SM_RESP PDU:

Med DELIVER_SM PDU:

Med DELIVER_SM_RESP PDU:

Kontrollera med din leverantör 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 klara är det sista att Inaktivera detaljerade SMPP-spår för att inte generera för många loggar. Du kan återaktivera dem för felsökning även i produktionssystem.