RTP - Srdjan Zezelj

7/29/2019 RTP - Srdjan Zezelj

1/22

Fakultet Tehnikih Nauka Novi sadSmer: Elektrotehnika i raunarstvoOdsek: Energetika, elektronika i telekomunikacijeUsmerenje: Telekomunikacije

PROJEKTNI ZADATAK

Protokol za prenos u realnom vremenu(engl. Real-time Transport Protocol, RTP)

Mentor Student:

dr Emil eerov Sran eelj, E10629

Novi Sad,Septembra, 2009. godine


2/22

Protokol za prenos u realnomvremenu SADRAJ

SADRAJ

1. Uvod ..................................................................................................... 22. Specifikacija scenarija upotrebe RTP .................................................. 3

2.1 Jednostavna viesmerna audio konferencija ................................... 3

2.2 Audio i video konferencija ............................................................. 32.3 Mikseri i prevodioci ...................................................................... 42.4 Kodiranje na nivou sloja ................................................................ 4

3. Definicije .............................................................................................. 54. RTP - Protokol transfera podataka ...................................................... 7

4.1 Fiksna polja RTP zaglavlja ........................................................... 74.2 Multipleksiranje RTP sesija ........................................................... 10

5. RTP Kontrolni protokol (RTCP) ....................................................... 115.1 Vrste paketa RTCP-a ..................................................................... 125.2 Izvetaji poiljaoca i primaoca ...................................................... 12

5.2.1 Izvetaj poiljaoca RTCP paketa .......................................... 12

5.2.2 Izvetaj primaoca RTCP paketa .......................................... 155.3 RTCP paket opisa izvora ............................................................... 165.3.1 Kanoniki identifikator krajnje take ................................... 165.3.2 Ime ......................................................................................... 175.3.3 Email ..................................................................................... 175.3.4 Telefon .................................................................................. 175.3.5 Geografska lokacija uesnika ................................................ 175.3.6 Ime aplikacije ili alatke ......................................................... 175.3.7 Beleka .................................................................................. 185.3.8 Privatni dodaci ..................................................................... 18

5.4 Odjavni RTCP paketi ..................................................................... 185.5 Aplikaciono-definisani RTCP paketi ............................................. 19

6. Literatura .............................................................................................. 21

1


3/22

Protokol za prenos u realnomvremenu UVOD

1. UVOD

Ovaj dokument opisuje protokol za prenos u realnom vremenu (engl. Real-time

Transport Protocol, RTP), koji omoguava servise sa kraja na kraj (engl. end-to-end) za

podatke sa karakteristikama realnog vremena, kao to su zvuk i video. Ovi servisi

ukljuuju identifikaciju podataka koji se prenose, broj sekvence, vremensku oznaku ipraenje dostave paketa. Aplikacije uglavnom pokreu RTP iznad UDP koji obezbeuje

multipleksiranje i proveru greke. Poto se izvrava u korisnikom prostoru i povezan je

sa aplikacijom, izvesno je da lii na protokol sloja aplikacija. S druge strane on je optiprotokol, nezavisan od bilo koje konkretne aplikacije, koji samo obezbeuje transportne

usluge, tako da lii na protokol transportnog sloja. Verovatno je najbolje smatrati ga

transportnim protokolom ugraenim u sloj aplikacija.Protokol za prenos u realnom vremenu je prvenstveno bio namenjen da zadovolji

potrebe multimedijskih aplikacija (internet telefonije, muzike na zahtev, video-

konferencija, videa na zahtev i dr.) ali on nije limitiran tom odreenom aplikacijom.Protokol za prenos u realnom vremenu takoe moe nai primenu u skladitenju

kontinualnih podataka, distribuciji interaktivnih simulacija kao i u aplikacijama kontrole imerenja.

Ovaj dokument opisuje RTP, sadran od dva vrsto povezana svoja dela:

- Protokol za prenos u realnom vremenu (RTP), prenos podataka sakarakteristikama realnog vremena.

- Protokol za upravljanje prenosom u realnom vremenu (engl. Real-time TransportControl Protocol, RTCP), koji povratno alje informacije, sinhronizuje tok iobezbeuje korisniko okruenje, ali ne prenosi podatke.

Kao dodatak ovom dokumentu, u cilju kompletne specifikacije RTP za odreenom

aplikaciju, neophodan je jedan ili vie prateih dokumenata:

- Dokumente specifikacije profila, koji definiu tipove i kodove koristnogtereta(engl. Payload) kao i njihovo mapiranje u formate koristnog tereta (engl.

Payload formats).

- Dokumente specifikacije formata koristnog tereta, koji definiu kako odreenikoristan teret, kao to su zvuk ili video kodovanje, treba preneti u RTP.

2


4/22

Protokol za prenos u realnomvremenu SPECIFI KACIJ A SCENARIJ A UPOTREBE RTP

2. SPECIFIKACIJA SCENARIJA UPOTREBE RTP

Sledei deo teksta opisuju neke aspekte primene RTP. Primeri su izabrani da

ilustruju osnovne operacije nad aplikacijama koje koriste RTP, ali ne i da ogranie

njegovu upotrebu. U ovim primerima, RTP je smeten iznad internet protokola (engl.

Internet Protocol, IP) i protokola za korisnike datagrame (engl. User Datagram Protocol,UDP), i prati usvojene konvencije profila za zvuk i video specificirane u RFC 3551.

2.1 Jednostavna viesmerna audio konferencija

Jednostavna viesmerna audio konferencija koristi usluge viesmernih IP servisainterneta za glasovnu (zvunu) komunikaciju. Kroz mehanizme dodele radne grupe, svaki

uesnik u viesmernoj konferenciji dobija adresu grupe i par portova. Jedan port se koristi

za prenos zvunih (audio) podataka, a drugi je kontrolni i koristi se za upravljanjeprenosom u realnom vremenu (RTCP). Informacija o adresi odnosno portu se distribuira

uesnicima u konferenciji. Ako se zahteva privatnost, podaci i kontrolni paketi mogu bitikodirani, a klju enkripcije generisan i prosleen namenjenim uesnicima konferencije.

Aplikacije uesnika konferencije alju male pakete od, recimo, 20ms trajanja.Svaki paketu audio podataka prethodi RTP zaglavlje; RTP zaglavlje i podaci su sadrani

u UDP paketu. U zaglavlju svakog RTP paketa su sadrane informacije o vrsti kodiranog

zvuka (PCM, ADPCM ili LPC), tako da poiljalac moe da menja vrstu kodiranja u tokukonferencije i prilagodi je slabo propusnom linku, tj. da reaguje na indicije zaguenja

mree. RTP zaglavlje sadri i vremenske informacije, odnosno informacije o rednom

broju sekvence, koja omoguava primaocu vremensku rekonstrukciju prispelih paketa injenu dalju reprodukciju na zvunik svakih 20ms.

Kako se lanovi ukljuuju i naputaju konferenciju, neophodno je u svakomtrenutku znati ko je prisutan i koliko dobro primaju audio podatke. U tu svrhu, aplikacija

svakog pojedinanog uesnika u konferenciji periodino viesmerno alje izvetaj o

primanju, i ime njenog uesnika na RTCP (kontrolnom) portu. Klijenti alju RTCP BYEpaket kada naputaju konferenciju.

2.2 Audio i video konferencija

Ukoliko su u konferenciji sadrani i zvuk i slika, oni se prenose u odvojenim RTP

sekcijama. Odvojeni RTP i RTCP paketi se prenose za svaki medijum korienjem

razliitih parova UDP porta i/ili viesmerne adrese. Na nivou RTP-a nema direktne sponeizmeu audio i video sekcije, osim to uesnik konferencije dodeljuje isto ime u RTP

paketu, zbog kasnijeg povezivanja i rekonstrukcije.

Jedna od motivacija za ovakvo razdvajanje je mogunost izbora, tj. prijema samojednog od medija od strane uesnika u konferenciji. Uprkos razdvojenosti u slanju RTP

paketa, sinhronizovana reprodukcija slike i zvuka od strane izvora se postie korienjem

vremenske informacije sadrane u RTCP paketu za obe sekcije.

3


5/22

Protokol za prenos u realnomvremenu SPECIFI KACIJ A SCENARIJ A UPOTREBE RTP

2.3 Mikseri i prevodioci

Do sada smo pretpostavili da svi sajtovi ele da primaju multimedijalne podatke u

istom formatu, meutim ovo nije uvek mogue.Pretpostavimo situaciju gde su korisnici

nisko propusne mree povezani sa uesnicima konferencije koji imaju visoko propusni

pristup. Umesto primoravanja da svi uesnici u konferenciji koriste niske brzine prenosa,odnosno smanjeni kvalitet zvuka, na strani nisko propusnog dela u RTP sloju se moe

smestiti mikser (engl. Mixer). Ovaj mikser resinhronizuje dolazee pakete da bi

rekonstruisao konstantnih 20ms razmaka generisanih od strane poiljaoca, mikserpovezuje ove pakete u jednu celinu, dekodira audio na nii propusni opseg, i takve nisko

propusne pakete odailje irom nisko propusnog linka.

Neki uesnici audio konferencije mogu biti povezani preko visoko propusnih

linkova, ali ne mogu biti dostupni preko viesmernog IP. Na primer, mogu biti iza

zatitnog zida(engl. Firewall) aplikacije koja ne dozvoljava prolaz IP paketa. U ovomsluaju su potrebne usluge drugo tipa sloja RTP-a, zvanog prevodilac (engl. Translator).

Prevodilac je smeten sa obe strane zatitnog zida. Spoljanji prevodilac tuneluje sveviesmerne pakete kroz sigurnosni zid aplikacije do unutranjeg prevodioca unutar

zatitnog zida koji ih ponovo elje kao viesmerne pakete zabranjene od straneunutranjosti mree sajta.

2.4 Kodiranje na nivou sloja

Multimedijalne aplikacije bi trebale da su u mogunosti da prilagode emitovanje

koje zadovoljava kapacitete primalaca ili da ih prilagodi mrei. Zbog konfliktnih zahtevaza propustni opsegom u viesmernim transmisijama esto dolazi do pojave da su svi

uesnici sesije ogranieni najuim propusnim opsegom korisnika u mrei.Umesto ovoga, odgovornost stope adaptacije prijema moe biti smetena na strani

primalaca kombinovanjem kodiranja na nivou sloja sa slojem sistema za transmisiju. U

kontekstu RTP-a preko viesmernog IP, izvor moe reprezentovati podatke preko viehijerarhijskih nivoa, tj. preko vie zasebnih RTP sesija prilagoenim razliitim propusnim

opsezima, noeni u okviru iste viesmerne grupe. U ovom sluaju primalac moe

pristupiti sesiji u okviru iste grupe koja je prilagoena njegovim mogunostima odnosno

njegovom propusnom opsegu.

4


6/22

Protokol za prenos u realnomvremenu DEFINICIJE

3. DEFINICIJE

Koristan teret RTP-a (engl. RTP Payload): Podaci transportovani putem RTP-a u

paketima, npr. audio sadraj ili video zapis.

RTP paket (engl. RTP Packet): Paket podataka koji se sastoji od fiksnog RTP zaglavlja,mogue prazne liste doprinosnih izvora i korisnog tereta.

