Главная › Услуги › Проблемы SMPP-протокола. Отправка смс по протоколу smpp, api для разработчиков

Проблемы SMPP-протокола. Отправка смс по протоколу smpp, api для разработчиков

SMPP (аббревиатура: Short message peer-to-peer protocol) в переводе с английского означает «Короткое сообщение равноправных узлов» и позволяет описать взаимодействие между SMS сервером и конечным клиентом. Данный протокол относится к числу наиболее популярных у SMS-провайдеров, использующих его для обмена текстовыми сообщениями между СМС центрами с равными правами. Для работы с SMPP протоколом необходимо наличие постоянно включенного сервера и соответствующего ПО, совместимого с SMS-шлюзом провайдера.

Поддержка различных текстовых форматов и wap sms;
Отправка длинных текстов;
Двухсторонний обмен сообщениями;
Выбор скорости отправки;
Выбор способа кодировки;
Расширяемость;
Получение детальных отчетов.

Протокол незаменим для регулярной отправки большого объема сообщений по надежному и высокоскоростному каналу. Поэтому SMS провайдер обычно использует данный протокол для обмена SMS и USSD сообщениями в системах VAS, для подключения различных внешних систем и т.д. Узнать подробнее о протоколе SMPP и о том, как существляется рассылка, Вы сможете, обратившись к нашим специалистам.

Поддерживаемые команды
Параметры отправки сообщения (SUBMIT_SM) по SMPP
Правила работы с smpp подключением
Формат Delivery Receipt
Зарезервированные коды ошибок протокола smpp
Приложение

Расшифровку ошибок можно найти в спецификации SMPP 3.4.

Внимание: Вам необходимо прислать список IP адресов, с которых Вы будете
подключаться, перед тем как начать использовать SMPP.

Параметры подключения с использованием SMPP

system_id - зарегистрированное в системе имя пользователя вида XXXX.X
password - пароль пользователя
Адрес -
Порт - 8056

Поддерживаемые команды по протоколу SMPP

На неподдерживаемые команды будут приходить GENERIC_NAK сообщения с кодом ошибки ESME_RINVCMDID.

Параметры отправки сообщения (SUBMIT_SM) по протоколу smpp

Правила работы с SMPP подключением

При установке подключения клиенту дается 10 секунд, что бы отправить команду BIND_TRANSMITTER или BIND_TRANSCEIVER, в противном случае соединение будет разорвано.

Клиент обязан отвечать на все пакеты, полученные через шлюз соответствующим resp пакетом в течение 1 минуты, иначе соединение будет разорвано без отсылки UNBIND.

Получение статуса доставки сообщения

Есть две возможности получения статуса доставки по протоколу smpp (активный и пассивный). Пассивный вариант является предпочтительным.

Пассивный вариант предусматривает установку флага registered_delivery пакета SUBMIT_SM.
После перехода сообщения в финальное состояние сервер отправит DELIVER_SM пакет с Delivery Receipt сообщением. Формат Delivery Receipt сообщения ниже.

Активный вариант предусматривает периодический опрос статуса сообщения отсылкой
QUERY_SM.

Формат Delivery Receipt

"id:IIIIIIIIII sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm
stat:DDDDDDD err:E Text: . . . . . . . . ."

Зарезервированные коды ошибок при smpp соединении

Код	Описание
0x0400 (1024)	Кодировка не распознана
0x0401 (1025)	Слишком большой текст сообщения. Максимальная длина не должна превышать 160
байт. 0x0402 (1026)	Ошибка регистрации сообщения на отправку. При возникновении этой ошибки обратитесь в службу поддержки.
0x0403 (1027)	Не прошла проверка текста сообщения на наличие недопустимых слов и/или фраз
0x0404 (1028)	Отправитель или получатель в черном списке
0x0453 (1107)	Сработало ограничение по отправке одинакового текста на один и тот же номер в течение небольшого промежутка времени. Обратитесь в поддержку, если хотите отключить или уменьшить период.
0x043C (1084)	Нет доступного тарифа для запрашиваемого направления.
0x043F (1087)	Нет подходящего тарифа у вышестоящего контрагента.
0x045A (1114)	Политика маршрутизации не найдена.
0x0446 (1094)	Ошибка транспорта. При возникновении этой ошибки обратитесь в службу поддержки.
0x433 (1075)	Недостаточно средств на счете.

