SMSC, SMS-шлюз и SMPP-сервер: что на самом деле делает каждый из них

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

SMSC, SMS-шлюз и SMPP-сервер в одном абзаце

SMSC находится внутри сети оператора мобильной связи и доставляет текстовые сообщения на телефоны. SMS-шлюз находится вне сети: он принимает сообщения от приложений и клиентов, направляет их в нужное подключение к оператору и собирает отчёты о доставке. SMPP-сервер представляет собой компонент шлюза, который позволяет другим системам подключаться к шлюзу по протоколу SMPP точно так же, как сам шлюз подключается к операторам. SMSC эксплуатируют операторы. Шлюзы эксплуатируют компании, которые отправляют или перепродают сообщения. Шлюзы, которые обслуживают технически подготовленных клиентов, эксплуатируют ещё и SMPP-серверы.

Всё, что написано ниже, представляет собой тот же абзац, дополненный подробностями.

SMSC: узел оператора для хранения и пересылки сообщений

Центр коротких сообщений (Short Message Service Centre) представляет собой часть мобильной сети, которая отвечает за SMS. Когда телефон отправляет сообщение, оно попадает в SMSC оператора отправителя; SMSC сохраняет его, выясняет, где находится телефон получателя, и пересылает сообщение, повторяя попытки, если телефон выключен или находится вне зоны покрытия. Именно благодаря такому поведению («сохранить и переслать», store and forward) сообщение приходит, когда вы снова включаете телефон, и делает это SMSC.

Отсюда следуют три вывода. SMSC общается с абонентскими устройствами через сигнальное ядро сети (SS7, а в более новых ядрах Diameter), и это отношения внутри телеком-отрасли, а не интернет-протокол. SMSC принадлежит оператору, и у каждого оператора он свой; глобального SMSC не существует. И SMSC остаётся единственным элементом в этой статье, который может доставить сообщение на телефон. Всё остальное представляет собой способы доставить сообщение до SMSC.

Компании получают доступ к SMSC одним из двух способов: через агрегатора, у которого уже есть подключения ко многим операторам, или напрямую, по договору и через SMPP-подключение (bind), которое предоставляет оператор. В обоих случаях компания является клиентом SMSC, а не тем, кто его эксплуатирует. Продукты, которые продвигают как «SMSC для предприятий», на деле являются шлюзами, принимающими SMPP-подключения (bind); сами по себе они не доставляют сообщения на телефоны.

SMS-шлюз: маршрутизатор, журнал операций и дашборд

SMS-шлюз представляет собой систему, которую компания эксплуатирует, чтобы отправлять сообщения в больших объёмах, а если она занимается перепродажей, то и для того, чтобы отправлять могли её собственные клиенты. Работа шлюза охватывает всё, что происходит между «сообщение принято» и «вот отчёт о доставке»:

• Приём сообщений из веб-консоли, через HTTP API, загрузку файла или SMPP-подключение (bind).
• Проверка: правила для имени отправителя, кодировка, длина, баланс клиента.
• Маршрутизация: выбор подключения к оператору или агрегатора, который доставит это сообщение в это направление, по цене, качеству или договору.
• Доставка по выбранному подключению, обычно по SMPP к оператору или агрегатору, иногда по HTTP к поставщику, с соблюдением скорости и окна (window) этого подключения.
• Сбор отчётов о доставке и их сопоставление с сообщениями, чтобы статус «доставлено», «ошибка» или «срок истёк» дошёл до клиента и до журнала операций.
• Биллинг: списание оплаты с клиента за каждое сообщение, учёт стоимости маршрута и отображение маржи.
• Отчётность для клиента и для того, кто эксплуатирует шлюз.

Шлюз может быть отдельным движком: самый известный движок с открытым исходным кодом называется Kannel, он обрабатывает подключения (bind), очереди и отчёты о доставке и ничего сверх этого. А может быть полноценной платформой, где движок составляет один уровень под порталом, таблицей маршрутизации, тремя моделями биллинга и системой отчётности. На странице платформы весь этот стек Smppcube показан на одной схеме: NGINX, PHP-консоль и конвейер на Node.js, очереди Redis, MySQL как основная база данных, MongoDB для архивов, Elasticsearch для поиска и Kannel в самом низу, который общается с SMSC. Всё это вместе и есть «SMS-шлюз». Kannel сам по себе является движком доставки.

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

SMPP-сервер: вход, к которому подключаются ваши клиенты

SMPP, стандартный протокол операторов связи, устроен по модели «клиент-сервер». Когда ваш шлюз устанавливает bind с оператором, сервером выступает сторона оператора, а клиентом выступаете вы. Когда ваши собственные клиенты хотят подключаться к вам по SMPP, сервером приходится быть вам. Этот компонент и есть SMPP-сервер: он слушает порт (по соглашению 2775), проверяет подключения (bind) по system_id и паролю, принимает пакеты submit_sm, возвращает идентификаторы сообщений, ограничивает пропускную способность для каждого аккаунта и отправляет отчёты о доставке обратно по той же сессии.

