Prezentacija 3

Napredne računarske mreže
Dio 3
Multimedijalno umrežavanje
Prof. Boris Damjanović
Boris Damjanović P 1.1

Pregled
9.1 Multimedijalne mrežne aplikacije

9.2 Striming uskladištenog videa
9.3 Prenos glasa preko Interneta (VoIP)
voice-over-IP
9.4 Protokoli za aplikacije za razgovor u realnom
vremenu
9.5 Mrežna podrška za multimediju

Multimedijalne mrežne aplikacije
• Za bilo koju mrežnu aplikaciju

– koja koristi zvuk ili video,
– kažemo da je multimedijalna mrežna aplikacija.
• Razmotrićemo suštinske karakteristike

– samih audio i video medija
• Potom slijedi
– klasifikacija aplikacija
• Svaka klasa aplikacija u ovoj

– klasifikaciji ima sebi svojstven skup zahtijeva
– vezan za usluge koje treba da pruže i
– načine na koji su projektovane

Svojstva videa
• Najistaknutija karakteristika videa je

– njegov veliki bitrate (čitamo bitrejt)
– bitrate predstavlja prosječan broj kilobita
» koji se koristi za pamćenje jedne sekunde
» videa ili zvuka.
• U domaćoj literaturi, bitrate se prevodi
• kao bitska brzina, brzina prenosa
• Bitrate videa na internetu

• obično se kreću u opsegu od
– 100 kb/s za video-konferencije
» niskog kvaliteta
– do preko 3 Mb/s za protok filmova
» visoke rezolucije
Svojstva videa
• Ukratko ćemo razmotriti

– tri različita korisnika koji koriste
– različite internet aplikacije.
• (1) Frenk, brzo lista fotografije

– na Facebook stranicama svojih prijatelja
– Frenk gleda novu fotografiju
» svakih 10 sekundi a fotografije su
» u prosjeku veličine 200 kB
• radi jednostavnosti uzimamo da je 1 kB = 8000 bita

Svojstva videa
• (2) Marta preuzima muziku preko interneta

– na svoj pametni telefon.
– Pretpostavimo da Marta koristi uslugu
» kao što je Spotify za slušanje pjesama
» u formatu MP3,
» jednu za drugom, pri čemu su one
» kodirane brzinom od 128 kb/s.

Svojstva videa
• (3) Viktor gleda video koji je

– kodiran na 2 Mb/s.
• Na kraju, pretpostavimo da sva tri korisnika
– koriste usluge 4000 sekundi
» približno 67 minuta.
• Protok videa troši
– daleko najviše propusnog opsega,
– pošto mu je bitrate
– deset puta veći od aplikacija za Facebook i protok muzike

Svojstva videa
• Kompanija Cisco navodi da je

– 2018. godine protok video sadržaja
» predstavljao 75% saobraćaja,
– a da će do 2022. godine
» protok videa uživo i snimljenih video-zapisa
» predstavljati 82%
» sveukupnog internet saobraćaja običnih korisnika

Svojstva videa
• Druga važna karakteristika videa je da

– video može da se komprimuje
• Video je niz slika,
– prikazuju se stalnom brzinom,
– npr. 24 ili 30 slika u sekundi.
• Nekomprimovana digitalno kodirana slika

– se sastoji od niza piksela,
– pri čemu se svaki piksel kodira
» određenim brojem bita
– koji predstavljaju osvijetljenost i boju.

Svojstva videa
• U videu postoje
– dvije vrste redundantnosti
– koje mogu da se koriste za video kompresiju.
• (1) Prostorna redundantnost

– je redundansa unutar date slike
• Slika koja se sastoji pretežno od bijelog prostora

– ima visok stepen redundantnosti i
– može efikasno da se komprimuje
– bez osjetnog žrtvovanja kvaliteta

Svojstva videa
• Vremenska redundantnost
– predstavlja ponavljanje iz jedne slike u sljedeću.
• Ako su, na primjer, prethodna slika i sljedeća slika

– potpuno iste,
• nema razloga da se sljedeća slika
– ponovo koduje;
• Umjesto toga, efikasnije je da se u kodiranju

– jednostavno ukaže na to da je
– sljedeća slika sasvim ista

Svojstva videa
• Algoritmi za kompresiju
– mogu da komprimuju video
– praktično na svaki željeni bitrate (bitsku brzinu).
• Što je bitrate (bitska brzina) veći,

– bolji je kvalitet slike i ukupan doživljaj korisnika.

Svojstva videa
• Možemo da napravimo,
– tri verzije istog videa,
– sa brzinama od 300 kb/s, 1 Mb/s i 3 Mb/s.
• U zavisnosti od propusnog opsega

• kojim trenutno raspolažu
– korisnici tada mogu da biraju koju verziju će gledati

Svojstva zvuka
• Digitalni zvuk
– uključujući digitalizovani govor i muziku
– ima znatno manje zahtjeve
– za propusnim opsegom od videa.
• Digitalni zvuk ima izvjesne osobine

– koje bi trebalo imati u vidu
– kada se projektuju multimedijalne mrežne aplikacije
• Pogledajmo najprije kako se analogni zvuk

– pretvara u digitalni signal:

Svojstva zvuka
• (1) Analogni zvučni signal se prvo uzorkuje

» odmjerava, semplira
• Sampling - uzimanje uzoraka
– nekom fiksnom brzinom,
– na primjer brzinom od 8000 uzoraka (semplova)
» u sekundi.
• Vrijednost svakog uzorka je

– proizvoljan realan broj.

Svojstva zvuka
• (2) Svi uzorci se zatim zaokružuju

– na jednu vrijednost iz konačnog skupa vrijednosti.
– Ova operacija se zove kvantizacija

» zaokruživanje.
– Broj takvih konačnih vrijednosti –

» koje se zovu kvantizacione vrijednosti –
» obično je neki stepen broja dva,
» na primjer. 256 kvantizacionih vrijednosti.

Svojstva zvuka
• (3) Svaka od kvantizacionih vrijednosti

– predstavlja se fiksnim brojem bita.
– ako postoji 256 kvantizacionih vrijednosti,
» onda se svaki uzorak predstavlja jednim bajtom.
• Ako se analogni zvučni signal semplira (uzorkuje)

» sa 8000 uzoraka u sekundi i
– ako se svaki uzorak kvantizuje i predstavi
» pomoću 8 bita,
– onda će dobijeni digitalni signal trajanja 1 sekunde
» moći da se snimi u datoteku dužine 64000 bita.

Svojstva zvuka
• Za reprodukciju preko zvučnika,

– taj digitalni signal može ponovo da se pretvori –
– odnosno, dekodira - u analogni signal.
• Međutim, dekodirani analogni signal

– je samo aproksimacija prvobitnog signala,
– pa kvalitet zvuka može da bude primjetno izobličen
• Povećavanjem brzine uzorkovanja i

– broja kvantizacionih vrijednosti,
– dekodirani signal može bolje
– da aproksimira prvobitni analogni signal.

Svojstva zvuka
• Kvantizacija može da bude linearna,

– kada su kvantizacione vrijednosti linearno raspoređene.
• Na slici je prikazan signal koji je kvantizovan pomoću 4 bita,

– kada se dobije (samo) 16 različitih nivoa amplitude,
– odnosno 16 kvantizacionih vrijednosti.

Svojstva zvuka
• Kvantizacija može da bude nelinearna,

– kada se kvantizacioni nivoi mijenjaju
– u funkciji amplitude signala.
• Na primjer, grublja skala

» manji broj kvantizacionih vrijednosti
– se koristi za veće amplitude
• a finija skala
» veći broj kvantizacionih vrijednosti
– za manje amplitude.
• Najvažnije tehnike nelinearne kvantizacije su

– A-law i µ-law algoritmi.

Svojstva zvuka
• Tehnika kodiranja koju smo upravo opisali

– zove se impulsna kodna modulacija
» pulse code modulation - PCM.
– Za govor se često koristi PCM,

» sa brzinom sempliranja (uzorkovanja)
» od 8000 uzoraka u sekundi i osam bita po uzorku
» 64 kb/s.
– Audio kompakt disk (CD) koristi PCM,

» od 44100 uzoraka u sekundi i 16 bita po uzorku;
» 705,6 kb/s za mono i
» 1,411 Mb/s za stereo.

Svojstva zvuka
• Kodiranje PCM tehnikom

– rijetko se koriste na internetu
• Popularna tehnika kompresije

– kvalitet približan CD kvalitetu
– MPEG 1 sloj 3 (MPEG layer 3)
– poznatija kao MP3.
• Srodan standard je
– Advanced Audio Coding-AAC,
– koji popularizuje Apple.

Svojstva zvuka
• mp3 kompresija nudi nam izbor bitrata

– od 16-320 kbita
• 128kbps
» 128 kilo bita po sekundi
» 16 kilo bajta po sekundi)
– najčešće korištena bitrata,
– sa najboljim odnosom kvaliteta zvuka i veličine
datoteke.
» CD - kvalitet,
– a mjera kompresije joj je približno
– 1:11 (11 puta manja datoteka).

Svojstva zvuka
• Zahtjevi za video i audio

– Donekle različiti
• Video konferencija se nastavlja ako se

– signal izgubi na nekoliko sekundi
• ako se zvučni signal često gubi,

– korisnici će možda morati da prekinu vezu

Šta je MP3?
• Mp3 je format kompresije audio zapisa

– pomoću kojeg veličinu audio datoteke
– možemo smanjiti i do više od deset puta
– bez vidljivog gubljenja kvaliteta.
• Nastao je iz MPEG standarda

– koga su razvile ISO i IEC organizacije
– za potrebe filmske industrije
» MPEG je skraćenica za
• Moving Pictures Experts Group.
• Visok stepen kompresije

– čini ga prihvatljivom
– za prenos putem interneta, arhiviranje isl.
Šta je MP3?
• Standardan audio zapis CD kvaliteta

– snimljen je frekvencijom od 44,1KHz
– sa dubinom (kvantizacijom) od 16 bita (216)
– sa dva kanala (stereo).
• 1. amplitudu signala mjerimo 44100 puta

– u toku jedne sekunde,
• 2. dubina/kvantizacija=16 bita
– za predstavljanje visine amplitude
– na raspolaganju imamo ukupno 65536 tačaka.
• 3. Nadamo se da treći podatak –

– stereo ne treba posebno objašnjavati
– dva kanala
Šta je MP3?
• U objašnjenjima načina kompresije podataka,

– većina autora polazi od
• psiho-akustičnog modela i
• maskiranja frekvencija,
– dok rijetko pominju i
• Furijeove transformacije.
• Na prvi pogled, mnogo komplikovanih izraza!

Šta je MP3?
• Pretpostavimo da se nalazite
– na aerodromu ili u diskoteci.
– Postoji realna vjerovatnoća
» da vašeg sagovornika nećete uopšte čuti
» zbog buke koja vas okružuje.
• To je direktna posljedica
• maskiranja frekvencija,
• kada su tiše frekvencije potisnute
– (maskirane) glasnijim.
• Psiho-akustični model
– koristi ovu činjenicu da kreira model
– pomoću kojeg će na najbolji način biti iskorišćeno
– odbacivanje nekih frekvencija koje su maskirane
– bez velikog uticaja na kvalitet zvuka.

Šta je MP3?
• Furijeova analiza proučava načine na koje

– neka funkcija (složen signal)
– može da se predstavi pomoću
– sume jednostavnijih trigonometrijskih funkcija
• Dakle, neki složen signal moguće je razložiti

– npr. na zbir signala sinusnog oblika
• sinusoida i kosinusoida
» različitih učestanosti (frekvencija).

Šta je MP3?
• Recimo da posmatramo signal trajanja 1 sec.

– i da se on može razložiti na 4 sinusna signala
– različitih frekvencija.
• U praksi, signali su mnogo kompleksniji!
• U tom slučaju, umjesto pomoću 44.100 tačaka
– signal možemo prikazati pomoću samo četiri tačke,
– pod uslovom da ga posmatramo
– u koordinatnom sistemu
– frekvencija na x osi-
– Amplituda na y osi

Šta je MP3?
• Pošto je jedna od frekvencija

– (označena crvenom bojom)
• maskirana,
– možemo je odbaciti
– pa tako dobijamo ukupno tri tačke
– potrebne za opisivanje ovog signala.

Šta je MP3?
• Takođe, mogli bi da odaberemo

– još neke frekvencije
» (izrazito niske ili izrazito visoke)
– koje možemo da uklonimo.
• Situacija je u praksi nešto komplikovanija,

– ali se pri kompresiji
– (stvaranju mp3 signala)
– služimo sličnim metodama.

• Namjerno prazna stranica

Vrste multimedijalnih mrežnih aplikacija
• Multimedijalne aplikacije razvrstavamo

• u tri opšte kategorije:
• (i) protok uskladištenog audio/video zapisa,

• (ii) prenos razgovora/videa korisnika preko interneta i
• (iii) protok audio/video signala uživo.

(i) protok uskladištenog audio/video zapisa,
• (i) protok uskladištenog audio/video zapisa,

Protok uskladištenog zvučnog i video zapisa
• Usredsredićemo se na protok
» (streaming-striming)
– uskladištenog videa,
– koji obično istovremeno obuhvata
– video i zvučne komponente.
• Striming zvuka (npr. Spotify)

– je sličan

• U ovoj klasi aplikacija,

– osnovni medijum je prethodno snimljen video,
» film, televizijska emisija,
» ili prethodno snimljen video koji je napravio korisnik
• Prethodno snimljeni video-zapisi