26 сентября 2011 в 12:59

Проблемы SMPP-протокола

Чулан

В мире сложно найти что-либо идеальное. Протокола SMPP также не лишен некоторых изъянов. Опишу свои проблемы с этим протоколом. Надеюсь кому-то это поможет в принятии правильных решений.

Первый , самый проблемный недостаток: потеря message_id при разрыве соединения. Страдают от этого операции отправки (submit_sm и т.п.) для которых не успел прийти ответ. Протокол не содержит встроенных средств восстановления утерянных идентификаторов. Как следствие, когда придет статус сообщения, его не к чему привязать. Более того, неизвестно принял ли это сообщение SMSC.
Если обмен осуществляется в синхронном режиме, то потеряется только одно сообщение. Но если работа производится в асинхронном режиме, тогда потери могут быть существенными.

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

Остальные недостатки связаны с проблемами реализации. Их решении, как правило, заключается в достижении договоренности между SMSC и SMPP-клиентом и не выходит за рамки спецификации.

Второй недостаток, который мне сильно досаждает, связан с отчетам о доставке deliver_sm. В версии протокола 3.4 нет строго определения как должна передаваться статусная информация. С одной стороны есть необязательная структура TLV в которой в жестко типизированной форме передается message_state и сопутствующие параметры. Это вариант хорош, за исключением того, что SMSC не сможет выслать в этой структуре какой-нибудь пространный комментарий. Но, повторюсь, нигде этот способ не указан как обязательный (MUST). Зато в приложении к протоколу приведен пример. Подчеркиваю: ПРИМЕР. Даже не рекомендация. Пример того, как SMSC может сообщать статусную информацию через (о боже, кто это придумал!!!) поле short_message. Т.е. в текстовом виде, странные сокращения, дикие форматы и т.д.
Вообще, это ситуация выбора одного из возможных вариантов (MAY). По моим представления о реализации протоколов выбор одного из разрешенных протоколом варианта - прерогатива формирующей пакет стороны. В данном случае с пакетом отчета это SMSC. А принимающая сторона обязана правильно обработать любой пакет соответствующий протоколу. Но суровая реальность говорит, что прав тот кто платит. Подавляющее большинство SMPP-клиентов понимают только поле short_message.
Славо богу из спецификации пятой версии протокола убрали эту мину (приложение), но найдите-ка SMPP-клиентов пятой версии.

Третий недостаток - передача длинных сообщений. Спецификация ненавязчиво ссылается на стандарт Technical Realisation of the Short Message Service Point to Point». Так ненавязчиво, что замечаешь ссылку только когда ищешь специально. Ссылка на этот стандарт приведена в разделе 1.4 References спецификации версии 3.4.
Вопрос: поле short_message предполагается протоколом использовать только в соответствии с GSM 03.40? GSM 03.40 предлагает длинный текст сообщения разбивается на серию конкатенированных sms, снабженных UDH-заголовками. Спецификация SMPP неявно подстегивает на свободное использование - длина поля 254 октетов. Это две sms латиницей или почти четыре sms кириллицей.
Читаем внимательно спецификацию SMPP:

4.4.1 “SUBMIT_SM” Syntax
«… Up to 254 octets of short message user data. The exact physical limit for short_message size may vary according to the underlying network… »

Т.е. ограничения накладываются передающей сетью (underlying network). В нашем случае underlying network описывается GSM 03.40. Следовательно 140 байт данных. Зачем же такое длинное поле? Дело в том что использоваться может 7-bit кодировка, тогда символов уже 160. short_message это текстовое поле измеряющееся в октетах, а не бинарное в байтах. Возможно, создатели закладывались и на другие, более изощренные варианты.
Разработчик SMPP-клиента по понятным причинам хочет упростить себе задачу. И не стремится на своей стороне связываться c конкатенированными SMS. В соответствии с протоколом SMSC МОЖЕТ предоставлять такую услугу через поле message_payload (самостоятельно делить сообщение на смски, снабжать заголовками) в форме по своему выбору (не стандартизировано). Но по протоколу не обязан. Да и применять это можно без страха только к обычным текстовым сообщениям. С точки зрения бизнеса вопрос тоже скользкий - как тарифицировать такие сообщения? А что если не все части сообщения имеют статус доставлено?

