1 Prenos multimedilnych informci cez paketov siete

Pri prepojovan kanlov sa upraven a v modernejch systmoch aj digitalizovan signl vkladal priamo do prenosovho kanla. Pri prenose rei v telefnii sa v kanli prenali priamo reov vzorky zakdovan najastejie pomocou kodeku G.711. V prpade prenosu multimedilnej informcie je potrebn vyui kontajnerizciu pre odlenie viacerch typov (audio, video, dta) multimedilnej informcie.

V paketovch sieach sa digitalizovan multimedilna informcia vklad do paketov, ktor ale vaka nespojovmu charakteru sasnho Internetu prichdzaj do cieovho terminlu s rznym oneskorenm, priom as z odoslanch paketov sa me strati, prpadne me djs k zmene poradia paketov. V alom texte sa bude predpoklada, e paketov sie je postaven na protokole IP.

1.1 Spracovanie a prenos rei

Spracovanie a prenos multimedilnej informcie, konkrtne jednorozmernho analgovho signlu (napr. rei) cez IP sie je zjednoduene naznaen nasledovnm obrzkom.

A/D kodr

01001010111RTP

RTP

01001010111RTP

RTPUDP

01001010111RTP

RTPUDPIP

0100101011101 0100001010110

D/A dekodr

01001010111RTP

RTP

01001010111RTP

RTPUDP

01001010111RTP

RTPUDPIP

0100101011101

01001010111RTP

RTPUDPIPL2 L2L2

01001010111RTP

RTPUDPIPL2 L2L2

buffer

Princp spracovania a prenosu rei, prpadne inho analgovho signlu

1.1.1 Digitalizcia rei

Samotn proces digitalizcie rei je toton s procesom, ktor prebieha v telefnnej sieti pracujcej na princpe TDM multiplexu. Pre potreby prenosu rei sa na zklade poiadaviek na dostaton zrozumitenos uili nasledovn zkladn parametre pre digitalizciu: vzorkovacia frekvencia a 256 kvantizanch rovn, o zodpoved 8 bitom na jednu reov

vzorku. Pozn.: Uveden parametre umouj prena samotn analgov signl vo frekvennom psme od 0 Hz do 3,4 kHz.

Pozn.: Analgov telefnia poaduje z hadiska dostatonej zrozumitenosti prenos vo frekvennom psme od 300 Hz do 3,4 kHz.

Vsledn digitalizovan reov signl tvor dtov tok s prenosovou rchlosou 64 kb/s, o je prenosov rchlos jednho digitlneho kanla v TDM multiplexe. Proces digitalizcie prebieha v troch krokoch vzorkovanie, kvantovanie, kdovanie.

Samotn proces digitalizcie rei je priamo spojen s logicky nasledujcimi procesmi kdovania a kompresie rei.

1.1.2 Kdovanie a kompresia rei

lohou kdovania a kompresie rei je zmeni digitlny (slicov) reov signl na tak digitlny signl, ktor je z hadiska vekosti vyprodukovanho mnostva dt (bitov) minimlny, pri zachovan poadovanej kvality rei.

Digitalizciou rei sa (a na vnimky) zska dtov tok s prenosovou rchlosou 64 kb/s, o je relatvne vysok prenosov rchlos pre prenos paketovou sieou. Je potrebn si uvedomi, e pri prenose cez kanl v prpade pouitia TDM systmov je tto prenosov rchlos optimlna, pretoe sa zhoduje s kapacitou kanla. Vzhadom na rezervciu kanla pre dan volanie a nemonos jeho zdieania s inmi volaniami, nie je vo vine prpadov potrebn vykonva kompresiu takto zskanho dtovho toku. Vnimkou je pouitie kompresie za elom zvenia kvality prenosu rei pri zachovan prenosovej rchlosti (napr. tzv. 7 kHz audio, pouit kodek G.722).

V paketovej sieti ale neexistuje granularita s krokom 64 kb/s, a preto m vznam komprimova re a tak zni potrebn prenosov rchlos pre prenos hlasu. alm vznamnm dvodom vedcim ku kompresii je aj fakt, e na prenos digitalizovanej rei s prenosovou rchlosou 64 kb/s cez paketov sie je vaka zapuzdrovaniu na jednotlivch vrstvch potrebn podstatne vyia prenosov rchlos, ako je spomnanch 64 kb/s. Konkrtna hodnota vekosti rmcov ako aj celkovej prenosovej rchlosti je zvisl od dky asovho okna pri vytvran reovho segmentu.

Pre kompresiu rei sa pouva cel rad kodekov (kompresnch algoritmov), ktor s uveden v nasledujcej tabuke.

Tabuka: Prehad vybranch hlasovch kodekov a ich vlastnost Nzo

v k

odek

u

tan

dard

izovan

org

anizcio

u

Stru

n p

opis

Pren

oso

v

rch

los

(kb/s)

Vzo

rkovacia

frekven

cia (kH

z)

Max

imln

a hodnota

MO

S

G.711 ITU-T Impulzn kdov modulcia (PCM)

64 8 4,4

G.721 ITU-T Adaptvna diferencilna impulzn kdov modulcia (ADPCM)

32 8

G.722 ITU-T 7 kHz audio kdovanie pre 64 kb/s kanl

64 16 4,5

G.722.1 ITU-T Kdovanie na 24 a 32 kb/s pre 24/32 16

hands-free aplikcie v systmoch s nzkou stratovosou rmcov

G.723 ITU-T Doplnok odporania G.721 pre adaptvnu diferencilnu impulzn kdov modulciu na 24 a 40 kb/s toky pre aplikcie vyuvajce prepojovanie okruhov

24/40 8

G.723.1 ITU-T Reov kodek s dvomi monmi prenosovmi rchlosami 5,6 a 6,3 kb/s pre multimedilne aplikcie

5.6/

6.3

8 3,65/

3,95

G.726 ITU-T 40, 32, 24, 16 kb/s adaptvna diferenn impulzn kdov modulcia (ADPCM)

16/24/

32/40

8 4,23

G.728 ITU-T Kdovanie rei na 16 kb/s s pouitm krtkodobej linernej predikcie LD-CELP

16 8 3,61

G.729 ITU-T Kdovanie pomocou metodiky CS-ACELP

8 8 4,1

Princp fungovania rznych kodekov je astokrt diametrlne odlin a je zaloen na algoritmoch, ktor na rznej rovni zohaduj fakt, e s primrne uren na prenos rei. Kodeky s najnim kompresnm pomerom (napr. G.711) s vhodn aj na prenos inch signlov, ako je re, naprklad faxovch signlov. Naopak, kodeky ktor s uren a na prenos rei, vyuvaj pecifick vlastnosti reovho signlu, ako aj psychoakustick model, a preto dosahuj vy kompresn pomer. Ich nevhodou ale je, e s nepouiten pre prenos inch typov signlov, ako je napr. faxov signl. Nasledujci text uvdza zkladn princpy na ktorch s postaven horeuveden kodeky.

Impulzn kdov modulcia (Pulse Code Modulation - PCM) je znma u od roku 1938 a v roku 1960 bola tandardizovan pod oznaenm G.711. Je to zkladn metda, pri ktorej je analgov signl vzorkovan 8000 krt za sekundu, a kad vzorka je kvantovan 8-mi bitmi (nelinerne kvantovanie poda pravidla A, alebo ). Vsledn prenosov rchlos 64 kb/s je pomerne vek, ale v sasnosti je tto metda najrozrenejia. Vhodou tejto metodiky je fakt, e je povinne podporovan vo vetkch hlasovch terminloch (analgovch, ISDN, VoIP), o je z hadiska zaruenia kompatibility kov zleitos.

Modernejie systmy pouvaj dokonalejie kodeky, ktor maj prepracovanejie metdy digitalizcie. Niektor kodeky prenaj vzorky s nim nrokom na prenosov rchlos (pri snahe nezni kvalitu), ako naprklad: ADPCM, LP-CELP, CS-ACELP.

In kodeky neprenaj priamo vzorky, ale urit parametre reovho signlu, z ktorch sa na druhej strane sptne obnovuje re. Tieto progresvne kodeky sa nazvaj vokodry. Pomocou vokodrov sa v sasnosti dosahuje potrebn prenosov rchlos rdovo jednotky kb/s a stovky bitov za sekundu.

Niektor kodeky (najm vokodry) nespracovvaj kad vzorku samostatne, ale kdovanie vykonvaj pre urit poet vzoriek asov interval reovho signlu. Tento asov interval sa nazva rmec. Rmec sa kodekom kduje a me by odoslan, a ke je cel spracovan, m vznik oneskorenie prenania vzoriek. Niektor kodeky tie

potrebuj vidie do nasledujceho rmca, to znamen, e pracuj s uritm sklzom, ktor ete zvyuje asov oneskorenie.

1.1.3 Kodek G.711A

V analgovej reprezentcii je kladn vstupn signl vstupujci do kodeku G.711A

mapovan na vstupn logaritmick signl z intervalu 0;1 poda nasledujceho vzahu:

1 ln . 1sgn ; 1

1 ln

. 1, 0

1 ln

A xy F x x pre x

A A

A xpre x

A A

V rovniciach je pouit parameter kompresie 87,6A .

Dekodr vykonva obrten proces, ktorho elom je expanzia komprimovanho signlu na linerne vzorky.

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

x

y

Kompresn charakteristika kodeku G.711A pre kladn vstupn signl

Nsledne je komprimovan signl kvantovan linernym kvantiztorom do 256 rovn. elom kompresie je zvrazni (zosilni) signly so malou amplitdou a mierne potlai signly s vekou amplitdou. Cel prepoet je koncipovan tak, aby pribline platilo:

x

k kontx

,

kde x je kvantizan chyba a x je amplitda signlu. Chce sa teda dosiahnu, aby relatvna kvantizan chyba bola pribline rovnako vek pre vetky signly nezvisle od ich amplitdy. Uveden vzah nsledne vedie na jednoduch diferencilnu rovnicu

.x k x ,

ktorej rieenm je exponencila.

Pri slicovej implementcii je 16 bitov linerne kvantovan signl konvertovan na 8 bitov komprimovan signl. Poda nasledujcej tabuky:

Linerne kdovan 16 bitov signl Komprimovan 8 bitov signl

s0000000wxyzabcd s000wxyz

s0000001wxyzabcd s001wxyz

s000001wxyzabcde s010wxyz

s00001wxyzabcdef s011wxyz

s0001wxyzabcdefg s100wxyz

s001wxyzabcdefgh s101wxyz

s01wxyzabcdefghi s110wxyz

s1wxyzabcdefghij s111wxyz

, kde bit s oznauje znamienko, bity a a j s bity, ktor sa pri prevode zanedbvaj a bity w a z sa prenaj do vslednho 8 bitovho kdu.

