razvoj sistema za obveŠČanje velikega Števila … · an increasingly versatile service-centric...

Marko Lubej

RAZVOJ SISTEMA ZA OBVEŠČANJE VELIKEGA ŠTEVILA UPORABNIKOV TELEKOMUNIKACIJSKIH OMREŽIJ

Diplomsko delo

Maribor, maj 2009

I

Diplomsko delo univerzitetnega študijskega programa

RAZVOJ SISTEMA ZA OBVEŠČANJE VELIKEGA ŠTEVILA UPORABNIKOV

TELEKOMUNIKACIJSKIH OMREŽIJ

Študent: Marko LUBEJ

Študijski program: Univerzitetni, Telekomunikacije

Smer: Telekomunikacije

Mentor: doc. dr. Bojan IMPERL

Somentor: doc. dr. Tomaž ROTOVNIK

Lektorica: Margit Berlič Ferlinc, prof.

Maribor, maj 2009

III

ZAHVALA

Zahvaljujem se mentorju doc. dr. Bojanu

IMPERLU in somentorju doc. dr. Tomažu

ROTOVNIKU za vso strokovno svetovanje,

potrpežljivost in vzpodbujanje v času nastajanja

diplomskega dela. Hvala tudi doc. dr. Andreju

ŽGANKU za pomoč in svetovanje.

Posebna zahvala velja tudi mojim staršem, ki so mi

omogočili študij.

IV

RAZVOJ SISTEMA ZA OBVEŠČANJE VELIKEGA ŠTEVILA UPORABNIKOV TELEKOMUNIKACIJSKIH OMREŽIJ

Ključne besede: telekomunikacije, storitve v telekomunikacijah, omrežja naslednje

generacije, VoiceXML, Parlay X, interaktivni glasovni odzivnik,

aplikacijski strežnik, klicni strežnik, VoIP.

UDK: 004.77:621.395(043.2)

Povzetek

Omrežja fiksne telefonije, podatkovna omrežja, omrežja mobilne telefonije in internet

danes niso več samostojni in neodvisni ločeni sistemi, temveč se povezujejo in zlivajo v

vedno bolj prepleteno in storitveno pestro platformo, ki odpira priložnosti za razvoj novih -

konvergenčnih storitev. Diplomsko delo predstavlja vse korake razvoja ene izmed takšnih

konvergenčnih storitev, sistema za obveščanje velikega števila uporabnikov

telekomunikacijskih omrežij, ki izkorišča zmožnosti sodobnih omrežij. Delo opisuje vse

faze razvoja, od analize omrežij naslednje generacije in njihovih elementov ter

informacijskih tehnologij, ki omogočajo implementacijo samih storitev, do analize

konkretnega problema in načrtovanja rešitve. Rezultat dela je sistem, napisan v

programskem jeziku Java, ki teče na operacijskem sistemu Windows in v veliki meri

izkorišča storitve vmesnika Parlay X, standardiziranega vmesnika za dostop do

funkcionalnosti telekomunikacijskih omrežij. Sistem je sestavljen iz dveh delov, prvi del je

spletni grafični uporabniški vmesnik, ki omogoča manipulacijo nad podatki v podatkovni

bazi, drugi del pa aplikacija, katera samodejno izvaja telefonske klice in s tem opravlja

funkcijo obveščanja uporabnikov telekomunikacijskih omrežij.

V

DEVELOPMENT OF A SYSTEM FOR INFORMING A LARGE NUMBER OF USERS OF TELECOMMUNICATION NETWORKS

Key words: telecommunications, services in telecommunications, next

generation networks, VoiceXML, Parlay X, interactive voice

response, application server, call server, VoIP.

UDK: 004.77:621.395(043.2)

Abstract

Fixed telephony networks, data networks, mobile telephony networks and the Internet

are no longer separate and independent systems, but they are connecting and merging in

an increasingly versatile service-centric platform that offers a variety of opportunities for

development of new convergent services. The diploma thesis represents the steps of the

development of one of such convergent services, a system for informing a large number of

users of telecommunication networks, which exploits the capabilities of modern networks.

The work describes all phases of development, from analysis of next generation networks

and their elements, and information technologies that enable the implementation of

services, to the analysis of the concrete problem and planning of a solution. The result of

the work is a system, written in the Java programming language that runs on the Windows

operating system and largely exploits services of the Parlay X interface, a standardized

interface for accessing the functionality of the telecommunication networks. The system

consists of two parts, the first part is a web graphical user interface that allows the

manipulation of data in the database, the second part is an application, which

automatically implements phone calls and thus performs the function of informing the

users of telecommunication networks.

VI

VSEBINA

1 UVOD...................................................................................................................................................... 1

2 KOMUNIKACIJSKA OMREŽJA....................................................................................................... 3

2.1 VODOVNO PREKLAPLJANJE ............................................................................................................. 3 2.2 PAKETNO PREKLAPLJANJE............................................................................................................... 5 2.3 PRIMERJAVA VODOVNEGA IN PAKETNEGA PREKLAPLJANJA ............................................................ 6 2.4 OMREŽJA NASLEDNJE GENERACIJE - NGN ...................................................................................... 7

3 GOVOR PREK IP ................................................................................................................................. 8

3.1 ZAKAJ VOIP?.................................................................................................................................. 8 3.2 PRENOS GOVORA Z IP.................................................................................................................... 11 3.3 RTP – TRANSPORTNI PROTOKOL ZA REALNI ČAS........................................................................... 12 3.4 H.323............................................................................................................................................ 13

3.4.1 Arhitektura H.323.................................................................................................................... 13 3.4.2 Klicni scenarij H.323............................................................................................................... 15

3.5 SIP – PROTOKOL ZA ZAGON SEJE................................................................................................... 16 3.5.1 Arhitektura SIP........................................................................................................................ 17 3.5.2 Vzpostavljanje klica SIP .......................................................................................................... 18 3.5.3 Prednosti SIP-a pred drugimi signalizacijskimi protokoli ...................................................... 20

4 KONCEPT NGN – ELEMENTI OMREŽJA.................................................................................... 21

4.1 CS – KLICNI STREŽNIK.................................................................................................................. 23 4.2 AS – APLIKACIJSKI STREŽNIK ....................................................................................................... 24 4.3 PREHODI........................................................................................................................................ 24

5 APLIKACIJSKI STREŽNIK ............................................................................................................. 26

6 TEHNOLOGIJE, UPORABLJENE PRI RAZVOJU SISTEMA.................................................... 31

6.1 PROGRAMSKI JEZIK JAVA .............................................................................................................. 31 6.2 PROGRAMSKI JEZIK SQL............................................................................................................... 33 6.3 PODATKOVNA BAZA MYSQL........................................................................................................ 34 6.4 PROGRAMSKI JEZIK VOICEXML ................................................................................................... 35 6.5 PARLAY X..................................................................................................................................... 38 6.6 RAZVOJNO OKOLJE NETBEANS...................................................................................................... 44

VII

7 SISTEM ZA OBVEŠČANJE VELIKEGA ŠTEVILA UPORABNIKOV

TELEKOMUNIKACIJSKIH OMREŽIJ ................................................................................................... 46

7.1 PREDSTAVITEV OKOLJA ................................................................................................................ 46 7.2 IZBIRA TEHNOLOGIJ ...................................................................................................................... 48 7.3 ARHITEKTURA IN ZASNOVA SISTEMA ............................................................................................ 49

7.3.1 Podatkovna baza...................................................................................................................... 49 7.3.2 Grafični uporabniški vmesnik.................................................................................................. 50 7.3.3 Funkcije grafičnega uporabniškega vmesnika......................................................................... 51 7.3.4 Aplikacija za obveščanje uporabnikov .................................................................................... 56 7.3.5 Scenarij klica ........................................................................................................................... 61 7.3.6 Glasovni odzivnik .................................................................................................................... 64

8 PRIMERJAVA DELOVANJA SISTEMA Z DELOM OPERATERJA......................................... 66

9 SKLEP .................................................................................................................................................. 67

VIRI, LITERATURA ................................................................................................................................... 69

PRILOGE ...................................................................................................................................................... 71

NASLOV ŠTUDENTA ..................................................................................................................................... 71 KRATEK ŽIVLJENJEPIS ................................................................................................................................. 71

VIII

SEZNAM SLIK

Slika 2.1: Prikaz vodovnega preklapljanja ............................................................................ 4

Slika 2.2: Prikaz paketnega preklapljanja.............................................................................. 5

Slika 3.1: Lega RTP-ja v protokolnem skladu in ugnezdenje paketa.................................. 12

Slika 3.2: Doseg H.323........................................................................................................ 14

Slika 3.3: Scenarij klica H.323 ............................................................................................ 16

Slika 3.4: Logična ločitev signalizacije SIP in medijev ...................................................... 17

Slika 3.5: Delovanje strežnika proksi .................................................................................. 18

Slika 3.6: Scenarij vzpostavljanja klica SIP ........................................................................ 19

Slika 4.1: Arhitektura NGN................................................................................................. 22

Slika 5.1: Aplikacijski strežnik v večslojni arhitekturi ....................................................... 28

Slika 5.2: Arhitektura AS in Parlay/OSA okolja................................................................. 30

Slika 6.1: Preprost programček, napisan v Javi................................................................... 33

Slika 6.2: Primer poizvedbe z jezikom SQL ....................................................................... 34

Slika 6.3: Arhitektura VoiceXML....................................................................................... 37

Slika 6.4: Arhitektura Parlay X ........................................................................................... 39

Slika 6.5: Third Party Call scenarij ..................................................................................... 42

Slika 6.6: Netbeans IDE ...................................................................................................... 45

Slika 7.1: Okolje sistema za obveščanje.............................................................................. 47

Slika 7.2: SoftPhone ............................................................................................................ 48

Slika 7.3: Arhitektura sistema za obveščanje uporabnikov................................................. 49

Slika 7.4: Struktura tabele v podatkovni bazi...................................................................... 50

IX

Slika 7.5: Arhitektura grafičnega uporabniškega vmesnika................................................ 51

Slika 7.6: Vstopni obrazec za prijavo v spletno aplikacijo.................................................. 52

Slika 7.7: Glavno okno spletne aplikacije ........................................................................... 53

Slika 7.8: Dodajanje novega vnosa...................................................................................... 53

Slika 7.9: Urejanje obstoječega vnosa................................................................................. 55

Slika 7.10: Brisanje vnosa iz baze ....................................................................................... 55

Slika 7.11: Umestitev aplikacije v omrežje ......................................................................... 57

Slika 7.12: Življenjski cikel aplikacije ................................................................................ 57

Slika 7.13: Potek pridobivanja telefonskih številk iz baze.................................................. 59

Slika 7.14: Potek klicanja številk iz seznama za klicanje.................................................... 60

Slika 7.15: Klic metode makeCall....................................................................................... 61

Slika 7.16: Potek klica ......................................................................................................... 62

Slika 7.17: Arhitektura glasovnega odzivnika..................................................................... 64

Slika 7.18: Scenarij delovanja glasovnega odzivnika ......................................................... 65

X

SEZNAM TABEL

Tabela 3.1: Metode SIP, definirane v osnovni specifikaciji................................................ 19

Tabela 6.1: Seznam Parlay X 3.0 specifikacij ..................................................................... 40

Tabela 6.2: CallStatus.......................................................................................................... 43

Tabela 6.3: CallTerminationCause...................................................................................... 43

Tabela 6.4: Struktura CallInformation................................................................................. 44

Tabela 7.1: Seznam vrednosti parametra »status«............................................................... 58

XI

UPORABLJENE KRATICE IN OZNAKE

3GPP Third Generation Partnership Project Partnerski projekt tretje generacije

ACF Admission Confirm potrditev sprejema

ANSI American National Standards Institute

Ameriški nacionalni inštitut za standardizacijo

API Application Programming Interface aplikacijski programski vmesnik

ARQ Admission request zahteva sprejema

AS Application Server aplikacijski strežnik

ASP Active Server Pages aktivne strežniške strani

ASR Automatic Speech Recognition samodejna razpoznava govora

ATM Asynchronous Transfer Mode asinhroni prenosni način

BGCF Breakout Gateway Control Function

funkcija krmiljenja prebojnega prehoda

CGI Common Gateway Interface splošni vmesnik prehoda

CLC Close Logical Channel zapri logični kanal

CS Call Server klicni strežnik

CSCF Call Session Control Function funkcija krmiljenja klicne seje

DTMF Dual-tone Multi-Frequency dvotonska večfrekvenčna signalizacija

ETSI European Telecommunications Standards Institute

Evropski inštitut za telekomunikacije

FR Frame Relay blokovno posredovanje

GUI Graphical User Interface grafični uporabniški vmesnik

HTML HyperText Markup Language jezik za označevanje hiperteksta

XII

HTTP Hypertext Transfer Protocol protokol za prenos hiperteksta

IDE Integrated Development Environment integrirano razvojno okolje

IIS Internet Information Server spletni informacijski strežnik

IMS IP Multimedia Subsystem IP multimedijski podsistem

IP Internet Protocol internetni protokol

ISDN Integrated Services Digital Network

digitalno omrežje z integriranimi storitvami

ISO International Organization for Standardization

Mednarodna organizacija za standardizacijo

ITU-T International Telecommunication Union – Telecommunication Standardization Sector

Mednarodna telekomunikacijska zveza – sektor za standardizacijo telekomunikacij

JAR Java ARchive javanska arhivska datoteka

JSP Java Server Pages javanske strežniške strani

JVM Java Virtual Machine javanska navidezna naprava

LAN Local Area Network lokalno omrežje

MCU Multipoint Control Unit večtočkovna kontrolna enota

MGCF Media Gateway Control Function funkcija krmiljenja medijskega prehoda

MGCP Media Gateway Control Protocol krmilni protokol za nadzor medijskih prehodov

MGW Media GateWay medijski prehod

MMS Multimedia Messaging Service storitev večpredstavnostnih sporočil

MSC Mobile Switching Center mobilni komutacijski center

MySQL My Structured Query Language ime podatkovne baze

NGN Next Generation Network omrežje naslednje generacije

OLC Open Logical Channel odpri logični kanal

OSA Open Services Architecture arhitektura odprtih storitev

XIII

PERL Practical Extraction and Report Language

priročni jezik za izvlečke in poročila

PCM Pulse-Code Modulation pulzno-kodna modulacija

PSTN Public Switched Telephone Network

javno komutirano telefonsko omrežje

RDBMS Relational Database Management System

sistem za upravljanje relacijskih podatkovnih baz

RPC Remote Procedure Call klic za oddaljeni postopek

RTCP Real-time Transport Control Protocol

krmilni transportni protokol v realnem času

RTSP Real-time Streaming protocol protokol strujanja v realnem času

RTP Real-time Transport Protocol transportni protokol v realnem času

SAP Session Announcement Protocol protokol za najavo seje

SBC Session Border Controller mejni krmilnik sej

SDP Session Description Protocol protokol za opis seje

SGW Signaling Gateway signalizacijski prehod

SIP Session Initiation Protocol protokol za zagon seje

SMS Short Message Service storitev kratkih sporočil

SOAP Simple Object Access Protocol protokol za izmenjavo XML sporočil preko omrežja

SS7 Signaling System No. 7 signalizacija številka 7

SQL Structured Query Language strukturirani jezik za poizvedovanje

TCP Transmission Control Protocol protokol za krmiljenje prenosa

TTS Text-To-Speech sinteza govora iz besedila

UAC User Agent Client klient uporabniškega agenta

UAS User Agent Server strežnik uporabniškega agenta

UDP User Datagram Protocol uporabniški datagramski protokol

URL Uniform Resource Locator enolični lokalizator vira

VoIP Voice Over IP govor prek IP

XIV

VoP Voice over Packet govor preko paketnega omrežja

VoiceXML Voice eXtensible Markup Language

glasovni razširljivi označevalni jezik

WAN Wide Area Network prostrano omrežje

WSDL Web Services Description Language jezik za opis spletnih storitev

XML eXtensible Markup Language razširljiv označevalni jezik

Razvoj sistema za obveščanje velikega števila uporabnikov telekomunikacijskih omrežij 1

1 UVOD

Omrežja in storitve nove generacije so temeljito prevetrile način pojmovanja

komunikacije, kakršen je bil v veljavi do danes. Odprla so nova obzorja tako s

tehnološkega kot tudi s storitvenega in socialno-psihološkega stališča. Omrežja fiksne

telefonije, podatkovna omrežja, omrežja mobilne telefonije in internet danes niso več

samostojni in neodvisni ločeni sistemi. Korakoma se povezujejo in zlivajo v vedno bolj

prepleteno, tehnološko in storitveno pestro platformo, ki odpira priložnosti za nove

storitve. Arhitekturno gledano je koncept zasnovan zelo široko in integrira obsežen nabor

dostopovnih in jedrnih tehnologij. Skladno s tem so potrebni ustrezni signalizacijski

postopki in nadzor sistema kot celote. Potrebna je tudi učinkovita platforma za načrtovanje,

razvoj in vpeljavo tržno zanimivih storitev. Pri tem so ključni predvsem varnostni vidiki in

zanesljivost, tako s stališča omrežja kot celote in operaterja, ki ga upravlja, kot tudi

končnega uporabnika, ki dostopa do omrežja in koristi storitve. Vodilo in razlog za

uvajanje novih sistemov so vselej uporabniki. Le-ti s sodobnim načinom življenja,

potrebami, zahtevami in znanjem narekujejo nove trende. Izkazalo se je že, da v ospredje

stopa mobilni princip komuniciranja. Med storitvami so ključne prisotnost, lokalizacija,

personalizacija in prepletanje tehnološko in predstavnostno različnih principov sporočanja.

Poglavitni izziv pri zastavljenih ciljih je slediti potrebam, ki so se izkazale kot

pomanjkljivost preteklih sistemov. Obenem je potrebno poskrbeti za stabilnost, ki je

potreben pogoj za uspešnost tovrstnih rešitev. Nenazadnje ne gre zanemariti finančnih in

socioloških parametrov, ki v širšem kontekstu oblikujejo sodobno informacijsko družbo.

S tem diplomskim delom bi radi predstavili razvoj sistema za obveščanje velikega

števila uporabnikov telekomunikacijskih omrežij. V vsakdanjem življenju se velikokrat

