Domov › Služby › Problémy s protokolem SMPP. Odesílání SMS přes protokol smpp, api pro vývojáře

Problémy s protokolem SMPP. Odesílání SMS přes protokol smpp, api pro vývojáře

SMPP (zkratka: Short message peer-to-peer protocol) v překladu z angličtiny znamená „Short message peer-to-peer protocol“ a umožňuje popsat interakci mezi SMS serverem a koncovým klientem. Tento protokol je jedním z nejoblíbenějších mezi poskytovateli SMS, kteří jej využívají k výměně textových zpráv mezi SMS centry se stejnými právy. Pro práci s protokolem SMPP musíte mít neustále zapnutý server a příslušný software kompatibilní s SMS bránou poskytovatele.

Podporuje různé textové formáty a wap sms;
Posílání dlouhých textů;
Obousměrné zasílání zpráv;
výběr rychlosti odesílání;
Výběr metody kódování;
Rozšiřitelnost;
Získejte podrobné zprávy.

Protokol je nepostradatelný pro pravidelné odesílání velkého množství zpráv přes spolehlivý a vysokorychlostní kanál. Proto poskytovatel SMS obvykle používá tento protokol pro výměnu SMS a USSD zpráv v systémech VAS, pro připojení různých externích systémů atd. Více o protokolu SMPP ao tom, jak probíhá zasílání pošty, se můžete dozvědět od našich specialistů.

Podporované příkazy
Parametry odesílání zpráv (SUBMIT_SM) přes SMPP
Pravidla pro práci s připojením smpp
Formát potvrzení o doručení
Vyhrazené chybové kódy protokolu smpp
Aplikace

Popis chyby lze nalézt ve specifikaci SMPP 3.4.

Pozor: Je potřeba zaslat seznam IP adres, ze kterých budete chtít
připojte se dříve, než začnete používat SMPP.

Nastavení připojení pomocí SMPP

system_id - uživatelské jméno ve tvaru XXXX.X registrované v systému
heslo - heslo uživatele
Adresa -
Port - 8056

Podporované příkazy SMPP

Nepodporované příkazy obdrží zprávy GENERIC_NAK s kódem chyby ESME_RINVCMDID.

Parametry pro odeslání zprávy (SUBMIT_SM) přes protokol smpp

Pravidla pro práci s připojením SMPP

Po navázání spojení má klient 10 sekund na odeslání příkazu BIND_TRANSMITTER nebo BIND_TRANSCEIVER, jinak bude spojení uzavřeno.

Klient musí na všechny pakety přijaté přes bránu odpovědět do 1 minuty odpovídajícím resp. paketem, jinak bude spojení ukončeno bez odeslání UNBIND.

Získání stavu doručení zprávy

Existují dvě možnosti, jak získat stav doručení pomocí protokolu smpp (aktivní a pasivní). Upřednostňuje se pasivní varianta.

Pasivní možnost zahrnuje nastavení příznaku Registered_delivery balíčku SUBMIT_SM.
Poté, co zpráva dosáhne konečného stavu, server odešle paket DELIVER_SM se zprávou o doručení. Formát zprávy Potvrzení o doručení je níže.

Aktivní volba umožňuje pravidelné dotazování na stav zprávy odesláním
QUERY_SM.

Formát potvrzení o doručení

"id:IIIIIIIIIIII sub:SSS dlvrd:DDD datum odeslání:YYMMDDhhmm datum dokončení:YYMMDDhhmm
stat:DDDDDDDD err:E Text: . . . . . . . . "

Vyhrazené chybové kódy pro připojení smpp

Kód	Popis
0x0400 (1024)	Kódování nebylo rozpoznáno
0x0401 (1025)	Text zprávy je příliš velký. Maximální délka by neměla přesáhnout 160
byte. 0x0402 (1026)	Chyba při registraci zprávy pro odeslání. Když dojde k této chybě kontaktujte podporu.
0x0403 (1027)	Text zprávy nebyl zkontrolován na nevhodná slova a/nebo fráze
0x0404 (1028)	Odesílatel nebo příjemce na černé listině
0x0453 (1107)	Platilo omezení na odesílání stejného textu na stejné číslo během krátké doby. Pokud chcete toto období deaktivovat nebo zkrátit, kontaktujte podporu.
0x043C (1084)	Pro požadovanou destinaci není dostupné žádné jízdné.
0x043F (1087)	Upstreamová protistrana nemá vhodný tarif.
0x045A (1114)	Zásady směrování nebyly nalezeny.
0x0446 (1094)	Chyba dopravy. Pokud k této chybě dojde, kontaktujte prosím zákaznický servis. podpora.
0x433 (1075)	Na účtu není dostatek prostředků.

