Dipl Merimin

Farultet za saobraaj i komunikacije
Diplomski rad
Saetak: Telekomunikacijski operateri nove generacije trebaju nove mree temeljene na IP tehnologiji koje omoguavaju jeftiniji prijenos govora i podataka nego mree temeljene na komutaciji kanala. Tehnologija koja omoguava prijenos govora preko IP mree zove se VoIP tehnologija (Voice over IP). Upotreba VoIP tehnologije osim jeftinijih telefonskih razgovora omoguava lake i bre uvoenje dodatnih usluga. Kako uspostava i raskidanje komunikacije spada u najvanije funkcije u telekomunikacijskoj mrei, signalizacija je, od samog poetka, bila jedno od kljunih podruja za razvitak VoIP tehnologija. Za uspostavu komunikacije preko IP mree 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 mreama. SIP protokol razvila je IETF organizacija s namjerom kreiranja protokola za uspostavu, modifikaciju i raskidanje IP multimedijalnih sesija izmeu jednog ili vie 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 mreama
Signalizacijski protokol za uspostavu komunikacije u IP
Diplomski rad
Sadraj
Saetak abstract
1. Uvod 2. Ciljevi i metodologija izrade diplomskog rada 2.1. ciljevi rada 2.2. Metodologija izrade diplomskog rada 3. H. 323 3.1 Pregled H. 323 protokola 3.2. Arhitektura H.323 mree 4. SIP (Session Initiation Protocol) 4.1. Pregled SIP protokola 4.2. Arhitektura SIP mree 4.2.1. Korisniki agenti 4.2.2. SIP proxy posluitelj (server) 4.2.2.1. Posluitelji bez stanja transakcije (stateless) 4.2.2.2. Posluitelji sa stanjem transakcije (stateful) 4.2.3. Redirect posluitelj 4.2.4. Registar 5. SIP funkcije 5.1. Razluivanje adresa 5.2. Sesijski vezane funkcije 5.2.1. Uspostava sesije 5.2.2. Prenos SIP poruka preko IP-a 5.2.3. Media Negotiation 5.2.4. Modifikacija sesije 5.2.5. Prekid i otkazivanje sesije 5.2.6. Signalizacija u toku poziva 5.2.7. Kontrola poziva 5.2.8. Preduslovi za uspostavu poziva 5.2.9. Ponovno slanje poruka u SIP-u 5.3. Funkcije bez sesije 5.3.1. Pokretljivost (mobilnost) 5.3.2. Prenos poruke 5.3.3. Procesi pretplate i obavijesti 5.3.4. Publikacija prisutnosti 5.3.5. Traenje autentifikacije 6 Osnovni SIP poziv 6.1. Osnovni SIP-T poziv 7. Ostale karakteristike SIP protokola 7.1. Interoperabilnost SIP protokola sa ITU-T protokolima 7.2. Komercijalni SIP produkti 7.3. SIP sigurnost 7.4. ta SIP ne radi 8. Zakljuak Popis slika
Merima Zuki mreama Signalizacijski protokol za uspostavu komunikacije u IP
4 6 6 7 8 8 11 14 14 17 17 18 19 20 20 21 23 23 24 24 25 26 28 29 30 31 33 34 35 35 38 38 40 40 44 45 47 47 48 49 49 51 53 2
Diplomski rad
Popis tabela Popis skraenica Literatura
54 54 56
1.
Uvod
Tradicionalna telekomunikacijska mrea temelji se na komutaciji kanala. Osnovu prometa u takvoj mrei ini prijenos govora. Pojavom raunara pojavila se i potreba za njihovim povezivanjem i razmjenom podataka. Komutacija paketa u takvoj okolini pokazuje se prikladnijim rjeenjem. Stvaraju se podatkovne mree i konano, Internet. Dok je sam Internet temeljen na paketskom prijenosu, pristup Internetu, zbog velike rairenosti mrea s komutacijom kanala, u velikoj mjeri temeljio na postojeim telekomunikacijskim mreama i koritenju modema. Poveanjem prometa raste potreba za digitalnim paketskim mreama. Postojanje odvojenih mrea za prijenos govora i podataka bio je dodatni poticaj razmatranju temeljnih razlika izmeu njih. Jedna od bitnih razlika je i u nainu tarifiranja Internet veze i telefonskih razgovora. Dok u cijeni koritenja Internet veze komponenta udaljenosti nije bitna, u sluaju klasine telefonije, ona ima jako vanu ulogu. Upravo taj ekonomski aspekt je bio kljuan za revoluciju koja se dogaa u telekomunikacijskoj industriji. Telekomunikacijski operateri nove generacije trebaju nove mree temeljene na komutaciji paketa koje omoguavaju jeftiniji prijenos govora i podataka nego mree temeljene na komutaciji kanala (uz zadovoljavajuu kvalitetu usluge). Sa razvojem mrea za prijenos podataka i irokom primjenom IP (Internet Protocol) protokola skrenuta je panja na prijenos govora Internetom i drugim paketskim mreama. Tehnologija koja omoguava prijenos govora preko IP mree zove se VoIP tehnologija (Voice over IP). Upotreba VoIP tehnologije omoguava jeftinije telefonske razgovore. Ona takoer omoguava lake i bre uvoenje usluga. Da bi se pruile upotrebljive usluge, IP telefonija zahtijeva skup kontrolnih ili signalizacijskih protokola za uspostavljanje konekcije, razmjenu informacija o uslugama koje se mogu koristiti izmeu dvije ili vie strana i uspostavljanje konferencija. Kako uspostava i raskidanje komunikacije spada u najvanije funkcije u telekomunikacijskoj mrei, signalizacija je, od samog poetka, bila jedno od kljunih podruja za razvitak VoIP tehnologija. Za uspostavu
Merima Zuki mreama
Diplomski rad
komunikacije preko IP mree 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) mreama. Kasnije je protokol je proiren tako da se korisnici ne moraju nalaziti u istoj LAN mrei. SIP protokol razvila je IETF (Internet Engineering Task Force) organizacija s namjerom kreiranja protokola za uspostavu, modifikaciju i raskidanje IP multimedijalnih sesija izmeu jednog ili vie sudionika. Pojam sesije odnosi se na multimedijalne konferencije, Internet telefoniju, uenje na daljinu i slino. SIP je takoer razvijen radi omoguavanja napredne telefonske usluge preko Interneta. SIP protokol je privukao dosta panje u zadnjih nekoliko godina, to je naglaeno prihvaanjem toga protokola kao signalizacijskoga protokola za pruanje viemedijskih usluga u 3G sistemima i posve izvjesnom migracijom telekomunikacijskih mrea prema IP vieuslunim mreama ili NGN. Iako su u poetku ovi protokoli imali razliite namjene, noviji standardi omoguavaju sline funkcionalnosti (imaju istu namjenu). Jedna od zajednikih namjena im je i uspostava komunikacije preko IP mree. SIP nije zamiljen da bude sveobuhvatan, pa e za komunikaciju meu ureajima biti potrebni i drugi protokoli. Njegova je namjena da omogui komunikaciju koja se nakon toga odvija na razliite naine, pa i pomou nekog drugog protokola. Uz SIP se najee 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 znai da je logika, osim usmjeravanja SIP poruka, spremljena na krajnjim ureajima. Stanje sesije je takoer spremljeno na krajnjim ureajima, ne postoji jedinstvena taka ispada. Mree koje su dizajnirane na taj nain dobro skaliraju. Cijena koju za to moramo platiti je vee zaglavlje. End-to-end koncept SIP protokola bitno je razliit od koncepta uobiajene PSTN (Public Switched Telephone Network) mree kod koje su sva stanja i logika koji se spremaju u mreu i krajnje ureaje (telefone) vrlo primitivni. Cilj je SIP protokola omoguiti istu funkcionalnost koju imaju klasine PSTN mree, ali end-to-end dizajn ini SIP mree sposobnijim za primjenu novih usluga koje se teko mogu implementirati u klasinim PSTN mreama. SIP je baziran na vjerovatno najuspjenijem i najvie koritenom internetskom protokoluHTTP-u. HTTP se moe klasificirati kao signalni protokol jer ga klijenti koriste da bi posluitelju rekli koji ih dokumenti zanimaju. SIP se koristi za prenoenje opisa parametara sesije, opis se kodira u dokument pomou SDP protokola. Oba protokola (HTTP i SIP) naslijedila su kodiranje zaglavlja poruka iz RFC 822. Kodiranje se tokom godina pokazalo sigurnim i fleksibilnim.
Merima Zuki mreama
Diplomski rad
2. Ciljevi i metodologija izrade diplomskog rada

2.1. Ciljevi rada
Znaajna uloga komunikacijske tehnologije uveliko danas odreuje nain ivota i diktira temeljite drutvene promjene. Tehnoloke inovacije na dinaminom, globlnom tritu mijenjaju sliku svijeta u kojem ivimo i radimo. Takav trend moemo pratiti u itavom proteklom stoljeu, periodu kada su telekomunikacijski ureaji postali roda iroke potronje, a telekomunikacijska industrija jedna od najprofitabilnijih djelatnosti. Tradicionalni telekomunikacijski operateri irom svijeta suoeni su sa izazovom opadanja profita generiranog kroz klasine telefonske usluge. Izlaz iz takve situacije veina operatera vidi u novim podatkovnim uslugama. Ipak ako se promatra struktura prihoda telekomunikacijskih operatera, mogue je uoiti kako i dalje veinu prihoda ine usluge prijenosa glasa, a ne podataka. Iako je u konstantnom porastu, promet generiran podatkovnim uslugama nije ni priblino ekvivalentan profitabilnosti glasovnih usluga. Kao to je reeno u samom uvodu, tehnologija koja omoguava prijenos govora preko IP mree je VoIP tehnologija (Voice over IP),
Diplomski rad
ija upotreba omoguava jeftinije telefonske razgovore, a takoer omoguava lake i bre uvoenje usluga. Kako uspostava i raskidanje komunikacije spada u najvanije funkcije u telekomunikacijskoj mrei, signalizacija je, od samog poetka, bila jedno od kljunih podruja za razvitak VoIP tehnologija, te je kljuno mjesto dato razvoju signalnih protokola za uspostavu komunikacije u IP mreama, meu kojima je najvaniji SIP protokol. Cilj ovog rada jeste da prui osnovne informacije o o ovom protokolu, njegove funkcionalnosti i njegov znaaj. U svrhu to uspjenijeg ostvarenja navedenog cilja, rad je podijeljen u devet poglavlja i ima slijedeu strukturu: 1. Uvod 2. Ciljevi i metodologija izrade diplomskog rada 3. H. 323 4. SIP (Session Initiation Protocol) 5. SIP funkcije 6. Osnovni SIP poziv 7. Ostale karakteristike SIP protokola 8. Zakljuak Prva dva poglavlja , Uvod i Ciljevi i metodologija izrade diplomskog rada, daju osnovna razmatranja o tematici obraenoj u okviru ovog rada, pord toga, deginirani su ciljevi i nain, odnosno metodologija koja nam omoguava da se postavljeni ciljevi i realiziraju. U treem poglavljusu data uvodna razmataranja o H. 323 protokolu, koji zajedno sa SIP protokolom predstavlja signalizacijski protokol u telekomunikaciskim sistemima. Budui da se danas sve vie preferira SIP, njemu e i biti vie posveena panja u narednim poglavljima. U etvrtom poglavljuse daju osnovne informacije o SIP protokolu kao i arhitektura SIP mree, te njene komponente. U petom poglavlju definiraju se SIP funkcije, od kojih su posebno izdvojene slijedee: razluivanje adresa, sesijski vezane funkcije, i funkcije bez sesije. U estom poglavlju objanjen ne oosnovni SIP poziv. U sedmom poglavlju definirane su i ukratko pojanjene ostale SIP karakteristike, od kojih su izdvojene: Interoperabilnost SIP protokola sa ITU-T protokolima, Komercijalni SIP produkti, SIP sigurnosti i na kraju ukratko je naglaeno ta zapravo SIP ne radi. Zakljukom se ukratko rezimira materija izloena u okviru diplomskog rada na nain da se iznesu i naglase spoznaje do kojih se dolo prilikom prouavanja ove problematike.
2.2. Metodologija izrade