srečamo s primeri, ko se pokaže potreba po hitrem obveščanju velikega števila ljudi (npr.

obveščanje neplačnikov, obveščanje ob naravnih nesrečah …) in le malokrat obstajajo za

ta namen učinkovite rešitve. Namen dela je izdelati in predstaviti celovito rešitev ob

uporabi vseh funkcionalnosti in tehnologij, ki jih ponujajo omrežja naslednje generacije.


Diplomsko delo predstavlja korak v smeri izpolnjevanja potreb operaterjev

telekomunikacij. Operaterji imajo omrežje, opremo in množico uporabnikov, kateri

zahtevajo vedno nove storitve. Sistem za obveščanje velikega števila uporabnikov

telekomunikacijskih omrežij, ki je predmet tega diplomskega dela, izkorišča zmožnosti

sodobnih omrežij in novih tehnologij, ter je tako idealen za operaterje, ki bi ga lahko brez

težav vključili v svoje omrežje in tako ponudili novo storitev. S pomočjo takšnega

avtomatiziranega sistema lahko operaterji učinkovito in z minimalnimi stroški rešujejo

problem obveščanja svojih uporabnikov, hkrati pa sistem prinaša korist tudi uporabnikom,

ki so lahko na ta način bolj pogosto in bolj podrobno obveščani o različnih zadevah.

Naša naloga je bila izdelati tako grafični vmesnik, preko katerega bo mogoče vstavljati,

brisati in urejati vnose v bazi podatkov, kot tudi samo aplikacijo, ki bo iz baze pridobila

vse potrebne informacije in samodejno izvajala telefonske klice. Ko bo klicani uporabnik

telekomunikacijskih omrežij odgovoril na prejeti telefonski klic, bo sistem aktiviral

glasovni odzivnik, ki bo uporabniku predvajal predvideno sporočilo.

Diplomsko delo je sestavljeno iz devetih poglavij. Najprej bomo za boljše razumevanje

pregledali komunikacijska omrežja. V ospredje bodo postavljena vodovno in paketno

preklapljana omrežja ter omrežja naslednje generacije. Predstavili bomo osnovne

značilnosti posamezne vrste omrežja in osnove njihovega delovanja. V tretjem poglavju

bomo predstavili govor prek IP. Povedali bomo, zakaj govor prek IP postaja vedno

popularnejši. Razložili bomo tudi, kako se govor sploh prenaša prek omrežja IP in kateri

protokoli so najpomembnejši pri tem. V četrtem poglavju bomo predstavili koncept

omrežij naslednje generacije. Opisali bomo najpomembnejše elemente omrežij NGN, ki so

potrebni za realizacijo sistema za obveščanja velikega števila uporabnikov. V petem

poglavju bo podrobno predstavljen osrednji element omrežij naslednje generacije,

aplikacijski strežnik. Povedali bomo, kje se uporablja in kakšne storitve ponuja. V šestem

poglavju bodo predstavljeni programski jeziki in tehnologije, ki smo jih uporabili pri

načrtovanju in implementaciji sistema za obveščanje velikega števila uporabnikov. V

sedmem poglavju bomo opisali razvoj sistema, ki je predmet tega diplomskega dela.

Predstavili bomo ves postopek – od ideje do realizacije. Predstavili bomo končni izdelek in

opisali težave, na katere smo naleteli pri razvoju. Osmo poglavje je namenjeno primerjavi

delovanja sistema z delom operaterja. V zadnjem, devetem poglavju, je podan sklep

diplomskega dela.


2 KOMUNIKACIJSKA OMREŽJA

Podatki, to so lahko na primer glas, slika, video, navadni podatki (številke, besedilo), se

na večjem območju od izvora do cilja prenašajo po omrežju vmesnih preklopnih vozlišč,

imenovanih usmerjevalniki ali centrale. V tem poglavju si bomo najprej ogledali in med

seboj primerjali osnovni vrsti preklapljanja v komunikacijskih omrežjih, vodovno in

paketno. To sta tradicionalna preklopna načina. Preostali načini preklapljanja so ponavadi

izpeljanke iz teh dveh osnovnih načinov. Izmed bolj znanih sta še asinhroni prenosni način

(ATM – Asynchronous Transfer Mode) in blokovno posredovanje (FR – Frame Relay).

Podrobneje se bomo seznanili le z vodovnim in paketnim preklapljanjem, saj nam bo

poznavanje teh dveh omrežij pomagalo pri razumevanju strukture in delovanja omrežij

naslednje generacije (NGN – Next Generation Network), ki so ravno posledica zlivanja in

združevanja različnih vrst omrežij v eno transparentno, tehnološko in storitveno pestro

omrežje. Naslednji razvojni korak z bolje definiranimi omrežnimi elementi, nalogami,

zmogljivostmi, protokoli in vmesniki je IP multimedijski podsistem (IMS – IP Multimedia

Subsystem), ki je danes označen kot potencialno izhodišče za oblikovanje dejanske

arhitekture, ki bo upoštevala tako fiksne kot mobilne vidike omrežij.

2.1 Vodovno preklapljanje

Vodovno preklapljanje (»circuit switching«) je danes prevladujoča tehnologija za

glasovne komunikacije [2]. Podatki se na večjem območju od izvora do cilja prenašajo po

omrežju vmesnih preklopnih vozlišč, imenovanih usmerjevalniki ali centrale. Central ne

zanima vsebina podatkov, ampak le premikajo podatke do cilja. Končne naprave, ki želijo

komunicirati, imenujemo postaje. To so lahko računalniki, terminali, telefoni in druge

komunikacijske naprave. Vsaka končna naprava je povezana na neko vozlišče, vsa vozlišča

skupaj s povezavami pa tvorijo omrežje (sl. 2.1). Pri tem načinu prenosa je točno določena

komunikacijska pot med dvema postajama za čas trajanja komunikacije oz. zveze med


njima. Pot je zaporedje vodov med vozlišči. Na vsakem vodu je neki kanal dodeljen samo

tej zvezi.

Komunikacija z uporabo vodovnega preklapljanja je sestavljena iz treh faz:

1. Vzpostavljanje zveze

Preden se lahko pošiljajo (podatkovni) signali, se mora vzpostaviti zveza od konca

do konca (od izvorne do ciljne postaje). V omrežju na sliki 2.1 na primer postaja A

pošlje zahtevo vozlišču 1 za vzpostavitev zveze do postaje B. Vozlišče 1 mora

izbrati naslednjo linijo v poti do vozlišča 3. To se zgodi na osnovi usmerjevalne

informacije, razpoložljivosti ali morda cene. V našem primeru izbere vozlišče 1

linijo do vozlišča 4, dodeli prost kanal na liniji 1-4 in pošlje vozlišču 4 zahtevo za

zvezo do postaje B. Preostanek poti se izbira podobno.

2. Prenos signalov

Ko je zveza vzpostavljena, se lahko prenašajo signali po omrežju od A do B. Signali

gredo najprej po A-1, nato se interno preklopijo skozi 1, nato gredo po kanalu 1-4,

se preklopijo skozi 4 in potujejo po kanalu 4-3, se preklopijo skozi 3 in potujejo po

3-B. V splošnem je zveza popolno dvosmerna.

3. Brisanje zveze

Po prenosu podatkov se zveza konča. Ponavadi jo konča ena od obeh postaj.

Slika 2.1: Prikaz vodovnega preklapljanja


2.2 Paketno preklapljanje

Medkrajevna vodovno preklapljana telekomunikacijska omrežja so bila v osnovi

razvita za glasovni promet. Bistvo teh omrežij je, da se viri v omrežju dodelijo določenemu

klicu oz. zvezi. To pomeni, da je zveza oz. vzpostavljena fizična povezava dobro

izkoriščena, če se po njej izvaja glasovni promet. Če prenašamo podatke, pa se pojavi ena

večja pomanjkljivost. Pri značilni zvezi, kot je na primer zveza terminal – gostiteljski

računalnik, se velik del časa ne prenaša nič. Torej je vodovno preklapljanje tu neučinkovito

v smislu izkoriščenosti povezave. To težavo rešuje paketno preklapljanje.

Pri paketnem preklapljanju se podatki prenašajo v paketih (značilna zgornja meja

dolžine paketov je okoli 1000 oktetov). Predolga sporočila se razbijejo v zaporedje

paketov. Vsak paket vsebuje uporabniške podatke in neko nadzorno informacijo, ki

vsebuje najmanj informacijo, potrebno za usmerjanje paketa skozi omrežje in predajo

izbranemu cilju.

Poglejmo omrežje na sliki 2.2, ki je paketno preklapljano. Vzemimo, da morajo biti

paketi poslani od postaje A do postaje B. Vsak paket bo vseboval nadzorno informacijo, ki

bo označevala, da je cilj paketa postaja B.

Slika 2.2: Prikaz paketnega preklapljanja


Prvi paket se najprej pošlje od postaje A do vozlišča 1. Ta paket shrani, izbere

naslednjo etapo na poti (na primer do vozlišča 3) in da paket v izhodno vrsto za izbrano

linijo (1 – 3) . Ko je ta prosta, se paket pošlje v vozlišče 3, ki ga bo poslalo v vozlišče 5, ta

pa končno do postaje B. Podobno velja za ostale pakete sporočila. Paketi, ki potujejo med

isto izvorno in ponorno točko, lahko gredo skozi omrežje preko različnih vozlišč (paket P3

na sl. 2.2). Pravilno zaporedje prispelih paketov, ki se ponovno združijo v originalno

sporočilo, zagotovi sprejemna stran.

2.3 Primerjava vodovnega in paketnega preklapljanja

Pri vodovnem preklapljanju se mora najprej skozi omrežje cilju poslati signal zahteve

po klicu za vzpostavitev zveze do cilja. Če cilj ni zaseden, pošlje nazaj signal sprejema

klica. Med zahtevo po klicu se v vsakem vozlišču pojavi zakasnitev zaradi procesiranja

zaradi vzpostavljanja poti. Pri povratnem signalu pa te zakasnitve ni več, ker je zveza že

vzpostavljena. Potem se sporočilo pošlje v enem bloku, brez omembe vredne zakasnitve v

preklopnih vozliščih. Vodovno preklapljanje je transparentno in zagotavlja konstantno

hitrost prenosa podatkov skozi omrežje.

Paketno preklapljanje ima vrsto prednosti pred vodovnim:

• Večja je linijska učinkovitost (izkoriščenost linij), ker lahko eno linijo

uporabljajo paketi iz različnih zvez. Postavijo se v vrsto in pošljejo naprej takoj,

ko je mogoče. Pri vodovnem preklapljanju pa so določene časovne reže na liniji

med vozliščema vnaprej prirejene eni zvezi s sinhronim časovnim

multipleksiranjem. Lahko se zgodi, da je linija večino časa prosta, če so reže

dodeljene zvezi, v kateri se nič ne pošilja.

• Paketno omrežje lahko izvaja pretvorbo podatkovne hitrosti. Pakete si lahko

izmenjujeta postaji z različnima podatkovnima hitrostma, ker je vsaka povezana

na svoje vozlišče s svojo podatkovno hitrostjo.

• Če v vodovno preklapljanem omrežju postane promet gost, so nekateri klici

blokirani. Paketno omrežje pa ponavadi odposlane pakete kljub velikemu

prometu sprejme za prenos, poveča pa se zakasnitev prenosa.


2.4 Omrežja naslednje generacije - NGN

Razvoj tehnologij in poslovnih modelov vodi v konvergenco omrežij in storitev. NGN

predstavlja pojem, pod katerim se skriva poenotenje oz. povezanost obstoječih omrežij, ki

omogočajo prenos oz. uporabo storitev, temelječih na IP (Internet Protocol – internetni

protokol) protokolu. IP protokol je bil razvit posebej za medomrežno povezovanje.

Protokol se uporablja za prenos podatkov v paketno preklapljanih omrežjih, ki smo jih

opisali v podpoglavju 2.2. Koncept omrežij in storitev naslednje generacije izhaja iz

obstoječe situacije na področju telekomunikacij, ki temelji na hierarhični arhitekturi,

zagotovljeni kakovosti storitev, upravljanju, nadzoru ter standardiziranih rešitvah.

Ključnega pomena je načelo interoperabilnosti »vsega in med vsem«. Lahko rečemo, da

gre za (r)evolucijo v razvoju velikih telekomunikacijskih sistemov. Nekdaj izrazito

tehnološko razmišljanje je danes v prvi vrsti usmerjeno k uporabniku, storitvam in

vsebinam.

Koncept omrežij naslednje generacije se širi od VoP (Voice over Packet – govor preko

paketnega omrežja) in VoIP (Voice over IP – govor prek IP), preko NGN vse do danes, ko

govorimo o IMS konceptu. Pri tem se poglavitne smernice ohranjajo, spreminjajo se le

imena, tehnološke rešitve pa se dograjujejo in prilagajajo realnim okoljem, v katerih naj bi

zaživele. Razvojni trendi v telekomunikacijah so usmerjeni k prehajanju na širokopasovna

paketna omrežja, razvoju novih storitev in zagotavljanju vsebin. Koncept NGN ne

opredeljuje sistemov podrobno, temveč le načela in cilje, po katerih naj bodo načrtovani.

Arhitekturna zasnova novih komunikacijskih sistemov je izrazito slojevita. Takšen

pristop pomeni večjo transparentnost in modularnost. Hkrati zagotavlja pregled

zmogljivosti in nalog, ki jih različni deli omrežja opravljajo. Po načelih koncepta omrežij

naslednje generacije sistem jasno ločuje sloj prenosa podatkov, sloj krmiljenja, storitve in

aplikacije ter sloj nadzora omrežja z ustreznimi podpornimi sistemi (beleženje,

zaračunavanje, statistična obdelava ipd.). Za komunikacije skrbijo protokoli, med katerimi

je bil pred leti najpomembnejši H.323, danes pa so to SIP (Session Initiation Protocol –

protokol za zagon seje), MGCP (Media Gateway Control Protocol – krmilni protokol za

nadzor medijskih prehodov), H.248/Megaco in vmesniki, kamor sodijo Parlay/Parlay X,

spletne storitve, XML (eXtensible Markup Language – razširljiv označevalni jezik) ipd. [7]


3 GOVOR PREK IP

Še pred nekaj leti je bilo precej dvomljivcev glede prenosa govora prek IP protokola.

Danes je teh vse manj, eden od razlogov pa je tudi ta, da uporabniki šele spoznavajo nove

možnosti, ki jih prinaša IP protokol. Ideja prenosa govora prek podatkovnih omrežij sicer

ni novost, kot bi marsikdo pomislil. V svojih prvih korakih pred desetletji je bil namen

predvsem zniževanje stroškov komunikacije. O kakršnihkoli dodatnih možnostih,

povezanih s tovrstno komunikacijo, ni bilo govora. Danes, ko postajajo uporabniki vse

zahtevnejši ter iščejo nove možnosti in storitve, se je pokazala še večja potreba po prehodu

govornega prometa na IP omrežja. Nesporno je prednost prenosa govora prek IP protokola

prav v novih storitvah ali lažji izvedbi obstoječih.

V tem poglavju bomo predstavili govor prek IP ter navedli nekaj dejstev, zakaj postaja

vedno bolj razširjen. Razložili bomo tudi, kako se govor sploh prenaša prek omrežja IP in

kateri protokoli so najpomembnejši pri tem.

3.1 Zakaj VoIP?

Govor prek IP preprosto pomeni prenos govornega prometa s protokolom IP.

Pravzaprav bi bilo bolj pravilno reči prenos glasovnega prometa (»voice«). Govor prek IP

ni isto kot govor prek interneta1, saj VoIP ne pomeni avtomatično, da se govor prenaša

prek interneta. V njem so včasih še težave z zagotavljanjem visokokakovostnega prenosa

govora, vendar je tudi teh vse manj. Problem se pojavlja predvsem v slabo načrtovanih

omrežjih [2].

1 V primeru internetne telefonije se za prenosno pot uporablja internet z vsemi svojimi morebitnimi

negativnimi vplivi na kvaliteto storitve. VoIP je moč izvesti tudi po lastnih poteh, na katerih lahko ponudnik

sam zagotavlja QoS od vstopne do končne točke, česar pri internetu praktično ni moč zagotoviti.


Razvoj gre pravzaprav v smeri h »carrier-grade VoIP«. Temu bi lahko rekli tudi VoIP

na operaterski stopnji. S tem so mišljena omrežja VoIP, ki bi se v razpoložljivosti,

kapaciteti, zakasnitvah, kakovosti govora ipd. lahko primerjala z današnjimi običajnimi

vodovno preklapljanimi telefonskimi omrežji. Zaradi napredka v internetu (rast pasovnih

širin, izboljšana strojna oprema, protokoli …) in napredka algoritmov za kodiranje in

prenos govora lahko že danes govorimo o govoru prek interneta na operaterski stopnji.

Internetna telefonija naj bi pomenila telefonsko storitev prek IP, ki uporablja klasični

internetni pristop. To pomeni, da je nadzor storitve v sistemih končnih uporabnikov, na

primer v PC-jih. Protokol, ki omogoča, da je nadzor storitve v končnih sistemih, se

imenuje SIP. Protokol SIP bomo podrobneje opisali v nadaljevanju.

IP telefonija naj bi pomenila telefonsko storitev prek IP, pri kateri pa se nadzor storitve

zagotavlja z inteligenco znotraj omrežja, podobno kot v tradicionalnem telefonskem

omrežju, kjer so terminali ponavadi poceni naprave z malo funkcijami. Dejansko

opravljanje povezave prek omrežja izvajajo centrale, povezane na terminalsko opremo.

IP je privlačna izbira za prenos govora iz več vzrokov:

• Nižja cena opreme in obratovanja: sistemi za vodovno preklapljanje so ponavadi

lastniški. Sistem od določenega proizvajalca uporablja njegovo lastno strojno

opremo in operacijski sistem, aplikacije pa uporabljajo njegovo lastno programsko

opremo. Ko se operater enkrat odloči za določenega proizvajalca, je popolnoma

vezan nanj. V svetu IP je drugače. Večina strojne opreme je standardna in

operacijski sistem in aplikacije tudi niso tako tesno vezane na strojno opremo. Tako

imajo operaterji več možnosti izbire.

