Modele implementacji usług w architekturze IMS

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 pazdziernika 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. WSTP ............................................................................................................................................... 9
2. SESSION INITIATION PROTOCOL........................................................................................... 15
2.1 WSTP....................................................................................................................................... 15
2.2 BUDOWA PROTOKOAU ORAZ MODEL SESJI................................................................................. 15
2.3 KIERUNKI ROZWOJU I ROLA SIP W IMS..................................................................................... 19
3. IP MULTIMEDIA SUBSYSTEM .................................................................................................. 23
3.1 WSTP....................................................................................................................................... 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 USAUGAMI............................................................................................... 35
3.6 PROCES NAWIZYWANIA SESJI.................................................................................................. 38
3.7 KIERUNKI 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 BEZPIECZECSTWO PARLAY X.................................................................................................... 55
4.11 MIEJSCE 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
5.6 PRZYKAADOWA USAUGA BLOKOWANIE POACZEC ................................................................ 83
6. ROLA WOLNEGO OPROGRAMOWANIA W TWORZENIU USAUG
TELEKOMUNIKACYJNYCH.................................................................................................... 87
6.1 WSTP....................................................................................................................................... 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 USAUGAMI
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 USAUGAMI Z WYKORZYSTANIEM FEDERACJI SERWERÓW APLIKACYJNYCH
................................................................................................................................................ 127
9.6 INTERAKCJE POMIDZY USAUGAMI I SERWERAMI APLIKACYJNYMI ......................................... 133
10. ANALIZA I IMPLEMENTACJA INTERFEJSÓW PARLAY X W MODELU USAUGOWYM
IMS................................................................................................................................................ 137
10.1 STEROWANIE ZESTAWIANIEM POACZEC PRZEZ TRZECI STRON (INTERFEJS THIRD PARTY CALL)
................................................................................................................................................ 138
10.2 OBSAUGA POACZEC (INTERFEJS CALL HANDLING)................................................................ 152
10.3 INFORMACJA O STATUSIE TERMINALA (INTERFEJS TERMINAL STATUS)..................................... 160
10.4 ZARZDZANIE 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 ZAAOś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 ROZWIZANIA ................................................................... 186
12. PODSUMOWANIE ....................................................................................................................... 189
7
Spis Treści
13. BIBLIOGRAFIA............................................................................................................................ 194
14. WYKAZ STOSOWANYCH SKRÓTÓW ................................................................................... 198
ZAACZNIK A: DEFINICJE KRYTERIÓW FILTRACJI IFC W HSS, STOSOWANE
PODCZAS ANALIZY................................................................................................................. 201
ZAACZNIK A: DEFINICJE KRYTERIÓW FILTRACJI IFC W HSS, STOSOWANE
PODCZAS ANALIZY................................................................................................................. 201
ZAACZNIK B: INSTRUKCJA URUCHOMIENIA SERWERÓW CSCF I HSS........................ 204
ZAACZNIK C: INSTRUKCJA URUCHOMIENIA SERWERÓW IMPLEMENTUJCYCH
PARLAY X API........................................................................................................................... 206
ZAACZNIK C: INSTRUKCJA URUCHOMIENIA SERWERA OBECNOŚCI ......................... 209
ZAACZNIK D: INSTRUKCJA INSTALACJI APLIKACJI CENTRUM KOMUNIKACJI
OSOBISTEJ.................................................................................................................................. 210
ZAACZNIK E: KONFIGURACJA I URUCHOMIENIE BRAMY MEDIALNEJ...................... 212
8
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
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
10
Wstęp
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.
11
Wstęp
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
12
Wstęp
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 Michał Kościesza
zaproponowanego w IP Multimedia Subsystem
10. Analiza i implementacja interfejsów Parlay X w modelu
usługowym IMS
10.1 Sterowanie zestawianiem połączeń przez trzecią stronę Michał Misiak
(interfejs Third Party Call)
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 Michał Kościesza
Management)
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
13
Część I
Podstawy teoretyczne
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/odpowiedz . 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
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:ala@eims.local)
16
Session Initiation Protocol
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ądz innych serwerów Proxy.
Funkcja serwera rejestru (Registrar) polega na gromadzeniu i udostępnianiu
informacji o lokalizacji sieciowej tj. skojarzenia pomiędzy identyfikatorem
17
Session Initiation Protocol
u\ytkownika Sip-URI (np. sip:ala@eims.local) 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).
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.
18
S
I
P
Session Initiation Protocol
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).
19
Session Initiation Protocol
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ę
20
Session Initiation Protocol
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.
21
Session Initiation Protocol
A B A B
INVITE INVITE
180 Trying 180 Trying
180 Ringing 183 Session Progress
200 OK PRACK
ACK 200 OK
UPDATE
transmisja mediów 200 OK
180 Ringing
PRACK
200 OK
200 OK
ACK
transmisja mediów
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ń.
22
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
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 (zródło [17])
Zgodnie z referencyjną funkcjonalną architekturą ETSI (patrz Rys. 5) sieć NGN mo\na
podzielić na:
24
IP Multimedia Subsystem
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.
25
IP Multimedia Subsystem
Rys. 6: Dualna architektura sieci UMTS (zró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.
26
IP Multimedia Subsystem
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.
27
IP Multimedia Subsystem
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.
28
IP Multimedia Subsystem
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.
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.
29
5
3
.
B
.
B
I
I
N
N
E
E
V
T
V
I
T
I
I
I
V
T
T
V
E
E
N
I
N
I
.
B
B
.
2
4
IP Multimedia Subsystem
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ądz
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).
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
Si Cx
Wx C D Gr Gc Rp Sh
SIP
gsmSCF
Application
Server
GMSC MSC / VLR
SGSN GGSN OSA SCS IM-SSF CSCF
CS Domain
PS Domain
IM CN subsystem
3GPP AAA Server Applications GUP Server
Rys. 10: Logiczna architektura HSS (zró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.
30
IP Multimedia Subsystem
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.
31
IP Multimedia Subsystem
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.
32
IP Multimedia Subsystem
d. realizować zestawienie połączenia w modelu trzeciej strony tzw. 3rd-Party-
Call-Control (rola 4 z Rys. 12).
Application Application
Server Server
From: X
SIP leg #1
To: Y
SIP leg #1
Call-ID: Z
From: X
To: Y
Call-ID: Z
S-CSCF S-CSCF
SIP leg #1 SIP leg #1
From: X
From: X
To: Y
To: Y
Call-ID: Z
Call-ID: Z
Application
Application
Server
Server
From: P
SIP leg #2
From: X
To: Q
SIP leg #1
SIP leg #1
To: Y
Call-ID: R
SIP leg #1 From: X
Call-ID: Z
From: X
To: Y
To: Y
Call-ID: Z
Call-ID: Z
S-CSCF
SIP leg #1 SIP leg #2
S-CSCF
SIP leg #1 SIP leg #1
From: X From: P
From: X From: X
To: Y To: Q
To: Y To: Y
Call-ID: Z Call-ID: R
Call-ID: Z Call-ID: Z
Rys. 12: Role jakie mo\e przyjmować serwer aplikacyjny w obsłudze połączeń (zró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.
33
IP Multimedia Subsystem
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).
34
IP Multimedia Subsystem
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 = ala@eims.local )).
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 ala@eims.local.
33
XML-Schema jest językiem opisu składni dokumentów XML (patrz http://www.w3.org/XML/Schema).
35
IP Multimedia Subsystem
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.
36
IP Multimedia Subsystem
Rys. 15 ilustruje przykładowy scenariusz realizacji zgłoszenia, w którym jest
wykorzystywany mechanizm sterowania usługami.
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 .
37
6
.
3
.
.
2
.
5
7
.
IP Multimedia Subsystem
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.
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.
38
4.
4.
5.
7.
3.
3.
2.
2.
1.
6
.
.
1
IP Multimedia Subsystem
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.
39
IP Multimedia Subsystem
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.
40
IP Multimedia Subsystem
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).
41
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
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.
43
Parlay/OSA oraz Parlay X
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 znalezć 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
44
Parlay/OSA oraz Parlay X
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]).
45
Parlay/OSA oraz Parlay X
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.
46
Parlay/OSA oraz Parlay X
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.
47
Parlay/OSA oraz Parlay X
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.
48
Parlay/OSA oraz Parlay X
Tab. 1 Zestawienie interfejsów Parlay X z podziałem na kategorie.
Kategoria Nr. Usługa Opis
Ogólne 1 Ogólne definicje Definiuje podstawowe typy danych XML, przestrzenie
typów danych nazw, typy błędów oraz zało\enia do opis interfejsów
przy pomocy WSDL.
Call 2 Third Party Call Zestawianie i zarządzanie połączeniami stworzonymi
Related 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.
12 Multimedia Interfejs ten umo\liwia kreację połączeń
Conference telekonferencyjnych i dynamiczne zarządzanie
uczestnikami telekonferencji oraz rodzajem mediów.
Messaging 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..
5 MMS Posiada podobną funkcjonalność jak interfejs powy\ej
z tym, \e obsługuje EMS, MMS, IM, e-mail, etc..
Charging 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..
7 Account Funkcjonalność doładowywania kont sprawdzania ich
management dla u\ytkowników pre-paid.
Terminal 8 Terminal status Za pomocą tej usługi mo\na uzyskać status terminala,
Related grupy terminali oraz powiadomienia o zmianie statusu
terminala.
9 Terminal Dostęp do informacji o lokalizacji (wysokość, długość
location oraz szerokość geograficzna) danego terminala, grupy
terminali. Usługa ta pozwala ustawić powiadomienia o
zmianie lokalizacji.
14 Presence Usługa ta pozawala na uzyskanie informacji o
obecności u\ytkownika oraz na zarządzanie nią.
49
Parlay/OSA oraz Parlay X
Rother 13 Address List Interfejs umo\liwia zarządzanie grupami kontaktów
Management (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
UDDI
Rejestr Usług Siecowych
Definicja Usługi Sieciowej
Definicja Usługi Sieciowej
Definicja Usługi Sieciowej
Web Services Broker
WSDL WSDL
ZNAJDy REJESTRUJ
Serwer Aplikacyjny Parlay Brama Parlay Web Services
PRZYWIś
Logika
Interfejs
Definicja Usługi Sieciowej
usługi
Aplikacyjny
Definicja Usługi Sieciowej
Aplikacje Parlay
KOMUNIKACJA Parlay X
Usługa Sieciowa
SOAP
Web Services Requestor Web Services Provider
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].
50
Framework
Parlay/OSA oraz Parlay X
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ózniejsze 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.
51
Parlay/OSA oraz Parlay X
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 zró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ózniejszego 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 ;
52
Parlay/OSA oraz Parlay X
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).
53
Parlay/OSA oraz Parlay X
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].
54
Parlay/OSA oraz Parlay X
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ęzle
UDDI
Web Service Provider, a\eby zarejestrować usługę w węzle 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ęzle UDDI.
Mechanizm bezpieczeństwa w momencie rejestracji usługi w prywatnym węzle
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]).
55
Parlay/OSA oraz Parlay X
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ęzle 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].
56
Parlay/OSA oraz Parlay X
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ć.
57
Parlay/OSA oraz Parlay X
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 (Web Services)
Parlay X
Parlay/OSA API
OSA
AS
SCS
ISC Sh
S-CSCF HSS
Cx
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 przezroczysty, 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.
58
Parlay/OSA oraz Parlay X
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).
59
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
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 Creation
Aplikacje niezaufane tworzone Aplikacje zaufane tworzone
Environment
przez trzecią stronę przez trzecią stronę
(JSCE)
Service APIs
JAIN Service Provider Security Interface
JAIN Service Logic Exectuion Environment Usługi
(JSLEE)
Call Control/Session API
Sygnalizacja
JAIN Call Control (JCC)
and JAIN Coordination and Transactions (JCAT)
Protocol/Connection API
Sieć
TCAP ISUP INAP SIP MAP MAP
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.
61
JAIN Service Logic Execution Environment
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 znalezć na stronie Sun Microsystems.
62
JAIN Service Logic Execution Environment
Asynchroniczność, przetwarzanie zorientowane na zdarzenia. Komponenty
rejestrują się poprzez mechanizm publish/subscribe66 w zró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.
Aatwość integracji z innymi systemami. Niezale\ność od sieci. JSLEE wprowadza
koncepcje Resource Adapters, które stanowią zró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: zró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.
63
JAIN Service Logic Execution Environment
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 Głównie synchroniczne
są generowane z ró\nych sieci (wywołania funkcji, bazy danych)
wykorzystujących ró\ne protokoły)
Poziom Bardzo du\a częstotliwość, zdarzenia Mała częstotliwość, zdarzenia
ziarnistości są bardzo proste (odwzorowują przenoszą du\ą ilość informacji
zdarzeń wiadomości protokołów) (dane z baz danych)
Komponenty Lekkie komponenty, oferujące Cię\kie komponenty, realizują
skromną funkcjonalność. Du\a liczba zawansowane zadania związane
kreacji i usuwania komponentów np. z przetwarzaniem zapytań do
baz danych. Mogą istnieć przez
długi czas na dysku np.
komponenty trwałe (persistient)
yródła danych Wiele zródeł danych (np. ró\ne Głównie serwery bazodanowe
protokoły, bazy danych)
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 TAK NIE koniecznie
rzeczywisty
Rozmieszczenie Rozproszone w sieci (częściowo Scentralizowane, bazy danych
mobilnej) 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.
64
JAIN Service Logic Execution Environment
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 odpowiedz. 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 odpowiedz np.: z komunikatem 304 albo przekazanie do kolejnego
SIP PROXY B. Jak mo\na się domyślić odpowiedz od SIP PROXY B mo\e przyjść w
dowolnym momencie (czas potrzebny na przetworzenie, dowolnie pózna odpowiedz 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.
65
JAIN Service Logic Execution Environment
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ą odpowiedz. Odpowiedz ta mo\e nadejść w dowolnym
momencie. Komponenty te są ze sobą luzno 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
66
Oczekiwanie na odpowiedz
Oczekiwanie na odpowiedz
Oczekiwanie na odpowiedz
JAIN Service Logic Execution Environment
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
zró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.
67
JAIN Service Logic Execution Environment
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 .
68
JAIN Service Logic Execution Environment
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; Bazuje na komponentach, architektura
obiektowa;
Brak modelu standaryzacji dla budowy
zło\onych aplikacji i ponownego Jednostką jest Service Building Block;
wykorzystania;
Ideą jest wspomaganie ponownego
69
JAIN Service Logic Execution Environment
wykorzystywania stworzonych wcześniej
komponentów;
Stanowość aplikacji
Servlety są bezstanowe; SBB mogą być zarówno bezstanowe lub
stanowe;
Współdzielony stan pomiędzy
poszczególnymi wywołaniami Servletu jest Stan SBB jest prywatny, przechowuje
przechowywany osobno jako para ciąg bezpieczne typy, utrzymywany w ramach
znaków i obiekt; transakcji i jest właściwością samego SBB;
Współdzielony stan jest widoczny dla Współdzielone stany mogą być
wszystkich Servletów, które mają dostęp do przechowywane w oddzielnych Activity
danej sesji; 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. Zarządzany przez system, np. izolacja na
Wykorzystanie mechanizmu monitorów w poziomie transakcji;
Javie;
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), Stan zarządzany przez kontener (SBB CMP,
który mo\e być replikowany; Activity Context, etc..). Stan ten mo\e być
replikowany;
Brak mechanizmu transakcji dla
przetwarzanych wiadomości SIP; Zdarzenia dostarczane w ramach transakcji;
Stan nie jest utrzymywany w ramach Operacje dla stanu zarządzanego przez
transakcji; kontener utrzymane są w ramach transakcji;
Generyczna funkcjonalność nie jest dostępna Funkcjonalności, np. timer są dostępne w
w ramach transakcji; transakcji;
Brak modelu dla obsługi błędów; Dobrze zdefiniowany i zrozumiały model
obsługi błędów po przez mechanizm
transakcji;
Zarządzanie
70
JAIN Service Logic Execution Environment
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.
Aplikacja do zarządzania
JMX
JAIN SLEE Kontener
Agent JMX
Timers
Service
Building
Service Service
Alarms Blocks
Building Building
Blocks Blocks
Tracing
Service
Building
Interfejsy do zarządzania
AC Naming
Blocks
usługami oraz SLEE
Usage
Resource Adaptor Resource Adaptor Resource Adaptor
JAIN API Inne API
Zasoby sieciowe
Rys. 26: Architektura JSLEE
71
JAIN Service Logic Execution Environment
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.
72
JAIN Service Logic Execution Environment
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 zró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óznienie 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óznień 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óznień 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.
73
JAIN Service Logic Execution Environment
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.
74
JAIN Service Logic Execution Environment
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.
Rys. 28: Główne elementy JSLEE i powiązania pomiędzy nimi
75
Kontener
JAIN Service Logic Execution Environment
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ędz 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
76
JAIN Service Logic Execution Environment
X1, X2, Z2 będące Root-SBB. Konkretne jednostki SBB mogą nale\eć tylko do jednego
drzewa.
Rys. 30: Drzewo SBB Entity (zró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.
77
JAIN Service Logic Execution Environment
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 (zró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.
78
JAIN Service Logic Execution Environment
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.
79
JAIN Service Logic Execution Environment
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.
80
JAIN Service Logic Execution Environment
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 Profilami
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 zró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.
81
JAIN Service Logic Execution Environment
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
() oraz zawiera Description-Element () i inne Service-
Eelments (). 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.
82
JAIN Service Logic Execution Environment
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 zró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 zró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].
83
JAIN Service Logic Execution Environment
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 zró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 zródłowy 2).
W metodzie setSbbContext, która znajduje się w kodzie zró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 zródłowego 1 i kodu zródłowego 2 został zło\ony kompletny SBB, realizujący
usługę blokowania połączeń. Kod tego SBB znajduje się w kodzie zró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.
84
JAIN Service Logic Execution Environment
Kod yró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.getOriginatingAddress();
if (source != null && source.getName().equals(address)){
return;
}
// Czytanie numerów dla usługi callblocking z profli
ProfileID id = profileFacility.getProfileID( ... )
CallBlockingAddressProfileCMP profile = getProfile(id);
Address[] blocked = profile.getBlockedAddresses();
// Sprawdzenie listy numerów i ewentualne zablkowanie zgłoszzenia.
Boolean block = false;
for (int i = 0; i < blocked.length && !block; i++)
{
block = (blocked[i] != null && blocked[i].getAddressString().
equals(source.getName()));
}
if (block) {
connection.release(JccEvent.CAUSE_DEST_NOT_OBTAINABLE);
}
} catch (Exception e) { ... }
finally { ... }
}
Kod zró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.lookup("profile");
}
catch (NamingException ne)
85
JAIN Service Logic Execution Environment
{
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 zródłowy 3: Klasa SBB-CallBlocking
public abstract class CallBlockingSbb implements Sbb
{
private SbbContext context;
private ProfileFacility profileFacility;
// SBB-Funkcje związane z cyklem \yciwoym usługi (Kod zródłowy 2) ...
// Logika usługowa przetwarzająca zdarzenia (Kod zródłowy 1) ...
}
86
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
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.
88
Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych
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 Sun Projekt open source. Rozwijany przez Open
Implementation Mikrosystem 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 jNetX Komercyjny produkt. OCFS wspiera oprócz
Feature Server (OCFS) 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ń.
89
Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych
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).
90
Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych
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 blizniaczy 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.
91
Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych
(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.
92
Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych
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
zró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ł.
93
Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych
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. yró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.
94
Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych
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 dzwię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..).
95
Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych
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ózniej. 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
96
Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych
Rys. 38: Architektura i składniki projektu Open IMS Core (zró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.
97
Część II
Implementacja i analiza
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
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.
100
Specyfikacja problemu i cele analizy
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
101
Specyfikacja problemu i cele analizy
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
102
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
ś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
104
Architektura środowiska badawczego
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.
105
Interfejs usług sieciowych Parlay X
(SOAP/HTTP)
interfejs ThirdPartyCall interfejs CallHandling interfejs TerminalStatus interfejs AddressListManagement interfejs Presence
J2SE
Serwer obsługi połączeń
Serwer sterowania Serwer zarządzania ksią\ką adresową Serwer udostępniający
Serwer
połączeniami 3PCC informacje o stanie obecności
udostępnianiainformacji o
u\ytkownika
stanie terminala
u\ytkownika
Set Rule
Delete Member Add Member
Get User Presence
Cancel Call Get Rule
Delete Group Create Group
Publish User Presence
Make Call Clear Rule Get Status
Query Members
stos JAIN-SIP
Interfejs sterowania usługami (SIP-ISC)
Asterisk PBX
Open SER
HSS
S-CSCF
Open SER
Procedura MGCF
Terminating-Service-Control Procedura Cx-Server-Assignment
P-CSCF
Procedura Procedura Cx-Multimedia-Authorization
Originating-Service-Control
Procedura Cx-User-Authorization
Procedura
SIP SIP
Procedura 'Assert Identity' Registration-Notification
I-CSCF
prolile u\ytkowników
MGW
Procedura
elementy implementowane w ramach
User-Registration-Query
środowiska badawczego
gotowe komponenty open
SIP
source
Interfejs do sieci PSTN
(ISDN-PRA)
Sieć PSTN
sieć IP
Rys. 41: Architektura
ś
rodowiska badawczego
Architektura
ś
rodowiska badawczego
106
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.
IP Multimedia Networks
Legacy mobile
signalling Networks
PSTN
Mb Mb PSTN
BGCF I-CSCF
Mm
PSTN
Mk Mk
Mw
C, D,
Mj
BGCF
Gc, Gr
Mi
Cx
IMS- MGCF HSS
S-CSCF
MGW
Mg
Mn
SLF
Mr
Dx
Mw
Mb
P-CSCF
MRFP MRFC
UE
Gm
Mp
Gq
Mb Mb Mb IM Subsystem
Rys. 42: Zakres implementacji (kolor zielony) modelu usługowego w środowisku badawczym na tle
architektury funkcjonalnej IMS (zró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
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.
108
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
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.
109
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
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
110
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
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.
111
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
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
112
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
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.
113
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
Odpowiedz 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.
Odpowiedz 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.
114
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
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..);
Odpowiedz HSS składa się z:
Kodu określającego rezultat operacji;
Profilu u\ytkownika.
115
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
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).
116
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
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
117
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
jest zarejestrowany w IMS)116. Rys. 54 pokazuje przykładową obsługę zgłoszenia dla
nie zarejestrowanego u\ytkownika.
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.
118
Profil B
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
INVITE sip:B@eims.local SIP/2.0 INVITE sip:B@eims.local SIP/2.0
P-Original-Dialog-ID: call-id=de40707c-cede-db11-8499@rubi;from-tag=2644707c P-Original-Dialog-ID: call-id=de40707c-cede-db11-8499@rubi;from-tag=2644707c
P-Service-Name: P-Service-Name:
sip:as1.eims.local
sip:as2.eims.local
AS#1
AS#2
Profil A
IFC, priorytet 1 = INVITE na sip:usluga1@as1.eims.local
IFC, priorytet 2 = INVITE na sip:usluga2@as2.eims.local
P-CSCF P-CSCF
1. INVITE B 6. INVITE B
u\ytkownik #A u\ytkownik #B
service control
S-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
119
5
3
.
B
.
B
I
I
N
N
E
E
V
T
V
I
T
I
I
I
V
T
T
V
E
N
E
I
N
I
.
B
B
.
2
4
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
powinno być skierowane do serwera aplikacyjnego o adresie
sip:usluga1@as1.eims.local
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.
120
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
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.
121
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
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).
122
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
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.
123
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
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.
124
7. Cx-UAA
5. Cx-UAR
2
2
2
.
0
C
1
.
x
1
C
-
.
S
9
x
C
.
-
A
S
x
C
A
-
A
x
M
R
-
M
A
A
A
R
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
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.
125
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
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:ala@eims.local. Publiczny identyfikator jest wykorzystywany w S-CSCF jako tzw AOR (Address of
routing), który w skojarzeniu z FQDM umo\liwia routing wiadomości.
126
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
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.
127
sip:ala@eims.local
4. INVITE
sip:ala@10.10.10.10:8060
5. INVITE

