Dipl merimin

Farultet za saobraćaj i komunikacije Diplomski rad

Sažetak: Telekomunikacijski operateri nove generacije trebaju nove mreže temeljene na IP tehnologiji koje omogućavaju jeftiniji prijenos govora i podataka nego mreže temeljene na komutaciji kanala. Tehnologija koja omogućava prijenos govora preko IP mreže zove se VoIP tehnologija (Voice over IP). Upotreba VoIP tehnologije osim jeftinijih telefonskih razgovora omogućava lakše i brže uvođenje dodatnih usluga. Kako uspostava i raskidanje komunikacije spada u najvažnije funkcije u telekomunikacijskoj mreži, signalizacija je, od samog početka, bila jedno od ključnih područja za razvitak VoIP tehnologija. Za uspostavu komunikacije preko IP mreže razvijeno je nekoliko signalizacijskih standarda: SIP (Session Initiation Protocol) i H.323 (H.323 Protocol). H.323 protokol je definirala ITU-T organizacija radi implementacije multimedijalnih konferencija u paketskim mrežama. SIP protokol razvila je IETF organizacija s namjerom kreiranja protokola za uspostavu, modifikaciju i raskidanje IP multimedijalnih sesija između jednog ili više sudionika.

Abstract: The next decade telecommunication operators are in a need of a new generation of networks, primarily based on IP technology which allows cheaper voice and data transfer in comparison to networks based on circuit switching. Technology that allows transfer of voice over IP network is called VoIP technology. Beside cheaper telephone calls, use of VoIP technology enables faster and easier introduction of supplementary services. Signaling was main area of development since main function in telecommunication network is related to call set-up and release. Several signaling protocols are developed for call set-up in IP network: H.323 protocol and SIP (Session Initiation Protocol). H.323 protocol was developed by ITU-T organization and it can be seen as an ‘umbrella standard’ which aggregates standards for multimedia conferencing over packet-based networks. SIP was standardized by the Internet Engineering Task Force as application layer control protocol that can establish, modify and terminate IP multimedia sessions between one or more participants.

Merima Zukić Signalizacijski protokol za uspostavu komunikacije u IP mrežama 1


SadržajSažetak – abstract

1. Uvod 4

2. Ciljevi i metodologija izrade diplomskog rada 6

2.1. ciljevi rada 6

2.2. Metodologija izrade diplomskog rada 7

3. H. 323 8

3.1 Pregled H. 323 protokola 8

3.2. Arhitektura H.323 mreže 11

4. SIP (Session Initiation Protocol) 14

4.1. Pregled SIP protokola 14

4.2. Arhitektura SIP mreže 17

4.2.1. Korisnički agenti 17

4.2.2. SIP proxy poslužitelj (server) 18

4.2.2.1. Poslužitelji bez stanja transakcije (stateless) 19

4.2.2.2. Poslužitelji sa stanjem transakcije (stateful) 20

4.2.3. Redirect poslužitelj 20

4.2.4. Registar 21

5. SIP funkcije 23

5.1. Razlučivanje adresa 23

5.2. Sesijski vezane funkcije 24

5.2.1. Uspostava sesije 24

5.2.2. Prenos SIP poruka preko IP-a 25

5.2.3. Media Negotiation 26

5.2.4. Modifikacija sesije 28

5.2.5. Prekid i otkazivanje sesije 29

5.2.6. Signalizacija u toku poziva 30

5.2.7. Kontrola poziva 31

5.2.8. Preduslovi za uspostavu poziva 33

5.2.9. Ponovno slanje poruka u SIP-u 34

5.3. Funkcije bez sesije 35



5.3.1. Pokretljivost (mobilnost) 35

5.3.2. Prenos poruke 38

5.3.3. Procesi pretplate i obavijesti 38

5.3.4. Publikacija prisutnosti 40

5.3.5. Traženje autentifikacije 40

6 Osnovni SIP poziv 44

6.1. Osnovni SIP-T poziv 45

7. Ostale karakteristike SIP protokola 47

7.1. Interoperabilnost SIP protokola sa ITU-T protokolima 47

7.2. Komercijalni SIP produkti 48

7.3. SIP sigurnost 49

7.4. Šta SIP ne radi 49

8. Zaključak 51

Popis slika 53

Popis tabela 54

Popis skraćenica 54

Literatura 56

1. Uvod



Tradicionalna telekomunikacijska mreža temelji se na komutaciji kanala. Osnovu prometa u takvoj mreži čini prijenos govora. Pojavom računara pojavila se i potreba za njihovim povezivanjem i razmjenom podataka. Komutacija paketa u takvoj okolini pokazuje se prikladnijim rješenjem. Stvaraju se podatkovne mreže i konačno, Internet. Dok je sam Internet temeljen na paketskom prijenosu, pristup Internetu, zbog velike raširenosti mreža s komutacijom kanala, u velikoj mjeri temeljio na postojećim telekomunikacijskim mrežama i korištenju modema. Povećanjem prometa raste potreba za digitalnim paketskim mrežama.

Postojanje odvojenih mreža za prijenos govora i podataka bio je dodatni poticaj razmatranju temeljnih razlika između njih. Jedna od bitnih razlika je i u načinu tarifiranja Internet veze i telefonskih razgovora. Dok u cijeni korištenja Internet veze komponenta udaljenosti nije bitna, u slučaju klasične telefonije, ona ima jako važnu ulogu. Upravo taj ekonomski aspekt je bio ključan za revoluciju koja se događa u telekomunikacijskoj industriji. Telekomunikacijski operateri nove generacije trebaju nove mreže temeljene na komutaciji paketa koje omogućavaju jeftiniji prijenos govora i podataka nego mreže temeljene na komutaciji kanala (uz zadovoljavajuću kvalitetu usluge). Sa razvojem mreža za prijenos podataka i širokom primjenom IP (Internet Protocol) protokola skrenuta je pažnja na prijenos govora Internetom i drugim paketskim mrežama. Tehnologija koja omogućava prijenos govora preko IP mreže zove se VoIP tehnologija (Voice over IP). Upotreba VoIP tehnologije omogućava jeftinije telefonske razgovore. Ona također omogućava lakše i brže uvođenje usluga.

Da bi se pružile upotrebljive usluge, IP telefonija zahtijeva skup kontrolnih ili signalizacijskih protokola za uspostavljanje konekcije, razmjenu informacija o uslugama koje se mogu koristiti između dvije ili više strana i uspostavljanje konferencija. Kako uspostava i raskidanje komunikacije spada u najvažnije funkcije u telekomunikacijskoj mreži, signalizacija je, od samog početka, bila jedno od ključnih područja za razvitak VoIP tehnologija. Za uspostavu komunikacije preko IP mreže razvijeno je nekoliko signalizacijskih standarda: SIP (Session Initiation Protocol) i H.323 (H.323 Protocol).

H.323 protokol razvila je ITU-T organizacija radi implementacije multimedijalnih konferencija u LAN (Local Area Network) mrežama. Kasnije je protokol je proširen tako da se korisnici ne moraju nalaziti u istoj LAN mreži.

SIP protokol razvila je IETF (Internet Engineering Task Force) organizacija s namjerom kreiranja protokola za uspostavu, modifikaciju i raskidanje IP multimedijalnih sesija između jednog ili više sudionika. Pojam sesije odnosi se na multimedijalne konferencije, Internet telefoniju, učenje na daljinu i slično. SIP je također razvijen radi omogućavanja napredne telefonske usluge preko Interneta. SIP protokol je privukao dosta pažnje u zadnjih nekoliko godina, što je naglašeno prihvaćanjem toga protokola kao signalizacijskoga protokola za pružanje višemedijskih usluga u 3G sistemima i posve izvjesnom migracijom telekomunikacijskih mreža prema IP višeuslužnim mrežama ili NGN.

Iako su u početku ovi protokoli imali različite namjene, noviji standardi omogućavaju slične funkcionalnosti (imaju istu namjenu). Jedna od zajedničkih namjena im je i uspostava komunikacije preko IP mreže.

SIP nije zamišljen da bude sveobuhvatan, pa će za komunikaciju među uređajima biti potrebni i drugi protokoli. Njegova je namjena 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 (Real - Time Protocol) i SDP (Session Description Protocol), o čemu ćemo detaljnije govoriti u poglavlju 4. SIP je dizajniran u skladu s Internet modelom. To je end-to-end tip signalnog protokola što znači da je logika, osim usmjeravanja SIP poruka, spremljena na krajnjim uređajima. Stanje sesije je također spremljeno na krajnjim uređajima, ne postoji jedinstvena tačka ispada. Mreže koje su dizajnirane na taj način dobro skaliraju. Cijena koju za to moramo platiti je veće zaglavlje.



End-to-end koncept SIP protokola bitno je različit od koncepta uobičajene PSTN (Public Switched Telephone Network) mreže kod koje su sva stanja i logika koji se spremaju u mrežu i krajnje uređaje (telefone) vrlo primitivni. Cilj je SIP protokola omogućiti istu funkcionalnost koju imaju klasične PSTN mreže, ali end-to-end dizajn čini SIP mreže sposobnijim za primjenu novih usluga koje se teško mogu implementirati u klasičnim PSTN mrežama.

SIP je baziran na vjerovatno najuspješnijem i najviše korištenom internetskom protokolu-HTTP-u. HTTP se može klasificirati kao signalni protokol jer ga klijenti koriste da bi poslužitelju rekli koji ih dokumenti zanimaju. SIP se koristi za prenošenje opisa parametara sesije, opis se kodira u dokument pomoću SDP protokola. Oba protokola (HTTP i SIP) naslijedila su kodiranje zaglavlja poruka iz RFC 822. Kodiranje se tokom godina pokazalo sigurnim i fleksibilnim.

2. Ciljevi i metodologija izrade diplomskog rada



2.1. Ciljevi rada

Značajna uloga komunikacijske tehnologije uveliko danas određuje način života i diktira temeljite društvene promjene. Tehnološke inovacije na dinamičnom, globlnom tržištu mijenjaju sliku svijeta u kojem živimo i radimo. Takav trend možemo pratiti u čitavom proteklom stoljeću, periodu kada su telekomunikacijski uređaji postali roda široke potrošnje, a telekomunikacijska industrija jedna od najprofitabilnijih djelatnosti.

Tradicionalni telekomunikacijski operateri širom svijeta suočeni su sa izazovom opadanja profita generiranog kroz klasične telefonske usluge. Izlaz iz takve situacije većina operatera vidi u novim podatkovnim uslugama. Ipak ako se promatra struktura prihoda telekomunikacijskih operatera, moguće je uočiti kako i dalje većinu prihoda čine usluge prijenosa glasa, a ne podataka. Iako je u konstantnom porastu, promet generiran podatkovnim uslugama nije ni približno ekvivalentan profitabilnosti glasovnih usluga. Kao što je rečeno u samom uvodu, tehnologija koja omogućava prijenos govora preko IP mreže je VoIP tehnologija (Voice over IP), čija upotreba omogućava jeftinije telefonske razgovore, a također omogućava lakše i brže uvođenje usluga. Kako uspostava i raskidanje komunikacije spada u najvažnije funkcije u telekomunikacijskoj mreži, signalizacija je, od samog početka, bila jedno od ključnih područja za razvitak VoIP tehnologija, te je ključno mjesto dato razvoju signalnih protokola za uspostavu komunikacije u IP mrežama, među kojima je najvažniji SIP protokol.

Cilj ovog rada jeste da pruži osnovne informacije o o ovom protokolu, njegove funkcionalnosti i njegov značaj.

U svrhu što uspješnijeg ostvarenja navedenog cilja, rad je podijeljen u devet poglavlja i ima slijedeću strukturu:

1. Uvod2. Ciljevi i metodologija izrade diplomskog rada3. H. 3234. SIP (Session Initiation Protocol)5. SIP funkcije6. Osnovni SIP poziv7. Ostale karakteristike SIP protokola8. Zaključak

Prva dva poglavlja , Uvod i Ciljevi i metodologija izrade diplomskog rada, daju osnovna razmatranja o tematici obrađenoj u okviru ovog rada, pord toga, deginirani su ciljevi i način, odnosno metodologija koja nam omogućava da se postavljeni ciljevi i realiziraju.

U trećem poglavljusu data uvodna razmataranja o H. 323 protokolu, koji zajedno sa SIP protokolom predstavlja signalizacijski protokol u telekomunikaciskim sistemima. Budući da se danas sve više preferira SIP, njemu će i biti više posvećena pažnja u narednim poglavljima.

U četvrtom poglavljuse daju osnovne informacije o SIP protokolu kao i arhitektura SIP mreže, te njene komponente.

U petom poglavlju definiraju se SIP funkcije, od kojih su posebno izdvojene slijedeće: razlučivanje adresa, sesijski vezane funkcije, i funkcije bez sesije.

U Šestom poglavlju objašnjen ne oosnovni SIP poziv.U sedmom poglavlju definirane su i ukratko pojašnjene ostale SIP karakteristike, od kojih

su izdvojene: Interoperabilnost SIP protokola sa ITU-T protokolima, Komercijalni SIP produkti, SIP sigurnosti i na kraju ukratko je naglašeno šta zapravo SIP ne radi.

Zaključkom se ukratko rezimira materija izložena u okviru diplomskog rada na način da se iznesu i naglase spoznaje do kojih se došlo prilikom proučavanja ove problematike.



2.2. Metodologija izrade

Metodologija je znanost o cjelokupnosti svih oblika i načina istraživanja pomoću kojih se dolazi do sistematskog i objektivnog znanja. Pored toga, metodologija se definira i kao znanstvna disciplina u kojoj se ispituju i eksplicitno izlažu različite opće i posebne znanstvene metode.

U svrhu ostvarenja definiranih ciljeva, prilikom obrade, stvaranja spoznaja i donošenja zaključaka o problematici signalizacijskih protokola za uspostavu komunikacije u IP mrežama, biće korištene različite metode, od kojih ćemo izdvojiti najvažnije:

Deskriptivna metoda Komparativna metoda Metoda analize Metoda sinteze Statistička metoda

Deskriptivnu metodu sam koristila prilikom opisivanja pojedinih dijelova SIP arhitekture, te svih funkcija SIP protokola.

Komparativnu metodu sam koristila pri poređenju SIP protokola sa ranije donešenim H.323 protokolom, koje su im sličnosti i razlike, te osnovne prednosti i nedostaci.

Metoda analize predstavljapostupak naučnog istraživanja i obješnjavanja stvarnosti putem raščlanjivanja složenih tehničkih tvorevina – pojmova, sudova i zaključaka na najjednostavnije dijelove i elemente kao i izučavanjesvakod elementa zasebno i u odnosu na druge elemente. Metoda analize je korištena prilikom izrade svakogod poglavlja, kako bi se došlo do što jednostavnijeg načina da se objasni uticaj SIP protokola u razvoju telekomunikacione tehnologije.

Metoda sinteze je postupak znanstvenog istraživanja i objašnjavanja stvarnosti putem spajanja, sastavljanja jednostavnih tehničkih konstrukcija u složenije povezujući odvojene elemente, pojave, prrocese i odnose u jedinstvenu cjelinu. Metoda sinteze je u prvom redu korištena pri evaluaciji spoznaja i izvođenju zaključaka.

3. H.323

Prije nego budemo detaljnije razmatrali problematiku SIP protokola kao ključnog signalizacijskog protokola za pružanje višemedijskih usluga u 3G sistemima, ovo poglavlje ćemo



posvetiti protokolu H.323, budući da razlikujemo dvije signalizacijske arhitekture koje se bore za primat u IP telefoniji: H.323 i SIP (Session Initiation Protocol).

H.323 protokol je razvijen od ITU-T organizaciju radi implementacije multimedijalnih konferencija u LAN mrežama. H.323 je protokol čini skup standarda koji definiraju arhitekturu sustava, te su vodič za implementaciju uspostave komunikacije, kontrole komunikacije i medije koja će se koristiti u komunikaciji. Do sada je specificirano pet verzija H.323 protokola.

Slika 1. Međuodnos protokola u H.323 mreži

3.1. Pregled H.323 protokola

H.323 standard definira prijenos audia, videa i podataka u realnom vremenu preko paketske mreže. H.323 se može primijeniti za različite namjene: samo audio (IP telefonija); audio i video (video telefonija); audio i podaci; audio, video i podaci. Također, se može primijeniti u multimedijalnim konferencijama. H.323 je protokol čini skup standarda. Njihov međusobni odnos, te odnos s drugim protokolima prikazan je na slici 1.

H.225 RAS (Registration, Admission and Status) signalizacija je potrebna kada se u mreži nalazi upravnik, te se koristi između krajnje točke i upravnika i omogućava

- registraciju krajnje točke na upravnik (slika 2). Tijekom registracije krajnja točka dobije identifikator koji se koristi u komunikaciji s upravnikom, te upravljanje krajnjom točkom od strane upravnika,

- kontrolu pristupa od i ka uređaja koji kontrolira upravnik. Kada je krajnja točka registrirana, ona može inicirati ili primiti poziv samo nakon prijema odobrenja od upravnika,



Slika 2. Signalizacijski dijagram registracije na upravnik

- omogućava razmjenu adresnih informacija (address resolution) između dva upravnika. Pri iniciranju procedure za dobijanje odobrenja za početak komunikacije, šalje se i adresa odredišta (npr. telefonski broj) upravniku. Upravnik inicira proceduru lociranja prema drugim upravnicima i dobija IP adresu odredišta (slika 3)

Slika 3. Signalizacijski dijagram dobivanja IP adrese odredišta

H.225.0 signalizacija se koristi za uspostavu i raskidanje komunikacije između dva H.323 entiteta. Ona je izvedena iz Q.931 (signalizacija za ISDN pozive) upotrebom dijela Q.931 poruka, te modificirana za upotrebu u paketskim mrežama.

H.245 signalizacija se koristi u čitavom nizu H.32x protokola, a dio primjenjiv u H.323 mrežama opisan je u aneksu A ovog protokola. Svrha samog protokola je uspostava, promjena i raskid medijskih tokova između krajnjih točaka u H.323 pozivu. Za tu namjenu, protokolom su definirane procedure za oglašavanje podržanih oblika razmjene medijskih tokova, otvaranja i zatvaranja medijskih tokova, zahtjeve za određenim načinom razmjene medijskog toka, poruke za upravljanjem medijskim tokom, opće naredbe i indikacije. U H.245 preporuci se za medijske tokove koristi naziv logički kanali. H.245 kanal, kanal kojim se prenosi H.245 signalizacija, se naziva nulti logički kanal, dok su pojedini medijski tokovi, kojima se razmjenjuju govorne, video i podatkovne informacije, logički kanali pobrojani od 1 pa naviše.

Snaga H.323 protokola leži u:- centralizirana i distribuirana kontrola, s H.323 sve ili dio funkcija kontrole poziva se mogu

pomaći na krajnje točke mreže (ovisno o potrebi), a operatorima se omogućava kontrola svakog aspekta poziva.



- integracija s Internet standardima, H.323 je integriran s postojećim Internet tehnologijama kao što su: RTP/RTCP, URL i DNS. H.323 dozvoljava korisniku pozivanje drugog korisnika klikom na URL adresu,

- fokus, H.323 je razvijen s ciljem omogućavanja audio, video i podatkovnih konferencija preko paketskih mreža. Daljnji razvoj H.323 standarda je ostao fokusiran ka tom cilju.

Neke od usluga koje omogućuje H.323 protokol su:- upravljanje pojasnom širinom, primjerice može se ograničiti broj istovremenih poziva ili

oduzeti dio pojasne širine nekom korisniku i sl.,- konferencije bez opreme specijalizirane za tu svrhu, H.323 podržava konferencije s tri ili

više učesnika sa i bez korištenja MCU jedinice,- multicast prijenos, što znači da korisnik može poslati jedan paket na više odredišta bez

ponavljanja slanja,- upotreba različitog hardvera i softvera, za komunikaciju, korisnici ne moraju imati istu

(sličnu) opremu,- tradicionalne usluge PSTN mreže.

U okvirima H.323 standarda je omogućeno adresiranje H.323 terminala korištenjem više adresa istog i/ili različitog tipa. H.323 standard podržava različite tipove adresa:

- dialedDigits (u starijim verzijama E.164).

- h323-ID,

- url-ID,

- transportID,

- email-ID,

- partyNumber,

- mobileUIM.

Ovaj pristup zahtijeva posebnu pretvorbu i razlučivost adresa, kao i posebne registracijske procedure za koje su u H.323 mreži zaduženi H.323 upravnici. Adresiranje korištenjem adresa dialedDigits ili partyNumber tipa je najzastupljenije jer korisnici povijesno koriste telefonske brojeve za identifikaciju. H323-ID tip je slovno-brojčani tip adrese i predstavlja korisnička imena ili e-mail adrese. MobileUIM tip adrese je prilagođen identifikaciji mobilnih korisnika i omogućava međudjelovanje s javnim mobilnim mrežama druge i treće generacije. Moguće je, u svrhu adresiranja, koristiti i transportnu adresu krajnje točke u obliku transport-ID adrese. Popularnost url-ID adresa kao najopćenitijeg tipa adresa (koji uključuje H.323 URL i “tel” URL) i email-ID adresa se, sa širenjem VoIP tehnologije, sve više povećava. Kada se u H.323 mrežama koristi adresiranje pomoću telefonskih brojeva, često se koriste i tzv. prefiks zone i tehnološki prefiks. Prefiks zone je predbroj jedinstven u okviru administrativne domene i unutar nje jednoznačno određuje zonu. Ovaj prefiks je bitan za usmjeravanje poziva među zonama unutar administrativne domene. Stoga se za pozivanje H.323 korisnika u drugoj zoni, njegovom telefonskom broju treba pridodati i prefiks zone. Primjerice, upravnik H.323 zone Zagreb može biti konfiguriran tako da zna kako prefiks 021 pripada zoni Split, odnosno pripadajućem upravniku. U slučaju da neki od terminala iz zone Zagreb poziva terminal u zoni Split, to će učiniti tako da utipka 021, a zatim telefonski broj željenog korisnika. U okviru H.225.0 – RAS procedure upravljanja pristupom, pozivajuća krajnja točka će unešeni broj prenijeti upravniku zone Zagreb, koji će prema upravniku zone Split pokrenuti proceduru lociranja krajnje točke.



3.2. Arhitektura H.323 mreže

H.323 standard specificira tri tipa komponenata koje se čine H.323 mrežu:- pristupnik (gateway) – povezuje H.323 mrežu s ne-H.323 mrežom (primjerice s PSTN

mrežom, slika 4). Pristupnik odražava karakteristike H.323 mreže prema H.323 terminalu i karakteristike mreže s komutacijom kanala prema SCN terminalu. Povezivanje se postiže translacijom protokola za uspostavu i raskidanje veze, prebacivanjem jednog medijskog formata u drugi i prijenosom informacije između dvije mreže. Ako je veza potpuno unutar H.323 mreže pristupnik nije potreban. Na H.323 strani pristupnik radi s H.245 upravljačkom signalizacijom (signalizacija za razmjenu podržanih sposobnosti), H.225 signalizacijom (signalizacija za uspostavu i raskid veze), te s H.225 RAS signalizacijom (signalizacija za registraciju na upravnik).

Slika 4. Funkcijski prikaz H.323/PSTN gateway-a

- upravnik (gatekeepers) – iako je opcionalna komponenta, to je mozak H.323 mreže, središnja točka za sve pozive u H.323 mreži koja definira i kontrolira upravljanje glasovnom i video komunikacijom preko IP mreže. Upravnik je odgovoran za translaciju adresa (između LAN alijasa i IP adrese), kontrolu i usmjeravanje poziva, upravljanje sustavom i politikom sigurnosti (autorizacija i autentifikacija terminala i pristupnika). Sve usluge u komunikaciji između upravnika i krajnje točke H.323 mreže definirane su H.225 RASom. Upravnik osigurava inteligenciju za isporuku novih IP usluga i aplikacija. On dozvoljava mrežnim administratorima konfiguraciju, nadgledanje i upravljanje aktivnostima, te registracijom krajnjih točaka (terminali, upravnika ili MCU). Također upravlja pridjeljivanjem pojasne širine i tarifiranjem. Samo upravnik može upravljati H.323 zonama (zona uključuje jedan upravnik i sve komponente spojene na njega kao što je prikazano na slici 5),



Slika 5. Prikaz H.323 zone

Jedinica za upravljanje višestranim konferencijama (multipoint control units, MCU) je element koji omogućava konferencije s tri i više učesnika. Osnovne funkcije ovog elementa je održavanje svih audio, video, podataka i upravljačkih tokova između svih učesnika u konferenciji. Glavne komponente H.323 MCU elementa su multipoint controler, MC , i multipoint procesor, MP. MC je logički element koji povezuje kanale za signalizaciju i nadzor konferencije triju ili više terminala i pristupnika u topologiju zvijezde. MC koordinira razmjenu mogućih načina komunikacije između svih terminala povezanih u konferenciju te na taj način upravlja odabirom vrste konferencije i načina komunikacije. Odabir vrste konferencije može biti ograničen mogućnostima uključenih terminala i samog MC elementa. MC može za različite terminale odabrati različite načine komunikacije. Osim kao dio MCU jedinice, MC može biti implementiran unutar H.323 terminala, pristupnika ili upravnika. U tom slučaju, za višestranu konferenciju nije potreban MCU. Nekoliko MC elemenata može biti povezano u nizu kako bi omogućili širenje uspostavljene konferencije. Funkcije MP komponente su: konverzija između različitih kodeka i različitih brzina prenosa, miksanje audia, isporuka podataka i miksanje videa. Obje komponente MC i MP mogu funkcijski biti u jednoj jedinici ili kao dio drugih H.323 komponenti.Primjer mreže temeljene na H.323 protokolu prikazan je na slici 6.

U H.323 standardu postoje tri različite vrste konferencijskih poziva, između tri i više različitih terminala i pristupnika (slika 7):

Centralizirana višestrana konferencija (Centralized Multipoint Conference), svi sudionici konferencije izmjenjuju, u dvostranoj komunikaciji, signalizacijske poruke sa MC elementom koji je dio MCU jedinice, dok MP elementu, koji je također dio MCU jedinice, šalju medijske tokove koje on prima, obrađuje i šalje natrag prema terminalima, sudionicima konferencije.

Decentralizirana višestrana konferencija (Decentralized Multipoint Conference), svi sudionici konferencije izmjenjuju, u dvostranoj komunikaciji, signalizacijske poruke sa MC elementom koji je dio MCU jedinice, pristupnika, upravnika ili terminala i koji upravlja konferencijom. Terminali izravno izmjenjuju govor i/ili video tokove koristeći multicast način slanja, dok, eventualne, podatkovne tokove šalju MP elementu koji ih distribuira.



Mješovita višestrana konferencija (Hybrid Multipoint Conference), kao što samo ime kaže, predstavlja kombinaciju centralizirane i decentralizirane konferencije. Dakle, za barem jedan medijski tok se koristi centralizirana a za video ili govorni tok decentralizirana konferencija.


Slika 6. Arhitektura H.323 mreže

Slika 7. Dijagram povezivanja u centraliziranoj i decentraliziranoj višestranoj konferenciji

4. SIP (Session Initiation Protocol)

Protokol za pokretanje sesija (SIP- Session Initiation Protocol) je signalizacijski protokol koji se koristi za uspostavu, modifikaciju i raskidanje višemedijskih sesija u mrežama utemeljenim na Internet protokolu između dva ili više sagovornika.SIP protokol je protokol aplikativnog nivoa i opisan je standardom RFC 3261 ustanovljenim od strane IETF (organizacije za standardizaciju Interneta) na osnovu dva protokola: HTTP (Hyper Text Transport Protocol) i SMTP (Simple Mail Transfer Protocol). Prihvatila su ga i ostala značajna međunarodna standardizacijska tijela kao glavni protokol u višemedijskim domenama 3G mobilnih sistema (višemedijski podsistem zasnovan na IP protokolu, IMS- IP Multimedia Subsystem), te kao okosnicu mreža slijedeće generacije NGN. S migracijom tradicionalnih telekomunikacijskih mreža prema all IP višeuslužnim i višemedijskim mrežama, protokol SIP dobiva nezaobilaznu važnost. Sve interesne grupe su se usaglasile da je protokol SIP glavno sredstvo realizacije višemedijskih komunikacijskih usluga slijedeće generacije.SIP je protokol koji omogućava:

Lociranje korisnika – mogu se naći na različitim mjestima u različito vrijeme Raspoloživost korisnika – određuje da li krajnji korisnik želi ili ne želi da učestvuje u toj

sesiji Karakteristike sagovornika – određuje medijum i parametre medija koji su bitni za

komunikaciju Uspostava sesije – razmjena parametara za uspostavu sesije Upravljanje sesijama – razmjena podataka vezanih za uspostavu, raskid i održavanje

sesije.Sesije označavaju skupinu pošiljatelja i primatelja koji komuniciraju te stanje pošiljatelja i

primatelja za vrijeme komuniciranja. Primjeri sesije su telefonski razgovori putem Interneta, distribucija multimedije, multimedijske konferencije, distribuirane računalne igre itd.SIP podržava i mapiranje imena i prosljeđivanje usluga, što omogućava mobilnost korisnika tako što se korisnička identifikacija ne mijenja u odnosu na lokaciju mreže.

Zajedno sa drugim IETF protokolima čini sastavni dio arhitekture koji u potpunosti omogućava multimediju.

4.1. Pregled SIP protokola

SIP je protokol s kraja na kraj koji se koristi za kreiranje, modificiranje i završavanje sesije s jednim ili više sudionika u IP mreži. Jedna od glavnih prednosti SIP protokola je mogućnost interakcije s drugim protokolima, te udruživanjem njihovih osobina dobijaju se napredne usluge. Ključ brzog prihvaćanja SIP protokola je tekstualno kodiranje.

SIP je tekst-kodiran protokol baziran na elementima HyperText Transport Protocol (HTTP), koji se koristi za pregledanje web stranica, i takođe Simple Mail Transport Protocol (SMTP), koji se koristi za e-mail na Internetu. SIP je razvijen od strane IETF radne grupe za Multiparty Multimedia Session Control (MMUSIC) WG kao dio Internet Multimedia Conferencing Architecture, ali ima razvijenu vlastitu radnu grupu SIP WG u sklopu IETF. Kao što ime kaže primarna funkcija SIP-a je pokretanje sesije (uspostava), ali takođe ima i druge bitne upotrebe i funkcije, kao što je obavještavanje o prisustvu i kratke poruke. SIP se koristi za peer-to-peer komunikaciju—tj., onu vrstu komunikacije u kojoj su obje strane u pozivu ravnopravne, nema gospodara ni roba. SIP koristi model prenosa klijent-server slično kao HTTP, kao što će biti opisano u sljedećem dijelu. SIP klijent generiše SIP zahtjev. SIP server odgovara na zahtjev generišući odgovor.Rastući set SIP tipova zahtjeva (poznati kao metodi) je prikazan u tabeli 1. Prvih šest je definisano u RFC 3261, osnovna SIP specifikacija. Ostali su proširenja SIP-a i definisani su u različitim RFC-ovima ili Internet prijedlozima. Nove metode se stalno predlažu kao dodatne funkcionalnosti u protokolu.

Tabela.1 SIP MetodeMetod OpisINVITE Uspostava sesijeACK Potvrda krajnjeg odgovora na INVITEBYE Prekid sesijeCANCEL Otkazivanje sesije na čekanjuREGISTER Registracija korisničkih URIOPTIONS Upiti o opcijama i mogućnostimaINFO Signalizacija prenosa među-pozivaPRACK Potvrda privremenog odgovoraUPDATE Obnova informacija o sesijiREFER Prenos korisnika do URISUBSCRIBE Zahtjev za obavijest o događajuNOTIFY Prenos obavijesti o pretplatničkom događajuMESSAGE Prenos brzih porukaPUBLISH Dizanje na server stanja o prisutnosti

Odgovori u SIP-u su u obliku brojeva. Mnogi kodovi za odgovore su posuđeni iz HTTP kao i kreirani novi. SIP kodovi za odgovore su podijeljeni u šest klasa, koji se identificiraju prema prvoj cifri koda kao što je prikazano u tabeli:.2.

Tabela 2 Klase kodova SIP odgovoraKlasa Opis1xx Privremeni ili informacijski – zahtjev raste, ali još nije kopmpletan2xx Uspjeh – Zahtjev je uspješno kompletiran

3xx Preusmjeravanje – Zahtjev bi trebalo pokušati na drugoj lokaciji4xx Klijent greška – Zahtjev nije završen zbog greške, može se pokušati nakon

ispravke5xx Server greška – Zahtjev nije završen zbog greške u prijemniku, može se pokušati

na drugoj lokaciji6xx Globalni neuspjeh – Zahtjev nije uspio i ne bi trebao biti ponovljen

Kodovi odgovora su dobar prikaz sličnosti SIP i HTTP. Odgovor 404NotFound je zamišljen kao pogrešan kod web pretraživača.SIP zahtjevi i odgovori su pravljeni ili kao metod zahtjeva, ili kao kod odgovora, pa je lista polja (tzv. zaglavlja), koja su slična zaglavljima u e-mail poruci. Zapravo neka (kao što je To, From, Subject, i Date) imaju identična značenja.Npr. poruke SIP zahtjeva prikazane u tabeli.3, zajedno sa minimalno zahtijevanim setom zaglavlja i opisom pojedinih linija.Table 3 SIP primjer sa detaljnim opisomLinija OpisINVITE sip:[email protected] SIP/2.0 Prva linija SIP zahtjeva ne sadrži zaglavlja,

ali počinje sa nazivom metode (INVITE), slijedi prazno polje, zahtjev URI, (u ovom slučaju: sip:[email protected], što je destinacijska adresa zahtjeva), prazno mjesto, trenutna verzija SIP (2.0). svaka linija završava sa CRLF (Carriage Return and Line Feed). Napomenimo da su obje SIP implementacije, i RFC 2543 i RFC 3261 verzije 2.0.

Via: SIP/2.0/UDP 4.3.2.1:5060; branch=z9hG4bK765d

Via zaglavlje sadrži verziju SIP-a (2.0) i tranportni protokol (UDP) kojeg slijedi IP adresa (4.3.2.1) ili ime hosta koji je poslao zahtjev i broj porta (5060, well-known – dobro znani SIP portovi). Bilo koji server koji prosljeđuje zahtjev dodaje poruci VIA zaglavlje sa vlastitom adresom i broj porta na kojem želi primiti odgovor. BRANCH parametar je identifikator prenosa, napravljen da bude jedinstven po prvih sedam karaktera koji ga čine „kolačićem“ z9hG4bK

To: User B <sip:[email protected]> Zaglavlje TO sadrži prikazano ime (user B) kojeg slijedi URI onog koji je poslao zahtjev zatvoren u zagrade <> (sip:[email protected])

From: User A <sip:[email protected]>;tag=34kd92kfs

Zaglavlje FROM sadrži prikazano ime (user A) kojeg slijedi URI onog koji je prima zahtjev zatvoren u zagrade <> (sip:[email protected]). Parametar TAG je pseudo slučajni string generisan jedinstveno za svaki dijalog

Call-ID: 4r59899D8g10c3413 Zaglavlje CALL-ID sadrži jedinstveni identifikator za ovaj poziv (sesiju). Obično je napravljen od lokalnog pseudoslučajnog

sip:[email protected]



stringa. Svaki zahtjev u toku poziva će imati isti CALL-ID

Max-Forwards: 70 Polje zaglavlja MAX-FORWARDS je mjerač hopova koji se smanjuje za jedan kod svakog proxy servera koji proslijedi zahtjev. Kada brojač dođe do 0, vraća se odgovor 483 TOO MANY HOPS

CSeq: 1 INVITE CSEQ je broj komandne sekvence koji sadrži cijeli broj (1), prazno mjesto, zatim metod zahtjeva (INVITE). Svaki sljedeći zahtjev (komanda) u toku poziva će imati veći CSEQ broj. Pozivajuća i pozivana strana svaka za sebe održavaju odvojene CSEQ brojače.

Contact: sip:[email protected] CONTACT sadrži jedan ili više SIP URI koji daju informaciju o drugoj strani u sesiji za vezu sa korisnikom A

Content-Length: 126 CONTENT-LENGTH je oktet (bajt) brojač tijela poruke (126) koji prati listu SIP zaglavlja i odvojen je od zaglavlja jednim CLRF. CONTENT-LENGTH 0 ukazuje na to da nema tijela poruke

4.2. Arhitektura SIP mreže

Iako je kod najjednostavnije implementacije moguće koristiti samo dva korisnička klijenta koji izravno 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 poslužitelji (Slika 8.). Ukratko ćemo ih opisati u ovom odlomku.

SIP elementi su samo logičke jedinice. Često ih je korisno spojiti, na primjer, kako bi se povećala brzina procesuiranja, ali to ovisi o pojedinačnoj implementaciji i konfiguraciji.

Slika 8. Osnovni elementi SIP arhitekture

SIP mreža ima klijent/server arhitekturu koja je prikazana na slici 9.

Slika 9. Arhitektura SIP mreže

Glavne komponente SIP mreže su: SIP korisnički agenti (UA, User Agent) i SIP serveri.

4.2.1. Korisnički agenti (UA -User Agents)

Krajnje tačke koje koriste SIP za međusobno lociranje i pregovaranje o karakteristikama sesije nazivaju se korisnički agenti (user agents). Obično se, ali ne i nužno, nalaze na korisničkom računalu u obliku aplikacije. To je trenutno najrašireniji oblik, međutim, korisnički agenti mogu biti i mobilni telefoni, PSTN gateway-i, PDA uređaji, automatizirani IVR sustavi itd. Korisničke agente često nazivamo poslužitelj 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, ovisno o situaciji, ima ulogu UAC-a ili UAS-a. UAC je dio korisničkog agenta koji ima zadatak slanja zahtjeva (request) i primanja odgovora (response). UAS je također dio korisničkog agenta, ali on ima zadatak primanja zahtjeva i slanja odgovora (slika 10.).

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 primjer, korisnički agent pozivatelja ponaša se kao UAC kada šalje INVITE zahtjeve i prima odgovore na zahtjev. Kao UAS ponaša se kad primi INVITE zahtjev i pošalje odgovore.

No ta se situacija mijenja kad pozivani odluči poslati BYE i prekinuti sesiju. U tom se slučaju korisnički agent pozivanog (koji šalje BYE) ponaša kao UAC a korisnički agent pozivatelja kao UAS.

Slika 10. Direktna komunikacija bez proxy poslužitelja

Unutar jedne sesije UA može biti i UAC (inicira komunikaciju) i UAS (prima zahtjev za prekid komunikacije). Korisnički agenti mogu komunicirati izravno jedan s drugim ili preko SIP servera. Jedna od UA funkcija je spremanje i upravljanje stanjima veze.

RFC 3261 prema funkcijama koje obavljaju definira tri tipa SIP servera: SIP Proxy server, SIP server za usmjeravanje ka drugom odredištu i SIP server za registraciju.

4.2.2. SIP Proxy server

SIP omogućava izgradnju infrastrukture s mrežnim računalima koja se zovu proxy poslužitelji (proxy server). Korisnički agenti mogu slati poruke (messages) proxy poslužitelju. Proxy poslužitelji su vrlo važni entiteti u SIP infrastrukturi, usmjeravaju poruke za uspostavu sesije s obzirom na trenutnu lokaciju pozivanog, obavljaju autentikaciju korisnika, accounting i ostale važne funkcije. SIP Proxy server se ponaša i kao server i kao klijent. Standardi definiraju SIP proxy kao element koji usmjerava SIP zahtjeve prema UA serveru, te SIP odgovore prema UA klijentu. Proxy server obično transparentno prenosi poruke, ali mu dopuštena i ograničena promjena poruka (zahtjeva i odgovora). Najvažniji zadatak proxy poslužitelja je usmjeravanje poruka za uspostavu sesije prema pozivanom. Zahtjev za uspostavom sesije obično prelazi nekoliko proxy poslužitelja dok ne prona.e onoga koji zna stvarnu lokaciju pozivanog. Taj će proxy izravno proslijediti zahtjev za sesijom prema pozivanom koji će prihvatiti ili odbiti zahtjev (Slika 11.).

Slika 11. Komunikacija sa proxy poslužiteljem

Postoje dvije osnovne vrste SIP proxy poslužitelja - bez stanja transakcije (stateless) i sa stanjem transakcije (stateful).

4.2.2.1. Poslužitelji bez stanja transakcije (stateless)

Poslužitelji bez stanja transakcije su obični prosljeditelji poruka. Oni prosljeđuju poruke neovisno o ostalim porukama vezanim uz istu transakciju. Iako su poruke obično složene u transakcije, proxy bez stanja transakcije o njima ne brine. Poslužitelji bez stanja transakcije su jednostavniji i brži od proxy poslužitelja sa stanjem transakcije. Mogu se koristiti za jednostavno balansiranje prometa, translaciju i usmjeravanje poruka. Jedan od nedostataka proxy poslužitelja bez stanja transakcije je nemogućnost apsorbiranja retransmisija poruka i izvođenja naprednijeg usmjeravanja, na primjer, forking (SIP proxy poslužitelj može poslati jednu SIP poruku na više destinacija) ili recursive usmjeravanja (kada proxy primi negativan odgovor za zahtjev koji je proslijedio, pa ponovo šalje zahtjev prema nekoj drugoj destinaciji (npr. voicemail)). Nakon prosljeđivanja poruke, stateless Proxy nema nikakvih informacija vezanih za ovu poruku, čak zaboravlja da ju je ikad obrađivao. Prosljeđivanje zahtjeva bez pamćenja stanja transakcije omogućava povećavanje skalabilnosti i performansi, ali se gubi informacija o uspješnosti poziva (nemoguće je povezati odgovori i zahtjevi), ponovljeni zahtjevi se obrađuju isto kao i prvi put poslane poruke. Najviše upotrebljava u jezgri mreže zbog velikog prospojnog kapaciteta.

4.2.2.2. Poslužitelji sa stanjem transakcije (stateful)

Proxy poslužitelji sa stanjem transakcije su složeniji. Kod primitka zahtjeva, oni stvaraju stanje i održavaju ga dok transakcija ne završi. Neke transakcije, naročito one koje nastaju INVITE metodom, mogu trajati dosta dugo, sve dok pozivani ne odgovori ili odbije poziv. Budući da moraju održavati stanje za vrijeme trajanja transakcija, njihove su performanse limitirane. Sposobnost povezivanja SIP poruka u transakcije omogućuje proxy poslužiteljima sa stanjem obavljanje naprednih funkcija. Oni mogu obavljati forking, što znači da se prilikom primitka poruke dalje šalju dvije ili više poruka.Tako.er mogu apsorbirati retransmisije budući da znaju, preko stanja transakcije, jesu li već primili istu poruku. Proxy poslužitelji sa stanjem transakcije mogu obavljati zahtjevnije metode pronalaženja korisnika.

Mogu, na primjer, pokušati doći do uredskog telefona korisnika, pa ako on ne prihvati poziv preusmjeriti ga na mobitel. Proxy bez stanja transakcije to nije u stanju obaviti, jer ne zna kako je završila transakcija s uredskim telefonom. Još jedna od prednosti proxy poslužitelja sa stanjem transakcije je mogućnost accountinga. kada se pamte stanja transakcija (statefull Proxy) – Proxy obrađuje transakcije. Postoje dva tipa transakcija: server transakcije (primanje zahtjeva i slanje odgovora) i klijent transakcije (slanje zahtjeva i primanje odgovora). Na slici 12 je prikazan model Proxy-ja koji pamti stanja transakcija. Jezgra je odgovorna za vezu između klijent i server transakcija i upravljanje stanjima zahtjeva. Također skuplja odgovore od različitih klijent transakcija i odabire odgovore koji će biti proslijeđeni dalje pomoću server transakcije. Statefull Proxy je svjestan stanja transakcija i povijesti poruka, te zbog toga može obaviti bolje procesiranje dolaznih poruka (može identificirati ponovno poslane poruke, inicirati ponovno slanje izgubljenih poruka, otkazati poslani zahtjev). Nedostatak im je veća upotreba memorije čime se ograničava maksimalni broj transakcija, više vremena za obradu transakcija čime se ograničava broj obrađeni transakcija u sekundi i teža implementacija (mnogo logike).

Slika 12. Blok dijagram proxy servera koji pamti stanja transakcija

4.2.3. Redirect poslužitelj

Entitet koji prima zahtjev i šalje odgovor s lokacijom određenog korisnika zove se redirect poslužitelj. Redirect poslužitelj prima zahtjev, te pretražuje lokacijsku bazu podataka koju kreira registrar, kako bi pronašao primatelja kojem je zahtjev namijenjen. Zatim kreira popis trenutnih lokacija korisnika i šalje ih pošiljatelju zahtjeva kao odgovor unutar 3xx grupe. Pošiljatelj zahtjeva zatim povlači popis destinacija i direktno njima šalje novi zahtjev (Slika 13).

Slika 13. Tok poziva sa redirect poslužiteljem

Za razliku od Proxy servera, server za usmjeravanje ka drugom odredištu ne propušta zahtjeve ka drugom serveru/UA, već ih prima, te šalje odgovore klijentima s adresama zahtijevanih servera. Ova osobina omogućava operatoru široki spektar mogućih usluga za krajnjeg korisnika (npr. aplikacija pozivnog centra).

4.2.4. Registrar

Registrar je poseban SIP entitet koji prima registracije od korisnika, povlači informacije o njihovoj trenutnoj lokaciji (IP adresa, port i korisničko ime) te sprema informacije u lokacijsku bazu podataka (slika14.). Namjena je lokacijske baze podataka mapirati sip:

[email protected]. u nešto poput sip:[email protected]:5060. Kad proxy zaprimi poziv za sip: [email protected]. pretražuje lokacijsku bazu podataka.

Pronalazi sip:[email protected]:5060 i poziv za uspostavu sesije šalje tamo. Svaka registracija ima ograničeno vremensko trajanje. Expires polje u zaglavlju ili parametar prestanka valjanosti Contact polja u zaglavlju odre.uju trajanje valjanosti registracije. Korisnik mora obnoviti registraciju unutar određenog roka ili će ona isteći a korisnik postati nedostupan. Registracija se vrši REGISTER metodom koja sadrži AoR (Address of Record) sip: [email protected]. i kontakt adresu sip:[email protected]:5060, gdje je 192.168.1.2 IP adresa telefona. Te se informacije šalju registraru, a on ih šalje u lokacijsku bazu podataka(Slika 15.).

Slika 14. REGISTER zahtjev

Slika 15. Komunikacija sa lokacijskom bazom podataka

mailto:[email protected]



5. SIP funkcije

SIP protokol će biti predstavljen u smislu nekih osnovnih funkcija komunikacijskih mreža: razlučivanje adresa, sesijski vezane funkcije (uključujući uspostavu sesije, medija pregovore, promjenu sesije, prekid sesije, i otkazivanje), signalizacija međupoziva, kontrola poziva, QoS uspostave poziva, i nesesijski vezane funkcije (kao što je pokretljivost, prenos poruka, fenomen pretplatnika i obavijesti, autentifikacija, i proširljivost). Svaka od ovih stavki će biti objašnjena u nastavku.

5.1 Razlučivanje adresa

Razlučivanje adresa je jedna od najbitnijih funkcija SIP protokola. Proces razlučivanja SIP adresa obično počinje sa URI, a završava sa korisničkim imenom na IP adresi. Ovo razlučivanje od generalnog imena do stvarnog korisnika na hostu je moćno u različitim tipovima mobilnosti i prenosivosti se automatski implementira. Razlučivanje adrese može biti izvedeno od oba korisnička agenta i servera.Proces razlučivanja adresa može uključivati sljedeće korake:

DNS NAPTR pretraživanje da bi se odredio transportni protokol (UDP, TCP, SCTP) kao što je opisano u RFC 3263

DNS SRV pretraživanje da bi se odredilo ime hosta na serveru kao i broj porta kao što je opisano u RFC 3263

DNS A pretraživanje da bi se odredila IP adresa hosta ENUM pretraživanje ako je u pitanju telefonski broj Kada se rutira na server u domeni korisnika, pretraživanje servisa lokacije, kao što je

opisano u RFC 3261

Iako je moguće da SIP korisnički agent ima pristup servisu lokacije, ovo pretraživanje je obično izvedeno od strane proxy-ja ili redirekcionog servera na račun korisničkog agenta.Generalno, proces razlučivanja adresa uključuje više koraka i više hopova za SIP poruke. Ovo dozvoljava korisničkim agentima i proxy-jima da obave rutiranje zahtjeva na bazi hop-po-hop metode. Svaki proxy konsultuje DNS ili ruting tabelu, a onda prosljeđuje zahtjev sljedećem hopu. Ovaj proces se nastavlja sve dok zahtjev ne bude dostavljen na odredište. Napomenimo da rutiranje odgovora u SIP-u ne uključuje razlučivanje adresa; svi odgovori se rutiraju nazad preko istih proxy-ja kao i zahtjev. Ovo je omogućeno zbog lanca VIA zaglavlja u poruci zahtjeva.

Na slici 16 razmatramo primjer rutiranja zahtjeva. Ovaj primjer ne pokazuje odlazne i dolazne proxy servere, nego samo jedan proxy server u sredini. Ovako jednostavna konfiguracija mreže se može primijeniti na rutiranje poziva u malim privatnim IP mrežama. SIP korisnički agent A želi poslati generalni SIP zahtjev drugom korisničkom agentu B identificiranom sa SIP URI sip:[email protected]. SIP telefon A prvo provodi DNS Naming Authority Pointer (NAPTR) a onda Service Record (SRV) upit da bi razlučio transportni protokol i da locira proxy server za domen there.com (a to je TCP i sipproxy.there.com koristeći port 5060 u koracima 1 i 2). SIP zahtjev 3 se onda šalje na IP adresu sipproxy.there.com. Onda ovaj proxy konsultuje servis lokacije u koraku 5, čime se locira trenutna registracija URI za korisnika B, a to je tel:+65123456789. Onda proxy šalje set ENUM upita u koraku 7 prema DNS da bi pronašao odgovarajuću URI adresu, koja je vraćena i korištena kao sip:[email protected] u koraku 9. Zahtjev se onda rutira korisniku B na datoj IP adresi, koji uzvraća proxy serveru SIP


odgovorom o uspjehu 200OK u koraku 10. Proxy server prosljeđuje odgovor o uspjehu 200OK u koraku 11 nazad do pozivaoca A.Proces razlučivanja adrese u SIP-u je dinamičan—proxy može koristiti bilo koje zaglavlje prisutno u zahtjevu i mnoge druge faktore pri ruting odlukama, uključujući i sljedeće:

Vrijeme dana Zaglavlje From Različita polja zaglavlja u zahtjevu za učitavanje dijeljenih ili Automatic Call Distributor

(ACD) aplikacija.

Obično, ovaj proces razlučivanja adrese provodi se samo jednom na početku sesije. Rezultat inicijalnog razlučivanja adrese se sprema i koristi u kasnijim zahtjevima između korisničkih agenata.

Slika 16 Primjer razlučivanja adrese korištenjem servisa lokacije i DNS

5.2. Sesijski vezane funkcije

Većina SIP funkcija uključuje uspostavu sesije ili se može pojaviti u toku uspostavljene sesije. Iako neke aplikacije SIP-a ne koriste sesijski vezane funkcije, većina korisnih aplikacija SIP-a ima koristi od ovih moćnih funkcija.

5.2.1. Uspostava sesije

Kao što samo ime protokola kaže, uspostava sesije je primarna funkcija SIP-a. Budući da je „uljudan“ protokol, SIP koristi INVITE zahtjev za uspostavu sesije između dva korisnička agenta. INVITE poruka obično sadrži oblik poruke koji opisuje tip sesije koju korisnički agent želi da uspostavi. SIP korisnik započinje To, From sa tag parametrom, i Call-ID zaglavlja na počeku sesije. Svaki korisnički agent koji generiše odgovor dodaje tagove polje To u zaglavlju. Kombinacija tagova

To, From i Call-ID se onda koriste da jednoznačno identificiraju ovu sesiju, nazvanu “dialog” u SIP-u. Ova zaglavlja se nikad ne mijenjaju u toku sesije. Ove informacije, plus bilo koje zahtijevane informacije o mediju, predstavljaju minimalnu količinu “call state” informacija koje korisnik mora imati. U slučaju „pada“ korisničkog agenta ili ponovnog pokretanja, polazne informacije moraju biti nekako vraćene da bi se poziv nastavio; inače, poziv će morati biti ponovo uspostavljen od početka. Ovdje treba napomenuti da u skladu sa arhitekturom Interneta, održavanje poziva može biti održavano od strane krajnjih tačaka SIP-a bez bilo kakvog održavanja poziva na serverima u mreži, ako se tako zahtijeva. SIP proxy serveri mogu održavati prenosnu vezu u toku faze uspostave poziva. Održavanje stanja u krajnjim tačkama SIP-a čini uspostavu poziva nezavisnom od prenosnih grešaka u mreži, jer krajnje tačke mogu koristiti ovakvko stanje za ponovno slanje poruka za uspostavu poziva.Uspostava SIP sesije obavlja se po principu „three-way handshake“ INVITE/200/ACK za uspješnu uspostavu i INVITE/4xx ili 5xx ili 6xx/ACK za pogrešku pri uspostavi poziva. INVITE je jedini način u SIP-u u kojem u principu „three-way handshake“ ima uključen ACK. Svi ostali SIP zahtjevi su u formi REQUEST/200 ili REQUEST/4xx ili 5xx ili 6xx za pogrešku. Slika 3 pokazuje uspješnu uspostavu sesije između dva SIP telefona uključujući INVITE, dva privremena odgovora (100Trying i 180Ringing), i krajnji odgovor (2000K), koji prima ACK. Nula ili više privremenih odgovora (1xx) mogu biti prethodno poslani na krajnje odredište.Jednom uspostavljena sesija nastavlja se neprekidno bez dodatnih zahtjeva za razmjenom SIP signalnih poruka. SIP brojač sesije može biti korišten da prekine sesiju koja se čini predugom. Ako jedna strana u sesiji želi da promijeni ili obustavi sesiju biće potrebna nova razmjena SIP signalnih poruka.Ovaj princip „three-way handshake“ dozvoljava forking, a to je paralelna pretraga koju inicira proxy, u kojoj više uspješnih odgovora može biti vraćeno kao jedan INVITE u pouzdanom smjeru, kao što će biti objašnjeno u nastavku.

5.2.2. Prenos SIP poruka preko IP-a

SIP poruke mogu biti prenošene preko transportnog sloja IP protokolom, uključujući i protokole TCP, UDP, SCTP i TLS. TLS je takođe poznat po imenu svog prethodnika SSL koji koristi TCP prenos. DTLS koristi UDP prenos. SIP ima ugrađene mehanizme pouzdanosti tako da može koristiti metodu najboljeg pokašaja „best effort“ nepouzdanih protokola kao što je UDP. Kad se koristi UDP jedna SIP poruka se prenosi po jednom UDP paketu. Kad se koristi TCP, prvo se uspostavi veza između korisničog agenta i sljedeće tačke „next hop“ (to može biti direktno drugi korisnički agent ili server). SIP poruke se onda šalju tom vezom. Content-length zaglavlje je prvenstveno za prenos ovih poruka i omogućava sastavljanje razdvojenih poruka. Odgovori se šalju drugom TCP vezom koja je otvorena u suprotnom smjeru, a koristi informacije koje su date u polju „via“ zaglavlja. TCP veza ne mora ostati otvorena za vrijeme trajanja sesije. Ako bude zatvorena nova TCP veza mora biti otvorena da bismo poslali ponovni poziv INVITE, ili da bismo završili sesiju BYE.Treba znati da SIP poruke sa više hopova mogu koristiti UDP za neke hopove, a TCP za neke druge hopove. Transportni protokol koji je korišten za hop bude snimljen u „via“ polju zaglavlja zajedno sa IP adresom i brojem porta za slanje odgovora. SIP poruke se takođe mogu prenositi koristeći i druge protokole kao što je SCTP razvijen od strane IETF SIGTRAN Working Group. SCTP omogućava pouzdanu vezu i dodatne funkcije kao što je multi-homing. Multi-homing omogućava hostu da se konektuje na dva ili više servera istovremeno. Bude li ijedan od ovih servera postao nepristupačan, saobraćaj se odmah prebacuje na drugi server, smanjujući vrijeme prekida.

Izbor protokola je određen aplikacijom. Najjednostavniji SIP korisnici, kao što su SIP telefoni, PC klijenti koriste UDP za prenos zbog jednostavnosti upravljanja UDP sesijama u usporedbi sa ostalim protokolima. Takođe nema kašnjenja u uspostavi veze (kao što je to slučaj sa TCP vezom) prije nego što počne razmjena SIP poruka. TCP se ponekad koristi između proxy servera ili u nekim drugim aplikacijama gdje je korisna stalna SIP konekcija. SCTP se preporučuje za veze između dva proxy servera ili proxy servera i velikih PSTN izlaza gdje su potrebne veze velike propusnosti i malih kašnjenja.

5.2.3. Media Negotiation

Media negotiation je dio sekvence INVITE/200/ACK koja se koristi za uspostavu SIP sesija između dvije krajnje tačke. SIP sam po sebi ne osigurava media negotiation, ali omogućava media negotiation između dva korisnička agenta koristeći Session Description Protocol (SDP). SDP nije pravi protokol, nego je više tekstualni opisni jezik, koji je definisan sa RFC 2327. Posjeduje i zahtijevana i polja opcije. Neka od zahtijevanih polja su uključena u same SIP poruke ali se ne koriste kao što će biti pokazano ovdje.

Slika 17 Primjer uspješno uspostavljene sesije koristeći INVITE

SDP je u početku razvijen sa poljem djelovanja u Internet multimedija arhitekturi kao vrsta “TV vodiča” za multikast multimedija sesije preko interneta. Neke od sposobnosti SDP su, a koje ne posjeduje SIP, obavještenje o izvori sesije, predmet sesije i funkcija rasporeda sa početnim i krajnjim vremenom sa ponavljanjem (t =... linija).Pregovori su ponuda-odgovor model definisan u RFC 3264 u kojem jedan korisnički agent predlaže jedan ili više tipova medija, a drugi korisnički agent ili prihvata ili odbija svaku medija sesiju u odgovoru. Prema slici 17, obično je ponuda sadržana u početnom INVITE od strane pozivaoca, a odgovor se prenosi u poruci 200OK. Dakle, pozivaoc može dozvoliti pozivanoj strani da odabere tip medija za sesiju tako što neće poslati SDP INVITE poruci. U ovom slučaju pozivana strna daje ponudu u poruci 200 OK (ili u pouzdanom privremenom odgovoru), i sada pozivaoc odgovara u poruci ACK. U SDP dijelu dodatom SIP zaglavlju, korisnički agent određuje tip medija, kodek, IP adresu, i broj porta za svaki medijski niz. Može biti određeno i više od jednog kodeka za svaki tip medija. Kada bude prihvaćen ponuđeni kodek korisnički agenti

moraju biti spremni primati podatke s tim kodekom dokle god traje ova sesija. Kao primjer ponuda/odgovor SDP razmjene pogledati RFC 4317.Primjer SDP ponude koji je prikazan u tabeli 4 sadrži dvije linije medija: jedna za video i jedna za audio. Svaka linija medija ima dva moguća alternativna kodeka koje podržava korisnički agent.

Tabela 4 Primjer SDP ponude sa opisom pojedinih linijaLinija Opisv=0 Verzija – Trenutni broj verzije SDP (0)-nije

korišten od strane SIP-ao=usera 2890844526 2890844526 IN IP4 client.example.com

Izvor – Samo verziju (2890844526) koristi SIP

s=Subject Temac=IN IP4 128.2.3.1 Veza – mreža (IN za INTERNET), tip adrese

(IP4 za IP verzija 4) i adresa (128.2.3.1)T=0 0 Vrijeme – početno i krajnje vrijeme – SIP ne

koristim=video 51372 RTP/AVP 34 98 Medija – tip medija (video), broj porta

(51372), tip (RTP/AVP profil) i broj (34 ili 98 profil)

a=rtpmap:34 H263/90000 Atribut – rtpmap lista atributa RTP/AVP video profil 34 uključujući kodek (H.263) i brzina uzorkovanja (90000 Hz)

a=rtpmap:98 H264/90000 Atribut – rtpmap lista atributa RTP/AVP video profil 98 (dinamički teret) uključujući kodek (H.264) i brzina uzorkovanja (90000 Hz)

m=audio 4006 RTP/AVP 0 97 Medija – tip drugog medija (audio), broj porta (4006), tip (RTP/AVP profil) i broj (0 ili 97 profili)

a=rtpmap:0 PCMU/8000 Atribut – rtpmap lista atributa RTP/AVP audio profil 0 uključujući kodek (PCMU – PCM µ-zakon) i brzina uzorkovanja (8000 Hz)

a=rtpmap:97 iLBC/8000 Atribut – rtpmap lista atributa RTP/AVP audio profil 97 (dinamički teret) uključujući kodek (iLBC) i brzina uzorkovanja (8000 Hz)

U odgovoru na ovu ponudu druga strana odbija video medija sesiju tako što postavlja broj porta na 0, i prihvata audio sesiju selektujući iLBC kodek i vraćajući broj porta različit od nule kao što je prikazano u tabeli 5.Dalji pregovori i promjene na mediju mogu se postići koristeći ponovni poziv re-INVITE kada bude sesija uspostavljena, kao što će biti opisano u sljedećem dijelu.Ovaj tip medija pregovora ograničenih sposobnosti je podržan SDP-om, dakle u SIP-u. Trenutno se razvija nasljednik SDP-a, eksperimentalno nazvan “SDPng” kao sljedeća generacija (Next Generation). Ovaj novi protokol će imati naprednije medija pregovore i sposobnosti opisa. Moguće je da će podrška SDP ostati na bazi SIP specifikacija, sa nasljednicima SDP će biti kao opcona podrška.

5.2.4. Modifikacija sesije

Kada se jednom uspostavi sesija koristeći sekvencu INVITE/200/ACK, ona može biti promijenjena sa drugom sekvencom INVITE/200/ACK, a ponekad i kao ponovni poziv re-INVITE. S obzirom da može biti samo jedan SIP zahtjev na čekanju, ponovni poziv ne može biti poslan sve dok inicijalni INVITE ne bude završen sa ACK. Ponovni poziv re-INVITE može biti izveden od bilo koje strane koristeći iste To, From (uključujući oznake), i Call-ID kao poziv INVITE. SDP u ponovnom pozivu reINVITE će zamijeniti pretpostavljeni inicijalni INVITESDP, ako je re-INVITE uspješan. Ako re-INVITE ne uspije iz bilo kog razloga ili bude odbačen, originalni SDP i originalna medija sesija će se nastaviti sve dok ne bude poslano BYE od bilo koje strane.

Tabela 5 Primjer SDP odgovora sa opisom pojedinih linijaLinija Opisv=0 Verzija – Broj trenutne verzije SDP-a (0) –

nije korišteno od strane SIPo=userb 2890844342 2890844543 INIP4client.example.net

Izvor – Nije korišten od strane SIP

s=- Subjekatc=IN IP4 16.22.3.1 Veza – Mreža (IN za internet), tip adrese (IP4

za IP verziju 4), adresa (16.22.3.1)t=0 0 Vrijeme – Početno i krajnje vrijeme – Nije

korišteno od strane SIP-am=video 0 RTP/AVP 34 98 Poruka – tip poruke (video), broj porta je

postavljen na nulu, što će reći da je video sesija odbijena

m=audio 6002 RTP/AVP 97 Poruka – tip poruke (audio), broj porta (6002), tip (RTP/AVP profil), i broj (profil 4), pošto broj porta nije nula ova sesija je odobrena

a=rtpmap:97 iLBC/8000 Atibuti – rtpmap lista atributa RTP/AVP audio profil 97, uključujući kodek (iLBC) i brzinu uzorkovanja (8000 Hz)

U primjeru na slici 18, poziv je uspostavljen između dva korisnička agenta koristeći opis poruke sdp1, prenesen u inicijalnom pozivu INVITE i 200 OK odgovoru. Pozivana strana pokušava izmijeniti parametre sesije šaljući drugi poziv INVITE sa porukom novog sadržaja sdp2. Ovo nije prihvatljivo za drugu stranu i ponovni poziv re-INVITE propada sa odgovorom 405 Not Acceptable u poruci 6. Sesija se nastavlja koristeći inicijalne parametre. Pozivana strana pokušava još jednom i ovoga puta ponovni poziv re-INVITE uspiejva te se onda stara sesija prekida dok je druga koristeći sdp2’’ i sdp1’’ uspostavljena sa drugačijim vrijednostima u oba smjera. Napomenimo da ponovni pozivi re-INVITE obično ne generišu privremene odgovore (kao što je 180Ringing), s obzirom da dvije strane već komuniciraju jedna s drugom.Recimo još i da ponovni poziv re-INVITE može promijeniti bilo koju karakteristiku poruka, uključujući i tip sesije, korišteni kodek, čak i izvorišnu IP adresu i broj porta.

Slika 18. Primjer promjene sesije koristeći poziv INVITE

5.2.5. Prekid i otkazivanje sesije

Prekid i otkazivanje sesije su dvije odvojene operacije u SIP protokolu ali često miješane. Prekid sesije se dešava kada bilo koji korisnički agent pošalje poruku BYE koja se odnosi na postojeći poziv (to jest uspješno uspostavljenu sesiju koristeći INVITE/200/ACK razmjenu). Ovo je pokazano na primjeru na slici 19.Prekid sesije se dešava kada korisnički agent prekine poziv prije završetka uspostave sesije i same uspostave poziva. Čitaoc može pomisliti na analogiju sa akcijom klika na tipku cancel u pregledniku. U ovom slučaju korisnik koji je poslao poziv INVITE, ali još nije primio krajnji odgovor (2xx, 3xx, 4xx, 5xx, ili 6xx), šalje CANCEL zahtjev. Zahtjev CANCEL može takođe biti iniciran od proxy da bi otkazao individualne dijelove u proxiju iz više dijelova ili u paralelnoj pretrazi. Dok su INVITE i BYE metode s kraja na kraj, CANCEL je primjer SIP zahtjeva koji je zahtjev skok po skok. Proxy prima CANCEL zahtjev i odmah odgovara sa odgovorom 200OK, sada proxy šalje CANCEL na sve destinacije do kojih je i originalni poziv INVITE poslan.

Slika 19. Primjer prekida sesije koristeći poruku BYE

Korisnički agnet prima CANCEL i odgovara sa 200OK ako krajnji odgovor još nije poslan ili odgovor 481 Transaction Unknown ako je krajnji odgovor poslan. Daljnja korespodencija je ustvari trka sa stanjem, gdje se poruke CANCEL i krajnji odgovor „sretnu na žici“. U tom slučaju korisnički agent treba poslati poruku BYE da bi otkazao poziv.

U primjeru na slici, korisnički agent šalje INVITE zahtjev, a onda i CANCEL zahtjev. Zahtjev INVITE je proslijeđen kroz dva proxy-ja da bi stigao do odredišnog korisničkog agenta. Primijetimo da zahtjev CANCEL poslan prvom proxiju rezultira odgovorom 200OK na zahtjev CANCEL, a zahtjev CANCEL se prosljeđuje sljedećem proxy-ju. Drugi proxy odmah šalje 200OK prvom proxy-ju a zahtjev CANCEL prosljeđuje odredišnom korisničkom agentu. Na kraju korisnički agent odgovara sa 200OK na CANCEL i 487RequestCancelled odgovorom na poziv INVITE. Odgovor 487 je potvrđen od strane drugog proxy-ja sa ACK, i onda se prosljeđuje 487 do prvog proxy-ja, koji će na kraju biti primljen i od strane korisničkog agenta koji je započeo poziv, koji onda zna da je sesija na čekanju uspješno otkazana. (Neuspjeli krajnji odgovori kao što su 3xx, 4xx, 5xx, ili 6xx se uvijek potvrđuju na bazi skok po skok metode. Samo 200 OK prima ACK s kraja na kraj). Korisnički agent je onda završio dva prenosa: CANCEL/200 i INVITE/487/ACK prenos.

Pošto je moguće CANCEL poslati istovremeno kad i 200OK odgovor, korisnički agent mora biti spreman poslati i ACK i BYE na 200 OK čak i nakon slanja CANCEL.Napomenimo da je CANCEL zahtjev jedinstven i ne može biti pozvan na autentikaciju kao ostali SIP zahtjevi, kao što će biti objašnjeno u nastavku ovog poglavlja.

5.2.6. Signalizacija u toku poziva

Signalizacija u toku poziva je razmjena signalnih poruka između dva korisnička agenta koji ne mijenjaju parametre sesije između njih. Ako pojava signalizacije u toku poziva promijeni parametre sesije (tj., SDP), onda će se pokrenuti reINVITE. Inače, SIP INFO metod će se

koristiti za prenos informacija između dva korisnička agenta. Informacija se prenosi u tijelu poruke INFO zahtjeva. Na primjer, informacije u signalizaciji u toku poziva sadžane u ISDN USR (Korisnik-korisnik poruka) poruci mogu biti prenesene koristeći INFO metod u mreži gdje se koristi ISDN User Part (ISUP) enkapsulacija. Primjer ovoga je prikazan na slici 20. gdje se koristi osnovno SIP-ISUP mapiranje od strane dva gateway-a. ISDN poruke na slici 20. su:

IAM—Initial address message – početna adresna poruka ANM—Answer message – poruka odgovor USR—User to user message – korisnik – korisnik poruka

Slika 20 Primjer otkazivanja sesije koristeći zahtjev CANCEL

5.2.7. Kontrola poziva

SIP arhtektura je jedna od peer-to-peer vrsta komunikacije sa kontrolom s kraja na kraj. Na primjer, proxy ne može pokrenuti BYE zahtjev za prekid poziva. Ovaj zahtjev može biti pokrenut samo od strane korisničkih agenata (krajnjih uređaja) koji učestvuju u pozivu.Dakako, mogućnost upravljanja i kontrole poziva između dvije strane od strane nekog trećeg mogla bi biti uveliko korisna u različitim implementacijama servisa. Na primjer, ugrađeni SIP URI na web stanici, nakon klika, bi mogao učiniti da desktop SIP telefon napravi poziv prema željenom URI. Ili kontrola poziva od treće strane može biti korištena u implementaciji web pozivnog centra ili ACD alat, koji je koristan za opsluživanje poziva za korisničke brojeve servisa, gdje kontroler prima pozive i usmjerava ih na osnovu nekih faktora kao što su dostupni agenti, dio dana, i ostali faktori.

Slika 21. Primjer signalizacije u toku poziva koristeći INFO

Postoje dva načina za implementaciju kontrole treće strane. Prva koristi kontroler koji prima SIP INVITE zahtjeve, odgovara na njih, a onda prosljeđuje zahtjev INVITE trećoj strani. Onda kontroler ostaje da prati signalizaciju, mijenja SDP s jedne grane na drugu, i transparentno kontroliše poziv. Drugi način koristi REFER metod da bi uspostavio kontrolu treće strane.U primjeru na slici 22. A i B uspostavljaju sesiju. A se onda obraća B da pokrene sesiju sa C koristeći REFER zahtjev. Onda A prekida sesiju sa B, dok B uspostavlja novu sesiju sa C.REFER zahtjev u poruci 6 ima sljedeći oblik:REFER sip:[email protected] SIP/2.0 Via: SIP/2.0/TCP pc.there.com:5060;branch=z9hG4bK765d To: User B <sip:[email protected]> From: User A <sip:[email protected]> Call-ID: [email protected] CSeq: 2 REFER Refer-To: <sip:[email protected]> Referred-By: <sip:[email protected]> Content-Length: 0

Slika 22. Primjer kontrole poziva koristeći REFER

Rezultujuća INVITE poruka (poruka 8) će onda imati sljedeći oblik:INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 100.101.102.103:5060 To: <sip:[email protected]> From: User B <sip:[email protected]> Call-ID: [email protected] CSeq: 67 INVITE Contact: sip:[email protected] Referred-By: <sip:[email protected]> Content-Length: ...Refer-To zaglavlje u zahtjevu REFER sadrži URI od onog kome se A obraća, dok zaglavlje Referred-By identificira A kao onog koji se obraća, i on se propušta do C u INVITE tako da C zna da se tački B obraća A u pokretanju ove sesije.

5.2.8. Preduslovi za uspostavu poziva

SIP ima dodatke koji zahtijevaju preduslove. Kvalitet servisa (QoS) može biti podržan na mrežnom sloju (IP sloj 3) i na podatkovnom sloju (sloj 2). QoS u IP mrežama je nezavisan od bilo koje specifične aplikacije ili mreže, stoga, potrebe ne moraju biti prema specifičnostima aplikacija (bile one telefoni, multimedija, finansijske transakcije, ili igrice). SIP je ortogonalan sa QoS.

Postavljanje aplikacija kao što su komercijalna telefonija sa QoS zahtijeva podršku priznatih mrežnih izvora (na primjer, davanje prioriteta toku podataka koji ima brzinu prenosa podataka 100 kb/s za 30 minuta na daljinu od preko 5,000 km). Zahtijeva se autorizacija da bi se osigurali mrežni resursi sa SIP pokretanje sesije koje uključuje kompleksne procedure autentikacije, autorizacije i naplate (AAA). Mi ćemo se zato ograničiti na diskusiju o QoS za SIP samo za jednostavne slučajeve gdje AAA problemi mogu biti zanemareni.

SIP omogućava korisničkim agentima da uspostave sesiju koristeći INVITE/200/ACK razmjenu. Da bismo uspostavili IP sesiju sa QoS, potrebna je malo komplikovanija razmjena

poruka. Integrisani servis protokol QoS u ovim primjerima je Resource Reservation Protocol (RSVP). Pristup opisan ovdje za SIP će takođe raditi i sa ostalim QoS pristupima, kao što je uspostavljanje bita tipa servisa (TOS) u IP zaglavlju koji se koristi u DiffServ.

Pojednostavljeni pristup QoS bi bio da prvo uspostavimo vezu na osnovu najboljeg pokušaja “best-effort” između korisničkih agenata, onda koristimo ponovni poziv re-INVITE za uspostavu nove QoS sesije. Kako je SIP razmjena poruka potpuno nezavisna od medija, u potpunosti je moguće uspostaviti sesiju koristeći, sesija može propasti samo zbog nedostatka propusnog opsega na mediju, i u tom slučaju će ovaj pristup propasti. Takođe, postoji želja da se oponaša ponašanje PSTN-a, gdje na pozivanoj strani telefon neće zvoniti ako nepostoji dovoljno resursa (tj, linija (trunk)) da bi se završio poziv ako bi odgovorila druga strana. Pristup opisan ovdje je razvijen od strane Packet Cable consortium za projekat Voice over Cable Modem – glas preko kablovskog modema.

Ovaj tok poziva koristi tri proširenja SIP-a. Prvi je Early Media, koji dozvoljava SDP-u da povremeno prikazuje poruku 183 Session Progress. Ovo dozvoljava dodatnomo mediju (SDP) rukovanje između korisničkih agenata potrebno za uspostavu QoS prvenstveno da bi bilo odgovoreno na poziv. Drugo proširenje SIP-a je Reliable Provisional Responses – pouzdani povremeni odgovor, koji omogućava da se izgubljeni privremeni odgovor kao što je 183 detektuje i ponovo pošalje (vidi “Ponovno slanje poruka u SIP-u”). Prijemnik 183 odgovora je obaviješten sa PRACK porukom (Provisional Response ACKnowledgement – potvrda privremenog odgovora). Treće proširenje je korištenje metode COMET (preCOnditions MET – metod preduvjeta), koji dozvoljava UAS da označi QoS preduslove koji mogu biti zahtijevani tako da korisnik može biti obaviješten, i poslan mu odgovor 180Ringing. Poziv se onda normalno nastavlja. Napomenimo da je potreba za QoS pokrenuta u zadnjoj liniji SDP-ovog inicijalnog zahtjeva INVITE, kao što je to prikazano ovdje sa atributima qos:mandatory:INVITE with mandatory QoS request INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK765d To: <sip:[email protected]> From: User A <sip:[email protected]> Call-ID: 5448kewl13981304oierek Max-Forwards: 0 CSeq: 1 INVITE Contact: sip:[email protected] Content-Length: ...v=0 c=IN IP4 100.101.102.102 m=audio 47172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=qos:mandatory

5.2.9. Ponovno slanje poruka u SIP-u

Osnovne SIP specifikacije dozvoljavaju da gotovo bilo koji izgubljeni zahtjev ili odgovor bude automatski ponovo poslan. Pošiljaoc SIP zahtjeva koristeći nepouzdan transport starta tajmer, označen kao T1 (osnovna vrijednost mu je 500ms). Ako odgovor nije primljen prije isteka ovog vremena, zahtjev se ponovo šalje. Ako je povremeni odgovor primljen (1xx), pošiljaoc prebacuje tajmer na sljedeće duže vrijeme označeno sa T2 (osnovna vrijednost mu je 4s). Ako je zahtjev izgubljen prijemnik ga neće primiti i neće ni generisati odgovor. Nakon isteka vremena T1, pošiljaoc će ponovo poslati zahtjev. Ako je izgubljen odgovor na zahtjev, pošiljaoc će ponovo poslati zahtjev. Prijemnik će prepoznati zahtjev kao ponovno poslan i on će ponovno poslati svoj odgovor.

Provođenje zahtjeva INVITE je malo drugačije od ostalih tipova zahtjeva, pošto treba više vremena da na poziv odgovori osoba. Prijemnik povremenog odgovora na INVITE ne prebacuje tajmer na T2 nego zaustavlja sva ponovna slanja zahtjeva INVITE. Onaj koji odgovara na INVITE postavlja tajmer T1 kada pošalje krajnji odgovor. Ako ne primi ACK, onaj koji odgovara ponovo šalje krajnji odgovor. Ovo omogućava da se izgubljeni INVITE, krajnji odgovor ili ACK pronađu i ponovo pošalju.

Izuzetak u ovom pravilu ponovnog prenosa su povremeni odgovori. Pošto povremeni odgovori ne primaju ACK ne postoji način ni za jednu stranu da znaju je li ovaj zahtjev izgubljen.

Pouzdani povremeni odgovor kao proširenje za SIP je razvijen da bi omogućio da povremeni odgovori budu potvrđeni sa PRACK čime se omogućava pouzdanost svim zahtjevima i odgovorima u SIP-u.

Slika 23. Preduslovi za uspostavu poziv korištenjem UPDATE i PRACK

5.3. funkcije bez sesije

Neke SIP funkcije se ne odnose izravno na podešavanje sesije. Ove funkcije se mogu pojaviti izvan sesija zasnovanih na SIP-u.

5.3.1. Pokretljivost ( mobilnost )

Registracijska funkcija SIP-a je vrlo slična registraciji na mobilnim telefonima. U registraciskoj poruci, korisnik šalje proxy server URI kojim želi primati pozive. Ova ugradnja koja podržaje mobilnost je izuzetno korisna osobina SIP-a i jedna je od glavnih prednosti u odnosu nad ostalim protokolima. Ta podrška mobilnosti je dovela do primjene protokola u mnogim novim aplikacijama i koja je predložena za upotrebu kontrole poziva u trećoj generaciji bežičnih mreža.SIP REGISTER zahtjev se koristi za ostvarivanje ove funkcije. Zahtjev sadrži zaglavlja kontakata, koja su URI-ovi registrovani od strane korisnika.

Na primjer, uspješna korisnička registracija agenta je prikazana na slici 6.10. Korisnik na početku registrira svoj uredski SIP telefon slanjem REGISTER poruke Registracijskom serveru. Registrar pohranjuje korisničku poruku u lokaciskom servisu i vraća 200 OK potvrdu registracije. Kasnije taj dan, kad korisnik napusti svoj ured zbog odlaska kući, gdje poništava svoju uredsku

telefonasku registraciju i registrira svoj SIP na kućni telefon. (Registracija mobilnog telefona tijekom mijenjanja mogla bi biti također razmatrana). Imajte na umu da protokol koji vrši upload registracije na lokacijski servis ili druge baze podataka nije SIP. Dolazni pozivi prema korisničkom URI će sada biti preusmjereni na njegovu IP adresu SIP-a kućnog telefona.

Također, treba imati na umu da kućni telefon ne treba biti SIP za ovu pred-pozivnu mobilnost. Korisnik također može registrirati PSTN telefon koristeći internet pristup, e-mail, ili reprogramirati registraciju za određeno vrijeme.

Korisnički agent se može podesiti da se automatski registruje u vrijeme uspostavljanja, za vrijeme korištenja, ili kad god se novi korisnik loguje na određeni uređaj. Registracija nije ograničena samo jedan URI. Više URI-a može biti korištena da prikaže listu brojeva mogućih alternativnih lokacija u željenom redu, ili mogu biti korišteni da prikažu listu mnogostrukih mogućih servisa kao što su SIP,PSTN, i e-mail. Na primjer uzmajući u razmatranje sljedeču REGISTER poruku:

SIP client to RegistrarREGISTER sip:registrar.here.com SIP/2.0Via: SIP/2.0/UDP 4.3.2.1:5060;branch=z9hG4bK87dsTo: User A <sip:[email protected]>From: User A <sip:[email protected]>;tag=34323kl12dCall-ID: a532431277gfhd43gsfg3awrsadMax-Forwards: 70

CSeq: 16 REGISTERContact: sip:[email protected];class=personalContact: tel:+1-314-555-1212Contact: mailto:[email protected]: 0Registrar to SIP clientSIP/2.0 200 OKVia: SIP/2.0/UDP 4.3.2.1:5060;branch=z9hG4bK87dsTo: User A <sip:[email protected]>;tag=9128394From: User A <sip:[email protected]>;tag=34323kl12dCall-ID: a532431277gfhd43gsfg3awrsadCSeq: 16 REGISTERContact: sip:[email protected];class=personalContact: tel:+1-314-555-1212Contact: mailto:[email protected]: 0

200 OK odgovora REGISTER ehima tri Contanct (Kontakta) URI-ja koji su uspješno registrovani. U ovom slučaju, upit Lokacijskom Servisu (Location Service) za SIP URI sip: [email protected] će vratiti tri URI Kontakta koji su registrovani. Prvi je SIP URI koji se može koristiti za domet korisnika A. Drugi URI predstavlja telefonski broj korisnika A, koji bi mogao biti postignut putem PSTN (ili preko SIP-a i gateway), i e-mail adresu korisnika A. URI-jev SIP u ovom primjeru može također sadržavati parametar ekstenzije koji nije prikazan ovdje, kao što je Contanct koji su definirani u Caller Postavkama dokumenta , koji dozvoljava korisničkom agentu da indentifikuje informacije o vrsti uređaja indentifikovanog URI-jem. Na primjer, prvi URI je identificiran kao osobni URI, drugi kao govorna pošta, treći je za posao, a četvrti je za mobitele. Naravno, a SIP poslužitelj će procesuirati listu URI-ja pokušavajući prvo prvi Kontakt (Contact) header URI, a zatim drugi, i tako dalje, uz pretpostavku redoslijednog pretraživanja. Reject-Contact zaglavlje (zaglavlje za odbijanje kontakta) radi na sličan način, ali sa obrnutim rezultatom. Na taj način, SIP omogućava korisničkim postavkama da budu prenesene porukom koja sadrži zahtjev. Na primjer, SIP zahtjev poslan na korisnikov URI može biti preusmjeren na bilo kojem broju uređaja, ovisno o tome gdje je korisnik trenutno registrovan, i koje su karakteristike i skripte aktivirane u pozvanoj strani SIP mreža. Također, ASIP zahtjev (ASIP request) može biti poslan sadržavajući Reject-Contact zaglavlje, ukazivajući da podnositelj zahtjeva ne želi voicemail uslugu, za primjer. Kada je SIP poruka obrađena od strane servera (poslužitelja), to obično zavisi od poslužitelja da li se radi o proxy zahtjevu ili zahtjevu za preusmjerenje, i da li će se prizvati serijski ili paralelno pretraživanje (forking). Međutim, korištenje zaglavlja za podnošenje zahtjeva za raspolaganje (Request-Disposition header) dopušta podnosiocu zahtjeva da ima određene ulaze. Na primjer, zahtjev koji sadrži Request-Dispositon: proxy, dosljedno označava da podnositelj zahtjeva ima želju da za zahtjev bude korišten proxy umjesto preusmjeravanja, i da ima serijsko pretraživanje za razliku od paralelnog pretraživanja. Postavke Pozivatelja dokumenta (The Caller Preferences document) opisuje sve opcije. Treba Imati na umu da proxy koji ne podrćane određene značajke može jednostavno zanemariti zaglavlje. Opis karakteristika pozivatelja (The Caller Preferences draft) uključuje pseudokod koji opisuje točno URI i parametar podudaranja, i interakciju q povlaštene vrijednosti, ako je prisutna. Treba imati na umu da upotreba povlaštenja pozivatelja definiranog proširenja kontakt zaglavlja je korisno u SIP CGI i CPL skriptiranju za stvaranje SIP usluga. Korištenje zahtijeva: prefs zaglavlje omogućuje korisničkom agentu da zahtijeva da se registar podržava karakteristike pozivatelja i da će postupati u skladu s tim.


5.3.2. Prenos poruke

Metoda poruka (The MESSAGE method) jednostavno prenosi tijelo poruke na URI odredište sa ili bez uspostavljanja sesije. Na primjer, razmatrajući sljedeću instant poruke (IM) prenesenu koristeći SIP:

SIP messageMESSAGE im:[email protected] SIP/2.0Via: SIP/2.0/UDP pc.here.com;branch=z9hG4bK343gTo: User B <im:[email protected]>From: User A <im:[email protected]>;tag=4541232dsMax-Forwards: 70Call-ID: a532431277432513CSeq: 15 MESSAGEContent-Type: text/plainContent-Length: 15Hi, how are you?

Primijetićemo da su URI u primjeru IM URI umjesto SIP URI. Kada korisnik B dobiva poruku, OK 200 odgovor biva generiran. Za razliku od Info metode, koje mogu biti poslane samo ako je uspostavljena sesija između dva korisnička agenta, zahtjev poruke može biti poslan u bilo kojem trenutku. SIP podrška prisutnosti i razmjene trenutnih poruka uključuje SIP poruke kao u navedenom primjer. Druge metode u SIP za podršku instant komunikacija su aktivnosti vezane za pretplatu i obavijesti za prisustvo.

5.3.3. Procesi pretplate i obavijesti

Sposobnost da se zahtijeva i prima obavijest kada se određeni događaj dogodi je podržano u SIP-u od SUBSCRIBE i NOTIFY tipova zahtjeva [26], [27]. Na primjer, značajka automatskog poziv u telefoniji može se koristiti kada je pozvana strana zauzeta (off hook), a pozivatelj želi biti obaviješten čim je pozivani pretplatnik dostupno [29]. Na slici 6.11, korisnik A šalje zahtjev INVITE te primi odgovor od B korisničkog agenta 486 Busy Here (Zauzeto). Korisnik A onda šalje SUBSCRIBE zahtjev za korisnika B zahtjevajući obavijest kada korisnik je korisnik B dostupna za uspostavu sesije. Kada korisnik B šalje NOTIFY zahtjev ukazivanja da je korisnik sada dostupna, korisnik A odmah uspostavlja sesiju.

Zahtjev pretplatnika ima sljedeći obrazac:SUBSCRIBE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 4.3.2.1;branch=z9hG4bK343dTo: User B <sip:[email protected]>From: User A <sip:[email protected]>;tag=h34s341Max-Forwards: 70Call-ID: a5f2d43127767eh54wfdCSeq: 23 SUBSCRIBEContact: <sip:[email protected]>Event: dialogExpires: 60Content-Length: 0

Zahtjev za notifikaciju ima formu:NOTIFY sip:[email protected] SIP/2.0Via: SIP/2.0/UDP pc.here.com:5060;branch=z9hG4bK343dTo: User A <sip:[email protected]>;tag=9839421323

From: User B <sip:[email protected]>;tag=h34s341Max-Forwards: 70Call-ID: a5f2d43127767eh54wfdSubscription-State: active;expires=55CSeq: 5 NOTIFYEvent: dialogContent-Length: ...

Na zaglavlju procesa se vidi koja notifikacija procesa je korištena. Ako korisnički agent Korisnika B nije spreman da izvrši notifikaciju ovog procesa, može se poslati odgovor 603 Decline. Servisna mreža može se graditi u izvedbi bez servera koristeći SUBSCRIBE i NOTIFY. SIP također podržava pristup baziran na serveru pomoću PUBLISH metoda.

5.3.4. Publikacija prisutnosti

SIP PUBLISH metoda dopušta korisničkom agentu da objavi ili učita informacije o prisutnosti na server. Taj server onda može da distribuira ovu informaciju. Slika 6,12 prikazuje jedan primjer za to.

5.3.5. Traženje Autentifikacije

SIP podržava dvije vrste traženja autentifikacije: korisnički agent prema korisničkom agentu, i korisnički agent prema serveru. Trenutno se ne podržava traženje autentifikacije server prema serveru ali to može biti ostvareno pomoću ne-SIP sheme kao što je IPSec. SIP podržava određen broj autentifikacijskih shema preuzetih od HTTP-a. SIP Digest autentifikacija je danas najviše upotrijebljena schema, koja se oslanja na traženje/odgovor i tajnu između korisničkog agenta koji traži autentifikaciju i proxy-ja ili korisničkog agenta koji zahtjeva autentifikaciju.

Od bilo kojeg SIP zahtjeva može biti zatražena autentifikacija. Tajna se obično sastoji od šifrovanog korisničkog imena i šifre. Tipična razmjena autentifikacijskih SIP poruka između korisničkih agenata ima formu INVITE/401 Authentication Required/ACK u kojoj korisnički agent saznaje da zahtjev traži autentifikaciju. Također saznaje prirodu zahtjeva autentifikacije iz 401 odgovora. Poslije toga se šalje novi INVITE koji sadrži Authorization header. Ako sadrži tačne preporuke poziv će se nastaviti kao normalan. U suprotnom će biti biće primljen novi 401 odgovor. Proxy server također može tražiti autentifikaciju koristeći odgovor 407 Proxy Autentification Required. Ali autentificiranje jednog proxy-ja od strane drugog nije podržano u SIP-u. Umjesto toga, jedan proxy može uspostaviti sigurnu vezu sa drugim proxy-jem koristeći IPSec.

Primjer SIP digest razmjene informacija je prikazano na slici 6,13. Inicijalna Invite poruke nema autorizacijske podatke i primljen je odgovor od Proxy-a koji glasi 407 Proxy Authorizations Required (potrebna proxy autorizacija), koja sadrži proxy-autorizacijsko zaglavlje koje opisuje prirodu problema. Nakon slanja ACK-a prema proxy, korisnički agent tada ponovo šalje poziv za autorizaciju sa zaglavljem koje sadrži šifrovano

korisničko ime i šifru korisnika. Proxy onda prihvaća podatke, šalje 100 Trying odgovor, i prosljeđuje zahtjev na odredišni korisnički agent. Korisnički agent tada pokreće vlastitu autentifikaciju sa 401 Neovlaštenim odgovorom. Ovaj odgovor je proslijeđen od strane proxy-a natrag na pozivanje korisničkog agenta. SIP korisnički agent onda napokon čini pravu stvar i ponovo šalje INVITE zahtjev koji sadrži obje proxy-autorizacije sa podacima za proxy i zaglavlje sa autentifikacijom za drugi korisnički agent. Sljedeće su detalji (pojedinosti) poruke 11, koje sadrže oba kompleta podataka:

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 4.3.2.1To: User B <sip:[email protected]>From: User A <sip:[email protected]>Call-ID: [email protected]: 3 INVITEProxy-Authorization: Digest username=”usera”,realm=”SIP Telephone Company”, nonce=”814f12cec4341a34e6e5a35549”opaque=””, uri=”sip:proxy.sip.com”, response=”6131d1854834593984587ecc”Authorization: Digest username=”A”, realm=”userb”,nonce=”e288df84f1cec4341ade6e5a359”, opaque=””,uri=”sip:[email protected]”, response=”1d19580cd833064324a787ecc”Contact: sip:[email protected]: ...

Na taj način, SIP podržava oboje mrežnu (server) i korisničku (korisnički agent) ovjere (podateke) unutar poziva.

5.3.6. Mogućnost proširenja

SIP protokol je osmišljen sa mogućnošću proširenja . Kao posljedica toga, protokol je osmišljen tako da korisnički agenti mogu implementirati nove ekstenzije pomoću novih zaglavlja i tijela poruka bez potrebe za središnjim serverima kao što su proxy za podršku extenzija. Po defaultu, proxy proslijeđuje nepromijenjen nepoznat tip zahtjeva i zaglavlja. Korištenje podržanih zaglavlja omogućava podnositelju zahtjeva da obavijestiti mrežu i drugi korisnički agent od kojeg su ekstenzije i karakteristike podržane, dopuštajući im opciju aktiviranja karakteristike. Ako je je potrebno da se karakteristika shvati ili aktivira, onda se upotrebljava Require header [30], koji je uključen u zahtjev. Korisnički agent koji prima takav zahtjev mora vratiti pogrešku ako ne razumije ili ne podržava karakteristiku.Tu je i Proxy-Require zaglavlje koje sadrži listu karakteristika (značajki) koje bilo koji proxy na putu mora podržavati. Međutim, primjena ovog zaglavlja je obeshrabljena, jer njegova prekomjerna upotreba će dovesti do gubitka poziva i problema interoperabilnosti.

SIP korisnički agenti također trebaju ukazati na metode (načine) i mogućnosti koje pružaju podršku koristeći Alow (dopusti), Supported (Podržano), Alow-Events (Dopušteni procesi), i Accept-Content (Prihvatljivi sadržaj) polja zaglavlja.

6. Osnovni SIP pozivZa uspostavu komunikacije u IP mrežama temeljenim na SIP protokolu koristi se:- SIP protokol s kraja na kraj za kreiranje, modificiranje i završavanje sesija,- SDP (Session Description Protocol) za prijenos informacija (IP adresa, port, atribute sesije,

lista podržanih medija, lista podržanih algoritama za sažimanje po mediju, medija atribute i sl.) potrebnih za otvaranje logičkih kanala. SDP se prenosi unutar SIP poruka.

Jedan primjer uspostave komunikacije u SIP mreži prikazan je na slici 24. Krajnja točka 1 šalje zahtjev za uspostavu komunikacije, šalje se INVITE zahtjev s SDP ponudom. Najvažnije informacije koje se nalaze u SDP ponudi su IP adresa, port, te lista podržanih algoritama sažimanja izlistanih po prioritetu. Kada krajnja točka 2 primi tu informaciju, logički kanal ka krajnjoj točki 1 se može smatrati otvorenim. SDP odgovor na ponudu se može poslati u bilo kojem prijevremenom odgovoru ili u konačnom odgovoru na INVITE zahtjev. SDP odgovor sadrži: IP adresu, port, te listu zajedničkih algoritama sažimanja posloženih po prioritetu. Prvi algoritam se smatra odabranim, a krajnje točke mogu promijeniti algoritam na bilo koji iz liste bez slanja zahtjeva za promjenu. U primjeru na slici SDP odgovor je poslan u 183 Session Progress privremenom odgovoru. Ako je krajnja točka 1 indicirala podržavanje PRACK (Provisional Responces ACKnowledgement) slanjem parametra 100rel, te ako krajnja toča 2 također indicirala podržavanje PRACK zahtjeva, krajnja točka 1 će svaki primljeni privremeni odgovor potvrditi slanjem PRACK zahtjeva. Ovo je uvedeno jer se na transportnoj razini najčešće koristi UDP koji ne osigurava potvrdu prenosa. U slućaju kada PRACK zahtjev nije podržan, SDP odgovor se mora ponoviti u konačnom pozitivnom odgovoru na INVITE. Nakon prijema SDP odogvora, logički kanali se mogu smatrati otvorenim. Nakon što je krajnji korisnik upozoren o dolaznom pozivu (zazvoni telefon), krajnja točka 2 šalje 180 Alerting privremeni odgovor. Nakon što se krajnji korisnik prihvati poziv šalje se 200 OK (INVITE) konačni odgovor. Potvrda prijema konačnog odgovor se šalje u ACK zahtjevu (ovo je jedini zahtjev na koji se ne očekuje odgovor). Kada je komunikacija završena šalje se BYE zahtjev.

Slika 24. Uspostava komunikacije u mreži temeljenoj na SIP protokolu

6.1. Osnovni SIP-T poziv

U slučaju kada su dvije PSTN mreže povezane preko IP mreže temeljene na SIP protokolu, dolazi do gubitka dijela informacija iz ISUP poruka, jer nema potpuno definiranog jednoznačnog preslikavanja parametara između ISUP i SIP parametara. Zbog toga je definiran SIP-T protokol, kao proširenje SIP protokola na način da se unutar SIP poruka enkapsuliraju ISUP poruke. Za uspostavu komunikacije u IP mrežama temeljenim na SIP-T protokolu koristi se:- SIP i ISUP za prijenos informacija za uspostavu komunikacije. ISUP poruke se prenose

unutar SIP poruka,- SDP (Session Description Protocol) za prijenos informacija potrebnih za otvaranje logičkih

kanala. SDP se prenosi unutar SIP poruka

Jedan primjer uspostave komunikacije u SIP-T mreži prikazan je na slici 25. Krajnja točka 1 šalje zahtjev za uspostavu komunikacije, šalje se INVITE zahtjev s SDP ponudom i IAM (Initial Address Message) porukom. Kada krajnja točka 2 primi tu informaciju, logički kanal ka krajnjoj točki 1 se može smatrati otvorenim. Slanje i obrada SDP ponude, te slanje i obrada SDP

odgovora je isto kao i za SIP protokol. U primjeru na slici SDP odgovor je poslan u 183 Session Progress privremenom odgovoru. Ako je krajnja točka 1 indicirala podržavanje PRACK (Provisional Responces ACKnowledgement) slanjem parametra 100rel, te ako krajnja toča 2 također indicirala podržavanje PRACK zahtjeva, krajnja točka 1 će svaki primljeni privremeni odgovor potvrditi slanjem PRACK zahtjeva. U slućaju kada PRACK zahtjev nije podržan, SDP odgovor se mora ponoviti u konačnom pozitivnom odgovoru na INVITE. Nakon prijema SDP odogvora, logički kanali se mogu smatrati otvorenim. Nakon što je krajnji korisnik upozoren o dolaznom pozivu (zazvoni telefon), krajnja točka 2 šalje 180 Alerting privremeni odgovor s enkapsuliranom ACM (Address Complete Message) porukom. Nakon što se krajnji korisnik prihvati poziv šalje se 200 OK (INVITE) konačni odgovor s enkapsuliranom ANM (Answer Message) porukom. Potvrda prijema konačnog odgovor se šalje u ACK zahtjevu (ovo je jedini zahtjev na koji se ne očekuje odgovor). Kada je komunikacija završena šalje se BYE zahtjev s enkapsuliranom REL (Release) porukom.

Slika 25. Uspostava komunikacije u mreži temeljenoj na SIP-T protokolu

7. Ostale karakteristike SIP protokola

7.1. Interoperabilnost SIP-protokola sa ITU-T protokolima

Velike međunarodne organizacije IETF ( Internet Engineering Task Force ) , ITU-T (International Telecommunications Union Telecommunications Standardization Sector ), kao i ETSI (European Telecommunications Standards Institute) su posvetile mnogo rada i pažnje za interoperabilnost SIP-a sa nizom drugih protokola, kao što su navedeni u tabeli:

Tabela 6. Interoperabilonst SIP protokola i ITU-T protokolaENUM E.164 za IP adresu koristeći DNS

SIP H.323 za interworking (za interakciju)

Pristup ISDN i PSTN IN uslugama sa SIP mreža

SIP i QSIG (signalizacijski protokol) za interakciju PBX - om

SIP-T SIP za telephone, za prijenos telefonskog signala kroz IP

Na slijedećoj slici prikazan je primjer SIP i PSTN interoperabilnosti koje će biti upućene slijedećim SIP-PSTN pristupnim uslugama. Na slici se također vidi SIP-PBX gateway.

Slika 26. IP-PSTN gateway usluga i SIP-PBX gateway7.2. Komercijalni SIP produkti

Kada je riječ o tehnologiji, aparaturi i sistemima vezanih za SIP, onda je vrlo važno reći da se u proteklim godinama neprestano i mnogo radilo na daljnjem unapređenju i razvoju sa nastojanjem uvođenja što više invoacija na tržište.

Danas većinom kompletna tele-komunikacijska industrija, internet ekspanzija i telekom servisi (žični ili bežični) koriste SIP.

Lakše je nabrojati izuzetke servisa koji ne koriste SIP, nego one koje koriste, a to su npr. Skype i Google Talk. Međutim i tako zatvoreni tipovi servisa koriste SIP za

konekciju sa ostatkom svijeta.

SIP produkti i servisi se mogu klasificirati prema mnogim kriterijima i aspektima, kao npr. tehničkog, tehnološkog, tržišnog itd. Ovdje ćemo navesti par proizvoda :

SIP Firewall-i i PBX – Gateway-i

SIP server

SIP servisi

SIP software komponente i alati

SIP korisnički agenti za PC / laptop i mobilne telephone itd.

Na slijedećoj slici je prikazan vrlo popularan tip SIP telefona sa ekranom

7.3. SIP sigurnost

Prednosti Internet komunikacije sa svijetom mogu nažalost istovremeno imati određene slabosti odnosno bolne tačke, sve dok se u startu ne ugrade sigurnosne preventivne mjere u SIP.

Spam ili širenje određenih bespotrebnih sadržaja mailovima, susrećemo također u VoIP- i Instant Messaging sistemima ito u raznim oblicima. Naravno, postoji solucija za protekciju od navedenih.

Postoji cijeli set vrijednosti i parametara za implementaciju SIP-security-a , koji uključuje mnoge aspekte kao na primjer:

1. REGISTER metoda,

2. denial-of-service (DOS) prevencija, i

3. Transport Level Security (TLS).

Ne postoji jednistveni sigurnosni mehanizam za potpunu protekciju SIP-a. Interesantno pitanje vezano za sigurnost SIP-a je koliko napora treba uložiti u dizajniranje sigurnosnih mjera? Odgovor na ovo pitanje nalazimo u potpuno novom pristupu sigurnosti koji ne zavisi od sigurnosti na perimetru.

Najopasnije je očekivati da se SIP-protokol i komunikacijske sigurnosti mogu integrisati u jedan funkcionirajući sistem, međutim-nažalost momentalno postoji veliki broj takvih subjekata koji promovišu ovakav pristup.

Druge uobičajene sigurnosne zamke potiću iz pretpostavke da u specifičnim zatvorenim IP-mrežama postoji dovoljan nivo sigurnosti, ne uzmiajući u obzir širok spektar ranjivosti i osjetljivosti iz internih izvora i određenih inficiranih aplikacija koje su u uletile mrežu na različite načine.

Generalno govoreći o sigurnosti, dobar SIP-security se zasniva na kvalitetnom software-u, sigurnosnim procedurama i praktičnoj realizaciji.

7.4. Šta SIP ne radi

Prema dosada rečenom, možemo zaključiti da SIP ne ostavlja utisak nekog “magičnog protokola” koji je u stanju da prevaziđe sve komunikacijske probleme. U kasnijim izlaganjima (poglavlje 6) ćemo vidjeti da je SIP veoma moćan no u drugu ruku jednostavan protokol za uspostavljanje interaktivnih komunikacija / sesija preko interneta.

SIP je protokol za iniciranje, modifikaciju i završavanje interaktivnih sesija. Proces uključuje otkrivanje odnosno pronalaženje korisnika, bez obzira gdje je on u datom momentu, tako da mu se može proslijedit zahtjev.

Naravno da treba spomenuti da postoji niz restrikcija odnosno / mogučnosti za čije izvršenje SIP nije dizajniran :

1. SIP nije namijenjen zamjeni svih telefonskih mogućnosti i servisa sa mreže s komutacijom kanala. Razlikujemo mnoštvo telefonskih servisa koja imaju svoja

obrazloženja i afirmaciju a proistiću upravo iz ograničenja koje imaju tehnologije zasnovane na komutaciji kanala.

Prenosiv lokalni telefonski broj na Internetu je još jedan primjer usluge koja nema smisla, budući da SIP može podržati prenosivost lokalnog broja, ali takav servis nije potreban budući da Universal Resource Identifier (URI) nema geografskiog značaja. Zatim, Caller ID predstavlja plaćenu uslugu koja je beznačajna za SIP, kao što su na primjer u e-mailu opcije "To:___“ i ”From:__“ besplatne.

2. SIP nije transfer protokol (kao npr. HTTP), te nije predviđen za prijenos velikih podataka, nego je dizajniran za transport isključivo malih količina podataka potrebnih za uspostavljanje interaktivnih komunikacija.

Manje količine podataka koje se ne odnose na uspostavu poziva(npr. kratke text poruke za IM) su pogodne za prijenos SIP-om, međutim kada je riječ o većim sadržajima, onda kažemo da ovaj tip protokola nije adekvatan za transportovanje.

3. SIP nije rezervacijski ili prioritetizacijski protokol,nego kontrolni protokol aplikacijskog sloja, tako da ne može osigurati QoS, ali može da interagira sa drugim protokolima dizajniranim tako da podržavaju QoS.

8. Zaključak

U zadnjih dvadesetak godina dolazi do ubrzanog razvoja svih komunikacijskih tehnologija, a jedna od onih koje se danas najbrže razvijaju je svakako i IP telefonija.Postoje procjene da će u idućem desetljeću ovaj način komunikacije postati prijetnja tradicionalnom telefonu i po kvaliteti usluge, a, što je još značajnije, po cijeni i velikom broju dodatnih mogućnosti koje omogućava ovakav oblik komunikacije.Zbog značajnog povećanja brzine pristupa Internetu u zadnjih nekoliko godina stvorena je kritična masa korisnika čiji zahtijevi za bržom i kvalitetnijom komunacijskom uslugom potiču razvoj ovih tehnologija. Procjenjuje se da će do 2010. najveći diokorisnika Interneta biti povezan najmanje 56k analognim modemima, iako neki optimističniji predviđaju značajan pad cijene DSL veze i korištenje stalne veze u najvećem broju zemalja.Činjenica je da je uopće moguće usmjeravati tradicionalne telefonske pozive preko IP mreže također dovodi u pitanje opstanak velikog broja kompanija koje se bave isključivo međunarodnim pozivima. Trenutno postoje dva prijedloga standarda na ovome području – prvi je SIP (Session Inititation Protocol) koji zastupa IETF a drugi H.323 koji zastupa ITU.VoIP je postao vrlo uspješna tehnologija za prijenos govora o čemu svjedoči brz rast tržišta računalnih telefonskih proizvoda. Kako uspostava i raskidanje poziva spada u najvažnije funkcije u telekomunikacijskoj infrastrukturi, signalizacija je, od samog početka, bila jedno od ključnih područja VoIP tehnologija. No, osim signalizacijskog protokola koji osigurava brzu i pouzdanu uspostavu i raskidanje poziva, i neki drugi aspekti igraju važnu ulogu. Kvaliteta i dostupnost usluge koju pruža PSTN mreža predstavlja velik izazov, a usporediva/slična razina se očekuje od svake nove mreže pa tako i od VoIP mreže. SIP i H.323 protokoli su na početku njihove standardizacije imala različite namjene (H.323 protokol je prvobitno zamišljen kao protokol za višestrane višemedijske konferencije preko paketskih mreža, a SIP s namjerom kreiranja protokola za uspostavu, modifikaciju i raskidanje IP multimedijalnih sesija između jednog ili više sudionika), kasnijim poboljšavanjem mogućnosti su im se proširile, te su sada ta dva protokola sve sličnija (sličnih ili istih mogućnosti). Vidjeli smo kako H.323 i SIP protokoli podržavaju spektar adresnih formata (od E.164 broja do IP adrese) iz čega se može zaključiti kako su H.323 i SIP standardi čvrsto povezani sa IP omogućenim tehnologijama. Zbog tekstualnog kodiranja, SIP protokol je bolje povezan s HTTP protokolom, ali je zato vrijeme uspostave komunikacije dulje nego u H.323 mreži. Dodatnom standardizacijom (dodatnim poboljšavanjem) pokušavaju se skratiti poruke i to na način da se ne pišu puna imena parametara, već skraćenice. Na ovaj način, poruke se mogu skratiti za 20 % i time se ubrzati uspostava komunikacije. Zbog početne jednostavnosti ovaj protokol je dobro prihvaćen u Internet zajednici. H.323 protokol ima tri godine prednosti, i u skladu s tim su i velika ulaganja u H.323 infrastrukturu. Suživot H.323 i SIP protokola je realnost, uz naglasak na potrebu međudjelovanja uz zadržavanje pune funkcionalnosti. Gledajući IP mreže i VoIP tehnologiju danas, može se zaključiti kako će se u budućnosti koristiti oba protokola. Za pružatelje usluga globalnih VoIP usluga povezanost ovih različitih protokola i mreža u jedinstvenu VoIP mrežu je vrlo visokog prioriteta, stoga standardiziranje SIP-H.323 međumrežnih funkcija unutar SIP Radne Grupe IETF organizacije mora biti nastavljeno.U ovom radu prvenstveno smo se bazirali na SIP protokol prije svega što je taj protokol prihvaćen kao glavni protokol u novo jegenaciji mreža, NGN. SIP je signalizacijski protokol aplikacijske razine razvijen u svrhu kreiranja, promjene i prekida višemedijskih sesija ili poziva izmedu dva ili više sudionika, lociranja korisnika i preusmjeravanja poziva, omogucavanja mobilnosti preusmjeravanjem poziva i upotrebom proxy poslužitelja. Iako ga je razvio i standardizirao IETF, prihvatila su ga i ostala znacajna medunarodna standardizacijska tijela kao glavni protokol u višemedijskim domenama 3G mobilnih sustava, IP Multimedia Subsystem (IMS), te kao okosnicu mreža sljedece generacije (Next Generation

Network, NGN). S migracijom tradicionalnih telekomunikacijskih mreža prema IP višeuslužnim i višemedijskim mrežama, SIP protokol dobiva nezaobilaznu važnost. Sve interesne grupe u telekomunikacijskoj industriji su se usuglasile da je protokol SIP glavno sredstvo realizacije višemedijskih komunikacijskih usluga sljedeće generacije.Prihvacanjem Internet tehnologija za prijenos medija, SIP protokol postaje predvodnik promjena koje ce uvesti nove vidove komuniciranja medu ljudima i mogucnosti realiziranja i korištenja brojnih novih usluga. Vrlo živa standardizacijska aktivnost usmjerena na dogradnju SIP protokola i njegovu primjenu, svjedoči o tome da SIP postaje nezaobilazan protokol u novim, IP temeljenim telekomunikacijskim mrežama.

Popis slika

Slika 1. Međuodnos protokola u H.323 mreži 8

Slika 2. Signalizacijski dijagram registracije na upravnik 9

Slika 3. Signalizacijski dijagram dobivanja IP adrese odredišta 9

Slika 4. Funkcijski prikaz H.323/PSTN gateway-a 11

Slika 5. Prikaz H.323 zone 12

Slika 6. Arhitektura H.323 mreže 13

Slika 7. Dijagram povezivanja u centraliziranoj i decentraliziranoj višestranoj konferenciji 13

Slika 8. Osnovni elementi SIP arhitekture 17

Slika 9. Arhitektura SIP mreže 17

Slika 10. Direktna komunikacija bez proxy poslužitelja 18

Slika 11. Komunikacija sa proxy poslužiteljem 19

Slika 12. Blok dijagram proxy servera koji pamti stanja transakcija 20

Slika 13. Tok poziva sa redirect poslužiteljem 21

Slika 14. REGISTER zahtjev 21

Slika 15. Komunikacija sa lokacijskom bazom podataka 22

Slika 16 Primjer razlučivanja adrese korištenjem servisa lokacije i DNS 24

Slika 17 Primjer uspješno uspostavljene sesije koristeći INVITE 26

Slika 18. Primjer promjene sesije koristeći poziv INVITE 29

Slika 19. Primjer prekida sesije koristeći poruku BYE 30

Slika 20 Primjer otkazivanja sesije koristeći zahtjev CANCEL 31

Slika 21. Primjer signalizacije u toku poziva koristeći INFO 32

Slika 22. Primjer kontrole poziva koristeći REFER 33

Slika 23. Preduslovi za uspostavu poziv korištenjem UPDATE i PRAC 35

Slika 24. Uspostava komunikacije u mreži temeljenoj na SIP protokolu 45

Slika 25. Uspostava komunikacije na mreži temeljenoj na SIP – T protokolu 46

Slika 26. IP-PSTN gateway usluga i SIP-PBX gateway 47

Popis tabela

Tabela.1 SIP Metode 15

Tabela 2 Klase kodova SIP odgovora 15

Table 3 SIP primjer sa detaljnim opisom 16

Tabela 4 Primjer SDP ponude sa opisom pojedinih linija 27

Tabela 5 Primjer SDP odgovora sa opisom pojedinih linija 28

Tabela 6. Interoperabilonst SIP protokola i ITU-T protokola 47

Popis skraćenica

AAA Authentication, Authorization, and AccountingCRM Customer relationship MamagementIP Internet ProtocolIM Instant messagingSIP Session Initiation ProtocolPSTN Public Switched Telephone NetworkTDM Time Division MultiplexVoIP Voice over IPPC Personal ComputerCPL Call Processing LanguageCGI Common Gateway InterfaceENUM E.164 NUmber MappingDNS Domain Name SystemIETF Internet Engineering Task Force,

ITU-TInternational Telecommunications Union - TelecommunicationsStandardization Sector

ETSI European Telecommunications Standards InstitutePINT PSTN and Internet INTerworkingTRIP Telephony Routing over IP protocolISP Internet Service ProviderQoS Quality of ServiceTLS Transport Level SecurityToIP Text over IPNGN New Generation NetworkATM Asynchronus Transfer ModeNGN New Generation NetworksRTP Real Time Protocol

SDP Session DescriptionIN Intelligent NetworkCTI Replacement for Computer Telephony IntegrationP2P Peer to PeerURI Uniform Resource IdentifierDNS Domain Name System3GPP Third-Generation Partnership Program

Literatura

[1] “Wiley & Sons - Internet Communications Using SIP Delivering VoIP and Multimedia Services with Session Initiation Protocol [2006].pdf”

[2] Šefkija Čekić, Osnovi metodologije i tehnologije izrade znanstvenog i stručnog djela, Fakultet za saobraćaj i komunikacije, Sarajevo, 1999. g.

[3] Multiservice Switching Forum, Implementation Agreement for SIP-T Profile for Media Gateway Controller, June 2002,

[4] P. Granstrom, S. Olson and M. Peck, "The future of communication using SIP", Ericsson Review No.1, 2002, (28-35),

[5] H. Schulzrinne and J. Rosenberg, "SIP: Internet-Centic Signalization" IEEE Communication Magazine, October 2001,

[6] J. Glasmann, W. Kellerer and H. Muller, "Service Architectures in H.323 and SIP: A Comparison" IEEE Communications Surveys & Tutorials, Fourth Quarter 2003,

[7] Meddahi and G. Vanwormhoudt, "Optimising SIP Performances with a Profile Based Approach", SoftCom 2003, (74-79),

[8] R. Glitho, "Advanced Service Arhitectures for Internet Telephony: A Critical Overview", IEEE Network Mag. Jul/Aug 2000, (38-44),

[9] B. Pagurek, J. Tang, T. White and R. Glitho, "Management of Advanced Services in H.323 Internet Protocol Telephony", IEEE INFOCOM 2000,

[10] M. Korpi and V. Kumar, "Supplementary Services in H.323 IP Telephony Network", IEEE Communication Magazine, July 1999, 118-125,

[11] R. Lončar, "SIP: session Initiation Protocol", SoftCom 2003, (36-41),

[12] IETF, Internet-draft, RFC 3261, "SIP: Session Initiation Protocol"

[13] IETF, Internet-draft, RFC 2976, "SIP INFO Method"

[14] IETF, Internet-draft, RFC 3311, "SIP UPDATE Method"

[15] IETF, Internet-draft, RFC 3372, "SIP for Telephone"

[16] ITUT-T Rec. H.225, "Call Signaling protocols and media stream packetisation for packet based multimedia communication systems"

[17] ITUT-T Rec. H.245, "Control protocol for multimedia communication"

[18] ITUT-T Rec. Q.1912.5 "Inerworking between SIP and BICC protocol or ISDN User Part

[19] Z. Tripalo, Ž. Solari Štanbuk, "Protokol H.323", Revija No.2, 2005, (3-38)

[20] N. Biondić, M. Vukušić Vasiljevski, L. Medak, V. Bolt, V. Vrlika "Protokol za pokretanje sesije", Revija No.1, 2005, (3-34)

Dipl merimin

Technology

Transcript of Dipl merimin