8   IP telefonie

V roce 2006 jsme se zabývali především problematikou multiprotokolových směrovacích systémů pro VoIP, možnostem monitorování kvality hovoru na hlasových branách, implementacím SS7 (Signalling system no. 7) v prostředí softwarové ústředny Asterisk, otázkami decentralizované IP telefonní architektury a její bezpečnosti a technologii ENUM. Dále jsme se věnovali správě a rozvoji IP telefonní infrastruktury, jejíž uspořádání znázorňuje schéma.

[Obrázek]

Obrázek 8.1: Schéma infrastruktury IP telefonie sítě CESNET2

Síť IP telefonie CESNETu je tvořena následujícím stavebními prvky:

V roce 2006 bylo prvky sítě IP telefonie směrováno 1,25 milionu hovorů o celkovém trvání 3,9 milionu minut (65 tisíc hodin). Pro ilustraci přikládáme graf znázorňující využití IP telefonní sítě od roku 2002 vyjádřené počtem hodin hovorů za rok. Mírný pokles v tomto roce je způsoben transformací výstupu do PSTN (Public Switched Telephone Network), která znamenala přesun výstupu do PSTN. O přesunu bylo rozhodnuto vedením sdružení po zvážení aspektů legislativy a financování. Od března roku 2006 výstup do PSTN pro členy sdružení CESNET zajišťuje VIC ČVUT v Praze. Několik institucí nepokračovalo ve využívání výstupu, což způsobilo zmíněný mírný pokles v níže uvedeném grafu.

[Obrázek]

Obrázek 8.2: Průběh využití IP telefonní sítě v období 2002-2006

Začátkem listopadu jsme uspořádali seminář jehož program a přednášky jsou vystaveny na webu sdružení. Potěšil nás velký zájem, díky němuž se na seminář dostavilo přes osmdesát posluchačů. Tento zájem nás znovu přesvědčil o smyslu podobných akcí a v příštím roce plánujeme jeho opakování. Informace o práci aktivity lze nalézt také ve wiki, jež slouží zároveň jako hlavní zdroj informací pro založení účtu, konfiguraci klientů a následné používání účtu na multidoménovém SIP serveru.

8.1   Multiprotokolový dynamický směrovací systém

Naším cílem bylo vytvořit multiprotokolový systém pracující se standardy SIP, H.323 a MGCP, který by byl schopen směrování do různých typů VoIP sítí. Prioritní byla multiprotokolová podpora signalizací SIP a H.323 a podpora směrování s využitím standardu ENUM, který v ČR v roce 2007 přejde z ověřovacího do reálného provozu. Realizovali jsme multiprotokolový směrovací systému, který je postaven z pěti klíčových komponent a umožňuje připojení hlasových bran, koncových uživatelů, stejně jako propojení s ostatními poskytovateli IP telefonie. Celý systém jsme zakomponovali do stávajícího řešení sdružení CESNET v pilotním režimu, jež slouží pro ověřování funkcí. Zároveň ukazuje variabilitu připojení různých typů zařízení od různých výrobců s různými protokoly.

Komponenty realizovaného systému jsou následující:

[Obrázek]

Obrázek 8.3: Schéma multiprotokolového systému

Klíčovým prvkem testovaného systému je SIP softswitch firmy Siemens hipath8000 (dále jen h8k). Jde o robustní systém orientovaný na velké podniky nebo operátory. V rámci pilotního nasazení v ČR se nám podařilo SW část h8k získat pro CESNET zdarma a provedli jsme pouze nákup HW.

Pořízený systém h8k je postaven na Suse Linuxu a platformě IBM x346. Jádro tvoří dva servery IBM x346 v plně redundantním režimu. Systém je rozšířen o media server, který poskytuje pro h8k hlasová hlášení a audiokonference a do celku je připojen protokoly SIP a MGCP. Předpokládáme, že se nám media server podaří napojit přímo i na další prvky jako SER či Asterisk.

Hlavním komunikačním protokolem systému je SIP. Dále podporuje MGCP a komunikaci s H.323 zajišťuje protokolová brána. Správa systému probíhá pomocí dedikovaného serveru s aplikacemi iNMC a iSMC, případně přímo řádkovým rozhraním. Nasazená h8k podporuje IPSec s profily pro jednotlivé spoje, čímž je možno zajistit i zabezpečení komunikačního kanálu, které jsme doposud v CESNETu nepoužívali.

