Interactive SMS  
SMPP

SMS-рассылки от 3 коп. за SMS!!!

    О проекте     Вопросы и ответы     Статьи     Архив     Утилиты     Программы     Обратная связь    

I. Основные этапы

Чтобы рассмотреть принципы построения информационных систем, использующих в качестве транспорта технологию коротких сообщений (СМС) надо начать со структуры и принципов работы в сетях ГСМ.
Технология построения таких систем довольно проста , т.к. функции транспорта уже реализованы оператором.
Принцип действия таких систем может немного варьироваться, но в основном он остается стандартным: запрос - ответ. Т.е. абонент сотовой сети посылает на некоторый сервисный номер, который может быть как коротким, так и иметь федеральный формат СМС соответствующего формата, центр по обработки коротких сообщений (СМСЦ) оператора направляет его на обслуживающее приложение (ЕСМЕ), которое, в свою очередь, обработав запрос, формирует запрашиваемый абонентом контент (информацию) и отправляет его в виде СМС на СМСЦ, который доставляет СМС абоненту.
В принципе, длина номера ограничена только стандартом. В стандарте SMPP принято, что длина номера может быть до 20 символов (байт, октетов). Как правило, операторы выделяют под сервисные услуги короткие номера. Это связано с тем, что в данном случае (при правильном администрировании СМСЦ) на указанный номер попадут только запросы своих абонентов, и с тем, что можно устанавливать на данный номер специальную тарификацию. Минусом такого подхода является то, что круг потенциальных абонентов-пользователей ограничивается данным СМСЦ (оператором), и для увеличения количества клиентов надо производить подключения к каждому СМСЦ и, соответственно, заключать необходимые договора. Использование федерального номера как сервисного обосновано в случае, когда СМС используется как транспорт, а финансовые потоки перекладываются с плеч абонентов, на плечи либо устроителей рекламных акций, либо на систему обслуживания и т.д. Плюсом является моментальный охват абонентов почти всего мира при необходимости только одного подключения.
На рисунке 1 показан общий путь СМС от запроса абонента, до получения им информации. Этот же рисунок показывает схему взаимодействия абонента, оператора, интернет и контен-провайдеров и зону разграничения их ответственности.
Общий путь СМС
Рисунок 1.
MT - мобильный терминал абонента
BSS - базовая станция
MSC - коммутатор оператора сотовой связи
SMSC - СМСЦ оператора сотовой связи
SA - сервера приложений контент-провайдера
SDB - сервера баз данных контент-провайдера


Нас интересует только самая правая часть схемы, вернее только то, что скрывается за аббревиатурой "Сервера приложений контент провайдера". Под этой аббревиатурой скрывается некий комплекс программно-аппаратных средств, который принимает-отправляет СМС от/к СМСЦ, обрабатывает поступающие запросы и формирует необходимый контент.
Общая структура такого приложения (ЕСМЕ) представлена на Рисунке 2.
Назначение каждого элемента видно из его названия:
SMPP-клиент: часть ПО, ответственная за взаимодействие с СМСЦ оператора, она принимает и отправляет СМС, а также делает сопутствующие действия (обрабатывает ошибки, формирует статусы и т.д).
Приемник СМС: часть ПО, ответственная за прием СМС от СМСЦ.
Передатчик СМС: часть ПО, ответственная за отправку СМС от ЕСМЕ на СМСЦ.
Обработчик СМС: часть ответственная за обработку поступивших СМС: готовит запросы на скрипты-формирователи контента, сортирует запросы, готовит контент на отправку.
Анализатор направлений: в зависимости от содержания запросов, либо в зависимости от сервисных номеров, передает обработчику СМС информацию о том, какие скрипты будут обрабатывать поступившие запросы.
Web-скрипт: скрипт, который в зависимости от поступившего запроса формирует необходимый контент.
База данных: база данных - где хранятся очереди на обработку, отправку и т.д.
Таймер: часть ПО, генерирующая периодические запросы, например для рассылок.
Общая структура такого SMPP приложения (ЕСМЕ)
Рисунок 2.

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

1. Поддержка соединения

