stringtranslate.com

Короткие сообщения Peer-to-Peer

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

SMPP часто используется для того, чтобы позволить третьим сторонам (например, поставщикам услуг с добавленной стоимостью, таким как новостные организации) отправлять сообщения, часто оптом, но его также можно использовать для SMS-пиринга. SMPP может переносить короткие сообщения, включая EMS , уведомления голосовой почты , Cell Broadcasts , сообщения 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.

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

Операция

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

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

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

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

Версии

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

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

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

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

Заголовок PDU

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

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

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

Пример

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

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

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

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

Заголовок PDU

'длина_команды', (60) ... 00 00 00 3C'идентификатор_команды', (4) ... 00 00 00 04'command_status', (0) ... 00 00 00 00'порядковый_номер', (5) ... 00 00 00 05

Корпус блока распределения питания

'тип_услуги', () ... 00'source_addr_ton', (2) ... 02'source_addr_ npi ', (8) ... 08'source_addr', (555) ... 35 35 35 00'адрес_назначения', (1) ... 01'dest_addr_npi ' , (1) ... 01'адрес_назначения', (555555555) ... 35 35 35 35 35 35 35 35 35 00'esm_class', (0) ... 00'protocol_id', (0) ... 00'priority_flag', (0) ... 00'время_доставки_по_графику', (0) ... 00'срок_действия', (0) ... 00'зарегистрированная_доставка', (0) ... 00'replace_if_present_flag', (0) ... 00'кодирование_данных', (3) ... 03'sm_default_msg_id', (0) ... 00'sm_length', (15) ... 0F'short_message', (Привет, Википедия) ... 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=4or 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 в SMPP 3.3 основано на GSM 03.38 , начиная с SMPP 3.4, для 7-битного алфавита GSM ( GSM 03.38 ) нет значения data_coding . Однако 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 Default Alphabet″. Какая именно это кодировка, зависит от типа SMSC и его конфигурации.

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

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

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

Если submit_sm не выполняется, SMSC возвращает сообщение submit_sm_respс ненулевым значением command_status и «пустым» message_id.

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

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

—  Кормак Лонг [ Эта цитата нуждается в цитировании ]

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

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

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

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

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

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

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

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

Смотрите также

Ссылки

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

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