VÝVOJ SIP KLIENTA V JAVAME

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

VÝVOJ SIP KLIENTA V JAVAME JAVAME SIP CLIENT

DIPLOMOVÁ PRÁCE MASTER’S THESIS

AUTOR PRÁCE

BC. ALEŠ JANEČEK

AUTHOR

VEDOUCÍ PRÁCE SUPERVISOR

BRNO 2008

ING. PETR KOVÁŘ

VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ Fakulta elektrotechniky a komunikačních technologií Ústav telekomunikací

Diplomová práce magisterský navazující studijní obor Telekomunikační a informační technika Student: Ročník:

Janeček Aleš Bc. 2

ID: 54123 Akademický rok: 2007/2008

NÁZEV TÉMATU:

Vývoj SIP klienta v JavaME POKYNY PRO VYPRACOVÁNÍ: Prostudujte standard SIP využívaný pro IP telefonii. Analyzujte možnosti platformy JavaME a její možnosti pro implementaci protokolu SIP. Zaměřte se zejména na SIP API a jeho podporu mezi výrobci mobilních telefonů. Na základě teoretických poznatků realizujte aplikaci fungující jako SIP klient, pokud to bude možné, s podporou IP telefonie. DOPORUČENÁ LITERATURA: [1] SINNREICH, H., JOHNSTON, A.B., SPARKS, R.J., SIP Beyond VoIP: The Next Step in the IP Communications Revolution. VON Publishing LLC, 2005. ISBN 978-0974813004 [2] MAHMOUD, Q. H., Naučte se Java2 Micro Edition. Grada Publishing a.s., 2002. ISBN 80-247-0444-7 Termín zadání:

11.2.2008

Vedoucí práce:

Ing. Petr Kovář

Termín odevzdání:

28.5.2008

prof. Ing. Kamil Vrba, CSc. předseda oborové rady

UPOZORNĚNÍ: Autor diplomové práce nesmí při vytváření diplomové 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.

LICENČNÍ SMLOUVA POSKYTOVANÁ K VÝKONU PRÁVA UŽÍT ŠKOLNÍ DÍLO uzavřená mezi smluvními stranami: 1. Pan/paní Jméno a příjmení:

Bc. Aleš Janeček

Bytem: Narozen/a (datum a místo):

4.5.1984, Chrudim

(dále jen "autor") a 2. Vysoké učení technické v Brně Fakulta elektrotechniky a komunikačních technologií se sídlem Údolní 244/53, 60200 Brno 2 jejímž jménem jedná na základě písemného pověření děkanem fakulty: prof. Ing. Kamil Vrba, CSc. (dále jen "nabyvatel")

Článek 1 Specifikace školního díla 1. Předmětem této smlouvy je vysokoškolská kvalifikační práce (VŠKP): disertační práce diplomová práce bakalářská práce jiná práce, jejíž druh je specifikován jako ......................................................... (dále jen VŠKP nebo dílo) Název VŠKP:

Vývoj SIP klienta v JavaME

Vedoucí/školitel VŠKP:

Ing. Petr Kovář

Ústav:

Ústav telekomunikací

Datum obhajoby VŠKP: ......................................................... VŠKP odevzdal autor nabyvateli v: tištěné formě

- počet exemplářů 1

elektronické formě

- počet exemplářů 1

2. Autor prohlašuje, že vytvořil samostatnou vlastní tvůrčí činností dílo shora popsané a specifikované. Autor dále prohlašuje, že při zpracovávání díla se sám nedostal do rozporu s autorským zákonem a předpisy souvisejícími a že je dílo dílem původním. 3. Dílo je chráněno jako dílo dle autorského zákona v platném znění. 4. Autor potvrzuje, že listinná a elektronická verze díla je identická.

Článek 2 Udělení licenčního oprávnění 1. Autor touto smlouvou poskytuje nabyvateli oprávnění (licenci) k výkonu práva uvedené dílo nevýdělečně užít, archivovat a zpřístupnit ke studijním, výukovým a výzkumným účelům včetně pořizovaní výpisů, opisů a rozmnoženin. 2. Licence je poskytována celosvětově, pro celou dobu trvání autorských a majetkových práv k dílu. 3. Autor souhlasí se zveřejněním díla v databázi přístupné v mezinárodní síti ihned po uzavření této smlouvy 1 rok po uzavření této smlouvy 3 roky po uzavření této smlouvy 5 let po uzavření této smlouvy 10 let po uzavření této smlouvy (z důvodu utajení v něm obsažených informací) 4. Nevýdělečné zveřejňování díla nabyvatelem v souladu s ustanovením § 47b zákona č. 111/1998 Sb., v platném znění, nevyžaduje licenci a nabyvatel je k němu povinen a oprávněn ze zákona.

Článek 3 Závěrečná ustanovení 1. Smlouva je sepsána ve třech vyhotoveních s platností originálu, přičemž po jednom vyhotovení obdrží autor a nabyvatel, další vyhotovení je vloženo do VŠKP. 2. Vztahy mezi smluvními stranami vzniklé a neupravené touto smlouvou se řídí autorským zákonem, občanským zákoníkem, vysokoškolským zákonem, zákonem o archivnictví, v platném znění a popř. dalšími právními předpisy. 3. Licenční smlouva byla uzavřena na základě svobodné a pravé vůle smluvních stran, s plným porozuměním jejímu textu i důsledkům, nikoliv v tísni a za nápadně nevýhodných podmínek. 4. Licenční smlouva nabývá platnosti a účinnosti dnem jejího podpisu oběma smluvními stranami.

V Brně dne: ............................................................

............................................................

............................................................

Nabyvatel

Autor

ABSTRAKT Cílem práce je analyzovat možnosti implementace SIP protokolu na zařízení využívající platformu Java Micro Edition. Analýza je zaměřena především na SIP protokol, SIP API (JSR-180) a vývoj v dnešních mobilních datových sítích. Na základě této analýzy je navržen midlet pro mobilní telefon, který pracuje jako SIP klient. Návrh klienta se zaměřuje především na základní komunikaci, registraci a přenos textových zpráv.

KLÍČOVÁ SLOVA J2ME, klient, SIP, JSR 180

ABSTRACT This thesis analyzes various alternatives of SIP protocol implementation on Java Micro Edition devices. This analysis is especially concentrated on SIP protocol, SIP API (JSR180) and the development in contemporary mobile data networks. I design a midlet for a mobile phone SIP client on the basis of this analysis. The design is especially concentrated on communication, registration and text mesage transfer.

KEYWORDS J2ME, client, SIP, JSR 180

JANEČEK A. Vývoj SIP klienta v JavaME. Brno: VUT Brno. Fakulta elektrotechniky a komunikačních technologií. Ústav telekomunikací, 2008. Počet stran 56. Diplomová práce. Vedoucí práce byl Ing. Petr Kovář.

PROHLÁŠENÍ Prohlašuji, že svou diplomovou práci na téma „Vývoj SIP klienta v JavaMEÿ jsem vypracoval samostatně pod vedením vedoucího diplomové 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é diplomové práce dále prohlašuji, že v souvislosti s vytvořením této diplomové 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)

Děkuji vedoucímu diplomové práce Ing. Petru Kovářovi za pomoc a rady při řešení práce.

OBSAH Seznam symbolů, veličin a zkratek

13

Úvod

15

1 VoIP, internetová telefonie 16 1.1 H.323 versus SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2 SIP (Session Initiation Protocol) 2.1 SIP prvky sítě . . . . . . . . . . . . . . . . . . 2.1.1 User Agent . . . . . . . . . . . . . . . 2.1.2 Zástupný server (Proxy Server) . . . . 2.1.3 Server přesměrování (Redirect Server) 2.1.4 Server umístění (Location Server) . . . 2.1.5 Registrační server (Registrar server) . . 2.2 Signalizace . . . . . . . . . . . . . . . . . . . . 2.3 Možnosti navázání spojení . . . . . . . . . . . 2.4 Identifikace uživatelů a směrování hovorů . . . 2.5 Struktura zpráv . . . . . . . . . . . . . . . . . 2.6 Přenos dat . . . . . . . . . . . . . . . . . . . . 2.6.1 Protokol SDP . . . . . . . . . . . . . . 2.6.2 Protokol RTP/RTCP . . . . . . . . . . 2.7 Bezpečnost, NAT, firewall . . . . . . . . . . . 2.7.1 Zabezpečení . . . . . . . . . . . . . . . 2.7.2 Řešení problémů s firewally . . . . . . 2.7.3 Řešení problémů s NAT . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

3 J2ME 3.1 Konfigurace . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 CLDC (Connected Limited Device Configuration) 3.1.2 CDC (Connected Device Configuration) . . . . . 3.2 Profily . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 MIDP (Mobile Information Device Profile) . . . . 3.2.2 Základní profil(Foundation Profile) . . . . . . . . 3.2.3 Osobní základní profil (Personal Basis Profile) . . 3.2.4 Osobní profil (Personal Profile) . . . . . . . . . . 3.2.5 Rozšiřující balíčky . . . . . . . . . . . . . . . . . 3.3 Midlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Balení midletů . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . . . . .

18 19 20 20 20 21 21 21 23 26 26 27 28 28 29 30 30 31

. . . . . . . . . . .

33 33 34 34 34 34 34 34 35 35 35 36

4 SIP API (JSR-180)

37

5 Analýza implementace SIP protokolu na mobilní telefon 40 5.1 SIP a mobilní datová síť . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.2 J2ME a přenos hlasu přes RTP . . . . . . . . . . . . . . . . . . . . . 42 6 SIP klient 6.1 Grafické rozhraní . . . . . . . . . . . . . . . . . . . . . . 6.2 Návrh a struktura . . . . . . . . . . . . . . . . . . . . . . 6.2.1 Posílání žádosti . . . . . . . . . . . . . . . . . . . 6.2.2 Příjem žádosti . . . . . . . . . . . . . . . . . . . . 6.2.3 Průběh registrace . . . . . . . . . . . . . . . . . . 6.2.4 notifyRequest - metoda pro zpracování žádosti . . 6.2.5 notifyResponse - metoda pro zpracování odpovědi

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

44 44 46 47 49 49 50 53

7 Závěr

55

Literatura

56

SEZNAM OBRÁZKŮ 2.1 2.2 2.3 2.4 2.5 2.6 2.7 3.1 3.2 4.1 4.2 5.1 6.1 6.2 6.3 6.4 6.5 6.6

Komunikace protokolem SIP . . . . . . . . . . Navázání přímého spojení mezi dvěma klienty Navázání spojení přes Redirect server . . . . . Navázání spojení přes Proxy server . . . . . . Registrace uživatele . . . . . . . . . . . . . . . Lokalizace uživatele . . . . . . . . . . . . . . . Hlavička RTP protokolu . . . . . . . . . . . . Schéma Java 2 Micro Edition . . . . . . . . . Životní cyklus Midletu . . . . . . . . . . . . . javax.microedition.sip . . . . . . . . . . . . . . Hlavní třídy a základní komunikace . . . . . . Nokia N80 . . . . . . . . . . . . . . . . . . . . Grafické rozhraní SIP klienta . . . . . . . . . . Odeslání žádosti . . . . . . . . . . . . . . . . . Nastvení naslouchání, metoda listen . . . . . . Příjem žadosti . . . . . . . . . . . . . . . . . . Registrace SIP účtu . . . . . . . . . . . . . . . Průběh obnovení registrace . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

19 23 24 24 25 25 29 33 35 38 39 40 45 48 49 50 50 51

SEZNAM TABULEK 1.1 4.1 4.2 5.1

Rozdíly mezi H.323 a SIP . . . . . . . . . . Rozhraní v balíčku javax.microedition.sip . . Třídy v balíčku javax.microedition.sip . . . . Srovnání technologií pro mobilní internet [6]

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

17 37 38 42

SEZNAM SYMBOLŮ, VELIČIN A ZKRATEK AOR Address Of Record – univerzální identifikátor uživatele bez ohledu na jeho poloze API Application Programming Interface – rozhraní pro programování aplikací DMZ Demilitarized Zone – zóna zařízení, která zprostředkovávají určité služby jak pro prostředí vnitřní sítě, tak pro prostředí sítě vnější ENUM Electronic NUMbering tElephone NUmber Mapping – doporučení, které definuje mapování telefonního čísla dle E.164 na URI znaky HTTP Hyper Text Transfer Protocol – protokol určený pro výměnu hypertextových dokumentů ve formátu HTML IETF Internet Engineering Task Force – Komise techniky Internetu IM

