SMPP — peer-to-peer-protokol for korte beskeder

Hej! Selvom messaging-apps og sociale medier hver dag erstatter traditionelle kommunikationsmetoder, mindsker det ikke populariteten af SMS. Verifikation på populære hjemmesider eller meddelelser om transaktioner bliver sendt via SMS, og de lever i bedste velgående. Har du nogensinde tænkt over, hvordan det hele fungerer? Ofte bruges protokollen SMPP til at sende massebeskeder, som vi vil tale om herunder.

Der har allerede været artikler om SMPP på Habré, 1,2, men deres mål var ikke at beskrive selve protokollen. Du kan selvfølgelig begynde med den originale kilde — specifikationerne, men jeg synes, det ville være godt at have et kort resumé. Jeg vil forklare med eksempel fra v3.4. Jeg ser frem til din objektive kritik.

SMPP-protokollen er en protokol til peer-to-peer-beskeder. Det betyder, at hver peer/hub-server er ligestillet. I dens enkleste form ser SMS-beskedudvekslingens ordning således ud:

Men hvis den nationale operatør ikke har en rute til en afsides region, beder de en mægler — en SMS-hub — om hjælp. Nogle gange, for at sende en SMS, skal der opbygges en kæde mellem flere lande eller endda kontinent.

Om protokollen

SMPP er en applikationsprotokol, der er baseret på udveksling af PDU og sendes over TCP / IP eller X25-sessions til transmission af SMS og USSD-beskeder. Normalt anvendes SMPP i permanent tilstand, hvilket sparer tid. SMPP bruger en klient-server kommunikationsmodel.

Kommunikationsmodus

Beskedudvekslingen mellem afsenderen og SMS-centret via SMPP kan finde sted i følgende tilstande:

Transmitter (afsender) — transmission af beskeder i én retning, sekventielt
Receiver (modtager) — kun modtagelse af beskeder fra SMS-centret.
Transreceiver (modtagelsestransmitter) — Udveksling af beskeder mellem SMS-centret og brugeren

Struktur

Beskedens længde

En SMS-besked kan indeholde 70 tegn, når det skrives med kyrilliske bogstaver og højst 157 latinske tegn + 3 UDH. Hvis der sendes en SMS med et stort antal tegn, vil den blive opdelt i flere segmenter og derefter sammensat i den modtagende enhed. Ved segmentering reduceres antallet af tegn på grund af meddelelsens overskrifter, hvor det angives, hvilken del af meddelelsen det drejer sig om. Derfor vil en stor SMS-besked indeholde maksimalt 153 latinske tegn eller 67 usædvanlige tegn.

Data Coding Scheme

Men for at sende en besked skal tegnene kodes. I SMPP-protokollen ansvarer et specielt felt - Data Coding Scheme, eller DCS - for kodningen. Dette felt angiver, hvordan beskeder skal genkendes. Derudover omfatter DCS-feltet:

• et tegnsæt, der bestemmer kodningen;
• typen af besked;
• anmodning om automatisk sletning efter læsning;
• angivelse af komprimering af besked;
• sproget for broadcast-beskeden;

Standard 7-bit alfabet (GSM 03.38). Dette blev udviklet til beskedssystemet i GSM. Denne kodning er passende for engelsk og en række latinske sprog. Hvert tegn består af 7 bit og kodes i en oktet.

UTF-16 (i GSM UCS2) For at inkludere de manglende tegn i 7-bit alfabetet blev UTF-16 kodningen udviklet, som tilføjer ekstra tegn (herunder kyrilliske) ved at reducere størrelse af beskeden fra 160 til 70; denne type kodning gentager næsten fuldstændig Unicode.

Brugerdefinerede 8-bit data. Disse inkluderer KOI8-R og Windows-1251. Selvom denne løsning synes mere økonomisk sammenlignet med UTF-16, opstår et berettiget spørgsmål om kompatibilitet på forskellige enheder, eftersom begge enheder skal være forudindstillet.

Beskedtype

