UNIVERZITET UNION RAČUNARSKI FAKULTET

VOIP TEHNOLOGIJA BAZIRANA NA ASTERISK PLATFORMI

MASTER RAD

Mentor: Student: Prof. dr. Stevan Milinković Petar Bojović Članovi komisije: Prof. dr. Desimir Vučić Mr. Mirjana Radivojević

2

SADRŽAJ � Uvod 3

� VoIP 4

� VoIP protokoli 6

� Kodeci za pakovanje glasa 10

� QoS 12

� Asterisk open-source platforma 14

� Asterisk kanali (channels) 16

� Aplikacije 17

� Dialplan 18

� Asterisk i VoIP protokoli 21

� IAX vs SIP 23

� Evolucija VoIP koncepta 24

� Dodatne mogućnosti Asterisk platforme 25

� Aplikacija za automatsko pozivanje 29

� Aplikacija za trenutni kurs NBS 34

� Aplikacija „Skiper“ 36

� Projekat razvojno ime: „Igre bez granica“ 39

� Echo problemi i rešenja 41

� Literatura 45

3

� Uvod

Telefonija predstavlja glavni vid komunikacije ljudi elektronskim putem.

Aktuelna tehnologija prenosa glasa – fiksna telefonija – sada već predstavlja zastareo sistem prenosa glasa.

Fiksna telefonija – telefonija koju Telekom već dugo nudi kao uslugu, funkcioniše po principu komutiranih (circuit switched) kola. Tako, kada želimo da uspostavimo vezu sa udaljenom lokacijom, zauzimamo ceo link do telefonske centrale, zatim rezervišemo sve linkove do krajnje centrale, i do korisnika koga pozivamo. Kako smo zauzeli po jedan link između svih centrala koje koristimo, drugi korisnici ne mogu koristiti taj link za svoje potrebe.

Analizom se došlo do rezultata da u razgovoru više od 60 % vremena prođe u ćutanju (vreme kada se ne vrši prenošenje glasa), došlo se do zaključka da iskorišćenost takvog linka iznosi maksimalno do 40 %.

Zbog nemogućnosti da isti link koristi više korisnika, korišćenje zauzetog linka njegova cena, pada na pojedinca koji koristi link. To je glavni razlog za visoku cenu razgovora između dve udaljene lokacije.

Ako saberemo ova dva parametra: visoku cenu korišćenja linka i malu efektivnu iskoristljivost, dolazimo do zaključka da je ova tehnologija prenosa glasa vrlo nepovoljna kako za kranje korisnike zbog visoke cene korišćenja, tako i za pružaoce ove usluge zbog potrebe za većim brojem resursa i skuplje opreme.

�

Primer hijararhije telefonsih centrala u fiksnoj telefoniji

4

� VoIP Prihvatanjem TCP/IP protokola kao standarda računarskih mreža stvorili su se

uslovi za povezivanje velikih i malih mreža u jednu celinu, popularno nazvanu internet, čime se otvorila nova mogućnost korišćenja postojećih linkova i drugih resursa.

Američki provajder ARPANET, začetnik Internet mreže je prvi provajder koji je još 1973. godine, započeo eksperimente na polju prenošenja glasa preko IP mreža.

Korišćenjem TCP/IP protokola, koji je paket switched tehnologija prenosa, mogu se rešiti dva najveća problema koja se javljaju kod tehnologija sa komutiranim kolima. Tehnolgija Voice over IP (VoIP), bazira se na TCP/IP modelu prenosa podataka. U zavisnosti od potrebe za kvalitetom, glas se prvo digitalizuje različitim metodama, zatim se pakuje naprednim algoritmima za kodiranje korišćenjem nekih od kodeka.

Tako kodiran paket se secka na dosta malih paketa. Veličina paketa zavisi od kodeka i protokola koji se koristi za slanje paketa, (SIP G711 ~ 160 bajta na svakih 20 milisekundi). Korišćenjem RTP protokola (Real-time Transport Protokol), mali paketi se šalju drugoj strani preko UDP protokola 4 sloja TCP/IP modela. Prijemna strana može biti krajnji korisnik, ili gateway koji treba da prosledi ili na neki način konvertuje te pakete i uruči glas krajnjem korisniku. Kada paket pristigne, on se odmah dekodira i reprodukuje.

Glavnu prednost VoIP sistema predstavlja to što jedan poziv, nikada, ne zauzima ceo link, već se kroz isti link mogu slati paketi više različitih korisnika. Ukoliko pak, samo jedan korisnik ima potrebu za korišćenjem linka, koristiće ga samo onoliko dugo koliko je potrebno za prenos njegovih paketa.

Uz pomoć novijih tehnologija sada je moguće detektovati situacije kada nastupa tišina (momenti kada se ne vrši prenos glasa), pa u tom momentu potrebno je smanjiti ili obustaviti slanje RTP paketa koji ne nose koristan sadržaj. Na ovaj način sigurno se povećava efikasnost skupih linkova. Za vreme tišine, paketi drugih korisnika će biti prenet linkom.

Upoređivanjem dve tehnologije prenosa glasa, VoIP i tehnogolije fiksne telefonije, dolazimo do zaključka da se korišćenjem VoIP ostvaruje znatna ušteda, kako od strane korisnika koji neće plaćati punu cenu iznajmljivanja linka, tako i od strane provajdera kojima se investicije u telekomunikacionu opremu zamenjuju investicijama u mrežnu opremu gde postoji znatna razlika u ceni.

Ako uzimamo cenu za glavni kriterijum, zaključićemo da je VoIP nemerljivo bolja tehnologija prenosa glasa od tradicionalne fiksne telefonije. Međutim, korišćenjem mrežnih resursa, VoIP pored pogodnosti donosi i nove probleme, koji su poznati u računarskim mrežama.

Neki od najčešćih problema koji postoje kod upotrebe VoIP tehnologija, dok kod fiksne telefonije ne predstavljaju problem su :

• Raspoloživi propusni opseg (bandwith) – direktno utiče kako na broj simultanih poziva, tako i na izbor kvaliteta kodeka za kodiranje glasa

• Kašnjenje – veliki broj malih paketa, zahteva minimalno zadržavanje na zagušenim linkovima. To je veoma čest problem i zahteva definisanje QoS (Quality of Service)

5

• Gubitak paketa – VoIP koristi UDP nepouzdani način prenosa zbog velikog broja paketa. Zagušeni linkovi odbacuju pakete kako bi regulisali zagušenost. Za VoIP mora se definisati QoS

• Jitter – je nepoželjna varijacija nepredvidivih nepoželjnih efekata kao što su kašnjenja i gubici paketa. Može se redukovati implementacijom QoS-a.

• Echo – eho je čest problem u hibridnim okruženjima. Uglavnom se stvara kod konverzije A/D – D/A signala i u slučaju nepodešenih impedansi konvertera.

• Zaštita – je kod fiksne telefonije bila jednostavna, poseduješ kabl, vlastitu liniju koja se fiziči štiti. VoIP se oslanja na računarske mrežame pa je potrebno implementirati odgovarajuću zaštitu.

• Pouzdanost – koristi se zajednička infrastruktura sa računarskim mrežama. Za unapređivanje pouzdanosti koriste se iste tehnike, kao i kod računarskih mreža. Udvojena, paralelna infrastrukura, rezervni linkovi i sl.

• Prevođenje pulsnog pozivanja u DTMF ton – stvar od koje se gotovo odustalo kod VoIP tehnologija.

Arhitektura VoIP mreže

Kao i kod drugih tipova servisa koje koriste TCP/IP model prenosa podataka,

i za prenos podataka su definisane različite vrste protokola. Kako bi se optimizovala putanja između dve udaljene tačke, uveden je

koncept koji omogućava da se različitim putem i do različitih destinacija kreće signal za upravljanje pozivom (uspostavljanje i prekid veze, dogovor oko izbora kodeka,

6

registrovanje korisnika i sl.), a različitim paketi koji nose glas. Ovim postupkom se postiže to da centri za pozivanje (signaling call centri) mogu biti na lokacijama bilo gde u svetu, a da bitno ne utiču na kvalitet i brzinu VoIP telefonije. Tako, npr. možete iz Srbije osnovati pretplatnički odnos u Americi, pa kada preko VoIP-a zovete Srbiju, paketi signalizacije će otići do call centra u Americi i vratiti se do vas, ali paketi sa glasom će samo putovati od vas do onoga koga pozivate (neće ići preko servera u Americi).

� VoIP protokoli

Kako sva mrežna komunikacija koristi protokole – definisana pravila – u

komunikaciji između dva uređaja, tako i za VoIP postoji određena grupa definisanih protokola. Protokoli se stalno nadograđuju i unapređuju, ali neki od protokola koji se najviše koriste u VoIP komunikacijijama su H.323, SIP, IAX, RTP i sl.

Preovlađuje VoIP model prenosa koji postavlja koncept gde signalizacija i glas mogu putovati različitim putanjama. Među VoIP protokolima može razlikovati protokole za signalizaciju i protokole za prenos glasa.

Za prenos glasa kroz IP protokol uglavnom se koristi RTP (Real-time

Transport Protocol), koji pakuje kodirane pakete u sitne pakete i šalje ih UDP protokolom.

Ono što predstavlja problem kod RTP protokola je što se teško štiti, odnosno što se mora obezbediti određeni spektar UDP portova (npr. 10000-20000 UDP), pa je potrebno i ceo spekat propusiti na firewall-u. Ukoliko se propusti manji spektar, manji broj istovremenih poziva može biti uspostavljen. RTP koristi 2 UDP porta po pozivu, jedan za prijem, drugi za slanje VoIP paketa.

Kod signalizacije stanje je vrlo raznoliko. H.323 protokol je postavljen od strane ITU organizacije i predstavlja prvi

signaling protokol koji je komercijalno prestavljen i prihvaćen. U okviru ovog protokola razvili su se drugi podprotokoli koji definišu rad H.323 protokola. Tako, npr. H.225.0 definišu konstrukciju paketa za pozivanje, ukazivanje da li je video ili običan poziv i sl.

H.323 koncept

H.323 protokol se, kao i većina drugih, „usput“ razvijao. Tako brojni nedostaci, prvenstveno zaštita, NAT, i sl., su otklonjeni definisanjem novog protokola u

7

okviru H.323. Početna solucija H.323 protokola nije posedovala nikakvu zaštitu, naime, bilo je dovoljno poznavanje ip adrese call centra kako bi se inicirala veza. Ovaj način ostvarivanja komunikacije naziva se H.323 preko Gateway-a. Uvođenjem standarda H.323 Gatekeeper znatno je podignut kvalitet zaštite preko Call Admission Control mehanizma, i implementiran sistem za prevođenje broja telefona u IP adresu. Implementacijom Gatekeeper mehanizma ostvaruje se potrebna kontrola pristupa preko H.323 protokola, sprečava zagušenje mreže i podiže nivo sigurnosti kroz autentifikaciju.

Call Admission Control je mehanizam, često i poseban uređaj, koji ima sledeće zadatke :

• Sprečava preopterećenje VoIP mreže – odbijajući poziv ukoliko ne postoji dovoljno resursa za njegovo uspostavljanje.

• Kontroliše sav voice saobraćaj obezbeđujući mu potreban kvalitet servisa (QoS) markiranjem.

• Sprečava zagušenja postojećih resusra prosleđivanjem novih poziva na druge linkove.

• Ukoliko se koristi RSVP protokol za rezervaciju resursa duž čitavog puta mreže, vrši kontrolu nad raspolaganjem tih resursa i ne dozvoljava uspostavu veze ako rezervacija nije obavljena.

• Ukoliko je iz bilo kog razloga procesor preopterećen, ili postoje problemi na linku i sl., poziv ne može biti kvalitetno uspostavljen, CAC odbija poziv, čime se poziv upućuje drugom putanjom.

• Novije varijante predviđaju napredne sisteme autentifikacije korisnika i zaštite od ranjivosti raznih tipova napada, npr. DOS (Denial-Of-Service)

Zadatak H.323 Gatekeeper mehanizma je da vrši Call Admission Control funkciju u H.323 protokolu. Pored toga vrši prevođenje E.164 identifikacije (broja telefona) u IP adresu.

SIP (Session Initiation Protocol) protokol je protokol definisan od strane IETF

organizacije i, po svemu sudeći, komercijalno je potisnuo H.323 iz masovne upotrebe. SIP protokol je definisan dokumentom RFC 3261. Može koristiti protokole transportnog sloja: TCP, UDP, SCTP. Počevši sa razvojem 1996. godine na Kolumbijskom Univerzitetu, u novembru 2000. godine je prihvaćen za 3G standard za signalizaciju VoIP paketa.

8

SIP koncept

SIP je koncipirao sledeće komponente VoIP mreže : Krajnje tačke – su uređaji ili softwer, koji vrše inicijalizaciju ili prihvatanje

poziva, tj. vrše interakciju sa korisnikom. ENUM ili DUNDI - su dve tehnologije za prevođenje broja telefona u ip

adresu krajnje tačke ili gateway-a preko koga se može stići do kranje tačke. SIP Proxy – su sistemi za zaštitu putem autentifikacije, kao i Admission

Control upravljanje mrežnim resusrima. Proxy serveri obavljaju posao rutiranja saobraćaja, tj usmeravaju signaling pakete ka drugim proxy serverima koji poseduju zahtevane podatke tj. znaju koja ip adresa odgovara pozvanom broju telefona.

Međusobnom signalizacijom SIP Proxy servera postiže se mogućnost

mobilnosti. To znači možete zadržati isti broj telefona, a promeniti fizičku lokaciju. SIP protokol je potpuno definisan na logičkom nivou, pa je fizički nezavisno gde se nalazite.

9

SIP signalizacija

H.323 i SIP protokol zahtevaju određene mrežne predispozicije da bi

funkcionisale. Do skoro, ni jedan ni drugi protokol nije mogao da funkcioniše ako bi se jedna ili druga strana nalazila iza NAT servisa. Razlog je to što bi registratori beležili javnu IP adresu, preko koje se ne može direktno stupiti u kontakt sa krajnjim korisnikom. Pošto veći deo mreža koje imaju pristup internetu koriste NAT kao mehanizam za prevođenje privatnih u javne ip adrese, SIP je predvideo mogućnost NAT-ovanih adresa što je dugo bila glavna prednost nad H.323 protokolom. Danas i H.323 protokol ima svoje rešenje za NAT okruženje.

