Привет! Хотя мессенджеры и соцсети с каждым днем вытесняют традиционные способы связи, это не умаляет популярность смс. Верификация на популярном сайте, или оповещение о транзакции демонстрируют — они жыви и будут жить. А задумывались как это все работает? Очень часто для рассылки массовых сообщений используется протокол SMPP, о котором и пойдет речь под катом.
На Хабре уже были статьи о smpp, 1,2, но их целью не было описание самого протокола. Безусловно вы можете сразу начать с первоисточника — спецификации, но думаю будет неплохо, чтобы существовало и краткое ее содержание. Буду объяснять на примере v3.4 Рад вашей объективной критике.
Протокол SMPP это протокол одноранговых сообщений. Это означает, что каждый пир/хаб сервер равноправный. В простейшем случае схема обмена смс сообщениями выглядит так:
Однако, если национальный оператор не имеет маршрута в какой-то отдаленный регион он просит об этом посредника — смс хаб. Иногда, чтобы отправить одну смс, нужно выстроить цепочку между несколькими странами, или даже континентами.
SMPP — протокол прикладного уровня, который базируется на обмене PDU и передается поверх TCP / IP, или Х25 сессий для передачи sms и ussd сообщений. Обычно SMPP используется в режиме постоянного подключения, это помогает сэкономить время. SMPP использует модель общения клиент — сервер.
Обмен сообщений между отправителем и SMSC через SMPP может проводиться в следующих режимах:
Transmitter (передатчик) — передача сообщения в одну сторону, поочередно
Receiver (приемник) — только прием сообщение от SMSC.
Transreceiver (приемопередатчик) — Обмен сообщениями между SMSC и пользователем
Одно SMS-сообщение может содержать 70 символов при наборе кириллицей и не более 157 латинских символов + 3 UDH Если отправить. SMS с большим количеством символов, оно будет разделено на несколько сегментов и объединены в принимающем устройства. В случае сегментации количество символов уменьшается за счет заголовков сообщения в котором указывается часть сообщения. Поэтому при отправке большого SMS-сообщения, оно содержит максимум 153 латинских символов или 67 нетипичных символов.
Однако для передачи сообщения символы требуют кодирования. В протоколе SMPP за кодирование отвечает специальное поле — Data Coding Scheme, или DCS. Это поле, которое указывает как нужно распознавать сообщения. Кроме этого поле DCS включает в себя:
Стандартный 7-битный алфавит (GSM 03.38). Был разработан для системы сообщений в GSM. Такое кодирование подходит для английского и ряда латинских языков. Каждый символ состоит из 7 бит и кодируется в октет.
UTF-16 (в GSM UCS2) Для включения отсутствующих символов в 7-битного кодирования была разработана кодировка UTF-16 которая и добавляет дополнительные символы (в том числе и кириллические) за счет уменьшения размера сообщения с 160 до 70 этот тип кодирования почти полностью повторяет Unicode.
8- битные данные определенные пользователем. К таковым относятся KOI8-R и Windows-1251. Хотя такое решение кажется более экономичным по сравнению с тем же UTF-1, но для использования таких кодировок требуется предварительная настройка на принимающем и передающим устройстве. Если на каком – то из них данные кодировки не поддерживаются сообщение будет отображаться не корректно. Поскольку в таком случае оба устройства должны быть заблаговременно настроены.
Silent message (SMS0) Тип смс сообщения без контента. Такое смс приходит без уведомления и не отображается на экране устройства.
Каждая pdu операция парная и состоит из запроса и ответа. Например: команда что говорит об установлении соединения (bind_transmitter / bind_transmitter_resp), или о том, что сообщение передано (deliver_sm / deliver_sm_resp)
Каждый pdu пакет состоит из двух частей — заголовок (header) и тело (body). Структура заголовка одинакова для любого pdu пакета: command length это длина пакета, id это название пакета, а команда status показывает успешно передано сообщение, или с ошибкой.
TLV (Tag Length Value), или дополнительные поля. Такие параметры используются для расширения функций протокола и не являются обязательными. Данное поле указывается в конце поля pdu. В качестве примера с помощью TLV dest_addr_np_information можно организовать передачу информации о портированности номера.
TON (Type of Number) параметр, сообщает SMSC о формате адресации и тип сети.
NPI (Numbering Plan Identification) параметр, указывающий на план нумерации.
Сообщения, отправляемые на телефон бывают двух разновидностей: цифровые и буквенные. Цифровые могут быть длинными (похожими на номер телефона) и короткими. Иногда у операторов существуют ограничения на отправку от нейтральных имен, например Infosms, Alert etc. Иногда операторы не пропускают трафик, если имя не зарегистрировано в их сети. Однако это скорее особенности оператора.
SMS-SUBMIT — это отправка сообщения MO FSM (короткое сообщение от мобильного терминала)
SMS-SUBMIT REPORT — подтверждение, что сообщение отправлено SMSC
SRI SM (SendRoutingInfo) — SMSC получает информацию от HLR относительно MSC / VLR места нахождения абонента
SRI SM RESP — ответ от HLR относительно мясца положения абонента
MT-FSM — после получения местоположения отправляется сообщение используя операцию «Forward Short Message»
MT-FSM ACK — ответ от SMSC о том, что сообщение отправлено
SMS-STATUS REPORT — SMSC отправляет статус о доставке сообщения.
SMS-STATUS REPORT может принимать несколько значений:
DELIVRD сообщение успешно доставлено
REJECTD — сообщение отвергнуто SMS-центром
EXPIRED — сообщение удалено из очереди отправки после окончания TTL (время жизни сообщения)
UNDELIV — другие случаи недоставки
UNKNOWN-не получен ответ об отправке.
Иногда сообщения не доставляются. Вследствие чего возникают ошибки. Ошибки возвращаются в PDUs_sms_resp. Все ошибки можно разделить на временные (Temporary) и постоянные (Permanent).
В качестве примера, к временным можно отнести absent_subscriber абонент не доступен или не в сети, а к постоянным — абонент не существует. В зависимости от ошибок, которые возникают формируется политика переотправки этих сообщений.
Например, если абонент был занят разговором и получил ошибку MT handset is busy, сообщение можно отправить повторно через несколько минут, однако, если у абонента заблокирован сервис приема сообщений повторная переотправка не будет иметь смысла. Список ошибок вы сможете найти на страницах SMSC, например, как эта.
На Хабре уже были статьи о smpp, 1,2, но их целью не было описание самого протокола. Безусловно вы можете сразу начать с первоисточника — спецификации, но думаю будет неплохо, чтобы существовало и краткое ее содержание. Буду объяснять на примере v3.4 Рад вашей объективной критике.
Протокол SMPP это протокол одноранговых сообщений. Это означает, что каждый пир/хаб сервер равноправный. В простейшем случае схема обмена смс сообщениями выглядит так:
Однако, если национальный оператор не имеет маршрута в какой-то отдаленный регион он просит об этом посредника — смс хаб. Иногда, чтобы отправить одну смс, нужно выстроить цепочку между несколькими странами, или даже континентами.
О протоколе
SMPP — протокол прикладного уровня, который базируется на обмене PDU и передается поверх TCP / IP, или Х25 сессий для передачи sms и ussd сообщений. Обычно SMPP используется в режиме постоянного подключения, это помогает сэкономить время. SMPP использует модель общения клиент — сервер.
Режим связи
Обмен сообщений между отправителем и SMSC через SMPP может проводиться в следующих режимах:
Transmitter (передатчик) — передача сообщения в одну сторону, поочередно
Receiver (приемник) — только прием сообщение от SMSC.
Transreceiver (приемопередатчик) — Обмен сообщениями между SMSC и пользователем
Структура
Длина сообщения
Одно SMS-сообщение может содержать 70 символов при наборе кириллицей и не более 157 латинских символов + 3 UDH Если отправить. SMS с большим количеством символов, оно будет разделено на несколько сегментов и объединены в принимающем устройства. В случае сегментации количество символов уменьшается за счет заголовков сообщения в котором указывается часть сообщения. Поэтому при отправке большого SMS-сообщения, оно содержит максимум 153 латинских символов или 67 нетипичных символов.
Data Coding Scheme
Однако для передачи сообщения символы требуют кодирования. В протоколе SMPP за кодирование отвечает специальное поле — Data Coding Scheme, или DCS. Это поле, которое указывает как нужно распознавать сообщения. Кроме этого поле DCS включает в себя:
- набор символов, который определяет кодирование;
- клас сообщения;
- запрос на автоматическое удаление после прочтения;
- указание о сжатии сообщения;
- язык широковещательного сообщения;
Стандартный 7-битный алфавит (GSM 03.38). Был разработан для системы сообщений в GSM. Такое кодирование подходит для английского и ряда латинских языков. Каждый символ состоит из 7 бит и кодируется в октет.
UTF-16 (в GSM UCS2) Для включения отсутствующих символов в 7-битного кодирования была разработана кодировка UTF-16 которая и добавляет дополнительные символы (в том числе и кириллические) за счет уменьшения размера сообщения с 160 до 70 этот тип кодирования почти полностью повторяет Unicode.
8- битные данные определенные пользователем. К таковым относятся KOI8-R и Windows-1251. Хотя такое решение кажется более экономичным по сравнению с тем же UTF-1, но для использования таких кодировок требуется предварительная настройка на принимающем и передающим устройстве. Если на каком – то из них данные кодировки не поддерживаются сообщение будет отображаться не корректно. Поскольку в таком случае оба устройства должны быть заблаговременно настроены.
Клас сообщения
- Class0, или flash, сообщение, хранящихся в памяти телефона по желанию пользователя;
- Class1, или те, которые хранятся в памяти телефона;
- Class2, должен гарантировать, что сообщение сохранится в памяти мобильного терминала, в противном случае должен отдать оповещения SMSC о невозможности сохранить;
- Class3 — в этом случае телефон должен направить извещение о том, что сообщение может быть сохранено, независимо от количества памяти в устройстве. Такой тип сообщения подразумевает, что сообщение достигло адресата;
Тип сообщения
Silent message (SMS0) Тип смс сообщения без контента. Такое смс приходит без уведомления и не отображается на экране устройства.
PDU
Каждая pdu операция парная и состоит из запроса и ответа. Например: команда что говорит об установлении соединения (bind_transmitter / bind_transmitter_resp), или о том, что сообщение передано (deliver_sm / deliver_sm_resp)
Каждый pdu пакет состоит из двух частей — заголовок (header) и тело (body). Структура заголовка одинакова для любого pdu пакета: command length это длина пакета, id это название пакета, а команда status показывает успешно передано сообщение, или с ошибкой.
Дополнительные параметры TLV
TLV (Tag Length Value), или дополнительные поля. Такие параметры используются для расширения функций протокола и не являются обязательными. Данное поле указывается в конце поля pdu. В качестве примера с помощью TLV dest_addr_np_information можно организовать передачу информации о портированности номера.
Ton и Npi
TON (Type of Number) параметр, сообщает SMSC о формате адресации и тип сети.
NPI (Numbering Plan Identification) параметр, указывающий на план нумерации.
Адрес источника сообщения, или альфа имя
Сообщения, отправляемые на телефон бывают двух разновидностей: цифровые и буквенные. Цифровые могут быть длинными (похожими на номер телефона) и короткими. Иногда у операторов существуют ограничения на отправку от нейтральных имен, например Infosms, Alert etc. Иногда операторы не пропускают трафик, если имя не зарегистрировано в их сети. Однако это скорее особенности оператора.
Стадии отправки
SMS-SUBMIT — это отправка сообщения MO FSM (короткое сообщение от мобильного терминала)
SMS-SUBMIT REPORT — подтверждение, что сообщение отправлено SMSC
SRI SM (SendRoutingInfo) — SMSC получает информацию от HLR относительно MSC / VLR места нахождения абонента
SRI SM RESP — ответ от HLR относительно мясца положения абонента
MT-FSM — после получения местоположения отправляется сообщение используя операцию «Forward Short Message»
MT-FSM ACK — ответ от SMSC о том, что сообщение отправлено
SMS-STATUS REPORT — SMSC отправляет статус о доставке сообщения.
Статус доставки сообщения
SMS-STATUS REPORT может принимать несколько значений:
DELIVRD сообщение успешно доставлено
REJECTD — сообщение отвергнуто SMS-центром
EXPIRED — сообщение удалено из очереди отправки после окончания TTL (время жизни сообщения)
UNDELIV — другие случаи недоставки
UNKNOWN-не получен ответ об отправке.
Ошибки передачи
Иногда сообщения не доставляются. Вследствие чего возникают ошибки. Ошибки возвращаются в PDUs_sms_resp. Все ошибки можно разделить на временные (Temporary) и постоянные (Permanent).
В качестве примера, к временным можно отнести absent_subscriber абонент не доступен или не в сети, а к постоянным — абонент не существует. В зависимости от ошибок, которые возникают формируется политика переотправки этих сообщений.
Например, если абонент был занят разговором и получил ошибку MT handset is busy, сообщение можно отправить повторно через несколько минут, однако, если у абонента заблокирован сервис приема сообщений повторная переотправка не будет иметь смысла. Список ошибок вы сможете найти на страницах SMSC, например, как эта.
Комментарии (5)
Daar
23.05.2019 20:19+1Вызвало некоторую дрожь в коленях :)) Давным давно в далекие далекие времена писали свой софт для отправки сообщений с сайта. И выдал нам тогда оператор связь толстый талмуд, точнее ксерокопию не первого качества на английском языке, и это было описание протокола SMPP. Мы его долго прогоняли через FineReader а потом через Promt, что бы понять что и как работает. В общем боль запомнилась на долго :)))
kilgur
24.05.2019 07:50Я дико извиняюсь — таки серьёзный ресурс, но можно я вот эту опечатку не в личку отправлю, а в комментарии оставлю? ИМХО, шедевр:
SRI SM RESP — ответ от HLR относительно мясца положения абонента
Alex_Crack
Такое ощущение, что перевели отрывки из спецификации через гуглотранслейт, попутно забыв про знаки препинания. По существу: про конкатенацию частей есть неточности в количестве символов, ну и вообще лишь маленькая оговорка о UDH, а ведь можно еще использовать SAR-параметры или класть текст в TLV-параметр message_payload. Список статусов доставки не полный и не раскрыт. А кодировки — вообще обширная тема, особенно то, как упаковыыаются 7-битные. А еще таймеры есть и много всякого интересного в smpp. В общем тема не раскрыта. Если б не умел глазами парсить дамп smpp, не понял бы о чем статья:)
nemodufruine Автор
Alex_Crack, благодарю за отзыв. С грамматикой у меня действительно проблемы, но это не оправдание. При написании я руководствовался спецификацией, но ничего не копировал. По поводу конкатенации, подскажите правильные цифры, пожалуйста.
По поводу SAR и UDH не много знаю, но узнаю, чтобы дополнить эту статью. Если вы поделитесь своими знаниями и опытом, буду благодарен.
По поводу TLV, конкатенации 7-битной кодировки и таймеров я старался рассказать не все, а только по существу. Вы согласны? Тем не менее это отличные темы для будущих статей.
В этой ознакомительной статье я попытался объяснить все нужные базовые параметры для отправки сообщения, сделав каждый раздел логично вытекающим из предыдущего. Если что-то из написанного вам кажется сложным для понимания не посвященного пользователя просьба уточнить.
Alex_Crack
Да, дополню.
Поле short_message по спецификации может быть длиной до 255 октетов.
Но оборудование (и софт) реально работает только со 140.
Тогда мы получаем для 7-битной кодировки (GSM0338) максимальное количество символов: 140*8/7=160 символов.
Для кириллицы каждый символ в кодировке UCS2 (UTF16BE) занимает 2 октета, т.е. 140/2 = 70 символов.
Это для сообщений состоящих из одной части.
Далее, если используется конкатенация с помощью UDH. Этот заголовок может быть двух видов: 6-октетный и 7-октетный. Шести-октетный имеет вид [0x05, 0x00, 0x03, ID, NN, PN], семи-октетный: [0x06, 0x08, 0x04, ID, ID, NN, PN], где ID — идентификатор пачки конкатенированных сообщений, NN — количество частей, PN — номер части в данной PDU.
Как правило, обычно используется только 6-октетный заголовок, рассмотрим его.
В этом случае конкатенированная часть в кодировке GSM0338 может состоять из (140-6)*8/7 = 153 символа, а в кодировке UCS2 — (140-6)/2 = 67 символов.
Этот момент в спецификации не очень хорошо освещен.
sar_*-параметры рассмотрены неплохо в спецификации.
Кстати, да. Хотел еще дополнить, что было бы неплохо увидеть именно серию статей, в каждой из которых подробно был бы рассмотрен каждый аспект. Русскоязычной подробной информации о SMPP, где рассматривались бы все подводные камни, в интернете практически нет. Когда я только подгружался в этот протокол, было очень сложно.