Введение

Протокол передачи коротких сообщений "Peer to Peer" (SMPP) в телекоммуникационной отрасли — это открытый отраслевой стандарт, предназначенный для обеспечения гибкого интерфейса обмена данными для передачи данных коротких сообщений между внешними сущностями коротких сообщений (ESME), маршрутизирующими сущностями (RE) и SMSC. SMPP часто используется для предоставления третьим сторонам (например, поставщикам услуг с добавленной стоимостью, таким как новостные организации) возможности отправлять сообщения, часто массово, но также может применяться для SMS-пиринга. SMPP способен передавать короткие сообщения, включая EMS, уведомления о голосовой почте, широковещательные сообщения, WAP-сообщения, включая WAP Push-сообщения (используемые для доставки уведомлений MMS), USSD-сообщения и другие. Благодаря своей универсальности и поддержке SMS-протоколов, отличных от GSM, таких как UMTS, IS 95 (CDMA), CDMA2000, ANSI 136 (TDMA) и iDEN, SMPP является наиболее распространенным протоколом для обмена короткими сообщениями вне сетей SS7.

История

SMPP (Short Message Peer to Peer) был первоначально разработан компанией Aldiscon, небольшой ирландской фирмой, которая позже была приобретена Logica (с 2016 года, после ряда преобразований, Mavenir). Протокол был изначально создан разработчиком Ианом Дж. Чемберсом для тестирования функциональности SMSC без использования SS7-оборудования для отправки сообщений. В 1995 году ETSI включил протокол SMPP в технический отчет TR 03.39. В 1999 году Logica официально передала SMPP Форуму разработчиков SMPP, впоследствии переименованному в SMS Forum. SMS Forum прекратил свою деятельность в 2007 году, о чем было объявлено следующим образом: "SMS Forum, некоммерческая организация, целью которой является разработка, развитие и продвижение SMS (службы коротких сообщений) на благо мировой индустрии беспроводной связи, прекратит свою деятельность до 27 июля 2007 года". В соответствии с первоначальными условиями передачи, права на SMPP вернулись к Mavenir.

Операция

SMPP использует клиент-серверную модель работы, несмотря на "peer to peer" в названии. Центр коротких сообщений (SMSC) обычно выступает в роли сервера, ожидая установления соединений от ESME. При использовании SMPP для SMS-пиринга, отправляющий MC обычно действует как клиент. Протокол основан на парах запроса/ответа PDU (протокольных единиц данных или пакетов), обмениваемых по соединениям OSI 4-го уровня (TCP-сессия или X.25 SVC3). Порт 2775, зарезервированный IANA для SMPP при работе через TCP, является общеизвестным, однако в средах обмена сообщениями часто используются различные произвольные номера портов. Перед началом обмена сообщениями необходимо отправить команду bind и получить подтверждение ее выполнения. Команда bind определяет направление, в котором возможна отправка сообщений: bind transmitter позволяет клиенту отправлять сообщения только на сервер, bind receiver означает, что клиент будет только принимать сообщения, а bind transceiver (представленный в SMPP 3.4) обеспечивает передачу сообщений в обоих направлениях. В команде bind ESME идентифицирует себя, используя идентификатор системы, тип системы и пароль; поле диапазона адресов, предназначенное для хранения адреса ESME, обычно остается незаполненным. Команда bind содержит параметр версии интерфейса для указания используемой версии протокола SMPP. Обмен сообщениями может быть синхронным, когда каждая сторона ожидает ответа на каждое отправленное PDU, или асинхронным, когда несколько запросов отправляются без ожидания подтверждения и подтверждаются другой стороной в произвольном порядке; количество неподтвержденных запросов называется окном; для достижения оптимальной производительности обе стороны должны быть настроены с одинаковым размером окна.

Версии

Стандарт SMPP развивался со временем. Наиболее часто используемые версии SMPP:

SMPP 3.3 – старейшая используемая версия (несмотря на свои ограничения, она до сих пор широко применяется); поддерживает только GSM. Генерирует немедленный ответ на каждое отправленное сообщение. SMPP 3.4 добавляет необязательные параметры в формате tag-length-value (TLV), поддержку SMS-технологий, отличных от GSM, и поддержку трансивера (одно соединение, способное отправлять и принимать сообщения). Обмен PDU запросов и ответов SMPP между ESME-передатчиком и SMSC может осуществляться синхронно или асинхронно. SMPP 5.0 – последняя версия SMPP; добавляет поддержку широковещательной рассылки (cell broadcasting) и интеллектуального управления потоком. По состоянию на 2023 год она не получила широкого распространения. Используемая версия передается в параметре версии интерфейса команды bind.

