You are on page 1of 61

IMS SERVISI

7.12.2009

Zahtjevi trita za novim kvalitetom servisa -1/2


Konvergencija servisa

Konvergencija pristupnih mrea

Konvergecija terminalnih ureaja


7.12.2009 2

1. Zahtjevi trita za novim kvalitetom servisa - 2/2


- Trend razvoja mobilnih servisa pokazuje potrebu za sve veim pristupnim brzinama - Korisnici ele koristiti iste servise bez obzira na nain pristupa do servisne mree - Novi multimedijalni servisi mogu da zadovolje korisnike i ujedno omogue vei ARPU (Average Revenue Per User) za operatore - Pitanja: kako zadovoljiti sve zahtjevnije trite, ponuditi veliki broj razliitih servisa u to kraem vremenu, pronai nove potencijale za poveanje ARPU-a, smanjiti trokove implementacije novih servisa i odravanje servisne mree???
7.12.2009 3

IMS koncept i tehnologija


IMS je mrena arhitektura, bazirana na telekomunikacijskim i Internet tehnologijama, podrana standardom od strane 3GPP grupe i ETSI TISPAN grupe IP Multimedijalni podsistem dizajniran je sa prevashodnim ciljevima da:
Olaka razvoj, konfiguraciju i koritenje multimedijalnih servisa Omogui nezavisnost od pristupnih mrea i tehnologija Iskoristi dinamian razvoj Interneta

7.12.2009

Arhitekturu IMS-a ine tehnoloki slojevi: Aplikacijski servisi Sloj servisa Kontrola sesija Sloj kontrole sesija Multimrena povezivost Sloj transporta ili povezivosti.

IMS koncept i tehnologija

7.12.2009

IMS koncept i tehnologija


IMS fukcionalnosti:
Upravljanje multimedijalnim sesijama, Kvalitet servisa (QoS), Upravljanje mobilnou, Kontrola servisa, Standardni interfejsi.

7.12.2009

IMS koncept i tehnologija


-Za operatora
-Redukcija servisnih arhitektura u jedinstveno IP rjeenje -Roaming korisnika na razliitim mrenim arhitekturama -Brzi razvoj i implementacija multiplatformskih servisa -Kombinirane multimedijalne aplikacije -Centralizovana administracija korisnikih profila -Jednostavno odravanje i menadment

-Za korisnika servisa


-Nova pozitivna iskustva u koritenju multikorisnikih i multimedijalnih servisa -Dostupnost donedavno jako skupih ili nezamislivih mogunosti -Personalizacija servisa -Velike mogunosti terminalne opreme
7.12.2009 7

IMS servisi
Svi dosadanji servisi bi trebali biti zadrani prelaskom na IMS, bez obzira na nain funkcionisanja, te bi IMS pored njih trebao da prui jo mnotvo novih servisa i da omogui korisniku kombinovanje razliitih servisa. Vezano za dosadanje servise razmotrimo sljedea dva pojma:
Emulacija (PSTN/ISDN emulacija) Simulacija (PSTN/ISDN simulacija)
7.12.2009 8

IMS Sigurnost
Kao i u drugim mreama i u IMS-u je bitna sigurnost. IMS ima svoje metode za autentikaciju i autorizaciju izmeu korisnika i IMS mree, pored onih metoda koje ve postoje na pristupnoj mrei ( na primjer, GPRS pristupnoj mrei ). IMS zahtijeva da se korisnici autenticiraju prije nego to ponu koristiti servise, dok korisnici, s druge strane mogu zahtijevati privatnost tokom svoje sesije. IMS je zamiljen da bude neovisan od vrste pristupne mree, te je stoga jezgra IMS-a odvojena od pristupne mree. Zbog toga IMS moe raditi sa razliitim pristupnim mreama, kao to su GPRS, WLAN i UMTS.
7.12.2009 9

