SMPP - Peer-to-Peer протокол за кратки съобщения

Здравейте! Въпреки че месинджърите и социалните мрежи заместват традиционните методи за комуникация всеки ден, това не намалява популярността на SMS. Проверка на популярен сайт или известие за транзакция повтаря, че те живеят и ще живеят. Замисляли ли сте се как работи всичко? Много често протоколът SMPP се използва за изпращане на групови съобщения, които ще бъдат обсъдени в раздела.

Habré вече имаше статии за smpp, 1,2, но тяхната цел не беше да опишат самия протокол. Разбира се, можете веднага да започнете от източника - специализация, но мисля, че би било хубаво, ако има резюме на съдържанието му. Ще обясня на v3.4 като пример Радвам се за обективната ви критика.

Протоколът SMPP е peer-to-peer протокол за съобщения. Това означава, че всеки peer/hub сървър е равен. В най-простия случай схемата за SMS съобщения изглежда така:

Но ако националният оператор няма маршрут, той иска посредник за това до някой отдалечен регион - SMS хъб. Понякога, за да изпратите един SMS, трябва да изградите верига между няколко държави или дори континенти.

Относно протокола

SMPP е протокол на приложно ниво, който се основава на обмен на PDU и се предава през TCP / IP или X25 сесии за изпращане на sms и ussd съобщения. Обикновено SMPP се използва в режим на постоянна връзка, което спестява време. SMPP използва комуникационен модел клиент-сървър.

Режим на връзка

Обменът на съобщения между подателя и SMS центъра чрез SMPP може да се извършва в следните режими:

Предавател (предавател) - предаване на съобщение в една посока, на свой ред
Получател (приемник) - само получаване на съобщение от SMS центъра.
Transreceiver (трансивър) - Обмен на съобщения между SMS центъра и потребителя

Структура

Дължина на съобщението

Едно SMS съобщение може да съдържа 70 символа при въвеждане на кирилица и не повече от 157 знака на латиница + 3 UDH Ако изпратите SMS с голям брой символи, той ще бъде разделен на няколко сегмента и комбиниран в приемащото устройство. В случай на сегментиране, броят на знаците се намалява от заглавките на съобщението, които показват частта от съобщението. Следователно, когато изпращате голямо SMS съобщение, то съдържа максимум 153 латински символа или 67 нетипични символа.

Схема за кодиране на данни

Знаците обаче трябва да бъдат кодирани, за да предадат съобщение. В протокола SMPP специално поле е отговорно за кодирането - Data Coding Scheme или DCS. Това е поле, което указва как да се разпознават съобщенията. Освен това полето DCS включва:

• наборът от символи, който определя кодирането;
• клас на съобщението;
• заявка за автоматично изтриване след прочитане;
• индикация за компресиране на съобщението;
• език на излъчваното съобщение;

Стандартна 7-битова азбука (GSM 03.38). Разработен е за системата за съобщения в GSM. Това кодиране е подходящо за английски и редица латински езици. Всеки символ се състои от 7 бита и е кодиран в октет.

UTF-16 (в GSM UCS2) За да се включат липсващите знаци в 7-битовата азбука, беше разработено кодирането UTF-16, което добавя допълнителни знаци (включително кирилски) чрез намаляване на размера на съобщението от 160 на 70, този тип кодиране почти напълно повтаря Unicode.

8-битови потребителски дефинирани данни. Те включват KOI8-R и Windows-1251. Въпреки че това решение изглежда по-икономично в сравнение със същия UTF-16. Има разумен въпрос за съвместимостта на различни устройства. Тъй като в този случай и двете устройства трябва да бъдат конфигурирани предварително.

Клас на съобщението

• Class0, или flash, съобщение, съхранявано в паметта на телефона по искане на потребителя;
• Class1, или тези, които се съхраняват в паметта на телефона;
• Class1, или тези, които се съхраняват в паметта на телефона;
• Class2, трябва да гарантира, че съобщението е съхранено в паметта на мобилния терминал, в противен случай трябва да даде известия на SMS центъра за невъзможност за запазване;
• Class3 - в този случай телефонът трябва да изпрати известие, че съобщението може да бъде запазено, независимо от количеството памет в устройството. Този тип съобщение предполага, че съобщението е достигнало местоназначението си;