• Integriranje govornih in podatkovnih aplikacij – konvergenčne aplikacije: IP je

danes standard za podatkovne aplikacije. To pomeni za vse vrste aplikacij – od

elektronske pošte do brskanja po spletu in elektronskega poslovanja. Če tem

storitvam dodamo še govor, dobimo množico naprednih storitev, ki temeljijo na

integraciji - konvergenci obojega. Obstaja že kar nekaj konvergenčnih aplikacij, ki

združujejo govorne in podatkovne funkcije: univerzalno sporočanje, govorni

portali, klicni centri IP, govorni dostop do spletnih vsebin, aplikacije, ki povezujejo

SMS s spletnimi ali govornimi storitvami in podobno ...


• Potencialno nižje zahteve po pasovni širini: vodovno preklapljana telefonska

omrežja prenašajo govor s hitrostjo 64 kbps. Ta hitrost je dobljena z digitalizacijo

PCM (Pulse-Code Modulation – pulzno-kodna modulacija) z 8000 otipki v sekundi

in njihovo predstavitvijo z 8 biti. Za standardno telefonijo se uporablja ta način,

obstaja pa še veliko drugih kodirnih načinov, ki uporabljajo bolj izpopolnjene

kodirne algoritme in omogočajo prenos govora z manjšimi hitrostmi (npr. 32, 16,

6.3, 5.3 kbps). Nekateri od teh znajo tudi izločati tišino, tako da se promet prenaša

samo, ko je kaj rečeno. Rešitve za VoIP na splošno podpirajo te kodirne načine.

Prav tako pa standardi za VoIP omogočajo, da se konca klica pogajata, kateri način

bo uporabljen. Tako naj bi bil VoIP zmožen zmanjšati potrebe po pasovni širini na

eno osmino tiste, ki je uporabljena v vodovnih omrežjih.

• Splošna razširjenost IP-ja: IP je danes praktično povsod, celo v dlančnikih in

različnih brezžičnih napravah. Posledica tega je, da je znanje o IP zelo razširjeno in

da obstaja ogromno podjetij za razvijanje na njem temelječih aplikacij.

Da bi VoIP lahko resnično konkuriral vodovno preklapljani telefoniji, mora zagotavljati

enako zanesljivost in kakovost govora kot slednja. To pa pomeni, da mora zagotavljati

99.999 – odstotno razpoložljivost (»pet devetk«), ter kakovost govora iz fiksne telefonije.

Če hoče VoIP resno konkurirati tehnologiji z vodovnim preklapljanjem, mora biti kakovost

govora vsaj tako dobra kot v današnjih telefonskih omrežjih in se ne sme spreminjati.

Govorni promet ima drugačne zahteve glede kakovosti kot podatkovni, v nekaterih

pogledih prav nasprotne. Pri govoru je sprejemljiv večji odstotek izgubljenih paketov,

vendar mora biti manjši od 5 odstotkov. Nasprotno pa je zelo zahteven glede zakasnitve.

Priporočilo ITU-T (International Telecommunication Union – Telecommunication

Standardization Sector – Mednarodna telekomunikacijska zveza - sektor za standardizacijo

telekomunikacij) pravi, da mora biti krožna zakasnitev pri telefoniji 300 ms ali manj.

Druga pomembna zahteva pri govoru je, da mora biti čim manjše trepetanje (»jitter«).

To pomeni, da četudi obstaja določena zakasnitev, mora biti vsaj konstantna. To dosežemo

z medpomnilniki (»buffer«) za trepetanje, kjer se paketi shranijo, da se lahko redno

predvajajo sprejemniku. Žal pa medpomnjenje nekoliko prispeva k zakasnitvi. Trepetanje v

omrežjih IP se pojavlja iz dveh razlogov. Prvi je ta, da paketi lahko od oddajnika do


sprejemnika potujejo po različnih poteh. Drugi pa je, da paketi, četudi potujejo po isti poti,

lahko različno dolgo čakajo v vrstah, ker so omrežni viri, kot so čakalne vrste v

usmerjevalnikih, poleg govora namenjene še za drug promet. Za visoko kakovost se ne

sme med govorcem in poslušalcem izgubiti skoraj nič govora. Ravno zaradi polnih vrst v

paketnih omrežjih pa se lahko paketi izgubljajo.

Ena od velikih prednosti VoIP je, da bi lahko uporabljali eno omrežje za zelo različne

aplikacije, na primer podatke, govor in video. Res pa je, da je treba v enem omrežju

različne vrste prometa obravnavati različno. Danes predstavlja VoIP že resno konkurenco

vodovno preklapljani telefoniji. Nekateri današnji prehodi VoIP že lahko obravnavajo več

gigabitov govornega prometa na sekundo. Vse to z opremo, ki zavzema zelo malo prostora.

3.2 Prenos govora z IP

Za prenos govora prek IP se uporablja UDP (User Datagram Protocol – uporabniški

datagramski protokol) in TCP (Transmission Control Protocol – protokol za krmiljenje

prenosa), čeprav UDP ne zagotavlja zanesljivega prenosa, TCP pa. Pri pogovoru nas toliko

ne moti, če se občasno izgubita eden ali dva paketa, ker govorni promet na splošno

uporablja kratke pakete (s trajanjem od 10 do 40 ms). Sodobne kodirne metode za govor

delujejo bolje, če ni izgub paketov, vendar pa vseeno lahko kodirni in dekodirni algoritmi

občasne izgube nekako popravijo, tako da niso zelo opazne. TCP potrebuje določen čas za

vzpostavitev povezave in prihaja tudi do zakasnitev zaradi potrjevanja in ponovnih oddaj

ob izgubi paketov. To pa nam seveda ni všeč pri prenosu govora. Pomembno je tudi, da so

izgube dovolj enakomerno porazdeljene. Izgube skupin zaporednih paketov lahko

odpravimo z uporabo metod za upravljanje in rezervacijo virov. Pri UDP je možno tudi, da

se spremeni vrstni red paketov, vendar pa je to malo verjetno, saj je pri VoIP narejeno

tako, da v eni seji oz. klicu vsi paketi potujejo po eni poti. Do pomešanja vrstnega reda

paketov lahko pride le v primeru odpovedi. UDP v osnovi ni bil narejen za prenos govora,

vendar pa se je izkazal za primernejšega kot TCP. Nekatere slabosti pri UDP, ki so moteče

pri aplikacijah v realnem času (govorne in video aplikacije), pa odpravljamo z drugimi

protokoli. Eden izmed njih je RTP (Real-time Transport Protocol – transportni protokol v

realnem času).


3.3 RTP – transportni protokol za realni čas

Multimedijske aplikacije v realnem času, kot so internetni radio, internetna telefonija,

videokonference, video na zahtevo, potrebujejo ustrezen transportni protokol. Tako je

nastal RTP, ki se še zdaj na široko uporablja. Poznamo pa tudi krmilni protokol RTP-ja

(RTCP – RTP Control Protocol). Določeno je bilo, da se bo RTP nahajal v uporabniškem

delu protokolnega sklada in da se bo izvajal prek UDP. Na splošno bi lahko rekli, da RTP

zagotavlja storitev prenosa od konca do konca. To je posebej primerno za aplikacije, ki

oddajajo podatke v realnem času.

Delovanje RTP: Multimedijska aplikacija je sestavljena iz več avdio, video, tekstovnih

in tudi drugih tokov. Speljani so v knjižnico RTP, ki je v uporabniškem prostoru skupaj z

aplikacijo. Ta knjižnica nato tokove multipleksira in kodira v pakete RTP, te pa pošilja v

vtičnico (»socket«). Na drugem koncu vtičnice (v jedru operacijskega sistema) se iz njih

tvorijo paketi UDP in ugnezdijo v pakete IP. Če je računalnik priključen na ethernet, se

paketi IP za prenos ugnezdijo v ethernet okvirje (sl. 3.1).

Slika 3.1: Lega RTP-ja v protokolnem skladu in ugnezdenje paketa

Čeprav morda zgleda, kot da je RTP aplikacijski protokol v aplikacijskem sloju, temu

ni povsem tako. Je splošen protokol, od aplikacije neodvisen, in le zagotavlja transportne

zmožnosti. Najbolje je reči, da je transportni protokol implementiran v aplikacijskem sloju.

Paketi RTP vsebujejo zaporedno številko, da lahko aplikacija, ki uporablja RTP,

odkrije, da se je nekaj paketov izgubilo, ter da zagotovi dostavo paketov v pravilnem


vrstnem redu. RTP paketi vsebujejo tudi časovni zaznamek, ki ustreza času, ko je bil paket

ustvarjen z vzorčenjem njegovega izvornega medijskega toka. Ciljna aplikacija lahko

uporabi ta zaznamek za zagotovitev sinhronega predvajanja ciljnemu uporabniku ter za

izračun zakasnitve in trepetanja.

3.4 H.323

V tradicionalnih telefonskih omrežjih se pred in med klicem izvajajo posebni

signalizacijski protokoli za zahtevo po vzpostavitvi klica, spremljanje napredovanja klica

in za končanje seje. Tudi v sistemih VoIP so potrebni signalizacijski protokoli, ki

opravljajo isto funkcijo. V ta namen je ITU-T razvil priporočilo H.323, ki je bil prvi

uporaben standard v omrežjih VoIP. Danes je že nekoliko zastarel, saj ga je nadomestil SIP

protokol. Prva različica H.323 je bila izdana leta 1996. Bila je razvita za multimedijske

komunikacije prek LAN-ov (Local Area Network – lokalno omrežje). V tej različici še

niso bile implementirane funkcije, potrebne za podporo VoIP v širšem okolju. Zato je ITU-

T leta 1998 izdal različico 2, katera je vsebovala nekaj novih funkcij in kmalu so začeli

H.323 bolj uporabljati. Kasneje so specifikacijo še izpopolnili in prišle so nove različice z

novimi funkcijami. Zadnja različica H.323 (iz leta 2006) nosi številko 6 [14].

3.4.1 Arhitektura H.323

H.323 ni oz. ne specificira enega samega protokola. Je eno tistih priporočil ITU-T, ki

specificirajo neko celotno arhitekturo in metodologijo ter vključujejo več drugih priporočil

(npr. H.225 in H.245). Doseg H.323 je prikazan na sliki 3.2. Arhitektura vsebuje terminale

H.323, prehode, vratarje in enote večtočkovnih krmilnikov (MCU – Multipoint Controller

Unit). Namen H.323 je omogočiti izmenjavo medijskih tokov med končnimi točkami

H.323. Končna točka je terminal, prehod ali MCU.


Slika 3.2: Doseg H.323

Terminal H.323 je končna točka, ki ponuja komunikacijo v realnem času z drugimi

končnimi točkami H.323. Ponavadi je terminal komunikacijska naprava končnega

uporabnika, ki podpira vsaj en avdio kodek, lahko pa še druge avdio ali video kodeke.

Prehod je končna točka H.323, ki ponuja storitve prevajanja med omrežjem H.323 in

drugo vrsto omrežja, na primer PSTN (Public Switched Telephone Network – javno

komutirano telefonsko omrežje) ali ISDN (Integrated Services Digital Network – digitalno

omrežje z integriranimi storitvami). Ena stran prehoda podpira signalizacijo H.323 in

zaključuje paketne medije v skladu z zahtevami H.323, druga stran prehoda pa je vmesnik

proti vodovno preklapljanemu omrežju in podpira prenosne lastnosti in signalizacijske

protokole tega omrežja. Prevajanje med signalizacijskimi protokoli in medijskimi formati

ene in druge strani se izvaja znotraj prehoda in je transparentno za druga vozlišča vodovno

preklapljanega omrežja in omrežja H.323.

Vratar je opcijski element znotraj omrežja H.323. Kadar je prisoten, nadzira terminale

H.323, prehode in MCU-je. Vratar daje dovoljenja za omrežni dostop eni ali več končnim

točkam in lahko dovoli ali zavrne klic od končne točke, ki jo ima pod nadzorom. Vratar

lahko izvaja tudi storitve nadzora pasovne širine in storitve prevajanja naslovov in s tem

omogoča uporabo aliasov v omrežju.


MCU je končna točka H.323, ki upravlja večtočkovne konference med tremi ali več

terminali ali prehodi. Za takšne konference MCU vzpostavi medije, katerih skupno

uporabo lahko omogoči z oddajo nabora zmožnosti različnim udeležencem konference.

MCU lahko v primeru, da se konferenci pridružijo nove končne točke ali da jo nekatere

končne točke zapustijo, nabor zmožnosti spremeni.

3.4.2 Klicni scenarij H.323

Pred pričetkom klicne signalizacije mora končna točka najprej dobiti dovoljenje od

vratarja. Lahko ga dobi z izmenjavo sporočil ARQ/ACF (ali pa ji ga je dal vratar vnaprej

pri registraciji). Sporočilo ARQ (Admission request – zahteva sprejema) vsebuje

zahtevano pasovno širino za celoten medijski tok. Sporočilo ACF (Admission Confirm –

potrditev sprejema) odobri zahtevo (sl. 3.3). Sledi izmenjava sporočil H.245 OLC (Open

Logical Channel – odpri logični kanal), ki so namenjena odprtju logičnega kanala za

vzpostavitev medijskega toka od ene končne točke do druge. Medijski tokovi RTP potujejo

vedno neposredno med končnima točkama. Po končanem prenosu medija stran, ki je

zahtevala odprtje logičnega kanala, pošlje sporočilo H.245 CLC (Close Logical Channel –

zapri logični kanal), ki pomeni zahtevo po zaprtju logičnega kanala. Seja se konča s

sporočilom »End Session« v eni in z enakim odgovorom nanj v drugi smeri. Na koncu

klica mora končna točka obvestiti vratarja, da je klic končan.


Slika 3.3: Scenarij klica H.323

3.5 SIP – protokol za zagon seje

Včasih je SIP protokol predstavljal močno alternativo H.323, danes pa ga je že skoraj

povsem izpodrinil. SIP je prožnejši, preprostejši kot H.323, lažji za implementacijo,

primernejši za pametne uporabniške naprave in za implementacijo naprednih storitev.

SIP so zasnovali kot del arhitekture za multimedijske podatke. Kot tak se SIP uporablja

skupaj z mnogimi drugimi protokoli, kot so SDP (Session Description Protocol – protokol

za opis seje), RTSP (Real-Time Streaming Protocol – protokol strujanja v realnem času) in

SAP (Session Announcement Protocol – protokol za najavo seje).


SIP je signalizacijski protokol, ki skrbi za vzpostavljanje, spreminjanje in sproščanje

multimedijskih sej [2] [15]. SIP se skupaj z drugimi protokoli uporablja za opisovanje

lastnosti seje morebitnim udeležencem seje. Čeprav je SIP napisan tako, da medij,

uporabljen v seji lahko uporablja katerikoli transportni protokol, se mediji običajno

prenašajo z RTP. Zelo verjetno je, da sporočila SIP potujejo skozi nekatere iste fizične

naprave kot prenašani medij. Kljub temu pa SIP obravnavamo ločeno od medijev (sl. 3.4).

Ločitev je pomembna, ker lahko signalizacija potuje skozi enega ali več proksijev ali

preusmeritvenih strežnikov, medijski tokovi pa po neposrednejši poti. Strežnik proksi (tudi

posredovalni strežnik), deluje podobno kot strežnik proksi za spletni dostop. Odjemalci

pošiljajo zahteve proksiju in ta jih obravnava sam ali pa pošlje drugim strežnikom, morda

po izvedbi določenega prevajanja. Tem drugim strežnikom se zdi, kot da je sporočilo prišlo

od proksija in ne od kakšnega osebka, skritega za njim. Ker proksi sprejema zahteve in jih

oddaja, vsebuje funkcionalnost strežnika in odjemalca.

Slika 3.4: Logična ločitev signalizacije SIP in medijev

3.5.1 Arhitektura SIP

SIP definira dva osnovna razreda omrežnih osebkov, to so odjemalci in strežniki.

Odjemalec (UAC – User Agent Client) je aplikacijski program, ki pošilja zahteve SIP.

Strežnik (UAS – User Agent Server) je osebek, ki odgovarja na zahteve. SIP je torej

protokol odjemalec – strežnik. Klici VoIP, ki uporabljajo SIP, se začenjajo pri odjemalcu

in zaključijo pri strežniku. Odjemalec je lahko v uporabnikovi napravi, ki je lahko na

primer PC s slušalkami ali SIP telefon, lahko pa se nahaja tudi na isti platformi kot


strežnik. SIP namreč omogoča uporabo proksi strežnikov, ki so hkrati odjemalci in

strežniki. Slika 3.5 prikazuje delovanje strežnika proksi. Vidimo, da se lahko

funkcionalnost takšnega strežnika uporabi za preusmeritev klica, usmerjanje po dnevnem

času ali sledilne storitve.

Slika 3.5: Delovanje strežnika proksi

3.5.2 Vzpostavljanje klica SIP

Gledano na visokem nivoju, kot prikazuje slika 3.6, je vzpostavljanje klica SIP

preprosto. Proces pošlje sporočilo SIP INVITE, ki se uporablja od kličočega h klicanemu.

To sporočilo povabi klicanega k sodelovanju v seji, torej klicu. Na INVITE se lahko pošlje

več odgovorov, preden klicana stran sprejme sodelovanje v klicu. Kličoči je na primer

lahko informiran, da je klic postavljen v vrsto ali da je klicani opozarjan (da mu zvoni

telefon). Nato klicani odgovori na klic, pri čemer se tvori odgovor OK in ta se pošlje

kličočemu. Kličoči odjemalec potrdi prejem odgovora klicanega z oddajo sporočila ACK.

Uporaba zaporedja INVITE, OK in ACK pomeni, da je za vzpostavljanje klica

uporabljeno tako imenovano »trojno rokovanje«. Nato se izmenjujejo podatki oz. medij.

Medij je običajno govor, lahko pa je tudi video ali kaj drugega. Na koncu ena od strani

odloži pogovorko, kar povzroči, da se pošlje sporočilo BYE. Stran, ki prejme BYE, pošlje

OK, da potrdi njegov prejem. Tako se klic konča.


Slika 3.6: Scenarij vzpostavljanja klica SIP

V osnovi je definiranih šest različnih SIP metod. To so INVITE, ACK, OPTIONS,