Четвертые недостаток связан с относительным форматом времени. Относительного чего отмерять указанное время? Когда нет задержек ни на клиенте ни на SMSC и между ними хорошая связь, вопросов, как правило, не возникает. Но если в каком-то месте появляется задержка, то точки отсчета времени клиента и SMSC существенно расходятся.
Для schedule_delivery_time в разделе 5.2.15 уточняется:

"..relative time from the current SMSC time at which delivery of this message will be attempted by the SMSC.."

Но проблему разных точек отсчета это не решает.

Литература

Short Message Peer to Peer Protocol Specification v3.4
Technical Realisation of the Short Message Service Point to Point»

Протокол обмена определяется спецификацией SMPP версии 3.4.

Версия 1.0 предназначена только для отправки сообщений и получения статуса доставки.

Прием сообщений в данный момент не поддерживается.

Расшифровку ошибок можно найти в спецификации SMPP версии 3.4.

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

Параметры подключения

Поддерживаемые команды

system_id - зарегистрированное в системе имя имя пользователя.
password - пароль SMS-пользователя
Адрес - sms.сайт
Порт - 9001

На неподдерживаемые команды сервер будет отвечать GENERIC_NAK сообщением с кодом ошибки ESME_RINVCMDID.

Параметры отправки сообщения (SUBMIT_SM)

Правила работы с SMPP подключением

При установке подключения клиенту дается 10 секунд, что бы отправить команду BIND_TRANSMITTER или BIND_TRANSCEIVER. Иначе соединение будет разорвано сервером.

Клиент обязан отвечать на все пакеты отправленные сервером соответствующим resp пакетом в течение 1 минуты. Иначе соединение будет разорвано сервером без отсылки UNBIND.

Получение статуса доставки сообщения

Есть две возможности получения статуса доставки (активный и пассивный). Пассивный вариант является предпочтительным.

Пассивный вариант предусматривает установки флага registered_delivery пакета SUBMIT_SM. После перехода сообщения в финальное состояние сервер отправит DELIVER_SM пакет с Delivery Receipt сообщением. Формат Delivery Receipt сообщения ниже.

Активный вариант предусматривает периодический опрос статуса сообщения отсылкой QUERY_SM.

SMPP - распространенный вид протокола, используемого для приема и передачи sms-сообщений и USSD-запросов. Особенность его является постоянность подключения, что дает одно очень важное преимущество - соединение не разрывается, а рассылка SMS производится с высокой скоростью (до нескольких раз выше, чем при других способах).

Итак, при использовании smpp протокола, вы получаете следующие возможности:

1. доступны различные форматы, в том числе wap push sms;

2. сообщения, отправленные по smpp могут быть не только короткого формата;

4. двухсторонний канал SMS;

5. регулировка скорости.

Как видите, протокол smpp дает большую свободу использования, но, как и у любого средства, здесь есть собственные уникальные особенности, связанные с с настройкой и непосредственно работой. Об этом и поговорим ниже.

Особенности работы с протоколом

Для функционирования smpp требуется сервер, который приспособлен для работы по данному протоколу, и специальное программное обеспечение (клиент). Кроме того, необходимо постоянное стабильное соединение со шлюзом провайдера. Поэтому, мы в обязательном порядке проводим тестирование оборудования, которым располагают наши клиенты - сервер должен быть совместим со скоростной рассылкой SMS. Таким образом, мы изначально упрощаем оказание качественных услуг.

Api подходят для сайтов, написанных на любом языка, в том числе, php.

