Krátká zpráva peer-to-peer - Short Message Peer-to-Peer - Wikipedia

Tento článek obsahuje seznam obecných Reference, ale zůstává z velké části neověřený, protože postrádá dostatečné odpovídající vložené citace. Prosím pomozte zlepšit tento článek představuji přesnější citace. (Listopadu 2018) (Zjistěte, jak a kdy odstranit tuto zprávu šablony)

Krátká zpráva peer-to-peer (SMPP) v telekomunikačním průmyslu je otevřený, průmyslový standardní protokol navržený tak, aby poskytoval flexibilní datové komunikační rozhraní pro přenos krátká zpráva^[1] data mezi Externí subjekty pro zasílání krátkých zpráv (ESME), směrovací entity (RE) a SMSC.^[2]

SMPP se často používá k povolení třetím stranám (např. poskytovatelé služeb s přidanou hodnotou například zpravodajské organizace) k odesílání zpráv, často hromadně, ale lze ji použít i pro peering SMS. SMPP je schopen nést krátké zprávy počítaje v to EMS, hlasová schránka oznámení, Mobilní vysílání, WAP zprávy včetně WAP Push zprávy (slouží k doručování MMS oznámení), USSD zprávy a další. Díky své univerzálnosti a podpořeGSM SMS protokoly, jako UMTS, IS-95 (CDMA), CDMA2000, ANSI-136 (TDMA) a iDEN „SMPP je nejčastěji používaný protokol pro výměnu krátkých zpráv venku SS7 sítí.

Dějiny

SMPP (Short Message Peer-to-Peer) původně navrhl Aldiscon, malý irština společnost, kterou později získala Logica (od roku 2016, po řadě změn Mavenir ). Protokol původně vytvořil vývojář Ian J Chambers, aby otestoval funkčnost protokolu SMSC bez použití testovacího zařízení SS7 k odesílání zpráv. V roce 1999 Logica formálně předala SMPP na Fórum vývojářů SMPP, později přejmenované na The SMS Forum a nyní se rozpadlo. Specifikace protokolu SMPP jsou stále k dispozici na webových stránkách, které rovněž obsahují upozornění, že budou odstraněny na konci roku 2007. V rámci původních podmínek předání se nyní vlastnictví SMPP vrátilo společnosti Mavenir kvůli rozpuštění SMS Fórum.

K dnešnímu dni je vývoj SMPP pozastaven a fórum SMS je rozpuštěno. Z webu SMS fóra:

31. července 2007 - Nezisková organizace SMS Forum, jejímž posláním je vyvíjet, podporovat a propagovat SMS (služby krátkých zpráv) ve prospěch globálního bezdrátového průmyslu, se rozpustí do 27. července 2007

Tisková zpráva připojená ke zprávě také varuje, že web bude brzy pozastaven. Přesto web stále většinou funguje a lze si stáhnout technické údaje (k 31. lednu 2012).

Úkon

Oproti svému názvu SMPP používá model klient-server provozu. The Centrum krátkých zpráv (SMSC) obvykle funguje jako server a čeká na připojení z ESME. Když se SMPP používá pro peering SMS, posílající MC obvykle funguje jako klient.

Protokol je založen na dvojicích PDU typu požadavek / odpověď (datové jednotky protokolu nebo pakety) vyměňovány OSI vrstva 4 (TCP relace nebo X.25 SVC3) připojení. The známý přístav přidělené IANA pro SMPP při provozu přes TCP je 2775, ale v prostředích zasílání zpráv se často používá více libovolných čísel portů.

Před výměnou jakýchkoli zpráv musí být odeslán a potvrzen příkaz vazby. Příkaz bind určuje, kterým směrem bude možné posílat zprávy; bind_transmitter umožňuje klientovi pouze odesílat zprávy na server, bind_receiver znamená, že klient bude zprávy pouze přijímat a bind_transceiver (zavedený v SMPP 3.4) umožňuje přenos zpráv v obou směrech. V příkazu bind se ESME identifikuje pomocí system_id, system_type a hesla; pole address_range navržené tak, aby obsahovalo adresu ESME, je obvykle prázdné. Příkaz bind obsahuje parametr interface_version k určení, která verze protokolu SMPP bude použita.

