Справочник по протоколам обмена сообщениями.
Точное, основанное на стандартах справочное руководство по протоколам передачи SMS — написано для инженеров, которые их настраивают. Основано на спецификациях SMPP v3.4/v5.0 и 3GPP TS 23.038 / 23.040, содержит реальные схемы байтов, таблицы полей и примеры форматов передачи.
Документов: 65 · протоколов: 9
SMPP
Протокол коротких одноранговых сообщений (SPE) — это протокол бинарных сессий, который операторы связи и агрегаторы предоставляют для высокоскоростной передачи сообщений A2P.
- Основы
Обзор протокола SMPP
Что такое SMPP, как устроена сессия ESME↔SMSC, чем отличаются v3.4 и v5.0 и почему он остаётся стандартом для высокопроизводительной A2P-рассылки SMS.
- Формат передачи
Структура PDU в SMPP: заголовок и тело
Точная разбивка PDU SMPP по байтам: 16-байтовый заголовок (command_length, command_id, command_status, sequence_number), тело и способы кодирования полей.
- Сессия
Операции bind и состояния сессии SMPP
Как аутентифицируется сессия SMPP: bind_transmitter, bind_receiver и bind_transceiver, поля system_id/password/system_type, interface_version, состояния сессии и unbind.
- Операции
SMPP submit_sm: все обязательные поля
Полный справочник по полям submit_sm — service_type, TON/NPI, esm_class, data_coding, registered_delivery, validity_period, short_message и остальные — с указанием действительно важных значений.
- Операции
SMPP deliver_sm: сообщения MO и отчёты
deliver_sm несёт от SMSC к ESME две вещи: сообщения от абонентов (MO) и отчёты о доставке. Как различить их по esm_class и почему всегда нужно отвечать deliver_sm_resp.
- Ошибки
Коды ошибок command_status в SMPP
Поле command_status в SMPP и диапазон ошибок ESME_R*: что означают распространённые коды (ESME_RINVPASWD, ESME_RTHROTTLED, ESME_RMSGQFUL…) и как реагировать на каждый из них.
- Формат передачи
Опциональные параметры TLV в SMPP
Опциональные параметры SMPP используют формат Tag-Length-Value. Разбивка TLV по байтам плюс распространённые теги: message_payload, receipted_message_id, message_state, user_message_reference и набор sar_* для конкатенации.
- Операции
Формат отчётов о доставке SMPP (DLR)
Формат текста отчёта о доставке из Приложения B внутри deliver_sm: id, sub, dlvrd, submit date, done date, stat, err и Text — плюс ключевые слова stat и их номера message_state.
- Сессия
SMPP enquire_link, оконный режим и троттлинг
Как SMPP поддерживает сессию с помощью enquire_link, как окно ограничивает число неподтверждённых PDU и как ESME_RTHROTTLED и TPS на каждый bind определяют вашу реальную пропускную способность.
- Безопасность
Защита SMPP: TLS, аутентификация и белые списки IP
У SMPP нет собственного шифрования. Как защитить bind в промышленной эксплуатации: SMPP поверх TLS, аутентификация по учётным данным и IP, белые списки и гигиена учётных данных.
- Основы
SMPP v3.4 против v5.0: что изменилось
Практические различия между SMPP v3.4 и v5.0: управление перегрузкой, операции широковещания, дополнительные состояния сообщения и TLV — и почему v3.4 остаётся межсетевым стандартом по умолчанию.
- Интеграция
Лучшие практики интеграции SMPP
Как построить интеграцию SMPP, устойчивую в промышленной эксплуатации: стратегия bind, дисциплина sequence_number, оконный режим, повторы с выдержкой, идемпотентность, обработка DLR и переподключение.
кодирование SMS
Как кодируется SMS-сообщение в сети — GSM 7-бит, UCS-2, схемы кодирования данных, сегментация и финансовые последствия для каждого символа.
- Наборы символов
Набор символов GSM-7
Полный 7-битный алфавит по умолчанию из GSM 03.38: базовая таблица из 128 символов, таблица расширения на основе escape (| ^ € { } [ ] ~ \ и form-feed) и как работает 7-битная упаковка.
- Наборы символов
UCS-2 и Unicode SMS
Как SMS передаёт Unicode через UCS-2 (16-битную): предел в 70 символов для одного сообщения, 67 на конкатенированный сегмент, что вынуждает UCS-2, и оговорка о суррогатных парах для эмодзи.
- Кодирование данных
Схема кодирования данных (DCS)
Байт схемы кодирования данных, сообщающий сети, как закодировано SMS: GSM-7 (0x00), 8-бит (0x04), UCS-2 (0x08), плюс классы сообщений (0/flash до 3/SIM) из GSM 03.38.
- Сегментация
Сегментация, конкатенация SMS и UDH
Как длинные SMS разбиваются и собираются заново: 6-байтовый User Data Header, вытекающие из него 153 (GSM-7) и 67 (UCS-2) символов на сегмент, номер ссылки и упорядочивание сегментов.
- Стоимость
Определение кодировки и стоимость SMS
Как определить, GSM-7 текст или UCS-2, какие символы незаметно вынуждают UCS-2 и как кодировка определяет число сегментов — а значит и стоимость — каждого отправляемого SMS.
SS7 / MAP
Сигнальная система № 7 и уровень MAP, передающие SMS-сообщения, отправленные мобильными устройствами, запросы HLR и управление мобильностью в устаревших базовых сетях.
- Основы
Обзор стека SS7: MTP, SCCP, TCAP, MAP, ISUP
Как построен стек SS7 — транспорт MTP1-3, адресация SCCP, транзакции TCAP и пользовательские части MAP и ISUP — и какой уровень что делает для SMS, вызовов и мобильности.
- Транспорт
MTP: Message Transfer Part (уровни 1-3)
Три уровня MTP, транспортирующих SS7: физические каналы MTP1, канал с контролем ошибок MTP2 (сигнальные единицы MSU/LSSU/FISU) и маршрутизация MTP3 по point code с распределением нагрузки и управлением сетью.
- Адресация
SCCP, трансляция global title и subsystem number
Как SCCP расширяет MTP3 адресацией по global title: Called/Calling Party Address, Global Title Translation (GTT), subsystem number (HLR/VLR/MSC) и классы без установления и с установлением соединения.
- Транзакции
TCAP: транзакции, диалоги и компоненты
Как TCAP структурирует прикладные обмены SS7: подуровень транзакций (Begin/Continue/End/Abort с идентификаторами транзакций), часть диалога (application context) и подуровень компонентов (Invoke, ReturnResult, ReturnError, Reject).
- MAP
Операции MAP: SRI-SM, ForwardSM, UpdateLocation и другие
Операции MAP, управляющие мобильными сетями: SendRoutingInfoForSM и MT-ForwardSM для SMS, UpdateLocation для роуминга, ProvideSubscriberInfo и AnyTimeInterrogation для местоположения — с их opcode из TS 29.002.
- Доставка SMS
Схема доставки MT-SMS через SS7, шаг за шагом
Полный путь SMS на абонента через SS7: SMSC к HLR SendRoutingInfoForSM, HLR возвращает IMSI + обслуживающий MSC, SMSC к MSC MT-ForwardSM, пейджинг и доставка, а также повтор для отсутствующего абонента через MWD и AlertServiceCentre.
- Адресация
Point code и сетевая адресация в SS7
Как SS7 адресует пункты сигнализации: 14-битные point code ITU-T против 24-битных ANSI, их структура зоны/сети, метка маршрутизации OPC/DPC/SLS и как point code соотносятся с global title SCCP.
- Безопасность
Угрозы безопасности SS7 и категории GSMA FS.11
Основные классы атак SS7 — отслеживание местоположения, перехват SMS/OTP, перенаправление вызовов и мошенничество — и как GSMA FS.11 классифицирует сообщения MAP (категории 1/2/3), чтобы сигнальные межсетевые экраны могли их фильтровать.
- Основы
SS7 против SIGTRAN: TDM-сигнализация поверх IP
Как SIGTRAN соотносится с классическим SS7: тот же прикладной уровень MTP3/SCCP/TCAP/MAP, но переносимый поверх IP с SCTP и M3UA (или SUA) вместо TDM-каналов MTP1/MTP2.
SIGTRAN
Сигнализация SS7, передаваемая по IP — M3UA, SUA и SCTP — является мостом между сигнализацией TDM и современными пакетными ядрами.
- Основы
Обзор SIGTRAN: сигнализация SS7 поверх IP
Что такое SIGTRAN: framework IETF (RFC 2719) для переноса сигнализации SS7 поверх IP с транспортом SCTP и уровнями адаптации (M3UA, SUA, M2PA), сохраняющими прикладной стек MTP3/SCCP/TCAP/MAP.
- Транспорт
SCTP: Stream Control Transmission Protocol
Как работает SCTP и почему SIGTRAN использует его: доставка, ориентированная на сообщения, мультипотоковость против блокировки в начале очереди, multi-homing для переключения путей, чанковый формат пакета и чем он отличается от TCP.
- Адаптация
M3UA: уровень адаптации пользователей MTP3
Как M3UA переносит SCCP и ISUP поверх SCTP: роли SG/ASP/AS, routing key и routing context, классы сообщений (Transfer, SSNM, ASPSM, ASPTM) и режимы IPSP против сигнального шлюза.
- Адаптация
Уровни адаптации M2PA и SUA
Ещё два уровня адаптации SIGTRAN: M2PA (RFC 4165) заменяет MTP2 для построения IP-каналов STP с полным MTP3, а SUA (RFC 3868) переносит пользователей SCCP (TCAP/MAP) прямо поверх SCTP, минуя MTP3.
- Архитектура
Архитектура развёртывания SIGTRAN: SG, ASP, AS
Как строится сеть SIGTRAN: сигнальный шлюз, соединяющий TDM и IP, серверы приложений и их процессы, ассоциации SCTP и режимы резервирования (override, load-share, broadcast), дающие доступность операторского класса.
SIP / VoIP
Протокол инициации сеанса (SIS), лежащий в основе программируемой голосовой связи, SIP-транкинга и управления вызовами VoLTE, а также медиатек, работающий параллельно с ним.
- Основы
Обзор протокола SIP
Что такое SIP и как он работает: текстовый протокол сигнализации запрос/ответ (RFC 3261), устанавливающий, изменяющий и завершающий медиасессии, его user agent, прокси и registrar, а также транзакции и диалоги.
- Запросы
Методы и запросы SIP
Каждый метод запроса SIP и что он делает: шесть основных методов RFC 3261 (INVITE, ACK, BYE, CANCEL, REGISTER, OPTIONS) и распространённые расширения (INFO, PRACK, UPDATE, SUBSCRIBE/NOTIFY, REFER, MESSAGE, PUBLISH).
- Ответы
Коды ответов SIP (1xx-6xx)
Шесть классов кодов ответов SIP и значимые из них: 1xx предварительные (100 Trying, 180 Ringing), 2xx успех (200 OK), 3xx перенаправление, 4xx ошибка клиента (404, 486), 5xx ошибка сервера и 6xx глобальный сбой.
- Сообщения
Заголовки SIP: Via, From, To, Call-ID, CSeq, Contact
Основные заголовки SIP и что они делают: Via (с параметром branch) для маршрутизации ответов, From/To с тегами, Call-ID, CSeq, Contact, Max-Forwards и как из них идентифицируются диалоги и транзакции.
- Медиа
SDP: Session Description Protocol
Как SDP описывает медиасессию внутри SIP: структура строк v=/o=/s=/c=/t=/m=/a=, модель offer/answer (RFC 3264), согласование кодеков через rtpmap и атрибуты направления медиа.
- Медиа
RTP и SRTP: медиапоток
Как текут медиа после того, как SIP установил вызов: заголовок и полезная нагрузка RTP, отчёты о качестве RTCP и шифрование и аутентификация SRTP с ключами через SDES или DTLS-SRTP.
- Схема вызова
Схема вызова SIP: от INVITE до BYE
Полный вызов SIP шаг за шагом: INVITE с предложением SDP, 100 Trying, 180 Ringing, 200 OK с ответом SDP, трёхстороннее ACK, медиа RTP и завершение BYE/200 OK — плюс как CANCEL прерывает звонящий вызов.
- Развёртывание
SIP-транкинг и пограничный контроллер сессий
Что такое SIP-транк и роль пограничного контроллера сессий (SBC): обход NAT с STUN/TURN/ICE, сокрытие топологии через B2BUA, безопасность и контроль допуска на границе сети и транскодирование.
DIAMETER
Протоколы AAA и сигнализации, лежащие в основе мобильности, политики и тарификации 4G/5G (S6a, Gx, Gy), управления IMS (Cx / Sh) и безопасности роуминга Diameter на границе IPX.
- Основы
Базовый протокол DIAMETER: разбор RFC 6733
Как работает базовый протокол DIAMETER по RFC 6733: 20-байтовый заголовок сообщения, коды команд и флаги R/P/E/T, обмен возможностями CER/CEA, watchdog DWR/DWA и отключение DPR/DPA поверх SCTP или TCP/TLS.
- Формат сообщений
AVP DIAMETER, типы данных и Result-Code
Анатомия AVP DIAMETER: код, флаги V/M/P, длина, опциональный Vendor-Id и данные; базовые типы данных (Enumerated, Unsigned32, OctetString, Address, Time); Grouped AVP; и модель ошибок Result-Code / Experimental-Result.
- Основы
DIAMETER против RADIUS: почему DIAMETER заменил RADIUS
Почему DIAMETER (RFC 6733) вытеснил RADIUS (RFC 2865) в операторском AAA: надёжный транспорт SCTP и failover, согласование возможностей, гораздо большее 32-битное пространство AVP, обнаружение пиров, богатая обработка ошибок и более сильная безопасность — со сравнительной таблицей и заметками о миграции.
- Мобильность (HSS)
DIAMETER S6a/S6d: мобильность LTE к HSS
Как мобильность LTE и управление подпиской работают поверх DIAMETER S6a (MME↔HSS) и S6d (SGSN↔HSS) по 3GPP TS 29.272: ULR/ULA, AIR/AIA, CLR/CLA, PUR/PUA и IDR/IDA, векторы аутентификации EPS-AKA и операции SS7 MAP, которые они заменяют.
- Политика и тарификация
DIAMETER Gx и Gy: контроль политики и тарификации
Как DIAMETER несёт контроль политики и тарификации: Gx (PCEF↔PCRF, CCR/CCA устанавливает правила PCC), Gy (онлайн-тарификация к OCS с квотой) и Rf (офлайн-тарификация к CDF) — плюс роли PCRF/PCEF/OCS/OFCS, QoS/QCI и интерфейсы Sy/Sd.
- IMS
DIAMETER Cx/Dx и Sh: регистрация IMS и HSS
Как регистрация и аутентификация IMS работают поверх DIAMETER Cx/Dx (S-CSCF/I-CSCF↔HSS) по 3GPP TS 29.228/29.229 — UAR/UAA, MAR/MAA, SAR/SAA, LIR/LIA — плюс интерфейс Sh (AS↔HSS) и как они связаны с SIP REGISTER.
- Безопасность
Безопасность роуминга DIAMETER: DRA, DEA и граница IPX
Как работают маршрутизация DIAMETER и безопасность межсоединений на границе роуминга: Diameter Routing Agent (DRA) и Diameter Edge Agent (DEA), маршрутизация по реалмам, классы угроз FS.19 (раскрытие информации, отслеживание местоположения, мошенничество), сокрытие топологии и фильтрация AVP.
Каналы обмена сообщениями
На уровне приложений предприятия используют следующие каналы обмена сообщениями: RCS Business Messaging / MaaP, WhatsApp Business Cloud API, MMS (MM1 / MM4 / MM7), проверенных и брендированных отправителей, а также оркестрацию резервных каналов.
- RCS
RCS Business Messaging и платформа MaaP
Как работает RCS Business Messaging: GSMA Universal Profile (RCC.07), архитектура Messaging-as-a-Platform (RCC.71), верифицированные агенты, определение возможностей, потоки MO/MT и события тарификации — и чем API агента RBM отличается от привязки SMPP.
- WhatsApp
Платформа WhatsApp Business: Cloud API и шаблоны
Как работает платформа WhatsApp Business: Cloud API против On-Premises API, шаблонные (HSM) сообщения против сессионных, 24-часовое окно клиентского обслуживания, категории marketing/utility/authentication, webhook, уровни качества номеров и получение согласия (opt-in).
- MMS
Архитектура MMS: интерфейсы MM1, MM4 и MM7
Как работает MMS по 3GPP TS 23.140 и OMA MMS: MMSC/relay-server, MM1 (телефон↔MMSC поверх WAP/HTTP), MM4 (MMSC↔MMSC поверх SMTP для межоператорского обмена), MM7 (VASP↔MMSC поверх SOAP/XML), контент MIME/SMIL, ограничения размера и A2P MMS.
- Доверие и брендинг
Верифицированные и брендированные отправители сообщений
Как бренды подтверждают свою идентичность в разных каналах: RCS Verified Sender и верифицированные бизнес-агенты, регистрация sender ID по GSMA и верификация бренда, а также сертификаты VMC с BIMI для верифицированных логотипов в электронной почте — средства контроля против подмены и выдачи себя за другого.
- Матрица выбора
RCS против SMS против WhatsApp: матрица выбора канала
Нейтральное к вендорам сравнение RCS, SMS и WhatsApp для бизнес-сообщений: функции, охват и покрытие, сквозное шифрование, отчёты о прочтении и индикатор набора, насыщенные медиа, модели стоимости, поведение отката и регуляторные ограничения — с рекомендациями, когда какой использовать.
- Оркестрация
Откат каналов и омниканальная оркестрация
Как омниканальная доставка каскадируется по каналам: проверки возможностей, откат RCS→SMS и WhatsApp→SMS, маршрутизация по наименьшей стоимости против наилучшего опыта, правила повторов и тайм-аутов и единое представление отчётов о доставке, сверяющее статус по всем каналам.
- Интерактив
Насыщенные карточки и интерактивные сообщения
Интерактивные строительные блоки RCS и WhatsApp: насыщенные карточки и карусели, предлагаемые ответы и действия, кнопки быстрых ответов и списки выбора — с примерами JSON-нагрузок для каждой платформы, а также рекомендации по UX и доступности.
Нумерация и идентификация
Уровень нумерации и идентификации, лежащий в основе каждого сообщения и вызова: коды E.164 / MSISDN, MCC-MNC / PLMN, идентификатор абонента IMSI / IMEI, ENUM (E.164 → URI) и маршрутизация переноса мобильных номеров.
- Публичная нумерация
Нумерация E.164 и MSISDN: разбор
Как работает международный план нумерации ITU-T E.164: коды стран, национальный код назначения (NDC) и абонентский номер, максимум в 15 цифр, структура MSISDN и как нормализовать номера к формату E.164 для A2P-сообщений.
- Идентичность сети
Коды MCC, MNC и PLMN: разбор (E.212)
Как работает план идентификации ITU-T E.212: 3-значный Mobile Country Code (MCC) и 2–3-значный Mobile Network Code (MNC), объединяющиеся в идентичность PLMN, как они идентифицируют домашнюю сеть, тестовые диапазоны и чем MCC-MNC отличается от NDC в составе MSISDN.
- Идентичность абонента
IMSI, IMEI и идентичность абонента: разбор
Идентичности, различающие абонента и устройство: IMSI (MCC+MNC+MSIN, E.212), IMEI (TAC+серийный номер), ключ аутентификации Ki, временные идентичности TMSI/GUTI, SIM/USIM/eSIM (eUICC) и как HLR сопоставляет MSISDN с IMSI.
- Маршрутизация номеров
ENUM: сопоставление номеров E.164 с URI
Как ENUM (IETF RFC 6116) сопоставляет телефонные номера E.164 с URI через DNS: домен e164.arpa с реверсом цифр, записи NAPTR с regexp-переписыванием и разница между публичным (пользовательским) и приватным (операторским/инфраструктурным) ENUM для маршрутизации SIP и VoIP.
- Маршрутизация номеров
Переносимость мобильных номеров и маршрутизация
Как переносимость мобильных номеров (MNP) разрывает связь между набранным номером и его домашней сетью: маршрутные номера (RN), All-Call-Query против Onward Routing, базы данных MNP и запросы к ним, и как HLR/MNP-поиск управляет маршрутизацией по наименьшей стоимости и надёжной доставкой.
HTTP API и вебхуки
Уровень HTTP/ REST над протоколами передачи данных: проектирование API для обмена REST -сообщениями, доставка веб-хуков и проверка подписи HMAC, статус/входящие данные, аутентификация и подписание, идемпотентность, ограничение скорости и ошибки problem+json — основано на стандартах (RFC 9457, проекты IETF).
- Проектирование API
Проектирование REST API сообщений: ресурсы, методы, коды состояния
Как моделируется REST API сообщений на основе стандартов: коллекция messages, HTTP-методы и семантика кодов состояния по RFC 9110, синхронная и асинхронная отправка (202 Accepted плюс status callback), согласование содержимого и версионирование в URL или заголовке — с таблицей сравнения REST и SMPP.
- Webhook
Доставка и надёжность webhook: повторы, порядок, dead-letter
Стандартная архитектура webhook/callback и её модель надёжности: доставка at-least-once, экспоненциальная выдержка с джиттером при повторах, тайм-ауты доставки, гарантии порядка, очереди dead-letter, идемпотентные потребители и здоровье эндпоинта / размыкание цепи для защиты отказавшего приёмника.
- Безопасность
Проверка подписи webhook: HMAC-SHA256 и защита от повторов
Как убедиться, что webhook подлинный и не подделан: HMAC-SHA256 над сырым телом, заголовки подписи и метки времени, защита от повторов с допуском по времени и nonce, сравнение за константное время против атак по времени и безопасная ротация секрета с перекрывающимися ключами.
- Webhook
Статус сообщения (DLR) и входящие (MO): полезные нагрузки webhook
Схемы полезной нагрузки двух ключевых callback сообщений: событие статуса доставки (DLR) с его message id, enum статуса, причиной ошибки и метками времени и событие входящего (MO) сообщения — плюс таксономия типов событий и то, как HTTP-DLR отображается на отчёт о доставке deliver_sm в SMPP.
- Безопасность
Аутентификация API и подпись запросов: токены, HMAC, OAuth, mTLS
Стандартные способы аутентификации HTTP API сообщений: bearer token и API-ключи в заголовке Authorization, подпись запросов через HMAC над каноническим запросом, ограничение области и ротация ключей, взаимный TLS и OAuth 2.0 client-credentials для доступа machine-to-machine.
- Надёжность
Идемпотентность и ограничение скорости: ключи, 429, Retry-After, RateLimit
Два HTTP-паттерна из стандартов для безопасных, дисциплинированных клиентов: заголовок Idempotency-Key (IETF-черновик) для отправки exactly-once с окном дедупликации и воспроизведением ответа и ограничение скорости — 429 с Retry-After, заголовки RateLimit / RateLimit-Policy (IETF-черновик), token bucket и обратное давление клиента.
- Проектирование API
Ошибки API (problem+json) и пагинация (cursor, заголовок Link)
Два стандарта, удерживающих HTTP API предсказуемым: RFC 9457 problem+json для машиночитаемых ошибок (type, title, status, detail, instance) с таксономией retryable/terminal и пагинация — cursor против offset, заголовок Link по RFC 8288 для next/prev и ограничения размера страницы.
От технических характеристик до готового изделия.
В этих документах описаны протоколы, которые BroadNet использует на уровне операторского класса с 2003 года — в 200+ странах и с 1000+ подключениями операторов. Когда вы будете готовы отправить данные, документы и инструменты ниже помогут вам пройти весь процесс от чтения до отправки.