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

Rok / Year: 2010

Svazek / Volume: 12

Číslo / Number: 2

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 [email protected],[email protected], [email protected] 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.

2010/21 – 30. 3. 2010

VOL.12, NO.2, APRIL 2010

PODPORA ARCHITEKTURY IP MULTIMEDIA SUBSYSTEM SUBSYS VE VÝVOJOVÉM PROSTŘEDÍ SDS ERICSSON 4.1 Ľ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, 612 00 Brno, Česká republika Email: [email protected], [email protected] [email protected], [email protected] [email protected] Č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 ž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 kolovém analyzátoru WireShark a ve Visual Traffic Flow poskytovaném prostředím SDS Ericsson.

•

1. ÚVOD

1.1. VÝVOJOVÉ PROSTŘEDÍ SDS ERICSSON 4.1

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 Global System for Mobile communications), 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 Digital Subscribe Line) Line a jiné [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é ňované služby patří např. PGM (Presence ( and Group Management), VoIP (Voice Voice over IP), 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) 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 ko JavaEE/SIP a spouštěných na integrovaném aplikačním serveru. Kromě výše zmíněných možností, SDS 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í ění SIP komunikaci Java aplikace s IMS simulátorem) [3].

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) Function pomocí protokolu SIP (Session Session Initiation Protocol), 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). 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 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 P/I/S-CSCF),

•

databáze (HSS, SLF – Subscription Locator Function),

•

služby (AS, MRF – Media Resource Function), Function

•

prvky pro vnitřní komunikaci s hlavními entitami (BGCF – Breakout Gateway Control Function, MGCF – Multimedia Gateway Control Function, IMIM MGW – IMS Media Gateway, SGW – Signalling Gateway),

•

a entity pro funkci zpoplatnění.

2. PRAKTICKÁ REALIZACE SLUŽEB S 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í ramová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í:

pomocné entity (PCRF – Policy and Charging Rules Function, SEG – Security Gateway, IBCF – Interconnection Border Control Function, TrGW – Transition Gateway, LRF – Location Retrieval Re Function), 21-1

•

databáze uživatelů,

•

modul pro přístup a správu databáze,

2010/21 – 30. 3. 2010 •

VOL.12, NO.2, APRIL 2010

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, IDaccount vztahující se k tabulce AccountType.

klientský modul.

Aplikace jsou testovány na třech osobních počítačích (PC). Osobní počítače PC1 (IP: 147.229.151.118) 147.229.151.118 a PC3 (147.229.151.114) představují klientskou část projektu, osobní počítač PC2 (IP: 147.229.151.115) 147.229.151.115 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].

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 luž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 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, 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 j 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.

Obr. č. 1: Grafické znázornění projektu pro poskytování prezenčních a hlasových služeb

2.1. DATABÁZE APLIKACE

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.

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, kliente 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 EMAIL a DATE. EMAIL určuje kontaktní e-mail e 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ř. (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). rok

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 infor 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í ormací o dostupnosti klienta po opětovném přihlášení se do klientské aplikace. 21-2

2010/21 – 30. 3. 2010

VOL.12, NO.2, APRIL 2010

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.

klienta 1. V případě, že modul pro přístup a správu databáze zjistí, že údaje o klientu (klient 1) jsou staré (starší starší než je povolený časový limit 10 minut), 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 do 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šti dat je stav klienta 1 nastaven na hodnotu online.

