Ahoj! I když messengerové aplikace a sociální sítě každý den vytlačují tradiční způsoby komunikace, nezmenšuje to popularitu SMS. Ověření na populárním webu nebo oznámení o transakci se opakují a budou žít dál. Už jste se zamysleli, jak to celé funguje? Velmi často se pro masovou distribuci zpráv používá protokol SMPP, o kterém bude řeč níže.
Na Habr již byly články o SMPP, ,, ale jejich cílem nebylo popsat samotný protokol. Bezpochyby můžete začít přímo ze zdroje — , ale myslím, že by bylo fajn mít také stručné shrnutí. Budu vysvětlovat na příkladu v3.4. Těším se na vaše objektivní kritiky.
Protokol SMPP je protokol pro vzájemnou komunikaci zpráv. To znamená, že každý uzel/hub server je rovnocenný. V nejjednodušším případě vypadá schéma výměny SMS zpráv takto:
Pokud však národní operátor nemá trasu do nějakého vzdáleného regionu, požádá o pomoc prostředníka — SMS hub. Někdy je třeba k odeslání jedné SMS vytvořit řetězec mezi několika zeměmi nebo dokonce kontinenty.
O protokolu
SMPP je aplikační protokol, který se založený na výměně PDU a přenáší se přes TCP/IP nebo X25 relace pro přenos SMS a USSD zpráv. Obvykle se SMPP používá v režimu trvalého připojení, což šetří č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 (vysílač) — jednosměrné odesílání zprávy, po jednom.
Receiver (příjímač) — pouze příjem zpráv od SMS centra.
Transreceiver (příjímač-vysílač) — 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 psaní cyrilicí a maximálně 157 latinských znaků + 3 UDH. Pokud se odešle SMS s větším počtem znaků, bude rozdělena na několik segmentů a znovu spojena na přijímajícím zařízení. V případě segmentace se počet znaků snižuje na úkor hlaviček zprávy, které uvádějí část zprávy. Proto při odesílání velkého SMS zprávy obsahuje maximálně 153 latinských znaků nebo 67 netypických znaků.
Data Coding Scheme
Pro přenos zprávy je třeba kódování znaků. V protokolu SMPP odpovídá za kódování speciální pole – Data Coding Scheme, nebo DCS. Toto pole uvádí, jak rozpoznávat zprávy. Kromě toho pole DCS zahrnuje:
- sadu znaků, která určuje kódování;
- typ zprávy;
- žádost o automatické odstranění po přečtení;
- příkaz ke kompresi zprávy;
- jazyk hromadné zprávy;
Standardní 7-bitový abeceda (GSM 03.38). Byla vyvinuta pro systém zpráv v GSM. Toto kódování je vhodné pro angličtinu a několik latinských jazyků. Každý znak se skládá ze 7 bitů a je kódován v oktetu.
UTF-16 (v GSM UCS2) Pro zahrnutí chybějících znaků v 7-bitové abecedě byla vyvinuta kódování UTF-16, která přidává další znaky (včetně cyrilice) na úkor zmenšení velikosti zprávy ze 160 na 70. Tento typ kódování téměř úplně napodobuje Unicode.
8-bitová data definovaná uživatelsky. Patří sem KOI8-R a Windows-1251. I když se toto řešení zdá být úspornější ve srovnání s UTF-16, vyvstává oprávněná otázka kompatibility na různých zařízeních. V takovém případě musí být obě zařízení předem nastavena.
Typ zprávy
- Class0, nebo flash, zpráva, která se ukládá do paměti telefonu na přání uživatele;
- Class1, nebo ty, které se ukládají do paměti telefonu;
- Class1, nebo ty, které se ukládají do paměti telefonu;
- Class2, musí zaručit, že zpráva bude uložena v paměti mobilního terminálu, jinak musí odeslat upozornění SMS centra o nemožnosti uložit;
- Class3 – v tomto případě telefon musí zaslat oznámení, že zpráva může být uložena, bez ohledu na množství paměti v zařízení. Tento typ zprávy předpokládá, že zpráva dorazila k adresátovi;
Typ zprávy
Tichá zpráva (SMS0) Typ SMS zprávy bez obsahu. Taková SMS přichází bez oznámení a nezobrazuje se na obrazovce zařízení.
PDU
Každá PDU operace je párová a skládá se z požadavku a odpovědi. Například: příkaz, který se týká navázání spojení (bind_transmitter / bind_transmitter_resp), nebo o tom, že zpráva byla odeslána (deliver_sm / deliver_sm_resp)
Každý pdu paket se skládá ze dvou částí — hlavičky (header) a těla (body). Struktura hlavičky je stejná pro jakýkoli pdu paket: command length je délka paketu, id je název paketu a příkaz status ukazuje, zda bylo zpráva úspěšně odeslána, nebo zda došlo k chybě.
Další parametry TLV
TLV (Tag Length Value), nebo další pole. Tyto parametry se používají pro rozšíření funkcí protokolu a nejsou povinné. Toto pole je uvedeno na konci pole pdu. Jako příklad s pomocí TLV dest_addr_np_information lze zorganizovat přenos informací o portabilitě čísla.
Ton a Npi
TON (Type of Number) parametr, který informuje SMSC o formátu adresace a typu sítě.
NPI (Numbering Plan Identification) parametr, který ukazuje na plán číslování.
Adresa zdroje zprávy, nebo alfa jméno
Zprávy odesílané na telefon existují ve dvou variantách: číselné a písmenkové. Číselné mohou být dlouhé (podobné číslu telefonu) a krátké. Někdy mají operátoři omezení na odesílání od neutrálních jmen, například Infosms, Alert atd. Někdy operátoři nepropouští provoz, pokud jméno není registrováno v jejich síti. To jsou však spíše specifika operátora.
Stádia odesílání
SMS-SUBMIT — to je odeslání zprávy MO FSM (krátké zprávy z mobilního terminálu)
SMS-SUBMIT REPORT — potvrzení, že zpráva byla odeslána SMSC
SRI SM (SendRoutingInfo) — SMSC získává informace od HLR o umístění MSC / VLR účastníka
SRI SM RESP — odpověď od HLR ohledně místa pobytu účastníka
MT-FSM — po obdržení polohy je odeslána zpráva pomocí operace "Forward Short Message"
MT-FSM ACK — odpověď od SMSC, že zpráva byla odeslána
SMS-STATUS REPORT — SMSC posílá status o doručení zprávy.
Status doručení zprávy
SMS-STATUS REPORT může přijímat několik hodnot:
DELIVRD zpráva byla úspěšně doručena
REJECTD — zpráva byla odmítnuta SMS centrem
EXPIRED — zpráva byla odstraněna z fronty odesílání po uplynutí TTL (doba životnosti zprávy)
UNDELIV — jiné případy nedoručení
UNKNOWN- nebyla přijata odpověď o odeslání.
Chyby přenosu
Někdy existují důvody, proč SMS zprávy nejsou doručovány účastníkovi. Důsledkem těchto příčin jsou vzniklé chyby. Chyby se vracejí v PDUs_sms_resp. Všechny chyby lze rozdělit na dočasné (Temporary) a trvalé (Permanent).
Jako příklad můžeme uvést dočasné stavy, jako je absent_subscriber — abonent není dostupný nebo není online, a trvalé stavy — abonent neexistuje. V závislosti na typech chyb se vytváří politika opakovaného zasílání těchto zpráv.
Pokud byl abonent během hovoru a obdržel chybu MT handset is busy, zprávu lze znovu odeslat za několik minut, avšak pokud má abonent zablokovanou službu příjmu zpráv, opakované zasílání nebude mělo smysl. Seznam chyb najdete na stránkách SMSC, například, jako .
Zdroj: habr.com