Metodologija je znanost o cjelokupnosti svih oblika i naina istraivanja pomou kojih se dolazi do sistematskog i objektivnog znanja. Pored toga, metodologija se definira i kao znanstvna disciplina u kojoj se ispituju i eksplicitno izlau razliite ope i posebne znanstvene metode. U svrhu ostvarenja definiranih ciljeva, prilikom obrade, stvaranja spoznaja i donoenja zakljuaka o problematici signalizacijskih protokola za uspostavu komunikacije u IP mreama, bie koritene razliite metode, od kojih emo izdvojiti najvanije: Deskriptivna metoda Komparativna metoda Metoda analize Metoda sinteze
Diplomski rad
Statistika metoda
Deskriptivnu metodu sam koristila prilikom opisivanja pojedinih dijelova SIP arhitekture, te svih funkcija SIP protokola. Komparativnu metodu sam koristila pri poreenju SIP protokola sa ranije doneenim H.323 protokolom, koje su im slinosti i razlike, te osnovne prednosti i nedostaci. Metoda analize predstavljapostupak naunog istraivanja i objenjavanja stvarnosti putem ralanjivanja sloenih tehnikih tvorevina pojmova, sudova i zakljuaka na najjednostavnije dijelove i elemente kao i izuavanjesvakod elementa zasebno i u odnosu na druge elemente. Metoda analize je koritena prilikom izrade svakogod poglavlja, kako bi se dolo do to jednostavnijeg naina da se objasni uticaj SIP protokola u razvoju telekomunikacione tehnologije. Metoda sinteze je postupak znanstvenog istraivanja i objanjavanja stvarnosti putem spajanja, sastavljanja jednostavnih tehnikih konstrukcija u sloenije povezujui odvojene elemente, pojave, prrocese i odnose u jedinstvenu cjelinu. Metoda sinteze je u prvom redu koritena pri evaluaciji spoznaja i izvoenju zakljuaka.
3. H.323
Prije nego budemo detaljnije razmatrali problematiku SIP protokola kao kljunog signalizacijskog protokola za pruanje viemedijskih usluga u 3G sistemima, ovo poglavlje emo posvetiti protokolu H.323, budui 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 mreama. 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.
Merima Zuki mreama
Diplomski rad
Slika 1. Meuodnos protokola u H.323 mrei
3.1. Pregled H.323 protokola

H.323 standard definira prijenos audia, videa i podataka u realnom vremenu preko paketske mree. H.323 se moe primijeniti za razliite namjene: samo audio (IP telefonija); audio i video (video telefonija); audio i podaci; audio, video i podaci. Takoer, se moe primijeniti u multimedijalnim konferencijama. H.323 je protokol ini skup standarda. Njihov meusobni odnos, te odnos s drugim protokolima prikazan je na slici 1. H.225 RAS (Registration, Admission and Status) signalizacija je potrebna kada se u mrei nalazi upravnik, te se koristi izmeu krajnje toke i upravnika i omoguava - registraciju krajnje toke na upravnik (slika 2). Tijekom registracije krajnja toka dobije identifikator koji se koristi u komunikaciji s upravnikom, te upravljanje krajnjom tokom od strane upravnika, - kontrolu pristupa od i ka ureaja koji kontrolira upravnik. Kada je krajnja toka registrirana, ona moe inicirati ili primiti poziv samo nakon prijema odobrenja od upravnika,
Slika 2. Signalizacijski dijagram registracije na upravnik
Merima Zuki mreama
Diplomski rad
- omoguava razmjenu adresnih informacija (address resolution) izmeu dva upravnika. Pri iniciranju procedure za dobijanje odobrenja za poetak komunikacije, alje se i adresa odredita (npr. telefonski broj) upravniku. Upravnik inicira proceduru lociranja prema drugim upravnicima i dobija IP adresu odredita (slika 3)
Slika 3. Signalizacijski dijagram dobivanja IP adrese odredita
H.225.0 signalizacija se koristi za uspostavu i raskidanje komunikacije izmeu 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 mreama. H.245 signalizacija se koristi u itavom nizu H.32x protokola, a dio primjenjiv u H.323 mreama opisan je u aneksu A ovog protokola. Svrha samog protokola je uspostava, promjena i raskid medijskih tokova izmeu krajnjih toaka u H.323 pozivu. Za tu namjenu, protokolom su definirane procedure za oglaavanje podranih oblika razmjene medijskih tokova, otvaranja i zatvaranja medijskih tokova, zahtjeve za odreenim nainom razmjene medijskog toka, poruke za upravljanjem medijskim tokom, ope naredbe i indikacije. U H.245 preporuci se za medijske tokove koristi naziv logiki kanali. H.245 kanal, kanal kojim se prenosi H.245 signalizacija, se naziva nulti logiki kanal, dok su pojedini medijski tokovi, kojima se razmjenjuju govorne, video i podatkovne informacije, logiki kanali pobrojani od 1 pa navie. Snaga H.323 protokola lei u: - centralizirana i distribuirana kontrola, s H.323 sve ili dio funkcija kontrole poziva se mogu pomai na krajnje toke mree (ovisno o potrebi), a operatorima se omoguava kontrola svakog aspekta poziva. - integracija s Internet standardima, H.323 je integriran s postojeim 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 omoguavanja audio, video i podatkovnih konferencija preko paketskih mrea. Daljnji razvoj H.323 standarda je ostao fokusiran ka tom cilju. Neke od usluga koje omoguuje H.323 protokol su: - upravljanje pojasnom irinom, primjerice moe se ograniiti broj istovremenih poziva ili oduzeti dio pojasne irine nekom korisniku i sl., - konferencije bez opreme specijalizirane za tu svrhu, H.323 podrava konferencije s tri ili vie uesnika sa i bez koritenja MCU jedinice, - multicast prijenos, to znai da korisnik moe poslati jedan paket na vie odredita bez ponavljanja slanja, - upotreba razliitog hardvera i softvera, za komunikaciju, korisnici ne moraju imati istu (slinu) opremu, - tradicionalne usluge PSTN mree. U okvirima H.323 standarda je omogueno adresiranje H.323 terminala koritenjem vie adresa istog i/ili razliitog tipa. H.323 standard podrava razliite tipove adresa:
Diplomski rad
dialedDigits (u starijim verzijama E.164). h323-ID, url-ID, transportID, email-ID, partyNumber, mobileUIM. Ovaj pristup zahtijeva posebnu pretvorbu i razluivost adresa, kao i posebne registracijske procedure za koje su u H.323 mrei zadueni H.323 upravnici. Adresiranje koritenjem adresa dialedDigits ili partyNumber tipa je najzastupljenije jer korisnici povijesno koriste telefonske brojeve za identifikaciju. H323-ID tip je slovno-brojani tip adrese i predstavlja korisnika imena ili e-mail adrese. MobileUIM tip adrese je prilagoen identifikaciji mobilnih korisnika i omoguava meudjelovanje s javnim mobilnim mreama druge i tree generacije. Mogue je, u svrhu adresiranja, koristiti i transportnu adresu krajnje toke u obliku transport-ID adrese. Popularnost url-ID adresa kao najopenitijeg tipa adresa (koji ukljuuje H.323 URL i tel URL) i email-ID adresa se, sa irenjem VoIP tehnologije, sve vie poveava. Kada se u H.323 mreama koristi adresiranje pomou telefonskih brojeva, esto se koriste i tzv. prefiks zone i tehnoloki prefiks. Prefiks zone je predbroj jedinstven u okviru administrativne domene i unutar nje jednoznano odreuje zonu. Ovaj prefiks je bitan za usmjeravanje poziva meu 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 moe biti konfiguriran tako da zna kako prefiks 021 pripada zoni Split, odnosno pripadajuem upravniku. U sluaju da neki od terminala iz zone Zagreb poziva terminal u zoni Split, to e uiniti tako da utipka 021, a zatim telefonski broj eljenog korisnika. U okviru H.225.0 RAS procedure upravljanja pristupom, pozivajua krajnja toka e uneeni broj prenijeti upravniku zone Zagreb, koji e prema upravniku zone Split pokrenuti proceduru lociranja krajnje toke.
3.2. Arhitektura H.323 mree

H.323 standard specificira tri tipa komponenata koje se ine H.323 mreu: - pristupnik (gateway) povezuje H.323 mreu s ne-H.323 mreom (primjerice s PSTN mreom, slika 4). Pristupnik odraava karakteristike H.323 mree prema H.323 terminalu i karakteristike mree s komutacijom kanala prema SCN terminalu. Povezivanje se postie translacijom protokola za uspostavu i raskidanje veze, prebacivanjem jednog medijskog formata u drugi i prijenosom informacije izmeu dvije mree. Ako je veza potpuno unutar H.323 mree pristupnik nije potreban. Na H.323 strani pristupnik radi s H.245 upravljakom signalizacijom (signalizacija za razmjenu podranih sposobnosti), H.225 signalizacijom (signalizacija za uspostavu i raskid veze), te s H.225 RAS signalizacijom (signalizacija za registraciju na upravnik).
Merima Zuki mreama
10
Diplomski rad
Slika 4. Funkcijski prikaz H.323/PSTN gateway-a
- upravnik (gatekeepers) iako je opcionalna komponenta, to je mozak H.323 mree, sredinja toka za sve pozive u H.323 mrei koja definira i kontrolira upravljanje glasovnom i video komunikacijom preko IP mree. Upravnik je odgovoran za translaciju adresa (izmeu LAN alijasa i IP adrese), kontrolu i usmjeravanje poziva, upravljanje sustavom i politikom sigurnosti (autorizacija i autentifikacija terminala i pristupnika). Sve usluge u komunikaciji izmeu upravnika i krajnje toke H.323 mree definirane su H.225 RASom. Upravnik osigurava inteligenciju za isporuku novih IP usluga i aplikacija. On dozvoljava mrenim administratorima konfiguraciju, nadgledanje i upravljanje aktivnostima, te registracijom krajnjih toaka (terminali, upravnika ili MCU). Takoer upravlja pridjeljivanjem pojasne irine i tarifiranjem. Samo upravnik moe upravljati H.323 zonama (zona ukljuuje jedan upravnik i sve komponente spojene na njega kao to je prikazano na slici 5),
Slika 5. Prikaz H.323 zone
Jedinica za upravljanje viestranim konferencijama (multipoint control units, MCU) je element koji omoguava konferencije s tri i vie uesnika. Osnovne funkcije ovog elementa je odravanje svih audio, video, podataka i upravljakih tokova izmeu svih uesnika u konferenciji. Glavne komponente H.323 MCU elementa su multipoint controler, MC , i multipoint procesor, MP. MC je logiki element koji povezuje kanale za signalizaciju i nadzor konferencije triju ili vie terminala i pristupnika u topologiju zvijezde. MC koordinira razmjenu moguih naina komunikacije izmeu svih terminala povezanih u konferenciju te na taj nain upravlja odabirom vrste konferencije i
11
Diplomski rad
naina komunikacije. Odabir vrste konferencije moe biti ogranien mogunostima ukljuenih terminala i samog MC elementa. MC moe za razliite terminale odabrati razliite naine komunikacije. Osim kao dio MCU jedinice, MC moe biti implementiran unutar H.323 terminala, pristupnika ili upravnika. U tom sluaju, za viestranu konferenciju nije potreban MCU. Nekoliko MC elemenata moe biti povezano u nizu kako bi omoguili irenje uspostavljene konferencije. Funkcije MP komponente su: konverzija izmeu razliitih kodeka i razliitih 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 mree temeljene na H.323 protokolu prikazan je na slici 6. U H.323 standardu postoje tri razliite vrste konferencijskih poziva, izmeu tri i vie razliitih terminala i pristupnika (slika 7): Centralizirana viestrana 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 takoer dio MCU jedinice, alju medijske tokove koje on prima, obrauje i alje natrag prema terminalima, sudionicima konferencije. Decentralizirana viestrana 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 koristei multicast nain slanja, dok, eventualne, podatkovne tokove alju MP elementu koji ih distribuira. Mjeovita viestrana konferencija (Hybrid Multipoint Conference), kao to samo ime kae, 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 mree
Merima Zuki mreama
12
Diplomski rad
Slika 7. Dijagram povezivanja u centraliziranoj i decentraliziranoj viestranoj 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 viemedijskih sesija u mreama utemeljenim na Internet protokolu izmeu dva ili vie 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 znaajna meunarodna standardizacijska tijela kao glavni protokol u viemedijskim domenama 3G mobilnih sistema (viemedijski podsistem zasnovan na IP protokolu, IMS- IP Multimedia Subsystem), te kao okosnicu mrea slijedee generacije NGN. S migracijom tradicionalnih telekomunikacijskih mrea prema all IP vieuslunim i viemedijskim mreama, protokol SIP dobiva nezaobilaznu vanost. Sve interesne grupe su se usaglasile da je protokol SIP glavno sredstvo realizacije viemedijskih komunikacijskih usluga slijedee generacije. SIP je protokol koji omoguava: Lociranje korisnika mogu se nai na razliitim mjestima u razliito vrijeme Raspoloivost korisnika odreuje da li krajnji korisnik eli ili ne eli da uestvuje u toj sesiji Karakteristike sagovornika odreuje 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 odravanje sesije. Sesije oznaavaju skupinu poiljatelja i primatelja koji komuniciraju te stanje poiljatelja i primatelja za vrijeme komuniciranja. Primjeri sesije su telefonski razgovori putem Interneta, distribucija multimedije, multimedijske konferencije, distribuirane raunalne igre itd. SIP podrava i mapiranje imena i prosljeivanje usluga, to omoguava mobilnost korisnika tako to se korisnika identifikacija ne mijenja u odnosu na lokaciju mree.
13
Diplomski rad
Zajedno sa drugim IETF protokolima ini sastavni dio arhitekture koji u potpunosti omoguava multimediju.
4.1. Pregled SIP protokola