V konenom dsledku kad kvantovan a kdovan vzorka nie je ni in ako 8 bitov

slo 7 6 5 4 3 2 1 0, , , , , , ,b b b b b b b b , ktorho vznam jednotlivch bitov je nasledovn :

najvy bit 7b m vznam znamienka, teda uruje polaritu signlu.

alie tri bity 6 5 4, ,b b b s bity, ktor uruj segment, ktor linerne aproximuje

kompresn krivku v danom intervale hodnt

posledn tyri bity 3 2 1 0, , ,b b b b uruj rove signlu v danom segmente.

Kvantovanie v rmci jednotlivch segmentov je vykonvan linerne.

Zobrazenie kompresora a jeho jednotlivch segmentov pre kodek G.711A

Kvantovanie pomocou kodeku G.711 A zkon

Kvantovanie v rmci segmentu je linerne

Vo finlnej fze sa invertuj prne bity v 8 bitovom slove (bity 6 4 2 0, , ,b b b b ), o sa

vykonva pomocou exkluzveho stu (XOR) kdovanej vzorky a kontanty 0x55.

Nhad na kompletn funkcionalitu kodeku G.711 http://www.en.voipforo.com/codec/codecs-g711-alaw.php

1.2 Prenos multimedilnej informcie pomocou aplikanch a transportnch protokolov

lohou aplikanch a transportnch protokolov je prenies multimedilny signl z kodeku od zdrojovho terminlu k cieovmu. Pri prenose informci v relnom ase je potrebn dta oznai kedy boli generovan (snman z mikrofnu), aby prijmacia strana vedela, kedy ich m prehra. V mnohch prpadoch je potrebn aj mera oneskorenie a riadi as odovzdvania. Pre tieto prenosy sa najastejie vyuva transportn protokol RTP (Real-time Transport Protocol), ktor pracuje nad protokolom UDP (vklad sa do protokolu UDP).

Pre riadenie prenosu cez RTP a pre potreby dohadu sa pouva protokol RTCP (RTP Control Protocol).

1.2.1 Protokoly RTP/RTCP

Real-time Transport Protocol (RTP) je aplikan protokol, ktor je primrne uren na prenos multimedilnych informci v relnom ase medzi terminlmi, i u sa jedn a komunikciu dvoch terminlov (unicast), alebo o jednosmern komunikciu medzi jednm a

viacermi terminlmi (multicast). Z uvedenho dvodu sa vyuva na prenos audia a videa pre potreby interaktvnej komunikcie, pri ktorej je potrebn zabezpei identifikciu prenanej informcie (typ kodeku), kontrolova poradov sla jednotlivch segmentov dt, vklada informciu o asovan jednotlivch segmentov (tzv. asov peiatka) a samozrejme sledova a monitorova prichdzajce RTP segmenty na prijmacej strane a vymiea si tieto dohadov informcie. Vetky spomnan lohy okrem posledne menovanej zabezpeuje protokol RTP. Monitoring a dohad nad tokom RTP segmentov m na starosti pridruen protokol Real-time Transport Control Protocol (RTCP).

Samotn protokoly RTP a RTCP nie s schopn garantova prenos multimedilnej informcie s poadovanou prenosovou rchlosou, oneskorenm a jitterom. Na tento el je potrebn poui in prostriedky (metodiky IS a DS, fragmentcia paketov a pod.), ktor s schopn zabezpei potrebn QoS parametre. Vina tchto metodk je zaloen na prioritnom spracovan paketov nescich multimedilnu informciu.

RTP a RTCP protokoly nevyaduj od niie postavench protokolov spoahliv doruovanie segmentov, ani dodranie ich poradia. Vaka sekvennm slam a asovm peiatkam je prijmajci terminl schopn zisti i dolo k strate segmentu, alebo k zmene poradia segmentov. V prpade straty segmentu sa jedn o nekorigovaten chybu, pretoe vzhadom na interaktvny charakter prenosu nie je z asovch dvodov mon poiada o optovn zaslanie chbajceho segmentu. Znovu zaslan segment by bol toti prijat prli neskoro na to, aby mohol by vyuit, nehovoriac o praktickej nemonosti korekcie straty segmentu pri multicaste. Ak djde k zmene poradia segmentov je prijmajci terminl vaka sekvennm slam schopn usporiada segmenty do sprvneho poradia.

Sprvy (protokolov dtov jednotky) protokolov RTP a RTCP sa zapuzdruj do segmentov protokolu UDP. V minulosti platilo pravidlo, e sprvy RTP sa prenali pomocou UDP segmentov s prnym slom portu a sprvy RTCP sa zapuzdrovali do segmentov s o jednotku vym (teda aj neprnym) slom portu. Napr. RTP sa prenalo cez port 10000 a RTCP cez port 10001. Najnovia pecifikcia protokolu RTP upa od tejto konvencie. Aj napriek tomu sa tto konvencia susednch portov per RTP a RTCP stle zvykne dodriava kvli sptnej kompatibilite so starmi zariadeniami alebo aplikciami.

lohou protokolu RTCP je okrem inho prenies od prijmaa k vysielau informciu o tom, v akej kvalite je signl prijat, t.j. koko paketov sa cestou stratilo a ak bolo kolsanie oneskorenia (jitter) tch, ktor sa preniesli. Aj ke nzov protokolu pripomna TCP (Transmission Control Protocol), RTCP nem opravn funkciu, ale dva len informciu o kvalite prijatia a ta sa mus rozhodn, i napr. kvli vekm stratm paketov nezmen kdovanie signlu tak, aby bol prenesen v niej kvalite, ale s menmi stratami.

Sequence number (Sekvenn slo)

0-1

Ver. P X CC M PT

Timestamp (asov peiatka)

SSRC identifier (identifiktor SSRS)

CSRC identifiers (identifiktory CSRS)

2 3 4-7 8 9-15 16-31bity-posun

0 1 2 3

0 - 31

32 - 63

64 - 95

96 - 127

bajty

RTP payload (Informan pole RTP PDU)128 - n

truktra PDU protokolu RTP (RFC 3550)

Zhlavie RTP protokolu m minimlne 12 bajtov. Za horeuvedenm zhlavm sa me nachdza nepovinn rozirujce zhlavie. Za zhlaviami nasleduje informan pole, ktorho vntorn truktra zvis od pouitho kodeku. Polia v zhlav s nasledovn:

Ver.: (2 bity) Uruje verziu RTP protokolu. Aktulna verzia je 2 a nepota sa z vvojom novej verzie RTP protokolu.

P (Padding): (1 bit) Uruje, i na konci RTP segmentu sa nachdzaj vplov dta, tak aby jeho vekos bola vhodn. Paket uritej vekosti me by poadovan ifrovacm algoritmom. Ak je k RTP segmentu pridan vpl, potom je bit P nastaven na jednotku a posledn oktet v RTP segmente obsahuje poet bajtov pridanej vplne vrtane poslednho bajtu. Vpl sa v RTP protokole pouva zriedka, priom najastejou prinou je prispsobenie mnostva prenanej informcie informanmu kanlu s kontantnou prenosovou rchlosou. Na nasledujcom obrzku je znzornen RTP segment obsahujci dta skomprimovan pomocou GSM kodeku do bloku po 33 bajtov, plus 12 bajtov tvor RTP zhlavie a nsledne je blok vslednch 45 bajtov doplnen na 48 bajtov z dvodu ifrovania pomocou algoritmu DES, ktor vyaduje, aby bolo mnostvo ifrovanej informcie celoselnm nsobkom 8 bajtov (64 bitov).

X (Extension): (1 bit) Uruje, i sa za zhlavm nachdzaj alie rozirujce zhlavia. Vekos kadho rozirujceho zhlavia je vo veobecnosti premenliv, preto je jeho formt nasledovn. Prv dva bajty rozirujceho zhlavia udvaj typ zhlavia, alie dva bajty udvaj dku zvynch dt rozirujceho zhlavia (bez dky prvch 4 bajtov). Tento formt je nielen dostatone flexibiln, ale taktie umouje, aby prijmatelia RTP segmentov, ktor nerozumej danmu rozirujcemu zhlaviu, ho mohli ignorova. Rozirujce pole zhlavia m svoj vznam skr pri experimentlnych aplikcich, kedy je potrebn prena aj in daje ako je mon prena priamo v RTP zhlav. Ako alternatvu k rozrenm zhlaviam mono poui novovytvoren RTP profil, v rmci ktorho mono efektvne prena vetky potrebn daje. V takomto prpade samozrejme dochdza k prenosu informcie v tele RTP segmentu. Aj napriek tomu, e RTP rozirujce zhlavia sa v praxi takmer nevyuvaj, robustne napsan aplikcie musia by schopn pracova aj s takmito RTP segmentmi, priom rozirujce zhlavia v prpade ich nepochopenia na strane prijmatea s samozrejme ignorovan.

CC (CSRC Count): (4 bity) Uruje poet CSRC identifiktorov.

M (Marker): (1 bit) Pole je vyuvan na aplikanej rovni a uruje, i dta v RTP segmente maj pecilny vznam pre aplikciu. Toto pole je zvisl od definovanho RTP profilu.

o Pri prenose audia v rmci jednoduchej videokonferencie mono M bit vyui na oznaenie prvho paketu poslanho po seku ticha. V takomto prpade je M bit nastaven na jednotku, inak je nastaven na nulu. Na zklade nastavenho M bitu si me prijmajci terminl nastavi presn as zaiatku prehrvania audia (taktie ho presne zosynchronizova s videom), pretoe pri prenose ticha sa nedb na presn asov synchronizciu pri prehrvan audia, kee pre udsk vnmanie nie je podstatn presne zachova dobu ticha, kee udia s na takto nedostatok necitliv. Podstatne vyia citlivos udskho vnmania je pri zmene asu prehratia reovch vzoriek poas prehrvania jasne poutenho zvuku.

o Pri prenose videa mono M bit vyui pre oznaenie poslednho paketu obsahujceho video snmok. Ak je M bit nastaven na nulu, potom je takto oznaen RTP segment poslednm segmentom prenajcim obrazov snmok. Toto je dleit najm pri prenose videa, aby video prehrvajci terminl nemusel aka na nasledujci RTP rmec s vyou hodnotou v poli Timestamp (asovej peiatky).

i u sa M bit vyuva pri prenose videa alebo audia, m iba upozorovac charakter, kee RTP segment sa me pri prenose sieou strati. Z uvedenho dvodu musia by aplikcie navrhnut tak, aby aj v prpade straty vznamnho segmentu s nastavenm M bitom, boli schopn korektne spracova mdiov tok. Pre audio tok je mon detegova koniec intervalu ticha, pretoe sa zaiatkom seku bez ticha strca vzba medzi sekvennm slom a asovou peiatkou. V prpade videa mono nov obrazov snmok detegova pomocou zvenej hodnoty asovej peiatky. Aplikcia by mala by napsan dostatone robustne, aby aj pri strate segmentu obsahujceho inkriminovan M bit, bola schopn korektne pracova, aj ke s mierne znenou vkonnosou.

PT (Payload Type): (7 bitov) Uruje formt informanho poa a spsob jeho interpretcie aplikciou. Zjednoduene povedan uruje typ pouitho kodeku. Hodnoty s dan v RFC 3551.

Spsob interpretcie informanho poa je definovan tzv. RTP profilom, ktor je definovan selnm kdom PT. Preto na zklade selnho kdu PT mono uri RTP profil a nsledne aj pecifikciu formtu dt, ktor s uloen v informanom poli. Tto vzba me by vytvoren ako staticky, tak aj dynamicky pomocou informovania sa s vyuitm inch protokolov (SDP a pod.). Mnoh aplikcie pracuj s RTP profilom pre audio a video konferencie s minimlnym riadenm (RFC 1890). Tento profil, ktor sa nazva ako audio/video profil (audio/video profile) AVP, prirauje vybranm typom kodekov prslun seln kdy. Prklady tchto kdov s uveden v tabuke niie. Okrem statickho priradenia mono poui aj dynamick priradenie selnch kdov ku kodekom pomocou inch (signalizanch) protokolov ako s napr.: SIP(SDP), RTSP, SAP alebo H.323(H.245). Pre audio/video profil s vyhraden seln kdy v rozsahu 96 a 127 prve pre takto dynamick priraovanie. Pri pouit inch RTP profilov mu by pre tento el vyhraden in seln rozsahy. Nezvisle od toho, i je pouit kodek definovan staticky alebo dynamicky, je potrebn zabezpei, aby aplikcia bola dopredu informovan o tom, ktor kodek sa bude pouva. Pre tento el sa najastejie pouva SDP protokol, ktorho ukka je nasledujca: v=0

o=bloggs 2890844526 2890842807 IN IP4 10.45.1.82

s=-

e=j.bloggs@example.com(Joe Bloggs)

c=IN IP4 224.2.17.12/127

t=2873397496 2873404696

m=audio 49170 RTP/AVP 0

m=video 51372 RTP/AVP 98

a=rtpmap:98 H263-1998/90000

V tomto prklade s zaujmav iba riadky zanajce znakmi c= a m=, ktor definuj pouit adresy a sla portov, ako aj profily a pouit typy PT. Riadok zanajci znakmi a= definuje pouit kodek pre kompresiu videa a jeho vzbu na prslun typ PT. V prklade s pouit dve multimedilne relcie. Audio sa posiela na multicastov adresu 224.2.17.12 na port 49170 s poom TTL (Time to live) nastavenm na hodnotu 127 a video sa posiela na t ist multicastov adresu na port 51372. V tomto prklade je prenos audia a aj videa popsan pomocou audio video profilu (AVP), o znamen, e je pouit reim pre audio a video konferencie s minimlnym riadenm. Typ PT je nastaven per audio na hodnotu 0, o zodpoved kodeku G.711U (alias PCMU). Typ PT pre video je definovan dynamicky pomocou hodnoty 98, ktor je namapovan pomocou riadku a= na kodek H.263-1998. Aj ke sa v praxi pre el popisu parametrov multimedilnej relcie pouva protokol SDP, neznamen to e je to jedin monos. Pri signalizcii pomocou protokolu H.323 sa pre tento el vyuva protokol H.245.

Sequence Number: (16 bitov) Sekvenn slo, ktor sa zvyuje o jednotku v kadom alom RTP segmente. Pole sa pouva na zistenie straty paketu a na zoradenie paketov do sprvneho poradia. Nevyuva sa pre korekciu chb, t sa z asovch dvodov nevykonva, namiesto nej je snaha potlai stratu segmentu tm, e sa napr. pri prehrvan videa sa zobraz znova predol rmec namiesto stratenho rmca. Poiaton hodnota poradovho sla me by nhodn.

Vzhadom na to, e pole je 16 bitov, dochdza relatvne asto k jeho preteeniu, o napr. pri kodeku G.711 a vytvran blokov po 20 ms nastva kadch cca 21 mint a 50 seknd. Z uvedenho dvodu aplikcie pouvaj rozren sekvenn slo, ktor je na rozdiel od sekvennho sla reprezentovan 32 bitmi, priom spodnch 16 bitov tohto rozrenho sekvennho sla tvor sekvenn slo. Primrne urenie sekvennho sla je zistenie straty paketu, prpadne viacerch paketov. Ak prijma prijme RTP segmenty a chbaj mu segmenty s uritmi slami, potom tieto straten segmenty mus vhodnm spsobom zakamuflova. Existuj rzne techniky potlania straty segmentov pouvan pri prehrvan signlu. alm vznamom poa je potreba zoradenia segmentov do sprvneho poradia, o zrchuje detekciu straty segmentu a taktie to uahuje dekompresiu multimedilneho signlu. Niektor kodeky umouj dekdovanie aj za predpokladu, e segmenty s dtami s prezentovan v zmenenom porad. Timestamp: (32 bitov) Pouva sa na synchronizovan prehrvanie prijatch dt v sprvnom asovom okamihu. Pri prenose rei sa hodnota zvyuje o 1 pri kadej vzorke, t.j. v segmente nescom 20 ms rei sa hodnota zvyuje o hodnotu 20 .8 160ms kHz .

Poiaton hodnota poa sa na strane vysielajceho terminlu nastavuje nhodne. Pridanm kadej vzorky dochdza k inkrementcii timestamp a kee kodeky generuj vzorky kontantnou rchlosou, inkrementuje sa aj hodnota timestamp v ase linerne. Dokonca aj pri pretan zznamu a pri skokoch v om nedochdza ku skokom v timestamp ale iba k jeho plynulmu zvyovaniu.

SSRC: (32 bitov) Synchronization SouRCe identifier uruje zdroj (pvodcu) multimedilneho toku mus by uniktne slo. Toto slo si nhodne vol kad participant pri RTP komunikcii. Ak by si obe strany zvolili rovnak SSRC, dolo by ku kolzii, ktor je potrebn vyriei. Pre tento el je v RTP definovan mechanizmus, pri ktorom participant, ktor detegoval kolziu SSRC posiela druhmu participantovi RTCP sprvu BYE a nsledne si sm vol nov nhodn hodnotu SSRC. Ak niektor zdroj generuje viacero multimedilnych tokov, naprklad systm ku ktormu je pripojench viacero kamier, potom kad z tchto RTP tokov pouva in identifiktor SSRC na logick oddelenie jednotlivch tokov. Nsledne prijma je schopn na zklade rozdielnych SSRC rozli jednotliv toky a uklada ich do separtnych akacch radov.

CSRC: Contributing SouRCe IDs identifiktory uruj prspevkov zdroje, z ktorch bol vytvoren vsledn multimedilny tok. Za normlnych okolnost je RTP mdiov tok generovan iba z mdiovch informci pochdzajcich z jednho zdroja. Ak ale viacer mdiov toky prechdzaj cez mixne zariadenie alebo konvertor (prekdova), potom tieto viacer mdiov toky prispievaj do vslednho mdiovho toku. Zoznam prispievajcich zdrojov sa potom udva pomocou viacerch 8 bajtovch (32 bitovch) identifiktorov CSRC. Kad identifiktor CSRC je kpiou identifiktoru SSRC konkrtneho prispievatea.

Extension header: (nepovinn) Rozirujce zhlavie bliie informcie mono njs v RFC 3550 .

PT kodek typ

mdia hodinov takt [Hz]

poet kanlov

0 PCMU A 8,000 1

1 reserved A

2 reserved A

3 GSM A 8,000 1

4 G723 A 8,000 1

5 DVI4 A 8,000 1

6 DVI4 A 16,000 1

7 LPC A 8,000 1

8 PCMA A 8,000 1

9 G722 A 8,000 1

10 L16 A 44,100 2

11 L16 A 44,100 1

12 QCELP A 8,000 1

13 CN A 8,000 1

14 MPA A 90,000 (bliie RFC 3551)

15 G728 A 8,000 1

16 DVI4 A 11,025 1

17 DVI4 A 22,050 1

18 G729 A 8,000 1

19 reserved A

20 unassigned A

21 unassigned A

22 unassigned A

23 unassigned A

dyn G726-40 A 8,000 1

dyn G726-32 A 8,000 1

dyn G726-24 A 8,000 1

dyn G726-16 A 8,000 1

dyn G729D A 8,000 1

dyn G729E A 8,000 1

dyn GSM-EFR A 8,000 1

dyn L8 A var. var.

dyn RED A (bliie RFC 3551)

dyn VDVI A var. 1

24 unassigned V

25 CelB V 90,000

26 JPEG V 90,000

27 unassigned V

28 nv V 90,000

29 unassigned V

30 unassigned V

31 H261 V 90,000

32 MPV V 90,000

33 MP2T AV 90,000

34 H263 V 90,000

35-71 unassigned ?

72-76 reserved N/A N/A

77-95 unassigned ?

96-

127

dynamic ?

dyn H263-1998 V 90,000

1.2.2 Secure Real-time Transport Protocol

Protokol Secure Real-time Transport Protocol (SRTP) definuje profil protokolu RTP,

ktor poskytuje prostriedky pre ifrovanie, autentifikciu, zabezpeenie integrity prenanch dt a zabrnenie optovnho prehratia uritej sekvencie. Protokol SRTP mono poui pre unicastov a multicastov apikcie. Protokol bol vyvinut sedemlennm tmom pozostvajcim z expertov z fyriem Cisco a Ericsson, konkrtne: David Oran, David McGrew, Mark Baugher, Mats Naslund, Elisabetta Carrara, Karl Norman a Rolf Blom. Pozor,

v tme bola aj ena! Protokol je popsan v tandarde RFC 3711 z marca roku 2004.

Pretoe protokol RTP je zviazan s protokolom RTCP za elom dohadu nad prenosom multimdi pomocou RTP protokolu, m aj protokol SRTP svojho sputnka s nzvom Secure RTCP (SRTCP). Vzah medzi SRTP a SRTCP je identick ako pre dvojicu RTP a RTCP.

Aj napriek tomu, e protokoly SRTP a SRTCP podporuj autentifikciu a ifrovanie, tieto vlastnosti s nepovinn a mu by nezvisle povolen, resp. zakzan. Jedinou vnimkou je autentifikcia sprv SRTCP, ktor je vdy vyuvan protokolom SRTCP.