Instant Messaging – umožňuje sledování stavu uživatelů a posílání zpráv

IPTEL Internet Protocol Telephony – pracovní skupina zabývající se číslováním a směrováním ITU International Telecommunication Union – mezinárodní telekomunikační unie ISDN Integrated Services Digital Network – digitální síť integrovaných služeb LDAP Lightweight Directory Access Protocol – protokol pro přístup k adresářovým službám v komunikacích online MMUSIC Multiparty Multimedia Session Control – pracovní skupina, která začala s vývojem SIP protokolu PDA Personal Digital Assistant – malý kapesní počítač QoS Quality of Service – kvalita služby PSTN Public Switched Telephone System – standardní telefonní síť RFC Request For Comments – označení řady standardů RTCP Real Time Control Protocol – slouží k řízení RTP relace a k sledování kvality toku RTP Real Time Transport Protocol – definuje standardní formát paketů pro přenos zvuku a videa po internetu v reálném čase

13

SDP Session Description Protocol – formát pro popis inicializačních parametrů streamingu médií SIMPLE SIP Instant Messaging and Presence Leveraging Extensions – pracovní skupina zabývající se službami zjišťování přítomnosti a předávání zpráv SIPPING Session Initiation Protocol INvestiGation – pracovní skupina zabývající se aplikace a návrhy dalšího vývoje SIP SMTP Simple Mail Transfer Protocol – protokol určený pro přenos zpráv elektronické pošty TLS Transport Layer Security – protokol poskytující možnost zabezpečené komunikace UDP User Datagram Protocol – nespolehlivý protokol přenášející datagramy mezi počítači v síti URI Uniform Resource Identifier – slouží k přesné specifikaci umístění zdroje URL Uniform Resource Locator – slouží k přesné specifikaci umístění zdrojů informací na Internetu WWW World Wide Web – soustava propojených hypertextových dokumentů

14

ÚVOD Internetová telefonie je poslední dobou na vzestupu a je čím dál více v oblibě. Jedná se o přenos hlasu, telefonních hovorů pomocí datových sítí, které poskytují technologie označované jako Voice over Internet Protocol. Hlavní výhodou je především cena, většinou se platí pouze paušál datového připojení. Výše ceny je pak také závislá na způsobu využívání VoIP, jelikož většinou se musí ještě připočítat poplatek za služby poskytovateli VoIP služeb. Nejvíce se nám volání vyplatí při hovorech do zahraničí a na pevné linky. V rámci sítě VoIP poskytovatele je často volání zdarma. Naopak nevýhodou je, že se jedná o relativně novou technologii, takže ještě není příliš rozšířená. Tato práce je zaměřena částečně na Internetovou telefonii, ale především na SIP protokol. Jedná se o signalizační protokol, který se nyní velmi využíván VoIP službami. Budou popsány vlastnosti protokolu SIP a jeho obecné použití v IP telefonii. Vzhledem k rostoucí oblibě IP telefonie, se tato technologie začíná rozšiřovat i na mobilní telefony. Tedy dalším cílem této práce bylo analyzovat možnosti implementace SIP protokolu do mobilního telefonu. Téměř každý telefon na trhu dnes podporuje programovací jazyk Java, který slouží pro vytváření aplikací pro mobilní zařízení. Konkrétně se jedná o platformu Java 2 Micro Edition, která je přizpůsobena pro tato zařízení. Pomocí J2ME se dá vytvořit SIP aplikace použitelné pro VoIP. Avšak podpora samotné J2ME nestačí, pro správnou funkci je nutno, aby přístroj podporoval také SIP API, což je rozhraní nebo specifikace pro tvorbu SIP aplikací v J2ME. SIP v mobilním telefonu je poměrně nová věc, používat se začala až v posledních cca dvou letech. Už existuje pár produktů, které tuto komunikaci umožňují. Ovšem existuje také mnoho problémů, které kazí prožitek z IP telefonie v mobilním telefonu. Jedním z problému malý počet uživatelů. Právě využívání a rozšiřování této komunikace může této technologii prospět. Samozřejmě největším problémem při využívání IP telefonie na mobilním zařízení, je kvalita mobilního datového spoje, přes který jsou data přenášena. V předposlední kapitole jsou uvedeny problémy a nejčastější požadavky spjaty s provozováním SIP klienta v mobilním telefonu. A Poslední kapitola je věnována vývoji a realizaci SIP klienta, který byl zaměřen především na registraci uživatele a posílání textových zpráv.

15

1

VOIP, INTERNETOVÁ TELEFONIE

K tomu abychom mohli přenášet hlas po síti, potřebujeme několik věcí a to například zajistit přenos dat, signalizaci spojení, zpracování řeči atd. Pro přenos hlasu se využívá standardně protokol RTP (Real Time Transport Protocol – definuje standardní formát paketů pro přenos zvuku a videa po internetu v reálném čase) a RTCP (Real Time Control Protocol – slouží k řízení RTP relace a k sledování kvality toku). Hlas je digitalizován a rozdělen do paketů. Přenos hlasu díky kompresi není náročný na šířku pásma, ale vyžaduje konstantní šířku pásma, tedy s minimální latencí, aby se kvalita hovoru nesnižovala. Na kompresi se využívají kodeky např. G.711 (PCM, 64 kbit/s), G.722 s 64, 56 a 48 kbit/s, G.723.1 s 5,3 a 6,3 kbit/s, G.728 s 16 kbit/s nebo G.723 s 8 kbit/s. V IP telefonii tedy můžeme použitím vhodného kodeku zvýšit efektivnost osmkrát nebo i vícekrát. Další nedílnou součástí je signalizační systém (signalizační protokoly). Signalizační protokoly se dělí skupin standardizovaných protokolů, mezi které patří především H.323, SIP, MGCP, MEGACO/H.248, IAX a proprietárních protokolů jako je například SKINNY firmy Cisco či SKYPE.

1.1

H.323 versus SIP

Nejznámějšími používanými signalizačními protokoly jsou H.323 a SIP. H.323 je mnohem známější než SIP, to proto že se využívá mnohem déle než SIP, ovšem vznikly zhruba ve stejnou dobu. Avšak SIP je modernější protokol a má velký potenciál, proto uvedu mírné porovnání těchto dvou protokolů, viz také tab.1.1. H.323 je ITU (International Telecommunication Union – mezinárodní telekomunikační unie) VoIP protokol. H.323 je robustní a je určen pro komplexní nasazení, zastřešuje všechny prostředky pro VoIP komunikaci. Zahrnuje například kódování zvuku (podle G.71x, G.72x), signalizaci volání RAS (Registration, Admission, Status) podle H.255 pro sestavení spojení a zabezpečení komunikace mezi koncovými body), řídicí signalizaci (H.245) pro vzájemnou informaci o vlastnostech koncových bodů, otevření/uzavření logických kanálů pro přenos, řízení toku dat, všeobecné příkazy a indikace stavu. Nabízí tedy široké spektrum funkcí pro multimediální přenosy. Výhoda H.323 spočívá ve vysoké kompatibilitě se starší telefonní sítí. SIP je naopak jednoduchý protokol, který se stará jen o inicializaci a ukončování relací. Poskytuje všechny služby pro vytvoření spojení po IP síti. SIP protokol dokáže spolupracovat bez problémů s mnoha jinými protokoly. To že je SIP jednoduchý a lehce implementovaný, je vhodným signalizačním protokolem pro využití VoIP v mobilních zařízeních. Další výhodou je, že podporuje IM (Instant Messaging – umožňuje sledování stavu uživatelů a posílání zpráv). O SIPu více v kapitole 2.

16

SIP Specifikace IETF (1999) Použitý model Internet / WWW Kódování textové Využití v mobil- ano ních sítích 3G Složitost střední Architektura modulární Podpora pro IM ano Zpoždění při na- 1,5x RTT (Roundvazování spojení Trip Time) Rozšiřitelnost otevřené pro nové protokolové prvky Adresace Transportní protokol Zabezpečení

URI, e-mailová adresa, H.323, E.164 především UDP, ale také TCP přenechává odpovědnost nižším přenosovým vrstvám

Tab. 1.1: Rozdíly mezi H.323 a SIP

17

H.323 ITU-T (1996) telefonie (Q.sig) binární ne vysoká monolitická ne 1,5x RTT - 7x RTT ASN.1 nestandardní změny podle výrobce pouze na předdefinovaných místech E.164, alias stanice zjištěný pomocí gatekeeper TCP, ale i UDP stará se o bezpečné doručení paketů

2

SIP (SESSION INITIATION PROTOCOL)

Protokol SIP [8] se začal vyvíjet v roce 1996 pracovní skupinou MMUSIC (Multiparty Multimedia Session Control) v rámci IETF (Internet Engineering Task Force – Komise techniky Internetu). V roce 1999 skupina MMUSIC vydala specifikaci standardu jádra protokolu RFC 2543, v tomto roce také vznikla nová pracovní skupina s názvem SIP. Ta poté v roce 2002 vydala nový standard RFC 3261 nahrazující ten původní. Dále vznikly ještě jiné pracovní skupiny, které přispívají k rozšiřování SIPu, např. SIPPING (Session Initiation Protocol INvestiGation – pracovní skupina zabývající se aplikace a návrhy dalšího vývoje SIP), SIMPLE (SIP Instant Messaging and Presence Leveraging Extensions – pracovní skupina zabývající se službami zjišťování přítomnosti a předávání zpráv) a IPTEL (Internet Protocol Telephony – pracovní skupina zabývající se číslováním a směrováním). Nyní se se SIPem využívá mnoho RFC (Request For Comments – označení řady standardů)RFC standardů. Protokol SIP je textově orientovaný, koncepci má obdobnou jako protokol HTTP, používaný službou WWW, nebo jako u SMTP. Jednotlivé zprávy jsou tvořeny posloupnostmi textových hlaviček. A to je příjemné, protože je mnohem jednodušší vytváření a rozpoznávání zpráv jak pro odesílatele, tak i pro příjemce. Další výhodou je jednodušší řešení problému a snadné monitorování provozu. Protokol SIP nespecifikuje, jaký bude použit transportní protokol, nebo např. protokol pro přenos multimediálních dat, či řízení hovoru(dohadování na schopnostech zařízení, použití kodeků). Jedná se o protokol aplikační vrstvy, který závisí na protokolech nižších vrstev. Je to signalizační protokol, který řeší sestavení spojení mezi dvěma či více účastníky, dohled nad používáním tohoto spojení a rušení spojení. Jako transportní protokol se nejčastěji používá UDP (User Datagram Protocol – nespolehlivý protokol přenášející datagramy mezi počítači v síti) pro svoji jednodušší implementaci. Pro přenos multimediálních zpráv je využíván RTP, to je výhodné např. při komunikaci s zařízeními používající protokol H.323. .SIP protokol není závislí na žádné konkrétním protokolu, proto máme značnou možnost výběru protokolů, se kterými chceme aby SIP spolupracoval. U protokolu SIP nezáleží až tak na spolehlivosti přenosu, ale především na rychlosti přenosu a jednoduchosti implementace. Uvnitř zprávy protokolu SIP při navázání spojení je proto zapouzdřena zpráva jiného protokolu, který specifikuje použitá kódování pro multimediální data, jejich parametry a čísla portů, na kterých mají být data vysílána nebo přijímána. Obvykle se pro tento účel používá SDP (Session Description Protocol – formát pro popis inicializačních parametrů streamingu médií), který je rovněž textový. SDP je popsán v RFC 2327 [1]. Zařízení pracující s protokolem SIP mohou komunikovat se zařízeními pracujícími s protokolem H.323 pomocí brány SIP/H.323. Tato brána převádí signalizační zprávy

18

obou protokolů. Protože pro vlastní přenos multimediálních dat používají zařízení typu H.323 i SIP obvykle protokol RTP, mohou po navázání spojení prostřednictvím brány dále komunikovat přímo. Obdobně mohou zařízení pracující s protokolem SIP komunikovat s telefony v telefonní síti PSTN (Public Switched Telephone System – standardní telefonní síť) pomocí brány SIP/PSTN, s ISDN (Integrated Services Digital Network – digitální síť integrovaných služeb) zařízeními pomocí brány SIP/ISDN, nebo i s mobilními telefony. Protokol SIP může být implementován buď přímo uvnitř telefonu, který pak umožňuje uživateli volání se stejným pohodlím jako při použití běžného telefonu, nebo jako softwarová aplikace spuštěná na PC či v mobilním telefonu. Komunikační možnosti při použití protokolu SIP jsou znázorněny na obrázku 2.1.