Postoje potrebe u VoIP saobraćaju, kada i RTP i signaling paketi treba da

putuju istom putanjom i do istog odredišta. To je česta situacija kada se međusobno povezuju call centri i uspostavljaju tzv. Trunk između svojih proxy i gateway servera. U tim situacijama komplikovano je to što moramo da vodimo računa u različitim portovima (TCP ili UDP) za SIP, RTP, ili H.323 protokol. Da bi preneli glas od tačke A do tačke B moramo otvoriti portove na firewall-u: od 10000-20000 UDP za RTP, 5060 za SIP, ili 1720 UDP za H.323, u svakom slučaju to je već širok spektar portova, plus što mora da se vodi računa o NAT konfiguraciji (da se poznaje javna IP ako se koristi privatna na serveru).

10

� Kodeci za pakovanje glasa

RTP protokol opisuje samo postupak prenošenja glasa kroz mrežne resurse. Postupak pakovanja glasa u pakete je definisan različitim standardima za digitalizovanje i kompresiju zvučnih podataka ili govora.

Standardi za digitalizovanje i kodiranje glasa, popularno kodeci (codecs), doživljavaju stalne modifikacije i nove revizije, varijante.

Još od uvođenja ISDN digitalnih linija, tema korišćenja različitih algoritama

za kodiranje i pakovanje glasa je bila često glavna tema na telekomunikacionim seminarima.

G.711 (PCM) kodek je standard propisan od strane ITU još 1972. godine. G.711 predstavlja algoritam za pulsno-kodnu modulaciju signala frekvencije glasa, koji se (odmerava) sampluje 8000 puta u sekundi. Ovaj standard je definisan iz dva dela.

µ-law, koji se koristi u Severnoj Americi i Japanu i A-law koji se koristi u ostalom delu sveta.

G.711 A-law je standard definisan za kodiranje glasa u računarske potrebe. U algoritmu se uzimaju 13 bita sempla i konvertuje u 8 bita. Karakteristike A-law kodeka su sledeće :

• Frekvencija semplovana : 8 kHz • 64 kb/s bitrate (8 kHz x 8 bita po samplu) • Za izvršavanje algoritma potrebno je oko 0,125 ms • Zadržava talasastu formu signala • Sadrži algoritme za oporavak izgubljenih paketa • Mehanizmi za detektovanje tišine ili generisanje udobnog šuma

Algoritmi za kodiranje, kodeci, su ocenjivani od strane ITU na osnovu postavljenih kriterijuma. Kao rezultat dobija se PSQM ocena (Perceptual Speech Quality Measure). Za G.711 (PCMA) A-law kodek ocena je 4.45 u idealnim uslovima a, 4.11 u realnim uslovima.

GSM kodek tipa Adaptive Multi-Rate (AMR) je kodek koji je prihvaćen na

3G algoritam za kodiranje glasa oktobra 1998. godine. GSM (AMR) kodek koristi 160 semplova dužine 20 milisekundi. Koristi sledeće tehnike prilikom kodiranja:

• Algebraic Code Excited Linear Prediction (ACELP) • Discontinuous Transmission (DTX) • Voice activity detection (VAD) • Comfort Noise Generation (CNG)

Kod GSM (AMR) kodeka koristi se AMR_12.20 mod koji ima bitrate 12.20 kbit/s. Kako bi bio otporniji na kvalitet mreže, GSM je smanjio kvalitet glasa.

Generalne karakteristike GSM kodeka su : • Frekvencija semplovanja 8 kHz/13-bita, filtrirano na između

200-3400Hz • Bitrate 12.20 kbit/s • Veličina okvira ~ 244 bita • Vreme izvršavanja algoritma 20 ms

11

• Kompleksnost algoritma je 5, u odnosu na to da je G.711=1 a G.729=15

• PSQM=4.14 za idealno i 3.79 za realno okruženje G.729 kodek postoji u različitim varijatama, skoro sve su komercijalnog i

zatvorenog tipa, pa je neophodno platiti licencu za korišćenje. G.729a je kodek koji koristi kompleksne matematičke funkcije kako bi našao

što bolji koder za pakovanje glasa. Pravno korišćenja ovog kodeka reguliše firma SIPRO. Karakteristike kodeka su sledeće :

• Frekvencija samplovanja 8 kHz/16 bita (80 semplova sa 10 ms) • Fiksirani bit rate na 8 kbit/s 10 ms okvir • Veličina okvira 10 bajta po 10 ms • Vreme izvršavanja 15 ms po okviru • G.729 koristi kompleksni oblik ACELP-a • Kompleksnost se ocenjuje ocenom 15 • PSQM=4.04 za idelano i 3.51 za realno okruženje

Kriterijum izbora kodeka za pakovanje glasa je raspoloživ bandwith. Ako se

radi o LAN okruženju, gde postoji 100 mbps ili brža mreža, bez razmišljanja se treba opredeliti za najkvalitetniji G.711 A-law kodek. U nedoumici možemo biti samo ako postoje WAN linkovi koji trpe određena zagušenja. Tad treba izabrati optimalan kodek koji daje zadovoljavajući kvalitet uz manju konzumaciju propusnog opsega od G.711. U realnosti, za ove slučajeve, najbolje se pokazao G.729 kodek koji ne smanjuje drastično kvalitet zvuka, za razliku od GSM kodeka. Problem predstavlja to što u nekim zemljama da bi se koristio mora da se plati licenca.

Zaključak : • LAN okruženjima koristiti SIP ili IAX sa G.711 a-law kodekom • WAN potencijalno zagušenim okruženjima koristiti IAX sa G.729

kodekom

Prikaz kvaliteta prenesenog glasa različitim kodecima

12

� QoS Glavna mana VoIP tehnologije naspram klasične – fiksne – telefonije je to što

VoIP saobraćaj nije jedini saobraćaj na zauzetim linkovima. Zbog toga dolazi do različitih problema, kao što su kašnjenje, odbačeni paketi. jitter i sl.

Da bi Komunikacija glasom bila dovoljno kvalitetna, slično klasičnoj telefoniji, mora se obezbediti odgovarajući uslovi za prenos VoIP paketa. QoS ili Quality of service prestavlja metod sprovođenja politike obezbeđenja linka potrebnog za kvalitetan prenos glasa. Ispravnom QoS politikom se može rešiti problem prouzrokovan korišćenjem istih linkova za raznolik sobraćaj.

Istim linkom prenose se paketi različitih tipova podataka. Mrežni uređaji, po

defaultu, ne raspoznaju tipove paketa, niti znaju koje su važnosti paketi koje prenose. Različite aplikacije imaju različite potrebe korišćenja mrežnih resursa. Tako,

recimo do skoro je važilo da HTTP služi za prenos sajtova, zahteva brz odziv, prenos malih fajlova, i vrlo kratko opterećuje linkove. Sa druge strane, FTP i Peer-to-peer programi zahtevaju veliki propusni opseg i imaju znatno veće vreme opterećenja linka (duže se prenose podaci), dok brzina odziva je skoro nebitan faktor. Potrebe svih aplikacija možemo klasifikovati na sledeći način :

• Potreba za propusnim opsegom (bandwith) – kako bi se napravila optimalna organizacija i raspodela mrežnih resursa, potrebno je odraditi proračun zahtevanog propusnog opsega. Ukoliko se zakupi manji propusni opseg nego što je potrebno, moglo bi da dođe do degradiranja performansi mrežnog saobraćaja, što se prikazuje lošijim rezultatima sledećih stavki.

• Količina odbačenih paketa (dropped pakets) – usled velikog broja, znatno utiče na TCP konekcije zahtevajući da se paket ponovo pošalje, čime se povećava kašnjenje. Kod UDP konekcije može a ne mora da se primeti. Najčešće se javlja usled „zagušenosti“ linka, tj. kada je potreban veći propusni opseg nego što je zakupljen.

• Kašnjenje (delay) – uvek postoji, makar zbog potrebe mrežnih uređaja da prebace bitove sa port-a na port. Velika kašnjenja prouzrokuje efekat „sporosti“ mreže. Kašnjenje se prikazuje u milisekundama (ms). Velika kašnjenja, između ostalog, nastaju kada je link zagušen, usled ponavljanja paketa, ako se primenjuje neadekvatan algoritam za redove i sl. Prilikom pregledanja sajtova, ako je odziv 1000 ms (1 sekund) stičemo utisak da internet radi veoma sporo.

• Jitter (džiter) – predstavlja nepredvidivu nepravilnu promenu u kašnjenju. Izražava se u procentima promena kašnjenja. Usled velikog jittera dolazi do istog efekta kao kod velikih kašnjenja.

• Pristizanje paketa bez pravilog rasporeda – kako je na internetu postupak preusmeravanja paketa potpuno automatizovan, tako ne možemo predvideti kojim putem će naši paketi proći do kranje destinacije. Kod slanja večih podataka, šalje se više manjih paketa. Ne mora da znači da će ti paketi putovati istim putem i da će stići prema rasporedu, kojim su poslati. Zbog ovog efekta može doći do velikog

13

kašnjenja ili gubitka nekog od paketa, što bi kod TCP prouzrokovalo ponovno slanje tog ili grupe paketa.

• Greške – se dešavaju zbog što fizički linkovi i sami uređaji nisu savršeni. Dešava se da se u prenosu paket minimalno izmeni, promeni jedan bit, zbog čega se smatra da je taj paket sa greškom i odbacuje se na sledećem uređaju. O odbacivanju se obaveštava pošaljilac kako bi se paket poslao ponovo. Ovaj efekat povećava kašnjenje zbog potrebe ponovnog slanja paketa.

Zadatak tehnologije Quality of Service (QoS) je da uvede red, odnosno

raspored, i da sprovede plan u organizaciji mrežnog sobraćaja. Time se postiže bolja iskorisćenost veoma skupih linkova, bez zakupa većeg i skupljeg propusnog opsega. Pravilnom planskom organizacijom mrežnog sobraćaja postže se da se aplikacijama sa različitim potrebama mrežnih resursa pruža ono što je potrebno za efikasan rad. Primer je to da ne moramo da se odreknemo Peer-to-peer programa, koji uvek maksimalno opterećuju propusni opseg ako hoćemo brz odziv HTTP strana. Dovoljno je samo na pravi način definisati QoS.

Prvi korak kod postavljanja QoS politike je određivanje potreba različitih

aplikacija. Sledeća tabela prikazuje zahteve nekih aplikacija :

Bandwith Odbačeni paketi Kašnjenje Jitter Ne pravilni

raspored paketa Greške

HTTP >128 kbps < 10 % < 500 ms < 1000 - - P2P Max - - - - - VoIP > 64 kbps < 1 % < 150 ms < 100 utiče na kašnjenje -||- Video > 300 kbps < 1 % < 100 ms < 100 -||- -||- Mission Critical

~ 45 kbps < 1 % < 50 ms < 10 -||- -||-

Drugi korak za uspostavljanje QoS politike je markiranje različitih tipova

saobraćaja i svrstavanje u odgovorajuće grupe. Pakete možemo razvrstati na osnovu više kriterijuma :

• Odredišna IP adresa • Izvorišna IP adresa • Odredišni port • Izvorišni port • Tip protokola • Vrednost DSCP ili TOS bitova • MAC adresa

Korišćenjem nekog od pomenutih parametara raspoznavanja tipa paketa, na

ulazu u router (ili switch), vršimo markiranje konekcije, tj. paketa. Time postižemo da uređaj razaznaje različite vrste aplikacija čije pakete prenosi.

14

Ukoliko ne postoji relacija poverenja između routera i drugog mrežnog uređaja, onda ne možemo očekivati da će markiranje DSCP vrednosti biti odrađeno na tom drugom uređaju, već se remarkacija DSCP vrednosti vrši na samom routeru uz pomoć drugih pomenutih kriterijuma razlikovanja paketa aplikacija.

Differentiated services ili DiffServ (DSCP) je polje u okviru TOS bitova

unutar IP hedera koje služi da odredi klasu servisa, tj. obeležava zahteve određene aplikacije, kako bi mrežni uređaji, kroz koji plaket prolazi, pokušali da pruže servis kakav se očekuje (malo kašnjenje, što manje gubitka paketa i sl.)

Za određivanje klase servisa koristi se 6 bitova u okviru IP hedera. Prva 3 bita se koriste za određivanje prioriteta saobraćaja (IP Precedence), tj. definisanje grupe klasa zahteva za uslugom. Svaka od te tri grupe sadrži više različitih nivoa klasa.

Sveobuhvatno gledajući, DSCP vrednosti možemo podeliti u tri posebne klase:

• Best-effort (BE) – klasa DSCP=0 gde se ne obezbeđuje nikakva garancija u transortu, ovo je ujedno i default klasa

• Expedited Forwarding (EF) – namenjena za saobraćaj koji zahteva minimalno kašnjenje i minimalan broj izgubljenih paketa

• Assured Forwarding (AF) – namenjen za sve druge klasifikacije saobraćaja

Paketi koji se prenose u realnom vremenu, kao što su VoIP i Video conference

komunikacije, zahtevaju minimalno kašnjenje i minimalan broj odbačenih paketa. Zbog toga, prilikom markiranja preporučljivo je da se tim paketima dodeli DSCP vrednost EF.

� Asterisk open-source platforma Težnja ka razvoju novih tehnologija dovodi do evolucije telefonije u smeru

VoIP-a. Kao i u velikom broju drugih projekata, i VoIP je svoj početak bazirao na open-source projektima pojedinaca.

Programer Mark Spencer je programer poznat po projektima GAIM, open-source AOL instant messager, linux projekti kao što su l2tpd i Cheops Network User Interface. Godine 1999. Mark se našao u problemu. Hteo je da nabavi za svoju firmu PBX (Personal Branch eXchange), telefonsku centalu, sa mogućnošću telefonske sekretarice, razgovora sa drugom ekspoziturom bez plaćanja telefonskog računa i drugih stvari što bi se moglo očekivati od nekih naprednijih centrala. Takvi proizvodi su već postojali na tržištu plasirani od strane najvećih telekomunikacionih kompanija, kao što su Siemens, Ericsson i dr. Cena PBX sistema, koji bi zadovoljili potrebe njegove firme bila je približno jednaka ceni bubrega na crnom tržištu (citirao Mark Spencer).

