Modele implementacji usług w architekturze IMS

POLITECHNIKA WARSZAWSKA

Rok akademicki

Wydział Elektroniki i Technik Informacyjnych

2006/2007

Instytut Telekomunikacji

PRACA DYPLOMOWA MAGISTERSKA

Michał Jan Kościesza

Michał Daniel Misiak

Modele implementacji usług w architekturze IMS

Praca wykonana pod kierunkiem

dra inż. Marka Średniawy

………………………..

ocena pracy

………………………..

podpis Przewodniczącego Komisji

Warszawa, 2007 r.

„Models of service implementation in the IMS architecture”

Abstract

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

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

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

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

opportunities, which require suitable software development models and technologies.

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

applications that operate across different telecommunication networks. APIs contain abstract

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

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

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

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

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

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

server.

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

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

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

divided into 3 areas:

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

specified application server based on subscriber profile.

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

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

user service with rich “contacts management” functionality .

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

applications

multi-layered,

real-time

and

asynchronous

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

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

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

2.1

STĘP

....................................................................................................................................... 15

2.2

UDOWA PROTOKOŁU ORAZ MODEL SESJI

................................................................................. 15

2.3

IERUNKI ROZWOJU I ROLA

SIP

IMS..................................................................................... 19

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

3.1

STĘP

....................................................................................................................................... 23

3.2

IMS

JAKO RDZENIOWA CZĘŚĆ ARCHITEKTURY

NGN ................................................................ 24

3.3

RCHITEKTURA

IMS................................................................................................................. 27

3.4

ROFIL UśYTKOWNIKA

.............................................................................................................. 33

3.5

ODEL STEROWANIA USŁUGAMI

............................................................................................... 35

3.6

ROCES NAWIĄZYWANIA SESJI

.................................................................................................. 38

3.7

IERUNKI ROZWOJU

.................................................................................................................. 38

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

4.1

ENEZA

ARLAY

/OSA.............................................................................................................. 42

4.2

PIS

ARLAY

/OSA ................................................................................................................... 43

4.3

RCHITEKTURA

ARLAY

/OSA.................................................................................................. 44

4.4

GRANICZENIA

ARLAY

/OSA .................................................................................................. 46

4.5

ARLAY

ERVICES

)........................................................................................ 46

4.6

ODELE BIZNESOWE

................................................................................................................. 47

4.7

UNKCJONALNOŚĆ

ARLAY

API ........................................................................................... 48

4.8

RCHITEKTURA

ARLAY

X......................................................................................................... 50

4.9

GRANICZENIA

ARLAY

X........................................................................................................ 54

4.10

EZPIECZEŃSTWO

ARLAY

X.................................................................................................... 55

4.11

IEJSCE

ARLAY

/OSA

ARLAY

W ARCHITEKTURZE

IMS ................................................... 57

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

5.1

NICJATYWA

JAIN..................................................................................................................... 60

5.2

EFINICJA

JSLEE,

WYMAGANIA DLA

JSLEE ............................................................................ 62

5.3

ORÓWNANIE TECHNIK

J2EE

JSLEE ...................................................................................... 64

5.4

ORÓWNANIE TECHNIK

JSLEE

SIP

ERVLET

....................................................................... 67

5.5

RCHITEKTURA

JSLEE............................................................................................................. 71

Spis Treści

5.6

RZYKŁADOWA USŁUGA

–

LOKOWANIE POŁĄCZEŃ

................................................................ 83

ROLA

WOLNEGO

OPROGRAMOWANIA

TWORZENIU

USŁUG

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

6.1

STĘP

....................................................................................................................................... 87

6.2

INUX W ZASTOSOWANIACH TELEKOMUNIKACYJNYCH

............................................................ 88

6.3

PEN

OURCE

JSLEE

–

OBICENTS

......................................................................................... 89

6.4

PEN

SIP

XPRESS

OUTER

...................................................................................................... 90

6.5

STERISK

.................................................................................................................................. 92

6.6

PEN

IMS

ORE

....................................................................................................................... 96

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

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

IMPLEMENTACJA

ANALIZA

MODELU

STEROWANIA

USŁUGAMI

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

9.1

PIS ZAIMPLEMENTOWANYCH MECHANIZMÓW

....................................................................... 108

9.2

ROCEDURA WSTAWIENIA INFORMACJI O IDENTYFIKACJI UśYTKOWNIKA

SSERT

DENTITY

) . 108

9.3

ROCEDURA PRZYDZIELENIA SERWERA

S-CSCF

PODCZAS PIERWSZEJ REJESTRACJI AGENTA

UśYTKOWNIKA

SER

-R

EGISTRATION

-Q

UERY

) ........................................................................ 110

9.4

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

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

9.5

ODEL STEROWANIA USŁUGAMI Z WYKORZYSTANIEM FEDERACJI SERWERÓW APLIKACYJNYCH

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

9.6

NTERAKCJE POMIĘDZY USŁUGAMI I SERWERAMI APLIKACYJNYMI

......................................... 133

10.

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

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

10.1

TEROWANIE ZESTAWIANIEM POŁĄCZEŃ PRZEZ TRZECIĄ STRONĘ

(

INTERFEJS

HIRD

ARTY

ALL

)

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

10.2

BSŁUGA POŁĄCZEŃ

(

INTERFEJS

ALL

ANDLING

)................................................................ 152

10.3

NFORMACJA O STATUSIE TERMINALA

(

INTERFEJS

ERMINAL

TATUS

)..................................... 160

10.4

ARZĄDZANIE LISTĄ KONTAKTÓW

(

INTERFEJS

DDRESS

IST

ANAGEMENT

) ......................... 164

10.5

NFORMACJA O STATUSIE OBECNOŚCI

(

INTERFEJS

RESENCE

) ................................................. 167

11.

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

11.1

AŁOśENIA PROJEKTOWE DLA APLIKACJI

................................................................................ 174

11.2

RCHITEKTURA APLIKACJI

...................................................................................................... 175

11.3

ROCES TWORZENIA APLIKACJI Z WYKORZYSTANIEM

ARLAY

X ........................................... 178

11.4

OMPONENTY APLIKACJI

........................................................................................................ 179

11.5

GRANICZENIA I PROPOZYCJE ICH ROZWIĄZANIA

................................................................... 186

12.

PODSUMOWANIE ....................................................................................................................... 189

Spis Treści

13.

BIBLIOGRAFIA............................................................................................................................ 194

14.

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

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

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

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

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

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

ZAŁĄCZNIK C: INSTRUKCJA URUCHOMIENIA SERWERÓW IMPLEMENTUJĄ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 MEDIALNEJ...................... 212

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ług

. Pomimo

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

głosowej

, 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ów

, 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ą

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ę”.

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.

W IN ma miejsce odwrotna sytuacja. Aplikacja realizująca usługę jest wykonywana po stronie sieci.

Wstęp

o protokół IP. Model NGN

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 konwergentnych

. To środowisko dostarcza narzędzi

pozwalających przyspieszyć proces budowy nowych usług oraz obniżyć ich koszt

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ści

. 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

Patrz rozdział 3.

Usług, w których przenikają się różne formy komunikacji, jak np. głos, wideo, wiadomości natychmiastowe,

lub szeroko rozumiana obecność.

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.

Z ang. Presence

Wstęp

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

zaawansowanej

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ług

. 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 IN

. Ponadto środowisko Java oraz zastosowana koncepcja

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

implementacjami JSLEE

. 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 IMS

, środowisko

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

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.

Wymagającej dostępu do sieci na niższym poziomie abstrakcji.

Analogicznie jak J2EE w rozwiązaniach IT.

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.

Okazało się to niemożliwe w przypadku IN.

Implementacje pełnej architektury IMS w komercyjnych sieciach są bardzo nieliczne.

Integrated Development Environment.

Wstęp

Cele Pracy

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

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

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

możliwości optymalizacji.

Analiza dekompozycji warstwy aplikacyjnej IMS jako sposobu na optymalizacje

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