l
u
l
a
i
f
c
o
o
r
l
.
p
s
e
i
m
i
n
e
a
d
@
a
a
l
\
a
.
:
2
p
i
s

l
i
f
o
r
p
.
3
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
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 Znaczenie i mo\liwe wartości Przykład zastosowania
budowy
kryteriów filtracji
Request-URI Określa, do jakiego węzła SIP Stosuje się zawsze tam, gdzie przy
jest adresowana wiadomość. konstrukcji reguły wa\ne jest, do
Zazwyczaj przyjmuje wartość kogo jest adresowana sesja.
publicznego identyfikatora Przykładowo, je\eli serwer
wywoływanego u\ytkownika. aplikacyjny realizuje usługę
Np. sip:ala@eims.local polegającą na blokowaniu połączeń
na określony adres.
rodzaj \ądania Mo\e przyjmować wartości W przypadku usługi obecności,
określające rodzaje \ądań. Np. reguła przekierowania powinna
INVITE, BYE, SUBSCRIBE, uwzględniać wiadomości
itd. SUBSCRIBE i PUBLISH, które
powinny być kierowane do serwera
obecności133.
wartość Składa się z nazwy nagłówka Nagłówki w wiadomościach SIP
określonego oraz z wartości, którą przenoszą bardzo wiele informacji.
nagłówka przyjmuje. Reguła Przykładowo, jeśli obsługa w
wykorzystująca to pole mo\e serwerach aplikacyjnych jest
stosować dowolne nagłówki. zale\na od sieci dostępowej
Np. P-Access-Network-Info: 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 .
128
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
access-type=3GPP-GERAN rozró\nienia zgłoszeń
albo P-Asserted-Identity: pochodzących z ró\nych sieci
ela@eims.local 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: Ka\da reguła musi być
0 dla połączeń wychodzących przyporządkowana do określonego
1 dla przychodzących rodzaju sesji. Część usług jest
2 dla przychodzących do wywoływana podczas zgłoszeń
niezarejestrowanego przychodzących (1 i 2) a część dla
u\ytkownika 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 Zawiera wyra\enia regularne, SDP zawiera informacje takie jak:
połączenia które odnoszą się do SDP. 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.
129
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
widomości do AS o odpowiednim priorytecie. Wynikiem tego mechanizmu jest przejście
wiadomości SIP przez tzw. łańcuch serwerów aplikacyjnych
AS AS AS
profil
S-CSCF
u\ytkownik #B
u\ytkownik #A
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.
3. wykonanie logiki usługi +
ewentualna modyfikacja
AS AS
wiadomości INVITE AS
S-CSCF S-CSCF
S-CSCF
u\ytkownik #A u\ytkownik #B u\ytkownik #A u\ytkownik #B
u\ytkownik #A u\ytkownik #B
1. 2a. 2b.
sygnalizacja
(SIP)
Rys. 62: Mechanizm "zakotwiczania" sesji SIP przez serwer aplikacyjny (AS)
130
2. BYE
3. BYE
2. INVITE
4. INVITE
7. 200 OK
8. 200 OK
5
4
2
E
.
E
E
.
.
T
I
I
N
B
B
Y
Y
V
V
Y
Y
B
B
6
K
N
I
.
.
E
E
I
.
T
O
1
1
2
.
E
0
0
1
0
0
2
O
.
K
9
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
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].
131
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
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.
132
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
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.
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
133
3. 200 OK
2. PUBLISH
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
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).
134
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
AS AS
SCIM
SIP Applilcatioo
nn
SIP App
Server icati
Server
Sh
ISC
OSA service
OSA
OSA service
OSA
HSS capabililiyy server
tt server application
S CSCF
--
HSS capabi
S CSCF
application
ISC (SCS))
server
Cx (SCS
server
OSA API
ISC
Si
IM SSF
--
IM SSF
MAP
CAP
Camel Service
Camel Service
Environment
Environment
Rys. 67: Architektura funkcjonalna warstwy aplikacyjnej IMS (zró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.
135
Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem
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.
136
usługa #D
usługa #C
usługa #B
usługa #A
6.
2.
7.
.
.
.
3
4
5
p
r
o
f
i
l
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óznienia, itp..
142
Nale\y przypomnieć, \e jest to projekt open source, w którym wiele rzeczy pozostaje tajemnicą nawet dla
jego twórców. Znalezliś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
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ózniejszą 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.
138
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
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.
139
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
stanu sesji funkcja
określenie
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.
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].
140
GetCallInformation
CancelCall
MakeCall
EndCall
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
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)
odpowiedz, 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 przezroczysty 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 odpowiedz149 (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.
141
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
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].
142
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
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.
143
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
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 sterownik sip: user_b@eims
(1) INVITE oferta1
bez mediów

