Wydział ETI, Katedra Systemów i Sieci Telekomunikacyjnych kasyl@eti.pg.gda.pl

2004

Poznańskie Warsztaty Telekomunikacyjne Poznań 9 - 10 grudnia 2004 Sylwester Kaczmarek

Politechnika Gdańska, Gdańsk

Wydział ETI, Katedra Systemów i Sieci Telekomunikacyjnych kasyl@eti.pg.gda.pl

Marek Wlizło

DGT Sp. z o.o., Gdańsk Marek.Wlizlo@dgt.com.pl

ANALIZA SYSTEMÓW WSPÓŁPRACY GATEKEEPERÓW

Streszczenie: Referat obejmuje zagadnienia związane z zapewnieniem współpracy pomiędzy gatekeeperami pracu- jącymi w systemie VoIP działającym w oparciu o zbiór zaleceń ITU-T H.323. Zaprezentowano podstawowe topolo- gie pracy gatekeeperów. Uwzględniono omówienie pojęć związanych z alternatywnymi gatekeeperami. Przedstawio- no wykorzystywaną implementację gatekeepera, modele laboratoryjne i przyjęte scenariusze. Omówiono wyniki badań i dalsze prace związane z tematem gatekeeperów.

1. WPROWADZENIE

Gatekeeper to fundamentalny element w sieci H.323. Bez gatekeepera nie da się zrealizować żadnych dodatkowych usług typu: połączenia konferencyjne lub dostęp do sieci publicznej poprzez gateway. Gatekeeper jest punktem centralnym służącym do kontroli i zarzą- dzania połączeniami realizowanymi w systemie VoIP działającym w oparciu o zbiór zaleceń ITU-T H.323 [1].

Pomimo, iż gatekeepery nie są wymagane w systemach H.323 to dostarczają one wielu ważnych usług takich jak: translacja adresów, autoryzacja abonentów i uwie- rzytelnianie terminali/gatewayów, kontrola pasma, reali- zacja billingu itp. W systemie VoIP może występować wiele współpracujących ze sobą gatekeeperów. Gateke- eper może fizycznie współistnieć na jednej platformie sprzętowej z innym elementem systemu H.323 (np. in- nym gatekeeperem lub terminalem). Gatekeeper wraz z obsługiwanymi przez niego elementami systemu H.323 tworzą tzw. strefę (Rys.1). W danej strefie w danym momencie może być aktywny tylko jeden gatekeeper, choć fizycznie może się on składać z wielu urządzeń. W systemie H.323 może współistnieć wiele stref, a dzięki zapewnieniu współpracy pomiędzy nimi możliwa jest realizacja połączeń międzystrefowych. Współpraca ta polega na wymianie wiadomości sygnalizacyjnych po- między gatekeeperami.

Gatekeepery mogą pracować w klastrach wydajno- ściowych (współpraca gatekeeperów sąsiednich) oraz niezawodnościowych (korzystanie z usług gatekeeperów alternatywnych).

Jeśli w systemie nie występuje gatekeeper, to nikt nie ma żadnej technicznej kontroli nad wykorzystaniem zasobów sieciowych. Użytkownicy mogą dowolnie ob-

ciążać łącze sieciowe dowolnym ruchem. Wtedy nawet przy korzystaniu z sieci zapewniającej gwarancję QoS (Quality of Service) a przy braku pasma dla przenoszenia połączeń, niektóre połączenia mogą być realizowane przy obniżonej jakości lub wcale nie dojdą do skutku.

Ponadto punkty końcowe przy braku gatekeeperów nie mogą adresować abonentów żądanych przy pomocy aliasów, lecz jedynie z wykorzystaniem ich adresów IP.

Rys. 1. Strefa i elementy ją tworzące

Referat jest zorganizowany w ten sposób, że w roz- dziale drugim zaprezentowano cechy funkcjonalne ga- tekeepera. Następnie w rozdziale trzecim omówiono dwie podstawowe topologie pracy gatekeeperów: płaską i hierarchiczną, oraz przybliżono zagadnienie współpra- cy gatekeepera z gatekeeperami alternatywnymi. W rozdziale czwartym zaprezentowano wykorzystywaną implementację gatekeepera oraz opisano przebieg badań laboratoryjnych omówionych w rozdziale czwartym schematów współpracy gatekeeperów. W rozdziale pią- tym podsumowano wyniki badań oraz wytyczono tok dalszych prac w tym temacie.