– se postavljaju na servere,
• a korisnici šalju zahtjeve tim serverima
– za gledanje određenog videa na zahtjev
• YouTube (Google), Netflix, Amazon, Hulu…

• (1) Striming.
• U aplikaciji za striming uskladištenog videa,
– klijent obično počinje emitovanje nekoliko sekundi
– nakon što počne prijem videa sa servera.
• To znači da klijent emituje

– sa jednog položaja u videu
– dok istovremeno prima preostale dijelove
» tog videa sa servera.
• Ova tehnika, je poznata pod nazivom striming

» označava protok tokom preuzimanja,
– izbjegava se preuzimanje cijele video datoteke
» i izlaganje mogućem dužem kašnjenju
– prije početka reprodukcije.

• (2) Interaktivnost.
• Pošto je sadržaj prethodno snimljen,
– korisnik može da privremeno prekine,
– premota unaprijed ili unazad
– kroz video sadržaj.
• Vrijeme od kada korisnik postavi takav zahtjev

– dok se posljedice tog zahtijeva ne ispolje
– kod klijenta trebalo bi da bude što kraće
– kako bi odziv bio prihvatljiv.

• (3) Kontinualno emitovanje.

• Kada emitovanje videa otpočne,
– trebalo bi da se obavlja
– vremenski usklađeno sa snimkom.
• Prema tome, podaci sa servera moraju

– da se prime na vrijeme za emitovanje kod klijenta;
• inače, kod korisnika se dešava
– zamrzavanje video okvira
» (kada klijent čeka na zakašnjele okvire)
– ili preskakanje okvira
» (kada klijent preskoči zakašnjele okvire).

• Najvažniji uticaj na striming videa

– je uticaj prosječne propusne moći
• Mreža mora aplikaciji za striming

– da obezbijedi prosječnu propusnu moć
– koja je najmanje jednaka bitskoj brzini samog videa
• Korišćenjem
• (1) baferovanja i
• (2) prethodnog preuzimanja,
– moguće je obezbediti kontinualno emitovanje
– čak i kada se propusna moć mijenja
• Sve dok je prosječna propusna moć

– veća od bitske brzine videa

• Za mnoge aplikacije za striming videa,

– prethodno snimljen video se skladišti i preuzima
– korišćenjem CDN mreža,
» content delivery network
– umjesto iz zasebnog centra podataka.
• Postoje mnoge P2P aplikacije za striming videa

– za koje se koristi video uskladišten
– na korisničkim (ravnopravnim) računarima

(ii) prenos razgovora/videa korisnika preko
interneta
• (ii) prenos razgovora/videa korisnika preko

interneta

Prenos razgovora i videa korisnika preko
interneta (Voice- and Video-over-IP)
• Prenos razgovora korisnika preko interneta
– u realnom vremenu obično se zove
– internet telefonija,
– pošto je, sa tačke gledišta korisnika,
– sličan tradicionalnoj komutiranoj telefonskoj usluzi.
• Često se zove i prenos glasa preko interneta

– (Voice over IP- VoIP).
• Prenos videa korisnika je sličan,

– osim što pored govora uključuje i video učesnika.

• Većina današnjih govornih i video sistema
– za razgovor korisnika dozvoljava korisnicima da
– prave konferencije sa tri ili više učesnika.
• Prenos razgovora i videa korisnika danas se

– naširoko koriste na internetu,
– pa se internet kompanije
– Skype, QQ, WhatsApp, Viber, Talky, WeChat i
Facebook Messenger
(proizvodnja programa Google Talk je prestala 2017.)
• hvale stotinama miliona svakodnevnih korisnika.

• Kada je u pitanju prenos
– govora i videa preko interneta
• ističu se dva važna zahtjeva
– zahtjev koji se tiče vremenskih ograničenja i
– zahtjev koji se tiče tolerisanja gubitaka podataka.
• Navedeni zahtjevi posebno su važni za

– aplikacije za razgovor i video korisnika.

• Neke aplikacije su
– izuzetno osjetljive na kašnjenje
• Kada je u pitanju razgovor (poziv) uživo
– kašnjenje od trenutka kada korisnik
» nešto kaže ili se pomjeri
– dok se ta akcija ne manifestuje na drugom kraju
» trebalo bi da bude
» manje od nekoliko stotina milisekundi.
– Slušalac ne primjećuje kašnjenja

» manja od 150 milisekundi,
– kašnjenja između 150 i 400 milisekundi
» mogu da budu prihvatljiva,
– a kašnjenja koja prelaze 400 milisekundi
» mogu da budu izuzetno neugodna

• Aplikacije za razgovor i video korisnika
– su tolerantne na gubitke –
– povremeni gubici prouzrokuju samo povremene smetnje
– ti gubici često mogu da se djelimično ili potpuno maskiraju.
• Osjetljivost na kašnjenje a tolerisanje gubitaka,

– ovih aplikacija
– jasno se razlikuju od onih kod elastičnih aplikacija,
– kao što su: krstarenje vebom, e-pošta, društvene mreže i
daljinsko prijavljivanje.
• Za elastične aplikacije,
– veća kašnjenja su neprijatna,
» ali ne i posebno štetna,
– cjelovitost i integritet prenijetih podataka neuporedivo su
značajniji.
(iii) protok audio/video signala uživo
• (iii) protok audio/video signala uživo

Striming zvuka i videa uživo
• Ovo je treća klasa aplikacija

– slična je klasičnom emitovanju radija i televizije,
– izuzev što se prenos obavlja preko interneta.
• Ove aplikacije omogućavaju korisniku

– da uživo prima radio ili televizijski prenos
– sa svih strana svijeta.
• Danas postoje hiljade radio i televizijskih stanica

– koje svoj program emituju preko interneta.

Striming zvuka i videa uživo
• Aplikacije za prenos uživo,

» slično difuznom emitovanju,
– obično imaju mnogo korisnika
– koji istovremeno primaju isti zvučni/video program.
– Ovo se, sa današnjim internetom,
» obično obavlja korišćenjem CDN mreža
• Mreža mora da svakom multimedijalnom toku

– obezbijedi prosječnu propusnu moć
– veću od brzine kojom se video koristi
• Mogu da se tolerišu kašnjenja do desetak sekundi

– od trenutka kada korisnik izabere
– prenos uživo do početka reprodukcije

Pregled

voice-over-IP
vremenu

Striming uskladištenog videa
• Za aplikacije za striming videa,

– unaprijed snimljeni video zapisi se
– postavljaju na servere,
– a korisnici tim serverima
– šalju zahtjeve za gledanje videa na zahtjev
» (videos on demand).
• Korisnik može da gleda video

– od početka do kraja bez prekidanja,
– može da prekine gledanje prije kraja videa,
– ili da utiče na emitovanje videa tako što ga
» pauzira ili promijeni tačku odakle ga gleda na neku sljedeću ili
proteklu scenu.

• Sistemi za striming videa mogu

• da se klasifikuju u tri kategorije:
– UDP striming,
– HTTP striming i
– prilagodljiv HTTP striming
• Mada se sve tri vrste sistema koriste u praksi,

– većina današnjih sistema koristi
– HTTP striming i
– prilagodljiv HTTP striming.

• Zajednička karakteristika
– sva tri oblika video striminga
– je veliko korišćenje baferovanja
» u aplikacijama sa klijentske strane,
– čime se ublažavaju posljedice kašnjenja
» od jednog do drugog kraja i
– promenljive količine propusnog opsega
• Za striming videa
– korisnici uglavnom mogu da tolerišu
– malo početno kašnjenje od nekoliko sekundi

• Kada video počne da pristiže kod klijenta,

– klijent ne mora odmah da počne sa emitovanjem,
– već može da napravi izvjesnu rezervu
– videa u baferu aplikacije.
• Pošto klijent u baferu napravi rezervu

– od nekoliko sekundi videa koji još nije odgledan,
– klijent može da počne sa emitovanjem videa.

• Postoje dvije značajne prednosti

– baferovanja na klijentskoj strani.
• (1) Baferovanje na klijentskoj strani

– može da apsorbuje varijacije kašnjenja
» od servera do klijenta.
• (2) ako propusni opseg između servera i klijenta

– nakratko padne
» ispod brzine kojom se video emituje,
– korisnik može i dalje da uživa u kontinualnom emitovanju,
– sve dok se bafer klijentske aplikacije
» potpuno ne isprazni

• Na slici je prikazano slanje video zapisa sa servera

– i baferovanje na klijentskoj strani.
• Prije nego što se upoznamo sa slikom
– obratićemo pažnju na trenutke vremena t0, t1 i t3.
– t0 je trenutak u kom je server počeo da šalje podatke
– t1 je trenutak u kom je klijent primio prve podatke
– t3 je trenutak u kom je klijent počeo da prikazuje video
– t2 ćemo objasniti kasnije

• Vremenski interval t0 – t1 je posljedica

– varijabilnog kašnjenja u mreži
– Variable Network Delay
• Vremenski interval t1 – t3 je interval za koji

– klijent odlaže emitovanje,
– rezervisan je za baferovanje
– Client Playout Delay

• Pretpostavimo da je video kodiran

– fiksnom bitratom (bitskom brzinom),
– svaki video blok sadrži
» video okvire koji bi trebalo da se
– prikazuju tokom istog fiksnog intervala vremena Δ.

• Server prenosi prvi blok u trenutku t0,

– drugi blok u trenutku t0 + Δ.
– treći blok u trenutku t0 + 2Δ i tako dalje.
• Kada klijent započne prikazivanje,
– svaki blok bi trebalo da se emituje
– Δ vremenskih jedinica nakon prethodnog
» kako bi se vrijeme podudarilo
» sa vremenom originalnog snimljenog videa.

• Zbog promjenljivog kašnjenja

– od kraja do kraja mreže,
– različiti video blokovi imaju različita kašnjenja.
• Prvi video blok stiže do klijenta

– u trenutku t1
– a drugi blok u trenutku t2.

• Kašnjenje mreže za i-ti blok je

– horizontalna udaljenost
» od trenutka kada je server poslao određeni blok
» do trenutka kada je taj blok stigao do klijenta;
– obratite pažnju na to da kašnjenje mreže
» varira od bloka do bloka.

• U ovom primjeru,
• ako bi klijent započeo emitovanje
– čim prvi blok stigne u t1
– drugi blok ne bi stigao na vrijeme do servera
– da bi se reprodukovao u t1 + Δ.
» emitovanje videa bi moralo da se zaustavi
» ili bi se blok 2 preskočio

UDP striming
• Sa UDP strimingom,
– server prenosi video
– tako što odsječke videa šalje
– stalnom brzinom preko protokola UDP.
• Pošto UDP ne koristi mehanizam

– za kontrolu zagušenja,
– server može da šalje pakete na mrežu
– brzinom kojom se video koristi
– bez ograničenja brzine koja postoji u protokolu TCP.
• UDP striming obično koristi mali bafer

– na klijentskoj strani,
– dovoljan da primi manje od jedne sekunde videa.

UDP striming
• Server video odsječke namijenjene za UDP

• enkapsulira u pakete posebno namijenjene
– za prenos zvuka i videa
– koristeći protokol za prenos u realnom vremenu
– npr.
– Real-Time Transport Protocol – RTP
– I slične protokole

UDP striming
• Drugo svojstvo kojim se odlikuje UDP striming je to što,

» pored protoka videa od servera do klijenta,
– klijent i server uporedo održavaju
– i posebnu kontrolnu vezu
» preko koje klijent šalje serveru komande
» koje se tiču promjena stanja uspostavljene veze
• Real-Time Streaming Protocol – RTSP

– je popularan protokol otvorenog koda za takve kontrolne veze

UDP striming
• Nedostaci:
• (1) Zbog nepredvidive i promjenljive količine
– raspoloživog propusnog opsega između servera i klijenta,
– UDP striming konstantnom brzinom
– ne omogućava uvijek kontinualnu reprodukciju
• (2) Potreban je server za kontrolu medija,
– kao što je RTSP server,
– koji obrađuje zahtjeve klijenta prema serveru i
– prati stanje klijenta
» poziciju klijenta u emitovanju videa,
» da li je video pauziran ili se emituje i tako dalje
– za sve uspostavljene veze klijenata.
• (3) Mnoge mrežne barijere konfigurisane tako
– da blokiraju UDP saobraćaj,
– pa korisnici iza tih mrežnih barijera ne mogu da primaju UDP video

HTTP striming
• U HTTP strimingu,
– video se jednostavno čuva na HTTP serveru
– kao obična datoteka
» sa određenom URL adresom.
• Kada korisnik želi da pogleda taj video,

– klijent uspostavlja TCP
» vezu sa serverom
– i šalje HTTP zahtjev GET
» za tu URL adresu.
• Server tada šalje odgovarajuću video datoteku,

– u okviru HTTP poruke odgovora,

HTTP striming
• Na klijentskoj strani, podaci se skupljaju

– u baferu klijentske aplikacije.
• Kada broj bajta u ovom baferu premaši

– unaprijed određen prag,
– klijentska aplikacija počinje emitovanje
• Uzima video okvire iz bafera klijentske aplikacije,

– dekomprimuje te okvire i
– prikazuje ih na korisnikovom ekranu

HTTP striming
• Prilikom prenosa datoteke protokolom TCP,

– brzina prenosa od servera do klijenta
– može znatno da varira
» krivac
» TCP mehanizam kontrole zagušenja
• Paketi takođe mogu znatno da kasne

– TCP mehanizam ponovnog slanja.
• TCP mehanizmi
– nisu uvijek prepreka za kontinualno emitovanje
– ako se koristi
» baferovanje i prethodno preuzimanje
Prethodno preuzimanje (prefeching)
• U primjeru sa slike
– server prenosi video brzinom
– kojom bi video trebalo da se emituje
• U realnosti,
– Server može prenositi podatke i brže!
• Klijent može da pokuša da

