Sms сервер своими руками

Понадобилась срочно информация о создании сервиса смс рассылок. По факту оказалось что обладаю лишь поверхностными знаниями по этой теме, и все знания больше теоретические. Так как дело оказалось актуальным — решил разобраться что нового в этой сфере. Помогать мне в этом будет только информация из интернета.

Несколько месяцев назад и ранее подключал смс-оповещения в интернет магазинах. Заказов там чаще всего немного, соответственно задачи искать сервис от операторов мобильной связи, или ставить дополнительное оборудование на сервер небыло смысла.

Решающим моментом стало наличие хорошей документации к API и наличие готовых решений для распространенных CMS. Мой первый выбор пал на сервис интернет рассылок от ButeHand. Стоимость одного смс в 40коп. для меня не играла роли. В общем все очень быстро завелось на joomshopping и функционирует, по крайней мере особых нареканий небыло.

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

А оказалось что моему собеседнику захотелось построить собственный шлюз смс рассылок. Причем с внушительной пропускной способностью. Вопросы которые он задавал были вполне логичны и с недурным любопытством. Минимальный ценник за 1 смс который мне удалось в стретить в интернете — это 7 коп. , но чаще ценник начинался от ометки 40 коп. Мне дали понять что и 6 коп. если количество смсок начинается от миллиона, — это дорого и что возможно собрать сервер рассылки самостоятельно.

Итак постараемся разобраться что такое смс шлюз и какие варианты его реализации есть.

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

Применяется sms шлюз чаще всего в следующих целях:

уведомление владельца банковского счета о транзакциях;
подтверждение регистрации на сайте или в системе;
информирование о состоянии выполнения заказа;
информирование о новых акциях, услугах компаний;

Шлюз, в данном контексте, это система которая позволяет отправлять и принимать смс. Собственно, использование API другого шлюза для отправки и создание своего API для приема смс превращает написанное в шлюз.

Если же интересует как работают большие шлюзы, которые обрабатывают миллионы смс в день, то нужно смотреть в сторону протокола SMPP или, если есть желание копать еще глубже, то SS7.

SMPP Short message peer-to-peer protocol — протокол, описывающий взаимодействие конечного клиента с SMS-сервером (SMSC). Используется для передачи SMS и USSD сообщений.

Так что, если цель отправлять некоторое количество смс , то надо найти качественного поставщика и подходящим подключением. HTTP API, с которым удобнее всего работать из PHP, сейчас предлагает каждый первый.

Можно арендовать короткий номер у всех операторов, или у агрегаторов (дешевле будет даже не номер, а отдельный префикс, при этом принимать сообщения будете по HTTP от агрегатора, а отправлять сможете как через агрегатора, так и через внешние шлюзы)

Если рассматривать собственный сервер, например чтобы преодолеть лимит в 500 смс/день, как вариант мы можем приобрести несколько сим-карт с красивыми номерами от разных провайдеров и собрать все сами, например на GSM модемах, как советует пользователь блога Subnets. Для приема сообщений кроме как модемом, можно арендовать и промышленный сервис (есть у многих поставщиков, гуглить по словосочетанию Sim hosting)

Если достаточно готового интернет шлюза, то также придется платить:

http://sms.ru/ — от 25 коп. входная цена до 7 коп. оптом.

http://www.smscourier.ru/ — от 20 коп. до 7 коп. оптом. Есть также единый тариф 14 коп. без зависимостей от кол-ва смс.

http://sms.gt/ — 1 доставленное смс — 7 копеек, по заверению разработчиков — никаких пакетов, никаких скрытых платежей.

http://smsaero.ru/ — Низкие цены от 19 до 4 копеек за 1 SMS-сообщение. Понравилось что есть 100 бесплатных смс и заявленная скорость отправки — 300смс в секунду. Так же у сайта оказался очень понятный и приятный интерфейс.

Итак мы выяснили, что сам сервис изначально должен создавться опираясь на бюджет и количество времени которое мы готовы уделять его администрированию. Либо это будет готовый интернет шлюз, либо нам необходимо будет ставить свое оборудование и искать специалистов. Немаловажным фактором является возможность прямого выхода на провайдеров своего города, так как от их техподдержки и качества каналов связи напрямую зависит качество нашего проектируемого сервиса.

Если у вас есть еще информация по проектированию смс-рассылок и интернет-шлюзов добро пожаловать в комментарии, буду рад вашим замечаниям.

Источник

Как сделать свой сервер для приема, обработки и передачи смс