2. FUNKCJONALNOŚĆ GATEKEEPERA Gdy gatekeeper występuje w systemie, to powinien obowiązkowo świadczyć następujące usługi:

• translacji adresów (Address Translation) – gateke- eper powinien dokonywać zamiany aliasów na adresy transportowe

, przy użyciu tablicy translacji, aktuali- zowanej np. poprzez wiadomości RRQ (Registration Request),

1

Adres transportowy tworzy para: adres sieciowy IP i identyfikator TSAP (numer portu)

1

• kontroli dostępu (Admission Control) – gatekeeper powinien autoryzować dostęp do sieci VoIP, wykorzy- stując wiadomości ARQ/ACF/ARJ (Admission Requ- est/Admission Confirmation/Admission Reject), do- stęp ten może być zależny od autoryzacji połączenia, szerokości dostępnego pasma lub innych kryteriów (producent może je sam określić), funkcję kontroli do- stępu można oczywiście wyłączyć,

• kontroli pasma (Bandwidth Control) – gatekeeper powinien obsługiwać wiadomości BRQ/BCF/BRJ (Bandwidth Change Request/Bandwidth Change Con- firmation/Bandwidth Change Reject) związane z za- rządzaniem pasmem, pomimo tego gatekeeper nie mu- si mieć zaimplementowanych mechanizmów zarzą- dzania pasmem – akceptuje wtedy wszystkie żądania o przydział pasma,

• zarządzania strefą (Zone Management) – gatekeeper powinien dostarczać wyżej wymienionych usług dla terminali, MCU (Multipoint Control Units) i gateway- ów zarejestrowanych u niego.

Gatekeeper może opcjonalnie świadczyć następują- ce usługi:

• obsługi sygnalizacji zgłoszeń (Call Control Signal- ling) – gatekeeper decyduje czy przetwarzać kanał sy- gnalizacji zgłoszeń zestawiony pomiędzy elementami końcowymi, czy też nie,

• autoryzacji połączenia (Call Authorization) – używa- jąc sygnalizacji H.225.0 gatekeeper może odmówić realizacji połączenia w przypadku błędnej autoryzacji,

• zarządzania pasmem (Bandwidth Management) – gatekeeper może kontrolować liczbę terminali jedno- cześnie korzystających z zasobów sieci, oznacza to, że w przypadku braku pasma potrzebnego do realizacji połączenia gatekeeper może go nie zrealizować, funk- cja ta dotyczy również przypadku przydzielania termi- nalowi dodatkowego pasma podczas trwania połącze- nia,

• zarządzania połączeniami (Call Management) – gatekeeper może posiadać listę aktywnych połączeń, by poinformować o stanie zajętości terminala, gdy jest do niego inne zgłoszenie, oraz by dostarczyć ją do funkcji zarządzania pasmem,

• modyfikacji aliasów – gatekeeper może przekazać terminalowi jego zmodyfikowany alias, którym powi- nien się on od tej pory posługiwać,

• translacji numerów na adresy sieciowe – gatekeeper może zamieniać przypisane numery na numerację zgodną z E.164 lub na adresy transportowe,

• zarządzania siecią gatekeeperów,

• rezerwacji pasma dla terminali,

• usługi katalogowe – odpowiedzialne między innymi za: skojarzenie użytkownika z punktem końcowym, obsługę funkcji książka telefoniczna i funkcji szybkie- go wybierania, wspomaganie konfiguracji punktu

końcowego, autoryzacja użytkownika.

W praktyce gatekeeper realizowany jest w postaci implementacji programowej uruchamianej na określonej platformie sprzętowej (np. profesjonalnych kompute- rach, PC, Sun).

3. SYSTEMY WSPÓŁPRACY GATEKEEPERÓW Gatekeeper uruchomiony jest na platformie sprzę- towej, która ma skończone możliwości obliczeniowe, w związku z tym może on obsłużyć w danym momencie ograniczoną liczbę punktów końcowych. Stąd w syste- mach, w których występuje duża liczba punktów końco- wych zachodzi potrzeba stosowania większej liczby gatekeeperów. W związku z tym należy umożliwić ko- munikację pomiędzy punktami końcowymi obsługiwa- nymi przez różne gatekeepery. Ponadto, nierzadko ko- nieczne jest wprowadzenie logicznego podziału abonen- tów przykładowo ze względu na ich różne rozmieszcze- nie geograficzne. Rozwiązaniem jest zbudowanie syste- mu połączeń pomiędzy gatekeeperami zlokalizowanymi w strukturze płaskiej lub/oraz w strukturze hierarchicz- nej gatekeeperów, w którym poszczególne gatekeepery współpracują ze sobą wymieniając odpowiednie wiado- mości. Użyta topologia połączeń gatekeeperów determi- nuje w jaki sposób zgłoszenia będą rutowane przez ga- tekeepery, a to wymusza implementację określonych planów numeracyjnych. Wyróżnia się dwie główne topo- logie sieci gatekeeperów: płaską i hierarchiczną.