Пример

Это пример двоичного кодирования PDU сообщения типа submit sm размером 60 октетов. Данные представлены в виде шестнадцатеричных значений октетов в едином дампе, за которым следует разбор заголовка и тела этого PDU. Для лучшего понимания того, как кодирование соответствует определению поля за полем, это следует сравнить с определением PDU сообщения типа submit sm из спецификации SMPP. Разбивка значений показана десятичными числами в скобках, а затем шестнадцатеричными значениями. Если вы видите один или несколько шестнадцатеричных октетов, это связано с тем, что для данного размера поля используется кодирование из одного или нескольких октетов. Повторное обращение к определению PDU сообщения типа submit sm в спецификации поможет прояснить все детали.

Заголовок PDU

"длина команды", (60) 00 00 00 3C
"идентификатор команды", (4) 00 00 00 04
"статус команды", (0) 00 00 00 00
"номер последовательности", (5) 00 00 00 05

Корпус PDU

'тип услуги', 00
'исходный адрес TON', (2) 02
'исходный адрес NPI', (8) 08
'исходный адрес', (555) 35 35 35 00
'адрес назначения TON', (1) 01
'адрес назначения NPI', (1) 01
'адрес назначения', (555555555) 35 35 35 35 35 35 35 35 35 00
'класс ESM', (0) 00
'идентификатор протокола', (0) 00
'флаг приоритета', (0) 00
'время запланированной доставки', (0) 00
'срок действия', (0) 00
'подтверждение доставки', (0) 00
'флаг замены при наличии', (0) 00
'кодировка данных', (3) 03
'идентификатор SM по умолчанию', (0) 00
'длина SM', (15) 0F
'короткое сообщение', (Привет, Википедия) 48 65 6C 6C 6F 20 57 69 6B 69 70 65 64 69 61

Обратите внимание, что текст в поле короткого сообщения должен соответствовать кодировке данных. Когда кодировка данных равна 8 (UCS2), текст должен быть в UCS 2BE (или его расширении, UTF 16BE). Когда кодировка данных указывает на 7-битное кодирование, каждый септет хранится в отдельном октете в поле короткого сообщения (с наиболее значимым битом, установленным в 0). SMPP 3.3 точно копирует значения TP DCS из GSM 03.38, что делает его подходящим только для 7-битной стандартной алфавитной системы GSM, UCS2 или бинарных сообщений; SMPP 3.4 представил новый список значений кодирования данных:

кодировка данных Значение 0 SMSC Default Alphabet (SMPP 3.4) / MC Specific (SMPP 5.0) 1 IA5 (CCITT T.50)/ASCII (ANSI X3.4) 2 Октат не указан (8-битное двоичное) 3 Latin 1 (ISO 8859 1) 4 Октат не указан (8-битное двоичное) 5 JIS (X 0208 1990) 6 Кириллица (ISO 8859 5) 7 Latin/Hebrew (ISO 8859 8) 8 UCS2 (ISO/IEC 10646) 9 Кодирование пиктограмм 10 ISO 2022 JP (Музыкальные коды) 11 Зарезервировано 12 Зарезервировано 13 Расширенный Kanji JIS (X 0212–1990) 14 KS C 5601 15 Зарезервировано 191-195 Зарезервировано 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 такое же, как в SMPP 3.3. Другие значения в диапазоне 1-15 зарезервированы в SMPP 3.3. К сожалению, в отличие от SMPP 3.3, где кодировка данных=0 однозначно соответствовала 7-битной стандартной алфавитной системе GSM, для SMPP 3.4 и выше 7-битная стандартная алфавитная система GSM отсутствует в этом списке, и кодировка данных=0 может отличаться для различных центров обслуживания коротких сообщений — это может быть ISO 8859 1, ASCII, 7-битная стандартная алфавитная система GSM, UTF 8 или даже настраиваемая для ESME. При использовании кодировки данных=0 обе стороны (ESME и SMSC) должны быть уверены, что они рассматривают ее как одну и ту же кодировку. В противном случае лучше не использовать кодировку данных=0. Использование 7-битной стандартной алфавитной системы GSM может быть сложным, некоторые центры обслуживания коротких сообщений требуют кодировки данных=0, другие, например, кодировки данных=241.