(2) 200 OK odpowiedz2
bez mediów
(3) ACK
(4) INVITE bez SDP

(5) 200 OK oferta2
(6) INVITE oferta2
(7) OK odpowiedz2
(8) ACK odpowiedz2
(9) ACK
Strumień Mediów (RTP/RTCP)
Rys. 74: Diagram wiadomości dla sposobu IV zestawiania sesji przez trzecią stronę
144
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
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 Nie Tak Tak Nie
mediach
Inne Mo\liwość Nie ma W efekcie,
wystąpienia gwarancji, \e mo\e nie zostać
pętli terminale mają zestawiony
zgodne kodeki 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.
145
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
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.
146
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
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ł.
147
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
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
148
Przeglądarka
WWW
Serwer HTTP
Apache + PHP
Tomcat + Axis 2
Serwer Aplikacyjny
Serwer Sterowania Połączeniami
(JAIN SIP)
Aplikacja 3PCC
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
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.
149
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
Rys. 77: Diagram UML z wywołaniami funkcji dla przykładowego procesu zestawiania sesji i
uruchamiania serwera.
150
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
Rys. 78: Logika Serwera Sterowania Połączeniami w postaci diagramu SDL.
151
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
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
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
152
SetRulesForGroup
ClearRules
GetRules
SetRules
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
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..
153
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
Tab. 7: Definicja typu danych: CallHandlingRules
Nazwa elementu Typ elementu Opcjo- Opis
Nalny
AcceptList xsd:anyURI Tak Lista numerów, z których
[0..unbounded] połączenie zostanie
zaakceptowane
BlockList xsd:anyURI Tak Lista numerów, z których
[0..unbounded] połączenie zostanie odrzucone
ForwardList ConditionalForward tak Lista numerów, na które
[0..unbounded] 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 Opcjo- Opis
elementu nalny
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.
154
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
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 dzwię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.
155
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
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.
156
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
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ł.
157
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
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.
158
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
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.
159
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
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
a@eims.local i c@eims.local 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.
160
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
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.
161
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
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_d
ev_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.
162
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
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ł.
163
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
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).
164
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
ParlayX - Address List Management
group member group management
interface interface 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].
165
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
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 odpowiedz 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 .
166
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
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).
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
167
queryMembers
deleteMember
addMember
updateSubscriptionAuthorization
startPresenceNotification
endPresenceNotification
getSubscribedAttributes
getOpenSubscriptions
subscribePresence
subscriptionEnded
notifySubscription
blockSubscription
getUserPresence
getMyWatchers
statusChanged
statusEnd
publish
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
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.
Pet
Presence suppliers
Watcher
applications
Presence
Pex
Pw
Presence External agent (Presence
List Server
information provided by elements
outside the provider s network)
Watcher
Pw
Presence Proxy
Pep
Pw
Presence User agent
Peu
(Presence information
Px
Presentity
provided by the user)
Presence Proxy
Pen
HSS
Pwp
Presence Network agent (Presence
(HLR)
information provided by the
network)
Pp
Pr
Pc
Ph Pi Pg Presence server
Pk Pl
(home network)
3GPP AAA MSC Server
PDG HSS/HLR S-CSCF SGSN
GGSN GMLC
Server /VLR
Interfaces Ph, Pi, Pc, Pg, Pk and Pl are based on existing Release 5
procedures e.g. CAMEL, MAP, CAP, RADIUS, ISC, Cx, Sh.
The Pr, Pp interfaces are based on existing Release 6 procedures of
the 3GPP- WLAN interworking architecture.
Rys. 90: Architektura usługi obecności w sieci 3GPP (zró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
168
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
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].
169
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
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]).
170
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
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 appointment
Available away
Busy breakfast
DoNotDisturb busy
OnThePhone dinner
Steering holiday
Meeting in-transit
Away looking-for-work
Meal meal
PermanentAbsence meeting
Holiday on-the-phone
Performance permanent-absence
InTransit playing
Travel presentation
171
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
Sleeping shopping
ActivityOther 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.
interakcja z aplikacja
u\ytkownikiem
CKO*
Parlay X
interfejs ParlayX: Presence 7. Konwersja modeli obecności z
J2SE
SIP na Parlay X
Serwer udostępniający
10. Konwersja modeli obecności z
informacje o stanie
3. Zapamietanie stanu obecności
Parlay X na SIP
obecności u\ytkownika
12. Zapamietanie stanu obecności
5. SUBSCRIBE
Get User Presence
6. NOTIFY
Publish
11. PUBLISH
stos JAIN-SIP
*) CKO = Centrum Komunikacji Osobistej
CSCF
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
172
2
.
P
U
B
L
I
S
H
H
S
I
L
B
U
P
.
1
Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS
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).
173
Centrum Komunikacji Osobistej
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 znalezć pod adresem: http://www22.verizon.com/business/iobi/.
174
Centrum Komunikacji Osobistej
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.
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.
175
Przeglądarka
JavaScript
Aplikacja
WWW
+ PHP
Serwer
AXIS v.2
Aplikacyjny +
(PEAR 0.9.1)
Serwer HTTP
Centrum Komunikacji Osobistej
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ć.
176
Centrum Komunikacji Osobistej
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.
177
Centrum Komunikacji Osobistej
Przeglądarka Server
(1) request: index.php
GET
(2) generowanie index.php
(3) wywołanie AJAX
ze zdarzenia JavaScript
POST
(4) Przetworzenie \ądania AJAX
(5) uzupełnienie \ądanej treści z
u\yciem modelu DOM
(8) wywołanie AJAX
POST
ze zdarzenia JavaScript v (7) Przetworzenie \ądania AJAX
(9) uzupełnienie \ądanej treści
z u\yciem modelu DOM
Utworzenie obiekt XMLHttpRequest Wypełniony danymi obiekt XMLHttpRequest
\ądanie odpowiedz
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:
178
Centrum Komunikacji Osobistej
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ózniejszego 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].
179
Centrum Komunikacji Osobistej
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.
Komponenty odpowiedzialne
za prezentację
Komponenty z logiką biznesową
Address List
getProxy
Managment
and Presence GUI
PEAR/SOAP
(groups.php)
Komponent AJAX
Graphical User
makeCall
onLoadAll
Interface
3rd Party Call
(center.php) endCall
showCustomer
Control Logic
addMember (makeCall.php)
deleteMember
makeCallFeatures
Stylesheet CSS getRules
makeCall
(style.css)
clearRules
setPresence Call Handling
(callhandling.php)
setRules
fillMenuCallHandling
showRules
clearRules
Third Party Call
publishPresence
blockedNumber
Control GUI
(makeCallGUI.php)
Seting up Presence
forwardingNumber
(setPresence.php)
GetXmlHttpObject
stateChangeXXX
Security and
authorization
(index.php) queryMembers
deleteMember
Address List
addMember
Managment
and Presence Logic
getPresence
(groups.php)
CallHandling GUI createGroup
(callhandling.php)
deleteGroup
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

