Poznańskie Warsztaty Telekomunikacyjne PWT2004

www.pwt.et.put.poznan.pl
Sylwester Kaczmarek
Politechnika Gdańska, Gdańsk
Wydział ETI, Katedra Systemów i Sieci Telekomunikacyjnych
[email protected]
Marek Wlizło
DGT Sp. z o.o., Gdańsk
[email protected]
2004
Poznańskie Warsztaty Telekomunikacyjne
Poznań 9 - 10 grudnia 2004
ANALIZA SYSTEMÓW WSPÓŁPRACY GATEKEEPERÓW
Streszczenie: Referat obejmuje zagadnienia związane z
zapewnieniem współpracy pomiędzy gatekeeperami pracującymi w systemie VoIP działającym w oparciu o zbiór
zaleceń ITU-T H.323. Zaprezentowano podstawowe topologie pracy gatekeeperów. Uwzględniono omówienie pojęć
związanych z alternatywnymi gatekeeperami. Przedstawiono wykorzystywaną implementację gatekeepera, modele
laboratoryjne i przyjęte scenariusze. Omówiono wyniki
badań i dalsze prace związane z tematem gatekeeperów.
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.
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 uwierzytelnianie terminali/gatewayów, kontrola pasma, realizacja billingu itp. W systemie VoIP może występować
wiele współpracujących ze sobą gatekeeperów. Gatekeeper może fizycznie współistnieć na jednej platformie
sprzętowej z innym elementem systemu H.323 (np. innym 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 pomię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-
PWT 2004, Poznań 9 - 10 grudnia 2004
Rys. 1. Strefa i elementy ją tworzące
Referat jest zorganizowany w ten sposób, że w rozdziale drugim zaprezentowano cechy funkcjonalne gatekeepera. Następnie w rozdziale trzecim omówiono
dwie podstawowe topologie pracy gatekeeperów: płaską
i hierarchiczną, oraz przybliżono zagadnienie współpracy 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) – gatekeeper powinien dokonywać zamiany aliasów na adresy
transportowe1, przy użyciu tablicy translacji, aktualizowanej np. poprzez wiadomości RRQ (Registration
Request),
1
Adres transportowy tworzy para: adres sieciowy IP i identyfikator
TSAP (numer portu)
1
www.pwt.et.put.poznan.pl
• kontroli dostępu (Admission Control) – gatekeeper
powinien autoryzować dostęp do sieci VoIP, wykorzystując wiadomości ARQ/ACF/ARJ (Admission Request/Admission Confirmation/Admission Reject), dostę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 dostę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 Confirmation/Bandwidth Change Reject) związane z zarządzaniem pasmem, pomimo tego gatekeeper nie musi 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 Signalling) – gatekeeper decyduje czy przetwarzać kanał sygnalizacji zgłoszeń zestawiony pomiędzy elementami
końcowymi, czy też nie,
• autoryzacji połączenia (Call Authorization) – używają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 jednocześ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ć, funkcja ta dotyczy również przypadku przydzielania terminalowi dodatkowego pasma podczas trwania połączenia,
• 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 powinien 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 szybkiego wybierania, wspomaganie konfiguracji punktu
PWT 2004, Poznań 9 - 10 grudnia 2004
końcowego, autoryzacja użytkownika.
W praktyce gatekeeper realizowany jest w postaci
implementacji programowej uruchamianej na określonej
platformie sprzętowej (np. profesjonalnych komputerach, 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 systemach, w których występuje duża liczba punktów końcowych zachodzi potrzeba stosowania większej liczby
gatekeeperów. W związku z tym należy umożliwić komunikację pomiędzy punktami końcowymi obsługiwanymi przez różne gatekeepery. Ponadto, nierzadko konieczne jest wprowadzenie logicznego podziału abonentów przykładowo ze względu na ich różne rozmieszczenie geograficzne. Rozwiązaniem jest zbudowanie systemu połączeń pomiędzy gatekeeperami zlokalizowanymi
w strukturze płaskiej lub/oraz w strukturze hierarchicznej gatekeeperów, w którym poszczególne gatekeepery
współpracują ze sobą wymieniając odpowiednie wiadomości. Użyta topologia połączeń gatekeeperów determinuje w jaki sposób zgłoszenia będą rutowane przez gatekeepery, a to wymusza implementację określonych
planów numeracyjnych. Wyróżnia się dwie główne topologie sieci gatekeeperów: płaską i hierarchiczną.
W topologii płaskiej (Rys. 2) każdy gatekeeper musi 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 przypadku konieczności obsługi połączeń wychodzących i przychodzą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ź niekontrolowanego włączania/wyłączania danego gatekeepera) to
tablica ta musi być aktualizowana w każdym z sąsiednich gatekeeperów. W dużych sieciach mechanizm ten
może być dość kłopotliwy i złożony przy realizacji.
2
www.pwt.et.put.poznan.pl
W topologii hierarchicznej, gatekeeper musi znać
dane adresowe (tj. adresy IP, numery odpowiednich
portów) tylko gatekeeperów zlokalizowanych w hierarchii bezpośrednio nad i pod nim. Jakiekolwiek zmiany w
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-
Rys. 2. Płaska struktura gatekeeperó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 hierarchicznej 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 dostępowych, gdzie zlokalizowani są użytkownicy końcowi. 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 czterech 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,
PWT 2004, Poznań 9 - 10 grudnia 2004
wy w przypadku jego awarii, przeciążenia lub konieczności wyłączenia (związanej przykładowo ze zmianą
parametrów konfiguracyjnych).
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
3
www.pwt.et.put.poznan.pl
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 przeprowadzono testy, które polegały na obserwacji pakietów wymienianych pomiędzy elementami badanego systemu
H.323 zgodnych ze specyfikacją ITU-T H.225.0 [2] oraz
weryfikacji zgodności używanej implementacji gatekeepera z zaleceniem ITU-T H.323. Pakiety monitorowano
przy pomocy narzędzia Ethereal [7].
• nagła i nieprzewidywalna awaria gatekeepera alternatywnego GK4.
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 74102 korzysta domyślnie z usług RAS gatekeepera podstawowego GK1. W przypadku awarii bądź przeciążenia GK1, ATK korzysta najpierw z usług GK4, a
gdy i ten ulegnie awarii bądź przeciążeniu, to wykorzystywany jest GK5. Przetestowano, więc następujące
scenariusze:
• przeciążenie gatekeepera podstawowego GK1 (zrealizowane poprzez ustawienie maksymalnej liczby zarejestrowanych 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
dla usługi POTS [3],[4]
PWT 2004, Poznań 9 - 10 grudnia 2004
Rys. 5. ATK i alternatywne gatekeepery - schemat blokowy badanego systemu
Każdy z trzech przetestowanych scenariuszy został
tak przygotowany, by pokazać jak ważna jest konieczność 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 alternatywnemu, 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-
4
www.pwt.et.put.poznan.pl
mie – dzięki temu mogą oni od razu przerejestrować
się do gatekeepera zastępczego, czyli GK4,
• nagła i nieprzewidywalna awaria gatekeepera alternatywnego GK4 – GK4 niespodziewanie znika z systemu 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 gatekeeperó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 aktywnie wykorzystuje się obecność w systemie gatekeeperó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 badanego 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ę gatekeepery 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 punkty końcowe (OhPhone). GK3 nie posiada u siebie zarejestrowanych ż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ł gatekeeperem 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łączonym do urządzenia ATK 7410. Zostanie, więc zrealizowane połączenie pomiędzy abonentem strefy 1 a abonentem 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ąsiednimi. Zaobserwowano, że w systemie takim połączenia
te mogą być z powodzeniem realizowane dzięki możliwości przekazywania pomiędzy gatekeeperami wiadomoś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 (Location Confirm). Od tego etapu fazy zestawiania połączenia, 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ą skonfigurowane 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 gatekeeper 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 blokowy badanego systemu
Jako główne cele testowe postawiono sobie realizację połączeń pomiędzy:
PWT 2004, Poznań 9 - 10 grudnia 2004
5
www.pwt.et.put.poznan.pl
• 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ładowo, 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 realizacji 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, zarejestrowane w niej punkty końcowe realizują pomiędzy sobą połączenia wykorzystując uproszczoną numerację (tzn. bez konieczności wybierania prefiksu
strefy), zasoby GK1 nie są używane, gdyż nie ma takiej potrzeby,
• międzystrefowe – punkt końcowy E inicjalizuje połączenie do punktu końcowego A, konieczne jest stosowanie 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, potwierdza, ż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łaskiej i hierarchicznej strukturze gatekeeperów. Nie oznacza to, że nie posiada ona błędów. Na szczęście nieustanne 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
PWT 2004, Poznań 9 - 10 grudnia 2004
H.323), albo już zostały poprawione, albo są w trakcie
korekt.
Poruszając inną kwestię, należy uczulić operatoró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 innymi 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żliwił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 systemów H.323 w sposób jasny i klarowny wymiarować
zasoby dla konkretnych systemów. Dzięki dalszym badaniom 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 badanej implementacji gatekeepera pozwalają na wprowadzanie wielu dodatkowych usług, zależnie od potrzeb
konkretnego systemu.
SPIS LITERATURY
[1] ITU-T Zalecenie H.323, Draft Revised Recommendation 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 packetization for packet-based multimedia communication systems” Version 5 (for Consent), Geneva, 2030 May 2003
[3] P. Gajos, Rozwiązania DGT w telefonii VoIP, materiał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
6