BYE, CANCEL in REGISTER. Pregled metod podaja tabela 3.1.

Tabela 3.1: Metode SIP, definirane v osnovni specifikaciji

Metoda Opis

INVITE Zahteva po pričetku seje

ACK Potrditev, da je bil sprejet končni odgovor

BYE Konča sejo

OPTIONS Povpraševanje strežnika po njegovih zmožnostih

CANCEL Končanje obstoječe zahteve

REGISTER Informira strežnik o uporabnikovi trenutni lokaciji


3.5.3 Prednosti SIP-a pred drugimi signalizacijskimi protokoli

Vprašamo se lahko, kaj je tako posebnega pri SIP protokolu, kar ga dela zanimivega.

Vsak protokol mora za klicno signalizacijo imeti način, da ena stran pokliče drugo, za

oznanitev pripravljenosti na sodelovanje v klicu in za njegovo sprostitev. SIP izvaja te

akcije in še malenkost več. Kar pa SIP loči od drugih protokolov in predvsem od

protokolov tradicionalne telefonije je to, da nam ponuja veliko prožnost. SIP-a ne zanima,

katera vrsta medijev se bo izmenjavala med sejo ali vrsta transporta, uporabljenega za te

medije. Dejansko se SIP lahko izvaja prek mnogo različnih transportnih protokolov.

Sporočila SIP lahko vsebujejo veliko opcijskih polj, ki lahko vsebujejo uporabniško

specificirane informacije. Ta pristop omogoča pošiljanje nestandardnih uporabniško

specificiranih informacij, ki omogočajo, da uporabniki in naprave sprejemajo inteligentne

odločitve za ravnanje s klici. Sporočilo INVITE lahko na primer vsebuje polje o predmetu

(»subject«) klica. Oseba, ki sprejme INVITE, se tako lahko na podlagi informacije o

kličočem in predmetu klica odloči, ali bo sprejela ali zavrnila klic.


4 KONCEPT NGN – ELEMENTI OMREŽJA

V tem poglavju bomo predstavili koncept omrežij naslednje generacije (NGN). Na

kratko si bomo ogledali arhitekturo NGN ter opisali ključne entitete NGN okolja.

Koncept omrežij naslednje generacije temelji na nekaterih osnovnih arhitekturnih

načelih, ki predstavljajo odločilno točko razlikovanja med klasičnimi in novimi

telekomunikacijskimi sistemi. Arhitektura NGN je osnovana na logično ločenih ravninah,

ter predstavlja preplet vseh osnovnih in dodatnih funkcionalnosti, ki so poznane že v

klasičnih telekomunikacijskih sistemih. To so funkcionalnost za zagotavljanje krmiljenja,

zagotavljanje storitev, delo z medijem in povezljivost v druga omrežja [6] [7].

Sistem temelji na paketnem transportnem omrežju in novih internetno orientiranih

tehnologijah. Povezljivost med omrežnimi elementi, ravninami in celotnim sistemom proti

zunanjemu okolju je osnovana na standardiziranih vmesnikih. To zagotavlja odprtost in

medsebojno povezljivost različnih operaterjev ter tudi ponudnikov in uporabnikov.

Standardiziranost omogoča tudi bodoče posodobitve in nadgradnje sistema kot celote.

Ključnega pomena pri načrtovanju arhitekture in pripadajočih funkcionalnosti je izrazita

storitvena orientiranost. Namen NGN je vzpostaviti zmogljivo, prilagodljivo in uporabniku

prijazno okolje za razvoj in izvajanje uporabniško zanimivih storitev.

Arhitektura NGN je sestavljena iz treh ravnin: dostopovna in transportna ravnina,

krmilna in signalizacijska ravnina ter storitvena ravnina (sl. 4.1).

Dostopovna in transportna ravnina temelji na paketni hrbtenici. Na tej ravnini se

nahajajo tudi NGN uporabniki, ki preko terminalne opreme z ustrezno protokolno podporo

neposredno dostopajo do krmilne in signalizacijske ravnine (tipični podprti protokoli so

SIP, H.323, MGCP/Megaco). Dostop do krmilne ravnine iz hrbteničnih omrežij je

omogočen preko robnega nadzornika sej (SBC – Session Border Controller), ki skrbi za

zaščito krmilne ravnine in skrbi za pravilno izvajanje sistemske politike.


Slika 4.1: Arhitektura NGN

Na krmilni ravnini se nahajajo funkcionalnosti, ki omogočajo izvedbo celovite

uporabniške in medsistemske komunikacije ter funkcionalnosti usmerjanja, proženja in

zagotavljanja storitev. Najpomembnejši omrežni element na tej ravnini je klicni strežnik.

Klicni strežnik opravlja signalizacijo in usmerjanje, krmili delovanje ostalih omrežnih

elementov, namenjen pa je tudi proženju in izvajanju storitev. Poleg modula za krmiljenje

in signalizacijo so pomembne funkcionalnosti, ki jih klicni strežnik implementira, krmilnik

medijskih prehodov (MGCF – Media Gateway Control Function) in krmilnik prehoda v

druga omrežja (BGCF – Breakout Gateway Control Function) ter lokalna baza podatkov z

uporabniškimi in storitvenimi podatki. Na robovih te ravnine so nameščeni različni tipi

medijskih in dostopovnih prehodov (MGW – Media/Access Gateway), ki predstavljajo

vstopno točko različnim med seboj tehnološko nezdružljivim dostopovnim omrežjem ter

drugim ne-NGN hrbteničnim omrežjem (npr. PSTN/ISDN). Na krmilno ravnino sodijo tudi

signalizacijski prehodi (SGW – Signaling Gateway), ki v sodelovanju z medijskimi

prehodi omogočajo medsistemsko povezljivost omrežja. Tu so tudi medijski strežniki z viri

za delo z medijem.


Aplikacijska ravnina je ostalim ravninam dosegljiva preko klicnega strežnika. Na njej

se nahajajo aplikacijski strežniki, ki predstavljajo funkcionalnosti za gostovanje, izvajanje

ter načrtovanje in razvoj kompleksnejših storitev z dodano vrednostjo. Aplikacijski

strežniki delujejo v tesnem sodelovanju s klicnim strežnikom in prevzemajo tisti del

storitvene logike, ki je za klicni strežnik preobsežen, hkrati pa časovno in zanesljivo

izvajanje le-te ni kritično.

4.1 CS – Klicni strežnik

Klicni strežnik, pogosto imenovan tudi programsko stikalo (»Softswitch«), je osrednja

naprava v telefonskem omrežju, ki povezuje klice iz ene telefonske linije na drugo. V

bistvu je to programska oprema, ki teče na računalniškem sistemu. Včasih je to delo

opravljala strojna oprema s fizičnimi preklopnimi elementi, ki je usmerjala klice. Klicni

strežnik se ponavadi uporablja za nadzor povezav na meji med vodovno preklapljanim in

paketnim omrežjem. Klicni strežnik je ena sama naprava, ki vsebuje preklopno logiko in

preklopni sistem. Med nalogami, ki jih opravlja klicni strežnik, so najpomembnejše

zaračunavanje, usmerjanje klicev, signalizacija in klicne storitve. Poleg teh nalog klicni

strežnik krmili tudi medijske prehode. Nadzoruje lahko več različnih medijskih prehodov

na geografsko razpršenem področju preko TCP/IP povezav. Klicni strežnik poleg

osnovnega krmiljenja klicev lahko opravlja tudi nekatere druge storitve, kot so

preusmeritev klica, čakajoči klic, vrnitev zadnjega klica idr. Za zagotavljanje vseh teh

storitev klicni strežnik pogosto sodeluje tudi z medijskim strežnikom.

V IMS omrežjih je klicni strežnik predstavljen kot kombinacija različnih elementov za

nadzor klicnih sej (CSCF – Call Session Control Function) in krmilnikov medijskih

prehodov MGC.

V čistih SIP okoljih SIP uporablja še proksi strežnike kot pomoč pri usmerjanju zahtev

do uporabnikove trenutne lokacije, avtentikaciji in avtorizaciji uporabnikov storitev.


4.2 AS – Aplikacijski strežnik

Aplikacijski strežnik nudi podobna funkcionalna opravila, kot jih ima tradicionalni

gostujoči računalnik kot odziv na zahtevo terminala ali katere druge komunikacijske

naprave. V modelu odjemalec/strežnik se te storitve nudijo za celotna opravila ali pa le za

posamezne dele opravil. Storitve se zahtevajo s klici oddaljenih procedur (RPC – Remote

Procedure Call) ali podobnimi tehnologijami. Pri določenem opravilu lahko sodeluje več

aplikacijskih strežnikov. Strežniki lahko imajo različne operacijske sisteme in lahko jih

sestavlja različna strojna oprema.

V povezavi z aplikacijskim strežnikom pogosto najdemo tudi Parlay X prehod, ki na

eni strani (proti uporabniku) izpostavlja vmesnik spletnih storitev, na drugi pa vmesnik za

komunikacijo s centralnim vozliščem (klicni strežnik ali TDM centrala, odvisno od

implementacije proizvajalca Parlay X prehoda). Popularna storitev, ki jo lahko

implementiramo s Parlay X in aplikacijskimi strežniki, je klik na izbiranje (»Click-to-

dial«). Gre za storitev, kjer na primer uporabnik v brskalniku na domačem računalniku

klikne na neko telefonsko številko in se klic avtomatsko vzpostavi. Parlay X omogoča še

celo paleto zanimivih storitev. Ena izmed njih je tudi sistem za obveščanje velikega števila

uporabnikov, kar je tema te diplomske naloge.

Podrobno bomo aplikacijski strežnik in Parlay X prehod ter njuno vlogo v omrežjih

naslednje generacije opisali v naslednjih poglavjih.

4.3 Prehodi

Za skupno delovanje omrežij VoIP in vodovno preklapljanih uporabljamo prehode.

Osnovna naloga prehoda je, da naredi, da omrežja različnih vrst drugo drugemu delujejo

kot omrežja iste vrste. Omrežja VoIP morajo sprejemati signalizacijo in medije iz vodovno

preklapljanih omrežij v prvotnem formatu in jih pretvoriti v format, uporabljen v omrežju

IP. Ker lahko signalizacija potuje po poti, zelo različni od poti medijev, uporabljamo dve

vrsti prehodov. Prvi so prehodi za pretvorbo signalizacije (SGW), drugi pa prehodi za

pretvorbo medijev (MGW). Ker obstaja logična ločitev, ni nobenega vzroka, da ne bi bila

ločitev tudi fizična. Fizična ločitev prehodov pa ima tudi nekatere prednosti. Omogoča, da

medijska pretvorba poteka čim bliže izvoru ali cilju prometa v vodovno preklapljanem


omrežju, medtem ko so funkcije ravnanja s klici centralizirane. Prednost je tudi ta, da

lahko majhno število krmilnikov prehodov z bolj osrednjo lego krmili več prehodov, ki se

nahajajo na različnih mestih.

MGW pogosto vsebuje tudi prehod VoiceXML (Voice eXtensible Markup Language –

glasovni razširljivi označevalni jezik) in tako MGW zagotavlja okolje za interpretiranje in

izvajanje skript VoiceXML, ki so lahko shranjena lokalno na MGW-ju ali pa jih dinamično

generira poljubni zunanji aplikacijski strežnik. MGW se lahko povezuje po protokolu IP s

TTS komponentami (Text-To-Speech – sinteza govora iz besedila), ASR (Automatic

Speech Recognition – samodejna razpoznava govora) in aplikacijskim strežnikom.

Vsakega od njih uporablja za določene naloge. TTS strežnik uporablja za sintezo govora iz

besedila, ASR strežnik za samodejno razpoznavanje govora, aplikacijski strežnik pa za

generiranje VoiceXML skript in bazo podatkov. Aplikacijski strežnik MGW-ju posreduje

VoiceXML skripte, ki krmilijo povezovanje MGW-ja s TTS in ASR strežnikom.


5 APLIKACIJSKI STREŽNIK

V tem poglavju bomo razložili pojem aplikacijskega strežnika. Povedali bomo, kaj je

aplikacijski strežnik, kje se uporablja ter kakšne storitve ponuja.

V računalništvu ima strežnik dva pomena:

• program, ki daje na voljo storitve drugim programom,

• računalnik v omrežju, ki daje svoja sredstva (npr. disk) v uporabo drugim

računalnikom.

Na splošno je strežnik programska oprema (strežniški operacijski sistem oz. strežniški

program), ki zagotavlja dostop do storitev drugim računalniškim programom na istem ali

drugem računalniku. Ponavadi je strežnik v računalniškem omrežju »odjemalec/strežnik«

enojen specializiran računalnik (strežniška strojna oprema), ki služi shranjevanju in

upravljanju s podatki in drugimi viri iz ene centralizirane lokacije. Strežnik ima nameščeno

strežniško programsko opremo, ki je izdelana za izvajanje točno določenih nalog in

storitev, kot je strežba zahtevanih podatkov, upravljanje tiskalnikov, gostovanje internetne

povezave in strežba ostalih informacijskih storitev v računalniškem omrežju.

Definicija aplikacijskega strežnika

Izraz aplikacijski strežnik se ne nanaša nujno na posebej specializiran računalnik v

omrežju, ampak je ponavadi kar kos programske opreme, ki znotraj večjega sistema služi

svojemu namenu. Zelo splošno bi lahko rekli, da je vsaka programska oprema, ki s

centralizirane lokacije procesira podatke za večje število porazdeljenih odjemalskih

računalnikov, aplikacijski strežnik. Naloga aplikacijskega strežnika je skrbeti za »poslovno

logiko« znotraj večslojne arhitekture. Poslovna logika preprosto pomeni funkcionalnost, ki

jo programska oprema izvaja nad podatki. Slojevitost arhitekture se najpogosteje nanaša na

tri sloje: odjemalec – aplikacijski strežnik – podatkovna baza (sl. 5.1).


Aplikacijski strežnik je napisan za točno določene naloge, ki jih narekujejo potrebe

posameznika ali organizacije, ki želi koristiti storitve aplikacijskega strežnika. Osnovna

naloga aplikacijskega strežnika je pridobitev, obdelava in predstavitev podatkov

uporabniku preko uporabniškega vmesnika. Strežnik opravlja tudi vrsto drugih opravil, kot

je obdelava najrazličnejših vhodnih podatkov, bodisi razne poizvedbe ali posodobitve,

vključno z validacijo, verifikacijo in varnostnimi pregledi, ki morajo biti izvršeni. Kaj

točno so podatki in procesi, ki jih izvaja aplikacijski strežnik, ni točno določeno. Obdeluje

lahko najrazličnejše vrste podatkov in opravlja različne procese, odvisno od potreb

odjemalca.

Značilen primer aplikacijskega strežnika je internetni iskalnik. V tem primeru so

odjemalci katerikoli računalniki, ki se prijavijo na spletno stran iskalnika ter vpišejo iskane

podatke. Aplikacijski strežnik vzame vhodne podatke, ki jih je podal odjemalec ter požene

nekaj operacij iskanja, ki se nanašajo na sam iskalni algoritem. Nato se izvedejo poizvedbe

v podatkovno bazo spletnih vsebin in na koncu se vrnjeni podatki servirajo nazaj k

odjemalcu.

Drugi pogosti primeri aplikacijskega strežnika:

• spletni sistemi za rezervacije,

• centraliziran nadzor blaga,

• spletno bančništvo,

• spletni slovarji in ostali viri.

Slojevitost arhitekture

Mnogo omrežij še vedno uporablja dvoslojni pristop, v katerem so odjemalci povezani

na osrednji aplikacijski strežnik, vendar pa ima vsak odjemalec nameščeno svojo kopijo

posamezne aplikacije. To pomeni, da se vsi procesi odvijajo na računalnikih odjemalcev in

je povezava s strežnikom namenjena samo izmenjavi podatkov. Trislojna arhitektura,

včasih imenovana tudi n-slojna ali multi-slojna, razbremenjuje odjemalce procesiranja

podatkov, saj se ta naloga prenese na strežnik. Odjemalcu je prepuščeno le prikazovanje

podatkov. V tem modelu arhitekture odjemalca pogosto imenujejo »tanki odjemalec«.


Čeprav so trije sloji ponavadi razdeljeni vsak na svoj ločen računalnik, je še vedno

mogoče, da so vsi trije sloji (vmesnik, aplikacija in podatkovna baza) implementirani na

enem samem računalniku. Slika 5.1 prikazuje značilni model ločene trislojne arhitekture.

Slika 5.1: Aplikacijski strežnik v večslojni arhitekturi

Prednosti in slabosti aplikacijskih strežnikov

Prednosti uporabe aplikacijskih strežnikov v omrežju so številne. S postavitvijo

aplikacije na centralni računalnik ločimo odjemalca od procesiranja in s tem omogočimo

odjemalcem, da dostopajo do aplikacije iz različnih platform. Z drugimi besedami,

katerikoli računalnik, ki poganja brskalnik na kateremkoli operacijskem sistemu

(Windows, Linux, Macintosh idr.), se lahko poveže na spletni aplikacijski strežnik, ne

glede na njegove individualne specifikacije. Centralizacija aplikacij predstavlja prednost

tudi glede vzdrževanja in upravljanja. Računalnik, na katerem teče aplikacijski strežnik, se

z lahkoto vzdržuje in posodablja, ko je to potrebno. Programsko opremo pa je mogoče

načrtovati in razvijati z zanesljivostjo okolja, kar ne bi bilo mogoče, če bi procesiranje

podatkov teklo na množici porazdeljenih računalnikov.


Imajo pa aplikacijski strežniki tudi tri večje pomanjkljivosti. Prva je ta, da če strežnik

slučajno odpove ali pa se iz kakršnih koli razlogov izklopi, odjemalci ne morejo dostopati

do aplikacij. Drugič, odvisnost od omrežnih povezav, vključno z internetom, izpostavlja

ranljivost glede izpada omrežja, ki prav tako onemogoča odjemalcem dostop do aplikacije.

Na koncu je tu še vidik varnosti, saj se med odjemalcem in aplikacijskim strežnikom

velikokrat prenašajo zelo občutljivi podatki, nemalokrat tudi preko javnih omrežij.

Prva dva problema rešujemo s postavitvijo redundančnih elementov in povezav v

omrežju. S tem se izognemo daljšim izpadom, saj nedelujoči strežnik nadomesti drugi,

