SMPP ( Short Message Peer-to-Peer ) este o transmisie peer-to-peer a mesajelor scurte . Este un protocol deschis în industria telecomunicațiilor, care este conceput special pentru a oferi o interfață flexibilă pentru mesageria SMS între platformele de aplicații SMS ( ESME ), routere (RE) și centrele de servicii pentru mesaje scurte ( SMS ). [unu]
SMPP este adesea folosit de terți, cum ar fi furnizorii de servicii cu valoare adăugată, instituțiile de știri, pentru a trimite mesaje SMS - adesea în vrac. Folosind acest protocol, puteți trimite SMS , EMS , notificări de mesagerie vocală, difuzare celulară , mesaje WAP , mesaje USSD etc. Datorită versatilității sale, care constă în suportul GSM , UMTS , IS-95 ( CDMA ), CDMA2000 , ANSI 136 ( TDMA ) și altele asemenea, SMPP este cel mai utilizat protocol de mesaje scurte în afara rețelelor SS7 ( SS7 ).
În noiembrie 1995, ETSI a inclus protocolul SMPP în TR 03.39. [2]
SMPP utilizează un model de operare client-server. Centrul de mesaje ( SMSC ) acționează de obicei ca un server, așteptând o conexiune de la un client - ESME . Atunci când SMPP este utilizat pentru peeringul SMS, MC-ul expeditor acționează de obicei ca client.
Protocolul se bazează pe schimbul de perechi de PDU -uri cerere-răspuns (unități de date protocol sau pachete) la nivelul al 4-lea OSI ( sesiuni TCP sau X25 SVC3). [3] Portul bine-cunoscut alocat de IANA către SMPP atunci când lucrează pe TCP este 2775, dar sunt adesea folosite numere de porturi arbitrare.
Înainte de a schimba mesaje, comanda bind trebuie trimisă și confirmată. Comanda bind determină în ce direcție pot fi trimise mesajele; bind_transmitter permite clientului să trimită doar mesaje către server, bind_receiver înseamnă că clientul va primi doar mesaje, iar bind_transceiver (introdus în SMPP 3.4 [4] ) permite trimiterea mesajelor în ambele direcții. Când trimite o comandă de legătură, ESME trebuie să se identifice cu parametrii system_id, system_type și parola; address_range este destinat să indice o adresă ESME, dar de obicei este transmisă goală. De asemenea, în comanda de legare există interface_version, care indică versiunea protocolului care va fi folosită în timpul sesiunii.
Mesageria poate fi sincronă, unde fiecare nod așteaptă un răspuns pe PDU, sau asincronă, unde cererile multiple pot fi trimise fără a aștepta un răspuns; numărul de cereri neconfirmate se numește „fereastră”; pentru cea mai bună experiență, ambele părți ar trebui să aibă setări identice pentru dimensiunea ferestrei.
În SMPP, PDU-urile sunt codificate în binar pentru o eficiență maximă. Ele încep cu un antet PDU, care poate fi urmat de un corp PDU.
| SMPP PDU | ||||
| Antet PDU (obligatoriu) | Corp PDU (opțional) | |||
| comanda lungime |
comanda ID |
comanda stare |
Secvenţă ID |
Corp PDU |
| 4 octeți | Lungime = (Valoarea lungimii comenzii - 4) octeți | |||
Fiecare PDU începe cu un antet. Antetul este format din 4 câmpuri, fiecare dintre ele având o lungime de 4 octeți.
lungime_comandă Lungimea totală a PDU-ului în octeți (inclusiv comanda câmpului de lungime în sine); valoarea minimă este 16, deoarece fiecare PDU trebuie să conțină un antet de 16 octeți comanda_id Specifică o operație (sau o comandă) SMPP starea_comandă Întotdeauna setat la 0 în interogări; răspunsul conține informații despre rezultatul operației număr de secvență Folosit pentru a corela solicitările și răspunsurile în cadrul unei sesiuni SMPP; oferă comunicare asincronă (folosind metoda „ferestrei glisante”)Toate câmpurile numerice din SMPP sunt afișate în ordine de la mare la scăzut (în engleză big endian ), adică primul octet este cel mai semnificativ octet (MSB).
Acesta este un exemplu de PDU submit_sm de 60 de octeți . Datele sunt afișate în format hexazecimal. Antetul și corpul PDU sunt prezentate separat și împărțite în câmpuri PDU.
Se recomandă ca acest exemplu să fie comparat cu definiția specificației SMPP a PDU - ului submit_sm pentru a înțelege modul în care codificarea fiecărui câmp este conformă cu specificația.
Valorile pentru fiecare câmp PDU sunt afișate în formă zecimală în paranteze și în formă hexazecimală după ele. Dacă un câmp se întinde pe mai mult de un octet, atunci toți octeții hexazecimali corespunzători sunt reprezentați pe o singură linie.
Din nou, citiți definiția submit_sm din specificația SMPP pentru mai multă claritate.
Rețineți că formatul textului din câmpul short_message trebuie să se potrivească cu valoarea câmpului data_coding . Când data_coding este setat la 8 ( UCS2 ), textul trebuie să fie în UCS-2BE (sau extensia sa, UTF-16BE ). Când data_coding indică o codificare de 7 biți, fiecare septet este stocat ca un octet separat în câmpul short_message (cu bitul cel mai semnificativ setat la 0). Valorile de codificare a datelor din SMPP versiunea 3.3 dublează exact valorile TP-DCS din standardul GSM 03.38, făcând această versiune potrivită numai pentru alfabetul GSM pe 7 biți, UCS2 și mesajele binare. SMPP 3.4 a introdus noi valori de codificare a datelor :
| codificare_date | Sens |
|---|---|
| 0 | Alfabet implicit SMSC (SMPP 3.4) / Specific MC (SMPP 5.0) |
| unu | IA5 (CCITT T.50)/ ASCII (ANSI X3.4) |
| 2 | Octet nespecificat (binar de 8 biți) |
| 3 | Latin 1 ( ISO-8859-1 ) |
| patru | Octet nespecificat (binar de 8 biți) |
| 5 | JIS (X0208-1990) |
| 6 | chirilic ( ISO-8859-5 ) |
| 7 | latină/ebraică ( ISO-8859-8 ) |
| opt | UCS2 (ISO/IEC-10646) |
| 9 | Codificarea pictogramelor |
| zece | ISO-2022-JP (Coduri muzicale) |
| unsprezece | Rezervat |
| 12 | Rezervat |
| 13 | Kanji JIS extins (X0212-1990) |
| paisprezece | KS C 5601 |
| 15-191 | Rezervat |
| 192-207 | Control GSM MWI - vezi GSM 03.38 |
| 208-223 | Control GSM MWI - vezi GSM 03.38 |
| 224-239 | Rezervat |
| 240-255 | Controlul clasei de mesaje GSM - vezi GSM 03.38 |
Valorile 4 și 8 pentru data_coding sunt aceleași pentru toate versiunile de SMPP. Alte valori din intervalul 1-15 sunt rezervate în SMPP 3.3. Din păcate, spre deosebire de SMPP 3.3, unde data_coding = 0 a identificat în mod unic alfabetul GSM pe 7 biți, pentru SMPP 3.4 și o versiune ulterioară, alfabetul GSM pe 7 biți nu este în această listă, iar data_coding = 0 poate diferi pentru diferite SMSC - acesta poate fi ISO -8859-1 , ASCII , alfabet GSM pe 7 biți, UTF-8 sau orice altă codificare implicită. Când se utilizează data_coding = 0, ambele părți (ESME și SMSC) trebuie să se asigure că consideră că acesta este un pointer către aceeași codificare. În caz contrar, este mai bine să nu folosiți data_coding = 0. Acest lucru poate face dificilă utilizarea alfabetului GSM pe 7 biți, deoarece unele SMSC necesită data_coding = 0, altele, cum ar fi data_coding = 241.
SMPP a fost implementat în Java de către proiectul jSMPP . Este folosit în Apache Camel și în diverse alte proiecte populare de software gratuit de mesagerie SMS. Implementare alternativă a Java nmote-smpp . Proiectul python-SMPP oferă SMPP pentru utilizatorii Python . Proiectul PHP-SMPP oferă SMPP pentru utilizatorii PHP .
În ciuda utilizării pe scară largă, SMPP are o serie de caracteristici problematice:
În SMPP 3.3, toate valorile de codificare de date sunt tratate conform GSM 03.38, dar din SMPP 3.4 nu există nicio valoare de codificare de date pentru alfabetul GSM pe 7 biți.
Conform SMPP 3.4 și 5.0 data_coding =0 înseamnă ″SMSC Default Alphabet″. Ce codificare este de fapt depinde de tipul SMSC și de configurația acestuia.
Una dintre codificările din standardul CDMA C.R1001 este Shift-JIS , folosită pentru japoneză . SMPP 3.4 și 5.0 definesc trei codificări pentru japoneză (JIS, ISO-2022-JP și JIS Extended Kanji ), dar niciuna dintre ele nu este identică cu CDMA MSG_ENCODING 00101. Codificarea pictogramelor ar trebui să fie utilizată pentru a trimite mesaje Shift-JIS în SMPP ( codarea_datelor =9).
Singura modalitate de a confirma livrarea unui mesaj în SMPP 3.3 este prin câmpul text short_message din PDU deliver_sm . Cu toate acestea, formatul acestui text este descris în apendicele „B” la specificația SMPP 3.4, deși SMPP 3.4 poate (și ar trebui) să folosească câmpurile TLV receipted_message_id și message_state în acest scop . SMPP 3.3 specifică faptul că identificatorul mesajului este un șir C de până la 8 caractere hexazecimale (plus un „\0” final). Cu toate acestea, SMPP 3.4 specifică că un anumit identificator în format C-string poate conține până la 10 caractere zecimale. Aceasta separă implementările SMPP în 2 grupuri:
Cu toate acestea, specificația SMPP 3.4 afirmă că formatul PDU-ului de confirmare a livrării depinde de furnizorul SMSC. Prin urmare, formatul descris în specificație este doar una dintre opțiunile posibile. După cum sa menționat mai sus, atunci când utilizați SMPP 3.4, TLV-urile receipted_message_id și message_state TREBUIE să fie utilizate pentru a confirma livrarea unui mesaj .
| Protocoale de bază TCP /IP pe straturi ale modelului OSI | |
|---|---|
| Fizic | |
| canalizat | |
| reţea | |
| Transport | |
| sesiune | |
| Reprezentare | |
| Aplicat | |
| Altele aplicate | |
| Lista de porturi TCP și UDP | |