Ahoj! I když messengery a sociální sítě každý den vytlačují tradiční způsoby komunikace, popularita SMS tím není nijak snížena. Ověření na populární webové stránce nebo oznámení o transakci se nijak neliší a budou žít dál. Přemýšleli jste někdy, jak to všechno funguje? Velmi často se pro hromadné odesílání zpráv používá protokol SMPP, o kterém pojednává tento článek.
Na Habr už byly články o smpp, ,, ale jejich cílem nebylo popisovat samotný protokol. Samozřejmě můžete začít přímo od zdroje — , ale myslím, že by nebylo špatné mít také jeho stručný přehled. Budu vysvětlovat na příkladu v3.4. Těším se na vaši objektivní kritiku.
Protokol SMPP je protokol pro peer-to-peer zprávy. To znamená, že každý uzel/hub server je rovnocenný. V nejjednodušším případě vypadá schéma výměny SMS zpráv následovně:

Pokud však národní operátor nemá trasu do nějakého vzdáleného regionu, žádá o to zprostředkovatele — SMS hub. Někdy, aby se odeslala jedna SMS, je třeba vytvořit řetězec mezi několika zeměmi nebo dokonce kontinenty.
O protokolu
SMPP je aplikační protokol, který je založen na výměně PDU a je přenášen přes TCP/IP nebo X25 sezení pro přenos SMS a USSD zpráv. Obvykle se SMPP používá v režimu trvalého připojení, což pomáhá šetřit čas. SMPP využívá model komunikace klient — server.
Režim komunikace

Výměna zpráv mezi odesílatelem a SMS centrem prostřednictvím SMPP může probíhat v následujících režimech:
Transmitter (přijímač) — jednosměrný přenos zprávy, sekvenčně
Receiver (přijímač) — pouze příjem zprávy od SMS centra.
Transreceiver (přijímač a odesílatel) — výměna zpráv mezi SMS centrem a uživatelem
Struktura

Délka zprávy
Jedna SMS zpráva může obsahovat 70 znaků při zadání cyrilicí a maximálně 157 latinských znaků + 3 UDH. Pokud odešlete SMS s velkým počtem znaků, bude rozdělena na několik segmentů a na přijímajícím zařízení opět spojena. V případě segmentace se počet znaků snižuje v důsledku hlaviček zprávy, které uvádějí část zprávy. Proto při odesílání velké SMS zprávy obsahuje maximálně 153 latinských znaků nebo 67 atypických znaků.
Data Coding Scheme
Avšak na prenos správy si znaky vyžadujú kódovanie. V protokole SMPP je za kódovanie zodpovedné špeciálne pole — Data Coding Scheme, alebo DCS. Toto pole určuje, ako je potrebné správy rozpoznávať. Okrem toho pole DCS obsahuje:
- sadu znakov, ktorá určuje kódovanie;
- klasifikáciu správy;
- žiadosť o automatické odstránenie po prečítaní;
- pokyn na kompresiu správy;
- jazyk hromadnej správy;
Štandardný 7-bitový abecedný znak (GSM 03.38). Bol vyvinutý pre systém správ v GSM. Takéto kódovanie je vhodné pre angličtinu a niekoľko latinských jazykov. Každý znak sa skladá zo 7 bitov a kóduje sa do oktetu.
UTF-16 (v GSM UCS2) Na zahrnutie chýbajúcich znakov v 7-bitovej abecede bola vyvinutá kódovanie UTF-16, ktoré pridáva ďalšie znaky (vrátane cyrilských) zmenšením veľkosti správy z 160 na 70, tento typ kódovania takmer úplne reprodukuje Unicode.
8-bitové dáta definované používateľom. Tieto zahŕňajú KOI8-R a Windows-1251. Hoci sa táto možnosť zdá byť ekonomickejšia oproti UTF-16, vzniká opodstatnená otázka kompatibility na rôznych zariadeniach. Pretože v takom prípade musia byť obe zariadenia vopred nastavené.
Klasifikácia správy
- Class0, alebo flash, správa, uložená v pamäti telefónu na želanie používateľa;
- Class1, alebo tie, ktoré sú uložené v pamäti telefónu;
- Class1, alebo tie, ktoré sú uložené v pamäti telefónu;
- Class2, musí zaručiť, že správa zostane uložená v pamäti mobilného terminálu, inak by mala poskytnúť upozornenia sms centra o nemožnosti uchovania;
- Class3 — v tomto prípade musí telefón poslať oznámenie, že správa môže byť uložená, bez ohľadu na množstvo pamäte v zariadení. Tento typ správy predpokladá, že správa dosiahla adresáta;
Typ správy
Tichá správa (SMS0) Typ sms správy bez obsahu. Taká sms prichádza bez upozornenia a nezobrazuje sa na obrazovke zariadenia.
PDU
Každá operácia pdu je párová a pozostáva z požiadavky a odpovede. Napríklad: príkaz, ktorý hovorí o nadviazaní spojenia (bind_transmitter / bind_transmitter_resp), alebo o tom, že správa bola odoslaná (deliver_sm / deliver_sm_resp)