26. září 2011 ve 12:59 hodin

Problémy s protokolem SMPP

Skříň

Je těžké najít na světě něco dokonalého. Protokol SMPP také není bez některých nedostatků. Popíšu své problémy s tímto protokolem. Doufám, že to někomu pomůže ve správných rozhodnutích.

První, nejproblematičtější nevýhoda: ztráta message_id při přerušení spojení. Trpí tím odesílání operací (submit_sm atd.), na které nepřišla včas odpověď. Protokol neobsahuje vestavěné prostředky pro obnovu ztracených identifikátorů. Výsledkem je, že když dorazí stav zprávy, není k čemu ji připojit. Navíc není známo, zda SMSC tuto zprávu obdržela.
Pokud je výměna provedena v synchronním režimu, bude ztracena pouze jedna zpráva. Pokud se však práce provádí v asynchronním režimu, mohou být ztráty značné.

Tato nevýhoda SMPP je možná jediná, kterou si pamatuji a kterou nelze vyřešit pomocí protokolu. Problém lze samozřejmě vyřešit, ale ne pomocí standardizovaných metod.

Zbývající nedostatky se týkají problémů s implementací. Jejich řešení zpravidla spočívá v dosažení dohody mezi SMSC a klientem SMPP a nejde nad rámec specifikace.

Druhý Chyba, která mě opravdu obtěžuje, souvisí se zprávami o doručení doručení_sm. V protokolu verze 3.4 neexistuje žádná přísná definice toho, jak by měly být informace o stavu přenášeny. Na jedné straně existuje volitelná struktura TLV, ve které jsou message_state a související parametry přenášeny v silně typované formě. Tato možnost je dobrá, až na to, že SMSC nebude moci v této struktuře posílat žádné dlouhé komentáře. Ale opakuji, nikde není tato metoda označena jako povinná (MUSÍ). Ale příklad je uveden v příloze protokolu. Zdůrazňuji: PŘÍKLAD. Ani doporučení. Příklad toho, jak SMSC může sdělovat stavové informace prostřednictvím (proboha, kdo na to přišel!!!) pole short_message. Tito. v textové podobě, podivné zkratky, divoké formáty atd.
Obecně se jedná o situaci výběru jedné z možných variant (KVĚTEN). Podle mého názoru na implementaci protokolů je výběr jedné z možností, které protokol umožňuje, výsadou strany tvořící paket. V tomto případě s balíčkem zpráv je to SMSC. A přijímající strana je povinna správně zpracovat každý paket, který odpovídá protokolu. Tvrdá realita ale říká, že pravdu má ten, kdo platí. Naprostá většina klientů SMPP rozumí pouze poli short_message.
Díky bohu byl tento důl (aplikace) odstraněn ze specifikace páté verze protokolu, ale hledejte SMPP klienty páté verze.

Třetí Nevýhodou je přenos dlouhých zpráv. Specifikace jemně odkazuje na technickou realizaci standardu služby krátkých textových zpráv Point to Point." Je tak nenápadný, že si odkazu všimnete, jen když jej konkrétně hledáte. Na tuto normu se odkazuje v části 1.4 Reference verze 3.4 specifikace.
Otázka: má být pole short_message používáno protokolem pouze v souladu s GSM 03.40? GSM 03.40 nabízí dlouhý text zprávy, který je rozdělen do řady zřetězených SMS, vybavených hlavičkami UDH. Specifikace SMPP implicitně vybízí k volnému použití – délka pole je 254 oktetů. Jedná se o dvě sms v latince nebo téměř čtyři sms v azbuce.
Pozorně si přečtěte specifikaci SMPP:

4.4.1 Syntaxe „SUBMIT_SM“.
“… Až 254 oktetů uživatelských dat krátkých zpráv. Přesný fyzický limit velikosti short_message se může lišit v závislosti na základní síti… »

Tito. omezení ukládá přepravní síť (podkladová síť). V našem případě je základní síť popsána GSM 03.40. Tedy 140 bajtů dat. Proč tak dlouhé pole? Faktem je, že lze použít 7bitové kódování, pak je zde již 160 znaků short_message je textové pole měřené v oktetech, nikoli binárně v bajtech. Možná tvůrci plánovali jiné, sofistikovanější možnosti.
Vývojář SMPP klienta chce pochopitelně zjednodušit svůj úkol. A nesnaží se komunikovat pomocí zřetězených SMS na své straně. V souladu s protokolem MŮŽE SMSC takovou službu poskytovat prostřednictvím pole message_payload (nezávisle rozdělit zprávu na SMS, poskytnout hlavičky) ve formě dle vlastního výběru (nestandardizované). Ale podle protokolu k tomu není povinen. Ano, a to lze bez obav aplikovat pouze na běžné textové zprávy. Z obchodního hlediska je otázka také kluzká – jak takové zprávy zpoplatnit? Co když ne všechny části zprávy mají stav doručeno?

