SMPP-Protokollanalyse mit Wireshark

In diesem Artikel erfahren Sie, wie Sie eine SMPP-Protokollanalyse mit Wireshark für Adobe Campaign Classic durchführen.

Beschreibung description

Umgebung

Adobe Campaign Classic (ACC)

Problem/Symptome

Erfahren Sie, wie Sie den SMPP-Traffic mit Wireshark analysieren.

Die meisten Short Message Service Center mit hohem Durchsatz (SMS-C) sind mit dem SMPP-Protokoll Version 3.4 kompatibel. Dieses Protokoll ermöglicht den Versand von SMS und den Empfang von Informationen über den Versand dieser SMS. Das SMPP-Protokoll ist in der SMPP Protocol Specification v3.4 dokumentiert, die im Internet als PDF-Dokument verfügbar ist.

Dieser Artikel ersetzt diese Spezifikation nicht: Er enthält praktische Tipps zur Interpretation der Protokollspezifikation und zur Anpassung an die Wireshark-Anzeige, um Probleme zwischen Adobe Campaign und dem SMS-C-Partner zu beheben.

Da das SMPP-Protokoll viele Teile enthält, die der Interpretation des Implementierungsteams überlassen bleiben, gibt es Unterschiede zwischen verschiedenen SMS-C.

Wenden Sie sich bei der Problembehebung immer an den SMS-C-Partner, um Informationen zu erhalten oder um zu überprüfen, was Sie erhalten. Wenn SMS-C mit einem Fehler antwortet, kann Ihr SMS-C-Partner Ihnen am besten mitteilen, warum es mit dem Fehler geantwortet hat. Wenn Sie einen SMPP-Simulator verwenden, anstatt eine Verbindung zu einem echten SMS-C herzustellen, sollten Sie den Quellcode (oder einen Debugger) verwenden, um zu verstehen, was passiert.

Lösung resolution

Erfassen des Netzwerk-Traffics ohne Wireshark

Wenn Sie keinen direkten Zugriff auf den Computer haben, kann es erforderlich sein, mithilfe von Befehlszeilen-Tools wie tcpdump zu erfassen. Wenn Sie bereits den TCP-Port der Verbindung kennen, stellen Sie den richtigen Filter ein, um zu vermeiden, dass der gesamte Traffic erfasst wird. Hier finden Sie eine Beispiel-tcpdump-Befehlszeile zum Erfassen von Port 12345 bis  outfile.pcap:

tcpdump -i any -w outfile.pcap tcp port 12345

Die Datei  outfile.pcap  kann dann in Wireshark für weitere Analysen geöffnet werden.

Wireshark-Handhabung

In diesem Thema wird davon ausgegangen, dass Sie mit den Grundlagen von Wireshark vertraut sind: Pakete erfassen, einfache Filter definieren, Paketdetails lesen. Eine kurze Einführung finden Sie unter howtogeek - Verwendung von Wireshark zum Erfassen, Filtern und Inspect-Paketen.

Um den SMPP-Traffic in Wireshark herauszufiltern, gibt es drei wichtige Funktionen:

  • Verwenden Sie einen Anzeigefilter für den Port der SMS-C.

    Wenn das SMS-C beispielsweise Port 10000 verwendet, verwenden Sie den folgenden Filter:
    tcp.port == 10000

  • Um Pakete nach Telefonnummer oder Textinhalt zu isolieren, verwenden Sie die Suchfunktion mit den folgenden Einstellungen:

    smpp1

  • Verwenden Sie die TCP-Stream -Tool, um den Stream zu isolieren, an dem Sie arbeiten.

    Schließen Sie das rote/blaue Textfenster, das angezeigt wird, da es nur für Textprotokolle nützlich ist, die für SMPP nicht relevant sind.

    smpp2

SMPP-Protokoll

Das Protokoll funktioniert über TCP und ist vollständig binär, was bedeutet, dass spezielle Tools wie Wireshark (oder ein hexadezimaler Editor) zum Entschlüsseln des Stream-Inhalts erforderlich sind.

