SMPP: различия между версиями

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
Интерактивная навигация по истории
[отпатрулированная версия][непроверенная версия]
← Предыдущая правка
Содержимое удалено Содержимое добавлено
ВизуальныйВики-текст
орфогр: корректировка склонения для "центров сообщений"; доп: аббревиатура для маршрутизаторов в контексте сущности коротких сообщений (RE = routing entry)
→Примеры: Корректировка в части T.50
 
(не показана 21 промежуточная версия 3 участников)
Строка 1: Строка 1:
'''SMPP — (Short Message Peer-to-Peer) <span>короткие сообщения одноранговой Сети.</span>'''
'''SMPP''' ({{lang-en|Short Message Peer-to-Peer}}) — одноранговая передача коротких сообщений.
Является открытым стандартом в телекоммуникационной отрасли, который разработан специально, чтобы обеспечить гибкий интерфейс для передачи коротких сообщений между внешними сущностями (устройства, приложения) коротких сообщений ([[ESME]]), маршрутизаторами (RE) и центрами сообщений ([[SMSC]]).
Является открытым протоколом в телекоммуникационной отрасли, который разработан специально, чтобы обеспечить гибкий интерфейс для обмена SMS-сообщениями между прикладными SMS-платформами ([[ESME]]), маршрутизаторами (RE) и центрами службы коротких сообщений ([[SMSC]]).<ref name="smpp50">[http://docs.nimta.com/smppv50.pdf «Short Message Peer-to-Peer Protocol Specification v5.0»] {{Wayback|url=http://docs.nimta.com/smppv50.pdf |date=20210411210000 }}, SMS Forum, 19 Февраля 2003</ref>


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

В ноябре 1995 г. [[ETSI]] включил протокол SMPP в технический отчет TR 03.39.<ref>{{книга|ссылка=https://books.google.ru/books?id=YPgfNaoYHUsC|заглавие=Short Message Service (SMS): The Creation of Personal Global Text Messaging|язык=en|страницы=112|страниц=194|автор=Friedhelm Hillebrand|издательство=[[John Wiley & Sons|Wiley]]|год=2010|isbn=978-0-470-68865-6|archivedate=2021-06-04|archiveurl=https://web.archive.org/web/20210604163933/https://books.google.ru/books?id=YPgfNaoYHUsC}}</ref>


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


Протокол основан на парах запрос-ответ [[:en:Protocol_Data_Unit|PDU]] (блоков данных протокола или пакетах) обмениваются через [[Сетевая модель OSI|OSI]] слой 4 ([[TCP]] сессии или X25 SVC3) соединений. Общеизвестный порт, назначенный [[IANA]] для SMPP при работе над [[TCP]] является 2775, но часто используются произвольные номера портов.
Протокол основан на обмене пар запрос-ответ [[:en:Protocol_Data_Unit|PDU]] (блоков данных протокола или пакетах) на 4м уровне [[Сетевая модель OSI|OSI]] ([[TCP]] сессии или X25 SVC3).<ref>{{статья
|автор=Croft, N.
|заглавие=On forensics: A silent SMS attack
|язык=en
|ссылка=https://ieeexplore.ieee.org/abstract/document/6320454
|издание=[[IEEE]]
|тип=журнал
|год=2012
|issn=2330-9881
|doi=10.1109/ISSA.2012.6320454
|archivedate=2021-06-09
|archiveurl=https://web.archive.org/web/20210609234826/https://ieeexplore.ieee.org/abstract/document/6320454
}}</ref> Общеизвестный порт, назначенный [[IANA]] для SMPP при работе над [[TCP]] является 2775, но часто используются произвольные номера портов.


Перед обменом сообщений, должна быть отправлена и подтверждена команда привязки. Команда привязки определяет, в каком направлении можно будет отправлять сообщения; bind_transmitter позволяет клиенту только отправлять сообщения на сервер, bind_receiver означает, что клиент будет только получать сообщения, и bind_transceiver (введен в SMPP 3.4) позволяет передавать сообщения в обоих направлениях.
Перед обменом сообщений, должна быть отправлена и подтверждена команда привязки. Команда привязки определяет, в каком направлении можно будет отправлять сообщения; bind_transmitter позволяет клиенту только отправлять сообщения на сервер, bind_receiver означает, что клиент будет только получать сообщения, и bind_transceiver (введен в SMPP 3.4<ref name="smpp34">[http://docs.nimta.com/SMPP_v3_4_Issue1_2.pdf «Short Message Peer to Peer Protocol Specification v3.4»] {{Wayback|url=http://docs.nimta.com/SMPP_v3_4_Issue1_2.pdf |date=20210411210011 }}, SMPP Developers Forum, 12 Октября 1999</ref>) позволяет передавать сообщения в обоих направлениях.
При отправке команды привязки, [[ESME]] должен себя идентифицировать с помощью параметров system_id, system_type и password; address_range предназначен для указания адреса ESME, но обычно, передается пустым. Так же, в команде связки есть interface_version, в котором указывают версию протокола, который будет использоваться во время сессии.
При отправке команды привязки, [[ESME]] должен себя идентифицировать с помощью параметров system_id, system_type и password; address_range предназначен для указания адреса ESME, но обычно, передается пустым. Так же, в команде привязки есть interface_version, в котором указывают версию протокола, который будет использоваться во время сессии.


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


== Формат PDU ==
== Формат PDU ==
В SMPP блоки PDU являются бинарными и кодируются для эффективности. Они начинаются с заголовка, который соответствуют телу:
В SMPP блоки PDU кодируются в двоичном формате для наибольшей эффективности. Они начинаются с заголовка PDU, за которым может следовать тело PDU.
{| class="wikitable" style="text-align:center"
{| class="wikitable" style="text-align:center"


| colspan="5" style="background: black; color: white; font-weight: bold" | SMPP PDU
| colspan="5" style="background: black; color: white; font-weight: bold" | SMPP PDU
|-
|-
| colspan="4" | PDU Header (обязательный)
| colspan="4" | Заголовок PDU (обязательный)
| PDU Body (опционально)
| Тело PDU (опционально)
|-
|-
| Command <br>
| Command <br>
Строка 33: Строка 47:
| Sequence <br>
| Sequence <br>
Id
Id
| Тело PDU
| PDU Body
|-
|-
| 4 octets
| 4 octets
Строка 40: Строка 54:


=== PDU header ===
=== PDU header ===
Каждый PDU начинается с заголовка. Заголовок состоит из 4-х полей, длина каждого из которых равна 4 октетам:
Каждый PDU начинается с заголовка. Заголовок состоит из 4-х полей, длина каждого из которых равна 4 октетам.
⚫
;<tt>command_length</tt>: Общая длина PDU в октетах (включая саму команду длины поля); минимальное значение 16, так как каждый PDU должен содержать заголовок длиной в 16 октетов
'''command_length '''<br>
⚫
;<tt>command_id</tt>: Указывает операцию SMPP (или команды)
⚫
<div>Общая длина PDU в октетах (включая саму команду длины поля); должна составлять не менее 16 октетов, так как каждый PDU должен содержать заголовок 16 октета'''<br>
⚫
;<tt>command_status</tt>: Всегда значение 0 в запросах; в ответе несет в себе информацию о результате операции
'''</div><div>'''command_id '''<br>
⚫
;<tt>sequence_number</tt>: Используется для корреляции запросов и ответов в рамках сессии SMPP; обеспечивает асинхронную связь (с помощью метода «скользящего окна»)
⚫
</div><div>Указывает операцию SMPP (или команды)'''<br>

'''</div><div>'''command_status '''<br>
⚫
Все числовые поля в SMPP отображаются в порядке от старшего к младшему ({{lang-en|big endian}}), то есть первый октет является старшим [[Порядок байтов|байтом]] (MSB).
⚫
</div><div>Всегда значение 0 в запросах; в ответе он несет в себе информацию о результате операции'''<br>
'''</div><div>'''sequence_number '''<br>
⚫
</div><div> Используется для корреляции запросов и ответов в рамках сессии SMPP; обеспечивает асинхронную связь (с помощью метода «скользящего окна»)'''<br>
'''</div>
⚫
Все числовые поля в SMPP пользуются большим обратным порядком, а это значит, что первый октет является старшим [[Порядок байтов|байтом]] (MSB).


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


Рекомендуется сопоставить данный пример с определением PDU ''submit_sm'' согласно спецификации SMPP, чтобы понять, как кодировка каждого поля соответствует спецификации.
Объём значений показан в десятичном виде в скобках и значениями Hex после них. Если вы видите один или несколько шестнадцатеричных октета, то это потому, что данный размер поля использует 1 или более октетов кодирования.


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

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


=== Заголовок PDU ===
=== Заголовок PDU ===
'command_length', (60) ... 00 00 00 3C
'command_length', (60) ... 00 00 00 3C
'command_id', (4) ... 00 00 00 04
'command_id', (4) ... 00 00 00 04
'command_status', (0) ... 00 00 00 00
'command_status', (0) ... 00 00 00 00
'sequence_number', (5) ... 00 00 00 05
'sequence_number', (5) ... 00 00 00 05


=== Содержимое PDU ===
=== Содержимое PDU ===
'service_type', () ... 00
'service_type', () ... 00
'source_addr_ton', (2) ... 02
'source_addr_ton', (2) ... 02
'source_addr_[[Телефонный план нумерации|npi]]', (8) ... 08
'source_addr_[[Телефонный план нумерации|npi]]', (8) ... 08
'source_addr', (555) ... 35 35 35 00
'source_addr', (555) ... 35 35 35 00
'dest_addr_ton', (1) ... 01
'dest_addr_ton', (1) ... 01
'dest_addr_[[Телефонный план нумерации|npi]]', (1) ... 01
'dest_addr_[[Телефонный план нумерации|npi]]', (1) ... 01
'dest_addr', (555555555) ... 35 35 35 35 35 35 35 35 35 00
'dest_addr', (555555555) ... 35 35 35 35 35 35 35 35 35 00
'esm_class', (0) ... 00
'esm_class', (0) ... 00
'protocol_id', (0) ... 00
'protocol_id', (0) ... 00
'priority_flag', (0) ... 00
'priority_flag', (0) ... 00
'schedule_delivery_time', (0) ... 00
'schedule_delivery_time', (0) ... 00
'validity_period', (0) ... 00
'validity_period', (0) ... 00
'registered_delivery', (0) ... 00
'registered_delivery', (0) ... 00
'replace_if_present_flag', (0) ... 00
'replace_if_present_flag', (0) ... 00
'data_coding', (3) ... 03
'data_coding', (3) ... 03
'sm_default_msg_id', (0) ... 00
'sm_default_msg_id', (0) ... 00
'sm_length', (15) ... 0F
'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', (Hello Wikipedia) ... 48 65 6C 6C 6F 20 77 69 6B 69 70 65 64 69 61'

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

{| class="wikitable"
{| class="wikitable"
! data_coding
! data_coding
Строка 93: Строка 107:
|-
|-
| style="text-align:center" | 1
| style="text-align:center" | 1
| IA5 (CCITT T.50)/[[ASCII]] (ANSI X3.4)
| {{iw|Международный справочный алфавит|IRA|en|International Reference Alphabet}} (ITU-T T.50)/[[ASCII]] (ANSI X3.4)
|-
|-
| style="text-align:center" | 2
| style="text-align:center" | 2
Строка 138: Строка 152:
|-
|-
| style="text-align:center" | 192—207
| style="text-align:center" | 192—207
| GSM MWI control — see GSM 03.38
| GSM MWI control — см. GSM 03.38
|-
|-
| style="text-align:center" | 208—223
| style="text-align:center" | 208—223
| GSM MWI control — see GSM 03.38
| GSM MWI control — см. GSM 03.38
|-
|-
| style="text-align:center" | 224—239
| style="text-align:center" | 224—239
Строка 147: Строка 161:
|-
|-
| style="text-align:center" | 240—255
| style="text-align:center" | 240—255
| GSM message class control — see GSM 03.38
| GSM message class control — см. GSM 03.38
|}
|}

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


== Реализации ==
== Реализации ==
Строка 156: Строка 171:
== Особенности ==
== Особенности ==
Несмотря на широкое распространение, SMPP имеет ряд проблемных особенностей:
Несмотря на широкое распространение, SMPP имеет ряд проблемных особенностей:
* Нет data_coding для GSM 7 bit default alphabet
* Отсутствие значения ''data_coding'' для GSM 7-битного алфавита
* Нет стандартного значения data_coding=0
* Отсутствие стандартизации для значения ''data_coding''=0
* Нечеткая поддержка кодировки Shift-JIS
* Нечеткая поддержка кодировки Shift-JIS
* Несовместимость submit_sm_resp между версиями SMPP
* Несовместимость ''submit_sm_resp'' между версиями SMPP
* Особенности ID сообщения при получении отчета о доставке, при использовании SMPP 3.3
* Особенности ID сообщения при получении отчета о доставке в SMPP 3.3


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


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


=== Нечеткая поддержка кодировки Shift-JIS ===
=== Нечеткая поддержка кодировки Shift-JIS ===
Одна из кодировок в [[CDMA]] стандартной [[C.R1001]] является [[Shift JIS|Shift-JIS]] используется для [[Японский язык|японского языка]]. SMPP 3.4 и 5.0 определяет три кодировки для Японии (JIS, ISO-2022-JP и Расширенная кандзи [[JIS]]), но ни один из них не совпадает с CDMA MSG_ENCODING 00101.
Одна из кодировок в стандарте [[CDMA]] C.R1001 — [[Shift JIS|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 ===
=== Несовместимость submit_sm_resp между версиями SMPP ===
{{перевести раздел|en|Short_Message_Peer-to-Peer#Incompatibility_of_submit_sm_resp_between_SMPP_versions}}
{{перевести раздел|en|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''.


== Примечания ==
== Примечания ==
Строка 179: Строка 203:


== Другие протоколы SMS ==
== Другие протоколы SMS ==
* [[SNPP]]
* [[SNPP]] [http://www.faqs.org/rfcs/rfc1861.html RFC1861]
* [[EMI/UCP]]
* [[EMI/UCP]]

== Ссылки ==


{{IPstack|nocat=1}}
{{IPstack|nocat=1}}

Текущая версия от 18:52, 16 ноября 2024

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 IRA[англ.] (ITU-T 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. Архивировано 4 июня 2021 года.
  3. ↑ Croft, N. On forensics: A silent SMS attack (англ.) // IEEE : журнал. — 2012. — ISSN 2330-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/ruwiki/w/index.php?title=SMPP&oldid=141559507