P. 1
11 IMS Servisi

11 IMS Servisi

|Views: 205|Likes:
Published by dzemo_m

More info:

Published by: dzemo_m on Dec 04, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

03/17/2012

pdf

text

original

IMS SERVISI

7.12.2009

1

Zahtjevi tržišta za novim kvalitetom servisa -1/2
Konvergencija servisa

Konvergencija pristupnih mreža

Konvergecija terminalnih uređaja
7.12.2009 2

1. Zahtjevi tržišta za novim kvalitetom servisa - 2/2
- Trend razvoja mobilnih servisa pokazuje potrebu za sve većim pristupnim brzinama - Korisnici žele koristiti iste servise bez obzira na način pristupa do servisne mreže - Novi multimedijalni servisi mogu da zadovolje korisnike i ujedno omoguće veći ARPU (Average Revenue Per User) za operatore - Pitanja: kako zadovoljiti sve zahtjevnije tržište, ponuditi veliki broj različitih servisa u što kraćem vremenu, pronaći nove potencijale za povećanje ARPU-a, smanjiti troškove implementacije novih servisa i održavanje servisne mreže???
7.12.2009 3

IMS koncept i tehnologija
IMS je mrežna arhitektura, bazirana na telekomunikacijskim i Internet tehnologijama, podržana standardom od strane 3GPP grupe i ETSI TISPAN grupe IP Multimedijalni podsistem dizajniran je sa prevashodnim ciljevima da:
Olakša razvoj, konfiguraciju i korištenje multimedijalnih servisa Omogući nezavisnost od pristupnih mreža i tehnologija Iskoristi dinamičan razvoj Interneta

7.12.2009

4

Arhitekturu IMS-a čine tehnološki slojevi: Aplikacijski servisi – Sloj servisa Kontrola sesija – Sloj kontrole sesija Multimrežna povezivost – Sloj transporta ili povezivosti.

IMS koncept i tehnologija

7.12.2009

5

IMS koncept i tehnologija
IMS fukcionalnosti:
Upravljanje multimedijalnim sesijama, Kvalitet servisa (QoS), Upravljanje mobilnošću, Kontrola servisa, Standardni interfejsi.

7.12.2009

6

IMS koncept i tehnologija
-Za operatora
-Redukcija servisnih arhitektura u jedinstveno IP rješenje -Roaming korisnika na različitim mrežnim arhitekturama -Brzi razvoj i implementacija multiplatformskih servisa -Kombinirane multimedijalne aplikacije -Centralizovana administracija korisničkih profila -Jednostavno održavanje i menadžment

-Za korisnika servisa
-Nova pozitivna iskustva u korištenju multikorisničkih i multimedijalnih servisa -Dostupnost donedavno jako skupih ili nezamislivih mogućnosti -Personalizacija servisa -Velike mogućnosti terminalne opreme
7.12.2009 7

IMS servisi
Svi dosadašnji servisi bi trebali biti zadržani prelaskom na IMS, bez obzira na način funkcionisanja, te bi IMS pored njih trebao da pruži još mnoštvo novih servisa i da omogući korisniku kombinovanje različitih servisa. Vezano za dosadašnje servise razmotrimo sljedeća dva pojma:
Emulacija (PSTN/ISDN emulacija) Simulacija (PSTN/ISDN simulacija)
7.12.2009 8

IMS Sigurnost
Kao i u drugim mrežama i u IMS-u je bitna sigurnost. IMS ima svoje metode za autentikaciju i autorizaciju između korisnika i IMS mreže, pored onih metoda koje već postoje na pristupnoj mreži ( na primjer, GPRS pristupnoj mreži ). IMS zahtijeva da se korisnici autenticiraju prije nego što počnu koristiti servise, dok korisnici, s druge strane mogu zahtijevati privatnost tokom svoje sesije. IMS je zamišljen da bude neovisan od vrste pristupne mreže, te je stoga jezgra IMS-a odvojena od pristupne mreže. Zbog toga IMS može raditi sa različitim pristupnim mrežama, kao što su GPRS, WLAN i UMTS.
7.12.2009 9