2.2. MODUL PRO PŘÍSTUP ŘÍSTUP A SPRÁVU DATABÁZE DATA 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 lech (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.

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í 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:

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

•

21-3

databáze operace: o

registrace klienta,

o

autentizace (ověření ( totožnosti),

2010/21 – 30. 3. 2010

VOL.12, NO.2, APRIL 2010

Obr. č. 4:: Porovnaní aplikace pro OS Windows XP a OS Symbian emulátor [5] o •

•

dostupnost služeb poskytovaných uživatelům (viz Obr. č. 2 entita Services),

projektu prostřednictvím servlet aplikace. Zpráva ve svém těle přenáší informace ve formátu XML (eXtensible eXtensible Markup Language), Language kdy jednotlivé informační prvky začínají jí 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“) „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 dost 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.

řízení služby: o

autorizace služby (zjištění oprávnění klienta využívat službu),

o

řízení relace (budování, udržování a ukončení),

přenos uživatelské uskutečňování služby.

informace

v průběhu

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

VYT VYTVOŘENÝCH

SLUŽEB

3.1. PROCES REGISTRACE 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, Expires Event a Content-Type. Hodnota Expires je nastavena na „3600“ „ (s), Event na „presence“ a Content-Type Type na „application/pidf+xml" [6].

Vzhledem, k tomu, že při procesu registrace je použita ICP platforma (kterou 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.

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

3.2. KOMUNIKACE PŘI SLEDOVÁNÍ Á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.

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 servle zašle v odpovědi NOTIFY. Klientský modul zprávu přijme a

BLISH se využívá v případě, že si Signalizace typu PUBLISH klient aktualizuje informace o dostupnosti v úložišti dat 21-4

2010/21 – 30. 3. 2010

VOL.12, NO.2, APRIL 2010

po zpracování zobrazí informace o uživatelích v aplikaci (viz Obr. č. 4). Vzhledem ke skutečnosti, č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/rlmi+xml, application/pidf+xml, multipart/related“) [6] [6]. Po obdržení tohoto požadavku, servlet aplikace potvrdí příjem zprávy pomocí SIP OK a vygeneruje odpověď věď 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í ání dostupnosti klientů. Konkrétně se jedná o Event („presence presence“), Require („eventlist“), Expires („3599“ (s)), subscription-state subscription („active; expires=3599“ nebo „terminated; deactivated“), deactivated“ Content-Type (obsahuje „multipart/related 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 (Multipurpose Multipurpose Internet Mail Extensions), ve kterém se přenášejí požadované informace o dotazovaných uživatelích.

communications) i v UMTS Telecommunications System)) sítích.

( (Universal

Mobile

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 H 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

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, Content 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.

147.229.151.114

147.229.151.118

›››

›››

147.229.151.118

147.229.151.114

Max. jitter

26,54 ms

26,52 ms

Průměrný jitter

25,17 ms

25,18 ms

Max. zpoždění

95,26 ms

95,20 ms

Ztrátovost

0%

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ž c bylo mírně překročeno. Tab. č. 2: Kvalita neměřených parametrů

3.3. KOMUNIKACE PŘI HLASOVÉÉ SLUŽBĚ

Parametr

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.

Jitter

Vyhovující

Zpoždění

Dobrá

Ztrátovost

Dobrá

Při realizaci služby uskutečněné mezi klienty je použit RTP protokol (Real-time time Transport Protocol) Protocol s AMR (Adaptive Multi-Rate) kodekem [9] [9], používaným v současných GSM (Global Global System for Mobile

Kvalita

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ě 21-5

2010/21 – 30. 3. 2010

VOL.12, NO.2, APRIL 2010

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 relace ukončená SIP zprávou BYE.

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

Session Description Protocol [11]) hlaviček Význam SDP (Session při zakládání relace (Obr. č. 7)) je následující: následující

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, Content definující úspěšnost žádosti, kterou vygenerovala klientská aplikace. V případě úspěšné realizace podpůrné funkce je odpověď ve formátu: „typ_pozadavku/ok{/info} typ_pozadavku/ok{/info}“). Například při přihlašovaní se do aplikace je možná i odpověď s nastavenou hlavičkou Content Content-Type: „login/ok/expiredPass““ informující o skutečnosti, že uživatelovo heslo je staré.

•

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 10004 100 RTP/AVP 98),

neúspěchu (viz Tab. č. 3 V případě „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 ContentContent Type: „del_uri/wrong/sip del_uri/wrong/sip“ s popisem informace o nesprávně zadaném SIP URI.

•

Media Attribute (a): popis parametrů použitého kodeku (AMR):

Tab. č. 3: Formát nastavení vení hlavičky Content-Type Content v SIP MESSAGE

o o

o

sendrecv: definuje, že se jedná o mód pro vysílání i příjem přenosu, rtpmap: typ přenášených dat, identifikátor kodeku (AMR AMR), clock rate (pro AMR 8000, pro AMR--WB 16000 [9]), počet audio kanálů (defaultní defaultní hodnota 1). 1 fmtp: atribut definující parametry specifické pro formát přenášených dat (např. při audio přenosu). ).