vendar pa je tako skoraj nemogoče predvideti in poskrbeti za vse možne scenarije. Na

primer večino WAN (Wide Area Network – prostrano omrežje) omrežja nimamo pod

nadzorom in stopnja varovanja pred izpadom je pogojena samo s pomembnostjo aplikacije,

ki teče na aplikacijskem strežniku. Reševanje varnostnih problemov je vedno težavno,

vseeno pa imamo na voljo danes številne metode, kriptiranja in varovane povezave, ki so

uporabne za vse oblike občutljivih spletnih transakcij.

Razvojne platforme

Referenca na področju razvoja aplikacijskih strežnikov je prav gotovo Java EE

platforma, znana tudi kot J2EE. Posledica tega je velika razširjenost programskega jezika

Java kot izbire za aplikacijski strežnik. Tudi Microsoftova ASP.NET platforma je zelo

zmogljiva in precej razširjena. Mnogo razvijalcev še vedno uporablja CGI (Common

Gateway Interface – splošni vmesnik prehoda) in PERL (Practical Extraction and Report

Language – priročni jezik za izvlečke in poročila). Izbira platforme za aplikacijski strežnik

je včasih težavna naloga, saj smo mnogokrat vezani na tehnične omejitve. Naloga

sistemskih analitikov in razvijalcev pa je, da predvidijo potrebe in zmožnosti postavitve

aplikacijskega strežnika.

Parlay X v povezavi z aplikacijskim strežnikom

Parlay/OSA (Open Services Architecture – arhitektura odprtih storitev) je storitvena

arhitektura, razvita za povečanje števila potencialnih telekomunikacijskih storitev in se

običajno zelo prepleta s pojmom aplikacijskega strežnika. S pomočjo Parlay arhitekture


lahko razvijalci ustvarjajo množico novih telefonskih aplikacij brez poglobljenega znanja

telekomunikacij. V upanju, da bi tehnologija dosegla še širši krog razvijalcev, je bil

predstavljen Parlay X kot razširitev Parlay/OSA. Parlay X funkcionalnost omogoča

aplikacijam, ki se nahajajo na internetu, uporabo omrežnih zmogljivosti iz

telekomunikacijskih omrežij preko tako imenovanih spletnih storitev (»web service«).

Aplikacija, ki se nahaja na internetu, lahko uporablja omrežne zmogljivosti preko

aplikacijskega strežnika, ki Parlay X gradnike pretvarja v primerne za komunikacijo z

omrežjem. Aplikacijski strežnik je povezan s Parlay/OSA okoljem in na ta način s stališča

aplikacije igra vlogo prehoda med aplikacijo in omrežjem. AS je porazdeljen sistem, ki

opravlja preslikave med Parlay X ukazi in Parlay/OSA ukazi. Porazdeljenost AS pomeni,

da vsebuje različna obdelovalna vozlišča, ki so lahko vključena med zahtevami storitev.

Slika 5.2 prikazuje arhitekturo AS in Parlay/OSA okolja.

Slika 5.2: Arhitektura AS in Parlay/OSA okolja

Storitvena arhitektura je lahko uporabljena v kateremkoli telekomunikacijskem

omrežju in ni določeno, v katerem omrežju morajo biti uporabniki, da lahko uporabljajo to

arhitekturo. Ena izmed najbolj obetajočih topologij predvideva končnega uporabnika

aplikacije, priključenega na internet. Parlay/OSA arhitektura povezana na internet se

pogosto nanaša na Parlay X arhitekturo, kjer so omrežni viri abstraktni in jih imenujemo

Parlay X spletne storitve.


6 TEHNOLOGIJE, UPORABLJENE PRI RAZVOJU SISTEMA

V tem poglavju bomo predstavili vse programske jezike in tehnologije, s katerimi smo

se srečali pri izdelavi sistema za obveščanje velikega števila uporabnikov. Nekaj od teh

tehnologij se nanaša na aplikacijski strežnik (poglavje 5), katerega smo tudi uporabili pri

razvoju sistema. Na aplikacijskem strežniku kot osrednjem in bistvenem elementu omrežja

se lahko uporablja veliko različnih tehnologij, vendar pa bomo mi predstavili le tiste

najpomembnejše, ki smo jih uporabili. Med njimi je prav gotovo najpomembnejši Parlay

X.

6.1 Programski jezik Java

Java je objektno orientiran, prenosljiv programski jezik, ki ga je razvil James Gosling s

sodelavci v podjetju Sun Microsystems [16]. Projekt, ki se je v začetku (leta 1991)

imenoval Oak (hrast), je bil razvit kot zamenjava za C++. Jave ne smemo zamenjevati z

jezikom JavaScript, ki ima podobno ime ter podobno, C-jevsko sintakso. Različica Java 1.0

je bila objavljena leta 1996, zadnja različica je 6 Update 10 (oktober 2008). Javo vzdržuje

in posodablja Sun Microsystems.

Tolmač za Javo je vgrajen v večino spletnih brskalnikov, s tem se javanski programčki

(»applet«) lahko izvajajo kot del HTML (HyperText Markup Language – jezik za

označevanje hiperteksta) dokumenta. Zanimivo, da so danes javanski programčki s spletnih

strani skoraj povsem izginili. Vendar pa je Javina prilagodljivost omogočila pohod na

številna druga področja, med drugim tudi na novo, povsod prisotno tehnologijo – na

področje prenosnih naprav, kot so mobilni telefoni in dlančniki. Na drugi strani pa Java

danes prevladuje kot podlaga za razvoj porazdeljenih poslovnih programov in kot

najpogostejši programski jezik, s katerim se prvič srečajo študenti računalništva po vsem

svetu.


Java je torej podlaga, ki jo sestavlja več pomembnih členov:

• programski jezik,

• programske knjižnice,

• izvajalno okolje.

Programski jezik Java je olajšal razvoj, bogata knjižnica pa je poskrbela za cel kup

sestavin sodobnih programov. Prava revolucija pa je bil način, kako se ta koda izvaja. Pred

uveljavitvijo Jave je bila učinkovitost izvajanja pomembnejša od udobja programerjev.

Uveljavljeni programski jeziki se zato prevajajo v strojno kodo, ki omogoča najhitrejše

izvajanje, vendar je takšna koda lahko izjemno nevarna, če ni popolna.

Java je nastala v želji izdelave programskega jezika za potrošniško elektroniko.

Naprave, ki naj bi jih krmilila Java, nimajo velikih zmogljivosti in so si medsebojno precej

različne, zato je bil cilj razvoja preprost jezik, ki izdela strnjeno kodo, sposobno izvajanja v

različnih napravah. Tvorci Jave so se ozrli na raziskave navideznih strojev in ta koncept

uspešno uporabili. Programska koda v Javi se zato ne prevaja v strojno, temveč v vmesno

kodo (»bytecode«). Ta koda se na običajnih procesorjih ne more izvajati, ker potrebuje

tolmača (»interpreter«). Vendar se program v vmesni kodi lahko izvaja na poljubni

napravi, za katero obstaja ustrezen tolmač. S tem je osnovni pogoj za obljubo »napiši

enkrat, poganjaj povsod« izpolnjen. Javino izvajalno okolje, poimenovano tudi Javanski

navidezni stroj (JVM – Java Virtual Machine), je postalo mnogo več kot tolmač vmesne

kode, ki omogoča programom, da se izvajajo na različnih strojnih podlagah. JVM ponuja

nadzorovano izvajalno okolje, ki skrbi za nekatere temeljne storitve (npr. samodejno

sproščanje pomnilnika), hkrati pa ponuja visoko stopnjo varnosti [3]. Številne prednosti

nadzorovanega okolja imajo seveda svojo ceno. Težko bi pričakovali, da se vmesna koda,

ki jo je treba tolmačiti, hkrati pa se kar naprej preverja zaradi varnosti, izvaja pri hitrosti,

primerljivi s strojno kodo, ki neovirano teče neposredno v procesorju. Vendar so tudi te

negativne posledice ublažili v novejših različicah Jave. Javanska zrna (»Java Beans«) so

majhne, ponovno uporabljive komponente, ki se uporabljajo za gradnjo večjih javanskih

programov. Javanske strežniške strani (JSP – Java Server Pages) in javanski strežniški

programčki (»servlets«) se na strežniški strani uporabljajo za dinamično generiranje


spletnih strani. Slika 6.1 prikazuje preprost programček, napisan v programskem jeziku

Java. Na začetku je definiran razred »Pozdravljen svet«, ki ima isto ime, kot je ime

datoteke, v kateri je shranjen program, torej »PozdravljenSvet.java«. Znotraj glavne

metode »main« kličemo še metodo »System.out.println«, ki izpiše na zaslon sporočilo

»Pozdravljen Svet!«.

Slika 6.1: Preprost programček, napisan v Javi

6.2 Programski jezik SQL

SQL (Structured Query Language – strukturirani jezik za poizvedovanje) je

računalniški jezik namenjen za delo s podatkovnimi bazami. Oblikovan je za upravljanje

podatkov v sistemih relacijskih podatkovnih baz (RDBMS – Relational Database

Management System). SQL je standardiziran interaktivni programski jezik, namenjen za

iskanje, spreminjanje in upravljanje podatkov v podatkovnih bazah ter je ISO

(International Organization for Standardization – Mednarodna organizacija za

standardizacijo) in ANSI (American National Standards Institute – Ameriški nacionalni

inštitut za standardizacijo) standard.

Jedro jezika SQL predstavlja zmožnost iskanja, vstavljanja, posodabljanja in brisanja

podatkov ter upravljavske in administrativne funkcije. SQL prav tako vključuje CLI (Call

Level Interface – vmesnik klicnega nivoja), ki omogoča dostop in upravljanje z bazo tudi

na daljavo.

Prva različica SQL je bila razvita v podjetju IBM v začetku leta 1970. Ta različica, ki je

bila sprva imenovana SEQUEL, je bila zasnovana za manipulacijo podatkov shranjenih v

IBM-ovi relacijski podatkovni bazi. IBM je patentiral njihovo različico SQL leta 1985,


medtem ko jezik SQL ni bil formalno standardiziran do leta 1986, ko ga je standardiziral

ANSI. Kasnejše verzije SQL standarda so bile izdane kot ISO standard.

Slika 6.2 prikazuje poizvedbo z rezervirano besedo SELECT, ki vrne seznam dragih

knjig. Poizvedba pridobi vse vrstice iz tabele z imenom »Knjige«, pri katerih je vrednost v

stolpcu z imenom »cena« večja kot 10.000. Rezultat je sortiran po naslovih v naraščajočem

vrstnem redu.

Slika 6.2: Primer poizvedbe z jezikom SQL

6.3 Podatkovna baza MySQL

Podatkovna baza je sklop zbirke dokumentov, medsebojnih sklicevanj na dokumente in

sistema za razvrščanje, iskanje in urejanje podatkov v bazi. Podatkovna baza je torej tudi

klasična knjižnica, a v vsakdanjem pogovoru baza pomeni računalniški sistem za hrambo

podatkov. Podatkovne baze so se pojavile zaradi potrebe po hitrem dostopu do informacij,

saj hramba podatkov iz preteklosti omogoča premišljeno odločanje o prihodnosti.

Za našo aplikacijo smo uporabili podatkovno bazo MySQL (My Structured Query

Language), zato jo bomo tudi bolj podrobno predstavili.

MySQL je sistem za upravljanje s podatkovnimi bazami. Je odprtokodna

implementacija relacijske podatkovne baze, ki za delo s podatki uporablja jezik SQL.

MySQL deluje na principu odjemalec – strežnik, pri čemer lahko strežnik namestimo kot

sistem, porazdeljen na več strežnikov. Obstaja veliko število odjemalcev, zbirk ukazov in

programskih vmesnikov za dostop do podatkovne baze MySQL.

Vse skupaj se je začelo z namenom uporabe mSQL, ki bi ga priključili tabelam z

uporabo hitrih rutin nizke stopnje. Po nekaj preizkusih so ugotovili, da mSQL ni dovolj

hiter in fleksibilen za potrebe zahtevnih uporabnikov. Po tem so razvili nov SQL vmesnik


za bazo podatkov, ampak s skoraj enakim programskim vmesnikom kot mSQL. Ta je bil

zasnovan tako, da dovoljuje tretji kodi, ki je bila napisana za uporabo z mSQL, da se lahko

prenese za uporabo z MySQL.

Lastnosti MySQL:

• Napisana je v jezikih C in C++.

• Deluje na več različnih operacijskih sistemih (Windows, Linux …).

• Za prenosljivost med OS uporablja GNU Automake, Autoconf in Tcl.

• Obstajajo programski vmesniki za C, C++, Eiffel, Java, Perl, PHP, Python …

• Bistvene programske niti mreže so večopravilne. Zna izkoristiti toliko

centralnih procesnih enot, kolikor jih je na voljo.

• Uporablja zelo hitre diskovne tabele MyISAM, s stiskanjem indeksov.

6.4 Programski jezik VoiceXML

Večina ljudi pozna avtomatske telefonske storitve, ki ponujajo uporabnikom različne

informacije, kot so urniki letov, bančni tečaji, spored filmov v kinu ipd. Skokovito širjenje

interneta in z njim povezanih tehnologij je omogočilo ponudnikom tradicionalnih

telefonskih storitev razvoj povsem novih storitev, ki uporabljajo omrežne tehnologije za

posredovanje informacij uporabnikom. Čeprav v večini primerov uporabniki še zmeraj

uporabljajo telefon za dostop do avtomatskih glasovnih storitev, pa ponudniki storitev

vedno bolj spoznavajo prednosti pri razvoju novih storitev, ki izkoriščajo prednosti in moč

internetnih in omrežnih tehnologij.

VoiceXML ponuja najboljše rešitve iz obeh svetov. Ponudniki storitev lahko preko

spletnih servisov ponudijo nove spletne storitve, ki so zasnovane na označevalnih jezikih,

kot je VoiceXML, uporabniki pa do njih dostopajo kar preko telefona. Razvijalci lahko

hitro razvijejo avtomatsko glasovno storitev na podoben način in z uporabo podobnih

tehnologij kot pri izdelovanju spletnih strani, s tem pa je mogoče občutno zmanjšati stroške

razvijanja aplikacije in storitev približati uporabnikom tradicionalnih telefonov.

VoiceXML ima svoje korenine v raziskovalnem projektu, imenovanem PhoneWeb, ki

so ga razvijali v laboratorijih AT&T. Kasneje so se projektu pridružili še IBM, Motorola in


Lucent, kar je privedlo do ustanovitve VoiceXML Foruma leta 1999. Forum je danes

globalna industrijska organizacija, ki promovira in pospešuje razvoj VoiceXML aplikacij

po vsem svetu.

VoiceXML je označevalni jezik, ki se uporablja za realizacijo govornih odzivnikov.

Razvit je bil z namenom, da s tehnologijama sintetiziranja in prepoznavanja govora

omogoči interakcijo med uporabnikom in internetom [11]. Preko vmesnikov, zgrajenih s

tehnologijo VoiceXML, uporabnik komunicira z glasovnim brskalnikom na tak način, da

posluša glasovna sporočila, katera so lahko vnaprej posneta ali pa jih v realnem času

pripravlja sistem za sintezo govora (TTS). Vhodne podatke lahko uporabnik podaja preko

tipkovnice (DTMF – Dual-tone Multi-Frequency, dvotonska večfrekvenčna signalizacija)

ali v govorni obliki, ki jo obdela sistem za avtomatsko prepoznavo govora (ASR).

Izven obsega jezika VoiceXML so aplikacijska logika, upravljanje stanj, generiranje

dialoga ter operacije nad podatkovno bazo. Te komponente so rešene na aplikacijskih

strežnikih z običajnimi tehnikami programiranja spletnih aplikacij.

V arhitekturi VoiceXML (sl. 6.3) nastopajo:

• Aplikacijski strežnik, ki je tipično spletni strežnik, na katerem teče

aplikacijska logika. Ta lahko vsebuje podatkovno bazo ali vmesnike do zunanje

podatkovne baze.

• Medijski prehod, na katerem teče VoiceXML interpreter in deluje kot

odjemalec aplikacijskega strežnika. Interpreter razume VoiceXML dialoge in

nadzoruje govorne in telefonske vire: ASR, TTS, avdio predvajanje in snemanje

ter vmesnik telefonskega omrežja.

• Omrežje, ki temelji na protokolu TCP/IP in povezuje aplikacijski strežnik in

medijski prehod preko HTTP.

• Telefonsko omrežje: PSTN/ISDN, privatno telefonsko omrežje ali omrežje

internetne telefonije.

• Kličoči uporabnik, ki je lahko katerikoli terminal, ki se lahko povezuje s

telefonskim omrežjem.


Slika 6.3: Arhitektura VoiceXML

V govornih storitvah ima VoiceXML podobno vlogo kot jezik HTML na svetovnem

spletu. To pomeni, da omogoča oblikovanje govornih »spletnih strani« oz. scenarijev

VoiceXML za izdelavo govornih storitev. Uporabnik z govorno aplikacijo komunicira

preko tipkovnice ali v govorni obliki ter posluša vnaprej posneta ali v realnem času

tvorjena sporočila. Govorna aplikacija omogoča tudi snemanje uporabnikovega govora in

preusmeritev uporabnika na poljubno telefonsko številko.

Govorne storitve VoiceXML temeljijo na scenarijih VoiceXML, ki med uporabnikom

in storitvijo definirajo dialog. Eno govorno storitev običajno tvori več scenarijev

VoiceXML. Ti so lahko zelo preprosti in predvidevajo samo predvajanje vnaprej posnetih

kratkih sporočil, lahko pa so tudi zelo kompleksni in omogočajo prepoznavo tonov DTMF,

pošiljanje podatkov na strežnik, prepoznavo in sintezo govora ipd. Za izvedbo

kompleksnejših govornih storitev se na spletnem strežniku pogosto uporabljajo strežniške

skripte in programi. Z uporabo ASR uporabnik ni več omejen le na pritiskanje tipk na

tipkovnici terminala, temveč lahko s sistemom vzpostavi dialog, ki je veliko bolj podoben

človeškemu pogovoru. Izvajanje govorne storitve se prične, ko uporabnik pokliče

