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
Все числовые поля в 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
Ссылки
Данная страница на сайте WikiSort.ru содержит текст со страницы сайта "Википедия".
Если Вы хотите её отредактировать, то можете сделать это на странице редактирования в Википедии.
Если сделанные Вами правки не будут кем-нибудь удалены, то через несколько дней они появятся на сайте WikiSort.ru .