Výměna zpráv může být synchronní, kde každý peer čeká na odpověď pro každou odesílanou PDU, nebo asynchronní, kde může být vydáno více požadavků bez čekání a potvrzeno v šikmém pořadí druhým peerem; počet nepotvrzených požadavků se nazývá a okno; pro nejlepší výkon musí být obě komunikující strany nakonfigurovány se stejnou velikostí okna.

Verze

Standard SMPP se za tu dobu vyvinul. Nejčastěji používané verze SMPP jsou:

• SMPP 3.3 nejstarší používaná verze (i přes svá omezení je stále široce používána); podporuje GSM pouze. Generuje okamžitou odpověď pro každou odeslanou zprávu.
• SMPP 3.4 přidává volitelně Hodnota délky značky (TLV) parametry, podpora jiných než GSM SMS technologií a vysílač podpora (jednotlivá připojení, která mohou odesílat a přijímat zprávy). Výměna PDU požadavku a odpovědi SMPP mezi vysílačem ESME a SMSC může probíhat synchronně nebo asynchronně.
• SMPP 5.0 je nejnovější verze SMPP; přidává podporu pro celulární vysílání, inteligentní řízení toku. Od roku 2019 není široce používán.

Příslušná verze je předána v parametru interface_version příkazu bind.

Formát PDU (po verzi 3.4)

PDU SMPP jsou binárně kódováno pro efektivitu. Začínají hlavičkou, za kterou může následovat text:

Záhlaví PDU

Každá jednotka PDU začíná záhlaví. Záhlaví se skládá ze 4 polí, každé o délce 4 oktetů:

délka_příkazu

Je celková délka PDU v oktetech (včetně samotného pole command_length); musí být ≥ 16, protože každá PDU musí obsahovat záhlaví 16 oktetů

command_id

Identifikuje operaci SMPP (nebo příkaz). Pokud je vymazán nejvýznamnější bit, jedná se o operaci požadavku. Jinak je to odpověď.

stav_příkazu

V požadavcích má vždy hodnotu 0; v odpovědích nese informace o výsledku operace

pořadové číslo

Používá se ke korelaci požadavků a odpovědí v rámci relace SMPP; umožňuje asynchronní komunikaci (pomocí a Posuvné okno metoda)

Všechna číselná pole v SMPP používají velký endian pořadí, což znamená, že první oktet je Nejvýznamnější bajt (MSB).

Příklad

Toto je příklad binárního kódování 60 oktetu submit_sm PDU. Data jsou zobrazena v hexadecimálním formátu oktet hodnoty jako jediný výpis a následuje rozpis záhlaví a těla tohoto PDU.

To je nejlepší ve srovnání s definicí PDU submit_sm ze specifikace SMPP, abychom pochopili, jak kódování odpovídá definici pole podle definice pole.

Rozpisy hodnot jsou zobrazeny s desetinnými místy v závorkách a hexadecimálními hodnotami. Tam, kde vidíte připojený jeden nebo několik hexadecimálních oktetů, je to proto, že daná velikost pole používá kódování 1 nebo více oktetů.

Po přečtení definice PDU submit_sm ze specifikace bude toto vše jasnější.

Záhlaví PDU

'command_length', (60) ... 00 00 00 3C'command_id ', (4) ... 00 00 00 04'command_status', (0) ... 00 00 00 00'sequence_number ', (5). .. 00 00 00 05

Tělo PDU

'service_type', () ... 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 35 00'esm_class ', (0) ... 00'protocol_id', (0) ... 00'priority_flag ', (0) ... 00'schedule_delivery_time', (0) ... 00'validity_period ', (0) ... 00'registered_delivery', (0) ... 00'replace_if_present_flag ', ( 0) ... 00'data_coding ', (3) ... 03'sm_default_msg_id', (0) ... 00'sm_length ', (15) ... 0F'short_message', (Hello Wikipedia) ... 48 65 6C 6C 6F 20 57 69 6B 69 70 65 64 69 61

Text v poli short_message se musí shodovat s datovým kódováním. Když je data_coding 8 (UCS2), text musí být v UCS-2BE (nebo jeho příponě, UTF-16BE ). Když data_coding označuje 7bitové kódování, každý septet je uložen v samostatném oktetu v poli short_message (s nejvýznamnějším bitem nastaveným na 0). SMPP 3.3 data_coding přesně zkopírované hodnoty TP-DCS GSM 03.38, díky čemuž je vhodný pouze pro výchozí 7bitovou GSM abecedu, UCS2 nebo binární zprávy; SMPP 3.4 představil nový seznam hodnot data_coding:

Význam data_coding = 4 nebo 8 je stejný jako v SMPP 3.3. Další hodnoty v rozsahu 1-15 jsou rezervovány v SMPP 3.3. Na rozdíl od SMPP 3.3, kde data_coding = 0 byla jednoznačně 7bitová výchozí abeceda GSM, pro SMPP 3.4 a vyšší v tomto seznamu chybí výchozí 7bitová abeceda GSM a data_coding = 0 se mohou u různých lišit Střediska služeb krátkých zpráv -může to být ISO-8859-1, ASCII, GSM 7bitová výchozí abeceda, UTF-8 nebo dokonce konfigurovatelné podle ESME. Při použití data_coding = 0, obě strany (ESME a SMSC) musí mít jistotu, že to považují za stejné kódování. Jinak je lepší jej nepoužívat data_coding = 0. Může být obtížné použít 7bitovou výchozí abecedu GSM, některé Střediska služeb krátkých zpráv vyžaduje data_coding = 0, ostatní např. data_coding = 241.

Vtipy

Navzdory širokému přijetí má SMPP řadu problematických funkcí:

• Ne data_coding pro výchozí 7bitovou abecedu GSM
• Nestandardizovaný význam data_coding = 0
• Nejasná podpora pro kódování Shift-JIS
• Neslučitelnost submit_sm_resp mezi verzemi SMPP
• Používání potvrzení o doručení SMPP 3.3 SMSC, zejména formát ID zprávy v nich

Žádné datové kódování pro výchozí 7bitovou abecedu GSM

Ačkoli hodnota data_coding v SMPP 3.3 je založena na GSM 03.38, protože SMPP 3.4 neexistuje žádná hodnota data_coding pro 7bitovou abecedu GSM (GSM 03.38 ). Je však běžné, že DCS = 0 označuje 7bitovou abecedu GSM, zejména pro připojení SMPP k SMSC v mobilních sítích GSM.

Nestandardizovaný význam data_coding = 0

Podle SMPP 3.4 a 5.0 data_coding = 0 znamená „Výchozí abeceda SMSC“. O jaké kódování skutečně jde, záleží na typu SMSC a jeho konfiguraci.

Nejasná podpora pro kódování Shift-JIS

Jedno z kódování ve standardu CDMA C.R1001 je Shift-JIS používá se pro japonštinu. SMPP 3.4 a 5.0 specifikuje tři kódování pro japonštinu (JIS, ISO-2022-JP a Extended Kanji JIS), ale žádné z nich není totožné s CDMA MSG_ENCODING 00101. Zdá se, že kódování piktogramu (data_coding = 9) se používá k přenosu zprávy v Shift-JIS v SMPP.

Nekompatibilita submit_sm_resp mezi verzemi SMPP

Když selže odeslání_sm, SMSC vrátí a submit_sm_resp s nenulovou hodnotou command_status a „prázdným“ message_id.

• SMPP 3.3 výslovně uvádí o pole message_id „Pokud toto pole chybí, musí obsahovat jeden NULL bajt“. Délka PDU je nejméně 17 oktetů.
• SMPP 3.4 obsahuje nešťastnou poznámku v SUBMIT_SM_RESP sekce ″ The submit_sm_resp Tělo PDU se nevrací, pokud stav_příkazu pole obsahuje nenulovou hodnotu. “Pak je délka PDU 16 oktetů.
• SMPP 5.0 to jen specifikuje id_zpravy je povinný parametr řetězce typu C-Octet v submit_sm_resp zpráva. Podle části 3.1.1 Nastavení NULL je ″ NULL řetězec ″ ″ zakódován jako 0x00 ″. Délka PDU je nejméně 17 oktetů.

Pro nejlepší kompatibilitu by jakákoli implementace SMPP měla přijímat obě varianty negativu submit_sm_resp bez ohledu na verzi standardu SMPP použitou pro komunikaci.

