SMPP

Материал из Википедии — свободной энциклопедии
Текущая версия страницы покане проверяласьопытными участниками и может значительно отличаться отверсии, проверенной 24 января 2020 года;проверки требует21 правка.
Перейти к навигации Перейти к поиску

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-октетного PDUsubmit_sm.Данные отображаются в шестнадцатеричном формате. Заголовок и тело PDU представлены по отдельности и разбиты по полям PDU.

Рекомендуется сопоставить данный пример с определением PDUsubmit_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-сообщений. Альтернативная реализация Javanmote-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.0data_coding=0 означает ″SMSC Default Alphabet″. Какая кодировка это на самом деле, зависит от типаSMSCи его конфигурации.

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

[править|править код]

Одна из кодировок в стандартеCDMAC.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в PDUdeliver_sm.Тем не менее, формат этого текста описан в Приложении «B» в спецификации SMPP 3.4, хотя SMPP 3.4 может (и должен) использовать для этой цели поля TLVreceipted_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.Архивировано4 июня 2021 года.
  3. ↑Croft, N.On forensics: A silent SMS attack(англ.)//IEEE:журнал. — 2012. —ISSN2330-9881.—doi:10.1109/ISSA.2012.6320454.Архивировано9 июня 2021 года.
  4. ↑«Short Message Peer to Peer Protocol Specification v3.4»Архивная копияот 11 апреля 2021 наWayback Machine,SMPP Developers Forum, 12 Октября 1999

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

[править|править код]
Источник —https://ru.wikipedia.org/w/index.php?title=SMPP&oldid=131031393