Obr. 2.1: Komunikace protokolem SIP

2.1

SIP prvky sítě

V základě SIP pracuje s následujícími síťovými prvky: ˆ User Agent, ˆ Proxy server, ˆ Redirect server,

19

ˆ Registrar server, ˆ Location server.

2.1.1

User Agent

User agents (UA) jsou koncovými zařízeními SIP sítě. Nejčastěji se jedná o IP telefony, a to buď o fyzické a nebo o aplikaci, která je spuštěna na koncovém zřízení. UA se stará o navazování spojení s ostatními UA. User agent se skládá ze dvou částí. Jednou částí je klient UAC (User Agent Client), která má na starosti iniciaci spojení. Druhou částí je server UAS (User Agent Server), který reaguje na příchozí žádosti a posílá odpovědi. V koncové zařízení pracuje tedy současně UAC i UAS a ukončit relaci mohou rovnocenně oba.

2.1.2

Zástupný server (Proxy Server)

Proxy server přijímá žádosti o spojení od UA nebo od jiného Proxy serveru. Pokud volaného nezná, předá žádost jinému Proxy Serveru buď postupně nebo paralelně, dokud některý server neodpoví. Pokud server má volaného v rámci spravované domény, předá volanému žádost o spojení. Proxy server tedy zajišťuje směrování žádostí dle aktuálního umístění adresáta. Proxy servery se dělí na dva typy: ˆ stateless (bezestavové), které jsou poměrně jednoduché a rychlé, pouze přeposílají zprávy nezávisle na vzájemné vazby, ˆ stateful (s informací o stavech), které si po přijetí požadavku vytvoří záznam stavu a tento stav drží, dokud nedojde k ukončení transakace, tudíž po celou dobu transakce.

2.1.3

Server přesměrování (Redirect Server)

Redirect server pracuje obdobně jako Proxy server, ale nepřeposílá žádosti. Redirect server naproti tomu pouze sdělí volajícímu klientovi adresu serveru volaného klienta a klient potom musí sám navázat spojení přímo se serverem volaného klienta. Adresu volaného klienta zjistí pomocí lokalizační služby. V případě neúspěšné lokalizace nepředá žádnou adresu. Je-li k dispozici více adres získaných z lokalizačního serveru, může klient kontaktovat více serverů.

20

2.1.4

Server umístění (Location Server)

Location server je vlastně databáze, která uchovává informace o možném umístění klientů pro Redirect a Proxy server. Komunikace mezi Location serverem a ostatními, není zprostředkována pomocí SIP protokolu, ale nejčastěji pomocí LDAP (Lightweight Directory Access Protocol – protokol pro přístup k adresářovým službám v komunikacích online) V praxi jsou ovšem tyto servery často jako jedna aplikace, která přijímá registrace koncových uzlů a podle konfigurace se chová zároveň buď jako proxy nebo redirect server.

2.1.5

Registrační server (Registrar server)

Registrar server přijímá od uživatelů požadavky na registraci, tím získává informaci o jejich aktuální poloze (IP adresa, port a uživatelské jméno) a předává informaci Location serveru. Uživatel si může registrovat svůj účet sám nebo to může za něj provést někdo jiný. Registrace se musí obnovovat. Klient může, ale nemusí specifikovat dobu, po kterou má být účet registrován, pokud ji nespecifikuje, platí standardní doba 1 hodina.

2.2

Signalizace

SIP je protokol typu klient-server. Klient navazuje spojení se serverem. Jedno zařízení může pracovat současně jako klient i server. Například telefon pracuje jako klient pro odchozí volání a jako server pro příchozí volání. Fakt, že protokol je typu klientserver, neznamená, že komunikace musí být pouze dvoubodová. Hovor, který může být hlasový nebo multimediální, může probíhat mezi více účastníky. Multimediální data jsou potom přenášena najednou pro všechny účastníky spojením typu multicast, spojením typu unicast od každého účastníka přes propojovací bránu, spojením typu unicast mezi každou dvojicí účastníků nebo kombinací těchto metod. Zprávy protokolu SIP jsou dvojího druhu - žádosti a odpovědi. UA a servery si posílají žádosti pomocí takzvaných metod. Jedná se o zprávy v textovém formátu, některé základní metody jsou: ˆ INVITE - žádost o navázání spojení nebo o změnu parametrů spojení, ˆ BYE - žádost o ukončení spojení, ˆ ACK - žádost, kterou klient potvrzuje, že obdržel odpověď na žádost INVITE,

21

ˆ REGISTER - žádost o registraci klienta u registračního serveru, ˆ CANCEL - žádost o zrušení probíhající žádosti INVITE, ˆ OPTIONS - žádost o zaslání přehledu funkcí podporovaných serverem, ˆ INFO - znamená přenos informací během hovoru, ˆ UPDATE - dovoluje klientovi aktualizovat parametry spojení, ˆ PRACK - dočasné potvrzení, ˆ SUBSCRIBE - znamená přijímání/odběr událostí (textové zprávy), ˆ NOTIFY - informuj (uvědom) účastníky, ˆ MESSAGE - zpráva.

Odpovědi na SIP metody jsou zprávy uvedené číselným kódem. Systém kódů je převzat z HTTP protokolu. Např. SIP odpověď ”404 Not Found” je velmi podobná té, které se objeví na web prohlížeči při přístupu na neexistující stránku. Číselné kódy odpovědí jsou členěny do skupin: ˆ 1xx - informační zprávy, které jsou odesílány na přijaté žádosti, ale výsledek zpracování není ještě znám, odesílatel pak na základě této odpovědi zastaví opakování odesílaní žádosti (žádost obdržena, probíhá zpracování např. ”100 Trying”, ”180 Ringing”), ˆ 2xx - úspěšné ukončení žádosti, je to poslední odpověď, kterou odesílatel dostane dostane na svoji žádost (”200 OK” - akceptování INVITE), ˆ 3xx - přesměrování, odpověď dává informaci o nové poloze uživatele nebo alternativní službě, která má být použita, Proxy server tuto odpověď, pokud nedokáže zpracovat přijatou žádost. (”302 Moved Temporarily”, ”305 Use Proxy”), ˆ 4xx - chyba, způsobená klientem například chybná syntaxe (”403 Forbidden”), ˆ 5xx - chyba serveru, žádost klienta může být v pořádku, ale server selhal při zpracování, klient může zkusit vyslat žádost znova (”500 Server Internal Error”, ”501 Not Implemented”), ˆ 6xx - obecná chyba, například pokud žádost nemůže být splněna na žádném serveru (”606 Not Acceptable”).

Časté odpovědi, které se nejvíce vyskytují jsou ”200 OK” - úspěšné provedení žádosti, ”302 Moved Temporarily” - běžné přesměrování Redirect serverem a ”404 Not Found” - volaný uživatel se nenachází na daném serveru.

22

2.3

Možnosti navázání spojení

Na obrázku 2.2. je znázorněno nejjednodušší navázání spojení, a to je komunikace mezi dvěma uživateli bez přítomnosti serveru. Toto je možné, pokud volající zná umístění volaného a může ho tedy oslovit přímo. Využívá se takzvaný třífázový handshake INVITE/200/ACK.

Obr. 2.2: Navázání přímého spojení mezi dvěma klienty Avšak častější případ je, kdy volající nezná umístění volaného a musí využít služeb Proxy nebo Redirect serveru. V tom případě musí UA navázat spojení se serverem. Server poté prostřednictvím lokalizační služby zjistí umístění volaného UA. Klient vždy potvrdí žádostí ACK, že obdržel konečnou odpověď na předchozí žádost INVITE. V případě, že uživatel naváže spojení s Proxy serverem viz. obr.2.4. Proxy příjme žádost INVITE, zjistí umístění volaného klienta z Location serveru, a pokud se klient nachází v rámci jím spravované domény, přepošle volanému klientovi žádost o spojení INVITE. Pokud se volaný klient nenachází v rámci jeho spravované domény přepošle INVITE dalšímu Proxy serveru ve směru volaného. Při navázaní spojení s Redirect serverem, viz obr.2.3, se server chová obdobně jako Proxy, ale po zjištění umístění volaného klienta sdělí volajícímu klientovi umístění serveru volaného uživatele. Klient potom musí sám navázat spojení přímo se serverem volaného uživatele. Aby mohl Proxy nebo Redirect server najít umístění klientů, musí navázat spojení s Location serverem, viz. obr.2.6. Tato komunikace není součástí protokolu SIP, probíhá jiným protokolem většinou LDAP. Location server může vrátit více adres,

23

Obr. 2.3: Navázání spojení přes Redirect server

Obr. 2.4: Navázání spojení přes Proxy server Proxy server pak může kontaktovat jednotlivé adresy postupně nebo paralelně, dokud některý server neodpoví. V případě použití Redirect serveru obdobně kontaktuje jednotlivé adresy sám klient. Může se tedy rozeslat hromadně žádost INVITE na několik serverů nebo klientů ze seznamu. Podaří-li se kontaktovat některý server nebo klienta, zbytek žádostí INVITE může být stornován žádostí CANCEL. Nakonec klient vždy potvrdí žádostí ACK, že obdržel konečnou odpověď na předchozí

24

žádost INVITE. Location server bývá většinou spojen s Registrar serverem, který se stará o registraci uživatelů obr.2.5 . Registrar server pak předává informaci o tom, kde se uživatel právě nachází Location serveru. Registrace se skládá ze zprávy REGISTER a následované odpovědi 200 OK, v případě úspěšné registrace. Délka platnosti registrace je časově omezena a potřebuje obnovovat. Správa REGISTER musí obsahovat tyto atributy: Call-ID, Contact, CSeq, From, To, Request-URI. viz. kapitola 2.5.

Obr. 2.5: Registrace uživatele

Obr. 2.6: Lokalizace uživatele

25

2.4

Identifikace uživatelů a směrování hovorů

SIP protokol používá pro identifikaci uživatelů URI (Uniform Resource Identifier – slouží k přesné specifikaci umístění zdroje), která je podobná e-mailové adrese. URI se skládá z uživatele a domény. Pokud chceme volat v rámci jediné domény, tak nám postačí uvést pouze uživatelské jméno nebo telefonní číslo. Klient pak doplní automaticky doménu, ke které je zaregistrován a odešle ji na příslušný server. Pokud chceme volat do cizích domén, je třeba uvést celé URI - uživatel @ doména. Kromě toho je možno použít i systém ENUM, pak je potřeba zadat telefonní číslo v mezinárodním tvaru například 42095001001. URI může mi tedy různé podoby, jako například: ˆ sip:[email protected], ˆ sip:[email protected], ˆ sip:[email protected], ˆ +420950071001 přes ENUM, ˆ (+420)950071001 z PSTN.

URI může obsahovat i další údaje popisující způsob kontaktu uživatele. Úplný tvar adresy je: sip: [username [:heslo] @ ]hostname [:port] [;parametr][?hlavička] Hranaté závorky jsou nepovinné části, takže jediným povinným údajem je ve skutečnosti jméno uživatele. Místo jména můžeme uvést například i IP adresu zařízení. Jako volitelné části můžeme uvést jméno uživatele, případě heslo potřebné k autentizaci. Místo jména uživatele lze uvést telefonní číslo, a to v případě, pokud zařízení pracuje jako brána do klasické telefonní sítě. URI může být doplněno seznamem parametrů a hlaviček. Parametry slouží například k popisu transportního protokolu (UDP nebo TCP), zda je uvedeno jméno nebo telefonní číslo uživatele a další údaje. Hlavičky jsou součástí signalizační zprávy.

2.5

Struktura zpráv

Žádost vždy začíná jménem metody, Request-URI a verzí protokolu SIP. Následují hlavičky a tělo zprávy. Hlavičky mají obdobný tvar jako například v protokolech HTTP nebo SMTP, tedy jméno hlavičky, dvojtečka a hodnota. Hlaviček je celkem asi 40. Význam nejdůležitějších hlaviček je uveden dále.

26

ˆ Authorization - Informace pro autentizaci klienta k zabezpečenému serveru. ˆ Call-ID - Identifikace hovoru nebo registrace, spolu v kombinaci s atributy To a From jednoznačně identifikuje SIP dialog. ˆ Contact - Obsahuje URI, na kterém je uživatel k dostižení, obvykle IP adresa nebo doména. ˆ CSeq - Číselný identifikátor žádosti, k jehož inkrementaci dochází po každé žádosti. Požívá se například při rozlišení nové žadosti a opakující se žádosti. ˆ From - Obsahuje AOR (Address Of Record – univerzální identifikátor uživatele bez ohledu na jeho poloze) klienta, který provádí registraci, většinou je stejné jako To. ˆ Request-URI - Určuje název domény Location serveru, pro který probíhá registrace. ˆ To - Obsahuje AOR klienta, pro kterého update registrace probíhá. ˆ Content-Type - Určuje typ media, typ přenášených dat. ˆ Via - Využívá se k zaznamu cesty žádosti, například proxy server směrující žádost vkládá svoji adresu na začátek této hlavičky. Via je pak využíváno ke směrování SIP odpovědí stejnou cestou, jakou byly odeslány žádosti.

