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

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

В Хабра вече имаше статии за SMPP, 1,2, но целта им не беше да опишат самия протокол. Разбира се, можете да започнете направо от първоизточника — спецификации, но мисля, че ще е добре да съществува и кратко резюме. Ще обясня на примера на v3.4. Радвам се на вашата обективна критика.

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

Обаче, ако националният оператор няма маршрут към някой отдалечен регион, той трябва да поиска помощ от посредник — СМС хъб. Понякога, за да изпратите едно СМС, е нужно да се изгради верига между няколко страни или дори континенти.

За протокола

SMPP е протокол на приложния слой, който се основава на обмяната на PDU и се предава върху TCP/IP или X25 сесии за предаване на СМС и USSD съобщения. Обикновено SMPP се използва в режим на постоянно свързване, което помага да се спести време. SMPP използва модел на комуникация клиент — сървър.

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

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

Transmitter (предавател) — предаване на съобщение в една посока, последователно
Receiver (приемник) — само прием на съобщение от СМС центъра.
Transreceiver (приемопредавател) — обмен на съобщения между СМС центъра и потребителя

Структура

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

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

Data Coding Scheme

Въпреки това, за да се предаде съобщение, символите трябва да бъдат кодирани. В протокола 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 — в този случай телефонът трябва да изпрати уведомление, че съобщението може да бъде запазено, независимо от наличието на памет в устройството. Този тип съобщение предполага, че съобщението е достигнало до получателя;

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

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

PDU

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

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

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

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

Ton и Npi

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

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

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

Етапи на изпращане

SMS-SUBMIT — това е изпращането на съобщение MO FSM (кратко съобщение от мобилен терминал)
SMS-SUBMIT REPORT — потвърждение, че съобщението е изпратено до SMSC
SRI SM (SendRoutingInfo) — SMSC получава информация от HLR относно местоположението на MSC / VLR на абоната
SRI SM RESP — отговор от HLR относно местоположението на абоната
MT-FSM — след получаване на местоположението, съобщението се изпраща с операцията 'Forward Short Message'
MT-FSM ACK — отговор от SMSC, че съобщението е изпратено
SMS-STATUS REPORT — SMSC изпраща статус относно доставката на съобщението.

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

SMS-STATUS REPORT може да приема няколко стойности:
DELIVRD съобщението е успешно доставено
REJECTD — съобщението е отхвърлено от SMS-центъра
EXPIRED — съобщението е изтрито от опашката за изпращане след изтичането на TTL (време на живот на съобщението)
UNDELIV — други случаи на недоставка
UNKNOWN- не е получен отговор за изпращането.

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

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

Например, временно абонент не е на разположение или не е в мрежата, а за постоянния — абонентът не съществува. Въз основа на възникналите грешки се формира политика за повторно изпращане на тези съобщения.

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

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