Zkušební směrovací prefixy jsou mapovány staticky pro zjednodušení a transparentnost při ověřování dostupnosti prvků. Veškeré další úvahy o propojování a adresaci jsme jednoznačně směrovali cestou ENUM, čili mapování E.164 a URI adres pomocí DNS. V současné době máme plně funkční a ověřený ENUM na SIP Express Routeru, kde kromě veřejného stromu e164.arpa využíváme přístupu do dalších stromů jakými jsou nrenum.net a privátní propojovací zóna.

Ve výsledném stavu by měl být ENUM podporován na prvcích SER, h8k, Asterisk a GnuGK. My jsme ovšem z technických důvodů realizovali ENUM na GnuGK, SER a Asterisku. GnuGk a SER jsou hraničními prvky pro komunikaci s dalšími VoIP sítěmi a na tyto stroje míří i ENUM NAPTR záznamy v DNS. Popis jednotlivých komponent řešení včetně konfigurací obsahuje technická zpráva 20/2006.

8.2   Monitorováni a měření kvality hovoru v prostředí VoIP

Pro monitorování hovorů a měření kvality mezi VoIP bránami v síti CESNET2 jsme zvolili analýzu dat z CDR (Call Detail Record) záznamů. Tyto záznamy jsou zasílány po ukončení hovoru bránou pomocí RADIUS protokolu na sběrné místo (RADIUS server). CDR záznamy obsahují kromě údajů o volaném, volajícím a době hovoru především údaje o kvalitě hovoru v položce ICPIF. Parametr ICPIF je specifikován v doporučení ITU-T G.113. Mnohem používanějším parametrem pro hodnocení kvality hovoru je ovšem MOS (Mean Opinion Score) dle ITU-T P.800 nebo R-factor. Ten je výsledkem výpočetního E-modelu popsaného v doporučení ITU-T G.107 a jedná se v současné době o nejuznávanější způsob hodnocení kvality. Všechny výše jmenované parametry lze navzájem převádět. Rovnice převodu uvádíme v technické zprávě 18/2006.

Výhodou námi navrženého řešení je jednoduchost získávání a předávání hodnot. Položky CDR záznamu jsou uloženy do databáze (MySQL) a vizualizace výsledků je provedena pomocí PHP ve formě WWW stránek. Pro hovory v rámci sítě CESNET se naměřená kvalita jen zřídka odchyluje od nejlepších hodnot. Horší výsledky se objevují při volání z domácích připojení používajících například několik skoků bezdrátovými sítěmi a podobně. Naměřené výsledky z CDR jsme porovnali s daty získanými zachycením vybraných hovorů přímo na síti, abychom potvrdili jejich správnost.

[Obrázek]

Obrázek 8.4: Příklad vyhodnocení hovorů

8.3   Implementace SS7 do prostředí softwarové ústředny

Pro nasazení SS7 do prostředí softwarové pobočkové ústředny (Private Brach Exchange, PBX) jsme využili program Asterisk. Ten kromě velkého množství funkcí srovnatelných s tradičními pobočkovými ústřednami nabízí také spolupráci s oběma typy současných telefonních sítí - PSTN i VoIP. Spolupráce s klasickou telefonní sítí je umožněna doplněním PBX o přídavné karty s analogovým nebo digitálním telefonním rozhraním (výrobci: Digium, Sangoma, Aculab). Tyto karty společně s moduly Asterisku umožňují zpracování množství signalizačních protokolů a nově také SS7.

SS7 je soubor protokolů umožňujících řízení v telefonní síti, který je využíván jako síťová signalizace v pevných i mobilních sítích po celém světě. Užívá se ke směrování hovorů v rámci sítě, sestavování a rušení spojení mezi ústřednami, dohledu nad spojením, dotazům do databází, ale také k vlastnímu řízení síťových prostředků. SS7 je robustní systém a vykazuje vysokou míru spolehlivosti. Tato signalizace byla původně určena pro řízení v rámci veřejných telefonních sítí a nyní se dostává až k samotným pobočkovým ústřednám.

