SIGNALIZACE TECHNOLOGIE IP MULTIMEDIA SUBSYSTEM IP MULTIMEDIA SUBSYSTEM TECHNOLOGY SIGNALING

VYSOKÉ UENÍ TECHNICKÉ V BRN BRNO UNIVERSITY OF TECHNOLOGY FAKULTA ELEKTROTECHNIKY A KOMUNIKANÍCH TECHNOLOGIÍ ÚSTAV TELEKOMUNIKACÍ FACULTY OF ELECTRICAL ENGINEERING AND COMMUNICATION DEPARTMENT OF TELECOMMUNICATIONS SIGNALIZACE TECHNOLOGIE IP MULTIMEDIA SUBSYSTEM IP MULTIMEDIA SUBSYSTEM TECHNOLOGY SIGNALING BAKALÁSKÁ PRÁCE BACHELOR S THESIS AUTOR PRÁCE AUTHOR VEDOUCÍ PRÁCE SUPERVISOR MARTIN ECH ING. TOMÁŠ MÁCHA BRNO 2009

VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ Fakulta elektrotechniky a komunikačních technologií Ústav telekomunikací Bakalářská práce bakalářský studijní obor Teleinformatika Student: Martin Čech ID: 78023 Ročník: 3 Akademický rok: 2008/2009 NÁZEV TÉMATU: Signalizace technologie IP Multimedia Subsystem POKYNY PRO VYPRACOVÁNÍ: Cílem práce je prostudovat a popsat technologii IMS (IP Multimedia Subsystem). Zaměřte se především na technické detaily protokolu SIP (Session Initiation Protocol) a jeho použití v IMS. Dále protokoly SDP, RTP (RTCP), Diameter, atd. Vytvořte experimentální síť pomocí programu SDS. Otestujte signalizaci na hovorových službách. Analyzujte kvalitativní parametry těchto služeb. Proveďte analýzu přenášených zpráv. DOPORUČENÁ LITERATURA: [1] POIKSELKA, Miikka, MAYER, Gregor, KHARTABIL, Hisham. The IMS: IP Multimedia Concepts and Services. England : WILEY, 2006. 431 s. Second edition. ISBN 0-470-01906-9. [2] CAMARILLO, Gonzalo, GACÍA-MARTÍN, Miguel A. The 3G IP Multimedia Subsystem (IMS). England : WILEY, 2006. 427 s. Second edition. ISBN 0-470-01818-6. Termín zadání: 9.2.2009 Termín odevzdání: 2.6.2009 Vedoucí práce: Ing. Tomáš Mácha prof. Ing. Kamil Vrba, CSc. Předseda oborové rady UPOZORNĚNÍ: Autor bakalářské práce nesmí při vytváření bakalářské práce porušit autorská práve třetích osob, zejména nesmí zasahovat nedovoleným způsobem do cizích autorských práv osobnostních a musí si být plně vědom následků porušení ustanovení 11 a následujících autorského zákona č. 121/2000 Sb., včetně možných trestněprávních důsledků vyplývajících z ustanovení 152 trestního zákona č. 140/1961 Sb.

ANOTACE Úkolem této bakaláské práce je popsat signalizaci pi komunikaci pomocí technologie IP Multimedia Subsystem. První ást se zamuje na popis samotné technologie, souástí její architektury a používaných protokol. Další ást se zabývá vytváením sít pro testování signalizace bhem hovorových služeb. Tato sí je vytváena pomocí programu Service Development Studio firmy Ericsson. V poslední ásti se hovoí o vytváení a testování klientské aplikace pro instant messaging. Klíová slova: Technologie IMS, protokol SIP, hovorová relace, instant messaging. ABSTRACT Aim of this Bachelor s thesis is to describe singnalization during communication through IP Multimedia Subsystem technology. The first part focuses on describing the technology itself, entities of its architecture and used protocols. Next part deals with creation of a network which will be used for examining signalization during call sessions. This network is created in Ericsson s Service Development Studio environment. The last part discusses development and testing of client application for instant messaging. Keywords: IMS technology, SIP protocol, call session, instant messaging.

Prohlášení Prohlašuji, že svou bakaláskou práci na téma Signalizace technologie IP Multimedia Subsystem jsem vypracoval samostatn pod vedením vedoucího bakaláské práce a s použitím odborné literatury a dalších informaních zdroj, které jsou všechny citovány v práci a uvedeny v seznamu literatury na konci práce. Jako autor uvedené bakaláské práce dále prohlašuji, že v souvislosti s vytvoením této práce jsem neporušil autorská práva tetích osob, zejména jsem nezasáhl nedovoleným zpsobem do cizích autorských práv osobnostních a jsem si pln vdom následk porušení ustanovení 11 a následujících autorského zákona. 121/2000 Sb., vetn možných trestnprávních dsledk vyplývajících z ustanovení 152 trestního zákona. 140/1961 Sb. V Brn dne...... podpis autora

PODKOVÁNÍ Dkuji vedoucímu bakaláské práce Ing. Tomáši Máchovi za velmi užitenou metodickou pomoc a cenné rady pi zpracování bakaláské práce. V Brn dne..(podpis autora)

SEZNAM ZKRATEK AS Auc AUTN AV BGCF BICC CK DNS HLR HSS HTTP I-CSCF IETF IK IMS IP ISIM ISUP LIA LIR MAA MAR MGCF MIME MRFC MRFP MSRP OMA P-CSCF PDF QoS RES Application Server Authentication Center Authentication Token Authentication Vector Breakout Gateway Control Function Bearer Independent Call Control Cyphering Key Domain Name System Home Location Register Home Subscriber Server Hypertext Transfer Protocol Interrogating Call Session Control Function Internet Engineering Task Force Integrity Key IP Multimedia Subsystem Internet Protocol IP Multimedia Service Identity Module ISDN User Part Location Info Answer Location Info Request Multimedia Auth Answer Multimedia Auth Request Multimedia Gateway Control Function Multipurpose Internet Mail Extension Multimedia Resource Function Controller Multimedia Resource Function Processor Message Session Relay Protocol Open Mobile Alliance Proxy Call Session Control Function Policy Decision Function Quality of Service Result

RTA Registration Termination Answer RTCP Real-time Transport Control Protocol RTP Real-time Transport Protocol RTR Registration Termination Request SAA Server Assignment Answer SAR Server Assignment Request S-CSCF Servin Call Session Control Function SCTP Stream Control Transmission Protocol SDP Session Description Protocol SGW Signaling Gateway SIP Session Initiation Protocol SLF Subscription Locator Function SMTP Simple Mail Transfer Protocol SS7 Signaling System No. 7 TCP Transmission Control Protocol TLS Transport Layer Security UA User Agent UAA User Authorization Answer UAC User Agent Client UAR User Authorization Request UAS User Agent Server UDP User Datagram Protocol URI Uniform Resource Identifier XRES Exepcted Result

