Arhitektura i Protokol VoIP Mreze

Arhitektura i protokoli VoIP mreže

Bečelor rad Dejan Kurtović 1

Sadržaj:

1 UVOD ............................................................................................................ 3

2 VoIP stek protokol ....................................................................................... 4

3 Protokol IP .................................................................................................... 4 3.1 IPv4 ........................................................................................................ 5 3.2 IP adrese ................................................................................................ 8 3.3 IPv6 ...................................................................................................... 10

4 Internet transportni protokol: UDP ........................................................... 13 4.1 Upoznavanje sa UDP-om ..................................................................... 13 4.2 Protokoli za prenos u realnom vremenu ( The Real - Time Transport

Protocol ) .............................................................................................. 14

5 Internet transportni protokol: TCP ........................................................... 17 5.1 Upoznavanje sa TCP-om ...................................................................... 17 5.2 TCP protokol ......................................................................................... 18

6 SIP protokol ................................................................................................ 20 6.1 Struktura protokola ............................................................................... 21 6.2 Adresiranje ........................................................................................... 22 6.3 SIP mrežni elementi ............................................................................. 23 6.3.1 Korisnički agenti ................................................................................... 23 6.3.2 Proxy server ......................................................................................... 24 6.3.2.1Proxy server bez stanja transakcije.......................................................25 6.3.2.2Proxy server sa stanjem transakcije......................................................25 6.3.3 Redirect server ..................................................................................... 26 6.3.4 Registrar ............................................................................................... 26 6.4 SIP poruke ............................................................................................ 27 6.5 SIP zahtevi ........................................................................................... 28 6.6 SIP odgovori ......................................................................................... 28 6.7 Transakcije ........................................................................................... 29 6.8 Dijalozi .................................................................................................. 31

7 MEGACO..................................................................................................... 32 7.1 MEGACO terminologija ........................................................................ 34 7.2 MEGACO poruke .................................................................................. 35 7.3 MEGACO transakcije............................................................................ 35 7.4 MEGACO terminacije i konteksti .......................................................... 36 7.5 MEGACO komande .............................................................................. 38

8 ZAKLJUČAK ............................................................................................... 38

9 LITERATURA .............................................................................................. 40



10 AKRONIMI I SKRAĆENICE ........................................................................ 41

Slike: Slika 1. VoIP stek protokol. .................................. Error! Bookmark not defined. Slika 2. Zaglavlje IPv4 paketa (Internet protokol) . Error! Bookmark not defined. Slika 3. Formati IP adresa. ................................................................................... 9 Slika 4. Specijalne IP adrese ................................................................................ 9 Slika 5. IPv6 zaglavlje ........................................................................................ 12 Slika 6. Zaglavlje UDP paketa. ........................................................................... 13 Slika 7. Pozicija RTP-a u protokol steku. ............................................................ 14 Slika 8. Ugnežđivanje paketa. ............................................................................ 15 Slika 9. (a) Translator; (b) Mikser. ...................................................................... 15 Slika 10. Format RTP zaglavlja. ......................................................................... 16 Slika 11. Format TCP zaglavlja. ......................................................................... 19 Slika 12. Položaj SIP-a u odnosu na ostale protokole . ...................................... 21 Slika 13. Struktura SIP protokola ....................................................................... 22 Slika 14. Osnovni elementi SIP arhitekture. ....................................................... 23 Slika 15. Direktna komunikacija bez proxy servera ............................................ 24 Slika 16. Komunikacija sa proxy serverom ......................................................... 25 Slika 17. Tok poziva sa redirect serverom . ........................................................ 26 Slika 18. REGISTRAR zahteva. ......................................................................... 27 Slika 19. Izgled SIP zahteva. .............................................................................. 27 Slika 20. SIP transakcija ..................................................................................... 30 Slika 21. SIP dijalog. .......................................................................................... 31 Slika 22. Razdvojenost funkcija signalizacije i prenosa govora. ......................... 32 Slika 23. Softsvič arhitektura. ............................................................................. 33 Slika 24.Terminacije MG-a . ............................................................................... 37 Slika 25. MEGACO konteksti i terminacije. ........................................................ 37

Tabele: Tabela 1. Neke IP opcije. ..................................................................................... 8 Tabela 2. Neki dodeljeni portovi. ........................................................................ 18 Tabela 3. MEGACO komande. ........................................................................... 38



1 Uvod Nekada davno, javni komutirani telefonski sistem korišćen je prvenstveno za govorni saobraćaj, sa tu i tamo nešto prenosa podataka. Razmenjivanje podataka je sve više raslo, sve dok se 1999. godine broj prenetih bitova podataka nije izjednačio sa brojem prenetih govornih bitova ( pošto se govor preko regionalnih linija modulira impulsno – kodno, može se izmeriti broj prenetih bitova u sekundi). Godine 2002. saobraćaj podataka je za red veličine premašio govorni saobraćaj i nastavio da raste eksponencijalno, dok je govorni saobraćaj sve vreme imao konstantnu brzinu rasta ( oko 5% godišnje). Zbog svega toga, mnogi operateri mreža koje rade s komutiranjem paketa najednom su počeli da se zanimaju za prenošenje govora njihovim mrežama. Tu je dodatni propusni opseg potreban za prenos govora minimalan jer su mreže sa komutiranjem paketa dimenzionisane za saobraćaj podataka. Međutim, telefonski račun prosečnog korisnika verovatno je veći od njegovog računa za internet, pa su operateri mreža u Internet telefoniji videli način da zgrnu veliki novac a da ne moraju da razvuku ni jedno jedino novo optičko vlakno. Tako je rođena Internet telefonija poznata i kao govor preko Interneta (engl. voice over IP). VoIP je tehnologija koja omogućava prenos glasa preko računarske mreže. Prvi pokušaji uvođenja su 70-tih godina. Upotrebom ovog standarda, uz upotrebu računarske infrastrukture, hardvera i programske podrške Internet postaje medij za prenošenje telefonskih poziva. Prilikom poziva sa PC-a plaća se samo veza sa Internet provajderom i nadoknada kompaniji koja omogućava datu uslugu po minutu razgovora. Funkciju centrala preuzimaju računari, poziv se inicira klikom miša, razgovori se mogu lako snimiti i organizovati. Sistem je moguće programirati za različite varijante automatske distribucije poziva, automatske telefonske sekretarice, faks uređaje i sl. Prednost nad klasičnim telefonskim sistemom je više nego očigledna. Konkretno, VoIP omogućava obavljanje telefonskog razgovora upotrebom već postojeće Internet veze, kao zamenu za standardnu telefoniju, kako u lokalnom i međugradskom saobraćaju, tako i u međunarodnom. Sve veća popularnost u svetu među telekomunikacionim kompanijama nije slučajna. Velika prednost je mogućnost pozivanja mobilnih i fiksnih pretplatnika i ostvarivanje međunarodnih poziva po izuzetno povoljnim cenama. Javna telefonska mreža koristi Public Switched Telephone Network (PSTN) sistem koji primenjuje tehnologiju komutacije kanala što znači da je predodređeni govorni kanal dodeljen svakom pojedinačnom razgovoru. Ali telefonske mreže su na migracionom putu prema VoIP-u. VoIP sistem obavlja digitalizaciju analognog signala, kodiranje i kompresiju, zatim segmentaciju u pakete i prenos do odredišta. Takva komprimovana digitalna poruka ne zahteva govorni kanal. Umesto toga, poruka može biti poslata preko istih linija koje se koriste za internet pa predodređeni kanal nije više potreban. Potrošači traže sve više od komunikacionih tehnologija. Oni žele govor, podatke i slike, a to sve zahteva povećanje kapaciteta. Komunikacione mreže koje nude takav povećani kapacitet postaju sve popularnije. IP telefon nudi tu pogodnost omogućavajući



korisnicima telefonske pozive preko postojećih mreža za prenos podataka i izbegavanje velikih računa koje bi uobičajeno primili od svojih operatora. Dok je VoIP tehnologija bila u ranom razvoju bilo je dosta problema sa kvalitetom usluga u odnosu na analognu telefoniju, ali VoIP tehnologija se ubrzano poboljšavala.

2 VoIP stek protokol

Slika 1. VoIP stek protokol