Pre potreby ifrovania sa vyuva tandardn ifra AES. Pretoe samotn ifrovanie neme zabrni toku spovajcom v optovnom prehrat zachytenej pase rei alebo audia, je potrebn tomuto typu toku zabrni pomocou zabezpeenia autentifikcie a integrity prenanch dt. Tto innos sa vykonva pomocou kontrolnej sumy vypotanej pomocou algoritmu SHA1, priom sa do vpotu zahaj nielen prenan dta, ale aj as zhlavia IP paketu ktor mus obsahova sekvenn slo paketu. Na strane prjmu sa samozrejme musia vybran prznaky (sekvenn slo, ...) paketu porovna s prznakmi z inch predtm prijatch paketov.

1.2.3 Protokol RTCP

Protokol RTCP je riadiaci protokol, ktor v pravidelnch intervaloch zasiela sprvy o kvalite, identifikcii participantov a in informcie o participantoch. Taktie m na starosti oznamovanie zmien v zloen relcie, tie vmenu informci potrebnch pre synchronizciu mdiovch tokov.

Rozoznvame tchto 5 typov sprv (v anglickej terminolgii packets):

receiver report (RR),

sender report (SR),

source description (SDES),

membership management (BYE),

application-defined (APP).

Vetky RTCP sprvy maj zkladn formt, ktorho doplnenm vznikaj konkrtne typy RTCP sprv.

Vznam jednotlivch pol je nasledovn:

1. Version number (V) slo verzie protokolu RTCP, ktor je vdy rovn 2 pre aktulnu verziu RTCP.

2. Padding (P) udva, i sa v RTCP sprve nachdza aj vpl. Vznam a pouitie tohto poa je identick s vznamom rovnakho poa v protokole RTP.

3. Item count (IC) udva poet blokov (zznamov) v RTCP sprve, prpadne sa pouva pre in pecifick ely v zvislosti os typu RTCP sprvy. V rznych typoch RTCP sprv m toto pole rzny vznam a aj nzov.

4. Packet type (PT) uruje typ RTCP sprvy (paketu). Momentlne je definovanch 5 typov sprv a k nim prislchajcich 5 hodnt.

5. Length dka celej RTCP sprvy aj so zhlaviami udvan v tvorbajtovch slovch (nsobkoch 32 bitov).

RTCP sprvy sa nikdy neposielaj samostatne, ale sa vdy zoskupuj do vch celkov tzv. zloench sprv. Tie sa nsledne viacer zapuzdruj do jednho segmentu. Ak sa RTCP sprvy ifruj, potom sa pred ne vklad tvorbajtov slovo z nhodnch sel. Formt RTCP sprvy zapuzdrenej do segmetu a IP paketu je zobrazen na nasledujcom obrzku.

1.2.3.1 Receiver Record sprva

Primrnou lohou RTP je informovanie odosielatea o kvalite prijmanho mdiovho toku. Tto loha sa vykonva pomocou RTCP Receiver Record (RR) paketov, teda paketov obsahujcich hlsenie prijmaa. Vetky zariadenia prijmajce RTP tok s povinn podva hlsenia pomocou RTCP RR paketov.

Formt RTCP Receiver Record sprv

RTCP Receiver Report sprva je identifikovan poom packet type, ktor obsahuje hodnotu 201. Kad zdruen RR sprva me obsahova viacero blokov (RR sprv), ktorch poet je uveden v poli RC (Report Count). Kad RR sprva popisuje kvalitatvne parametre RTP toku medzi prijmateom a vysielaom RTP sprv za uit asov interval. Maximlny poet RR sprv, ktor sa mu nachdza v zdruenej RR sprve, je 31.

RR sprva obsahuje nasledovn polia:

Reporter SSRC identifiktor odosielatea hlsenia o kavlite mdiovho toku, teda v tomto prpade prjmatea RTP paketov.

Reportee SSRC identifiktor zdroja, ktormu je hlsenie (sprva) uren, teda v tomto prpade odosielate RTP paketov.

Cumulative number of packets lost celkov poet stratench paketov za cel dobu prenosu (od zaiatku prenosu). Vypotava sa ako poet oakvanch paketov zmenen o poet prijatch paketov. Poet oakvanch paketov sa vypotava ako rozdiel sekvennch sel poslednho a prvho prijatho RTP paketu. Irniou je, e do prijatch paketov sa potaj aj tie, ktor prili neskoro, prpadne boli zduplikovan. Preto uveden poet paketov me by vy ako poet odoslanch paketov, teda celkov poet stratench paketov me by aj zporn slo.

Extended highest sequence number received najvyie poradov slo prijatho RTP paketu os zaiatku prenosu.

Loss fraction stratovos paketov. Pota sa pre dan interval ako podiel potu stratench paketov k oakvanmu potu paketov. Ak je poet tratench paketov zporn, nastavuje sa na hodnotu 0.

Interarrival jitter asov zmeny prchodov RTP paketov (tzv. jitter). Toto pole obsahuje odhad zmien oneskorenia paketov na strane prijmaa, konkrtne

hodnotu jitteru iJ , ktorej vpoet je vysvetlen niie.

Last sender report (LSR) timestamp je 32 bitov slovo vybran zo stredu 64-bitovho poa timestamp z poslednej prijatej sprvy RTCP SR od odosielatea RTP paketov. Ak nebola prijat iadna takto sprva, potom je pole nastaven na nulu.

Delay since last sender report (DLSR) je doba od poslednho prijatia sprvy SR.

1.2.3.1.1 Vpoet jitteru:

Preto aby bolo mon vypota jitter, je potrebn pozna as prenosu paketu. Pretoe odosielate a prijmate RTP paketu nemaj synchronizovan hodiny, nie je mon zmera absoltny rozdiel asov. Namiesto toho sa vypotava relatvny as prenosu ako rozdiel asu na strane prijmaa v okamihu prijatia paketu a asovej peiatky v RTP pakete (asu odosielatea paketu). Tento rozdiel je zaaen chybou, ktor je dan posunom hodn odosielatea a prijmatea RTP paketu. Tento posun v hodinch je ale z hadiska variancie oneskorenia irelevantn, pretoe na nem vplyv.

Ak je iS asov peiatka RTP paketu i a iR je as prijatia RTP paketu i , potom

relatvny as prenosu paketu je i iR S .

Rozdiel relatvnych asov prenosu dvoch po sebe idcich paketov i a j :

, j j i i j i j iD i j R S R S R R S S Jitter prchodov paketov sa pota ako kzav priemer z rozdielu relatvnych asov

prenosu dvoch po sebe idcich paketov.

1

1

1,

16

i

i i

D i i JJ J

1.2.3.1.2 Vyuitie a interpretovanie hodnt posielanch v sprvach RR

Prijat sprvy RR slia odosielateovi RTP paketov, aby prispsobil mdiov tok, aby mohol by korektne prenesen cez sie. Jednou z monost je napr. zmena kodeku.

o je ale zaujmavejie, tak zo sprv RR mu erpa mnoh informcie aj analyztory a monitory multimedilnych tokov, ktor nemusia monitorova cel RTP premvku, ale sta sa im zamera na RTCP sprvy.

Zo sprv RR me naprklad odosielate RTP paketov relatvne presne vypota oneskorenie RTT (tam a sp). Princp tohto vpotu spova v odpotan asu odoslania hlsenia SR od asu prijatia RR a hodnoty DLSR. Inak povedan, ak bolo hlsenie SR

odoslan v ase St a hlsenie RR prijat v ase Rt , potom dobu oneskorenia RTT mono

vypota nasledovne:

R S RRTT t t DLSR t LSR DLSR

V prklade na nasledujcom obrzku bolo hlsenie SR poslan v ase

3024992005.125St s , hlsenie RR bolo prijat v ase 3024992016.5Rt s a doba medzi

prijatm a SR a odoslanm RR je SR a odoslanm RR je 5.25DLSR s . Vsledn

oneskorenie RTT je preto nasledovn:

3024992016.5 3024992005.125 5.25 6.125RRTT t LSR DLSR s

Odhad oneskorenia RTT

Vznam hodnt stratovosti paketov a jitteru je zrejm a nebudem ho na tomto mieste popisova.

1.2.3.2 Sender Report sprva

Ak odosielate RTP paketov prijal od ich prjemcov RTCP RR sprvu, potom im pole Sender Report sprvu (SR), ktor sli nielen pre informovanie o mnostve poslanch paketov a bajtov, ale aj pre ely synchronizcie viacerch mdiovch tokov a pre synchronizciu rtov (videa s audiom).

RTCP Sender Report

1.2.3.3 Source Description sprva

Tto sprvu me poui odosielate RTP paketov pre odoslanie informci o sebe. Konkrtne sa me jedna o telefnne slo alebo e-mailov adresu, umiestnenie klienta a pod. Tieto informcie sa mu zobrazova v okne aplikcie a maj zvyajne iba informatvny charakter pre samotnho pouvatea.

RTCP Source Description

Prklad RTCP Source Description sprvy

1.2.3.4 Bye sprva

Sprva sa pouva, ak niektor participant u opa vytvoren relciu a nem potrebu v nej zotrva. To sa deje naprklad pri ukonen volania. Samozrejme pomocou tejto sprvy nemono ukoni volanie, pretoe to je mon vykona iba pomocou prslunch signalizanch sprv.

In pouitie sprvy Bye je pri kolzii SSRC, teda ke odosielate a prijmate RTP paketov si nhodne zvolia ten ist identifiktor SSRC.

RTCP BYE sprva

1.2.3.5 Application defined sprva

Tento typ sprvy nem presne definovan pouitie, nakoko sa jedn o univerzlne rozrenie pre aplikcie, ktor si pomocou takchto RTCP sprv mu jednoducho vymiea informcie.

Application defined RTCP sprva

1.2.4 Protokol UDP

User Datagram Protocol (UDP) je protokol, ktor poskytuje negarantovan a nezabezpeen prenos segmentov medzi dvoma terminlmi. samotn protokol sa spolu s protokolom TCP rad medzi transportn protokoly. Vzhadom na svoj charakter je vyuvan aj na prenos multimedilnych informci v relnom ase, ale najastejie v kombincii s protokolom RTP, ktor do protokolu UDP zapuzdruje. Samotn protokol UDP nie je vhodn na prenos multimedilnej informcie, pretoe nedisponuje potrebnmi prostriedkami na to, aby detegoval stratu segmentu, alebo zmenu poradia segmentov. Poskytuje ale slubu oddelenia viacerch komunikanch spojen medzi terminlmi pomocou zdrojovch a cieovch portov, ktor nie je schopn zabezpei protokol RTP.

V princpe mono kontatova, e protokoly UDP a RTP s navzjom dopaj, a tak umouj prenos multimedilnej informcie v paketovej sieti v relnom ase.