IMS Naplativost
IMS takoe mora obezbijediti metode naplaivanja i obraunavanja trokova. Pored standardnih metoda preuzetih iz ve postojeih mrea IMS omogua i jo neke metode naplaivanja. IMS mora obezbijediti naplaivanje po vrsti multimedijalnog sadraja koji korisnici razmjenjuju tokom jedne sesije, jer IMS omoguava korisnicima da kombinuju razliite vrste multimedijalnog sadraja tokom jedne sesije.
7.12.2009 10

IMS QoS
Na Internet-u kanjenja mogu biti velika i promjenjiva, paketi mogu stizati bez ikakvog redoslijeda, a neki paketi mogu u potpunosti biti izgubljeni ili odbaeni. Sa IMS-om ovo ne bi smio vie biti sluaj. Sa IMS-om korisnici koji uestvuju u komunikaciji pregovaraju o mogunostima i potrebnom QoSu pri uspostavljanju SIP sesije. Potrebni parametri se dogovaraju na aplikativnom nivou, a putem pristupne mree se udovoljava traenim uslovima
7.12.2009 11

Arhitektura IMS (3GPP)


Aplikacioni nivo AS prisustvo AS komunikacij poruka AS konferencije AS ...

IMS funkcije tarifiranja CSCF MRFC SEG

Kontrolni nivo

HSS

PDF

BGCF

MGCF

SGW

Druge IMS mreze I vanjske IP mreze

Korisnicki nivo

SGSN

GGSN

MRFP

IMS-MGW

Mreze sa komutacijom kanala

7.12.2009

12

APLIKATIVNI NIVO
Aplikativni nivo obezbjeuje infrastrukturu za upravljanje servisima. Na ovom nivou imamo aplikativne servere i funkcije za naplaivanje. Aplikativni server moe biti smjeten u korisnikovoj lokalnoj mrei ili moe biti samostalan. Aplikativni server posjeduje nekoliko osnovnih funkcija: Mogunost procesiranja dolazeih SIP sesija poslanih od strane IMS Sposobnost izdavanja SIP zahtjeva Sposobnost slanja informacija o obraunavanju trokova funkcijama za naplaivanje
7.12.2009 13

Aplikativni serveri
Servisi koje nudi aplikativni server nisu ogranieni samo na servise koji se baziraju na SIP-u. neki baziraju na CAMEL-u ( Customized Applications for Mobile network Enhanced Logic ), a neki na IN (Inteligent Network kod PSTN) Parlay OSA ( Open Service Architecture ).
7.12.2009 14

Kontrolni nivo
Kontrolni nivo se sastoji od nekoliko dijelova Dijelovi koji su zadueni za upravljanje sesijama i njihovim rutiranjem ( CSCF-Call Session Control Function ), Dijelovi za skladitenje podataka o korisnicima i servisima ( HSS-Home Subscriber Server i SLF-Subscription Locator Function ) Dijelovi za podrku ( PDF-Policy Decision Function, PDEPosition Determining Entity, SEG-Security Gateway, THIGTopology Hiding Internetwork Gateway ) Dijelovi za kontrolu povezivanja razliitih sistema ( BGCFBreakout Gateway Control Function, MGCF-Media Gateway Control Function, MGW-Media Gateway i SGW-Signalling Gateway ). Unutar ovog nivoa postoje jo i dijelovi zadueni za posebne servise ( MRFC-Multimedia Resource Function Controller, MRFP-Media Resource Function Processor ).
7.12.2009 15

CSCF ( Call Session Control Function )


CSCF (Call/Session Control Function) predstavlja funkcionalnost kontrole sesija/poziva. CSCF predstavlja osnovni mreni lan (node) IMS sistema putem kojeg se obavljaju svi neophodni SIP signalizacijski procesi CSCF ine tri zasebna lana, sa svojim posebnim funkcionalnim ulogama:
P-CSCF (Proxy-CSCF) predstavlja prvu kontaktnu taku prilikom uspostave sesija izmeu IMS terminala i IMS mree I-CSCF (Interrogating-CSCF) I-CSCF djeluje kao SIP proksi server za administrativne funkcije S-CSCF (Serving-CSCF) S-CSCF ima vanu ulogu u korisnikoj registraciji
7.12.2009

16