rodowisku dwuwarstwowym (warstwa komponentów aplikacyjnych i warstwa

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

przy takim podejściu.

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

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

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

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

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

Układ pracy

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

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

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

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

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

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

podstawą do analizy zagadnień poruszanych w tej pracy.

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

następująco:

1. Wstęp

Michał Misiak

Część I
2. Session Initiation Protocol

Michał Kościesza

3. IP Multimedia Subsystem

Michał Kościesza

4. Parlay/OSA oraz Parlay X

Michał Misiak

5. JAIN Service Logic Execution Environment

Michał Misiak

Rola

wolnego

oprogramowania

tworzeniu

usług

telekomunikacyjnych

6.1 Wstęp

Michał Misiak

Wstęp

6.2 Linux w zastosowaniach telekomunikacyjnych

Michał Misiak

6.3 Open Source JSLEE – Mobicents

Michał Misiak

6.4 Open SIP Express Router

Michał Kościesza

6.5 Asterisk

Michał Misiak

6.6 Open IMS Core

Michał Kościesza

Część II
7. Specyfikacja problemu i cele analizy

Michał Kościesza

8. Architektura środowiska badawczego

Michał Kościesza

Implementacja

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

Session Initiation Protocol

2.1

Wstęp

SIP jest protokołem warstwy aplikacyjnej umożliwiającym sterowanie procesem

zestawiania, modyfikacji oraz rozłączania sesji multimedialnych

[22]. SIP zapewnia takie

elementarne mechanizmy jak: lokalizacja terminala użytkownika

, 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.

sesja multimedialna może być przekazem wideo, audio, komunikatów tekstowych itd..

możliwość określenia adresu sieciowego terminala użytkownika.

Session Initiation Protocol

CANCEL – kończy proces nawiązywania sesji.

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

adresowana.

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.

Lokalizacja sieciowa to skojarzenie pomiędzy adresem IP a publicznym identyfikatorem użytkownika (np.

sip:ala@eims.local)

Session Initiation Protocol

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

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

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

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

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

to:

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

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

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

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

bą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

użytkownika Sip-URI (np. sip:ala@eims.local) a adresem sieciowym terminala

danego użytkownika.

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

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

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

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

faktycznego agenta użytkownika, który jest inicjatorem sesji

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

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

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

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

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

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

nawzajem swoje adresy IP.

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

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

o model negocjacji zdefiniowany w [23].

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

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

Session Initiation Protocol

2.3

Kierunki rozwoju i rola SIP w IMS

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

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

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

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 RFC

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:

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

Session Initiation Protocol

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

identyfikacji użytkowników sieci PSTN.

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

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

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

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

ISUP).

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

wykorzystywany do lokalizacji serwerów Proxy.

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

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

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

subskrybuje status obecności innego użytkownika.

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

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

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

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

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

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

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

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

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

zagwarantowania.

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

radiowym w IMS stosuje się kompresję.

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

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

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

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

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

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

Session Initiation Protocol

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

IMS.

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

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

IMS z siecią PSTN.

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

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

użytkownika jest serwer Proxy.

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

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

P-Charging-Function-Addresses,

P-Charging-Vector.

Przenoszą

informacje

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

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

połączenia (call transfer) i konferencja.

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

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

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

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

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

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

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

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

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

Session Initiation Protocol

INVITE

200 OK

ACK

180 Ringing

transmisja mediów

180 Trying

INVITE

200 OK

ACK

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 IMS

(na podstawie [6])

Jedną z podkreślanych cech protokołu SIP jest jego prostota

. 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.

Serwery pośredniczące zostały pominięte.

SIP rozumiany jako protokół zdefiniowany w RFC 3261, bez rozszerzeń.

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-Talk

). 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 dodanej

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.

Usługa

„Push-to-Talk”

zdefiniowana

jest

‘OMA,

Push

talk

Over

Cellular

v1.0’

(http://www.openmobilealliance.org/)

Usługi o wartości dodanej są to usługi, których funkcje wykraczają poza podstawową funkcje sieci, jaką jest

zestawienie połączenia pomiędzy dwoma użytkownikami.

IP Multimedia Subsystem

3.2

IMS jako rdzeniowa część architektury NGN

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

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

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

cechami sieci w architekturze NGN są:

komutacja pakietów;

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

funkcji związanych z usługami;

otwarte interfejsy;

zdolność do realizacji szerokiego zakresu usług;

szerokopasmowa transmisja z zaimplementowanymi mechanizmami QoS;

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

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

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

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

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

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

podzielić na:

IP Multimedia Subsystem

warstwę funkcji transportowych (Transfer Functions) – grupuje wszystkie

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

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

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

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

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

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

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

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

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

PPP) oraz przyznanie adresacji IP.

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

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

podsystemu jest emulacja PSTN/ISDN w sieci pakietowej.

podsystem IMS (Core IMS

) – jest odpowiedzialny za sterowanie połączeniami i

zgłoszeniami.

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

Sieć UMTS

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.

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.

Dokładnie sieć UMTS w architekturze, co najmniej 3GPP Release 5.

IP Multimedia Subsystem

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

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 3GPP

, 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.

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

IP Multimedia Subsystem

Rys. 8: Architektura IMS

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

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

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

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

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

do wyższych warstw stosu SS7 po sieci IP.

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

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

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

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

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

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

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

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

SGW.

IP Multimedia Subsystem

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

scenariusze usług

Element funkcjonalne architektury IMS to:

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

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

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

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

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

obsługi tj:

zgłoszenie może być skierowane do terminala innego użytkownika;

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

obsługiwany w obcej sieci;

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.

. I

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

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).

Applications

Gr Gc

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

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 QoS

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)

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

IP Multimedia Subsystem

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

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

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

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

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

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

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

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

RTP

Signalling Gateway (SGW)

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

sieci IP za pomocą protokołu SCTP

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)

. 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:

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);

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

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

RTP jest protokołem transportowym strumieni medialnych w sieci IP (RFC 3550).

Protokół SCTP zdefiniowany jest w RFC 2960.

MRFC i MRFP są jednymi z najmniej dokładnie zdefiniowanymi elementami IMS.

IP Multimedia Subsystem

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

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

S-CSCF

Application

Server

SIP leg #1

From: X
To: Y
Call-ID: Z

S-CSCF

Application

Server

SIP leg #1

From: X
To: Y
Call-ID: Z

S-CSCF

Application

Server

SIP leg #1

From: X
To: Y
Call-ID: Z

SIP leg #1

From: X
To: Y
Call-ID: Z

SIP leg #1

From: X
To: Y
Call-ID: Z

S-CSCF

Application

Server

SIP leg #2

From: P
To: Q
Call-ID: R

SIP leg #1

From: X
To: Y
Call-ID: Z

SIP leg #1

From: X
To: Y
Call-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

Struktura profilu jest definiowana przy pomocy języka UML

. 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.

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

IP Multimedia Subsystem

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

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

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

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

użytkowników.

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

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

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

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

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

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

mogą podlegać wszystkie nagłówki i pole SDP

, do którego także mogą być stosowane

wyrażenia regularne

(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-Schema

. 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

Protokół służący do opisu parametrów sesji.

Możliwości tworzenia kryteriów są elastyczne, przykładowo można zdefiniować taką regułę:

(Method=”INVITE” OR Method = ”MESSAGE” OR Method=”SUBSCRIBE”) AND (Method=”INVITE” OR
Method = ”MESSAGE” OR (NOT Header = ”from” Content =”ala@eims.local”)).

Powyższe wyrażenie opisuje regułę definiującą, że kierowane do AS będą wiadomości: INVITE, MESSAGE
oraz takie wiadomości SUBSCRIBE, które nie zostały wysłane przez użytkownika posługującego się
publicznym identyfikatorem ala@eims.local.

XML-Schema jest językiem opisu składni dokumentów XML (patrz http://www.w3.org/XML/Schema).

IP Multimedia Subsystem

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

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

w sieci.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2 fazy:

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

niezarejestrowanego użytkownika, wychodzące);

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

zgłoszenie.

IP Multimedia Subsystem

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

wykorzystywany mechanizm sterowania usługami.

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

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

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

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ą).

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

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

nie zarejestrowanego użytkownika).

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

realizuje usługę „przekierowania”).

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

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

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

IP Multimedia Subsystem

3.6

Proces nawiązywania sesji

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

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

użytkownikiem sieci PSTN.

Rys. 16: Nawiązywanie sesji w IMS

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

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

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

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

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

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

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

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

3.7

Kierunki rozwoju

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

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

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

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

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

IP Multimedia Subsystem

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

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

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

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

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

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

głosowych opartych o VoIP z wystarczającą jakością

. 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.

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

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. HSPA

). „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

HSDPA i HSUPA.

IP Multimedia Subsystem

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

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

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

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

sygnalizacji z IMS

, 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.

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

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 OFTEL

. 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. TINA

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.

Regulator rynku elektronicznego w Wielkiej Brytanii, odpowiednik polskiego Urzędu Komunikacji

Elektronicznej.

Telecommunication Information Networking Architecture. TINA była jedną z pierwszych prób zdefiniowania

architektury, która integrowała funkcje sterowania i zarządzania w jedną logiczną całość, a usługi miały być
tworzone z wykorzystaniem standardowych języków programowania. Szczegóły dotyczące tej inicjatywy
dostępne są pod adresem http://www.tinac.com/ [58].

Parlay/OSA oraz Parlay X

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

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

usług, sprzętu, treści. Efektem prac Parlay Group

