SMS-gateway és GSM-modemek: amikor a régi technológia még mindig a legmegbízhatóbb

A nyári VoIP-bejegyzés után többen kérdezték, hogy az SMS-t is saját infrastruktúrán kezeljük-e. A válasz: attól függ, és ez a bejegyzés arról szól, mitől. Az elmúlt hónapokban két olyan rendszert építettünk, ahol a szöveges üzenetküldés nem kiegészítő funkció volt, hanem a szolgáltatás gerince, és mindkettőben előkerült a kérdés: aggregátor API vagy saját GSM-modemek.

Miért egyáltalán GSM-modem?

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

A GSM-modem melletti érvek a gyakorlatban:

• Belföldi számról érkezik az üzenet. Az aggregátoron keresztül küldött üzenet gyakran rövid számról vagy alfanumerikus feladóval jelenik meg, amit egyes címzettek spamnek néznek, egyes hálózatok pedig szűrnek.
• Kétirányú. Egy valódi SIM-kártyára válaszolni lehet, és a válasz ugyanoda érkezik, ahonnan a kérdés ment. Ez ügyfélszolgálati esetekben 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, mint a darabonkénti ár.
• Függetlenség. Nem egy külső API rendelkezésre állásától függ a rendszer.

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

A modem pool és az AT-parancsok

Egy modem másodpercenként nagyságrendileg egy üzenetet tud kiküldeni, ezért bármilyen komoly volumenhez több modem kell. Ezt USB-s modemek vagy több SIM-foglalatos ipari eszközök formájában szoktuk megoldani, 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. Egyszerűnek hangzik, de a gyakorlatban:

• minden modemgyártó kicsit másképp értelmezi a szabványt, és a hibaüzenetek gyakran semmitmondóak,
• a PDU-mód (bináris kódolás) kell ahhoz, hogy ékezetes karakterek és több részre bontott üzenetek megbízhatóan működjenek; a szöveges mód csak demóhoz jó,
• 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 csak egy USB-szintű újraindítás vagy tápkapcsolás segít.

A poolt ezért egy külön szolgáltatás kezeli: modemenként egy worker, amely a soros portot birtokolja, egy közös Redis-sorból veszi a feladatokat, és az eredményt visszaírja. Egy modem kiesése így csak a kapacitást csökkenti, nem a szolgáltatást állítja le.

SIM-kezelés és kézbesítési jelentések

Amit az első rendszernél alábecsültünk: 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á, mennyi ü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 a pool tagjai között egyenletesen osztjuk el, és SIM-enkénti 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 visszajelzi, hogy az üzenet megérkezett-e a készülékre, nem csak azt, hogy a központ átvette. Ehhez a küldéskor kérni kell a jelentést, a beérkező jelentést pedig párosítani az eredeti üzenettel a hálózati üzenetazonosító alapján. 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.

Üzenetsor és újrapróbálkozás

Az SMS-küldés aszinkron. Az alkalmazás nem várja meg, amíg az üzenet kimegy, hanem egy sorba teszi, és később kérdezi le az állapotát. Amit a sor tervezésekor figyelembe veszü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 a modemhibáknál; az érvénytelen szám nem lesz jobb tízedszerre sem,
• 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 vezet át egy másik témába: az SMS akkor hasznos igazán, ha nem önmagában áll. Az általunk épített rendszerekben a hívás, az SMS és a webes értesítés egy közös eseménymodellre épül. Ha a hívást nem veszik fel, megy egy SMS; ha az SMS-re válaszolnak, az bekerül az ügyfél idővonalába. Ezt a mintát egyre inkább alapkövetelménynek látjuk.

Mikor válasszunk inkább aggregátort?

Őszintén: a legtöbb esetben. 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, az aggregátor API a jobb választás: egy HTTP-hívás, kézbesítési webhook, számla a hónap végén.

Amit mindkét esetben megteszünk: a küldő réteget absztraháljuk. Az alkalmazás egy belső interfészen keresztül küld üzenetet, és az, hogy mögötte modem, aggregátor vagy mindkettő van (például modem belföldre, aggregátor külföldre), konfigurációs kérdés. Ez teszi lehetővé, hogy egy modemhiba vagy egy szolgáltatóváltás ne érintse az üzleti logikát.