BAZE PODATAKA
Postoje dvije baze podataka u IMS arhitekturi:HSS (Home Subscriber Server) i SLF (Subscriber Location Function) HSS je osnovna baza za uvanje podataka o svim pretplatnicima i servisima IMS-a Osnovni podaci koji se uvaju u HSS-u ukljuuju korisniki identitet, informacije o registraciji, pristupne parametre i informacije tekue usluge. SLF predstavlja mehanizam koji omoguuje da ICSCF, S-CSCF i AS pronau adresu HSS-a koji sadri korisnike podatke za autentifikaciju korisnika u sluaju da je angaovano vie adresabilnih HSSova od strane mrenog operatora
7.12.2009 17

MRF, BGCF, PSTN/CS Gateway, PDF


MRF (Media Resource Function) predstavlja izvor medijalnih sadraja u domaoj mrei, a u isto vrijeme djeluje kao transkoder izmeu razliitih aplikacijskih kodeka BGCF (Breakout Gateway Control Function) se koristi za funkcionalnost rutiranja PSTN brojeva u konekcijama sa klasinih CS PSTN mrea u IMS mreu. Ovaj element selektuje odgovarajui PSTN/CS gateway za odgovarajuu CS PSTN domenu PSTN/CS Gateway omoguuje uspostavu konekcija i prijem poziva sa PSTN/ISDN mrea. Moe biti :
SGW (Signaling Gateway) MGCF (Media Gateway Control Function)

PDF (Policy Decision Function) odreuje i kontrolie QoS vrijednosti za svaki pojedini IMS servis. 7.12.2009

18

KORISNIKI PRISTUPNI NIVO Korisniki sloj obezbjeuje pristup korisnike opreme raznim servisima IMS mree preko razliitih pristupnih mrea. Osnovni elementi korisnikog sloja su ( u sluaju da se kao pristupna mrea razmatra GPRS mrea ):
IMS-MGW ( IMS Media Gateway Function ) SGSN ( Serving GPRS Suppost Node ) GGSN ( Gateway GPRS Support Node )
7.12.2009 19

IMS-MGW ( IP Multimedia Subsystem Media Gateway Function)


IMS-MGW predstavlja vezu na korisnikom nivou izmeu mrea sa komutacijom kanala ( PSTN, GSM ) i IMS-a. Omoguava povezivanje na nivou prenosioca informacija, to na prvom mjestu predstavlja saradnju izmeu razliitih mehanizama transporta kao to su TDM i IP. Vri transkodiranje i obradu signala na korisnikom nivou kada je to potrebno. Takoer, IMS-MGW je u mogunosti da korisnicima u mrei sa komutacijom kanala prui ton i obavijesti. MGCF kontrolie IMS-MGW.
7.12.2009 20

SGSN ( Serving GPRS Support Node )


SGSN je odgovoran za kontrolne funkcije i funkcije upravljanja saobraajem u paketski komutiranim mreama. Kontrolna funkcija se sastoji iz dvije funkcije: - Upravljanje mobilnou
- Upravljanje sesijama

Upravljanje mobilnou se odnosi na lokaciju i stanje korisnike opreme, kao i autentikaciju kako korisnike opreme tako i pretplatnika. Upravljanje sesijama se bavi kontrolom pristupa i svim to je vezano za datu konekciju. Upravljanje saobraajem takoe spada u funkcije upravljanja sesijama. SGSN takoe nadzire saobraaj izmeu korisnike opreme i GGSN. 21 7.12.2009

Gateway GPRS Support Node


GGSN je zaduen da korisniku opremu spoji na IMS mreu. GGSN rutira IP pakete koji sadre SIP signalizaciju izmeu korisnike opreme i P-CSCF, i obratno

7.12.2009

22

Komunikacioni protokoli u IMS-u

7.12.2009

23