IMS Naplativost
IMS takođe mora obezbijediti metode naplaćivanja i obračunavanja troškova. Pored standardnih metoda preuzetih iz već postojećih mreža IMS omoguća i još neke metode naplaćivanja. IMS mora obezbijediti naplaćivanje po vrsti multimedijalnog sadržaja koji korisnici razmjenjuju tokom jedne sesije, jer IMS omogućava korisnicima da kombinuju različite vrste multimedijalnog sadržaja tokom jedne sesije.
7.12.2009 10

IMS QoS
Na Internet-u kašnjenja mogu biti velika i promjenjiva, paketi mogu stizati bez ikakvog redoslijeda, a neki paketi mogu u potpunosti biti izgubljeni ili odbačeni. Sa IMS-om ovo ne bi smio više biti slučaj. Sa IMS-om korisnici koji učestvuju u komunikaciji pregovaraju o mogućnostima i potrebnom QoSu pri uspostavljanju SIP sesije. Potrebni parametri se dogovaraju na aplikativnom nivou, a putem pristupne mreže se udovoljava traženim 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 obezbjeđuje infrastrukturu za upravljanje servisima. Na ovom nivou imamo aplikativne servere i funkcije za naplaćivanje. Aplikativni server može biti smješten u korisnikovoj lokalnoj mreži ili može biti samostalan. Aplikativni server posjeduje nekoliko osnovnih funkcija: Mogućnost procesiranja dolazećih SIP sesija poslanih od strane IMS Sposobnost izdavanja SIP zahtjeva Sposobnost slanja informacija o obračunavanju troškova funkcijama za naplaćivanje
7.12.2009 13

Aplikativni serveri
Servisi koje nudi aplikativni server nisu ograničeni 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 zaduženi za upravljanje sesijama i njihovim rutiranjem ( CSCF-Call Session Control Function ), Dijelovi za skladištenje podataka o korisnicima i servisima ( HSS-Home Subscriber Server i SLF-Subscription Locator Function ) Dijelovi za podršku ( PDF-Policy Decision Function, PDEPosition Determining Entity, SEG-Security Gateway, THIGTopology Hiding Internetwork Gateway ) Dijelovi za kontrolu povezivanja različitih sistema ( BGCFBreakout Gateway Control Function, MGCF-Media Gateway Control Function, MGW-Media Gateway i SGW-Signalling Gateway ). Unutar ovog nivoa postoje još i dijelovi zaduženi 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 mrežni č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 tačku prilikom uspostave sesija između IMS terminala i IMS mreže I-CSCF (Interrogating-CSCF) I-CSCF djeluje kao SIP proksi server za administrativne funkcije S-CSCF (Serving-CSCF) S-CSCF ima važnu ulogu u korisničkoj 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 uključuju korisnički identitet, informacije o registraciji, pristupne parametre i informacije tekuće usluge. SLF predstavlja mehanizam koji omogućuje da ICSCF, S-CSCF i AS pronađu adresu HSS-a koji sadrži korisničke podatke za autentifikaciju korisnika u slučaju da je angažovano više adresabilnih HSSova od strane mrežnog operatora
7.12.2009 17

MRF, BGCF, PSTN/CS Gateway, PDF
MRF (Media Resource Function) predstavlja izvor medijalnih sadržaja u domaćoj mreži, a u isto vrijeme djeluje kao transkoder između različitih aplikacijskih kodeka BGCF (Breakout Gateway Control Function) se koristi za funkcionalnost rutiranja PSTN brojeva u konekcijama sa klasičnih CS PSTN mreža u IMS mrežu. Ovaj element selektuje odgovarajući PSTN/CS gateway za odgovarajuću CS PSTN domenu PSTN/CS Gateway omogućuje uspostavu konekcija i prijem poziva sa PSTN/ISDN mreža. Može biti :
SGW (Signaling Gateway) MGCF (Media Gateway Control Function)

