Pull to refresh

Comments 16

У меня работает шлюз по отправке СМС и получению отчетов на библиотеке opensmpp.org/ (которая повторяет API LOGICA)
Могу написать статью по работе с ней, думал она не будет полезна.
А JSMPP я пробовал но он не понравился из-за какой-то глючности
Спасибо за ссылку, но с JSMPP вроде бы все проблемы порешал, так что, скорее всего, она останется в проекте. Но про Ваш опыт по части ее багов было бы узнать интересно (на всякий случай, вдруг что-то важное упустил)
Насчёт ошибки slf4j — подключите библиотеку slf4j-log4j и автоматом получите логи изнутри jsmpp. Для этого slf4j и нужен)
Да, завтра хочу поковырять в этом направлении. Надо добиться нормального журналирования.
Насчет этого — достаточно использовать библиотеку из Maven Central, а не деплоить самому в локальный репозиторий с неполным POM-файлом. Заодно и бонусы в виде подключенных исходников библиотеки в IDE получите.
Я написал в статье, что у нас имеется собственная реализация SMPP шлюза. Также есть требование относительно его использования. Поскольку и то и другое писал не я, вопрос относительно моды не ко мне.
Виноват, пока не очень силен в терминологии. Шлюза HTTP -> SMPP у нас нет. Есть SMPP сервер.
Честно говоря, я не вижу весомых причин добавлять в эту связку еще и «старый добрый kannel», но возможно Вы меня разубедите?

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

Иначе говоря — поставив kannel вы получаете http=>smpp гейт, решать проблемы с которым проще некуда.
Использовали в боевом режиме (апп как раз на java был) с реальными операторами.
Еще раз повторюсь, я понимаю все это, но установка дополнительного софта (не важно с какой лицензией) — вопрос не моей компетенции. Я разрабатываю продукт в соответсвии с тех. заданием и планом работ. Со своей стороны я также пока не вижу причин включать в решение kannel. Задача уже решена без него
Что ж. Это плохое решение, но принятое руководством — вам с ним жить, раз вы не можете на это повлиять.
Всем, кому потребуется решение в будущем общаться с SMPP — советую использовать готовые отлаженные и испытанные в продакшене инструменты.
С этим советом я согласен и присоединяюсь к нему
1. Если вы хотите получать ещё и отчёты о доставке, то BIND_TX будет недостаточно — потребуется BIND_TRX и асинхронное получение отчётов о доставке.
2. Поддержу предыдущий коммент — лучше используйте kannel в качестве шлюза SMPP <=> HTTP и подключаться по HTTP. Протокол SMPP простой, но нюансов в нём много, проще взять готовый продукт и использовать его.
Отчеты о доставке получать пока не планирую. Я понимаю Ваши доводы относительно kannel, но вопрос его использования находится вне моей компетенции. Мне дали доступ только по SMPP, это часть требований ТЗ на разработку продукта
Библиотека 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 из-за неправильного состояния сессии (ошибка редкая, но я сталкивался).

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

Articles