była specyfikacja interfejsów

Parlay/OSA

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/aplikacji

, 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

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.

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.

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

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

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 CORBA

. 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

Common Object Request Broker Architecture – technika, która zapewnia komunikacje pomiędzy elementami

heterogenicznego środowiska komputerowego (patrz [56]).

Parlay/OSA oraz Parlay X

4.4

Ograniczenia Parlay/OSA

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

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

Vendor). Oto one:

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

sposób zabezpieczona;

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

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

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

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

Brama.

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

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

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

telekomunikacyjnej.

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

garden

”. Przejście do modeli np. „Enterprise Integration”, czy „Open Network”

, 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 back

oraz z sesji.

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.

Opis tych modeli znajduje się w [50].

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

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

wykorzystanie interfejsów Web Services

. 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

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

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

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

Kategoria

Nr. Usługa

Opis

Ogólne

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.

Third Party Call

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

Call Notification Pozwala określić, w jaki sposób zgłoszenie

zainicjowane z sieci powinno być traktowane.
Umożliwia prostą obsługę połączeń.

Call Handling

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

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

Multimedia
Conference

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

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

MMS

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

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

Account
management

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

Terminal status

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

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

Presence

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

Parlay/OSA oraz Parlay X

Rother

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

Interfejs

Aplikacyjny

Parlay X

Brama Parlay Web Services

Rejestr Usług Siecowych

Definicja Usługi Sieciowej

Serwer Aplikacyjny Parlay

Definicja Usługi Sieciowej

Aplikacje Parlay

Web Services Provider

Web 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ół SOAP

(Simple Object Application Protocol).

Wywołanie funkcji danego interfejsu tzw. żądanie usługi (service request) powoduje

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

wykonanie tej funkcji na zdalnym systemie, hostującym żądaną usługę. Usługa sieciowa

opisana jest przy użyciu języka WSDL

(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 UDDI

(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.

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].

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

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ą:

Dane biznesowe takie jak: nazwa, opis i informacje kontaktowe. Są to tzw.

„białe strony”.

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:

publikacja informacji o dostawcy usługi - stworzenie „białej strony”;

Parlay/OSA oraz Parlay X

publikowanie usługi – stworzenie „żółtej strony”, zadecydowanie do jakiej

kategorii powinna przynależeć usługa;

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:

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.

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:

W trakcie projektowania (at design time) – opis interfejsów usługi pobierany

jest w momencie tworzenia aplikacji.

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

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 XML

. 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

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

wcześniejsze skompilowanie kodu Javy

. 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 zabezpieczenie

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

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].

Rozwiązaniem jest użycie asynchronicznych kolejek wiadomości oraz niezawodnych protokołów

transportowych np. HTTPR, BEEP (patrz [45]).

Parlay/OSA oraz Parlay X

Węzeł prywatny UDDI może wykorzystywać podobny mechanizm jak węzeł

publiczny. Mechanizm ten jednak może zostać dodatkowo rozszerzony o konieczność

posiadania uprawnień w sieci, w której znajduje się węzeł.

Bezpieczeństwo w trakcie wyszukiwania usługi w węź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

odpowiedzialna

bezpieczeństwo powinna dokonać autoryzacji w każdej z bram.

Bezpieczeństwo danych

Bezpieczeństwo danych jest zapewnione przez protokół komunikacyjny WS-

Security

. 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ć

Web Service Security - Specyfikacja protokołu znajduje się w [43].

Parlay/OSA oraz Parlay X

użyty protokół HTTPS

albo TLS (Transaction Layer Security)

. 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ę

, 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).

HyperText Transfer Protocol Secure – wykorzystuje mechanizm SSL (Secure Socket Layer) do

zabezpieczenia danych na poziomie protokołu HTTP. Specyfikacja znajduje się w [31].

Patrz rozdział 1.

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

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

OSA

SCS

S-CSCF

HSS

Parlay X (Web Services)

Parlay/OSA API

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,

MSISDN

, 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]).

Mobile Subscriber ISDN – numer abonenta sieci komórkowej.

Parlay/OSA oraz Parlay X

W stworzonym środowisku badawczym zrezygnowano z implementacji interfejsów

Bramy Parlay X na OSA SCS, co jest powszechnie przyjęta praktyką w branży

telekomunikacyjnej. Interfejsy te zostały zaimplementowane jako odrębne serwery

aplikacyjne (patrz Rys. 41), a na styku ISC użyty został protokół SIP z dodatkowymi

nagłówkami, które wymagane są do spełniania założeń dla styku ISC zgodnie z TS 23.228 [4]

(patrz rozdział 1).

JAIN Service Logic Execution Environment

5.1

Inicjatywa JAIN

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 Process

powołał program JAIN

. 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,

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.

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).

W ramach JAIN istnieją 2 grupy eksperckie: Application Expert Group (AEG) oraz Protocol Expert Group

(PEG). PEG przygotowuje standardy na poziomie protokołów sygnalizacyjnych w sieciach IP, stacjonarnych i
mobilnych. AEG zajmuje się problemem bezpiecznego dostępu do sieci operatora (JAIN Parlay), specyfikuje
model zarządzaniem połączeniami (JCC, JCAT) oraz środowisko do kreacji usług.

JAIN Service Logic Execution Environment

GSM, etc..). Model zgłoszenia reprezentuje maszynę stanów, do której dostęp realizowany

jest przez JCC/JCAT API. Przy tworzeniu aplikacji na tym poziomie programista nie musi

znać szczegółów odnoszących się do poszczególnych sieci, gdyż korzysta z generycznych

funkcji tj. jak wysłanie wiadomości, zestawienie połączenia, etc..

W centrum architektury JAIN znajduje się środowisko wykonawcze dla usług tzw.

Service Logic Execution Environment. SLEE definiuje jednakowy model programistyczny dla

aplikacji sterowanych zdarzeniami oraz kontener, który oferuje szereg standardowych

funkcjonalności (mechanizm transakcji, mechanizm kierowania zdarzeń, zarządzania

aplikacją, etc..). Dzięki temu programista może skupić się wyłączenie na implementacji logiki

aplikacji. Szczegółowa analiza tego środowiska zostanie popełniona w dalszej części tej

pracy.

JAIN Service Logic Exectuion Environment

(JSLEE)

JAIN Call Control (JCC)

and JAIN Coordination and Transactions (JCAT)

TCAP

ISUP

INAP

SIP

MAP

Security Interface

JAIN 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

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 kontenerem

, 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 Block

JSLEE wykorzystuje język Java, który zapewnia przenośność i obiektowość aplikacji.

Główne koncepcje wykorzystane przy projektowaniu kontenera JSLEE bazują na specyfikacji

J2EE

, a jako przykład może posłużyć użyta technika JMX

(Java Management Extension)

do zarządzania kontenerem. Poza tym JSLEE wspiera także inne interfejsy Javy m. in. J2SE,

JNDI, JAXP

, 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.

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.

Szczegółowy SBB opis zostanie podany w rozdziale5.5.5.

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].

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.

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

Asynchroniczność, przetwarzanie zorientowane na zdarzenia. Komponenty

rejestrują się poprzez mechanizm publish/subscribe

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

JSLEE

mogą znacząco się różnić pomiędzy sobą w zakresie wydajności oraz sposobie

działania poszczególnych mechanizmów.

Mechanizm publish/subscribe zaprojektowany został do realizacji komunikacji asynchronicznej. Nie należy go

mylić z mechanizmem komunikacji asynchronicznej lister/provider wykorzystywanym w Javie.

Istniejące implementacje referencyjne JSLEE zostaną omówione w rozdziale 1.

JAIN Service Logic Execution Environment

5.3

Porównanie technik J2EE i JSLEE

JSLEE czerpie z rozwiązań stworzonych dla J2EE. Jako przykład można podać kilka

analogii w obydwu architekturach. W jednym i w drugim rozwiązaniu jest to architektura

komponentowa. W J2EE komponenty nazywają się Enterprise Java Beans

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

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

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

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

cze

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)

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

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

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”

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ść

) 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 webowymi

w języku Java i wykonywane są poprzez serwer aplikacji w specjalnie do tego

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..).

Atomizm, spójność, izolacja, trwałość tzw. ACID: Atomicity, Consistency, Isolation, Durability są

podstawowymi cechami, którymi musi się charakteryzować transakcja.

Aplikacje webowe rozumiane są szeroko, tzn. nie tylko jako programy do generowania stron HTML.

JAIN Service Logic Execution Environment

przeznaczonym kontenerze. Zostały zdefiniowane przez Java Community Process w

specyfikacji JSR 154 [37] na potrzeby platformy J2EE.

Zasada działania oraz struktura klas servletów została przedstawiona na Rys. 25.

