SMPP

Kokeneet kirjoittajat eivät ole vielä tarkistaneet sivun nykyistä versiota, ja se voi poiketa merkittävästi 24. tammikuuta 2020 tarkistetusta versiosta . tarkastukset vaativat 20 muokkausta .

SMPP ( Short Message Peer-to-Peer ) on lyhytsanomien vertaislähetys .  Se on tietoliikennealan avoin protokolla, joka on erityisesti suunniteltu tarjoamaan joustava rajapinta SMS-viestintään SMS-sovellusalustojen ( ESME ), reitittimien (RE) ja lyhytsanomapalvelukeskusten ( SMSC ) välillä. [yksi]

Kolmannet osapuolet, kuten lisäarvopalveluntarjoajat, uutistoimistot, käyttävät usein SMPP:tä tekstiviestien lähettämiseen - usein joukkona. Tämän protokollan avulla voit lähettää tekstiviestejä , EMS- , puheposti-ilmoituksia, matkapuhelinlähetyksiä , WAP - viestejä, USSD -viestejä jne. Monipuolisuuden ansiosta, joka koostuu GSM- , UMTS- , IS-95 ( CDMA ), CDMA2000 , ANSI 136 -tuesta. ( TDMA ) ja vastaavat, SMPP on laajimmin käytetty lyhytsanomaprotokolla SS7 ( SS7 ) -verkkojen ulkopuolella.

Marraskuussa 1995 ETSI sisällytti SMPP-protokollan TR 03.39:ään. [2]

Työprosessi

SMPP käyttää asiakas-palvelin -toimintamallia. Viestikeskus ( SMSC ) toimii tyypillisesti palvelimena, joka odottaa yhteyttä asiakkaalta - ESME . Kun SMPP:tä käytetään tekstiviestien peeringissä, lähettävä MC yleensä toimii asiakkaana.

Protokolla perustuu pyyntö-vastaus- PDU -parien (protokolladatayksiköiden tai -pakettien) vaihtoon 4. OSI-kerroksessa ( TCP - istunnot tai X25 SVC3). [3] IANA :n SMPP:lle TCP :llä työskennellessä osoittama tunnettu portti on 2775, mutta usein käytetään mielivaltaisia ​​porttinumeroita.

Ennen viestien vaihtoa sidoskomento on lähetettävä ja kuitattava. Sidoskomento määrittää, mihin suuntaan viestejä voidaan lähettää; bind_transmitter sallii asiakkaan lähettää vain viestejä palvelimelle, bind_receiver tarkoittaa, että asiakas vastaanottaa vain viestejä, ja bind_transceiver (otettu käyttöön SMPP 3.4:ssä [4] ) sallii viestien lähettämisen molempiin suuntiin. Sidoskomentoa lähetettäessä ESME :n on tunnistettava itsensä system_id-, system_type- ja salasanaparametreilla; osoiteväli on tarkoitettu osoittamaan ESME-osoitetta, mutta se välitetään yleensä tyhjänä. Lisäksi sitovassa komennossa on interface_version, joka ilmaisee istunnon aikana käytettävän protokollan version.

Viestintä voi olla synkronista, jossa jokainen solmu odottaa vastausta PDU:ta kohti, tai asynkronista, jolloin voidaan lähettää useita pyyntöjä odottamatta vastausta; vahvistamattomien pyyntöjen määrää kutsutaan "ikkunaksi"; Parhaan kokemuksen saamiseksi molemmilla puolilla on oltava samat ikkunan kokoasetukset.

PDU-muoto

SMPP:ssä PDU:t koodataan binäärimuodossa maksimaalisen tehokkuuden saavuttamiseksi. Ne alkavat PDU-otsikolla, jota voi seurata PDU-runko.

SMPP PDU
PDU-otsikko (pakollinen) PDU-runko (valinnainen)
komento

pituus

komento

ID

komento

Tila

Järjestys

ID

PDU-runko
4 oktettia Pituus = (komennon pituus - 4) oktettia

PDU-otsikko

Jokainen PDU alkaa otsikolla. Otsikko koostuu 4 kentästä, joista jokainen on 4 oktettia pitkä.

komento_pituus PDU:n kokonaispituus okteteina (mukaan lukien itse pituuskentän komento); pienin arvo on 16, koska jokaisen PDU:n on sisällettävä 16 oktetin otsikko komentotunnus Määrittää SMPP-toiminnon (tai komennon) komento_tila Aseta aina 0 kyselyissä; vastaus sisältää tietoa toimenpiteen tuloksesta sekvenssi numero Käytetään korreloimaan pyyntöjä ja vastauksia SMPP-istunnon sisällä; tarjoaa asynkronisen tiedonsiirron ("liukuvan ikkunan" menetelmällä)

