smpp протокол что это
Проблемы SMPP-протокола
В мире сложно найти что-либо идеальное. Протокола SMPP также не лишен некоторых изъянов. Опишу свои проблемы с этим протоколом. Надеюсь кому-то это поможет в принятии правильных решений.
Первый, самый проблемный недостаток: потеря message_id при разрыве соединения. Страдают от этого операции отправки (submit_sm и т.п.) для которых не успел прийти ответ. Протокол не содержит встроенных средств восстановления утерянных идентификаторов. Как следствие, когда придет статус сообщения, его не к чему привязать. Более того, неизвестно принял ли это сообщение SMSC.
Если обмен осуществляется в синхронном режиме, то потеряется только одно сообщение. Но если работа производится в асинхронном режиме, тогда потери могут быть существенными.
Этот недостаток SMPP, пожалуй, единственный нерешаемый средствами протокола из тех, которые я могу припомнить. Проблема, конечно, решается но не стандартизованными методами.
Остальные недостатки связаны с проблемами реализации. Их решении, как правило, заключается в достижении договоренности между SMSC и SMPP-клиентом и не выходит за рамки спецификации.
Второй недостаток, который мне сильно досаждает, связан с отчетам о доставке deliver_sm. В версии протокола 3.4 нет строго определения как должна передаваться статусная информация. С одной стороны есть необязательная структура TLV в которой в жестко типизированной форме передается message_state и сопутствующие параметры. Это вариант хорош, за исключением того, что SMSC не сможет выслать в этой структуре какой-нибудь пространный комментарий. Но, повторюсь, нигде этот способ не указан как обязательный (MUST). Зато в приложении к протоколу приведен пример. Подчеркиваю: ПРИМЕР. Даже не рекомендация. Пример того, как SMSC может сообщать статусную информацию через (о боже, кто это придумал. ) поле short_message. Т.е. в текстовом виде, странные сокращения, дикие форматы и т.д.
Вообще, это ситуация выбора одного из возможных вариантов (MAY). По моим представления о реализации протоколов выбор одного из разрешенных протоколом варианта — прерогатива формирующей пакет стороны. В данном случае с пакетом отчета это SMSC. А принимающая сторона обязана правильно обработать любой пакет соответствующий протоколу. Но суровая реальность говорит, что прав тот кто платит. Подавляющее большинство SMPP-клиентов понимают только поле short_message.
Славо богу из спецификации пятой версии протокола убрали эту мину (приложение), но найдите-ка SMPP-клиентов пятой версии.
Третий недостаток — передача длинных сообщений. Спецификация ненавязчиво ссылается на стандарт [GSM 03.40] Technical Realisation of the Short Message Service Point to Point». Так ненавязчиво, что замечаешь ссылку только когда ищешь специально. Ссылка на этот стандарт приведена в разделе 1.4 References спецификации версии 3.4.
Вопрос: поле short_message предполагается протоколом использовать только в соответствии с GSM 03.40? GSM 03.40 предлагает длинный текст сообщения разбивается на серию конкатенированных sms, снабженных UDH-заголовками. Спецификация SMPP неявно подстегивает на свободное использование — длина поля 254 октетов. Это две sms латиницей или почти четыре sms кириллицей.
Читаем внимательно спецификацию SMPP:
4.4.1 “SUBMIT_SM” Syntax
«… Up to 254 octets of short message user data. The exact physical limit for short_message size may vary according to the underlying network… »
Т.е. ограничения накладываются передающей сетью (underlying network). В нашем случае underlying network описывается GSM 03.40. Следовательно 140 байт данных. Зачем же такое длинное поле? Дело в том что использоваться может 7-bit кодировка, тогда символов уже 160. short_message это текстовое поле измеряющееся в октетах, а не бинарное в байтах. Возможно, создатели закладывались и на другие, более изощренные варианты.
Разработчик SMPP-клиента по понятным причинам хочет упростить себе задачу. И не стремится на своей стороне связываться c конкатенированными SMS. В соответствии с протоколом SMSC МОЖЕТ предоставлять такую услугу через поле message_payload (самостоятельно делить сообщение на смски, снабжать заголовками ) в форме по своему выбору (не стандартизировано). Но по протоколу не обязан. Да и применять это можно без страха только к обычным текстовым сообщениям. С точки зрения бизнеса вопрос тоже скользкий — как тарифицировать такие сообщения? А что если не все части сообщения имеют статус доставлено?
Четвертые недостаток связан с относительным форматом времени. Относительного чего отмерять указанное время? Когда нет задержек ни на клиенте ни на SMSC и между ними хорошая связь, вопросов, как правило, не возникает. Но если в каком-то месте появляется задержка, то точки отсчета времени клиента и SMSC существенно расходятся.
Для schedule_delivery_time в разделе 5.2.15 уточняется:
«..relative time from the current SMSC time at which delivery of this message will be attempted by the SMSC..»
Но проблему разных точек отсчета это не решает.
Smpp протокол что это
SMPP Protocol: API to enable SMS messaging between applications and mobiles.
The SMPP (Short Message Peer-to-Peer) protocol is an open, industry standard protocol designed to provide a flexible data communications interface for the transfer of short message data between External Short Message Entities (ESME), Routing Entities (RE) and Message Centres (MC). It is a means by which applications can send SMS messages to mobile devices and receive SMS from mobile devices. This is done using an SMPP connection with a Short Message Service Center (SMSC), SMS gateway (UK), SMPP gateway or hub.
SMPP API Overviews
Ancillary documents
SMPP Specifications
There are three versions of the SMPP protocol specification in use. The original public version of the specification is SMPP v3.3 and was released in 1997. This was updated in 1999 to SMPP v3.4. The final version was released in 2003 and is SMPP v5.
SMPP v3.3
SMPP v3.4
SMPP v5
Short Message Service (SMS)
Developers
SMPP Protocol Overview
What is SMPP?
The SMPP (Short Message Peer-to-Peer) protocol is an open, industry standard protocol designed to provide a flexible data communications interface for the transfer of short message data between External Short Message Entities (ESME), Routing Entities (RE) and Message Centres (MC). It is a means by which applications (termed ESMEs) can send SMS messages to mobile devices and receive SMS from mobile devices.
It can also be used as an API for use with USSD, CBC and other mobile services.
Supported Cellular Technologies
SMPP is designed to support short messaging functionality for any cellular technology and has specific applications and features for technologies such as: GSM, UMTS, LTE, IS-95 (CDMA), CDMA2000 (1xRTT & 3xRTT), ANSI-136 (TDMA), iDEN
Typical Applications of SMPP
The variety of messaging applications, particularly using SMS, for which SMPP can be employed is almost boundless. Mobile Operators, Message Centre vendors, Infrastructure Providers, and application developers are continually developing new applications for SMS. SMPP is ideal as an access protocol for these applications. The following summarises typical applications of SMPP:
SMPP Sessions
In order to make use of the SMPP Protocol, an SMPP session must be established between the ESME and Message Centre or SMPP Routing Entity where appropriate. The established session is based on an application layer TCP/IP connection between the ESME and MC/RE and is usually initiated by the ESME. The connection is often over the Internet and can use SMPP over TLS or a VPN to secure the connection. SMPP has been assigned TCP port 2775 by IANA, however other port numbers are often used.
There are three forms of ESME-initiated session:
Additionally, the Message Centre can establish an SMPP session by connecting to the ESME. This is referred to as an Outbind Session.
Protocol Operations and PDUs
The SMPP protocol is a set of operations, each one taking the form of a request and response Protocol Data Unit (PDU) containing an SMPP command. For example, if an ESME wishes to submit a short message, it may send a submit_sm PDU to the MC. The MC responds with a submit_sm_resp PDU, indicating the success or failure of the request. Likewise, if an MC wishes to deliver a message to an ESME, it may send a deliver_sm PDU to an ESME, which in turn responds with a deliver_sm_resp PDU as a means of acknowledging the delivery.
Some operations are specific to an ESME with others specific to the MC. Others may be specific to a given session type. Referring to the submit_sm and deliver_sm examples above, an ESME may send a submit_sm to an MC only if it has established a TX or TRX session with that Message Centre. Likewise, an MC may send deliver_sm PDUs only to ESMEs that have established RX or TRX sessions.
Operations are broadly categorised into the following groups:
SMPP PDU Example: Send SMS (submit_sm / submit_sm_resp)
submit_sm
| Bytes | Field | Meaning |
|---|---|---|
| PDU header | ||
| 00000048 | Length | 72 bytes |
| 00000004 | Command ID | SUBMIT_SM |
| 00000000 | Command Status | n/a |
| 00000002 | Sequence Number | 2 |
| PDU body | ||
| 00 | Service Type | null (none specified) |
| 05 | Source Address TON | Alphanumeric |
| 00 | Source Address NPI | None / Unknown |
| 4d656c726f73654c61627300 | Source Address | MelroseLabs |
| 01 | Destination Address TON | International |
| 01 | Destination Address NPI | ISDN |
| 34343737313233343536373800 | Destination Address | 447712345678 |
| 00 | ESM Class | 0 |
| 00 | Protocol ID | 0 |
| 00 | Priority Flag | 0 |
| 00 | Schedule Delivery Time | Deliver immediately |
| 00 | Validity Period | SMSC default validity |
| 01 | Registered Delivery | SMSC delivery receipt requested |
| 00 | Replace If Present Flag | 0 |
| 00 | Data Coding | Default character set |
| 00 | Short Message Default Msg ID | 0 |
| 10 | Short Message Length | 16 bytes |
| 48656c6c6f20576f726c64201b650201 | Short Message | Hello World €$£ |
Message is using Data Coding of 0 (i.e. the MC’s default character set) which in this case is configured on the MC to be the GSM character set. Message encoding has following meaning:
| Hello World | SP | € | $ | £ |
|---|---|---|---|---|
| 48656c6c6f 20 576f726c64 | 20 | 1b 65 | 02 | 01 |
submit_sm_resp
| Bytes | Field | Meaning |
|---|---|---|
| PDU header | ||
| 00000051 | Length | 81 bytes |
| 80000004 | Command ID | SUBMIT_SM_RESP |
| 00000000 | Command Status | n/a |
| 00000002 | Sequence Number | 2 |
| PDU body | ||
| 30393537326130613039626337336632 65393065393338626336656138636132 64636630636434356234303938316534 36323966383430353535343765613331 00 | Message ID | |
SMPP Commands
The following is a list of all SMPP commands:
| Command ID | Value | Purpose |
|---|---|---|
| bind_receiver | 0x00000001 | Establish a receiver bind. |
| bind_receiver_resp | 0x80000001 | |
| bind_transmitter | 0x00000002 | Establish a transmitter bind. |
| bind_transmitter_resp | 0x80000002 | |
| query_sm | 0x00000003 | Query status of previously submitted message. |
| query_sm_resp | 0x80000003 | |
| submit_sm | 0x00000004 | Submit message to the Message Center for onward delivery to mobile / short message entity (SME). |
| submit_sm_resp | 0x80000004 | |
| deliver_sm | 0x00000005 | Send message to ESME from MC (typically delivery receipt or mobile originated SMS). |
| deliver_sm_resp | 0x00000005 | |
| unbind | 0x00000006 | Unbind from MC and close SMPP session. |
| unbind_resp | 0x00000006 | |
| replace_sm | 0x00000007 | Replace a previously submitted message that is pending delivery. |
| replace_sm_resp | 0x00000007 | |
| cancel_sm | 0x00000008 | Cancel delivery of previously submitted message(s). |
| cancel_sm_resp | 0x00000008 | |
| bind_transceiver | 0x00000009 | Establish a transceiver bind. |
| bind_transceiver_resp | 0x80000009 | |
| outbind | 0x0000000B | Request ESME to bind (sent by MC). |
| outbind_resp | 0x8000000B | |
| enquire_link | 0x00000015 | Initiate a check to confirm ESME/MC is still reachable. |
| enquire_link_resp | 0x80000015 | |
| submit_multi | 0x00000021 | Submit message to the Message Center for onward delivery to multiple mobiles / short message entities (SME). |
| submit_multi_resp | 0x80000021 | |
| alert_notification | 0x00000102 | Indicate to ESME that mobile subscriber has become available. |
| data_sm | 0x00000103 | Submit packet to MC for onward delivery to SME or from MC to ESME. |
| data_sm_resp | 0x80000103 | |
| broadcast_sm | 0x00000111 | Submit message to the Message Center for onward delivery to mobiles in a specified geographical area or set of areas. |
| broadcast_sm_resp | 0x80000111 | |
| query_broadcast_sm | 0x00000112 | Query status of previously submitted broadcast message. |
| query_broadcast_sm_resp | 0x80000112 | |
| cancel_broadcast_sm | 0x00000113 | Cancel delivery of previously submitted broadcast message. |
| cancel_broadcast_sm_resp | 0x80000113 | |
| generic_nack | 0x80000000 | Acknowledge unrecognized or corrupt PDU. |
| Reserved | 0x00010200-0x000102FF 0x80010200-0x800102FF | Reserved for MC vendors to define |
SMPP Error Codes (partial list)
The following is a list of SMPP error codes (command_status and error_status_code):
This domain was acquired in June 2019 for the purpose of being a source of reference for the Short Message Peer-to-Peer (SMPP) protocol. The objective is to return this domain back to being the main reference for SMPP. The site will include the SMPP specifications, tools and other related resources.
This domain was originally the home of the SMPP Developers Forum / SMPP Forum that later became the now disbanded SMS Forum. This site has no association with any legal owner of the protocol or successor organisation.
Пример реализации отправки sms через протокол SMPP v 3.4
После получения необходимых реквизитов от провайдера: таких как логин, пароль, сетевой адрес, номер порта и небольшого томика документации, стало понятно, что дело придется иметь с так называемым сетевым протоколом SMPP v 3.4.
Надо признаться, что до этого момента у меня не было опыта работы с каким-либо сетевым протоколом, и кроме языка 1С уровня программиста-внедренца, более никаким программным языком не владею.
ActiveХ: Winsock
Из википедии. Windows Sockets API (WSA), название которого было укорочено до Winsock. Это техническая спецификация, которая определяет, как сетевое программное обеспечение Windows будет получать доступ к сетевым сервисам, в том числе, TCP/IP. Он определяет стандартный интерфейс между клиентским приложением (таким как FTP-клиент или веб-браузер) и внешним стеком протоколов TCP/IP. Он основывается на API модели сокетов Беркли, использующейся в BSD для установки соединения между программами.
Для установки и регистрации в ОС Windows необходмых файлов данной компоненты воспользовался советом и просто установил на компьютер пакет http://www.microsoft.com/ru-ru/softmicrosoft/VisualStudioExpress.aspx
После установки пакета (я установил версию visual basic 2012 express) появилась возможность разместить на форме winsock компоненту и использовать ее свойства и методы.
Рис. 1 Расположение компоненты
Рис. 2 Методы winsock
Первым шагом алгоритма будет процедура инициализации настроек и выполнение метода подключения
Для сборки PDU используем многомерный массив 1С COMSafeArray.
Клиент обязан отвечать на все пакеты отправленные сервером соответствующим resp пакетом в течение 1 минуты. Иначе соединение будет разорвано сервером без отсылки UNBIND.
После установки подключения и авторизации сервер будет отправлять ENQUIRE_LINK пакеты каждую минуту. На этот пакет клиент также обязан ответить в течение 1 минуты.
Методом DataArrival() принимаем и обрабатываем входящие пакеты:
После того как клиент и сервер успешно обменялись пакетами ENQUIRE_LINK можно отправить текст смс-сообщения
В правилах хорошего тона будет считаться отправка UNBIND пакета, если канал связи вы больше не будете использовать.
Преимущества использования SMPP протокола
Для отправки коротких сообщений между двумя равнозначными узлами обычно используется отрытый протокол SMPP (Short Message Peer to Peer). Принцип его работы схож с протоколом HTTP, но, в отличие от последнего, SMPP подразумевает постоянное подключение к серверу, отсутствие запросов и периодических отключений от канала передачи данных.
Как результат, отправка сообщений происходит практически мгновенно. Правда, провайдеры смс-услуг могут искусственно ограничивать скорость протокола для распределения и оптимизации ресурсов, что приводит к непредвиденным задержкам и ошибкам при отправке SMS, но это уже политика конкретной компании, а не ограничения технологии.
Сила протокола SMPP заключается не только в скорости работы, но и в универсальности. Он способен работать с любыми типами сообщений, включая EMI/UCP и Unicode. SMPP поддерживает три типа соединений:
Протокол SMPP позволяет провайдерам расширять список стандартных параметров, перечисленных в спецификации. За счет этого SMPP сервер способен работать в качестве сервера для других приложений, а не только для сервиса SMS. В любом случае, передача сообщений между SMS-сервером клиента и SMS-центром провайдера GSM услуг осуществляется через сеть Интернет. Возможна работа и через защищенное IP-соединение.
Применение SMPP протокола целесообразно в тех случаях, когда количество отправляемых сообщений превышает 100 sms/час. По SMPP сообщения передаются намного быстрее, чем через аналогичные протоколы, что позволяет работать с большим количеством подключенных клиентов, не опасаясь за стабильность функционирования IT-инфраструктуры. Не стоит забывать о возможности добавления произвольной информации в строку «номер отправителя» (максимум – 11 знаков). У получателя сообщения введенная информация будет отображаться в строке «Сообщение от:». Таким образом, компания-отправитель получает возможность выделить свои сообщения и поддерживать высокий уровень обслуживания клиентов.
Интеграция с сервисом (API)
API позволяет рассылать сообщения через ваши проекты и сервисы по протоколам HTTP/HTTPS, SMTP и SMPP. Готовые библиотеки на разных языках программирования подключаются к вашему проекту и помогают отправлять сообщения из любого места с помощью одной команды.
SMPP протокол
Подключение
Через наш SMS-шлюз возможно отправлять сообщения по протоколу SMPP версий 3.4 и 5.0.
Для получения доступа по SMPP-протоколу необходимо включить в настройках в группе «Настройки API» соответствующую опцию и добавить IP-адреса, с которых будете выполнять подключение, на этой странице.
Адрес SMPP-сервера: smpp.smscentre.com, порт: 3700.
Для шифрованного SSL-подключения используется порт 3443.
Адрес резервного SMPP-сервера: smpp2.smscentre.com.
Пример настроек для подключения (формат kannel): group = smsc
smsc = smpp
smsc-id = smsc
host = smpp.smscentre.com
port = 3700
smsc-username =
smsc-password =
system-type = «»
interface-version = 34
source-addr-autodete ct = yes
source-addr-ton = 5
source-addr-npi = 1
dest-addr-ton = 1
dest-addr-npi = 1
validityperiod = 1440
transceiver-mode = true
receive-port = 0
enquire-link-interva l = 60
wait-ack-expire = 0
max-pending-submits = 300
throughput = 30
Максимально возможный интервал бездействия составляет 2 минуты. В течение этого времени Клиенту необходимо отправить сообщение или выполнить пустую команду ENQUIRE_LINK, иначе соединение будет разорвано из-за не активности.
Логин используется от личного кабинета, пароль должен быть создан на странице Пароли для доступа. Логин и пароль не должны быть на русском языке.
Данный раздел содержит только краткое описание SMPP-протокола. Подробности смотрите в спецификации.
Скачать спецификацию протокола SMPP v3.4 smpp34.zip (500 Кб) smpp34rus.zip (1,1 Mб).
Скорость рассылок
Пропускная способность подключения или количество отправляемых каждую секунду SMS-сообщений зависит от размера окна передачи (smpp window size). В примере настроек данный параметр называется max-pending-submits. Для массовых рассылок лучше задавать большие значения (1000-2000). Также в примере параметр throughput задает ограничение на максимальное количество SMS-сообщений в секунду.
Вместе с массовыми рассылками через одно подключение можно отправлять и срочные одиночные SMS-уведомления. Система установит максимальный приоритет таким сообщениям и отправит их раньше любых массовых рассылок без ожидания в очереди.
При массовой отправке сообщений не стоит забывать о системе контроля скорости отправки сообщений в секунду, при превышении которой происходит генерация ошибки превышения скорости (throttling). В случае получения данной ошибки Клиенту по SMPP-стандарту необходимо повторить отправку, снизив общую скорость на своей стороне. По умолчанию скорость задана 30 SMS/cек для каждого аккаунта. Для изменения максимально разрешенной скорости необходимо отправить запрос в службу поддержки сервиса.
Множественные подключения
По умолчанию сервер обрабатывает одновременно с одного логина только одно подключение для более корректной отдачи статусов, поэтому при повторном подключении ранее подключенное соединение с таким же логином будет автоматически завершаться. Если же необходимо иметь несколько одновременных подключений для повышения скорости отправки, то можно в настройках всех подключений задать следующий параметр (multi connection):
system-type = «MCON2»
или
system-type = «MCON9» Значение после MCON может быть от 1 до 9 и задает количество одновременных подключений.
Также возможны одновременные подключения с разными логинами, привязанными к одному личному кабинету и счету. Для этого необходимо создать в личном кабинете в разделе «Реселлер» дополнительные аккаунты с необходимым типом субаккаунта.
Отправка SMS-сообщения
Для отправки SMS-сообщения используйте команду SUBMIT_SM согласно спецификации.
Для использования кодировки ISO-8859-1 (ASCII) вместо GSM при подключении нужно указать:
system-type = «ISO»
В текст SMS-сообщения можно добавлять комментарии, предназначенные для просмотра отправителем истории сообщений в личном кабинете.
Команда SUBMIT_MULTI для множественной рассылки пока не реализована.
Сервер не принимает более одного одинакового запроса на отправку SMS-сообщений в течение минуты для защиты от ошибок и зацикливаний в программе на стороне Клиента для того, чтобы снизить нагрузку и не расходовать средства Клиента, а также не допустить многократной отправки сообщения одному абоненту.
Сервер также блокирует отправку более 50 сообщений одному абоненту, которые были отправлены с перерывом между сообщениями менее 30-ти секунд, для защиты от флуда и лишнего списания средств со счета Клиента, так как многие операторы не пропускают большое количество сообщений одному абоненту за короткий промежуток времени.
Комментарии в SMS-сообщениях
При отправке SMS-сообщений можно добавлять в конец текста любой комментарий, уточняющий либо дополняющий SMS-сообщение для отправителя. Данный текст не будет отправляться абонентам и влиять на стоимость SMS и доступен для просмотра и фильтрации в списке отправленных сообщений в личном кабинете.
Для добавления комментария необходимо в конце текста SMS-сообщения, предназначенного для отправки, указать специальную комбинацию «\n
\n» (перевод строки, 3 символа тильды и снова перевод строки), и после этого любой текст, который будет считаться комментарием, не будет отправлен абоненту, но отобразится в истории.
Отправка MMS-сообщения
Отправка e-mail сообщения
Отправка голосового сообщения (звонок)
Для отправки голосового сообщения используйте команду SUBMIT_SM с текстом «__CALL__: \nvoice: » (текст «__CALL__», двоеточие, пробел, текст сообщения, перевод строки, слово «voice», двоеточие, голос, используемый для озвучивания текста).
\n» (перевод строки, 3 символа тильды и снова перевод строки), после которой передать параметр param, определяющий некоторые характеристики звонка (более подробно можно посмотреть в описании).
Отправка viber-сообщения
Для отправки viber-сообщения используйте команду SUBMIT_SM с текстом «__VIBER__: » (текст «__VIBER__», двоеточие, пробел, текст сообщения).
При формировании текста сообщения можно использовать специальные макросы для создания кнопки, при нажатии на которую будет происходить открытие браузера и переход по указанной в макросе ссылке, а также прикреплять файлы. Более подробно дополнительные возможности при отправке viber-сообщений описаны в документации к http-протоколу.
Отправка soc-сообщения
Для отправки soc-сообщения, отправляемого пользователям социальных сетей «Одноклассники», «ВКонтакте» или пользователям «Mail.Ru Агент», используйте команду SUBMIT_SM с текстом «__SOC__: » (текст «__SOC__», двоеточие, пробел, текст сообщения).
Отправка HLR-запроса
Для отправки HLR-запроса используйте команду SUBMIT_SM с текстом __HLR__. Результат запроса приходит в обычном статусе (Delivery Report), который можно получить как по SMPP-подключению, так и по HTTP на свой обработчик.
Формат статуса с результатом HLR-запроса, возвращаемого по SMPP: id: stat: err: imsi: msc: mcc: mnc: cn: net: rcn: rnet:
Описание параметров:
| Параметр | Значение |
|---|---|
| id | Идентификатор сообщения. |
| status | Статус сообщения. |
| err | Код ошибки, если абонент недоступен (список). |
| imsi | Уникальный код IMSI SIM-карты абонента. |
| msc | Номер сервис-центра оператора, в сети которого находится абонент. |
| mcc | Числовой код страны абонента. |
| mnc | Числовой код оператора абонента. |
| cn | Название страны регистрации абонента. |
| net | Название оператора регистрации абонента. |
| rcn | Название роуминговой страны абонента при нахождении в чужой сети. |
| rnet | Название роумингового оператора абонента при нахождении в чужой сети. |
Строковые данные, например, страна и оператор, закодированы через функцию urlencode.
Проверка статуса
Получать статус доставки отправленного SMS-сообщения по SMPP-протоколу можно как в автоматическом режиме, получая от сервера ответную PDU-команду DELIVER_SM сразу после изменения статуса, так и по запросу отдельной командой QUERY_SM. Для автоматического получения статуса по SMPP-протоколу необходимо подключаться в режиме transceiver или receiver и при отправке SMS указывать флаг запроса статуса (registered_delivery). Если при отправке не указывать данный флаг, то статусы сообщений будут передаваться на HTTP-обработчик.
При автоматическом возврате статуса в команде DELIVER_SM передаются стандартные TLV-параметры receipted_message_id ( ), message_state (числовой ) и network_error_code ( ), а также дополнительные TLV-поля с кодами 0x2000 и 0x2001, содержащие информацию о стоимости и типе сообщения:
| Имя (код) поля | Размер | Тип | Описание |
|---|---|---|---|
| 8192 (0x2000) | Var. max 6 | COctet String | Стоимость сообщения в формате «n.nnnn». |
| 8193 (0x2001) | 2 | Integer | Флаг в виде 2-х байтового числа, содержащий различную информацию о сообщении. Возможны комбинации значений битов разных характеристик. Биты 0-3 (тип сообщения): Бит 5 – оплата сообщения со второго баланса. |
Также в команде DELIVER_SM передается текст статуса в следующем формате:
id: sub: dlvrd: submit date: done date: stat: err:
Описание параметров:
| Параметр | Значение |
|---|---|
| id | Идентификатор сообщения, назначенный сервером при отправке. |
| sub | Количество SMS частей в отправленном сообщении. |
| dlvrd | Количество доставленных SMS. |
| submit date | Дата отправки. |
| done date | Дата изменения статуса. |
| status | Статус сообщения в виде строки (DELIVRD, EXPIRED, UNDELIV). |
| err | Код ошибки, если сообщение не может быть доставлено (список). |
Пример результата строки статуса (Delivery Report): id:854019 sub:001 dlvrd:001 submit date:1108202241 done date:1108202241 stat:DELIVRD err:000
По умолчанию для длинных сообщений, разбиваемых на несколько SMS, сервер возвращает только один статус (DELIVER_SM) для всего склеенного сообщения и одинаковые ID в ответе SUBMIT_SM_RESP для всех SMS-частей данного сообщения. Для включения режима обработки и возврата статусов для каждой SMS-части отдельно установите следующий параметр в настройках подключения (либо в настройках личного кабинета): system-type = «SINGLE»
Если необходимо указать несколько параметров в поле system-type, то укажите их через запятую: system-type = «ISO,SINGLE»
Получение входящих сообщений
Для включения пересылки входящих SMS-сообщений по SMPP-подключению необходимо установить галочку «Передавать входящие SMS по SMPP-подключению» в настройках личного кабинета (раскрывающаяся вкладка «Настройки API») либо обратиться в службу поддержки. При этом передача входящих сообщений на обработчик Клиента должна быть отключена.
Входящие сообщения приходят в PDU-команде DELIVER_SM. Для получения необходимо подключаться к SMPP-серверу в режиме transceiver или receiver.
Коды ошибок в статусе
Возможные коды ошибок в статусе сообщений или HLR-запросов (значения ):