SMPP kézbesítési jelentés formátuma

Az SMPP kézbesítési jelentéseket az SMPP Szerver küldi az SMPP kliensnek, miután a szöveges üzenet sikeresen kézbesítésre került a kézbeszkészülékre. Az eredeti SMS-t az SMPP kliens küldi el egy smpp submit_sm kéréssel. Amikor a submit_sm-t elfogadja az SMPP szerver, egy submit_sm_resp választ küld vissza, egy SMS referencia azonosítóval. A kézbesítési jelentés később érkezik meg. Ez tartalmazza a kézbesítés időpontját és az SMS referencia azonosítót, amely az SMS-t azonosítja. Az alábbi dokumentum elmagyarázza az SMPP kézbesítési jelentés PDU tartalmát és példát mutat a kézbesítési jelentésre.

Mi az az smpp kézbesítési jelentés formátuma

Az smpp kézbesítési jelentés szabványos szöveges üzenetként érkezik. Az üzenet szövege speciális formátumú, amely különféle mezőket tartalmaz az eredetileg elküldött SMS-ről. Ezek a mezők segítségével meghatározható az SMS kézbesítés állapota.

Kézbesítési jelentés példa

Kézbesítési jelentés érkezett. +44251234567->+0000000 'Kézbesítve; Címzett: +44251234567; Időpont: 2022-10-03 12:07:00; 
Ref: 636445148; id:636445148 sub:000 dlvrd:001 beküldés dátuma:2210031207 kézbesítés dátuma:2210031207 
stat:DELIVRD err: szöveg:'

Sikeres kézbesítés jelentve az admin@localhost címre. Feladat azonosító: cdfd66e1-880e-4ead-a559-7ca46d9ec669. 
Kézbesítve; Címzett: +44251234567; Időpont: 2022-10-03 12:07:00; Ref: 636445148; id:636445148 sub:000 dlvrd:001 
beküldés dátuma:2210031207 kézbesítés dátuma:2210031207 stat:DELIVRD err: szöveg:

Hogyan kapjunk SMPP kézbesítési jelentést

Az SMPP kézbesítési jelentés fogadásához

1. Kapcsolódj az SMPP klienssel
2. Kötődj transceiverként
3. Küldd el az SMS-t a submit_sm pdu-val
4. Jegyezd fel az SMS azonosítót a submit_sm_resp-ből
5. Várj, amíg az SMS megérkezik a mobilra
6. Fogadd az SMS kézbesítési jelentés pdu-t
7. Párosítsd az SMS azonosítót az elküldött üzenettel
8. Jegyezd fel az SMS kézbesítés időpontját

SMPP kézbesítési jelentés paraméterei

Az SMPP támogatja a kézbesítési visszaigazolásokat / jelentéseket (DLR-eket) SMS üzenetekhez, így az alkalmazásod meghatározhatja az SMS kézbesítés eredményét.

A kézbesítési visszaigazolás / jelentés (DLR) visszaküldése függ a registered_delivery mezőben beállított értéktől, amelyet az ESME az MC-nek küldött submit_sm műveletben az üzenet elküldésekor állított be. Ez beállítható nem kézbesítés és csak kézbesítés esetén is, ami olyan helyzetekhez vezethet, amikor a visszaigazolás nem kerül visszaküldésre. A kézbesítési visszaigazolások deliver_sm és data_sm műveletekben kerülnek visszaküldésre.

A következő mezők relevánsak a deliver_sm és data_sm műveletekben, amikor kézbesítési visszaigazolások továbbítására használják őket.

• forrás cím (azaz source_addr_ton, source_addr_npi, source_addr) - A forráscím az eredeti rövid üzenet célcíméből lesz véve, amely a kézbesítési visszaigazolást generálta. A visszaigazolás úgy tűnik, mintha az eredeti regisztrált üzenet címzettjétől származna.
• cél cím (azaz dest_addr_ton, dest_addr_npi, destination_addr) - A célcím az eredeti rövid üzenet forráscíméből lesz véve, amely a kézbesítési visszaigazolást generálta. A visszaigazolás az eredetileg a regisztrált üzenetet küldő SME-hez címzett.
• esm_class - Az esm_class 2. bitje 1-re van állítva, jelezve, hogy az üzenet egy MC kézbesítési visszaigazolás. Ha az 5. bit is be van állítva, akkor az üzenet egy közbenső értesítés.
• message_state TLV - Az eredeti üzenet végső állapotát jelzi. Lásd alább a Üzenet állapotok részt.
• network_error_code TLV - Lásd alább a Hibakódok részt.
• receipted_message_id TLV - Az üzenet azonosító, amelyet az ESME-nek az MC küldött a submit_sm_resp PDU-ban.

