Здравейте! Въпреки че месинджърите и социалните мрежи изместват традиционните средства за комуникация, популярността на SMS не се намалява. Проверка на известен уебсайт или известие за транзакция продължават да съществуват, и ще продължат да съществуват. Замисляли ли сте се как всичко това работи? Често за изпращане на масови съобщения се използва протоколът SMPP, за който ще говорим по-долу.
В Хабра вече имаше статии за SMPP, ,, но целта им не беше да опишат самия протокол. Разбира се, можете да започнете директно от оригиналния източник — , но мисля, че ще е полезно да има и кратко резюме. Ще обясня с примера на v3.4. Радвам се на конструктивната ви критика.
Протоколът SMPP е протокол за равноправни съобщения. Това означава, че всеки възел/хъб сървър е равноправен. В най-простия случай схемата за обмен на SMS съобщения изглежда така:
Обаче, ако националният оператор няма маршрут за отдалечен регион, той може да поиска посредник — SMS хъб. Понякога, за да се изпрати едно SMS, трябва да се изградят вериги между няколко държави или дори континенти.
За протокола
SMPP — приложен протокол, който се основава на обмен на PDU и се предава по TCP/IP или X25 сесии за предаване на SMS и USSD съобщения. Обикновено SMPP се използва в режим на постоянна връзка, което спестява време. SMPP използва модел на комуникация клиент-сървър.
Режим на свързване
Обменът на съобщения между изпращача и SMS центъра чрез SMPP може да се провежда в следните режими:
Transmitter (предавател) — предаване на съобщение в една посока, последователно
Receiver (приемник) — само прием на съобщение от SMS центъра.
Transreceiver (приемопредавател) — обмен на съобщения между SMS центъра и потребителя
Структура
Дължина на съобщението
Едно 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).
Като пример, времевите могат да включват absent_subscriber абонат не е на разположение или не е онлайн, а постоянните — абонатът не съществува. В зависимост от грешките, които възникват, се формира политика за повторно изпращане на тези съобщения.
Например, ако абонатът е бил зает на разговора и е получил грешка MT handset is busy, съобщението може да бъде изпратено отново след няколко минути, но ако абонатът има блокирана услуга за получаване на съобщения, повторното изпращане няма да има смисъл. Списък с грешки можете да намерите на страниците на SMSC, например, както .
Източник: habr.com