Der Stream besteht aus unabhängigen PDUs: Jede PDU ist eine Nachricht mit einem Befehl, einem Status, einer Sequenznummer und anderen Informationen, die auf dem Befehl basieren.

Aufgrund der Natur von TCP als Stream-Protokoll kann ein TCP-Paket mehr als eine PDU enthalten, und PDUs können 2 oder mehr TCP-Pakete umfassen. Wireshark wird PDUs korrekt zusammenstellen, sodass sie für den Wireshark-Benutzer größtenteils transparent sind.

Im Folgenden finden Sie ein Beispiel für PDUs, die beim Senden eines MT und anschließendem Empfangen eines SR durch das Netzwerk weitergeleitet werden:
smpp3
Hinweis: Die Liste der Standardbefehle finden Sie in Abschnitt 5.1.2.1 der SMPP-Spezifikation (SMPP-Befehlssatz).

SMPP-Antworten

Das SMPP-Protokoll erfordert, dass alle Befehle von einer Antwort-PDU quittiert werden:

BIND_TRANSMITTER wird durch  BIND_TRANSMITTER_RESPSUBMIT_SM  wird von  SUBMIT_SM_RESP, usw.

Es gibt eine Zeitüberschreitung für Antworten, normalerweise 10, 30 oder 60 Sekunden. Die Antwort kann eine positive Bestätigung (Befehl _status = 0) oder einen Fehler (siehe 5.1.3) enthalten.  command_statusTabelle 5-2  in der SMPP-Spezifikation für die Liste der Standardfehler). Meistens sind diese Antworten sofort und ein Antwort-Timeout wird nicht erreicht.

Achten Sie darauf, zwischen SMPP-Antwortfehlern und SR-Fehlercodes zu unterscheiden: derselbe Fehlercode kann im Antwortfehler oder im SR-Fehlerfeld unterschiedliche Bedeutungen haben. Wenn Sie einen Fehlercode melden, müssen Sie sehr genau darauf achten, wo Sie ihn gefunden haben, denn die Bedeutung des Wertes hängt von seinem Kontext ab.

SMPP-Verbindungsinitialisierung

Die SMPP-Verbindung beginnt mit der Verbindung über TCP. Dann wird ein BIND-Vorgang per Kampagne gesendet, der von einer BIND RESP bestätigt wird. Diese Vorgänge werden in Abschnitt 4.1 der SMPP-Spezifikation (BIND-Vorgang) beschrieben.

smpp4 Der Bindungsvorgang führt die Anmelde-/Kennwortprüfung durch und tauscht Informationen über den Plattformnamen, die Version und andere in der Spezifikation beschriebene Felder aus.

Hinweis: Die Anmeldung finden Sie im Feld system_id .

In Campaign sollte eine  BIND_TRANSMITTER  Paket beim Initiieren einer MT-Übertragung und einer  BIND_RECEIVER  packet when  nlsm  Trigger eine MO/SR-Verbindung.

Sender, Empfänger und Transceiver:  Der SMPP-Connector für Campaign Classic funktioniert in einem separaten Sender-/Empfängermodus: Es gibt zwei TCP-Verbindungen, eine zum Senden von MT und eine andere zum Empfangen von MO und SR. Beachten Sie, dass die TCP-Verbindung immer von Campaign initiiert wird, auch für den Empfängermodus.

SMPP bietet auch einen Transceiver-Modus. Dieser Modus wird jedoch für Campaign Classic nicht im SMPP-Connector implementiert.

Der SMPP-Connector verwendet mehrere parallele Verbindungen, um MT zu übertragen. Dies kann aufgrund der Art und Weise, wie der Connector entwickelt wurde, nicht gesteuert werden.

Empfangen von MO
Wenn der Empfänger gebunden ist, kann das SMS-C MO jederzeit senden. Der MO wird mithilfe einer  DELIVER_SM  PDU mit Bits 2-5 von  esm_clas s  clear (oft)  esm_class  ist einfach 0).

