SMPP - Peer-to-Peer Short Message Protocol

Hej! Selvom instant messengers og sociale netværk erstatter traditionelle kommunikationsmetoder hver dag, forringer dette ikke populariteten af ​​SMS. Bekræftelse på et populært websted, eller en transaktionsmeddelelse gentager, at de lever og vil leve. Har du tænkt over, hvordan det hele fungerer? Meget ofte bruges SMPP-protokollen til at sende bulkmeddelelser, som vil blive diskuteret under snittet.

Habré havde allerede artikler om smpp, 1,2, men deres formål var ikke at beskrive selve protokollen. Selvfølgelig kan du straks starte fra kilden - specifikationer, men jeg synes, det ville være rart, hvis der var et resumé af indholdet. Jeg vil forklare at bruge v3.4 som eksempel.Jeg er glad for din objektive kritik.

SMPP-protokollen er en peer-to-peer-meddelelsesprotokol. Det betyder, at hver peer/hub-server er lige. I det enkleste tilfælde ser SMS-beskedskemaet sådan ud:

SMPP - Peer-to-Peer Short Message Protocol

Men hvis den nationale operatør ikke har en rute, beder han en mellemmand om denne til en fjerntliggende region - en SMS-hub. Nogle gange, for at sende en SMS, skal du bygge en kæde mellem flere lande eller endda kontinenter.

Om protokol

SMPP er en applikationslagsprotokol, der er baseret på udveksling af PDU'er og transmitteres over TCP/IP eller X25-sessioner til afsendelse af sms- og ussd-beskeder. Normalt bruges SMPP i vedvarende forbindelsestilstand, hvilket sparer tid. SMPP bruger en klient-server kommunikationsmodel.

Kommunikationstilstand

SMPP - Peer-to-Peer Short Message Protocol

Udvekslingen af ​​beskeder mellem afsender og SMS-center via SMPP kan udføres i følgende tilstande:

Sender (sender) - transmission af en meddelelse i én retning på skift
Modtager (modtager) - modtager kun besked fra SMS-centeret.
Transreceiver (transceiver) - Beskedudveksling mellem SMS-centeret og brugeren

Struktur

SMPP - Peer-to-Peer Short Message Protocol

Beskedens længde

En SMS-besked kan indeholde 70 tegn ved indtastning på kyrillisk og højst 157 latinske tegn + 3 UDH Sender du en SMS med et stort antal tegn, vil den blive opdelt i flere segmenter og kombineret i den modtagende enhed. Ved segmentering reduceres antallet af tegn med beskedhovederne, som angiver den del af beskeden. Derfor, når du sender en stor SMS-besked, indeholder den maksimalt 153 latinske tegn eller 67 ikke-typiske tegn.

Datakodningsskema

Dog skal tegn være kodet for at formidle et budskab. I SMPP-protokollen er et særligt felt ansvarlig for kodning - Data Coding Scheme eller DCS. Dette er et felt, der angiver, hvordan meddelelser skal genkendes. Derudover omfatter DCS-feltet:

  • tegnsættet, der definerer kodningen;
  • besked klasse;
  • anmodning om automatisk sletning efter læsning;
  • en indikation af meddelelseskomprimering;
  • sprog for udsendelse af beskeder;

Standard 7-bit alfabet (GSM 03.38). Det blev udviklet til beskedsystemet i GSM. Denne kodning er velegnet til engelsk og en række latinske sprog. Hvert tegn består af 7 bit og er kodet til en oktet.

UTF-16 (i GSM UCS2) For at inkludere manglende tegn i 7-bit alfabetet blev UTF-16-kodningen udviklet, som tilføjer yderligere tegn (inklusive kyrilliske) ved at reducere meddelelsesstørrelsen fra 160 til 70, denne type kodning næsten fuldstændig gentager Unicode.

8-bit brugerdefinerede data. Disse omfatter KOI8-R og Windows-1251. Selvom denne løsning ser ud til at være mere økonomisk sammenlignet med den samme UTF-16. Der er et rimeligt spørgsmål om kompatibilitet på forskellige enheder. Da begge enheder i dette tilfælde skal konfigureres på forhånd.

