VoIP, SIP és PSTN-bridge: belépés a telekom világába

Az idei év elején léptünk be egy olyan területre, amelyet korábban csak kívülről ismertünk: a telefóniába. Egy ügyfélszolgálati rendszerhez kellett bejövő és kimenő hívásokat kezelni, a meglévő webes alkalmazással összekötve. Az alábbiakban azt írjuk le, mit tanultunk az első hónapokban. Aki évek óta VoIP-pal foglalkozik, annak ez ismerős lesz; aki webfejlesztőként most nézi meg először, annak talán megspórol néhány hetet.

A SIP nem HTTP, még ha úgy is néz ki

A SIP (Session Initiation Protocol) szövegalapú, kérés-válasz protokoll, fejlécekkel és státuszkódokkal, ezért webfejlesztőként az ember azt hiszi, érti. Az első meglepetés, hogy a SIP csak a hívás felépítéséről és lebontásáról szól (INVITE, ACK, BYE), a hang maga egy teljesen külön csatornán, RTP-n megy, UDP felett. A két protokoll közötti kapcsolatot az SDP-ben leírt IP-cím és port teremti meg, és pontosan ez az a pont, ahol a legtöbb hiba történik.

A második meglepetés a kodekek. A G.711 (alaw, mulaw) 64 kbit/s sávszélességet használ, tömörítés nélkül, és minden eszköz ismeri; a G.722 szélesebb sávot ad, az Opus pedig a WebRTC világából jön, és jól tűri a hálózati ingadozást. Ha a két oldal nem talál közös kodeket, a hívás felépül, de csend van. Ha a köztes elem átkódol (transcoding), az CPU-t eszik és késleltetést ad. Ezt tudni kell, mielőtt az ember infrastruktúrát méretez.

NAT és RTP: ahol az egyirányú hang születik

A klasszikus hiba: a hívás felépül, az egyik fél hallja a másikat, a másik nem. Ez szinte mindig NAT-probléma. A SIP-üzenetben szereplő privát IP-cím a másik oldalról nem elérhető, az RTP-csomagok rossz helyre mennek.

Amit ebből következően minden telepítésnél ellenőrzünk:

• a SIP-szerver külső címe explicit be van állítva, nem a hálózati interfészről találja ki,
• az RTP-porttartomány (jellemzően több ezer UDP port) nyitva van a tűzfalon, és ugyanaz a tartomány van a szerveren és a tűzfalszabályban,
• a Dockerben futó SIP-komponensek host hálózaton futnak, vagy az RTP-tartomány kifejezetten publikálva van; a bridge-hálózat port-átirányítása több ezer UDP portnál nem jó ötlet,
• WebRTC-oldalon STUN és szükség esetén TURN szerver van, mert a böngésző szimmetrikus NAT mögül másképp nem jut ki.

Az rtp_symmetric és a hasonló “bízz abban a címben, ahonnan a csomag jött” beállítások sokat segítenek, de nem oldanak meg mindent.

SIP-trunk és PSTN-bridge

Ahhoz, hogy a rendszerünk valódi telefonszámokat hívjon és fogadjon, kapcsolat kell a nyilvános telefonhálózathoz (PSTN). Ezt ma szinte mindig SIP-trunkön keresztül biztosítja egy szolgáltató: kapunk egy SIP-fiókot vagy IP-alapú hitelesítést, és a hívásokat a szolgáltató továbbítja a hagyományos hálózatba.

A “PSTN-bridge” nálunk azt a komponenst jelenti, amely a saját rendszerünk (webalkalmazás, WebRTC-kliensek, hangfeldolgozás) és a SIP-trunk között ül. Ez a réteg felel a hívások irányításáért, a számformátumok normalizálásáért (E.164), a hitelesítésért és a hívásrekordok (CDR) írásáért. Fontos, hogy a trunk hitelesítési adatai soha ne kerüljenek a kliensoldalra: a böngésző a bridge-hez regisztrál, és a bridge beszél a szolgáltatóval.

Tanulság a trunk-választásról: több szolgáltatóval érdemes tesztelni, mert a hangminőség, a hívásfelépítési idő és a hibakódok kezelése jelentősen eltér, és a dokumentáció ritkán egyezik a valósággal.

IVR és hívásirányítás

Az interaktív hangválasz (IVR) az, ami “nyomja meg az egyest” formában mindenki ismer. Technikailag egy állapotgép, amely hangfájlokat játszik le, DTMF-jeleket vár, és ezek alapján továbbirányít. Néhány dolog, ami a gyakorlatban számít:

• a DTMF három módon érkezhet (in-band hangként, RFC 2833 RTP-eseményként, SIP INFO üzenetként), és ha a lánc két eleme másban egyezett meg, a gombnyomás elveszik,
• az IVR-menü szerkezetét nem a telefonközpont konfigurációjában, hanem az alkalmazás adatbázisában tartjuk, hogy az ügyfél maga szerkeszthesse,
• a hívásirányításnál a “senki nem veszi fel” eset legalább olyan fontos, mint a sikeres kapcsolás: hangposta, visszahívás-kérés vagy átirányítás mindig legyen definiálva.

A hívásirányítás összekötése a webalkalmazással (ki a hívó, milyen ügyfél, kihez menjen) az a pont, ahol a telefónia és a szoftverfejlesztés találkozik, és ahol a legtöbb üzleti értéket látjuk.

Hívásminőség mérése

A telefóniában a “működik” nem bináris. Egy hívás felépülhet, és közben szaggathat, késhet, visszhangozhat. Amit mérünk és naplózunk minden hívásnál:

• csomagvesztés, jitter és körbejárási idő az RTCP-jelentésekből,
• a hívásfelépítés ideje (INVITE-tól a 200 OK-ig),
• a hívás lezárásának oka (normál, elutasított, időtúllépés, hálózati hiba) SIP-státuszkóddal,
• a becsült MOS-érték, hogy egy számmal is lehessen trendet nézni.

Ezek Prometheus-metrikákként és a hívásrekord részeként is tárolódnak, így egy panasz esetén vissza tudjuk keresni, mi történt pontosan.

A telefónia sokkal kevésbé megbocsátó, mint a web: nincs újratöltés gomb, és a felhasználó azonnal hallja, ha valami nem jó. Ez egyben az, ami vonzóvá teszi: itt tényleg számít az infrastruktúra minősége. A következő hónapokban a GSM-modemekről és az SMS-küldésről is írunk, mert a hang mellé az is előkerült.