Протестировать работу настроенного smpp канала могут и сами клиенты, для этого предоставляются все возможности еще до начала пользования услугами. Это позволяет понять, как быстро ваши сообщения, отправленные через протокол smpp, будут доставлены получателям.

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

Параметры для подключения

system_id - зарегистрированное в системе имя пользователя вида XXXX.X
password - пароль пользователя
Адрес -
Порт - 8056

Поддерживаемые команды

	Описание
BIND_TRANSMITTER	Подключиться как TRANSMITTER
BIND_TRANSCEIVER	Подключиться как TRANSCEIVER
	Отправить сообщение
	Запросить статус сообщения
	Отправка Delivery Receipt сервером
	Проверка связи
	Ошибочная команда
	Отключение

В случае ввода некорректной команды, придет ответ вида GENERIC_NAK, в тексте которого будет код ошибки ESME_RINVCMDID.

Параметры отправки SMS сообщения (SUBMIT_SM)

Правила соединения

У клиента есть 10 секунд для установки соединения через шлюз smpp, в течение которых должна быть послана одна из команд: BIND_TRANSCEIVER, BIND_TRANSMITTER. В противном случае произойдет разрыв соединения.

Также, разрыв произойдет если клиент не ответит на любой пакет, который отправил сервер не позже чем за одну минуту установленным правилами пакетом resp. При подобном разрыве UNBIND не отправляется.

Единовременно допускается smpp соединение лишь от единственного имени пользователя. Все остальные соединения получат ошибку 0x00000005 ESME Already in Bound State. Однако если вам нужно осуществить не одно соединение в рамках вашего кабинета, то для каждого из этих соединений можно создать собственного пользователя.

В случае отсылки Submit_sm, отмеченного при этом флажком registered_delivery, отправка статуса СМС возможна лишь тому пользователю, который отправлял сообщение.

Статус доставки смс

При работе по данному протоколу статус доставки может быть пассивным (желательно) или активным.

Для получения пассивного отчета необходимо пакет SUBMIT_SM отправлять с предварительно включенным флажком registered_delivery.

Текст Delivery Receipt в пакете DELIVER_SM приходит от сервера когда смс переходит на финальный этап рассылки.

При активном отчете статус смс регулярно проверяется при помощи отправки QUERY_SM.

Формат Delivery Receipt

"id:IIIIIIIIII sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm
stat:DDDDDDD err:E Text: . . . . . . . . ."

Зарезервированные коды ошибок

	Описание
	Кодировка не распознана
	Слишком большой текст сообщения. Максимальная длина не должна превышать 160
0x0402 (1026)	Ошибка регистрации сообщения на отправку. При возникновении этой ошибки обратитесь в службу поддержки.
	Не прошла проверка текста сообщения на наличие недопустимых слов и/или фраз
	Отправитель или получатель в черном списке
	Сработало ограничение по отправке одинакового текста на один и тот же номер в течение небольшого промежутка времени. Обратитесь в поддержку, если хотите отключить или уменьшить период.
	Нет доступного тарифа для запрашиваемого направления.
	Нет подходящего тарифа у вышестоящего контрагента.
	Политика маршрутизации не найдена.
	Ошибка транспорта. При возникновении этой ошибки обратитесь в службу Поддержки.
	Недостаточно средств на счете.

Аббревиатура SMPP расшифровывается как Short message peer-to-peer protocol (протокол соединения равноправных узлов для передачи коротких сообщений), протокол используется для передачи SMS, USSD и других типов сообщений, как правило, в системах VAS. В конце статьи приведен список терминов используемых в тексте.

SMPP был разработан компанией Aldiscon из Ирландии , перекупленной потом компанией Logica . В 1999 SMPP перешёл под управление SMPP Developers Forum, переименованный позднее в SMSForum . Протокол базируется на обмене PDU (protocol data units) передаваемой на уровне сетевой модели 4 OSI . Обмен пакетами может происходить как синхронно (после отправки запроса дальнейший обмен пакетами приостанавливается до получения ответа), так и асинхронно (запросы отправляются без задержек, обработка ответов происходит по мере их поступления). До недавнего времени последней опубликованной спецификацией была SMPP 3.4, а спецификация SMPP 5.0 долгое время являлась собственностью Logica , но в настоящее время также доступна. Обычно этот протокол используется в режиме постоянного подключения, что позволяет значительно повысить скорость передачи, т.к. не требуется каждый раз устанавливать соединение. Инициировать соединение может как пользователь, называемый в описании протокола External Short Message Entity (ESME), так и SMS-центр (SMSC).

