Podpora architektury IP Multimedia Subsystem ve vývojovém prostředí SDS Ericsson 4.1

Transkript

1 Rok / Year: Svazek / Volume: Číslo / Number: Podpora architektury IP Multimedia Subsystem ve vývojovém prostředí SDS Ericsson 4.1 Support of IP Multimedia Subsystem in the development tool SDS Ericsson 4.1 Ľuboš Nagy, Vít Novotný, Tomáš Mácha lubos.nagy@phd.feec.vutbr.cz,novotnyv@feec.vutbr.cz, tomas.macha@phd.feec.vutbr.cz Fakulta elektrotechniky a komunikačních technologií VUT v Brně Abstrakt: Článek se zabývá podporou architektury IP Multimedia Subsystem v prostředí SDS. Je zde uveden praktický návrh realizace služeb pro sledování dostupnosti uživatelů a služby pro přenos hlasu ve studiu SDS Ericsson 4.1 a jejich možnost nasazení jako Java aplikace pro emulátor OS Symbian a pro Windows XP s použitím platformy ICP (IMS Client Platform). Při realizaci hlasového přenosu je posouzena i kvalita služby. V závěru článku je znázorněn průběh vytvoření relace zachycené v protokolovém analyzátoru WireShark a ve Visual Traffic Flow poskytovaném prostředím SDS Ericsson. Abstract: This paper presents the IP Multimedia Subsystem in the development tool SDS Ericsson 4.1. The possibility of Java application employment using ICP platform to provide the present and VoIP services is discussed.

2 PODPORA ARCHITEKTURY IP MULTIMEDIA SUBSYSTEM VE VÝVOJOVÉM PROSTŘEDÍ SDS ERICSSON ÚVOD Ľuboš Nagy, Vít Novotný, Tomáš Mácha Vysoké učení technické v Brně, Fakulta elektrotechniky a komunikačních technologií, Ústav telekomunikací, Purkyňova 118, Brno, Česká republika lubos.nagy@phd.feec..vutbr.cz, novotnyv@feec.vutbr.cz, tomas.macha@phd.feec.vutbr.cz Článek se zabývá podporou architektury IP Multimedia Subsystem v prostředí SDS. Je zde uveden praktický návrh realizace služeb pro sledování dostupnosti uživatelů a služby pro přenos hlasu ve studiu SDS Ericsson 4.1 a jejich možnost nasazení jako Java aplikace pro emulátor OS Symbian a pro Windows XP s použitím platformy ICP (IMS Client Platform). Při realizaci hlasového přenosu je posouzena i kvalita služby. V závěru článku je znázorněn průběh vytvoření relace zachycené v protokolovém analyzátoru WireShark a ve Visual Traffic Flow poskytovaném prostředím SDS Ericsson. IP Multimedia Subsystem (IMS) je generická architektura sloužící jako standard podpory moderních telekomunikačních služeb pro konvergenci pevných a mobilních sítí, podporujících přístupy jako jsou např.: GSM (Global System for Mobile communications), GPRS (General Packet Radio System), EDGE (Enhanced Data rates for GSM Evolution), WiMAX (Worldwide Interoperability for Microwave Access), WLAN (Wireless Local Area Network), DSL (Digital Subscribe Line) a jiné [1]. Poskytování služeb uživatelům je v IMS řešeno prostřednictvím aplikačních serverů (AS). AS komunikují s IMS (s entitou CSCF Call Session Control Function) pomocí protokolu SIP (Session Initiation Protocol), který je zároveň i hlavním signalizačním protokolem v systému IMS nebo prostřednictvím protokolu DIAMETER (v případě signalizace s HSS Home Subscribe Server). Díky vzájemné spolupráci mezi servery AS dokáže subsystem IMS poskytnout uživatelům klientských aplikací různé služby pro různé přístupové sítě a různá koncová zařízení. Kromě již zmíněných entit CSCF a HSS (umístěných na tzv. řídicí vrstvě) obsahuje i další prvky zabezpečující kompletní funkcionalitu systému. Entity IMS technologie je možné rozdělit na šest skupin [1]: management relací a směrovaní (P/I/S-CSCF), databáze (HSS, SLF Subscription Locator Function), služby (AS, MRF Media Resource Function), prvky pro vnitřní komunikaci s hlavními entitami (BGCF Breakout Gateway Control Function, MGCF Multimedia Gateway Control Function, IM- MGW IMS Media Gateway, SGW Signalling Gateway), pomocné entity (PCRF Policy and Charging Rules Function, SEG Security Gateway, IBCF Interconnection Border Control Function, TrGW Transition Gateway, LRF Location Retrieval Function), 21-1 a entity pro funkci zpoplatnění VÝVOJOVÉ PROSTŘEDÍ SDS ERICSSON 4.1 Vývojové studio SDS Ericsson, založeno na IDE Eclipse 3.4, poskytuje programátorům možnosti pro realizaci a simulaci některých služeb v rámci architektury IMS. Mezi zmiňované služby patří např. PGM (Presence and Group Management), VoIP (Voice over IP), PTT (Push-To-Talk). Přímo v tomto vývojovém prostředí od firmy Ericsson jsou obsaženy i síťové simulátory IMS technologie (P/I/S- CSCF, BGCF, HSS, DNS a ENUM) a ICP [2] platforma (IMS Client Platform), která poskytuje podporu v OS Windows XP (Vista) a OS Symbian 9.1. Kromě těchto simulátorů SDS obsahuje i podporu pro koncová zařízení, v podobě možnosti vývoje projektů pro platformu JavaME pro mobilní telefony, jenž je ve vývojovém prostředí SDS implementována pod označením IJCU IMS JavaME Client Utility. Také se nabízí možnost vývoje vlastních aplikací vytvářených jako JavaEE/SIP a spouštěných na integrovaném aplikačním serveru. Kromě výše zmíněných možností, SDSS studio má přímo v sobě implementovány i testovací nástroje (Test Agents, ATF Automatic Test Framework) ) i VTF Visual Traffic Flow, který slouží ke znázornění SIP komunikaci Java aplikace s IMS simulátorem) [3]. 2. PRAKTICKÁ REALIZACE SLUŽEB V SDS V této kapitole je ukázána možnost návrhu IMS projektu ve vývojovém prostředí SDS Ericsson, a to v podobě realizací J2SE a J2EE/SIP aplikací. V případě J2SE projektů se jedná o klientské moduly spuštěné v emulátoru OS Symbian a o desktopové aplikace pro Windows XP. Na J2EE/SIP aplikaci je znázorněna podpora programování servlet aplikace (modulu pro přístup a správu databáze) testované v SDS na integrovaném aplikačním serveru. Navrhované řešení projektu (viz Obr. č. 1) pro podporu síťových služeb v rámci subsystému IMS v oblasti služeb sledování dostupnosti uživatelů a služby pro přenos hlasu je možné rozdělit do třech logických částí: databáze uživatelů, modul pro přístup a správu databáze,

