SMPP

Эта статья находится на начальном уровне проработки, в одной из её версий выборочно используется текст из источника, распространяемого под свободной лицензией
Материал из энциклопедии Руниверсалис

SMPP (англ. Short Message Peer-to-Peer) — одноранговая передача коротких сообщений. Является открытым протоколом в телекоммуникационной отрасли, который разработан специально, чтобы обеспечить гибкий интерфейс для обмена SMS-сообщениями между прикладными SMS-платформами (ESME), маршрутизаторами (RE) и центрами службы коротких сообщений (SMSC).[1]

SMPP часто используют третьи лица, такие как поставщики дополнительных услуг, новостные агентства, для передачи SMS сообщений — часто массово. По данному протоколу можно передавать SMS, EMS, уведомления голосовой почты, сотовое радиовещание, WAP-сообщения, USSD сообщения и пр. Из-за своей универсальности, заключающейся в поддержке сетей GSM, UMTS, IS-95 (CDMA), CDMA2000, ANSI-136 (TDMA) и подобных, SMPP является наиболее широко используемым протоколом для обмена короткими сообщениями за пределами сетей ОКС7 (SS7).

В ноябре 1995 г. ETSI включил протокол SMPP в технический отчет TR 03.39.[2]

Процесс работы

SMPP использует модель работы клиент-сервер. Центр сообщений (SMSC), как правило, выступает в качестве сервера, ожидая подключения от клиента — ESME. Когда SMPP используется для SMS пиринга, отправляющий MC обычно выступает в качестве клиента.

Протокол основан на обмене пар запрос-ответ PDU (блоков данных протокола или пакетах) на 4м уровне OSI (TCP сессии или X25 SVC3).[3] Общеизвестный порт, назначенный IANA для SMPP при работе над TCP является 2775, но часто используются произвольные номера портов.

Перед обменом сообщений, должна быть отправлена и подтверждена команда привязки. Команда привязки определяет, в каком направлении можно будет отправлять сообщения; bind_transmitter позволяет клиенту только отправлять сообщения на сервер, bind_receiver означает, что клиент будет только получать сообщения, и bind_transceiver (введен в SMPP 3.4[4]) позволяет передавать сообщения в обоих направлениях. При отправке команды привязки, ESME должен себя идентифицировать с помощью параметров system_id, system_type и password; address_range предназначен для указания адреса ESME, но обычно, передается пустым. Так же, в команде привязки есть interface_version, в котором указывают версию протокола, который будет использоваться во время сессии.

Обмен сообщениями может быть синхронным, где каждый узел ожидает ответа на каждый PDU или асинхронный, где множественные запросы могут быть отправлены без ожидания ответа; количество неподтвержденных запросов называется «окно»; для наилучшего взаимодействия, обе стороны должны иметь идентичные настройки размера окна.

Формат PDU

В SMPP блоки PDU кодируются в двоичном формате для наибольшей эффективности. Они начинаются с заголовка PDU, за которым может следовать тело PDU.

SMPP PDU
Заголовок PDU (обязательный) Тело PDU (опционально)
Command

length

Command

Id

Command

Status

Sequence

Id

Тело PDU
4 octets Length = (Command Length value — 4) octets

PDU header

Каждый PDU начинается с заголовка. Заголовок состоит из 4-х полей, длина каждого из которых равна 4 октетам.

command_length
Общая длина PDU в октетах (включая саму команду длины поля); минимальное значение 16, так как каждый PDU должен содержать заголовок длиной в 16 октетов
command_id
Указывает операцию SMPP (или команды)
command_status
Всегда значение 0 в запросах; в ответе несет в себе информацию о результате операции
sequence_number
Используется для корреляции запросов и ответов в рамках сессии SMPP; обеспечивает асинхронную связь (с помощью метода «скользящего окна»)

Все числовые поля в SMPP отображаются в порядке от старшего к младшему (англ. big endian), то есть первый октет является старшим байтом (MSB).

Примеры

Это пример 60-октетного PDU submit_sm. Данные отображаются в шестнадцатеричном формате. Заголовок и тело PDU представлены по отдельности и разбиты по полям PDU.

Рекомендуется сопоставить данный пример с определением PDU submit_sm согласно спецификации SMPP, чтобы понять, как кодировка каждого поля соответствует спецификации.