1.3 Strun zhodnotenie prenosu rei v IP sieach z hadiska efektivity prenosu uitonej informcie

Prenos rei cez paketov sie je podstatne menej efektvny, ako cez sie pracujcu na princpe prepojovania kanlov (ISDN, PSTN). Dvodom je relatvne vysok redundancia spsoben prenosom zhlav a zapt protokolov RTP, UDP, IP a pouitho protokolu na linkovej vrstve. Konkrtne dochdza k pridaniu 12 B zhlavia protokolu RTP, 8 B zhlavia protokolu UDP, 20 B zhlavia protokolu IP a ak je pouit technolgia Ethernet, tak je pridanch alch 26 B. Celkov redundancia je teda 66 B pri pouit technolgie Ethernet.

Ak je pouit zkladn kodek G.711 a vekos asovho okna je 20 ms, potom pri vzorkovacej frekvencii 8 kHz spad do okna 160 vzoriek, ktor s kdovan pomocou 160 B. Po pridan redundancie 66 B vychdza celkov vekos rmca 226 B, z ktorch iba 160 B nesie informciu o reovom signli. Efektivita pri pouit kodeku G.711 a 20 ms okne je

16071%

226

B

B

a potrebn prenosov rchlos na fyzickej vrstve je

226 226.890,4 /

20 20

B bv kb s

ms ms .

V prpade pouitia kodeku G.723.1 s produkovanm dtovm tokom 6,3 kb/s

a s vekosou asovho okna 30 ms spad do jednho okna 6,3 kb/s . 30 ms = 189 b .

Pridanm redundancie 66 B sa dosiahne celkov vekos rmca 717b. Efektivita pri pouit takhoto kodeku je

18926,4%

717

b

b

a potrebn prenosov rchlos na fyzickej vrstve je

71723,9 /

30

bv kb s

ms ,

o predstavuje takmer tvornsobn dtov tok oproti toku, ktor produkuje samotn kodek.

1.4 Pohad na prenos rei cez IP sie z hadiska oneskorenia

Pre pochopenie vzniku oneskorenia pri prenose rei cez IP sie sa treba pozera na cel problm komplexne. Oneskorenie totito vznik nielen pri prenose paketov cez sie, ale aj pri kdovan, resp. prekdovan signlov, paketizcii, vyrovnvan zmien oneskorenia a pod. V nasledujcom texte bud bliie vysvetlen faktory, ktor sa podieaj na vzniku oneskorenia pri prenose rei cez IP sie.

1.4.1 tandardy udvajce limity oneskorenia

Medzinrodn telekomunikan nia (International Telecommunication Union ITU) sa zaober limitmi oneskorenia pre aplikcie zaloen na prenose rei v odporan G.114. Toto odporanie definuje tri intervaly pre oneskorenia koniec-koniec (oneskorenie medzi dvoma astnkmi meran iba pri prenose jednm smerom). Logicky sa v odporan nedefinuje oneskorenie tam a sp (Round Trip Time Delay RTT), pretoe je vypotaten z oneskorenia koniec-koniec ako jeho dvojnsobok. Preto je postaujce zadefinova iba jeden typ oneskorenia.

Intervaly hodnt oneskorenia koniec-koniec definuje nasledujca tabuka:

Tab. 1: Intervaly hodnt oneskorenia koniec-koniec poda G.114

Oneskorenie [ms] Charakteristika

0 - 150 Akceptovaten oneskorenie pre vinu aplikci zaloench na prenose rei

150 - 300 Prijaten za predpokladu, e sprvcovia s si vedom vzniknutho oneskorenia a jeho dopadu na kvalitu prenosu rei a nsledne aj na kvalitu pouvateskch aplikci.

300 - 400 Veobecne neprijaten na ely plnovania siet. Avak, je zrejm, e v niektorch vnimonch prpadoch je tento limit prekroen.

Poznmka: Tieto odporania s uren pre spojenia s dostatone kompenzovanou ozvenou. To znamen, e sa pouvaj prostriedky pre potlaenie echa (echo canceller), ak je jednosmern oneskorenie dlhie ako 25 ms (G.131).

Tieto odporania s uren pre nrodnch opertorov. Z tohto dvodu, s tieto kritri prsnejie, ako sa poaduj napr. v privtnej telefnnej sieti. V privtnej sieti mu by za uritch okolnost dovolen aj vyie hodnoty oneskorenia. Toto je ale aplikane zvisl. Pre privtne siete je akceptovaten oneskorenie zven na 200 ms, priom rozumn limit je 250 ms.

Vzhadom na to, e je mon uskutoni volanie z privtnej do verejnej siete, je v konenom dsledku potrebn aj pre takto typ volan zabezpei rovnak kvalitatvne parametre ako pre volania prebiehajce isto cez verejn siete.

1.4.2 Zdroje oneskorenia

Vo veobecnosti mono zdroje oneskorenia rozdeli do dvoch kategri poda toho, ak tatistick charakter maj nimi generovan oneskorenia:

Zdroje spsobujce kontantn oneskorenie tieto zdroje oneskorenia prispievaj k celkovmu oneskoreniu rovnako poas celej doby prenosu rei. Prspevky jednotlivch oneskoren mono v tomto prpade stava, pretoe sa jedn o deterministick proces.

Zdroje spsobujce variabiln oneskorenie. K vzniku tohto typu oneskorenia dochdza vo vstupnch frontoch na sieovch rozhraniach v paketovej sieti. V tchto vyrovnvacch pamtiach dochdza ku vzniku variabilnho oneskorenia, ktor sa nazva jitter. Toto oneskorenie sa zvyuje v kadej vyrovnvacej pamti, do ktorej sa paket dostane poas svojho putovania sieou. Vzhadom na to, e sa jedn o nhodn procesy, ktor s do uritej miery korelovan, nedochdza tu k jednoduchej sumcii oneskoren. Variabiln oneskorenie sa odstrauje a v zariaden, ktor ukonuje paketov prenos (terminl alebo hlasov (mdiov) brna) pomocou na tento el pecilne vytvorenej vyrovnvacej pamte nazvanej de-jitter buffer.

Zdroje oneskorenia na prenosovej ceste

Jednotliv zdroje oneskorenia s zobrazen na obrzku v prenosovej ceste a s detailne popsan v nasledujcich kapitolch. V princpe rozoznvame tieto zdroje oneskorenia:

Oneskorenie kdera spsoben spracovanm dt - Coder (Processing) Delay

Oneskorenie spsoben vytvranm paketov - Packetization Delay

Oneskorenie spsoben vytvranm rmcov - Serialization Delay

Oneskorenie vo frontoch - Queuing/Buffering Delay

Oneskorenie pri prepnan v sieovch uzloch- Network Switching Delay

Oneskorenie pri ren signlu Propagation Delay

Oneskorenie pri kompenzcii jitteru - De-Jitter Delay

1.4.3 Oneskorenie kdera

Oneskorenie kdera je doba, ktor digitlny signlny procesor (DSP) potrebuje pre kompresiu bloku PCM vzoriek. Toto oneskorenie sa tie nazva oneskorenie spracovania

signlu. Oneskorenie kodra zvis od typu pouitho kodeku a od rchlosti procesora. Naprklad kodek zaloen na algoritme ACELP analyzuje 10 ms bloky PCM vzoriek a potom ich komprimuje.

Doba kompresie pre kodek Conjugate Structure Algebraic Code Excited Linear Prediction (CS-ACELP) sa pohybuje v rozmedz od 2,5 do 10 ms v zvislosti od zaaenia procesora.

Ak je DSP plne zaaen kompresiou napr. tyroch hlasovch kanlov, oneskorenie kderu je 10 ms. Ak DSP kduje iba jeden hlasov kanl oneskorenie je 2,5 ms. Pri odhade oneskorenia v sieti pri jej dimenzovan je samozrejme potrebn voli najhor variant, teda dobu 10 ms.

Doba dekompresie jednho bloku je pribline jedna desatina z doby kompresie. Avak, doba dekompresie mern potu blokov v rmci, ktor ich me obsahova rzny poet. Naprklad najvy mon as dekompresie jednho rmca obsahujceho tri bloky (kad blok popisuje 10 ms sek signlu) je 3 x 1 ms alebo 3 ms. Obvykle sa pri kodeku G.729 v jednom rmci nachdzaj dva alebo tri bloky komprimovanho signlu, zatia o v prpade pouitia kodeku G.723.1 je v jednom rmci iba jeden blok.

Odhady oneskorenia kdera (najlepie mon a najhorie mon doln a horn odhad)

Kder Prenosov rchlos

[kb/s]

Poadovan vekos bloku

[ms]

Oneskorenie kdera [ms]

Najlepie

mon

Najhorie

mon

ADPCM, G.726 32.0 10 2.5 10

CS-ACELP, G.729A 8.0 10 2.5 10

MP-MLQ, G.723.1 6.3 30 5.0 20

MP-ACELP, G.723.1 5.3 30 5.0 20

Pozn.: Tabuka udvajca odhad oneskorenia dekodra nie je uveden, pretoe oneskorenie dekodra mono pribline uri ako jednu desatinu oneskorenia kdera.

1.4.3.1 Oneskorenie algoritmu kodeku alias algoritmick oneskorenie

Kompresn algoritmus vychdza zo znmych charakteristikch rei a na zklade nich je schopn sprvne spracova vzorku bloku N. Algoritmus mus ma znalosti o obsahu aspo asti bloku N +1, aby dokzal presne reprodukova vzorky bloku N. Tento pohad dopredu vna do celho procesu alie oneskorenie, ktor sa nazva algoritmick oneskorenie. Tto metodika inne zvyuje dku komprimovanho bloku.

Pozeranie sa na obsah nasledujceho bloku sa vykonva pre vetky bloky, teda napr. pre zakdovanie bloku N+1 je potrebn pozna daje aj z bloku N+2. V konenom dsledku dochdza k vzniku oneskorenia, ktor je dan mnostvom informcie, ktor mus kodek pozna z nasledujceho bloku. Pri 50% prekryt a dke bloku 10 ms dochdza k algoritmickmu oneskoreniu 5 ms. Celkov as na spracovanie bloku s dkou 10 ms je teda 15 ms.

Algoritmick oneskorenie pre kodek G.726 je 0 ms, pre kodek G.729 je 5 ms a pre kodek G.723.1 je 7,5 ms.

V vetkch alch prkladoch v tomto dokumente sa uvauje s kompresiou s kodekom G.729 s vekosou okna 30 ms a vekosou vslednho komprimovanho bloku 30 B. Vetky tabuky udvajce oneskorenia potaj s maximlnym monm oneskorenm kodeku, o je prstup vhodn pri navrhovan siete, kee pota s najhorm monm variantom.