SIP protokol
SIP protokol je definisan od strane IETF, a prilikom rada na specifikaciji u kojoj je predstavljen IMS, 3GPP je usvojio ovaj protokol kao osnovni protokol za IMS. SIP je protokol aplikativnog nivoa koji se koristi za uspostavljanje, upravljanje i prekidanje multimedijalnih sesija u IP mreama. Multimedijalne sesije se odvijaju na sljedei nain:
Uspostavljanje sesije: korisnikov ureaj alje signal koji obavjetava o potrebi za uspostavljanjem sesije, te se potom identificira lokacija mree u kojoj se korisnik nalazi i dodjeljuje se jedinstveni sesijski identifikator URI ( Uniform Recource Identifier ). Opis sesije: dostavlja opis sesije korisnikom ureaju. Za ovu funkciju se koristi SDP ( Session Description Protocol ). SIP unutar svoje poruke prenosi poruku koju SDP generie. Upravljanje sesijom: kada se sesija prihvati od strane korisnika dolazi do direktne razmjene sadraja izmeu krajnjih taaka. Sadraj sesije koji se prenosi moe biti glasovnog karaktera, video ili podatkovnog karaktera. U ovom dijelu se koriste RTP ( Real Time Protocol ) i RTSP ( Real Time Streaming Protocol ). Prekidanje sesije: bilo koji uesnik moe zahtjevati prekid sesije nakon to se prenos zavri.
7.12.2009 24

SIP poruke
SIP je veoma jednostavan jer je baziran na modelu zahtjev-odgovor. U poruci zahtjeva, poetna linija je linija zahtjeva koja se sastoji od metode tj. poruke, URI-a koji odreuje korisnika ili uslugu kojoj je zahtjev upuen, te verzije SIP protokola. Svaki SIP zahtjev sadri polje, nazvano metoda koje oznaava njegovu svrhu. Postoji est osnovnih SIP metoda koje imaju razliitu namjenu:
INVITE pokree sesiju pozivajui korisnika da uestvuje u njoj ACK potvruje da je klijent primio konaan odgovor na INVITE zahtjev BYE pokree prekid sesije CANCEL ponitava SIP zahtjev za koji jo nije stigao finalni odgovor REGISTER registruje lokaciju korisnika u registracijskom serveru OPTIONS upit o mogunostima servera ( metode, ekstenzije SIP-a, kodeke, itd.)
7.12.2009 25

SIP odgovori
Poetna linija poruke odgovora se sastoji od verzije SIP protokola, numeriki prikazanog koda odgovora i odgovarajue tekstualne fraze. Prva cifra koda statusa definie klasu odgovora, dok preostale dvije cifre nemaju kategorizacijsku ulogu. Kodovi stausa su grupisani u slijedee klase:
1xx Provisional oznaava da je poruka zahtjeva primljena i da se zahtjev procesira. 2xx Success zahtjev je uspjeno primljen i prihvaen 3xx Redirection oznaava da zahtjev treba biti preusmjeren,tj. dodatne akcije su potrebne za kompletiranje zahtjeva 4xx Client Error oznaava da zahtjev ne moe biti prihvaen zbog greke klijenta 5xx Server Error zahtjev ne moe biti prihvaen zbog greke servera 6xx Global Failure nijedan server ne moe ispuniti zahtjev

Npr. znaenja odgovora su: 100 pokuava, 180 zvoni, 183 progres, 200 OK, 302 prebaeno, 500 Serverska interna greka, 606 ne prihvatljivo
7.12.2009 26

Jednostavnost
Njegove poruke su bazirane na tekstu i kao takve su jednostavne za kreiranje, itanje, razumijevanje i debugiranje. SIP je neovisan o prenosnom protokolu, podjednako dobro funkcionie i sa konekciono-orijentisanim protokolima ( TCP, SCTP ), kao i sa nekonekciono-orijentisanim protokolima ( UDP ). Ovaj protokol omoguava rutiranje na zahtjev, a ono moe biti direktno i preko proxy-ja. Mogunost nadogradnje i proirenja ovog protokola je jako velika
7.12.2009 27

Pozicija SIP-a

7.12.2009

28

