Másodpercenként egy üzenet: SMS-gateway saját GSM-modemekkel

Egy GSM-modem nagyságrendileg másodpercenként egy SMS-t tud kiküldeni. Ebből a számból következik a saját SMS-infrastruktúra szinte minden tervezési döntése. A nyári VoIP-bejegyzés után többen megkérdezték, hogy az SMS-t is saját eszközökön kezeljük-e. A válasz: attól függ. Az elmúlt hónapokban két olyan rendszert építettünk, amelyekben a szöveges üzenetküldés volt a szolgáltatás gerince, és mindkettőnél ugyanaz a kérdés jött elő: aggregátor API vagy saját GSM-modemek.

A legrégebbi csatorna

Az SMS a legrégebbi digitális üzenetküldő csatorna, amelyet még mindig mindenki használ. Nem kell hozzá alkalmazás, adatkapcsolat vagy okostelefon. Egy egyszeri kód, egy időpont-emlékeztető vagy egy riasztás akkor is célba ér, ha a címzett tízéves készüléket használ.

A GSM-modem mellett a gyakorlatban négy érv szól:

• Belföldi számról érkezik az üzenet. Az aggregátoron át küldött SMS gyakran rövid számról vagy alfanumerikus feladóval jelenik meg. Egyes címzettek ezt spamnek nézik, egyes hálózatok szűrik.
• Kétirányú. Egy valódi SIM-kártyára válaszolni lehet, és a válasz oda érkezik, ahonnan a kérdés ment. Ügyfélszolgálati esetekben ez lényeges.
• Kiszámítható költség. Egy vállalati előfizetés korlátlan vagy nagy keretes SMS-csomaggal bizonyos volumenig olcsóbb a darabonkénti árnál.
• Függetlenség. A rendszer nem egy külső API rendelkezésre állásán múlik.

A hátrányok is valósak, ezekre a végén visszatérünk.

Modem pool, AT-parancsok

Komoly volumenhez a másodpercenkénti egy üzenet miatt több modem kell. Ezt USB-s modemekkel vagy több SIM-foglalatos ipari eszközökkel oldjuk meg, Linux alatt, soros porton keresztül.

A modemekkel AT-parancsokkal beszélünk. Ez egy évtizedek óta létező szöveges protokoll: AT+CMGS küldi az üzenetet, AT+CMGL listázza a beérkezetteket, AT+CSQ adja vissza a térerőt. Papíron egyszerű. A gyakorlatban:

• minden modemgyártó kicsit másképp értelmezi a szabványt, a hibaüzenetek pedig gyakran semmitmondóak,
• az ékezetes karakterekhez és a több részre bontott üzenetekhez PDU-mód (bináris kódolás) kell; a szöveges mód csak demóhoz elég,
• a soros portot egyszerre egy folyamat használhatja, ezért a modemenkénti hozzáférést sorosítani kell,
• a modemek időnként lefagynak, és ilyenkor csak USB-szintű újraindítás vagy tápkapcsolás segít.

A poolt ezért külön szolgáltatás kezeli. Modemenként egy worker birtokolja a soros portot, egy közös Redis-sorból veszi a feladatokat, és visszaírja az eredményt. Ha egy modem kiesik, csökken a kapacitás, a szolgáltatás megy tovább.

A SIM-ek külön munka

Az első rendszernél alábecsültük, hogy a SIM-kártyák üzemeltetése önálló feladat. Nyilván kell tartani, melyik SIM melyik modemben van, milyen előfizetés tartozik hozzá, hány üzenet ment ki rajta az adott időszakban, és mikor jár le a feltöltés vagy a keret. Az operátorok a rendellenesen nagy forgalmú SIM-eket felfüggeszthetik. Ezért a terhelést egyenletesen osztjuk el a pool tagjai között, és SIM-enként napi korlátot tartunk.

A kézbesítési jelentés (delivery report) a SIM-alapú küldés egyik nagy előnye. A hálózat azt is visszajelzi, hogy az üzenet megérkezett-e a készülékre, nem csak azt, hogy a központ átvette. Ehhez küldéskor kérni kell a jelentést, a beérkező jelentést pedig a hálózati üzenetazonosító alapján párosítani az eredeti üzenettel. Az azonosító modemenként ismétlődhet, ezért a párosítást modem és időablak szerint is szűkíteni kell.

Sor és újrapróbálkozás

Az SMS-küldés aszinkron. Az alkalmazás nem várja meg, amíg az üzenet kimegy: sorba teszi, és később kérdezi le az állapotát. A sor tervezésénél ezekre figyelünk:

• prioritás: az egyszeri belépési kód nem várhat egy marketingkampány mögött,
• újrapróbálkozás exponenciális várakozással, de csak modemhibánál; az érvénytelen szám tizedszerre sem lesz jobb,
• idempotencia: ugyanaz az üzenet ugyanarra a számra egy időablakon belül nem megy ki kétszer,
• a kimenő üzenetek és a beérkező válaszok egy közös, bérlőnként szűrt üzenetnaplóba kerülnek.

Az utolsó pont már egy másik témához vezet. Az SMS akkor igazán hasznos, ha nem önmagában áll. Az általunk épített rendszerekben a hívás, az SMS és a webes értesítés közös eseménymodellre épül. Ha a hívást nem veszik fel, megy egy SMS. Ha az SMS-re válaszolnak, a válasz bekerül az ügyfél idővonalába. Ezt a mintát egyre inkább alapkövetelménynek látjuk.

Az aggregátor mellett

A legtöbb esetben az aggregátor a jobb választás. A saját modem pool akkor éri meg, ha a belföldi szám, a kétirányúság vagy a függetlenség konkrét üzleti követelmény, és van, aki a hardvert üzemelteti. Nemzetközi küldéshez, nagy (napi több tízezres) volumenhez, vagy ha egyszerűen nincs kapacitás modemeket pásztorolni, marad az aggregátor API: egy HTTP-hívás, egy kézbesítési webhook, a hónap végén egy számla.

Egy dolgot mindkét esetben megcsinálunk: absztraháljuk a küldő réteget. Az alkalmazás belső interfészen keresztül küld üzenetet. Hogy mögötte modem, aggregátor vagy mindkettő dolgozik (például modem belföldre, aggregátor külföldre), az konfiguráció kérdése. Így egy modemhiba vagy egy szolgáltatóváltás nem érinti az üzleti logikát.