Čtvrtý nevýhoda souvisí s relativním formátem času. V poměru k čemu by se měl měřit indikovaný čas? Pokud nedochází ke zpoždění ani na straně klienta, ani na SMSC a existuje mezi nimi dobrá komunikace, problémy zpravidla nevznikají. Pokud se ale na nějakém místě objeví zpoždění, pak se časové referenční body klienta a SMSC výrazně liší.
Pro schedule_delivery_time v sekci 5.2.15 je specifikováno:

"..relativní čas od aktuálního času SMSC, kdy se SMSC pokusí o doručení této zprávy."

To ale neřeší problém různých referenčních bodů.

Literatura

Specifikace protokolu Peer to Peer pro krátké zprávy v3.4
Technická realizace služby krátkých textových zpráv Point to Point"

Výměnný protokol je definován specifikací SMPP verze 3.4.

Verze 1.0 je pouze pro odesílání zpráv a získávání stavu doručení.

Přijímání zpráv není aktuálně podporováno.

Popis chyby lze nalézt ve specifikaci SMPP verze 3.4.

Pro zvýšení úrovně zabezpečení při práci se systémem můžete poskytnout seznam IP adres, ze kterých bude navázáno spojení.

Nastavení připojení

Podporované příkazy

system_id - uživatelské jméno registrované v systému.
heslo - heslo uživatele SMS
Adresa - sms.site
Port - 9001

Server odpoví na nepodporované příkazy zprávou GENERIC_NAK s kódem chyby ESME_RINVCMDID.

Parametry odesílání zpráv (SUBMIT_SM)

Pravidla pro práci s připojením SMPP

Po navázání spojení má klient 10 sekund na odeslání příkazu BIND_TRANSMITTER nebo BIND_TRANSCEIVER. V opačném případě bude připojení serverem ukončeno.

Klient je povinen odpovědět na všechny pakety zaslané serverem odpovídajícím resp. paketem do 1 minuty. V opačném případě bude připojení serverem ukončeno bez odeslání UNBIND.

Získání stavu doručení zprávy

Existují dvě možnosti, jak získat stav doručení (aktivní a pasivní). Upřednostňuje se pasivní varianta.

Pasivní možnost zahrnuje nastavení příznaku Registered_delivery balíčku SUBMIT_SM. Poté, co zpráva dosáhne konečného stavu, server odešle paket DELIVER_SM se zprávou o doručení. Formát zprávy Potvrzení o doručení je níže.

Aktivní volba umožňuje pravidelné dotazování na stav zprávy odesláním QUERY_SM.

SMPP- běžný typ protokolu používaný pro příjem a přenos SMS zpráv a požadavků USSD. Jeho zvláštností je stálé připojení, které dává jednu velmi důležitou výhodu - spojení není přerušeno a SMS jsou odesílány vysokou rychlostí (až několikanásobně vyšší než u jiných metod).

Takže při použití protokolu smpp získáte následující funkce:

1. K dispozici jsou různé formáty, včetně wap push sms;

2. zprávy odeslané prostřednictvím smpp mohou mít nejen krátký formát;

4. obousměrný kanál SMS;

5. nastavení rychlosti.

Jak můžete vidět, protokol smpp poskytuje velkou svobodu použití, ale jako každý nástroj má své vlastní jedinečné vlastnosti související s konfigurací a skutečným provozem. O tom si povíme níže.

Vlastnosti práce s protokolem

Aby smpp fungoval, je vyžadován server, který je uzpůsoben pro práci s tímto protokolem, a speciální software (klient). Navíc potřebujete stálé stabilní připojení k bráně poskytovatele. Proto dbáme na to, abychom otestovali vybavení našich klientů - server musí být kompatibilní s vysokorychlostním odesíláním SMS. Tím zpočátku zjednodušujeme poskytování kvalitních služeb.

Api jsou vhodné pro stránky napsané v jakémkoli jazyce, včetně PHP.

Klienti sami mohou vyzkoušet fungování nakonfigurovaného smpp kanálu, všechny příležitosti jsou poskytovány ještě předtím, než začnou využívat služby. To vám umožní pochopit, jak rychle budou vaše zprávy odeslané prostřednictvím protokolu smpp doručeny příjemcům.