MC kézbesítési visszaigazolás

Ez az üzenettípus egy MC kézbesítési visszaigazolás szállítására szolgál. Az MC, amikor észleli egy regisztrált üzenet végső állapotát, általában létrehoz egy új visszaigazoló üzenetet, amely az első üzenet küldőjéhez címzett. Az MC kézbesítési visszaigazolás ezután egy deliver_sm vagy data_sm műveletben kerül továbbításra az ESME-nek.

Közbenső értesítés

A közbenső értesítés egy speciális üzenetforma, amelyet az MC küldhet egy ESME-nek egy mobilhoz küldött üzenet kézbesítése során. Ez egy közbenső állapotot jelent az üzenet kézbesítési kísérletéről.

Jellemzően az üzenet újrapróbálkozási élettartama során történt kézbesítési kísérletek eredményeit jelenti az MC-n belül. Ez használható az üzenet célhoz történő kézbesítésének különféle okainak nyomon követésére és a feliratkozó elérhetőségének profilozására.

A közbenső értesítés funkcionalitásának támogatása az MC implementációjától és az MC szolgáltatótól függ, és túlmutat ennek a specifikációnak a keretein.

Nyugta a short_message mezőben

Számos 3.4-es verzió előtti API és a 3.3-as verziót támogató Üzenetközpont valószínűleg rendelkezik olyan eszközzel, amely a nyugtázási információkat a short_message mezőben továbbítja. Ez vonatkozik az MC kézbesítési nyugtákra és a köztes értesítésekre is. Ennek az információformátumnak a részletei az SMS átjárótól és az SMSC platformtól függenek, és túllépnek a specifikáció keretein. Az alábbiakban az általánosan alkalmazott módszer látható:

id:123A456B sub:1 dlvrd:1 submit date:1702281424 done date:1702281424 stat:DELIVRD err:0 text:

A mezők a következők szerint vannak meghatározva:

Mező	Méret (oktett)	Leírás
id	Változó	Az SMSC által az eredeti beküldéskor hozzárendelt üzenetazonosító.
sub	3	Az eredetileg beküldött rövid üzenetek száma. Az érték vezető nullákkal lehet feltöltve.
dlvrd	3	A kézbesített rövid üzenetek száma. Az érték vezető nullákkal lehet feltöltve.
submit date	10	A rövid üzenet beküldésének időpontja és dátuma. Egy lecserélt üzenet esetén ez az a dátum, amikor az eredeti üzenet le lett cserélve. A formátum a következő: YYMMDDhhmm, ahol: YY az év utolsó két számjegye (00-99) MM = hónap (01-12) DD nap (01-31) hh óra (00-23) mm perc (00-59)
done date	10	Az az időpont és dátum, amikor a rövid üzenet elérte végső állapotát. A formátum ugyanaz, mint a submit date esetében.
stat	7	Az üzenet végső állapota. Lásd az Üzenetállapotok részt lent. Az állapotszöveg rövidítve is lehet.
err	3	Hálózati vagy SMSC hibakód az üzenethez. Lásd a Hibakódok részt lent.
text	20	Nem használt mező, az eredmény üres lesz.

Ozeki SMPP fejlesztések

Mivel nagyon sok SMPP kapcsolatot valósítottunk meg, a következő problémákat találtuk különböző implementációkban:

1. megfigyelés:

A kézbesítési jelentésben szereplő ID mező értéke (amit mi Ozekiben Submit Reference-nek hívunk) gyakran eltér az SMS szolgáltatótól kapott azonosítótól. A leggyakoribb eltérés az, hogy az eredeti azonosítót szabványos egész számként kapjuk vissza, míg a kézbesítési jelentésben szereplő azonosítót hexadecimális számként. Ez fordítva is előfordulhat. A jó hír az, hogy ebben a helyzetben, ha visszaalakítjuk a két szám megegyezik, így a kézbesítési jelentések párosíthatók. Az Ozeki SMS implementációk különféle ellenőrzéseket végeznek, és képesek kezelni a leírt helyzetet.

2. megfigyelés:

A dátummezők értékei gyakran nem szabványos formátumban érkeznek. Az Ozeki jelenleg a következő minták alapján értelmezi a dátummezőket. A szoftver konfigurációs űrlapján egyéni dátummező mintát is megadhat.

• "yyMMddHHmm",
• "yyMMddHHmmss",
• "dd-MMM-yyHH:mm",
• "dd-MMM-yyHH:mm:ss",
• "dd-MMM-yy HH:mm",
• "dd-MMM-yy HH:mm:ss",
• "yyyyMMddHHmmss",
• "yyyyMMddHHmm",
• egyéni

Üzenet állapotok

Az alábbi lista a rövid üzenetek megengedett állapotait tartalmazza. Az MC az üzenetállapot értékét visszaadja az ESME-nek a query_sm_resp, query_broadcast_sm_resp vagy deliver_sm kézbesítési visszaigazoló PDU részeként.

A köztes állapotok olyan állapotok, amelyek változhatnak. A végleges állapotok olyan állapotok, amelyek az üzenet életciklusának végét jelentik.

Például egy újraküldés alatt álló üzenet ENROUTE állapotot adhat vissza. Később ez az üzenet vagy lejár, vagy kézbesítésre kerül. Az állapot ezután EXPIRED vagy DELIVERED állapotba kerül. Így az ENROUTE állapotban lévő üzenet köztes állapotúnak tekinthető.

A DELIVERED vagy EXPIRED állapotban lévő üzenet nem kerülhet más állapotba. Ezek az állapotok tehát végleges állapotok.

Üzenet állapota	Érték	Típus
SCHEDULED	0	Köztes
Az üzenet ütemezve van. A kézbesítés még nem kezdődött el. Egy ütemezett kézbesítési idővel beküldött üzenet lekérdezésekor ez az állapot jelenhet meg. Ez az érték az SMPP v5.0 verzióban került bevezetésre. Az SMPP v3.3 és SMPP v3.4 korábbi verzióit támogató MC-k valószínűleg ENROUTE állapotot adnak vissza ütemezett üzenetek esetén.
ENROUTE vagy EN_ROUTE	1	Köztes
Az üzenet úton van. Ez egy általános állapot, amely azt írja le, hogy az üzenet aktív az MC-n belül. Az üzenet lehet újraküldés alatt, vagy továbbítva lett egy mobil hálózatba a mobil eszközre történő kézbesítés céljából.
DELIVERED	2	Végleges
Az üzenet kézbesítésre került a címzetthez. Az üzenet megérkezett a címzetthez. További kézbesítési kísérletek nem történnek.
EXPIRED	3	Végleges
Az üzenet érvényességi ideje lejárt. Az üzenet nem került kézbesítésre az érvényességi időn és/vagy az újraküldési időn belül. További kézbesítési kísérletek nem történnek.
DELETED	4	Végleges
Az üzenet törölve lett. Az üzenet törölve vagy visszavonva lett az MC-ből. További kézbesítési kísérletek nem történnek.
UNDELIVERABLE	5	Végleges
Az üzenet nem kézbesíthető. Az üzenet kézbesítési hibába ütközött és véglegesen nem kézbesíthetőnek minősül. További kézbesítési kísérletek nem történnek. Bizonyos hálózati vagy MC belső hibák az üzenet végleges kézbesítésének elmaradásához vezetnek. Ilyen hibák például az ismeretlen előfizető vagy olyan hálózati hiba, amely azt jelzi, hogy a cél mobil eszköz nem kaphat SMS szolgáltatást vagy nem támogatja az SMS-t.

SMPP kézbesítési visszaigazolási hibakódok