SIP je protokol s kraja na kraj koji se koristi za kreiranje, modificiranje i zavravanje sesije s jednim ili vie sudionika u IP mrei. Jedna od glavnih prednosti SIP protokola je mogunost interakcije s drugim protokolima, te udruivanjem njihovih osobina dobijaju se napredne usluge. Klju brzog prihvaanja 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 takoe 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 kae primarna funkcija SIP-a je pokretanje sesije (uspostava), ali takoe ima i druge bitne upotrebe i funkcije, kao to je obavjetavanje o prisustvu i kratke poruke. SIP se koristi za peer-to-peer komunikacijutj., onu vrstu komunikacije u kojoj su obje strane u pozivu ravnopravne, nema gospodara ni roba. SIP koristi model prenosa klijent-server slino kao HTTP, kao to e biti opisano u sljedeem dijelu. SIP klijent generie SIP zahtjev. SIP server odgovara na zahtjev generiui odgovor. Rastui set SIP tipova zahtjeva (poznati kao metodi) je prikazan u tabeli 1. Prvih est je definisano u RFC 3261, osnovna SIP specifikacija. Ostali su proirenja SIP-a i definisani su u razliitim RFC-ovima ili Internet prijedlozima. Nove metode se stalno predlau kao dodatne funkcionalnosti u protokolu. Tabela.1 SIP Metode Metod INVITE ACK BYE CANCEL REGISTER OPTIONS INFO PRACK UPDATE REFER SUBSCRIBE NOTIFY MESSAGE PUBLISH Opis Uspostava sesije Potvrda krajnjeg odgovora na INVITE Prekid sesije Otkazivanje sesije na ekanju Registracija korisnikih URI Upiti o opcijama i mogunostima Signalizacija prenosa meu-poziva Potvrda privremenog odgovora Obnova informacija o sesiji Prenos korisnika do URI Zahtjev za obavijest o dogaaju Prenos obavijesti o pretplatnikom dogaaju Prenos brzih poruka Dizanje na server stanja o prisutnosti
Odgovori u SIP-u su u obliku brojeva. Mnogi kodovi za odgovore su posueni 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 odgovora Klasa Opis 1xx Privremeni ili informacijski zahtjev raste, ali jo nije kopmpletan 2xx Uspjeh Zahtjev je uspjeno kompletiran
14
Diplomski rad
3xx 4xx 5xx 6xx
Preusmjeravanje Zahtjev bi trebalo pokuati na drugoj lokaciji Klijent greka Zahtjev nije zavren zbog greke, moe se pokuati nakon ispravke Server greka Zahtjev nije zavren zbog greke u prijemniku, moe se pokuati na drugoj lokaciji Globalni neuspjeh Zahtjev nije uspio i ne bi trebao biti ponovljen
Kodovi odgovora su dobar prikaz slinosti SIP i HTTP. Odgovor 404NotFound je zamiljen kao pogrean kod web pretraivaa. SIP zahtjevi i odgovori su pravljeni ili kao metod zahtjeva, ili kao kod odgovora, pa je lista polja (tzv. zaglavlja), koja su slina zaglavljima u e-mail poruci. Zapravo neka (kao to je To, From, Subject, i Date) imaju identina znaenja. Npr. poruke SIP zahtjeva prikazane u tabeli.3, zajedno sa minimalno zahtijevanim setom zaglavlja i opisom pojedinih linija. Table 3 SIP primjer sa detaljnim opisom Linija Opis INVITE sip:userb@there.com SIP/2.0 Prva linija SIP zahtjeva ne sadri zaglavlja, ali poinje sa nazivom metode (INVITE), slijedi prazno polje, zahtjev URI, (u ovom sluaju: sip:userb@there.com, to je destinacijska adresa zahtjeva), prazno mjesto, trenutna verzija SIP (2.0). svaka linija zavrava 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; Via zaglavlje sadri verziju SIP-a (2.0) i branch=z9hG4bK765d 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 prosljeuje 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 kolaiem z9hG4bK To: User B <sip:userb@there.com> Zaglavlje TO sadri prikazano ime (user B) kojeg slijedi URI onog koji je poslao zahtjev zatvoren u zagrade <> (sip:userb@there.com) From: User A Zaglavlje FROM sadri prikazano ime (user <sip:usera@here.com>;tag=34kd92kfs A) kojeg slijedi URI onog koji je prima zahtjev zatvoren u zagrade <> (sip:usera@here.com). Parametar TAG je pseudo sluajni string generisan jedinstveno za svaki dijalog Call-ID: 4r59899D8g10c3413 Zaglavlje CALL-ID sadri jedinstveni identifikator za ovaj poziv (sesiju). Obino je napravljen od lokalnog pseudosluajnog
15
Diplomski rad
Max-Forwards: 70
CSeq: 1 INVITE
Contact: sip:usera@4.3.2.1 Content-Length: 126
stringa. Svaki zahtjev u toku poziva e imati isti CALL-ID Polje zaglavlja MAX-FORWARDS je mjera hopova koji se smanjuje za jedan kod svakog proxy servera koji proslijedi zahtjev. Kada broja doe do 0, vraa se odgovor 483 TOO MANY HOPS CSEQ je broj komandne sekvence koji sadri cijeli broj (1), prazno mjesto, zatim metod zahtjeva (INVITE). Svaki sljedei zahtjev (komanda) u toku poziva e imati vei CSEQ broj. Pozivajua i pozivana strana svaka za sebe odravaju odvojene CSEQ brojae. CONTACT sadri jedan ili vie SIP URI koji daju informaciju o drugoj strani u sesiji za vezu sa korisnikom A 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 mree

