Menu Zavrieť

ENUM – Telephone Number Mapping

ENUM (Projekt z predmetu Sieťové architektúry)

Vypracoval:

Tomáš Bohuš
Miroslav Lupták
5ZR021
2009/2010

Téma projektu:

– princíp ENUMu

– stav na Slovensku a v Čechách

– konfigurácia DNS servera a ENUMu – implementácia v DNS systéme BIND 9

Použité zdroje:

 

Všeobecné teoretické zdroje

– http://www.ietf.org/

– http://www.iana.org/

– http://en.wikipedia.org/, http://cs.wikipedia.org/, http://sk.wikipedia.org/

– http://enum.nic.cz/

– http://www.telecom.gov.sk/

– https://sip.cesnet.cz/

– http://crawler.enum.at/

– http://www.enum.at/

– http://www.domainmaster.cz/beta/napoveda/

– http://www.vus.sk/broadband/

– http://www.lupa.cz/

– http://fwd.etrend.sk/

– http://dns.kify.com/

– http://www.ripe.net/enum/

 

DNS – BIND 9

– http://debianclusters.cs.uni.edu/index.php/Name_Service:_DNS_and_BIND

– http://tldp.org/HOWTO/DNS-HOWTO.html

– http://www.debian.org/doc/manuals/network-administrator/ch-bind.html

– http://mit.edu/sip/sip.edu/dns.shtml

 

OpenSER

– http://www.opensips.org/Resources/Documentation/

– http://www.kamailio.org/dokuwiki/

– http://www.sipwise.com/index.php/products?start=3

– http://openser.oralnet.co.uk/

– http://www.voip-info.org/

– http://nil.uniza.sk/

– Flavio E. Goncalves – Building Telephony Systems with OpenSER

 

ENUM modul

– https://www.nrenum.net/

– http://www.opensips.org/html/docs/modules/devel/enum.html

 

VoIP Softphone – XLite

– http://www.counterpath.com/x-lite.html

– http://www.ip-pabx.com/xliteconf/

– http://www.simtex.com.au/support/manuals/SimtexXLITEConfigv1-1.pdf

 

1. Princíp ENUMu

 

ENUM všeobecne

 

          Skratka ENUM pochádza zo spojenia „E.164 Number Mapping“ (alebo Telephone Number Mapping), čo doslova znamená „mapovanie telefónnych čísiel“. E.164 je doporučenie organizácie ITU-T, ktoré popisuje číslovací plán hlavne pre sieť PSTN (telefónnu sieť). Telefónne číslo podľa tohto doporučenia začína znakom „+“ a za ním môže nasledovať až 15 číslic, teda napr. + 421 415 134 301 (tel. č. na Katedru informačných sietí).

 

          S návrhom využiť ENUM prišiel pôvodne švéd Patrik Fältström pracujúci pre spoločnosť Cisco Systems Inc., ktorý ho popísal v dokumente RFC 2916 a neskôr v RFC 3761. Ale čo to ten ENUM vlastne je? Zjednodušene povedané, ENUM je štandard prijatý organizáciou IETF popisujúci zjednotenie telefónneho systému (PSTN) s internetom (IP) pomocou systému DDDS. Systém DDDS (Dynamic Delegation Discovery System) je spôsob uloženia adries pomocou systému DNS, pričom jednotlivé záznamy (NAPTR) obsahujú informáciu o tom, ako telefónne číslo (E.164) prevedené na názov domény (URI) ďalej previesť na adresu ľubovoľného VoIP operátora (VoIP zo slova Voice Over Internet Protocol, teda prenos hlasu cez internet). DDDS je vlastne akoby nadstavba systému DNS používaného na prevod medzi názvom domény a IP adresou.

 

Analógia ENUM – DNS

 

          Pred začiatkom vysvetľovania ako mechanizmus ENUM vlastne funguje by bolo dobré prepracovať sa k nemu pekne poporiadku, teda objasniť si, prečo vlastne ENUM funguje tak ako funguje. Ako už bolo spomínané, ENUM sa používa hlavne pre možnosť zastihnutia VoIP účastníka (IP) z telefónnej sieti (PSTN). Telefónnu sieť reprezentuje číslo vo formáte E.164 a internetovú sieť adresa vo formáte URI. Keď tieto dva formáty porovnáme, zistíme, že majú podobný princíp.

 

          Zoberme si napríklad samotnú Katedru informačných sietí, FRI, ŽU. Telefónne číslo katedry je + 421 41 513 4 301, kde 421 je číslo krajiny (SR), 41 je číslo telefónneho obvodu (Žilina), 513 je číslo firmy/inštitúcie (Žilinská univerzita), 4 konkrétne je predvoľba na Fakultu riadenia a informatiky a 301 je číslo konkrétneho telefónu na tejto fakulte. Oproti tomu, internetová adresa katedry je www.kis.fri.uniza.sk, kde (odzadu) „sk“ značí slovenskú doménu, „uniza“ Žilinskú univerzitu, „fri“ Fakultu riadenia a informatiky, „kis“ Katedru informačných sietí a „www“ značí webový server.

 

          Z tohto príkladu je teda zrejmé, že konverzia E.164 na URI by mohla nastať v tom prípade, ak by sme číslo vo formáte E.164 napísali pospiatky a patričným spôsobom ho upravili. A takto to skutočne aj funguje, pričom v takto otočenom čísle sa jednotlivé číslice oddelia bodkami a za nimi sa pridá koncovka „.e164.arpa“ (skratku ARPA si vysvetlíme neskôr). Teda telefónne číslo katedry by sa preložilo do podoby 1.0.3.4.3.1.5.1.4.1.2.4.e164.arpa.

 

          Teraz by bolo potrebné si vysvetliť, prečo sa na koniec otočeného čísla dodáva koncovka „.e164.arpa“ a akú súvislosť to má celé so systémom DNS. DNS pôvodne vzniklo kvôli tomu, že pre človeka je ľahšie si zapamätať nejaké slovo alebo názov ako číselnú IP adresu. DNS zabezpečuje práve túto skutočnosť, a to prevod symbolických doménových mien na číselné IP adresy. Pri reverznom prevode sa zas naopak pýtame DNS servera aké symbolické doménové meno odpovedá IP adrese.

 

          Napríklad teda, ak vieme, že IP adresa web servera, na ktorom beží www.kis.fri.uniza.sk, je 158.193.152.1, z tejto IP adresy sa vytvorí doménové meno tak, že otočíme poradie 4 zložiek IP adresy a na koniec pridáme koncovku „.in-addr.arpa“, a teda dostaneme 1.152.193.158.in-addr.arpa. Pri takomto reverznom DNS dotaze by sme teda dostali adresu www.kis.fri.uniza.sk. Porovnaním tohto postupu s postupom pri konverzii čísla vo formáte E.164 na URI adresu je nám zrejmé, že princíp je rovnaký.

 

          Ale prečo teda vlastne pridávame na koniec koncovku „.in-addr.arpa“ alebo „.e164.arpa“? Zložka „arpa“ tu označuje doménu najvyššej úrovne (TLD, top-level domain) a zložky „in-addr“ a „e164“ označujú zas doménu druhej úrovne (SLD, second-level domain). TLD doména „arpa“ tu ale neznačí organizáciu ARPA, ktorá zabezpečovala prvé kroky internetu, ale značí skratku zo slova Address and Routing Parameter Area, čiže oblasť pre parametre adresovania a smerovania.

 

          Doména „arpa“ slúžila pôvodne ako dočasný prostriedok pri zavádzaní systému DNS a okrem iného aj na spätný preklad IP adries na doménové mená. Nakoniec sa rozhodlo, že všetky infraštruktúrne záznamy sa budú uchovávať práve v tejto doméne. Pod túto TLD doménu sa teda zaraďujú SLD domény ako „in-addr“ pre mapovanie IPv4 adries do doménových mien, „ip6“ pre mapovanie IPv6 adries do doménových mien, „e164“ pre mapovanie telefónnych čísiel do URI, a tak ďalej.

 

Realizácia ENUMu

 

          Po objasnení prečo ENUM funguje tak ako funguje, by sme si teda mohli zopakovať celý postup a pridať k nemu aj vysvetlenie, čo je záznam NAPTR a ako súvisí s týmto mechanizmom. Predpokladajme teda, že máme číslo v medzinárodnom formáte E.164, napríklad už niekoľkokrát spomínané číslo katedry + 421 415 134 301. Toto číslo musí byť v úplnom formáte, teda pre našu krajinu to znamená 12 číslic so znamienkom „+“ na začiatku. Niekedy sa používa namiesto znamienka „+“ ešte aj „00“. A teraz si stručne zopakujeme postup, ktorým dostaneme z telefónneho čísla doménové meno:

 

          1. Z telefónneho čísla odstránime všetky nečíselné znaky (čiže znamienko „+“, poprípade „00“ ak je číslo v tomto formáte) a dostaneme číslo 421415134301.

 

          2. Číslo otočíme (zrkadlovo) a medzi každú číslicu vložíme bodku a dostaneme zápis 1.0.3.4.3.1.5.1.4.1.2.4 (jednotlivé číslice teraz predstavujú subdomény).

 

          3. Nakoniec pridáme spomínanú koncovku „.e164.arpa“ a takto získame doménové meno 1.0.3.4.3.1.5.1.4.1.2.4.e164.arpa.

 

          K takto vytvorenej doméne, uložíme do systému DNS do špeciálneho záznamu NAPTR SIP adresu vo formáte URI v tvare „sip:užívateľ@doména“. NAPTR (zo slova Naming Autority Pointer) je vlastne DNS záznam, ktorý obsahuje informácie o jednotlivých IP službách dostupných pre dané telefónne číslo v tvare doménového mena (URI).

 

          NAPTR záznam nemusí obsahovať len jeden SIP záznam, ale môže obsahovať aj záznamy iného typu služby akými sú napríklad e-mailová adresa, adresa webových stránok, elektronická vizitka, a podobne. Potom je však nutné určiť prioritu týchto záznamov. NAPTR záznam v DNS môže vyzerať napríklad nasledovne (o tom ako sa tento záznam konfiguruje v systéme BIND 9 a čo jednotlivé položky znamenajú si povieme neskôr v kapitole 3):

 

          $ORIGIN 1.0.3.4.3.1.5.1.4.1.2.4.e164.arpa.

 

               NAPTR 10 100 “u” “E2U+sip” “!^.*$!sip:uzivatel@domena.com!” .

 

               NAPTR 10 101 “u” “E2U+h323” “!^.*$!h323:uzivatel@domena.com!” .

 

               NAPTR 10 102 “u” “E2U+msg” “!^.*$!mailto:uzivatel@domena.com!” .

 

          Daný záznam vraví o tom, že telefónne číslo + 421 415 134 301 v tvare doménového mena 1.0.3.4.3.1.5.1.4.1.2.4.e164.arpa preferuje, aby bolo kontaktované cez protokol SIP (priorita 100) (SIP je IP protokol pre prenos signalizácie vo VoIP), alebo cez H.323 (priorita 101) (H.323 je doporučenie definujúce protokoly pre audio-video IP komunikáciu, je to v podstate zložitejší predchodca SIPu) alebo nakoniec pomocou protokolu SMTP (priorita 102) (SMTP je IP protokol pre prenos elektronickej pošty).

 

Princíp fungovania ENUMu

 

          Pre ilustráciu ako volanie v systéme ENUM vlastne v princípe funguje, použijeme nasledovný obrázok:

 

princip fungovania ENUMu

(tento obrázok bol prevzatý a upravený zo stránky www.wikipedia.org)

 

          Tento obrázok ilustruje, čo sa vlastne deje, keď telefónny účastník A chce volať telefónnemu účastníkovi B. Celkový postup je nasledovný:

 

          1. Privátna telefónna ústredňa (takzvaná PBX/PABX/EPABX) alebo taktiež brána užívateľa A, ktorá ovláda ENUM a má na starosti komunikáciu a spojenie, preloží požiadavku na telefónne číslo + 421 415 134 301 do podoby doménového mena 1.0.3.4.3.1.5.1.4.1.2.4.e164.arpa.

 

          2. Následne brána pošle DNS serveru požiadavku na vyhľadanie tohto doménového mena.

 

          3. DNS server vyhľadá vo svojej databáze odpovedajúci NAPTR záznam, ktorý pošle bráne ako odpoveď. Brána si následne z tohto „súboru“ adries vo formáte URI vyberie položku podľa protokolu a priority (pri tomto konkrétnom príklade je to adresa odpovedajúca protokolu internetovej telefónie SIP).

 

          4. Koncová aplikácia účastníka A nastaví komunikačný kanál a hovor je smerovaný po internete.

 

Čo všetko je potrebné pre prevádzku ENUMu?

 

          Aby sme mohli ENUM vôbec prevádzkovať, je potrebné najprv zaregistrovať si ENUM doménu odpovedajúcu nášmu telefónnemu číslu u spoločnosti, ktorá túto možnosť poskytuje. Táto registrácia však obsahuje len odkazy na DNS servery pre túto doménu. Samotný prevod telefónneho čísla vo formáte E.164 na adresu URI si musí zákazník zabezpečiť sám. Pre ENUM sa používa nový typ DNS záznamu, a to NAPTR, ktorý, ako už bolo v niektorej z predošlých podkapitol spomenuté, obsahuje informácie o jednotlivých IP službách dostupných pre dané telefónne číslo v tvare doménového mena (URI).

 

          NAPTR je teda vlastne pravidlo, ktoré dostane na vstup dotaz smerujúci do systému ENUM a na výstupe podá odpoveď, ktorá určuje, kam má byť smerovaný. Veľkou výhodou oproti bežným DNS záznamom je tu ale to, že namiesto niekoľko rôznych záznamov v prípade, že existujú viaceré telefónne čísla pre jednu doménu, nepotrebujeme pre každé číslo zapisovať nové pravidlo, ale postačí zapísať jedno pravidlo pre celý rozsah týchto čísiel.

 

          Podobne, pre jedno telefónne číslo môže existovať viacero služieb, napríklad e-mail, web adresa, SIP adresa, a tak ďalej. Na vstupe tohto pravidla (NAPTR) je teda potrebné ešte definovať aj požiadavku na typ výsledku, teda akú službu (Enumservice) vlastne požadujeme. Špecifikácie týchto služieb, platných protokolov a formátov výsledku (URI schém) sú spravované organizáciou IANA, ktorá celosvetovo dohliada na prideľovanie IP adries, správu koreňových zón pre DNS a iných náležitostí IP protokolov.

 

          Mohlo by sa ale stať, že niekto cudzí, ktorý nevlastní naše telefónne číslo, si zaregistruje ENUM doménu odpovedajúcu nášmu číslu. Povedzme, že niekto ďalší, napríklad náš príbuzný, by nám chcel na toto číslo poslať správu. V presvedčení, že toto číslo patrí nám, správu pošle, ale správa príde cudziemu, ktorý ju môže prípadne aj zneužiť. Preto je veľmi potrebné zabezpečiť, že užívateľ, ktorý žiada registráciu ENUM domény je oprávneným užívateľom koncového čísla.

 

          Toto opatrenie sa nazýva validácia a väčšinou sa prevádza tým, že registrátor jednoducho zavolá na konkrétne číslo alebo mu pošle SMS správu s kódom, ktorý zákazník musí obratom vrátiť registrátorovi, napríklad vyplnením formuláru na webe a odoslaním. Ďalšou možnosťou môže byť napríklad notárom overené osvedčenie, ale konkrétna podoba validácie závisí na konkrétnej spoločnosti, ktorá registruje ENUM domény. Keďže sa ale telefónne číslo užívateľa alebo držiteľ čísla môže časom zmeniť, je potrebné opakovanie tejto validácie v určitých časových intervaloch.

 

Viaceré typy ENUMu

 

          DNS záznamy určené pre ENUM (NAPTR) sa odlišujú svojím použitím od bežných DNS záznamov doménových mien. Zatiaľ čo v DNS požiadavke je bežne požadovaná IP adresa danej domény, a teda stačí jeden globálny DNS strom pre všetkých (in-addr.arpa), tak v prípade ENUMu sú požadované ohľadom jednej domény aj ďalšie rôzne informácie, a preto je nutných viacero záznamových stromov. Pre ENUM pripadajú do úvahy okrem iných práve tieto dva základné stromy – User ENUM a Infrastructure ENUM.

 

          User ENUM je strom DNS záznamov určený pre koncových užívateľov, ktorí podľa vlastného uváženia a vôle ukladajú do systému DNS informácie o ich telefónnom čísle, ktoré sú verejne dostupné. Takto „popísané“ číslo v systéme ENUM je potom možné využiť pre nadviazanie spojenia s daným telefónnym číslom. Tento strom slúži teda k výmene údajov a komunikácii medzi používateľmi.

 

          Má to avšak jeden háčik, a to ten, že keď si to celé zoberieme do úvahy, tak užívateľ, ktorý pridá svoje telefónne číslo do systému ENUM, tým neušetrí nič, ušetria práve tí ľudia, ktorí mu budú volať. A tento problém má teda za následok nižšiu motiváciu a skôr opatrnejšie zaobchádzanie a nasadzovanie tohto systému do bežného života. Samozrejme, existujú aj situácie, pri ktorých za celý hovor alebo jeho časť platí volaný, ale tieto situácie nenastávajú až v takej veľkej miere. Navyše, ďalším negatívnym činiteľom sú tu práve telekomunikační operátori, ktorí by týmto spôsobom prišli o svoje zisky, keďže telefonovanie cez internet by bolo „zadarmo“ a teda užívatelia by uprednostňovali práve túto cestu ako nákladnú cestu po sieti PSTN.

 

          Na druhej strane však ENUM predstavuje veľký prínos pre alternatívnych telefónnych operátorov, ktorí môžu získavať zákazníkov na svoju stranu práve ponukou lacnejšieho a modernejšieho telefonovania. Zároveň využitím systému ENUM sa môžu títo operátori vyhnúť poplatkom za používanie telekomunikačných sietí a teda znižovať svoje náklady.

 

          Infrastructure ENUM je strom určený práve pre telefónnych operátorov. Každý operátor vloží do DNS informácie o všetkých telefónnych číslach, ktoré má vo svojej sieti a pridá k nim aj údaj, akým spôsobom môžu ostatní operátori smerovať hovory a rôzne iné služby, ako napríklad SMS, MMS, e-mail a iné, na tieto čísla. Infrastructure ENUM rieši teda prepojovanie IP sietí operátorov a teda tieto informácie sú na rozdiel od User ENUM stromu neverejné.

 

          Okrem týchto základných typov ENUMu môžu existovať ešte aj ďalšie, napríklad privátne stromy pre vlastné účely a potreby operátorov.

 

Výhody ENUMu

 

          Pre predstavu akú skvelú možnosť vlastne ENUM ponúka, predstavme si situáciu, že užívateľ sa rozhodne, že už ďalej nechce volať po drahej sieti PSTN, ale „zadarmo“, teda po IP sieti.

 

          Prvá možnosť, ktorú má užívateľ, je zmeniť svojho PSTN operátora na VoIP operátora. Táto možnosť má ale za následok zmenu užívateľovho čísla, a teda užívateľ musí každému, kto mal jeho predošlé číslo, oznámiť, že má nové číslo, čo nie je vôbec ľahké.

 

          Druhá možnosť, ktorá sa tu ponúka užívateľovi, je využiť prenositeľnosť čísla a prejsť k VoIP operátorovi bez zmeny súčasného čísla. V prípade, ak má užívateľ pevné telefónne číslo, to nie je žiadny problém. Problém však vyvstáva v prípade, že užívateľ má mobilné číslo. S takýmto číslom nie je možné bez zmeny prejsť k VoIP operátorovi.

 

          Obidva prípady obsahujú v sebe teda istý problém. Navyše možnosť prenositeľnosti čísla nezávisí od požiadavky užívateľa, ale od možností operátora. Ponúka sa nám tu však ešte jedna možnosť, a tou je práve ENUM, ktorý umožňuje zachovanie pôvodného čísla.

 

          Ako už bolo spomenuté, ENUM umožňuje šetriť peniaze takým spôsobom, že sa automaticky vyberie spôsob kontaktovania osoby. Ak užívateľský agent zistí, že užívateľa je možné dosiahnuť po internete (čiže zadarmo), kontaktuje ho týmto spôsobom. V prípade, že užívateľa nie je možné dosiahnuť týmto spôsobom, je hovor uskutočnený po telefónnej sieti (PSTN) (teda za peniaze).

 

          Ďalšia veľmi dobrá vlastnosť systému ENUM je možnosť definovania viacerých URI adries k jednému telefónnemu číslu. Táto skutočnosť umožňuje užívateľovi nakonfigurovať komunikačné zariadenie tak, aby v prípade, ak by neodpovedal na VoIP volanie, bol hovor presmerovaný do hlasovej odkazovej schránky (napríklad hlasový odkaz poslaný e-mailom), prípadne bola poslaná užívateľovi správa (napríklad cez SMS alebo „instant messaging“).

 

2. Stav na Slovensku a v Čecháchh

 

Momentálny stav vo svete

 

          Pre zobrazenie súčasnej štatistiky, ako je na tom ENUM celkovo vo svete, môžeme využiť monitoring rakúskej domény „enum.at“, ktorá poskytuje na stránke http://crawler.enum.at/ aktuálny počet ENUM záznamov. Tieto čísla dosahuje pomocou takzvaného „lezúňa“, ktorý prehľadáva doménu „e164.arpa“ a hľadá tu jednotlivé NAPTR záznamy, pričom jedno celé obehnutie trvá približne týždeň. Tento „lezúň“ však ale nedokáže objaviť všetky záznamy, pretože niektoré DNS servery môžu používať implementácie, ktoré mu v tom bránia.

 

          Pre priblíženie, aký je vlastne počet všetkých objavených registrácií, uvádzame nasledovnú tabuľku (stav k 30.10.2009) (treba však brať do úvahy, že tieto čísla sú len orientačné a vôbec nemusia zodpovedať skutočnosti):

 

P. č.

Štát

Predvoľba

Počet

1.

Rumunsko

+ 40

410 688

2.

Rakúsko

+ 43

33 392

3.

Poľsko

+ 48

25 034

4.

Nemecko

+ 49

22 187

5.

Švédsko

+ 46

19 234

6.

Kórea

+ 82

9 689

7.

Česko

+ 420

4 846

8.

Nórsko

+ 47

1 166

9.

Slovensko

+ 421

753

10.

Veľká Británia

+ 44

302

11.

Holandsko

+31

132

12.

Austrália

+61

128

13.

Írsko

+353

48

14.

Spojené Arabské Emiráty

+971

41

15.

Japonsko

+81

33

16.

Vietnam

+84

12

17.

Litva

+370

7

18.

Fínsko

+358

3

19.

Brazília

+55

2

20.

Lichtenštajnsko

+423

2

21.

Grécko

+30

2

 

Slovensko

 

          Po schválení požiadavky na zavedenie systému ENUM na Slovensku organizáciami RIPE NCC (riadi prideľovanie IP adries pre Európu) a ITU-T (spravuje telekomunikačné štandardy) je od júna 2003 držiteľom domény „1.2.4.e164.arpa“ Ministerstvo dopravy, pôšt a telekomunikácií SR. Technickým zabezpečením bolo poverené združenie SANET.

 

          V októbri 2004 bola založená pracovná skupina ENUM, ktorej úlohou bolo nadobudnúť znalosti o tomto systéme, spolupracovať pri vytváraní podmienok pre prevádzkové skúšky, zhodnotiť výsledky týchto skúšok a následne navrhnúť odporúčania na realizáciu systému ENUM na Slovensku. Táto pracovná skupina ukončila svoju činnosť v júni 2007.

 

          Na Slovensku v súčasnosti ENUM ešte nie je plne uvedený do prevádzky, pričom zatiaľ prebieha len rutinná prevádzka a testovanie v prostredí akademickej siete v Žiline (Žilinská univerzita), v Bratislave (Univerzita Komenského a projekt Infovek) a v Košiciach (Technická univerzita, Univerzita Pavla Jozefa Šafárika a Slovenská Akadémia Vied). V septembri roku 2007 bolo na Slovensku zaregistrovaných 69 ENUM domén, ktoré tvorilo 62 356 telefónnych čísiel. Štyria hlavní telekomunikační operátori Slovak Telecom, T-Mobile, Orange a O2 vnímajú ENUM pozitívne, ale zatiaľ túto možnosť neposkytujú.

 

Česko

 

          Rovnako ako aj na Slovensku, v Čechách bola doména „0.2.4.e164.arpa“ zaregistrovaná taktiež v júni 2003. Držiteľom tejto domény je Ministerstvo informatiky ČR. Technickým zabezpečením bol poverený administrátor českej ccTLD domény (.cz), CZ.NIC. V rokoch 2004 až 2006 prebiehalo samotné budovanie infraštruktúry a testovanie systému ENUM. Až v januári roku 2007 bol ENUM uvedený do plnej prevádzky pre E.164 (telefónne), mobilné a VoIP čísla s potrebnou validáciou každých 6 mesiacov.

 

          V súčasnosti združenie CZ.NIC zabezpečuje len samotný chod koreňovej domény „0.2.4.e164.arpa“, registrovanie vlastných ENUM domén zabezpečujú zatiaľ iba malé telekomunikačné spoločnosti. Týchto registrátorov je v súčasnosti 21 (stav k 15.9.2009). Spomedzi najznámejších sú to IPEX, CL-NET, NETWAY.CZ, GYRUSS TELECOM, General Registry, KRAXNET, IGNUM a združenie CESNET v akademickej sfére. V súčasnosti je v Čechách zaregistrovaných 4 015 ENUM domén, ktoré predstavujú 560 773 telefónnych čísiel (stav k 30.10.2009). Veľké telekomunikačné firmy ako sú O2, T-Mobile a Vodafone zatiaľ túto možnosť neposkytujú v dôsledku obáv zo strát na ziskoch.

 

3. Konfigurácia DNS servera a ENUMu

 

          V nasledovnej sekcii sa oboznámime so základnými konfiguráciami zvolených opensource riešení pre platformu Linux, konkrétne OS Debian. Ako DNS server bol zvolený BIND 9, ktorý má ako jeden z mála dostupných riešení natívnu podporu pre ENUM. V prípade SIP servera, bolo zvolené opensource riešenie OpenSER, ktoré taktiež natívne podporuje ENUM, avšak túto službu treba aktivovať, pretože nie je spúšťaná ako základná služba.

 

          Popisované riešenie bolo zrealizované a otestované na nasledovnej topológii:

 