SIP poruke
Komunikacija pomou SIP protokla, koja se esto se naziva i signalizacija, sastoji se od niza poruka (messages). Uobiajeno je da se svaka poruka prenosi u posebnom UDP datagramu. Svaka se poruka sastoji od "poetne linije", zaglavlja poruke i tijela poruke. Poetna linija oznaava vrstu poruke. Postoje dvije vrste poruka zahtjevi (request) i odgovori (response). Zahtjevi se obino koriste za iniciranje neke akcije ili za obavjetavanje primatelja zahtjeva o neemu. Odgovori se koriste za potvrivanje da je zahtjev primljen i procesuiran te sadre status procesuiranja.
7.12.2009 29

Primjer poruke - INVITE


Startna linija Zaglavlja
INVITE sip: uB@lucent.com SIP/2.0 Via: SIP/2.0/UDP lucent.com: 4545 From: User A <sip: uA@lucent.com> To: User B <sip:uB@site.uottawa.ca> Call-ID: 34567@lucent.com Cseq: 1 INVITE Subject: test SIP message Contact: User B <sip:uB@cs.site.uottawa.ca> Content-Type: application/sdp Content-Length: 187

Tijelo poruke

v=0 o=user1 53655765 2353687637 IN IP4 128.3.4.5


c=IN IP4 224.2.0.1/127 t=0 0 m=audio 3456 RTP/AVP 0

7.12.2009

30

Dijelovi poruke 1/2


Prva linija prikazuje da se radi o INVITE poruci za uspostavu sesije. URI u prvoj liniji naziva se Request-URI i sadri URI sljedeeg koraka poruke (next hop). Iz From i To polja zaglavlja identificiraju se pozivatelj (caller) i pozivani (callee). From polje zaglavlja sadri parametar tag koji slui kao identifikator dijaloga. Call-ID polje zaglavlja je identifikator dijaloga i njegova svrha je identifikacija poruka koje pripadaju istom pozivu. Takve poruke imaju isti Call-ID identifikator.
7.12.2009 31

Dijelovi poruke 2/2


CSeq slui kako bi se zadrao ispravan redoslijed zahtjeva, jer se zahtjevi alju UDP protokolom koji moe promijeniti redoslijed poruka. Contact polje zaglavlja sadri IP adresu i port na kojem pozivatelj eka daljnje zahtjeve koje alje pozivani. Dodatno, tijelo INVITE poruke sadri opis tipa medija koje pozivatelj prihvaa kodiranih u SDPu.
7.12.2009 32

SIP arhitektura SIP komponente


SIP predstavlja kontrolni protokol koji omoguuje pokretanje, modifikaciju i zakljuenje sesija izmeu vie uesnika. Osnovne komponente SIP arhitekture: -Korisniki agent -Proksi serveri -Registrar -Redirekcijski server -SIP poruke i odgovori -SIP transakcije

7.12.2009

33

Direktno rutiranje
Budui da korisniki agent sadri i klijent i server stranu (jer zna poslati zahtjev i dati odgovor), esto kaemo da se korisniki agent ponaa kao UAC (user agent client) ili UAS (user agent server) 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 pozvani odlui poslati BYE i prekinuti sesiju. U tom se sluaju korisniki agent pozvanog (koji alje BYE) ponaa kao UAC, a korisniki agent pozivatelja kao UAS.
7.12.2009 34

Direktno rutiranje

7.12.2009

35

Proxy serveri
Korisniki agenti mogu slati poruke (messages) proxy serveru. Proxy serveri 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. Najvaniji zadatak proxy servera je usmjeravanje poruka za uspostavu sesije prema pozivanom. Zahtjev za uspostavom sesije obino prelazi nekoliko proxy servera dok ne pronae onoga koji zna stvarnu lokaciju pozivanog. Taj e proxy direktno proslijediti zahtjev za sesijom prema pozivanom koji e prihvatiti ili odbiti zahtjev.
7.12.2009 36

Rutiranje preko proxy servera

7.12.2009

37

Pamenje stanja transakcije


Serveri 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. Serveri bez stanja transakcije su jednostavniji i bri od proxy servera sa stanjem transakcije. Mogu se koristiti za jednostavno balansiranje prometa, translaciju i usmjeravanje poruka. Jedan od nedostataka proxy servera bez stanja transakcije je nemogunost apsorbiranja retransmisija poruka i izvoenja naprednijeg usmjeravanja, na primjer, forking (SIP proxy server 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)). 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 servera sa stanjem transakcije je mogunost accountinga.
7.12.2009 38