Иначе говоря, это ещё один вход в шлюз. Сообщения, пришедшие через SMPP-сервер, попадают в ту же очередь, ту же таблицу маршрутизации и тот же журнал операций, что и сообщения из HTTP API и консоли; почему платформе нужно и то и другое и чем они отличаются на практике, разобрано в руководстве по SMPP и HTTP. Чем SMPP-сервер не является, так это маршрутом к телефонам: он служит входом в систему, а не выходом из неё. Компании, которой нужно только отправлять сообщения, он не нужен никогда. Компании, которая хочет видеть среди клиентов банки, поставщиков OTP и других агрегаторов, он понадобится в тот день, когда об этом попросит первый из них.

Как все три связаны на реальном пути сообщения

Если собрать все три вместе, путь сообщения от клиента реселлера до телефона выглядит так:

1. Клиент передаёт сообщение в шлюз реселлера через веб-консоль, HTTP API или подключение (bind) к SMPP-серверу реселлера.
2. Шлюз проверяет сообщение, списывает стоимость с баланса клиента и выбирает маршрут для направления.
3. Движок шлюза отправляет сообщение через SMPP-подключение (bind) или HTTP-вызов агрегатору либо напрямую оператору получателя.
4. SMSC оператора сохраняет сообщение, находит телефон и доставляет его.
5. SMSC возвращает отчёт о доставке по той же цепочке в обратном направлении; шлюз сопоставляет его с сообщением, проводит операцию в журнале операций и передаёт отчёт клиенту (как deliver_sm в его SMPP-подключении или как webhook в его API).

Два замечания. Во-первых, SMPP-сервер реселлера и SMSC оператора никогда не общаются друг с другом; шлюз между ними работает по SMPP как клиент в сторону операторов (upstream) и как сервер в сторону клиентов (downstream), и именно поэтому термины путают. Во-вторых, один и тот же шлюз может одновременно быть клиентом нескольких SMSC и агрегаторов, и на этом строится вся маршрутизация: сообщение уходит по тому подключению, которое для этого направления самое дешёвое, самое качественное или предусмотрено договором.

Кто что эксплуатирует

	SMSC	SMS-шлюз	SMPP-сервер
Где находится	Внутри ядра сети оператора мобильной связи	На сервере, которым управляет компания (или в аренде как SaaS)	Внутри шлюза, как одна из его точек входа
Кто эксплуатирует	Операторы мобильной связи	Предприятия, реселлеры, агрегаторы, CPaaS-платформы	Шлюзы, которые обслуживают технически подготовленных клиентов
С кем общается	С абонентскими устройствами (через SS7/Diameter) и подключёнными шлюзами	С SMSC, агрегаторами и HTTP-поставщиками выше по цепочке; с клиентами ниже по цепочке	С клиентами, которые подключаются по SMPP
Может сам доставить сообщение на телефон	Да	Только через SMSC	Нет
Примеры	Собственные системы операторов	Kannel (движок); полноценные платформы, такие как Smppcube	Встроен в платформу или добавлен поверх движка

Пометка «в аренде как SaaS» в столбце шлюза указывает на вторую распространённую путаницу: арендованная SMS-панель тоже является шлюзом, только эксплуатирует его кто-то другой, а вы работаете в нём как арендатор. Руководство по SMS-шлюзу на собственном сервере честно сравнивает собственную эксплуатацию шлюза с арендой места в чужом.

Что из этого нужно эксплуатировать вам

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

Если вы перепродаёте сообщения, проводите рассылки для других или обслуживаете обмен сообщениями для многих внутренних команд, вам нужен шлюз. Следующий вопрос в том, арендовать его или держать на собственном сервере, и решают его данные, маржа и зависимость от поставщика, а не технологии; разовая лицензия, например лицензия Smppcube, на вашем собственном сервере соответствует варианту self-hosted в этом выборе.

Если среди ваших клиентов есть те, кто работает с клиентской библиотекой SMPP (банки, поставщики OTP, маркетинговые платформы, другие агрегаторы), вашему шлюзу нужен SMPP-сервер. В некоторых платформах он уже есть; с голым движком вы добавляете его сами.

SMSC вам не нужен. Эксплуатировать его, не будучи оператором, нельзя, да и незачем: до SMSC любого оператора можно добраться через bind или через агрегатора. На практике «нам нужен SMSC» почти всегда означает «нам нужен шлюз с SMPP-сервером и два или три договора с операторами», а это задача гораздо меньше и гораздо дешевле.

Никто, кроме операторов, не эксплуатирует SMSC. Компании эксплуатируют шлюз, а технически подготовленные клиенты подключаются к SMPP-серверу этого шлюза. Разберитесь с терминами, и список покупок составится сам.

Замечание о названиях, которые используют поставщики

Поскольку в маркетинге эти термины пересекаются, читайте список возможностей, а не название. Продукт под названием «ПО для SMSC», в описании которого указаны SMPP-подключения (bind), маршрутизация и биллинг, является шлюзом. «SMPP-сервер», в описании которого есть клиентские аккаунты, тарифные сетки и портал, является шлюзом с точкой входа по SMPP. «SMS-шлюз», который представляет собой только REST-эндпоинт без таблицы маршрутизации, является API одного поставщика. Покупать любой из них не ошибка; важно понимать, что именно он делает, прежде чем сравнивать цены, и для любого выбранного варианта проверить, что он работает на сервере, к которому у вас есть доступ, и хранит записи, которые можно выгрузить.