Протокол SMPP

SMPP — протокол, описывающий взаимодействие клиента с SMS-сервером платформы для передачи SMS и USSD сообщений.

Внимание

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

Точка доступа

Взаимодействие клиента с SMS-сервером платформы осуществляется по адресам:

• smpp01.integrationapi.net (194.226.179.12) – основной адрес для рекламных рассылок.
• smpp02.integrationapi.net (194.226.179.13) – резервный адрес для рекламных рассылок.
• smpp03.integrationapi.net (194.226.179.10) – основной адрес для транзакционных рассылок.
• smpp04.integrationapi.net (194.226.179.11) – резервный адрес для транзакционных рассылок.

Проверка доступного баланса осуществляется через личный кабинет клиента.

Настройка SMPP-клиента

Для работы с платформой по протоколу SMPP необходимо произвести следующие настройки SMPP-клиента:

Host: 194.226.179.12
Port: 2775

Обязательные параметры

Название	Значение	Описание
System_ID	Пользовательское	Логин, присвоенный клиенту.
Password	Пользовательское	Пароль, присвоенный клиенту.
Interface_Version	0x34	Версия SMPP.
System_Type	NULL	Тип системы SMSC. Используется пустое значение (NULL).
Src_Addr_TON	0x05	Тип адреса источника.
Src_Addr_NPI	0x01	Нумерация адреса источника.
Dest_Addr_TON	0x01	Тип адреса назначения.
Dest_Addr_NPI	0x01	Нумерация адреса назначения.

Пример

System_ID: client_login
Password: client_password
Interface_Version: 0x34
System_Type: NULL
Src_Addr_TON: 0x05
Src_Addr_NPI: 0x01
Dest_Addr_TON: 0x01
Dest_Addr_NPI: 0x01

Описание взаимодействия

Функциональность:

• Протокол работы сервиса SMPP 3.4 (TCP/IP/SMPP).
• Сервис работает в асинхронном режиме. Размер окна определяется клиентом, количество сессий может доходить до четырех.
• Каждая сессия может работать в любом из режимов:
  • tx (transmitter) - только отправка
  • rx (receiver) - только прием отчетов
  • trx (transceiver) - прием/передача в одной сессии
• Платформа поддерживает запросы query_sm, скорость отправки запросов и окно устанавливаются клиентом.

Отправка и получение сообщений:

• При получении сообщения отправлять на каждый принятый Deliver_sm подтверждение Deliver_sm_resp (Data_sm_resp) всегда со статусом 0 (ok). Generic_nack не допускаются. В случае отправки будет произведен сброс сессии путем отправки пакета unbind.
• Отправлять запрос Enquire_link следует только в случае отсутствия приёма любых SMPP PDU со стороны SMSC в течение 60 секунд. При отсутствии ответа от SMSC (Enquire_link_resp) следует закрывать SMPP сессию командой Unbind.
• Сообщения, состоящие более чем из одной части, должны разбиваться на стороне клиента (кроме отправки через Message Payload) одним из методов отправки составных сообщений:
  • Использование опционных параметров (SAR-метод)
  • Использование UDH
• Отправка через Message Payload - разбивка происходит на стороне SMS-центра. Тарификация сообщений будет проводиться по сформированным сегментам. В данном случае отчет о доставке будет отправлен только на одну (первую) часть.
• UDH-заголовок должен занимать 6 байт.
• В одной части составного сообщения можно передавать 66-67 символов в кириллице и 150-153 в латинице (поле message_length должно быть 132-134 байта).
• Если сервис использует более одного sys_id (несколько аккаунтов), то для корректной склейки все части разбитого сообщения должны отсылаться через один и тот же sys_id (через один и тот же аккаунт).
• Параметр validity_period должен быть не менее 60 секунд. Возможны ограничения доставки сообщений с указанием меньшего периода.
• После обрыва сессии по SMPP и TCP/IP необходимо выдержать таймаут не менее 60 секунд, только после этого можно устанавливать TCP/IP сессию и отправлять PDU Bind_transceiver. В случае неудачной попытки соединения таймаут увеличивается до 90 секунд.

Ошибки:

• При получении ошибки Invalid Destination Address сообщение необходимо удалить из своей очереди и не посылать данное сообщение снова.
• При получении ошибки Throttling error сообщение нужно вернуть в очередь, но необходимо выдержать таймаут на данном соединении в течение 1 секунды.
• При получении ошибки Message Queue Full необходимо поставить сообщение, на которое вернулась данная ошибка, в конец очереди. Затем необходимо сделать еще 3-5 попыток доставки этого сообщения, каждый раз возвращая это сообщение в конец очереди при получении той же ошибки. Рекомендуется применять прогрессивный метод обработки этой ошибки – при первом получении делать паузу перед отправкой в 5 секунд, при второй – 15, третьей – 45 и так далее.