Redirect server
Entitet koji prima zahtjev i alje odgovor s lokacijom odreenog korisnika zove se redirect server. Redirect server 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.
7.12.2009 39

Redirect rutiranje

7.12.2009

40

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. Namjena je lokacijske baze podataka mapirati sip:tperic@etf.unsa.ba u neto poput sip:tperic@192.168.1.2:5060. Kad proxy primi poziv za sip:tperic@etf.unsa.ba pretrauje lokacijsku bazu podataka. Pronalazi sip:tperic@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 odreuju trajanje valjanosti registracije. Korisnik mora obnoviti registraciju unutar odreenog roka ili e ona istei, a korisnik postati nedostupan.
7.12.2009 41

Registrar
Registracija se vri REGISTER metodom koja sadri AoR (Address of Record) sip:tperic@etf.unsa.ba I kontakt adresu sip:tperic@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.

7.12.2009

42

Komunikacija sa lokacijskom bazom

7.12.2009

43

Transakcije
Iako smo rekli da se SIP poruke alju neovisno, obino ih u transakcije dijele koriniki agenti i odreene vrste proxy servera. Dakle, za SIP se kae da je transakcijski protokol. Transakcija je niz SIP poruka koje se razmjenjuju izmeu elemenata SIP mree, a sastoji se od jednog zahtjeva i svih odgovora na taj zahtjev. To ukljuuje nula ili nekoliko privremenih odgovora, te jedan ili vie zavrnih odgovora. Na INVITE se moe odgovoriti s vie zavrnih odgovora kad proxy server rava zahtjev (forking). Ako je transakciju pokrenuo INVITE zahtjev, tada ona ukljuuje i ACK, ali samo ako zavrni odgovor nije bio 2xx. Ako je zavrni odgovor bio 2xx, tada se ACK ne smatra dijelom transakcije.
7.12.2009 44

Transakcije
Kao to vidimo, radi se o prilino asimetrinom ponaanju - ACK je dio transakcija s negativnim zavrnim odgovorom, ali nije dio transakcija s pozitivnim zavrnim odgovorima. Razlog je takvog razdvajanja vanost isporuke svih 200 OK poruka. Ne samo da one uspostavljaju sesiju, ve ih mogu generirati i viestruki entiteti kada proxy server rava zahtjev, a sve se takve poruke moraju isporuiti korisnikom agentu koji inicira sesiju. U takvom sluaju korisniki agenti preuzimaju odgovornost i retransmitiraju 200 OK odgovore dok ne prime ACK. 45 7.12.2009

SIP transakcija

7.12.2009

46

Dijalozi
Pokazali smo to su transakcije, da jedna transakcije ukljuuje INVITE poruku i njezine odgovore, a druga transakcija ukljuuje BYE poruku i njezine odgovore kada se sesija prekida. No te bi dvije transakcije trebale biti na neki nain povezane - obje spadaju u isti dijalog (dialog). Dijalog predstavlja peer-to-peer SIP odnos izmeu dva korisnika agenta. Dijalog traje neko vrijeme te predstavlja vrlo vaan koncept za korisnike agente. Dijalozi olakavaju pravilni sequencing I usmjeravanje poruka izmeu SIP krajnjih toaka.
7.12.2009 47

Dijalozi
Dijalozi se identificiraju pomou Call-ID, From i To (tagova). Poruke u kojima ta tri identifikatora imaju iste vrijednosti, spadaju u isti dijalog. CSeq u zaglavlju koristi za slaganje poruka po redu, to jest za redoslijed poruka unutar dijaloga. Broj mora rasti po veliini za svaku poruku unutar dijaloga inae e ga peer obraditi kao neispravan zahtjev ili retransmisiju. CSeq broj identificira transakciju unutar dijaloga, jer smo rekli da se zahtjevi i povezani odgovori nazivaju transakcija. To znai da unutar dijaloga moe biti aktivna samo jedna transakcija u svakom pravcu.
7.12.2009 48