Kao programer sa velikim brojem projekata, koji su odlično prihvaćeni u open-source krugovima, rešio je da sam napiše software koji bi zadovoljio njegove potrebe. 5. decembra 1999. godine je objavljen Asterisk 0.1.0. Sadržao je samo centralnu (core) varijantu sa dokumentacijom za razvijanje dodatnih modula, čime je otvorem put drugim učesnicima open-source udruženja. 23. septembra 2004. godine izdata je prva stabilna Asterisk 1.0 verzija kada je održana i prva Asterisk user i developer konferencija.

15

Asterisk 1.0 je prva open-source VoIP PBX platforma na tržištu. Broj programera koji su uvideli prednost ovog projekta i pridružili se razvijanju, rastao je nepredvidivo brzo. Težilo se razvijanju što većeg broja modula, proširivanju funkcionalnosti softwerske PBX platforme kako bi se dostigle mogućnosti najskupljih PBX sistema poznatih proizvođača.

Veliki odziv programera za razvoj dodatnih modula nije usporio ni razvoj centralnog sistema (core) pa je već 17. novembra 2005. objavljen Asterisk u verziji 1.2 sa preko 3000 revizija koda centralnog sistema. Ova verzija je u okviru centralnog softverskog sistema donela i mnoge nove napredne mogućnosti, kao što su novi VoIP protokoli (IAX), veća proširivost različitim tipova Trunk linkova, DUNDI, ENUM, i sl.

Asterisk 1.2, kroz svoje manje revizije se i danas koristi kao najrasprostranjeniji softverski PBX sistem. Verzija 1.2 predstavlja testiranu i najstabilniju verziju ovog projekta.

Poslednja verzija Asterisk 1.4 je predstavljena 27. decembra 2006. godine. Najnovija verzija donosi kompletno restruktuiranje centralnog sistema, procesa upravljanja pozivima, modulima, servisima, konfiguraciji, CDR (logovima), i optimizaciji resursa. Napravljena je bolja podrška hardverskim modulima za konekciju sa ne VoIP tehnologijama. Zbog velike promene naspram verzije 1.2, dosta postojećih modula je zahtevalo reviziju, pa čak i kompletan redizajn. To je i glavni razlog što do danas verzija 1.4 još uvek nije potisnula verziju 1.2 iz upotrebe. U ovom momentu gotovi se svi moduli plasiraju u varijanti Asterisk 1.2 i Asterisk 1.4.

Trenuto je u pripremi i varijanta 1.6. Došla je do svoje beta 8 faze.

Digium – Asterisk zaštitni znak

Mark Spenser je napisao Asterisk za firmu poznatu pod imenom Digium, koja

sada predstavlja rukovodioca projektom Asterisk. Firma Digium se bavi proizvodnjom i prodajom hardvera za prilagođavanje ne VoIP tehnologija, Asterisk PBX platformi. Najpoznatiji proizvodi su više-portni analogni modemi, kao i više-portni BRI ili PRI uređaji preko kojih se Asterisk platforma može povezati sa klasičnom telefonijom.

Digium u svojoj ponudi ima i Asterisk Enterprise verziju sistema za direktnu primenu u industrijskim sistemima. Ovaj proizvod nije open-source i sadrži dodatne mogućnosti kao što su text-to-speach, prepoznavanje govora, samo kontrola opterećenosti, mogućnost sprovođenja stotine hiljada istovremenih poziva.

Još jedna grana kojom se Digium bavi, a prilično je cenjena, predstavlja njihov edukativni centar. Organizuju se kampovi, seminari, radionice, simulacije, trening centri i sertifikacije. Sertifikat Digium Certified Asterisk Professional je prilično cenjen kada se radi o open-source VoIP PBX primeni.

16

� Asterisk kanali (channels)

Kanali (channels) - kao termin predstavljen je u Asterisk platformi da definiše

vezu telefona sa centralom. To znači da se kreira jedan kanal za komunikaciju jedne tehnologije sa centralom.

Asterisk poseduje drajvere za različite tipove kanala čime poseduje podršku za različite tehnologije. Standardna je podrška za VoIP tehnologije, kao što su IAX, SIP, MGCP i H.323. Pored toga, poseduje i kanal drajvere za hardverske modeme za Zaptel uređaje FXO i FXS portove, ISDN modeme BRI, PRI, i dr.

Svaki telefon, bilo hardverski ili softverski konektuje se na kanal centrale. Neke tehnologije zahtevaju tom prilikom autentifikaciju kako bi proverile korisnika. Centrala, takođe, mora da uspostavi kanal sa drugom centralom ako je predviđena mogućnost međusobne komunikacije preko VoIP-a.

Ugrađeni drajveri za kanale koji dolaze uz Asterisk : • Agent – kontrola poziva od strane ovlašćenih lica • Console – Linux konzola drajver preko koga se pristupa zvučnoj

kartici • H.323 – kanal za korišćenje H.323 protokola • IAX, IAX2 – kanal za korišćenje IAX protokola • Local – interni kanal za ponovni prolazak kroz kontekste (context) • MGCP – Media Gateway Protocol još jedan od VoIP protokola • mISDN – kanal za pristup mISDN drajveru za ISDN modeme • NBS – kanal za Network Broadcast Sound • phone – Linux telefon kanal • SIP – kanal za SIP protokol • Skinny - kanal za Cisco Skinny protokol • Gtalk – kanal za Google Talk protokol • VOFR – kanal za VoiceOverFrame ADTRAN protokol • VPB – kanal za Vicetronics kartice za konektovanje na običan telefon • Zap – kanal za Zaptel modeme

Pored ovih kanala postoji i veliki broj drugih, kao i dokumentacija kako

možete napraviti kanal za svoju tehnologiju, bilo da se radi o softverskoj – VoIP – ili hardverskoj podršci.

Ako imate neki svoj uređaj, za koji želite da šaljete komande preko Asterisk platforme, treba napraviti drajver za Asterisk preko kanala. Postoji detaljna dokumentacija koje metode drajver treba da implementira i kako da pozove. Tu je i veliki broj primera, pošto je kompletna platforma open-source, lako se tumače jednostavni kanali i od njih pravi ono što nam je potrebno.

Programiranjem drajvera uspostavljate konektivnost vašeg uređaja sa Asterisk platformom. Ostaje konfiguracija ili postavljanje konteksta kako tj. kad se koristi vaš hardver.

17

� Aplikacije

Zahvaljujući objekto orjentisanom modelu asterisk platforme pruža se mogućnost stepenastog razvoja i nadogradnje sistema. Korišćenjem do tada ugrađenih funkcija u centralni sistem mogu se napraviti određene aplikacije koje se mogu integrisati u centrali i vršiti procesiranje nad raspoloživim resursima.

Svaki dolazni, odlazni, lokalni i bilo koji drugi poziv izvršava se kroz veći broj aplikacija, komandi koje se izvršavaju na asterisk platformi. Aplikacija je sve od sitne komande Goto do vrlo kompleksnih, kao što je Voicemail ili Conference call.

Postoji ogroman broj aplikacija koje su već ugrađene u Asterisk platformu, ali i veliki broj onih koje su napisane od strane drugih programera koji indirektno učestvuju u razvoju.

Aplikacije, tj. komande se koriste u različitim skriptama i u okviru Dialplan-a. Asterisk platforma predviđa smeštanje dialplan-a u konfiguracioni fajl extensions.conf odake se sprovodi skript dialplana za različite situacije.

Neke od aplikacija su :

• Authenticate – služi za verifikaciju korisnika • ChannelRedirect – preusmeravanje kanala na dialplan • SendDTMF – slanje DTMF tona • Transfer – preusmeravanje poziva na određeni interni lokal • Wait – sačekati određeno vreme • WaitMusicOnHold – sačekati određeno vreme uz muziku na čekanju • Answer – „podigni slušalicu“ ako zvoni • Busy – odgovori sa zauzetim signalom • Congestion – odgovori sa signalom o zagušenom linku • Dial – pozovi i spoj na trenutni kanal • DISA – spoljni pristup internom sistemu • Hangup – „spusti slušalicu“ • Ringing – pošalji signal da zvoni • SetCallerID – postavi identifikaciju poziva, predstavi se kao ... • EnumLookup – pogledaj ENUM bazu • Macro – pozovi Macro skript • NoOp – zapiši poruku u Log fajl • AGI – izvrši spoljnu aplikaciju, PHP, Perl, Bash, Java .... • Goto – skoči na određeni deo skripta • Set – postavi vrednost kanal ili globalne promenljive • Math – izračunaj matematički izraz • Echo – reprodukuj na izlaz ono što se izgovori na ulazu • MP3Player – pusti određenu MP3 pesmu • SayUnixTime – izgovori vreme na sistemu • SayDigits – izgovori brojeve • Monitor – snimaj razgovor u fajl

18

• VoiceMail – ostavi poruku na govornoj pošti • Queue – prebaci kanal u red za čekanje

Ovo su samo neke od aplikacija koje su integrisane u Asterisk platformu. Bilo koja nova mogućnost koja može dograditi sistem i prilagoditi specifičnim potrebama, se može takođe napraviti.

Za programiranje aplikacija postoji dokumentacija, kao i svi primeri aplikacija koji su ugrađeni u platformu. Potrebno je samo koristiti strukture koje objektni model Asterisk platforme postavlja i napraviti algoritam za potrebno procesiranje.

� DialPlan

Dialplan je mesto koje povezuje sve aplikacije, kanale, module, kodeke u jednu celinu. Dialplan je najčešće smešten u jedan text fajl extensions.conf . U tom fajlu povezane su akcije sa ekstenzijama (lokalima). Svaka ekstenzija pripada nekom kontekstu, bilo da je to default kontekst ili posebno definisani kontekst. Specijalni konteksti se kreiraju, npr. dolazni SIP kontekst, lokalni pozivi, pozivi između ekspozitura, ili već drugačije namenski podeljeno. Kada se korisnik konektuje na Asterisk, on mora biti dodeljen nekom kontekstu, određenom u conf fajlu, Asterisk konsultuje dialplan sa namerom da sazna kako i šta da uradi sa tim pozivom. Centrala proverava prava korisnika, da li on ima prava da pozove taj broj, da li su slobodne linije kojima treba da uputi poziv, izvrši poziv i spoji ta dva kanala.

U dialplanu podešavaju se sve akcije za koje je Asterisk predviđen da odreaguje. Može se napraviti i takav kontekst koji će funkcionisati samo u određenom delu dana, vezan za sat. Kontekst može da obuhvati i drugi kontekst čime se stvara mogućnost da se dialplan znatno iskomplikuje.

Zahvaljujući ovoj činjenici potrebno je da se bude vešt u dialplan skriptingu kako bi se postavila željena konfiguracija.

Tako se, na primer, može postići: • Prebacivanje na govornu poštu ukoliko se korisnik ne javi u roku od

20 sekundi • Prebacivanje jednog poziva na više učesnika u konferenciskoj vezi • Prebacivanje poziva na drugu Asterisk centralu • Blokiranje poziva neželjenih ili neidentifikovanih pozivalaca • Na osnovu broja koji je neko zvao treba rešiti na koji interni lokal

prebaciti poziv • Kreirati redove za čekanje i dopustiti ljudima da biraju ko će

odgovoriti na poziv Dialplan se sastoji od statičkih konfiguracija i skripti, tj. konteksta. Statičke

konfiguracije podržavaju dve vrste promenljivih General i Globals. Postoje specijalne vrste konteksta koje se nazivaju Makroi, čiji je naziv macro-ime. Makroi se koriste kod situacija kada jedan postupak ponavljamo na više mesta, kao kod procedura u

19

programskim jezicima. Svaki kontekst se nalazi unutar dialplan-a kao ime konteksta uokviren uglastim zagradama [context], što pomalo podseća na strukturu .ini fajla u Windows-u.

Pisanje skripti unutar konteksta vrši se bilo pozivanjem nekog drugog konteksta ili komandi na seledeći način :

exten => extension,priority,Command(parameters)

Reč exten=> predstavlja ključnu reč za početak komande i koristi se kod svake komande.

Extension – predstavlja kod, broj ekstenzije, koji može biti ili konkretan broj ili patern kojim se definiše opseg ekstenzija.

Priority – predstavlja redni broj izvrašanja komandi u jednom kontekstu. Kada se neka aplikacija ili skript prebaci na neki kontekst, ako nađe ekstenziju sa prioritetom 1 onda izvršava komandu, a ako ne izlazi iz tog konteksta. Nakon izvršavanja prioriteta 1 ide se na na komandu sa prioritetom 2 pa tako redom.

Command – je aplikacija koju poziva skripta kada se zadovolji broj ekstenzije i prioritet.

Parameters – paramteri koji se prosleđuju određenoj aplikaciji, pojedine aplikacije ne zahtevaju parametre

Prlikom izbora ekstenzije mogu se koristiti paterni na sedeći način :

• X – predstavlja bilo koji broj od 0-9 • Z – predstavlja bilo koji broj od 1-9 • N – predstavlja bilo koji broj od 2-9 • [125] – prihvata samo brojeve u zagradi • [2-5] – prihvata samo brojeve u opsegu kao u zagradi • . – džoker koji prihvata jedan ili više brojeva • ! – džoker koji prihvata nula ili više brojeva (prihvata sve)

Da bi određena ekstenzija bila patern mora početi sa znakom _ (underscore). Npr: _001800NXXXXXX – prihvata sve brojeve koji počinju sa 001800 pa neki

broj veći od 1 i još 6 drugih cifara _61XX – prihvata sve četvorocifrene brojeve koji počinju sa 61 _7[04-9]XX – prihvata sve četvorocifrene broejve koji počinju sa 70, 74, 75,

76, 77, 78, 79. _9011. – prihvata broj koji počinje sa 9011 i ima još cifara _9011! – prihvata broj koji počinje sa 9011, a ne mora da ima još cifara _# - prihvata ako je otkucana samo # _*. – prihvata ako je otkucana * i još neki broj Primer jednog konteksta bi izgledao ovako : [interni-korisnik]

20

exten => 123,1,Answer exten => 123,2,Playback(welcome) exten => 123,3,Voicemail(44) exten => 123,4,Hangup

Sa ovakvim kontekstom u dialplanu, telefon koji je registrovan da koristi kontekst [interni-korisnik] kada nazove broj telefona 123, skočiće na prioritet 1, tj. komandu Answer, čime će biti izvršena aplikacija Answer, i Asterisk će dati signal telefonu da je podignuta slušalica.

Nakon toga skače se na prioritet 2 gde se izvršava aplikacija koja pušta na kanal zvuk welcome.wav smešteno u fajl strukturi Asterisk platforme.

Posle toga izvršava se aplikacija koja nudi mogućnost da se ostavi poruka u govornoj pošti u sandučetu broj 44.

Kada se izvrši i ova komanda, aplikacija Hangup govori Asterisk-u da prekine vezu.

Kako više nema komandi, završava se rad u ovom kontekstu, i pošto ne postoji kontekst u koji bi se Asterisk vratio (nad kontekst) prekida se rad sa tim kanalom.

Ukoliko ne postoji kontekst za određenu operaciju ili korisnika, Asterisk

pristupa kontekstu [default] i sledi skript tu opisan. Najčešće se u ovaj kontekst ulazi samo greškom ili neovlašćenim pristupom, tako da se ovde na fin način samo prekida veza i beleži log.

Globalne pormenljive se deklarišu u kontekstu [globals] u formi : VAR1=5 ZTR=SIP/123 Kako bi povećali čitljivost konfiguracionog fajla dialplan-a extensions.conf

fajl se može podeliti na više manjih fajlova. Tako, recimo, možemo kreirati fajl extensions_local.conf u kome bi se nalazio skript koji definiše ponašanje ekstenzija u lokalu, tj. kako međusobno da pozivaju ekstenzije na istoj centrali.

Potrebno je samo u glavnom dialplan konfigruacionom fajlu inkludovati novi kreiran fajl sa komandom #include „extensions_local.conf“ .

Macro se može ilustrovati sledećim primerom : [globals] PHONE1=Zap/1 PHONE2=SIP/6002 [macro-zovi] exten=>s,1,Dial(${ARG1},20,t) exten=>s,2,Voicemail(u${MACRO_EXTEN}) exten=>s,3,Hangup exten=>s,102,Voicemail(b${MACRO_EXTEN}) exten=>s,103,Hangup [local]

21

exten=>6601,1,Macro(zovi,${PHONE1}) exten=>6602,1,Macro(zovi,${PHONE2}) U primeru vidimo definisanje globalnih promenljiva PHONE1 i PHONE2.

Definisan je i Macro nazvan „zovi“ čiji je cilj da prihvati prosleđen argument i pokrene Dial aplikaciju za izvršenje pozivanja. ${ARG1} je promenljiva koja se prenosi kao argument kojim je pozvan Makro.

Kada se poziv uspešno obavi, odnosno završi, izvršava se komanda sa prioritetom 2, tj. pozivalac se šalje na govornu poštu sa brojem „uX“ (X je broj telefona sa koga zovemo).

Nakon ostavljanja poruke u govornoj pošti prekida se veza. Ukoliko je veza zauzeta ili iz nekog drugog razloga poziv nije uspešno

uspostavljen, aplikacija Dial skače na 101+prioritet sa kog je izvršen Dial, tj. na prioritet 102.

Tu se ponovo izvršava govorna pošta na lokalu „bX“ (gde je „b“ znak da je linija zauzeta, pa će to biti rečeno u govornoj pošti, a X broj telefona sa kog zovemo).

Na kraju glavni kontekst, kontekst local koji poziva Makro zovi pa broj telefona preko globalne promenljive, zove jedn broj ako je uneto 6601 ili drugi ako je uneto 6602.

Primetićete da su oba prioriteta na 1. To je zato što se radi o različitim ekstenzijama.

� Asterisk i VoIP protokoli Ideja Asterisk platforme je bila da pruži podršku VoIP protokolima kao što su

SIP, RTP, H.323. Na SIP protokolu je bazirana komplenta početna ideja o softverskim ekstenzijama, VoIP telefonima, i gateway adapterima za vezu sa klasičnim telefonima.

Pojam SIP Trunk linkova – linkova koji povezuju PBX sisteme, preko kojih se može preneti više istovremenih poziva – kao i SIP remote extensions linkovi – linkovi ka udaljenim lokalima, koji su možda fizički potpuno na drugom kraju sveta –koristi se od same ideje da se telefonija uzidgne na 3. nivo TCP/IP mreže. Za Asterisk platformu ovo je predstavljalo primarni koncept organizacije interlinkova i ekstenzija, tj. korisnika.

SIP podržava nezaobilaznu autentifikaciju i autorizaciju, tako da pruža mogućnost razlikovanja korisnika i evidenciju za potrebe računovodstva, tj. naplate usluga.

SIP je protokol za signalizaciju VoIP saobraćaja. On ne prenosi podatke, tj. glas kroz mrežu, već služi za razmenu kontrolne informacije između dva kraja koja razmenjuju pakete sa glasom. Glas se šalje mrežom RTP protokolom digitalizovanim nekim od kodeka.

SIP definiše različite vrste paketa, kao što su : • Registracija korisnika na PBX – autentifikacija i autorizacija • Poziv udaljene lokacije na uspostavu veze – invite • Prvihvatanje poziva – ack • Odbijanje poziva – cancel

22

• Prekidanje veze – bye • SIP dodatne metode za napredne funkcije

Proces uspostavljanja razgovora između tačaka A i B svodi se na sledeću

proceduru : • A instancira UTP socket za SIP protokol na portu 5060 i generiše

paket sa zahtevom za uspostavu veze. • Taj paket pošalje na UTP socket sa ip adresom centrale na port 5060. • Duž celog puta, od A do B, centrale uspostavljaju Trunk link sa porta

5060 na port 5060 šaljući zahtev (invite) za uspostavljanje veze. • Kada zahtev stigne do korisnika B, ukoliko želi da prihvati poziv,

instancira dva UTP socketa spremna za prihvatanje RTP protokol paketa.

• B nakon toga vraća poruku svojoj centrali da želi da prihvati poziv (SIP odgovor ACK).

• Opet poruka od B do A putuje duž svih trunk linkovima centrala od B do A.

• A prihvata ACK poruku i kreira dve UTP RTP sesije (jedna za odlazni govor, druga za dolazni), ka korisniku B na portu koji je B otvorio za prijem glasovnih paketa.

Zbog potrebe kontrole glasovnog saobraćaja, Asterisk platforma je predvidela

mogućnost da u slučaju razovora A i B, RTP paketi ne putuju samostalno od A do B, već kroz centralu. Jedna od primena ove kontrole je mogućnost snimanja svih ili određenih razgovora. To se postiže na taj način što se na mesto adrese B u povratnom ACK paketu postavlja adresa centrale i ona postane posrednik.

Praksa u upotrebi SIP protokola u današnjim računarskim mrežama je

pokazala određene nedostatke kada se SIP koristi u NAT-ovanom okruženju. Kao zakrpa za te nedostatke, SIP je dobio određene podstandarde.

Još jedan problem je bio teško rešiv kod SIP protokola, a to je kada se vrši interlinkovanje centrala. Kada postoji potreba da se i glas i signalizacija „provuče“ kroz isti Trunk, i kroz perzistentan socket link.

Sa aspekta sigurnosti, možemo primetiti, kako bi VoIP korišćenjem SIP protokola funkcionisao kako treba, moramo otvoriti odlazne i dolazne UDP portove 5060, kao i opseg odlaznih i dolaznih portova potrebnih za RTP protokol. Broj portova za RTP zavisi od željenog broja simultanih razgovora pomnoženih sa 2, jedan za odlazne pakete drugi za dolazne.

Udruženje koje je radilo na razvoju Asterisk platforme predložilo je poseban protokol, koji je prvobitno bio namenjen samo interkonektivnosti centrala.

Inter Asterisk eXchange ili IAX je protokol namenjen za kreiranje Trunk linkova između više VoIP centrala.

Od definisanja do danas IAX je doživeo samo jednu veliku modifikaciju, kada je dobio oznaku IAX revizija 2 ili IAX2.

23

Glavne karakteristike IAX protokola su :

• Koristi samo jedan UDP port 4569 i za signalizaciju i za prenos glasa • Podržava PKI baziranu autentifikaciju • Poseduje jitter bafer u samom drajveru

Trunk je veza između dva učesnika u VoIP saobraćaju. Prilikom uspostavljanja trunka IAX koristi propusni opeg samo toliko koliko mu je u tom momentu potreban, za razliku od drugih protokola koji koriste RTP i drže rezervisan propusni opseg i ako ne koriste link.

IAX trunk podržava prenos više signalnih i govornih kanala preko jednog trunka smanjujući time nekoristan saobraćaj (overhead) IP paketa.

IAX uvek šalje DTMF posebnom signalizacijom, ne integrišući ton u pakete za prenos glasa.

Jitter bafer je dodat iz razloga otpornosti VoIP razogovora na velike varijacije kašnjenja, tj. jittera. Loš kvalitet veze se ne može bezuslovno kompenzovati, zato ova tehnologija ima samo uslovnu primenu. Tako recimo, kod ADSL tehnologije prenosa podataka jitter bafer može biti veoma koristan jer kompenzuje jitter povećavajući kašnjenje. Ako je jitter relativno mali, upotrebom bafera potpuno će nestati. Ako je sa druge strane veliki, kompenzacijom ništa nećemo dobiti jer će kvalitet prenosa glasa i dalje biti loš zbog velikog kašnjenja.

Praksa je pokazala da verovatno najznačajnija predost IAX protokola nad drugim VoIP protokolima je upravo otpornost na probleme koje stvaraju NAT servisi.

Kada postoji potreba da se koristi IAX protokol u NAT-ovanom okuženju treba povesti računa o sledećim stvarima :

Konzistentan NAT – predstavlja zahtev da NAT servis vodi računa o konekcijama tako što će koristiti uvek isto zamenjivanje izvorišne adrese i porta u toku jedne konekcije. Današnjim ruterima je ovo opcija koja je po default-u upaljena.

Timeout konzistentnog NAT-a – predstavlja još jedan parametar o kome se mora voditi računa. IAX koristi UDP protokol, što znači da NAT servis ili router nema stanja konekcija kroz flagove, već vrši evidinciju na osnovu poslednjeg paketa. Ukoliko prođe neki timeout period, a ne stigne novi paket, briše se zapis mapiranja i gubi se konzistentan NAT. Ovaj problem rešava se podešavanjem registracionog perioda, tj. perioda na osnovu kog će dve tačke razmenjivati informacije o registraciji i time sačuvati konzistentnost na NAT servisu. Na MikroTik ruteru ovaj period je 3 mintua.

� IAX vs SIP

Praktična testiranja su pokazala da se upotrebom IAX protokola, koji istim

kanalom prenosi i signalizaciju i pakete sa podacima, postiže ne zanemarljivo veća efikasnost kod prenosa većeg broja razgovora nego kod SIP protokola koji koristi odvojene RTP kanale za svaki razogovor.

Za jedan razgovor IAX koristi isti kanal za signalizaciju i prenos glasa i jedne i druge strane, dok se za signalizaciju kod SIP-a koristi isti kanal sa obe strane, ali se za prenos glasa formira još po jedan kanal. Rezimirano izgleda da IAX formira jednu konekciju, a SIP tri konekcije.

24

Prednost jedne konekcije predstavlja lakša kontrola saobraćaja od strane mrežne administracije.

Sa stanovišta sigurnosti, za IAX komunikaciju dovoljno je na firewall-u otvoriti jedan port UDP 4569, dok je za SIP komunikaciju potrebno otvoriti jedan UDP 5060 za signalizaciju i opseg UDP adresa za prenos glasa. Za RTP se najčešće odvajaju UDP portovi od 10000-20000. Bezbednost mreže može biti znatno narušena ukoliko se kroz firewall propusti veliki broj portova.

Zbog efikasnosti i što pouzdanijeg prenosa, IAX za signalizaciju koristi informaciono-baziran enkodiran protokol, za razliku od SIP-a koji koristi ASCII enkodiran protokol.

Za potrebe asterisk baziranih korisnika, IAX predviđa prenos specijalnih informacija čime bi se omogućila posebna usluga za privilegovanu grupu korisnika.

Vreme je pokazalo, konfigurisanje i stabilnost IAX Trunk linkova znatno

uspešnije nego što je to slučaj kod SIP protokola. Kontrola stanja, merenje saobraćaja, otklanjanje problema su dosta lakši nego što je to slučaj u SIP baziranom okruženju.

Asterisk platforma je predvidela mogućnost korišćenja IAX protokola i za potrebe krajnjih korisnika tj. ekstenzija, čime je olakšan posao onima koji žele da pružaju usluge telefonije krajnjim korisnicima. Korisnik se može bez problema priključiti na svog IAX provajdera, nema potrebe za proverom okruženja da li je NAT ili ne.

Kao pravilo važi da ako funkcioniše ping ka centrali, verovatno će raditi i odlazni pozivi. Za dolazne pozive potrebno je podesiti router, tj. firewall da prosleđuje jedan jedini port UDP 4569 na odgovarajuću radnu stanicu.

IAX2 protokol, i jednostavnost njegove implementacije i konfiguracije, naterala je proizvođače hardverskih i softverskih telefona da počnu sa implementacijom ovog protokola. Softverski telefoni kao što su: Idefisk (sada Zoiper), FireFly i neki drugi komercijalni, u najboljem svetlu prezentuju kako je jednostavno podesiti vaš računar za telefoniranje preko VoIP provajdera. Proizvođači hardverskih VoIP telefona su izbacili IAX varijante čekajući odziv na taj potez.

I ako je IAX protokol uglavnom vezan za Asterisk platformu, njegov algoritam je open-soruce pa je implementacija dozovljena i u drugim komercijalnim sistemima.

Novitetima koje je doneo IAX protokol u konceptu, pokrenulo je razmišljanje u grupama koje se bave VoIP razvojem od samog početka.

� Evolucija VoIP koncepta

Početak razvoja VoIP tehnologija obeležio je koncept odvojene signalizacije i

toka podataka. Razumljivo, glavna namena ovog koncepta je da dve veoma udaljene tačke uspostave komunikaciju najbližom putanjom. Nažalost, ovo odlično zvuči samo na papiru, u praksi je nešto drugačije.

Svedoci smo određenih neravnopravnosti u podeli internet resursa. Uvek je bilo i biće situacija gde će raspoloživost kvalitetnih linkova zavisti od cene koju smo spremni da platimo. Ako je tako, da li je onda ispravan koncept „najkraća putanja je uvek i najbolja“ ?

25

ISP provajderi se međusobno razlikuju po kvalitetu linkova i ceni koju traže za ustupanju istih. Razmotrimo sledeći slučaj kao na slici: kompanija može da plati provajderu A, koji ima nižu cenu i lošiji kvalitet linkova prema internetu, usuge interneta; provajderu B, koji ima odlične linkove i visoku cenu, plati samo usluge telefonije (prenos VoIP paketa). Da li je onda i dalje bolje probati ostvariti direktnu vezu sa udaljenim korisnikom, ili je možda bolje razgovor vršiti posredstvom provajdera sa dobrim linkom ?

FirmaISP A

ISP B

ISP Z1Company

ISP C ISP D

Flat rate1000 din/mesecno

1000 din/GB

50ms

Najkraća putanja

Najbolja putanja

Poređenje najbolje i najkraće putanje

Promena koncepta, koji dovodi IAX protokol, je vrlo dobro prihvaćen, prvobitno u krugovima gde se koristi asterisk platforma, a ubrzo i od strane proizvođaća VoIP hardvera.

Direktna relacija između korisnika i provajdera VoIP usluga je postala mnogo bolje rešenje tako da se to odrazilo čak i na uobičajni koncept koji primenjuje SIP. SIP ima mogućnost da šalje i signalizaciju i glas istom putanju, ali do pojave IAX-a je relativno zanemarena.

VoIP provajderima je instalacija klijenata vrlo pojednostavljena pojavom IAX Softphone-a, koji se mogu koristiti bez potrebe za nekom komplikovanom konfiguracijom na strani klijenta, čak i uobičajnom NAT-ovanom okruženju.

IAX protokol je napravljen sa namenom da poveže više asterisk platformi preko VoIP mreža, mada, već danas ima potpuno drugi smisao. Njegova jednostavnost u konceptu, implementaciji i rukovanju, znatno olakšava plasiranje VoIP tehnologije. Iako SIP protokol pruža znatno više mogućnosti kod nekih specijalnih zahteva, IAX mu žestoko parira kod upotrebe na relaciji provajder-korisnik i provajer interlink.

� Dodatne mogućnosti Asterisk platforme Koncept razvoja Asterisk platforme se sastoji iz više nivoa razvoja. Kao što

sam pomenuo, osnovni centralni sistem postoji sa ciljem da pruži osnovne mogućnosti za dalji razvoj i unapređivanje sistema novim modulima, aplikacijama i skriptama.

Najbolji način da se prikaže za kakav razvoj je ovakva platforma predviđena, predstavlja veliki broj primera i konkretnih implementacija, koji se dobijaju uz samu platformu.

Neke od dodatnih mogućnosti, koji se dobijaju uz standardni paket Asterisk platforme, su :

• Alarm – aplikacija preko koje možete zakazati alarm, tj. buđenje u određeno vreme. Sama aplikacija može da bude toliko agresivna da vam ne dozvoljava

26

da prekinete vezu dok nije sigurna da ste se probudili, npr. aplikacija će nastaviti da vas zove dok ne odgovorite tačno na pitanje o zbiru dva dvocifrena broja. Ovakva aplikacija može biti korisna za hotele ili „pametne kuće“.

• Blacklist – aplikacija za blokiranje nepoželjnih pozivalaca na osnovu CallerID promenljive, koja predstavlja broj onoga koji zove. Poziv može biti prekinut samo slanjem signala zauzeto ili izgovorom neke snimljene poruke.

• Blind Transfer – predstavlja mogućnost koja nedostaje „jeftinijim“ centralama. Preko ove aplikacije možete proslediti vezu drugom lokalu, bez potrebe da proveravate da li taj lokal želi da primi vezu.

• Call Monitoring – predstavlja aplikaciju koja dozvoljava ovlašćenim licima da „prisluškuju“ razgovor i aktiviraju aplikaciju za snimanje po potrebi.

• Call Parking – aplikacija predviđa mogućnost prebacivanja korisnika na čekanje dok određena grupa agenata ne prihvati poziv.

• Call Queueing – naprednija metoda za raspored poziva na čekanju. Ova aplikacija predstavlja vrlo kompleksan algoritam za raspodelu dolazećeg poziva. Posebno je pogodna za Call centre, gde postoji više zahteva za uslugom nego broj agenata. Pozivalac upada u određeni Queue gde čeka svoj red. Dok čeka sluša snimljenu muziku ili definisanu poruku. Queue može korisniku koji čeka da na određenom intervalu izgovori koji je na redu za operatera. Operateri, agenti, dobijaju poziv iz reda čim oslobode svoju liniju. Više agenata može prihvatiti pozive iz reda. U samoj aplikaciji možemo definisati koliko da se sačeka pre nego što ponovo zazvoni telefon agentu koji je tek završio razogovor. Slična implementacija kod drugih telefonskih sistema košta veoma mnogo. Queue je jedna od aplikacija koja znatno donosi prednost u ceni Asterisk platformi naspram durgih telefonskih PBX sistema.

• Call Recording - predstavlja mogućnost snimanja svih ili određenih razgovora koji se obavljaju na centrali. Iniciranje snimanja se vrši odabirom DTMF koda u toku razogovora. Razgovor se snima u Waw ili MP3 formatu na centrali.

• Call Transfer – predstavlja aplikaciju za prebacivanje veze na način na koji smo navikli kod standardnih centrala. Kada dobijemo poziv, postavimo pozivalaca na čekanje. Tom prilikom on čuje muziku ili nasnimljenu poruku, zatim nazovemo osobu kojoj treba da prebacimo vezu, proverimo da li želi da prihvati poziv. Ako druga osoba želi da prihvati poziv (kaže da želi da prihvati), zamolimo je da ostane na vezi i mi spustimo slušalicu. Ako ne želi, sačekamo da spusti slušalicu nakon čega ponovo dobijamo na vezi pozivalaca, saopštavamo mu da prebacivanje ne može biti obavljeno.

• Call Waiting – aplikacija pruža mogućnost koja nam je poznata u mobilnoj telefoniji. Aktiviranjem CW usluge za određenog korisnika, omogućićemo to da i ako korisnik trentuno razogovara, zvoniće mu telefon na drugog slobodnoj liniji. Bez ove opcije, pozivalacu se vraća poruka da je broj trenutno zauzet.

• Calling card – u svetu su vrlo popularne kartice, koje se prodaju kao pre-paid, a pružaju mogućnost jeftinijeg razogovra sa određenim zemljama u inostranstvu. Ova aplikacija pravi podršku za takve pozive.

27

• Conference Bridging – predstavlja aplikaciju za obavljanje konferencijskih razgovora sa velikim brojem lokala. Uz pomoć nje direktor može obaviti sastanak sa svim zaposlenima u firmi iz svoje fotelje.

• Database integration – podrška za integraciju sa različitim bazama podatka. Uglavnom se koristi za povezivanje drugih aplikacija sa bazom podataka.

• Dial by Aame – predstavlja aplikaciju sličnu našem 988 servisu. U aplikaciju unesemo ime osobe koju želimo da pozovemo, a ona pozove traženi broj.

• Direct Inward System Access – DISA – predstavlja aplikaciju koja se koristi za specijalne potrebe poziva od spolja kroz centralu, kao da se nalazite unutar firme. Npr. u jednoj firmi se nalazi Asterisk PBX koji pokirva lokale te firme. On ima izlazne VoIP i ZAP (Telekom) kanale. Ako imam potrebu da od kuće nazovem nekoga u ime firme, ili da koristim VoIP Trunkove firme za razogovor sa inostranstvom, mogu pristupiti DISA aplikaciji i dalje zvati kao da sam u firmi. DISA predviđa mogućnost zaštite preko CallerID ili preko specijalne PIN šifre.

• Distinctive Ring – predstavlja mogućnost različitog zvuka zvona za određene pozivalace. Tako npr. može se namestiti da drugačije zvoni ako zove direktor što je znak da morate odmah da se javite ili npr. kada se u „pametnim kućama“ povezuje interfon sa centralom, drugačije zvoni telefon ako je poziv stigao sa interfona.

• Distributed Universal Aumber Discovery – DUNDI – predstavlja sistem za razrešavanje broja telefona u ip adresu centrale. Ovaj sistem je napravljen sa namerom da se međusobno povežu centrale, a da pritom ni ne poznaju koji brojevi se nalaze na kojoj centrali. To je postignuto tako što se na centralnim DNS serverima podigne ENUM polje koje razrešava broj telefona u IP adresu centrale preko koje se može dobiti. Tada saobraćaj, umesto da ide default rutom, ide VoIP-om direktno ka centrali i poziv je potpuno besplatan.

• Do Aot Disturb – opcija koju može aktivirati svaki lokal kada želi da spreči sve dolazne pozive. Pozivalac dobija poruku da je korisnik nedostupan.

• Fax Transmit and Receive – se postiže kroz dodatne aplikacije koje koriste elektronsku varijantu kodiranja i prenosa Faxa. Pitanje i problemi Fax-a u VoIP-u su još uvek aktuelna tema, i za sada ne postoji univerzalno 100 % uspešno rešenje, pa se predviđa zanemarivanje tehnologije Fax-a u korist mail-a. Kao među rešenje postoji aplikacija HylaFax koja se može uz pomoć Iaxmodem projekta integrisati sa Asterisk platformom.

• Protocol Conversion – aplikacija za spajanje više različitih tehnologija prenosa. Tako je moguće ostvariti razgovor između korisnika na SIP i korisnika na IAX2 tehnologiji, kao i između ZAP (Telekom) i korisnika na nekoj VoIP tehnologiji.

• Roaming Extensions – predstavlja mogućnost da se korisnik loguje na svoj lokal uz pomoć definisane šifre, preko interneta, tako da sa praktično neograničene fizičke udaljenosti vrši pozive kao da se nalazi tamo gde je centrala. Uz pomoć te mogućnosti ovlašćena osoba može i od kuće da vrši razgovore kao da je u firmi.

28

• Spell / Say – aplikacija je prilagođena za spelovanje ili izgovaranje određenih reči, slova i brojeva. Za sada postoji podrška za mali broj jezika, ali ne i za srpski jezik.

• Streaming Media Access – mogućnost da reprodukuje na telefonsku liniju ono što se nalazi na ulazu u zvučnu kartu. Recimo, kada postoji potreba da se radio signal prenese na Music on hold, tj. kada se neko nalazi na čekanju da čuje radio.

• Talk Detection – predstavlja aplikaciju koja je u stanju da u razgovoru detektuje kada neko izgovori neku jednostavnu reč i reprodukuje neki fajl. Tako recimo, ako izgovorite „hello“ , centrala može uzvratiti „hello to you“.

• Time and Date – predstavlja aplikaciju koja čita datum i vreme sa centrale i izgovora na engleskom jeziku.

• Transcoding – je sistem za prevođenje glasovnih paketa kodiranih jednim kodekom u drugi kodek. Ova operacija ponekad zahteva veliko procesorsko vreme, pa kada postoji potreba za velikim brojem simultanih poziva uz konvertovanje kodeka, potrebno je obezbediti PBX sa jakom procesorskom snagom.

• VoIP Gateways – predstavlja aplikacije koje već imaju podršku i konfiguracije ka određenim VoIP provajderima. Pojednostavljuje povezivanje Asterisk platforme na VoIP telefoniju. Ubačeni provejderi nisu optimalni za našu zemlju zbog velikih kašnjenja do njihovih centrala.

• Voicemail – predstavlja aplikaciju za govornu poštu. Voicemail je obeležje „skupih“ centrala, a nalazi se u svakom paketu Asterisk platforme. Uz pomoć ove aplikacije možete svakoj ekstenziji dodeliti sanduče za poštu. Kada je lokal nedostupan ili zauzet, pozivalac dobija poruku o tome i može ostaviti svoj snimak, svoju poruku. Svaki korisnik može pristupiti svojoj govornoj pošti, preslušati svoje poruke, izmeniti pozdravnu poruku, obrisati ili sačuvati stare poruke.

• Voicemail to mail - jedna o pogodnosti koje donosi Asterisk platforma. Vaše poruke u govornoj pošti ne morate preslušavati preko govornog automata i gubiti vreme na izbor opcija, možete jednostavno primiti snimak na svoj mail. Taj snimak primate istog momenta kada pozivalac ostavi poruku, a poslušavate kada ste u mogućnosti. Poruka će biti poslata u WAV ili MP3 formatu.

• Web Voicemail Interface – ako ni mail ne zadovoljava vaše zahteve za preslušavanje, možete preslušati snimkove preko Web interfejsa. Tu se pored spiska zapisa o ostavljenim poruka sa tačnim datumom kad je poruka stigla i informacijama ko je ostavio, nalazi i lista ostvarenih dolaznih i odlaznih poziva izvršenih sa tog lokala.

29

� Aplikacija za automatsko pozivanje

Često se susrećemo sa problemom u telefoniji da je određeni broj telefona konstantno zauzet. Urgentnost nekog poziva se često usklađuje sa strpljenjem potrebnim da se dobiju takve veze. Najčešće su u pitanju pozivi ka Ambasadama, nekim Info Centrima i sl.

Asterisk platforma je vrlo programabilna, što ukazuje da možemo napraviti aplikacije za različite specifične potrebe.

Moj cilj je bio da napravim aplikaciju koja će vršiti automatsko pozivanje teško dostupnih brojeva.

Početak istraživanja radi pronalaženja rešenja za zadati problem, predstavlja tumačenje sistema od strane centralne jedinice Asterisk platforme (core). Asterisk core koncipira izlazne pozive preko procesa za izlazne pozive.

Kreiranje takvog procesa mora da se obavi na neki od sledećih načina : • preko Dial aplikacije • preko Manager konzole • preko Call fajlova

Dial aplikacija se poziva skriptom iz extensions.conf fajla. To znači da se

kompletan program implementira u okviru skripta. Međutim postoji problem što se skript izvršava u okviru istog kanala, odnosno da prekida rad kada se kanal prekine.

Na taj način apliacija radi samo dok smo mi na vezi. U trenutku kad spustim slušalicu skript se prekida.

Menager konzola je vrlo koristan modul u okviru Asteirsk platforme koji

omogućava određeni broj API poziva od strane aplikacija pisanih u drugim programskim jezicima. Praktično možemo napisati bilo kakvu aplikaciju, implemetirati u nju API pozive za Asteirsk platformu i manipulisati radom centrale odatle.

Menager konzola je sposobna da prati različite događaje (Event) i o tome izveštava našu aplikaciju. Sposobna je da upravlja kanalima, što znači da šalje određene komande, modifikuje skripte, kreira i ubija kanal, tako da praktično upravlja radom centrale.

Za moju aplikaciju za automatsko pozivanje pokušao sam da izbegnem upravljanje preko nekog trećeg softvera, jer u tom slučaju komplikujem proces ispravljanja grešaka i smanjujem stabilnost sistema uvođenjem još jednog interpretera.

