SMPP ( Short Message Peer-to-Peer ) je peer-to-peer přenos krátkých zpráv . Jedná se o otevřený protokol v telekomunikačním průmyslu, který je speciálně navržen tak, aby poskytoval flexibilní rozhraní pro zasílání zpráv SMS mezi aplikačními platformami SMS ( ESME ), směrovači (RE) a centry krátkých zpráv ( SMSC ). [jeden]
SMPP je často používán třetími stranami, jako jsou poskytovatelé služeb s přidanou hodnotou, zpravodajská média, k odesílání SMS zpráv – často hromadně. Pomocí tohoto protokolu můžete posílat SMS , EMS , upozornění na hlasovou poštu, mobilní vysílání , WAP zprávy, USSD zprávy atd. Vzhledem k jeho univerzálnosti, která spočívá v podpoře GSM , UMTS , IS-95 ( CDMA ), CDMA2000 , ANSI 136 ( TDMA ) a podobně, SMPP je nejrozšířenějším protokolem krátkých zpráv mimo sítě SS7 ( SS7 ).
V listopadu 1995 zahrnulo ETSI protokol SMPP do TR 03.39. [2]
SMPP používá model provozu klient-server. Centrum zpráv ( SMSC ) obvykle funguje jako server a čeká na připojení od klienta - ESME . Když se SMPP používá pro peering SMS, odesílající MC se obvykle chová jako klient.
Protokol je založen na výměně párů PDU typu požadavek-odpověď (protokolové datové jednotky nebo pakety) na 4. vrstvě OSI ( TCP sessions nebo X25 SVC3). [3] Známý port přidělený IANA SMPP při práci na TCP je 2775, ale často se používají libovolná čísla portů.
Před výměnou zpráv je nutné odeslat a potvrdit příkaz bind. Příkaz bind určuje, kterým směrem lze zprávy odesílat; bind_transmitter umožňuje klientovi pouze odesílat zprávy na server, bind_receiver znamená, že klient bude pouze přijímat zprávy, a bind_transceiver (zavedený v SMPP 3.4 [4] ) umožňuje odesílání zpráv oběma směry. Při odesílání příkazu bind se ESME musí identifikovat pomocí parametrů system_id, system_type a password; rozsah_adres je určen k označení adresy ESME, ale obvykle se předává prázdný. V příkazu pro vazbu je také uvedena verze_rozhraní, která označuje verzi protokolu, která bude použita během relace.
Zasílání zpráv může být synchronní, kde každý uzel čeká na odpověď na PDU, nebo asynchronní, kdy lze odeslat více požadavků bez čekání na odpověď; počet nepotvrzených požadavků se nazývá „okno“; pro nejlepší zážitek by měly mít obě strany stejné nastavení velikosti okna.
V SMPP jsou PDU kódovány binárně pro maximální účinnost. Začínají hlavičkou PDU, po které může následovat tělo PDU.
| SMPP PDU | ||||
| Záhlaví PDU (povinné) | Tělo PDU (volitelné) | |||
| příkaz délka |
příkaz ID |
příkaz Postavení |
Sekvence ID |
Tělo PDU |
| 4 oktety | Délka = (hodnota Délka příkazu - 4) oktety | |||
Každý PDU začíná záhlavím. Hlavička se skládá ze 4 polí, z nichž každé je dlouhé 4 oktety.
délka_příkazu Celková délka PDU v oktetech (včetně samotného příkazu pole délky); minimální hodnota je 16, protože každý PDU musí obsahovat 16oktetovou hlavičku id_příkazu Určuje operaci SMPP (nebo příkaz) stav_příkazu Vždy nastaveno na 0 v dotazech; odpověď obsahuje informaci o výsledku operace pořadové_číslo Používá se ke korelaci požadavků a odpovědí v rámci relace SMPP; poskytuje asynchronní komunikaci (pomocí metody "posuvného okna")Všechna číselná pole v SMPP jsou zobrazena v pořadí od vysoké po nízkou ( anglicky big endian ), to znamená, že první oktet je nejvýznamnější byte (MSB).
Toto je příklad 60 oktetového submit_sm PDU . Data jsou zobrazena v hexadecimálním formátu. Hlavička a tělo PDU jsou uvedeny samostatně a rozděleny do polí PDU.
Doporučuje se, aby byl tento příklad porovnán s definicí SMPP specifikace submit_sm PDU , abyste pochopili, jak kódování každého pole odpovídá specifikaci.
Hodnoty pro každé pole PDU jsou uvedeny v desítkovém tvaru v závorkách a za nimi v hexadecimálním tvaru. Pokud pole zahrnuje více než jeden oktet, pak jsou všechny odpovídající hexadecimální oktety reprezentovány na jednom řádku.
Pro větší přehlednost si znovu přečtěte definici submit_sm ve specifikaci SMPP.
Všimněte si, že formát textu v poli short_message musí odpovídat hodnotě pole data_coding . Když je data_coding nastaveno na 8 ( UCS2 ), text musí být v UCS-2BE (nebo jeho rozšíření, UTF-16BE ). Když data_coding indikuje 7-bitové kódování, je každý septet uložen jako samostatný oktet v poli short_message (s nejvýznamnějším bitem nastaveným na 0). Hodnoty data_coding v SMPP verze 3.3 přesně duplikují hodnoty TP-DCS ze standardu GSM 03.38, takže tato verze je vhodná pouze pro GSM 7bitovou abecedu, UCS2 a binární zprávy. SMPP 3.4 zavedl nové hodnoty data_coding :
| kódování dat | Význam |
|---|---|
| 0 | Výchozí abeceda SMSC (SMPP 3.4) / Specifická pro MC (SMPP 5.0) |
| jeden | IA5 (CCITT T.50)/ ASCII (ANSI X3.4) |
| 2 | Nespecifikovaný oktet (8bitový binární kód) |
| 3 | Latina 1 ( ISO-8859-1 ) |
| čtyři | Nespecifikovaný oktet (8bitový binární kód) |
| 5 | JIS (X0208-1990) |
| 6 | Cyrilice ( ISO-8859-5 ) |
| 7 | latina/hebrejština ( ISO-8859-8 ) |
| osm | UCS2 (ISO/IEC-10646) |
| 9 | Kódování piktogramů |
| deset | ISO-2022-JP (hudební kódy) |
| jedenáct | Rezervováno |
| 12 | Rezervováno |
| 13 | Rozšířené Kanji JIS (X0212-1990) |
| čtrnáct | KS C 5601 |
| 15-191 | Rezervováno |
| 192-207 | GSM MWI ovládání - viz GSM 03.38 |
| 208-223 | GSM MWI ovládání - viz GSM 03.38 |
| 224-239 | Rezervováno |
| 240-255 | Ovládání třídy zpráv GSM - viz GSM 03.38 |
Hodnoty 4 a 8 pro data_coding jsou stejné pro všechny verze SMPP. Ostatní hodnoty v rozsahu 1-15 jsou vyhrazeny v SMPP 3.3. Bohužel na rozdíl od SMPP 3.3, kde data_coding = 0 jednoznačně identifikuje GSM 7bitovou abecedu, pro SMPP 3.4 a vyšší, GSM 7bitová abeceda není v tomto seznamu a data_coding = 0 se může lišit pro různé SMSC - může to být ISO -8859-1 , ASCII , GSM 7bitová abeceda, UTF-8 nebo jakékoli jiné výchozí kódování. Při použití data_coding = 0 si obě strany (ESME a SMSC) musí být jisti, že to považují za ukazatel na stejné kódování. V opačném případě je lepší nepoužívat data_coding = 0. To může ztížit použití GSM 7bitové abecedy, protože některá SMSC vyžadují data_coding = 0, jiná, například data_coding = 241.
SMPP byl v Javě implementován projektem jSMPP . Používá se v Apache Camel a různých dalších populárních bezplatných softwarových projektech pro zasílání SMS zpráv. Alternativní implementace Java nmote-smpp . Projekt python-SMPP poskytuje uživatelům Pythonu SMPP . Projekt PHP-SMPP poskytuje uživatelům PHP SMPP .
Navzdory širokému použití má SMPP řadu problematických funkcí:
V SMPP 3.3 jsou všechny hodnoty data_coding zpracovávány podle GSM 03.38, ale od SMPP 3.4 neexistuje žádná hodnota data_coding pro 7bitovou GSM abecedu.
Podle SMPP 3.4 a 5.0 data_coding =0 znamená ″Výchozí abeceda SMSC″. O jaké kódování se vlastně jedná, závisí na typu SMSC a jeho konfiguraci.
Jedno z kódování ve standardu CDMA C.R1001 je Shift-JIS , používané pro japonštinu . SMPP 3.4 a 5.0 definují tři kódování pro japonštinu (JIS, ISO-2022-JP a JIS Extended Kanji ), ale žádné z nich není identické s CDMA MSG_ENCODING 00101. Piktogramové kódování má být použito k odesílání zpráv Shift-JIS v SMPP ( kódování dat =9).
Jediný způsob, jak potvrdit doručení zprávy v SMPP 3.3, je prostřednictvím textového pole short_message v doručovacím PDU_sm . Formát tohoto textu je však popsán v Dodatku "B" specifikace SMPP 3.4, ačkoli SMPP 3.4 může (a měl by) pro tento účel používat pole TLV recipiented_message_id a message_state . SMPP 3.3 určuje, že identifikátor zprávy je C-řetězec o délce až 8 hexadecimálních znaků (plus koncové '\0'). SMPP 3.4 však uvádí, že daný identifikátor ve formátu řetězce C může obsahovat až 10 desetinných znaků. To rozděluje implementace SMPP do 2 skupin:
Specifikace SMPP 3.4 však uvádí, že formát PDU potvrzení doručení závisí na poskytovateli SMSC. Formát popsaný ve specifikaci je tedy pouze jednou z možných možností. Jak bylo uvedeno výše, při použití SMPP 3.4 BY MĚLY být pro potvrzení doručení zprávy použity TLV přijaté_zprávy_id a stavy zprávy .
| Základní protokoly TCP /IP podle vrstev modelu OSI | |
|---|---|
| Fyzický | |
| odvedeny | |
| síť | |
| Doprava | |
| zasedání | |
| Zastoupení | |
| Aplikovaný | |
| Uplatněno jiné | |
| Seznam portů TCP a UDP | |