3 klientský modul. Aplikace jsou testovány na třech osobních počítačích (PC). Osobní počítače PC1 (IP: ) a PC3 ( ) představují klientskou část projektu, osobní počítač PC2 (IP: ) je určen pro testování chování entit: simulátoru IMS, poskytovaném prostředím SDS, modulu pro přístup a správu databáze uživatelů, navrhované databáze. Vzhledem k tomu, že není možné spouštět ICP platformu pod OS Windows vícekrát, je nutné pro simulaci hlasové služby, testovat klientský modul i na PC3. Klientská aplikace je simulovaná jako Java aplikace pro PC pod OS Windows XP a jako aplikace spustitelná pro emulátor OS Symbian. Z důvodu, že v obou případech se uživatelé registrují do simulátoru IMS pomocí integrované platformy ICP, bylo vývojové prostředí SDS nainstalováno i na osobní počítače PC1 a PC3. Problematika vývoje aplikací pro OS Symbian byla pojednána už v [4]. Obr. č. 1: Grafické znázornění projektu pro poskytování prezenčních a hlasových služeb 2.1. DATABÁZE APLIKACE Jako úložiště informací o uživatelích aplikace pro poskytovaní služeb v rámci realizovaného projektu slouží databáze složená z devíti entit (viz Obr. č. 2): User, Uri, Presence, List, Status, AccountType, SpecialServices, StandardServices a Services. Tabulka User obsahuje základní přístupové informace o klientech, kterým je umožněno využívat navrženou aplikaci. Pro ověření tohoto uživatele přihlašujícího se do aplikace jsou využity položky NICK a PASS. Kromě těchto položek entita User obsahuje i a DATE. určuje kontaktní uživatele aplikace, na který mu bude zasláno nové heslo v případě zapomenutí hesla starého. DATE vyjadřuje časový údaj určující změnu již zmíněných údajů (např. při změně přihlašovacího hesla) a poskytování možnosti varování uživatele v případě užívání již zastaralého hesla (v projektu je platnost hesla nastavená na jeden rok). Další definovanou entitou v databázi je tabulka Uri, ve které se nacházejí informace o registrovaných SIP URI jednotlivých klientech. Při návrhu databáze je zohledněna skutečnost, že jeden klient se může stát vlastníkem více účtů, rozlišujících se navzájem pomocí SIP URI (např. pracovní, soukromé, atd.). Tyto účty jsou identifikovatelné v rámci databáze prostřednictvím primárního klíče IDuri, popřípadě, v samotné aplikaci pomocí názvu účtu (viz Obr. č. 2 - NameUri), definovaný uživatelem při jeho vytváření. Toto řešení umožňuje stav, kdy uživatel aplikace může mít odlišné informace o své dostupnosti pro každý svůj účet (například pro pracovní: online, pro soukromý: offline). V rámci navrhované databáze je u každého uživatele řešen i seznam dostupných služeb, které má klient aktivovány. Pro určení, ke kterému URI má klient aktivován jaký balík služeb, je v této entitě definovaná i položka IDaccount, vztahující se k tabulce AccountType. Samotné služby poskytované provozovatelem aplikace jsou definovány v entitě Services (např. služba pro poskytování informací o dostupnosti klientů). Poskytovatel může tyto služby nabízet jako balík služeb nebo samostatně jako tzv. doplňkovou službu. Pro rozlišení jednotlivých balíků služeb je definována tabulka AccountType. Například balík služeb s názvem premium (viz položka Name v tabulce AccountType) může obsahovat služby pro poskytování informací o dostupnosti klientů a službu pro přenos hlasu. Přiřazení jednotlivých služeb poskytovatelem je definováno pomocí spojovací tabulky StandardServices, a to prostřednictvím cizích klíčů IDaccount (identifikace balíku) a IDservice (identifikace služby). Táto entita je umístěna mezi tabulkami AccountType a Services, vůči kterým má vazbu N:1 (viz Obr. č. 2). Kromě služeb, které jsou nabízeny v balících, si klient může aktivovat tyto služby i jako samostatnou (doplňkovou) službu ke svému již aktivovanému balíku služeb. Toto je umožněno pomocí entity SpecialServices. Tato tabulka, podobně jako i StandardServices, má funkci spojovací tabulky pro entity Uri a Services. V obou případech (StandardServices a SpecialServices) se jedná o implementaci spojovací tabulky pro rozdělení vazby N:M na dvě vazby N:1. Vytvoření jednotlivých seznamů uživatelů pro klienta používajícího aplikaci je realizováno pomocí entity List. V této tabulce jsou definovány položky identifikující výše popsané informace v entitách User a Uri. Poslední entity tvořící databázi (Presence a Status) slouží jako úložiště informací, které blíže popisují stav dostupnosti daného klienta. Entita Status definuje dostupné stavy pro entitu Presence (např. offline, online, meeting). V tabulce Presence se nacházejí data o dostupnosti klientů. Tyto informace se vztahují na registrovaný účet daného uživatele. Data se skládají z informací o stavu klienta (IDstat, např. 6, tj. meeting) a bližšího popisu jeho stavu (Info, např. jsem na poradě do 14:00 ). Položky IDlaststatus a LastInfo slouží pro načtení informací o dostupnosti klienta po opětovném přihlášení se do klientské aplikace. 21-2

4 Obr. č. 2: Databáze pro uložení informací o klientech Položka Time, umožňuje uložení poslední aktualizace stavu klienta. Tento údaj je v projektu v pravidelných intervalech obnovován po přijetí SIP PUBLISH zprávy s aktualizovanými informacemi o klientově dostupnosti MODUL PRO PŘÍSTUP A SPRÁVU DATABÁZE Podobně jako předcházející popsaná část projektu, tak i modul pro přístup a správu databáze, vyvíjen jako SIP servlet aplikace, je spuštěn na PC2 (viz Obr. č. 1). Úlohou této aplikace je zabezpečení zpracování požadavků z klientských modulů a komunikace s databázovým serverem. Uživatel pošle prostřednictvím klientských modulů servlet aplikaci SIP požadavky, pomocí kterých si klient např. aktualizuje své informace o stavu dostupnosti (SIP PUBLISH), obnovuje údaje o dostupnosti uživatelů umístěných ve svém seznamu (SIP SUBSCRIBE, NOTIFY) atd. Jako už bylo výše zmíněno, uživatel pomocí klientského modulu zasílá v pravidelných intervalech (každé tři minuty) zprávu SIP PUBLISH pro aktualizaci vlastních informací popisující dostupnost vzhledem k ostatním klientům. Po každé výzvě ze strany klienta adresované servlet aplikaci je kromě informace o stavu uživatele aktualizována i položka Time, obsahující právě poslední pokus o obnovu vlastních údajů. Tento postup je zvolen z důvodu zabezpečení aktuálnosti informací o dostupnosti klienta, o které by mohli mít zájem ostatní uživatelé aplikace. Zprávu SIP PUBLISH klient zasílá i v okamžiku změny svého statusu. Na Obr. č. 3 je graficky znázorněna situace, kdy klient 1, z blíže nespecifikovaných důvodů (např. neregulérní vypnutí aplikace), přestane posílat zprávy obsahující aktualizace svého stavu dostupnosti. Klient 2 (viz Obr. č. 3) má klienta 1 na svém seznamu. Po přijetí požadavku (SIP SUBSCRIBE) o zaslání informací týkajících se klienta 1, je před posláním těchto dat, kontrolován v servlet aplikaci údaj určující čas poslední obnovy klienta 1. V případě, že modul pro přístup a správu databáze zjistí, že údaje oklientu (klient 1) jsou staré (starší než je povolený časový limit 10 minut), vyzve tohoto klienta k obnově svých informací o dostupnosti. V případě, že klient 1 nereaguje ani na tuto vyzvu, servlet aplikace automaticky zašle dotazujícímu se uživateli zprávu informující, že stav dostupnosti klienta 1 je NDF (v zprávě SIP NOTIFY), tj. uživatel je nedostupný pro komunikaci s ostatními uživateli aplikace. Na Obr. č. 3 je tento scénář znázorněn seznam klienta 2 obsahuje i klienta 1, ke kterému má přiřazen status NDF i navzdory tomu, že v úložištii dat je stav klienta 1 nastaven na hodnotu online. Obr. č. 3: Zjednodušený princip významu časové obnovy informace [5] 2.3. KLIENTSKÝ MODUL Tento modul poskytuje grafické rozhraní umožňující použití služeb sledování dostupnosti jednotlivých klientů a pro přenos hlasu mezi nimi. Komunikace, umožňující uskutečňovat požadavky pro splnění definovaných služeb v rámci navrhovaného projektu vysílaných z klientských modulů, je možné rozdělit podle typu činnosti účastníka: databáze operace: o registrace klienta, o autentizacee (ověření totožnosti), 21-3

5 o řízení služby: o o Obr. č. 4: Porovnaní aplikace pro OS Windows XP a OS Symbian emulátor [5] dostupnost služeb poskytovaných uživatelům (viz Obr. č. 2 entita Services), autorizace služby (zjištění oprávnění klienta využívat službu), řízení relace (budování, udržování a ukončení), přenos uživatelské informace v průběhu uskutečňování služby. Modul je vyvíjen pro možnost nasazení do emulátoru OS Symbian (P1i a M600) a pro použití jako desktopové aplikace spuštěné v OS Windows XP (viz Obr. č. 4). 3. PRŮBĚH KOMUNIKACE VYTVOŘENÝCH SLUŽEB 3.1. PROCES REGISTRACE UŽIVATELE Vzhledem, k tomu, že při procesu registrace je použita ICP platforma (kterou je možné využívat i pro OS Symbian emulátor) implementovaná výrobcem vývojového prostředí, nebude v článku tento proces podrobněji popsán. Samotný proces registrace se skládá z žádosti SIP REGISTER zaslané uživatelskou aplikací k simulátoru IMS. V případě správně zadaných přihlašovacích údajů se klient v systému IMS zaregistruje a tato skutečnost je mu potvrzena odpovědí SIP OK KOMUNIKACE PŘI SLEDOVÁNÍ DOSTUPNOSTI KLIENTŮ Signalizace pro poskytování této služby se skládá prakticky ze třech SIP zpráv, a to ze SIP PUBLISH, SUBSCRIBE a NOTIFY, a probíhá v pravidelných intervalech. Signalizace typu PUBLISH se využívá v případě, že si klient aktualizuje informace o dostupnosti v úložišti dat 21-4 projektu prostřednictvím servlet aplikace. Zpráva ve svém těle přenáší informace ve formátu XML (extensible Markup Language), kdy jednotlivé informační prvky začínají a končí párovým tagem presence. V rámci tohoto tagu jsou definovány entity přenášející přímo data o stavu klienta (např. meeting ) a podrobnější popis k statusu (např. do 14:00 ).. Vzhledem, ke skutečnosti, že tyto informace se po zpracování servlet aplikací ukládají na databázovém serveru, je potřebné, aby se v rámci XML formátu posílaly i údaje pro ověření uživatele. Tyto informace jsou obsaženy v těle XML jako entity userlogin a userpass a po zpracování modulem pro přístup a správu databáze se porovnají s údaji uloženými v databázi. Vzhledem k tomu, že se přenášejí i uživatelově citlivé údaje, komunikace je šifrována. V případě shody těchto údajů je proces aktualizace stavu dostupnosti uživatele úspěšný a informace o něm jsou zapsány do úložiště dat. Poslední entitou definovanou v rámci těla SIP PUBLISH je contact, ve kterém se přenáší SIP URI uživatele. Vzhledem k tomu, že navrhovaný projekt má realizovat tzv. prezenční službu, musí být ve zprávě PUBLISH doplněny povinné hlavičky pro tuto síťovou službu. Těmito hlavičkami jsou: Expires, Event a Content-Type. Hodnota Expires je nastavena na 3600 (s), Event na presence a Content-Type na application/pidf+xml" [6]. Procedura aktualizace probíhá i během procesu vypínání klientské aplikace. V tomto případě, nemá uživatel možnost nastavit přímo svůj zveřejňovaný status dostupnosti (ten se automaticky přepne do režimu offline), ale je mu umožněno nastavení pro podrobnější popis důvodu své nepřítomnosti. Pro zjištění informace o dostupnosti klientů umístěných v seznamu uživatele slouží signalizace pomocí zpráv SUBSCRIBE a NOTIFY. Prostřednictvím SUBSCRIBE klientský modul žádá servlet aplikaci o informace týkající se stavu ostatních klientů, které mu servlet zašle v odpovědi NOTIFY. Klientský modul zprávu přijme a

