Как стать автором
Обновить

Комментарии 3

Разрешите добавить пару уточнений? — В вашем коде оказалось много магических констант без пояснений.

source_addr_ton => 1,
source_addr_npi => 1,

В общем случае это неверно. Зачастую отправка выполняется с буквенного отправителя, соответственно будет TON = 5 (alphanumeric), NPI = 0 (unknown). Иногда SMSC указывает требования к TON/NPI.

destination_addr => DestMsisdn,

Тут аккуратно, для указанного TON подразумевается номер с кодом страны без плюса. Например: 79981234545.

data_coding => 246,

В этом поле указывается кодировка и модификаторы. Кодировка получается = 6, конкретно CYRLLIC_ISO88595. В реальной жизни так редко бывает: большинство поставщиков умеют в UCS2 (иногда в UTF-16, т.е. тот же UCS2 но со смайликами) и в latin1 (почти все перешли, но некоторые до сих пор умеют в 7-битную кодировку). Вообще вопрос кодировки в этом коде автор полностью обошёл стороной, хотя он крайне важен.

К вопросу 7-битной кодировки. SIGTRAN (который, вроде только необязательное расширение к SS7) выходит за рамки статьи, но для тех у кого опыт именно там и им неожиданно понадобился SMPP — важно заметить, что в SMPP кодирование выполняется иначе. В SS7 байты уже упаковываются по 7 бит, а в SMPP — нет.

Модификаторы — это вот эти единички в битовой маске: 1111 0110. Под рукой нет мануала, обычно 0xC0 это Silent, а 0x10 это Flash. Но у вас тут ещё бит 0x20 установлен, расшифруете?

protocol_id => 127,

Обычно там NULL. Кажется у вас очень специфичная сеть? — Нужны детали.

esm_class => 64,

Это не только для concatenated messages. Это UDHI, он много чего умеет. Например application port иногда используют. Более того, это означает что вы ОБЯЗАНЫ в short_message использовать UDHI, иначе сообщение не будет корректно разобрано. А это ест драгоценные байты (т.к. длина по-прежнему лимитирована 140 байтов (с использованием 7-битного кодирования получается 160 символов для латиницы)).
Подробно есть на Wiki: en.wikipedia.org/wiki/User_Data_Header

Так же вы забыли рассказать как отправить многопартовое сообщение. Что по каждой партиции будет свой отчёт о доставке, итд. Причём в сообщении из двух частей может придти по одной статус доставлено, а по другой не доставлено.

Если критично SMPP и нужны многопартовые, то выбрав поставщика с поддержкой TLV-поля message_payload вы можете забыть о проблемах партиционирования сообщений.

PS: Если вы не телеком (которому это может быть нужно), то рекомендую использовать HTTP API поставщика для отправки SMS. Сэкономите нервы.

Спасибо за развернутый комментарий!


Сразу вспомнил мем "как нарисовать сову". Код примера носит иллюстративный характер. В репозитории еще есть и серверная часть, которая эти запросы обрабатывает. В самом начале я придумал дополнительные условия, тем самым искусственно усложняя ситуацию, чтобы показать удобство интерфейсов.
Я думаю, для отправки обычных SMS через SMPP пользователь может ограничиться https://hexdocs.pm/smppex/SMPPEX.html#module-smppex-esme-sync.


Но если нужно решить более сложные задачи, то необходимы знания. В этом случае прямая дорога в чтение спецификаций в поисках ответов на многие вопросы: какие нужны ton/npi для тех или иных разновидностей адресов, UDHI в esm_class, работа с UDH, набор кодировок, multipart SM и многое другое. Но как говорится, это отдельная история.


n.b. Про телеком это вы в точку.

Причем длинные смс есть минимум 4 способа отправить:
— короткий UDH
— длинный UDH
— заголовки sar_*
— TLV message_payload

И поставщик может разные способы поддерживать в разной степени. В целом обычно хороший выбор это короткий UDH.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории