Využití protokolu IAX pro spojení mezi ústřednami Petr Kovář, Karol Molnár Vysoké učení technické v Brně, Fakulta elektrotechniky a komunikačních technologií, Ústav telekomunikací, Purkyňova 118, 612 00 Brno, Česká republika. Email: kovarp@feec.vutbr.cz, molár@feec.vutbr.cz Protokol Inter Asterisk Exchange, IAX, získává v poslední době na důležitosti. Jeho nejčastějším využitím je propojení IP telefonních ústředen. Jeho specifikace do značné části odporuje moderním trendům. Paradoxně právě proto je tak často nasazován. 1 Úvod Narozdíl od univerzálního protokolu SIP byl protokol IAX (Inter Asterisk Exchange) navržen s ohledem na maximální jednoduchost a snadnost implementace. Jeho cílovou platformou měla být velmi jednoduchá a levná koncová zařízení. Jedná se o binární protokol, který sdružuje signalizaci i hlasová data v jenom kanálu a umožní tak lépe využít šířku pásma a snadno přechází mezi sítěmi s překladem adres (NAT). Nakonec se protokol IAX vyprofiloval na řešení, které je určeno pro přímé propojení dvou ústředen Asterisk. 2 Implementace IAX IAX je zaveden do ústředny Asterisk od samého počátku vývoje. Od Asterisk 0.5 (současná verze 1.6) začala být podporována vylepšená verze protokolu, nazývaná IAX2. Ta je využívána až do současnosti a stala se také pracovním dokumentem IETF - jedná se o typ Internet-Draft. Není tedy standardizován žádnou normou RFC ani IEEE, ale jeho specifikace je veřejná [1]. Protokol lze tedy využít jako alternativu k protokolům SIP a H323 i u klientských zařízení, i když terminálů, které by jej využívaly, zatím není příliš mnoho. Důvodem je hlavně mnohem více využívaná alternativa, SIP. IAX je orientován na přenos peer-to-peer a je určen pro přenos signalizačních i hlasových dat. Pomocí protokolu IAX lze provést registraci vzdálených systémů, vyvářet, udržovat a ukončovat multimediální přenosy. Protokol je navržen a vytvořen speciálně pro využití s IP protokolem. 2.1 Přednosti IAX oproti SIP/RTP Základní myšlenkou protokolu IAX2 je využití jediného kanálu pro přenos signalizace i samotných multimediálních dat, jako je hlas a video. Základní myšlenkou je také multiplex více hovorových i signalizačních dat do jednotného datového toku. Pro přenos je využíván pouze jeden UDP port - tím je obvykle port 4569, patřící do seznamu registrovaných [2] portů. Zde je namístě upozornit, že v aktuálním návrhu standardu IAX[1] je tento port nešťastně označen jako velmi známý. Oficiální seznam čísel portů [2] termín velmi známý nicméně využívá jen pro porty 0-1023. IAX je binárně orientovaný protokol. Díky tomu může být mnohem efektivnější při hospodaření s přenosovou šířkou přiděleného pásma. Díky využití binárního protokolu je systém, který jej využívá, také mnohem odolnější proti útokům typu buffer overrun. 42-1
Využití binárního protokolu a sloučení signalizace a dat do jednoho toku sice zmenšuje srozumitelnost celého procesu a zároveň jde proti současnému trendu, který striktně odděluje hlasová a hovorová data, na druhou stranu ovšem umožní snadnější průchod přes firewall a NAT, přičemž, jak již bylo řečeno, nezanedbatelná je i snížená režie celého přenosu. Základní komunikační jednotkou protokolu IAX je IAX rámec. Existuje více typů rámců, přičemž základní a nesoucí hovorová i signalizační data je tzv. Full Frame. Pro přenos multimediálních dat je využit tzv. Mini Frame. Již při pouhém přenosu multimediálních dat lze identifikovat značné rozdíly oproti protokolu RTP který vyžaduje 12 bajtů, protože hlavička rámce Mini Frame má velikost pouhých 4 bajtů. Je samozřejmé, že stranou nemohlo zůstat ani zabezpečení, proto je autentizace zabezpečená protokolem RSA. Bezpečnost je důležitá hlavně v případech, kdy dochází k propojení dvou pobočkových ústředen prostřednictvím Internetu. Protokol IAX oproti využití kombinace SIP/RTP tedy efektivněji hospodaří s přenosovým pásmem. Tato optimalizace je znatelná již při jednom přenášeném hovoru. Pokud bychom uvažovali přenos pouze pomocí Mini Frame, bylo by jen na hlavičkách datových multimediálních jednotek ušetřeno 3,2 kbit/s. V literatuře se ovšem, kvůli dodatečné signalizaci, uvádí úspora pásma o šířce cca 2,4 kbit/s[3][4]. Při využití kodeku G.729 se při trunkování (viz kap. 2.3) díky ušetřené signalizaci udává šance realizovat až trojnásobný počet hovorů na jeden megabit/s šířky pásma (měřeno na linkové vrstvě) než při využití SIP/RTP[5]. 2.2 Rámce protokolu IAX Jak již bylo zmíněno, protokol IAX využívá dva typy rámců MiniFrame a FullFrame (viz Obr. 1). MiniFrame má hlavičku pouze 4 bytovou, která obsahuje posledních 16 bitů časové značky zdrojové číslo volajícího (Source call number) a bit F, který rozlišuje typ rámce. FullFrame má hlavičku 12 bajtovou. Obsahuje stejné informace jako MiniFrame, včetně plné časové značky TimeStamp. Navíc obsahuje číslo volaného (Destination Call Numer), OSeqno (OutBound stream sequence number), které udává číslo odchozích rámců. ISeqno (InBound stream sequence number) obsahuje stejnou informaci jako OSeqno, ale tentokrát pro příchozí rámce. Frame Type určuje typ rámce (DTMF signalizace, Hlasová data, Video, řídící rámec, IAX řízení, atd...). Pole C určuje jak bude interpretováno pole nazývané Subclass. Pokud je C rovno nule, Subclass je interpretováno jako mocnina dvou, když je C jedna, Subclass je interpretován jako 7bitová hodnota. Pokud je pro přenos DTMF použit úplný rámec, Subclass obsahuje aktuální přenesenou číslici. Pokud je přenášeno video, hlas nebo obraz, pole Subclass udává typ komprese. 42-2
Obr. 1: Rámce protokolu IAX. Nalevo FullFrame, napravo MiniFrame 2.3 Spojení pomocí protokolu IAX Jak již bylo řečeno úvodem, komunikace protokolu IAX probíhá pomocí binárních kódů. Přesto lze najít mnoho podobností s textově orientovanými protokoly. Následuje popis mechanizmů, které jsou důležité pro využití v projektu Výzkum a vývoj internetové telefonní ústředny (MPO FT-TA3/011). 2.3.1 Adresování IAX Protokol IAX využívá pro adresaci standardních formátů typu URI (Uniform Resource Identifiers) podle doporučení [5]. Základní schéma URI protokolu IAX je následující: iax2: [uživatelské_jméno @ ]host[ : port][ / identifikátor[? kontext]], kde jednotlivé položky mají následující význam: iax2 Označení protokolu, povinný údaj uživatelské_jméno Uživatelské jméno, vyžadováno pro registraci a autentizaci host Identifikace systému v síti. Akceptovány jsou IP adresy ve tvaru IPv4 nebo IPv6 nebo doménové jméno. Využití doménových jmén je při identifikaci systémů silně doporučeno. port Určuje port protokolu UDP. identifikátor Číslo nebo jméno identifikující zdroj na konkrétním systému kontext Určení části systému, na kterém je služba provozována Příklady využití: iax2:testovaci_system.cz/tester15?testeri iax2:test@192.168.0.61:4569/tester15?testeri iax2:[2001:db8::1]:4569/tester15?testeri 42-3
Pole host a identifikátor, které jsou využity v protokou IAX2 URI nejsou typu case sensitive, tzn. že nezáleží, zda jsou v adrese využity malá nebo velká písmena. Následující identifikátory jsou tedy ekvivalentní: iax2:testovaci_system.cz/tester15?testeri iax2:testovaci_system.cz/tester15?testeri Pro uživatelské jméno to ovšem neplatí, zde je nutno dodržet přesný tvar. Adresace pomocí URI je využívána hlavně v koncových zařízeních jako základní identifikátor vzdálených systémů a dále se využívá u služby ENUM, která slouží pro vyhledávání a identifikaci takovýchto zdrojů [3][4]. 2.3.2 Režimy a funkce protokolu IAX a příslušné zprávy Všechny zprávy protokolu IAX se dělí na dvě základní skupiny: spolehlivé (reliable) a negarantované (non-guaranteed). Mezi spolehlivé se řadí všechny ty, které využívají Full Frame, které jsou popsány výše. Negaratnované zprávy jsou označovány všechny informace, které jsou zaslány pomocí Mini Frame. Režimy a funkce, kterými disponují příslušné implementace protokolu IAX jsou následující: Registrace (volitelně) Správa hovorových kanálů Optimalizace hovorové trasy (volitelně) Režim hovoru Ukončení hovoru Monitorování sítě Číselná volba (volitelně) Stažení Firmware (volitelně) Automatické nastavení zařízení (volitelně) Různé Multimediální zprávy Proces registrace Jestliže mají být systémy využívající IAX navzájem dostupné, je nutné zajistit patřičnou adresaci. Adresy mohou být nastaveny manuálně, získány pomocí k tomu určené technologie ENUM nebo získány pomocí protokolu IAX. Pro poslední způsob disponuje IAX mechanizmem registrace. Při procesu registrace dochází k tomu, že lokální systém, který zná adresu systému vzdáleného, se u něj zaregistruje a může být tedy vzdáleným systémem dosažen i za předpokladu, že ten jeho adresu původně neznal. 42-4
Neregistrovaný Inicializace, odeslán REGAUTH Registrace odeslána Obdržen REGAUTH, odeslán REGREQ Obdržen REGACK, odeslán ACK Timeout registrace, odeslán REGREQ Obdržen REGAUTH bez (vyhovujících) přihlašovacích informací odeslán ACK Registrovaný Neautorizovaný Obdržen REGAUTH, odeslán REGREL Uvolněný Žádost o uvolnění, odeslán REGREL Obdržen REGAUTH bez (vyhovujících) přihlašovacích informací odeslán ACK obdržen ACK Obdržen REGREJ, odeslán ACK Zamítnutý Obr. 2: Stavový diagram procesu registrace protokolu IAX Implementace registračního procesu v zařízeních podporujících protokol IAX je volitelná a například při využití protokolu v IP telefonech se logicky počítá jen s implementací registrační části protokolu, nikoliv registrující. Stavový diagram procesu registrace je znázorněno na obrázku 2. Autentifikace vzdáleného systému je možná pomocí volitelných metod. Nejčastěji se využívá šifrování MD5, RSA nebo 3DES. Při registraci je nejprve zaslána zpráva REGREQ (Registration Request Message) spolu s uživatelským jménem a dobou vypršení registrace. Jestliže je vyžadována autentifikace, registrar (systém ke kterému se vzdálený uživatel registruje) odpoví pomocí zprávy REGAUTH (Registration Authentication Response Message), která obsahuje autentizační metody podporované registrarem. Vzdálený systém odpoví opět zprávou REGREQ, přičemž tentokrát již zpráva obsahuje i autentizační údaje v potřebném formátu. Jestliže nelze registraci akceptovat, stav vzdáleného sytému bude neautorizovaný a žádné další akce nejsou nutné. Pokud je registrace akceptována, registrar odpoví zprávou REGACK (Registration Acknowledgment Message), která musí obsahovat IP adresu registraru a měla by obsahovat také dobu vypršení registrace. Pokud tomu tak není, obě strany musí nastavit shodnou dobu vypršení registrace na 60 vteřin. Pokud je registrace odmítnuta např. z důvodu poruchy, je využito zprávy REGREJ (Registration Reject Message). Každá registrace je platná jen po omezenou časovou peridu (standardně 60 sekund, jak již bylo uvedeno výše). Vzdálený systém může tuto dobu prodloužit pomocí opakování registračního procesu nebo naopak zkrátit pomocí zprávy REGREL (Registration Release Request Message). 42-5
Správa hovorových kanálů, ukončení hovoru Protokol IAX využívá pro realizaci hovoru virtuálních spojení, linek, sestavených mezi dvěma body, které chtějí hovor realizovat. Celý proces je názorně zobrazen na obr. 3 a 4. Proces zřízení hovorového kanálu začíná zasláním zprávy NEW, jejíž součástí je identifikátor volaného systému. Ten odpoví pomocí zpráv AUTHREG, pokud vyžaduje autorizaci, respektive ACCEPT nebo REJECT pro schválení nebo zamítnutí požadavku na sestavení hovoru. Pokud je vzdáleným systémem hovor povolen, dojde k přechodu do režimu spojený. Do stavu činný přejde hovorový kanál ve chvíli, kdy je hovor vyzvednut druhou stranou. To je signalizováno pomocí zprávy ANSWER. Hovor je ukončen pomocí zprávy HANGUP a jejím následným potvrzením. Obr. 3: Stavový diagram procesu zřízení hovorového kanálu 42-6
Obr. 3: Stavový diagram procesu uzavření hovorového kanálu Režim hovoru V režimu hovoru mohou nastat další situace a také být k dispozici služby, jejichž zabezpečení je nutno ošetřit pomocí komunikačního protokolu. Během hovoru disponuje IAX těmito možnostmi a funkcemi: Flash (zpráva FLASH Request Message), hold (přidržení hovoru, zprávy HOLD Request Message a UNHOLD Request Message), quelch (umlčení, zprávy QUELCH Request Message a UNQUELCH Request Message), přepojení hovoru (zpráva TRANSFER Request Message). 2.4 Konfigurace IAX Trunk Termínem trunk se označuje propojení dvou telekomunikačních ústředen pomocí k tomu vhodné nebo speciálně určené technologie. Při využití klasických komunikačních technologií se jedná zejména o linky typu E1 (označována také jako primární ISDN), ATM a podobně. V případě využití IP telefonie po dosti dlouhou dobu chyběla technologie s tak přesným zacílením, vytvořená přesně za tímto účelem. Pro trunk lze sice využít (a také je nejčastěji využíván) protokol SIP, ale jeho nasazení na tuto úlohu není příliš optimální. Hlavní nevýhodou je příliš široká šířka pásma nutná pro signalizaci, obtížný průchod přes oblasti využívající NAT a také nutnost sestavit a udržet nové spojení pro každý hovor. I přes původně zamýšlené určení protokolu IAX, který měl být pro svou jednoduchost a robustnost využit hlavně pro implementaci v levných IP telefonech, je nejčastěji IAX využíván právě pro sestavení trunků. Zde se dokáží plně projevit jeho kladné vlastnosti, které spočívají ve velké úspoře přenosového pásma, jednoduchosti a robustní struktuře. Pro ověření možností protokolu IAX a uvážení jeho případného nasazení v projektu bylo samozřejmě nutné realizovat testovací systém, který by teoretické předpoklady ověřil v praxi a 42-7
také otestoval implementaci protokolu v open source ústředně Asterisk, která je nasazena jako řídící modul projektu. Základem pro úspěšnou realizaci IAX trunku je samozřejmě funkční a odzkoušený systém, stávající se z minimálně dvou ústředen Asterisk a příslušných IP telefonů, pomocí kterých lze prakticky ověřit možnosti realizace a také zhodnotit vliv využití protokolu IAX na subjektivní vnímání kvality přenášeného signálu. Zjednodušené schéma systému je znázorněno na obr. 2. IP telefon (SIP) Protokol SIP/RTP Ústředna Asterisk (1) Protokol IAX Ústředna Asterisk (2) Protokol SIP/RTP IP telefon (SIP) Obr. 5: Schéma systému využívající protokol IAX pro vzájemné spojení (trunk) Konfigurace SIP klientů je standardní, pro realizaci spojení pomocí IAX není třeba žádná další režie ani speciální nastavení klientských zařízení, neboť veškeré změny se dějí jen na straně ústředny. Pro realizaci protokolu IAX v systému je využit modul chan_iax.so, konfigurace protokolu IAX je provedena pomocí změny konfiguračního souboru iax.conf. Zjednodušený vzorový konfigurační soubor protokolu IAX je zobrazen ve výpisu 1. 1: [general] 2: bindaddr=192.168.0.61 3: bindport=4569 4: disallow=all 5: allow=gsm 6: allow=g729a 7: allow=alaw 8: 9: [trunkiax] 10: type=user 11: host=dynamic 12: username=trunkiax 13: secret=trunk 14: context=internal Výpis 1: Vzorová konfigurace iax.conf Řádek 1 signalizuje obecný kontext, zde zapsaná konfigurační data budou platná pro všechny účty. Na řádku 2 je specifikována IP adresa na které má Asterisk vytvořit socket IAX protokolu. To je nutné v případě, kdy má Asterisk problémy s identifikací vlastní IP adresy, případně pokud má k dispozici více síťových rozhraní s různými adresami. Řádek 3 je obdobou řádku 2, ale v tomto místě je specifikován port. Obvykle to není nutné, ovšem je dobré port explicitně specifikovat. Hlavně pro případ, že by v systému zůstal proces v nestandardním stavu, který by daný port blokoval. V případě, že bude port explicitně určen, bude také nemožnost jeho otevření 42-8
pro komunikaci signalizována. Pokud by číslo portu nebylo uvedeno, program ústředny by prostě zvolil pro komunikaci port jiný, což by vedlo k nemožnosti realizace příchozích spojení. Služba by kvůli tomu tedy fungovala jen částečně, ale systém by nevykázal žádný chybový stav. Na řádku 4 je příkazem disallow specifikováno, které kodeky se nesmějí využít pro přenos. V tomto případě jsou zakázány všechny podporované, aby byly explicitně na řádcích 5 až 7 povoleny jen ty žádoucí. Tento zdánlivě nelogický postup zaručí využití opravdu jen těch kodeků, které jsou správcem ústředny vyžadovány. Na řádku 9 je definován kontext uživatele s označením trunkiax. S tímto jménem bude nadále pracovat celá ústředna. Řádek 10 specifikuje typ uživatele. Typem user je sděleno, že tento účet se bude využívat pro realizaci příchozích spojení, ať už přijdou z jakékoliv IP adresy. Řádek 11 nicméně specifikuje, že vzdálený systém nemá pevnou IP adresu. Je tedy jasné, že se pro správnou funkci bude muset v tomto případě u této konkrétní ústředny registrovat. Řádek 12 a 13 specifikuje přihlašovací údaje a řádek 14 volí kontext pro další zpracování spojení v číslovacím plánu. Při úpravě číslovacího plánu je nutno zajistit jednotné číslování v celé síti nebo alespoň volbu ústředny pomocí předvoleb. Vzorová ukázka velmi zjednodušeného číslovacího plánu je zobrazena ve výpisu 2. 1: [internal] 2: exten => _1XX,1,Macro(lokalni_hovor,${EXTEN}) 3: exten => _1XX,2,Hangup() 4: exten => _2XX,1,Dial(IAX2/trunkiax:trunk@192.168.0.3/${EXTEN}) 5: exten => _2XX,2,Dial(SIP/trunksip:trunk@192.168.0.3/${EXTEN}) 6: exten => _2XX,3,Dial(IAX2/trunk2:trunk@192.168.0.5/${EXTEN}) 7: exten => _2XX,4,Dial(SIP/trunksip2:trunk@192.168.0.5/${EXTEN}) 8: exten => _2XX,5,Playback(linka_neni_k_dispozici) 9: exten => _2XX,6,Hangup() 10: [macro-lokalni_hovor] 11: exten => s,1,dial(sip/${arg1},60) 12: exten => s,2,playback(vm-nobodyavail) 13: exten => s,3,congestion(5) 14: exten => s,4,hangup() Výpis 2: Vzorová konfigurace extensions.conf Na řádku 1 je zvolen odpovídající kontext. Musí se jednat o stejný kontext, jako je specifikován v souboru iax.conf. Řádky 2,3 a 10 až 14 jsou určeny pro zajištění základní funkčnosti připojených IP SIP telefonů, a nejsou tedy pro tento text důležité. Na řádku 4 je zvolen primární trunk pro propojení se vzdálenou ústřednou. V případě, že ústředna nebude na volání odpovídat, je systém připraven zvolit náhradní řešení a komunikovat pomocí protokolu SIP (řádek 5). V případě neúspěchu je možno realizovat pokus o spojení s náhradní ústřednou (řádky 6 a 7). Pokud ani tento pokus neuspěje, je uživateli přehráno chybové hlášení a hovor je ukončen. 2.5 Ověření funkčnosti IAX Trunk Při ověření funkčnosti byl sestaven systém podle schématu na obr. 2. Při nastavení byly u první ústředny zvoleny telefonní čísla z rozsahu 1xx a u druhé z rozsahu 2xx. Při testování nebyly zjištěny žádné větší obtíže. Průběh komunikace tak, jak je zaznamenán volající ústřednou je znázorněn na výpisu 3, na straně volajícího na výpisu 4. 42-9
1: -- Executing Dial("SIP/100-a95c", "IAX2/trunkiax:trunk@192.168.0.3/201") in new stack 2: -- Called trunkiax:trunk@192.168.0.3/201 3: -- Call accepted by 192.168.0.3 (format gsm) 4: -- Format for call is gsm 5: -- IAX2/192.168.0.3:4569-1 is ringing 6: -- IAX2/192.168.0.3:4569-1 stopped sounds 7: -- IAX2/192.168.0.3:4569-1 answered SIP/100-a95c 8: -- Hungup 'IAX2/192.168.0.3:4569-1' 9: == Spawn extension (internal, 6201, 1) exited non-zero on 'SIP/100-a95c' Výpis 3: Sestavení spojení pomocí protokolu IAX, volající strana 1: -- Accepting AUTHENTICATED call from 192.168.0.61: 2: > requested format = alaw, 3: > requested prefs = (gsm alaw), 4: > actual format = gsm, 5: > host prefs = (gsm), 6: > priority = mine 7: -- Executing [201@internal:1] Macro("IAX2/192.168.0.61:4569-1", "call SIP/201") in new stack 8: -- Executing [s@macro-call:1] Dial("IAX2/192.168.0.61:4569-1", "SIP/201 30") in new stack 9: -- Called 201 10: -- SIP/201-081c9cb8 is ringing 11: -- SIP/201-081c9cb8 answered IAX2/192.168.0.61:4569-1 12: == Spawn extension (macro-call, s, 1) exited non-zero on 'IAX2/192.168.0.61:4569-1' in macro 'call' 13: == Spawn extension (macro-call, s, 1) exited non-zero on 'IAX2/192.168.0.61:4569-1' 14: -- Hungup 'IAX2/192.168.0.61:4569-1' Výpis 4: Sestavení spojení pomocí protokolu IAX, volaná strana Je vidět, že na počátku je u volající strany vyvoláno ochozí volání a poté dochází ke společnému sjednání použitého kodeku. Vždy je použit jen takový kodek, který podporují obě strany komunikace. Na řádku 7 u volající strany, respektive 11 u volané strany je signalizováno vyzvednutí volání druhou stranou a hovor je spojen. Ukončení hovoru je odpovídajícím způsobem signalizováno spojení je zrušeno (8, 14). 3 Závěr Protokol IAX byl speciálně navržen jako jednoduchý a robustní VoIP protokol s minimálními nároky na šířku pásma. Jeho nejčastější využití je realizace trunků, tedy propojení dvou VoIP ústředen. V současné době existuje ve verzi 2 a bývá používán i pro spojení s klientskými zařízeními. Výhodou IAX, oproti kombinaci protokolů SIP/RTP, je jednotný kanál pro signalizační, synchronizační i hovorová data, díky čemuž je možno ušetřit část režií a lépe realizovat propojení přes firewall a mezi zónami NAT. IAX je také přímo navržen pro využití 42-10
jednoho virtuálního kanálu pro více spojení. Tím se sníží vytížení linky využité pro komunikaci, nároky na řídící procesor ústředny i využití operační paměťi, neboť i při větším počtu současných hovorů nebude nutno uchovávat informace o tak velkém počtu přenosových kanálů. Proto existuje snaha protokol IAX nasazovat také do levných IP telefonů, protože při jeho využití lze ušetřit značnou část výrobních nákladů volbou méně náročných komponent. Dle předběžných zjištění by mělo být navíc možné pomocí protokolu IAX také sdílet číslovací plán, což bude ve výsledku znamenat mnohem snazší konfiguraci celého systému. Ověření této skutečnosti bude následovat při vytvoření funkčních prototypů všech částí systému. Předběžné výsledky ovšem naznačují, že jako mnohem výhodnější řešení se bude jevit online aktualizace veškerých konfiguračních dat z řídícího uzlu celého systému. Poděkování Tento článek vznikl při práci na projektech MPO FT-TA3/011. Literatura [1] Internet Engineering Task Force: IAX2: Inter-Asterisk exchange Version 2, návrh č. 4. [online návrh standardu] http://tools.ietf.org/id/draft-guy-iax-04.txt [2] Internet Assigned Numbers Authority: Port Numbers. [online standard] http://www.iana.org/assignments/port-numbers [3] Internet Engineering Task Force: The E.164 to Uniform Resource Identifiers (URI), Dynamic Delegation Discovery System (DDDS) Application (ENUM). [online standard], http://www.ietf.org/rfc/rfc3761.txt [4] PETERKA, J. Co je ENUM?, Lupa.cz, 2006. [online], http://www.lupa.cz/clanky/co-jeenum/ [5] voip-info.org: IAX versus SIP [online]. http://www.voipinfo.org/wiki/view/iax+versus+sip [6] MAHLER, P. VoIP Telephony with Asterisk. Burlingame: Signate, 2005. ISBN-0975999222 [7] Internet Engineering Task Force: Guidelines and Registration Procedures for New URI Schemes. [online standard] http://www.rfc-editor.org/rfc/rfc4395.txt 42-11