Paket protokola za upravljanje u realnom vremenu (engl. RTCP Packet):Upravljaki paket koji se sastoji od fiksnog zaglavlja slian onome kod RTP paketa.

Tipino je da su vie RTCP paketa smeteni u jedan sabrani RTCP paket nieg protokola;

ovo je omogueno poljem duine fiksnog zaglavlja svakog RTCP paketa.

Transportna adresa (engl. Transport Address): Kombinacija mrene adrese i porta

koji identifikuje krajnju taku transportnog sloja, npr. IP adresa i UDP port,

Tip medija RTP-a (engl. RTP Media Type): Tip medija RTP-a je kolekcija korisnihtereta koji mogu biti transportovani u okviru jedne RTP sesije.

Multimedijalna sesija (engl. Multimedia Session): Set konkurentnih RTP sesija u

uobiajnoj grupi uesnika. Npr. video konferencija (koja je multimedijalna sesija) moe

sadrati Audio RTP sesiju u Video RTP sesiju,

RTP sesija (engl. RTP Session): U mutlimedijalnim sesijama, uglavnom je svaki

medijum transportovan u posebnoj RTP sesiji sa posebnim RTCP paketima, ukolikoprilikom kodiranja nisu multipleksirani mediji u jedan pojedinani tok. Jasna prednost

svake RTP sesije je to svaka sadri odvojene identifikatore sinhronizacionog izvora(engl. Synchronization Source, SSRC).

Sinhronizacioni izvor (engl. Synchronization Source, SSRC): Izvor toka paketa RTP-a, identifikovan 32-bitnim brojem sinhronizacionog izvora sadranim u RTP zaglavlju,

tako da je nezavisan od mrene adrese. Ako uesnik generie vie tokova sadraja u

jednoj RTP sesiji, npr. od vie odvojenih kamera, svaki mora biti identifikovan kao

razliiti sinhronizacioni izvor.

Dopunski izvor (engl. Contributing Source): Izvor toka RTP paketa koji je doprineo

stvaranju kombinovanog toka proizvedenog od strane RTP miksera. Mikser ubacuje listuSSRC identifikatora izvora koji su doprineli stvaranju odreenog paketa unutar RTP

zaglavlja tog paketa, pri emu se stvara lista dopunskih izvora. Npr. u audio konferenciji

gde mikser pokazuje sve iji je govor kombinovan da bi se kreirao izlazni paket,dozvoljavajui prijemniku da identifikuje trenutnog razgovaraa, ak i ako su svi audio

paketi sadrali isti identifikator sinhronizacionog izvora (onog na mikseru).

Krajnji sistem (engl. End System): Aplikacija koja kreira sadraj koji e biti poslat RTP

paketima ili koristi sadraj primljenih RTP paketa.

5


7/22

Protokol za prenos u realnomvremenu DEFINICIJE

Mikser (engl. Mixer): Umetnuti sistem koji prima RTP pakete od jednog ili vie izvora,

verovatno menjajui format podataka, kombinuje pakete i onda dalje prosleuje noviRTP paket. Iako vreme du vie izvornih taaka nee biti sinhronizovano, mikser e

napraviti vremensko podeavanje du tokova i generisari njegovo vreme kombinovanog

toka. Tako e svi paketi koji potiu iz miksera identifikovati mikser kao njihov

identifikazioni izvor.

Prevodilac (engl. Translator): Umetnuti sistem koji prosleuje RTP pakete sa njihovim

netaknutim sinhronizacionim izvorom. Primeri prevodilaca ukljuuju ureaje kojikonvertuju kodovan sadraj bez miksovanja, replikatori viesmernih tokova u

pojedinani, filtriranje u aplikacionim nivoima zatitnog zida.

Nadgleda (engl. Monitor): Aplikacija koja prima RTCP pakete poslate od strane

uesnika u RTP sesiji, izvetaje o dostavi i proraunava trenutni kvalitet usluge za

distribuirano nadgledanje, greke u dijagnostici i dugovene statistike. Funkcijenadgledanja su najee ugraene u aplikacije uesnika u sesiji, ali isto tako mogu biti

izvedene i kao aplikacije tree strane (engl. Third-party Monitors).

6


8/22

Protokol za prenos u realnomvremenu RTP - PROTOKOL TRANSFERA PODATAKA

4. RTP - PROTOKOL TRANSFERA PODATAKA

4.1 Fiksna polja RTP zaglavlja

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1V=2 D Z DI M

VRSTA KORISNOGTERETA

REDNI BROJ

VREMENSKA OZNAKA

IDENTIFIKATOR IZVORITA NAMENJEN ZA SINHRONIZOVANJE (SSRC)

IDENTIFIKATOR DOPUNSKOG IZVORITA (CSRC)....

Prvih dvanaest okteta su prisutni u svakom RTP zaglavlju dok je lista dopunski izvorita

prisutna samo ako je ubaena od strane miksera. Polja imaju sledea znaenja:

Verzija (V): 2 bita

Ovo polje identifikuje verziju RTP. Verzija definisana ovom specifikacijom jedva (2) .

Dopuna (D): 1 bit

Bit D oznaava da li je paket bio dopunjavan do umnoka od 4 bajta. Poslednjibajt dopune saoptava koliko je ukupno dodato bajtova.

Dodatno zaglavlje (Z): 1bit

Ukazuje da postoji dodatno zaglavlje. Ne definiu se njegov format i znaenje,ve samo to da njegova prva re oznaava duinu. Reenje za sluaj da se pojavezahtevi koje niko nije mogao unapred da predvidi.

Dopunski izvori (DI): 4 bita

Polje DI govori koliko ima dopunskih izvora, 0 do 15.

Marker (M): 1bit

Bit M je rezervisan za oznaku koju na to mesto postavlja aplikacija. Ona ga moeiskoristiti da oznai poetak okvira, poetak rei na audio kanalu ili neto tree tosamo ona razume.

7


9/22


Vrsta korisnog tereta: 7 bita

Vrsta korisnog tereta govori o upotrebljenom algoritmu (npr. nekomprimovani 8-bitni audio, MP3 i slino). Set mapiranja za audio i video je opisan u RFC 3515.Poto svaki paket ima ovo polje, tip korisnog tereta moe se menjati tokom

prenosa.Redni broj: 16 bita

Redni broj se inkrementira za jedan za svaki poslat RTP paket, i moe bitikorien od strane prijemnika za detekciju izgubljenih paketa i povratka rednogbroja sekvence. Inicijalna vrednost ovog polja trebala bi biti nasuminopostavljena (nepredvidljivo).

Vremenska oznaka: 32 bita

Izvorite treba da ozna

i prvi uzorak u svakom paketu. Vremensko uzorkovanjemora biti dostavljeno od sata koji se monotono i linearno poveava u vremenu, dabi omoguio sinhronizaciju i kalkulaciju ditera. Rezolucija sata mora bitidovoljana za eljenu preciznost sinhronizacije i za merenje ditera pristiglihpodataka. Frekvencija sata zavisi od formata podataka koji se prenose u korisnomtovaru i statiki je specificirana za dati profil u njegovoj specifikaciji, ili moe bitidinamiki odreena za Ne-RTP (engl. Non-RTP) pakete. Za RTP pakete koji superiodino generisani, nominolno uzorkovanje je odreeno satom nominalnoguzorkovanja koji je korien, a ne oitavanjima sistemskog sata. Kao primer, zafiksi-uzorkovani zvuk, sat vremenske oznake e se poveavati za jedan za svakiperiod odabira.Inicijalna vrednost vremenske oznake trbala bi biti nasumina, kao i za brojsekvence.Nekoliko uzastopnih RTP paketa e imati jednake vremenste oznakeako su (logino) genirasani odjednom, na primer, pripadaju istom kadru videa.Uzastopni RTP paketi mogu da sadre vremenske oznake koje nisu monotone,ako se podaci ne prenose u redosledu uzorkovanja, kao to je u sluaju MPEGinterpoliranih video frejmova.RTP vremenske oznake iz razliitih medijskih tokova (razliitih brzina) uglavnomsu nezavisne i imaju sluajan ofset. Stoga, iako su ove vremenske oznakedovoljne za rekonstrukciju toka pojedinanog medija, direktno uporeivanjevremenskih oznaka razliitih medijski tokova nije efikasno za sinhronizaciju.Umesto toga, za svaki medijum vremenska oznaka RTP paketa se gleda u odnosuna referentni sat (zidni sat, engl. wallclock) koji reprezentuje vreme kada supodaci sa odgovarajuom vremenskom oznakom uzorkovani.Trenutno uzorkovanje je izabrano kao referentna taka za vremensku oznaku RTPpaketa, jer je poznato da se prenosi, a krajnja taka je zajednika definicija za svemedije, nezavisno od kodiranja, kanjenja ili druge obrade.Cilj je da se dozvolisinhronizacija svih medija uzorkovanih u isto vreme.

8


10/22


SSRC: 32bita

SSRC polje identifikuje izvor sinhronizacije. Ovaj identifikator trebao bi bitinasumino biran, sa namerom da ne postoje dva izvora sinhronizacije unutar isteRTP sesije sa istim SSRC identifikatorom. Iako je mala verovatnoa izvora

sinhronizacije da izaberu isti identifikator, sve RTP implementacije moraju bitipripremljene da detektuju i ree koliziju.

CSRC lista: od 0 do 15 stavki, 32 bita svaka

CSRC lista identifikuje sve izvore koji su doprinelu nastajanju tovara sadranog upaketu. Broj identifikatora je dat u CC polju. Ako ima vie od 15 podrinosnihizvora, samo 15 moe biti identifikovano. CSRC identifikatori su umetnuti odstrane miksera, koristei SSRC polja doprinosnih izvora. Na primer, za audiopaket svi SSRC identifikatori izvorita su pomeani zajedno da bi se kreiralaCSRC lista, omoguavajui pritom identifikaciju govornika na prijemnoj strani.

4.2 Multipleksiranje RTP sesija

Za efikasno procesiranje protokola broj taaka multipleksiranja treba minimizirati,kao sto je opisano u principima obrade itegrisanih slojeva (10). U RTP-u,multipleksiranje je omogueno na osnovu odredine tranportne adresa (mrene adrese ibroja porta) koja je drugaija za svaku RTP sesiju. Na primer, u telekonferencijamasainjenih od audija i videa kodovanih posebno, svaki medijum treba nositi u odvojenojRTP sesiji sa njegovom zasebnom odredinom transportnom adresom.

Odvojeni audio i video tokove ne treba nositi u pojedinanoj RTP sesiji idemultipleksirati na osnovu tovara ili SSRC polja. Prepletanje paketa sa drugaijim RTPmedijskim tipom ali koristei isti SSRC e izazvati nekoliko problema:

1. Ako, dva audio toka dele istu RTP sesiju i isti SSRC, i jedan hoe dapromeni vrstu kodiranja i prema tome dodeljuje drugaiji tip RTP tovara,nee biti nikako mogue utvrditi koji od ova dva toka je promeniokodovanje.

2. SSRC je definisan da identifikuje pojedinaan razmak vremena i brojasekvence. Prepletanje vie tipova tovara zahteva drugaiji vremenskirazmak ako se tempo medijskog sata razlikuje i zahtevae drugaijirazmak broja sekvence da bi rekao koji tovar je pretrpeo gubitak paketa.

3. RTCP izvetaji poiljaoca i primaoca mogu opisati samo jedan razmakvremena i broja sekvence po SSRC i ne nose polje tipa tovara.

4. RTP mikser nee biti u mogunosti da kombinuje prepletane tokovenekompatibilnih medija u jedan tok.

9


11/22


5. Noenje vie tipova medija u jednoj RTP sesiji iskljuuje: upotrebudrugaijeg mrenog puta i alokaciju mrenih izvora; prijem podskupamedijskog toka, na primer, samo audija ako video prevazilazi propusniopseg mree; upotrebu razliitih procesa implementacije na razliitimmedijima od strane primaoca, dok upotreba odvojenih RTP sesija

dozvoljava jedan ili vie procesa implementacije.

Upotreba posebnih SSRC za svaki medijum i njihovo slanje kroz istu RTP sesijubi izbegla prva tri problema ali ne i poslednja dva.

U drugu ruku multipleksiranje vie povezanih izvora istog medija u jednu RTPsesiju koristei razliite SSRC vrednosti je norma za viesmerne sesije.

10


12/22

Protokol za prenos u realnomvremenu RTP - KONTROLNI PROTOKOL (RTCP)

5. RTP KONTROLNI PROTOKOL (RTCP)

RTP kontrolni protokol (RTCP) se zasniva na periodinoj transmisiji kontrolnihpaketa svim uesnicima u sesiji, koristei iste distributivne mehanizme kao i paketipodataka. Osnovni protokol mora da obezbedi multipleksiranje podataka i kontrolnih

paketa, na primer, koristei odvojene brojeve portova sa UDP. RTCP obavlja

etirifunkcije:

1. Primarna funkcija je da obezbedi povratne informacije o kvalitetu distribucijepodataka. To je sastavni deo uloge RTP-a kao transportnog protokola i odnosise na kontrolu funkcija toka i zaguenja drugih transportnih protokola.Povratne informacije mogu direktno biti korisne za kontrolu adaptivnogkodiranja, ali eksperimenti sa viesmernim IP su pokazali da je kritino dobitipovratnu informaciju od primaoca da bi se dijagnostikovale greke udistribuciji. Slanje povratnih izvetaja, svim uesnicima u mrei, dozvoljavaonome ko posmatra problem da proceni da li je on lokalnog ili globalnog

karaktera. Uz distributivni mehanizam, kao to je viesmerni IP, je mogue ida entitet kao to je mreni servisni provajder koji nije drugaije ukljuen u

sesiju da prima povratne informacije i da se ponaa kao nadgleda (tree lice),da bi diagnostikovao mreni problem. Ove povratne funkcije obavljaju se uzpomo RTCP-a poiljaoca i primaoca izvetaja.

2. RTCP nosi identifikator transportnog nivoa za RTP izvor koji se zovekanoniko ime ili CNAME. S obzirom da se SSRC identifikator moepromeniti ako je otkriven konflikt ili ako je program restartovan, primaocizahtevaju CNAME da bi pratili svakog uesnika. Primaoci takoe moguzahtevati CNAME da bi udruili vie tokova podataka od datog uesnika usetu povezanih RTP sesija, na primer, da bi sinhronizovali audio i video.Sinhronizacija izmeu media takoe zahteva NTP i RTP vremensku oznakusadranu u RTCP paketima poiljaoca.

3. Prve dve funkcije zahtevaju da svi uesnici alju RTCP pakete, dakle stopaposlatih RTCP paketa mora biti kontrolisana u cilju neoptereenja propusnogopsega u sluaju velikog broja uesnika. Ako svaki uesnik poalje svojkontrolni paket svima drugima, onda e svaki uesnik znati taan broj svihuesnika u mrei, i prema tom broju e se odreivati brzina kojom e se slatipaketi.

4. etvrta opcionalna funkcija je prenos minimalne koliine kontrolnihinformacija za datu sesiju, na primer, identifikacija uesnika na korisnikominterfejsu. Ovo bi verovatno bilo korisno u slabo kontrolisanom okruenju,gde uesnici mogu da uu i izau bez kontrole lanstva ili parametarapregovaraa. RTCP slui kao pogodan kanal za pristizanje do svih uesnika,ali se od njega nuno ne oekuje da podrava sve kontrolne zahteve kojepodrava aplikacija.

11


13/22


Funkcije 1-3 trebale bi biti koriene u svim okruenjima, a posebno uviesmernom IP-u. Dizajneri RTP aplikacija trebali bi izbegavati mehanizme koji radesamo u jednosmernom modu i ne mogu se prilagoditi veim razmerama. TransmisijaRTCP paketa opcionalno moe biti kontrolisana odvojeno za poiljaoca i primaoca, zasluajeve jednosmernih linkova gde povratna informacija od primaoca nije mogua.

5.1 Vrste paketa RTCP-a

SR: Izvetaj poiljaoca (engl. Sender Report), statistika prenosa i prijema svih uesnikakoji su aktivni poiljaoci.

RR: Izvetaj primaoca (engl. Receiver Report), za primanje statisktike uesnika koji nisuaktivni poiljaoci, i u kombinaciji sa SR za aktivno izvetavanje poiljaoca sa vie od 31izvora.

SDES: Stavke opisa izvora (engl. Source Description Items), ukljuujui CNAME.

BYE: Indicira kraj uea.

APP: Specifine funkcije aplikacije.

5.2 Izvetaji poiljaoca i primaoca