W topologii płaskiej (Rys. 2) każdy gatekeeper mu- si znać lokalizację swoich gatekeeperów sąsiednich (przykładowo dla GK_7 gatekeeperami sąsiednimi są:

GK_1 i GK_6). Zgodnie z zasadami przyjętymi przez

twórców wykorzystywanej w badaniach implementacji

gatekeepera (patrz rozdział 4) każdy gatekeeper posiada

tablicę z adresami IP przypisanych jemu gatekeeperów

sąsiednich. Z tablicy tej gatekeeper korzysta w przypad-

ku konieczności obsługi połączeń wychodzących i przy-

chodzących do jego strefy. Jeśli w rozległej sieci VoIP

zbudowanej w oparciu o płaską topologię gatekeeperów

(może być ich kilkadziesiąt) dochodzi do częstych zmian

jej struktury (wynikających przykładowo z: dodania

nowego gatekeepera, kontrolowanego bądź niekontrolo-

wanego włączania/wyłączania danego gatekeepera) to

tablica ta musi być aktualizowana w każdym z sąsied-

nich gatekeeperów. W dużych sieciach mechanizm ten

może być dość kłopotliwy i złożony przy realizacji.

W topologii hierarchicznej, gatekeeper musi znać dane adresowe (tj. adresy IP, numery odpowiednich portów) tylko gatekeeperów zlokalizowanych w hierar- chii bezpośrednio nad i pod nim. Jakiekolwiek zmiany w

strukturze sieci gatekeeperów nie wymagają zmian w tablicach każdego gatekeepera. W związku z tym jest to system łatwiejszy do zarządzania.

W zaprezentowanym na Rys. 3 przykładzie hierar- chicznej struktury gatekeeperów najwyższy w hierarchii jest tzw. podstawowy gatekeeper katalogowy (GK1a i GK1b), który zwykle jest klastrem gatekeeperów. U gatekeepera tego zarejestrowane są tzw. subgatekeepery (GK2A, GK2B), umieszczane zwykle w obszarach do- stępowych, gdzie zlokalizowani są użytkownicy końco- wi. Każdemu subgatekeeperowi przyporządkowane są prefiksy odpowiadające przykładowo obsługiwanemu obszarowi dostępowemu. Liczba kolejnych poziomów subgatekeeperów jest zależna od zapotrzebowania w lokalnym systemie (na Rys. 3 pokazano system o czte- rech poziomach hierarchii). Przykładowo subgatekeeper GK_2B3C4B może być odpowiednikiem w technologii VoIP dotychczas stosowanej w firmie centralki PABX, obsługującym ruch lokalny (połączenia wewnątrz firmy) oraz zewnętrzny. U subgatekeeperów najniższych w hierarchii zarejestrowane są terminale abonentów.

W celu zapewnienia gwarancji dostępu do systemu, nadmiarowości oraz skalowalności gatekeeper może obsługiwać funkcje sygnalizacji RAS (Registration,

Admission and Status), wykorzystując kilka fizycznych lub logicznych urządzeń, określanych jako alternatywne gatekeepery (patrz Rys. 4). Gatekeepery alternatywne zastępują funkcje pełnione przez gatekeeper podstawo-

wy w przypadku jego awarii, przeciążenia lub koniecz- ności wyłączenia (związanej przykładowo ze zmianą parametrów konfiguracyjnych).

Rys. 2. Płaska struktura gatekeeperów

Rys. 4. Gatekeepery alternatywne

4. MODEL LABORATORYJNY I TESTY

Najbardziej popularną na świecie, wykorzystywaną

komercyjnie implementacją gatekeepera jest The GNU

Gatekeeper (w skrócie GnuGk) dostępna na zasadach

licencji GPL ([5], [6]). Wykorzystywano ją w badaniach

Rys. 3. Hierarchiczna struktura gatekeeperów laboratoryjnych. W dalszej części referatu omówiono