Komunikacja z servletem, ze względu na jego pierwotne przeznaczanie

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ć aplikacje

. Jednak kontener dla Servletów posiada szereg

ograniczeń, które uniemożliwiają spełnienie kilku istotnych założeń koniecznych do

Technika servletów zostały pierwotnie stworzona na potrzeby budowania dynamicznie generowanych stron

HTML.

W specyfikacji SIP Servlet można przeczytać „Emphasis is on simplicity and minimality rather than

completeness”.

JAIN Service Logic Execution Environment

tworzenia zawansowanych aplikacji telekomunikacyjnych. Ograniczenia te zostaną

omówione w następujących kategoriach:

Architektura aplikacji. Servlety wykorzystywane są do prostych zadań. Brak w tym

przypadku modularyzacji na poziomie funkcjonalnym. W JSLEE takimi modułami

są SBB. Servlety w swoim założeniu przeznaczone są do obsługi konkretnego

protokołu. Jeśli chcielibyśmy obsłużyć jednocześnie inny protokół musielibyśmy

dziedziczyć po innej klasie, a że w Java nie zapewnia wielokrotnego dziedziczenia,

tak więc można wykorzystać tylko jeden protokół w ramach konkretnego servletu.

Stanowość aplikacji. Servlety zostały zaprojektowane głównie do obsługi protokołu

HTTP, który jest z zasady protokołem bezstanowym. Utrzymanie stanu w servletach

wiąże się z przechowywaniem informacji o nim w ramach sesji jako para ciąg

znaków-obiekt. Komponenty SSB w JSLEE mogą być zarówno stanowe jak i

bezstanowe. Stan ich utrzymywany jest w ramach transakcji, co gwarantuje

bezpieczeństwo powrócenia do ostatniego poprawnego stanu w przypadku

wystąpienia jakiegokolwiek błędu.

Sterowanie dostępem do zasobów (problem hazardu). W Servletach brak jest

mechanizmu transakcji. Ażeby uniknąć efektu hazardu należy korzystać z

mechanizmu monitorów. JSLEE oferuje standardowo transakcje, które izolują

poszczególne procesy.

Funkcjonalność dostępna dla aplikacji. JSLEE oferuje znaczenie szerszy zbiór

funkcjonalności przydatnych w tworzeniu aplikacji telekomunikacyjnych (patrz

5.5.2).

Zarządzanie. W Servletach brakuje mechanizmu do zarządzania. JSLEE oferuje

zestandaryzowany mechanizm JMX, udostępniając szereg interfejsów, które

pozwalają zrządzać aplikacją, cyklem życia, etc..

Tab. 3: Porównanie technik JAIN SLEE i SIP Servlet.

SIP Servlety

JAIN SLEE

Architektura aplikacji

Bazuje na Servletach HTTP;

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

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

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

Interfejsy do zarządzania

usługami oraz SLEE

JAIN SLEE

Agent JMX

Kontener

Service

Building

Blocks

Service

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

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, JSP

). 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;

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

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

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

Rys. 27: Mechanizm przekazywania zdarzeń w JSLEE - router zdarzeń

5.5.3

Model Komponentowy w architekturze JSLEE

Model komponentowy określa budowę zorientowanych zdarzeniowo aplikacji jak zbiór

komponentów, jak i również interakcje pomiędzy komponentami oraz pomiędzy

komponentami, a kontenerem.

Aplikacje JSLEE składają się z:

Service Building Blocks (SBB);

Zdarzeń (Events) oraz typów zdarzeń (Event Type);

Activity, Activity Object i Activity Context;

Profili (Profiles), Tabeli Profili (Profile Table) i specyfikacji profili (Profile

Specyfication).

Model komponentowy opisuje również sposób konfiguracji aplikacji po przez tzw.

Deyployment Descriptor. Na Rys. 28 przedstawiono zależności pomiędzy poszczególnymi

elementami modelu komponentowego.

Rys. 28: Główne elementy JSLEE i powiązania pomiędzy nimi

JAIN Service Logic Execution Environment

5.5.4

Service Building Block - SSB

SBB, czyli Service Building Block jest podstawowym komponentem, który zwiera cześć

logiki aplikacji. Jest bardzo podobny do Enterprise Java Beans (EJBs) m. in. ze względu na

cykl życiowy usługi, który kontrolowany jest przez środowisko wykonawcze. Środowisko

wykonawcze, a więc kontener zarządza przetwarzaniem zdarzeń i zapewnia poprawność tego

procesu używając mechanizmu transakcji.

Rys. 29: Budowa Service Building Block (SBB). Wymagane interfejsy klasy abstrakcyjnej

Klasa abstrakcyjna SBB, która została przedstawiona poglądowo na Rys. 29 musi

definiować następujące elementy:

typy odbieranych i generowanych zdarzeń po przez SBB;

handlers, czyli funkcje, które są wołane do obsługi przychodzących zdarzeń;

funkcje lokalne interfejsu SBB;

graf SBB oraz drzewo instancji SBB;

wspólne dane, czyli profile.

5.5.5

Drzewo SBB

Każda usługa składa się z jednego lub więcej instancji SBB różnych typów i może

zostać przedstawiona jako drzewo. Jednostki SBB (SBB Entity) są instancjami komponentów

SBB. Oczywiście każde SBB może być wielokrotnie wykorzystane w innych usługach.

Poszczególne SBB są węzłami w drzewie (patrz Rys. 30), a pomiędzy nimi znajduje się

krawę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

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(...)

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

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 (Call

) 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.

Obiekt Call pochodzi ze specyfikacji JAIN API.

JAIN Service Logic Execution Environment

JSLEE oferuje dla Komponentów mechanizm publish/subscribe. Komponenty mogą się

rejestrować przy pomocy tego mechanizmu w Activity Context, w celu odbierania

interesujących je zdarzeń. Należy w tym miejscu zauważyć, że mechanizm publish/subcribe

różni się od mechanizmu listner/provider udostępnianego w języku Java. W mechanizmie

listener/provider strony, które są wzajemnie zainteresowane odbieraniem i generowaniem

zdarzeń znają się, ponieważ Listner musi zarejestrować się u konkretnego Providera. W

JSLEE komponent generujący zdarzenia i komponent nasłuchujący przychodzących zdarzeń

nie znają się wzajemnie. Każdy z nich rejestruje się w Activity Context deklarując jedynie

chęć odbierania konkretnego typu zdarzeń. Dzięki opisanemu mechanizmowi swobodnego

wiązania dwóch komponentów za pomocą zdarzeń istnie możliwość tworzenia systemów

rozproszonych zorientowanych zdarzeniowo.

Rys. 32: Activity Context i Activity. Zależności u umiejscowienie w architekturze JSLEE

Na Rys. 33 została zaprezentowana przykładowa ścieżka jaką przebywa zdarzenie w

architekturze JSLEE przy zestawianiu sesji komunikacyjnej SIP.

Wiadomość INVITE zostaje wygenerowana przez sieć i następnie zostaje

przechwycona przez SIP-Resource Adapter (SIP-RA). Ponieważ INVITE jest pierwszą

wiadomością w sekwencji zestawiania połączenia dla protokołu SIP, zostaje wytworzony

Activity Obiekt przez SIP-RA. SIP-RA przekazuje dalej zdarzenie związane z wiadomością

INVITE do routera zdarzeń. Router zdarzeń powołuje do życia Activity Context ze względu

na to, że jest pierwszy we wspomnianej sekwencji. Zdarzenie zostaje odebrane przez

zainteresowany nim SBB, który wcześniej zarejestrował się przy wykorzystaniu

ActivityContextInterface

w Activity Context. SBB przetwarza zdarzenie zgodnie z

zaimplementowaną logiką, a następnie woła metodę SIP-RA z parametrem będącym

zdarzeniem-odpowiedzią. SIP-RA generuje następnie wiadomość „OK” do sieci.

JAIN Service Logic Execution Environment

Rys. 33: Przykładowa droga zdarzenia w JSLEE

5.5.7

Zdarzenia

Pojęcie zdarzenia jest jednym z istotniejszych w architekturze SLEE. Zdarzenie to

obiekt, który przenosi pewną informację z jednego elementu do innego znajdującego się w

SLEE. Jednym elementem, który może zarówno generować jak i odpowiadać na zdarzenia

jest SBB, pozostałe komponenty jak Facility, Resource Adapters generują jedynie zdarzenia.

Każde zdarzenie jest reprezentowane przez Event Object - obiekt w znaczeniu języka

Java i posiada określony typ. Typ determinuje sposób przekazywania zdarzenia. SBB

rejestrują typy zdarzeń, którymi są zainteresowane po przez podłączenie się do

odpowiedniego Activity Context.