SEZNAM OBRÁZK...- 9 - ÚVOD... - 10 - ARCHITEKTURA IMS... - 11-1.1 BLOK ÍDÍCÍCH FUNKCÍ VOLÁNÍ A RELACÍ...- 11-1.1.1 P-CSCF... - 11-1.1.2 I-CSCF... - 12-1.1.3 S-CSCF... - 12-1.2 DATABÁZE...- 13-1.2.1 HSS... - 13-1.2.2 SLF... - 13-1.3 SLUŽEBNÍ FUNKCE...- 13-1.3.1 MRFC... - 13-1.3.2 MRFP... - 14-1.3.3 AS... - 14-1.4 MEZISÍOVÉ FUNKCE...- 14-1.4.1 MGCF... - 14-1.4.2 SGW... - 14-1.4.3 IMS-MGW... - 14-1.4.4 BGCF... - 15-1.5 PODPRNÉ FUNKCE...- 15-1.5.1 PDF... - 15-2 PROTOKOLY VYUŽÍVANÉ V IMS... - 16-2.1 SIP...- 16-2.1.1 Adresace... - 17-2.1.2 Prvky SIP... - 17-2.2 SDP...- 18-2.3 RTP...- 18-2.4 DIAMETER...- 19-3 REGISTRACE DO IMS... - 20-3.1 TYPY REGISTRACÍ...- 20-3.1.1 Identifikaní Moduly... - 20-3.2 REGISTRACE POMOCÍ ISIM...- 21-4 RELACE V IMS... - 24-4.1 TYPY RELACÍ...- 24-4.1.1 Hovor smuje mimo IMS... - 24-4.1.2 Hovor smuje do IMS... - 24-4.2 USTAVENÍ RELACE...- 24-5 SDS (SERVICE DEVELOPMENT STUDIO)... - 28-5.1 VÝVOJOVÉ PROSTEDÍ...- 28-5.1.1 Development Perspective... - 28-5.1.2 Provisioning Perspective... - 28-5.1.3 Visual Network Perspective... - 28-5.1.4 Automated Testing Framework Perspective... - 29 -

5.1.5 Visual Traffic Flow Perspective... - 29-5.2 IMS CLIENT PLATFORM (ICP)...- 29-6 VYTVOENÍ EXPERIMENTÁLNÍ SÍT... - 30-6.1 NASTAVENÍ NA PC1...- 30-6.1.1 Okno Preferences... - 30-6.1.2 Okno Provisionning... - 30-6.1.3 Nastavení ICP... - 30-6.2 NASTAVENÍ NA PC2...- 31-6.2.1 Nastavení ICP Symbian... - 31-6.3 SPUŠTNÍ SIMULÁTOR...- 32-6.4 REALIZACE HOVORU...- 33-7 IMS-M SIMULÁTOR... - 36-7.1 ONE-TO-ONE INSTANT MESSAGE...- 36-7.2 ONE-TO-ONE INSTANT MULTIMEDIA MESSAGE...- 36-7.3 ONE-TO-ONE IMS-M SE ZPOŽDNÝM DORUENÍM...- 37-7.4 ONE-TO-MANY MESSAGE...- 37-7.5 ONE-TO-ONE CHAT...- 37-8 IMSM KLIENT... - 38-8.1 INICIALIZACE...- 38-8.2 VYTVOENÍ ZPRÁVY...- 38-8.3 ZPRACOVÁNÍ ZPRÁVY...- 39-8.4 GUI...- 40-8.5 ODESLÁNÍ ZPRÁVY...- 41-9 ZÁVR... - 43 - SEZNAM POUŽITÉ LITERATURY... - 44 - SEZNAM PÍLOH... - 45 -

SEZNAM OBRÁZK OBR.1 ARCHITEKTURA IMS...- 12 - OBR.2 PROTOKOLY VYUŽÍVANÉ V IMS...- 16 - OBR.3.1 ZPRÁVA REGISTER...- 21 - OBR.3.2 SIGNALIZACE BHEM REGISTRACE...- 23 - OBR.4.1 ZPRÁVA INVITE...- 25 - OBR.4.2 SIGNALIZACE BHEM NAVAZOVÁNÍ RELACE...- 27 - OBR.6.1 NASTAVENÍ ICP...- 31 - OBR.6.2 NASTAVENI ICP SYMBIAN...- 32 - OBR.6.3 REGISTRACE UŽIVATELE...- 32 - OBR.6.4 INVITE...- 33 - OBR.6.5 VOIP RELACE...- 35 - OBR.8.1 ROZHRANÍ APLIKACE IMSM KLIENT...- 40 - OBR.8.2 INVITE IMS MESSAGE...- 41 - OBR.8.3 ODESLÁNÍ ZPRÁVY...- 42 -

ÚVOD Technologie IMS (IP Multimedia Subsystem) je vyvíjena jako architektura, která je postavena na protokolu IP a bez ohledu na metodu pístupu umožní koncovým uživatelm využívání rzných multimediálních služeb [1]. Mezi tyto služby patí napíklad služba Presence, Push to talk, VoIP, Instant messaging nebo streamování videa. Úkolem technologie IMS je poskytnout tyto služby co nejvtšímu potu uživatel bez ohledu na to, jakou využívají sí a obohatit tak možnosti jejich vzájemné komunikace. Poskytuje také vtší míru zabezpeení než nap. bžné VoIP a podporuje pokroilé ízení pidlování síových prostedk. Poátek vývoje této technologie spadá do roku 1999, kdy byla založena skupina 3GPP (Third Generation Partnership Program). Ta dostala za úkol vydávat a spravovat soubory specifikací pro sít tetí generace (GPRS/UMTS). Tyto soubory zveejuje každoron formou tzv. Release. První specifikace technologie IMS byla uvedena v Release 5 z roku 2002 a dále byla rozšíena a upravena v Release 6 a 7. V první kapitole své práce se budu vnovat architektue technologie IMS a blíže se seznámím s funkcí jednotlivých entit, které jsou bu pímou souástí architektury, nebo s ní úzce souvisí. V následující ásti popíšu dležité protokoly, které se vztahují k technologii IMS. Zejména se zamím na signalizaní protokol SIP, který v celé problematice hraje velmi dležitou roli. Poté se budu detailnji zabývat popisem jednotlivých procedur, konkrétn samotné registrace a vytvoení relace. Zde se zamím pedevším na probíhající signalizaci, smrování a tvar zpráv, které jsou v prbhu tchto procedur vymovány. V dalších kapitolách se seznámím s programem Service Development Studio, který budu používat pro vytvoení experimentální sít a pro testování VoIP komunikace. Po uskutenní hovoru budu analyzovat reálné SIP zprávy penášené bhem hovorové relace. Poté vytvoím aplikaci, která bude fungovat jako klient pro instant messaging, popíšu princip jeho innosti a ovím správnou funknost.

ARCHITEKTURA IMS Architektura IMS je souborem funkcí propojených pes standardizovaná rozhraní [2]. Zaízení potebná k zajištní pístupu do sít nejsou souástí architektury. Z hlediska IMS nezáleží, pomocí jaké sít je zajištn pístup uživatele, protože implementuje funkce pro peklad signalizace z jiných sítí na signalizaci využívanou v síti IMS. Skládá se z nkolika blok sdružujících entity s podobnou úlohou. Obsahuje blok ídících funkcí volání a relací, databáze, služební, ídící a pomocné funkce. Jejich innost bude vysvtlena dále v textu. 1.1 Blok ídících funkcí volání a relací Funkce ídící volání a relace hrají významnou roli bhem registrace a ustavování relace a zajišují v síti smrování signalizace. Uchovávají informace o probíhajících relacích a všech registrovaných úastnících. Generují a zasílají data pro vyútování. V IMS jsou definovány ti tyto ídící funkce, každá z nich plní v rámci sít speciální úlohu. Mohou být implementovány v jediném uzlu, ale z hlediska bezpenosti je výhodnjší, když fungují oddlen [3]. 1.1.1 P-CSCF(Proxy Call Session Control Function) Je v signalizaní rovin prvním pístupovým bodem do IMS (Obr.1). Veškerá SIP signalizace z uživatelských zaízení pichází do sít IMS pes P-CSCF a naopak signalizace ze sít je zpt do uživatelských zaízení zasílána opt pes P-CSCF [1]. Dále tato funkce musí zaruit, že zaízení pistupující do sít je zaregistrováno a je mu umožnn pístup. Zajišuje také základní smrování žádostí a odpovdí. Pro zmenšení objemu penášených signalizaních dat a urychlení ustavování relací zde probíhá komprese a dekomprese SIP zpráv vymovaných mezi IMS sítí a terminálem. Dalším úkolem P-CSCF je kontrola identity a dvryhodnosti uživatele a zabránní neautorizovaného pístupu. P-CSCF také spolupracuje s PDF(Policy Decision Function) pi pidlování síových prostedk a generování dat pro vyútování.