Poruke u SIP dijalogu

7.12.2009

49

Dijalog
Neke poruke uspostavljaju dijalog, a druge ne. Na taj se nain jasno moe pokazati odnos poruka i slati poruke koje nisu povezane s ostalim porukama izvan dijaloga. To olakava implementaciju, jer korisniki agenti ne moraju odravati stanje dijaloga. Na primjer, INVITE poruka uspostavlja dijalog, jer e nakon nje uslijediti BYE zahtjev koji prekida sesiju. BYE zahtjev alje se unutar dijaloga koji je uspostavila INVITE poruka. Ali ako klijent poalje MESSAGE zahtjev, on ne uspostavlja dijalog. Sve e naknadne poruke (ak I MESSAGE) biti neovisne o onoj prijanjoj.
7.12.2009 50

SDP (Session Description Protocol)


SDP je protokol koji se koristi za opis najave multimedijalne sesije, poziva na sesiju i druge oblike iniciranja multimedijalne sesije. Multimedijska sesija se definie kao skup medijskih tokova koji e se razmjenjivati u odreenom vremenu. Kako je SDP opisni protokol SDP poruke se mogu transportovati razliitim protokolima, npr. SIP, RTSP, ...
7.12.2009 51

SDP paket
SDP paketi obino ukljuuju slijedee informacije:
- Ime i namjene sesije. - Vremena trajanja sesije.

Poto su resursi potrebni za uee u sesiji ogranieni potrebno je ukljuiti dodatne informacije:
- Informaciju o opsegu koji e se koristiti u toku sesije. - Kontakt na osobu koja je odgovorna za sesiju.

Informacije o mediju:
- Tip medija, naprimjer, video i audio. - Transportni protokol, kao to je RTP/UDP/IP i H.320. - Format medija, kao to je H.261 video i MPEG video. - Multicast adresa i Transportni Port za medij (IP multicast sesija). - Udaljena adresa medija i Transportni port za kontakt adresu (IP unicast sesija).
7.12.2009 52

SDP - Session Description Protocol


Mogui su sljedei parametri:
V Protocol Version (mandatory) o Identifier (mandatory) S Session Name (mandatory) I Session Information (mandatory) U Description URI e E-mail p Telephone Number C Connection Information b Bandwidth Z Correction Time K Key a Attributes T Session Start (Start y stop) (mandatory) R Repetition Time m Transport Protocol Information (media) (mandatory)
7.12.2009 53

SDP poruka primjer 1/2


Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): Cisco-SIPUA 26425 12433 IN IP4 192.168.0.100 Owner Username: Cisco-SIPUA Session ID: 26425 Session Version: 12433 Owner Network Type: IN Owner Address Type: IP4 Owner Address: 192.168.0.100 Session Name (s): SIP Call Connection Information (c): IN IP4 192.168.0.100 Connection Network Type: IN Connection Address Type: IP4 Connection Address: 192.168.0.100

7.12.2009

54

SDP poruka primjer 1/2


Time Description, active time (t): 0 0 Session Start Time: 0 Session Stop Time: 0 Media Description, name and address (m): audio 17338 RTP/AVP 0 8 18 101 Media Type: audio Media Port: 17338 Media Proto: RTP/AVP Media Format: ITU-T G.711 PCMU Media Format: ITU-T G.711 PCMA Format: ITU-T G.729 Media Format: 101 Media Attribute (a): rtpmap:0 PCMU/8000 Media Attribute (a): rtpmap:8 PCMA/8000 Media Attribute (a): rtpmap:18 G729/8000 Media Attribute (a): rtpmap:101 telephone-event/8000 Media Attribute (a): fmtp:101 0-15
7.12.2009 55

SDP I SIP
SIP I SDP ine izuzetnu cjelinu pri transmisiji informacije jedne sesije. SIP predstavlja mehanizam poruka za uspostavljanje multimedijalnih sesija. SDP je strukturirani jezik za opis tih sesija. Zaglavlja identifikuju tijlo poruke. U slijedeem primjeru sa slike pokazan je metod INVITE sa viestrukim medijskim tokovima.