2.6

Přenos dat

Po navázání spojení pomocí SIP protokolu, je již většinou požadován přenos dat. K tomu jsou využívány, jak už bylo zmíněno, jiné protokoly. Jako transportní protokol je využíván protokol UDP, který je nespolehlivý, nezaručuje, že každý vyslaný paket bude doručen k cíli a ani to, že pakety dorazí ve správném pořadí. Je ale využíván hlavně kvůli své jednoduchosti oproti TCP. Data přenášená mezi klienty nebo servery jsou buď textové zprávy, hlas nebo video. Pro přenos multimediálních dat v reálném čase je využíván protokol RTP, který se ovšem při přenosu paketů chová obdobně jako UDP protokol, proto je využíván spolu s RTP ještě RTCP protokol, který poskytuje kontrolní a identifikační mechanismus pro přenosy RTP a popřípadě také QoS. K tomu aby klienti věděli, jak bude spojení a přenos multimediálních dat probíhat, se musí před samotným přenosem dat domluvit. K této domluvě se využívá protokol SDP, pomocí kterého se provede následná multimediální relace.

27

2.6.1

Protokol SDP

Protokol SDP [1] slouží k popisu multimediálních relací, specifikuje kódování a další parametry přenosu multimediálních dat během relace. Zpráva protokolu SDP je složena z posloupnosti jednopísmenných příznaků ve tvaru typ = hodnota. Příznaky říkají, jaký parametr komunikace je popisován. Na začátku jsou nejprve uvedeny řádky určené pro celé spojení a všech přenášených dat. Poté následují řádky sloužící k popisu jednotlivých toků dat. Zde je stručný popis některých příznaků: ˆ v - verze SDP protokolu, ˆ o - tvůrce a identifikátor relace, obsahuje jeho uživatelské jméno a adresu, ˆ s - jméno relace, ˆ i - informace o relaci, ˆ t - časové nastavení sešny při střídání s jinými sešnami, ˆ u - URI, ˆ c - cílová adresa spojení , často jde o multicastovou IP adresu, ˆ a - příznak přenášející doplňkové informace, ˆ m - popis toku dat, udává typ dat (audio, video, atd.), číslo portu cílová adresy, na který mají směřovat data, transportní protokol (RTP, UDP, atd.) a kódování.

Přenos multimediálních dat mezi koncovými uživateli probíhá dohodnutým transportním protokolem, adresách a portech. Data jsou přenášena přímo mezi uživateli bez účasti Proxy nebo Redirect serveru. Pro přenos multimediálních dat se u VoIP nejčastěji využívá RTP protokol spolu s řídícím protokolem RTCP.

2.6.2

Protokol RTP/RTCP

Přenosový protokol pro přenos multimediálních dat reálném čase [2]. Jak již bylo zmíněno, nezaručuje doručení dat a ani správné pořadí doručených paketů. Jediné, co zajišťuje, je označování paketů pořadovými čísly. Je tedy na koncové aplikaci, aby zajistila správné sestavení pořadí paketů a detekovala chybějící pakety. Pro činnost kontroly RTP spojení je RTP protokol používán spolu RTCP protokolem. RTCP protokol zajišťuje řízení RTP protokolu, sledování kvality a doručování dat. Koncovým aplikacím pomáhá například detekovat ztrátu paketů nebo zabraňuje zahlcení sítě pomocí řízení toku. Mezi RTP relací a účastníky probíhá periodická

28

výměna RTCP paketů, tudíž vysílací strana může dynamicky reagovat na požadavky příjmací strany. RTP je nezávislý na typu sítě a přenosovém protokolu, převážně se ale používá spolu s UDP protokolem. Bit 0

2

V

8 9

4

PX

CC

16

PT

M

31

Čís lo pořadí Times tamp

Synchronizační zdroj (SSRC) Z droj užitečného obs ahu (CSRC) (0-15)

Obr. 2.7: Hlavička RTP protokolu

ˆ V - 1 bit udává verzi RTP protokolu. ˆ P - 1 bit doplnění, při nastavení toho bitu, je na konec paketu přidáno jeden či více bytů, které nejsou součástí užitečného obsahu. Tyto byty využívají například kryptovací algoritmy. ˆ CC - 4 bity udávající počet CSRC identifikátorů, které následují za pevným záhlavím. ˆ M - 1 bit záložka definovaná konkrétním profilem média. ˆ PT - 7 bitový index , který popisuje formát užitečného obsahu. ˆ číslo pořadí - 16 bitové jedinečné číslo paketu, které udává pozici paketu v pořadí paketů. K inkrementaci dochází po každém odeslaném paketu. ˆ timestamp - 32 bitů, které vyjadřují moment odebrání vzorku prvního bytu užitečného obsahu. ˆ SSRC - 32 bitový identifikátor synchronizační zdroje. ˆ CSRC - 32 bitový identifikátor zdroje přispívající do užitečného obsahu.

2.7

Bezpečnost, NAT, firewall

SIP spadá do skupiny protokolů, kterým působí problém průchod NATem. Pro tyto protokoly je typické, že přenášejí IP adresy a čísla portů i na aplikační úrovni. To způsobí, že se nezdaří buď už samotná signalizace, ale určitě se znemožní doručení

29

RTP streamu mezi účastníky volání. Dalším problémem při SIP signalizaci je blokování přicházejících paketů z veřejné sítě , kdy se dohadují parametry RTP streamu.

2.7.1

Zabezpečení

HTTP autentizace Jedná se o nejzákladnější ochranu, kterou SIP zajišťuje. Tato autentizace je postavena na bázi Message Digest (MD5) a je nutné ji implementovat do všech SIP klientů a proxy bran. MD5 je jednocestná hashovaci funkce, která vytváří z libovolně dlouhého vstupu 128 bitů dlouhý hash. Je nutná znalost hesla na obou stranách, které se používá k vytvoření hashe. Proxy server pošle klientovy náhodné číslo (Nonce), které klient použije k vytvoření hashe a ten odešle zpět serveru. Serever získá data zpět a pokud se shodují s odeslanými, tak je provedena autentizace. Využívají se odpovědi 401 (Unauthorized) a 407 (Proxy Authentication Required) S/MIME (Secure/Multipurpose Internet Mail Extensions) S/MIME se používá k šifrování dat přímo ve zprávách v protokolu SIP. Případný posluchač tak není schopen okamžitě určit zdroje, cíle a kodeky použité při transportu. S/MIME však zvyšuje složitost řešení a mohou se vyskytnout omezení funkcionality. Lze využít i se systémem tunelování. SIPS (Secure SIP) SIPS je v podstatě SIP provozovaný přes kanál TLS (Transport Layer Security – protokol poskytující možnost zabezpečené komunikace). TLS nabízí dostatečnou bezpečnost a také toto bezpečné spojení dokáže udržet i přes složitě sestavovanou relaci. Pro Secure SIP komunikaci je definován identifikátor SIPS URI. Komunikace funguje tak, že klient kontaktuje Proxy server, který pošle zpět klientovi veřejný certifikát, přičemž klient musí certifikát potvrdit. Poté dojde k vytvoření relace a vzájemné výměně klíčů, pomocí nichž se bude provádět šifrování a dešifrování dat. To samé pak vytvoří Proxy server s druhým klientem a vytvoří tak celý TLS kanál.

2.7.2

Řešení problémů s firewally

Application Level Gateways ALG je software vložený do firewallu nebo NATu, který rozumí protokolu SIP a dynamicky otevírá či zavírá potřebné porty. Pokud je ALG obsaženo v NAT, ALG pak modifikuje hlavičky SIP paketů tak, aby odpovídaly správným interním IP adresám

30

v privátní síti nebo veřejné síti. ALG nahrazuje privátní adresu svou vlastní adresou a dále mapuje RTP data na porty, ze kterých může ALG číst a dovede z nich směrovat na správné zařízení. ALG je nejjednodušším a nejbezpečnějším způsobem pro řešení problémů SIP s firewally a NATem. Session Borders Controllers Díky absenci univerzálně přijímaného řešení firewall/NAT průchodu přinesli vývojáři na trh řešení, které se stalo známé pod označením Session Controller nebo také Session Bordur Controller (SBC). SBC jsou speciální zařízení, jejichž hlavní schopností je poskytovat služby SIP přes NAT a firewally. Dále zajišťuje bezpečnost, například skrývá o údaje privátní sítí atd. Očekává se rostoucí poptávka po těchto produktech.

2.7.3

Řešení problémů s NAT

STUN (Simple Traversal of UDP through NATs) Je vyžadován STUN klient v telefonu nebo v koncovém bodu, který odesílá pakety STUN serveru. STUN server vrátí klientovy jeho veřejnou IP adresu, port otevřený pro příchod dat do sítě a zjistí typ NATu. Klient pak použije získanou IP adresu a port ke konstrukci odesílané zprávy. STUN však pracuje jen s méně zabezpečenými NAT tzv.“Full Cone NAT” a tak hrozí že, klient bude vystaven útkou od někoho, kdo dokáže zachytit STUN pakety. STUN se všeobecně moc nedoporučuje, už například kvůli tomu že, se používají většinou symetrické NAT, se kterými STUN neumí pracovat. TURN (Traversal Using Relay NAT) TURN dovoluje konečnému bodu za firewallem nebo NATem přijmout data přes TCP nebo UDP. Řeší průchod skrz symetrické NATy, jako doplněk k STUN. Spojení musí být požadováno TURN klientem a podporuje pouze spojení klienta za NATem s pouze jediným klientem. TURN server nabízí zdroje (šířku pásma a porty) klientům, kteří se k němu připojí, oproti STUN. K TURN serveru mají přístup pouze autorizovaní klienti. Klient se autentifikuje prostřednictvím Shared Secret žádosti poslané přes TLS. Shared Secret odpověď předá klientovi jméno a heslo (na jedno použití). Toto heslo je pak používáno k autentifikaci alokační zprávy poslané klientem na TURN server, aby zjistil jeho veřejnou IP adresu a port serveru. Klient pak odesílá data pod veřejnou IP adresou TURN serveru. Příchozí data pak TURN server posílá klientovi na adresu přidělenou NATem.

31

ICE (Interactive Connectivity Establishment) ICE zahrnuje v podstatě všechny existující protokoly, které řeší průchod NAT/Firewall, jako je STUN, TURN a další. ICE staví na vzájemné spolupráci obou koncových bodů v SIP dialogu. Dynamicky vyhledává nejkratší cestu mezi dvěma uživateli. Využívá se například, když se nacházejí oba klienti za NATem UPnP (Universal Plug and Play) V tomto případě musí NAT podporovat UPnP protokol. Klient se pak přímo táže NATu na svou externí IP adresu a číslo portu. Nepočítá se však se stupňovanými NATs a dále existují vážná bezpečnostní rizika.

32

3

J2ME

Java 2 Micro Edition (J2ME) [10] je řada specifikací, které definují různě zmenšené verze standardní platformy Java 2. J2ME je využíváno k programování zařízení s omezenou pamětí, jako jsou například mobilní telefony, PDA (Personal Digital Assistant – malý kapesní počítač), pagery, výherní a prodejní automaty, kreditní karty a některá spotřební elektronika. Z toho důvodu má ve srovnání s J2SE vytvořen menší virtuální stroj a omezeny API (Application Programming Interface – rozhraní pro programování aplikací) funkce. Struktura J2ME je na obrazku3.1. Zařízení s vyšší pamětí a výkonejšími procesory

Mobilní telefony a jiná zařízení s omezenou pamětí

Rozšiřujíc í balíčky Osobní profil Osobní základ profil

Rozšiřujíc í balíčky MIDP

Základový profil

CDC

CDC

JVM

KVM

Obr. 3.1: Schéma Java 2 Micro Edition

3.1

Konfigurace

Konfigurace je specifikace definující softwarové prostředí pro skupinu zařízení. Tato skupina je většinou definována vlastnostmi jako: ˆ typ a velikost dostupné paměti, ˆ typ a frekvence procesoru, ˆ typ síťového připojení, které má zařízení k dispozici.

