8   IP telefonie

IP telefonie patří k progresivním aplikacím a získává čím dál více uživatelů. Sdružení CESNET věnuje patřičné úsilí rozvoji a zkvalitnění služeb IP telefonní infrastruktury. V roce 2005 jsme řešili otázky související s transformací výstupu do veřejné sítě, zabývali jsme se hodnocením kvality hovoru, připravili jsme pro členy možnost adresování využívající ENUM, věnovali jsme se implementacím IP telefonie na otevřených řešeních jako je GnuGK, SER a Asterisk. V závěru roku se v rámci aktivity uskutečnil seminář o IP telefonii, kde byli posluchači informováni o rozsahu stávajících služeb a připravovaných novinkách.

Během letošního roku bylo přes síť CESNET2 uskutečněno více než 1,5 mil. hovorů a VoIP infrastruktura umožnila letos prohovořit celkově 4,5 mil. minut, přičemž mezi univerzitami v rámci CESNET2 to bylo téměř 0,7 mil. minut. Tato čísla jsou nepřehlédnutelná.

8.1   Stávající stav

Jako každoročně jsme i letos zaznamenali zájem o připojení dalších ústředen členů sdružení, konkrétně se jednalo o SLU Opava v Karviné, MZLU v Brně a tři pražské ústavy AV ČR - Geologický ústav, Ústav chemických procesů a Ústav experimentální botaniky. Aktuální seznam institucí zapojených do projektu IP telefonie lze nalézt na stránce s informacemi o naší síti. Připojené instituce používají stejná telefonní čísla jako ve veřejné síti, ale CESNET má od ČTÚ navíc přidělen i prefix pro přístup do sítě IP telefonie ve tvaru 950 0, pro IP telefony tedy máme k dispozici sto tisíc čísel. Dostupnost těchto čísel byla prověřena ze sítí Českého Telecomu, GTS Novera a Oskar. V souvislosti s transformací výstupu sdružení CESNET do veřejné telefonní sítě se ale objevil problém s voláním do VTS, jelikož identifikace volajícího je vázána na výstup umístěný v sídle sdružení. Proto jsme pozastavili distribuci těchto čísel mezi členy.

[Obrázek]

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

Na obrázku najdete schéma sítě s prvky infrastruktury IP telefonie. Jednotlivé hlasové brány členů jsou registrovány na vnitřní GK1 a GK2. Dostupnost z Internetu zajišťují hraniční gk1ext a gk2ext. Veškeré brány jsou schopné komunikovat obousměrně protokolem H.323 a většina je schopna přijmout příchozí spojení protokolu SIP. Pokud je zapotřebí překlad mezi SIP a H.323, spojení prochází přes překladovou bránu. Můžeme tedy konstatovat, že máme funkční síť s podporou obou signifikantních protokolů používaných ve VoIP. Kromě řídících prvků GK1, GK2, gk1ext a gk2ext pro H.323, máme nasazen SIP server SER, který obsluhuje volání protokolem SIP.

8.2   Kvalita hovoru

Jako kritéria pro určování kvality hovoru používáme R-faktor a MOS. K měření používáme analyzátor Surveyor, který umožňuje konvertování získaného R-faktoru na parametry Mean Opinion Score (MOS), Listener Quality (MOS-LQ), Mean Opinion Score PESQ (MOS-PQ) a Conversational Quality (MOS-CQ). Síťový R-faktor (Network R-factor) je generován na základě zhoršení způsobeného fyzickým zařízením. Uživatelský R-faktor (User R-factor) sčítá vnímavostní efekty se zhoršením způsobeným zařízením (např. aktuálnost a zpoždění). Komponenty pro výpočet R-faktoru jsou popsány v doporučení ITU-T G.107. Výpočet je založen na E-modelu a kombinuje všechny přenosové parametry důležité pro zvažované spojení. Obecně lze oblast měření kvality volání rozdělit na tři základní typy:

Listening Quality
Měření odvolávající se na skutečnost, jak uživatelé hodnotí, co slyší během volání.
Conversational Quality
Měření se odkazuje na skutečnost, jak uživatelé hodnotí celkovou kvalitu volání, a to na základě kvality poslechu a jejich schopnosti konverzace během tohoto volání.
Transmission Quality
Měření se odkazuje na kvalitu síťového spojení používaného pro přenos hlasového signálu. Konkrétně se tedy jedná o měření kvality síťové služby, a to jako protikladu ke specifické kvalitě volání.
[Obrázek]