1.1.2 I-CSCF (Interrogating Call Session Control Function) Slouží jako brána do každé individuální IMS sít (Obr.1) a mže být použita ke skrytí detail o síti ped ostatními operátory (odstranním uritých hlaviek SIP zpráv) [2]. Pomáhá chránit S-CSCF a servery uchovávající data o uživatelích ped neoprávnným pístupem z jiných sítí, mže být považována za firewall sítí IMS. Dležitým úkolem této funkce je pidlování S-CSCF uživatelm. O pidlení rozhoduje bu podle podporovaných služeb nebo podle geografické polohy S-CSCF [1]. Potebné informace získává dotazováním na HSS. 1.1.3 S-CSCF (Serving Call Session Control Function) Je centrálním bodem IMS (Obr.1). Z pohledu protokolu SIP je to registrar zodpovdný za ízení procesu registrace a autentifikace všech úastník, kteí se pokoušejí registrovat do sít. Registrovaným úastníkm povoluje využívání služeb a umožuje pístup k rzným aplikaním serverm. Kontroluje zasílání zpráv a doruování obsahu. Poskytuje ostatním aplikacím informace o stavu registrace úastníka a udržuje kontrolu nad pidlenými službami po dobu trvání registrace úastníka. Informace o úastnících ukládá na HSS. Obr.1 Architektura IMS

1.2 Databáze Architektura IMS obsahuje dv hlavní databáze. Centrální zdroj uživatelských dat (HSS) a funkci, která pomáhá umístní tchto dat v síti lokalizovat (SLF). 1.2.1 HSS (Home Subscriber Server) Je hlavní úložišt dat o úastnících a službách (Obr.1). Uchovává informace o tom, jaké služby je úastník oprávnn používat, do jakých sítí je oprávnn pistupovat. Ukládá veejné a privátní identity úastník. Uchovává také šifrovací a autentifikaní klíe úastník. Pi každé zmn zasílá všechna data o uživateli do S-CSCF, za úelem jejich pepsání aktuálními. Výhodou HSS je schopnost spravovat více identit pro jedno pihlášení [1]. Bhem registrace sem pistupuje S-CSCF a stahuje si uživatelský profil. Obsahuje také HLR/Auc. Home Location Rregister umožuje spolupráci s prvky paketov i okruhov spínaných sítí a díky tomu je uživatel schopen do tchto sítí pistupovat. AuC uchovává bezpenostní klíe mobilních uživatel. 1.2.2 SLF (Subscription Locator Function) Mže být souástí jiné funkce nebo fungovat jako samostatný server. V pípad pítomnosti více úložiš uživatelských dat se ídící funkce a servery aplikací této funkce dotazují na adresu serveru, který ukládá informace o konkrétním uživateli (Obr.1). 1.3 Služební funkce Služební funkce zajišují obsluhu a ízení multimediálních tok a poskytování aplikaních služeb. Do skupiny tchto funkcí patí rzné aplikaní servery, procesor a kontroler funkcí zdroje multimédií. 1.3.1 MRFC (Multimedia Resource Function Controller) V signalizaní rovin ídí SIP komunikaci proudící do a z S-CSCF (Obr.1) a kontroluje innost MRFP. Umožuje vytváení statistik o mediálních tocích. S procesorem je spojen pes rozhraní H.284 [2].

1.3.2 MRFP (Multimedia Resource Function Processor) V uživatelské rovin provádí zpracování a konverzi multimediálních tok. V pípad více zdroj tchto tok uskuteuje jejich slouení. Mže také provádt analýzu médií (Obr.1). 1.3.3 AS (Application Server) Je víceúelová funkce poskytující aplikaní služby. Není souástí jádra IMS. Je pímo propojen s rznými funkcemi ízení volání a relací a komunikuje s nimi pomocí protokol SIP a DIAMETER (Obr.1). Mže se chovat i jako SIP user agent. 1.4 Mezisíové funkce Mezisíové funkce zajišují komunikaci mezi rznými doménami a peklad signalizaních a komunikaních protokol. 1.4.1 MGCF (Multimedia Gateway Control Function) Není skutenou souástí IMS. Zajišuje propojení mezi doménou pepínání okruh a doménou pepínání paket. Hovory pocházející z domény pepínání okruh jsou smrovány na tuto funkci, která na aplikaní vrstv provede peklad zpráv ISUP/ BICC na zprávy SIP a odešle je na P-CSCF (Obr.1). 1.4.2 SGW (Signalling Gateway) Provádí na transportní vrstv obousmrnou konverzi signalizace mezi signalizací založenou na IP a signalizací založenou na SS7 (Obr.1). Úkolem SGW není pekládat zprávy na aplikaní vrstv. 1.4.3 IMS-MGW (IMS Media Gateway) Je ízena MGCF (Obr.1). Poskytuje na uživatelské rovin spojení mezi IMS a sítmi pepínání okruh. Zakonuje penosové kanály ze sítí s pepínáním okruh a provádí potebné zpracování penášené signalizace. Pracuje také jako generátor tón.

1.4.4 BGCF (Breakout Gateway Control Function) Vybírá bod pestupu do sít pepínání okruh (Obr.1). Pokud pestup nastane ve stejné síti BGCF zvolí MGCF pro další ízení relace. Pokud nastane pestup v jiné síti je relace smrována na BGCF v této síti. 1.5 Podprné funkce Podprné funkce umožují operátorm stanovovat pro úastníky pravidla využívání sít. Nkteré z tchto funkcí umožují také aplikovat rzné bezpenostní mechanismy. 1.5.1 PDF(Policy Decision Function) Na základ informací zasílaných z P-CSCF (Obr.1) ídí pidlování síových prostedk. Obsahuje funkce pro generování informací pro vyútování.

2 PROTOKOLY VYUŽÍVANÉ V IMS Protokol je sada pravidel, která definuje význam zpráv vymovaných pi komunikaci mezi dvma nebo více entitami. Dležitými prvky protokolu jsou syntax, sémantika a synchronizace. Syntax uruje formáty dat a významy znak. Sémantika obsahuje informace pro ízení tok dat a opravy chyb. Synchronizace zajišuje asování. V IMS jsou využívány protokoly aplikaní vrstvy pro ízení, popis a správu relací jako SIP, SDP nebo RTP. Pro penos vlastní signalizace jsou použity protokoly transportní vrstvy UDP a TCP (Obr.2). Obr.2 Protokoly využívané v IMS 2.1 SIP (Session Initiation Protocol) Je protokol aplikaní vrstvy používaný pro vybudování, úpravu a ukonení multimediálních relací v IP sítích. Je souástí architektury, jejíž protokoly jsou neustále standardizovány organizaci IETF. Jeho použití zasahuje do oblastí penosu hlasu, videa, síového hraní, instant messaging, kontroly hovor a služby presence [1]. Je to textový protokol využívající principy protokolu HTTP a poštovním protokolu SMTP. Je schopný pracovat jak nad protokolem UDP, tak nad protokolem TCP. Funguje na bázi klient-server a ke komunikaci používá dva druhy zpráv, žádosti a odpovdi. Nejastjší typy žádostí: INVITE-žádost o vytvoení relace, ACK-potvrzuje pijetí odpovdi na žádost INVITE, BYE-žádost o ukonení relace, CANCEL-žádost o ukonení jiné nevyízené žádosti,