– prethodno preuzme (prefetching)
– video okvire koji će se trošiti kasnije

Prethodno preuzimanje (prefeching)
• Pretpostavimo da je
– brzina korišćenja videa 1 Mb/s,
• ali da je mreža u stanju da isporuči video
– od servera do klijenta
– konstantnom brzinom od 1,5 Mb/s.
• Klijent će biti u stanju i

– da svakog sekunda poveća količinu
– uskladištenih video podataka za 500 kb.
• Ako bi kasnije klijent neko kraće vrijeme

– primao podatke brzinom manjom od 1 Mb/s,
» on bi mogao i dalje
– da obezbijedi kontinualno emitovanje,
– zahvaljujući rezervi

Bafer klijentske aplikacije i TCP baferi
• Na slici je
– interakcija između klijenta i servera za HTTP striming
• Lijevo, na strani servera
– dio video datoteke prikazan bijelom bojom
» već je poslat u soket servera,
– dok je tamniji dio ono što je
» preostalo da se pošalje

• Iz ovog bafera
– podaci se smještaju
• u TCP bafer za slanje
– prije nego što se prenesu na internet
• Pošto je TCP bafer za slanje na slici pun,

– server trenutno ne može da šalje
– više bajta iz datoteke u soket

• Na klijentskoj strani,
– klijentska aplikacija (media player)
– učitava podatke iz TCP prijemnog bafera
– i smješta ih u bafer klijentske aplikacije.
• Klijentska aplikacija
– povremeno uzima video okvire iz bafera
– dekomprimuje okvire i prikazuje ih

• Šta se dešava
– kada korisnik pauzira video tokom striminga?
• Za vrijeme pauze,
– podaci se ne uzimaju iz bafera klijentske aplikacije,
– mada podaci i dalje pristižu iz servera u bafer.
• Ako je bafer klijentske aplikacije konačan,
– on će se na kraju popuniti,
– što dovodi do „povratnog pritiska” (back pressure)
– čitavim putem do servera

• Kada se bafer klijentske aplikacije popuni,

– podaci ne mogu više da izlaze
– iz TCP bafera za primanje,
– pa se i on popuni.
• Kada se TCP bafer za primanje popuni,
– podaci ne mogu više da izlaze
– iz TCP bafera servera za slanje,
– pa se i on popuni.
• Kada se popuni serverov TCP bafer za slanje,
– server ne može više da šalje podatke u soket.

• Tako, ako korisnik pauzira video,

– server bi mogao da bude primoran
– da prekine slanje,
– pa bi u tom slučaju server bio blokiran,
» sve dok korisnik ne nastavi
» sa emitovanjem videa.

• Čak i tokom uobičajenog reprodukcije

» bez pauziranja,
– ako se popuni bafer klijentske aplikacije,
» povratni pritisak dovodi do toga
» da se popune TCP baferi,
– zbog čega server mora da smanji brzinu.

• Da bi se odredila ta brzina,
• mora se voditi računa o tome da,
– kada klijentska aplikacija ukloni f bita,
• jer ih je uzela da prikaže korisniku
» ona u baferu klijentske aplikacije
» pravi mjesto za f bita,
– što sa svoje strane omogućava da
» server pošalje f dodatnih bita.

• Brzina slanja iz servera

– ne može biti veća
– od brzine potrošnje u klijentu.
• Pun bafer klijentske aplikacije

– posredno ograničava brzinu
– kojom se video šalje od servera ka klijentu
» kada se koristi HTTP striming.

Analiza video striminga
• Malo jednostavnog modelovanja

– daće nam bolji uvid u početno odlaganje emitovanja
– i zamrzavanje zbog pražnjenja bafera aplikacije.
• Pogledaćemo primjer na slici
• Neka je B veličina (u bitima) bafera klijentske
aplikacije,
– a Q broj bita koji moraju da se baferuju
– prije nego što klijentska aplikacija započne emitovanje
– (naravno, Q < B).

• Neka je r brzina potrošnje videa –

– brzina kojom klijent tokom reprodukcije
» uzima bite iz bafera klijentske aplikacije.
• ako se okviri smjenjuju
– brzinom od 30 okvira/sekundi,
• a svaki (komprimovani) okvir
– ima 100 000 bita,
• onda je r = 3 Mb/s.
• Zanemarićemo TCP bafere za slanje i primanje.

• Pretpostavimo da server šalje

– bite konstantnom brzinom x,
– kad god bafer klijenta nije pun
» Ovo je uprošćeno, jer znamo
• TCP brzina slanja varira zbog kontrole zagušenja

• Pretpostavimo da je u trenutku t = 0
– bafer aplikacije prazan i
» video počinje da stiže u bafer klijentske aplikacije.
• Sada se pitamo u kom trenutku t = tp
– počinje emitovanje.
• Takođe se pitamo u kom trenutku t = tf
– će se popuniti bafer klijentske aplikacije.

• Najprije ćemo odrediti tp

– vrijeme kada je Q bita ušlo u bafer aplikacije
» i kad počinje emitovanje.
• Sjećate se da biti stižu u bafer klijentske aplikacije

– brzinom x i da se iz tog bafera
– ni jedan bit ne uklanja
» prije početka reprodukcije.
• Prema tome, vrijeme potrebno da se prikupi Q bita

– (početno kašnjenje baferovanja)
– iznosi tp = Q/x.

• Sada ćemo odrediti tf,

– trenutak kada se bafer
– klijentske aplikacije napuni.
• Najprije primjećujemo da, ako je

–x < r
– to jest, ako je brzina kojom server šalje
» manja od brzine kojom se video troši,
• bafer klijenta
– nikada neće da se napuni!

• Zaista, počevši od trenutka t

– bafer klijenta se prazni brzinom r,
– a popunjava samo brzinom x < r.
• Prije ili kasnije,
– bafer klijenta će se potpuno isprazniti,
» pa će se u tom trenutku video
» zamrznuti na ekranu
– dok bafer klijenta čeka još tp sekundi
– da prikupi Q bita videa.

• Kada je raspoloživa brzina u mreži

– manja od brzine videa,
• emitovanje će naizmjenično
– imati periode kontinualnog reprodukcije
– i periode zamrzavanja.

• Sada ćemo odrediti tf,

– kada je bafer postaje pun.
• Primjetićemo da je sada x > r.
• U ovom slučaju,
– počevši od trenutka tp,
– bafer raste od Q do B,
» brzinom x - r,
– pošto se biti troše brzinom r,
– a pristižu (većom) brzinom x, kao što je prikazano na slici

• Reprodukcija počinje
– kada se u baferu nalazi Q bita.
• Vrijeme potrebno da se on popuni je Q/x sekundi
– U tom vremenu, na početku, nema reprodukcije!
– Bafer se ne prazni!
• Za popunjavanje dodatnih B-Q bita,
– potrebno je (B - Q)/(x - r) sekundi.
» Sada se bafer istovremeno i popunjava i prazni!
» Ali se popunjava većom brzinom
• Znači, ukupno vrijeme za popunjavanje bafera je
• tf = (Q/x) + (B - Q)/(x - r) sekundi

Prijevremeno prekidanje reprodukcije i
promjena pozicije u videu
• Sistemi za HTTP striming obično koriste
– HTTP zaglavlje za opseg bajtova
» HTTP byte-range header
• u HTTP poruci zahtijeva GET
– u kome se navodi određen raspon bajta
– koje klijent trenutno želi da preuzme
» iz željenog videa.
• Ovo je posebno korisno kada korisnik

– hoće da promijeni poziciju (tj. da preskoči)
» na kasnije mjesto u videu.

• Kada korisnik mijenja poziciju u videu,
– klijent šalje novi HTTP zahtjev,
– a u zaglavlju za opseg bajta naznačava
– od kojeg bajta u datoteci
– bi server trebalo da počne slanje podataka.
• Kada server primi taj novi HTTP zahtjev,

– on može da zaboravi prethodne zahtjeve i
– umjesto toga šalje podatke
– počevši od bajta navedenog
» u zahtjevu za opseg bajtova.

• Ogroman propusni opseg na internetu
– se nepotrebno troši
– zbog prijevremenog prekidanja,
» što nije baš jeftino
• Mnogi sistemi za striming

– koriste ograničene veličine bafera
» klijentske aplikacije ili
– ograničavaju količinu prethodno preuzetog videa
• Promjena pozicije u videu

– i prijevremeno prekidanje reprodukcije
– slični su obilnom obroku čiji se mali dio pojede,
– a ostatak baci,
» čime se rasipa hrana.

Prilagodljivi HTTP striming - DASH
• Ranije smo obradili

– UDP striming,
– odnosno HTTP striming.
• Treća vrsta striminga je

– dinamički prilagodljiv protok protokolom HTTP
– Dynamic Adaptive Streaming over HTTP - DASH,
» koji koristi više verzija videa,
» pri čemu se svaka komprimuje različitom brzinom.

• Mada se protok video zapisa

– korišćenjem protokola HTTP,
• svakodnevno izuzetno puno koristi
• on ima i svoje nedostatke:

– svi klijenti primaju video zapis
» kodovan na isti način,
– bez obzira na to što širina propusnog opsega
» nije uvijek ista

• Ovo je dovelo do razvoja novog tipa

– protokola za prenos video sadržaja
» koji se zasniva na protokolu HTTP,
– koji se naziva
– Dinamički prilagodljiv protok protokolom HTTP
» Dynamic Adaptive Streaming over HTTP -
DASH

• Za DASH, video zapis se kodira

– u nekoliko različitih verzija,
– pri čemu svaka verzija ima drugačiju bitsku brzinu
– i drugačiji nivo kvaliteta.
• Klijent dinamički zahtjeva odsječke video zapisa

– u trajanju od nekoliko sekundi.
• Kada mu je dostupna veća širina propusnog opsega,

– klijent prirodno bira odsječke
» iz verzije sa većom brzinom,
– a kada je širina propusnog opsega mala,
» bira iz verzije sa manjom brzinom.

• DASH omogućava da klijenti

– sa različitim brzinama pristupa intemetu
– preuzimaju video zapise
» kodovane različitim brzinama.
• Kada se koristi DASH, sve verzije video zapisa

– se čuvaju na HTTP serveru,
» pri čemu svaka ima drugačiju URL adresu.
• Na tom HTTP serveru se nalazi i

– datoteka manifest u kojoj su
» navedene URL adrese
» za sve postojeće verzije i njihove bitske brzine

• Klijent prvo zahtjeva datoteku manifest i

– na taj način saznaje
– koje sve različite verzije postoje.
• Poslije toga, klijent bira odsječke jedan za drugim

– navodeći njihove URL adrese
» i broj bajta za svaki odsječak
– u HTTP GET porukama zahtjeva
• DASH omogućava klijentima

– da slobodno prelaze
– između različitih nivoa kvaliteta video zapisa

Pregled

voice-over-IP
vremenu

Prenos glasa preko Interneta (VoIP)
• Za razgovor preko interneta

– u realnom vremenu
• često se kaže da je internet telefonija,
– pošto je sličan tradicionalnoj telefonskoj usluzi
» sa komutacijom kola.
• Takođe, uobičajeno se naziva i

– prenos glasa preko interneta
– Voice over IP – VoIP

Prenos glasa preko Interneta (VoIP)
• Opisaćemo principe i protokole

– na kojima počiva VoIP.
• Prenos videa tokom razgovora

– po mnogo čemu liči na VoIP,
» osim što uključuje i video učesnika
• Ovdje se usredsređujemo
– samo na razgovor,
» a ne na kombinaciju prenosa glasa i videa

Ograničenja IP usluge najboljeg pokušaja
• Protokol mrežnog sloja IP

– nudi uslugu najboljeg pokušaja.
• Ne garantuje pristizanje paketa na odredište

– unutar nekog ograničenog kašnjenja
– ni najveći procent izgubljenih paketa
• Ovo postavlja velike izazove

– pred projektante aplikacija za prenos govora
» u realnom vremenu,
– koje su krajnje osjetljive na
» kašnjenje paketa,
» promenljivo kašnjenje i
» gubitke
• Razmatraćemo nekoliko načina

– na koje se mogu poboljšati performanse
– VoIP aplikacija
– preko mreže sa uslugom najboljeg pokušaja
• Posmatramo rješenja koja

– ne zahtijevaju bilo kakve izmjene
– u jezgru mreže,

• Opisaćemo ograničenja
• IP usluge najboljeg pokušaja
– u slučaju određenog VoIP primjera
• Primjer:
• Pošiljalac generiše podatke brzinom od
– 8000 bajta u sekundi,
– a svakih 20 milisekundi
– pošiljalac prikuplja bajte u odsječke.

• Odsječak i posebno zaglavlje

» (opisano kasnije)
– enkapsuliraju se u UDP segment,
– preko poziva interfejsu soketa.
• Broj bajta u jednom odsečku iznosi

– (20 ms) • (8000 b/s) =
– 0.02•8000 =
– 160 bajta,
• a UDP segment se šalje svakih 20 ms.

• Ako svaki paket uspije da stigne do primaoca

– sa konstantnim kašnjenjem
» od kraja do kraja,
– onda paketi stižu do primaoca
» ravnomjerno
– svakih 20 ms.
• U tim idealnim uslovima,

– primalac može prosto
– da emituje svaki dio čim pristigne.

• Ali, na nesreću,
– neki paketi mogu da se izgube,
– a većina paketa nema isto kašnjenje
» od kraja do kraja,
– čak i u slabo zagušenom internetu.
• Iz tog razloga, primalac mora