A kézbesítési visszaigazolásokban visszaadott hibakódok az üzenet kézbesítése során felmerülő hibás helyzetek jelzésére szolgálnak. A hibakódok SMS átjáró és SMSC platform specifikusak. Az alábbiakban azonban egy gyakran alkalmazott megközelítés látható:

Kód	Jelentés
1	Az MT szám ismeretlen az MT hálózat HLR-jában
2	Az MT szám ismeretlen az MT hálózat HLR-jában
5	Az MT szám ismeretlen az MT hálózat MSC-jében
9	Az MT szám illegális előfizetőként van nyilvántartva az MT hálózat MSC-jében
11	Az MT HLR "Teleszolgáltatás nincs kiépítve" hibát küld vissza az SRI-re válaszként
12	Az MT készülék illegális eszközként van nyilvántartva az MSC-n.
13	Az ügyfél tiltva van az MT HLR szerint az SMS fogadásától
15	Az MT ügyfél olyan CUG tagja, amely nem kaphat SMS-t
21	Az SMS nem támogatott az MT hálózatban.
22	Az SMS nem támogatott az MT MSC-ben
31	Az MT készülék foglalt. A jelző vezérlő csatorna használatban van. 
	(Valószínűleg éppen egy másik SMS-t fogad)
32	GPRS – Mint fent
34	Rendszerhiba az MT hálózatban.
35	Hiányzó adat az MT HLR vagy MSC rendszerében
36	Váratlan adatérték érkezett az FSM vagy SRI válaszként
40	Az MT készülék memóriakapacitása meghaladva
41	Az MT készülék protokollhiba
42	Az MT készülék nem képes SMS fogadására
43	A "0" típusú rövid üzenet nem támogatott az MT készüléken.
44	Az MT hálózat nem tudja lecserélni az SMS-t az MT ügyfél készülékén
45	Meghatározatlan protokollhiba az MT készüléken
46	Az üzenet osztály nem támogatott az MT készüléken
47	Meghatározatlan DCS (adatkódolási séma) hiba az MT készüléken
48	Az átviteli réteg PDU nem támogatott az MT készüléken
49	Az MT készülék SIM kártyája megtelt
50	Az MT készülék SIM kártyája nem képes az üzenet tárolására
51	Hiba az MT készüléken
52	Az MT készülék memóriakapacitása meghaladva
53	Az SIM alkalmazás eszközkészlet foglalt az MS készüléken
54	SIM adatletöltési hiba az MT ügyfél készülékén
55	Meghatározatlan MS készülék hiba
60	Hiányzó előfizető. Az ok ismeretlen
61	Hiányzó előfizető, mert a telefon ki van kapcsolva
62	Hiányzó előfizető, mert a telefon kívül van a lefedettségi területen/lemerült az akkumulátor
63	Hiányzó előfizető roaming korlátozás/korlátozott terület miatt
64	Hiányzó előfizető, mert törölve lett az HLR-ból
65	Hiányzó előfizető, mert törölve lett a VLR-ből (24+ órája ki van kapcsolva)
66	Hiányzó előfizető (GPRS) nem érhető el az SGSN által történő hívásra
67	Hiányzó előfizető, mert GPRS leválasztva
68	Hiányzó előfizető, mert törölve lett az HLR-ból (GPRS)
69	Hiányzó előfizető, mert GPRS MS törölve lett a VLR-ből
70	Hiányzó előfizető, mert ismeretlen előfizető az MSC-n, ahová az FSM el lett küldve.
71	Hiányzó előfizető, mert ismeretlen előfizető az SGSN-n

Hogyan teszteljük az SMPP kézbesítési jelentéseket

Létrehozhat egy SMPP szimulátor konfigurációt, az SMS kézbesítési jelentések tesztelésére. A szimulátorban a tesztelő kapcsolat visszaadhat sikeres és sikertelen kézbesítési jelentéseket. Ezt fogja tenni, ha beállítja a "Kézbesítési jelentés kérése" opciót az "Advanced" lapon az SMPP Tesztelő kapcsolat konfigurációs űrlapján. Ha ez az opció engedélyezve van, egy kézbesítési jelentés kerül visszaküldésre minden beküldött SMS-hez egy véletlenszerű későbbi időpontban, véletlenszerűen sikeres vagy sikertelen kézbesítési állapottal.

GYIK

