С.Кадаков
sgerr@hotmail.com
SMS в двух словах Глава 1 От авторов.

Этой статьей мы открываем цикл, посвящённый сервису SMS, набирающему сейчас всё большую популярность. Основной причиной, побудившей нас взяться за их написание, явилась необходимость просуммировать «для себя» опыт общения с различными SMS протоколами, накопленный при разработке различных же приложений. В процессе написания небольшие заметки «на полях», стали принимать вид достаточно развернутых статей, которые хотелось бы систематизировать, для того, чтобы они пригодились и еще кому-то. Таким образом, на данные статьи предлагается смотреть, как на мини-howto, которое позволит сориентироваться изучающему данный вопрос. Основной трудностью, с которой мы столкнулись «на старте» стала, как ни странно, труднодоступность простой для понимания информации по данному вопросу. Т. е. не то чтобы её не было, а её слишком много и она разного качества: нам не попадалось документа, который внятно бы, step-by-step, показывал, как например, написать приложение с возможностью посылки и приёма SMS. Попытаемся восполнить этот пробел, не претендуя на всеохватность изложения.

SMS (Short Messages Service) — услуга, предоставляемая операторами цифровых стандартов мобильной связи (GSM, CDMA, DAMPS), заключающаяся в отправке коротких текстовых (и не только) сообщений на мобильный телефон, называемый также Mobile Terminal (MT) или Mobile Station (MS). В силу некоторой специфики, данный сервис не приобрёл в России такой же популярности, как на западе, однако, постепенно начинает ее завоевывать. Причина «западной» популярности сервиса проста: его дешевизна по сравнению с голосовыми переговорами, а также то, что обмен короткими сообщениями хорошо поддается автоматизации. Вообще, с точки зрения SMS, сотовый телефон можно рассматривать, как двусторонний пейджер, с одним большим преимуществом: сообщение будет обязательно доставлено (как говорят «доведено»), вне зависимости, находится ли абонент в зоне приема в момент его отправки (а точнее будут предприниматься попытки его доведения до тех пор, пока не истечет его «срок годности», validity period). А длины в 160 символов обычно достаточно, чтобы сказать что-нибудь типа «Я выезжаю» или «Свяжись со мной по телефону 02».

Резонный вопрос, ведь написание софта для «мобильников» не самая распространенная область программистской деятельности. Но вся штука в том, что большинство (а скорее всего — все) операторов предоставляют возможность обмена короткими сообщениями между MT и внешними, по отношению к мобильной сети (PLMN – Private Local Mobile Network) устройствами, т. н. ESME (External Short Messages Entity), в качестве которого может выступать любое ПО, поддерживающее определенный протокол. Делается это с помощью определенных устройств, называемых SMSC (Short Messages Service Center), одним «концом» подключенных к PLMN, а другим — в сеть общего назначения, например TCP/IP (Internet). Вот как это выглядит:

Не обращайте пока внимание на аббревиатуру SMPP (к ней мы вернемся чуть позже), а вместо неё читайте «некоторый протокол для связи с SMSC». Хорошим примером ESME является последняя версия ICQ. Что? Уже кидали «мессаги» подружке на трубку? Так не пора ли теперь разобраться, как все это устроено? 2.3 Протоколы SMS.

Вот тут мы затронули достаточно скользкую тему. Дело в том, что хоть они и называются «протоколами», таковыми они на деле не являются: это отраслевые рекомендации разработчиков SMSC, которых довольно много. И если в части передачи сообщений по мобильным сетям особых разногласий не наблюдается: работает «настоящий» протокол SS7 (Signaling System Seven, тема для отдельного большого разговора), то в части доведения сообщений от ESME до SMSC каждый разработчик придумывает свой «протокол»; единственное требование к разработчику: публикация спецификаций. Упомянем самые популярные протоколы, кратко перечислив их отличительные черты.

SMPP (Short Messages Peer-to-Peer) является, видимо, самым распространенным протоколом и разрабатывается SMPP Developers Forum (ничего общего с Open Source, просто организация такая). Один из, на наш взгляд, самых удобных протоколов, много возможностей, достаточно хорошо проработан. SMPP предлагает бинарную кодировку пакетов (впрочем, к этому мы еще вернемся). Используется многими операторами, в т. ч. British Telecom.

Протокол EMI (External Machine Interface) продвигает ETSI (кажется расшифровывается как European Telecommunication Standards Institute). Предлагает текстовую кодировку пакетов, также имеет развернутые возможности, но, на наш взгляд, неэстетичен. В различных диалектах используется многими провайдерами, точно — Swisscom'ом, и, вроде как, — NWGSM'ом.

Тяжёлый протокол, разрабатывается SEMA Group. Однако, возможности большие. Предлагает на выбор бинарную, шестнадцатиричную и IA5 кодировку пакетов. Используется Vodafone. Оставляет неприятные воспоминания.

Тоже протокол... Напоминает EMI... ;)

Несмотря на такое изобилие, суть работы всех протоколов сводится, что очевидно, к нескольким простым функциям (смотрим со стороны ESME): Организация соединения с SMSC Отправка сообщений в PLMN Прием сообщений из PLMN Прием подтверждений доставки (delivery receipts) 2.4.1 Установка связи

Фактически, порядок работы следующий: соединяемся с SMSC и, поверх сетевого протокола, начинаем слать пакеты (называемые часто «командами» или «операциями») в формате выбранного нами SMS-протокола. Для простоты, будем опираться на самый распространенный случай, связь по TCP/IP, хотя многие модели SMSC поддерживают связь через, например, X.25 или PSTNA, а SMS-протоколы абстрагированы, насколько возможно, от деталей установки соединения.

Для того, чтобы предоставить гарантию доставки, все SMS-протоколы используют транзакционный механизм, а проще говоря, подтверждения для каждой, испущенной (invoke) любой из сторон, команды. Получив команду, участник обмена (SMSC или ESME) обязан ответить на неё специальным пакетом, называемым в разных протоколах по-разному: response, result или ACK (от acknowledgement). Мы будем называть такие пакеты ACK (опять же, чтобы не путаться в терминах). Различают два типа ACK'ов: собственно ACK — положительный ответ и NACK — отрицательный (negative) ответ. NACK кроме указания на тот факт, что приключилась ошибка, передает еще и её код, прописанный в спецификации протокола. Вот как это выглядит в графике:

И в обратную сторону:

Каждая транзакция нумеруется инициирующей стороной, принимающая сторона использует переданный ей номер в ACK'е. Правила нумерации обычно свободные, указывается только диапазон допустимых номеров, для каждого протокола он, естественно, разный. Однако открытие двух транзакций с одним номером в рамках одной сессии, как правило, недопустимо. В случае неприхода ACK'а за определенное время (настраиваемое как на SMSC, так и на ESME) команда считается неуспешной и, в зависимости от логики работы, повторяется. Если противоположная сторона продолжает «молчать» в ответ на испущенные команды, соединение обычно разрывается.

Теперь мы знаем о предмете достаточно, чтобы сформулировать задачи требующие решения для написания ESME клиента. Необходимо: Иметь возможность установки соединения по TCP/IP с сервис-центром. Уметь формировать пакеты в формате выбранного нами протокола. (В скобках заметим, что, как правило, выбор протокола определяется не пристрастиями программиста, а жестко закреплен предоставляемым сервисом.) Уметь «разбирать» (parse) пакеты в формате выбранного протокола. Мы здесь не упомянули одну важную «административную» задачу — подписание договора на обслуживание с поставщиком услуг сотовой связи. Однако, решение таких вопросов обычно лежит вне рамок программистской компетенции.

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