Konfiguracja kryteriów iFC

Wszystkie opisane poniżej działania konfiguracyjne wykonane zostały poprzez in-terfejs GUI zrealizowany jako strona Web dostępna na serwerze HSS. Konfiguracja kryteriów iFC wymagała, aby użytkownicy, których one dotyczą byli uprzednio utworzeni i skonfigurowani w bazie HSS.

Rysunek 10. Widok menu „Private User Identity” do konfiguracji identyfikatora IMPI

Utworzenie użytkowników (abonentów) systemu IMS polegało na wykreowaniu identyfikatorów prywatnego – IMPI (IP Multimedia Private Identity) i publicznego

– IMPU (IP Multimedia Public Identity) oraz połączeniu ich w subskrypcję IMS (IMS subscription). Na rysunkach 10-12 pokazano szczegółową zawartość kolej-nych menu służących do konfiguracji odpowiednio identyfikatorów IMPI, IMPU oraz IMSU. Pokazane menu wypełnione zostały przykładowymi danymi dla użyt-kownika „Alicja”.

Rysunek 11. Widok menu „Public User Identity” do konfiguracji identyfikatora IMPU

Kryteria iFC, decydujące o przekazaniu sterowania do płaszczyzny aplikacyjnej, są częścią profilu usługi (Service Profile), którego konfiguracji dokonuje się w menu „Service->Service Profiles”. W zasadzie profil usługi to zestaw kryteriów iFC decy-dujących o kolejności wywoływania usług lub ich komponentów. Powiązanie po-między abonentem a profilem usługi tj. określenie, z których usług może korzystać konkretny abonent, następuje w menu „User identities” -> „Public User Identity” (rysunek 11). Na rysunku 13 pokazano widok z konfiguracji profilu usługi „TAS_sp” (TAS Service Profile), w którym widać dodane tylko jedno kryterium iFC o nazwie „tas_ifc”.

Rysunek 13. Konfiguracja profilu usługi TAS_sp.

Konfiguracja kryteriów iFC odbywa się w menu „Initial Filter Criteria” i obejmuje ustalenie wartości następujących parametrów: nazwa (Name) identyfikująca kryte-rium iFC np. „tas_ifc”, nazwa powiązanego punktu wyzwalania (Trigger Point) np. „tas_tp”, nazwa identyfikująca serwer aplikacyjny (Application Server) np. „tas_as” oraz określenie wymagań dotyczących statusu użytkowników korzystających z tego konkretnego kryterium iFC (Profile Part Indicator) np. czy musi być zarejestrowany (Registered). Konfiguracja kryteriów iFC dla naszej usługi przekierowania CFU zo-stała pokazana na rysunku 14.

Rysunek 14. Konfiguracja kryteriów iFC dla usługi przekierowania CFU

Punkt wyzwalania (Trigger Point), który jest jednym z elementów kryteriów iFC, definiuje konkretne warunki, których spełnienie powoduje przekazanie sterowania do serwera aplikacyjnego. Konfiguracja punktu wyzwalania dla przykładu rozważa-nej usługi CFU, została pokazana na rysunku 15.

Definicja punktu wyzwalania (Trigger Point) obejmuje określenie jego unikalnej na-zwy (name) np. „tas_tp”, powiązanie go z istniejącym kryterium iFC (List of atta-ched IFCs) np. „tas_ifc” oraz określenie wartości dla konkretnych elementów wiadomości sygnalizacyjnej SIP, których wystąpienie spowoduje przekierowanie wiadomości do serwera aplikacyjnego. Elementy, których wartości możemy okre-ślać, obejmują adres „Request URI” decydujący o routingu wiadomości SIP, metodę SIP, dowolny nagłówek wiadomości SIP oraz kierunek połączenia (Session Case) określający czy analiza spełnienia warunków ma następować po stronie inicjującej (Origin – Req) czy po stronie odbierającej (Term – Req).

Do konfiguracji usługi CFU dla użytkownika „Bolek” należy przypisać parame-trom „Request URI”, „SIP Method” oraz „Session Case” takie wartości, jak poka-zane na Rysunku 15. Z definicji usługi CFU dla użytkownika „Bolek” wynika, że powinna być ona wywoływana tylko dla użytkownika „Bolek”, podczas zestawiania do niego sesji. Dlatego element „Request URI” musi zawierać identyfikator pu-bliczny (IMPU) użytkownika „Bolek”, a element „SIP Method” musi przyjąć war-tość „Invite”.