Mi az a kézbesítési jelentés?

Az SMS-üzenet küldésekor kulcsfontosságú annak megerősítése, hogy az megérkezett-e a címzett telefonjára. Az SMS kétlépcsős megerősítési rendszert használ ennek biztosítására.

Amikor elküldi üzenetét a mobilhálózat Rövid Üzenet Szolgáltatási Központjába (SMSC), egy "üzenet beküldési jelentést" kap. Ez a jelentés azt jelzi, hogy az SMSC elfogadta az üzenetét továbbításra. Tartalmaz egy egyedi azonosítót is, amelyet gyakran "üzenet-referenciának" vagy "callback ID-nek" neveznek, és lehetővé teszi az üzenet nyomon követését az SMSC rendszerében.

Az elfogadás után az üzenet az SMSC-ben tárolódik, amíg a kézbesítés lehetségessé nem válik. Ez késleltethető, ha a címzett telefonja ki van kapcsolva, akár napokig is eltarthat. Amint a címzett telefonja elérhetővé válik, az üzenet kézbesítésre kerül. A sikeres kézbesítés után egy "kézbesítési jelentést" küldenek vissza a feladónak, külön SMS-üzenetként.

Ez a megerősítő SMS tartalmazza:

• A címzett telefonszámát: Ellenőrzi, hogy a szándékolt címzett kapta-e meg az üzenetet.
• Az üzenet-referenciát (callback ID): Megegyezik az eredeti beküldési jelentésből származó azonosítóval, egyértelmű kapcsolatot teremtve a két lépés között.
• A kézbesítés időbélyegét: Megadja a pontos időt, amikor az üzenet elérte a címzett telefonját.

Fontos megjegyezni, hogy a "kézbesítési jelentés" általában erre a megerősítő SMS-re utal, amelyet a feladó kap. Nem minden mobilhálózat kínál kézbesítési jelentéseket, és egyeseknél a felhasználónak kell aktiválnia ezt a szolgáltatást.

Beállíthatom, hogy mennyi ideig tárolják az üzenetet az SMSC-ben?

Bár az SMS-üzenetküldés kényelmes módja a kommunikációnak, fontos, hogy az üzenet időben megérkezzen a címzetthez. Itt jön képbe az "érvényességi időszak" fogalma.

Az érvényességi időszak az az időkeret, ameddig egy SMS-üzenet tárolódik a Rövid Üzenet Szolgáltatási Központban (SMSC), ha a címzett telefonja nem elérhető. Ha az üzenet ezen időszak lejárta után sem kerül kézbesítésre, automatikusan törlődik az SMSC-ből, megelőzve a késleltetett kézbesítést.

Az érvényességi időszak használatának előnyei:

• Időérzékeny üzenetek: Képzelje el, hogy egy időérzékeny eseményről, például egy élő TV-műsorról küld szöveget. A megfelelő érvényességi időszak beállításával biztosítható, hogy az üzenet ne kerüljön kézbesítésre az esemény lezárulta után, ami értelmetlenné tenné azt.
• Hálózati hatékonyság: Az érvényességi időszak megakadályozza a szükségtelen kézbesítési kísérleteket elérhetetlen telefonokra, ezzel optimalizálva a hálózati erőforrásokat.

Bár egyes mobilhálózatok lehetőséget kínálnak az érvényességi időszak közvetlen beállítására a kimenő üzenetekhez, az alapértelmezett beállítás gyakran a hálózat maximuma (általában egy hét). Ez az érték módosítható a telefon beépített menüopcióin keresztül.

Fontos megjegyezni, hogy nem minden mobilhálózat kínál felhasználó által konfigurálható érvényességi időszakot, és egyeseknél a felhasználónak kell aktiválnia a kézbesítési jelentéseket (megerősítés, hogy az üzenet elérte a címzettet).

More information

• SMPP specification
• SMPP protocol version comparison
• SMPP PDU logging
• How to use SMPP API with programming languages
• Secure SMPP connection over SSL TLS
• SMPP delivery report format
• What is an SMPP simulator
• SMPP error codes
• How to send a test SMPP SMS message
• SMPP PDU decode
• SMPP Character encoding
• SMPP wireshark