SMPP – ett peer-to-peer-protokoll för korta meddelanden

Hej! Även om meddelandeappar och sociala medier undan för undan ersätter traditionella kommunikationssätt, minskar det inte SMS:ens popularitet. Verifiering på en populär webbplats eller meddelanden om transaktioner upprepas i realtid och kommer att fortsätta att existera. Har du någonsin funderat över hur allt detta fungerar? Mycket oftast används protokollet SMPP för massutskick av meddelanden, vilket är vad vi kommer att diskutera nedan.

Det har redan publicerats artiklar om SMPP på Habré, 1,2, men deras syfte var inte att beskriva själva protokollet. Självklart kan du börja direkt med källan — specifikationen, men jag tycker det skulle vara bra att det även finns en sammanfattning. Jag kommer att förklara med exemplet v3.4 Jag uppskattar din objektiva kritik.

SMPP-protokollet är ett protokoll för peer-to-peer-meddelanden. Det innebär att varje peer/hubserver är lika värdig. I enklaste fall ser schemat för utbyte av SMS-meddelanden ut så här:

Men om den nationella operatören inte har en rutt till någon avlägsen region ber han en mellanhand — SMS-hubben. Ibland, för att skicka ett SMS, måste man bygga en kedja mellan flera länder eller till och med kontinenter.

Om protokollet

SMPP är ett applikationsprotokoll som bygger på utbyte av PDU och överförs över TCP/IP eller X.25-sessioner för att skicka SMS och USSD-meddelanden. Vanligtvis används SMPP i ett läge med ständig anslutning, vilket hjälper till att spara tid. SMPP använder modellen klient-server.

Kommunikationsläge

Utbyte av meddelanden mellan avsändaren och SMS-centret via SMPP kan ske i följande lägen:

Transmitter (sändare) — överföring av meddelanden i en riktning, sekventiellt
Receiver (mottagare) — endast mottagande av meddelanden från SMS-centret.
Transreceiver (sänd- och mottagare) — Utbyte av meddelanden mellan SMS-centret och användaren

Struktur

Meddelandets längd

Ett SMS-meddelande kan innehålla 70 tecken när det skrivs med kyrilliska bokstäver och högst 157 latinska tecken + 3 UDH. Om du skickar ett SMS med ett stort antal tecken kommer det att delas upp i flera segment och sammanfogas i mottagarens enhet. Vid segmentering minskar antalet tecken på grund av meddelandets rubriker som anger delen av meddelandet. Därför, när du skickar ett stort SMS, innehåller det högst 153 latinska tecken eller 67 atypiska tecken.

Data Coding Scheme

Men för att överföra ett meddelande krävs kodning av tecken. I SMPP-protokollet ansvarar ett speciellt fält för kodning — Data Coding Scheme, eller DCS. Detta fält anger hur meddelanden ska tolkas. Dessutom innehåller DCS-fältet:

• ett teckenuppsättning som definierar kodningen;
• meddelandeklass;
• förfrågan om automatisk borttagning efter läsning;
• indikation om komprimering av meddelandet;
• språk för broadcast-meddelandet;

Standard 7-bitars alfabet (GSM 03.38). Det utvecklades för meddelandesystemet i GSM. Denna kodning är lämplig för engelska och flera latinska språk. Varje tecken består av 7 bitar och kodas i en oktett.

UTF-16 (i GSM UCS2) För att inkludera saknade tecken i det 7-bitar alfabetet utvecklades kodningen UTF-16 som lägger till extra tecken (inklusive kyrilliska) genom att minska storleken på meddelandet från 160 till 70; denna typ av kodning motsvarar nästan helt Unicode.

Användardefinierade 8-bitarsdata. Sådana inkluderar KOI8-R och Windows-1251. Även om denna lösning verkar mer kostnadseffektiv jämfört med UTF-16, uppstår en rimlig fråga om kompatibilitet på olika enheter. Eftersom båda enheterna i sådana fall måste vara inställda i förväg.

Meddelandeklass