Konfigurace má reprezentovat minimální platformu pro dané zařízení, přičemž se nedefinují žádné volitelné funkce. V konfiguraci jsou také definovány funkce virtuálního stroje(VM). Výrobci zařízení však nejsou nuceni k tomu, aby používali VM

33

od firmy Sun, mohou použít jakýkoli jiný, který obsahuje funkce podle následujících konfigurací. V J2ME jsou dostupné tyto dvě konfigurace.

3.1.1

CLDC (Connected Limited Device Configuration)

CLDC je určeno pro nízkoúrovňovou spotřební elektroniku, jako jsou například mobilní telefony, PDA, pagery atd. Zařízení by mělo mít paměť velkou 160kB-512Kb a 16-bitový nebo 32-bitový procesor s minimální taktovací frekvencí 25MHz. CLDC je úzce spjato s Wireless Java, jejímž cílem je umožnit uživatelům mobilních telefonů nákup a stažení malých javových aplikací neboli midletů. Aktuální verze specifikace CLDC je verze 1.1 [9], která na rozdíl od předchozí verse vyžaduje min. 192kB paměti, dále byla přidána podpora plovoucí čárky (typy Float a Double) a větší podpora zařízení s většími zdroji. CLDC obsahuje tzv. Kilobyte Virtual Machine (KVM), redukovaný VM s velmi malými paměťovými nároky.

3.1.2

CDC (Connected Device Configuration)

CDC se zaměřuje na zařízení, která leží mezi CLDC a úplnými stolními systémy, na nichž běží platforma J2SE. Tato zařízení mají mnohem více paměti a procesorového výkonu. Mohou tedy podporovat úplnější softwarové prostředí Javy.

3.2 3.2.1

Profily MIDP (Mobile Information Device Profile)

MIDP přidává do CLDC síťové služby, součásti uživatelského rozhraní a místní úložný prostor. Profil je zaměřen především na omezený displej a úložné prostředky. Poskytuje tedy relativně jednoduché uživatelské rozhraní a základní síťové služby na základě HTTP 1.1. Je to nejznámější profil J2ME a tvoří základ bezdrátové Javy.

3.2.2

Základní profil(Foundation Profile)

Základní profil rozšíří CDC o téměř všechny standardní knihovny, které obsahuje jádro Javy 2.

3.2.3

Osobní základní profil (Personal Basis Profile)

Přidává základní funkce uživatelského rozhraní k Základovému profilu. Jeho záměrem je neumožnit najednou více aktivních oken než pouze jediné.

34

3.2.4

Osobní profil (Personal Profile)

Používá se pro platformy, která podporují složitější uživatelské rozhraní.

3.2.5

Rozšiřující balíčky

Jsou to nové balíčky, které rozšiřují standardní API o nové funkce. Jedná se například o 3D grafiku (JSR 184), podporu SIP protokolu (JSR 180) a další.

3.3

Midlet

Aplikace v Javě běžící na zařízeních MIDP jsou známé pod pojmem midlety. Midlet obsahuje alespoň jednu javovou třídu odvozenou od abstraktní třídy javax. microedition.midlet.MIDlet definované MIDP. Musí rozšiřovat speciální třídu MIDlet a v telefonu běží z bezpečnostních důvodů v tzv. sandboxu, neboli na svém vlastním pískovišti, které nemůže opustit. Skupina midletů se nazývá sadou midletů. Každá sada midletů se nachází opět na svém pískovišti. V MIDP 2.0 ovšem už povoluje důvěryhodným sadám midletů přístup k citlivým rozhraním, který je ostatním sadám zakázán. Životní cyklus a stavy midletu jsou ukázány na obrázku 3.2.

Obr. 3.2: Životní cyklus Midletu Po zavedení je zpočátku midlet ve stavu Paused. Dochází k obvyklé inicializaci tříd a instancí. Pak se volá implicitní konstruktor. Do stavu Active je změněn zavoláním metody startApp(). V této metodě midlet inicializuje zdroje typu Thread, Connection ap. Když se midlet pozastaví, volá se metodou pauseApp(), kterou se midlet vrací do pasivního stavu. Midlet by obecně měl uvolnit všechny držené prostředky a uložit aktuální stav k obnovení. Hlavní důsledek přechodu midletu do stavu Paused je, že nemá přístup k obrazovce. Žádná jím vytvořená vlákna nejsou automaticky ukončena a časovače zůstávají aktivní. Ovšem midlet může tak sám učinit a ukončit je, ale není povinen tak učinit. Pro ukončení midletu se volá metoda destroyApp(). Nenachází li se midlet ve vhodném stavu pro ukončení a je zároveň

35

zavolána destroyApp() s argumentem false, měl by midlet vyvolat výjimku MIDletStateChangeException a dát najevo, že ještě nechce být ukončen. Jestli že je midlet připraven skončit, vyvolá notifyDestroyed() aby sdělil, že chce být ukončen. Při ukončení by měl midlet uvolnit všechny prostředky a ukončit všechny aktivní vlákna a časovače.

3.4

Balení midletů

Předtím, než lze midlet použít v zařízení, je jej nutno zabalit. Midlet s dalšími nezbytnými třídami a všemi obrázky a dalšími soubory, k nimž potřebuje midlet při běhu přístup se zabalí do jediného souboru JAR. Dále se ještě vytvoří JAD (Java application descriptor) soubor. Pokud si chce uživatel stáhnout aplikaci, stáhne si nejprve menší JAD soubor, ve kterém jsou informace midletu. Podle těchto informací se zjistí jestli je tento midlet kompatibilní se zařízením, na které se bude instalovat.

36

4

SIP API (JSR-180)

JSR 180 [4] je specifikace definující balíček, který poskytuje SIP API (application programming interface) pro J2ME, takže můžeme vytvářet SIP aplikace na paměťově omezených zařízeních podporujících J2ME. API je kompaktní a dá se použít na jakýkoli J2ME profil a ne jen na MDIP. Minimálně jde však použít jen na zařízení podporující CLDC ver.1. a vyšší, v případě implementace na profil MIDP je JSR-180 podporováno až ve verzi 2, dále lze také použít na zařízení CDC. SIP API spoléhají na nižší vrstvě ležící CLDC Generic Connection Framework a pracují dle bezpečnostního modelu MSA. API definuje balíček javax.microedition.sip. Teto balíček obsahuje osm rozhraní tab.4.1 a čtyři třídy tab.4.2. Rozhraní SipConnection

SipClientConnection

SipServerConnection SipConnectionNotifier

SipServerConnectionListener SipClientConnectionListener SipDialog

SipRefreshListener

Popis Základní rozhraní pro SIP připojení, sdílí společné vlastnosti a metody se subrozhraními SipClientConnection a SipServerConnection. Reprezentuje transakci SIP klienta. Aplikace může vytvořit nové SipClientConnection použitím javax.microedition.io.Connector nebo SipDialog. Reprezentuje transakci SIP serveru. Vytvoří jej SipConnectionNotifier, když je přijata nová žádost. Definuje označovač SIP serveru, který rozřazuje příchozí zprávy. Pro přijmutí příchozího žádosti, použije aplikace metodu acceptAndOpen(), která otevře nové SipServerConnection. Jestliže nejsou ve frontě žádné zprávy, metoda je zablokována dokud není přijata nová zpráva. Rozhraní pro naslouchání příchozího SIP žádosti. Rozhraní pro naslouchání příchozí SIP odpovědi. Představuje jeden SIP dialog. SipDialog může být získán z objektu SipConnection, který se vytvoří po žádosti INVITE nebo SUBSCRIBE. Rozhraní pro naslouchání RefreshHelper třídy. Deklaruje refreshEvent() metodu, která získává refreshID k identifikaci obnovovacího úkolu a statusCOde, který reprezentuje výsledek obnovení: 0 pro zrušení, 200 pro úspěch, a jiné pro selhání.

Tab. 4.1: Rozhraní v balíčku javax.microedition.sip Na obrázku 4.1 jez názorněn diagram tříd, relace mezi třídami, dědění z třídy javax.microedition.io.Connection a s třídou javax.microedition.io.Connector. Hlavnímy SIP třídami pro zajištění komunikace jsou SipClientConnection, SipServerConnection and SipConnectionNotifier. Jejich možné použití je znázorněno

37

Třídy SipAddress SipHeader

SipRefreshHelper SipException

Popis Zajišťuje hlídání SIP adres. Může být použita k analýze a nebo k vytvoření adresy. Umožňuje práci se SIP hlavičkou. Může být použita pro získání hlavičky ze SIP zprávy a nebo konstrukci SIP hlavičky. Implementuje funkci, která msto aplikace zajišťuje manipulaci s obnovováním žádostí. Třída vyjímek pro specifické chyby SIP

Tab. 4.2: Třídy v balíčku javax.microedition.sip

Obr. 4.1: javax.microedition.sip na obrázku 4.2 a vlastnosti popsány v tabulce 4.1. Níže uvedený kód je jako příklad pro odeslání textové zprávy SIP klientovy. Nejprve se naváže spojeni s klientem [email protected], který čeká na příchozí zprávy na portu 5060. Po navázání spojení se provede inicializace žádosti MESSAGE, která slouží k posílaní textových zpráv. Následuje sestavení těla zprávy, které spočívá v nastavení příslušných hlaviček, například pro koho je zpráva určena. Nastavuje se také hlavička Content-Type, která udává typ přenášených dat, text/plain označuje prostý text. Po sestavení zprávy se otevře odchozí stream ze zprávy se vytvoří pole bytů, které se pak odešle druhé straně a zavře se odchozí stream. Poté si již jen vyčkává na odpověď, která potvrdí přijetí zprávy.

38