Zdarzenia są odbierane przez SBB i uruchomiają odpowiednie funkcje tzw. Handlers.

5.5.8

Profile, Tabele Profili i Specyfikacje Profili

Profile (Profile) udostępniają dane przechowywane w postaci atrybutów. W schemacie

profili określa się zbiór atrybutów i ich typy. Tabele Profili (Profile Table) natomiast

zawierają profile, które przynależą do tego samego schematu. Specyfikacje Profili (Profile

Specification) definiują Interfejsy, zbiory klas i deskryptory rozmieszczenia (Deployment

Descriptors). Specyfikacje Profili można określić jako typy, które mogą być wykorzystywane

przez wiele Tabeli Profili.

JAIN Service Logic Execution Environment

W JSLEE został już zdefiniowany zbiór bazowych specyfikacji profili. Przykładową

specyfikacją profilu jest np.: „Resource Info Profile Specification“.

Eys. 34: Zależności pomiędzy Specyfikacjami Profili, Tablicami Profili i Profilami

5.5.9

Resource Adapters

Resource Adapters (RAs) jest kolejną koncepcją, która podobnie jak zdarzenia,

uniezależnia SLEE od konkretnego protokołu sygnalizacyjnego, zbioru danych, urządzenia.

JSLEE może dysponować dowolną liczbą RA i to jest istotna zaleta. Jeśli wystąpi potrzeba,

ażeby JSLEE komunikował się z inną siecią należy dopisać i zainstalować odpowiedni RA.

RAs konwertują specyficzne dla danego ź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

5.5.10

Opis konfiguracji usługi (Deploymnet Descriptor)

Każda usługa w JSLEE musi zostać opisana przez deskryptor (Deployment

Descriptor

,), 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 generowania

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:

service-xml.xml;

deployable-unit.xml;

archiwów JAR.

Dokument service-xml.xml posiada element, który jest korzeniem dokumentu XML

(

<service-xml>

) oraz zawiera Description-Element (

) i inne Service-

Eelments (

). Service-Element opisuje poszczególne usługi. Np. dla usługi

CallBlockingAndCallForwarding

Service-Elements

są

usługi

CallBlocking

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.

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.

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

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 X

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.

Implementacja dokonana na przykładzie zaczerpniętym z [14].

JAIN Service Logic Execution Environment

Metoda

onCallDeliveryEvent

sprawdza, czy zdarzenie reprezentuje przychodzące

zgłoszenie (filtruje zdarzenia na podstawie typu wiadomości i wybiera jedynie wiadomości

INVITE). W przypadku zdarzenia zawierającego inną wiadomości SIP niż INVITE metoda

natychmiast kończy swoje działanie, gdyż blokowane ma być jedynie połączenie

przychodzące. Realizowane jest to po przez porównanie URI ź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

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

String address = connection.getAddress().getName();

JccAddress source = connection.getOriginatingAddress();

if (source != null && source.getName().equals(address)){

return;

}

// Czytanie numerów dla usługi callblocking z profli

ProfileID id = profileFacility.getProfileID( ... )

CallBlockingAddressProfileCMP profile = getProfile(id);

Address[] blocked = profile.getBlockedAddresses();

// Sprawdzenie listy numerów i ewentualne zablkowanie zgłoszzenia.

Boolean block = false;

for (int i = 0; i < blocked.length && !block; i++)

{

block = (blocked[i] != null && blocked[i].getAddressString().

equals(source.getName()));

}

if (block) {

connection.release(JccEvent.CAUSE_DEST_NOT_OBTAINABLE);

}

} catch (Exception e) { ... }

finally { ... }

}

Kod ź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.lookup("profile");

}

catch (NamingException ne)

JAIN Service Logic Execution Environment

{

throw new CreateException("facility not available", ne);

}

public void sbbPostCreate() {}

public void sbbActivate() {}

public void sbbPassivate() {}

public void sbbLoad() {}

public void sbbStore() {}

public void sbbRemove() {}

public void sbbExceptionThrown(Exception exception, Object

ActivityContextInterface aci) {}

public void sbbRolledBack(RolledBackContext context) {}

Kod źródłowy 3: Klasa SBB-CallBlocking

public abstract class CallBlockingSbb implements Sbb

{

private SbbContext context;

private ProfileFacility profileFacility;

// SBB-Funkcje zwi

zane z cyklem

yciwoym usługi (Kod

ródłowy 2) ...

// Logika usługowa przetwarzaj

ca zdarzenia (Kod

ródłowy 1) ...

}

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ż otwarte

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 wszystkich

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

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.

Warto wspomnieć, iż kwestia kopiowania oprogramowania została przemilczana w definicji „open source”.

Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych

programistycznych, języków programowania, rozwiązań IT, etc.., z których potrafi

korzystać znacznie szersza społeczność.

niektóre projekty open source są na tyle dojrzałe i dopracowane, że mogą spełnić

wymagania, jakie stawia środowisko telekomunikacyjne (aspekty bezpieczeństwa,

wydajności, niezawodności). Jako przykład można wskazać np. Linux, w

szczególności jego inicjatywa OSDL-CGL (Open Source Development Labs Carrier

Grade Linux).

Zastosowanie open source w telekomunikacji niesie szereg korzyści:

umożliwia obniżenie kosztów w wyniku zastąpienia komercyjnych dedykowanych

rozwiązań wolnym oprogramowaniem (np. Linux). Operator nie musi się wiązać z

dostawcą sprzętu. Do rozbudowy i utrzymania może zatrudnić konkurencyjne firmy.

umożliwia budowę prototypów i ich testowanie niskim kosztem, dzięki zaangażowaniu

szerokiej społeczności programistów. Przykładem mogą być projekty: Mobicents,

Open IMS Core.

pozwala tworzyć złożone systemy wykorzystujące gotowe rozwiązania open source.

Przykładem może być zastosowanie serwera SER w komercyjnych softswitch.

Obecnie powstaje wiele inicjatyw tzw. „.org Players”, które promują zastosowanie

wolnego oprogramowania w telekomunikacji. Do ich grona można zaliczyć m.in.: OSDL-

CGL, Communications Platforms Trade Association (CP-TA), PCI Industrial Computer

Manufacturers Group (PICMG), SCOPE Alliance, Service Availability Forum (SA Forum),

etc..

6.2

Linux w zastosowaniach telekomunikacyjnych

Linux jest dobrym przykładem na bazie, którego można przedstawić generyczny cykl

ycia wolnego oprogramowania w zastosowaniach operatorskich. Początkowo Linux był

wykorzystywany wyłącznie do świadczenia usług, które nie były krytyczne dla działania

biznesu (np. obliczenia użytkowe, OS dla serwera WWW, FTP, itp..). W momencie

pojawienia się koncepcji NGN (softswitch, bramy medialne, itp..) oraz wzrostu stabilności

Linux-a, zaczęto go stosować do zadań o charakterze krytycznym, wymagających dużej

wydajności, niezawodności i bezpieczeństwa. Coraz większe zainteresowanie ze strony

operatorów i dostawców sprzętu przyczyniło się do powstania inicjatyw, które pracują nad

rozwojem takich cech Linux-a, które są istotne w zastosowaniach telekomunikacyjnych.

Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych

Przykładem takiej działalności jest OSDL-CGL, która rozwija i testuje system Linux pod

względem zapewnienia kompatybilności i wydajności.

6.3

Open Source JSLEE – Mobicents

Mobicents jest implementacją referencyjną JSLEE 1.0 Należy do grupy czterech

certyfikowanych przez SUN platform JSLEE (patrz Tabela 4). Jest to projekt open source,

którego jednym z celi jest stworzenie Open Source IMS. Aktualnie został przeniesiony przez

jego twórcę Ivelina Ivanov do struktur JBOSS, co przyspieszyło jego rozwój. W projekt

zaangażowani są przedstawiciele branży telekomunikacyjnej m.in. NIST, Open Cloud,

Alcatel Lucent, etc.. oraz grupa indywidualnych programistów.

Tabela 4 Istniejące implementacje referencyjne JSLEE

Implementacja

Utrzymanie

Informacje

JAIN SLEE Reference
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.x

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

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

postaci

WWW

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 FOKUS

, a następnie był

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

rozwijany razem z firmą Iptelorg

, 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 GPL

, 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ów

. 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

Iptelorg jest obecnie częścią firmy Tekelec.

GPL (GNU General Public License) jetst umową licencyjną zakładającą otwartość udostępnianego

oprogramowania (open source).

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

(interpretuje skrypty CPL), AUTH_DIAMETER (daje możliwość uwierzytelnienia z

wykorzystaniem zewnętrznego serwera AAA) oraz PRESENCE (implementuje serwer

obecności)

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