IP - Internet Protocol UDP - User Datagram Protocol (protokol za korisničke datagrame) TCP - Transmission Control Protocol ( protokol za upravljanje prenosom) RTCP - Real-time Transport Control Protocol (protokol za upravljanje prenosom u

realnom vremenu) RTSP – Resource reSerVation Protocol (protokol za rezervisanje resursa RTP – Real-time Transport Protocol (protokol za prenos u realnom vremenu) SIP – Session Initiation Protocol (protokol zaotvaranje sesija) SDP – Session Description Protocol (protokol za opis sesija)

3 Protokol IP

Ovo poglavlje je napisano na osnovu knjige ″Računarske mreže″ koju je napisao Andrew S. Tanenbaum. IP (Internet protokol) (engl. Internet Protocol) je protokol trećeg sloja OSI referentnog modela (sloja mreže). Sadrži informacije o adresiranju, čime se postiže da svaki mrežni uređaj (računar, server, radna stanica, interfejs rutera) koji je povezan na internet ima jedinstvenu adresu i može se lako identifikovati u celoj Internet mreži, a isto tako sadrži kontrolne inforamacije koje omogućuju paketima da budu prosleđeni (rutirani) na osnovu poznatih IP adresa. Ovaj protokol je dokumentovan u RFC 791 i predstavlja sa TCP protokolom jezgro Internet protokola, TCP/IP stek protokola (engl. Transmission Control Protocol/Internet Protocol). IP ne zahteva prethodno



upostavljanje veze u trenutku slanja podatka, već računar koji šalje podatke pokušava sve dok ne prosledi poruku (best effort model). Prenos podataka je relativno nepouzdan, što znači da nema gotovo nikave garancije da će poslati paket zaista i doći do odredišta nakon što je poslat. Sam paket u procesu prenosa se može promeniti, zbog različitih osnovnih prenosnih pravaca, može se dogoditi da segmenti ne stižu po redosledu, mogu se duplirati ili potpuno izgubiti tokom prenosa. Ukoliko aplikacija zahteva pouzdanost, koriste se mehanizmi TCP protokola u sloju iznad samog IP protokola. TCP protokol je isto zadužen za definisanje redosleda paketa koji stižu (sekvence). S obzirom da je sam koncept IP protokola oslobođen mehanizama koji osiguravaju pouzdanost, sam proces usmeravanja (rutiranja) paketa unutar mreže je relativno brz i jednostavan.

IP ima tri primarne funkcije: Adresiranje (definiše način dodele internet adresa), Internet moduli

koriste adrese koje paketi nose u IP zaglavlju kako bi ih prosledili dalje ka destinaciji.

Rutiranje, određivanje putanje za prenos podataka sa jednog računara na drugi bez prethodnog uspostavljanja veze (engl. connectionless), po (engl. best-effort) modelu.

Fragmentaciju i ponovno sastavljanje paketa kada je potrebno kako bi se preneli kroz mrežu koja ima manji MTU (engl. maximum transmission unit).

3.1 IPv4 IP datagram sadrži zaglavlje i tekstualni deo. Zaglavlje ima fiksni deo

dužine 20 bajtova i opcioni deo promenljive dužine. Format zaglavlja prikazan je na slici 2. Ono se prenosi redosledom sa leva udesno, pri čemu prvo ide najznačajniji bit polja Verzija.

U polju Verzija (engl. Version) označena je verzija protokola kome pripada datagram. Uključivanjem verzije u datagrame neće morati cela mreža da odjednom pređe na novu verziju protokola – zamena se može obavljati godinama. Danas je aktuelan prelazak sa protokola IPv4 na protokol IPv6. Postojao je protokol za prenos u realnom vremenu - IPv5, koji nikada nije bio šire prihvaćen.

Pošto dužina zaglavlja nije fiksna, postoji u njemu polje DIZ (engl. IHL, Internet header length) u kome se beleži dužina zaglavlja u 32-bitnim rečima. Najmanja vrednost je 5, što se koristi kada nema opcija. Najveća vrednost ovog 4-bitnog polja je 15, što ograničava zaglavlja na 60 bajtova, a polja Opcije na 40 bajtova. Za neke operacije, npr. za beleženje putanje paketa, 40 bajtova je premalo, pa takva opcija ne služi ničemu.



Slika 2. Zaglavlje IPv4 paketa (Internet protokol)

Vrsta usluge (engl. Type of service) je jedno od retkih polja koje je tokom

godina (neznatno) promenilo svoju ulogu. Ono je od početka bilo namenjeno razgraničavanju različitih klasa usluga, a tu ulogu ima i sada. U tom pogledu, moguće su različite kombinacije pouzdanosti i brzine isporuke. Za digitalizovan govor, brza isporuka ima prednost nad tačnom isporukom. Za prenos datoteka, prenos bez grešaka je važniji od brzog prenosa.

Ovo 6-bitno polje prvobitno je sadržavalo ( sleva udesno) 3-bitno potpolje Prioritet i tri indikatora D, T, i R. Prioritet je označavan vrednostima od 0 (normalan) do 7 (mrežni upravljački paket). tri indikatorska bita su računaru omogućavala da naznači o čemu najviše brine ( o kašnjenju – engl. Delay, protoku podataka – engl. Throughput ili o pouzdanosti prenosa – engl. Reliabiluty). Ta polja su teorijski omogućavala usmerivačima da biraju između, na primer, satelitske veze s visokim protokom podataka i velikim kašnjenjem, i iznajmljene linije s niskim protokom podataka i malim kašnjenjem. U praksi, međutim, usmerivači često potpuno zanemaruju polje Vrsta usluge.

Polje Ukupna dužina (engl. Total length) obuhvata sve što se nalazi u datagramu – i zaglavlje i podatke. Maksimalna dužina je 65.535 bajtova. Ta gornja granica je zasad prihvatljiva, ali u budućim gigabitnim mrežama može se pojaviti potreba za većim datagramima.

Iz polja Identifikacija (engl. Identification) odredišni računar utvrđuje kom datagramu pripada pristigli fragment. Svi fragmenti istog datagrama imaju istu Identifikaciju.

Posle ovog polja sledi jedan neiskorišćen bit, a zatim dva jednobitna polja. DF znači Ne Fragmentiraj. To je naredba usmerivačima da ne fragmentiraju datagram jer odredište ne može da od njih ponovo sklopi datagram. na primer, kada se računar podiže, njegov ROM može zahtevati da mu se memorijska slika pošalje u obliku jedinstvenog datagrama. Kada datagram označi bitom NF, pošiljalac zna da će on stići u jednom komadu, pa makar morao da odstupi od optimalne putanje da bi izbegao mreže koje ograničavaju veličinu paketa. Od



svih računara se zahteva da prihvate fragmente veličine 576 bajtova ili manje fragmente.

MF znači još fragmenata. Svi fragmenti datagrama, osim poslednjeg imaju postavljen taj bit. On je potreban da bi se znalo kada je datagram kompletiran.

Redni broj fragmenta (engl. Fragment offset) pokazuje gde spada fragment unutar datagrama. Svi fragmenti datagrama, osim poslednjeg, moraju biti umnošci od 8 bajtova – veličine elementarnog fragmenta. Pošto je polje dužine 13 bitova, dozvoljeno je najviše 8192 fragmenata po datagramu, što daje datagram maksimalne dužine 65.536 bajtova, za bajt više no što dozvoljava polje Ukupna dužina.

Životni vek (engl. Time to live) je brojač koji ograničava trajanje paketa na mreži. Predviđen je da vreme meri sekundama, pa je najveći životni vek paketa 255 sekundi. Brojač mora smanjivati vrednost za jedinicu pri svakom skoku, a trebalo bi da je smanjuje i ako se duže zadrži u redu čekanja usmerivača. U praksi, međutim, on samo broji skokove. Kada njegova vrednost dostigne nulu, paket se odbacuje, a izvorišnom računaru šalje se paket upozorenja. Ovo polje onemogućava datagrame da večno lutaju mrežom, što bi se moglo dogoditi ako se poremete tabele usmerivača.

Kada mrežni sloj sklopi potpun datagram, on treba da zna šta sa njim da radi. Polje Protokol (engl. Protocol) naznačava proces kome paket treba predati. Taj proces može biti protokol TCP, ali i protokol UDP ili drugi procesi. Protokoli se na Internetu globalno označavaju brojevima. Ranije su se brojevi protokola i drugi brojevi koji se dodeljuju nalazili u RFC 1700 dokumentu, ali se sada nalaze u mrežnoj bazi podataka.

Kontrolnim zbirom zaglavlja (engl. Header checksum) proverava se, prirodno, samo zaglavlje. Takav kontrolni zbir se koristi za proveru grešaka izazvanih neispravnim memorijskim rečima usmerivača. Algoritam radi tako što se aritmetikom nepotpunih komplemenata sabiraju sve 16-bitne polureči onako kako pristižu, a zatim se od rezultata odbije nepotpuni komplement. Za svrhe ovog algoritma, pretpostavlja se da je Kontrolni zbir zaglavlja po stizanju jednak nuli (tj. ako nije došlo do greške). Opisani algoritam je robusniji od običnog sabiranja. Kontrolni zbir zaglavlja se mora ponovo računati pri svakom skoku, pošto se bar jedno polje uvek menja ( Životni vek), ali postoje načini da se to izračunavanje ubrza.

Izvorišna (engl. Source address) i odredišna (engl. Destination address) adresa ukazuju na broj mreže i broj računara. Polje opcije (engl. Options) prihvata informacije koje nose novije verzije protokola (za koje se nije znalo u trenutku projektovanja formata), omogućava eksperimentatorima da isprobaju nove ideje i obezbeđuje mesto za informacije koje se retko koriste. Same opcije mogu biti različite dužine. Svaka počinje 1-bajtnim kodom koji identifikuje opciju. Kod nekih opcija zatim sledi 1-bajtno polje s dužinom opcije, a zatim kod svih sledi jedan ili više bajtova podataka. Polje Opcije dopunjava se nulama do umnoška od četiri bajta. Prvobitno je definisano pet opcija (tabela 1), ali ih je kasnije dodato još.



Opcija Opis Bezbednost (Security) Označava stepen tajnosti datagrama Strogo usmeravanje sa izvora (Strict source routing)

Daje se potpuna putanja za prosleđivanje paketa

Približno usmeravanje sa izvora (Loose source routing) Daje se lista obaveznih usmerivača

beleženje putanje (Record route) Svaki usmerivač treba da fragmentu doda svoju IP adresu

Vremenska oznaka (Timestamp) Svaki usmerivač treba da fragmentu doda svoju IP adresu i vreme prolaska

Tabela 1. Neke IP opcije

Bezbednost naznačava tajnost informacija. Ovo polje teorijski može da upotrebi vojska da bi iz putanje isključila države koje smatra nepodobnim. U praksi ga, međutim svi usmerivači zanemaruju, tako da služi samo špijunima, kao indikator „vredne robe“. Strogo usmeravanje sa izvora daje potpunu putanju od izvorišta do odredišta kao sekvencu IP adresa. Datagram mora da sledi tu putanju. Opcija najviše koristi administratorima sistema da pošalju upozoravajuće pakete kada se poremete tabele za usmeravanje ili onda kada vrše vremenska merenja.

Opcijom Približno usmeravanje sa izvora zahteva se da paket prođe listu usmerivača navedenim redom, ali se ne zabranjuje prolazak i kroz druge usmerivače. Njom se najčešće zadaje samo nekoliko usmerivača da bi se forsirala određena putanja. Na primer, da bi smo prisilili paket da iz Londona za Sidnej krene na zapad umesto na istok, možemo navesti usmerivače u Njujorku, Los Anđelesu i Honoluluu. Opcija je najkorisnija kada politički ili ekonomski razlozi diktiraju (ne)prolazak kroz određene države. Opcija Beleženje putanje nalaže usmerivačima duž putanje da u polje Opcije dodaje svoju IP adresu. To administratorima sistema omogućava da povratnim putem pronađu greške u algoritmima za usmeravanje. Vremenska oznaka liči na Beleženje putanje, osim što pored svoje 32-bitne IP adrese svaki usmerivač beleži i 32-bitnu vremensku oznaku. I ova opcija uglavnom služi za otkrivanje grešaka u algoritmima za usmeravanje.

3.2 IP adrese

Svaki računar i svaki usmerivač na Internetu imaju svoju IP adresu koja obuhvata broj njihove mreže i broj računara. Ta kombinacija je jedinstvena: dva računara na Internetu u načelu ne mogu imati istu IP adresu. Dužina svih IP adresa je 32 bita i one se koriste u poljima Izvorišna adresa i Odredišna adresa IP paketa. IP adresa se u stvari ne odnosi na računar, već na mrežni interfejs, pa ako se računar nalazi u dve mreže, mora imati dve IP adrese. Međutim, u praksi je to retko, računari su uglavnom na jednoj mreži i imaju jednu IP adresu.

Već više decenija IP adrese se dele u pet kategorija prikazanih na slici 3. Takva podela je dobila naziv klasno adresiranje. Ona se više ne koristi ali se u literaturi još uvek navodi.



Slika 3. Formati IP adresa

Formati klasa A, B, C i D omogućavaju 128 mreža sa po 16 miliona

računara, 16.384 mreže sa po 64K računara i 2 miliona mreža sa 256 računara.. Podržano je i višesmerno emitovanje – upućivanje datagrama mnogim računarima. Adrese koje počinju na 1111 rezervisane su za buduću upotrebu. Na Internet je sada povezano preko 500.000 mreža, a taj broj raste svake godine. Da bi se izbegli sukobi, brojeve mreža dodeljuje neprofitna Korporacija za dodeljivanje imena i brojeva na Internetu (engl. Internet Corporation for Asigned Names and Numbers, ICANN). Organizacija ICANN je za uzvrat poverila delove adresnog prostora različitim regionalnim vlastima, koje IP adrese dalje dele davaocima Internet usluga i drugim kompanijama.

Mrežne adrese, 32-bitni brojevi, obično se pišu decimalnom notacijom s tačkom. Tom notacijom, svaki od 4 bajta piše se decimalno, od 0 do 255. Na primer, 32-bitna heksadecimalna adresa C0290614 piše se kao 192.41.6.20. Najniža IP adresa je 0.0.0.0, a najviša 255.255.255.255.

Vrednosti 0 i -1 (sve jedinice) imaju specijalno značenje, što se vidi sa slike 4. Vrednost -1 koristi se kao adresa za neusmereno emitovanje svim računarima na naznačenoj mreži.

Slika 4. Specijalne IP adrese



Adresu 0.0.0.0 koriste računari u fazi uključivanja. IP adresa sa mrežnim

brojem 0 označava tekuću mrežu. Takve adrese omogućavaju računarima da adresiraju sopstvenu mrežu iako joj ne znaju broj (ali moraju znati njenu klasu jer od toga zavisi koliko će nula da uključe u adresu). Adresa koja se sastoji od samih jedinica omogućava neusmereno (difuzno) emitovanje u lokalnoj mreži. adrese koje u mrežnom delu imaju ispravan broj mreže, a ostatak su same jedinice, omogućavaju slanje i difuzno distribuiranje paketa u naznačenoj udaljenoj mreži bilo gde na internetu (premda mnogi administratori mreža isključuju ovu opciju). Sve adrese tipa 127.xx.yy.zz rezervisane su za testiranje povratnom petljom. Paketi koji se pošalju na takvu adresu ne izlaze na žicu, oni se obrađuju lokalno kao paketi koji su došli spolja. To omogućava da se paketi pošalju lokalnoj mreži, a da pošiljalac ne mora da zna njen broj.

3.3 IPv6 IETF je 1990. počeo da razvija novu verziju protokola IP, takvu kojoj nikada neće ponestati adresa, koja će rešiti brojne probleme i istovremeno biti fleksibilnija i efikasnija od prethodne. Trebalo je da nova verzija ispuni sledeće zahteve:

1. Da podrži milijarde računara, čak i uz neefikasno korišćenje adresnog prostora

2. Da smanji veličinu tabela za usmeravanje. 3. Da bude jednostavnija kako bi usmerivačima omogućila da brže

obrađuju pakete. 4. Da bude bezbednija (identifikovanje i privatnost) od postojeće verzije. 5. Da obrati više pažnje na vrstu usluge, naročito na prenos u realnom

vremenu. 6. Da podrži višesmerno emitovanje, omogućujući definisanje opsega

adresa. 7. Da računarima omogući kretanje bez menjanja adrese. 8. Da ostavi mogućnost za buduće razvijanje protokola. 9. Da omogući uporedno korišćenje stare i nove verzije tokom dužeg

vremena. IPv6 odgovara na postavljene zahteve prilično uspešno. U njemu su

zadržane dobre osobine protokola IP, one loše su odbačene ili potisnute u drugi plan a – gde je trebalo – dodate su i nove. IPv6 u načelu nije kompatibilan sa verzijom IPv4, ali jeste sa drugim pomoćnim Internet protokolima, uključujući TCP, UDP, ICMP, IGMP, OSPF, BGP, i DNS, ponekada uz male izmene.

Prvo i najvažnije, IPv6 radi sa dužim adresama nego protokol IPv4. One su dugačke 16 bajtova, što rešava jedan od postavljenih zadataka: obezbeđuje praktično neograničen broj Internet adresa.

Drugo glavno poboljšanje koje je uveo protokol IPv6 odnosi se na uprošćenje zaglavlja. Ono sadrži samo sedam polja ( u odnosu na 13 kod IPv4).



Ta promena omogućava usmerivačima da brže obrađuju pakete, i tako povećaju njihov protok i smanje kašnjenje.

Treće veće poboljšanje je bolja podrška opcijama. To je bilo neophodno kada je uvedeno novo zaglavlje, pošto su polja koja su ranije bila obavezna sada postala opciona. Osim toga, drugačiji je i način na koji se opcije predstavljaju, što usmerivačima omogućava da preskoče opcije koje nisu namenjene njima. Ta osobina ubrzava obradu paketa.

Četvrto područje koje je u protokolu IPv6 znatno unapređeno jeste bezbednost. IETF je imao u vidu punu policu novinskih članaka o 12-godišnjacima koji pomoću svojih PC računara provaljuju u banke i vojne baze širom Interneta. Preovladalo je čvrsto ubeđenje da u pogledu toga treba nešto učiniti. Zbog toga su provera identiteta i privatnost ključne osobine novog IP protokola. Te osobine su kasnije dodate i u IPv4, tako da sada – na području bezbednosti – nema velikih razlika između stare i nove verzije protokola. Zaglavllje IPv6 paketa je prikazano na slici 5.

Polje Verzija (engl. Version) ima uvek vrednost 6 za IPv6 (4 za IPv4). Tokom perioda prelaska s protokola IPv4 na protokol IPv6, usmerivači će moći da ispituju ovo polje i da tako utvrde kakav paket imaju. Ova provera troši nekoliko instrukcija na kritičnoj putanji, pa će mnoge realizacije verovatno pokušati da je zaobiđu koristeći za razlikovanje paketa neko polje u zaglavlju sloja veze. Na taj način, paketi se direktno mogu proslediti odgovarajućem programu za obradu u mrežnom sloju. Međutim, ako sloj veze podataka počne da vodi brigu o vrstama paketa, to potpuno ruši princip da sloj ne treba ništa da zna o značenju bitova koje mu isporučuje viši sloj.

Polje Klasa saobraćaja (engl. Traffic class) koristi se za prepoznavanje paketa sa različitim zahtevima u pogledu isporuke u realnom vremenu. Takvo polje je postojalo u protokolu IP od samog početka, ali su ga usmerivači retko koristili.

I polje Oznaka toka (engl. Flow label) još uvek je eksperimentalno, ali će se koristiti za uspostavljanje pseudoveze između izvorišta i odredišta za koju se mogu definisati određena svojstva i zahtevi. Na primer, tok paketa od izvesnog procesa na izvorišnom računaru do izvesnog procesa na odredišnom računaru može da ima posebne zahteve u pogledu kašnjenja paketa i zato se za njega mora rezervisati propusni opseg. Takav tok se može unapred podesiti, pri čemu dobija određeni identifikator. Kada se pojavi Oznaka toka različitom od nule, svi usmerivači mogu da ga potraže u svojim internim tabelama da bi utvrdili kako sa njim treba postupati. U stvari, takvi tokovi predstavljaju pokušaj da se objedine dva dobra: fleksibilnost datagramske podmreže i garantovanost isporuke u podmreži s virtuelnim kolima.



Slika 5. IPv6 zaglavlje

Svaki tok se označava izvorišnom adresom, odredišnom adresom i brojem

toka, tako da između istog para IP adresa istovremeno može da bude aktivno više tokova. Čak i kada dva toka koji potiču s različitih računara nose istu oznaku, usmerivač može da ih razlikuje na osnovu izvorišnih i odredišnih adresa.

Dužina korisničkih podataka (engl. Payload length) govori koliko bajtova sledi iza 40-bajtnog zaglavlja sa slike 5. Ime odgovarajućeg polja IPv4 paketa (Ukupna dužina) promenjeno je jer je i značenje polja nešto drugačije: njegova vrednost više ne obuhvata 40 bajtova zaglavlja.

Polje Sledeće zaglavlje (engl. Next header) otkriva tajnu. Osnovno zaglavlje je tako jednostavno zato što se dopuštaju i (opciona) dodatna zaglavlja. Ovo polje saopštava koje od (za sada) šest dodatnih zaglavlja sledi iza aktuelnog zaglavlja, ukoliko je uopšte i upotrebljeno. Ako je aktuelno zaglavlje i poslednje IP zaglavlje, polje Sledeće zaglavlje ukazuje na program transportnog protokola (npr. TCP, UDP) kome treba proslediti paket na obradu.

Najveći broj skokova (engl. Hop limit) onemogućava večni život paketa. To polje ima istu funkciju kao polje Životni vek u protokolu IPv4, tj. njegova vrednost se pri svakom skoku smanjuje za jedan. U protokolu IPv4, Životni vek se teorijski izražava sekundama, ali ga nijedan usmerivač nije tako tumačio, pa mu je i ime promenjeno da bi bolje odražavalo način njegove stvarne upotrebe. Slede polja Izvorišna adresa (engl. Source address) i Odredišna (engl. Destination address) adresa.



4 Internet transportni protokol: UDP

Ovo poglavlje je napisano na osnovu slajdova sa vežbi koje je održavala

profesorica Tatjana Lončar Turukalo. Internet ima dva glavna protokola na transportnom nivou, protokol sa uspostavom veze i protokol bez uspostave veze. U nastavku upoznaćemo se sa obe vrste protokola. Protokol bez uspostave veze je UDP. Protokol sa uspostavom veze je TCP. S obzirom na to da UDP predstavlja IP sa dodatnim zaglavljem, počećemo sa njim. Razmotrićemo i dve primene UDP protokola.

4.1 Upoznavanje sa UDP-om

UDP ( User Datagram Protocol ) predstavlja jednostavan protokol koji

služi za slanje pojedinačnih datagrama ( termin datagram koristi se za UDP i IP poruke, zbog velike sličnosti ova dva protokola ).

UDP ne obezbeđuje pouzdanost. Ne beleži se koji su datagrami poslati, niti se očekuje potvrda prijema datagrama.

UDP ne uvodi nikakve dodatne mehanizme, u odnosu na IP, koji bi obezbeđivali pouzdanost. Omogućeno je slanje datagrama većem broju računara istovremeno, tj. multicasting i broadcasting.

Osnovne funkcije UDP-a: Dve osnovne funkcije koje UDP vrši kao nadogradnja IP-a su: 1. Multipleksiranje i demultipleksiranje aplikacija korišćenjem portova. 2. Provera ispravnosti podataka. Ova funkcija se ogleda u tome da UDP

vrši proveru celokupnog UDP datagrama, za razliku od IP koji vrši proveru samo svog zaglavlja.

Format UDP zaglavlja Format UDP datagrama dat je na slici 6.

Slika 6. Zaglavlje UDP paketa Port izvora ( source port ) identifikuje program koji šalje podatke.



Port odredišta ( destination port ) identifikuje program koji prima podatke. Ukupna dužina ( UDP length ) definiše dužinu UDP zaglavlja i UDP

podataka u bajtima. Provera pariteta ( UDP checksum ) služi za proveru ispravnost:

UDP zaglavlja. UDP podataka. Dela IP zaglavlja koji je proveren u IP zaglavlju ( najvažniji deo IP

zaglavlja pa se vrši dodatna provera ). o IP adrese pošiljaoca. o IP adrese odredišta. o Polja protokola.

Deo IP zaglavlja ne upisuje se dodatno u UDP segment - pseudozaglavlje. UDP provera pariteta se proverava samo na odredištu. U slučaju greške, datagram se odbacuje bez obaveštavanja izvora, jer ne postoji uspostava veze.

Polje posebne primene UDP-a su klijent - server situacije. Često, klijent šalje kratki zahtev serveru i očekuje odgovor. Ako se upit ili odgovor izgubi klijent može sačeka i pokuša ponovo.

4.2 Protokoli za prenos u realnom vremenu ( The Real - Time Transport Protocol )

The Real - Time Transport Protocol ( RTP ) se koristi za prenos

korisničkih podataka, tj. prenos audio, video i multimedijalnih podataka. Postoji posebna RTP sesija za audio i posebna za video podatke. U tom smislu učesnik može da bira koje podatke će da prima. Sa druge strane, ne postoji veza na RTP nivou između ovih sesija, osim kanoničkog imena učesnika koje mora biti isto za obe sesije.

RTP se koristi u slučajevima komunikacije više učesnika, pri čemu, učesnici mogu da šalju i primaju informacije u različitom formatu.

RTP radi iznad UDP-a, s tim da dodaje neke informacije o paketu Podatak o rednom broju sekvence, što omogućava detekciju

gubitka. Vreme kada je paket odabiran na izvoru, što omogućava

sinhronizaciju i merenje kašnjenja. Pozicija RTP-a u protokol steku prikazana je na slici 7.

Slika 7. Pozicija RTP-a u protokol steku



RTP paketi se smeštaju u UDP pakete, a oni u IP pakete, a IP u Ethernet pakete, prikazano na slici 8.

Slika 8. Ugnežđivanje paketa

RTP ne rešava probleme, već samo obezbeđuje informacije aplikaciji. Aplikacija koja menja formate i brzine podataka koji se prenose naziva se

RTP translator, prikazana na slici 9(a). S druge strane, postoji i RTP mikser, aplikacija koja može da:

Menja formate i brzine podataka koji se prenose ( kao translator ). Kombinuje više tokova u jedan u slučaju konferencije ( npr. Četiri

učesnika sa 64 kbit/s, mikser primi signale od tri učesnika, pretvori ih u analogni signal, kombinuje ih i ponovo odabira brzinom od 64 kbit/s i šalje četvrtom učesniku ). Ovo je prikazano na slici 9(b).

Slika 9. (a) Translator; (b) Mikser

RTP od aplikacije preuzima jedan ili više odbiraka, dodaje RTP zaglavlje i takav paket šalje UDP-u. RTP zaglavlje sadrži informacije koje su neophodne odredišnoj aplikaciji da što vernije rekonstruiše signal.



Format RTP zaglavlja prikazan je na slici 10.

Slika 10. Format RTP zaglavlja

Opis pojedinih polja: Polje Ver predstavlja verziju RTP protokola. Trenutno je verzija 2. Polje P označava da li postoji dopuna korisničkog dela paketa (mora da

bude umnožak 32 bita ). X bit je ekstenzija, označava da li postoji dodatak zaglavlju. Polje CC nam govori koliko ima identifikatora kontributora izvora u RTP

zaglavlju. Koristi se u slučaju miksera. Npr, ako u konferenciji učestvuju 4 učesnika, tada ovo polje ima vrednost 3, jer prijemna strana dobija signal koji je kombinacuja signala od 3 učesnika.

M bit je marker, koji se koristi u slučaju potiskivanja tišine. Ovaj bit se setuje u prvom paketu nakon perioda tišine.

Polje Payload type označava format podataka koji se šalju. Postoje identifikatori za poznate formate ( GSM, G.723 i slične ). Mogu se koristiti i drugi formati, tada se ova vrednost dinamički dodeljuje u skladu sa dogovorom dve strane.

Sequence number predstavlja slučajan broj koji predajna strana postavlja na početku sesije. U svakom narednom paketu broj se uvećava za jedan. Dakle, ovo polje služi za kontrolu toka na odredišnoj strani.

Timestamp polje označava vremensku oznaku koja nam govori trenutak kada je generisan prvi odbirak u okviru podataka koji se prenose datim paketom. Ovo vreme se dobija od generatora takta odabiranja na predajnoj strani, pri čemu se početna vrednost bira slučajno. Vrednost vremenske oznake u narednom paketu jednaka je vrednosti vremenske oznake datog paketa uvećanom za broj odbiraka datog paketa. Na primer, prvi paket ima vrednost vremenske oznake 1 i sadrži 10 govornih odbiraka. Dakle, sledeći paket će imati vrednost vremenske oznake 11.

Polje Synchronization source identifier predstavlja identifikator izvora sinhronizacije, odnosno izvora RTP toka. Izvor toka je entitet koji postavlja broj



sekvence i vremensku oznaku. U slučaju da mikser generiše tok, tada ovaj identifikator identifikuje mikser.

Polje Contributing source identifier predstavlja identifikator prvobitnih izvora, koji se koristi u slučaju miksera.

Postoji i RTCP protokol ( RTP Control Protocol ), koji ne prenosi korisnički saobraćaj. Nije obavezan protokol, ali se njegovo korišćenje preporučuje. Ovaj protokol definiše poruke koje se razmenjuju između učesnika sesije koje se odnose na kvalitet sesije ( broj izgubljenih paketa, kašnjenje itd. ).

Osnovna funkcija RTCP-a: Periodično razmenjivanje kontrolnih informacija koje se odnose na kvalitet

između učesnika sesije. Za svaki RTP tok koji prima, prijemna strana pravi izveštaj o prijemu.

Zatim se više izveštaja pakuje u jedan RTCP paket i šalje svim učesnicima sesije. Ove informacije se koriste za detektovanje i u nekim slučajevima za rešavanje problema prilikom prenosa podataka.

RFC 3550 definiše 4 funkcije RTCP-a: 1. Obezbeđivanje povratnih informacija koje se odnose na kvalitet

distribucije podataka. 2. RTCP sadrži kanoničko ime, CNAME - koristi se za združivanje više

tokova od jednog učesnika. 3. Kontrolisanje emisije RTCP paketa kako ne bi došlo do opterećenja

mreže. 4. Prenošenje minimalno kontrolisanih informacija, koje se koriste u slabo

kontrolisanim sesijama u kojima učesnici, bez kontrole pristupa, vrše pridruživanje i napuštanje sesije.

5 Internet transportni protokol: TCP

Ovo poglavlje je napisano na osnovu informacija prikupljenih sa interneta. UDP je jednostavan protokol, koji omogućava brzo slanje podataka drugom računaru sa minimumom intervencija protokola aplikacionog nivoa. Ne omogućava pouzdan prenos. U tom smislu, javila se potreba za drugim protokolom. Taj protokol se naziva TCP ( Transmission Control Protocol ).

5.1 Upoznavanje sa TCP-om

TCP predstavlja pouzdan protokol sa uspostavljanjem veze i garantuje isporuku poruka. Kod ovog protokola ostvaruje se logička veza “sa kraja na kraj”. Takođe omogućava full-duplex prenos podataka između dve aplikacije. Projektovan je tako da se dinamički prilagođava svojstvima kombinovane mreže i da bude otporan na mnoge havarije. TCP segment sadrži fiksno 20-bajtno zaglavlje i podatke ( kojih i ne mora da bude ). Za veličinu TCP segmenta postoje dva ograničenja. Prvo, svaki segment, zajedno sa TCP zaglavljem, mora da stane u polje za korisničke podatke IP paketa ( maksimalno 65.515 bajtova ). Drugo, za svaku mrežu postoji najveća jedinica prenosa ( engl. Maximum Transmission Unit, MTU ).



TCP servis je omogućen i klijentskoj i serverskoj strani kreiranjem krajnjih tačaka koje nazivamo socket. Socket predstavlja kombinaciju IP adrese i 16-bitnog broja koji identifikuje svaku od aplikacija jednog računara. Ovaj broj nazivamo port. Dakle, pomoću socket adrese jednoznačno se određuje jedna strana u komunikaciji. Više aplikacija, koje razlikujemo na osnovu vrednosti portova, mogu koristiti usluge istog protokola transportnog nivoa (multipleksiranje). A par socket-a klijentske i serverske strane jednoznačno definiše jednu TCP konekciju, odnosno logičku vezu između klijenta i servera. Prilikom povezivanja na neki server klijentska strana mora znati:

1. IP adresu servera. 2. Port koji ga određuje. Za najčešće korišćene aplikacije uvedeni su standardizovani portovi. Svi

klijenti ih znaju unapred, pre obraćanja serveru. Ovi portovi se nazivaju “dobro poznati“ ( well - known ports ). Neki od tih portova dati su u tabeli 2.

Port Protokol Upotreba 21 FTP Prenos datoteka 23 Telnet Daljinsko prijavljivanje 25 SMTP E-pošta 69 TFTP Trivijalni protokol za prenos datoteka 79 Finger Traženje informacija o korisniku 80 HTTP Web 110 POP-3 Daljinski pristup e-pošti 119 NNTP Diskusione grupe

Tabela 2. Neki dodeljeni portovi

Za well - known portove namenjeni su portovi od 1 do 1023. TCP i UDP koriste isti princip portova, ali se razlikovanje između ova dva

protokola vrši na osnovu polja protokola u IP zaglavlju. Portovi na strani klijenta: Server port klijentske aplikacije dobija se prilikom primanja zahteva za

određenim servisom. Portovi namenjeni klijentskoj strani mogu uzeti bilo koju vrednost iz skupa ( 1024-65535 ). Ovi portovi se dinamički dodeljuju kako bi se izbegla mogućnost da dve aplikacije u istom trenutku imaju istu vrednost porta.

5.2 TCP protokol

TCP konekcija podrazumeva tačno dva kraja koja komuniciraju ( end - 2 - end protocol ). Broadcasting i multicasting nisu primenljivi. Pre prenosa podataka mora se uspostaviti logička veza između datih aplikacija.

Raskidanje logičke veze između aplikacija vrši se nakon završetka prenosa.

Osobine TCP-a: Neprekidan tok podataka ( engl. stream - oriented ). Ovo se odnosi

na to da sve podatke koje aplikacija želi da pošalje predaje TCP-u,



bez obzira na njihovu veličinu. Aplikacija na odredištu podatke prima kontinualno, nezavisno od načina na koji su oni poslani.

Multipleksiranje / demultipleksiranje koje je ostvareno na isti način kao i u slučaju UDP-a, korišćenjem portova.

Pouzdanost. TCP garantuje ispravnu isporuku svih predatih mu podataka. Ispravnost podataka proverava se korišćenjem provere pariteta. Ispravan prijem segmenta odredište potvrđuje slanjem potvrde, tj. slanjem ACK poruke. Takođe se vrši i sortiranje pristiglih segmenata, kao i odbacivanje segmenata koji predstavljaju duplikate. Za svaki od poslatih segmenata startuje se tajmer koji određuje vreme čekanja na potvrdu. Nakon isteka tajmera vrši se retransmisija segmenata.

Kontrola toka podataka. Ogleda se u tome da pošiljalac može da pošalje samo onoliko podataka koliko u tom trenutku prijemnik može da memoriše i obradi. Kontrola toka podataka ostvarena je korišćenjem mehanizma pod nazivom “klizeći prozor” (sliding window).

Na slici 11. prikazan je format TCP zaglavlja.

Slika 11. Format TCP zaglavlja

Objašnjenje pojedinih polja: Polje source port predstavlja broj porta izvora koji određuje aplikaciju na

predajnoj strani. Polje destination port predstavlja broj porta odredišta koji određuje

aplikaciju na prijemnoj strani. Sequence number, tj. redni broj prvog bajta podataka sadržanih u datom

TCP segmentu. Prilikom uspostavljanja TCP konekcije, strana koja šalje podatke na slučaj odabira vrednost početnog rednog broja ( ISN - Initial Sequence



Number ). Redni broj svakog od bajta podataka određuje se uvećavanjem ISN-a u koracima od po jedan za svaki novi bajt.

Acknowledgement number predstavlja redni broj potvrde. Služi za potvrdu ispravnog prijema poslatih paketa. Ovim poljem istovremeno se potvrđuje ispravan prijem svih bajtova poslatih pre ACK-a. Pri tome, bajtovi koji se potvrđuju ne moraju pripadati istim segmentima.

Polje TCP header length označava dužinu zaglavlja koja sadrži dužinu TCP zaglavlja u 32 - bitnim rečima.

Biti URG, ACK, PSH, RST, SYN, FIN označavaju flegove ili zastavice. Dakle, postoji šest flegova.

Pomoću polja window size prijemnik oglašava veličinu prozora, odnosno veličinu slobodnog prostora u prijemnom baferu.

Checksum označava proveru pariteta koja se na predajnoj strani računa za ceo TCP segmenta. Ova provera se vrši samo na odredištu.

Urgent pointer polje, tj. pokazivač na hitne podatke služi za označavanje dela sekvence podataka koji je potrebno posebno hitno isporučiti odredištu.

Polje options se najčešće koristi za definisanje maksimalne dužine segmenta ( MSS - Maximum Segment Size ) koju je jedan kraj konekcije spreman da primi.

U data polje su smešteni podaci primljeni od aplikacije.

6 SIP protokol

Ovo poglavlje je napisano na osnovu knjige ″Encyclopedia of Networking and Telecommunications″ koju je napisao Thomas Sheldon. SIP je skraćenica za Session Initiation Protocol, kontrolni protokol aplikacijskog sloja koji je razvijen unutar IETF-a Internet Engineering Task Force. Dizajniran je tako da omogućava jednostavnu implementaciju, dobru skalabilnost i fleksibilnost. Specifikacija je data u nekoliko RFC-ova. Najvažniji, RFC 3261, sadrži osnovu protokola. Postoji mnogo aplikacija na internetu koje zahtevaju kreiranje i upravljanje sesijama, gde je sesija upotrebljena za razmenu podataka između učesnika u komunikaciji. Implementacija ovih aplikacija je veoma komplikovana u praksi od strane učesnika: korisnici mogu da se menjaju na krajevima, mogu da se adresiraju sa više naziva i mogu da komuniciraju preko različitih posrednika po nekad simultano.

SIP nije zamišljen da bude sveobuhvatan, pa će za komunikaciju među uređajima biti potrebni i drugi protokoli. Njegova namena je da omogući komunikaciju koja se nakon toga odvija na različite načine, pa i pomoću nekog drugog protokola. Uz SIP se najčešće koriste protokoli RTP i SDP. SIP radi u skladu sa ovim protokolima omogućujući krajnjim korisnicima (user agents) da prepoznaju jedni druge i da se dogovore za tip sesije koji žele da dele. Za pronalaženje mogućeg korisnika, i ostale funkcije, SIP uključuje infrastrukturu proxy servera za koje korisnički agent može da pošalje registraciju, poziv za sesiju, i druge zahteve. SIP može da uspostavi sesiju između dva korisnika (običnu telefonsku vezu), sesiju izmedu više korisnika (od kojih svaka može da sluša i da govori) i višesmernu sesiju (između jednog pošiljaoca i više primalaca).



SIP je dizajniran u skladu s Internet modelom. To je end-to-end tip signalnog protokola što znači da je logika, osim usmeravanja SIP poruka, čuvanja na krajnjim uređajima. Stanje sesije je takođe sačuvano na krajnjim uređajima, ne postoji jedinstvena tačka ispada. Mreže koje su dizajnirane na taj način dobro skaliraju. Loša strana ovog tipa je veće zaglavlje.

Slika 12. Položaj SIP-a u odnosu na ostale protokole

6.1 Struktura protokola

Protokol SIP je strukturiran kao slojevit protokol, pri čemu svaki sloj definiše određen skup pravila. Elementi koje taj protokol specificira su logički elementi. Svaki element protokola ne mora sadržati svaki od slojeva. Nadalje, kada se kaže da neki element sadrži određen sloj, to zapravo znači da taj element poštuje skup pravila koje taj sloj definiše.

Najniži sloj protokola SIP je njegova sintaksa i kodiranje (syntax and encoding) koji koristi ABNF (Augmented Backup-Naur Form) pravila

Drugi sloj je transportni sloj (transport layer) koji definiše kako klijent i server šalje zahteve i prima odgovore putem mreže. Sve komponente protokola SIP moraju implementirati protokol korisničkih datagrama (UDP – User Datagram Protocol) i protokol upravljanja prenosom (TCP – Transmission Control Protocol), ali mogu i podržavati i druge protokole, kao što je protokol za kontrolu transmisije toka podataka (SCTP – Stream Control Transmission Protocol). Budući da je UDP nepouzdan protokol, SIP ima vlastiti mehanizam retransmisije koji uključuje i three-way razmenu između korisnika prilikom uspostavljanja sesije.

Treći sloj transakcijski sloj (transnaction layer) koji upravlja retransmisijama aplikacijskog sloja, povezivanjem odgovora i zahteva, kao i o isteku vremena aplikacijskog sloja (application



layer timeouts). Transakcija je temeljna komponenta protokola SIP koja se sastoji od zahteva te jednog ili više odgovora. Transakcijski sloj sadrži klijent i server komponentu, od kojih je svaka predstavljena automatom stanja koji je konstruisan kako bi obradio određeni zahtev. Klijent transakcija šalje zahteve i prosleđuje odgovore korisniku transakcije pa je odgovorna za pouzdanu retransmisiju zahteva u slučajevima kada se koristi nepouzdani transport UDP.

Iznad transakcijskoga sloja se nalazi sloj korisnika transakcije (TU – Transaction User). Svi su entiteti (logičke komponente) protokola SIP, osim stateless proxy servera, korisnici transakcije TU. Kada korisnik transakcije želi poslati zahtev, mora kreirati klijent transakciju a zatim joj proslediti zahtev zajedno sa IP adresom, portom i transportom kojem treba poslati zahtev.

Slika 13. Struktura SIP protokola

6.2 Adresiranje

Umesto IP adresom, odredište u protokolu SIP može biti predstavljeno URI-jem koji ima isti format kao i adresa i u skladu s tim ispravna SIP adresa može biti sip:[email protected]. Korišćenje URI-a implicira upotrebu sistema imena domena (DNS – Domain Name System), kako bi se imena čvora (host) i domena mogla mapirati u IP adrese.

Povezanost protokola SIP i DNS-a omogućava interoperabilnost telefonskih sistema i mehanizma adresiranja. Podržavanje E.164 brojeva u DNS-u (ENUM) omogućava SIP klijentima i serverima da šalju i primaju telefonske brojeve umesto SIP URI-a u porukama pa ih usmeravaju u razumljivom obliku.

Osim SIP URI-a podržan je i SIPS URI, koji podrazumeva primenu sigurnosnog mehanizma. Poziv prema SIPS URI-u garantuje da je siguran,



kriptografski zaštićen transport (TLS – Transport Layer Security) korišćen za prenos svih SIP poruka od onoga ko zove do domena pozvanog. SIP URI i SIPS URI moraju sadržati ime čvora pa mogu sadržati i ime korisnika i broj portova. Uz SIP URI i SIPS URI mogu se koristiti i drugi kao što su TEL URL i TEL URI:

o sip:[email protected] o sip:+381-64-365-5555:[email protected]; user=-phone o sips:[email protected] o sip:proxy.server1.com:5060 o sip:another-proxy.server1.com; transport=UDP o tel:+381-64-365-5555

6.3 SIP mrežni elementi

Iako je kod najjednostavnije implementacije moguće koristiti samo dva korisnička klijenta koji ravnopravno međusobno šalju SIP poruke, tipična SIP mreža sastoji se od više vrsta SIP elemenata. Osnovni elementi su korisnički agenti (User Agents), proxy, register i redirect serveri. SIP elementi su samo logičke jedinice. Često ih je korisno spojiti, na primer, kako bi se povećala brzina obrade, ali to zavisi od pojedinačne implementacije i konfiguracije.

Slika 14. Osnovni elementi SIP arhitekture

6.3.1 Korisnički agenti (UA - User Agents)

Krajnje tačke koje koriste SIP za međusobno pronalaženje i pregovaranje o karakteristikama sesije nazivaju se korisnički agenti (user agents). Obično se nalaze na korisničkom računaru u obliku aplikacije. To je trenutno najrašireniji oblik. Korisnički agenti mogu biti i mobilni telefoni, PSTN gateway, PDA uređaji, automatizovani IVR sistemi itd.

Korisničke agente često nazivamo server korisničkog agenta (User Agent Server - UAS) i klijent korisničkog agenta (User Agent Client - UAC). UAS i UAC



su samo logičke jedinice, svaki korisnički agent, zavisno od situacije, ima ulogu UAC-a ili UAS-a. UAC je deo korisničkog agenta koji ima zadatak slanja zahteva (request) i primanja odgovora (response). UAS je takođe deo korisničkog agenta, ali on ima zadatak primanja zahteva i slanja odgovora.

Budući da korisnički agent sadrži i UAC i UAS, često kažemo da se korisnički agent ponaša kao UAC ili UAS. Na primer, korisnički agent koji poziva ponaša se kao UAC kada šalje INVITE zahteve i prima odgovore na zahtev. Kao UAS ponaša se kad primi INVITE zahtev i pošalje odgovore.

Ali ta se situacija menja kad pozvana strana odluči poslati BYE i prekinuti sesiju. U tom se slučaju korisnički agent pozvane strane (koji šalje BYE) ponaša kao UAC a korisnički agent koji je pozivalac kao UAS.

Slika 15. Direktna komunikacija bez proxy servera

6.3.2 Proxy server Osim toga, SIP omogućava izgradnju infrastrukture s mrežnim računarima

koja se zovu proxy serveri. Korisnički agenti mogu slati poruke (messages) proxy serveru. Proxy serveri su vrlo važni entiteti u SIP infrastrukturi, usmeravaju poruke za kreiranje sesije s obzirom na trenutnu lokaciju pozvane strane, obavljaju autentikaciju korisnika, očitavanje i ostale važne funkcije.

Najvažniji zadatak proxy servera je usmeravanje poruka za kreiranje sesije prema pozvanoj strani. Zahtev za kreiranje sesije obično prelazi nekoliko proxy servera dok ne pronađe onoga koji zna stvarnu lokaciju pozvane strane. Tada će proxy server direktno proslediti zahtev za sesijom prema pozvanoj strani koji će prihvatiti ili odbiti zahtev.



Slika 16. Komunikacija sa proxy serverom

Postoje dve osnovne vrste SIP proxy servera - bez stanja transakcije

(stateless) i sa stanjem transakcije (stateful).

6.3.2.1 Proxy server bez stanja transakcije (stateless)

Stateless serveri su jednostavni prosleđivači poruka. Oni prosleđuju poruke nezavisno jedne od drugih, iako su poruke često složene u transakcije. Ovakvi proxy serveri su jednostavniji, ali brži od statefull proxy servera. Mogu se koristiti kao jednostavni raspoređivači opterećenja, prevodioci poruka i ruteri.

Loša kod stateless proxy servera je to što ne mogu da prepoznaju i spreče retransmisiju poruka i vrše naprednije rutiranje, na primer, SIP proxy server može poslati jednu SIP poruku na više destinacija (forking) ili kada proxy server primi negativan odgovor za zahtev koji je prosledio, pa ponovo šalje zahtev prema nekoj drugoj destinaciji usmeravanja (recursive).

6.3.2.2 Proxy server sa stanjem transakcije (stateful)

Statefull proxy serveri su složeniji. Ovakvi proxy serveri ne tretiraju pojedinačne poruke već formiraju transakcije. Nakon prijema zahteva, statefull proxy serveri kreiraju stanje i čuvaju ga sve dok se transakcija ne završi.

Statefull proxy server upravlja dvema vrstama transakcija: serverske transakcije koje primaju zahteve i šalju odgovore, kao i klijentske transakcije koje šalju zahteve i primaju odgovore. Dolazeći zahtev se obrađuje serverskom transakcijom i dalje se prosleđuje uz pomoć jedne ili više klijentskih transakcija (više transakcija se formira u slučaju račvanja). Dolazeći odgovor prima odgovarajuća klijentska transakcija i prosleđuje se odgovarajućoj serverskoj transakciji.



6.3.3 Redirect server

Entitet koji prima zahtev i šalje odgovor koji sadrži listu trenutnih lokacija određenog korisnika se naziva server redirekcije (redirect server). Server redirekcije preuzima i traži željenog korisnika u bazi koju je kreirao registrar. Listu trenutnih lokacija šalje izvoru zahteva koji na osnovu te liste šalje zahteve direktno korisniku kojeg želi da kontaktira.

Slika 17. Tok poziva sa redirect serverom

6.3.4 Registrar

Registrar je specijalni entitet koji prihvata registracije od korisnika, izdvaja informacije o njihovoj trenutnoj lokaciji (recimo IP adresu, port i korisničko ime) i skladišti ove informacije u bazu podataka. Zatim se baza podataka sa lokacijama koristi da bi se odredilo gde se šalje zahtev za određenog korisnika.

Registrari obrađuju REGISTER poruke koje generišu klijenti za željom da uspostave ili prekinu mapiranje između svoje opšte poznate SIP adrese i adrese na koju žele da budu kontaktirani. REGISTER zahtev se može koristiti i za pregled mapiranja postavljenih za određenu adresu.

Svaki registrar obrađuje zahteve za određeni skup domena i može autentifikovati REGISTER zahteve upotrebom odgovora 401 (Unauthenticated). Registrari su najčešće logički entiteti i zbog tesne veze sa proxy serverima se često nalaze na istom mestu.



Slika 18. REGISTRAR zahteva

6.4 SIP poruke

Komunikacija pomoću SIP protokla, koja se često naziva i signalizacija, sastoji se od niza poruka (messages). Uobičajeno je da se svaka poruka prenosi u posebnom UDP datagramu. Svaka se poruka sastoji od “početne linije“, zaglavlja poruke i tela poruke. Početna linija označava vrstu poruke. Postoje dve vrste poruka – zahtevi (request) i odgovori (response). Zahtevi se obično koriste za iniciranje neke akcije ili za obaveštavanje pozvane strane zahteva o nečemu. Odgovori se koriste za potvrđivanje da je zahtev primljen i obrađen pa sadrže i status obrade.

INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 192.168.0.3: 51660;received=66.87.48.68 From: sip:[email protected] To:sip:[email protected];tag=794fe65c16edfdf45da4fc39a5d286c.b713 Call-ID: [email protected] CSeq: 2 INVITE Contact: <sip:user3@domen:51660;transport=udp>;q=0.00;expires=120 User-Agent: Sip EXpress router (0.8.11pre21xrc (i386/linux)) Content-Length: 451

Slika 19. Izgled SIP zahteva

Prva linija prikazuje da se radi o INVITE poruci za kreiranje sesije. URI u

prvoj liniji naziva se Request- URI i sadrži URI sledećeg koraka poruke (next hop). U ovom slučaju to je 192.168.0.3 i port je 51660.

Iz From i To polja zaglavlja se indetifikuju pozivalac (caller) i pozvana strana (callee). From polje zaglavlja sadrži parametar tag koji služi kao identifikator dijaloga.



Call-ID polje zaglavlja je identifikator dijaloga i njegova svrha je identifikacija poruka koje pripadaju istom pozivu. Takve poruke imaju isti Call-ID identifikator.

CSeq služi kako bi se zadržao ispravan redosled zahteva, jer se zahtevi šalju UDP protokolom koji može promeniti redosled poruka.

Contact polje zaglavlja sadrži IP adresu i port na kojem pozvana strana čeka zahteve koje šalje pozivalac.

Telo INVITE poruke sadrži opis tipa medija koje pozvana strana prima, kodiranih u SDPu.

6.5 SIP zahtevi Postoji više vrsta SIP zahteva i svaki od njih ima određene osobine. Najvažniji zahtevi su:

INVITE – ova poruka se koristi za uspostavljanje sesije. Takođe se sa njom mogu menjati parametri poziva (re-INVITE).

ACK – poruka kojom se potvrđuje prijem završnog odgovora na INVITE. Uspostavljanje sesije se vrši preko 3-way hand-shaking zbog asimetrrične prirode poziva.

BYE – koristi se da bi se prekinula sesija. Strana koja želi da prekine sesiju šalje BYE drugoj strani.

CANCEL – koristi se za prekid još neuspostavljenih sesija. Ukoliko pozvani korisnik nije odgovorio, a korisnik koji je inicirao poziv želi da prekine poziv (tipično kada pozvani korisnik ne odgovara neko vreme).

REGISTER – svrha REGISTER zahteva je da se registraru dostavi trenutna lokacija korisnika. Preko REGISTER poruka se prenose inforamcije o trenutnoj IP adresi i portu na kome se može doći do korisnika.

OPTIONS – korsti se da bi se saznale mogućnosti druge strane u sesiji.

INFO – služi za slanje informacija u toku sesije koje ne menjaju stanje sesije.

6.6 SIP odgovori

Kad korisnički agenti ili proxy server prime zahtev, šalju odgovor. Na svaki zahtev mora se odgovoriti. Izuzetak su ACK zahtevi na koje ne treba odgovarati.

Kôd odgovora je celi broj od 100 do 699 i ukazuje na vrstu odgovora. Postoji 6 grupa odgovora:

1xx su privremeni odgovori koji pozvanoj strani kažu da je određeni zahtev primljen ali rezultat obrade još nije poznat. Šalju se jedino u slučaju kada se obrada ne završi odmah (npr. 100 Trying). Pozivalac mora zaustaviti slanje zahteva kad primi privremeni odgovor. Tipično proxy serveri odgovoraju šifrom 100 kad počnu



obrađivati INVITE, a korisnički agenti šalju odgovore sa šifrom 180 (Ringing), što znači da telefon pozvane strane zvoni.

2xx odgovori su pozitivni završni odgovori. Završni odgovor je konačni odgovor koji će pozivalac zahteva primiti. To znači da završni odgovori označavaju rezultat obrade određenog zahteva. Završni odgovori takođe prekidaju transakcije. Šifre od 200 do 299 su pozitivni odgovori što znači da je zahtev obrađen uspešno. Na primer, odgovor 200 OK šalje se kad korisnik prihvati poziv za uspostavljanje sesije (INVITE zahtev). UAC može primiti nekoliko poruka tipa 200 kod jednog INVITE zahteva. Razlog tome je što forking proxy server može deliti zahtev, kontaktirati nekoliko UAS-a, a svaki od njih će prihvatiti poziv. U ovom slučaju svaki odgovor se razlikuje po tag parametru u polju To zaglavlja. Svaki odgovor predstavlja jedinstven dijalog s jednoznačnim identifikatorom dijaloga.

3xx odgovori koriste se za preusmeravanje pozivalaca. Odgovor o preusmeravanju daje informaciju o novoj lokaciji korisnika ili alternativnoj usluzi koju pozivalac može upotrebiti za ostvarenje poziva. Odgovore o preusmeravanju obično šalju proxy serveri. Kad proxy primi zahtev, a ne želi ga ili ne može obraditi iz nekog razloga, tada će pozivaocu poslati odgovor o preusmeravanju i navesti drugu lokaciju sa kojom pozivalac može pokušati da uspostavi sesiju. To može biti lokacija nekog drugog proxy servera ili trenutna lokacija pozvane strane (iz lokacijske baze podataka koju je kreirao registrar). Pozivalac bi tada trebao ponovno da pošalje zahtev na novu lokaciju. 3xx odgovori su završni.

4xx su negativni završni odgovori. 4xx odgovor znači da je problem na strani pozivaoca. Zahtev se nije obradio jer sadrži pogrešnu sintaksu ili se ne može izvršiti na tom serveru.

5xx znači da je problem na strani servera. Zahtev je naizgled ispravan ali ga server nije obradio. Klijenti bi po pravilu trebali kasnije da ponove zahtev.

6xx znači da se zahtev ne može izvršiti ni na jednom serveru. Ovaj odgovor obično šalje server koji ima konačnu informaciju o određenom korisniku. Korisnički agenti obično šalju odgovor 603 Decline kada korisnik ne želi da učestvuje u sesiji.

6.7 Transakcije

Iako smo rekli da se SIP poruke šalju nezavisno, obično ih u transakcije dele korinički agenti i određene vrste proxy servera. Dakle, za SIP se kaže da je transakcijski protokol.

Transakcija je niz SIP poruka koje se razmenjuju između elemenata SIP mreže, a sastoji se od jednog zahteva i svih odgovora na taj zahtev. To uključuje nula ili nekoliko privremenih odgovora, jedan ili više završnih odgovora. Na INVITE se može odgovoriti s više završnih odgovora kad proxy server deli zahtev (forking).



Ako je transakciju pokrenuo INVITE zahtev, tada ona uključuje i ACK, ali samo ako završni odgovor nije bio 2xx. Ako je završni odgovor bio 2xx, tada se ACK ne smatra delom transakcije. Kao što vidimo, radi se o prilično asimetričnom ponašanju - ACK je deo transakcija s negativnim završnim odgovorom, ali nije deo transakcija s pozitivnim završnim odgovorima. Razlog je takvog razdvajanja važnost isporuke svih 200 OK poruka. Ne samo da one uspostavljaju sesiju, već ih mogu generisati i višestruki entiteti kada proxy server deli zahtev, a sve se takve poruke moraju isporučiti korisničkom agentu koji inicira sesiju. U takvom slučaju korisnički agenti preuzimaju odgovornost i retransmitiraju 200 OK odgovore dok ne prime ACK. Može se primetiti da se jedino odgovori na INVITE poruke retransmisuju!

Slika 20. SIP transakcija

SIP entiteti koji su sposobni za praćenje transakcije nazivaju se entiteti sa

stanjem transakcije (stateful). Takvi entiteti obično stvaraju stanje povezano s transakcijom koja se čuva u memoriji za vreme trajanja transakcije. Kad se primi zahtev ili odgovor, entitet sa stanjem transakcije pokušava povezati zahtev (ili odgovor) s postojećim transakcijama. Za to je potrebno ekstraktovati jedinstveni identifikator transakcije iz poruke i uporediti ga s identifikatorima svih postojećih transakcija. Ako takva transakcija postoji, tada se stanje identifikatora ažurira iz poruke.

U prethodnom RFC 2543 identifikator transakcije izračunavao se kao hash svih polja u zaglavlju poruke (uključujući To, From, Request-URI i CSeq). To se



pokazalo sporim i komplkovanim, za vreme sprovođenja testova interoperabilnosti takvi su identifikatori transakcija bili uobičajeni izvori problema.

U kasnijem RFC 3261 način izračunavanja identifikatora transakcija u potpunosti je promenjen. Umesto komplikovanog hashinga važnih polja u zaglavlju, SIP poruka sada direktno uključuje identifikator. Branch parameter polja Via u zaglavlju direktno uključuje identifikator transakcije. To je značajno pojednostavljenje, ali još su uvek prisutne implementacije koji ne podržavaju novi način, a nove implementacije za sada moraju biti kompatibilne.

6.8 Dijalozi

Pokazali smo šta su transakcije, da jedna transakcije uključuje INVITE poruku i njene odgovore, a druga transakcija uključuje BYE poruku i njene odgovore kada se sesija prekida. Ali te dve transakcije bi trebale na neki način da budu povezane - obe spadaju u isti dijalog (dialog). Dijalog predstavlja peer-to-peer SIP odnos između dva korisnička agenta. Dijalog traje neko vreme pa predstavlja vrlo važan koncept za korisničke agente. Dijalozi olakšavaju pravilno određivanje redosleda (sequencing) i usmeravanje poruka između SIP krajnjih tačaka.

Dijalozi se identifikuju pomoću Call-ID, From etikete i To etikete (tag). Poruke u kojima ta tri identifikatora imaju iste vrednosti, spadaju u isti dijalog. Pokazali smo da se polje CSeq u zaglavlju koristi za slaganje poruka po redu, to jest za redosled poruka unutar dijaloga. Broj mora da raste po veličini za svaku poruku unutar dijaloga inače će ga peer obraditi kao neispravan zahtev ili retransmisiju. U stvari, CSeq broj identifikuje transakciju unutar dijaloga, jer smo rekli da se zahtevi i povezani odgovori nazivaju transakcija. To znači da unutar dijaloga može biti aktivna samo jedna transakcija u svakom pravcu. Mogli bismo takođe reći da je dijalog sekvenca transakcija. Sledeća slika prikazuje koje poruke spadaju u isti dijalog.

Slika 21. SIP dijalog



Neke poruke uspostavljaju dijalog, a druge ne. Na taj se način jasno može pokazati odnos poruka i slati poruke koje nisu povezane s ostalim porukama izvan dijaloga. To olakšava implementaciju, jer korisnički agenti ne moraju održavati stanje dijaloga. Na primer, INVITE poruka uspostavlja dijalog, jer će nakon nje uslediti BYE zahtev koji prekida sesiju. BYE zahtev šalje se unutar dijaloga koji je uspostavila INVITE poruka.

7 MEGACO

Ovo poglavlje je napisano na osnovu slajdova sa vežbi koje je održavala profesorica Tatjana Lončar Turukalo. Ako posmatramo VoIP mrežu i klasičnu telefonsku PSTN (Public Switched Telephone Network) mrežu kao dve odvojene mreže, elegantna integracija ove dve mreže u jedan sistem podrazumeva da korisnik jedne mreže kontaktira (uspostavlja telefonski poziv) korisnika druge mreže i ostvaruje željeni servis na isti način kao da se oba korisnika nalaze na istoj mreži. U osnovi, to znači da mreže treba povezati uređajima (gejtvejima) koji će obezbediti konverziju dva osnovna informaciona toka u okviru telefonske mreže: signalizacionog toka i toka prenosa govornog signala.

Slika 22. Razdvojenost funkcija signalizacije i prenosa govora

Putanje kroz mrežu kojima se prenosi govorni signal i njemu pridružene signalizacione poruke ne moraju biti iste, što je koncept nasleđen još od uvođenja SS7 (Signaling System No. 7) arhitekture (signalizacija po odvojenom kanalu). Stoga i sami gejtveji između PSTN i IP mreže mogu da sadrže odvojeno funkcije koje se bave obradom i translacijom signalizacije i funkcije koje vrše konverziju toka govornog signala, kao što je prikazano na slici (Slika 22). Funkcije koje se bave obradom signalizacionih poruka deo su globalnog sistema kontrole poziva (Call Control) i povezuju odgovarajuće delove za kontrolu poziva unutar PSTN i IP mreže. Deo za konverziju govornog signala pripada globalnom sistemu prenosa čiji je zadatak ostvarenje potreba korisnika koje diktira upravo deo za kontrolu poziva.



Kako su signalizacioni elementi sistema i elementi sistema prenosa govornog signala logički razdvojeni, nema razloga da, ukoliko to ima smisla, ne dođe i do njihovog fizičkog odvajanja. Drugim rečima, nema potrebe da svaki gejtvej sadrži obe funkcije. Sada možemo govoriti o podeli na dva tipa gejtveja na spoju između PSTN i IP mreže:

• MGC (Media Gateway Controller) – mrežni element čiji je zadatak obrada signalizacionih poruka i ostvarenje funkcije kontrole poziva, i • MG (Media Gateway) – gejtvej čiji je zadatak konverzija govornog signala iz PSTN mreže sa komutacijom kola u IP mrežu sa komutacijom paketa. Kao posledica obavljanja funkcije kontrole poziva, MGC u master/slave

maniru komunicira sa jednim ili više MG-a prenoseći im direktna uputstva za rad. Komunikacija između MGC-a i MG-a odigrava se po standardizovanim komunikacionim protokolima od kojih su se vremenom izdvojila dva dominantna:

• Media Gateway Control Protocol (MGCP) i • MEGACO/H.248 protokol. Istovremeno, kao standard za komunikaciju između MGC-a i elemenata IP

mreže za kontrolu VoIP poziva, izdvojio se Session Initiation Protocol (SIP). Na ovaj način došlo se do arhitekture kombinovane PSTN/IP mreže prikazane na slici (Slika 23), poznate pod nazivom Softswitch arhitektura.

Slika 23. Softsvič arhitektura

U Softsvič arhitekturi upotreba SIP protokola kao signalizacionog protokola u IP delu mreže čini MGC-e istovremeno i SIP user agent-ima (elementima SIP mreže). Na strani PSTN mreže danas standardno očekujemo ISUP SS7 signalizacioni protokol, tako da je uloga MGC-a zapravo translacija SIP/ISUP signalizacije. Na interfejsima između MGC-a i MG-a danas su dominantni već pomenuti MGCP i MEGACO/H.248.



MEGACO protokol je alternativa MGCP protokolu nastala kao jedan od prvih pokušaja IETF-a i ITU-T-a da ostvare zajedničku saradnju. Kao rezultat nastao je protokol sa dva radna naziva, MEGACO koji je u upotrebi od strane IETF-a, i H.248 koji je u upotrebi od strane ITUT- a. U osnovi, kao i kod MGCP-a, u pitanju je protokol koji definiše komunikaciju između signalizacionog MGC-a i MG medija gejtveja. Razmenom MEGACO poruka između MGC-a i MG-a ostvaruju se osnovne funkcije uspostavljanja i raskidanja poziva u okviru NGN (Next Generation Networks) mreže.

MEGACO arhitektura u potpunosti prati koncept uveden MGCP protokolom. Osnovni funkcionalni elementi su element upravljanja pozivima, odnosno signalizacionim porukama, MGC, i gejtvej za konverziju transportovanih podataka, MG. MGC vrši osnovne signalizacione funkcije poput uspostavljanja i raskidanja poziva, i odgovara ulozi MGC-a tj. Call Agent-a u MGCP mreži. MG u MEGACO mreži, poput istoimenih uređaja u MGCP mreži, vrši konverziju podataka koji se prenose, najčešće iz TDM orijentisanog PSTN/ISDN dolaznog toka u IP paketski tok.

MEGACO je protokol koji opisuje komunikaciju između MGC i MG elemenata. Komunikacija se odvija razmenom transakcionih zahteva (transaction request) koji sadrže jednu ili više komandi (commands) i transakcionih odgovora (transaction reply) koji sadrže jedan ili više odgovora (responses). Najčešće je MGC izvor transakcionih zahteva, a MG transakcionih odgovora, ali moguća je komunikacija i u suprotnom smeru.

7.1 MEGACO terminologija

Osnovni zadatak MEGACO protokola jeste komunikacija MGC i MG-a u cilju uspostavljanja (npr. govornog) servisa između različitih mreža (najčešće PSTN i IP mreže). MGC-i zaduženi su za prihvat, procesiranje, konverziju i prosleđivanje signalizacionih poruka kontrole poziva. Tako npr. signalizacione poruke kontrole poziva (npr. uspostavljanja ili raskidanja) mogu na MGC da pristignu kao deo korisničke DSS1 ISDN signalizacije. Po njihovoj obradi u MGC-u, vrši se uspostavljanje veze i razmena poruka između odgovarajućih MGC-a najčešće upotrebom SIP protokola. Istovremeno sa tom razmenom poruka, u odgovarajućim trenucima, MGC upotrebom MEGACO protokola daje uputstva odgovarajućem MG-u na putanji podataka da uspostavi/raskine odgovarajući govorni kanal, tj. realizuje njegov transfer na prelazu iz npr. ISDN u IP mrežu. Dakle, uloga MEGACO protokola je u upravljanju MG-om koji se nalazi na putanji podataka od strane MGC-a koji se nalazi na putanji signalizacije.

Za ispravno referenciranje na odgovarajuće elemente MEGACO protokola uvedena je odgovarajuća MEGACO terminologija. U osnovne pojmove ove terminologije spadaju poruke (messages), transakcije (transactions), komande (commands), konteksti (contexts) i terminacije (terminations). Ovi pojmovi opisuju elemente razmene između MGC i MG-a kao i elemente koji nastaju kao posledice ove razmene.



7.2 MEGACO poruke

Poruka je hijerarhijski najviši element razmene MEGACO protokola. Jedna poruka može da sadrži jednu ili više transakcija. Poruka predstavlja skup više transakcija, kada jedna strana u komunikaciji ima potrebu da trenutno pošalje veći broj transakcija. Transakcije se mogu generisati i slati i pojedinačno, bez pakovanja u poruke, o čemu će biti reči u nastavku.

Sintaksa poruke započinje ključnom rečju MEGACO, posle čega sledi kosa crta (slash), verzija MEGACO protokola, ID broj poruke (mId) i telo poruke (koje se najčešće sastoji iz više transakcija). MId je najčešće domensko ime ili kombinacija IP adresa/port entiteta koji emituje poruku. Transakcije unutar jedne poruke tretiraju se i procesiraju nezavisno. Redosled transakcija unutar poruke ne diktira redosled kojim će transakcije biti obrađivane na prijemnoj strani. Primer sintakse poruke prikazan je u sledećih nekoliko redova teksta: MEGACO/1.0 [147.91.133.1]:2045 Transaction = 142 {

Context = 12 { Command 1,

Command 2, …

} Context = $ {

Command 1, Command 2, …

} }

7.3 MEGACO transakcije

MEGACO transakcije obuhvataju upućivanje komandi (Commands) i odgovora na komande (Responds). Transakcije se razmenjuju između MGC i MG-a i odnose se na neku akciju koju je potrebno izvršiti. Akcija se najčešće odnosi samo na jednu ili podskup konekcija koje prolaze preko MG-a (videti pojmove kontekst i terminacija u nastavku).

Transakcije se razmenjuju u okviru transakcionih zahteva (Transaction Request), koji mogu da sadrže veći broj komandi. Komande mogu da se odnose na jednu ili više konekcija (konteksta) trenutno aktivnih preko MG-a. Moguće je da transakcioni zahtevi sadrže samo jednu komandu koja se odnosi na samo jednu konekciju (kontekst).

Sintaksa transakcionog zahteva je veoma jednostavna. Posle ključne reči TransactionRequest, unutar vitičastih zagrada navodi se 32-bitni TransactionID, posle čega sledi niz komandi. Komande su grupisane prema konekcijama (kontekstima) na koje se odnose, a detalji o sintaksi ovog dela ostavljeni su za kraj odeljka (nakon upoznavanja sa kontekstima i terminacijama).

Po prijemu transakcionog zahteva vrši se sekvencijalna obrada komandi u zahtevu (za razliku od obrade transakcija unutar poruke koja ne mora biti



sekvencijalna). Po obradi svih komandi, prijemnik formira i šalje transakcioni odgovor (Transaction Reply). Transakcioni odgovor je slične strukture kao transakcioni zahtev, s tim što umesto komandi sadrži odgovore. Ako je prijemniku za procesiranje transakcionog zahteva potrebno više vremena, pa će samim tim trenutak emitovanja transakcionog odgovora kasniti, moguće je da prijemnik prvo emituje potvrdu o prijemu transakcionog zahteva (Transaction Pending), a zatim po završetku obrade zahteva i transakcioni odgovor.

7.4 MEGACO terminacije i konteksti Prethodni pojmovi odnose se na nazive elemenata koji se razmenjuju

MEGACO protokolom između MGC-a i MG-a. Svaki od njih izaziva odgovarajuće akcije koje utiču na rad pre svega MG-a i omogućuju mu da rukuje konekcijama koje su uspostavljene preko njega. Kako bi ove konekcije ispravno referencirali, uvedeni su odgovarajući MEGACO pojmovi.

Terminacije se odnose na izvore ili odredišta toka podataka na MG-u. Terminacije mogu biti fizički resursi (npr. analogna PSTN linija ili E0 kanal TDM multipleksa) i tada ih nazivamo semi-permanentne terminacije (semi-permanent terminations), ili logički resursi koji postoje samo za vreme trajanja poziva (npr. RTP/IP sesija) kada ih nazivamo kratkotrajne terminacije (ephemeral terminations). Kratkotrajne terminacije se kreiraju Add komandom MEGACO protokola, a brišu Subtract komandom. U zavisnosti od tipa terminacije razlikuju se osobine terminacije i skupovi parametara koji ih opisuju. Parametri koji opisuju terminaciju grupišu se u skup tzv. deskriptora (descriptors). Deskriptori se uključuju kao parametri MEGACO komandi kako bi se određeni parametri terminacije inicijalizovali ili menjali vremenom. Svaka terminacija identifikuje se TerminationID brojem. Upotreba wildcard karaktera pri referenciranju na terminacije je dozvoljena pa se koriste tzv. all (*) i choose ($) karakteri

Terminacije su samo krajnje tačke u okviru MG-a koje donose ili odnose tok podataka. Zadatak MG-a je da ove terminacije interno poveže na odgovarajući način kako bi obezbedio uspostavljanje konekcija (npr. poziva). Stoga je potrebno identifikovati podskupove terminacija u okviru MG-a kojima je dozvoljeno da međusobno razmenjuju podatke. Ovi podskupovi predstavljaju konekcije koje se uspostavljaju preko MG-a i nazivaju se konteksti.

Terminacija se dodaje u kontekst upotrebom Add komande. Ako Add komanda ne odredi u koji kontekst se dodaje terminacija, kreira se novi kontekst za datu terminaciju. Ovo predstavlja jedini način kreiranja novog konteksta. Komandom Move možemo prebacivati terminacije iz jednog konteksta u drugi (primer može biti pri realizaciji dodatnog servisa poziva na čekanju, kada jedan poziv treba prebaciti iz jednog konteksta u drugi). Terminacija se uklanja iz konteksta upotrebom Subtract komande. Ako se uklanja poslednja terminacija iz konteksta, kontekst se briše.

Više terminacija u okviru istog konteksta može da razmenjuje podatke. Međutim, to ne znači da svaka terminacija može da šalje i prima podatke od bilo koje druge terminacije u kontekstu. To zavisi od načina definisanja konteksta, pri



čemu se definiše njegova topologija koja upravo opisuje koja terminacija u kontekstu je primalac, koja pošiljalac, a koja i jedno i drugo.

Kontekst u okviru MG-a se identifikuje ContextID identifikatorom. ContextID dodeljuje sam MG lokalno. Pri referenciranju na kontekste u komandama MEGACO protokola moguće je koristiti wildcard all (*) i choose ($) karaktere.

Tipičan MG najčešće sadrži terminacije kao što je prikazano na slici (Slika 24). Ka klasičnoj telefonskoj PSTN/ISDN mreži MG poseduje određen broj semi-permanentnih terminacija, dok je ka IP mreži u stanju da kreira određeni broj kratkotrajnih terminacija (RTP/IP sesija). Dok ne pripadaju kontekstima, ove terminacije su neaktivne.

Slika 24. Terminacije MG-a

Upotrebom MEGACO komandi prenetih u okviru MEGACO transakcija ili poruka (grupa transakcija) MGC može kreirati na MG-u nove kontekste i dodeliti im neke od terminacija. Primer formiranja konteksta u okviru MG-a dat je na slici (Slika 25).

Slika 25. MEGACO konteksti i terminacije



7.5 MEGACO komande

Osnovni mehanizam kontrole MG-a od strane signalizacionog MGC-a je putem MEGACO komandi. MEGACO komande su deo MEGACO transakcija i odnose se na neki od postojećih konteksta na MG-u (ili služe da kreiraju novi kontekst). Zapravo, smisao MEGACO komandi upravo je u tome da omoguće rukovanje terminacijama i kontekstima na MG-u. Stoga je korisno upoznati se sa MEGACO komandama kako bi se stekao uvid šta je sve moguće ostvariti u kontroli MG-a. S obzirom da MEGACO komandi ima samo osam, to nije težak posao, pa se kratak pregled svih osam komandi daje u tabeli (Tabela 7.1) u nastavku.

Tabela 3. MEGACO komande

8 Zaključak

Tema ovog rada je VoIP. U radu su predstavljeni arhitektura i protokoli VoIP-a.

VoIP tehnologija kod nas još nije zaživela u tolikoj meri koliko je u svetu zastupljena i popularna. U narednih nekoliko godina, očekuje se da će se i to promeniti. Zasad, VoIP je ″ušao″ samo u pojedina preduzeća. Zapravo, preduzeća i mogu imati najveće beneficije primenom VoIP tehnologije.



VoIP tehnologija uveliko može uticati na informacionu konkurentnost jednog preduzeća. Osim što snižava troškove upotrebe klasične telefonije, na adekvatan način povećava eksploataciju postojećih Internet instalacija u firmi, koje preduzeće ne koristi u potpunosti zbog objektivnih razloga. Ovako, firma je u mogućnosti da u potpunosti koristi sve kapacitete kadrova koje ima u radnom odnosu bez obzira gde se radnici nalaze. Šta više, preduzeće može koristiti znanje ″pozajmljenih″ kadrova iz bilo kog dela planete uz niske troškove komunikacije. Uz pomoć jeftinih Web kamera, u mogućnosti je da održava sastanke sa partnerima ili klijentima, štedeći na troškovima reprezentacije (put, smeštaj i sl.). U najmanju ruku, preduzeće može organizovati komunikaciju između organizacionih jedinica u preduzeću koristeći već postojeću mrežnu instalaciju računara štedeći na kupovini skupih telefonskih instalacija i centrala. Osim navedene uštede, preduzeće smanjuje troškove amortizacije koju bi imala upotrebom navedene opreme, i ujedno, troškovi održavanja se lokalizuju na postojeće troškove održavanja informacionog i mrežnog sistema u firmi.



9 Literatura

[1] Andrew S. Tanenbaum, Computer networks, fourth edition, Prentice Hall, New Jersey, 2003

[2] Thomas Sheldon, Encyclopedia of Networking and Telecommunications, McGraw-Hill, New York City, 2001

[3] The International Engineering Consortium, Web ProForum Tutorials, Voice over Internet Protocol,

http://www.iec.org/online/tutorials/int_tele/.

[4] http://en.wikipedia.org/wiki/Voice_over_Internet_Protocol

[5] http://en.wikipedia.org/wiki/User_Datagram_Protocol

[6] http://en.wikipedia.org/wiki/Transmission_Control_Protocol

[7] http://www.fcc.gov/voip/

[8] http://www.freesoft.org/CIE/Course/Section3/3.htm

[9] http://www.srbijavoip.com

[10] http://www.javvin.com/protocolMegaco.html

[11] http://ftp.sunet.se/pub/lang/erlang/project/megaco/index.html

[12] http://www.networksorcery.com/enp/protocol/rtcp.htm

[13] http://www.virtualnigrad.com/Sta_je_VoIP_Uvod_u_VoIP-74-3513



10 Akronimi i skraćenice

ABNF Augmented Backup-Naur Form ACK Acknowledge BGP Border Gateway Protocol CNAME Canonical Name DNS Domain Name System FTP File Transfer Protocol GSM Global System for Mobile communication HTTP Hypertext Transfer Protocol ICANN Internet Corporation for Asigned Names and Numbers ICMP Internet Control Message Protocol IETF Internet Engineering Task Force IGMP Internet Group Management Protocol IHL Internet Header Length IP Internet Protocol ISDN Integrated Services Digital Network ISN Initial Sequence Number MEGACO Media Gateway Control Protocol MG Media Gateway MGC Media Gateway Controller MGCP Media Gateway Control Protocol MSS Maximum Segment Size MTU Maximum Transmission Unit NNTP Network News Transfer Protocol OSI Open System Interconnection Reference Model OSPF Open Shortest Path First PC Personal computer PDA Personal digital assistant PSTN Public Switched Data Network RFC Request for Comments ROM Read-only memory RTCP Real-time Transport Control Protocol RTP Real-time Transport Protocol RTSP Real Time Streaming Protocol SCTP Stream Control Transmission Protocol SDP Session Description Protocol SIP Session Initiation Protocol SMTP Simple Mail Transfer Protocol TCP Transmission Control Protocol TDM Time-division multiplexing TFTP Trivial File Transfer Protocol TLS Transport Layer Security TU Transaction User UA User Agents



UAC User Agent Client UAS User Agent Server UDP User Datagram Protocol VoIP Voice over Internet Protoco

Documents

Arhitektura i Protokol VoIP Mreze