Iako je kod najjednostavnije implementacije mogue koristiti samo dva korisnika klijenta koji izravno meusobno alju SIP poruke, tipina SIP mrea sastoji se od vie vrsta SIP elemenata. Osnovni elementi su korisniki agenti (User Agents), proxy, register i redirect posluitelji (Slika 8.). Ukratko emo ih opisati u ovom odlomku. SIP elementi su samo logike jedinice. esto ih je korisno spojiti, na primjer, kako bi se poveala brzina procesuiranja, ali to ovisi o pojedinanoj implementaciji i konfiguraciji.
Merima Zuki mreama
16
Farultet za saobraaj i komunikacije Slika 8. Osnovni elementi SIP arhitekture
Diplomski rad
SIP mrea ima klijent/server arhitekturu koja je prikazana na slici 9.
Slika 9. Arhitektura SIP mree
Glavne komponente SIP mree su: SIP korisniki agenti (UA, User Agent) i SIP serveri. 4.2.1. Korisniki agenti (UA -User Agents) Krajnje take koje koriste SIP za meusobno lociranje i pregovaranje o karakteristikama sesije nazivaju se korisniki agenti (user agents). Obino se, ali ne i nuno, nalaze na korisnikom raunalu u obliku aplikacije. To je trenutno najraireniji oblik, meutim, korisniki agenti mogu biti i mobilni telefoni, PSTN gateway-i, PDA ureaji, automatizirani IVR sustavi itd. Korisnike agente esto nazivamo posluitelj korisnikog agenta (User Agent Server -UAS) i klijent korisnikog agenta (User Agent Client - UAC). UAS i UAC su samo logike jedinice, svaki korisniki agent, ovisno o situaciji, ima ulogu UAC-a ili UAS-a. UAC je dio korisnikog agenta koji ima zadatak slanja zahtjeva (request) i primanja odgovora (response). UAS je takoer dio korisnikog agenta, ali on ima zadatak primanja zahtjeva i slanja odgovora (slika 10.). Budui da korisniki agent sadri i UAC i UAS, esto kaemo da se korisniki agent ponaa kao UAC ili UAS. Na primjer, korisniki agent pozivatelja ponaa se kao UAC kada alje INVITE zahtjeve i prima odgovore na zahtjev. Kao UAS ponaa se kad primi INVITE zahtjev i poalje odgovore. No ta se situacija mijenja kad pozivani odlui poslati BYE i prekinuti sesiju. U tom se sluaju korisniki agent pozivanog (koji alje BYE) ponaa kao UAC a korisniki agent pozivatelja kao UAS.
Merima Zuki mreama
17
Farultet za saobraaj i komunikacije Slika 10. Direktna komunikacija bez proxy posluitelja
Diplomski rad
Unutar jedne sesije UA moe biti i UAC (inicira komunikaciju) i UAS (prima zahtjev za prekid komunikacije). Korisniki 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 odreditu i SIP server za registraciju. 4.2.2. SIP Proxy server SIP omoguava izgradnju infrastrukture s mrenim raunalima koja se zovu proxy posluitelji (proxy server). Korisniki agenti mogu slati poruke (messages) proxy posluitelju. Proxy posluitelji su vrlo vani entiteti u SIP infrastrukturi, usmjeravaju poruke za uspostavu sesije s obzirom na trenutnu lokaciju pozivanog, obavljaju autentikaciju korisnika, accounting i ostale vane funkcije. SIP Proxy server se ponaa 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 obino transparentno prenosi poruke, ali mu doputena i ograniena promjena poruka (zahtjeva i odgovora). Najvaniji zadatak proxy posluitelja je usmjeravanje poruka za uspostavu sesije prema pozivanom. Zahtjev za uspostavom sesije obino prelazi nekoliko proxy posluitelja 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 posluiteljem
Postoje dvije osnovne vrste SIP proxy posluitelja - bez stanja transakcije (stateless) i sa stanjem transakcije (stateful). 4.2.2.1. Posluitelji bez stanja transakcije (stateless)
Merima Zuki mreama
18
Diplomski rad
Posluitelji bez stanja transakcije su obini prosljeditelji poruka. Oni prosljeuju poruke neovisno o ostalim porukama vezanim uz istu transakciju. Iako su poruke obino sloene u transakcije, proxy bez stanja transakcije o njima ne brine. Posluitelji bez stanja transakcije su jednostavniji i bri od proxy posluitelja sa stanjem transakcije. Mogu se koristiti za jednostavno balansiranje prometa, translaciju i usmjeravanje poruka. Jedan od nedostataka proxy posluitelja bez stanja transakcije je nemogunost apsorbiranja retransmisija poruka i izvoenja naprednijeg usmjeravanja, na primjer, forking (SIP proxy posluitelj moe poslati jednu SIP poruku na vie 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 prosljeivanja poruke, stateless Proxy nema nikakvih informacija vezanih za ovu poruku, ak zaboravlja da ju je ikad obraivao. Prosljeivanje zahtjeva bez pamenja stanja transakcije omoguava poveavanje skalabilnosti i performansi, ali se gubi informacija o uspjenosti poziva (nemogue je povezati odgovori i zahtjevi), ponovljeni zahtjevi se obrauju isto kao i prvi put poslane poruke. Najvie upotrebljava u jezgri mree zbog velikog prospojnog kapaciteta.
4.2.2.2. Posluitelji sa stanjem transakcije (stateful) Proxy posluitelji sa stanjem transakcije su sloeniji. Kod primitka zahtjeva, oni stvaraju stanje i odravaju ga dok transakcija ne zavri. Neke transakcije, naroito one koje nastaju INVITE metodom, mogu trajati dosta dugo, sve dok pozivani ne odgovori ili odbije poziv. Budui da moraju odravati stanje za vrijeme trajanja transakcija, njihove su performanse limitirane. Sposobnost povezivanja SIP poruka u transakcije omoguuje proxy posluiteljima sa stanjem obavljanje naprednih funkcija. Oni mogu obavljati forking, to znai da se prilikom primitka poruke dalje alju dvije ili vie poruka.Tako.er mogu apsorbirati retransmisije budui da znaju, preko stanja transakcije, jesu li ve primili istu poruku. Proxy posluitelji sa stanjem transakcije mogu obavljati zahtjevnije metode pronalaenja korisnika. Mogu, na primjer, pokuati doi 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 zavrila transakcija s uredskim telefonom. Jo jedna od prednosti proxy posluitelja sa stanjem transakcije je mogunost accountinga. kada se pamte stanja transakcija (statefull Proxy) Proxy obrauje 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 izmeu klijent i server transakcija i upravljanje stanjima zahtjeva. Takoer skuplja odgovore od razliitih klijent transakcija i odabire odgovore koji e biti proslijeeni dalje pomou server transakcije. Statefull Proxy je svjestan stanja transakcija i povijesti poruka, te zbog toga moe obaviti bolje procesiranje dolaznih poruka (moe identificirati ponovno poslane poruke, inicirati ponovno slanje izgubljenih poruka, otkazati poslani zahtjev). Nedostatak im je vea upotreba memorije ime se ograniava maksimalni broj transakcija, vie vremena za obradu transakcija ime se ograniava broj obraeni transakcija u sekundi i tea implementacija (mnogo logike).
Merima Zuki mreama
19
Diplomski rad
Slika 12. Blok dijagram proxy servera koji pamti stanja transakcija
4.2.3. Redirect posluitelj Entitet koji prima zahtjev i alje odgovor s lokacijom odreenog korisnika zove se redirect posluitelj. Redirect posluitelj prima zahtjev, te pretrauje lokacijsku bazu podataka koju kreira registrar, kako bi pronaao primatelja kojem je zahtjev namijenjen. Zatim kreira popis trenutnih lokacija korisnika i alje ih poiljatelju zahtjeva kao odgovor unutar 3xx grupe. Poiljatelj zahtjeva zatim povlai popis destinacija i direktno njima alje novi zahtjev (Slika 13).
Slika 13. Tok poziva sa redirect posluiteljem
Za razliku od Proxy servera, server za usmjeravanje ka drugom odreditu ne proputa zahtjeve ka drugom serveru/UA, ve ih prima, te alje odgovore klijentima s adresama zahtijevanih servera. Ova osobina omoguava operatoru iroki spektar moguih usluga za krajnjeg korisnika (npr. aplikacija pozivnog centra). 4.2.4. Registrar Registrar je poseban SIP entitet koji prima registracije od korisnika, povlai informacije o njihovoj trenutnoj lokaciji (IP adresa, port i korisniko ime) te sprema informacije u lokacijsku bazu podataka (slika14.). Namjena je lokacijske baze podataka mapirati sip: ime@ericsson.com. u neto poput sip:ime@192.168.1.2:5060. Kad proxy zaprimi poziv za sip: ime@ericsson.com. pretrauje lokacijsku bazu podataka.
20
Diplomski rad
Pronalazi sip:ime@192.168.1.2:5060 i poziv za uspostavu sesije alje tamo. Svaka registracija ima ogranieno vremensko trajanje. Expires polje u zaglavlju ili parametar prestanka valjanosti Contact polja u zaglavlju odre.uju trajanje valjanosti registracije. Korisnik mora obnoviti registraciju unutar odreenog roka ili e ona istei a korisnik postati nedostupan. Registracija se vri REGISTER metodom koja sadri AoR (Address of Record) sip: ime@ericsson.com. i kontakt adresu sip:ime@192.168.1.2: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
Merima Zuki mreama
21
5. SIP funkcije
SIP protokol e biti predstavljen u smislu nekih osnovnih funkcija komunikacijskih mrea: razluivanje adresa, sesijski vezane funkcije (ukljuujui uspostavu sesije, medija pregovore, promjenu sesije, prekid sesije, i otkazivanje), signalizacija meupoziva, kontrola poziva, QoS uspostave poziva, i nesesijski vezane funkcije (kao to je pokretljivost, prenos poruka, fenomen pretplatnika i obavijesti, autentifikacija, i proirljivost). Svaka od ovih stavki e biti objanjena u nastavku.
5.1 Razluivanje adresa

Razluivanje adresa je jedna od najbitnijih funkcija SIP protokola. Proces razluivanja SIP adresa obino poinje sa URI, a zavrava sa korisnikim imenom na IP adresi. Ovo razluivanje od generalnog imena do stvarnog korisnika na hostu je mono u razliitim tipovima mobilnosti i prenosivosti se automatski implementira. Razluivanje adrese moe biti izvedeno od oba korisnika agenta i servera. Proces razluivanja adresa moe ukljuivati sljedee korake: DNS NAPTR pretraivanje da bi se odredio transportni protokol (UDP, TCP, SCTP) kao to je opisano u RFC 3263 DNS SRV pretraivanje da bi se odredilo ime hosta na serveru kao i broj porta kao to je opisano u RFC 3263 DNS A pretraivanje da bi se odredila IP adresa hosta ENUM pretraivanje ako je u pitanju telefonski broj Kada se rutira na server u domeni korisnika, pretraivanje servisa lokacije, kao to je opisano u RFC 3261 Iako je mogue da SIP korisniki agent ima pristup servisu lokacije, ovo pretraivanje je obino izvedeno od strane proxy-ja ili redirekcionog servera na raun korisnikog agenta. Generalno, proces razluivanja adresa ukljuuje vie koraka i vie hopova za SIP poruke. Ovo dozvoljava korisnikim agentima i proxy-jima da obave rutiranje zahtjeva na bazi hop-po-hop metode. Svaki proxy konsultuje DNS ili ruting tabelu, a onda prosljeuje zahtjev sljedeem hopu. Ovaj proces se nastavlja sve dok zahtjev ne bude dostavljen na odredite. Napomenimo da rutiranje odgovora u SIP-u ne ukljuuje razluivanje adresa; svi odgovori se rutiraju nazad preko istih proxy-ja kao i zahtjev. Ovo je omogueno 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 mree se moe primijeniti na rutiranje poziva u malim privatnim IP mreama. SIP korisniki agent A eli poslati generalni SIP zahtjev drugom korisnikom agentu B identificiranom sa SIP URI sip:userb@there.com. SIP telefon A prvo provodi DNS Naming Authority Pointer (NAPTR) a onda Service Record (SRV) upit da bi razluio transportni protokol i da locira proxy server za domen there.com (a to je TCP i sipproxy.there.com koristei 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 pronaao odgovarajuu URI adresu, koja je vraena i koritena kao sip:userb@100.101.102.103 u koraku
9. Zahtjev se onda rutira korisniku B na datoj IP adresi, koji uzvraa proxy serveru SIP odgovorom o uspjehu 200OK u koraku 10. Proxy server prosljeuje odgovor o uspjehu 200OK u koraku 11 nazad do pozivaoca A. Proces razluivanja adrese u SIP-u je dinamianproxy moe koristiti bilo koje zaglavlje prisutno u zahtjevu i mnoge druge faktore pri ruting odlukama, ukljuujui i sljedee: Vrijeme dana Zaglavlje From Razliita polja zaglavlja u zahtjevu za uitavanje dijeljenih ili Automatic Call Distributor (ACD) aplikacija. Obino, ovaj proces razluivanja adrese provodi se samo jednom na poetku sesije. Rezultat inicijalnog razluivanja adrese se sprema i koristi u kasnijim zahtjevima izmeu korisnikih agenata.
Slika 16 Primjer razluivanja adrese koritenjem servisa lokacije i DNS
5.2. Sesijski vezane funkcije

Veina SIP funkcija ukljuuje uspostavu sesije ili se moe pojaviti u toku uspostavljene sesije. Iako neke aplikacije SIP-a ne koriste sesijski vezane funkcije, veina korisnih aplikacija SIP-a ima koristi od ovih monih funkcija. 5.2.1. Uspostava sesije Kao to samo ime protokola kae, uspostava sesije je primarna funkcija SIP-a. Budui da je uljudan protokol, SIP koristi INVITE zahtjev za uspostavu sesije izmeu dva korisnika agenta. INVITE poruka obino sadri oblik poruke koji opisuje tip sesije koju korisniki agent eli da uspostavi.
SIP korisnik zapoinje To, From sa tag parametrom, i Call-ID zaglavlja na poeku sesije. Svaki korisniki agent koji generie odgovor dodaje tagove polje To u zaglavlju. Kombinacija tagova To, From i Call-ID se onda koriste da jednoznano 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 koliinu call state informacija koje korisnik mora imati. U sluaju pada korisnikog agenta ili ponovnog pokretanja, polazne informacije moraju biti nekako vraene da bi se poziv nastavio; inae, poziv e morati biti ponovo uspostavljen od poetka. Ovdje treba napomenuti da u skladu sa arhitekturom Interneta, odravanje poziva moe biti odravano od strane krajnjih taaka SIP-a bez bilo kakvog odravanja poziva na serverima u mrei, ako se tako zahtijeva. SIP proxy serveri mogu odravati prenosnu vezu u toku faze uspostave poziva. Odravanje stanja u krajnjim takama SIP-a ini uspostavu poziva nezavisnom od prenosnih greaka u mrei, jer krajnje take 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 uspjenu uspostavu i INVITE/4xx ili 5xx ili 6xx/ACK za pogreku pri uspostavi poziva. INVITE je jedini nain u SIP-u u kojem u principu three-way handshake ima ukljuen ACK. Svi ostali SIP zahtjevi su u formi REQUEST/200 ili REQUEST/4xx ili 5xx ili 6xx za pogreku. Slika 3 pokazuje uspjenu uspostavu sesije izmeu dva SIP telefona ukljuujui INVITE, dva privremena odgovora (100Trying i 180Ringing), i krajnji odgovor (2000K), koji prima ACK. Nula ili vie privremenih odgovora (1xx) mogu biti prethodno poslani na krajnje odredite. Jednom uspostavljena sesija nastavlja se neprekidno bez dodatnih zahtjeva za razmjenom SIP signalnih poruka. SIP broja sesije moe biti koriten da prekine sesiju koja se ini predugom. Ako jedna strana u sesiji eli da promijeni ili obustavi sesiju bie potrebna nova razmjena SIP signalnih poruka. Ovaj princip three-way handshake dozvoljava forking, a to je paralelna pretraga koju inicira proxy, u kojoj vie uspjenih odgovora moe biti vraeno kao jedan INVITE u pouzdanom smjeru, kao to e biti objanjeno u nastavku. 5.2.2. Prenos SIP poruka preko IP-a SIP poruke mogu biti prenoene preko transportnog sloja IP protokolom, ukljuujui i protokole TCP, UDP, SCTP i TLS. TLS je takoe poznat po imenu svog prethodnika SSL koji koristi TCP prenos. DTLS koristi UDP prenos. SIP ima ugraene mehanizme pouzdanosti tako da moe koristiti metodu najboljeg pokaaja 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 izmeu korisniog agenta i sljedee take next hop (to moe biti direktno drugi korisniki agent ili server). SIP poruke se onda alju tom vezom. Content-length zaglavlje je prvenstveno za prenos ovih poruka i omoguava 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 zavrili sesiju BYE. Treba znati da SIP poruke sa vie hopova mogu koristiti UDP za neke hopove, a TCP za neke druge hopove. Transportni protokol koji je koriten za hop bude snimljen u via polju zaglavlja zajedno sa IP adresom i brojem porta za slanje odgovora. SIP poruke se takoe mogu prenositi koristei i druge protokole kao to je SCTP razvijen od strane IETF SIGTRAN Working Group. SCTP omoguava pouzdanu vezu i dodatne funkcije kao to je multi-homing. Multi-homing omoguava hostu da se konektuje na dva ili vie servera istovremeno. Bude li ijedan od ovih
servera postao nepristupaan, saobraaj se odmah prebacuje na drugi server, smanjujui vrijeme prekida. Izbor protokola je odreen 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. Takoe nema kanjenja u uspostavi veze (kao to je to sluaj sa TCP vezom) prije nego to pone razmjena SIP poruka. TCP se ponekad koristi izmeu proxy servera ili u nekim drugim aplikacijama gdje je korisna stalna SIP konekcija. SCTP se preporuuje za veze izmeu dva proxy servera ili proxy servera i velikih PSTN izlaza gdje su potrebne veze velike propusnosti i malih kanjenja. 5.2.3. Media Negotiation Media negotiation je dio sekvence INVITE/200/ACK koja se koristi za uspostavu SIP sesija izmeu dvije krajnje take. SIP sam po sebi ne osigurava media negotiation, ali omoguava media negotiation izmeu dva korisnika agenta koristei Session Description Protocol (SDP). SDP nije pravi protokol, nego je vie tekstualni opisni jezik, koji je definisan sa RFC 2327. Posjeduje i zahtijevana i polja opcije. Neka od zahtijevanih polja su ukljuena u same SIP poruke ali se ne koriste kao to e biti pokazano ovdje.
Slika 17 Primjer uspjeno uspostavljene sesije koristei INVITE
SDP je u poetku razvijen sa poljem djelovanja u Internet multimedija arhitekturi kao vrsta TV vodia za multikast multimedija sesije preko interneta. Neke od sposobnosti SDP su, a koje ne posjeduje SIP, obavjetenje o izvori sesije, predmet sesije i funkcija rasporeda sa poetnim i krajnjim vremenom sa ponavljanjem (t =... linija). Pregovori su ponuda-odgovor model definisan u RFC 3264 u kojem jedan korisniki agent predlae jedan ili vie tipova medija, a drugi korisniki agent ili prihvata ili odbija svaku medija sesiju u odgovoru. Prema slici 17, obino je ponuda sadrana u poetnom INVITE od strane pozivaoca, a odgovor se prenosi u poruci 200OK. Dakle, pozivaoc moe dozvoliti pozivanoj strani da odabere tip medija za sesiju tako to nee poslati SDP INVITE poruci. U ovom sluaju 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, korisniki agent odreuje tip medija, kodek, IP adresu, i broj porta za svaki medijski niz. Moe biti odreeno i vie od jednog kodeka za svaki tip medija. Kada bude prihvaen ponueni kodek korisniki 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 sadri dvije linije medija: jedna za video i jedna za audio. Svaka linija medija ima dva mogua alternativna kodeka koje podrava korisniki agent. Tabela 4 Primjer SDP ponude sa opisom pojedinih linija Linija Opis v=0 Verzija Trenutni broj verzije SDP (0)-nije koriten od strane SIP-a o=usera 2890844526 2890844526 IN IP4 Izvor Samo verziju (2890844526) koristi client.example.com SIP s=Subject Tema c=IN IP4 128.2.3.1 Veza mrea (IN za INTERNET), tip adrese (IP4 za IP verzija 4) i adresa (128.2.3.1) T=0 0 Vrijeme poetno i krajnje vrijeme SIP ne koristi m=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 ukljuujui kodek (H.263) i brzina uzorkovanja (90000 Hz) a=rtpmap:98 H264/90000 Atribut rtpmap lista atributa RTP/AVP video profil 98 (dinamiki teret) ukljuujui 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 ukljuujui kodek (PCMU PCM zakon) i brzina uzorkovanja (8000 Hz) a=rtpmap:97 iLBC/8000 Atribut rtpmap lista atributa RTP/AVP audio profil 97 (dinamiki teret) ukljuujui 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 selektujui iLBC kodek i vraajui broj porta razliit od nule kao to je prikazano u tabeli 5. Dalji pregovori i promjene na mediju mogu se postii koristei ponovni poziv re-INVITE kada bude sesija uspostavljena, kao to e biti opisano u sljedeem dijelu. Ovaj tip medija pregovora ogranienih sposobnosti je podran SDP-om, dakle u SIP-u. Trenutno se razvija nasljednik SDP-a, eksperimentalno nazvan SDPng kao sljedea generacija (Next Generation). Ovaj novi protokol e imati naprednije medija pregovore i sposobnosti opisa. Mogue je da e podrka SDP ostati na bazi SIP specifikacija, sa nasljednicima SDP e biti kao opcona podrka.
5.2.4. Modifikacija sesije Kada se jednom uspostavi sesija koristei sekvencu INVITE/200/ACK, ona moe biti promijenjena sa drugom sekvencom INVITE/200/ACK, a ponekad i kao ponovni poziv reINVITE. S obzirom da moe biti samo jedan SIP zahtjev na ekanju, ponovni poziv ne moe biti poslan sve dok inicijalni INVITE ne bude zavren sa ACK. Ponovni poziv re-INVITE moe biti izveden od bilo koje strane koristei iste To, From (ukljuujui oznake), i Call-ID kao poziv INVITE. SDP u ponovnom pozivu reINVITE e zamijeniti pretpostavljeni inicijalni INVITESDP, ako je re-INVITE uspjean. Ako re-INVITE ne uspije iz bilo kog razloga ili bude odbaen, 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 linija Linija Opis v=0 Verzija Broj trenutne verzije SDP-a (0) nije koriteno od strane SIP o=userb 2890844342 2890844543 Izvor Nije koriten od strane SIP INIP4client.example.net s=Subjekat c=IN IP4 16.22.3.1 Veza Mrea (IN za internet), tip adrese (IP4 za IP verziju 4), adresa (16.22.3.1) t=0 0 Vrijeme Poetno i krajnje vrijeme Nije koriteno od strane SIP-a m=video 0 RTP/AVP 34 98 Poruka tip poruke (video), broj porta je postavljen na nulu, to e rei 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), poto broj porta nije nula ova sesija je odobrena a=rtpmap:97 iLBC/8000 Atibuti rtpmap lista atributa RTP/AVP audio profil 97, ukljuujui kodek (iLBC) i brzinu uzorkovanja (8000 Hz) U primjeru na slici 18, poziv je uspostavljen izmeu dva korisnika agenta koristei opis poruke sdp1, prenesen u inicijalnom pozivu INVITE i 200 OK odgovoru. Pozivana strana pokuava izmijeniti parametre sesije aljui drugi poziv INVITE sa porukom novog sadraja sdp2. Ovo nije prihvatljivo za drugu stranu i ponovni poziv re-INVITE propada sa odgovorom 405 Not Acceptable u poruci 6. Sesija se nastavlja koristei inicijalne parametre. Pozivana strana pokuava jo jednom i ovoga puta ponovni poziv re-INVITE uspiejva te se onda stara sesija prekida dok je druga koristei sdp2 i sdp1 uspostavljena sa drugaijim vrijednostima u oba smjera. Napomenimo da ponovni pozivi re-INVITE obino ne generiu privremene odgovore (kao to je 180Ringing), s obzirom da dvije strane ve komuniciraju jedna s drugom. Recimo jo i da ponovni poziv re-INVITE moe promijeniti bilo koju karakteristiku poruka, ukljuujui i tip sesije, koriteni kodek, ak i izvorinu IP adresu i broj porta.
Slika 18. Primjer promjene sesije koristei poziv INVITE
5.2.5. Prekid i otkazivanje sesije Prekid i otkazivanje sesije su dvije odvojene operacije u SIP protokolu ali esto mijeane. Prekid sesije se deava kada bilo koji korisniki agent poalje poruku BYE koja se odnosi na postojei poziv (to jest uspjeno uspostavljenu sesiju koristei INVITE/200/ACK razmjenu). Ovo je pokazano na primjeru na slici 19. Prekid sesije se deava kada korisniki agent prekine poziv prije zavretka uspostave sesije i same uspostave poziva. itaoc moe pomisliti na analogiju sa akcijom klika na tipku cancel u pregledniku. U ovom sluaju korisnik koji je poslao poziv INVITE, ali jo nije primio krajnji odgovor (2xx, 3xx, 4xx, 5xx, ili 6xx), alje CANCEL zahtjev. Zahtjev CANCEL moe takoe biti iniciran od proxy da bi otkazao individualne dijelove u proxiju iz vie 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 koristei poruku BYE
Korisniki 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 sluaju korisniki agent treba poslati poruku BYE da bi otkazao poziv. U primjeru na slici, korisniki agent alje INVITE zahtjev, a onda i CANCEL zahtjev. Zahtjev INVITE je proslijeen kroz dva proxy-ja da bi stigao do odredinog korisnikog agenta. Primijetimo da zahtjev CANCEL poslan prvom proxiju rezultira odgovorom 200OK na zahtjev CANCEL, a zahtjev CANCEL se prosljeuje sljedeem proxy-ju. Drugi proxy odmah alje 200OK prvom proxy-ju a zahtjev CANCEL prosljeuje odredinom korisnikom agentu. Na kraju korisniki agent odgovara sa 200OK na CANCEL i 487RequestCancelled odgovorom na poziv INVITE. Odgovor 487 je potvren od strane drugog proxy-ja sa ACK, i onda se prosljeuje 487 do prvog proxy-ja, koji e na kraju biti primljen i od strane korisnikog agenta koji je zapoeo poziv, koji onda zna da je sesija na ekanju uspjeno otkazana. (Neuspjeli krajnji odgovori kao to su 3xx, 4xx, 5xx, ili 6xx se uvijek potvruju na bazi skok po skok metode. Samo 200 OK prima ACK s kraja na kraj). Korisniki agent je onda zavrio dva prenosa: CANCEL/200 i INVITE/487/ACK prenos. Poto je mogue CANCEL poslati istovremeno kad i 200OK odgovor, korisniki 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 moe biti pozvan na autentikaciju kao ostali SIP zahtjevi, kao to e biti objanjeno u nastavku ovog poglavlja. 5.2.6. Signalizacija u toku poziva Signalizacija u toku poziva je razmjena signalnih poruka izmeu dva korisnika agenta koji ne mijenjaju parametre sesije izmeu njih. Ako pojava signalizacije u toku poziva promijeni parametre sesije (tj., SDP), onda e se pokrenuti reINVITE. Inae, SIP INFO metod e se
koristiti za prenos informacija izmeu dva korisnika agenta. Informacija se prenosi u tijelu poruke INFO zahtjeva. Na primjer, informacije u signalizaciji u toku poziva sadane u ISDN USR (Korisnik-korisnik poruka) poruci mogu biti prenesene koristei INFO metod u mrei 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: IAMInitial address message poetna adresna poruka ANMAnswer message poruka odgovor USRUser to user message korisnik korisnik poruka
Slika 20 Primjer otkazivanja sesije koristei 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 moe pokrenuti BYE zahtjev za prekid poziva. Ovaj zahtjev moe biti pokrenut samo od strane korisnikih agenata (krajnjih ureaja) koji uestvuju u pozivu. Dakako, mogunost upravljanja i kontrole poziva izmeu dvije strane od strane nekog treeg mogla bi biti uveliko korisna u razliitim implementacijama servisa. Na primjer, ugraeni SIP URI na web stanici, nakon klika, bi mogao uiniti da desktop SIP telefon napravi poziv prema eljenom URI. Ili kontrola poziva od tree strane moe biti koritena u implementaciji web pozivnog centra ili ACD alat, koji je koristan za opsluivanje poziva za korisnike 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 koristei INFO
Postoje dva naina za implementaciju kontrole tree strane. Prva koristi kontroler koji prima SIP INVITE zahtjeve, odgovara na njih, a onda prosljeuje zahtjev INVITE treoj strani. Onda kontroler ostaje da prati signalizaciju, mijenja SDP s jedne grane na drugu, i transparentno kontrolie poziv. Drugi nain koristi REFER metod da bi uspostavio kontrolu tree strane. U primjeru na slici 22. A i B uspostavljaju sesiju. A se onda obraa B da pokrene sesiju sa C koristei REFER zahtjev. Onda A prekida sesiju sa B, dok B uspostavlja novu sesiju sa C. REFER zahtjev u poruci 6 ima sljedei oblik: REFER sip:userb@there.com SIP/2.0 Via: SIP/2.0/TCP pc.there.com:5060;branch=z9hG4bK765d To: User B <sip:userb@there.com> From: User A <sip:usera@here.com> Call-ID: a5-32-43-12-77@4.3.2.1 CSeq: 2 REFER Refer-To: <sip:UserC@anywhere.com> Referred-By: <sip:usera@here.com> Content-Length: 0
Slika 22. Primjer kontrole poziva koristei REFER
Rezultujua INVITE poruka (poruka 8) e onda imati sljedei oblik: INVITE sip:UserC@anywhere.com SIP/2.0 Via: SIP/2.0/UDP 100.101.102.103:5060 To: <sip:UserC@anywhere.com> From: User B <sip:userb@there.com> Call-ID: 383874109476@there.com CSeq: 67 INVITE Contact: sip:userb@here.com Referred-By: <sip:usera@here.com> Content-Length: ... Refer-To zaglavlje u zahtjevu REFER sadri URI od onog kome se A obraa, dok zaglavlje Referred-By identificira A kao onog koji se obraa, i on se proputa do C u INVITE tako da C zna da se taki B obraa A u pokretanju ove sesije.
5.2.8. Preduslovi za uspostavu poziva SIP ima dodatke koji zahtijevaju preduslove. Kvalitet servisa (QoS) moe biti podran na mrenom sloju (IP sloj 3) i na podatkovnom sloju (sloj 2). QoS u IP mreama je nezavisan od bilo koje specifine aplikacije ili mree, stoga, potrebe ne moraju biti prema specifinostima aplikacija (bile one telefoni, multimedija, finansijske transakcije, ili igrice). SIP je ortogonalan sa QoS. Postavljanje aplikacija kao to su komercijalna telefonija sa QoS zahtijeva podrku priznatih mrenih 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 mreni resursi sa SIP pokretanje sesije koje ukljuuje kompleksne procedure autentikacije, autorizacije i naplate (AAA). Mi emo se zato ograniiti na diskusiju o QoS za SIP samo za jednostavne sluajeve gdje AAA problemi mogu biti zanemareni. SIP omoguava korisnikim agentima da uspostave sesiju koristei 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 takoe 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 pokuaja best-effort izmeu korisnikih agenata, onda koristimo ponovni poziv re-INVITE za uspostavu nove QoS sesije. Kako je SIP razmjena poruka potpuno nezavisna od medija, u potpunosti je mogue uspostaviti sesiju koristei, sesija moe propasti samo zbog nedostatka propusnog opsega na mediju, i u tom sluaju e ovaj pristup propasti. Takoe, postoji elja da se oponaa ponaanje PSTN-a, gdje na pozivanoj strani telefon nee zvoniti ako nepostoji dovoljno resursa (tj, linija (trunk)) da bi se zavrio 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 proirenja SIP-a. Prvi je Early Media, koji dozvoljava SDP-u da povremeno prikazuje poruku 183 Session Progress. Ovo dozvoljava dodatnomo mediju (SDP) rukovanje izmeu korisnikih agenata potrebno za uspostavu QoS prvenstveno da bi bilo odgovoreno na poziv. Drugo proirenje SIP-a je Reliable Provisional Responses pouzdani povremeni odgovor, koji omoguava da se izgubljeni privremeni odgovor kao to je 183 detektuje i ponovo poalje (vidi Ponovno slanje poruka u SIP-u). Prijemnik 183 odgovora je obavijeten sa PRACK porukom (Provisional Response ACKnowledgement potvrda privremenog odgovora). Tree proirenje je koritenje metode COMET (preCOnditions MET metod preduvjeta), koji dozvoljava UAS da oznai QoS preduslove koji mogu biti zahtijevani tako da korisnik moe biti obavijeten, 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:userb@there.com SIP/2.0 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK765d To: <sip:userb@there.com> From: User A <sip:usera@here.com> Call-ID: 5448kewl13981304oierek Max-Forwards: 0 CSeq: 1 INVITE Contact: sip:usera@here.com 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. Poiljaoc SIP zahtjeva koristei nepouzdan transport starta tajmer, oznaen 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), poiljaoc prebacuje tajmer na sljedee due vrijeme oznaeno sa T2 (osnovna vrijednost mu je 4s). Ako je zahtjev izgubljen prijemnik ga nee primiti i nee ni generisati odgovor. Nakon isteka vremena T1, poiljaoc e ponovo poslati zahtjev. Ako je izgubljen odgovor na zahtjev, poiljaoc e ponovo poslati zahtjev. Prijemnik e prepoznati zahtjev kao ponovno poslan i on e ponovno poslati svoj odgovor. Provoenje zahtjeva INVITE je malo drugaije od ostalih tipova zahtjeva, poto treba vie 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 poalje krajnji odgovor. Ako ne primi ACK, onaj koji odgovara ponovo alje krajnji odgovor. Ovo omoguava da se izgubljeni INVITE, krajnji odgovor ili ACK pronau i ponovo poalju. Izuzetak u ovom pravilu ponovnog prenosa su povremeni odgovori. Poto povremeni odgovori ne primaju ACK ne postoji nain ni za jednu stranu da znaju je li ovaj zahtjev izgubljen.
Pouzdani povremeni odgovor kao proirenje za SIP je razvijen da bi omoguio da povremeni odgovori budu potvreni sa PRACK ime se omoguava pouzdanost svim zahtjevima i odgovorima u SIP-u.
Slika 23. Preduslovi za uspostavu poziv koritenjem UPDATE i PRACK
5.3. funkcije bez sesije