pouzita topologia

 

          Použitú doménu (192.168.1.0/24) sme nazvali example.com. Na serveri (192.168.1.1) s OS Debian beží BIND 9 a OpenSER. Na server sú pripojení dvaja klienti – calella (192.168.1.37), bežiaci ako „virtuálny host“ na serveri, a mirec (192.168.1.6) s OS Windows XP. Obidvaja klienti používajú rovnaký softvérový telefón Xlite.

 

Konfigurácia DNS servera BIND 9

 

          Pri bežnej inštalácii by sme mali dostať nasledujúce súbory:

 

/etc/resolv.conf – súbor, definujúci DNS server (192.168.1.1) pre doménu (example.com)

search example.com
nameserver 192.168.1.1

 

 

/etc/bind – zložka pre BIND 9, obsahujúca súbory pre nastavenie domén, DNS záznamov a pod.

 

/etc/bind/db.empty – prázdny DNS záznam

 

/etc/bind/named.conf.local – definovanie lokálnych zón (domén pre DNS preklad), teda použitej domény example.com (192.168.1.0/24), jej reverznej domény 1.168.192.in-addr.arpa a reverznej domény pre E.164 telefónne čísla pre Slovensko 1.2.4.e164.arpa

zone "example.com" {
    type master;
    file "/etc/bind/db.example.com";
};

zone "1.168.192.in-addr.arpa" {
    type master;
    file "/etc/bind/db.1.168.192";
};

zone "1.2.4.e164.arpa" {
    type master;
    file "/etc/bind/db.1.2.4.e164.arpa";
};

 

 

          Teraz si musíme vytvoriť súbory, ktoré sme definovali pre jednotlivé zóny.

 

/etc/bind/db.example.com – záznam pre našu doménu example.com obsahuje nasledovné údaje:

$TTL	3D

 

     – definovanie TTL hodnoty, čiže po akom čase server zisťuje, či boli prevedené zmeny v lokálnych súboroch

 

@	IN	SOA	ns.example.com. root.example.com. (
			09103101	; Serial
			8H		; Refresh
			2H		; Retry
			4W		; Expire
			1D )	; Negative Cache TTL

 

     – „@“ definuje doménu example.com, „IN SOA“ definuje typ záznamu (autoritu) a ďalej nasleduje definovanie master DNS servera a adresy pre kontakt; zvyšné hodnoty sú dôležité ak máme viac DNS serverov

 

@	IN	NS	ns

 

     – NS záznam DNS servera pre doménu (IP adresa alebo doménové meno), v našom prípade „ns“; keďže za „ns“ nie je bodka „.“, úplné doménové meno bude „ns.example.com“

 

localhost	IN	A	127.0.0.1
ns		    IN	A	192.168.1.1
sip       IN	A	192.168.1.1
mirec     IN	A	192.168.1.6
calella		IN	A	192.168.1.37

 

     – tu definujeme preklad doménových mien na IP adresy (záznamy typu A)

 

_sip._udp.example.com. 	86400 	IN	SRV	0	5	5060	sip.example.com.

 

     – SRV záznam potrebný pre SIP požiadavky v rámci „example.com“ domény definujúci službu (sip), transportný protokol (udp), dobu platnosti (1 deň), triedu (internet), typ záznamu (SRV), prioritu (0), váhu (5), port (5060) a adresu obslužného SIP proxy servera (sip.example.com)

 

/etc/bind/db.1.168.192 – reverzný DNS záznam pre doménu example.com

$TTL	3D
@	IN	SOA	ns.example.com. root.example.com. (
			09110101	; Serial
			8H		; Refresh
			2H		; Retry
			4W		; Expire
			1D)		; Negative Cache TTL
@	IN	NS	ns.example.com.

 

     – to isté ako v prípade súboru pre doménu example.com

 

1   PTR	ns.example.com.
6   PTR	mirec.example.com.
37  PTR	calella.example.com.

 

     – tu definujeme preklad IP adries na doménové mená (záznamy typu PTR)

 

          Teraz nám zostáva už len vytvoriť súbor obsahujúci NAPTR záznamy (/etc/bind/db.1.2.4.e164.arpa), predtým si však ešte vysvetlíme, čo taký záznam obsahuje. NAPTR záznam obsahuje 6 polí: ORDER, PREFERENCE, FLAGS, SERVICE, REGULAR EXPRESSION a REPLACEMENT.

 

     ORDER – slúži na určenie priority záznamu, menšie číslo znamená vyššiu prioritu

 

     PREFERENCE – slúži na rozlíšenie priorít v prípade, ak viaceré záznamy majú zvolenú rovnakú prioritu (pole ORDER)

 

     FLAGS – pole príznakov, v prípade NAPTR záznamu je povolený len flag „u“, čo určuje, že výstupom bude adresa vo formáte URI

 

     SERVICE – obsahuje rozpoznávacie značky (v prípade e164.arpa domény je to E2U+), typ a podtyp služby

 

     REGULAR EXPRESSION – popisuje prevod z E.164 tel. čísla na URI adresu pomocou regulárnych výrazov, ako oddeľovací znak je použitý „!“

 

     REPLACEMENT – používa sa na ďalší prevod, v prípade flagu „u“ sa nepoužíva

 

/etc/bind/db.1.2.4.e164.arpa – obsahuje NAPTR záznamy pre telefónne čísla s predvoľbou + 421