Ваш СМПП клиент должен, кроме функции приема и отправки СМС, обладать таким замечательным свойством - как поддержание постоянного соединения с СМСЦ оператора. Даже если вы работаете только на отправку СМС, то все равно не стоит каждый раз, при возникновении потребности отправки, коннектиться к СМСЦ и отправлять СМС. Процедура установки соединения, состоящая из 2 частей (установка физического соединения и установка соединения с СМСЦ - Bind), довольно ресурсоемкая и не приветствуется операторами. Вернее, оператору все равно, но возможности подключения к СМСЦ вы скоро лишитесь на административном уровне.
В зависимости от установленного оборудования и ПО соединения может быть как в незащищенном режиме, так и с использованием шифрованного канала. Тип подключения в основном зависит от оператора (хозяина СМСЦ).
Т.к. соединение идет через интернет, а он довольно нестабилен, то соединения будут рваться. Вы должны отслеживать разрыв соединения, при необходимости, делать переконнект.
    Есть несколько способов отследить разрыв соединения:
  • На физическом уровне. Т.к. на низком уровне соединенные машины обмениваются служебными пакетами, то разрыв соединения, соответственно, приведет к потере пакетов и возникновению сигнала о потере соединения. В данном случае информация о критической ситуации получается довольно быстро.
  • На уровне СМПП-протокола. Для определения разрыва соединения и проверки корректной работы установленного коннекта СМПП-клиент (ЕСМЕ) - СМСЦ или СМСЦ - ЕСМЕ в протокол СМПП введены пакеты Enquirer_link, при получении которых необходимо просто отправить назад Enquire_link_resp. Если ваше приложение использует этот способ проверки коннекта, то желательно иметь возможность задавать интервал посылки Enquire_link, т.к. частые посылки загружают канал, а редкие - увеличивают время обнаружения аварии. Описание данной команды приведено в Приложении Б.1
  • На уровне submit_sm или в любом другом случае, когда идет посылка пакетов ЕСМЕ - СМСЦ. В данном случае обрабатывается разрыв соединения на физическом уровне, т.к. ЕСМЕ пытается отправить пакеты в разорванное соединение. Можно применять, когда осуществляется только отправка сообщений. В данном случае повторный Bind можно вообще делать не сразу, а только по потребности следующей отправки.
    В любом случае обнаружения пропажи соединения, вы должны его (соединение) восстановить как можно скорее, но и здесь есть некоторые особенности. Некоторые СМСЦ могут не знать, что соединение разорвано, и поэтому при вашей повторной посылке Bind выдавать соответствующую ошибку, которая зависит от конкретной реализации СМСЦ:
  • 0x00000004: (ESME_RINVBNDSTS,'Incorrect BIND Status for given command');
  • 0x00000005: ('ESME_RALYBND', 'ESME Already in bound state');
  • 0x0000000d: ('ESME_RBINDFAIL', 'Bind failed');
  • 0x0000000e: ('ESME_RINVPASWD','Invalid password');
  • 0x0000000f: ('ESME_RINVSYSID', 'Invalid System ID')
Было бы очень хорошо, если бы ваш ЕСМЕ имел настройки таймаута, через который делать повторный Bind.
Если коннект есть, то можно перейти к следующему этапу.


2. Получение СМС

И так, ваш СМПП-клиент работает устойчиво, соединение с СМСЦ держит мертвой хваткой, и вы получили долгожданный deliver_sm. И началась самая важная работа. Первое, что надо сделать, это сформировать правильно и послать deliver_sm_resp. Даже, если вы работаете в асинхронном режиме. Я считаю, что это правила хорошего тона: СМСЦ свое дело сделал, пакет до вас дошел, поблагодарите СМСЦ за это и займитесь дальнейшей обработкой.
И опять первое, (второго, как правило, не бывает) что надо сделать - это определиться, где находится текст сообщения, в Short_Message или Message_Payload. Проверить это довольно просто: если длина Short_Message равна нулю, и в опциональных параметрах СМС есть Message_Payload, то текст доставать из Message_Payload, иначе - как обычно, из Short_Message.
Второе. Можно было бы сразу проверить кодировку и получить СМС в удобочитаемом виде : если бы не длинные СМС, которые подготовлены для склейки. Поэтому сначала обрабатываем склеенные СМС (об этом будет сказано ниже, если я не забуду).
Для остальных СМС производим раскодировку. Мне, например, удобнее хранить текст сообщения в windows-1251, как бы не ругали ее. Как правило, перевод символов национального алфавита, представленных в Unicode не вызывает затруднений. Проблемы начинаются при обработке СМС в GSM Default алфавите. Для правильной обработки необходимо иметь настройку, которая говорит о том, в каком виде приходит текст СМС. Дело в том, что некоторые СМСЦ, даже при указании DCS=0 передают СМС на ЕСМЕ в 8 битке, для других случаев надо распаковать текст сообщения из 7 битки в нормальный, читаемый вид.
И так. СМС принято, разобрано, все необходимое из него получено. И остается ... отправить данное СМС в очередь на обработку.


3. Обработка СМС