REGISTER-žádost o registraci klienta u SIP serveru, SUBSCRIBE-pihlášení k odbru informací, PRACK-potvrzeni doasné (1xx) odpovdi, NOTIFY-zveejování informací, MESSAGE- penáší zprávy, PUBLISH-nahrává na server uživatelv status. Odpovdi se dlí do rzných kategorií podle jejich kódu: 1xx: doasné/informaní, 2xx: požadavek pijat, 3xx: pesmrování, 4xx: chyba na stran klienta, 5xx: chyba na stran serveru, 6xx: globální chyba. Každá zpráva protokolu SIP je tvoena hlavikou (header) a vlastním obsahem (body). První ádek identifikuje její typ. Zprávy SIP se využívají k penosu popisu parametr relace, tento popis je uložen uvnit dokument využívajících protokolu SDP [4]. 2.1.1 Adresace Jednotlivé entity jsou identifikovány pomocí SIP URI (Uniform Resource Identifier). SIP URI má tvar sip: [user_name]@[host_name][:port][-parameters], velmi podobný e-mailové adrese. Pokud není uvedeno íslo portu, pedpokládá se použití portu 5060. URI mže mít i tvar telefonního ísla. 2.1.2 Prvky SIP User Agent: Proxy Server: Je koncové zaízení sít, vtšinou HW nebo SW SIP telefon, PDA apod. V UA je vtšinou implementován jak UAS (User Agent Server), který pijímá žádosti a odesílá na n odpovdi, tak UAC (User Agent Client), který žádosti vysílá. Úlohou proxy serveru je smrovat žádosti o sestavení spojení od UA nebo jiného proxy. Tyto žádosti mže smrovat bu pímo volanému (zná-li jeho umístní) nebo na další proxy (blíž volanému).

Redirect Server: Registrar Server: Zajišuje smrování žádostí. Zjišuje v registrar serveru aktuální umístní UA a v odpovdi o nm informuje odesílatele požadavku, který poté na toto umístní zasílá svoji žádost. Pijímá žádosti o registraci a ukládá do databáze lokalizace všech UA v domén. 2.2 SDP (Session Description Protocol) Je protokol aplikaní vrstvy urený k popisu multimediálních relací. Podobn jako SIP je i tento protokol textov orientovaný. Každá zpráva obsahuje nkolik povinných a volitelných údaj [1]: Popis relace: v- verze protokolu, o- pvod a identifikátor relace, s- název relace, c- informace o spojení, b- informace o šíce pásma, k- šifrovací klí. Popis asu: t- informace o délce relace, r- as opakování. Popis média: m- název média a transportní adresa, k- šifrovací klí, a- atributy média. 2.3 RTP (Real-time Transport Protocol) RTP definuje standardní formát paket pro doruování hlasových a obrazových dat v reálném ase po internetu. Protokol samotný data nepenáší, zajišuje pouze jejich rekonstrukci na stran píjemce. Parametry protokolu RTP [5]: V (Version)- oznauje verzi protokolu RTP, P (Padding)- indikuje doplkové slabiky, X (Extension)- indikuje rozšíení hlaviky RTP, CC (Contributin Source count)- poet zdroj dat, M (Marker)- doplkový bit, PT (Payload type)- formát penášených dat (kodek),

SN (Sequence number)- íslo paketu, využívá píjemce ke zjištní poadí píchozích paket, TS (Time stamp)- asová znaka, používá se k odstranní jitter, SSRC (Synchronization source)- identifikace zdroje paket, CSRC (Contributing source list)- seznam zdroj dat, DATA- data. RTCP je protokol urený k monitorování vlastností spojení. Jeho úkolem je poskytovat zptnou vazbu na QoS. 2.4 DIAMETER Je autentizaní, autorizaní a útovací protokol vyvinutý organizací IETF. Jeho pedchdcem je protokol RADIUS. Vlastní protokol lze rozdlit na základní protokol a jeho aplikace (protokoly založené na Diameteru). Základní protokol je zodpovdný za doruování datových jednotek, vyjednávání zpsobilosti, ešení chyb a poskytování rozšiitelnosti. Pro penos využívá protokoly TCP a SCTP a pro zabezpeení spojení protokoly IPsec a TLS. Aplikace rozšiují základní protokol pidáním nových píkaz. Každá aplikace je definována zvláš. Pro oblast IMS je dležitá aplikace DIAMETER SIP, která SIP serveru umožuje autentifikovat uživatele a autorizovat ho k použití rzných prostedk SIP. Definuje nkolik píkaz rozšiujících základní protokol Diameter [1]: UAR/UAA urují, zda je uživatel autorizován k vyžívání urité služby pokud ano, ukazují na server schopný tuto službu poskytnout, SAR/SAA piadí uživateli specifický server a doruí na nj uživatelský profil, LIR/LIA zjišuje adresu S-CSCF pidlené uživateli, MAR/MAA autentifikuje a autorizuje uživatele pro uritou službu, RTR/RTA odregistrování ze strany Diameter serveru.

3 REGISTRACE DO IMS Registrace do IMS je procedura, pi které si uživatel vyžádá autorizaci pro využívání služeb IMS sít. Registrace probíhá pomocí protokolu SIP konkrétn žádostí REGISTER a odpovdí na n [2]. 3.1 Typy Registrací Procedury registrace se rzní podle typu sít, pomocí které terminál získává pístup do IMS. Terminál mže využívat jak drátové (DSL, Dial-up) tak bezdrátové (GPRS, WLAN) linky. V pípad využití GPRS pipojení získává terminál svojí IP adresu a adresu P-CSCF bhem procedury Activate PDP Context. V ostatních pípadech probhne konfigurace terminálu pomocí DHCP. 3.1.1 Identifikaní Moduly Vlastní registrace do IMS se liší podle vlastností terminálu, konkrétn aplikace, ve které terminál uchovává identifikaní údaje. Pro pístup do IMS lze využít dv tyto aplikace. ISIM (IP multimedia Service Identity Module) obsahuje sadu parametr potebných k autentifikaci a autorizaci v IMS [2]. Privátní identita je jedinený identifikátor uživatele. Veejné identity jsou ekvivalentem telefonních ísel. URI domácí sít se používá k nalezení adresy domácí sít. Registrace pomocí ISIM je podrobn popsána dále v textu. USIM (Universal Subscriber Identity Module) uchovává informace potebné pro využívání sítí tetí generace [2]. IMSI je identita pidlená uživateli. Je viditelná pouze sítí, která ji využívá pro autentifikaci. MSISDN uchovává telefonní ísla uživatele. CK a IK jsou klíe zajišující šifrování a kontrolu integrity. Pro úely registrace do IMS mže terminál pomocí IMSI vytvoit doasnou privátní identitu, veejnou identitu a URI domácí sít. Tyto parametry poté využije k sestavení žádosti REGISTER.

3.2 Registrace pomocí ISIM Ve chvíli, kdy terminál získá pístup do IP sít, obdrží IP adresu a nalezne adresu P-CSCF, mže zapoít jeho registrace do IMS. 1) Terminál nejprve nate z ISIM (IP Multimedia Service Identity Module) privátní identitu, veejnou identitu a URI domácí sít. Poté zane vytváet první žádost REGISTER (Obr.3.1), která obsahuje nkolik parametr [4]: URI žádosti: Via: Route: From: To: Contact: Authorization: Call-ID: Content-Length: místo urení, v tomto pípad domácí sí, adresa terminálu, dležitá pro doruení odpovdi, adresa P-CSCF, kdo provádí registraci, veejná identita (chceme zaregistrovat), adresa, na které bude veejná identita k dosažení, v parametru username je obsažena privátní identita, jedinený identifikátor spojení, velikost obsahu. Obr.3.1 Zpráva REGISTER Žádost REGISTER v takovémto tvaru odešle terminál do P-CSCF. 2) V tuto chvíli není ješt terminál oven a komunikuje s P-CSCF pes nezabezpeené spojení. P-CSCF posílá žádost na další prvek. Dotazem na DNS získá adresu I-CSCF v domácí síti uživatele a odešle na ní žádost. Ješt ped