– da vodi računa o tome
– da bi odredio
» (1) kada da emituje neki dio i
» (2) šta da uradi sa dijelom
• koji nedostaje.

Gubitak paketa
• Zamislite jedan od UDP segmenata

– koje je stvorila naša VoIP aplikacija.
• Taj UDP segment se

– enkapsulira u IP datagram.
• Dok datagram luta kroz mrežu,

– on prolazi kroz bafere u ruterima.
• Dešava se da jedan bafer ili više njih

– na putanji budu puni,
• U tom slučaju se pristigli IP datagrami odbacuju,

– pa nikad ne stignu u prijemnu aplikaciju.

Gubitak paketa
• Gubici bi mogli da se otklone

– slanjem paketa protokolom TCP
» pouzdan prenos podataka
– umjesto protokolom UDP.
• Međutim, za mehanizme za ponovni prenos

– često se smatra da su neprihvatljivi
– za prenos glasa u realnom vremenu,
» kao što je VoIP,
– zato što povećavaju kašnjenje od kraja do kraja

Gubitak paketa
• Pored toga, zbog TCP kontrole zagušenja,

– posljedica gubitaka paketa može da bude
– smanjivanje brzine prenosa TCP pošiljaoca
– na brzinu manju
» od brzine pražnjenja kod primaoca,
– što može da dovede
» do potpunog pražnjena bafera u aplikaciji.
• To može ozbiljno da utiče

– na razumljivost govora kod primaoca.
• Iz tih razloga, većina postojećih VoIP aplikacija

– podrazumijevano radi preko protokola UDP.

Gubitak paketa
• Međutim, gubitak paketa nije uvijek tako strašan

– kao što bi se moglo pomisliti.
• Zapravo, gubici paketa u opsegu

– od 1 procenta do 20 procenata
» mogu da se tolerišu,
– u zavisnosti od toga
» kako se govor koduje i prenosi
– i od toga
» kako se gubici maskiraju kod primaoca.
• Na primjer, ispravljanje grešaka unaprijed
– forward error correction – FEC
– može da pomogne u maskiranju gubitaka paketa.

Gubitak paketa
• Kada se koristi FEC,

– uporedo uz originalnu informaciju
» prenose se i redundantne informacije,
– pa neki od izgubljenih originalnih podataka
» mogu da se oporave iz tih redundantnih informacija.
• Ipak, ako su jedan ili više linkova

– između pošiljaoca i primaoca ozbiljno zagušeni,
» a gubitak paketa premašuje 10 do 20 procenata
– tada stvarno ništa ne može da se uradi
» da bi se postigao prihvatljiv kvalitet zvuka

Kašnjenje od kraja do kraja
• Kašnjenje od kraja do kraja

• je zbir kašnjenja
– uslijed prenosa, obrade i čekanja u redu u ruterima;
» transmission, processing, and queuing delays
– kašnjenja uslijed prostiranja u linkovima,
» propagation
– kao i kašnjenja uslijed obrade u krajnjem sistemu
» end-system processing.

Kašnjenje od kraja do kraja
• Za aplikacije za razgovor u realnom vremenu,

– kašnjenja od kraja do kraja manja od 150 milisekundi
» slušalac uopšte ne primjećuje;
– kašnjenja između 150 i 400 milisekundi
» mogu da budu prihvatljiva,
– a kašnjenja koja prevazilaze 400 milisekundi
» mogu da onemoguće razgovor.
• Prijemna strana VoIP aplikacije će po pravilu

– zanemariti sve pakete
– koji kasne više od određenog praga,
» na primjer, više od 400 milisekundi.
• Drugim riječima, paketi koji kasne

– više od toga
– u stvari su izgubljeni.

Neravnomjerno kašnjenje paketa
• Najvažniji dio kašnjenja od kraja do kraja

– jesu promjenljiva kašnjenja
» u redovima čekanja
• koja paket trpi u ruterima na mreži.
• Zbog ovih promjenljivih kašnjenja,

– vrijeme koje protekne
» od stvaranja paketa u izvoru
– dok ga primalac ne primi
» može da odstupa od paketa do paketa,
• Ova pojava se zove

– neravnomjerno kašnjenje
– jitter - džiter.

• Zamislite dva uzastopna paketa

– u našoj VoIP aplikaciji.
• Pošiljalac šalje drugi paket

– 20 ms kasnije, pošto je poslao prvi paket.
• Ali, kod primaoca,

– razmak između tih paketa
» može da bude veći od 20 ms.
• Kako?

• Pretpostavimo da prvi paket

– stiže u skoro prazan red na ulazu u ruter,
• ali baš prije nego što drugi paket stigne u red,
– u taj isti red stiže veliki broj paketa
» iz drugih izvora.
• Pošto prvi paket ima malo kašnjenje

» uslijed čekanja u redu,
– a drugi paket dugo čeka u redu tog rutera,
• razmak između prvog i drugog paketa
– je veći od 20 ms.

• Razmak između susjednih paketa

– može da bude i manji od 20 ms.
• Da biste to razumjeli,
– opet zamislite dva susjedna paketa.
• Pretpostavimo da prvi paket

– dolazi na kraj reda čekanja
» u kome je veliki broj paketa,
– a da drugi paket stiže u red neposredno iza njega,
» a prije paketa koji potiču iz drugih izvora.

• Naša dva paketa će se naći

– u redu čekanja
– tačno jedan iza drugog.
• Ako je vrijeme potrebno

– da se paket pošalje na odlazni link rutera
– manje od 20 ms,
– tada će razmak između prvog i drugog paketa
– biti manji od 20 ms.

• Ako bi primalac zanemario

– postojanje neravnomjernosti kašnjenja i
» emitovao dijelove čim stignu,
– onda bi dobijeni kvalitet zvuka
» mogao lako da postane nerazumljiv kod primaoca.
• Na svu sreću, neravnomjernost kašnjenja

• obično može da se ukloni korišćenjem
– rednih brojeva,
– vremenskih oznaka i
– odloženim emitovanjem

Uklanjanje neravnomjernog kašnjenja kod
primaoca zvuka
• Često je potrebno obezbjediti
– ravnomerno emitovanje odsečaka sa glasom
• To se obično radi uporednim korišćenjem

– sljedeća dva mehanizma:
• (1) Stavljanje vremenske oznake

– ispred svakog odsječka.
• (2) Odlaganje reprodukcije odsječaka kod
primaoca.

primaoca zvuka
• Stavljanje vremenske oznake ispred svakog
odsečka.
– Pošiljalac označava sve odsječke
» vremenom kada je odgovarajući odsječak nastao.
• Odlaganje reprodukcije odsječaka kod primaoca

» mora da bude dovoljno dugo
» da se većina paketa primi prije vremena
• koje je predviđeno za njihovu reprodukciju.
» To odlaganje reprodukcije može da bude
• isto tokom čitave uspostavljene
– veze za prenos glasa,
• a može i da se prilagođava dok ta veza traje.

primaoca zvuka
• Sada ćemo objasniti
– kako ovi mehanizmi,
» kada se koriste zajedno,
– mogu da olakšaju ili čak odstrane
» posljedice neravnomjernog kašnjenja.
• Ispitaćemo dvije strategije za emitovanje:

– sa fiksnim odlaganjem reprodukcije i
– sa prilagodljivim odlaganjem reprodukcije.

Fiksno odlaganje reprodukcije
• Kod strategije sa fiksnim odlaganjem,

– primalac pokušava da reprodukuje sve odsječke
– za tačno q ms
– nakon što je određeni odsječak generisan.
• Na taj način, ako pošiljalac vremenski označi

» neki odsječak u trenutku t,
– primalac reprodukuje taj odsječak
» u trenutku t + q,
– pod pretpostavkom da je odsječak
– stigao do tog vremena.
• Paketi koji stignu poslije vremena

– koje je predviđeno za njihovu reprodukciju
» odbacuju se i smatra se da su izgubljeni.

• Šta bi bio dobar izbor za q?

– Odnosno, kada treba početi reprodukciju?
• VoIP može da podrži kašnjenja

» do približno 400 ms,
– mada se bolji osjećaj pri razgovoru postiže
– sa manjim vrijednostima za q.
• S druge strane, ako je q mnogo manje od 400 ms,

– tada mnogi paketi mogu da
– ne stignu na vrijeme
» predviđeno za reprodukciju
– zbog neravnomjernog kašnjenja paketa koje unosi mreža.

• Na primjer,
• Ako su uobičajene velike promjene

– u kašnjenju od kraja do kraja,
• bolje je koristiti veće q;
• Ako je kašnjenje manje,

– a odstupanja u kašnjenjima takođe mala,
• bolje je koristiti manje q,
– čak manje i od 150 ms.

• Kompromis između odlaganja reprodukcije

– i gubitaka paketa prikazan je na slici
• Slika prikazuje
– vremena u kojima se paketi generišu i emituju.
• Razmatraju se dva različita

– početna odlaganja reprodukcije.

• Kao što je prikazano krajnje lijevim stepenicama,

– pošiljalac generiše pakete
– u pravilnim intervalima - recimo, svakih 20 ms.
• Prvi paket
– prima se u trenutku r.
• Dolasci sljedećih paketa
– nisu ravnomjerno raspoređeni zbog džitera
» (neravnomjernog kašnjenja u mreži).

• Za prvu reprodukciju,
– fiksno početno odlaganje reprodukcije
– postavljeno je na p - r.
• Za ovako emitovanje,
– četvrti paket ne stiže na vrijeme za
– i primalac smatra da je izgubljen.

• Za drugu reprodukciju,
– fiksno početno odlaganje reprodukcije
» postavljeno je na p' - r.
• Za ovakvu reprodukciju,
– svi paketi stižu prije vremena
» predviđenih za njihovu reprodukciju,
– pa zato nema gubitaka.

Prilagodljivo odlaganje reprodukcije
• U prethodnom primjeru
– prikazan je značaj kompromisa
– između odlaganja i gubitaka
– koji se javlja pri primjeni strategije
– reprodukcije sa fiksnim odlaganjem.
• Ako je početno odlaganje reprodukcije veliko,

» većina paketa će uspjeti da održi svoje rokove
– i zato će gubici biti zanemarljivi;
• Kod usluga prenosa govora, kao što je VoIP,

– velika kašnjenja mogu da budu neprijatna,
– ako ne i neprihvatljiva.
• Idealno, željeli bismo da odlaganje reprodukcije

– bude svedeno na najmanju mjeru
– uz ograničenje da gubici ostanu ispod nekoliko procenata.

• Prirodan način da se izađe na kraj

– sa kompromisom
» između odlaganja i gubitaka jeste
– da se procijene kašnjenje i
– promjene kašnjenja u mreži i
» da se na početku svakog govornog intervala
– odlaganje emitovanja
» podesi u skladu sa njima.

• Takvo prilagodljivo podešavanje

– odlaganja emitovanja
» na početku govornog intervala
» dovešće do toga da se
– periodi tišine
» smanje ili povećaju;
• Ipak, manji ili veći intervali tišine

– ako ih nema previše
– u razgovoru se ne primjećuju.

Oporavljanje od gubitaka paketa
• Podrobno smo opisali kako VoIP aplikacija

– može da se izbori sa
– neravnomjernim kašnjenjem paketa.
• Sada ćemo ukratko opisati

– više različitih šema
• koje se koriste da bi se
– u prihvatljivoj mjeri očuvao kvalitet zvuka
» kada postoje gubici paketa.

• Takve šeme se zovu

– šeme za oporavak od gubitaka.
• Ovdje gubitak paketa definišemo u širem smislu:

» paket se gubi ako uopšte ne stigne do primaoca
– ili ako
» stigne poslije predviđenog vremena za emitovanje.
• Naš primjer VoIP aplikacije

– opet će poslužiti kao kontekst
– za opisivanje šema za oporavak od gubitaka.

• Kao što je pomenuto na početku ovog odjeljka,

– ponovno prenošenje izgubljenih paketa
– nije pogodno za aplikacije za
– prenos govora u realnom vremenu
» kao što je VoIP.
• Zapravo, ponovno prenošenje paketa

– koji je propustio svoj rok za emitovanje
– nema apsolutno nikakvu svrhu.

• A ponovno prenošenje paketa koji je

– naišao na prepun red čekanja u ruteru
» obično ne može da se izvrši dovoljno brzo.
• Zbog toga, VoIP aplikacije često koriste

– neku vrstu šeme za očekivane gubitke.
• Dvije takve šeme su

– ispravljanje grešaka unaprijed (FEC) i
– preplitanje (interleaving).

Ispravljanje grešaka unaprijed (FEC)
• Osnovna zamisao sa FEC

» ispravljanjem grešaka unaprijed
– jeste da se originalnom protoku paketa
» dodaju redundantne informacije.
• Po cijeni neznatnog povećanja protoka,

– redundantne informacije mogu da se iskoriste
» kako bi se obnovile približne ili tačne
– verzije nekih izgubljenih paketa.

• Ovde ćemo opisati

– dva jednostavna FEC mehanizma.
• Prvi mehanizam šalje redundantni kodirani odsječak

– poslije svakih n odsječaka.
• Redundantni odsječak se dobija

– pomoću operacije isključivo ILI (XOR)
– nad n originalnih odsječaka.

• Na taj način, ako se izgubi bilo koji paket

– u grupi od n + 1 paketa,
– primalac može u potpunosti
» da obnovi izgubljen paket.
• Ali, ako se izgube dva ili više paketa u grupi,