Есть несколько режимов подключения:

Режим «Transmitter» (передатчик) – режим только для отправки сообщений на SMSC и получения соответствующих ответов, без приема входящих сообщений (DELIVER_SM пакетов);

Режим «Receiver » (приемник) – в это режиме все наоборот, только прием входящих сообщений и возвращение соответствующих ответов от SMPP клиентана SMSC , отправка коротких сообщений через этот режим не происходит (SUBMIT _SM пакетов);

Режим «Transceiver» - режим для передачи и приема сообщений, процесс может реализовываться синхронно и асинхронно.

Все данные в протоколе SMPP как говорилось ранее, вложены в блоках, называемых Protocol Data Units, который состоит из заголовка и тела.

Заголовок PDU пакета содержит в себе следующие поля:

command_length - указывает общее число октетов, содержащихся в этом пакете, включая поле длины.

command _ id – идентификатор команды (например submit _ sm , query _ sm и т.д.). И дентификатор команды ответа идентичен соответствующему идентификатору команды запроса, но с установленным 31 битом.

command _ status - указывает успех или неудачу запроса. Данное поле является значимым только в сообщении ответа и должно быть установлено в NULL в сообщениях запроса.

sequence _ number – в данном поле содержится номер последовательности, который позволяет запросам и ответам ассоциироваться в целях корреляции. Использование номеровпоследовательности позволяет, чтобы пакеты SMPP обменивались асинхронно.

Тело PDU является опционным и может быть не включенным в каждый PDU пакет. Структура тела описана в спецификации протокола отдельно, в зависимости от типа PDU.

Так же в PDU пакете могут присутствовать опциональные параметры имеющие общий формат TLV (Tag , Length ,Value).Данные параметры обеспечивают механизм для будущего ввода новых параметров, как и когда определяется в будущих версиях протокола SMPP. Опционные параметры являются полями, которые могут быть включены в сообщение SMPP произвольно, они могут быть включены в любом удобном порядке в пределах раздела «Optional Parameters» передаваемого PDU и их не обязательно надо кодировать в порядке, представленном в спецификации протокола.

Tag – идентификатор данного конкретного опционного параметра;

Length - указывает длину поля Value в октетах (эта длина не включает длину полей Tag и Lengt) . Поле опционного параметра Length всегда будет длиной в 2 октета;

Value – это поле содержит фактические данные для данного опционного параметра.

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

Более подробное описание протокола вы сможете найти в спецификации на русском языке тут: SMPP_v3.4_rus.pdf

Основные понятия и сокращения

SM (Short Message ) – короткое сообщение;

SMS (Short Message Service) - Служба коротких сообщений, осуществляет передачу SM между клиентами мобильных сетей, а также внешними клиентскими приложениями;

USSD (Unstructured Supplementary Service Data)- стандартный сервис в сетях GSM, позволяющий организовать интерактивное взаимодействие между абонентом сети и сервисным приложением в режиме передачи коротких сообщений;

MMS (Multimedia Messaging Service ) — это система передачи мультимедийных сообщений (изображений, мелодий, видео) в сетях сотовой связи .

SMSC (Short Message Service Center ) - Центр обслуживания коротких сообщений - основа функционирования SMS;

VAS (Value Added Services ) — услуги, приносящие дополнительный доход;

ESME (External Short Message Entity ) - Внешнее клиентское приложение, реализующее SMPP-протокол, принимающее или посылающее короткие сообщения;

HLR (Home location register) - Постоянная база данных абонентов, подключенных к мобильной сети. HLR предоставляет SMS маршрут передачи SM адресату;

Октет - 8 бит . В русском языке октет обычно называют байтом .