Одноранговая передача коротких сообщений ( SMPP ) в телекоммуникационной отрасли - это открытый отраслевой стандартный протокол, предназначенный для обеспечения гибкого интерфейса передачи данных для передачи данных коротких сообщений [1] между внешними объектами обмена короткими сообщениями (ESME) и объектами маршрутизации. (RE) и SMSC . [2]
SMPP часто используется, чтобы позволить третьим сторонам (например, поставщикам дополнительных услуг, таким как новостные организации) отправлять сообщения, часто массово, но он также может использоваться для пиринга по SMS. SMPP способен выполнять короткие сообщения , включая EMS , голосовую почту уведомления, Cell вещание , 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 для отправки сообщений. В 1999 году Logica официально передала SMPP Форуму разработчиков SMPP, который позже был переименован в SMS Forum, а сейчас распущен. В соответствии с первоначальными условиями передачи права собственности на SMPP теперь вернулись к Mavenir в связи с расформированием SMS Forum.
На сегодняшний день развитие SMPP приостановлено, а SMS Forum расформирован. С сайта SMS-форума:
31 июля 2007 г. - SMS Forum, некоммерческая организация, миссия которой заключается в разработке, продвижении и продвижении SMS (службы коротких сообщений) на благо глобальной беспроводной индустрии, будет распущена к 27 июля 2007 г.
К новостям прилагается пресс-релиз, предупреждающий о том, что работа сайта скоро будет приостановлена. Несмотря на это, сайт в основном функционировал, и спецификации можно было скачать (по состоянию на 31 января 2012 г.). С 12 апреля 2021 года сменился владелец веб-сайта, и спецификации могут быть загружены только с зеркальных сайтов.
Операция
Вопреки своему названию, SMPP использует модель работы клиент-сервер . Центр службы коротких сообщений (SMSC) обычно действует как сервер, ожидая соединений от ESME. Когда SMPP используется для пиринга SMS, отправляющий MC обычно действует как клиент.
Протокол основан на парах PDU запроса / ответа ( блоки данных протокола или пакетов), которыми обмениваются через соединения уровня 4 OSI ( сеанс TCP или X.25 SVC3). Хорошо известный порт , назначенный IANA для SMPP при работе над TCP является 2775, но несколько произвольные номера портов часто используются в средах обмена сообщениями.
Перед обменом какими-либо сообщениями необходимо отправить и подтвердить команду привязки. Команда bind определяет, в каком направлении можно будет отправлять сообщения; bind_transmitter только позволяет клиенту отправлять сообщения на сервер, bind_receiver означает, что клиент будет только получать сообщения, а bind_transceiver (представленный в SMPP 3.4) разрешает передачу сообщений в обоих направлениях. В команде bind ESME идентифицирует себя с помощью system_id, system_type и пароля; поле address_range, предназначенное для хранения адреса ESME, обычно остается пустым. Команда bind содержит параметр interface_version, чтобы указать, какая версия протокола 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; добавляет поддержку сотового вещания, интеллектуальное управление потоком. По состоянию на 2019 год широко не используется.
Применимая версия передается в параметре interface_version команды bind.
Формат PDU (после версии 3.4)
PDU SMPP кодируются в двоичном формате для повышения эффективности. Они начинаются с заголовка, за которым может следовать тело:
SMPP PDU | ||||
Заголовок PDU (обязательно) | Корпус PDU (опционально) | |||
Команда длина | Команда Id | Команда Статус | Порядковый номер | Корпус PDU |
4 октета | Длина = (значение длины команды - 4) октета |
Заголовок PDU
Каждый PDU начинается с заголовка. Заголовок состоит из 4 полей, каждое из которых имеет длину 4 октета:
- command_length
- Общая длина PDU в октетах (включая само поле command_length); должно быть ≥ 16, так как каждый PDU должен содержать заголовок из 16 октетов
- command_id
- Обозначает операцию (или команду) SMPP. Если старший бит очищен, это операция запроса. В противном случае это ответ.
- command_status
- В запросах всегда имеет значение 0; в ответах несет информацию о результате операции
- Последовательность чисел
- Используется для сопоставления запросов и ответов в рамках сеанса SMPP; позволяет асинхронную связь (с использованием метода скользящего окна )
Все числовые поля в SMPP используют порядок прямого байта , что означает, что первый октет является старшим значащим байтом (MSB).
Пример
Это пример двоичного кодирования 60-октетного PDU submit_sm . Данные отображаются в значениях шестнадцатеричных октетов в виде единого дампа, за которым следует разбивка заголовка и тела этого PDU.
Это лучше всего сравнить с определением PDU submit_sm из спецификации SMPP, чтобы понять, как кодировка соответствует определению поля по полю.
Разбивка значений показана с десятичными числами в скобках и шестнадцатеричными значениями после них. Если вы видите один или несколько добавленных шестнадцатеричных октетов, это связано с тем, что данный размер поля использует кодировку 1 или более октетов.
Опять же, чтение определения 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'source_addr_ton', (2) ... 02'source_addr_ npi ', (8) ... 08исходный_аддр, (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'идентификатор_протокола', (0) ... 00'priority_flag', (0) ... 00'schedule_delivery_time', (0) ... 00'validity_period', (0) ... 00'зарегистрированная_ доставка', (0) ... 00'replace_if_present_flag', (0) ... 00'data_coding', (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 | Имея в виду |
---|---|
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 | JIS ( X 0208-1990 ) |
6 | Кириллица ( ISO-8859-5 ) |
7 | Латинский / иврит ( ISO-8859-8 ) |
8 | UCS2 ( ISO / IEC-10646 ) |
9 | Кодирование пиктограмм |
10 | ISO-2022-JP (Музыкальные коды) |
11 | Зарезервированный |
12 | Зарезервированный |
13 | Расширенные кандзи JIS (X 0212-1990) |
14 | KS C 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 для 7-битного алфавита GSM по умолчанию
- Нестандартизированное значение data_coding = 0
- Непонятная поддержка кодировки Shift-JIS
- Несовместимость submit_sm_resp между версиями SMPP
- Использование SMPP 3.3 SMSC Delivery Receipts, особенно формата Message Id в них
Нет data_coding для 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.
Нестандартизированное значение 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 ″ Если оно отсутствует, это поле должно содержать единственный байт NULL ″. Длина PDU составляет не менее 17 октетов.
- SMPP 3.4 содержит неудачное примечание в разделе SUBMIT_SM_RESP ″ Тело PDU submit_sm_resp не возвращается, если поле 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 и delivery_sm_resp PDU с пустым телом и без него. В случае этих двух PDU это пустое тело будет выглядеть как единственный октет NULL в конце потока. Причина, по которой вам может понадобиться эта возможность для включения того, что я называю фиктивными телами с NACKed-запросами, заключается в том, что другая сторона уравнения может быть неспособна или не желает изменять свою реализацию, чтобы допустить отсутствие тела. (Я работал над тремя версиями спецификации SMPP в Aldiscon / Logica и разработал решение ESME для Openmind Networks)
- Кормак Лонг
Идентификатор сообщения в SMPP 3.3 квитанции о доставке SMSC
Единственный способ передать квитанции о доставке в SMPP 3.3 - поместить информацию в текстовой форме в поле short_message ; Однако, формат текста описан в Приложении В SMPP 3.4, хотя SMPP 3.4 может (и должен) использование receipted_message_id и message_state TLVs для этой цели. В то время как SMPP 3.3 утверждает, что идентификатор сообщения представляет собой C-октетную строку (Hex) длиной до 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 TLVs должен быть использован для передачи исхода сообщения.
Расширяемость, совместимость и взаимодействие
С момента введения параметров Tag-Length-Value (TLV) в версии 3.4, SMPP можно рассматривать как расширяемый протокол. Для достижения максимально возможной степени совместимости и взаимодействия любая реализация должна применять принцип устойчивости Интернета : ″ Будьте консервативны в том, что вы отправляете, будьте либеральны в том, что вы принимаете ″. Он должен использовать минимальный набор функций, необходимых для выполнения задачи. И если цель - общение, а не придирки, каждая реализация должна преодолевать незначительные несоответствия стандарту:
- Ответьте generic_nack с command_status = 3 на любую нераспознанную команду SMPP, но не прекращайте обмен данными.
- Игнорируйте любые нераспознанные, неожиданные или неподдерживаемые параметры TLV.
- Границы PDU всегда задаются полем command_length PDUs . Любое поле сообщения не должно превышать конец PDU. Если поле не завершено должным образом, оно должно рассматриваться как усеченное в конце PDU и не должно влиять на дальнейшие PDU.
Информацию, применимую к одной версии SMPP, часто можно найти в другой версии SMPP, например, в случае SMPP 3.4, описывающего единственный механизм получения уведомлений о доставке в SMPP 3.3, описанный выше.
Безопасность
Протокол SMPP разработан на основе бинарного протокола с открытым текстом, который необходимо учитывать при использовании для потенциально конфиденциальной информации, такой как одноразовые пароли через SMS. Однако существуют реализации SMPP через безопасный SSL / TLS, если это необходимо. [3]
Смотрите также
- Универсальный компьютерный протокол / внешний машинный интерфейс (UCP / EMI)
- Компьютерный интерфейс для распространения сообщений (CIMD)
- Богатые коммуникационные услуги
Рекомендации
- ^ "GSM 03.40 Техническая реализация службы коротких сообщений (SMS)" , 3GPP , 2003-12-03
- ^ Спецификация протокола одноранговой сети коротких сообщений v5.0
- ^ "Secure Short Message Peer-to-Peer Protocol" , Международный журнал исследований электронной торговли, 2012 г.
Внешние ссылки
- SMPP реализован на Java
- SMPP Wireshark