6 po zpracování zobrazí informace o uživatelích v aplikaci (viz Obr. č. 4). Vzhledem ke skutečnosti, že se opět, tak jako v případě PUBLISH, jedná o signalizaci v rámci tzv. prezenčních služeb, jsou definovány pro SUBSCRIBE, hlavičky Supported ( eventlist ), Event ( presence ), Expires ( 3600 (s)) a Accept ( application/rlmi+xml, application/pidf+xml, multipart/related ) [6]. Po obdržení tohoto požadavku, servlet aplikace potvrdí příjem zprávy pomocí SIP OK a vygeneruje odpověď NOTIFY pomocí dat uložených v databázi. Kromě povinných hlaviček, specifikovaných v [7] zpráva obsahuje i entity blíže definující službu sledování dostupnosti klientů. Konkrétně se jedná o Event ( presence ), Require ( eventlist ), Expires ( 3599 (s)), subscription-state ( active; expires=3599 nebo terminated; deactivated ), Content-Type (obsahuje multipart/related s hodnotou boundary) [6]. Parametr Require, který je dán hodnotou hlavičky Supported obsažené v SUBSCRIBE. Tělo NOTIFY zprávy má formát MIME (Multipurposee Internet Mail Extensions), ve kterém se přenášejí požadované informace o dotazovaných uživatelích. Informace o stavu dostupnosti daných uživatelů jsou rozděleny v MIME do sekvencí pomocí hodnoty boundary [8], definované v hlavičce Content-Type. Samotný MIME formát je možné rozdělit na dvě hlavní části. První, začínající entitou First boundary a končící párovým tagem list, obsahuje data o uživatelích, kterým se v druhé části MIME specifikují informace o dostupnosti (stav a doplňující informace o nastaveném stavu). Tato druhá část začíná právě končícím tagem list a je ukončena hodnotou Last boundary. První část je v rámci těla NOTIFY zprávy identifikovatelná pomocí hlavičky Content-ID, která nabývá hodnotu parametru start definovaným v hlavičce Content-Type. V této části jsou přenášeny základní informace o klientech, jako je jich SIP URI nebo jméno, pod kterým v dané službě vystupují. Kromě těchto údajů je při každém SIP URI definován parametr CID (Content ID), pomocí kterého jsou identifikována doplňující data o stavu dostupnosti uživatelů v druhé části MIME formátu. Tento identifikátor souhlasí s hodnotami Content-ID generovanými pro každého uživatele samostatně. Na základě této skutečnosti není problém přiřadit ke každému kontaktu definovanému v první části MIME formátu informace přenášené z úložiště dat v druhé části a po zpracování klientským modulem je zobrazit v aplikaci KOMUNIKACE PŘI HLASOVÉ SLUŽBĚ Jako už je v předcházející části zmíněno, hlavním rozdílem mezi službou sledování dostupnosti klientů a službou přenosu hlasu z pohledu signalizace v průběhu komunikace mezi entitami je ten, že v případě hlasové služby se jí neúčastní servlet aplikace. Při realizaci služby uskutečněné mezi klienty je použit RTP protokol (Real-time Transport Protocol) s AMR (Adaptive Multi-Rate) kodekem [9], používaným v současných GSM (Global System for Mobile communications) i v UMTS (Universal Mobile Telecommunications System) ) sítích. Na Obr. č. 5 je znázorněna změřená charakteristika parametru jitter v průběhu uskutečňování služby hlasového přenosu pro oba směry přenosu v paketovém analyzátoru WireShark. Hodnota parametru jitter je ustálená kolem 26 ms. V Tab. č. 1 jsou zobrazeny hodnoty pro maximální a průměrný jitter, maximální zpoždění a ztrátovost paketů. Obr. č. 5: Změřený průběh kolísaní zpoždění paketů při hlasové službě v programu WireShark Tab. č. 1: Naměřené parametry v programu WireShark Max. jitter Průměrný jitter ,54 ms 25,17 ms Max. zpoždění 95,26 ms Ztrátovost 0% V Tab. č. 2 je posouzena kvalita služby podle [10]. Nejhůře v porovnání dopadl parametr jitter a to s kvalitou vyhovující. Hraniční hodnota jittru pro kvalitu s hodnotou dobrá je 20 ms, což bylo mírně překročeno. Tab. č. 2: Kvalita neměřených parametrů Parametr Jitter Zpoždění Ztrátovost Kvalita Vyhovující Dobrá Dobrá Průběh spojení při realizaci hlasové služby je graficky znázorněn na Obr. č. 6. Relace pro navázání spojení mezi klienty pro přenos hlasu se skládá z SIP požadavku INVITE (Obr. č. 7) s definovaným SDP. V případě ,52 ms 25,18 ms 95,20 ms 0% 21-5