Нет кодирования данных для 7-битного алфавита GSM по умолчанию

Хотя значения кодирования данных в SMPP 3.3 основаны на GSM 03.38, начиная с SMPP 3.4, значения кодирования данных для 7-битной GSM-алфавита (GSM 03.38) отсутствуют. Тем не менее, часто значение DCS=0 используется для обозначения 7-битной GSM-алфавита, особенно при SMPP-соединениях с SMSC в GSM-мобильных сетях. Кроме того, остаётся неясным, используется ли 7-битная алфавит в упакованном виде, как в GSM, что позволяет отправлять 160 символов в 140 октетах, или каждый 7-битный символ занимает целый октет (с установленным в ноль старшим битом, как в ASCII).

Не стандартизированное значение data_coding=0

Согласно SMPP 3.4 и 5.0, кодировка данных, равная 0, означает "Алфавит по умолчанию SMSC". Фактическая используемая кодировка зависит от типа SMSC и его конфигурации.

Неясная поддержка кодирования Shift-JIS

Одним из кодирований в стандарте CDMA C. R1001 является Shift JIS, используемый для японского языка. SMPP 3.4 и 5.0 определяет три кодировки для японского языка (JIS, ISO 2022 JP и Extended Kanji JIS), но ни одна из них не совпадает с CDMA MSG ENCODING 00101. Похоже, что кодирование пиктограмм (кодировка данных = 9) используется для передачи сообщений в кодировке Shift JIS в SMPP.

Несовместимость submit_sm_resp между версиями SMPP

Когда отправка sm не удается, SMSC возвращает ответ submit sm resp с ненулевым значением статуса команды и «пустым» идентификатором сообщения. SMPP 3.3 явно указывает относительно поля идентификатора сообщения: «Если поле отсутствует, оно должно содержать один нулевой байт». Длина PDU составляет не менее 17 октетов. SMPP 3.4 содержит неудачное примечание в разделе SUBMIT SM RESP: «Тело PDU ответа submit sm resp не возвращается, если поле статуса команды содержит ненулевое значение». В этом случае длина PDU составляет 16 октетов. SMPP 5.0 просто определяет, что идентификатор сообщения является обязательным параметром типа C Octet string сообщения submit sm resp. Согласно разделу 3.1.1 «Настройки NULL», «NULL-строка» кодируется как 0x00. Длина PDU составляет не менее 17 октетов. Для обеспечения наилучшей совместимости любая реализация SMPP должна принимать оба варианта отрицательного ответа submit sm resp, независимо от версии стандарта SMPP, используемого для связи.

Расширяемость, совместимость и операционная совместимость

С момента введения параметров TLV в версии 3.4, SMPP следует рассматривать как расширяемый протокол. Для достижения максимально возможной совместимости и взаимодействия любая реализация должна применять принцип устойчивости Интернета: «Будьте консервативны в отправляемых данных, будьте снисходительны к принимаемым». Следует использовать минимальный набор функций, необходимых для выполнения задачи. И если цель – коммуникация, а не придирки, каждая реализация должна игнорировать незначительные отклонения от стандарта:

Отвечайте общим негативным подтверждением (nack) со статусом команды=3 на любую неизвестную команду SMPP, но не прерывайте соединение. Игнорируйте любые нераспознанные, неожиданные или неподдерживаемые параметры TLV. Границы PDU всегда определяются полем длины команды PDU. Ни одно поле сообщения не должно выходить за пределы PDU. Если поле завершено некорректно, оно должно рассматриваться как усеченное в конце PDU и не должно влиять на последующие PDU. Информация, применимая к одной версии SMPP, часто может быть найдена и в другой версии SMPP, например, описание единственного механизма подтверждений о доставке в SMPP 3.4, которое относится к SMPP 3.3, описанному выше.

Безопасность

Протокол SMPP основан на бинарном протоколе в открытом виде, что следует учитывать при передаче потенциально конфиденциальной информации, например, одноразовых паролей по SMS. Тем не менее, существуют реализации SMPP с использованием SSL/TLS, если это необходимо.