Pre zjednoduenie terminolgie sa bude v nasledujcom texte po pojmom sumrne oneskorenie kodeku nazva oneskorenie pozostvajce z oneskorenia kdera, oneskorenia dekodra a algoritmickho oneskorenia.

Rovnica pre urenie sumrneho oneskorenia kodeku je:

Sumrne_oneskorenie_kodeku=Doba_kompresie_bloku+

doba_dekompresie_bloku . Poet_blokov_v_rmci+Algoritmick_oneskorenie

Pre kodek G.729 vychdza sumrne oneskorenie kdera nasledovne:

Najhor prpad oneskorenia kodeku: 10 ms

Doba dekompresie bloku: 1 ms

Poet blokov v rmci 3

Algoritmick oneskorenie 5 ms

Sumrne oneskorenie kodeku 10 ms +3.1 ms + 5 ms = 18 ms

1.4.4 Paketizan oneskorenie

Paketizan oneskorenie je as potrebn na vyplnenie paketu s zakdovanou reou. Toto oneskorenie je zvisl na vekosti bloku vzoriek poadovanho reovm kodrom a na pote blokov umiestnench do jednho rmca paketu. Paketizan oneskorenie sa taktie me nazva aj ako akumulan oneskorenie, pretoe hlasov vzorky sa hromadia v zsobnku pred ich vloenm do paketu.

Vo veobecnosti je potrebn paketizan oneskorenie udra na maximlnej hodnote 30 ms.

Kodek Kodekom produkovan

dtov tok [kb/s] Vekos

rmca [B] Paketizan

oneskorenie [ms]

PCM, G.711 64,0 160 20

240 30

ADPCM, G.726 32,0 80 20

120 30

CS-ACELP, G.729 8,0 20 20

30 30

MP-MLQ, G.723.1 6,3 24 30,5

60 76

MP-ACELP, G.723.1 5,3 20 30

60 90,5

alm faktorom, ktor je potrebn bra do vahy je zvislos zaaenia procesora (nielen v terminloch, ale v konenom dsledku aj v uzloch siete) od paketizanho oneskorenia. m je paketizan oneskorenie menie, tm je menia aj vekos paketov, ale zas na druhej strane sa zvyuje poet paketov (kee je efektvny dtov tok kontantn) a nsledne aj vyaenie procesora. Na niektorch menej vkonnch platformch je mon vyai procesor takmer na maximum u pri vkladan rmcov obsahujcich 20 ms rei.

1.4.4.1 Zreazenie oneskoren v pri paketizcii

Hoci kad vzorka hlasu je oneskoren vplyvom paketizanho oneskorenia a oneskorenia kdera, v skutonosti je tento efekt menej vrazn ako by sa dalo oakva, pretoe oba procesy sa v ase iastone prekrvaj a s preto sa odohrvaj takmer paralelne. Tento efekt je zobrazen na obrzku.

obr.: Zreazenie oneskoren pri paketizcii

Horn riadok zobrazuje asov priebeh seku rei. Druh riadok zobrazuje asov klu v krokoch po 10 ms. V ase T0 zana algoritmus CS-ACELP zana zbiera PCM vzorky z

kodeku. V ase T1, algoritmus zhromadil svoj prv 10 ms blok vzoriek a zana ho komprimova. V ase T2 je prv blok vzoriek skomprimovan. V tomto prklade je as kompresie 2,5 ms, o zodpoved rozdielu asov T2-T1.

Druh a tret blok je zhromaovan v ase T3 a T4. Tret blok je skomprimovan v ase T5. Paket je zostaven a zaslan (predpoklad sa, e okamit) v ase T6. Vzhadom k iastone paralelnmu charakteru procesu kompresie a paketizcie je celkov oneskorenie menie ako suma jednotlivch oneskoren. Celkov oneskorenie je dan rozdielom asov T6 a T0, teda pribline 32,5 ms.

Tento prklad predpoklad najlep mon (optimistick) variant oneskorenia kdera na rovni 2,5 ms. V pesimistickom prpade sa oneskorenie kdera me pohybova na rovni cca 10 ms. To v sumre s paketizanm oneskorenm 30 ms dva celkov oneskorenie 40 ms. Pozn.: Tento prklad neberie do vahy algoritmick oneskorenie. Ak by tomu tak bolo, zvilo by sa oneskorenie o tto hodnotu, omu zodpoved odhadovan nrast oneskorenia o 5 ms.

1.4.5 Serializan oneskorenie

Serializan oneskorenie, ktor vznik pri vysielan rmcov cez sieov rozhranie. Toto oneskorenie priamo svis s prenosovou rchlosou samotnho rozhrania a taktie zvis od vekosti rmca. Pri nzkych prenosovch rchlostiach a malch rmcoch me ma na nrast oneskorenia aj fakt, e medzi jednotliv rmce je potrebn vklada znaku, ktor oddeuje jednotliv rmce. Tento problm je citen iba pri posielan rmcov cez pomal WAN linky (linkov protokol na takchto linkch me by napr. HDLC, alebo PPP).

Nasledujca tabuka zobrazuje serializan oneskorenie pre rzne vekosti rmcov (celkov vekosti rmcov, nie iba vekos reovch vzoriek) a prenosov rchlosti.

Serializan oneskorenie mono jednoducho vypota pomocou vzorca:

frame

ser

link

ld

v , (0.1)

kde framel je dka rmca v bitoch a linkv je prenosov rchlos linky v b/s.

Tabuka: Serializan oneskorenie pre rzne vekosti rmcov [ms]

Vekos rmca

[B]

Rchlos linky [kb/s]

19.2 56 64 128 256 384 512 768 1024 1544 2048

38 15.83 5.43 4.75 2.38 1.19 0.79 0.59 0.40 0.30 0.20 0.15

48 20.00 6.86 6.00 3.00 1.50 1.00 0.75 0.50 0.38 0.25 0.19

64 26.67 9.14 8.00 4.00 2.00 1.33 1.00 0.67 0.50 0.33 0.25

128 53.33 18.29 16.00 8.00 4.00 2.67 2.00 1.33 1.00 0.66 0.50

256 106.67 36.57 32.00 16.00 8.00 5.33 4.00 2.67 2.00 1.33 1.00

512 213.33 73.14 64.00 32.00 16.00 10.67 8.00 5.33 4.00 2.65 2.00

1024 426.67 149.29 128.00 64.00 32.00 21.33 16.00 10.67 8.00 5.31 4.00

1500 625.00 214.29 187.50 93.75 46.88 31.25 23.44 15.63 11.72 7.77 5.86

2048 853.33 292.57 256.00 128.00 64.00 42.67 32.00 21.33 16.00 10.61 8.00

V tabuke je napr. uveden prklad linky s prenosovou rchlosou 64 kb/s, pouit kodek je CS-ACELP, ktormu zodpoved vekos rmca 38 B (37 B + 1 B pre flag). Serializan oneskorenie v takomto prpade je 4.75 ms.

Pozn.: Serializan oneskorenie pre 53 bajtov ATM bunku je za predpokladu pouitia aspo 2,048 Mb/s linky zanedbaten, pretoe ATM bunka je vemi mal a serializan oneskorenie v takomto prpade je iba cca 0.207 ms.

1.4.6 Oneskorenie vo fronte

Potom o je vytvoren blok reovch vzoriek, je pridan zhlavie a takto vytvoren rmec je pripraven na odoslanie. Predtm ne je fyzicky odoslan cez rozhranie, je uloen do vyrovnvacej pamte, kde me krtky okamih aka, km ho bude mono odosla. Pretoe pakety nesce re alebo in multimedilnu informciu s spracovvan v sieovch uzloch prioritne, akacia doba je minimlna mon. Paket obsahujci re ak na in paket obsahujci re alebo in prioritn informciu (napr. multimedilny obsah, informcie smerovacieho protokolu), alebo pok, km je prve vysielan paket (me sa jedna aj o neprioritn paket nesci napr. pouvatesk dta) odvysielan cel.

V podstate hlasov paket ak dobu, ktor je dan serializanm oneskorenm danm sumou predchdzajcich prioritnch paketov vo fronte. Oneskorenie v fronte je asovo premenliv a nhodn, ale vdy zvisl od aktulnej dky frontu, teda od aktulneho zaaenia linky a od jej prenosovej rchlosti.

m je v sieti viac hlasovej premvky, tm je vyia doba akania hlasovho paketu vo fronte. Vaka svojej vyej priorite ak paket nesci re iba na in prioritn pakety, ale neak na vo vstupnom fronte zaraden dtov pakety.

1.4.7 Oneskorenie pri prepnan v sieovch uzloch

Vo WAN sieach taktie dochdza k oneskoreniu pri prepnan. Nezvisle od princpu fungovania siet (synchrnne / asynchrnne) dochdza aj pri prepnan rmcov k zvyovaniu latencie.

Pri pouit technolgie FR dochdza k vzniku oneskorenia, take napr. opertori v USA potali s celkovm kontantnm oneskorenm vo FR sieti na rovni 40 ms a s variabilnou zlokou 25 ms, take celkov pesimistick odhad v prpade spojenia v rmci USA bol 65 ms. Tto hodnota ale zohaduje aj oneskorenie spsoben renm signlu.

Aj v sieti s prepnanm kanlov dochdza k vzniku oneskorenia v prepnacch uzloch. Je potrebn si uvedomi, e technolgie TDM vyuvaj zva rmce s dobou trvania 125 s, o je vzorkovacia perida pouvan pri digitalizcii rei v telefnnych sieach. Vzhadom na to, e TDM uzly vykonvaj prepojovanie jednotlivch vzoriek alebo ich vch celkov z jednho asovho rmca do inho asovho rmca, vyaduje si to vo veobecnosti oneskorenie na rovni trvania asovho rmca, teda 125 s. Celkov oneskorenie je dan ako set prspevkov oneskorenia jednotlivch TDM uzlov, cez ktor volanie prebieha, teda ako

.(125 )n s , kde n je poet uzlov. Vzhadom na zanedbaten hodnotu celkovho oneskorenia

voi inm oneskoreniam spsobenm inmi faktormi sa s tmto oneskorenm v TDM sieach nie je potrebn zabera.

1.4.8 Oneskorenie pri ren signlu

Oneskorenie vznik aj pri ren signlu po prenosovch mdich. Oneskorenie je dan konenou rchlosou renia sa elektromagnetickej vlny v danom prostred. Hodnoty oneskorenia sa lia pre rdiov spoje, metalick a optick mdia. Toto oneskorenie nadobda relevantn hodnoty iba v prpade, ak je volanie realizovan na vek vzdialenos, rdovo

tisce kilometrov. K minimlnemu oneskoreniu dochdza aj v opakovaoch pri regenercii signlu.