PDF (Policy Decision Function) određuje i kontroliše QoS vrijednosti za svaki pojedini IMS servis. 7.12.2009

18

KORISNIČKI PRISTUPNI NIVO Korisnički sloj obezbjeđuje pristup korisničke opreme raznim servisima IMS mreže preko različitih pristupnih mreža. Osnovni elementi korisničkog sloja su ( u slučaju da se kao pristupna mreža razmatra GPRS mreža ):
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 korisničkom nivou između mreža sa komutacijom kanala ( PSTN, GSM ) i IMS-a. Omogućava povezivanje na nivou prenosioca informacija, što na prvom mjestu predstavlja saradnju između različitih mehanizama transporta kao što su TDM i IP. Vrši transkodiranje i obradu signala na korisničkom nivou kada je to potrebno. Također, IMS-MGW je u mogućnosti da korisnicima u mreži sa komutacijom kanala pruži ton i obavijesti. MGCF kontroliše IMS-MGW.
7.12.2009 20

SGSN ( Serving GPRS Support Node )
SGSN je odgovoran za kontrolne funkcije i funkcije upravljanja saobraćajem u paketski komutiranim mrežama. Kontrolna funkcija se sastoji iz dvije funkcije: - Upravljanje mobilnošću
- Upravljanje sesijama

Upravljanje mobilnošću se odnosi na lokaciju i stanje korisničke opreme, kao i autentikaciju kako korisničke opreme tako i pretplatnika. Upravljanje sesijama se bavi kontrolom pristupa i svim što je vezano za datu konekciju. Upravljanje saobraćajem takođe spada u funkcije upravljanja sesijama. SGSN takođe nadzire saobraćaj između korisničke opreme i GGSN. 21 7.12.2009

Gateway GPRS Support Node
GGSN je zadužen da korisničku opremu spoji na IMS mrežu. GGSN rutira IP pakete koji sadrže SIP signalizaciju između korisničke 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 mrežama. Multimedijalne sesije se odvijaju na sljedeći način:
Uspostavljanje sesije: korisnikov uređaj šalje signal koji obavještava o potrebi za uspostavljanjem sesije, te se potom identificira lokacija mreže u kojoj se korisnik nalazi i dodjeljuje se jedinstveni sesijski identifikator URI ( Uniform Recource Identifier ). Opis sesije: dostavlja opis sesije korisničkom uređaju. Za ovu funkciju se koristi SDP ( Session Description Protocol ). SIP unutar svoje poruke prenosi poruku koju SDP generiše. Upravljanje sesijom: kada se sesija prihvati od strane korisnika dolazi do direktne razmjene sadržaja između krajnjih tačaka. Sadržaj sesije koji se prenosi može 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 učesnik može zahtjevati prekid sesije nakon što se prenos završi.
7.12.2009 24

SIP poruke
SIP je veoma jednostavan jer je baziran na modelu zahtjev-odgovor. U poruci zahtjeva, početna linija je linija zahtjeva koja se sastoji od metode tj. poruke, URI-a koji određuje korisnika ili uslugu kojoj je zahtjev upućen, te verzije SIP protokola. Svaki SIP zahtjev sadrži polje, nazvano metoda koje označava njegovu svrhu. Postoji šest osnovnih SIP metoda koje imaju različitu namjenu:
INVITE – pokreće sesiju pozivajući korisnika da učestvuje u njoj ACK – potvrđuje da je klijent primio konačan odgovor na INVITE zahtjev BYE – pokreće prekid sesije CANCEL – poništava SIP zahtjev za koji još nije stigao finalni odgovor REGISTER – registruje lokaciju korisnika u registracijskom serveru OPTIONS – upit o mogućnostima servera ( metode, ekstenzije SIP-a, kodeke, itd.)
7.12.2009 25