– primalac ne može da obnovi izgubljene pakete.
• Ako se veličina grupe, n + 1,

– ograniči na male vrijednosti,
– veliki dio izgubljenih paketa
» može da se obnovi ukoliko gubici nisu pretjerani.

• Međutim, što je veličina grupe manja,

– to je veće relativno povećanje protoka.
• Tačnije, protok se povećava 1/n puta;

– na primjer, ako je n = 3,
» tada se protok povećava za 33 procenta.
• Pored toga, ova jednostavna šema

– povećava odlaganje reprodukcije,
» pošto primalac mora da sačeka
» dok ne primi cijelu grupu paketa,
– prije nego što počne sa reprodukcijom

• Drugi FEC mehanizam koristi mogućnost

– da se kao redundantna informacija
– šalje tok zvuka manje rezolucije.
• Na primjer, pošiljalac bi mogao da napravi

– nominalni tok zvuka i
– odgovarajući tok zvuka male rezolucije
» i male bitrate.
• Nominalni tok bi mogao da bude

– PCM kodiran pomoću 64 kb/s,
• a tok manjeg kvaliteta
– GSM kodiran pomoću 13 kb/s

• Tok male bitrate se zove

– redundantni tok.
• Kao što je prikazano na slici
– pošiljalac pravi n-ti paket
– tako što uzme n-ti odsječak iz nominalnog toka i
– na njegov početak doda (n - 1) po redu
» odsječak iz redundantnog toka.

• Na taj način,
– kad god se desi gubitak pojedinačnog paketa,
– primalac može da prikrije gubitak,
» tako što emituje taj odsječak
» kodiran malom bitratom
» koji stiže sa slijedećim paketom.

• Naravno, odsječci manje bitrate

– daju niži kvalitet od nominalnih dijelova.
• Međutim, tok koji se pretežno sastoji
– od odsječaka visokog kvaliteta,
» sa povremenim odsečcima nižeg kvaliteta,
– a bez nedostajućih odsečaka,
» daje dobar ukupan kvalitet zvuka.

• Da bi se smanjio uticaj uzastopnih gubitaka,

– možemo da koristimo jednostavnu
– varijaciju predložene metode.
• Umjesto da nominalnom n-tom odsječku
– na početak pridoda samo (n - 1) odsječak male bitrate,
– pošiljalac može na početak da pridoda
– (n -1) i (n - 2) odsječak male bitrate,
» ili da pridoda više npr. i (n - 3) odsječaka

Preplitanje
• Kao zamjenu za prenos redundantnih informacija,

– VoIP aplikacija može da šalje isprepleten zvuk.
– pošiljalac preuređuje jedinice
– zvučnih podataka prije prenosa,
• tako da su prvobitno susjedne jedinice
– donekle razdvojene u toku koji se prenosi.
• Preplitanje može da ublaži posljedice gubitaka paketa.

Preplitanje
• Ako je, na primjer,

• zvuk podijeljen na jedinice i odsječke i
• ako su jedinice dužine 5 ms, a odsječci 20 ms
– (odnosno četiri jedinice po odsječku),
• onda bi prvi odsječak mogao da sadrži
– jedinice 1, 5, 9 i 13;
• drugi odsječak bi mogao da sadrži
– jedinice: 2, 6, 10 i 14 itd.

Preplitanje
• Na slici pokazuje se da
• gubitak jednog paketa iz prepletenog toka
– dovodi do više malih procjepa
– u oporavljenom toku,
• za razliku od jednog velikog procepa
– koji bi se pojavio u neprepletenom toku.

Preplitanje
• Preplitanje može značajno da

– poboljša kvalitet zvučnog toka
• Očigledan nedostatak preplitanja
– je to što povećava kašnjenje.
• To ograničava njegovu upotrebu

– u aplikacijama za prenos govora,
» kao što je VoIP,
– mada može dobro da radi
» za striming uskladištenog zvučnog signala.
• Glavna prednost preplitanja je

– to što ne povećava zahtjeve za propusnim opsegom.

Maskiranje grešaka
• Šemama za maskiranje grešaka

– pokušava se da se napravi
– zamjena za izgubljeni paket
– koja je slična originalu.
• To je moguće zato što zvučni signali,

– a govor posebno,
– imaju dosta kratkotrajnih
» sličnih odsječaka.

Maskiranje grešaka
• Kao takve,
– tehnike zamjena za izgubljeni paket
• uspješno rade
– kod relativno malih gubitaka
» (manjih od 15 procenata)
– i malih paketa
» (4-40 ms).
• Kada se dužina gubitka približi

– dužini pojedinih fonema (5-100 ms),
» te tehnike ne uspijevaju,
» zato što slušaocu mogu da promaknu cijeli fonemi.

Maskiranje grešaka
• Ponavljanje paketa je
– možda najjednostavniji oblik
– oporavka na strani primaoca.
• Ponavljanjem paketa, izgubljeni paketi

– se zamjenjuju kopijama paketa
– koji su stigli neposredno prije gubitka.
• Rješenje računarski nije složeno

– i funkcioniše prilično dobro.

Maskiranje grešaka
• Drugi oblik oporavka na strani primaoca

– jeste interpolacija,
» koja na osnovu zvuka prije i posle gubitka,
– interpolira signal između njih
» i tako pokriva gubitak.
• Interpolacija radi nešto bolje

– od ponavljanja paketa,
– ali je značajno zahtijevnija
» što se tiče izračunavanja

Pregled

voice-over-IP
vremenu

Protokoli za aplikacije za razgovor u realnom
vremenu
• Aplikacije za razgovor u realnom vremenu,
– uključujući VoIP i video konferencije,
– neizbježne su i veoma popularne.
• Zato ne iznenađuje to što su

– organizacije za standardizaciju,
» kao što su IETF i ITU,
– radile godinama (i još uvijek rade)
– na stvaranju standarda za ovu klasu aplikacija
• U ovom odjeljku ispitaćemo

– protokole RTP i SIP
» za aplikacije za razgovor u realnom vremenu.

RTP Real-time Transport Protocol
• RTP može da se koristi

– za prenos uobičajenih formata
– kao što su PCM, ACC i MP3 za zvuk i
– MPEG i H.263 za video.
• On takođe može da se koristi i

– za prenos posebnih zvučnih i video formata.
• Danas se RTP puno koristi u brojnim proizvodima i

– istraživačkim prototipovima.
• On je takođe komplementaran
– sa drugim značajnim protokolima
– za interaktivni prenos u realnom vremenu,
– kao što je SIP - Session Initiation Protocol.
Osnove RTP protokola
• RTP, po pravilu,
– radi preko protokola UDP.
• Predajna strana enkapsulira

– odsječak medijuma u RTP paket,
– zatim taj paket enkapsulira
» u UDP segment i
– taj segment predaje protokolu IP.
• Prijemna strana izdvaja RTP paket

» iz UDP segmenta,
– zatim izdvaja odsječak medijuma
» iz RTP paketa i taj odsječak
– prosleđuje programu za reprodukciju
» koji ga dekodira i prikazuje.

• Kao primjer, razmotrimo korišćenje

– protokola RTP za prenos glasa.
• Pretpostavimo da je izvor glasa

– kodiran PCM modulacijom
» (odnosno uzorkovan, kvantizovan i digitalizovan)
– na 64 kb/s.
• Zatim, pretpostavimo da aplikacija

– prikuplja kodirane podatke
» u odsječke od po 20 ms,
– odnosno 160 bajta u odsječku.

• Predajna strana
– ispred svakog odsječka audio podataka
• stavlja RTP zaglavlje
– koje obuhvata vrstu audio kodiranja,
– redni broj i
– vremensku oznaku.
• RTP zaglavlje
– uobičajeno ima 12 bajta.

• Zvučni odsječak zajedno sa RTP zaglavljem

– sačinjava RTP paket.
• RTP paket se zatim šalje
– na interfejs UDP soketa.
• Na prijemnoj strani,
– aplikacija prima RTP paket
– iz interfejsa svog soketa.
• Aplikacija izdvaja zvučni odsječak

» iz RTP paketa
– i koristi polja zaglavlja RTP paketa
– za ispravno dekodiranje i reprodukciju
» zvučnog odsečka.

• Ako neka aplikacija za opis

– vrste podataka,
– rednih brojeva,
– ili vremenske oznake
• koristi RTP – umjesto sopstvene šeme –
– tada ta aplikacija može bolje
– da sarađuje
» sa drugim umreženim
» multimedijalnim aplikacijama.

• Na primjer, ako dvije različite kompanije

– razvijaju softver za VoIP
» i obe koriste RTP za svoje proizvode,
– postoji nada da će korisnik
» koji upotrebljava jedan od VoIP proizvoda
– moći da komunicira
– sa korisnikom
» koji upotrebljava drugi VoIP proizvod.
• Vidjećemo da se RTP često koristi

– uporedo sa protokolom SIP,
» Session Initiation Protocol
– koji predstavlja važan standard za internet
telefoniju.
• RTP ne nudi
– bilo kakav mehanizam kojim bi osigurao
» pravovremenu isporuku podataka ili
– ponudio druge garancije za kvalitet usluge
» quality-of-service - QoS

• RTP dopušta da se svakom izvoru

» (na primjer, kameri ili mikrofonu)
– dodjeli sopstveni nezavisni RTP tok paketa.
• Na primjer, za video konferenciju

– između dva učesnika
– moglo bi da se otvori četiri RTP toka –
– dva za slanje zvuka
» (po jedan u svakom smjeru)
– i dva toka za prenos videa
» (opet, po jedan u svakom smjeru).

• Međutim, mnoge popularne tehnike

kodovanja –
– uključujući tu MPEG 1 i MPEG 2 –
– u procesu kodovanja stavljaju
– zvuk i video u isti tok.
• Kada program za kodiranje

– stavi zvuk i video zajedno,
– onda se u svakom smjeru
– generiše samo jedan RTP tok.

Polja u zaglavlju RTP paketa

– četiri glavna polja u zaglavlju RTP paketa
– su polja za tip korisnih podataka,
– redni broj,
– vremensku oznaku i
– identifikator izvora.

• Polje za tip korisnih podataka (payload type)

• u RTP paketu
– ima dužinu od 7 bita.
• Za zvučni tok,
– polje za tip korisnih podataka
– služi da ukaže koji se način kodiranja za zvuk koristi
» na primjer,
• PCM,
• prilagodljiva delta modulacija,
• linearno prediktivno kodiranje)

• Ako pošiljalac odluči

– da promijeni kodiranje u toku sesije,
– on može da obavijesti primaoca o toj promijeni
– kroz ovo polje (payload type) za tip korisnih podataka.
• Pošiljalac može da promijeni kodiranje
– da bi povećao kvalitet zvuka
– ili da bi smanjio brzinu RTP toka.

• Za video tok,
– tip korisnih podataka
– se koristi da se naznači
– način video kodovanja
» (na primjer, motion JPEG, MPEG 1, MPEG 2, H.261).
• I u ovom slučaju,
– pošiljalac može da promijeni
– video kodiranje tokom trajanja sesije.

• Polje za redni broj (sequence number).

• Polje za redni broj je
– dugačko 16 bita.
• Redni broj se povećava
– za jedan za svaki poslat RTP paket,
» a primalac može da ga upotrebi
» kako bi otkrio gubitke paketa
» i obnovio njihov redosled.

• Na primjer,
– ako prijemna strana aplikacije
– prima tok RTP paketa
– sa procjepom između rednih brojeva 86 i 89,
– onda primalac zna
» da nedostaju paketi 87 i 88.
• Primalac tada može da pokuša
– da prikrije izgubljene podatke.

• Polje za vremensku oznaku (timestamp).

• Polje za vremensku oznaku
– je dugačko 32 bita.
• Ono odražava trenutak sempliranja
– prvog bajta u RTP paketu podataka.
• Kao što smo vidjeli u prethodnom odjeljku,

– primalac može da upotrebi vremenske oznake
– da bi otklonio džiter
– koji je nastao u mreži
– i da bi obezbedio sinhrono emitovanje kod primaoca.

• Identifikator izvora sinkronizacije.

– synchronization source identifier – SSRC
• Dužina polja SSRC je 32 bita.
– Ono identifikuje izvor RTP toka.
• Po pravilu, svaki tok u RTP

– sesiji ima različit SSRC.
• To je broj koji izvor slučajno dodjeljuje
– kada se pokrene novi tok.
• Verovatnoća da dva toka dobiju
– isti SSRC veoma je mala.
• Ukoliko bi se to dogodilo, dva izvora biraju
– novu vrijednost za SSRC.


SIP- Session Initiation Protocol
• Protokol SIP
– Session Initiation Protocol –
– Protokol za započinjanje sesije
• je jednostavan je protokol otvorenog koda
– koji radi sljedeće:
• (1) Nudi mehanizme za uspostavljanje poziva

– preko IP mreže
» između pozivaoca i pozvanog.
– Omogućava pozivaocu da obavijesti pozvanog
» da želi da pokrene poziv.
– Omogućava učesnicima da se dogovore
» o kodiranju medijuma.
– Uz to, omogućava učesnicima
» da završe razgovor.

SIP- Session Initiation Protocol
• (2) Nudi mehanizme kojima

– pozivalac određuje
» trenutnu IP adresu pozvanog.
– Korisnici nemaju samo jednu, stalnu IP adresu
» zato što adrese mogu da im se dodjeljuju
• dinamički (korišćenjem DHCP) i
• zato što mogu da imaju više IP uređaja,
• od kojih svaki ima različitu IP adresu.
• (3) Nudi mehanizme za upravljanje pozivima,

