VYSOKÉ UýENÍ TECHNICKÉ V BRNċ BRNO UNIVERSITY OF TECHNOLOGY
FAKULTA ELEKTROTECHNIKY A KOMUNIKAýNÍ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
MARTIN ýECH
AUTHOR
VEDOUCÍ PRÁCE SUPERVISOR BRNO 2009
ING. TOMÁŠ MÁCHA
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: Ročník:
Martin Čech 3
ID: 78023 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
Vedoucí práce:
Ing. Tomáš Mácha
Termín odevzdání:
2.6.2009
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 pĜi komunikaci pomocí technologie IP Multimedia Subsystem. První þást se zamČĜuje 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 bČhem 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 informaþní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 vytvoĜením této práce jsem neporušil autorská práva tĜetích osob, zejména jsem nezasáhl nedovoleným zpĤsobem do cizích autorských práv osobnostních a jsem si 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.
V BrnČ dne ................ ............................................ podpis autora
PODċKOVÁNÍ DČkuji vedoucímu bakaláĜské práce Ing. Tomáši Máchovi za velmi užiteþnou metodickou pomoc a cenné rady pĜi zpracování bakaláĜské práce. V BrnČ dne …………… ………………………..(podpis autora)
SEZNAM ZKRATEK AS
Application Server
Auc
Authentication Center
AUTN
Authentication Token
AV
Authentication Vector
BGCF
Breakout Gateway Control Function
BICC
Bearer Independent Call Control
CK
Cyphering Key
DNS
Domain Name System
HLR
Home Location Register
HSS
Home Subscriber Server
HTTP
Hypertext Transfer Protocol
I-CSCF
Interrogating Call Session Control Function
IETF
Internet Engineering Task Force
IK
Integrity Key
IMS
IP Multimedia Subsystem
IP
Internet Protocol
ISIM
IP Multimedia Service Identity Module
ISUP
ISDN User Part
LIA
Location Info Answer
LIR
Location Info Request
MAA
Multimedia Auth Answer
MAR
Multimedia Auth Request
MGCF
Multimedia Gateway Control Function
MIME
Multipurpose Internet Mail Extension
MRFC
Multimedia Resource Function Controller
MRFP
Multimedia Resource Function Processor
MSRP
Message Session Relay Protocol
OMA
Open Mobile Alliance
P-CSCF
Proxy Call Session Control Function
PDF
Policy Decision Function
QoS
Quality of Service
RES
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 PODPģRNÉ 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 Identifikaþní Moduly .............................................................................. - 20 - 3.2 REGISTRACE POMOCÍ ISIM .................................................................................- 21 - 4 RELACE V IMS ................................................................................................. - 24 - 4.1 TYPY RELACÍ .....................................................................................................- 24 - 4.1.1 Hovor smČĜuje mimo IMS ..................................................................... - 24 - 4.1.2 Hovor smČĜuje do IMS .......................................................................... - 24 - 4.2 USTAVENÍ RELACE .............................................................................................- 24 - 5 SDS (SERVICE DEVELOPMENT STUDIO) ..................................................... - 28 - 5.1 VÝVOJOVÉ PROSTěEDÍ........................................................................................- 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 VYTVOěENÍ 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ŠTċNÍ 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ŽDċNÝM DORUýENÍ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 VYTVOěENÍ ZPRÁVY............................................................................................- 38 - 8.3 ZPRACOVÁNÍ ZPRÁVY .........................................................................................- 39 - 8.4 GUI ..................................................................................................................- 40 - 8.5 ODESLÁNÍ ZPRÁVY .............................................................................................- 41 - 9 ZÁVċR .............................................................................................................. - 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 BċHEM REGISTRACE ...............................................................- 23 - OBR.4.1 ZPRÁVA INVITE ........................................................................................- 25 - OBR.4.2 SIGNALIZACE BċHEM 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živatelĤm využívání rĤzný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 nejvČtšímu poþtu uživatelĤ bez ohledu na to, jakou využívají síĢ a obohatit tak možnosti jejich vzájemné komunikace. Poskytuje také vČtší míru zabezpeþení než napĜ. bČžné VoIP a podporuje pokroþilé Ĝízení pĜidČlování síĢových prostĜedkĤ. 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Č tĜetí generace (GPRS/UMTS). Tyto soubory zveĜejĖuje každoroþnČ 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 vČnovat architektuĜe 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 dĤležité protokoly, které se vztahují k technologii IMS. Zejména se zamČĜím na signalizaþní protokol SIP, který v celé problematice hraje velmi dĤležitou roli. Poté se budu detailnČji zabývat popisem jednotlivých procedur, konkrétnČ samotné registrace a vytvoĜení relace. Zde se zamČĜím pĜedevším na probíhající signalizaci, smČrování a tvar zpráv, které jsou v prĤbČhu tČchto procedur vymČĖovány. V dalších kapitolách se seznámím s programem Service Development Studio, který budu používat pro vytvoĜení experimentální sítČ a pro testování VoIP komunikace. Po uskuteþnČní hovoru budu analyzovat reálné SIP zprávy pĜenášené bČhem hovorové relace. Poté vytvoĜím aplikaci, která bude fungovat jako klient pro instant messaging, popíšu princip jeho þinnosti a ovČĜím správnou funkþnost.
ͲϭϬͲ
ARCHITEKTURA IMS Architektura IMS je souborem funkcí propojených pĜes standardizovaná rozhraní [2]. ZaĜízení potĜebná k zajištČní pĜístupu do sítČ nejsou souþástí architektury. Z hlediska IMS nezáleží, pomocí jaké sítČ je zajištČn pĜístup uživatele, protože implementuje funkce pro pĜeklad signalizace z jiných sítí na signalizaci využívanou v síti IMS. Skládá se z nČkolika 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 vysvČtlena 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 bČhem registrace a ustavování relace a zajišĢují v síti smČrová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 tĜi 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 bezpeþnosti je výhodnČjší, když fungují oddČlenČ [3]. 1.1.1 P-CSCF(Proxy Call Session Control Function) Je v signalizaþní rovinČ prvním pĜístupovým bodem do IMS (Obr.1). Veškerá SIP signalizace z uživatelských zaĜízení pĜichází do sítČ IMS pĜes P-CSCF a naopak signalizace ze sítČ je zpČt do uživatelských zaĜízení zasílána opČt pĜes P-CSCF [1]. Dále tato funkce musí zaruþit, že zaĜízení pĜistupující do sítČ je zaregistrováno a je mu umožnČn pĜístup. ZajišĢuje také základní smČrování žádostí a odpovČdí. Pro zmenšení objemu pĜenášených signalizaþních dat a urychlení ustavování relací zde probíhá komprese a dekomprese SIP zpráv vymČĖovaných mezi IMS sítí a terminálem. Dalším úkolem P-CSCF je kontrola identity a dĤvČryhodnosti uživatele a zabránČní neautorizovaného pĜístupu. P-CSCF také spolupracuje s PDF(Policy Decision Function) pĜi pĜidČlování síĢových prostĜedkĤ 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 pĜed ostatními operátory (odstranČním urþitých hlaviþek SIP zpráv) [2]. Pomáhá chránit S-CSCF a servery uchovávající data o uživatelích pĜed neoprávnČným pĜístupem z jiných sítí, mĤže být považována za firewall sítí IMS. DĤležitým úkolem této funkce je pĜidČlování S-CSCF uživatelĤm. O pĜidČlení rozhoduje buć podle podporovaných služeb nebo podle geografické polohy S-CSCF [1]. PotĜebné 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 zodpovČdný za Ĝízení procesu registrace a autentifikace všech úþastníkĤ, kteĜí se pokoušejí registrovat do sítČ. Registrovaným úþastníkĤm povoluje využívání služeb a umožĖuje pĜístup k rĤzným aplikaþním serverĤm. Kontroluje zasílání zpráv a doruþování obsahu. Poskytuje ostatním aplikacím informace o stavu registrace úþastníka a udržuje kontrolu nad pĜidČlený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ístČní tČchto 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ávnČn používat, do jakých sítí je oprávnČn pĜistupovat. Ukládá veĜejné a privátní identity úþastníkĤ. Uchovává také šifrovací a autentifikaþní klíþe úþastníkĤ. PĜi každé zmČnČ zasílá všechna data o uživateli do S-CSCF, za úþelem jejich pĜepsání aktuálními. Výhodou HSS je schopnost spravovat více identit pro jedno pĜihlášení [1]. BČhem registrace sem pĜistupuje 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 tČchto sítí pĜistupovat. AuC uchovává bezpeþnostní 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í aplikaþních služeb. Do skupiny tČchto funkcí patĜí rĤzné aplikaþní servery, procesor a kontroler funkcí zdroje multimédií. 1.3.1 MRFC (Multimedia Resource Function Controller) V signalizaþní 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 pĜes 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Ĥ tČchto tokĤ uskuteþĖuje jejich slouþení. MĤže také provádČt analýzu médií (Obr.1). 1.3.3 AS (Application Server) Je víceúþelová funkce poskytující aplikaþní služby. Není souþástí jádra IMS. Je pĜímo propojen s rĤzný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 rĤznými doménami a pĜeklad signalizaþních a komunikaþních protokolĤ. 1.4.1 MGCF (Multimedia Gateway Control Function) Není skuteþnou souþástí IMS. ZajišĢuje propojení mezi doménou pĜepínání okruhĤ a doménou pĜepínání paketĤ. Hovory pocházející z domény pĜepínání okruhĤ jsou smČrovány na tuto funkci, která na aplikaþní vrstvČ
provede pĜeklad 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Č obousmČrnou konverzi signalizace mezi signalizací založenou na IP a signalizací založenou na SS7 (Obr.1). Úkolem SGW není pĜekládat zprávy na aplikaþní vrstvČ. 1.4.3 IMS-MGW (IMS Media Gateway) Je Ĝízena MGCF (Obr.1). Poskytuje na uživatelské rovinČ spojení mezi IMS a sítČmi pĜepínání okruhĤ. Zakonþuje pĜenosové kanály ze sítí s pĜepínáním okruhĤ a provádí potĜebné zpracování pĜenášené signalizace. Pracuje také jako generátor tónĤ.
ͲϭϰͲ
1.4.4 BGCF (Breakout Gateway Control Function) Vybírá bod pĜestupu do sítČ pĜepínání okruhĤ (Obr.1). Pokud pĜestup nastane ve stejné síti BGCF zvolí MGCF pro další Ĝízení relace. Pokud nastane pĜestup v jiné síti je relace smČrována na BGCF v této síti.
1.5 PodpĤrné funkce PodpĤrné funkce umožĖují operátorĤm stanovovat pro úþastníky pravidla využívání sítČ. NČkteré z tČchto funkcí umožĖují také aplikovat rĤzné bezpeþnostní mechanismy. 1.5.1 PDF(Policy Decision Function) Na základČ informací zasílaných z P-CSCF (Obr.1) Ĝídí pĜidČlování síĢových prostĜedkĤ. 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 vymČĖovaných pĜi komunikaci mezi dvČma nebo více entitami. DĤležitými prvky protokolu jsou syntax, sémantika a synchronizace. Syntax urþuje 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 aplikaþní vrstvy pro Ĝízení, popis a správu relací jako SIP, SDP nebo RTP. Pro pĜenos 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 aplikaþní vrstvy používaný pro vybudování, úpravu a ukonþení 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í pĜenosu 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 odpovČdi. NejþastČjší typy žádostí:
INVITE-žádost o vytvoĜení relace, ACK-potvrzuje pĜijetí odpovČdi na žádost INVITE, BYE-žádost o ukonþení relace, CANCEL-žádost o ukonþení jiné nevyĜízené žádosti, ͲϭϲͲ
REGISTER-žádost o registraci klienta u SIP serveru, SUBSCRIBE-pĜihlášení k odbČru informací, PRACK-potvrzeni doþasné (1xx) odpovČdi, NOTIFY-zveĜejĖování informací, MESSAGE- pĜenáší zprávy, PUBLISH-nahrává na server uživatelĤv status. OdpovČdi se dČlí do rĤzných kategorií podle jejich kódu: 1xx: doþasné/informaþní, 2xx: požadavek pĜijat, 3xx: pĜesmČrování, 4xx: chyba na stranČ klienta, 5xx: chyba na stranČ serveru, 6xx: globální chyba. Každá zpráva protokolu SIP je tvoĜena hlaviþkou (header) a vlastním obsahem (body). První Ĝádek identifikuje její typ. Zprávy SIP se využívají k pĜenosu 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, pĜedpokládá se použití portu 5060. URI mĤže mít i tvar telefonního þísla. 2.1.2 Prvky SIP User Agent:
Je koncové zaĜízení sítČ, vČtšinou HW nebo SW SIP telefon, PDA apod. V UA je vČtšinou implementován jak UAS (User Agent Server), který pĜijímá žádosti a odesílá na nČ odpovČdi, tak UAC (User Agent Client), který žádosti vysílá.
Proxy Server:
Úlohou proxy serveru je smČrovat žádosti o sestavení spojení od UA nebo jiného proxy. Tyto žádosti mĤže smČrovat buć pĜímo volanému (zná-li jeho umístČní) nebo na další proxy (blíž volanému). ͲϭϳͲ
Redirect Server:
ZajišĢuje smČrování žádostí. ZjišĢuje v registrar serveru aktuální umístČní UA a v odpovČdi o nČm informuje odesílatele požadavku, který poté na toto umístČní zasílá svoji žádost.
Registrar Server:
PĜijí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 aplikaþní vrstvy urþený k popisu multimediálních relací. PodobnČ jako SIP je i tento protokol textovČ orientovaný. Každá zpráva obsahuje nČkolik povinných a volitelných údajĤ [1]: Popis relace: v- verze protokolu, o- pĤvod 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
doruþování
hlasových
a obrazových dat v reálném þase po internetu. Protokol samotný data nepĜenáší, zajišĢuje pouze jejich rekonstrukci na stranČ pĜíjemce. Parametry protokolu RTP [5]: V (Version)- oznaþuje verzi protokolu RTP, P (Padding)- indikuje doplĖkové slabiky, X (Extension)- indikuje rozšíĜení hlaviþky RTP, CC (Contributin Source count)- poþet zdrojĤ dat, M (Marker)- doplĖkový bit, PT (Payload type)- formát pĜenášených dat (kodek), ͲϭϴͲ
SN (Sequence number)- þíslo paketu, využívá pĜíjemce ke zjištČní poĜadí pĜíchozích paketĤ, TS (Time stamp)- þasová znaþka, používá se k odstranČní jitter, SSRC (Synchronization source)- identifikace zdroje paketĤ, CSRC (Contributing source list)- seznam zdrojĤ dat, DATA- data. RTCP je protokol urþený k monitorování vlastností spojení. Jeho úkolem je poskytovat zpČtnou vazbu na QoS.
2.4 DIAMETER Je autentizaþní, autorizaþní a úþtovací protokol vyvinutý organizací IETF. Jeho pĜedchĤdcem je protokol RADIUS. Vlastní protokol lze rozdČlit na základní protokol a jeho aplikace (protokoly založené na Diameteru). Základní
protokol
je
zodpovČdný
za
doruþování
datových
jednotek,
vyjednávání zpĤsobilosti, Ĝešení chyb a poskytování rozšiĜitelnosti. Pro pĜenos využívá protokoly TCP a SCTP a pro zabezpeþení spojení protokoly IPsec a TLS. Aplikace rozšiĜují základní protokol pĜidáním nových pĜíkazĤ. Každá aplikace je definována zvlášĢ. Pro oblast IMS je dĤležitá aplikace DIAMETER SIP, která SIP serveru umožĖuje autentifikovat uživatele a autorizovat ho k použití rĤzných prostĜedkĤ SIP. Definuje nČkolik pĜíkazĤ rozšiĜujících základní protokol Diameter [1]: UAR/UAA
urþují, zda je uživatel autorizován k vyžívání urþité služby pokud ano, ukazují na server schopný tuto službu poskytnout,
SAR/SAA
pĜiĜadí uživateli specifický server a doruþí na nČj uživatelský profil,
LIR/LIA
zjišĢuje adresu S-CSCF pĜidČlené uživateli,
MAR/MAA
autentifikuje a autorizuje uživatele pro urþitou službu,
RTR/RTA
odregistrování ze strany Diameter serveru.
ͲϭϵͲ
3 REGISTRACE DO IMS Registrace do IMS je procedura, pĜi 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 odpovČdí na nČ [2].
3.1 Typy Registrací Procedury registrace se rĤzní 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 pĜipojení získává terminál svojí IP adresu a adresu P-CSCF bČhem procedury Activate PDP Context. V ostatních pĜípadech probČhne konfigurace terminálu pomocí DHCP. 3.1.1 Identifikaþní Moduly Vlastní registrace do IMS se liší podle vlastností terminálu, konkrétnČ aplikace, ve které terminál uchovává identifikaþní údaje. Pro pĜístup do IMS lze využít dvČ tyto aplikace. ISIM (IP multimedia Service Identity Module) obsahuje sadu parametrĤ potĜebných k autentifikaci a autorizaci v IMS [2]. Privátní identita je jedineþný identifikátor uživatele. VeĜejné 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 potĜebné pro využívání sítí tĜetí generace [2]. IMSI je identita pĜidČlená 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 vytvoĜit doþasnou privátní identitu, veĜejnou 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 naþte z ISIM (IP Multimedia Service Identity Module) privátní
identitu, veĜejnou identitu a URI domácí sítČ. Poté zaþne vytváĜet první žádost REGISTER (Obr.3.1), která obsahuje nČkolik parametrĤ [4]: URI žádosti:
místo urþení, v tomto pĜípadČ domácí síĢ,
Via:
adresa terminálu, dĤležitá pro doruþení odpovČdi,
Route:
adresa P-CSCF,
From:
kdo provádí registraci,
To:
veĜejná identita (chceme zaregistrovat),
Contact:
adresa, na které bude veĜejná identita k dosažení,
Authorization:
v parametru username je obsažena privátní identita,
Call-ID:
jedineþný identifikátor spojení,
Content-Length:
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 ovČĜen a komunikuje s P-CSCF pĜes
nezabezpeþené 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Č pĜed
odesláním ale odstraní vlastní záznam z hlaviþky Route a pĜidá svojí adresu na první místo do hlaviþky Via. Aby zajistilo, že veškerá signalizace urþená terminálu projde pĜes P-CSCF, pĜidává do každé žádosti REGISTER svoji adresu uloženou v hlaviþce Path. 3)
Když I-CSCF obdrží žádost, potĜebuje zjistit, zda již má uživatel pĜidČleno
nČjaké 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 pĜidČleno nebylo, zahrne do odpovČdi také parametry pro jeho výbČr. 4)
I-CSCF pĜidá svojí adresu na první místo v hlaviþce Via, do hlaviþky Route
zapíše adresu pĜidČleného S-CSCF a zprávu odešle (Obr.3.2). 5)
S-CSCF potĜebuje získat z HSS data pro ovČĜení uživatele. Na základČ
privátní identity vytvoĜí žádost (Diameter MAR) pro HSS, které mu odpoví (Diameter MAA) a do odpovČdi zahrne i AV (Authentication Vector), který obsahuje parametry pro ovČĜení uživatele (Obr.3.2). 6)
S-CSCF odešle zpČt 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 pamČti. Upravenou zprávu pošle na terminál (Obr.3.2). 9)
Terminál pĜedá 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 bezpeþnou komunikaci s P-CSCF (Obr.3.2). 10, 11, 12) 13)
Terminál odešle druhou žádost REGISTER, ve které uvede i RES.
S-CSCF porovná pĜijatou RES s oþekávanou (XRES) získanou z HSS a pokud
se shodují, je uživatel úspČšnČ ovČĜen. 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živatelĤv profil.
ͲϮϮͲ
14)
S-CSCF odešle na terminál odpovČć 200(OK). OdpovČć bude obsahovat
hlaviþku 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 pĜes I-CSCF (Obr.3.2).
Obr.3.2 Signalizace bČhem 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 pĜi 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 vytvoĜení 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 smČĜuje mimo IMS Pokud S-CSCF obdrží zprávu INVITE pro uživatele, který se nachází mimo doménu IMS, pĜedá ji BGCF. Úkolem této funkce je, rozhodnout jak žádost dále smČrovat. Pokud se adresát nachází ve stejné síti, smČĜuje žádost na MGCF, která zajistí spojení s doménou SS7. Pokud se adresát nachází v jiné síti, je žádost pĜesmČrována na BGCF v této síti [3]. 4.1.2 Hovor smČĜuje do IMS Pokud MGCF obdrží zprávu (Initial Adress Message) z domény SS7 pĜevede ji na zprávu INVITE [1]. ZároveĖ také zmČní telefonní þíslo uživatele na SIP URI, þímž umožní smČrování v IMS. Poté již žádost odešle podle potĜeby 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 podrobnČji popíšu co se dČje pĜi 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ží bČhem celého dialogu jako hlavní identifikátor uživatele. ýíslo 1357 v hlaviþce Via udává þíslo portu zabezpeþeného spojení mezi terminálem a P-CSCF. 2)
P-CSCF ovČĜí, zda žádost obdržela pĜes zabezpeþené spojení. Pokud ne,
zamítne ji. Poté porovná hodnotu z hlaviþky P-Preferred-Identity s identitou uživatele, od kterého obdržela žádost. Pokud se shodují, nahradí P-Preferred-Identity hlaviþkou P-Asserted-Identity, do které uloží pĤvodní hodnotu. V pĜípadČ, že se neshodují nebo v žádosti hlaviþka P-Preferred-Identity nebyla, uloží do P-Asserted-Identity hodnotu defaultní registrované identity uživatele. Nakonec odstraní vlastní záznam z Route, pĜidá vlastní záznam do Record-Route a Via (bez þísla portu) a odešle žádost na SCSCF (Obr.4.2). 3)
S-CSCF identifikuje uživatele na základČ informací z hlaviþky P-Asserted-
Identity. NáslednČ zkontroluje stav jeho registrace a mĤže do této hlaviþky pĜidat další URI. NáslednČ odstraní vlastní záznam z Route, pĜidá vlastní záznam do Record-Route a Via a dotazem na DNS zjistí adresu I-CSCF v síti volaného ͲϮϱͲ
PĜed odesláním ovČĜí, že síĢ volaného je dĤvČryhodná (pokud ano nemusí odstraĖovat P-Asserted-Identity) a žádost odešle (Obr.4.2). 4)
I-CSCF odstraní vlastní záznam z Route a pĜidá vlastní záznam do Via. Z HSS
zjistí adresu S-CSCF pĜidČleného volanému a žádost na ní odešle (Obr.4.2). 5)
S-CSCF odstraní vlastní záznam z Route, pĜidá 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 pĜeposlat i s položkou P-AssertedIdentity. PĜes zabezpeþené spojení odešle žádost na terminál volaného (Obr.4.2). 7)
Terminál B vytvoĜí odpovČć 183 (Session Progress), ve které do hlaviþky
Contact uloží vlastní adresu vþetnČ þísla bezpeþného portu, a odešle ji na adresu podle prvního záznamu z hlaviþky 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ž zapoþalo vyjednávání o vlastnostech pĜenosu. 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 bČhem 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 doruþovány nespolehlivČ, proto bylo nutné do pĤvodní žádosti INVITE vložit hlaviþku Supported: 100rel, která zaruþí, že i doþasná zpráva (1xx) bude doruþena spolehlivČ. Ve zprávČ PRACK (potvrzuje doruþení 1xx zprávy) sdČluje terminál A jaký kodek bude použit pro jaké médium. 14)
OdpovČć OK terminálu B potvrzuje souhlas s vyjednanými parametry pĜenosu.
ͲϮϲͲ
15)
Oba terminály jsou nyní ve fázi, kdy si rezervují prostĜedky potĜebné
k uskuteþnČní hovoru. Když si terminál A vyhradí dostateþné množství prostĜedkĤ, 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 prostĜedkĤ zaþíná
vyzvánČt, o þemž informuje volajícího zprávou 180 (Ringing) (Obr.4.2). 17)
PĜijmutí hovoru signalizuje terminál B zasláním odpovČdi 200 (OK) (Obr.4.2).
Obr.4.2 Signalizace bČhem navazování relace
ͲϮϳͲ
5 SDS (Service Development Studio) SDS je program, vyvíjený spoleþností Ericsson, urþený pro návrh a testování jak klientských tak serverových aplikací využívajících služeb technologie IMS. UmožĖuje v tČchto aplikacích využívání pokroþilý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 nČkolik aplikaþních serverĤ. Klientské aplikace lze otestovat buć pĜímo v prostĜedí Windows, nebo na nČkterém z emulovaných telefonĤ s operaþním systémem Symbian. SDS podporuje vývoj aplikací podle specifikací JSR 116 a JSR 289.
5.1 Vývojové prostĜedí Vývojové prostĜedí je založeno na platformČ Eclipse IDE. Je rozdČleno do nČkolika 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 dČlí na nČkolik druhĤ. 5.1.1 Development Perspective Tato perspektiva obsahuje souþásti JDT (Java Development Tool) a soubor funkcí urþený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 urþena pro obsluhu uzlĤ simulované sítČ. V sekci DNS umožĖuje Ĝízení hovorových relací pĜiĜazová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 smČrování žádostí na rĤzné aplikaþní 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 prostĜedí (CSCF, DNS, PoC Server, Symbian Emulator) a stavĤ jednotlivých þástí. Pomocí tohoto
ͲϮϴͲ
grafického rozhraní lze rychle pĜistupovat k jednotlivým uzlĤm, zjišĢovat a mČnit jejich konfiguraci. 5.1.4 Automated Testing Framework Perspective Se využívá k vytváĜení a spouštČní 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í sekvenþní diagramy SIP komunikace procházející pĜes CSCF. UmožĖuje v reálném þase sledovat smČrová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 urþená ke spouštČní klientských aplikací pro operaþní 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 spoleþnou platformu všem klientĤm vytvoĜený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 VytvoĜení experimentální sítČ Experimentální síĢ sestává ze dvou poþítaþĤ s operþním systémem Windows XP Professional s nainstalovanými aktualizacemi Service Pack 3. Na obou stanicích je kompletnČ nainstalováno prostĜedí SDS. První poþítaþ bude hostit simulované prostĜedí sítČ IMS a VoIP klienta pro Windows. Na druhém poþítaþi bude klientská aplikace spuštČna na emulovaném mobilním telefonu se systémem Symbian ve verzi S60.
6.1 Nastavení na PC1 Na tomto poþítaþi bude spuštČn SIP server, DNS Server a všechny Ĝídící funkce, a proto je tĜeba v programu SDS zmČnit urþitá nastavení. 6.1.1 Okno Preferences V záložce CSCF na kartČ Server okna Preferences jsem zmČnil adresu DNS serveru na hodnotu IP adresy síĢového rozhraní, port i doména zĤstávají pĤvodní. V záložce transport je tĜeba u všech tĜí Ĝídících funkcí adresu localhost zmČnit 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 opČt na IP adresu síĢového rozhraní. V záložce HSS jsem vytvoĜl nový služební profil TestProfile obsahující filtraþní kritéria pro IMSM. Poté jsem vytvoĜil dva nové uživatelské profily user1 a user2 pro doménu ericsson.com a obČma jsem pĜiĜadil služební profil TestProfile. 6.1.3 Nastavení ICP V ovládacích panelech je tĜeba 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 potĜeba defaultnČ nastavený loopback adapter zmČnit na reálnou síĢovou kartu instalovanou v poþítaþi. V záložce UserProfile jsem vyplnil veĜejnou a privátní identitu a pĜihlaš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ávnČn využívat. V záložce Server addresses je tĜeba 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þítaþi bude spuštČn pouze emulátor mobilního telefonu Sony Ericsson P1i, ve kterém bude nainstalován VoIP klient. PĜed instalováním VoIP klienta do tohoto telefonu je v programu SDS potĜeba nastavit cestu k emulátoru. To se provede v záložce Symbian UIQ na kartČ Client v oknČ Preferences. Po jejím potvrzení probČhne instalce platformy ICP do emulátoru Symbianu. 6.2.1 Nastavení ICP Symbian Nastavování ICP v telefonu s operaþním systémem Symbian probíhá ve složce Control Panel. Zde je nejprve potĜeba vytvoĜit nový profil IMSSetting. Poté již lze upravovat nastavení v jednotlivých položkách podobnČ jako ve Windows (Obr.6.2). Network selection urþuje zpĤsob pĜipojení telefonu k místní síti. V položce Server Addresses je tĜeba nastavit IP adresu proxy CSCF a SIP serveru spuštČné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 pĜidČlena IP adresa, která je nČkolik sekund zobrazena v horní þásti obrazovky.
ͲϯϭͲ
Obr.6.2 Nastaveni ICP Symbian
6.3 SpuštČní simulátorĤ Nejprve je tĜeba spustit SIP server. Po jeho úspČšném spuštČní 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štČní je opČt 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 zmČní 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 usukteþním hovor mezi obČma poþítaþi. Po úspČšném navázání spojení stisknu tlaþítko pro ztišení hovoru, a po chvíli konverzaci opČt obnovím. Nakonec klient na PC2 zavČsí. 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 hlaviþce Allow této zprávy je uveden seznam všech metod podporovaných user agentem (ICP), který zprávu vygeneroval. Hlaviþku Require využívá klient pro sdČlení serveru , jaké podmínky musí splĖovat, aby mohl žádost úspČšnČ vyĜídit. Hodnota v hlaviþce session-expires udává pĜedpokládanou dobu, po kterou bude relace existovat.
Obr.6.4 INVITE
ͲϯϯͲ
Content-Length udává velikost tČla zprávy. Do hlaviþky Contact vložil user2 svojí adresu a v parametru pĜipojuje informaci o službČ, kterou využívá (+g.ericsson. voip-p2p). Proxy-Authorization obsahuje identifikaþní údaje klienta, které sdČluje proxy vyžadující autentizaci. V Call-ID je uveden jedineþný identifikátor spojení. V hlaviþce Content-Type se pĜíjemci pĜedává informace o typu média obsaženém v tČle zprávy. Prázdný Ĝádek oddČluje 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 oznaþuje síĢ Internet a IP4 znaþí, že uvedená adresa (192.168.1.8) je typu IPv4. Typ média pĜeneseného bČhem relace je popsán v Ĝádku s písmenem m. Jedná se o pĜenos zvuku, cílový port má þíslo 10000 a pro pĜenos je využit protokol RTP. ýíslo 98 upĜesĖuje vlastnosti pĜenáš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 pĜijímat. Atribut rtpmap nese informaci o vlastnostech audio profilu 98, o použitém kodeku (AMR), clockrate a kódovacích parametrech (poþtu audio kanálĤ). Server odpovídá zprávou 100 Trying, kterou dává klientovi na vČdomí, že žádost pĜijal a zpracoval a není nutné její opČtovné odeslání. Samotnou žádost odešle na adresu user1. Pomocí zpráv Ringing, Session Progress a UPDATE mezi sebou klienti vyjednají parametry pĜenosu. User1 hovor pĜijme odesláním zprávy [13] 200 OK (Obr.6.5). Po stlaþení 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 zmČní na sendonly, þímž dá najevo že bude datový tok pouze vysílat. Po opČtovném stlaþení tlaþítka Mute upraví další zprávou [21] UPDATE (Obr.6.5) atribut zpČt na sendrecv a umožní tak pokraþování hovoru. Pro ukonþení 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
klientĤm
pĜi
komunikaci využívat služeb instant messaging a chat. IMS-M simulátor je funkce nainstalovaná na SIP kontejneru a její implementace þásteþnČ 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í bČhem 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ždČným doruþením, jednomu nebo více adresátĤm, vytváĜení chatových relací a zasílání souborĤ.
7.1 One-to-one Instant Message Tato služba umožĖuje úþastníkĤm zasílat a pĜijímat zprávy do velikosti 1300 bytĤ [7]. Tento mód je vhodný pro zasílaní krátkých zpráv s rychlým doruþení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 pĜenášena pĜes signalizaþní rovinu což zajišĢuje rychlý a na spojení nenároþný pĜenos bez nutnosti vytváĜení relace. Všechny následné zprávy a odpovČdi na nČ jsou samostatné zprávy a nejsou s pĜedchozí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 doruþena pozdČji.
7.2 One-to-One Instant Multimedia Message Tato služba je vhodná pro multimediální komunikaci pomocí zpráv, jejichž velikost pĜesá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 doruþování obsahu využíván protokol MSRP (Message Session Relay Protocol), který umožĖuje pĜenášet data uzavĜená v MIME (Multipurpose Internet Mail Extension) kontejnerech. PĜed odesláním multimediální zprávy je vytvoĜena relace a jsou vyjednány podmínky jednosmČrného pĜenosu. Tato relace trvá pouze po dobu pĜenosu zprávy
ͲϯϲͲ
a po jeho dokonþení je okamžitČ ukonþena. BČhem jedné relace lze pĜenést pouze jednu zprávu.
7.3 One-to-One IMS-M se zpoždČným doruþením Zprávy zaslané offline uživateli se službou opoždČného doruþení jsou uloženy v jeho schránce a jsou mu doruþeny ihned po jeho pĜihlášení [7]. Pokud adresát nevyužívá službu pro opoždČné doruþení je pro odesílatele vygenerována zpráva o nedostupnosti adresáta. O doruþení zpoždČných zpráv se žádné hlášení negeneruje. Pokud se adresát nepĜihlásí pĜed 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ĜíjemcĤm [7]. Adresa zprávy je nastavena na adresu IMS-M serveru a seznam pĜíjemcĤ je uložen v tČle 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 dvČma uživatelĤm vytvoĜit relaci pro zasílání zpráv v reálném þase. Mezi obČma 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 VytvoĜil jsem aplikaci, která funguje jako klient pro IMS messaging. UmožĖuje zasílat si v reálném þase mezi dvČma poþítaþi textové zprávy a pĜiklá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 pĜed vytvoĜení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 vytvoĜení objektu IMsgSending, který spravuje operace pĜi odesílání a pĜijí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 VytvoĜení zprávy PĜed odesláním zprávy musí klient nejprve vytvoĜit objekt IImsmMessage tĜídy ImsmFactory. Adresa volaného je uložena v ĜetČzci adresat. Je nutné vytvoĜit 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 vytvoĜit objekt MIMEContainer tĜídy SdpFactory, do kterého se budou ukládat rĤzné MIME objekty obsahující text, video, audio a data. Text zprávy je uložen v ĜetČzci text. Voláním metody addContent pĜidá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 pĜidání souboru ke zprávČ je potĜeba vytvoĜit objekt MessageAttachment a v jeho parametrech uvést cestu k souboru a jeho typ/pĜíponu. Cesta k souboru je uložena v ĜetČzci soubor a jeho typ je uložen v promČnné typ. Voláním metody addContent do kontejneru pĜidáme další MIME objekt tentokrát obsahující pĜiložený soubor. MessageAttachment priloha = new MessageAttachment(soubor,typ); container.addContent((MIME) priloha.getMIME().clone()); priloha.release();
Metoda setBody nastaví kontejner jako obsah tČla 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í pĜijatých zpráv je potĜeba vytvoĜit 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 ĜetČzce 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ží tČlo 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 nČjaký 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 tĜi 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Č pĜiložit. Pole PĜíjem editovatelné není. Zobrazují se zde výpisy pĜijatých zpráv, a informace o pĜijatých souborech. Navíc se do tohoto pole vypisují i všechna chybová hlášení. Aplikace se ukonþí výbČrem 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 vidČt, že user agent využívá službu +g.oma.sip-im. PĜenos zprávy probČhne pomocí protokolu TCP a MRSP na portu 4000. Atribut sendonly znaþí, že se bude jednat o jednosmČrný pĜenos a atribut filesize udává velikost pĜenáš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 pĜenosu. Ihned po donþení pĜenosu odesílá user2 zprávu [7] BYE, kterou ukonþí relaci.
ͲϰϭͲ
Obr.8.3 Odeslání zprávy
ͲϰϮͲ
9 ZÁVċR BČhem 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 architektuĜe této technologie a jak napomáhají spolupráci s jinými sítČmi. Tyto funkce mohou být soustĜedČny do jednoho zaĜízení nebo distribuovány v rĤzných þástech sítČ, což usnadĖuje její správu. Popsal jsem vlastnosti nejþastČji používaných protokolĤ a jejich využití v IMS. PodrobnČ jsem rozebral základní procedury registrace a navazování relace. PĜedevším jsem si všímal, jaké parametry obsahují pĜenášené zprávy a jak se tyto parametry mČní pĜi prĤchodu zpráv pĜes jednotlivé prvky architektury. Dále mČ zajímal systém zabezpeþení a nakládání s informacemi o uživatelích. Všiml jsem si, že kvĤli lepšímu zabezpeþení komunikace, je pĜi tČchto procedurách nutné pĜenášet vČtší množství zpráv než u bČžné SIP relace. Seznámil jsem se s programem Service Development Studio spoleþnosti Ericson. Zjistil jsem jak v tomto programu fungují a jak se pracuje se simulátory jednotlivých prvkĤ IMS sítČ. VytvoĜil 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 uskuteþnil VoIP hovor a sledoval jsem, jak probíhá vyjednávání ustavení relace, nastavování parametrĤ spojení a jak se v prĤbČhu hovoru dají tyto parametry zmČnit. VytvoĜil jsem Java aplikaci, která plní funkci klienta pro IMS instant messaging. Popsal jsem nejdĤležitČjší metody potĜebné pro její správnou þinnost. Poté jsem si mezi dvČma poþítaþi zasílal krátké textové zprávy a pĜiložil k nim i testovací soubor. PĜenos probČhl podle oþekávání, relace protokolu MSRP byla úspČšnČ navázána a text i soubor byly doruþeny. I zde jsem podrobnČ sledoval a rozebral obsah pĜenášených zpráv, zajímal jsem se pĜedevším o zprávy INVITE, pomocí kterých se vytváĜí relace pro pĜenos.
ͲϰϯͲ
SEZNAM POUŽITÉ LITERATURY: [1]
POIKSELKA, Miikka, MAYER, Gregor, KHARTABIL, Hisham. The IMS: IP Multimedia Concepts and Services. Second edition. England : WILEY, 2006. 431 s. ISBN 0-470-01906-9
[2]
CAMARILLO, Gonzalo, GACÍA-MARTÍN, Miguel A. The 3G IP Multimedia Subsystem (IMS). Second edition. England : WILEY, 2006. 427 s. ISBN 0470-01818-6
[3]
RUSSEL, Thomas, The IP Multimedia Subsystem (IMS): Session Control and Other Network Operations. First edition. McGRAW-HILL Communications. 2007 ISBN 978-0-07-148853-2
[4]
SINNREICH, H., JOHNSTON, A. B. Internet Communications Using SIP: Delivering VoIP and Multimedia Services with Session Initiation Protocol. First edition. Canada: Wiley, 2006. ISBN 978-0471776574
[5]
PERKINS, Colin. RTP: Audio and Video for the Internet. First edition. Addison Wesley. 2003. 432 s. ISBN 0-672-32249-8
[6]
CAMARILLO, Gonzalo. SIP Demystified. First edition. McGraw-Hill Publishing. 2001. 264 s. ISBN 0-07-137340-3
[7]
Service Development Studio (SDS) 4.1 Developer's Guide, 198 17-APR 901 753/3
ͲϰϰͲ
SEZNAM PěÍLOH PĜíloha 1: Zdrojový kód aplikace IMSM Klient
ͲϰϱͲ