Neke SIP funkcije se ne odnose izravno na podeavanje sesije. Ove funkcije se mogu pojaviti izvan sesija zasnovanih na SIP-u. 5.3.1. Pokretljivost ( mobilnost ) Registracijska funkcija SIP-a je vrlo slina registraciji na mobilnim telefonima. U registraciskoj poruci, korisnik alje proxy server URI kojim eli primati pozive. Ova ugradnja koja podraje mobilnost je izuzetno korisna osobina SIP-a i jedna je od glavnih prednosti u odnosu nad ostalim protokolima. Ta podrka mobilnosti je dovela do primjene protokola u mnogim novim aplikacijama i koja je predloena za upotrebu kontrole poziva u treoj generaciji beinih mrea. SIP REGISTER zahtjev se koristi za ostvarivanje ove funkcije. Zahtjev sadri zaglavlja kontakata, koja su URI-ovi registrovani od strane korisnika. Na primjer, uspjena korisnika registracija agenta je prikazana na slici 6.10. Korisnik na poetku registrira svoj uredski SIP telefon slanjem REGISTER poruke Registracijskom serveru. Registrar pohranjuje korisniku poruku u lokaciskom servisu i vraa 200 OK potvrdu registracije.
Kasnije taj dan, kad korisnik napusti svoj ured zbog odlaska kui, gdje ponitava svoju uredsku telefonasku registraciju i registrira svoj SIP na kuni telefon. (Registracija mobilnog telefona tijekom mijenjanja mogla bi biti takoer razmatrana). Imajte na umu da protokol koji vri upload registracije na lokacijski servis ili druge baze podataka nije SIP. Dolazni pozivi prema korisnikom URI e sada biti preusmjereni na njegovu IP adresu SIP-a kunog telefona. Takoer, treba imati na umu da kuni telefon ne treba biti SIP za ovu pred-pozivnu mobilnost. Korisnik takoer moe registrirati PSTN telefon koristei internet pristup, e-mail, ili reprogramirati registraciju za odreeno vrijeme.
Korisniki agent se moe podesiti da se automatski registruje u vrijeme uspostavljanja, za vrijeme koritenja, ili kad god se novi korisnik loguje na odreeni ureaj. Registracija nije ograniena samo jedan URI. Vie URI-a moe biti koritena da prikae listu brojeva moguih alternativnih lokacija u eljenom redu, ili mogu biti koriteni da prikau listu mnogostrukih moguih servisa kao to su SIP,PSTN, i e-mail. Na primjer uzmajui u razmatranje sljedeu REGISTER poruku: SIP client to Registrar REGISTER sip:registrar.here.com SIP/2.0 Via: SIP/2.0/UDP 4.3.2.1:5060;branch=z9hG4bK87ds To: User A <sip:usera@here.com> From: User A <sip:usera@here.com>;tag=34323kl12d Call-ID: a532431277gfhd43gsfg3awrsad
Max-Forwards: 70 CSeq: 16 REGISTER Contact: sip:usera@4.3.2.1;class=personal Contact: tel:+1-314-555-1212 Contact: mailto:usera@here.com Content-Length: 0 Registrar to SIP client SIP/2.0 200 OK Via: SIP/2.0/UDP 4.3.2.1:5060;branch=z9hG4bK87ds To: User A <sip:usera@here.com>;tag=9128394 From: User A <sip:usera@here.com>;tag=34323kl12d Call-ID: a532431277gfhd43gsfg3awrsad CSeq: 16 REGISTER Contact: sip:usera@4.3.2.1;class=personal Contact: tel:+1-314-555-1212 Contact: mailto:usera@here.com Content-Length: 0 200 OK odgovora REGISTER ehima tri Contanct (Kontakta) URI-ja koji su uspjeno registrovani. U ovom sluaju, upit Lokacijskom Servisu (Location Service) za SIP URI sip: usera@here.com e vratiti tri URI Kontakta koji su registrovani. Prvi je SIP URI koji se moe 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 moe takoer sadravati parametar ekstenzije koji nije prikazan ovdje, kao to je Contanct koji su definirani u Caller Postavkama dokumenta , koji dozvoljava korisnikom agentu da indentifikuje informacije o vrsti ureaja indentifikovanog URI-jem. Na primjer, prvi URI je identificiran kao osobni URI, drugi kao govorna pota, trei je za posao, a etvrti je za mobitele. Naravno, a SIP posluitelj e procesuirati listu URI-ja pokuavajui prvo prvi Kontakt (Contact) header URI, a zatim drugi, i tako dalje, uz pretpostavku redoslijednog pretraivanja. Reject-Contact zaglavlje (zaglavlje za odbijanje kontakta) radi na slian nain, ali sa obrnutim rezultatom. Na taj nain, SIP omoguava korisnikim postavkama da budu prenesene porukom koja sadri zahtjev. Na primjer, SIP zahtjev poslan na korisnikov URI moe biti preusmjeren na bilo kojem broju ureaja, ovisno o tome gdje je korisnik trenutno registrovan, i koje su karakteristike i skripte aktivirane u pozvanoj strani SIP mrea. Takoer, ASIP zahtjev (ASIP request) moe biti poslan sadravajui Reject-Contact zaglavlje, ukazivajui da podnositelj zahtjeva ne eli voicemail uslugu, za primjer. Kada je SIP poruka obraena od strane servera (posluitelja), to obino zavisi od posluitelja da li se radi o proxy zahtjevu ili zahtjevu za preusmjerenje, i da li e se prizvati serijski ili paralelno pretraivanje (forking). Meutim, koritenje zaglavlja za podnoenje zahtjeva za raspolaganje (Request-Disposition header) doputa podnosiocu zahtjeva da ima odreene ulaze. Na primjer, zahtjev koji sadri Request-Dispositon: proxy, dosljedno oznaava da podnositelj zahtjeva ima elju da za zahtjev bude koriten proxy umjesto preusmjeravanja, i da ima serijsko pretraivanje za razliku od paralelnog pretraivanja. Postavke Pozivatelja dokumenta (The Caller Preferences document) opisuje sve opcije. Treba Imati na umu da proxy koji ne podrane odreene znaajke moe jednostavno zanemariti zaglavlje. Opis karakteristika pozivatelja (The Caller Preferences draft) ukljuuje pseudokod koji opisuje tono URI i parametar podudaranja, i interakciju q povlatene vrijednosti, ako je prisutna. Treba imati na umu da upotreba povlatenja pozivatelja definiranog proirenja kontakt zaglavlja je korisno u SIP CGI i CPL skriptiranju za stvaranje SIP usluga. Koritenje zahtijeva: prefs zaglavlje omoguuje korisnikom agentu da zahtijeva da se registar podrava 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 odredite sa ili bez uspostavljanja sesije. Na primjer, razmatrajui sljedeu instant poruke (IM) prenesenu koristei SIP: SIP message MESSAGE im:userb@there.com SIP/2.0 Via: SIP/2.0/UDP pc.here.com;branch=z9hG4bK343g To: User B <im:userb@there.com> From: User A <im:usera@here.com>;tag=4541232ds Max-Forwards: 70 Call-ID: a532431277432513 CSeq: 15 MESSAGE Content-Type: text/plain Content-Length: 15 Hi, how are you? Primijetiemo 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 izmeu dva korisnika agenta, zahtjev poruke moe biti poslan u bilo kojem trenutku. SIP podrka prisutnosti i razmjene trenutnih poruka ukljuuje SIP poruke kao u navedenom primjer. Druge metode u SIP za podrku 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 odreeni dogaaj dogodi je podrano u SIP-u od SUBSCRIBE i NOTIFY tipova zahtjeva [26], [27]. Na primjer, znaajka automatskog poziv u telefoniji moe se koristiti kada je pozvana strana zauzeta (off hook), a pozivatelj eli biti obavijeten im je pozivani pretplatnik dostupno [29]. Na slici 6.11, korisnik A alje zahtjev INVITE te primi odgovor od B korisnikog agenta 486 Busy Here (Zauzeto). Korisnik A onda alje SUBSCRIBE zahtjev za korisnika B zahtjevajui 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 sljedei obrazac: SUBSCRIBE sip:userb@there.com SIP/2.0 Via: SIP/2.0/UDP 4.3.2.1;branch=z9hG4bK343d To: User B <sip:userb@there.com> From: User A <sip:usera@here.com>;tag=h34s341 Max-Forwards: 70 Call-ID: a5f2d43127767eh54wfd CSeq: 23 SUBSCRIBE Contact: <sip:usera@client.there.com> Event: dialog Expires: 60 Content-Length: 0 Zahtjev za notifikaciju ima formu: NOTIFY sip:usera@here.com SIP/2.0 Via: SIP/2.0/UDP pc.here.com:5060;branch=z9hG4bK343d To: User A <sip:usera@here.com>;tag=9839421323
From: User B <sip:userb@there.com>;tag=h34s341 Max-Forwards: 70 Call-ID: a5f2d43127767eh54wfd Subscription-State: active;expires=55 CSeq: 5 NOTIFY Event: dialog Content-Length: ... Na zaglavlju procesa se vidi koja notifikacija procesa je koritena. Ako korisniki agent Korisnika B nije spreman da izvri notifikaciju ovog procesa, moe se poslati odgovor 603 Decline. Servisna mrea moe se graditi u izvedbi bez servera koristei SUBSCRIBE i NOTIFY. SIP takoer podrava pristup baziran na serveru pomou PUBLISH metoda.
5.3.4. Publikacija prisutnosti SIP PUBLISH metoda doputa korisnikom agentu da objavi ili uita informacije o prisutnosti na server. Taj server onda moe da distribuira ovu informaciju. Slika 6,12 prikazuje jedan primjer za to. 5.3.5. Traenje Autentifikacije SIP podrava dvije vrste traenja autentifikacije: korisniki agent prema korisnikom agentu, i korisniki agent prema serveru. Trenutno se ne podrava traenje autentifikacije server prema serveru ali to moe biti ostvareno pomou ne-SIP sheme kao to je IPSec. SIP podrava odreen broj autentifikacijskih shema preuzetih od HTTP-a. SIP Digest autentifikacija je danas najvie upotrijebljena schema, koja se oslanja na traenje/odgovor i tajnu izmeu korisnikog agenta koji trai autentifikaciju i proxy-ja ili korisnikog agenta koji zahtjeva autentifikaciju. Od bilo kojeg SIP zahtjeva moe biti zatraena autentifikacija. Tajna se obino sastoji od ifrovanog korisnikog imena i ifre. Tipina razmjena autentifikacijskih SIP poruka izmeu korisnikih agenata ima formu INVITE/401 Authentication Required/ACK u kojoj korisniki agent saznaje da zahtjev trai autentifikaciju. Takoer saznaje prirodu zahtjeva autentifikacije iz 401 odgovora. Poslije toga se alje novi INVITE koji sadri Authorization header. Ako sadri tane preporuke poziv e se nastaviti kao normalan. U suprotnom e biti bie primljen novi 401 odgovor. Proxy server takoer moe traiti autentifikaciju koristei odgovor 407 Proxy Autentification Required. Ali autentificiranje jednog proxy-ja od strane drugog nije podrano u SIP-u. Umjesto toga, jedan proxy moe uspostaviti sigurnu vezu sa drugim proxy-jem koristei 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 sadri proxy-autorizacijsko zaglavlje koje opisuje prirodu problema. Nakon slanja ACK-a prema proxy, korisniki agent tada ponovo alje poziv za autorizaciju sa zaglavljem koje sadri ifrovano
korisniko ime i ifru korisnika. Proxy onda prihvaa podatke, alje 100 Trying odgovor, i prosljeuje zahtjev na odredini korisniki agent. Korisniki agent tada pokree vlastitu autentifikaciju sa 401 Neovlatenim odgovorom. Ovaj odgovor je proslijeen od strane proxy-a natrag na pozivanje korisnikog agenta. SIP korisniki agent onda napokon ini pravu stvar i ponovo alje INVITE zahtjev koji sadri obje proxy-autorizacije sa podacima za proxy i zaglavlje sa autentifikacijom za drugi korisniki agent. Sljedee su detalji (pojedinosti) poruke 11, koje sadre oba kompleta podataka: INVITE sip:userb@there.com SIP/2.0 Via: SIP/2.0/UDP 4.3.2.1 To: User B <sip:userb@there.com> From: User A <sip:usera@here.com> Call-ID: a5-32-43-12-77@4.3.2.1 CSeq: 3 INVITE Proxy-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:userb@there.com, response=1d19580cd833064324a787ecc Contact: sip:usera@here.com Content-Length: ... Na taj nain, SIP podrava oboje mrenu (server) i korisniku (korisniki agent) ovjere (podateke) unutar poziva.
5.3.6. Mogunost proirenja SIP protokol je osmiljen sa mogunou proirenja . Kao posljedica toga, protokol je osmiljen tako da korisniki agenti mogu implementirati nove ekstenzije pomou novih zaglavlja i tijela poruka bez potrebe za sredinjim serverima kao to su proxy za podrku extenzija. Po defaultu, proxy proslijeuje nepromijenjen nepoznat tip zahtjeva i zaglavlja. Koritenje podranih zaglavlja omoguava podnositelju zahtjeva da obavijestiti mreu i drugi korisniki agent od kojeg su ekstenzije i karakteristike podrane, doputajui im opciju aktiviranja karakteristike. Ako je je potrebno da se karakteristika shvati ili aktivira, onda se upotrebljava Require header [30], koji je ukljuen u zahtjev. Korisniki agent koji prima takav zahtjev mora vratiti pogreku ako ne razumije ili ne podrava karakteristiku.Tu je i Proxy-Require zaglavlje koje sadri listu karakteristika (znaajki) koje bilo koji proxy na putu mora podravati. Meutim, primjena ovog zaglavlja je obeshrabljena, jer njegova prekomjerna upotreba e dovesti do gubitka poziva i problema interoperabilnosti.
SIP korisniki agenti takoer trebaju ukazati na metode (naine) i mogunosti koje pruaju podrku koristei Alow (dopusti), Supported (Podrano), Alow-Events (Doputeni procesi), i Accept-Content (Prihvatljivi sadraj) polja zaglavlja.
6. Osnovni SIP poziv

Za uspostavu komunikacije u IP mreama temeljenim na SIP protokolu koristi se: - SIP protokol s kraja na kraj za kreiranje, modificiranje i zavravanje sesija, - SDP (Session Description Protocol) za prijenos informacija (IP adresa, port, atribute sesije, lista podranih medija, lista podranih algoritama za saimanje po mediju, medija atribute i sl.) potrebnih za otvaranje logikih kanala. SDP se prenosi unutar SIP poruka. Jedan primjer uspostave komunikacije u SIP mrei prikazan je na slici 24. Krajnja toka 1 alje zahtjev za uspostavu komunikacije, alje se INVITE zahtjev s SDP ponudom. Najvanije informacije koje se nalaze u SDP ponudi su IP adresa, port, te lista podranih algoritama saimanja izlistanih po prioritetu. Kada krajnja toka 2 primi tu informaciju, logiki kanal ka krajnjoj toki 1 se moe smatrati otvorenim. SDP odgovor na ponudu se moe poslati u bilo kojem prijevremenom odgovoru ili u konanom odgovoru na INVITE zahtjev. SDP odgovor sadri: IP adresu, port, te listu zajednikih algoritama saimanja posloenih po prioritetu. Prvi algoritam se smatra odabranim, a krajnje toke 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 toka 1 indicirala podravanje PRACK (Provisional Responces ACKnowledgement) slanjem parametra 100rel, te ako krajnja toa 2 takoer indicirala podravanje PRACK zahtjeva, krajnja toka 1 e svaki primljeni privremeni odgovor potvrditi slanjem PRACK zahtjeva. Ovo je uvedeno jer se na transportnoj razini najee koristi UDP koji ne osigurava potvrdu prenosa. U sluaju kada PRACK zahtjev nije podran, SDP odgovor se mora ponoviti u konanom pozitivnom odgovoru na INVITE. Nakon prijema SDP odogvora, logiki kanali se mogu smatrati otvorenim. Nakon to je krajnji korisnik upozoren o dolaznom pozivu (zazvoni telefon), krajnja toka 2 alje 180 Alerting privremeni odgovor. Nakon to se krajnji korisnik prihvati poziv alje se 200 OK (INVITE) konani odgovor. Potvrda prijema konanog odgovor se alje u ACK zahtjevu (ovo je jedini zahtjev na koji se ne oekuje odgovor). Kada je komunikacija zavrena alje se BYE zahtjev.
Slika 24. Uspostava komunikacije u mrei temeljenoj na SIP protokolu
6.1. Osnovni SIP-T poziv

U sluaju kada su dvije PSTN mree povezane preko IP mree temeljene na SIP protokolu, dolazi do gubitka dijela informacija iz ISUP poruka, jer nema potpuno definiranog jednoznanog preslikavanja parametara izmeu ISUP i SIP parametara. Zbog toga je definiran SIP-T protokol, kao proirenje SIP protokola na nain da se unutar SIP poruka enkapsuliraju ISUP poruke. Za uspostavu komunikacije u IP mreama 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 logikih kanala. SDP se prenosi unutar SIP poruka Jedan primjer uspostave komunikacije u SIP-T mrei prikazan je na slici 25. Krajnja toka 1 alje zahtjev za uspostavu komunikacije, alje se INVITE zahtjev s SDP ponudom i IAM (Initial Address Message) porukom. Kada krajnja toka 2 primi tu informaciju, logiki kanal ka krajnjoj toki 1 se moe 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 toka 1 indicirala podravanje PRACK (Provisional Responces ACKnowledgement) slanjem parametra 100rel, te ako krajnja toa 2 takoer indicirala podravanje PRACK zahtjeva, krajnja toka 1 e svaki primljeni privremeni odgovor potvrditi slanjem PRACK zahtjeva. U sluaju kada PRACK zahtjev nije podran, SDP odgovor se mora ponoviti u konanom pozitivnom odgovoru na INVITE. Nakon prijema SDP odogvora, logiki kanali se mogu smatrati otvorenim. Nakon to je krajnji korisnik upozoren o dolaznom pozivu (zazvoni telefon), krajnja toka 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) konani odgovor s enkapsuliranom ANM (Answer Message) porukom. Potvrda prijema konanog odgovor se alje u ACK zahtjevu (ovo je jedini zahtjev na koji se ne oekuje odgovor). Kada je komunikacija zavrena alje se BYE zahtjev s enkapsuliranom REL (Release) porukom.
Slika 25. Uspostava komunikacije u mrei temeljenoj na SIP-T protokolu
7.
Ostale karakteristike SIP protokola

7.1. Interoperabilnost SIP-protokola sa ITU-T protokolima
Velike meunarodne 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 panje za interoperabilnost SIP-a sa nizom drugih protokola, kao to su navedeni u tabeli: Tabela 6. Interoperabilonst SIP protokola i ITU-T protokola ENUM E.164 za IP adresu koristei DNS SIP H.323 za interworking (za interakciju) Pristup ISDN i PSTN IN uslugama sa SIP mrea SIP i QSIG (signalizacijski protokol) za interakciju PBX - om SIP-T SIP za telephone, za prijenos telefonskog signala kroz IP
Na slijedeoj slici prikazan je primjer SIP i PSTN interoperabilnosti koje e biti upuene slijedeim SIP-PSTN pristupnim uslugama. Na slici se takoer vidi SIP-PBX gateway.
Slika 26. IP-PSTN gateway usluga i SIP-PBX gateway
7.2.
Komercijalni SIP produkti
Kada je rije o tehnologiji, aparaturi i sistemima vezanih za SIP, onda je vrlo vano rei da se u proteklim godinama neprestano i mnogo radilo na daljnjem unapreenju i razvoju sa nastojanjem uvoenja to vie invoacija na trite. Danas veinom kompletna telekomunikacijska industrija, internet ekspanzija i telekom servisi (ini ili beini) koriste SIP. Lake je nabrojati izuzetke servisa koji ne koriste SIP, nego one koje koriste, a to su npr. Skype i Google Talk. Meutim 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. tehnikog, tehnolokog, trinog itd. Ovdje emo navesti par proizvoda : SIP Firewall-i i PBX Gateway-i SIP server SIP servisi SIP software komponente i alati SIP korisniki agenti za PC / laptop i mobilne telephone itd. Na slijedeoj slici je prikazan vrlo popularan tip SIP telefona sa ekranom
7.3. SIP sigurnost
Prednosti Internet komunikacije sa svijetom mogu naalost istovremeno imati odreene slabosti odnosno bolne take, sve dok se u startu ne ugrade sigurnosne preventivne mjere u SIP. Spam ili irenje odreenih bespotrebnih sadraja mailovima, susreemo takoer u VoIPi 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 ukljuuje 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 uloiti u dizajniranje sigurnosnih mjera? Odgovor na ovo pitanje nalazimo u potpuno novom pristupu sigurnosti koji ne zavisi od sigurnosti na perimetru. Najopasnije je oekivati da se SIP-protokol i komunikacijske sigurnosti mogu integrisati u jedan funkcionirajui sistem, meutim-naalost momentalno postoji veliki broj takvih subjekata koji promoviu ovakav pristup. Druge uobiajene sigurnosne zamke potiu iz pretpostavke da u specifinim zatvorenim IP-mreama postoji dovoljan nivo sigurnosti, ne uzmiajui u obzir irok spektar ranjivosti i osjetljivosti iz internih izvora i odreenih inficiranih aplikacija koje su u uletile mreu na razliite naine. Generalno govorei o sigurnosti, dobar SIP-security se zasniva na kvalitetnom softwareu, sigurnosnim procedurama i praktinoj realizaciji.
7.4. ta SIP ne radi