– kao što je dodavanje novih tokova
» (medium streams) za vrijeme poziva,
– mijenjanje kodiranja za vrijeme poziva,
– pozivanje novih učesnika za vrijeme poziva,
– prenos poziva (call transfer)
– i zadržavanje (hold) poziva.
Uspostavljanje poziva do poznate IP adrese
• Pogledaćemo primjer.
• U ovom primjeru, Alisa je ispred računara i
– želi da pozove Boba,
» koji takođe radi na svom računaru.
• Alisin i Bobov računar su opremljeni
– softverom za pozivanje i primanje telefonskih poziva
– koji se zasniva na protokolu SIP.

• U ovom početnom primjeru,

– pretpostavićemo da Alisa zna IP adresu
» Bobovog računara.
• Na slici je prikazan
– postupak za uspostavljanje poziva koji SIP koristi.

• Na slici vidimo da SIP sesija počinje

– kada Alisa pošalje Bobu poruku INVITE,
» koja liči na HTTP poruku zahtjeva.
• Ta poruka INVITE šalje se
– protokolom UDP na dobro poznat port 5060 za SIP.
» (SIP poruke mogu da se šalju i protokolom TCP.)

• Poruka INVITE sadrži

– identifikator za Boba (bob@ 193.64.210.89),
– Alisinu trenutnu IP adresu,
– naznaku da Alisa želi da prima zvuk
» koji će biti kodiran u formatu AVP 0
• (PCM kodiran µ-law tehnikom)
– i enkapsuliran u RTP, kao i
– naznaku da ona želi da prima RTP
» pakete na portu 38060.

• Kada primi Alisinu poruku INVITE,

– Bob šalje SIP poruku odgovora,
– koja liči na HTTP poruku odgovora.
» Ta SIP poruka odgovora se takođe šalje
• na SIP port 5060.
• Bobov odgovor sadrži 200 OK,
– kao i njegovu IP adresu,
– njegovo željeno kodiranje i
– kao i njegov broj porta na koji bi
» audio paketi trebalo da se šalju.

• Obratite pažnju na to da će u ovom primjeru

– Alisa i Bob koristiti različite mehanizme
» za kodiranje zvuka:
– od Alise se traži
» da koduje svoj zvuk u formatu GSM,
– dok se od Boba traži
» da koduje svoj zvuk
• u formatu PCM
• korišćenjem µ-law tehnike

• Pošto primi Bobov odgovor,

– Alisa mu šalje SIP poruku potvrde (ACK).
• Nakon ove SIP transakcije,
– Bob i Alisa mogu da razgovaraju.
– na slici je prikazano da Alisa govori poslije Boba,
» ali u stvarnosti oni mogu normalno da govore u isto vrijeme.

• Bob će kodirati zvuk i praviti pakete

» kao što se zahtijeva i slati te pakete
– na port broj 38060
– na IP adresu 167.180.112.24.
• Alisa će takođe kodirati zvuk i praviti pakete
» kao što se zahtijeva i slati te pakete
– na broj porta 48753 na IP adresu 193.64.210.89.

• U ovom primjeru razmotrićemo

– šta bi se dogodilo ako Bob nema
– PCM µ-law kodek za kodiranje zvuka.
• U tom slučaju, umjesto da odgovori sa 200 OK,
– Bob bi vjerovatno odgovorio sa 600 Not Acceptable
– i porukom sa listom svih kodeka koje može da koristi.
• Alisa bi zatim odabrala jedan od kodeka sa liste

– i poslala drugu poruku INVITE,
– navodeći kodek koji je sada izabrala.
• Bob bi takođe mogao prosto da odbije poziv,

– poslavši jedan od mnogih mogućih kodova za odbijanje
– „busy” (zauzet), „gone” (nije tu), „payment required” (zahtijeva se
plaćanje) i „forbidden” (zabranjeno).

SIP adrese
• U prethodnom primjeru, Bobova SIP adresa je:

– sip:bob@193.64.210.89.
• Međutim, ljudima je prihvatljivije da većina - ako ne i sve –
– SIP adrese liči na adrese e-pošte.
• Na primjer, Bobova adresa bi mogla da bude:

– sip:bob@domain.com.
• Kada Alisin SIP uređaj pošalje poruku INVITE,
– u njoj bi bila ova adresa koja liči na adresu e-pošte;
• SIP infrastruktura bi zatim usmjerila

– odgovarajuću poruku na IP uređaj koji Bob trenutno koristi
• Drugi mogući oblici SIP adresa mogli bi da budu

– Bobov običan broj telefona ili
– samo Bobovo ime/srednje ime/prezime

SIP adrese
• Zanimljiva osobina SIP adresa je

– da one mogu da se stave na veb stranice
• Na primjer, pretpostavimo da Bob

– ima svoju veb stranicu i da želi
– da ponudi način na koji posetioci
– njegove veb stranice mogu da ga pozovu.
• Onda bi mogao jednostavno da ubaci
– URL adresu: sip:bob@domain.com.
• Kada posetilac izabere taj URL,

– pokreće se SIP aplikacija
» na uređaju posetioca
– i Bobu se šalje poruka INVITE.

SIP poruke
• U ovom kratkom uvodu u SIP,

– nećemo objašnjavati sve vrste
» SIP poruka i zaglavlja.
• Umjesto toga, ukratko ćemo razmotriti

– SIP poruku INVITE,
• Ponovo pretpostavljamo da Alisa želi

– da započne VoIP poziv ka Bobu,
» ali ovog puta Alisa zna
» samo Bobovu SIP adresu,
• bob@domain.com,
– a ne zna IP adresu uređaja koji Bob trenutno koristi.

SIP poruke
• U tom slučaju, njena poruka bi

– mogla da izgleda ovako:
INVITE sip:bob@domain.com SIP/2.0
Via: SIP/2.0/UDP 167.180.112.24
From: sip:alice@hereway.com
To: sip:bob@domain.com
Call-ID: a2e3a@pigeon.hereway.com
Content-Type: application/sdp
Content-Length: 885
c=IN IP4 167.180.112.24
m=audio 38060 RTP/AVP 0

SIP poruke
• Red INVITE sadrži verziju protokola SIP,

– kao kod HTTP poruke zahtjeva.
• Kad neka SIP poruka

– prođe kroz neki SIP uređaj
» (uključujući tu i uređaj iz koga ta poruka potiče),
– on priključuje zaglavlje Via,
» koje ukazuje na IP adresu tog uređaja.
INVITE sip:bob@domain.com SIP/2.0

Via: SIP/2.0/UDP 167.180.112.24
From: …
…

SIP poruke
• Poruka SIP sadrži

– red zaglavlja From (od) i
– red zaglavlja To (ka).
• Poruka obuhvata red Call-ID,
– koji jedinstveno identifikuje poziv
INVITE ...
...
From: sip:alice@hereway.com
Call-ID: a2e3a@pigeon.hereway.com
…

SIP poruke
• Zaglavlje sadrži i red Content-Type,

– u kojem se definiše format sadržaja SIP poruke.
• Poruka takođe sadrži red zaglavlja Content-Length,
– koji daje dužinu sadržaja poruke u bajtovima.
• Najzad, poslije znaka za kraj reda i znaka za prelazak u novi red,
– nalazi se sadržaj poruke.
– U ovom slučaju, sadržaj obezbjeđuje informaciju
– o Alisinoj IP adresi i
– tome kako Alisa želi da prima zvuk
INVITE ...
...
Content-Type: application/sdp
Content-Length: 885
c=IN IP4 167.180.112.24
m=audio 38060 RTP/AVP 0
…

Prevođenje imena i pronalaženje korisnika
• Ranije smo pretpostavili da Alisin SIP uređaj

– zna IP adresu na kojoj se može naći Bob.
• Ali, takva pretpostavka je sasvim nerealna,

– ne samo zato što se IP adrese
– često dinamički dodjeljuju pomoću DHCP servera,
– nego i zato što Bob može da ima
» više IP uređaja
• različite uređaje u stanu,
• na radnom mjestu i automobilu

• Pretpostavićemo da Alisa zna

– samo Bobovu adresu za e-poštu, bob@domain.com
» i da se ta ista adresa koristi za pozive
» koji se zasnivaju na protokolu SIP.
• U tom slučaju,
– Alisi je potrebno da dobije
– IP adresu uređaja
» koji korisnik bob@domain.com trenutno koristi.

• Da bi to otkrila, Alisa pravi poruku INVITE,

– koja počinje sa
» INVITE bob@domain.com SIP/2.0
– i šalje tu poruku na SIP proksi.

• Proksi uzvraća SIP odgovorom,

– koji može da sadrži IP adresu uređaja koji
» bob@domain.com trenutno koristi.
– Sa druge strane, odgovor može da sadrži
» IP adresu Bobovog sandučeta za govornu poštu
» ili URL adresu veb stranice
• koja kaže: „Bob spava. Ostavite me na miru!”.
• Rezultat može da zavisi od osobe
– koja je uputila poziv:

• Sada se vjerovatno pitate

– kako proksi server
– može da odredi
– trenutnu IP adresu za bob@domain.com.
• Da bismo odgovorili na to pitanje,

– trebalo bi da kažemo nekoliko riječi
– o još jednom SIP uređaju,
– SIP arhivaru (registrar), registar

• Svaki SIP korisnik

– ima pridruženi registar.
• Kad god korisnik pokrene
– SIP aplikaciju na nekom uređaju,
– aplikacija šalje registru
» SIP poruku registrovanja,
– čime ga obavještava o svojoj trenutnoj IP adresi.

• Kada Bob pokrene SIP aplikaciju

– na svom PDA uređaju,
– aplikacija šalje poruku sličnu ovoj:
REGISTER sip:domain.com SIP/2.0

Via: SIP/2.0/UDP 193.64.210.89
From: sip:bob@domain.com
Expires: 3600
• Dakle, samom sebi,

• sa IP adresom
• U polju VIA

• Registar (registrar) je sličan

– DNS serveru imena
• SIP registar prevodi nepromjenljive

– identifikatore ljudi
» (na primjer, bob@domain.com)
– u dinamičke IP adrese.
• SIP registri i SIP proksiji

– obično rade na istom računaru.

• Kako Alisin SIP proksi server

– dobija Bobovu trenutnu IP adresu?
• Proksi server jednostavno trebalo

– da proslijedi Alisinu poruku INVITE
– na Bobov registrar/proksi.
• Bobov registrar/proksi
– Zna tačnu Bobovu adresu ili
– Zna gdje se ona može naći.
• Pogledajte primjer na slijedećem slajdu:

• Primjer
• pogledajte sliku na kojoj korisnik jim@umass.edu,
– koji trenutno radi na 217.123.56.89,
– lijevo
• želi da započne razgovor koristeći VoIP
– (Voice over IP)
• sa korisnikom keith@upenn.edu,
– koji trenutno radi na 197.87.54.21.
– desno

• Preduzimaju se sljedeći koraci:

• (1) Jim (lijevo) šalje INVITE poruku
– SIP proksiju umass.edu
• (2) Proksi vrši DNS pretraživanje na

– SIP registru upenn.edu
» korisnik keith@upenn.edu,
» je kod njega bio registrovan

• (3) Pošto keith@upenn.edu

– više nije registrovan na upenn.edu
– registar upenn šalje odgovor preusmjeravanja,
– pokazujući da bi trebalo
– pokušati sa adresom: keith@nyu.edu (desno)
• (4) Proksi umass.edu šalje

– SIP INVITE poruku
– na registar nyu.edu.

• (5) Registar nyu.edu zna IP adresu

– korisnika keith@upenn.edu i
» prosljeđuje INVITE poruku
» računaru 197.87.54.21,
• na kome radi Keitov SIP klijent.

• (6 -8) SIP odgovor se šalje natrag

– kroz registre/proksije
– do SIP klijenta na 217.123.56.89.
• (9) Podaci se šalju direktno

– između dva klijenta.

• Opis protokola SIP

– bio je usmjeren na započinjanje poziva
– za pozive glasom.
• Pošto je SIP opšti signalni protokol

– za započinjanje i završavanje poziva,
» može da se upotrebi za video konferencije,
» kao i za veze za razmjenu tekstualnih poruka.
• U stvari, SIP je postao

– osnovni sastavni dio
– u mnogim aplikacijama za trenutne poruke.

Pregled

voice-over-IP
vremenu

Mrežna podrška za multimediju
• Do sada smo vidjeli

– kako brojni mehanizmi
» na aplikativnom sloju
– mogu da se koriste
» u multimedijalnim aplikacijama
– da bi se poboljšale performanse,
– pošto internet pruža samo jednu klasu
» usluge najboljeg pokušaja

• Postavlja se pitanje da li bi mreža

» a ne samo aplikacije
» ili infrastruktura na aplikativnom sloju
– mogla da ponudi mehanizme za isporuku
– multimedijalnih sadržaja.
• Odgovor je, naravno, „da”!

• Koriste se tri šira rješenja

– za pružanje podrške na nivou mreže
– za multimedijalne aplikacije
• (1) Što bolje korišćenje

– usluge najboljeg pokušaja.
• (2) Diferenciranje (razdvajanje)

– usluga.
• (3) Garantovanje kvaliteta usluge

– (QoS) po vezi

Dimenzionisanje mreža usluge najboljeg
pokušaja
• Teškoće u podršci multimedijalnim aplikacijama
– potiču od njihovih
– strogih zahtijeva za performansama
» malo kašnjenje paketa sa kraja na kraj,

» mala promjenljivost kašnjenja i
» mali gubici

