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]
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.
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 |
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).
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.
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.
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 .
Laajasta käytöstä huolimatta SMPP:llä on useita ongelmallisia ominaisuuksia:
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.
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.
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).
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 .
TCP /IP-perusprotokollat OSI -mallin kerroksittain | |
---|---|
Fyysinen | |
kanavoitu | |
verkkoon | |
Kuljetus | |
istunto | |
Edustus | |
Sovellettu | |
Muuta sovellettu | |
Luettelo TCP- ja UDP-porteista |