TLVs (Optionalparameter, eingeführt in v3.4) erweitern eine PDU über ihre Pflichtfelder hinaus. Jedes wird als 2-Byte-Tag, 2-Byte-Length und ein Length Bytes langer Value codiert, alle Big-Endian. TLVs erscheinen nach dem Pflicht-Body in beliebiger Reihenfolge und lassen SMPP Nutzlasten, Verkettungs-Metadaten und Berichtskorrelation tragen, ohne das feste Feld-Layout zu ändern.
Das TLV-Format
Ein TLV (auch Optionalparameter genannt) ist ein selbstbeschreibendes Feld: Ein 2-Oktett-Tag identifiziert den Parameter, eine 2-Oktett-Length gibt die Größe des Value in Oktetten an, und der Value folgt. Sowohl Tag als auch Length sind Big-Endian. Weil sie mit Tags versehen sind, können TLVs nach den Pflichtparametern in beliebiger Reihenfolge erscheinen, und ein Empfänger überspringt einfach Tags, die er nicht erkennt.
04 24 Tag = 0x0424 (message_payload)
00 05 Length = 5 octets
48 65 6C 6C 6F Value = "Hello"Gängige TLV-Tags
Eine Handvoll TLVs erledigt den Großteil der Arbeit in der Produktion. message_payload trägt eine für short_message zu lange Nachricht. receipted_message_id und message_state machen Zustellberichte maschinell parsbar. Mit user_message_reference hängen Sie Ihre eigene Korrelations-ID an. Der sar_*-Satz bietet standardbasierte Verkettung ohne UDH-Bytes im Body.
| Tag | Name | Wert | Verwenden |
|---|---|---|---|
| 0x0424 | message_payload | Octet String | Nachrichteninhalt, wenn er short_message überschreitet |
| 0x001E | receipted_message_id | C-Octet String (65) | Ursprüngliches message_id in einem Zustellbericht |
| 0x0427 | message_state | Integer (1) | Endgültiger/vorläufiger Status in einer Zustellbestätigung (siehe unten) |
| 0x0204 | user_message_reference | Integer (2) | ESME-zugewiesene Korrelationsreferenz |
| 0x020C | sar_msg_ref_num | Integer (2) | Verkettung: gemeinsame Referenz über Segmente hinweg |
| 0x020E | sar_total_segments | Integer (1) | Verkettung: Gesamtzahl der Segmente |
| 0x020F | sar_segment_seqnum | Integer (1) | Verkettung: die Sequenz dieses Segments |
| 0x0423 | network_error_code | Octet String (3) | Netzspezifische Fehlerdetails in einer Zustellbestätigung |
| 0x0426 | more_messages_to_send | Integer (1) | Signalisiert, dass weitere Segmente folgen |
| 0x020A | source_port | Integer (2) | Anwendungsportadressierung (Quelle) |
| 0x020B | dest_port | Integer (2) | Anwendungsportadressierung (Ziel) |
message_state-Werte
Das message_state-TLV (0x0427) meldet den Lebenszyklus-Zustand einer Nachricht numerisch — das maschinenlesbare Gegenstück zum stat-Schlüsselwort des DLR-Textes. Diese Werte erscheinen auch in query_sm_resp.
| Wert | Status | DLR-stat-Schlüsselwort |
|---|---|---|
| 1 | ENROUTE | (unterwegs) |
| 2 | DELIVERED | DELIVRD |
| 3 | EXPIRED | EXPIRED |
| 4 | DELETED | DELETED |
| 5 | UNDELIVERABLE | UNDELIV |
| 6 | ACCEPTED | ACCEPTD |
| 7 | UNKNOWN | UNKNOWN |
| 8 | REJECTED | REJECTD |
| 9 | SKIPPED (v5.0) | — |
SAR-Verkettung vs. UDH
SMPP bietet zwei Wege, eine lange Nachricht zu verketten. Die UDH-Methode legt einen 6-Byte-User-Data-Header in short_message ab und setzt das esm_class-UDHI-Bit. Die SAR-Methode hält den Body sauber und trägt stattdessen die drei sar_*-TLVs. Wählen Sie eine Methode und bleiben Sie je Route konsistent — manche Netze akzeptieren nur UDH, andere nur SAR. Mischen Sie die beiden niemals in derselben Nachricht.
Regeln und Fallstricke
Befüllen Sie nicht sowohl short_message als auch message_payload — Anbieter weisen das zurück. Eigene TLVs außerhalb der von Ihrem Anbieter freigegebenen Bereiche werden häufig entfernt oder verursachen nachgelagert Parse-Fehler, senden Sie Metadaten daher nur in vereinbarten Tags. Ein Empfänger muss unbekannte TLVs tolerieren, indem er Length Bytes überspringt; eine fehlerhafte Length ist die klassische Ursache für einen verfälschten Parse von allem, was danach folgt.
Häufig gestellte Fragen
Wofür steht TLV in SMPP?
Tag-Length-Value. Jeder Optionalparameter wird als 2-Byte-Tag, 2-Byte-Length und so viele Bytes Value codiert. TLVs wurden in SMPP v3.4 eingeführt und erscheinen nach dem Pflicht-Body einer PDU.
Wann sollte ich message_payload statt short_message verwenden?
Verwenden Sie das message_payload-TLV (0x0424), wenn die Nachricht das 254-Oktett-Feld short_message überschreitet oder wenn Ihr Anbieter es für lange Inhalte bevorzugt. Setzen Sie nicht beide Felder in derselben PDU.
Wie korreliere ich einen Zustellbericht mit meiner eingereichten Nachricht?
Gleichen Sie das receipted_message_id-TLV (0x001E) im Bericht gegen die message_id ab, die Sie aus submit_sm_resp gespeichert haben. Normalisieren Sie zuerst die Formate, da manche SMSCs die ID beim Submit hexadezimal und im Bericht dezimal zurückgeben.
Sind sar_*-TLVs besser als UDH für die Verkettung?
Keines ist universell besser — es sind zwei Codierungen derselben Idee. SAR hält den Nachrichten-Body frei von Header-Bytes; UDH ist breiter akzeptiert. Verwenden Sie das, was Ihre Route unterstützt, und bleiben Sie konsistent.
Kann ich eigene TLVs hinzufügen?
Nur innerhalb des herstellerspezifischen Tag-Bereichs, den Ihr Anbieter freigibt. Nicht freigegebene eigene TLVs werden unterwegs häufig entfernt oder abgewiesen, vereinbaren Sie die Tags und ihre Bedeutung daher zuerst mit dem Anbieter.
Quellenspezifikationen
Diese Seite basiert auf den veröffentlichten Standards. (Wird in einem neuen Tab geöffnet.)