Servisní pracovníci vám rádi pomohou porozumět všem složitostem práce přes protokol smpp, integraci pomocí php na vašem webu, pomohou s připojením a testováním všech služeb a zodpoví jakékoli dotazy.

Parametry připojení

system_id - uživatelské jméno ve tvaru XXXX.X registrované v systému
heslo - heslo uživatele
Adresa -
Port - 8056

Podporované příkazy

	Popis
BIND_TRANSMITTER	Připojte se jako VYSÍLAČ
BIND_TRANSCEIVER	Připojte se jako TRANSCEIVER
	Odeslat zprávu
	Vyžádejte si stav zprávy
	Odeslání potvrzení o doručení serverem
	Kontrola připojení
	Špatný příkaz
	Vypnutí

Pokud zadáte nesprávný příkaz, obdržíte odpověď jako GENERIC_NAK, jejíž text bude obsahovat kód chyby ESME_RINVCMDID.

Parametry pro odesílání SMS zpráv (SUBMIT_SM)

Pravidla připojení

Klient má 10 sekund na navázání spojení přes bránu smpp, během kterých musí být odeslán jeden z příkazů: BIND_TRANSCEIVER, BIND_TRANSMITTER. V opačném případě bude spojení ztraceno.

Přerušení také nastane, pokud klient neodpoví na žádný paket odeslaný serverem nejpozději do jedné minuty s příslušným paketem stanoveným pravidly. Pokud k takovému přerušení dojde, UNBIND se neodešle.

Smpp připojení je povoleno pouze z jednoho uživatelského jména najednou. Všechna ostatní připojení obdrží chybu 0x00000005 ESME Již ve stavu Bound. Pokud však potřebujete v rámci svého účtu vytvořit více než jedno připojení, můžete pro každé z těchto připojení vytvořit vlastního uživatele.

V případě odeslání Submit_sm, které je označeno příznakem registrované_doručení, je zaslání stavu SMS možné pouze uživateli, který zprávu odeslal.

Stav doručení SMS

Při práci s tímto protokolem může být stav doručení pasivní (nejlépe) nebo aktivní.

Chcete-li obdržet pasivní zprávu, musíte odeslat paket SUBMIT_SM s dříve povoleným příznakem register_delivery.

Text potvrzení o doručení v balíčku DELIVER_SM pochází ze serveru, když SMS vstoupí do konečné fáze distribuce.

Při aktivním reportu je pravidelně kontrolován stav SMS zasláním QUERY_SM.

Formát potvrzení o doručení

"id:IIIIIIIIIIII sub:SSS dlvrd:DDD datum odeslání:YYMMDDhhmm datum dokončení:YYMMDDhhmm
stat:DDDDDDD err:E Text: . . . . . . . . "

Vyhrazené chybové kódy

	Popis
	Kódování nebylo rozpoznáno
	Text zprávy je příliš velký. Maximální délka by neměla přesáhnout 160
0x0402 (1026)	Chyba při registraci zprávy pro odeslání. Když dojde k této chybě kontaktujte podporu.
	Text zprávy nebyl zkontrolován na nevhodná slova a/nebo fráze
	Odesílatel nebo příjemce na černé listině
	Platilo omezení na odesílání stejného textu na stejné číslo během krátké doby. Pokud chcete toto období deaktivovat nebo zkrátit, kontaktujte podporu.
	Pro požadovanou destinaci není dostupné žádné jízdné.
	Upstreamová protistrana nemá vhodný tarif.
	Zásady směrování nebyly nalezeny.
	Chyba dopravy. Pokud k této chybě dojde, kontaktujte prosím zákaznický servis. Podpora.
	Na účtu není dostatek prostředků.

Zkratka SMPP znamená Short message peer-to-peer protokol, protokol používaný k přenosu SMS, USSD a dalších typů zpráv, obvykle v systémech VAS. Na konci článku je seznam pojmů používaných v textu.

SMPP vyvinula společnost Aldiscon z Irska, kterou později získala společnost Logica. V roce 1999 se SMPP dostal pod kontrolu SMPP Developers Forum, později přejmenovaného na SMSForum. Protokol je založen na výměně PDU (protokolových datových jednotek) přenášených na úrovni modelu sítě OSI 4. Výměna paketů může probíhat buď synchronně (po odeslání požadavku je další výměna paketů pozastavena, dokud není přijata odpověď), nebo asynchronně (požadavky jsou odesílány bez zpoždění, odpovědi jsou zpracovávány tak, jak přicházejí). Až donedávna byla poslední publikovaná specifikace SMPP 3.4 a specifikace SMPP 5.0 byla dlouho majetkem společnosti Logica, ale nyní je také k dispozici. Obvykle se tento protokol používá v režimu trvalého připojení, což může výrazně zvýšit přenosovou rychlost, protože není nutné pokaždé navazovat spojení. Spojení může být iniciováno buď uživatelem, který se v popisu protokolu nazývá External Short Message Entity (ESME), nebo SMS centrem (SMSC).

