SMPP ( Short Message Peer-to-Peer ) är en peer-to-peer-överföring av korta meddelanden . Det är ett öppet protokoll inom telekommunikationsindustrin som är speciellt utformat för att tillhandahålla ett flexibelt gränssnitt för SMS-meddelanden mellan SMS-applikationsplattformar ( ESME ), routrar (RE) och Short Message Service Centers ( SMSC ). [ett]
SMPP används ofta av tredje part, såsom leverantörer av mervärdestjänster, nyhetskanaler, för att skicka SMS - ofta i bulk. Med detta protokoll kan du skicka SMS , EMS , röstmeddelanden, mobilsändningar , WAP - meddelanden, USSD- meddelanden, etc. På grund av dess mångsidighet, som består i att stödja GSM , UMTS , IS-95 ( CDMA ), CDMA2000 , ANSI 136 ( TDMA ) och liknande är SMPP det mest använda kortmeddelandeprotokollet utanför SS7 ( SS7 )-nätverk.
I november 1995 inkluderade ETSI SMPP-protokollet i TR 03.39. [2]
SMPP använder en klient-server-driftsmodell. Message Center ( SMSC ) fungerar vanligtvis som en server som väntar på en anslutning från en klient -ESME . När SMPP används för SMS-peering, agerar vanligtvis den sändande MC:n som klient.
Protokollet är baserat på utbyte av par av begäran-svar PDU (protokolldataenheter eller paket) vid det 4:e OSI-lagret ( TCP -sessioner eller X25 SVC3). [3] Den välkända porten som tilldelats av IANA till SMPP när man arbetar med TCP är 2775, men godtyckliga portnummer används ofta.
Innan meddelanden utbyts måste bindningskommandot skickas och bekräftas. Bind-kommandot bestämmer i vilken riktning meddelanden kan skickas; bind_transmitter tillåter klienten att bara skicka meddelanden till servern, bind_receiver betyder att klienten endast kommer att ta emot meddelanden, och bind_transceiver (introducerad i SMPP 3.4 [4] ) tillåter att meddelanden skickas i båda riktningarna. När ett bindningskommando skickas måste ESME identifiera sig med parametrarna system_id, system_type och lösenord; adressintervall är avsett att indikera en ESME-adress, men skickas vanligtvis tomt. I bindningskommandot finns också interface_version, som anger vilken version av protokollet som kommer att användas under sessionen.
Meddelanden kan vara synkrona, där varje nod väntar på ett svar per PDU, eller asynkront, där flera förfrågningar kan skickas utan att vänta på ett svar; antalet obekräftade förfrågningar kallas "fönstret"; för bästa upplevelse bör båda sidorna ha identiska fönsterstorleksinställningar.
I SMPP är PDU:er kodade i binärt för maximal effektivitet. De börjar med en PDU-huvud, som kan följas av en PDU-kropp.
| SMPP PDU | ||||
| PDU-huvud (krävs) | PDU-kropp (valfritt) | |||
| kommando längd |
kommando ID |
kommando Status |
Sekvens ID |
PDU-kropp |
| 4 oktetter | Längd = (Command Length värde - 4) oktetter | |||
Varje PDU börjar med en rubrik. Rubriken består av 4 fält, som vart och ett är 4 oktetter långt.
kommandolängd Den totala längden av PDU:n i oktetter (inklusive själva längdfältskommandot); minimivärdet är 16, eftersom varje PDU måste innehålla ett 16-oktetthuvud kommando_id Anger en SMPP-operation (eller kommando) kommando_status Alltid inställd på 0 i frågor; svaret innehåller information om resultatet av operationen sekvensnummer Används för att korrelera förfrågningar och svar inom en SMPP-session; ger asynkron kommunikation (med "glidfönster"-metoden)Alla numeriska fält i SMPP visas i ordning från hög till låg ( engelska big endian ), det vill säga den första oktetten är den mest signifikanta byten (MSB).
Detta är ett exempel på en 60 oktett submit_sm PDU . Data visas i hexadecimalt format. PDU-huvudet och huvuddelen presenteras separat och uppdelade i PDU-fält.
Det rekommenderas att detta exempel matchas mot SMPP-specifikationens definition av submit_sm PDU för att förstå hur varje fälts kodning överensstämmer med specifikationen.
Värdena för varje PDU-fält visas i decimalform inom parentes och hexadecimalform efter dem. Om ett fält sträcker sig över mer än en oktett, representeras alla motsvarande hexadecimala oktetter på en enda rad.
Återigen, läs definitionen av submit_sm i SMPP-specifikationen för mer klarhet.
Observera att formatet på texten i fältet short_message måste matcha värdet för data_coding- fältet . När data_coding är satt till 8 ( UCS2 ), måste texten vara i UCS-2BE (eller dess tillägg, UTF-16BE ). När data_coding indikerar en 7-bitars kodning, lagras varje septett som en separat oktett i fältet short_message (med den mest signifikanta biten satt till 0). Data_coding - värdena i SMPP version 3.3 duplicerar exakt TP-DCS-värdena från GSM 03.38-standarden, vilket gör denna version endast lämplig för GSM 7-bitars alfabet, UCS2 och binära meddelanden. SMPP 3.4 introducerade nya data_coding- värden :
| data_coding | Menande |
|---|---|
| 0 | SMSC Default Alphabet (SMPP 3.4) / MC Specific (SMPP 5.0) |
| ett | IA5 (CCITT T.50)/ ASCII (ANSI X3.4) |
| 2 | Oktett ospecificerad (8-bitars binär) |
| 3 | Latin 1 ( ISO-8859-1 ) |
| fyra | Oktett ospecificerad (8-bitars binär) |
| 5 | JIS (X0208-1990) |
| 6 | Kyrillisk ( ISO-8859-5 ) |
| 7 | latin/hebreiska ( ISO-8859-8 ) |
| åtta | UCS2 (ISO/IEC-10646) |
| 9 | Piktogramkodning |
| tio | ISO-2022-JP (musikkoder) |
| elva | Reserverad |
| 12 | Reserverad |
| 13 | Utökad Kanji JIS (X0212-1990) |
| fjorton | KS C 5601 |
| 15-191 | Reserverad |
| 192-207 | GSM MWI-styrning - se GSM 03.38 |
| 208-223 | GSM MWI-styrning - se GSM 03.38 |
| 224-239 | Reserverad |
| 240-255 | GSM-meddelandeklasskontroll - se GSM 03.38 |
Värdena 4 och 8 för data_coding är desamma för alla versioner av SMPP. Andra värden i intervallet 1-15 är reserverade i SMPP 3.3. Tyvärr, till skillnad från SMPP 3.3, där data_coding = 0 unikt identifierade GSM 7-bitars alfabetet, för SMPP 3.4 och högre, finns inte GSM 7-bitars alfabetet i denna lista, och data_coding = 0 kan skilja sig åt för olika SMSC:er - detta kan vara ISO -8859-1 , ASCII , GSM 7-bitars alfabet, UTF-8 eller någon annan standardkodning. När data_coding = 0 används måste båda parter (ESME och SMSC) vara säkra på att de anser att detta är en pekare till samma kodning. Annars är det bättre att inte använda data_coding = 0. Detta kan göra det svårt att använda GSM 7-bitars alfabetet, eftersom vissa SMSC kräver data_coding = 0, andra, såsom data_coding = 241.
SMPP har implementerats i Java av jSMPP- projektet . Det används i Apache Camel och olika andra populära program för gratis SMS-meddelanden. Alternativ implementering av Java nmote-smpp . Python- SMPP -projektet tillhandahåller SMPP för Python -användare . PHP-SMPP-projektet tillhandahåller SMPP för PHP -användare .
Trots dess utbredda användning har SMPP ett antal problematiska egenskaper:
I SMPP 3.3 behandlas alla datakodningsvärden enligt GSM 03.38, men sedan SMPP 3.4 finns det inget datakodningsvärde för GSM 7-bitars alfabetet.
Enligt SMPP 3.4 och 5.0 betyder data_coding =0 ″SMSC Default Alphabet″. Vilken kodning det faktiskt är beror på SMSC- typen och dess konfiguration.
En av kodningarna i CDMA C.R1001-standarden är Shift-JIS , som används för japanska . SMPP 3.4 och 5.0 definierar tre kodningar för japanska (JIS, ISO-2022-JP och JIS Extended Kanji ), men ingen av dem är identisk med CDMA MSG_ENCODING 00101. Piktogramkodningen är tänkt att användas för att skicka Shift-JIS-meddelanden i SMPP ( data_coding =9).
Det enda sättet att bekräfta leverans av ett meddelande i SMPP 3.3 är genom textfältet short_message i leverans_sm PDU . Formatet på denna text beskrivs dock i bilaga "B" i SMPP 3.4-specifikationen, även om SMPP 3.4 kan (och bör) använda fälten receipted_message_id och message_state TLV för detta ändamål . SMPP 3.3 anger att meddelandeidentifieraren är en C-sträng med upp till 8 hexadecimala tecken (plus ett avslutande '\0'). SMPP 3.4 anger dock att en given identifierare i C-strängformat kan innehålla upp till 10 decimaltecken. Detta separerar SMPP-implementeringar i två grupper:
Emellertid anger SMPP 3.4-specifikationen att formatet för PDU:n för leveransbekräftelse är beroende av SMSC-leverantören. Därför är formatet som beskrivs i specifikationen bara ett av de möjliga alternativen. Som nämnts ovan, när du använder SMPP 3.4, SKA receipted_message_id och message_state TLV användas för att bekräfta leverans av ett meddelande .
| Grundläggande TCP / IP-protokoll efter lager av OSI-modellen | |
|---|---|
| Fysisk | |
| kanaliserad | |
| nätverk | |
| Transport | |
| session | |
| Representation | |
| Applicerad | |
| Annat ansökt | |
| Lista över TCP- och UDP-portar | |