SMPP — одноранговий протокол коротких повідомлень

Вітаю! У цій публікації розповім про те, як доставляються ваші SMS. Це коротке викладення специфікації SMPP v3.4

Протокол SMPP — це протокол однорангових повідомлень. Це означає, що кожен пір/хаб сервер рівноправний. У найпростішому випадку схема обміну смс повідомленнями виглядає так:

Проте якщо національний оператор не має маршруту в якийсь віддалений регіон, він просить про це посередника — смс-хаб. Іноді, щоб відправити одну смс, потрібно побудувати ланцюжок між кількома країнами або навіть континентами.

Про протокол

SMPP — протокол прикладного рівня, що базується на обміні PDU і передається поверх TCP/IP, або Х25 сесій для передачі SMS та ussd повідомлень. Зазвичай SMPP використовується в режимі постійного підключення, що допомагає заощадити час. SMPP використовує модель спілкування клієнт-сервер.

Режим зв’язку

Обмін повідомлень між відправником та SMSC через SMPP може проводитися в наступних режимах:

  • Transmitter (передавач) — передача повідомлення в один бік, по черзі.
  • Receiver (приймач) — лише прийом повідомлення від SMSC.
  • Transreceiver (приймач) — обмін повідомленнями між SMSC та користувачем.

Структура

Довжина повідомлення

Одне 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-1, але для використання таких кодувань потрібне попереднє налаштування на приймаючому та передавальному пристрої. Якщо на якомусь з них дані кодування не підтримуються, повідомлення буде відображатися не коректно. Оскільки в такому випадку обидва пристрої повинні бути заздалегідь налаштовані.

Клас повідомлення

  • Class0 або flash повідомлення, що зберігаються в пам’яті телефону за бажанням користувача.
  • Class1 або ті, що зберігаються у пам’яті телефону.
  • Class2 повинен гарантувати, що повідомлення збережеться в пам’яті мобільного терміналу, в іншому випадку повинен віддати оповіщення SMSC про неможливість зберегти.
  • Class3 — телефон повинен надіслати повідомлення про збереження повідомлення незалежно від кількості пам’яті пристрою. Такий тип повідомлення має на увазі, що повідомлення досягло адресата.

Тип повідомлення

Silent message (SMS0). Тип смс-повідомлення без вмісту. Таке смс надходить без попередження та не відображається на екрані пристрою.

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 etc. Іноді оператори не пропускають трафік, якщо ім’я не зареєстроване в мережі. Однак це скоріше особливості оператора.

Стадії відправлення

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 може набувати кількох значень:
NULL. Помилка підключення SMPP до SMS-центру.
ENROUTE. Повідомлення зараз маршрутизується.
DELIVRD. Повідомлення успішно доставлено.
REJECTD. Повідомлення відкинуто SMS-центром.
EXPIRED. Повідомлення видалено з черги відправки після закінчення TTL (час життя повідомлення).
UNDELIV. Інші випадки недоставки.
UNKNOWN. Не отримано відповіді про відправлення.
DELETED. Повідомлення видалено.
ACCEPTD. Повідомлення прийняте та прочитане.
QUERY REQUEST FAILED. Сервер SMS-центру не зміг знайти ваше повідомлення.

Помилки передачі

Іноді повідомлення не надсилаються. Внаслідок чого виникають помилки. Помилки повертаються в PDUs_sms_resp. Всі помилки можна розділити на тимчасові (Temporary) і постійні (Permanent).

Як приклад, до тимчасових можна віднести absent_subscriber — абонент недоступний або не в мережі, а до постійних абонент не існує. Залежно від помилок, що виникають, формується політика перенаправлення цих повідомлень.

Наприклад, якщо абонент був зайнятий розмовою та отримав помилку MT handset is busy, повідомлення можна надіслати повторно через кілька хвилин, однак, якщо в абонента заблокований сервіс прийому повідомлень, повторне перенаправлення не матиме сенсу. Список помилок ви зможете знайти на сторінках SMSC, наприклад, як ця .

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному2
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Я читав, що колись XMPP мав шанси стати таким же поширеним протоколом, як поштовий (email), але великі корпораціі перейшли на закриті протоколи. Як ви оцінюєте шанси XMPP на майбутнє?

В мене немає досвіду з xmpp, але з того що бачу xmpp використовують там де необхідна приватність. Корпораціям приватність користувачів не потрібна.

Непогано ще б знати на скільки перспективними є СМС, тобто чи не є цей спосіб передачі даних атавізмом.

На мою думку, поки sms ефективно виконують свої функції ні. Проте ідейним наступником SMS є протокол Rich Communication Services або RCS

О, а які є новини стосовно RCS? Бо щось дуже повільно впроваджують

Я знаю що в SMS центрі де я раніше працював ним цікавляться, тестують і вивчають специфікацію, але далі цього поки не пішло

Це означає, що кожен бенкет/хаб сервер рівноправний

Мабуть в оригіналі було «пир» — українською так і залиште «пір», а то якась бавовна виходить ) І я так розумію — все це відбувається всередині мережі, кінцевий користувач усі ці деталі не побачить (навіть якщо буде відправляти SMS із якогось GSM-модему із низькорівневим доступом)?

Дякую за виправлення. Ні користувач цього не може побачити, це відбувається на рівні SMS центру

Підписатись на коментарі