smpp5 Die *DELIVER_SM* PDU muss schnell von einem *DELIVER_SM_RESP* PDU mit dem gleichen *sequence_number*.

Senden von MT
Um ein MT zu senden, muss der Sender erfolgreich gebunden sein. Prüfen Sie vor allem, ob der Bindungsprozess erfolgreich durchgeführt wurde.

Der MT wird in einer  SUBMIT_SM  PDU. SMS-C sollte schnell mit einer  SUBMIT_SM_RESP  PDU: Dieses Antwortpaket ist besonders, da es die Kennung der Nachricht in der Datenbank der SMS-C enthält (immer diese ID angeben, wenn Sie mit dem SMS-C-Partner sprechen, um ihn bei der Suche nach der Nachricht zu unterstützen). Diese ID ist im SR enthalten und ist die einzige Möglichkeit, das MT dem entsprechenden SR zuzuordnen.

Das Feld  registered_delivery  (siehe Abschnitt 5.2.17 der Spezifikation) gibt dem SMS-C an, ob für diesen MT ein SR angefordert wird. Wenn Sie für eine bestimmte Nachricht keinen SR erhalten, überprüfen Sie, ob das Feld in der Variablen  SUBMIT_SM  PDU.

smpp5

Kodierung von MT

Achtung: Die SMS-Kodierung ist ein komplexes Thema mit vielen Fallen und verschiedenen Implementierungen.

Es empfiehlt sich, sich im Falle von Kodierungsproblemen stets an den SMS-C-Partner zu wenden. Ihr SMS-Partner verfügt über genaue Kenntnisse der unterstützten Kodierung und speziellen Regeln, die aufgrund von Einschränkungen in seiner technischen Plattform angewendet werden können. Lassen Sie sie überprüfen, was Sie ihnen senden und was sie Ihnen zurückschicken. Dies ist der einzige Weg zu einer erfolgreichen und stabilen Verbindung.

SMS-Nachrichten verwenden eine spezielle 7-Bit-Kodierung, die oft GSM7-Kodierung genannt wird. Siehe Wikipedia GSM 03.38 (auf Englisch).

Im SMPP-Protokoll wird der GSM7-Text auf 8 Bit pro Zeichen erweitert, um die Fehlerbehebung zu erleichtern. Das SMS-C packt ihn in 7 Bit pro Zeichen, bevor es an das Mobilgerät gesendet wird. Das bedeutet, dass das Feld „short_message“ der SMS im SMPP-Rahmen bis zu 160 Byte lang sein kann, während es beim Versand über das Mobilfunknetz auf 140 Byte begrenzt ist (das höchstwertige Bit wird einfach verworfen).

Bei Kodierungsproblemen sollten Sie Folgendes überprüfen:

  • Stellen Sie zunächst sicher, dass Sie wissen, welche Zeichen zu welcher Kodierung gehören. GSM7 ist berüchtigt für seine nur teilweise Unterstützung diakritischer Zeichen (Akzente). Besonders im Französischen, wo é und è zu GSM7 gehören, ê, â oder ï aber nicht. Die Situation in Bezug auf Spanisch ist nicht besser.
  • Das C mit Zedille (ç) ist im GSM7-Alphabet nur in Großbuchstaben vorhanden, aber einige Telefone geben es in Kleinbuchstaben oder „intelligenter“ Großschreibung wieder: die allgemeine Empfehlung ist, es ganz zu vermeiden und die Zedille zu entfernen (es ist im Französischen immer noch sehr gut lesbar) oder zu UCS-2 zu wechseln.
  • Verwenden Sie kein ASCII in SMS, es sei denn, der SMS-C-Partner verlangt dies ausdrücklich: Diese Kodierung verschwendet Platz, da sie 8-Bit-Zeichen und eine geringere Abdeckung als GSM7 hat.
  • Latin-1 wird nicht immer unterstützt: Fragen Sie bei Ihrem SMS-C-Partner nach der Kompatibilität, bevor Sie versuchen, Latin-1 zu verwenden.
  • Nationale Sprachverschiebungstabellen werden vom Adobe Campaign Classic-Connector nicht unterstützt. Sie müssen stattdessen UCS-2 verwenden.
  • UCS-2 und UTF-16 werden oft per Telefon gemischt. Dies ist ein Problem für Personen, die Emojis und andere selten verwendete Zeichen senden, die nicht in UCS-2 vorhanden sind.
  • Die GSM7-Kodierung wird von Wireshark nicht unterstützt: Sonderzeichen werden falsch angezeigt. Wenn Sie überprüfen müssen, ob eine GSM7-Zeichenfolge korrekt kodiert ist, müssen Sie Hexadezimalcodes mit der GSM7-Tabelle vergleichen.