Podczas rejestracji użytkownika w systemie IMS, zestaw kryteriów iFC (będący elementem profilu usługi powiązanego z użytkownikiem) ładowany jest z bazy HSS do węzła S-CSCF obsługującego danego użytkownika. W przypadku usługi CFU działającej na rzecz użytkownika „Bolek”, kryteria iFC z nią związane zostaną za-ładowane do tego węzła S-CSCF, który obsługuje użytkownika „Bolek”. Z tego powodu element „Session Case” ma ustaloną wartość „Term – Req”, czyli działa dla połączeń przychodzących, w domyśle do użytkownika „Bolek” (rysunek 15). 5.2. Konfiguracja serwera TAS

Konfiguracja Kamailio jako serwera TAS z usługą CFU wymaga stworzenia w lokalnej bazie danych w tabeli „usr_preferences” wpisu, który obędzie okre-ślać specyficzne zasady obsługi połączenia kierowanego do wskazanego użyt-kownika, którym w tym przypadku jest abonent „Bolek”. W tym celu należy wy-konać poniższą komendę SQL INSERT, która doda do lokalnej bazy danych zrealizowanej w oparciu o system mysql, informację o zamianie adresów URI.

insert into usr_preferences VALUES (1,' ','Bolek','open-ims.test','callfwd,'0','sip:celina@open-ims.test',' ')

Wprowadzony wiersz definiuje dla użytkownika o nazwie „Bolek” nowy atrybut o nazwie „callfwd” i przypisuje mu wartość „sip:celina@open-ims.test”. Następ-nie w pliku kamailio.cfg, w którym zapisana jest cała logika rutingu wiadomości sygnalizacyjnych SIP, w części odnoszącej się do akcji podejmowanych po ode-braniu wiadomości SIP „Invite”, należy dodać fragment kodu sprawdzający czy dla użytkownika określonego przez nazwę w adresie „Request URI” wiadomości SIP „Invite” zdefiniowane zostały akcje zmiany zasad kierowania i ewentualnie wykonać je.

W naszym przypadku weryfikacja polega na sprawdzeniu czy w bazie „usr_pre-ferences” dla użytkownika określonego przez nazwę w adresie „Request-URI” ist-nieje atrybut „callfwd”. To sprawdzenie zaimplementowane jest w następującej linii pliku kamailio.cfg:

if (avp_db_load("$ruri/username", "s:callfwd")) {

Jeżeli weryfikacja przebiegnie pozytywnie, wówczas należy zmienić zasady kie-rowania wiadomości SIP „Invite” według reguł określonych w odnalezionym wpi-sie tabeli „usr_preferences”. Oznacza to, że do adresu Request-URI otrzymanej wiadomości SIP „Invite” należy wstawić wartość przechowywaną w atrybucie „callfwd” odnalezionego wpisu. To zadanie realizuje następująca linia kodu z pliku kamailio.cfg:

avp_pushto("$ruri", "s:callfwd");

Przy konfiguracji określonej powyżej, odebranie w serwerze TAS wiadomości SIP „Invite” z nazwą “Bolek” w adresie „Request-URI”, spowoduje sprawdzenie i odnalezienie atrybutu “callfwd” oraz przepisanie do adresu „Request-URI” wartości „sip:celina@open-ims.test”. Natomiast odebranie wiadomości SIP „Invite” z jakąkolwiek inną nazwą w adresie „Request-URI” nie spowoduje żadnych zmian. W efekcie tylko wiadomości SIP „Invite” kierowane do użytkow-nika „Bolek” będą przekierowywane na adres sip: celina@open-ims.test.

W opisany powyżej sposób, bardzo elastycznie można zmieniać zasady kie-rowania wiadomości SIP poprzez dodawanie odpowiednich wpisów w tabeli „usr_preferences”. Dzięki temu na platformie Kamailio 3.0 można zrealizować inne usługi dodatkowe telefonii np. przekierowanie w przypadku zajętości abo-nenta wywoływanego (Call Forward on Busy) lub w przypadku braku odpowie-dzi (Call Forward No Answer).

Na rysunku 16 przedstawiono wymianę wiadomości sygnalizacyjnych podczas zestawiania połączenia i wywołania usługi CFU. Ilustracja przedstawia wymianę wiadomości SIP faktycznie przesyłanych w sieci i zebranych za pomocą analizatora sieciowego Wireshark [34] na maszynie wirtualnej, na której zainstalowano plat-formę OpenIMSCore.

Z punktu widzenia obserwowanej wymiany wiadomości SIP jest to optymalny punkt przechwytywania ruchu SIP, ponieważ pozwala zaobserwować całą wymianę w jednym punkcie, tj. ruch od i do terminali, ruch od i do platformy OpenIMSCore oraz ruch od i do serwera aplikacyjnego Kamailio.

Należy podkreślić, że z powodu instalacji całej platformy OpenIMSCore na jed-nej maszynie wirtualjed-nej, węzły P-CSCF, S-CSCF oraz I-CSCF związane są z tym samym interfejsem sieciowym i adresem IP różniąc się jedynie numerami portów UDP. Z tego powodu na rysunku 16 węzły P-CSCF, S-CSCF oraz I-CSCF reprezen-towane są jako jeden element, a wiadomości SIP wymieniane między nimi nie zo-stały przedstawione.

Rysunek 16. Wymiana wiadomości sygnalizacyjnych podczas wykonywania usługi CFU Alicja P-CSCF S-CSCF I-CSCF Serwer

Aplikacyjny ^{Bolek Celina}

Invite (bolek@open-ims.test)

100 Trying 100 Trying _{Invite (bolek@open-ims.test)}

100 Trying Podmiana adresu docelowego Invite (celina@open-ims.test) Invite (celina@open-ims.test) 100 Trying 183 Progress 183 Progress 183 Progress 183 Progress

PRACK (bolek@open-ims.test) _{PRACK (bolek@open-ims.test)} PRACK (bolek@open-ims.test) 200 OK PRACK (bolek@open-ims.test) 180 Ringing 200 OK 180 Ringing 200 OK 180 Ringing 200 OK 180 Ringing

PRACK (bolek@open-ims.test)_{PRACK (bolek@open-ims.test)} PRACK (bolek@open-ims.test) PRACK (bolek@open-ims.test) 200 OK 200 OK 200 OK 200 OK 200 OK 200 OK 200 OK 200 OK Odebranie połączenia ACK (bolek@open-ims.test) ACK (bolek@open-ims.test) ACK (bolek@open-ims.test) ACK (bolek@open-ims.test) BYE BYE BYE BYE 200 OK 200 OK 200 OK 200 OK

6. Podsumowanie

W opracowaniu przedstawiono genezę oraz koncepcję systemu IP Multimedia Sub-system. W skrótowy sposób opisano jego architekturę oraz zasady działania. Na wy-kresach MSC (Message Sequence Chart) zilustrowano wymianę informacji w pod-stawowych scenariuszach sygnalizacyjnych, tj. podczas rejestracji użytkownika w systemie (rysunek 2), w czasie zestawiania połączenia pomiędzy dwoma abonen-tami sieci IMS (rysunek 3), a także podczas zestawiania połączenia z sieci IMS do PSTN (rysunek 4) oraz z sieci PSTN do IMS (rysunek 5). Analiza przedstawionych scenariuszy wymiany sygnalizacji miała na celu osiągnięcie efektu lepszego zrozu-mienia zasad działania systemu IMS oraz roli poszczególnych elementów z płasz-czyzny sterowania. W rozdziale 4 omówiono sposób realizacji usług w systemie IMS, wyjaśniając rolę takich elementów konfiguracji jak: profil użytkownika, profil usługi, identyfikatory publiczny (IMPU) i prywatny (IMPI), kryteria filtrowania iFC, punkty wyzwalania (Trigger Points) oraz punkty wyzwalania usługi (Service Point Triggers). Opisano również rolę i tryby pracy serwerów aplikacyjnych. W rozdziale 5 przedstawiono proces kreacji i konfiguracji usługi bezwarunkowego przekierowa-nia połączeprzekierowa-nia telefonicznego (CFU) na bazie oprogramowaprzekierowa-nia OpenIMSCore oraz Kamailio. Przykład miał na celu skonkretyzowanie koncepcji przybliżanych w roz-działach 1-4 oraz zapoznanie czytelników z konfiguracją platformy OpenIMSCore oraz wykorzystaniem oprogramowania Kamailio jako serwera telefonii (Telephony Application Server; TAS). Szczegółowo opisane kolejne kroki konfiguracji środowi-ska OpenIMSCore oraz implementacji usługi CFU pozwalają czytelnikom na samo-dzielne powtórzenie procesu wdrożenia usługi i w ten sposób nabycie umiejętności praktycznych związanych z obsługą wdrażania usług w systemie IMS.

Literatura

[1] ITU-T Recommendation I.120, „Integrated Services Digital Networks (ISDNs)”, March 1993.

[2] ITU-T Recommendation I.412, „ISDN user-network interfaces – Interface structures and access capabilities”, November 1988.

[3] ITU-T Recommendation I.113, „Vocabulary of terms for broadband aspects of ISDN”, June 1997.

[4] ATM-Forum, Technical Committee, “Traffic Management Specification, Ver-sion 4.0” – April 1996.

[5] http://www.3gpp.org

[6] 3GPP TR 21.101, „Technical Specifications and Technical Reports for a UTRAN-based 3GPP system”.

[7] Spec 3GPP TS 24.302 version 11.7.0 Release 11 [8] http://www.openimscore.org

[9] 3GPP TS 22.228, “Service Requirements for the Internet Protocol (IP) Multi-media Core Network Subsystem; Stage 1”.

[10] G. Camarillo, M.A. García-Martín, The 3G IP multimedia subsystem (IMS): merging the Internet and the cellular worlds, 3rd ed. Chichester, West Sussex: Wiley, 2008.

[11] ITU-T Recommendation Q.1208 „General aspects of the Intelligent Network Application protocol”.

[12] ITU-T Recommendation Q.1201 „Principles of IN Architecture”. [13] ITU-T Recommendation Q.1202 „IN Service Plane Architecture”. [14] ITU-T Recommendation Q.1203 „IN Global Functional Plane”.

[15] Rosenberg, J., et al., “SIP: Session Initiation Protocol” IETF RFC-3261, June 2002.

[16] ETSI, ETS 300 374-1, „IN CS-1; Core Intelligent Network Application Pro-tocol (INAP); Part 1 - proPro-tocol specification”, September 1994.

[17] ETSI, TS 101 046 V5.5.0, „Digital cellular telecommunications system (Phase 2+); Customized Applications for Mobile network Enhanced Logic (CA-MEL); CAMEL Application Part (CAP) specification”, July 1998.

[18] 3GPP TS 23.002: „Network Architecture”.

[19] 3GPP TS 23.228, „IP Multimedia Subsystem (IMS); Stage 2”.

[20] Fajardo V. et al., “Diameter Base Protocol”, IETF RFC 6733, October, 2012. [21] ITU-T Recommendation H.248.1, March 2013.

[22] ITU-T Recommendation Q.700, „Introduction to CCITT Signalling System No. 7”, March 1993.

[23] ITU-T Recommendation Q. 701, „Functional description of the message transfer part (MTP) of Signalling System No. 7”, June 1993.

[24] Stewart R., „Stream Control Transmission Protocol”, IETF RFC 4960, Sep-tember 2007.

[25] 3GPP TS 09.02, „Mobile Application Part (MAP) Specification”.

[26] ITU-T Recommendation Q.1901, „Bearer independent call control protocol”, June 2000.

[27] ITU-T Recommendation Q.761, „Signalling system No. 7 – ISDN user part functional description”, December 1999.

[28] 3GPP, „Customized Applications for Mobile network Enhanced Logic (CA-MEL); Service definition (Stage 1)”, 3rd Generation Partnership Project (3GPP), TS 02.78, June 1996.

[29] 3GPP TS 29.198-1: „Open Service Access (OSA); Application Programming Interface (API); Part 1: Overview”.

[30] 3GPP TS 29.228: „IP Multimedia (IM) Subsystem Cx and Dx interfaces; Si-gnalling flows and message contents ”.

[31] Jennings C. et al., „Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks”, IETF RFC-3325, November 2002.

[32] 3GPP TS 24.229: „IP multimedia call control protocol based on Session Ini-tiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3”. [33] http://www.kamailio.org

[34] http://www.wireshark.org

[35] 3GPP TS 24.228, „Signalling flows for the IP multimedia call control based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3”.

Architecture and principle of IP Multimedia Subsystem

Abstract

This paper describes the main idea of IP Multimedia Subsystem, the overview of its architecture, operating principles, basic signalling scenarios and the service provisioning process. The explained concepts are accompanied by an example configuration of the so called „call forward unconditional” supple-mentary voice service deployed on OpenIMSCore platform with support of Kamailio software serving as an application server.