Besked klasse

  • Class0, eller flash, en besked gemt i telefonens hukommelse efter anmodning fra brugeren;
  • Klasse1 eller dem, der er gemt i telefonens hukommelse;
  • Klasse1 eller dem, der er gemt i telefonens hukommelse;
  • Klasse2, skal sikre, at beskeden er gemt i mobilterminalens hukommelse, ellers skal give besked til SMS-centret om umuligheden af ​​at gemme;
  • Klasse3 - i dette tilfælde skal telefonen sende en meddelelse om, at beskeden kan gemmes, uanset mængden af ​​hukommelse i enheden. Denne type meddelelse indebærer, at meddelelsen har nået sin destination;

Meddelelsestype

Tavs besked (SMS0) SMS-meddelelsestype uden indhold. En sådan SMS kommer uden meddelelse og vises ikke på enhedens skærm.

PDU'er

Hver pdu-operation er parret og består af en anmodning og et svar. For eksempel: en kommando, der siger, at en forbindelse er blevet etableret (bind_transmitter / bind_transmitter_resp), eller at en besked er blevet sendt (deliver_sm / levering_sm_resp)

SMPP - Peer-to-Peer Short Message Protocol

Hver pdu-pakke består af to dele - en header (header) og en body (body). Header-strukturen er den samme for enhver pdu-pakke: kommandolængde er pakkens længde, id er navnet på pakken, og statuskommandoen angiver, om meddelelsen blev sendt med succes eller mislykkedes.

Yderligere TLV-parametre

TLV (Tag Length Value) eller yderligere felter. Sådanne parametre bruges til at udvide funktionaliteten af ​​protokollen og er valgfrie. Dette felt er angivet i slutningen af ​​pdu-feltet. Som et eksempel, ved at bruge dest_addr_np_information TLV, kan du organisere overførslen af ​​oplysninger om portering af nummeret.

Ton og Npi

TON (Type of Number) parameter informerer SMSC om adresseringsformatet og netværkstypen.
NPI (Numbering Plan Identification) parameter, der angiver nummereringsplanen.

SMPP - Peer-to-Peer Short Message Protocol

Beskedkildeadresse eller alfanavn

Beskeder sendt til telefonen kommer i to varianter: numerisk og alfabetisk. Tal kan være lange (svarende til et telefonnummer) eller korte. Nogle gange har operatører begrænsninger for at sende fra neutrale navne, såsom Infosms, Alert osv. Nogle gange tillader operatører ikke trafik, hvis navnet ikke er registreret i deres netværk. Dette er dog mere et træk ved operatøren.

Indsendelsesstadier

SMPP - Peer-to-Peer Short Message Protocol

SMS-SEND sender MO FSM besked (kort besked fra mobilterminal)
SMS-INDSend RAPPORT — bekræftelse på, at beskeden blev sendt af SMSC
SRI SM (SendRoutingInfo) - SMSC modtager information fra HLR vedrørende abonnentens MSC/VLR placering
SRI SM RESP — svar fra HLR vedrørende abonnentpositionskød
MT-FSM - efter at have modtaget placeringen, sendes en besked ved hjælp af "Forward Short Message" operationen
MT-FSM-ACK — svar fra SMSC om, at beskeden er blevet sendt
SMS STATUS RAPPORT — SMSC sender beskedens leveringsstatus.

Status for meddelelseslevering

SMS STATUS RAPPORT kan have flere værdier:
DELIVRD besked blev leveret
AFVISET — besked afvist af SMS-centret
UDLØBET - meddelelsen fjernes fra sendekøen efter afslutningen af ​​TTL (meddelelsens levetid)
UDELIV - andre tilfælde af manglende levering
UKENDT- Intet svar modtaget.

Transmissionsfejl

Nogle gange er årsagerne til, at SMS-beskeder ikke leveres til abonnenten. Konsekvensen af ​​disse årsager er forekomsten af ​​fejl. Fejl returneres i PDUs_sms_resp. Alle fejl kan opdeles i midlertidige (midlertidige) og permanente (permanente).

Som et eksempel er absent_subscriber midlertidig, abonnenten er ikke tilgængelig eller ikke online, og permanent - abonnenten eksisterer ikke. Afhængigt af de fejl, der opstår, dannes der en politik for genafsendelse af disse meddelelser.

For eksempel, hvis abonnenten var optaget af at tale og modtog en MT-håndsæt er optaget-fejl, kan beskeden sendes igen efter et par minutter, men hvis abonnenten har blokeret beskedmodtagelsestjenesten, vil genafsendelse ikke give mening. Du kan finde en liste over fejl på SMSC-siderne, for eksempel som dette.

Kilde: www.habr.com

Tilføj en kommentar