Die  data_coding  gibt an, welche Kodierung verwendet wird. Das einzige Problem ist, dass der Wert 0 in der Spezifikation für die SMS-C-Standardkodierung steht, im Allgemeinen aber für GSM7. Mit SMS-C prüfen  Partner, welche Kodierung mit data_coding = 0 verknüpft ist (Adobe Campaign unterstützt nur GSM7 für data_coding)  = 0).

Die maximale Größe einer Nachricht hängt von ihrer Kodierung ab. In dieser Tabelle sind alle relevanten Informationen zusammengefasst:

Codierung
data_coding
Nachrichtengröße (Zeichen)
Größe der Teile für mehrteilige SMS
Verfügbare Zeichen
GSM7
0
160
152
GSM7-Standardzeichensatz + Erweiterung (Erweiterte Zeichen benötigen 2 Zeichen)
Latin-1
3
140
134
ISO-8859-1
UCS-2 UTF-16
8
70
67
Unicode (variiert von Telefon zu Telefon)

User Data Header (UDH)
UDH (User Data Header) sind kleine binäre Kopfzeilen, die zum Text einer SMS hinzugefügt werden. Sie können besondere Funktionen wie SMS-Verkettung, nationale Sprachverschiebungstabellen, Logos/Bilder (selten verwendet) oder WAP-Push auslösen.

Da der UDH Teil des Textfelds ist (SMPP-Feld „short_message“), verkürzt er die effektive Größe einer SMS. Beispielsweise verbraucht ein verketteter SMS-UDH 6 Byte pro SMS-Teil (d. h. 6 echte 8-Bit-Bytes, nicht 7-Bit-Zeichen), sodass nur für 152 7-Bit-Zeichen genügend Platz pro Nachrichtenteil bleibt.

Wikipedia hat nette Artikel über User Data Header und verkettete SMS (in englischer Sprache).

Um herauszufinden, ob „short_message“ einen UDH enthält, überprüfen Sie die Bits 6 und 7 von „esm_class“ (siehe Abschnitt 5.2.12 der Spezifikation). Wireshark analysiert UDH in der Benutzeroberfläche und gibt genaue Informationen.

smpp7 Im obigen Screenshot sehen Sie den Header der Benutzerdaten im Nachrichtenfeld (1), die Informationen in der UDH (2) und einige zusätzliche Informationen, die nicht zum Paket gehören, aber von Wireshark berechnet werden (3): Das Feld Short Message Body ist besonders interessant, da es die vollständige Nachricht enthält, die von Wireshark neu zusammengestellt wurde.

Empfangen von SR
Wenn der Empfänger gebunden ist, kann das SMS-C SR jederzeit senden. Der SR wird mit einer DELIVER_SM-PDU mit Bits 2-5 von  esm_class festgelegt ist.

smpp8

Die  DELIVER_SM  PDU muss schnell von einem  DELIVER_SM_RESP  PDU mit dem gleichen  sequence_number. Suchen Sie den MT, der diesem SR entspricht, nach einer  SUBMIT_SM_RESP  mit derselben ID. Dies ist beispielsweise der MT, der mit dem SR übereinstimmt:

smpp9

SR werden nur gesendet, wenn die  registered_delivery  im MT festgelegt ist.