V praxi sa zvykne pota s priblinou hodnotou oneskorenia renm signlu 6 s/km. Pri komunikcii na vzdialenos 1000 km to in cca 6 ms, o mono ete stle povaova za zanedbaten hodnotu.

1.4.9 Oneskorenie pri kompenzcii jitteru

Pretoe dtov tok produkovan kodekom m kontantn hodnotu, mus by na strane terminlu alebo PSTN brny tto variabiln zloka oneskorenia odstrnen. Tm dochdza k vytvoreniu dtovho toku s kontantnou rchlosou. To sa uskutouje pomocou tzv. de-jitter buffera, teda vyrovnvacej pamte, ktor kompenzuje variabiln oneskorenie tak, e prijat reov vzorky uklad do pamte a vyber ich z nej v pravidelnch asovch intervaloch. Tm ale dochdza k vzniku stleho oneskorenia, ktorho hodnota je dan vekosou vyrovnvacej pamte. Toto oneskorenie je v podstate oneskorenie prehratia zznamu a nazva sa v anglickej terminolgii ako play out delay. V tomto texte sa bude nazva ako oneskorenie prehrvania.

Je vemi dleit vhodne nastavi vekos vyrovnvacej pamte, pretoe pri nastaven na nzku hodnotu dochdza asto krt k podteeniu pamte a nsledne sa to prejavuje vpadkami v rei. Zjednoduene povedan vzorka doraz do ciea neskr ako by mala by prehran. Pri vekej vyrovnvacej pamti zas dochdza k nrastu oneskorenia, o me by kritick najm ak sa celkov hodnota oneskorenia zane pribliova k limitnm prpustnm hodnotm oneskorenia pre poskytovanie sluieb danch odporanm ITU-T G.114.

Optimlna hodnota oneskorenia prehrvania sa rovn variabilnej zloke oneskorenia v prenosovom reazci. V praxi sa asto pouva metodika dynamickho de-jitter buffera, teda vyrovnvacej pamte, ktorej vekos sa dynamicky men v zvislosti od aktulnej hodnoty variabilnej zloky oneskorenia za urit sledovan dobu. Vekos vyrovnvacej pamte je sce premenliv, ale jej vekos bva zhora obmedzen hodnotou, ktor vychdza z pesimistickho odhadu variabilnej zloky oneskorenia, s ktorou je potrebn pota aj v prpade nvrhu siete.

Princp odstraovania variabilnej zloky oneskorenia

Vznik variabilnej zloky oneskorenia v IP sieti

Separcia tokov paketov a ukladanie paketov do vstupnch vyrovnvacch pamt v prijmai

Variabiln zloka oneskorenia a vyrovnvacia pam pre jeho kompenzciu

Poiaton hodnota oneskorenia je konfigurovaten, zvyajne sa nastavuje na cca 40 ms. Maximlna hodnota sa zvyajne nastavuje na 1,5 a dvojnsobok tejto hodnoty.

Ak je nastaven nominlna hodnota oneskorenia na 40 ms, znamen to, e prv prijat vzorka bude aka vo vyrovnvacej pamti 40 ms, km bude prehran. To znamen, e nasledujca vzorka nachdzajca sa v alom pakete sa me voi prvej oneskori a o 40 ms, priom na vslednej kvalite signlu sa to negatvne neprejav. Ak by bolo oneskorenie vie, vyrovnvacia pam by sa vyprzdnila, tak al prijat paket by sa pozdral o alch 40 ms, km by jeho obsah bol prehran, aby dolo k znovunastaveniu vyrovnvacej pamte a aj celho procesu kompenzcie variabilnej zloky oneskorenia. Vsledkom tohto javu je vpadok v prehrvanom zvuku poas doby cca 40 ms.

2 Signalizan protokoly v IP sieach

Pre potreby vytvorenia alebo zruenia volania v IP sieti existuje v sasnosti mnoho signalizanch protokolov, z ktorch nasledovn mono poui pre riadenie terminlov:

Session Initiation Protocol (SIP) definovan IETF v RFC

H.323 definovan ITU-T

Inter-Asterisk eXchange (IAX) proprietrny protokol pre softvrov PB Asterisk

Skinny Call Control Protocol (SCCP alebo Skinny) proprietrny protokol fy Cisco

Existuj taktie mechanizmy pre tunelovanie existujcich signalizanch protokolov:

SIGTRAN tunelovanie CCS7 cez Stream Control Transmission Protocol

QSIG over IP tunelovanie QSIG cez H.323 alebo SIP (podporuje Cisco)

SIP-T tunelovanie ISUP a QSIG signalizcie cez SIP

in :-)

alou kategriou s protokoly, ktor sa pouvaj na riadenie mdiovch brn. V takomto prpade riadi Media Gateway Controller samotn mdiov brnu Media Gateway. Existuj dva najznmejie protokoly:

Megaco (H.248), ktor vznikol vaka spoluprci ITU-T a IETF.

Media Gateway Control Protocol (MGCP) definovan IETF.

2.1 Inter-Asterisk eXchange

Protokol Inter-Asterisk eXchange (IAX) je natvny protokol pre softvrov PBX Asterisk. Aj napriek tomu je podporovan viacermi softvrovmi PBX a softswitchmi. Tento protokol je uren nielen pre vzjomn komunikciu medzi servermi (softvrov PBX, softswitch), ale aj medzi klientom a serverom (napr.: VoIP terminl softvrov PBX).

Pod skratkou IAX treba chpa aktulnu druh verziu protokolu IAX, t.j. IAX2. Prv verzia nebola oficilne schvlen a je v sasnosti nahraden IAX2, ktor je dan RFC 5456 (Februr 2009).

Protokol IAX2 umouje sasne prena nielen signalizciu, ale aj mdiov tok, samozrejme s vyuitm jednho portu. Multimedilny tok a signalizcia s prenan v binrnom formte. Pouitie jednho portu je vhodn najm pre terminly s pridelenou privtnou IP adresou (tzv. za NAT), alebo terminly za firewallom. Cel logika protokolu bola navrhnut tak, aby dobre pracoval aj za firewallom a NATom. Ostatn protokoly ako s SIP, H.323 a MGCP prenaj v jednom toku iba signalizciu, kee s to isto signalizan protokoly. Mdiov informcie sa prenaj cez protokol RTP v separtnom toku.

IAX2 vyuva protokol UDP, priom obvykl slo portu je 4569. Protokol podporuje vytvranie zvzkov (trunking), m umouje vytvori multiplex viacerch mdiovch tokov, ktor s prenan medzi dvoma bodmi v sieti ako jeden tok paketov. Tm sa redukuje nadbytonos zhlav, priom sa nezvyuje oneskorenie, ako by sa stalo pri zvovan paketov a logickom predlovan asovho okna. Nzka nadbytonos zhlav je jednou z podstatnch vhod IAX2.

Medzi nevhody IAX2 patr relatvne zloit rozirovanie alej funkcionality protokolu extensions.

2.2 Skinny Call Control Protocol

Aj napriek snahm medzinrodnch tandardizanch organizci vznikaj vo vetkch oblastiach proprietrne rieenia, ktor sa vymykaj tandardom. Tento trend sa nevyhol ani oblasti signalizanch protokolov pre VoIP, oho prkladom je proprietrny protokol SCCP od spolonosti Cisco. Dvodom pre vytvorenie vlastnho protokolu bola snaha o jednoduch zvyovanie funkcionality siete a pridvanie novch sluieb, bez potreby modernizcie (upgrade) firmvru v VoIP terminloch. Cisco sa snailo o zjednoduenie VoIP terminlov a nsledne sn aj o znenie ich ceny, aj ke to nie je vbec pozna :-). Samotn protokol SCCP vznikol odvodenm z rodiny protokolov sstredench okolo tandardu H.323. Vaka signalizanej brne nazvanej Cisco Unified Communications Manager (po starom Cisco Call Manager) mu terminly pracujce s protokolom SCCP komunikova aj s ostatnmi terminlmi pracujcimi poda tandardov H.323 a SIP. V prpade, e Cisco Unified Communications Manager podporuje H.323, vykonva konverziu signalizanch protokolov H.225.0 a H.245 na SCCP a obrtene. Pretoe protokol SCCP je oproti protokolom z rodiny H.323 jednoduch a odbremeuje terminl od mnohch konov, prina vsledn rieenie finann sporu na terminloch. Na druhej strane je zase potrebn Cisco Unified Communications Manager, ktor mus by schopn konvertova SCCP na in tandardn signalizan protokol, o je vzhadom na vyiu zloitos tandardnch protokolov relatvne komplexn a na hardvrov vybavenie relatvne nron loha. Poda tandardnej schmy prebieha komunikcia za pomoci SCCP protokolu nasledovnm spsobom:

uiton (re, prpadne multimdi) informcia sa prena prostrednctvom priameho spojenia medzi dvomi terminlmi

signalizcia sa prena prostrednctvom Cisco Unified Communications Managera, ktor taktie sli ako sprostredkovate signalizcie, prpadne ako signalizan brna zabezpeujca konverziu signalizanho protokolu

Jedna z monch architektr pre SCCP

2.2.1 Zjednoduen prklad vstavby volania pomocou SCCP

Uvate navolil cel vobu pozostvajcu zo 4 sel a zodvihnutm mikrotelefnu zabezpeil zaiatok vstavby spojenia. Sprva OffHookMessage oznamuje Cisco Unified Communications Manager (alej CUCM), e bol zodvihnut mikrotelefn. Nsledne CUCM odpoved sprvou CallStateMessage, ktor obsahuje potvrdenie informcie o stave volajceho terminlu a taktie identifikan slo volania, ktor sa vytvra. Sprva StrtToneMessage oznamuje terminlu, aby generoval oznamovac tn. Potom, o terminl zale CM prv slicu voby v sprve KeyPadButtonMessage, prike CUCM

prostrednctvom sprvy StopToneMessage terminlu zastavi generovanie oznamovacieho tnu. Terminl nsledne odole zostvajce slice voby. Po prijat a analze kompletnej voby v CUCM, je cieovmu terminlu odoslan sprva o prichdzajcom volan, spolu s identifikanm slom spojenia, ktor je platn iba pre spojenie medzi CUCM a volanm terminlom. Nsledne s volanmu terminlu (CallInfoMessage) oznmen informcie o spojen (tel. sla a nzvy volajcej a volanej strany, informcie o presmerovan, ...).

kontr. vyzv.

tn

Cisco IP

Phone 7490

OffHookMessage

Call

Manager

Cisco IP

Phone 7490

CallStateMessage (Call ID)

StartToneMessage (InsideDialTone) ozn. tn

zadanie kom-

pletnej voby a zdvihnutie

mikrotelefnu

KeyPadButtonMessage (1. slica voby)

StopToneMessage

KeyPadButtonMessage (2. slica voby)