jest w pełni funkcjonalną centralką telefoniczną IP tzw. IP PBX (Private

Branch Exchange). Pomysłodawcą i twórcą tego rozwiązania był Mark Spencer

. Projekt

W wersji 1.2 oficjalne wydanie Open SER posiada 67 modułów.

Strona WWW projektu: www.asterisk.org.

Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych

został napisany w języku C i początkowo był przeznaczony pod system Linux, jednak

aktualnie powstały odmiany działające na większości systemów operacyjnych

. 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 Asterisk

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ów

. 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

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.

Powstała nawet kompilacja (asterisk@home) działająca pod systemem Windows, której instalacja i

konfiguracja wymaga minimalnych umiejętności.

Protokół IAX.

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

sygnału programowo, a nie na kartach TDM. Dzięki temu podejściu mogła zwiększyć się

liczba potencjalnych użytkowników

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

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

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

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-

Tomcat

serwery CSCF - Są to serwery SER z dodatkowymi rozszerzeniami zapewniające

funkcje związane ze środowiskiem systemu IMS.

Apache-Tomcat jest serwerem aplikacyjnym implementującym architekturę ‘http-Servlet’

Rola wolnego oprogramowania w tworzeniu usług telekomunikacyjnych

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

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 3GPP

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ń

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.

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:

mechanizmy sterowania usługami oparte o tzw. filtracje wiadomości SIP i

federacje serwerów aplikacyjnych;

mechanizmy zarządzania mobilnością;

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:

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;

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:

technika wykorzystująca interfejsy programistyczne zdefiniowane w ramach

inicjatywy JAIN (a w szczególności JAIN SIP);

architektura środowiska implementacji i uruchamiania aplikacji JSLEE;

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:

JAIN i JSLEE

Asterisk PBX

Open Sip Express Router

Opens IMS Core

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 SIP

, albo

specjalny algorytm uwierzytelnienia dla sieci UMTS

. 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 Internet

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

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.

IMS wymaga, aby agent użytkownika (UA) w procedurze uwierzytelnienia stosował algorytm EAP-AKA

(opisany w RFC4187).

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

Proxy

100

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, Presence

102

Warstwę logiki aplikacji tworzy:

usługa „Centrum Komunikacji Osobistej” (CKO), która jest zaimplementowana jako

skrypt PHP

103

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.

ite

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”

SIP

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ący
informacje 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’

: A

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

IP Multimedia Networks

IMS-
MGW

PSTN

MRFP

Legacy mobile
signalling Networks

I-CSCF

BGCF

C, D,
Gc, Gr

MRFC

SLF

PSTN

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 sygnalizacyjne

104

, 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

Identifier

105

. 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-CSCF

107

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 rejestracje

108

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żytkownika

109

Następnie zgłoszenie rejestracji jest kierowane do S-CSCF, którego adres został

otrzymany z HSS

110

. 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żytkownika

111

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ć Diameter

112

, 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 Cx

113

. 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ć rejestracji

114

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 rejestracji

115

. 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

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.

fil

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-CSCF

117

. 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 A
IFC, priorytet 1 = INVITE na sip:usluga1@as1.eims.local
IFC, priorytet 2 = INVITE na sip:usluga2@as2.eims.local

użytkownik #A

1. INVITE B

S-CSCF

P-CSCF

. I

service control

INVITE sip:B@eims.local SIP/2.0
P-Original-Dialog-ID: call-id=de40707c-cede-db11-8499@rubi;from-tag=2644707c
P-Service-Name: <sip:usluga1@as1.eims.local>

INVITE sip:B@eims.local SIP/2.0
P-Original-Dialog-ID: call-id=de40707c-cede-db11-8499@rubi;from-tag=2644707c
P-Service-Name: <sip:usluga2@as2.eims.local>

użytkownik #B

6. INVITE B

P-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

serwera

aplikacyjnego

adresie

„sip:usluga1@as1.eims.local”

Rys. 56: Definicja filtru IFC

IFC zawiera także informacje o rodzaju sesji (SessionCase), której dotyczy dana

reguła IFC. Rodzaj sesji określa czy IFC ma być stosowane do zgłoszeń

wychodzących (Originating Service Control), zgłoszeń przychodzących (Terminating

Service Control) lub zgłoszeń przychodzących do użytkownika, który nie jest

zarejestrowany w systemie IMS (Terminating Service Control for Unregistered User

State).

Wstawienie nagłówka „P-Original-Dialog-ID”

118

Jeśli zgłoszenie jest nowym zgłoszeniem (nie jest powracającym zgłoszeniem z

serwera aplikacyjnego) i wymaga obsługi w serwerze aplikacyjnym, to S-CSCF

dodaje do wiadomości SIP dodatkowy nagłówek identyfikujący jednoznacznie

przynależność tej wiadomości do danego zgłoszenia. Wartością nagłówka ‘P-

Original-Dialog-ID’ jest konkatenacja identyfikatorów dialogu protokołu SIP, czyli

wartości nagłówka ‘Call-ID’ oraz etykiet nagłówków ‘From’ i ‘To’ (patrz Rys. 57).

118

W IMS jest stosowany inny mechanizm tzn. nie jest wstawiany dodatkowy nagłówek ‘P-Original-Dialog-

ID’. Według [7] aby umożliwić identyfikacje powracającej wiadomości do poszczególnych zgłoszeń stosuje się
nagłówek ‘Route’ (jego rola w protokole SIP opisana jest w [22]), do którego dodaje się specjalnie
skonstruowany adres nieistniejącego serwera. Ten spreparowany adres jest używany jako identyfikator
zgłoszenia i pozwala S-CSCF zidentyfikować wiadomość. To rozwiązanie zostało zaakceptowane przez 3GPP i
jest obecnie standardem. We wczesnych pracach nad mechanizmami w IMS pojawiła się propozycja użycia
nagłówka ‘P-Original-Dialog-ID’ (opisana w IETF draft-henrikson-sip-original-dialog-id), która zakładała
użycie nowego nagłówka zamiast korzystania z ‘Route’, który jest bazowym (opisanym RFC3261) elementem
protokołu SIP. Propozycja ta wynikała z faktu, że wykorzystywanie ‘Route’ jako identyfikatora sesji (tak jak
zostało to opisane powyżej) jest de facto niezgodne z przeznaczeniem tego nagłówka opisanym RFC3261. Ta
kwestia była i jest poddawana krytyce.

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 SIP

119

. Dzieje się tak, ponieważ

każdy serwer aplikacyjny potencjalnie może występować w tzw. roli B2BUA

120

. 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

-U

x-M

. C

x-M

. C

x-S

. C

x-S

Rys. 59: Proces rejestracji użytkownika w systemie IMS (środowisko badawcze)

Szczegółowy opis procesu rejestracji:

Agent użytkownika zaimplementowany w terminalu wysyła do P-CSCF

121

wiadomość

P-CSCF tworzy nową transakcje dla zgłoszenia i modyfikuje R-URI

122

wiadomości,

wstawiając w to pole adres serwera I-CSCF.

Wiadomość REGISTER kierowana jest do I-CSCF.

I-CSCF rozpoczyna wykonywanie procedury User-Registration-Query, której celem

jest uzyskanie adresu serwera S-CSCF.

I-CSCF wysyła wiadomość Cx-User-Authentication-Request

123

do HSS, w której

zawarty jest publiczny (PUI) i prywatny (PRUI) identyfikator użytkownika.

HSS wykonuje procedurę Cx-User-Authentication, której celem jest sprawdzenie

poprawności identyfikatorów użytkownika i wybranie serwera S-CSCF

124

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

HSS wysyła wiadomość Cx-User-Authentication-Answer do I-CSCF, która zawiera

adres serwera S-CSCF wybranego do obsługi użytkownika.

I-CSCF przesyła wiadomość REGISTER do S-CSCF.

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 uwierzytelnienia

125

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 HSS

126

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-CSCF

128

(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:

pytanie do HSS o profil użytkownika identyfikującego się poprzez PUI;

odczyt z profilu, adresu obsługującego S-CSCF i translacja PUI na adres sieciowy

zgodnie z asocjacją AOR->FQDM w S-CSCF.

127

Zgodnie z [7] po popraniu profilu użytkownika, S-CSCF powinien wykonać tzw. procedurę „rejestracji przez

trzecią stronę” (z ang. Third-Party Registration) polegającą na rejestracji użytkownika przez S-CSCF we
wszystkich serwerach aplikacyjnych, których adresy są zawarte w profilu. Ze względu na małe znaczenie tego
mechanizmu w analizowanych zagadnieniach w implementowanym środowisku badawczym został on
pominięty.

128

Według specyfikacji IMS, HSS może też wybrać listę serwerów S-CSCF.

129

Np. terminal przyłączony do sieci pod adresem IP = 10.10.10.10 i nasłuchujący wiadomości SIP na porcie

UDP = 8060 posiada adres URI = sip:10.10.10.10:8060. Jest to tak zwany FQDN (Fully qualified domain name)
jednoznacznie określający host w sieci IP.

130

Np. sip:ala@eims.local. Publiczny identyfikator jest wykorzystywany w S-CSCF jako tzw AOR (Address of

routing), który w skojarzeniu z FQDM umożliwia routing wiadomości.

Implementacja i analiza modelu sterowania usługami zaproponowanego w IP Multimedia Subsystem

127

filu

fil

‘si

l’

. I

@
e

ca
l

. I

@
1

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),

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 logicznych