RTP primaoci obezbeuju povratni izvetaj o kvalitetu koristei RTP izvetajekoji mogu imati jednu od dve forme u zavisnosti da li je primalac ujedno i poiljaoc.Jedina razlika izmeu izvetaja poiljaoca (SR) i izvetaja primaoca (RR) u formi je toto izvetaj poiljaoca sadri dodatnih 20 bajta informacija za upotrebu od strane aktivnihpoiljalaca.

5.2.1 Izvetaj poiljaoca RTCP paketa (engl. Sender Report RTCP Packet, SR)

0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1V=2 P RC PT=SR=200 DUINA

SSRC POILJAOCANTP VREMENSKA OZNAKA, NAJZNAAJNIJI BIT

NTP VREMENSKA OZNAKA, NAJMANJE ZNAAJAN BITRTP VREMENSKA OZNAKA

BROJA PAKETA POILJAOCABROJA OKTETA POILJAOCA

SSRC_1 (SSRC PRVOG IZVORA)IZGUBLJENIH FRAKCIJA KUMULATIVAN BROJ IZGUBLJENIH PAKETANAJDUI NIZ PRIMLJENIH PAKETA

DITERPOSLEDNJA SR VREMENSKA OZNAKA

KANJENJE OD POSLEDNJEG SRSSRC_2 (SSRC DRUGOG IZVORA)

...SPECIFINA EKSTENZIJA PROFILA

12


14/22


Izvetaj poiljaoca sadri tri sekcije, sa mogunou da su praene i etvrtom sekcijomspecifinog profila. Prvi segment, zaglavlja, je 8 okteta dugaak. Polja imaju sledeeznaenje:

Verzija (V): 2 bita

Identifikuje verziju RTP-a, koja je ista u RTCP paketima kao i u RTP paketimapodataka. Verzija definisana ovim dokumentom je dve (2) .

Dopuna (D): 1 bit

Ako je bit dopune setovan (,,1), ovaj individualni RTCP paket sadri nekedodatne oktete dopuna na kraju koji nisu deo kontrolnih informacija, ali suukljueni u polje duine. Poslednji oktet dopune govori koliko okteta dopunetreba ignorisati, ukljuujui i sebe. Dopuna moe biti potrebna zbog algoritamakodiranja sa fiknom veliinom bloka.

Broja izvetaja prijema (BP): 5 bita

Broj blokova izvetaja prijema sadranih u ovom paketu. Moe biti i nula.

Tip paketa (TP): 8 bita

Sadri konstantu 200 koja identifikuje da je ovo RTCP izvetaj poiljaoca.

Duina: 16 bita

Duina ovog RTCP paketa u 32-bitnim reima minus jedna, ukljuujui zaglavljei bilo kakav dodatak.

SSRC: 32 bita

Identifikator izvorita namenjen za sinhronizovanje, koji se odnosi na poiljaoca.

Druga sekcija, informacije poiljaoca, je 20 okteta dugaka i prisutna je u svakomizvetaju poiljaoca. Ona rezimira prenos podataka poiljaoca. Polja imaju sledeeznaenje:

NTP vremenska oznaka: 64 bita

Oznaava vremensku referencu zidnog sata (engl. wallclock time) kada je ovajizvetaj poslat, i moe biti korien u kombinaciji sa vremenskim oznakamavraenim u izvetajima o prijemu od strane drugih prijemnika da bi se izraunaloukupno vreme obilaska.

13


15/22


RTP vremenska oznaka: 32 bita

Predstavlja istu vremensku referencu kao NTP vremeska oznaka, ali u istimjedinicama i sa itim ofsetom kao kod RTP paketa. Ova prepiska se moe koristitiza unutar i izmeu medijsku sinhronizaciju za izvore ije NTP vremenske oznake

su sinhronizovane, i mogu se koristiti od strane medija, nezavisnog prijemnika daproceni RTP sat nominalne frekvencije. U veini sluajeva ovo vreme nee bitiisto kao kod RTP vremenske oznake susednih paketa. Ono mora biti raunato ododgovarajue NTP vremenske oznake koristei odnos izmeu RTP vremenskogbrojaa i realnog vremena odravanog periodinom proverom zidnog sata navremenskom uzorku.

Broj paketa poiljaoca: 32 bita

Ukupan broj RTP paketa podataka poslatih od strane poiljaoca od poetkaprenosa do vremena kada je generisan ovaj izvetaj. Broj bi trebalo resetovati ako

poiljalac promeni svoj SSRC identifikator.Broj okteta poiljaoca: 32 bita

Ukupan broj okteta korisnog tereta (ne ukljuujui zaglavlje i dopunu) prenetih uRTP paketima podataka od strane poiljaoca od poetka prenosa do vremena kadaje generisan ovaj izvetaj poiljaoca. Ovo polje se moe koristiti za izraunavanjeprosene brzine prenosa podataka.

Trea sekcija sadri nulu ili vie blokova sa izvetajima prijema u zavisnosti od brojadrugih izvora sasluanih od strane ovog poiljaoca u periodu od poslednjeg izvetaja.Svaki blok prijema izvetaja prenosi statistiku prijema RTP paketa iz jednog izvora zasinhronizaciju. Prijemnici ne treba da prenose statistiku ako su izvori promenuli SSRCidentifikator usled sudara. Ove statistike su:

SSRC_n (identifikator n-tog izvora): 32 bita

SSRC prvog izvora iji podaci su stigli do vora koji alje SR paket; u svakombloku za izvetaj se nalaze podaci za samo jedan izvor saobraaja.

Izgubljenih frakcija: 8 bita

Predstavlja odnos broja paketa koji su izgubljeni i broja oekivanih paketa odtrenutka dobijanja poslednjeg SR ili RR paketa.

Kumulativni broj izgubljenih paketa: 24 bita

Ukupan broj izgubljenih paketa koji potiu od izvora SSRC_n, a koji su poslati odtrenutka poetka slanja.

