Кіріспе
Қысқа хабарламаларды тасымалдау протоколы
Телекоммуникация саласындағы Қысқа хабарламалар арасындағы байланыс протоколы (SMPP) – сыртқы қысқа хабарлама беру бірліктері (ESME), бағыттандыру бірліктері (RE) және SMSC арасында қысқа хабарламалардың деректерін тасымалдау үшін икемді деректер байланысы интерфейсін қамтамасыз ететін ашық, индустриялық стандартты протокол. SMPP көбінесе үшінші тараптарға (мысалы, жаңалықтар ұйымдары сияқты қосымша қызметтер ұсынатын провайдерлерге) хабарламаларды, әсіресе көп көлемде жіберуге мүмкіндік береді, бірақ оны SMS байланысын құру үшін де пайдалануға болады. SMPP EMS, дауыстық хабарламалар, ұялы желіге тарату, WAP хабарламалары (WAP Push хабарламаларын қоса, олар MMS хабарламаларын жеткізу үшін қолданылады), USSD хабарламалары және басқа да қысқа хабарлама түрлерін тасымалдай алады. Өз әмбебаптығымен және UMTS, IS 95 (CDMA), CDMA2000, ANSI 136 (TDMA) және iDEN сияқты GSM емес SMS протоколдарына қолдауымен SMPP, SS7 желілерінен тыс қысқа хабарлама алмасу үшін ең көп қолданылатын протокол болып табылады.
Тарих
SMPP (Short Message Peer to Peer) бастапқыда шағын ирланд компаниясы Aldiscon әзірлеген, кейіннен оны Logica сатып алды (2016 жылдан бастап, бірнеше өзгерістерден кейін Mavenir). Протоколды бастапқыда Иан Дж. Чемберс хабарларды жіберу үшін SS7 сынақ жабдықтарын пайдаланбай SMSC функционалдығын тексеру мақсатында жасады. 1995 жылы ETSI SMPP протоколын TR 03.39 техникалық есебіне қосты. 1999 жылы Logica SMPP-ді SMPP Developers Forum-ға ресми түрде тапсырды, кейіннен ол SMS Forum деп аталды. SMS Forum 2007 жылы таратылды, осы хабарламамен: "SMS Forum, коммерциялық емес ұйым, SMS (қысқа хабарлама қызметі) дамыту, қолдау және жариялау миссиясын орындап, әлемдік сымсыз индустрияның мүддесі үшін 2007 жылдың 27 шілдесіне дейін таратылады". Бастапқы тапсыру шарттарына сәйкес, SMPP-ге құқық Mavenir-ге қайтарылды.
Операция
SMPP клиент-серверлік жұмыс моделін қолданады, атауында "теңдес арасында" делінгеніне қарамастан. Қысқа хабарламалар орталығы (SMSC) әдетте сервер рөлінде болады және ESME-лерден қосылыстарды күтеді. SMPP SMS-тің тікелей жөнелуі үшін қолданылғанда, жіберуші MC әдетте клиент рөлінде әрекет етеді. Протокол сұрау/жауап PDU (протоколдық дерек бірліктері немесе пакеттер) жұптарына негізделген, олар OSI 4-ші қабатындағы (TCP сессиясы немесе X.25 SVC3) қосылымдар арқылы алмасылады. TCP арқылы жұмыс істегенде SMPP үшін IANA белгілеген стандартты порт 2775, бірақ хабар алмасу орталарында бірнеше кездейсоқ порттар жиі қолданылады. Кез келген хабар алмасудан бұрын, байланыс командасы жіберіліп, расталуы керек. Байланыс командасы хабарларды қай бағытта жіберуге болатынын анықтайды; байланыс жіберуші тек клиентке серверге хабарларды жіберуге рұқсат береді, байланыс қабылдаушы клиентке тек хабарларды қабылдауға рұқсат береді, ал байланыс қабылдағыш-жіберуші (SMPP 3.4 нұсқасында енгізілген) екі бағытта да хабар алмасуға мүмкіндік береді. Байланыс командасында ESME жүйелік идентификатор, жүйе түрі және пароль арқылы өзін таныстырады; ESME мекенжайы үшін арналған мекенжайлар диапазоны өрісі әдетте бос қалдырылады. Байланыс командасында SMPP протоколының қай нұсқасы қолданылатынын көрсету үшін интерфейс нұсқасы параметрі бар. Хабар алмасу синхронды болуы мүмкін, онда әрбір тарап әрбір PDU жіберілгеннен кейін жауап күтеді, немесе асинхронды, онда бірнеше сұрау күтпестен жіберілуі мүмкін және басқа тарап оларды ретсіз растауы мүмкін; расталмаған сұраулар саны терезе деп аталады; ең жақсы өнімділік үшін екі тарап терезенің бірдей мөлшерімен конфигурациялануы керек.
Нұсқалар
SMPP стандарты уақыт өте келе өзгеріп дамыды. SMPP-ның ең көп қолданылатын нұсқалары:
SMPP 3.3 – ең ескі қолданылған нұсқасы (шектеулеріне қарамастан, ол әлі де кеңінен қолданылады); тек GSM-ді қолдайды. Жіберілген әрбір хабарламаға дереу жауап береді. SMPP 3.4 нұсқасына опциялық таңба-ұзындық-мәнді (TLV) параметрлер, GSM емес SMS технологияларын қолдау және трансиверлерді қолдау (хабарларды жіберіп, қабылдай алатын жалғыз қосылым) қосылды. ESME таратушысы мен SMSC арасында SMPP сұрау және жауап PDU-ларының алмасуы синхронды немесе асинхронды түрде жүзеге асырылуы мүмкін. SMPP 5.0 – SMPP-ның ең соңғы нұсқасы; жасушалық хабар таратуды, интеллектуалды ағын басқаруды қолдайды. 2023 жылдың мәліметі бойынша, ол кеңінен қолданылмайды. Қолданылатын нұсқа байлау командасының интерфейс нұсқасы параметрі арқылы беріледі.
Мысал
Бұл 60 октеттік жіберу SM PDU-ының екілік кодтамасының мысалы. Дерек бір реттік гекса октеттік мәндер түрінде көрсетілген, одан кейін осы PDU-дың бас және дерек бөлігінің талдауы келтірілген. Бұл кодтаманың SMPP спецификациясындағы жіберу SM PDU-ының әр өрісінің анықтамасына қалай сәйкес келетінін түсіну үшін осы анықтамамен салыстыруға кеңес беріледі. Мәндердің талдауы ондық санмен жақшада, одан кейін алтылық санмен көрсетілген. Егер бір немесе бірнеше гекса октеттер қосылған болса, бұл берілген өрістің көлемі 1 немесе одан көп октетті кодтауды пайдаланатынын білдіреді. Қосымша түсініктің үшін спецификациядан жіберу SM PDU-ының анықтамасын қайта қарау ұсынылады.
PDU басындағы
'команда ұзындығы', (60) 00 00 00 3C
'команда идентификаторы', (4) 00 00 00 04
'команда статусы', (0) 00 00 00 00
'реттік нөмір', (5) 00 00 00 05
'command id', (4) 00 00 00 04
'command status', (0) 00 00 00 00
'sequence number', (5) 00 00 00 05
PDU органы
'қызмет түрі', 00
'көз адресінің түрі', (2) 02
'көз адресінің нпи', (8) 08
'көз адресі', (555) 35 35 35 00
'мақсат адресінің түрі', (1) 01
'мақсат адресінің нпи', (1) 01
'мақсат адресі', (555555555) 35 35 35 35 35 35 35 35 35 00
'esm класы', (0) 00
'протокол идентификаторы', (0) 00
'басымдық белгісі', (0) 00
'жеткізілу уақытын жоспарлау', (0) 00
'қолданылу мерзімі', (0) 00
'тіркелген жеткізу', (0) 00
'болған жағдайда ауыстыру белгісі', (0) 00
'деректерді кодтау', (3) 03
'sm ең кішкентай идентификаторы', (0) 00
'sm ұзындығы', (15) 0F
'қысқа хабарлама', (Сәлем, Википедия) 48 65 6C 6C 6F 20 57 69 6B 69 70 65 64 69 61
'source addr ton', (2) 02
'source addr npi', (8) 08
'source addr', (555) 35 35 35 00
'dest addr ton', (1) 01
'dest addr npi', (1) 01
'dest addr', (555555555) 35 35 35 35 35 35 35 35 35 00
'esm class', (0) 00
'protocol id', (0) 00
'priority flag', (0) 00
'schedule delivery time', (0) 00
'validity period', (0) 00
'registered delivery', (0) 00
'replace if present flag', (0) 00
'data coding', (3) 03
'sm default msg id', (0) 00
'sm length', (15) 0F
'short message', (Hello Wikipedia) 48 65 6C 6C 6F 20 57 69 6B 69 70 65 64 69 61
Ескеріңіз, қысқа хабарлама өрісіндегі мәтін деректерді кодтауға сәйкес келуі керек. Деректерді кодтау 8 (UCS2) болғанда мәтін UCS 2BE (немесе оның кеңейтімі, UTF 16BE) форматында болуы тиіс. Деректерді кодтау 7 биттік кодтауды көрсеткенде, әрбір септа қысқа хабарлама өрісінің жеке октетінде сақталады (ең маңызды бит 0 ретінде белгіленеді). SMPP 3.3 деректерді кодтау GSM 03.38-дің TP DCS мәндерін дәл көшірді, бұл оны GSM 7-биттік әдепкі әліпбиі, UCS2 немесе екілік хабарламалар үшін ғана жарамды етеді; SMPP 3.4 деректерді кодтау мәндерінің жаңа тізімін енгізді:
Деректерді кодтау Мағынасы
0 SMSC әдепкі әліпбиі (SMPP 3.4) / MC ерекше (SMPP 5.0)
1 IA5 (CCITT T.50) / ASCII (ANSI X3.4)
2 Октат белгісіз (8 биттік екілік)
3 Латын 1 (ISO 8859 1)
4 Октат белгісіз (8 биттік екілік)
5 JIS (X 0208 1990)
6 Кирилл (ISO 8859 5)
7 Латын / еврей (ISO 8859 8)
8 UCS2 (ISO/IEC 10646)
9 Пиктограмма кодтау
10 ISO 2022 JP (Музыка кодтары)
11 Қорытылған
12 Қорытылған
13 Кеңейтілген кандзи JIS (X 0212–1990)
14 KS C 5601
15 Қорытылған
191-192 GSM MWI бақылауы – GSM 03.38 қараңыз
208-223 GSM MWI бақылауы – GSM 03.38 қараңыз
224-239 Қорытылған
240-255 GSM хабарлама класының бақылауы – GSM 03.38 қараңыз
Деректерді кодтау=4 немесе 8 мәні SMPP 3.3-тегідей болды. SMPP 3.3-те 1-15 аралығындағы басқа мәндер қорытылған. Өкінішке орай, SMPP 3.3-тен айырмашылығы, онда деректерді кодтау=0 біржақты түрде GSM 7-биттік әдепкі әліпбиі болды, SMPP 3.4 және одан жоғарыда GSM 7-биттік әдепкі әліпбиі бұл тізімде жоқ, ал деректерді кодтау=0 әртүрлі қысқа хабарламалар орталықтары үшін әртүрлі болуы мүмкін – бұл ISO 8859 1, ASCII, GSM 7-биттік әдепкі әліпбиі, UTF 8 немесе ESME бойынша конфигурациялануы мүмкін. Деректерді кодтау=0 қолданғанда, екі тарап та (ESME және SMSC) оны бірдей кодтау деп санайтынына сенімді болуы керек. Әйтпесе, деректерді кодтау=0 қолданбаған жөн. GSM 7-биттік әдепкі әліпбиін пайдалану қиын болуы мүмкін, кейбір қысқа хабарламалар орталықтары деректерді кодтау=0, ал басқалары, мысалы, деректерді кодтау=241 талап етеді.
GSM 7 биттік әдетті әліпбиі үшін data_coding жоқ
SMPP 3.3 нұсқасындағы дерек кодтау мәндері GSM 03.38 стандартына негізделгенімен, SMPP 3.4 нұсқасынан бастап GSM 7 биттік әліпбиі (GSM 03.38) үшін дерек кодтау мәні жоқ. Дегенмен, DCS=0 мәні GSM 7 биттік әліпбиін білдіруі жиі кездеседі, әсіресе GSM ұялы желілеріндегі SMSC-ге SMPP қосылымдарында. 7 биттік әліпби GSM стандартындағыдай жиналған, яғни 160 символ 140 октет көлемінде жіберіле ме, әлде әр 7 биттік символ толық октетті пайдалана ма (ASCII-дегідей жоғары биті нөлге тең қойылады) деген мәселе де нақты емес.
data_coding=0-ның стандартталмаған мағынасы
SMPP 3.4 және 5.0 нұсқаларына сәйкес деректер кодтамасы = 0 дегеніміз «SMSC жүйесінің әдепкі әліпбиі». Нақты қандай кодтау қолданылатыны SMSC түрі мен оның конфигурациясына байланысты.
Shift-JIS кодтамасын анық қолдамайды
CDMA стандартындағы C. R1001 кодтамаларының бірі – жапон тілі үшін қолданылатын Shift JIS. SMPP 3.4 және 5.0 жапон тілі үшін үш кодтаманы белгілейді (JIS, ISO 2022 JP және кеңейтілген кандзи JIS), бірақ олардың ешқайсысы CDMA MSG ENCODING 00101-мен сәйкес келмейді. SMPP-да Shift JIS форматындағы хабарламаларды жеткізу үшін пиктограмма кодтамасы (деректер кодтамасы=9) пайдаланылатын сияқты.
SMPP нұсқалары арасында submit_sm_resp үйлесімсіздігі
СМСС жіберу сәтсіз аяқталғанда, SMSC команда статусының нөлдік емес мәнімен және "бос" хабарлама идентификаторымен жауап қайтарады. SMPP 3.3 стандарты хабарлама идентификаторы өрісі туралы "Егер өріс болмаса, онда бір ғана NULL байты болуы тиіс" деп нақты айтады. PDU ұзындығы кем дегенде 17 октет болуы керек. SMPP 3.4 стандарты SUBMIT SM RESP бөлімінде келесідей ескерту жасайды: "Егер команда статусы өрісі нөлдік емес мәнді қамтыса, SUBMIT SM RESP PDU Body қайтарылмайды". Осы жағдайда PDU ұзындығы 16 октеттей болады. SMPP 5.0 стандарты хабарлама идентификаторын C типті октеттік тізбек түріндегі міндетті параметр ретінде белгілейді. 3.1.1 NULL параметрлері бөлімінде көрсетілгендей, "NULL тізбегі" 0x00 ретінде кодталады. PDU ұзындығы кем дегенде 17 октет болуы керек. Ең жақсы үйлесімділікті қамтамасыз ету үшін, кез келген SMPP жүзеге асыруы қолданылатын SMPP стандартының нұсқасына қарамастан, теріс жауаптың екі түрін де қабылдауы тиіс.
Кеңейту, үйлесімділік және өзара іс-қимыл
3.4 нұсқасында TLV параметрлері енгізілгеннен кейін SMPP кеңейтілген протокол ретінде қарастырылуы мүмкін. Ең жоғары деңгейде үйлесімділік пен өзара іс-қимылға қол жеткізу үшін кез келген жүзеге асыру Интернеттің сенімділік принципін қолдануы керек: «Жібергенде сақтықпен, ал қабылдағанда кеңдікпен». Міндетті орындау үшін қажетті мүмкіндіктердің ең минималды жиынтығын пайдалану керек. Егер мақсат – байланыс болса, әрбір жүзеге асыру стандартқа толық сәйкес келмесе де, шағын қателіктерді жеңуі керек: кез келген танылмаған SMPP командасына команда статусы = 3 болатын жалпы NACK жауабын қайтарыңыз, бірақ байланысты үзбеңіз. Белгісіз, күтпеген немесе қолдау көрсетілмейтін TLV параметрлерін назардан тыс қалдырыңыз. PDU шекаралары әрқашан PDU командасының ұзындық өрісімен анықталады. Кез келген хабарлама өрісі PDU соңынан асып кетпеуі керек. Егер өріс толыққанды аяқталмаса, ол PDU соңында уысып қалған деп есептелуі керек және келесі PDU-ларға әсер етпеуі керек. SMPP-ның бір нұсқасына қатысты ақпарат басқа нұсқада да кездесуі мүмкін, мысалы, SMPP 3.4-те сипатталған жеткізілген хабарламалардың механизмі SMPP 3.3 нұсқасында да келтірілген.
Respond with a generic nack with command status=3 to any unrecognised SMPP command, but do not stop the communication. Ignore any unrecognised, unexpected or unsupported TLV parameters. The borders of PDUs are always given by the PDUs' command length field. Any message field must not exceed the end of PDU. If a field is not properly finished, it should be treated as truncated at the end of PDU, and it should not affect further PDUs. Information applicable to one version of SMPP can often be found in another version of SMPP, for example with the case of SMPP 3.4 describing the only mechanism of delivery receipts in SMPP 3.3 described above.
Қауіпсіздік
SMPP протоколы ашық мәтінді бинарлық протокол негізінде құрылған, SMS арқылы бір реттік парольдер сияқты құпиялы ақпаратты жіберу үшін пайдаланғанда бұл ескерілуі керек. Қажет болса, SMPP-ні SSL/TLS арқылы іске асыруға болады.