$TTL	3D
@	IN	SOA	ns.example.com. root.example.com. (
			09110301	; Serial
			8H		; Refresh
			2H		; Retry
			4W		; Expire
			1D)		; Negative Cache TTL
@	IN	NS	ns.example.com.

 

     – to isté ako v prípade súboru pre doménu example.com

 

9.8.7.6.5.4.3.2.1	IN	NAPTR	10	101	"u"	"E2U+sip"	"!^.*$!sip:mirec@example.com!"	.
7.8.7.6.5.4.3.2.1	IN	NAPTR	10	101	"u"	"E2U+sip"	"!^.*$!sip:calella@example.com!"	.

 

     – NAPTR záznamy pre užívateľov mirec (tel. č.: 123456789) a calella (tel. č.: 123456787)

 

Konfigurácia SIP servera OpenSER

 

          Pri bežnej inštalácii, by sme mali dostať nasledujúce súbory:

 

/etc/openser/openserctlrc – konfiguračný súbor OpenSERu, kde nastavíme adresu sip servera

SIP_DOMAIN=sip.example.com

 

 

/etc/openser/openser.cfg – hlavný konfiguračný súbor OpenSERu, kde nastavíme potrebné parametre a kde je definovaný obslužný proces „route“

alias=example.com 

 

     – alias nastavíme na našu doménu example.com

 

debug=3	
log_stderror=yes 

 

     – stupeň zachytávania chýb a vypisovanie chýb na konzolu (no – bez výpisu)

 

port=5060
listen=udp:192.168.1.1:5060 

 

     – nastavenie, na ktorom porte a na ktorej adrese server „načúva“ (a použitý protokol)

 

mpath="/usr/lib/openser/modules/"

 

     – cesta k modulom OpenSERu

 

loadmodule "sl.so"
loadmodule "tm.so"
loadmodule "rr.so"
loadmodule "maxfwd.so"
loadmodule "usrloc.so"
loadmodule "registrar.so"
loadmodule "textops.so"
loadmodule "mi_fifo.so"
loadmodule "xlog.so"
loadmodule "enum.so" 

 

     – zapnutie modulov potrebných pre bežnú činnosť, podporu pre ENUM zapneme použitím modulu „enum.so“, v našom prípade sme vypli podporu pre SQL databázu

 

modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo")

 

     – názov a umiestenie súboru FIFO, ktorý bude vytvorený pre načúvanie a prečítanie externých príkazov

 

modparam("usrloc", "db_mode", 0)

 

     – pri registrácii klienta uloží informáciu o jeho umiestnení na miesto, kde ukazuje „db_mode“, v prípade parametra 0 sa jedna o lokálnu pamäť

 

modparam("rr", "enable_full_lr", 1)

 

     – zabezpečuje kompatibilitu so staršími SIP servermi, ktoré nespracúvajú funkciu „record_route()“

 

modparam("enum","domain_suffix","e164.arpa.")

 

     – nastavenie doménovej prípony pridanej k doménovému menu získanému z E.164 čísla

 

route
{
	if (!mf_process_maxfwd_header("2")) 
  {
		sl_send_reply("483","Too Many Hops");
		exit;
	};	

 

     – kontrola, či nedošlo k priveľa preposielaniam, aby sa zabránilo „loopom“, v prípade, že sa tak stane, vygeneruje chybu pre klienta typu 483 a ukončí proces „route“

 

	if (msg:len >= 2048 ) 
  {
		sl_send_reply("513", "Message too big");
		exit;
	};

 

     – kontrola na dĺžku prijatej správy, v prípade, že správa presiahne povolenú maximálnu dĺžku, vygeneruje chybu pre klienta typu 513 a ukončí proces „route“

 

	if (!method=="REGISTER") 
  {
		record_route();
	}

 

     – ak správa nie je typu REGISTER, server zaznamená „trasu“ do hlavičky VIA SIP správy, inak povedané, príkaz „record_route()“ prikazuje serveru, aby spravoval SIP požiadavky medzi dvoma klientmi

 

	if (loose_route())
 	{
		append_hf("P-hint: rr-enforced\r\n");
		route(1);
	};

 

     – tento blok testuje, či požiadavka bude smerovaná použitím hlavičiek, ktoré boli pridané funkciou „record_route()“, teda zjednodušene povedané , ak požiadavky sú z rovnakého „dialógu“, tak požiadavku len pošleme ďalej

 

	if (!uri==myself) 
 	{
		exit();
	};

 

     – daný odsek slúži na spravovanie požiadaviek z domény, ktorá nie je spravovaná naším serverom, v našom prípade, kde máme len jednu doménu, odsek ukončí proces „route“

 

	if (uri==myself) 
  {
		if (method=="REGISTER") 
    {
		  save("location");
		  exit;
	  };

 

     – ak požiadavky sú z našej domény, vykoná sa kontrola, či sa jedná o požiadavku typu REGISTER, ak áno, umiestenie klienta sa uloží do pamäte a ukončí sa proces „route“

 

		if (uri =~ "sip:\+[0-9]+@") 
    {
			enum_query();
		};

 

     – pomocou výrazu „sip:\+[0-9]+@“ sa pýtame, či URI je v tvare telefónneho čísla začínajúceho znakom „+“, ak áno, zavolá sa funkcia „enum_query()“, ktorá overí, či pre toto volané číslo existuje NAPTR záznam, a v prípade, že existuje, vráti SIP záznam v tvare „sip:užívatel@example.com“, ktorým prepíše vyžiadanú URI adresu (R-URI)

 

		if (!lookup("location")) 
    {
     		sl_send_reply("404", "Not Found");
		  	exit;
		};
		append_hf("P-hint: usrloc applied\r\n");
	};
	route(1);
};

 

     – funkcia „lookup(“location”)“ pohľadá v lokálnej tabuľke, či existuje pre vyžiadanú URI adresu (R-URI) umiestnenie (IP adresa), ktoré bolo získané pri registrácii účastníka; ak záznam existuje, tak R-URI zmení na príslušnú IP adresu; ak záznam nenájde, vygeneruje chybu pre klienta typu 404 a ukončí proces „route“

 