przydatność tej implementacji na potrzebę realizacji systemu gatekeeperów alternatywnych oraz płaskiej i hierarchicznej topologii gatekeeperów. Po odpowiednim skonfigurowaniu każdego z gatekeeperów przeprowa- dzono testy, które polegały na obserwacji pakietów wy- mienianych pomiędzy elementami badanego systemu H.323 zgodnych ze specyfikacją ITU-T H.225.0 [2] oraz weryfikacji zgodności używanej implementacji gateke- epera z zaleceniem ITU-T H.323. Pakiety monitorowano przy pomocy narzędzia Ethereal [7].

4.1. GnuGk i alternatywne gatekeepery Na Rys. 5 przedstawiono schemat blokowy połą- czeń logicznych elementów badanego systemu H.323. W systemie tym GK1 pełni rolę gatekeepera podstawowego natomiast GK4 i GK5 to jego gatekeepery alternatywne.

ATK 7410

korzysta domyślnie z usług RAS gatekeepe- ra podstawowego GK1. W przypadku awarii bądź prze- ciążenia GK1, ATK korzysta najpierw z usług GK4, a gdy i ten ulegnie awarii bądź przeciążeniu, to wykorzy- stywany jest GK5. Przetestowano, więc następujące scenariusze:

• przeciążenie gatekeepera podstawowego GK1 (zreali- zowane poprzez ustawienie maksymalnej liczby zare- jestrowanych u niego punktów końcowych na 2),

• celowe wyłączenie gatekeepera podstawowego GK1,

2

ATK 7410 – urządzenie produkowane przez firmę DGT Sp. z o.o., będące platformą sprzętowo-programową dedykowaną do realizacji telefonii VoIP z wykorzystaniem zwykłych aparatów telefonicznych

• nagła i nieprzewidywalna awaria gatekeepera alterna- tywnego GK4.

Rys. 5. ATK i alternatywne gatekeepery - schemat blo- kowy badanego systemu

Każdy z trzech przetestowanych scenariuszy został tak przygotowany, by pokazać jak ważna jest koniecz- ność stosowania zabezpieczeń w postaci alternatywnych gatekeeperów. Wnioski końcowe odnośnie testowanych scenariuszy:

• przeciążenie gatekeepera podstawowego – zgodnie z założeniem GK1 nie mogąc zarejestrować u siebie więcej niż dwóch punktów końcowych przekazuje ich obsługę swojemu pierwszemu gatekeeperowi alterna- tywnemu, czyli GK4,

• celowe wyłączenie gatekeepera podstawowego GK1 –

GK1 przed wyłączeniem zdąży jeszcze poinformować

swych klientów o tym, że kończy swą pracę w syste-

mie – dzięki temu mogą oni od razu przerejestrować się do gatekeepera zastępczego, czyli GK4,

• nagła i nieprzewidywalna awaria gatekeepera alterna- tywnego GK4 – GK4 niespodziewanie znika z syste- mu H.323 (np. na skutek awarii zasilania), jednakże punkty końcowe periodycznie co czas TimeToLive sprawdzają obecność GK4 w systemie i dzięki temu dowiadują się o jego braku – wtedy przerejestrowują się do GK5.

Ta dość specyficzna metoda współpracy gatekeepe- rów wynikająca przede wszystkim z konieczności speł- nienia względów niezawodnościowych systemu może zostać z powodzeniem wykorzystana w konfiguracji, w której dwa gatekeepery zabezpieczają sobie nawzajem dostęp do usług. Dzięki temu, każdy z gatekeeperów czynnie obsługuje swoje punkty końcowe, a w razie potrzeby i punkty końcowe sąsiada. W ten sposób ak- tywnie wykorzystuje się obecność w systemie gateke- eperów alternatywnych w celu odciążenia gatekeeperów podstawowych przy dużym ruchu w sieci.

4.2. GnuGk i płaska topologia gatekeeperów Na Rys.6 przedstawiono schemat blokowy badane- go systemu H.323. W systemie tym można testować różne scenariusze połączeń międzystrefowych w płaskiej topologii gatekeeperów. Na system składają się gateke- epery GK1, GK2 i GK3. U GK1 zarejestrowany jest programowy punkt końcowy H.323 OpenPhone, GK2 z kolei obsługuje ATK 7410, na który składają się 4 punk- ty końcowe (OhPhone). GK3 nie posiada u siebie zareje- strowanych żadnych punktów końcowych, gdyż jego rola skupia się tu jedynie na przekazywaniu wiadomości odpowiedzialnych za lokalizację punktów końcowych.

