Felsöka SMS sms-troubleshooting

Problemet uppstod på ett eller flera konton

I så fall kan du tillämpa andra felsökningsprocedurer på varje konto separat. Det är bäst att inaktivera andra konton när du diagnostiserar ett konto för att minska nätverkstrafiken och antalet loggar.

Problemet uppstod inte när endast ett konto är aktivt vid något tillfälle

Du har en konflikt mellan konton. Som tidigare nämnts behandlar Adobe Campaign konton individuellt, men leverantören kan behandla dem som ett enda konto.

• Du använder olika kombinationer av inloggning och lösenord för alla dina konton.
  Du måste kontakta leverantören för att diagnostisera potentiella konflikter hos dem.

• Vissa externa konton har samma kombination av inloggning och lösenord.
  Leverantören har inget sätt att avgöra från vilket externt konto de BIND PDU kommer från, så de behandlar alla anslutningar från flera konton som en enda. De kan ha dirigerat MO och SR slumpmässigt över de två kontona, vilket orsakar problem.
  Om leverantören stöder flera korta koder för samma kombination av inloggning/lösenord måste du fråga dem var de ska placera den korta koden i .BIND PDU Observera att den här informationen måste placeras i BIND PDU, och inte i SUBMIT_SM, eftersom BIND PDU det är den enda platsen som tillåter att MO:er dirigeras korrekt.
  Se avsnittet Information i varje typ av PDU ovan för att veta vilket fält som är tillgängligt i BIND PDU, vanligtvis lägger du till den korta koden i address_range, men det kräver särskilt stöd från leverantören. Kontakta dem för att få veta hur de förväntar sig att dirigera flera kortkoder oberoende av varandra.
  Adobe Campaign stöder hantering av flera korta koder på samma externa konto.

Undersök om kopplingen nyligen har ändrats och av vem (markera Externa konton som en grupp).

select saccount, (sserver ||':'||sport) as serverPort, iextaccountid, CASE WHEN N0.iactive=1 THEN 'Yes' ELSE 'No' END as "(x) Enabled",

(select X1.sname from xtkoperator X1 where N0.icreatedbyid = X1.ioperatorid) as "Created By",

(select X1.sname from xtkoperator X1 where N0.imodifiedbyid = X1.ioperatorid) as "Last Modified By",

N0.slabel as "External Account", N0.tslastmodified as "LastModifiedDate"

from nmsextaccount N0 LEFT JOIN xtkoperator X0 ON (N0.icreatedbyid=X0.ioperatorid) order by 8 DESC LIMIT 50;

Undersök (i katalogen /postupgrade) om systemet uppgraderades och när