, w których dynamicznie (bez konieczności przeładowania strony z
192 CSS2 Cascading Style Sheets, level 2, Specyfikacja CSS w [46]
180
(logic.js)
AJAX Logic
Centrum Komunikacji Osobistej
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

, które reprezentują poszczególne moduły. W dalszej kolejności wypełnienie
znacznika

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/services/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.
181
Centrum Komunikacji Osobistej
przygotowanie wywołania stworzenie struktury danych z parametrami
przekazanymi w \ądaniu HTTP:
$request = array(
'address' => $_GET['address'],
'rules' => array (
'blockList' => $blockList,
'forward' => array(
'forwardingAddress' => $forwardingAddress,
'onBusyAddress' => $forwardingAddress,
'onNoAnswerAddress' => $forwardingAddress
)
)
);
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. Odpowiedz 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:ala@eims.local)
ustawić dla właściwości onreadystatechange obiektu XMLHttpRequest tzw.
EventHandler. EventHandler mo\e być dowolną funkcją, która powinna zwrócić 4 w
182
Centrum Komunikacji Osobistej
przypadku, gdy zostanie odebrana cała odpowiedz od serwera. Funkcja ta zastępuje
odpowiedni

zawartością odpowiedzi z XMLHttpRequest
(document.getElementById("BuddyList").innerHTML=xmlHttp.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
183
Centrum Komunikacji Osobistej
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

, w którym zakotwiczony
jest moduł Make Call.
184
Centrum Komunikacji Osobistej
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.
185
Centrum Komunikacji Osobistej
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ądz
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.
186
Centrum Komunikacji Osobistej
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-odpowiedz, 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
Wyobrazmy 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.
187
Centrum Komunikacji Osobistej
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
odpowiedz 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 wyobrazmy 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.
188
Podsumowanie
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..
189
Podsumowanie
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.
190
Podsumowanie
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).
191
Podsumowanie
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
192
Podsumowanie
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.
193
Bibliografia
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
194
Bibliografia
[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
195
Bibliografia
[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", Pazdziernik 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
zródła internetowe
[51] http://ajaxpatterns.org/HTTP_Streaming
[52] http://gcc.gnu.org/java/
196
Bibliografia
[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/
197
Wykaz stosowanych skrótów
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
198
Wykaz stosowanych skrótów
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
199
Wykaz stosowanych skrótów
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
200
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:registered@ps.eims.local:5063 i sip:unregistered@ps.eims.local:5063).

0
1

0

0
0
PUBLISH

0

0
0
SUBSCRIBE

sip:registered@ps.eims.local:5063
0

1
2

0

0
0
PUBLISH

0

0
0
SUBSCRIBE

201

sip:unregistered@ps.eims.local:5063
0

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:callhandling@as.eims.local:5072).

3
2

0

0
0
INVITE

sip:callhandling@as.eims.local:5072
0

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:callhandling@as.eims.local:5072).

