SMPP

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск

SMPP — (Short Message Peer-to-Peer) короткие сообщения одноранговой Сети. Является открытым стандартом в телекоммуникационной отрасли, который разработан специально, чтобы обеспечить гибкий интерфейс для передачи коротких сообщений между внешними сущностями (устройства, приложения) коротких сообщений (ESME), маршрутизаторами и центров сообщений (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.

Несовместимость submit_sm_resp между версиями SMPP[править | править вики-текст]

Примечания[править | править вики-текст]

Другие протоколы SMS[править | править вики-текст]

Ссылки[править | править вики-текст]