Тип съобщение

Безшумно съобщение (SMS0) Тип SMS съобщение без съдържание. Такива SMS идват без известие и не се показват на екрана на устройството.

PDU

Всяка pdu операция е сдвоена и се състои от заявка и отговор. Например: команда, която казва, че е установена връзка (bind_transmitter / bind_transmitter_resp), или че е изпратено съобщение (deliver_sm / deliver_sm_resp)

Всеки pdu пакет се състои от две части - заглавка (header) и тяло (body). Структурата на заглавката е една и съща за всеки pdu пакет: дължината на командата е дължината на пакета, id е името на пакета, а командата за състояние показва дали съобщението е изпратено успешно или неуспешно.

Допълнителни TLV параметри

TLV (Tag Length Value) или допълнителни полета. Такива параметри се използват за разширяване на функционалността на протокола и не са задължителни. Това поле е посочено в края на полето pdu. Като пример, използвайки dest_addr_np_information TLV, можете да организирате прехвърлянето на информация за пренасянето на номера.

Тон и Npi

Параметърът TON (Тип номер) информира SMSC за формата на адресиране и типа на мрежата.
NPI (Numbering Plan Identification) параметър, указващ номерационния план.

Адрес на източника на съобщението или алфа име

Съобщенията, изпратени до телефона, се предлагат в два вида: цифрови и азбучни. Номерата могат да бъдат дълги (подобно на телефонен номер) или кратки. Понякога операторите имат ограничения за изпращане от неутрални имена, като Infosms, Alert и др. Понякога операторите не разрешават трафик, ако името не е регистрирано в тяхната мрежа. Това обаче е по-скоро функция на оператора.

Етапи на подаване

SMS-ИЗПРАЩАНЕ изпраща MO FSM съобщение (кратко съобщение от мобилен терминал)
SMS-ИЗПРАТЕТЕ ОТЧЕТ — потвърждение, че съобщението е изпратено от SMSC
SRI SM (SendRoutingInfo) - SMSC получава информация от HLR относно местоположението на MSC/VLR на абоната
SRI SM RESP — отговор от HLR относно позицията на абоната
MT-FSM - след получаване на местоположението се изпраща съобщение чрез операцията "Препращане на кратко съобщение".
MT-FSM-ACK — отговор от SMSC, че съобщението е изпратено
ОТЧЕТ ЗА СЪСТОЯНИЕТО на SMS — SMSC изпраща състоянието на доставка на съобщението.

Състояние на доставка на съобщението

ОТЧЕТ ЗА СЪСТОЯНИЕТО на SMS може да приема няколко стойности:
ДЕЛИВРД съобщението е доставено успешно
ОТХВЪРЛЕНО — съобщението е отхвърлено от SMS центъра
ПРОСРОЧЕН - съобщението се премахва от опашката за изпращане след края на TTL (живот на съобщението)
НЕИЗПЕЛ - други случаи на липса на доставка
UNKNOWN- Не е получен отговор.

Грешки при предаване

Понякога причините, поради които SMS съобщенията не се доставят на абоната. Последицата от тези причини е появата на грешки. Грешките се връщат в PDUs_sms_resp. Всички грешки могат да бъдат разделени на временни (Temporary) и постоянни (Permanent).

Като пример, absent_subscriber е временен, абонатът не е достъпен или не е онлайн, и постоянен - ​​абонатът не съществува. В зависимост от възникналите грешки се формира политика за повторно изпращане на тези съобщения.

Например, ако абонатът е бил зает да говори и е получил грешка МТ слушалката е заета, съобщението може да бъде изпратено отново след няколко минути, но ако абонатът е блокирал услугата за получаване на съобщения, повторното изпращане няма да има смисъл. Можете да намерите списък с грешки на страниците на SMSC, например като това.

Източник: www.habr.com