Každý PDU paket pozostáva z dvoch častí — hlavička (header) a telo (body). Štruktúra hlavičky je rovnaká pre akýkoľvek PDU paket: command length je dĺžka paketu, id je názov paketu, a príkaz status ukazuje, či bola správa úspešne odoslaná, alebo sa vyskytla chyba.
Dodatočné parametre TLV
TLV (Tag Length Value), alebo dodatočné polia. Tieto parametre sa používajú na rozšírenie funkcií protokolu a nie sú povinné. Toto pole sa uvádza na konci poľa PDU. Ako príklad s použitím TLV dest_addr_np_information môžeme usporiadať prenos informácií o portabilite čísla.
Ton a Npi
TON (Type of Number) parameter informuje SMSC o formáte adresovania a type siete.
NPI (Numbering Plan Identification) parameter, ktorý označuje plán číslovania.

Adresa zdroja správy alebo alfa meno
Správy odosielané na telefón môžu byť dvoch druhov: digitálne a písmenové. Digitálne môžu byť dlhé (podobné telefónnemu číslu) a krátke. Niekedy majú operátori obmedzenia na odosielanie z neutrálnych mien, napríklad Infosms, Alert atď. Niekedy operátori neprechádzajú traffic, ak meno nie je registrované v ich sieti. To sú však skôr špecifiká operátora.
Fázy odosielania
![]()
SMS-SUBMIT — to je odosielanie správy MO FSM (krátka správa z mobilného terminálu)
SMS-SUBMIT REPORT — potvrdenie, že správa bola odoslaná SMSC
SRI SM (SendRoutingInfo) — SMSC získava informácie od HLR ohľadom MSC / VLR miesta pobytu účastníka
SRI SM RESP — odpoveď od HLR ohľadom miesta pobytu účastníka
MT-FSM — po získaní polohy sa správa odosiela pomocou operácie „Forward Short Message“
MT-FSM ACK — odpoveď od SMSC o tom, že správa bola odoslaná
SMS-STATUS REPORT — SMSC odosiela stav o doručení správy.
Stav doručenia správy
SMS-STATUS REPORT môže mať niekoľko hodnôt:
DELIVRD správa bola úspešne doručená
REJECTD — správa bola odmietnutá SMS centrom
EXPIRED — správa bola odstránená z odosielacej fronty po uplynutí TTL (čas života správy)
UNDELIV — iné prípady nedoručenia
UNKNOWN-nebol prijatý odpoveď o odoslaní.
Chyby prenosu
Niekedy sú dôvody, prečo SMS správy nie sú doručené účastníkovi. Dôsledkom týchto dôvodov sú chyby. Chyby sa vracajú v PDUs_sms_resp. Všetky chyby môžeme rozdeliť na dočasné (Temporary) a trvalé (Permanent).
Ako príklad môžeme uviesť, že k dočasným patrí absent_subscriber, keď je účastník nedostupný alebo nie je online, a k trvalým patrí, ak účastník neexistuje. Na základe chýb, ktoré sa vyskytujú, sa formuluje politika opätovného odosielania týchto správ.
Napríklad, ak bol účastník zaneprázdnený hovorom a dostal chybu MT handset is busy, správu je možné odoslať znova po niekoľkých minútach, avšak ak má účastník zablokovanú službu prijímania správ, opätovné odoslanie nebude mať zmysel. Zoznam chýb nájdete na stránkach SMSC, napríklad, ako .
Zdroj: habr.com