OpenReceiveChannelAck (OK, Port1)

KeyPadButtonMessage (3. slica voby)

CallStateMessage (RingIn, Call ID)

CallInfoMessage (...)

SetRingerMessage (InsideRing)

koniec

vyzva- nia

CallInfoMessage (...)

StartToneMessage (AlertingTone)

CallStateMessage (RingOut) zdvihnutie

mikrotele-

fnu OffHookMessage

SetRingerMessage (RingOff)

koniec

ozn. tnu

CallStateMessage (Connected)

StopToneMessage koniec kontr.

vyzv. tnu

CallInfoMessage (InBoundCall)

CallStateMessage (Connected)

CallInfoMessage (OutBoundCall)

StartMediaTransmission (Port1, ...)

OpenReceiveChannelAck (OK, Port2)

StartMediaTransmission (Port2, ...)

Prenos paketov obsahujcich uiton informciu cez priame spojenie medzi

terminlmi pomocou protokolu RTP

OpenReceiveChannel (G.711, ...)

OpenReceiveChannel (G.711, ...)

vyzva-

nie

KeyPadButtonMessage (4. slica voby)

as

Zjednoduen prklad signalizcie pri vytvran volania

Zvonenie volanho terminlu je vyvolan nasledujcou sprvou SetRingerMessage. Stav o kontaktovan a vyzvan volanho terminlu je volajcemu terminlu oznmen sborom troch sprv, z ktorch prv obsahuje informcie o spojen (tel. sla a nzvy volajcej a volanej strany, ...). Nsledne je terminlu prikzan, aby generoval kontroln

vyzvac tn (StartToneMessage) a taktie oznmenie o vyzvan volanho terminlu (CallStateMessage).

Potom, o volan astnk zodvihne mikrotelefn, je tto udalos oznmen CUCM odoslanm sprvy OffHookMessage, na ktor reaguje CUCM zaslanm sprvy SetRingerMessage, ktor prikazuje terminlu ukoni vyzvanie. Sprva o zodvihnut mikrotelefnu spsob, e CUCM odole volajcemu terminlu prkaz na ukonenie generovania kontrolnho vyzvacieho tnu (StopToneMessage). alej CUCM ponkne obom terminlom sbor vlastnost volania (perida odosielania paketov, typ kodeku), ktor sa m vybudova (OpenReceiveChannel) a informuje ich o jeho stave a parametroch (CallStateMessage, CallInfoMessage). Terminl po porovnan sboru vlastnost volania definovanch sprvou OpenReceiveChannel zasiela potvrdenie do CUCM pomocou sprvy OpenReceiveChannelAck, v ktorej je uveden, i s ponkanmi vlastnosami shlas, alebo nie a taktie slo portu UDP, ktor bude terminl pouva pre vmenu uitonch informci. Po pozitvnom potvrden CUCM zasiela terminlu sprvu StartMediaTransmission, v ktorej je uveden IP adresa a slo portu druhho terminlu. tudent, ktor na skke dostatone presne nakresl a pope informcie z tejto podkapitoly bude poda prva na 99,9% hodnoten znmkou FX, pretoe je nad slnko jasn, e na skke pouil nedovolen prostriedky ako s ahky, bomby, mobil, at. Samozrejme pred nemilosrdnm aktom vyhodenia zo skky sa podrob detailnmu preskaniu, aby sa vylil vplyv fenomenlnej pamte alebo geniality. Podobne aj volan terminl oznamuje volanmu terminlu svoju IP a dresu a slo portu. Vzhadom na to, e s znme vetky potrebn informcie potrebn pre komunikciu oboch terminlov, zan si obidva terminly vymiea uiton informcie prostrednctvom protokolu RTP.

2.3 tandard H.323

tandard H.323 predstavuje komplexn rieenie, ktor pecifikuje protokoly a postupy pre multimedilnu komunikciu (audio, video, dta) cez IP sie. Samotn odporanie H.323 priam nedefinuje iadny z protokolov, ale spja a odvolva sa na mnostvo inch odporan a draftov, ktor definuj vetky potrebn protokoly a postupy.

Signalizcia poda tandardu H.323 v sebe spja signalizciu Register Admission & Status (RAS) poda tandardu H.225.0, signalizciu pre volanie (H.225.0) a signalizciu pre riadenie volania (H.245). Pre zostavenie spojenia sa pouva kombincia tchto troch signalizci. Sasou tandardu je mnostvo alch odporan: bezpenostn aspektu a kdovanie H.235, prepojenie a spoluprca so sieami s prepojovanm kanlov (ISDN, PSTN) H.246, podpora multimedilnych konferenci H.332 a doplnkov sluby H.450.1 a H.450.12 a desiatky alch odporan definujcich mnostvo inch detailov. Pozn.: Tieto tandardy nie s kvli prehadnosti zahrnut na obrzku.

Pre prenos mdiovch informci vyaduje tandard H.323 podporu funknost protokolov RTP a RTCP, priom odporanie H.323 definuje prslun audio a video kodeky, ktor mu by pouit pri transporte prslunch mdiovch signlov.

Samotn tandard vemi preczne pecifikuje jednotliv procesy, protokoly a spsoby prenosu signalizcie pri nadviazan, modifikcii a ruen volania. Takisto poskytuje dostaton flexibilitu komunikcie v tom zmysle, e umouje vzjomn komunikciu i takch zariaden, ktor nepodporuj rovnak charakter sluieb (napr. do videokonferennho spojenia me by zapojen aj astnk s terminlom podporujcim iba prenos rei). Pouitie tandardu nie je viazan na topolgiu siete a mono ho poui nielen pri komunikcii v rmci LAN, ale aj v Internete.

Implementcie tandardu H.323 s spravidla stabiln a dobre pracujce aj vaka protokolovej vyzretosti tandardu, vaka ktorej s v tandarde definovan takmer vetky

mon stavy a taktie prechody medzi nimi po nastan definovanch udalost. tandard H.323 je irok a robustn, ale jeho alie rozirovanie je komplikovan, o sa v sasnosti ukazuje by jeho najvou slabinou, vzhadom na mnostvo novch vznikajcich sluieb.

Fyzick vrstva

Linkov vrstva

IP

UDP TCP

RTP

G.711

G.722

G723.1

G728

G.729

H.261

H.263

H.264 RTCP

RAS

H.225.0

X.224 trieda 0

Signalizciapre volanie

H.225.0

(Q.931)

Signalizciapre riadenie

volania

H.245

T.123

T.125

T.124

Audio Video Riadenie a manament terminlu Dta

Protokolov referenn model H.323

2.4 Session Initiation Protocol

Protokol SIP je najjednoduch signalizan protokol pre IP telefniu a multimedilnu komunikciu. Pln nzov protokolu SIP je Session Initiation Protocol, o mono preloi ako protokol pre nadviazanie komunikanej relcie. tento nzov je viac ne vstin, pretoe protokol SIP neumouje vykona iadne in lohy, ako je napr. definovanie parametrov multimedilneho toku (sla portov, typ kodeku, typ transportnho protokolu a pod.). Pre tieto ely sa vyuva in prototokol, najastejie protokol Session Description Protocol (SDP). Sprvy protokolu SDP sa prenaj zapuzdren do sprv protokolu SIP.

asto krt sa aj v odbornej literatre hovor o SIP signalizcii alebo o tandarde SIP. Toto vyjadrenie nie je presn, pretoe sa jedn o signalizciu alebo o signalizan tandard na bze protokolu SIP, ale vzhadom na zjednoduenie a poudtenie problematiky sa pripa aj tto drobn nepresnos. Naproti tomu v tandarde H.323 (ani mimo neho) neexistuje iadny protokol H.323, ale pouvaj sa v rmci neho u spomenut skupiny protokolov.

Protokol SIP sa vyuva na vytvorenie, modifikciu a ukonenie interaktvnych relci (komunikci v relnom ase) v paketovch sieach. Pod pojmom relcia mono chpa multimedilnu konferenciu, prenos rei cez IP sie, zdieanie multimedilnych dt, alebo aj prenos textovch sprv alebo dokonca aj sborov, i webovch strnok. astnci zapojen do relcie mu vyuva ako unicastov (bod bod), tak aj multicastov (bod viac bodov) spojenia, prpadne ich kombinciu.

SIP poskytuje nasledovn sluby:

registrcia terminlu uvatea umouje identifikciu terminlu uvatea a tm nepriamo aj samotnho uvatea prostrednctvom logickej adresy (SIP adresa, tf. slo a pod.) nezvisle od jeho fyzickho umiestnenia a IP adresy v sieti,

lokalizciu terminlu uvatea urenie (vyhadanie) terminlu v sieti pre potreby komunikcie,

nadviazanie spojenia stanovenie parametrov pre volajcu a volan stranu,

dostupnos uvatea zistenie (voliten) dostupnosti volanej strany a sledovanie jej prtomnosti

SIP naproti tomu nedoke:

realizova manament interaktvnych relci po ich nadviazan

zabezpei poadovan kvalitu sluby (QoS), pretoe nedoke zabezpei, aby bola uprednostovan urit typ prevdzky ani rezervova potrebn sieov prostriedky, ale me spolupracova s protokolmi (RSVP), ktor s schopn zabezpei QoS.

efektvne realizova prenos vekho objemu dt, pretoe nie je protokolom na to urenm. S prenosom mench objemov dt, ale nie s iadne komplikcie.

Architektra interaktvnych sluieb vyuvajcich protokol SIP je relatvne zloit a podobne ako pri tandarde H.323 zahruje cel rad protokolov. Aj napriek uvedenmu je z hadiska signalizcie architektra na bze protokolu SIP podstatne jednoduchia, ako architektra postaven na tandarde H.323. Uveden fakt plat nielen o do mnostva protokolov, ale aj z hadiska ich plnosti, komplexnosti a celkovej vyzretosti. Na obrzku je znzornen referenn model architektry vyuvajcej protokol SIP. Za povimnutie stoj fakt, e pre minimalistick (ale aj najastejie pouvan) rieenie poskytnutia VoIP s potrebn iba protokoly SIP, SDP, RTP, UDP, IP a protokoly linkovej a fyzickej vrstvy.

Fyzick vrstva

Linkov vrstva

IP

UDP TCP

RTP

G.711

G.722

G723.1

G728

G.729

H.261

H.263

H.264 RTCP

SIP SAP

HTTP

RTSP

Ria

denie

rel

cie

a/a

lebo

konfe

rencie

Vid

eo

Sig

naliz

cia

apre

nos d

t

SDP

HTTPSCCPRSVP

Audio

Doha

d n

ad

multim

ed. to

kom

Vzdia

len r

iadenie

str

eam

ovacc

hserv

ero

v

Referenn model architektry vyuvajcej SIP