route[1]
{
	if (!t_relay())
  {
	   sl_reply_error();
	};
  exit;
}

 

     – ak všetko prebehne v poriadku, vstúpi sa do bloku route[1], ktorý len prepošle požiadavku; v prípade chyby pošle informáciu o nej späť užívateľovi

 

Ukážka ako prebieha hovor medzi dvoma užívateľmi

 

          Nasledovné 2 obrázky boli „odfotené“ z programu Wireshark. Súbor “.pcap” so zachytenými paketmi si môžete stiahnuť tu: VoIP call flow with ENUM.pcap (treba premenovať z “.txt” na “.pcap”).

 

SIP flow

 

          Tento obrázok ilustruje celkovú SIP komunikáciu medzi serverom 192.168.1.1 a hostom „mirec“ (192.168.1.6). Ako je z obrázku zrejmé, najprv prebehne registrovanie účastníka na serveri, a teda naplnenia tabuľky servera príslušnými údajmi o užívateľovi. Potom nasleduje samotné začatie hovoru pozvaním účastníka s číslom + 421 123 456 787, ďalej sú to informačné správy, potvrdenie hovoru, samotný hovor (ktorý tu ale nie je vidieť) a ukončenie hovoru.

 

VoIP call flow

 

          Tento obrázok zobrazuje len samotný VoIP hovor medzi účastníkmi mirec (192.168.1.6) a číslom + 421 123 456 787 (192.168.1.37) pomocou servera 192.168.1.1. Najskôr je užívateľ pozvaný na hovor s príslušným opisom (pomocou SDP), nasledujú informačné správy o zvonení, potvrdenie hovoru, samotný hovor (pomocou RTP) trvajúci 5,5s a ukončenie hovoru na druhej strane.

 

          Nasledovný výpis bol „odfotený“ priamo z konzoly servera 192.168.1.1. Ako je zrejmé, po spustení SIP servera OpenSER sa užívatelia najprv na serveri zaregistrujú, čo dokazuje aj výpis uloženej tabuľky (pomocou príkazu „openserctl ul show“). Nasleduje VoIP hovor z hosta mirec (192.168.1.6) na číslo + 421 123 456 787, ktoré je pomocou ENUM dotazu prepísané na hosta calella (192.168.1.37). Ďalej nasleduje potvrdenie hovoru, samotný hovor a ukončenie hovoru.

 

CalellaNBLinux:/home/calella# /etc/init.d/openser start
Listening on 
             udp: 192.168.1.1 [192.168.1.1]:5060
Aliases: 
             udp: ns.example.com:5060
             *: example.com:*

CalellaNBLinux:/home/calella#
vyziadana metoda: [REGISTER], z URI: [sip:mirec@example.com], na URI: [sip:mirec@example.com]
vyziadana metoda: [REGISTER], z URI: [sip:calella@example.com], na URI: [sip:calella@example.com]

CalellaNBLinux:/home/calella# openserctl ul show
Domain:: location table=512 records=2 max_slot=1
	AOR:: mirec
		Contact:: sip:mirec@192.168.1.6:5060;rinstance=a9e6f07e56d56da8 Q=
			Expires:: 3567
			Callid:: YWQ1MDAzMTYwOGY5YzVjZmFkNjllYjAyMmVlNmJmMWU.
			Cseq:: 1
			User-agent:: X-Lite release 1103k stamp 53621
			State:: CS_NEW
			Flags:: 0
			Cflag:: 0
			Socket:: udp:192.168.1.1:5060
			Methods:: 5951
	AOR:: calella
		Contact:: sip:calella@192.168.1.37:5061 Q=
			Expires:: 1788
			Callid:: 1650FCA111DCE5B0B0AF6F6F84AD3421@example.com
			Cseq:: 61071
			User-agent:: X-Lite release 1105d
			State:: CS_NEW
			Flags:: 0
			Cflag:: 0
			Socket:: udp:192.168.1.1:5060
			Methods:: 4294967295

CalellaNBLinux:/home/calella#
vyziadana metoda: [INVITE], z URI: [sip:mirec@example.com], na URI: [sip:+421123456787@example.com]
zaznamenavam trasu
adresa je vo formate +xxxxxx@
ENUM dotaz vratil  
smerujem...
vyziadana metoda: [ACK], z URI: [sip:mirec@example.com], na URI: [sip:+421123456787@example.com]
idem cestou urcenou zaznamenavanim
smerujem...
vyziadana metoda: [BYE], z URI: [sip:+421123456787@example.com], na URI: [sip:mirec@example.com]
idem cestou urcenou zaznamenavanim
smerujem...

 

 

Rate this post

Pridaj komentár

Vaša e-mailová adresa nebude zverejnená. Vyžadované polia sú označené *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

The reCAPTCHA verification period has expired. Please reload the page.