132

. 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:ala@eims.local

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ści

133

wartość
określonego
nagłówka

Składa się z nazwy nagłówka
oraz

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

serwerach

aplikacyjnych

jest

zależna

sieci

dostępowej

użytkownika

można

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:

ela@eims.local’

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 AS

134

. 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

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

użytkownik #A

sygnalizacja
(SIP)

użytkownik #B

0 O

3. wykonanie logiki usługi +
ewentualna modyfikacja
wiadomości INVITE

S-CSCF

użytkownik #A

użytkownik #B

S-CSCF

użytkownik #A

użytkownik #B

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. dwunastoma

136

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 transakcji

137

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

138

dla zgłoszeń przychodzących powinny być skierowane właśnie do tego

serwera aplikacyjnego, czyli właściwego serwera obecności. Obsługa innych zgłoszeń

(zgłoszenie 2) nie jest przekazywana do AS.

Rys. 65: Zależność pomiędzy IFC a funkcją realizowaną przez dany AS (na przykładzie serwera

obecności)

Występowanie problemów opisanych w rozdziale 9.5, związanych z przeciążeniem

wiadomościami sygnalizacyjnymi nakłada wymaganie, aby definicje filtracji (IFC) bardzo

szczegółowo określały zakres zgłoszeń, których obsługa będzie kierowana do serwera

aplikacyjnego. Dzięki takiej precyzyjnej, uwzględniającej specyfikę logiki realizowanej na

AS definicji, możliwe jest obsługiwanie zgłoszeń na wielu serwerach aplikacyjnych, które

138

Znaczenie wiadomości SUBSCRIBE i PUBLISH w realizacji usługi obecności wyjaśniona jest w rozdziale

10.5

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

CSCF

SIP Application

Server

SIP Application

Server

HSS

OSA service

capability server

(SCS)

OSA service

capability server

(SCS)

SSF

Camel Service

Environment

Camel Service

Environment

OSA

application

server

OSA

application

server

ISC

CAP

MAP

OSA API

SCIM

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

(wiadomość

2.).

Następnie,

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

łu

profil

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 technik

139

, 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

wybrali

140

ten najbardziej złożony

141

. 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ą

Mobicents

142

, 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 aplikacji

143

, 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 3PCC

145

. 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 dokumencie

146

[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.

llI

tio

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ątkowe

147

. 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 sesji

148

. 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 address

150

, 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-only

151

. 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 UA

152

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)

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 holed

153

Nie

Tak

Nie

Problem time-out

Tak

Nie

Założenia

mediach

Nie

Tak

Nie

Inne

Możliwość
wystąpienia
pętli

Nie

gwarancji,

terminale mają
zgodne kodeki

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 testach

154

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- RMI

155

rdzenia aplikacji

156

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 webowej

157

rozmieszczonej na serwerze

aplikacyjnym. Dodatkowo aplikacja ta zawiera klasy pomocnicze służące przygotowaniu i

procesowaniu wiadomości SOAP

158

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 XML

159

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

lą

W
W
W

lik

)

łą

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)

klasy

ThirdPartyCallAdapter

. Natomiast w ciele funkcji

makeCall(...)

z klasy

ThirdPartyCallAdapter

znajduje

się

wywołanie

funkcji

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 SDL

160

, 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

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ą funkcje

161

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 numeru

162

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

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,

które

powinno zostać przekierowanie
połączenie.

Forward

UnconditionalForward tak

Numer

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

Numer, na który zostanie przekierowanie
połączenie

OnBusyAddress

xsd:anyURI

Numer, na który zostanie przekierowanie
połączenie w przypadku gdy linia jest zajęta

OnNoAnswerAddress xsd:anyURI

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:

na jakiej podstawie dane połączenie powinno zostać odrzucone,

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ń aplikacji

164

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 XML

165

), 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

wywołania

odpowiednich

metod

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

TaskState

166

skojarzenie

reguł

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

a@eims.local i c@eims.local zostaną obsłużone przez CSCF (nie obciążają serwera

obsługi połączeń);

obiekt

CallHandlingRulesAss

jest tworzony w momencie utworzenia reguł dla danego

numeru, a usuwany w momencie wyczyszczenia reguł tj. wywołania funkcji

void

clearRules(...)

;

funkcja

processCallHandlingRule(...)

– przetwarza reguły obsługi połączeń

zgodnie z kolejnością wskazaną w rozdziale 10.2.1. Brak reguły powoduje

pominięcie danego kroku;

10.3

Informacja o statusie terminala (interfejs Terminal Status)

Interfejs Parlay X: Terminal Status, jak sama nazwa wskazuje umożliwia uzyskanie

informacji na temat statusu terminala lub terminali IMS, a także na odbieranie w sposób

asynchroniczny powiadomień o zmianach statusu terminala/i IMS. Funkcjonalność taka

pozwala na projektowanie usług kontekstowych zainteresowanych informacją o statusie

terminala. Funkcjonalność tego interfejsu może zostać wykorzystana np. do realizacji usługi

dzwoń kiedy jest dostępny (call when available) w ramach usługi telekonferencji. Wówczas

telekonferencja taka zostanie zestawiona w momencie, gdy zadeklarowany zbiór terminali

będzie miał określony status - osiągalny.

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ęty

167

(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: Presence

168

. Do sprawdzenia statusu terminala postanowiono użyć

wiadomości OPTIONS

169

, 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 Here

170

- aplikacja zwraca status BUSY

Nie otrzymał żadnej wiadomości w przeciągu 30 sek. – aplikacja zwraca status

UNREACHABLE.

Przykładowe zachowanie się serwera na wysłanie wiadomości OPTIONS przedstawia Rys.

85.

168

Warto w tym miejscu wspomnieć o mechanizmie użytym przez IBM przy implementacji interfejsu Parlay X:

Terminal

Status

(patrz

http://publib.boulder.ibm.com/infocenter/wtelecom/v6r1/index.jsp?topic=/com.ibm.twss.services.doc/termstat_d
ev_c.html). Zaimplementowany mechanizm jest mechanizmem wykorzystywanym w usłudze obecności. Bazuje
on na wiadomościach SUBSCRIBE i NOTIFY, które wymieniane są pomiędzy serwerem obecności, a aplikacją
zbudowana na usłudze sieciowej. Rodzi się zatem pytanie jaki cel przyświecał implementacji interfejsu Parlay
X: Terminal Status, skoro ma identyczną funkcjonalność jak interfejs Parlay X: Presence?

169

Definicja żądania OPTIONS znajduje się w [22] w sekcji 4.2.3.

170

Definicja tej odpowiedzi znajduje się w [22] w sekcji 21.4.24.

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 XML

171

), 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.

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 Managemnet

172

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

funkcje

173

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 grupy

174

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

ryM
e

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).

su
b

scr
ib

se
n

se
rP

se
n

rtP

se
n

ce
N

tif

tio

ce
N

tif

tio

sC
h

sE
n

tif

yS
u

sc
rip

tio

su
b

sc
rip

tio

lish

scr
ip

tio

riza
tio

W
a

tch
e

sc
rib

ttr

ckS

tio

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 5

procedures e.g. CAMEL, MAP, CAP, RADIUS, ISC, Cx, Sh.

The Pr, Pp interfaces are based on existing Release 6 procedures of

the 3GPP- WLAN interworking architecture.

Peu

Presence User agent

(Presence information

provided by the user)

Presence Network agent (Presence

information provided by the

network)

Pen

MSC Server

/VLR

SGSN

GMLC

Presence suppliers

Presence server

(home network)

Presentity

Presence Proxy

Watcher

Presence Proxy

Watcher

applications

HSS

(HLR)

Pwp

GGSN

S-CSCF

HSS/HLR

Presence External agent (Presence

information provided by elements

outside the provider’ s network)

Pex

3GPP AAA

Server

PDG

Pep

Presence

List Server

Pet

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 funkcje

175

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ócona

176

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:

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 PIDF

177

RPIDF

178

, 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ący
informacje o stanie
obecności użytkownika

Publish

Get User Presence

1. PU

BLISH

2. P

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 rozliczony