Prema dosada reenom, moemo zakljuiti da SIP ne ostavlja utisak nekog maginog protokola koji je u stanju da prevazie sve komunikacijske probleme. U kasnijim izlaganjima (poglavlje 6) emo vidjeti da je SIP veoma moan no u drugu ruku jednostavan protokol za uspostavljanje interaktivnih komunikacija / sesija preko interneta. SIP je protokol za iniciranje, modifikaciju i zavravanje interaktivnih sesija. Proces ukljuuje otkrivanje odnosno pronalaenje korisnika, bez obzira gdje je on u datom momentu, tako da mu se moe proslijedit zahtjev. Naravno da treba spomenuti da postoji niz restrikcija odnosno / mogunosti za ije izvrenje SIP nije dizajniran : 1. SIP nije namijenjen zamjeni svih telefonskih mogunosti i servisa sa mree s komutacijom kanala. Razlikujemo mnotvo telefonskih servisa koja imaju svoja
obrazloenja i afirmaciju a proistiu upravo zasnovane na komutaciji kanala.
iz ogranienja koje imaju tehnologije
Prenosiv lokalni telefonski broj na Internetu je jo jedan primjer usluge koja nema smisla, budui da SIP moe podrati prenosivost lokalnog broja, ali takav servis nije potreban budui da Universal Resource Identifier (URI) nema geografskiog znaaja. Zatim, Caller ID predstavlja plaenu uslugu koja je beznaajna 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 predvien za prijenos velikih podataka, nego je dizajniran za transport iskljuivo malih koliina podataka potrebnih za uspostavljanje interaktivnih komunikacija. Manje koliine podataka koje se ne odnose na uspostavu poziva(npr. kratke text poruke za IM) su pogodne za prijenos SIP-om, meutim kada je rije o veim sadrajima, onda kaemo da ovaj tip protokola nije adekvatan za transportovanje. 3. SIP nije rezervacijski ili prioritetizacijski protokol,nego kontrolni protokol aplikacijskog sloja, tako da ne moe osigurati QoS, ali moe da interagira sa drugim protokolima dizajniranim tako da podravaju QoS.
8. Zakljuak
U zadnjih dvadesetak godina dolazi do ubrzanog razvoja svih komunikacijskih tehnologija, a jedna od onih koje se danas najbre razvijaju je svakako i IP telefonija. Postoje procjene da e u iduem desetljeu ovaj nain komunikacije postati prijetnja tradicionalnom telefonu i po kvaliteti usluge, a, to je jo znaajnije, po cijeni i velikom broju dodatnih mogunosti koje omoguava ovakav oblik komunikacije.Zbog znaajnog poveanja brzine pristupa Internetu u zadnjih nekoliko godina stvorena je kritina masa korisnika iji zahtijevi za brom i kvalitetnijom komunacijskom uslugom potiu razvoj ovih tehnologija. Procjenjuje se da e do 2010. najvei dio korisnika Interneta biti povezan najmanje 56k analognim modemima, iako neki optimistiniji predviaju znaajan pad cijene DSL veze i koritenje stalne veze u najveem broju zemalja.injenica je da je uope mogue usmjeravati tradicionalne telefonske pozive preko IP mree takoer dovodi u pitanje opstanak velikog broja kompanija koje se bave iskljuivo meunarodnim pozivima. Trenutno postoje dva prijedloga standarda na ovome podruju prvi je SIP (Session Inititation Protocol) koji zastupa IETF a drugi H.323 koji zastupa ITU. VoIP je postao vrlo uspjena tehnologija za prijenos govora o emu svjedoi brz rast trita raunalnih telefonskih proizvoda. Kako uspostava i raskidanje poziva spada u najvanije funkcije u telekomunikacijskoj infrastrukturi, signalizacija je, od samog poetka, bila jedno od kljunih podruja VoIP tehnologija. No, osim signalizacijskog protokola koji osigurava brzu i pouzdanu uspostavu i raskidanje poziva, i neki drugi aspekti igraju vanu ulogu. Kvaliteta i dostupnost usluge koju prua PSTN mrea predstavlja velik izazov, a usporediva/slina razina se oekuje od svake nove mree pa tako i od VoIP mree. SIP i H.323 protokoli su na poetku njihove standardizacije imala razliite namjene (H.323 protokol je prvobitno zamiljen kao protokol za viestrane viemedijske konferencije preko paketskih mrea, a SIP s namjerom kreiranja protokola za uspostavu, modifikaciju i raskidanje IP multimedijalnih sesija izmeu jednog ili vie sudionika), kasnijim poboljavanjem mogunosti su im se proirile, te su sada ta dva protokola sve slinija (slinih ili istih mogunosti). Vidjeli smo kako H.323 i SIP protokoli podravaju spektar adresnih formata (od E.164 broja do IP adrese) iz ega se moe zakljuiti kako su H.323 i SIP standardi vrsto povezani sa IP omoguenim tehnologijama. Zbog tekstualnog kodiranja, SIP protokol je bolje povezan s HTTP protokolom, ali je zato vrijeme uspostave komunikacije dulje nego u H.323 mrei. Dodatnom standardizacijom (dodatnim poboljavanjem) pokuavaju se skratiti poruke i to na nain da se ne piu puna imena parametara, ve skraenice. Na ovaj nain, poruke se mogu skratiti za 20 % i time se ubrzati uspostava komunikacije. Zbog poetne jednostavnosti ovaj protokol je dobro prihvaen u Internet zajednici. H.323 protokol ima tri godine prednosti, i u skladu s tim su i velika ulaganja u H.323 infrastrukturu. Suivot H.323 i SIP protokola je realnost, uz naglasak na potrebu meudjelovanja uz zadravanje pune funkcionalnosti. Gledajui IP mree i VoIP tehnologiju danas, moe se zakljuiti kako e se u budunosti koristiti oba protokola. Za pruatelje usluga globalnih VoIP usluga povezanost ovih razliitih protokola i mrea u jedinstvenu VoIP mreu je vrlo visokog prioriteta, stoga standardiziranje SIP-H.323 meumrenih 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 prihvaen kao glavni protokol u novo jegenaciji mrea, NGN. SIP je signalizacijski protokol aplikacijske razine razvijen u svrhu kreiranja, promjene i prekida viemedijskih sesija ili poziva izmedu dva ili vie sudionika, lociranja korisnika i preusmjeravanja poziva, omogucavanja mobilnosti preusmjeravanjem poziva i upotrebom proxy posluitelja. Iako ga je razvio i standardizirao IETF, prihvatila su ga i ostala znacajna medunarodna standardizacijska tijela kao glavni protokol u viemedijskim domenama 3G mobilnih sustava, IP Multimedia Subsystem (IMS), te kao okosnicu mrea sljedece generacije (Next Generation
Network, NGN). S migracijom tradicionalnih telekomunikacijskih mrea prema IP vieuslunim i viemedijskim mreama, SIP protokol dobiva nezaobilaznu vanost. Sve interesne grupe u telekomunikacijskoj industriji su se usuglasile da je protokol SIP glavno sredstvo realizacije viemedijskih komunikacijskih usluga sljedee generacije. Prihvacanjem Internet tehnologija za prijenos medija, SIP protokol postaje predvodnik promjena koje ce uvesti nove vidove komuniciranja medu ljudima i mogucnosti realiziranja i koritenja brojnih novih usluga. Vrlo iva standardizacijska aktivnost usmjerena na dogradnju SIP protokola i njegovu primjenu, svjedoi o tome da SIP postaje nezaobilazan protokol u novim, IP temeljenim telekomunikacijskim mreama.
Popis slika
Slika 1. Meuodnos protokola u H.323 mrei Slika 2. Signalizacijski dijagram registracije na upravnik Slika 3. Signalizacijski dijagram dobivanja IP adrese odredita Slika 4. Funkcijski prikaz H.323/PSTN gateway-a Slika 5. Prikaz H.323 zone Slika 6. Arhitektura H.323 mree Slika 7. Dijagram povezivanja u centraliziranoj i decentraliziranoj viestranoj konferenciji Slika 8. Osnovni elementi SIP arhitekture Slika 9. Arhitektura SIP mree Slika 10. Direktna komunikacija bez proxy posluitelja Slika 11. Komunikacija sa proxy posluiteljem Slika 12. Blok dijagram proxy servera koji pamti stanja transakcija Slika 13. Tok poziva sa redirect posluiteljem Slika 14. REGISTER zahtjev Slika 15. Komunikacija sa lokacijskom bazom podataka Slika 16 Primjer razluivanja adrese koritenjem servisa lokacije i DNS Slika 17 Primjer uspjeno uspostavljene sesije koristei INVITE Slika 18. Primjer promjene sesije koristei poziv INVITE Slika 19. Primjer prekida sesije koristei poruku BYE Slika 20 Primjer otkazivanja sesije koristei zahtjev CANCEL Slika 21. Primjer signalizacije u toku poziva koristei INFO Slika 22. Primjer kontrole poziva koristei REFER Slika 23. Preduslovi za uspostavu poziv koritenjem UPDATE i PRAC Slika 24. Uspostava komunikacije u mrei temeljenoj na SIP protokolu Slika 25. Uspostava komunikacije na mrei temeljenoj na SIP T protokolu Slika 26. IP-PSTN gateway usluga i SIP-PBX gateway 8 9 9 11 12 13 13 17 17 18 19 20 21 21 22 24 26 29 30 31 32 33 35 45 46 47
Popis tabela
Tabela.1 SIP Metode Tabela 2 Klase kodova SIP odgovora Table 3 SIP primjer sa detaljnim opisom Tabela 4 Primjer SDP ponude sa opisom pojedinih linija Tabela 5 Primjer SDP odgovora sa opisom pojedinih linija Tabela 6. Interoperabilonst SIP protokola i ITU-T protokola 15 15 16 27 28 47
Popis skraenica
AAA CRM IP IM SIP PSTN TDM VoIP PC CPL CGI ENUM DNS IETF ITU-T ETSI PINT TRIP ISP QoS TLS ToIP NGN ATM NGN RTP
Authentication, Authorization, and Accounting Customer relationship Mamagement Internet Protocol Instant messaging Session Initiation Protocol Public Switched Telephone Network Time Division Multiplex Voice over IP Personal Computer Call Processing Language Common Gateway Interface E.164 NUmber Mapping Domain Name System Internet Engineering Task Force, International Telecommunications Union - Telecommunications Standardization Sector European Telecommunications Standards Institute PSTN and Internet INTerworking Telephony Routing over IP protocol Internet Service Provider Quality of Service Transport Level Security Text over IP New Generation Network Asynchronus Transfer Mode New Generation Networks Real Time Protocol
SDP IN CTI P2P URI DNS 3GPP
Session Description Intelligent Network Replacement for Computer Telephony Integration Peer to Peer Uniform Resource Identifier Domain Name System Third-Generation Partnership Program
Literatura
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] Wiley & Sons - Internet Communications Using SIP Delivering VoIP and Multimedia Services with Session Initiation Protocol [2006].pdf efkija eki, Osnovi metodologije i tehnologije izrade znanstvenog i strunog djela, Fakultet za saobraaj i komunikacije, Sarajevo, 1999. g. Multiservice Switching Forum, Implementation Agreement for SIP-T Profile for Media Gateway Controller, June 2002, P. Granstrom, S. Olson and M. Peck, "The future of communication using SIP", Ericsson Review No.1, 2002, (28-35), H. Schulzrinne and J. Rosenberg, "SIP: Internet-Centic Signalization" IEEE Communication Magazine, October 2001, J. Glasmann, W. Kellerer and H. Muller, "Service Architectures in H.323 and SIP: A Comparison" IEEE Communications Surveys & Tutorials, Fourth Quarter 2003, Meddahi and G. Vanwormhoudt, "Optimising SIP Performances with a Profile Based Approach", SoftCom 2003, (74-79), R. Glitho, "Advanced Service Arhitectures for Internet Telephony: A Critical Overview", IEEE Network Mag. Jul/Aug 2000, (38-44), B. Pagurek, J. Tang, T. White and R. Glitho, "Management of Advanced Services in H.323 Internet Protocol Telephony", IEEE INFOCOM 2000, M. Korpi and V. Kumar, "Supplementary Services in H.323 IP Telephony Network", IEEE Communication Magazine, July 1999, 118-125, R. Lonar, "SIP: session Initiation Protocol", SoftCom 2003, (36-41), IETF, Internet-draft, RFC 3261, "SIP: Session Initiation Protocol" IETF, Internet-draft, RFC 2976, "SIP INFO Method" IETF, Internet-draft, RFC 3311, "SIP UPDATE Method" IETF, Internet-draft, RFC 3372, "SIP for Telephone" ITUT-T Rec. H.225, "Call Signaling protocols and media stream packetisation for packet based multimedia communication systems" ITUT-T Rec. H.245, "Control protocol for multimedia communication" ITUT-T Rec. Q.1912.5 "Inerworking between SIP and BICC protocol or ISDN User Part Z. Tripalo, . Solari tanbuk, "Protokol H.323", Revija No.2, 2005, (3-38) N. Biondi, M. Vukui Vasiljevski, L. Medak, V. Bolt, V. Vrlika "Protokol za pokretanje sesije", Revija No.1, 2005, (3-34)

Dipl Merimin

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Dipl Merimin

Uploaded by

Copyright:

Available Formats

Farultet za saobraaj i komunikacije

Merima Zuki mreama

Signalizacijski protokol za uspostavu komunikacije u IP

Farultet za saobraaj i komunikacije

Farultet za saobraaj i komunikacije

Popis tabela Popis skraenica Literatura

Merima Zuki mreama

Signalizacijski protokol za uspostavu komunikacije u IP

Farultet za saobraaj i komunikacije

Merima Zuki mreama

Signalizacijski protokol za uspostavu komunikacije u IP

Farultet za saobraaj i komunikacije

2. Ciljevi i metodologija izrade diplomskog rada

Farultet za saobraaj i komunikacije

2.2. Metodologija izrade

Farultet za saobraaj i komunikacije

Merima Zuki mreama

Signalizacijski protokol za uspostavu komunikacije u IP

Farultet za saobraaj i komunikacije

Slika 1. Meuodnos protokola u H.323 mrei

3.1. Pregled H.323 protokola

Slika 2. Signalizacijski dijagram registracije na upravnik

Merima Zuki mreama

Signalizacijski protokol za uspostavu komunikacije u IP

Farultet za saobraaj i komunikacije

Slika 3. Signalizacijski dijagram dobivanja IP adrese odredita

Farultet za saobraaj i komunikacije

3.2. Arhitektura H.323 mree

Merima Zuki mreama

Signalizacijski protokol za uspostavu komunikacije u IP

Farultet za saobraaj i komunikacije

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

Slika 5. Prikaz H.323 zone

Farultet za saobraaj i komunikacije

Slika 6. Arhitektura H.323 mree

Merima Zuki mreama

Signalizacijski protokol za uspostavu komunikacije u IP

Farultet za saobraaj i komunikacije

Slika 7. Dijagram povezivanja u centraliziranoj i decentraliziranoj viestranoj konferenciji

4. SIP (Session Initiation Protocol)

Farultet za saobraaj i komunikacije

4.1. Pregled SIP protokola

Farultet za saobraaj i komunikacije

3xx 4xx 5xx 6xx

Farultet za saobraaj i komunikacije

Contact: sip:usera@4.3.2.1 Content-Length: 126

4.2. Arhitektura SIP mree

Merima Zuki mreama

Signalizacijski protokol za uspostavu komunikacije u IP

Farultet za saobraaj i komunikacije Slika 8. Osnovni elementi SIP arhitekture

SIP mrea ima klijent/server arhitekturu koja je prikazana na slici 9.

Slika 9. Arhitektura SIP mree

Merima Zuki mreama

Signalizacijski protokol za uspostavu komunikacije u IP

Slika 11. Komunikacija sa proxy posluiteljem

Merima Zuki mreama

Signalizacijski protokol za uspostavu komunikacije u IP

Farultet za saobraaj i komunikacije

Merima Zuki mreama

Signalizacijski protokol za uspostavu komunikacije u IP

Farultet za saobraaj i komunikacije

Slika 13. Tok poziva sa redirect posluiteljem

Farultet za saobraaj i komunikacije