Короткое сообщение в одноранговой сети

Одноранговая передача коротких сообщений ( SMPP ) в телекоммуникационной отрасли представляет собой открытый стандартный протокол, разработанный для обеспечения гибкого интерфейса передачи данных для передачи коротких сообщений. ^[1] данные между внешними объектами обмена короткими сообщениями (ESME), объектами маршрутизации (RE) и SMSC . ^[2]

SMPP часто используется, чтобы позволить третьим сторонам (например, поставщикам дополнительных услуг, таким как новостные организации) отправлять сообщения, часто массово, но его также можно использовать для пиринга SMS. SMPP может передавать короткие сообщения, включая EMS , голосовой почты уведомления , сотовую трансляцию , сообщения WAP , включая сообщения WAP Push (используемые для доставки MMS- уведомлений), сообщения USSD и другие. Благодаря своей универсальности и поддержке отличных от GSM протоколов SMS, , таких как 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. ^[3]

В 1999 году Logica официально передала SMPP Форуму разработчиков SMPP, позже переименованному в SMS Forum.

SMS Forum распался в 2007 году со следующим объявлением: «SMS Forum, некоммерческая организация, миссия которой заключается в разработке, развитии и продвижении SMS (службы коротких сообщений) на благо мировой индустрии беспроводной связи, будет расформирована к 27 июля. 2007 год». ^[4] В соответствии с первоначальными условиями передачи право собственности на SMPP вернулось Mavenir.

Операция

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

Протокол основан на парах PDU запроса/ответа ( блоках данных протокола или пакетах), которыми обмениваются соединения уровня 4 OSI ( сеанс TCP или X.25 SVC3). ^[5] назначенный Хорошо известный порт, IANA для SMPP при работе через TCP, — 2775, но в средах обмена сообщениями часто используются несколько произвольных номеров портов.

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

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

Версии

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

SMPP 3.3 — самая старая используемая версия (несмотря на ограничения, она до сих пор широко используется); поддерживает только GSM . Генерирует немедленный ответ на каждое отправленное сообщение.
SMPP 3.4 добавляет дополнительные параметры тега-длины-значения (TLV), поддержку технологий SMS, отличных от GSM, и поддержку трансивера (отдельные соединения, которые могут отправлять и получать сообщения). Обмен PDU запроса и ответа SMPP между передатчиком ESME и SMSC может происходить синхронно или асинхронно.
SMPP 5.0 — последняя версия SMPP; добавляет поддержку сотового вещания, интеллектуальное управление потоком. По состоянию на 2023 год ^[update], он не получил широкого распространения.

Соответствующая версия передается в параметре Interface_version команды привязки.

Формат PDU (после версии 3.4)

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

СМПП ПДУ
Заголовок PDU (обязательно)				Корпус PDU (дополнительно)
Команда длина	Команда Идентификатор	Команда Статус	Последовательность Число	Корпус PDU
4 октета	Длина = (значение длины команды — 4) октетов

заголовок PDU

Каждый PDU начинается с заголовка. Заголовок состоит из 4 полей, каждое длиной 4 октета:

command_length: Общая длина PDU в октетах (включая само поле command_length); должно быть ≥ 16, поскольку каждый PDU должен содержать заголовок длиной 16 октетов.
command_id: Идентифицирует операцию (или команду) SMPP. Если старший бит очищен, это операция запроса. В противном случае это ответ.
command_status: Всегда имеет значение 0 в запросах; в ответах несет информацию о результате операции
sequence_number: Используется для корреляции запросов и ответов в сеансе SMPP; обеспечивает асинхронную связь (используя метод скользящего окна )

Все числовые поля в SMPP используют обратный порядок байтов, что означает, что первый октет является старшим значащим байтом (MSB).

Пример

Это пример двоичного кодирования 60-октетного PDU submit_sm . Данные отображаются в значениях шестнадцатеричных октетов в виде одного дампа, за которым следует заголовок и разбивка тела этого PDU.

Это лучше всего сравнить с определением PDU submit_sm из спецификации SMPP, чтобы понять, как кодировка соответствует полю по определению поля.

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

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

заголовок 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 57 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 , что делает его пригодным только для 7-битного алфавита GSM по умолчанию, UCS2 или двоичных сообщений; В SMPP 3.4 представлен новый список значений data_coding:

`data_coding`	Значение
0	Алфавит SMSC по умолчанию (SMPP 3.4)/специфичный для MC (SMPP 5.0)
1	IA5 ( CCITT T.50 )/ ASCII (ANSI X3.4)
2	Октет не указан (8-битный двоичный файл)
3	Латинский 1 ( ISO-8859-1 )
4	Октет не указан (8-битный двоичный файл)
5	ДЖИС ( Х 0208-1990 )
6	Кириллица ( ISO-8859-5 )
7	Латинский/иврит ( ISO-8859-8 )
8	UCS2 ( ИСО/МЭК-10646 )
9	Значок кодировки
10	ISO-2022-JP (Музыкальные коды)
11	Сдержанный
12	Сдержанный
13	Расширенный кандзи JIS (X 0212–1990)
14	КС С 5601
15-191	сдержанный
192-207	Управление GSM MWI – см. GSM 03.38.
208-223	Управление GSM MWI – см. GSM 03.38.
224-239	сдержанный
240-255	Управление классом сообщений GSM – см. GSM 03.38.

