Ahoj! Hoci instant messenger a sociálne siete každý deň nahrádzajú tradičné spôsoby komunikácie, na popularite SMS to neuberá. Overenie na obľúbenom webe alebo oznámenie o transakcii sa zopakujú a budú fungovať. Zamysleli ste sa nad tým, ako to celé funguje? Veľmi často sa protokol SMPP používa na odosielanie hromadných správ, o ktorých bude reč pod rezom.
Habré už mal články o smpp, ,, ale ich účelom nebolo popísať samotný protokol. Samozrejme, môžete okamžite začať od zdroja - , ale myslím, že by bolo fajn, keby tam bolo aj krátke zhrnutie. Vysvetlím na príklade v3.4, budem rád za vašu objektívnu kritiku.
Protokol SMPP je protokol zasielania správ typu peer-to-peer. To znamená, že každý peer/hub server je rovnaký. V najjednoduchšom prípade vyzerá schéma SMS správ takto:
Ak však národný operátor trasu nemá, požiada o to sprostredkovateľa do nejakého vzdialeného regiónu - SMS hub. Niekedy na odoslanie jednej SMS potrebujete vybudovať reťazec medzi niekoľkými krajinami alebo dokonca kontinentmi.
O protokole
SMPP je protokol aplikačnej vrstvy, ktorý je založený na výmene PDU a prenáša sa cez TCP/IP alebo X25 relácie na odosielanie sms a ussd správ. Zvyčajne sa SMPP používa v režime trvalého pripojenia, čo šetrí čas. SMPP používa komunikačný model klient-server.
Komunikačný režim
Výmena správ medzi odosielateľom a SMS centrom cez SMPP môže prebiehať v nasledujúcich režimoch:
Vysielač (vysielač) - vysielanie správy v jednom smere, po jednom
Receiver (receiver) - iba príjem správy z SMS centra.
Transreceiver (transceiver) - Výmena správ medzi SMS centrom a používateľom
Štruktúra
Dĺžka správy
Jedna SMS správa môže obsahovať 70 znakov pri písaní v azbuke a nie viac ako 157 znakov latinky + 3 UDH Ak posielate SMS s veľkým počtom znakov, bude rozdelená na niekoľko segmentov a v prijímacom zariadení spojená. V prípade segmentácie sa počet znakov znižuje o hlavičky správ, ktoré označujú časť správy. Pri odosielaní veľkej SMS správy teda obsahuje maximálne 153 latinských znakov alebo 67 netypických znakov.
Schéma kódovania údajov
Symboly však vyžadujú kódovanie na prenos správy. V protokole SMPP je za kódovanie zodpovedné špeciálne pole - Data Coding Scheme alebo DCS. Toto je pole, ktoré určuje, ako sa majú správy rozpoznávať. Okrem toho pole DCS obsahuje:
- znakovú sadu, ktorá definuje kódovanie;
- trieda správ;
- žiadosť o automatické vymazanie po prečítaní;
- indikácia kompresie správy;
- jazyk vysielaných správ;
Štandardná 7-bitová abeceda (GSM 03.38). Bol vyvinutý pre systém zasielania správ v GSM. Toto kódovanie je vhodné pre angličtinu a množstvo latinských jazykov. Každý znak pozostáva zo 7 bitov a je zakódovaný do oktetu.
UTF-16 (v GSM UCS2) Na zahrnutie chýbajúcich znakov v 7-bitovej abecede bolo vyvinuté kódovanie UTF-16, ktoré pridáva ďalšie znaky (vrátane cyrilických) zmenšením veľkosti správy zo 160 na 70, tento typ kódovania takmer úplne opakuje Unicode.
8-bitové užívateľom definované dáta. Patria sem KOI8-R a Windows-1251. Aj keď sa toto riešenie zdá ekonomickejšie v porovnaní s rovnakým UTF-16. Vzniká rozumná otázka kompatibility na rôznych zariadeniach. Pretože v tomto prípade musia byť obe zariadenia nakonfigurované vopred.
Trieda správ
- Class0 alebo flash, správa uložená v pamäti telefónu na žiadosť používateľa;
- Trieda 1 alebo tie, ktoré sú uložené v pamäti telefónu;
- Trieda 1 alebo tie, ktoré sú uložené v pamäti telefónu;
- Trieda 2, musí zabezpečiť uloženie správy v pamäti mobilného terminálu, inak musí SMS centrum upozorniť na nemožnosť uloženia;
- Trieda 3 – v tomto prípade by mal telefón odoslať upozornenie, že správu je možné uložiť, bez ohľadu na veľkosť pamäte v zariadení. Tento typ správy znamená, že správa dosiahla svoje miesto určenia;
Typ správy
Tichá správa (SMS0) Typ SMS správy bez obsahu. Takáto SMS prichádza bez upozornenia a nezobrazuje sa na obrazovke zariadenia.
PDU
Každá operácia pdu je spárovaná a pozostáva z požiadavky a odpovede. Napríklad: príkaz, ktorý hovorí, že spojenie bolo vytvorené (bind_transmitter / bind_transmitter_resp), alebo že bola odoslaná správa (deliver_sm / delivery_sm_resp)
Každé balenie pdu sa skladá z dvoch častí - hlavičky (header) a tela (body). Štruktúra hlavičky je rovnaká pre akýkoľvek paket pdu: dĺžka príkazu je dĺžka paketu, id je názov paketu a príkaz status označuje, či bola správa odoslaná úspešne alebo neúspešne.
Ďalšie parametre TLV
TLV (Tag Length Value) alebo ďalšie polia. Takéto parametre sa používajú na rozšírenie funkčnosti protokolu a sú voliteľné. Toto pole je uvedené na konci poľa pdu. Napríklad pomocou dest_addr_np_information TLV môžete zorganizovať prenos informácií o prenose čísla.
Ton a Npi
Parameter TON (Type of Number) informuje SMSC o formáte adresovania a type siete.
Parameter NPI (Numbering Plan Identification) označujúci plán číslovania.
Adresa zdroja správy alebo alfa názov
Správy odoslané do telefónu prichádzajú v dvoch variantoch: číselné a abecedné. Čísla môžu byť dlhé (podobne ako telefónne číslo) alebo krátke. Niekedy majú operátori obmedzenia na odosielanie z neutrálnych mien, ako sú Infosms, Alert atď. Operátori niekedy nepovolia prenos, ak názov nie je zaregistrovaný v ich sieti. To je však skôr vlastnosť operátora.
Etapy podania
SMS-POSLAŤ - toto je odoslanie správy MO FSM (krátka správa z mobilného terminálu)
SMS - ODOSLAŤ HLÁSENIE — potvrdenie, že správa bola odoslaná prostredníctvom SMSC
SRI SM (SendRoutingInfo) - SMSC prijíma informácie z HLR týkajúce sa MSC/VLR polohy účastníka
SRI SM RESP — odpoveď od HLR týkajúca sa pozície predplatiteľa
MT-FSM - po prijatí polohy sa odošle správa pomocou operácie "Forward Short Message".
MT-FSM-ACK — odpoveď od SMSC, že správa bola odoslaná
SMS HLÁSENIE STAVU — SMSC odošle stav doručenia správy.
Stav doručenia správy
SMS HLÁSENIE STAVU môže nadobudnúť niekoľko hodnôt:
DELIVRD správa bola úspešne doručená
ZAMIETNUTÉ — správa odmietnutá centrom SMS
EXPIRED - správa je odstránená z frontu na odoslanie po skončení TTL (života správy)
UNDELIV - iné prípady nedoručenia
NEZNÁMY- Žiadna odpoveď.
Chyby prenosu
Niekedy dôvody, pre ktoré SMS správy nie sú doručené účastníkovi. Dôsledkom týchto dôvodov je výskyt chýb. Chyby sú vrátené v PDUs_sms_resp. Všetky chyby možno rozdeliť na dočasné (Temporary) a trvalé (Permanent).
Napríklad absent_subscriber je dočasný, účastník nie je dostupný alebo nie je online a trvalý - účastník neexistuje. V závislosti od chýb, ktoré sa vyskytnú, sa vytvorí politika opätovného odosielania týchto správ.
Napríklad, ak bol účastník zaneprázdnený hovorom a prijal MT slúchadlo je obsadené, správa sa môže znova odoslať po niekoľkých minútach, ak však účastník zablokoval službu prijímania správ, opätovné odoslanie nebude mať zmysel. Zoznam chýb nájdete na stránkach SMSC napr .
Zdroj: hab.com