Kaikki SMPP:n numeeriset kentät näytetään järjestyksessä korkeasta matalaan ( englanniksi  big endian ), eli ensimmäinen oktetti on merkittävin tavu (MSB).

Esimerkkejä

Tämä on esimerkki 60 oktetin submit_sm PDU:sta . Tiedot näytetään heksadesimaalimuodossa. PDU-otsikko ja runko esitetään erikseen ja jaoteltuina PDU-kenttiin.

On suositeltavaa, että tämä esimerkki verrataan SMPP-määrityksen submit_sm PDU :n määritelmään, jotta ymmärrettäisiin, kuinka kunkin kentän koodaus on määrityksen mukainen.

Kunkin PDU-kentän arvot näytetään desimaalimuodossa suluissa ja heksadesimaalimuodossa niiden jälkeen. Jos kenttä kattaa useamman kuin yhden oktetin, kaikki vastaavat heksadesimaalioktetit esitetään yhdellä rivillä.

Lue vielä kerran SMPP -spesifikaatiossa oleva submit_sm.

PDU-otsikko

'komennon_pituus', (60) ... 00 00 00 3C 'komentotunnus', (4) ... 00 00 00 04 'komennon_tila', (0) ... 00 00 00 00 'sekvenssinumero', (5) ... 00 00 00 05

PDU-sisältö

'palvelun_tyyppi', () ... 00 'source_addr_ton', (2) ... 02 'source_addr_npi ' , (8) ... 08 'source_addr', (555) ... 35 35 35 00 'dest_addr_ton', (1) ... 01 'dest_addr_npi ' , (1) ... 01 'dest_addr', (555555555) ... 35 35 35 35 35 35 35 35 35 00 "esm_class", (0) ... 00 'protokollan_tunnus', (0) ... 00 'priority_flag', (0) ... 00 'schedule_delivery_time', (0) ... 00 'validity_period', (0) ... 00 'rekisteröity_toimitus', (0) ... 00 'replace_if_present_flag', (0) ... 00 'data_coding', (3) ... 03 'sm_default_msg_id', (0) ... 00 'sm_length', (15) ... 0F 'short_message', (Hei Wikipedia) ... 48 65 6C 6C 6F 20 77 69 6B 69 70 65 64 69 61'

Huomaa, että short_message- kentän tekstin muodon on vastattava data_coding -kentän arvoa . Kun data_koodaus on asetettu arvoon 8 ( UCS2 ), tekstin on oltava UCS-2BE:ssä (tai sen laajennuksessa UTF-16BE ). Kun data_coding ilmaisee 7-bittistä koodausta, kukin septetti tallennetaan erillisenä oktettina short_message- kenttään (merkittävimmän bitin ollessa 0). Data_coding -arvot SMPP -versiossa 3.3 kopioivat täsmälleen GSM 03.38 -standardin TP-DCS-arvot, joten tämä versio sopii vain GSM 7-bittisille aakkosille, UCS2- ja binääriviesteille. SMPP 3.4 esitteli uusia data_coding- arvoja :

data_koodaus Merkitys
0 SMSC-oletusaakkoset (SMPP 3.4) / MC-kohtainen (SMPP 5.0)
yksi IA5 (CCITT T.50) / ASCII (ANSI X3.4)
2 Oktetti määrittelemätön (8-bittinen binaari)
3 Latinalainen 1 ( ISO-8859-1 )
neljä Oktetti määrittelemätön (8-bittinen binaari)
5 JIS (X0208-1990)
6 Kyrillinen ( ISO-8859-5 )
7 latina/heprea ( ISO-8859-8 )
kahdeksan UCS2 (ISO/IEC-10646)
9 Piktogrammin koodaus
kymmenen ISO-2022-JP (musiikkikoodit)
yksitoista Varattu
12 Varattu
13 Laajennettu Kanji JIS (X0212-1990)
neljätoista KS C 5601
15-191 Varattu
192-207 GSM MWI ohjaus - katso GSM 03.38
208-223 GSM MWI ohjaus - katso GSM 03.38
224-239 Varattu
240-255 GSM-viestiluokan ohjaus - katso GSM 03.38

Data_codingin arvot 4 ja 8 ovat samat kaikissa SMPP -versioissa. Muut arvot välillä 1-15 on varattu SMPP 3.3:ssa. Valitettavasti toisin kuin SMPP 3.3, jossa data_koodaus = 0 yksilöi GSM:n 7-bittisen aakkoston, SMPP 3.4:ssä ja sitä uudemmissa versioissa GSM 7-bittinen aakkosto ei ole tässä luettelossa, ja data_coding = 0 voi vaihdella eri SMSC :issä – tämä voi olla ISO -8859-1 , ASCII , GSM 7-bittinen aakkoset, UTF-8 tai mikä tahansa muu oletuskoodaus. Data_coding = 0 käytettäessä molempien osapuolten (ESME ja SMSC) on oltava varmoja, että he pitävät tätä osoittimena samaan koodaukseen. Muuten on parempi olla käyttämättä data_coding = 0. Tämä voi vaikeuttaa GSM 7-bittisten aakkosten käyttöä, koska jotkut SMSC :t vaativat data_coding = 0, toiset, kuten data_coding = 241.

