Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
POLITECHNIKA WARSZAWSKA Rok akademicki Wydział Elektroniki i Technik Informacyjnych 2006/2007 Instytut Telekomunikacji
PRACA DYPLOMOWA MAGISTERSKA
Michał Jan Kościesza Michał Daniel Misiak
Modele implementacji usług w architekturze IMS
Praca wykonana pod kierunkiem dra inŜ. Marka Średniawy
……………………….. ocena pracy ……………………….. podpis Przewodniczącego Komisji
Warszawa, 2007 r.
„Models of service implementation in the IMS architecture”
Abstract
IMS is an IP-based service architecture specified by 3GPP for UMTS. The architecture
became main part of ETSI and ITU NGN reference model, which defines new public
telecommunication network architecture. IMS offers broad set of functionalities, like
multimedia sessions or context aware environment. These features open new service creation
opportunities, which require suitable software development models and technologies.
Parlay X is a set of technology-independent APIs which enable development of
applications that operate across different telecommunication networks. APIs contain abstract
methods (e.g. makeCall) that describe basic network functionalities. Parlay APIs can be
implemented on SIP application servers and thus can be adapted to the IMS service model.
Jain-SLEE is a Java based service execution environment, which defines a component based
model for structuring the application logic of communications. JSLEE represents a different
approach in comparison to Parlay concept and defines both an execution environment and
API. Using SIP resource adapter JSLEE implementation can be used as an IMS application
server.
The thesis focuses on analysis of IMS service architecture and different programming
approaches that can be used in the service implementation process. Within the scope was also
implementation of an IMS environment, based on open source software. This process was
divided into 3 areas:
- IMS service control model, which is responsible for session-handling transfer to
specified application server based on subscriber profile.
- Parlay X capability server that implements selected APIs in the IMS environment.
- web-based application, which takes advantage of Parlay X APIs and implements end-
user service with rich “contacts management” functionality .
The environment became a “playground” for research on aspects of creating service
applications in a multi-layered, real-time and asynchronous next generation
telecommunication network.
“Modele implementacji usług w architekturze IMS”
Streszczenie
IMS jest architekturą usługową opracowaną przez 3GPP dla sieci UMTS. Referencyjny
model sieci NGN, który jest definiowany przez ETSI oraz ITU wykorzystuje IMS w swojej
rdzeniowej części. Nowa architektura oferuje szeroki zakres funkcjonalności, otwierający
nowe moŜliwości kreacji usług. Wymaga to opracowania modeli programistycznych, które
będą odpowiednie do nowego środowiska sieciowego.
Parlay X jest zbiorem API umoŜliwiających tworzenie aplikacji w sposób niezaleŜny od
rozwiązań technicznych zastosowanych w sieci. Zbiór ten złoŜony jest z abstrakcyjnych
metod (np. makeCall), które opisują podstawowe funkcjonalności sieci. Implementacja
Parlay X API jako serwera aplikacyjnego wykorzystującego protokół SIP, umozliwia
integracje z systemem IMS. Jain-SLEE jest środowiskiem programistycznym opartym o
model komponentowy umoŜliwiający tworzenie aplikacji, realizujących usługi
telekomunikacyjne. W odróŜnieniu od Parlay, definiuje zarówno API jak i środowisko
wykonywania usług. Wykorzystując tzw. SIP resource adapter, aplikacje Jain-SLEE mogą
być wykorzystywane do implementacji usług w IMS.
Przedmiotem niniejszej pracy jest analiza architektury usługowej IMS oraz technik
programistycznych, które mogą być wykorzystane w procesie implementacji. Zakres
obejmuje takŜe implementacje środowiska IMS opartego o oprogramowanie open source. Ten
proces moŜna podzielić na 3 obszary:
- Model sterowania połączeniami w IMS, który polega na przekazywaniu obsługi
zgłoszeń do serwerów aplikacyjnych w oparciu o profil uŜytkownika.
- Serwery implementujące wybrane interfejsy Parlay X w środowisku IMS
- Aplikacje wykorzystująca Parlay X API, do implementacji scenariusza usług.
Powstałe środowisko zostało wykorzystane do badań związanych z róŜnymi aspektami
kreacji usług w wielowarstwowej architekturze sieci następnej generacji.
śyciorysy
Michał Jan Kościesza
Urodziłem się w 29 października 1981 roku w Nowym Sączu.
Ukończyłem Liceum Ogólnokształcące im. Jana Zamoyskiego w
Warszawie i w roku 2002 rozpocząłem studia na Wydziale Elektroniki i
Technik Informacyjnych. Po dwóch latach wybrałem specjalność Teleinformatyka i
Zarządzanie w Telekomunikacji. Od 2005 roku pracuję w Działe Rozwoju Sieci Rdzeniowej i
Usług firmy Polkomtel S.A. Zdobytą na studiach wiedzę, a w szczególności tą podczas badań
związanych z przedmiotem tej pracy, z sukcesem wykorzystuję w Ŝyciu zawodowym.
Michał Daniel Misiak
Urodziłem się w 11 grudnia 1982 roku w Płocku. Ukończyłem Liceum
Ogólnokształcące im. Władysława Jagiełło w Płocku i w roku 2002
rozpocząłem studia na Wydziale Elektroniki i Technik Informacyjnych.
Po dwóch latach studiów wybrałem specjalność Teleinformatyka i
Zarządzanie w Telekomunikacji. W 2006 roku odbyłem stypendium
zagraniczne Sokrates-Erasmus w Niemczech na uczelni Hochschule Esslingen na wydziale
informatyki. W połowie 2006 roku przyjąłem propozycję stworzenia własnego działu
Rozwoju Produktu w eTel Telecom Austria Group i do chwili obecnej piastuję stanowisko
kierownika tegoŜ działu. Solidna wiedza zdobyta na studiach pozwala mi realizować się w
Ŝyciu zawodowym.
Prywatnie interesuje się fizyką teoretyczną oraz sportami motorowodnymi.
Autorzy pragną podziękować
Panu dr inŜ. Markowi Średniawie
za nieocenioną pomoc w trakcie pisania niniejszej pracy
Spis treści
śYCIORYSY ............................................................................................................................................. 2
ABSTRACT................................................................................................................................................ 2
SPIS TREŚCI ............................................................................................................................................. 5
1. WSTĘP ............................................................................................................................................... 9
2. SESSION INITIATION PROTOCOL........................................................................................... 15
2.1 WSTĘP....................................................................................................................................... 15
2.2 BUDOWA PROTOKOŁU ORAZ MODEL SESJI................................................................................. 15
2.3 K IERUNKI ROZWOJU I ROLA SIP W IMS..................................................................................... 19
3. IP MULTIMEDIA SUBSYSTEM .................................................................................................. 23
3.1 WSTĘP....................................................................................................................................... 23
3.2 IMS JAKO RDZENIOWA CZĘŚĆ ARCHITEKTURY NGN ................................................................ 24
3.3 ARCHITEKTURA IMS................................................................................................................. 27
3.4 PROFIL UśYTKOWNIKA .............................................................................................................. 33
3.5 MODEL STEROWANIA USŁUGAMI............................................................................................... 35
3.6 PROCES NAWIĄZYWANIA SESJI.................................................................................................. 38
3.7 K IERUNKI ROZWOJU.................................................................................................................. 38
4. PARLAY/OSA ORAZ PARLAY X................................................................................................ 42
4.1 GENEZA PARLAY /OSA.............................................................................................................. 42
4.2 OPIS PARLAY /OSA ................................................................................................................... 43
4.3 ARCHITEKTURA PARLAY /OSA..................................................................................................44
4.4 OGRANICZENIA PARLAY /OSA ..................................................................................................46
4.5 PARLAY X (PARLAY WEB SERVICES)........................................................................................ 46
4.6 MODELE BIZNESOWE................................................................................................................. 47
4.7 FUNKCJONALNOŚĆ PARLAY X API ........................................................................................... 48
4.8 ARCHITEKTURA PARLAY X......................................................................................................... 50
4.9 OGRANICZENIA PARLAY X........................................................................................................ 54
4.10 BEZPIECZEŃSTWO PARLAY X.................................................................................................... 55
4.11 M IEJSCE PARLAY /OSA I PARLAY X W ARCHITEKTURZE IMS ................................................... 57
5. JAIN SERVICE LOGIC EXECUTION ENVIRONMENT........... .............................................. 60
5.1 INICJATYWA JAIN..................................................................................................................... 60
5.2 DEFINICJA JSLEE, WYMAGANIA DLA JSLEE............................................................................ 62
5.3 PORÓWNANIE TECHNIK J2EE I JSLEE ...................................................................................... 64
5.4 PORÓWNANIE TECHNIK JSLEE VS SIP SERVLET....................................................................... 67
5.5 ARCHITEKTURA JSLEE............................................................................................................. 71
Spis Treści
7
5.6 PRZYKŁADOWA USŁUGA – BLOKOWANIE POŁĄCZEŃ ................................................................ 83
6. ROLA WOLNEGO OPROGRAMOWANIA W TWORZENIU USŁUG
TELEKOMUNIKACYJNYCH.................................................................................................... 87
6.1 WSTĘP....................................................................................................................................... 87
6.2 LINUX W ZASTOSOWANIACH TELEKOMUNIKACYJNYCH ............................................................ 88
6.3 OPEN SOURCE JSLEE – MOBICENTS......................................................................................... 89
6.4 OPEN SIP EXPRESS ROUTER......................................................................................................90
6.5 ASTERISK.................................................................................................................................. 92
6.6 OPEN IMS CORE....................................................................................................................... 96
7. SPECYFIKACJA PROBLEMU I CELE ANALIZY ............... .................................................... 99
8. ARCHITEKTURA ŚRODOWISKA BADAWCZEGO ............................................................. 103
9. IMPLEMENTACJA I ANALIZA MODELU STEROWANIA USŁUGAMI
ZAPROPONOWANEGO W IP MULTIMEDIA SUBSYSTEM .......... .................................. 107
9.1 OPIS ZAIMPLEMENTOWANYCH MECHANIZMÓW....................................................................... 108
9.2 PROCEDURA WSTAWIENIA INFORMACJI O IDENTYFIKACJI UśYTKOWNIKA (ASSERT IDENTITY) . 108
9.3 PROCEDURA PRZYDZIELENIA SERWERA S-CSCF PODCZAS PIERWSZEJ REJESTRACJI AGENTA
UśYTKOWNIKA (USER-REGISTRATION-QUERY) ........................................................................ 110
9.4 ZAIMPLEMENTOWANY PROCES REJESTRACJI UśYTKOWNIKA I REALIZACJA MOBILNO ŚCI W SIECI
................................................................................................................................................ 123
9.5 MODEL STEROWANIA USŁUGAMI Z WYKORZYSTANIEM FEDERACJI SERWERÓW APLIKACYJNYCH
................................................................................................................................................ 127
9.6 INTERAKCJE POMIĘDZY USŁUGAMI I SERWERAMI APLIKACYJNYMI ......................................... 133
10. ANALIZA I IMPLEMENTACJA INTERFEJSÓW PARLAY X W MODELU USŁUGOWYM
IMS................................................................................................................................................ 137
10.1 STEROWANIE ZESTAWIANIEM POŁĄCZEŃ PRZEZ TRZECIĄ STRONĘ (INTERFEJS THIRD PARTY CALL)
................................................................................................................................................ 138
10.2 OBSŁUGA POŁĄCZEŃ (INTERFEJS CALL HANDLING)................................................................ 152
10.3 INFORMACJA O STATUSIE TERMINALA (INTERFEJS TERMINAL STATUS)..................................... 160
10.4 ZARZĄDZANIE LISTĄ KONTAKTÓW (INTERFEJS ADDRESS LIST MANAGEMENT) ......................... 164
10.5 INFORMACJA O STATUSIE OBECNOŚCI (INTERFEJS PRESENCE) ................................................. 167
11. CENTRUM KOMUNIKACJI OSOBISTEJ ............................................................................... 174
11.1 ZAŁOśENIA PROJEKTOWE DLA APLIKACJI................................................................................ 174
11.2 ARCHITEKTURA APLIKACJI......................................................................................................175
11.3 PROCES TWORZENIA APLIKACJI Z WYKORZYSTANIEM PARLAY X ........................................... 178
11.4 KOMPONENTY APLIKACJI........................................................................................................ 179
11.5 OGRANICZENIA I PROPOZYCJE ICH ROZWIĄZANIA ................................................................... 186
12. PODSUMOWANIE ....................................................................................................................... 189
Spis Treści
8
13. BIBLIOGRAFIA............................................................................................................................ 194
14. WYKAZ STOSOWANYCH SKRÓTÓW ................................................................................... 198
ZAŁ ĄCZNIK A: DEFINICJE KRYTERIÓW FILTRACJI IFC W HSS, S TOSOWANE
PODCZAS ANALIZY................................................................................................................. 201
ZAŁ ĄCZNIK A: DEFINICJE KRYTERIÓW FILTRACJI IFC W HSS, S TOSOWANE
PODCZAS ANALIZY................................................................................................................. 201
ZAŁ ĄCZNIK B: INSTRUKCJA URUCHOMIENIA SERWERÓW CSCF I HS S........................ 204
ZAŁ ĄCZNIK C: INSTRUKCJA URUCHOMIENIA SERWERÓW IMPLEMENT UJĄCYCH
PARLAY X API........................................................................................................................... 206
ZAŁ ĄCZNIK C: INSTRUKCJA URUCHOMIENIA SERWERA OBECNO ŚCI ......................... 209
ZAŁ ĄCZNIK D: INSTRUKCJA INSTALACJI APLIKACJI CENTRUM KOMUNIKACJI
OSOBISTEJ.................................................................................................................................. 210
ZAŁ ĄCZNIK E: KONFIGURACJA I URUCHOMIENIE BRAMY MEDIALNE J...................... 212
1. Wstęp
Ewolucja sieci telekomunikacyjnej spowodowana jest koniecznością tworzenia nowych
usług i doskonalenia dotychczasowych. Aby to osiągnąć, stosuje się róŜne koncepcje i
rozwiązania. Sieć inteligentną (Intelligent Network) moŜna uznać za jedną z pierwszych
takich koncepcji. Architektura IN udostępniła funkcjonalność usługową sieci przez
rozdzielenie funkcji związanych ze sterowaniem połączeniami i zgłoszeniami (SSP) od
funkcji związanych z wykonywaniem usług o wartości dodanej (SCP). IN wprowadza model
sterowania scenariuszem usługi oraz środowisko kreacji. Istotną wartością dodaną, jaką
koncepcja sieci inteligentnej wniosła do świata telekomunikacyjnego, było dostrzeŜenie
potrzeby standaryzacji tam, gdzie dotychczas jej nie było, czyli w obszarze usług1. Pomimo
tych udoskonaleń, oferowane aplikacje były jedynie nowymi wariacjami tradycyjnej usługi
głosowej2, polegającymi głównie na odpowiednim sterowaniu jej scenariuszem.
Postrzeganie usług przez abonentów zmieniło się diametralnie w momencie pojawienia
się Internetu. Stał się on kopalnią nowych usług w wyniku odwrócenia paradygmatu
umiejscowienia „inteligencji” w sieci. Usługi stały się aplikacjami, a ich logika znajdowała
się na obrzeŜach - w terminalach uŜytkowników3, a Internet stanowił jedynie medium do
transmisji danych. W związku z tym wiele usług mogło być realizowanych z pominięciem
operatorów telekomunikacyjnych, a ich rola mogła zostać ograniczona głównie do
zapewnienia szerokopasmowego dostępu do sieci.
Szybki rozwój sieci pakietowych i coraz większa powszechność rozwiązań bazujących
na IP spowodowała powstanie wielu koncepcji łączących moŜliwości Internetu i
telekomunikacji. Początkowo były to proste próby przeniesienia usługi głosowej (tzw. Voice
Over IP), jednak w miarę rozwoju pakietowej transmisji danych, zaczęto pracować nad
zastąpieniem dotychczasowej architektury sieci telekomunikacyjnej przez architekturę opartą
1 Standaryzacji został poddany interfejs pomiędzy SSP a SCP. Środowisko uruchomieniowe i model programistyczny pozostały poza normalizacją, co spowodowało, Ŝe aplikacje realizujące usługi nie były przenośne pomiędzy rozwiązaniami róŜnych dostawców. Ze względu na to wprowadzenie IN doprowadziło do częściowego tylko otwarcia sieci na model realizacji usług przez „trzecią stronę”. 2 Oczywiście nie naleŜy zapominać, iŜ w tejŜe sieci oprócz usług głosowych moŜna było realizować usługę wideotelefonii. Jednak zainteresowanie tą usługą w śród uŜytkowników było marginalne. 3 W IN ma miejsce odwrotna sytuacja. Aplikacja realizująca usługę jest wykonywana po stronie sieci.
Wstęp
10
o protokół IP. Model NGN4 stał się urzeczywistnieniem tych prac i miał na celu opracowanie
uniwersalnej sieci usługowej pozwalającej zarówno na komunikację głosową, jak i transmisję
wideo oraz danych, z uwzględnieniem róŜnych wymagań jakościowych.
IP Multimedia Subsystem jest architekturą usługową, która stanowi rdzeniowy element
sieci NGN. IMS ma zapewnić neutralność dostępową (w załoŜeniu), ujednolicić sterowanie
zgłoszeniami oraz zdefinować styk z warstwą aplikacyjną, tworząc tym samym spójne
środowisko do kreacji usług konwergentnych5. To środowisko dostarcza narzędzi
pozwalających przyspieszyć proces budowy nowych usług oraz obniŜyć ich koszt6.
Protokołem wykorzystywanym w IMS jest rozszerzona wersja Session Initiation
Protocol. Cechy SIP umoŜliwi ą realizację złoŜonych usług konwergentnych, które w jednej
sesji komunikacyjnej mogą łączyć wideo, głos, przesyłanie danych (np., komunikaty
natychmiastowe) oraz uwzględniać informację o obecności7. Istotnym elementem środowiska
IMS są serwery aplikacyjne, w których następuje wykonywanie aplikacji realizujących usługi.
Wbrew pozorom, standard IMS pozostawia duŜą swobodę i elastyczność w ich tworzeniu,
poniewaŜ nie definiuje modelu komponentów aplikacyjnych ani środowiska wykonywania
usług. Takie podejście sprawia, Ŝe implementacja wymaga adaptacji odpowiednich technik
programistycznych (np. Web Services, Servlety, etc..). Informatyka od połowy lat 60 XX
wieku wpływa na kształt rozwiązań stosowanych w telekomunikacji (np. zastosowanie
sterowania programowego w centralach 1 ESS). W miarę rozwoju techniki i koncepcji w
informatyce konwergencja pomiędzy tymi dwoma dziedzinami staje się coraz głębsza.
Szczególnie chętnie adoptowane są powszechnie stosowane techniki (np. Java, Web
Services), które umoŜliwiają tworzenie usług szerszej grupie osób.
W warstwie aplikacji projektant moŜe korzystać z wielu rozwiązań, choćby takich jak:
SIP Servlet API, JAIN SIP API, JAIN SLEE, Parlay/OSA API, Parlay X. KaŜda z tych technik
ma cechy, które sprawiają, Ŝe kaŜda z tych aplikacji lepiej się sprawdza w określonym
zastosowaniu niŜ pozostałe. Przykładowo Parlay X moŜe być wykorzystany w sytuacji, gdy
operator chciałby udostępnić funkcjonalność sieci w bezpieczny sposób jak najszerszej grupie
4 Patrz rozdział 3. 5 Usług, w których przenikają się róŜne formy komunikacji, jak np. głos, wideo, wiadomości natychmiastowe, lub szeroko rozumiana obecność. 6 Ze względu na brak „dojrzałych” implementacji w komercyjnych sieciach, postulat dotyczący optymalizacji pod względem kosztu i czasu wdroŜenia usług nie został jeszcze w praktyce sprawdzony. 7 Z ang. Presence
Wstęp
11
potencjalnych twórców aplikacji. Jeśli natomiast pojawia się potrzeba udostępnienia bardziej
zaawansowanej8 funkcjonalności, ale wciąŜ dostępnej dla szerokiego kręgu dostawców,
najlepiej w tym przypadku jest zastosować Parlay/OSA API. Zakładając, Ŝe aplikacja ma
wykorzystywać niskopoziomową funkcjonalność sieci a jednocześnie charakteryzować się
wysoką wydajnością, naleŜałoby zastanowić się na uŜyciem do tego celu JAIN SIP.
Standard JAIN SLEE jest wynikiem dąŜenia do stworzenia jednolitego modelu
programistycznego oraz środowiska wykonawczego dla usług9. W architekturze JSLEE
aplikacja zbudowana jest z mniejszych komponentów (Service Building Block), których
moŜna ponownie uŜyć do budowy innych aplikacji. Jest to pewnego rodzaju rozszerzenie idei
Service Independent Block z IN10. Ponadto środowisko Java oraz zastosowana koncepcja
kontenera sprawia, Ŝe aplikacje wykazują pełną przenośność pomiędzy róŜnymi
implementacjami JSLEE11. Te dwa główne aspekty pozwalają urzeczywistnić głoszone
slogany marketingowe, takie jak optymalizacja „time-to-market” oraz usługa typu „off-the-
shelf”.
Podsumowując dokonania w dziedzinie telekomunikacji moŜna stwierdzić, Ŝe na dzień
dzisiejszy dysponujemy zestandaryzowanym pełnym modelem wykonywania i tworzenia
usług konwergentnych. W skład tego modelu wchodzi architektura IMS12, środowisko
wykonywania aplikacji JSLEE, narzędzia wspomagające tworzenie aplikacji tzw. IDE13 oraz
interfejs Parlay X eksponujący funkcje sieci na wysokim poziomie abstrakcji.
W niniejszej pracy zostało stworzone rzeczywiste środowisko składające się z wyŜej
wymienionych elementów. Doświadczenia związane z implementacją tego środowiska oraz
przykładowej usługi „Centrum Komunikacji Osobistej” stanowiły podstawę do szczegółowej
analizy moŜliwości i cech przyjętego modelu.
8 Wymagającej dostępu do sieci na niŜszym poziomie abstrakcji. 9 Analogicznie jak J2EE w rozwiązaniach IT. 10 JSLEE zostały zdefiniowane jedynie reguły, według których SBB mają być tworzone, dlatego teŜ zbiór SBB nie jest z góry narzucony. 11 Okazało się to niemoŜliwe w przypadku IN. 12 Implementacje pełnej architektury IMS w komercyjnych sieciach są bardzo nieliczne. 13 Integrated Development Environment.
Wstęp
12
Cele Pracy
� Analiza modelu sterowania usługami zaproponowanego w IMS. Określenie jak
mechanizmy protokołu SIP są wykorzystywane do budowy modelu usługowego,
jakie są korzyści i negatywne strony związane z jego zastosowaniem oraz jakie są
moŜliwości optymalizacji.
� Analiza dekompozycji warstwy aplikacyjnej IMS jako sposobu na optymalizacje
procesu tworzenia usług. Określenie jak wygląda model implementacji usług w
środowisku dwuwarstwowym (warstwa komponentów aplikacyjnych i warstwa
aplikacji) na przykładzie Parlay X i JSLEE. Jakie są korzyści i jakie ograniczenia
przy takim podejściu.
� Analiza implementacji usług w róŜnych modelach programistycznych. Określenie
jak róŜne modele programistyczne wpływają na proces tworzenia.
� Analiza moŜliwości wykorzystania rozwiązań „ open-source” w telekomunikacji.
Ocena jak oprogramowanie typu „open source” wpływa na rozwój współczesnej
telekomunikacji, jakie są kierunki zmian i potencjalne korzyści.
Układ pracy
Praca jest podzielona na dwie części. Pierwsza z nich obejmuje ogólną charakterystykę
wszystkich obszarów, które zostały poddane analizie tj. architektura IMS, protokół SIP,
koncepcja Parlay i Parlay X oraz architektura JAIN SLEE, która została omówiona bardziej
szczegółowo ze względu na niewielką liczbę, obecnie dostępnych opracowań tego
rozwiązania. Druga część jest poświęcona analizie realizacji usług w architekturze IMS.
Zawiera ona opis zaimplementowanego, środowiska modelującego system IMS, które było
podstawą do analizy zagadnień poruszanych w tej pracy.
Poszczególne rozdziały zostały opracowane przez dwóch autorów. Podział przedstawia się
następująco:
1. Wstęp Michał Misiak Część I 2. Session Initiation Protocol Michał Kościesza 3. IP Multimedia Subsystem Michał Kościesza 4. Parlay/OSA oraz Parlay X Michał Misiak 5. JAIN Service Logic Execution Environment Michał Misiak 6. Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych
6.1 Wstęp Michał Misiak
Wstęp
13
6.2 Linux w zastosowaniach telekomunikacyjnych Michał Misiak 6.3 Open Source JSLEE – Mobicents Michał Misiak 6.4 Open SIP Express Router Michał Kościesza 6.5 Asterisk Michał Misiak 6.6 Open IMS Core Michał Kościesza
Część II 7. Specyfikacja problemu i cele analizy Michał Kościesza 8. Architektura środowiska badawczego Michał Kościesza 9. Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
Michał Kościesza
10. Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
10.1 Sterowanie zestawianiem połączeń przez trzecią stronę (interfejs Third Party Call)
Michał Misiak
10.2 Obsługa połączeń (interfejs Call Handling) Michał Misiak 10.3 Informacja o statusie terminala (interfejs Terminal Status) Michał Misiak 10.4 Zarządzanie listą kontaktów (interfejs Address List Management)
Michał Kościesza
10.5 Informacja o statusie obecności (interfejs Presence) Michał Kościesza 11. Centrum Komunikacji Osobistej Michał Misiak 12. Podsumowanie Michał Kościesza
Michał Misiak
Podział związany z implementacją elementów środowiska badawczego:
Model sterowania usługami IMS (P-CSCF, S-CSCF, HSS) Michał Kościesza Serwery implementujące interfejsy Pralay X:
Third Party Call Michał Misiak Call Handling Michał Misiak Terminal Status Michał Misiak Address List Management Michał Kościesza Presence Michał Kościesza
Aplikacja „Centrum Komunikacji Osobistej” Michał Misiak
2. Session Initiation Protocol
2.1 Wstęp
SIP jest protokołem warstwy aplikacyjnej umoŜliwiającym sterowanie procesem
zestawiania, modyfikacji oraz rozłączania sesji multimedialnych14 [22]. SIP zapewnia takie
elementarne mechanizmy jak: lokalizacja terminala uŜytkownika15, określenie dostępności
uŜytkownika, negocjacja parametrów połączenia oraz zestawianie i zarządzanie sesją
multimedialną.
Pierwsza wersja protokołu została zaprojektowana przez Henninga Schulzrinne’a i
Marka Handlera w 1996. Najbardziej aktualną normą IETF definiującą bazowe mechanizmy
protokołu jest RFC 3261 [22]. W roku 2000, w ramach prac na standardem IMS, 3GPP
znacznie rozszerzyła funkcje SIP i włączyła go do grupu norm dla sieci UMTS.
Warto zaznaczyć, Ŝe SIP nie jest protokołem, który umoŜliwia realizację kompletnego
systemu komunikacyjnego, jest raczej składnikiem, który razem z innymi protokołami takimi
jak SDP (opis parametrów sesji) albo RTP (protokół transportu strumieni medialnych) moŜe
być wykorzystany do takich celów.
2.2 Budowa protokołu oraz model sesji
SIP jest protokołem tekstowym o składni zbliŜonej do HTTP. W warstwie
transportowej moŜe być przenoszony zarówno za pomocą protokołu UDP jak i TCP/TLS.
Podobnie jak HTTP, SIP jest oparty o model transakcyjny - „Ŝądanie/odpowiedź”. KaŜda
transakcja składa się z Ŝądania, które jest wywołaniem określonej metody na serwerze oraz z
przynajmniej jednej odpowiedzi. Wiadomości protokołu moŜna podzielić na Ŝądania i
odpowiedzi. Podstawowymi rodzajami Ŝądań są:
� INVITE – jest to pierwsza wiadomość rozpoczynająca proces inicjacji sesji.
� ACK – wysyłana jest w celu potwierdzenia zgody na przyjęcie sesji od wywoływanej
strony.
� BYE – powoduje zakończenie trwającej sesji.
14 sesja multimedialna moŜe być przekazem wideo, audio, komunikatów tekstowych itd.. 15 moŜliwość określenia adresu sieciowego terminala uŜytkownika.
Session Initiation Protocol
16
� CANCEL – kończy proces nawiązywania sesji.
� OPTIONS – umoŜliwia poznanie obsługiwanych mechanizmów terminala, do której jest
adresowana.
� REGISTER – umoŜliwia rejestrację lokalizacji sieciowej terminala uŜytkownika16.
Odpowiedzi moŜna pogrupować na serie określające klasę przenoszonych informacji
(podobnie jak w HTTP):
� 1xx (np. „180 Ringing”) – odpowiedzi informacyjne (wskazują na postęp w realizacji
zgłoszenia).
� 2xx (np. „200 OK”) – pozytywne potwierdzenia (wskazują na pomyślne zakończenie
transakcji).
� 3xx (np. „302 Moved Temporarily”) – przekierowania (wskazują na potrzebę
wykonania innych akcji w celu dokończenia realizacji zgłoszenia)
� 4xx (np. „404 Not Fund”) – błędy strony klienckiej (np. wiadomość jest niepoprawna,
albo niemoŜliwa do obsługi przez serwer)
� 5xx (np. „501 Not Implemented”) – błędy serwera
� 6xx (np. „604 Does Not Exist Anywhere”) – błędy ogólnego typu
Rys. 1 przedstawia przykład wiadomości SIP (Ŝądanie). Wiadomość złoŜona jest z tzw.
„pierwszej linii” określającej rodzaj i adres systemu, do którego jest kierowane zgłoszenie
(tzw. Request-URI albo R-URI) oraz z nagłówków określających róŜne parametry zgłoszenia.
Przykładowo nagłówki ‘Via’ wskazują na drogę w sieci tj., przez jakie elementy była
obsługiwana wiadomość, nagłówek ‘From’ określa, kto jest nadawcą a ‘Allow’ wskazuje,
jakie rodzaje wiadomości są obsługiwane przez inicjatora zgłoszenia.
16 Lokalizacja sieciowa to skojarzenie pomiędzy adresem IP a publicznym identyfikatorem uŜytkownika (np. sip:[email protected])
Session Initiation Protocol
17
Rys. 1: Przykładowa wiadomość INVITE protokołu SIP
Na Rys. 2 przedstawiono przykładowy scenariusz nawiązania sesji oraz jej zakończenia.
Rys. 2: Nawiązywanie i rozłączanie sesji
W architekturze protokołu moŜna wyróŜnić elementy pełniące określone funkcje, które
są realizowane przez systemy uczestniczące w procedurach wykorzystujących SIP. Te funkcje
to:
� Funkcja agenta uŜytkownika (User Agent, UA) – polega na moŜliwości inicjowania i
odbierania sesji. Zazwyczaj implementowana jest w terminalach uŜytkownika.
� Funkcja serwera pośredniczącego (Proxy) – polega na odbieraniu i podejmowaniu
decyzji związanych z właściwym kierowaniem wiadomości do agentów uŜytkownika
bądź innych serwerów Proxy.
� Funkcja serwera rejestru (Registrar) – polega na gromadzeniu i udostępnianiu
informacji o lokalizacji sieciowej tj. skojarzenia pomiędzy identyfikatorem
Session Initiation Protocol
18
uŜytkownika Sip-URI (np. sip:[email protected]) a adresem sieciowym terminala
danego uŜytkownika.
� Funkcja B2BUA (Back-To-Back User Agent) – jest to połączenie funkcji agenta
uŜytkownika z funkcją serwera pośredniczącego. Wiadomości, w których wymianie
pośredniczy serwer implementujący funkcje B2BUA, są widziane dla elementów
sieci SIP, tak jakby były zainicjowane właśnie z serwera B2BUA, a nie z
faktycznego agenta uŜytkownika, który jest inicjatorem sesji17.
System serwerów Proxy, Registrar i agentów uŜytkownika (UA) tworzy model sesji, który
jest określany jako „trapez SIP” (Rys. 3).
SIP
Rys. 3: Model sesji opartej o SIP ("trapez SIP")
UA nawiązują połączenie wykorzystując serwery Proxy, które dysponują informacją o
adresacji terminali (funkcja lokalizacji). Po nawiązaniu połączenia dalsza wymiana
wiadomości moŜe następować z pominięciem serwerów Proxy, poniewaŜ UA znają juŜ
nawzajem swoje adresy IP.
Uzgadnianie parametrów połączenia pomiędzy stronami odbywa się przy pomocy
protokołu SDP, który jest przenoszony wewnątrz wiadomości SIP. Ten mechanizm jest oparty
o model negocjacji zdefiniowany w [23].
Szczegółowa analiza mechanizmów protokołu SIP jest zawarta w [12].
17 Ten mechanizm jest zbliŜony do NAT w sieci TCP/IP, tylko jest przeprowadzany na warstwie protokołu SIP.
Session Initiation Protocol
19
2.3 Kierunki rozwoju i rola SIP w IMS
Protokół SIP zdefiniowany w [22] słuŜy do nawiązywania sesji multimedialnych w sieci
IP. Cechuje się on przejrzystością składni (jest tekstowy i przypomina HTTP) i stosunkowo
prostą budową (sześć podstawowych wiadomości: INVITE, ACK, CANCEL, BYE,
REGISTER, OPTIONS). Te cechy wpłynęły na to, Ŝe SIP jest najczęściej wybieranym
protokołem w implementowaniu systemów komunikacji multimedialnej w sieci Internet.
Warto zauwaŜyć, Ŝe właśnie zastosowanie SIP w Internecie jest wyróŜnione w specyfikacji
definiującej protokół.
Dzięki modularnej budowie i wbudowanych mechanizmach pozwalających na
rozszerzanie funkcji, powstało wiele inicjatyw, których celem było „wzbogacenie” bazowego
SIP o nowe mechanizmy na przykład takie jak realizacja usługi natychmiastowych
wiadomości (z ang. Instant Messaging, IM) albo publikacji statusu obecności uŜytkownika (z
ang. Instant Presence). Do maja 2007 roku opublikowano około 50 róŜnego rodzaju
rozszerzeń SIP względem bazowej normy, które otrzymały status norm IETF RFC18.
SIP został wybrany jako podstawowy protokół sterowania połączeniami i zgłoszeniami
w systemie IMS (opis w rozdziale 3.) dla sieci UMTS. Prace ETSI [17] i ITU [35]
wykorzystują IMS jako rdzeniową część w nowym modelu sieci telekomunikacyjnej - NGN.
W związku z tym, SIP został protokołem słuŜącym do sterowania połączeniami i
zgłoszeniami w projektowanej publicznej sieci telekomunikacyjnej następnej generacji. Do
zastosowań telekomunikacyjnych definicja protokołu zawarta w RFC 3261 nie jest
wystarczająca. Przykładowo brakuje w niej mechanizmów umoŜliwiających interakcje z
sieciami PSTN bez utraty określonych informacji o realizowanym połączeniu, mechanizmów
pozwalających na kontrolę przez operatora negocjowanych parametrów połączenia
potrzebnych do QoS oraz funkcji związanych z taryfikacją. Ze względu na to, standardy
3GPP wprowadzają szereg rozszerzeń i definiują, na potrzeby IMS, tzw. profil protokołu SIP
[7], który jest złoŜony z bazowego standardu [22] oraz listy rozszerzeń. Tak określony profil
stanowi minimalny zestaw mechanizmów, jakie są wymagane w odniesieniu do wszystkich
uczestników (terminali, elementów sieci) pracujących w środowisku systemu IMS.
Wymagane rozszerzenia SIP wprowadzone w IMS to:
18 Dane na podstawie IETF WG-SIP (http://www.ietf.org/html.charters/sip-charter.html).
Session Initiation Protocol
20
� Tel-URI (RFC 3966) – określa specjalny format adresu uŜywany w SIP dla
identyfikacji uŜytkowników sieci PSTN.
� wiadomość INFO (RFC 2976) – umoŜliwia przenoszenie sygnalizacji DTMF.
� wiadomość ‘183 Session Progress’ i PRACK (RFC 3262) – umoŜliwiają bardziej
szczegółową wymianę informacji dotyczącą procesu zestawiania sesji, co jest
wymagane w celu zachowania kompatybilności z siecią PSTN (współpraca SIP-
ISUP).
� rekordy NAPTR w systemie DNS dla protokołu SIP (RFC 3263) - system DNS jest
wykorzystywany do lokalizacji serwerów Proxy.
� wiadomości SUBSCRIBE i NOTIFY (RFC 3265) – wprowadzają mechanizm
umoŜliwiający elementom sieci SIP śledzenie roŜnego typu zdarzeń. Jest to
wykorzystywane między innymi w realizacji usługi obecności, w której terminal
subskrybuje status obecności innego uŜytkownika.
� wiadomość UPDATE (RFC 3311) – rolą tej wiadomości jest umoŜliwienie zmiany
wynegocjowanych parametrów połączenia przed faktycznym rozpoczęciem się sesji.
Bez wiadomości UPDATE zmiany takiego typu mogą odbywać się tylko po
rozpoczęciu sesji (poprzez mechanizm re-INVITE [22]).
� nagłówek P-Media-Authorization (RFC 3313) – przenosi informacje dotyczącą
uwierzytelnionych parametrów połączenia. Jest to potrzebne w realizacji przez sieć
mechanizmów związanych z QoS. W IMS, kaŜda sesja jest kontrolowana przez
element P-CSCF, którego zadaniem jest sprawdzanie czy negocjowane przez
uŜytkowników parametry połączenia (w tym parametry QoS) są moŜliwe do
zagwarantowania.
� kompresja SIP (RFC 3320) – w celu optymalizacji wykorzystania zasobów na łączu
radiowym w IMS stosuje się kompresję.
� nagłówek Privacy (RFC 3323) – umoŜliwia określanie poziomów prywatności dla
sesji. Ma to wpływ między innymi na taki aspekt jak prezentacja numeru.
� nagłówki P-Asserted-Identity i P-Preferred-Identity (RFC 3325) – te dodatkowe
nagłówki przenoszą informacje dotyczącą strony inicjującej połączenie. Zgodnie [22]
taka informacja zawarta jest w nagłówku From, ale ze względu na wymogi związane
z taryfikacją (From jest formowane przez terminal uŜytkownika) w IMS stosuje się
Session Initiation Protocol
21
dodatkową informację, która jest wstawiana do wiadomości przez elementy systemu
IMS.
� nagłówek Reason (RFC 3326) – przenosi dodatkowe informacje dotyczące przyczyny
określonych zdarzeń w sieci. Wymagany jest w celu zachowania kompatybilności
IMS z siecią PSTN.
� nagłówek Path (RFC 3327) – umoŜliwia kierowanie wiadomości do uŜytkownika w
sytuacji, w której pomiędzy serwerem rejestrującym (Registrar), a terminalem
uŜytkownika jest serwer Proxy.
� nagłówki “P-Headers” (RFC 3455) – są to dodatkowe nagłówki takie jak: P-
Associated-URI, P-Called-Party-ID, P-Visited-Network-ID, P-Access-Network-Info,
P-Charging-Function-Addresses, P-Charging-Vector. Przenoszą informacje
związane z siecią dostępową i informacje potrzebne do taryfikacji.
� wiadomość REFER (RFC 3515) – wspomaga realizacje takich usług jak przekazanie
połączenia (call transfer) i konferencja.
� nagłówek Service Route (RFC 3608) – umoŜliwia poprawne kierowanie wiadomości
pomiędzy serwerami IMS a terminalami uŜytkowników.
� subskrypcja stanu rejestracji (RFC 3680) – umoŜliwia terminalowi uŜytkownika
pobieranie informacji o stanie rejestracji róŜnych identyfikatorów Sip-URI, którymi
dysponuje. Odbywa się to za pomocą wiadomości SUBSCRIBE i NOTIFY.
Większość powyŜej opisanych rozszerzeń powstała w wyniku prac 3GPP i ma
praktyczne zastosowanie jedynie w systemie IMS. Niektóre dodane mechanizmy mają
charakter bardzo szczegółowy i są wynikiem dostosowania protokołu SIP, który pierwotnie
był projektowany dla sieci Internet, do wymogów stawianych sieci telekomunikacyjnej.
Session Initiation Protocol
22
A
INVITE
200 OK
ACK
B
180 Ringing
transmisja mediów
180 Trying
A
INVITE
200 OK
ACK
B
180 Ringing
transmisja mediów
180 Trying
183 Session Progress
PRACK
200 OK
UPDATE
200 OK
PRACK
200 OK
SIP zgodny z RFC 3261 SIP zgodny z IMS
Rys. 4: Scenariusze nawiązania sesji: SIP podstawowy i SIP IMS19 (na podstawie [6])
Jedną z podkreślanych cech protokołu SIP jest jego prostota20. Aby umoŜliwi ć
świadczenie usług telekomunikacyjnych, 3GPP wprowadziło szereg rozszerzeń, które
mają zastosowanie w systemie IMS. SIP zgodny z IMS cechuje się dwukrotnie większą
ilością wiadomości, kilkunastoma dodatkowymi nagłówkami i specyficznymi, względem
standardu pierwotnego, mechanizmami. Rys. 4 przedstawia scenariusz nawiązania sesji
wykorzystujący podstawową wersję protokołu SIP oraz wersję zgodną z IMS. Aby
nawiązać połączenie VoIP w sieci Internet (SIP zgodny z RFC 3261) wystarczy wymiana
5 wiadomości sygnalizacyjnych, a w IMS niezbędne jest uŜycie 12 wiadomości.
19 Serwery pośredniczące zostały pominięte. 20 SIP rozumiany jako protokół zdefiniowany w RFC 3261, bez rozszerzeń.
3. IP Multimedia Subsystem
3.1 Wstęp
IP Multimedia Subsystem (IMS) po raz pierwszy pojawia się w piątej wersji norm
3GPP definiujących UMTS (3GPP UMTS Release 5) [3], gdzie stanowi dodatkowy
komponent (podsystem) w architekturze sieci. Główną jego funkcja jest prawie wyłącznie
realizacja dodatkowych usług multimedialnych w dziedzinie pakietowej (np. Video-sharing,
Push-To-Talk21). Wraz z rozwojem koncepcji Sieci Następnej Generacji (Next Generation
Network, NGN), IMS staje się (3GPP Release 6) kluczowym systemem rdzeniowej części
UMTS, realizującym zarówno klasyczne usługi telefoniczne jak i nowe, tzw. usługi
konwergentne, które łączą moŜliwości sieci pakietowych i sieci z komutacją łączy. IMS
umoŜliwia tworzenie róŜnorodnych usług wykorzystujących: multimedia (w tym tradycyjne
połączenie głosowe), transmisje danych oraz szeroko rozumiany kontekst komunikacji.
Wszystkie te składowe mogą się wzajemnie „przenikać” w budowanych scenariuszach
usługowych.
Aktualne prace standaryzacyjne nad 3GPP Release 7 i 8 są wykorzystywane przez ETSI
i ITU do stworzenia architektury sieci NGN, czyli sieci pakietowej, zdolnej do świadczenia
usług telekomunikacyjnych, która jest niezaleŜna od rodzaju techniki dostępowej [33]. ETSI
rozszerza funkcje IMS o konwergencje z sieciami stacjonarnymi i w ten sposób IMS staje się
systemem, który stanowi rdzeń w nowej uniwersalnej, publicznej sieci telekomunikacyjnej.
Integrująca i unifikująca rola IMS jest wielopłaszczyznowa, dotyka warstwy
dostępowej, sterowania połączeniami i warstwy aplikacyjnej, czyli miejsca realizacji usług.
Usługi o wartości dodanej22 są postrzegane jako waŜny wyróŜnik atrakcyjności sieci
telekomunikacyjnej, aby sprostać temu wymaganiu, niezbędna jest zmiana paradygmatu
wprowadzania nowych aplikacji. IMS zawiera w sobie mechanizmy, których celem jest
umoŜliwienie budowy aplikacji o bogatej funkcjonalności oraz optymalizacja tego procesu
zarówno pod względem kosztowym jak i czasowym.
21 Usługa „Push-to-Talk” zdefiniowana jest w ‘OMA, Push to talk Over Cellular v1.0’ (http://www.openmobilealliance.org/) 22 Usługi o wartości dodanej są to usługi, których funkcje wykraczają poza podstawową funkcje sieci, jaką jest zestawienie połączenia pomiędzy dwoma uŜytkownikami.
IP Multimedia Subsystem
24
3.2 IMS jako rdzeniowa część architektury NGN
Terminem „Sieć Następnej Generacji” określa się architekturę sieci opartą o komutacje
pakietów, zdolną do realizacji usług telekomunikacyjnych wykorzystujących róŜne
przepływności dostarczane przez róŜne techniki dostępowe. Zgodnie z [33] najwaŜniejszymi
cechami sieci w architekturze NGN są:
� komutacja pakietów;
� separacja funkcji sterowania połączeniami i zgłoszeniami od funkcji transportowych i
funkcji związanych z usługami;
� otwarte interfejsy;
� zdolność do realizacji szerokiego zakresu usług;
� szerokopasmowa transmisja z zaimplementowanymi mechanizmami QoS;
� współpraca z sieciami tradycyjnymi (z siecią PSTN);
� konwergencja pomiędzy usługami sieci stacjonarnej i mobilnej;
� niezaleŜność usług od technik dostępowych;
� otwartość dla róŜnych technik realizacji dostępu.
Rys. 5: Referencyjna funkcjonalna architektura NGN (źródło [17])
Zgodnie z referencyjną funkcjonalną architekturą ETSI (patrz Rys. 5) sieć NGN moŜna
podzielić na:
IP Multimedia Subsystem
25
� warstwę funkcji transportowych (Transfer Functions) – grupuje wszystkie
mechanizmy odpowiedzialne za udostępnienie łącza danych, które często nazywane
jest określeniem IP-CAN (IP Connectivity Access Network). Realizacja łącza IP moŜe
odbywać się za pomocą dowolnych technik dostępowych.
� podsystem sterowania zasobami i dostępem (Resorce and Admission Control
Subsystem, RACS) – steruje przyznawaniem zasobów dla konkretnego ruchu
generowanego przez uŜytkownika. Systemy z wyŜszych warstw (np. Core-IMS)
instruują ten podsystem do stosowania odpowiednich polityk kontroli dostępu i QoS.
� podsystem powiązania sieciowego (Network Attachment Subsystem, NAS) – jego
głównym zadaniem jest uwierzytelnienie uŜytkownika w warstwie transportowej (np.
PPP) oraz przyznanie adresacji IP.
� podsystem emulacji PSTN/ISDN (PSTN/ISDN Emulation subsystem) – pozwala na
obsługę sieci dostępowych opartych o komutacje łączy. Głównym zadaniem tego
podsystemu jest emulacja PSTN/ISDN w sieci pakietowej.
� podsystem IMS (Core IMS23) – jest odpowiedzialny za sterowanie połączeniami i
zgłoszeniami.
� warstwę aplikacji (Applications) – zawiera funkcje realizujące usługi.
Sieć UMTS24 jest zgodna z modelem NGN ogólnie zdefiniowanym w [17] i [33]. Rys. 6
pokazuje architekturę UMTS, która jest połączeniem tradycyjnej sieci z komutacją łączy oraz
sieci pakietowej. Część pakietowa UMTS razem z podsystemem IMS tworzy pełną sieć w
modelu NGN.
23 W architekturze ETSI-NGN podsystem IMS nosi nazwę „Core IMS”. Jest spowodowane tym, Ŝe zgodnie z definicją 3GPP, IMS zawiera elementy realizujące sterowanie połączeniami i zgłoszeniami oraz warstwę serwerów aplikacyjnych, a definicja ETSI zawęŜa rolę IMS tylko do sterowania połączeniami i zgłoszeniami. 24 Dokładnie sieć UMTS w architekturze, co najmniej 3GPP Release 5.
IP Multimedia Subsystem
26
Rys. 6: Dualna architektura sieci UMTS (źródło [3])
Jedną z waŜnych cech IMS, która zadecydowała o wykorzystaniu go w NGN, jest
niezaleŜność warstwy usługowej od techniki dostępowej. KaŜdy terminal, który jest zdolny do
nawiązania łączności IP z elementami IMS, moŜe korzystać z funkcji usługowych sieci
telekomunikacyjnej, poniewaŜ wszystkie mechanizmy niezbędne do obsługi zgłoszeń są
niezaleŜne od technik dostępowych. Przykładem tej neutralności dostępowej jest identyfikacja
uŜytkownika, która w IMS odbywa się przy pomocy adresacji protokołu SIP, tzw. SIP-uri,
który jest niezaleŜny od adresacji IP przyznawanej w podsystemach NAS, specyficznych dla
danej sieci dostępowej. Podobnie jest w przypadku procedury uwierzytelnienia uŜytkownika,
która moŜe być przeprowadzana w kaŜdej sieci dostępowej w specyficzny sposób, ale zawsze
terminal uŜytkownika po uzyskaniu łączności IP z IMS jest poddawany powtórnemu
uwierzytelnieniu poprzez protokół SIP.
IP Multimedia Subsystem
27
Rys. 7: Model uniwersalnej sieci NGN
Rys. 7 pokazuje model sieci NGN, w której IMS jest niezaleŜny od róŜnych technik
dostępowych.
3.3 Architektura IMS
IMS jest rdzeniowym elementem sieci NGN realizującym funkcje zwiane ze
sterowaniem połączeniami i zgłoszeniami. W tym rozdziale zostanie omówiona architektura
IMS zgodna ze specyfikacjami 3GPP25, które określają funkcje IMS szerzej tj. oprócz funkcji
sterowania połączeniami i zgłoszeniami, wyróŜniają takŜe funkcje związane z aplikacjami
realizującymi usługi i funkcje bram medialnych.
25 Dokładnie z wersją 6 tj. 3GPP Release 6.
IP Multimedia Subsystem
28
Rys. 8: Architektura IMS
Elementy funkcjonalne systemu IMS oraz protokoły stosowane na interfejsach są
pokazane na Rys. 8. Jak moŜna zauwaŜyć, wykorzystywane są cztery protokoły
sygnalizacyjne: SIP do sterowania połączeniami i zgłoszeniami, H.248/MEGACO jako
protokół słuŜący do sterowania bramami medialnymi, DIAMETER wykorzystywany do
autoryzacji zgłoszeń oraz parametrów QoS oraz SCTP, który stanowi protokół transportowy
do wyŜszych warstw stosu SS7 po sieci IP.
W architekturze funkcjonalnej IMS (Rys. 8) moŜna wyróŜnić 3 warstwy:
� warstwa urządzeń końcowych i bram – obejmuje elementy odpowiedzialne za
obsługę ruchu uŜytkowego. NaleŜą do niej takie elementy jak: bramy medialne (IM-
MGW), serwery zajmujące się generowaniem treści (MRFP) oraz urządzenia
końcowe odpowiedzialne za odbiór i nadawanie ruchu uŜytkowego.
� warstwa sterowania połączeniami i zgłoszeniami – obejmuje wszystkie elementy
odpowiedzialne za sterowanie połączeniami i zgłoszeniami. NaleŜą do niej elementy
takie jak: S-CSCF, I-CSCF, P-CSCF, HSS, SLF, BGCF, MGCF, MRFC, PDF,
SGW.
IP Multimedia Subsystem
29
� warstwa aplikacyjna – jest złoŜona z serwerów aplikacyjnych (AS) realizujących
scenariusze usług
Element funkcjonalne architektury IMS to:
� Serving-Call/Session Control Function (S-CSCF)
Jest właściwym elementem systemu IMS odpowiedzialny za odpowiednie kierowanie
zgłoszeń (w postaci wiadomości SIP). NajwaŜniejsze funkcje S-CSCF to: sterowanie
sesją multimedialną, uwierzytelnienie uŜytkownika i sterowanie połączeniami.
Dla kaŜdego zgłoszenia analizowanego w S-CSCF wybierany jest właściwy sposób
obsługi tj:
a. zgłoszenie moŜe być skierowane do terminala innego uŜytkownika;
b. zgłoszenie moŜe być skierowane do serwera I-CSCF jeśli odbiorca jest
obsługiwany w obcej sieci;
c. zgłoszenie moŜe być skierowane do serwera aplikacyjnego jeśli profil
uŜytkownika wskazuje na potrzebę realizacji usług.
Rys. 9 pokazuje przykładowy scenariusz obsługi w S-CSCF. Na podstawie
profilu uŜytkownika A, zgłoszenie zostaje skierowane do serwera aplikacyjnego (AS1)
a następnie do innego (AS2). Po zakończeniu obsługi związanej z usługami,
zgłoszenie jest kierowane do uŜytkownika B.
2. INVITE B
3. IN
VITE B
4. INVITE B
5. IN
VITE B
Rys. 9: Analiza profilu w S-CSCF
Z punktu widzenia modelu protokołu SIP, S-CSCF pełni funkcję serwera SIP-proxy i
serwera Registrar.
IP Multimedia Subsystem
30
� Home Subscriber Server (HSS)
Element HSS pełni funkcję uniwersalnego repozytorium danych skojarzonych z
uŜytkownikiem. Dane te są to zarówno informacje potrzebne do spersonalizowanej
realizacji usług w serwerach aplikacyjnych, jak i informacje niezbędne do realizacji
podstawowych funkcji związanych ze sterowaniem połączeniami i zgłoszeniami bądź
zarządzaniem mobilnością. HSS uczestniczy takŜe w procedurach uwierzytelnienia
uŜytkownika (udostępnia wektory kryptograficzne) oraz przechowuje reguły obsługi
zgłoszeń w określonych serwerach aplikacyjnych (tzw. reguły filtracji IFC).
Wx
Applications
D C Gr Gc Sh Rp Cx Si
gsmSCF
HSS
Mobility Management Identification handling
User security info. generation Service authorization support
User security support Access authorization
Service Provisioning support Application Services Support
Call / Session establishment support CAMEL Services Support
GUP Data Repository
CS Domain PS Domain IM CN subsystem
GUP Server
SGSN GGSN GMSC MSC / VLR CSCF IM-SSF
SIP Application Server
OSA SCS
3GPP AAA Server
Rys. 10: Logiczna architektura HSS (źródło [3])
HSS jest uniwersalnym repozytorium, oznacza to, Ŝe gromadzi dane wykorzystywane
przez wszystkie elementy sieci komórkowej (nie tylko IMS). Rys. 10 pokazuje
wszystkie logiczne funkcje i interfejsy HSS.
� Subscriber Location Function (SLF)
Rola SLF w sieci IMS polega na informowaniu, w którym HSS znajduje się profil
uŜytkownika. Funkcja SLF jest implementowana w sytuacji, kiedy w sieci znajduję się
kilka serwerów HSS.
� Proxy-Call/Session Control Function (P-CSCF)
Jest to serwer SIP-proxy, który pośredniczy pomiędzy terminalem uŜytkownika a S-
CSCF. Jego główną funkcją jest kontrola dostępu, kontrola sesji w kontekście
parametrów QoS oraz kompresja/dekompresja protokołu SIP.
IP Multimedia Subsystem
31
Rys. 11: Rola P-CSCF
Rys. 11 pokazuje rolę P-CSCF we współpracy z PDF i GGSN. Wiadomości
inicjujące sesje są analizowane w P-CSCF i na ich podstawie P-CSCF razem z PDF
„otwiera” moŜliwość transmisji ruchu uŜytkowego w GGSN oraz rezerwuje niezbędne
zasoby zgodnie z profilem QoS26.
� Policy Decision Function (PDF)
Funkcja ta jest opowiedzialna za zcentralizowaną kontrolę wykorzystania i rezerwacji
zasobów transmisyjnych. PDF otrzymuje od P-CSCF Ŝądane przez uŜytkowników
parametry QoS dla danej sesji na podstawie, których podejmuje decyzje o zezwoleniu
na połączenie. Funkcje PDF jest szczegółowo opisane w specyfikacji 3GPP TS 29.207
(Policy control over Go interface).
� Interrogating-Call/Session Control Function (I-CSCF)
Pośredniczy w wymianie sygnalizacji (SIP) pomiędzy S-CSCF, a innymi sieciami
(implementuje funkcje ukrywania topologii sieci). I-CSCF uczestniczy takŜe w
procedurze rejestracji uŜytkownika, co jest szczegółowo opisane w rozdziale 9.3. Z
punktu widzenia modelu protokołu SIP, I-CSCF jest serwerem SIP-proxy oraz
implementuje funkcje B2BUA.
� Breakout Gateway Control Function (BGCF)
26 Sposób definicji Ŝądanych parametrów QoS za pomocą protokołu SIP/SDP definiuje RFC3312.
IP Multimedia Subsystem
32
Bierze udział w zestawianiu połączenia, które ma się zakończyć w sieci PSTN.
Główną funkcją BGCF jest określenie odpowiedniego serwera MGCF (w przypadku,
gdy w sieci jest wiele serwerów MGCF) i przekazanie do niego zgłoszenia.
� Media Gateway Control Function, Media Gateway (MGCF, IM-MGW)
Brama medialna i kontroler bramy medialnej łączą sieć IMS z siecią PSTN. MGCF
odpowiedzialny jest za konwersje sygnalizacji pomiędzy SIP a ISUP (albo Q.931 w
przypadku ISDN) oraz odpowiednie wysterowanie MGW, który odpowiedzialny jest
za konwersję ruchu uŜytkowego pomiędzy łączami komutowanymi a strumieniami
RTP27.
� Signalling Gateway (SGW)
Odpowiedzialny jest za przeniesienie protokołów wyŜszych warstw SS7 (np. ISUP) do
sieci IP za pomocą protokołu SCTP28.
� Multimedia Resource Function Controller, Multimedia Resource Function
Processor (MRFC, MRFC)
MRFC i MRFP są elementami realizującymi funkcje tzw. serwera mediów. Główną
ich rolą jest udostępnianie i przetwarzanie treści multimedialnych. MRFC odpowiada
za sygnalizacje, a MRFP za ruch uŜytkowy (strumienie medialne)29. Przykładem
wykorzystania tych elementów moŜe być implementacja mostka konferencyjnego,
albo serwera poczty głosowej.
� Application Server (AS)
Serwer aplikacyjny jest miejscem implementacji usług w sieci IMS. AS uczestniczy w
realizacji połączeń w na kilka sposobów, tj. moŜe:
a. odbierać i przetwarzać zgłoszenia (sekwencje wiadomości protokołu SIP) z S-
CSCF, które wymagają obsługi związanej z usługami (rola 3 z Rys. 12);
b. przyjmować połączenia (rola 1 z Rys. 12);
c. inicjować połączenia (rola 2 z Rys. 12);
27 RTP jest protokołem transportowym strumieni medialnych w sieci IP (RFC 3550). 28 Protokół SCTP zdefiniowany jest w RFC 2960. 29 MRFC i MRFP są jednymi z najmniej dokładnie zdefiniowanymi elementami IMS.
IP Multimedia Subsystem
33
d. realizować zestawienie połączenia w modelu trzeciej strony tzw. 3rd-Party-
Call-Control (rola 4 z Rys. 12).
S-CSCF
ApplicationServer
SIP leg #1
SIP leg #1
From: XTo: YCall-ID: Z
From: XTo: YCall-ID: Z
S-CSCF
ApplicationServer
SIP leg #1
SIP leg #1
From: XTo: YCall-ID: Z
From: XTo: YCall-ID: Z
S-CSCF
ApplicationServer
SIP leg #1
SIP leg #1
From: XTo: YCall-ID: Z
From: XTo: YCall-ID: Z
SIP leg #1From: XTo: YCall-ID: Z
SIP leg #1
From: XTo: YCall-ID: Z
S-CSCF
ApplicationServer
SIP leg #2
SIP leg #2
From: PTo: QCall-ID: R
From: PTo: QCall-ID: R
SIP leg #1From: XTo: YCall-ID: Z
SIP leg #1
From: XTo: YCall-ID: Z
Rys. 12: Role jakie moŜe przyjmować serwer aplikacyjny w obsłudze połączeń (źródło [4])
Z punktu widzenia modelu protokołu SIP, serwer aplikacyjny implementuje funkcje
SIP-proxy, UA oraz B2BUA.
3.4 Profil uŜytkownika
HSS przechowuje i udostępnia profile uŜytkowników, które zawierają dane
wykorzystywane przez elementy IMS do świadczenia usług. Profil moŜe być pobierany z
HSS przez serwery aplikacyjne, które przechowują w nim informacje potrzebne do
personalizacji wykonywanych usług albo przez S-CSCF w celu realizacji procedur
związanych ze sterowaniem usługami. KaŜdy profil składa się z informacji, która opisuje, w
jakich sytuacjach i na jakie serwery aplikacyjne maja być kierowane zgłoszenia trafiające do
S-CSCF. Stanowi to podstawę modelu sterowania usługami opisanego w rozdziale 3.5.
IP Multimedia Subsystem
34
Struktura profilu jest definiowana przy pomocy języka UML30. Rys. 13 przedstawia
budowę profilu abonenta w HSS.
Rys. 13: Struktura profilu w HSS
W skład profilu uŜytkownika wchodzą takie informacje jak:
� ‘Public Identification’ - jest to grupa publicznych identyfikatorów, którymi posługuje
się uŜytkownik. Dany profil jest stosowany tylko, jeśli abonent posługuje się
identyfikatorem wymienionym w tej grupie.
30 Unified Modeling Language (http://www.ogm.org/uml).
IP Multimedia Subsystem
35
� ‘Core Network Service Authorization’ - są to informacje uwierzytelniające.
� ‘Initial Filter Criteria’ - zawiera kryteria filtracji wiadomości na określony serwer
aplikacyjny (szczegółowo jest to omówione poniŜej).
� ‘Shared iFC Set’ - jest to wskazanie na kryteria filtracji współdzielone przez róŜnych
uŜytkowników.
Dla modelu sterowania usługami istotnym elementem profilu są kryteria filtracji (Initial
Filter Criteria, IFC), które są analizowane w S-CSCF, gdy przychodzi wiadomość
sygnalizacyjna SIP. Na podstawie tych danych, zostaje podjęta decyzja czy wiadomość
(zgłoszenie) ma być skierowana na właściwy serwer aplikacyjny. MoŜliwości analizy
wiadomości SIP są bardzo szerokie. Definicja IFC składa się z wyraŜenia przedstawiającego
sumę lub negacje logiczną, warunków dotyczących części składowych wiadomości. Analizie
mogą podlegać wszystkie nagłówki i pole SDP31, do którego takŜe mogą być stosowane
wyraŜenia regularne32 (szerzej jest to omówione w rozdziale 1).
Profil uŜytkownika jest przesyłany w postaci dokumentu XML o określonej składni.
Definicja składni jest specyfikowana przy pomocy specjalnego XML-Schema33. Szczegółowy
opis budowy profilu zawarty jest w [9].
3.5 Model sterowania usługami
W IMS miejsce realizacji usługi o wartości dodanej jest precyzyjnie zdefiniowane i tym
miejscem jest serwer aplikacyjny. Takie rozgraniczenie wprowadza klarowny podział
pomiędzy elementarnymi funkcjami (np. zapewnienie przezroczystego kanału danych,
zarządzanie mobilnością itd.) a cała gamą dodanych funkcjonalności.
Podstawowymi elementami biorącymi udział w sterowaniu usługami IMS są: serwery
aplikacyjne (AS), element zarządzający sterowaniem połączeniami i zgłoszeniami (S-CSCF)
oraz repozytorium profili uŜytkownika (HSS). Rys. 14 przedstawia interfejsy i protokoły
31 Protokół słuŜący do opisu parametrów sesji. 32 MoŜliwości tworzenia kryteriów są elastyczne, przykładowo moŜna zdefiniować taką regułę:
(Method=”INVITE” OR Method = ”MESSAGE” OR Method=”SUBSCRIBE”) AND (Method=”INVITE” OR Method = ”MESSAGE” OR (NOT Header = ”from” Content =”[email protected]”)).
PowyŜsze wyraŜenie opisuje regułę definiującą, Ŝe kierowane do AS będą wiadomości: INVITE, MESSAGE oraz takie wiadomości SUBSCRIBE, które nie zostały wysłane przez uŜytkownika posługującego się publicznym identyfikatorem [email protected]. 33 XML-Schema jest językiem opisu składni dokumentów XML (patrz http://www.w3.org/XML/Schema).
IP Multimedia Subsystem
36
pomiędzy tymi elementami. Interakcja S-CSCF z AS odbywa się za pomocą protokołu SIP,
który zarazem jest podstawowym protokołem słuŜącym do realizacji sterowania zgłoszeniami
w sieci.
Rys. 14: Elementy architektury IMS biorące udział w sterowaniu usługami
Sterowanie usługami polega na odpowiednim przekazywaniu obsługi zgłoszeń do
serwerów aplikacyjnych. KaŜdy uŜytkownik IMS jest obsługiwany przez wyróŜniony serwer
S-CSCF, który podczas procedury rejestracji pobiera profil uŜytkownika z HSS. Profil
zawiera tzw. filtry IFC, które definiują warunki kierowania zgłoszenia do odpowiedniego AS.
Procedury sterowania usługami moŜna podzielić na 3 klasy:
� Procedury związane z obsługą zgłoszeń przychodzących dla zarejestrowanego
uŜytkownika – analizowany jest profil wywoływanego uŜytkownika;
� Procedury związane z obsługą zgłoszeń przychodzących dla nie zarejestrowanego
uŜytkownika – z HSS pobierany jest profil wywoływanego uŜytkownika, który nie
jest w danej chwili zarejestrowany w S-CSCF (jest poza siecią IMS);
� Procedury związane z obsługą zgłoszeń wychodzących – analizowany jest profil
uŜytkownika, który inicjuje zgłoszenie.
Obsługa kaŜdego zgłoszenia związana ze sterowaniem usługami w S-CSCF jest podzielona na
2 fazy:
1. decyzja, do której klasy naleŜy zgłoszenie (przychodzące, przychodzące do
niezarejestrowanego uŜytkownika, wychodzące);
2. analiza filtrów IFC i wybór serwera aplikacyjnego, do którego ma być skierowane
zgłoszenie.
IP Multimedia Subsystem
37
Rys. 15 ilustruje przykładowy scenariusz realizacji zgłoszenia, w którym jest
wykorzystywany mechanizm sterowania usługami.
2. 3. 5.
6.
7.
Rys. 15: Mechanizm sterowania usługami - przykładowy scenariusz
Przebiega on w sposób następujący:
1. UŜytkownik ‘ala’ wywołuje uŜytkownika ‘ula’.
2. Zgłoszenie trafia do S-CSCF, który analizuje profil ‘ala’ (procedura dla połączeń
wychodzących) i zgodnie z nim, wykonuje przekierowanie zgłoszenia do AS1 (który
moŜe przykładowo realizować usługę blokowania połączeń wychodzących gdy
uŜytkownik jest poza określoną lokalizacją).
3. AS1 wykonuje swoja logikę i zwraca obsługę zgłoszenia do S-CSCF.
4. S-CSCF pobiera profil uŜytkownika ‘ula’ (procedura dla połączeń przychodzących do
nie zarejestrowanego uŜytkownika).
5. S-CSCF zgodnie z pobranym profilem kieruje zgłoszenie do AS2. (który przykładowo
realizuje usługę „przekierowania”).
6. AS2 modyfikuje zgłoszenie, zamieniając adres odbiorcy na adres wskazujący na
uŜytkownika ‘ela’. Zgłoszenie kierowane jest do S-CSCF.
7. S-CSCF zgodnie z adresem odbiorcy zgłoszenia, kieruje je do uŜytkownika ‘ela’.
IP Multimedia Subsystem
38
3.6 Proces nawiązywania sesji
Na Rys. 16 przedstawiono dwa scenariusze pokazujące proces nawiązywania sesji, tj.
sesji pomiędzy uŜytkownikami IMS oraz sesji pomiędzy uŜytkownikiem IMS, a
uŜytkownikiem sieci PSTN.
1. 6.
2.
3. 4
.5.
1.
2.
3. 4
.
7.
Rys. 16: Nawiązywanie sesji w IMS
W przypadku scenariusza pierwszego, uŜytkownik inicjuje zgłoszenie, które jest obsługiwane
w S-CSCF (1, 2). Jeśli profil uŜytkownika wymaga obsługi związanej z usługami to
zgłoszenie kierowane jest do odpowiedniego serwera aplikacyjnego (3, 4), a następnie do
wywoływanego uŜytkownika B (5, 6). W przypadku scenariusza, w którym uŜytkownik B jest
obsługiwany przez sieć PSTN, S-CSCF kieruje zgłoszenie do serwera BGCF (5), który
określa właściwy MGCF przyłączony do sieci PSTN (6). MGCF dokonuje translacji
sygnalizacji SIP na ISUP (7) oraz steruje MGW tak, aby strumienie RTP od uŜytkownika A
zostały zamienione na połączenie w sieci z komutacją łączy.
3.7 Kierunki rozwoju
Architektura IMS powstała w wyniku prac 3GPP związanych z rozwojem sieci
mobilnej UMTS, a następnie została zaadaptowana przez ETSI [17] oraz ITU [35] na
potrzeby uniwersalnej architektury sieci NGN. Pewnego rodzaju paradoksem jest to, Ŝe
obecne implementacje IMS w przewaŜającej większości mają miejsce w sieciach
stacjonarnych pomimo, Ŝe IMS pierwotnie został zaprojektowany dla sieci komórkowej.
IP Multimedia Subsystem
39
Główną przyczyną tego są ograniczenia związane z siecią dostępową opartą o IP (IP-CAN).
Operatorzy stacjonarni do budowania rozwiązań, NGN wykorzystują szerokopasmowy dostęp
DSL albo infrastrukturę sieci kablowej (sieć HFC). Te techniki umoŜliwiają osiąganie
przepływności i parametrów jakościowych umoŜliwiających realizacje usług głosowych
(VoIP). W przypadku sieci mobilnych, dostęp realizowany jest przy pomocy sieci radiowej,
która na dzień dzisiejszy w rzeczywistych implementacjach nie umoŜliwia realizacji usług
głosowych opartych o VoIP z wystarczającą jakością34. To ograniczenie jest główną
przyczyną braku implementacji IMS w sieciach mobilnych oraz jest przyczyną prac
związanych z rozwojem IMS, głównie skupionych właśnie na próbie rozwiązania tego
problemu.
W wersji (3GPP Release) 7 i 8 standaryzacji 3GPP dla sieci UMTS, rozwaŜane są
rozwiązania, których celem jest umoŜliwienie wykorzystania sieci z komutacją łączy do
świadczenia usług opartych o IMS. Jako przykład kierunku tych prac opisane zostaną dwa
rozwiązania określane jako VCC (Voice Call Continuity) oraz IMS centralized services.
VCC jest rozszerzeniem architektury IMS o elementy umoŜliwiające przeniesienie
(handover) pomiędzy sesją realizowaną poprzez IMS (opartą o VoIP), a połączeniem
wykorzystującym komutacje łączy. Głównym celem wprowadzenia tego typu funkcji do sieci
jest rozwiązanie problemu polegającego na braku ciągłego pokrycia geograficznego siecią
radiową zdolną do świadczenia usług głosowych na bazie VoIP. Rys. 17 pokazuje scenariusz
przełączenia pomiędzy sesją IP, a połączeniem w sieci GSM.
34 Przykładowo techniki takie jak HSDPA i HSUPA w sieci UMTS umoŜliwiają realizacje VoIP, lecz obecny zasięg pokrycia geograficznego UMTS jest niewystarczający do zapewnienia usługi w warunkach mobilności uŜytkownika.
IP Multimedia Subsystem
40
Rys. 17: Przekazywanie (Handover) pomiędzy IMS a siecią GSM
Przykładowo uŜytkownik „A” (Rys. 17) jest w zasięgu sieci umoŜliwiającej szerokopasmowy
dostęp IP (np. HSPA35). „A” korzysta z IMS do połączenia z uŜytkownikiem „B” (sieć GSM).
Gdy uŜytkownik „A” opuszcza obszar zasięgu szerokopasmowego, jego terminal inicjuje
połączenie GSM, które jest kierowane do aplikacji VCC (serwer aplikacyjny) w IMS, a ruch
uŜytkowy jest „zakotwiczany” w MGW. VCC instruuje MGCF, aby skojarzył dwie „odnogi”
tego połączenia, co powoduje, Ŝe dalsza realizacja odbywa się juŜ w całości w sieci GSM.
Szczegółowo działanie VCC opisane jest w [5].
IMS centralized services jest próbą ujednolicenia implementacji usług. Zgodnie z
architekturą IMS release 5 i 6, usługi na serwerach aplikacyjnych mogą być świadczone tylko
dla uŜytkowników sieci pakietowej. Ze względu na ograniczenia związane z brakiem
mobilnej sieci pakietowej o wystarczających parametrach jakościowych, udostępnienie
35 HSDPA i HSUPA.
IP Multimedia Subsystem
41
usługi, która ma być dostępna dla wszystkich uŜytkowników, wymaga implementacji
zarówno na bazie IMS, jak i z wykorzystaniem metod na potrzeby sieci z komutacją łączy
(np. IN). IMS centralized services zakłada, Ŝe kaŜdy uŜytkownik (sieci z komutacją łączy)
będzie utrzymywał kanał danych o niskiej przepływności wykorzystywany do wymiany
sygnalizacji z IMS36, który między innymi jest wykorzystywany do rejestracji. KaŜde
połączenie inicjowane do uŜytkownika będzie kierowane do IMS (poprzez MGCF i MGW),
gdzie zostaną wykonane procedury związane z realizacją usług (na serwerach aplikacyjnych),
a następnie połączenie zostanie „zawrócone” z powrotem do sieci z komutacją łączy (patrz
Rys. 18)
Rys. 18: Połączenie pomiędzy uŜytkownikami sieci GSM z obsługą usług w IMS
Prace nad IMS centralized services [1] są na wczesnym etapie i mają jeszcze charakter
koncepcyjny.
36 RozwaŜany jest GPRS (dla sieci 2.5G) albo USSD (dla 2G).
4. Parlay/OSA oraz Parlay X
4.1 Geneza Parlay/OSA
W roku 1984 British Telecom (BT) został podzielony na dwie niezaleŜne spółki na
mocy decyzji wydanej przez OFTEL37. Decyzja ta była ściśle związana z sytuacją na rynku
telekomunikacyjnym w Wielkiej Brytanii – wchodził on właśnie w fazę liberalizacji. Jedna z
tych firm miała zajmować się usługami transportowymi w sieci, druga dostarczaniem usług
dla klienta końcowego. Potrzebne, więc były narzędzia za pomocą, których spółka zajmująca
się transportem w sieci mogłaby udostępniać funkcjonalność tejŜe sieci na rzecz tej drugiej
spółki, a takŜe na rzecz innych potencjalnych usługodawców. Pięć firm (m.in. Siemens, BT,
Nortel, Ulticom i Microsoft) podjęło się wyzwania stworzenia jednolitej architektury do
budowy usług. W tym celu została powołana inicjatywa Parlay.
Inicjatywa Parlay bazowała na wcześniejszych, podobnych doświadczeniach
przedsięwzięć chcących stworzyć otwarte środowisko do kreacji usług (np. TINA38).
Ostatecznie inicjatywy te kończyły się poraŜką (oczywiście z tego grona naleŜy wyłączyć
koncepcję sieci inteligentnej) ze względu na poniŜej wymienione problemy:
� Brak szerokiej współpracy pomiędzy operatorami, dostawcami sprzętu, treści usług,
integratorami;
� Oferowane wsparcie jedynie dla jednego typu sieci/terminala;
� Zbyt duŜa złoŜoność, aby mógł zostać zaadoptowany i wykorzystywany przez trzecią
stronę. Usługi mogła tworzyć jedynie wąska grupa specjalistów;
� Brak bezpieczeństwa i ochrony zasobów operatora, który je udostępnia;
� Brak moŜliwości prostej integracji z istniejącymi systemami rozliczeniowymi
operatorów;
� ZaleŜność od techniki sieciowej oraz jej implementacji.
37 Regulator rynku elektronicznego w Wielkiej Brytanii, odpowiednik polskiego Urzędu Komunikacji Elektronicznej. 38 Telecommunication Information Networking Architecture. TINA była jedną z pierwszych prób zdefiniowania architektury, która integrowała funkcje sterowania i zarządzania w jedną logiczną całość, a usługi miały być tworzone z wykorzystaniem standardowych języków programowania. Szczegóły dotyczące tej inicjatywy dostępne są pod adresem http://www.tinac.com/ [58].
Parlay/OSA oraz Parlay X
43
Parlay Group w wymaganiach uwzględniło wyŜej wymienione aspekty, a przy procesie
opracowywania specyfikacji skupiło szeroką grupę przedstawicieli operatorów, dostawców
usług, sprzętu, treści. Efektem prac Parlay Group39 była specyfikacja interfejsów
Parlay/OSA40.
4.2 Opis Parlay/OSA
Norma Parlay/OSA definiuje architekturę, która umoŜliwia twórcom usług i aplikacji
dostęp do zasobów i funkcjonalności sieci telekomunikacyjnej operatora poprzez
zestandaryzowany interfejs programistyczny tzw. API (Application Programming Interface).
Parlay/OSA API przedstawia abstrakcję dla zbioru protokołów. Abstrakcja ta przykrywa
niskopoziomową funkcjonalność protokołów, co w efekcie niesie za sobą dwie zasadnicze
konsekwencje. Z jednej strony podejście takie ułatwia tworzenie usług/aplikacji41, gdyŜ
operujemy na uogólnionym zbiorze funkcji, który jest wspólny dla grupy protokołów.
Ujednolicenie heterogenicznego środowiska (sieć IN, sieć IP) wspiera takŜe pisanie aplikacji
konwergentnych. Z drugiej jednak strony ogranicza wykorzystanie zawansowanej
funkcjonalności dostępnej jedynie z poziomu protokołu i czasami wyłącznie dla danego
protokołu.
Sposób myślenia związany z prezentacją moŜliwości i funkcjonalności sieci po przez
API jest znany doskonale programistom. Programista kojarzy zestawienie połączenia w
TCP/IP z wywołaniem funkcji bind() , connect() , send() , etc.., a nie z wymianą
wiadomości. Jeśli by chciał natomiast zestawić połączenie w sieci SIP napisałby
39 Parlay Group zostało załoŜone na bazie inicjatywy Parlay w roku 1998 i aktualnie zrzesza 75 firm m.in. operatorów, dostawców usług, sprzętu i treści. Do projektu dołączyły ETSI i 3GPP. W tym samym roku opublikowali pierwszą specyfikację Parlay API. W wyniku zainteresowania, jakie standard wzbudził wśród operatorów podczas testowych wdroŜeń oraz powstałych na tej bazie wniosków Parlay Group wydało w 2003 roku wersję 4.1 interfejsów Parlay API. 40 Istnienie dwóch nazw: Parlay i OSA (Open Services Architecture) ma podłoŜe historyczne. Parlay odwołuje się do standardów tworzony przez Parlay Group, natomiast OSA odwołuje się do prac na standardami prowadzonymi przez 3GPP (Third Generation Partner Ship Project). Efekty prac obu ciał miały te same cele, tak więc postanowiono połączyć siły grup Parlay Group, ETSI i 3GPP. 41 Stworzenie usługi w środowisku IN wymaga duŜej wiedzy, co znacząco zawęŜa grupę potencjalnych twórców usług. W [50] oszacowano, Ŝe grupa potencjalnych twórców usług dla IN obejmuje ok. 10000 osób, natomiast liczba potencjalnych programistów potrafiących napisać usługę w oparciu o Parlay/OSA zwiększa się do 250 000. Wynika to z faktu, iŜ w przypadku podejścia Parlay/OSA, które wykorzystuje standardowe języki programowania np. Java, C napisanie usługi sprowadza się do stworzenia aplikacji, której złoŜoność nie jest większa niŜ np.: złoŜoność aplikacji wykorzystującej standardowe API dla berkley-owskich gniazd sieciowych (socket API). Natomiast budowa usługi IN wymaga precyzyjnej znajomości protokołów oraz ich implementacji.
Parlay/OSA oraz Parlay X
44
najprawdopodobniej makeCall(adres_a, adres_b) . Propagowanie opisanego modelu
programistycznego zwiększa rzeszę potencjalnych twórców usług telekomunikacyjnych.
Funkcjonalność oferowana przez zbiór Parlay/OSA API jest róŜnorodna i w gruncie
rzeczy pozwala zaspokoić oczekiwania twórców usług, gdyŜ spełnia większość wymagań
stawianych aplikacjom SIP/IMS. Przykładowo API do sterowania sesją obejmuje m.in.
generyczne sterowanie zgłoszeniami (Generic Call Control), wielostronne sterowanie
połączeniami (Multi-Party Call Control), sterowanie mediami podczas połączenia oraz
połączeniami konferencyjnymi (Multi-Media Call Control and Conference Call Control).
Szczegółowy wykaz funkcjonalności wszystkich API moŜna znaleźć w rodzinie specyfikacji
w [16].
4.3 Architektura Parlay/OSA
Architektura Parlay składa się z elementów:
� Aplikacja - wykorzystuje interfejsy usług udostępnianych przez Operatora Sieci.
Aplikacje mogą być równieŜ tworzone przez trzecią stronę i rozmieszczone w jej
domenie.
� Szkielet (Framework) - jest rdzeniem architektury Parlay/OSA. Udostępnia funkcje
zabezpieczające dostęp do interfejsów usług i chroni sieć operatora przed
naduŜyciami. Framework wspiera:
� identyfikację aplikacji (Authentication);
� odkrywanie nowych interfejsów (Discovery);
� informowanie o zdarzeniach (Event Notification);
� zarządzania integralnością API (Integrity Management);
� dodawanie nowych interfejsów w API (Registration);
� zarządzanie kontraktami (Contract Management);
� zarządzanie cyklem Ŝycia usług (Service Life Cycle Manager);
� Usługi (Services) - składają się z pojedynczych Interfejsów Usług (Service Interface) i
Obiektu Usługi (Service Object) tj. jej implementacji. Interfejsy Usług dają dostęp do
funkcjonalności sieci, którą Operator Sieci chce eksponować po przez Parlay/OSA.
Usługi są implementowane i dostępne po przez Obiekty Usług, które są logicznym
Parlay/OSA oraz Parlay X
45
elementem implementującym jedną lub więcej Interfejsów Usług. Obiekty Usług
oddziałują z elementami sieci.
� Zasobów (Resources) - reprezentują zasoby sieciowe, funkcjonalność innych urządzeń
w sieci dostępnych za pomocą Obiektów Usług. Przykładami są routery, systemy
bilingowe, serwer obecności, itp..
Zasoby sieciowe eksponowane są po przez Bramę Parlay/OSA, która mapuje je do
Parlay/OSA API z wykorzystaniem techniki CORBA42. Interfejs programistyczny
udostępniany przez Bramę składa się z interfejsu Parlay Framework oraz jednego lub więcej
Service Capability Server (SCS). KaŜdy serwer moŜe obejmować jedną lub więcej Service
Capability Features (SCF), natomiast za kaŜdym SCS znajdują się określone zasoby, które
udostępnia implementacja konkretnej Usługi. Struktura architektury Parlay/OSA została
przedstawiona na Rys. 19.
Rys. 19: Ogólna architektura Parlay/OSA
42 Common Object Request Broker Architecture – technika, która zapewnia komunikacje pomiędzy elementami heterogenicznego środowiska komputerowego (patrz [56]).
Parlay/OSA oraz Parlay X
46
4.4 Ograniczenia Parlay/OSA
Technika Parlay/OSA ma pewne ograniczenia związane z realizacją wymagania
dotyczącego moŜliwości swobodnego tworzenia aplikacji przez ISV (Independent Software
Vendor). Oto one:
� komunikacja pomiędzy serwerem aplikacyjnym, a Bramą Parlay/OSA nie jest w Ŝaden
sposób zabezpieczona;
� uŜyta technika CORBA uniemoŜliwia komunikację pomiędzy elementami Bramy
poprzez urządzenia takie jak NAT (Network Address Translation), czy firewall, które
są stałym elementem sieci operatorów i dostawców usług. Zatem aplikacje stworzone
z wykorzystaniem Parlay/OSA API mogą znajdować się jedynie w sieci, w której jest
Brama.
� ostatecznie doświadczenia operatorów, którzy wdroŜyli Parlay/OSA wskazują, Ŝe
interfejsy pomimo znacznego uproszczenia nadal wymagają od ISV duŜej wiedzy w
zakresie telekomunikacji m.in. znajomości architektury i działania sieci
telekomunikacyjnej.
Ograniczenia te sprawiają, Ŝe Parlay/OSA wdraŜane jest jako model tzw. „walled
garden43” . Przejście do modeli np. „Enterprise Integration”, czy „Open Network”44, które
pozwalają Operatorom otworzyć szerzej ich sieci moŜliwe jest w momencie rozwiązania
wymienionych problemów, a techniką, która moŜe temu stawić czoła jest Parlay X.
4.5 Parlay X (Parlay Web Services)
Parlay X jest kolejną techniką, która wspiera idee otwarcia sieci telekomunikacyjnych.
Specyfikacja została stworzona przez konsorcjum, które wcześniej przygotowało koncepcję i
definicję Parlay/OSA. Głównym celem, jaki został postawiony projektantom Parlay X było
stworzenie takiego interfejsu, który będzie bardzo łatwy w uŜyciu. W związku z tym
zrezygnowano z wykorzystania funkcji typu call back45 oraz z sesji.
43 Model „walled garden” (stworzony przez Parlay Group) - opisuje kolejny krok związany z otwarciem sieci operatora. W tym modelu usługi tworzone są juŜ przez ISV, ale zarządzane i utrzymywane w środowisku operatora. 44 Opis tych modeli znajduje się w [50]. 45 Funkcje typu call back – wywołania zwrotne – działają odwrotnie to zwykłych funkcji. Funkcje te rejestruje się, a ich wywołaniem zajmuje się odpowiednia biblioteka. Jako argument funkcja tego typu otrzymuje kod, który powinien zostać wykonany.
Parlay/OSA oraz Parlay X
47
Parlay X uogólnia funkcjonalność dostarczaną przez Parlay/OSA API poprzez
wykorzystanie interfejsów Web Services46. Natomiast Web Services otwiera alternatywny
sposób tworzenia i rozmieszczania usług. Cechą charakterystyczną Web Services jest:
� łatwa integracja – w przeciwieństwie do technik takich jak CORBA, Remote Method
Invocation (RMI), które posiadają stosunkowo złoŜone modele programistyczne oraz
pewne ograniczenia (CORBA, patrz rozdział 4.4) związane z wykorzystaniem poza
siecią macierzystą;
� redukcja kosztów dzięki wykorzystaniu istniejącej infrastruktury dla aplikacji
bazujących na protokole HTTP. Aplikacje mogą być tworzone z wykorzystaniem
dowolnego języka programowania (np. Java, C#, etc..), który wspiera Web Services;
� moŜliwość wykorzystania posiadanych juŜ umiejętności oraz narzędzi (np. Borland
JBuilder, Visual Studio .Net, SunONE Studio) uŜywanych przy tworzeniu aplikacji
bazujących na usługach sieciowych. Jest to równieŜ potencjalna okazja dla ISV,
aŜeby wejść na rynek aplikacji telekomunikacyjnych oraz rozszerzyć funkcjonalność
juŜ istniejących swoich produktów/usług.
Oczywiście Parlay X uwzględnia równieŜ szereg wymagań postawionych przed
Parlay/OSA, a m.in. aspekty dotyczące bezpieczeństwa (np. autoryzację, identyfikację
aplikacji), moŜliwość zagwarantowania SLA, moŜliwość rozliczenia, etc..
4.6 Modele biznesowe
Jedną z głównych przyczyn powstania Parlay X były oczywiście kwestie biznesowe.
Wykorzystanie Web Services rozszerza modele biznesowe wypracowane dla Parlay/OSA.
Modele te zapewniają zwiększenie przychodów oraz redukcję kosztów zarówno dla
operatorów jak i równieŜ ISV. Zwiększenie przychodów moŜe zostać osiągnięte w wyniku
oferowania istniejących usług, poprzez nowopowstałe kanały oraz poprzez pojawienie się
nowych ciekawszych usług. Nowe usługi mają szanse stać się bardziej atrakcyjne, poniewaŜ
proces realizacji usługi jest mniej skomplikowany, a większa rzesza osób potrafiących
tworzyć usługi, to potencjalnie więcej pomysłów znacznie lepiej odzwierciedlających
oczekiwania zróŜnicowanej grupy uŜytkowników. Natomiast redukcja kosztów wynika z
46 Web Services – (dalej nazywane równieŜ usługami sieciowymi) jest to komponent programistyczny, który implementuje pewną funkcjonalność. Funkcjonalność ta jest prezentowana i dostępna za pomocą interfejsu Web Services. Szczegółowo architektura zostanie przedstawiona w trakcie omawiania architektury Parlay X.
Parlay/OSA oraz Parlay X
48
wcześniej wspomnianego aspektu uproszczenia procesu tworzenia oraz skrócenia łańcucha jej
dostarczenia do uŜytkownika końcowego (np.: twórca usługi moŜe być bezpośrednio jej
dostawcą, uproszczenie integracji systemów etc..).
W [44] zostały szczegółowo przedstawione i omówione trzy przykładowe modele
biznesowe:
� współpraca pomiędzy operatorami (cross network access) polegająca na wzajemnym
wykorzystaniu zasobów lub odsprzedawaniu zasobów wirtualnym operatorom
mobilnym (Moblie Vritual Network Operator);
� współpraca pomiędzy ISV produkującymi nowe usługi i dostawcami usług mająca na
celu odkrycie rynków niszowych i dostarczenie na nie odpowiednich produktów;
� wykorzystanie interfejsów Parlay X do rozszerzenia funkcjonalności aplikacji typu
enterprise np.: systemów ERP, CRM o moŜliwości oferowane przez sieci
telekomunikacyjne. Procesem rozbudowy aplikacji moŜe zająć się dział IT, który nie
koniecznie musi mieć specjalistów telekomunikacji. Poza tym wykorzystanie Web
Services w aplikacjach enterprise jest naturalnym sposobem ich rozbudowy, gdyŜ
przedsiębiorstwa nie chcą uniezaleŜniać się od konkretnej techniki, czy dostawcy
rozwiązań IT.
4.7 Funkcjonalność Parlay X API
Parlay X w wersji 2 oferuje zestaw 14 interfejsów (Tab. 1), które moŜna podzielić na
następujące kategorie:
� interfejsy związane z abstrakcją zgłoszeń (call related);
� interfejsy do mechanizmów rozliczania (charging);
� interfejsy związane z funkcjonalnością urządzeń końcowych (terminal related)
� kategoria dla interfejsów usług, które nie mieszczą się w powyŜszych kategoriach.
Parlay/OSA oraz Parlay X
49
Tab. 1 Zestawienie interfejsów Parlay X z podziałem na kategorie.
Kategoria Nr. Usługa Opis
Ogólne 1 Ogólne definicje typów danych
Definiuje podstawowe typy danych XML, przestrzenie nazw, typy błędów oraz załoŜenia do opis interfejsów przy pomocy WSDL.
2 Third Party Call Zestawianie i zarządzanie połączeniami stworzonymi przez aplikację. Interfejs ten pozwala na zestawienie połączenia pomiędzy dwoma stronami.
3 Call Notification Pozwala określić, w jaki sposób zgłoszenie zainicjowane z sieci powinno być traktowane. UmoŜliwia prostą obsługę połączeń.
10 Call Handling Pozwala sterować przebiegiem zgłoszenia i realizować takie usługi jak: akceptacja, blokowanie, przekierowanie zgłoszenia, odgrywanie przekazów audio.
11 Audio Call Interfejs ten pozwala na odgrywanie zapowiedzi. Jest to prosty interfejs niewymagający od programisty tworzenia połączenia, ani jego modyfikacji w celu odegrania wiadomości.
Call Related
12 Multimedia Conference
Interfejs ten umoŜliwia kreację połączeń telekonferencyjnych i dynamiczne zarządzanie uczestnikami telekonferencji oraz rodzajem mediów.
4 SMS Pozwala na obsługę wiadomości SMS m.in. wysyłanie, odbieranie tekstu, dzwonków, prostej grafiki, ustawiania powiadomień o przyjściu SMS, etc..
Messaging
5 MMS Posiada podobną funkcjonalność jak interfejs powyŜej z tym, Ŝe obsługuje EMS, MMS, IM, e-mail, etc..
6 Payment Pozwalaja definiować róŜnego rodzaju płatności dla treści w otwartym środowisku sieciowy, np. płatności pre-paid, post-paid, etc..
Charging
7 Account management
Funkcjonalność doładowywania kont sprawdzania ich dla uŜytkowników pre-paid.
8 Terminal status Za pomocą tej usługi moŜna uzyskać status terminala, grupy terminali oraz powiadomienia o zmianie statusu terminala.
9 Terminal location
Dostęp do informacji o lokalizacji (wysokość, długość oraz szerokość geograficzna) danego terminala, grupy terminali. Usługa ta pozwala ustawić powiadomienia o zmianie lokalizacji.
Terminal Related
14 Presence Usługa ta pozawala na uzyskanie informacji o obecności uŜytkownika oraz na zarządzanie nią.
Parlay/OSA oraz Parlay X
50
Rother 13 Address List Management
Interfejs umoŜliwia zarządzanie grupami kontaktów (odpytywanie, usuwanie, modyfikacja).
Wybrane do implementacji interfejsy zostały omówione szczegółowo w rozdziale 1.
Rys. 69 prezentuje zaimplementowane w ramach środowiska badawczego interfejsy Parlay X.
4.8 Architektura Parlay X
Logika
usługi
Usługa Sieciowa
Framework
Interfejs
Aplikacyjny
Parlay X
Brama Parlay Web Services
Rejestr Usług Siecowych
Definicja Usługi SieciowejDefinicja Usługi SieciowejDefinicja Usługi Sieciowej
Serwer Aplikacyjny Parlay
Definicja Usługi SieciowejDefinicja Usługi Sieciowej
Aplikacje Parlay
Web Services ProviderWeb Services Requestor
Web Services Broker
ZNAJDŹ REJESTRUJ
PRZYWIĄś
WSDL
SOAP
KOMUNIKACJA
WSDL
UDDI
Rys. 20 Architektura Web Services z naniesioną terminologią Parlay X
Standardowa architektura Web Services z naniesionymi terminami Parlay X została
przedstawiona na Rys. 20. Rozpoczynając omawianie architektury Parlay X na samym
początku zostanie podana definicja zasadniczego pojęcia usługi sieciowej.
Web Service (usługa sieciowa) – jest to interfejs, który opisuje zbiór operacji/funkcji
dostępnych w sieci takiej jak np. Internet po przez zdefiniowany mechanizm wymiany
wiadomości wykorzystujący protokół SOAP47 (Simple Object Application Protocol).
Wywołanie funkcji danego interfejsu tzw. Ŝądanie usługi (service request) powoduje
47 Simple Object Access Protocol (SOAP) – jest standardem opartym o język XML słuŜącym do wymiany informacji pomiędzy aplikacjami w rozproszonym środowisku. Aktualnie SOAP jest przenoszony na protokole HTTP i wykorzystywanym do wykonywania usług sieciowych. Inne sposoby transportu są równieŜ moŜliwe np. SMTP. Specyfikacja znajduje się w [47].
Parlay/OSA oraz Parlay X
51
wykonanie tej funkcji na zdalnym systemie, hostującym Ŝądaną usługę. Usługa sieciowa
opisana jest przy uŜyciu języka WSDL48 (Web Service Description Language).
Architektura Web Services opisuje interakcje pomiędzy trzema aktorami (patrz Rys.
20): Web Service Provider, Web Service Requestor i Web Service Broker. Interakcja
pomiędzy tymi elementami obejmuje: operacje rejestracji usługi (publish), operacje
wyszukania usługi (find), przywiązania (bind) oraz późniejsze zdalne wywoływanie funkcji
usługi sieciowej.
W typowym scenariuszu, Web Service Provider przechowuje dostępny w sieci
komponent programistyczny, który zawiera implementację konkretnej usługi sieciowej.
Usługa sieciowa powinna zostać opisana przez Web Service Provider’a za pomocą języka
WSDL i zarejestrowana u Web Service Broker’a. Web Service Requester musi wyszukać
opublikowaną wcześniej usługę sieciową (find). MoŜe tego dokonać korzystając ze specjalnie
stworzonej do tego usługi sieciowej UDDI49 (Universal Description, Discovery and
Integration). Po znalezieniu usługi musi pobrać jej opis i przywiązać do interfejsu usługi
(bind). Warto wspomnieć, Ŝe opis usługi moŜe zostać pobrany niezaleŜnie od UDDI w postaci
pliku XML z WSDL.
PoniŜej zostały role w architekturze Web Services:
� Web Service Provider. Patrząc z punktu widzenia modelu biznesowego jest to
właściciel usługi sieciowej. Z punktu widzenia architektury Web Sercvices zajmuje
się on przechowywaniem implementacji usługi na serwerze. Określa równieŜ zasady
dostępu do usługi.
48 Web Service Description Language (WSDL) – jest językiem opartym o XML stworzonym do opisywania usług sieciowych. Zawiera informacje na temat, w jaki sposób komunikować się z usługą. Specyfikacja znajduje się w [48]. 49 Universal Description, Discovery and Integration (UDDI) jest niezaleŜną platformą, która udostępnia bazujący na XML rejestr, w którym umieszczane są opisy usług dostępne poprzez sieć Internet. UDDI jest otwartą inicjatywą sponsorowaną przez OASIS. UDDI jest zorganizowany podobnie jak ksiąŜka telefoniczna, a informacja, ktrórą przechowuje obejmuje:
� Białe strony – adresy, kontakty i elementy identyfikujące;
� śółte strony – podział usług według branŜy;
� Zielone strony – informacja techniczna, co zrobić, aby z danej usługi skorzystać.
UDDI naleŜy do specyfikacji Web Services. MoŜna wyróŜnić:
� węzły UDDI (UDDI Nodes) – są to serwery wspierające specyfikację UDDI i przynaleŜące do określonego rejestru UDDI;
� Rejestry UDDI (UDDI Registry) – jest to jeden lub więcej węzłów UDDI.
Parlay/OSA oraz Parlay X
52
� Web Service Requestor. Z biznesowego punktu widzenia jest to jednostka, która Ŝąda
określonej funkcjonalności. Natomiast z punktu widzenia architektury jest to
aplikacja kliencka, która wyszukuje, inicjuje i wywołuje Ŝądaną usługę sieciową
udostępnianą przez Web Service Provider’a. Oczywiście w roli Web Service
Requestor’a moŜe być inna usługa sieciowa, która wykorzystuje daną
funkcjonalność.
� Web Service Broker (Registry) zajmuje się zarządzaniem informacją o Web Service
Provider’ach i oferowanych przez nich usługach sieciowych. Informacje te mają
podobną strukturę jak ksiąŜki telefoniczne i obejmują:
o Dane biznesowe takie jak: nazwa, opis i informacje kontaktowe. Są to tzw.
„białe strony” .
o Dane opisujące politykę bezpieczeństwa, procesy biznesowe, sposób
korzystania z usługi. Jednym słowem dane, które opisują, w jaki sposób uŜyć
usługę. Analogicznie do ksiąŜek telefonicznych są to tzw. „zielone strony”.
Web Service Broker moŜe klasyfikować usługi pod kątem funkcjonalności
będą to tzw. „zielone strony”, oferować specjalny mechanizm do ich
przeszukiwania oraz ich sprzedaŜy (np. UDDI). Z punktu widzenia architektury
jest to rejestr, który przechowuje opisy usług publikowane przez Web Service
Provider’a. Opisy usług mogą zostać pobrane z alternatywnych źródeł jak np.
strona WWW w postaci pliku XML, jeśli znamy bezpośrednio ich dostawcę,
dlatego teŜ Web Service Broker jest opcjonalnym element architektury Web
Services.
PoniŜej zdefiniowano zbiór akcji, który moŜe być wykonywany przez lub na rolach
architektury Web Services.
� Publish. Akcja wykonywana przez Web Service Provider’a, polegająca na
zarejestrowaniu opisu usługi, w celu późniejszego odszukania jej przez Web Service
Requestor’a. Po przygotowaniu opisu usługi w WSDL-u budowany jest tzw. tModel,
który jest jednoznacznym identyfikatorem danej usługi sieciowej. tModel moŜe być
traktowany w kategorii przestrzeni nazw uŜywanej w innych tModel-ach. Proces
rejestracji przebiega w trzech krokach:
o publikacja informacji o dostawcy usługi - stworzenie „białej strony” ;
Parlay/OSA oraz Parlay X
53
o publikowanie usługi – stworzenie „ Ŝółtej strony”, zadecydowanie do jakiej
kategorii powinna przynaleŜeć usługa;
o publikowanie informacji na temat dostępu do usługi – opis funkcjonalności
oferowanej przez usługi i technicznej informacji na temat komunikacji z
usługą.
� WyróŜnia się dwa rodzaje sposobów, na jakie usługa moŜe zostać
opublikowana:
o bezpośrednia publikacja (direct publication) – najprostszy mechanizm
publikacji. Opis usługi sieciowej jest udostępniany przez Web Service
Provider’a bezpośrednio (np. za pomocą e-mail, na stronie www, itp.) w
postaci pliku XML.
o Dynamiczna publikacja (dynamic publication) – opis usługi sieciowej zostaje
umieszczony w repozytorium, którym moŜe być np. prywatny lub publiczny
serwer UDDI.
� Find. Operacja ta wykonywana jest przez Web Service Requestor’a. Pobiera on opis
usługi bezpośrednio lub odpytuje Web Service Broker’a o Ŝądaną usługę. Informacja
o usłudze moŜe zostać pobrana w dwóch róŜnych cyklach działania Web Service
Requestor’a:
o W trakcie projektowania (at design time) – opis interfejsów usługi pobierany
jest w momencie tworzenia aplikacji.
o W trakcie działania (at runtime) – aplikacja wyszukuje Ŝądaną usługę i łączy
się z nią w trakcie jej wykonywania.
� Bind. Operacja wykonywana przez aplikację Web Service Requestor’a podczas jej
działania. Aplikacja inicjuje komunikacje z usługą sieciowa uŜywając informacji jak
się z nią połączyć m.in. lokalizacja, kontakt i sposób wywołania usług. Informacje te
znajdują się w opisie usługi (patrz Rys. 21).
Parlay/OSA oraz Parlay X
54
Rys. 21 Przykładowy fragment opisu usługi w języku WSDL zawierający informacje potrzebne do
wykonania operacji Bind.
4.9 Ograniczenia Parlay X
Parlay X posiada pewne ograniczenia, których powinien być świadomy konstruktor
usług telekomunikacyjnych. Ograniczenia te wynikają głównie z faktu, Ŝe Web Services jest
techniką, która nie była projektowana dla aplikacji telekomunikacyjnych i do tej pory nie
poświęcano im wszystkim wystarczająco duŜo uwagi. Do tych ograniczeń moŜna zaliczyć
m.in.: kwestię wydajności, bezpieczeństwa, dostępności, niezawodności, zarządzania
przeciąŜeniami, skalowalności, odporności na błędy, itp. czynników istotnych w systemach
telekomunikacyjnych. Przeczytawszy tą listę moŜna mieć wraŜenie, Ŝe technika Web Services
zupełnie nie nadaje się do tego, do czego została wybrana przez twórców Parlay X. Tak
oczywiście nie jest. Rozwiązanie wymienionych kwestii leŜy głównie w kompetencjach
projektantów platform, zespołów implementujących usługi sieciowe oraz ogólnego rozwoju
systemów obliczeniowych.
Kwestia niskiej wydajności wynika z faktu, Ŝe Web Services wymaga przejścia przez
wiele warstw w stosie protokołów. Najbardziej zasobochłonnymi procesami jest analiza
składniowa i przetwarzanie wiadomości SOAP będących dokumentami XML. W tym
przypadku rozwiązaniem jest wybór odpowiednio lekkiego i zoptymalizowanego analizatora
składni XML50. Problemy z wydajnością dotyczą równieŜ aplikacji napisanych w języku Java,
który często jest wykorzystywany przez społeczność tworzącą rozwiązania
telekomunikacyjne. Optymalizacja działania tych aplikacji moŜe zostać uzyskana poprzez
50 Istnieje kilka rodzajów analizatorów składni tzw. parserów, które róŜnią się wydajnością oraz funkcjonalnością. Dwa zasadnicze to SAX i DOM. W ostatnim czasie pojawiły się projekty parserów, które łączą najlepsze cechy obydwu. Takim parserem jest np. DOM-SAX. Przykładowe zestawienie parserów znajduje się w [55].
Parlay/OSA oraz Parlay X
55
wcześniejsze skompilowanie kodu Javy51. Oczywiście rozwój mocy obliczeniowej maszyn
rozwiąŜe w pewnym stopniu kwestie wydajności.
Ograniczenie dotyczące niezawodności Web Services uwarunkowane jest tym, Ŝe
protokołem transportowym dla Web Services jest HTTP. Protokół HTTP nie gwarantuje ani
dostarczenia wiadomości (jest protokołem bezstanowym), ani równieŜ Ŝadnego QoS. W tym
zakresie istotne jest odpowiednie zabezpieczenie52 przez twórcę usługi kanału transmisji
pomiędzy Web Service Requestor-em, a Web Service Provider-em.
Wyeliminowanie problemów: skalowalności, zarządzania przeciąŜeniami, dostępności
moŜliwe jest przez stworzenie odpowiedniej architektury fizycznej. Ze względu na fakt, Ŝe
Parlay X nie ma mechanizmu sesji – jest bezstanowy - problemy te daje się łatwo rozwiązać
poprzez uŜycie wystarczającej liczby odpowiednio wydajnych maszyn, na których ma działać
Brama Parlay X.
Kwestia bezpieczeństwa ze względu na jej wagę, zostanie omówiona osobno w
kolejnym punkcie.
4.10 Bezpieczeństwo Parlay X
Dla Operatorów otwierających swoje sieci bezpieczeństwo jest jednym z waŜniejszych
aspektów. W Web Services kaŜdy element definiuje mechanizmy bezpieczeństwa.
� Mechanizm bezpieczeństwa w momencie rejestracji usługi w publicznym węźle
UDDI
Web Service Provider, aŜeby zarejestrować usługę w węźle UDDI musi wcześniej
uzyskać swój identyfikator. W wersji 2 UDDI moŜliwość modyfikacji, usunięcia
zarejestrowania nowej usługi moŜliwe jest jedynie po wcześniejszym zautoryzowaniu
uŜytkownika w węźle UDDI.
� Mechanizm bezpieczeństwa w momencie rejestracji usługi w prywatnym węźle
UDDI
51 Do tego celu moŜna wykorzystać kompilator gjc. Oczywiście taki kod przestaje być przenośnym natomiast charakterystyka wydajności ulega znacznemu polepszeniu. Przykładowe testy porównawcze dostępne są w [52]. 52 Rozwiązaniem jest uŜycie asynchronicznych kolejek wiadomości oraz niezawodnych protokołów transportowych np. HTTPR, BEEP (patrz [45]).
Parlay/OSA oraz Parlay X
56
Węzeł prywatny UDDI moŜe wykorzystywać podobny mechanizm jak węzeł
publiczny. Mechanizm ten jednak moŜe zostać dodatkowo rozszerzony o konieczność
posiadania uprawnień w sieci, w której znajduje się węzeł.
� Bezpieczeństwo w trakcie wyszukiwania usługi w węźle UDDI
W wersji 2 UDDI nie był implementowany mechanizm zabezpieczający przed
odczytywaniem zawartości tak, więc wszystkie wpisy w rejestrze były dostępne dla
kaŜdego. Chcąc ograniczyć dostęp do danej usługi naleŜy ustawić odpowiednio
politykę bezpieczeństwa przy operacji bind. Wersja 3 UDDI została wyposaŜona w
mechanizm kontroli dostępu do treści tak, więc moŜna ograniczyć dostęp do
informacji o danej usłudze. Oczywiście nie zwalnia to z definicji polityki
bezpieczeństwa przy operacji bind.
� Bezpieczeństwo przy łączeniu z Bramą Pralay X
Brama Parlay X jest elementem, który ostatecznie powinien regulować dostęp do
usług sieciowych. Mechanizm bezpieczeństwa moŜe być zrealizowany poprzez
implementację dodatkowej usługi, która byłaby odpowiedzialna za przestrzeganie
polityki autoryzacji i dostępu do Ŝądanej usługi.
W modelu, w którym Parlay X korzysta z funkcjonalności jednej lub więcej Bram
Parlay/OSA dedykowana usługa sieciowa Parlay X odpowiedzialna za
bezpieczeństwo powinna dokonać autoryzacji w kaŜdej z bram.
� Bezpieczeństwo danych
Bezpieczeństwo danych jest zapewnione przez protokół komunikacyjny WS-
Security53. WS-Security dokonuje szyfrowania wiadomości SOAP na dowolnie
wybranym poziomie w zaleŜności od potrzeb aplikacji. WS-Security umoŜliwia
zabezpieczenie całej wiadomości lub tylko wybranych elementów pomijając np.:
informację w nagłówkach routingowych. Dzięki temu serwery pośredniczące w
wymianie wiadomości mogą realizować ich przetwarzanie bez konieczności
posiadania uprawnień do jej odszyfrowania.
Innym sposobem zapewnienia integralności i poufności dla Web Services jest
zabezpieczenie komunikacji na poziomie warstwy transportowej. W tym celu moŜe zostać
53 Web Service Security - Specyfikacja protokołu znajduje się w [43].
Parlay/OSA oraz Parlay X
57
uŜyty protokół HTTPS54 albo TLS (Transaction Layer Security)55. Serwery pośredniczące,
które korzystają z tego rodzaju zabezpieczenia muszą mieć jednak moŜliwość odszyfrowania
wiadomości, aŜeby móc dalej ją przekierować. W efekcie zwiększa się liczba potencjalnych
miejsc do ataku, gdzie informacja pozostaje niezabezpieczona. Mechanizm ten powinien być
stosowany jedynie w przypadku, gdy poziom bezpieczeństwa oferowany przez WS-Security
jest niewystarczający.
4.11 Miejsce Parlay/OSA i Parlay X w architekturze IMS
Brama Parlay/OSA znajduje się w architekturze IMS w warstwie aplikacji i jest
traktowana jako jeden z rodzajów serwerów aplikacyjnych (AS). Zgodnie z nomenklaturą
IMS element ten nazywa się OSA Service Capability Server. OSA SCS moŜe wpływać na
zachowanie przebiegu sesji SIP komunikując się z S-CSCF po przez styk ISC (IP multimedia
Subsytem Service Control Interface). Styk ISC (patrz Rys. 22) powinien wspierać moŜliwość
rejestracji OSA SCS u S-CSCF w celu otrzymywania powiadomień o zachodzących
zdarzeniach (event notifications) w UAs (m.in. zmiana stanu zarejestrowanego UA, czy jest
zarejestrowany, jaką funkcjonalność posiada – kodeki, rodzaje mediów, jaką
charakterystykę56, etc.. określonych zgodnie z [27]). O tym, czy w obsłudze danego
zgłoszenia powinien uczestniczyć OSA SCS decyduje S-CSCF na podstawie IFC
przechowywanych w HSS. Wówczas kieruje on przychodzące Ŝądanie SIP do odpowiedniego
AS w tym przypadku OSA SCS (patrz rozdział 3). NaleŜy zaznaczyć, iŜ styk ISC nie
umoŜliwia autoryzacji i bezpieczeństwa pomiędzy trzecią OSA SCS, a S-CSCF. Poza tym styk
ISC powinien:
� zapewnić przesyłanie informacji na temat rozliczeń (patrz TS 32.240 [10] i TS 32.260
[11]);
� wykorzystywać protokół SIP (zdefiniowany w RFC 3261 [22]). Protokół SIP na
interfejsie ISC, powinien umoŜliwiać S-CSCF rozróŜnianie Ŝądań SIP realizowanych
na stykach Mw, Mm i Mg, a Ŝądaniami na ISC (patrz rozdział 3).
54 HyperText Transfer Protocol Secure – wykorzystuje mechanizm SSL (Secure Socket Layer) do zabezpieczenia danych na poziomie protokołu HTTP. Specyfikacja znajduje się w [31]. 55 Patrz rozdział 1. 56 Zgodnie z [27], charakterystyka (characteristic) jest to podobny zbiór funkcjonalności/moŜliwości, które posiada urządzenie (capabilities) z tym, Ŝe nie moŜna go negocjować.
Parlay/OSA oraz Parlay X
58
Analogicznie do Parlay/OSA na styku ISC wprowadza się równieŜ pojęcie „odnogi
SIP” („SIP leg”), która reprezentuje dialog rozumiany według RFC 3261. Pojęcie te
systematyzuje opis interakcji pomiędzy S-CSCF, a OSA SCS.
Aplikacja
Parlay X
OSASCS
AS
S-CSCF HSS
Parlay X (Web Services)
Parlay/OSA API
Sh
Cx
ISC
Rys. 22 Wycinek warstwy aplikacyjnej architektury IMS
OSA SCS posiada równieŜ bezpośredni styk o nazwie Sh z HSS (patrz Rys. 22).
Interfejs ten jest wewnętrznym interfejsem operatora i odpowiada za przekazywanie
informacji do OSA SCS zgodnie z ustaloną polityką. Informacje, które mogą być przesyłane
do OSA SCS to np.: dane potrzebne do realizacji danej usługi, informacje o uŜytkowniku,
MSISDN57, funkcjonalność wizytowanej sieci, informacja o lokalizacji uŜytkownika, dane
współdzielone z innymi aplikacjami jak np.: ksiąŜką adresowa, etc.. NaleŜy zaznaczyć, Ŝe
dane na tym styku przekazywane są w sposób przeźroczysty, co oznacza, Ŝe HSS nie
dokonuje ich przetwarzania, czy interpretacji. OSA SCS moŜe otrzymać równieŜ uprawnienia
pozwalające na aktywację/dezaktywację swoich iFC.
Architektura IMS nie definiuje styku pomiędzy Parlay X, a OSA SCS. Funkcjonalność,
jaką powinien posiadać ten styk opisują dokumenty, w których przedstawiono moŜliwe
sposoby mapowania OSA SCS na Parlay X (patrz [18]). Styk pomiędzy Parlay X, a aplikacją
został zdefiniowany w specyfikacji Parlay X (patrz [18]).
57 Mobile Subscriber ISDN – numer abonenta sieci komórkowej.
Parlay/OSA oraz Parlay X
59
W stworzonym środowisku badawczym zrezygnowano z implementacji interfejsów
Bramy Parlay X na OSA SCS, co jest powszechnie przyjęta praktyką w branŜy
telekomunikacyjnej. Interfejsy te zostały zaimplementowane jako odrębne serwery
aplikacyjne (patrz Rys. 41), a na styku ISC uŜyty został protokół SIP z dodatkowymi
nagłówkami, które wymagane są do spełniania załoŜeń dla styku ISC zgodnie z TS 23.228 [4]
(patrz rozdział 1).
5. JAIN Service Logic Execution Environment
5.1 Inicjatywa JAIN58
Szybko rosnąca popularność języka Java, ze względu na jego charakterystyczne cechy,
tj. intuicyjny model programistyczny, przenośność, budowę komponentową (tzw. beans),
model zdarzeniowy wraz z rodząca się potrzebą otwarcia sieci, sprawiły Ŝe zaczęto prowadzić
prace nad moŜliwościami zastosowania Javy w telekomunikacji - Java Community Process59
powołał program JAIN60. Celem JAIN jest wyspecyfikowanie interfejsów programistycznych,
które będą stanowiły abstrakcję dla róŜnego rodzaju technik sieciowych i protokołów,
wspomagających i upraszczających proces tworzenia usług telekomunikacyjnych.
Architektura JAIN została przedstawiona na Rys. 23. JAIN Składa się z trzech warstw:
protokołów/sieci, sterowania sesją/połączeniem oraz usług. KaŜda z tych warstw wprowadza
pewien stopień abstrakcji. Im wyŜszy stopień abstrakcji tym funkcjonalność API
udostępniana przez daną warstwę jest bardziej ograniczona, ale jednocześnie wymagana jest
mniejsza wiedza. Ponadto dzięki takiemu podejściu aplikacja jest niezaleŜna od sposobu
implementacji warstwy niŜszej. Np. na poziomie warstwy protokołów aplikacja jest
niezaleŜna od konkretnej implementacji protokołu dostarczonej przez producenta urządzeń
sieciowych. W warstwie protokołów specyfikowane są API dla kaŜdego z protokołu z osobna
(np. JAIN SIP API dla protokołu SIP, etc..). Za pomocą tego API programista ma dostęp do
pełnej funkcjonalności oferowanej przez dany protokół. WiąŜe się to z koniecznością
posiadania wiedzy na temat mechanizmów protokołu.
Warstwa sterowania połączeniem/sesją uogólnia mechanizmy wykorzystywane przez
poszczególne protokoły. JAIN Call Control and JAIN Coordination and Transaction API
oferuje jednakowy model zgłoszenia (call model) dla róŜnych rodzajów sieci (ATM, PSTN,
58 Początkowo nazwą inicjatywy było Java API for Intelligent Network. Nazwa została zmieniona ze względu na to, Ŝe JAIN zaczął obejmować inne protokoły i techniki poza Intelligent Network. 59 Java Community Process został powołany przez Sun Microsystem (1998) w celu sformalizowania procesu specyfikacji nowych rozszerzeń i zastosowań Javy. W procesie tym mogą być zaangaŜowane strony trzecie zainteresowane tworzeniem standardów w zakresie języka Javy. Wydawane standardy noszą nazwę Java Specification Request (JSR). 60 W ramach JAIN istnieją 2 grupy eksperckie: Application Expert Group (AEG) oraz Protocol Expert Group (PEG). PEG przygotowuje standardy na poziomie protokołów sygnalizacyjnych w sieciach IP, stacjonarnych i mobilnych. AEG zajmuje się problemem bezpiecznego dostępu do sieci operatora (JAIN Parlay), specyfikuje model zarządzaniem połączeniami (JCC, JCAT) oraz środowisko do kreacji usług.
JAIN Service Logic Execution Environment
61
GSM, etc..). Model zgłoszenia reprezentuje maszynę stanów, do której dostęp realizowany
jest przez JCC/JCAT API. Przy tworzeniu aplikacji na tym poziomie programista nie musi
znać szczegółów odnoszących się do poszczególnych sieci, gdyŜ korzysta z generycznych
funkcji tj. jak wysłanie wiadomości, zestawienie połączenia, etc..
W centrum architektury JAIN znajduje się środowisko wykonawcze dla usług tzw.
Service Logic Execution Environment. SLEE definiuje jednakowy model programistyczny dla
aplikacji sterowanych zdarzeniami oraz kontener, który oferuje szereg standardowych
funkcjonalności (mechanizm transakcji, mechanizm kierowania zdarzeń, zarządzania
aplikacją, etc..). Dzięki temu programista moŜe skupić się wyłączenie na implementacji logiki
aplikacji. Szczegółowa analiza tego środowiska zostanie popełniona w dalszej części tej
pracy.
JAIN Service Logic Exectuion Environment
(JSLEE)
JAIN Call Control (JCC)
and JAIN Coordination and Transactions (JCAT)
TCAP ISUP INAP SIP MAP MAP
Security InterfaceJAIN Service Provider
Aplikacje niezaufane tworzone
przez „trzecią stronę”
JAIN Service Creation
Environment
(JSCE)
Aplikacje zaufane tworzone
przez „trzecią stronę”
Service APIs
Call Control/Session API
Protocol/Connection API
Sygnalizacja
Sieć
Usługi
Rys. 23: Architektura JAIN
Warstwa sterowania sesją i warstwa protokołów znajdują się w domenie operatora,
który jest obszarem bezpiecznym (patrz Rys. 23). Idea JAIN przewiduje pełne otwarcie sieci
dla niezaleŜnych dostawców oprogramowania, dlatego dodatkowo definiuje interfejsy w
warstwie usług dla aplikacji zaufanych (JAIN Service Provider) i niezaufanych (Security
Interface). Standaryzacja tych interfejsów przebiega jednak bardzo wolno, poniewaŜ
operatorzy do pełnego otwarcia swoich sieci chcą stosować inne techniki tj. Parlay/OSA, a do
ich implementacji wystarczające są API z niŜszych warstw architektury JAIN.
JAIN Service Logic Execution Environment
62
5.2 Definicja JSLEE, wymagania dla JSLEE
JSLEE, czyli JAIN Service Logic Execution Environment jest serwerem aplikacyjnym i
centralną częścią programu JAIN prowadzonego w ramach JCP, a jego specyfikacja (JSLEE
1.0) została zawarta w dokumencie JSR 22 (Java Specification Request). Aktualnie
prowadzone są prace nad JSLEE 1.1 w grupie JSR 240.
Serwer aplikacyjny jest kontenerem61, który oferuje środowisko wykonawcze (Run
Time Environment) dla aplikacji reprezentujących usługi. Jest to środowisko komponentowe,
które pozwala na wykorzystanie wcześniej stworzonych komponentów w ramach tej samej
lub innej aplikacji. Np. w JSLEE komponenty, to tzw. SBB – Service Building Block62.
JSLEE wykorzystuje język Java, który zapewnia przenośność i obiektowość aplikacji.
Główne koncepcje wykorzystane przy projektowaniu kontenera JSLEE bazują na specyfikacji
J2EE63, a jako przykład moŜe posłuŜyć uŜyta technika JMX64 (Java Management Extension)
do zarządzania kontenerem. Poza tym JSLEE wspiera takŜe inne interfejsy Javy m. in. J2SE,
JNDI, JAXP65, dzięki czemu te dwa środowiska moŜna bez większych trudności integrować.
Kontener dostarczany przez JSLEE znacznie się róŜni od kontenera J2EE. Kontener
JSLEE wspiera przede wszystkim aplikacje sterowane zdarzeniami (message driven
application), co jest uwarunkowane koniecznością obsłuŜenia komunikacji asynchronicznej
charakterystycznej dla aplikacji telekomunikacyjnych. Dodatkowo musi spełniać inne
wymagania stawiane przez środowisko telekomunikacyjne. Dlatego teŜ został zaprojektowany
w taki sposób, aby obsłuŜyć bardzo duŜo prostych transakcji opartych na zdarzeniach w
czasie rzeczywistym oraz zapewnić Ŝądaną bezawaryjność pracy. PoniŜej zostały
wylistowane wymagania, które uwzględnia specyfikacja JSLEE.
61 Kontener jest to podstawowy element architektury, w którym instalowane są aplikacje (inne komponenty). Jest obiektem, który oddziałuje bezpośrednio z niskopoziomową funkcjonalnością charakterystyczną dla danej platformy. Eksponuje ją dla komponentów w nim umieszczonych w postaci API do usług tj. transakcje, bezpieczeństwo, wyszukiwanie zarejestrowanych obiektów za pomocą ich nazwy, itp.. Zarządza cyklem Ŝycia komponentów. 62 Szczegółowy SBB opis zostanie podany w rozdziale5.5.5. 63 Java 2 Platform, Enterprise Edition jest to standard stworzony przez JCP do tworzenia aplikacji rozproszonych, opartych o architekturę wielowarstwową. Wykorzystuje język Java oraz definiuje model aplikacji i środowiska wykonawczego tzw. kontener. Zdefiniowany został w JSR 151[36]. 64 Java Management Extensions jest to technika, która umoŜliwia zarządzanie i monitorowanie aplikacji sieciowych. Dane zasoby reprezentowane są przez obiekty MBean (Manager Bean). Ciekawym rozwiązaniem jest moŜliwość dynamicznego ładowania i inicjalizowania klas. 65 Chodzi o wszystkie zgodność z bibliotekami dla Java 2 Platform Edition, Java Naming Directory Index, Java API for XML Processing. Specyfikacje tych technik moŜna znaleźć na stronie Sun Microsystems.
JAIN Service Logic Execution Environment
63
� Asynchroniczność, przetwarzanie zorientowane na zdarzenia. Komponenty
rejestrują się poprzez mechanizm publish/subscribe66 w źródłach zdarzeń w celu
odbierania zdarzeń, którymi są zainteresowane. Mechanizm ten jest wbudowany
takŜe w kontener i wspiera mechanizm elastycznego filtrowania i przekazywania
zdarzeń z określonymi priorytetami.
� Krótki czas reakcji i duŜa przepustowość. Czasy odpowiedzi powinny być krótsze
niŜ 200 ms oraz JSLEE powinien wspierać przetwarzanie równoczesne duŜej liczby
prostych zdarzeń i prostych transakcji.
� DuŜa niezawodność. Zgodnie ze standardami telekomunikacyjnymi powinna być
zagwarantowana bezawaryjność na poziomie 99.999%. Sposobem na jej osiągnięcie
jest replikacja stanów i wykorzystanie grup serwerów.
� Łatwość integracji z innymi systemami. NiezaleŜność od sieci. JSLEE wprowadza
koncepcje Resource Adapters, które stanowią źródła i ujścia dla zdarzeń
pochodzących z innych systemów. Takie podejście sprawia, Ŝe dołoŜenie nowego
elementu sieci, czy teŜ konieczność obsłuŜenia innego protokołu nie będzie
wymagało modyfikacji środowiska, w którym działają usługi.
� Przenośność. Aplikacje tworzone w środowisku JSLEE są niezaleŜne od konkretnego
rozwiązania sprzętowego i systemu operacyjnego. W związku z tym kod aplikacji
nie wymaga modyfikacji w przypadku przenoszenia z jednego środowiska do innego.
Aplikacje są odizolowane od architektury sprzętowej i systemu poprzez
wykorzystanie wirtualnej maszyny Javy.
� Wbudowany mechanizm zarządzania. JSLEE oferuje mechanizm zarządzania w
postaci JMX oraz zbiór narzędzi takich jak: źródło czasu, alarmy, etc..
NaleŜy zaznaczyć, Ŝe specyfikacja JSLEE definiuje jedynie architekturę i mechanizmy,
przy czym nie narzuca konkretnych rozwiązań implementacyjnych. Dlatego implementacje
JSLEE67 mogą znacząco się róŜnić pomiędzy sobą w zakresie wydajności oraz sposobie
działania poszczególnych mechanizmów.
66 Mechanizm publish/subscribe zaprojektowany został do realizacji komunikacji asynchronicznej. Nie naleŜy go mylić z mechanizmem komunikacji asynchronicznej lister/provider wykorzystywanym w Javie. 67 Istniejące implementacje referencyjne JSLEE zostaną omówione w rozdziale 1.
JAIN Service Logic Execution Environment
64
5.3 Porównanie technik J2EE i JSLEE
JSLEE czerpie z rozwiązań stworzonych dla J2EE. Jako przykład moŜna podać kilka
analogii w obydwu architekturach. W jednym i w drugim rozwiązaniu jest to architektura
komponentowa. W J2EE komponenty nazywają się Enterprise Java Beans68 tzw. EJBs,
natomiast w JSLEE SSBs. Poza tym JSLEE wykorzystuje szereg mechanizmów z J2EE np.:
mechanizm do zarządzania i monitorowania aplikacji - Java Management Extension, czy
JNDI wykorzystywany do rejestrowania i wyszukiwania obiektów na podstawie ich nazwy.
Powstaje zatem pytanie, dlaczego potrzebny jest nowy kontener? Czy J2EE nie mógłby zostać
wykorzystany równieŜ dla celów telekomunikacyjnych? OtóŜ nie do końca.
Tab. 2: Porównanie pomiędzy rozwiązaniami IT uŜywanymi w sieciach prywatnych/wydzielonych, a
systemami telekomunikacyjnymi.
Systemy Telekomunikacyjne Systemy IT
Wywołania Głównie asynchroniczne, (zdarzenia są generowane z róŜnych sieci wykorzystujących róŜne protokoły)
Głównie synchroniczne (wywołania funkcji, bazy danych)
Poziom ziarnistości zdarzeń
Bardzo duŜa częstotliwość, zdarzenia są bardzo proste (odwzorowują wiadomości protokołów)
Mała częstotliwość, zdarzenia przenoszą duŜą ilość informacji (dane z baz danych)
Komponenty Lekkie komponenty, oferujące skromną funkcjonalność. DuŜa liczba kreacji i usuwania komponentów
CięŜkie komponenty, realizują zawansowane zadania związane np. z przetwarzaniem zapytań do baz danych. Mogą istnieć przez długi czas na dysku np. komponenty trwałe (persistient)
Źródła danych Wiele źródeł danych (np. róŜne protokoły, bazy danych)
Głównie serwery bazodanowe
Transakcje Proste transakcje ZłoŜone transakcje
Obliczenia DuŜa liczba drobnych obliczeń ZłoŜone obliczenia, przetwarzanie duŜych zapytań do baz danych.
Dostępność 99,999% 99%
Czas rzeczywisty
TAK NIE koniecznie
Rozmieszczenie Rozproszone w sieci (częściowo mobilnej)
Scentralizowane, bazy danych znajdują się w jednym miejscu
68 Enterprise Java Bean jest zarządzanym, znajdującym się po stronie serwera komponentem, który wykorzystywany jest do budowy modularnych aplikacji. Specyfikacja EJB znajduje się w JSR 220.
JAIN Service Logic Execution Environment
65
Węzły od 1 do 4 CPUs na węzeł od 2 do 32 CPUs na węzeł
Grupy węzłów DuŜe. Od 2 do 16 węzłów Od 2 do 4 węzłów
W Tab. 2 porównano cechy, systemów telekomunikacyjnych oraz systemów IT tzw.
enterprise wykorzystywanych w sieciach wydzielonych. Reprezentantem tego drugiego
rodzaju systemów jest m.in. platforma J2EE. Systemy telekomunikacyjne mają odmienne
wymagania w odróŜnieniu od systemów IT. Podstawową róŜnica pomiędzy tymi dwoma
typami systemów jest sposób komunikowania się oraz charakter pracy komponentów. W
systemach IT komunikacja odbywa się w sposób synchroniczny. Wynika to m. in. z faktu, Ŝe
w systemach tych wykorzystywany jest proceduralny model programowania. Polega on na
tym, Ŝe po wywołaniu określonej funkcji następuje natychmiastowa odpowiedź. Zaletą
zachowania synchroniczności wywołań jest łatwość tworzenia spójnego oprogramowania
(proces projektowania i debugowania aplikacji). W przypadku próby zastosowania tego
paradygmatu w systemach telekomunikacyjnych spowodowałoby to nieefektywne
wykorzystanie zasobów.
Elementy systemów telekomunikacyjnych komunikują się ze sobą asynchronicznie, co
moŜe zostać zaprezentowane na przykładzie zbioru węzłów sygnalizacyjnych
przetwarzających wiadomości protokołu SIP (patrz Rys. 24). Wysłanie przez UAC
wiadomości INVITE do pierwszego węzła (SIP PROXY A) powoduje odpowiednie jej
przetworzenie i/albo odpowiedź np.: z komunikatem 304 albo przekazanie do kolejnego
SIP PROXY B. Jak moŜna się domyślić odpowiedź od SIP PROXY B moŜe przyjść w
dowolnym momencie (czas potrzebny na przetworzenie, dowolnie późna odpowiedź UAC po
stronie SIP PROXY B) lub w przypadku awarii UAC B SIP PROXY A moŜe nie otrzymać
Ŝadnej wiadomości zwrotnej. Jeśli zostałby uŜyty synchroniczny sposób komunikacji,
wówczas wywołanie funkcji, która realizuje wysłanie wiadomość INVITE zablokowałoby
kolejno zasoby UAC A, SIP PROXY A SIP PROXY B na czas do momentu uzyskania
odpowiedzi, która de facto moŜe nie nadejść. W przypadku sygnalizacji i systemów
rozproszonych nie mamy wiedzy o stanie węzłów znajdujących się dalej niŜ sąsiednie.
Oczywiście w takim przypadku moŜna zdefiniować odpowiednie czasy oczekiwania (time
out), po upłynięciu, których system uzna proces za zakończony. MoŜna równieŜ umieścić
kolejne wywołania funkcji w osobnych wątkach. Nie unikniemy jednak blokady i
marnotrawienia zasobów.
JAIN Service Logic Execution Environment
66
Oczekiwanie na odpowiedź
Oczekiwanie na odpowiedź
Oczekiwanie na odpowiedź
Rys. 24: Mechanizm komunikacji synchronicznej
Rozwiązaniem tego problemu jest zastosowanie komunikacji asynchronicznej, która
odzwierciedla naturalne zachowanie się rozproszonej architektury węzłów sygnalizacyjnych.
Koncepcja ta wyraŜa się w architekturze zdarzeniowej, w której główną rolę odgrywają
zdarzenia (events). Zdarzenia są nośnikiem informacji pomiędzy komponentami. Wysłanie
zdarzenia nie powoduje zajęcia zasobów, do czasu uzyskania odpowiedzi, gdyŜ system nie
oczekuje na natychmiastową odpowiedź. Odpowiedź ta moŜe nadejść w dowolnym
momencie. Komponenty te są ze sobą luźno powiązane (loosely coupled) w związku z czym
łatwo moŜna tworzyć rozproszone systemy oraz efektywnie wykorzystywać zasoby.
Architektura J2EE równieŜ oferuje asynchroniczny sposób komunikacji realizowany
przez mechanizm JMS (Java Message Service)69 wraz z modelem publish/subscribe. Jest to
jednak mechanizm zewnętrzny, który nie zapewnia komunikacji przy wykorzystaniu zdarzeń
pochodzących z wnętrza kontenera, co powoduje, Ŝe komunikacja pomiędzy komponentami
musi być synchroniczna. JMS uniemoŜliwia równieŜ dynamiczne tworzenie nowych kolejek
wiadomości (miejsc, w których gromadzone są i obsługiwane przychodzące asynchronicznie
wiadomości) oraz dynamiczną aktualizację mechanizmu kierowania zdarzeń z poziomu
aplikacji.
Oprócz tego istnieje zasadnicza róŜnica dotycząca charakteru zdarzeń, które musi
przetworzyć system telekomunikacyjny.Przede wszystkim w porównaniu do systemów IT jest
69 Java Message Service jest tzw. Java Message Oriented Middleware (MOM) API słuŜące do wysyłania widomości pomiędzy dwoma lub większą liczbą klientów. JMS został wyspecyfikowany w JSR 914
JAIN Service Logic Execution Environment
67
to duŜa liczba prostych obiektów, które muszą zostać przetworzone w czasie rzeczywistym.
Kontener J2EE nie nadaje się do realizacji tego zadania, poniewaŜ jest zbyt „cięŜki” 70.
Kolejną róŜnicą między JSLEE, a J2EE jest sposób komunikacji ze światem
zewnętrznym rozumiany jako dostęp do róŜnego rodzaju zasobów. Dla J2EE głównym
źródłem danych jest serwer bazodanowy natomiast dla JSLEE jest to szereg róŜnych
protokołów oraz baz danych. Dzięki koncepcji aplikacji sterowanych zdarzeniami, JSLEE
zapewnia ujednolicony sposób komunikacji z róŜnymi typami sieci oraz elementami
architektury.
Inne cechy posiadają równieŜ komponenty obydwu systemów. EJB posiadają
przewaŜnie zaawansowaną funkcjonalność, która słuŜy głownie do przetwarzania danych
pobranych z bazy danych. Dlatego są to tzw. cięŜkie komponenty o długim czasie Ŝycia
(persistent). Natomiast komponenty SBB słuŜą do przetwarzania duŜej liczby małych i
prostych porcji danych, które najczęściej reprezentują wiadomości danego protokołu. W
związku z tym komponenty tego typu kreowane i niszczone są bardzo często.
Istotnym mechanizmem zabezpieczającym komunikację (gwarantującym: atomowość,
spójność, izolację, trwałość71) są transakcje. Charakter transakcji uzaleŜniony jest oczywiście
w duŜej mierze od danych, które zabezpiecza. I tak dla JSLEE występuje wiele prostych
transakcji, natomiast J2EE charakteryzuje się długimi i złoŜonymi transakcjami
(zabezpieczenie duŜych porcji danych pochodzących z długo trwających transakcji).
Jeśli chodzi o aspekt niezawodności, to w przypadku systemów telekomunikacyjnych
wymagana jest bardzo wysoka bezawaryjność rzędu 99,999%. Natomiast w przypadku
systemów IT wystarczający poziom bezawaryjności jest na poziomie 99%.
5.4 Porównanie technik JSLEE i SIP Servlet
Servlety są techniką do tworzenia aplikacji sieciowych potocznie zwanych webowymi72
w języku Java i wykonywane są poprzez serwer aplikacji w specjalnie do tego
70 Rozbudowana funkcjonalność kontenera J2EE, która nie jest konieczna do budowy SBB natomiast ma duŜy wpływ na wydajność (np. Java Persistence API, etc..). 71 Atomizm, spójność, izolacja, trwałość tzw. ACID: Atomicity, Consistency, Isolation, Durability są podstawowymi cechami, którymi musi się charakteryzować transakcja. 72 Aplikacje webowe rozumiane są szeroko, tzn. nie tylko jako programy do generowania stron HTML.
JAIN Service Logic Execution Environment
68
przeznaczonym kontenerze. Zostały zdefiniowane przez Java Community Process w
specyfikacji JSR 154 [37] na potrzeby platformy J2EE.
Zasada działania oraz struktura klas servletów została przedstawiona na Rys. 25.
Komunikacja z servletem, ze względu na jego pierwotne przeznaczanie73 realizowana jest z
wykorzystaniem protokołu HTTP. Przeglądarka generuje Ŝądanie do serwera aplikacyjnego, a
serwer aplikacyjny na jego podstawie wybiera odpowiedni kontener, w którym umieszczony
został servlet. Program korzystając z HTTPServlet API moŜe dokonać analizy Ŝądania i
wygenerować dokument HTML, który zostanie odesłany do przeglądarki.
Rys. 25: Zasada działania servletów oraz struktura klas słuŜących do jego budowy
Technika Servletów w zamierzeniu nie była projektowana wyłączenie do aplikacji
wykorzystujących protokół HTTP. Ze względu na wiele podobieństw protokołów HTTP i SIP
model programistyczny servletów został w łatwy sposób zaadoptowany do tworzenia
aplikacji bazujących na protokole SIP. Wystarczy skorzystać z mechanizmu dziedziczenia i z
klasy GenericServlet wyprowadzić API dla protokołu SIP (SIPServlet, patrz Rys. 25).
Zasada działania servletów pozostaje wówczas taka sama, a na Rys. 25 naleŜy jedynie
zastąpić protokół HTTP protokołem SIP.
Model programistyczny, który oferuje technika servletów jest stosunkowo łatwy i
pozwala szybko budować aplikacje74. Jednak kontener dla Servletów posiada szereg
ograniczeń, które uniemoŜliwiają spełnienie kilku istotnych załoŜeń koniecznych do
73 Technika servletów zostały pierwotnie stworzona na potrzeby budowania dynamicznie generowanych stron HTML. 74 W specyfikacji SIP Servlet moŜna przeczytać „Emphasis is on simplicity and minimality rather than completeness”.
JAIN Service Logic Execution Environment
69
tworzenia zawansowanych aplikacji telekomunikacyjnych. Ograniczenia te zostaną
omówione w następujących kategoriach:
� Architektura aplikacji . Servlety wykorzystywane są do prostych zadań. Brak w tym
przypadku modularyzacji na poziomie funkcjonalnym. W JSLEE takimi modułami
są SBB. Servlety w swoim załoŜeniu przeznaczone są do obsługi konkretnego
protokołu. Jeśli chcielibyśmy obsłuŜyć jednocześnie inny protokół musielibyśmy
dziedziczyć po innej klasie, a Ŝe w Java nie zapewnia wielokrotnego dziedziczenia,
tak więc moŜna wykorzystać tylko jeden protokół w ramach konkretnego servletu.
� Stanowość aplikacji . Servlety zostały zaprojektowane głównie do obsługi protokołu
HTTP, który jest z zasady protokołem bezstanowym. Utrzymanie stanu w servletach
wiąŜe się z przechowywaniem informacji o nim w ramach sesji jako para ciąg
znaków-obiekt. Komponenty SSB w JSLEE mogą być zarówno stanowe jak i
bezstanowe. Stan ich utrzymywany jest w ramach transakcji, co gwarantuje
bezpieczeństwo powrócenia do ostatniego poprawnego stanu w przypadku
wystąpienia jakiegokolwiek błędu.
� Sterowanie dostępem do zasobów (problem hazardu). W Servletach brak jest
mechanizmu transakcji. AŜeby uniknąć efektu hazardu naleŜy korzystać z
mechanizmu monitorów. JSLEE oferuje standardowo transakcje, które izolują
poszczególne procesy.
� Funkcjonalność dostępna dla aplikacji. JSLEE oferuje znaczenie szerszy zbiór
funkcjonalności przydatnych w tworzeniu aplikacji telekomunikacyjnych (patrz
5.5.2).
� Zarządzanie. W Servletach brakuje mechanizmu do zarządzania. JSLEE oferuje
zestandaryzowany mechanizm JMX, udostępniając szereg interfejsów, które
pozwalają zrządzać aplikacją, cyklem Ŝycia, etc..
Tab. 3: Porównanie technik JAIN SLEE i SIP Servlet.
SIP Servlety JAIN SLEE
Architektura aplikacji
Bazuje na Servletach HTTP;
Brak modelu standaryzacji dla budowy złoŜonych aplikacji i ponownego wykorzystania;
Bazuje na komponentach, architektura obiektowa;
Jednostką jest Service Building Block;
Ideą jest wspomaganie ponownego
JAIN Service Logic Execution Environment
70
wykorzystywania stworzonych wcześniej komponentów;
Stanowość aplikacji
Servlety są bezstanowe;
Współdzielony stan pomiędzy poszczególnymi wywołaniami Servletu jest przechowywany osobno jako para ciąg znaków i obiekt;
Współdzielony stan jest widoczny dla wszystkich Servletów, które mają dostęp do danej sesji;
SBB mogą być zarówno bezstanowe lub stanowe;
Stan SBB jest prywatny, przechowuje bezpieczne typy, utrzymywany w ramach transakcji i jest właściwością samego SBB;
Współdzielone stany mogą być przechowywane w oddzielnych Activity Context;
Dostęp do współdzielonych stanów moŜe być deklarowany w momencie rozmieszczenia SBB;
Sterowanie współzawodnictwem (hazard)
Zarządzenie z poziomu aplikacji np. Wykorzystanie mechanizmu monitorów w Javie;
Zarządzany przez system, np. izolacja na poziomie transakcji;
Protokół
SIP i HTTP; NiezaleŜne od protokołu;
MoŜe być rozszerzane o dodatkowe protokoły i zewnętrzne zasoby przy wykorzystaniu Resource Adaptors;
Spójny model zdarzeniowy, niezaleŜny od protokołu czy zasobów;
Generyczna funkcjonalność
Timer; Timer; Trace; Alarm; Profiles;
Dostępne mechanizmy
Stan zarządzany przez kontener (obiekt sesji), który moŜe być replikowany;
Brak mechanizmu transakcji dla przetwarzanych wiadomości SIP;
Stan nie jest utrzymywany w ramach transakcji;
Generyczna funkcjonalność nie jest dostępna w ramach transakcji;
Brak modelu dla obsługi błędów;
Stan zarządzany przez kontener (SBB CMP, Activity Context, etc..). Stan ten moŜe być replikowany;
Zdarzenia dostarczane w ramach transakcji;
Operacje dla stanu zarządzanego przez kontener utrzymane są w ramach transakcji;
Funkcjonalności, np. timer są dostępne w transakcji;
Dobrze zdefiniowany i zrozumiały model obsługi błędów po przez mechanizm transakcji;
Zarządzanie
JAIN Service Logic Execution Environment
71
Brak standardowego mechanizmu
Standardowy mechanizm do zarządzania - Java for Management Extensions;
NiezaleŜny od protokołu zarządzania;
Interfejs do zarządzania aplikacjami, włączając cykl Ŝycia, aktualizacje, profile, itp.;
Interfejs do zarządzania cyklem Ŝycia SLEE;
JSLEE jest duŜo bardziej zaawansowaną techniką niŜ SIP Servlety. Wynika to z tego, iŜ
SIP Servlety są jedynie modelem programistycznym natomiast JAIN SLEE oferuje coś
więcej, mianowicie środowisko do wykonywania aplikacji.
Ponadto JSLEE został zestandaryzowany równieŜ w celu osiągnięcia wysokiej
niezawodności, którą zapewniają jego mechanizmy programistyczne uodparniające aplikacje
na pojawiające się błędy.
5.5 Architektura JSLEE
W tym rozdziale zostaną omówione główne elementy i mechanizmy architektury
JSLEE na podstawie specyfikacji JSLEE w wersji 1.1.
Architektura JSLEE składa się z czterech elementów: Zarządzania (Management),
Szkieletu (Framework), Modelu Komponentowego (Component Model) i Adapterów do
zasobów (Resorce Adapters). Została ona przedstawiona Rys. 26.
Resource Adaptor Resource Adaptor Resource Adaptor
Interfejsy do zarządzania
usługami oraz SLEE
JAIN SLEE Agent JMXKontener
Service
Building
BlocksService
Building
Blocks
Service
Building
Blocks
Service
Building
Blocks
Timers
Alarms
Tracing
Aplikacja do zarządzania
JMX
AC Naming
Usage
JAIN API Inne API
Zasoby sieciowe
Rys. 26: Architektura JSLEE
JAIN Service Logic Execution Environment
72
5.5.1 Zarządzanie
Za zarządzanie w JSLEE odpowiedzialny jest mechanizm Java Management
Extension. Rozwiązanie to zostało wybrane m. in. ze względu na skalowalność, łatwość
integracji z innymi systemami zarządzania (np. po przez strony WWW) oraz względną
prostotę zaimplementowania go w samej platformie JSLEE (np. jako servlety, JSP75). Poza
tym JMX jest niezaleŜny od protokołów.
Zadania JMX w JSLEE są bardzo podobne jak w J2EE np.: zarządzanie środowiskiem
wykonawczym, instalacja, zarządzanie cyklem Ŝycia usług, zarządzanie dostępem usług do
danych po przez tzw. profile, etc..
Szczegółową funkcjonalność wyraŜają poniŜsze interfejsy pochodzące z pakietu
javax.slee.management .
� SleeManagementMBean
� DeploymentMBean;
� ServiceManagementMBean;
� ServiceUsageMBean;
� ProfileProvisioningMBean;
� AlarmMBean;
� TraceMBean;
� ResourceManagementMBean;
JMX umoŜliwia równieŜ zbudowanie przy pomocy MBeans graficznego interfejsu do
zarządzania, który ułatwia administrowanie całym system.
5.5.2 Framework
Framework oferuje bazową funkcjonalność (tzw. facilities) dla komponentów. Z tego
powodu budowa usług sprowadza się głównie do implementacji logiki w komponentach SBB,
przez co wytwarzanie usług staje się prostsze. Poza tym podstawowa funkcjonalność
dostarczana przez Framework czyni usługi niezaleŜnymi od konkretnej platformy.
Framework oferuje następującą funkcjonalność:
� Timer Facility;
75 Java Server Pages – technika umoŜliwiają tworzenie dynamicznych dokumentów HTML, XHTML, XML wykorzystaniem języka Java wplecionym w kod strony HTML.
JAIN Service Logic Execution Environment
73
� Alarm Facility;
� Trace Facility;
� Activity Context Naming Facility;
� Profile Facility;
� router zdarzeń.
Timer Facility
W zastosowaniach telekomunikacyjnych czas odgrywa waŜną rolę. Programista
aplikacji musi mieć narzędzie, które pozwoli np.: określić przedział czasu, za jaki dany
uŜytkownik powinien zostać rozliczony lub wyznaczyć moment, w którym dana usługa
powinna zostać wyłączona. Taką funkcjonalność dostarcza dla środowiska wykonawczego
Timer Facility.
Timer Facility zarządza równieŜ innymi typami źródeł czasu po przez interfejs
TimerFacility. MoŜe on takŜe generować zdarzenia zawierające informację o czasie tzw.
Timer Event.
Czasami jednak moŜe wystąpić problem z punktualnym dostarczeniem zdarzenia
czasowego. Na opóźnienie zdarzeń mogą mieć wpływ dwa czynniki:
� przeciąŜenie w danej chwili routera zdarzeń;
� ustawienie zbyt niskiego priorytetu w kolejce przechowującej zdarzenia docierające do
SBB.
Rozwiązanie dotyczące problemów opóźnień zdarzeń nie zostało zawarte w
specyfikacji JSLEE i nie jest trywialne. Jest to jedno z wielu zagadnień, którego rozwiązanie
pozostawiono w gestii programistów, a zastosowane podejście ma istotny wpływ na
wydajność działania serwera aplikacyjnego. Przy implementacji naleŜy liczyć się, Ŝe
minimalizacja i zapewnienie jednakowych opóźnień pochłania wiele zasobów, ze względu na
konieczność przechowywania m. in. informacji o ścieŜce kaŜdego zdarzenia.
Alarm Facility
Funkcjonalność alarmów wykorzystywana jest zarówno przez SBBs jak i Resource
Adaptors w celu informowania o stanie usługi JSLEE oraz zewnętrznych systemów
zarządzania. Interfejs Alarm Facility został zdefiniowany jako AlarmMBeanInterface .
Wszystkie alarmy zostają wysyłane przez AlarmMBean jako obiekty AlarmNotification .
JAIN Service Logic Execution Environment
74
SBBs i Resource Adoptors mają dostęp do Alarm Facility po przez obiekt
AlarmFacility , natomiast obiekt AlarmFacility implementuje AlarmFacilityInterface .
Trace Facility
Ta funkcjonalność Framework pozwala przekazywać informacje związane z logami
generowanymi w JSLEE.
Activity Context Naming Facility
Activity Context Naming Facility oferuje globalną przestrzeń nazw dla Acitivity
Contexts. Sposób działania jest podobny do mechanizmu JNDI z J2EE. SBB moŜe dla danego
Activity Context ustawić nazwę. Na podstawie tej nazwy konkretny Activity Conetxt moŜe być
wyszukiwany po przez inne SBB. W ten sposób SBBs mogą wymieniać po między sobą
wiadomości.
Profile Facility
Ta funkcjonalność pozwala SBB i Resorce Adapters wyszukiwać Ŝądane przez nie
profile (Profile) w tabeli profili (Profile Table).
Event Routing
Specyfikacja JSLEE definiuje w jaki sposób przekazywane są zdarzenia pomiędzy
komponentami. Definicja ta zapisana jest równieŜ w sformalizowany matematyczny sposób.
Ten sposób wymiany zdarzeń implementuje element logiczny tzw. router zdarzeń (Event
Router). MoŜna powiedzieć, Ŝe jest on rdzeniem JSLEE. Jego miejsce w architekturze JSLEE
i interakcje z innymi elementami JSLEE przedstawia poglądowo Rys. 27. Router zdarzeń
odbiera przychodzące zdarzeń z Resource Adapters i przekierowuje je dalej do
zainteresowanych tymi zdarzeni SBB, jak i równieŜ w przeciwną stronę od SBB do Resource
Adapter.
JAIN Service Logic Execution Environment
75
Rys. 27: Mechanizm przekazywania zdarzeń w JSLEE - router zdarzeń
5.5.3 Model Komponentowy w architekturze JSLEE
Model komponentowy określa budowę zorientowanych zdarzeniowo aplikacji jak zbiór
komponentów, jak i równieŜ interakcje pomiędzy komponentami oraz pomiędzy
komponentami, a kontenerem.
� Aplikacje JSLEE składają się z:
� Service Building Blocks (SBB);
� Zdarzeń (Events) oraz typów zdarzeń (Event Type);
� Activity, Activity Object i Activity Context;
� Profili (Profiles), Tabeli Profili (Profile Table) i specyfikacji profili (Profile
Specyfication).
Model komponentowy opisuje równieŜ sposób konfiguracji aplikacji po przez tzw.
Deyployment Descriptor. Na Rys. 28 przedstawiono zaleŜności pomiędzy poszczególnymi
elementami modelu komponentowego.
Konten
er
Rys. 28: Główne elementy JSLEE i powiązania pomiędzy nimi
JAIN Service Logic Execution Environment
76
5.5.4 Service Building Block - SSB
SBB, czyli Service Building Block jest podstawowym komponentem, który zwiera cześć
logiki aplikacji. Jest bardzo podobny do Enterprise Java Beans (EJBs) m. in. ze względu na
cykl Ŝyciowy usługi, który kontrolowany jest przez środowisko wykonawcze. Środowisko
wykonawcze, a więc kontener zarządza przetwarzaniem zdarzeń i zapewnia poprawność tego
procesu uŜywając mechanizmu transakcji.
Rys. 29: Budowa Service Building Block (SBB). Wymagane interfejsy klasy abstrakcyjnej
Klasa abstrakcyjna SBB, która została przedstawiona poglądowo na Rys. 29 musi
definiować następujące elementy:
� typy odbieranych i generowanych zdarzeń po przez SBB;
� handlers, czyli funkcje, które są wołane do obsługi przychodzących zdarzeń;
� funkcje lokalne interfejsu SBB;
� graf SBB oraz drzewo instancji SBB;
� wspólne dane, czyli profile.
5.5.5 Drzewo SBB
KaŜda usługa składa się z jednego lub więcej instancji SBB róŜnych typów i moŜe
zostać przedstawiona jako drzewo. Jednostki SBB (SBB Entity) są instancjami komponentów
SBB. Oczywiście kaŜde SBB moŜe być wielokrotnie wykorzystane w innych usługach.
Poszczególne SBB są węzłami w drzewie (patrz Rys. 30), a pomiędzy nimi znajduje się
krawędź z etykietą określającą priorytet dostarczenia zdarzenia kolejnemu SBB w hierarchii.
W drzewie musi równieŜ zostać zdefiniowany tzw. Root-SBB. Root-SBB jest jedyną
jednostką SBB, która moŜe zostać wytworzona przez SLEE. Np. na Rys. 30 dane są trzy SBB
JAIN Service Logic Execution Environment
77
X1, X2, Z2 będące Root-SBB. Konkretne jednostki SBB mogą naleŜeć tylko do jednego
drzewa.
Rys. 30: Drzewo SBB Entity (źródło JSR 240)
Specyfikacja JSLEE podaje przykład ułatwiający zrozumienie interpretacji drzewa
SBBs. Usługa Call Blocking and Call Forwarding reprezentowana jest przez jednostkę Root-
SBB nazwaną CallBlockingAndCallForwarding. SLEE moŜe inicjować tą usługę poprzez
stworzenie instancji Root-SBB tej usługi w wyniku przyjścia zdarzenia sygnalizującego
pojawienia się rozmowy telefonicznej. W zaleŜności od stanu usługi Root-SBB moŜe tworzyć
instancje CallBlockingSBB lub CallForwardingSBB. AŜeby usługa mogła obsłuŜyć więcej niŜ
jedno połączenie JSLEE moŜe wykreować więcej instancji CallBlocking-SBB.
Graf SBB
Konkretne drzewo SBB jest instancją grafu SBB. Przykładowy graf pokazany został na
Rys. 31. Na podstawie grafu z rysunku zostało zbudowane jedno z kliku moŜliwych drzew
SBB (patrz Rys. 30). W grafie został równieŜ zaznaczony SLEE jako „ojciec” dla wszystkich
Root-SBB oraz wartości priorytetów dla przekazywanych zdarzeń od Root-SBB w dół drzewa.
Funkcje lokalnego interfejsu SBB
KaŜdy SBB moŜe implementować lokalny interfejs. Lokalny interfejs jest konkretnym
interfejsem, który zostaje dostarczony przez twórcę usługi np.: funkcja void hello(...) z
Rys. 29. Interfejs ten musi rozszerzać SbbLocalObject Interfeace . Obiekty SBB mogą
wzajemnie uŜywać swoich interfejsów, a więc wywoływać funkcje synchronicznie.
JAIN Service Logic Execution Environment
78
Obiekt SBB (SBB Object) reprezentuje konkretną jednostkę SBB (SBB Entity). Obiekt
SBB moŜe wołać inny Obiekt SBB poprzez lokalny interfejs naleŜący do tego samego drzewa
jednostek SBB.
Rys. 31: Graf SBB (źródło JSR 240)
5.5.6 Activity, Activity Context
Zdarzenia, które mają podobne znaczenie grupowane są w tzw. Activity. Tak więc
moŜna obrazowo powiedzieć, iŜ Activity jest strumieniem powiązanych ze sobą znaczeniowo
zdarzeń. Activity reprezentuje określoną jednostkę SBB (SBB Entity), która jest
zainteresowana konkretnym zdarzeniem. Np. zgłoszenie (Call76) jest Activity. Activity Object
jest obiektem w znaczeniu języka Javy (dziedziczy z typu java.Object) reprezentującym i
posiadającym funkcje, które mogą być wołane na Activity. Acitivity znajduje się w warstwie
Resource Adapters (patrz Rys. 32).
Przykładem obiektu Activity jest na przykład JccCall, który reprezentuje zgłoszenie.
JccCall naleŜy do specyfikacji JCC w programie JAIN.
Activity Context reprezentuje przyporządkowany jemu Activity i znajduje się w warstwie
SLEE. Relacja pomiędzy Activity i Activity Context jest jeden do jednego. Jedną z
funkcjonalności Activity Context jest przechowywanie danych w postaci atrybutów. Z pomocą
Activity Context jednostki SBB (SBB-Entity) mogą pomiędzy sobą wymieniać dane i
komunikować się asynchronicznie. Jednostka SBB moŜe być podłączona do wielu Activity
Context.
76 Obiekt Call pochodzi ze specyfikacji JAIN API.
JAIN Service Logic Execution Environment
79
JSLEE oferuje dla Komponentów mechanizm publish/subscribe. Komponenty mogą się
rejestrować przy pomocy tego mechanizmu w Activity Context, w celu odbierania
interesujących je zdarzeń. NaleŜy w tym miejscu zauwaŜyć, Ŝe mechanizm publish/subcribe
róŜni się od mechanizmu listner/provider udostępnianego w języku Java. W mechanizmie
listener/provider strony, które są wzajemnie zainteresowane odbieraniem i generowaniem
zdarzeń znają się, poniewaŜ Listner musi zarejestrować się u konkretnego Providera. W
JSLEE komponent generujący zdarzenia i komponent nasłuchujący przychodzących zdarzeń
nie znają się wzajemnie. KaŜdy z nich rejestruje się w Activity Context deklarując jedynie
chęć odbierania konkretnego typu zdarzeń. Dzięki opisanemu mechanizmowi swobodnego
wiązania dwóch komponentów za pomocą zdarzeń istnie moŜliwość tworzenia systemów
rozproszonych zorientowanych zdarzeniowo.
Rys. 32: Activity Context i Activity. ZaleŜności u umiejscowienie w architekturze JSLEE
Na Rys. 33 została zaprezentowana przykładowa ścieŜka jaką przebywa zdarzenie w
architekturze JSLEE przy zestawianiu sesji komunikacyjnej SIP.
Wiadomość INVITE zostaje wygenerowana przez sieć i następnie zostaje
przechwycona przez SIP-Resource Adapter (SIP-RA). PoniewaŜ INVITE jest pierwszą
wiadomością w sekwencji zestawiania połączenia dla protokołu SIP, zostaje wytworzony
Activity Obiekt przez SIP-RA. SIP-RA przekazuje dalej zdarzenie związane z wiadomością
INVITE do routera zdarzeń. Router zdarzeń powołuje do Ŝycia Activity Context ze względu
na to, Ŝe jest pierwszy we wspomnianej sekwencji. Zdarzenie zostaje odebrane przez
zainteresowany nim SBB, który wcześniej zarejestrował się przy wykorzystaniu
ActivityContextInterface w Activity Context. SBB przetwarza zdarzenie zgodnie z
zaimplementowaną logiką, a następnie woła metodę SIP-RA z parametrem będącym
zdarzeniem-odpowiedzią. SIP-RA generuje następnie wiadomość „OK” do sieci.
JAIN Service Logic Execution Environment
80
Rys. 33: Przykładowa droga zdarzenia w JSLEE
5.5.7 Zdarzenia
Pojęcie zdarzenia jest jednym z istotniejszych w architekturze SLEE. Zdarzenie to
obiekt, który przenosi pewną informację z jednego elementu do innego znajdującego się w
SLEE. Jednym elementem, który moŜe zarówno generować jak i odpowiadać na zdarzenia
jest SBB, pozostałe komponenty jak Facility, Resource Adapters generują jedynie zdarzenia.
KaŜde zdarzenie jest reprezentowane przez Event Object - obiekt w znaczeniu języka
Java i posiada określony typ. Typ determinuje sposób przekazywania zdarzenia. SBB
rejestrują typy zdarzeń, którymi są zainteresowane po przez podłączenie się do
odpowiedniego Activity Context.
Zdarzenia są odbierane przez SBB i uruchomiają odpowiednie funkcje tzw. Handlers.
5.5.8 Profile, Tabele Profili i Specyfikacje Profili
Profile (Profile) udostępniają dane przechowywane w postaci atrybutów. W schemacie
profili określa się zbiór atrybutów i ich typy. Tabele Profili (Profile Table) natomiast
zawierają profile, które przynaleŜą do tego samego schematu. Specyfikacje Profili (Profile
Specification) definiują Interfejsy, zbiory klas i deskryptory rozmieszczenia (Deployment
Descriptors). Specyfikacje Profili moŜna określić jako typy, które mogą być wykorzystywane
przez wiele Tabeli Profili.
JAIN Service Logic Execution Environment
81
W JSLEE został juŜ zdefiniowany zbiór bazowych specyfikacji profili. Przykładową
specyfikacją profilu jest np.: „Resource Info Profile Specification“.
Eys. 34: ZaleŜności pomiędzy Specyfikacjami Profili, Tablicami Profili i Pro filami
5.5.9 Resource Adapters
Resource Adapters (RAs) jest kolejną koncepcją, która podobnie jak zdarzenia,
uniezaleŜnia SLEE od konkretnego protokołu sygnalizacyjnego, zbioru danych, urządzenia.
JSLEE moŜe dysponować dowolną liczbą RA i to jest istotna zaleta. Jeśli wystąpi potrzeba,
aŜeby JSLEE komunikował się z inną siecią naleŜy dopisać i zainstalować odpowiedni RA.
RAs konwertują specyficzne dla danego źródła wiadomości na określone typy zdarzeń i dalej
przekazują je do wszystkich zainteresowanych SBB. Zatem RA jest elementem, który
powinien być dostarczany przez dostawcę (providera) danego urządzenia, protokołu, zbioru
danych, poniewaŜ zna on najlepiej specyfikę swoich rozwiązań. Dodatkowo w SLEE naleŜy
stworzyć następujące elementy: Event Object, Event Type i Activity. Dzięki RAs usługi
napisane w JSLEE stają się niezaleŜne od rodzaju sieci i jak tylko to moŜliwe najlepiej
dopasowane do specyficznych dla danego dostawcy urządzeń.
Analizowana implementacja referencyjna JSLEE Mobicents dysponuje juŜ następującymi
RAs:
� SIP – RA
� Parlay - RA
� Diameter - RA
� Asterisk - RA
� XMPP - RA.
JAIN Service Logic Execution Environment
82
5.5.10 Opis konfiguracji usługi (Deploymnet Descriptor)
KaŜda usługa w JSLEE musi zostać opisana przez deskryptor (Deployment
Descriptor77,), analogicznie jak to jest w J2EE. Budowa przykładowego deskryptora została
przedstawiona na Rys. 35. Deskryptor ma określoną strukturę i jest dokumentem XML.
Definiuje on, gdzie powinny znajdować się poszczególne komponenty usługi w strukturze
katalogowej JSLEE. KaŜdy deskryptor zawiera zbiór elementów XML z róŜnymi
parametrami. Ze względu na duŜą złoŜoność deskryptora zostały opracowane narzędzia do ich
automatycznego generowania78.
Elementy XML opisujące komponenty usługi muszą zostać umieszczone w Deployable
Unit. Deployable Unit jest to archiwum Javy JAR. Składa się ono z następujących rzeczy:
� Deskryptorów:
o service-xml.xml;
o deployable-unit.xml;
� archiwów JAR.
Dokument service-xml.xml posiada element, który jest korzeniem dokumentu XML
(<service-xml> ) oraz zawiera Description-Element (<description> ) i inne Service-
Eelments (<service> ). Service-Element opisuje poszczególne usługi. Np. dla usługi
CallBlockingAndCallForwarding Service-Elements są to usługi CallBlocking i
CallForwarding.
Deployable-unit jest głównym deskryptorem, który opisuje wykorzystane w usłudze
komponenty takie jak (Typy Zdarzeń, specyfikacje Profili, SBBs). Deskryptor Deployable-
Unit znajduje się w katalogu META-INF i nazywa się deployable-unit.xml.
77 Autor pragnie zauwaŜyć, Ŝe krok ten jest jednym z trudniejszych dla początkujących, ze względu na konieczność dokładnej znajomości całej architektury oraz skojarzenia elementów deskryptora z rzeczywistymi elementami architektury. 78 Implementacja JSLEE - Mobicents dostarcza plug-in do środowiska Eclipse, który generuje automatycznie szkielet usługi oraz odpowiednie wpisy w Deployment Descriptor.
JAIN Service Logic Execution Environment
83
Rys. 35: Model Deployable-Unit.
5.6 Przykładowa usługa – Blokowanie połączeń
W ramach środowiska badawczego mają zostać zaimplementowane interfejsy Parlay X.
Blokowanie połączeń (Call Blocking) jest jedną z funkcji interfejsu Parlay X: Call Handling.
Ze względu na niestabilność i inne problemy związane z implementacją JSLEE (patrz
rozdział 10) autorzy postanowili zaimplementować interfejsy Parlay X z wykorzystaniem
JAIN SIP, a nie jak zakładano JSLEE. Jednak dla zobrazowania sposobu tworzenia aplikacji
JSLEE uznano za słuszne implementację choćby jednego z interfejsów Parlay X79.
Przedstawiony w kodzie źródłowym 3 Service Building Block: CallBlockingSBB
opakowuje całą logikę usługi blokowania połączeń, która realizuje:
� filtrowanie przychodzących połączeń;
� automatyczne kończenie niepoŜądanych połączeń.
Rdzeń SBB tworzy metoda onCallDeliveryEvent (patrz kod źródłowy 1), która
zajmuje się przetwarzaniem przychodzących zdarzeń. Metoda ta otrzymuje dwa parametry:
� obiekt typu JccConnectionEvent (właściwe zdarzenie)
� ActivityContextInterface .
Obiekt JccConnection reprezentuje połączenie telefoniczne. Pochodzi ze specyfikacji
JCC – Java Call Control [38]. ActivityContextInterface nie jest wykorzystywany w tym
przykładzie.
79 Implementacja dokonana na przykładzie zaczerpniętym z [14].
JAIN Service Logic Execution Environment
84
Metoda onCallDeliveryEvent sprawdza, czy zdarzenie reprezentuje przychodzące
zgłoszenie (filtruje zdarzenia na podstawie typu wiadomości i wybiera jedynie wiadomości
INVITE). W przypadku zdarzenia zawierającego inną wiadomości SIP niŜ INVITE metoda
natychmiast kończy swoje działanie, gdyŜ blokowane ma być jedynie połączenie
przychodzące. Realizowane jest to po przez porównanie URI źródła z nagłówka From z
wywoływanym numerem.
W dalszej kolejności zostaje załadowana lista z niepoŜądanymi numerami. Znajduje
się ona w Profilu.
Jeśli numer dzwoniącego jest obecny na liście, zgłoszenie to jest natychmiast kończone,
po przez metodę connectionrelease .
Teraz muszą zostać przygotowane metody odpowiedzialne za funkcjonowanie usługi
w kontenerze, podobnie jak w J2EE. Z tego powodu aplikacja musi implementować interfejs
javax.slee.Sbb , którego metody będą wołane przez kontener w odpowiednich momentach
cyklu Ŝyciowego usługi (patrz kod źródłowy 2).
W metodzie setSbbContext , która znajduje się w kodzie źródłowym 2 zostaje
zapisana jedna z referencji przekazanych przez kontener SLEE. W tym przypadku
SbbContext jest dla SBB interfejsem do środowiska wykonawczego SLEE.
Metoda sbbCreate() jest wywoływana przez kontener w przypadku, gdy potrzeba
przetworzyć przychodzące zdarzenia przez SBB. Kontener pobiera wówczas SBB z Puli SBB
(tzw. SBBs Pool) i woła na nim tą metodę. W tym przykładzie SBB sięga po przez JNDI do
jednej z usług oferowanych przez Framework mianowicie ProfileFacility. Tak jak to juŜ
wcześniej zostało omówione, Profile pozwalają na dostęp do specyficznych dla usługi
danych. W przypadku rozpatrywanej usługi jest to numer dzwoniącego.
Z kodu źródłowego 1 i kodu źródłowego 2 został złoŜony kompletny SBB, realizujący
usługę blokowania połączeń. Kod tego SBB znajduje się w kodzie źródłowym 3.
SBB jest zadeklarowany jako klasa abstrakcyjna, dlatego kontener JSLEE moŜe
dynamicznie uzupełnić SBB o funkcje słuŜące do połączenia się ze środowiskiem
wykonawczym tzw. Runtime Environment.
JAIN Service Logic Execution Environment
85
Kod Źródłowy 1: Przetwarzanie zdarzenia
// Logika usługowa odpowiedzialna za przetwarzanie zdarzenia
public void onCallDeliveryEvent(JccConnectionEvent event,
ActivityContextInterface aci)
{
JccConnection connection = event.getConnection();
try
{
// Sprawdzenie, Ŝe zgłosznie jest przychodz ące
String address = connection.getAddress().getName( );
JccAddress source = connection.getOriginatingAddr ess();
if (source != null && source.getName().equals(add ress)){
return;
}
// Czytanie numerów dla usługi callblocking z pro fli
ProfileID id = profileFacility.getProfileID( ... )
CallBlockingAddressProfileCMP profile = getProfi le(id);
Address[] blocked = profile.getBlockedAddresses() ;
// Sprawdzenie listy numerów i ewentualne zablkow anie zgłoszzenia.
Boolean block = false;
for (int i = 0; i < blocked.length && !block; i++ )
{
block = (blocked[i] != null && blocked[i].getAdd ressString().
equals(source.getName()));
}
if (block) {
connection.release(JccEvent.CAUSE_DEST_NOT_OBTAI NABLE);
}
} catch (Exception e) { ... }
finally { ... }
}
Kod źródłowy 2: Funkcje związane z cyklem Ŝyciowym usługi
public void setSbbContext(SbbContext context)
{
this.context = context;
}
public void unsetSbbContext() {
context = null;
}
public void sbbCreate() throws CreateException
{
try {
Context facilities = (Context) new InitialContext ().
lookup("java:comp/env/slee/facilities");
profileFacility = (ProfileFacility) facilities.lo okup("profile");
}
catch (NamingException ne)
JAIN Service Logic Execution Environment
86
{
throw new CreateException("facility not available ", ne);
}
}
public void sbbPostCreate() {}
public void sbbActivate() {}
public void sbbPassivate() {}
public void sbbLoad() {}
public void sbbStore() {}
public void sbbRemove() {}
public void sbbExceptionThrown(Exception exception, Object
ActivityContextInterface aci) {}
public void sbbRolledBack(RolledBackContext context ) {}
Kod źródłowy 3: Klasa SBB-CallBlocking
public abstract class CallBlockingSbb implements Sb b
{
private SbbContext context;
private ProfileFacility profileFacility;
// SBB-Funkcje zwi ązane z cyklem Ŝyciwoym usługi (Kod źródłowy 2) ...
// Logika usługowa przetwarzaj ąca zdarzenia (Kod źródłowy 1) ...
}
6. Rola wolnego oprogramowania w tworzeniu usług
telekomunikacyjnych
6.1 Wstęp
Za początek idei wolnego oprogramowania moŜna przyjąć powstanie organizacji Free
Software Foundation (FSF). ZałoŜyciel tej organizacji, Richard Stallman, wprowadził pojęcie
wolnego oprogramowania (z ang. free software), w rozumieniu, którego dane
oprogramowanie moŜe zostać uznane za wolne, jeśli udostępnia pełne prawa do: jego
uŜytkowania w dowolnym celu, modyfikacji, kopiowania i rozpowszechniania. Działalność
FSF skupia się głównie na aspekcie etycznym, a za swoich oponentów uznaje organizacje,
firmy, które licencjonują wytwarzane oprogramowanie. Zupełnie inne podejście do tej idei
wyznają załoŜyciele Open Source Initative (OSI). Chcą wskazać, iŜ otwarte80
oprogramowanie moŜe nieść ze sobą istotne korzyści praktyczne, które mogą równieŜ
zainteresować i zaangaŜować duŜe firmy komercyjne. OSI promuje termin „open source” w
rozumieniu, którego, wolne oprogramowanie jest środkiem wspomagającym i kształtującym
rozwój techniczny, ze względu na fakt, iŜ kaŜdy ma moŜliwość włączyć się w ten proces –
kod jest ogólnie dostępny, czyli „otwarty” dla wszystkich81.
Podczas dotychczasowej działalności obydwu nurtów wolnego i otwartego
oprogramowania powstało wiele inicjatyw, które stały się punktem wyjścia dla nowych
projektów, czy teŜ substytutami dla rozwiązań komercyjnych. Do najbardziej znanych naleŜą
w kategorii systemów operacyjnych: Linux, FreeBSD, w kategorii oprogramowania
biurowego: Open Office, w kategorii serwerów: Apache, Tomcat, BIND, a w kategorii
języków programowania: PHP, Perl oraz Pyton.
Od dłuŜszego czasu aplikacje open source zaczynają odgrywać coraz większą rolę w
zastosowaniach telekomunikacyjnych. Jest to rezultat dwóch czynników:
� pojawienie się koncepcji sieci NGN, czyli sieci telekomunikacyjnej całkowicie opartej o
protokół IP, wprowadzenie róŜnych API udostępniających w sposób abstrakcyjny
funkcje sieci, co daje moŜliwość uŜywania powszechnie stosowanych narzędzi
80 Terminy „wolne” (free software) i „otwarty kod” (open source) wywodzą się z róŜnych nurtów (FSF, OSI), ale są w tym kontekście toŜsame. 81 Warto wspomnieć, iŜ kwestia kopiowania oprogramowania została przemilczana w definicji „open source”.
Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych
88
programistycznych, języków programowania, rozwiązań IT, etc.., z których potrafi
korzystać znacznie szersza społeczność.
� niektóre projekty open source są na tyle dojrzałe i dopracowane, Ŝe mogą spełnić
wymagania, jakie stawia środowisko telekomunikacyjne (aspekty bezpieczeństwa,
wydajności, niezawodności). Jako przykład moŜna wskazać np. Linux, w
szczególności jego inicjatywa OSDL-CGL (Open Source Development Labs Carrier
Grade Linux).
Zastosowanie open source w telekomunikacji niesie szereg korzyści:
� umoŜliwia obniŜenie kosztów w wyniku zastąpienia komercyjnych dedykowanych
rozwiązań wolnym oprogramowaniem (np. Linux). Operator nie musi się wiązać z
dostawcą sprzętu. Do rozbudowy i utrzymania moŜe zatrudnić konkurencyjne firmy.
� umoŜliwia budowę prototypów i ich testowanie niskim kosztem, dzięki zaangaŜowaniu
szerokiej społeczności programistów. Przykładem mogą być projekty: Mobicents,
Open IMS Core.
� pozwala tworzyć złoŜone systemy wykorzystujące gotowe rozwiązania open source.
Przykładem moŜe być zastosowanie serwera SER w komercyjnych softswitch.
Obecnie powstaje wiele inicjatyw tzw. „.org Players”, które promują zastosowanie
wolnego oprogramowania w telekomunikacji. Do ich grona moŜna zaliczyć m.in.: OSDL-
CGL, Communications Platforms Trade Association (CP-TA), PCI Industrial Computer
Manufacturers Group (PICMG), SCOPE Alliance, Service Availability Forum (SA Forum),
etc..
6.2 Linux w zastosowaniach telekomunikacyjnych
Linux jest dobrym przykładem na bazie, którego moŜna przedstawić generyczny cykl
Ŝycia wolnego oprogramowania w zastosowaniach operatorskich. Początkowo Linux był
wykorzystywany wyłącznie do świadczenia usług, które nie były krytyczne dla działania
biznesu (np. obliczenia uŜytkowe, OS dla serwera WWW, FTP, itp..). W momencie
pojawienia się koncepcji NGN (softswitch, bramy medialne, itp..) oraz wzrostu stabilności
Linux-a, zaczęto go stosować do zadań o charakterze krytycznym, wymagających duŜej
wydajności, niezawodności i bezpieczeństwa. Coraz większe zainteresowanie ze strony
operatorów i dostawców sprzętu przyczyniło się do powstania inicjatyw, które pracują nad
rozwojem takich cech Linux-a, które są istotne w zastosowaniach telekomunikacyjnych.
Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych
89
Przykładem takiej działalności jest OSDL-CGL, która rozwija i testuje system Linux pod
względem zapewnienia kompatybilności i wydajności.
6.3 Open Source JSLEE – Mobicents
Mobicents jest implementacją referencyjną JSLEE 1.0 NaleŜy do grupy czterech
certyfikowanych przez SUN platform JSLEE (patrz Tabela 4). Jest to projekt open source,
którego jednym z celi jest stworzenie Open Source IMS. Aktualnie został przeniesiony przez
jego twórcę Ivelina Ivanov do struktur JBOSS, co przyspieszyło jego rozwój. W projekt
zaangaŜowani są przedstawiciele branŜy telekomunikacyjnej m.in. NIST, Open Cloud,
Alcatel Lucent, etc.. oraz grupa indywidualnych programistów.
Tabela 4 Istniejące implementacje referencyjne JSLEE
Implementacja Utrzymanie Informacje
JAIN SLEE Reference Implementation
Sun Mikrosystem
Projekt open source. Rozwijany przez Open Cloud na bazie Implementacji referencyjnej platformy J2EE w wersji 1.3.
http://java.sun.com/proudcts/jslee/1.0/
Rihno Open Cloud Komercyjny produkt. Open Cloud uczestniczył przy rozwoju specyfikacji JSLEE i efektem tych prac jest równieŜ ta platforma.
www.opencloud.com/slee/intro.html
Open Convergent Feature Server (OCFS)
jNetX Komercyjny produkt. OCFS wspiera oprócz standardu JSLEE równieŜ interfejsy dla Parlay.
http://www.jnetx.com/index.php?id=ocfs
Mobicents Project Rozwijany Projekt open source. Implementacja referencyjna JSLEE bazująca na Boss.
http://www.mobicents.org
Ze względu na fakt, iŜ cześć standaryzacji JSLEE opiera się na standaryzacji J2EE
twórcy skorzystali z gotowych juŜ elementów zaimplementowanych na potrzeby platform
JBoss w wersji 3.2.x82.
82 Z JBoss został wykorzystany m.in. Mikrokontroler JMX (Java Managment Extension), JNDI (Java Naming and Directory Interface) dla rejestracji usług w SLEE, JTA (Java Transaction API) realizujący zarządzanie transakcjami oraz TreeCache – mechanizm odpowiedzialny za replikację stanów. Z rdzenia serwera aplikacyjnego JBoss został usunięty JMS (Java Message Service) i na nowo zaimplementowany kluczowy mechanizm do routingu zdarzeń.
Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych
90
Projekt Mobicents oprócz implementacji rdzenia JSLEE obejmuje równieŜ
implementację:
� Resource Adaptors (RAs). Do tej pory zostały zaimplementowane m.in. SIP RA –
wykorzystujący JAIN SIP, XMPP/Google Talk RA – stworzony na bazie biblioteki
Smack, Asterisk RA – wykorzystujący bibliotekę Asterisk-Java, Java Call Control
RA, Diameter RA, etc ..
� narzędzi do zarządzania serwerem aplikacyjnym. Jednym z nich jest Mobicents
Manager, który oferuje graficzny interfejs w postaci WWW do
instalowania/deinstalowywania, uruchamiania i monitorowania usług;
� środowiska programistycznego (IDE) o nazwie EclipSLEE wspomagającego pisanie
aplikacji JSLEE w postaci wtyczki do programu Eclipse. EclipSLEE ułatwia
stworzenie wszystkich elementów wymaganych do prawidłowego funkcjonowania
usługi w JSLEE m.in. SBB, Deployment Descriptor, zdarzeń i ich typów,
specyfikacji profili, etc..
Architektura Mobicents pokrywa się z architekturą JSLEE i szczegółowo została
omówiona w rozdziale 1.
Próby wykorzystania Mobicents do implementacji środowiska badawczego na potrzeby
tej pracy okazały się nieudane, gdyŜ serwer działał niestabilnie, a wiele rzeczy wymaganych
przy tworzeniu aplikacji pozostawało tajemnicą tylko twórców projektu. Na potrzeby tego
opracowania została zaprojektowana prosta aplikacja, której celem była analiza procesu
implementacji aplikacji JSLEE oraz poznanie środowiska uruchamiania usług
charakterystycznego dla Mobicents.
Krytyczna analiza tego projektu została przedstawiona we wstępie do rozdziału 10.
6.4 Open SIP Express Router
Open SIP Express Router (Open SER) jest projektem, którego celem jest stworzenie i
rozwijanie w pełni skalowalnego serwera SIP. Open SER wywodzi się z projektu SER, który
został rozpoczęty w 2001 roku pod auspicjami instytutu Frauthofer FOKUS83, a następnie był
83 FOKUS (Fraunhofer Institut für Offene Kommunikationssysteme) jest niemieckim instytutem badawczym zajmującym się opracowywaniem, analizą i implementacją prototypów systemów komunikacyjnych. Główe dziedziny które są w zainteresowaniach FOKUS to: infrastruktura sieci mobilnej w modelu powyŜej 3G oraz środowiska sieci sensorowych (Ambient Intelligencee).
Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych
91
rozwijany razem z firmą Iptelorg84, która wykorzystywała SER do świadczenia komercyjnych
usług. Ze względu na niejasności związane z licencjonowaniem SER, część twórców
odłączyła się i rozpoczęła „bliźniaczy” projekt o nazwie Open SER. Obecnie SER i Open SER
są udostępniane na bazie licencji GPL85, ale prace nad nimi toczą się oddzielnie.
Architektura Open SER jest przedstawiona na Rys. 36. Serwer złoŜony jest z systemu
rdzeniowego, który zapewnia podstawowe funkcje związane z analizą składni wiadomości
SIP oraz odpowiednim ich kierowaniem zgodnym z RFC 3261 [22]. Rdzeń udostępnia
interfejs programistyczny (API), z którego korzystają moduły rozszerzające funkcje. Całość
jest sterowana przez podsystem zarządzania, odpowiedzialny za powoływanie wielu instancji
serwera i rozkładanie pomiędzy nimi ruchu.
Rys. 36: Architektura serwera Open SER
Modularna budowa umoŜliwia dobranie konfiguracji Open SER dostosowanej do
funkcji, jaką będzie pełnił w sieci (powoduje to optymalne wykorzystanie zasobów). W
zaleŜności od tej konfiguracji serwer moŜe pełnić funkcje takie jak: serwer pośredniczący (z
ang. Proxy), serwer rejestru (z ang. Registrar) albo serwer przekierowujący (z ang. Redirect
Server). Innym rezultatem modularnej budowy jest moŜliwość rozwijania rozszerzeń w
sposób niezaleŜny od siebie i przez szeroką grupę programistów86. Przykładowe moduły to:
ENUM (umoŜliwia korzystanie z systemu DNS do translacji numerów telefonicznych na
adresacje SIP), ACC (opowiada za generowanie rekordów taryfikacyjnych CDR), CPL-C
84 Iptelorg jest obecnie częścią firmy Tekelec. 85 GPL (GNU General Public License) jetst umową licencyjną zakładającą otwartość udostępnianego oprogramowania (open source). 86 KaŜdy moŜe stworzyć moduł i opublikować go na stronie projektu. Jeśli przejdzie on testy zostanie włączony do oficjalnego wydania.
Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych
92
(interpretuje skrypty CPL), AUTH_DIAMETER (daje moŜliwość uwierzytelnienia z
wykorzystaniem zewnętrznego serwera AAA) oraz PRESENCE (implementuje serwer
obecności)87.
Jednym z głównych celów przyświecających projektowi jest budowa jak najbardziej
optymalnego (pod względem wykorzystania zasobów komputera) rozwiązania. Open SER jest
implementowany w C i moŜe być uruchomiony na systemach operacyjnych z rodziny UNIX
(np. Linux, BSD, Solaris). W implementacji jest stosowanych szereg specjalnych
mechanizmów mających na celu zminimalizowanie wykorzystania pamięci oraz mocy
obliczeniowej procesora. Przykład mechanizmu kontroli analizy składni wiadomości SIP
pokazuje Rys. 37.
Rys. 37: Mechanizm optymalizacji analizy składni wiadomości SIP
Polega on na analizowaniu tylko tych fragmentów wiadomości, które są wymagane w
obsłudze. Na Rys. 37 pokazany jest scenariusz, w którym moduł rozszerzenia odczytuje
wartość nagłówka z wiadomość (poprzez API). Kontroler zaimplementowany w rdzeniu
serwera sprawdza, czy Ŝądany nagłówek został juŜ odczytany (np. przez inny moduł), jeśli tak
to zwraca go, jeśli nie to przeprowadza analizę składni wiadomości do momentu jego
znalezienia. Dzięki temu mechanizmowi wiadomości SIP są odczytywane tylko w takim
zakresie, jaki wymaga tego dynamiczny kontekst obsługi.
6.5 Asterisk
Asterisk88 jest w pełni funkcjonalną centralką telefoniczną IP tzw. IP PBX (Private
Branch Exchange). Pomysłodawcą i twórcą tego rozwiązania był Mark Spencer89. Projekt
87 W wersji 1.2 oficjalne wydanie Open SER posiada 67 modułów. 88 Strona WWW projektu: www.asterisk.org.
Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych
93
został napisany w języku C i początkowo był przeznaczony pod system Linux, jednak
aktualnie powstały odmiany działające na większości systemów operacyjnych90. Kod
źródłowy jest udostępniany na podwójnej licencji, która obejmuje licencje GPL (kod
centralki) oraz licencje właściwe dla stosowanych w nim opatentowanych rozwiązań (np. dla
kodeka G.729).
Asterisk obsługuje szereg protokołów sygnalizacyjnych:
� w sieci IP: SIP, H.323, MGCP, protokół CISCO SCCP oraz zaprojektowany na
potrzeby komunikacji z centralką Asterisk protokół Inter Exchange Asterisk91 tzw.
IAX;
� w sieciach TDM: SS7 i DSS1.
Protokół IAX powstał w odpowiedzi na trudności, jakie występowały przy stosowaniu
protokołu SIP, czy teŜ H.323. Mowa tu o problemach z serwerami Network Address
Translation, czy Firewall. IAX jest protokołem binarnym przenoszącym sygnalizację oraz
media. Mechanizmy zastosowane w protokole IAX rozwiązują problemy NAT oraz Firewall.
Protokół umoŜliwia transport dowolnej liczby strumieni medialnych, które mogą być
kodowane przy uŜyciu większości istniejących kodeków92. Ponadto protokół został
wyposaŜony w mechanizmy pozwalające minimalizować wykorzystywane pasmo. W
przypadku, gdy w ramach danego połączenia realizowane jest klika strumieni mediów IAX
umoŜliwia multipleksację strumieni i kompresję nagłówków.
Komunikacja z siecią TDM realizowana jest przy pomocy kart PCI, które mogą być
wyposaŜone w róŜne interfejsy np. E1, T1, 4xE1, FXS, FXO etc.. Wówczas, gdy powstawał
Asterisk karty tego typu były drogie, poniewaŜ standardowo miały wbudowany procesory
DSP. Projektanci postanowili obniŜyć całkowity koszt centralki, poprzez realizację obróbki
89 Patrząc na historię Asterisk’a idealnie sprawdza się powiedzenie, Ŝe potrzeba jest matką wynalazku. Pod koniec lat 90 Mark Spencer chciał załoŜyć swoją firmę, która oferowałby pomoc dla uŜytkowników systemu Linux. AŜeby sprawnie obsługiwać klientów potrzebował centrali PBX. Takie kosztowały krocie. Spencer zaczął, więc eksperymentować na komputerze z kartą PCI podłączoną do sieci telefonicznej. Gdy zobaczył, jaki potencjał tkwi w takim podejściu postanowił stworzyć własną centralkę IP PBX. Aktualnie prowadzi firmę Digium, która zajmuje się rozwojem projektu i sprzętu potrzebnego do podłączenia Asteriska do sieci TDM. 90 Powstała nawet kompilacja (asterisk@home) działająca pod systemem Windows, której instalacja i konfiguracja wymaga minimalnych umiejętności. 91 Protokół IAX. 92 G.729, G.711u, G.711a, G.726, G.723.1. Nowy kodek moŜe zostać w łatwy sposób zainstalowany jako dodatkowy moduł.
Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych
94
sygnału programowo, a nie na kartach TDM. Dzięki temu podejściu mogła zwiększyć się
liczba potencjalnych uŜytkowników93.
Rys. 1: Architektura centralki Asterisk
Asterisk posiada architekturę złoŜoną z modułów (patrz Rys. 1). Struktura modułowa
pozwala pogrupować podobne funkcje w jednym bloku, dzięki czemu projekt staje się
przejrzysty i łatwy w rozbudowie. Modułem startowym jest Dynamic Module Loader, który
po uruchomieniu ładuje i inicjalizuje pozostałe moduły oraz wymagane sterowniki.
Komutacja połączeń przychodzących z róŜnych interfejsów realizowana jest w PBX
Switching Core. KaŜde połączenie obsługiwane jest według pewnego algorytmu zapisanego z
uŜyciem dedykowanego języka skryptowego, w którym mogą być wywoływane inne
aplikacje (np. playaudio, dial, hangup, etc..). Aplikacje te są uruchamiane i sterowane przez
Application Launcher. Codec Translator realizuje translację połączeń wykorzystujących
róŜne kodeki.
Asterisk udostępnia cztery rodzaje API:
� Channel API. Channel API abstrahuje głównie funkcjonalność PBX Switching Core.
Za pomocą tego API moŜna komutować połączenia realizowane przy pomocy
róŜnych technik (np. TDM, SIP, H.323, IAX) w jednorodny sposób. Źródło sygnału
cyfrowego lub analogowego pochodzące z karty TDM traktowane jest jako
93 Aktualnie ze względu na spadek cen sprzętu powraca się do obróbki mediów z wykorzystaniem procesorów DSP.
Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych
95
urządzenie wirtualne TDM, którego funkcje DSP zostały zaimplementowane
programowo.
� Codec Translator API. Codec Translator API udostępnia prosty interfejs za pomocą,
którego dokonywane jest transkodowanie róŜnego rodzaju strumieni mediów.
Konwersja moŜe odbywać się pomiędzy następującymi formatami: GSM, G.723,
ADPCM, G.711, G.729.
� File Format API . File Format API pozwala na odtwarzanie i nagrywanie dźwięków w
róŜnych formatach m.in. WAV, AU, MP3, etc... Dzięki temu tworzone aplikacje dla
Asterisk są bardziej elastyczne. Sygnały marszrutowania, DTMF, dzwonienia mogą
być zapisane w róŜnych formatach.
� Application API . Application API udostępnia interfejs do podstawowych funkcji
oferowanych przez Asterisk, jak i równieŜ do funkcjonalności dostarczanej przez
dodatkowe aplikacje, które mają charakter modułów. Jednym z waŜniejszych
interfejsów aplikacyjnych jest AGI – Application Gateway Interface, który pozwala
tworzyć aplikacje/moduły w innych językach np. Java, Perl, C, …
WaŜnym pojęciem w architekturze Asterisk są interfejsy i kanały. W terminologii
Asterisk wszystkie połączenia przychodzą i wychodzą na specyficznych interfejsach. Nazwy
ich pochodzą od obsługiwanych protokołów, czy technik np. SIP, ZAP (dla TDM) natomiast
wszelkiego typu operacje na konkretnym połączeniu to operacje na specyficznym dla danego
interfejsu kanale (channel). Przychodzące połączenia obsługiwane są zgodnie z wcześniej
skonstruowaną logiką zapisaną przy pomocy dedykowanego języka skryptowego jako tzw.
dial plan. Implementacja kaŜdego z interfejsów znajduje się w module chan_xxx.so.
Funkcjonalność oferowana przez Asterisk realizowana jest za pomocą odrębnych
aplikacji, które tworzone są jako moduły. Przykładowymi aplikacjami są: ADSI On-Screen
Menu System, Authentication, Blacklists, Blind Transfer, Call Forward on Busy/No Answer,
Call Parking, Call Queuing, Call Recording, Conference Bridging, Database Integration,
E911, ENUM, Interactive Voice Response (IVR), SMS Messaging, etc..
Asterisk udostępnia pseudo środowisko do kreacji usług. Usługi mogą być tworzone
przy pomocy następujących mechanizmów:
� dial plan – jest to algorytm przetwarzania zgłoszenia napisany w dedykowanym języku
skryptowym. Język ten umoŜliwia korzystanie z funkcji udostępnianych przez
zainstalowane moduły (np.: dial, voicemail, gotoif, playaudio, etc..).
Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych
96
� AGI (Asterisk Gateway Interfejs) – interfejs przy pomocy, którego moŜemy pisać
zewnętrzne aplikacje wywoływane w dial plan z uŜyciem róŜnych języków np.
C/C++, Java, Perl
� MAPI (Manager API) – protokół do sterowania Asterisk oraz odbierania zdarzeń
(event) pojawiających się w centrali za pomocą połączenia sieciowego.
� Moduły – zawansowany sposób rozbudowy Asterisk. UmoŜliwia tworzenie
dodatkowych modułów w języku C z wykorzystaniem funkcji udostępnianych przez
rdzeniowe biblioteki Asterisk.
6.6 Open IMS Core
Podobnie jak wspomniany wcześniej SER, Open IMS Core jest projektem realizowany
przez instytut Frauthofer FOKUS. Jego celem jest budowa w pełni funkcjonalnej rdzeniowej
części systemu IMS. Projekt został rozpoczęty w 2004 roku, a pierwsza wersja została
udostępniona 2 lata później. Wszystkie elementy Open IMS Core są dostępne pod licencją
GPL.
Elementy systemu są pokazane na Rys. 38 i są to:
� serwer HSS – Jest implementowany w języku Java z wykorzystaniem serwera Apache-
Tomcat94.
� serwery CSCF - Są to serwery SER z dodatkowymi rozszerzeniami zapewniające
funkcje związane ze środowiskiem systemu IMS.
94 Apache-Tomcat jest serwerem aplikacyjnym implementującym architekturę ‘http-Servlet’
Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych
97
Rys. 38: Architektura i składniki projektu Open IMS Core (źródło http://www.openimscore.org/)
W załoŜeniach twórców projektu, Open IMS Core powinien skupić wokół siebie
środowisko programistów, którzy będą go rozwijali zgodnie z ideą „open-source”, budując w
ten sposób system umoŜliwiający nie tylko testy rozwiązań IMS, ale system, który będzie
mógł być z sukcesem stosowany w komercyjnych rozwiązaniach.
7. Specyfikacja problemu i cele analizy
Zaproponowana przez 3GPP nowa architektura usługowa IMS została zaadoptowana
przez ETSI [17] i ITU [35] jako rdzeniowy element architektury NGN. Zmiana modelu sieci
(z sieci z komutacją łączy na sieci pakietową) implikuje konieczność zastosowania innych
technologii realizacji usług. Wynikają z tego nowe moŜliwości, szczególnie związane ze
zwiększonym zakresem funkcji sieci, które mogą być wykorzystywane w projektowaniu.
Jednym z celów tego opracowania jest zarówno pokazanie jak model usługowy IMS
aktualizuje i dostosowuje znane juŜ koncepcje takie jak Parlay do sieci NGN, jak i pokazanie,
jakie są nowe (np. JSLEE) moŜliwości związane z zastosowaniem protokołu IP, SIP i
otwartych technik programistycznych (z duŜym naciskiem na rozwiązania typu „open-
source”) w tworzeniu usług.
Istotnym faktem, mającym wpływ na duŜą elastyczność w wyborze metod
implementacji oraz w projektowaniu usług jest to, Ŝe zakres standaryzacji IMS zostawia
pewnego rodzaju „przestrzeń” nie specyfikując środowiska do uruchamiania usług ani
komponentów aplikacyjnych. Rys. 39 pokazuje elementy, które zostały objęte standaryzacją.
Jak moŜna zauwaŜyć serwery aplikacyjne, które tworzą warstwę usług, pozostają poza
zakresem prac 3GPP95.
Projektant środowiska aplikacyjnego, które jest budowane z wykorzystaniem IMS,
moŜe skorzystać z juŜ istniejących propozycji róŜnych grup i inicjatyw, chociaŜby takich jak
JAIN (np. środowisko JSLEE omówione w rozdziale 5) czy Parlay, albo moŜe zdefiniować
własne środowisko wybierając z pośród róŜnych propozycji to, co najlepiej pasuje do
planowanych zastosowań96.
95 Zestandaryzowane jest styk pomiędzy AS, a CSCF, który oparty jest o protokół SIP i ma charakter czysto „połączeniowy” tzn. nie definiuje Ŝadnych funkcji związanych z usługami, które mogłyby być realizowane na serwerach aplikacyjnych. 96 Zalety i wady róŜnych technik programistycznych w IMS są szeroko omówione w [13].
Specyfikacja problemu i cele analizy
100
Rys. 39: Zakres standaryzacji w IMS
Z jednej strony ta dowolność w wyborze daje duŜą elastyczność, ale z drugiej brak
jednej referencyjnej architektury warstwy aplikacyjnej wymaga od projektanta głębokiej
analizy zasadności uŜycia danych rozwiązań. Jest to utrudnione ze względu na fakt, Ŝe
implementacje w środowiskach zgodnych z koncepcjami NGN są obecne w praktyce od
stosunkowo niedawna i nie ma jeszcze wypracowanych tzw. „dobrych praktyk” w tego typu
podejściu.
Inną waŜną kwestią, która została poddana analizie jest dekompozycja warstwy
aplikacyjnej IMS na warstwę komponentów usługowych i warstwę logiki usług. Rys. 40
pokazuje wzajemne relacje pomiędzy elementami realizującymi usługi końcowe, a
komponentami, które mogą być wielokrotnie wykorzystywane w róŜnych scenariuszach
usługowych.
Specyfikacja problemu i cele analizy
101
Rys. 40: Dekompozycja warstwy aplikacyjnej IMS
Normy definiujące IMS [4] nie precyzują kształtu warstwy aplikacyjnej, a model
architektury przedstawiony na Rys. 40 jest propozycją wynikającą z roŜnych prac spoza
głównego standardu 3GPP. W tym opracowaniu zostanie poddany analizie model opracowany
w ramach Parlay Group, w którym aplikacje realizujące scenariusze usług korzystają z sieci
(a w szczególności z sieci IMS) za pośrednictwem abstrakcyjnego API (Parlay X API),
uogólniającego funkcje niŜszego poziomu.
Podsumowując, najwaŜniejszymi celami tego opracowania są:
� Analiza modelu sterowania usługami zaproponowanego w IMS. Określenie jak
mechanizmy protokołu SIP są wykorzystywane do budowy modelu usługowego,
jakie są korzyści i negatywne strony związane z jego zastosowaniem oraz jakie są
moŜliwości optymalizacji.
Szczegółowej analizie zostaną poddane:
o mechanizmy sterowania usługami oparte o tzw. filtracje wiadomości SIP i
federacje serwerów aplikacyjnych;
o mechanizmy zarządzania mobilnością;
o mechanizmy wspomagające interakcje pomiędzy róŜnymi usługami
realizowanymi w środowisku serwera aplikacyjnego.
� Analiza dekompozycji warstwy aplikacyjnej IMS jako sposobu na optymalizacje
procesu tworzenia usług. Określenie jak wygląda model implementacji usług w
środowisku dwu warstwowym (warstwa komponentów aplikacyjnych i warstwa
Specyfikacja problemu i cele analizy
102
aplikacji) na przykładzie Parlay X i JSLEE. Jakie są korzyści i jakie ograniczenia
przy takim podejściu.
Szczegółowej analizie zostaną poddane:
o komponenty usługowe (sterowanie połączeniami przez trzecią stronę,
obecność, obsługa połączeń, dostępność terminala, scentralizowana ksiąŜka
adresowa) zdefiniowane w ramach Parlay X i ich odzwierciedlenie w
implementacji na bazie serwerów aplikacyjnych i protokołu SIP w środowisku
IMS;
o modele implementacji usług przy zastosowaniu jednego serwera aplikacyjnego
(bez wyróŜnienia warstwy komponentów aplikacyjnych) na przykładzie
architektury JSLEE.
� Analiza implementacji usług w róŜnych modelach programistycznych. Określenie
jak róŜne modele programistyczne wpływają na proces tworzenia usług.
Szczegółowej analizie zostaną poddane:
o technika wykorzystująca interfejsy programistyczne zdefiniowane w ramach
inicjatywy JAIN (a w szczególności JAIN SIP);
o architektura środowiska implementacji i uruchamiania aplikacji JSLEE;
o implementacja usług wykorzystująca interfejsy programistyczne realizowane
za pomocą serwisów sieciowych (Web Services) opartych o protokół SOAP.
� Analiza moŜliwości wykorzystania rozwiązań „ open-source” w telekomunikacji.
Ocena jak oprogramowanie typu „open source” wpływa na rozwój współczesnej
telekomunikacji, jakie są kierunki zmian i potencjalne korzyści.
Szczegółowo zostaną omówione projekty:
o JAIN i JSLEE
o Asterisk PBX
o Open Sip Express Router
o Opens IMS Core
8. Architektura środowiska badawczego
Na potrzeby realizacji celów analizy, które zostały opisane w rozdziale 1, powstało
dedykowane środowisko badawcze. Składnikami tego środowiska są elementy, które stanowią
implementacje modelu budowy usług telekomunikacyjnych, zaproponowanego w standardach
opisujących IMS oraz modelu zdefiniowanego w ramach prac grupy Parlay. Odwzorowanie w
środowisku elementów funkcjonalnych IMS/Parlay ma zakres zawęŜony tylko do procedur i
interfejsów niezbędnych do realizacji badanego modelu usługowego oraz do analizy
załoŜonych scenariuszy dla konkretnych mechanizmów usługowych, które są przedmiotem
badań.
Rys. 41 przedstawia architekturę systemu. Zaznaczone są na nim zarówno logiczne
elementy funkcjonalne IMS/Parlay, jak i fizyczna realizacja, bazująca na rozwiązaniach typu
open source i komponentach implementowanych specjalnie na potrzeby tego opracowania
(zaznaczone kolorem zielonym). Zgodnie z modelami IMS i Parlay, zbudowany system
moŜna poddać dekompozycji na cztery warstwy, w których mają miejsce poszczególne fazy
realizacji usługi telekomunikacyjnej.
Warstwę urządzeń końcowych i bram tworzą:
� aplikacje klienckie implementujące agenta uŜytkownika protokołu SIP , czyli tzw.
UA. Zgodnie z normami specyfikującymi IMS, UA powinno wspierać kilka
specyficznych mechanizmów np. dodatkowe nagłówki w protokole SIP97, albo
specjalny algorytm uwierzytelnienia dla sieci UMTS98. Ze względu na brak obecnie
dostępnych implementacji takich UA oraz małe znaczenie tych dodatkowych
mechanizmów w badanym zagadnieniu, w analizie byli stosowani agenci
uŜytkownika przystosowani do sieci Internet99.
� brama medialna (MGW), której funkcje realizuje serwer Asterisk PBX. MGW jest
połączony do centrali telefonicznej za pomocą łącza ISDN PRA. Dzięki temu
97 Na potrzeby IMS, 3GPP wprowadziło dodatkowe nagłówki do oryginalnego protokołu SIP. Są to tzw. „Private-Headers”, np. „P-Preffered-Identity” (patrz [24]), którym UA informuje S-CSCF, jaki publiczny identyfikator chce stosować w inicjowane sesji. 98 IMS wymaga, aby agent uŜytkownika (UA) w procedurze uwierzytelnienia stosował algorytm EAP-AKA (opisany w RFC4187). 99 W sieci Internet stosowane są UA zgodne z protokołem SIP opisanym w[22].
Architektura środowiska badawczego
104
środowisko badawcze umoŜliwia analizę interakcji pomiędzy sieciami tradycyjnymi
opartymi o komutacje łączy, a siecią w modelu NGN.
Warstwę sterowania połączeniami i zgłoszeniami tworzą elementy:
� serwer P-CSCF, który jest realizowany na bazie projektu Open Sip Express Router.
Specyficzna logika związana z IMS jest zaimplementowana za pomocą modułu
rozszerzającego działanie Open SER ponad standardową funkcję serwera SIP
Proxy100.
� serwery S-CSCF i I-CSCF. Podobnie jak P-CSCF, specyficzna logika tych elementów
funkcjonalnych IMS jest zaimplementowana za pomocą modułu rozszerzającego
funkcje Open SER. W środowisku badawczym oba elementy P/I-CSCF są
implementowane jako jeden fizyczny serwer.
� repozytorium profili u Ŝytkowników (HSS), którego funkcja została w środowisku
zaimplementowana takŜe jako moduł do Open SER. HSS wykorzystuje relacyjną
bazę danych do przechowywania tzw. profili uŜytkowników. Ta funkcja jest
zintegrowana z modułem realizującym elementy S-CSCF i I-CSCF.
� kontroler bramy medialnej (MGCF) , który jest realizowany wspólnie z MGW przez
Asterisk PBX. W środowisku badawczym Asterisk występuje takŜe w roli bramy
sygnalizacyjnej (SGW).
Warstwę komponentów usługowych tworzą:
� serwer obecności (z ang. Presence Server), który udostępnia informacje o stanie
obecności poprzez wiadomości protokołu SIP. W środowisku badawczym do tej
funkcji została wykorzystana aplikacja zrealizowana w ramach pracy dyplomowej
Michała Giermasińskiego i Krzysztofa Henniga [42].
� Serwery aplikacyjne (AS) realizujące logikę wybranych interfejsów Parlay X w
modelu IMS. AS dokonują przełoŜenia funkcji zdefiniowanych w ramach Parlay na
odpowiednią sekwencje wiadomości sygnalizacyjnych w IMS. W implementacji
wykorzystany został stos protokołu SIP zdefiniowany w ramach inicjatywy JAIN,
100 Jest to element architektury protokołu SIP
Architektura środowiska badawczego
105
czyli JAIN SIP (JSR 32)101. Wybrane interfejsy to: ThirdPartyCall, CallHandling,
TerminalStatus, AddressListManagement, Presence102.
Warstwę logiki aplikacji tworzy:
� usługa „Centrum Komunikacji Osobistej” (CKO) , która jest zaimplementowana jako
skrypt PHP103 w środowisku serwera HTTP. Ta aplikacja, z jednej strony, udostępnia
uŜytkownikowi interfejs WWW, a z drugiej strony korzysta w realizacji swojej
logiki z interfejsów Parlay X udostępnianych przez serwery aplikacyjne z warstwy
komponentów aplikacyjnych.
101 Specyfikacja JSR 32 definiuje API stosu SIP. W implementacji została wykorzystana referencyjna implementacja tego API, wykonana przez National Institute of Standards and Technology (NIST). 102 Szczegółowy opis funkcjonalny tych interfejsów zamieszczony jest w rozdziale 4. 103 PHP jest językiem skryptowym najczęściej stosowanym do oprogramowywania dynamicznych stron WWW.
Archite
ktura środ
ow
iska bad
awcze
go
106
P-CSCF
Interfejs usług sieciowych Parlay X
(SOAP/HTTP)
Interfejs sterowania usługami (SIP-ISC)
MGCF
MGW
Sieć PSTN
Interfejs do sieci PSTN
(ISDN-PRA)
sieć „IP”
SIPSIP
I-CSCF
HSS
SIP
Procedura‘User-Registration-Query’
Procedura
‘Terminating-Service-Control’
S-CSCF
Procedura ‘Cx-User-Authorization’
Procedura ‘Cx-Multimedia-Authorization’
Procedura ‘Cx-Server-Assignment’
Make Call
Cancel Call
Set Rule
Get Rule
Clear Rule
Serwer udostępnianiainformacji o stanie terminala uŜytkownika
Get Status
Serwer zarządzania ksiąŜką adresową
Delete Group
Query Members
Delete Member
Create Group
Add Member
J2SE
stos JAIN-SIP
interfejs ThirdPartyCall interfejs CallHandling interfejs TerminalStatus interfejs AddressListManagement interfejs Presence
Open SER
prolile uŜytkowników
Open SER
Procedura 'Assert Identity'
Asterisk PBX
Serwer udostępniającyinformacje o stanie obecności uŜytkownika
Publish User Presence
Get User Presence
Serwer sterowania połączeniami 3PCC
Serwer obsługi połączeń
elementy implementowane w ramach
środowiska badawczego
gotowe komponenty „open
source”
Procedura‘Originating-Service-Control’
Procedura
‘Registration-Notification’
Rys. 41: A
rchitektura środowiska badaw
czego
9. Implementacja i analiza modelu sterowania
usługami zaproponowanego w IP Multimedia
Subsystem
Model sterowania usługami zaproponowany w standardach opisujących IMS został
omówiony w rozdziale 3. W implementacji środowiska badawczego, którego celem jest
analiza tego modelu, wybrano podzbiór funkcji, procedur i interfejsów, które stanowią
podstawową bazę badanego zagadnienia.
P-CSCF
IM Subsystem
S-CSCF MGCF HSS
Cx
IP Multimedia Networks
IMS-MGW
PSTN
Mn
Mb
Mg
Mm
MRFP
Mb
Mr
Mb
Legacy mobile signalling Networks
I-CSCF
Mw
Mw
Gm
BGCF Mj Mi
BGCF
Mk Mk
C, D, Gc, Gr
UE
Mb
Mb
Mb
MRFC
SLF Dx
Mp
PSTN
PSTN
Gq
Rys. 42: Zakres implementacji (kolor zielony) modelu usługowego w środowisku badawczym na tle
architektury funkcjonalnej IMS ( źródło [3])
Na Rys. 42 przedstawiona jest architektura funkcjonalna IMS z zaznaczonymi
elementami, których funkcje/procedury zostały zaimplementowane w ramach środowiska
badawczego. Wybór tych elementów stanowi podzbiór niezbędny do analizy badanego
modelu usługowego. Elementy, których implementacja nie obejmuje są co prawda, niezbędne
do funkcjonowania standardowego komercyjnego systemu IMS, ale ich znaczenie w badanym
zagadnieniu jest niewielkie.
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
108
9.1 Opis zaimplementowanych mechanizmów
Zestaw implementowanych mechanizmów związanych z obsługą zgłoszeń, moŜna
podzielić ze względu na elementy funkcjonalne architektury IMS, które je realizują. Rys. 43
pokazuje umiejscowienie tych mechanizmów w poszczególnych elementach środowiska
badawczego. Zaimplementowane procedury są skojarzone z takimi elementami jak: P-CSCF,
S-CSCF, I-CSCF i HSS i wspólnie umoŜliwiają zamodelowanie sterowania usługami.
Rys. 43: Sterowanie połączeniami i zgłoszeniami IMS - zaimplementowane procedury związane z
modelem sterowania usługami
9.2 Procedura wstawienia informacji o identyfikacji uŜytkownika
(Assert Identity)
Procedura wstawienia informacji o identyfikacji uŜytkownika (Assert Identity) jest
wykonywana w serwerze P-CSCF. Podczas próby inicjacji sesji multimedialnej, UA
uŜytkownika wysyła wiadomości sygnalizacyjne104, które kierowane są do P-SCCF.
Następnie P-CSCF dokonuje uwierzytelnienia uŜytkownika, co umoŜliwia jednoznaczne
określenie toŜsamości tj. prywatnego identyfikatora uŜytkownika tzw. Private-User-
104 Inicjacja sesji odbywa się za pomocą widomości INVITE protokołu SIP.
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
109
Identifier105. Gdy znana jest juŜ toŜsamość, P-CSCF modyfikuje wiadomości sygnalizacyjne
dla inicjowanej sesji poprzez umieszczenie w nich informacji o uwierzytelnionym juŜ
identyfikatorze uŜytkownika. Ta informacja jest zawarta w dodatkowym nagłówku protokołu
SIP tj. P-Asserted-Indentity, którego wartością jest publiczny identyfikator jednoznacznie
skojarzony z uwierzytelnioną toŜsamością106. Rys. 44 ilustruje kolejność zdarzeń w tej
procedurze, natomiast na Rys. 45 jest pokazana przykładowa widomość INVITE i jej
modyfikacja w P-CSCF.
Rys. 44: Procedura identyfikacji uŜytkownika w P-CSCF (Assert Identity)
Informacja o uwierzytelnionej identyfikacji uŜytkownika jest propagowana do innych
elementów IMS za pomocą nagłówka P-Asserted-Indentity. Jest to podstawą do realizacji
wszystkich mechanizmów związanych z wykonywaniem usług dla połączeń wychodzących
(tzw. originating service control, opis w rozdziale 9.3.7). Uwierzytelnienie uŜytkownika
następuje tylko w P-CSCF, a pozostałe systemy biorące udział w realizacji połączenia (z
serwerami aplikacyjnymi włącznie), aby zidentyfikować inicjatora sesji korzystają z
informacji zapisanej w P-Asserted-Indentity.
105 W IMS toŜsamość uŜytkownika jest skojarzona z prywatnym identyfikatorem. 106 Według specyfikacji IMS [7] wartością nagłówka P-Asserted-Identity jest publiczny identyfikator, który został zarejestrowany (za pomocą wiadomości REGISTER) i jest skojarzony z uwierzytelnionym prywatnym identyfikatorem. UŜytkownik moŜe zarejestrować wiele publicznych identyfikatorów skojarzonych z jednym prywatnym identyfikatorem. Agent uŜytkownika informuje P-CSCF, jakim konkretnym publicznym identyfikatorem chce się posługiwać w inicjowanej sesji poprzez umieszczenie w wiadomości INVITE dodatkowego nagłówka P-Preffered-Identity. Ze względu na niedostępność gotowych implementacji agentów uŜytkownika zgodnych z IMS, czyli takich, którzy między innymi wspierali by mechanizm opisany powyŜej, implementowany w środowisku badawczym mechanizm Assert Identity umieszcza w nagłówku P-Asserted-Identity pierwszy zarejestrowany publiczny identyfikator skojarzony z uwierzytelnionym uŜytkownikiem, niezaleŜnie od wartości nagłówka P-Preffered-Identity, który nie występuje w UA niezgodnych z IMS. Tym sposobem w środowisku badawczym mogą być uŜywani agenci uŜytkownika niewspierający mechanizmów specyficznych dla IMS.
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
110
Rys. 45: Przykładowa modyfikacja wiadomości INVITE w P-CSCF107.
Prywatny identyfikator uŜytkownika pojawia się w sygnalizacji wyłącznie podczas
procedury uwierzytelnienia w P-CSCF i w procedurze rejestracji w S-CSCF. W komunikacji
z serwerami aplikacyjnymi (AS) do identyfikacji uŜytkownika jest wykorzystywany tylko
nagłówek P-Asserted-Indentity. Minimalizacja „uŜycia” prywatnego identyfikatora jest
spowodowana wymogami bezpieczeństwa i ochrony prywatności uŜytkownika, który moŜe
występować w sieci pod róŜnymi publicznymi identyfikatorami, ale moŜliwość skojarzenia
powiązania pomiędzy nimi jest moŜliwa tylko w bezpiecznej części sieci macierzystej i tylko
na elementach niebiorących bezpośredniego udziału w realizacji usług.
9.3 Procedura przydzielenia serwera S-CSCF podczas pierwszej
rejestracji agenta uŜytkownika (User-Registration-Query)
Procedura przydzielenia serwera S-CSCF (User-Registration-Query) ma miejsce w
serwerze I-CSCF. Podczas przyłączenia się do sieci, agent uŜytkownika w terminalu
końcowym dokonuje rejestracji w systemie IMS wysyłając zgłoszenie rejestracji, które
poprzez P-CSCF trafia do I-CSCF, gdzie przeprowadzane są następujące czynności:
� I-CSCF komunikuje się z HSS w celu uzyskania zezwolenia na rejestracje publicznego
identyfikatora (PUI). HSS wykonuje procedurę Cx-User-Authorization (opis
poniŜej), której rezultatem jest zwrócenie informacji o zgodzie na rejestracje108.
107 Pokazane przykładowe wiadomości INVITE protokołu SIP nie są całkowicie zgodne z wymogami, jakie nakładają specyfikacje IMS tj. brakuje w nich specyficznych dla IMS nagłówków, które zostały opisane w [24] i [25]. Nieobecność tych dodatkowych nagłówków nie wpływa na implementowany w ramach środowiska badawczego model sterowania usługami IMS. 108 Brak zgody na rejestracje moŜe być spowodowany: niemoŜnością znalezienia publicznego identyfikatora (PUI) uŜytkownika, który się rejestruje albo tym, Ŝe rejestrowany PUI nie naleŜy do prywatnego identyfikatora
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
111
� I-CSCF komunikuje się z HSS w celu uzyskania informacji o adresie S-CSCF, który
będzie obsługiwał rejestrującego się uŜytkownika109.
Następnie zgłoszenie rejestracji jest kierowane do S-CSCF, którego adres został
otrzymany z HSS110. Kolejność realizowanych mechanizmów została przedstawiona na Rys.
46, w którym takŜe są zaznaczone logiczne styki pomiędzy elementami funkcjonalnymi IMS
implementowanymi w środowisku badawczym jako jeden fizyczny serwer.
Rys. 46: Procedura User-Registration-Query w I-CSCF i Cx-User-Authorization w HSS
Podstawową rolą procedury User-Registration-Query w rejestracji uŜytkownika jest
przydzielenie odpowiedniego S-CSCF, który będzie właściwym serwerem obsługującym
wszystkie zgłoszenia przychodzące i wychodzące od rejestrowanego uŜytkownika111.
9.3.1 Procedury interfejsu Cx
Interfejs Cx jest stykiem pomiędzy serwerami CSCF, a HSS. Na Rys. 47 zaznaczone są
główne funkcje tego interfejsu. Do najwaŜniejszych procedur zdefiniowanych na tym
interfejsie naleŜą udostępnianie informacji niezbędnych do uwierzytelnienia uŜytkownika
oraz udostępnianiu tzw. profilu, w którym zawarte są informacje, jakie serwery aplikacyjne
mają brać udział w dalszej obsłudze zgłoszenia.
uŜytkownika (PRUI). Brak zgody na rejestracje moŜe teŜ być podyktowany wewnętrzną polityką narzuconą na HSS. 109 Zgodnie z [9] HSS zwraca I-CSCF listę adresów S-CSCF, które mogą obsługiwać uŜytkownika. W implementacji na potrzeby środowiska badawczego HSS zwraca jeden adres serwera S-CSCF. 110 W środowisku badawczym I-CSCF, S-CSCF i HSS są zaimplementowani w jednym serwerze, ale komponenty aplikacyjne odpowiedzialne za poszczególne elementy funkcjonalne są wydzielone. 111 Przejście zgłoszenia rejestracji przez I-CSCF ma duŜe znaczenie w przypadku, gdy uŜytkownik jest w sieci obcej względem swojej macierzystej (tzw. z ang. roaming). W tym przypadku I-CSCF otrzymuje informacje z HSS o adresie S-CSCF naleŜącym do macierzystej sieci rejestrującego się uŜytkownika i tam następuje dalsza obsługa. Ze względu na małe znaczenie tych mechanizmów w analizowanym zagadnieniu, w środowisku badawczym nie zostały one zaimplementowane.
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
112
Rys. 47: Funkcje interfejsu Cx
Zgodnie z [9] specyfikującym interfejs pomiędzy HSS i CSCF, protokołem na styku Cx
powinien być Diameter112, ze względu na przyjętą zintegrowaną implementacje funkcji HSS i
CSCF, Cx jest zamodelowany za pomocą programistycznego API pomiędzy modułami w
serwerze Open SER (patrz Rys. 48).
Rys. 48: Implementacja interfejsu Cx jako API
112 Protokół ‘Diameter’ opisany jest w RFC 3588
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
113
9.3.2 Procedura autoryzacji Ŝądania rejestracji (Cx-User-Authorization)
Procedura autoryzacji Ŝądania rejestracji (Cx-User-Authorization) jest to jedna z
procedur zdefiniowana na interfejsie Cx113. Polega na przydzieleniu rejestrującemu się
uŜytkownikowi serwer S-CSCF, który będzie go obsługiwał. Przed przyznaniem adresu S-
CSCF, HSS dokonuje sprawdzenia czy uŜytkownik, który rejestruje się w sieci przedstawia
się poprawnymi identyfikatorami i czy PUI jest skojarzony z PRUI.
Procedura składa się z Ŝądania skierowanego z I-CSCF do HSS i odpowiedzi HSS. Na
Rys. 49 przedstawiona jest programistyczna definicja funkcji modelującej tą procedurę.
Parametrami Ŝądania są:
� PUI;
� Publiczny identyfikator uŜytkownika, który jest rejestrowany;
� Typ uwierzytelnienia, w którym I-CSCF informuje HSS o tym, czy zgłoszenie dotyczy
nowej rejestracji uŜytkownika albo dotyczy Ŝądania wyrejestrowania z sieci IMS.
Rys. 49: Funkcja CX-UA modelująca procedurę Cx-User-Authorization
Po otrzymaniu Ŝądania, HSS dokonuje sprawdzenia czy publiczny identyfikator naleŜy
do uŜytkownika i czy uŜytkownik ma prawo dokonać rejestracji114.
113 W implementacji na potrzeby środowiska badawczego ten interfejs nie ma charakteru sieciowego (funkcje CSCF i HSS są zintegrowane w ramach jednego serwera) tylko jest zamodelowany jako API pomiędzy dwoma komponentami programistycznymi. 114 Implementacja HSS w środowisku badawczym umoŜliwia blokowanie moŜliwości rejestracji poszczególnych publicznych identyfikatorów.
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
114
Odpowiedź HSS składa się z:
� Kodu określającego rezultat operacji;
� Adresu serwera S-CSCF, który został przydzielony do obsługi zgłoszenia.
9.3.3 Procedura uwierzytelnienia uŜytkownika (Cx-Multimedia-Authentication)
Procedura uwierzytelnienia uŜytkownika (Cx-Multimedia-Authentication) jest to jedna z
procedur zdefiniowana na interfejsie Cx. SłuŜy do pobrania z HSS kluczy niezbędnych do
uwierzytelnienia uŜytkownika, które następnie są porównywane w S-CSCF z danymi
uzyskanymi ze zgłoszenia rejestracji115. Rys. 50 pokazuje funkcję CX-MA, która modeluje
procedurę Cx-Multimedia-Authentication.
Rys. 50: Funkcja CX-MA modelująca procedurę Cx-Multimedia-Authentication
Parametrami Ŝądania są:
� PRUI;
� Publiczny identyfikator, którego dotyczy zgłoszenie rejestracji.
Odpowiedź HSS składa się z:
� Kodu określającego rezultat operacji;
� Danych, które umoŜliwiają uwierzytelnienie (klucze).
115 W IMS uwierzytelnienie uŜytkownika odbywa się przy pomocy algorytmu EAP-AKA (opisany w RFC4187). Polega on na współdzieleniu kluczy prywatnych pomiędzy HSS i kartą USIM, znajdująca się w telminalu uŜytkownika. Przy takim modelu W procedurze Cx-Multimedia-Authentication HSS zwraca S-CSCF tzw. zmienne RAND, AUTN i XRES (opis w 3GPP TS 33.203). W implementacji był stosowany model uproszczony, w którym HSS zwraca tylko jeden klucz umoŜliwiający uwierzytelnienie uŜytkownika.
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
115
9.3.4 Procedura pobrania profilu uŜytkownika (Cx-Server-Assigment)
Procedura pobrania profilu uŜytkownika (Cx-Server-Assigment) jest to jedna z procedur
zdefiniowana na interfejsie Cx. Główną funkcją tej procedury w implementowanym
środowisku badawczym, jest umoŜliwienie pobrania profilu uŜytkownika z HSS do
obsługującego serwera S-CSCF. Po pomyślnym uwierzytelnieniu uŜytkownika S-CSCF
kieruje Ŝądanie w celu rejestracji w HSS tego, Ŝe dany uŜytkownik jest obsługiwany w danym
serwerze S-CSCF. Rys. 51 pokazuje funkcje CX-SA, która jest modelem procedury Cx-
Server-Assigment w API udostępnianym przez HSS.
Rys. 51: Funkcja CX-SA modelująca procedurę Cx-Server-Assigment
Parametrami Ŝądania są:
� Prywatny identyfikator uŜytkownika (PRUI);
� Publiczny identyfikator, którego dotyczy zgłoszenie rejestracji;
� Adres serwera S-CSCF, który obsługuje uŜytkownika;
� Typ rejestracji (nowa rejestracja, de-rejestracja, powtórna rejestracja, brak rejestracji,
itd..);
Odpowiedź HSS składa się z:
� Kodu określającego rezultat operacji;
� Profilu uŜytkownika.
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
116
Wywołanie Cx-Server-Assigment moŜe teŜ mieć miejsce dla uŜytkowników, którzy
aktualnie nie są przyłączenie do sieci. Dzieje się tak w przypadku konieczności pobrania
profilu takiego uŜytkownika przez S-CSCF w celu wykonania procedury związanej z
usługami (patrz procedura Terminating Service Control).
9.3.5 Procedura rejestracji uŜytkownika w serwerze S-CSCF (Registration-
Notification)
Procedura rejestracji uŜytkownika w serwerze S-CSCF (Registration-Notification) ma
miejsce w serwerze S-CSCF. Po otrzymaniu zgłoszenia rejestracji z serwera I-CSCF,
przeprowadzane jest uwierzytelnienie. W tym celu S-CSCF pobiera z HSS klucze
autoryzacyjne (patrz procedura Cx-Multimedia-Authentication) i dokonuje sprawdzenia, czy
dane pobrane z HSS umoŜliwiają uwierzytelnienie. Jeśli znana jest juŜ toŜsamość
uŜytkownika, S-CSCF informuje HSS o poprawnej rejestracji i pobiera odpowiedni profil
uŜytkownika, dla którego została przeprowadzona procedura rejestracji (patrz procedura Cx-
Server-Assigment).
Rys. 52: Procedura rejestracji uŜytkownika w S-CSCF
Rys. 52 pokazuje czynności wchodzące w skład procedury Registration-Notification.
9.3.6 Procedury sterowania usługami (Service Control)
Procedury sterowania usługami (Service Control) są podstawą modelu usługowego
zaproponowanego w specyfikacjach opisujących IMS. Istotą ich funkcji jest odpowiednie
skierowanie obsługi danego zgłoszenia do właściwego serwera aplikacyjnego. Decyzja, jakie
zgłoszenie i przez jaki serwer aplikacyjny ma być obsługiwane zgłoszenie, odbywa się na
podstawie profilu uŜytkownika, a w szczególności na podstawie tzw. kryteriów filtracji (z
ang. Initial Filter Criteria ).
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
117
W implementowanym modelu sterowania usługami proces obsługi zgłoszeń jest podzielony
na kilka etapów:
� określanie czy zgłoszenie jest zgłoszeniem przychodzącym czy wychodzącym
WyróŜnione są dwie procedury sterowania usługami. Jedna dla połączeń
przychodzących do uŜytkownika (Terminating Service Control) i dla połączeń
inicjowanych przez uŜytkownika (Originating Service Control). W przypadku
połączeń wychodzących, procedura sterowania usługami oparta jest o profil
uŜytkownika, który zainicjował zgłoszenie. Jeśli zgłoszenie jest przychodzące to
wywoływana jest procedura sterowania oparta o profil adresata zgłoszenia (patrz
Rys. 53).
Rys. 53: Zgłoszenie od uŜytkownika A do B i analiza profili w S-CSCF
� Sprawdzenie dostępności profilu u Ŝytkownika i ewentualne pobranie profilu z HSS
S-CSCF pobiera profil uŜytkownika w procedurze rejestracji (patrz Registration-
Notification) i podczas obsługi zgłoszeń wychodzących zawsze profil uŜytkownika
jest dostępny w S-CSCF, poniewaŜ tylko uŜytkownicy, którzy są zarejestrowani
mają prawo inicjować połączenia. W przypadku połączeń przychodzących,
uŜytkownik, do którego jest adresowane zgłoszenie, moŜe aktualnie być poza siecią
tzn. być nie zarejestrowany w systemie IMS. Jeśli taka sytuacja nastąpi, S-CSCF
wykonuje procedurę Cx-Server-Assigment w celu pobrania profilu uŜytkownika
wywoływanego w analizowanym zgłoszeniu. Pobranie profilu dla nie
zarejestrowanego uŜytkownika jest potrzebne, poniewaŜ kaŜdy uŜytkownik moŜe
mieć przypisane usługi, które są wykonywane właśnie, gdy jest on poza siecią (nie
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
118
jest zarejestrowany w IMS)116. Rys. 54 pokazuje przykładową obsługę zgłoszenia dla
nie zarejestrowanego uŜytkownika.
Profil B
Rys. 54: Zgłoszenie od uŜytkownika A do B i analiza profili w S-CSCF dla niezarejestrowanego
uŜytkownika
� Określenie czy zgłoszenie jest zgłoszeniem juŜ obsługiwanym przez serwer
aplikacyjny.
Serwer aplikacyjny (AS), do którego S-CSCF skieruje zgłoszenie w celu wykonania
scenariusza usługi, moŜe dokonać modyfikacji tego zgłoszenia (modyfikacji
wiadomości protokołu SIP) i następnie moŜe skierować to zgłoszenie ponownie do
S-CSCF117. Aby uniknąć sytuacji, w której powracające zgłoszenie z serwera
aplikacyjnego zostanie jeszcze raz „zawrócone” do tego samego AS, S-CSCF
kierując wiadomości SIP do danego AS wstawia dodatkowy nagłówek (‘P-Original-
Dialog-ID’), który umoŜliwia przyporządkowanie powracających wiadomości SIP z
serwerów aplikacyjnych do danego zgłoszenia. S-CSCF posiada informacje, jakie
AS obsługiwały dane zgłoszenie i w ten sposób nigdy dana wiadomości nie jest
dwukrotnie kierowana do tego samego serwera aplikacyjnego.
116 Przykładem takiej usługi moŜe być przekierowanie połączeń na inny numer (np. poczty głosowej) w przypadku wyłączonego terminala. 117 Takie zachowanie serwera aplikacyjnego odpowiada funkcji SIP-proxy.
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
119
AS#1
sip:as1.eims.local
AS#2
sip:as2.eims.local
Profil AIFC, priorytet 1 = INVITE na sip:[email protected]
IFC, priorytet 2 = INVITE na sip:[email protected]
uŜytkownik #A
1. INVITE B
S-CSCF
P-CSCF
2. INVITE B
3. IN
VITE B
4. INVITE B
5. IN
VITE B
service control
INVITE sip:[email protected] SIP/2.0
P-Original-Dialog-ID: call-id=de40707c-cede-db11-8499@rubi;from-tag=2644707cP-Service-Name: <sip:[email protected]>
INVITE sip:[email protected] SIP/2.0
P-Original-Dialog-ID: call-id=de40707c-cede-db11-8499@rubi;from-tag=2644707cP-Service-Name: <sip:[email protected]>
uŜytkownik #B
6. INVITE BP-CSCF
Rys. 55: Obsługa zgłoszenia poprzez kilka serwerów aplikacyjnych
Rys. 55 pokazuje obsługę wiadomości INVITE, dla danego zgłoszenia wychodzącego.
Profil uŜytkownika zawiera informacje instruującą S-CSCF o konieczności kierowania
wiadomości INVITE do dwóch serwerów aplikacyjnych (AS#1 i AS#2). Zgodnie z
zapisanym w profilu priorytetem S-CSCF kieruje wiadomości do pierwszego AS,
wstawiając nagłówek ‘P-Original-Dialog-ID’ zawierający identyfikator danego
zgłoszenia (szczegółowy opis znajduje się poniŜej). Powracająca widomość z AS
zawiera ten nagłówek i na tej podstawie S-CSCF jest wstanie podjąć decyzję, Ŝe
następnym serwerem aplikacyjnym dla tej wiadomości będzie AS#2 (zgodnie z
priorytet zapisanym w profilu).
� Analiza kryteriów filtrowania - IFC
Profil uŜytkownika, który jest pobierany z HSS, zawiera tzw. filtry IFC (z ang.
Initial Filter Criteria ). IFC definiują reguły określające, jakie wiadomości protokołu
SIP wyzwalają przekierowanie zgłoszenie do danego serwera aplikacyjnego. Profil
zawiera wiele reguł IFC, które mają przyporządkowany priorytet. Priorytet decyduje o
kolejności analizowania danych z poszczególnych IFC w S-CSCF.
KaŜdy IFC składa się z kryteriów wyzwolenia (z ang. Trigger Point), które
określają zestaw warunków decydujących o potrzebie zastosowania obsługi zgłoszenia
w serwerze aplikacyjnym. Rys. 56 pokazuje przykładową definicję IFC, która zawiera
Trigger Point określający, Ŝe kaŜde zgłoszenie zawierające wiadomość INVITE
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
120
powinno być skierowane do serwera aplikacyjnego o adresie
„sip:[email protected]”
Rys. 56: Definicja filtru IFC
IFC zawiera takŜe informacje o rodzaju sesji (SessionCase), której dotyczy dana
reguła IFC. Rodzaj sesji określa czy IFC ma być stosowane do zgłoszeń
wychodzących (Originating Service Control), zgłoszeń przychodzących (Terminating
Service Control) lub zgłoszeń przychodzących do uŜytkownika, który nie jest
zarejestrowany w systemie IMS (Terminating Service Control for Unregistered User
State).
� Wstawienie nagłówka „P-Original-Dialog-ID” 118
Jeśli zgłoszenie jest nowym zgłoszeniem (nie jest powracającym zgłoszeniem z
serwera aplikacyjnego) i wymaga obsługi w serwerze aplikacyjnym, to S-CSCF
dodaje do wiadomości SIP dodatkowy nagłówek identyfikujący jednoznacznie
przynaleŜność tej wiadomości do danego zgłoszenia. Wartością nagłówka ‘P-
Original-Dialog-ID’ jest konkatenacja identyfikatorów dialogu protokołu SIP, czyli
wartości nagłówka ‘Call-ID’ oraz etykiet nagłówków ‘From’ i ‘To’ (patrz Rys. 57).
118 W IMS jest stosowany inny mechanizm tzn. nie jest wstawiany dodatkowy nagłówek ‘P-Original-Dialog-ID’. Według [7] aby umoŜliwi ć identyfikacje powracającej wiadomości do poszczególnych zgłoszeń stosuje się nagłówek ‘Route’ (jego rola w protokole SIP opisana jest w [22]), do którego dodaje się specjalnie skonstruowany adres nieistniejącego serwera. Ten spreparowany adres jest uŜywany jako identyfikator zgłoszenia i pozwala S-CSCF zidentyfikować wiadomość. To rozwiązanie zostało zaakceptowane przez 3GPP i jest obecnie standardem. We wczesnych pracach nad mechanizmami w IMS pojawiła się propozycja uŜycia nagłówka ‘P-Original-Dialog-ID’ (opisana w IETF draft-henrikson-sip-original-dialog-id), która zakładała uŜycie nowego nagłówka zamiast korzystania z ‘Route’, który jest bazowym (opisanym RFC3261) elementem protokołu SIP. Propozycja ta wynikała z faktu, Ŝe wykorzystywanie ‘Route’ jako identyfikatora sesji (tak jak zostało to opisane powyŜej) jest de facto niezgodne z przeznaczeniem tego nagłówka opisanym RFC3261. Ta kwestia była i jest poddawana krytyce.
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
121
Rys. 57: Budowa nagłówka P-Original-Dialog-ID'
Potrzeba stosowania P-Original-Dialog-ID wynika z faktu, Ŝe identyfikacja, do
jakiego zgłoszenia naleŜy dana wiadomość jest niemoŜliwa w oparciu tylko o
standardowe nagłówki określające dialog protokołu SIP119. Dzieje się tak, poniewaŜ
kaŜdy serwer aplikacyjny potencjalnie moŜe występować w tzw. roli B2BUA120. W tej
roli, AS moŜe tworzyć nowy dialog (w sensie protokołu SIP) i tym sposobem
wiadomość powracają z AS do S-CSCF nie mogłaby być rozpoznana jako
powracająca w ramach jednego zgłoszenia. Faktycznie naleŜałaby do nowego,
zainicjowanego przez AS, dialogu. Umieszczanie P-Original-Dialog-ID daje
moŜliwość S-CSCF identyfikacji oryginalnej przynaleŜności wiadomości do dialogu i
co za tym idzie, identyfikacji przynaleŜności do danego zgłoszenia (patrz Rys. 58).
119 Dialog w protokole SIP identyfikowany jest przez wartość nagłówka ‘Call-ID’ i etykiety (‘tag’) z nagłówków ‘From’ i ‘To’. 120 Opis zamieszczony jest w rozdziale 2.
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
122
Rys. 58: Modyfikacja identyfikatorów dialogu w wiadomości SIP przy przejściu przez AS, który
występuje w roli B2BUA
� Skierowanie zgłoszenia do odpowiedniego serwera aplikacyjnego.
Po sprawdzeniu, czy profil uŜytkownika definiuje potrzebę skierowania obsługi do
serwera aplikacyjnego i po umieszczeniu w wiadomości SIP naleŜącej do danego
zgłoszenia, wszystkich dodatkowych nagłówków, następuje wysłanie wiadomości do
serwera aplikacyjnego, w którym odbywa się dalsza obsługa związana z
wykonywanie scenariusza usług.
9.3.7 Procedura sterowania usługami dla zgłoszeń wychodzących (Originating
Service Control)
Procedura sterowania usługami dla zgłoszeń wychodzących (Originating Service
Control) wykonywana jest w S-CSCF dla zgłoszeń inicjowanych przez uŜytkownika. S-CSCF
identyfikuje inicjatora zgłoszenia poprzez wartość nagłówka P-Asserted-Identity (patrz
procedura Assert Identity). KaŜdy uŜytkownik, który inicjuje połączenie musi być
zarejestrowany w S-CSCF i podczas procedury rejestracji pobierany jest jego profil z HSS. W
chwili wykonywania procedury Originating Service Control, S-CSCF dysponuje profilem,
który podlega analizie w kontekście procedury sterowania usługami opisanej powyŜej (patrz
Service Control).
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
123
9.3.8 Procedura sterowania usługami dla zgłoszeń przychodzących
(Terminating Service Control)
Procedura sterowania usługami dla zgłoszeń przychodzących (Terminating Service
Control) wykonywana jest w S-CSCF dla zgłoszeń przychodzących do uŜytkownika. JeŜeli
uŜytkownik, do którego jest kierowane zgłoszenie jest zarejestrowany w systemie IMS to
dalsza analiza w kontekście sterowania usługami oparta jest o profil, który jest w dyspozycji
S-CSCF. JeŜeli uŜytkownik nie jest zarejestrowany, to S-CSCF wykonuje procedurę Cx-
Server-Assigment, której rezultatem jest pobranie z HSS profilu nie zarejestrowanego
uŜytkownika (patrz Rys. 54). Dalsza obsługa odbywa się zgodnie z opisem powyŜej (patrz
Service Control).
9.4 Zaimplementowany proces rejestracji uŜytkownika i realizacja
mobilności w sieci
Głównym zadaniem zaimplementowanych mechanizmów związanych z rejestracją
uŜytkownika jest umoŜliwienie realizacji mobilności terminali uŜytkowników w środowisku
badawczym oraz zamodelowanie zcentralizowanego repozytorium profili uŜytkowników
(jedna z funkcji HSS).
Rys. 59 przedstawia uproszczony przepływ wiadomości sygnalizacyjnych mających
miejsce w procesie rejestracji uŜytkownika. W poszczególnych miejscach tego rysunku
zaznaczone są takŜe momenty, w których są wykonywane zaimplementowane procedury.
Procedury te zostały opisane w rozdziale 9.1.
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
124
5. Cx-U
AR
7. Cx-U
AA 9. C
x-MAR
11. Cx-M
AA
20. Cx-SAR
22. Cx-S
AA
Rys. 59: Proces rejestracji uŜytkownika w systemie IMS (środowisko badawcze)
Szczegółowy opis procesu rejestracji:
1. Agent uŜytkownika zaimplementowany w terminalu wysyła do P-CSCF121 wiadomość
REGISTER protokołu SIP.
2. P-CSCF tworzy nową transakcje dla zgłoszenia i modyfikuje R-URI122 wiadomości,
wstawiając w to pole adres serwera I-CSCF.
3. Wiadomość REGISTER kierowana jest do I-CSCF.
4. I-CSCF rozpoczyna wykonywanie procedury User-Registration-Query, której celem
jest uzyskanie adresu serwera S-CSCF.
5. I-CSCF wysyła wiadomość Cx-User-Authentication-Request123 do HSS, w której
zawarty jest publiczny (PUI) i prywatny (PRUI) identyfikator uŜytkownika.
6. HSS wykonuje procedurę Cx-User-Authentication, której celem jest sprawdzenie
poprawności identyfikatorów uŜytkownika i wybranie serwera S-CSCF124.
121 W środowisku badawczym adres serwera P-CSCF jest konfigurowalnym parametrem terminala uŜytkownika. W systemie IMS, adres P-CSCF moŜe być uzyskany przez terminal poprzez protokół DHCP, albo podczas tworzenie kontekstu PDP w sieci GPRS. 122 Request-URI (opis w rozdziale 2). 123 Jest to wiadomość interfejsu Cx (patrz [9]) oparta o protokół ‘Diameter’. 124 W środowisku badawczym został zaimplementowany jeden serwer S-CSCF.
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
125
7. HSS wysyła wiadomość Cx-User-Authentication-Answer do I-CSCF, która zawiera
adres serwera S-CSCF wybranego do obsługi uŜytkownika.
8. I-CSCF przesyła wiadomość REGISTER do S-CSCF.
9. S-CSCF przesyła wiadomość Cx-Multimedia-Authorization-Request do HSS, w celu
uzyskania parametrów potrzebnych do uwierzytelnienia uŜytkownika.
10. HSS wykonuje procedurę Cx-Multimedia-Authorization, w której generowany jest
parametr potrzebny do uwierzytelnienia125.
11. HSS wysyła wiadomość Cx-Multimedia-Authorization-Answer, która zawiera dane
potrzebne do uwierzytelnienia.
12. S-CSCF przesyła wiadomość protokołu SIP ‘401 Unauthorized’, której celem jest
poinformowanie agenta uŜytkownika o potrzebie zawarcia w Ŝądaniu rejestracji
danych wymaganych do uwierzytelnienia.
13. I-CSCF przesyła wiadomość ‘401 Unauthorized’ do P-CSCF.
14. P-CSCF przesyła widomość ‘401 Unauthorized’ do agenta uŜytkownika.
15. W terminalu końcowym są generowane parametry uwierzytelniające.
16. Agent uŜytkownika powtórnie wysyła wiadomość REGISTER z załączonymi
parametrami potrzebnymi do uwierzytelnienia.
17. P-CSCF przesyła wiadomość REGISTER do I-CSCF
18. I-CSCF przesyła wiadomość REGISTER do S-CSCF, którego adres wcześniej został
pobrany z HSS.
19. S-CSCF wykonuje procedurę Registration-Notification polegającą na sprawdzeniu
poprawności danych uwierzytelniających i pobraniu profilu uŜytkownika z HSS126.
20. S-CSCF wysyła wiadomości Cx-Server-Assigment-Request do HSS, która zawiera
informacje o poprawnym uwierzytelnieniu.
21. HSS przeprowadza procedurę Cx-Server-Assigment polegającą za zapisaniu informacji
o poprawnym przydzieleniu uŜytkownikowi danego serwera S-CSCF.
125 Dane potrzebne do uwierzytelnienia uŜytkownika w systemie IMS składają się z wielu parametrów (opis w 3GPP TS 33.203). Na potrzeby środowiska badawczego ten model został uproszczony i uwierzytelnienie odbywa się za pomocą algorytmu EAP-MD5, w którym parametrem jest skrót (MD5) hasła uŜytkownika.
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
126
22. HSS wysyła wiadomość Server-Assigment-Answer, której najwaŜniejszą częścią jest
profil rejestrującego się uŜytkownika.
23. S-CSCF potwierdza poprawność rejestracji agentowi uŜytkownika przesyłając
wiadomość ‘200 OK’127.
24. I-CSCF przesyła wiadomość ‘200 OK’ do P-CSCF.
25. P-CSCF przesyła wiadomość ‘200 OK’ do agenta uŜytkownika.
Mobilność uŜytkowników zapewniona jest poprzez elementy HSS i S-CSCF. HSS w
procedurze rejestracji uŜytkownika, wybiera serwer S-CSCF128 (punkt 6) i po poprawnym
uwierzytelnieniu i autoryzacji, zapisuje jego adres w profilu uŜytkownika (punkt 21). Dzięki
temu, informacja o adresie S-CSCF, który aktualnie obsługuje uŜytkownika zawsze jest
dostępna w HSS.
S-CSCF integruje w sobie funkcje SIP-Registrar (patrz rozdział 2) tj. w procesie
rejestracji uzyskuje informacje o skojarzeniu pomiędzy aktualnym sieciowym adresie
terminala uŜytkownika (FQDM)129, a publicznym identyfikatorem (AOR)130 tego
uŜytkownika. UmoŜliwia to S-CSCF kierowanie wiadomości SIP adresowanych przy pomocy
publicznych identyfikatorów (PUI) do konkretnych terminali przyłączonych do sieci IP.
Informacja o sieciowym adresie terminala uŜytkownika identyfikującego się publicznym
identyfikatorem (PUI) jest moŜliwa do uzyskania w 2 krokach:
1. pytanie do HSS o profil uŜytkownika identyfikującego się poprzez PUI;
2. odczyt z profilu, adresu obsługującego S-CSCF i translacja PUI na adres sieciowy
zgodnie z asocjacją AOR->FQDM w S-CSCF.
127 Zgodnie z [7] po popraniu profilu uŜytkownika, S-CSCF powinien wykonać tzw. procedurę „rejestracji przez trzecią stronę” (z ang. Third-Party Registration) polegającą na rejestracji uŜytkownika przez S-CSCF we wszystkich serwerach aplikacyjnych, których adresy są zawarte w profilu. Ze względu na małe znaczenie tego mechanizmu w analizowanych zagadnieniach w implementowanym środowisku badawczym został on pominięty. 128 Według specyfikacji IMS, HSS moŜe teŜ wybrać listę serwerów S-CSCF. 129 Np. terminal przyłączony do sieci pod adresem IP = 10.10.10.10 i nasłuchujący wiadomości SIP na porcie UDP = 8060 posiada adres URI = sip:10.10.10.10:8060. Jest to tak zwany FQDN (Fully qualified domain name) jednoznacznie określający host w sieci IP. 130 Np. sip:[email protected]. Publiczny identyfikator jest wykorzystywany w S-CSCF jako tzw AOR (Address of routing), który w skojarzeniu z FQDM umoŜliwia routing wiadomości.
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
127
2. Ŝadanie profilu
3. profil ‘sip:ala@
eims.local’
4. IN
VITE
sip:ala@
eim
s.lo
cal
5. IN
VITE
sip:ala@
10.10.10.10:8060
Rys. 60: Realizacja mobilności
Rys. 60 ilustruje poszczególne zdarzenia, które zachodzą w sieci, aby zapewnić
moŜliwość realizacji mobilności. Adresatem zgłoszenie przychodzącego do serwera S-
CSCF#1 jest uŜytkownik, aktualnie obsługiwany przez inny serwer S-CSCF (patrz punkt 1 z
Rys. 60). Aby moŜliwa była realizacji poprawnego kierowania ruchu, S-CSCF#1 pobiera z
HSS profil wywoływanego uŜytkownika, który zawiera informacje o adresie serwera S-
CSCF, aktualnie obsługującego uŜytkownika (punkty 1-2). Gdy zgłoszenie trafi do
właściwego serwera S-CSCF następuje skierowanie widomości na fizyczny adres terminala, z
którego uŜytkownik zarejestrował swój publiczny identyfikator (punkt 5)131.
9.5 Model sterowania usługami z wykorzystaniem federacji
serwerów aplikacyjnych
Podstawą modelu sterowania usługami w IMS jest mechanizm kierowania zgłoszeń do
odpowiednich serwerów aplikacyjnych, zgodnie z regułami zawartymi w profilu,
przechowywanym w centralnym miejscu w sieci tzn. w elemencie HSS. Skierowanie obsługi
131 Ten model zarządzania mobilnością zaproponowany w ramach systemu IMS jest wzorowany na rozwiązaniach stosowanych w sieci GSM. W sieci komórkowej GSM informacja o fizycznej „lokalizacji” uŜytkownika jest dostępna w VLR skojarzonym z centralą MSC, a informacja o tym, pod którym VLR jest obsługiwany dany uŜytkownik jest zawarta w profilu w HLR. Poprawna realizacja zgłoszeń w MSC odbywa się poprzez mechanizm „odpytania” HLR o aktualny adres VLR obsługującego uŜytkownika. Istnieje silna analogia pomiędzy HSS i S-CSCF, a HLR i MSC/VLR.
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
128
zgłoszenia do serwera aplikacyjnego jest realizowane poprzez wiadomości sygnalizacyjne,
które są wykorzystywane do zestawienia połączenia. Realizacja usług polega na interakcji ich
scenariuszy (implementowanych przez serwer aplikacyjny), z wiadomościami
sygnalizacyjnymi protokołu SIP generowanymi przez agentów uŜytkownika.
Decyzja czy dane zgłoszenie będzie skierowane do określonego serwera aplikacyjnego
jest podejmowana w serwerze S-CSCF na podstawie profilu uŜytkownika. Reguły
przekierowania zgłoszenia oparte są o analizę syntaktyczną wiadomości SIP. Profil
zawierający filtry IFC (patrz rozdział 3), definiuje rodzaje wiadomości (nazwy wiadomości
sygnalizacyjnych, np. INVITE, BYE, SUBSCRIBE, itd.), występowanie lub nie określonych
nagłówków we wiadomościach SIP oraz elementy opisu sesji zawartej w SDP. IFC ma postać
wyraŜeń złoŜonych z tych reguł w odpowiednich relacjach logicznych132. Tab. 5 pokazuje
parametry, które umoŜliwiają konstruowanie kryteriów IFC
Tab. 5: Reguły budowy kryteriów filtracji - IFC
Parametry do budowy
kryteriów filtracji
Znaczenie i moŜliwe wartości Przykład zastosowania
Request-URI Określa, do jakiego węzła SIP jest adresowana wiadomość. Zazwyczaj przyjmuje wartość publicznego identyfikatora wywoływanego uŜytkownika. Np. sip:[email protected]
Stosuje się zawsze tam, gdzie przy konstrukcji reguły waŜne jest, do kogo jest adresowana sesja. Przykładowo, jeŜeli serwer aplikacyjny realizuje usługę polegającą na blokowaniu połączeń na określony adres.
rodzaj Ŝądania MoŜe przyjmować wartości określające rodzaje Ŝądań. Np. INVITE, BYE, SUBSCRIBE, itd.
W przypadku usługi obecności, reguła przekierowania powinna uwzględniać wiadomości SUBSCRIBE i PUBLISH, które powinny być kierowane do serwera obecności133.
wartość określonego nagłówka
Składa się z nazwy nagłówka oraz z wartości, którą przyjmuje. Reguła wykorzystująca to pole moŜe stosować dowolne nagłówki. Np. ‘P-Access-Network-Info:
Nagłówki w wiadomościach SIP przenoszą bardzo wiele informacji. Przykładowo, jeśli obsługa w serwerach aplikacyjnych jest zaleŜna od sieci dostępowej uŜytkownika to moŜna do
132 Przekazywanie zgłoszenia do danego serwera aplikacyjnego w IMS oparte jest o syntaktyczna analizę wiadomości SIP. W modelu sieci inteligentnej (IN) przekazanie zgłoszenia do obsługi w SCP odbywa się w oparciu o analizę semantyczną tj. w oparciu o tzw. model BCSM (Basic Call State Model), który definiuje stany w realizacji połączenia. 133 Z dodatkowym warunkiem, określającym, Ŝe nagłówek ‘Event’ przyjmuje wartość ‘presence’.
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
129
access-type=3GPP-GERAN’ albo ‘P-Asserted-Identity: [email protected]’
rozróŜnienia zgłoszeń pochodzących z róŜnych sieci wykorzystać nagłówek ‘P-Access-Network-Info’, który przyjmuje wartość określające technikę dostępową z której korzysta dany uŜytkownik.
rodzaj sesji MoŜe przyjmować 3 wartości: 0 – dla połączeń wychodzących 1 – dla przychodzących 2 – dla przychodzących do niezarejestrowanego uŜytkownika
KaŜda reguła musi być przyporządkowana do określonego rodzaju sesji. Część usług jest wywoływana podczas zgłoszeń przychodzących (1 i 2) a część dla wychodzących (0). Przykładem zastosowania moŜe być usługa przekierowania sesji na inny adres wtedy, gdy dany uŜytkownik jest poza zasięgiem. W regule dla tego przypadku parametr rodzaj sesji przyjmowałby wartość 2.
parametry połączenia
Zawiera wyraŜenia regularne, które odnoszą się do SDP.
SDP zawiera informacje takie jak: rodzaj sesji medialnej (audio, wideo), kodowanie albo parametry QoS Ŝądane dla tego połączenia.
Analiza wiadomości SIP uwzględniająca reguły, złoŜone z parametrów zamieszonych w
Tab. 5, jest mechanizmem niskiego poziomu, odnoszącym się do składni przetwarzanych
wiadomości. Takie rozwiązanie daje bardzo duŜą elastyczność, ale wprowadza pewnego
rodzaju niejednoznaczność, polegającą na braku bezpośredniego odniesienia pomiędzy
usługami realizowanymi na serwerach aplikacyjnych, a kryteriami przekierowania. IFC
odnoszą się do składni protokołu, a nie do semantyki usług, które powinny wyzwalać.
Projektowanie reguł filtracji wymaga wypracowania tzw. „dobrych praktyk”, które dla dobrze
zdefiniowanych usług, oferowałyby gotowe najlepsze reguły IFC.
Profil uŜytkownika moŜe być złoŜony z wielu reguł odnoszących się do róŜnych usług i
skojarzonych z róŜnymi serwerami aplikacyjnymi. Potrzeba obsługi zgłoszenia przez wiele
serwerów aplikacyjnych wymaga prioryteryzacji kolejności przekierowań wiadomości SIP do
odpowiednich AS134. Rys. 61 pokazuje drogę wiadomości SIP podczas obsługi zgłoszenia w
wielu AS. KaŜdorazowo serwer S-CSCF dokonuje analizy profilu i przekierowania
134 Priorytet serwera aplikacyjnego jest zawarty w definicji IFC.
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
130
widomości do AS o odpowiednim priorytecie. Wynikiem tego mechanizmu jest przejście
wiadomości SIP przez tzw. „łańcuch serwerów aplikacyjnych”
S-CSCF
AS AS AS
uŜytkownik #A uŜytkownik #B
profil
sygnalizacja (SIP)
dane uŜytkowników (strumienie RTP)
Rys. 61: Sekwencyjne przetwarzanie zgłoszenia tzw. "ła ńcuch serwerów aplikacyjnych"
KaŜdy AS moŜe, zgodnie z logiką usługi, jaką realizuje, dokonać zakończenia
zgłoszenia. Powoduje to przerwanie „łańcucha serwerów aplikacyjnych” i AS, które
występują w profilu, a jeszcze nie brały udziału w obsłudze, są pomijane.
Serwer aplikacyjny (AS) otrzymując przekierowaną z S-CSCF wiadomość inicjującą
zgłoszenie, moŜe dokonać tzw. „zakotwiczenia” sesji. Polega to na odpowiedniej modyfikacji
wiadomości inicjującej, która jest zwracana do S-CSCF. Przy „zakotwiczonej” sesji w AS,
wszystkie wiadomości sygnalizacyjne protokołu SIP, które są wymieniane pomiędzy
terminalami uŜytkowników w ramach sesji, są kierowane poprzez „zakotwiczony” serwer
aplikacyjny.
S-CSCF
AS
uŜytkownik #A
sygnalizacja
(SIP)
uŜytkownik #B
1. IN
VITE
2. IN
VITE
4. IN
VITE
5. INVITE
6. 200 OK
7. 200 O
K
8. 200 O
K
9. 200 OK
3. wykonanie logiki usługi +
ewentualna modyfikacja
wiadomości INVITE
S-CSCF
AS
uŜytkownik #A uŜytkownik #B
1. BYE
2. BYE
3. BYE
4. BYE
S-CSCF
AS
uŜytkownik #A uŜytkownik #B
1. BYE 2. B
YE
1. 2a. 2b.
Rys. 62: Mechanizm "zakotwiczania" sesji SIP przez serwer aplikacyjny (AS)
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
131
Rys. 62 pokazuję obsługę zgłoszenia przez serwer aplikacyjny w róŜnych wariantach.
W punkcie 1. następuje inicjacja sesji za pomocą wiadomości INVITE, która jest
przekierowana do AS, który wykonuje logikę usługi. Wariant 2a. pokazuje scenariusz
zakończenia tej sesji w przypadku „zakotwiczenia” (wiadomość BYE jest kierowana do AS),
a wariant 2b. pokazuje scenariusz bez „zakotwiczenia”, w którym AS nie uczestniczy w
wymianie wiadomości BYE.
Serwer aplikacyjny, aby „zakotwiczyć” sesje wykorzystuje mechanizm kierowania
wiadomości protokołu SIP tj. tzw. „loose routing”135. Na Rys. 63 pokazany jest przepływ
wiadomości inicjującej sesje tj. wiadomości INVITE, która z S-CSCF zostaje skierowana do
AS. Aby dokonać „zakotwiczenia” AS modyfikuje wiadomość dodając do niej nagłówek
Record-Route zawierający adres danego AS. Zgodnie z mechanizmem „loose routing”,
terminal uŜytkownika w kolejnych wiadomościach w ramach sesji (tj. w ramach dialogu
protokołu SIP) będzie umieszczał informacje (w nagłówku Route), Ŝe dana wiadomość
powinna być skierowana na dany serwer aplikacyjny. W ten sposób kaŜda widomość w
ramach sesji będzie kierowana poprzez serwer aplikacyjny.
Rys. 63: Rola nagłówka 'Record-Route' w mechanizmie "zakotwiczenia" sesji
„Zakotwiczanie” sesji w AS jest silnie zaleŜne od logiki usługi, która jest realizowana.
Jeśli dana usługa wymaga kontrolowania sesji od jej inicjacji, aŜ do zakończenia niezbędne
135 Mechanizm „loose routing” jest opisany w [22].
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
132
jest „zakotwiczenie”. Natomiast w przypadku, gdy tylko moment inicjacji sesji jest istotny dla
realizacji danej usługi, „zakotwiczenie” nie jest potrzebne.
Obsługa sesji przez wiele serwerów aplikacyjnych jednocześnie umoŜliwia realizacje
wielu niezaleŜnych usług dla pojedynczego zgłoszenia. Rozwiązanie polegające na
kierowaniu przez S-CSCF wiadomości SIP do poszczególnych AS zgodnie z priorytetem
zapisanym w profilu uŜytkownika, wymusza zwiększony ruch sygnalizacyjny. KaŜde
przekierowanie do AS skutkuje ok. dwunastoma136 dodatkowymi wiadomościami
sygnalizacyjnymi.
Rys. 64: Typowy przepływ wiadomości inicjuj ącej sesje (z uwzględnieniem obsługi w AS)
Rys. 64 pokazuje przepływ wiadomości na styku pomiędzy S-CSCF a AS. KaŜde
wywołanie serwera aplikacyjnego w obsłudze zgłoszenia wymaga pośrednictwa AS we
wszystkich wiadomościach danej transakcji137 inicjującej, a w przypadku „zakotwiczenia”
całej sesji (dialogu SIP). Problem tak duŜego narzutu sygnalizacyjnego szczególnie jest
istotny w przypadku obsługi zgłoszenia przez kilka serwerów aplikacyjnych jednocześnie,
poniewaŜ wtedy ruch sygnalizacyjny rośnie wprost proporcjonalnie do ilości AS biorących
udział w obsłudze.
136 Dla typowego scenariusza inicjacji sesji bez uwzględnienia negocjacji parametrów QoS. 137 Transakcji protokołu SIP.
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
133
9.6 Interakcje pomiędzy usługami i serwerami aplikacyjnymi
Usługi w modelu IMS realizowane są za pomocą serwerów aplikacyjnych, do których
kierowane są zgłoszenia (sekwencje wiadomości SIP) zgodnie z profilem uŜytkownika. Profil
zawiera tzw. kryteria filtracji (IFC), które są regułami przekazania danego zgłoszenia do
odpowiedniego serwera aplikacyjnego. Mechanizm ten oparty jest o syntaktyczną analizę
wiadomości SIP polegającą na filtracji wiadomości za pomocą „pseudo” wyraŜeń regularnych
wychwytujących róŜne składowe wiadomości SIP (np. nagłówki i ich wartości, składowe
SDP).
Definicja IFC musi odzwierciedlać zakres funkcji, które są realizowane przez dany
serwer aplikacyjny. Rys. 65 ilustruje przykład, w którym AS pełni funkcje serwera obecności
(Presence Server). Reguły IFC zawierają wyraŜenia określające, Ŝe wiadomości PUBLISH i
SUBSCRIBE138 dla zgłoszeń przychodzących powinny być skierowane właśnie do tego
serwera aplikacyjnego, czyli właściwego serwera obecności. Obsługa innych zgłoszeń
(zgłoszenie 2) nie jest przekazywana do AS.
2. PUBLISH
3. 200 O
K
Rys. 65: ZaleŜność pomiędzy IFC a funkcją realizowaną przez dany AS (na przykładzie serwera
obecności)
Występowanie problemów opisanych w rozdziale 9.5, związanych z przeciąŜeniem
wiadomościami sygnalizacyjnymi nakłada wymaganie, aby definicje filtracji (IFC) bardzo
szczegółowo określały zakres zgłoszeń, których obsługa będzie kierowana do serwera
aplikacyjnego. Dzięki takiej precyzyjnej, uwzględniającej specyfikę logiki realizowanej na
AS definicji, moŜliwe jest obsługiwanie zgłoszeń na wielu serwerach aplikacyjnych, które
138 Znaczenie wiadomości SUBSCRIBE i PUBLISH w realizacji usługi obecności wyjaśniona jest w rozdziale 10.5
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
134
realizują róŜne usługi. KaŜde zgłoszenie jest kierowane do właściwego AS zgodnie z IFC
zawartym w profilu. Taki mechanizm umoŜliwia częściowe rozwiązanie problemów
związanych z interakcjami pomiędzy usługami, ale tylko, jeśli są one realizowane na róŜnych
serwerach aplikacyjnych. Jeśli w sieci jest więcej niŜ jeden AS wymagający obsługi danego
zgłoszenia, to realizacja usług następuje sekwencyjne, zgodnie z mechanizmem „łańcucha
serwerów aplikacyjnych”, który został opisany w rozdziale 9.5. Kolejność obsługi
uzaleŜniona jest od priorytetu podanego w IFC.
Jeden Serwer aplikacyjny moŜe wykonywać scenariusz jednej usługi lub wielu usług.
Takie modele implementacji są pokazane na Rys. 66, który przedstawia moŜliwy podział AS
na dwa rodzaje: dedykowany, czyli taki który realizuje tylko jedną usługę i ogólnego
zastosowania, realizujący kilka niezaleŜnych usług.
Rys. 66: Dwa modele serwerów aplikacyjnych: ogólnego zastosowania i dedykowany
W przypadku AS ogólnego zastosowania, pojawia się powaŜny problem związany z
interakcjami pomiędzy usługami w ramach jednego serwera aplikacyjnego. W modelu z
dedykowanymi AS, interakcje rozwiązywane są za pomocą filtracji IFC oraz „łańcucha
serwerów aplikacyjnych”, czyli S-CSCF zarządza potrzebą i kolejnością wykonywania usług
korzystając z profilu uŜytkownika. Natomiast w przypadku wielu niezaleŜnych usług
realizowanych na jednym AS, zasadność obsługi zgłoszenia i kolejność musi być
rozstrzygana wewnętrznie tj. w ramach danego AS. Aby rozwiązać problem interakcji
pomiędzy usługami w IMS został wprowadzony element funkcjonalny SCIM (Service
Capability Interaction Module), który jest częścią składową serwera aplikacyjnego (patrz
Rys. 67).
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
135
S - CSCF S - CSCF
SIP Application Server
SIP Application Server
HSS HSS OSA service
capability server (SCS)
OSA service capability server
(SCS)
IM - SSF IM - SSF
Camel Service Environment
Camel Service Environment
OSA application
server
OSA application
server
ISC
Cx ISC
ISC
CAP MAP
OSA API
SCIM
AS AS
Sh
Si
Rys. 67: Architektura funkcjonalna warstwy aplikacyjnej IMS ( źródło [3])
W modelu implementacji wielu usług na jednym serwerze aplikacyjnym reguły
„filtracji” wiadomości SIP muszą być analizowane dwa razy dla zgłoszenia, tj. w serwerze S-
CSCF oraz w danym AS zawierającym komponenty aplikacyjne realizujące usługi. Rys. 68
ilustruję te mechanizmy. Przychodząca wiadomość (patrz 1.) od uŜytkownika A do
uŜytkownika B jest zgodnie z regułami zawartymi w profilu pobranym z HSS, kierowana do
AS (wiadomość 2.). Następnie, w ramach wewnętrznych mechanizmów
zaimplementowanych w AS, zgłoszenie jest dystrybuowane do odpowiednich komponentów
aplikacyjnych.
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
136
usługa #A
usługa #B
usługa #C
usługa #D
2.
7.
profil
3.
4.
5.
6.
Rys. 68: Rola SCIM w obsłudze zgłoszenia w ramach serwera aplikacyjnego
Warte zauwaŜenia jest to, Ŝe dokumenty 3GPP definiujące IMS specyfikują tylko
mechanizm filtracji w S-CSCF bazujący na profilu uŜytkownika. Funkcje SCIM są
definiowane tylko w bardzo ogólny, koncepcyjny sposób i większość mechanizmów SCIM
zaleŜy od implementacji danego serwera aplikacyjnego.
Implementacja wielu usług na jednym serwerze aplikacyjnym jest korzystna ze względu
na oszczędność zasobów związanych z mocą obliczeniową serwerów oraz ze względu na
ograniczenie ruchu sygnalizacyjnego na styku pomiędzy S-CSCF a AS. Negatywną strona
takiego modelu jest to, Ŝe aplikacje realizujące usługi są silnie związane ze środowiskiem
specyficznym dla danego serwera aplikacyjnego, co skutkuje ich ograniczoną
przenaszalnością do innych AS.
10. Analiza i implementacja interfejsów Parlay X w
modelu usługowym IMS
IMS pozostawia duŜą swobodę przy implementacji aplikacji realizujących usługi.
MoŜemy skorzystać z wielu technik139, dla których środowiskiem uruchomieniowym są
serwery aplikacyjne, np.: omawiany JSLEE (patrz rozdział 1), ale i nie tylko. Wybór
odpowiedniej techniki powinien być umotywowany zarówno wymaganiami technicznymi
(aspekty bezpieczeństwa i skalowalności, wybór pomiędzy środowiskiem webowym, a
aplikacją stacjonarną, etc..) jak i równieŜ biznesowymi (kto będzie tworzył aplikacje, kto jest
odbiorcą aplikacji, jaki model biznesowy jest optymalny, etc..).
Spośród dostępnych technik i propozycji modeli warstwy aplikacyjnej autorzy
wybrali140 ten najbardziej złoŜony141. Struktura wybranego modelu warstwy aplikacyjnej
została pokazana na Rys. 41, natomiast techniki uŜyte do jej implementacji to Parlay X (patrz
rozdział 1) i JSLEE. W ostateczności JSLEE został zastąpiony techniką JAIN, poniewaŜ przy
analizie i próbie stworzenia przykładowej aplikacji w implementacji JSLEE pod nazwą
Mobicents142, okazało się, Ŝe aplikacja nie zachowywała się stabilnie i deterministycznie. W
139 PobieŜny przegląd technik wykorzystywanych do implementacji usług telekomunikacyjnych w IMS został zawarty w [13]. Warto zwrócić uwagę, iŜ do celów tworzenia usług w IMS zaadoptowano istniejące juŜ techniki webowe: np. servlety, czy teŜ implementowane przez autorów Web Services Parlay. 140 Początkowo rozwaŜaliśmy wybór techniki, którą mieliśmy wykorzystać do implementacji aplikacji usługowej Własne Centrum Komunikacyjne zarówno od strony biznesowej, jak i od strony technicznej. Stwierdziliśmy jednak, iŜ wybór powinien zostać dokonany wyłącznie pod kątem technicznym ze względu na fakt, iŜ implementowane środowisko ma charakter wyłącznie czysto badawczy, a skupienie się nad jedną kwestią pozwoli szczegółowej i precyzyjniej omówić jej zalety i wady. Nie czuliśmy się równieŜ na siłach, aby zabierać głos w kwestiach biznesowych. 141 Po wstępnej analizie projektów związanych z Parlay/OSA i Parlay X zauwaŜyli śmy, Ŝe wszystkie omawiają kwestię wykorzystania Parlay X do implementacji usług, natomiast Ŝaden nie dyskutuje problematyki implementacji samych interfejsów Parlay X. Uznaliśmy, Ŝe jest to ciekawe zagadnienie i postanowiliśmy przyjrzeć się jemu uwaŜniej w naszej pracy. Poza tym nie spotkaliśmy się równieŜ z pomysłem implementacji Parlay X jako aplikacji JSLEE, a co za tym idzie, jakie konsekwencje ze sobą moŜe nieść takie podejście. Dodatkową korzyścią płynącą z wyboru najbardziej złoŜonego modelu usługowego jest chęć zaobserwowania równieŜ kwestii czysto fizycznych tj. wydajność, przeciąŜenie, opóźnienia, itp.. 142 NaleŜy przypomnieć, Ŝe jest to projekt open source, w którym wiele rzeczy pozostaje tajemnicą nawet dla jego twórców. Znaleźli śmy róŜnego rodzaju niedomówienia w jego implementacji, a ich naprawa mogła by być dobrym tematem na kolejną pracę magisterską lub inŜynierską, ze względu na duŜą złoŜoność projektu. RównieŜ wbrew pozorom duŜa złoŜoność procesu przygotowywania aplikacji (deskryptory, duŜa liczba typy obiektów, brak dokumentacji, itp..) bez wsparcia narzędzi programistycznych uniemoŜliwia pisanie bardziej zaawansowanych aplikacji.
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
138
efekcie JAIN okazał się pouczającym wyborem, poniewaŜ pozwolił poznać zarówno wady
jak i zalety względem wcześniej przeanalizowanej techniki JSLEE.
Rys. 69: Interfejsy Parlay X
Na Rys. 69 pokazano interfejsy, które obejmuje specyfikacja Parlay X, a na zielono
zaznaczono, te które zostały zaimplementowane. W procesie wyboru tych interfejsów
kierowano się późniejszą moŜliwością stworzenia aplikacji143, której funkcjonalność
pozwalałby na zarządzanie własną komunikacją w sieci stacjonarnej (przekierowanie
połączeń, blokowanie połączeń, zestawienia połączenia pomiędzy dwoma stronami, usługa
obecności, etc..).
10.1 Sterowanie zestawianiem połączeń przez trzecią stronę
(interfejs Third Party Call)
10.1.1 Definicja i zastosowania
Third Party Call Control (3PCC) jest terminem określającym funkcjonalność oraz
mechanizm umoŜliwiający zestawienie i zarządzanie sesją komunikacyjną przez Trzecią
Stronę pomiędzy dwoma lub większą liczbą uczestników (Stronami)144. Trzecia Strona
nazywana jest równieŜ Sterownikiem (Controller). W rozumieniu powyŜszej definicji moŜe to
być dowolny SIP User Agent. Do zestawienia sesji komunikacyjnej wykorzystywane są
mechanizmy zdefiniowane w specyfikacji protokołu SIP. Ze względu na duŜą elastyczność
143 Aplikacja ta została omówiona w rozdziale11. 144 Definicja Third Party Call Control została zaczerpnięta z [26]. Ze względu na charakter interfejsów Parlay X: Third Party Call Control w dalszej części tego opracowania będzie rozwaŜane zestawienie połączenia wyłączenie pomiędzy dwoma stronami.
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
139
protokołu SIP istnieje wiele sposobów realizacji 3PCC145. Te róŜne podejścia zostaną
przedstawione w 10.1.3.
Jako przykład zastosowania 3PCC warto wskazać usługę Click-to-Call , dla której
przykładowy scenariusz został przedstawiony poniŜej (patrz Scenariusz 1). Dla tej usługi
3PCC rozszerza funkcjonalność rozwiązań webowych. Pojawia się w związku z tym potrzeba
stworzenia narzędzi umoŜliwiających budowę tego typu usług w standardowy sposób.
Jednym z takich narzędzi jest interfejs Pralay X: Third Party Call Control wykorzystujący
Web Services.
Scenariusz 1: Przykładowy scenariusz dla usługi Click-to-Call
UŜytkownik przeglądając stronę internetową pewnej firmy jest zainteresowany jednym z ich
produktów. Obok opisu produktu znajduje się formularz click-to-call. Po wprowadzeniu
swojego numeru telefonu, firma zestawi automatycznie połączenie pomiędzy nim, a
odpowiednim konsultantem.
10.1.2 Specyfikacja interfejsu
Interfejs Third Party Call Control został wyspecyfikowany w dokumencie146 [8].
Funkcjonalność interfejsu Third Party Call Control pozwala na:
� zestawienie sesji – funkcja:
xsd:string MakeCall(xsd:anyURI CallingParty, xsd:anyURI CalledParty)
Parametrami dla tej funkcji są adresy stron w postaci URI, pomiędzy którymi ma
być zestawiona sesja. Funkcja zwraca unikalny CallIdentifier, który moŜna
wykorzystać do zarządzania zgłoszeniem i monitorowania jego stanu.
� zakończenie sesji – funkcja:
void EndCall(xsd:string CallIdentifier)
Parametrem wejściowym dla tej funkcji jest identyfikator połączenia, który został
zwrócony przez funkcję MakeCall(...) przy zestawianiu połączenia.
� anulowanie zestawiania sesji – funkcja:
void CancelCall(xsd:string CallIdentifier)
145 Charakter dokumentów IETF, w których została zawarta specyfikacja protokołu SIP pozwala na dość swobodne wykorzystywanie wiadomości SIP. Wynika to z braku jednoznacznego opisu protokołu jako np. automatu FSM (brak definicji stanów i wszystkich moŜliwych przejść pomiędzy nimi). 146 Szczegółowy opis interfejsów został zapisany przy uŜyciu języka WSDL 1.2 i załączony jako pliki XML do specyfikacji.
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
140
� określenie stanu sesji – funkcja
xsd:CallInformation GetCallInformation(xsd:string CallIdentifier)
Funkcja ta pozwala uzyskać informacje na temat stanu połączenia o danym
CallIdentifier. MoŜe być wywoływana wielokrotnie po przez aplikację nawet po
zakończeniu połączenia, a czas dostępności informacji o zgłoszeniu po jego
zakończeniu określa zmienna StatusRetentionTime .
Na Rys. 70 wyszczególniono funkcje, które zostały zaimplementowane w serwerze
sterowania połączeniami.
CancelCall
EndCall
GetCallIn
form
atio
n
MakeCall
Rys. 70: Funkcje interfejsu Parlay X: Third Party Call Control
10.1.3 Propozycje rozwiązania problemu
Problematykę 3PCC moŜna podzielić na 4 części: proces zestawienia sesji, informacje o
sesji, modyfikacje sesji oraz zakończenie sesji. W kaŜdym z tych procesów mogą wystąpić
sytuacje wyjątkowe147. Jednak ze względu na fakt, iŜ tematyka 3PCC nie jest głównym celem
tej pracy pominięty zostanie wątek sytuacji wyjątkowych, a główny nacisk zostanie połoŜony
na proces zestawiania sesji.
Zestawianie sesji (Call Establishment)
� Sposób I zestawiania sesji przez trzecią stronę
147 Szczegółowa analiza sytuacji wyjątkowych znajduje się w dokumencie IETF RFC 3725 [26].
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
141
Rys. 71: Diagram wiadomości dla sposobu I zestawiania sesji przez trzecią stronę
Przedstawiony na Rys. 71 przepływ wiadomości jest najprostszym sposobem
zestawienia sesji komunikacyjnej. Sterownik rozpoczyna dialog SIP z sip:user_a@eims
wysyłając do niego widomość (1) INVITE bez opisu sesji148. W odpowiedzi otrzymuje ofertę
(2) od sip:user_a@eims, która nie podlegając Ŝadnym modyfikacjom stanowi opis sesji dla
wiadomości (3) INVITE wysłanej do sip:user_b@eims. Sip:user_a@eims odsyła (4)
odpowiedź, która jest jednocześnie odpowiedzią (6) dla sip:user_a@eims. Zadaniem
Sterownika jest przekazywanie SDP bez Ŝadnych modyfikacji, sterownik w tym przypadku
jest praktycznie przeźroczysty dla całego dialogu pomiędzy stroną A i B. Brak jest równieŜ
ograniczeń dotyczących kodeków, wspieranych przez obie strony. Słabą stroną
przedstawionego rozwiązania 3PCC jest natomiast potencjalny problem przekroczenia
czasów oczekiwania na odpowiedź149 (time-out) zdefiniowanych w [22]. W takiej sytuacji
sip:user_a@eims dokonuje retransmisji widomości (2a) 200 OK oczekując na wiadomość (6)
ACK. W przypadku, gdy połączenie nie zostanie zaakceptowane przez sip:user_b@eims w
zdefiniowanym przedziale czasu sip:user_a@eims zakończy dialog z błędem.
� Sposób II zestawiania sesji przez trzecią stronę
148 Opis sesji przenoszony jest za pomocą protokołu SDP – Session Description Protocol [30]. 149 Zgodnie RFC 3261 Sekcja 13.3.1.4 przedział czasowy, w którym następuje cykliczne wysłanie wiadomości 200 OK w trakcie oczekiwania na ACK wynosi 64*T1. Standardowo T1 przyjmuje się 500 ms RFC 3261 Sekcja 17.1.1.2.
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
142
Rys. 72: Diagram wiadomości dla sposobu II zestawiania sesji przez trzecią stronę
W mechanizmie 3PCC zaprezentowanym na Rys. 72 został rozwiązany problem
przekroczenia czasów odpowiedzi, o którym była mowa przy I sposobie zestawiania
połączenia. Dokonano tego poprzez zamknięcie w załoŜonym limicie czasu transakcji
rozpoczętej przez wiadomość (1) i wykorzystaniem funkcjonalności re-INVITE.
Wiadomość (1) INVITE zostaje wysłana z losowo wygenerowanym numerem portu,
konkretnym kodekiem oraz adresem połączenia ustawionym na 0.0.0.0. Jest to tzw. black
holed address150, który sprawia, Ŝe strumień mediów RTP/RTCP nie zostanie wysłany do
sieci. NaleŜy tu wspomnieć, iŜ ze stosowaniem black holed address wiąŜe się
niebezpieczeństwo, Ŝe dana implementacja SIP UA, w odpowiedzi na (2) wyśle równieŜ adres
0.0.0.0, co spowoduje, Ŝe juŜ po zestawieniu sesji media od sip:user_a@eims nie będą
płynęły. Ze względu na wspomnianą wadę mechanizmu black holed address coraz częstszym
podejściem jest zastąpienie jego przez zestaw atrybutów send-only, receive-only151. W tym
przypadku w SDP podaje się normalny adres, na który w przyszłości będą ewentualnie
wysyłane media.
Innym powaŜnym problemem moŜe być powstanie pętli na skutek przesłania w
odpowiedzi (8) innego niŜ w odpowiedzi (2) kodeka. W konsekwencji sterownik powinien
ponownie wynegocjować kodek z sip:user_b@eims dokonując re-INVITE, po czym dokonać
150 Black holed address – mechanizm opisany w [23]. Mechanizm ten rodzi istotne zastrzeŜenia ze względu na uŜycie adresu 0.0.0.0, który w róŜnych rodzajach sieci moŜe być roŜnie interpretowany. Zaleca się, aby jako black holed address uŜywać nazwy nieistniejącej głównej domeny DNS. 151 UŜycie atrybutów send-only i receive-only zostało opisane w [23].
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
143
re-INVITE z sip:user_a@eims. Zakładając, Ŝe sip:user_a@eims zwróci inne SDP niŜ
poprzednio, taki proces moŜe powtarzać się w nieskończoność. Rozwiązaniem, moŜe być
uŜycie inteligentnych UA lub inteligentnego kontrolera, które będą wstanie wykryć taki
przypadek.
� Sposób III zestawiania sesji przez trzecią stronę
Rys. 73: Diagram wiadomości dla sposobu III zestawiania sesji przez trzecią stronę
Prezentowany na Rys. 73 sposób zestawienia sesji przez trzecią stronę rozwiązuje
problemy istniejące w poprzednich sposobach. Po pierwsze Sterownik nie musi nic wiedzieć
na temat rodzaju mediów, gdyŜ w pierwszej widomości (1) INVITE nie zostaje wysłany opis
sesji. Wykorzystanie mechanizmu black holed address sprawia, Ŝe sip:user_a@eims nie
wysyła strumienia mediów. Potencjalne nie występuje równieŜ problem przekroczenia
załoŜonych czasów oczekiwania, gdyŜ wszystkie wiadomości są natychmiast potwierdzane
(ACK). Jedynie istotne jest, aby implementacja SIP UA152 odpowiedziała w załoŜonym
limicie czasu na przesłaną przez Sterownik wiadomość re-INVITE, ze względu na koniczność
zamknięcia transakcji zestawiania połączenia z sip:user_b@eims krok (8).
Wadą tego rozwiązania jest konieczność ingerencji Sterownika w opis sesji. W efekcie
Sterownik ma większą złoŜoność niŜ w poprzednich przypadkach. Słabą stroną jest równieŜ
wykorzystanie mechanizmu black holed address, którego skutki zostały opisane powyŜej.
152 W tym przypadku przesłanie odpowiedzi na drugą wiadomość INVITE w odróŜnieniu od wcześniej analizowanego przypadku realizowane jest automatycznie przez UA.
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
144
NaleŜy równieŜ zauwaŜyć, Ŝe lista mediów w ofercie (2) uzyskana od sip:user_a@eims moŜe
nie pokrywać się z lista mediów w odpowiedzi (5) od sip:user_b@eims. Sterownik w tym
przypadku powinien zakończyć dialog.
� Sposób IV zestawiania sesji przez trzecią stronę
Na diagramie wiadomości IV (patrz Rys. 74) została przedstawiona zmodyfikowana
wersja diagramu III w efekcie, której nastąpiła nieznaczna redukcja złoŜoności. RównieŜ brak
oferty mediów w ciele pierwszej wiadomości (1) INVITE zwalnia Sterownik z konieczności
posiadania informacji na temat mediów obsługiwanych przez sip:user_a@eims.
Rozwiązanie te posiada istotną wadę związaną z brakiem pewności, czy w ramach
zainicjowanej sesji komunikacyjnej strony obsługują wspólny typ mediów i czy faktycznie
pomiędzy stronami będzie moŜliwość zestawienia strumienia mediów. ZauwaŜmy, iŜ dopiero
w kroku (7) następuje potwierdzenie zgodności typu mediów, przy czym strony (np.
uŜytkownicy) zostały poinformowane i odebrały wcześniej (sip:user_a@eims po wiadomości
(2), a sip:user_b@eims po wiadomości (5)) przychodzące zgłoszenie. Sytuacja, w której
połączenie zostało zaakceptowane obustronnie nie przez automat, a przez człowieka moŜe
być dla niego irytująca, gdy na początku przez pewien okres czasu nie słyszy ona swojego
rozmówcy.
sip: user_a@eims
(1) INVITE oferta1 bez mediów
(2) 200 OK odpowiedź2 bez mediów
(4) INVITE bez SDP
(5) 200 OK oferta2
(3) ACK
(8) ACK odpowiedź2
sterownik sip: user_b@eims
(6) INVITE oferta2
(7) OK odpowiedź2
(9) ACK
Strumień Mediów (RTP/RTCP)
<dzwoni>
<dzwoni>
Rys. 74: Diagram wiadomości dla sposobu IV zestawiania sesji przez trzecią stronę
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
145
Tab. 6: Zestawienie cech poszczególnych sposobów realizacji 3PCC.
Diagram I Diagram II Diagram III Diagram IV ZłoŜoność Prosty ZłoŜony Bardzo złoŜony ZłoŜony Black holed153 Nie Tak Tak Nie Problem time-out Tak Nie Nie Nie ZałoŜenia o mediach
Nie Tak Tak Nie
Inne MoŜliwość wystąpienia pętli
Nie ma gwarancji, Ŝe terminale mają zgodne kodeki
W efekcie, moŜe nie zostać zestawiony strumień mediów
Kończenie sesji
Od momentu zestawienia sesji, strony nie mają świadomości, iŜ pomiędzy nimi
znajduje się Sterownik. Co prawda Sterownik nie pośredniczy w wymianie strumienia
mediów jednak transakcja SIP związana z zakończeniem sesji komunikacyjnej powinna być
realizowana równieŜ po przez Sterownik. Wynika to z faktu, iŜ Sterownik jest zaangaŜowany
w dialog w sensie RFC 3261 pomiędzy dwoma stronami. Dlatego teŜ wiadomość BYE,
wysłana przez którąkolwiek stronę powinna zostać przekazana przez Sterownik drugiej
stronie, po czym przesłane Ŝądania BYE powinny zostać potwierdzone wiadomością OK (por.
Rys.75).
Istotną kwestią jest moŜliwość modyfikacji parametrów sesji komunikacyjnej podczas
jej trwania za pomocą mechanizmu re-INVITE. W tej sytuacji, odebranie przez Sterownik
widomości INVITE powinno skutkować przekazaniem jej do drugiej strony. Oczywiście w
zaleŜności od tego jaki został wybrany sposób realizacji 3PCC, Sterownik odpowiednio
powinien zmodyfikować SDP.
153 Potencjalnie istnieje moŜliwość zastąpienia mechanizmu black holed address poprzez odpowiednie uŜycie atrybutów sendonly i receiveolny.
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
146
Rys.75 Diagram wiadomości w przypadku kończenia sesji przez jedną ze stron
10.1.4 Implementacja
Po przeanalizowaniu wad i zalet (patrz Tab. 6) róŜnych rozwiązań realizacji 3PCC, do
celów implementacji Serwera Sterowania Połączeniami został wybrany pierwszy sposób. Jak
juŜ wcześniej zostało wspominane jest on najmniej złoŜony, poza tym nie wprowadza
ograniczeń na rodzaj mediów. W testach154 zostało równieŜ zauwaŜone, Ŝe czasy oczekiwania
przez UA na wiadomość ACK w brew pozorom nie są takie krótkie (powyŜej 1 min.), co jest
w zupełności wystarczające, nawet jeśli po obu stronach korzystającymi są ludzie. W tym
przypadku problem związany z time-out’ami schodzi na drugi plan.
Architektura
Architektura Serwera Sterowania Połączeniami oraz sposób połączenia go z aplikacją
wykorzystującą jego funkcjonalność została zaprezentowana na Rys. 76. Serwer ten składa się
z 3 części:
� interfejsu Web Services dla 3PCC Parlay X,
� szkieletu i zrębu- RMI155,
� rdzenia aplikacji156 napisanego z wykorzystaniem bibliotek JAIN SIP.
Interfejs Web Services dla 3PCC reprezentowany jest po przez zbiór klas
odpowiadających poszczególnym metodom, które zostały wygenerowane automatycznie na
podstawie opisującego je kodu WSDL załączonego do specyfikacji. Implementacje metod
154 Testy zostały przeprowadzone z uŜyciem dwóch róŜnych UA: pierwszy IP SoftPhone X-Lite 3.0 firmy Xten Networks, Inc. oraz IP Phone Policom 410. 155 RMI – Remote Method Invocation – jest to mechanizm Javy, słuŜący zdalnemu wywoływaniu obiektów. Architektura RMI bazuje na dwóch elementach: stub i skeleton. Wywoływanie zdalne metod realizuje się lokalnie na skeleton’ie, po czym parametry zostają serializowane i trafiają do stub’a, gdzie następuje wykonanie docelowych metod. 156 Określenia autora wskazujące element architektury aplikacji, w którym znajduje się logika 3PCC.
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
147
naleŜących do tego interfejsu są częścią aplikacji webowej157 rozmieszczonej na serwerze
aplikacyjnym. Dodatkowo aplikacja ta zawiera klasy pomocnicze słuŜące przygotowaniu i
procesowaniu wiadomości SOAP158.
Skeleton i Stub są obiektami umoŜliwiającymi zdalną komunikację przy wykorzystaniu
mechanizmu RMI. Skeleton implementuje metody z interfejsu 3PCC po stronie aplikacji
webowej (wchodzi w jej skład), natomiast Stub po stronie rdzenia aplikacji.
� Logika 3PCC zlokalizowana jest w rdzeniu aplikacji. Rdzeń aplikacji obejmuje 4 klasy:
� sterownik, klasa: ThirdPartyCallController – odpowiedzialna jest za uruchomienie
Serwera Sterowania Połączeniami (załadowanie konfiguracji z pliku XML159),
skreowanie wymaganych obiektów m.in. stosu JAIN SIP, instancji klasy
ThirdPartyCallApplication oraz ThirdPartyCallAdapter .
� adapter, klasa: ThirdPartyCallAdapter. Klasa ta mapuje wywołania metod
interfejsu Web Services na wywołania odpowiednich metod z klasy
ThirdPartyCallApplication .
� aplikację, klasa: ThirdPartyCallApplication . Klasa ta zawiera logikę Serwera
Sterowania Połączeniami. Szczegółowa budowa i zasada działania tej klasy zostanie
omówiona poniŜej.
� stan aplikacji dla określonego dialogu, klasa TaskState . Jest klasą pomocniczą,
przechowującą stan dialogu oraz zmienne pomocnicze jak np. oferty mediów,
referencje na obiekty dialogu oraz transakcji pomiędzy sterownikiem, a stronami,
adresy URI stron, itp..
157 NaleŜy zauwaŜyć, Ŝe aplikacja webowa zgodna ze specyfikacją J2EE ma określoną strukturę. Oprócz klas, w których zaimplementowana została logika istnieje zbiór plików z meta-danymi. 158 SOAP – Simple Object Application Protocol (patrz [47]) 159 W pliku przekazywane są m.in. informacje na temat adresu IP, do którego powinien połączyć się stos JAIN SIP, numer portu, na którym będzie nasłuchiwał.
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
148
Serw
er HTTP
Apache + PHPP
rzeglądarka
WWW
Serw
er Aplikacyjny
Tomcat + Axis 2
Aplikacja 3PCC
(JAIN SIP)
Serw
er Sterowania Połączeniami
Rys. 76: Diagram interakcji pomiędzy poszczególnymi elementami przy zestawianiu połączenia przez
trzecią stronę na tle architektury Serwera Sterowania Połączeniami.
Zasada działania
Zasada działania Serwera Sterowania Połączeniami oraz interakcje pomiędzy
poszczególnymi elementami architektury usługowej zostały przedstawione na Rys. 76.
Wypełnienie formularza HTML na stronie WWW i wciśnięcie przycisku Make Call
powoduje wysłanie Ŝądania GET (1) do serwera WWW z wartościami parametrów
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
149
wprowadzonych w poszczególne pola. Na serwerze WWW zostaje uruchomiony skrypt PHP i
zostają wywołane odpowiednie metody przygotowujące wiadomość SOAP do wysłania (2).
Serwer Sterowania Połączeniami zgodnie z nomenklaturą Web Services nazywa się
Dostawcą Web Services (Web Services Provider). Otrzymuje on od śądającego Web Services
(Web Services Requestor) wiadomość SOAP (3), która zawiera zdalne wywołanie metody
xsd:string MakeCall(xsd:anyURI CallingParty, xsd:anyURI CalledParty)
znajdującej się w Web Services 3PCC na serwerze aplikacyjnym. Na podstawie tej
wiadomości następuje wywołanie odpowiedniej funkcji (4), która to wywołuje na Szkelecie
RMI zdalnie metodę public String makeCall(URI callingParty, URI calledParty) z
klasy ThirdPartyCallAdapter . Natomiast w ciele funkcji makeCall(...) z klasy
ThirdPartyCallAdapter znajduje się wywołanie funkcji z klasy
ThirdPartyCallApplication , która realizuje konkretną logikę.
Klasa ThirdPartyCallApplication składa się z części synchronicznej (metody
MakeCall(...) , EndCall(...) , …) i asynchronicznej. Cześć asynchroniczna implementuje
interfejsy JAIN SIP ProcessRequest(...) , ProcessResponse (...) odpowiedzialne za
przetwarzane przychodzących Ŝądań i odpowiedzi SIP.
Ze względu na fakt, iŜ do obsługi wszystkich zgłoszeń wykorzystana jest jedna
instancja ThirdPartyCallApplication , wymagane jest odrębne przechowywanie informacji
skojarzonej z poszczególnymi sesjami. Do tego celu słuŜy wcześniej wspomniana klasa
TaskState . KaŜda sesja identyfikowana jest jako ciąg znaków połączonych Call-ID dialogów
pomiędzy Sterownikiem, a Stronami.
Zadaniem klasy jest poprawna realizacja wybranego scenariusza 3PCC związanego z
zestawianiem sesji oraz jej rozłączaniem. Zachowanie się klasy zostało zobrazowane na Rys.
78 jako diagram SDL160, a przykładowy scenariusz tworzenia obiektów i interakcji między
nimi na diagramie UML Rys. 77.
160 Service Description Language – jest językiem wykorzystywanym do opisu procesów systemów rozproszonych.
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
150
Rys. 77: Diagram UML z wywołaniami funkcji dla przykładowego procesu zestawiania sesji i
uruchamiania serwera.
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
151
Rys. 78: Logika Serwera Sterowania Połączeniami w postaci diagramu SDL.
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
152
10.2 Obsługa połączeń (interfejs Call Handling)
Pod terminem obsługa połączeń (w jęz. angielskim: call handling) rozumie się grupę
usług, których realizacja jest związana z odpowiednim przetwarzaniem przychodzących i
trwających połączeń. Przykładami usług naleŜących do takiej grupy mogą być usługi takie
jak: akceptowanie połączenia (ang. call accepting), blokowanie połączenia (ang. call
blocking), czy teŜ przekierowanie połączenia (ang. call forwarding).
Usługi te naleŜą równieŜ do standardowych usług świadczonych w sieciach
telekomunikacyjnych TDM (PSTN, ISDN, GSM). MoŜna pokusić się o stwierdzenie, Ŝe są
podstawowymi komponentami usługowymi z punktu widzenia uŜytkownika, z których moŜna
budować bardziej zaawansowane usługi telekomunikacyjne. Przykładem moŜe być integracja
usługi przekierowania połączenia z usługą lokalizacji, a scenariusz moŜe wyglądać
następująco. UŜytkownik ma moŜliwość zdefiniowania sobie róŜnych obszarów. Do tak
zdefiniowanych obszarów moŜe przypisać odpowiednio np.: usługę bezwarunkowego
przekierowania połączenia na wskazany numer. Niech jednym ze zdefiniowanym obszarów
będzie biuro, wówczas kaŜde połączenie przychodzące do uŜytkownika w momencie, gdy
znajduje się on w biurze zostanie przekierowanie na telefon stacjonarny (choćby ze względu
na fakt, iŜ telefon stacjonarny oferuje lepszą jakość). MoŜna sobie wyobrazić, Ŝe potencjalna
liczba usług wykorzystujących te bazowe usługi jest duŜa.
ParlayX – Call
Handling
ClearR
ules
GetRules
SetR
ulesForG
roup
SetR
ules
implementowane w ramach środowiska badawczego
Rys. 79: Funkcje interfejsu Parlay X: Call Handling
10.2.1 Specyfikacja interfejsu Parlay X: Call Handling
Ze względu na duŜe znaczenie usług typu call handling jako podstawowych
komponentów, z których moŜna tworzyć bardziej zaawansowane usługi telekomunikacyjne
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
153
zostały one równieŜ włączone w specyfikację interfejsów Parlay X. Specyfikacja (patrz [8],
część 10) obejmuje następujące usługi:
� Akceptowanie połączeń;
� Blokowanie połączeń;
� Bezwarunkowe przekierowanie połączenia;
� Warunkowe przekierowanie połączenia (UA jest zajęty, UA nie odbiera
przychodzącego połączenia przez określony czas).
Usługom tym odpowiadają funkcje161 interfejsu Parlay X: Call Handling, wyszczególnione na
Rys. 79. Wybrane funkcje zaznaczone na zielono zostały zaimplementowane w serwerze
obsługi połączeń, a poniŜej znajduje się szczegółowy ich opis:
void setRules(xsd:anyURI Address, CallHandlingRules Rules)
Funkcja ta ustawia zbiór reguł (ang. rules) typu CallHandlingRules dla numeru162,
na który przychodzi połączenie. W przypadku, gdy dla danego numeru został
przypisany zbiór reguł, ponowne wywołanie tej funkcji spowoduje ich nadpisanie.
CallHandlingRules getRules(xsd:anyURI Address)
Funkcja wykorzystywana do pobrania zadeklarowanego zbioru reguł przypisanego
określonemu numerowi.
void claerRules(xsd:anyURI [1..unbounded])
Za pomocą tej funkcji dokonywane jest usunięcie zadeklarowanego zbioru reguł dla
określonego numeru lub zbioru numerów.
W Tab. 7 i Tab. 8 zostały przedstawione definicje typu danych odpowiednio dla
CallHandlingRules i UnconditionalForward zgodnie ze specyfikacją Parlay X.
161 Funkcje zostały zdefiniowane przy uŜyciu pseudokodu, a parametry i dane, z których korzystają zostały opisane w XML Schema. 162 Autor pod pojęciem numeru rozumie róŜnego rodzaju typy adresacji UA np. SIP URI, TelURI, E.164, itp..
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
154
Tab. 7: Definicja typu danych: CallHandlingRules
Nazwa elementu Typ elementu Opcjo- Nalny
Opis
AcceptList xsd:anyURI [0..unbounded]
Tak Lista numerów, z których połączenie zostanie zaakceptowane
BlockList xsd:anyURI [0..unbounded]
Tak Lista numerów, z których połączenie zostanie odrzucone
ForwardList ConditionalForward [0..unbounded]
tak Lista numerów, na które powinno zostać przekierowanie połączenie.
Forward UnconditionalForward tak Numer na który zostanie przekierowanie połączenie bezwarunkowo
VoiceInteractionContent VoiceInteraction tak Przekierowanie połączenia do systemu interakcji z informacją o zawartości
Tab. 8: Definicja typu danych: UnconditionalForward
Nazwa elementu Typ elementu
Opcjo-nalny
Opis
ForwardingAddress xsd:anyURI No Numer, na który zostanie przekierowanie połączenie
OnBusyAddress xsd:anyURI No Numer, na który zostanie przekierowanie połączenie w przypadku gdy linia jest zajęta
OnNoAnswerAddress xsd:anyURI No Numer, na który zostanie przekierowanie połączenie w przypadku, gdy nie zostanie odebrane
W specyfikacji [8] została dokładnie określona kolejność podejmowania akcji w
przypadku, gdy dla wszystkich usług zostały ustawione reguły. Jeśli reguły nie zostały
ustalone dla jakieś usługi krok ten zostaje pominięty. Kolejność ta przedstawia się
następująco:
� akceptacja połączenia – determinuje, czy połączenie powinno zostać zatwierdzone, czy
teŜ odrzucone. Jeśli dzwoniący nie jest na liście połączeń akceptowanych, wówczas
takie połączenie zostaje odrzucone i dalsze przetwarzanie reguł zostaje zakończone;
� blokowanie połączeń – determinuje, czy połączenie powinno zostać odrzucone. Jeśli
dzwoniący jest na liście numerów zablokowanych, połączenie zostaje odrzucone i
przetwarzanie reguł zostaje zakończone.
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
155
� warunkowe przekierowanie połączenia – kaŜde przychodzące połączenie na numer, dla
którego zostały określone specyficzne reguły przekierowania zostaje przekierowanie.
Dalej przetwarzanie reguł zostaje zakończone.
� bezwarunkowe przekierowanie połączenia – numer wywoływany zostaje zamieniony na
numer zadeklarowany w regule, po czym przetwarzanie reguły zostaje zakończone.
� odegranie dźwięku – połączenie zostaje obsłuŜone przez system głosowy. Przetwarzanie
tej reguły kończy się w momencie, gdy połączenie zostaje zakończone.
� Kontynuacja przetwarzania połączenia do momentu zestawienia połączenia na
oryginalnie wywoływany numer.
10.2.2 Implementacja
Ze względu na fakt, iŜ celem pracy jest jedynie pokazanie modelu i sposobu
implementacji usług w IMS, a nie implementacja wszystkich funkcji interfejsu Parlay X: Call
handling postanowiono, iŜ Serwer Obsługi Połączeń będzie realizował dwie wybrane usługi
mianowicie: bezwarunkowe przekierowanie połączenia oraz blokowanie połączenia.
Blokowanie połączenia
W Ŝadnym z dokumentów RFC dotyczącym SIP nie ma definicji mechanizmu
blokowania połączenia. Próbując zdefiniować taki mechanizm naleŜy zastanowić się na
dwoma zasadniczymi kwestiami:
1 na jakiej podstawie dane połączenie powinno zostać odrzucone,
2 jaka wiadomość SIP powinna zostać uŜyta do poinformowania UA inicjującego
połączenie o fakcie zablokowania jego wywołania.
Pewien szkic sformalizowania wyŜej wymienionych dwóch aspektów został omówiony
szczegółowo w [19]163. Autor proponuje wprowadzenie do standardu SIP nowej wiadomości
4xx (BLOCKED) oraz wymienia potencjalne warunki, na podstawie których dane połączenie
mogłoby zostać odrzucone. Jednocześnie dokonuje podziału mechanizmu blokowania
wywołań na: w pełni zablokowane (ang. full blocked) i częściowo zablokowane (ang.
partial blocked).
163 NaleŜy zauwaŜyć, iŜ draft [19] ten nie został włączony do zbioru RFC, a jego waŜność wygasła z dniem 02/15/2007. W związku z tym definicja mechanizmu blokowania połączenia jest wciąŜ tematem otwartym.
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
156
Pod pojęciem w pełni zablokowanych wywołań rozumie się, iŜ dane wywołanie
zostanie odrzucone ze względu na numer UA, który je zainicjował lub zakres numerów UA
lub nazwę domeny, z której pochodzą.
Częściowe blokowanie połączenia dotyczy filtrowania połączeń, które nie spełniają
kryteriów związanych z opisem sesji np. rodzaju kodeków, typu mediów, itp.. W tym
przypadku UA moŜe ponownie wysłać Ŝądanie z uwzględnieniem preferencji wywoływanego
UA, które otrzymał w odpowiedzi 4xx (BLOCKED) (przyczyna podawana jest w nagłówku
Reasone Header).
Przytoczone powyŜej sformalizowanie mechanizmu blokowania połączenia wraz z
rozszerzeniem specyfikacji SIP o dodatkową wiadomość pozwala w precyzyjny sposób
określać warunki na podstawie, których dane połączenie powinno zostać odrzucone. Zdając
sobie jednak sprawę, iŜ implementacja mechanizmu, który nie stał się standardem moŜe nieść
za sobą brak kompatybilności z innymi SIP UAs, autorzy postanowili rozwiązać ten problem
trochę inaczej. Do odrzucenia połączenia zostanie wykorzystana wiadomość CANCEL.
UŜycie wiadomości CANCEL w mechanizmie blokowania połączenia nie wybiega poza jej
definicję (patrz [22]), a przykładowy diagram widomości został przedstawiony na Rys. 80.
Dodatkowo uŜycie mechanizmu z [19] wiązałoby się z rozszerzeniem specyfikacji interfejsu
Parlay X: Call Handling o dodatkowy typ danych, który uwzględniałby warunki dla
blokowania częściowego i pełnego.
Rys. 80: Diagram wiadomości SIP dla usługi blokowania połączeń
Bezwarunkowe przekierowanie połączenia
Mechanizm przekierowania połączenia nie został równieŜ wyspecyfikowany w Ŝadnym
RFC dotyczącym SIP. Jednak w spisie wiadomości SIP z grupy tymczasowych (provisional)
znajduje się wiadomość o kodzie 181 ‘Call is being forwarded’, która moŜe zostać
wykorzystana do poinformowania UA o fakcie przekierowania jego połączenia. Przykładowy
diagram wymiany wiadomości SIP w trakcie przekierowania połączenia prezentuje Rys. 81.
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
157
Jak moŜna zauwaŜyć jest to standardowa transakcja INVITE rozszerzona jedynie o
wiadomość o kodzie 181, która ma jedynie informacyjny charakter.
Rys. 81: Diagram wiadomości SIP dla usługi przekierowania połączenia
10.2.3 Architektura
Architektura Serwera Obsługi Połączeń podobnie jak w przypadku architektury Serwera
Sterowania Połączeniami (patrz rozdział 10.1) obejmuje trzy elementy:
� interfejs Web Services dla Parlay X: Call Handling,
� szkielet i zręb - RMI,
� rdzeń aplikacji164 napisany z wykorzystaniem bibliotek JAIN SIP.
Budowa i działanie dwóch pierwszych elementów jest analogiczne do elementów z
Serwera Sterownia Połączeniami (szczegółowy opis 10.1.4), tak więc opis ich w tym miejscu
zostanie pominięty.
Rdzeń aplikacji jest głównym elementem serwera, a jego architektura została
przedstawiona na Rys. 82. Obejmuje on następujące klasy:
� sterownik, klasa: CallHandlingController – odpowiedzialna jest za uruchomienie
Serwera Obsługi Połączeń (załadowanie konfiguracji z pliku XML165), skreowanie
164 Określenia autora wskazujące element architektury aplikacji, w którym znajduje się logika serwera obsługi połączeń. 165 W pliku przekazywane są m.in. informacje na temat adresu IP, do którego powinien połączyć się stos JAIN SIP, numer portu, na którym będzie nasłuchiwał.
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
158
wymaganych obiektów m.in. stosu JAIN SIP, instancji klasy
CallHandlingApplication oraz CallHandlingAdapter .
� adapter, klasa: CallHandlingAdapter. Klasa ta mapuje wywołania metod interfejsu
Web Services na wywołania odpowiednich metod z klasy
CallHandlingApplication .
� aplikację, klasa: CallHandlingApplication . Klasa ta zawiera logikę Serwera Obsługi
Połączeń.
� Klasy pomocnicze takie jak stan aplikacji dla określonego dialogu: klasa
TaskState166, skojarzenie reguł z konkretnym numerem: klasa
CallHandlingRuleAss oraz powiązania transakcji klienckiej i serwera dla
stanowego SIP Proxy: klasa SipProxy . Klasy te zostały zaznaczone kolorem
szarym.
Rys. 82: Zestaw klas z najwaŜniejszymi funkcjami, z których zbudowany jest Serwer Obsługi Połączeń.
Klasy szare są klasami pomocniczymi.
166 Klasa ta jest identyczna jak klasa w Serwerze Sterowania Połączeniami.
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
159
Rys. 83: Diagram sekwencji wymiany wiadomości/wywołania funkcji dla procesu uruchamiania serwera
obsługi połączeń, ustawiania reguł oraz procesu przekierowania połączenia.
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
160
Uwagi:
� diagram przedstawia scenariusz ustawiania reguł dla danego uŜytkownika za pomocą
aplikacji Osobiste Centrum Komunikacji, jak i równieŜ proces obsługi połączenia dla
reguły usługi przekierowania połączeń;
� dla uproszenia w diagramie S-CSCF oraz P-CSCF przedstawiono jako CSCF;
� kaŜdorazowe ustawienie reguł (wywołanie setRules(...) ) powoduje nadpisanie
numeru, na który ma zostać przekierowanie połączenie oraz dodanie listy numerów
zablokowanych do listy wcześniej juŜ ustawionych;
� serwer obsługi połączenia nie wstawia nagłówka Record Router co skutkuje tym, Ŝe
zamknięcie transakcji z INVITE oraz wszystkie inne transakcje pomiędzy
[email protected] i [email protected] zostaną obsłuŜone przez CSCF (nie obciąŜają serwera
obsługi połączeń);
� obiekt CallHandlingRulesAss jest tworzony w momencie utworzenia reguł dla danego
numeru, a usuwany w momencie wyczyszczenia reguł tj. wywołania funkcji void
clearRules(...) ;
� funkcja processCallHandlingRule(...) – przetwarza reguły obsługi połączeń
zgodnie z kolejnością wskazaną w rozdziale 10.2.1. Brak reguły powoduje
pominięcie danego kroku;
10.3 Informacja o statusie terminala (interfejs Terminal Status)
Interfejs Parlay X: Terminal Status, jak sama nazwa wskazuje umoŜliwia uzyskanie
informacji na temat statusu terminala lub terminali IMS, a takŜe na odbieranie w sposób
asynchroniczny powiadomień o zmianach statusu terminala/i IMS. Funkcjonalność taka
pozwala na projektowanie usług kontekstowych zainteresowanych informacją o statusie
terminala. Funkcjonalność tego interfejsu moŜe zostać wykorzystana np. do realizacji usługi
dzwoń kiedy jest dostępny (call when available) w ramach usługi telekonferencji. Wówczas
telekonferencja taka zostanie zestawiona w momencie, gdy zadeklarowany zbiór terminali
będzie miał określony status - osiągalny.
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
161
Rys. 84: Wykaz interfejsów i funkcji wchodzących w skład usługi sieciowej Parlay X: Terminal Status
10.3.1 Opis interfejsu Parlay X: Terminal Status
Interfejs Parlay X: Terminal Status został zdefiniowany w dokumencie [8]. Funkcjonalność
tego interfejsu umoŜliwia uzyskanie informacji o statusie terminala poprzez:
� wysłanie Ŝądania, w odpowiedzi na które zostanie zwrócony status terminala;
� wysłanie Ŝądania do grupy terminali;
� przysyłania w sposób asynchroniczny powiadomienia o zmianach w statusie terminala.
WyróŜnia się następujące statusy terminala:
� osiągalny (reachable);
� nieosiągalny (unreachable);
� zajęty167 (busy).
Na Rys. 84 znajduje się wykaz interfejsów i funkcji wchodzących w skład usługi sieciowej
Parlay X: Terminal Status. Interfejsy te odpowiadają wcześniej wymienionym sposobom
uzyskania informacji o statusie terminala. Z pośród nich do celów środowiska badawczego
postanowiono zaimplementować funkcję GetStatus, której deklaracja wygląda następująco:
Status GetStatus(xsd:anyURI Address)
Funkcja jako parametr przyjmuje adres terminala, którego status ma zostać
określony. W odpowiedzi zawraca jedną z trzech moŜliwych wartości typu
wyliczeniowego Status , które zostały wyszczególnione w Tab. 9
167 Nie wszystkie terminale mogą udostępnia informację o zajętości. W związku z tym aplikacja powinna adoptować się do informacji jakie uzyskuje.
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
162
Tab. 9: Definicja typu wyliczeniowego Status
Nazwa typu wyliczeniowego Opis Reachable Terminal jest dostępny Unreachable Terminal nie jest dostępny Busy Terminal jest zajęty
Implementacja
Ograniczenie się do implementacji wyłączenie jednej funkcji z usługi sieciowej Parlay
X: Terminal Status wynikało z faktu, iŜ zdaniem autorów funkcjonalność pozostałych
interfejsów z Rys. 84 moŜe być w prosty sposób osiągnięta z wykorzystaniem usługi
sieciowej Parlay X: Presence168. Do sprawdzenia statusu terminala postanowiono uŜyć
wiadomości OPTIONS169, która zgodnie z [22] wykorzystywana jest do odpytywania UAS o
jego preferencje tj. rodzaj kodeków, typ mediów, itp.., Terminal w odpowiedzi na OPTIONS
zwraca taką wiadomość jaką zwróciłby w przypadku otrzymania wiadomości INVITE.
Serwer rozróŜnia trzy przypadki:
� Otrzymał wiadomość OK – aplikacja zwraca status terminala REACHABLE
� Otrzymał wiadomość o kodzie 486 Busy Here170 - aplikacja zwraca status BUSY
� Nie otrzymał Ŝadnej wiadomości w przeciągu 30 sek. – aplikacja zwraca status
UNREACHABLE.
Przykładowe zachowanie się serwera na wysłanie wiadomości OPTIONS przedstawia Rys.
85.
168 Warto w tym miejscu wspomnieć o mechanizmie uŜytym przez IBM przy implementacji interfejsu Parlay X: Terminal Status (patrz http://publib.boulder.ibm.com/infocenter/wtelecom/v6r1/index.jsp?topic=/com.ibm.twss.services.doc/termstat_dev_c.html). Zaimplementowany mechanizm jest mechanizmem wykorzystywanym w usłudze obecności. Bazuje on na wiadomościach SUBSCRIBE i NOTIFY, które wymieniane są pomiędzy serwerem obecności, a aplikacją zbudowana na usłudze sieciowej. Rodzi się zatem pytanie jaki cel przyświecał implementacji interfejsu Parlay X: Terminal Status, skoro ma identyczną funkcjonalność jak interfejs Parlay X: Presence? 169 Definicja Ŝądania OPTIONS znajduje się w [22] w sekcji 4.2.3. 170 Definicja tej odpowiedzi znajduje się w [22] w sekcji 21.4.24.
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
163
Rys. 85: Diagram wiadomości SIP dla trzech przypadków statusu terminala: REACHABLE,
UNREACHABLE, BUSY
Architektura serwera jest analogiczna do architektury wcześniej opisywanych serwerów
obsługi połączeń i sterowania zestawianiem połączeń (patrz rozdział 10.1 i 10.2).
Rdzeń aplikacji tworzą następujące klasy:
� sterownik, klasa: TerminalStatusController – odpowiedzialna jest za uruchomienie
Serwera Terminal Status (załadowanie konfiguracji z pliku XML171), skreowanie
wymaganych obiektów m.in. stosu JAIN SIP, instancji klasy
TerminalStatusApplication oraz TerminalStatusAdapter .
� adapter, klasa: TerminalStatusAdapter. Klasa ta mapuje wywołania metod
interfejsu Web Services na wywołania odpowiednich metod z klasy
TerminalStatusApplication .
� aplikację, klasa: TerminalStatusApplication . Klasa ta zawiera logikę Serwera
Terminal Status. W skład tej klasy wchodzi m.in. funkcja void
getTerminalStatus(URI address). Zasada działania tej klasy została
przedstawiona na diagramie SDL na Rys. 86.
171 W pliku przekazywane są m.in. informacje na temat adresu IP, do którego powinien połączyć się stos JAIN SIP, numer portu, na którym będzie nasłuchiwał.
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
164
Rys. 86: Diagram w języku SDL opisujący działanie serwera Terminal Status
10.4 Zarządzanie listą kontaktów (interfejs Address List
Management)
W ramach środowiska badawczego została zaimplementowana aplikacja realizująca
funkcje związane z organizacją i zarządzaniem listą kontaktów uŜytkownika. Udostępnia on
zbiór wybranych funkcji zgodnych z specyfikacją interfejsu Parlay X: Address List
Management (patrz [8], część 13). Rys. 87 pokazuje wszystkie funkcje tego interfejsu oraz te,
które zostały zaimplementowane na potrzeby tego opracowania (zaznaczone kolorem
zielonym).
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
165
ParlayX - Address List Management
group management
interface
member
interface
group
interface
implementowane w ramach środowiska badawczego
Rys. 87:Funkcje interfejsu Parlay X: Addres List Managemnet172
Dostęp do prywatnej ksiąŜki kontaktów uŜytkowników ma waŜna znaczenie dla
budowania usług końcowych. UmoŜliwienie aplikacji, realizowanie logiki usługi w oparciu o
zcentralizowane informacje dotyczące prywatnej listy kontaktów uŜytkownika, wzbogaca
funkcjonalnie usługę (np. poczta elektroniczna z aktywną listą kontaktów) oraz daje moŜliwość
budowy całkowicie nowych rozwiązań dla końcowego uŜytkownika. Ze względu na te
kwestie, funkcjonalności związane z zarządzaniem listą kontaktów zostały włączone do
specyfikacji interfejsów Parlay/OSA i Parlay X. Stanowią one teŜ waŜny element warstwy
komponentów usługowych w realizowanym na potrzeby tego opracowania środowisku
badawczym.
10.4.1 Opis interfejsu Parlay X: Address List Management
Na potrzeby analizy w środowisku badawczym zaimplementowane zostały następujące
funkcje173:
� xsd:anyURI createGroup(
xsd:string name,
xsd:string domain,
xsd:boolean autoName)
172 Na podstawie specyfikacji Parlay X API wersja 2.1 173 Funkcje są zdefiniowane przy uŜyciu pseudokodu i typów danych XML-Schema (zdefiniowanych w ‘W3C XML Schema Part 2: Datatypes Second Edition’). Definicja funkcji zaczerpnięta jest z [8].
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
166
Tworzy grupę, która będzie identyfikowana porzez URI złoŜonym z nazwy ‘name’ i
dziedzinie ‘domain’. Jeśli parametr ‘autoName’ jest pozytywny to w przypadku
konfliktu nazw, nowa nazwa grupy zostanie wygenerowana automatycznie i zwrócona
jako odpowiedź na wywołanie tej funkcji.
� deleteGroup( xsd:anyURI group )
Usuwa grupę identyfikowaną przez URI ‘group’.
� addMember( xsd:anyURI group, xsd:anyURI member )
Dodaje nowego uŜytkownika identyfikowanego przez URI ‘member’ do grupy
identyfikowanej przez URI ‘group’.
� deleteMember( xsd:anyURI group, xsd:anyURI member )
Usuwa uŜytkownika ‘member’ z grupy identyfikowaną przez URI ‘group’.
� xsd:anyURI [0..*] queryMembers(
xsd:anyURI group,
xsd:boolean resoveGroups )
Wysyła prośbę o listę uŜytkowników naleŜących do grupy identyfikowanej przez URI
‘group’. Jeśli ‘ resolveGroups’ jest pozytywne to takŜe są zwracani członkowie
wszystkich podgrup wewnątrz danej grupy174.
10.4.2 Scenariusze wywołania funkcji interfejsu
Rys. 88 pokazuje przykładowy scenariusz wywołań funkcji tego interfejsu. UŜytkownik
korzysta z aplikacji Centrum Komunikacji Osobistej (implementowane w ramach środowiska
badawczego), którego jedną z funkcji jest wizualizowanie ksiąŜki adresowej. Po zalogowaniu
się uŜytkownika, aplikacja CKO wywołuje funkcję ‘queryMembers’, aby pobrać adresy
innych uŜytkowników, którzy znajdują się w ksiąŜce adresowej. Następnie uŜytkownik
dodaje nowy adres (wywołanie funkcji ‘addMember’) i usuwa inny (‘deleteMember’).
174 W zaimplementowanym środowisku badawczym nie ma moŜliwości stworzenia ‘podgrupy’.
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
167
queryMembers
addMember
deleteMember
Rys. 88: Przykładowy scenariusz wywołania funkcji interfejsu Parlay X: Address List Management
10.5 Informacja o statusie obecności (interfejs Presence)
W ramach środowiska badawczego została zaimplementowana aplikacja realizująca
funkcje związane z zarządzaniem informacją o statusie obecności uŜytkownika. Udostępnia
ona zbiór wybranych funkcji zgodnych z specyfikacją interfejsu Parla X: Presence (patrz [8],
część 14). Rys. 87 pokazuje wszystkie funkcje tego interfejsu oraz te, które zostały
zaimplementowane na potrzeby tego opracowania (zaznaczone kolorem zielonym).
subscrib
ePresence
getUserP
resence
startP
resenceNotific
atio
n
endPresenceNotific
atio
n
statusChanged
statusEnd
notify
Subscrip
tion
subscrip
tionEnded
publish
getO
penSubscrip
tions
updateSubscrip
tionAuthoriz
atio
n
getM
yWatchers
getSubscrib
edAttrib
utes
blockSubscrip
tion
Rys. 89: Funkcje interfejsu Parlay X: Presence
Informacja o statusie obecności uŜytkownika umoŜliwia budowanie tzw. usług
kontekstowych czyli takich, których scenariusz realizacji podczas wywołania zaleŜy od zbioru
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
168
czynników aktualnie określających środowisko, w którym znajduję się uŜytkownik. Dotycz to
zarówno informacji o obecności uŜytkownika, ale takŜe o lokalizacji, czy dostępności w sieci.
Na Rys. 90 pokazana jest architektura usługi obecności w sieci UMTS zdefiniowana w
ramach prac 3GPP. Podstawowymi elementami są:
� Presence Server – przechowuje i udostępnia informacje o obecności;
� Presence User Agent – dostarcza informacje o obecności pochodzącą od uŜytkownika;
� Presence Network Agent – dostarcza informacje o obecności pochodzącą z elementów
sieci. Przykładowo gdy uŜytkownik jest poza siecią, element realizujący funkcję
Presence Network Agent, mając dostęp do HSS, moŜe powiadomić serwer obecności
(Presence Server) o niedostępności uŜytkownika;
� Watcher application – pobiera informacje o obecności uŜytkowników z Presence
Server. Tą funkcję moŜe pełnić aplikacja usługowa, albo agent uŜytkownika (UA),
który „nasłuchuję” zmian w statusie obecności innych uŜytkowników.
Interfaces Ph, Pi, Pc, Pg, Pk and Pl are based on existing Release 5procedures e.g. CAMEL, MAP, CAP, RADIUS, ISC, Cx, Sh.The Pr, Pp interfaces are based on existing Release 6 procedures ofthe 3GPP- WLAN interworking architecture.
PeuPresence User agent(Presence informationprovided by the user)
Presence Network agent (Presenceinformation provided by the
network)
Pen
Pi
MSC Server/VLR SGSN GMLC
Ph Pc Pg
Presence suppliers
Presence server(home network)
PresentityPresence Proxy
WatcherPresence Proxy
Watcherapplications
HSS(HLR)
Pwp
Pw
Pw
Px
GGSNS-CSCFHSS/HLR
Pk Pl
Presence External agent (Presenceinformation provided by elementsoutside the provider’s network)
Pex
Pr
3GPP AAAServer
Pp
PDG
Pep
PresenceList Server
Pet
Pw
Rys. 90: Architektura usługi obecności w sieci 3GPP (źródło 3GPP TS 23.141)
Zgodnie z architekturą pokazana na Rys. 90, informacja o obecności moŜe pochodzić
bezpośrednio od uŜytkownika albo moŜe być „odkrywana” w sposób pośredni np. za pomocą
analizy stanów elementów sieciowych. Model usługi obecności (a w zasadzie komponentu
usługowego) opiera się współdziałanie pomiędzy: podmiotami, które publikują informacje o
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
169
obecności uŜytkowników, repozytorium przechowującym takie dane oraz podmiotami, które
odczytują informacje o obecności uŜytkowników (patrz Rys. 91).
Rys. 91: Model realizacji usługi obecności
W implementowanym środowisku badawczym, poszczególne funkcje pełnione przez
dane elementy są pokazane na Rys. 92.
Rys. 92: Funkcje usługi obecności realizowane przez poszczególne elementy środowiska badawczego
10.5.1 Opis interfejsu
„Serwer udostępniający informacje o statusie obecności uŜytkownika” jest elementem
realizującym interfejs Parlay X: Presence w środowisku badawczym (patrz Rys. 92). Na
potrzeby analizy zaimplementowane zostały następujące funkcje175:
� publish (
xsd:anyURI presentity,
presence_xsd:PresenceAttribute presence )
175 Funkcje są zdefiniowane przy uŜyciu pseudokodu i typów danych XML-Schema (zdefiniowanych w ‘W3C XML Schema Part 2: Datatypes Second Edition’). Definicja funkcji zaczerpnięta jest z [8].
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
170
Wywołanie tej funkcji publikuje status obecności uŜytkownika identyfikowanego
poprzez presentity. Status obecności jest określony poprzez parametr presence, który
zgodnie z [8] moŜe między innymi przyjmować wartości określające aktywność, które
zostały wypisane w Tab. 10.
� presence_xsd:PresenceAttribute getUserPresence(
xsd:anyURI watcher,
xsd:anyURI presentity,
xsd:string [0..*] attributes)
Zwraca informacje o obecności uŜytkownika identyfikowanego, poprzez URI
presentity. Aplikacja wywołująca tą funkcje musi określić uŜytkownika, który pobiera
informacje (watcher) oraz rodzaj informacji, która ma być zwrócona176.
10.5.2 Realizacja usługi obecności przy pomocy protokołu SIP
Publikacja i pobieranie informacji z serwera obecności odbywa się za pomocą protokołu
SIP rozszerzonego o dodatkowe mechanizmy zdefiniowane w [29]. Wiadomości biorące
udział w realizacji usługi obecności to:
� SUBSCRIBE - umoŜliwia aplikacji nasłuchującej (Watcher Application)
zarejestrowanie w serwera obecności (Presence Server) potrzeby pobierania
informacji o obecności.
� NOTIFY – umoŜliwia serwerowi obecności (Presence Server) przesyłanie informacji o
obecności do aplikacji nasłuchującej (Watcher Application).
� PUBLISH – umoŜliwia publikacje statusu obecności przez agenta obecności (Presence
Agent)
Dokumenty [28] i [32] specyfikują model reprezentacji obecności, który jest
wykorzystywany w protokole SIP. Do tego celu jest stosowany opis w postaci PIDF177 i
RPIDF178, który jest przenoszony za pomocą wiadomości PUBLISH i NOTIFY.
176 W środowisku badawczym dostępna jest tylko informacja o aktywności uŜytkownika. 177 PIDF (Presence Information Data Format) jest sposobem opisu stanu obecności opartym o XML i definiowanym w [28]. 178 RPIDF (Rich Presence Information Data Format) jest rozszerzeniem opisu w stosunku do PIDF (patrz [32]).
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
171
Rys. 93: Przykładowy dokument PIDF/RPIDF opisujący status obecności
Przykład dokumentu PIDF/RPIDF opisującego status obecności przedstawia Rys. 93.
Tab. 10 pokazuje róŜne moŜliwe statusy aktywności zdefiniowane w ramach Parlay X i SIP
(PIDF/RPIDF). Jak moŜna zauwaŜyć oba modele nie są zgodne i niezbędna jest konwersja
pomiędzy statusami obecności przekazywanymi poprzez interfejs Parlay X, a statusem
obecności, który jest uŜywany w sieci IMS opartej o protokół SIP.
Tab. 10: Porównanie moŜliwych aktywności zdefiniowanych w ramach Parlay X i modelu obecności dla
protokołu SIP (RPIDF)
Parlay X SIP (PIDF/RPIDF) ActivityNone Available Busy DoNotDisturb OnThePhone Steering Meeting Away Meal PermanentAbsence Holiday Performance InTransit Travel
appointment away breakfast busy dinner holiday in-transit looking-for-work meal meeting on-the-phone permanent-absence playing presentation
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
172
Sleeping ActivityOther
shopping sleeping travel vacation working other unknown
10.5.3 Scenariusz usługi obecności
Rys. 94 pokazuje przepływy wiadomości pomiędzy elementami środowiska
badawczego przy wywołaniach funkcji interfejsu Parlay X: Presence.
CSCF
aplikacja
CKO*interakcja z
uŜytkownikiem
*) CKO = Centrum Komunikacji Osobistej
Parlay X
interfejs ParlayX: Presence
J2SE
stos JAIN-SIP
Serwer udostępniającyinformacje o stanieobecności uŜytkownika
Publish
Get User Presence
1. PUBLISH
2. PUBLISH
3. Zapamietanie stanu obecności
12. Zapamietanie stanu obecności
5. SUBSCRIBE
6. NOTIFY
7. Konwersja modeli obecności z
SIP na Parlay X
10. Konwersja modeli obecności z
Parlay X na SIP
11. PUBLISH
Rys. 94: Interakcje pomiędzy elementami środowiska badawczego podczas wywoływania funkcji
interfejsy Parlay X: Presence
Terminal uŜytkownika publikuję informacje o obecności po zarejestrowaniu się w sieci
IMS. W tym celu wysyła wiadomość PUBLISH (1). Wiadomość PUBLISH zgodnie z
zasadami kierowania zgłoszeń w IMS trafia do serwera obecności (2). Serwer obecności
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
173
odczytuje informacje o statusie obecności zapisaną w dokumencie PIDF/RPIDF zawartym w
otrzymanej wiadomości PUBLISH (3). Inny uŜytkownik uruchamia aplikację CKO, która
wywołuje funkcję ‘getUserPresence’ w celu uzyskania informacji o obecności (4). Serwer
aplikacyjny implementujący interfejs Presence przesyła do serwera obecności widomość
SUBSCRIBE z Ŝądaniem powiadomienia o statusie obecności uŜytkownika (5). Serwer
obecności przesyła za pomocą wiadomości NOTIFY dokument PIDF/RPIDF uŜytkownika,
który w punkcie 3 został zapamiętany (6). Serwer aplikacyjny dokonuje konwersji między
PIDF/RPIDF a modelem stosowanym, w Parlay X (7). Informacja o statusie obecności jest
zwracana do aplikacji CKO (8). UŜytkownik aplikacji CKO modyfikuje statusie obecności.
Aplikacja CKO wywołuje funkcję ‘publish’ w celu zmiany informacji o statusie obecności
(9). Serwer aplikacyjny dokonuje konwersji modeli (10) i wysyła widomość PUBLISH do
serwera obecności zawierającą dokument PIDF/RPIDF z nowym statusem obecności (11).
Serwer obecności zapamiętuję nowy status obecności uŜytkownika (12).
Centrum Komunikacji Osobistej
174
11. Centrum Komunikacji Osobistej
W ramach warstwy aplikacyjnej zostały zaimplementowane i omówione wybrane
interfejsy ze specyfikacji Parlay X. Interfejsy te są punktem, w którym operator otwiera sieć
telekomunikacyjną oraz udostępnia jej funkcjonalność. Na bazie tej funkcjonalności trzecia
strona moŜe budować własne usługi telekomunikacyjne.
W związku z tym naturalnym zwieńczeniem prac nad analizą modelu tworzenia usług w
IMS jest pokazanie, w jaki sposób moŜna wykorzystać usługi sieciowe Parlay X. Dlatego
wramach środowiska badawczego tworzonego na potrzeby niniejszego opracowania została
zaimplementowana aplikacja „Centrum Komunikacji Osobistej” 179.
11.1 ZałoŜenia projektowe dla aplikacji
Przed przystąpieniem do prac nad aplikacją została sporządzona poniŜsza lista załoŜeń.
ZałoŜenia uporządkowano zgodnie z ich waŜnością.
Funkcjonalność:
� moŜliwość zestawienia połączenia pomiędzy dwoma stronami, bez względu na
rodzaj sieci (naleŜy wprowadzić jedynie odpowiednie URI);
� zakończenie połączenia, po przez wybranie go z listy istniejących;
� przekierowanie połączenia na wskazany URI;
� blokowanie połączeń – blokada zgłoszenia przychodzącego z określonego URI;
� informację o statusie obecności uŜytkowników, którzy znajdują się na liście
kontaktowej;
� publikowanie własnego statusu obecności (moŜliwość zdefiniowania opisu, oraz
wybrania predefiniowanego statusu z poziomu aplikacji), jeśli takiej funkcjonalności
nie udostępnia SIP UA uŜytkownika lub uŜytkownik korzysta z tradycyjnej telefonii;
� zarządzanie własną listą kontaktów (usuwanie, edycja, dodawanie nowych
kontaktów);
� sprawdzanie statusu terminala na podstawie URI;
� aplikacja ma prezentować moŜliwości Parlay X;
179 Inspiracją dla usługi była usługa o nazwie IOBI amerykańskiego operatora Verizon. Szczegóły dotyczące protoplasty moŜna znaleźć pod adresem: http://www22.verizon.com/business/iobi/.
Centrum Komunikacji Osobistej
175
� uŜytkownik moŜe personalizować aplikację, włączając lub wyłączając określoną
funkcjonalność, za którą powinien być odpowiednio rozliczony180;
� aplikacja ma być stworzona z wykorzystaniem standardowych narzędzi do budowy
stron WWW, jednakŜe ma imitować aplikację stacjonarną tzw. „stand-alone” (bez
konieczności ciągłego odświeŜania strony, pobierania danych. Reakcja na zdarzenia
wywołane przez uŜytkownika ma być natychmiastowa);
� uŜytkownik jest identyfikowany i autoryzowany za pomocą loginu w postaci SIP
URI oraz hasła;
� aplikacja ma spełniać standardy bezpieczeństwa rozwiązań webowych np. Transport
Layer Security181 (TLS), XML Encryption;
� Interfejs uŜytkownika ma być moŜliwie prosty i funkcjonalny.
11.2 Architektura aplikacji
11.2.1 Wybrane techniki i narzędzia
Do realizacji projektu, biorąc pod uwagę postawione wymagania, wybrano
następujące techniki: język zgodny ze standardem XHTML [49], język PHP [57], Java Script
[15], Asynchronous JavaScript And XML (AJAX), protokół SOAP [47] oraz Transport Layer
Security (TLS) [21]. Zakres, w jakim te techniki pozwalają realizować załoŜenia projektowe
zostaną wyszczególnione w opisach kaŜdej z nich, a miejsce ich zastosowania pokazano na
rysunku Rys. 95.
Serw
er HTTP
+ PHP
(PEAR 0.9.1)P
rzeglądarka
WWW
Aplikacja
JavaScrip
t
Serw
er
Aplikacyjny +
AXIS v.2
Rys. 95: Wykorzystanie wybranych technik w realizacji aplikacji
180 Zostanie omówiony sposób rozliczenia uŜytkownika, jednak ze względu na brak usługi sieciowej odpowiedzialnej za ten proces w samej implementacji funkcjonalność ta została pominięta. 181 Technika ta zostanie przedstawiona w dalszej części pracy.
Centrum Komunikacji Osobistej
176
Język PHP
Język PHP (Hypertext Preprocessor) został wybrany spośród alternatywnych rozwiązań
takich jak JSP/Servlet182, CGI183 ze względu na jego prostotę uŜycia, powszechne stosowanie
i funkcjonalność184. Jest to język skryptowy, który wykonywany jest po stronie serwera. Nie
posiada, więc ograniczeń związanych z odpowiednim oprogramowaniem strony klienckiej.
Dzięki temu aplikacja ma charakter sieciowy, nie musi być instalowana i nie jest zaleŜna od
środowiska w, którym jest uruchamiana. PHP pozwala na tworzenie stron HTML/XHTML
generowanych dynamicznie, poprzez wkomponowanie wyraŜeń w treść dokumentu HTML.
W projekcie wykorzystano wersję piątą języka ze względu na fakt, iŜ pozwala w pełni
na programowanie obiektowe oraz jest kompatybilna z projektem PEAR185. Projekt PEAR
posiada m. in. zbiór klas wspierających komunikację z wykorzystaniem protokołu SOAP.
Funkcjonalność biblioteki PEAR/SOAP umoŜliwia korzystanie z interfejsów Parlay X. Do
budowy aplikacji uŜyto biblioteki PEAR/SOAP w wersji 0.9.1.
Java Script
Java Script znajduje się po stronie klienta i jest prostym186, powszechnie stosowanym
językiem skryptowym. Pozwala na dynamiczne przetwarzanie stron w języku HTML bez
interakcji z serwerem. Dzięki temu zawartość aplikacji nie musi być przeładowywana (jednak
pobranie nowych danych wymaga przeładowania strony).
Java Script oferuje równieŜ mechanizm zdarzeń, który umoŜliwia budowę aplikacji z
zaawansowanym GUI (pod elementy strony moŜna podpiąć zdarzenia i obsłuŜyć je w
dowolny sposób). Poza tym technika ta wymagana jest, aŜeby korzystać z AJAX. Do budowy
aplikacji wykorzystano język w wersji 1.2.
182 Techniki opracowane przez Sun Microsystem. Specyfikacja i dokumentacja technik dostępna na [53] i [54]. 183 Common Gateway Interface (CGI) – specyfikacja dostępna na [59]. 184 Autor ma na myśli duŜą liczbę rozszerzeń w postaci modułów jak i równieŜ dodatkowych bibliotek np.: projekt PEAR. 185 PEAR - PHP Extension And Application Repository. Jest to środowisko oraz system dystrybucji rozszerzeń do PHP jako oprogramowania na licencji open source. 186 Java Script zorientowany jest na ścisła współpracę z dokumentami HTML. Posiada wbudowaną strukturę obiektową dokumentu (np. froms, links, applets, hisotry), do którego elementów moŜna łatwo się odwoływać.
Centrum Komunikacji Osobistej
177
AJAX
Jest stosunkowo nową techniką187, która wypełnia lukę pomiędzy moŜliwościami języka
Java Script, a PHP. Jej głównym atutem jest moŜliwość aktualizacji strony bez konieczności
jej przeładowania, asynchronicznie. Ta funkcjonalność umoŜliwia budowę aplikacji, która
posiada cechy takie jak tradycyjna aplikacja stacjonarna tzw. „stand-alone”. Przewaga nad
aplikacją stand-alone polega na tym, Ŝe aplikacji sieciowej nie trzeba instalować, a do jej
działania potrzebna jest zwykła przeglądarka WWW.
RóŜnicę pomiędzy działaniem strony zbudowanej z wykorzystaniem techniki AJAX, a
zwykłą stroną WWW pokazano na Rys. 96 i Rys. 97. Poszczególne elementy strony zasilane
są w porcje danych, jeśli zajdzie taka potrzeba, dzięki czemu oszczędza się pasmo, a
zawartość strony zostaje wyświetlona duŜo szybciej (następuje uaktualnienie jedynie
określonych jej części).
AJAX stanowi konglomerat technik:
� XHTML i CSS – do tworzenia interfejsu uŜytkownika,
� DOM – do obsługi elementów dynamicznych i zdarzeń, XML.
Dane wymieniane są z wykorzystaniem obiektu XMLHttpRequest188. Techniki te łączone są w
całość z wykorzystaniem Java Scriptu, który odpowiada za logikę aplikacji oraz dynamiczną
budowę interfejsu.
187 Technika ta powstała w końcu roku 2006 i stała się hitem w programowaniu stron HTML. 188 Jest to standardowy element wielu przeglądarek, np. w Internet Explorer jest to wbudowany obiekt ActiveX, natomiast w Fire Fox i innych jest obiektem Java Script. MoŜe jednak wystąpić nie kompatybilność ze starszymi przeglądarkami niŜ IE 5.5, FF 1.5. Posiada proste API pozwalające na wysyłanie drobnych Ŝądań GET/POST.
Centrum Komunikacji Osobistej
178
Przeglądarka Server
(1) request: index.phpGET
(2) generowanie index.php(3) wywołanie AJAX
ze zdarzenia JavaScript
(5) uzupełnienie Ŝądanej treści z
uŜyciem modelu DOM
POST(4) Przetworzenie Ŝądania AJAX
(8) wywołanie AJAX
ze zdarzenia JavaScript
(9) uzupełnienie Ŝądanej treści
z uŜyciem modelu DOM
(7) Przetworzenie Ŝądania AJAXPOST
Utworzenie obiekt XMLHttpRequest
v
Wypełniony danymi obiekt XMLHttpRequest
Ŝądanie odpowiedź
Rys. 96: Sposób wymiany Ŝądań i odpowiedzi pomiędzy klientem a serwerem z wykorzystaniem techniki
AJAX.
Rys. 97: Przepływ Ŝądań i odpowiedzi w standardowym modelu dla protokołu HTTP.
TLS
Transport Layer Security jest rozwinięciem protokołu SSL (Secure Socjet Layer).
Zapewnia poufność i integralność transmisji danych oraz uwierzytelnienie na poziomie od
warstwy transportu w górę modelu OSI. TLS został wykorzystany w aplikacji do zapewnienia
bezpieczeństwa podczas wymiany danych pomiędzy serwerem, a przeglądarką oraz
autoryzacji uŜytkownika.
11.3 Proces tworzenia aplikacji z wykorzystaniem Parlay X
Zbudowanie aplikacji wykorzystującej interfejsy Parlay X wymaga poczynienia
następujących kroków:
Centrum Komunikacji Osobistej
179
1. Wyszukanie interesujących usług sieciowych w węzłach UDDI189;
2. Pobranie opisu usługi sieciowej w postaci WSDL z UDDI lub bezpośrednio ze
strony zwierającej specyfikację Parlay X (np. www.parlay.org);
3. Wygenerowanie zrębu aplikacji – metod, za pomocą których będą wołane usługi;
4. Stworzenie aplikacji;
5. Rejestracja/podpisanie stosownej umowy z dostawcą usług sieciowych w celu
późniejszego rozliczenia oraz w kwestiach bezpieczeństwa;
6. Wywoływanie usług sieciowych.
Zatem moŜna zauwaŜyć, iŜ oczekiwania względem programisty, który chce stworzyć
usługę telekomunikacyjną sprowadzają się do posiadania przez niego wiedzy i umiejętności
posługiwania się Web Services. W chwili wygenerowania zrębu aplikacji zadaniem
programisty jest jedynie odpowiednie wywoływanie usług, tak jak w przypadku zwykłych
funkcji w dowolnie wybranym i preferowanym przez niego języku programowania. PoniŜej
zostaną omówione kroki 3. i 4. na przykładzie aplikacji Osobiste Centrum Komunikacyjne.
11.4 Komponenty aplikacji
Aplikacja składa się z trzech rodzajów komponentów190 tj.:
� komponenty zajmujące się prezentacją informacji,
� komponenty z logiką aplikacji, w których następuje wywołanie odpowiednich usług
sieciowych i przetworzenie pozyskanych danych oraz
� komponent zajmujący się komunikacją pomiędzy dwoma wyŜej wymienionymi
rodzajami komponentów.
Jednym z powodów wprowadzenia podziału na komponenty, była potrzeba oddzielenia
prezentacji od logiki. Dzięki temu moŜna w łatwy sposób rozszerzać aplikację o kolejne
moduły funkcjonalne np.: moduł związany z usługa lokalizacji, SMS, MMS191, itd..
Sprowadza się to jedynie do dopisania modułu zajmującego się odpytywaniem usług
sieciowych, dodania funkcji AJAX łączącej logikę z prezentacją oraz dopisania kodu HTML
kotwiczącego oraz formatującego otrzymaną informację. W ten sposób zbudowana aplikacja
189 Patrz rozdział 4.5. 190 Autor dla porządku komponentem nazywa podstawowy składnik aplikacji (np.: komponent z logiką usługi obecności, komponent prezentujący usługę obecności). Zbiór komponentów oferuje pewną funkcjonalność. Taki zbiór komponentów nazywany będzie modułem. 191 Patrz specyfikacja interfejsów Parlay X [8].
Centrum Komunikacji Osobistej
180
pozwala równieŜ na realizację załoŜenia projektowego, które dotyczyło moŜliwości
personalizowania przez uŜytkownika aplikacji i rozliczania jego za wybraną liczbę modułów
funkcjonalnych.
Komponenty te zostały przedstawione na Rys. 98 i odpowiednio rozdzielone na
powyŜej wymienione grupy. Dodatkowym element, który został wyróŜniony na Rys. 98 jest
arkuszy styli (CSS192), który w transparentny i globalny sposób pozwala zarządzać
formatowaniem elementów HTML.
Graphical UserInterface
(center.php)
Security and authorization(index.php)
Third Party Call Control GUI
(makeCallGUI.php)
Stylesheet CSS(style.css)
Address List Managment
and Presence GUI(groups.php)
onLoadAll
showCustomer
GetXmlHttpObject
addMember
deleteMember
makeCallFeatures
makeCall
setPresence
fillMenuCallHandling
showRules
clearRules
blockedNumber
forwardingNumber
stateChangeXXX
AJAX Logic
(logic.js)
getPresence
Address List Managment
and Presence Logic(groups.php)
queryMembers
deleteMember
addMember
createGroup
deleteGroup
3rd Party Call Control Logic(makeCall.php)
makeCall
endCall
Call Handling(callhandling.php)
getRules
clearRules
setRules
Seting up Presence(setPresence.php)
publishPresence
PEAR/SOAP
getProxy
Komponenty odpowiedzialne
za prezentację Komponenty z logiką biznesową
Komponent AJAX
CallHandling GUI(callhandling.php)
Rys. 98: Podział funkcjonalny komponentów oraz podział na rodzaje komponentów aplikacji "Centrum
Komunikacji Osobistej"
11.4.1 Opis komponentów prezentacji
Komponenty prezentacji (Third Party Call Control GUI, Address List Managment and
Presence GUI, Call Handling GUI) zagnieŜdŜone są w stronie HTML (center.php), za
pomocą znaczników <div> , w których dynamicznie (bez konieczności przeładowania strony z
192 CSS2 – Cascading Style Sheets, level 2, Specyfikacja CSS w [46]
Centrum Komunikacji Osobistej
181
wykorzystaniem techniki AJAX) moŜe być wstawiany obiekt HTML. W tym przypadku w
stosunkowo łatwy sposób moŜna zrealizować funkcjonalność wyboru przez uŜytkownika
interesujących go modułów. Odbywa się to na poziomie języka PHP. Po uzyskaniu
toŜsamości uŜytkownika, następuje wygenerowanie siatki strony HTML jedynie z wybranymi
znaczkami <div> , które reprezentują poszczególne moduły. W dalszej kolejności wypełnienie
znacznika <div> realizowane jest za pomocą funkcji z komponentu AJAX Logic
(showCustomer(...) , makeCallFeatures(...) , fillMenuCallHandling(...) ,
showRules(...) ).
W komponencie Address List Managment and Presence zostało uwzględnione równieŜ
sterowanie własną informacją o obecności tj. publikowanie oraz jej pobieranie.
Warto wspomnieć, iŜ logika związana ze sterowaniem prezentacją została zaszyta w
komponencie AJAX Logic.
11.4.2 Opis komponentów z logiką aplikacji
Głównym zadaniem komponentów zawierających logikę aplikacji (Setting up
Presence, Address List Managment and Presence Logic, Call Handling, 3rd Party Call
Control Logic) jest odpytywanie usług sieciowych, przetworzenie otrzymanej struktury
danych w odpowiedzi i przygotowanie odpowiedzi na Ŝądanie obiektu AJAX
XMLHttpRequest. Komponenty z logiką biznesową zostały napisane w języku PHP193 ze
względu na istnienie oraz łatwość uŜycia odpowiednich bibliotek wspierających Web Services
(PEAR/SOAP).
KaŜdy komponent tego typu został podzielony na sekcje związane z funkcjonalnością
danego modułu. Np., Logika modułu call handling składa się z trzech sekcji setRules,
getRules, clearRules. Części te są odpowiednio odwzorowywane na funkcje komponentu
AJAX Logic.
W ramach kaŜdej z tych sekcji następuje obsługa usługi sieciowej, która realizowana
jest w trzech krokach:
� ustawienie referencji na Ŝądaną usługę sieciową:
$wsdl=new SOAP_WSDL('http://localhost:8180/axis2/se rvices/CallHa
ndlingService?wsdl');
193 Technika AJAX moŜe współpracować z innymi językami, poniewaŜ komunikacja pomiędzy klientem, a serwerem realizowana jest w oparciu o obiekt przenoszący XML.
Centrum Komunikacji Osobistej
182
� przygotowanie wywołania – stworzenie struktury danych z parametrami
przekazanymi w Ŝądaniu HTTP:
$request = array(
'address' => $_GET['address'],
'rules' => array (
'blockList' => $blockList,
'forward' => array(
'forwardingAddress' => $fo rwardingAddress,
'onBusyAddress' => $forwar dingAddress,
'onNoAnswerAddress' => $fo rwardingAddress
)
)
);
� wywołanie funkcji na obiekcie reprezentującym usługę sieciową:
$response = $client->setRules($request);
� przetworzenie zgodnie z wymaganiami odpowiedzi z usługi sieciowej i wypisanie na
standardowe wyjście PHP. Odpowiedź podobnie jak Ŝądanie jest przewaŜnie tablicą
asocjacyjną z indeksami będącymi nazwami zmiennych.
11.4.3 Opis komponentu AJAX
Komponent AJAX Logic jest łącznikiem pomiędzy graficznym interfejsem
uŜytkownika, a logikę biznesową. Zdarzenie wywołane przez uŜytkownika powoduje
wywołanie funkcji komponentu (np. showRules(...) , makeCall(...) , itp..) zgodnie z
modelem zdarzeń w Java Script. Funkcje te muszą być zbudowane w następujący sposób:
� po pierwsze musi zostać stworzony obiekt XMLHttpRequest (w przypadku, gdy dana
przeglądarka nie obsługuje, wyjątek ten powinien zostać odpowiednio obsłuŜony);
� ustalić adres względny URL komponentu, do którego ma zostać przekazane
wywołanie (np. ../callhandling.php )
� do adresu URL dołączyć tzw. Query String z przekazanymi do funkcji parametrami
(?method=addMember&group=sip:[email protected] )
� ustawić dla właściwości onreadystatechange obiektu XMLHttpRequest tzw.
EventHandler. EventHandler moŜe być dowolną funkcją, która powinna zwrócić 4 w
Centrum Komunikacji Osobistej
183
przypadku, gdy zostanie odebrana cała odpowiedź od serwera. Funkcja ta zastępuje
odpowiedni <div> zawartością odpowiedzi z XMLHttpRequest
(document.getElementById("BuddyList").innerHTML=xmlH ttp.responseText )
.
� Otworzyć połączenie dla wybranego Ŝądania HTTP (np. GET): funkcja
open( Ŝądanie, url, czy wysła ć);
� Wysłać Ŝądanie (funkcja send(null) ).
Komponent AJAX Logic, ma równieŜ modułową budowę, która zapewnia łatwą
rozbudowę aplikacji o kolejne moduły funkcjonalne. Dodanie nowego modułu wiąŜe się ze
stworzeniem nowego EventHandler’a oraz dopisaniem funkcji przywiązanej do określonego
zdarzenia Java Script.
11.4.4 Zasada działania aplikacji
Rejestracja uŜytkownika
Pierwszym etapem w interakcji uŜytkownika z aplikacją jest rejestracja do systemu.
UŜytkownik podaje standardowo login i hasło. Strona zawierająca komponent Security and
authorization zabezpieczona jest z wykorzystaniem protokołu TLS. Dane rejestracyjne są
przesyłane w zaszyfrowanym kanale TLS do serwera. Na serwerze następuje komunikacja z
bazą HSS zawierającą profil uŜytkownika oraz sprawdzenie toŜsamości i uprawnień
uŜytkownika. Ten etap komunikacji nie jest juŜ zabezpieczony, poniewaŜ zgodnie z definicją
JAIN realizowany jest w obszarze bezpiecznym naleŜącym do operatora sieci
Centrum Komunikacji Osobistej
184
Zestawianie połączenia (moduł Make Call)
Rys. 99: Interakcje pomiędzy komponentami w scenariuszu zestawiania połączenia
Pod danym przyciskiem na interfejsie graficznym zostało podpięte zdarzenie Java
Script onClick, a pod zdarzeniem funkcja makeCall(...) . Przeglądarka wywołuje funkcję
makeCall(...) (patrz Rys. 99) w momencie kliknięcia przez uŜytkownika przycisku. Dane o
URI stron, pomiędzy którymi ma zostać zestawione połączenie zostają pobrane z formularza i
przekazane do funkcji makeCall(...) . Funkcja makeCall(...) tworzy nowy obiekt
XMLHttpRequest oraz przygotowuje zapytanie, które ma zostać wysłane do serwera.
Zapytanie (patrz Rys. 99, URL) kierowane jest na adres pliku, w którym znajduje się
komponent makeCall i zawiera nazwę metody oraz adresy stron. Serwer po odebraniu
zapytania wykonuje Web Service Zestawianie Połączenia i w odpowiedzi otrzymuje
identyfikator połączenia, w przypadku gdy połączenie doszło do skutku. Dalej przesyła
dokument XML w obiekcie XMLHttpObject do aplikacji AJAX (moduł AJAX Logic). W
momencie, gdy zostanie przesłany cały XMLHttpObeject funkcja stateChangeMakeCall()
zwraca wartość 4, po czym następuje nadpisanie elementu <div> , w którym zakotwiczony
jest moduł Make Call.
Centrum Komunikacji Osobistej
185
Rys. 100: Diagram UML dla realizowanych kolejno procesów logowania do aplikacji, dodawania nowego
kontaktu do listy, aktualizowania informacji na li ście kontaktowej i w module make call.
Centrum Komunikacji Osobistej
186
11.5 Ograniczenia i propozycje ich rozwiązania
W trakcie tworzenia aplikacji „Centrum Komunikacji Osobistej” pojawiały się
problemy ze spełnieniem załoŜeń projektowych, wynikające z ograniczeń, które posiadały
uŜyte techniki. Ich opis oraz proponowane rozwiązania zostaną przedstawione poniŜej.
Problem związany z brakiem asynchronicznej komunikacji pomiędzy serwerem i
klientem oraz niewystarczająca ilość informacji na temat powodzenia zestawienia bądź
zakończenia połączenia. Dla przykładu wywołanie przez uŜytkownika funkcji
makeCall(...) powoduje zainicjowanie zestawiania sesji pomiędzy dwoma UAs.
UŜytkownik jednak nie otrzymuje informacji zwrotnej na temat tego, czy połączenie doszło
do skutku tzn. czy obie strony je odebrały, czy któraś ze stron była moŜe nie dostępna itp..
Jedyną informacją uzyskiwaną w tym przypadku z wywołania makeCall(...) na usłudze
sieciowej jest potwierdzenie, Ŝe wywołano tą funkcję w Serwerze Sterowania Połączeniami
oraz zwrócony identyfikator połączenia. Autor zaproponował w związku z tym wzbogacenie
informacji o stanie realizowanego połączenia rozszerzając funkcjonalność Serwera
Sterowania Połączeniami194. Odbywa się to po przez zwrócenie odpowiedniego ciągu
znakowego. W przypadku, gdy jedna ze stron jest niedostępna, tzn. Serwer Sterowania
Połączeniami otrzymał wiadomość SIP ‘480 Temporarily Unavailable’ w odpowiedzi usługa
sieciowa zwraca treść tej wiadomości. Natomiast identyfikator połączenia (czyli dowolny ciąg
znaków brany z wygenerowanego nagłówka Call-Id) jest zwracany, gdy Serwer Sterowania
Połączeniami otrzyma wiadomość ACK od strony B. Oznacza to, Ŝe w kaŜdej z
wymienionych wyŜej sytuacji Serwer Sterownia Połączeniami musi zatrzymać na określony
czas wywołanie do momentu otrzymania odpowiedniej wiadomości SIP. Jest to wspomniany
wcześniej problem braku wsparcia dla asynchronicznej komunikacji pomiędzy dostawcą
usługi sieciowej, a jej Ŝądającym. Zbyt długie wstrzymanie Serwera Sterowania Połączeniami
powoduje nieoptymalne wykorzystanie zasobów oraz moŜne doprowadzić do przekroczenia
czasów oczekiwania (time-out) co w efekcie spowoduje wygenerowanie błędu po stronie
klienta, nawet jeśli połączenie doszło do skutku. Jedyną moŜliwością rozwiązania problemu
asynchroniczności request-response jest ustawienie stosunkowo długich time-out na kaŜdym
194 NaleŜy wspomnieć, iŜ zaproponowane rozszerzenie nie jest w pełni zgodne ze specyfikacją Parlay X (patrz [16]), jednak zdaniem autora zwiększa ona znacznie funkcjonalność związaną z zestawianiem połączenia przez trzecią stronę. Zgodnie ze specyfikacją Parlay X informacja, która winna być zwrócona to identyfikator zestawionego połączenia. Przypomnę, Ŝe identyfikator połączenia jest nadawany w momencie wysłania pierwszej wiadomości INVITE i jest to nagłówek Call-Id.
Centrum Komunikacji Osobistej
187
etapie przekazywania odpowiedzi tj. w usłudze sieciowej (konfiguracja AXIS2) oraz na
serwerze WWW.
Problem dotyczący otrzymywania wiadomości jedynie za pomocą standardowego
modelu Ŝądanie-odpowiedź, kwestia asynchroniczności. Istota tego problemu po części jest
związana z tematyką poprzedniego, lecz w tym przypadku zagadnienie asynchroniczności
zostanie rozpatrzone na poziomie aplikacji klienckiej. Problem ten pojawił się m.in. przy
budowie modułu Address List Managment and Presence. Moduł ten wyświetla informacje o
obecności innych obserwowanych uŜytkowników. W przypadku, gdy jeden z nich zmieni
swój stan moduł powinien tą informację zaktualizować. Ze względu na protokół HTTP
aktualizacja informacji wyświetlanych na stronie odbywa się w wyniku ponownego Ŝądania
skierowanego do serwera. AŜeby stan obserwowanych uŜytkowników był w miarę
moŜliwości aktualny, strona powinna być odświeŜana stosunkowo często. Oczywiście
kaŜdorazowe odświeŜenie powoduje zbędne obciąŜenie serwera, poniewaŜ przewaŜenie w tak
krótkim czasie stan obserwowanych nie ulegnie zmianie. Jednak jako uŜytkownicy
chcielibyśmy, aby informacje o stanie obserwowanych uŜytkowników były w miarę
moŜliwości aktualne, tak, więc nie moŜna wydłuŜyć czasu pomiędzy kolejnymi
przeładowniami strony. Dodatkowo przeładowanie strony zajmuje określony czas, co czyni
aplikację mało atrakcyjną i niewygodną w uŜyciu195. Poza tym na stronie znajdują się inne
moduły, które nie wymagają tak częstego odświeŜania, jednak przy odświeŜeniu serwer i tak
będzie musiał wygenerować całą stronę, co powoduje znaczące marnotrawienie jego
zasobów. Największe obciąŜenie poza standardowym Ŝądaniem HTTP następuje podczas
wykonania skryptu PHP. Rozwiązaniem mogłoby być uŜycie języka kompilowanego np.:
C/C++ i wykorzystanie dość mało elastycznego, jednakŜe wydajnego mechanizmu CGI196
(Common Gateway Interface). UŜywając CGI nie moŜna ominąć jednak zasadniczej kwestii
związanej cyklicznym częstym przeładowywaniem strony.
Rozwiązanie tego problemu wymagało zaproponowania przez autora mechanizmu,
który pozwoli aplikacji przeładować wyłącznie197 moduł Address List Managment and
Presence jedynie w momencie, gdy którykolwiek z obserwowanych uŜytkowników zmieni
swój stan.
195 Wyobraźmy sobie, Ŝe nasza aplikacja jest przeładowywana co 5 sekund. 196 Specyfikacja znajduje się w [59]. 197 Aktualizacja pojedynczego modułu zapewnia wcześniej opisywana technika AJAX.
Centrum Komunikacji Osobistej
188
Po stronie klienta utworzono funkcję, która dysponowała maską modułów
wymagających asynchronicznej aktualizacji. Funkcja ta została napisana w Java Script i
zostaje wykonywana cyklicznie w tle. W ramach kaŜdego wykonania zostaje utworzone
Ŝądanie HTTP z minimalną ilością danych (zmienna typu boolowskiego dla kaŜdego z
modułu), potrzebnych jedynie do stwierdzenia, czy dany moduł powinien zostać
zaktualizowany, czy teŜ nie (ustawiana odpowiednio wartość true lub false). Przychodząca
odpowiedź HTTP ze strony serwera zostaje prasowana i po czym następuje sprawdzenie, czy
któraś ze zmiennych została ustawiana na true. Jeśli tak, dokonywane jest wywołanie
odpowiedniej funkcji z komponentu AJAX Logic i przeładowanie wybranego modułu. Innym
ciekawym podejściem do uporania się z omawianym problemem jest mechanizm tzw. HTTP
Streaming. Jest ono rozszerzeniem techniki AJAX polegającym na utrzymywaniu non stop
otwartego połączenia pomiędzy klientem, a serwerem. W czasie trwania połączenia
pojawiające dane natychmiast przesyłane są do klienta.
Oczywiście zaproponowane mechanizmy nie rozwiązują problemu cyklicznego
wykonywania zapytania na poziomie usług sieciowych, co powoduje znaczące obciąŜenie
serwera WWW (jako Ŝądającego usług sieciowych) oraz serwera dostawcy usług
sieciowych198. Wprowadzenie podobnego rozwiązania w usługach sieciowych nie wchodziło
w rachubę, gdyŜ wymagałoby znacznych ingerencji w aplikację będącą dostawcą usług
sieciowych (aplikacja AXIS2). Poza tym, tak zmodyfikowaną aplikację trudno było by
traktować w kategoriach Web Services.
198 NaleŜy pamiętać, Ŝe dostawca usług sieciowych to aplikacja webowa rozmieszczona na serwerze aplikacyjnym Tomcat. Ze względu na to, iŜ jest to środowisko Javy, częste wywołania usług sieciowych w tym środowisku wymagają duŜych mocy obliczeniowych. PoniewaŜ w danym momencie z danej usługi sieciowej moŜe korzystać wielu uŜytkowników wyobraźmy sobie jak znacząco moŜe wzrosnąć obciąŜenie serwera aplikacyjnego (dostawcy usług), które jest wielokrotnością funkcji, która jako argument przyjmuje częstość wykonywania danej usługi przez pojedynczego uŜytkownika.
Podsumowanie
189
12. Podsumowanie
W ramach tej pracy powstało środowisko złoŜone z implementacji wybranych
rdzeniowych199 elementów architektury funkcjonalnej IMS (P-CSCF, S-CSCF, HSS). Zakres
implementacji ograniczony został do procedur umoŜliwiających modelowanie mechanizmu
sterowania usługami200. Kolejnymi komponentami wchodzącym w skład środowiska
badawczego były serwery aplikacyjne implementujące wybrane interfejsy Parlay X API, które
zarówno obsługiwały zgłoszenia skierowane przez S-CSCF (SIP), jak i przez aplikacje
realizującą usługę końcową (SOAP). Przedmiotem implementacji była takŜe aplikacja
„Centrum Komunikacji Osobistej” (CKO) 201, która stanowiła praktyczne sprawdzenie
moŜliwości zrealizowanej architektury.
Rys. 101: Zaimplementowane elementy
Środowisko (Rys. 101) posłuŜyło do analizy czterech problemów:
1. Model sterowania usługami IMS;
2. Realizacja usług w architekturze dwuwarstwowej tj. w warstwie komponentów
usługowych (serwery Parlay X) i w warstwie aplikacji (CKO);
199 W rozumieniu architektury ETSI NGN [17], rdzeniowy IMS (IMS Core) to elementy realizujące wyłącznie funkcje sterowania zgłoszeniami i połączeniami. 200 Mechanizm ten polega na selektywnym przekazywaniu obsługi zgłoszeń do serwerów aplikacyjnych, zgodnie z tzw. regułami filtracji wiadomości SIP (IFC), zawartymi w profilu uŜytkownika. 201 Takich jak ksiąŜka adresowa z funkcją statusu obecności, przekierowanie/blokowanie połączeń, itd..
Podsumowanie
190
3. Implementacja usług za pomocą róŜnych modeli programistycznych na
przykładzie JSLEE, JAIN-SIP, oraz z wykorzystaniem serwisów sieciowych (Web
Services – protokół SOAP);
4. Wykorzystanie rozwiązań open-source w telekomunikacji (szczególnie projekty:
Mobicents JSLEE, Asterisk, Open SER).
Model sterowania usługami IMS
Mechanizm kierowania zgłoszeń do serwerów aplikacyjnych oparty o syntaktyczną
analizę wiadomości SIP w zaleŜności od reguł IFC zawartych w profilu uŜytkownika jest
podstawą modelu sterowania usługami w IMS. Daje on duŜą elastyczność w budowaniu usług
w środowisku wielu serwerów aplikacyjnych. Ta elastyczność wynika głównie z tego, Ŝe
analiza wiadomości jest niskiego poziomu (syntaktyczna). Takie podejście pociąga za sobą
brak bezpośredniego związku pomiędzy scenariuszem usługi (semantyką usługi), a regułami
kierowania zgłoszeń, które wyzwalają wykonanie tej usługi. Ze względu na to definicje IFC
powinny być tworzone z uwzględnieniem wieloznaczności protokołu SIP202, co moŜe rodzić
duŜą złoŜoność tego procesu i wymaga opracowania odpowiednich narzędzi, których obecnie
brak.
Potrzeba dokładnych definicji reguł IFC jest teŜ takŜe wymagana ze względu na
znaczny wzrost ruchu sygnalizacyjnego przy stosowaniu przekierowania wiadomości SIP na
serwery aplikacyjne. Dokładne definicje powinny uwzględniać charakter usługi (co jest
trudne) i minimalizować sytuacje, w których zgłoszenie jest kierowane do serwera
aplikacyjnego pomimo, Ŝe scenariusz usługi tego nie wymaga203.
W środowisku, w którym wiele niezaleŜnych usług jest realizowanych na jednym
serwerze aplikacyjnym, występują problemy związane z interakcjami pomiędzy
scenariuszami usługowymi. W takich sytuacjach mechanizm IFC realizowany w serwerze S-
CSCF nie ma zastosowania i wymagana jest implementacja komponentu odpowiedzialnego
za właściwe kierowanie zgłoszeń w ramach serwera aplikacyjnego. To rozwiązanie zostało
nazwane SCIM, lecz nie zostało ustandaryzowane i w praktyce jest realizowane na kilka
róŜnych sposobów w zaleŜności od implementacji serwera aplikacyjnego. MoŜe to skutkować
202 Te same wiadomości w róŜnych kontekstach mogą być wynikiem realizacji róŜnych usług lub roŜne wiadomości nie, kiedy realizują identyczne funkcje. 203 W takiej sytuacji serwer aplikacyjny pełni funkcje wyłącznie serwera Proxy nie wnosząc nic do scenariusza realizowanego połączenia.
Podsumowanie
191
nieprzenaszalnością komponentów realizujących usługi pomiędzy róŜnymi serwerami
aplikacyjnymi204.
Budowa usług w modelu wykorzystującym Parlay X w systemie IMS
Abstrakcyjność interfejsów Parlay X sprawia, Ŝe aplikacje realizujące usługi mogą
wykonywać swoje scenariusze niezaleŜnie od techniki stosowanej w sieci
telekomunikacyjnej. Implementacja w ramach tej pracy dotyczyła sieci opartej o model NGN,
bazującej na systemie IMS, w którym protokołem sterowania zgłoszeniami jest SIP. Wybrane
interfejsy Parlay X zostały zaimplementowany jako serwery aplikacyjne, które z jednej strony
uczestniczą w modelu sterowania usługami IMS, a z drugiej udostępniają API poprzez
serwisy sieciowe. Serwery aplikacyjne w takim modelu są odpowiedzialne za konwersje
wywołań funkcji takich jak makeCall czy getPresence na sekwencje wiadomości SIP.
Definicja interfejsów Parlay X ma charakter semantyczny, tzn. bezpośrednio wiąŜe się
ze scenariuszem usługowym, a model sterowania usługami IMS jest oparty o analizę
syntaktyczną. Ze względu na to implementacja Parlay X w środowisku systemu IMS jest
bardzo zasadna, poniewaŜ umoŜliwia „przykrycie” przesłonięcie złoŜoności i duŜej liczby
parametrów protokołu SIP, bardzo prostym API.
Techniki programistyczne
Podczas implementacji środowiska badawczego wykorzystano wiele technik
programistycznych, które umoŜliwiły spełnienie przyjętych załoŜeń projektowych
uwzględniających równieŜ m.in. aspekty bezpieczeństwa, wydajności, łatwości uŜycia oraz
funkcjonalności. Techniki te obejmują m.in.:
� język C, w którym został napisany moduł realizujący funkcjonalność CSCF oraz
implementacja interfejsów do HSS. Na poziomie sterowania zgłoszeniami istotną rolę
odgrywa wydajność serwera CSCF.
� język Java wraz z biblioteką dla JAIN SIP API wykorzystany do implementacji
interfejsów Parlay X API. JAIN SIP API pozwala na uŜycie niskopoziomowych
204 W ramach implementacji S-CSCF w środowisku badawczym wprowadzony został mechanizm umieszczania w wiadomościach SIP (przekierowanych do AS) specjalnego nagłówka P-Service-Name (jest to rozszerzenie zaproponowane w ramach tej pracy), który umoŜliwiałby przeniesienie informacji dotyczącej analizy IFC do AS. Ten dodatkowy nagłówek zawiera informacje, do jakiej usługi (definicji IFC) zostało zakwalifikowane zgłoszenie, zwalniałoby to serwer aplikacyjny z konieczności tej analizy i przez to znacznie upraszczało SCIM. To rozwiązanie pomimo, Ŝe zostało zaimplementowane, nie zostało uwzględnione w opisie, gdyŜ nie rozwiązuje problemu interakcji pomiędzy usługami, tylko upraszcza implementacje elementu SCIM, powodując przy tym wiele negatywnych konsekwencji (np. wzrost ilości przekierowań z S-CSCF do AS).
Podsumowanie
192
mechanizmów protokołu SIP. Do komunikacji pomiędzy serwerami z logiką usług, a
serwerem z interfejsami Web Services zastosowano RMI.
� usługi sieciowe (Web Services) będące częścią specyfikacji Parlay X API. Usługi
sieciowe umoŜliwiają korzystanie z usług dostarczanych przez sieć telekomunikacyjną
w sieci Internet. Zapewniają bezpieczeństwo sieci operatora oraz charakteryzują się
prostotą uŜycia.
� techniki wykorzystywane w tworzeniu aplikacji sieciowych m.in. Java Script, PHP,
XHTML, XML i AJAX. Na wyróŜnienie zasługuje technika AJAX, dzięki której
strona internetowa nie musi być przeładowywana. Strona zapewnia uŜytkownikowi
duŜy poziom interakcyji oraz bogatą funkcjoanloność. Przykładem zastosowania jest
np. strona do obsługi poczty Google: www.gmail.com.
� Transport Layer Security zabezpieczająca komunikację pomiędzy aplikacją sieciową,
a serwerem WWW.
Rozwiązania open-source
Stworzone środowisko badawcze opiera się wyłącznie na rozwiązaniach open source,
gdyŜ próba napisania całego środowiska od początku wymagałaby nakładu pracy licznego w
setkach osobolat. Jest to pewien dowód na to, iŜ open-source dostarcza na tyle dojrzałe
rozwiązania, aby mogły być z powodzeniem wykorzystywane w telekomunikacji, choćby w
procesie prototypowania. Takie podejście pozwala przyśpieszyć implementację nowych
koncepcji. UŜyte oprogramowanie charakteryzowało się wysoką jakością, o czym moŜe
świadczyć fakt stosowania go w produktach komercyjnych (np. Open SER, Linux, Asterisk).
W projekcie wykorzystano następujące rozwiązania:
� Open SER;
� Serwer aplikacyjny Apache Tomcat;
� Mobicents - JAIN SLEE;
� Centralkę IP PBX Asterisk;
� System operacyjny Linux dystrybucja Debian’a.
Kierunki dalszej rozbudowy
Zbudowane środowisko badawcze na potrzeby niniejszej pracy stanowi podstawową
implementację systemu IMS, która moŜe zostać wykorzystana do testowania róŜnych
koncepcji kreacji usług telekomunikacyjnych. W trakcie powstawania tej pracy został
udostępniony na licencji GPL projekt Open IMS Core (patrz rozdział 6), który stanowi
Podsumowanie
193
kompletną implementację elementów warstwy sterowania połączeniami tj. CSCF i HSS. W
związku ewentualna rozbudowa moŜe być oparta właśnie o ten projekt. W obszarze
aplikacyjnym środowisko badawcze moŜe być wzbogacone poprzez:
� implementacje pozostałych interfejsów Parlay X jako serwerów aplikacyjnych;
� wykorzystanie serwera aplikacyjnego JSLEE do budowy usług lub implementacji
interfejsów Parlay X;
� do zainstalowania serwera aplikacyjnego z kontenerem do obsługi SIP Servlet.
Bibliografia
194
13. Bibliografia
[1] 3GPP TR 23.982 - IP Multimedia System (IMS) centralized services
[2] 3GPP TR 24.879 - Combining CS calls and IMS sessions
[3] 3GPP TS 23.002 – Network Architecture
[4] 3GPP TS 23.228 - IP Multimedia Subsystem (IMS); Stage 2
[5] 3GPP TS 24.206 - Voice Call Continuity between the Circuit-Switched (CS) domain and
the IP Multimedia Core Network (CN) (IMS) subsystem
[6] 3GPP TS 24.228 - Signaling flows for the IP multimedia call control based on Session
Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3
[7] 3GPP TS 24.229 - IP Multimedia Call Control Protocol based on Session Initiation
Protocol (SIP) and Session Description Protocol (SDP); Stage 3
[8] 3GPP TS 29.199-X - Open Service Access (OSA); Parlay X web services;
[9] 3GPP TS 29.228 - IP Multimedia (IM) Subsystem Cx and Dx Interfaces; Signaling flows
and message contents
[10] 3GPP TS 32.240 - Telecommunication management; Charging management; Charging
architecture and principles
[11] 3GPP TS 32.260 - Telecommunication management; Charging management; IP
Multimedia Subsystem (IMS) charging
[12] Alan B. Johnston, "SIP: Understanding the Session Initiation Protocol", Artech House
2004
[13] Daniel Söbirk, Håkan Jonsson, Kristofer Kimbler - "IMS Programming Models for
Different Business Requirements - Evaluating Existing Programming Models for
SIP/IMS"; konferencja ICIN 2006
[14] Dr. Christoph Bröcker, Sven Haiges, Michael Maretzke - "Ereignisorientierte
Komponenten mit JAIN SLEE", javaspectrum.de, 2005
[15] ECMA Script Language Specification, 1999
Bibliografia
195
[16] ETSI ES 204 915 - Open Service Access (OSA); Application Programming Interface
(API);
[17] ETSI ES 282 001 - NGN Functional Architecture Release 1
[18] ETSI TR 102 397 - Open Service Access (OSA); Mapping of Parlay X 2 Web Services
to Parlay/OSA APIs; Draft
[19] IETF draft-sinha-sip-block, Amardeep Sinha, Sunil Kumar Sinha, The SIP BLOCKED
Response
[20] IETF RFC 2327 - SDP: Session Description Protocol
[21] IETF RFC 2818 - HTTP Over TLS
[22] IETF RFC 3261 - SIP: Session Initiation Protocol
[23] IETF RFC 3264 - An Offer/Answer Model with the Session Description Protocol (SDP)
[24] IETF RFC 3325 - Private Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks
[25] IETF RFC 3455 - Private Header (P-Header) Extensions to the Session Initiation
Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)
[26] IETF RFC 3725 - Best Current Practices for Third Party Call Control (3pcc) in the
Session Initiation Protocol (SIP)
[27] IETF RFC 3840 - Indicating User Agent Capabilities in the Session Initiation Protocol
(SIP)
[28] IETF RFC 3863 - Presence Information Data Format (PIDF)
[29] IETF RFC 3903 - Session Initiation Protocol (SIP) Extension for Event State
Publication
[30] IETF RFC 4317 - Session Description Protocol (SDP) Offer/Answer Examples
[31] IETF RFC 4346 - The Transport Layer Security (TLS) Protocol
[32] IETF RFC 4480 - RPID: Rich Presence Extensions to the Presence Information Data
Format (PIDF)
[33] ITU-T Y.2001 - General overview of NGN
Bibliografia
196
[34] ITU-T Y.2011 - General principles and general reference model for Next Generation
Networks
[35] ITU-T Y.2021 - IMS for Next Generation Networks
[36] JCP JSR 151 - Java 2 Platform, Enterprise Edition 1.4 (J2EE 1.4) Specification
[37] JCP JSR 154 - Java Servlet 2.4 Specification
[38] JCP JSR 21 - JAIN Java Call Control (JCC) Specification
[39] JCP JSR 22 - JAIN Service Logic Execution Environment API Specification 1.0
[40] JCP JSR 240 - JAIN Service Logic Execution Environment API Specification 1.1
[41] Jesse James Garrett, "Ajax: A New Approach to Web Applications", adaptivepath.com,
Luty 2005
[42] Michał Giermasiński, Krzysztof Hennig - "Model implementacji usług
telekomunikacyjnych w hybrydowym środowisku mobilnym WLAN/GPRS",
Politechnika Warszawska, Wydział Elektroniki i Technik Informacyjnych, Warszawa
2004
[43] OASIS Web Services Security: SOAP Message Security 1.1 Specification, 1 Luty 2006
[44] Parlay Group - "Web Services Working Group, Parlay Web Services – Business
Models", Październik 2002
[45] Rajesh Sumra - "Quality of Service for Web Services - Demystification, Limitations,
and Best Practices"
[46] W3C CSS2 - Cascading Style Sheets, level 2 Specification
[47] W3C SOAP Version 1.2 Part 1: Messaging Framework Specification
[48] W3C Web Services Description Language (WSDL) 1.1 Specification
[49] W3C XHTML 1.0 The Extensible HyperText Markup Language Specification
[50] Zygmunt Lozinski - "Parlay/OSA and the Intelligent Network", Pralay Group, Luty
2005
źródła internetowe
[51] http://ajaxpatterns.org/HTTP_Streaming
[52] http://gcc.gnu.org/java/
Bibliografia
197
[53] http://java.sun.com/products/jsp/
[54] http://java.sun.com/products/servlet/
[55] http://www.extreme.indiana.edu/~aslom/exxp/ - "On Performance of Java XML Parsers
(with SOAP)"
[56] http://www.omg.org/technology/documents/spec_catalog.htm
[57] http://www.php.net/
[58] http://www.tinac.com/
[59] http://www.w3.org/CGI/
[60] http://wikipedia.org/
Wykaz stosowanych skrótów
198
14. Wykaz stosowanych skrótów
3GPP 3rd Generation Partnership Project 3PCC Third Party Call Controll AAA Authentication, Authorization, and Accounting AEG Application Expert Group AJAX Asynchronous JavaScript and XML AOR Address of Routing API Application Programming Interface AS Application Server ATM Asynchronous Transfer Mode B2BUA Back-to-Back User Agent BGCF Breakout Gateway Control Function CDR Charging Data Record CGI Common Gateway Interface CSCF Call/Session Control Function CSS Cascading Style Sheets DNS Domain Name System DOM Document Object Model EJB Enterprise Java Bean ETSI European Telecommunications Standards Institute FQDM Fully Qualified Domain Name FSF Free Software Foundation FSM Finite State Machine FTP File Transfer Protocol GGSN Gateway GPRS Support Node GPRS General Packet Radio Service GSM Global System for Mobile Communications GUI Graphical User Interface HLR Home Location Register HSDPA High-Speed Downlink Packet Access HSPA High Speed Packet Access HSS Home Subscriber Server HSUPA High Speed Uplink Packet Access HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol I-CSCF Interrogating-CSCF IETF Internet Engineering Task Force IFC Initial Filter Criteria IMS IP Multimedia Subsystem IN Intelligent Network IP Internet Protocol IP-CAN IP-Connectivity Access Network ISDN Integrated Services Digital Network ISUP ISDN User Part ITU International Telecommunication Union J2EE Java 2 Platform, Enterprise Edition JAIN Java APIs for Integrated Networks JAR Java Archive
Wykaz stosowanych skrótów
199
JAXP Java API for XML Processing JCAT JAIN Coordinations and Transactions JCC JAIN Call Control JCP Java Community Process JMS Java Message Service JMX Java Management Extensions JNDI Java Naming and Directory Interface JSCE JAIN Service Creation Environment JSLEE JAIN Service Logic Execution Environment JSR Java Specification Request MGCF Media Gateway Control Function MGW Media Gateway MMS Multimedia Messaging Service MRFC Multimedia Resource Function Controller MRFP Multimedia Resource Function Processor MSC Mobile Switching Center NAS Network Attachment Subsystem NGN Next Generation Network OCK Osobiste Centrum Komunikacji OSA Open Service Access OSI Open Source Initative PBX Private Branch Exchange P-CSCF Proxy-CSCF PDF Policy Decision Function PEAR PHP Extension and Application Repository PEG Protocol Expert Group PIDF Presence Information Data Format PRUI Private User Identifier PSTN Public Switched Telephone Network PUI Public User Identifier QoS Quality of Service RA Resource Adapter RACS Resorce and Admission Control Subsystem RFC Request For Comment RMI Remote Method Invocation RPIDF Rich Presence Information Data Format RTCP Real Time Control Protocol RTP Real-Time Transport Protocol R-URI Request-URI SBB Service Building Block SCIM Service Capability Interaction Module S-CSCF Serving-CSCF SCTP Stream Control Transmission Protocol SDL Specification and Description Language SDP Session Description Protocol SGW Signaling Gateway SIP Session Initiation Protocol SLF Subscriber Location Function SMS Short Message Service SOAP Simple Object Access Protocol SS7 Signaling System number 7
Wykaz stosowanych skrótów
200
TCP Transmission Control Protocol TLS Transport Layer Security UA User Agent UAS User Agent Server UDDI Universal Description, Discovery and Integration UDP User Datagram Protocol UML Unified Modeling Language UMTS Universal Mobile Telecommunications System URI Uniform Resource Identifier USIM Uniiversal Subscriber Identity Module VCC Voice Call Continuity VLR Visitor Location Register VoIP Voice over IP WSDL Web Service Definition Language XML Extesible Markup Language XMPP Extensible Messaging and Presence Protocol
201
Załącznik A: Definicje kryteriów filtracji IFC w HSS,
stosowane podczas analizy
1. Profil #1
Definiuje przekierowanie wiadomości PUBLISH i SUBSCRIBE dla zgłoszeń
przychodzących do zarejestrowanego i nie zarejestrowanego uŜytkownika, na adres serwera
obecności (sip:[email protected]:5063 i sip:[email protected]:5063).
<profile> <InitialFilterCriteria> <Priority>0</Priority> <SessionCase>1</SessionCase> <TriggerPoint> <ConditionTypeCNF>0</ConditionTypeCNF> <SPT> <ConditionNegated>0</ConditionNegated> <Group>0</Group> <Method>PUBLISH</Method> </SPT> </TriggerPoint> <TriggerPoint> <ConditionTypeCNF>0</ConditionTypeCNF> <SPT> <ConditionNegated>0</ConditionNegated> <Group>0</Group> <Method>SUBSCRIBE</Method> </SPT> </TriggerPoint> <ApplicationServer> <ServerName>sip:[email protected]:5063</ServerName> <DefaultHandling index="0">0</DefaultHandling> </ApplicationServer> </InitialFilterCriteria> <InitialFilterCriteria> <Priority>1</Priority> <SessionCase>2</SessionCase> <TriggerPoint> <ConditionTypeCNF>0</ConditionTypeCNF> <SPT> <ConditionNegated>0</ConditionNegated> <Group>0</Group> <Method>PUBLISH</Method> </SPT> </TriggerPoint> <TriggerPoint> <ConditionTypeCNF>0</ConditionTypeCNF> <SPT> <ConditionNegated>0</ConditionNegated> <Group>0</Group> <Method>SUBSCRIBE</Method> </SPT> </TriggerPoint>
202
<ApplicationServer> <ServerName>sip:[email protected]:5063</ServerName> <DefaultHandling index="0">0</DefaultHandling> </ApplicationServer> </InitialFilterCriteria> </profile>
2. Profil #2
Definiuje przekierowanie wiadomość INVITE dla zgłoszeń przychodzących do nie
zarejestrowanego uŜytkownika, na adres serwera implementującego interfejs Parlay X: Call
Handling (sip:[email protected]:5072).
<profile> <InitialFilterCriteria> <Priority>3</Priority> <SessionCase>2</SessionCase> <TriggerPoint> <ConditionTypeCNF>0</ConditionTypeCNF> <SPT> <ConditionNegated>0</ConditionNegated> <Group>0</Group> <Method>INVITE</Method> </SPT> </TriggerPoint> <ApplicationServer> <ServerName>sip:[email protected]:5072</ServerName> <DefaultHandling index="0">0</DefaultHandling> </ApplicationServer> </InitialFilterCriteria> </profile>
3. Profil #3
Definiuje przekierowanie wiadomość INVITE dla zgłoszeń przychodzących do
zarejestrowanego uŜytkownika, na adres serwera implementującego interfejs Parlay X: Call
Handling (sip:[email protected]:5072).
<profile> <InitialFilterCriteria> <Priority>3</Priority> <SessionCase>1</SessionCase> <TriggerPoint> <ConditionTypeCNF>0</ConditionTypeCNF> <SPT> <ConditionNegated>0</ConditionNegated> <Group>0</Group> <Method>INVITE</Method> </SPT> </TriggerPoint> <ApplicationServer> <ServerName>sip:[email protected]:5072</ServerName>
203
<DefaultHandling index="0">0</DefaultHandling> </ApplicationServer> </InitialFilterCriteria> </profile>
204
Załącznik B: Instrukcja uruchomienia serwerów CSCF i
HSS
Funkcje P-CSCF, S-CSCF i HSS są realizowane z wykorzystaniem dwóch instancji serwera
Open SER oraz bazy danych PostreSQL.
1. ZałoŜenia
Środowiskiem uruchomieniowy jest komputer z architekturą procesora zgodną z x86 i
system operacyjny GNU/Linux. Z hosta tego komputera jest osiągalna baza danych
PostgreSQL (lokalnie lub poprzez sieć). Wymagane oprogramowanie to: libc6 (wersja >=
2.5), libpg5, postgresql-client. UŜytkownik uruchamiający serwery powinien mieć
uprawnienia super-uŜytkownika (su).
W wybranym katalogu naleŜy umieści zawartość /oprogramowanie/ims z płyty
dołączonej do tego opracowania.
Tab. 11: Parametry wymagane do konfiguracji CSCF i HSS
zmienna opis PCSCF_IP Adres IP serwera P-CSCF, np. 127.0.0.1 PCSCF_PORT Port UDP dla protokołu SIP serwera P-CSCF, np. 5060 PCSCF_URI Adres SIP-URI serwera P-CSCF, np. sip:127.0.0.1:5060 SCSCF_IP Adres IP serwera S-CSCF, np. 127.0.0.1 SCSCF_PORT Port UDP dla protokołu SIP serwera S-CSCF, np. 5061 SCSCF_URI Adres SIP-URI serwera S-CSCF, np. sip:127.0.0.1:5061 ICSCF_URI Adres SIP-URI serwera I-CSCF, np. sip:127.0.0.1:5061 DOMAIN Domena dla konfigurowanej sieci SIP, np. eims.local HSS_IP Adres IP bazy PostgreSQL, np. 127.0.0.1 HSS_USER Nazwa uŜytkownika do bazy PostgreSQL HSS_PASS Hasło uŜytkownika do bazy PostgreSQL
2. Konfiguracja
1. NaleŜy zmodyfikować plik cscf/pcscf.cfg:
17: listen=udp:<PCSCF_IP>:<PCSCF_PORT>
44: modparam("ims", "hss_db_url", "postgres://<HSS_USER>:<HSS_PASS>@<HSS_IP>/hss")
91: rewriteuri("<ICSCF_URI>");
100: setdsturi("<SCSCF_URI>");
205
2. NaleŜy zmodyfikować plik cscf/scscf.cfg:
17: listen=udp:<PCSCF_IP>:<PCSCF_PORT>
49: modparam("ims", "hss_db_url", "postgres://<HSS_USER>:<HSS_PASS>@<HSS_IP>/hss ")
50: modparam("ims", "authorization_realm", "<DOMAIN>")
51: modparam("ims", "scscf_name", "<SCSCF_URI>")
52: modparam("auth_db", "db_url", "postgres://<HSS_USER>:<HSS_PASS>@<HSS_IP>/hss ")
100: if (uri=~"<ICSCF_URI>") {
3. NaleŜy utworzyć strukturę bazy danych w PostgeSQL wykorzystując skrypt hss.sql.
4. NaleŜy odpowiednio zmodyfikować dane w bazie, dodając uŜytkowników. Struktura
bazy przedstawiona jest na Rys. 102.
Rys. 102: Struktura danych w HSS
3. Uruchamianie serwerów
Aby wystartować serwery P-CSCF i S-CSCF naleŜy uruchomić skrypt run_cscf.sh.
#>./run_cscf.sh
206
Załącznik C: Instrukcja uruchomienia serwerów
implementujących Parlay X API
Serwery implementujące Parlay X API są realizowane z wykorzystaniem:
� samodzielnych serwerów, napisanych w języku JAVA
� serwera Apache Tomcat 5.0
� bazy danych PostreSQL
� serwera RMI (rmiregistry)
1. ZałoŜenia
Środowiskiem uruchomieniowy jest komputer, na którym jest zainstalowane
środowisko uruchomieniowe JRE 1.5 (Java Run time Environment) i skrypty java oraz
rmiregistry są dostępne poprzez zmienną $PATH. Z hosta tego komputera jest osiągalna baza
danych PostgreSQL (lokalnie lub poprzez sieć). Na komputerze jest zainstalowany serwer
Apache Tomcat 5.0
W wybranym katalogu naleŜy umieści zawartość /oprogramowanie/parlayx z płyty
dołączonej do tego opracowania.
Tab. 12: Parametry wymagane do konfiguracji serwerów Parlay X
zmienna opis SCSCF_IP Adres IP serwera S-CSCF, np. 127.0.0.1 SCSCF_PORT Port UDP dla protokołu SIP serwera S-CSCF, np. 5061 3PCC_IP Adres IP serwera implementującego interfejs Third Party Call, np. 127.0.0.1 3PCC_PORT Port UDP dla protokołu SIP serwera implementującego interfejs Third Party
Call, np. 5074 CH_IP Adres IP serwera implementującego interfejs Call Handling, np. 127.0.0.1 CH_PORT Port UDP dla protokołu SIP serwera implementującego interfejs Call
Handling, np. 5072 TS_IP Adres IP serwera implementującego interfejs Terminal Status, np. 127.0.0.1 TS_PORT Port UDP dla protokołu SIP serwera implementującego interfejs Terminal
Status, np. 5073 PR_IP Adres IP serwera implementującego interfejs Presence, np. 127.0.0.1 PR_PORT Port UDP dla protokołu SIP serwera implementującego interfejs Presence,
np. 5070 HSS_IP Adres IP bazy PostgreSQL, np. 127.0.0.1 HSS_USER Nazwa uŜytkownika do bazy PostgreSQL HSS_PASS Hasło uŜytkownika do bazy PostgreSQL
207
2. Konfiguracja
1. Zawartość katalogu tomcat-shared naleŜy umieścić katalogu shared serwera Tomcat
2. Przy pomocy narzędzie manager naleŜy zainstalować na serwerze Tomcat aplikacje
axis2.war
3. Przy pomocy narzędzia axis2-admin (http://<TOMCAT>/axis2/axis2-admin)205 naleŜy
zainstalować usługi sieciowe: ThirdPartyCallService.aar, CallHandlingService.aar,
TerminalStatusService.aar, GroupManagementService.aar, GroupService.aar,
PresenceConsumerService.aar, PresenceSupplierService.aar
4. NaleŜy zmodyfikować plik parlayx/thirdpartycall_controller_config.xml:
<entry key="javax.sip.IP_ADDRESS"><3PCC_IP></entry>
<entry key="javax.sip.OUTBOUND_PROXY"><SCSCF_IP>:<SCSCF_PORT>/UDP</entry>
<entry key="org.eims.SIP_PORT"><3PCC_PORT></entry>
5. NaleŜy zmodyfikować plik parlayx/callhandling_controller_config.xml:
<entry key="javax.sip.IP_ADDRESS"><CH_IP></entry>
<entry key="javax.sip.OUTBOUND_PROXY"><SCSCF_IP>:<SCSCF_PORT>/UDP</entry>
<entry key="org.eims.SIP_PORT"><CH_PORT></entry>
6. NaleŜy zmodyfikować plik parlayx/terminalstatus_controller_config.xml:
<entry key="javax.sip.IP_ADDRESS"><TS_IP></entry>
<entry key="javax.sip.OUTBOUND_PROXY"><SCSCF_IP>:<SCSCF_PORT>/UDP</entry>
<entry key="org.eims.SIP_PORT"><TS_PORT></entry>
7. NaleŜy zmodyfikować plik parlayx/addresslistmanagement_controller_config.xml:
<entry key="org.eims.HSS_URL">jdbc:postgresql://<HSS_IP>/hss</entry>
<entry key="org.eims.HSS_USER"><HSS_USER></entry>
<entry key="org.eims.HSS_PASSWORD"><HSS_PASS></entry>
8. NaleŜy zmodyfikować plik parlayx/ presence_controller_config.xml:
<entry key="javax.sip.IP_ADDRESS"><PR_IP></entry>
<entry key="javax.sip.OUTBOUND_PROXY"><SCSCF_IP>:<SCSCF_PORT>/UDP</entry>
<entry key="org.eims.SIP_PORT"><PR_PORT></entry>
205 UŜytkownik „admin”, hasło „axis2”
208
3. Uruchamianie serwerów
Aby wystartować serwery implementujące interfejsy Parlay X naleŜy uruchomić skrypt
run_parlayx.sh.
#>./run_parlayx.sh
209
Załącznik C: Instrukcja uruchomienia serwera
obecności
Serwer obecności jest samodzielną aplikacją napisaną w języku JAVA. Szczegółowa
procedura konfiguracji i instalacji zawarta jest w [42].
1. ZałoŜenia
Środowiskiem uruchomieniowy jest komputer, na którym jest zainstalowane
środowisko uruchomieniowe JRE 1.5 (Java Run time Environment) i skrypty java jest
dostępny poprzez zmienną $PATH.
W wybranym katalogu naleŜy umieści zawartość /oprogramowanie/ps z płyty
dołączonej do tego opracowania.
Tab. 13: Parametry wymagane do konfiguracji serwera obecności
zmienna opis PS_IP Adres IP serwera obecności, np. 127.0.0.1 PS_PORT Port UDP dla protokołu SIP serwera obecności, np. 5061 DBS_IP Adres IP serwera bazodanowego dla serwera obecności, np. 127.0.0.1 DBS_PORT Port na którym nasłuchuje serwer bazodanowy, np. 8100
2. Konfiguracja
1. NaleŜy zmodyfikować plik ps/databaseserver/dbs.cfg:
DBS_PORT=<DBS_PORT>
2. NaleŜy zmodyfikować plik ps/presenceserver/ps.cfg:
javax.sip.IP_ADDRESS=<PS_IP>
PRES_PORT=<PS_PORT>
PRES_DBS_ADDRESS=<DBS_IP>
PRES_DBS_PORT=<DBS_PORT>
3. Uruchamianie serwera
Aby wystartować serwer obecności naleŜy uruchomić skrypt run_ps.sh.
#>./run_ps.sh
210
Załącznik D: Instrukcja instalacji aplikacji Centrum
Komunikacji Osobistej
1. ZałoŜenia
Środowiskiem wykonawczym dla aplikacji Centrum Komunikacji Osobistej jest serwer
WWW (np. Apache). Serwer WWW musi mieć zainstalowany moduł dla języka PHP w
wersji 5.0 oraz dodatkową biblioteką PEAR/SOAP 0.9.1. Po stronie klienta wymagane jest,
aby przeglądarka obsługiwała język Java Script 1.2 oraz pozwalała na stronie obiektu
XMLHttpRequest .
Zbiór plików wymienionych w Tab. 14 powinien zostać umieszczony w katalogu
htdocs serwera WWW.
Tab. 14: Wykaz plików wchodzących w skład aplikacji CKO
Plik Katalog Opis center.php /ajax Szkielet strony index.php /ajax Pierwsza strona z oknem do logowania logic.js /ajax Zawiera zestaw funkcji dla AJAX szablon.css /ajax Zawiera zbiór stylów callhandling.php / Obsługa zapytań Web Services i logika usługi
Call Handling groups.php / Obsługa zapytań Web Services i logika usługi
List and Group Management makeCallFeatures.php / Prezentacja modułu 3PCC makeCall.php / Obsługa zapytań Web Services i logika usługi
3PCC setPresence.php / Obsługa zapytań Web Services i logika usługi
Presence dla w danej chwili zalogowanego uŜytkownika CKO
terminalstatus.php / Obsługa zapytań Web Services dla usługi Terminal Status
2. Konfiguracja
NaleŜy zainstalować jedynie wymagane oprogramowanie wskazane powyŜej w
załoŜeniach.
212
Załącznik E: Konfiguracja i uruchomienie bramy
medialnej
Funkcjonalność bramy medialnej realizuje centralka IP PBX ASTERISK. Centralka jest
zainstalowana na serwerze wyposaŜonym w karty TDM z interfejsami E1 obsługującymi
sygnalizację DSS1.
1. ZałoŜenia
Asterisk moŜe zostać zainstalowany na dowolnej dystrybucji Linux. Na potrzeby
środowiska badawczego wykorzystano dystrybucję Linux Debian. System operacyjny
powinien zawierać następujące pakiety:
1. Jądro Linux w wersji 2.4 lub w wersji 2.6
2. Pakiet bison i bison-devel (wymagane do kompilacji Asterisk)
3. Pakiety zlib i zlib-devel
4. Pakiety openssl i openssl-devel
Oprócz kodów źródłowych centralki Asterisk wymagane są libpri oraz zaptel. Kod
źródłowy moŜe zostać pobrany bezpośrednio ze strony www.asterisk.org lub serwera CVS.
PoniŜej podane są instrukcje potrzebne do ściągnięcia wymaganych plików z serwera CVS
dla wersji stabilnej Asterisk 1.2.0.
# cvs checkout -r v1-2-0 zaptel libpri asterisk
W celu kompilacji i instalacji Asterisk naleŜy wykonać poniŜej wylistowane komendy.
NaleŜy zachować kolejność instalacji: libpri, zaptel, asterisk
� Instalacja libpri
#cd /usr/src/asterisk/libpri
#make clean
#make
#make install
� Instalacja zaptel
#cd /usr/src/asterisk/zaptel
213
#make clean
#make install
Uwaga: W przypadku jądra 2.6 naleŜy wykonać następujące polecenie '#make linux26',
przed komendą '#make install'.
� Instalacja asterisk
#cd /usr/src/asterisk/asterisk
#make clean
#make install
� Instalacja standardowej konfiugracji Asterisk
#make samples
2. Konfiguracja
W przypadku, gdy została zainstalowana podstawowa konfiguracja Asterisk wystarczy w
pliku extension.conf dodać następujący wpis. NaleŜy zaznaczyć, iŜ jest to najprostsza
konfiguracja, która pozwala na wykonywanie połączeń bez autoryzacji.
exten => _0XXXXXX,4,Dial(ZAP/${ZAP_MAIN_GROUP}/${EXTEN:1})
exten => _0XXXXXX,5,hangup()
W przypadku podłączenia Asterisk do centrali telefonicznej bazowa konfiguracja
modułu obsługującego kartę TDM powinna wyglądać następująco:
� Plik zapata.conf
group=3
signalling=pri_cpe
channel => 1-15,17-31
3. Uruchamianie Asterisk
Asterisk moŜna uruchomić wpisując następującą komendę:
/etc/init.d/asterisk start