Значение data_coding=4 или 8 такой же, как в SMPP 3.3. Другие значения в диапазоне 1–15 зарезервированы в SMPP 3.3. К сожалению, в отличие от SMPP 3.3, где data_coding=0 однозначно означал 7-битный алфавит GSM по умолчанию, для SMPP 3.4 и выше 7-битный алфавит GSM по умолчанию отсутствует в этом списке, и data_coding=0 может отличаться для разных центров обслуживания коротких сообщений — это может быть ISO-8859-1 , ASCII , 7-битный алфавит GSM по умолчанию, UTF-8 или даже настраиваемый для каждого ESME. При использовании data_coding=0обе стороны (ESME и SMSC) должны быть уверены, что считают одну и ту же кодировку. В противном случае лучше не использовать data_coding=0. Использование 7-битного алфавита GSM по умолчанию может оказаться затруднительным. Некоторые центры службы коротких сообщений требуют data_coding=0, другие, например data_coding=241.

Причуды

Несмотря на широкое распространение, SMPP имеет ряд проблемных особенностей:

Нет data_coding для GSM 7-битный алфавит по умолчанию
Не стандартизированное значение data_coding=0
Непонятная поддержка кодировки Shift-JIS.
Несовместимость submit_sm_resp между версиями SMPP
Использование квитанций о доставке SMSC SMPP 3.3, особенно формата идентификатора сообщения в них.

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

Хотя значение data_coding в SMPP 3.3 основано на GSM 03.38 ) отсутствует , начиная с SMPP 3.4 значение data_coding для 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 data_coding=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. Похоже, что кодировка пиктограммы (data_coding=9) используется для передачи сообщения в Shift-JIS в SMPP.

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

При сбое submit_sm SMSC возвращает сообщение submit_sm_resp с ненулевым значением command_status и ″пустым″ message_id.

SMPP 3.3 прямо заявляет о message_id field ″Если это поле отсутствует, оно должно содержать один NULL-байт″. Длина PDU составляет не менее 17 октетов.
SMPP 3.4 содержит досадное примечание в SUBMIT_SM_RESP раздел ″ submit_sm_resp Тело PDU не возвращается, если command_status поле содержит ненулевое значение.″ Тогда длина PDU составляет 16 октетов.
SMPP 5.0 просто указывает, что message_id является обязательным параметром строки типа C-Octet submit_sm_resp сообщение. В соответствии с разделом 3.1.1 Настройки NULL, ″NULL-строка ″″ кодируется как 0x00″. Длина PDU составляет не менее 17 октетов.

Для лучшей совместимости любая реализация SMPP должна принимать оба варианта отрицательных значений. submit_sm_resp независимо от версии стандарта SMPP, используемой для связи.

Первоначальное намерение сценариев ошибок заключалось в том, что в ответе PDU не будет возвращено никакое тело. Это было стандартное поведение всех SMSC Aldiscon/Logica, а также большинства других поставщиков. Когда SMPP 3.4 обсуждался на форуме WAP, было запрошено несколько разъяснений относительно того, следует ли включать тело в ответ NACKed, и были приняты меры для разъяснения этого в нескольких местах спецификации, включая submit_sm разделе, а также в разделе bind_transceiver раздел. Что нужно было сделать, так это добавить пояснение, которое мы в конечном итоге добавили в V5.0... о том, что тела не должны включаться в ответы об ошибках. Некоторые поставщики были очень глупы в своих реализациях, включая тела отклоненных bind_transmitter ответы, но не на bind_transceiver ответы и т. д. Рекомендация, которую я бы дал продавцам... как предложено выше... примите оба варианта. Но также разумно позволить себе выдавать NACKed submit_sm_resp и deliver_sm_resp PDU с пустым телом и без него. В случае этих двух PDU это пустое тело будет выглядеть как один NULL-октет в конце потока. Причина, по которой вам может понадобиться эта возможность для включения того, что я называю фиктивными телами, в запросы с NACK, заключается в том, что другая сторона уравнения может быть неспособна или не захочет изменить свою реализацию, чтобы допустить отсутствующее тело. (Я работал над тремя версиями спецификации SMPP в Aldiscon/Logica и разработал решение ESME для Openmind Networks)
— Кормак Лонг ^{[ Эта цитата нуждается в цитировании ]}

Идентификатор сообщения в уведомлениях о доставке SMPP 3.3 SMSC