Obrázek 8.2: Zobrazení statistik pro Details - Audio Channel Quality

Obrázek obsahuje zobrazení statistik pro Details - Audio Channel Quality z analyzátoru. Při měření získáváme kvalitativní parametry spojení, jimiž jsou:

Výstupem z oblasti měření kvality hovorů jsou v roce 2005 dvě technické zprávy [VoZ05a] zabývající se kvalitou hlasu v prostředí VoIP s praktickými výsledky a [VoZ05] popisující analýzu pomocí aplikace Surveyor.

8.3   Podpora H.323

V letošním roce jsme pokračovali v rekonfiguraci hraničního gk1ext.cesnet.cz a řešili jsme problémy autentizace, volání přes NAT a začlenění do GDS.

V současné době se autentizují pouze IP telefony, které jsou přímo registrovány na gk1ext. Autentizace vyžaduje uživatelské jméno a heslo (hash MD5), účty jsou vytvářeny na vyžádání. Zaregistrovali jsme několik požadavků na propojení GK, z nichž nejvýznamnější bylo propojení s národním GK akademické sítě v Litvě. Každopádně bilaterární dohody o propojení nejsou zajímavé, protože v rámci NREN je strategie orientována na použití GDS (Global Dialing Scheme), což obnáší vytvoření národního gatekeeperu a jeho propojení na světové GK. Přínosem je možnost volat a být volán ze všech registrovaných sítí (převážně národní akademické sítě, univerzity a výzkumné ústavy). Sdružení CESNET využívá GDS a českým národním GK je gk1ext.cesnet.cz.

Problémy, které mají uživatelé s NAT, jsme se pokusili vyřešit nasazením proxy režimu pro neveřejné adresy na gk1ext. Mechanismus je takový, že pokud detekuje gk1ext přihlášení uživatele, který je za NATem, funguje pro tohoto uživatele jako signalizační i RTP proxy a veškerá komunikace probíhá přes gk1ext. Ověřili jsme funkčnost pro Full Cone NAT, pro symetrický NAT ovšem nastavení proxy režimu nestačí. Řešením je použití VPN klienta a přístup na VPN koncentrátor konkrétní instituce. V případě řešitelů výzkumného záměru sdružení lze pochopitelně využívat CESNET VPN, na kterém jsou řešitelé autorizováni pomocí TACACS+ účtu.

Výstupem z oblasti konfigurace gk1ext je technická zpráva [VoN05] s názvem "GNU Gatekeeper a jeho nasazení v síti CESNET2".

V první polovině roku 2005 jsme otestovali IP telefony, které byly zapůjčeny od VoIP operátorů v ČR prostřednictvím redakce časopisu Connect!. Výsledky byly publikovány v květnovém vydání časopisu. Pro použití s H.323 a GnuGK doporučujeme každopádně IP telefon, který umožňuje autentizaci. Pokud autentizaci nezvládá, je možné nastavit aspoň ověření uživatele proti IP adrese, což je rovněž popsáno v technické zprávě [VoN05].

8.4   Asterisk

V letošním roce jsme se zabývali podporou protokolu IAX2, SIP a dostupností H.323 kanálu. Testovali jsme telefony AT-320, a to v režimu IAX2, H.323 i SIP. Zajímavou oblastí je ovládání Asterisku prostřednictvím příkazového řádku (Command Line Interface, CLI), stejně jako ovládání GnuGk pomocí rozhraní pro Telnet.

IAX2 je velmi dobrou volbou pro průchod přes NAT. Největším problémem je, že není dosud standardizován. V současné době vyšel nový internet draft, který nahradil předchozí verzi návrhu s prošlou platností, dokončení standardizace se očekává v polovině roku 2006. Dokument popisuje protokol určený pro řízení aplikační vrstvy a přenášené médium, vytvoření, modifikaci a ukončení relace prostřednictvím sítě s protokolem IP. IAX2 je primárně určen pro řízení přenosu hlasu přes IP, může být však použit také pro streaming různorodých dat (audio, video). Primárním cílem protokolu je minimalizovat nezbytnou šířku pásma určenou pro signalizaci a vlastní přenášené médium. Cílem je také poskytnout přirozenou podporu pro NAT transparentnost. Je použit pouze jeden UDP port, pro nějž není problémem nakonfigurovat konkrétní firewall.