odesláním ale odstraní vlastní záznam z hlaviky Route a pidá svojí adresu na první místo do hlaviky Via. Aby zajistilo, že veškerá signalizace urená terminálu projde pes P-CSCF, pidává do každé žádosti REGISTER svoji adresu uloženou v hlavice Path. 3) Když I-CSCF obdrží žádost, potebuje zjistit, zda již má uživatel pidleno njaké S-CSCF. Zašle proto dotaz (Diameter UAR) na HSS (Obr.3.2). HSS odpoví (Diameter UAA), a pokud uživateli zatím žádné S-CSCF pidleno nebylo, zahrne do odpovdi také parametry pro jeho výbr. 4) I-CSCF pidá svojí adresu na první místo v hlavice Via, do hlaviky Route zapíše adresu pidleného S-CSCF a zprávu odešle (Obr.3.2). 5) S-CSCF potebuje získat z HSS data pro ovení uživatele. Na základ privátní identity vytvoí žádost (Diameter MAR) pro HSS, které mu odpoví (Diameter MAA) a do odpovdi zahrne i AV (Authentication Vector), který obsahuje parametry pro ovení uživatele (Obr.3.2). 6) S-CSCF odešle zpt zprávu 401(Unauthorized), která obsahuje i AV. 8) P-CSCF z této zprávy vyjme IK(Integrity Key) a CK(Cyphering Key) a uloží si je do pamti. Upravenou zprávu pošle na terminál (Obr.3.2). 9) Terminál pedá parametry AV ze zprávy aplikaci ISIM, která na jejich základ vygeneruje odpov (RES) pro S-CSCF a nakonec spoítá také IK, který bude využívat jako sdílený klí pro bezpenou komunikaci s P-CSCF (Obr.3.2). 10, 11, 12) Terminál odešle druhou žádost REGISTER, ve které uvede i RES. 13) S-CSCF porovná pijatou RES s oekávanou (XRES) získanou z HSS a pokud se shodují, je uživatel úspšn oven. S-CSCF zasílá zprávu (Diameter SAR) na HSS, ve které ho informuje o úspšné registraci uživatele a zárove si stáhne uživatelv profil.

14) S-CSCF odešle na terminál odpov 200(OK). Odpov bude obsahovat hlaviku Service-Route, do které S-CSCF uložilo svojí adresu. Terminál si tuto adresu uloží a píští žádost již nebude muset procházet pes I-CSCF (Obr.3.2). Obr.3.2 Signalizace bhem registrace

4 RELACE V IMS Relace mže mít formu jakékoliv komunikace mezi terminály. Mže jít o hlasovou i video komunikaci, ale také instant messaging, zasílání e-mail nebo síové hraní. Pokud je pi komunikaci využito více typ médií, sestává také hovor z více relací, takže napíklad videohovor obsahuje zvláš relaci pro video a zvláš pro hlas. 4.1 Typy Relací Podobn jako v pípad registrace se i navazování relace liší podle sít, ze které pochází požadavek na vytvoení relace. Jinak vypadá procedura pro požadavky pocházející z IMS a jinak pro požadavky nap. ze sítí využívajících signalizaci SS7. 4.1.1 Hovor smuje mimo IMS Pokud S-CSCF obdrží zprávu INVITE pro uživatele, který se nachází mimo doménu IMS, pedá ji BGCF. Úkolem této funkce je, rozhodnout jak žádost dále smrovat. Pokud se adresát nachází ve stejné síti, smuje žádost na MGCF, která zajistí spojení s doménou SS7. Pokud se adresát nachází v jiné síti, je žádost pesmrována na BGCF v této síti [3]. 4.1.2 Hovor smuje do IMS Pokud MGCF obdrží zprávu (Initial Adress Message) z domény SS7 pevede ji na zprávu INVITE [1]. Zárove také zmní telefonní íslo uživatele na SIP URI, ímž umožní smrování v IMS. Poté již žádost odešle podle poteby na I-CSCF (adresát se nachází ve stejné síti) nebo BGCF (adresát se nachází v jiné síti). 4.2 Ustavení Relace V následující ásti podrobnji popíšu co se dje pi navazování relace v situaci kdy je jak terminál A tak terminál B již úspšn registrován ve vlastní IMS síti. Hovor bude iniciován ze strany terminálu A. 1) Pro zahájení komunikace vytvoí Terminál A žádost INVITE (Obr.4.1) a odešle ji na P-CSCF

Obr.4.1 Zpráva INVITE P-Preffered-Identity je nepovinná položka, jejíž hodnota udává registrovanou privátní identitu uživatele. P-Asserted-Identity slouží bhem celého dialogu jako hlavní identifikátor uživatele. íslo 1357 v hlavice Via udává íslo portu zabezpeeného spojení mezi terminálem a P-CSCF. 2) P-CSCF oví, zda žádost obdržela pes zabezpeené spojení. Pokud ne, zamítne ji. Poté porovná hodnotu z hlaviky P-Preferred-Identity s identitou uživatele, od kterého obdržela žádost. Pokud se shodují, nahradí P-Preferred-Identity hlavikou P-Asserted-Identity, do které uloží pvodní hodnotu. V pípad, že se neshodují nebo v žádosti hlavika P-Preferred-Identity nebyla, uloží do P-Asserted-Identity hodnotu defaultní registrované identity uživatele. Nakonec odstraní vlastní záznam z Route, pidá vlastní záznam do Record-Route a Via (bez ísla portu) a odešle žádost na S- CSCF (Obr.4.2). 3) S-CSCF identifikuje uživatele na základ informací z hlaviky P-Asserted- Identity. Následn zkontroluje stav jeho registrace a mže do této hlaviky pidat další URI. Následn odstraní vlastní záznam z Route, pidá vlastní záznam do Record-Route a Via a dotazem na DNS zjistí adresu I-CSCF v síti volaného

Ped odesláním oví, že sí volaného je dvryhodná (pokud ano nemusí odstraovat P-Asserted-Identity) a žádost odešle (Obr.4.2). 4) I-CSCF odstraní vlastní záznam z Route a pidá vlastní záznam do Via. Z HSS zjistí adresu S-CSCF pidleného volanému a žádost na ní odešle (Obr.4.2). 5) S-CSCF odstraní vlastní záznam z Route, pidá vlastní záznam do Record- Route, zkontroluje stav registrace volaného a nahradí SIP URI uživatele adresou, kterou si volaný registroval. Nakonec do Route uloží cestu k uživateli B a žádost odešle (Obr.4.2). 6) P-CSCF na stran volaného zkontroluje hodnotu Private v žádosti. V našem pípad není nastavena, tudíž mže žádost peposlat i s položkou P-Asserted- Identity. Pes zabezpeené spojení odešle žádost na terminál volaného (Obr.4.2). 7) Terminál B vytvoí odpov 183 (Session Progress), ve které do hlaviky Contact uloží vlastní adresu vetn ísla bezpeného portu, a odešle ji na adresu podle prvního záznamu z hlaviky Via (Obr.4.2). 13) Terminál A vytvoí a odešle žádost PRACK, kterou potvrzuje odpov 183 (Obr.4.2). Souástí první žádosti INVITE byl i první návrh protokolu SDP, ímž zapoalo vyjednávání o vlastnostech penosu. V této zpráv terminál A zasílá terminálu B seznam všech typ médií a všech kodek, které bude chtít bhem relace využít. Terminál B vložil svou SDP odpov (seznam podporovaných médií a kodek) do SIP zprávy 183 (Session Progress). Zprávy s kódem 1xx jsou doruovány nespolehliv, proto bylo nutné do pvodní žádosti INVITE vložit hlaviku Supported: 100rel, která zaruí, že i doasná zpráva (1xx) bude doruena spolehliv. Ve zpráv PRACK (potvrzuje doruení 1xx zprávy) sdluje terminál A jaký kodek bude použit pro jaké médium. 14) Odpov OK terminálu B potvrzuje souhlas s vyjednanými parametry penosu.