14


16/22


Najdui niz primljenih paketa: 32 bita

Donjih 16 bita sadre broj najdueg niza primljenih RTP data paketa od izvoraSSRC_n, a 16 najznaajnijih bita proiruju taj broj sa odgovarajuim brojemciklusa.

Diter: 32 bita

Procena statistike varijacije meuvremena (engl. interarrival time) dolaska RTPpaketa mereno u jedinicama vremenske oznake (engl. timestamp).

Poslednja SR vremenska oznaka: 32 bita

Srednja 32 bita od 64-bitne NTP vremenske oznake poslednjeg primljenog SRRTCP paketa. Ako jo nije primljen SR polje je setovano na nulu.

Kanjenje od poslednjeg SR: 32 bita

Kanjenje izraeno u jedinicama 1/65536 sekunde, izmeu prijema poslednjeg SRpaketa od izvora SSRC_n i slanja ovog bloka izvetaja o prijemu. Ako jo nije primljenSR polje je setovano na nulu.

5.2.2 Izvetaj primaoca RTCP paketa (engl. Receiver Report RTCP Packet, RR)

0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1V=2 P RC PT=SR=201 DUINA

SSRC POILJAOCA

SSRC_1 (SSRC PRVOG IZVORA)IZGUBLJENIH FRAKCIJA KUMULATIVAN BROJ IZGUBLJENIH PAKETA

NAJDUI NIZ PRIMLJENIH PAKETADITER

POSLEDNJA SR VREMENSKA OZNAKAKANJENJE OD POSLEDNJEG SRSSRC_2 (SSRC DRUGOG IZVORA)

...SPECIFINA EKSTENZIJA PROFILA

Format izvetaja primaoca je isti kao kod izvetaja poiljaoca, samo to polje tip paketasadri konstantu 201 i pet polja je izostavljeno u odnosu na poiljaoca i to su NTP i RTPvremenske oznake i brojai paketa i okteta poiljaoca. Preostala polja imaju potpuno isto

znaenje kao kod SR paketa.

Prazan RR paket (RC = 0) mora biti stavljen na elo sloenog RTCP paketa kada nemaslanja i prijema podaka odnosno izvetaja.

15


17/22


5.3 RTCP paket opisa izvora (engl. Source Description RTCP packet, SDES)

0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

V=2 D BROJ IZVORA TP = SDES = 202 DUINA

IDENTIFIKATOR IZVORITA NAMENJEN ZA SINHRONIZOVANJE (SSRC_1) /IDENTIFIKATOR DOPUNSKOG IZVORITA (CSRC_1)

SDES STAVKE...

IDENTIFIKATOR IZVORITA NAMENJEN ZA SINHRONIZOVANJE (SSRC_2) /IDENTIFIKATOR DOPUNSKOG IZVORITA (CSRC_2)

SDES STAVKE...

SDES paket je struktura od 3 nivoa sastavljena od zaglavlja, nula ili vie dodataka odkoga je svaki sastavljen od identifikatora izvora i njegovog opisa. Znaenja polja susledea:

Verzija (V), dopuna (D), duina:

Opisano u SR paketima.

Broj izvora: 5 bita

Sadri informaciju koliko se SDES blokova nalazi u paketu, od kojih je svakisastavljen od SSRC/CSRC identifikatora i polja tipa SDES paketa.


Sadri konstantu 202 koja identifikuje paketa kao RTCP SDES paket.

Svaka SDES stavka poinje 32 bitnom granicom. On se sastoji od 8-bitnog tipa polja ibrojaa okteta koji opisuje duinu teksta (dakle, ne ukljuujui ova dva okteta zaglavlja).Tekst se koduje u UTF-8 standardu, i treba zapaziti da tekst ne moe biti dui od 255okteta, ali ovo je u skladu sa potrebom da se ogranii potonja protoka od strane RTCP-a.

5.3.1 Kanoniki identifikator krajnje take (engl. Canonical End-Point Identifier,

CNAME)

0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

POLJE TIPA = CNAME = 1 DUINA IME KORISNIKA I DOMENA ...

Za parametar CNAME, polje tipa ima vrednost 1. Polje teksta treba da je jedinstveno zasve uesnike u sesiji i najee predstavlja ime korisnika i domena.

16


18/22


5.3.2 Ime (engl. Name)

0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

POLJE TIPA = NAME = 2 DUINA UOBIAJNO IME KORISNIKA ...

Ovo je pravo ime koje se koristi da se opie izvor, npr. Sran eelj, student, i moebiti u formi koju zahteva korisnik. Polje tipa ima vrednost 2.

5.3.3 Email (engl. Electronic Mail Address)

0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

POLJE TIPA = EMAIL = 3 DUINA EMAIL ADRESA KORISNIKA ...

Polje tipa ima vrednost 3 i treba da predstavlja e-mail adresu uesnika u komunikaciji u

formatu prema specifikaciji RFC2822 (9), npr. [email protected].

5.3.4 Telefon (engl. Phone)

0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

POLJE TIPA = PHONE = 4 DUINA BROJ TELEFONA IZVORA ...

Polje tipa ima vrednost 4, a broj telefona bi trebao da je u formatu + 381 21 1234567,gde je izlazni internacionalni kod zamenjen sa +.

5.3.5 Geografska lokacija uesnika (engl. Geographic User Location, LOC)

0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

POLJE TIPA = LOC = 5 DUINA GEOGRAFSKA LOKACIJA UESNIKA ...

U zavisnosti od aplikacije razliiti detalji su potrebni. Za aplikacije konferencije, najeeje dovoljno Veternik, Novi Sad dok je za aktivan sistem oznake (engl. active badgesystem), oznaka tipa Room 2A122, AT&T BL MH odgovarajua.

