Die Referenz zum Messaging-Protokoll.
Ein präzises, standardbasiertes Nachschlagewerk für die Protokolle zur SMS-Übertragung – speziell für die Ingenieure, die diese implementieren. Es basiert auf den SMPP -Spezifikationen v3.4/v5.0 und 3GPP TS 23.038/23.040 und enthält reale Byte-Layouts, Feldtabellen und Beispiele für die Datenformatierung.
65 Dokumente zu 9 Protokollen
SMPP
Das Short Message Peer-to-Peer-Protokoll – das binäre Sitzungsprotokoll, das Carrier und Aggregatoren für A2P Messaging mit hohem Durchsatz bereitstellen.
- Grundlagen
SMPP-Protokoll im Überblick
Was SMPP ist, wie die ESME↔SMSC-Sitzung funktioniert, der Unterschied zwischen v3.4 und v5.0 und warum es der Standard für A2P-SMS mit hohem Durchsatz bleibt.
- Wire-Format
SMPP-PDU-Anatomie: Header und Body
Das exakte Byte-Layout einer SMPP-PDU: der 16-Byte-Header (command_length, command_id, command_status, sequence_number), der Body und wie Felder codiert werden.
- Sitzung
SMPP-Bind-Operationen und Sitzungszustände
Wie sich eine SMPP-Sitzung authentifiziert: bind_transmitter, bind_receiver und bind_transceiver, die Felder system_id/password/system_type, interface_version, Sitzungszustände und Unbind.
- Operationen
SMPP submit_sm: jedes Pflichtfeld
Eine vollständige feldweise Referenz für submit_sm — service_type, TON/NPI, esm_class, data_coding, registered_delivery, validity_period, short_message und den Rest — mit den Werten, die wirklich zählen.
- Operationen
SMPP deliver_sm: MO-Nachrichten und Berichte
deliver_sm trägt zwei Dinge vom SMSC zur ESME: mobil-originierte (MO) Nachrichten und Zustellberichte. Wie man sie über esm_class unterscheidet und warum man stets mit deliver_sm_resp antworten muss.
- Fehler
SMPP-command_status-Fehlercodes
Das SMPP-Feld command_status und der ESME_R*-Fehlerbereich: was die gängigen Codes bedeuten (ESME_RINVPASWD, ESME_RTHROTTLED, ESME_RMSGQFUL …) und wie man auf jeden reagiert.
- Wire-Format
SMPP-TLV-Optionalparameter
Die Optionalparameter von SMPP verwenden ein Tag-Length-Value-Format. Das TLV-Byte-Layout plus die gängigen Tags: message_payload, receipted_message_id, message_state, user_message_reference und der sar_*-Verkettungssatz.
- Operationen
SMPP-Zustellberichte (DLR): Format
Das Zustellbericht-Textformat gemäß Appendix B innerhalb von deliver_sm: id, sub, dlvrd, submit date, done date, stat, err und Text — plus die stat-Schlüsselwörter und ihre message_state-Nummern.
- Sitzung
SMPP enquire_link, Windowing und Drosselung
Wie SMPP eine Sitzung mit enquire_link am Leben hält, wie das Fenster ausstehende unbestätigte PDUs begrenzt und wie ESME_RTHROTTLED und TPS je Bind Ihren tatsächlichen Durchsatz bestimmen.
- Sicherheit
SMPP absichern: TLS, Auth und IP-Allowlisting
SMPP hat keine native Verschlüsselung. Wie man einen Bind produktiv absichert: SMPP über TLS, Authentifizierung per Zugangsdaten und IP-Basis, Allowlisting und Zugangsdaten-Hygiene.
- Grundlagen
SMPP v3.4 vs. v5.0: was sich geändert hat
Die praktischen Unterschiede zwischen SMPP v3.4 und v5.0: Congestion Control, Broadcast-Operationen, zusätzliche Nachrichtenzustände und TLVs — und warum v3.4 weiterhin die Standardkopplung ist.
- Integration
SMPP-Integration: Best Practices
Wie man eine SMPP-Integration baut, die produktiv zuverlässig bleibt: Bind-Strategie, sequence_number-Disziplin, Windowing, Retries mit Backoff, Idempotenz, DLR-Verarbeitung und Reconnect.
SMS-Codierung
Wie SMS-Texte über die Leitung kodiert werden – GSM 7-Bit, UCS-2, Datenkodierungsverfahren, Segmentierung und die Kostenfolgen jedes einzelnen Zeichens.
- Zeichensätze
Der GSM-7-Zeichensatz
Das vollständige GSM-7-Bit-Standardalphabet aus GSM 03.38: die Basistabelle mit 128 Zeichen, die Escape-basierte Erweiterungstabelle (| ^ € { } [ ] ~ \ und Form Feed) und wie das 7-Bit-Packing funktioniert.
- Zeichensätze
UCS-2 und Unicode-SMS
Wie SMS Unicode über UCS-2 (16 Bit) trägt: das 70-Zeichen-Limit einer einzelnen Nachricht, 67 je verkettetem Segment, was UCS-2 erzwingt und der Surrogatpaar-Vorbehalt bei Emojis.
- Data Coding
Das Data Coding Scheme (DCS)
Das Data-Coding-Scheme-Byte, das dem Netz mitteilt, wie eine SMS codiert ist: GSM-7 (0x00), 8-bit (0x04), UCS-2 (0x08) plus Nachrichtenklassen (0/Flash bis 3/SIM) aus GSM 03.38.
- Segmentierung
SMS-Segmentierung, Verkettung und der UDH
Wie lange SMS zerlegt und wieder zusammengesetzt werden: der 6-Byte-User-Data-Header, die daraus resultierenden 153 (GSM-7) und 67 (UCS-2) Zeichen je Segment, die Referenznummer und die Segmentsequenzierung.
- Kosten
Codierungserkennung und SMS-Kosten
Wie man erkennt, ob Text GSM-7 oder UCS-2 ist, welche Zeichen stillschweigend UCS-2 erzwingen und wie die Codierung die Segmentzahl — und damit die Kosten — jeder gesendeten SMS bestimmt.
SS7 / MAP
Signalisierungssystem Nr. 7 und die MAP Schicht, die mobile SMS, HLR Abfragen und Mobilitätsmanagement über bestehende Kernnetze hinweg übertragen.
- Grundlagen
SS7-Stack im Überblick: MTP, SCCP, TCAP, MAP, ISUP
Wie der SS7-Stack geschichtet ist — MTP1-3-Transport, SCCP-Adressierung, TCAP-Transaktionen sowie die MAP- und ISUP-User-Parts — und welche Schicht was für SMS, Anrufe und Mobilität leistet.
- Transport
MTP: der Message Transfer Part (Ebenen 1-3)
Die drei MTP-Ebenen, die SS7 transportieren: MTP1-Physikverbindungen, MTP2-fehlerkontrollierte Sicherungsschicht (MSU/LSSU/FISU-Signaleinheiten) und MTP3-Routing per Point Code mit Lastteilung und Netzmanagement.
- Adressierung
SCCP, Global Title Translation und Subsystem-Nummern
Wie SCCP MTP3 um Global-Title-Adressierung erweitert: die Called/Calling Party Address, Global Title Translation (GTT), Subsystem-Nummern (HLR/VLR/MSC) und verbindungslose vs. verbindungsorientierte Klassen.
- Transaktionen
TCAP: Transaktionen, Dialoge und Komponenten
Wie TCAP SS7-Anwendungsaustausche strukturiert: der Transaktions-Sublayer (Begin/Continue/End/Abort mit Transaction-IDs), der Dialog-Anteil (Application Context) und der Komponenten-Sublayer (Invoke, ReturnResult, ReturnError, Reject).
- MAP
MAP-Operationen: SRI-SM, ForwardSM, UpdateLocation und mehr
Die MAP-Operationen, die Mobilnetze betreiben: SendRoutingInfoForSM und MT-ForwardSM für SMS, UpdateLocation für Roaming, ProvideSubscriberInfo und AnyTimeInterrogation für den Standort — mit ihren TS-29.002-Opcodes.
- SMS-Zustellung
SS7-MT-SMS-Zustellablauf, Schritt für Schritt
Der vollständige Pfad mobil-terminierter SMS über SS7: SMSC zu HLR SendRoutingInfoForSM, HLR gibt IMSI + bedienende MSC zurück, SMSC zu MSC MT-ForwardSM, Paging und Zustellung sowie der Absent-Subscriber-Retry über MWD und AlertServiceCentre.
- Adressierung
SS7-Point-Codes und Netzadressierung
Wie SS7 Signalisierungspunkte adressiert: ITU-T-14-bit- vs. ANSI-24-bit-Point-Codes, ihre Zonen-/Netzstruktur, das OPC/DPC/SLS-Routing-Label und wie Point Codes zu SCCP-Global-Titles in Beziehung stehen.
- Sicherheit
SS7-Sicherheitsbedrohungen und die GSMA-FS.11-Kategorien
Die wichtigsten SS7-Angriffsklassen — Standort-Tracking, SMS-/OTP-Abfangen, Anrufumleitung und Betrug — und wie GSMA FS.11 MAP-Nachrichten kategorisiert (Kategorien 1/2/3), damit Signalisierungs-Firewalls sie filtern können.
- Grundlagen
SS7 vs. SIGTRAN: TDM-Signalisierung über IP
Wie SIGTRAN sich zu klassischem SS7 verhält: dieselbe MTP3/SCCP/TCAP/MAP-Anwendungsschicht, aber über IP mit SCTP und M3UA (oder SUA) statt über TDM-MTP1/MTP2-Verbindungen getragen.
SIGTRAN
SS7 -Signalisierung über IP — M3UA, SUA und SCTP — die Brücke zwischen TDM Signalisierung und modernen Paketkernen.
- Grundlagen
SIGTRAN im Überblick: SS7-Signalisierung über IP
Was SIGTRAN ist: das IETF-Framework (RFC 2719) zum Tragen von SS7-Signalisierung über IP, mit SCTP-Transport und Adaptationsschichten (M3UA, SUA, M2PA), die den MTP3/SCCP/TCAP/MAP-Anwendungsstack bewahren.
- Transport
SCTP: Stream Control Transmission Protocol
Wie SCTP funktioniert und warum SIGTRAN es nutzt: nachrichtenorientierte Zustellung, Multi-Streaming gegen Head-of-Line-Blocking, Multi-Homing für Pfad-Failover, das Chunk-basierte Paketformat und wie es sich von TCP unterscheidet.
- Adaptation
M3UA: MTP3-User-Adaptation-Layer
Wie M3UA SCCP und ISUP über SCTP trägt: die SG/ASP/AS-Rollen, Routing Keys und Routing Contexts, Nachrichtenklassen (Transfer, SSNM, ASPSM, ASPTM) und IPSP- vs. Signalling-Gateway-Modi.
- Adaptation
M2PA- und SUA-Adaptationsschichten
Zwei weitere SIGTRAN-Adaptationsschichten: M2PA (RFC 4165) ersetzt MTP2, um IP-basierte STP-Verbindungen mit vollständigem MTP3 aufzubauen, und SUA (RFC 3868) trägt SCCP-User (TCAP/MAP) direkt über SCTP und umgeht MTP3.
- Architektur
SIGTRAN-Deployment-Architektur: SG, ASP, AS
Wie ein SIGTRAN-Netz aufgebaut ist: das Signalling Gateway, das TDM und IP überbrückt, Application Server und ihre Prozesse, SCTP-Assoziationen und die Redundanzmodi (Override, Load-share, Broadcast), die Carrier-Grade-Verfügbarkeit geben.
SIP / VoIP
Das Session Initiation Protocol (SIP) ist die Grundlage für programmierbare Sprachübertragung, SIP-Trunking und VoLTE Anrufsteuerung sowie der dazugehörige Medienstack.
- Grundlagen
SIP-Protokoll im Überblick
Was SIP ist und wie es funktioniert: ein textbasiertes Request/Response-Signalisierungsprotokoll (RFC 3261), das Mediensitzungen aufbaut, ändert und abbaut, seine User Agents, Proxies und Registrars sowie seine Transaktionen und Dialoge.
- Requests
SIP-Methoden und -Requests
Jede SIP-Request-Methode und ihre Funktion: die sechs Kernmethoden von RFC 3261 (INVITE, ACK, BYE, CANCEL, REGISTER, OPTIONS) und die gängigen Erweiterungen (INFO, PRACK, UPDATE, SUBSCRIBE/NOTIFY, REFER, MESSAGE, PUBLISH).
- Responses
SIP-Response-Codes (1xx-6xx)
Die sechs Klassen von SIP-Response-Codes und die relevanten: 1xx provisorisch (100 Trying, 180 Ringing), 2xx Erfolg (200 OK), 3xx Umleitung, 4xx Client-Fehler (404, 486), 5xx Server-Fehler und 6xx globaler Fehler.
- Nachrichten
SIP-Header: Via, From, To, Call-ID, CSeq, Contact
Die wesentlichen SIP-Header und ihre Funktion: Via (mit dem branch-Parameter) zum Routen von Responses, From/To mit Tags, Call-ID, CSeq, Contact, Max-Forwards und wie Dialoge und Transaktionen daraus identifiziert werden.
- Medien
SDP: das Session Description Protocol
Wie SDP eine Mediensitzung innerhalb von SIP beschreibt: die Zeilenstruktur v=/o=/s=/c=/t=/m=/a=, das Offer/Answer-Modell (RFC 3264), die Codec-Aushandlung über rtpmap und die Medienrichtungs-Attribute.
- Medien
RTP und SRTP: der Medienstrom
Wie die Medien fließen, sobald SIP einen Anruf aufgebaut hat: der RTP-Header und die Nutzlast, RTCP-Qualitätsberichte sowie SRTP-Verschlüsselung und -Authentifizierung mit Schlüsselaustausch über SDES oder DTLS-SRTP.
- Anrufablauf
SIP-Anrufablauf: INVITE bis BYE
Ein vollständiger SIP-Anruf Schritt für Schritt: INVITE mit SDP-Offer, 100 Trying, 180 Ringing, 200 OK mit SDP-Answer, das Drei-Wege-ACK, RTP-Medien und der BYE/200-OK-Abbau — plus wie CANCEL einen klingelnden Anruf abbricht.
- Deployment
SIP-Trunking und der Session Border Controller
Was ein SIP-Trunk ist und die Rolle des Session Border Controllers (SBC): NAT-Traversal mit STUN/TURN/ICE, Topology Hiding über B2BUA, Sicherheit und Admission Control an der Netzgrenze sowie Transcoding.
DIAMETER
Das AAA und Signalisierungsprotokoll hinter 4G/5G-Mobilität, Richtlinien und Abrechnung (S6a, Gx, Gy), IMS Steuerung (Cx / Sh) und Diameter-Roaming-Sicherheit am IPX Rand.
- Grundlagen
DIAMETER-Basisprotokoll: RFC 6733 erklärt
Wie das DIAMETER-Basisprotokoll gemäß RFC 6733 funktioniert: der 20-Byte-Nachrichten-Header, Command Codes und R/P/E/T-Flags, der CER/CEA-Fähigkeitsaustausch, DWR/DWA-Watchdog und DPR/DPA-Trennung, über SCTP oder TCP/TLS.
- Nachrichtenformat
DIAMETER-AVPs, Datentypen und Result-Code
Die Anatomie eines DIAMETER-AVP: Code, V/M/P-Flags, Länge, optionale Vendor-Id und Daten; die Basisdatentypen (Enumerated, Unsigned32, OctetString, Address, Time); Grouped-AVPs; und das Fehlermodell aus Result-Code / Experimental-Result.
- Grundlagen
DIAMETER vs. RADIUS: warum DIAMETER RADIUS ablöste
Warum DIAMETER (RFC 6733) RADIUS (RFC 2865) für Carrier-AAA ablöste: zuverlässiger SCTP-Transport und Failover, Fähigkeitsverhandlung, ein weit größerer 32-Bit-AVP-Raum, Peer-Discovery, reichere Fehlerbehandlung und stärkere Sicherheit — mit Vergleichstabelle und Migrationshinweisen.
- Mobilität (HSS)
DIAMETER S6a/S6d: LTE-Mobilität zum HSS
Wie LTE-Mobilität und Subskriptionsverwaltung über DIAMETER S6a (MME↔HSS) und S6d (SGSN↔HSS) gemäß 3GPP TS 29.272 laufen: ULR/ULA, AIR/AIA, CLR/CLA, PUR/PUA und IDR/IDA, EPS-AKA-Authentifizierungsvektoren und die von ihnen ersetzten SS7-MAP-Operationen.
- Policy & Charging
DIAMETER Gx und Gy: Policy- und Charging-Steuerung
Wie DIAMETER Policy and Charging Control überträgt: Gx (PCEF↔PCRF, CCR/CCA zum Installieren von PCC-Regeln), Gy (Online-Charging zum OCS mit Kontingent) und Rf (Offline-Charging zur CDF) — plus die Rollen PCRF/PCEF/OCS/OFCS und die Schnittstellen QoS/QCI sowie Sy/Sd.
- IMS
DIAMETER Cx/Dx und Sh: IMS-Registrierung und das HSS
Wie IMS-Registrierung und -Authentifizierung über DIAMETER Cx/Dx (S-CSCF/I-CSCF↔HSS) gemäß 3GPP TS 29.228/29.229 laufen — UAR/UAA, MAR/MAA, SAR/SAA, LIR/LIA — plus die Sh-Schnittstelle (AS↔HSS) und wie diese an SIP REGISTER anknüpfen.
- Sicherheit
DIAMETER-Roaming-Sicherheit: DRA, DEA und die IPX-Grenze
Wie Diameter-Routing und Interconnect-Sicherheit an der Roaming-Grenze funktionieren: der Diameter Routing Agent (DRA) und Diameter Edge Agent (DEA), realm-basiertes Routing, die FS.19-Bedrohungsklassen (Informationsoffenlegung, Standortverfolgung, Betrug), Topology Hiding und AVP-Filterung.
Messaging-Kanäle
Die Messaging-Kanäle der Anwendungsschicht, über die Unternehmen senden: RCS Business Messaging / MaaP, WhatsApp Business Cloud API, MMS (MM1 / MM4 / MM7), verifizierter und gebrandeter Absender sowie Kanal-Fallback-Orchestrierung.
- RCS
RCS Business Messaging und die MaaP-Plattform
Wie RCS Business Messaging funktioniert: das GSMA Universal Profile (RCC.07), die Messaging-as-a-Platform-Architektur (RCC.71), verifizierte Agenten, Capability-Discovery, MO/MT-Flüsse und Abrechnungsereignisse — und wie die RBM-Agenten-API sich von einem SMPP-Bind unterscheidet.
- WhatsApp
WhatsApp Business Platform: Cloud API und Templates
Wie die WhatsApp Business Platform funktioniert: Cloud API vs. On-Premises API, Template-Nachrichten (HSM) vs. Session-Nachrichten, das 24-Stunden-Kundenservicefenster, die Kategorien Marketing/Utility/Authentication, Webhooks, Qualitätsstufen von Rufnummern und Opt-in.
- MMS
MMS-Architektur: die Schnittstellen MM1, MM4 und MM7
Wie MMS gemäß 3GPP TS 23.140 und OMA MMS funktioniert: das MMSC/Relay-Server, MM1 (Endgerät↔MMSC über WAP/HTTP), MM4 (MMSC↔MMSC über SMTP für den Verkehr zwischen Betreibern), MM7 (VASP↔MMSC über SOAP/XML), MIME/SMIL-Inhalt, Größenlimits und A2P-MMS.
- Vertrauen & Branding
Verifizierte und gebrandete Sender-Nachrichten
Wie Marken kanalübergreifend belegen, wer sie sind: RCS Verified Sender und verifizierte Business-Agenten, GSMA-Sender-ID-Registrierung und Markenverifizierung sowie VMC-Zertifikate mit BIMI für verifizierte Logos in E-Mail — die Kontrollen gegen Spoofing und Impersonation.
- Entscheidungsmatrix
RCS vs. SMS vs. WhatsApp: eine Kanal-Entscheidungsmatrix
Ein herstellerneutraler Vergleich von RCS, SMS und WhatsApp für Business Messaging: Funktionen, Reichweite und Abdeckung, Ende-zu-Ende-Verschlüsselung, Lesebestätigungen und Schreibanzeige, reichhaltige Medien, Kostenmodelle, Fallback-Verhalten und regulatorische Beschränkungen — mit Hinweisen, wann welcher zu nutzen ist.
- Orchestrierung
Kanal-Fallback und Omnichannel-Orchestrierung
Wie Omnichannel-Zustellung über Kanäle kaskadiert: Capability-Prüfungen, RCS→SMS- und WhatsApp→SMS-Fallback, Least-Cost- versus Best-Experience-Routing, Retry- und Timeout-Regeln sowie eine einheitliche Zustellbericht-Sicht, die den Status über jeden Kanal abgleicht.
- Interaktiv
Rich Cards und interaktives Messaging
Die interaktiven Bausteine von RCS und WhatsApp: Rich Cards und Karussells, Antwortvorschläge und Aktionen, Schnellantwort-Buttons und Listenauswahl — mit Beispiel-JSON-Payloads je Plattform sowie UX- und Barrierefreiheitshinweisen.
Nummerierung und Identität
Die Nummerierungs- und Identitätsebene, die jeder Nachricht und jedem Anruf zugrunde liegt: E.164 / MSISDN, MCC-MNC / PLMN Codes, IMSI / IMEI Teilnehmeridentität, ENUM (E.164 → URI) und Routing der Mobilfunknummernmitnahme.
- Öffentliche Nummerierung
E.164-Nummerierung und die MSISDN erklärt
Wie der internationale Nummerierungsplan ITU-T E.164 funktioniert: Ländervorwahlen, National Destination Code (NDC) und Teilnehmernummer, die Höchstlänge von 15 Stellen, der MSISDN-Aufbau und wie man Nummern für A2P-Messaging auf E.164 normalisiert.
- Netzidentität
MCC, MNC und PLMN-Codes erklärt (E.212)
Wie der Identifizierungsplan ITU-T E.212 funktioniert: der 3-stellige Mobile Country Code (MCC) und der 2–3-stellige Mobile Network Code (MNC), die zu einer PLMN-Identität verschmelzen, wie sie das Heimnetz identifizieren, Testbereiche und wie sich MCC-MNC vom NDC der MSISDN unterscheidet.
- Teilnehmeridentität
IMSI, IMEI und Teilnehmeridentität erklärt
Die Identitäten, die einen Teilnehmer von einem Gerät unterscheiden: die IMSI (MCC+MNC+MSIN, E.212), die IMEI (TAC+Seriennummer), der Authentifizierungsschlüssel Ki, die temporären Identitäten TMSI/GUTI, die SIM/USIM/eSIM (eUICC) und wie das HLR die MSISDN auf die IMSI abbildet.
- Nummern-Routing
ENUM: E.164-Nummern auf URIs abbilden
Wie ENUM (IETF RFC 6116) E.164-Rufnummern über DNS auf URIs abbildet: die Domain e164.arpa mit umgekehrten Ziffern, NAPTR-Records mit Regexp-Umschreibung und der Unterschied zwischen öffentlichem (Nutzer-) und privatem (Carrier-/Infrastruktur-)ENUM für SIP- und VoIP-Routing.
- Nummern-Routing
Mobile Rufnummernportierung und Routing
Wie die mobile Rufnummernportierung (MNP) die Verbindung zwischen einer gewählten Nummer und ihrem Heimnetz aufbricht: Routing Numbers (RN), All-Call-Query vs. Onward Routing, MNP-Datenbanken und -Dips und wie HLR-/MNP-Lookup Least-Cost-Routing und zuverlässige Zustellung antreibt.
HTTP-API & Webhooks
Die HTTP/ REST Schicht über den Netzwerkprotokollen: REST Messaging API-Design, Webhook-Übermittlung und HMAC -Signaturprüfung, Status/eingehende Nutzdaten, Authentifizierung und Signierung, Idempotenz, Ratenbegrenzung und problem+json Fehler – standardbasiert (RFC 9457, IETF-Entwürfe).
- API-Design
REST-Messaging-API-Design: Ressourcen, Methoden, Statuscodes
Modell einer standardbasierten REST-Messaging-API: messages-Collection, HTTP-Methoden und Statuscodes nach RFC 9110, asynchrones Senden mit 202 Accepted plus Callback, Content Negotiation und Versionierung — mit REST-vs-SMPP-Tabelle.
- Webhooks
Webhook-Zustellung und Zuverlässigkeit: Retries, Reihenfolge, Dead-Letter
Die standardmäßige Webhook-/Callback-Architektur und ihr Zuverlässigkeitsmodell: at-least-once-Zustellung, exponentieller Backoff mit Jitter bei Retries, Zustell-Timeouts, Reihenfolgegarantien, Dead-Letter-Queues, idempotente Consumer und Endpoint-Health.
- Sicherheit
Webhook-Signaturverifizierung: HMAC-SHA256 und Replay-Schutz
Wie man verifiziert, dass ein webhook authentisch und unverändert ist: HMAC-SHA256 über den rohen Body, die Signatur- und Timestamp-Header, Replay-Schutz per Timestamp-Toleranz und Nonce, konstantzeitiger Vergleich gegen Timing-Angriffe und sichere Secret-Rotation.
- Webhooks
Nachrichtenstatus (DLR) und Inbound (MO) — Webhook-Payloads
Die Payload-Schemata der beiden zentralen Messaging-Callbacks: das Delivery-Status-Event (DLR) mit Message-ID, Status-Enum, Fehlergrund und Zeitstempeln und das Inbound-Event (MO) — plus eine Event-Typ-Taxonomie und wie ein HTTP-DLR auf ein SMPP-deliver_sm-Receipt abgebildet wird.
- Sicherheit
API-Authentifizierung und Request-Signierung: Tokens, HMAC, OAuth, mTLS
Die Standardwege, eine HTTP-Messaging-API zu authentifizieren: bearer tokens und API-Keys im Authorization-Header, HMAC-Request-Signierung über einen kanonischen Request, Key-Scoping und -Rotation, mutual TLS und OAuth 2.0 Client-Credentials für Machine-to-Machine-Zugriff.
- Zuverlässigkeit
Idempotenz und Rate Limiting: Keys, 429, Retry-After, RateLimit
Zwei standardnahe HTTP-Muster für sichere, wohlerzogene Clients: der Idempotency-Key-Header (IETF-Draft) für Exactly-once-Einreichung mit Dedup-Fenster und Response-Replay, und Rate Limiting — 429 mit Retry-After, die RateLimit-/RateLimit-Policy-Header, Token Buckets und Client-Backpressure.
- API-Design
API-Fehler (problem+json) und Pagination (cursor, Link-Header)
Zwei Standards, die eine HTTP-API berechenbar halten: RFC 9457 problem+json für maschinenlesbare Fehler (type, title, status, detail, instance) mit einer retryable-vs-terminal-Taxonomie und Pagination — cursor vs. offset, der RFC-8288-Link-Header für next/prev und Page-Size-Limits.
Von der Spezifikation bis zum Kabel.
Diese Referenzen beschreiben die Protokolle, die BroadNet seit 2003 auf Carrier-Niveau in 200+ Ländern und über 1.000+ Betreiberverbindungen betreibt. Wenn Sie bereit sind zu senden, führen Sie die unten stehenden Dokumente und Tools vom Lesen bis zum Versand.