Значения для каждого поля PDU показаны в десятичном виде в скобках и шестнадцатеричном виде после них. Если поле занимает более одного октета, то все соответствующие шестнадцатеричные октеты представлены одной строкой.

Опять же, для большей ясности следует прочитать определение submit_sm в спецификации SMPP.

Заголовок PDU

'command_length', (60) ... 00 00 00 3C
'command_id',      (4) ... 00 00 00 04
'command_status',  (0) ... 00 00 00 00
'sequence_number', (5) ... 00 00 00 05

Содержимое PDU

'service_type',                 () ... 00
'source_addr_ton',             (2) ... 02
'source_addr_npi',             (8) ... 08
'source_addr',               (555) ... 35 35 35 00
'dest_addr_ton',               (1) ... 01
'dest_addr_npi',               (1) ... 01
'dest_addr',           (555555555) ... 35 35 35 35 35 35 35 35 35 00
'esm_class',                   (0) ... 00
'protocol_id',                 (0) ... 00
'priority_flag',               (0) ... 00
'schedule_delivery_time',      (0) ... 00
'validity_period',             (0) ... 00
'registered_delivery',         (0) ... 00
'replace_if_present_flag',     (0) ... 00
'data_coding',                 (3) ... 03
'sm_default_msg_id',           (0) ... 00
'sm_length',                  (15) ... 0F
'short_message', (Hello Wikipedia) ... 48 65 6C 6C 6F 20 77 69 6B 69 70 65 64 69 61'

Обратите внимание, что формат текста в поле short_message должен соответствовать значению поля data_coding. Когда data_coding имеет сначение 8 (UCS2), текст должен быть в формате UCS-2BE (или его расширения, UTF-16BE). Когда data_coding указывает на 7-битную кодировку, каждый септет хранится в отдельном октете в поле short_message (с наиболее старшим битом, установленным в 0). Значения data_coding в версии SMPP 3.3 точно дублируют значения TP-DCS из стандарта GSM 03.38, что делает данную версию пригодной только для GSM 7-битного алфавита, UCS2 и бинарных сообщений. В версии SMPP 3.4 введены новые значения data_coding:

data_coding Значение
0 SMSC Default Alphabet (SMPP 3.4) / MC Specific (SMPP 5.0)
1 IA5 (CCITT T.50)/ASCII (ANSI X3.4)
2 Octet unspecified (8-bit binary)
3 Latin 1 (ISO-8859-1)
4 Octet unspecified (8-bit binary)
5 JIS (X 0208-1990)
6 Cyrillic (ISO-8859-5)
7 Latin/Hebrew (ISO-8859-8)
8 UCS2 (ISO/IEC-10646)
9 Pictogram Encoding
10 ISO-2022-JP (Music Codes)
11 Зарезервирован
12 Зарезервирован
13 Extended Kanji JIS (X 0212-1990)
14 KS C 5601
15-191 Зарезервирован
192—207 GSM MWI control — см. GSM 03.38
208—223 GSM MWI control — см. GSM 03.38
224—239 Зарезервирован
240—255 GSM message class control — см. GSM 03.38

Значения 4 и 8 для data_coding совпадают для всех версий SMPP. Другие значения в диапазоне 1-15 зарезервированы в версии SMPP 3.3. К сожалению, в отличие от SMPP 3.3, где значение data_coding = 0 однозначно определяло GSM 7-битный алфавит, для SMPP 3.4 и выше GSM 7-битный алфавит отсутствует в этом списке, и data_coding = 0 могут отличаться для различных SMSC — это может быть ISO-8859-1, ASCII, GSM 7-битный алфавит, UTF-8 или любая другая кодировка по умолчанию. При использовании data_coding = 0, обе стороны (ESME и SMSC) должны быть уверены, что они считают это указателем к одной и той же кодировке. В противном же случае, лучше не использовать data_coding = 0. Это может затруднить использование GSM 7-битного алфавита, так как некоторые SMSC требует data_coding = 0, другие, например, data_coding = 241.

Реализации