15) Oba terminály jsou nyní ve fázi, kdy si rezervují prostedky potebné k uskutenní hovoru. Když si terminál A vyhradí dostatené množství prostedk, informuje o tom terminál B pomocí žádosti UPDATE (Obr.4.2). 16) Terminál B odpovídá 200 (OK) a po úspšné rezervaci prostedk zaíná vyzvánt, o emž informuje volajícího zprávou 180 (Ringing) (Obr.4.2). 17) Pijmutí hovoru signalizuje terminál B zasláním odpovdi 200 (OK) (Obr.4.2). Obr.4.2 Signalizace bhem navazování relace

5 SDS (Service Development Studio) SDS je program, vyvíjený spoleností Ericsson, urený pro návrh a testování jak klientských tak serverových aplikací využívajících služeb technologie IMS. Umožuje v tchto aplikacích využívání pokroilých služeb jako Presence, Push to talk, Voice over IP, IP Television nebo IMS Messaging. SDS obsahuje simulátor základní IMS sít a jejích služeb. Umožuje emulaci ídících funkcí volání a relací, databázových a mezisíových funkcí. Pro testování serverových aplikací poskytuje nkolik aplikaních server. Klientské aplikace lze otestovat bu pímo v prostedí Windows, nebo na nkterém z emulovaných telefon s operaním systémem Symbian. SDS podporuje vývoj aplikací podle specifikací JSR 116 a JSR 289. 5.1 Vývojové prostedí Vývojové prostedí je založeno na platform Eclipse IDE. Je rozdleno do nkolika perspektiv. Každá perspektiva definuje soubor a rozložení pohled v pracovním okn. Podle specifických funkcí podporovaných v jednotlivých perspektivách se dlí na nkolik druh. 5.1.1 Development Perspective Tato perspektiva obsahuje souásti JDT (Java Development Tool) a soubor funkcí urených pro práci s java projekty. Zde probíhá samotný vývoj klientských a serverových aplikací. 5.1.2 Provisioning Perspective Tato perspektiva je urena pro obsluhu uzl simulované sít. V sekci DNS umožuje ízení hovorových relací piazováním doménových názv, telefoních ísel, IP adres a transportních protokol. Dále vytváení a správu uživatelských, služebních, a PSI profil. Vytváejí a upravují se zde kritéria pro smrování žádostí na rzné aplikaní servery a realizaci služeb. Zobrazuje informace o stavu registrací uživatel. 5.1.3 Visual Network Perspective Tato perspektiva umožuje grafické zobrazení simulovaného prostedí (CSCF, DNS, PoC Server, Symbian Emulator) a stav jednotlivých ástí. Pomocí tohoto

grafického rozhraní lze rychle pistupovat k jednotlivým uzlm, zjišovat a mnit jejich konfiguraci. 5.1.4 Automated Testing Framework Perspective Se využívá k vytváení a spouštní testovacích skript, které umožují simulovat chování klientské aplikace. Obsahuje také testovacího agenta pro SIP, pomocí kterého lze vytváet a odesílat reálné SIP zprávy a tím testovat chování jednotlivých uzl. 5.1.5 Visual Traffic Flow Perspective Zde se zobrazují sekvenní diagramy SIP komunikace procházející pes CSCF. Umožuje v reálném ase sledovat smrování a formát SIP zpráv. Je zde možné nastavovat pravidla pro filtrování zobrazovaných zpráv, nebo sledování specifické komunikace. 5.2 IMS Client Platform (ICP) ICP je služba urená ke spouštní klientských aplikací pro operaní systémy Windows a Symbian. Tato služba bží na pozadí systému a funguje jako user agent pro všechny klienty IMS. ICP poskytuje spolenou platformu všem klientm vytvoeným pomocí SDS a podporuje všechny základní služby a protokoly IMS. Mže fungovat jak v simulované tak v reálné IMS síti.

6 Vytvoení experimentální sít Experimentální sí sestává ze dvou poíta s operním systémem Windows XP Professional s nainstalovanými aktualizacemi Service Pack 3. Na obou stanicích je kompletn nainstalováno prostedí SDS. První poíta bude hostit simulované prostedí sít IMS a VoIP klienta pro Windows. Na druhém poítai bude klientská aplikace spuštna na emulovaném mobilním telefonu se systémem Symbian ve verzi S60. 6.1 Nastavení na PC1 Na tomto poítai bude spuštn SIP server, DNS Server a všechny ídící funkce, a proto je teba v programu SDS zmnit uritá nastavení. 6.1.1 Okno Preferences V záložce CSCF na kart Server okna Preferences jsem zmnil adresu DNS serveru na hodnotu IP adresy síového rozhraní, port i doména zstávají pvodní. V záložce transport je teba u všech tí ídících funkcí adresu localhost zmnit na stejnou hodnotu jako v pípad nastavení DNS serveru. 6.1.2 Okno Provisionning Na záložce DNS jsem upravil záznam pro URI sip:imsm.ericsson.com opt na IP adresu síového rozhraní. V záložce HSS jsem vytvol nový služební profil TestProfile obsahující filtraní kritéria pro IMSM. Poté jsem vytvoil dva nové uživatelské profily user1 a user2 pro doménu ericsson.com a obma jsem piadil služební profil TestProfile. 6.1.3 Nastavení ICP V ovládacích panelech je teba spustit IMSSettings. V záložce Profile Manager se konfiguruje profil IMS Setting (Obr.6.1). Pokud je v záložce IMS Attach Mode zatržena možnost PowerOnMode, mže se ICP registrovat do IMS sít automaticky. V záložce Network je poteba defaultn nastavený loopback adapter zmnit na reálnou síovou kartu instalovanou v poítai. V záložce UserProfile jsem vyplnil veejnou a privátní identitu a pihlašovací heslo uživatele, kterého chci zaregistrovat (user1). Záložka Service Root Path obsahuje cestu k.xml souboru, ve kterém jsou uloženy informace o službách, které je uživatel

oprávnn využívat. V záložce Server addresses je teba vyplnit adresy proxy CSCF a SIP serveru. Profile Status zobrazuje informace o tom, zda ICP bží a zda je uživatel úspšn zaregistrován. Spouští a zastavuje se zde registrace uživatele. Obr.6.1 Nastavení ICP 6.2 Nastavení na PC2 Na tomto poítai bude spuštn pouze emulátor mobilního telefonu Sony Ericsson P1i, ve kterém bude nainstalován VoIP klient. Ped instalováním VoIP klienta do tohoto telefonu je v programu SDS poteba nastavit cestu k emulátoru. To se provede v záložce Symbian UIQ na kart Client v okn Preferences. Po jejím potvrzení probhne instalce platformy ICP do emulátoru Symbianu. 6.2.1 Nastavení ICP Symbian Nastavování ICP v telefonu s operaním systémem Symbian probíhá ve složce Control Panel. Zde je nejprve poteba vytvoit nový profil IMSSetting. Poté již lze upravovat nastavení v jednotlivých položkách podobn jako ve Windows (Obr.6.2). Network selection uruje zpsob pipojení telefonu k místní síti. V položce Server Addresses je teba nastavit IP adresu proxy CSCF a SIP serveru spuštného na PC1. V User Profile se nastaví údaje druhého uživatele (user2) a v Profile Status se spustí jeho registrace. Po úspšné registraci je telefonu pidlena IP adresa, která je nkolik sekund zobrazena v horní ásti obrazovky.

