Проблемы 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.."

Но проблему разных точек отсчета это не решает.

Литература
  • Short Message Peer to Peer Protocol Specification v3.4
  • [GSM 03.40] Technical Realisation of the Short Message Service Point to Point»
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 39

    0
    А какие у нас есть альтернативы?
      0
      Умные HTTP гейты, которые решают эти проблемы сами. А мы радостные и довольные пользуемся готовым из коробочки.
        0
        Но только если выбранный SMSC их имеет и в коробочке раздает.
          0
          Это могут решать посредники. Которые пишут потом вот эти посты :))
          В своё время я тоже хлебнул радости, kannel патчил и плевался.
          Теперь — пусть другие разгребают эти конюшни. А нам, пожалуйста, умный http гейтик.
            0
            На данный момент пользуюсь kannel и он выполняет свою работу отлично. И знаю несколько «посредников», которые точно так же используют kannel как основное средство взаимодействия по SMPP.
              0
              А можно ваши координаты в личку? Мне вот, как поставщику, кое-кто жалуется, что не может приучить kannel «фильтровать базар» на предмет непечатных символов. Кто знает, мож насоветовали бы всяких там ticks&tricks…
          0
          в основе этих гейтов все равно стоит SMPP!
            +1
            Необязательно. Если гейт подключен к SMS-центру, который сразу подключен к телефонке S7. Ттакую конфигурацию оправдано делать операторам с большим количеством каналов и мощным железом SMS-центра и умным софтом, иначе коммерческий трафик запросто может загнуть трафик реальных абонентов, а это для любого оператора недопустимо.
        –1
        Альтернативы чего? SMPP? Большая часть операторов и агрегаторов предлагают свои облегченные протоколы на связке XML+HTTP. В них по своему решают эти проблемы не связываясь стандартом.
          0
          да, SMPP. С чем ещё умеют работать smsc будущего? Про кастомную реализацию XML+HTTP понятно, а что-нибудь общее для отрасли планируется?
            0
            SMPP и есть общее для отрасли. Альтернативы, способные претендовать на общий стандарт мне неизвестны. Да и зачем, если SMS остаются такими какие они есть?
          0
          angry_stitch, а если как вариант использовать не message_id, а sequense_number, это может решить проблему?
            0
            sequence_number обнуляется в первую очередь. На самом деле, есть операторы которые сохраняют message_id после реконнекта. А вообще при определенной договоренности вполне можно передавать свой собственный ID учитывающий реконнекты в TLV.
              0
              0 — запрещенное значение. Разрешен диапазон 0x00000001 to 0x7FFFFFFF. А про сброс sequence_number где требование в спецификации?
              0
              Да, именно по sequense_number мы и решали эту проблему. В качестве SMSC использовался софт East Wind и мы с разработчиками договаривались что клиент шлет sequenсe_number уникальные (не только в пределах живой сессии). И если случается разрыв и потеря смс (счет шел на сотни а то и на тысячи смс, если разрывы шли подряд) то клиент шлет на SMSC запрос query_sm где указывает sequenсe_number с спец. префиксом.
              Это расходится с рекомендацией протокола относительно генерации sequenсe_number. В данном случае это не смертельно. Да и это всего лишь рекомендация.
                0
                ццц. это решение, но это ой как далеко от спецификации. блин, в кои то веки интересная тема, близкая к основной тематике работы, но контактёры слили карму, камрады, исправляйте положение как можете, я на все вопросы тогда отвечу)))
                  0
                  не так уж и далеко.
                  Насчет сплошной уникальной генерации 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.
              0
              хех. Если фундаментально копать, то смпп — это некая переработка 1-максимально почти- в1 сигнализации ОКС7.
              т.е. минимум всяких штучек и дрючек, нечего смсц перетруждаться.
              Но не учитываются все же нюансы tcp соединения, ну что им стоило ввести аналог submit_resp_resp :)
              это бы логически завершало «сеансовость» передачи сообщения.
              что касаемо длинных сообщений, то есть TLV message_payload, странно, что мало кто его использует, хотя иногда оно работает криво на некоторых реализациях типа eastwind smsc, в решениях от svyazcom оно работает нормально
              что касаемо message_state, тут да, нету стандартизации, приходится либо брать значение из TLV, и/или из текста сообщений. разные девелоперы предоставляют разную инфу, но самая удобная там, где оно в формате map/gsm.
              и напоследок. время у нас одно. UTC.
                0
                Так, про «криво на некоторых реализациях типа eastwind smsc» можно подробнее? Мы сними плотно работаем, но вроде проблем не выявляли.

                Про время — видимо не так поняли — стандарт позволяет время schedule_delivery_time и validity_period передавать в относительной форме. Например, schedule_delivery_time задано 3 часа — значит отправлять через 3 часа. Я в статье привел выдержку из протокола. Теперь представим — клиент сформировал сообщение, выставил 3 часа, положил в базу для отправки и тут у интернет-провайдера сгорел коммутатор и связь восстановилась только через 2 часа. Логика у клиента, которая рассчитывала время, отработала до того как сохранить сообщение для отправки. Соответственно сообщение попадет на SMSC через 2 часа к которым тот честно прибавит 3 часа (SMSC понятия не имеет относительно какой временной точки рассчитывал время клиент). Итого сообщение ушло через 5 часов. Проблема, однако!
                  0
                  Подробнее, message_payload не всегда корректно обрабатываются, сейчас нет актуальной инфы почему. Ощущение, что UDH «забывают» добавлять. В итоге длинные смс приходят как попало.
                  А про время вообще нигде не говорил…
                  Однако, по опыту, имею кулек зубной эмали от админов смсц, которым отгружают смски со schedule_delivery_time. Не делайте так. Очереди перегружены. СМСЦ ненадежны. Отправляйте тогда, когда пришло время, и молитесь, молитесь… Из последнего примера — смс отправлено вовремя, но из очереди смсц извлеклось спустя полтора часа, потому что кому-то в голову пришло просто миллион смс поставить в эту самую очередь.
                  Мое резюме — протокол сырой, не отвечает реалиям нынешнего времени, и расчитан на идеальные условия. Реализация еще хуже.
                    0
                    Ну так это на мой взгляд у клиента проблема, что он шлет сообщение из своей базы в SMSC в том виде, в котором оно там лежит, не учитывая что лежать там оно могло даже гораздо больше своего validity_period. А SMSC как получил инструкцию от клиента «отправить через 3 часа» так и сработал.
                      0
                      Но мы же отлично понимаем что проблемы клиента — это проблемы тех кому он платит. По крайней мере клиент так думает и вспоминает об этом при оплате услуг и выборе поставщика.
                    +1
                    Значение message_state как раз и надо брать из TLV, которое обязательно должно присутствовать для delivery receipt. Это написанно в SMPP 3.4. Кроме того, на формат текста который пихают в этот delivery receipt тоже есть есть описание в одном из дополнений, но к сожалению за 5 минут в гугле ссылки на это я не нашел, попробую поискать завтра.
                      +1
                      эм, message_state afair не является mandatory.
                      а раз так, то как хотите, так и парсите.
                      На мой взгляд, важнее сочетание submit_sm_delivery и deliver_sm по своему формату. гадство в том, что в случае с deliver_sm в ПРИМЕРЕ возвращается весьма короткий msgid, не отвечающий реалиям современного трафика :)
                      А этот пример берут за образец, со всеми вытекающими.
                        0
                        message_state обязательный — «Should be present for SMSC Delivery Receipts and Intermediate Notifications.»
                        Да, к сожалению message_id тоже все высылают какой хотят, не удобно — спору нет.
                    0
                    А у всех проблемы одни и те же я смотрю :)
                    Добавлю еще одну. Для установки самой распространенной кодировки (GSM 7 BIT) в пакетах submit_sm и deliver_sm в протоколе явно не задано никакого значения поля data_coding. Конечно, значение «0» (SMSC Default alphabet) большинство считает за 7битку из за ее большой распространенности. Но, есть некоторые ребята которые при значении «0» кодируют сообщение очень экзотическими кодировками, мотивируя это тем что для их систем эти кодировки действительно стандарт де-факто.
                      0
                      Давайте разъясню, как я это понимаю, с вашего позволения.
                      с одной стороны, конечно, оно подразумевается, что шлем в обычном ascii, а smsc разберется, и это правильно.
                      С другой стороны, есть дрянной символ @ — он имеет код 0x00 в gsm alphabet, и тут есть сложности, в результате приходится приходится уточнять у разработчиков/сопровождальщиков, а что же они в виду имели…
                      Худший вариант, по моему опыту, это когда смс шлют с этим самым нулевым dcs, до кучи пакуя 7битку, дабы уложиться в 140 октетов, но это вообще ад и третье чтение стандарта :)
                        0
                        Хм, ну мы как и большинство с кем приходилось сталкиваться трактуем 0 в dcs как 7битку. И да, выставив 0 в dcs дествительно пакуем сообщения в 7битку что бы уложиться в 140 октетов. На счет ада с символом собачки согласен, как можно вообще было додуматься так закодировать :)
                          0
                          эээ! :)
                          Тут надо разделять все же.
                          Какая-то нелогичность все же прослеживается.
                          Как я это вижу.
                          ситуация раз: клиент робкий пытается прятать тело нежное в утесах. Старательно пакует 160 байт сообщения в 140 октетов, используя «упаковку» бит (тут и далее кавычки в кавычках). Бред несусветный, но старание понятно, ибо так нам диктует неоднозначно понятый стандарт.
                          вариант нормальный: клиент шлет as is. обычный текст, обычный ascii, проверяем на хрень в 8-м бите, проверяем на «печатность» текста, все хорошо, твои 160 символов «транслита» засчитываются за 160 символов в нормальной смс, ибо это тут и далее проблема смсц, как это закодировать (а ничо, никого не волнует, что dest_number в реальной передаче кодируется набблами?)
                          шикарный чудо что такое: встретил в своей практике. Клиент выставлял dcs ==8, а слал транслит. В силу специфики платформы оно местами пыталось преобразоваться во что-то печатно-понятное, в итоге вышло нечто похожее на «Посетите официальный функции несколько бурных Gumoujiaoquan стук перемычки Moxiaoheisong» :) Радуюсь, что оно фильтром не воспринялось как осмысленное нечто, и клиенту ушла ошибка, иначе бы получил «квадратики» на телефон абонента, за свой счет.

                            0
                            Отчего же dcs=0 и сообщение в 7bit это неправильно понятый стандарт? Это такое же допущение, как и ваше о том что dsc=0 это ASCII. Если клиент хочет слать в ASCII, пусть шлет — указав при этом DSC=1, как и написано в стандарте.
                              0
                              Такова практика. SMPP сервер != SMSC
                              И фиг переучишь клиента грамотно указывать кодировки, я выше писал уже о курьезе. Default SMSC Alphabet не нашел где определен, и это может сильно отличаться от Default GSM Alphabet.
                          0
                          А не могли бы вы рассказать подробнее о том, что это за проблемы с символом @ и как их преодолевать при кодировании сообщения 7-ми битами?
                            0
                            Строго говоря, это делать не нужно вообще.
                            Это проблема smpp сервера, как это принять и обработать.
                            Наилучшее и наипростейшее решение — засылать как есть, в ascii, и самому упаковывать в 7бит ничего не нужно, пусть этим smsc занимается, это его работа.

                            Ну а рассказать про символ @ я уже выше рассказал.
                            Если вдруг попадается строка в кодировке gsm, то символ @ там кодируется значением 0х00, что де-факто является признаком конца строки в большинстве языков программирования. Поэтому правильное поведение — перекодирование из кодировки gsm в что-то свое уже понятное (да хоть бы и utf-8) и с этим работать уже дальше.
                        0
                        ццц. это решение, но это ой как далеко от спецификации. блин, в кои то веки интересная тема, близкая к основной тематике работы, но контактёры слили карму, камрады, исправляйте положение как можете, я на все вопросы тогда отвечу)))
                          0
                          я не окурю, как этот коммент улетел не туда :( понавыдумывают же.
                          0
                          Был доработан класс на php для отправки смс на кирилице и проверки статусов сообщений. Но в итоге на https+xml перешли и отказались от smpp
                            0
                            увы, это не означает, что избавились от всяких там проблем. В оконцовке все равно это сводится к smpp, как к единственному более-менее стандартному протоколу со всеми вытекающими плюсами и минусами, о чем и был изначальный пост. Единственное исключение, если вдруг вам так интересно повезло, что кто-то вас пустил поработать с smsc через php напрямую, в что я искренне не верю :)
                              0
                              работаем через посредника. услугами и ценами довольны.
                                0
                                А если не секрет..?

                          Only users with full accounts can post comments. Log in, please.