Prilikom razvoja Asterisk platforme predviđena je mogućnost iniciranja

poziva i preko .call fajla koji je smešten u određeni pool direktorijum. Definisana je putanja /var/spool/asterisk/outgoing kao putanja do pool

direktorijuma u kome se mogu nalaziti fajlovi za odlazne pozive. Definisana je tačna struktura fajla koji se analizira i prevodi u proces za

pozivanje. Fajl mora imati .call ekstenziju. Fajl je tekstualne strukture i može sadržati sledeća polja :

• Channel: <channel> - predstavlja opis kanala preko kog treba izvršiti izlazni poziv.

30

• CallerID: *ame <number> - predstavlja identifikaciju pozivalac, uprincipu korisno je samo kod VoIP poziva

• MaxRetries: <number> - maksimalan broj pokušaja ne računajući prvi pokušaj

• RetryTime: <number> - broj sekundi između pokušaja • WaitTime: <number> - broj sekundi koliko se čeka na

uspostavljanje veze, ukiliko istekne poziv se smatra neuspešnim i pokušava ponovo

• Account: <number> - ako je potreban specijalan broj naloga za korišćenje privilegovanih trunkova

Kada se poziv uspostavi bitni su sledeći parametri: • Context: <context-name> - Skoči na odgovarajući kontekst u

extensions.conf fajlu • Extension: <ext> - U kontekstu na odgovarajuću ekstenziju • Priority: <priority> - U ekstenziji na odgovarajući prioritet • Set: - se koristi za prenos promenljive kroz fajl u kontekst, piše se u

formi putanja=/etc/asterisk/fajl • Application: - umesto slanja na određeni kontekst, proces može

pozvati određenu aplikaciju, ovde se stavlja ime aplikacije • Data: - podaci koji se prosleđuju aplikaciji

Kod Chanell promenljive se koristi tačan naziv kanala sa brojem telefona koji

zovemo. Tako npr. za poziv preko voip-a koristimo IAX2/32165 ili IAX2/212.200.18.230 ili SIP/212.200.18.230/32165. Za poziv na fiksni telefon ZAP/1/988, 1 predstavlja broj linije ako imamo više izlaznih linija.

Formiranom fajlu sa odgovarajućom strukturom se promeni ime u npr. 123412.call i premesti u /var/spool/asterisk/outgoing. Asterisk će bukvalno u roku od par milisekundi početi da obrađuje fajl, kreirati proces i vršiti poziv.

Da bih napravio dinamični call fajl napravio sam skript u bash-u koji generiše

call fajl na osnovu moji ulaznih parametara. Skript izlega ovako : make_callfile()

{

extension="$1"

phone_number="$2"

context="$3"

CALLFILE=$(cat <<-EOF1

Channel: local/$phone_number@from-internal

CallerID: AutoDial <$phone_number>

MaxRetries: 40

RetryTime: 60

31

WaitTime: 45

Context: $context Extension: $extension

Priority: 1

Set: Info=$extension-$phone_number)

name="$CALL_SPOOL_DIR"/$(date +%YAaVM%S)-$phone_number.call

echo "$CALLFILE" >> $name

chown root /$name

chmod 777 /$name

mv /$nome /var/spool/asterisk/outgoing

}

ASTERISK_CFG="/etc/asterisk"

CALL_SPOOL_DIR="/etc/asterisk"

make_callfile "$1" "$2" "$3"

Skript sam nazvao redial.sh. Pozivanjem skripta generiše se fajl sa

jedinstvenim imenom koje sadrži vreme, datum, i broj koji pozivam u $home lokaciji profila.

Zatim se u fajl učitava struktura koja je potrebna Asterisku da kreira poces. U Channel polje unosi kanal Local, koji predstavlja logički kanal za pronalaženje najbolje putanje kroz dial-plan. Local/broj_telefona@from-internal kaže, pronađi najbolju putanju za pozivanje tog broja telefona prolazeći kroz glavni kontekst (koji postavlja FreePBX).

Auto dialer pokušava zvati maksimum 40 puta čekajući do 60 sekundi između poziva, a na uspostavljanje veze čeka do 45 sekundi. Tako auto-dialer radi maksimalno oko sat vremena kada se aktivira.

Ukoliko uspešno uspostavi poziv ili čak ne uspe da uspostavi poziv posle makimalnog broja pokušaja, on skače na kontekst definisan ulaznim paramterom, kao i na odgovarajuću ekstenziju (ekstenziju pozivalac).

Kako bih vodio računa ko je koga zvao, preko paramtera Set prenosim promenljive o tome. Info=$extension-$phone_number pokazuje koji je broj koga zvao.

Tako napunjenom fajlu podešavamo privilegije tako da sigurno bude čitljiv iz Asterisk-a i premeštamo u pool lokaciju.

Ukoliko ne počne obrada fajla, to znači da je fajl loše struktuiran, ne može da

se pročita ili nije loadovan modul pbx_spool.so. U ovom momentu sam delimično završio projekat automatskog pozivanja. Uz

pomoć skripte mogu pokrenuti proceduru za poziv koja će nakon dobijene veze proslediti na moj lokal. Pozivam skriptu sa redial.sh 125 988 from-internal. Međutim, ova skripta radi samo ukoliko je pozovem iz komandne linije. Da bih dobio pravu funkcionalnost moram je uvrstiti u dial plan.

32

Napravio sam poseban skript koji se poziva preko include iz extensions.conf. Skript sadrži sledeće komande:

exten => _*5.,1,SetVar(BOX=${EXTEA:2})

exten => _*5.,n,DBdel(auto/${BOX})

exten => _*5.,n,saydigits(${BOX})

exten => _*5.,n,Playback(beep)

exten => _*5.,n,system(/etc/asterisk/redial.sh ${CALLERID(num)} ${BOX} autodial)

exten => _*5.,n,Hangup

Sve komande se odnose na ekstenziju sa paternom *5. što znači da kada neko

pozove broj koji počinje sa *5 i imaju još cifara, centrala počinje izvršavanje ove skripte. Prvo se izvršava komanda sa prioritetom 1 koja kaže smesti u promenljuvu

BOX vrednost ekstenzije (koju zovemo) ali bez prva dva znaka (pošto su *5). Umesto da dalje koristim brojač prioriteta, koristim univerzalnu promenljivu prioriteta n, koja se sama inkrementuje kad je pozovem na mestu prioriteta. Zbog toga druga komanda koju izvršavam je DBdel jer je odmah u sledećem redu ispod 1. prioriteta.

DBdel briše iz lokalne baze podataka zapis ukoliko već postoji postavljen autodialer. To je zaštita koju sam postavio da bih se osigurao od duplikata.

Sa trećom komandom pozivam aplikaciju koja čita unete brojeve korisniku, kako bi proverio da li je ispravno uneo autodial broj. Ako korisnik prekine vezu za vreme diktiranja, program se prekida.

Četvrta komanda šalje signal beep kako bi korisnik znao da je prihvaćen njegov zahtev za autodial.

Peta komanda je upravo komanda koja pokreće bash skriptu sa odgovorajućim parametrima. Prvi parametar je broj pozivalaca, drugi broj koji zove, a treći je kontekst u koji treba da se vrati, tj. kontekst autodial.

Poseban kontekst povratka sam napravio kako bih onoga koga sam zvao, kada dobije vezu, uputio u to da malo sačeka dok se ne javi pozivalac.

Skripta konteksta autodial izgleda ovako : [autodial]

exten => _X.,1,Set(DIAL_OPTIOAS=m(autodial)Ww)

exten => _X.,n,Set(TRUAK_OPTIOAS=m(autodial)Ww)

exten => _X.,n,Goto(from-internal,${EXTEA},1)

exten => failed,1,Set(fb=${DB(auto/${CUT(Info,,1)})})

exten => failed,n,GotoIf($["${fb}"!="40"]?nista)

exten => failed,n,Aoop(Javi neuspelo autopozivanje)

exten => failed,n,DBdel(auto/${CUT(Info,,1)})

exten => failed,n,Set(EXT=${CUT(Info,,1)})

exten => failed,n,Set(BR=${CUT(Info,,2)})

exten => failed,n,Wait(2)

exten => failed,n,system(/etc/asterisk/redial.sh ${BR} ${EXT} autodial-back)

33

exten => failed,n,Goto(stop)

exten => failed,n(nista),Set(DB(auto/${CUT(Info,,1)})=$[${fb}+1]) exten => failed,n(stop),Aoop(Failed br ${br})

Ovde razmatram dva slučaja. Prvi, ako je poziv uspešno uspostavljen, a drugi

ako autodialer nije uspeo da uspostavi vezu nakon svih pokušaja. U svakom slučaju, kontrola se vraća skriptu u autodialer kontekst.

Ukoliko je veza uspešno uspostavljena, izvršava se ekstenzija na broju onoga ko je zadao da se automatski poziva, na broju pozivalaca. Ako nije izvršava se skripta na specijalnoj failed ekstenziji.

Kada je poziv uspešno uspostavljen, postavljam kanalne promenljive DIAL_OPTIOAS=m(autodial)Ww i TRUAK_OPTIOAS=m(autodial)Ww tako da koristi muziku dok se ne javi druga strana. m(autodial) kaže koristi muziku iz klase muzika autodial. U autodila klasi muzika sam postavio jedan .mp3 fajl u kome se nalazi poruka da su dobili sistem za automatko pozivanje i da malo sačekaju, a u pozadini je smirujuća muzika.

Sa trećom komadnom šaljem ostatak obrade na default skriptu za obradu internih poziva. Time autodialer završava svoj program uručujući poziv onome ko ga je prvi put pokrenuo.

Da bi aplikacija bila celokupna, nedostaje mi samo još sistem koji će voditi

računa do kog pokušaja sam stigao i koji će obavestiti korisnika kad ne uspe autodialer da dobije.

U okviru default koneksta moje skripte dodao sam podršku za poziv samo *5 broja.

exten => _*5,1,Set(fb=${DB(auto/${CALLERID(num)})})

exten => _*5,n,GotoIf($["${fb}"!=""]?10)

exten => _*5,n,Playback(you-must-first-dial)

exten => _*5,n,saydigits(*5)

exten => _*5,n,Playback(and) exten => _*5,n,Playback(number)

exten => _*5,n,Goto(kraj)

exten => _*5,10,Playback(call)

exten => _*5,n,Playback(card-number)

exten => _*5,n,SayAumber(${fb})

exten => _*5,n(kraj),Hangup

Prva komanda kaže da se u fb promenljivu smesti vrednost iz lokalne baze

podataka ako postoji poziv sa tog lokala, koji je broj poziva. Druga komanda proverava da li je uopšte postavljeno neštu u fb, ako nije znači da ne postoji autodial proces, ako jeste onda je to neki broj. Ukoliko jeste postavljen fb, skače se na prioritet 10, gde se izgovara „Trenutni pokušaj je“ pa broj fb i prekida veza. Ako ne postoji proces, sistem izgovara „Morate prvo pozvati *5 i broj“ i prekida vezu.

34

Problem obaveštenja ukoliko nije uspešno izvršen autodial poziv je rešen u okviru autodial konteksta, sa failed eksntenzijom.

Ponovo se uzima fb promenljiva iz baze podataka za lokal koji je u Info postavljen za pozivalaca. Skripta proverava da li je fb došao do pokušaja broj 40. Ako nije povećava se fb broj u bazi za 1 i pokušava ponovno pozivanje. Ukoliko jeste, beleži log da je neuspešno autodial pozivanje. Briše zapis u lokalnoj bazi. Postavlja promenljive pozivalaca i broja koji poziva sačeka par sekundi i poziva izvršenje redial.sh skripte ali pritom se zamene mesta pozvalaca i broja koji se poziva, sa kontekstom autodial-back.

Autodial-back kontekst izgleda ovako : [autodial-back]

exten => _X.,1,Answer

exten => _X.,n,DBdel(auto/${CUT(Info,,1)})

exten => _X.,n,Background(custom/AutoReturn)

exten => _X.,n,Hangup

Cilj ovog konteksta je da nazove lokal sa koga je prvobitno pokrenuta skripta i

saopšti mu snimljenu poruku, tj. da autodialer nije uspešno završio svoj posao.

� Aplikacija za trenutni kurs *BS

Glavnu prednost Asterisk platforme naspram drugih PBX telefonskih sistema predstavlja to što je platforma bazirana na PC računarskom sistemu, Linux operativnom sistemu. Ta činjenica nam pruža mogućnost da kombinujemo različite softverske tehnologije sa telefonijom u cilju obezbeđivanja što većeg broja korisnih mogućnosti.

Kako se kod Asterisk platforme radi o open-source udruženju ljudi koji preko interneta komuniciraju, razmenjuju iskustva, repozitorijume projekta i aplikacije, centrala bi trebalo da ima stalnu vezu sa svetskom mrežom.

Kombinujući najveću svetsku bazu podataka, kakav je internet i telefonija, možemo napraviti neograničen broj servisa koji mogu biti dostupni korisniku koristeći svakodnevni uređeaj najveće popularnosti – telefon.

Jedna od ideja prilikom korišćenja Asterisk baziranog rešenja bila je da zaposleni u firmi u svakom momentu mogu saznati gornji kurs Narodne banke Srbije.

Iz te ideje nastao je projekat koji je imao za cilj da predstavi laku i brzu implementaciju i interpretaciju internet baze podataka Narodne bane Srbije sa korisnicima telefonske centrale.

Zadato cilj je da se pozivanjem fiksnog broja telefona dobije servis koji će

istog momenta konsultovati gornji kurs na sajtu Narodne banke Srbije i izgovoriti kurs korisniku.

Za programiranje ove aplikacije rešio sam da koristim Asteriskov API, tj. AGI koji dozvoljava eksternim aplikacijama da kontrolišu uspostavljen kanal.

U okviru dialplan-a izvršena je integracija AGI skripta sa pozivanim brojem :

exten => _*83,1,Answer

35

exten => _*83,n,Playback(wait-moment)

exten => _*83,n,Agi(kurs.php) exten => _*83,n,Playback(goodbye)

exten => _*83,n,Hangup

U okviru skripta definisan je niz komandi koje treba da se izvrše kada se

nazove broj *83. Nakon uspostavljanja veze, prve komande, pozivalacu se izgovara poruka „Molim Vas sačekajte“. Nakon toga modul za AGI (Asterisk Gateway Interface) izvršava skript pisan u nekom od programskih jezika, kome je dozvoljena manipulacija kanalom poziva. Nakon izgovorenog kursa izgovora pozdravnu poruku i prekida vezu.