Pro implementaci SS7 do prostředí softwarové ústředny jsme jako první řešení vyzkoušeli SS7 kanál (chan_ss7) od společnosti SIFIRA. Toto řešení je implementováno ve formě modulu, který se načítá do ústředny Asterisk obdobně jako jiné komunikační kanály (SIP, IAX,...). Modul podporuje SS7 protokoly síťové vrstvy MTP2 (Message Transfer Part) a MTP3 dle Q.703 a Q.704 a protokol aplikační vrstvy ISUP (ISDN User Part) dle Q.76x. Pro fyzickou komunikaci využívá zařízení s E1 rozhraním od společnosti Digium.

Testování modulu jsme provedli ve dvou fázích. Nejprve jsme propojili pomocí E1 rozhraní dvě pobočkové ústředny Asterisk s nainstalovaným SS7 kanálovým modulem a vyzkoušeli funkčnost. V druhé fázi jsme Asterisk připojili k veřejné telefonní ústředně Ericsson AXE umístěné ve výzkumném a vývojovém centru RDC na FEL ČVUT. V obou případech bylo řešení funkční a spolehlivé. Kromě základních hovorových služeb jsme otestovali také doplňkové služby, například identifikaci volajících, přidržení hovoru, signalizaci dalšího hovoru a jiné.

[Obrázek]

Obrázek 8.5: Příklad hovoru - výpis z konzole Asterisku

Druhým řešením vyzkoušeným v rámci projektu byla knihovna libss7, která pochází přímo od tvůrců pobočkové ústředny Asterisk a byla vydána v létě tohoto roku. I tato varianta podporuje SS7 protokoly MTP a ISUP podle doporučení ITU-T. Toto řešení jsme otestovali zatím lokálně oproti SS7 kanálu a hovorové služby fungují. Připravujeme technickou zprávu obsahující popis celého postupu.

V příštím roce plánujeme pokračovat v testování obou SS7 řešení. Rádi bychom druhé řešení vyzkoušeli také proti veřejné ústředně. U obou řešení bychom chtěli provést testy shody (interoperability tests) jak u základních služeb, tak u doplňkových služeb a také bychom rádi vyzkoušeli dlouhodobou spolehlivost při zátěžových testech.

V rámci implementace SS7 do prostředí softwarových pobočkových ústředen se zajímáme také o přenos SS7 v IP sítích. Tomu odpovídá IETF standard SIGTRAN, jehož implementací se zabývá například projekt OpenSS7. V současné době jsme v úvodní fázi průzkumu tohoto řešení.

8.4   Decentralizace VoIP infrastruktury

Doposud bylo řešení IP telefonie v CESNETu velmi centralizované, kdy brány institucí jsou připojeny na centrální řídící prvky. Toto řešení však přestává vyhovovat, pokud instituce chce zapojit větší množství IP klientů a systém integrovat do svého prostředí. Jako přechodový a ukázkový prvek decentralizace v prostředí SIP slouží multidoménový SIP Server. SIP server je provozován na PC platformě se systémem Linux, kde funkci vlastního SIP serveru plní SIP Express Router v multidoménovém režimu.

Podmínkou pro zřízení domény na tomto serveru je zřízení DNS SRV záznamů v doméně instituce a fungující eduroam v dané instituci. Eduroam je využit registračním systémem SERREG pro ověření identity uživatele při zakládání SIP účtu. Systém nevyužívá režim eduroam simple, přesto jej plánujeme převést na nově vznikající systém federativní AAI. Multidoménový server v současnosti obsluhuje domény: cesnet.cz, fel.cvut.cz, fjfi.cvut.cz, tul.cz, uvtuk.cuni.cz a ics.muni.cz. Cílem multidoménového serveru logicky není provozní nasazení pro všechny domény, ale slouží jako model, na němž si především techničtí pracovníci institucí mohou vyzkoušet fungování služby a pak přejít k jejímu nasazení v rámci své domácí instituce.

V tomto směru spolupracujeme například se ZČU v Plzni, kde je systém implementován v rámci projektu FR CESNETu, a dále připravujeme spolupráci při nasazení například na TUL, VŠCHT a JČU, kde již lokální řešení testují.

V rámci řešení tohoto úkolu jsme publikovali články v časopisech a přednášeli na odborných seminářích. Snažili jsme se především upozornit na bezpečnostní problémy decentralizované, tedy obecně mezidoménové komunikace a přispět k jejich řešení. Problematika důvěryhodné a bezpečné komunikace je obsažena i v plánu TERENA TF-ECS.

8.5   ENUM