3
1

0

0
0
INVITE

sip:callhandling@as.eims.local:5072
202
0

203
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::
44: modparam("ims", "hss_db_url", "postgres://:@/hss")
91: rewriteuri("");
100: setdsturi("");
204
2. Nale\y zmodyfikować plik cscf/scscf.cfg:
17: listen=udp::
49: modparam("ims", "hss_db_url", "postgres://:@/hss ")
50: modparam("ims", "authorization_realm", "")
51: modparam("ims", "scscf_name", "")
52: modparam("auth_db", "db_url", "postgres://:@/hss ")
100: if (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
205
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
206
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:///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:
<3PCC_IP>
:/UDP
<3PCC_PORT>
5. Nale\y zmodyfikować plik parlayx/callhandling_controller_config.xml:

:/UDP

6. Nale\y zmodyfikować plik parlayx/terminalstatus_controller_config.xml:

:/UDP

7. Nale\y zmodyfikować plik parlayx/addresslistmanagement_controller_config.xml:
jdbc:postgresql:///hss

8. Nale\y zmodyfikować plik parlayx/ presence_controller_config.xml:

:/UDP

205
U\ytkownik admin , hasło axis2
207
3. Uruchamianie serwerów
Aby wystartować serwery implementujące interfejsy Parlay X nale\y uruchomić skrypt
run_parlayx.sh.
#>./run_parlayx.sh
208
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=
2. Nale\y zmodyfikować plik ps/presenceserver/ps.cfg:
javax.sip.IP_ADDRESS=
PRES_PORT=
PRES_DBS_ADDRESS=
PRES_DBS_PORT=
3. Uruchamianie serwera
Aby wystartować serwer obecności nale\y uruchomić skrypt run_ps.sh.
#>./run_ps.sh
209
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.
210
3. Uruchamianie serwera
Aplikacja zostaje uruchomiona w momencie wystartowania serwera WWW.
211
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 zródłowych centralki Asterisk wymagane są libpri oraz zaptel. Kod
zró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
212
#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
213
W celu zarządzania centralką nale\y podłączyć się do uruchomionego demona w
następujący sposób:
asterisk vvvvvc
214

Wyszukiwarka

Podobne podstrony:
Modele biznesowe e usług
rup implementation model?11A0C
20 Organizacja usług dodatkowych w zakładzie hotelarskim
Budowanie wizerunku firmy poprzez architekturę
NiBS 3 Rozklad trojkatny Modele Starzenie obiektow nieodnawianych
Modele wzrostu, rozwoju gospodarczego
modele rownan
kultura org Modele i teorie
architekt arki
technik architektury krajobrazu21[07] z2 01 u
refine the architecture?F2AA31

więcej podobnych podstron