Требуется приемка по spp протоколу. Отправка смс по протоколу smpp, api для разработчиков. Поддерживаемые команды по протоколу SMPP
Аббревиатура 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 бит . В русском языке октет обычно называют байтом .
В сети существует такой класс сервисов,
которые дают пользователям возможность
вызывать какие-либо функции, посылая SMSки на
специальные номера и получая ответы также в
SMSках. Например, вы можете зарегистрировать
email-ящик для которого можно установить
форвардинг входящего мыла на ваш телефон.
Можно получать в реальном времени новости и
участвовать в чатах. Можно с помощью SMS
заказывать картинки и мелодии для своей
мобилы. Наконец, можно участвовать в
голосованиях. Некоторые ОпСоСы
поддерживают такую услугу, когда за каждую
отправленную юзером SMSку он платит не
только ОпСоСу, но и владельцу сервиса,
осуществляя оплату за услуги, чаще всего,
виртуальные. Пользуясь телефоном, мы не
придаем сопутствующему расходу денег
такого значения, как при использовании WebMoney
или при платежах через СберБанк.
Возможности SMS дают широкий простор для
электронного бизнеса. Многих привлекает
заманчивая перспектива получать легкие
деньги, когда ты только наблюдаешь на
процессом и считаешь деньги, а работают за
тебя скрипты на сервере. Я не ставлю цели
составить руководство по новому виду "бизнеса
для одного человека". В этой статье я
изложу лишь техническую сторону проблемы
автоматизированной обработки SMS.
Разные подходы
В зависимости от поставленных задач и от
имеющегося количества денег можно выбрать
одно из следующих решений:
- Только передавать SMS можно через формы
на сайтах ОпСоСов или на каких-нибудь
порталах. Это бесплатно. Так можно
реализовать отправку SMS со своего портала,
но для реализации платного сервиса, от
которого юзеры ждут особой надежности,
это несерьезно. О них много уже писалось,
поэтому не буду заострять на них внимание,
тем более, что все они в настоящее время
защищены тестом Тьюринга, так что этот
способ в настоящее время недоступен. - Специальные http-to-SMS шлюзы для бизнес-приложений.
Ты платишь, и тебе дают возможность http-запросами
из своих скриптов посылать SMSки в любую
точку мира, а также получать SMS,
отправленные на специальные номера. Так
очень легко сделать портал с SMS-формой или
уведомление о новых письмах. - Протокол SMPP дает возможность не только
принимать и передавать SMS, но и получать
уведомления о доставке отправленных
сообщений, а также отменять и заменять
сообщения. Тебе выделяется номер или
целый диапазон номеров, ты получаешь все
сообщения, приходящие на него и
отправляешь сообщения от любого номера.
Возможно уведомление о полученных
сообщениях: SMS-центр подсоединяется на
предварительно указанный IP и порт и
передает тебе сообщения.
В этой статье я расскажу об SMPP как о самом
продвинутом методе работы с SMS-шлюзами.
С помощью этого протокола можно принимать
и посылать SMS через так называемые SMS-центры.
SMS-центры являются шлюзами между интернетом
и сотовыми сетями. Для работы с этим
протоколом существуют готовые решения,
например, Net::SMPP в Perl. Описание протокола и
ссылки на программные продукты можно найти
по адресу www.smpp.org .
Последняя версия протокола на момент
написания статьи — 3.4. Там же можно скачать
прогу для тестирования клиентского ПО — SMPP
Client Test Tool (SCTT). Пока еще не купили доступ к
реальному SMS-центру, надо как-то тестить
свои проги. Неудобно только ко, что SCTT
написана под Linux, так что придется
повозиться с Virtual PC или сразу кодить под Linux.
Описание протокола
Инициировать соединение может как
пользователь, называемый в описании
протокола External Short Message Entity (ESME), так и SMS-центр
(SMSC). Заметим, что ввиду этой возможности
было бы неправильно называть SMS-центр
сервером, поскольку он может быть и
клиентом. Первый вариант используется, как
правило, при отправке сообщений, а второй
при получении, хотя никто не запрещает
отправлять сообщения через соединение,
установленное SMS-центром и получать через
соединение, установленное тобой самим. Все
данные в протоколе SMPP вложены в блоках,
называемых Protocol Data Units (PDU), которые имеют
заголовок, в котором указан размер блока и
код операции.
Формат PDU header:
DWORD Length — длина всего блока, включая
заголовок
DWORD Command
DWORD Status — 0 в запросах и код ошибка и ответах
DWORD SequenceNumber — порядковый номер.
Порядковый номер в ответе должен
равняться номеру в запросе.
Все числа в SMPP кодируются так, что старший
байт слева. Для этого можно воспользоваться
функцией htonl(). Все PDU делятся на запросы и
ответы. В кодах запросов старший бит равен
нулю, в о ответах единице. На каждый запрос
должен прийти ответ, за исключением
уведомлений о поступивших сообщениях. Пока
ответ не получен, операция считается
незавершенной. Если ответа не последовало
до разрыва соединения, участник, будь то SMSC
или ESME, должен повторить запрос. Протокол
асинхронный, т.е. отправитель запроса может
посылать очередной запрос, не дожидаясь
ответа, и ответы могут следовать в любой
последовательности. Все операции также
делятся на те, которые могут использоваться
ESME, которые могут использоваться SMSC и те,
которые могут использоваться обеими
сторонами. Соединение может находиться в
следующих состояниях:
— Открыто (еще не пройдена аутентификация)
— Передача
— Прием
— Прием и передача
— Закрыто
В состоянии "Открыто", т. е. сразу после
установления TCP-соединения ESME, желающий
передать SMS, должен послать запрос bind_transmitter.
Для приема — bind_receiver. Для обоих действий
сразу — bind_transceiver. В этом запросе передается
логин и пароль. Если соединение установлено
SMSC, то сначала он должен послать запрос outbind
и в нем передать логин и пароль, потому что в
этой ситуации уже его права доступа надо
проверять. Для примера покажу, как выгладит
команда bind_transmitter:
Заголовок:
DWORD Длина
DWORD Command = BIND_TRANSMITTER
DWORD Status = 0
DWORD Sequence number
Данные:
Строка Логин
Строка Пароль
Строка Тип системы (например, WWW или Mail)
BYTE Версия протокола = 0x34
BYTE addr_ton (тип номеров), 0 = default
BYTE addr_npi (Number Plan), 0 = default
Строка Диапазон номеров, пустая строка,
если провайдер и сам знает, какие номера мы
обслуживаем
Строки — ASCIIZ, т. е. Null-terminated.
Большинство параметров этого запроса
могут быть нулями или пустыми строками. В
ответ на такой запрос придет ответ, в
котором кроме заголовка будет SystemId SMS-центра,
а в поле Status будет ноль в случае успеха. Если
установлено соединение для передачи, то мы
имеем право посылать запросы submit_sm, а если
установлено соединение для приема, то надо
ждать запросов deliver_sm, содержащих тексты
поступивших сообщений, и обрабатывать их.
Завершив работу, посылаем сообщение unbind и
отключаемся.
В большинстве запросов есть куча
параметров, над которыми можно особо не
париться и занулять их. Так что несмотря на
внушительный объем документации,
простенький SMS-автоответчик, на основе
которого можно построить какую-нибудь
справочную систему, получился у меня
объемом всего в 25 кБ текста на C++, и тест на
SCTT показал, что всё работает, и осталось
только купить доступ к SMSC:).
К кому подключаться
Сообщения по протоколу SMPP для своих
клиентов принимают многие ОпСоСы, так что
никаких конкретных ссылок. Ищите инфу на
сайте того ОпСоСа, к которым предпочитаете
работать. Кроме того, свой SMS-центр,
работающий по протоколу SMPP, предоставляет
Проблемы SMPP-протокола
- Чулан
В мире сложно найти что-либо идеальное. Протокола SMPP также не лишен некоторых изъянов. Опишу свои проблемы с этим протоколом. Надеюсь кому-то это поможет в принятии правильных решений.
Первый
, самый проблемный недостаток: потеря message_id при разрыве соединения. Страдают от этого операции отправки (submit_sm и т.п.) для которых не успел прийти ответ. Протокол не содержит встроенных средств восстановления утерянных идентификаторов. Как следствие, когда придет статус сообщения, его не к чему привязать. Более того, неизвестно принял ли это сообщение SMS C.
Если обмен осуществляется в синхронном режиме, то потеряется только одно сообщение. Но если работа производится в асинхронном режиме, тогда потери могут быть существенными.
Этот недостаток 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.
(Short Message Peer to Peer - короткое сообщение равноправных узлов) – открытый протокол, который используется для отправки/получения смс-сообщений между равноправными субъектами. Данный протокол используется, как и HTTP, поверх TCP/IP, но является бинарным. Как правило, SMPP протокол обеспечивает режим постоянного подключения, без совершения запросов и ожидания ответов от сервера с дальнейшим разрывом соединения. Использование постоянного подключения увеличивает в разы скорость отправки сообщений.
SMS провайдеры могут ограничить скорость, с которой они будут принимать сообщения в целях оптимизации и распределения их ресурсов. Если вы пытаетесь отправить с большей скоростью, чем позволяет ваш провайдер, вы можете столкнуться с неожиданными ошибками и задержками.
SMPP способен передавать любой тип сообщения, включая такие как UCP/EMI. SMPP поддерживает как длинные текстовые сообщения, так и сообщения, написанные в Unicode. Некоторые SMPP-сервера требуют от отправителя цельное длинное сообщение, а другие - чтобы выполнялось сегментирование сообщения, основанное на типе сообщения.
Существуют три различных типа соединений, которые могут быть поддержаны SMPP сервером.
- «Отправитель» или «отправить только» - работает только передача сообщения и сервер не может получать никаких сообщений.
- «Получатель», или «только прием» - подключение через соединение для передачи сообщений не допускается, сервер может только принимать сообщения. Любая попытка получать сообщения через это соединение, как правило, приводит к ошибке.
- «Трансивер» - разрешено отправлять и передавать сообщения через одно соединение.
Тип подключения, который вы используете, будет зависеть от предпочтений и политики ваших SMPP услуг.
Протокол SMPP является расширяемым, что позволяет провайдерам добавлять свои собственные дополнительные параметры, которые известны как TLV параметры, названные так из-за формата этих параметров: тег (метка), длина, стоимость. Некоторые TLV параметры, определены в спецификации, но не являются обязательными в использовании. Другие параметры предоставляются провайдером.
Возможно использование сервиса SMS, как SMPP сервер для других приложений. Другие клиенты или приложения подключаются к SMS-сервису и их SMPP серверу, и SMS-сервис связывается с одним или несколькими другими SMS-центрами для отправки и получения SMS-сообщений, с использованием SMPP, или, возможно других протоколов.
Передача сообщений между SMS-сервером и SMS Центром провайдера GSM службы по IP связи может быть через выделенную линию (шлюз) через Интернет. При этом IP-соединение между ПК и SMS Центром может быть защищено.
Преимущество SMPP протокола состоит в том, что процесс происходит намного быстрее и с меньшим интервалом (от одной до десяти секунд), чем при использовании мобильного телефона. SMPP рекомендуется применять, если максимальное количество отправляемых сообщений более чем 100 смс/час. Также, SMPP-сервис позволяет вписывать любую информацию (11 знаков) в строку номера отправителя. Поддерживаются цифры, символы латинского алфавита, знаки препинания пробел. Введенная информация будет фигурировать у получателя в строке «Сообщение от:» и может быть самостоятельно сменена отправителем. Таким образом, у вас есть возможность использовать свой SMS-центр, работающий по протоколу SMPP.
