Структура запроса#

Взаимодействие с платформой#

Взаимодействие сервиса Платформы RCS с сервисом Партнера осуществляется на базе SMPP-протокола (версия 3.4).

Для отправки сообщения абоненту сервис Партнёра устанавливает соединение с сервером Сервис-провайдера и передает пакет submit_sm, котрый содержит все необходимые параметры сообщения, в т.ч. TLV-параметры (опционально).

Сервис-провайдер принимает пакет, обрабатывает его, отправляет сообщение абоненту и отвечает Партнёру пакетом submit_sm_resp.

Для получения статуса доставки используются отдельные пары пакетов deliver_sm и deliver_sm_resp (см. Сервис получения статусов доставки).

Для достижения максимальной производительности при отправке сообщений от Партнёра к Сервис-провайдеру рекомендуется:

  • использовать двухсокетный SMPP (transmitter/receiver);

  • использовать несколько параллельных соединений с одним логином допустимо, но следует учитывать, что с точки зрения SMPP-сервера они все равнозначны

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

  • при отправке длинных сообщений передавать все сообщение целиком в одном PDU с использованием message_payload;

  • вести отправку сообщений в асинхронном режиме с ограниченным буфером передачи:

    • отправлять в сокет следующую PDU submit_sm, не ожидая получения submit_sm_resp на предыдущую;

    • при этом нужно следить, чтобы общее количество отправленных в сокет PDU, на которые ответы ещё не получены, не превышало установленных значений (в зависимости от качества сетевого канала между клиентом и сервером. Рекомендуемый диапазон данного значения: от 5 до 50).

Установка соединения#

Для установки соединения в различных режимах используются пакеты BIND: bind_transmitter / bind_receiver / bind_transceiver.
SMPP-сервер Сервис-провайдера не анализирует следующие параметры:

  • system_type;

  • interface_version;

  • addr_ton;

  • addr_npi;

  • address_range;

  • source_addr_ton;

  • source_addr_npi;

  • dest_addr_ton;

  • dest_addr_npi.

В ответ на запрос установления соединения сервер Сервис-провайдера отправляет один из следующих PDU: bind_transmitter_resp / bind_receiver_resp / bind_transceiver_resp.
Возможные значения возвращаемых ошибок приведены в таблице.

Код ошибки

Описание

0x00

Успешная аутентификация.

0x0F

Неверный идентификатор сервиса (логин).

0x0E

Неверный пароль.

0x05

Превышен лимит количества одновременно доступных активных соединений с сервером.

0x0D

Попытка соединения с неразрешенного IP-адреса.

Поддержание соединения#

Для поддержания соединения в периоды отсутствия трафика используются PDU enquire_link. Сервер посылает пакет enquire_link раз в минуту, если за этот период по соединению не было никакого трафика.
При отсутствии в течение 30 секунд (время настраивается на платформе Сервис-провайдера) адекватного ответа от клиента (PDU enquire_link_resp) сервер разрывает соединение без отправки пакета unbind.
Клиент также может в любой момент времени отправить в сторону Сервера пакет enquire_link и ожидать незамедлительного ответа enquire_link_resp.

Повторная обработка сообщений#

Если сервис Партнёра не отвечает на запросы Сервис-провайдера:

  1. Сервис помечается как «неработающий». Все сообщения, поступившие Сервис-провайдеру и предназначенные для данного сервиса, помещаются в очередь отложенных. Сервис будет неработающим, пока Партнер не подключится заново.

  2. Всем абонентам, обратившимся к неработающему сервису, высылается сообщение о недоступности сервиса и задержке в оказании услуг (только в случае, если для сервиса настроена подобная опция).

  3. Количество попыток отправки сообщения указывается в настройках интеграционного подключения, в параметре «Макс. кол-во попыток отправить МО-сообщение», который может принимать любое целое значение. Если значение не указано или равно 0, то система будет пытаться произвести отправку, пока не истечет время жизни сообщения.