telefonsko številko, na kateri je nastavljena storitev VoiceXML. Telekomunikacijsko

vozlišče preusmeri klic na strežnik VoiceXML, ki uporabi ustrezen scenarij, ga interpretira

ter izvede predpisano storitev (npr. predvaja zvočni posnetek). Glede na uporabnikov ukaz

lahko strežnik VoiceXML izvede drug scenarij, ki z uporabnikom prične nov dialog.


6.5 Parlay X

Parlay X je poenostavljena in visoko abstraktna različica Parlay-a, standardiziranega

vmesnika za dostop do funkcionalnosti telekomunikacijskih omrežij. Parlay X predstavlja

skupek aplikacijskih programskih vmesnikov (API – Application Programming Interface),

definiranih s strani ETSI (European Telecommunications Standards Institute – Evropski

inštitut za telekomunikacije), Parlay Group in 3GPP (3rd Generation Partnership Project –

Partnerski projekt tretje generacije), ki razvijalcem aplikacij ponujajo funkcionalnosti

spletnih storitev. S pomočjo Parlay X naj bi bilo po podatkih 3GPP možno izvesti 80%

vseh najaktualnejših storitev za omrežja naslednje generacije. Parlay X storitve so

abstraktne storitve osnovnih komunikacijskih zmožnosti, ki so na voljo razvijalcem preko

XML podatkovnih shem in WSDL (Web Services Description Language – jezik za opis

spletnih storitev) opisov. Razvijalec lahko uporabi WSDL za generiranje primerne

komunikacijske odjemalske kode za uporabo znotraj aplikacij. Parlay X storitev je lahko

ponujena neposredno od aplikacijskega strežnika, ki uporablja WSDL, podobno kot so

druge »internetne« zmožnosti ponujene znotraj arhitekture spletnih storitev. Tako ponujene

storitve omogočajo razvijalcu uporabo orodij za avtomatsko generiranje primernih

odjemalcev iz WSDL dokumenta, katerega dobi od aplikacijskega strežnika [10].

Za razvijalca je pomembno le to, da razume XML shemo, ki ponuja zahtevane

definicije podatkov, povezane z implementiranimi metodami znotraj Parlay X storitve. Te

definicije podatkov prispejo z WSDL dokumentom kot XML shema. Razvijalec ne

potrebuje poglobljenega znanja telekomunikacij, saj je Parlay X neodvisen od katerekoli

implementacije na tem nivoju. Razvijalec prav tako ne potrebuje poznavanja kakšnega

novega kompleksnega programskega jezika ali razvojnega okolja, saj lahko piše kodo v

poznanem Java ali .NET okolju ter uporablja orodja iz teh okolij. Izpostavitev

telekomunikacijskih funkcionalnosti kot storitev znotraj arhitekture spletnih storitev je

nedvomno velik korak naprej od kompleksnih in pogosto visoko specializiranih lastniških

vmesnikov, katere je razumela le peščica specializiranih strokovnjakov na področju

telekomunikacij.


Arhitektura Parlay X

Slika 6.4 prikazuje možne komponente, ki lahko sodelujejo v sestavi Parlay X

arhitekture. Storitve, ki pripadajo telekomunikacijski domeni (1), so izpostavljene preko

Parlay X storitvenega vmesnika. Ta storitveni vmesnik je abstrakten (manj kompleksnosti)

v primerjavi z nižje-nivojskimi telekomunikacijskimi funkcionalnostmi. Storitve so

registrirane ali objavljene kot spletne storitve (2). Navzven se kažejo z uporabo WSDL

opisa. Koda aplikacije dostopa do storitve preko registra spletnih storitev (3). Register je

opcijski element, saj lahko njegovo funkcionalnost prevzameta aplikacijski strežnik ali

prehod. Programskega odjemalca, uporabljenega v aplikaciji, ustvari razvijalec iz opisa

WSDL datoteke. Aplikacija nato komunicira s telekomunikacijsko domeno (4). Interakcija

med aplikacijo in telekomunikacijsko domeno poteka z izmenjavo XML sporočil preko

SOAP (Simple Object Access Protocol – protokol za izmenjavo XML sporočil preko

omrežja) protokola.

Slika 6.4: Arhitektura Parlay X


Z uporabo arhitekture spletnih storitev Parlay X omogoča razvijalcem aplikacij, da

enostavno vključijo v svoje aplikacije funkcionalnosti, kot so telekomunikacijski klic,

pošiljanje sporočil in ostale. Aplikacije lahko dostopajo do virov v javnem omrežju, kjer so

Parlay X storitve objavljene in izpostavljene.

Parlay X je lahko implementiran na Parlay ali drugem storitvenem prehodu, ki se v

omrežju nahaja med aplikacijskimi strežniki ter omrežnimi elementi. Ob dogodkih v

omrežju ali na strani aplikacijskega strežnika se med Parlay X prehodom in aplikacijskim

strežnikom pošiljajo HTTP zahteve, ki vsebujejo XML vsebino. Zahteve predstavljajo klic

metode določene spletne storitve, XML pa vsebuje parametre, potrebne za izvajanje

storitve. Trenutne izvedbe Parlay X so omejene na Parlay prehode. Uvajanje Parlay

prehodov v omrežja je zahtevno, dodaten faktor pa predstavlja cena. Dejstvo, da je Parlay

X predviden kot eden ključnih v arhitekturi IMS, bo nedvomno vplivalo na nove

implementacije, tudi takšne, ki ne bodo temeljile zgolj na Parlay X.

Parlay X specifikacije

Parlay X aplikacijski programski vmesniki so objavljeni kot skupek specifikacij.

Tabela 6.1: Seznam Parlay X 3.0 specifikacij

Parlay X 3.0 specifikacija Funkcionalnost

Part 1: Common definira skupne zmožnosti, kot so podatkovne definicije in WSDL opisi vmesnikov

Part 2: Third Party Call vzpostavljanje in kontrola klicev s strani aplikacije

Part 3: Call Notification obveščanje aplikacij o klicih

Part 4: Short Messaging pošiljanje in prejemanje sporočil SMS

Part 5: Multimedia Messaging pošiljanje in prejemanje sporočil MMS

Part 6: Payment zaračunavanje storitev in predplačna funkcionalnost

Part 7: Account Management upravljanje z uporabniškim računom

Part 8: Terminal Status status terminala (npr. dosegljiv, zaseden …)

Part 9: Terminal Location pridobivanje informacij o lokaciji terminala

Part 10: Call Handling upravljanje z uporabniškimi nastavitvami (npr. bele/črne liste klicev, preusmeritve)


Part 11: Audio Call izvajanje avdio klicev na osnovi teksta, zvočnih datotek ali VoiceXML ter vplivanje na njihov potek

Part 12: Multimedia Conference upravljanje multimedijskih konferenc

Part 13: Address List Management upravljanje s skupinami naročnikov

Part 14: Presence pridobitev informacije o prisotnosti registriranih uporabnikov

Part 15: Message Broadcast pošiljanje sporočil vsem terminalom na določenem geografskem področju

Part 16: Geocoding pridobivanje informacij o lokaciji naročnikov (npr. država, mesto, ulica …)

Part 17: Application-driven quality of Service (QoS)

dinamično spreminjanje kvalitete storitve (npr. pasovne širine)

Part 18: Device Capabilities and Configuration pridobivanje informacij o zmožnostih naprave

Part 19: Multimedia Streaming Control nadzor pretoka multimedijskih vsebin do naročnika

Part 20: Multimedia Multicast Session Management nadzor sej pri oddajanju več različnim prejemnikom

Third Party Call

Spletna storitev Third Party Call omogoča vzpostavljanje in kontrolo klicev s strani

aplikacije. Namen te spletne storitve je ponuditi razvijalcem aplikacij preproste funkcije za

vzpostavljanje klica. S pomočjo te storitve lahko razvijalci uporabljajo funkcije za

obravnavanje klica brez poglobljenega znanja telekomunikacij.

Slika 6.5 prikazuje scenarij uporabe spletne storitve Third Party Call. V tem scenariju

aplikacija najprej z metodo makeCall da poziv za vzpostavitev zveze med UporabnikomA

in UporabnikomB. Nato spletna storitev Third Party Call preko Parlay/OSA SCS-CC (Call

Control – nadzor klica) vmesnika kliče Parlay API metodo. SCS obravnava poziv in pošlje

sporočilo proti MSC (Mobile Switching Center – mobilni komutacijski center) za

vzpostavitev klica med uporabnikoma A in B. Najprej začne zvoniti telefon pri

UporabnikuA. Ko se javi, začne zvoniti še telefon UporabnikaB in ko se javi, se vzpostavi

zveza med njima.


Slika 6.5: Third Party Call scenarij

Definicija vmesnika spletne storitve in podatkovni tipi

• Metoda: makeCall

Klic metode makeCall zahteva vzpostavitev glasovnega klica med dvema

naslovoma, callingParty in calledParty. Opcijsko lahko aplikacija zazna tudi

informacijo o stroških (»charging«). S klicem te metode lahko aplikacija spremlja

status zahtevanega klica. Metoda vrača parameter callIdentifier, ki je uporabljen za

identificiranje posameznega klica. Za pridobitev informacije o statusu klica mora

aplikacija klicati metodo getCallInformation.

• Metoda: getCallInformation

Metoda getCallInformation poizve o trenutnem statusu klica, ki ga identificira na

podlagi parametra CallIdentifier. Metodo lahko kličemo večkrat, tudi če se je klic

že končal.


• Metoda: endCall

Klic metode endCall zahteva parameter callIdentifier in zaključi klic, ki ga

identificira na podlagi identifikatorja klica. Če je klic še vedno v fazi

vzpostavljanja, ima metoda enak učinek kot metoda cancelCall.

• Metoda: cancelCall

Klic metode cancelCall prekine predhodno zahtevo po klicu, identificirano na

podlagi parametra callIdentifier. Ta metoda se razlikuje od metode endCall po

tem, da poskusi prekiniti vzpostavitev klica, vendar pa nima učinka, če je klic že

vzpostavljen.

• CallStatus

Tabela 6.2: CallStatus

Vrednost Opis

CallInitial Klic je bil vzpostavljen.

CallConnected Aktiven klic.

CallTerminated Klic je bil prekinjen.

• CallTerminationCause

Tabela 6.3: CallTerminationCause

Vrednost Opis

CallingPartyNoAnswer Kličoča stran ni odgovorila.

CalledPartyNoAnswer Klicana stran ni odgovorila.

CallingPartyBusy Kličoča stran zasedena.

CalledPartyBusy Klicana stran zasedena.

CallingPartyNotReachable Kličoča stran nedosegljiva.

CalledPartyNotReachable Klicana stran nedosegljiva.

CallHangUp Klic je bil končan s prekinitvijo ene od strani.

CallAborted Klic je bil prekinjen (katerikoli drugi vzrok).


• CallInformation struktura

Tabela 6.4: Struktura CallInformation

Vrednost Opis

callStatus Označuje trenutni status klica.

startTime Označuje čas začetka klica (ko je izpolnjen pogoj callStatus <> CallInitial).

duration Označuje trajanje klica izraženo v sekundah (ko je izpolnjen pogoj callStatus = = CallTerminated).

termiantionCause Označuje vzrok prekinitve klica (ko je izpolnjen pogoj callStatus = = CallTerminated).

6.6 Razvojno okolje Netbeans

Netbeans se nanaša na platformo za razvoj javanskih aplikacij in tudi na integrirano

razvojno okolje (IDE – Integrated Development Environment), razvito z uporabo Netbeans

platforme. Netbeans platforma omogoča, da so aplikacije razvite iz vrste modularnih

programskih komponent, ki se imenujejo moduli. Modul je javanska arhivska datoteka

(JAR – Java ARchive), ki vsebuje javanske razrede, napisane za interakcijo z aplikacijskim

programskim vmesnikom in datoteko z imenom manifest, ki ga označuje za modul.

Aplikacije, ki so zgrajene iz modulov, se lahko kadarkoli razširi z novimi moduli. Ker so

lahko moduli razviti povsem neodvisno, lahko aplikacije, ki temeljijo na Netbeans

platformi, dopolnjuje in dalje razvija tudi tretji, neodvisni razvijalec.

Začetki razvojnega okolja Netbeans segajo v leto 1997, ko je bil to eden izmed

študentskih projektov v okviru Fakultete za matematiko in fiziko na Univerzi v Pragi.

Roman Stanek je kasneje na osnovi projekta ustanovil podjetje, ki je izdelovalo

komercialno verzijo Netbeans IDE, dokler podjetje ni bilo odkupljeno od podjetja Sun

Microsystems leta 1999. Sun je Netbeans IDE objavil kot odprtokodni produkt junija leta

1999. Od takrat je Netbeans skupnost neprestano rasla, zahvaljujoč posameznikom in

podjetjem, ki so Netbeans uporabljali in pomagali razvijati. Slika 6.6 prikazuje Netbeans

IDE.


Slika 6.6: Netbeans IDE

Netbeans IDE je odprtokodno integrirano razvojno okolje, v celoti napisano v

programskem jeziku Java, z uporabo Netbeans platforme. Netbeans podpira razvoj vseh

vrst Java aplikacij (J2SE, web, EJB, mobilne aplikacije …). Vse funkcije IDE-ja so

ponujene z moduli. Vsak modul ponuja dobro opredeljene funkcije, kot je na primer

podpora za programski jezik Java. Netbeans vsebuje vse module, potrebne za razvoj Java

aplikacij, in s tem omogoča uporabniku, da začne delati takoj, ko si naloži okolje Netbeans.

Moduli tudi omogočajo razširitev okolja Netbeans. Nove funkcije, kot je podpora za druge

programske jezike, je mogoče dodati z namestitvijo dodatnih modulov.


7 SISTEM ZA OBVEŠČANJE VELIKEGA ŠTEVILA

UPORABNIKOV TELEKOMUNIKACIJSKIH OMREŽIJ

V tem poglavju bomo predstavili razvoj sistema za obveščanje velikega števila

uporabnikov telekomunikacijskih omrežij. Naša naloga je bila izdelati celovit sistem,

katerega primarna naloga bi bila avtomatsko, preko telefonskega klica in glasovnega

odzivnika, obveščati večje število uporabnikov telekomunikacijskih omrežij. Prvotna ideja

je bila izdelava sistema za obveščanje neplačnikov telefonskih storitev. Temu namenu je

prirejen tudi naš sistem, vendar pa ga je mogoče z manjšimi popravki spremeniti v sistem

za obveščanje katerekoli vrste uporabnikov telekomunikacijskih omrežij. Namen sistema je

s pomočjo tehnologij, ki jih ponujajo omrežja naslednje generacije, vpeljati storitev z

dodano vrednostjo, ki bi dopolnjevala ali povsem nadomestila klasične načine obveščanja

uporabnikov telekomunikacijskih omrežij, kot jih poznamo danes. S tem bi bilo mogoče

zmanjšati stroške, ki nastanejo ob pošiljanju sporočil preko navadne pošte, na primer

opominov v primeru neplačnikov oz. stroške dela operaterjev, ki opravljajo klice v klicnem

centru. Sistem bi bil uporaben tudi v številnih drugih primerih, na primer ob naravnih

nesrečah, kjer bi lahko v zelo kratkem času obvestili veliko število ljudi o dogajanju in s

tem preprečili poslabšanje situacije. Z malo domišljije bi sistem lahko uporabili tudi v

oglaševalske namene itd.

7.1 Predstavitev okolja

Sistem za obveščanje velikega števila uporabnikov telekomunikacijskih omrežij je

potrebno integrirati v okolje, kjer bo le-ta deloval. Naš sistem smo razvijali in testirali v

testnem telekomunikacijskem omrežju Fakultete za elektrotehniko, računalništvo in

informatiko v Mariboru (sl. 7.1). Jedro testnega omrežja je večstoritveno krmilno vozlišče

SI3000 – MSCN, produkt podjetja Iskratel. Vozlišče sestavljajo tri ključne komponente

omrežij naslednje generacije, aplikacijski strežnik, klicni strežnik ter signalizacijski in


medijski prehod. Znotraj signalizacijskega in medijskega prehoda je integriran VoiceXML

interpreter, nanj pa sta povezana še ASR strežnik in VoiceXML strežnik, ki interpreterju

dostavlja VoiceXML skripte. Na aplikacijskem strežniku, ki je povezan s klicnim

strežnikom, se nahaja vmesnik Parlay X, ki preko spletnih storitev omogoča sistemu

uporabo in izvajanje funkcionalnosti telekomunikacijskih omrežij (izvajanje klicev).

Celoten sistem za obveščanje, vključno s podatkovno bazo, se nahaja na PC-ju, ki se preko

protokola HTTP povezuje z aplikacijskim strežnikom in preko protokola H.323 s klicnim

strežnikom.

Slika 7.1: Okolje sistema za obveščanje

Za testiranje klicev smo uporabili tako imenovani »softphone« oz. programsko opremo,

ki se lahko namesti na poljuben PC, kjer opravlja funkcije telefona. Za takšno rešitev smo

se odločili, ker je preprosta in poceni, hkrati pa nismo imeli v testnem prostoru nameščenih

dovolj IP telefonov. Uporabili smo Iskratelovo programsko opremo SoftPhone (sl. 7.2), ki


podpira H.323 protokol, tega pa uporablja tudi klicni strežnik za izvajanje klicev.

SoftPhone je nameščen na PC-ju, na katerem je sistem za obveščanje.

Slika 7.2: SoftPhone

7.2 Izbira tehnologij

Prve korake pri razvoju sistema smo začeli z izbiro programskega jezika in razvojnega

okolja. Ugotovili smo, da bi bil najprimernejši programski jezik Java, tako s stališča

uporabe različnih spletnih storitev kot tudi prenosljivosti programske kode. Pri izbiri

razvojnega okolja je bilo več težav, saj je na voljo veliko število dobrih in brezplačnih

razvojnih okolij. Odločili smo se, da bomo programsko kodo pisali in testirali v razvojnem

okolju Netbeans, ki je po našem mnenju eno izmed boljših in uporabniku prijaznih okolij,

predvsem kar se tiče podpore za programski jezik Java. Kot spletni strežnik smo uporabili

strežnik Tomcat, ki je med drugim integriran tudi v razvojno okolje Netbeans. Na tem