Obr.6.2 Nastaveni ICP Symbian 6.3 Spuštní simulátor Nejprve je teba spustit SIP server. Po jeho úspšném spuštní se v konzolovém okn vypíše hlášení, že naslouchá na portu 5060 SIP a 5061 SIPS. Dále je nutné spustit simulátor CSCF a DNS serveru. Jejich úspšné spuštní je opt signalizováno v okn konzole. Nyní je již možné registrovat uživatele jak v ICP ve Windows tak v mobilním telefonu. Po úspšné registraci se status uživatele zmní na Registered a v perspektiv Provisioning se objeví informace o registraci (Obr.6.3). Obr.6.3 Registrace uživatele

6.4 Realizace hovoru Pro testování hovorových služeb jsem se rozhodl využít VoIP klienta, který je obsažen v instalaci SDS. Pomocí tohoto klienta usuktením hovor mezi obma poítai. Po úspšném navázání spojení stisknu tlaítko pro ztišení hovoru, a po chvíli konverzaci opt obnovím. Nakonec klient na PC2 zavsí. Klient user2 sestaví první zprávu [1]INVITE (Obr.6.5), kterou zve uživatele user1 k navázání hovorové relace a odešle ji na server (Obr.6.4). V hlavice Allow této zprávy je uveden seznam všech metod podporovaných user agentem (ICP), který zprávu vygeneroval. Hlaviku Require využívá klient pro sdlení serveru, jaké podmínky musí splovat, aby mohl žádost úspšn vyídit. Hodnota v hlavice session-expires udává pedpokládanou dobu, po kterou bude relace existovat. Obr.6.4 INVITE

Content-Length udává velikost tla zprávy. Do hlaviky Contact vložil user2 svojí adresu a v parametru pipojuje informaci o služb, kterou využívá (+g.ericsson. voip-p2p). Proxy-Authorization obsahuje identifikaní údaje klienta, které sdluje proxy vyžadující autentizaci. V Call-ID je uveden jedinený identifikátor spojení. V hlavice Content-Type se píjemci pedává informace o typu média obsaženém v tle zprávy. Prázdný ádek oddluje protokol SIP od protokolu SDP. Pro popis relace je využit protokol SDP verze 0. Informace o spojení jsou specifikovány v ádcích zaínajících písmenem c. Parametr IN oznauje sí Internet a IP4 znaí, že uvedená adresa (192.168.1.8) je typu IPv4. Typ média peneseného bhem relace je popsán v ádku s písmenem m. Jedná se o penos zvuku, cílový port má íslo 10000 a pro penos je využit protokol RTP. íslo 98 upesuje vlastnosti penášených dat, konkrétn, že se jedná o dynamický datový tok specifikovaný v RFC3267. Atribut sendrecv znaí, že odesílatel popisu relace je schopen datové toky jak odesílat tak pijímat. Atribut rtpmap nese informaci o vlastnostech audio profilu 98, o použitém kodeku (AMR), clockrate a kódovacích parametrech (potu audio kanál). Server odpovídá zprávou 100 Trying, kterou dává klientovi na vdomí, že žádost pijal a zpracoval a není nutné její optovné odeslání. Samotnou žádost odešle na adresu user1. Pomocí zpráv Ringing, Session Progress a UPDATE mezi sebou klienti vyjednají parametry penosu. User1 hovor pijme odesláním zprávy [13] 200 OK (Obr.6.5). Po stlaení tlaítka Mute v aplikaci odešle user2 zprávu [17] UPDATE (Obr.6.5), ve které upravuje nastavení probíhající relace. Atribut sendrecv zmní na sendonly, ímž dá najevo že bude datový tok pouze vysílat. Po optovném stlaení tlaítka Mute upraví další zprávou [21] UPDATE (Obr.6.5) atribut zpt na sendrecv a umožní tak pokraování hovoru. Pro ukonení hovoru odešle user1 zprávu [25] BYE (Obr.6.5).

Obr.6.5 VoIP relace

7 IMS-M Simulátor Simulátor IMS Messagingu obsažený v SDS umožuje klientm pi komunikaci využívat služeb instant messaging a chat. IMS-M simulátor je funkce nainstalovaná na SIP kontejneru a její implementace ásten dodržuje OMA-TS-SIMPLE-IM_V1 specifikace uvedené v dokumentaci na stránkách organizace OMA (Open Mobile Alliance) [7]. Simulátor podporuje jak zasílání zpráv bez nutnosti navázání relace (page mode) tak jejich zasílání bhem relace (session mode). Tuto funkci lze využít pro zasílání textových a multimediálních zpráv v reálném ase nebo s opoždným doruením, jednomu nebo více adresátm, vytváení chatových relací a zasílání soubor. 7.1 One-to-one Instant Message Tato služba umožuje úastníkm zasílat a pijímat zprávy do velikosti 1300 byt [7]. Tento mód je vhodný pro zasílaní krátkých zpráv s rychlým doruením a nebo zpráv u kterých není vyžadována odpov. Není vhodný pro zasílání multimediálních zpráv. Zpráva je penášena pes signalizaní rovinu což zajišuje rychlý a na spojení nenároný penos bez nutnosti vytváení relace. Všechny následné zprávy a odpovdi na n jsou samostatné zprávy a nejsou s pedchozími nijak vázány. Tyto zprávy mohou být zasílány i na zaízení podporující poze SMS. Pokud je adresát offline je mu zpráva doruena pozdji. 7.2 One-to-One Instant Multimedia Message Tato služba je vhodná pro multimediální komunikaci pomocí zpráv, jejichž velikost pesáhne 1300 byt [7]. Zprávy tohoto typu mohou obsahovat kombinaci textu, obrázk, audio nebo video soubor. Instant multimedia messaging vyhovuje specifikacím 3GPP. V tomto módu je pro doruování obsahu využíván protokol MSRP (Message Session Relay Protocol), který umožuje penášet data uzavená v MIME (Multipurpose Internet Mail Extension) kontejnerech. Ped odesláním multimediální zprávy je vytvoena relace a jsou vyjednány podmínky jednosmrného penosu. Tato relace trvá pouze po dobu penosu zprávy

a po jeho dokonení je okamžit ukonena. Bhem jedné relace lze penést pouze jednu zprávu. 7.3 One-to-One IMS-M se zpoždným doruením Zprávy zaslané offline uživateli se službou opoždného doruení jsou uloženy v jeho schránce a jsou mu dorueny ihned po jeho pihlášení [7]. Pokud adresát nevyužívá službu pro opoždné doruení je pro odesílatele vygenerována zpráva o nedostupnosti adresáta. O doruení zpoždných zpráv se žádné hlášení negeneruje. Pokud se adresát nepihlásí ped vypršením platnosti zprávy je tato smazána. 7.4 One-to-Many Message Tato služba podporuje zasílání krátkých a multimediálních zpráv více píjemcm [7]. Adresa zprávy je nastavena na adresu IMS-M serveru a seznam píjemc je uložen v tle zprávy. IMS-M server seznam píjemc ze zprávy vyjme a vytvoí a odešle zprávu zvláš pro každého z nich. Pokud byla zpráva multimediální, vytvoí server s každým adresátem vlastní relaci. 7.5 One-to-One Chat Umožuje dvma uživatelm vytvoit relaci pro zasílání zpráv v reálném ase. Mezi obma uživateli vznikne spojení pomocí protokolu MSRP [7]. Druh a velikost zpráv je limitována pouze schopnostmi koncových zaízení nebo pravidly operátora.