• Class0 eller flash-besked, gemt i telefonens hukommelse efter brugerens ønske;
• Class1 eller dem, der gemmes i telefonens hukommelse;
• Class1 eller dem, der gemmes i telefonens hukommelse;
• Class2, som skal sikre, at beskeden gemmes i mobilterminalens hukommelse, ellers skal den returnere en SMS-centers underretning om, at det ikke er muligt at gemme;
• Class3 - i dette tilfælde skal telefonen sende en meddelelse om, at beskeden kan gemmes, uanset hvor meget hukommelse der er på enheden. Denne type besked forudsætter, at beskeden er nået modtageren;

Beskedtype

Silent message (SMS0) Type smsbesked uden indhold. Denne sms modtages uden underretning og vises ikke på enhedens skærm.

PDU

Hver PDU-operation er parret og består af anmodning og svar. For eksempel: kommandoen, der angiver forbindelsesoprettelse (bind_transmitter / bind_transmitter_resp), eller at beskeden er sendt (deliver_sm / deliver_sm_resp)

Hver PDU-pakke består af to dele - header og body. Strukturen af headeren er identisk for enhver PDU-pakke: command length er længden af pakken, id er navnet på pakken, og kommandoen status angiver, om beskeden er blevet sendt succesfuldt eller med fejl.

Supplerende TLV-parametre

TLV (Tag Length Value), eller supplerende felter. Disse parametre bruges til at udvide protokollens funktioner og er ikke obligatoriske. Dette felt angives til sidst i PDU-feltet. Som et eksempel kan TLV-dest_addr_np_information bruges til at organisere overførsel af information om nummerportabilitet.

Ton og Npi

TON (Type of Number) parameteren informerer SMSC om adresseformatet og typen af netværk.
NPI (Numbering Plan Identification) parameteren angiver nummereringsplanen.

Afsenderadressen for beskeden, eller alpha-name

Beskeder, der sendes til telefonen, findes i to varianter: digitale og bogstavelige. Digitale kan være lange (lignende et telefonnummer) eller korte. Nogle gange har operatører begrænsninger for at sende fra neutrale navne, såsom Infosms, Alert etc. Nogle gange tillader operatører ikke trafik, hvis navnet ikke er registreret i deres netværk. Men dette er snarere operatørens specifikationer.

Faser af afsendelse

SMS-SUBMIT — det er afsendelse af en MO FSM-besked (kort besked fra mobilterminalen)
SMS-SUBMIT REPORT — bekræftelse på, at beskeden er sendt til SMSC
SRI SM (SendRoutingInfo) — SMSC modtager information fra HLR vedrørende MSC/VLR, hvor abonnenten befinder sig
SRI SM RESP — svar fra HLR vedrørende abonnentens beliggenhed
MT-FSM — efter modtagelse af placeringen sendes beskeden ved hjælp af operationen ‘Forward Short Message’
MT-FSM ACK — svar fra SMSC om, at beskeden er sendt
SMS-STATUS REPORT — SMSC sender status om levering af beskeden.

Beskedens leveringsstatus

SMS-STATUS REPORT kan have flere værdier:
DELIVRD beskeden blev leveret succesfuldt
REJECTD — beskeden blev afvist af SMS-centret
EXPIRED — beskeden blev fjernet fra sendekøen efter udløbet af TTL (tid til liv for beskeden)
UNDELIV — andre tilfælde af manglende levering
UNKNOWN- der blev ikke modtaget svar på afsendelsen.

Overførselsfejl

Nogle gange er der årsager til, at SMS-beskeder ikke leveres til abonnenten. Følgerne af disse årsager fører til opståen af fejl. Fejl returneres i PDUs_sms_resp. Alle fejl kan opdeles i midlertidige (Temporary) og permanente (Permanent).

Som eksemplet kan midlertidige fejl som absent_subscriber, som betyder, at abonnenten ikke er tilgængelig eller ikke er online, henføres til. Permanent fejl — abonnenten eksisterer ikke. Afhængigt af de fejl, der opstår, dannes politikken for at gensende disse meddelelser.

For eksempel, hvis abonnenten var optaget af et opkald og fik fejlen MT handset is busy, kan meddelelsen gensendes efter et par minutter, men hvis abonnenten har blokkeret tjenesten for modtagelse af meddelelser, vil gensendelsen ikke give mening. Du kan finde listen over fejl på SMSC-siderne, for eksempel som denne.

Kilde: habr.com