strežniku se tako izvajajo skripte JSP grafičnega vmesnika. Za shranjevanje podatkov smo

uporabili relacijsko podatkovno bazo MySQL, ki zadostuje vsem potrebam sistema, prav

tako pa je upravljanje z njo relativno enostavno. Za izvajanje klicev smo uporabili vmesnik

Parlay X, ki teče na aplikacijskem strežniku. Za predvajanje glasovnih sporočil pa skrbi

VoiceXML interpreter (integriran v medijskem prehodu) v povezavi z VoiceXML

strežnikom.


7.3 Arhitektura in zasnova sistema

Arhitekturno gledano je sistem sestavljen iz dveh delov (sl. 7.3). Prvi del predstavlja

grafični uporabniški vmesnik (GUI – Graphical User Interface), ki omogoča

administratorju oz. pooblaščeni osebi dostop do vseh podatkov uporabnikov telefonskih

številk v podatkovni bazi. GUI omogoča tudi vnos novih uporabnikov v podatkovno bazo,

urejanje podatkov že obstoječih uporabnikov ter brisanje iz baze. Drugi del sistema je

računalniška aplikacija, ki iz podatkovne baze, kjer so shranjeni vsi uporabniki, katere je

potrebno obvestiti, pridobi telefonske številke in druge pomembne parametre ter

samodejno opravi klice na te številke in uporabnikom predvaja vnaprej posneto sporočilo.

Slika 7.3: Arhitektura sistema za obveščanje uporabnikov

Aplikacija klice izvaja s pomočjo spletne storitve Third Party Call, ki je le ena izmed

mnogih storitev vmesnika Parlay X. Predvajanje sporočila klicanemu pa opravlja glasovni

odzivnik s pomočjo VoiceXML. Podroben opis in delovanje grafičnega uporabniškega

vmesnika ter same aplikacije, ki izvaja klice, bomo opisali v podpoglavjih.

7.3.1 Podatkovna baza

Jedro našega sistema za obveščanje predstavlja MySQL podatkovna baza, kjer so

shranjeni vsi podatki, s katerimi operira sistem. Ključnega pomena pred začetkom pisanja

programske kode je bilo razmisliti o strukturi baze in o tem, kateri podatki se bodo vanjo


shranjevali. Po temeljiti analizi in premisleku smo se odločili, da bomo uporabili le eno

tabelo v bazi. Tabela vsebuje vse pomembne podatke o lastnikih telefonskih številk. Sem

sodijo ime, priimek, naslov, telefonska številka, naslov elektronske pošte in drugi

parametri. Parametri so pomembni predvsem s stališča aplikacije, ki opravlja klice, saj se

na podlagi vrednosti parametrov odloči, katerega uporabnika bo poklicala. Pomembni

parametri so »datum vnosa«, »datum zadnjega klica«, »število klicev«, »število uspešnih

klicev«, »status«, »nedosegljiv/zaseden«. Slika 7.4 prikazuje strukturo tabele v podatkovni

bazi.

Slika 7.4: Struktura tabele v podatkovni bazi

7.3.2 Grafični uporabniški vmesnik

Grafični uporabniški vmesnik mora administratorju omogočati pregled vseh

uporabnikov telefonskih številk v bazi, vstavljanje novih, urejanje že obstoječih vnosov ter

brisanje iz baze. V ta namen smo s tehnologijo JSP izdelali spletno aplikacijo, ki je

naložena na spletnem strežniku Tomcat in je preko spleta dostopna od kjerkoli in

kadarkoli. Spletni strežnik je lahko tudi kateri drugi, vendar pa mora biti takšen, ki

podpirati programski jezik Java in podatkovno bazo MySQL. Administrator oz. uporabnik

spletne aplikacije potrebuje samo dostop do spleta in URL (Uniform Resource Locator –

enolični lokalizator vira) naslov spletne aplikacije, ki ga vpiše v spletni brskalnik (Mozilla

Firefox, Internet Explorer …). Pred vstopom v aplikacijo se mora prijaviti še z

uporabniškim imenom in geslom, nato pa mu je omočen dostop do vseh podatkov, ki jih

lahko pregleduje in poljubno spreminja.


7.3.3 Funkcije grafičnega uporabniškega vmesnika

Grafični uporabniški vmesnik je zasnovan modularno (sl. 7.5). Preko prijavnega

obrazca se uporabnik prijavi v spletno aplikacijo, kjer ima na glavni strani aplikacije na

voljo štiri funkcionalne sklope. Uporabnik lahko doda novi vnos v podatkovno bazo, uredi

že obstoječe vnose, briše vnose ter išče med vnosi v bazi. Po končanem delu se uporabnik

odjavi iz spletne aplikacije.

Slika 7.5: Arhitektura grafičnega uporabniškega vmesnika

Prijava v spletno aplikacijo

V podatkovni bazi se nahajajo občutljivi osebni podatki, zato je bilo potrebno poskrbeti

za varnost le-teh. Dostop do spletne aplikacije je mogoč samo preko prijave z

uporabniškim imenom in geslom. Ta varnostni mehanizem omogoča dostop do kritičnih

podatkov samo pooblaščenim osebam. Problema smo se lotili na nivoju spletnega strežnika

in v konfiguraciji strežnika določili potrebne parametre za varnost. V nastavitvah strežnika


je mogoče dodajati nove uporabnike, katerim se dodeli uporabniško ime in geslo, ter

pravice oz. vsebina spletne aplikacije, do katere imajo dostop. Prav tako smo izdelali

spletni obrazec (sl. 7.6), preko katerega se lahko uporabnik prijavi v spletno aplikacijo.

Slika 7.6: Vstopni obrazec za prijavo v spletno aplikacijo

Osnovna stran spletne aplikacije

Po uspešni prijavi v aplikacijo se na zaslonu pojavi osnovna stran s tabelo (sl. 7.7), ki

vsebuje podatke o lastnikih telefonskih številk. Tabela v spletni aplikaciji se polni direktno

iz baze podatkov, kjer so zbrani vsi zapisi. V programski kodi je to realizirano s pomočjo

jezika SQL. Najprej se vzpostavi povezava z bazo, nato pa se vrstico po vrstico zapis iz

baze prepiše v tabelo na zaslonu. Uporabniku aplikacije niso na voljo vsi podatki iz baze.

Vidni so samo ime, priimek, naslov, naslov elektronske pošte in telefonska številka. Ti

podatki se lahko tudi spreminjajo pri že obstoječih vnosih v bazi. Ostali parametri, kot so

»datum_vnosa« ali »datum_posodobitve«, v spletni tabeli niso vidni in jih tudi ni mogoče

spreminjati, saj se tvorijo samodejno ob novem vnosu ali posodobitvi podatkov o že

obstoječem lastniku telefonske številke. Ob vsaki vrstici v tabeli, ki predstavlja enega

lastnika telefonske številke v bazi, je dodan izbirni gumb. S klikom na gumb lahko

izberemo točno določenega lastnika telefonske številke in ga tako označimo za urejanje oz.

brisanje iz baze. Pod tabelo je polje z gumbi, ki omogočajo dodajanje novega vnosa,


urejanje in brisanje. Desno zgoraj ob tabeli so podatki o tem, kdo je prijavljen v spletno

aplikacijo in možnost odjave.

Slika 7.7: Glavno okno spletne aplikacije

Dodajanje novega vnosa

S klikom na gumb »Dodaj« se pod tabelo odpre nova vnosna forma, preko katere

vnesemo podatke o novem lastniku telefonske številke, ki ga želimo dodati v bazo (sl. 7.8).

Slika 7.8: Dodajanje novega vnosa


Vpisani podatki se pred samim vnosom v bazo preverjajo, da se izognemo nepravilnostim

med delovanjem celotnega sistema. Ime in priimek lahko vsebujeta samo črke oz. znake

abecede, brez številk ali katerih drugih posebnih znakov. Telefonska številka lahko vsebuje

le števke, naslov elektronske pošte pa mora ustrezati točno določenim pravilom zapisa, ki

so določena v standardih za obliko elektronskih naslovov (npr.: [email protected]).

Naslov lastnika telefonske številke je načeloma lahko kakršnekoli oblike in lahko vsebuje

vse znake. Če uporabnik v katero od vnosnih polj vnese nedovoljene znake, ga aplikacija

na to opozori in ne dovoli vpisa v bazo, dokler uporabnik ne popravi vnosa. Šele ko vsi

vpisani podatki ustrezajo pravilom, lahko s klikom na gumb »Dodaj zapis«, zapišemo

podatke v bazo, hkrati pa se nov vnos pojavi tudi v prikazni tabeli spletne aplikacije.

Urejanje obstoječih vnosov

Kadar želimo spremeniti podatke o že obstoječem vnosu v bazi, moramo s klikom na

izbirni gumb izbrati točno določenega lastnika telefonske številke v tabeli, kateremu

želimo spreminjati podatke. Podobno kot pri vnosu novega lastnika telefonske številke, se

tudi ob kliku na gumb »Posodobi« pod tabelo pojavi vnosna forma. Razlika je le ta, da

vnosna polja v tem primeru že vsebujejo podatke o osebi, katero smo izbrali v zgornji

tabeli. Podatke lahko zdaj poljubno spreminjamo in jih na koncu shranimo. Tudi tukaj se

vneseni podatki preverjajo in šele ko zadostujejo vsem pogojem, je omogočen zapis

posodobljenih podatkov v bazo. Po kliku na gumb »Posodobi zapis« se podatki posodobijo

tudi v bazi, hkrati pa se spletna aplikacija v brskalniku osveži in v tabeli so takoj vidni novi

posodobljeni podatki. Na sliki 7.9 je prikazano urejanje podatkov o lastniku telefonske

številke, ki smo ga predhodno s klikom na izbirni gumb izbrali v tabeli. Izbrali smo osebo

pod identifikacijsko številko 14, ki nosi ime Lojze in priimek Novak.


Slika 7.9: Urejanje obstoječega vnosa

Brisanje vnosov

Kadar želimo določenega lastnika telefonske številke izbrisati oz. odstraniti iz baze, ga

moramo najprej s klikom na izbirni gumb izbrati v tabeli in nato pritisniti še gumb »Briši«.

Ob kliku nam aplikacija odpre pogovorno okno z opozorilom (sl. 7.10), da želimo trajno

izbrisati podatke o izbrani osebi iz baze in nam ponudi dvoje možnosti. V primeru

potrditve izbrisa se vnos nemudoma izbriše iz baze, drugače pa se spletna aplikacija

osveži, podatki pa ostanejo nespremenjeni.

Slika 7.10: Brisanje vnosa iz baze


Iskanje

Spletni aplikaciji smo dodali tudi možnost iskanja. Ta funkcija pride zelo prav v realnih

situacijah, ko je v bazi veliko število lastnikov telefonskih številk (nekaj tisoč), mi bi pa

radi poiskali in spremenili podatke točno določeni osebi oz. jo izbrisali iz baze, ker ni več

potrebe po obveščanju te osebe.

Na osnovni strani spletne aplikacije se nahaja vnosno polje za iskanje, kamor vpišemo

iskano besedo ali niz. Ob kliku na gumb »Išči« se zažene iskalni algoritem v programski

kodi, ki pregleda celotno tabelo vnosov ter poišče ujemajoče se besede. Tiste vnose v bazi,

ki vsebujejo iskano besedo ali niz, izpiše v novi tabeli in jo prikaže uporabniku na zaslonu.

Postopek urejanja ali brisanja najdenega vnosa je identičen tistemu, ki smo ga opisali že

prej. Nekatere omejitve oz. težave se pokažejo, ko je v bazi resnično veliko število vnosov

(nekaj deset tisoč). Pojavijo se lahko zakasnitve pri iskanju in izpisu najdenih vnosov na

zaslon. Problem ni v transakcijah med aplikacijo in bazo, te so zelo hitre, ampak časovno

zakasnitev vnašata sam grafični uporabniški vmesnik in spletni strežnik, ki imata v takem

primeru ogromno dela z indeksiranjem posameznih vrstic v tabeli in izpisom na zaslon.

7.3.4 Aplikacija za obveščanje uporabnikov

Aplikacija za obveščanje uporabnikov (v nadaljevanju aplikacija) je bistveni del

celotnega sistema, saj samodejno vzpostavlja klice med osebami v bazi, ki jih je potrebno

obvestiti in glasovnim odzivnikom, ki obveščanemu predvaja določeno, vnaprej posneto

sporočilo. Aplikacija je v celoti napisana v programskem jeziku Java in je v svoji osnovi

preprosta namizna javanska aplikacija, ki jo poženemo z javansko izvršljivo datoteko.

Grafični vmesnik aplikacije je zelo preprost in vsebuje le gumb, s katerim sprožimo

izvajanje aplikacije in polje za prikaz besedila, v katerem se izpisujejo nekateri pomembni

podatki med izvajanjem aplikacije. Aplikacija za obveščanje je odjemalska aplikacija, ki jo

je bilo potrebno integrirati v telekomunikacijsko omrežje. V našem testnem okolju se

aplikacija nahaja na PC-ju, ki ima povezavo z aplikacijskim strežnikom in klicnim

strežnikom, ki smo ju podrobneje opisali v poglavju 4. Na istem PC-ju je tudi baza s

podatki o osebah, ki jih je potrebno obveščati. Slika 7.11 prikazuje umestitev aplikacije za

obveščanje v telekomunikacijsko omrežje.


Slika 7.11: Umestitev aplikacije v omrežje

Aplikacija pridobi telefonske številke iz baze ter s pomočjo storitve Third Party Call,

vmesnika Parlay X na aplikacijskem strežniku, vzpostavi klic med uporabnikom in

glasovnim odzivnikom. Življenjski cikel delovanja aplikacije je sestavljen iz treh delov (sl.

7.12). Takoj po zagonu aplikacija vzpostavi povezavo s podatkovno bazo in iz nje prebere

vse uporabnike, za katere mora vzpostaviti klic. Uporabnike skupaj z vsemi atributi vpiše v

seznam, iz katerega nato jemlje telefonske številke za vzpostavljanje klica. Na koncu

aplikacija na podlagi informacij o klicu posodobi parametre za določenega uporabnika in

jih shrani nazaj v bazo.

Slika 7.12: Življenjski cikel aplikacije


Pridobitev telefonskih številk iz baze

Pred vzpostavljanjem klicev mora aplikacija pridobiti iz baze telefonske številke, ki jih

nato uporabi za klicanje. Ker smo našo aplikacijo načrtovali za primer obveščanja

neplačnikov telefonskih storitev, igrajo veliko vlogo pri izbiri uporabnikov iz baze

parametri, ki so dodeljeni posameznemu neplačniku. Parameter »status« nam pove stopnjo

kritičnosti neplačnika. Status lahko ima vrednosti od 0 do 3. Pri tem 0 pomeni, da je

neplačnik na novo v bazi in ga še nismo obveščali, status 3 pa označuje neplačnika, ki smo

ga že velikokrat obvestili, vendar še vedno ostaja neplačnik. Tiste neplačnike z višjim

statusom kličemo bolj pogosto kot tiste z nižjim. Pri neplačnikih z višjim statusom igra

pomembno vlogo še parameter »datum zadnjega klica«. Preden damo neplačnika v seznam

za klicanje, preverimo časovno razliko med trenutnim datumom in datumom zadnjega

klica. V primeru, da časovna razlika ustreza vnaprej določeni vrednosti za posamezni

status, dodamo neplačnika v seznam za klicanje. Posebni parameter »nedosegljiv_zaseden«

lahko nosi vrednosti 0 ali 1. Parameter dobi vrednost 1, kadar smo neplačnika klicali,

vendar pa ni bil dosegljiv, je bil zaseden ali pa je prekinil zvezo predčasno. Kadar ima

neplačnik postavljen ta parameter na 1, ga damo v seznam za klicanje nemudoma in ga

pokličemo spet takoj, ko je mogoče. Slika 7.13 prikazuje potek pridobivanja neplačnikov

iz baze, tabela 7.1 pa pomen posameznih vrednosti parametra »status«.

Tabela 7.1: Seznam vrednosti parametra »status«

Status Opis

0 Prvi vnos neplačnika, nismo še klicali => dodaj v seznam za klicanje.

1 Neplačnika smo že klicali, vendar neuspešno => če je razlika med trenutnim datumom in datumom zadnjega klica več kot 7 dni, dodaj v seznam za klicanje.

2 Neplačnika smo že klicali, vendar neuspešno => če je razlika med trenutnim datumom in datumom zadnjega klica več kot 3 dni, dodaj v seznam za klicanje.

3 Neplačnika smo že klicali, vendar neuspešno => če je razlika med trenutnim datumom in datumom zadnjega klica več kot 1 dan, dodaj v seznam za klicanje.


Slika 7.13: Potek pridobivanja telefonskih številk iz baze


Vzpostavljanje klicev

Ko imamo vse neplačnike v seznamu za klicanje, lahko pričnemo dejansko

vzpostavljati klice na njihove telefonske številke. Aplikacija iz seznama vzame telefonsko

številko prvega neplačnika in vzpostavi klic med njim in glasovnim odzivnikom. Na

podlagi informacij o klicu se odloči, katere parametre bo nastavila in nato vzame

telefonsko številko naslednjega neplačnika iz seznama. Slika 7.14 prikazuje potek klicanja

številk iz seznama za klicanje.

Slika 7.14: Potek klicanja številk iz seznama za klicanje

Posodobitev baze

Aplikacija med opravljanjem klicev sproti beleži in posodablja parametre za vsakega

uporabnika v seznamu za klicanje. Ko opravi vse klice, so tako v seznamu že vsi

posodobljeni podatki. Naloga aplikacije je zdaj samo še posodobitev vseh podatkov v bazi.

V ta namen vzpostavi povezavo z MySQL podatkovno bazo in prepiše vrednosti atributov,

ki so se spremenile, z novimi s seznama. S tem je delovanje aplikacije zaključeno, baza pa

pripravljena na novo obveščanje.


7.3.5 Scenarij klica

Aplikacija za vzpostavljanje klica uporablja storitev Third Party Call vmesnika Parlay

X. Za vsako telefonsko številko s seznama za klicanje aplikacija kliče metodo makeCall.

Metoda zahteva dva parametra, telefonsko številko kličočega in telefonsko številko