3.4. SIGNALIZACE PRO PODPŮRNÉ 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. služeb

Popis

Hlavička Content-Type

Odeslání požadavku

typ_pozadavku/send

Splnění požadavku

typ_pozadavku/ok{/info}

Nesplnění požadavku z důvodu obsaženého v části info s podrobnějším popisem v těle SIP Message

typ_pozadavku/wrong/info

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 email ( (definovaný v databázi pod položkou Email v entitě User) 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 8-12. 8 Takto generované heslo je uživateli zasláno na email 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 emailu 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.

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), 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 ContentType ve zprávě MESSAGE. Pro každou úspěšně vykonanou žádost je potřebný přístup do databázového serveru.

4. ZÁVĚR 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 21-6

2010/21 – 30. 3. 2010

VOL.12, NO.2, APRIL 2010

klienta a službu hlasového přenosu. su. Tyto služby je možné uživatelům poskytovat jako samostatné služby nebo ve formě speciálních balíčků.

LITERATURA [1] POIKSELKÄ, M.,, MAYER, G. G The IMS: IP Multimedia Concepts and Services.. WILEY, WI 2009. 560 s. Třetí vydaní. ISBN 978-0-470 470-72196-4.

Prezenční služba (služba služba sledování dostupnosti klientů) klientů je založena na SIP signalizaci při posílání zpráv PUBLISH (pro obnovu informací popisujících stav av dostupnosti klienta), SUBSCRIBE (žádost pro zaslání údajů popisujících stav uživatelů umístěných v seznamu klienta) klienta a NOTIFY (vygenerované 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í jišť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) minut 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í oslední 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.

[2] Ericsson. Service Development Studio (SDS) 4.1 ICP API Documentation. 2008. [3] Ericsson. Service Development Studio (SDS) 4.1 Technical Description.. [online] 2009. Dostupný z WWW: [4] NOVOTNÝ, V., MÁCHA, T.: Aplikace pro mobilní terminály s operačním systémem Symbian. Elektrorevue Internetový časopis (http://www.elektrorevue.cz http://www.elektrorevue.cz) 2009, č. 67, s. 1-8. ISSN: 1213 – 1539. [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, 2009. 102 s. [6] Ericsson. Service Development Studio (SDS) 4.1 Developer Guide.. [online] 2009. Dostupný z WWW: [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. 2002-06]. 2002 Dostupný z WWW: .

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ů., 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 dnot jittru je mírně nad hranicí doporučené hodnoty (20 ms). Z těchto měření lze tedy odvodit, odvodit že aplikace je vhodná pro reálné využití.

[8] FREED, N., BORENSTEIN, N. Multipart Internet Mail Extensions (MIME) Part Two: Tw Media Types. RFC 2046, IETF, [online]. 1996, [cit. 2002-11]. 2002 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 Multi (AMR) and Adaptive Mutli-Rate Rate Wideband (AMR-WB) Audio Codecs.. RFC 3267, IETF [online]. 2002, [cit. 2002-06]. 2002 Dostupný z WWW: [10] KOVÁŘ, P., MOLNÁR, K., NOVOTNÝ, V.: Současnost a budoucnost VoIP sítí. sítí Elektrorevue Internetový časopis (http://www.elektrorevue.cz http://www.elektrorevue.cz), 2007, s. 1-9. ISSN: 123-1539. [11] HANDLEY, M., JACOBSON, V., PERKINS, C. SDP – Session Description Protocol. Protocol RFC 4566, IETF [online]. 2006, [cit. 2006 2006-07] Dostupný z WWW:

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.

PODĚKOVÁNÍ Tento článek vznikl na základě podpory FRVŠ projektů (FRVŠ FRVŠ 2954/2010/F1a a FRVŠ 2986/2010/G1). 2986/2010/G1 21-7

2010/21 – 30. 3. 2010

VOL.12, NO.2, APRIL 2010

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

2010/21 – 30. 3. 2010

VOL.12, NO.2, APRIL 2010

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

21-9