SMPP был реализован на Java в проекте jSMPP. Он используется в Apache Camel и различных других популярных бесплатных программных проектах для SMS-сообщений. Альтернативная реализация Java nmote-smpp. Проект python-SMPP предоставляет SMPP для пользователей Python. Проект PHP-SMPP предоставляет SMPP для пользователей PHP.

Особенности

Несмотря на широкое распространение, SMPP имеет ряд проблемных особенностей:

  • Отсутствие значения data_coding для GSM 7-битного алфавита
  • Отсутствие стандартизации для значения data_coding=0
  • Нечеткая поддержка кодировки Shift-JIS
  • Несовместимость submit_sm_resp между версиями SMPP
  • Особенности ID сообщения при получении отчета о доставке в SMPP 3.3

Отсутствие значения data_coding для GSM 7-битного алфавита

В SMPP 3.3 все значения data_coding трактуются согласно GSM 03.38, но начиная с SMPP 3.4 отсутствует значение data_coding для GSM 7-битного алфавита.

Отсутствие стандартизации для значения data_coding=0

Согласно SMPP 3.4 и 5.0 data_coding=0 означает ″SMSC Default Alphabet″. Какая кодировка это на самом деле, зависит от типа SMSC и его конфигурации.

Нечеткая поддержка кодировки Shift-JIS

Одна из кодировок в стандарте CDMA C.R1001 — Shift-JIS, используется для японского языка. SMPP 3.4 и 5.0 определяют три кодировки для японского языка (JIS, ISO-2022-JP и Расширенная кандзи JIS), но ни одна из них не идентична CDMA MSG_ENCODING 00101. Предполагается, что для передачи сообщений Shift-JIS в SMPP следует использовать кодировку пиктограммы (data_coding=9).

Несовместимость submit_sm_resp между версиями SMPP

Дополнительные материалы для этого раздела см.тут: Short_Message_Peer-to-Peer#Incompatibility_of_submit_sm_resp_between_SMPP_versions (англ.).

Особенности ID сообщения при получении отчета о доставке в SMPP 3.3

Единственный способ подтверждения доставки сообщения в SMPP 3.3 — через текстовое поле short_message в PDU deliver_sm. Тем не менее, формат этого текста описан в Приложении «B» в спецификации SMPP 3.4, хотя SMPP 3.4 может (и должен) использовать для этой цели поля TLV receipted_message_id и message_state. В SMPP 3.3 указано, что идентификатор сообщения представляет собой C-строку длиной до 8 шестнадцатеричных символов (плюс завершающий '\0'). Зато в SMPP 3.4 указано, что данный идентификатор в формате C-строки может содержать до 10 десятичных символов. Это разделяет реализации SMPP на 2 группы:

  • Реализации, использующие десятичное представление идентификатора сообщения в PDU подтверждения доставки и шестнадцатеричное представление в полях message_id и receipted_message_id.
  • Реализации, использующие одно и то же шестнадцатеричное число (или даже одну и ту же произвольную строку) как в параметре message_id, так и в PDU подтверждения доставки.

Однако в спецификации SMPP 3.4 указано, что формат PDU подтверждения доставки зависит от поставщика SMSC. Поэтому формат, описанный в спецификации, является лишь одним из возможных вариантов. Как отмечалось выше, при использовании SMPP 3.4 для подтверждения доставки сообщения следует использовать TLV-значения receipted_message_id и message_state.

Примечания

  1. ↑ «Short Message Peer-to-Peer Protocol Specification v5.0» Архивная копия от 11 апреля 2021 на Wayback Machine, SMS Forum, 19 Февраля 2003
  2. ↑ Friedhelm Hillebrand. Short Message Service (SMS): The Creation of Personal Global Text Messaging (англ.). — Wiley, 2010. — P. 112. — 194 p. — ISBN 978-0-470-68865-6.
  3. ↑ Croft, N. On forensics: A silent SMS attack (англ.) // IEEE : журнал. — 2012. — ISSN 2330-9881. — doi:10.1109/ISSA.2012.6320454.
  4. ↑ «Short Message Peer to Peer Protocol Specification v3.4» Архивная копия от 11 апреля 2021 на Wayback Machine, SMPP Developers Forum, 12 Октября 1999

Другие протоколы SMS

Источник — https://xn--h1ajim.xn--p1ai/index.php?title=SMPP&oldid=10386836