Srž ove aplikacije nalazi se u skriptu pozivanom od strane AGI modula. AGI modul sarži API kontrole za koje postoje adekvatne biblioteke za veliki broj programskih jezika (ActiveX, Java, Pascal, Perl, PHP, Python, Ruby, C, .NET, Bash).

Zbog jednostavnosti i integrisanog interpretera i veliki broj Linux OS-a izabrao sam PHP kao jezik za programiranje ovog skripta.

Programirane skripte treba postaviti u agi-bin direktorijum asterisk putanje. Konkretna putanja u kojoj se nalazi moja aplikacija je : /var/lib/asterisk/agi-bin/

Source skripta kurs.php je sledeći : #!/usr/bin/php -q <?php ob_implicit_flush(true); set_time_limit(6); $in = fopen("php://stdin","r"); $stdlog = fopen("/var/log/asterisk/my_agi.log", "w"); function read() { global $in, $debug, $stdlog; $input = str_replace("\n", "", fgets($in, 4096)); return $input; } function errlog($line) { global $err; echo "VERBOSE \"$line\"\n"; } function write($line) { global $debug, $stdlog; echo $line."\n"; } // glasvni program $client = new HttpClient('www.nbs.yu'); $client->post('/internet/latinica/scripts/kl.html', array( 'broj' => 'br.', 'godina' => '2006', 'datum' => date("d.m.Y"), 'vrsta' => '2', 'eksport' => 'html' )); $pageContents = $client->getContent(); $findstr='<td align="right" class="tablecell">'; $poz=strpos($pageContents,$findstr); $poz=$poz+strlen($findstr); $poz=strpos($pageContents,$findstr); $poz=$poz+strlen($findstr); $kupovni=substr($pageContents,$poz,7); $poz=strpos($pageContents,$findstr,$poz); $poz=$poz+strlen($findstr); $prodajni=substr($pageContents,$poz,7); $poz=strpos($prodajni,","); write("SAY DIGITS ".substr($prodajni,0,$poz)." X"); read();

36

write("STREAM FILE dot \"\" "); read(); write("SAY DIGITS ".substr($prodajni,-4)." X"); read(); sleep(2); write("SAY DIGITS ".substr($prodajni,0,$poz)." X"); read(); write("SAY DIGITS ".substr($prodajni,0,$poz)." X"); read(); write("STREAM FILE dot \"\" "); read(); write("SAY DIGITS ".substr($prodajni,-4)." X"); read(); sleep(1); fclose($in); fclose($stdlog); exit;

Citirani kod prikazuje funkcije potrebne za rad sa Asterisk AGI interfejsom.

AGI interfejs sadrži u sebi intergisane biblioteke za rad sa PHP interpreterom. Nakon definisanja funkcija za slanje podataka na AGI, čitanje sa AGI-a i upis

u log fajl, pristupa se pribavljanju i obradi rezultata sa sajta NBS. U kodu nedostaje definicija za objekat klase HttpClient. Međutim, isti se

može lako naći na internetu kao PHP open-source. Prvo se instancira objekat HttpClient sa paramterom sajta NBS. Nakon čega

se poziva metoda POST koja ima za cilj da određenoj internet strani prosledi parametre POST metodom. Sledeći parametri se prosleđuju : broj=br., godina=2006, datum=današnji_datum(dan.mesec.godina), vrsta=2, eksport=html. U stvari ovo je tačno ono što bi Web Client poslao NBS serveru da ste zatražili kursnu listu na današnji dan.

Nakon toga skript preuzima sadržaj strane u enkodiranom HTML formatu. Parsuje deo podataka iz tablice, koji nas interesuje (gornji kurs), <td align="right" class="tablecell"> .

Čisti string koji je dobio od Web servera od svih enkodovanih stvari koje bi smetale daljoj obradi. Razdvaja i smešta prodajni kurs u promenljivu Prodajni, kupovni u Kupovni. Posle toga počinje da šalje informacije kanalu kroz AGI protokol.

Prvo šalje komandu SAYDIGITS, koja aktivira aplikaciju za izgovor brojeva u nizu brojeva. Prethodno prodajni kurs je parsiran za deo do zareza i deo posle, tako da se prvo šalje komanda za izgovor brojeva do zareza. Zatim se šalje komanda „STREAM FILE dot“ koja zadaje kanalu da pusti Wav fajl dot.wav. Nakon čega se šalju cifre posle zareza. Ceo skript se ukoči na par sekundi, pa se procedura izgovora brojeva ponovi još jednom, potom skript završava svoj rad.

Nakon svake ispravno konstruisane komande u AGI protokolu, centrala šalje potvrdu da je komanda uspešno prihvaćena. To je glavni razlog zbog kojeg posle svake write() funkcije pozivam jednu read(), kako se ne bi gomilali odgovori.

� Aplikacija „Skiper“ Asterisk platforma nema sve mogućnosti koje su neki drugi, znatno skuplji

sistemi implementirali. Kako PBX sistemi poseduju mogućnost da imaju veliki broj Trunk linija različitih tehnologija, što je za korisnika potpuno transparentno, ponekad se teško može voditi računa kuda je neko izašao.

37

Neretko se dešavalo da iz firme neko nazove mobilni telefon, centrala takav poziv prosleđuje na uređaj koji preko GSM mreže uspostavlja poziv sa drugim korisnikom. Time se znatno redukuje cena razogovra jer razogovor mobilni-mobilni su povoljniji nego fiksni-mobilni, posebno ako je razgovor u okviru iste mreže.

Dešavalo se da pozivalac ne uspe da dobije osobu na mobilni telefon. Ali toj pozvanoj osobi ipak ostaje identifikacija da je poziv došao sa centrale. Često se zbog toga dešavalo da pozvani korisnik pozove broj centrale i traži onoga ko ga je zvao. U toj situaciji vrlo teško da će osoba zadužena za transfer veze znati kome treba da prebaci vezu.

Neke veoma skupe centrale poznatih proizvođača su rešile ovaj problem. Ideja je bila da napravim i ja svoje rešenje.

Asterisk platforma ima predviđen i ugrađen modul za CDR (Call Data

Recording). To je baza podataka koja čuva zapise o svim ostvarenim kanalima. Podatke, kao što su, ko je zvao, koga je zvao, sa koje tehnologije, preko koje tehnologije, koliko je trajao razogovor, kada je inicirana veza, da li je veza uspešno uspostavljena, koja je poslednja poruka koji je kanal razmenio i sl.

Koristeći te podatke mogu napraviti aplikaciju koja će u slučaju da dobijem povratni poziv, u nekom zadatom periodu, proslediti taj poziv direktno pozivalacu umesto da bude obrađen na default način.

Radi lakše konfiguracije Asterisk dialplan-a i ekstenzija koristio sam FreePBX open-source kontroler, integracija ovog rešenja u već integrisanu funkcionalonst FreePBX-a nije bio lak zadatak. Morao sam pronaći tačno određeno mesto, pod-kontekst, gde se mogu ubaciti a da ne remetim rad FreePBX-a.

U dialplan-u je trebalo obaviti par integracija. Prva i naj bitnija integracija je analiziranje poziva pre nego što se odradi default rutina obrade dolaznih poziva.

Srećom, prilikom projektovanja FreePBX je predvideo specijalne custom kontekste koje se pozivaju pre obrade njihovih default konteksta. To znači da je bilo dovoljno samo definisati neki od tih custom konteksta i on će biti izvršen pre drugih.

[from-pstn-custom]

exten => _X.,1,Gosub(skiper,s,1) Mada izgleda prilično jednostavno, dosta analize i dokumentacije je bilo

potrebno pre nego što sam došao do ove dve komande. [from-pstn-custom] ima za cilj da izvrši taj kontekst pre default konteksta [from-pstn] koji se izvršava za sve Trunk linije.

Jedina definisana komanda ima za cilj da za sve brojčane ekstenzije pokuša da izvrši Skiper proceduru. Gosub vrši poziv funkcije, tako da ako ne uspe nastavlja sa daljom obradom.

[skiper]

exten => s,1,Set(skiperbr=error)

exten => s,n,Agi(skiper.php,${CALLERID(num)})

exten => s,n,AoOp(Skiper : skiperbr=${skiperbr})

exten => s,n,GotoIf($["${skiperbr}"="error"]?nok)

exten => s,n,Set(__FROM_DID=s)

38

exten => s,n,Gosub(cidlookup,cidlookup_1,1)

exten => s,n,Gosub(app-blacklist-check,s,1) exten => s,n,GotoIf($[ "${CALLERID(name)}" != "" ] ?cidok)

exten => s,n,Set(CALLERID(name)=${CALLERID(num)})

exten => s,n(cidok),Aoop(CallerID is ${CALLERID(all)})

exten => s,n,Answer

exten => s,n,Playtones(ring)

exten => s,n,Goto(from-did-direct,${skiperbr},1)

exten => s,n(nok),Aoop(Izlazim iz Skipera)

exten => s,n,Return()

Skiper kontekst izvršava glavno procesiranje i proveru za potrebom

preskakanja default procedure. Kako AGI skripte bez problema pristupaju kanalnim promenljivama, prva

komanda podešava promenljivu skiperbr na error, da bih znao da li je skripta našla nešto. Nakon toga poziva se skiper.php AGI skript pisan u PHP jeziku smešten u

agi-bin direktorijumu, i prosleđuje mu se broj telefona pozivalaca. Beležimo u log fajl da je skiper završio sa skriptom i proveravamo da li je

vrednost promenljive jos uvek error ili je vratio broj telefona koji je zvao. Ako je vraćen broj telefona onog ko je inicirao prvi poziv, setujemo kanalnu

promenljivu __FORM_DID na s jer je to bitno zbog daljeg usmeravanja poziva. Izvršavamo proveru identiteta pozivalaca sa imenikom, proveravamo da li je pozivalac blacklistovan, vršimo korekturu CALLERID identifikacije. Psrihvatamo poziv i šaljemo mu signal da druga strana zvoni. Tek onda upućujemo dalji tok obrade na kontekst koji će ustvari izvršiti poziv. From-did-direct je kontekst koji na osnovu DID-a (s) prati default proceduru, međutim mi smo je presreli time što smo joj poslali argument da odmah nastavi sa pozivanjem broja koji se nalazi u promenljivoj skiperbr. Ukoliko iz bilo kog razloga ne uspe uspostavljanje veze sa drugom stranom, poziv se evidentira u logu i sa return vraća na default proceduru obrade dolaznog poziva.

Ako je vrednost promenljive i dalje error, znači da skiper nije našao zapis u bazi koji ukazuje da je taj broj pozivan u skorašnje vreme, evidentira to u log fajlu i nastavlja sa default procedurom obrade dolaznog poziva.

Skiper.php skripa izgleda ovako :

#!/usr/bin/php -q <?php ob_implicit_flush(true); set_time_limit(6); $in = fopen("php://stdin","r"); $stdlog = fopen("/var/log/asterisk/my_agi.log", "w"); function read() { global $in, $debug, $stdlog; $input = str_replace("\n", "", fgets($in, 4096)); return $input; } function errlog($line) { global $err; echo "VERBOSE \"$line\"\n"; } function write($line) { global $debug, $stdlog;

39

echo $line."\n"; } // parsiranmje ulaznih promenljiva while ($env=read()) { $s = split(": ",$env); $agi[str_replace("agi_","",$s[0])] = trim($s[1]); if (($env == "") || ($env == "\n")) { break; } } // glavni program $db = mysql_connect('localhost', 'root', 'password'); mysql_select_db('asteriskcdrdb'); $vreme = date("Y-m-d H:i:s",mktime(date("H") -1, date("i") , date("s") , date("m") , date("Y"))); $dst = str_replace("+381", "%", $argv[1]); if ($dst{0}=='0') $dst = substr($dst, 3); $sql="SELECT src FROM `cdr` WHERE dst like '".$dst."' and calldate > '".$vreme."' ORDER BY calldate DESC LIMIT 1"; $result = mysql_query($sql); $row = mysql_fetch_array($result); if ($row) { write("SET VARIABLE skiperbr ".$row[0]); read(); } fclose($in); fclose($stdlog); exit; ?>

Pored već opisanih procedura za komunikaciju sa AGI protokolom, koristim i funkciju za prebacivanje globalnih promenljiva u niz.

Asterisk CDR baza podataka se nalazi u MySQL bazi podataka. Iz PHP-a se relativno jednostavno pristupa MySQL-u zahvaljujući ugrađenim funkcijama. mysql_connect uspostavlja konekcija sa bazom preko zadatih autentifikacionih parametara. mysql_select_db vrši odabir baze nad kojom se vrše upiti.

Komanda date, ima cilj da sastavi tekstualnu reprezentaciju vremena pogodnu za MySQL i to u formatu 2008-05-13 21:20:15. Konkretna komanda koja je gore pozvana nema zadatak samo da formatira datum, već i da generiše formatiran datum sa trenutnim vremenom smanjenim za 1 sat.

Ovako generisan datum nam služi kao filter u SQL upitu nad bazom. Generišemo tako upit da nam prikaže izvorišni broj telefona onoga ko je zvao broj koji trenutno upućuje poziv i proverava da li je taj poziv bio iniciran u prethodnih sat vrmena.

Preko mysql_query izvršavam zadati upit, preko mysql_fetch_array preuzimam podatak ukoliko postoji.

Ukoliko postoji podatak, izvršavam AGI komandu setovanja kanalne promenljive skiperbr na broj telefona koji je uputio poslednji poziv u prethondih sat vremena.

� Projekat razvojno ime: „Igre bez granica“

Na konferenciji SouthEasternEuropeBroadbandConference upoznao sam se sa timom elektroničara iz Bugarske. Elektroničarska firma Neomontana jer donela prospekte i izložila nekoliko vrlo interesantnih malih proizvoda.

Jedan od njih je mali mikro-kontrolerski uređaj nazvan PicoIP. Ovaj uređaj predstavlja mikrokontroler sa Ethernet interfejsem i 32 pin-a za eksternu konekciju.

40

16 pinova predstavljaju posebne kanale za digitalne signale. 8 pinova prihvataju i generišu analogni signal. A 8 pinova imaju neku programiranu funkciju.

Mali PicoIP uređaj u sebi poseduje program koji implementira TCP/IP stack toliko da se preko Web interfejsa, kao i preko SNMP-a može vršiti konfiguracija i kontrola uređaja.