7 odmítnutí druhým klientem (klientem, který je vyzván k spojení) je relace zamítnuta pomocí zprávy SIP Decline Obr. č. 8. Po uskutečnění služby je relacee ukončená SIP zprávou BYE. Význam SDP (Session Description Protocol [11]) hlaviček při zakládání relace (Obr. č. 7) je následující: Version (v): verze SDP protokolu, Owner/Creator (o): identifikuje zdroj požadavku, skládá se z názvu tvůrce relace, ID relace, verze relace, typ sítě, typ adresy, adresa. Session Name (s): pojmenování relace, Connection Information (c): typ sítě (IN internet), typ adresy (IPv4), adresa připojení. Time Description (t): popis časového intervalu relace (čas začátku a konce relace) ), Media Description (m): typ přenosu, port a hodnota RTP/AVP (např. audio RTP/AVP 98), Media Attribute (a): popis parametrů použitého kodeku (AMR): o sendrecv: definuje, že se jedná o mód pro vysílání i příjem přenosu, o rtpmap: typ přenášených dat, identifikátor kodeku (AMR), clock rate (pro AMR 8000, pro AMR-Wpočet audio kanálů (defaultní hodnota 1) [9]), o fmtp: atribut definující parametry specifické pro formát přenášených dat (např. při audio přenosu) SIGNALIZACE PRO PODPŮRNÉ FUNKCE Kromě signalizace pro přímé poskytování služeb existuje v projektu signalizace zabezpečující tzv. podpůrné funkce. Pod pojmem podpůrná funkce se rozumí vše, co je spojeno s realizací relací pro uskutečnění následujících činností: přihlášení/odhlášení uživatele v aplikaci, správa uživatelského účtu, správa klientských SIP URI, správa kontaktů v uživatelském seznamu, správa přístupového hesla do aplikace, správa standardních a doplňkových služeb. Signalizace pro tyto podpůrné funkce probíhá za pomoci SIP protokolu, a to prostřednictvím požadavku INVITE (pro navázání spojení mezi aplikacemi klienta a servletu), MESSAGE (pro definování žádostí) a BYE (pro ukončení relace). Rozhodujícím faktorem pro rozlišení jednotlivých podpůrných funkcí je hodnota povinné hlavičky Content- vykonanou Type ve zprávě MESSAGE. Pro každou úspěšně žádost je potřebný přístup do databázového serveru Proto jsou nutnou součástí přenesené informace, které blíže specifikují požadovanou funkci v těle SIP MESSAGE, i přístupové informace uživatele (přihlašovací jméno a heslo). V Tab. č. 3 jsou znázorněny formáty možné uživatelské požadavky a reakcí servlet aplikace. Součástí odpovědí vygenerovaných servletem je i SIP MESSAGE obsahující nastavenou hlavičku Content-Type, definující úspěšnost žádosti, kterou vygenerovala klientská aplikace. V případě úspěšné realizacee podpůrné funkce je odpověď ve formátu: typ_pozadavku/ok{/info} ). Například při přihlašovaní se do aplikace je možná i odpověď s nastavenou hlavičkou Content-Type: login/ok/expiredpass informující o skutečnosti, že uživatelovo heslo je staré. V případě neúspěchu (viz Tab. č. 3 typ_pozadavku/wrong/info ) je popis důvodu obsažen v samotném těle zprávy MESSAGE. Například při zrušení účtu je možná i odpověď s nastavenou hlavičkou Content- s popisem informace Type: del_uri/wrong/sip o nesprávně zadaném SIP URI. Tab. č. 3: Formát nastavení hlavičky Content-Type v SIP MESSAGE Popis Odeslání požadavku Splnění požadavku Nesplnění požadavku z důvodu obsaženého v části info s podrobnějším popisem v těle SIP Message V realizovaném projektu se řeší i situace, když klient zapomene své přístupové heslo do aplikace pro využití služeb. V případě, že uživatel zašle požadavek o zaslání nového hesla na (definovaný v databázi pod položkou v entitě User) servlet aplikace po ověření uživatele, od kterého přijala SIP zprávu, vygeneruje nové heslo. Toto heslo se skládá z prvků abecedy, číslic a speciálních znaků o délce Takto generované heslo je uživateli zasláno na pomocí Java podpory JavaMail v samotné servlet aplikaci. Postup nového vytvoření hesla je zvolen z důvodu ukládání hesla ve tvaru hash kódu. V zaslaném u poskytovatel služby informuje uživatele aplikace o změně hesla a žádá ho o zadání vlastního (lépe zapamatovatelného) přístupového hesla po přihlášení se do aplikace. 4. ZÁVĚR Hlavička Content-Type typ_pozadavku/send typ_pozadavku/ok{/info} typ_pozadavku/wrong/info V článku je popsán návrh aplikace vyvíjené pro IMS platformu v prostředí SDS od firmy Ericsson. Vytvořený příklad projektu poskytuje služby pro zjištění dostupnosti