• Class0, eller flash, meddelande, lagrat i telefonens minne på användarens begäran;
• Class1, eller de som lagras i telefonens minne;
• Class1, eller de som lagras i telefonens minne;
• Class2, ska säkerställa att meddelandet sparas i det mobila terminalens minne; annars ska den skicka en notifikation till SMS-centret om att det inte går att spara;
• Class3 — i detta fall ska telefonen skicka en notifiering om att meddelandet kan sparas, oavsett mängden minne i enheten. Denna typ av meddelande innebär att meddelandet har nått mottagaren;

Meddelandetyp

Silent message (SMS0) Typ av SMS-meddelande utan innehåll. Detta SMS kommer utan avisering och visas inte på enhetens skärm.

PDU

Varje PDU-operation är parvis och består av en begäran och ett svar. Till exempel: kommandot som handlar om att etablera en anslutning (bind_transmitter / bind_transmitter_resp), eller att meddelandet har skickats (deliver_sm / deliver_sm_resp)

Varje PDU-paket består av två delar — en rubrik (header) och ett innehåll (body). Strukturens rubrik är densamma för varje PDU-paket: command length är paketets längd, id är paketets namn, och kommandot status visar om meddelandet har skickats framgångsrikt eller om det har uppstått ett fel.

Ytterligare TLV-parametrar

TLV (Tag Length Value), eller ytterligare fält. Dessa parametrar används för att utöka protokollets funktioner och är inte obligatoriska. Detta fält anges i slutet av PDU-fältet. Som exempel kan TLV dest_addr_np_information användas för att organisera överföring av information om nummerportabilitet.

Ton och Npi

TON (Type of Number) parametern informerar SMSC om adresseringsformatet och nätverkstypen.
NPI (Numbering Plan Identification) parametern indikerar nummerräkningsplan.

Avsändaradressen för meddelandet, eller alfa-namnet

Meddelanden som skickas till telefoner kan vara av två typer: digitala och alfabetiska. Digitala kan vara långa (liknande ett telefonnummer) och korta. Ibland har operatörer begränsningar för sändning från neutrala namn, såsom Infosms, Alert etc. Ibland tillåter operatörer inte trafik om namnet inte är registrerat i deras nätverk. Men detta är mer en operatörsspecifik egenskap.

Skeden av sändning

SMS-SUBMIT — det är sändning av ett MO FSM (kort meddelande från en mobil terminal)
SMS-SUBMIT RAPPORT — bekräftelse på att meddelandet har skickats till SMSC
SRI SM (SendRoutingInfo) — SMSC får information från HLR angående MSC / VLR-platsen för abonnenten
SRI SM RESP — svar från HLR angående abonnentens plats
MT-FSM — efter att ha mottagit platsen skickas ett meddelande med operationen "Forward Short Message"
MT-FSM ACK — svar från SMSC om att meddelandet har skickats
SMS-STATUS RAPPORT — SMSC skickar status för meddelandets leverans.

Meddelandets leveransstatus

SMS-STATUS RAPPORT kan ta flera värden:
DELIVRD meddelandet har levererats framgångsrikt
REJECTD — meddelandet har avvisats av SMS-centret
EXPIRED — meddelandet har tagits bort från kö för sändning efter att TTL (livslängd för meddelandet) har löpt ut
UNDELIV — andra fall av misslyckad leverans
UNKNOWN- inget svar har mottagits om sändningen.

Överföringsfel

Ibland finns det orsaker till varför SMS-meddelanden inte levereras till abonnenten. Följderna av dessa orsaker är uppkomsten av fel. Felen returneras i PDUs_sms_resp. Alla fel kan delas in i temporära (Temporary) och permanenta (Permanent).

Som exempel kan tillfälliga meddelanden som absent_subscriber stå för en abonnent som inte är tillgänglig eller inte är online, medan permanenta meddelanden innebär att abonnenten inte existerar. Beroende på de fel som uppstår, formas policyn för återutsändning av dessa meddelanden.

Till exempel, om abonnenten var upptagen i ett samtal och fick felet MT handset is busy, kan meddelandet skickas igen efter några minuter. Men om abonnenten har blockerat tjänsten för att ta emot meddelanden, kommer en återutsändning inte att ha någon mening. Listan över fel kan du hitta på SMSC:s sidor, till exempel hur detta.

Källa: habr.com