Původním záměrem chybových scénářů bylo, že v odpovědi PDU nebude vrácen žádný text. Toto bylo standardní chování, které se projevovalo na všech Aldiscon / Logica SMSC a také u většiny ostatních prodejců. Když fórum WAP převzalo SMPP 3.4, bylo požadováno několik objasnění, zda by měl být subjekt zahrnut do odpovědi NACKed, a byla přijata opatření k objasnění tohoto na několika místech ve specifikaci, včetně submit_sm sekci a také v bind_transceiver sekce. Mělo se udělat, bylo přidat vysvětlení, které jsme nakonec přidali ve V5.0 .. že těla by neměla být zahrnuta do chybových odpovědí. Někteří prodejci byli ve svých implementacích velmi hloupí, včetně orgánů o odmítnutí bind_transmitter odpovědi, ale ne na bind_transceiver odpovědi atd. Doporučení, které bych poskytl prodejcům .. jak bylo navrženo výše .. akceptujte obě varianty. Ale je také moudré nechat si vydat NACKed submit_sm_resp a deliver_sm_resp PDU s prázdným tělem a bez něj. V případě těchto dvou PDU bude toto prázdné tělo vypadat jako jediný NULL oktet na konci streamu. Důvod, proč budete potřebovat tuto schopnost zahrnout to, čemu říkám fiktivní těla, s požadavky NACKed je ten, že druhá strana rovnice může být neschopná nebo neochotná změnit jejich implementaci, aby tolerovala chybějící tělo. (Pracoval jsem na třech verzích specifikace SMPP v Aldiscon / Logica a navrhl řešení ESME pro Openmind Networks)

— Cormac Long

ID zprávy v SMPP 3.3 Potvrzení o doručení SMSC

Jediným způsobem, jak předat potvrzení o doručení v SMPP 3.3, je předat informace do textového formuláře krátká zpráva pole; formát textu je však popsán v příloze B SMPP 3.4, ačkoli SMPP 3.4 může (a měl by) používat ID_příjmené_správy a stav zprávy za účelem. Zatímco SMPP 3.3 uvádí, že ID zprávy je řetězec C-oktetu (hexadecimální) až 8 znaků (plus zakončení ' 0'), SMPP 3.4 uvádí, že pole id ve formátu potvrzení o doručení je řetězec C-oktetu ( Desetinné) až 10 znaků. Tím se implementace SMPP rozdělí do 2 skupin:

• Implementace využívající desetinnou reprezentaci celého čísla ID zprávy v poli id ​​těla těla doručenky a hexadecimální reprezentaci celého čísla ID zprávy v id_zpravy a ID_příjmené_správy pole
• Implementace používající stejné šestnáctkové číslo (nebo dokonce stejný libovolný řetězec) v obou id_zpravy parametr a v poli id ​​těla potvrzení o doručení, které přísně vzato, porušuje standard SMPP

Rozšiřitelnost, kompatibilita a interoperabilita

Od zavedení Hodnota délky značky (TLV) ve verzi 3.4, lze SMPP považovat za rozšiřitelný protokol. Za účelem dosažení nejvyšší možné míry kompatibility a interoperabilita jakákoli implementace by měla používat internet princip robustnosti: „Buďte konzervativní v tom, co posíláte, buďte liberální v tom, co přijímáte“. Měl by používat minimální sadu funkcí, které jsou nezbytné pro splnění úkolu. A pokud je cílem komunikace a ne hádka, každá implementace by měla standardně překonat drobné neshody:

• Odpovězte pomocí a generic_nack s command_status = 3 na jakýkoli nerozpoznaný příkaz SMPP, ale komunikaci nezastavujte.
• Ignorujte všechny nerozpoznané, neočekávané nebo nepodporované parametry TLV.
• Hranice PDU jsou vždy dány PDU délka_příkazu pole. Žádné pole zprávy nesmí překročit konec PDU. Pokud pole není správně dokončeno, mělo by se s ním zacházet na konci PDU jako zkrácené a nemělo by to ovlivnit další PDU.

Informace vztahující se k jedné verzi SMPP lze často najít v jiné verzi SMPP, například v případě SMPP 3.4 popisujícího jediný mechanismus potvrzení o doručení v SMPP 3.3 popsaném výše.

Bezpečnostní

Protokol SMPP je navržen na binárním protokolu ve formátu prostého textu, který je třeba vzít v úvahu, pokud se používá pro potenciálně citlivé informace, jako jsou jednorázová hesla prostřednictvím SMS. V případě potřeby však existují implementace SMPP přes zabezpečený SSL / TLS.^[3]

Viz také

• Univerzální počítačový protokol / rozhraní externího stroje (UCP / EMI)
• Počítačové rozhraní pro distribuci zpráv (CIMD)
• Bohaté komunikační služby

Reference

externí odkazy

• O připojení SMPP mezi počítačem a SMSC
• SMPP implementován v Javě