Praca dyplomowa magisterska

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

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

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

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

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

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

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

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

‘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

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.

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

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.

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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/

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

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>

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

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”

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.

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