5.3.6 Ime aplikacije ili alatke (engl. Application or Tool Name)

0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

POLJE TIPA = TOOL = 6 DUINA IME/VERZIJA IZVORNE APLIKACIJE ...

Daje ime, esto i verziju aplikacije koja se koristi za generisanje toka podataka, npr.Skype 4.1. Polje tipa ima vrednost 6.

17


19/22


5.3.7 Beleka (engl. Note)

0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

POLJE TIPA = NOTE = 7 DUINA BELEKA O IZVORU ...

Za parametar NOTE, polje tipa ima vrednost 7. Ova stavka moe da opisuje trenutnostanje izvora, npr. telefonira, ne moe odgovoriti, ili u toku seminara ova stavka moeda se koristi da se prenese naslov govora uesnicima u seminaru. Ovo treba koristitisamo da nosi izuzetne informacije i ne treba biti rutinski ukljueno kao mogunost svihuesnika, jer bi to usporilo brzinu kojom se alju i primaju CNAME izvetaji, ime bi seugrozile performanse protokola.

5.3.8 Privatni dodaci (engl. Private Extensions)

0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

POLJE TIPA = PRIV = 8 DUINA DUINA PREFIKSA NAZIV PREFIKSA ...

... VREDNOSNA INFORMACIJA ...

Ova stavka se koristi za definisanje eksperimentalnih ili specifinih SDES ekstenzija.Ona sadri par duine i prefiksa, koji je praen samom vrednosnom informacijomprivatnog dodatka. Treba imati na umu da prefiks troi prostor u okviru stavke ukupneduine 255 okteta, tako da bi trebao da bude to je mogue krai, ime ne bi bilapreoptereena propusnost RTCP , poto ona nije namenjena da zadovolji sve zahteve zakontrolnim informacijama aplikacije. Polje tipa ove stavke ima vrednost 8.

5.4 Odjavni RTCP paketi (engl. Goodbye RTCP Packet, BYE)

0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

V=2 D BROJ IZVORA TP = BYE = 203 DUINA

IDENTIFIKATOR IZVORITA NAMENJEN ZA SINHRONIZOVANJE (SSRC) /IDENTIFIKATOR DOPUNSKOG IZVORITA (CSRC)

...

DUINA RAZLOG NAPUTANJA SESIJE ...

Odjavni RTCP paketi se koriste za indikaciju da jedan ili vie izvora nisu vie aktivni.



18


20/22


Broj izvora: 5 bita

Sadri informaciju o broju SSRC/CSRC identifikatora sadranih u ovom BYEpaketu.

Tip paketa (TP): 8 bitaSadri konstantu 203 koja identifikuje paket kao RTCP BYE paket.

Poslednja dva polja su opciona i mogu da predstavljaju razlog naputanja sesije, pri tomse mora paziti da ukoliko nije zauzeto celo polje od 32 bita neophodno je dodavanje nulana kraju.

5.5 Aplikaciono-definisani RTCP paketi (engl. Application-Defined RTCP Packet,APP)

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

V=2 D PODTIP TP = APP = 204 DUINA

IDENTIFIKATOR IZVORITA NAMENJEN ZA SINHRONIZOVANJE (SSRC) /IDENTIFIKATOR DOPUNSKOG IZVORITA (CSRC)

IME (ASCII)

APLIKACIONO-ZAVISNI PODACI...

APP paket je namenjen za eksperimentalno korienje sa novim aplikacijama ifunkcijama, bez zahteva za registracijom tipa podataka.



Podtip (engl. Subtipe): 5 bita

Moe biti iskorien kao podtip da bi se omoguilo setu APP paketa da bududefinisani pod jednim unikatnim imenom, ili za bilo koje aplikaciono zavisnepodatke.


Sadri konstantu 204 koja identifikuje paket kao RTCP APP paket.

Ime: 4 okteta

Ime po izboru koje definie set APP paketa koji su jedinstveni u odnosu na drugeAPP pakete koje moe da primi ova aplikacija. Kreator aplikacije moe izabrati dakoristi ime aplikacije, a zatim da koordinira raspodelu vrednosti podtipa drugima

19


21/22


koji ele da definiu nove vrste paketa za aplikaciju. Ime se tumai kao niz odetiri ASCII karaktera, sa mogunou razlikovanja malih i velikih slova.

Aplikaciono-zavisni podaci: n x 32 bita

Aplikaciono-zavisni podaci se mogu i ne moraju pojaviti u APP paketima. Oni sutumaeni od strane aplikacije a ne samog RTP-a. Moraju biti ceo umnoak od 32bita.

20


22/22

Protokol za prenos u realnomvremenu LITERATURA

LITERATURA

[1] Tanenbaum, Andrew., ,,Raunarske mree, Mikro knjiga, Beograd, 2005.

URL izvori:

http://en.wikipedia.org/wiki/Real-time_Transport_Protocol (septembar 2009.)http://telekomunikacije.etf.bg.ac.yu/predmeti/ot4ipt/VoIP.pdf(septembar 2009.)

http://www.ietf.org/rfc/rfc3550.txt (septembar 2009.)
http://en.wikipedia.org/wiki/Real-time_Transport_Protocolhttp://telekomunikacije.etf.bg.ac.yu/predmeti/ot4ipt/VoIP.pdfhttp://www.ietf.org/rfc/rfc3550.txthttp://www.ietf.org/rfc/rfc3550.txthttp://telekomunikacije.etf.bg.ac.yu/predmeti/ot4ipt/VoIP.pdfhttp://en.wikipedia.org/wiki/Real-time_Transport_Protocol

Documents

RTP - Srdjan Zezelj