Как не странно, обработка СМС, вроде, не имеет никакого отношения к СМПП, но составляет "краеугольный камень" (В.И.Ленин) построения рассматриваемых систем.
Что должно происходить на этом этапе? Да все что угодно. Мы имеем основные параметры СМС: номер абонента-отправителя, сервисный номер (на который было послано СМС), и текст СМС. И с этим мы можем распоряжаться так, как нам вздумается.
При обработке необходимо учитывать, что этот этап может быть довольно трудоемким, ресурсоемким и занимать много времени. Это основная причина того, что рассматриваемая система должна работать в асинхронном режиме (повторюсь, асинхронный режим не на уровне СМПП-протокола, а именно на уровне рассматриваемой системы, в которой части получения СМС, обработки, и отправки разнесены и независимы друг от друга).
Также необходимо рассматривать вопрос о возможности гибкого и легкого конфигурирования обработчиков, т.к. новые сервисы могут появляться довольно часто и подключение их должно занимать как можно меньше времени и быть как можно проще.
Поэтому я предлагаю вынести обработчики наружу и соединяться с ними, используя HTTP протокол.
Итак, что нам надо иметь для обработчика: возможность многопоточных обращений к веб-скриптам, и, собственно, сами веб-скрипты на установленном (где угодно) веб-сервере. Преимуществом такого решения вопроса является независимость от языка программирования обработчиков, расположения скриптов, времени запроса и времени их выполнения (т.к. при многопоточности увеличивается только время обработки конкретного запроса и не тормозится общая очередь).
При унификации протокола обмена между ЕСМЕ и веб, подключение новых сервисов становится очень простой задачей.
Здесь самое время рассмотреть пример такого протокола. (Приложение Б.1.), и, соответственно примеры отправки возможного контента (Приложение Б.1.).
Итак, что мы получили в итоге? В итоге мы получили данные, которые надо отослать абоненту (содержание СМС, дополнительные параметры и т.д.). Т.к. мы уже определились в необходимости асинхронной работы ЕСМЕ, то полученные данные надо поместить в очередь на отправку.
Какие еще проблемы могут возникнуть при рассматриваемом типе обработки? Это может быть как потеря соединения с веб-скриптом в момент запроса или ожидания ответа, так и некорректность сформированного веб-скриптом ответа. И если что-либо изменить на веб-скрипте ЕСМЕ не может, то, при наличии ошибки при обращении к веб-скрипту, необходимо ее проанализировать, и в зависимости от типа ошибки (404 - нет запрашиваемой страницы, 500 - ошибка выполнения скрипта, либо просто временно нет соединения с веб-сервером), либо прекратить дальнейшие попытки получить контент, либо делать заданное в администрировании необходимое количество попыток через заданный промежуток времени.


4. Отправка СМС

Если в очереди на отправку есть данные, которые надо отправить абоненту, то этим как раз и занимается та часть ЕСМЕ, которая отвечает за отправку.
Как обычно, на первый взгляд, все просто - сформировал из полученных данных нужное PDU (формат) и отправил в СМСЦ.
Но даже в этом есть определенные тонкости. Первая тонкость - это кодирование и указывание DCS. Кодировать необходимо либо в Unicode, либо GSM default алфавит(7 битка). Правда, некоторые СМСЦ латинские символы принимают в 8 битной кодировке не зависимо от указания DCS=0 и правильно кодируют в 7 битку уже на своей стороне.
Итак, submit_sm сформировано и отослано. Остается ждать submit_sm_resp. И необходимо приступить к ожиданию и обработке возможных ошибок.
Во первых, submit_sm_resp, может и не прийти. Вообще. Это может быть как из-за ошибок СМСЦ, так и из-за обрыва связи с СМСЦ. Я рекомендую, в данном случае, через, заданный в настройках ЕСМЕ интервал времени, повторить отсылку данного submit_sm. При выборе интервала времени надо учитывать то, что он не должен быть слишком маленьким (т.к. это может вызвать лавинообразный рост отправляемых СМС при увеличении интервала получения submit_sm_resp), так и слишком большим. Лучше узнать, какой интервал времени стоит на СМСЦ при формировании ошибки Timeout при неполучении submit_sm_resp. Я рекомендую устанавливать данный интервал в размере 10 минут.
Если submit_sm_resp пришел, то самое главное, что нас в нем интересует - это статус нашего отправленного сообщения. И опять имеются 2 ситуации:
- если статус равен 0x00000000 => {code => 'ESME_ROK', msg => 'No error'}, то СМС успешно принято СМСЦ, либо доставлено абоненту (при работе через шлюз),
- статус не равен нулю.
И опять два варианта: критические и не критические ошибки. А вот об их обработки будет рассказано отдельно.

  wlxml2xml & xml2wlxml  
Нужен ли сервис на сайте?
Да (774)50%
Нет (515)33%
Все равно (222)14%
gsm 7 (22)1%
Другой  

Предыдущие голосования
 
  Реклама  
sms2web - легкий путь стать контент-провайдером

 
  Новости-OnLine  

Архив Новостей

 
  Статьи  
 
  Статистика  
  • Посещений:15369873
  • Форумов:13
  • Тем:1367
  • Сообщений:6289
  • Пользователей:6043