Základní vlastnosti protokolu:

8.4.1   Kanál H.323

V současnosti existuje několik nezávislých implementací kanálu H.323 do systému Asterisk (h323, oh323, ooh323c, woomera). V našem případě jsme se zabývali implementací kanálu oh323 a možností jeho využití pro komunikaci H.323 terminálů. Tento kanál se nám podařilo společně s GnuGk přivést do stavu částečné funkčnosti. V současnosti jsme schopni k softwarové ústředně Asterisk připojit terminály typu SIP, IAX2 a H.323. V souvislosti s použitím telefonů optiPoint (300 advance, 400 standard) se vyskytl problém korektního zobrazení příchozího telefonního čísla. Tyto telefony v současnosti nezobrazují číslo korektně, například softwarový telefon SJPhone však ano.

H323
Jedná se o kanál obsažený ve zdrojové distribuci Asterisku v adresáři /channels/h323. Tento kanál funguje pouze jako H.323 gateway, ne však jako gatekeeper.
Oh323
Implementace H.323 kanálu (ve skutečnosti vůbec první implementace) nazvaná Asterisk-oh323, která je stále aktivně vyvíjena, a to projektem firmy InAccess Network.

V současné době se u implementací H.323 do Asterisku potýkáme s následujícími problémy:

GnuGk je využit ve funkci gatekeeperu potřebného pro podporu H.323 kanálu v softwarové ústředně Asterisk. Zatím jsme testovali pouze konfigurace umožňující přihlášení libovolného terminálu, omezené požadavkem na tvar telefonního čísla a příslušnou definicí čísla v souboru číslovacího plánu. Pokročilejší autorizace je řešena v technické zprávě [VoN05].

Výstupem z oblasti implementace softwarové ústředny Asterisk je technická zpráva [WZV05] s názvem "Asterisk a jeho použití".

8.5   SIP

Základním řídícím prvkem implementace protokolu SIP v síti CESNET2 je SIP proxy server běžící na platformě Linux a SIP Express Router (SER). Server plní funkci registračního a proxy serveru. Na tento prvek mohou být zaregistrováni SIP klienti ve formě softwarových balíčků i hardwarových telefonů a komunikovat přes něj s okolním světem. SIP proxy provádí také směrování hovorů na brány připojených institucí podle telefonních prefixů. Většina bran je připojena přímo protokolem SIP. Pouze tam, kde to hardware nedovoluje, jsou hovory směrovány přes SIP/H.323 bránu. Proxy server také obsluhuje příchozí a odchozí hovory do jiných SIP domén, jako například iptel.org, bts.sk, aarnet.edu.au.

[Obrázek]

Obrázek 8.3: Schéma propojení SIP a H.323 sítí

Hovory (iniciované z ústředen za branami, z veřejné telefonní sítě a z H.323 IP klientů) směřující do SIP sítě, procházejí přes SIP/H.323 bránu. S nasazením nového směrovacího systému v příštím roce bude všude, kde je to možné, použit přímo protokol SIP bez překladu. Jako SIP/H.323 bránu momentálně používáme zařízení CISCO IOS IP2IP gateway. Její schopnosti nejsou například v oblasti ENUM pro nás zcela vyhovující, proto se pokusíme i o využití Asterisku, který má však zatím rezervy v implementaci H.323.

SIP proxy funguje v takzvaném multidoménovém režimu. To znamená, že kromě své mateřské domény cesnet.cz je schopna obsloužit i domény jiných institucí. Naším záměrem je, aby si instituce tímto způsobem vyzkoušely SIP systém a pak přenesly SIP proxy přímo k sobě a integrovaly SIP do svých systémů ještě lépe, než tomu může být v případě naší multidoménové proxy.

Zřízení domény na multidoménové proxy je nutné doprovodit vytvořením SRV záznamu v příslušné DNS doméně instituce, aby bylo zajištěno správné směrování požadavků. Potenciální uživatelé si zřizují účet pomocí webového formuláře. Identita žadatele je ověřena prostřednictvím infrastruktury eduroam, která využívá AA systémů domovských institucí. V následujících letech, s nástupem nové distribuované AAI, předpokládáme ještě lepší a důslednější využití AAI systémů, především v oblasti mezidoménové autentizace a přístupu ke sdíleným službám.