Единственный способ передать квитанции о доставке в SMPP 3.3 — поместить информацию в текстовом виде в short_message поле; однако формат текста описан в Приложении B SMPP 3.4, хотя SMPP 3.4 может (и должен) использовать receipted_message_id и message_state TLV для этой цели. В то время как SMPP 3.3 утверждает, что идентификатор сообщения представляет собой строку C-октета (шестнадцатеричную) длиной до 8 символов (плюс завершающий '\0'), спецификация SMPP 3.4 утверждает, что поле id в формате уведомления о доставке представляет собой строку C-октета. (десятичный) до 10 символов. Это разделяет реализации SMPP на 2 группы:

Реализации, использующие десятичное представление целочисленного идентификатора сообщения в поле id тела уведомления о доставке и шестнадцатеричное представление целочисленного идентификатора сообщения в message_id и receipted_message_id поля
Реализации, использующие одно и то же шестнадцатеричное число (или даже одну и ту же произвольную строку), как в message_id параметр и в поле id тела квитанции о доставке.

Однако в спецификации SMPP 3.4 указано, что формат уведомления о доставке зависит от поставщика SMSC, и поэтому формат, включенный в спецификацию, является лишь одним из возможных вариантов. Как отмечалось выше, при использовании SMPP 3.4 receipted_message_id и message_state TLV следует использовать для передачи результата сообщения.

Расширяемость, совместимость и взаимодействие

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

Ответить с помощью generic_nack с command_status=3 любой нераспознанной команде SMPP, но не прекращайте связь.
Игнорируйте любые нераспознанные, неожиданные или неподдерживаемые параметры TLV.
Границы PDU всегда задаются command_length поле. Любое поле сообщения не должно выходить за конец PDU. Если поле не завершено должным образом, оно должно рассматриваться как усеченное в конце PDU и не должно влиять на дальнейшие PDU.

Информацию, применимую к одной версии SMPP, часто можно найти в другой версии SMPP, например, в случае SMPP 3.4, описывающего единственный механизм получения доставки в SMPP 3.3, описанный выше.

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

Протокол SMPP разработан на основе двоичного протокола с открытым текстом, который необходимо учитывать при использовании для передачи потенциально конфиденциальной информации, такой как одноразовые пароли через SMS. Однако при необходимости существуют реализации SMPP через SSL/TLS. ^[7]

См. также

Ссылки

^ «GSM 03.40 Техническая реализация службы коротких сообщений (SMS)» , 3GPP , 3 декабря 2003 г.
^ «Спецификация однорангового протокола коротких сообщений v5.0» (PDF) .
^ Фридхельм Хиллебранд (2010). Служба коротких сообщений (SMS): создание персональных глобальных текстовых сообщений . Уайли . п. 112. ИСБН 978-0-470-68865-6 .
^ «Главная страница SMS-форума» . smsforum.net . Архивировано из оригинала 22 декабря 2007 г.
^ Нил Крофт (2012). «О криминалистике: тихая SMS-атака» . 2012 Информационная безопасность для Южной Африки . ИИЭЭ . стр. 1–4. дои : 10.1109/ISSA.2012.6320454 . ISBN 978-1-4673-2159-4 . ISSN 2330-9881 . S2CID 13448347 .
^ А. Анри-Лабордер; Винсент Джонак (2004). Взаимодействие SMS и MMS в мобильных сетях . Артех Хаус . стр. 137–138. ISBN 1-58053-890-8 .
^ «Безопасный одноранговый протокол коротких сообщений» , Международный журнал исследований электронной коммерции, 2012 г.

Внешние ссылки

[1] «GSM 03.40 Техническая реализация службы коротких сообщений (SMS)» , 3GPP , 3 декабря 2003 г.

[smpp50-2] «Спецификация однорангового протокола коротких сообщений v5.0» (PDF) .

[3] Фридхельм Хиллебранд (2010). Служба коротких сообщений (SMS): создание персональных глобальных текстовых сообщений . Уайли . п. 112. ИСБН 978-0-470-68865-6 .

[4] «Главная страница SMS-форума» . smsforum.net . Архивировано из оригинала 22 декабря 2007 г.

[5] Нил Крофт (2012). «О криминалистике: тихая SMS-атака» . 2012 Информационная безопасность для Южной Африки . ИИЭЭ . стр. 1–4. дои : 10.1109/ISSA.2012.6320454 . ISBN 978-1-4673-2159-4 . ISSN 2330-9881 . S2CID 13448347 .

[6] А. Анри-Лабордер; Винсент Джонак (2004). Взаимодействие SMS и MMS в мобильных сетях . Артех Хаус . стр. 137–138. ISBN 1-58053-890-8 .

[7] «Безопасный одноранговый протокол коротких сообщений» , Международный журнал исследований электронной коммерции, 2012 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]