180

;

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 Security

181

(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.

)

lą

W
W
W

lik

rip

lik

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/Servlet

182

, CGI

183

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 PEAR

185

. 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 prostym

186

, 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 XMLHttpRequest

188

. 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.php

GET

(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 AJAX

POST

Utworzenie obiekt XMLHttpRequest

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

Wyszukanie interesujących usług sieciowych w węzłach UDDI

189

;

Pobranie opisu usługi sieciowej w postaci WSDL z UDDI lub bezpośrednio ze

strony zwierającej specyfikację Parlay X (np. www.parlay.org);

Wygenerowanie zrębu aplikacji – metod, za pomocą których będą wołane usługi;

Stworzenie aplikacji;

Rejestracja/podpisanie stosownej umowy z dostawcą usług sieciowych w celu

późniejszego rozliczenia oraz w kwestiach bezpieczeństwa;

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ów

190

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, MMS

191

, 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 (CSS

192

), który w transparentny i globalny sposób pozwala zarządzać

formatowaniem elementów HTML.

Graphical User

Interface

(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

ic.

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 PHP

193

względu na istnienie oraz łatwość użycia odpowiednich bibliotek wspierających Web Services

(PEAR/SOAP).

Każdy komponent tego typu został podzielony na sekcje związane z funkcjonalnością

danego modułu. Np., Logika modułu call handling składa się z trzech sekcji setRules,

getRules, clearRules. Części te są odpowiednio odwzorowywane na funkcje komponentu

AJAX Logic.

W ramach każdej z tych sekcji następuje obsługa usługi sieciowej, która realizowana

jest w trzech krokach:

ustawienie referencji na żądaną usługę sieciową:

$wsdl=new SOAP_WSDL('http://localhost:8180/axis2/services/CallHa

ndlingService?wsdl');

193

Technika AJAX może współpracować z innymi językami, ponieważ komunikacja pomiędzy klientem, a

serwerem realizowana jest w oparciu o obiekt przenoszący XML.

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' => $forwardingAddress,

'onBusyAddress' => $forwardingAddress,

'onNoAnswerAddress' => $forwardingAddress

)

);

wywołanie funkcji na obiekcie reprezentującym usługę sieciową:

$response = $client->setRules($request);

przetworzenie zgodnie z wymaganiami odpowiedzi z usługi sieciowej i wypisanie na

standardowe wyjście PHP. 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:ala@eims.local

)

ustawić dla właściwości

onreadystatechange

obiektu XMLHttpRequest tzw.

EventHandler. EventHandler może być dowolną funkcją, która powinna zwrócić 4 w

Centrum Komunikacji Osobistej

183

przypadku, gdy zostanie odebrana cała odpowiedź od serwera. Funkcja ta zastępuje

odpowiedni

<div>

zawartością

odpowiedzi

XMLHttpRequest

(

document.getElementById("BuddyList").innerHTML=xmlHttp.responseText

)

Otworzyć połączenie dla wybranego żądania HTTP (np. GET): funkcja

open(

żą

danie, url, czy wysła

);

Wysłać żądanie (funkcja

send(null)

Komponent AJAX Logic, ma również modułową budowę, która zapewnia łatwą

rozbudowę aplikacji o kolejne moduły funkcjonalne. Dodanie nowego modułu wiąże się ze

stworzeniem nowego EventHandler’a oraz dopisaniem funkcji przywiązanej do określonego

zdarzenia Java Script.

11.4.4

Zasada działania aplikacji

Rejestracja użytkownika

Pierwszym etapem w interakcji użytkownika z aplikacją jest rejestracja do systemu.

Użytkownik podaje standardowo login i hasło. Strona zawierająca komponent Security and

authorization zabezpieczona jest z wykorzystaniem protokołu TLS. Dane rejestracyjne są

przesyłane w zaszyfrowanym kanale TLS do serwera. Na serwerze następuje komunikacja z

bazą HSS zawierającą profil użytkownika oraz sprawdzenie tożsamości i uprawnień

użytkownika. Ten etap komunikacji nie jest już zabezpieczony, ponieważ zgodnie z definicją

JAIN realizowany jest w obszarze bezpiecznym należącym do operatora sieci

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łączeniami

194

. 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życiu

195

. 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 CGI

196

(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łącznie

197

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

sieciowych

198

. 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

rdzeniowych

199

elementów architektury funkcjonalnej IMS (P-CSCF, S-CSCF, HSS). Zakres

implementacji ograniczony został do procedur umożliwiających modelowanie mechanizmu

sterowania usługami

200

. 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:

Model sterowania usługami IMS;

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

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);

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 SIP

202

, 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 wymaga

203

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

aplikacyjnymi

204

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

techniki

stosowanej

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

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

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

Intelligent Network

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

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

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

Profil #1

Definiuje

przekierowanie

wiadomości

PUBLISH

dla

zgłoszeń

przychodzących do zarejestrowanego i nie zarejestrowanego użytkownika, na adres serwera

obecności (sip:registered@ps.eims.local:5063 i sip:unregistered@ps.eims.local:5063).

<SPT>

<Method>PUBLISH</Method>

</SPT>

</TriggerPoint>

<SPT>

<Method>SUBSCRIBE</Method>

</SPT>

</TriggerPoint>

<ServerName>sip:registered@ps.eims.local:5063</ServerName>

</ApplicationServer>

</InitialFilterCriteria>

<SPT>

<Method>PUBLISH</Method>

</SPT>

</TriggerPoint>

<SPT>

<Method>SUBSCRIBE</Method>

</SPT>

</TriggerPoint>

202

<ServerName>sip:unregistered@ps.eims.local:5063</ServerName>

</ApplicationServer>

</InitialFilterCriteria>

</profile>

Profil #2

Definiuje przekierowanie wiadomość INVITE dla zgłoszeń przychodzących do nie

zarejestrowanego użytkownika, na adres serwera implementującego interfejs Parlay X: Call

Handling (sip:callhandling@as.eims.local:5072).

<SPT>

<Method>INVITE</Method>

</SPT>

</TriggerPoint>

<ServerName>sip:callhandling@as.eims.local:5072</ServerName>

</ApplicationServer>

</InitialFilterCriteria>

</profile>

Profil #3

Definiuje przekierowanie wiadomość INVITE dla zgłoszeń przychodzących do

zarejestrowanego użytkownika, na adres serwera implementującego interfejs Parlay X: Call

Handling (sip:callhandling@as.eims.local:5072).

<SPT>

<Method>INVITE</Method>

</SPT>

</TriggerPoint>

<ServerName>sip:callhandling@as.eims.local:5072</ServerName>

203

</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.

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

Konfiguracja

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

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>") {

Należy utworzyć strukturę bazy danych w PostgeSQL wykorzystując skrypt hss.sql.

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

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)

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

Konfiguracja

Zawartość katalogu tomcat-shared należy umieścić katalogu shared serwera Tomcat

Przy pomocy narzędzie manager należy zainstalować na serwerze Tomcat aplikacje

axis2.war

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

Należy zmodyfikować plik parlayx/thirdpartycall_controller_config.xml:

Należy zmodyfikować plik parlayx/callhandling_controller_config.xml:

Należy zmodyfikować plik parlayx/terminalstatus_controller_config.xml:

Należy zmodyfikować plik parlayx/addresslistmanagement_controller_config.xml:

<entry key="org.eims.HSS_URL">jdbc:postgresql://<HSS_IP>/hss</entry>

Należy zmodyfikować plik parlayx/ presence_controller_config.xml:

205

Użytkownik „admin”, hasło „axis2”

208

Uruchamianie serwerów

Aby wystartować serwery implementujące interfejsy Parlay X należy uruchomić skrypt

run_parlayx.sh.

#>./run_parlayx.sh

209

Załącznik

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].

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

Konfiguracja

Należy zmodyfikować plik ps/databaseserver/dbs.cfg:

DBS_PORT=<DBS_PORT>

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>

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

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

Konfiguracja

Należy zainstalować jedynie wymagane oprogramowanie wskazane powyżej w

założeniach.

211

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.

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:

Jądro Linux w wersji 2.4 lub w wersji 2.6

Pakiet bison i bison-devel (wymagane do kompilacji Asterisk)

Pakiety zlib i zlib-devel

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

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

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

Wyszukiwarka

Podobne podstrony:
Modele organizacji i usług w opiece zdrowotnej
(P) modele biznesowe e usług
standardy wykonywania zawodu i zakres uslug architekta
9,10 Modele rastrowych i wektorowych danych w SIP,Mozliwosci wykorzystania SIP w architekturze krajo
9,10 Modele rastrowych i wektorowych danych w SIP,Mozliwosci wykorzystania SIP w architekturze krajo

więcej podobnych podstron