8 klienta a službu hlasového přenosu. Tyto služby je možné uživatelům poskytovat jako samostatné služby nebo ve formě speciálních balíčků. Prezenční služba (služba sledování dostupnosti klientů) je založena na SIP signalizaci při posílání zpráv PUBLISH (pro obnovu informací popisujících stav dostupnosti klienta), SUBSCRIBE (žádost pro zaslání údajů popisujících stav uživatelů umístěných v seznamu klienta) a NOTIFY (vygenerované informace popisující prezenční stav uživatelů). Vzhledem ke skutečnosti, že všechny informace se při této službě zjišťují právě z databázového serveru a ne přímo od klientů, je nutné řešit problematiku aktuálnosti poskytovaných údajů. Informace o své dostupnosti si každý klient obnovuje v pravidelných intervalech (v projektu každé tři minuty) sám, nebo po každé změně svého statusu. Při každé aktualizaci se změna údajů zaznamená přímo do úložiště dat. Proto v okamžiku, kdy servlet aplikace zpracuje žádost SUBSCRIBE, ještě před vygenerováním obsahu MIME v NOTIFY, kontroluje servlet aplikace v databázi právě časový údaj poslední aktualizace informací. V případě, že poslední obnova klienta je starší než povolený časový limit (v projektu 10 minut), klient je servlet aplikací vyzván o obnovu informací o své dostupnosti. V případě, že klientský modul neodpovídá na tuto žádost, bez ohledu na to, jaké má uživatel nastaveny informace o své dostupnosti, servlet aplikace zasílá prostřednictvím NOTIFY údaj NDF a klient je označen jako nedostupný uživatel. Hlasová služba využívá protokol RTP s kodekem AMR. Tak jako služba sledování dostupnosti, tak i tato služba se simuluje pro nasazení aplikace pod OS Windows XP a pro emulátor OS Symbian (P1i a M600). Vzhledem k tomu, že projekt je vyvíjen s podporou integrované ICP platformy [2], která není plně funkční pro přenos hlasu v emulátoru OS Symbian, byla tato služba nakonec zprovozněna pouze jako aplikace pro OS Windows XP. V průběhu simulace hlasové služby byly zaznamenány i parametry zpoždění a jitter pomocí paketového analyzátoru WireShark. Jejich hodnoty pro oba směry jsou zapsáni v Chyba! Nenalezen zdroj odkazů., maximální jitter (26,54 ms a 26,52 ms), průměrný jitter (25,17 ms a 25,18 ms), zpoždění (95,26 ms a 95,20 ms) a ztrátovost paketů (0% v obou směrech). Podle ITU (Iternational Telecommunication Union) má byt zpoždění menší než 150 ms a ztrátovost paketů do 0,5 %, což realizovaná aplikace dostatečně splňuje. V případě hodnot jittru je mírně nad hranicí doporučené hodnoty (20 ms). Z těchto měření lze tedy odvodit, že aplikace je vhodná pro reálné využití. Funkčnost celého realizovaného projektu byla ověřena pouze na uvedených simulátorech dostupných ve studiu SDS, a tedy bez testování v reálné IMS síti. LITERATURA [1] POIKSELKÄ, M., MAYER, G. The IMS: IP Multimedia Concepts and Services. WILEY, s. Třetí vydaní. ISBN [2] Ericsson. Service Development Studio (SDS) 4.1 ICP API Documentation [3] Ericsson. Service Development Studio (SDS) 4.1 Technical Description. [online] Dostupný z WWW: < hnologies/ims_poc/docs/tech_desc_sds_40> [4] NOVOTNÝ, V., MÁCHA, T.: Aplikace pro mobilní terminály s operačním systémem Symbian. Elektrorevue Internetový časopis ( 2009, č. 67, s ISSN: [5] NAGY, Ľ. Tvorba IMS aplikací (Diplomová práce, vedoucí Ing. Tomáš Mácha.). Vysoké učení technické v Brně, Fakulta elektrotechniky a komunikačních technologií, Brno, s. [6] Ericsson. Service Development Studio (SDS) 4.1 Developer Guide. [online] Dostupný z WWW: < hnologies/ims_poc/docs/sds_40_dev_guide> [7] ROSENBERG, J., SCHULZRINNE, H., CAMARILLO, G., JOHNSTON, A., PETERSON, J., SPARKS, R., HANDLEY, M., SCHOOLER, E. SIP Session Initiation Protocol. RFC 3261, IETF [online]. 2002, [cit ]. Dostupný z WWW: < [8] FREED, N., BORENSTEIN, N. Multipart Internet Mail Extensions (MIME) Part Two: Media Types. RFC 2046, IETF, [online]. 1996, [cit ]. Dostupný z WWW: < [9] SJOBERG, J., WESTERLUND, M., LAKANIEMI, A., XIE, Q. Real-Time Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Mutli-Rate Wideband (AMR-WB) Audio Codecs. RFC 3267, IETF [online]. 2002, [cit ]. Dostupný z WWW: < [10] KOVÁŘ, P., MOLNÁR, K., NOVOTNÝ, V.: Současnost a budoucnost VoIP sítí. Elektrorevue Internetový časopis ( 2007, s ISSN: [11] HANDLEY, M., JACOBSON, V., PERKINS, C. SDP Session Description Protocol. RFC 4566, IETF [online]. 2006, [cit ] Dostupný z WWW: < PODĚKOVÁNÍ Tento článek vznikl na základě podpory FRVŠ projektů (FRVŠ 2954/2010/F1a a FRVŠ 2986/2010/G1). 21-7

9 Obr. č. 6: Výstup z aplikace WireShark zachycující komunikaci mezi aplikačními entitami při hlasovém přenosu (zachycen na PC1) Obr. č. 7: Výstup z aplikace WireShark zachycující komunikaci mezi aplikačními entitami při realizaci relace pro hlasový přenos pomocí SIP INVITE 21-8

10 Obr. č. 8: Diagram SIP signalizace v průběhu vytváření spojení pro hlasovou službu zachycen pomocí Visual Traffic Flow v prostředí SDS Ericsson (vlevo: úspěšné vytvoření a ukončení relace pro hlasový přenos, vpravo: odmítnutí vytvoření spojení klientem s IP adresou ) 21-9