Namena tog uređaja je, recimo, mogućnost da pinguje određenu IP adresu i ako ne uspe, šalje signal nekom releju da ga fizički restartuje. To su neki od programa koji su učitani u njegov mikrokontroler.

Ova mala spravica predstavlja izvor ideja kako možemo integrisati računarski sistem u bukvalno sve i svašta.

Korišćenjem digitalnih ulaza možemo napraviti razne prekidačke detektore koji će direktno prenositi podatke računaru. Jedan od primera je alarm.

Korišćenjem digitalnih izlaza možemo povezati bukvalno svaki elektrosnki sklop i upravljati ga iz daljine putem računara i računarske mreže.

Korišćenjem analognih ulaza možemo vršiti akviziciju i merenje vrednosti signala za monitoring.

Sve to preneti preko mreže do udaljenih centralnih ili distribuiranih sistema. Kao jedna od ideja ovog projekta bila je ideja da se omogući otvaranje i

zatvaranje kapije, ulaznih vrata, paljenje ili gašenje svetla, kroz telefonski poziv. Kao u situaciji da se bližite svojoj kući, treba da parkirate auto u svoju garažu,

a hteli bi ste da kapija bude već otvorena kad stignete. Bilo bi dovoljno da pozovete svoj broj telefona, unesete odgovarajuću šifru i kod za otvaranje kapije. Centrala će poslati signal kontroleru kapije umesto Vas.

Uređaj podržava SNMP komande. Koristeći snmpget i snmpset komande, koje se za Linux mogu lako naći, možemo lako dobiti stanje pinova na uređaju ili pak postaviti iste.

Da bih omogućio upravljanje PicoIP uređajem sa centrale, dovoljno je uvrstiti u dialplan sledeću skriptu :

exten => _4444,1,GotoIf($[$["${CALLERID(num)}" != "125" ]]?prekid) exten => _4444,n,Playback(beep) exten => _4444,n,system(/usr/local/bin/snmpset -v 1 -c private 192.168.0.100 pctrlPort3.0 i 1) exten => _4444,n,wait(5) exten => _4444,n,Playback(beep) exten => _4444,n,system(/usr/local/bin/snmpset -v 1 -c private 192.168.0.100 pctrlPort3.0 i 0) exten => _4444,n(prekid),hangup

Pozivom na lokal 4444 skripta proverava da li je poziv došao sa lokala broj 125, ako nije, prekida vezu.

Ukoliko jeste, šalje znak beep kao znak da je prihvatio akciju, šalje SNMP komandu uređaju na adresi 192.168.0.100 (PicoIP) da postavi vrednost SNMP objekta pctrlPort3.0 na 1, tj uključeno. Tada je bilo koji priključeni relej odreagovao i izvršio akciju.

Sačeka 5 sekundi, šalje ponovo znak beep, i šalje komandu za gašenje određenog pina. Nakon čega skript završava sa radom.

41

� Echo problemi i rešenja VoIP telefonija, sama po sebi nije kompatabilna sa klasičnom telefonijom.

Samim tim nije moguće bez prilagođavanja povezati VoIP telefonsku centralu sa klasičnom telefonijom.

Najbliža tehnologija klasične telefonije, VoIP tehnologiji, je ISDN tehnologija. ISDN koristi posebne kanale za signalizaciju, a posebne za prenos glasa u digitalnoj formi, što je vrlo slično SIP i RTP načinu prenosa. Razlika je u tome, ako uporedimo u odnosu na TCP/IP mrežni model, to što ISDN komunicira do data link nivoa, dok SIP i RTP koriste i više nivoe mrežnog modela.

ISDN predstavlja digitalnu komunikaciju preko telefonskih linija, međutim, danas, još uvek, ISDN nije deo svakog domaćinstva već se može naći samo u pojednim firmama lociranim u većim gradovima.

Kada kažemo klasična telefonija, danas se to odnosi na PSTN analognu tehnologiju prenosa glasa.

Pojava da korisnik prilikom razgovora čuje svoj sopstveni glas, poznata je pod

nazivom Echo (exo). Problem Echo je poznat od prvih dana korišenja resursa za daljinski prenos glasa. Najčešći uzrok Echo pojave je neusaglašenost glasnoće glasa sagovornika. Ovaj problem postoji kako u VoIP telefoniji tako i u klasičnoj i mobilnoj telefoniji. Za razliku od drugih tehnologija, VoIP ima osetljivost na još jednu komponentu prenosa. Osetljivost na kašnjenje (Delay) dodatno pravi problem u eliminisanju i izolovanju problema sa Echom.

Echo se stvara kao proizvod kombinacije dve pojave, preglasnosti – prevelike amplitude signala, i kašnjenja. Kod klasične telefonije, često se dešava da je signal preglasan, ali zbog nepostojanja kašnjenja ne dolazi do Echo pojave. Hardverski uređaji koji služe za eliminisanje Echo pojave, su veoma skupi, pa se zbog toga ne ugrađuju u lokalne centrale već samo u veće, centralne telefonske jedinice. Zbog toga postoji veća šansa da ćete u klasičnoj telefoniji čuti Echo ako uputite lokalni poziv (poziv na istoj centrali), nego neki međugradski poziv.

U mobilnoj telefoniji često uređaji šalju neprilagođen (preglasan) singal, a dolazi i do varijabilnih kašnjenja zbog bežičnog prenosa. Zbog toga često možemo primetiti Echo efekat u razgovoru. Neophodna je implementacija sistema za eliminisanje Echo pojave kako bi se postigao pristojan kvalitet razogovra.

Razgovor između dva aparata klasične telefonije šematski izleda ovako:

>)--<-+ 4-wire trunk +->--(<

| +---------------->--------------+ |

| 2-wire local loop | | 2-wire local loop |

Hybrid <---------------> Hybrid Hybrid <---------------> Hybrid

| | | |

| +----------------<--------------+ |

o)-->-+ +-<--(o

Caller Callee

Problem može nastati u Hybrid multiplekseru koji zbog glasnoće ne može pravilno da razdvoji dolazni od odlaznog signala.

42

Problem može nastati i u konstrukciji telefonske slušalice koja bi vibracije sa zvučnika slučajno prenela na mikrofon.

Problem može nastati i zbog uticaja iz spoljnog okruženja, npr. prirodan Echo prouzrokovan malom praznom prostorijom.

Problem se može desiti i zbog korišćenja loših, ne upredenih kablova za prenos gde dolazi do nepoželjne indukcije.

Postoji još nekoliko razloga zbog kojih dolazi do pojave Echo efekta, ali poznavanje samo tih razloga nije siguran način da se Echo suzbije. Sa povećanjem rastojanja na kojima se prenosi glas raste i kašnjenje, tj. vreme potrebno da se taj glas prenese. Kod klasične telefonije važi sledeća računica.

Ako za prenos kvalitetnog glasa, bez bojazni da će se pojaviti Echo, računamo da je maksimalno dozvoljeno kašnjenje 50 ms, a uzmemo da je brzina prenosa glasa kroz žicu približno jednaka brzini svetlosti, dobijamo sledeće :

50 ms * 3.10^8 m/s / 2 = 7500km

Što znači da je tehnički moguće preneti glas kroz maksimalno 7500 km kabla

bez bojazni za da će se pojaviti Echo, bar što se tiče kašnjenja. Kod hibridnih sistema za spajanje VoIP na klasičnu telefoniju problemi su još

veći. Šematski to izgleda ovako :

Svi problemi poznati kod klasične telefoniju su zastupljeni i ovde jer se

uglavnom koriste resursi klasične telefonije. Međutim, dodatne probleme prave i višestruke Analogno-digitalne (A/D) i Digitalno-analogne (D/A) konverzije.

Rešenje svih ovih problema uopšte nije jednostavno niti univerzalno. Koriste

se različite metode koje imaju različit stepen uspešnosti u različitim delovima sveta. Neke od različitih metoda rešavanja Echo problema : Eliminisanjem uslova za Echo od strane izvora, tj. za odlazne signale. Vrši se

kontrola glasnoće signala od strane VoIP telefonske centrale. Na taj način se sprečavaju preklapanja i greške prilikom multipleksa odlaznog i dolaznog signala. Kod VoIP centrala vrši se kalibrisanje koeficijenata glasnoće signala, tako da se kompletan signal utišava do zadovoljavajuće granice. Ponekad glasnoća signala treba da se i pojača, kako korisnik ne bi pojačavao svoj aparat na nekom od krajeva i time stvorio nove uslove za Echo. Ova metoda eliminisanja nije mnogo efikasna, jer kontrolišemo samo jedan od izvora problema. Još jedan nedostatak je to što se kalibracija vrši u odnosu na neki telefonski uređaj, a moguće je da na istoj centrali postoji mnogo različitih telefonskih uređaja koji šalju glas sa različitom glasnoćom.

VoIP traffic

>)-<- D-to-A =======<====== A-to-D --<-+ 4-wire trunk +->--(<

| +---------------->--------------+ |

| 2-wire local loop | | 2-wire local loop |

Hybrid <---------------> Hybrid Hybrid <---------------> Hybrid

| | | |

| +----------------<--------------+ |

o)->- A-to-D =======>====== D-to-A -->-+ +-<--(o

^^^^^^^^^^^^ ^^^^^^^^^^^^

VoIP phone PSTN-VoIP gateway

43

Echo suppression – je metoda koja vrši detekciju govora i na osnovu toga šalje ili ne šalje glas. Ideja je da se ne šalje glas koji bi mogao da prouzrokuje Echo ukoliko se ne detektuje govor, tj. ako sagovornik ćuti tj. sluša. Iako je prvobitno izgledalo kao odlična ideja za eliminisanje nepotrebnog saobraća i smanjenje šanse za nastanak Echo efekta, ova metoda stvara druge probleme kada oba sagovornika pokušaju u istom momentu da govore. Dolazi do veoma neprijatnog efekta da se od nje i odustalo. Još jedna stvar po pitanju izbacivanja tišine može da napravi zabunu. Naime, kada druga strana ne govori, čovek je navikao da čuje pozadinski šum, zujanje, muziku, lupanje ili bilo šta. Ako čovek u momentu svog govora ne čuje apsolutno ništa od svog sagovornika, čak ni taj šum, stiče utisak da se veza prekinula i da priča sam sa sobom.

Echo cancellation – predstavlja primenu filtara i različitih obrada signala kako bi se eliminisao Echo. Poseban deo nauke o algoritmima bavi se proučavanjem algoritama za ukidanje Echo efekta. Postoje razne, hardverske i softverske implementacije algoritama. Faktički mnogi hardverski elementi u telefoniji se razlikuju samo po mehanizmu za ukidanje Echo pojave.

Asterisk ima ugrađenu podršku za sledeće algoritme za ukidanje Echo efekta :

• Mark • Mark2 • Mark3 • Steve • Steve2 • KB1 • MG2

Za poslednje verzije Asterisk platforme u integraciji sa Zaptel drajverima za

uređaje za komunikaciju sa klasičnom telefonijom koristi se MG2 algoritam za ukidanje Echo pojave.

Gradimo pretpostavku da na našoj lokalnoj telefonskoj centrali ne postoji ugrađen i aktivan Echo canceller zbog cene hardverske komponente. To znači da uklanjanje Echa moramo raditi na našem kraju.

Algoritam se implementira na određenom zvučnom periodu. Konkretno uzima se odabirak od 8 KHz u trajanju od 0,125 ms. Asterisk po defaultu uzima 128 odabirka nad kojima primenjuje algoritam za uklanjanje Echa, što znači da obrađuje 16 ms po 16 ms.

U realnosti vrlo je teško predvideti šta se u datom momentu može izazvati

Echo efekat. Zbog toga su pomenuti algoritmi delimično efikasni. Uglavnom svaki od njih je dobar za određenu vrstu Echo signala.

Postoje i hibridni Echo cancelleri koji implementiraju različite algoritme u zavisnosti od toga kakvu vrstu Echo signala primaju. Ti algoritmi razvijaju čak i posebne neuronske mreže pomoću kojih uče na konkretnom primeru da li je određeni postupak rešio problem, u kojoj meri i sl.

Ovakvi algoritmi su uglavnom komercijalnog tipa, ali postoji i nekoliko

Open-source varijanti.

44

Open Source Line Echo Canceller (OSLEC) je jedan od kompleksnijih Echo canceller-a koji se polako implementira u sve telefonske sisteme. Efikasnost ovog rešenja naspram ceni je ono što daje prednost OSLEC-u naspram drugih komercijalnih rešenja.

OCTASIC SoftEcho je jedan od trenutno najkvalitetnijih komercijalnih Echo

canceller softvera. Masovno se implementira u hardverske komponente kao hardverski Echo canceller.

45

� Literatura

[1] Jim Van Meggelen, Jared Smith, Leif Madsen. Asterisk™: The Future of Telephony, 2nd Edition, August 15, 2007

[2] Benjamin Jackson, Champ Clark III, Johnny Long, Larry Chaffin. Asterisk Hacking Syngress; 2007

[3] Stephen P. Olejniczak, Brady Kirby, Mark Spencer. Asterisk for Dummies , John Wiley & Songs; 2007

William C. Hardy, VoIP Service Quality: Measuring and Evaluating Packet-Switched Voice, McGraw-Hill Professional

[4] Asterisk Community http://www.asterisk.org/community

[5] Voip-info http://www.voip-info.org/

[6] FreePBX http://www.freepbx.org/

[7] Trixbox Community http://www.trixbox.org/

[8] Neomontana PicoIP http://lan.neomontana-bg.com/picoip.php

[9] SkyCommunications http://www.skycommunications.co.yu/

[10] Wikipedia http://en.wikipedia.org/wiki/Wiki

[11] RFC

• SIP – RFC3261 - http://www.ietf.org/rfc/rfc3261.txt

• RTP – RFC3984, RFC3640, RFC3016, RFC3551, RFC3550, RFC1890, RFC1889, RFC2250 - http://tools.ietf.org/html/rfc3550

• MGCP – RFC3435 - http://tools.ietf.org/html/rfc3435

• IAX2 – DRAFT RFC - http://www.ietf.org/internet-drafts/draft-guy-iax-04.txt

[12] ITU

• G.711 PCMA - http://www.itu.int/rec/T-REC-G.711-198811-I/en

• G.729 - http://www.itu.int/rec/T-REC-G.729/e

• H.323 - http://www.itu.int/rec/T-REC-H.323/e