public void sendTextMessage ( S t r i n g msg ) { SipClientConnection sc = null ; try { // v y t v o r e n i SIP s p o j e n i s c = ( S i p C l i e n t C o n n e c t i o n ) Connector . open ( ” s i p : s i p p y . t e s t e r @ h o s t . com : 5 0 6 0 ” ) ; // i n i c i a l i z a c e SIP z a d o s t i MESSAGE s c . i n i t R e q u e s t ( ”MESSAGE” , n u l l ) ; // n a s t a v e n i h l a v i c e k s c . s e t H e a d e r ( ”From” , ” s i p : u s e r @ h o s t . com” ) ; sc . setHeader ( ” Subject ” , ” t e s t i n g . . . ” ) ; // s e s t a v e n i t e l a z p r a v y s c . s e t H e a d e r ( ” Content−Type” , ” t e x t / p l a i n ” ) ; s c . s e t H e a d e r ( ” Content−Length ” , I n t e g e r . t o S t r i n g ( msg . l e n g t h ( ) ) ) ; OutputStream o s = s c . openContentOutputStream ( ) ; o s . w r i t e ( msg . g e t B y t e s ( ) ) ; o s . c l o s e ( ) ; // o d e s l e z p r a v u a z a v r e s p o j e n i // v y c k a v a n i max 15 sekund na odpoved sc . receive (15000); // p r i j m u t i o d p o v e d i i f ( s c . g e t S t a t u s C o d e ( ) == 2 0 0 ) { // o b r d z e n i o d p o v e d i 200 OK } else { // o b d r z e n i j i n e o d p o v e d i } sc . c los e ( ) ; } catch ( E x c e p t i o n ex ) // o b d r z e n i n e j a k e v y j i m k y } }

SIP klient UAC+UAS SipClient Conecction SipConecction Notifier

jiný SIP klient Přijímání žádosti

Odeslání žádosti

Odeslání odpovědi SipServer Conecction

Příjímání odpovědi Přijímání žádosti Odeslání odpovědi

Obr. 4.2: Hlavní třídy a základní komunikace

39

SIP síť

Odeslání žádosti

Příjímání odpovědi

5

ANALÝZA IMPLEMENTACE SIP PROTOKOLU NA MOBILNÍ TELEFON

Vlivem rozšiřující se VoIP si začínají někteří uživatelé přát VoIP klienta v mobilním telefonu. A proč ne, v dnešní době je to už možné díky rychle se vyvíjející mobilní technice. Používání VoIP klientů na mobilních telefonech je sice teprve v začátcích, ale brzké rozšíření je nepochybné. Ne však na každém mobilním telefonu můžeme provozovat VoIP. K provozování SIP komunikace musí mobilní telefon splňovat několik následujících podmínek: ˆ podpora JAVA 2 Micro Edition, CLDC 1.1, MIDP 2.0, ˆ podpora UDP protokolu a Socketů, ˆ podpora SIP API (JSR 180), ˆ v případě přenosu hlasu musí podporovat audio kodeky na kompresi hlasu, případná softwarová implementace kodeku by zřejmě byla příliš pomalá, ˆ musí podporovat datový přenos přes mobilní síť nejlépe 3G-třetí generace(UMTS, CDMA), dále ještě pomocí WiFi (což je zatím nejperspektivnější, i když je problém s pokrytím).

Všechny tyto požadavky většinou splňují pouze telefony s operačním systémem Symbian S60 3rd Edition. Nejsou nijak vzácné, dnes je na trhu celkem velký výběr, již kolem 40 druhů. Nejvíce typů nabízí Nokia, ale do produkce se zapojil i Samsung a LG. Jedná se o takzvané Smart telefony neboli chytré telefony, které disponují nadstandardní softwarovou výbavou.

Obr. 5.1: Nokia N80

40

Jako příklad Smart telefonu uvádím Nokii N80, jejíž technické parametry, které by nás mohly zajímat při používaní SIP protokolu, jsou: ˆ OS Symbian S60 3rd Edition, ˆ podpora datových sítí - WCDMA, EGPRS, GPRS, HSCSD, CSD, WLAN 802.11b/g, ˆ Java Technology - zde je to především MIDP 2.0, CLDC 1.1, JSR 180 SIP API, ale také umí více JSR 135 Mobile Media API, JSR 172 Web Services API, JSR 177 Security and Trust Services API, JSR 179 Location API, ˆ podporované kodeky - AAC, AAC+, eAAC+, MP3, MP4, M4A, WMA, AMRNB, AMR-WB, Mobile XMF, SP-MIDI, MIDI Tones, RealAudio 7,8,10, True tones, zde je důležitý především AMR kodek (Adaptive Multi-Rate compression) sloužící ke kompresi hlasu (AMR-NB fvz= 8kHz, AMR-WB fvz= 16kHz).

5.1

SIP a mobilní datová síť

Největším problémem použití VoIP v mobilním telefonu je zajištění kvalitního přenosu dat. Na kvalitu hovoru má především vliv: ˆ použitý kodek, ˆ zpoždění přenosu, ˆ změna zpoždění (jitter), ˆ ztrátovost paketů.

V současné době se u nás rozvíjí 3G 1 mobilní datové sítě. Tyto sítě zajišťují relativně velký datový tok, ale bohužel horší kvalitu signálu, což je způsobeno především zatím malým rozšířením. VoIP nepotřebuje pro přenos hlasu moc rychlé připojení, vše závisí na použité kompresi hlasu. Například při použití AMR-NB komprese se datový tok pohybuje od 6,6 kb/s do 23,85 kb/s, podle požadované kvality, G.711 64 kb/s, G.722.2 od 6,6 kb/s od 23,85 kb/s. Rozhodující je tedy zpoždění. Ještě nedávno se použití VoIP na mobilních telefonech nejevilo moc reálně, ale služby se postupem času zlepšují. Podle doporučení ITU-T G.114 by se pro kvalitní přenos mělo zpoždění pohybovat kolem hranice 150 ms, od 150 do 300 ms je kvalita akceptovatelné a nad 300ms je už nevyhovující. Vliv na zpoždění má především kódování 1

V současné době se začíná mluvit o nové mobilní technologii o LTE (Long Term Evolution). Měla by to být síť s dokonalým pokrytím a připojení v mobilu rychlejší než 100 Mb/s.

41

a dekódování paketů, odesílaní a přenos paketů, čekání paketů ve fortnách a přijímacím bufferu. Dalším důležitým vlivem je změna zpoždění paketů Jitter, kdy změna do 20 ms je ještě dobrá a nad 50 ms je již nevyhovující. Na portálu mobilmania.cz byl zveřejněn článek [6] testující kvalitu dostupných technologií mobilních datových sítí v ČR. Výsledky jejich měření jsou znázorněny v tabulce 5.1. služba aplikace UMTS HSDPA CDMA Internet

download [Kbit/s] / rychlost.cz speedtest. zive.cz 312 317 897 812 401 422 4G 324 255

upload [Kbit/s] rychlost.cz speedtest. zive.cz 244 218 294 288 63 52 222 348

odezva průměrná odezva [ms] 211 127 192 327

Tab. 5.1: Srovnání technologií pro mobilní internet [6] V tabulce jsou uvedeny průměrné naměřené2 hodnoty. Jako nejlepší připojení se jeví HSDPA, ovšem pokrytí touto technologií je jen v Brně a v Praze. Nejlépe s pokrytím je na tom CDMA a se zpožděním na tom také není zle. Ovšem záleží na aktuální kvalitě signálu. Některé telefony mají možnost se připojit i pomocí WiFi, což je v této době asi nejlepší a nejlevnější možnost komunikace, ale je tu opět problém s pokrytím. SIP klient v mobilním telefonu však podporuje i odesílání zpráv a k této komunikaci postačí GPRS. Také se objevilo několik zpráv, že by například T-mobile měl přikročit k blokaci VoIP a IM komunikace, ale ty to zprávy se ještě nepotvrdily. VoIP přes jejich datové sítě pro operátory není příjemná a přicházejí o zisk, tudíž se to může postupem času a rozšiřováním změnit.

5.2

J2ME a přenos hlasu přes RTP

Samotná práce se SIP protokolem, je velmi usnadněna již zmíněným API a příslušnou dokumentací. To bohužel neplatí v případě použití RTP protokolu pro přenos hlasu. J2ME bohužel nepodporuje protokol RTP, nemá žádné API a proto je nezbytně nutné implementovat všechny prvky RTP protokolu. Nyní se budu snažit popsat, jak by takový průběh zpracovaní a odeslaní řeči mohl probíhat. Je zapotřebí zajistit následující události. ˆ vytvoření RTP paketu, přizpůsobení a zpětné získání z UDP paketu, 2

Toto měření bylo prováděno k datu 17. 6. 2007 a měřilo se z jednoho místa s využitím služby www.rychlost.cz a speedtest.zive.cz.

42

ˆ posílání a a příjem UDP paketů, ˆ vytvoření streamu a přehrání audio dat.

Pro přenos RTP paketu leze využít v J2ME rozhraní DatagramConnection, kdy jsou datagramy posílány v oddělených paketech. Pro příjem datagramu potřebujeme znát port příchozích dat, adresu a port odchozích dat. Tato domluva se děje prostřednictvím SDP protokolu. Příjmem příchozích datagramů by mohl vypadat následovně: DatagramConnection p r i j i m a c = ( DatagramConnection ) Connector . open ( ” datagram : / / :32767 ” ) ; byte [ ] b u f f e r = new byte [ l e n g t h ] Datagram p a c k e t = p r i j i m a c . newDatagram ( b u f f e r , b u f f e r . l e n g t h ) ; prijmac . r e c e i v e ( packet ) ;

Musíme také zajistit zpracování a přehrávání hlasu. Touto problematikou se zabývá specifikace JSR-135 Mobile Media API[5][7], podle kterého se dá vytvořit přehrávání dat získaných po sestavení audio proudu z datagramů. Mobile Media API umožnuje také záznam zvuku pomocí metody Manager.createPlayer(String locator), příklad použití může vypadat nasledovně: c a p t u r e P l a y e r = Manager . c r e a t e P l a y e r ( ” c a p t u r e : / / a u d i o ? e n c o d i n g=pcm&r a t e =8000 &b i t s=8&c h a n n e l s=1” ) ;

Nastavené kódování odpovídá kodeku G.711. Podobným způsobem leze zajistit i přehrávání. Nezbytnou součástí je konstrukce RTP paketu. Nejprve musíme převést zaznamenanou řeč na bytové pole, které se následně rozdělí na menší části. Poté se přidělí datům RTP hlavička. Takto vytvořený RTP pakte se pak odešle datagramem.

43

6

SIP KLIENT

Po získání potřebných informací jsem mohl přikročit k realizaci SIP klienta. Aplikace SIP klient byla vytvořena v NetBeans IDE 6.0 na platformě J2ME s použitím profilu CLDC 1.1, MIDP 2.0 a SIP API. Úkolem této aplikace je zajistit registraci uživatele k Registrar serveru a peer-to-peer 1 komunikaci s druhým klientem pomocí textových zpráv. Abychom mohli kontaktovat druhého klienta, musíme znát jeho identifikační údaje (SIP jméno, doménu a port). Pro vývoj byl použit Registrar server a emulátor mobilního telefonu obsažený v Java Wireless Toolkit 2.5.2. . Emulátor představuje obecný telefon, který se řídí jen podle nadefinovaných profilu a použitých API. Před použitím na reálném telefonu, se musí aplikace nejprve odzkoušet na příslušném emulátoru pro daný typ telefonu. A to především proto, že někteří výrobci nemají zcela kompletní podporu různých API, což by znamenalo, že to co je vytvořeno podle specifikace pro daná API nemusí fungovat na konkrétním telefonu.

6.1

Grafické rozhraní

Uživatelské prostředí aplikace je jednoduché a je vytvořeno pomocí několika formulařů viz obr.6.1. Grafické rozhraní je tvořeno komponentami balíčku javax. microedition.lcdui. Jedná se například o abstraktní třídu Screen a její podtřídy Form, List, atd., poté o prvky odvozené od třídy Item jako je TextField a ovládací prvky odvozené od třídy Command. Třída Screen poskytuje vysokoúrovňové komponenty, které jsou například nezávislé na typu a velikosti displeje, a tím je zajištěna přenositelnost mezi různými mobilními telefony. Použité komponenty jsou: ˆ List - slouží k vytvoření seznamu, který umožňuje výběr registrace, volání, chat a ukončení aplikace, ˆ Form - vytváří jednotlivé formuláře, registrační, vytvoření volání a okno se zprávami, ˆ Alert - používá se pro informování o výsledku provedené operace (úspěšná registrace), upozornění na příchozí hovor a chybové hlášení.

Po spuštění aplikace se zobrazí úvodní formulář obr.a-6.1, kde si volit z možností registrace, chat a volání. K tomu, abychom se mohli s někým spojit, potřebujeme vytvořit SIP účet. Právě k vytvoření SIP účtu slouží formulář registrace obr. b-6.1, který vytvoří po vyplnění 1

jedná se o přímou komunikaci mezi klienty bez přítomnosti proxy serveru

44

potřebných údajů účet u příslušného registračního serveru. Požadované registrační údaje jsou SIP jméno, celé jméno, port, na kterém bude klient naslouchat, adresa registračního serveru a doba, po které vyprší registrace a dojde k následné obnově registrace. Po zmáčknutí tlačítka Registrace se zobrazí informace o úspěšné, či neúspěšné registraci Po vytvoření SIP účtu jsme již k zastižení pro jiné uživatele a zároveň může klient kontaktovat jiné klienty. K navázání spojení s jiným klientem slouží položka Chat a nebo Volání. Obě tyto možnosti mají společný formulář pro vyplnění kontaktních údajů volaného účastníka obr. c-6.1. Důležité údaje jsou SIP jméno, adresa a port, na kterém volaný naslouchá. K použitelnému navázání kontaktu s druhou stranou lze využít bohužel pouze Chat, ten slouží ke komunikaci pomocí textových zpráv, což je znázorněno na obr. e,f-6.1.

a

b

d

e

c

f

Obr. 6.1: Grafické rozhraní SIP klienta Položka Volání naváže kontakt s druhou stranou také, ale to je vše. Tato položka, jak již napovídá název, má v budoucnu sloužit k přenosu hlasu mezi klienty. V této době je funkční pouze kontaktování druhého klienta a domluvení se s ním

45

na multimediální relaci pomocí protokolu SDP. Nefunkčnost přenosu hlasu je způsobena poměrně složitou a časově náročnou implementací RTP protokolu. Bohužel v Java ME není RTP API, jako je tomu například v Java SE, které by napomáhalo k jednodušší implementaci RTP protokolu, a proto se mi nepovedlo zajistit přenos řeči. Dále jsou v aplikaci použita různá upozornění k informování, například o úspěšné či neúspěšné registraci, o příchozím hovoru, o ukončení hovoru, dále jsou použity vyčkávací obrazovky pro čekaní na provedení operace, jako je navázání spojení s jiným klientem nebo čekání na provedení registrace.

6.2

Návrh a struktura

Navržená aplikace neboli midlet se skládá ze dvou následujících tříd: ˆ SIPklient - toto je hlavní třída, obsahuje grafické rozhraní, ovládací prvky a SIP rozhraní, ˆ Sender - tato třída slouží k odesílání textových zpráv druhé straně.

Jak je vidět, vše důležité je koncentrováno ve třídě SIPklient. Třída SIPklient se stará o životní cyklus midletu, zajišťuje grafické rozhraní, zachytávání uživatelských událostí a také implementuje sipové rozhraní. Hlavními použitými parametry jsou: ˆ myName - udává SIP jméno uživatele registrovaného účtu, ˆ myDisplayName - udává celé jméno registrovaného uživatele (Display Name), ˆ mySipPort - port, na kterém bude klient naslouchat, ˆ friendName - SIP jméno volaného účastníka a také SIP jméno příchozího hovoru,je nutné ho zadat při volání druhé strany, ˆ friendSipPort - port, na kterém naslouchá volaný uživatel, je nutné ho zadat při volání druhé strany, ˆ friendDomain - přímá adresa volaného účastníka a nebo adresa proxy serveru, u kterého se účastník nachází, ˆ proxyAddress - adresa proxy nebo registrar serveru, většinou jsou sloučeny, využívá se při registraci účtu, ˆ expires - doba, po které vyprší registrace u registrar serveru a dojde k případné obnově.

46

Dále je použito několik tříd a implementováno několik rozhraní ze SIP API. public c l a s s S I P k l i e n t extends MIDlet implements CommandListener , SipClientConnectionListener , SipServerConnectionListener , SipRefreshListener {

Třída SIPklient je rosšiřuje abstraktní třídy javax.micoredition.midlet.MIDlet a implementuje rozhraní SipClientConnectionListener, SipServerConnectionListener, SipRefreshListener a používá několik následujících tříd a rozhraní API: ˆ Connector - tato třída nepatří do SIP API, otevírá spojení a vrací příslušné instance pro třídy SipClientConnection nebo SipServerConnection, ˆ SipClientConnection - rozhraní zajišťující klientské transakce, ˆ SipServerConnection - rozhraní zajišťující serverové transakce, ˆ SipClientConnectionListener - rozhraní, kteře umožňuje naslouchat průchozím SIP odpovědím, ˆ SipServerConnectionListener - rozhraní, kteře umožňuje naslouchat průchozím SIP žádostem, ˆ SipRefreshHelper - tato třída pomáhá aplikaci při obnovování žádostí, ˆ SipRefreshListener - rozhraní pro RefreshHelper události, ˆ SipConnectionNotifier - rozhraní definující oznamovač serverového spojení .

Rozhraní a třídy SIP API byly popsány v tabulkách 4.1 a 4.2. Po spuštění aplikace se tedy dostaneme k výběru požadované akce. První, co musíme udělat je registrace SIP účtu, po vyplnění registračních údajů se především volá metoda register, ale také metoda listen, která předá parametr naslouchacího portu třídě SipConnectionNotifier, a tím je zajištěno zachytávání a obsloužení příchozích žádostí. Po registraci již můžeme přistoupit k vytvoření spojení a nebo vyčkat na příchozí spojení. Při vytváření spojení se volá metoda invite. Po vytvoření spojení jsou následně volány metody openServerConnection, v případě iniciování spojení a nebo openClientConnection, v případě přijmutí hovoru. Obě tyto metody slouží k odesílaní textových zpráv pomocí soketů.

6.2.1

Posílání žádosti

Na obrázku 6.2 je znázorněn průběh vysílání žádosti. Různé žádosti, které se využívají v SIP protokolu, byly popsány výše, viz. 2.2. V této aplikaci jsou použity pouze

47

dvě žádosti REGISTER a INVITE. Těm odpovídají i požité metody. Metoda register, která zajišťuje registraci účtu a metoda invite, která žádá druhého účastníka o spojení. Na následujícím obrázku 6.2 je znázorněn průběh obou metod. Obě tyto metody otevírají klientské spojení pomocí scc = (SipClientConnection) Connector.open(. . . .);, rozdíl je pouze v zadaném parametru. Metoda invite má za parametr adresu volaného účastníka. Metoda register bude popsána níže. Po vytvoření spojení následuje nastavení naslouchání příchozí odpovědi pomocí scc.setListener (listener);, kde listner je typu SipClientConnectionListener. Dále se provede inicializace žádosti scc.initRequest(”INVITE”, scn);, kde je žádost spjata s SipConnectionNotifier s definovaným naslouchacím portem, a tím je zaručeno zachycení odpovědi. Poté se provede nastavení všech důležitých hlaviček, například scc.setHeader(”To”, adr); Jednou z důležitých hlaviček je také Content-Type, příklad nastavení je scc. setHeader(”Content-Type”, ”text/plain”); , tím je nastaven typ přenášených dat na text a druhá strana ví, jaká data budou přicházet a jakým způsobem je má zpracovat. Po nastavení těla zprávy se otevře výstupní kanál, kterým jsou data v poli bytů zapsána a odeslána kanálem k druhé straně os.write(message.getBytes());. Nakonec se výstupní kanál uzavře a následně se změní status, ve kterém se aplikace nachází. V případě odeslání žádosti INVITE se status změní na INVITING, a to kvůli správnému zpracování odpovědi, které bude popsáno později. Klient 2

Klient 1

Aplikace Sip klient

Connector

SipClientConnection

Status

open(sipAddress) SipClientConnection setListener(this) inicializace žádosti otevření streamu, nastavení kontextu odeslaní zprávy

setStatus() close()

Obr. 6.2: Odeslání žádosti

48

přijímací strana

6.2.2

Příjem žádosti

Nejprve je nutné nastavení portu, na kterém bude naslouchat serverová část 6.3, nastavení se provede v metodě listen pomocí scn = (SipConnectionNotifier) Connector.open(”sip:” + mySipPort); a scn.setListener(listener);, kde tedy SipConnectionNotifier obsahuje odkaz na objekt typu SipServerConnectionListener. Klient

Aplikace Sip klient

Connector

SipConnectionNotifier

open(sip: listenerPort) SipConnectionNotifier setListener(listener)

Obr. 6.3: Nastvení naslouchání, metoda listen Celý průběh zpracování příchozí žádosti je na obrázku 6.4. Po nastavení naslouchání serverové části rozhraní, SipConnectionNotifier zachytí příchozí žádost a volá metodu acceptAndOpen();, která vyčkává dokud klient není připojen a poté vrací instance SipServerConnection pro zpracování žádosti a odeslání příslušné odpovědi. Podrobnější příklad bude uveden na metodě notifyReguest6.2.4, která právě zachytává a provádí obsloužení příchozích žádostí.

6.2.3

Průběh registrace

Při registraci SIP účtu se provádí odeslání žádosti REGISTER regisrar serveru. Registraci provádí metoda register. Postup odesílání žádosti byl zmíněn výše viz.6.2.1. Při registraci se využívají ještě další třídy SIP API, jak je vidět na obrázku 6.5. Touto metodou je enableRefresh třídy SipRefreshHelper, která aktivuje obnovování registrace po určitém čase. Použití je refreshIdentifier = scc.enableRefresh(SIPklient.this);. Metoda enableRefresh vrací identifikátor obnovení refreshIdentifier, potřebný pro obnovení či zastavení obnovování registrace. Doba obnovení se registrar serveru odesílá v hlavičce Contact, scc.setHeader(”Contact”, contact + ”;expires=” + expires);. Na obrázku 6.6 je znázorněn průběh obnovení registrace.

49

Klient 1

Aplikace Sip klient

C onnector

Klient 2

SipC onnectionNotifier

SipServerC onnection

přijímací strana

open(sip: listenerPort) SipC onnectionNotifer setListenner(this) příchozí žádost notifyRequest(SipC onnectionNotifier) acceptAndOpen() SipServerC onnection čtení zprávy(getHeader(), openC onnectInputStream()) inicializace odpov ědi, nastavení hlaviček send() odpověď

Obr. 6.4: Příjem žadosti Klient

Aplikace Sip klient

Connector

Registrar server

SipClientConnection

Timer

Status

přijímací strana

open(RegistrarAddress) SipclientConnection setListener(listener) inicializace žádosti REGISTER, setHeader() enableRefresh(this) refresh identifikátor send() odeslaní zprávy REGISTER nastavení časovače setStatus(REGISTERING)

Obr. 6.5: Registrace SIP účtu

6.2.4

notifyRequest - metoda pro zpracování žádosti

Následující kód je metoda notifyReguest, která zajišťuje zachycení příchozích žádostí. Její význam je tedy v identifikaci zachycené žádosti, přečtení obsahu zprávy a odeslání příslušné zprávy druhé straně. Nejprve se zavolá metoda acceptAndOpen(), která vyčkává na příchozí spojení a poté vrací parametry SipConnectionNotifier objektu typu SipServerConnection. Následně může již metoda identifikovat

50

Klient

Aplikace Sip klient

Time Task

Registrar server

SipRefreshHelper

přijímací strana

Timer

run() update(refresh ID) odeslání zprávy REGISTER příchozí odpov ěď refreshEvent()

Obr. 6.6: Průběh obnovení registrace příchozí žádost. Aplikace dokáže obsloužit žádosti INVITE, ACK a BYE. ACK je potvrzovací zpráva po vytvořeném spojení. BYE je zpráva ukončující spojení. K identifikaci žádosti se přistupuje metodou getMethod(). public void n o t i f y R e q u e s t ( S i p C o n n e c t i o n N o t i f i e r s i p C o n n e c t i o n N o t i f i e r ) { try { s s c = s i p C o n n e c t i o n N o t i f i e r . acceptAndOpen ( ) ; // b l o c k i n g System . out . p r i n t l n ( ” R e c e i v e d r e q u e s t : ” + s s c . getMethod ( ) . t o S t r i n g ( ) ) ; i f ( s s c . getMethod ( ) . e q u a l s ( ”INVITE” ) ) { S t r i n g contentType = s s c . g e t H e a d e r ( ” Content−Type” ) ; S t r i n g c o n t e n t L e n g t h = s s c . g e t H e a d e r ( ” Content−Length ” ) ; int length = I n t e g e r . p a r s e I n t ( contentLength ) ; ...

V případě že příchozí zpráva je INVITE se následně zjišťuje obsah halvičky Content-Type, přenáší informaci o typu dat, která se budou přenášet ve vytvořené relaci. Typ dat která je aplikace schopna zachytit jsou text/plain a application/sdp. Je-li zachyceno text/plain, aplikace se připraví na příjem textových zpráv. Z hlavičky Content-Length se získá parametry soketu, které bude použit pro přenos dat. Následně se změní status na RINGING, odešle se odpověď 180 (RINGING) a informuje uživatele pomoci grafického rozhraní o příchozím hovoru switchDisplayable(getHovorAl(), getTalkForm());. Uživatel má poté možnost hovor přijmout, tím pomocí metody sendAccepted() zašle druhé straně odpověď 200 (OK) a nebo může odmítnout hovor metodou sendCancel(), kdy dojde k zaslání odpovědi 486 (Busy Here). i f ( contentType . e q u a l s ( ” a p p l i c a t i o n / sdp ” ) ) { InputStream i s = s s c . openContentInputStream ( ) ; byte [ ] c o n t e n t = new byte [ l e n g t h ] ; i s . read ( content ) ; // z i s k a parametry s o k e t o v e h o s p o j e n i c l i e n t S o c k P a r a m s = new S t r i n g ( c o n t e n t ) ; u a S t a t u s . s e t S t a t u s (RINGING ) ; s w i t c h D i s p l a y a b l e ( getHovorAl ( ) , getCallForm ( ) ) ; s s c . i n i t R e s p o n s e ( 1 8 0 ) ; //RINGING s s c . send ( ) ; dialog = ssc . getDialog ( ) ;

51

Je-li zachyceno application/sdp, nestane se téměř nic. Tento typ dat se většinou využívá k přenosu různých multimediálních dat, v tomto případě by se mělo jednat o přenos hlasu. Při zachycení application/sdp, dojde pouze k nastavení multimediální relace pomocí protokolu SDP. Poté by mělo následovat nastavení kodeků, zachytávání řeči a následný přenos hlasu přes RTP protokol. } e l s e i f ( contentType . e q u a l s ( ” t e x t / p l a i n ” ) ) { c h a t = true ; InputStream i s = s s c . openContentInputStream ( ) ; byte [ ] c o n t e n t = new byte [ l e n g t h ] ; i s . read ( content ) ; c l i e n t S o c k P a r a m s = new S t r i n g ( c o n t e n t ) ; // z i s k a parametry s o k e t o v e h o s p o j e n i u a S t a t u s . s e t S t a t u s (RINGING ) ; s w i t c h D i s p l a y a b l e ( getHovorAl ( ) , getTalkForm ( ) ) ; s s c . i n i t R e s p o n s e ( 1 8 0 ) ; //RINGING s s c . send ( ) ; dialog = ssc . getDialog ( ) ; }

Parametry SPD protokolu jsou přenášeny v hlavičce Content-Length. Při přijmutí hovoru nestačí odeslat pouze odpověď 200 (OK), ale musí dojít také k nastavení hlaviček Content-Length a Content-Type. Nastavení SDP se provede vytvořením řetězce sdp, který může vypadat následovně: sdp =

”v=0\no=− 0 0 IN IP4 ”+s c n . g e t L o c a l A d d r e s s ()+ ” \ ns=S I P c l i e n t m o b i l e \ nc=IN IP4 ”+s c n . g e t L o c a l A d d r e s s ()+ ” \ nt=0 0\nm=a u d i o ” + r t p P o r t + ” RTP/AVP 0\ na=s e n d r e c v ” ;

Význam hlaviček byl již popsán v kapitole 2.6.1, zde je podrobnější nastavení: ˆ v= (verze protokolu)

v=0 ˆ o=<session-id><session-verze>

o=<-><7><2>< IP4><192.168.100.103> ˆ c=< typ sítě(např. IN=Internet) >

c=< IN >< IP 4 >< 192.168.100.103 > ˆ t=<čas spuštění><čas zastavení>

t=<0><0> ˆ m=<protokol> . . .

m=audio 49232 RTP/AVP 0 , kde 0 znamená že je vybrán kodek u-law PCM Po obdržení odpovědi 200(OK) druhou stranou, přijde potvrzovací zpráva ACK, po které se aktivuje metoda openClientConnection se získanými parametry soketového spojení, dojde ke změně stavu na TALKING a může následovat zasílání textových zpráv.

52

Při obdržení ukončovací zprávy BYE se odešle druhé straně odpověď 200(OK) a změní se stav na REGISTERED. } e l s e i f ( s s c . getMethod ( ) . e q u a l s ( ”ACK” ) ) { i f ( u a S t a t u s . g e t S t a t u s ( ) == RINGING) { i f ( chat ) { openClientConnection ( clientSockParams ) ; } u a S t a t u s . s e t S t a t u s (TALKING ) ; } } e l s e i f ( s s c . getMethod ( ) . e q u a l s ( ”BYE” ) ) { i f ( d i a l o g . isSameDialog ( s s c ) ) { s w i t c h D i s p l a y a b l e ( getByeAl ( ) , g e t I n v i t e F r m ( ) ) ; i f ( u a S t a t u s . g e t S t a t u s ( ) == TALKING) { ssc . initResponse (200); s s c . send ( ) ; try { i f ( s e r v e r S o c k e t != n u l l ) { serverSocket . close ( ) ; } e l s e i f ( s c != n u l l ) { sc . clos e ( ) ; } } catch ( E x c e p t i o n e ) { } u a S t a t u s . s e t S t a t u s (REGISTERED ) ;

6.2.5

notifyResponse - metoda pro zpracování odpovědi

Tato metoda slouží k zachytávání příchozích odpovědí. Nejprve metoda počká 1 sekundu na odpověď, po té rozřazuje odpovědi podle číselných kódů a stavu, ve kterém se aplikace nachází. public void n o t i f y R e s p o n s e ( S i p C l i e n t C o n n e c t i o n s i p C l i e n t C o n n e c t i o n ) { try { boolean ok = s c c . r e c e i v e ( 1 0 0 0 ) ; i f ( ! ok ) { System . out . p r i n t l n ( ” Response not r e c e i v e d ” ) ; return ; } i n t code = s c c . g e t S t a t u s C o d e ( ) ; System . out . p r i n t l n ( ” R e c e i v e d s t a t u s code : ” + code ) ;

Pokud se aplikace nachází ve stavu kdy probíhá registrace tzn. REGISTERING, mohou nastat tyto události. V případě přijetí odpovědi 200 (OK) je potvrzena úspěšná registrace. Uživateli se zobrazí informace o úspěšné registraci a vrátí ho do hlavního menu. Mnoho nastat i chyby, to v případě že se příjme odpověď 401, nebo 407 se jedná o chyby autentizace, tato chyba je způsobena přihlašováním k zabezpečenému serveru. V případě přijmutí úplně jiné odpovědi se zobrazí chybové hlášení registrace a aplikace se navrátí zpět na registrační formulář. i f ( u a S t a t u s . g e t S t a t u s ( ) == REGISTERING) { i f ( code == 2 0 0 ) { System . out . p r i n t l n ( ” R e c e i v e d OK a f t e r REGISTER” ) ; u a S t a t u s . s e t S t a t u s (REGISTERED ) ; s w i t c h D i s p l a y a b l e ( getRegOkAl ( ) , getMainMenu ( ) ) ; } e l s e i f ( code == 4 0 1 ) { s w i t c h D i s p l a y a b l e ( g e t A u t e n t E r r ( ) , getRegFrm ( ) ) ; } e l s e i f ( code == 4 0 7 ) { s w i t c h D i s p l a y a b l e ( g e t A u t e n t E r r ( ) , getRegFrm ( ) ) ;

53

} else { s w i t c h D i s p l a y a b l e ( getRegErrAl ( ) , getRegFrm ( ) ) ; }

Když se aplikace nachází ve stavu kdy vytváří spojení s druhou stranu INVITING a zachytí odpověď 200 (OK), dojde k inicializaci potvrzovací zprávy ACK a nastavení hlaviček Content-Type a Content-Length. A v případě že jsme vytvářeli spojení pro přenos textových zpráv (volba Chat v hlavním menu) dojde ke spuštění metody openServerConnection, sloužící k přenosu textových zpráv pomocí soketů a aplikace se přepne na formulář textových zpráv. } e l s e i f ( u a S t a t u s . g e t S t a t u s ( ) == INVITING ) { i f ( ( code >= 1 0 0 ) && ( code < 2 0 0 ) ) { System . out . p r i n t l n ( ” P r o v i s i o n i n g r e s p o n s e : ” + code ) ; } e l s e i f ( code == 2 0 0 ) { System . out . p r i n t l n ( ” R e c e i v e d OK a f t e r INVITE” ) ; S t r i n g contentType = s c c . g e t H e a d e r ( ” Content−Type” ) ; S t r i n g c o n t e n t L e n g t h = s c c . g e t H e a d e r ( ” Content−Length ” ) ; int length = I n t e g e r . p a r s e I n t ( contentLength ) ; s c c . i n i t A c k ( ) ; // i n i t i a l i z e a o d e s l a n i ACK s c c . send ( ) ; dialog = scc . getDialog ( ) ; u a S t a t u s . s e t S t a t u s (TALKING ) ; i f ( chat ) { o p e n S e r v e r C o n n e c t i o n ( mySocket ) ; s w i t c h D i s p l a y a b l e ( null , getTalkForm ( ) ) ; } else { s w i t c h D i s p l a y a b l e ( null , getCallForm ( ) ) ; } } e l s e i f ( code == 4 8 6 ) { //BUSY HERE switchDisplayable ( getInviteErr ( ) , getInviteFrm ( ) ) ; } else { switchDisplayable ( getInviteErr ( ) , getInviteFrm ( ) ) ; }

Jestliže aplikace ukončuje spojení s druhou stranu, vyčkává na potvrzení odpovědi 200 (OK), kdy po příjetí odpovědi ukončí spojení s druhou stranou. } e l s e i f ( u a S t a t u s . g e t S t a t u s ( ) == BYE) { i f ( code == 2 0 0 ) { System . out . p r i n t l n ( ” R e c e i v e d OK a f t e r BYE” ) ; u a S t a t u s . s e t S t a t u s (REGISTERED ) ; try { i f ( s e r v e r S o c k e t != n u l l ) { serverSocket . close ( ) ; } e l s e i f ( s c != n u l l ) { sc . c los e ( ) ; } } catch ( E x c e p t i o n e ) { } ssc . close ( ) ; s w i t c h D i s p l a y a b l e ( getByeAl ( ) , g e t I n v i t e F r m ( ) ) ; } } } catch ( E x c e p t i o n e ) { e . printStackTrace ( ) ; } }

54

7

ZÁVĚR

Práce byla zaměřena především na porozumění SIP protokolu, seznámení se SIP API a možného využití SIP protokolu v mobilním zařízení. Nejprve je soustředěna na stručné popsání využití SIP protokolu a porovnání s H.323 protokolem, který je dosud nejpoužívanějším protokolem pro VoIP. Dále byl popsán podrobně SIP protokol jeho metody navazování spojení, signalizace, přenos zpráv a také možnosti zabezpečení přenosu a řešení problému vznikající při průchodu SIP protokolu přes firewally a NAT. Jelikož je SIP protokol jednoduchý a podporuje mobilitu, je vhodný pro využití k vytvořeni SIP klienta pro mobilní zařízení. Tímto problémem se zabývalo několik pracovních skupin, které vytvořili SIP API, jež umožňuje snadnější vytváření SIP aplikací pro zařízení používající J2ME. Díky tomu, že mobilní operátoři zavádějí nové technologie do mobilních datových sítí, nebo že se objevují na trhu telefony podporující WiFi připojení, se dá předvídat SIPu velká budoucnost využití pro VoIP v mobilních zařízeních. Na základě těchto získaných informací byla podle specifikace RFC-3261 vytvořena aplikace, která z pohledu uživatele zajišťuje službu registrace SIP účtu k Registrar serveru, dále umožňuje tzv. peer-to-peer komunikaci s druhým klientem a přenos textových zpráv. Z pohledu síťového rozhraní obstarává kompletní signalizaci potřebnou, pro zajištění zmíněných služeb. Implementuje dvě části starající se o komunikaci. První částí je User Agent Client, který obstarává iniciaci žádostí. Iniciace spočívá především v nastavení základních informací o cíli, kterému je žádost určena. Druhou částí je User Agent Server, který obstarává příchozí žádosti a v reakci na ně odesílá odpovědi. Aplikace byla vytvořena v NetBeans IDE 6.0 s mobility balíčkem a s využitím Java Wireless Toolkit (WTK) 2.5.2 od firmy Sun. WTK obsahuje mnoho užitečných nástrojů, ze kterých byl využit emulátor mobilního telefonu a SIP Proxy/Registrar server. Na emulátoru byl prováděl vývoj a zkoušky funkčnost aplikace. SIP Proxy/Registrar server se využil především při testování registrace a k navazování spojení s druhým klientem. Server obsahuje i jednoduchý SIP analyzátor, který zobrazuje zachycené SIP zprávy. Pro podrobnější informace o probíhající síťové komunikaci, byl použit protokolový analyzátor Wireshark. Testování aplikace bylo úspěšně provedeno pomocí ústředny Asterisk, spočívalo v provedení registrace účtu a navázání spojení s IP telefonem. Takto navržená aplikace je vhodná pro další rozšiřování, jako je například implementace STUN klienta či instant messaging.

55

LITERATURA [1] HANDLEY, M., JACOBSON V. SDP: Session Description Protocol,RFC 2327 [online]. IETF, 1998, Dostupné z URL: . [2] SCHULZRINNE, H., JACOBSON, V., CASNER, S., FREDERICK, R. RTP: A Transport Protocol for Real-Time Applications, RFC 3550 [online]. IETF, 2003, Dostupné z URL: . [3] HRUBÝ, P. Protokol SIP [online]. 2003, .

Dostupné

z

URL:

[4] JSR-180 EXPERT GROUP SIP API for JavaT M 2 Micro Edition [online]. 2007, Dostupné z URL: . [5] JSR-135 Mobile Media API [online]. .

2007,

Dostupné

z

URL:

[6] KURUC, J. Srovnání: nejrychlejší mobilní internet [online]. 2007, Dostupné z URL: . [7] VIKRAM, G. Pro Java ME MMAPI Mobile Media API for Java Micro Edition Apress, 2006. 267 s. ISBN:1590596390 [8] ROSENBERG, J., SCHULZRINNE, H., CAMARILLO, G. SIP: Session Initiation Protocol,RFC 3261 [online]. IETF, 2002, Dostupné z URL: . [9] SUN MICROSYSTEMS Connected Limited Device Configuration [online]. 2003, Dostupné z URL: . [10] TOPLEY, K. J2ME V KOSTCE Pohotová referenční příručka GRADA, 2004. 519 s. ISBN: 80-247-0426-9 [11] WARD, M. Secure SIP chrání provoz VoIP [online]. 2007, Dostupné z URL: .

56