ENUM slouží k mapování telefonních čísel na identifikátory služeb. Pravidla, která tento proces zajišťují, jsou uložena v systému DNS a těží z jeho distribuované podstaty a odzkoušeného provozu. Telefonní čísla jsou pro uložení do DNS upravena tak, že po odstranění všech nečíselných znaků se převrátí pořadí číslic, mezi ně se vloží oddělovač (tečka) a na konec se doplní označení příslušného stromu, například e164.arpa. Jako příklad pravidel můžeme uvést konkrétní záznam pro 9.8.2.5.5.3.4.2.2.0.2.4.e164.arpa:

   
  IN NAPTR 100 50 u "E2U+sip" "!^\+(.*)$!sip:\1@cesnet.cz!"          .
  IN NAPTR 200 50 u "E2U+h323" "!^\+(.*)$!h323:\1@gk1ext.cesnet.cz!" .

Aplikací těchto pravidel v dotazujícím se systému, nikoliv na DNS serveru, je telefonní číslo v E.164 formátu +420224355289 převedeno na URI (Uniform Resource Identifcator) sip:420224355289@cesnet.cz a h323:420224355289@gk1ext.cesnet.cz, která jsou použita pro směrování požadavku.

V ENUM rozlišujeme několik kategorií stromů. Základní rozdělení je na privátní a veřejné, rámci obou kategorií pak mohou existovat stromy uživatelské a infrastrukturní. Delegace ve veřejném uživatelském stromě e164.arpa podléhají validačnímu procesu. Národní podstromy jsou delegovány po schválení příslušným úřadem, například Ministestvem Informatiky ČR, a záznamy do něj mohou vkládat pouze uživatelé čísla, kteří prokáží fakt užívání například SMS validačním kódem.

Delegaci národní zóny veřejného uživatelského ENUM pro ČR (0.2.4.e164.arpa) drží sdružení CZ.NIC. V současnosti běží testovací provoz nového registračního systému zóny 0.2.4.e164.arpa a od ledna by měl být spuštěn ostrý provoz. Na přelomu roku se nám podařilo zajistit delegaci více jak 70 prefixů členů sdružení CESNET a následně naplnit zóny záznamy, které směřují hovory na hraniční prvky naší IP telefonní sítě a odtud na ústředny institucí.

Kromě veřejného stromu existuje celá řada stromů privátních. Jeden z nich provozuje iniciativa nrenum.net, která si klade za cíl především podporu ENUM v NREN, kde není možné využít veřejný strom. Vzhledem k tomu, že naše záznamy jsou ve veřejném stromě, podporujeme pouze dotazy do nrenum.net a účastníme se odborných diskuzí v tomto fóru. Další privátní zónu jsme zřídili prozatím pro interní testy propojování se SIP operátory v ČR. Administrační rozhraní pro privátní propojovací ENUM zónu je v současnosti v testovacím režimu. Jakmile budou testy úspěšně dokončeny hodláme nabídnout jeho využití i SIP operátorům, s nimiž jsem propojeni.

Příchozí směrování, které je zajištěno publikací NAPTR záznamů ve více jak sedmdesáti zónách, je tedy funkční. Odchozí směrování, tedy podpora na řídících prvcích, je plně realizováno na SIP proxy pro zóny e164.arpa, nrenum.net (ověřeno s kolegy v Evropě) a privátní peeringovou zónu. ENUM je v současnosti pro několik vybraných prefixů nasazen i v GnuGK (GK1-EXT).

CESNET je v souvislosti s ENUM často zmiňován, protože ENUM ve své sítí podporuje. Zároveň však nezapomínáme upozorňovat na jeho možná bezpečností úskalí.

8.6   TERENA TF-ECS

Jako jedna z nástupců úspěšné skupiny TF-VVC vznikla na podzim pracovní skupina Enhanced Communication Services (TF-ECS). Aktivně jsme se zapojili do přípravy programu a práce této pracovní skupiny. Její zaměření je poněkud užší než tomu bylo u TF-VVC a zabývá se problematikou pokročilých komunikačních služeb, jakými jsou audio a video komunikace obohacená i o prezenci a textové zprávy. Jedním ze zásadních úkolů je definice požadavků a následný návrh architektury pro důvěryhodné a bezpečné propojení mezi institucemi.

předchozí
obsah 		následující
fond rozvojemetacentrumliberouterpřenosyvideoservereduroamdalší servery