Szia! Bár a messenger alkalmazások és közösségi média napról napra kiszorítják a hagyományos kommunikációs módszereket, ez nem csökkenti az SMS népszerűségét. Az ellenőrzés egy népszerű weboldalon, vagy egy tranzakció értesítése, ezek élnek és fognak élni. Elgondolkodtál már azon, hogyan működik mindez? Nagyon gyakran tömeges üzenetek küldésére az SMPP protokollt használják, amelyről szó lesz a cikkben.
A Habr-on már voltak cikkek az SMPP-ről, ,, de ezek célja nem volt a protokoll leírása. Természetesen azonnal kezdheted az eredeti forrással — , de úgy gondolom, hogy nem ártana, ha lenne egy rövid összefoglaló is. Példán keresztül fogom magyarázni a v3.4-en. Örülök az objektív kritikádnak.
Az SMPP protokoll egy párhuzamos üzenetküldési protokoll. Ez azt jelenti, hogy minden egyes peer/hub szerver egyenrangú. A legegyszerűbb esetben az SMS üzenetek cseréjének sémája így néz ki:
Azonban, ha a nemzeti szolgáltatónak nincs útja egy távoli régióba, akkor kér egy közvetítőt — SMS hubot. Néha, hogy egy SMS-t küldjünk, több országon keresztül kell láncot építeni, akár kontinenst is átívelve.
A protokollról
Az SMPP egy alkalmazási szintű protokoll, amely PDU-k cseréjén alapul, és TCP/IP-n, vagy X25 üléseken keresztül küld SMS és USSD üzeneteket. Az SMPP-t általában állandó kapcsolódási módban használják, ami időt takarít meg. Az SMPP az ügyfél — szerver kommunikációs modellt használ.
Kapcsolati mód
Az üzenetek cseréje az SMS központ és a küldő között SMPP-n keresztül az alábbi módokban történhet:
Transmitter (kibocsátó) — az üzenet egyirányú átvitele, sorban
Receiver (fogadó) — csak az üzenetek fogadása az SMS központtól.
Transreceiver (átvitel) — üzenetek cseréje az SMS központ és a felhasználó között
Struktúra
Üzenet hossza
Egy SMS üzenet 70 karaktert tartalmazhat cirill írással, és legfeljebb 157 latin karaktert + 3 UDH. Ha több karaktert küldesz SMS-ben, az több szegmensre oszlik, és a fogadó eszköz egyesíti őket. A szegmentálás esetén a karakterek száma csökken a szegmensekhez szükséges üzenetfejlécek miatt. Ezért, ha nagy SMS-t küldesz, az maximálisan 153 latin karakter vagy 67 nem tipikus karaktert tartalmaz.
Adatok kódolási séma
Az üzenet átviteléhez a karakterek kódolása szükséges. Az SMPP protokollban a kódolásért egy speciális mező, a Data Coding Scheme (DCS) felel. Ez a mező határozza meg, hogy hogyan kell felismerni az üzeneteket. Ezen kívül a DCS mező tartalmazza:
- a karakterkészletet, amely meghatározza a kódolást;
- az üzenet osztályát;
- az automatikus törlés igényét olvasás után;
- az üzenet tömörítésére vonatkozó utasítást;
- a széleskörű hirdetési üzenet nyelvét;
A standard 7 bites ábécé (GSM 03.38). Ezt a GSM üzenetrendszerhez fejlesztették ki. Ez a kódolás megfelelő az angol és számos latin nyelv számára. Minden egyes karakter 7 bitből áll és oktettbe van kódolva.
UTF-16 (GSM UCS2) Az eltérő karakterek 7 bites ábécéből való bevonására hozták létre az UTF-16 kódolást, amely további karaktereket (például cirill betűket) ad hozzá, csökkentve az üzenet méretét 160-ról 70-re, ez a kódolási típus szinte teljes mértékben megfelel a Unicode-nak.
Felhasználó által definiált 8-bites adatok. Ide tartozik a KOI8-R és a Windows-1251. Bár ez a megoldás költséghatékonyabbnak tűnik az UTF-16-hoz képest, felmerül a kompatibilitás kérdése különböző eszközökön. Mivel ebben az esetben mindkét eszköznek előre be kell állítva lennie.
Üzenet osztálya
- Class0, vagy flash üzenet, amelyet a felhasználó kívánságára a telefon memóriájában tárolnak;
- Class1, vagy azok, amelyek a telefon memóriájában tárolódnak;
- Class1, vagy azok, amelyek a telefon memóriájában tárolódnak;
- Class2, amely garantálja, hogy az üzenet megmarad a mobilterminál memóriájában, ellenkező esetben értesítést kell küldenie az SMS központnak az elmentés lehetetlenségéről;
- Class3 – ebben az esetben a telefon értesítést kell küldjön arról, hogy az üzenet menthető, függetlenül az eszköz memóriájának mennyiségétől. Ez a típusú üzenet azt feltételezi, hogy az üzenet elérte a címzettet;
Üzenettípus
Csendes üzenet (SMS0) Olyan SMS üzenettípus, amely nem tartalmaz tartalmat. Ez az SMS értesítés nélkül érkezik, és nem jelenik meg az eszköz kijelzőjén.
PDU
Minden PDU művelet párba állított és egy kérésből és válaszból áll. Például: a parancs, amely a kapcsolat létrehozását jelzi (bind_transmitter / bind_transmitter_resp), vagy hogy az üzenet át lett adva (deliver_sm / deliver_sm_resp)
Minden PDU csomag két részből áll — fejléc (header) és törzs (body). A fejléc szerkezete bármilyen PDU csomag esetén azonos: a parancs hossza (command length) a csomag hossza, az ID a csomag neve, míg a status parancs azt jelzi, hogy az üzenetet sikeresen továbbították, vagy hiba történt.
További TLV paraméterek
A TLV (Tag Length Value), vagyis a további mezők. Ezek a paraméterek a protokoll funkcióinak kiterjesztésére szolgálnak, és nem kötelezőek. Ez a mező a PDU mező végén található. Például a TLV dest_addr_np_information segítségével lehetőség van a szám hordozhatóságával kapcsolatos információk továbbítására.
Ton és Npi
A TON (Type of Number) paraméter tájékoztatja az SMSC-t a címzési formátumról és a hálózat típusáról.
Az NPI (Numbering Plan Identification) paraméter a számításhoz használt számtervet jelzi.
Az üzenet forráscíme, vagy alfa név
Az okostelefonokra küldött üzenetek kétféle lehet: digitális és betűs. A digitális üzenetek lehetnek hosszúak (hasonlítanak a telefonszámokra) és rövidek. Néha a szolgáltatóknak lehetnek korlátozásaik a semleges nevek, például Infosms, Alert stb. küldésére. Néha a szolgáltatók nem engedélyezik a forgalmat, ha a név nincs regisztrálva a hálózatukban. Ez azonban inkább a szolgáltató sajátossága.
Az üzenetküldés szakaszai
SMS-SUBMIT — az MO FSM üzenet (rövid üzenet a mobilterminálból) elküldése
SMS-SUBMIT REPORT — megerősítés arról, hogy az üzenetet elküldték az SMSC-nek
SRI SM (SendRoutingInfo) — az SMSC információt kap a HLR-től az MSC/VLR helyéről, ahol a felhasználó tartózkodik
SRI SM RESP — válasz a HLR-től a felhasználó pozíciójának helyéről
MT-FSM — a helymeghatározás után üzenetet küldenek az 'Forward Short Message' művelet segítségével
MT-FSM ACK — az SMSC válasza arról, hogy az üzenet elküldésre került
SMS-STATUS REPORT — az SMSC az üzenet kézbesítési állapotáról tájékoztat.
Az üzenet kézbesítési állapota
SMS-STATUS REPORT több értéket vehet fel:
DELIVRD az üzenet sikeresen kézbesítve
REJECTD — az üzenetet elutasította az SMS központ
EXPIRED — az üzenet törlésre került a küldési sorból a TTL (időtartam) lejárta után
UNDELIV — egyéb kézbesítési esetek
UNKNOWN- nem érkezett válasz a küldésről.
Átvitel hibái
Néha vannak okok, amelyek miatt az SMS üzenetek nem jutnak el a címzetthez. Ezeknek az okoknak a következményei hibák keletkezése. A hibák az PDUs_sms_resp -ben térnek vissza. Minden hiba két csoportba osztható: átmeneti (Temporary) és állandó (Permanent).
Például a dobozok esetében az absent_subscriber a nem elérhető vagy nem online előfizető, míg a tartós hibák közé tartozik az előfizető nem létezik. A hibák függvényében alakul ki az üzenetek visszaküldésének politikája.
Például, ha az előfizető egy beszélgetés közepén volt, és kapott egy MT handset is busy hibát, az üzenetet néhány perc múlva újra lehet küldeni, viszont ha az előfizetőnél le van tiltva az üzenetfogadás, akkor a további küldésnek nincs értelme. A hibák listáját megtalálhatja az SMS központ oldalain, például itt: .
Forrás: habr.com