SIP odgovori
Početna linija poruke odgovora se sastoji od verzije SIP protokola, numerički prikazanog koda odgovora i odgovarajuće tekstualne fraze. Prva cifra koda statusa definiše klasu odgovora, dok preostale dvije cifre nemaju kategorizacijsku ulogu. Kodovi stausa su grupisani u slijedeće klase:
1xx Provisional – označava da je poruka zahtjeva primljena i da se zahtjev procesira. 2xx Success – zahtjev je uspješno primljen i prihvaćen 3xx Redirection – označava da zahtjev treba biti preusmjeren,tj. dodatne akcije su potrebne za kompletiranje zahtjeva 4xx Client Error – označava da zahtjev ne može biti prihvaćen zbog greške klijenta 5xx Server Error – zahtjev ne može biti prihvaćen zbog greške servera 6xx Global Failure – nijedan server ne može ispuniti zahtjev

Npr. značenja odgovora su: 100 – pokušava, 180 – zvoni, 183 – progres, 200 – OK, 302 – prebačeno, 500 – Serverska interna greška, 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 funkcioniše i sa konekciono-orijentisanim protokolima ( TCP, SCTP ), kao i sa nekonekciono-orijentisanim protokolima ( UDP ). Ovaj protokol omogućava rutiranje na zahtjev, a ono može biti direktno i preko proxy-ja. Mogućnost nadogradnje i proširenja ovog protokola je jako velika
7.12.2009 27

Pozicija SIP-a

7.12.2009

28

SIP poruke
Komunikacija pomoću SIP protokla, koja se često se naziva i signalizacija, sastoji se od niza poruka (messages). Uobičajeno je da se svaka poruka prenosi u posebnom UDP datagramu. Svaka se poruka sastoji od "početne linije", zaglavlja poruke i tijela poruke. Početna linija označava vrstu poruke. Postoje dvije vrste poruka – zahtjevi (request) i odgovori (response). Zahtjevi se obično koriste za iniciranje neke akcije ili za obavještavanje primatelja zahtjeva o nečemu. Odgovori se koriste za potvrđivanje da je zahtjev primljen i procesuiran te sadrže 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 sadrži URI sljedećeg koraka poruke (next hop). Iz From i To polja zaglavlja identificiraju se pozivatelj (caller) i pozivani (callee). From polje zaglavlja sadrži parametar tag koji služi kao identifikator dijaloga. Call-ID polje zaglavlja je identifikator dijaloga i njegova svrha je identifikacija poruka koje pripadaju istom pozivu. Takve poruke imaju isti Call-ID identifikator.
7.12.2009 31

Dijelovi poruke 2/2
CSeq služi kako bi se zadržao ispravan redoslijed zahtjeva, jer se zahtjevi šalju UDP protokolom koji može promijeniti redoslijed poruka. Contact polje zaglavlja sadrži IP adresu i port na kojem pozivatelj čeka daljnje zahtjeve koje šalje pozivani. Dodatno, tijelo INVITE poruke sadrži opis tipa medija koje pozivatelj prihvaća kodiranih u SDPu.
7.12.2009 32

SIP arhitektura – SIP komponente
SIP predstavlja kontrolni protokol koji omogućuje pokretanje, modifikaciju i zaključenje sesija između više učesnika. Osnovne komponente SIP arhitekture: -Korisnički agent -Proksi serveri -Registrar -Redirekcijski server -SIP poruke i odgovori -SIP transakcije

7.12.2009

33

Direktno rutiranje
Budući da korisnički agent sadrži i klijent i server stranu (jer zna poslati zahtjev i dati odgovor), često kažemo da se korisnički agent ponaša kao UAC (user agent client) ili UAS (user agent server) Na primjer, korisnički agent pozivatelja ponaša se kao UAC kada šalje INVITE zahtjeve i prima odgovore na zahtjev. Kao UAS ponaša se kad primi INVITE zahtjev i pošalje odgovore. No ta se situacija mijenja kad pozvani odluči poslati BYE i prekinuti sesiju. U tom se slučaju korisnički agent pozvanog (koji šalje BYE) ponaša kao UAC, a korisnički agent pozivatelja kao UAS.
7.12.2009 34

Direktno rutiranje

7.12.2009

35

Proxy serveri
Korisnički agenti mogu slati poruke (messages) proxy serveru. Proxy serveri su vrlo važni entiteti u SIP infrastrukturi, usmjeravaju poruke za uspostavu sesije s obzirom na trenutnu lokaciju pozivanog, obavljaju autentikaciju korisnika, accounting i ostale važne funkcije. Najvažniji zadatak proxy servera je usmjeravanje poruka za uspostavu sesije prema pozivanom. Zahtjev za uspostavom sesije obično prelazi nekoliko proxy servera dok ne pronađe 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

Pamćenje stanja transakcije
Serveri bez stanja transakcije su obični prosljeditelji poruka. Oni prosljeđuju poruke neovisno o ostalim porukama vezanim uz istu transakciju. Iako su poruke obično složene u transakcije, proxy bez stanja transakcije o njima ne brine. Serveri bez stanja transakcije su jednostavniji i brži 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 nemogućnost apsorbiranja retransmisija poruka i izvođenja naprednijeg usmjeravanja, na primjer, forking (SIP proxy server može poslati jednu SIP poruku na više destinacija) ili recursive usmjeravanja (kada proxy primi negativan odgovor za zahtjev koji je proslijedio, pa ponovo šalje zahtjev prema nekoj drugoj destinaciji (npr. voicemail)). Mogu, na primjer, pokušati doći do uredskog telefona korisnika, pa ako on ne prihvati poziv preusmjeriti ga na mobitel. Proxy bez stanja transakcije to nije u stanju obaviti, jer ne zna kako je završila transakcija s uredskim telefonom. Još jedna od prednosti proxy servera sa stanjem transakcije je mogućnost accountinga.
7.12.2009 38

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

Redirect rutiranje

7.12.2009

40

Registrar
Registrar je poseban SIP entitet koji prima registracije od korisnika, povlači informacije o njihovoj trenutnoj lokaciji (IP adresa, port i korisničko ime) te sprema informacije u lokacijsku bazu podataka. Namjena je lokacijske baze podataka mapirati sip:tperic@etf.unsa.ba u nešto poput sip:tperic@192.168.1.2:5060. Kad proxy primi poziv za sip:tperic@etf.unsa.ba pretražuje lokacijsku bazu podataka. Pronalazi sip:tperic@192.168.1.2:5060 i poziv za uspostavu sesije šalje tamo. Svaka registracija ima ograničeno vremensko trajanje. Expires polje u zaglavlju ili parametar prestanka valjanosti Contact polja u zaglavlju određuju trajanje valjanosti registracije. Korisnik mora obnoviti registraciju unutar određenog roka ili će ona isteći, a korisnik postati nedostupan.
7.12.2009 41

Registrar
Registracija se vrši REGISTER metodom koja sadrži 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, obično ih u transakcije dijele korinički agenti i određene vrste proxy servera. Dakle, za SIP se kaže da je transakcijski protokol. Transakcija je niz SIP poruka koje se razmjenjuju između elemenata SIP mreže, a sastoji se od jednog zahtjeva i svih odgovora na taj zahtjev. To uključuje nula ili nekoliko privremenih odgovora, te jedan ili više završnih odgovora. Na INVITE se može odgovoriti s više završnih odgovora kad proxy server račva zahtjev (forking). Ako je transakciju pokrenuo INVITE zahtjev, tada ona uključuje i ACK, ali samo ako završni odgovor nije bio 2xx. Ako je završni odgovor bio 2xx, tada se ACK ne smatra dijelom transakcije.
7.12.2009 44

Transakcije
Kao što vidimo, radi se o prilično asimetričnom ponašanju - ACK je dio transakcija s negativnim završnim odgovorom, ali nije dio transakcija s pozitivnim završnim odgovorima. Razlog je takvog razdvajanja važnost isporuke svih 200 OK poruka. Ne samo da one uspostavljaju sesiju, već ih mogu generirati i višestruki entiteti kada proxy server račva zahtjev, a sve se takve poruke moraju isporučiti korisničkom agentu koji inicira sesiju. U takvom slučaju korisnički agenti preuzimaju odgovornost i retransmitiraju 200 OK odgovore dok ne prime ACK. 45 7.12.2009

SIP transakcija

7.12.2009

46

Dijalozi
Pokazali smo što su transakcije, da jedna transakcije uključuje INVITE poruku i njezine odgovore, a druga transakcija uključuje BYE poruku i njezine odgovore kada se sesija prekida. No te bi dvije transakcije trebale biti na neki način povezane - obje spadaju u isti dijalog (dialog). Dijalog predstavlja peer-to-peer SIP odnos između dva korisnička agenta. Dijalog traje neko vrijeme te predstavlja vrlo važan koncept za korisničke agente. Dijalozi olakšavaju pravilni sequencing I usmjeravanje poruka između SIP krajnjih točaka.
7.12.2009 47

Dijalozi
Dijalozi se identificiraju pomoću 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 veličini za svaku poruku unutar dijaloga inače ć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 znači da unutar dijaloga može 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 način jasno može pokazati odnos poruka i slati poruke koje nisu povezane s ostalim porukama izvan dijaloga. To olakšava implementaciju, jer korisnički agenti ne moraju održavati stanje dijaloga. Na 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 pošalje MESSAGE zahtjev, on ne uspostavlja dijalog. Sve će naknadne poruke (čak I MESSAGE) biti neovisne o onoj prijašnjoj.
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 definiše kao skup medijskih tokova koji će se razmjenjivati u određenom vremenu. Kako je SDP opisni protokol SDP poruke se mogu transportovati različitim protokolima, npr. SIP, RTSP, ...
7.12.2009 51

SDP paket
SDP paketi obično uključuju slijedeće informacije:
- Ime i namjene sesije. - Vremena trajanja sesije.

Pošto su resursi potrebni za učešće u sesiji ograničeni potrebno je uključiti 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
Mogući su sljedeći 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 slijedećem primjeru sa slike pokazan je metod INVITE sa višestrukim medijskim tokovima.

7.12.2009

56

H.248/MEGACO (Media Gateway Control)
H.248/MEGACO je signalni protokol između Media Gatewaya i Media Gateway Controller-a (MGC) i predstavlja rezultat zajedničkog 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 podrži 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 podržavati oba standarda, dok MG može ali ne mora imati podršku za oba standarda
7.12.2009 57

H.248/Megaco arhitektura
Protokol je dizajniran tako da obezbijedi centralizovanu arhitekturu sa centralnim uređajem MGC-om koji upravlja logikom komutacije i funkcijama kontrole poziva Media Gateway vrši konverziju formata glasovne/video informacije iz TDM mreže u IP mrežu i obrnuto H.248 obezbjeđuje kreiranje, modifikaciju i brisanje media strima preko Media Gateway, s tim da protokol obezbjeđuje i mogućnost 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 omogućava 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 obezbjeđuje mehanizme za slanje i primanje podataka u vidu strima Po definiciji RTP podržava različite transportne protokole, mada uobičajeno se pokreće 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 Kašnjenje [ms] 0,125 0,125 0,125 2,5 30 10

„Mean Option Scoring“ ili skraćeno MOS koja je definisana ITU-T preporukom P.800 je subjektivna metoda određivanja kvaliteta prenesenog glasa:5-odličan, 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 obezbjeđuje periodičnu razmjenu kontrolnih informacija između učesnika sesije i ove informacije se koriste za detekciju i korekciju problema u distribuciji. RTCP definiše pet različitih tipova RTCP paketa i to:
Report pošiljaoca (SR) se koristi od strane aktivnih učesnika sesije za prenos predajne i prijemne statistike; Report primatelja (RR) se koristi za slanje prijemne statistike od strane učesnika koji samo primaju, a ne šalju podatke; Opis izvora (SDES) sadrži jedan ili više opisa pojedinih učesnika sesije; BYE se koristi za indikaciju kraja sesije za pojedinačnog učesnika; Funkcije specifične aplikaciji (APP) omogućuje slanje RTCP paketa specifične za pojedine aplikacije.
7.12.2009 61

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->