8 IMSM Klient Vytvoil jsem aplikaci, která funguje jako klient pro IMS messaging. Umožuje zasílat si v reálném ase mezi dvma poítai textové zprávy a pikládat k nim soubory obsahující text, zvuk, obraz nebo data. 8.1 Inicializace IPlatform je objekt tídy ICPFactory využívaný pro vytváení IMS profilu. V jedné klientské aplikaci mže být pouze jeden objekt IPlatform. IProfile je hlavní rozhraní ICP funkce, pomocí kterého se klientská aplikace musí zaregistrovat ped vytvoením relace. Poskytuje metody pro zpracování služeb IMS. V jedné aplikaci mže existovat více než jeden IProfile. ImsgManager je objekt tídy ImsmFactory. Umožuje vytvoení objektu IMsgSending, který spravuje operace pi odesílání a pijímání IMSM zpráv. IPlatform platform = ICPFactory.createPlatform(); platform.addlistener(new PlatformAdapter()); platform.registerclient( IMSM_Client ); IProfile profile = platform.createprofile( IMSSetting ); profile.addlistener(new ProfileAdapter()); ImsgManager msgmanager = ImsmFactory.createMsgManager(profile); msgmanager.setlistener(new MsgManagerAdapter()); 8.2 Vytvoení zprávy Ped odesláním zprávy musí klient nejprve vytvoit objekt IImsmMessage tídy ImsmFactory. Adresa volaného je uložena v etzci adresat. Je nutné vytvoit objekt IImsmAddress. Parametry tohoto objektu obsahují URI volaného, zobrazené jméno a informaci jestli je adresa anonymní. Voláním metody addaddress vložíme adresu volaného do objektu imsmmessage. IImsmMessage imsmmessage = ImsmFactory.createImsmMessage(); IImsmAddress komu = null; komu = ImsmFactory.createImsmAddress(adresat,adresat,false); imsmmessage.addaddress(msgfield.to, komu); Nyní musí klient vytvoit objekt MIMEContainer tídy SdpFactory, do kterého se budou ukládat rzné MIME objekty obsahující text, video, audio a data. Text zprávy je uložen v etzci text. Voláním metody addcontent pidáme do kontejneru MIME objekt zprava který obsahuje text zprávy.

MIMEContainer container = SdpFactory.createMIMEContainer(); MessageText zprava = new MessageText(text); container.addcontent((mime) zprava.getmime().clone()); zprava.release(); Pro pidání souboru ke zpráv je poteba vytvoit objekt MessageAttachment a v jeho parametrech uvést cestu k souboru a jeho typ/píponu. Cesta k souboru je uložena v etzci soubor a jeho typ je uložen v promnné typ. Voláním metody addcontent do kontejneru pidáme další MIME objekt tentokrát obsahující piložený soubor. MessageAttachment priloha = new MessageAttachment(soubor,typ); container.addcontent((mime) priloha.getmime().clone()); priloha.release(); Metoda setbody nastaví kontejner jako obsah tla zprávy. V tuto chvíli klient vytvoí objekt ImsgSending se vstupním parametrem imsmmessage. Voláním metody send klient zprávu odešle. imsmmessage.setbody(container); container.release(); ImsgSending msgsending = msgmanager.createmsgsending(imsmmessage); msgsending.setlistener(new MsgSendingAdapter()); msgsending.send(); msgsending.release(); imsmmessage.release(); msgmanager.release(); 8.3 Zpracování zprávy Pro dekódování pijatých zpráv je poteba vytvoit metodu processmessage se vstupním parametrem IImsmMessage. Adresa odesílatele se vloží do objektu IImsmAddress voláním metody getaddress s parametrem From a poté je uložena do etzce odesilatel, který je možné zobrazit ve výstupu programu. public void processmessage(iimsmmessage aimsmmessage){ IImsmAddress od = aimsmmessage.getaddress(msgfield.from, 0); String odesilatel = od.geturi(); od.release(); Nyní klient vytvoí prázdný MIME kontejner, do kterého voláním metody getbody vloží tlo píchozí zprávy. MIMEContainer container = null; container = aimsmmessage.getbody();

Metoda getcontents získá z kontejneru všechny MIME objekty, které jsou poté zpracovány podle toho jestli obsahují text nebo njaký soubor. for(int i = 0; i < container.getcontents().size(); i++){ MIME mime = container.getcontent(i); if (MessageText.isInstance(mime)){ MessageText zprava = new MessageText ((MIME) mime.clone()); zprava.release();} else if (MessageAttachment.isInstance(mime)){ MessageAttachment priloha = new MessageAttachment ((MIME) mime.clone()); priloha.release();} 8.4 GUI Grafické uživatelské rozhraní IMSM Klienta obsahuje ti editovatelná pole (Obr.8.1). Do textového pole Adresa se zadává adresa píjemce ve tvaru sip:jméno@doména. Toto pole lze také rychle vyplnit zvolením píjemce v menu Adresá. Do pole Zpráva se zapisuje textový obsah zprávy a do pole Píloha se zadává cesta k souboru, který chceme ke zpráv piložit. Pole Píjem editovatelné není. Zobrazují se zde výpisy pijatých zpráv, a informace o pijatých souborech. Navíc se do tohoto pole vypisují i všechna chybová hlášení. Aplikace se ukoní výbrem možnosti Konec v menu Soubor. Obr.8.1 Rozhraní aplikace IMSM Klient

8.5 Odeslání zprávy Po stisknutí tlaítka odeslat vytvoí IMSM Klient zprávu [1]INVITE (Obr.8.2). Z obsahu zprávy je vidt, že user agent využívá službu +g.oma.sip-im. Penos zprávy probhne pomocí protokolu TCP a MRSP na portu 4000. Atribut sendonly znaí, že se bude jednat o jednosmrný penos a atribut filesize udává velikost penášeného souboru. Obr.8.2 INVITE IMS Message Uživatel user1 odpovídá zprávou [5] 200 OK (Obr.8.3), ve které potvrzuje vyjednané podmínky penosu. Ihned po donení penosu odesílá user2 zprávu [7] BYE, kterou ukoní relaci.

Obr.8.3 Odeslání zprávy

9 ZÁVR Bhem práce na této bakaláské práci jsem se podrobn seznámil s technologií IP Multimedia Subsystem. Zjistil jsem, jaké funkce plní jednotlivé entity obsažené v architektue této technologie a jak napomáhají spolupráci s jinými sítmi. Tyto funkce mohou být soustedny do jednoho zaízení nebo distribuovány v rzných ástech sít, což usnaduje její správu. Popsal jsem vlastnosti nejastji používaných protokol a jejich využití v IMS. Podrobn jsem rozebral základní procedury registrace a navazování relace. Pedevším jsem si všímal, jaké parametry obsahují penášené zprávy a jak se tyto parametry mní pi prchodu zpráv pes jednotlivé prvky architektury. Dále m zajímal systém zabezpeení a nakládání s informacemi o uživatelích. Všiml jsem si, že kvli lepšímu zabezpeení komunikace, je pi tchto procedurách nutné penášet vtší množství zpráv než u bžné SIP relace. Seznámil jsem se s programem Service Development Studio spolenosti Ericson. Zjistil jsem jak v tomto programu fungují a jak se pracuje se simulátory jednotlivých prvk IMS sít. Vytvoil a nakonfiguroval jsem malou IMS sísestávající ze dvou poíta, mezi kterými jsem s pomocí aplikace obsažení v instalaci programu uskutenil VoIP hovor a sledoval jsem, jak probíhá vyjednávání ustavení relace, nastavování parametr spojení a jak se v prbhu hovoru dají tyto parametry zmnit. Vytvoil jsem Java aplikaci, která plní funkci klienta pro IMS instant messaging. Popsal jsem nejdležitjší metody potebné pro její správnou innost. Poté jsem si mezi dvma poítai zasílal krátké textové zprávy a piložil k nim i testovací soubor. Penos probhl podle oekávání, relace protokolu MSRP byla úspšn navázána a text i soubor byly dorueny. I zde jsem podrobn sledoval a rozebral obsah penášených zpráv, zajímal jsem se pedevším o zprávy INVITE, pomocí kterých se vytváí relace pro penos.