klicanega, da lahko vzpostavi telefonsko zvezo med njima. Telefonska številka kličočega

je številka neplačnika s seznama, ki ga nameravamo obveščati in je ob vsakem klicu

metode drugačna (drugi neplačnik). Številka klicanega pa ves čas izvajanja aplikacije

ostaja ista, saj se za njo skriva glasovni odzivnik. Učinek je podoben, kot da bi uporabnik

sam poklical na številko odzivnika, le da v našem primeru aplikacija sama poskrbi za

vzpostavitev zveze in se uporabnik tega niti ne zaveda.

Poglejmo scenarij klica, kjer želimo neplačnika s telefonsko številko 082023 obvestiti,

da naj čim prej poravna račun za telefonske storitve. Glasovni odzivnik se nahaja na

številki 082024. Aplikacija uporabi ti dve številki kot parametra pri klicu metode

makeCall. Najprej sistem pokliče na številko neplačnika, zato pri njemu zvoni telefon. Ko

se ta javi, sistem pokliče še na številko odzivnika in ko se odzivnik aktivira, sistem

vzpostavi zvezo med neplačnikom in glasovnim odzivnikom. Zdaj odzivnik predvaja

sporočilo neplačniku in zveza se konča, ko uporabnik odloži slušalko.

Na sliki 7.15 je izsek programske kode, ki vzpostavi klic med neplačnikom in

odzivnikom. Vidimo, da lahko samo z eno vrstico programske kode vzpostavimo klic.

Ostale tri vrstice poskrbijo za inicializacijo telefonskih številk in storitve Third Party Call.

Slika 7.15: Klic metode makeCall

Slika 7.16 prikazuje potek klica, ki je vzpostavljen in nadzorovan s strani aplikacije

(Third Party Call). Prikazan je primer seje, v kateri se kličeta metodi makeCall in

getCallInformation vmesnika Parlay X. Najprej aplikacija kliče metodo makeCall. Parlay


X se odzove na klic metode s kreiranjem posebnega identifikatorja seje CallIdentifier, ki je

za vsako sejo edinstven in jo enoznačno določa. Hkrati s posredovanjem identifikatorja

seje proti aplikaciji, Parlay X pošlje tudi zahtevo za vzpostavitev klica proti klicnemu

strežniku. Ta poskrbi za vzpostavitev telefonske zveze med uporabnikom in glasovnim

odzivnikom (telefonski številki obeh strani sta argumenta metode makeCall). Najprej

pokliče uporabnika in počaka, da se ta javi. Ko se uporabnik javi na klic, klicni strežnik

zadrži zvezo in pokliče še glasovni odzivnik. Ko se aktivira še glasovni odzivnik, klicni

strežnik vzpostavi zvezo med njima in lahko se prične dialog.

Slika 7.16: Potek klica

Ves čas od klica metode makeCall pa do konca zveze lahko aplikacija poizveduje in

pridobiva informacije o klicu. S klicem metode getCallInformation lahko aplikacija

ugotovi, kdaj je bila zveza med uporabnikom in glasovnim odzivnikom vzpostavljena, kdaj

je bila zveza končana in kako dolgo je trajala ter tudi vzrok, zaradi katerega je bila zveza

prekinjena in katera stran jo je končala. Vse te informacije so za delovanje sistema zelo


pomembne, saj se ravno na podlagi teh aplikacija odloči, kako bo spremenila vrednosti

atributov posameznemu uporabniku v bazi. Na primer, če aplikacija ugotovi, da je zveza

trajala prekratek čas, to pomeni, da neplačnik ni do konca poslušal sporočila predvajanega

s strani odzivnika in zato se mu atribut »nedosegljiv/zaseden« postavi na vrednost 1 oz.

»TRUE«. To pa pomeni, da bo ob naslednjem pregledu baze izbran za ponovni klic, čeprav

smo ga pred kratkim že klicali. Atribut »nedosegljiv/zaseden« se postavi na vrednost 1

tudi, kadar aplikacija ugotovi, da je klicani neplačnik nedosegljiv, zaseden ali pa se

preprosto ni javil na klic oz. ga je prekinil in se zveza med njim in glasovnim odzivnikom

niti ni mogla vzpostaviti. Aplikacija sproti ob vsakem klicu posodablja parametre v

seznamu za klicanje. Na podlagi identifikatorja seje aplikacija ve, kateri uporabnik je bil

udeležen pri klicu in kateremu mora prirediti nove vrednosti parametrov.

Aplikacija je zasnovana tako, da vzpostavi naenkrat samo en klic. Premika se po

seznamu za klicanje od prvega uporabnika do zadnjega in za vsakega vzpostavi klic. Ko se

klic zaključi in se parametri v seznamu posodobijo, začne vzpostavljati novi klic za

naslednjega uporabnika v seznamu. Zavedamo se, da v realnih razmerah, kjer je potrebno v

kratkem času obvestiti nekaj tisoč uporabnikov telekomunikacijskih omrežij, takšen pristop

ne bi bil najboljša izbira, saj bi obveščanje trajalo predolgo. Potrebno bi bilo uvesti hkratno

vzpostavljanje klicev za večje število uporabnikov, kar vmesnik Parlay X, klicni strežnik in

drugi elementi omrežja tudi omogočajo. Za implementacijo tega koraka se nismo odločili

zaradi povečanja kompleksnosti sistema, ki bi ga tak korak prinesel. V programski kodi bi

bilo potrebno implementirati paralelno izvajanje velikega števila operacij (niti). Soočili bi

se tudi z ogromno množico podatkov, ki bi jih bilo potrebno obdelati, hkrati pa bi morali

ob določenem trenutku prestreči točno določen podatek za posamezni klic izmed množice

drugih, kar pa ni ravno lahka naloga. Takšen pristop bi zahteval mnogo več časa za razvoj

in testiranje, zavedamo pa se, da bo v prihodnosti potrebno tudi ta korak implementirati, če

bo hotel sistem izpolniti vsa pričakovanja uporabnikov in služiti namenu.


7.3.6 Glasovni odzivnik

Za potrebe glasovnega odzivnika je bilo potrebno uporabiti strežnik VoiceXML, ki

VoiceXML interpreterju (ki je del signalizacijskega in medijskega prehoda) predaja

VoiceXML skripte, da jih ta lahko zaganja ter uporabniku predvaja sporočila.

Na VoiceXML strežniku imamo dve skripti, ki služita kot vstopna in izstopna skripta.

Za naše potrebe je to dovolj, saj uporabniku želimo le predvajati sporočilo. Uporabnik

lahko interaktivno komunicira z odzivnikom le po koncu predvajanja sporočila, kjer lahko

z DTMF izbiro ponovno posluša sporočilo ali pa konča pogovor. Na sliki 7.17 je prikazana

arhitektura in princip delovanja glasovnega odzivnika.

Slika 7.17: Arhitektura glasovnega odzivnika

Skripte na VoiceXML strežniku tečejo pod strežnikom Tomcat, ki skrbi za generiranje in

predstavljanje skript. Tomcat omogoča, da so VoiceXML skripte napisane v programskem

jeziku Java in predstavljene kot servleti. Na sliki 7.18 je prikazan primer komunikacije

med uporabnikom in glasovnim odzivnikom.


Slika 7.18: Scenarij delovanja glasovnega odzivnika

Aplikacija je pred tem že poklicala uporabnika, sedaj pa kliče še odzivnik in ko se

odzivnik aktivira, vzpostavi zvezo med njima, tako da lahko uporabnik posluša sporočila,

ki mu jih predvaja odzivnik.

Na centrali je številka odzivnika vezana na VoiceXML skripto. Centrala pošlje zahtevo

za main VoiceXML skripto proti VoiceXML strežniku, ki ga ima vpisanega v bazi za to

številko. Strežnik na zahtevo vrne VoiceXML skripto, ki jo centrala v VoiceXML

interpreterju prevede in izvede. Uporabniku se predvaja sporočilo, na koncu pa se ga

pozove, da izbere eno od sledečih možnosti. Uporabnik na tipkovnici telefona pritisne

ustrezno tipko in na podlagi izbire interpreter pošlje VoiceXML strežniku zahtevo po novi

skripti. Scenarij se nadaljuje, dokler uporabnik ne prekine zveze (odloži telefonsko

slušalko) ali izbere DTMF izbiro za končanje pogovora.


8 PRIMERJAVA DELOVANJA SISTEMA Z DELOM

OPERATERJA

Namen sistema za obveščanje uporabnikov je dopolniti delo ljudi (operaterjev) oz. ga

popolnoma nadomestiti. Razvoj sistema je začetni strošek, ki pa se kmalu povrne, če

upoštevamo, da sistem deluje avtomatizirano in opravi mnogo več klicev naenkrat, kot jih

zmore človek. Sistem je sposoben vzpostaviti nekaj sto klicev naenkrat (odvisno od

zmogljivosti opreme), medtem ko človek lahko opravi le en klic v določenem trenutku. Za

isto delo, kot bi ga opravil sistem, bi torej potrebovali nekaj sto operaterjev, kar pa

predstavlja ogromen strošek. Za uspešno in pravilno delovanje sistema je potrebno le

osebje, ki skrbi za vnos in urejanje podatkov v podatkovni bazi, in osebje, ki skrbi za

pravilno delovanje sistema in njegovo vzdrževanje. Število teh ljudi je zanemarljivo

majhno v primerjavi s številom, ki bi ga potrebovali, če bi hoteli opraviti v določenem času

isto število klicev, kot ga zmore sistem. Ljudje so sicer dokaj zanesljivi in predvsem

nadomestljivi, kar za sistem ne moremo trditi. Možnosti napak v sistemu so vedno

prisotne, prav tako pa je ob odpovedi najmanjše komponente sistema moteno delovanje

celotnega sistema. Če nimamo rezervnega scenarija, je lahko izpad precejšen, vendar pa se

te zadeve lahko rešujejo tudi z operaterji, ki bi priskočili na pomoč v času nedelovanja

sistema. Sama administracija sistema je zelo preprosta, saj uporablja preprost grafični

vmesnik z malo funkcijami. Vstavljanje v bazo in urejanje vnosov poteka preko spletnega

brskalnika, kjer je grafični vmesnik preprost in jasno definiran. Zagon sistema za

vzpostavljanje klicev je mogoč preko namizne aplikacije, ki ima »okenski« uporabniški

vmesnik, ki je prav tako zelo preprost za uporabo, saj vsebuje le gumb za začetek izvajanja

klicev in končanje delovanja ter okno, v katerem se izpisujejo trenutne operacije sistema za

lažje spremljanje delovanja. S stališča uporabniške izkušnje je sistem zelo primeren, saj ne

zahteva dodatnega izobraževanja ljudi, ki bi z njim upravljali.


9 SKLEP

Razvoj telekomunikacij ter omrežja naslednje generacije v modernem času prinašajo

eno poglavitnih prednosti – nove konvergenčne storitve, ki predstavljajo pomemben

dejavnik tudi pri vse večji razširjenosti govora prek IP. Za množičen razvoj storitev so

ključni odprti aplikacijski vmesniki, ki omogočajo selitev inteligence iz omrežnih

elementov v aplikacijske strežnike. Omrežja naslednje generacije bodo tako preko le-teh

ponudila dostop do zmogljivosti telekomunikacijskih omrežnih elementov. Hitrejši razvoj

novih aplikacij bodo omogočili predvsem vmesniki, ki temeljijo na skriptnih jezikih in so

dostopni preko spleta, in ki bodo na voljo množični skupnosti razvijalcev internetnih

aplikacij.

Cilj diplomskega dela je bil izdelati sistem za obveščanje velikega števila uporabnikov

telekomunikacijskih omrežij, ki bi nadomestil ali dopolnil že obstoječe načine obveščanja.

Sistem temelji v prvi vrsti na klicnem obveščanju, vendar pa je zasnovan tako, da ga je v

prihodnosti mogoče dopolniti in razširiti tudi z drugimi načini obveščanja (SMS,

elektronska pošta ...). V nalogi smo opisali vse postopke ter probleme, ki smo jih imeli v

fazi razvoja sistema. Največji izziv, s katerim smo se srečali že na začetku načrtovanja, je

bil prav gotovo izbira tehnologij, s katerimi bi se dalo sistem realizirati. Velik izziv je bil

tudi spojitev vseh tehnologij v sinergijsko celoto, da na eni strani z vidika administratorja

sistema in na drugi strani uporabnika telekomunikacijskih omrežij sistem deluje usklajeno

in učinkovito. Rezultat dela je delujoč sistem, ki cilja predvsem na integracijo in uporabo

znotraj večjega sistema, na primer v omrežju nacionalnega operaterja telekomunikacij ali

katerega drugega operaterja, ki razpolaga z dovolj zmogljivo opremo in omrežjem. Ko

govorimo o obveščanju preko telefona, danes mislimo predvsem na ljudi (operaterje), ki

opravljajo telefonske klice. Ključen problem pri tem je hitrost in s tem povezani stroški. Za

vzpostavitev velikega števila klicev v kratkem času potrebujemo danes tudi veliko število

ljudi, kar pa povečuje stroške. Z uporabo našega avtomatiziranega sistema za obveščanje bi

se izognili tem stroškom, hkrati pa bi ogromno pridobili na hitrosti in času, kar po našem


mnenju komercialno in finančno opravičuje razvoj in integracijo takšnega sistema. Za

uspešno delovanje sistema je potrebna le peščica usposobljenih ljudi, ki bi skrbeli za

pravilno delovanje in vzdrževanje sistema. Z vidika uporabnika telekomunikacijskih

omrežij pa je sistem dobrodošel iz razloga, da je vedno pravočasno in kvalitetno obveščen

o pomembnih zadevah.

Realizacija tega projekta mi je dala veliko novih izkušenj in znanja, ki mi bodo pri

nadaljnjem delu zelo koristila, hkrati pa naj bo to diplomsko delo vzpodbuda bralcu pri

razmišljanju in razvoju novih storitev, ki jih omrežja naslednje generacije prav gotovo

ponujajo. Diplomsko delo sem napisal na podlagi raziskovalnega dela in izkušenj, ki sem

jih pridobil med študijem na Fakulteti za elektrotehniko, računalništvo in informatiko v

Mariboru.


VIRI, LITERATURA

[1] T. Kapus, Telekomunikacijska omrežja I, zapiski predavanj, Fakulteta za elektrotehniko, računalništvo in informatiko, Maribor, 2006.

[2] T. Kapus, Telekomunikacijska omrežja II, zapiski predavanj, Fakulteta za elektrotehniko, računalništvo in informatiko, Maribor, 2005.

[3] U. Mesojedec, B. Fabjan, Java 2, temelji programiranja, Pasadena, Ljubljana, 2004.

[4] L. Zebec, I. Humar, A. Kos, J. Bešter, Razvoj storitev v 21CN na osnovi XML, Laboratorij za telekomunikacije, Fakulteta za elektrotehniko, Univerza v Ljubljani, Ljubljana, 2005, http://www.ltfe.org/wp-content/pdf/Storitve_21CN.pdf

[5] A. Kos, M. Volk, J. Bešter, NGN, VoIP ali Skype?, Laboratorij za telekomunikacije, Fakulteta za elektrotehniko, Univerza v Ljubljani, Ljubljana, 2005, http://www.ltfe.org/wp-content/pdf/NGN_VoIP_Skype.pdf

[6] Uvod v NGN, Laboratorij za telekomunikacije, Fakulteta za elektrotehniko, Ljubljana, 2008, http://lt.fe.uni-lj.si/gradiva/NVTSS/Jagodic%20-%202007-2008/15-uvod-v-ngn-akos.pdf

[7] Wikipedia, Next Generation networking, http://en.wikipedia.org/wiki/Next_Generation_Networking

[8] Wikipedia, IP Multimedia Subsystem, http://en.wikipedia.org/wiki/IP_Multimedia_Subsystem

[9] J. Andersson, M. Kihl, D. Söbirk, Overload Control of Parlay X Application Server, Department of Communication Systems Lund Institute Of Technology, Sweden, http://www.scs.org/getDoc.cfm?id=2895

[10] Parlay Group, http://www.parlay.org

http://www.ltfe.org/wp-content/pdf/Storitve_21CN.pdf

http://www.ltfe.org/wp-content/pdf/NGN_VoIP_Skype.pdf

http://lt.fe.uni-lj.si/gradiva/NVTSS/Jagodic%20-%202007-2008/15-uvod-v-ngn-akos.pdf

http://lt.fe.uni-lj.si/gradiva/NVTSS/Jagodic%20-%202007-2008/15-uvod-v-ngn-akos.pdf

http://en.wikipedia.org/wiki/Next_Generation_Networking

http://en.wikipedia.org/wiki/IP_Multimedia_Subsystem

http://www.scs.org/getDoc.cfm?id=2895

http://www.parlay.org/


[11] VoiceXML Forum, http://www.voicexml.org

[12] D. Bodnaruk, K. Peternel, Parlay X komponenta, Funkcijska specifikacija, (Iskratel – interni dokument), Kranj, 2008.

[13] M. Lepener, Govorni vmesnik za osebni komunikacijski portal, diplomska naloga univerzitetnega študijskega programa, Fakulteta za elektrotehniko, računalništvo in informatiko, Maribor, 2006.

[14] H.323 Forum, http://www.h323forum.org/

[15] Wikipedia, Session Initiation Protocol, http://en.wikipedia.org/wiki/Session_Initiation_Protocol

[16] Wikipedia, Java,

http://en.wikipedia.org/wiki/Java_(programming_language)

http://www.voicexml.org/

http://www.h323forum.org/

http://en.wikipedia.org/wiki/Session_Initiation_Protocol

http://en.wikipedia.org/wiki/Java_(programming_language)


PRILOGE

Naslov študenta

Marko Lubej

Mladinska ul. 2

2000 Maribor

Tel.: 040 616 748

e-mail: [email protected]

Kratek življenjepis

Rojen: 29. 5. 1984 v Mariboru

Šolanje: 1991-1999 Osnovna šola Bojana Ilicha Maribor

1999-2003 II. gimnazija Maribor

2003-2009 Fakulteta za elektrotehniko, računalništvo in informatiko, Maribor

Univerzitetni študijski program Telekomunikacije

mailto:[email protected]

razvoj sistema za obveŠČanje velikega Števila … · an increasingly versatile service-centric...

Documents