pokušaja
• Prvi pristup za unaprjeđenje kvaliteta
– multimedijalnih aplikacija –
» pristup koji se obično koristi
– za rješavanje skoro svakog problema
– tamo gdje su resursi ograničeni –
» jeste da se „novac baci na problem”
» i tako se jednostavno
– izbjegne ograničenost resursa.

pokušaja
• U slučaju umreženih multimedija,
– to bi značilo da se obezbjedi
– dovoljan kapacitet linkova
» kroz čitavu mrežu tako da se zagušenje mreže,
» pa prema tome kašnjenje ili gubici paketa,
» nikad (ili bar veoma rijetko) ne dese.
• Uz dovoljan kapacitet linkova,

– paketi bi letjeli kroz današnji internet
– bez gubitaka ili kašnjenja u redovima čekanja.

pokušaja
• Pitanje koliki kapacitet bi trebalo da se obezbjedi
» mrežnim linkovima u datoj topologiji
– da bi se postigao potreban nivo performansi
» poznat kao obezbjeđivanje propusnog opsega
– bandwidth provisioning
• Još složeniji problem je

– projektovanje mrežne topologije
» gdje postaviti rutere,
» kako rutere međusobno povezati linkovima i
» kakav kapacitet dodijeliti linkovima,
• da bi se postigao potreban nivo performansi
• jeste problem projektovanja mreža koji se naziva
– dimenzionisanje mreže - network dimensioning

pokušaja
• Zašto to današnji internet ne postiže
– A mogao bi da podrži multimedijalni saobraćaj
– odgovarajućim nivoom performansi
– kada bi bio dimenzionisan
• Sa ekonomskog stanovišta,
– da li bi korisnici bili spremni
– da svojim posrednicima za internet usluge plate dovoljno?
• Pošto će putanja sa kraja na kraj

– između dvije multimedijalne krajnje tačke
– proći kroz mreže mnogih posrednika za internet usluge
• Postavlja se pitanje - sa organizacionog stanovišta,

– da li su ti posrednici spremni da sarađuju
– kako bi se osiguralo da putanja bude pravilno dimenzionisana ?

Obezbjeđivanje različitih klasa usluga
• Možda najjednostavnije unaprjeđenje današnje

– usluge najboljeg pokušaja je
• dijeljenje saobraćaja na klase,
– tako da se različitim klasama saobraćaja
– nude različiti nivoi usluga.
• (1) Na primjer, ISP bi mogao da nudi višu klasu usluge

– saobraćaju koji je osjetljiv na kašnjenje,
» kao što su VoIP ili telekonferencije
– i da za takvu uslugu naplaćuje više
» nego za elastični saobraćaj
» kao što su e-pošta ili HTTP.

Obezbjeđivanje različitih klasa usluga
• (2) Drugo rešenje je da ISP

– jednostavno nudi viši nivo usluge
– kupcima spremnim da plate više za bolju uslugu.
• Veći broj posrednika za internet usluge

– koji kućnim korisnicima nude pristup internetu
» preko ožičenih mreža
» ili preko mobilnih bežičnih mreža
– već primjenjuje takve nivoe usluga –
» tako da pretplatnici koji za usluge plaćaju više
» uživaju u boljim performansama
» od pretplatnika koji plaćaju manje.

Primeri za bolje razumevanje problema
• Na slici je prikazan jednostavan primjer mreže

– u kojoj su dva toka paketa aplikacija
– koji potiču sa računara H1 i H2
» u jednoj LAN mreži
– upućena do računara H3 i H4
» u drugoj LAN mreži.

• Ruteri u ove dvije LAN mreže

– su povezani pomoću linka od 1,5 Mb/s.
• Pretpostavimo da su brzine LAN mreža
– značajno veće od 1,5 Mb/s i
– pažnju usmjeravamo na izlazni red čekanja
» u ruteru R1.

• To je mjesto gdje će se pojaviti

– kašnjenja i gubici paketa ako zbirna brzina slanja
– H1 i H2 pređe vrijednost od 1,5 Mb/s
• Pretpostavimo dalje da audio aplikacija od 1 Mb/s
– na primjer, poziv glasom CD kvaliteta
» dijeli link od 1,5 Mb/s i
• zmeđu R1 i R2
– sa HTTP aplikacijom pretraživanja veba
» koja preuzima veb stranicu iz H2 u H4.

• Na internetu sa uslugom najboljeg pokušaja,

– audio i HTTP paketi
– se miješaju u izlaznom redu za čekanje u R1
• i prenose se (obično)
– prema redoslijedu dolaska (FIFO).
• Paketi sa veb servera
– mogli bi da napune red za čekanje,
– pa bi IP audio paketi ili previše kasnili ili se gubili

• Rješenje: mogli bismo dati strogi prioritet

– zvučnim paketima u redu rutera R1.
• Tada bi HTTP saobraćaj koristio link od R1 do R2
– samo ako u redu za čekanje nema audio saobraćaja
• Svaki paket mora da bude označen

– da pripada nekoj od te dvije klase saobraćaja
• To je bio prvobitni cilj
– polja za vrstu usluge (ToS) u protokolu IPv4.

• Zapažanje 1:
• Označavanje paketa omogućava
– da ruter razlikuje pakete koji
– pripadaju različitim klasama saobraćaja.

• Pretpostavimo da je ruter konfigurisan

– tako da obezbijedi prioritet
– paketima označenim da pripadaju audio aplikaciji
– od 1 Mb/s.
• Pošto je brzina odlaznog linka 1,5 Mb/s
– i pored toga što HTTP paketi imaju niži prioritet,
– oni će ipak, u prosjeku, dobijati 0,5 Mb/s usluge prenosa.

• Ali, šta se dešava ako audio aplikacija

– počne da šalje pakete brzinom od 1,5 Mb/s ili većom
– zlonamjerno ili zbog greške u aplikaciji?
• U tom slučaju, HTTP paketi će biti zakočeni,

– odnosno neće dobiti nikakvu uslugu na linku
• Slični problemi bi se pojavili ako bi više aplikacija

– sa istom klasom usluge kao ta audio aplikacija,
– dijelile propusni opseg linka

• Zapažanje 2:
• Poželjno je obezbjediti neki stepen izolacije
– između klasa saobraćaja,
» tako da jedna klasa ne trpi
– negativan uticaj druge klase saobraćaja
» koja se loše ponaša.

Garancije kvaliteta usluge po vezi: rezervacija
resursa i prihvatanje poziva
• Ispitaćemo nekoliko mehanizama
– za obezbeđivanje te izolacije
– između klasa saobraćaja.
• Napominjemo da mogu da se
– primjene dva opšta rešenja.
• Prvo, može da se vrši

– (1) nadgledanje saobraćaja (traffic policing),
– (2) izolacija između klasa

• Ako neka klasa ili tok saobraćaja
– moraju da ispune određene kriterijume
» na primjer, da audio tok
» ne prelazi graničnu brzinu od 1 Mb/s,
– onda može da se uspostavi mehanizam za nadgledanje
– koji osigurava da se ti
» kriterijumi zaista primjenjuju.

• Ako se nadgledana aplikacija loše ponaša,
– mehanizam za nadgledanje
» će preduzeti neku mjeru
– tako da se saobraćaj
» koji ulazi u mrežu reguliše
– u skladu sa odgovarajućim kriterijumima.

• Mehanizam „bušne kofe”,
– možda je najšire korišćen mehanizam za nadgledanje.
• Na slici
– mehanizam za klasifikaciju i označavanje paketa
» (marking, zapažanje 1)
– i mehanizam za nadgledanje
» (policing, zapažanje 2)
– zajedno su smješteni na obod mreže,
» bilo u krajnjem sistemu,
» bilo u ruteru na obodu mreže.

• Rješenje kojim se obezbjeđuje izolacija
– između klasa saobraćaja
• jeste da se mehanizam za raspoređivanje paketa
– na sloju veze
• dopuni tako da svakoj klasi saobraćaja
– posebno dodjeljuje fiksnu količinu propusnog opsega linka.

• Na primjer, na R1 bi audio klasi
• moglo da se dodijeli
– 1 Mb/s, a HTTP klasi 0,5 Mb/s.

• U ovom slučaju,
• audio i HTTP tok
• vide logički link
– sa kapacitetom od
– 1,0 Mb/s, odnosno
– 0,5 Mb/s,
» kao što je prikazano na slici

• Uz strogu primjenu
– dodjeljivanja propusnog opsega na sloju veze,
• klasa može da koristi
• samo onu količinu propusnog opsega
– koja joj je dodijeljena;
– drugim riječima,
» ne može da koristi propusni opseg
» koji trenutno ne koriste druge klase.

• Zapažanje 3:
• Prilikom izolovanja klasa i tokova,
– poželjno je da se resursi
» na primjer, propusni opseg i
» privremene memorije linka
– koriste što je moguće efikasnije.

Probušena kofa
• Jedno od prethodnih zapažanja bilo je da

– je nadgledanje i upravljanje brzinom
» kojom se klasi ili toku dozvoljava da ubacuje pakete
– u mrežu važan QoS mehanizam.
• Međutim, koje elemente koji utiču na brzinu

– toka paketa bi trebalo nadgledati?
• Prepoznaju se
– tri važna kriterijuma za nadgledanje

Probušena kofa
• (1-a) Prosječna brzina (average rate).

• Ponekad želimo da ograničimo
– dugoročnu prosječnu brzinu
» (broj paketa u nekom periodu)
» kojom paketi toka mogu da se šalju u mrežu.
• Ovdje je najvažnije pitanje vremenskog intervala

– u kojem se nadgleda prosječna brzina.

Probušena kofa
• (1-b) Prosječna brzina (average rate).
• Tok čija je prosječna brzina ograničena

– na 100 paketa u sekundi
• ograničeniji je od izvora
– koji je ograničen na 6000 paketa u minutu,
» mada u dovoljno dugom vremenskom intervalu
» oba imaju istu prosječnu brzinu.
» ‚
• Ovo drugo ograničenje bi dozvolilo toku da pošalje
– 1000 paketa u datom intervalu od jedne sekunde,
• dok prvo ograničenje
– ne bi dozvolilo pošiljaocu da se tako ponaša.

Probušena kofa
• (2) Vršna brzina (peak rate).

• Dok ograničenje prosječne brzine
– ograničava količinu saobraćaja
» koji može da se pošalje u mrežu
» u relativno dugom periodu,
• ograničenje vršne brzine
– ograničava maksimalan broj paketa
» koji može da se pošalje u kraćem periodu.
• Koristeći gornji primjer,

– mreža može da nadgleda tok
– prosječne brzine od 6000 paketa u minutu,
• pri čemu vršnu brzinu toka
– ograničava na 1500 paketa u sekundi.

Probušena kofa
• (3-a) Veličina naleta paketa (burst size).

• Mreža takođe može da ograniči
– maksimalan broj paketa
» („nalet”, burst paketa)
– koji može da se pošalje u mrežu
• u izuzetno kratkom
– vremenskom intervalu.

Probušena kofa
• (3-b) U graničnom slučaju,

– kada dužina intervala teži nuli,
» burst size veličina ograničava broj paketa
• varijabla burst size
» koji mogu trenutno da se pošalju u mrežu.
• Iako je fizički nemoguće

– da se istovremeno šalje
» više paketa u mrežu
• svaki link ima maksimalnu fizičku brzinu prenosa
» apstrakcija maksimalne veličine naleta je korisna.

Probušena kofa
• Mehanizam bušne kofe je apstrakcija

– koja može da se upotrebi za opis
– ovih ograničenja nadgledanja.
• Kao što je prikazano na slici,
– bušna kofa podrazumijeva kofu
– koja može da primi do b žetona.

Probušena kofa
• Žetoni se dodaju u ovu kofu na slijedeći način.

• Novi žetoni koji bi mogli da se dodaju u kofu
– uvijek se stvaraju
– brzinom od r žetona u sekundi.
» Radi jednostavnosti, ovdje pretpostavljamo da je
» vremenska jedinica sekunda.
• Ako u kofi ima manje od b žetona kada se žeton napravi,
– onda se novostvoreni žeton dodaje u kofu;
– u suprotnom, on se zanemaruje,
» a kofa ostaje puna sa b žetona.

Probušena kofa
• Sada ćemo razmotriti

– kako bušna kofa može da se iskoristi
– za nadgledanje toka paketa.
• Pretpostavimo da paket ne može
– da se pošalje u mrežu
– dok prije toga ne uzme žeton iz kofe sa žetonima.

Probušena kofa
• Ako je kofa sa žetonima prazna,

– paket mora da čeka na žeton.
• Drugo rješenje je da se paket odbaci,

– mada tu opciju ovdje nećemo razmatrati.
• Hajde da sada razmotrimo kako ovo ponašanje

– nadgleda tok saobraćaja.

Probušena kofa
• Pošto u kofi može biti najviše b žetona,

» za tok koji se nadzire pomoću bušne kofe
– maksimalna veličina naleta
– može da bude b paketa.
• Pored toga, pošto je brzina stvaranja žetona r,
– maksimalan broj paketa
– koji može da uđe u mrežu
– u bilo kom vremenskom intervalu dužine t je rt + b.

Probušena kofa
• Prema tome, brzina stvaranja žetona, r,

– služi da se ograniči dugoročna prosječna brzina
» kojom paketi mogu da ulaze u mrežu.
• Bušne kofe
» posebno dvije zaredom
– takođe mogu da se koriste,
• pored nadgledanja dugoročne prosječne brzine toka
– i za nadgledanje vršne brzine toka.