7.12.2009

56

H.248/MEGACO (Media Gateway Control)


H.248/MEGACO je signalni protokol izmeu Media Gatewaya i Media Gateway Controller-a (MGC) i predstavlja rezultat zajednikog rada IETF-a i ITU-a H.248 je ime dato od strane ITU-a, dok je Megaco dato od strane IETF-a Protokol je napisan da podri i tekstualni i binarno kodiranje IETF je specificirao tekstualno kodiranje i to format ABNF (Augmented Backus-Naur Form), to je opisano u dokumentu RFC 2234 Binarno kodiranje je specificirano od strane ITU-T preporukom X.680 i to format ASN.1 (Abstract Syntax Notation One) MGC mora podravati oba standarda, dok MG moe ali ne mora imati podrku za oba standarda
7.12.2009 57

H.248/Megaco arhitektura
Protokol je dizajniran tako da obezbijedi centralizovanu arhitekturu sa centralnim ureajem MGC-om koji upravlja logikom komutacije i funkcijama kontrole poziva Media Gateway vri konverziju formata glasovne/video informacije iz TDM mree u IP mreu i obrnuto H.248 obezbjeuje kreiranje, modifikaciju i brisanje media strima preko Media Gateway, s tim da protokol obezbjeuje i mogunost dogovaranja media formata koji se koristi kod prenosa podataka. Media Gateway Controller/ Call
Agent/ Softswitch
Megaco/ H.248 Megaco/ H.248 Megaco/ H.248 Megaco/ H.248

PSTN/ PLMN media strim

Trunk Media Gateway

Paketizirani media strim (RTP)

Trunk Media Gateway

PSTN/ PLMN media strim

7.12.2009

PSTN/ PLMN media strim

Trunk Media Gateway

Paketizirani media strim (RTP)

Trunk Media Gateway

PSTN/ PLMN media strim

58

RTP
Real-time Transport Protocol (RTP) je protokol koji omoguava real-time prenos podataka s kraja na kraj, kao to su audio, video, tekst preko IP-a RTP sam ne garantuje real-time prenos podataka, ali obezbjeuje mehanizme za slanje i primanje podataka u vidu strima Po definiciji RTP podrava razliite transportne protokole, mada uobiajeno se pokree nad UDP-om Definicija RTP je data u dokumentima IETF RFC 1889, 3550 i 3551
7.12.2009 59

Standardi kodiranja
Tip G.711 G.721 G.726 4,2 G.728 G.723.1 G.729 4,2 3,5 3,98 4,2 MOS 4,8 4,2 Brzina prenosa [kbit/s] 64 32 16 24 32 40 16 5,3 6,3 8 Kanjenje [ms] 0,125 0,125 0,125 2,5 30 10

Mean Option Scoring ili skraeno MOS koja je definisana ITU-T preporukom P.800 je subjektivna metoda odreivanja kvaliteta prenesenog glasa:5-odlian, 4-dobar, 3-korektan, 2-lo, 1-neprijatan
7.12.2009 60

RTCP
RTCP, tj. Real-time Transport Control Protocol ili kako ga jo neki nazivaju RTP Control Protocol ima primarnu funkciju da obezbjedi informaciju kako bi se popravio kvalitet servisa. Ovaj protokol obezbjeuje periodinu razmjenu kontrolnih informacija izmeu uesnika sesije i ove informacije se koriste za detekciju i korekciju problema u distribuciji. RTCP definie pet razliitih tipova RTCP paketa i to:
Report poiljaoca (SR) se koristi od strane aktivnih uesnika sesije za prenos predajne i prijemne statistike; Report primatelja (RR) se koristi za slanje prijemne statistike od strane uesnika koji samo primaju, a ne alju podatke; Opis izvora (SDES) sadri jedan ili vie opisa pojedinih uesnika sesije; BYE se koristi za indikaciju kraja sesije za pojedinanog uesnika; Funkcije specifine aplikaciji (APP) omoguuje slanje RTCP paketa specifine za pojedine aplikacije.
7.12.2009 61

You might also like