Les TLV (paramètres optionnels, introduits en v3.4) étendent une PDU au-delà de ses champs obligatoires. Chacun est encodé comme un Tag de 2 octets, une Length de 2 octets et une Value de Length octets, le tout en big-endian. Les TLV apparaissent après le corps obligatoire, dans n'importe quel ordre, et permettent au SMPP de porter des charges utiles, des métadonnées de concaténation et la corrélation des accusés sans modifier la disposition fixe des champs.
Le format TLV
Un TLV (aussi appelé paramètre optionnel) est un champ auto-descriptif : un Tag de 2 octets identifie le paramètre, une Length de 2 octets donne la taille de la Value en octets, et la Value suit. Tag et Length sont en big-endian. Parce qu'ils sont étiquetés, les TLV peuvent apparaître dans n'importe quel ordre après les paramètres obligatoires, et un récepteur ignore simplement les tags qu'il ne reconnaît pas.
04 24 Tag = 0x0424 (message_payload)
00 05 Length = 5 octets
48 65 6C 6C 6F Value = "Hello"Tags TLV courants
Une poignée de TLV fait l'essentiel du travail en production. message_payload porte un message trop long pour short_message. receipted_message_id et message_state rendent les accusés de réception analysables par machine. user_message_reference permet d'attacher votre propre id de corrélation. L'ensemble sar_* fournit une concaténation normalisée sans octets UDH dans le corps.
| Étiquette | Nom | Valeur | Utiliser |
|---|---|---|---|
| 0x0424 | message_payload | Octet String | Corps du message lorsqu'il dépasse short_message |
| 0x001E | receipted_message_id | C-Octet String (65) | message_id d'origine dans un accusé de réception |
| 0x0427 | message_state | Integer (1) | État final/intermédiaire d'un reçu (voir ci-dessous) |
| 0x0204 | user_message_reference | Integer (2) | Référence de corrélation attribuée par l'ESME |
| 0x020C | sar_msg_ref_num | Integer (2) | Concaténation : référence partagée entre les segments |
| 0x020E | sar_total_segments | Integer (1) | Concaténation : nombre total de segments |
| 0x020F | sar_segment_seqnum | Integer (1) | Concaténation : la séquence de ce segment |
| 0x0423 | network_error_code | Octet String (3) | Détails de la panne spécifique au réseau dans un reçu |
| 0x0426 | more_messages_to_send | Integer (1) | Indique que d'autres segments suivent |
| 0x020A | source_port | Integer (2) | Adressage des ports d'application (source) |
| 0x020B | dest_port | Integer (2) | Adressage du port d'application (destination) |
Valeurs de message_state
Le TLV message_state (0x0427) rapporte l'état du cycle de vie d'un message sous forme numérique — le pendant lisible par machine du mot-clé stat du texte de DLR. Ces valeurs apparaissent aussi dans query_sm_resp.
| Valeur | État | Mot-clé stat du DLR |
|---|---|---|
| 1 | ENROUTE | (en transit) |
| 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) | — |
Concaténation SAR vs UDH
Le SMPP offre deux façons de concaténer un long message. La méthode UDH place un User Data Header de 6 octets dans short_message et positionne le bit UDHI d'esm_class. La méthode SAR garde le corps propre et porte à la place les trois TLV sar_*. Choisissez-en une et restez cohérent par route — certains réseaux n'acceptent que l'UDH, d'autres que le SAR. Ne mélangez jamais les deux sur un même message.
Règles et pièges
Ne renseignez pas à la fois short_message et message_payload — les fournisseurs le rejettent. Les TLV personnalisés hors des plages approuvées par votre fournisseur sont souvent supprimés ou provoquent des erreurs d'analyse en aval ; n'envoyez donc de métadonnées que dans les tags convenus. Un récepteur doit tolérer les TLV inconnus en sautant les octets Length ; une Length malformée est la cause classique d'une analyse corrompue de tout ce qui suit.
Questions fréquemment posées
Que signifie TLV en SMPP ?
Tag-Length-Value. Chaque paramètre optionnel est encodé comme un tag de 2 octets, une length de 2 octets, et ce nombre d'octets de valeur. Les TLV ont été introduits en SMPP v3.4 et apparaissent après le corps obligatoire d'une PDU.
Quand utiliser message_payload plutôt que short_message ?
Utilisez le TLV message_payload (0x0424) lorsque le message dépasse le champ short_message de 254 octets, ou lorsque votre fournisseur le préfère pour du contenu long. Ne renseignez pas les deux champs sur la même PDU.
Comment corréler un accusé de réception avec mon message soumis ?
Rapprochez le TLV receipted_message_id (0x001E) de l'accusé du message_id que vous avez conservé depuis submit_sm_resp. Normalisez d'abord les formats, car certains SMSC renvoient l'id en hexadécimal au submit et en décimal dans l'accusé.
Les TLV sar_* sont-ils meilleurs que l'UDH pour la concaténation ?
Aucun n'est universellement meilleur — ce sont deux encodages de la même idée. Le SAR garde le corps du message exempt d'octets d'en-tête ; l'UDH est plus largement accepté. Utilisez ce que votre route prend en charge et restez cohérent.
Puis-je ajouter mes propres TLV personnalisés ?
Seulement dans la plage de tags propres au fournisseur qu'il approuve. Les TLV personnalisés non approuvés sont fréquemment supprimés ou rejetés en transit ; convenez donc des tags et de leur signification avec le fournisseur au préalable.
Spécifications sources
Les normes publiées sur lesquelles repose cette page. S'ouvre dans un nouvel onglet.