Hinweis: Der Adobe Campaign Classic SMPP-Connector verarbeitet keine SR, die vor dem  SUBMIT_SM_RESP  Paket. Die Spezifikation verbietet dieses Verhalten nicht ausdrücklich, aber es wird als schlechtes Verhalten angesehen (es würde bedeuten, dass die Nachricht empfangen wurde, bevor sie gesendet wurde). Wenn Sie diesen Fall zu oft feststellen, bitten Sie Ihren SMS-C-Partner, seine Plattform zu reparieren.

Entschlüsseln des Felds „short_message“ des SR
Das Textfeld der SR-PDUs verfügt über eine spezielle Kodierung, die in Anhang B der SMPP-Protokollspezifikation beschrieben ist. Leider ist dieses Format nur eine Empfehlung und nicht Teil des Protokolls, auch wenn die meisten SMS-C mehr oder weniger genau dieses Format einhalten.

Sie sollten den SMS-C-Partner direkt um eine Dokumentation seiner eigenen Implementierung bitten und überprüfen, ob sie mit dem übereinstimmt, was Sie in Wireshark sehen. Oftmals kennen die SMS-C-Implementierer nicht einmal ihre eigene Implementierung, was zu Problemen und Missverständnissen führt. Fragen Sie den SMS-C-Partner um Hilfe, wenn Sie Zweifel bezüglich dieses Felds haben (insbesondere wegen der Fehlercodes).

Das Grundformat lautet wie folgt:

id:IIIIIIIIII sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDDDDDD err:EEE
Text:........

Dies sind allgemeine Leitlinien für das Lesen der obigen Zeile:

  • Die ID ist die gleiche, die im  SUBMIT_SM_RESP des entsprechenden MT.
  • Sie können Probleme im Textfeld ignorieren: Dieses Feld wird von Campaign ignoriert, da es nutzlos, unzuverlässig und sogar völlig unlesbar ist, wenn die SMS mit einer anderen Kodierung als reinem alphanumerischen ASCII gesendet wurde. Dies ist ein normales Verhalten.
  • Bei Feldnamen wird nicht zwischen Groß- und Kleinschreibung unterschieden (z. B. id: sub: Text: kann auch als ID vermerkt werden: SUB: text:).
  • Die  dlvrd-Feld ist im Allgemeinen nicht zuverlässig, es sei denn, es wird von dem SMS-C-Partner dokumentiert.
  • Die Datumsangaben können eine beliebige Zeitzone haben, was sie praktisch unbrauchbar macht, oder sie sind schlichtweg falsch, weil die Uhr des entfernten Servers falsch geht.
  • Die  stat-Feld kann andere als die in Anlage B definierten Werte aufweisen. Verwenden Sie den gesunden Menschenverstand und die Dokumentation des SMSC-Partners, um dessen Bedeutung zu verstehen.
  • Die  err-Feld hängt vollständig von der SMS-C ab, die meistens vom SMS-C-Partner dokumentiert wird. Oft bedeutet der Code 000 einen Erfolg, während jeder andere Code Fehler anzeigt. Das Feld ist häufig numerisch, kann aber auch hexadezimal sein.

Mehrere SR für dasselbe MT
Einige SMS-C senden mehrere SR für dasselbe MT, um den Fortschritt des MT im Netzwerk zu verfolgen. Dies ist zumeist nutzlos, da der Client in den meisten Fällen nur wissen möchte, wann die Nachricht empfangen wurde (dies ist in der Regel das letzte SR).

Im Zweifelsfall sollten Sie nur das letzte vom SMS-C empfangene SR verwenden, um den Status einer Nachricht zu ermitteln.

SMPP-Fenster
Da Vorgänge und Antworten asynchron sind, können Sie Übertragungsraten optimieren, indem Sie mehrere Vorgangs-PDUs senden, bevor Sie auf die Antworten warten. Die Anzahl der Nachrichten ohne Antwort wird als Fenster bezeichnet.

Beispiel einer Übertragung mit einem maximalen Fenster von 4:
smpp10
Die aktuelle Implementierung kontrolliert das Fenster nicht und erwartet, dass das Remote-SMS-C für die Handhabung von MT schnell genug ist.

recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f