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 или асинхронный, где множественные запросы могут быть отправлены без ожидания ответа; количество неподтвержденных запросов называется «окно»; для наилучшего взаимодействия, обе стороны должны иметь идентичные настройки размера окна.

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

Каждый 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.

'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

'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:

Значения 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

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

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

Одна из кодировок в стандарте 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).

Этот раздел слишком короткий. Пожалуйста, улучшите и дополните его.

Единственный способ подтверждения доставки сообщения в 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.

• SNPP
• EMI/UCP