214
POLITECHNIKA WARSZAWSKA Rok akademicki Wydzial Elektroniki i Technik Informacyjnych 2006/2007 Instytut Telekomunikacji PRACA DYPLOMOWA MAGISTERSKA Michal Jan Kościesza Michal Daniel Misiak Modele implementacji uslug w architekturze IMS Praca wykonana pod kierunkiem dra inŜ. Marka Średniawy ……………………….. ocena pracy ……………………….. podpis Przewodniczącego Komisji Warszawa, 2007 r.

Praca dyplomowa magisterskamath.uni.lodz.pl/~mmisiak/res/mgr.pdf · Parlay X jest zbiorem API umo Ŝliwiaj ących tworzenie aplikacji w sposób niezale Ŝny od rozwi ąza ń technicznych

  • Upload
    others

  • View
    2

  • Download
    0

Embed Size (px)

Citation preview

POLITECHNIKA WARSZAWSKA Rok akademicki Wydział Elektroniki i Technik Informacyjnych 2006/2007 Instytut Telekomunikacji

PRACA DYPLOMOWA MAGISTERSKA

Michał Jan Kościesza Michał Daniel Misiak

Modele implementacji usług w architekturze IMS

Praca wykonana pod kierunkiem dra inŜ. Marka Średniawy

……………………….. ocena pracy ……………………….. podpis Przewodniczącego Komisji

Warszawa, 2007 r.

„Models of service implementation in the IMS architecture”

Abstract

IMS is an IP-based service architecture specified by 3GPP for UMTS. The architecture

became main part of ETSI and ITU NGN reference model, which defines new public

telecommunication network architecture. IMS offers broad set of functionalities, like

multimedia sessions or context aware environment. These features open new service creation

opportunities, which require suitable software development models and technologies.

Parlay X is a set of technology-independent APIs which enable development of

applications that operate across different telecommunication networks. APIs contain abstract

methods (e.g. makeCall) that describe basic network functionalities. Parlay APIs can be

implemented on SIP application servers and thus can be adapted to the IMS service model.

Jain-SLEE is a Java based service execution environment, which defines a component based

model for structuring the application logic of communications. JSLEE represents a different

approach in comparison to Parlay concept and defines both an execution environment and

API. Using SIP resource adapter JSLEE implementation can be used as an IMS application

server.

The thesis focuses on analysis of IMS service architecture and different programming

approaches that can be used in the service implementation process. Within the scope was also

implementation of an IMS environment, based on open source software. This process was

divided into 3 areas:

- IMS service control model, which is responsible for session-handling transfer to

specified application server based on subscriber profile.

- Parlay X capability server that implements selected APIs in the IMS environment.

- web-based application, which takes advantage of Parlay X APIs and implements end-

user service with rich “contacts management” functionality .

The environment became a “playground” for research on aspects of creating service

applications in a multi-layered, real-time and asynchronous next generation

telecommunication network.

“Modele implementacji usług w architekturze IMS”

Streszczenie

IMS jest architekturą usługową opracowaną przez 3GPP dla sieci UMTS. Referencyjny

model sieci NGN, który jest definiowany przez ETSI oraz ITU wykorzystuje IMS w swojej

rdzeniowej części. Nowa architektura oferuje szeroki zakres funkcjonalności, otwierający

nowe moŜliwości kreacji usług. Wymaga to opracowania modeli programistycznych, które

będą odpowiednie do nowego środowiska sieciowego.

Parlay X jest zbiorem API umoŜliwiających tworzenie aplikacji w sposób niezaleŜny od

rozwiązań technicznych zastosowanych w sieci. Zbiór ten złoŜony jest z abstrakcyjnych

metod (np. makeCall), które opisują podstawowe funkcjonalności sieci. Implementacja

Parlay X API jako serwera aplikacyjnego wykorzystującego protokół SIP, umozliwia

integracje z systemem IMS. Jain-SLEE jest środowiskiem programistycznym opartym o

model komponentowy umoŜliwiający tworzenie aplikacji, realizujących usługi

telekomunikacyjne. W odróŜnieniu od Parlay, definiuje zarówno API jak i środowisko

wykonywania usług. Wykorzystując tzw. SIP resource adapter, aplikacje Jain-SLEE mogą

być wykorzystywane do implementacji usług w IMS.

Przedmiotem niniejszej pracy jest analiza architektury usługowej IMS oraz technik

programistycznych, które mogą być wykorzystane w procesie implementacji. Zakres

obejmuje takŜe implementacje środowiska IMS opartego o oprogramowanie open source. Ten

proces moŜna podzielić na 3 obszary:

- Model sterowania połączeniami w IMS, który polega na przekazywaniu obsługi

zgłoszeń do serwerów aplikacyjnych w oparciu o profil uŜytkownika.

- Serwery implementujące wybrane interfejsy Parlay X w środowisku IMS

- Aplikacje wykorzystująca Parlay X API, do implementacji scenariusza usług.

Powstałe środowisko zostało wykorzystane do badań związanych z róŜnymi aspektami

kreacji usług w wielowarstwowej architekturze sieci następnej generacji.

śyciorysy

Michał Jan Kościesza

Urodziłem się w 29 października 1981 roku w Nowym Sączu.

Ukończyłem Liceum Ogólnokształcące im. Jana Zamoyskiego w

Warszawie i w roku 2002 rozpocząłem studia na Wydziale Elektroniki i

Technik Informacyjnych. Po dwóch latach wybrałem specjalność Teleinformatyka i

Zarządzanie w Telekomunikacji. Od 2005 roku pracuję w Działe Rozwoju Sieci Rdzeniowej i

Usług firmy Polkomtel S.A. Zdobytą na studiach wiedzę, a w szczególności tą podczas badań

związanych z przedmiotem tej pracy, z sukcesem wykorzystuję w Ŝyciu zawodowym.

Michał Daniel Misiak

Urodziłem się w 11 grudnia 1982 roku w Płocku. Ukończyłem Liceum

Ogólnokształcące im. Władysława Jagiełło w Płocku i w roku 2002

rozpocząłem studia na Wydziale Elektroniki i Technik Informacyjnych.

Po dwóch latach studiów wybrałem specjalność Teleinformatyka i

Zarządzanie w Telekomunikacji. W 2006 roku odbyłem stypendium

zagraniczne Sokrates-Erasmus w Niemczech na uczelni Hochschule Esslingen na wydziale

informatyki. W połowie 2006 roku przyjąłem propozycję stworzenia własnego działu

Rozwoju Produktu w eTel Telecom Austria Group i do chwili obecnej piastuję stanowisko

kierownika tegoŜ działu. Solidna wiedza zdobyta na studiach pozwala mi realizować się w

Ŝyciu zawodowym.

Prywatnie interesuje się fizyką teoretyczną oraz sportami motorowodnymi.

Autorzy pragną podziękować

Panu dr inŜ. Markowi Średniawie

za nieocenioną pomoc w trakcie pisania niniejszej pracy

Spis treści

śYCIORYSY ............................................................................................................................................. 2

ABSTRACT................................................................................................................................................ 2

SPIS TREŚCI ............................................................................................................................................. 5

1. WSTĘP ............................................................................................................................................... 9

2. SESSION INITIATION PROTOCOL........................................................................................... 15

2.1 WSTĘP....................................................................................................................................... 15

2.2 BUDOWA PROTOKOŁU ORAZ MODEL SESJI................................................................................. 15

2.3 K IERUNKI ROZWOJU I ROLA SIP W IMS..................................................................................... 19

3. IP MULTIMEDIA SUBSYSTEM .................................................................................................. 23

3.1 WSTĘP....................................................................................................................................... 23

3.2 IMS JAKO RDZENIOWA CZĘŚĆ ARCHITEKTURY NGN ................................................................ 24

3.3 ARCHITEKTURA IMS................................................................................................................. 27

3.4 PROFIL UśYTKOWNIKA .............................................................................................................. 33

3.5 MODEL STEROWANIA USŁUGAMI............................................................................................... 35

3.6 PROCES NAWIĄZYWANIA SESJI.................................................................................................. 38

3.7 K IERUNKI ROZWOJU.................................................................................................................. 38

4. PARLAY/OSA ORAZ PARLAY X................................................................................................ 42

4.1 GENEZA PARLAY /OSA.............................................................................................................. 42

4.2 OPIS PARLAY /OSA ................................................................................................................... 43

4.3 ARCHITEKTURA PARLAY /OSA..................................................................................................44

4.4 OGRANICZENIA PARLAY /OSA ..................................................................................................46

4.5 PARLAY X (PARLAY WEB SERVICES)........................................................................................ 46

4.6 MODELE BIZNESOWE................................................................................................................. 47

4.7 FUNKCJONALNOŚĆ PARLAY X API ........................................................................................... 48

4.8 ARCHITEKTURA PARLAY X......................................................................................................... 50

4.9 OGRANICZENIA PARLAY X........................................................................................................ 54

4.10 BEZPIECZEŃSTWO PARLAY X.................................................................................................... 55

4.11 M IEJSCE PARLAY /OSA I PARLAY X W ARCHITEKTURZE IMS ................................................... 57

5. JAIN SERVICE LOGIC EXECUTION ENVIRONMENT........... .............................................. 60

5.1 INICJATYWA JAIN..................................................................................................................... 60

5.2 DEFINICJA JSLEE, WYMAGANIA DLA JSLEE............................................................................ 62

5.3 PORÓWNANIE TECHNIK J2EE I JSLEE ...................................................................................... 64

5.4 PORÓWNANIE TECHNIK JSLEE VS SIP SERVLET....................................................................... 67

5.5 ARCHITEKTURA JSLEE............................................................................................................. 71

Spis Treści

7

5.6 PRZYKŁADOWA USŁUGA – BLOKOWANIE POŁĄCZEŃ ................................................................ 83

6. ROLA WOLNEGO OPROGRAMOWANIA W TWORZENIU USŁUG

TELEKOMUNIKACYJNYCH.................................................................................................... 87

6.1 WSTĘP....................................................................................................................................... 87

6.2 LINUX W ZASTOSOWANIACH TELEKOMUNIKACYJNYCH ............................................................ 88

6.3 OPEN SOURCE JSLEE – MOBICENTS......................................................................................... 89

6.4 OPEN SIP EXPRESS ROUTER......................................................................................................90

6.5 ASTERISK.................................................................................................................................. 92

6.6 OPEN IMS CORE....................................................................................................................... 96

7. SPECYFIKACJA PROBLEMU I CELE ANALIZY ............... .................................................... 99

8. ARCHITEKTURA ŚRODOWISKA BADAWCZEGO ............................................................. 103

9. IMPLEMENTACJA I ANALIZA MODELU STEROWANIA USŁUGAMI

ZAPROPONOWANEGO W IP MULTIMEDIA SUBSYSTEM .......... .................................. 107

9.1 OPIS ZAIMPLEMENTOWANYCH MECHANIZMÓW....................................................................... 108

9.2 PROCEDURA WSTAWIENIA INFORMACJI O IDENTYFIKACJI UśYTKOWNIKA (ASSERT IDENTITY) . 108

9.3 PROCEDURA PRZYDZIELENIA SERWERA S-CSCF PODCZAS PIERWSZEJ REJESTRACJI AGENTA

UśYTKOWNIKA (USER-REGISTRATION-QUERY) ........................................................................ 110

9.4 ZAIMPLEMENTOWANY PROCES REJESTRACJI UśYTKOWNIKA I REALIZACJA MOBILNO ŚCI W SIECI

................................................................................................................................................ 123

9.5 MODEL STEROWANIA USŁUGAMI Z WYKORZYSTANIEM FEDERACJI SERWERÓW APLIKACYJNYCH

................................................................................................................................................ 127

9.6 INTERAKCJE POMIĘDZY USŁUGAMI I SERWERAMI APLIKACYJNYMI ......................................... 133

10. ANALIZA I IMPLEMENTACJA INTERFEJSÓW PARLAY X W MODELU USŁUGOWYM

IMS................................................................................................................................................ 137

10.1 STEROWANIE ZESTAWIANIEM POŁĄCZEŃ PRZEZ TRZECIĄ STRONĘ (INTERFEJS THIRD PARTY CALL)

................................................................................................................................................ 138

10.2 OBSŁUGA POŁĄCZEŃ (INTERFEJS CALL HANDLING)................................................................ 152

10.3 INFORMACJA O STATUSIE TERMINALA (INTERFEJS TERMINAL STATUS)..................................... 160

10.4 ZARZĄDZANIE LISTĄ KONTAKTÓW (INTERFEJS ADDRESS LIST MANAGEMENT) ......................... 164

10.5 INFORMACJA O STATUSIE OBECNOŚCI (INTERFEJS PRESENCE) ................................................. 167

11. CENTRUM KOMUNIKACJI OSOBISTEJ ............................................................................... 174

11.1 ZAŁOśENIA PROJEKTOWE DLA APLIKACJI................................................................................ 174

11.2 ARCHITEKTURA APLIKACJI......................................................................................................175

11.3 PROCES TWORZENIA APLIKACJI Z WYKORZYSTANIEM PARLAY X ........................................... 178

11.4 KOMPONENTY APLIKACJI........................................................................................................ 179

11.5 OGRANICZENIA I PROPOZYCJE ICH ROZWIĄZANIA ................................................................... 186

12. PODSUMOWANIE ....................................................................................................................... 189

Spis Treści

8

13. BIBLIOGRAFIA............................................................................................................................ 194

14. WYKAZ STOSOWANYCH SKRÓTÓW ................................................................................... 198

ZAŁ ĄCZNIK A: DEFINICJE KRYTERIÓW FILTRACJI IFC W HSS, S TOSOWANE

PODCZAS ANALIZY................................................................................................................. 201

ZAŁ ĄCZNIK A: DEFINICJE KRYTERIÓW FILTRACJI IFC W HSS, S TOSOWANE

PODCZAS ANALIZY................................................................................................................. 201

ZAŁ ĄCZNIK B: INSTRUKCJA URUCHOMIENIA SERWERÓW CSCF I HS S........................ 204

ZAŁ ĄCZNIK C: INSTRUKCJA URUCHOMIENIA SERWERÓW IMPLEMENT UJĄCYCH

PARLAY X API........................................................................................................................... 206

ZAŁ ĄCZNIK C: INSTRUKCJA URUCHOMIENIA SERWERA OBECNO ŚCI ......................... 209

ZAŁ ĄCZNIK D: INSTRUKCJA INSTALACJI APLIKACJI CENTRUM KOMUNIKACJI

OSOBISTEJ.................................................................................................................................. 210

ZAŁ ĄCZNIK E: KONFIGURACJA I URUCHOMIENIE BRAMY MEDIALNE J...................... 212

1. Wstęp

Ewolucja sieci telekomunikacyjnej spowodowana jest koniecznością tworzenia nowych

usług i doskonalenia dotychczasowych. Aby to osiągnąć, stosuje się róŜne koncepcje i

rozwiązania. Sieć inteligentną (Intelligent Network) moŜna uznać za jedną z pierwszych

takich koncepcji. Architektura IN udostępniła funkcjonalność usługową sieci przez

rozdzielenie funkcji związanych ze sterowaniem połączeniami i zgłoszeniami (SSP) od

funkcji związanych z wykonywaniem usług o wartości dodanej (SCP). IN wprowadza model

sterowania scenariuszem usługi oraz środowisko kreacji. Istotną wartością dodaną, jaką

koncepcja sieci inteligentnej wniosła do świata telekomunikacyjnego, było dostrzeŜenie

potrzeby standaryzacji tam, gdzie dotychczas jej nie było, czyli w obszarze usług1. Pomimo

tych udoskonaleń, oferowane aplikacje były jedynie nowymi wariacjami tradycyjnej usługi

głosowej2, polegającymi głównie na odpowiednim sterowaniu jej scenariuszem.

Postrzeganie usług przez abonentów zmieniło się diametralnie w momencie pojawienia

się Internetu. Stał się on kopalnią nowych usług w wyniku odwrócenia paradygmatu

umiejscowienia „inteligencji” w sieci. Usługi stały się aplikacjami, a ich logika znajdowała

się na obrzeŜach - w terminalach uŜytkowników3, a Internet stanowił jedynie medium do

transmisji danych. W związku z tym wiele usług mogło być realizowanych z pominięciem

operatorów telekomunikacyjnych, a ich rola mogła zostać ograniczona głównie do

zapewnienia szerokopasmowego dostępu do sieci.

Szybki rozwój sieci pakietowych i coraz większa powszechność rozwiązań bazujących

na IP spowodowała powstanie wielu koncepcji łączących moŜliwości Internetu i

telekomunikacji. Początkowo były to proste próby przeniesienia usługi głosowej (tzw. Voice

Over IP), jednak w miarę rozwoju pakietowej transmisji danych, zaczęto pracować nad

zastąpieniem dotychczasowej architektury sieci telekomunikacyjnej przez architekturę opartą

1 Standaryzacji został poddany interfejs pomiędzy SSP a SCP. Środowisko uruchomieniowe i model programistyczny pozostały poza normalizacją, co spowodowało, Ŝe aplikacje realizujące usługi nie były przenośne pomiędzy rozwiązaniami róŜnych dostawców. Ze względu na to wprowadzenie IN doprowadziło do częściowego tylko otwarcia sieci na model realizacji usług przez „trzecią stronę”. 2 Oczywiście nie naleŜy zapominać, iŜ w tejŜe sieci oprócz usług głosowych moŜna było realizować usługę wideotelefonii. Jednak zainteresowanie tą usługą w śród uŜytkowników było marginalne. 3 W IN ma miejsce odwrotna sytuacja. Aplikacja realizująca usługę jest wykonywana po stronie sieci.

Wstęp

10

o protokół IP. Model NGN4 stał się urzeczywistnieniem tych prac i miał na celu opracowanie

uniwersalnej sieci usługowej pozwalającej zarówno na komunikację głosową, jak i transmisję

wideo oraz danych, z uwzględnieniem róŜnych wymagań jakościowych.

IP Multimedia Subsystem jest architekturą usługową, która stanowi rdzeniowy element

sieci NGN. IMS ma zapewnić neutralność dostępową (w załoŜeniu), ujednolicić sterowanie

zgłoszeniami oraz zdefinować styk z warstwą aplikacyjną, tworząc tym samym spójne

środowisko do kreacji usług konwergentnych5. To środowisko dostarcza narzędzi

pozwalających przyspieszyć proces budowy nowych usług oraz obniŜyć ich koszt6.

Protokołem wykorzystywanym w IMS jest rozszerzona wersja Session Initiation

Protocol. Cechy SIP umoŜliwi ą realizację złoŜonych usług konwergentnych, które w jednej

sesji komunikacyjnej mogą łączyć wideo, głos, przesyłanie danych (np., komunikaty

natychmiastowe) oraz uwzględniać informację o obecności7. Istotnym elementem środowiska

IMS są serwery aplikacyjne, w których następuje wykonywanie aplikacji realizujących usługi.

Wbrew pozorom, standard IMS pozostawia duŜą swobodę i elastyczność w ich tworzeniu,

poniewaŜ nie definiuje modelu komponentów aplikacyjnych ani środowiska wykonywania

usług. Takie podejście sprawia, Ŝe implementacja wymaga adaptacji odpowiednich technik

programistycznych (np. Web Services, Servlety, etc..). Informatyka od połowy lat 60 XX

wieku wpływa na kształt rozwiązań stosowanych w telekomunikacji (np. zastosowanie

sterowania programowego w centralach 1 ESS). W miarę rozwoju techniki i koncepcji w

informatyce konwergencja pomiędzy tymi dwoma dziedzinami staje się coraz głębsza.

Szczególnie chętnie adoptowane są powszechnie stosowane techniki (np. Java, Web

Services), które umoŜliwiają tworzenie usług szerszej grupie osób.

W warstwie aplikacji projektant moŜe korzystać z wielu rozwiązań, choćby takich jak:

SIP Servlet API, JAIN SIP API, JAIN SLEE, Parlay/OSA API, Parlay X. KaŜda z tych technik

ma cechy, które sprawiają, Ŝe kaŜda z tych aplikacji lepiej się sprawdza w określonym

zastosowaniu niŜ pozostałe. Przykładowo Parlay X moŜe być wykorzystany w sytuacji, gdy

operator chciałby udostępnić funkcjonalność sieci w bezpieczny sposób jak najszerszej grupie

4 Patrz rozdział 3. 5 Usług, w których przenikają się róŜne formy komunikacji, jak np. głos, wideo, wiadomości natychmiastowe, lub szeroko rozumiana obecność. 6 Ze względu na brak „dojrzałych” implementacji w komercyjnych sieciach, postulat dotyczący optymalizacji pod względem kosztu i czasu wdroŜenia usług nie został jeszcze w praktyce sprawdzony. 7 Z ang. Presence

Wstęp

11

potencjalnych twórców aplikacji. Jeśli natomiast pojawia się potrzeba udostępnienia bardziej

zaawansowanej8 funkcjonalności, ale wciąŜ dostępnej dla szerokiego kręgu dostawców,

najlepiej w tym przypadku jest zastosować Parlay/OSA API. Zakładając, Ŝe aplikacja ma

wykorzystywać niskopoziomową funkcjonalność sieci a jednocześnie charakteryzować się

wysoką wydajnością, naleŜałoby zastanowić się na uŜyciem do tego celu JAIN SIP.

Standard JAIN SLEE jest wynikiem dąŜenia do stworzenia jednolitego modelu

programistycznego oraz środowiska wykonawczego dla usług9. W architekturze JSLEE

aplikacja zbudowana jest z mniejszych komponentów (Service Building Block), których

moŜna ponownie uŜyć do budowy innych aplikacji. Jest to pewnego rodzaju rozszerzenie idei

Service Independent Block z IN10. Ponadto środowisko Java oraz zastosowana koncepcja

kontenera sprawia, Ŝe aplikacje wykazują pełną przenośność pomiędzy róŜnymi

implementacjami JSLEE11. Te dwa główne aspekty pozwalają urzeczywistnić głoszone

slogany marketingowe, takie jak optymalizacja „time-to-market” oraz usługa typu „off-the-

shelf”.

Podsumowując dokonania w dziedzinie telekomunikacji moŜna stwierdzić, Ŝe na dzień

dzisiejszy dysponujemy zestandaryzowanym pełnym modelem wykonywania i tworzenia

usług konwergentnych. W skład tego modelu wchodzi architektura IMS12, środowisko

wykonywania aplikacji JSLEE, narzędzia wspomagające tworzenie aplikacji tzw. IDE13 oraz

interfejs Parlay X eksponujący funkcje sieci na wysokim poziomie abstrakcji.

W niniejszej pracy zostało stworzone rzeczywiste środowisko składające się z wyŜej

wymienionych elementów. Doświadczenia związane z implementacją tego środowiska oraz

przykładowej usługi „Centrum Komunikacji Osobistej” stanowiły podstawę do szczegółowej

analizy moŜliwości i cech przyjętego modelu.

8 Wymagającej dostępu do sieci na niŜszym poziomie abstrakcji. 9 Analogicznie jak J2EE w rozwiązaniach IT. 10 JSLEE zostały zdefiniowane jedynie reguły, według których SBB mają być tworzone, dlatego teŜ zbiór SBB nie jest z góry narzucony. 11 Okazało się to niemoŜliwe w przypadku IN. 12 Implementacje pełnej architektury IMS w komercyjnych sieciach są bardzo nieliczne. 13 Integrated Development Environment.

Wstęp

12

Cele Pracy

� Analiza modelu sterowania usługami zaproponowanego w IMS. Określenie jak

mechanizmy protokołu SIP są wykorzystywane do budowy modelu usługowego,

jakie są korzyści i negatywne strony związane z jego zastosowaniem oraz jakie są

moŜliwości optymalizacji.

� Analiza dekompozycji warstwy aplikacyjnej IMS jako sposobu na optymalizacje

procesu tworzenia usług. Określenie jak wygląda model implementacji usług w

środowisku dwuwarstwowym (warstwa komponentów aplikacyjnych i warstwa

aplikacji) na przykładzie Parlay X i JSLEE. Jakie są korzyści i jakie ograniczenia

przy takim podejściu.

� Analiza implementacji usług w róŜnych modelach programistycznych. Określenie

jak róŜne modele programistyczne wpływają na proces tworzenia.

� Analiza moŜliwości wykorzystania rozwiązań „ open-source” w telekomunikacji.

Ocena jak oprogramowanie typu „open source” wpływa na rozwój współczesnej

telekomunikacji, jakie są kierunki zmian i potencjalne korzyści.

Układ pracy

Praca jest podzielona na dwie części. Pierwsza z nich obejmuje ogólną charakterystykę

wszystkich obszarów, które zostały poddane analizie tj. architektura IMS, protokół SIP,

koncepcja Parlay i Parlay X oraz architektura JAIN SLEE, która została omówiona bardziej

szczegółowo ze względu na niewielką liczbę, obecnie dostępnych opracowań tego

rozwiązania. Druga część jest poświęcona analizie realizacji usług w architekturze IMS.

Zawiera ona opis zaimplementowanego, środowiska modelującego system IMS, które było

podstawą do analizy zagadnień poruszanych w tej pracy.

Poszczególne rozdziały zostały opracowane przez dwóch autorów. Podział przedstawia się

następująco:

1. Wstęp Michał Misiak Część I 2. Session Initiation Protocol Michał Kościesza 3. IP Multimedia Subsystem Michał Kościesza 4. Parlay/OSA oraz Parlay X Michał Misiak 5. JAIN Service Logic Execution Environment Michał Misiak 6. Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych

6.1 Wstęp Michał Misiak

Wstęp

13

6.2 Linux w zastosowaniach telekomunikacyjnych Michał Misiak 6.3 Open Source JSLEE – Mobicents Michał Misiak 6.4 Open SIP Express Router Michał Kościesza 6.5 Asterisk Michał Misiak 6.6 Open IMS Core Michał Kościesza

Część II 7. Specyfikacja problemu i cele analizy Michał Kościesza 8. Architektura środowiska badawczego Michał Kościesza 9. Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem

Michał Kościesza

10. Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

10.1 Sterowanie zestawianiem połączeń przez trzecią stronę (interfejs Third Party Call)

Michał Misiak

10.2 Obsługa połączeń (interfejs Call Handling) Michał Misiak 10.3 Informacja o statusie terminala (interfejs Terminal Status) Michał Misiak 10.4 Zarządzanie listą kontaktów (interfejs Address List Management)

Michał Kościesza

10.5 Informacja o statusie obecności (interfejs Presence) Michał Kościesza 11. Centrum Komunikacji Osobistej Michał Misiak 12. Podsumowanie Michał Kościesza

Michał Misiak

Podział związany z implementacją elementów środowiska badawczego:

Model sterowania usługami IMS (P-CSCF, S-CSCF, HSS) Michał Kościesza Serwery implementujące interfejsy Pralay X:

Third Party Call Michał Misiak Call Handling Michał Misiak Terminal Status Michał Misiak Address List Management Michał Kościesza Presence Michał Kościesza

Aplikacja „Centrum Komunikacji Osobistej” Michał Misiak

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/odpowiedź”. KaŜda

transakcja składa się z Ŝądania, które jest wywołaniem określonej metody na serwerze oraz z

przynajmniej jednej odpowiedzi. Wiadomości protokołu moŜna podzielić na Ŝądania i

odpowiedzi. Podstawowymi rodzajami Ŝądań są:

� INVITE – jest to pierwsza wiadomość rozpoczynająca proces inicjacji sesji.

� ACK – wysyłana jest w celu potwierdzenia zgody na przyjęcie sesji od wywoływanej

strony.

� BYE – powoduje zakończenie trwającej sesji.

14 sesja multimedialna moŜe być przekazem wideo, audio, komunikatów tekstowych itd.. 15 moŜliwość określenia adresu sieciowego terminala uŜytkownika.

Session Initiation Protocol

16

� CANCEL – kończy proces nawiązywania sesji.

� OPTIONS – umoŜliwia poznanie obsługiwanych mechanizmów terminala, do której jest

adresowana.

� REGISTER – umoŜliwia rejestrację lokalizacji sieciowej terminala uŜytkownika16.

Odpowiedzi moŜna pogrupować na serie określające klasę przenoszonych informacji

(podobnie jak w HTTP):

� 1xx (np. „180 Ringing”) – odpowiedzi informacyjne (wskazują na postęp w realizacji

zgłoszenia).

� 2xx (np. „200 OK”) – pozytywne potwierdzenia (wskazują na pomyślne zakończenie

transakcji).

� 3xx (np. „302 Moved Temporarily”) – przekierowania (wskazują na potrzebę

wykonania innych akcji w celu dokończenia realizacji zgłoszenia)

� 4xx (np. „404 Not Fund”) – błędy strony klienckiej (np. wiadomość jest niepoprawna,

albo niemoŜliwa do obsługi przez serwer)

� 5xx (np. „501 Not Implemented”) – błędy serwera

� 6xx (np. „604 Does Not Exist Anywhere”) – błędy ogólnego typu

Rys. 1 przedstawia przykład wiadomości SIP (Ŝądanie). Wiadomość złoŜona jest z tzw.

„pierwszej linii” określającej rodzaj i adres systemu, do którego jest kierowane zgłoszenie

(tzw. Request-URI albo R-URI) oraz z nagłówków określających róŜne parametry zgłoszenia.

Przykładowo nagłówki ‘Via’ wskazują na drogę w sieci tj., przez jakie elementy była

obsługiwana wiadomość, nagłówek ‘From’ określa, kto jest nadawcą a ‘Allow’ wskazuje,

jakie rodzaje wiadomości są obsługiwane przez inicjatora zgłoszenia.

16 Lokalizacja sieciowa to skojarzenie pomiędzy adresem IP a publicznym identyfikatorem uŜytkownika (np. sip:[email protected])

Session Initiation Protocol

17

Rys. 1: Przykładowa wiadomość INVITE protokołu SIP

Na Rys. 2 przedstawiono przykładowy scenariusz nawiązania sesji oraz jej zakończenia.

Rys. 2: Nawiązywanie i rozłączanie sesji

W architekturze protokołu moŜna wyróŜnić elementy pełniące określone funkcje, które

są realizowane przez systemy uczestniczące w procedurach wykorzystujących SIP. Te funkcje

to:

� Funkcja agenta uŜytkownika (User Agent, UA) – polega na moŜliwości inicjowania i

odbierania sesji. Zazwyczaj implementowana jest w terminalach uŜytkownika.

� Funkcja serwera pośredniczącego (Proxy) – polega na odbieraniu i podejmowaniu

decyzji związanych z właściwym kierowaniem wiadomości do agentów uŜytkownika

bądź innych serwerów Proxy.

� Funkcja serwera rejestru (Registrar) – polega na gromadzeniu i udostępnianiu

informacji o lokalizacji sieciowej tj. skojarzenia pomiędzy identyfikatorem

Session Initiation Protocol

18

uŜytkownika Sip-URI (np. sip:[email protected]) a adresem sieciowym terminala

danego uŜytkownika.

� Funkcja B2BUA (Back-To-Back User Agent) – jest to połączenie funkcji agenta

uŜytkownika z funkcją serwera pośredniczącego. Wiadomości, w których wymianie

pośredniczy serwer implementujący funkcje B2BUA, są widziane dla elementów

sieci SIP, tak jakby były zainicjowane właśnie z serwera B2BUA, a nie z

faktycznego agenta uŜytkownika, który jest inicjatorem sesji17.

System serwerów Proxy, Registrar i agentów uŜytkownika (UA) tworzy model sesji, który

jest określany jako „trapez SIP” (Rys. 3).

SIP

Rys. 3: Model sesji opartej o SIP ("trapez SIP")

UA nawiązują połączenie wykorzystując serwery Proxy, które dysponują informacją o

adresacji terminali (funkcja lokalizacji). Po nawiązaniu połączenia dalsza wymiana

wiadomości moŜe następować z pominięciem serwerów Proxy, poniewaŜ UA znają juŜ

nawzajem swoje adresy IP.

Uzgadnianie parametrów połączenia pomiędzy stronami odbywa się przy pomocy

protokołu SDP, który jest przenoszony wewnątrz wiadomości SIP. Ten mechanizm jest oparty

o model negocjacji zdefiniowany w [23].

Szczegółowa analiza mechanizmów protokołu SIP jest zawarta w [12].

17 Ten mechanizm jest zbliŜony do NAT w sieci TCP/IP, tylko jest przeprowadzany na warstwie protokołu SIP.

Session Initiation Protocol

19

2.3 Kierunki rozwoju i rola SIP w IMS

Protokół SIP zdefiniowany w [22] słuŜy do nawiązywania sesji multimedialnych w sieci

IP. Cechuje się on przejrzystością składni (jest tekstowy i przypomina HTTP) i stosunkowo

prostą budową (sześć podstawowych wiadomości: INVITE, ACK, CANCEL, BYE,

REGISTER, OPTIONS). Te cechy wpłynęły na to, Ŝe SIP jest najczęściej wybieranym

protokołem w implementowaniu systemów komunikacji multimedialnej w sieci Internet.

Warto zauwaŜyć, Ŝe właśnie zastosowanie SIP w Internecie jest wyróŜnione w specyfikacji

definiującej protokół.

Dzięki modularnej budowie i wbudowanych mechanizmach pozwalających na

rozszerzanie funkcji, powstało wiele inicjatyw, których celem było „wzbogacenie” bazowego

SIP o nowe mechanizmy na przykład takie jak realizacja usługi natychmiastowych

wiadomości (z ang. Instant Messaging, IM) albo publikacji statusu obecności uŜytkownika (z

ang. Instant Presence). Do maja 2007 roku opublikowano około 50 róŜnego rodzaju

rozszerzeń SIP względem bazowej normy, które otrzymały status norm IETF RFC18.

SIP został wybrany jako podstawowy protokół sterowania połączeniami i zgłoszeniami

w systemie IMS (opis w rozdziale 3.) dla sieci UMTS. Prace ETSI [17] i ITU [35]

wykorzystują IMS jako rdzeniową część w nowym modelu sieci telekomunikacyjnej - NGN.

W związku z tym, SIP został protokołem słuŜącym do sterowania połączeniami i

zgłoszeniami w projektowanej publicznej sieci telekomunikacyjnej następnej generacji. Do

zastosowań telekomunikacyjnych definicja protokołu zawarta w RFC 3261 nie jest

wystarczająca. Przykładowo brakuje w niej mechanizmów umoŜliwiających interakcje z

sieciami PSTN bez utraty określonych informacji o realizowanym połączeniu, mechanizmów

pozwalających na kontrolę przez operatora negocjowanych parametrów połączenia

potrzebnych do QoS oraz funkcji związanych z taryfikacją. Ze względu na to, standardy

3GPP wprowadzają szereg rozszerzeń i definiują, na potrzeby IMS, tzw. profil protokołu SIP

[7], który jest złoŜony z bazowego standardu [22] oraz listy rozszerzeń. Tak określony profil

stanowi minimalny zestaw mechanizmów, jakie są wymagane w odniesieniu do wszystkich

uczestników (terminali, elementów sieci) pracujących w środowisku systemu IMS.

Wymagane rozszerzenia SIP wprowadzone w IMS to:

18 Dane na podstawie IETF WG-SIP (http://www.ietf.org/html.charters/sip-charter.html).

Session Initiation Protocol

20

� Tel-URI (RFC 3966) – określa specjalny format adresu uŜywany w SIP dla

identyfikacji uŜytkowników sieci PSTN.

� wiadomość INFO (RFC 2976) – umoŜliwia przenoszenie sygnalizacji DTMF.

� wiadomość ‘183 Session Progress’ i PRACK (RFC 3262) – umoŜliwiają bardziej

szczegółową wymianę informacji dotyczącą procesu zestawiania sesji, co jest

wymagane w celu zachowania kompatybilności z siecią PSTN (współpraca SIP-

ISUP).

� rekordy NAPTR w systemie DNS dla protokołu SIP (RFC 3263) - system DNS jest

wykorzystywany do lokalizacji serwerów Proxy.

� wiadomości SUBSCRIBE i NOTIFY (RFC 3265) – wprowadzają mechanizm

umoŜliwiający elementom sieci SIP śledzenie roŜnego typu zdarzeń. Jest to

wykorzystywane między innymi w realizacji usługi obecności, w której terminal

subskrybuje status obecności innego uŜytkownika.

� wiadomość UPDATE (RFC 3311) – rolą tej wiadomości jest umoŜliwienie zmiany

wynegocjowanych parametrów połączenia przed faktycznym rozpoczęciem się sesji.

Bez wiadomości UPDATE zmiany takiego typu mogą odbywać się tylko po

rozpoczęciu sesji (poprzez mechanizm re-INVITE [22]).

� nagłówek P-Media-Authorization (RFC 3313) – przenosi informacje dotyczącą

uwierzytelnionych parametrów połączenia. Jest to potrzebne w realizacji przez sieć

mechanizmów związanych z QoS. W IMS, kaŜda sesja jest kontrolowana przez

element P-CSCF, którego zadaniem jest sprawdzanie czy negocjowane przez

uŜytkowników parametry połączenia (w tym parametry QoS) są moŜliwe do

zagwarantowania.

� kompresja SIP (RFC 3320) – w celu optymalizacji wykorzystania zasobów na łączu

radiowym w IMS stosuje się kompresję.

� nagłówek Privacy (RFC 3323) – umoŜliwia określanie poziomów prywatności dla

sesji. Ma to wpływ między innymi na taki aspekt jak prezentacja numeru.

� nagłówki P-Asserted-Identity i P-Preferred-Identity (RFC 3325) – te dodatkowe

nagłówki przenoszą informacje dotyczącą strony inicjującej połączenie. Zgodnie [22]

taka informacja zawarta jest w nagłówku From, ale ze względu na wymogi związane

z taryfikacją (From jest formowane przez terminal uŜytkownika) w IMS stosuje się

Session Initiation Protocol

21

dodatkową informację, która jest wstawiana do wiadomości przez elementy systemu

IMS.

� nagłówek Reason (RFC 3326) – przenosi dodatkowe informacje dotyczące przyczyny

określonych zdarzeń w sieci. Wymagany jest w celu zachowania kompatybilności

IMS z siecią PSTN.

� nagłówek Path (RFC 3327) – umoŜliwia kierowanie wiadomości do uŜytkownika w

sytuacji, w której pomiędzy serwerem rejestrującym (Registrar), a terminalem

uŜytkownika jest serwer Proxy.

� nagłówki “P-Headers” (RFC 3455) – są to dodatkowe nagłówki takie jak: P-

Associated-URI, P-Called-Party-ID, P-Visited-Network-ID, P-Access-Network-Info,

P-Charging-Function-Addresses, P-Charging-Vector. Przenoszą informacje

związane z siecią dostępową i informacje potrzebne do taryfikacji.

� wiadomość REFER (RFC 3515) – wspomaga realizacje takich usług jak przekazanie

połączenia (call transfer) i konferencja.

� nagłówek Service Route (RFC 3608) – umoŜliwia poprawne kierowanie wiadomości

pomiędzy serwerami IMS a terminalami uŜytkowników.

� subskrypcja stanu rejestracji (RFC 3680) – umoŜliwia terminalowi uŜytkownika

pobieranie informacji o stanie rejestracji róŜnych identyfikatorów Sip-URI, którymi

dysponuje. Odbywa się to za pomocą wiadomości SUBSCRIBE i NOTIFY.

Większość powyŜej opisanych rozszerzeń powstała w wyniku prac 3GPP i ma

praktyczne zastosowanie jedynie w systemie IMS. Niektóre dodane mechanizmy mają

charakter bardzo szczegółowy i są wynikiem dostosowania protokołu SIP, który pierwotnie

był projektowany dla sieci Internet, do wymogów stawianych sieci telekomunikacyjnej.

Session Initiation Protocol

22

A

INVITE

200 OK

ACK

B

180 Ringing

transmisja mediów

180 Trying

A

INVITE

200 OK

ACK

B

180 Ringing

transmisja mediów

180 Trying

183 Session Progress

PRACK

200 OK

UPDATE

200 OK

PRACK

200 OK

SIP zgodny z RFC 3261 SIP zgodny z IMS

Rys. 4: Scenariusze nawiązania sesji: SIP podstawowy i SIP IMS19 (na podstawie [6])

Jedną z podkreślanych cech protokołu SIP jest jego prostota20. Aby umoŜliwi ć

świadczenie usług telekomunikacyjnych, 3GPP wprowadziło szereg rozszerzeń, które

mają zastosowanie w systemie IMS. SIP zgodny z IMS cechuje się dwukrotnie większą

ilością wiadomości, kilkunastoma dodatkowymi nagłówkami i specyficznymi, względem

standardu pierwotnego, mechanizmami. Rys. 4 przedstawia scenariusz nawiązania sesji

wykorzystujący podstawową wersję protokołu SIP oraz wersję zgodną z IMS. Aby

nawiązać połączenie VoIP w sieci Internet (SIP zgodny z RFC 3261) wystarczy wymiana

5 wiadomości sygnalizacyjnych, a w IMS niezbędne jest uŜycie 12 wiadomości.

19 Serwery pośredniczące zostały pominięte. 20 SIP rozumiany jako protokół zdefiniowany w RFC 3261, bez rozszerzeń.

3. IP Multimedia Subsystem

3.1 Wstęp

IP Multimedia Subsystem (IMS) po raz pierwszy pojawia się w piątej wersji norm

3GPP definiujących UMTS (3GPP UMTS Release 5) [3], gdzie stanowi dodatkowy

komponent (podsystem) w architekturze sieci. Główną jego funkcja jest prawie wyłącznie

realizacja dodatkowych usług multimedialnych w dziedzinie pakietowej (np. Video-sharing,

Push-To-Talk21). Wraz z rozwojem koncepcji Sieci Następnej Generacji (Next Generation

Network, NGN), IMS staje się (3GPP Release 6) kluczowym systemem rdzeniowej części

UMTS, realizującym zarówno klasyczne usługi telefoniczne jak i nowe, tzw. usługi

konwergentne, które łączą moŜliwości sieci pakietowych i sieci z komutacją łączy. IMS

umoŜliwia tworzenie róŜnorodnych usług wykorzystujących: multimedia (w tym tradycyjne

połączenie głosowe), transmisje danych oraz szeroko rozumiany kontekst komunikacji.

Wszystkie te składowe mogą się wzajemnie „przenikać” w budowanych scenariuszach

usługowych.

Aktualne prace standaryzacyjne nad 3GPP Release 7 i 8 są wykorzystywane przez ETSI

i ITU do stworzenia architektury sieci NGN, czyli sieci pakietowej, zdolnej do świadczenia

usług telekomunikacyjnych, która jest niezaleŜna od rodzaju techniki dostępowej [33]. ETSI

rozszerza funkcje IMS o konwergencje z sieciami stacjonarnymi i w ten sposób IMS staje się

systemem, który stanowi rdzeń w nowej uniwersalnej, publicznej sieci telekomunikacyjnej.

Integrująca i unifikująca rola IMS jest wielopłaszczyznowa, dotyka warstwy

dostępowej, sterowania połączeniami i warstwy aplikacyjnej, czyli miejsca realizacji usług.

Usługi o wartości dodanej22 są postrzegane jako waŜny wyróŜnik atrakcyjności sieci

telekomunikacyjnej, aby sprostać temu wymaganiu, niezbędna jest zmiana paradygmatu

wprowadzania nowych aplikacji. IMS zawiera w sobie mechanizmy, których celem jest

umoŜliwienie budowy aplikacji o bogatej funkcjonalności oraz optymalizacja tego procesu

zarówno pod względem kosztowym jak i czasowym.

21 Usługa „Push-to-Talk” zdefiniowana jest w ‘OMA, Push to talk Over Cellular v1.0’ (http://www.openmobilealliance.org/) 22 Usługi o wartości dodanej są to usługi, których funkcje wykraczają poza podstawową funkcje sieci, jaką jest zestawienie połączenia pomiędzy dwoma uŜytkownikami.

IP Multimedia Subsystem

24

3.2 IMS jako rdzeniowa część architektury NGN

Terminem „Sieć Następnej Generacji” określa się architekturę sieci opartą o komutacje

pakietów, zdolną do realizacji usług telekomunikacyjnych wykorzystujących róŜne

przepływności dostarczane przez róŜne techniki dostępowe. Zgodnie z [33] najwaŜniejszymi

cechami sieci w architekturze NGN są:

� komutacja pakietów;

� separacja funkcji sterowania połączeniami i zgłoszeniami od funkcji transportowych i

funkcji związanych z usługami;

� otwarte interfejsy;

� zdolność do realizacji szerokiego zakresu usług;

� szerokopasmowa transmisja z zaimplementowanymi mechanizmami QoS;

� współpraca z sieciami tradycyjnymi (z siecią PSTN);

� konwergencja pomiędzy usługami sieci stacjonarnej i mobilnej;

� niezaleŜność usług od technik dostępowych;

� otwartość dla róŜnych technik realizacji dostępu.

Rys. 5: Referencyjna funkcjonalna architektura NGN (źródło [17])

Zgodnie z referencyjną funkcjonalną architekturą ETSI (patrz Rys. 5) sieć NGN moŜna

podzielić na:

IP Multimedia Subsystem

25

� warstwę funkcji transportowych (Transfer Functions) – grupuje wszystkie

mechanizmy odpowiedzialne za udostępnienie łącza danych, które często nazywane

jest określeniem IP-CAN (IP Connectivity Access Network). Realizacja łącza IP moŜe

odbywać się za pomocą dowolnych technik dostępowych.

� podsystem sterowania zasobami i dostępem (Resorce and Admission Control

Subsystem, RACS) – steruje przyznawaniem zasobów dla konkretnego ruchu

generowanego przez uŜytkownika. Systemy z wyŜszych warstw (np. Core-IMS)

instruują ten podsystem do stosowania odpowiednich polityk kontroli dostępu i QoS.

� podsystem powiązania sieciowego (Network Attachment Subsystem, NAS) – jego

głównym zadaniem jest uwierzytelnienie uŜytkownika w warstwie transportowej (np.

PPP) oraz przyznanie adresacji IP.

� podsystem emulacji PSTN/ISDN (PSTN/ISDN Emulation subsystem) – pozwala na

obsługę sieci dostępowych opartych o komutacje łączy. Głównym zadaniem tego

podsystemu jest emulacja PSTN/ISDN w sieci pakietowej.

� podsystem IMS (Core IMS23) – jest odpowiedzialny za sterowanie połączeniami i

zgłoszeniami.

� warstwę aplikacji (Applications) – zawiera funkcje realizujące usługi.

Sieć UMTS24 jest zgodna z modelem NGN ogólnie zdefiniowanym w [17] i [33]. Rys. 6

pokazuje architekturę UMTS, która jest połączeniem tradycyjnej sieci z komutacją łączy oraz

sieci pakietowej. Część pakietowa UMTS razem z podsystemem IMS tworzy pełną sieć w

modelu NGN.

23 W architekturze ETSI-NGN podsystem IMS nosi nazwę „Core IMS”. Jest spowodowane tym, Ŝe zgodnie z definicją 3GPP, IMS zawiera elementy realizujące sterowanie połączeniami i zgłoszeniami oraz warstwę serwerów aplikacyjnych, a definicja ETSI zawęŜa rolę IMS tylko do sterowania połączeniami i zgłoszeniami. 24 Dokładnie sieć UMTS w architekturze, co najmniej 3GPP Release 5.

IP Multimedia Subsystem

26

Rys. 6: Dualna architektura sieci UMTS (źródło [3])

Jedną z waŜnych cech IMS, która zadecydowała o wykorzystaniu go w NGN, jest

niezaleŜność warstwy usługowej od techniki dostępowej. KaŜdy terminal, który jest zdolny do

nawiązania łączności IP z elementami IMS, moŜe korzystać z funkcji usługowych sieci

telekomunikacyjnej, poniewaŜ wszystkie mechanizmy niezbędne do obsługi zgłoszeń są

niezaleŜne od technik dostępowych. Przykładem tej neutralności dostępowej jest identyfikacja

uŜytkownika, która w IMS odbywa się przy pomocy adresacji protokołu SIP, tzw. SIP-uri,

który jest niezaleŜny od adresacji IP przyznawanej w podsystemach NAS, specyficznych dla

danej sieci dostępowej. Podobnie jest w przypadku procedury uwierzytelnienia uŜytkownika,

która moŜe być przeprowadzana w kaŜdej sieci dostępowej w specyficzny sposób, ale zawsze

terminal uŜytkownika po uzyskaniu łączności IP z IMS jest poddawany powtórnemu

uwierzytelnieniu poprzez protokół SIP.

IP Multimedia Subsystem

27

Rys. 7: Model uniwersalnej sieci NGN

Rys. 7 pokazuje model sieci NGN, w której IMS jest niezaleŜny od róŜnych technik

dostępowych.

3.3 Architektura IMS

IMS jest rdzeniowym elementem sieci NGN realizującym funkcje zwiane ze

sterowaniem połączeniami i zgłoszeniami. W tym rozdziale zostanie omówiona architektura

IMS zgodna ze specyfikacjami 3GPP25, które określają funkcje IMS szerzej tj. oprócz funkcji

sterowania połączeniami i zgłoszeniami, wyróŜniają takŜe funkcje związane z aplikacjami

realizującymi usługi i funkcje bram medialnych.

25 Dokładnie z wersją 6 tj. 3GPP Release 6.

IP Multimedia Subsystem

28

Rys. 8: Architektura IMS

Elementy funkcjonalne systemu IMS oraz protokoły stosowane na interfejsach są

pokazane na Rys. 8. Jak moŜna zauwaŜyć, wykorzystywane są cztery protokoły

sygnalizacyjne: SIP do sterowania połączeniami i zgłoszeniami, H.248/MEGACO jako

protokół słuŜący do sterowania bramami medialnymi, DIAMETER wykorzystywany do

autoryzacji zgłoszeń oraz parametrów QoS oraz SCTP, który stanowi protokół transportowy

do wyŜszych warstw stosu SS7 po sieci IP.

W architekturze funkcjonalnej IMS (Rys. 8) moŜna wyróŜnić 3 warstwy:

� warstwa urządzeń końcowych i bram – obejmuje elementy odpowiedzialne za

obsługę ruchu uŜytkowego. NaleŜą do niej takie elementy jak: bramy medialne (IM-

MGW), serwery zajmujące się generowaniem treści (MRFP) oraz urządzenia

końcowe odpowiedzialne za odbiór i nadawanie ruchu uŜytkowego.

� warstwa sterowania połączeniami i zgłoszeniami – obejmuje wszystkie elementy

odpowiedzialne za sterowanie połączeniami i zgłoszeniami. NaleŜą do niej elementy

takie jak: S-CSCF, I-CSCF, P-CSCF, HSS, SLF, BGCF, MGCF, MRFC, PDF,

SGW.

IP Multimedia Subsystem

29

� warstwa aplikacyjna – jest złoŜona z serwerów aplikacyjnych (AS) realizujących

scenariusze usług

Element funkcjonalne architektury IMS to:

� Serving-Call/Session Control Function (S-CSCF)

Jest właściwym elementem systemu IMS odpowiedzialny za odpowiednie kierowanie

zgłoszeń (w postaci wiadomości SIP). NajwaŜniejsze funkcje S-CSCF to: sterowanie

sesją multimedialną, uwierzytelnienie uŜytkownika i sterowanie połączeniami.

Dla kaŜdego zgłoszenia analizowanego w S-CSCF wybierany jest właściwy sposób

obsługi tj:

a. zgłoszenie moŜe być skierowane do terminala innego uŜytkownika;

b. zgłoszenie moŜe być skierowane do serwera I-CSCF jeśli odbiorca jest

obsługiwany w obcej sieci;

c. zgłoszenie moŜe być skierowane do serwera aplikacyjnego jeśli profil

uŜytkownika wskazuje na potrzebę realizacji usług.

Rys. 9 pokazuje przykładowy scenariusz obsługi w S-CSCF. Na podstawie

profilu uŜytkownika A, zgłoszenie zostaje skierowane do serwera aplikacyjnego (AS1)

a następnie do innego (AS2). Po zakończeniu obsługi związanej z usługami,

zgłoszenie jest kierowane do uŜytkownika B.

2. INVITE B

3. IN

VITE B

4. INVITE B

5. IN

VITE B

Rys. 9: Analiza profilu w S-CSCF

Z punktu widzenia modelu protokołu SIP, S-CSCF pełni funkcję serwera SIP-proxy i

serwera Registrar.

IP Multimedia Subsystem

30

� Home Subscriber Server (HSS)

Element HSS pełni funkcję uniwersalnego repozytorium danych skojarzonych z

uŜytkownikiem. Dane te są to zarówno informacje potrzebne do spersonalizowanej

realizacji usług w serwerach aplikacyjnych, jak i informacje niezbędne do realizacji

podstawowych funkcji związanych ze sterowaniem połączeniami i zgłoszeniami bądź

zarządzaniem mobilnością. HSS uczestniczy takŜe w procedurach uwierzytelnienia

uŜytkownika (udostępnia wektory kryptograficzne) oraz przechowuje reguły obsługi

zgłoszeń w określonych serwerach aplikacyjnych (tzw. reguły filtracji IFC).

Wx

Applications

D C Gr Gc Sh Rp Cx Si

gsmSCF

HSS

Mobility Management Identification handling

User security info. generation Service authorization support

User security support Access authorization

Service Provisioning support Application Services Support

Call / Session establishment support CAMEL Services Support

GUP Data Repository

CS Domain PS Domain IM CN subsystem

GUP Server

SGSN GGSN GMSC MSC / VLR CSCF IM-SSF

SIP Application Server

OSA SCS

3GPP AAA Server

Rys. 10: Logiczna architektura HSS (źródło [3])

HSS jest uniwersalnym repozytorium, oznacza to, Ŝe gromadzi dane wykorzystywane

przez wszystkie elementy sieci komórkowej (nie tylko IMS). Rys. 10 pokazuje

wszystkie logiczne funkcje i interfejsy HSS.

� Subscriber Location Function (SLF)

Rola SLF w sieci IMS polega na informowaniu, w którym HSS znajduje się profil

uŜytkownika. Funkcja SLF jest implementowana w sytuacji, kiedy w sieci znajduję się

kilka serwerów HSS.

� Proxy-Call/Session Control Function (P-CSCF)

Jest to serwer SIP-proxy, który pośredniczy pomiędzy terminalem uŜytkownika a S-

CSCF. Jego główną funkcją jest kontrola dostępu, kontrola sesji w kontekście

parametrów QoS oraz kompresja/dekompresja protokołu SIP.

IP Multimedia Subsystem

31

Rys. 11: Rola P-CSCF

Rys. 11 pokazuje rolę P-CSCF we współpracy z PDF i GGSN. Wiadomości

inicjujące sesje są analizowane w P-CSCF i na ich podstawie P-CSCF razem z PDF

„otwiera” moŜliwość transmisji ruchu uŜytkowego w GGSN oraz rezerwuje niezbędne

zasoby zgodnie z profilem QoS26.

� Policy Decision Function (PDF)

Funkcja ta jest opowiedzialna za zcentralizowaną kontrolę wykorzystania i rezerwacji

zasobów transmisyjnych. PDF otrzymuje od P-CSCF Ŝądane przez uŜytkowników

parametry QoS dla danej sesji na podstawie, których podejmuje decyzje o zezwoleniu

na połączenie. Funkcje PDF jest szczegółowo opisane w specyfikacji 3GPP TS 29.207

(Policy control over Go interface).

� Interrogating-Call/Session Control Function (I-CSCF)

Pośredniczy w wymianie sygnalizacji (SIP) pomiędzy S-CSCF, a innymi sieciami

(implementuje funkcje ukrywania topologii sieci). I-CSCF uczestniczy takŜe w

procedurze rejestracji uŜytkownika, co jest szczegółowo opisane w rozdziale 9.3. Z

punktu widzenia modelu protokołu SIP, I-CSCF jest serwerem SIP-proxy oraz

implementuje funkcje B2BUA.

� Breakout Gateway Control Function (BGCF)

26 Sposób definicji Ŝądanych parametrów QoS za pomocą protokołu SIP/SDP definiuje RFC3312.

IP Multimedia Subsystem

32

Bierze udział w zestawianiu połączenia, które ma się zakończyć w sieci PSTN.

Główną funkcją BGCF jest określenie odpowiedniego serwera MGCF (w przypadku,

gdy w sieci jest wiele serwerów MGCF) i przekazanie do niego zgłoszenia.

� Media Gateway Control Function, Media Gateway (MGCF, IM-MGW)

Brama medialna i kontroler bramy medialnej łączą sieć IMS z siecią PSTN. MGCF

odpowiedzialny jest za konwersje sygnalizacji pomiędzy SIP a ISUP (albo Q.931 w

przypadku ISDN) oraz odpowiednie wysterowanie MGW, który odpowiedzialny jest

za konwersję ruchu uŜytkowego pomiędzy łączami komutowanymi a strumieniami

RTP27.

� Signalling Gateway (SGW)

Odpowiedzialny jest za przeniesienie protokołów wyŜszych warstw SS7 (np. ISUP) do

sieci IP za pomocą protokołu SCTP28.

� Multimedia Resource Function Controller, Multimedia Resource Function

Processor (MRFC, MRFC)

MRFC i MRFP są elementami realizującymi funkcje tzw. serwera mediów. Główną

ich rolą jest udostępnianie i przetwarzanie treści multimedialnych. MRFC odpowiada

za sygnalizacje, a MRFP za ruch uŜytkowy (strumienie medialne)29. Przykładem

wykorzystania tych elementów moŜe być implementacja mostka konferencyjnego,

albo serwera poczty głosowej.

� Application Server (AS)

Serwer aplikacyjny jest miejscem implementacji usług w sieci IMS. AS uczestniczy w

realizacji połączeń w na kilka sposobów, tj. moŜe:

a. odbierać i przetwarzać zgłoszenia (sekwencje wiadomości protokołu SIP) z S-

CSCF, które wymagają obsługi związanej z usługami (rola 3 z Rys. 12);

b. przyjmować połączenia (rola 1 z Rys. 12);

c. inicjować połączenia (rola 2 z Rys. 12);

27 RTP jest protokołem transportowym strumieni medialnych w sieci IP (RFC 3550). 28 Protokół SCTP zdefiniowany jest w RFC 2960. 29 MRFC i MRFP są jednymi z najmniej dokładnie zdefiniowanymi elementami IMS.

IP Multimedia Subsystem

33

d. realizować zestawienie połączenia w modelu trzeciej strony tzw. 3rd-Party-

Call-Control (rola 4 z Rys. 12).

S-CSCF

ApplicationServer

SIP leg #1

SIP leg #1

From: XTo: YCall-ID: Z

From: XTo: YCall-ID: Z

S-CSCF

ApplicationServer

SIP leg #1

SIP leg #1

From: XTo: YCall-ID: Z

From: XTo: YCall-ID: Z

S-CSCF

ApplicationServer

SIP leg #1

SIP leg #1

From: XTo: YCall-ID: Z

From: XTo: YCall-ID: Z

SIP leg #1From: XTo: YCall-ID: Z

SIP leg #1

From: XTo: YCall-ID: Z

S-CSCF

ApplicationServer

SIP leg #2

SIP leg #2

From: PTo: QCall-ID: R

From: PTo: QCall-ID: R

SIP leg #1From: XTo: YCall-ID: Z

SIP leg #1

From: XTo: YCall-ID: Z

Rys. 12: Role jakie moŜe przyjmować serwer aplikacyjny w obsłudze połączeń (źródło [4])

Z punktu widzenia modelu protokołu SIP, serwer aplikacyjny implementuje funkcje

SIP-proxy, UA oraz B2BUA.

3.4 Profil uŜytkownika

HSS przechowuje i udostępnia profile uŜytkowników, które zawierają dane

wykorzystywane przez elementy IMS do świadczenia usług. Profil moŜe być pobierany z

HSS przez serwery aplikacyjne, które przechowują w nim informacje potrzebne do

personalizacji wykonywanych usług albo przez S-CSCF w celu realizacji procedur

związanych ze sterowaniem usługami. KaŜdy profil składa się z informacji, która opisuje, w

jakich sytuacjach i na jakie serwery aplikacyjne maja być kierowane zgłoszenia trafiające do

S-CSCF. Stanowi to podstawę modelu sterowania usługami opisanego w rozdziale 3.5.

IP Multimedia Subsystem

34

Struktura profilu jest definiowana przy pomocy języka UML30. Rys. 13 przedstawia

budowę profilu abonenta w HSS.

Rys. 13: Struktura profilu w HSS

W skład profilu uŜytkownika wchodzą takie informacje jak:

� ‘Public Identification’ - jest to grupa publicznych identyfikatorów, którymi posługuje

się uŜytkownik. Dany profil jest stosowany tylko, jeśli abonent posługuje się

identyfikatorem wymienionym w tej grupie.

30 Unified Modeling Language (http://www.ogm.org/uml).

IP Multimedia Subsystem

35

� ‘Core Network Service Authorization’ - są to informacje uwierzytelniające.

� ‘Initial Filter Criteria’ - zawiera kryteria filtracji wiadomości na określony serwer

aplikacyjny (szczegółowo jest to omówione poniŜej).

� ‘Shared iFC Set’ - jest to wskazanie na kryteria filtracji współdzielone przez róŜnych

uŜytkowników.

Dla modelu sterowania usługami istotnym elementem profilu są kryteria filtracji (Initial

Filter Criteria, IFC), które są analizowane w S-CSCF, gdy przychodzi wiadomość

sygnalizacyjna SIP. Na podstawie tych danych, zostaje podjęta decyzja czy wiadomość

(zgłoszenie) ma być skierowana na właściwy serwer aplikacyjny. MoŜliwości analizy

wiadomości SIP są bardzo szerokie. Definicja IFC składa się z wyraŜenia przedstawiającego

sumę lub negacje logiczną, warunków dotyczących części składowych wiadomości. Analizie

mogą podlegać wszystkie nagłówki i pole SDP31, do którego takŜe mogą być stosowane

wyraŜenia regularne32 (szerzej jest to omówione w rozdziale 1).

Profil uŜytkownika jest przesyłany w postaci dokumentu XML o określonej składni.

Definicja składni jest specyfikowana przy pomocy specjalnego XML-Schema33. Szczegółowy

opis budowy profilu zawarty jest w [9].

3.5 Model sterowania usługami

W IMS miejsce realizacji usługi o wartości dodanej jest precyzyjnie zdefiniowane i tym

miejscem jest serwer aplikacyjny. Takie rozgraniczenie wprowadza klarowny podział

pomiędzy elementarnymi funkcjami (np. zapewnienie przezroczystego kanału danych,

zarządzanie mobilnością itd.) a cała gamą dodanych funkcjonalności.

Podstawowymi elementami biorącymi udział w sterowaniu usługami IMS są: serwery

aplikacyjne (AS), element zarządzający sterowaniem połączeniami i zgłoszeniami (S-CSCF)

oraz repozytorium profili uŜytkownika (HSS). Rys. 14 przedstawia interfejsy i protokoły

31 Protokół słuŜący do opisu parametrów sesji. 32 MoŜliwości tworzenia kryteriów są elastyczne, przykładowo moŜna zdefiniować taką regułę:

(Method=”INVITE” OR Method = ”MESSAGE” OR Method=”SUBSCRIBE”) AND (Method=”INVITE” OR Method = ”MESSAGE” OR (NOT Header = ”from” Content =”[email protected]”)).

PowyŜsze wyraŜenie opisuje regułę definiującą, Ŝe kierowane do AS będą wiadomości: INVITE, MESSAGE oraz takie wiadomości SUBSCRIBE, które nie zostały wysłane przez uŜytkownika posługującego się publicznym identyfikatorem [email protected]. 33 XML-Schema jest językiem opisu składni dokumentów XML (patrz http://www.w3.org/XML/Schema).

IP Multimedia Subsystem

36

pomiędzy tymi elementami. Interakcja S-CSCF z AS odbywa się za pomocą protokołu SIP,

który zarazem jest podstawowym protokołem słuŜącym do realizacji sterowania zgłoszeniami

w sieci.

Rys. 14: Elementy architektury IMS biorące udział w sterowaniu usługami

Sterowanie usługami polega na odpowiednim przekazywaniu obsługi zgłoszeń do

serwerów aplikacyjnych. KaŜdy uŜytkownik IMS jest obsługiwany przez wyróŜniony serwer

S-CSCF, który podczas procedury rejestracji pobiera profil uŜytkownika z HSS. Profil

zawiera tzw. filtry IFC, które definiują warunki kierowania zgłoszenia do odpowiedniego AS.

Procedury sterowania usługami moŜna podzielić na 3 klasy:

� Procedury związane z obsługą zgłoszeń przychodzących dla zarejestrowanego

uŜytkownika – analizowany jest profil wywoływanego uŜytkownika;

� Procedury związane z obsługą zgłoszeń przychodzących dla nie zarejestrowanego

uŜytkownika – z HSS pobierany jest profil wywoływanego uŜytkownika, który nie

jest w danej chwili zarejestrowany w S-CSCF (jest poza siecią IMS);

� Procedury związane z obsługą zgłoszeń wychodzących – analizowany jest profil

uŜytkownika, który inicjuje zgłoszenie.

Obsługa kaŜdego zgłoszenia związana ze sterowaniem usługami w S-CSCF jest podzielona na

2 fazy:

1. decyzja, do której klasy naleŜy zgłoszenie (przychodzące, przychodzące do

niezarejestrowanego uŜytkownika, wychodzące);

2. analiza filtrów IFC i wybór serwera aplikacyjnego, do którego ma być skierowane

zgłoszenie.

IP Multimedia Subsystem

37

Rys. 15 ilustruje przykładowy scenariusz realizacji zgłoszenia, w którym jest

wykorzystywany mechanizm sterowania usługami.

2. 3. 5.

6.

7.

Rys. 15: Mechanizm sterowania usługami - przykładowy scenariusz

Przebiega on w sposób następujący:

1. UŜytkownik ‘ala’ wywołuje uŜytkownika ‘ula’.

2. Zgłoszenie trafia do S-CSCF, który analizuje profil ‘ala’ (procedura dla połączeń

wychodzących) i zgodnie z nim, wykonuje przekierowanie zgłoszenia do AS1 (który

moŜe przykładowo realizować usługę blokowania połączeń wychodzących gdy

uŜytkownik jest poza określoną lokalizacją).

3. AS1 wykonuje swoja logikę i zwraca obsługę zgłoszenia do S-CSCF.

4. S-CSCF pobiera profil uŜytkownika ‘ula’ (procedura dla połączeń przychodzących do

nie zarejestrowanego uŜytkownika).

5. S-CSCF zgodnie z pobranym profilem kieruje zgłoszenie do AS2. (który przykładowo

realizuje usługę „przekierowania”).

6. AS2 modyfikuje zgłoszenie, zamieniając adres odbiorcy na adres wskazujący na

uŜytkownika ‘ela’. Zgłoszenie kierowane jest do S-CSCF.

7. S-CSCF zgodnie z adresem odbiorcy zgłoszenia, kieruje je do uŜytkownika ‘ela’.

IP Multimedia Subsystem

38

3.6 Proces nawiązywania sesji

Na Rys. 16 przedstawiono dwa scenariusze pokazujące proces nawiązywania sesji, tj.

sesji pomiędzy uŜytkownikami IMS oraz sesji pomiędzy uŜytkownikiem IMS, a

uŜytkownikiem sieci PSTN.

1. 6.

2.

3. 4

.5.

1.

2.

3. 4

.

7.

Rys. 16: Nawiązywanie sesji w IMS

W przypadku scenariusza pierwszego, uŜytkownik inicjuje zgłoszenie, które jest obsługiwane

w S-CSCF (1, 2). Jeśli profil uŜytkownika wymaga obsługi związanej z usługami to

zgłoszenie kierowane jest do odpowiedniego serwera aplikacyjnego (3, 4), a następnie do

wywoływanego uŜytkownika B (5, 6). W przypadku scenariusza, w którym uŜytkownik B jest

obsługiwany przez sieć PSTN, S-CSCF kieruje zgłoszenie do serwera BGCF (5), który

określa właściwy MGCF przyłączony do sieci PSTN (6). MGCF dokonuje translacji

sygnalizacji SIP na ISUP (7) oraz steruje MGW tak, aby strumienie RTP od uŜytkownika A

zostały zamienione na połączenie w sieci z komutacją łączy.

3.7 Kierunki rozwoju

Architektura IMS powstała w wyniku prac 3GPP związanych z rozwojem sieci

mobilnej UMTS, a następnie została zaadaptowana przez ETSI [17] oraz ITU [35] na

potrzeby uniwersalnej architektury sieci NGN. Pewnego rodzaju paradoksem jest to, Ŝe

obecne implementacje IMS w przewaŜającej większości mają miejsce w sieciach

stacjonarnych pomimo, Ŝe IMS pierwotnie został zaprojektowany dla sieci komórkowej.

IP Multimedia Subsystem

39

Główną przyczyną tego są ograniczenia związane z siecią dostępową opartą o IP (IP-CAN).

Operatorzy stacjonarni do budowania rozwiązań, NGN wykorzystują szerokopasmowy dostęp

DSL albo infrastrukturę sieci kablowej (sieć HFC). Te techniki umoŜliwiają osiąganie

przepływności i parametrów jakościowych umoŜliwiających realizacje usług głosowych

(VoIP). W przypadku sieci mobilnych, dostęp realizowany jest przy pomocy sieci radiowej,

która na dzień dzisiejszy w rzeczywistych implementacjach nie umoŜliwia realizacji usług

głosowych opartych o VoIP z wystarczającą jakością34. To ograniczenie jest główną

przyczyną braku implementacji IMS w sieciach mobilnych oraz jest przyczyną prac

związanych z rozwojem IMS, głównie skupionych właśnie na próbie rozwiązania tego

problemu.

W wersji (3GPP Release) 7 i 8 standaryzacji 3GPP dla sieci UMTS, rozwaŜane są

rozwiązania, których celem jest umoŜliwienie wykorzystania sieci z komutacją łączy do

świadczenia usług opartych o IMS. Jako przykład kierunku tych prac opisane zostaną dwa

rozwiązania określane jako VCC (Voice Call Continuity) oraz IMS centralized services.

VCC jest rozszerzeniem architektury IMS o elementy umoŜliwiające przeniesienie

(handover) pomiędzy sesją realizowaną poprzez IMS (opartą o VoIP), a połączeniem

wykorzystującym komutacje łączy. Głównym celem wprowadzenia tego typu funkcji do sieci

jest rozwiązanie problemu polegającego na braku ciągłego pokrycia geograficznego siecią

radiową zdolną do świadczenia usług głosowych na bazie VoIP. Rys. 17 pokazuje scenariusz

przełączenia pomiędzy sesją IP, a połączeniem w sieci GSM.

34 Przykładowo techniki takie jak HSDPA i HSUPA w sieci UMTS umoŜliwiają realizacje VoIP, lecz obecny zasięg pokrycia geograficznego UMTS jest niewystarczający do zapewnienia usługi w warunkach mobilności uŜytkownika.

IP Multimedia Subsystem

40

Rys. 17: Przekazywanie (Handover) pomiędzy IMS a siecią GSM

Przykładowo uŜytkownik „A” (Rys. 17) jest w zasięgu sieci umoŜliwiającej szerokopasmowy

dostęp IP (np. HSPA35). „A” korzysta z IMS do połączenia z uŜytkownikiem „B” (sieć GSM).

Gdy uŜytkownik „A” opuszcza obszar zasięgu szerokopasmowego, jego terminal inicjuje

połączenie GSM, które jest kierowane do aplikacji VCC (serwer aplikacyjny) w IMS, a ruch

uŜytkowy jest „zakotwiczany” w MGW. VCC instruuje MGCF, aby skojarzył dwie „odnogi”

tego połączenia, co powoduje, Ŝe dalsza realizacja odbywa się juŜ w całości w sieci GSM.

Szczegółowo działanie VCC opisane jest w [5].

IMS centralized services jest próbą ujednolicenia implementacji usług. Zgodnie z

architekturą IMS release 5 i 6, usługi na serwerach aplikacyjnych mogą być świadczone tylko

dla uŜytkowników sieci pakietowej. Ze względu na ograniczenia związane z brakiem

mobilnej sieci pakietowej o wystarczających parametrach jakościowych, udostępnienie

35 HSDPA i HSUPA.

IP Multimedia Subsystem

41

usługi, która ma być dostępna dla wszystkich uŜytkowników, wymaga implementacji

zarówno na bazie IMS, jak i z wykorzystaniem metod na potrzeby sieci z komutacją łączy

(np. IN). IMS centralized services zakłada, Ŝe kaŜdy uŜytkownik (sieci z komutacją łączy)

będzie utrzymywał kanał danych o niskiej przepływności wykorzystywany do wymiany

sygnalizacji z IMS36, który między innymi jest wykorzystywany do rejestracji. KaŜde

połączenie inicjowane do uŜytkownika będzie kierowane do IMS (poprzez MGCF i MGW),

gdzie zostaną wykonane procedury związane z realizacją usług (na serwerach aplikacyjnych),

a następnie połączenie zostanie „zawrócone” z powrotem do sieci z komutacją łączy (patrz

Rys. 18)

Rys. 18: Połączenie pomiędzy uŜytkownikami sieci GSM z obsługą usług w IMS

Prace nad IMS centralized services [1] są na wczesnym etapie i mają jeszcze charakter

koncepcyjny.

36 RozwaŜany jest GPRS (dla sieci 2.5G) albo USSD (dla 2G).

4. Parlay/OSA oraz Parlay X

4.1 Geneza Parlay/OSA

W roku 1984 British Telecom (BT) został podzielony na dwie niezaleŜne spółki na

mocy decyzji wydanej przez OFTEL37. Decyzja ta była ściśle związana z sytuacją na rynku

telekomunikacyjnym w Wielkiej Brytanii – wchodził on właśnie w fazę liberalizacji. Jedna z

tych firm miała zajmować się usługami transportowymi w sieci, druga dostarczaniem usług

dla klienta końcowego. Potrzebne, więc były narzędzia za pomocą, których spółka zajmująca

się transportem w sieci mogłaby udostępniać funkcjonalność tejŜe sieci na rzecz tej drugiej

spółki, a takŜe na rzecz innych potencjalnych usługodawców. Pięć firm (m.in. Siemens, BT,

Nortel, Ulticom i Microsoft) podjęło się wyzwania stworzenia jednolitej architektury do

budowy usług. W tym celu została powołana inicjatywa Parlay.

Inicjatywa Parlay bazowała na wcześniejszych, podobnych doświadczeniach

przedsięwzięć chcących stworzyć otwarte środowisko do kreacji usług (np. TINA38).

Ostatecznie inicjatywy te kończyły się poraŜką (oczywiście z tego grona naleŜy wyłączyć

koncepcję sieci inteligentnej) ze względu na poniŜej wymienione problemy:

� Brak szerokiej współpracy pomiędzy operatorami, dostawcami sprzętu, treści usług,

integratorami;

� Oferowane wsparcie jedynie dla jednego typu sieci/terminala;

� Zbyt duŜa złoŜoność, aby mógł zostać zaadoptowany i wykorzystywany przez trzecią

stronę. Usługi mogła tworzyć jedynie wąska grupa specjalistów;

� Brak bezpieczeństwa i ochrony zasobów operatora, który je udostępnia;

� Brak moŜliwości prostej integracji z istniejącymi systemami rozliczeniowymi

operatorów;

� ZaleŜność od techniki sieciowej oraz jej implementacji.

37 Regulator rynku elektronicznego w Wielkiej Brytanii, odpowiednik polskiego Urzędu Komunikacji Elektronicznej. 38 Telecommunication Information Networking Architecture. TINA była jedną z pierwszych prób zdefiniowania architektury, która integrowała funkcje sterowania i zarządzania w jedną logiczną całość, a usługi miały być tworzone z wykorzystaniem standardowych języków programowania. Szczegóły dotyczące tej inicjatywy dostępne są pod adresem http://www.tinac.com/ [58].

Parlay/OSA oraz Parlay X

43

Parlay Group w wymaganiach uwzględniło wyŜej wymienione aspekty, a przy procesie

opracowywania specyfikacji skupiło szeroką grupę przedstawicieli operatorów, dostawców

usług, sprzętu, treści. Efektem prac Parlay Group39 była specyfikacja interfejsów

Parlay/OSA40.

4.2 Opis Parlay/OSA

Norma Parlay/OSA definiuje architekturę, która umoŜliwia twórcom usług i aplikacji

dostęp do zasobów i funkcjonalności sieci telekomunikacyjnej operatora poprzez

zestandaryzowany interfejs programistyczny tzw. API (Application Programming Interface).

Parlay/OSA API przedstawia abstrakcję dla zbioru protokołów. Abstrakcja ta przykrywa

niskopoziomową funkcjonalność protokołów, co w efekcie niesie za sobą dwie zasadnicze

konsekwencje. Z jednej strony podejście takie ułatwia tworzenie usług/aplikacji41, gdyŜ

operujemy na uogólnionym zbiorze funkcji, który jest wspólny dla grupy protokołów.

Ujednolicenie heterogenicznego środowiska (sieć IN, sieć IP) wspiera takŜe pisanie aplikacji

konwergentnych. Z drugiej jednak strony ogranicza wykorzystanie zawansowanej

funkcjonalności dostępnej jedynie z poziomu protokołu i czasami wyłącznie dla danego

protokołu.

Sposób myślenia związany z prezentacją moŜliwości i funkcjonalności sieci po przez

API jest znany doskonale programistom. Programista kojarzy zestawienie połączenia w

TCP/IP z wywołaniem funkcji bind() , connect() , send() , etc.., a nie z wymianą

wiadomości. Jeśli by chciał natomiast zestawić połączenie w sieci SIP napisałby

39 Parlay Group zostało załoŜone na bazie inicjatywy Parlay w roku 1998 i aktualnie zrzesza 75 firm m.in. operatorów, dostawców usług, sprzętu i treści. Do projektu dołączyły ETSI i 3GPP. W tym samym roku opublikowali pierwszą specyfikację Parlay API. W wyniku zainteresowania, jakie standard wzbudził wśród operatorów podczas testowych wdroŜeń oraz powstałych na tej bazie wniosków Parlay Group wydało w 2003 roku wersję 4.1 interfejsów Parlay API. 40 Istnienie dwóch nazw: Parlay i OSA (Open Services Architecture) ma podłoŜe historyczne. Parlay odwołuje się do standardów tworzony przez Parlay Group, natomiast OSA odwołuje się do prac na standardami prowadzonymi przez 3GPP (Third Generation Partner Ship Project). Efekty prac obu ciał miały te same cele, tak więc postanowiono połączyć siły grup Parlay Group, ETSI i 3GPP. 41 Stworzenie usługi w środowisku IN wymaga duŜej wiedzy, co znacząco zawęŜa grupę potencjalnych twórców usług. W [50] oszacowano, Ŝe grupa potencjalnych twórców usług dla IN obejmuje ok. 10000 osób, natomiast liczba potencjalnych programistów potrafiących napisać usługę w oparciu o Parlay/OSA zwiększa się do 250 000. Wynika to z faktu, iŜ w przypadku podejścia Parlay/OSA, które wykorzystuje standardowe języki programowania np. Java, C napisanie usługi sprowadza się do stworzenia aplikacji, której złoŜoność nie jest większa niŜ np.: złoŜoność aplikacji wykorzystującej standardowe API dla berkley-owskich gniazd sieciowych (socket API). Natomiast budowa usługi IN wymaga precyzyjnej znajomości protokołów oraz ich implementacji.

Parlay/OSA oraz Parlay X

44

najprawdopodobniej makeCall(adres_a, adres_b) . Propagowanie opisanego modelu

programistycznego zwiększa rzeszę potencjalnych twórców usług telekomunikacyjnych.

Funkcjonalność oferowana przez zbiór Parlay/OSA API jest róŜnorodna i w gruncie

rzeczy pozwala zaspokoić oczekiwania twórców usług, gdyŜ spełnia większość wymagań

stawianych aplikacjom SIP/IMS. Przykładowo API do sterowania sesją obejmuje m.in.

generyczne sterowanie zgłoszeniami (Generic Call Control), wielostronne sterowanie

połączeniami (Multi-Party Call Control), sterowanie mediami podczas połączenia oraz

połączeniami konferencyjnymi (Multi-Media Call Control and Conference Call Control).

Szczegółowy wykaz funkcjonalności wszystkich API moŜna znaleźć w rodzinie specyfikacji

w [16].

4.3 Architektura Parlay/OSA

Architektura Parlay składa się z elementów:

� Aplikacja - wykorzystuje interfejsy usług udostępnianych przez Operatora Sieci.

Aplikacje mogą być równieŜ tworzone przez trzecią stronę i rozmieszczone w jej

domenie.

� Szkielet (Framework) - jest rdzeniem architektury Parlay/OSA. Udostępnia funkcje

zabezpieczające dostęp do interfejsów usług i chroni sieć operatora przed

naduŜyciami. Framework wspiera:

� identyfikację aplikacji (Authentication);

� odkrywanie nowych interfejsów (Discovery);

� informowanie o zdarzeniach (Event Notification);

� zarządzania integralnością API (Integrity Management);

� dodawanie nowych interfejsów w API (Registration);

� zarządzanie kontraktami (Contract Management);

� zarządzanie cyklem Ŝycia usług (Service Life Cycle Manager);

� Usługi (Services) - składają się z pojedynczych Interfejsów Usług (Service Interface) i

Obiektu Usługi (Service Object) tj. jej implementacji. Interfejsy Usług dają dostęp do

funkcjonalności sieci, którą Operator Sieci chce eksponować po przez Parlay/OSA.

Usługi są implementowane i dostępne po przez Obiekty Usług, które są logicznym

Parlay/OSA oraz Parlay X

45

elementem implementującym jedną lub więcej Interfejsów Usług. Obiekty Usług

oddziałują z elementami sieci.

� Zasobów (Resources) - reprezentują zasoby sieciowe, funkcjonalność innych urządzeń

w sieci dostępnych za pomocą Obiektów Usług. Przykładami są routery, systemy

bilingowe, serwer obecności, itp..

Zasoby sieciowe eksponowane są po przez Bramę Parlay/OSA, która mapuje je do

Parlay/OSA API z wykorzystaniem techniki CORBA42. Interfejs programistyczny

udostępniany przez Bramę składa się z interfejsu Parlay Framework oraz jednego lub więcej

Service Capability Server (SCS). KaŜdy serwer moŜe obejmować jedną lub więcej Service

Capability Features (SCF), natomiast za kaŜdym SCS znajdują się określone zasoby, które

udostępnia implementacja konkretnej Usługi. Struktura architektury Parlay/OSA została

przedstawiona na Rys. 19.

Rys. 19: Ogólna architektura Parlay/OSA

42 Common Object Request Broker Architecture – technika, która zapewnia komunikacje pomiędzy elementami heterogenicznego środowiska komputerowego (patrz [56]).

Parlay/OSA oraz Parlay X

46

4.4 Ograniczenia Parlay/OSA

Technika Parlay/OSA ma pewne ograniczenia związane z realizacją wymagania

dotyczącego moŜliwości swobodnego tworzenia aplikacji przez ISV (Independent Software

Vendor). Oto one:

� komunikacja pomiędzy serwerem aplikacyjnym, a Bramą Parlay/OSA nie jest w Ŝaden

sposób zabezpieczona;

� uŜyta technika CORBA uniemoŜliwia komunikację pomiędzy elementami Bramy

poprzez urządzenia takie jak NAT (Network Address Translation), czy firewall, które

są stałym elementem sieci operatorów i dostawców usług. Zatem aplikacje stworzone

z wykorzystaniem Parlay/OSA API mogą znajdować się jedynie w sieci, w której jest

Brama.

� ostatecznie doświadczenia operatorów, którzy wdroŜyli Parlay/OSA wskazują, Ŝe

interfejsy pomimo znacznego uproszczenia nadal wymagają od ISV duŜej wiedzy w

zakresie telekomunikacji m.in. znajomości architektury i działania sieci

telekomunikacyjnej.

Ograniczenia te sprawiają, Ŝe Parlay/OSA wdraŜane jest jako model tzw. „walled

garden43” . Przejście do modeli np. „Enterprise Integration”, czy „Open Network”44, które

pozwalają Operatorom otworzyć szerzej ich sieci moŜliwe jest w momencie rozwiązania

wymienionych problemów, a techniką, która moŜe temu stawić czoła jest Parlay X.

4.5 Parlay X (Parlay Web Services)

Parlay X jest kolejną techniką, która wspiera idee otwarcia sieci telekomunikacyjnych.

Specyfikacja została stworzona przez konsorcjum, które wcześniej przygotowało koncepcję i

definicję Parlay/OSA. Głównym celem, jaki został postawiony projektantom Parlay X było

stworzenie takiego interfejsu, który będzie bardzo łatwy w uŜyciu. W związku z tym

zrezygnowano z wykorzystania funkcji typu call back45 oraz z sesji.

43 Model „walled garden” (stworzony przez Parlay Group) - opisuje kolejny krok związany z otwarciem sieci operatora. W tym modelu usługi tworzone są juŜ przez ISV, ale zarządzane i utrzymywane w środowisku operatora. 44 Opis tych modeli znajduje się w [50]. 45 Funkcje typu call back – wywołania zwrotne – działają odwrotnie to zwykłych funkcji. Funkcje te rejestruje się, a ich wywołaniem zajmuje się odpowiednia biblioteka. Jako argument funkcja tego typu otrzymuje kod, który powinien zostać wykonany.

Parlay/OSA oraz Parlay X

47

Parlay X uogólnia funkcjonalność dostarczaną przez Parlay/OSA API poprzez

wykorzystanie interfejsów Web Services46. Natomiast Web Services otwiera alternatywny

sposób tworzenia i rozmieszczania usług. Cechą charakterystyczną Web Services jest:

� łatwa integracja – w przeciwieństwie do technik takich jak CORBA, Remote Method

Invocation (RMI), które posiadają stosunkowo złoŜone modele programistyczne oraz

pewne ograniczenia (CORBA, patrz rozdział 4.4) związane z wykorzystaniem poza

siecią macierzystą;

� redukcja kosztów dzięki wykorzystaniu istniejącej infrastruktury dla aplikacji

bazujących na protokole HTTP. Aplikacje mogą być tworzone z wykorzystaniem

dowolnego języka programowania (np. Java, C#, etc..), który wspiera Web Services;

� moŜliwość wykorzystania posiadanych juŜ umiejętności oraz narzędzi (np. Borland

JBuilder, Visual Studio .Net, SunONE Studio) uŜywanych przy tworzeniu aplikacji

bazujących na usługach sieciowych. Jest to równieŜ potencjalna okazja dla ISV,

aŜeby wejść na rynek aplikacji telekomunikacyjnych oraz rozszerzyć funkcjonalność

juŜ istniejących swoich produktów/usług.

Oczywiście Parlay X uwzględnia równieŜ szereg wymagań postawionych przed

Parlay/OSA, a m.in. aspekty dotyczące bezpieczeństwa (np. autoryzację, identyfikację

aplikacji), moŜliwość zagwarantowania SLA, moŜliwość rozliczenia, etc..

4.6 Modele biznesowe

Jedną z głównych przyczyn powstania Parlay X były oczywiście kwestie biznesowe.

Wykorzystanie Web Services rozszerza modele biznesowe wypracowane dla Parlay/OSA.

Modele te zapewniają zwiększenie przychodów oraz redukcję kosztów zarówno dla

operatorów jak i równieŜ ISV. Zwiększenie przychodów moŜe zostać osiągnięte w wyniku

oferowania istniejących usług, poprzez nowopowstałe kanały oraz poprzez pojawienie się

nowych ciekawszych usług. Nowe usługi mają szanse stać się bardziej atrakcyjne, poniewaŜ

proces realizacji usługi jest mniej skomplikowany, a większa rzesza osób potrafiących

tworzyć usługi, to potencjalnie więcej pomysłów znacznie lepiej odzwierciedlających

oczekiwania zróŜnicowanej grupy uŜytkowników. Natomiast redukcja kosztów wynika z

46 Web Services – (dalej nazywane równieŜ usługami sieciowymi) jest to komponent programistyczny, który implementuje pewną funkcjonalność. Funkcjonalność ta jest prezentowana i dostępna za pomocą interfejsu Web Services. Szczegółowo architektura zostanie przedstawiona w trakcie omawiania architektury Parlay X.

Parlay/OSA oraz Parlay X

48

wcześniej wspomnianego aspektu uproszczenia procesu tworzenia oraz skrócenia łańcucha jej

dostarczenia do uŜytkownika końcowego (np.: twórca usługi moŜe być bezpośrednio jej

dostawcą, uproszczenie integracji systemów etc..).

W [44] zostały szczegółowo przedstawione i omówione trzy przykładowe modele

biznesowe:

� współpraca pomiędzy operatorami (cross network access) polegająca na wzajemnym

wykorzystaniu zasobów lub odsprzedawaniu zasobów wirtualnym operatorom

mobilnym (Moblie Vritual Network Operator);

� współpraca pomiędzy ISV produkującymi nowe usługi i dostawcami usług mająca na

celu odkrycie rynków niszowych i dostarczenie na nie odpowiednich produktów;

� wykorzystanie interfejsów Parlay X do rozszerzenia funkcjonalności aplikacji typu

enterprise np.: systemów ERP, CRM o moŜliwości oferowane przez sieci

telekomunikacyjne. Procesem rozbudowy aplikacji moŜe zająć się dział IT, który nie

koniecznie musi mieć specjalistów telekomunikacji. Poza tym wykorzystanie Web

Services w aplikacjach enterprise jest naturalnym sposobem ich rozbudowy, gdyŜ

przedsiębiorstwa nie chcą uniezaleŜniać się od konkretnej techniki, czy dostawcy

rozwiązań IT.

4.7 Funkcjonalność Parlay X API

Parlay X w wersji 2 oferuje zestaw 14 interfejsów (Tab. 1), które moŜna podzielić na

następujące kategorie:

� interfejsy związane z abstrakcją zgłoszeń (call related);

� interfejsy do mechanizmów rozliczania (charging);

� interfejsy związane z funkcjonalnością urządzeń końcowych (terminal related)

� kategoria dla interfejsów usług, które nie mieszczą się w powyŜszych kategoriach.

Parlay/OSA oraz Parlay X

49

Tab. 1 Zestawienie interfejsów Parlay X z podziałem na kategorie.

Kategoria Nr. Usługa Opis

Ogólne 1 Ogólne definicje typów danych

Definiuje podstawowe typy danych XML, przestrzenie nazw, typy błędów oraz załoŜenia do opis interfejsów przy pomocy WSDL.

2 Third Party Call Zestawianie i zarządzanie połączeniami stworzonymi przez aplikację. Interfejs ten pozwala na zestawienie połączenia pomiędzy dwoma stronami.

3 Call Notification Pozwala określić, w jaki sposób zgłoszenie zainicjowane z sieci powinno być traktowane. UmoŜliwia prostą obsługę połączeń.

10 Call Handling Pozwala sterować przebiegiem zgłoszenia i realizować takie usługi jak: akceptacja, blokowanie, przekierowanie zgłoszenia, odgrywanie przekazów audio.

11 Audio Call Interfejs ten pozwala na odgrywanie zapowiedzi. Jest to prosty interfejs niewymagający od programisty tworzenia połączenia, ani jego modyfikacji w celu odegrania wiadomości.

Call Related

12 Multimedia Conference

Interfejs ten umoŜliwia kreację połączeń telekonferencyjnych i dynamiczne zarządzanie uczestnikami telekonferencji oraz rodzajem mediów.

4 SMS Pozwala na obsługę wiadomości SMS m.in. wysyłanie, odbieranie tekstu, dzwonków, prostej grafiki, ustawiania powiadomień o przyjściu SMS, etc..

Messaging

5 MMS Posiada podobną funkcjonalność jak interfejs powyŜej z tym, Ŝe obsługuje EMS, MMS, IM, e-mail, etc..

6 Payment Pozwalaja definiować róŜnego rodzaju płatności dla treści w otwartym środowisku sieciowy, np. płatności pre-paid, post-paid, etc..

Charging

7 Account management

Funkcjonalność doładowywania kont sprawdzania ich dla uŜytkowników pre-paid.

8 Terminal status Za pomocą tej usługi moŜna uzyskać status terminala, grupy terminali oraz powiadomienia o zmianie statusu terminala.

9 Terminal location

Dostęp do informacji o lokalizacji (wysokość, długość oraz szerokość geograficzna) danego terminala, grupy terminali. Usługa ta pozwala ustawić powiadomienia o zmianie lokalizacji.

Terminal Related

14 Presence Usługa ta pozawala na uzyskanie informacji o obecności uŜytkownika oraz na zarządzanie nią.

Parlay/OSA oraz Parlay X

50

Rother 13 Address List Management

Interfejs umoŜliwia zarządzanie grupami kontaktów (odpytywanie, usuwanie, modyfikacja).

Wybrane do implementacji interfejsy zostały omówione szczegółowo w rozdziale 1.

Rys. 69 prezentuje zaimplementowane w ramach środowiska badawczego interfejsy Parlay X.

4.8 Architektura Parlay X

Logika

usługi

Usługa Sieciowa

Framework

Interfejs

Aplikacyjny

Parlay X

Brama Parlay Web Services

Rejestr Usług Siecowych

Definicja Usługi SieciowejDefinicja Usługi SieciowejDefinicja Usługi Sieciowej

Serwer Aplikacyjny Parlay

Definicja Usługi SieciowejDefinicja Usługi Sieciowej

Aplikacje Parlay

Web Services ProviderWeb Services Requestor

Web Services Broker

ZNAJDŹ REJESTRUJ

PRZYWIĄś

WSDL

SOAP

KOMUNIKACJA

WSDL

UDDI

Rys. 20 Architektura Web Services z naniesioną terminologią Parlay X

Standardowa architektura Web Services z naniesionymi terminami Parlay X została

przedstawiona na Rys. 20. Rozpoczynając omawianie architektury Parlay X na samym

początku zostanie podana definicja zasadniczego pojęcia usługi sieciowej.

Web Service (usługa sieciowa) – jest to interfejs, który opisuje zbiór operacji/funkcji

dostępnych w sieci takiej jak np. Internet po przez zdefiniowany mechanizm wymiany

wiadomości wykorzystujący protokół SOAP47 (Simple Object Application Protocol).

Wywołanie funkcji danego interfejsu tzw. Ŝądanie usługi (service request) powoduje

47 Simple Object Access Protocol (SOAP) – jest standardem opartym o język XML słuŜącym do wymiany informacji pomiędzy aplikacjami w rozproszonym środowisku. Aktualnie SOAP jest przenoszony na protokole HTTP i wykorzystywanym do wykonywania usług sieciowych. Inne sposoby transportu są równieŜ moŜliwe np. SMTP. Specyfikacja znajduje się w [47].

Parlay/OSA oraz Parlay X

51

wykonanie tej funkcji na zdalnym systemie, hostującym Ŝądaną usługę. Usługa sieciowa

opisana jest przy uŜyciu języka WSDL48 (Web Service Description Language).

Architektura Web Services opisuje interakcje pomiędzy trzema aktorami (patrz Rys.

20): Web Service Provider, Web Service Requestor i Web Service Broker. Interakcja

pomiędzy tymi elementami obejmuje: operacje rejestracji usługi (publish), operacje

wyszukania usługi (find), przywiązania (bind) oraz późniejsze zdalne wywoływanie funkcji

usługi sieciowej.

W typowym scenariuszu, Web Service Provider przechowuje dostępny w sieci

komponent programistyczny, który zawiera implementację konkretnej usługi sieciowej.

Usługa sieciowa powinna zostać opisana przez Web Service Provider’a za pomocą języka

WSDL i zarejestrowana u Web Service Broker’a. Web Service Requester musi wyszukać

opublikowaną wcześniej usługę sieciową (find). MoŜe tego dokonać korzystając ze specjalnie

stworzonej do tego usługi sieciowej UDDI49 (Universal Description, Discovery and

Integration). Po znalezieniu usługi musi pobrać jej opis i przywiązać do interfejsu usługi

(bind). Warto wspomnieć, Ŝe opis usługi moŜe zostać pobrany niezaleŜnie od UDDI w postaci

pliku XML z WSDL.

PoniŜej zostały role w architekturze Web Services:

� Web Service Provider. Patrząc z punktu widzenia modelu biznesowego jest to

właściciel usługi sieciowej. Z punktu widzenia architektury Web Sercvices zajmuje

się on przechowywaniem implementacji usługi na serwerze. Określa równieŜ zasady

dostępu do usługi.

48 Web Service Description Language (WSDL) – jest językiem opartym o XML stworzonym do opisywania usług sieciowych. Zawiera informacje na temat, w jaki sposób komunikować się z usługą. Specyfikacja znajduje się w [48]. 49 Universal Description, Discovery and Integration (UDDI) jest niezaleŜną platformą, która udostępnia bazujący na XML rejestr, w którym umieszczane są opisy usług dostępne poprzez sieć Internet. UDDI jest otwartą inicjatywą sponsorowaną przez OASIS. UDDI jest zorganizowany podobnie jak ksiąŜka telefoniczna, a informacja, ktrórą przechowuje obejmuje:

� Białe strony – adresy, kontakty i elementy identyfikujące;

� śółte strony – podział usług według branŜy;

� Zielone strony – informacja techniczna, co zrobić, aby z danej usługi skorzystać.

UDDI naleŜy do specyfikacji Web Services. MoŜna wyróŜnić:

� węzły UDDI (UDDI Nodes) – są to serwery wspierające specyfikację UDDI i przynaleŜące do określonego rejestru UDDI;

� Rejestry UDDI (UDDI Registry) – jest to jeden lub więcej węzłów UDDI.

Parlay/OSA oraz Parlay X

52

� Web Service Requestor. Z biznesowego punktu widzenia jest to jednostka, która Ŝąda

określonej funkcjonalności. Natomiast z punktu widzenia architektury jest to

aplikacja kliencka, która wyszukuje, inicjuje i wywołuje Ŝądaną usługę sieciową

udostępnianą przez Web Service Provider’a. Oczywiście w roli Web Service

Requestor’a moŜe być inna usługa sieciowa, która wykorzystuje daną

funkcjonalność.

� Web Service Broker (Registry) zajmuje się zarządzaniem informacją o Web Service

Provider’ach i oferowanych przez nich usługach sieciowych. Informacje te mają

podobną strukturę jak ksiąŜki telefoniczne i obejmują:

o Dane biznesowe takie jak: nazwa, opis i informacje kontaktowe. Są to tzw.

„białe strony” .

o Dane opisujące politykę bezpieczeństwa, procesy biznesowe, sposób

korzystania z usługi. Jednym słowem dane, które opisują, w jaki sposób uŜyć

usługę. Analogicznie do ksiąŜek telefonicznych są to tzw. „zielone strony”.

Web Service Broker moŜe klasyfikować usługi pod kątem funkcjonalności

będą to tzw. „zielone strony”, oferować specjalny mechanizm do ich

przeszukiwania oraz ich sprzedaŜy (np. UDDI). Z punktu widzenia architektury

jest to rejestr, który przechowuje opisy usług publikowane przez Web Service

Provider’a. Opisy usług mogą zostać pobrane z alternatywnych źródeł jak np.

strona WWW w postaci pliku XML, jeśli znamy bezpośrednio ich dostawcę,

dlatego teŜ Web Service Broker jest opcjonalnym element architektury Web

Services.

PoniŜej zdefiniowano zbiór akcji, który moŜe być wykonywany przez lub na rolach

architektury Web Services.

� Publish. Akcja wykonywana przez Web Service Provider’a, polegająca na

zarejestrowaniu opisu usługi, w celu późniejszego odszukania jej przez Web Service

Requestor’a. Po przygotowaniu opisu usługi w WSDL-u budowany jest tzw. tModel,

który jest jednoznacznym identyfikatorem danej usługi sieciowej. tModel moŜe być

traktowany w kategorii przestrzeni nazw uŜywanej w innych tModel-ach. Proces

rejestracji przebiega w trzech krokach:

o publikacja informacji o dostawcy usługi - stworzenie „białej strony” ;

Parlay/OSA oraz Parlay X

53

o publikowanie usługi – stworzenie „ Ŝółtej strony”, zadecydowanie do jakiej

kategorii powinna przynaleŜeć usługa;

o publikowanie informacji na temat dostępu do usługi – opis funkcjonalności

oferowanej przez usługi i technicznej informacji na temat komunikacji z

usługą.

� WyróŜnia się dwa rodzaje sposobów, na jakie usługa moŜe zostać

opublikowana:

o bezpośrednia publikacja (direct publication) – najprostszy mechanizm

publikacji. Opis usługi sieciowej jest udostępniany przez Web Service

Provider’a bezpośrednio (np. za pomocą e-mail, na stronie www, itp.) w

postaci pliku XML.

o Dynamiczna publikacja (dynamic publication) – opis usługi sieciowej zostaje

umieszczony w repozytorium, którym moŜe być np. prywatny lub publiczny

serwer UDDI.

� Find. Operacja ta wykonywana jest przez Web Service Requestor’a. Pobiera on opis

usługi bezpośrednio lub odpytuje Web Service Broker’a o Ŝądaną usługę. Informacja

o usłudze moŜe zostać pobrana w dwóch róŜnych cyklach działania Web Service

Requestor’a:

o W trakcie projektowania (at design time) – opis interfejsów usługi pobierany

jest w momencie tworzenia aplikacji.

o W trakcie działania (at runtime) – aplikacja wyszukuje Ŝądaną usługę i łączy

się z nią w trakcie jej wykonywania.

� Bind. Operacja wykonywana przez aplikację Web Service Requestor’a podczas jej

działania. Aplikacja inicjuje komunikacje z usługą sieciowa uŜywając informacji jak

się z nią połączyć m.in. lokalizacja, kontakt i sposób wywołania usług. Informacje te

znajdują się w opisie usługi (patrz Rys. 21).

Parlay/OSA oraz Parlay X

54

Rys. 21 Przykładowy fragment opisu usługi w języku WSDL zawierający informacje potrzebne do

wykonania operacji Bind.

4.9 Ograniczenia Parlay X

Parlay X posiada pewne ograniczenia, których powinien być świadomy konstruktor

usług telekomunikacyjnych. Ograniczenia te wynikają głównie z faktu, Ŝe Web Services jest

techniką, która nie była projektowana dla aplikacji telekomunikacyjnych i do tej pory nie

poświęcano im wszystkim wystarczająco duŜo uwagi. Do tych ograniczeń moŜna zaliczyć

m.in.: kwestię wydajności, bezpieczeństwa, dostępności, niezawodności, zarządzania

przeciąŜeniami, skalowalności, odporności na błędy, itp. czynników istotnych w systemach

telekomunikacyjnych. Przeczytawszy tą listę moŜna mieć wraŜenie, Ŝe technika Web Services

zupełnie nie nadaje się do tego, do czego została wybrana przez twórców Parlay X. Tak

oczywiście nie jest. Rozwiązanie wymienionych kwestii leŜy głównie w kompetencjach

projektantów platform, zespołów implementujących usługi sieciowe oraz ogólnego rozwoju

systemów obliczeniowych.

Kwestia niskiej wydajności wynika z faktu, Ŝe Web Services wymaga przejścia przez

wiele warstw w stosie protokołów. Najbardziej zasobochłonnymi procesami jest analiza

składniowa i przetwarzanie wiadomości SOAP będących dokumentami XML. W tym

przypadku rozwiązaniem jest wybór odpowiednio lekkiego i zoptymalizowanego analizatora

składni XML50. Problemy z wydajnością dotyczą równieŜ aplikacji napisanych w języku Java,

który często jest wykorzystywany przez społeczność tworzącą rozwiązania

telekomunikacyjne. Optymalizacja działania tych aplikacji moŜe zostać uzyskana poprzez

50 Istnieje kilka rodzajów analizatorów składni tzw. parserów, które róŜnią się wydajnością oraz funkcjonalnością. Dwa zasadnicze to SAX i DOM. W ostatnim czasie pojawiły się projekty parserów, które łączą najlepsze cechy obydwu. Takim parserem jest np. DOM-SAX. Przykładowe zestawienie parserów znajduje się w [55].

Parlay/OSA oraz Parlay X

55

wcześniejsze skompilowanie kodu Javy51. Oczywiście rozwój mocy obliczeniowej maszyn

rozwiąŜe w pewnym stopniu kwestie wydajności.

Ograniczenie dotyczące niezawodności Web Services uwarunkowane jest tym, Ŝe

protokołem transportowym dla Web Services jest HTTP. Protokół HTTP nie gwarantuje ani

dostarczenia wiadomości (jest protokołem bezstanowym), ani równieŜ Ŝadnego QoS. W tym

zakresie istotne jest odpowiednie zabezpieczenie52 przez twórcę usługi kanału transmisji

pomiędzy Web Service Requestor-em, a Web Service Provider-em.

Wyeliminowanie problemów: skalowalności, zarządzania przeciąŜeniami, dostępności

moŜliwe jest przez stworzenie odpowiedniej architektury fizycznej. Ze względu na fakt, Ŝe

Parlay X nie ma mechanizmu sesji – jest bezstanowy - problemy te daje się łatwo rozwiązać

poprzez uŜycie wystarczającej liczby odpowiednio wydajnych maszyn, na których ma działać

Brama Parlay X.

Kwestia bezpieczeństwa ze względu na jej wagę, zostanie omówiona osobno w

kolejnym punkcie.

4.10 Bezpieczeństwo Parlay X

Dla Operatorów otwierających swoje sieci bezpieczeństwo jest jednym z waŜniejszych

aspektów. W Web Services kaŜdy element definiuje mechanizmy bezpieczeństwa.

� Mechanizm bezpieczeństwa w momencie rejestracji usługi w publicznym węźle

UDDI

Web Service Provider, aŜeby zarejestrować usługę w węźle UDDI musi wcześniej

uzyskać swój identyfikator. W wersji 2 UDDI moŜliwość modyfikacji, usunięcia

zarejestrowania nowej usługi moŜliwe jest jedynie po wcześniejszym zautoryzowaniu

uŜytkownika w węźle UDDI.

� Mechanizm bezpieczeństwa w momencie rejestracji usługi w prywatnym węźle

UDDI

51 Do tego celu moŜna wykorzystać kompilator gjc. Oczywiście taki kod przestaje być przenośnym natomiast charakterystyka wydajności ulega znacznemu polepszeniu. Przykładowe testy porównawcze dostępne są w [52]. 52 Rozwiązaniem jest uŜycie asynchronicznych kolejek wiadomości oraz niezawodnych protokołów transportowych np. HTTPR, BEEP (patrz [45]).

Parlay/OSA oraz Parlay X

56

Węzeł prywatny UDDI moŜe wykorzystywać podobny mechanizm jak węzeł

publiczny. Mechanizm ten jednak moŜe zostać dodatkowo rozszerzony o konieczność

posiadania uprawnień w sieci, w której znajduje się węzeł.

� Bezpieczeństwo w trakcie wyszukiwania usługi w węźle UDDI

W wersji 2 UDDI nie był implementowany mechanizm zabezpieczający przed

odczytywaniem zawartości tak, więc wszystkie wpisy w rejestrze były dostępne dla

kaŜdego. Chcąc ograniczyć dostęp do danej usługi naleŜy ustawić odpowiednio

politykę bezpieczeństwa przy operacji bind. Wersja 3 UDDI została wyposaŜona w

mechanizm kontroli dostępu do treści tak, więc moŜna ograniczyć dostęp do

informacji o danej usłudze. Oczywiście nie zwalnia to z definicji polityki

bezpieczeństwa przy operacji bind.

� Bezpieczeństwo przy łączeniu z Bramą Pralay X

Brama Parlay X jest elementem, który ostatecznie powinien regulować dostęp do

usług sieciowych. Mechanizm bezpieczeństwa moŜe być zrealizowany poprzez

implementację dodatkowej usługi, która byłaby odpowiedzialna za przestrzeganie

polityki autoryzacji i dostępu do Ŝądanej usługi.

W modelu, w którym Parlay X korzysta z funkcjonalności jednej lub więcej Bram

Parlay/OSA dedykowana usługa sieciowa Parlay X odpowiedzialna za

bezpieczeństwo powinna dokonać autoryzacji w kaŜdej z bram.

� Bezpieczeństwo danych

Bezpieczeństwo danych jest zapewnione przez protokół komunikacyjny WS-

Security53. WS-Security dokonuje szyfrowania wiadomości SOAP na dowolnie

wybranym poziomie w zaleŜności od potrzeb aplikacji. WS-Security umoŜliwia

zabezpieczenie całej wiadomości lub tylko wybranych elementów pomijając np.:

informację w nagłówkach routingowych. Dzięki temu serwery pośredniczące w

wymianie wiadomości mogą realizować ich przetwarzanie bez konieczności

posiadania uprawnień do jej odszyfrowania.

Innym sposobem zapewnienia integralności i poufności dla Web Services jest

zabezpieczenie komunikacji na poziomie warstwy transportowej. W tym celu moŜe zostać

53 Web Service Security - Specyfikacja protokołu znajduje się w [43].

Parlay/OSA oraz Parlay X

57

uŜyty protokół HTTPS54 albo TLS (Transaction Layer Security)55. Serwery pośredniczące,

które korzystają z tego rodzaju zabezpieczenia muszą mieć jednak moŜliwość odszyfrowania

wiadomości, aŜeby móc dalej ją przekierować. W efekcie zwiększa się liczba potencjalnych

miejsc do ataku, gdzie informacja pozostaje niezabezpieczona. Mechanizm ten powinien być

stosowany jedynie w przypadku, gdy poziom bezpieczeństwa oferowany przez WS-Security

jest niewystarczający.

4.11 Miejsce Parlay/OSA i Parlay X w architekturze IMS

Brama Parlay/OSA znajduje się w architekturze IMS w warstwie aplikacji i jest

traktowana jako jeden z rodzajów serwerów aplikacyjnych (AS). Zgodnie z nomenklaturą

IMS element ten nazywa się OSA Service Capability Server. OSA SCS moŜe wpływać na

zachowanie przebiegu sesji SIP komunikując się z S-CSCF po przez styk ISC (IP multimedia

Subsytem Service Control Interface). Styk ISC (patrz Rys. 22) powinien wspierać moŜliwość

rejestracji OSA SCS u S-CSCF w celu otrzymywania powiadomień o zachodzących

zdarzeniach (event notifications) w UAs (m.in. zmiana stanu zarejestrowanego UA, czy jest

zarejestrowany, jaką funkcjonalność posiada – kodeki, rodzaje mediów, jaką

charakterystykę56, etc.. określonych zgodnie z [27]). O tym, czy w obsłudze danego

zgłoszenia powinien uczestniczyć OSA SCS decyduje S-CSCF na podstawie IFC

przechowywanych w HSS. Wówczas kieruje on przychodzące Ŝądanie SIP do odpowiedniego

AS w tym przypadku OSA SCS (patrz rozdział 3). NaleŜy zaznaczyć, iŜ styk ISC nie

umoŜliwia autoryzacji i bezpieczeństwa pomiędzy trzecią OSA SCS, a S-CSCF. Poza tym styk

ISC powinien:

� zapewnić przesyłanie informacji na temat rozliczeń (patrz TS 32.240 [10] i TS 32.260

[11]);

� wykorzystywać protokół SIP (zdefiniowany w RFC 3261 [22]). Protokół SIP na

interfejsie ISC, powinien umoŜliwiać S-CSCF rozróŜnianie Ŝądań SIP realizowanych

na stykach Mw, Mm i Mg, a Ŝądaniami na ISC (patrz rozdział 3).

54 HyperText Transfer Protocol Secure – wykorzystuje mechanizm SSL (Secure Socket Layer) do zabezpieczenia danych na poziomie protokołu HTTP. Specyfikacja znajduje się w [31]. 55 Patrz rozdział 1. 56 Zgodnie z [27], charakterystyka (characteristic) jest to podobny zbiór funkcjonalności/moŜliwości, które posiada urządzenie (capabilities) z tym, Ŝe nie moŜna go negocjować.

Parlay/OSA oraz Parlay X

58

Analogicznie do Parlay/OSA na styku ISC wprowadza się równieŜ pojęcie „odnogi

SIP” („SIP leg”), która reprezentuje dialog rozumiany według RFC 3261. Pojęcie te

systematyzuje opis interakcji pomiędzy S-CSCF, a OSA SCS.

Aplikacja

Parlay X

OSASCS

AS

S-CSCF HSS

Parlay X (Web Services)

Parlay/OSA API

Sh

Cx

ISC

Rys. 22 Wycinek warstwy aplikacyjnej architektury IMS

OSA SCS posiada równieŜ bezpośredni styk o nazwie Sh z HSS (patrz Rys. 22).

Interfejs ten jest wewnętrznym interfejsem operatora i odpowiada za przekazywanie

informacji do OSA SCS zgodnie z ustaloną polityką. Informacje, które mogą być przesyłane

do OSA SCS to np.: dane potrzebne do realizacji danej usługi, informacje o uŜytkowniku,

MSISDN57, funkcjonalność wizytowanej sieci, informacja o lokalizacji uŜytkownika, dane

współdzielone z innymi aplikacjami jak np.: ksiąŜką adresowa, etc.. NaleŜy zaznaczyć, Ŝe

dane na tym styku przekazywane są w sposób przeźroczysty, co oznacza, Ŝe HSS nie

dokonuje ich przetwarzania, czy interpretacji. OSA SCS moŜe otrzymać równieŜ uprawnienia

pozwalające na aktywację/dezaktywację swoich iFC.

Architektura IMS nie definiuje styku pomiędzy Parlay X, a OSA SCS. Funkcjonalność,

jaką powinien posiadać ten styk opisują dokumenty, w których przedstawiono moŜliwe

sposoby mapowania OSA SCS na Parlay X (patrz [18]). Styk pomiędzy Parlay X, a aplikacją

został zdefiniowany w specyfikacji Parlay X (patrz [18]).

57 Mobile Subscriber ISDN – numer abonenta sieci komórkowej.

Parlay/OSA oraz Parlay X

59

W stworzonym środowisku badawczym zrezygnowano z implementacji interfejsów

Bramy Parlay X na OSA SCS, co jest powszechnie przyjęta praktyką w branŜy

telekomunikacyjnej. Interfejsy te zostały zaimplementowane jako odrębne serwery

aplikacyjne (patrz Rys. 41), a na styku ISC uŜyty został protokół SIP z dodatkowymi

nagłówkami, które wymagane są do spełniania załoŜeń dla styku ISC zgodnie z TS 23.228 [4]

(patrz rozdział 1).

5. JAIN Service Logic Execution Environment

5.1 Inicjatywa JAIN58

Szybko rosnąca popularność języka Java, ze względu na jego charakterystyczne cechy,

tj. intuicyjny model programistyczny, przenośność, budowę komponentową (tzw. beans),

model zdarzeniowy wraz z rodząca się potrzebą otwarcia sieci, sprawiły Ŝe zaczęto prowadzić

prace nad moŜliwościami zastosowania Javy w telekomunikacji - Java Community Process59

powołał program JAIN60. Celem JAIN jest wyspecyfikowanie interfejsów programistycznych,

które będą stanowiły abstrakcję dla róŜnego rodzaju technik sieciowych i protokołów,

wspomagających i upraszczających proces tworzenia usług telekomunikacyjnych.

Architektura JAIN została przedstawiona na Rys. 23. JAIN Składa się z trzech warstw:

protokołów/sieci, sterowania sesją/połączeniem oraz usług. KaŜda z tych warstw wprowadza

pewien stopień abstrakcji. Im wyŜszy stopień abstrakcji tym funkcjonalność API

udostępniana przez daną warstwę jest bardziej ograniczona, ale jednocześnie wymagana jest

mniejsza wiedza. Ponadto dzięki takiemu podejściu aplikacja jest niezaleŜna od sposobu

implementacji warstwy niŜszej. Np. na poziomie warstwy protokołów aplikacja jest

niezaleŜna od konkretnej implementacji protokołu dostarczonej przez producenta urządzeń

sieciowych. W warstwie protokołów specyfikowane są API dla kaŜdego z protokołu z osobna

(np. JAIN SIP API dla protokołu SIP, etc..). Za pomocą tego API programista ma dostęp do

pełnej funkcjonalności oferowanej przez dany protokół. WiąŜe się to z koniecznością

posiadania wiedzy na temat mechanizmów protokołu.

Warstwa sterowania połączeniem/sesją uogólnia mechanizmy wykorzystywane przez

poszczególne protokoły. JAIN Call Control and JAIN Coordination and Transaction API

oferuje jednakowy model zgłoszenia (call model) dla róŜnych rodzajów sieci (ATM, PSTN,

58 Początkowo nazwą inicjatywy było Java API for Intelligent Network. Nazwa została zmieniona ze względu na to, Ŝe JAIN zaczął obejmować inne protokoły i techniki poza Intelligent Network. 59 Java Community Process został powołany przez Sun Microsystem (1998) w celu sformalizowania procesu specyfikacji nowych rozszerzeń i zastosowań Javy. W procesie tym mogą być zaangaŜowane strony trzecie zainteresowane tworzeniem standardów w zakresie języka Javy. Wydawane standardy noszą nazwę Java Specification Request (JSR). 60 W ramach JAIN istnieją 2 grupy eksperckie: Application Expert Group (AEG) oraz Protocol Expert Group (PEG). PEG przygotowuje standardy na poziomie protokołów sygnalizacyjnych w sieciach IP, stacjonarnych i mobilnych. AEG zajmuje się problemem bezpiecznego dostępu do sieci operatora (JAIN Parlay), specyfikuje model zarządzaniem połączeniami (JCC, JCAT) oraz środowisko do kreacji usług.

JAIN Service Logic Execution Environment

61

GSM, etc..). Model zgłoszenia reprezentuje maszynę stanów, do której dostęp realizowany

jest przez JCC/JCAT API. Przy tworzeniu aplikacji na tym poziomie programista nie musi

znać szczegółów odnoszących się do poszczególnych sieci, gdyŜ korzysta z generycznych

funkcji tj. jak wysłanie wiadomości, zestawienie połączenia, etc..

W centrum architektury JAIN znajduje się środowisko wykonawcze dla usług tzw.

Service Logic Execution Environment. SLEE definiuje jednakowy model programistyczny dla

aplikacji sterowanych zdarzeniami oraz kontener, który oferuje szereg standardowych

funkcjonalności (mechanizm transakcji, mechanizm kierowania zdarzeń, zarządzania

aplikacją, etc..). Dzięki temu programista moŜe skupić się wyłączenie na implementacji logiki

aplikacji. Szczegółowa analiza tego środowiska zostanie popełniona w dalszej części tej

pracy.

JAIN Service Logic Exectuion Environment

(JSLEE)

JAIN Call Control (JCC)

and JAIN Coordination and Transactions (JCAT)

TCAP ISUP INAP SIP MAP MAP

Security InterfaceJAIN Service Provider

Aplikacje niezaufane tworzone

przez „trzecią stronę”

JAIN Service Creation

Environment

(JSCE)

Aplikacje zaufane tworzone

przez „trzecią stronę”

Service APIs

Call Control/Session API

Protocol/Connection API

Sygnalizacja

Sieć

Usługi

Rys. 23: Architektura JAIN

Warstwa sterowania sesją i warstwa protokołów znajdują się w domenie operatora,

który jest obszarem bezpiecznym (patrz Rys. 23). Idea JAIN przewiduje pełne otwarcie sieci

dla niezaleŜnych dostawców oprogramowania, dlatego dodatkowo definiuje interfejsy w

warstwie usług dla aplikacji zaufanych (JAIN Service Provider) i niezaufanych (Security

Interface). Standaryzacja tych interfejsów przebiega jednak bardzo wolno, poniewaŜ

operatorzy do pełnego otwarcia swoich sieci chcą stosować inne techniki tj. Parlay/OSA, a do

ich implementacji wystarczające są API z niŜszych warstw architektury JAIN.

JAIN Service Logic Execution Environment

62

5.2 Definicja JSLEE, wymagania dla JSLEE

JSLEE, czyli JAIN Service Logic Execution Environment jest serwerem aplikacyjnym i

centralną częścią programu JAIN prowadzonego w ramach JCP, a jego specyfikacja (JSLEE

1.0) została zawarta w dokumencie JSR 22 (Java Specification Request). Aktualnie

prowadzone są prace nad JSLEE 1.1 w grupie JSR 240.

Serwer aplikacyjny jest kontenerem61, który oferuje środowisko wykonawcze (Run

Time Environment) dla aplikacji reprezentujących usługi. Jest to środowisko komponentowe,

które pozwala na wykorzystanie wcześniej stworzonych komponentów w ramach tej samej

lub innej aplikacji. Np. w JSLEE komponenty, to tzw. SBB – Service Building Block62.

JSLEE wykorzystuje język Java, który zapewnia przenośność i obiektowość aplikacji.

Główne koncepcje wykorzystane przy projektowaniu kontenera JSLEE bazują na specyfikacji

J2EE63, a jako przykład moŜe posłuŜyć uŜyta technika JMX64 (Java Management Extension)

do zarządzania kontenerem. Poza tym JSLEE wspiera takŜe inne interfejsy Javy m. in. J2SE,

JNDI, JAXP65, dzięki czemu te dwa środowiska moŜna bez większych trudności integrować.

Kontener dostarczany przez JSLEE znacznie się róŜni od kontenera J2EE. Kontener

JSLEE wspiera przede wszystkim aplikacje sterowane zdarzeniami (message driven

application), co jest uwarunkowane koniecznością obsłuŜenia komunikacji asynchronicznej

charakterystycznej dla aplikacji telekomunikacyjnych. Dodatkowo musi spełniać inne

wymagania stawiane przez środowisko telekomunikacyjne. Dlatego teŜ został zaprojektowany

w taki sposób, aby obsłuŜyć bardzo duŜo prostych transakcji opartych na zdarzeniach w

czasie rzeczywistym oraz zapewnić Ŝądaną bezawaryjność pracy. PoniŜej zostały

wylistowane wymagania, które uwzględnia specyfikacja JSLEE.

61 Kontener jest to podstawowy element architektury, w którym instalowane są aplikacje (inne komponenty). Jest obiektem, który oddziałuje bezpośrednio z niskopoziomową funkcjonalnością charakterystyczną dla danej platformy. Eksponuje ją dla komponentów w nim umieszczonych w postaci API do usług tj. transakcje, bezpieczeństwo, wyszukiwanie zarejestrowanych obiektów za pomocą ich nazwy, itp.. Zarządza cyklem Ŝycia komponentów. 62 Szczegółowy SBB opis zostanie podany w rozdziale5.5.5. 63 Java 2 Platform, Enterprise Edition jest to standard stworzony przez JCP do tworzenia aplikacji rozproszonych, opartych o architekturę wielowarstwową. Wykorzystuje język Java oraz definiuje model aplikacji i środowiska wykonawczego tzw. kontener. Zdefiniowany został w JSR 151[36]. 64 Java Management Extensions jest to technika, która umoŜliwia zarządzanie i monitorowanie aplikacji sieciowych. Dane zasoby reprezentowane są przez obiekty MBean (Manager Bean). Ciekawym rozwiązaniem jest moŜliwość dynamicznego ładowania i inicjalizowania klas. 65 Chodzi o wszystkie zgodność z bibliotekami dla Java 2 Platform Edition, Java Naming Directory Index, Java API for XML Processing. Specyfikacje tych technik moŜna znaleźć na stronie Sun Microsystems.

JAIN Service Logic Execution Environment

63

� Asynchroniczność, przetwarzanie zorientowane na zdarzenia. Komponenty

rejestrują się poprzez mechanizm publish/subscribe66 w źródłach zdarzeń w celu

odbierania zdarzeń, którymi są zainteresowane. Mechanizm ten jest wbudowany

takŜe w kontener i wspiera mechanizm elastycznego filtrowania i przekazywania

zdarzeń z określonymi priorytetami.

� Krótki czas reakcji i duŜa przepustowość. Czasy odpowiedzi powinny być krótsze

niŜ 200 ms oraz JSLEE powinien wspierać przetwarzanie równoczesne duŜej liczby

prostych zdarzeń i prostych transakcji.

� DuŜa niezawodność. Zgodnie ze standardami telekomunikacyjnymi powinna być

zagwarantowana bezawaryjność na poziomie 99.999%. Sposobem na jej osiągnięcie

jest replikacja stanów i wykorzystanie grup serwerów.

� Łatwość integracji z innymi systemami. NiezaleŜność od sieci. JSLEE wprowadza

koncepcje Resource Adapters, które stanowią źródła i ujścia dla zdarzeń

pochodzących z innych systemów. Takie podejście sprawia, Ŝe dołoŜenie nowego

elementu sieci, czy teŜ konieczność obsłuŜenia innego protokołu nie będzie

wymagało modyfikacji środowiska, w którym działają usługi.

� Przenośność. Aplikacje tworzone w środowisku JSLEE są niezaleŜne od konkretnego

rozwiązania sprzętowego i systemu operacyjnego. W związku z tym kod aplikacji

nie wymaga modyfikacji w przypadku przenoszenia z jednego środowiska do innego.

Aplikacje są odizolowane od architektury sprzętowej i systemu poprzez

wykorzystanie wirtualnej maszyny Javy.

� Wbudowany mechanizm zarządzania. JSLEE oferuje mechanizm zarządzania w

postaci JMX oraz zbiór narzędzi takich jak: źródło czasu, alarmy, etc..

NaleŜy zaznaczyć, Ŝe specyfikacja JSLEE definiuje jedynie architekturę i mechanizmy,

przy czym nie narzuca konkretnych rozwiązań implementacyjnych. Dlatego implementacje

JSLEE67 mogą znacząco się róŜnić pomiędzy sobą w zakresie wydajności oraz sposobie

działania poszczególnych mechanizmów.

66 Mechanizm publish/subscribe zaprojektowany został do realizacji komunikacji asynchronicznej. Nie naleŜy go mylić z mechanizmem komunikacji asynchronicznej lister/provider wykorzystywanym w Javie. 67 Istniejące implementacje referencyjne JSLEE zostaną omówione w rozdziale 1.

JAIN Service Logic Execution Environment

64

5.3 Porównanie technik J2EE i JSLEE

JSLEE czerpie z rozwiązań stworzonych dla J2EE. Jako przykład moŜna podać kilka

analogii w obydwu architekturach. W jednym i w drugim rozwiązaniu jest to architektura

komponentowa. W J2EE komponenty nazywają się Enterprise Java Beans68 tzw. EJBs,

natomiast w JSLEE SSBs. Poza tym JSLEE wykorzystuje szereg mechanizmów z J2EE np.:

mechanizm do zarządzania i monitorowania aplikacji - Java Management Extension, czy

JNDI wykorzystywany do rejestrowania i wyszukiwania obiektów na podstawie ich nazwy.

Powstaje zatem pytanie, dlaczego potrzebny jest nowy kontener? Czy J2EE nie mógłby zostać

wykorzystany równieŜ dla celów telekomunikacyjnych? OtóŜ nie do końca.

Tab. 2: Porównanie pomiędzy rozwiązaniami IT uŜywanymi w sieciach prywatnych/wydzielonych, a

systemami telekomunikacyjnymi.

Systemy Telekomunikacyjne Systemy IT

Wywołania Głównie asynchroniczne, (zdarzenia są generowane z róŜnych sieci wykorzystujących róŜne protokoły)

Głównie synchroniczne (wywołania funkcji, bazy danych)

Poziom ziarnistości zdarzeń

Bardzo duŜa częstotliwość, zdarzenia są bardzo proste (odwzorowują wiadomości protokołów)

Mała częstotliwość, zdarzenia przenoszą duŜą ilość informacji (dane z baz danych)

Komponenty Lekkie komponenty, oferujące skromną funkcjonalność. DuŜa liczba kreacji i usuwania komponentów

CięŜkie komponenty, realizują zawansowane zadania związane np. z przetwarzaniem zapytań do baz danych. Mogą istnieć przez długi czas na dysku np. komponenty trwałe (persistient)

Źródła danych Wiele źródeł danych (np. róŜne protokoły, bazy danych)

Głównie serwery bazodanowe

Transakcje Proste transakcje ZłoŜone transakcje

Obliczenia DuŜa liczba drobnych obliczeń ZłoŜone obliczenia, przetwarzanie duŜych zapytań do baz danych.

Dostępność 99,999% 99%

Czas rzeczywisty

TAK NIE koniecznie

Rozmieszczenie Rozproszone w sieci (częściowo mobilnej)

Scentralizowane, bazy danych znajdują się w jednym miejscu

68 Enterprise Java Bean jest zarządzanym, znajdującym się po stronie serwera komponentem, który wykorzystywany jest do budowy modularnych aplikacji. Specyfikacja EJB znajduje się w JSR 220.

JAIN Service Logic Execution Environment

65

Węzły od 1 do 4 CPUs na węzeł od 2 do 32 CPUs na węzeł

Grupy węzłów DuŜe. Od 2 do 16 węzłów Od 2 do 4 węzłów

W Tab. 2 porównano cechy, systemów telekomunikacyjnych oraz systemów IT tzw.

enterprise wykorzystywanych w sieciach wydzielonych. Reprezentantem tego drugiego

rodzaju systemów jest m.in. platforma J2EE. Systemy telekomunikacyjne mają odmienne

wymagania w odróŜnieniu od systemów IT. Podstawową róŜnica pomiędzy tymi dwoma

typami systemów jest sposób komunikowania się oraz charakter pracy komponentów. W

systemach IT komunikacja odbywa się w sposób synchroniczny. Wynika to m. in. z faktu, Ŝe

w systemach tych wykorzystywany jest proceduralny model programowania. Polega on na

tym, Ŝe po wywołaniu określonej funkcji następuje natychmiastowa odpowiedź. Zaletą

zachowania synchroniczności wywołań jest łatwość tworzenia spójnego oprogramowania

(proces projektowania i debugowania aplikacji). W przypadku próby zastosowania tego

paradygmatu w systemach telekomunikacyjnych spowodowałoby to nieefektywne

wykorzystanie zasobów.

Elementy systemów telekomunikacyjnych komunikują się ze sobą asynchronicznie, co

moŜe zostać zaprezentowane na przykładzie zbioru węzłów sygnalizacyjnych

przetwarzających wiadomości protokołu SIP (patrz Rys. 24). Wysłanie przez UAC

wiadomości INVITE do pierwszego węzła (SIP PROXY A) powoduje odpowiednie jej

przetworzenie i/albo odpowiedź np.: z komunikatem 304 albo przekazanie do kolejnego

SIP PROXY B. Jak moŜna się domyślić odpowiedź od SIP PROXY B moŜe przyjść w

dowolnym momencie (czas potrzebny na przetworzenie, dowolnie późna odpowiedź UAC po

stronie SIP PROXY B) lub w przypadku awarii UAC B SIP PROXY A moŜe nie otrzymać

Ŝadnej wiadomości zwrotnej. Jeśli zostałby uŜyty synchroniczny sposób komunikacji,

wówczas wywołanie funkcji, która realizuje wysłanie wiadomość INVITE zablokowałoby

kolejno zasoby UAC A, SIP PROXY A SIP PROXY B na czas do momentu uzyskania

odpowiedzi, która de facto moŜe nie nadejść. W przypadku sygnalizacji i systemów

rozproszonych nie mamy wiedzy o stanie węzłów znajdujących się dalej niŜ sąsiednie.

Oczywiście w takim przypadku moŜna zdefiniować odpowiednie czasy oczekiwania (time

out), po upłynięciu, których system uzna proces za zakończony. MoŜna równieŜ umieścić

kolejne wywołania funkcji w osobnych wątkach. Nie unikniemy jednak blokady i

marnotrawienia zasobów.

JAIN Service Logic Execution Environment

66

Oczekiwanie na odpowiedź

Oczekiwanie na odpowiedź

Oczekiwanie na odpowiedź

Rys. 24: Mechanizm komunikacji synchronicznej

Rozwiązaniem tego problemu jest zastosowanie komunikacji asynchronicznej, która

odzwierciedla naturalne zachowanie się rozproszonej architektury węzłów sygnalizacyjnych.

Koncepcja ta wyraŜa się w architekturze zdarzeniowej, w której główną rolę odgrywają

zdarzenia (events). Zdarzenia są nośnikiem informacji pomiędzy komponentami. Wysłanie

zdarzenia nie powoduje zajęcia zasobów, do czasu uzyskania odpowiedzi, gdyŜ system nie

oczekuje na natychmiastową odpowiedź. Odpowiedź ta moŜe nadejść w dowolnym

momencie. Komponenty te są ze sobą luźno powiązane (loosely coupled) w związku z czym

łatwo moŜna tworzyć rozproszone systemy oraz efektywnie wykorzystywać zasoby.

Architektura J2EE równieŜ oferuje asynchroniczny sposób komunikacji realizowany

przez mechanizm JMS (Java Message Service)69 wraz z modelem publish/subscribe. Jest to

jednak mechanizm zewnętrzny, który nie zapewnia komunikacji przy wykorzystaniu zdarzeń

pochodzących z wnętrza kontenera, co powoduje, Ŝe komunikacja pomiędzy komponentami

musi być synchroniczna. JMS uniemoŜliwia równieŜ dynamiczne tworzenie nowych kolejek

wiadomości (miejsc, w których gromadzone są i obsługiwane przychodzące asynchronicznie

wiadomości) oraz dynamiczną aktualizację mechanizmu kierowania zdarzeń z poziomu

aplikacji.

Oprócz tego istnieje zasadnicza róŜnica dotycząca charakteru zdarzeń, które musi

przetworzyć system telekomunikacyjny.Przede wszystkim w porównaniu do systemów IT jest

69 Java Message Service jest tzw. Java Message Oriented Middleware (MOM) API słuŜące do wysyłania widomości pomiędzy dwoma lub większą liczbą klientów. JMS został wyspecyfikowany w JSR 914

JAIN Service Logic Execution Environment

67

to duŜa liczba prostych obiektów, które muszą zostać przetworzone w czasie rzeczywistym.

Kontener J2EE nie nadaje się do realizacji tego zadania, poniewaŜ jest zbyt „cięŜki” 70.

Kolejną róŜnicą między JSLEE, a J2EE jest sposób komunikacji ze światem

zewnętrznym rozumiany jako dostęp do róŜnego rodzaju zasobów. Dla J2EE głównym

źródłem danych jest serwer bazodanowy natomiast dla JSLEE jest to szereg róŜnych

protokołów oraz baz danych. Dzięki koncepcji aplikacji sterowanych zdarzeniami, JSLEE

zapewnia ujednolicony sposób komunikacji z róŜnymi typami sieci oraz elementami

architektury.

Inne cechy posiadają równieŜ komponenty obydwu systemów. EJB posiadają

przewaŜnie zaawansowaną funkcjonalność, która słuŜy głownie do przetwarzania danych

pobranych z bazy danych. Dlatego są to tzw. cięŜkie komponenty o długim czasie Ŝycia

(persistent). Natomiast komponenty SBB słuŜą do przetwarzania duŜej liczby małych i

prostych porcji danych, które najczęściej reprezentują wiadomości danego protokołu. W

związku z tym komponenty tego typu kreowane i niszczone są bardzo często.

Istotnym mechanizmem zabezpieczającym komunikację (gwarantującym: atomowość,

spójność, izolację, trwałość71) są transakcje. Charakter transakcji uzaleŜniony jest oczywiście

w duŜej mierze od danych, które zabezpiecza. I tak dla JSLEE występuje wiele prostych

transakcji, natomiast J2EE charakteryzuje się długimi i złoŜonymi transakcjami

(zabezpieczenie duŜych porcji danych pochodzących z długo trwających transakcji).

Jeśli chodzi o aspekt niezawodności, to w przypadku systemów telekomunikacyjnych

wymagana jest bardzo wysoka bezawaryjność rzędu 99,999%. Natomiast w przypadku

systemów IT wystarczający poziom bezawaryjności jest na poziomie 99%.

5.4 Porównanie technik JSLEE i SIP Servlet

Servlety są techniką do tworzenia aplikacji sieciowych potocznie zwanych webowymi72

w języku Java i wykonywane są poprzez serwer aplikacji w specjalnie do tego

70 Rozbudowana funkcjonalność kontenera J2EE, która nie jest konieczna do budowy SBB natomiast ma duŜy wpływ na wydajność (np. Java Persistence API, etc..). 71 Atomizm, spójność, izolacja, trwałość tzw. ACID: Atomicity, Consistency, Isolation, Durability są podstawowymi cechami, którymi musi się charakteryzować transakcja. 72 Aplikacje webowe rozumiane są szeroko, tzn. nie tylko jako programy do generowania stron HTML.

JAIN Service Logic Execution Environment

68

przeznaczonym kontenerze. Zostały zdefiniowane przez Java Community Process w

specyfikacji JSR 154 [37] na potrzeby platformy J2EE.

Zasada działania oraz struktura klas servletów została przedstawiona na Rys. 25.

Komunikacja z servletem, ze względu na jego pierwotne przeznaczanie73 realizowana jest z

wykorzystaniem protokołu HTTP. Przeglądarka generuje Ŝądanie do serwera aplikacyjnego, a

serwer aplikacyjny na jego podstawie wybiera odpowiedni kontener, w którym umieszczony

został servlet. Program korzystając z HTTPServlet API moŜe dokonać analizy Ŝądania i

wygenerować dokument HTML, który zostanie odesłany do przeglądarki.

Rys. 25: Zasada działania servletów oraz struktura klas słuŜących do jego budowy

Technika Servletów w zamierzeniu nie była projektowana wyłączenie do aplikacji

wykorzystujących protokół HTTP. Ze względu na wiele podobieństw protokołów HTTP i SIP

model programistyczny servletów został w łatwy sposób zaadoptowany do tworzenia

aplikacji bazujących na protokole SIP. Wystarczy skorzystać z mechanizmu dziedziczenia i z

klasy GenericServlet wyprowadzić API dla protokołu SIP (SIPServlet, patrz Rys. 25).

Zasada działania servletów pozostaje wówczas taka sama, a na Rys. 25 naleŜy jedynie

zastąpić protokół HTTP protokołem SIP.

Model programistyczny, który oferuje technika servletów jest stosunkowo łatwy i

pozwala szybko budować aplikacje74. Jednak kontener dla Servletów posiada szereg

ograniczeń, które uniemoŜliwiają spełnienie kilku istotnych załoŜeń koniecznych do

73 Technika servletów zostały pierwotnie stworzona na potrzeby budowania dynamicznie generowanych stron HTML. 74 W specyfikacji SIP Servlet moŜna przeczytać „Emphasis is on simplicity and minimality rather than completeness”.

JAIN Service Logic Execution Environment

69

tworzenia zawansowanych aplikacji telekomunikacyjnych. Ograniczenia te zostaną

omówione w następujących kategoriach:

� Architektura aplikacji . Servlety wykorzystywane są do prostych zadań. Brak w tym

przypadku modularyzacji na poziomie funkcjonalnym. W JSLEE takimi modułami

są SBB. Servlety w swoim załoŜeniu przeznaczone są do obsługi konkretnego

protokołu. Jeśli chcielibyśmy obsłuŜyć jednocześnie inny protokół musielibyśmy

dziedziczyć po innej klasie, a Ŝe w Java nie zapewnia wielokrotnego dziedziczenia,

tak więc moŜna wykorzystać tylko jeden protokół w ramach konkretnego servletu.

� Stanowość aplikacji . Servlety zostały zaprojektowane głównie do obsługi protokołu

HTTP, który jest z zasady protokołem bezstanowym. Utrzymanie stanu w servletach

wiąŜe się z przechowywaniem informacji o nim w ramach sesji jako para ciąg

znaków-obiekt. Komponenty SSB w JSLEE mogą być zarówno stanowe jak i

bezstanowe. Stan ich utrzymywany jest w ramach transakcji, co gwarantuje

bezpieczeństwo powrócenia do ostatniego poprawnego stanu w przypadku

wystąpienia jakiegokolwiek błędu.

� Sterowanie dostępem do zasobów (problem hazardu). W Servletach brak jest

mechanizmu transakcji. AŜeby uniknąć efektu hazardu naleŜy korzystać z

mechanizmu monitorów. JSLEE oferuje standardowo transakcje, które izolują

poszczególne procesy.

� Funkcjonalność dostępna dla aplikacji. JSLEE oferuje znaczenie szerszy zbiór

funkcjonalności przydatnych w tworzeniu aplikacji telekomunikacyjnych (patrz

5.5.2).

� Zarządzanie. W Servletach brakuje mechanizmu do zarządzania. JSLEE oferuje

zestandaryzowany mechanizm JMX, udostępniając szereg interfejsów, które

pozwalają zrządzać aplikacją, cyklem Ŝycia, etc..

Tab. 3: Porównanie technik JAIN SLEE i SIP Servlet.

SIP Servlety JAIN SLEE

Architektura aplikacji

Bazuje na Servletach HTTP;

Brak modelu standaryzacji dla budowy złoŜonych aplikacji i ponownego wykorzystania;

Bazuje na komponentach, architektura obiektowa;

Jednostką jest Service Building Block;

Ideą jest wspomaganie ponownego

JAIN Service Logic Execution Environment

70

wykorzystywania stworzonych wcześniej komponentów;

Stanowość aplikacji

Servlety są bezstanowe;

Współdzielony stan pomiędzy poszczególnymi wywołaniami Servletu jest przechowywany osobno jako para ciąg znaków i obiekt;

Współdzielony stan jest widoczny dla wszystkich Servletów, które mają dostęp do danej sesji;

SBB mogą być zarówno bezstanowe lub stanowe;

Stan SBB jest prywatny, przechowuje bezpieczne typy, utrzymywany w ramach transakcji i jest właściwością samego SBB;

Współdzielone stany mogą być przechowywane w oddzielnych Activity Context;

Dostęp do współdzielonych stanów moŜe być deklarowany w momencie rozmieszczenia SBB;

Sterowanie współzawodnictwem (hazard)

Zarządzenie z poziomu aplikacji np. Wykorzystanie mechanizmu monitorów w Javie;

Zarządzany przez system, np. izolacja na poziomie transakcji;

Protokół

SIP i HTTP; NiezaleŜne od protokołu;

MoŜe być rozszerzane o dodatkowe protokoły i zewnętrzne zasoby przy wykorzystaniu Resource Adaptors;

Spójny model zdarzeniowy, niezaleŜny od protokołu czy zasobów;

Generyczna funkcjonalność

Timer; Timer; Trace; Alarm; Profiles;

Dostępne mechanizmy

Stan zarządzany przez kontener (obiekt sesji), który moŜe być replikowany;

Brak mechanizmu transakcji dla przetwarzanych wiadomości SIP;

Stan nie jest utrzymywany w ramach transakcji;

Generyczna funkcjonalność nie jest dostępna w ramach transakcji;

Brak modelu dla obsługi błędów;

Stan zarządzany przez kontener (SBB CMP, Activity Context, etc..). Stan ten moŜe być replikowany;

Zdarzenia dostarczane w ramach transakcji;

Operacje dla stanu zarządzanego przez kontener utrzymane są w ramach transakcji;

Funkcjonalności, np. timer są dostępne w transakcji;

Dobrze zdefiniowany i zrozumiały model obsługi błędów po przez mechanizm transakcji;

Zarządzanie

JAIN Service Logic Execution Environment

71

Brak standardowego mechanizmu

Standardowy mechanizm do zarządzania - Java for Management Extensions;

NiezaleŜny od protokołu zarządzania;

Interfejs do zarządzania aplikacjami, włączając cykl Ŝycia, aktualizacje, profile, itp.;

Interfejs do zarządzania cyklem Ŝycia SLEE;

JSLEE jest duŜo bardziej zaawansowaną techniką niŜ SIP Servlety. Wynika to z tego, iŜ

SIP Servlety są jedynie modelem programistycznym natomiast JAIN SLEE oferuje coś

więcej, mianowicie środowisko do wykonywania aplikacji.

Ponadto JSLEE został zestandaryzowany równieŜ w celu osiągnięcia wysokiej

niezawodności, którą zapewniają jego mechanizmy programistyczne uodparniające aplikacje

na pojawiające się błędy.

5.5 Architektura JSLEE

W tym rozdziale zostaną omówione główne elementy i mechanizmy architektury

JSLEE na podstawie specyfikacji JSLEE w wersji 1.1.

Architektura JSLEE składa się z czterech elementów: Zarządzania (Management),

Szkieletu (Framework), Modelu Komponentowego (Component Model) i Adapterów do

zasobów (Resorce Adapters). Została ona przedstawiona Rys. 26.

Resource Adaptor Resource Adaptor Resource Adaptor

Interfejsy do zarządzania

usługami oraz SLEE

JAIN SLEE Agent JMXKontener

Service

Building

BlocksService

Building

Blocks

Service

Building

Blocks

Service

Building

Blocks

Timers

Alarms

Tracing

Aplikacja do zarządzania

JMX

AC Naming

Usage

JAIN API Inne API

Zasoby sieciowe

Rys. 26: Architektura JSLEE

JAIN Service Logic Execution Environment

72

5.5.1 Zarządzanie

Za zarządzanie w JSLEE odpowiedzialny jest mechanizm Java Management

Extension. Rozwiązanie to zostało wybrane m. in. ze względu na skalowalność, łatwość

integracji z innymi systemami zarządzania (np. po przez strony WWW) oraz względną

prostotę zaimplementowania go w samej platformie JSLEE (np. jako servlety, JSP75). Poza

tym JMX jest niezaleŜny od protokołów.

Zadania JMX w JSLEE są bardzo podobne jak w J2EE np.: zarządzanie środowiskiem

wykonawczym, instalacja, zarządzanie cyklem Ŝycia usług, zarządzanie dostępem usług do

danych po przez tzw. profile, etc..

Szczegółową funkcjonalność wyraŜają poniŜsze interfejsy pochodzące z pakietu

javax.slee.management .

� SleeManagementMBean

� DeploymentMBean;

� ServiceManagementMBean;

� ServiceUsageMBean;

� ProfileProvisioningMBean;

� AlarmMBean;

� TraceMBean;

� ResourceManagementMBean;

JMX umoŜliwia równieŜ zbudowanie przy pomocy MBeans graficznego interfejsu do

zarządzania, który ułatwia administrowanie całym system.

5.5.2 Framework

Framework oferuje bazową funkcjonalność (tzw. facilities) dla komponentów. Z tego

powodu budowa usług sprowadza się głównie do implementacji logiki w komponentach SBB,

przez co wytwarzanie usług staje się prostsze. Poza tym podstawowa funkcjonalność

dostarczana przez Framework czyni usługi niezaleŜnymi od konkretnej platformy.

Framework oferuje następującą funkcjonalność:

� Timer Facility;

75 Java Server Pages – technika umoŜliwiają tworzenie dynamicznych dokumentów HTML, XHTML, XML wykorzystaniem języka Java wplecionym w kod strony HTML.

JAIN Service Logic Execution Environment

73

� Alarm Facility;

� Trace Facility;

� Activity Context Naming Facility;

� Profile Facility;

� router zdarzeń.

Timer Facility

W zastosowaniach telekomunikacyjnych czas odgrywa waŜną rolę. Programista

aplikacji musi mieć narzędzie, które pozwoli np.: określić przedział czasu, za jaki dany

uŜytkownik powinien zostać rozliczony lub wyznaczyć moment, w którym dana usługa

powinna zostać wyłączona. Taką funkcjonalność dostarcza dla środowiska wykonawczego

Timer Facility.

Timer Facility zarządza równieŜ innymi typami źródeł czasu po przez interfejs

TimerFacility. MoŜe on takŜe generować zdarzenia zawierające informację o czasie tzw.

Timer Event.

Czasami jednak moŜe wystąpić problem z punktualnym dostarczeniem zdarzenia

czasowego. Na opóźnienie zdarzeń mogą mieć wpływ dwa czynniki:

� przeciąŜenie w danej chwili routera zdarzeń;

� ustawienie zbyt niskiego priorytetu w kolejce przechowującej zdarzenia docierające do

SBB.

Rozwiązanie dotyczące problemów opóźnień zdarzeń nie zostało zawarte w

specyfikacji JSLEE i nie jest trywialne. Jest to jedno z wielu zagadnień, którego rozwiązanie

pozostawiono w gestii programistów, a zastosowane podejście ma istotny wpływ na

wydajność działania serwera aplikacyjnego. Przy implementacji naleŜy liczyć się, Ŝe

minimalizacja i zapewnienie jednakowych opóźnień pochłania wiele zasobów, ze względu na

konieczność przechowywania m. in. informacji o ścieŜce kaŜdego zdarzenia.

Alarm Facility

Funkcjonalność alarmów wykorzystywana jest zarówno przez SBBs jak i Resource

Adaptors w celu informowania o stanie usługi JSLEE oraz zewnętrznych systemów

zarządzania. Interfejs Alarm Facility został zdefiniowany jako AlarmMBeanInterface .

Wszystkie alarmy zostają wysyłane przez AlarmMBean jako obiekty AlarmNotification .

JAIN Service Logic Execution Environment

74

SBBs i Resource Adoptors mają dostęp do Alarm Facility po przez obiekt

AlarmFacility , natomiast obiekt AlarmFacility implementuje AlarmFacilityInterface .

Trace Facility

Ta funkcjonalność Framework pozwala przekazywać informacje związane z logami

generowanymi w JSLEE.

Activity Context Naming Facility

Activity Context Naming Facility oferuje globalną przestrzeń nazw dla Acitivity

Contexts. Sposób działania jest podobny do mechanizmu JNDI z J2EE. SBB moŜe dla danego

Activity Context ustawić nazwę. Na podstawie tej nazwy konkretny Activity Conetxt moŜe być

wyszukiwany po przez inne SBB. W ten sposób SBBs mogą wymieniać po między sobą

wiadomości.

Profile Facility

Ta funkcjonalność pozwala SBB i Resorce Adapters wyszukiwać Ŝądane przez nie

profile (Profile) w tabeli profili (Profile Table).

Event Routing

Specyfikacja JSLEE definiuje w jaki sposób przekazywane są zdarzenia pomiędzy

komponentami. Definicja ta zapisana jest równieŜ w sformalizowany matematyczny sposób.

Ten sposób wymiany zdarzeń implementuje element logiczny tzw. router zdarzeń (Event

Router). MoŜna powiedzieć, Ŝe jest on rdzeniem JSLEE. Jego miejsce w architekturze JSLEE

i interakcje z innymi elementami JSLEE przedstawia poglądowo Rys. 27. Router zdarzeń

odbiera przychodzące zdarzeń z Resource Adapters i przekierowuje je dalej do

zainteresowanych tymi zdarzeni SBB, jak i równieŜ w przeciwną stronę od SBB do Resource

Adapter.

JAIN Service Logic Execution Environment

75

Rys. 27: Mechanizm przekazywania zdarzeń w JSLEE - router zdarzeń

5.5.3 Model Komponentowy w architekturze JSLEE

Model komponentowy określa budowę zorientowanych zdarzeniowo aplikacji jak zbiór

komponentów, jak i równieŜ interakcje pomiędzy komponentami oraz pomiędzy

komponentami, a kontenerem.

� Aplikacje JSLEE składają się z:

� Service Building Blocks (SBB);

� Zdarzeń (Events) oraz typów zdarzeń (Event Type);

� Activity, Activity Object i Activity Context;

� Profili (Profiles), Tabeli Profili (Profile Table) i specyfikacji profili (Profile

Specyfication).

Model komponentowy opisuje równieŜ sposób konfiguracji aplikacji po przez tzw.

Deyployment Descriptor. Na Rys. 28 przedstawiono zaleŜności pomiędzy poszczególnymi

elementami modelu komponentowego.

Konten

er

Rys. 28: Główne elementy JSLEE i powiązania pomiędzy nimi

JAIN Service Logic Execution Environment

76

5.5.4 Service Building Block - SSB

SBB, czyli Service Building Block jest podstawowym komponentem, który zwiera cześć

logiki aplikacji. Jest bardzo podobny do Enterprise Java Beans (EJBs) m. in. ze względu na

cykl Ŝyciowy usługi, który kontrolowany jest przez środowisko wykonawcze. Środowisko

wykonawcze, a więc kontener zarządza przetwarzaniem zdarzeń i zapewnia poprawność tego

procesu uŜywając mechanizmu transakcji.

Rys. 29: Budowa Service Building Block (SBB). Wymagane interfejsy klasy abstrakcyjnej

Klasa abstrakcyjna SBB, która została przedstawiona poglądowo na Rys. 29 musi

definiować następujące elementy:

� typy odbieranych i generowanych zdarzeń po przez SBB;

� handlers, czyli funkcje, które są wołane do obsługi przychodzących zdarzeń;

� funkcje lokalne interfejsu SBB;

� graf SBB oraz drzewo instancji SBB;

� wspólne dane, czyli profile.

5.5.5 Drzewo SBB

KaŜda usługa składa się z jednego lub więcej instancji SBB róŜnych typów i moŜe

zostać przedstawiona jako drzewo. Jednostki SBB (SBB Entity) są instancjami komponentów

SBB. Oczywiście kaŜde SBB moŜe być wielokrotnie wykorzystane w innych usługach.

Poszczególne SBB są węzłami w drzewie (patrz Rys. 30), a pomiędzy nimi znajduje się

krawędź z etykietą określającą priorytet dostarczenia zdarzenia kolejnemu SBB w hierarchii.

W drzewie musi równieŜ zostać zdefiniowany tzw. Root-SBB. Root-SBB jest jedyną

jednostką SBB, która moŜe zostać wytworzona przez SLEE. Np. na Rys. 30 dane są trzy SBB

JAIN Service Logic Execution Environment

77

X1, X2, Z2 będące Root-SBB. Konkretne jednostki SBB mogą naleŜeć tylko do jednego

drzewa.

Rys. 30: Drzewo SBB Entity (źródło JSR 240)

Specyfikacja JSLEE podaje przykład ułatwiający zrozumienie interpretacji drzewa

SBBs. Usługa Call Blocking and Call Forwarding reprezentowana jest przez jednostkę Root-

SBB nazwaną CallBlockingAndCallForwarding. SLEE moŜe inicjować tą usługę poprzez

stworzenie instancji Root-SBB tej usługi w wyniku przyjścia zdarzenia sygnalizującego

pojawienia się rozmowy telefonicznej. W zaleŜności od stanu usługi Root-SBB moŜe tworzyć

instancje CallBlockingSBB lub CallForwardingSBB. AŜeby usługa mogła obsłuŜyć więcej niŜ

jedno połączenie JSLEE moŜe wykreować więcej instancji CallBlocking-SBB.

Graf SBB

Konkretne drzewo SBB jest instancją grafu SBB. Przykładowy graf pokazany został na

Rys. 31. Na podstawie grafu z rysunku zostało zbudowane jedno z kliku moŜliwych drzew

SBB (patrz Rys. 30). W grafie został równieŜ zaznaczony SLEE jako „ojciec” dla wszystkich

Root-SBB oraz wartości priorytetów dla przekazywanych zdarzeń od Root-SBB w dół drzewa.

Funkcje lokalnego interfejsu SBB

KaŜdy SBB moŜe implementować lokalny interfejs. Lokalny interfejs jest konkretnym

interfejsem, który zostaje dostarczony przez twórcę usługi np.: funkcja void hello(...) z

Rys. 29. Interfejs ten musi rozszerzać SbbLocalObject Interfeace . Obiekty SBB mogą

wzajemnie uŜywać swoich interfejsów, a więc wywoływać funkcje synchronicznie.

JAIN Service Logic Execution Environment

78

Obiekt SBB (SBB Object) reprezentuje konkretną jednostkę SBB (SBB Entity). Obiekt

SBB moŜe wołać inny Obiekt SBB poprzez lokalny interfejs naleŜący do tego samego drzewa

jednostek SBB.

Rys. 31: Graf SBB (źródło JSR 240)

5.5.6 Activity, Activity Context

Zdarzenia, które mają podobne znaczenie grupowane są w tzw. Activity. Tak więc

moŜna obrazowo powiedzieć, iŜ Activity jest strumieniem powiązanych ze sobą znaczeniowo

zdarzeń. Activity reprezentuje określoną jednostkę SBB (SBB Entity), która jest

zainteresowana konkretnym zdarzeniem. Np. zgłoszenie (Call76) jest Activity. Activity Object

jest obiektem w znaczeniu języka Javy (dziedziczy z typu java.Object) reprezentującym i

posiadającym funkcje, które mogą być wołane na Activity. Acitivity znajduje się w warstwie

Resource Adapters (patrz Rys. 32).

Przykładem obiektu Activity jest na przykład JccCall, który reprezentuje zgłoszenie.

JccCall naleŜy do specyfikacji JCC w programie JAIN.

Activity Context reprezentuje przyporządkowany jemu Activity i znajduje się w warstwie

SLEE. Relacja pomiędzy Activity i Activity Context jest jeden do jednego. Jedną z

funkcjonalności Activity Context jest przechowywanie danych w postaci atrybutów. Z pomocą

Activity Context jednostki SBB (SBB-Entity) mogą pomiędzy sobą wymieniać dane i

komunikować się asynchronicznie. Jednostka SBB moŜe być podłączona do wielu Activity

Context.

76 Obiekt Call pochodzi ze specyfikacji JAIN API.

JAIN Service Logic Execution Environment

79

JSLEE oferuje dla Komponentów mechanizm publish/subscribe. Komponenty mogą się

rejestrować przy pomocy tego mechanizmu w Activity Context, w celu odbierania

interesujących je zdarzeń. NaleŜy w tym miejscu zauwaŜyć, Ŝe mechanizm publish/subcribe

róŜni się od mechanizmu listner/provider udostępnianego w języku Java. W mechanizmie

listener/provider strony, które są wzajemnie zainteresowane odbieraniem i generowaniem

zdarzeń znają się, poniewaŜ Listner musi zarejestrować się u konkretnego Providera. W

JSLEE komponent generujący zdarzenia i komponent nasłuchujący przychodzących zdarzeń

nie znają się wzajemnie. KaŜdy z nich rejestruje się w Activity Context deklarując jedynie

chęć odbierania konkretnego typu zdarzeń. Dzięki opisanemu mechanizmowi swobodnego

wiązania dwóch komponentów za pomocą zdarzeń istnie moŜliwość tworzenia systemów

rozproszonych zorientowanych zdarzeniowo.

Rys. 32: Activity Context i Activity. ZaleŜności u umiejscowienie w architekturze JSLEE

Na Rys. 33 została zaprezentowana przykładowa ścieŜka jaką przebywa zdarzenie w

architekturze JSLEE przy zestawianiu sesji komunikacyjnej SIP.

Wiadomość INVITE zostaje wygenerowana przez sieć i następnie zostaje

przechwycona przez SIP-Resource Adapter (SIP-RA). PoniewaŜ INVITE jest pierwszą

wiadomością w sekwencji zestawiania połączenia dla protokołu SIP, zostaje wytworzony

Activity Obiekt przez SIP-RA. SIP-RA przekazuje dalej zdarzenie związane z wiadomością

INVITE do routera zdarzeń. Router zdarzeń powołuje do Ŝycia Activity Context ze względu

na to, Ŝe jest pierwszy we wspomnianej sekwencji. Zdarzenie zostaje odebrane przez

zainteresowany nim SBB, który wcześniej zarejestrował się przy wykorzystaniu

ActivityContextInterface w Activity Context. SBB przetwarza zdarzenie zgodnie z

zaimplementowaną logiką, a następnie woła metodę SIP-RA z parametrem będącym

zdarzeniem-odpowiedzią. SIP-RA generuje następnie wiadomość „OK” do sieci.

JAIN Service Logic Execution Environment

80

Rys. 33: Przykładowa droga zdarzenia w JSLEE

5.5.7 Zdarzenia

Pojęcie zdarzenia jest jednym z istotniejszych w architekturze SLEE. Zdarzenie to

obiekt, który przenosi pewną informację z jednego elementu do innego znajdującego się w

SLEE. Jednym elementem, który moŜe zarówno generować jak i odpowiadać na zdarzenia

jest SBB, pozostałe komponenty jak Facility, Resource Adapters generują jedynie zdarzenia.

KaŜde zdarzenie jest reprezentowane przez Event Object - obiekt w znaczeniu języka

Java i posiada określony typ. Typ determinuje sposób przekazywania zdarzenia. SBB

rejestrują typy zdarzeń, którymi są zainteresowane po przez podłączenie się do

odpowiedniego Activity Context.

Zdarzenia są odbierane przez SBB i uruchomiają odpowiednie funkcje tzw. Handlers.

5.5.8 Profile, Tabele Profili i Specyfikacje Profili

Profile (Profile) udostępniają dane przechowywane w postaci atrybutów. W schemacie

profili określa się zbiór atrybutów i ich typy. Tabele Profili (Profile Table) natomiast

zawierają profile, które przynaleŜą do tego samego schematu. Specyfikacje Profili (Profile

Specification) definiują Interfejsy, zbiory klas i deskryptory rozmieszczenia (Deployment

Descriptors). Specyfikacje Profili moŜna określić jako typy, które mogą być wykorzystywane

przez wiele Tabeli Profili.

JAIN Service Logic Execution Environment

81

W JSLEE został juŜ zdefiniowany zbiór bazowych specyfikacji profili. Przykładową

specyfikacją profilu jest np.: „Resource Info Profile Specification“.

Eys. 34: ZaleŜności pomiędzy Specyfikacjami Profili, Tablicami Profili i Pro filami

5.5.9 Resource Adapters

Resource Adapters (RAs) jest kolejną koncepcją, która podobnie jak zdarzenia,

uniezaleŜnia SLEE od konkretnego protokołu sygnalizacyjnego, zbioru danych, urządzenia.

JSLEE moŜe dysponować dowolną liczbą RA i to jest istotna zaleta. Jeśli wystąpi potrzeba,

aŜeby JSLEE komunikował się z inną siecią naleŜy dopisać i zainstalować odpowiedni RA.

RAs konwertują specyficzne dla danego źródła wiadomości na określone typy zdarzeń i dalej

przekazują je do wszystkich zainteresowanych SBB. Zatem RA jest elementem, który

powinien być dostarczany przez dostawcę (providera) danego urządzenia, protokołu, zbioru

danych, poniewaŜ zna on najlepiej specyfikę swoich rozwiązań. Dodatkowo w SLEE naleŜy

stworzyć następujące elementy: Event Object, Event Type i Activity. Dzięki RAs usługi

napisane w JSLEE stają się niezaleŜne od rodzaju sieci i jak tylko to moŜliwe najlepiej

dopasowane do specyficznych dla danego dostawcy urządzeń.

Analizowana implementacja referencyjna JSLEE Mobicents dysponuje juŜ następującymi

RAs:

� SIP – RA

� Parlay - RA

� Diameter - RA

� Asterisk - RA

� XMPP - RA.

JAIN Service Logic Execution Environment

82

5.5.10 Opis konfiguracji usługi (Deploymnet Descriptor)

KaŜda usługa w JSLEE musi zostać opisana przez deskryptor (Deployment

Descriptor77,), analogicznie jak to jest w J2EE. Budowa przykładowego deskryptora została

przedstawiona na Rys. 35. Deskryptor ma określoną strukturę i jest dokumentem XML.

Definiuje on, gdzie powinny znajdować się poszczególne komponenty usługi w strukturze

katalogowej JSLEE. KaŜdy deskryptor zawiera zbiór elementów XML z róŜnymi

parametrami. Ze względu na duŜą złoŜoność deskryptora zostały opracowane narzędzia do ich

automatycznego generowania78.

Elementy XML opisujące komponenty usługi muszą zostać umieszczone w Deployable

Unit. Deployable Unit jest to archiwum Javy JAR. Składa się ono z następujących rzeczy:

� Deskryptorów:

o service-xml.xml;

o deployable-unit.xml;

� archiwów JAR.

Dokument service-xml.xml posiada element, który jest korzeniem dokumentu XML

(<service-xml> ) oraz zawiera Description-Element (<description> ) i inne Service-

Eelments (<service> ). Service-Element opisuje poszczególne usługi. Np. dla usługi

CallBlockingAndCallForwarding Service-Elements są to usługi CallBlocking i

CallForwarding.

Deployable-unit jest głównym deskryptorem, który opisuje wykorzystane w usłudze

komponenty takie jak (Typy Zdarzeń, specyfikacje Profili, SBBs). Deskryptor Deployable-

Unit znajduje się w katalogu META-INF i nazywa się deployable-unit.xml.

77 Autor pragnie zauwaŜyć, Ŝe krok ten jest jednym z trudniejszych dla początkujących, ze względu na konieczność dokładnej znajomości całej architektury oraz skojarzenia elementów deskryptora z rzeczywistymi elementami architektury. 78 Implementacja JSLEE - Mobicents dostarcza plug-in do środowiska Eclipse, który generuje automatycznie szkielet usługi oraz odpowiednie wpisy w Deployment Descriptor.

JAIN Service Logic Execution Environment

83

Rys. 35: Model Deployable-Unit.

5.6 Przykładowa usługa – Blokowanie połączeń

W ramach środowiska badawczego mają zostać zaimplementowane interfejsy Parlay X.

Blokowanie połączeń (Call Blocking) jest jedną z funkcji interfejsu Parlay X: Call Handling.

Ze względu na niestabilność i inne problemy związane z implementacją JSLEE (patrz

rozdział 10) autorzy postanowili zaimplementować interfejsy Parlay X z wykorzystaniem

JAIN SIP, a nie jak zakładano JSLEE. Jednak dla zobrazowania sposobu tworzenia aplikacji

JSLEE uznano za słuszne implementację choćby jednego z interfejsów Parlay X79.

Przedstawiony w kodzie źródłowym 3 Service Building Block: CallBlockingSBB

opakowuje całą logikę usługi blokowania połączeń, która realizuje:

� filtrowanie przychodzących połączeń;

� automatyczne kończenie niepoŜądanych połączeń.

Rdzeń SBB tworzy metoda onCallDeliveryEvent (patrz kod źródłowy 1), która

zajmuje się przetwarzaniem przychodzących zdarzeń. Metoda ta otrzymuje dwa parametry:

� obiekt typu JccConnectionEvent (właściwe zdarzenie)

� ActivityContextInterface .

Obiekt JccConnection reprezentuje połączenie telefoniczne. Pochodzi ze specyfikacji

JCC – Java Call Control [38]. ActivityContextInterface nie jest wykorzystywany w tym

przykładzie.

79 Implementacja dokonana na przykładzie zaczerpniętym z [14].

JAIN Service Logic Execution Environment

84

Metoda onCallDeliveryEvent sprawdza, czy zdarzenie reprezentuje przychodzące

zgłoszenie (filtruje zdarzenia na podstawie typu wiadomości i wybiera jedynie wiadomości

INVITE). W przypadku zdarzenia zawierającego inną wiadomości SIP niŜ INVITE metoda

natychmiast kończy swoje działanie, gdyŜ blokowane ma być jedynie połączenie

przychodzące. Realizowane jest to po przez porównanie URI źródła z nagłówka From z

wywoływanym numerem.

W dalszej kolejności zostaje załadowana lista z niepoŜądanymi numerami. Znajduje

się ona w Profilu.

Jeśli numer dzwoniącego jest obecny na liście, zgłoszenie to jest natychmiast kończone,

po przez metodę connectionrelease .

Teraz muszą zostać przygotowane metody odpowiedzialne za funkcjonowanie usługi

w kontenerze, podobnie jak w J2EE. Z tego powodu aplikacja musi implementować interfejs

javax.slee.Sbb , którego metody będą wołane przez kontener w odpowiednich momentach

cyklu Ŝyciowego usługi (patrz kod źródłowy 2).

W metodzie setSbbContext , która znajduje się w kodzie źródłowym 2 zostaje

zapisana jedna z referencji przekazanych przez kontener SLEE. W tym przypadku

SbbContext jest dla SBB interfejsem do środowiska wykonawczego SLEE.

Metoda sbbCreate() jest wywoływana przez kontener w przypadku, gdy potrzeba

przetworzyć przychodzące zdarzenia przez SBB. Kontener pobiera wówczas SBB z Puli SBB

(tzw. SBBs Pool) i woła na nim tą metodę. W tym przykładzie SBB sięga po przez JNDI do

jednej z usług oferowanych przez Framework mianowicie ProfileFacility. Tak jak to juŜ

wcześniej zostało omówione, Profile pozwalają na dostęp do specyficznych dla usługi

danych. W przypadku rozpatrywanej usługi jest to numer dzwoniącego.

Z kodu źródłowego 1 i kodu źródłowego 2 został złoŜony kompletny SBB, realizujący

usługę blokowania połączeń. Kod tego SBB znajduje się w kodzie źródłowym 3.

SBB jest zadeklarowany jako klasa abstrakcyjna, dlatego kontener JSLEE moŜe

dynamicznie uzupełnić SBB o funkcje słuŜące do połączenia się ze środowiskiem

wykonawczym tzw. Runtime Environment.

JAIN Service Logic Execution Environment

85

Kod Źródłowy 1: Przetwarzanie zdarzenia

// Logika usługowa odpowiedzialna za przetwarzanie zdarzenia

public void onCallDeliveryEvent(JccConnectionEvent event,

ActivityContextInterface aci)

{

JccConnection connection = event.getConnection();

try

{

// Sprawdzenie, Ŝe zgłosznie jest przychodz ące

String address = connection.getAddress().getName( );

JccAddress source = connection.getOriginatingAddr ess();

if (source != null && source.getName().equals(add ress)){

return;

}

// Czytanie numerów dla usługi callblocking z pro fli

ProfileID id = profileFacility.getProfileID( ... )

CallBlockingAddressProfileCMP profile = getProfi le(id);

Address[] blocked = profile.getBlockedAddresses() ;

// Sprawdzenie listy numerów i ewentualne zablkow anie zgłoszzenia.

Boolean block = false;

for (int i = 0; i < blocked.length && !block; i++ )

{

block = (blocked[i] != null && blocked[i].getAdd ressString().

equals(source.getName()));

}

if (block) {

connection.release(JccEvent.CAUSE_DEST_NOT_OBTAI NABLE);

}

} catch (Exception e) { ... }

finally { ... }

}

Kod źródłowy 2: Funkcje związane z cyklem Ŝyciowym usługi

public void setSbbContext(SbbContext context)

{

this.context = context;

}

public void unsetSbbContext() {

context = null;

}

public void sbbCreate() throws CreateException

{

try {

Context facilities = (Context) new InitialContext ().

lookup("java:comp/env/slee/facilities");

profileFacility = (ProfileFacility) facilities.lo okup("profile");

}

catch (NamingException ne)

JAIN Service Logic Execution Environment

86

{

throw new CreateException("facility not available ", ne);

}

}

public void sbbPostCreate() {}

public void sbbActivate() {}

public void sbbPassivate() {}

public void sbbLoad() {}

public void sbbStore() {}

public void sbbRemove() {}

public void sbbExceptionThrown(Exception exception, Object

ActivityContextInterface aci) {}

public void sbbRolledBack(RolledBackContext context ) {}

Kod źródłowy 3: Klasa SBB-CallBlocking

public abstract class CallBlockingSbb implements Sb b

{

private SbbContext context;

private ProfileFacility profileFacility;

// SBB-Funkcje zwi ązane z cyklem Ŝyciwoym usługi (Kod źródłowy 2) ...

// Logika usługowa przetwarzaj ąca zdarzenia (Kod źródłowy 1) ...

}

6. Rola wolnego oprogramowania w tworzeniu usług

telekomunikacyjnych

6.1 Wstęp

Za początek idei wolnego oprogramowania moŜna przyjąć powstanie organizacji Free

Software Foundation (FSF). ZałoŜyciel tej organizacji, Richard Stallman, wprowadził pojęcie

wolnego oprogramowania (z ang. free software), w rozumieniu, którego dane

oprogramowanie moŜe zostać uznane za wolne, jeśli udostępnia pełne prawa do: jego

uŜytkowania w dowolnym celu, modyfikacji, kopiowania i rozpowszechniania. Działalność

FSF skupia się głównie na aspekcie etycznym, a za swoich oponentów uznaje organizacje,

firmy, które licencjonują wytwarzane oprogramowanie. Zupełnie inne podejście do tej idei

wyznają załoŜyciele Open Source Initative (OSI). Chcą wskazać, iŜ otwarte80

oprogramowanie moŜe nieść ze sobą istotne korzyści praktyczne, które mogą równieŜ

zainteresować i zaangaŜować duŜe firmy komercyjne. OSI promuje termin „open source” w

rozumieniu, którego, wolne oprogramowanie jest środkiem wspomagającym i kształtującym

rozwój techniczny, ze względu na fakt, iŜ kaŜdy ma moŜliwość włączyć się w ten proces –

kod jest ogólnie dostępny, czyli „otwarty” dla wszystkich81.

Podczas dotychczasowej działalności obydwu nurtów wolnego i otwartego

oprogramowania powstało wiele inicjatyw, które stały się punktem wyjścia dla nowych

projektów, czy teŜ substytutami dla rozwiązań komercyjnych. Do najbardziej znanych naleŜą

w kategorii systemów operacyjnych: Linux, FreeBSD, w kategorii oprogramowania

biurowego: Open Office, w kategorii serwerów: Apache, Tomcat, BIND, a w kategorii

języków programowania: PHP, Perl oraz Pyton.

Od dłuŜszego czasu aplikacje open source zaczynają odgrywać coraz większą rolę w

zastosowaniach telekomunikacyjnych. Jest to rezultat dwóch czynników:

� pojawienie się koncepcji sieci NGN, czyli sieci telekomunikacyjnej całkowicie opartej o

protokół IP, wprowadzenie róŜnych API udostępniających w sposób abstrakcyjny

funkcje sieci, co daje moŜliwość uŜywania powszechnie stosowanych narzędzi

80 Terminy „wolne” (free software) i „otwarty kod” (open source) wywodzą się z róŜnych nurtów (FSF, OSI), ale są w tym kontekście toŜsame. 81 Warto wspomnieć, iŜ kwestia kopiowania oprogramowania została przemilczana w definicji „open source”.

Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych

88

programistycznych, języków programowania, rozwiązań IT, etc.., z których potrafi

korzystać znacznie szersza społeczność.

� niektóre projekty open source są na tyle dojrzałe i dopracowane, Ŝe mogą spełnić

wymagania, jakie stawia środowisko telekomunikacyjne (aspekty bezpieczeństwa,

wydajności, niezawodności). Jako przykład moŜna wskazać np. Linux, w

szczególności jego inicjatywa OSDL-CGL (Open Source Development Labs Carrier

Grade Linux).

Zastosowanie open source w telekomunikacji niesie szereg korzyści:

� umoŜliwia obniŜenie kosztów w wyniku zastąpienia komercyjnych dedykowanych

rozwiązań wolnym oprogramowaniem (np. Linux). Operator nie musi się wiązać z

dostawcą sprzętu. Do rozbudowy i utrzymania moŜe zatrudnić konkurencyjne firmy.

� umoŜliwia budowę prototypów i ich testowanie niskim kosztem, dzięki zaangaŜowaniu

szerokiej społeczności programistów. Przykładem mogą być projekty: Mobicents,

Open IMS Core.

� pozwala tworzyć złoŜone systemy wykorzystujące gotowe rozwiązania open source.

Przykładem moŜe być zastosowanie serwera SER w komercyjnych softswitch.

Obecnie powstaje wiele inicjatyw tzw. „.org Players”, które promują zastosowanie

wolnego oprogramowania w telekomunikacji. Do ich grona moŜna zaliczyć m.in.: OSDL-

CGL, Communications Platforms Trade Association (CP-TA), PCI Industrial Computer

Manufacturers Group (PICMG), SCOPE Alliance, Service Availability Forum (SA Forum),

etc..

6.2 Linux w zastosowaniach telekomunikacyjnych

Linux jest dobrym przykładem na bazie, którego moŜna przedstawić generyczny cykl

Ŝycia wolnego oprogramowania w zastosowaniach operatorskich. Początkowo Linux był

wykorzystywany wyłącznie do świadczenia usług, które nie były krytyczne dla działania

biznesu (np. obliczenia uŜytkowe, OS dla serwera WWW, FTP, itp..). W momencie

pojawienia się koncepcji NGN (softswitch, bramy medialne, itp..) oraz wzrostu stabilności

Linux-a, zaczęto go stosować do zadań o charakterze krytycznym, wymagających duŜej

wydajności, niezawodności i bezpieczeństwa. Coraz większe zainteresowanie ze strony

operatorów i dostawców sprzętu przyczyniło się do powstania inicjatyw, które pracują nad

rozwojem takich cech Linux-a, które są istotne w zastosowaniach telekomunikacyjnych.

Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych

89

Przykładem takiej działalności jest OSDL-CGL, która rozwija i testuje system Linux pod

względem zapewnienia kompatybilności i wydajności.

6.3 Open Source JSLEE – Mobicents

Mobicents jest implementacją referencyjną JSLEE 1.0 NaleŜy do grupy czterech

certyfikowanych przez SUN platform JSLEE (patrz Tabela 4). Jest to projekt open source,

którego jednym z celi jest stworzenie Open Source IMS. Aktualnie został przeniesiony przez

jego twórcę Ivelina Ivanov do struktur JBOSS, co przyspieszyło jego rozwój. W projekt

zaangaŜowani są przedstawiciele branŜy telekomunikacyjnej m.in. NIST, Open Cloud,

Alcatel Lucent, etc.. oraz grupa indywidualnych programistów.

Tabela 4 Istniejące implementacje referencyjne JSLEE

Implementacja Utrzymanie Informacje

JAIN SLEE Reference Implementation

Sun Mikrosystem

Projekt open source. Rozwijany przez Open Cloud na bazie Implementacji referencyjnej platformy J2EE w wersji 1.3.

http://java.sun.com/proudcts/jslee/1.0/

Rihno Open Cloud Komercyjny produkt. Open Cloud uczestniczył przy rozwoju specyfikacji JSLEE i efektem tych prac jest równieŜ ta platforma.

www.opencloud.com/slee/intro.html

Open Convergent Feature Server (OCFS)

jNetX Komercyjny produkt. OCFS wspiera oprócz standardu JSLEE równieŜ interfejsy dla Parlay.

http://www.jnetx.com/index.php?id=ocfs

Mobicents Project Rozwijany Projekt open source. Implementacja referencyjna JSLEE bazująca na Boss.

http://www.mobicents.org

Ze względu na fakt, iŜ cześć standaryzacji JSLEE opiera się na standaryzacji J2EE

twórcy skorzystali z gotowych juŜ elementów zaimplementowanych na potrzeby platform

JBoss w wersji 3.2.x82.

82 Z JBoss został wykorzystany m.in. Mikrokontroler JMX (Java Managment Extension), JNDI (Java Naming and Directory Interface) dla rejestracji usług w SLEE, JTA (Java Transaction API) realizujący zarządzanie transakcjami oraz TreeCache – mechanizm odpowiedzialny za replikację stanów. Z rdzenia serwera aplikacyjnego JBoss został usunięty JMS (Java Message Service) i na nowo zaimplementowany kluczowy mechanizm do routingu zdarzeń.

Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych

90

Projekt Mobicents oprócz implementacji rdzenia JSLEE obejmuje równieŜ

implementację:

� Resource Adaptors (RAs). Do tej pory zostały zaimplementowane m.in. SIP RA –

wykorzystujący JAIN SIP, XMPP/Google Talk RA – stworzony na bazie biblioteki

Smack, Asterisk RA – wykorzystujący bibliotekę Asterisk-Java, Java Call Control

RA, Diameter RA, etc ..

� narzędzi do zarządzania serwerem aplikacyjnym. Jednym z nich jest Mobicents

Manager, który oferuje graficzny interfejs w postaci WWW do

instalowania/deinstalowywania, uruchamiania i monitorowania usług;

� środowiska programistycznego (IDE) o nazwie EclipSLEE wspomagającego pisanie

aplikacji JSLEE w postaci wtyczki do programu Eclipse. EclipSLEE ułatwia

stworzenie wszystkich elementów wymaganych do prawidłowego funkcjonowania

usługi w JSLEE m.in. SBB, Deployment Descriptor, zdarzeń i ich typów,

specyfikacji profili, etc..

Architektura Mobicents pokrywa się z architekturą JSLEE i szczegółowo została

omówiona w rozdziale 1.

Próby wykorzystania Mobicents do implementacji środowiska badawczego na potrzeby

tej pracy okazały się nieudane, gdyŜ serwer działał niestabilnie, a wiele rzeczy wymaganych

przy tworzeniu aplikacji pozostawało tajemnicą tylko twórców projektu. Na potrzeby tego

opracowania została zaprojektowana prosta aplikacja, której celem była analiza procesu

implementacji aplikacji JSLEE oraz poznanie środowiska uruchamiania usług

charakterystycznego dla Mobicents.

Krytyczna analiza tego projektu została przedstawiona we wstępie do rozdziału 10.

6.4 Open SIP Express Router

Open SIP Express Router (Open SER) jest projektem, którego celem jest stworzenie i

rozwijanie w pełni skalowalnego serwera SIP. Open SER wywodzi się z projektu SER, który

został rozpoczęty w 2001 roku pod auspicjami instytutu Frauthofer FOKUS83, a następnie był

83 FOKUS (Fraunhofer Institut für Offene Kommunikationssysteme) jest niemieckim instytutem badawczym zajmującym się opracowywaniem, analizą i implementacją prototypów systemów komunikacyjnych. Główe dziedziny które są w zainteresowaniach FOKUS to: infrastruktura sieci mobilnej w modelu powyŜej 3G oraz środowiska sieci sensorowych (Ambient Intelligencee).

Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych

91

rozwijany razem z firmą Iptelorg84, która wykorzystywała SER do świadczenia komercyjnych

usług. Ze względu na niejasności związane z licencjonowaniem SER, część twórców

odłączyła się i rozpoczęła „bliźniaczy” projekt o nazwie Open SER. Obecnie SER i Open SER

są udostępniane na bazie licencji GPL85, ale prace nad nimi toczą się oddzielnie.

Architektura Open SER jest przedstawiona na Rys. 36. Serwer złoŜony jest z systemu

rdzeniowego, który zapewnia podstawowe funkcje związane z analizą składni wiadomości

SIP oraz odpowiednim ich kierowaniem zgodnym z RFC 3261 [22]. Rdzeń udostępnia

interfejs programistyczny (API), z którego korzystają moduły rozszerzające funkcje. Całość

jest sterowana przez podsystem zarządzania, odpowiedzialny za powoływanie wielu instancji

serwera i rozkładanie pomiędzy nimi ruchu.

Rys. 36: Architektura serwera Open SER

Modularna budowa umoŜliwia dobranie konfiguracji Open SER dostosowanej do

funkcji, jaką będzie pełnił w sieci (powoduje to optymalne wykorzystanie zasobów). W

zaleŜności od tej konfiguracji serwer moŜe pełnić funkcje takie jak: serwer pośredniczący (z

ang. Proxy), serwer rejestru (z ang. Registrar) albo serwer przekierowujący (z ang. Redirect

Server). Innym rezultatem modularnej budowy jest moŜliwość rozwijania rozszerzeń w

sposób niezaleŜny od siebie i przez szeroką grupę programistów86. Przykładowe moduły to:

ENUM (umoŜliwia korzystanie z systemu DNS do translacji numerów telefonicznych na

adresacje SIP), ACC (opowiada za generowanie rekordów taryfikacyjnych CDR), CPL-C

84 Iptelorg jest obecnie częścią firmy Tekelec. 85 GPL (GNU General Public License) jetst umową licencyjną zakładającą otwartość udostępnianego oprogramowania (open source). 86 KaŜdy moŜe stworzyć moduł i opublikować go na stronie projektu. Jeśli przejdzie on testy zostanie włączony do oficjalnego wydania.

Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych

92

(interpretuje skrypty CPL), AUTH_DIAMETER (daje moŜliwość uwierzytelnienia z

wykorzystaniem zewnętrznego serwera AAA) oraz PRESENCE (implementuje serwer

obecności)87.

Jednym z głównych celów przyświecających projektowi jest budowa jak najbardziej

optymalnego (pod względem wykorzystania zasobów komputera) rozwiązania. Open SER jest

implementowany w C i moŜe być uruchomiony na systemach operacyjnych z rodziny UNIX

(np. Linux, BSD, Solaris). W implementacji jest stosowanych szereg specjalnych

mechanizmów mających na celu zminimalizowanie wykorzystania pamięci oraz mocy

obliczeniowej procesora. Przykład mechanizmu kontroli analizy składni wiadomości SIP

pokazuje Rys. 37.

Rys. 37: Mechanizm optymalizacji analizy składni wiadomości SIP

Polega on na analizowaniu tylko tych fragmentów wiadomości, które są wymagane w

obsłudze. Na Rys. 37 pokazany jest scenariusz, w którym moduł rozszerzenia odczytuje

wartość nagłówka z wiadomość (poprzez API). Kontroler zaimplementowany w rdzeniu

serwera sprawdza, czy Ŝądany nagłówek został juŜ odczytany (np. przez inny moduł), jeśli tak

to zwraca go, jeśli nie to przeprowadza analizę składni wiadomości do momentu jego

znalezienia. Dzięki temu mechanizmowi wiadomości SIP są odczytywane tylko w takim

zakresie, jaki wymaga tego dynamiczny kontekst obsługi.

6.5 Asterisk

Asterisk88 jest w pełni funkcjonalną centralką telefoniczną IP tzw. IP PBX (Private

Branch Exchange). Pomysłodawcą i twórcą tego rozwiązania był Mark Spencer89. Projekt

87 W wersji 1.2 oficjalne wydanie Open SER posiada 67 modułów. 88 Strona WWW projektu: www.asterisk.org.

Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych

93

został napisany w języku C i początkowo był przeznaczony pod system Linux, jednak

aktualnie powstały odmiany działające na większości systemów operacyjnych90. Kod

źródłowy jest udostępniany na podwójnej licencji, która obejmuje licencje GPL (kod

centralki) oraz licencje właściwe dla stosowanych w nim opatentowanych rozwiązań (np. dla

kodeka G.729).

Asterisk obsługuje szereg protokołów sygnalizacyjnych:

� w sieci IP: SIP, H.323, MGCP, protokół CISCO SCCP oraz zaprojektowany na

potrzeby komunikacji z centralką Asterisk protokół Inter Exchange Asterisk91 tzw.

IAX;

� w sieciach TDM: SS7 i DSS1.

Protokół IAX powstał w odpowiedzi na trudności, jakie występowały przy stosowaniu

protokołu SIP, czy teŜ H.323. Mowa tu o problemach z serwerami Network Address

Translation, czy Firewall. IAX jest protokołem binarnym przenoszącym sygnalizację oraz

media. Mechanizmy zastosowane w protokole IAX rozwiązują problemy NAT oraz Firewall.

Protokół umoŜliwia transport dowolnej liczby strumieni medialnych, które mogą być

kodowane przy uŜyciu większości istniejących kodeków92. Ponadto protokół został

wyposaŜony w mechanizmy pozwalające minimalizować wykorzystywane pasmo. W

przypadku, gdy w ramach danego połączenia realizowane jest klika strumieni mediów IAX

umoŜliwia multipleksację strumieni i kompresję nagłówków.

Komunikacja z siecią TDM realizowana jest przy pomocy kart PCI, które mogą być

wyposaŜone w róŜne interfejsy np. E1, T1, 4xE1, FXS, FXO etc.. Wówczas, gdy powstawał

Asterisk karty tego typu były drogie, poniewaŜ standardowo miały wbudowany procesory

DSP. Projektanci postanowili obniŜyć całkowity koszt centralki, poprzez realizację obróbki

89 Patrząc na historię Asterisk’a idealnie sprawdza się powiedzenie, Ŝe potrzeba jest matką wynalazku. Pod koniec lat 90 Mark Spencer chciał załoŜyć swoją firmę, która oferowałby pomoc dla uŜytkowników systemu Linux. AŜeby sprawnie obsługiwać klientów potrzebował centrali PBX. Takie kosztowały krocie. Spencer zaczął, więc eksperymentować na komputerze z kartą PCI podłączoną do sieci telefonicznej. Gdy zobaczył, jaki potencjał tkwi w takim podejściu postanowił stworzyć własną centralkę IP PBX. Aktualnie prowadzi firmę Digium, która zajmuje się rozwojem projektu i sprzętu potrzebnego do podłączenia Asteriska do sieci TDM. 90 Powstała nawet kompilacja (asterisk@home) działająca pod systemem Windows, której instalacja i konfiguracja wymaga minimalnych umiejętności. 91 Protokół IAX. 92 G.729, G.711u, G.711a, G.726, G.723.1. Nowy kodek moŜe zostać w łatwy sposób zainstalowany jako dodatkowy moduł.

Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych

94

sygnału programowo, a nie na kartach TDM. Dzięki temu podejściu mogła zwiększyć się

liczba potencjalnych uŜytkowników93.

Rys. 1: Architektura centralki Asterisk

Asterisk posiada architekturę złoŜoną z modułów (patrz Rys. 1). Struktura modułowa

pozwala pogrupować podobne funkcje w jednym bloku, dzięki czemu projekt staje się

przejrzysty i łatwy w rozbudowie. Modułem startowym jest Dynamic Module Loader, który

po uruchomieniu ładuje i inicjalizuje pozostałe moduły oraz wymagane sterowniki.

Komutacja połączeń przychodzących z róŜnych interfejsów realizowana jest w PBX

Switching Core. KaŜde połączenie obsługiwane jest według pewnego algorytmu zapisanego z

uŜyciem dedykowanego języka skryptowego, w którym mogą być wywoływane inne

aplikacje (np. playaudio, dial, hangup, etc..). Aplikacje te są uruchamiane i sterowane przez

Application Launcher. Codec Translator realizuje translację połączeń wykorzystujących

róŜne kodeki.

Asterisk udostępnia cztery rodzaje API:

� Channel API. Channel API abstrahuje głównie funkcjonalność PBX Switching Core.

Za pomocą tego API moŜna komutować połączenia realizowane przy pomocy

róŜnych technik (np. TDM, SIP, H.323, IAX) w jednorodny sposób. Źródło sygnału

cyfrowego lub analogowego pochodzące z karty TDM traktowane jest jako

93 Aktualnie ze względu na spadek cen sprzętu powraca się do obróbki mediów z wykorzystaniem procesorów DSP.

Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych

95

urządzenie wirtualne TDM, którego funkcje DSP zostały zaimplementowane

programowo.

� Codec Translator API. Codec Translator API udostępnia prosty interfejs za pomocą,

którego dokonywane jest transkodowanie róŜnego rodzaju strumieni mediów.

Konwersja moŜe odbywać się pomiędzy następującymi formatami: GSM, G.723,

ADPCM, G.711, G.729.

� File Format API . File Format API pozwala na odtwarzanie i nagrywanie dźwięków w

róŜnych formatach m.in. WAV, AU, MP3, etc... Dzięki temu tworzone aplikacje dla

Asterisk są bardziej elastyczne. Sygnały marszrutowania, DTMF, dzwonienia mogą

być zapisane w róŜnych formatach.

� Application API . Application API udostępnia interfejs do podstawowych funkcji

oferowanych przez Asterisk, jak i równieŜ do funkcjonalności dostarczanej przez

dodatkowe aplikacje, które mają charakter modułów. Jednym z waŜniejszych

interfejsów aplikacyjnych jest AGI – Application Gateway Interface, który pozwala

tworzyć aplikacje/moduły w innych językach np. Java, Perl, C, …

WaŜnym pojęciem w architekturze Asterisk są interfejsy i kanały. W terminologii

Asterisk wszystkie połączenia przychodzą i wychodzą na specyficznych interfejsach. Nazwy

ich pochodzą od obsługiwanych protokołów, czy technik np. SIP, ZAP (dla TDM) natomiast

wszelkiego typu operacje na konkretnym połączeniu to operacje na specyficznym dla danego

interfejsu kanale (channel). Przychodzące połączenia obsługiwane są zgodnie z wcześniej

skonstruowaną logiką zapisaną przy pomocy dedykowanego języka skryptowego jako tzw.

dial plan. Implementacja kaŜdego z interfejsów znajduje się w module chan_xxx.so.

Funkcjonalność oferowana przez Asterisk realizowana jest za pomocą odrębnych

aplikacji, które tworzone są jako moduły. Przykładowymi aplikacjami są: ADSI On-Screen

Menu System, Authentication, Blacklists, Blind Transfer, Call Forward on Busy/No Answer,

Call Parking, Call Queuing, Call Recording, Conference Bridging, Database Integration,

E911, ENUM, Interactive Voice Response (IVR), SMS Messaging, etc..

Asterisk udostępnia pseudo środowisko do kreacji usług. Usługi mogą być tworzone

przy pomocy następujących mechanizmów:

� dial plan – jest to algorytm przetwarzania zgłoszenia napisany w dedykowanym języku

skryptowym. Język ten umoŜliwia korzystanie z funkcji udostępnianych przez

zainstalowane moduły (np.: dial, voicemail, gotoif, playaudio, etc..).

Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych

96

� AGI (Asterisk Gateway Interfejs) – interfejs przy pomocy, którego moŜemy pisać

zewnętrzne aplikacje wywoływane w dial plan z uŜyciem róŜnych języków np.

C/C++, Java, Perl

� MAPI (Manager API) – protokół do sterowania Asterisk oraz odbierania zdarzeń

(event) pojawiających się w centrali za pomocą połączenia sieciowego.

� Moduły – zawansowany sposób rozbudowy Asterisk. UmoŜliwia tworzenie

dodatkowych modułów w języku C z wykorzystaniem funkcji udostępnianych przez

rdzeniowe biblioteki Asterisk.

6.6 Open IMS Core

Podobnie jak wspomniany wcześniej SER, Open IMS Core jest projektem realizowany

przez instytut Frauthofer FOKUS. Jego celem jest budowa w pełni funkcjonalnej rdzeniowej

części systemu IMS. Projekt został rozpoczęty w 2004 roku, a pierwsza wersja została

udostępniona 2 lata później. Wszystkie elementy Open IMS Core są dostępne pod licencją

GPL.

Elementy systemu są pokazane na Rys. 38 i są to:

� serwer HSS – Jest implementowany w języku Java z wykorzystaniem serwera Apache-

Tomcat94.

� serwery CSCF - Są to serwery SER z dodatkowymi rozszerzeniami zapewniające

funkcje związane ze środowiskiem systemu IMS.

94 Apache-Tomcat jest serwerem aplikacyjnym implementującym architekturę ‘http-Servlet’

Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych

97

Rys. 38: Architektura i składniki projektu Open IMS Core (źródło http://www.openimscore.org/)

W załoŜeniach twórców projektu, Open IMS Core powinien skupić wokół siebie

środowisko programistów, którzy będą go rozwijali zgodnie z ideą „open-source”, budując w

ten sposób system umoŜliwiający nie tylko testy rozwiązań IMS, ale system, który będzie

mógł być z sukcesem stosowany w komercyjnych rozwiązaniach.

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

100

Rys. 39: Zakres standaryzacji w IMS

Z jednej strony ta dowolność w wyborze daje duŜą elastyczność, ale z drugiej brak

jednej referencyjnej architektury warstwy aplikacyjnej wymaga od projektanta głębokiej

analizy zasadności uŜycia danych rozwiązań. Jest to utrudnione ze względu na fakt, Ŝe

implementacje w środowiskach zgodnych z koncepcjami NGN są obecne w praktyce od

stosunkowo niedawna i nie ma jeszcze wypracowanych tzw. „dobrych praktyk” w tego typu

podejściu.

Inną waŜną kwestią, która została poddana analizie jest dekompozycja warstwy

aplikacyjnej IMS na warstwę komponentów usługowych i warstwę logiki usług. Rys. 40

pokazuje wzajemne relacje pomiędzy elementami realizującymi usługi końcowe, a

komponentami, które mogą być wielokrotnie wykorzystywane w róŜnych scenariuszach

usługowych.

Specyfikacja problemu i cele analizy

101

Rys. 40: Dekompozycja warstwy aplikacyjnej IMS

Normy definiujące IMS [4] nie precyzują kształtu warstwy aplikacyjnej, a model

architektury przedstawiony na Rys. 40 jest propozycją wynikającą z roŜnych prac spoza

głównego standardu 3GPP. W tym opracowaniu zostanie poddany analizie model opracowany

w ramach Parlay Group, w którym aplikacje realizujące scenariusze usług korzystają z sieci

(a w szczególności z sieci IMS) za pośrednictwem abstrakcyjnego API (Parlay X API),

uogólniającego funkcje niŜszego poziomu.

Podsumowując, najwaŜniejszymi celami tego opracowania są:

� Analiza modelu sterowania usługami zaproponowanego w IMS. Określenie jak

mechanizmy protokołu SIP są wykorzystywane do budowy modelu usługowego,

jakie są korzyści i negatywne strony związane z jego zastosowaniem oraz jakie są

moŜliwości optymalizacji.

Szczegółowej analizie zostaną poddane:

o mechanizmy sterowania usługami oparte o tzw. filtracje wiadomości SIP i

federacje serwerów aplikacyjnych;

o mechanizmy zarządzania mobilnością;

o mechanizmy wspomagające interakcje pomiędzy róŜnymi usługami

realizowanymi w środowisku serwera aplikacyjnego.

� Analiza dekompozycji warstwy aplikacyjnej IMS jako sposobu na optymalizacje

procesu tworzenia usług. Określenie jak wygląda model implementacji usług w

środowisku dwu warstwowym (warstwa komponentów aplikacyjnych i warstwa

Specyfikacja problemu i cele analizy

102

aplikacji) na przykładzie Parlay X i JSLEE. Jakie są korzyści i jakie ograniczenia

przy takim podejściu.

Szczegółowej analizie zostaną poddane:

o komponenty usługowe (sterowanie połączeniami przez trzecią stronę,

obecność, obsługa połączeń, dostępność terminala, scentralizowana ksiąŜka

adresowa) zdefiniowane w ramach Parlay X i ich odzwierciedlenie w

implementacji na bazie serwerów aplikacyjnych i protokołu SIP w środowisku

IMS;

o modele implementacji usług przy zastosowaniu jednego serwera aplikacyjnego

(bez wyróŜnienia warstwy komponentów aplikacyjnych) na przykładzie

architektury JSLEE.

� Analiza implementacji usług w róŜnych modelach programistycznych. Określenie

jak róŜne modele programistyczne wpływają na proces tworzenia usług.

Szczegółowej analizie zostaną poddane:

o technika wykorzystująca interfejsy programistyczne zdefiniowane w ramach

inicjatywy JAIN (a w szczególności JAIN SIP);

o architektura środowiska implementacji i uruchamiania aplikacji JSLEE;

o implementacja usług wykorzystująca interfejsy programistyczne realizowane

za pomocą serwisów sieciowych (Web Services) opartych o protokół SOAP.

� Analiza moŜliwości wykorzystania rozwiązań „ open-source” w telekomunikacji.

Ocena jak oprogramowanie typu „open source” wpływa na rozwój współczesnej

telekomunikacji, jakie są kierunki zmian i potencjalne korzyści.

Szczegółowo zostaną omówione projekty:

o JAIN i JSLEE

o Asterisk PBX

o Open Sip Express Router

o Opens IMS Core

8. Architektura środowiska badawczego

Na potrzeby realizacji celów analizy, które zostały opisane w rozdziale 1, powstało

dedykowane środowisko badawcze. Składnikami tego środowiska są elementy, które stanowią

implementacje modelu budowy usług telekomunikacyjnych, zaproponowanego w standardach

opisujących IMS oraz modelu zdefiniowanego w ramach prac grupy Parlay. Odwzorowanie w

środowisku elementów funkcjonalnych IMS/Parlay ma zakres zawęŜony tylko do procedur i

interfejsów niezbędnych do realizacji badanego modelu usługowego oraz do analizy

załoŜonych scenariuszy dla konkretnych mechanizmów usługowych, które są przedmiotem

badań.

Rys. 41 przedstawia architekturę systemu. Zaznaczone są na nim zarówno logiczne

elementy funkcjonalne IMS/Parlay, jak i fizyczna realizacja, bazująca na rozwiązaniach typu

open source i komponentach implementowanych specjalnie na potrzeby tego opracowania

(zaznaczone kolorem zielonym). Zgodnie z modelami IMS i Parlay, zbudowany system

moŜna poddać dekompozycji na cztery warstwy, w których mają miejsce poszczególne fazy

realizacji usługi telekomunikacyjnej.

Warstwę urządzeń końcowych i bram tworzą:

� aplikacje klienckie implementujące agenta uŜytkownika protokołu SIP , czyli tzw.

UA. Zgodnie z normami specyfikującymi IMS, UA powinno wspierać kilka

specyficznych mechanizmów np. dodatkowe nagłówki w protokole SIP97, albo

specjalny algorytm uwierzytelnienia dla sieci UMTS98. Ze względu na brak obecnie

dostępnych implementacji takich UA oraz małe znaczenie tych dodatkowych

mechanizmów w badanym zagadnieniu, w analizie byli stosowani agenci

uŜytkownika przystosowani do sieci Internet99.

� brama medialna (MGW), której funkcje realizuje serwer Asterisk PBX. MGW jest

połączony do centrali telefonicznej za pomocą łącza ISDN PRA. Dzięki temu

97 Na potrzeby IMS, 3GPP wprowadziło dodatkowe nagłówki do oryginalnego protokołu SIP. Są to tzw. „Private-Headers”, np. „P-Preffered-Identity” (patrz [24]), którym UA informuje S-CSCF, jaki publiczny identyfikator chce stosować w inicjowane sesji. 98 IMS wymaga, aby agent uŜytkownika (UA) w procedurze uwierzytelnienia stosował algorytm EAP-AKA (opisany w RFC4187). 99 W sieci Internet stosowane są UA zgodne z protokołem SIP opisanym w[22].

Architektura środowiska badawczego

104

środowisko badawcze umoŜliwia analizę interakcji pomiędzy sieciami tradycyjnymi

opartymi o komutacje łączy, a siecią w modelu NGN.

Warstwę sterowania połączeniami i zgłoszeniami tworzą elementy:

� serwer P-CSCF, który jest realizowany na bazie projektu Open Sip Express Router.

Specyficzna logika związana z IMS jest zaimplementowana za pomocą modułu

rozszerzającego działanie Open SER ponad standardową funkcję serwera SIP

Proxy100.

� serwery S-CSCF i I-CSCF. Podobnie jak P-CSCF, specyficzna logika tych elementów

funkcjonalnych IMS jest zaimplementowana za pomocą modułu rozszerzającego

funkcje Open SER. W środowisku badawczym oba elementy P/I-CSCF są

implementowane jako jeden fizyczny serwer.

� repozytorium profili u Ŝytkowników (HSS), którego funkcja została w środowisku

zaimplementowana takŜe jako moduł do Open SER. HSS wykorzystuje relacyjną

bazę danych do przechowywania tzw. profili uŜytkowników. Ta funkcja jest

zintegrowana z modułem realizującym elementy S-CSCF i I-CSCF.

� kontroler bramy medialnej (MGCF) , który jest realizowany wspólnie z MGW przez

Asterisk PBX. W środowisku badawczym Asterisk występuje takŜe w roli bramy

sygnalizacyjnej (SGW).

Warstwę komponentów usługowych tworzą:

� serwer obecności (z ang. Presence Server), który udostępnia informacje o stanie

obecności poprzez wiadomości protokołu SIP. W środowisku badawczym do tej

funkcji została wykorzystana aplikacja zrealizowana w ramach pracy dyplomowej

Michała Giermasińskiego i Krzysztofa Henniga [42].

� Serwery aplikacyjne (AS) realizujące logikę wybranych interfejsów Parlay X w

modelu IMS. AS dokonują przełoŜenia funkcji zdefiniowanych w ramach Parlay na

odpowiednią sekwencje wiadomości sygnalizacyjnych w IMS. W implementacji

wykorzystany został stos protokołu SIP zdefiniowany w ramach inicjatywy JAIN,

100 Jest to element architektury protokołu SIP

Architektura środowiska badawczego

105

czyli JAIN SIP (JSR 32)101. Wybrane interfejsy to: ThirdPartyCall, CallHandling,

TerminalStatus, AddressListManagement, Presence102.

Warstwę logiki aplikacji tworzy:

� usługa „Centrum Komunikacji Osobistej” (CKO) , która jest zaimplementowana jako

skrypt PHP103 w środowisku serwera HTTP. Ta aplikacja, z jednej strony, udostępnia

uŜytkownikowi interfejs WWW, a z drugiej strony korzysta w realizacji swojej

logiki z interfejsów Parlay X udostępnianych przez serwery aplikacyjne z warstwy

komponentów aplikacyjnych.

101 Specyfikacja JSR 32 definiuje API stosu SIP. W implementacji została wykorzystana referencyjna implementacja tego API, wykonana przez National Institute of Standards and Technology (NIST). 102 Szczegółowy opis funkcjonalny tych interfejsów zamieszczony jest w rozdziale 4. 103 PHP jest językiem skryptowym najczęściej stosowanym do oprogramowywania dynamicznych stron WWW.

Archite

ktura środ

ow

iska bad

awcze

go

106

P-CSCF

Interfejs usług sieciowych Parlay X

(SOAP/HTTP)

Interfejs sterowania usługami (SIP-ISC)

MGCF

MGW

Sieć PSTN

Interfejs do sieci PSTN

(ISDN-PRA)

sieć „IP”

SIPSIP

I-CSCF

HSS

SIP

Procedura‘User-Registration-Query’

Procedura

‘Terminating-Service-Control’

S-CSCF

Procedura ‘Cx-User-Authorization’

Procedura ‘Cx-Multimedia-Authorization’

Procedura ‘Cx-Server-Assignment’

Make Call

Cancel Call

Set Rule

Get Rule

Clear Rule

Serwer udostępnianiainformacji o stanie terminala uŜytkownika

Get Status

Serwer zarządzania ksiąŜką adresową

Delete Group

Query Members

Delete Member

Create Group

Add Member

J2SE

stos JAIN-SIP

interfejs ThirdPartyCall interfejs CallHandling interfejs TerminalStatus interfejs AddressListManagement interfejs Presence

Open SER

prolile uŜytkowników

Open SER

Procedura 'Assert Identity'

Asterisk PBX

Serwer udostępniającyinformacje o stanie obecności uŜytkownika

Publish User Presence

Get User Presence

Serwer sterowania połączeniami 3PCC

Serwer obsługi połączeń

elementy implementowane w ramach

środowiska badawczego

gotowe komponenty „open

source”

Procedura‘Originating-Service-Control’

Procedura

‘Registration-Notification’

Rys. 41: A

rchitektura środowiska badaw

czego

9. Implementacja i analiza modelu sterowania

usługami zaproponowanego w IP Multimedia

Subsystem

Model sterowania usługami zaproponowany w standardach opisujących IMS został

omówiony w rozdziale 3. W implementacji środowiska badawczego, którego celem jest

analiza tego modelu, wybrano podzbiór funkcji, procedur i interfejsów, które stanowią

podstawową bazę badanego zagadnienia.

P-CSCF

IM Subsystem

S-CSCF MGCF HSS

Cx

IP Multimedia Networks

IMS-MGW

PSTN

Mn

Mb

Mg

Mm

MRFP

Mb

Mr

Mb

Legacy mobile signalling Networks

I-CSCF

Mw

Mw

Gm

BGCF Mj Mi

BGCF

Mk Mk

C, D, Gc, Gr

UE

Mb

Mb

Mb

MRFC

SLF Dx

Mp

PSTN

PSTN

Gq

Rys. 42: Zakres implementacji (kolor zielony) modelu usługowego w środowisku badawczym na tle

architektury funkcjonalnej IMS ( źródło [3])

Na Rys. 42 przedstawiona jest architektura funkcjonalna IMS z zaznaczonymi

elementami, których funkcje/procedury zostały zaimplementowane w ramach środowiska

badawczego. Wybór tych elementów stanowi podzbiór niezbędny do analizy badanego

modelu usługowego. Elementy, których implementacja nie obejmuje są co prawda, niezbędne

do funkcjonowania standardowego komercyjnego systemu IMS, ale ich znaczenie w badanym

zagadnieniu jest niewielkie.

Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem

108

9.1 Opis zaimplementowanych mechanizmów

Zestaw implementowanych mechanizmów związanych z obsługą zgłoszeń, moŜna

podzielić ze względu na elementy funkcjonalne architektury IMS, które je realizują. Rys. 43

pokazuje umiejscowienie tych mechanizmów w poszczególnych elementach środowiska

badawczego. Zaimplementowane procedury są skojarzone z takimi elementami jak: P-CSCF,

S-CSCF, I-CSCF i HSS i wspólnie umoŜliwiają zamodelowanie sterowania usługami.

Rys. 43: Sterowanie połączeniami i zgłoszeniami IMS - zaimplementowane procedury związane z

modelem sterowania usługami

9.2 Procedura wstawienia informacji o identyfikacji uŜytkownika

(Assert Identity)

Procedura wstawienia informacji o identyfikacji uŜytkownika (Assert Identity) jest

wykonywana w serwerze P-CSCF. Podczas próby inicjacji sesji multimedialnej, UA

uŜytkownika wysyła wiadomości sygnalizacyjne104, które kierowane są do P-SCCF.

Następnie P-CSCF dokonuje uwierzytelnienia uŜytkownika, co umoŜliwia jednoznaczne

określenie toŜsamości tj. prywatnego identyfikatora uŜytkownika tzw. Private-User-

104 Inicjacja sesji odbywa się za pomocą widomości INVITE protokołu SIP.

Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem

109

Identifier105. Gdy znana jest juŜ toŜsamość, P-CSCF modyfikuje wiadomości sygnalizacyjne

dla inicjowanej sesji poprzez umieszczenie w nich informacji o uwierzytelnionym juŜ

identyfikatorze uŜytkownika. Ta informacja jest zawarta w dodatkowym nagłówku protokołu

SIP tj. P-Asserted-Indentity, którego wartością jest publiczny identyfikator jednoznacznie

skojarzony z uwierzytelnioną toŜsamością106. Rys. 44 ilustruje kolejność zdarzeń w tej

procedurze, natomiast na Rys. 45 jest pokazana przykładowa widomość INVITE i jej

modyfikacja w P-CSCF.

Rys. 44: Procedura identyfikacji uŜytkownika w P-CSCF (Assert Identity)

Informacja o uwierzytelnionej identyfikacji uŜytkownika jest propagowana do innych

elementów IMS za pomocą nagłówka P-Asserted-Indentity. Jest to podstawą do realizacji

wszystkich mechanizmów związanych z wykonywaniem usług dla połączeń wychodzących

(tzw. originating service control, opis w rozdziale 9.3.7). Uwierzytelnienie uŜytkownika

następuje tylko w P-CSCF, a pozostałe systemy biorące udział w realizacji połączenia (z

serwerami aplikacyjnymi włącznie), aby zidentyfikować inicjatora sesji korzystają z

informacji zapisanej w P-Asserted-Indentity.

105 W IMS toŜsamość uŜytkownika jest skojarzona z prywatnym identyfikatorem. 106 Według specyfikacji IMS [7] wartością nagłówka P-Asserted-Identity jest publiczny identyfikator, który został zarejestrowany (za pomocą wiadomości REGISTER) i jest skojarzony z uwierzytelnionym prywatnym identyfikatorem. UŜytkownik moŜe zarejestrować wiele publicznych identyfikatorów skojarzonych z jednym prywatnym identyfikatorem. Agent uŜytkownika informuje P-CSCF, jakim konkretnym publicznym identyfikatorem chce się posługiwać w inicjowanej sesji poprzez umieszczenie w wiadomości INVITE dodatkowego nagłówka P-Preffered-Identity. Ze względu na niedostępność gotowych implementacji agentów uŜytkownika zgodnych z IMS, czyli takich, którzy między innymi wspierali by mechanizm opisany powyŜej, implementowany w środowisku badawczym mechanizm Assert Identity umieszcza w nagłówku P-Asserted-Identity pierwszy zarejestrowany publiczny identyfikator skojarzony z uwierzytelnionym uŜytkownikiem, niezaleŜnie od wartości nagłówka P-Preffered-Identity, który nie występuje w UA niezgodnych z IMS. Tym sposobem w środowisku badawczym mogą być uŜywani agenci uŜytkownika niewspierający mechanizmów specyficznych dla IMS.

Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem

110

Rys. 45: Przykładowa modyfikacja wiadomości INVITE w P-CSCF107.

Prywatny identyfikator uŜytkownika pojawia się w sygnalizacji wyłącznie podczas

procedury uwierzytelnienia w P-CSCF i w procedurze rejestracji w S-CSCF. W komunikacji

z serwerami aplikacyjnymi (AS) do identyfikacji uŜytkownika jest wykorzystywany tylko

nagłówek P-Asserted-Indentity. Minimalizacja „uŜycia” prywatnego identyfikatora jest

spowodowana wymogami bezpieczeństwa i ochrony prywatności uŜytkownika, który moŜe

występować w sieci pod róŜnymi publicznymi identyfikatorami, ale moŜliwość skojarzenia

powiązania pomiędzy nimi jest moŜliwa tylko w bezpiecznej części sieci macierzystej i tylko

na elementach niebiorących bezpośredniego udziału w realizacji usług.

9.3 Procedura przydzielenia serwera S-CSCF podczas pierwszej

rejestracji agenta uŜytkownika (User-Registration-Query)

Procedura przydzielenia serwera S-CSCF (User-Registration-Query) ma miejsce w

serwerze I-CSCF. Podczas przyłączenia się do sieci, agent uŜytkownika w terminalu

końcowym dokonuje rejestracji w systemie IMS wysyłając zgłoszenie rejestracji, które

poprzez P-CSCF trafia do I-CSCF, gdzie przeprowadzane są następujące czynności:

� I-CSCF komunikuje się z HSS w celu uzyskania zezwolenia na rejestracje publicznego

identyfikatora (PUI). HSS wykonuje procedurę Cx-User-Authorization (opis

poniŜej), której rezultatem jest zwrócenie informacji o zgodzie na rejestracje108.

107 Pokazane przykładowe wiadomości INVITE protokołu SIP nie są całkowicie zgodne z wymogami, jakie nakładają specyfikacje IMS tj. brakuje w nich specyficznych dla IMS nagłówków, które zostały opisane w [24] i [25]. Nieobecność tych dodatkowych nagłówków nie wpływa na implementowany w ramach środowiska badawczego model sterowania usługami IMS. 108 Brak zgody na rejestracje moŜe być spowodowany: niemoŜnością znalezienia publicznego identyfikatora (PUI) uŜytkownika, który się rejestruje albo tym, Ŝe rejestrowany PUI nie naleŜy do prywatnego identyfikatora

Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem

111

� I-CSCF komunikuje się z HSS w celu uzyskania informacji o adresie S-CSCF, który

będzie obsługiwał rejestrującego się uŜytkownika109.

Następnie zgłoszenie rejestracji jest kierowane do S-CSCF, którego adres został

otrzymany z HSS110. Kolejność realizowanych mechanizmów została przedstawiona na Rys.

46, w którym takŜe są zaznaczone logiczne styki pomiędzy elementami funkcjonalnymi IMS

implementowanymi w środowisku badawczym jako jeden fizyczny serwer.

Rys. 46: Procedura User-Registration-Query w I-CSCF i Cx-User-Authorization w HSS

Podstawową rolą procedury User-Registration-Query w rejestracji uŜytkownika jest

przydzielenie odpowiedniego S-CSCF, który będzie właściwym serwerem obsługującym

wszystkie zgłoszenia przychodzące i wychodzące od rejestrowanego uŜytkownika111.

9.3.1 Procedury interfejsu Cx

Interfejs Cx jest stykiem pomiędzy serwerami CSCF, a HSS. Na Rys. 47 zaznaczone są

główne funkcje tego interfejsu. Do najwaŜniejszych procedur zdefiniowanych na tym

interfejsie naleŜą udostępnianie informacji niezbędnych do uwierzytelnienia uŜytkownika

oraz udostępnianiu tzw. profilu, w którym zawarte są informacje, jakie serwery aplikacyjne

mają brać udział w dalszej obsłudze zgłoszenia.

uŜytkownika (PRUI). Brak zgody na rejestracje moŜe teŜ być podyktowany wewnętrzną polityką narzuconą na HSS. 109 Zgodnie z [9] HSS zwraca I-CSCF listę adresów S-CSCF, które mogą obsługiwać uŜytkownika. W implementacji na potrzeby środowiska badawczego HSS zwraca jeden adres serwera S-CSCF. 110 W środowisku badawczym I-CSCF, S-CSCF i HSS są zaimplementowani w jednym serwerze, ale komponenty aplikacyjne odpowiedzialne za poszczególne elementy funkcjonalne są wydzielone. 111 Przejście zgłoszenia rejestracji przez I-CSCF ma duŜe znaczenie w przypadku, gdy uŜytkownik jest w sieci obcej względem swojej macierzystej (tzw. z ang. roaming). W tym przypadku I-CSCF otrzymuje informacje z HSS o adresie S-CSCF naleŜącym do macierzystej sieci rejestrującego się uŜytkownika i tam następuje dalsza obsługa. Ze względu na małe znaczenie tych mechanizmów w analizowanym zagadnieniu, w środowisku badawczym nie zostały one zaimplementowane.

Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem

112

Rys. 47: Funkcje interfejsu Cx

Zgodnie z [9] specyfikującym interfejs pomiędzy HSS i CSCF, protokołem na styku Cx

powinien być Diameter112, ze względu na przyjętą zintegrowaną implementacje funkcji HSS i

CSCF, Cx jest zamodelowany za pomocą programistycznego API pomiędzy modułami w

serwerze Open SER (patrz Rys. 48).

Rys. 48: Implementacja interfejsu Cx jako API

112 Protokół ‘Diameter’ opisany jest w RFC 3588

Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem

113

9.3.2 Procedura autoryzacji Ŝądania rejestracji (Cx-User-Authorization)

Procedura autoryzacji Ŝądania rejestracji (Cx-User-Authorization) jest to jedna z

procedur zdefiniowana na interfejsie Cx113. Polega na przydzieleniu rejestrującemu się

uŜytkownikowi serwer S-CSCF, który będzie go obsługiwał. Przed przyznaniem adresu S-

CSCF, HSS dokonuje sprawdzenia czy uŜytkownik, który rejestruje się w sieci przedstawia

się poprawnymi identyfikatorami i czy PUI jest skojarzony z PRUI.

Procedura składa się z Ŝądania skierowanego z I-CSCF do HSS i odpowiedzi HSS. Na

Rys. 49 przedstawiona jest programistyczna definicja funkcji modelującej tą procedurę.

Parametrami Ŝądania są:

� PUI;

� Publiczny identyfikator uŜytkownika, który jest rejestrowany;

� Typ uwierzytelnienia, w którym I-CSCF informuje HSS o tym, czy zgłoszenie dotyczy

nowej rejestracji uŜytkownika albo dotyczy Ŝądania wyrejestrowania z sieci IMS.

Rys. 49: Funkcja CX-UA modelująca procedurę Cx-User-Authorization

Po otrzymaniu Ŝądania, HSS dokonuje sprawdzenia czy publiczny identyfikator naleŜy

do uŜytkownika i czy uŜytkownik ma prawo dokonać rejestracji114.

113 W implementacji na potrzeby środowiska badawczego ten interfejs nie ma charakteru sieciowego (funkcje CSCF i HSS są zintegrowane w ramach jednego serwera) tylko jest zamodelowany jako API pomiędzy dwoma komponentami programistycznymi. 114 Implementacja HSS w środowisku badawczym umoŜliwia blokowanie moŜliwości rejestracji poszczególnych publicznych identyfikatorów.

Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem

114

Odpowiedź HSS składa się z:

� Kodu określającego rezultat operacji;

� Adresu serwera S-CSCF, który został przydzielony do obsługi zgłoszenia.

9.3.3 Procedura uwierzytelnienia uŜytkownika (Cx-Multimedia-Authentication)

Procedura uwierzytelnienia uŜytkownika (Cx-Multimedia-Authentication) jest to jedna z

procedur zdefiniowana na interfejsie Cx. SłuŜy do pobrania z HSS kluczy niezbędnych do

uwierzytelnienia uŜytkownika, które następnie są porównywane w S-CSCF z danymi

uzyskanymi ze zgłoszenia rejestracji115. Rys. 50 pokazuje funkcję CX-MA, która modeluje

procedurę Cx-Multimedia-Authentication.

Rys. 50: Funkcja CX-MA modelująca procedurę Cx-Multimedia-Authentication

Parametrami Ŝądania są:

� PRUI;

� Publiczny identyfikator, którego dotyczy zgłoszenie rejestracji.

Odpowiedź HSS składa się z:

� Kodu określającego rezultat operacji;

� Danych, które umoŜliwiają uwierzytelnienie (klucze).

115 W IMS uwierzytelnienie uŜytkownika odbywa się przy pomocy algorytmu EAP-AKA (opisany w RFC4187). Polega on na współdzieleniu kluczy prywatnych pomiędzy HSS i kartą USIM, znajdująca się w telminalu uŜytkownika. Przy takim modelu W procedurze Cx-Multimedia-Authentication HSS zwraca S-CSCF tzw. zmienne RAND, AUTN i XRES (opis w 3GPP TS 33.203). W implementacji był stosowany model uproszczony, w którym HSS zwraca tylko jeden klucz umoŜliwiający uwierzytelnienie uŜytkownika.

Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem

115

9.3.4 Procedura pobrania profilu uŜytkownika (Cx-Server-Assigment)

Procedura pobrania profilu uŜytkownika (Cx-Server-Assigment) jest to jedna z procedur

zdefiniowana na interfejsie Cx. Główną funkcją tej procedury w implementowanym

środowisku badawczym, jest umoŜliwienie pobrania profilu uŜytkownika z HSS do

obsługującego serwera S-CSCF. Po pomyślnym uwierzytelnieniu uŜytkownika S-CSCF

kieruje Ŝądanie w celu rejestracji w HSS tego, Ŝe dany uŜytkownik jest obsługiwany w danym

serwerze S-CSCF. Rys. 51 pokazuje funkcje CX-SA, która jest modelem procedury Cx-

Server-Assigment w API udostępnianym przez HSS.

Rys. 51: Funkcja CX-SA modelująca procedurę Cx-Server-Assigment

Parametrami Ŝądania są:

� Prywatny identyfikator uŜytkownika (PRUI);

� Publiczny identyfikator, którego dotyczy zgłoszenie rejestracji;

� Adres serwera S-CSCF, który obsługuje uŜytkownika;

� Typ rejestracji (nowa rejestracja, de-rejestracja, powtórna rejestracja, brak rejestracji,

itd..);

Odpowiedź HSS składa się z:

� Kodu określającego rezultat operacji;

� Profilu uŜytkownika.

Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem

116

Wywołanie Cx-Server-Assigment moŜe teŜ mieć miejsce dla uŜytkowników, którzy

aktualnie nie są przyłączenie do sieci. Dzieje się tak w przypadku konieczności pobrania

profilu takiego uŜytkownika przez S-CSCF w celu wykonania procedury związanej z

usługami (patrz procedura Terminating Service Control).

9.3.5 Procedura rejestracji uŜytkownika w serwerze S-CSCF (Registration-

Notification)

Procedura rejestracji uŜytkownika w serwerze S-CSCF (Registration-Notification) ma

miejsce w serwerze S-CSCF. Po otrzymaniu zgłoszenia rejestracji z serwera I-CSCF,

przeprowadzane jest uwierzytelnienie. W tym celu S-CSCF pobiera z HSS klucze

autoryzacyjne (patrz procedura Cx-Multimedia-Authentication) i dokonuje sprawdzenia, czy

dane pobrane z HSS umoŜliwiają uwierzytelnienie. Jeśli znana jest juŜ toŜsamość

uŜytkownika, S-CSCF informuje HSS o poprawnej rejestracji i pobiera odpowiedni profil

uŜytkownika, dla którego została przeprowadzona procedura rejestracji (patrz procedura Cx-

Server-Assigment).

Rys. 52: Procedura rejestracji uŜytkownika w S-CSCF

Rys. 52 pokazuje czynności wchodzące w skład procedury Registration-Notification.

9.3.6 Procedury sterowania usługami (Service Control)

Procedury sterowania usługami (Service Control) są podstawą modelu usługowego

zaproponowanego w specyfikacjach opisujących IMS. Istotą ich funkcji jest odpowiednie

skierowanie obsługi danego zgłoszenia do właściwego serwera aplikacyjnego. Decyzja, jakie

zgłoszenie i przez jaki serwer aplikacyjny ma być obsługiwane zgłoszenie, odbywa się na

podstawie profilu uŜytkownika, a w szczególności na podstawie tzw. kryteriów filtracji (z

ang. Initial Filter Criteria ).

Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem

117

W implementowanym modelu sterowania usługami proces obsługi zgłoszeń jest podzielony

na kilka etapów:

� określanie czy zgłoszenie jest zgłoszeniem przychodzącym czy wychodzącym

WyróŜnione są dwie procedury sterowania usługami. Jedna dla połączeń

przychodzących do uŜytkownika (Terminating Service Control) i dla połączeń

inicjowanych przez uŜytkownika (Originating Service Control). W przypadku

połączeń wychodzących, procedura sterowania usługami oparta jest o profil

uŜytkownika, który zainicjował zgłoszenie. Jeśli zgłoszenie jest przychodzące to

wywoływana jest procedura sterowania oparta o profil adresata zgłoszenia (patrz

Rys. 53).

Rys. 53: Zgłoszenie od uŜytkownika A do B i analiza profili w S-CSCF

� Sprawdzenie dostępności profilu u Ŝytkownika i ewentualne pobranie profilu z HSS

S-CSCF pobiera profil uŜytkownika w procedurze rejestracji (patrz Registration-

Notification) i podczas obsługi zgłoszeń wychodzących zawsze profil uŜytkownika

jest dostępny w S-CSCF, poniewaŜ tylko uŜytkownicy, którzy są zarejestrowani

mają prawo inicjować połączenia. W przypadku połączeń przychodzących,

uŜytkownik, do którego jest adresowane zgłoszenie, moŜe aktualnie być poza siecią

tzn. być nie zarejestrowany w systemie IMS. Jeśli taka sytuacja nastąpi, S-CSCF

wykonuje procedurę Cx-Server-Assigment w celu pobrania profilu uŜytkownika

wywoływanego w analizowanym zgłoszeniu. Pobranie profilu dla nie

zarejestrowanego uŜytkownika jest potrzebne, poniewaŜ kaŜdy uŜytkownik moŜe

mieć przypisane usługi, które są wykonywane właśnie, gdy jest on poza siecią (nie

Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem

118

jest zarejestrowany w IMS)116. Rys. 54 pokazuje przykładową obsługę zgłoszenia dla

nie zarejestrowanego uŜytkownika.

Profil B

Rys. 54: Zgłoszenie od uŜytkownika A do B i analiza profili w S-CSCF dla niezarejestrowanego

uŜytkownika

� Określenie czy zgłoszenie jest zgłoszeniem juŜ obsługiwanym przez serwer

aplikacyjny.

Serwer aplikacyjny (AS), do którego S-CSCF skieruje zgłoszenie w celu wykonania

scenariusza usługi, moŜe dokonać modyfikacji tego zgłoszenia (modyfikacji

wiadomości protokołu SIP) i następnie moŜe skierować to zgłoszenie ponownie do

S-CSCF117. Aby uniknąć sytuacji, w której powracające zgłoszenie z serwera

aplikacyjnego zostanie jeszcze raz „zawrócone” do tego samego AS, S-CSCF

kierując wiadomości SIP do danego AS wstawia dodatkowy nagłówek (‘P-Original-

Dialog-ID’), który umoŜliwia przyporządkowanie powracających wiadomości SIP z

serwerów aplikacyjnych do danego zgłoszenia. S-CSCF posiada informacje, jakie

AS obsługiwały dane zgłoszenie i w ten sposób nigdy dana wiadomości nie jest

dwukrotnie kierowana do tego samego serwera aplikacyjnego.

116 Przykładem takiej usługi moŜe być przekierowanie połączeń na inny numer (np. poczty głosowej) w przypadku wyłączonego terminala. 117 Takie zachowanie serwera aplikacyjnego odpowiada funkcji SIP-proxy.

Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem

119

AS#1

sip:as1.eims.local

AS#2

sip:as2.eims.local

Profil AIFC, priorytet 1 = INVITE na sip:[email protected]

IFC, priorytet 2 = INVITE na sip:[email protected]

uŜytkownik #A

1. INVITE B

S-CSCF

P-CSCF

2. INVITE B

3. IN

VITE B

4. INVITE B

5. IN

VITE B

service control

INVITE sip:[email protected] SIP/2.0

P-Original-Dialog-ID: call-id=de40707c-cede-db11-8499@rubi;from-tag=2644707cP-Service-Name: <sip:[email protected]>

INVITE sip:[email protected] SIP/2.0

P-Original-Dialog-ID: call-id=de40707c-cede-db11-8499@rubi;from-tag=2644707cP-Service-Name: <sip:[email protected]>

uŜytkownik #B

6. INVITE BP-CSCF

Rys. 55: Obsługa zgłoszenia poprzez kilka serwerów aplikacyjnych

Rys. 55 pokazuje obsługę wiadomości INVITE, dla danego zgłoszenia wychodzącego.

Profil uŜytkownika zawiera informacje instruującą S-CSCF o konieczności kierowania

wiadomości INVITE do dwóch serwerów aplikacyjnych (AS#1 i AS#2). Zgodnie z

zapisanym w profilu priorytetem S-CSCF kieruje wiadomości do pierwszego AS,

wstawiając nagłówek ‘P-Original-Dialog-ID’ zawierający identyfikator danego

zgłoszenia (szczegółowy opis znajduje się poniŜej). Powracająca widomość z AS

zawiera ten nagłówek i na tej podstawie S-CSCF jest wstanie podjąć decyzję, Ŝe

następnym serwerem aplikacyjnym dla tej wiadomości będzie AS#2 (zgodnie z

priorytet zapisanym w profilu).

� Analiza kryteriów filtrowania - IFC

Profil uŜytkownika, który jest pobierany z HSS, zawiera tzw. filtry IFC (z ang.

Initial Filter Criteria ). IFC definiują reguły określające, jakie wiadomości protokołu

SIP wyzwalają przekierowanie zgłoszenie do danego serwera aplikacyjnego. Profil

zawiera wiele reguł IFC, które mają przyporządkowany priorytet. Priorytet decyduje o

kolejności analizowania danych z poszczególnych IFC w S-CSCF.

KaŜdy IFC składa się z kryteriów wyzwolenia (z ang. Trigger Point), które

określają zestaw warunków decydujących o potrzebie zastosowania obsługi zgłoszenia

w serwerze aplikacyjnym. Rys. 56 pokazuje przykładową definicję IFC, która zawiera

Trigger Point określający, Ŝe kaŜde zgłoszenie zawierające wiadomość INVITE

Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem

120

powinno być skierowane do serwera aplikacyjnego o adresie

„sip:[email protected]

Rys. 56: Definicja filtru IFC

IFC zawiera takŜe informacje o rodzaju sesji (SessionCase), której dotyczy dana

reguła IFC. Rodzaj sesji określa czy IFC ma być stosowane do zgłoszeń

wychodzących (Originating Service Control), zgłoszeń przychodzących (Terminating

Service Control) lub zgłoszeń przychodzących do uŜytkownika, który nie jest

zarejestrowany w systemie IMS (Terminating Service Control for Unregistered User

State).

� Wstawienie nagłówka „P-Original-Dialog-ID” 118

Jeśli zgłoszenie jest nowym zgłoszeniem (nie jest powracającym zgłoszeniem z

serwera aplikacyjnego) i wymaga obsługi w serwerze aplikacyjnym, to S-CSCF

dodaje do wiadomości SIP dodatkowy nagłówek identyfikujący jednoznacznie

przynaleŜność tej wiadomości do danego zgłoszenia. Wartością nagłówka ‘P-

Original-Dialog-ID’ jest konkatenacja identyfikatorów dialogu protokołu SIP, czyli

wartości nagłówka ‘Call-ID’ oraz etykiet nagłówków ‘From’ i ‘To’ (patrz Rys. 57).

118 W IMS jest stosowany inny mechanizm tzn. nie jest wstawiany dodatkowy nagłówek ‘P-Original-Dialog-ID’. Według [7] aby umoŜliwi ć identyfikacje powracającej wiadomości do poszczególnych zgłoszeń stosuje się nagłówek ‘Route’ (jego rola w protokole SIP opisana jest w [22]), do którego dodaje się specjalnie skonstruowany adres nieistniejącego serwera. Ten spreparowany adres jest uŜywany jako identyfikator zgłoszenia i pozwala S-CSCF zidentyfikować wiadomość. To rozwiązanie zostało zaakceptowane przez 3GPP i jest obecnie standardem. We wczesnych pracach nad mechanizmami w IMS pojawiła się propozycja uŜycia nagłówka ‘P-Original-Dialog-ID’ (opisana w IETF draft-henrikson-sip-original-dialog-id), która zakładała uŜycie nowego nagłówka zamiast korzystania z ‘Route’, który jest bazowym (opisanym RFC3261) elementem protokołu SIP. Propozycja ta wynikała z faktu, Ŝe wykorzystywanie ‘Route’ jako identyfikatora sesji (tak jak zostało to opisane powyŜej) jest de facto niezgodne z przeznaczeniem tego nagłówka opisanym RFC3261. Ta kwestia była i jest poddawana krytyce.

Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem

121

Rys. 57: Budowa nagłówka P-Original-Dialog-ID'

Potrzeba stosowania P-Original-Dialog-ID wynika z faktu, Ŝe identyfikacja, do

jakiego zgłoszenia naleŜy dana wiadomość jest niemoŜliwa w oparciu tylko o

standardowe nagłówki określające dialog protokołu SIP119. Dzieje się tak, poniewaŜ

kaŜdy serwer aplikacyjny potencjalnie moŜe występować w tzw. roli B2BUA120. W tej

roli, AS moŜe tworzyć nowy dialog (w sensie protokołu SIP) i tym sposobem

wiadomość powracają z AS do S-CSCF nie mogłaby być rozpoznana jako

powracająca w ramach jednego zgłoszenia. Faktycznie naleŜałaby do nowego,

zainicjowanego przez AS, dialogu. Umieszczanie P-Original-Dialog-ID daje

moŜliwość S-CSCF identyfikacji oryginalnej przynaleŜności wiadomości do dialogu i

co za tym idzie, identyfikacji przynaleŜności do danego zgłoszenia (patrz Rys. 58).

119 Dialog w protokole SIP identyfikowany jest przez wartość nagłówka ‘Call-ID’ i etykiety (‘tag’) z nagłówków ‘From’ i ‘To’. 120 Opis zamieszczony jest w rozdziale 2.

Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem

122

Rys. 58: Modyfikacja identyfikatorów dialogu w wiadomości SIP przy przejściu przez AS, który

występuje w roli B2BUA

� Skierowanie zgłoszenia do odpowiedniego serwera aplikacyjnego.

Po sprawdzeniu, czy profil uŜytkownika definiuje potrzebę skierowania obsługi do

serwera aplikacyjnego i po umieszczeniu w wiadomości SIP naleŜącej do danego

zgłoszenia, wszystkich dodatkowych nagłówków, następuje wysłanie wiadomości do

serwera aplikacyjnego, w którym odbywa się dalsza obsługa związana z

wykonywanie scenariusza usług.

9.3.7 Procedura sterowania usługami dla zgłoszeń wychodzących (Originating

Service Control)

Procedura sterowania usługami dla zgłoszeń wychodzących (Originating Service

Control) wykonywana jest w S-CSCF dla zgłoszeń inicjowanych przez uŜytkownika. S-CSCF

identyfikuje inicjatora zgłoszenia poprzez wartość nagłówka P-Asserted-Identity (patrz

procedura Assert Identity). KaŜdy uŜytkownik, który inicjuje połączenie musi być

zarejestrowany w S-CSCF i podczas procedury rejestracji pobierany jest jego profil z HSS. W

chwili wykonywania procedury Originating Service Control, S-CSCF dysponuje profilem,

który podlega analizie w kontekście procedury sterowania usługami opisanej powyŜej (patrz

Service Control).

Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem

123

9.3.8 Procedura sterowania usługami dla zgłoszeń przychodzących

(Terminating Service Control)

Procedura sterowania usługami dla zgłoszeń przychodzących (Terminating Service

Control) wykonywana jest w S-CSCF dla zgłoszeń przychodzących do uŜytkownika. JeŜeli

uŜytkownik, do którego jest kierowane zgłoszenie jest zarejestrowany w systemie IMS to

dalsza analiza w kontekście sterowania usługami oparta jest o profil, który jest w dyspozycji

S-CSCF. JeŜeli uŜytkownik nie jest zarejestrowany, to S-CSCF wykonuje procedurę Cx-

Server-Assigment, której rezultatem jest pobranie z HSS profilu nie zarejestrowanego

uŜytkownika (patrz Rys. 54). Dalsza obsługa odbywa się zgodnie z opisem powyŜej (patrz

Service Control).

9.4 Zaimplementowany proces rejestracji uŜytkownika i realizacja

mobilności w sieci

Głównym zadaniem zaimplementowanych mechanizmów związanych z rejestracją

uŜytkownika jest umoŜliwienie realizacji mobilności terminali uŜytkowników w środowisku

badawczym oraz zamodelowanie zcentralizowanego repozytorium profili uŜytkowników

(jedna z funkcji HSS).

Rys. 59 przedstawia uproszczony przepływ wiadomości sygnalizacyjnych mających

miejsce w procesie rejestracji uŜytkownika. W poszczególnych miejscach tego rysunku

zaznaczone są takŜe momenty, w których są wykonywane zaimplementowane procedury.

Procedury te zostały opisane w rozdziale 9.1.

Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem

124

5. Cx-U

AR

7. Cx-U

AA 9. C

x-MAR

11. Cx-M

AA

20. Cx-SAR

22. Cx-S

AA

Rys. 59: Proces rejestracji uŜytkownika w systemie IMS (środowisko badawcze)

Szczegółowy opis procesu rejestracji:

1. Agent uŜytkownika zaimplementowany w terminalu wysyła do P-CSCF121 wiadomość

REGISTER protokołu SIP.

2. P-CSCF tworzy nową transakcje dla zgłoszenia i modyfikuje R-URI122 wiadomości,

wstawiając w to pole adres serwera I-CSCF.

3. Wiadomość REGISTER kierowana jest do I-CSCF.

4. I-CSCF rozpoczyna wykonywanie procedury User-Registration-Query, której celem

jest uzyskanie adresu serwera S-CSCF.

5. I-CSCF wysyła wiadomość Cx-User-Authentication-Request123 do HSS, w której

zawarty jest publiczny (PUI) i prywatny (PRUI) identyfikator uŜytkownika.

6. HSS wykonuje procedurę Cx-User-Authentication, której celem jest sprawdzenie

poprawności identyfikatorów uŜytkownika i wybranie serwera S-CSCF124.

121 W środowisku badawczym adres serwera P-CSCF jest konfigurowalnym parametrem terminala uŜytkownika. W systemie IMS, adres P-CSCF moŜe być uzyskany przez terminal poprzez protokół DHCP, albo podczas tworzenie kontekstu PDP w sieci GPRS. 122 Request-URI (opis w rozdziale 2). 123 Jest to wiadomość interfejsu Cx (patrz [9]) oparta o protokół ‘Diameter’. 124 W środowisku badawczym został zaimplementowany jeden serwer S-CSCF.

Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem

125

7. HSS wysyła wiadomość Cx-User-Authentication-Answer do I-CSCF, która zawiera

adres serwera S-CSCF wybranego do obsługi uŜytkownika.

8. I-CSCF przesyła wiadomość REGISTER do S-CSCF.

9. S-CSCF przesyła wiadomość Cx-Multimedia-Authorization-Request do HSS, w celu

uzyskania parametrów potrzebnych do uwierzytelnienia uŜytkownika.

10. HSS wykonuje procedurę Cx-Multimedia-Authorization, w której generowany jest

parametr potrzebny do uwierzytelnienia125.

11. HSS wysyła wiadomość Cx-Multimedia-Authorization-Answer, która zawiera dane

potrzebne do uwierzytelnienia.

12. S-CSCF przesyła wiadomość protokołu SIP ‘401 Unauthorized’, której celem jest

poinformowanie agenta uŜytkownika o potrzebie zawarcia w Ŝądaniu rejestracji

danych wymaganych do uwierzytelnienia.

13. I-CSCF przesyła wiadomość ‘401 Unauthorized’ do P-CSCF.

14. P-CSCF przesyła widomość ‘401 Unauthorized’ do agenta uŜytkownika.

15. W terminalu końcowym są generowane parametry uwierzytelniające.

16. Agent uŜytkownika powtórnie wysyła wiadomość REGISTER z załączonymi

parametrami potrzebnymi do uwierzytelnienia.

17. P-CSCF przesyła wiadomość REGISTER do I-CSCF

18. I-CSCF przesyła wiadomość REGISTER do S-CSCF, którego adres wcześniej został

pobrany z HSS.

19. S-CSCF wykonuje procedurę Registration-Notification polegającą na sprawdzeniu

poprawności danych uwierzytelniających i pobraniu profilu uŜytkownika z HSS126.

20. S-CSCF wysyła wiadomości Cx-Server-Assigment-Request do HSS, która zawiera

informacje o poprawnym uwierzytelnieniu.

21. HSS przeprowadza procedurę Cx-Server-Assigment polegającą za zapisaniu informacji

o poprawnym przydzieleniu uŜytkownikowi danego serwera S-CSCF.

125 Dane potrzebne do uwierzytelnienia uŜytkownika w systemie IMS składają się z wielu parametrów (opis w 3GPP TS 33.203). Na potrzeby środowiska badawczego ten model został uproszczony i uwierzytelnienie odbywa się za pomocą algorytmu EAP-MD5, w którym parametrem jest skrót (MD5) hasła uŜytkownika.

Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem

126

22. HSS wysyła wiadomość Server-Assigment-Answer, której najwaŜniejszą częścią jest

profil rejestrującego się uŜytkownika.

23. S-CSCF potwierdza poprawność rejestracji agentowi uŜytkownika przesyłając

wiadomość ‘200 OK’127.

24. I-CSCF przesyła wiadomość ‘200 OK’ do P-CSCF.

25. P-CSCF przesyła wiadomość ‘200 OK’ do agenta uŜytkownika.

Mobilność uŜytkowników zapewniona jest poprzez elementy HSS i S-CSCF. HSS w

procedurze rejestracji uŜytkownika, wybiera serwer S-CSCF128 (punkt 6) i po poprawnym

uwierzytelnieniu i autoryzacji, zapisuje jego adres w profilu uŜytkownika (punkt 21). Dzięki

temu, informacja o adresie S-CSCF, który aktualnie obsługuje uŜytkownika zawsze jest

dostępna w HSS.

S-CSCF integruje w sobie funkcje SIP-Registrar (patrz rozdział 2) tj. w procesie

rejestracji uzyskuje informacje o skojarzeniu pomiędzy aktualnym sieciowym adresie

terminala uŜytkownika (FQDM)129, a publicznym identyfikatorem (AOR)130 tego

uŜytkownika. UmoŜliwia to S-CSCF kierowanie wiadomości SIP adresowanych przy pomocy

publicznych identyfikatorów (PUI) do konkretnych terminali przyłączonych do sieci IP.

Informacja o sieciowym adresie terminala uŜytkownika identyfikującego się publicznym

identyfikatorem (PUI) jest moŜliwa do uzyskania w 2 krokach:

1. pytanie do HSS o profil uŜytkownika identyfikującego się poprzez PUI;

2. odczyt z profilu, adresu obsługującego S-CSCF i translacja PUI na adres sieciowy

zgodnie z asocjacją AOR->FQDM w S-CSCF.

127 Zgodnie z [7] po popraniu profilu uŜytkownika, S-CSCF powinien wykonać tzw. procedurę „rejestracji przez trzecią stronę” (z ang. Third-Party Registration) polegającą na rejestracji uŜytkownika przez S-CSCF we wszystkich serwerach aplikacyjnych, których adresy są zawarte w profilu. Ze względu na małe znaczenie tego mechanizmu w analizowanych zagadnieniach w implementowanym środowisku badawczym został on pominięty. 128 Według specyfikacji IMS, HSS moŜe teŜ wybrać listę serwerów S-CSCF. 129 Np. terminal przyłączony do sieci pod adresem IP = 10.10.10.10 i nasłuchujący wiadomości SIP na porcie UDP = 8060 posiada adres URI = sip:10.10.10.10:8060. Jest to tak zwany FQDN (Fully qualified domain name) jednoznacznie określający host w sieci IP. 130 Np. sip:[email protected]. Publiczny identyfikator jest wykorzystywany w S-CSCF jako tzw AOR (Address of routing), który w skojarzeniu z FQDM umoŜliwia routing wiadomości.

Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem

127

2. Ŝadanie profilu

3. profil ‘sip:ala@

eims.local’

4. IN

VITE

sip:ala@

eim

s.lo

cal

5. IN

VITE

sip:ala@

10.10.10.10:8060

Rys. 60: Realizacja mobilności

Rys. 60 ilustruje poszczególne zdarzenia, które zachodzą w sieci, aby zapewnić

moŜliwość realizacji mobilności. Adresatem zgłoszenie przychodzącego do serwera S-

CSCF#1 jest uŜytkownik, aktualnie obsługiwany przez inny serwer S-CSCF (patrz punkt 1 z

Rys. 60). Aby moŜliwa była realizacji poprawnego kierowania ruchu, S-CSCF#1 pobiera z

HSS profil wywoływanego uŜytkownika, który zawiera informacje o adresie serwera S-

CSCF, aktualnie obsługującego uŜytkownika (punkty 1-2). Gdy zgłoszenie trafi do

właściwego serwera S-CSCF następuje skierowanie widomości na fizyczny adres terminala, z

którego uŜytkownik zarejestrował swój publiczny identyfikator (punkt 5)131.

9.5 Model sterowania usługami z wykorzystaniem federacji

serwerów aplikacyjnych

Podstawą modelu sterowania usługami w IMS jest mechanizm kierowania zgłoszeń do

odpowiednich serwerów aplikacyjnych, zgodnie z regułami zawartymi w profilu,

przechowywanym w centralnym miejscu w sieci tzn. w elemencie HSS. Skierowanie obsługi

131 Ten model zarządzania mobilnością zaproponowany w ramach systemu IMS jest wzorowany na rozwiązaniach stosowanych w sieci GSM. W sieci komórkowej GSM informacja o fizycznej „lokalizacji” uŜytkownika jest dostępna w VLR skojarzonym z centralą MSC, a informacja o tym, pod którym VLR jest obsługiwany dany uŜytkownik jest zawarta w profilu w HLR. Poprawna realizacja zgłoszeń w MSC odbywa się poprzez mechanizm „odpytania” HLR o aktualny adres VLR obsługującego uŜytkownika. Istnieje silna analogia pomiędzy HSS i S-CSCF, a HLR i MSC/VLR.

Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem

128

zgłoszenia do serwera aplikacyjnego jest realizowane poprzez wiadomości sygnalizacyjne,

które są wykorzystywane do zestawienia połączenia. Realizacja usług polega na interakcji ich

scenariuszy (implementowanych przez serwer aplikacyjny), z wiadomościami

sygnalizacyjnymi protokołu SIP generowanymi przez agentów uŜytkownika.

Decyzja czy dane zgłoszenie będzie skierowane do określonego serwera aplikacyjnego

jest podejmowana w serwerze S-CSCF na podstawie profilu uŜytkownika. Reguły

przekierowania zgłoszenia oparte są o analizę syntaktyczną wiadomości SIP. Profil

zawierający filtry IFC (patrz rozdział 3), definiuje rodzaje wiadomości (nazwy wiadomości

sygnalizacyjnych, np. INVITE, BYE, SUBSCRIBE, itd.), występowanie lub nie określonych

nagłówków we wiadomościach SIP oraz elementy opisu sesji zawartej w SDP. IFC ma postać

wyraŜeń złoŜonych z tych reguł w odpowiednich relacjach logicznych132. Tab. 5 pokazuje

parametry, które umoŜliwiają konstruowanie kryteriów IFC

Tab. 5: Reguły budowy kryteriów filtracji - IFC

Parametry do budowy

kryteriów filtracji

Znaczenie i moŜliwe wartości Przykład zastosowania

Request-URI Określa, do jakiego węzła SIP jest adresowana wiadomość. Zazwyczaj przyjmuje wartość publicznego identyfikatora wywoływanego uŜytkownika. Np. sip:[email protected]

Stosuje się zawsze tam, gdzie przy konstrukcji reguły waŜne jest, do kogo jest adresowana sesja. Przykładowo, jeŜeli serwer aplikacyjny realizuje usługę polegającą na blokowaniu połączeń na określony adres.

rodzaj Ŝądania MoŜe przyjmować wartości określające rodzaje Ŝądań. Np. INVITE, BYE, SUBSCRIBE, itd.

W przypadku usługi obecności, reguła przekierowania powinna uwzględniać wiadomości SUBSCRIBE i PUBLISH, które powinny być kierowane do serwera obecności133.

wartość określonego nagłówka

Składa się z nazwy nagłówka oraz z wartości, którą przyjmuje. Reguła wykorzystująca to pole moŜe stosować dowolne nagłówki. Np. ‘P-Access-Network-Info:

Nagłówki w wiadomościach SIP przenoszą bardzo wiele informacji. Przykładowo, jeśli obsługa w serwerach aplikacyjnych jest zaleŜna od sieci dostępowej uŜytkownika to moŜna do

132 Przekazywanie zgłoszenia do danego serwera aplikacyjnego w IMS oparte jest o syntaktyczna analizę wiadomości SIP. W modelu sieci inteligentnej (IN) przekazanie zgłoszenia do obsługi w SCP odbywa się w oparciu o analizę semantyczną tj. w oparciu o tzw. model BCSM (Basic Call State Model), który definiuje stany w realizacji połączenia. 133 Z dodatkowym warunkiem, określającym, Ŝe nagłówek ‘Event’ przyjmuje wartość ‘presence’.

Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem

129

access-type=3GPP-GERAN’ albo ‘P-Asserted-Identity: [email protected]

rozróŜnienia zgłoszeń pochodzących z róŜnych sieci wykorzystać nagłówek ‘P-Access-Network-Info’, który przyjmuje wartość określające technikę dostępową z której korzysta dany uŜytkownik.

rodzaj sesji MoŜe przyjmować 3 wartości: 0 – dla połączeń wychodzących 1 – dla przychodzących 2 – dla przychodzących do niezarejestrowanego uŜytkownika

KaŜda reguła musi być przyporządkowana do określonego rodzaju sesji. Część usług jest wywoływana podczas zgłoszeń przychodzących (1 i 2) a część dla wychodzących (0). Przykładem zastosowania moŜe być usługa przekierowania sesji na inny adres wtedy, gdy dany uŜytkownik jest poza zasięgiem. W regule dla tego przypadku parametr rodzaj sesji przyjmowałby wartość 2.

parametry połączenia

Zawiera wyraŜenia regularne, które odnoszą się do SDP.

SDP zawiera informacje takie jak: rodzaj sesji medialnej (audio, wideo), kodowanie albo parametry QoS Ŝądane dla tego połączenia.

Analiza wiadomości SIP uwzględniająca reguły, złoŜone z parametrów zamieszonych w

Tab. 5, jest mechanizmem niskiego poziomu, odnoszącym się do składni przetwarzanych

wiadomości. Takie rozwiązanie daje bardzo duŜą elastyczność, ale wprowadza pewnego

rodzaju niejednoznaczność, polegającą na braku bezpośredniego odniesienia pomiędzy

usługami realizowanymi na serwerach aplikacyjnych, a kryteriami przekierowania. IFC

odnoszą się do składni protokołu, a nie do semantyki usług, które powinny wyzwalać.

Projektowanie reguł filtracji wymaga wypracowania tzw. „dobrych praktyk”, które dla dobrze

zdefiniowanych usług, oferowałyby gotowe najlepsze reguły IFC.

Profil uŜytkownika moŜe być złoŜony z wielu reguł odnoszących się do róŜnych usług i

skojarzonych z róŜnymi serwerami aplikacyjnymi. Potrzeba obsługi zgłoszenia przez wiele

serwerów aplikacyjnych wymaga prioryteryzacji kolejności przekierowań wiadomości SIP do

odpowiednich AS134. Rys. 61 pokazuje drogę wiadomości SIP podczas obsługi zgłoszenia w

wielu AS. KaŜdorazowo serwer S-CSCF dokonuje analizy profilu i przekierowania

134 Priorytet serwera aplikacyjnego jest zawarty w definicji IFC.

Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem

130

widomości do AS o odpowiednim priorytecie. Wynikiem tego mechanizmu jest przejście

wiadomości SIP przez tzw. „łańcuch serwerów aplikacyjnych”

S-CSCF

AS AS AS

uŜytkownik #A uŜytkownik #B

profil

sygnalizacja (SIP)

dane uŜytkowników (strumienie RTP)

Rys. 61: Sekwencyjne przetwarzanie zgłoszenia tzw. "ła ńcuch serwerów aplikacyjnych"

KaŜdy AS moŜe, zgodnie z logiką usługi, jaką realizuje, dokonać zakończenia

zgłoszenia. Powoduje to przerwanie „łańcucha serwerów aplikacyjnych” i AS, które

występują w profilu, a jeszcze nie brały udziału w obsłudze, są pomijane.

Serwer aplikacyjny (AS) otrzymując przekierowaną z S-CSCF wiadomość inicjującą

zgłoszenie, moŜe dokonać tzw. „zakotwiczenia” sesji. Polega to na odpowiedniej modyfikacji

wiadomości inicjującej, która jest zwracana do S-CSCF. Przy „zakotwiczonej” sesji w AS,

wszystkie wiadomości sygnalizacyjne protokołu SIP, które są wymieniane pomiędzy

terminalami uŜytkowników w ramach sesji, są kierowane poprzez „zakotwiczony” serwer

aplikacyjny.

S-CSCF

AS

uŜytkownik #A

sygnalizacja

(SIP)

uŜytkownik #B

1. IN

VITE

2. IN

VITE

4. IN

VITE

5. INVITE

6. 200 OK

7. 200 O

K

8. 200 O

K

9. 200 OK

3. wykonanie logiki usługi +

ewentualna modyfikacja

wiadomości INVITE

S-CSCF

AS

uŜytkownik #A uŜytkownik #B

1. BYE

2. BYE

3. BYE

4. BYE

S-CSCF

AS

uŜytkownik #A uŜytkownik #B

1. BYE 2. B

YE

1. 2a. 2b.

Rys. 62: Mechanizm "zakotwiczania" sesji SIP przez serwer aplikacyjny (AS)

Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem

131

Rys. 62 pokazuję obsługę zgłoszenia przez serwer aplikacyjny w róŜnych wariantach.

W punkcie 1. następuje inicjacja sesji za pomocą wiadomości INVITE, która jest

przekierowana do AS, który wykonuje logikę usługi. Wariant 2a. pokazuje scenariusz

zakończenia tej sesji w przypadku „zakotwiczenia” (wiadomość BYE jest kierowana do AS),

a wariant 2b. pokazuje scenariusz bez „zakotwiczenia”, w którym AS nie uczestniczy w

wymianie wiadomości BYE.

Serwer aplikacyjny, aby „zakotwiczyć” sesje wykorzystuje mechanizm kierowania

wiadomości protokołu SIP tj. tzw. „loose routing”135. Na Rys. 63 pokazany jest przepływ

wiadomości inicjującej sesje tj. wiadomości INVITE, która z S-CSCF zostaje skierowana do

AS. Aby dokonać „zakotwiczenia” AS modyfikuje wiadomość dodając do niej nagłówek

Record-Route zawierający adres danego AS. Zgodnie z mechanizmem „loose routing”,

terminal uŜytkownika w kolejnych wiadomościach w ramach sesji (tj. w ramach dialogu

protokołu SIP) będzie umieszczał informacje (w nagłówku Route), Ŝe dana wiadomość

powinna być skierowana na dany serwer aplikacyjny. W ten sposób kaŜda widomość w

ramach sesji będzie kierowana poprzez serwer aplikacyjny.

Rys. 63: Rola nagłówka 'Record-Route' w mechanizmie "zakotwiczenia" sesji

„Zakotwiczanie” sesji w AS jest silnie zaleŜne od logiki usługi, która jest realizowana.

Jeśli dana usługa wymaga kontrolowania sesji od jej inicjacji, aŜ do zakończenia niezbędne

135 Mechanizm „loose routing” jest opisany w [22].

Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem

132

jest „zakotwiczenie”. Natomiast w przypadku, gdy tylko moment inicjacji sesji jest istotny dla

realizacji danej usługi, „zakotwiczenie” nie jest potrzebne.

Obsługa sesji przez wiele serwerów aplikacyjnych jednocześnie umoŜliwia realizacje

wielu niezaleŜnych usług dla pojedynczego zgłoszenia. Rozwiązanie polegające na

kierowaniu przez S-CSCF wiadomości SIP do poszczególnych AS zgodnie z priorytetem

zapisanym w profilu uŜytkownika, wymusza zwiększony ruch sygnalizacyjny. KaŜde

przekierowanie do AS skutkuje ok. dwunastoma136 dodatkowymi wiadomościami

sygnalizacyjnymi.

Rys. 64: Typowy przepływ wiadomości inicjuj ącej sesje (z uwzględnieniem obsługi w AS)

Rys. 64 pokazuje przepływ wiadomości na styku pomiędzy S-CSCF a AS. KaŜde

wywołanie serwera aplikacyjnego w obsłudze zgłoszenia wymaga pośrednictwa AS we

wszystkich wiadomościach danej transakcji137 inicjującej, a w przypadku „zakotwiczenia”

całej sesji (dialogu SIP). Problem tak duŜego narzutu sygnalizacyjnego szczególnie jest

istotny w przypadku obsługi zgłoszenia przez kilka serwerów aplikacyjnych jednocześnie,

poniewaŜ wtedy ruch sygnalizacyjny rośnie wprost proporcjonalnie do ilości AS biorących

udział w obsłudze.

136 Dla typowego scenariusza inicjacji sesji bez uwzględnienia negocjacji parametrów QoS. 137 Transakcji protokołu SIP.

Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem

133

9.6 Interakcje pomiędzy usługami i serwerami aplikacyjnymi

Usługi w modelu IMS realizowane są za pomocą serwerów aplikacyjnych, do których

kierowane są zgłoszenia (sekwencje wiadomości SIP) zgodnie z profilem uŜytkownika. Profil

zawiera tzw. kryteria filtracji (IFC), które są regułami przekazania danego zgłoszenia do

odpowiedniego serwera aplikacyjnego. Mechanizm ten oparty jest o syntaktyczną analizę

wiadomości SIP polegającą na filtracji wiadomości za pomocą „pseudo” wyraŜeń regularnych

wychwytujących róŜne składowe wiadomości SIP (np. nagłówki i ich wartości, składowe

SDP).

Definicja IFC musi odzwierciedlać zakres funkcji, które są realizowane przez dany

serwer aplikacyjny. Rys. 65 ilustruje przykład, w którym AS pełni funkcje serwera obecności

(Presence Server). Reguły IFC zawierają wyraŜenia określające, Ŝe wiadomości PUBLISH i

SUBSCRIBE138 dla zgłoszeń przychodzących powinny być skierowane właśnie do tego

serwera aplikacyjnego, czyli właściwego serwera obecności. Obsługa innych zgłoszeń

(zgłoszenie 2) nie jest przekazywana do AS.

2. PUBLISH

3. 200 O

K

Rys. 65: ZaleŜność pomiędzy IFC a funkcją realizowaną przez dany AS (na przykładzie serwera

obecności)

Występowanie problemów opisanych w rozdziale 9.5, związanych z przeciąŜeniem

wiadomościami sygnalizacyjnymi nakłada wymaganie, aby definicje filtracji (IFC) bardzo

szczegółowo określały zakres zgłoszeń, których obsługa będzie kierowana do serwera

aplikacyjnego. Dzięki takiej precyzyjnej, uwzględniającej specyfikę logiki realizowanej na

AS definicji, moŜliwe jest obsługiwanie zgłoszeń na wielu serwerach aplikacyjnych, które

138 Znaczenie wiadomości SUBSCRIBE i PUBLISH w realizacji usługi obecności wyjaśniona jest w rozdziale 10.5

Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem

134

realizują róŜne usługi. KaŜde zgłoszenie jest kierowane do właściwego AS zgodnie z IFC

zawartym w profilu. Taki mechanizm umoŜliwia częściowe rozwiązanie problemów

związanych z interakcjami pomiędzy usługami, ale tylko, jeśli są one realizowane na róŜnych

serwerach aplikacyjnych. Jeśli w sieci jest więcej niŜ jeden AS wymagający obsługi danego

zgłoszenia, to realizacja usług następuje sekwencyjne, zgodnie z mechanizmem „łańcucha

serwerów aplikacyjnych”, który został opisany w rozdziale 9.5. Kolejność obsługi

uzaleŜniona jest od priorytetu podanego w IFC.

Jeden Serwer aplikacyjny moŜe wykonywać scenariusz jednej usługi lub wielu usług.

Takie modele implementacji są pokazane na Rys. 66, który przedstawia moŜliwy podział AS

na dwa rodzaje: dedykowany, czyli taki który realizuje tylko jedną usługę i ogólnego

zastosowania, realizujący kilka niezaleŜnych usług.

Rys. 66: Dwa modele serwerów aplikacyjnych: ogólnego zastosowania i dedykowany

W przypadku AS ogólnego zastosowania, pojawia się powaŜny problem związany z

interakcjami pomiędzy usługami w ramach jednego serwera aplikacyjnego. W modelu z

dedykowanymi AS, interakcje rozwiązywane są za pomocą filtracji IFC oraz „łańcucha

serwerów aplikacyjnych”, czyli S-CSCF zarządza potrzebą i kolejnością wykonywania usług

korzystając z profilu uŜytkownika. Natomiast w przypadku wielu niezaleŜnych usług

realizowanych na jednym AS, zasadność obsługi zgłoszenia i kolejność musi być

rozstrzygana wewnętrznie tj. w ramach danego AS. Aby rozwiązać problem interakcji

pomiędzy usługami w IMS został wprowadzony element funkcjonalny SCIM (Service

Capability Interaction Module), który jest częścią składową serwera aplikacyjnego (patrz

Rys. 67).

Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem

135

S - CSCF S - CSCF

SIP Application Server

SIP Application Server

HSS HSS OSA service

capability server (SCS)

OSA service capability server

(SCS)

IM - SSF IM - SSF

Camel Service Environment

Camel Service Environment

OSA application

server

OSA application

server

ISC

Cx ISC

ISC

CAP MAP

OSA API

SCIM

AS AS

Sh

Si

Rys. 67: Architektura funkcjonalna warstwy aplikacyjnej IMS ( źródło [3])

W modelu implementacji wielu usług na jednym serwerze aplikacyjnym reguły

„filtracji” wiadomości SIP muszą być analizowane dwa razy dla zgłoszenia, tj. w serwerze S-

CSCF oraz w danym AS zawierającym komponenty aplikacyjne realizujące usługi. Rys. 68

ilustruję te mechanizmy. Przychodząca wiadomość (patrz 1.) od uŜytkownika A do

uŜytkownika B jest zgodnie z regułami zawartymi w profilu pobranym z HSS, kierowana do

AS (wiadomość 2.). Następnie, w ramach wewnętrznych mechanizmów

zaimplementowanych w AS, zgłoszenie jest dystrybuowane do odpowiednich komponentów

aplikacyjnych.

Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem

136

usługa #A

usługa #B

usługa #C

usługa #D

2.

7.

profil

3.

4.

5.

6.

Rys. 68: Rola SCIM w obsłudze zgłoszenia w ramach serwera aplikacyjnego

Warte zauwaŜenia jest to, Ŝe dokumenty 3GPP definiujące IMS specyfikują tylko

mechanizm filtracji w S-CSCF bazujący na profilu uŜytkownika. Funkcje SCIM są

definiowane tylko w bardzo ogólny, koncepcyjny sposób i większość mechanizmów SCIM

zaleŜy od implementacji danego serwera aplikacyjnego.

Implementacja wielu usług na jednym serwerze aplikacyjnym jest korzystna ze względu

na oszczędność zasobów związanych z mocą obliczeniową serwerów oraz ze względu na

ograniczenie ruchu sygnalizacyjnego na styku pomiędzy S-CSCF a AS. Negatywną strona

takiego modelu jest to, Ŝe aplikacje realizujące usługi są silnie związane ze środowiskiem

specyficznym dla danego serwera aplikacyjnego, co skutkuje ich ograniczoną

przenaszalnością do innych AS.

10. Analiza i implementacja interfejsów Parlay X w

modelu usługowym IMS

IMS pozostawia duŜą swobodę przy implementacji aplikacji realizujących usługi.

MoŜemy skorzystać z wielu technik139, dla których środowiskiem uruchomieniowym są

serwery aplikacyjne, np.: omawiany JSLEE (patrz rozdział 1), ale i nie tylko. Wybór

odpowiedniej techniki powinien być umotywowany zarówno wymaganiami technicznymi

(aspekty bezpieczeństwa i skalowalności, wybór pomiędzy środowiskiem webowym, a

aplikacją stacjonarną, etc..) jak i równieŜ biznesowymi (kto będzie tworzył aplikacje, kto jest

odbiorcą aplikacji, jaki model biznesowy jest optymalny, etc..).

Spośród dostępnych technik i propozycji modeli warstwy aplikacyjnej autorzy

wybrali140 ten najbardziej złoŜony141. Struktura wybranego modelu warstwy aplikacyjnej

została pokazana na Rys. 41, natomiast techniki uŜyte do jej implementacji to Parlay X (patrz

rozdział 1) i JSLEE. W ostateczności JSLEE został zastąpiony techniką JAIN, poniewaŜ przy

analizie i próbie stworzenia przykładowej aplikacji w implementacji JSLEE pod nazwą

Mobicents142, okazało się, Ŝe aplikacja nie zachowywała się stabilnie i deterministycznie. W

139 PobieŜny przegląd technik wykorzystywanych do implementacji usług telekomunikacyjnych w IMS został zawarty w [13]. Warto zwrócić uwagę, iŜ do celów tworzenia usług w IMS zaadoptowano istniejące juŜ techniki webowe: np. servlety, czy teŜ implementowane przez autorów Web Services Parlay. 140 Początkowo rozwaŜaliśmy wybór techniki, którą mieliśmy wykorzystać do implementacji aplikacji usługowej Własne Centrum Komunikacyjne zarówno od strony biznesowej, jak i od strony technicznej. Stwierdziliśmy jednak, iŜ wybór powinien zostać dokonany wyłącznie pod kątem technicznym ze względu na fakt, iŜ implementowane środowisko ma charakter wyłącznie czysto badawczy, a skupienie się nad jedną kwestią pozwoli szczegółowej i precyzyjniej omówić jej zalety i wady. Nie czuliśmy się równieŜ na siłach, aby zabierać głos w kwestiach biznesowych. 141 Po wstępnej analizie projektów związanych z Parlay/OSA i Parlay X zauwaŜyli śmy, Ŝe wszystkie omawiają kwestię wykorzystania Parlay X do implementacji usług, natomiast Ŝaden nie dyskutuje problematyki implementacji samych interfejsów Parlay X. Uznaliśmy, Ŝe jest to ciekawe zagadnienie i postanowiliśmy przyjrzeć się jemu uwaŜniej w naszej pracy. Poza tym nie spotkaliśmy się równieŜ z pomysłem implementacji Parlay X jako aplikacji JSLEE, a co za tym idzie, jakie konsekwencje ze sobą moŜe nieść takie podejście. Dodatkową korzyścią płynącą z wyboru najbardziej złoŜonego modelu usługowego jest chęć zaobserwowania równieŜ kwestii czysto fizycznych tj. wydajność, przeciąŜenie, opóźnienia, itp.. 142 NaleŜy przypomnieć, Ŝe jest to projekt open source, w którym wiele rzeczy pozostaje tajemnicą nawet dla jego twórców. Znaleźli śmy róŜnego rodzaju niedomówienia w jego implementacji, a ich naprawa mogła by być dobrym tematem na kolejną pracę magisterską lub inŜynierską, ze względu na duŜą złoŜoność projektu. RównieŜ wbrew pozorom duŜa złoŜoność procesu przygotowywania aplikacji (deskryptory, duŜa liczba typy obiektów, brak dokumentacji, itp..) bez wsparcia narzędzi programistycznych uniemoŜliwia pisanie bardziej zaawansowanych aplikacji.

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

138

efekcie JAIN okazał się pouczającym wyborem, poniewaŜ pozwolił poznać zarówno wady

jak i zalety względem wcześniej przeanalizowanej techniki JSLEE.

Rys. 69: Interfejsy Parlay X

Na Rys. 69 pokazano interfejsy, które obejmuje specyfikacja Parlay X, a na zielono

zaznaczono, te które zostały zaimplementowane. W procesie wyboru tych interfejsów

kierowano się późniejszą moŜliwością stworzenia aplikacji143, której funkcjonalność

pozwalałby na zarządzanie własną komunikacją w sieci stacjonarnej (przekierowanie

połączeń, blokowanie połączeń, zestawienia połączenia pomiędzy dwoma stronami, usługa

obecności, etc..).

10.1 Sterowanie zestawianiem połączeń przez trzecią stronę

(interfejs Third Party Call)

10.1.1 Definicja i zastosowania

Third Party Call Control (3PCC) jest terminem określającym funkcjonalność oraz

mechanizm umoŜliwiający zestawienie i zarządzanie sesją komunikacyjną przez Trzecią

Stronę pomiędzy dwoma lub większą liczbą uczestników (Stronami)144. Trzecia Strona

nazywana jest równieŜ Sterownikiem (Controller). W rozumieniu powyŜszej definicji moŜe to

być dowolny SIP User Agent. Do zestawienia sesji komunikacyjnej wykorzystywane są

mechanizmy zdefiniowane w specyfikacji protokołu SIP. Ze względu na duŜą elastyczność

143 Aplikacja ta została omówiona w rozdziale11. 144 Definicja Third Party Call Control została zaczerpnięta z [26]. Ze względu na charakter interfejsów Parlay X: Third Party Call Control w dalszej części tego opracowania będzie rozwaŜane zestawienie połączenia wyłączenie pomiędzy dwoma stronami.

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

139

protokołu SIP istnieje wiele sposobów realizacji 3PCC145. Te róŜne podejścia zostaną

przedstawione w 10.1.3.

Jako przykład zastosowania 3PCC warto wskazać usługę Click-to-Call , dla której

przykładowy scenariusz został przedstawiony poniŜej (patrz Scenariusz 1). Dla tej usługi

3PCC rozszerza funkcjonalność rozwiązań webowych. Pojawia się w związku z tym potrzeba

stworzenia narzędzi umoŜliwiających budowę tego typu usług w standardowy sposób.

Jednym z takich narzędzi jest interfejs Pralay X: Third Party Call Control wykorzystujący

Web Services.

Scenariusz 1: Przykładowy scenariusz dla usługi Click-to-Call

UŜytkownik przeglądając stronę internetową pewnej firmy jest zainteresowany jednym z ich

produktów. Obok opisu produktu znajduje się formularz click-to-call. Po wprowadzeniu

swojego numeru telefonu, firma zestawi automatycznie połączenie pomiędzy nim, a

odpowiednim konsultantem.

10.1.2 Specyfikacja interfejsu

Interfejs Third Party Call Control został wyspecyfikowany w dokumencie146 [8].

Funkcjonalność interfejsu Third Party Call Control pozwala na:

� zestawienie sesji – funkcja:

xsd:string MakeCall(xsd:anyURI CallingParty, xsd:anyURI CalledParty)

Parametrami dla tej funkcji są adresy stron w postaci URI, pomiędzy którymi ma

być zestawiona sesja. Funkcja zwraca unikalny CallIdentifier, który moŜna

wykorzystać do zarządzania zgłoszeniem i monitorowania jego stanu.

� zakończenie sesji – funkcja:

void EndCall(xsd:string CallIdentifier)

Parametrem wejściowym dla tej funkcji jest identyfikator połączenia, który został

zwrócony przez funkcję MakeCall(...) przy zestawianiu połączenia.

� anulowanie zestawiania sesji – funkcja:

void CancelCall(xsd:string CallIdentifier)

145 Charakter dokumentów IETF, w których została zawarta specyfikacja protokołu SIP pozwala na dość swobodne wykorzystywanie wiadomości SIP. Wynika to z braku jednoznacznego opisu protokołu jako np. automatu FSM (brak definicji stanów i wszystkich moŜliwych przejść pomiędzy nimi). 146 Szczegółowy opis interfejsów został zapisany przy uŜyciu języka WSDL 1.2 i załączony jako pliki XML do specyfikacji.

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

140

� określenie stanu sesji – funkcja

xsd:CallInformation GetCallInformation(xsd:string CallIdentifier)

Funkcja ta pozwala uzyskać informacje na temat stanu połączenia o danym

CallIdentifier. MoŜe być wywoływana wielokrotnie po przez aplikację nawet po

zakończeniu połączenia, a czas dostępności informacji o zgłoszeniu po jego

zakończeniu określa zmienna StatusRetentionTime .

Na Rys. 70 wyszczególniono funkcje, które zostały zaimplementowane w serwerze

sterowania połączeniami.

CancelCall

EndCall

GetCallIn

form

atio

n

MakeCall

Rys. 70: Funkcje interfejsu Parlay X: Third Party Call Control

10.1.3 Propozycje rozwiązania problemu

Problematykę 3PCC moŜna podzielić na 4 części: proces zestawienia sesji, informacje o

sesji, modyfikacje sesji oraz zakończenie sesji. W kaŜdym z tych procesów mogą wystąpić

sytuacje wyjątkowe147. Jednak ze względu na fakt, iŜ tematyka 3PCC nie jest głównym celem

tej pracy pominięty zostanie wątek sytuacji wyjątkowych, a główny nacisk zostanie połoŜony

na proces zestawiania sesji.

Zestawianie sesji (Call Establishment)

� Sposób I zestawiania sesji przez trzecią stronę

147 Szczegółowa analiza sytuacji wyjątkowych znajduje się w dokumencie IETF RFC 3725 [26].

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

141

Rys. 71: Diagram wiadomości dla sposobu I zestawiania sesji przez trzecią stronę

Przedstawiony na Rys. 71 przepływ wiadomości jest najprostszym sposobem

zestawienia sesji komunikacyjnej. Sterownik rozpoczyna dialog SIP z sip:user_a@eims

wysyłając do niego widomość (1) INVITE bez opisu sesji148. W odpowiedzi otrzymuje ofertę

(2) od sip:user_a@eims, która nie podlegając Ŝadnym modyfikacjom stanowi opis sesji dla

wiadomości (3) INVITE wysłanej do sip:user_b@eims. Sip:user_a@eims odsyła (4)

odpowiedź, która jest jednocześnie odpowiedzią (6) dla sip:user_a@eims. Zadaniem

Sterownika jest przekazywanie SDP bez Ŝadnych modyfikacji, sterownik w tym przypadku

jest praktycznie przeźroczysty dla całego dialogu pomiędzy stroną A i B. Brak jest równieŜ

ograniczeń dotyczących kodeków, wspieranych przez obie strony. Słabą stroną

przedstawionego rozwiązania 3PCC jest natomiast potencjalny problem przekroczenia

czasów oczekiwania na odpowiedź149 (time-out) zdefiniowanych w [22]. W takiej sytuacji

sip:user_a@eims dokonuje retransmisji widomości (2a) 200 OK oczekując na wiadomość (6)

ACK. W przypadku, gdy połączenie nie zostanie zaakceptowane przez sip:user_b@eims w

zdefiniowanym przedziale czasu sip:user_a@eims zakończy dialog z błędem.

� Sposób II zestawiania sesji przez trzecią stronę

148 Opis sesji przenoszony jest za pomocą protokołu SDP – Session Description Protocol [30]. 149 Zgodnie RFC 3261 Sekcja 13.3.1.4 przedział czasowy, w którym następuje cykliczne wysłanie wiadomości 200 OK w trakcie oczekiwania na ACK wynosi 64*T1. Standardowo T1 przyjmuje się 500 ms RFC 3261 Sekcja 17.1.1.2.

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

142

Rys. 72: Diagram wiadomości dla sposobu II zestawiania sesji przez trzecią stronę

W mechanizmie 3PCC zaprezentowanym na Rys. 72 został rozwiązany problem

przekroczenia czasów odpowiedzi, o którym była mowa przy I sposobie zestawiania

połączenia. Dokonano tego poprzez zamknięcie w załoŜonym limicie czasu transakcji

rozpoczętej przez wiadomość (1) i wykorzystaniem funkcjonalności re-INVITE.

Wiadomość (1) INVITE zostaje wysłana z losowo wygenerowanym numerem portu,

konkretnym kodekiem oraz adresem połączenia ustawionym na 0.0.0.0. Jest to tzw. black

holed address150, który sprawia, Ŝe strumień mediów RTP/RTCP nie zostanie wysłany do

sieci. NaleŜy tu wspomnieć, iŜ ze stosowaniem black holed address wiąŜe się

niebezpieczeństwo, Ŝe dana implementacja SIP UA, w odpowiedzi na (2) wyśle równieŜ adres

0.0.0.0, co spowoduje, Ŝe juŜ po zestawieniu sesji media od sip:user_a@eims nie będą

płynęły. Ze względu na wspomnianą wadę mechanizmu black holed address coraz częstszym

podejściem jest zastąpienie jego przez zestaw atrybutów send-only, receive-only151. W tym

przypadku w SDP podaje się normalny adres, na który w przyszłości będą ewentualnie

wysyłane media.

Innym powaŜnym problemem moŜe być powstanie pętli na skutek przesłania w

odpowiedzi (8) innego niŜ w odpowiedzi (2) kodeka. W konsekwencji sterownik powinien

ponownie wynegocjować kodek z sip:user_b@eims dokonując re-INVITE, po czym dokonać

150 Black holed address – mechanizm opisany w [23]. Mechanizm ten rodzi istotne zastrzeŜenia ze względu na uŜycie adresu 0.0.0.0, który w róŜnych rodzajach sieci moŜe być roŜnie interpretowany. Zaleca się, aby jako black holed address uŜywać nazwy nieistniejącej głównej domeny DNS. 151 UŜycie atrybutów send-only i receive-only zostało opisane w [23].

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

143

re-INVITE z sip:user_a@eims. Zakładając, Ŝe sip:user_a@eims zwróci inne SDP niŜ

poprzednio, taki proces moŜe powtarzać się w nieskończoność. Rozwiązaniem, moŜe być

uŜycie inteligentnych UA lub inteligentnego kontrolera, które będą wstanie wykryć taki

przypadek.

� Sposób III zestawiania sesji przez trzecią stronę

Rys. 73: Diagram wiadomości dla sposobu III zestawiania sesji przez trzecią stronę

Prezentowany na Rys. 73 sposób zestawienia sesji przez trzecią stronę rozwiązuje

problemy istniejące w poprzednich sposobach. Po pierwsze Sterownik nie musi nic wiedzieć

na temat rodzaju mediów, gdyŜ w pierwszej widomości (1) INVITE nie zostaje wysłany opis

sesji. Wykorzystanie mechanizmu black holed address sprawia, Ŝe sip:user_a@eims nie

wysyła strumienia mediów. Potencjalne nie występuje równieŜ problem przekroczenia

załoŜonych czasów oczekiwania, gdyŜ wszystkie wiadomości są natychmiast potwierdzane

(ACK). Jedynie istotne jest, aby implementacja SIP UA152 odpowiedziała w załoŜonym

limicie czasu na przesłaną przez Sterownik wiadomość re-INVITE, ze względu na koniczność

zamknięcia transakcji zestawiania połączenia z sip:user_b@eims krok (8).

Wadą tego rozwiązania jest konieczność ingerencji Sterownika w opis sesji. W efekcie

Sterownik ma większą złoŜoność niŜ w poprzednich przypadkach. Słabą stroną jest równieŜ

wykorzystanie mechanizmu black holed address, którego skutki zostały opisane powyŜej.

152 W tym przypadku przesłanie odpowiedzi na drugą wiadomość INVITE w odróŜnieniu od wcześniej analizowanego przypadku realizowane jest automatycznie przez UA.

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

144

NaleŜy równieŜ zauwaŜyć, Ŝe lista mediów w ofercie (2) uzyskana od sip:user_a@eims moŜe

nie pokrywać się z lista mediów w odpowiedzi (5) od sip:user_b@eims. Sterownik w tym

przypadku powinien zakończyć dialog.

� Sposób IV zestawiania sesji przez trzecią stronę

Na diagramie wiadomości IV (patrz Rys. 74) została przedstawiona zmodyfikowana

wersja diagramu III w efekcie, której nastąpiła nieznaczna redukcja złoŜoności. RównieŜ brak

oferty mediów w ciele pierwszej wiadomości (1) INVITE zwalnia Sterownik z konieczności

posiadania informacji na temat mediów obsługiwanych przez sip:user_a@eims.

Rozwiązanie te posiada istotną wadę związaną z brakiem pewności, czy w ramach

zainicjowanej sesji komunikacyjnej strony obsługują wspólny typ mediów i czy faktycznie

pomiędzy stronami będzie moŜliwość zestawienia strumienia mediów. ZauwaŜmy, iŜ dopiero

w kroku (7) następuje potwierdzenie zgodności typu mediów, przy czym strony (np.

uŜytkownicy) zostały poinformowane i odebrały wcześniej (sip:user_a@eims po wiadomości

(2), a sip:user_b@eims po wiadomości (5)) przychodzące zgłoszenie. Sytuacja, w której

połączenie zostało zaakceptowane obustronnie nie przez automat, a przez człowieka moŜe

być dla niego irytująca, gdy na początku przez pewien okres czasu nie słyszy ona swojego

rozmówcy.

sip: user_a@eims

(1) INVITE oferta1 bez mediów

(2) 200 OK odpowiedź2 bez mediów

(4) INVITE bez SDP

(5) 200 OK oferta2

(3) ACK

(8) ACK odpowiedź2

sterownik sip: user_b@eims

(6) INVITE oferta2

(7) OK odpowiedź2

(9) ACK

Strumień Mediów (RTP/RTCP)

<dzwoni>

<dzwoni>

Rys. 74: Diagram wiadomości dla sposobu IV zestawiania sesji przez trzecią stronę

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

145

Tab. 6: Zestawienie cech poszczególnych sposobów realizacji 3PCC.

Diagram I Diagram II Diagram III Diagram IV ZłoŜoność Prosty ZłoŜony Bardzo złoŜony ZłoŜony Black holed153 Nie Tak Tak Nie Problem time-out Tak Nie Nie Nie ZałoŜenia o mediach

Nie Tak Tak Nie

Inne MoŜliwość wystąpienia pętli

Nie ma gwarancji, Ŝe terminale mają zgodne kodeki

W efekcie, moŜe nie zostać zestawiony strumień mediów

Kończenie sesji

Od momentu zestawienia sesji, strony nie mają świadomości, iŜ pomiędzy nimi

znajduje się Sterownik. Co prawda Sterownik nie pośredniczy w wymianie strumienia

mediów jednak transakcja SIP związana z zakończeniem sesji komunikacyjnej powinna być

realizowana równieŜ po przez Sterownik. Wynika to z faktu, iŜ Sterownik jest zaangaŜowany

w dialog w sensie RFC 3261 pomiędzy dwoma stronami. Dlatego teŜ wiadomość BYE,

wysłana przez którąkolwiek stronę powinna zostać przekazana przez Sterownik drugiej

stronie, po czym przesłane Ŝądania BYE powinny zostać potwierdzone wiadomością OK (por.

Rys.75).

Istotną kwestią jest moŜliwość modyfikacji parametrów sesji komunikacyjnej podczas

jej trwania za pomocą mechanizmu re-INVITE. W tej sytuacji, odebranie przez Sterownik

widomości INVITE powinno skutkować przekazaniem jej do drugiej strony. Oczywiście w

zaleŜności od tego jaki został wybrany sposób realizacji 3PCC, Sterownik odpowiednio

powinien zmodyfikować SDP.

153 Potencjalnie istnieje moŜliwość zastąpienia mechanizmu black holed address poprzez odpowiednie uŜycie atrybutów sendonly i receiveolny.

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

146

Rys.75 Diagram wiadomości w przypadku kończenia sesji przez jedną ze stron

10.1.4 Implementacja

Po przeanalizowaniu wad i zalet (patrz Tab. 6) róŜnych rozwiązań realizacji 3PCC, do

celów implementacji Serwera Sterowania Połączeniami został wybrany pierwszy sposób. Jak

juŜ wcześniej zostało wspominane jest on najmniej złoŜony, poza tym nie wprowadza

ograniczeń na rodzaj mediów. W testach154 zostało równieŜ zauwaŜone, Ŝe czasy oczekiwania

przez UA na wiadomość ACK w brew pozorom nie są takie krótkie (powyŜej 1 min.), co jest

w zupełności wystarczające, nawet jeśli po obu stronach korzystającymi są ludzie. W tym

przypadku problem związany z time-out’ami schodzi na drugi plan.

Architektura

Architektura Serwera Sterowania Połączeniami oraz sposób połączenia go z aplikacją

wykorzystującą jego funkcjonalność została zaprezentowana na Rys. 76. Serwer ten składa się

z 3 części:

� interfejsu Web Services dla 3PCC Parlay X,

� szkieletu i zrębu- RMI155,

� rdzenia aplikacji156 napisanego z wykorzystaniem bibliotek JAIN SIP.

Interfejs Web Services dla 3PCC reprezentowany jest po przez zbiór klas

odpowiadających poszczególnym metodom, które zostały wygenerowane automatycznie na

podstawie opisującego je kodu WSDL załączonego do specyfikacji. Implementacje metod

154 Testy zostały przeprowadzone z uŜyciem dwóch róŜnych UA: pierwszy IP SoftPhone X-Lite 3.0 firmy Xten Networks, Inc. oraz IP Phone Policom 410. 155 RMI – Remote Method Invocation – jest to mechanizm Javy, słuŜący zdalnemu wywoływaniu obiektów. Architektura RMI bazuje na dwóch elementach: stub i skeleton. Wywoływanie zdalne metod realizuje się lokalnie na skeleton’ie, po czym parametry zostają serializowane i trafiają do stub’a, gdzie następuje wykonanie docelowych metod. 156 Określenia autora wskazujące element architektury aplikacji, w którym znajduje się logika 3PCC.

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

147

naleŜących do tego interfejsu są częścią aplikacji webowej157 rozmieszczonej na serwerze

aplikacyjnym. Dodatkowo aplikacja ta zawiera klasy pomocnicze słuŜące przygotowaniu i

procesowaniu wiadomości SOAP158.

Skeleton i Stub są obiektami umoŜliwiającymi zdalną komunikację przy wykorzystaniu

mechanizmu RMI. Skeleton implementuje metody z interfejsu 3PCC po stronie aplikacji

webowej (wchodzi w jej skład), natomiast Stub po stronie rdzenia aplikacji.

� Logika 3PCC zlokalizowana jest w rdzeniu aplikacji. Rdzeń aplikacji obejmuje 4 klasy:

� sterownik, klasa: ThirdPartyCallController – odpowiedzialna jest za uruchomienie

Serwera Sterowania Połączeniami (załadowanie konfiguracji z pliku XML159),

skreowanie wymaganych obiektów m.in. stosu JAIN SIP, instancji klasy

ThirdPartyCallApplication oraz ThirdPartyCallAdapter .

� adapter, klasa: ThirdPartyCallAdapter. Klasa ta mapuje wywołania metod

interfejsu Web Services na wywołania odpowiednich metod z klasy

ThirdPartyCallApplication .

� aplikację, klasa: ThirdPartyCallApplication . Klasa ta zawiera logikę Serwera

Sterowania Połączeniami. Szczegółowa budowa i zasada działania tej klasy zostanie

omówiona poniŜej.

� stan aplikacji dla określonego dialogu, klasa TaskState . Jest klasą pomocniczą,

przechowującą stan dialogu oraz zmienne pomocnicze jak np. oferty mediów,

referencje na obiekty dialogu oraz transakcji pomiędzy sterownikiem, a stronami,

adresy URI stron, itp..

157 NaleŜy zauwaŜyć, Ŝe aplikacja webowa zgodna ze specyfikacją J2EE ma określoną strukturę. Oprócz klas, w których zaimplementowana została logika istnieje zbiór plików z meta-danymi. 158 SOAP – Simple Object Application Protocol (patrz [47]) 159 W pliku przekazywane są m.in. informacje na temat adresu IP, do którego powinien połączyć się stos JAIN SIP, numer portu, na którym będzie nasłuchiwał.

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

148

Serw

er HTTP

Apache + PHPP

rzeglądarka

WWW

Serw

er Aplikacyjny

Tomcat + Axis 2

Aplikacja 3PCC

(JAIN SIP)

Serw

er Sterowania Połączeniami

Rys. 76: Diagram interakcji pomiędzy poszczególnymi elementami przy zestawianiu połączenia przez

trzecią stronę na tle architektury Serwera Sterowania Połączeniami.

Zasada działania

Zasada działania Serwera Sterowania Połączeniami oraz interakcje pomiędzy

poszczególnymi elementami architektury usługowej zostały przedstawione na Rys. 76.

Wypełnienie formularza HTML na stronie WWW i wciśnięcie przycisku Make Call

powoduje wysłanie Ŝądania GET (1) do serwera WWW z wartościami parametrów

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

149

wprowadzonych w poszczególne pola. Na serwerze WWW zostaje uruchomiony skrypt PHP i

zostają wywołane odpowiednie metody przygotowujące wiadomość SOAP do wysłania (2).

Serwer Sterowania Połączeniami zgodnie z nomenklaturą Web Services nazywa się

Dostawcą Web Services (Web Services Provider). Otrzymuje on od śądającego Web Services

(Web Services Requestor) wiadomość SOAP (3), która zawiera zdalne wywołanie metody

xsd:string MakeCall(xsd:anyURI CallingParty, xsd:anyURI CalledParty)

znajdującej się w Web Services 3PCC na serwerze aplikacyjnym. Na podstawie tej

wiadomości następuje wywołanie odpowiedniej funkcji (4), która to wywołuje na Szkelecie

RMI zdalnie metodę public String makeCall(URI callingParty, URI calledParty) z

klasy ThirdPartyCallAdapter . Natomiast w ciele funkcji makeCall(...) z klasy

ThirdPartyCallAdapter znajduje się wywołanie funkcji z klasy

ThirdPartyCallApplication , która realizuje konkretną logikę.

Klasa ThirdPartyCallApplication składa się z części synchronicznej (metody

MakeCall(...) , EndCall(...) , …) i asynchronicznej. Cześć asynchroniczna implementuje

interfejsy JAIN SIP ProcessRequest(...) , ProcessResponse (...) odpowiedzialne za

przetwarzane przychodzących Ŝądań i odpowiedzi SIP.

Ze względu na fakt, iŜ do obsługi wszystkich zgłoszeń wykorzystana jest jedna

instancja ThirdPartyCallApplication , wymagane jest odrębne przechowywanie informacji

skojarzonej z poszczególnymi sesjami. Do tego celu słuŜy wcześniej wspomniana klasa

TaskState . KaŜda sesja identyfikowana jest jako ciąg znaków połączonych Call-ID dialogów

pomiędzy Sterownikiem, a Stronami.

Zadaniem klasy jest poprawna realizacja wybranego scenariusza 3PCC związanego z

zestawianiem sesji oraz jej rozłączaniem. Zachowanie się klasy zostało zobrazowane na Rys.

78 jako diagram SDL160, a przykładowy scenariusz tworzenia obiektów i interakcji między

nimi na diagramie UML Rys. 77.

160 Service Description Language – jest językiem wykorzystywanym do opisu procesów systemów rozproszonych.

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

150

Rys. 77: Diagram UML z wywołaniami funkcji dla przykładowego procesu zestawiania sesji i

uruchamiania serwera.

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

151

Rys. 78: Logika Serwera Sterowania Połączeniami w postaci diagramu SDL.

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

152

10.2 Obsługa połączeń (interfejs Call Handling)

Pod terminem obsługa połączeń (w jęz. angielskim: call handling) rozumie się grupę

usług, których realizacja jest związana z odpowiednim przetwarzaniem przychodzących i

trwających połączeń. Przykładami usług naleŜących do takiej grupy mogą być usługi takie

jak: akceptowanie połączenia (ang. call accepting), blokowanie połączenia (ang. call

blocking), czy teŜ przekierowanie połączenia (ang. call forwarding).

Usługi te naleŜą równieŜ do standardowych usług świadczonych w sieciach

telekomunikacyjnych TDM (PSTN, ISDN, GSM). MoŜna pokusić się o stwierdzenie, Ŝe są

podstawowymi komponentami usługowymi z punktu widzenia uŜytkownika, z których moŜna

budować bardziej zaawansowane usługi telekomunikacyjne. Przykładem moŜe być integracja

usługi przekierowania połączenia z usługą lokalizacji, a scenariusz moŜe wyglądać

następująco. UŜytkownik ma moŜliwość zdefiniowania sobie róŜnych obszarów. Do tak

zdefiniowanych obszarów moŜe przypisać odpowiednio np.: usługę bezwarunkowego

przekierowania połączenia na wskazany numer. Niech jednym ze zdefiniowanym obszarów

będzie biuro, wówczas kaŜde połączenie przychodzące do uŜytkownika w momencie, gdy

znajduje się on w biurze zostanie przekierowanie na telefon stacjonarny (choćby ze względu

na fakt, iŜ telefon stacjonarny oferuje lepszą jakość). MoŜna sobie wyobrazić, Ŝe potencjalna

liczba usług wykorzystujących te bazowe usługi jest duŜa.

ParlayX – Call

Handling

ClearR

ules

GetRules

SetR

ulesForG

roup

SetR

ules

implementowane w ramach środowiska badawczego

Rys. 79: Funkcje interfejsu Parlay X: Call Handling

10.2.1 Specyfikacja interfejsu Parlay X: Call Handling

Ze względu na duŜe znaczenie usług typu call handling jako podstawowych

komponentów, z których moŜna tworzyć bardziej zaawansowane usługi telekomunikacyjne

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

153

zostały one równieŜ włączone w specyfikację interfejsów Parlay X. Specyfikacja (patrz [8],

część 10) obejmuje następujące usługi:

� Akceptowanie połączeń;

� Blokowanie połączeń;

� Bezwarunkowe przekierowanie połączenia;

� Warunkowe przekierowanie połączenia (UA jest zajęty, UA nie odbiera

przychodzącego połączenia przez określony czas).

Usługom tym odpowiadają funkcje161 interfejsu Parlay X: Call Handling, wyszczególnione na

Rys. 79. Wybrane funkcje zaznaczone na zielono zostały zaimplementowane w serwerze

obsługi połączeń, a poniŜej znajduje się szczegółowy ich opis:

void setRules(xsd:anyURI Address, CallHandlingRules Rules)

Funkcja ta ustawia zbiór reguł (ang. rules) typu CallHandlingRules dla numeru162,

na który przychodzi połączenie. W przypadku, gdy dla danego numeru został

przypisany zbiór reguł, ponowne wywołanie tej funkcji spowoduje ich nadpisanie.

CallHandlingRules getRules(xsd:anyURI Address)

Funkcja wykorzystywana do pobrania zadeklarowanego zbioru reguł przypisanego

określonemu numerowi.

void claerRules(xsd:anyURI [1..unbounded])

Za pomocą tej funkcji dokonywane jest usunięcie zadeklarowanego zbioru reguł dla

określonego numeru lub zbioru numerów.

W Tab. 7 i Tab. 8 zostały przedstawione definicje typu danych odpowiednio dla

CallHandlingRules i UnconditionalForward zgodnie ze specyfikacją Parlay X.

161 Funkcje zostały zdefiniowane przy uŜyciu pseudokodu, a parametry i dane, z których korzystają zostały opisane w XML Schema. 162 Autor pod pojęciem numeru rozumie róŜnego rodzaju typy adresacji UA np. SIP URI, TelURI, E.164, itp..

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

154

Tab. 7: Definicja typu danych: CallHandlingRules

Nazwa elementu Typ elementu Opcjo- Nalny

Opis

AcceptList xsd:anyURI [0..unbounded]

Tak Lista numerów, z których połączenie zostanie zaakceptowane

BlockList xsd:anyURI [0..unbounded]

Tak Lista numerów, z których połączenie zostanie odrzucone

ForwardList ConditionalForward [0..unbounded]

tak Lista numerów, na które powinno zostać przekierowanie połączenie.

Forward UnconditionalForward tak Numer na który zostanie przekierowanie połączenie bezwarunkowo

VoiceInteractionContent VoiceInteraction tak Przekierowanie połączenia do systemu interakcji z informacją o zawartości

Tab. 8: Definicja typu danych: UnconditionalForward

Nazwa elementu Typ elementu

Opcjo-nalny

Opis

ForwardingAddress xsd:anyURI No Numer, na który zostanie przekierowanie połączenie

OnBusyAddress xsd:anyURI No Numer, na który zostanie przekierowanie połączenie w przypadku gdy linia jest zajęta

OnNoAnswerAddress xsd:anyURI No Numer, na który zostanie przekierowanie połączenie w przypadku, gdy nie zostanie odebrane

W specyfikacji [8] została dokładnie określona kolejność podejmowania akcji w

przypadku, gdy dla wszystkich usług zostały ustawione reguły. Jeśli reguły nie zostały

ustalone dla jakieś usługi krok ten zostaje pominięty. Kolejność ta przedstawia się

następująco:

� akceptacja połączenia – determinuje, czy połączenie powinno zostać zatwierdzone, czy

teŜ odrzucone. Jeśli dzwoniący nie jest na liście połączeń akceptowanych, wówczas

takie połączenie zostaje odrzucone i dalsze przetwarzanie reguł zostaje zakończone;

� blokowanie połączeń – determinuje, czy połączenie powinno zostać odrzucone. Jeśli

dzwoniący jest na liście numerów zablokowanych, połączenie zostaje odrzucone i

przetwarzanie reguł zostaje zakończone.

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

155

� warunkowe przekierowanie połączenia – kaŜde przychodzące połączenie na numer, dla

którego zostały określone specyficzne reguły przekierowania zostaje przekierowanie.

Dalej przetwarzanie reguł zostaje zakończone.

� bezwarunkowe przekierowanie połączenia – numer wywoływany zostaje zamieniony na

numer zadeklarowany w regule, po czym przetwarzanie reguły zostaje zakończone.

� odegranie dźwięku – połączenie zostaje obsłuŜone przez system głosowy. Przetwarzanie

tej reguły kończy się w momencie, gdy połączenie zostaje zakończone.

� Kontynuacja przetwarzania połączenia do momentu zestawienia połączenia na

oryginalnie wywoływany numer.

10.2.2 Implementacja

Ze względu na fakt, iŜ celem pracy jest jedynie pokazanie modelu i sposobu

implementacji usług w IMS, a nie implementacja wszystkich funkcji interfejsu Parlay X: Call

handling postanowiono, iŜ Serwer Obsługi Połączeń będzie realizował dwie wybrane usługi

mianowicie: bezwarunkowe przekierowanie połączenia oraz blokowanie połączenia.

Blokowanie połączenia

W Ŝadnym z dokumentów RFC dotyczącym SIP nie ma definicji mechanizmu

blokowania połączenia. Próbując zdefiniować taki mechanizm naleŜy zastanowić się na

dwoma zasadniczymi kwestiami:

1 na jakiej podstawie dane połączenie powinno zostać odrzucone,

2 jaka wiadomość SIP powinna zostać uŜyta do poinformowania UA inicjującego

połączenie o fakcie zablokowania jego wywołania.

Pewien szkic sformalizowania wyŜej wymienionych dwóch aspektów został omówiony

szczegółowo w [19]163. Autor proponuje wprowadzenie do standardu SIP nowej wiadomości

4xx (BLOCKED) oraz wymienia potencjalne warunki, na podstawie których dane połączenie

mogłoby zostać odrzucone. Jednocześnie dokonuje podziału mechanizmu blokowania

wywołań na: w pełni zablokowane (ang. full blocked) i częściowo zablokowane (ang.

partial blocked).

163 NaleŜy zauwaŜyć, iŜ draft [19] ten nie został włączony do zbioru RFC, a jego waŜność wygasła z dniem 02/15/2007. W związku z tym definicja mechanizmu blokowania połączenia jest wciąŜ tematem otwartym.

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

156

Pod pojęciem w pełni zablokowanych wywołań rozumie się, iŜ dane wywołanie

zostanie odrzucone ze względu na numer UA, który je zainicjował lub zakres numerów UA

lub nazwę domeny, z której pochodzą.

Częściowe blokowanie połączenia dotyczy filtrowania połączeń, które nie spełniają

kryteriów związanych z opisem sesji np. rodzaju kodeków, typu mediów, itp.. W tym

przypadku UA moŜe ponownie wysłać Ŝądanie z uwzględnieniem preferencji wywoływanego

UA, które otrzymał w odpowiedzi 4xx (BLOCKED) (przyczyna podawana jest w nagłówku

Reasone Header).

Przytoczone powyŜej sformalizowanie mechanizmu blokowania połączenia wraz z

rozszerzeniem specyfikacji SIP o dodatkową wiadomość pozwala w precyzyjny sposób

określać warunki na podstawie, których dane połączenie powinno zostać odrzucone. Zdając

sobie jednak sprawę, iŜ implementacja mechanizmu, który nie stał się standardem moŜe nieść

za sobą brak kompatybilności z innymi SIP UAs, autorzy postanowili rozwiązać ten problem

trochę inaczej. Do odrzucenia połączenia zostanie wykorzystana wiadomość CANCEL.

UŜycie wiadomości CANCEL w mechanizmie blokowania połączenia nie wybiega poza jej

definicję (patrz [22]), a przykładowy diagram widomości został przedstawiony na Rys. 80.

Dodatkowo uŜycie mechanizmu z [19] wiązałoby się z rozszerzeniem specyfikacji interfejsu

Parlay X: Call Handling o dodatkowy typ danych, który uwzględniałby warunki dla

blokowania częściowego i pełnego.

Rys. 80: Diagram wiadomości SIP dla usługi blokowania połączeń

Bezwarunkowe przekierowanie połączenia

Mechanizm przekierowania połączenia nie został równieŜ wyspecyfikowany w Ŝadnym

RFC dotyczącym SIP. Jednak w spisie wiadomości SIP z grupy tymczasowych (provisional)

znajduje się wiadomość o kodzie 181 ‘Call is being forwarded’, która moŜe zostać

wykorzystana do poinformowania UA o fakcie przekierowania jego połączenia. Przykładowy

diagram wymiany wiadomości SIP w trakcie przekierowania połączenia prezentuje Rys. 81.

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

157

Jak moŜna zauwaŜyć jest to standardowa transakcja INVITE rozszerzona jedynie o

wiadomość o kodzie 181, która ma jedynie informacyjny charakter.

Rys. 81: Diagram wiadomości SIP dla usługi przekierowania połączenia

10.2.3 Architektura

Architektura Serwera Obsługi Połączeń podobnie jak w przypadku architektury Serwera

Sterowania Połączeniami (patrz rozdział 10.1) obejmuje trzy elementy:

� interfejs Web Services dla Parlay X: Call Handling,

� szkielet i zręb - RMI,

� rdzeń aplikacji164 napisany z wykorzystaniem bibliotek JAIN SIP.

Budowa i działanie dwóch pierwszych elementów jest analogiczne do elementów z

Serwera Sterownia Połączeniami (szczegółowy opis 10.1.4), tak więc opis ich w tym miejscu

zostanie pominięty.

Rdzeń aplikacji jest głównym elementem serwera, a jego architektura została

przedstawiona na Rys. 82. Obejmuje on następujące klasy:

� sterownik, klasa: CallHandlingController – odpowiedzialna jest za uruchomienie

Serwera Obsługi Połączeń (załadowanie konfiguracji z pliku XML165), skreowanie

164 Określenia autora wskazujące element architektury aplikacji, w którym znajduje się logika serwera obsługi połączeń. 165 W pliku przekazywane są m.in. informacje na temat adresu IP, do którego powinien połączyć się stos JAIN SIP, numer portu, na którym będzie nasłuchiwał.

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

158

wymaganych obiektów m.in. stosu JAIN SIP, instancji klasy

CallHandlingApplication oraz CallHandlingAdapter .

� adapter, klasa: CallHandlingAdapter. Klasa ta mapuje wywołania metod interfejsu

Web Services na wywołania odpowiednich metod z klasy

CallHandlingApplication .

� aplikację, klasa: CallHandlingApplication . Klasa ta zawiera logikę Serwera Obsługi

Połączeń.

� Klasy pomocnicze takie jak stan aplikacji dla określonego dialogu: klasa

TaskState166, skojarzenie reguł z konkretnym numerem: klasa

CallHandlingRuleAss oraz powiązania transakcji klienckiej i serwera dla

stanowego SIP Proxy: klasa SipProxy . Klasy te zostały zaznaczone kolorem

szarym.

Rys. 82: Zestaw klas z najwaŜniejszymi funkcjami, z których zbudowany jest Serwer Obsługi Połączeń.

Klasy szare są klasami pomocniczymi.

166 Klasa ta jest identyczna jak klasa w Serwerze Sterowania Połączeniami.

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

159

Rys. 83: Diagram sekwencji wymiany wiadomości/wywołania funkcji dla procesu uruchamiania serwera

obsługi połączeń, ustawiania reguł oraz procesu przekierowania połączenia.

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

160

Uwagi:

� diagram przedstawia scenariusz ustawiania reguł dla danego uŜytkownika za pomocą

aplikacji Osobiste Centrum Komunikacji, jak i równieŜ proces obsługi połączenia dla

reguły usługi przekierowania połączeń;

� dla uproszenia w diagramie S-CSCF oraz P-CSCF przedstawiono jako CSCF;

� kaŜdorazowe ustawienie reguł (wywołanie setRules(...) ) powoduje nadpisanie

numeru, na który ma zostać przekierowanie połączenie oraz dodanie listy numerów

zablokowanych do listy wcześniej juŜ ustawionych;

� serwer obsługi połączenia nie wstawia nagłówka Record Router co skutkuje tym, Ŝe

zamknięcie transakcji z INVITE oraz wszystkie inne transakcje pomiędzy

[email protected] i [email protected] zostaną obsłuŜone przez CSCF (nie obciąŜają serwera

obsługi połączeń);

� obiekt CallHandlingRulesAss jest tworzony w momencie utworzenia reguł dla danego

numeru, a usuwany w momencie wyczyszczenia reguł tj. wywołania funkcji void

clearRules(...) ;

� funkcja processCallHandlingRule(...) – przetwarza reguły obsługi połączeń

zgodnie z kolejnością wskazaną w rozdziale 10.2.1. Brak reguły powoduje

pominięcie danego kroku;

10.3 Informacja o statusie terminala (interfejs Terminal Status)

Interfejs Parlay X: Terminal Status, jak sama nazwa wskazuje umoŜliwia uzyskanie

informacji na temat statusu terminala lub terminali IMS, a takŜe na odbieranie w sposób

asynchroniczny powiadomień o zmianach statusu terminala/i IMS. Funkcjonalność taka

pozwala na projektowanie usług kontekstowych zainteresowanych informacją o statusie

terminala. Funkcjonalność tego interfejsu moŜe zostać wykorzystana np. do realizacji usługi

dzwoń kiedy jest dostępny (call when available) w ramach usługi telekonferencji. Wówczas

telekonferencja taka zostanie zestawiona w momencie, gdy zadeklarowany zbiór terminali

będzie miał określony status - osiągalny.

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

161

Rys. 84: Wykaz interfejsów i funkcji wchodzących w skład usługi sieciowej Parlay X: Terminal Status

10.3.1 Opis interfejsu Parlay X: Terminal Status

Interfejs Parlay X: Terminal Status został zdefiniowany w dokumencie [8]. Funkcjonalność

tego interfejsu umoŜliwia uzyskanie informacji o statusie terminala poprzez:

� wysłanie Ŝądania, w odpowiedzi na które zostanie zwrócony status terminala;

� wysłanie Ŝądania do grupy terminali;

� przysyłania w sposób asynchroniczny powiadomienia o zmianach w statusie terminala.

WyróŜnia się następujące statusy terminala:

� osiągalny (reachable);

� nieosiągalny (unreachable);

� zajęty167 (busy).

Na Rys. 84 znajduje się wykaz interfejsów i funkcji wchodzących w skład usługi sieciowej

Parlay X: Terminal Status. Interfejsy te odpowiadają wcześniej wymienionym sposobom

uzyskania informacji o statusie terminala. Z pośród nich do celów środowiska badawczego

postanowiono zaimplementować funkcję GetStatus, której deklaracja wygląda następująco:

Status GetStatus(xsd:anyURI Address)

Funkcja jako parametr przyjmuje adres terminala, którego status ma zostać

określony. W odpowiedzi zawraca jedną z trzech moŜliwych wartości typu

wyliczeniowego Status , które zostały wyszczególnione w Tab. 9

167 Nie wszystkie terminale mogą udostępnia informację o zajętości. W związku z tym aplikacja powinna adoptować się do informacji jakie uzyskuje.

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

162

Tab. 9: Definicja typu wyliczeniowego Status

Nazwa typu wyliczeniowego Opis Reachable Terminal jest dostępny Unreachable Terminal nie jest dostępny Busy Terminal jest zajęty

Implementacja

Ograniczenie się do implementacji wyłączenie jednej funkcji z usługi sieciowej Parlay

X: Terminal Status wynikało z faktu, iŜ zdaniem autorów funkcjonalność pozostałych

interfejsów z Rys. 84 moŜe być w prosty sposób osiągnięta z wykorzystaniem usługi

sieciowej Parlay X: Presence168. Do sprawdzenia statusu terminala postanowiono uŜyć

wiadomości OPTIONS169, która zgodnie z [22] wykorzystywana jest do odpytywania UAS o

jego preferencje tj. rodzaj kodeków, typ mediów, itp.., Terminal w odpowiedzi na OPTIONS

zwraca taką wiadomość jaką zwróciłby w przypadku otrzymania wiadomości INVITE.

Serwer rozróŜnia trzy przypadki:

� Otrzymał wiadomość OK – aplikacja zwraca status terminala REACHABLE

� Otrzymał wiadomość o kodzie 486 Busy Here170 - aplikacja zwraca status BUSY

� Nie otrzymał Ŝadnej wiadomości w przeciągu 30 sek. – aplikacja zwraca status

UNREACHABLE.

Przykładowe zachowanie się serwera na wysłanie wiadomości OPTIONS przedstawia Rys.

85.

168 Warto w tym miejscu wspomnieć o mechanizmie uŜytym przez IBM przy implementacji interfejsu Parlay X: Terminal Status (patrz http://publib.boulder.ibm.com/infocenter/wtelecom/v6r1/index.jsp?topic=/com.ibm.twss.services.doc/termstat_dev_c.html). Zaimplementowany mechanizm jest mechanizmem wykorzystywanym w usłudze obecności. Bazuje on na wiadomościach SUBSCRIBE i NOTIFY, które wymieniane są pomiędzy serwerem obecności, a aplikacją zbudowana na usłudze sieciowej. Rodzi się zatem pytanie jaki cel przyświecał implementacji interfejsu Parlay X: Terminal Status, skoro ma identyczną funkcjonalność jak interfejs Parlay X: Presence? 169 Definicja Ŝądania OPTIONS znajduje się w [22] w sekcji 4.2.3. 170 Definicja tej odpowiedzi znajduje się w [22] w sekcji 21.4.24.

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

163

Rys. 85: Diagram wiadomości SIP dla trzech przypadków statusu terminala: REACHABLE,

UNREACHABLE, BUSY

Architektura serwera jest analogiczna do architektury wcześniej opisywanych serwerów

obsługi połączeń i sterowania zestawianiem połączeń (patrz rozdział 10.1 i 10.2).

Rdzeń aplikacji tworzą następujące klasy:

� sterownik, klasa: TerminalStatusController – odpowiedzialna jest za uruchomienie

Serwera Terminal Status (załadowanie konfiguracji z pliku XML171), skreowanie

wymaganych obiektów m.in. stosu JAIN SIP, instancji klasy

TerminalStatusApplication oraz TerminalStatusAdapter .

� adapter, klasa: TerminalStatusAdapter. Klasa ta mapuje wywołania metod

interfejsu Web Services na wywołania odpowiednich metod z klasy

TerminalStatusApplication .

� aplikację, klasa: TerminalStatusApplication . Klasa ta zawiera logikę Serwera

Terminal Status. W skład tej klasy wchodzi m.in. funkcja void

getTerminalStatus(URI address). Zasada działania tej klasy została

przedstawiona na diagramie SDL na Rys. 86.

171 W pliku przekazywane są m.in. informacje na temat adresu IP, do którego powinien połączyć się stos JAIN SIP, numer portu, na którym będzie nasłuchiwał.

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

164

Rys. 86: Diagram w języku SDL opisujący działanie serwera Terminal Status

10.4 Zarządzanie listą kontaktów (interfejs Address List

Management)

W ramach środowiska badawczego została zaimplementowana aplikacja realizująca

funkcje związane z organizacją i zarządzaniem listą kontaktów uŜytkownika. Udostępnia on

zbiór wybranych funkcji zgodnych z specyfikacją interfejsu Parlay X: Address List

Management (patrz [8], część 13). Rys. 87 pokazuje wszystkie funkcje tego interfejsu oraz te,

które zostały zaimplementowane na potrzeby tego opracowania (zaznaczone kolorem

zielonym).

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

165

ParlayX - Address List Management

group management

interface

member

interface

group

interface

implementowane w ramach środowiska badawczego

Rys. 87:Funkcje interfejsu Parlay X: Addres List Managemnet172

Dostęp do prywatnej ksiąŜki kontaktów uŜytkowników ma waŜna znaczenie dla

budowania usług końcowych. UmoŜliwienie aplikacji, realizowanie logiki usługi w oparciu o

zcentralizowane informacje dotyczące prywatnej listy kontaktów uŜytkownika, wzbogaca

funkcjonalnie usługę (np. poczta elektroniczna z aktywną listą kontaktów) oraz daje moŜliwość

budowy całkowicie nowych rozwiązań dla końcowego uŜytkownika. Ze względu na te

kwestie, funkcjonalności związane z zarządzaniem listą kontaktów zostały włączone do

specyfikacji interfejsów Parlay/OSA i Parlay X. Stanowią one teŜ waŜny element warstwy

komponentów usługowych w realizowanym na potrzeby tego opracowania środowisku

badawczym.

10.4.1 Opis interfejsu Parlay X: Address List Management

Na potrzeby analizy w środowisku badawczym zaimplementowane zostały następujące

funkcje173:

� xsd:anyURI createGroup(

xsd:string name,

xsd:string domain,

xsd:boolean autoName)

172 Na podstawie specyfikacji Parlay X API wersja 2.1 173 Funkcje są zdefiniowane przy uŜyciu pseudokodu i typów danych XML-Schema (zdefiniowanych w ‘W3C XML Schema Part 2: Datatypes Second Edition’). Definicja funkcji zaczerpnięta jest z [8].

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

166

Tworzy grupę, która będzie identyfikowana porzez URI złoŜonym z nazwy ‘name’ i

dziedzinie ‘domain’. Jeśli parametr ‘autoName’ jest pozytywny to w przypadku

konfliktu nazw, nowa nazwa grupy zostanie wygenerowana automatycznie i zwrócona

jako odpowiedź na wywołanie tej funkcji.

� deleteGroup( xsd:anyURI group )

Usuwa grupę identyfikowaną przez URI ‘group’.

� addMember( xsd:anyURI group, xsd:anyURI member )

Dodaje nowego uŜytkownika identyfikowanego przez URI ‘member’ do grupy

identyfikowanej przez URI ‘group’.

� deleteMember( xsd:anyURI group, xsd:anyURI member )

Usuwa uŜytkownika ‘member’ z grupy identyfikowaną przez URI ‘group’.

� xsd:anyURI [0..*] queryMembers(

xsd:anyURI group,

xsd:boolean resoveGroups )

Wysyła prośbę o listę uŜytkowników naleŜących do grupy identyfikowanej przez URI

‘group’. Jeśli ‘ resolveGroups’ jest pozytywne to takŜe są zwracani członkowie

wszystkich podgrup wewnątrz danej grupy174.

10.4.2 Scenariusze wywołania funkcji interfejsu

Rys. 88 pokazuje przykładowy scenariusz wywołań funkcji tego interfejsu. UŜytkownik

korzysta z aplikacji Centrum Komunikacji Osobistej (implementowane w ramach środowiska

badawczego), którego jedną z funkcji jest wizualizowanie ksiąŜki adresowej. Po zalogowaniu

się uŜytkownika, aplikacja CKO wywołuje funkcję ‘queryMembers’, aby pobrać adresy

innych uŜytkowników, którzy znajdują się w ksiąŜce adresowej. Następnie uŜytkownik

dodaje nowy adres (wywołanie funkcji ‘addMember’) i usuwa inny (‘deleteMember’).

174 W zaimplementowanym środowisku badawczym nie ma moŜliwości stworzenia ‘podgrupy’.

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

167

queryMembers

addMember

deleteMember

Rys. 88: Przykładowy scenariusz wywołania funkcji interfejsu Parlay X: Address List Management

10.5 Informacja o statusie obecności (interfejs Presence)

W ramach środowiska badawczego została zaimplementowana aplikacja realizująca

funkcje związane z zarządzaniem informacją o statusie obecności uŜytkownika. Udostępnia

ona zbiór wybranych funkcji zgodnych z specyfikacją interfejsu Parla X: Presence (patrz [8],

część 14). Rys. 87 pokazuje wszystkie funkcje tego interfejsu oraz te, które zostały

zaimplementowane na potrzeby tego opracowania (zaznaczone kolorem zielonym).

subscrib

ePresence

getUserP

resence

startP

resenceNotific

atio

n

endPresenceNotific

atio

n

statusChanged

statusEnd

notify

Subscrip

tion

subscrip

tionEnded

publish

getO

penSubscrip

tions

updateSubscrip

tionAuthoriz

atio

n

getM

yWatchers

getSubscrib

edAttrib

utes

blockSubscrip

tion

Rys. 89: Funkcje interfejsu Parlay X: Presence

Informacja o statusie obecności uŜytkownika umoŜliwia budowanie tzw. usług

kontekstowych czyli takich, których scenariusz realizacji podczas wywołania zaleŜy od zbioru

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

168

czynników aktualnie określających środowisko, w którym znajduję się uŜytkownik. Dotycz to

zarówno informacji o obecności uŜytkownika, ale takŜe o lokalizacji, czy dostępności w sieci.

Na Rys. 90 pokazana jest architektura usługi obecności w sieci UMTS zdefiniowana w

ramach prac 3GPP. Podstawowymi elementami są:

� Presence Server – przechowuje i udostępnia informacje o obecności;

� Presence User Agent – dostarcza informacje o obecności pochodzącą od uŜytkownika;

� Presence Network Agent – dostarcza informacje o obecności pochodzącą z elementów

sieci. Przykładowo gdy uŜytkownik jest poza siecią, element realizujący funkcję

Presence Network Agent, mając dostęp do HSS, moŜe powiadomić serwer obecności

(Presence Server) o niedostępności uŜytkownika;

� Watcher application – pobiera informacje o obecności uŜytkowników z Presence

Server. Tą funkcję moŜe pełnić aplikacja usługowa, albo agent uŜytkownika (UA),

który „nasłuchuję” zmian w statusie obecności innych uŜytkowników.

Interfaces Ph, Pi, Pc, Pg, Pk and Pl are based on existing Release 5procedures e.g. CAMEL, MAP, CAP, RADIUS, ISC, Cx, Sh.The Pr, Pp interfaces are based on existing Release 6 procedures ofthe 3GPP- WLAN interworking architecture.

PeuPresence User agent(Presence informationprovided by the user)

Presence Network agent (Presenceinformation provided by the

network)

Pen

Pi

MSC Server/VLR SGSN GMLC

Ph Pc Pg

Presence suppliers

Presence server(home network)

PresentityPresence Proxy

WatcherPresence Proxy

Watcherapplications

HSS(HLR)

Pwp

Pw

Pw

Px

GGSNS-CSCFHSS/HLR

Pk Pl

Presence External agent (Presenceinformation provided by elementsoutside the provider’s network)

Pex

Pr

3GPP AAAServer

Pp

PDG

Pep

PresenceList Server

Pet

Pw

Rys. 90: Architektura usługi obecności w sieci 3GPP (źródło 3GPP TS 23.141)

Zgodnie z architekturą pokazana na Rys. 90, informacja o obecności moŜe pochodzić

bezpośrednio od uŜytkownika albo moŜe być „odkrywana” w sposób pośredni np. za pomocą

analizy stanów elementów sieciowych. Model usługi obecności (a w zasadzie komponentu

usługowego) opiera się współdziałanie pomiędzy: podmiotami, które publikują informacje o

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

169

obecności uŜytkowników, repozytorium przechowującym takie dane oraz podmiotami, które

odczytują informacje o obecności uŜytkowników (patrz Rys. 91).

Rys. 91: Model realizacji usługi obecności

W implementowanym środowisku badawczym, poszczególne funkcje pełnione przez

dane elementy są pokazane na Rys. 92.

Rys. 92: Funkcje usługi obecności realizowane przez poszczególne elementy środowiska badawczego

10.5.1 Opis interfejsu

„Serwer udostępniający informacje o statusie obecności uŜytkownika” jest elementem

realizującym interfejs Parlay X: Presence w środowisku badawczym (patrz Rys. 92). Na

potrzeby analizy zaimplementowane zostały następujące funkcje175:

� publish (

xsd:anyURI presentity,

presence_xsd:PresenceAttribute presence )

175 Funkcje są zdefiniowane przy uŜyciu pseudokodu i typów danych XML-Schema (zdefiniowanych w ‘W3C XML Schema Part 2: Datatypes Second Edition’). Definicja funkcji zaczerpnięta jest z [8].

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

170

Wywołanie tej funkcji publikuje status obecności uŜytkownika identyfikowanego

poprzez presentity. Status obecności jest określony poprzez parametr presence, który

zgodnie z [8] moŜe między innymi przyjmować wartości określające aktywność, które

zostały wypisane w Tab. 10.

� presence_xsd:PresenceAttribute getUserPresence(

xsd:anyURI watcher,

xsd:anyURI presentity,

xsd:string [0..*] attributes)

Zwraca informacje o obecności uŜytkownika identyfikowanego, poprzez URI

presentity. Aplikacja wywołująca tą funkcje musi określić uŜytkownika, który pobiera

informacje (watcher) oraz rodzaj informacji, która ma być zwrócona176.

10.5.2 Realizacja usługi obecności przy pomocy protokołu SIP

Publikacja i pobieranie informacji z serwera obecności odbywa się za pomocą protokołu

SIP rozszerzonego o dodatkowe mechanizmy zdefiniowane w [29]. Wiadomości biorące

udział w realizacji usługi obecności to:

� SUBSCRIBE - umoŜliwia aplikacji nasłuchującej (Watcher Application)

zarejestrowanie w serwera obecności (Presence Server) potrzeby pobierania

informacji o obecności.

� NOTIFY – umoŜliwia serwerowi obecności (Presence Server) przesyłanie informacji o

obecności do aplikacji nasłuchującej (Watcher Application).

� PUBLISH – umoŜliwia publikacje statusu obecności przez agenta obecności (Presence

Agent)

Dokumenty [28] i [32] specyfikują model reprezentacji obecności, który jest

wykorzystywany w protokole SIP. Do tego celu jest stosowany opis w postaci PIDF177 i

RPIDF178, który jest przenoszony za pomocą wiadomości PUBLISH i NOTIFY.

176 W środowisku badawczym dostępna jest tylko informacja o aktywności uŜytkownika. 177 PIDF (Presence Information Data Format) jest sposobem opisu stanu obecności opartym o XML i definiowanym w [28]. 178 RPIDF (Rich Presence Information Data Format) jest rozszerzeniem opisu w stosunku do PIDF (patrz [32]).

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

171

Rys. 93: Przykładowy dokument PIDF/RPIDF opisujący status obecności

Przykład dokumentu PIDF/RPIDF opisującego status obecności przedstawia Rys. 93.

Tab. 10 pokazuje róŜne moŜliwe statusy aktywności zdefiniowane w ramach Parlay X i SIP

(PIDF/RPIDF). Jak moŜna zauwaŜyć oba modele nie są zgodne i niezbędna jest konwersja

pomiędzy statusami obecności przekazywanymi poprzez interfejs Parlay X, a statusem

obecności, który jest uŜywany w sieci IMS opartej o protokół SIP.

Tab. 10: Porównanie moŜliwych aktywności zdefiniowanych w ramach Parlay X i modelu obecności dla

protokołu SIP (RPIDF)

Parlay X SIP (PIDF/RPIDF) ActivityNone Available Busy DoNotDisturb OnThePhone Steering Meeting Away Meal PermanentAbsence Holiday Performance InTransit Travel

appointment away breakfast busy dinner holiday in-transit looking-for-work meal meeting on-the-phone permanent-absence playing presentation

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

172

Sleeping ActivityOther

shopping sleeping travel vacation working other unknown

10.5.3 Scenariusz usługi obecności

Rys. 94 pokazuje przepływy wiadomości pomiędzy elementami środowiska

badawczego przy wywołaniach funkcji interfejsu Parlay X: Presence.

CSCF

aplikacja

CKO*interakcja z

uŜytkownikiem

*) CKO = Centrum Komunikacji Osobistej

Parlay X

interfejs ParlayX: Presence

J2SE

stos JAIN-SIP

Serwer udostępniającyinformacje o stanieobecności uŜytkownika

Publish

Get User Presence

1. PUBLISH

2. PUBLISH

3. Zapamietanie stanu obecności

12. Zapamietanie stanu obecności

5. SUBSCRIBE

6. NOTIFY

7. Konwersja modeli obecności z

SIP na Parlay X

10. Konwersja modeli obecności z

Parlay X na SIP

11. PUBLISH

Rys. 94: Interakcje pomiędzy elementami środowiska badawczego podczas wywoływania funkcji

interfejsy Parlay X: Presence

Terminal uŜytkownika publikuję informacje o obecności po zarejestrowaniu się w sieci

IMS. W tym celu wysyła wiadomość PUBLISH (1). Wiadomość PUBLISH zgodnie z

zasadami kierowania zgłoszeń w IMS trafia do serwera obecności (2). Serwer obecności

Analiza i implementacja interfejsów Parlay X w modelu usługowym IMS

173

odczytuje informacje o statusie obecności zapisaną w dokumencie PIDF/RPIDF zawartym w

otrzymanej wiadomości PUBLISH (3). Inny uŜytkownik uruchamia aplikację CKO, która

wywołuje funkcję ‘getUserPresence’ w celu uzyskania informacji o obecności (4). Serwer

aplikacyjny implementujący interfejs Presence przesyła do serwera obecności widomość

SUBSCRIBE z Ŝądaniem powiadomienia o statusie obecności uŜytkownika (5). Serwer

obecności przesyła za pomocą wiadomości NOTIFY dokument PIDF/RPIDF uŜytkownika,

który w punkcie 3 został zapamiętany (6). Serwer aplikacyjny dokonuje konwersji między

PIDF/RPIDF a modelem stosowanym, w Parlay X (7). Informacja o statusie obecności jest

zwracana do aplikacji CKO (8). UŜytkownik aplikacji CKO modyfikuje statusie obecności.

Aplikacja CKO wywołuje funkcję ‘publish’ w celu zmiany informacji o statusie obecności

(9). Serwer aplikacyjny dokonuje konwersji modeli (10) i wysyła widomość PUBLISH do

serwera obecności zawierającą dokument PIDF/RPIDF z nowym statusem obecności (11).

Serwer obecności zapamiętuję nowy status obecności uŜytkownika (12).

Centrum Komunikacji Osobistej

174

11. Centrum Komunikacji Osobistej

W ramach warstwy aplikacyjnej zostały zaimplementowane i omówione wybrane

interfejsy ze specyfikacji Parlay X. Interfejsy te są punktem, w którym operator otwiera sieć

telekomunikacyjną oraz udostępnia jej funkcjonalność. Na bazie tej funkcjonalności trzecia

strona moŜe budować własne usługi telekomunikacyjne.

W związku z tym naturalnym zwieńczeniem prac nad analizą modelu tworzenia usług w

IMS jest pokazanie, w jaki sposób moŜna wykorzystać usługi sieciowe Parlay X. Dlatego

wramach środowiska badawczego tworzonego na potrzeby niniejszego opracowania została

zaimplementowana aplikacja „Centrum Komunikacji Osobistej” 179.

11.1 ZałoŜenia projektowe dla aplikacji

Przed przystąpieniem do prac nad aplikacją została sporządzona poniŜsza lista załoŜeń.

ZałoŜenia uporządkowano zgodnie z ich waŜnością.

Funkcjonalność:

� moŜliwość zestawienia połączenia pomiędzy dwoma stronami, bez względu na

rodzaj sieci (naleŜy wprowadzić jedynie odpowiednie URI);

� zakończenie połączenia, po przez wybranie go z listy istniejących;

� przekierowanie połączenia na wskazany URI;

� blokowanie połączeń – blokada zgłoszenia przychodzącego z określonego URI;

� informację o statusie obecności uŜytkowników, którzy znajdują się na liście

kontaktowej;

� publikowanie własnego statusu obecności (moŜliwość zdefiniowania opisu, oraz

wybrania predefiniowanego statusu z poziomu aplikacji), jeśli takiej funkcjonalności

nie udostępnia SIP UA uŜytkownika lub uŜytkownik korzysta z tradycyjnej telefonii;

� zarządzanie własną listą kontaktów (usuwanie, edycja, dodawanie nowych

kontaktów);

� sprawdzanie statusu terminala na podstawie URI;

� aplikacja ma prezentować moŜliwości Parlay X;

179 Inspiracją dla usługi była usługa o nazwie IOBI amerykańskiego operatora Verizon. Szczegóły dotyczące protoplasty moŜna znaleźć pod adresem: http://www22.verizon.com/business/iobi/.

Centrum Komunikacji Osobistej

175

� uŜytkownik moŜe personalizować aplikację, włączając lub wyłączając określoną

funkcjonalność, za którą powinien być odpowiednio rozliczony180;

� aplikacja ma być stworzona z wykorzystaniem standardowych narzędzi do budowy

stron WWW, jednakŜe ma imitować aplikację stacjonarną tzw. „stand-alone” (bez

konieczności ciągłego odświeŜania strony, pobierania danych. Reakcja na zdarzenia

wywołane przez uŜytkownika ma być natychmiastowa);

� uŜytkownik jest identyfikowany i autoryzowany za pomocą loginu w postaci SIP

URI oraz hasła;

� aplikacja ma spełniać standardy bezpieczeństwa rozwiązań webowych np. Transport

Layer Security181 (TLS), XML Encryption;

� Interfejs uŜytkownika ma być moŜliwie prosty i funkcjonalny.

11.2 Architektura aplikacji

11.2.1 Wybrane techniki i narzędzia

Do realizacji projektu, biorąc pod uwagę postawione wymagania, wybrano

następujące techniki: język zgodny ze standardem XHTML [49], język PHP [57], Java Script

[15], Asynchronous JavaScript And XML (AJAX), protokół SOAP [47] oraz Transport Layer

Security (TLS) [21]. Zakres, w jakim te techniki pozwalają realizować załoŜenia projektowe

zostaną wyszczególnione w opisach kaŜdej z nich, a miejsce ich zastosowania pokazano na

rysunku Rys. 95.

Serw

er HTTP

+ PHP

(PEAR 0.9.1)P

rzeglądarka

WWW

Aplikacja

JavaScrip

t

Serw

er

Aplikacyjny +

AXIS v.2

Rys. 95: Wykorzystanie wybranych technik w realizacji aplikacji

180 Zostanie omówiony sposób rozliczenia uŜytkownika, jednak ze względu na brak usługi sieciowej odpowiedzialnej za ten proces w samej implementacji funkcjonalność ta została pominięta. 181 Technika ta zostanie przedstawiona w dalszej części pracy.

Centrum Komunikacji Osobistej

176

Język PHP

Język PHP (Hypertext Preprocessor) został wybrany spośród alternatywnych rozwiązań

takich jak JSP/Servlet182, CGI183 ze względu na jego prostotę uŜycia, powszechne stosowanie

i funkcjonalność184. Jest to język skryptowy, który wykonywany jest po stronie serwera. Nie

posiada, więc ograniczeń związanych z odpowiednim oprogramowaniem strony klienckiej.

Dzięki temu aplikacja ma charakter sieciowy, nie musi być instalowana i nie jest zaleŜna od

środowiska w, którym jest uruchamiana. PHP pozwala na tworzenie stron HTML/XHTML

generowanych dynamicznie, poprzez wkomponowanie wyraŜeń w treść dokumentu HTML.

W projekcie wykorzystano wersję piątą języka ze względu na fakt, iŜ pozwala w pełni

na programowanie obiektowe oraz jest kompatybilna z projektem PEAR185. Projekt PEAR

posiada m. in. zbiór klas wspierających komunikację z wykorzystaniem protokołu SOAP.

Funkcjonalność biblioteki PEAR/SOAP umoŜliwia korzystanie z interfejsów Parlay X. Do

budowy aplikacji uŜyto biblioteki PEAR/SOAP w wersji 0.9.1.

Java Script

Java Script znajduje się po stronie klienta i jest prostym186, powszechnie stosowanym

językiem skryptowym. Pozwala na dynamiczne przetwarzanie stron w języku HTML bez

interakcji z serwerem. Dzięki temu zawartość aplikacji nie musi być przeładowywana (jednak

pobranie nowych danych wymaga przeładowania strony).

Java Script oferuje równieŜ mechanizm zdarzeń, który umoŜliwia budowę aplikacji z

zaawansowanym GUI (pod elementy strony moŜna podpiąć zdarzenia i obsłuŜyć je w

dowolny sposób). Poza tym technika ta wymagana jest, aŜeby korzystać z AJAX. Do budowy

aplikacji wykorzystano język w wersji 1.2.

182 Techniki opracowane przez Sun Microsystem. Specyfikacja i dokumentacja technik dostępna na [53] i [54]. 183 Common Gateway Interface (CGI) – specyfikacja dostępna na [59]. 184 Autor ma na myśli duŜą liczbę rozszerzeń w postaci modułów jak i równieŜ dodatkowych bibliotek np.: projekt PEAR. 185 PEAR - PHP Extension And Application Repository. Jest to środowisko oraz system dystrybucji rozszerzeń do PHP jako oprogramowania na licencji open source. 186 Java Script zorientowany jest na ścisła współpracę z dokumentami HTML. Posiada wbudowaną strukturę obiektową dokumentu (np. froms, links, applets, hisotry), do którego elementów moŜna łatwo się odwoływać.

Centrum Komunikacji Osobistej

177

AJAX

Jest stosunkowo nową techniką187, która wypełnia lukę pomiędzy moŜliwościami języka

Java Script, a PHP. Jej głównym atutem jest moŜliwość aktualizacji strony bez konieczności

jej przeładowania, asynchronicznie. Ta funkcjonalność umoŜliwia budowę aplikacji, która

posiada cechy takie jak tradycyjna aplikacja stacjonarna tzw. „stand-alone”. Przewaga nad

aplikacją stand-alone polega na tym, Ŝe aplikacji sieciowej nie trzeba instalować, a do jej

działania potrzebna jest zwykła przeglądarka WWW.

RóŜnicę pomiędzy działaniem strony zbudowanej z wykorzystaniem techniki AJAX, a

zwykłą stroną WWW pokazano na Rys. 96 i Rys. 97. Poszczególne elementy strony zasilane

są w porcje danych, jeśli zajdzie taka potrzeba, dzięki czemu oszczędza się pasmo, a

zawartość strony zostaje wyświetlona duŜo szybciej (następuje uaktualnienie jedynie

określonych jej części).

AJAX stanowi konglomerat technik:

� XHTML i CSS – do tworzenia interfejsu uŜytkownika,

� DOM – do obsługi elementów dynamicznych i zdarzeń, XML.

Dane wymieniane są z wykorzystaniem obiektu XMLHttpRequest188. Techniki te łączone są w

całość z wykorzystaniem Java Scriptu, który odpowiada za logikę aplikacji oraz dynamiczną

budowę interfejsu.

187 Technika ta powstała w końcu roku 2006 i stała się hitem w programowaniu stron HTML. 188 Jest to standardowy element wielu przeglądarek, np. w Internet Explorer jest to wbudowany obiekt ActiveX, natomiast w Fire Fox i innych jest obiektem Java Script. MoŜe jednak wystąpić nie kompatybilność ze starszymi przeglądarkami niŜ IE 5.5, FF 1.5. Posiada proste API pozwalające na wysyłanie drobnych Ŝądań GET/POST.

Centrum Komunikacji Osobistej

178

Przeglądarka Server

(1) request: index.phpGET

(2) generowanie index.php(3) wywołanie AJAX

ze zdarzenia JavaScript

(5) uzupełnienie Ŝądanej treści z

uŜyciem modelu DOM

POST(4) Przetworzenie Ŝądania AJAX

(8) wywołanie AJAX

ze zdarzenia JavaScript

(9) uzupełnienie Ŝądanej treści

z uŜyciem modelu DOM

(7) Przetworzenie Ŝądania AJAXPOST

Utworzenie obiekt XMLHttpRequest

v

Wypełniony danymi obiekt XMLHttpRequest

Ŝądanie odpowiedź

Rys. 96: Sposób wymiany Ŝądań i odpowiedzi pomiędzy klientem a serwerem z wykorzystaniem techniki

AJAX.

Rys. 97: Przepływ Ŝądań i odpowiedzi w standardowym modelu dla protokołu HTTP.

TLS

Transport Layer Security jest rozwinięciem protokołu SSL (Secure Socjet Layer).

Zapewnia poufność i integralność transmisji danych oraz uwierzytelnienie na poziomie od

warstwy transportu w górę modelu OSI. TLS został wykorzystany w aplikacji do zapewnienia

bezpieczeństwa podczas wymiany danych pomiędzy serwerem, a przeglądarką oraz

autoryzacji uŜytkownika.

11.3 Proces tworzenia aplikacji z wykorzystaniem Parlay X

Zbudowanie aplikacji wykorzystującej interfejsy Parlay X wymaga poczynienia

następujących kroków:

Centrum Komunikacji Osobistej

179

1. Wyszukanie interesujących usług sieciowych w węzłach UDDI189;

2. Pobranie opisu usługi sieciowej w postaci WSDL z UDDI lub bezpośrednio ze

strony zwierającej specyfikację Parlay X (np. www.parlay.org);

3. Wygenerowanie zrębu aplikacji – metod, za pomocą których będą wołane usługi;

4. Stworzenie aplikacji;

5. Rejestracja/podpisanie stosownej umowy z dostawcą usług sieciowych w celu

późniejszego rozliczenia oraz w kwestiach bezpieczeństwa;

6. Wywoływanie usług sieciowych.

Zatem moŜna zauwaŜyć, iŜ oczekiwania względem programisty, który chce stworzyć

usługę telekomunikacyjną sprowadzają się do posiadania przez niego wiedzy i umiejętności

posługiwania się Web Services. W chwili wygenerowania zrębu aplikacji zadaniem

programisty jest jedynie odpowiednie wywoływanie usług, tak jak w przypadku zwykłych

funkcji w dowolnie wybranym i preferowanym przez niego języku programowania. PoniŜej

zostaną omówione kroki 3. i 4. na przykładzie aplikacji Osobiste Centrum Komunikacyjne.

11.4 Komponenty aplikacji

Aplikacja składa się z trzech rodzajów komponentów190 tj.:

� komponenty zajmujące się prezentacją informacji,

� komponenty z logiką aplikacji, w których następuje wywołanie odpowiednich usług

sieciowych i przetworzenie pozyskanych danych oraz

� komponent zajmujący się komunikacją pomiędzy dwoma wyŜej wymienionymi

rodzajami komponentów.

Jednym z powodów wprowadzenia podziału na komponenty, była potrzeba oddzielenia

prezentacji od logiki. Dzięki temu moŜna w łatwy sposób rozszerzać aplikację o kolejne

moduły funkcjonalne np.: moduł związany z usługa lokalizacji, SMS, MMS191, itd..

Sprowadza się to jedynie do dopisania modułu zajmującego się odpytywaniem usług

sieciowych, dodania funkcji AJAX łączącej logikę z prezentacją oraz dopisania kodu HTML

kotwiczącego oraz formatującego otrzymaną informację. W ten sposób zbudowana aplikacja

189 Patrz rozdział 4.5. 190 Autor dla porządku komponentem nazywa podstawowy składnik aplikacji (np.: komponent z logiką usługi obecności, komponent prezentujący usługę obecności). Zbiór komponentów oferuje pewną funkcjonalność. Taki zbiór komponentów nazywany będzie modułem. 191 Patrz specyfikacja interfejsów Parlay X [8].

Centrum Komunikacji Osobistej

180

pozwala równieŜ na realizację załoŜenia projektowego, które dotyczyło moŜliwości

personalizowania przez uŜytkownika aplikacji i rozliczania jego za wybraną liczbę modułów

funkcjonalnych.

Komponenty te zostały przedstawione na Rys. 98 i odpowiednio rozdzielone na

powyŜej wymienione grupy. Dodatkowym element, który został wyróŜniony na Rys. 98 jest

arkuszy styli (CSS192), który w transparentny i globalny sposób pozwala zarządzać

formatowaniem elementów HTML.

Graphical UserInterface

(center.php)

Security and authorization(index.php)

Third Party Call Control GUI

(makeCallGUI.php)

Stylesheet CSS(style.css)

Address List Managment

and Presence GUI(groups.php)

onLoadAll

showCustomer

GetXmlHttpObject

addMember

deleteMember

makeCallFeatures

makeCall

setPresence

fillMenuCallHandling

showRules

clearRules

blockedNumber

forwardingNumber

stateChangeXXX

AJAX Logic

(logic.js)

getPresence

Address List Managment

and Presence Logic(groups.php)

queryMembers

deleteMember

addMember

createGroup

deleteGroup

3rd Party Call Control Logic(makeCall.php)

makeCall

endCall

Call Handling(callhandling.php)

getRules

clearRules

setRules

Seting up Presence(setPresence.php)

publishPresence

PEAR/SOAP

getProxy

Komponenty odpowiedzialne

za prezentację Komponenty z logiką biznesową

Komponent AJAX

CallHandling GUI(callhandling.php)

Rys. 98: Podział funkcjonalny komponentów oraz podział na rodzaje komponentów aplikacji "Centrum

Komunikacji Osobistej"

11.4.1 Opis komponentów prezentacji

Komponenty prezentacji (Third Party Call Control GUI, Address List Managment and

Presence GUI, Call Handling GUI) zagnieŜdŜone są w stronie HTML (center.php), za

pomocą znaczników <div> , w których dynamicznie (bez konieczności przeładowania strony z

192 CSS2 – Cascading Style Sheets, level 2, Specyfikacja CSS w [46]

Centrum Komunikacji Osobistej

181

wykorzystaniem techniki AJAX) moŜe być wstawiany obiekt HTML. W tym przypadku w

stosunkowo łatwy sposób moŜna zrealizować funkcjonalność wyboru przez uŜytkownika

interesujących go modułów. Odbywa się to na poziomie języka PHP. Po uzyskaniu

toŜsamości uŜytkownika, następuje wygenerowanie siatki strony HTML jedynie z wybranymi

znaczkami <div> , które reprezentują poszczególne moduły. W dalszej kolejności wypełnienie

znacznika <div> realizowane jest za pomocą funkcji z komponentu AJAX Logic

(showCustomer(...) , makeCallFeatures(...) , fillMenuCallHandling(...) ,

showRules(...) ).

W komponencie Address List Managment and Presence zostało uwzględnione równieŜ

sterowanie własną informacją o obecności tj. publikowanie oraz jej pobieranie.

Warto wspomnieć, iŜ logika związana ze sterowaniem prezentacją została zaszyta w

komponencie AJAX Logic.

11.4.2 Opis komponentów z logiką aplikacji

Głównym zadaniem komponentów zawierających logikę aplikacji (Setting up

Presence, Address List Managment and Presence Logic, Call Handling, 3rd Party Call

Control Logic) jest odpytywanie usług sieciowych, przetworzenie otrzymanej struktury

danych w odpowiedzi i przygotowanie odpowiedzi na Ŝądanie obiektu AJAX

XMLHttpRequest. Komponenty z logiką biznesową zostały napisane w języku PHP193 ze

względu na istnienie oraz łatwość uŜycia odpowiednich bibliotek wspierających Web Services

(PEAR/SOAP).

KaŜdy komponent tego typu został podzielony na sekcje związane z funkcjonalnością

danego modułu. Np., Logika modułu call handling składa się z trzech sekcji setRules,

getRules, clearRules. Części te są odpowiednio odwzorowywane na funkcje komponentu

AJAX Logic.

W ramach kaŜdej z tych sekcji następuje obsługa usługi sieciowej, która realizowana

jest w trzech krokach:

� ustawienie referencji na Ŝądaną usługę sieciową:

$wsdl=new SOAP_WSDL('http://localhost:8180/axis2/se rvices/CallHa

ndlingService?wsdl');

193 Technika AJAX moŜe współpracować z innymi językami, poniewaŜ komunikacja pomiędzy klientem, a serwerem realizowana jest w oparciu o obiekt przenoszący XML.

Centrum Komunikacji Osobistej

182

� przygotowanie wywołania – stworzenie struktury danych z parametrami

przekazanymi w Ŝądaniu HTTP:

$request = array(

'address' => $_GET['address'],

'rules' => array (

'blockList' => $blockList,

'forward' => array(

'forwardingAddress' => $fo rwardingAddress,

'onBusyAddress' => $forwar dingAddress,

'onNoAnswerAddress' => $fo rwardingAddress

)

)

);

� wywołanie funkcji na obiekcie reprezentującym usługę sieciową:

$response = $client->setRules($request);

� przetworzenie zgodnie z wymaganiami odpowiedzi z usługi sieciowej i wypisanie na

standardowe wyjście PHP. Odpowiedź podobnie jak Ŝądanie jest przewaŜnie tablicą

asocjacyjną z indeksami będącymi nazwami zmiennych.

11.4.3 Opis komponentu AJAX

Komponent AJAX Logic jest łącznikiem pomiędzy graficznym interfejsem

uŜytkownika, a logikę biznesową. Zdarzenie wywołane przez uŜytkownika powoduje

wywołanie funkcji komponentu (np. showRules(...) , makeCall(...) , itp..) zgodnie z

modelem zdarzeń w Java Script. Funkcje te muszą być zbudowane w następujący sposób:

� po pierwsze musi zostać stworzony obiekt XMLHttpRequest (w przypadku, gdy dana

przeglądarka nie obsługuje, wyjątek ten powinien zostać odpowiednio obsłuŜony);

� ustalić adres względny URL komponentu, do którego ma zostać przekazane

wywołanie (np. ../callhandling.php )

� do adresu URL dołączyć tzw. Query String z przekazanymi do funkcji parametrami

(?method=addMember&group=sip:[email protected] )

� ustawić dla właściwości onreadystatechange obiektu XMLHttpRequest tzw.

EventHandler. EventHandler moŜe być dowolną funkcją, która powinna zwrócić 4 w

Centrum Komunikacji Osobistej

183

przypadku, gdy zostanie odebrana cała odpowiedź od serwera. Funkcja ta zastępuje

odpowiedni <div> zawartością odpowiedzi z XMLHttpRequest

(document.getElementById("BuddyList").innerHTML=xmlH ttp.responseText )

.

� Otworzyć połączenie dla wybranego Ŝądania HTTP (np. GET): funkcja

open( Ŝądanie, url, czy wysła ć);

� Wysłać Ŝądanie (funkcja send(null) ).

Komponent AJAX Logic, ma równieŜ modułową budowę, która zapewnia łatwą

rozbudowę aplikacji o kolejne moduły funkcjonalne. Dodanie nowego modułu wiąŜe się ze

stworzeniem nowego EventHandler’a oraz dopisaniem funkcji przywiązanej do określonego

zdarzenia Java Script.

11.4.4 Zasada działania aplikacji

Rejestracja uŜytkownika

Pierwszym etapem w interakcji uŜytkownika z aplikacją jest rejestracja do systemu.

UŜytkownik podaje standardowo login i hasło. Strona zawierająca komponent Security and

authorization zabezpieczona jest z wykorzystaniem protokołu TLS. Dane rejestracyjne są

przesyłane w zaszyfrowanym kanale TLS do serwera. Na serwerze następuje komunikacja z

bazą HSS zawierającą profil uŜytkownika oraz sprawdzenie toŜsamości i uprawnień

uŜytkownika. Ten etap komunikacji nie jest juŜ zabezpieczony, poniewaŜ zgodnie z definicją

JAIN realizowany jest w obszarze bezpiecznym naleŜącym do operatora sieci

Centrum Komunikacji Osobistej

184

Zestawianie połączenia (moduł Make Call)

Rys. 99: Interakcje pomiędzy komponentami w scenariuszu zestawiania połączenia

Pod danym przyciskiem na interfejsie graficznym zostało podpięte zdarzenie Java

Script onClick, a pod zdarzeniem funkcja makeCall(...) . Przeglądarka wywołuje funkcję

makeCall(...) (patrz Rys. 99) w momencie kliknięcia przez uŜytkownika przycisku. Dane o

URI stron, pomiędzy którymi ma zostać zestawione połączenie zostają pobrane z formularza i

przekazane do funkcji makeCall(...) . Funkcja makeCall(...) tworzy nowy obiekt

XMLHttpRequest oraz przygotowuje zapytanie, które ma zostać wysłane do serwera.

Zapytanie (patrz Rys. 99, URL) kierowane jest na adres pliku, w którym znajduje się

komponent makeCall i zawiera nazwę metody oraz adresy stron. Serwer po odebraniu

zapytania wykonuje Web Service Zestawianie Połączenia i w odpowiedzi otrzymuje

identyfikator połączenia, w przypadku gdy połączenie doszło do skutku. Dalej przesyła

dokument XML w obiekcie XMLHttpObject do aplikacji AJAX (moduł AJAX Logic). W

momencie, gdy zostanie przesłany cały XMLHttpObeject funkcja stateChangeMakeCall()

zwraca wartość 4, po czym następuje nadpisanie elementu <div> , w którym zakotwiczony

jest moduł Make Call.

Centrum Komunikacji Osobistej

185

Rys. 100: Diagram UML dla realizowanych kolejno procesów logowania do aplikacji, dodawania nowego

kontaktu do listy, aktualizowania informacji na li ście kontaktowej i w module make call.

Centrum Komunikacji Osobistej

186

11.5 Ograniczenia i propozycje ich rozwiązania

W trakcie tworzenia aplikacji „Centrum Komunikacji Osobistej” pojawiały się

problemy ze spełnieniem załoŜeń projektowych, wynikające z ograniczeń, które posiadały

uŜyte techniki. Ich opis oraz proponowane rozwiązania zostaną przedstawione poniŜej.

Problem związany z brakiem asynchronicznej komunikacji pomiędzy serwerem i

klientem oraz niewystarczająca ilość informacji na temat powodzenia zestawienia bądź

zakończenia połączenia. Dla przykładu wywołanie przez uŜytkownika funkcji

makeCall(...) powoduje zainicjowanie zestawiania sesji pomiędzy dwoma UAs.

UŜytkownik jednak nie otrzymuje informacji zwrotnej na temat tego, czy połączenie doszło

do skutku tzn. czy obie strony je odebrały, czy któraś ze stron była moŜe nie dostępna itp..

Jedyną informacją uzyskiwaną w tym przypadku z wywołania makeCall(...) na usłudze

sieciowej jest potwierdzenie, Ŝe wywołano tą funkcję w Serwerze Sterowania Połączeniami

oraz zwrócony identyfikator połączenia. Autor zaproponował w związku z tym wzbogacenie

informacji o stanie realizowanego połączenia rozszerzając funkcjonalność Serwera

Sterowania Połączeniami194. Odbywa się to po przez zwrócenie odpowiedniego ciągu

znakowego. W przypadku, gdy jedna ze stron jest niedostępna, tzn. Serwer Sterowania

Połączeniami otrzymał wiadomość SIP ‘480 Temporarily Unavailable’ w odpowiedzi usługa

sieciowa zwraca treść tej wiadomości. Natomiast identyfikator połączenia (czyli dowolny ciąg

znaków brany z wygenerowanego nagłówka Call-Id) jest zwracany, gdy Serwer Sterowania

Połączeniami otrzyma wiadomość ACK od strony B. Oznacza to, Ŝe w kaŜdej z

wymienionych wyŜej sytuacji Serwer Sterownia Połączeniami musi zatrzymać na określony

czas wywołanie do momentu otrzymania odpowiedniej wiadomości SIP. Jest to wspomniany

wcześniej problem braku wsparcia dla asynchronicznej komunikacji pomiędzy dostawcą

usługi sieciowej, a jej Ŝądającym. Zbyt długie wstrzymanie Serwera Sterowania Połączeniami

powoduje nieoptymalne wykorzystanie zasobów oraz moŜne doprowadzić do przekroczenia

czasów oczekiwania (time-out) co w efekcie spowoduje wygenerowanie błędu po stronie

klienta, nawet jeśli połączenie doszło do skutku. Jedyną moŜliwością rozwiązania problemu

asynchroniczności request-response jest ustawienie stosunkowo długich time-out na kaŜdym

194 NaleŜy wspomnieć, iŜ zaproponowane rozszerzenie nie jest w pełni zgodne ze specyfikacją Parlay X (patrz [16]), jednak zdaniem autora zwiększa ona znacznie funkcjonalność związaną z zestawianiem połączenia przez trzecią stronę. Zgodnie ze specyfikacją Parlay X informacja, która winna być zwrócona to identyfikator zestawionego połączenia. Przypomnę, Ŝe identyfikator połączenia jest nadawany w momencie wysłania pierwszej wiadomości INVITE i jest to nagłówek Call-Id.

Centrum Komunikacji Osobistej

187

etapie przekazywania odpowiedzi tj. w usłudze sieciowej (konfiguracja AXIS2) oraz na

serwerze WWW.

Problem dotyczący otrzymywania wiadomości jedynie za pomocą standardowego

modelu Ŝądanie-odpowiedź, kwestia asynchroniczności. Istota tego problemu po części jest

związana z tematyką poprzedniego, lecz w tym przypadku zagadnienie asynchroniczności

zostanie rozpatrzone na poziomie aplikacji klienckiej. Problem ten pojawił się m.in. przy

budowie modułu Address List Managment and Presence. Moduł ten wyświetla informacje o

obecności innych obserwowanych uŜytkowników. W przypadku, gdy jeden z nich zmieni

swój stan moduł powinien tą informację zaktualizować. Ze względu na protokół HTTP

aktualizacja informacji wyświetlanych na stronie odbywa się w wyniku ponownego Ŝądania

skierowanego do serwera. AŜeby stan obserwowanych uŜytkowników był w miarę

moŜliwości aktualny, strona powinna być odświeŜana stosunkowo często. Oczywiście

kaŜdorazowe odświeŜenie powoduje zbędne obciąŜenie serwera, poniewaŜ przewaŜenie w tak

krótkim czasie stan obserwowanych nie ulegnie zmianie. Jednak jako uŜytkownicy

chcielibyśmy, aby informacje o stanie obserwowanych uŜytkowników były w miarę

moŜliwości aktualne, tak, więc nie moŜna wydłuŜyć czasu pomiędzy kolejnymi

przeładowniami strony. Dodatkowo przeładowanie strony zajmuje określony czas, co czyni

aplikację mało atrakcyjną i niewygodną w uŜyciu195. Poza tym na stronie znajdują się inne

moduły, które nie wymagają tak częstego odświeŜania, jednak przy odświeŜeniu serwer i tak

będzie musiał wygenerować całą stronę, co powoduje znaczące marnotrawienie jego

zasobów. Największe obciąŜenie poza standardowym Ŝądaniem HTTP następuje podczas

wykonania skryptu PHP. Rozwiązaniem mogłoby być uŜycie języka kompilowanego np.:

C/C++ i wykorzystanie dość mało elastycznego, jednakŜe wydajnego mechanizmu CGI196

(Common Gateway Interface). UŜywając CGI nie moŜna ominąć jednak zasadniczej kwestii

związanej cyklicznym częstym przeładowywaniem strony.

Rozwiązanie tego problemu wymagało zaproponowania przez autora mechanizmu,

który pozwoli aplikacji przeładować wyłącznie197 moduł Address List Managment and

Presence jedynie w momencie, gdy którykolwiek z obserwowanych uŜytkowników zmieni

swój stan.

195 Wyobraźmy sobie, Ŝe nasza aplikacja jest przeładowywana co 5 sekund. 196 Specyfikacja znajduje się w [59]. 197 Aktualizacja pojedynczego modułu zapewnia wcześniej opisywana technika AJAX.

Centrum Komunikacji Osobistej

188

Po stronie klienta utworzono funkcję, która dysponowała maską modułów

wymagających asynchronicznej aktualizacji. Funkcja ta została napisana w Java Script i

zostaje wykonywana cyklicznie w tle. W ramach kaŜdego wykonania zostaje utworzone

Ŝądanie HTTP z minimalną ilością danych (zmienna typu boolowskiego dla kaŜdego z

modułu), potrzebnych jedynie do stwierdzenia, czy dany moduł powinien zostać

zaktualizowany, czy teŜ nie (ustawiana odpowiednio wartość true lub false). Przychodząca

odpowiedź HTTP ze strony serwera zostaje prasowana i po czym następuje sprawdzenie, czy

któraś ze zmiennych została ustawiana na true. Jeśli tak, dokonywane jest wywołanie

odpowiedniej funkcji z komponentu AJAX Logic i przeładowanie wybranego modułu. Innym

ciekawym podejściem do uporania się z omawianym problemem jest mechanizm tzw. HTTP

Streaming. Jest ono rozszerzeniem techniki AJAX polegającym na utrzymywaniu non stop

otwartego połączenia pomiędzy klientem, a serwerem. W czasie trwania połączenia

pojawiające dane natychmiast przesyłane są do klienta.

Oczywiście zaproponowane mechanizmy nie rozwiązują problemu cyklicznego

wykonywania zapytania na poziomie usług sieciowych, co powoduje znaczące obciąŜenie

serwera WWW (jako Ŝądającego usług sieciowych) oraz serwera dostawcy usług

sieciowych198. Wprowadzenie podobnego rozwiązania w usługach sieciowych nie wchodziło

w rachubę, gdyŜ wymagałoby znacznych ingerencji w aplikację będącą dostawcą usług

sieciowych (aplikacja AXIS2). Poza tym, tak zmodyfikowaną aplikację trudno było by

traktować w kategoriach Web Services.

198 NaleŜy pamiętać, Ŝe dostawca usług sieciowych to aplikacja webowa rozmieszczona na serwerze aplikacyjnym Tomcat. Ze względu na to, iŜ jest to środowisko Javy, częste wywołania usług sieciowych w tym środowisku wymagają duŜych mocy obliczeniowych. PoniewaŜ w danym momencie z danej usługi sieciowej moŜe korzystać wielu uŜytkowników wyobraźmy sobie jak znacząco moŜe wzrosnąć obciąŜenie serwera aplikacyjnego (dostawcy usług), które jest wielokrotnością funkcji, która jako argument przyjmuje częstość wykonywania danej usługi przez pojedynczego uŜytkownika.

Podsumowanie

189

12. Podsumowanie

W ramach tej pracy powstało środowisko złoŜone z implementacji wybranych

rdzeniowych199 elementów architektury funkcjonalnej IMS (P-CSCF, S-CSCF, HSS). Zakres

implementacji ograniczony został do procedur umoŜliwiających modelowanie mechanizmu

sterowania usługami200. Kolejnymi komponentami wchodzącym w skład środowiska

badawczego były serwery aplikacyjne implementujące wybrane interfejsy Parlay X API, które

zarówno obsługiwały zgłoszenia skierowane przez S-CSCF (SIP), jak i przez aplikacje

realizującą usługę końcową (SOAP). Przedmiotem implementacji była takŜe aplikacja

„Centrum Komunikacji Osobistej” (CKO) 201, która stanowiła praktyczne sprawdzenie

moŜliwości zrealizowanej architektury.

Rys. 101: Zaimplementowane elementy

Środowisko (Rys. 101) posłuŜyło do analizy czterech problemów:

1. Model sterowania usługami IMS;

2. Realizacja usług w architekturze dwuwarstwowej tj. w warstwie komponentów

usługowych (serwery Parlay X) i w warstwie aplikacji (CKO);

199 W rozumieniu architektury ETSI NGN [17], rdzeniowy IMS (IMS Core) to elementy realizujące wyłącznie funkcje sterowania zgłoszeniami i połączeniami. 200 Mechanizm ten polega na selektywnym przekazywaniu obsługi zgłoszeń do serwerów aplikacyjnych, zgodnie z tzw. regułami filtracji wiadomości SIP (IFC), zawartymi w profilu uŜytkownika. 201 Takich jak ksiąŜka adresowa z funkcją statusu obecności, przekierowanie/blokowanie połączeń, itd..

Podsumowanie

190

3. Implementacja usług za pomocą róŜnych modeli programistycznych na

przykładzie JSLEE, JAIN-SIP, oraz z wykorzystaniem serwisów sieciowych (Web

Services – protokół SOAP);

4. Wykorzystanie rozwiązań open-source w telekomunikacji (szczególnie projekty:

Mobicents JSLEE, Asterisk, Open SER).

Model sterowania usługami IMS

Mechanizm kierowania zgłoszeń do serwerów aplikacyjnych oparty o syntaktyczną

analizę wiadomości SIP w zaleŜności od reguł IFC zawartych w profilu uŜytkownika jest

podstawą modelu sterowania usługami w IMS. Daje on duŜą elastyczność w budowaniu usług

w środowisku wielu serwerów aplikacyjnych. Ta elastyczność wynika głównie z tego, Ŝe

analiza wiadomości jest niskiego poziomu (syntaktyczna). Takie podejście pociąga za sobą

brak bezpośredniego związku pomiędzy scenariuszem usługi (semantyką usługi), a regułami

kierowania zgłoszeń, które wyzwalają wykonanie tej usługi. Ze względu na to definicje IFC

powinny być tworzone z uwzględnieniem wieloznaczności protokołu SIP202, co moŜe rodzić

duŜą złoŜoność tego procesu i wymaga opracowania odpowiednich narzędzi, których obecnie

brak.

Potrzeba dokładnych definicji reguł IFC jest teŜ takŜe wymagana ze względu na

znaczny wzrost ruchu sygnalizacyjnego przy stosowaniu przekierowania wiadomości SIP na

serwery aplikacyjne. Dokładne definicje powinny uwzględniać charakter usługi (co jest

trudne) i minimalizować sytuacje, w których zgłoszenie jest kierowane do serwera

aplikacyjnego pomimo, Ŝe scenariusz usługi tego nie wymaga203.

W środowisku, w którym wiele niezaleŜnych usług jest realizowanych na jednym

serwerze aplikacyjnym, występują problemy związane z interakcjami pomiędzy

scenariuszami usługowymi. W takich sytuacjach mechanizm IFC realizowany w serwerze S-

CSCF nie ma zastosowania i wymagana jest implementacja komponentu odpowiedzialnego

za właściwe kierowanie zgłoszeń w ramach serwera aplikacyjnego. To rozwiązanie zostało

nazwane SCIM, lecz nie zostało ustandaryzowane i w praktyce jest realizowane na kilka

róŜnych sposobów w zaleŜności od implementacji serwera aplikacyjnego. MoŜe to skutkować

202 Te same wiadomości w róŜnych kontekstach mogą być wynikiem realizacji róŜnych usług lub roŜne wiadomości nie, kiedy realizują identyczne funkcje. 203 W takiej sytuacji serwer aplikacyjny pełni funkcje wyłącznie serwera Proxy nie wnosząc nic do scenariusza realizowanego połączenia.

Podsumowanie

191

nieprzenaszalnością komponentów realizujących usługi pomiędzy róŜnymi serwerami

aplikacyjnymi204.

Budowa usług w modelu wykorzystującym Parlay X w systemie IMS

Abstrakcyjność interfejsów Parlay X sprawia, Ŝe aplikacje realizujące usługi mogą

wykonywać swoje scenariusze niezaleŜnie od techniki stosowanej w sieci

telekomunikacyjnej. Implementacja w ramach tej pracy dotyczyła sieci opartej o model NGN,

bazującej na systemie IMS, w którym protokołem sterowania zgłoszeniami jest SIP. Wybrane

interfejsy Parlay X zostały zaimplementowany jako serwery aplikacyjne, które z jednej strony

uczestniczą w modelu sterowania usługami IMS, a z drugiej udostępniają API poprzez

serwisy sieciowe. Serwery aplikacyjne w takim modelu są odpowiedzialne za konwersje

wywołań funkcji takich jak makeCall czy getPresence na sekwencje wiadomości SIP.

Definicja interfejsów Parlay X ma charakter semantyczny, tzn. bezpośrednio wiąŜe się

ze scenariuszem usługowym, a model sterowania usługami IMS jest oparty o analizę

syntaktyczną. Ze względu na to implementacja Parlay X w środowisku systemu IMS jest

bardzo zasadna, poniewaŜ umoŜliwia „przykrycie” przesłonięcie złoŜoności i duŜej liczby

parametrów protokołu SIP, bardzo prostym API.

Techniki programistyczne

Podczas implementacji środowiska badawczego wykorzystano wiele technik

programistycznych, które umoŜliwiły spełnienie przyjętych załoŜeń projektowych

uwzględniających równieŜ m.in. aspekty bezpieczeństwa, wydajności, łatwości uŜycia oraz

funkcjonalności. Techniki te obejmują m.in.:

� język C, w którym został napisany moduł realizujący funkcjonalność CSCF oraz

implementacja interfejsów do HSS. Na poziomie sterowania zgłoszeniami istotną rolę

odgrywa wydajność serwera CSCF.

� język Java wraz z biblioteką dla JAIN SIP API wykorzystany do implementacji

interfejsów Parlay X API. JAIN SIP API pozwala na uŜycie niskopoziomowych

204 W ramach implementacji S-CSCF w środowisku badawczym wprowadzony został mechanizm umieszczania w wiadomościach SIP (przekierowanych do AS) specjalnego nagłówka P-Service-Name (jest to rozszerzenie zaproponowane w ramach tej pracy), który umoŜliwiałby przeniesienie informacji dotyczącej analizy IFC do AS. Ten dodatkowy nagłówek zawiera informacje, do jakiej usługi (definicji IFC) zostało zakwalifikowane zgłoszenie, zwalniałoby to serwer aplikacyjny z konieczności tej analizy i przez to znacznie upraszczało SCIM. To rozwiązanie pomimo, Ŝe zostało zaimplementowane, nie zostało uwzględnione w opisie, gdyŜ nie rozwiązuje problemu interakcji pomiędzy usługami, tylko upraszcza implementacje elementu SCIM, powodując przy tym wiele negatywnych konsekwencji (np. wzrost ilości przekierowań z S-CSCF do AS).

Podsumowanie

192

mechanizmów protokołu SIP. Do komunikacji pomiędzy serwerami z logiką usług, a

serwerem z interfejsami Web Services zastosowano RMI.

� usługi sieciowe (Web Services) będące częścią specyfikacji Parlay X API. Usługi

sieciowe umoŜliwiają korzystanie z usług dostarczanych przez sieć telekomunikacyjną

w sieci Internet. Zapewniają bezpieczeństwo sieci operatora oraz charakteryzują się

prostotą uŜycia.

� techniki wykorzystywane w tworzeniu aplikacji sieciowych m.in. Java Script, PHP,

XHTML, XML i AJAX. Na wyróŜnienie zasługuje technika AJAX, dzięki której

strona internetowa nie musi być przeładowywana. Strona zapewnia uŜytkownikowi

duŜy poziom interakcyji oraz bogatą funkcjoanloność. Przykładem zastosowania jest

np. strona do obsługi poczty Google: www.gmail.com.

� Transport Layer Security zabezpieczająca komunikację pomiędzy aplikacją sieciową,

a serwerem WWW.

Rozwiązania open-source

Stworzone środowisko badawcze opiera się wyłącznie na rozwiązaniach open source,

gdyŜ próba napisania całego środowiska od początku wymagałaby nakładu pracy licznego w

setkach osobolat. Jest to pewien dowód na to, iŜ open-source dostarcza na tyle dojrzałe

rozwiązania, aby mogły być z powodzeniem wykorzystywane w telekomunikacji, choćby w

procesie prototypowania. Takie podejście pozwala przyśpieszyć implementację nowych

koncepcji. UŜyte oprogramowanie charakteryzowało się wysoką jakością, o czym moŜe

świadczyć fakt stosowania go w produktach komercyjnych (np. Open SER, Linux, Asterisk).

W projekcie wykorzystano następujące rozwiązania:

� Open SER;

� Serwer aplikacyjny Apache Tomcat;

� Mobicents - JAIN SLEE;

� Centralkę IP PBX Asterisk;

� System operacyjny Linux dystrybucja Debian’a.

Kierunki dalszej rozbudowy

Zbudowane środowisko badawcze na potrzeby niniejszej pracy stanowi podstawową

implementację systemu IMS, która moŜe zostać wykorzystana do testowania róŜnych

koncepcji kreacji usług telekomunikacyjnych. W trakcie powstawania tej pracy został

udostępniony na licencji GPL projekt Open IMS Core (patrz rozdział 6), który stanowi

Podsumowanie

193

kompletną implementację elementów warstwy sterowania połączeniami tj. CSCF i HSS. W

związku ewentualna rozbudowa moŜe być oparta właśnie o ten projekt. W obszarze

aplikacyjnym środowisko badawcze moŜe być wzbogacone poprzez:

� implementacje pozostałych interfejsów Parlay X jako serwerów aplikacyjnych;

� wykorzystanie serwera aplikacyjnego JSLEE do budowy usług lub implementacji

interfejsów Parlay X;

� do zainstalowania serwera aplikacyjnego z kontenerem do obsługi SIP Servlet.

Bibliografia

194

13. Bibliografia

[1] 3GPP TR 23.982 - IP Multimedia System (IMS) centralized services

[2] 3GPP TR 24.879 - Combining CS calls and IMS sessions

[3] 3GPP TS 23.002 – Network Architecture

[4] 3GPP TS 23.228 - IP Multimedia Subsystem (IMS); Stage 2

[5] 3GPP TS 24.206 - Voice Call Continuity between the Circuit-Switched (CS) domain and

the IP Multimedia Core Network (CN) (IMS) subsystem

[6] 3GPP TS 24.228 - Signaling flows for the IP multimedia call control based on Session

Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3

[7] 3GPP TS 24.229 - IP Multimedia Call Control Protocol based on Session Initiation

Protocol (SIP) and Session Description Protocol (SDP); Stage 3

[8] 3GPP TS 29.199-X - Open Service Access (OSA); Parlay X web services;

[9] 3GPP TS 29.228 - IP Multimedia (IM) Subsystem Cx and Dx Interfaces; Signaling flows

and message contents

[10] 3GPP TS 32.240 - Telecommunication management; Charging management; Charging

architecture and principles

[11] 3GPP TS 32.260 - Telecommunication management; Charging management; IP

Multimedia Subsystem (IMS) charging

[12] Alan B. Johnston, "SIP: Understanding the Session Initiation Protocol", Artech House

2004

[13] Daniel Söbirk, Håkan Jonsson, Kristofer Kimbler - "IMS Programming Models for

Different Business Requirements - Evaluating Existing Programming Models for

SIP/IMS"; konferencja ICIN 2006

[14] Dr. Christoph Bröcker, Sven Haiges, Michael Maretzke - "Ereignisorientierte

Komponenten mit JAIN SLEE", javaspectrum.de, 2005

[15] ECMA Script Language Specification, 1999

Bibliografia

195

[16] ETSI ES 204 915 - Open Service Access (OSA); Application Programming Interface

(API);

[17] ETSI ES 282 001 - NGN Functional Architecture Release 1

[18] ETSI TR 102 397 - Open Service Access (OSA); Mapping of Parlay X 2 Web Services

to Parlay/OSA APIs; Draft

[19] IETF draft-sinha-sip-block, Amardeep Sinha, Sunil Kumar Sinha, The SIP BLOCKED

Response

[20] IETF RFC 2327 - SDP: Session Description Protocol

[21] IETF RFC 2818 - HTTP Over TLS

[22] IETF RFC 3261 - SIP: Session Initiation Protocol

[23] IETF RFC 3264 - An Offer/Answer Model with the Session Description Protocol (SDP)

[24] IETF RFC 3325 - Private Extensions to the Session Initiation Protocol (SIP) for

Asserted Identity within Trusted Networks

[25] IETF RFC 3455 - Private Header (P-Header) Extensions to the Session Initiation

Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)

[26] IETF RFC 3725 - Best Current Practices for Third Party Call Control (3pcc) in the

Session Initiation Protocol (SIP)

[27] IETF RFC 3840 - Indicating User Agent Capabilities in the Session Initiation Protocol

(SIP)

[28] IETF RFC 3863 - Presence Information Data Format (PIDF)

[29] IETF RFC 3903 - Session Initiation Protocol (SIP) Extension for Event State

Publication

[30] IETF RFC 4317 - Session Description Protocol (SDP) Offer/Answer Examples

[31] IETF RFC 4346 - The Transport Layer Security (TLS) Protocol

[32] IETF RFC 4480 - RPID: Rich Presence Extensions to the Presence Information Data

Format (PIDF)

[33] ITU-T Y.2001 - General overview of NGN

Bibliografia

196

[34] ITU-T Y.2011 - General principles and general reference model for Next Generation

Networks

[35] ITU-T Y.2021 - IMS for Next Generation Networks

[36] JCP JSR 151 - Java 2 Platform, Enterprise Edition 1.4 (J2EE 1.4) Specification

[37] JCP JSR 154 - Java Servlet 2.4 Specification

[38] JCP JSR 21 - JAIN Java Call Control (JCC) Specification

[39] JCP JSR 22 - JAIN Service Logic Execution Environment API Specification 1.0

[40] JCP JSR 240 - JAIN Service Logic Execution Environment API Specification 1.1

[41] Jesse James Garrett, "Ajax: A New Approach to Web Applications", adaptivepath.com,

Luty 2005

[42] Michał Giermasiński, Krzysztof Hennig - "Model implementacji usług

telekomunikacyjnych w hybrydowym środowisku mobilnym WLAN/GPRS",

Politechnika Warszawska, Wydział Elektroniki i Technik Informacyjnych, Warszawa

2004

[43] OASIS Web Services Security: SOAP Message Security 1.1 Specification, 1 Luty 2006

[44] Parlay Group - "Web Services Working Group, Parlay Web Services – Business

Models", Październik 2002

[45] Rajesh Sumra - "Quality of Service for Web Services - Demystification, Limitations,

and Best Practices"

[46] W3C CSS2 - Cascading Style Sheets, level 2 Specification

[47] W3C SOAP Version 1.2 Part 1: Messaging Framework Specification

[48] W3C Web Services Description Language (WSDL) 1.1 Specification

[49] W3C XHTML 1.0 The Extensible HyperText Markup Language Specification

[50] Zygmunt Lozinski - "Parlay/OSA and the Intelligent Network", Pralay Group, Luty

2005

źródła internetowe

[51] http://ajaxpatterns.org/HTTP_Streaming

[52] http://gcc.gnu.org/java/

Bibliografia

197

[53] http://java.sun.com/products/jsp/

[54] http://java.sun.com/products/servlet/

[55] http://www.extreme.indiana.edu/~aslom/exxp/ - "On Performance of Java XML Parsers

(with SOAP)"

[56] http://www.omg.org/technology/documents/spec_catalog.htm

[57] http://www.php.net/

[58] http://www.tinac.com/

[59] http://www.w3.org/CGI/

[60] http://wikipedia.org/

Wykaz stosowanych skrótów

198

14. Wykaz stosowanych skrótów

3GPP 3rd Generation Partnership Project 3PCC Third Party Call Controll AAA Authentication, Authorization, and Accounting AEG Application Expert Group AJAX Asynchronous JavaScript and XML AOR Address of Routing API Application Programming Interface AS Application Server ATM Asynchronous Transfer Mode B2BUA Back-to-Back User Agent BGCF Breakout Gateway Control Function CDR Charging Data Record CGI Common Gateway Interface CSCF Call/Session Control Function CSS Cascading Style Sheets DNS Domain Name System DOM Document Object Model EJB Enterprise Java Bean ETSI European Telecommunications Standards Institute FQDM Fully Qualified Domain Name FSF Free Software Foundation FSM Finite State Machine FTP File Transfer Protocol GGSN Gateway GPRS Support Node GPRS General Packet Radio Service GSM Global System for Mobile Communications GUI Graphical User Interface HLR Home Location Register HSDPA High-Speed Downlink Packet Access HSPA High Speed Packet Access HSS Home Subscriber Server HSUPA High Speed Uplink Packet Access HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol I-CSCF Interrogating-CSCF IETF Internet Engineering Task Force IFC Initial Filter Criteria IMS IP Multimedia Subsystem IN Intelligent Network IP Internet Protocol IP-CAN IP-Connectivity Access Network ISDN Integrated Services Digital Network ISUP ISDN User Part ITU International Telecommunication Union J2EE Java 2 Platform, Enterprise Edition JAIN Java APIs for Integrated Networks JAR Java Archive

Wykaz stosowanych skrótów

199

JAXP Java API for XML Processing JCAT JAIN Coordinations and Transactions JCC JAIN Call Control JCP Java Community Process JMS Java Message Service JMX Java Management Extensions JNDI Java Naming and Directory Interface JSCE JAIN Service Creation Environment JSLEE JAIN Service Logic Execution Environment JSR Java Specification Request MGCF Media Gateway Control Function MGW Media Gateway MMS Multimedia Messaging Service MRFC Multimedia Resource Function Controller MRFP Multimedia Resource Function Processor MSC Mobile Switching Center NAS Network Attachment Subsystem NGN Next Generation Network OCK Osobiste Centrum Komunikacji OSA Open Service Access OSI Open Source Initative PBX Private Branch Exchange P-CSCF Proxy-CSCF PDF Policy Decision Function PEAR PHP Extension and Application Repository PEG Protocol Expert Group PIDF Presence Information Data Format PRUI Private User Identifier PSTN Public Switched Telephone Network PUI Public User Identifier QoS Quality of Service RA Resource Adapter RACS Resorce and Admission Control Subsystem RFC Request For Comment RMI Remote Method Invocation RPIDF Rich Presence Information Data Format RTCP Real Time Control Protocol RTP Real-Time Transport Protocol R-URI Request-URI SBB Service Building Block SCIM Service Capability Interaction Module S-CSCF Serving-CSCF SCTP Stream Control Transmission Protocol SDL Specification and Description Language SDP Session Description Protocol SGW Signaling Gateway SIP Session Initiation Protocol SLF Subscriber Location Function SMS Short Message Service SOAP Simple Object Access Protocol SS7 Signaling System number 7

Wykaz stosowanych skrótów

200

TCP Transmission Control Protocol TLS Transport Layer Security UA User Agent UAS User Agent Server UDDI Universal Description, Discovery and Integration UDP User Datagram Protocol UML Unified Modeling Language UMTS Universal Mobile Telecommunications System URI Uniform Resource Identifier USIM Uniiversal Subscriber Identity Module VCC Voice Call Continuity VLR Visitor Location Register VoIP Voice over IP WSDL Web Service Definition Language XML Extesible Markup Language XMPP Extensible Messaging and Presence Protocol

201

Załącznik A: Definicje kryteriów filtracji IFC w HSS,

stosowane podczas analizy

1. Profil #1

Definiuje przekierowanie wiadomości PUBLISH i SUBSCRIBE dla zgłoszeń

przychodzących do zarejestrowanego i nie zarejestrowanego uŜytkownika, na adres serwera

obecności (sip:[email protected]:5063 i sip:[email protected]:5063).

<profile> <InitialFilterCriteria> <Priority>0</Priority> <SessionCase>1</SessionCase> <TriggerPoint> <ConditionTypeCNF>0</ConditionTypeCNF> <SPT> <ConditionNegated>0</ConditionNegated> <Group>0</Group> <Method>PUBLISH</Method> </SPT> </TriggerPoint> <TriggerPoint> <ConditionTypeCNF>0</ConditionTypeCNF> <SPT> <ConditionNegated>0</ConditionNegated> <Group>0</Group> <Method>SUBSCRIBE</Method> </SPT> </TriggerPoint> <ApplicationServer> <ServerName>sip:[email protected]:5063</ServerName> <DefaultHandling index="0">0</DefaultHandling> </ApplicationServer> </InitialFilterCriteria> <InitialFilterCriteria> <Priority>1</Priority> <SessionCase>2</SessionCase> <TriggerPoint> <ConditionTypeCNF>0</ConditionTypeCNF> <SPT> <ConditionNegated>0</ConditionNegated> <Group>0</Group> <Method>PUBLISH</Method> </SPT> </TriggerPoint> <TriggerPoint> <ConditionTypeCNF>0</ConditionTypeCNF> <SPT> <ConditionNegated>0</ConditionNegated> <Group>0</Group> <Method>SUBSCRIBE</Method> </SPT> </TriggerPoint>

202

<ApplicationServer> <ServerName>sip:[email protected]:5063</ServerName> <DefaultHandling index="0">0</DefaultHandling> </ApplicationServer> </InitialFilterCriteria> </profile>

2. Profil #2

Definiuje przekierowanie wiadomość INVITE dla zgłoszeń przychodzących do nie

zarejestrowanego uŜytkownika, na adres serwera implementującego interfejs Parlay X: Call

Handling (sip:[email protected]:5072).

<profile> <InitialFilterCriteria> <Priority>3</Priority> <SessionCase>2</SessionCase> <TriggerPoint> <ConditionTypeCNF>0</ConditionTypeCNF> <SPT> <ConditionNegated>0</ConditionNegated> <Group>0</Group> <Method>INVITE</Method> </SPT> </TriggerPoint> <ApplicationServer> <ServerName>sip:[email protected]:5072</ServerName> <DefaultHandling index="0">0</DefaultHandling> </ApplicationServer> </InitialFilterCriteria> </profile>

3. Profil #3

Definiuje przekierowanie wiadomość INVITE dla zgłoszeń przychodzących do

zarejestrowanego uŜytkownika, na adres serwera implementującego interfejs Parlay X: Call

Handling (sip:[email protected]:5072).

<profile> <InitialFilterCriteria> <Priority>3</Priority> <SessionCase>1</SessionCase> <TriggerPoint> <ConditionTypeCNF>0</ConditionTypeCNF> <SPT> <ConditionNegated>0</ConditionNegated> <Group>0</Group> <Method>INVITE</Method> </SPT> </TriggerPoint> <ApplicationServer> <ServerName>sip:[email protected]:5072</ServerName>

203

<DefaultHandling index="0">0</DefaultHandling> </ApplicationServer> </InitialFilterCriteria> </profile>

204

Załącznik B: Instrukcja uruchomienia serwerów CSCF i

HSS

Funkcje P-CSCF, S-CSCF i HSS są realizowane z wykorzystaniem dwóch instancji serwera

Open SER oraz bazy danych PostreSQL.

1. ZałoŜenia

Środowiskiem uruchomieniowy jest komputer z architekturą procesora zgodną z x86 i

system operacyjny GNU/Linux. Z hosta tego komputera jest osiągalna baza danych

PostgreSQL (lokalnie lub poprzez sieć). Wymagane oprogramowanie to: libc6 (wersja >=

2.5), libpg5, postgresql-client. UŜytkownik uruchamiający serwery powinien mieć

uprawnienia super-uŜytkownika (su).

W wybranym katalogu naleŜy umieści zawartość /oprogramowanie/ims z płyty

dołączonej do tego opracowania.

Tab. 11: Parametry wymagane do konfiguracji CSCF i HSS

zmienna opis PCSCF_IP Adres IP serwera P-CSCF, np. 127.0.0.1 PCSCF_PORT Port UDP dla protokołu SIP serwera P-CSCF, np. 5060 PCSCF_URI Adres SIP-URI serwera P-CSCF, np. sip:127.0.0.1:5060 SCSCF_IP Adres IP serwera S-CSCF, np. 127.0.0.1 SCSCF_PORT Port UDP dla protokołu SIP serwera S-CSCF, np. 5061 SCSCF_URI Adres SIP-URI serwera S-CSCF, np. sip:127.0.0.1:5061 ICSCF_URI Adres SIP-URI serwera I-CSCF, np. sip:127.0.0.1:5061 DOMAIN Domena dla konfigurowanej sieci SIP, np. eims.local HSS_IP Adres IP bazy PostgreSQL, np. 127.0.0.1 HSS_USER Nazwa uŜytkownika do bazy PostgreSQL HSS_PASS Hasło uŜytkownika do bazy PostgreSQL

2. Konfiguracja

1. NaleŜy zmodyfikować plik cscf/pcscf.cfg:

17: listen=udp:<PCSCF_IP>:<PCSCF_PORT>

44: modparam("ims", "hss_db_url", "postgres://<HSS_USER>:<HSS_PASS>@<HSS_IP>/hss")

91: rewriteuri("<ICSCF_URI>");

100: setdsturi("<SCSCF_URI>");

205

2. NaleŜy zmodyfikować plik cscf/scscf.cfg:

17: listen=udp:<PCSCF_IP>:<PCSCF_PORT>

49: modparam("ims", "hss_db_url", "postgres://<HSS_USER>:<HSS_PASS>@<HSS_IP>/hss ")

50: modparam("ims", "authorization_realm", "<DOMAIN>")

51: modparam("ims", "scscf_name", "<SCSCF_URI>")

52: modparam("auth_db", "db_url", "postgres://<HSS_USER>:<HSS_PASS>@<HSS_IP>/hss ")

100: if (uri=~"<ICSCF_URI>") {

3. NaleŜy utworzyć strukturę bazy danych w PostgeSQL wykorzystując skrypt hss.sql.

4. NaleŜy odpowiednio zmodyfikować dane w bazie, dodając uŜytkowników. Struktura

bazy przedstawiona jest na Rys. 102.

Rys. 102: Struktura danych w HSS

3. Uruchamianie serwerów

Aby wystartować serwery P-CSCF i S-CSCF naleŜy uruchomić skrypt run_cscf.sh.

#>./run_cscf.sh

206

Załącznik C: Instrukcja uruchomienia serwerów

implementujących Parlay X API

Serwery implementujące Parlay X API są realizowane z wykorzystaniem:

� samodzielnych serwerów, napisanych w języku JAVA

� serwera Apache Tomcat 5.0

� bazy danych PostreSQL

� serwera RMI (rmiregistry)

1. ZałoŜenia

Środowiskiem uruchomieniowy jest komputer, na którym jest zainstalowane

środowisko uruchomieniowe JRE 1.5 (Java Run time Environment) i skrypty java oraz

rmiregistry są dostępne poprzez zmienną $PATH. Z hosta tego komputera jest osiągalna baza

danych PostgreSQL (lokalnie lub poprzez sieć). Na komputerze jest zainstalowany serwer

Apache Tomcat 5.0

W wybranym katalogu naleŜy umieści zawartość /oprogramowanie/parlayx z płyty

dołączonej do tego opracowania.

Tab. 12: Parametry wymagane do konfiguracji serwerów Parlay X

zmienna opis SCSCF_IP Adres IP serwera S-CSCF, np. 127.0.0.1 SCSCF_PORT Port UDP dla protokołu SIP serwera S-CSCF, np. 5061 3PCC_IP Adres IP serwera implementującego interfejs Third Party Call, np. 127.0.0.1 3PCC_PORT Port UDP dla protokołu SIP serwera implementującego interfejs Third Party

Call, np. 5074 CH_IP Adres IP serwera implementującego interfejs Call Handling, np. 127.0.0.1 CH_PORT Port UDP dla protokołu SIP serwera implementującego interfejs Call

Handling, np. 5072 TS_IP Adres IP serwera implementującego interfejs Terminal Status, np. 127.0.0.1 TS_PORT Port UDP dla protokołu SIP serwera implementującego interfejs Terminal

Status, np. 5073 PR_IP Adres IP serwera implementującego interfejs Presence, np. 127.0.0.1 PR_PORT Port UDP dla protokołu SIP serwera implementującego interfejs Presence,

np. 5070 HSS_IP Adres IP bazy PostgreSQL, np. 127.0.0.1 HSS_USER Nazwa uŜytkownika do bazy PostgreSQL HSS_PASS Hasło uŜytkownika do bazy PostgreSQL

207

2. Konfiguracja

1. Zawartość katalogu tomcat-shared naleŜy umieścić katalogu shared serwera Tomcat

2. Przy pomocy narzędzie manager naleŜy zainstalować na serwerze Tomcat aplikacje

axis2.war

3. Przy pomocy narzędzia axis2-admin (http://<TOMCAT>/axis2/axis2-admin)205 naleŜy

zainstalować usługi sieciowe: ThirdPartyCallService.aar, CallHandlingService.aar,

TerminalStatusService.aar, GroupManagementService.aar, GroupService.aar,

PresenceConsumerService.aar, PresenceSupplierService.aar

4. NaleŜy zmodyfikować plik parlayx/thirdpartycall_controller_config.xml:

<entry key="javax.sip.IP_ADDRESS"><3PCC_IP></entry>

<entry key="javax.sip.OUTBOUND_PROXY"><SCSCF_IP>:<SCSCF_PORT>/UDP</entry>

<entry key="org.eims.SIP_PORT"><3PCC_PORT></entry>

5. NaleŜy zmodyfikować plik parlayx/callhandling_controller_config.xml:

<entry key="javax.sip.IP_ADDRESS"><CH_IP></entry>

<entry key="javax.sip.OUTBOUND_PROXY"><SCSCF_IP>:<SCSCF_PORT>/UDP</entry>

<entry key="org.eims.SIP_PORT"><CH_PORT></entry>

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

<entry key="javax.sip.IP_ADDRESS"><TS_IP></entry>

<entry key="javax.sip.OUTBOUND_PROXY"><SCSCF_IP>:<SCSCF_PORT>/UDP</entry>

<entry key="org.eims.SIP_PORT"><TS_PORT></entry>

7. NaleŜy zmodyfikować plik parlayx/addresslistmanagement_controller_config.xml:

<entry key="org.eims.HSS_URL">jdbc:postgresql://<HSS_IP>/hss</entry>

<entry key="org.eims.HSS_USER"><HSS_USER></entry>

<entry key="org.eims.HSS_PASSWORD"><HSS_PASS></entry>

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

<entry key="javax.sip.IP_ADDRESS"><PR_IP></entry>

<entry key="javax.sip.OUTBOUND_PROXY"><SCSCF_IP>:<SCSCF_PORT>/UDP</entry>

<entry key="org.eims.SIP_PORT"><PR_PORT></entry>

205 UŜytkownik „admin”, hasło „axis2”

208

3. Uruchamianie serwerów

Aby wystartować serwery implementujące interfejsy Parlay X naleŜy uruchomić skrypt

run_parlayx.sh.

#>./run_parlayx.sh

209

Załącznik C: Instrukcja uruchomienia serwera

obecności

Serwer obecności jest samodzielną aplikacją napisaną w języku JAVA. Szczegółowa

procedura konfiguracji i instalacji zawarta jest w [42].

1. ZałoŜenia

Środowiskiem uruchomieniowy jest komputer, na którym jest zainstalowane

środowisko uruchomieniowe JRE 1.5 (Java Run time Environment) i skrypty java jest

dostępny poprzez zmienną $PATH.

W wybranym katalogu naleŜy umieści zawartość /oprogramowanie/ps z płyty

dołączonej do tego opracowania.

Tab. 13: Parametry wymagane do konfiguracji serwera obecności

zmienna opis PS_IP Adres IP serwera obecności, np. 127.0.0.1 PS_PORT Port UDP dla protokołu SIP serwera obecności, np. 5061 DBS_IP Adres IP serwera bazodanowego dla serwera obecności, np. 127.0.0.1 DBS_PORT Port na którym nasłuchuje serwer bazodanowy, np. 8100

2. Konfiguracja

1. NaleŜy zmodyfikować plik ps/databaseserver/dbs.cfg:

DBS_PORT=<DBS_PORT>

2. NaleŜy zmodyfikować plik ps/presenceserver/ps.cfg:

javax.sip.IP_ADDRESS=<PS_IP>

PRES_PORT=<PS_PORT>

PRES_DBS_ADDRESS=<DBS_IP>

PRES_DBS_PORT=<DBS_PORT>

3. Uruchamianie serwera

Aby wystartować serwer obecności naleŜy uruchomić skrypt run_ps.sh.

#>./run_ps.sh

210

Załącznik D: Instrukcja instalacji aplikacji Centrum

Komunikacji Osobistej

1. ZałoŜenia

Środowiskiem wykonawczym dla aplikacji Centrum Komunikacji Osobistej jest serwer

WWW (np. Apache). Serwer WWW musi mieć zainstalowany moduł dla języka PHP w

wersji 5.0 oraz dodatkową biblioteką PEAR/SOAP 0.9.1. Po stronie klienta wymagane jest,

aby przeglądarka obsługiwała język Java Script 1.2 oraz pozwalała na stronie obiektu

XMLHttpRequest .

Zbiór plików wymienionych w Tab. 14 powinien zostać umieszczony w katalogu

htdocs serwera WWW.

Tab. 14: Wykaz plików wchodzących w skład aplikacji CKO

Plik Katalog Opis center.php /ajax Szkielet strony index.php /ajax Pierwsza strona z oknem do logowania logic.js /ajax Zawiera zestaw funkcji dla AJAX szablon.css /ajax Zawiera zbiór stylów callhandling.php / Obsługa zapytań Web Services i logika usługi

Call Handling groups.php / Obsługa zapytań Web Services i logika usługi

List and Group Management makeCallFeatures.php / Prezentacja modułu 3PCC makeCall.php / Obsługa zapytań Web Services i logika usługi

3PCC setPresence.php / Obsługa zapytań Web Services i logika usługi

Presence dla w danej chwili zalogowanego uŜytkownika CKO

terminalstatus.php / Obsługa zapytań Web Services dla usługi Terminal Status

2. Konfiguracja

NaleŜy zainstalować jedynie wymagane oprogramowanie wskazane powyŜej w

załoŜeniach.

211

3. Uruchamianie serwera

Aplikacja zostaje uruchomiona w momencie wystartowania serwera WWW.

212

Załącznik E: Konfiguracja i uruchomienie bramy

medialnej

Funkcjonalność bramy medialnej realizuje centralka IP PBX ASTERISK. Centralka jest

zainstalowana na serwerze wyposaŜonym w karty TDM z interfejsami E1 obsługującymi

sygnalizację DSS1.

1. ZałoŜenia

Asterisk moŜe zostać zainstalowany na dowolnej dystrybucji Linux. Na potrzeby

środowiska badawczego wykorzystano dystrybucję Linux Debian. System operacyjny

powinien zawierać następujące pakiety:

1. Jądro Linux w wersji 2.4 lub w wersji 2.6

2. Pakiet bison i bison-devel (wymagane do kompilacji Asterisk)

3. Pakiety zlib i zlib-devel

4. Pakiety openssl i openssl-devel

Oprócz kodów źródłowych centralki Asterisk wymagane są libpri oraz zaptel. Kod

źródłowy moŜe zostać pobrany bezpośrednio ze strony www.asterisk.org lub serwera CVS.

PoniŜej podane są instrukcje potrzebne do ściągnięcia wymaganych plików z serwera CVS

dla wersji stabilnej Asterisk 1.2.0.

# cvs checkout -r v1-2-0 zaptel libpri asterisk

W celu kompilacji i instalacji Asterisk naleŜy wykonać poniŜej wylistowane komendy.

NaleŜy zachować kolejność instalacji: libpri, zaptel, asterisk

� Instalacja libpri

#cd /usr/src/asterisk/libpri

#make clean

#make

#make install

� Instalacja zaptel

#cd /usr/src/asterisk/zaptel

213

#make clean

#make install

Uwaga: W przypadku jądra 2.6 naleŜy wykonać następujące polecenie '#make linux26',

przed komendą '#make install'.

� Instalacja asterisk

#cd /usr/src/asterisk/asterisk

#make clean

#make install

� Instalacja standardowej konfiugracji Asterisk

#make samples

2. Konfiguracja

W przypadku, gdy została zainstalowana podstawowa konfiguracja Asterisk wystarczy w

pliku extension.conf dodać następujący wpis. NaleŜy zaznaczyć, iŜ jest to najprostsza

konfiguracja, która pozwala na wykonywanie połączeń bez autoryzacji.

exten => _0XXXXXX,4,Dial(ZAP/${ZAP_MAIN_GROUP}/${EXTEN:1})

exten => _0XXXXXX,5,hangup()

W przypadku podłączenia Asterisk do centrali telefonicznej bazowa konfiguracja

modułu obsługującego kartę TDM powinna wyglądać następująco:

� Plik zapata.conf

group=3

signalling=pri_cpe

channel => 1-15,17-31

3. Uruchamianie Asterisk

Asterisk moŜna uruchomić wpisując następującą komendę:

/etc/init.d/asterisk start

214

W celu zarządzania centralką naleŜy podłączyć się do uruchomionego demona w

następujący sposób:

asterisk vvvvvc