Probušena kofa
• Podsjetićemo se
• Ponderisano (težinsko) ravnopravno čekanje (weighted fair
queuing, WFQ)
– u kome se izlazni link ravnopravno dijeli i
» zmeđu različitih veza sa kraja na kraj
» čiji paketi čekaju na prenos.
• Svakoj vezi se garantuje dio propusnog opsega
– Prema ponderu - težini (weight) wi.

Probušena kofa
• Bušna kofa i WFQ mogu zajedno da se iskoriste

– kako bi se ograničilo kašnjenje
– kroz red čekanja u ruteru.
• Razmotrimo izlazni link rutera
• koji multipleksira n tokova,
– od kojih se svaki nadgleda pomoću bušne kofe
– sa parametrima bi i ri i = 1,. .., n, koristeći WFQ raspoređivanje.
• Ovdje termin tok koristimo slobodnije,
– u značenju skupa paketa
» koje raspoređivač međusobno ne razlikuje.

Probušena kofa
• U praksi, tok bi mogao da se sastoji

– od saobraćaja jedne
» end-to-end veze
– ili skupa više takvih veza,
» kao što je prikazano na slici

Probušena kofa
• WFQ svakom toku i garantuje

– da će dobiti dio propusnog opsega linka
·
– jednak najmanje ∑
– gdje je R brzina prenosa linka u paketima po sekundi.
• Koliko je u tom slučaju maksimalno kašnjenje

– koje će paket iskusiti dok čeka na WFQ uslugu
» odnosno poslije prolaska pored bušne kofe?

Probušena kofa
• Usredsredimo se na tok 1.
• Pretpostavimo daje bušna kofa toka 1
– u početku puna.
• Nalet od paketa stiže
– do bušne kofe za tok 1.
• Ti paketi uzimaju sve žetone (bez čekanja)
– iz bušne kofe i pridružuju se
– WFQ baferu čekanja za tok 1.

Probušena kofa
• Pošto se b1 tih paketa opslužuje brzinom od

·
– najmanje ∑ paketa/sekundi,
• posljednji od tih paketa će u tom slučaju

– imati maksimalno kašnjenje, dmax,
» dok se njegov prenos ne završi, gde je:

• ·
∑

• Pogledajte slijedeći slajd za objašnjenje

Probušena kofa
• Objašnjenje na kojem se zasniva ova formula je da,

– ako postoji b1 paketa
» u redu za čekanje,
– a paketi se opslužuju (uklanjaju) iz tog reda
– brzinom od najmanje
·
» ∑ paketa u sekundi,
– onda vrijeme dok se i posljednji bit posljednjeg paketa
– ne prenese ne može biti veće od

• ·
.
∑



Diffserv
• Diffserv je specifična arhitektura koja

– nudi mogućnost razdvajanja (diferencijacije)
» usluga (servisa) na više nivoa
» (service differentiation-Diffserv)
• odnosno, mogućnost da se
• različite klase saobraćaja
– opslužuju na različite načine na internetu
– na prilagodljiv način.

Diffserv
• Potreba za prilagodljivošću
– nastaje iz činjenice da na backbone ruteru
» može da bude
– više miliona istovremenih tokova saobraćaja
» od izvora do odredišta.
• Ta se potreba zadovoljava tako

– što se unutar jezgra mreže
– obavlja samo dio potrebnih zadataka,
» dok se složenije kontrolne operacije
» primjenjuju na obodu mreže.

Diffserv
• Počećemo jednostavnom mrežom prikazanom na slici.

• Diffserv arhitektura sastoji se od
– dva skupa funkcionalnih elemenata:
– Funkcije na obodu:
» klasifikacija paketa i prilagođavanje saobraćaja.
– Funkcija jezgra:
» prosleđivanje.

Diffserv
• (1-a) Funkcije na obodu: klasifikacija paketa i

prilagođavanje saobraćaja.
• Na ulaznom obodu mreže
– odnosno, na računaru sa podrškom za Diffserv
» koji generiše saobraćaj
– ili na prvom ruteru sa podrškom za Diffserv
» kroz koji saobraćaj prolazi,
• dolazni paketi se označavaju.
• Tačnije rečeno, polje Differentiated Service (DS)
– u zaglavlju IPv4 ili IPv6 paketa
– postavlja se na neku vrijednost

Diffserv
• (1-b) Funkcije na obodu:

– klasifikacija paketa i prilagođavanje
saobraćaja.
• Polje DS namijenjeno je
– da zamjeni prethodna polja
– za vrstu usluge u IPv4
– i polja za klasu saobraćaja u IPv6,

Diffserv
• (1-b) Funkcije na obodu: klasifikacija paketa i prilagođavanje

saobraćaja.
• Na slici paketi koji se šalju od H1 do H3

– mogli bi da se označe u R1,
• dok bi paketi koji se šalju od H2 do H4
– mogli da se označe u R2.
• Oznaka koju paket dobija ukazuje
– na klasu saobraćaja kome on pripada.
• Različite klase saobraćaja će onda primiti
– različite usluge u jezgru mreže.

Diffserv
• (2-1)Funkcija jezgra: prosleđivanje.

• Kada paket označen sa DS stigne u ruter
» sa podrškom za Diffserv,
– on se prosljeđuje na svoj sljedeći skok
– u skladu sa takozvanim ponašanjem po skoku
» per-hop behavior – PHB
– koje je pridruženo toj klasi paketa.
• Ponašanje po skoku utiče na to
– kako se baferi rutera i propusni opseg linka
– dijele između raznih klasa saobraćaja
» koje se za njih nadmeću.

Diffserv
• (2-2)Funkcija jezgra: prosleđivanje.

• Glavno načelo arhitekture Diffserv
– jeste da će se ponašanje rutera po skoku
– zasnivati samo na označavanju paketa,
» odnosno na klasi saobraćaja kojoj paket pripada.
• Dakle, ako paketi koji se šalju od H1 do H3 na slici
» dobiju istu oznaku
– kao paketi koji se šalju od H2 do H4,
» onda mrežni ruteri postupaju sa tim paketima ravnopravno,
» bez razlikovanja da li potiču iz Hl ili H2.
• Na primjer, R3 ne bi pravio razliku
– između paketa iz H1 i H2
– kada ih prosleđuje na R4.

Diffserv
• Na slici je dat logički prikaz

– funkcija klasifikacije i označavanja
» u ruteru na obodu mreže.
• Paketi koji stižu u ruter na obodu mreže
– prvo se klasifikuju.
• Klasifikator bira pakete na osnovu vrijednosti

• u jednom ili više polja zaglavlja
– na primjer, adresa izvora, adresa odredišta,
– porta izvora, porta odredišta i ID protokola
• i usmjerava paket na odgovarajuću funkciju označavanja.
• Kao što je rečeno, oznaka paketa se drži

– u polju DS u zaglavlju paketa.

Diffserv
• U nekim slučajevima,
– krajnji korisnik se možda saglasio
» da ograniči brzinu slanja njegovih paketa
– tako da bude unutar deklarisanog profila saobraćaja.
• Profil saobraćaja može da sadrži

– ograničenje za vršnu brzinu,
– kao i za nalete (burst) u toku paketa,
» kao što smo već vidjeli kod mehanizma bušne kofe.

Diffserv
• Sve dok korisnik šalje pakete u mrežu

– na način koji odgovara
» dogovorenom profilu saobraćaja,
– paketi dobijaju označavanje
» koje odgovara njihovom prioritetu i
» prosljeđuju se na njihovu putanju do odredišta.

Diffserv
• S druge strane,
– ako se prekrši profil saobraćaja,
» paketi van profila
» mogu da se označe drugačije,
– da im se promijeni način proslijeđivanja
• (oblik-shape)
» na primjer, da se zadrže
• kako bi se poštovalo ograničenje
• maksimalne brzine,
» ili da se odbace na obodu mreže.

Diffserv
• Uloga funkcije mjerenja, prikazane na slici

– jeste da poredi tok dolaznih paketa
– sa dogovorenim profilom saobraćaja
– i da odredi da li je paket unutar tog profila.
• Stvarna odluka o tome da li će se nekom paketu
» odmah dodijeliti druga oznaka, da li će se
» proslijediti, zadržati ili odbaciti
– pitanje je pravila
– koje određuje administrator mreže
» i nije određena u arhitekturi Diffserv.

Diffserv
• Druga ključna komponenta Diffserv arhitekture

– obuhvata ponašanje po skoku (per-hop behavior - PHB)
» koje sprovode ruteri sa podrškom za Diffserv.
• Ponašanje po skoku je teže razumljivo,
– ali pažljivo definisano kao
– „opis spolja uočljivog ponašanja Diffserv čvora
– pri proslijeđivanju koje se primjenjuje
– na poseban skup Diffserv ponašanja”
• Definicija obuhvata nekoliko značajnih zapažanja:

Diffserv
• (1) Posledica PHB

• per-hop-behavior
– može da bude to da
» različite klase saobraćaja
» dobiju različite performanse
• odnosno da se prema njima različito ponaša
• pri prosleđivanju, što se može spolja uočiti.

Diffserv
• (2) Mada PHB definiše

» per-hop-behavior
– razlike u performansama između klasa,
• njime se ne propisuje
• nikakav poseban mehanizam
• za postizanje tih ponašanja.
– Sve dok su ispunjeni spolja vidljivi
» kriterijumi za performanse,
• može se koristiti bilo koji mehanizam
• kojim se to postiže
• (3) Razlike u performansama

– moraju da budu uočljive,
– pa samim tim i mjerljive.

Diffserv
• Definisana su dva ponašanja po skoku:

• (1) PHB
– sa ubrzanim proslijeđivanjem
• (2) i PHB
– sa garantovanim prosleđivanjem
• PHB sa ubrzanim proslijeđivanjem (expedited forwarding-EF)

– propisuje da brzina odlaska
» jedne klase saobraćaja iz rutera
– mora biti jednaka
» konfigurisanoj brzini ili veća od nje.
• PHB sa garantovanim proslijeđivanjem (assured forwarding - AF)

– dijeli saobraćaj na četiri klase,
» pri čemu se svakoj AF klasi
» garantuje neka minimalna količina propusnog opsega i bafera.

Diffserv
• Zaključci
• (1) Prećutno smo pretpostavljali

– da se Diffserv primjenjuje
» unutar jednog administrativnog domena,
– ali češće se dešava da
» ova usluga mora da se podesi
» između više posrednika za internet usluge
• Da bi se obezbjedila Diffserv usluga

– svi posrednici između krajnjih sistema
– moraju da obezbjede tu uslugu i da sarađuju!

Diffserv
• (2) Čak iako bi se Diffserv usluga uspostavila,

– a mreža radi samo pod osrednjim opterećenjem,
» u najvećem dijelu vremena
– ne bi se primjećivala razlika
» između usluge naboljeg pokušaja i
» Diffserv usluge.
• Potrebno je veće opterećenje da

– ova usluga pokaže svoje pravo lice!

• Kraj

Prezentacija 3

Uploaded by

Document Information

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

Prezentacija 3

Uploaded by

Copyright:

Available Formats

Napredne računarske mreže

Prof. Boris Damjanović

Boris Damjanović P 1.1

9.1 Multimedijalne mrežne aplikacije

Boris Damjanović P 1.2

• Za bilo koju mrežnu aplikaciju

• Razmotrićemo suštinske karakteristike

• Svaka klasa aplikacija u ovoj

Boris Damjanović P 1.3

• Najistaknutija karakteristika videa je

• Bitrate videa na internetu

• Ukratko ćemo razmotriti

• (1) Frenk, brzo lista fotografije

Boris Damjanović P 1.5

• (2) Marta preuzima muziku preko interneta

Boris Damjanović P 1.6

• (3) Viktor gleda video koji je

Boris Damjanović P 1.7

• Kompanija Cisco navodi da je

Boris Damjanović P 1.8

• Druga važna karakteristika videa je da

• Nekomprimovana digitalno kodirana slika

Boris Damjanović P 1.9

• (1) Prostorna redundantnost

• Slika koja se sastoji pretežno od bijelog prostora

Boris Damjanović P 1.10

• Ako su, na primjer, prethodna slika i sljedeća slika

• Umjesto toga, efikasnije je da se u kodiranju

Boris Damjanović P 1.11

• Što je bitrate (bitska brzina) veći,

Boris Damjanović P 1.12

• U zavisnosti od propusnog opsega

Boris Damjanović P 1.13

• Digitalni zvuk ima izvjesne osobine

• Pogledajmo najprije kako se analogni zvuk

Boris Damjanović P 1.14

• (1) Analogni zvučni signal se prvo uzorkuje

• Vrijednost svakog uzorka je

Boris Damjanović P 1.15

• (2) Svi uzorci se zatim zaokružuju

– Ova operacija se zove kvantizacija

– Broj takvih konačnih vrijednosti –

Boris Damjanović P 1.16

• (3) Svaka od kvantizacionih vrijednosti

• Ako se analogni zvučni signal semplira (uzorkuje)

Boris Damjanović P 1.17

• Za reprodukciju preko zvučnika,

• Međutim, dekodirani analogni signal

• Povećavanjem brzine uzorkovanja i

Boris Damjanović P 1.18

• Kvantizacija može da bude linearna,

• Na slici je prikazan signal koji je kvantizovan pomoću 4 bita,

Boris Damjanović P 1.19

• Kvantizacija može da bude nelinearna,

• Na primjer, grublja skala

• Najvažnije tehnike nelinearne kvantizacije su

Boris Damjanović P 1.20

• Tehnika kodiranja koju smo upravo opisali

– Za govor se često koristi PCM,

– Audio kompakt disk (CD) koristi PCM,

Boris Damjanović P 1.21

• Kodiranje PCM tehnikom

• Popularna tehnika kompresije

Boris Damjanović P 1.22