Existuje několik režimů připojení:

Režim „Transmitter“ (vysílač) – režim pouze pro odesílání zpráv do SMSC a přijímání odpovídajících odpovědí, bez příjmu příchozích zpráv (DELIVER_SM pakety);

Režim „Přijímač“ (receiver) - v tomto režimu je vše naopak, pouze přijímá příchozí zprávy a vracejí odpovídající odpovědi od SMPP klienta do SMSC, nedochází k odesílání krátkých zpráv přes tento režim (SUBMIT _SM pakety);

režim" Transceiver" - režim pro odesílání a přijímání zpráv, proces mohou být implementovány synchronně nebo asynchronně.

Všechna data v protokolu SMPP, jak již bylo zmíněno dříve, jsou vnořena do bloků zvaných Protocol Data Units, které se skládají z hlavičky a těla.

Hlavička PDU paketu obsahuje následující pole:

délka_příkazu - Označuje celkový počet oktetů obsažených v tomto paketu, včetně pole délky.

příkaz _ id – identifikátor příkazu (například odeslat _ sm,dotaz _ sm atd.). A ID příkazu odezvy je identické s odpovídajícím ID příkazu požadavku, ale s nastavenými 31 bity.

command_status - označuje úspěch nebo selhání požadavku. Toto pole má význam pouze ve zprávě s odpovědí a ve zprávách požadavku musí být nastaveno na hodnotu NULL.

sekvence _ číslo – v tomto Pole obsahuje pořadové číslo, které umožňuje asociaci požadavků a odpovědí pro účely korelace. Použití sekvenčních čísel umožňuje asynchronní výměnu paketů SMPP.

Tělo PDU je volitelné a nemusí být součástí každého paketu PDU. Struktura těla je popsána samostatně ve specifikaci protokolu v závislosti na typu PDU.

Také v paketu PDU mohou být volitelné parametry, které mají společný formát TLV (Tag, Length, Value). Tyto parametry poskytují mechanismus pro budoucí zavedení nových parametrů, jak a kdy budou definovány v budoucích verzích protokolu SMPP. Volitelné parametry jsou pole, která mohou být volitelně zahrnuta do zprávy SMPP, mohou být zahrnuta v libovolném vhodném pořadí v sekci volitelných parametrů přenášené PDU a nemusí být nutně kódována v pořadí uvedeném ve specifikaci protokolu.

Tag – identifikátor tohoto specifického parametru volby;

Délka - určuje délku pole Hodnota v oktetech (tato délka nezahrnuje délku polí Tag a Lengt). Nepovinné pole parametru Délka bude vždy dlouhé 2 oktety;

Hodnota – toto pole obsahuje aktuální údaje pro tento parametr volby.

Oblasti použití krátkých zpráv v moderním světě jsou velké; protokol SMPP je ideální pro rychlý přenos velkého množství zpráv, například pro společnosti s velkou zákaznickou základnou nebo pro provádění SMS hlasování v reálném čase, kde existuje; velký tok příchozích a odchozích dat.

Podrobnější popis protokolu naleznete ve specifikaci v ruštině zde: SMPP_v3.4_rus.pdf

Základní pojmy a zkratky

SM (Short Message) – krátká zpráva;

SMS (Short Message Service) - Služba krátkých zpráv, přenáší SM mezi klienty mobilních sítí a také externími klientskými aplikacemi;

USSD (Unstructured Supplementary Service Data) je standardní služba v sítích GSM, která umožňuje organizovat interaktivní interakci mezi předplatitelem sítě a aplikací služby v režimu přenosu krátkých zpráv;

MMS (Multimedia Messaging Service) je systém pro přenos multimediálních zpráv (obrázky, melodie, videa) přes mobilní sítě.

SMSC (Short Message Service Center) - Středisko krátkých textových zpráv - základ pro fungování SMS;

VAS (Value Added Services) – služby, které generují dodatečný příjem;

ESME (External Short Message Entity) – externí klientská aplikace, která implementuje protokol SMPP, přijímá nebo odesílá krátké zprávy;

HLR (Home location register) - Stálá databáze účastníků připojených k mobilní síti. HLR poskytuje cestu přenosu SMS příjemci SM;

Oktet - 8 bitů. V ruštině se oktet obvykle nazývá bajt.

Oblíbené v kategorii: