Comments 39
А какие у нас есть альтернативы?
Умные HTTP гейты, которые решают эти проблемы сами. А мы радостные и довольные пользуемся готовым из коробочки.
Но только если выбранный SMSC их имеет и в коробочке раздает.
Это могут решать посредники. Которые пишут потом вот эти посты :))
В своё время я тоже хлебнул радости, kannel патчил и плевался.
Теперь — пусть другие разгребают эти конюшни. А нам, пожалуйста, умный http гейтик.
В своё время я тоже хлебнул радости, kannel патчил и плевался.
Теперь — пусть другие разгребают эти конюшни. А нам, пожалуйста, умный http гейтик.
в основе этих гейтов все равно стоит SMPP!
Необязательно. Если гейт подключен к SMS-центру, который сразу подключен к телефонке S7. Ттакую конфигурацию оправдано делать операторам с большим количеством каналов и мощным железом SMS-центра и умным софтом, иначе коммерческий трафик запросто может загнуть трафик реальных абонентов, а это для любого оператора недопустимо.
Альтернативы чего? SMPP? Большая часть операторов и агрегаторов предлагают свои облегченные протоколы на связке XML+HTTP. В них по своему решают эти проблемы не связываясь стандартом.
angry_stitch, а если как вариант использовать не message_id, а sequense_number, это может решить проблему?
sequence_number обнуляется в первую очередь. На самом деле, есть операторы которые сохраняют message_id после реконнекта. А вообще при определенной договоренности вполне можно передавать свой собственный ID учитывающий реконнекты в TLV.
Да, именно по sequense_number мы и решали эту проблему. В качестве SMSC использовался софт East Wind и мы с разработчиками договаривались что клиент шлет sequenсe_number уникальные (не только в пределах живой сессии). И если случается разрыв и потеря смс (счет шел на сотни а то и на тысячи смс, если разрывы шли подряд) то клиент шлет на SMSC запрос query_sm где указывает sequenсe_number с спец. префиксом.
Это расходится с рекомендацией протокола относительно генерации sequenсe_number. В данном случае это не смертельно. Да и это всего лишь рекомендация.
Это расходится с рекомендацией протокола относительно генерации sequenсe_number. В данном случае это не смертельно. Да и это всего лишь рекомендация.
ццц. это решение, но это ой как далеко от спецификации. блин, в кои то веки интересная тема, близкая к основной тематике работы, но контактёры слили карму, камрады, исправляйте положение как можете, я на все вопросы тогда отвечу)))
не так уж и далеко.
Насчет сплошной уникальной генерации sequence_number
3.2.1 "..The sequence_number should be increased
monotonically for each submitted SMPP
request PDU and must be preserved in the
associated SMPP response PDU.
The sequence_number may range from:
0x00000001 to 0x7FFFFFFF." — это положение не нарушается
положение 5.1.4 тоже не нарушается.
Самодеятельность только в query_sm.
Насчет сплошной уникальной генерации sequence_number
3.2.1 "..The sequence_number should be increased
monotonically for each submitted SMPP
request PDU and must be preserved in the
associated SMPP response PDU.
The sequence_number may range from:
0x00000001 to 0x7FFFFFFF." — это положение не нарушается
положение 5.1.4 тоже не нарушается.
Самодеятельность только в query_sm.
хех. Если фундаментально копать, то смпп — это некая переработка 1-максимально почти- в1 сигнализации ОКС7.
т.е. минимум всяких штучек и дрючек, нечего смсц перетруждаться.
Но не учитываются все же нюансы tcp соединения, ну что им стоило ввести аналог submit_resp_resp :)
это бы логически завершало «сеансовость» передачи сообщения.
что касаемо длинных сообщений, то есть TLV message_payload, странно, что мало кто его использует, хотя иногда оно работает криво на некоторых реализациях типа eastwind smsc, в решениях от svyazcom оно работает нормально
что касаемо message_state, тут да, нету стандартизации, приходится либо брать значение из TLV, и/или из текста сообщений. разные девелоперы предоставляют разную инфу, но самая удобная там, где оно в формате map/gsm.
и напоследок. время у нас одно. UTC.
т.е. минимум всяких штучек и дрючек, нечего смсц перетруждаться.
Но не учитываются все же нюансы tcp соединения, ну что им стоило ввести аналог submit_resp_resp :)
это бы логически завершало «сеансовость» передачи сообщения.
что касаемо длинных сообщений, то есть TLV message_payload, странно, что мало кто его использует, хотя иногда оно работает криво на некоторых реализациях типа eastwind smsc, в решениях от svyazcom оно работает нормально
что касаемо message_state, тут да, нету стандартизации, приходится либо брать значение из TLV, и/или из текста сообщений. разные девелоперы предоставляют разную инфу, но самая удобная там, где оно в формате map/gsm.
и напоследок. время у нас одно. UTC.
Так, про «криво на некоторых реализациях типа eastwind smsc» можно подробнее? Мы сними плотно работаем, но вроде проблем не выявляли.
Про время — видимо не так поняли — стандарт позволяет время schedule_delivery_time и validity_period передавать в относительной форме. Например, schedule_delivery_time задано 3 часа — значит отправлять через 3 часа. Я в статье привел выдержку из протокола. Теперь представим — клиент сформировал сообщение, выставил 3 часа, положил в базу для отправки и тут у интернет-провайдера сгорел коммутатор и связь восстановилась только через 2 часа. Логика у клиента, которая рассчитывала время, отработала до того как сохранить сообщение для отправки. Соответственно сообщение попадет на SMSC через 2 часа к которым тот честно прибавит 3 часа (SMSC понятия не имеет относительно какой временной точки рассчитывал время клиент). Итого сообщение ушло через 5 часов. Проблема, однако!
Про время — видимо не так поняли — стандарт позволяет время schedule_delivery_time и validity_period передавать в относительной форме. Например, schedule_delivery_time задано 3 часа — значит отправлять через 3 часа. Я в статье привел выдержку из протокола. Теперь представим — клиент сформировал сообщение, выставил 3 часа, положил в базу для отправки и тут у интернет-провайдера сгорел коммутатор и связь восстановилась только через 2 часа. Логика у клиента, которая рассчитывала время, отработала до того как сохранить сообщение для отправки. Соответственно сообщение попадет на SMSC через 2 часа к которым тот честно прибавит 3 часа (SMSC понятия не имеет относительно какой временной точки рассчитывал время клиент). Итого сообщение ушло через 5 часов. Проблема, однако!
Подробнее, message_payload не всегда корректно обрабатываются, сейчас нет актуальной инфы почему. Ощущение, что UDH «забывают» добавлять. В итоге длинные смс приходят как попало.
А про время вообще нигде не говорил…
Однако, по опыту, имею кулек зубной эмали от админов смсц, которым отгружают смски со schedule_delivery_time. Не делайте так. Очереди перегружены. СМСЦ ненадежны. Отправляйте тогда, когда пришло время, и молитесь, молитесь… Из последнего примера — смс отправлено вовремя, но из очереди смсц извлеклось спустя полтора часа, потому что кому-то в голову пришло просто миллион смс поставить в эту самую очередь.
Мое резюме — протокол сырой, не отвечает реалиям нынешнего времени, и расчитан на идеальные условия. Реализация еще хуже.
А про время вообще нигде не говорил…
Однако, по опыту, имею кулек зубной эмали от админов смсц, которым отгружают смски со schedule_delivery_time. Не делайте так. Очереди перегружены. СМСЦ ненадежны. Отправляйте тогда, когда пришло время, и молитесь, молитесь… Из последнего примера — смс отправлено вовремя, но из очереди смсц извлеклось спустя полтора часа, потому что кому-то в голову пришло просто миллион смс поставить в эту самую очередь.
Мое резюме — протокол сырой, не отвечает реалиям нынешнего времени, и расчитан на идеальные условия. Реализация еще хуже.
Ну так это на мой взгляд у клиента проблема, что он шлет сообщение из своей базы в SMSC в том виде, в котором оно там лежит, не учитывая что лежать там оно могло даже гораздо больше своего validity_period. А SMSC как получил инструкцию от клиента «отправить через 3 часа» так и сработал.
Значение message_state как раз и надо брать из TLV, которое обязательно должно присутствовать для delivery receipt. Это написанно в SMPP 3.4. Кроме того, на формат текста который пихают в этот delivery receipt тоже есть есть описание в одном из дополнений, но к сожалению за 5 минут в гугле ссылки на это я не нашел, попробую поискать завтра.
эм, message_state afair не является mandatory.
а раз так, то как хотите, так и парсите.
На мой взгляд, важнее сочетание submit_sm_delivery и deliver_sm по своему формату. гадство в том, что в случае с deliver_sm в ПРИМЕРЕ возвращается весьма короткий msgid, не отвечающий реалиям современного трафика :)
А этот пример берут за образец, со всеми вытекающими.
а раз так, то как хотите, так и парсите.
На мой взгляд, важнее сочетание submit_sm_delivery и deliver_sm по своему формату. гадство в том, что в случае с deliver_sm в ПРИМЕРЕ возвращается весьма короткий msgid, не отвечающий реалиям современного трафика :)
А этот пример берут за образец, со всеми вытекающими.
А у всех проблемы одни и те же я смотрю :)
Добавлю еще одну. Для установки самой распространенной кодировки (GSM 7 BIT) в пакетах submit_sm и deliver_sm в протоколе явно не задано никакого значения поля data_coding. Конечно, значение «0» (SMSC Default alphabet) большинство считает за 7битку из за ее большой распространенности. Но, есть некоторые ребята которые при значении «0» кодируют сообщение очень экзотическими кодировками, мотивируя это тем что для их систем эти кодировки действительно стандарт де-факто.
Добавлю еще одну. Для установки самой распространенной кодировки (GSM 7 BIT) в пакетах submit_sm и deliver_sm в протоколе явно не задано никакого значения поля data_coding. Конечно, значение «0» (SMSC Default alphabet) большинство считает за 7битку из за ее большой распространенности. Но, есть некоторые ребята которые при значении «0» кодируют сообщение очень экзотическими кодировками, мотивируя это тем что для их систем эти кодировки действительно стандарт де-факто.
Давайте разъясню, как я это понимаю, с вашего позволения.
с одной стороны, конечно, оно подразумевается, что шлем в обычном ascii, а smsc разберется, и это правильно.
С другой стороны, есть дрянной символ @ — он имеет код 0x00 в gsm alphabet, и тут есть сложности, в результате приходится приходится уточнять у разработчиков/сопровождальщиков, а что же они в виду имели…
Худший вариант, по моему опыту, это когда смс шлют с этим самым нулевым dcs, до кучи пакуя 7битку, дабы уложиться в 140 октетов, но это вообще ад и третье чтение стандарта :)
с одной стороны, конечно, оно подразумевается, что шлем в обычном ascii, а smsc разберется, и это правильно.
С другой стороны, есть дрянной символ @ — он имеет код 0x00 в gsm alphabet, и тут есть сложности, в результате приходится приходится уточнять у разработчиков/сопровождальщиков, а что же они в виду имели…
Худший вариант, по моему опыту, это когда смс шлют с этим самым нулевым dcs, до кучи пакуя 7битку, дабы уложиться в 140 октетов, но это вообще ад и третье чтение стандарта :)
Хм, ну мы как и большинство с кем приходилось сталкиваться трактуем 0 в dcs как 7битку. И да, выставив 0 в dcs дествительно пакуем сообщения в 7битку что бы уложиться в 140 октетов. На счет ада с символом собачки согласен, как можно вообще было додуматься так закодировать :)
эээ! :)
Тут надо разделять все же.
Какая-то нелогичность все же прослеживается.
Как я это вижу.
ситуация раз: клиент робкий пытается прятать тело нежное в утесах. Старательно пакует 160 байт сообщения в 140 октетов, используя «упаковку» бит (тут и далее кавычки в кавычках). Бред несусветный, но старание понятно, ибо так нам диктует неоднозначно понятый стандарт.
вариант нормальный: клиент шлет as is. обычный текст, обычный ascii, проверяем на хрень в 8-м бите, проверяем на «печатность» текста, все хорошо, твои 160 символов «транслита» засчитываются за 160 символов в нормальной смс, ибо это тут и далее проблема смсц, как это закодировать (а ничо, никого не волнует, что dest_number в реальной передаче кодируется набблами?)
шикарный чудо что такое: встретил в своей практике. Клиент выставлял dcs ==8, а слал транслит. В силу специфики платформы оно местами пыталось преобразоваться во что-то печатно-понятное, в итоге вышло нечто похожее на «Посетите официальный функции несколько бурных Gumoujiaoquan стук перемычки Moxiaoheisong» :) Радуюсь, что оно фильтром не воспринялось как осмысленное нечто, и клиенту ушла ошибка, иначе бы получил «квадратики» на телефон абонента, за свой счет.
Тут надо разделять все же.
Какая-то нелогичность все же прослеживается.
Как я это вижу.
ситуация раз: клиент робкий пытается прятать тело нежное в утесах. Старательно пакует 160 байт сообщения в 140 октетов, используя «упаковку» бит (тут и далее кавычки в кавычках). Бред несусветный, но старание понятно, ибо так нам диктует неоднозначно понятый стандарт.
вариант нормальный: клиент шлет as is. обычный текст, обычный ascii, проверяем на хрень в 8-м бите, проверяем на «печатность» текста, все хорошо, твои 160 символов «транслита» засчитываются за 160 символов в нормальной смс, ибо это тут и далее проблема смсц, как это закодировать (а ничо, никого не волнует, что dest_number в реальной передаче кодируется набблами?)
шикарный чудо что такое: встретил в своей практике. Клиент выставлял dcs ==8, а слал транслит. В силу специфики платформы оно местами пыталось преобразоваться во что-то печатно-понятное, в итоге вышло нечто похожее на «Посетите официальный функции несколько бурных Gumoujiaoquan стук перемычки Moxiaoheisong» :) Радуюсь, что оно фильтром не воспринялось как осмысленное нечто, и клиенту ушла ошибка, иначе бы получил «квадратики» на телефон абонента, за свой счет.
А не могли бы вы рассказать подробнее о том, что это за проблемы с символом @ и как их преодолевать при кодировании сообщения 7-ми битами?
Строго говоря, это делать не нужно вообще.
Это проблема smpp сервера, как это принять и обработать.
Наилучшее и наипростейшее решение — засылать как есть, в ascii, и самому упаковывать в 7бит ничего не нужно, пусть этим smsc занимается, это его работа.
Ну а рассказать про символ @ я уже выше рассказал.
Если вдруг попадается строка в кодировке gsm, то символ @ там кодируется значением 0х00, что де-факто является признаком конца строки в большинстве языков программирования. Поэтому правильное поведение — перекодирование из кодировки gsm в что-то свое уже понятное (да хоть бы и utf-8) и с этим работать уже дальше.
Это проблема smpp сервера, как это принять и обработать.
Наилучшее и наипростейшее решение — засылать как есть, в ascii, и самому упаковывать в 7бит ничего не нужно, пусть этим smsc занимается, это его работа.
Ну а рассказать про символ @ я уже выше рассказал.
Если вдруг попадается строка в кодировке gsm, то символ @ там кодируется значением 0х00, что де-факто является признаком конца строки в большинстве языков программирования. Поэтому правильное поведение — перекодирование из кодировки gsm в что-то свое уже понятное (да хоть бы и utf-8) и с этим работать уже дальше.
ццц. это решение, но это ой как далеко от спецификации. блин, в кои то веки интересная тема, близкая к основной тематике работы, но контактёры слили карму, камрады, исправляйте положение как можете, я на все вопросы тогда отвечу)))
Был доработан класс на php для отправки смс на кирилице и проверки статусов сообщений. Но в итоге на https+xml перешли и отказались от smpp
увы, это не означает, что избавились от всяких там проблем. В оконцовке все равно это сводится к smpp, как к единственному более-менее стандартному протоколу со всеми вытекающими плюсами и минусами, о чем и был изначальный пост. Единственное исключение, если вдруг вам так интересно повезло, что кто-то вас пустил поработать с smsc через php напрямую, в что я искренне не верю :)
Sign up to leave a comment.
Проблемы SMPP-протокола