SMPP

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

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

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

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

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

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

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

Формат PDU

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

SMPP PDU
PDU Header (обязательный)				PDU Body (опционально)
Command length	Command Id	Command Status	Sequence Id	PDU Body
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 пользуются большим обратным порядком, а это значит, что первый октет является старшим байтом (MSB).

Примеры

Это пример двоичного кодирования 60 октетов submit_sm PDU. Данные представлены в значениях октетных Hex как единого дампа и затем заголовка и тела разбивкой этого PDU.

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

Опять же, прочитав определение submit_sm PDU из спецификации сделает все это яснее.

Заголовок 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). SMPP 3.3 data_coding точно скопированны значения 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 — see GSM 03.38
208—223	GSM MWI control — see GSM 03.38
224—239	Зарезервирован
240—255	GSM message class control — see 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 могут отличаться для различных СМСЦ — это может быть ISO-8859-1, ASCII, GSM 7-битный алфавит,UTF-8 или любая другая настроенная для каждого ESME. При использовании data_coding = 0, обе стороны (ESME и SMSC) должны быть уверены, что они считают это указателем к одной и той же кодировке. В противном же случае, лучше не использовать data_coding = 0. Это может затруднить использование GSM 7-битного алфавита, так как некоторые СМСЦ требует 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 bit default alphabet
• Нет стандартного значения data_coding=0
• Нечеткая поддержка кодировки Shift-JIS
• Несовместимость submit_sm_resp между версиями SMPP
• Особенности ID сообщения при получении отчета о доставке, при использовании SMPP 3.3

Нет data_coding для GSM 7 bit default alphabet

В SMPP 3.3 все значения data_coding трактуются согласно GSM 03.38, но начиная с SMPP 3.4 отсутствует значение data_coding для GSM 7 bit default alphabet

Нет стандартного значения 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.

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

• SNPP RFC1861
• EMI/UCP