Spolu se SIP serverem jsme spustili nový web IpTelWiki věnovaný především implementaci SIPu v síti CESNET2. Na IpTelWiki je možné získat informace o vlastním protokolu SIP, o jeho integraci do IP-telefonní sítě CESNET2, o vytvoření SIP účtu a volání přes SIP. Naším cílem je, aby se tento web stal místem pro sdílení informací o IP telefonii v rámci co nejširší komunity uživatelů a správců. Tyto stránky se postupně stanou webem celé aktivity IP telefonie, který doposud naleznete na webu sdružení. Kromě informačních stránek je součástí systému také webové rozhraní SIP serveru SerWeb, které umožňuje uživatelům správu účtů a klientských registrací a poskytuje další údaje o jeho využívaní, jako jsou záznamy o provedených hovorech.

8.6   ENUM

Sdružení CZ.NIC, držitel delegace národní domény 0.2.4.e164.arpa, připravuje testovací provoz. Delegace domén pro prefixy 234 680 a 950 0, které jsme získali již před spuštěním testovacího provozu, jsou momentálně jedinými delegacemi v celém stromu 0.2.4.e164.arpa.

Abychom mohli naplno využít potenciál technologie ENUM, připravili jsme pro členy sdružení zapojené do projektu IP telefonie možnost vyřízení delegace našim prostřednictvím. Cílem je dosáhnout úplného pokrytí IP telefonní sítě CESNET2 ENUM záznamy. Instituce si mohou spravovat své záznamy na svých jmenných serverech, nebo jim nabízíme možnost správy koncových záznamů na DNS serverech sdružení. Mezi těmito variantami je možné přecházet bez nutnosti interakce s držitelem delegace národní domény. S přechodem do ostrého provozu, který se předpokládá na začátku roku 2007, požádají instituce pouze některého z registrátorů o registraci podle nově vytvořených pravidel pro 0.2.4.e164.arpa a záznamy zůstanou funkční. Zde je vhodné připomenout, že registrace v doméně 0.2.4.e164.arpa probíhají odlišně od klasických domén, kvůli své vazbě na veřejné telefonní číslo. Odezva na připravený postup byla příznivá a předpokládáme vyřízení delegace pro valnou většinu prefixů připojených institucí ještě do konce roku 2005.

V rámci organizace TERENA jsme se zapojili do diskusí o novém směrovacím systému, který postupně nahradí GDS hierarchii. Jednou z možností je právě využití technologie ENUM. Nevýhodou GDS je jeho pevná vazba na H.323, kterou by ENUM řešil. Vzhledem k různé úrovni národních implementací ENUM, půjde pravděpodobně o použití privátního stromu. To pro nás znamená pouze jednoduchou operaci, kdy informace již publikované do stromu veřejného budou publikovány i do privátního stromu.

8.7   CCM a aplikace

V průběhu letošního roku jsme provedli pokusné připojení IVR (Interactive Voice Response) aplikací na rozhraní SW a HW klientů. V první fázi jsme použili IVR integrované v CCM a jako aplikaci jsme použili VoiceBox pro zanechání hlasových zpráv nepřítomnému uživateli. Problémy nastaly při využití distribuované architektury jednotlivých komponent takto navrženého systému. Vypadávalo spojení mezi úložištěm dat a vlastním CCM, který řešil signalizační a distribuční část této aplikace. V další fázi jsme se snažili o vybudování takovéhoto systému v návaznosti na jakoukoliv obecnou databázi, v níž jsou uloženy záznamy hlasových zpráv, a o jednotnou autentizaci uživatele VoIP klienta pro všechny aplikace s ním svázané. Jako základní postup jsme úspěšně vyzkoušeli rozhraní LDAP. Předpokládáme zprovoznění hlasového záznamníku v první polovině následujícího roku. Současně budou prováděny zkoušky pro klienty komunikující jinými signalizačními protokoly a zapojení jakýchkoliv obecných IVR do tohoto systému.

předchozí
obsah 		následující
další weby:fond rozvojemetacentrumCzechLightpřenosyvideoservereduroameduID.cz