Undersök om några paket som påverkar SMS kan ha uppgraderats nyligen (https://experienceleague.adobe.com/var/log/dpkg.log?lang=sv).

Om du returnerar en kod som BIND PDU inte är noll command_status ber du providern om mer information.

Kontrollera att nätverket är korrekt konfigurerat så att TCP-anslutningen kan göras till providern.

Be leverantören kontrollera att de har lagt till IP-adresserna till tillåtelselista i Adobe Campaign-instansen.

Kontrollera inställningarna för externt konto. Fråga leverantören vilket värde fälten har.

Om anslutningen lyckas men inte fungerar kontrollerar du avsnittet Problem med instabila anslutningar.

Om det är svårt att diagnostisera anslutningsproblem kan nätverksinhämtningen ge information. Se till att nätverksinhämtningen körs samtidigt medan problemet uppstår så att det kan analyseras effektivt. Du bör också notera exakt när problemet uppstår.

Om du startar om MTA kommer du att korrigera saker tillfälligt. Det innebär att en instabil anslutning utlöser MTA-strypning på Adobe Campaign Standard, och att MTA startas om. Det kommer att hända igen tills rotorsaken hittas.

Providern skickar UNBIND PDUs.

enquire_link timeout, antingen på Adobe Campaign eller på leverantörssidan. I så fall kan ENQUIRE_LINK_RESP visas med en felkod som inte är noll.

Det finns många BIND PDUs. Det får inte finnas mer än ett fåtal under en dag, beroende på antalet anslutningar. Mer än 1 BIND PDU per timme ska vara varningar.

Instabila anslutningar är sällan rotorsaken, det beror ofta på ett annat problem som utlöser en frånkoppling. Att hitta rotorsaken är prioriteten.

Aktivera utförliga SMPP-spår. De måste se vad som händer när anslutningen startas om.

Om providern skickar BIND PDU kan något vara fel. Fråga din leverantör varför UNBING skickas.

Ibland är det enda sättet att se hur anslutningen stängs att ta en nätverksinhämtning.

Om providern stänger anslutningarna genom att skicka antingen ett TCP FIN- eller ett TCP RST-paket ber du leverantören om mer information.

Om providern stänger anslutningen efter att ha skickat ett rent fel som DELIVER_SM_RESP med en felkod måste de åtgärda sin koppling, annars förhindras andra typer av meddelanden från att skickas och MTA-begränsning aktiveras. Detta är särskilt viktigt i sändningsläge där stängning av anslutningen påverkar både MT och SR.

Kontrollera att anslutningen är stabil. En SMPP-anslutning bör vara upp till minst en timme kontinuerligt. Se avsnittet Problem med instabila anslutningar.

Om du startar om MTA så att sändning av MT fungerar igen under en liten tidsperiod, har du antagligen strypning på grund av en instabil anslutning. Se avsnittet Problem med instabila anslutningar.

Kontrollera att den breda loggen finns och att den har rätt status med rätt datum. Annars kan det vara ett leveransproblem.

Kontrollera att MTA faktiskt behandlar meddelandet. Om så inte är fallet är det kanske inte ett SMS-problem.

Kontrollera att SMS-anslutningen är bunden till providerns utrustning. Be leverantören om feedback för att säkerställa att alla system kommunicerar på rätt sätt. Mer information om bindningsprocessen finns i BIND_TRANSMITTER och BIND_TRANSCEIVER PDU. Du kan behöva aktivera SMPP-spår för korrekt felsökning.

Kontrollera att SUBMIT_SM PDU innehåller rätt information när SMPP-spårningarna är aktiverade.

Kontrollera att providern svarar med ett SUBMIT_SM_RESP PDU med värdet OK (kod 0). Kontrollera att PDU:n kommer med en rimlig fördröjning: allt som är längre än en sekund måste diskuteras med leverantören, det kommer vanligtvis om mindre än 100 ms.

Om alla dessa steg fungerar kan du vara säker på att problemet ligger hos leverantören. De måste göra felsökningen på sin plattform.

Om det fungerar men flödet inte är konsekvent kan du försöka justera sändande fönster och sänka MT-flödet. Du måste arbeta med leverantören för att justera det. Adobe Campaign kan skicka meddelanden mycket snabbt så att det kan uppstå prestandaproblem på leverantörens utrustning.

Om dubbletter skickas med exakt 60 sekunders mellanrum är det antagligen ett problem på providersidan. De skickar inte SUBMIT_SM_RESP tillräckligt snabbt.

Om du ser många BIND/UNBIND har du en instabil anslutning. Se avsnittet Problem med instabila anslutningar för lösningar innan du försöker lösa problem med dubblettmeddelanden.

SMPP-spår måste vara aktiverade för att du ska kunna utföra någon typ av SR-felsökning.

Kontrollera att DELIVER_SM PDU kommer från providern och att den är korrekt formaterad.

Kontrollera att Adobe Campaign svarar med ett lyckat DELIVER_SM_RESP PDU i tid. I Adobe Campaign Standard garanterar detta att hela bearbetningslogiken har tillämpats, om så inte är fallet kommer det garanterat att visas ett felmeddelande i loggarna som talar om varför bearbetningen misslyckades.

Kontrollera regex relaterat till id-extrahering och felbearbetning i externt konto. Du kan behöva validera dem mot innehållet i DELIVER_SM PDU.

Kontrollera att fel har etablerats korrekt i tabellen broadLogMsg.

Kontrollera att tabellerna broadLog och broadLogExec är korrekt synkroniserade för Adobe Campaign Standard.

Aktivera SMPP-spår under tester. Om du inte aktiverar TLS bör du göra en nätverksavbildning när du felsöker MO för att kontrollera att PDU:er innehåller rätt information och är korrekt formaterade.

När du samlar in nätverkstrafik eller analyserar SMPP-spår måste du samla in hela konversationen med MO och dess svars-MT om ett svar har konfigurerats.

Om flerlägesobjektet (DELIVER_SM PDU) inte visas i spårningarna är problemet på providersidan. De måste felsöka på sin plattform.

Om DELIVER_SM PDU visas kontrollerar du att den har bekräftats av Adobe Campaign med en DELIVER_SM_RESP PDU (kod 0). Denna RESP garanterar att all bearbetningslogik har använts av Adobe Campaign (autosvar och tillåt/blocklist). Om så inte är fallet söker du efter ett felmeddelande i MTA-loggarna.

Om automatiska svar är aktiverade kontrollerar du att SUBMIT_SM har skickats till providern. Annars kommer det garanterat att hitta ett felmeddelande i MTA-loggarna.

Om SUBMIT_SM MT PDU som innehåller svaret finns i spårningarna men SMS:et inte kommer till mobiltelefonen, måste du kontakta leverantören för hjälp med felsökning.

Kontrollera att telefonnummerformatet är exakt detsamma i karantäntabellen och i leveransloggen. Om så inte är fallet, gå till det här avsnittet om du har problem med plustexet för det internationella telefonnummerformatet.

Kontrollera korta koder. Undantag kan inträffa om den korta koden för mottagaren antingen är densamma som den är definierad i det externa kontot eller om den är tom (tom = valfri kortkod). Om bara en kort kod används för hela Adobe Campaign-instansen är det enklare att lämna alla short code-fält tomma.

Aktivera detaljerade SMPP-meddelanden när problemet uppstår. De flesta SMS-problem är omöjliga att lösa utan detta.

Om problemet är relaterat till SMS-trafik ska du kontakta leverantören först. Deras plattform passar bäst för effektiv diagnos av SMS-trafikproblem i realtid.

Ta med en kort men faktisk beskrivning av problemet.

Ta med en beskrivning av det förväntade resultatet.

Inkludera feedback från leverantören.

Inkludera relevanta loggar och/eller nätverksinhämtningar. Se till att du återskapar problemet under hämtningen när du gör hämtningar.

Om du inkluderar loggar, kalkeringar eller hämtningar pekar du exakt på platsen i filen när problemet uppstår.

Om du refererar till meddelanden, PDU:er eller loggar måste du tydligt ange deras tidsstämpel för att göra dem lättare att hitta.

Försök återskapa problemet i en testmiljö. Om du är osäker på en inställning kan du testa den i testmiljön och kontrollera resultatet med SMPP-spår. Det är oftast bättre att rapportera problem som replikeras i testmiljöer än att rapportera direkt i produktionsmiljöer.

Inkludera alla ändringar eller förbättringar som gjorts på plattformen. Ta även med eventuella ändringar som leverantören kan ha gjort på sin sida.

Anslutningsproblem, men de detaljerade meddelandena visar inga BIND_RESP PDU.

Oförklarliga frånkopplingar utan felmeddelande, det vanliga beteendet för anslutningsappen när den upptäcker ett protokollfel på låg nivå.

Leverantören klagar på avbindnings-/frånkopplingsprocessen.

Kodningsproblem i valfria TLV-fält.

Trafiken misstänks vara blandad mellan olika anslutningar.

TLS aktiverat: TLS-trafik krypteras per definition så att den inte kan avbildas.

Prestandaproblem: Loggar innehåller all information som behövs för att spåra prestandaproblem.

Timingproblem (retry timing, enquire_link period, begränsning av genomströmning osv.)

SR-parsning och -bearbetning: utförliga loggar ger mycket mer kontext och en bättre presentation.

MO-behandling (automatiska svar, karantän).

Fel som inte involverar faktisk SMPP-trafik: Förberedelse av leverans, API-problem för Message Center, arbetsflödesproblem osv.