Gatekeepery skonfigurowano tak, by GK1 nie był gatek- eeperem sąsiednim dla gatekeepera GK2 (i vice versa), natomiast gatekeeper GK3, był gatekeeperem sąsiednim zarówno dla GK1 jak i dla GK2 (i vice versa).

Rys. 6. ATK i sąsiednie gatekeepery – schemat blokowy badanego systemu

Przyjęto następujący scenariusz połączenia: klient programowy H.323 OpenPhone E inicjalizuje wymianę strumienia audio (usługi mowa) z aparatem B podłączo- nym do urządzenia ATK 7410. Zostanie, więc zrealizo- wane połączenie pomiędzy abonentem strefy 1 a abonen- tem strefy 2.

Struktura logiczna analizowanego systemu została tak dobrana, by zaprezentować wymianę wiadomości sygnalizacyjnych, gdy zachodzi potrzeba realizacji połą- czeń pomiędzy punktami końcowymi zlokalizowanymi w strefach, których gatekeepery nie są dla siebie sąsied- nimi. Zaobserwowano, że w systemie takim połączenia te mogą być z powodzeniem realizowane dzięki możli- wości przekazywania pomiędzy gatekeeperami wiado- mości LRQ (Location Request). Gdy LRQ dociera od GK1 poprzez GK3 do GK2 to następuje stwierdzenie obecności u GK2 poszukiwanego punktu końcowego, wtedy GK2 wysyła bezpośrednio do GK1 potwierdzenie odnalezienia żądanego punktu końcowego LCF (Loca- tion Confirm). Od tego etapu fazy zestawiania połącze- nia, GK1 i GK2 zapominają o istnieniu GK3, który był wykorzystany jedynie do przekazania wiadomości LRQ.

Wynika z tego, że, pomimo iż GK1 i GK2 nie są skonfi- gurowane jako gatekeepery sąsiednie, to jednak możliwe jest zrealizowanie połączenia pomiędzy ich strefami.

4.3. GnuGk i hierarchiczna topologia gatekeeperów Na Rys. 7 przedstawiono schemat systemu H.323, w którym badano współpracę gatekeeperów GK1 i GK2 pracujących w strukturze hierarchicznej. GK1 to gateke- eper nadrzędny, a GK2 – podrzędny. Jak wynika ze schematu blokowego GK1 obsługuje: programowego klienta H.323 OpenPhone (E) oraz gatekeeper GK2 pracujący jako punkt końcowy. Natomiast GK2 ma u siebie zarejestrowane punkty końcowe należące do urzą- dzenia ATK 7410, tj. A, B, C i D.

Rys. 7. ATK i nadrzędne gatekeepery – schemat bloko- wy badanego systemu

Jako główne cele testowe postawiono sobie realiza-

cję połączeń pomiędzy:

• punktami końcowymi zlokalizowanymi na różnych poziomach hierarchii systemu H.323 – tj. punktem końcowym E i jednym z punktów końcowych ATK 7410 (np. punktem końcowym A),

• punktami końcowymi zlokalizowanymi na tym samym poziomie hierarchii.

Te dwa jakże odmienne schematy połączeń mają ukazać zasadność wprowadzania do systemu H.323 hierarchicznej struktury połączeń gatekeeperów.

Z Rys. 7 wynika, że strefa 1 obejmuje swym zasię- giem strefę 2. Oznacza to, że GK2 rejestruje się u GK1 tak jakby był punktem końcowym. Wynikające z tego tytułu konsekwencje są łatwe do przewidzenia. Przykła- dowo, gdy GK2 chce obsłużyć połączenie zewnętrzne wychodzące lub przychodzące (takie właśnie testowano) do jego strefy to wymagane jest uzyskanie na to zgody od GK1. Potwierdzają to wyniki przeprowadzonych badań. Niewątpliwą zaletą pracy gatekeepera jedynie w strukturze hierarchicznej jest uproszczenie procesu reali- zacji połączeń międzystrefowych, co nierozerwalnie związane jest z koniecznością nadawania prefiksów dla stref obsługiwanych przez gatekeepery podrzędne, gdyż to właśnie na podstawie analizy prefiksu gatekeepery dowiadują się gdzie zlokalizowany jest żądany punkt końcowy. W rozważanym systemie o dwóch poziomach hierarchii zaprezentowano dwa różne warianty realizacji połączeń:

• wewnątrzstrefowe – dotyczy strefy 2, punkt końcowy A inicjalizuje połączenie do punktu końcowego B, za- rejestrowane w niej punkty końcowe realizują pomię- dzy sobą połączenia wykorzystując uproszczoną nu- merację (tzn. bez konieczności wybierania prefiksu strefy), zasoby GK1 nie są używane, gdyż nie ma ta- kiej potrzeby,

• międzystrefowe – punkt końcowy E inicjalizuje połą- czenie do punktu końcowego A, konieczne jest stoso- wanie pełnego numeru żądanego punktu końcowego (tj. z podaniem prefiksu), GK1 i GK2 biorą czynny udział przy obsłudze sygnalizacji RAS połączenia.

5. PODSUMOWANIE

Dokładna analiza wymienianych wiadomości, po- twierdza, że badana implementacja gatekeepera dość wiernie realizuje podstawowe wymogi stawiane przez zbiór zaleceń ITU-T H.323 dla przypadku korzystania z usług gatekeeperów alternatywnych oraz pracy w pła- skiej i hierarchicznej strukturze gatekeeperów. Nie ozna- cza to, że nie posiada ona błędów. Na szczęście nie- ustanne prace nad udoskonalaniem kodu źródłowego wykonywane przez programistów na całym świecie powodują, że większość niezgodności z zaleceniami ITU-T, które zostały zauważone i upublicznione przez użytkowników (głównie administratorów systemów

H.323), albo już zostały poprawione, albo są w trakcie korekt.

Poruszając inną kwestię, należy uczulić operato- rów, że tak jak ważne jest zapewnienie ciągłości dostępu do usług w dotychczas tradycyjnie wykorzystywanych systemach z komutacją szczelin czasowych, tak i w telefonii VoIP. W związku z tym, koniecznością jest wymóg stosowania gatekeeperów alternatywnych, jako kryterium dopuszczające system H.323 do pracy w sieci korporacyjnej a w przyszłości i publicznej.

Dalsze prace związane z gatekeeperami powinny skupić się na testowaniu współpracy gatekeepera z in- nymi elementami systemu H.323 tj. z gateway'ami i mostkami konferencyjnymi. Rozszerzeniem możliwości wykorzystywanej implementacji gatekeepera byłaby zapewne jego integracja z tzw. softswitchem, co umożli- wiłoby operatorowi świadczenie kompleksowych usług telekomunikacyjnych. Wręcz niezbędna jest analiza ruchowa wykorzystywanej implementacji, umożliwiają- ca określić jej rzeczywiste możliwości co do obsługi ruchu. Analiza taka umożliwiłyby projektantom syste- mów H.323 w sposób jasny i klarowny wymiarować zasoby dla konkretnych systemów. Dzięki dalszym ba- daniom można by oszacować ilu dodatkowych klientów jest w stanie obsłużyć już pracujący gatekeeper przy braku pogorszenia dotychczasowego GoS i QoS zauwa- żalnego przez klienta końcowego. Zagadnienia te zwią- zane są bezpośrednio z planowaniem zasobów, które uwzględnia możliwość wzrostu natężenia ruchu w sieci lub konieczność podłączenia nowych abonentów.

Należy dodać, że różnorodność zapotrzebowania klientów, a jednocześnie opensource'owy charakter ba- danej implementacji gatekeepera pozwalają na wprowa- dzanie wielu dodatkowych usług, zależnie od potrzeb konkretnego systemu.

SPIS LITERATURY

[1] ITU-T Zalecenie H.323, Draft Revised Recommen- dation H.323 V5 (for Consent), Geneva, 20-30 May 2003

[2] ITU-T Zalecenie H.225.0, Draft Revised H.225.0

“Call signaling protocols and media stream pack- etization for packet-based multimedia communica- tion systems” Version 5 (for Consent), Geneva, 20- 30 May 2003

[3] P. Gajos, Rozwiązania DGT w telefonii VoIP, mate- riały DGT Sp. z o.o., Gdańsk 2003

[4] G. Nitka, A. Orcholski, ATK – oprogramowanie, materiały DGT Sp. z o.o.

[5] www.gnugk.org – OpenH323 Gatekeeper – The GNU Gatekeeper for H.323 VOIP Systems [6] www.openh323.org – OpenH323 Project Web Site [7] www.ethereal.com - Ethereal A Network Protocol

Analyzer