Toteutukset

SMPP on toteutettu Javassa jSMPP - projektissa . Sitä käytetään Apache Camelissa ja monissa muissa suosituissa ilmaisissa tekstiviestiohjelmistoprojekteissa. Vaihtoehtoinen Java nmote-smpp -toteutus . Python - SMPP-projekti tarjoaa SMPP:n Python -käyttäjille . PHP-SMPP-projekti tarjoaa SMPP:n PHP - käyttäjille .

Ominaisuudet

Laajasta käytöstä huolimatta SMPP:llä on useita ongelmallisia ominaisuuksia:

Puuttuva data_coding-arvo GSM 7-bittiselle aakkoselle

SMPP 3.3:ssa kaikki data_coding- arvot käsitellään GSM 03.38:n mukaisesti, mutta SMPP 3.4 :n jälkeen GSM 7-bittiselle aakkostolle ei ole data_coding -arvoa.

Standardoinnin puute data_coding=0:lle

SMPP 3.4:n ja 5.0 :n mukaan data_coding =0 tarkoittaa ″SMSC-oletusaakkosta″. Se, mikä koodaus se todella on, riippuu SMSC -tyypistä ja sen kokoonpanosta.

Fuzzy Shift-JIS-koodaustuki

Yksi CDMA C.R1001 -standardin koodauksista on Shift-JIS , jota käytetään japanissa . SMPP 3.4 ja 5.0 määrittelevät kolme koodausta japanin kielelle (JIS, ISO-2022-JP ja JIS Extended Kanji ), mutta mikään niistä ei ole identtinen CDMA MSG_ENCODING 00101 kanssa. Piktogrammikoodausta on tarkoitus käyttää Shift-JIS-sanomien lähettämiseen. SMPP ( data_koodaus =9).

submit_sm_resp yhteensopimattomuus SMPP-versioiden välillä

Viestitunnuksen ominaisuudet vastaanotettaessa toimitusraporttia SMPP 3.3:ssa

Ainoa tapa vahvistaa viestin toimittaminen SMPP 3.3:ssa on delivery_sm PDU:n short_message - tekstikenttä . Tämän tekstin muoto on kuitenkin kuvattu SMPP 3.4 -spesifikaation liitteessä "B", vaikka SMPP 3.4 voi (ja sen pitäisi) käyttää TLV-kenttiä Received_message_id ja message_state tähän tarkoitukseen . SMPP 3.3 määrittää, että viestin tunniste on C-merkkijono , jossa on enintään 8 heksadesimaalimerkkiä (sekä lopussa oleva \0). SMPP 3.4 kuitenkin määrittää, että tietty tunniste C-merkkijonomuodossa voi sisältää enintään 10 desimaalimerkkiä. Tämä jakaa SMPP-toteutukset kahteen ryhmään:

SMPP 3.4 -spesifikaatiossa kuitenkin todetaan, että toimitusvahvistus-PDU:n muoto riippuu SMSC-palveluntarjoajasta. Siksi eritelmässä kuvattu muoto on vain yksi mahdollisista vaihtoehdoista. Kuten yllä todettiin, käytettäessä SMPP 3.4: ää, TLV-tunnisteita Received_message_id ja message_state PITÄÄ käyttää vahvistamaan viestin toimittaminen .

Muistiinpanot

  1. "Short Message Peer-to-Peer Protocol Specification v5.0" Arkistoitu 11. huhtikuuta 2021 Wayback Machinessa , SMS Forum, 19. helmikuuta 2003
  2. Friedhelm Hillebrand. Short Message Service (SMS): Henkilökohtaisen globaalin tekstiviestinnän  luominen . - Wiley , 2010. - S. 112. - 194 s. — ISBN 978-0-470-68865-6 .
  3. Croft, N. Forensics: hiljainen tekstiviestihyökkäys  // IEEE  : Journal  . - 2012. - ISSN 2330-9881 . - doi : 10.1109/ISSA.2012.6320454 .
  4. "Short Message Peer to Peer Protocol Specification v3.4" Arkistoitu 11. huhtikuuta 2021 Wayback Machinessa , SMPP Developers Forum, 12. lokakuuta 1999

Muut SMS-protokollat