АД по имени JSMPP

[wisd]

У меня работает шлюз по отправке СМС и получению отчетов на библиотеке opensmpp.org/ (которая повторяет API LOGICA)
Могу написать статью по работе с ней, думал она не будет полезна.
А JSMPP я пробовал но он не понравился из-за какой-то глючности

[GlukKazan]

Спасибо за ссылку, но с JSMPP вроде бы все проблемы порешал, так что, скорее всего, она останется в проекте. Но про Ваш опыт по части ее багов было бы узнать интересно (на всякий случай, вдруг что-то важное упустил)

[Googolplex]

Насчёт ошибки slf4j — подключите библиотеку slf4j-log4j и автоматом получите логи изнутри jsmpp. Для этого slf4j и нужен)

[GlukKazan]

Да, завтра хочу поковырять в этом направлении. Надо добиться нормального журналирования.

[lightoze]

Насчет этого — достаточно использовать библиотеку из Maven Central, а не деплоить самому в локальный репозиторий с неполным POM-файлом. Заодно и бонусы в виде подключенных исходников библиотеки в IDE получите.

[datacompboy]

А старый бобрый kannel уже не в моде?

[GlukKazan]

Я написал в статье, что у нас имеется собственная реализация SMPP шлюза. Также есть требование относительно его использования. Поскольку и то и другое писал не я, вопрос относительно моды не ко мне.

[GlukKazan]

Виноват, пока не очень силен в терминологии. Шлюза HTTP -> SMPP у нас нет. Есть SMPP сервер.
Честно говоря, я не вижу весомых причин добавлять в эту связку еще и «старый добрый kannel», но возможно Вы меня разубедите?

Что это даст?

[datacompboy]

Каннел подключается к SMPP, вам доступен простой и понятный HTTP интерфейс с кучей функций.
HTTP клиент в любом языке — в разы проще, чем SMPP с кучей особенностей и кривизны из всех щелей.

Иначе говоря — поставив kannel вы получаете http=>smpp гейт, решать проблемы с которым проще некуда.
Использовали в боевом режиме (апп как раз на java был) с реальными операторами.

[GlukKazan]

Еще раз повторюсь, я понимаю все это, но установка дополнительного софта (не важно с какой лицензией) — вопрос не моей компетенции. Я разрабатываю продукт в соответсвии с тех. заданием и планом работ. Со своей стороны я также пока не вижу причин включать в решение kannel. Задача уже решена без него

[datacompboy]

Что ж. Это плохое решение, но принятое руководством — вам с ним жить, раз вы не можете на это повлиять.
Всем, кому потребуется решение в будущем общаться с SMPP — советую использовать готовые отлаженные и испытанные в продакшене инструменты.

[GlukKazan]

С этим советом я согласен и присоединяюсь к нему

[vp7]

1. Если вы хотите получать ещё и отчёты о доставке, то BIND_TX будет недостаточно — потребуется BIND_TRX и асинхронное получение отчётов о доставке.
2. Поддержу предыдущий коммент — лучше используйте kannel в качестве шлюза SMPP <=> HTTP и подключаться по HTTP. Протокол SMPP простой, но нюансов в нём много, проще взять готовый продукт и использовать его.

[GlukKazan]

Отчеты о доставке получать пока не планирую. Я понимаю Ваши доводы относительно kannel, но вопрос его использования находится вне моей компетенции. Мне дали доступ только по SMPP, это часть требований ТЗ на разработку продукта

[ivnik]

Библиотека jsmpp предоставляет просто низкоуровневое api для работы с smpp. Это минус, когда требуется «просто отправить смску», но зато низкоуровневое api является гибким инструментом если уметь им пользоваться.

Насчёт data coding, в стандарте GSM 03.38 (SMS Data Coding Scheme) под него выделено 4 бита, остальные биты служат для других целей, и Alphabet.ALPHA_DEFAULT — это и есть как-бы «нулевой» data coding.

Bits 3 and 2 indicate the alphabet being used, as follows:
Bit 3 Bit2 Alphabet:
0 0 Default alphabet
0 1 8 bit
1 0 UCS2 (16bit) [10]
1 1 Reserved

Но в SMPP спецификации действительно SMSC Default Alphabet в случае, когда все биты = 0.
В библиотеке используется кодирование согласно стандарту GSM 03.38, правильно или нет трудно сказать.

P.S. грабли которые могут ещё встретиться: в случае латиницы, default alphabet не определяет кодировку, на практике может встречаться как latin1 (ISO-8859-1), так и кодировка GSM 03.38, в которой по другому кодируются некоторые символы (буквенные символы кодируются по прежнему, проблема со знаками). Также, в случае default alphabet, smsc может ожидать «упакованную» латиницу (т.е. 160 символов кодируются в 140 байт).

А ещё, с этой библиотекой нужно следить, если соединение порвалось, то переустанавливать соединение.

И вероятно, до сих пор не исправлен баг, когда входящий deliver_sm может начать обрабатываться одновременно с bind_*_resp (race condition), библиотека отвергнет этот deliver_sm из-за неправильного состояния сессии (ошибка редкая, но я сталкивался).

[GlukKazan]

Спасибо за такой столь развернутый комментарий в части кодировок. Про race condition уже тоже успел услышать. Reconnect сессии будет безусловно.