Доброго времени суток, уважаемое хабросообщество!
Недавно в универе мне была поставлена задача создать сервис смс-рассылки уведомлений старостами (деканатом и прочими) своим группам.
Основные требования к сервису были следующими:
— Сервис должен быть многопользовательским (старост более 1) с возможностью одновременной обработки запросов
— Не должен быть привязан к online сервисам рассылки (дабы не утекли базы пользователей)
— Должен быть достаточно легким и мобильным
— Максимально малозатратным
— Должен использовать только открытое программное обеспечение
— Должен обеспечивать отправку уведомлений, даже если у отправляющей стороны нет доступа к Интернету и/или компьютеру. (т.е. не только отправлять, но и принимать входящие смс сообщения от старост + определять от кого конкретно они поступили и делать рассылку по их группам)

Как удалось это реализовать — смотрите под катом.

Список ингредиентов.

Для того, чтобы приступить к организации сервиса, нам будет нужно собрать все необходимые железки.

Компьютером у меня будет выступать нетбук ASUS EEEPC 701
Мобильный телефон, используемый для отправки смс — Nokia 3110
USB bluetooth адаптер — для связи компьютера и телефона
Зарядки для мобильника и нетбука для постоянной поддержки рабочего состояния
Подключение к Интернету. По LAN или Wi-Fi.
Симкарта с тарифом МТС «Супер МТС». У них все смски по РО на любого ОПСОСа по 10 копеек.
Зарегистрированный хостинг и какое-нибудь доменное имя.

В принципе, на этом можно и ограничиться. Но для более комфортной работы я бы посоветовал еще:

Монитор
Беспроводную клавиатуру
Дополнительное охлаждения для нетбука (ибо при работе 24/7 собственного маленького кулера ему будет явно не достаточно)

Охлаждение.

Что касается охлаждения — сделать его совершенно элементарно. Возьмите старый 80 миллиметровый кулер, зачистите красный и черный проводки, идущие от него. Затем отрежьте половину от ненужного USB кабеля. Также зачистите на нем красный и черный провод. Смотайте провода от кулера и от USB вместе, заизолируйте и ваше охлаждение готово. Желательно разместить кулер под нетбуком на пластилиновых ножках, чтобы он громко не резонировал.

Собственно, вот как это выглядит:

Что касается зачистки проводов — я люблю сначала опалить их концы на керосиновой горелке, а потом ножом легко счистить остатки. Керосинку тоже покупать не стоит — ее можно сделать из обычной 60 Ваттной лампочки Ильича. Пробиваете верхушку цоколя, заливаете туда керосин, вставляете кусок старой тряпки вместо фитиля и готово. Вот как это выглядит:

Подготавливаем железо к работе.

В виде операционной системы для нетбука я выбрал EasyPeasy — система для нетбуков, основанная на ядре Linux и модифицированная для слабых компьютеров. Скачать ее, установить на флешку, а затем на нетбук можно тут.

Bluetooth

После того, как операционная система заняла свое место, подключаем bluetooth-адаптер в свободный USB порт. Система должна распознать его автоматически. Включаем Nokia и спариваем телефон и компьютер.

Установка gnokii

Нужно установить gnokii. Я уже и раньше ссылался на эту статью по его установке на Линукс. Думаю, разберетесь.
После установки наберите в консоли что-то вроде echo «Привет, друг!» | gnokii —sendsms ‘+7номер_вашего_друга’ и проверьте, отправилась ли смска.

Подготовка хостинга

Возможно, Вам подойдет какой-либо другой способ организации многопользовательской работы, но я использовал возможности Joomla ACL (уровней доступа). Как это настроить — очень подробно описано в этой статье. Я лишь хочу заметить, что на выходе у Вас должен получиться сайт, где каждый из пользователей (те, кто будет отправлять смски) будет иметь свой личный кабинет, попасть в который он сможет введя номер своего мобильного телефона (в качестве логина, в формате 79XX XXX XX XX) и пятизначный цифровой код в качестве пароля. К примеру, как на сайте vamsms.ru

Подготавливаем программное обеспечение к работе.

Внимание! Все программки я писал сам. Можете использовать их как вам хочется, только дайте обратную связь, если найдете какой-либо серьезный косяк.

Итак, наша задача состоит в том, чтобы научить наш сервер общаться с удаленным сайтом, собирать с него заявки на отправку и отправлять сообщения. Кроме того, сервер должен уметь принимать входящие сообщения (на Nokia, с которой смски отправляются), осознавать, что они отправлены старостами и также ставить в очередь на рассылку по той группе, к которой конкретная староста принадлежит. Плюс, все это нужно синхронизировать. Ну и вести логи, конечно.

Организация MySQL БД

Для начала необходимо сделать БД, относящуюся к хостингу, на котором у Вы организовали сайт. Я назвал свою БД — pXXXX_sender (под XXX скрываются цифры моего пользователя на хостинге)
Внутри этой БД нужно создать 3 таблицы. У меня они имеют следующую структуру:

starosti (идентификация и ареалы действий для старост)
— number
— group
— course
— facultet
— pass

telephones (все телефоны в базе)
— number
— groups
— course
— facultet

on_demand (тут хранятся сообщения на отправку)
— message
— group
— course
— id_this_trans
— date_log

Отлично, на этом с базами данных все.

Организация shell-скрипта на нетбуке (сервере).

Теперь нужно сделать так, чтобы нетбук каждые 10 минут проверял:
1) Поступили ли новые сообщения с сайта? Если да, то отправляю их нужным группам.
2) Поступили новые входящие смски? Если да, то от старост ли они? Если нет, то просто удаляю их, если да, то определяю, за какую группу отвечает староста и делаю рассылку сообщения по той группе.

Привожу листинг shell-скрипта:

Кроме того, в папке со скриптом нужно создать файл cache_test_trig.txt со значением 1 (и в таблице on_demand сделать первую запись какую-нибудь)

Организация php-скриптов на удаленном хостинге.

В личном кабинете пользователя в joomla должна быть форма следующего содержания:

Очевидно, данные из формы передаются в файл, лежащий в корневой директории хостинга handler.php

Вот его листинг:

Далее, для того, чтобы удаленный хостинг мог отвечать на запросы shell-скрипта, необходимо, чтобы в его корневой директории были расположены следующие файлы:

файл serv_mobile.php — отвечает за обработку сообщений, принятых мобильным телефоном

Скрипт trigger.php, тоже лежит в корневой директории, создает папки на хостинге, содержащие файл с сообщением и файл с номерами, которым это сообщение будет рассылаться.

Последний файл в корневой директории — файл terminate.php. Удаляет созданные ранее папки с сервера, когда сообщения уже разосланы.

Подведение итогов.

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

Источник

Свой личный SMS-шлюз. Часть 2 – создаём API и форму отправки

Представляю вам вторую часть из серии статей по созданию своего шлюза.
В первой части мы настроили Gammu, рассмотрели особо интересные параметры и успешно произвели отправку SMS сообщения. Сейчас нам предстоит задача посложнее – создать некую программную прослойку (API), для того, чтобы можно было работать со шлюзом путем отправки запросов на этот API. В первую очередь это комфорт, во вторую – большое количество дополнительных возможностей.

Постановка задачи

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

На чем будем писать backend
Тут все просто, что умеем, на том и пишем, поэтому в моем случае – PHP

Авторизация
Конечно. Сервис будет смотреть в интернет, поэтому авторизация обязательна.

Один пользователь – одна sim-карта?
Конечно нет. У нас сервис для личного пользования и мы хотим иметь один логин, но при этом отправлять с нескольких номеров. Но если появится необходимость выделить один шлюз под конкретный сервис, мы должны иметь возможность добавления пользователей.

Как мы хотим общаться с этим API, откуда будут попадать запросы
Общение будет через POST/GET. Запросы могут отправляться различными устройствами, в том числе и теми, которые не умеют POST или заморочно реализовать, поэтому принимать и обрабатывать будем $_REQUEST. Также мы хотим иметь возможность отправки сообщений через простую форму на сайте.

Один запрос – один адресат?
Нет. В одном запросе с одним текстовым сообщением должна быть возможность указать несколько адресатов. Суть этого понятна. Например я отслеживаю наличие ЭЭ на даче и в случае отключения хочу получить уведомление на все свои телефоны, а может даже телефон супруги… почему бы и нет, ведь уведомление важное.

История отправленных сообщений
Конечно, история это наша важная составляющая жизни, поэтому ее мы всегда храним

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

Задача на разработку поставлена, цель ясна, итак приступим

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

Приступим к созданию БД и создание таблиц
Я буду использовать несколько таблиц для:

users – данные пользователей
smsc_gateway – данных шлюзов
gateway_smscount – счётчик отправленных сообщений по каждому шлюза в конкретный месяц
sms_queue – очередь отправки сообщений
sms_archive – история сообщений

Стоит подробнее остановиться на таблице с данными шлюза и используемых полей – smsc_gateway. Здесь мы используем:

uuid – id пользователя, которому назначен данный шлюз
host – ip-адрес компьютера с модемами для подключения по ssh
port – порт мы тоже укажем, так как желательно не использовать стандартный 22-й, а также это позволит при необходимости использовать port forwarding
password – пароль ssh
gw_phone – фактической номер телефона
maxcount – ограничение на количество отправляемых сообщений
status – статус. 1 — активен, 0 — заблокирован.
gateway_id – канал этого модема в Gammu (помните, у нас может быть несколько модемов)
state – статус шлюза. lock — заблокирован.
comment – свободное поле с комментарием, чтобы просто делать заметки, если нужно

Классов будет всего 5:

Авторизация пользователя – Users_Auth.class.php
Работа с PDO – MYSQL_PDO.class.php
Обработчик по работе с входящими данными SMS – SMS_data_handle.class.php
Работа с Gammu – Gammu_SMS.class.php
Возврат http ответов в json – http_response.class.php

Дальше я буду объяснять как поток данных будет ходить по API опираясь на базу данных. Мне кажется так нагляднее и понятнее. Также я приведу куски этого кода под спойлерами.

В итоге мы получаем такую последовательность действий.

Пользователь отправляет запрос с параметрами:

Значения flash и replacemessages мы рассматривали в прошлой статье. В можно указать несколько номеров телефонов через «,». + в номере телефона указывать не нужно, но обязательно указывать номер в международном формате (для России это 7…). Так же в стоку можно добавить еще один параметр – &attempts= – количество попыток внутри одной отправки, то есть, если можем при отправке вернул ошибку, пытаться ли отправить тут же еще раз?

Вот, что происходит под капотом smsc.php

Первым делом мы подключаем файл с настройками – config.php:

делаем небольшую проверку на XSS, а далее проверяем авторизацию, вызывая метод класса Users_Auth::do($PDO):

Если получили false – авторизация не удалась, возвращаем код и описание ошибки в json, если необходимо.

Если авторизация успешная вызываем $sms_handle->save(), проверяем переданы ли обязательные параметры – телефон и текст сообщения, проверяем в БД статус пользователя, разбираем строку запроса и приводим в нужный нам вид, удаляем пробелы и «+» из номера телефона, а также разделяем их по запятой. Таким образом получаем массив номеров телефонов и текста сообщения, которое нужно на них отправить. Делаем из этого json и сохраняем в таблицу очереди на отправку. Проверка на наличие телефона обязательна. Если попытаться отправлять сообщения без указания номера телефона, возникнет ошибка в Gammu, и шлюз будет занят на несколько секунд. Когда шлюз освободится возникнет аналогичная повторная ситуация, что в свою очередь создаст так называемую «пробку» и последующие сообщения из очереди просто не смогут уйти.

Дальше мы используем простой скрипт, который поставим в cron и будем вызывать раз в 5-10 секунд (по вкусу) – send_queue.php

Он будет обращаться к методу класса обработчика сообщений SMS_data_handle->send(). Здесь уже начинается самое интересное.

Мы получаем сообщение за последние 10 минут без тегов статуса. Если нашли такое, ставим на него тег — process и берём в работу.

Извлекаем из тела json uuid пользователя, обращаемся к таблице и получаем список активных шлюзов. Идем в таблицу со счётчиком и проверяем, не превышен ли лимит на отправку. Если мы получили активный шлюз и счётчик не превышен, ставим на него тег — lock, чтобы никакой другой процесс уже не смог параллельно к нему обратиться. Все вызовы происходит внутри метода send(), но логика раскидана по другим методам класса. По указанному выше описанию работы метода эти обращения легко видны.

Далее мы создаем объект класса $send_proc = new Gammu_SMS($param) с параметрами и обращаемся к методу $send_proc->send($attr) с атрибутами

Весь код метода send():

Если объект вернул true, то переносим сообщение в архив и увеличиваем счётчик отправленных сообщений. Иначе снимаем тег proccess и через некоторое время будет повторная попытка отправки по cron.

Особо внимательные заметили, что мы вызываем метод с дефолтным параметром равным одному – send($с = 1). Параметр $c заложен «на перспективу» и позволяет нам, в случае необходимости получать пачку сообщений из базы данных и обрабатывать их отправку в цикле. Для этого в файле, вызываемом в cron нужно в вызове метода указать число сообщений для выборки их БД – $sms_handle->send(<число>);

Обратим внимание еще на один момент. В файле smsc.php есть возможность отправлять сообщения сразу после того, как оно было добавлено в БД. Для этого нужно раскомментировать следующую строку:

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

Теперь наш шлюз работает через API и умеет отправлять сообщения.

Ну и бонусом мы сделаем простую форму для отправки сообщений с сайта. Ее код не нуждается в пояснении, она просто принимает от вас тест и отправляет POST-запрос на указанный нами скрипт. Единственное в блоке отправки ajax нужно заменить url: «/ » на адрес вашего скрипта smsc.php

Итак подведем итоги проделанной работы. Мы создали аппаратную платформу, научились отправлять сообщения через терминал и расширили возможности системы собственным API для легкого доступа к шлюзу устройств способных отправлять GET/POST-запросы. Хранить историю и балансировать нагрузку между картами и прочее. Все это сильно упрощает работу со шлюзом и позволяет хранить все в одном сервисе.

Внимание, я не претендую на великолепную красоту кода и буду рад любой объективной критике для понимания своих ошибок (в случае наличия) и совершенствования навыков.

Источник