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
правитьЭтот раздел слишком короткий. |
Особенности 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.
Примечания
править- ↑ «Short Message Peer-to-Peer Protocol Specification v5.0» Архивная копия от 11 апреля 2021 на Wayback Machine, SMS Forum, 19 Февраля 2003
- ↑ 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 года.
- ↑ Croft, N. On forensics: A silent SMS attack (англ.) // IEEE : журнал. — 2012. — ISSN 2330-9881. — doi:10.1109/ISSA.2012.6320454. Архивировано 9 июня 2021 года.
- ↑ «Short Message Peer to Peer Protocol Specification v3.4» Архивная копия от 11 апреля 2021 на Wayback Machine, SMPP Developers Forum, 12 Октября 1999