Csend a vonalban: amit a SIP-ről, az RTP-ről és a PSTN-bridge-ről tanultunk

Ha egy hívás felépül, de csak az egyik fél hallja a másikat, szinte biztosan NAT-probléma van a háttérben. Ezt az idei év első hónapjaiban tanultuk meg, amikor egy ügyfélszolgálati rendszerhez bejövő és kimenő hívásokat kellett kötni egy meglévő webes alkalmazáshoz. Addig a telefóniát csak kívülről ismertük. Aki évek óta VoIP-pal dolgozik, sok újat nem talál az alábbiakban. Aki webfejlesztőként most kezd bele, néhány hetet megspórolhat.

Hasonlít a HTTP-re, mégsem az

A SIP (Session Initiation Protocol) szövegalapú, kérés-válasz protokoll, fejlécekkel és státuszkódokkal. Webfejlesztőként ezért az ember azt hiszi, érti. Csakhogy a SIP kizárólag a hívás felépítését és lebontását intézi (INVITE, ACK, BYE). A hang egy teljesen külön csatornán, RTP-n megy, UDP felett. A kettőt az SDP-ben leírt IP-cím és port köti össze, és a hibák többsége pontosan ezen a ponton keletkezik.

A kodekek a második meglepetés. A G.711 (alaw, mulaw) tömörítés nélkül, 64 kbit/s-mal dolgozik, és minden eszköz ismeri. A G.722 szélesebb sávot ad. Az Opus 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, és csend van a vonalban. Ha egy köztes elem átkódol (transcoding), az CPU-t eszik és késleltetést ad. Infrastruktúra méretezése előtt ezt tudni kell.

Az egyirányú hang

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

Minden telepítésnél ezeket ellenőrizzük:

• 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 szerepel 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 rossz ötlet,
• WebRTC-oldalon van STUN, szükség esetén TURN szerver is, 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” típusú beállítások sokat segítenek. Mindent nem oldanak meg.

Trunk és bridge

Valódi telefonszámok hívásához és fogadásához kapcsolat kell a nyilvános telefonhálózathoz (PSTN). Ezt ma szinte mindig egy szolgáltató adja, SIP-trunkön keresztül: SIP-fiókot vagy IP-alapú hitelesítést kapunk, a hívásokat pedig a szolgáltató továbbítja a hagyományos hálózatba.

Nálunk a “PSTN-bridge” az a komponens, amely a saját rendszerünk (webalkalmazás, WebRTC-kliensek, hangfeldolgozás) és a SIP-trunk között ül. Ez irányítja a hívásokat, normalizálja a számformátumokat (E.164), hitelesít, és írja a hívásrekordokat (CDR). A trunk hitelesítési adatai soha nem kerülhetnek a kliensoldalra: a böngésző a bridge-hez regisztrál, a szolgáltatóval csak a bridge beszél.

A trunk kiválasztásakor több szolgáltatót kell kipróbálni. A hangminőség, a hívásfelépítési idő és a hibakódok kezelése jelentősen eltér, a dokumentáció pedig ritkán egyezik a valósággal.

Nyomja meg az egyest

Az interaktív hangválasz (IVR) technikailag állapotgép: hangfájlokat játszik le, DTMF-jelekre vár, és ezek alapján továbbirányít. A gyakorlatban három dolog számít:

• a DTMF háromféleképpen é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 az alkalmazás adatbázisában tartjuk, a telefonközpont konfigurációján kívül, így az ügyfél maga szerkesztheti,
• a “senki nem veszi fel” eset legalább annyira fontos, mint a sikeres kapcsolás: hangpostának, visszahívás-kérésnek vagy átirányításnak mindig definiálva kell lennie.

Ahol a hívásirányítás a webalkalmazással találkozik (ki a hívó, melyik ügyfél, kihez kerüljön), ott ér össze a telefónia és a szoftverfejlesztés. Mi itt látjuk a legtöbb üzleti értéket.

Számokban mérve

A telefóniában a “működik” nem igen-nem kérdés. Egy hívás felépülhet, és közben szaggathat, késhet, visszhangozhat. Minden hívásnál mérjük és naplózzuk:

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

Az adatok Prometheus-metrikaként és a hívásrekord részeként is megmaradnak. Panasz esetén így vissza tudjuk keresni, mi történt pontosan.

A telefónia sokkal kevésbé bocsát meg, mint a web. Nincs újratöltés gomb, és a felhasználó azonnal hallja, ha valami rossz. Itt tényleg számít az infrastruktúra minősége, és ettől vonzó a terület. 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.