Analiza comunicarii intr-o retea moderna prin VoIP

Scopul lucrrii n aceast lucrare se va face o introducere n telefonia prin Internet prezentndu-se n partea teoretic modul de funcionare a acestei tehnologi mpreun cu avantajele acesteia i dezavantajele fa de telefonia clasic pe care cu toii o cunoatem. O mare atenie se va acorda protocolului de semnalizare SIP mpreun cu protocoalele adiacente. Prima Parte a lucrrii reprezint partea teoretic a acestei lucrri. Prezint motivele pentru care se folosete aceast tehnologie, avantajele i dezavantajele VoIP-ului, problemele care apar n transportul vocii, modul cum se realizeaz semnalizarea folosindu -se protocolul SIP i caracteristicile vocii transportate. n a doua parte a lucrrii se prezint o aplicaie software ce combin convesaiile de tip text (chat) cu conversaiile de tip voce (VoIP). Sunt descrise caracteristicile programului, modul de funcionare i modul de utilizare.

I Introducere n VoIP 1 Prezentare general Telefonia prin Internet definit ca i comunicaia prin voce n timp real prin reeaua cu comutaie de pachete nu mai este de mult o noutate. Aceast tehnologie dateaz nc de pe vremea zilelor de nceput ale Internetului. Proiectul Network Secure Communications al ageniei ARPA (Advanced Research Projects Agency) implementa o infrastructur pentru comunicarea prin voce n timp real nc din decembrie 1973. Protocolul ce st la baza implementrii, Network Voice Protocol, avea ca scop principal s demonstreze c este posibil o convorbire ntre doua persoane prin voce n timp real, de bun calitate, sigur i cu

o band folosit mic. Concluzia proiectului a fost c transmisia mpachetat a vocii prezint avantaje economice i poate fi realizat [16]. Totui au fost necesari aproape 20 de ani pentru ca aceast form de transmisie s fie apreciat de publicul larg. Echipamentele specializate folosite atunci nu mai sunt necesare: un calculator personal are n mod obinuit o plac de sunet, un microfon, boxe. Pe lng acestea mai este nevoie i de un software proiectat pentru transmisia i recepia vocii prin reea care acum se gsete foarte uor. Avnd n vedere rspndirea calculatoarelor i a conexiunilor la o reea de date pe scar mondial, telefonia peste reelele de pachete este posibil pentru un numr foarte mare de utilizatori. La prima vedere transmisia vocii prin reelele de date pare o idee proast. Deja exist o reea telefonic ce se bazeaz pe comutarea de circuite i care se extinde peste cele apte continente i formeaz cea mai mare reea construit vreodat de om. n plus reele de date sunt i nepotrivite pentru transmisia vocii. Aceasta este o aplicaie n timp real i necesit privilegii speciale din partea reelei deoarece n prezent cele mai multe reele nu asigur servicii de timp real. Totui VoIP a gsit clieni deoarece propunea la momentul apariiei tarife ce nu se comparau cu cele practicate de furnizorii de telefonie clasic pentru apelurile la distan. Popularitatea apelurilor aproape gratuite la distan a dovedit c i calitatea proast este satisfctoare dac preul este convenabil. Astfel motto-ul ntr-o pia competitiv i dezvoltat trei lucruri sunt importante: preul, preul i preul se adeverete nc o dat. n viitor tarifele pentru apelurile la distan se vor micora nu din cauza VoIP, ci din cauza competiiei din ce n ce mai acerbe ntre furnizorii de servicii. Avantajul din punctul de vedere al tarifelor se va diminua, dar experii afirm c aceast tehnologie are un viitor strlucitor. Datorit multiplexrilor statistice i metodelor avansate de compresie, VoIP va fi prezenta n continuare tarife mai mici dect transmisia vocii prin reelele bazate pe comutarea circuitelor. Alt avantaj ce impune aceast tehnologie pe pia l reprezint suportul pentru conferine ce permite realizarea unor conversaii ntre mai multe persoane ntr-un mod simplu i eficient. Din punctul de vedere al utilizatorului, principalul avantaj al telefoniei prin Internet l reprezint schema de tarifare. Aici spre deosebire de telefonia clasic nu se ine cont de distana dintre apelat i apelant, astfel pentru distane medii i mari telefonia prin Internet este mai rentabil dect cea tradiional. Dar pe lng preurile mai reduse, calitatea convorbirii trebuie s fie cel puin la aceeai nivel cu cea oferit de telefonia clasic i n plus s se asigure i alte serviciile speciale.

Transmisia vocii i a datelor pe reeaua cu comutaie de pachete reprezint o folosire mai eficient a reelei dect n cazul telefoniei tradiionale unde o parte din resursele reelei se pune la dispoziia utilizatorului pe tot parcursul convorbirii chiar dac acesta vorbete sau nu. Telefonia clasic ofer astzi pe lng convorbiri de calitate nalt i servicii n plus cum ar fi convorbiri la numere speciale pentru care nu se taxeaz, transmiterea la alte adrese a apelurilor primite, restricionarea unor apeluri, apeluri cu tax invers i altele. O parte din aceste servicii ar trebui suportate i de telefonia prin Internet pentru a putea concura cu adevrat cu telefonia clasic. Utilizatorii de telefonie prin Internet pot profita i de natura software a acesteia. Soluiile software pot fi uor extinse i integrate cu alte servicii i aplicaii cum ar fi whiteboard, calendar electronic sau internet propriu-zis. Dezvoltarea de servicii noi necesit mult mai puine investiii n timp i bani dect dezvoltarea de servicii pentru reeaua cu comutaie de circuite. O aplicaie pentru telefonia prin Internet poate fi transmisia n timp real al facsimilelor. Calitatea transmisiilor faxurilor sunt n mod tipic afectate de ntrzierile din reea, compatibilitatea mainilor i calitatea semnalului analogic. Pentru a trimite faxuri prin o reea cu comutaie de pachete, o interfa trebuie s formeze pachete din datele ce trebuiesc trimise, s se ocupe de conversia protocoalelor de semnalizare i control i s asigure livrarea complet a datelor scanate n ordinea corect. Pentru aceast aplicaie este i mai critic fenomenul de pierdere a pachetelor dect pentru aplicaiile de voce. Multe alte aplicaii pot implementa VoIP. De exemplu, mesajele sonore pot fi pregtite utiliznd un telefon i apoi livrate unei csue potale ce poate conine i voce i date folosind Internetul sau serviciile intranet. Documentele ce conin note audio, fiierele multimedia, etc. pot uor ajunge standarde n aplicaiile tip Office n viitorul apropriat. Principalele justificri pentru dezvoltarea VoIP pot fi concentrate dup cum urmeaz: Pre redus. Cum s-a menionat mai sus, sunt avantaje reale pentru convorbiri pe distane mari, lucru de mare importan pentru companiile ce au legturi cu alte ri. Simplificare. O reea voce/date permite standardizarea mai uoar i reduce necesarul de echipament. Aplicaii avansate. Beneficiile pe termen lung ale VoIP includ i suportul pentru aplicaiile multimedia i cu multiple ntrebuinri, cu care sistemul telefonic actual nu poate concura. Creterea pieei VoIP a fost spectaculoas n ultimii ani i se crede c aceast tendin va continua. Totui, exista numeroase aspecte ce trebuiesc mbuntite de ctre dezvoltatorii

de echipamente VoIP cum ar fi calitatea vocii, ntrzierea i pierderea pachetelor dar i controlul apelurilor i managementul sistemelor [13]. Pentru interconectarea cu celelalte reele de telefonie este folosit un gateway care n romn poate fi tradus ca convertor de interconectare sau mai simplu poart. n continuare am pstrat denumirea de gateway. Aici este locul unde semnalul de voce este pachetizat sau unde pachetele de voce sunt transformate n semnal de voce. n cazul unui apel telefon clasic telefon clasic prin reeaua IP, un gateway este un server la care utilizatorul sun aa cum ar suna la server-ul unui furnizor de Internet de la modemul calculatorului. Server-ul i va cere utilizatorului s introduc informaiile privitoare la contul folosit i numrul la care va suna, apoi va pachetiza semnalul vocal, fiecare pachet avnd n antet informaiile necesare care s-l trimit spre un alt gateway unde procesul va fi inversat i apelul va fi trimis spre un telefon obinuit. Pe de alt parte ultimul gateway care este localizat ct mai aproape de centrala apelatului, formeaz numrul telefonului apelat i cnd conexiunea a fost stabilit, ncepe s trimit semnalul de voce al apelantului ntr-un sens i n cellalt sens vocea pachetizat a apelatului. Gateway-urile permit ca apelurile de lung distan sau cele internaionale s par sistemelor de taxare ale operatorilor PSTN ca i cum ar fi apeluri locale. Nu toate server-ele iniiale trimit apelurile PSTN spre Internet i nu toate server-ele finale primesc apeluri din Internet. Gateway-urile pot fi conectate la orice fel de reea IP, i n cazul furnizorilor de telefonie IP comerciali acea reea nu este Internetul public. Muli furnizori, totui, Internetul public este folosit pentru o parte sau pentru tot procesul de rutare a pachetelor de voce i aceasta are implicaii n calitatea apelului. Odat intrate pe Internet, pachetele sunt tratate la fel cu celelalte pachete indiferent dac conin text, grafice sau video. Atunci cnd ajung la gateway-ul final pachetele sunt procesate i trimise spre reeaua PSTN. Operatorii de gateway-uri prefer s plaseze echipamentele n marile centre metropolitane, unde pot fi contactai cei mai muli abonai PSTN printr-un apel telefonic local. Dac un server trebuie s foloseasc un apel de distan mare pentru a stabili apelul telefonic, avantajele economice reale se pierd. Operatorii de gateway-uri finale trebuie s plteasc pentru liniile de acces n reeaua PSTN, care sunt n general aceleai linii cu cele administrate de furnizorii de Internet, astfel nct utilizatorii s se poat conecta prin conexiuni dial-up la ambele servicii. Utilizatorii de telefonie IP care sunt conectai n permanen la o reea local nu apeleaz la un gateway, cel puin nu n prima faz. n schimb reeaua lor este conectat

mereu la unul sau mai multe echipamente de acest tip. n reelele de telefonie IP ce in de o companie sau de un grup restrns apelurile ar putea s nu treac niciodat printr-un gateway. Scenariile de folosire a telefoniei prin reelele de pachete sunt clasificate dup tipul terminalelor ce se afl la capetele unui apel. Deoarece la fiecare capt al firului poate fi un telefon obinuit sau un terminal de date, exist patru clase generale. n clasificarea ce va urma abrevierea PC se refer la orice terminal de date capabil s transmit voce prin reea (calculatoare personale, telefoane IP, etc.). Scenariile sunt: Terminalul apelantului: PC, terminalul apelatului: PC. Acest situaie este atractiv pentru utilizatorii privai care au deja o conexiune la Internet i un calculator capabil s nregistreze i s redea voce. Pachetul software necesar este gratis. Acest scenariu pur IP va beneficia de avantajele integrrii serviciului de telefonie cu alte servicii Internet, ca WWW, mesagerie instantanee, e-mail, etc. . Pentru apelant costul convorbirii l reprezint costul conectrii la Internet, costul achiziionrii pachetului software care deobicei este zero, plus costurile aferente deinerii i ntreinerii hardware-lui necesar. Terminalul apelantului: PC, terminalul apelatului: telefon legat la una din reelele nonISDN, ISDN, GSM, . Acest scenariu reprezint o extensie a scenariului precedent n care cei care folosesc un PC ca telefon pot vorbi i cu utilizatorii reelei PSTN. Este folosit un gateway ce convertete apelul prin Internet ntr-un apel PSTN. Acest gateway trebuie s fie ct mai aproape de reedina apelatului pentru ca s se minimizeze costurile conexiunii gateway-apelant. Acest scenariu este comercializat de operatorii de gateway-uri. Pentru apelant costurile iniierii convorbirii i meninerii acesteia sunt suma costului accesului la Internet, a costului deinerii software-lui care este de obicei zero, a costului cerut de operatorul gateway-ului folosit ce depinde n mare msur de costul conexiunii gatewayutilizator apelat i a costului deineri i ntreineri hardware-lui necesar. Terminalul apelantului: telefon ( non-ISDN, ISDN, GSM), terminalul apelatului: telefon ( non-ISDN, ISDN, GSM). Aceast scenariu este atractiv pentru utilizatorii care vor s economiseasc bani n cazul convorbirilor la mare distan i nu au sau nu doresc s foloseasc un PC. De exemplu, utilizatori de telefoane mobile prefer s poarte doar aparatul propiu-zis fr alte aparate n plus. Apelul trebuie s treac prin dou gateway-uri: PSTNInternet i Internet-PSTN. Aceast soluie este comercializat de operatorii de gateway-uri. Costurile se compun din tarifele percepute de cele dou gateway-uri (tariful perceput de gateway-ul de destinaie este proporional cu costul conexiunii gateway-utilizator apelat) i din costul conexiunii utilizator apelant-gateway local.

Terminalul apelantului: telefon ( non-ISDN, ISDN, GSM), terminalul apelatului: PC. Aceasta form de apel este folositoare utilizatorilor ce vor s vorbeasc cu utilizatori de Internet folosind un telefon normal. Costurile conin tariful gateway-ului folosit i costul apelului pn la acesta [12]. Indiferent de ce se afl ntre interlocutori, o conversaie telefonic ntre dou persoane impune ca fiecare s aib un microfon i un difuzor. n telefonul tradiional, microfonul i difuzorul sunt incluse n receptor. n telefonul analogic (pe care toi l cunoatem) semnalul vocal produs de microfon este trimis direct printr-un fir ctre centrala local. Dac se folosete telefonia prin Internet, este necesar i aici folosirea unui microfon i a unui difuzor. Acestea pot fi microfonul i boxele livrate mpreun cu calculatorul personal sau pot fi incluse ntr-o casc ce include elemente de emisie i recepie. Dar acestea pot proveni i de la un telefon analogic care este legat la o central care suport telefonia prin Internet sau de la un telefon conectat direct la Internet care cunoate tehnicile VoIP. Indiferent de aparatul folosit, mecanismul unui apel telefonic prin Internet este acelai. Deci ce se ntmpl atunci cnd dorim s iniiem un apel? Mai nti, dup ce am tastat un numr de telefon sau am accesat un link coninnd numele interlocutorului dorit, este necesar s porneasc procesul de semnalizare pentru a determina starea terminalului apelat disponibil sau ocupat i s stabileasc conexiunea. Apoi, cnd conversaia a nceput, semnalul analogic produs de microfon trebuie codat ntr-un format digital corespunztor transmisiei prin reea cu comutaie de pachete. Reeaua nsi trebuie s asigure c datele produse de conversaia n timp real este transportat peste mediul avut la dispoziie ntr-o manier care produce o calitate acceptabil a vocii. n final, ar putea fi necesar ca fluxul de date ce reprezint vocea utilizatorului s fie convertit de un gateway ntr-un alt format ori din cauza interoperabilitii cu o alt schem multimedia, ori destinaia apelului se afl ntr -o reea telefonic tradiional [11] . innd cont de ceea ce s-a scris n paragraful de mai sus se poate emite ideea c, n mare, necesarul tehnologic al unei soluii VoIP se poate mpri n patru categorii semnalizare prezentat pe larg n subcapitolul 3, codare vocea i codecurile folosite sunt prezentate n subcapitolul 4, transport prezentat n continuare i controlul gateway-ului nu este prezentat n aceast lucrare, amnunte putndu-se citi n cartea IP telephony [2] .

2. Transportul datelor

Semnalul analogic primit de la microfonul folosit de utilizator este eantionat dup anumii parametri acceptai de toi interlocutorii n faza premergtoare apelului propiu -zis. n urma acestui proces se obin datele ce trebuiesc trimise la aparatele ce particip la aceast conversaie. nainte s prezint protocoalele folosite pentru transferul informaiei voi meniona cteva din problemele care trebuie rezolvate pentru a avea o calitate bun.

2.1 Problemele transportului datelor n timp real Cel mai rspndit sistem telefonic este astzi cel analogic. Acest sistem folosete modulaia semnalelor electrice pe un fir pentru a transporta vocea. Dei este o tehnologie veche, transmisia analogic are multe avantaje: este simpl i este caracterizat de o ntrziere a transmisiei foarte mic deoarece semnalul se propag pe fir aproape cu viteza luminii. Este de asemenea i foarte ieftin atunci cnd sunt puini utilizatori care vorbesc n acelai timp, i cnd sunt la mic distan unii fa de alii. Dar i cea mai simpl tehnologie analogic necesit o pereche de fire pentru fiecare conversaie, fapt ce devine rapid nepractic i foarte costisitor. O prim mbuntire a acestei tehnologii a fost s se multiplexeze mai multe conversaii pe acelai fir, folosind diferite frecvene de transport pentru fiecare semnal. Dar i aceast versiune are deficiene: dac nu se folosesc centrale (switchboards) manuale, comutaia automat necesit numeroase mecanisme electromecanice care sunt costisitoare de cumprat i de ntreinut; zgomotul se adaug la fiecare etap a transmisiei din cauz c nu se poate s se deosebeasc semnalul original de zgomot i astfel eliminarea zgomotului este aproape imposibil. Pentru toate aceste motive, multe ri folosesc o reea telefonic digital. n cele mai multe cazuri linia abonatului rmne analogic, dar semnalul este convertit la un flux digital n prima central. De obicei, acest semnal are o rat de 64kb/s (un eantion de 8 bii la fiecare 125s). Acum multe canale de voce pot fi multiplexate pe aceeai linie de transmisi une folosind o tehnologie numit multiplexare cu diviziune n timp (TDM). n acest tehnologie, fluxul digital ce reprezint o singur conversaie este mprit n blocuri (de obicei n octei, denumite i eantioane), i blocuri de la mai multe conversaii sunt ntreesute ntr-o manier round-robin n sloturile temporale ale liniei de transmisiune.

Cu aceast tehnologie digital, zgomotul care se amestec cu semnalul original nu influeeaz calitatea comunicaiei deoarece semnalele digitale pot fi refcute. Mai mult, multiplexarea cu diviziune n timp face posibil comutaia digital. Comutatorul trebuie s copieze coninutul unui slot temporal din transmisia de intrare n alt slot temporal din transmisia de ieire. De aceea funcia de comutare poate fi realizat folosind calculatoare. Totui o mic ntrziere este introdus de fiecare comutator deoarece pentru fiecare conversaie un slot temporal este disponibil numai la fiecare T microsecunde, i n unele cazuri ar putea fi necesar s se atepte pn la T microsecunde pentru a copia coninutul unui slot n altul. Tinnd cont c T este 125s n cele mai multe reele digitale, acest timp este neglijabil i ntrzierea depinde n principal de timpul de propagare. Numai n cazul n care dorete s impun un punct de vedere, un utilizator va vorbi n mod normal n numai jumtate din timpul total al conversaiei. i cum nainte de a vorbi trebuie s se gndeasc puin va utiliza numai 35% din timpul unei conversaii normale. Dac, acest utilizator, ar putea s apese pe un buton de fiecare dat cnd are ceva de spus, el va trimite spre reea informaii numai atunci cnd vorbete nu i cnd tace. Cum vom vedea mai trziu, cele mai multe tehnici folosite pentru a transforma vocea n bii de informaie (numite codecuri) au acum posibilitatea s detecteze perioadele de linite, atunci cnd utilizatorul nu vorbete. Cu acest metod, cunoscut ca detecia activiti vocii (voice activity detection), nloc s se transmit informaii, voce sau linite la fiecare 125 microsecunde, cum se face astzi, se poate transmite informaii doar atunci cnd trebuie, n mod asincron. Cnd este vorba de multiplexarea a mai multor conversaii pe aceiai linie de transmisiune, n loc s se ocupe banda tot timpul, aceast band poate fi folosit de altcineva atunci cnd un anumit utilizator tace. Acest mod de multiplexare este cunoscut ca multiplexare dinamic (sau statistic). Principalul avantaj al acestei multiplexri este c permite ca banda total a unei linii poate fi folosit mult mai eficient, n special atunci cnd sunt multe conversaii pe aceiai linie. Dar multiplexarea dinamic introduce incertitudinea n reea. Tocmai am spus c n cazul TDM, o ntrziere de pn la T microsecunde poate fi introdus la fiecare comutator; aceast ntrziere este constant pe parcursul ntregii conversaii. Situaia este total diferit la multiplexarea dinamic: dac linia de transmisiune este goal atunci cnd trebuie trimise date prin reea, acestea vor trece imediat. Dac, pe de alt parte, linia este ocupat, datele trebuie s atepte pn cnd va exista posibilitatea de a le trimite.

Acest ntrziere variabil se numete jitter i trebuie corectat de partea ce recepioneaz datele. Altfel, dac bucile de date sunt redate imediat cum sunt primite, cea ce a spus transmitorul mesajului poate devenii inteligibil. Urmtoarea generaie de telefonie va utiliza probabil multiplexarea dinamic i va mixa voce i date pe aceeai linie de transmisiune. Mai multe tehnologi sunt bune candidate pentru aceasta, ca de exemplu voce peste Frame Relay, voce peste ATM i bineneles voce peste IP. Se crede c voce peste IP este cea mai flexibil soluie deoarece nu necesit stabilirea de canale virtuale ntre dispozitivele care vor comunica. Aceasta este scalabil mai mult dect ATM sau Frame Relay n termeni de conectivitate [2]. VoIP se confrunt cu destul de multe probleme tehnice; deoarece reelele IP existente nu au fost proiectate s serveasc aplicaiile n timp real adic aplicaii care au limit e impuse privind timpul de rspuns. Cerinele pentru voce sunt dure: pentru o comunicaie n timp real de calitate bun este necesar o ntrziere maxim dus-ntors de 200 300 ms adic pe un sens ntrzierea nu trebuie s depeasc 100 150 ms. Pentru a compensa jitterul este folosit la recepie un buffer; lungimea acestui buffer influeneaz i el ntrzierea dus-ntors. De aceea jitterul trebuie s fie mic astfel nct redarea sunetului la recepie s rmn lin. Pierderea pachetelor trebuie i ea s fie mic, deoarece fluxul de voce este sensibil la pierderea de pachete.( Pierderea unor pachete duce la pierderea unor buci din semnalul primit de la microfonului transmitorului i astfel redarea la recepie se face cu ntreruperi.) Din pcate pierderea de pachete n Internet este corelat deoarece pierderile apar n timpul congestiilor i aceste pierderi continue de pachete reduc substanial inteligibilitatea vocii. Voi face n continuare o prezentare mai detaliat a principalelor probleme: pierderea pachetelor; ntrzierile; jitterul.

2.1.1 Pierderea pachetelor Este un lucru comun n reelele cu comutaie de pachete, deoarece pe msur ce rutele devin congestionate, cozile de ateptare n elementele de rutare devin nencptoare i nu va mai fi loc pentru alte pachete i acestea vor fi aruncate. Pierderea de pachete poate duce la degradarea calitii vocii. Fiecare pachet conine ntre 20 80ms, n funcie de codecul folosit, din semnalul captat de microfon. Cnd sunt doar cteva pachete pierdute, creierul uman este capabil s reconstruiasc zonele pierdute, dar dac numrul pachetelor este mare vocea redat

este neinteligibil. n continuare sunt prezentate tehnicile prin care se poate rezolva problema pierderii pachetelor: mbuntirea reelei. Deoarece fenomenul de aruncare a pachetelor este strns legat de banda insuficient a conexiunilor i de viteza de procesare a elementelor de rutare, mbuntirea reelei poate fi o soluie pentru aceast problem. nlocuirea cu pauze. La destinaie coninutul pachetelor este redat, aprnd probleme atunci cnd pachetele a cror informaie trebuia redat nu mai sosesc fiind ntrziate sau pierdute. nlocuirea cu pauze rezolv aceast problem prin redarea de linite n locul informaiei din pachetele pierdute. Din pcate, dac rata de pierdere a pachetelor este prea mare sau pachetele sunt prea mari (adic conin fragmente mari de semnalul captat) n semnalul redat apar frnturi din semnalul original, lucru ce deterioreaz semnificativ calitatea vocii. nlocuirea cu zgomot. Aceast metod nlocuiete zonele fr informaie cu zgomot. Studiile arat c se obin performane mai bune dect metoda precedent. Repetarea pachetelor. Redarea informaiei din ultimul pachet recepionat corect, atunci cnd un pachet lipsete este o alt metod de a recupera din pagubele produse de pierderea de pachete. Interpolarea pachetelor. Folosete caracteristicile vocii din pachetele nvecinate pentru a estima informaia audio ce s-a pierdut. Sunt cteva tehnici de interpolare i studiile n aceast privin au artat c aceast metod poate avea performane mai bune dect cele menionate mai sus. ntreesarea eantioanelor audio pe mai multe pachete(frame interleaving). n reelele cu comutaie de pachete fenomenul de pierdere a pachetelor este corelat i astfel nu numai un pachet este pierdut n cazul congestiei ci mai multe pachete consecutive. Acest fapt degradeaz calitatea vocii considerabil. ntreeserea eantioanelor audio pe mai multe pachete poate reduce acest efect. Dezavantajul multor eantioane pentru a le ntreese. Transmisie redundant. Informaia dintr-un pachet este n mod redundant transmis n pachete consecutive. n cazul n care pachetul original este pierdut, acesta poate fi refcut din pachetele urmtoare.

2.1.2 ntrzierea pachetelor ntrzierile de lung durat provoac intrarea participanilor la o conversaie ntr-un mod de comunicaie half-duplex, adic unul dintre ei vorbete i ceilali ateapt un timp pentru ca s fie siguri c vorbitorul a terminat ce are de zis. Dac timpul de ateptare este ales

n mod eronat, pot exista doi sau mai muli vorbitori n aceali timp. ntrzierile de lung durat este un efect pgubos i din cauza ecoului care face ca vorbitorul s i aud propria sa voce dup un timp dup ce a terminat de vorbit. Cerinele exacte n privina ntrzieri nu pot fi date din cauz c este un fenomen subiectiv, dar exist anumite limite. Se spune c o redare a vocii interlocutorului cu 150ms decalat fa de momentul cnd vorbete, este aceptabil pentru cele mai multe aplicaii. Pe msur ce ntrzierea crete interlocutorii ncep s vorbeasc n acelai timp sau se confrunt cu un ecou deranjant, adic calitatea convorbirii este foarte sczut. Totui, ntrzieri ntre 150 i 400ms sunt acceptate pentru convorbiri ntre persoane aflate la mare distan. ntrzierea este una din cele mai mari probleme cu care se confrunt telefonia prin Internet. n reelele cu comutaie de pachete factorii cauzatori sunt: ntrzierea produs de codecuri. Funcia principal a unui codec este de a digitaliza semnalul vocal analog, dar i de-a realiza o compresie pentru a reduce necesarul de band. Ratele mari de compresie pot fi obinute cu ajutorul unor algoritmi ce au ca dezavantaj timpul de procesare destul de mare. ntrzierea este compus din timpul necesar prelucrrii eantioanelor ce intr ntr-un singur pachet i din timpul necesar observrii eantioanelor urmtoare pentru a exploata anumite corelaii ce ar putea apare. Timpul necesar decodrii este de obicei jumate din timpul necesar codrii deci la recepie ntrzierea produs este mai mic dect cea produs la transmisie. ntrzierea din cauza transmisiei. Reprezint timpul necesar pentru a pune un pachet pe linia de transmisiune i este determinat de viteza liniei i de mrimea pachetului. ntrzierile produse de cozile de ateptare. Acest timp pierdut reprezint problema cea mai important introdus de reelele cu comutaie de pachete. Depinde de numrul de pachete ce ateapt n coad i variaz enorm de la un pachet la altul. ntrzierea produs de cozile de ateptare este principala problem pentru aplicaiile n timp real deoarece este o surs pentru jitter. ntrzierile cauzate de propagare. Reprezint timpul necesar pentru ca semnalul s ajung de la un punct al reelei la cellalt i este determinat de viteza lumini. Acest timp devine important dac distanele ntre puncte este mare cum ar fi czut legturilor prin satelit.

2.1.3 Jitterul Jitterul reprezint variaia duratei de timp ntre pachetele primite la recepie. Mai poate fi definit ca variaia ntrzierilor la care sunt supuse pachetelor. Acest fenomen este o problem important ce trebuie depit n comunicaiile prin voce. Jitterul apare mai ales din cauza ntrzierilor produse de cozile de ateptare, dar poate proveni si din faptul c pachetele

pot parcurge trasee diferite. Pentru a-l compensa, la recepie, se folosete un buffer n care sunt inute primele pachetele sosite pentru o durat de timp definit nainte ca informai a coninut s fie redat. ntrzierea produs de acest buffer se adaug la ntrzierea total deci pentru a avea o comunicaie de calitate trebuie s avem de asemenea un jitter mic. n mod ideal, dimensiunea buffer-ului este aleas n mod dinamic n concordan cu situaia reelei. De obicei dimensiunea buffer-ului este de 50 100ms. n figura I.1 este prezentat o situaie ce s -ar putea ntmpla din cauza jitter-ului. O fraz rostit normal ar putea ajunge la cellalt capt cu ntreruperi.

Figura I.1 Jitter-ul

2.2 RTP (RFC 1889) Am vzut c atunci cnd o reea cu multiplexare dinamic este folosit pentru transmisia datelor n timp real, ca de exemplu vocea, jitterul trebuie luat n consideraie de ctre receptor. Ruterele sunt exemple bune pentru dispozitive ce realizeaz multiplexarea dinamic i de aceea n tehnologiile voce i video peste IP trebuie s fie luat n considerare problemele cauzate de jitter. Grupul pentru transportul informaiilor audio i video din cadrul IETF a nceput lucrul la un protocol de transport n timp real n 1993. Scopul acestui protocol este de a oferi servicii cerute de conferinele multimedia interactive, ca sincronizarea redrii informaiilor primite, demultiplexare, identificarea tipului de mediu folosit pentru transmisie i identificarea participanilor activi. Totui, nu numai aplicaiile pentru conferine multimedia pot beneficia de RTP, ci i stocarea de date continue, distribuia interactiv de date cu formate multimedia,

simulri realizate n paralel pe mai multe terminale i aplicaiile de msur i control pot profita de avantajele aduse de RTP. Scopul proiectrii RTP a fost obinerea unui protocol cu urmtoarele caracteristici: Flexibil. RTP nu trebuie s fie limitat numai pentru conferine audio i video; Extensibil. RTP trebuie s permit implementarea de noi servicii; Independent fa de protocoalele inferioare. RTP ar trebui s lucreze cu UDP, TCP, ATM i altele; Capabil s combine mai multe fluxuri media ntr-unul singur i s-l transmit cu alt tip de codare; Eficient din punct de vedere al benzii. Dimensiunea antetului n cazul pachetelor mici de voce poate fi chiar ct dimensiunea informaiilor propriu-zise. De exemplu pentru pachetele ce conin 65ms de voce codat de o procedur ce ofer 4800bit/s d imensiunea informaiei transportate este 39 de octei. Ipv4 introduce 20 de octei n antet, UDP[3] nc 8 octei i nivelul de transport ali cel puin 8 octei. Cu antetul RTP de 4 8 octei dimensiunea antetului total poate ajunge la 40 44 de octei. Acest fapt poate sta n calea folosirii RTP pe conexiuni de mic vitez. Internaional. Protocolul trebuie s includ codri de tipul legea A, legea dar i seturi de caractere non ASCII. Eficient din punct de vedere al procesrii. i cele mai mari intervale de timp coninute n pachete creeaz o rat de 40 de pachete pe secund pentru un singur canal de voce. La acesta valoare procesarea pachetelor poate deveni o problem. Implementabil imediat. Protocolul poate s nu aib o via ndelungat i de acee a trebuie s fie posibil s fie implementat avnd la dispoziie software-ul i hardware-ul curent. Protocolul pentru transportul n timp real (RTP) a fost proiectat pentru a permite receptoarelor compensarea problemelor cauzate de jitter i sosirea ntr-o alt ordine a pachetelor dect cea n care au fost transmise. RTP poate fi folosit pentru orice flux de date n timp real, de exemplu pentru voce i pentru video. RTP include o modalitate de a identifica pachetele IP ce transport informaii isocrone prin urmtoarele informai incluse n antet: Informaii referitoare la tipul datelor transportate; Informaii referitoare la tipul la care au fost emise (timestamps); Numere de secven. Un alt protocol, RTCP, ce este n mod obinuit folosit mpreun cu RTP, permite ajungerea la transmitor a rapoartelor privind calitatea transmisiei (mrimea jitterului,

numrul de pachete pierdute, etc.) i poate transporta cteva informaii privind identitatea participanilor. RTP i RTCP nu au nici-o influen asupra comportrii reelei IP; acestea nu controleaz n nici-un fel calitatea seviciului. Reeaua poate elimina, ntrzia pachetele RTP sau schimba ordinea acestora, ca orice pachet IP. RTP i RTCP doar permit receptoarelor s aib o funcionare corect chiar dac reeaua produce jitter prin folosirea de buffere i s dein mai multe informaii despre reea pentru ca msurile de corectare corespunztoare s fie aplicate (redundan, codecuri cu rat sczut, etc.). Aceste dou protocoale sunt proiectate de a putea fi folosite peste orice protocol de transport. Dar de obicei se folosesc peste UDP deoarece schema de retransmisi a TCP nu este adaptat pentru datele ce trebuiesc transportate cu ntrzieri foarte mici, cum sunt comunicaiile interactive. n acest caz RTP este asociat n mod tradiional unui port UDP par iar RTCP urmtorului port UDP impar. Aa cum se poate citi din RFC-ul 1889, RTP este un protocol ce asigur servicii de transport capt la capt al unor date cu caracteristici de timp real, cum ar fi audio sau video facnd parte dintr-o comunicaie interactiv. Printre aceste servicii sunt incluse indentificarea tipului datelor transportate, numerotarea pachetelor, tampilarea cu informaii de timp a pachetelor i monitorizarea livrrii. Aplicaiile folosesc n mod obinuit RTP peste UDP pentru a beneficia de serviciile sale de multiplexare i de verificare a corectitudini informaiilor (prin suma de verificare). RTP permite i transferul datelor ctre destinaii multiple folosind distribuia de tip multicast dac aceast este furnizat de ctre reeaua folosit. Amintesc din nou c acest protocol nu furnizeaz nici un mecanism care s asigure transportul la timp al datelor sau alte garan ii de calitate a serviciilor, dar se bazeaz pe serviciile nivelurilor inferioare s asigure aceste garanii. Acesta nu garanteaz transportul sau transportul n secven i nici nu presupune c reeaua folsit este sigur i livreaz pachetele n secvena n care au fost transmise. Numerele de secven incluse n RTP permit receptorului s reconstruiasc secvena n care a transmis transmitorul. Acest protocol este de multe ori integrat n procesele desfurate de ctre o aplicaie dect s fie implementat ca un strat separat. n timpul creri protocolului nu s-au specificat toate elementele pentru a se permite modificrile. Pe lng RTP o implementare complet pentru o anumit aplicaie necesit specificarea modului cum un tip de date este transportat de acest protocol dar i modul cum se identific acest tip de date i cum se codeaz acesta. Voi prezenta n continuare cteva utilizri importante ale cmpurilor RTP:

- numrul de secven i informaia de timp. Fiecare pachet RTP conine un numr de secven i o informaie de timp. n funcie de aplicaie, acestea pot fi folosite n mai multe moduri. O aplicaie video, de exemplu, poate imediat deduce din informaia de timp pentru ce zon din ecran este informaia dintr-un anumit pachet. Chiar dac nu a primit pachetele care erau naintea acestuia din cauza pierderilor sau a ntrzierilor, aplicaia poate folosi pachetul pentru a construi imaginea ce o descrie. O aplicaie audio nu poate folosi aceast informaie n acest mod, deoarece nu se poate nelege vocea cu poriuni lips sau chiar cu poriuni care nu sunt n secvena n care au fost nregistrate, dar poate folosi numrul de secven i informaia de timp pentru a controla un buffer de recepie. De exemplu, o aplicaie poate decide c va pstra, ntr-un buffer, 100ms de voce nainte de a le reda. De fiecare dat cnd un nou pachet RTP va sosi, el este plasat n buffer n poziia corespunztoare n funcie de numrul de secven. Dac un pachet nu ajunge la timp i nc lipsete atunci cnd ar trebui redat, aplicaia poate s copieze informaia din ultimul pachet care tocmai a fost redat i s o repete destul timp pentru ca s se ajung la o valoare a timpului redrii echivalent cu informaia de timp din urmtorul pachet primit, sau s foloseasc o schem de interpolare defini de codecul folosit. - tipul informaiei transportate. Formatul informaiei de timp real transportate este nespecificat n RFC 1889 i trebuie definit ori de aplicaie ori de profilul RTP folosit. Pentru a distinge dintre un format particular i altul fr a analiza coninutul pachetului, antetul RTP conine un identificator al tipului informaiei. n continuare voi prezenta cteva exemple de folosire a RTP-ului: - O simpla audio conferin. Un grup de lucru se ntlnete pentru a discuta folosind serviciile multicast ale Internetului pentru comunicaii de voce. Printr-un mecanism oarecare de alocare se obine o adres multicast i o pereche de porturi. Un port este folosit pentru datele audio i cellalt este folosit pentru pachetele de control (RTCP). Adresa de multicast i porturile sunt distribuite participanilor dorii. Dac se dorete ca aceast conferin s nu fie ascultat i de ali participani nedorii, pachetele de date i de control pot fi codate cu mecanismele prezentate n RFC-ul 1889 subcapitolul 9.1, caz n care o cheie de codare trebuie generat i distribuit participanilor dorii. Aplicaiile de audio conferin folosit de fiecare participant trimite date audio n buci mici, de exemplu, de durat 20ms. Antetul RTP i datele sunt ncapsulate ntr-un pachet UDP. Antetul RTP indic tipul codri (ca PCM, ADPCM sau LPC) datelor din fiecare pachet pentru ca receptori s poate cunoate tipul datelor primite iar transmitorii s poat modifica tipul

codrii n timpul conferinei pentru, de exemplu, a permite recepia de ctre un nou participant ce este conectat printr-o legtur cu band mic sau pentru a reaciona la congestia reelei. Internetul, ca orice alt reea de pachete, ocazional pierde i reordoneaz pachetele i le ntrzie cu o durat variabil de timp. Pentru a nvinge aceste impedimente, antetul RTP conine informaii de timp i un numr de secven care permit receptorilor s reconstruiasc secvena nregistrat de surs, pentru ca n acest exemplu, poriunile primite s fie redate la fiecare 20 de milisecunde. Aceast reconstrucie este aplicat pentru fiecare surs de RTP ce ia parte la aceast conferin. Numrul de secven poate fi de altfel folosit i la determinarea de ctre receptor a numrului de pachete ce au fost pierdute. Deoarece membrii grupului pot intra sau prsi conferina n timpul conferinei, este necesar s se tie cine particip la un moment dat i ct de bine se recepioneaz datele audio. Pentru acest scop fiecare instan a aplicaie audio din conferin, n mod periodic, trimite n mod multicast un raport de recepie plus numele persoanei care folosete aceast instan spre portul RTCP. Raportul indic ct de bine este recepionat vorbitorul curent i poate fi folosit pentru a controla codecurile adaptive. Pe lng numele utilizatorului i alte informaii de indentificare pot fi incluse. O locaie trimite pachetul RTCP BYE cnd prsete conferina. - Conferin audio i video. Dac se folosesc n aceeai conferin ambele modaliti (audio i video) acestea sunt transmise ca dou sesiuni RTP separate. Pachetele sunt transmise folosind pentru fiecare modalitate dou perechi de porturi diferite i/sau adrese de multicast. Nu exist nici-o legtur la nivelul RTP ntre fluxurile audio i video, cu excepia c utilizatorul ce particip n ambele sesiuni trebuie s utilizeze acelai nume n pachetele RTCP pentru ca sesiunile s poat fi asociate. O motivare pentru aceast separare o reprezint posibilitatea ce se acord participanilor s aleag modul de primire a datelor (numai audio, numai video sau ambele). n ciuda separrii, sicronizarea redrii fluxurilor audio i video poate fi realizat folosind informaiile de timp transportate n pachetele RTCP pentru cele dou sesiuni. - Mixere i translatoare. Pn acum, n exemplele prezentate s-a presupus c toi participani doresc s primeasc fluxurile n acelai format. Totui, acest lucru nu se poate realiza ntotdeauna. S considerm cazul n care participanii dintr-o zon sunt legai printr-o conexiune de vitez mic de ceilali participani care se bucur de conexiuni de mare vitez. n loc s se impun tuturor folosirea unui codec ce produce fluxuri de calitate i band sczut, un releu la nivelul RTP-ului numit mixer poate fi plasat lng zona cu band limitat. Acesta resincronizeaz pachetele audio primite, mixeaz fluxurile ntr-un singur flux, codeaz datele audio din acesta folosind un codec de band mai mic i trimite pachetele ce conine

datele rezultate pe link-ul ce duce spre zona ce o deservete mixerul. Aceste pachete pot fi trimise n mod unicast spre un singur recipient sau n mod multicast pe mai multe adrese spre recipiente multiple. Antetul RTP include un mijloc pentru ca mixerul s identifice sursele ce au contribuit la un pachet mixat, astfel rapotndu-se corect vorbitorul curent la receptor. Civa participani la conferin ar putea fi conectai printr-o conexiune de mare vitez dar ar putea de asemenea s nu fie direct accesibili prin multicast prin IP. De exemplu, acetia ar putea fi n spatele unui firewall la nivel aplicaie care elimin toate pachetel IP. Pentru aceste staii, folosirea unui mixer nu ar fi necesar, dar trebuie folosit alt obiect ce lucreaz la nivelul RTP-ului, numit translator. Doi translatori sunt instalai de fiecare parte a firewallului, cel din exterior trimind pachetele de multicast primite printr-o conexiune sigur, spre translatorul din interior. Acesta din urm trimite pachetele din interior n mod multicast spre grupul ce particip la conferin. Mixerele i translatorii pot fi proiectai pentru o gam larg de scopuri. Un exemplu ar fi un mixer care modific imaginile primite prin mai multe fluxuri combinndu-le ntr-un singur flux video pentru a crea o imagine n care toi participanii sunt prezeni. nainte de a prezenta cmpurile ce sunt prezente ntr-un pachet RTP cteva definiii sunt necesare: Sesiune RTP. O sesiune RTP reprezint un grup de participani ce comunic prin RTP. Fiecare participant folosete dou adrese de transport (n cazul IP, de exemplu, dou porturi pe calculatorul local) pentru fiecare sesiune: una pentru fluxul RTP i cealalt pentru rapoartele RTCP. Dac se folosete o transmisie multicast, toi participanii folosesc aceeai pereche de adrese multicast de nivel 4 (de transport). Fluxurile media din aceeai sesiune ar trebui s foloseasc acelai canal RTCP. Surs de sincronizare SSRC. Sursa unui flux RTP, identificat printr-un cmp de 32 de bii din antetul RTP. Toate pachetele RTP cu un SSRC comun au aceeai referin de timp i de sincronizare, deci un receptor grupeaz pachetele dupa sursa de sincronizare n vederea sincronizrii. Exemplele de surse includ transmitorul unui flux de pachete obinute de la o surs de semnal cum ar fi un microfon sau o camer, sau un mixer RTP. O surs de sincronizare i poate schimba formatul datelor trimise n timp. Identificatorul SSRC este ales n mod aleator astfel nct aceast valoare s fie unic ntr-o sesiune RTP. Un participant nu trebuie s folosesc acelai identificator pentru toate sesiunile dintr-o sesiune multimedia; legtura dintre aceste sesiuni se face prin RTCP. Dac un participant genereaz mai multe fluxuri ntr-o sesiune RTP, cum ar fi fluxurile de la mai multe camere video, fiecare dintre acestea trebuie identificat prntr-un SSRC diferit.

Surs contribuitoare CSRC. Cnd un flux RTP este rezultatul unei combinri (mixri) a mai multe fluxuri, lista de SSRC-uri a fiecrui flux folosit este adugat n antetul RTP-ului al fluxului rezultat ca CSRC. Acest flux are propriul lui SSRC. Formatul NTP. O modalitate standard de a exprima (scrie) informaia de timp din fiecare pachet, prin scrierea numrului de secunde trecute din 1 ianuarie 1900, ora 0, cu ajutorul a 32 de bii pentru partea ntreag i 32 de bii pentru partea zecimal (n cazul prii zecimale numrul este exprimat n ^32 secunde). O form mai compact exist cu numai 16 bii pentru partea ntreag si 16 pentru partea zecimal. Primi 16 bii ce s-au omis pot fi obinui din ziua curent, iar partea zecimal este pur i simplu truncat la partea cea mai semnificativ. Pachetul RTP conine ntotdeauna toate cmpurile pn la lista CSRC. Aceast list exist numai dup ce pachetul trece de un mixer. Cmpurile sunt: 2 bii sunt rezervai pentru versiunea folosit de RTP. Un bit ce indic adugarea de bii n plus din cosiderente de aliniere. Dac pachetul a fost modificat (P=1), atunci ultimul octet al cmpului de indic tipul datelor transportate indic mai precis ci octei au fost adugai. Un bit de extensie X indic prezena extensiilor dup eventuala list CSRC a antetului fix. Extensiile au forma prezentat n figura I.2.

Figura I.2 Extensia antetului Cmpul de 4 bii CC indic numrul de CSRC-uri ce urmeaz dup antetul fix. Bit de marcaj (M). Interpretarea acestui bit este definit de un alt document ce vine odat cu aplicaia folosit i numit profil RTP. A fost pus cu intenia pentru a permite semnalizarea unor evenimente importante cum ar fi marginile unui cadru n fluxul de pachete. Acel document ar putea defini i ali bii de marcaj sau specifica c nu exist bit de marcaj prin modificarea numrului de bii din cmpul tipul informaiei transportate (sarcini). Tipul informaiei transportate(PT). Are 7 bii i identific forma informaiei transportate i determin interpretarea acesteia de ctre aplicaie. Documentul amintit mai sus

specific o coresponden static ntre coduri de identificare a tipului informaiei i diferite formate de date. n plus se pot defini alte corespondene dinamice prin mijloace non-RTP. Un emitor RTP trimite un singur identificator de sarcin la un moment dat; acest cmp nu este destinat pentru multiplexarea a unor fluxuri media diferite. Figura I.3 prezint o parte din identificatori statici.

Figura I.3 Identificatori statici Numrul de secven (16 bii). Numrul de secven este incrementat pentru fiecare pachet RTP trimis i poate fi folosit de receptor pentru a detecta pierderea pachetelor i a reface ordinea pachetelor. Valoarea iniial a numrului este aleatorie pentru a face atacurile asupra fluxurilor codate mai dificile.

Figura I.4 Pachetul RTP

Informaia de timp (32 de bii). Aceasta reflect momentul cnd s-a fcut eantionarea primului octet din datele coninute n pachet. Aceast valoare trebuie luat de la un ceas care este incrementat monoton i linear n timp pentru a permite sincronizarea i calculul jitterului. Rezoluia ceasului trebuie s fie suficient pentru acurateea dorit a sincronizrii i pentru a msura jitterul pachetelor la sosire. Frecvena ceasului este dependent de formatul informaiei transportate i este specificat n mod static n documentele ce definesc profilele i corespondena acestora cu coduri sau paoate fi definit n mod dinamic pentru formate definite prin mijloace non-RTP. Dac pachetele RTP sunt generate periodic, se va folosi valoarea ceasului de eantionare, nu valoarea ceasului sistemului. Ca exemplu, pentru flux audio cu rat fix, ceasul folosit va fi incrementat cu unu pentru fiecare perioad de eantionare. Dac o aplicaie audio citete blocuri acoperind 160 de perioade de eantionare de la dispozitivulde nregistrare, valoarea informaiei de timp va fi mrit cu 160 pentru fiecare astfel de blocuri, indiferent dac vor fi transmise sau elimitate din cauz c reprezint perioade de linite. Valoarea iniial a informaiei de timp este una aleatorie, la fel ca numrul de secven. Cteva pachete RTP pot avea valori ale informaiei de timp egale dac aceste sunt (teoretic) sunt generate n acelai timp, cum ar fi pachetele ce aparin aceluiai cadru video. Pachetele consecutive pot fi marcate cu valori nemonotone dac datele sunt transmise n alt ordine dect cea n care au fost nregistrate i eantionate, ca n cazul cadrelor video interpolate MPEG (numerele de secven sunt n continuare monotone). SSRC (32 de bii). Cpul SSRC identific sursa dup care se face sincronizarea. Acest identificator este ales n mod aleator, cu intenia ca s nu existe doua surse de sincronizare n aceeai sesiune RTP cu acelai SSRC. Cu toate c probabilitatea ca acest lucru s se ntmple este mic, toate aplicaiile RTP trebuie s fie pregtite s detecteze i s rezolva aceste coliziuni. Dac o surs i schimb adresa de transport surs, trebuie s i schimbe i SSRC-ul pentru a evita apariia confuziilor. Lista CSRC (ntre 0 i 15 elemente de 32 de bii fiecare). Acest list identific sursele ce au contribuit la datele ce sunt coninute de pachet. Numrul surselor este dat de cmpul CC. Dac sunt mai mult de 15 surse, numai 15 pot fi identificate. Identificatorii CSRC sunt inserai de mixere, folosind identificatorii SSRC ai surselor contribuitoare. De exemplu, pentru pachetele audio identificatorii SSRC ai surselor care au fost mixate mpreun pentru a crea un pachet sunt listate n cadul cmpului CSRC, permind astfel indicarea vorbitorului la recepie n mod corect. Pentru un studiu aprofundat se pot consulta urmtoarele materiale RFC 1889[4], Reele de calculatoare [1] i IP Telephony [2]

2.3 RTCP (RFC 1889) Protocolul pentru controlul RTP-ului este bazat pe transmisia periodic a pachetelor de control ctre toi participanii unei sesiuni particulare. Pachetele de control sunt distribuite n acelai mod ca i pachetele de date. Fiecare pachet RTCP include un raport al transmitorului i/sau un raport al receptorului care prezint statistici cum ar fi numrul de pachete trimise, numrul de pachete pierdute, jitterul, ntrzierea fat de ultimul raport, timpul de emisie al ultimului raport, etc, utile pentru aplicaiilor. RTCP are patru funcii separate: Funcia principal este de a furniza feedback cu privire la calitatea distribuiei de date. Informaiile primite prin aceast cale putnd fi folosite la controlul unei codri adaptive (codec adaptiv). Experimentele folosind multiplexarea IP au artat c feedback-ul este critic pentru diagnosticul greelilor n distribuie. Aceast funcie este realizat prin folosirea a dou rapoarte: raportul transmitorului i raportul receptorului. RTCP identific toi participani unei sesiuni. Acest protocol face acest lucru prin transportul unui identificator de nivel transport al fiecrei surse numit nume canonic (CNAME) (canonical name) i al unui identificator de surs de sincronizare (SSRC). SSRC-ul se poate schimba ntr-o sesiune. Identificatorul CNAME este de asemenea folosit pentru sincronizarea fluxurilor multimedia multiple. Cnd un participant prsete conferina este trimis un pachet RTCP BYE. Pachetele protocolului sunt trimise pentru a ndeplini primele dou funcii, de aceea rata cu care sunt trimise pachetele este de asemenea controlat. Acest control al ratei este realizat de RTCP. Numrul de participani observat este folosit pentru determinarea valorii acestei rate. Cu ct numrul participanilor este mai mare cu att rata cu care se trimite pachete de ctre fiecare participant este mai mic. A patra funcie (opional) este de a transporta minimum de informaie de control a sesiunii, pentru, ca exemplu, s se poat face identificarea participanilor n interfaa grafic. Toi participani trebuie s trimit pachete RTCP, fapt ce poate crea probleme pentru conferinele pe baz de multicast de mari dimensiuni deoarece traficul RTCP va create liniar cu creterea numrului de participani. Acceast problem nu exist cu fluxurile RTP n conferinele audio ce folosesc suprimarea pauzelor, deoarece oameni nu vorbesc de regul n acelai timp.

Deoarece numrul de participani este cunoscut tuturor ce ascult rapoartele RTCP, fiecare din acetia i poate controla rata cu care trimite aceste rapoarte. Acest fapt este folosit pentru a limita banda folosite de RTCP la o valoare rezonabil, de obicei nu mai mult de 5% din banda alocat sesiunii. Aceast band trebuie mprit de toi participanii. n standarde se stipuleaz c transmitorilor activi le revine un sfert din aceast band deoarece informaiile coninute n raportele transmitorilor sunt foarte importante pentru receptori. Cea ce rmne se mparte ntre receptori. Chiar i pentru cele mai mici sesiuni, cea mai mare rat cu care se poate transmite, de ctre un participant, un raport RTCP este unul la fiecare 5 secunde. Rata cu care se transmite este aleatorizat cu un factor de 0,5 pn la 1,5 pentru a nu se crea sincronizri nedorite ntre rapoarte. Valoarea medie a ratei este derivat, de fiecare participant, din mrimea pachetului pe care vrea s-l trimit i din numrul de transmitori i receptori din pavhetele pe care le primete. Sunt mai multe tipuri de pachete RTCP, unul pentru fiecare tip de informaie: SR: reprezint raportul transmitorului i conine informaiile de transmisie i recepie despre transmitorii activi; RR: reprezint raportul receptorului i conine informaiile despre asculttorii ce nu sunt i transmitori activi; SDES: reprezint descrierea sursei i conine numeroi parametrii referitori la surs, incluznd i CNAME; BYE: reprezint raportul trimis atunci cnd un participant prsete conferint; APP: prezint funciile specifice unei aplicaii. Cteva pachete RTCP pot fi incluse ntr-un singur pachet al protocolului de transport. Fiecare mesaj RTCP conine destule informaii pentru a fi decodat fr probleme dac mai multe asemenea mesaje sunt ncapsulate n acelai pachet UDP. Acest mod de folosire este folositor pentru a transmite eficient informaia, innd cont de dimensiunile antetului protocolului de transport. Rapoartele receptorului i ale transmitorului (figura I.5) Fiecare SR (sender report) conine trei seciuni obligatori. Prima seciune conine: 5 bii pentru numrul de rapoarte coninute n acest raport; tipul pachetului, care n cazul SR-ului este 200; lungimea acestui raport pe 16 bii i numrul de bii introdui ca umplutur pe 32 de bii;

SSRC-ul transmitorului acestui raport. Acest indentificator se va regsi i n pachetele RTP ce pleac de la acesta. A doua seciune conine informaiile despre fluxul RTP ce este trimis de acest transmitor: informaia de timp ce conine data la care a fost trimis acest raport. Aceasta poate s fie absolut sau relativ fat de momentul nceperii sesiunii. informaia de timp RTP ce reprezint acelai lucru ca mai sus dar folosind regulile de la pachetele RTP; numrul de pachete trimise de acest transmitor de la nceputul sesiunii pe 16 bii. Este resetat dac SSRC-ul este schimbat; numrul de octei de date ce au fost trimise de la nceputul sesiunii. Aceste este de semenea resetat cnd se schimb SSRC-ul. Cea de-a treia seciune conine un set de fragmente ale raportului de recepie, unul pentru fiecare surs de care a auzit de cnd a trimis ultimul SR sau RR. Fiecare are acelai format. Acestea conin: SSRC (indentificatorul sursei): 32 de bii identificatorul sursei despre care se face raportul; rata pierderilor: 8 bii valoarea rotunjit a raportului (pachete primite/pachete pierdute*256); numrul total al pachetelor pierdute (24 bii) de la nceputul recepiei. Pachetele ntrziate nu sunt numrate ca pierdute iar pachetele duplicate sunt numrate ca primite; cel mai mare numr de secven primit, variant extins: (32 bii). Cei mai importani 16 bii conin numrul de cicluri ale numrului de secven iar ultimi 16 bii conin cel mai mare numr de secven primit ntr-un pachet RTP de la sursa indicat n primul cmp; jitterul: 32 de bii. O estimare a variaiei a timpului scurs ntre sosirile pachetelor RTP, msurat n uniti n care se msoar i informaia de timp i exprimat ca un numr ntreg fr semn. Jitterul J este definit ca deviaia medie a diferenei ntre distanele n timp de la receptor fa de cele la transmitor pentru o pachete consecutive. Aa cum este artat n relaia de mai jos, definiia este echivalent cu diferena timpului de propagare relativ pentru cele dou pachete; timpul de propagare relativ este diferena ntre informaia de timp nscris n pachetul RTP i timpul indicat de ceasul receptorului atunci la momentul sosirii pachetului, msurate n acelai uniti. Dac Si reprezint informaia de timp purtat de pachetul i i Ri este timpul de sosire al acestuia, atunci pentru cele dou pachete i i j, D poate fi exprimat ca: D(i,j)=(Rj-Ri)-(Sj-Si)=(Rj-Sj)-(Ri-Si). Jitterul este calculat n mod continuu la fiecare

sosire a unui pachet i de la sursa SSRC_n, folosind aceast diferen D pentru acest pachet i pentru pachetul i-1 n ordinea sosirii (nu neaprat n secven), conform formulei: J=J+(|D(i1,i)|-J)/16. Cnd se emite un raport, valoarea curent a lui J este preluat. informaia de timp coninut de ultimul raport al sursei (LSR): 32 de bii. Se folosesc cei 32 de bii din mijlocul informaiei de timp coninut de ultimul raport primit din partea unei surse (aceast form se numete forma compact). ntrzierea fa de momentul cnd s-a primit ultimul raport SR (DLSR): 32 de bii. Exprimat n forma compact (mai simplu n multipli de 1/65536s). mpreun cu LSR transmitorul acestui ultim SR poate folosi aceast informaie pentru a calcula timpul dusntors. Rapotul receptorului arat ca raportul transmitorului, cu diferenele c valoarea cmpului ce indic tipul informaiei transportate (PT) este egal cu 201 i seciunea a doua lipsete. Acest raport poate fi folosit de receptorii pasivi care nu genereaz fluxuri de RTP.

SDES: pachetul RTCP de descriere al sursei (figura I.6) Un pachet SDES are cmpul PT egal cu 202 i conine poriuni unde se enumer sursele (SC). Fiecare poriune conine un SSRC sau un CSRC i o list de informaii. Fiecare element din list este prezentat folosind formatul tip, lungime, valoare. Urmtoarele tipuri exist dar doar CNAME trebuie s existe: CNAME(unic n cadrul unei sesiuni) este de forma utilizator@main_gazd, adresa IP sau numele domeniului mainii gazd; NAME, numele obinuit al sursei; EMAIL; PHONE, numrul de telefon; LOC, locaia mainii surs. n figura 6 se prezint pachetul SDES.

BYE (figura I.7) Pachetul RTCP BYE indic c unul sau mai multe surse indicate prin poriuni de enumerare (SC) nu mai sunt active.

Figura I.5 Raportul transmitorului

APP: pachetul RTCP definit de aplicaie (figura I.8) Acest pachet poate fi folosit pentru a transporta informaii ce in numai de aplicaia folosit. Cmpul PT este setat la valoarea 204. Detalii n plus se pot gsi n RFC 1889[4], IP telephony [2].

Figura I.6 Descrierea surselor

Figura I.7 Pachetul BYE

Figura I.8 Pachetul APP

2.4 RTSP (Real Time Streaming Protocol RFC 2326)

Protocolul pentru fluxurile n timp real sau RTSP [5] este un protocol de nivel aplicaie pentru controlul livrrii datelor cu proprietti de timp real. RTSP furnizeaz o baz extensibil pentru a permite transportul controlat, la cerere, al datelor de timp real, cum ar fi cele audio i video. Sursele de date pot fi att aparatele ce capteaz n momentul transmisiei c i date stocate. Acest protocol este proiectat pentru a controla multiple sesiuni de transfer de date, pentru a furniza mijloacele prin care se alege canalele de transport, cum ar fi UDP, multicast UDP sau TCP i pentru a furniza mijloacele pentru alegerea mecanismel or de transport bazate pe RTP.

RTSP stabilete i controleaz unul sau mai multe fluxuri sincronizate de date continue cum ar fi audio sau video. n mod normal nu transport el nsui aceste fluxuri, cu toate c interpunerea fluxurilor media cu fluxul de control este posibil. Cu alte cuvinte, RTSP propune un control la distan prin reea al server-elor multimedia. Setul de fluxuri ce trebuiesc controlate sunt definite de o descriere a prezentrii (presentation description). Formatul acestei descrieri se face ntr-un document ce trebuie s fie specificat la implementarea protocolului. Nu exist noiunea de conexiune RTSP, dar serverul menine o sesiune etichetat cu ajutorul unui identificator. O astfel de sesiune nu este legat n nici un fel de conexiunea de la nivelul transport, cum ar fi de exemplu o conexiune TCP. n timpul unei sesiuni RTSP, un client poate deschide i nchide mai multe conexiuni sigure de transport ctre server pentru a trimite cereri RTSP sau poate folosi un protocol fr conexiune cum ar fi UDP. Fluxurile controlate de RTSP pot folosi RTP, dar modul de funcionare al protocolului prezentat nu depinde de mecanismul de transport folosit pentru a duce datele n timp real. Protocolul este intenionat asemntor n sintax i mod de operare cu HTTP versiunea 1.1 [7]. HTTP adic Hypertext Transfer Protocol este un protocol de nivel aplicaie pentru sistemele aflate la distan i care comunic ntre ele. Este un protocol generic, fr stri. Acesta a fost folosit de ctre iniiativa global informatic World Wide Web nc din 1990. Prima versiune HTTP/0.9 a fost un simplu protocol pentru transferul datelor neprelucrate prin Internet. Versiunea 1.0, cum a fost definit n RFC-ul 1495, a mbuntit protocolul prin faptul c a permis mesajelor s aib un format asemntor cu formatul MIME (Multipurpose Internet Mail Extensions), mesaje ce conineau informaii despre datele transportate i modificatori ai semanticii mesajelor de cerere i rspuns. Versiunea 1.1 include cerine mai dure dect versiunea anterioar cu scopul de a furniza implementri sigure a caracteristicilor acestui protocol. HTTP asigur un set de metode i antete ce indic scopul unei cereri. Acesta este construit pe disciplina referinelor furnizate de Uniform Resource Identifier(URI), ca locaie URL sau ca nume URN, pentru a indica resursa pentru care se va aplica metoda. Mesajele sunt trimise ntr-un format similar cu cel folosit n sistemele de pot electronic din Internet definit n documentul Multipurpose Internet Mail Extensions (MIME). HTTP este de altfel folosit i ca protocol de comunicaie ntre agentul utilizatorului (aplicaia care ruleaz la cererea utilizatorului), gateway-uri sau proxy-uri i alte sisteme din Internet, incluznd i pe acelea ce suport protocoalele FTP i SMTP. n acest mod HTTP permite acesul la resursele disponibile de la diverse aplicaii.

HTTP este un protocol de tip cerere rspuns. Un client trimite o cerere ctre server, ce conine metoda cerut, un cmp URI, o versiune de protocol urmat de un mesaj de format asemntor cu MIME ce are n componen modificatori de sintax a cereri, informaii despre client, i posibil coninutul mesajului pe o conexiune cu serverul. Acesta rspunde cu o linie de stare, ce include versiunea protocolului i un cod de succes sau de erore urmat de un mesaj asemntor MIME ce conine informaiile despre server, informaiile despre entitatea indicat n cerere i posibil corpul entitii. Protocolul RTSP se difereniaz de HTTP/1.1 prin urmtoarele aspecte: introduce un numr de noi metode i are un identificator de protocol diferit; un server RTSP trebuie s menin o stare n toate cazurile, spre deosebire de natura fr stri a HTTP-ului. i clientul i serverul pot emite cereri. datele sunt transportate de ctre un alt protocol. setul de caractere folosite n compunerea mesajelor este altul. identificatorul resursei URI este n cadrul unei cereri ntotdeauna absolut. Aceste modificri duc la implementarea mai uoar a unor situaii n care exist mai multe ierarhii de directoare pe o singur gazd cu o singur adres IP. Protocolul permite urmtoarele operaii: - obinerea de informaii de la un server. Clientul poate cere o descriere a prezentrilor prin HTTP sau alt metod. Dac prezentarea este trimis n mod multicast atunci descrierea conine adresa de multicast i porturile utilizate pentru fluxurile media. Dac doar acest client este vizat de prezentare, adic numai el va primi fluxurile media prin unicast atunci clientul va oferi destinaia din motive de securitate. - invitarea unui server media la o conferin. Un server media poate fi invitat la o conferin, fie pentru a reda fiiere multimedia, fie pentru a nregistra toat sau o parte din conferin. Acest operaie este foarte util pentru aplicaiile de nvmnt la distan. - informarea utilizatorilor despre tipurile de date n timp real disponibile pentru o prezentare existent deja. n special pentru prezentrile n timp real, este util s se informeze pe cei care particip de ctre server ce tipuri de date n timp real au devenit disponibile. Sunt necesare cteva precizri: Prezentarea. Reprezint unul sau mai multe fluxuri prezentate de ctre server clienilor ca o transmisiune multimedia complet, folosind descrierea prezentrii care este definit mai jos. n cele mai multe cazuri n contextul RTSP, aceasta implic controlul asupra acelor fluxuri, dar nu ntotdeauna este aa.

Descrierea prezentrii. O descriere a unei prezentri conine informaii asupra unuia sau mai multe fluxuri media din cadrul prezentrii, cum ar fi setul de codecuri folosit, adresele folosite i informaii despre coninut. n alte protocoale propuse de IETF ca SDP (Session Description Protocol) folosesc termenul de sesiune pentru o prezentare n timp real. Descrierea prezentrii poate avea mai multe formate, incluznd dar nu numai formatul SDP. Flux media. Reprezint un singur flux de date ce pot fi audio, video sau datele provenite de la un whiteboard. Cnd se folosete RTP, un flux conine toate pachetele RTP i RTCP create de o surs ntr-o sesiune RTP. Mesaj. Este unitatea de baz n comunicaia RTSP. Entitate. Reprezint informaia transferat n cadrul unui rspuns sau cereri. Sesiunea RTSP. Reprezint o tranzacie complet RTSP, cum ar fi vizionarea unui film. O sesiune const de obicei n crearea de ctre client a unui mecanism de transport pentru fluxul media, pornirea redrii i nchiderea fluxului. Protocolul RTSP are urmtoarele proprieti: Extensibil. Metode i parametri noi pot fi foarte uor adugai la acest protocol; Uor de analizat. RTSP poate analizat de ctre analizoarele standard HTTP sau MIME; Sigur. RTSP reutilizeaz mecanismele reelei de securitate. Toate mecanismele de autentificare folosite n HTTP sunt direct aplicabile. Se pot folosi i mecanismele de securitate ale nivelurilor transport i reea; Independent de modul de transport. RTSP poate folosi protocolul cu datagrame nesigur UDP sau protocolul sigur pe baz de fluxuri ca RTP. Capabil de lucrul cu mai multe servere. Fiecare flux media dintr-o prezentare poate fi stocat pe diferite servere. Clientul n mod automat stabilete mai multe sesiuni de control concurente cu severele ce conin fiierele media. Sincronizarea se face la nivelul transport; Controleaz aparatele ce fac nregistrarea. Protocolul poate controla att aparatele ce fac nregistrarea sau redarea fiierelor media ct i a aparatelor ce fac aceste funci n mod alternativ; Separ controlul fluxului de iniializarea conferinei. Controlul fluxului este separat de invitarea la conferin a server-elor. Singura cerin n acest caz este ca protocolul ce iniiaz conferint s furnizeze sau utilizat pentru a crea un identificator pentru conferin. n particular SIP sau H.323 pot fi utilizai pentru invitarea unui server la o conferin. Prin server se nelege orice sistem ce dorete sau este solicitat s trimit date n timp real.

Potrivit pentru aplicaiile profesionale. RTSP furnizeaz o acuratee mare, la nivelul cadrelor ce permite editarea la distan; Neutru din punct de vedere al descrierii prezentrii. Protocolul nu impune un format de descriere i poate comunica tipul descrierii ce va fi folosit. Totui, descrierea trebuie s aib cel puin un identificator al resursei adic un URI; Permite folosirea sistemelor firewall i proxy. Protocolul poate fi manevrat cu uurin att de sistemele firewall la nivel aplicaie ct i de cele la nivel transport. Un astfel de sistem trebuie s neleag metoda SETUP pentru a deschide un canal de comunicaie pentru fluxul media de pe UDP; Folosete HTTP. Acolo unde este nevoie, RTSP reutilizeaz conceptele HTTP pentru ca infrastuctura existent s nu fie modificat; Permite controlul rezonabil al server-ului. Dac un client poate s porneasc un flux de date, atunci el trebuie s aib capacitatea i s opreasc fluxul. Server-ele nu trebuie s porneasc trimiterea unui flux ntr-un asemenea mod nct clientul s nu poat s opreasc acel flux; Permite negocierea metodei de transport. Clientul poate negocia metoda de transport nainte de a fi nevoit s proceseze un flux de date n timp real; Permite negocierea capacitilor. Dac caracteristicile de baz nu sunt disponibile, trebuie s existe un mecanism pentru ca clientul s determine ce metode nu vor fi implementate. Aceasta permite clienilor s afieze interfaa grafic corespunztoare. De exemplu, dac srirea unor poriuni din film nu este permis, atunci interfaa grafic trebuie s fie n stare s mpiedice micarea indicatorului de poziie n timp al filmului. Fiecare prezentare i flux media poate fi identificat de un URL. Prezentarea n sine i proprietile fluxurilor din care aceasta este format sunt definite de un document ce conine descrierea prezentrii. Acest document poate fi obinut de ctre client folosind HTTP sau alte mijloace cum ar fi pota electronic i nu este obligatorul s fie stocat pe serverul media. n general aceast document trebuie s conin descrierea mediilor ce formeaz prezentarea, incluznd i codecurile folosite, limbajul i ali parametri care permit clientului s aleag cea mai potrivit combinaie. n acest descriere a prezentrii fiecare flux media controlat de RTSP este identificat printr-un URL al protocolului RTSP, care indic spre server-ul ce prelucreaz acel flux i poart numele ori a fluxului ori a server-ului. Mai multe fluxuri media pot fi localizate pe servere diferite; de exemplu, fluxurile audio i video pot fi mprite pe mai multe server-e pentru ca ncrcarea acestora s fie echitabil. Descrierea enumer i ce metode de transport poate folosi un server.

Pe lng parametri mediilor folosite, adresa de reea destinaie i portul trebuiesc determinai. Cteva moduri de operare pot fi distinse: Unicast: datele audio sau video sunt transmise spre locul de unde a fost trimis cererea RTSP, cu numrul portului ales de client. Este posibil ca datele s fie transmise pe acelai flux sigur ca RSTP. Multicast cu alegerea adresei de ctre server: aceasta alege i adresa i portul. Aceasta este cazul tipic pentru o transmisie n timp real sau aproape de o transmisie la cerere. Multicast cu legerea adresei de ctre client: dac server-ul trebuie s participe la o conferin deja existent, adresa de multicast, portul i modalitatea de codare sunt precizate de descrierea conferinei. RTSP controleaz un flux care poate fi trimis prin intermediul unui protocol separat, independent de canalul de control. De exemplu, controlul RTSP se poate face prin intermediul unei conexiuni TCP iar datele pot fi transportate cu ajutorul protocolului UDP. Astfel, livrarea datelor continu i dac nici o alt cerere RTSP nu este recepionat de ctre server. Totui, pe timpul vieii unei conexiuni, un singur flux media poate fi controlat prin cereri RTSP trimise n mod secvenial pe diferite conexiuni TCP. De aceea, server-ul trebuie s menin o stare a sesiunii pentru a fi capabil s coreleze cererile cu un flux. Multe metode din cadrul RTSP nu contribuie la modificarea strii. Totui urmtoarele joac un rol central n definirea alocrii i utilizrii resurselor n server: SETUP, PLAY, RECORD, PAUSE i TEARDOWN. Metoda SETUP face ca server-ul s aloce resurse pentru un flux i s porneasc o sesiune RTSP. Metodele PLAY i RECORD pornesc transmisia datelor pentru un flux alocat prin metoda SETUP. Metoda PAUSE oprete temporar un flux fr a elibera resursele server-ului. Metoda TEARDOWN elibereaz resursele asociate cu fluxul media. Sesiunea nceteaz s mai existe n server. Metodele care contribuie la starea unei sesiuni conin cmpul antet sesiune pentru a indica starea crei sesiuni o manipuleaz. Serverul genereaz un identificator al sesiunii n rspuns la o cerere de tip SETUP. Server-ul, dup ce primete cererile cu metodele de mai sus, rspunde cu un mesaj ce conine n principal o linie de stare format din versiunea protocolului, un cod de trei cifre ce indic clientului succesul sau insuccesul aciunii cerute prin metoda trimis i o fraz textual ce indic n cuvinte ce nseamn codul. Prima cifr din cod definete clasa rspunsului.

Ultimele dou cifre nu au nici un rol n ierarhia raspunsurilor. Exist 5 valori posibile pentru prima cifr: 1xx: rspuns informaional rspuns primit, procesul continu; 2xx: succes aciunea a fost primit cu succes, neleas i acceptat; 3xx: ndrumare ctre alte adrese trebuiesc luate aciuni n plus pentru a completa cererea; 4xx: eroare de client cererea conine erori de sintax i nu poate fi ndeplinit; 5xx: eroare de server server-ul nu poate ndeplini o cerere ce pare valid. Codurile sunt incluse n sintaxa rspunsului pentru a fi citite i nelese de ctre automate iar frazele ce le urmeaz sunt destinate utilizatorilor umani. Pentru informaii n plus recomand RFC 2326 [5]

3 Semnalizarea

3.1 Introducere Semnalizarea reprezit procesul ce permite iniializarea i controlul unei conversaii ntre dou sau mai multe persoane. n cazul telefoniei prin Internet de acest lucru se ocup protocoalele de semnalizare. Acestea sunt folosite pentru a stabili i controla sesiunile sau apelurile multimedia. Aceste sesiuni includ conferine multimedia, telefonie, nvmnt la distan i alte astfel de aplicaii. Protocoalele de semnalizare peste IP sunt folosite s interconecteze clieni software i hardware prin reele locale (LAN) sau prin Internet. Principalele funcii ale acestui tip de protocoale sunt: cutarea unui utilizator, translaia de adrese i nume, stabilirea unei conexiuni, negocierea parametrilor unui apel, schimbul parametrilor specifici aparatelor folosite n conversaie, ntreruperea unui apel i managementul participanilor la o conversaie cum ar fi invitarea de noi participani. Alte servicii, cum ar fi securitatea, tarifarea, anunarea sesiunilor pot fi incluse n aceste protocoale. Semnalizarea este foarte strns legat de transmisia fluxurilor de date, dar aceasta nu face parte din semnalizare. Astzi dou protocoale de semnalizare exist pe pia: H.323 i SIP. Aceste dou protocoale reprezint dou abordri diferite asupra aceleiai probleme: semnalizarea i controlul conferinelor multimedia.

H.323 este un standard umbrel de la International Telecomunications Union (ITU) pentru comunicaii multimedia peste reele locale (LAN-uri) care nu furnizeaz nici un fel de garanie privind calitatea serviciilor. H.323 face parte din o serie mai mare de standarde pentru comunicaii numit seria H.32x, ce conine standarde pentru conferine multimedia peste tipuri diferite de reele, incluznd ISDN i PSTN. Specificaia H.323 a fost aprobat n 1996, dar primele standarde din seria H.32x au fost aprobate nc din 1990. Versiunea 2 a standardului se refer la conferinele peste reelele de mari dimensiuni de tipul WAN (Wide Area Networks) i a fost aprobat n 1998. Aceast versiune a adugat i specificaii pentru comunicaia ntre reelele de pachete i cele de circuite. Versiunea 3 a fost aprobat n anul 2000 i conine specificaii pentru transmisia fax-urilor peste reelele de pachete, pentru comunicaia ntre managerii de apeluri i pentru mecanisme mai rapide pentru stabilirea conexiunii telefonice. n curnd va apare i versiunea 4. H.323 reprezint o abordare tradiional folosind tehnicile telefoniei prin reelele de circuite, bazate pe protcolul de semnalizare ISDN Q.931. Protocolul denumit Session Initiation Protocol pe scurt SIP [9] este dezvoltat de grupul de lucru Multiparty Multimedia Session Control (MMUSIC) ce face parte din Internet Engineering Task Force (IETF). Acest protocol este mai puin cunoscut dect H.323 i de aceea va fi dezbtut pe larg n urmtoarele pagini. SIP este un protocol mai simplu i se bazeaz pe protocolul HTTP. El a fost proiectat iniial pentru conferinele multimedia ce folosesc Internetul.

3.2 SIP sau Protocolul de Iniiere a Sesiunii (RFC 3261)

3.2.1 Introducere SIP

SIP este definit n RFC-ul 3261 din iunie 2002, document ce ia locul RFC-ului 2543 din martie 1999. Protocolul de Initializare al Sesiunii (SIP) a fost gndit pentru a se asigura un mod avansat de control al nceperii, terminrii si administrrii modului n care se transmit datele ntr-o reea. La dezvoltarea protocolului s-a inut cont de faptul ca acesta va trebui sa ruleze eficient pe diverse variante de servicii multimedia. Cu ajutorul SIP se pot localiza ntr-o maniera scalabil resursele dintr-o reea si, indiferent de localizarea fizica a acestora, se pot iniia si negocia caracteristicile sesiunii de

comunicare. Cateva dintre domeniile care suporta acest protocol sunt aplicatiile de telefonie IP si videoconferin. Dupa cum se observ i din denumire, Protocolul de Iniializare al Sesiunii iniializeaz, administreaz si termin o sesiune de comunicaie ntr-o reea. Protocolul a fost proiectat pentru facilitarea oferirii serviciilor vocale pe reele de date. Aplicaiile care au adoptat deja acest protocol sunt cele de telefonie IP si videoconferint, ns acesta poate fi utilizat cu succes si pentru servicii de mesagerie instantanee, notificare de evenimente sau pentru administrarea altor tipuri de sesiuni de comunicare. In ceea ce priveste realizarea unei legturi pentru comunicatie, SIP este un protocol de control care ofera servicii similare cu cele oferite de protocoalele de control existente n cazul aplicaiilor de telefonie clasic, ns realizeaza acestui lucru ntr-un context strns legat de Internet. Session Initiation Protocol face parte din arhitectura promovat de civa ani de Internet Engineering Task Force, care mai cuprinde Real-Time Transport Protocol (RTP) protocolul de transport pentru date audio, video, sau alte date sensibile in ceea ce priveste timpul de transfer prin retea, Real-Time Streaming Protocol (RTSP) - pentru controlul fluxurilor multimedia la cerere, Session Description Protocol (SDP) - pentru descrierea sesiunilor multimedia, Session Announcement Protocol (SAP) - pentru anunarea sesiunilor de comunicare de la un singur emitator la mai multi receptori, Telephony Routing over IP (TRIP) - pentru localizarea celei mai bune ci de transmisie ntre Internet si reeaua de telefonie public. n principal SIP este destinat pentru asigurarea sesiunilor de comunicaie intre utilizatori identificai prin identificatori de tip e-mail sau numr de telefon. Orice echipament care are asignat un nume de gazd ntr-o reea poate lua parte la o sesiune SIP. Procesul de creare a unei legaturi SIP ncepe cu descoperirea unui utilizator indiferent de localizarea acestuia n reea, pentru ca descrierea sesiunii sa poata fi trimis utilizatorului. O caracteristic foarte important este dat de faptul c utilizatorul va menine acelai identificator, chiar daca se va schimba locaia fizic sau dispozitivul cu care acesta se conecteaza la reea. Atribuirea acestui identificator unui utilizator va fi realizat de catre furnizorul serviciului de conectare n reea sau compania telefonic. In plus, identitatea unui singur utilizator poate fi reprezentat simultan de un numr de terminale conectate la reea. n funcie de elementele logice prezente in elementele de reea SIP, se pot trimite cereri de realizare a comunicaiei catre oricare dintre terminalele care recunosc acelasi identificator (unul, mai multe sau chiar toate). Iniierea sesiunii depinde si de abilitatea parii apelate de a determina cantitatea de informatii necesare despre sesiunea n sine, astfel inct aceasta sa poat decide n ceea ce

priveste participarea sau nu la comunicaia care ar urma sa aib loc. Ca urmare, un mesaj SIP include informatii despre apelant, motivul pentru care se dorete deschiderea unei sesiuni, ct de urgent este realizarea legturii si informaii despre parametrii sesiunii de comunicare.

3.2.2 SDP SIP folosete protocolul de descriere al sesiunii (SDP) specificat n RFC-ul 2327 din aprilie 1998, elaborat de ctre grupul de lucru MMUSIC. Pentru ca un receptor s poat s fie n stare s recepioneze o sesiune SIP, acesta trebuie s cunoasc: care adres de multicast va fi folosit de ctre sesiune; care va fi portul de destinaie UDP; codecurile video sau/i audio care vor fi folosite; cteva informaii despre sesiune (numele, scurt descreiere); informaii de contact; orarul de activitate. Principalul scop al descrierii sesiunii de tip SDP este s defineasc o sintax standard pentru aceast tip de informaie. Aceste informaii pot fi livrate folosind o varietate de metode de transport, depinznd de context: protocolul pentru anunarea sesiunilor (SAP) pentru reelele multicast; protocolul pentru fluxurile de date n timp real (RTSP) pentru aplicaiile ce lucreaz cu fluxuri; SIP pentru iniializarea comunicaiilor punct la punct sau multipunct. O descripie a unei sesiuni exprimat n format SDP este scurt prezentare textual a numelui i scopului unei sesiuni i informaii despre mediul, protocoalele, codecurile i modul de transport ce sunt necesare pentru a decide dac o sesiune este de interes i pentru a cunoate ce aplicaii trebuiesc pornite pentru a participa la sesiune. SDP este pur i simplu un format pentru descrierea de sesiune nu incorporeaz un protocol de transport. n general, SDP trebuie s asigure destule informaii pentru ca un receptor s fie capabil s ia parte la o sesiune i s anune resursele ce vor fi folosite, elementelor de reea ce nu particip la sesiune dar care doresc s cunoasc aceste informaii. Pentru o sesiune poate exista sau nu o coresponden n timp. Indiferent de acest lucru o sesiune poate fi activ numai la anumite momente de timp. SDP poate transporta o list de date i ore la care o sesiune ncepe i se termin. Pentru fiecare dintre aceste dou evenimente

se poate specifica momentele de timp cnd se vor repeta. Aceste informaii sunt sunt adevrate n ntreaga reea. Se pot de asemenea specifica modificatori de timp. Descrierea unei sesiuni se compune din informaii generale care se aplic ntregii sesiuni urmate de seciuni ce sunt specifice fiecrui format al datelor n timp real transmise. Fiecare seciune conine tipul (video, audio), protocolul de transport (RTP/UDP/IP, H.320) i atributele codecului folosit. Pentru o sesiune IP de tip multicast, adresele de multicast i porturile de transport sunt de asemenea livrate receptoarelor. Aceastea reprezint adresele de destinaie i porturile de destinaie ale fluxului multicast, indiferent dac este trimis, recepionat sau ambele. Pentru o sesiune IP de tip multicast, sunt precizate n aceast descriere i adresa distant pentru fluxul media i portul de transport pentru adresa de contact. Astfel rspunsul la invitaie ar putea conine informaii similare privind locul unde apelantul s trimit fluxurile audio i video. Sintaxa SDP: O descriere a unei sesiuni const ntr-un numr de linii de text de forma: <tip>=<valoare> unde <tip> este mereu un caracter i depinde dac este liter mare sau liter mic, iar <valoare> este un text al crui format depinde de <tip>. n general <valoare> este ori un numr de cmpuri delimitate de un singur caracter spaiu sau un sir de caractere cu un format oarecare. O descriere de sesiune conine o descriere la nivelul ntregii sesiuni (care se aplic ntregii sesiuni i tuturor fluxurilor media) i opional mai multe descrieri la nivelul fluxurilor ce conine detalii ce se aplic unui singur flux. Prima parte ncepe cu linie ce are caracterele v= i continu cu prima descriere de flux media. Aceasta ncepe cu o linie ce are la ceput caracterele m= i continu cu urmtoarea descriere de flux sau cu sfitul ntregii descrieri. n general, valorile coninute n descrierea de nivel sesiune sunt valabile pentru toate fluxurile cu excepia cazului n care sunt rescrise de o valoare echivalent existent ntr-o descriere a unui flux. n continuare prezint un exemplu de descriere a unei sesiuni:

v=0 o=g.bell 877283459 877283519 IN IP4 132.151.1.19 s=Come here,Watson! u=http://www.ietf.org e=g.bell@bell-telephone.com c= IN IP4 132.151.1.19

b=CT:64 t=3086272736 0 k=clear:manhole cover m=audio 3456 RTP/AVP 96 a=rtpmap:96 VDVI/8000/1 m=video 3458 RTP/AVP 31 m=aplication 32416 udp wb a=orient:portrait Cmpurile individuale au urmtoarele sensuri i trebuie s fie n aceast ordine cu caracterul * indicnd un cmp opional: v= versiunea protocolului o= creatorul i identificatorul sesiunii s= numele sesiunii i=* informaii despre sesiune u=* link-ul (URI) descrierii e=* adres de e-mail p=* numr de telefon c=* informaii despre modul de conectare b=* informaii despre band una sau mai multe informaii de timp z=* modificator de timp cu valoarea dependent de fusul orar k=* cheie de codificare a=* zero sau mai multe atribute de sesiune zero sau mai multe descrieri de fluxuri Fiecare informaie de timp este format dintr-un cmp ce incepe cu caracterul t urmat de nc cmp opional r. t= momentul de timp cnd sesiunea este activ r=* zero sau mai multe mmente de timp cnd se repet sesiunea Fiecare descriere de flux exte format din cmpul ce are la nceputul liniei caracterul m i din alte cmpuri opionale ce furnizeaz informaii n plus: m= numele fluxului i adresa de transport

i=* titlul fluxului c=* informaii despre modul de conectare b=* informaii despre band k=* cheie de codare a=* zero sau mai multe atribute ale fluxului Cmpurile ci a din descrierea de nivel sesiune se aplic tuturor fluxurilor cu excepia cazului n care sunt rescrise de cmpurile cu acelai nume din descrierile fluxurilor.

3.2.3 SAP (RFC 2974) Acest protocol este folosit pentru a face cunoscute unui public larg, conferinele multicast i alte tipuri de sesiuni multicast. Un emitor SAP trimite n mod multicast n mod periodic pachete de informare, folosind adrese de multicast i porturi cunoscute. Un asculttor SAP afl de utilizatorii vizai de transmisia multicast folosind protocolul Multicast Scope Zone Announcement Protocol. Emitorul SAP nu este contient de prezena sau absena asculttorilor SAP. Un anun SAP este trimis viznd aceiai utilizatori ca i sesiunea pe care o anun, asigurnd c receptorii anunului pot fi receptori posibili ai sesiunii anunate. Dac o sesiune folosete adrese n mai multe zone administrative, este necesar ce emitorul SAP s trimit copii identice al anunului pentru fiecare zon administrativ. Emitorii SAP multiplii pot anuna aceiai sesiune, fapt ce ajut la robusteea protocolului n faa pierderii de pachete sau defectrii emittoarelor SAP. Durata de timp ce exist ntre dou anunri a aceleiai sesiuni este aleas astfel nct banda total folosit de toate anunurile unui singur grup SAP s rmn limit preconfigurat. Fiecare emitor SAP ar trebui s asculte celelalte anunuri pentru a determina numrul total de sesiuni anunate pentru un grup particular. SAP conine mecanisme pentru a asigura integritatea anunurilor de sesiuni, pentru a autentificarea originii unui anun i pentru codarea anunului. Formatul pachetului SAP pentru versiunea 4 a protocolului IP este prezentat n figura 9. Cmpul tipul mesajului (T) indic dac acest pachet anun o sesiune sau terge un anun. Un bit (E) indic dac sarcina pachetului este codat sau nu i un bit (C) indic dac sau nu informaia din acest pachet este comprimat. Combinaia informaiilor din cmpurile

identificatorul mesajului i sursa anunului ar trebui sa furnizeze un identificator unic al anunului care poate fi folosit pentru a identifica o versiune particular a unei sesiuni. Acest lucru este binevenit n cazul n care se memoreaz anunurile sau pentru a ignora pachetele care nu au putut fi decriptate. Deoarece acest identificator nu este garantat a fi unic, trebuiesc folosite alte metode adiionale cum ar fi verificarea lungimi pachetelor i chiar verificarea n mod periodic a coninutului pachetelor. Anunurile SAP pot fi autentificate folosind o semntur digital a informaiei transportate de pachet, folosind cmpul de autentificare opional. De asemenea acestea pot fi i codate. Totui, acest lucru nu nseamn c modul standard de a iniia o conferin privat ntr-o reea de mari dimensiuni este prin anunarea ei cu ajutorul pachetelor SAP codate pentru acest scop protocolul SIP este mai util. Principala utilizare a anunurilor SAP ar trebui s fie n reelele de tip intranet unde pot deranja puin utilizatori sau pentru a sesiunile foarte mari unde utilizatori sunt facturai pentru aprticiparea la conferin. Deoarece este uor pentru un utilizator de rea credin s rspndeasc o cheie SAP este necesar luarea de msuri suplimentare pentru accesul participanilor la conferin. SAP trebuie folosit pentru sesiuni de interes public unde participani nu sunt cunoscui n prealabil. Dac se cunosc inviataii un mecanism mai bun este invitarea lor explicit folosind SIP. Detalii se poat obine consultnd RFC 2974 [8]

Figura I.9 Pachetul SAP 3.2.4 Entitile SIP i definiii SIP reprezint satndardul IETF pentru stabilirea conexiunilor VoIP. Protocolul de Iniializare a Sesiunilor este un protocol de control la nivel aplicaie (de semnalizare) pentru crearea, modificarea i nchiderea sesiunilor cu unul sau mai muli aprticipani. Aceste sesiuni includ conferine multimedia prin Internet, apeluri telefonice prin Internet i distribuii multimedia. Participanii ntr-o sesiune pot comunica prin multicast, printr-o reea de canale unicast sau printr-o combinaia a acestor dou moduri. Arhitectura SIP este similar cu aceea a protocolului HTTP. Cererile sunt generate de ctre client i trimise serverului. Aceste proceseaz cererile i trimite un rspuns clientului. O cerere i rspunsul corespunztor formeaz o tranzacie. SIP are mesajele INVITE i ACK care definesc procesele de deschidere a de canale sigure prin care mesajele de control ale apelului pot fi trimise. Protocolul face foarte puine presupuneri cu privire la protocolul de transport. El nsui asigur sigurana transportului i nu se bazeaz pe TCP pentru aceasta. SIP se bazeaz de SDP (Protocolul de Descriere al Sesiunilor) pentru negocierea codecurilor disponibile. Protocolul de Iniializare a Sesiunilor folosete descrieri de sesiuni pentru a permite participanilor punerea de acord asupra unor tipuri de media compatibile. Acest protocol sprijin mobilitatea utilizatorului prin existena funciilor de tip proxy i de ndrumare a rspunsurilor spre locaia curent a utilizatorului. SIP asigur urmtoarele faze din stabilirea i nchiderea unei comunicaii (RFC 3261): Gsirea utilizatorului: determinarea terminalului care va fi folosit pentru comunicaie; Determinarea strii utilizatorului: protocolul poate determina dac un utilizator este disponibil s rpund la un apel sau nu; Determinarea capacitilor de comunicare: poate afla care sunt tipurile de media i proprietile acestora, ce pot fi folosite n timpul comunicaiei. Stabilirea sesiunii: anunarea parilor participante i stabilirea parametrilor la ambele capete ale sesiunii; Managementul sesiunii: include transferul i nchiderea sesiunii, modificarea parametrilor i invocarea de servicii.

Aa cum am mai spus SIP nu este un sistem de comunicaie complet. Acesta este mai degrab o component care poate fi folosit mpreun cu alte protocoale IETF pentru a forma o arhitectur multimedia complet. n mod normal aceast arhitectur va cuprinde protocoale ca RTP (RFC 1889) pentru transportul datelor de timp real i pentru a furniza un feedback n privina calitii serviciilor, RTSP (RFC 2326) pentru controlul transportului fluxurilor media, Protocolul pentru controlul gateway-urilor media (MEGACO Media Gateway Control Protocol RFC 3015) pentru controlul gateway-urilor ce sunt la marginea reelelor de pachete i fac legtura cu reelele cu comutaie de circuite i SDP (RFC 2327) pentru descrierea sesiunilor multimedia. De aceea, SIP trebuie folosit n conjuncie cu alte protocoale pentru a furniza servicii complete utilizatorilor. Totui, funcionarea protocolului nu depinde de niciun protocol. SIP nu furnizeaz servicii. n schimb, SIP folosete primitive care pot fi folosite pentru a implementa diferite servicii. De exemplu SIP poate localiza un utilizator i trimite la acea locaie cteva pachete de date. Dac aceast primitiv este folosit pentru a trimite o descriere de sesiune atunci, de exemplu, cele dou terminale pot conveni asupra parametrilor sesiunii. Dac aceeai primitiv este folosit pentru a trimite o fotografie a apelantului n acelai mod ca descrierea sesiunii, atunci un serviciu de identificare a apelantului poate fi uor de implementat. Cum a artat acest exemplu, o singur primitiv este folosit pentru a furniza diferite servicii. SIP nu ofer servicii de control a conferinelor cum ar fi controlul vorbitorului curent (floor control) sau votare i nu indic cum ar trebui condus o conferin. Acest protocol poate fi folosit pentru a iniia o sesiune care folosete un alt protocol de control al conferinelor. Deoarece mesajele SIP i sesiunile stabilite cu acestea nu pot trece prin reele complet diferite, SIP nu poate i nu ofer nici o modaliate prin care s se asigure rezervare de resurse. Din cauza naturi informaiilor transmise sigurana acestora este important. n acest scop, protocolul poate fi folosit pentru a se implementa servicii de securitate ce includ prevenirea atacurilor de tip denial-of-service, autentificarea, protecia integritii i codarea. nainte de a prezenta entitile i modul de operare al protocolului este necesar precizarea unor noiuni: Client: un program aplicaie care trimite cereri SIP. Clienii pot sau nu pot interaciona cu un utilizator uman. Server: Un server este un program aplicaie care accept cereri pentru ale prelucra i trimite napoi rspunsuri la aceste cereri. Apel: un apel const din toi participanii dintr-o conferin invitai de o surs comun. Un apel SIP este identificat de ctre un identificator unic. Astfel, dac un utilizator este invitat la acceai sesiune multicast de ctre persoane diferite, fiecare din aceste invitaii este un apel unic. O conversaie telefonic prin Internet punct la punct reprezint un singur apel SIP. Conexiune: o conexiune ce servete o conversaie este identificat printr-o combinaie de cmpuri: identificatorul apelului, adresele participanilor i valorile cmpurilor From(De

la) i To(Spre). Avnd aceeai identificator al apelului, cererile ce au cmpurile cu valorile Spre A i De la B aparin aceleiai conexiuni ca i cererile ce au cmpurile cu valorile Spre B i De la A, din direcie opus. Sesiune: n specificaia SDP o sesiune multimedia reprezint un set de transmitori i receptori i fluxurile de date ce sunt ntre acetia. O conferin multimedia este un exemplu de sesiune. Dup cum s-a mai spus un apelat poate fi invitat la aceeai sesiune de mai multe ori. Dac se folosete SDP, o sesiune este definit de concatenarea numelui utilizatorului, identificatorul sesiunii, tipul reelei, tipul adresei i elementele de adres din cmpul Origine din antet. Tranzacie SIP: are loc ntre un client i un server i conine toate mesajele de la prima cerere trimis de client server-ului pn la ultimul rspuns trimis de server ctre client. O tranzacie este identificat, ntr-o conexiune, de numrul de secven Cseq. Componentele arhitecturii SIP sunt: Agentul utilizatorului: este o aplicaie ce conine att un agent client ct i un agent server. Clientul este agentul ce trimite apelurile iar serverul este cel care le primete. Server proxy: este un program intermediar ce funcioneaz att ca server ct i ca client cu scopul de a face sau retrimite cereri din partea altor clieni. Server de ndrumare: reprezint server-ul care accept o cerere SIP i asociaz unui client mai multe adrese la care poate fi gsit. Spre deosebire de server-ul proxy, acesta nu trimite mesajul mai departe. n schimb, trimite noua adres gsit clientului cerndu-i acestuia s retrimit mesajul acolo. Server de localizare: este folosit de ctre un server proxy sau de ndrumare pentru a obine informaii despre locaiile posibile ale unui apelant. Proxy outbound : este proxy-ul ce este localizat aproape de originea unei cereri. Primete toate cererile unui agent client, incluznd i acelea care nu i sunt adresate. Proxy-ul trimite aceste cereri, dup procesri locale, la adresele din antete. Registrator: este un server ce accept cererile de nregistrare REGISTER. Monitorizeaz utilizatorii n interiorul domeniului de reea asignat. Este n mod tipic pus n aceai locaie cu un server proxy sau de ndrumare i poate face ca informaiile ce le deine s fie disponibile. Acestea sunt elemente separate logic i nu sunt implementri fizice distincte. Nu este deloc un fenomen neobinuit de a gsi servere proxy, de ndrumare i registratori care ruleaz n cadrul unei singure conversaii.

n cazul unei sesiuni SIP tipice, mesajele trimise de un agent trec prin unul sau mai multe servere proxy, dup care ajung la unul sau mai muli ageni S IP. Cu toate acestea, nu este exclus nici realizarea unei comunicaii directe (fr intermediari) ntre agenii SIP. De fapt este un fenomen de comunicaie foarte normal acela n care doar prima cerere de comunicaie trece prin serverele proxy, dup care toate celelalte mesaje vor fi schimbate direct ntre ageni.

3.2.5 Modul de operare SIP Apelanii i apelai sunt identificai prin adrese SIP. Cnd realizeaz un apel SIP, un apelant trebuie s localizeze mai nti server-ul corespunztor i s-i trimit o cerere. Pentru a fi invitat i identificat partea apelat trebuie s aib un nume. SIP folosete un identificator de tip e-mail de forma utilizator@domeniu, utilizator@gazd, utilizator@adres IP sau numr de telefon@ gateway din cauz c acest mod de adresare este cel mai rspndit n Internet. Folosind o adres de e-mail ca o adres SIP, acest protocol furnizeaz metode scalabile prin care un agent client al utilizatorului poate furniza o cerere ctre un server SIP. Apelantul poate afla unde s trimit cererea folosind serverele DNS. Prin realizarea unei serii de interogri DNS (Domain Name Server) de ctre cel ce vrea s iniieze o convorbire se poate determina adresa server -ului ce are sub control un anumit domeniu. Adresa de tip e-mail permite ca adresele SIP s fie uor transformate n informaii de tip URI (Uniform Resource Identifiers) cum ar fi sip: teodor@constantin . Avantajul acestui fapt este c aceste informaii pot fi uor introduse n pagini Web, astfel nct plin apsarea cu mouse-ul pe link-ul corespunztor iniiaz un apel ctre acea adres, ntr-un mod asemntor cu link-urile pentru trimiterea unui e-mail de genul mail to : URL. Un server de reea SIP poate trimite apelul ctre alte servere, ajungnd ntr-un final la unul care tie sigur adresa IP unde utilizatorul poate fi gsit. Procesul de determinare a urmtorului hop se numete rutare next hop. Ca un rezultat al deciziilor luate n urma rutrii, un server de reea SIP poate ajunge la concluzia c la un utilizator se poa te ajunge prin mai multe servere adiacente. n aceste cazuri, SIP permite unui server proxy s creeze mai multe copii dintr-o cerere recepionat i s o trimit pe mai multe ci paralele spre serverele adiacente. n condiii normale, fiecare server va genera un rspuns; SIP are reguli definite pentru concatenarea rspunsurilor i trimiterea acestora la agentul client. Odat ce localizarea server-ului s-a ncheiat, clientul poate trimite cereri ctre acesta. O cerere mpreun cu rspunsul corespunztor formeaz o tranzacie SIP. Cererea poate fi

trimis prin canale TCP sigure sau prin UDP. Dac se folosete un protocol sigur, cererea i rspunsurile dintr-o singur tranzacie SIP sunt transportate pe aceeai conexiune. Mai multe cereri SIP de la acelai client ctre acelai server pot fi transmise pe aceeai conexiune sau se poate folosi cte o conexiune pentru fiecare cerere. Dac un client trimite cererea printr-un protocol de datagrame n mod unicast de tipul UDP-ului, agentul ce o recepioneaz trimite rspunsul conform informaiei coninut n cmpul Via din antetul cereri. Fiecare server proxy de pe calea urmat de cerere trimite rspunsul folosind acelai cmp Via. Pentru protocoalele de datagrame, sigurana transmisiei se obine prin retransmisii. O invitaie SIP ncununat cu succes const din dou cereri: una INVITE urmat de ACK. Cererea INVITE cere apelatului s intre ntr-o conferin anume sau s stabileasc o conversaie. Dup ce apelatul a acceptat s participe, apelantul confirm c a primit rspunsul prin trimiterea unei cereri ACK. Cererea INVITE conine o descriere a sesiunii care i furnizeaz apelatului destule informaii pentru a se intra n sesiune. Dac apelatul dorete s accepte apelul, rspunde invitaiei prin trimiterea unui rspuns cu o descriere similar a sesiunii. Dup ce apelatul a acceptat s participe, apelantul confirm c a primit rspunsul prin trimiterea unei cereri ACK. Un apelat poate s i schimbe poziia n timp. Aceste locaii pot fi n mod dinamic nregistrate la un server SIP. Cnd un server SIP este interogat despre poziia apelatului, acesta ntoarce o list cu posibilele locaii. De fapt un server de localizare din siestemul SIP genereaz lista i o paseaz serverului SIP. Ar putea exista situaia n care suntem nevoii s schimbm parametrii unei sesiuni existente. Aceasta se poate realiza prin retrimiterea cererii INVITE folosind acelai identificator de apel (cmpul Call ID acelai) dar cu un nou corp al mesajului. Cererea trebuie s aib un numr de secven Cseq mai mare dect cel avut de ultima cerere a clientului ctre server. 3.2.6 Proprietile protocolului SIP Este un protocol cu stri de durat mic. O sesiune n care avem o conferin sau un apel const una sau mai multe tranzacii cerere-rspuns SIP. Fiecare dintre acestea pot parcurge rute diferite prin server-ele din reea. ntr-un apel obinuit, cererea este de tipul INVITE i poate parcurge mai multe server-e de reea n drumul ei pn la apelat. Rspunsul

la aceast cerere conine o adres amnunit care poate fi folosit de agentul client pentru a trimite cererile urmtoare direct ctre agentul server. Deoarece server-ele de reea SIP nu trebuie s menin starea apelului i dup ce o tranzacie s-a ncheiat, acestea nu dein informaii despre apelant sau apelat. Aceast caracteristic faciliteaz scalabilitatea i siguran unui server SIP, deoarece se poate bloca fr ca s afecteze tranzaciile iniiate prin el. Durata i numrul strilor meninute ntr-un server sunt mici n comparaie cu acelea din reeaua de telefonie clasic, unde o central trebuie s menin starea unui apel pentru ntreag durat a acestuia. Totui un server ce dorete s cunoasc starea unui apel poate menine starea unui apel pe ntrega durata a acestuia. Prin intermediul cmpurilor Route(rut) i RecordRoute(rut inregistrat) din antetul mesajelor SIP, fiecare proxy poate ,n mod individual, insista s fie pe calea urmat de tranzaciile urmtoare. Mai mult, proxy-ul se poate rzgndi i se poate scoate de pe calea de semnalizare. Un server de reea SIP nu trebuie s aib stri nici chiar pe durat tranzaciilor. Un server proxy sau de ndrumare poate fi complet fr stri. Dup ce primete o cerere, acesta ori genereaz un rspuns ori trimite cererea mai departe i uit tot. Mesajele conin toate informaiile necesare pentru ca un server proxy s le proceseze i s la ruteze. Aceast mod de funcionare corespunde arhitecturii bazate pe datagrame din Internet, unde pachetele conin informaii suficiente pentru a fi rutate n mod individual. n plus, un proxy cu stri poate deveni fr stri n orice moment fr a afecta modul de funcionare al protocolului. Administratorul decide n privina fiecrui apel dac un proxy va fi cu stri sau fr. Aceast flexibilitate permite existena unor servere de mari dimensiuni poziionate central n reea care sunt fr stari. Pemite i existena unor servere mai mici cu stri poziionate spre periferia reelei. Protocolul este neutru din punctul de vedere al protocoalelor de nivele inferioare. SIP face presupuneri minime asupra protocolalelor de transport i de nivel reea. Nivelele inferioare pot furniza servicii ce se bazeaz pe pachete sau fluxuri de octei i pot fi sau nu sigure. n contextul Internetului, SIP poate utiliza i UDP i TCP ca protocoale de transport. UDP permite aplicaiei s controleze mai uor momentul trimiteri mesajelor i retransmisia acestora, s realizeze cutri paralele i s foloseasc transmisie n mod multicast. Ruterele pot lucra mai repede cu pachete SIP UDP. TCP permite trecerea cu uurin prin componentele de tip firewall existente. Cnd este folosit TCP, SIP poate folosi una sau mai multe conexiuni pentru a ncerca s contacteze un utilizator sau s modifice parametri unei conferine deja existente. Cereri diferite SIP pentru acelai apel SIP pot folosi conexiuni TCP

diferite sau una singur, dup preferin. SIP poate fi folosit cu protocoalele din Internet la fel cum poate fi folosit i cu protocoale ca AAL5 de la ATM, IPX, Frame Rel ay sau X.25. Agenii utilizatorului ar putea implementa i UDP i TCP. Serverele proxy, de ndrumare, registratoarele trebuie s implementeze i UDP i TCP. Protocolul se bazeaz pe text. SIP folosete ca form de codare UTF-8. Acest fapt permite o implementare uoar n limbaje cum ar fi Java, Tcl sau Perl, permite gsirea i corectarea greilor de programare cu uurin i cel mai important face ca SIP s fie un protocol flexibil i extensibil. Cum SIP este folosit n principal pentru iniierea conferinelor multimedia dect pentru transferul datelor multimedia, se consider c procesarea n plus existent din cauza folosirii unui protocol bazat pe text nu este important.

3.2.7 Mesajele SIP Aa cum am mai spus mai devreme SIP este un protocol bazat pe text. Sintaxa mesajelor i cmpurile din antet sunt identice cu specificaia HHTP/1.1. Un mesaj SIP este sau o cerere sau un rspuns. O cerere este generat de un client i un rspuns este generat de un server. Mesajele cerere i rspuns folosesc formatul mesajului generic din RFC-ul 822 pentru transferul corpului unui mesaj. Ambele tipuri de mesaje const dintr-o linie de start, unul sau mai multe linii de antet, o linie goal (adic o linie ce nu ere nimic naintea caracterului CRLF ce indic terminarea unei linii) ce avertizeaz c s-au terminat liniile din antet i opional corpul mesajului. Formatul mesajului cerere este expus n continuare: Cerere: linie de cerere

*(antet general | antet cerere | antet corp mesaj) CRLF [corpul mesajului] unde linia de cerere este format din cmpurile: linie de cerere : metoda SP identificatorul de tip URI al sursei SP Versiunea SIP CRLF cu urmtoarele semnificaii: Cmpul metoda poate urmtoarele valori: INVITE | ACK | OPTIONS | BYE | CANCEL | REGISTER | metod extins Cmpul versiunea SIP : SIP/2.0 Cmpul SP: (spaiu liber)

Mesajele SIP folosete cmpurile antetului pentru a specifica diferite informaii despre participani, calea de urmat i altele. Aceste cmpuri sunt asemntoare cu cele de la HTTP n sintax i semantic. Ordinea n care apar nu are n general nici-o importan, cu excepia cmpurilor ce sunt introduse ntre server-e. Unele cmpuri din antet sunt folosite n toate mesajele i altele doar cnd sunt necesare. O aplicaie ce implementeaz SIP nu trebuie s neleag toate cpurile, dar ar fi de dorit s o poate face. Dac un participant SIP nu nelege un antet l poate ignora. Numrul total de cmpuri n antetul SIP este 44 i pot fi mprite n patru grupuri: Cmpurile antetului general ce exist i n cereri i n rspunsuri. Cmpurile antetului corp mesaj ce definesc informaia despre corpul mesajului sau dac acesta nu este prezent atunci despre resursa identificat de cerere. Cmpurile antetului cerere ce permit clientului s trimit informaii n plus despre cerere i despre el nsui, server-ului. Cmpurile antetului rspuns ce conin informaiile despre server i despre accesul la resursa identificat de URI din cerere. n cadrul antetului general se afl urmtoarele cmpuri mai importante: Call-ID (identificatorul apelului; de exemplu CallID:12ef-56ac4-235ade@home.ro) este folosit n multe scopuri. n cadrul cererilor de nregistrare i de obinere a parametrilo r unui server este folosit pentru a recunoate rspunsurile corespunztoare cererilor. Pentru cererile de invitare i de nregistrare este folosit i pentru a detecta copiile acestor cereri.Cererile INVITE succesive cu acelai CallID dar cu parametrii diferii pot fi folosite pentru a schimba n mod dinamic parametri ntr-o conferin. Prima parte din identificator trebuie sa fie unic pentru fiecare gazd iar ultima parte, un domeniu sau o adres IP a gazdei, l face unic n toat reeaua. Un nou CallID trebuie generat pentru fiecare nou apel. Cseq (Command Sequence, de exemplu Cseq: 1234 INVITE) trebuie s existe n fiecare cerere. Este format din un numr de secven fr semn i numele metodei. ntr-un apel, numrul de secven este incrementat cu fiecare nou cerere (cu excepia situaiei n care cererea este retransmisia unei alte cereri) i are la nceput o valoare aleatoare. Server-ul trebuie s copieze valoarea acestui cmp n toate rspunsurile ce sunt determinate de cererea ce l conine. From (de exemplu From: teo<sip:teo@home.ro>). Acest cmp trebuie s fie prezent n toate cererile i rspunsurile. Conine numele utilizatorului ce poate fi afiat n interfaa grafic (parte ce poate s lipseasc) i adresa de unde a plecat cererea. Informaii n plus pot fi

adugate. Trebuie spus c acest cmp este copiat n rspunsuri i astfel cmpul From din rspuns nu-l indic pe cel ce la trimis. To (de exemplu To: mihai<sip:home@yahoo.com>; tag=287747). Acest cmp trebuie s fie prezent i n cereri i n rspunsuri i indic destinaia dorit a cereri. Este copiat n rspuns. Valoarea cmpului tag identific destinaia n cazul n care un identificator URI SIP se indic mai multe terminale posibile. n cazul acestei situaii n rspunsuri se introduce acest cmp tag cu o valoare aleatoare pentru a se putea distinge ntre mai multe terminale. Via (de exmplu Via: SIP/2.0/UDP/PXY1.furnizor.ro; received 10.0.0.3). Cmpul Via este folosit pentru a nregistra ruta urmat de ctre o cerere, pentru a permite server-elor SIP intermediare s trimit rspunsurile pe aceeai rut. Pentru a realiza acest lucru fiecare server proxy adaug n antet un nou cmp Via la cele existente. Receptorul unei cereri poate aduga parametri opionali, de exeplu pentru a indica c a primit o cerere de la o adres care nu se afl n ultimul cmp Via. Folosind aceast informaie un server proxy poate trimite rspunsul ctre transmitorul original, chiar dac pe ruta dintre ei se afl un dispozitiv NAT ce translateaz adresele de reea. Cnd parametrul maddr ce indic existena unei adrese multicast este prezent n cmpul Via, rspunsul este trimis folosind o transmisie multicast la adresa specificat dup maddr i timpul de via este stocat n parametrul ttl. Existena acestui cmp arat c SIP a fost proiectat avnd n vedere problemele IP. Encryption (de exemplu: Encryption: PGP version=2.6.2,encoding=ascii). Acest cmp indic c corpul mesajului i posibil anumite mesaje din antet sunt codate. Antetul ce se refer la corpul mesajului conine urmtoarele cmpuri: Content-Type (de exemplu Content-Type: application/sdp). Acesta descrie tipul informaiei din corpul mesajului. n eemplul dat, antetul este urmat de o descriere a unei sesiuni n format SDP. Un alt exemplu de valoare posibil este text/html. Content-length. Indic numrul de octei al corpului mesajului. Cmpurile ce apar numai n mesajele de cerere sunt coninute n antetul cerere i au urmtoarea semnificaie: Accept (de exemplu Accept: application/sdp, text/html). Acest cmp opional indic ce tipuri de informaii sunt permise n rspuns. Sintaxa este specificat n RFC-ul 1288. Accept-Language (de exemplu Accept-Language: fr, en-gb; q=0.8, en; q=0.7). Acesta indic n ce prefer apelantul s se vorbeasc. Sintaxa este de asemenea prezentat n RFC 1288. Expires (folosit la mesajele INVITE i REGISTER; de exemplu Expires: Thu, 01 Dec 2004 16:00:00 GMT sau Expires: 5 n secunde). Pentru un mesaj de nregistrare, acest cmp

indic pentru ct timp nregistrarea va fi valid. nregistratorul poate scurta aceast perioad n rspunsul su. Pentru un mesaj de invitare, acest cmp poate fi folosit pentru limitarea duratei de cutare. Priority (de exemplu Priority: emergency). Valorile posibile sunt cele indicate n RFC 2076 plus emergency. Record-Route (folosit de asemenea i n mesajele de rspuns; de exemplu RecordRoute: sip:central.home.ro;maddr=192.190.123.234;sip:facturare.firma.ro;maddr=192.194.126.23). Unele server-e proxy pot aduga elemente noi la acest cmp dac vor s fie pe calea urmat de semnalizri. n exemplul dat cererea a trecut printr-un proxy de facturare i apoi printr-o central. Asemenea entiti trebuie s monitorizeze starea apelurilor pentru a-i indeplini scopul. Subject (de exemplu Subject:Conferin despre SIP). Acest conine text fr o sintax bine definit i are ca scop informarea apelatului despre ce va fi vorba n apel. Metodele SIP sunt listate mai jos: INVITE: o cerere INVITE invit un utilizator sau un serviciu s participe ntr-o sesiune. Corpul mesajului conine o descriere a mesajului. ACK: cererea ACK confirm c apelantul a primit un rspuns final la o cerere INVITE, confirm un rspuns afirmativ. OPTIONS: aceast metod se ocup cu informaiile privind caracteristicile participanilor i afl caracteristicile receptorului. BYE: cererea BYE nchide un apel sau termin o cerere de apel, putnd fi trimis i de apelant i de apelat. CANCEL: cererea CANCEL termin o cerere de apel nerezolvat dar nu afecteaz apelurile ce sunt n desfurare. REGISTER: metoda REGISTER este folosit pentru a nregistra locaia curent a utilizatorului. Aceast metod este folosit i atunci cnd sunt mai multe server -e SIP pe un singur calculator. n acest caz doar un singur server poate folosi portul asociat SIP. INFO: reprezint informaia din timpul apelrii cum ar fi tonurile DTMF. PRACK: este o confirmare provizorie. Alte metode ar mai putea fi COMET, SUBSCRIBE i NOTIFY. Metodele care nu sunt recunoscute de server-ele proxy sau de ndrumare sunt tratate ca fiind metoda OPTIONS i trimise ca atare. Metodele care nu sunt recunoscute de un agent server sau un registrator provoac un rspuns de tipul 501 Server Failure (eroare server).

Antetul poate fi urmat de un corp al mesajului separat de acesta printr-o linie goal (alb). Pentru cererile ACK, INVITE i OPTIONS corpul este mereu o descriere a unei sesiuni. Cmpul Content-Type trebuie s conin tipul informaiei. n eemplele date tipul corpului mesajului este Sessiun Description Protocol. Dup ce a primit i a interpretat mesajul, sistemul rspunde cu un mesaj de rspuns SIP. Linia de stare a acestuia este format din versiunea SIP, codul ce indic rspunsul i o fraz de motivare a rspunsului. Aceast fraz este o descriere textual scurt a codului. Formatul rspunsului este artat n continuare: Rspuns: linie de stare *(antet general | antet rspuns | antet al corpului mesajului) CRLF [corpul mesajului] Linie de stare= versiunea SIP SP codul SP fraz de motivare CRLF Codul= Informaional | Succes | ndrumare catre alte adrese| Eroare client | Eroare server | Eroare global | Cod extins (3 cifre) Fraza de motivare= text codat UTF-8, fr CR, LF Codul este un numr ntreg format din trei cifre, prima cifr indicnd tipul rspunsului: 1XX : Informaional: indic c s-a primit cererea i procearea acesteia continu. Acesta nu este un rspuns definitiv spre deosebire de restul. Exemplu: 180 RINGING (Sun). 2XX : Succes: rspunsul arat c s-a primit cererea, a fost neleas i acceptat. Exemplu: 200 OK. 3XX :ndrumare ctre alte adrese: trebuie s se fac operaii n plus pentru ca cererea s fie ndeplinit. Eemplu: 302 MOVED TEMPORARILY (mutat temporar). 4XX : Eroare client: cererea conine greeli de sintax sau nu poate fi ndeplinit la acest server. Exemplu: 404 NOT FOUND (nu s-a gsit destinaia dorit). 5XX : Eroare server: serverul nu poate s ndeplineasc o cerere ce pare valid. Exemplu: 501 NOT IMPLEMENTED (nu este implementat aciunea cerut) 6XX : Eroare global: Cererea nu s-a putu ndeplini la nici un server. Exemplu: 600 BUSY EVERYWHERE (ocupat peste tot). Acest mod de clasificare permite adugarea de noi coduri foarte uor. Cnd un terminal mai vechi primete un rspuns ce are un cod CXX pe care nu-l cunoate, acesta l trateaz ca fiind C00. Astefel i cele mai vechi terminale pot reaciona inteligent atunci cnd

se confrunt cu coduri necunoscute. Acestea pot da informaii adiionale utilizatorului dac fraza de motivare este prezent.

3.2.8 Exemple de apeluri SIP

3.2.8.1 Apel propriu-zis n exemplul urmtor se va prezenta mesajele schimbate ntre dou terminalele atunci cnd Teo vrea s-l sune pe Mihai. Teo indic faptul c poate primi prin RTP audio codat 0 (PCM), 3(GSM) i 4(G.723). Partea scris cu italic reprezint corpul mesajului.

C->S: INVITE sip:adi@bucuresti.rom-tel.com SIP/2.0 Via: SIP/2.0/UDP cell.rom-tel.com From: Teo<sip:Teo@craiova.rom-tel.com>;tag=3 To: Adi<sip:adi@bucuresti.rom-tel.com> Call-ID: 662606876@cell.rom-tel.com CSeq: 1 INVITE Contact: <sip:Teo@craiova.cell.rom-tel.com> Subject: Adi, vino repede. Content-Type: application/sdp Content-Length: ... v=0 o=rom 53655765 2353687637 IN IP4 128.3.4.5 s= Adi, vino repede. t=3149328600 0 c=IN IP4 cell.rom-tel.com m=audio 3456 RTP/AVP 0 3 4 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:4 G723/8000 S->C: SIP/2.0 100 Trying Via: SIP/2.0/UDP cell.rom-tel.com From: Teo<sip:Teo@craiova.rom-tel.com>;tag=3

To: Adi<sip:adi@bucuresti.rom-tel.com> ;tag=37462311 Call-ID: 662606876@cell.rom-tel.com CSeq: 1 INVITE Content-Length: 0 S->C: SIP/2.0 180 Ringing Via: SIP/2.0/UDP cell.rom-tel.com From: Teo<sip:Teo@craiova.rom-tel.com>;tag=3 To: Adi<sip:adi@bucuresti.rom-tel.com> ;tag=37462311 Call-ID: 662606876@cell.rom-tel.com CSeq: 1 INVITE Content-Length: 0 S->C: SIP/2.0 182 Queued, 2 callers ahead Via: SIP/2.0/UDP cell.rom-tel.com From: Teo<sip:Teo@craiova.rom-tel.com>;tag=3 To: Adi<sip:adi@bucuresti.rom-tel.com> ;tag=37462311 Call-ID: 662606876@cell.rom-tel.com CSeq: 1 INVITE Content-Length: 0 S->C: SIP/2.0 182 Queued, 1 caller ahead Via: SIP/2.0/UDP cell.rom-tel.com From: Teo<sip:Teo@craiova.rom-tel.com>;tag=3 To: Adi<sip:adi@bucuresti.rom-tel.com> ;tag=37462311 Call-ID: 662606876@cell.rom-tel.com CSeq: 1 INVITE Content-Length: 0 S->C: SIP/2.0 200 OK Via: SIP/2.0/UDP cell.rom-tel.com From: Teo<sip:Teo@craiova.rom-tel.com>;tag=3 To: Adi <sip:adi@bucuresti.rom-tel.com> ;tag=37462311 Call-ID: 662606876@cell.rom-tel.com CSeq: 1 INVITE Contact: sip:adi@bucuresti.rom-tel.com Content-Type: application/sdp Content-Length: ...

v=0 o=adi 4858949 4858949 IN IP4 192.1.2.3 s=vin n curnd t=3149329600 0 c=IN IP4 cell.rom-tel.com m=audio 5004 RTP/AVP 0 3 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 C->S: ACK sip:adi@ bucuresti.rom-tel.com SIP/2.0 Via: SIP/2.0/UDP cell.rom-tel.com From: Teo<sip:Teo@craiova.rom-tel.com>;tag=3 To: Adi<sip:adi@bucuresti.rom-tel.com> ;tag=37462311 Call-ID: 3298420296@cell.rom-tel.com CSeq: 1 ACK C->S: BYE sip:adi@ bucuresti.rom-tel.com SIP/2.0 Via: SIP/2.0/UDP cell.rom-tel.com From: Teo<sip:Teo@craiova.rom-tel.com>;tag=3 To: Adi <sip:adi@bucuresti.rom-tel.com> ;tag=37462311 Call-ID: 3298420296@cell.rom-tel.com CSeq: 2 BYE S->C: SIP/2.0 OK Via: SIP/2.0/UDP cell.rom-tel.com From: Teo<sip:Teo@craiova.rom-tel.com>;tag=3 To: Adi <sip:adi@bucuresti.rom-tel.com> ;tag=37462311 Call-ID: 662606876@cell.rom-tel.com CSeq: 2 BYE Exemplul ilustreaz folosirea rspunsurilor informaionale. Aici, recepia apelului este confirmat imediat (100), apoi, dup ntrzieri datorate unor procesri n baza de date, se indic sunarea celuilalt participant (180) i apelul este pus ntr-o coad, cu anunri periodice ale situaiei. Adi nu poate s primeasc dect audio PCMU i GSM. De observat c lista de codecuri ale lui Adi poate s diferere de cea a lui Teo deoarece fiecare parte trimite lista cu codecuri pe care le poate folosi la recepie. Adi va trimite datele audio la portul 3456 al

terminalului craiova.rom-tel.com iar Teo la portul 5004 al terminalului bucuresti.romtell.com. Se consider c sesiunea media este o sesiune RTP. Astfel Adi va primi pachete RTCP pe portul 5004 iar Teo le va primi pe portul 3457. Deoarece cele dou pri au convenit asupra setului de codecuri ce vor fi folosite, Teo confirm apelul fr a trimite o nou descriere de sesiune (ACK). Pentru a ncheia conversaia, Teo trimite un mesaj BYE ctre Adi.

3.2.8.2 nregistrarea Un utilizator la maina saturn.rom-tell.com se nregistreaz prin multicast la serverul local SIP numit rom-tell.com. n exemplu, agentul utilizatorului de pe saturn se ateapt s primeasc cereri SIP pe portul UDP 3890. nregistrarea expir peste dou ore. Toate invitaiile ulterioare primite pe adresa Teo@craiova.rom-tel.com sosite la server-ul SIP rom-tel.com vor fi redirecionate ctre Teo@saturn.rom-tel.com, portul UDP 3890. C->S: REGISTER sip:rom-tel.com SIP/2.0 Via: SIP/2.0/UDP saturn.rom-tel.com From: <sip:Teo@craiova.rom-tel.com>;tag=19 To: sip:Teo@craiova.rom-tel.com Call-ID: 70710@saturn.rom-tel.com CSeq: 1 REGISTER Contact: <sip:Teo@saturn.rom-tel.com:3890;transport=udp> Expires: 7200

3.2.9 Modul de operare

Figura I.10. Modul de operare proxy

n figurile I.10 i I.11 se prezint cele dou moduri n care poate lucra protocolul SIP. Astfel comunicaia ntre un server i un client se poate face direct ntre acestea dou aa cum se prezint n figura 11 sau prin intermediul unui proxy cum este prezentat n figura 10. Ultima situaie este folosit atunci cnd se dorete tarifarea utilizatorilor pentru serviciile oferite, mesajele toate trecnd prin server-ul proxy, dar i cnd se dorete folosirea serviciilor mai complexe [15].

Figura I.11 Modul de operare direct

3.2.10 Servicii avansate SIP Fr extensii SIP ofer numeroase servicii de management ale apelului. Multe din acestea fiind implementate cu ajutorul registratorilor SIP, server-elor proxy i de ndrumare. Registratorul. Un registrator este un server care accept cereri REGISTER. Acelai server poate implementa i alte funcii SIP cum ar fi un server proxy. Registratorul este folosit pentru a pstra locaia curent a unui utilizator.Adresa IP a unui utilizator se poate schimba n mai multe situaii este conectat printr-un furnizor de Internet ce asigur adrese dinamice, este conectat printr-o reea LAN unde adresele se stabilesc prin DHCP (Dynamic Host Configuration Protocol) sau un utilizator ce folosete serviciul roaming. Pentru a apela acest utilizator folosind adresa lui SIP, o entitate din reeaua SIP trebuie s menin corespondena ntre adresele SIP i adresele IP. Acesta este scopul registratorului. Pentru a facilita mobilitatea utilizatorului i pentru a evita configurarea manual ct mai mult, SIP definete o adres de multicast prin care se pot contacta toate serverele SIP (sip.mcast.net 224.0.1.75). Un client poate nregistra adresa IP curent folosind un mesaj de nregistrare multicast. Din mai multe motive, SIP limiteaz timpul de via a acestui mesaj (TTL) la 1, astfel putndu-se descoperi registratori numai n reeaua local.

Acest mod de nregistrare este asemntor cu metoda de descoperire a gatekeeperelor prezentat n H.323. Totui, n H.323, gatekeeper-ele care doresc s preia apelul pot rspunde , permind clientului s-l selecteze pe cel mai apropriat i s-l contacteze n mod direct mai trziu. n prezent, server-ele SIP nu pot rspunde la un mesaj cerere de nregistrare, de aceea clientul nu are ansa s afle adresa celui mai apropriat server, sau chiar s tie dac exist un server care ia acceptat nregistrarea. Registratorul poate fi de asemenea contactat n mod direct dac se cunoate adresa acestuia. n acest caz procedura este asemntoare ca n cazul oricrei cereri SIP. Starea registratorului nu este permanent. Dac nregistrarea nu este reactualizat aceasta va fi eliminat dup o or prin convenie (aceast valoare poate fi modificat cu ajutorul cmpului expires). Pentru a menine o nregistrare, un terminal trebuie s trimit mesaje de nregistrare n mod periodic. Dac terminalul sau utilizatorul se mut i doresc s modifice parametrii nregistrrii, acetia pot elimina nregistrarea prin trimiterea unui mesaj cu valoarea cmpului contact egal cu caracterul * i apoi prin trimiterea unui nou mesaj de nregistrare. Server proxy. Un server proxy se comport ca un server pe o parte (acceptnd cereri) i ca un client pe cealalt parte (trimind cereri). Un proxy poate trimite un mesaj fr s -i schimbe destinaia final, sau poate s-i schimbe civa parametrii nainte s- de-a drumul. Acesta chiar poate s trimit un rspuns generat local. O cerere de la A ctre B poate fi rutat prin mai multe server-e proxy. Este de dorit ca rspunsul s parcurg aceeai rut. De exemplu, un proy se poate ocupa de facturarea apelului sau de controlul unui firewall i trebuie s cunoasc situaia apelului. Cnd este folosit o conexiune TCP pentru o tranzacie SIP, n mod obinui nu sunt probleme deoarece rspunsul ajunge la cellalt capt n mod automat datorit modului de operare al protocolului TCP. Pe de alt parte, cnd se folosete UDP anumite informai trebuie s existe pentru a permite receptorului unei cereri s cunoasc unde s trimit rspunsul. Deoarece protocolul SIP nu depinde de protocolul folosit, acesta conine cmpul Via pentru a rezolva problema de mai sus. Existena acestui cmp ajut i la evitarea buclelor deoarece fiecare proxy verific dac nu este deja pe lista din cmpul Via. n fiecare moment cnd un proxy SIP trimite o cerere din partea unui utilizator, acesta adaug numele su n lista de server-e proxy strbtute de cerere. Cnd un proxy trimite un rspuns, realizeaz procesul invers i se terge de pa acea list.

Dac nu numai cererile i rspunsurile ci i toate cererile trebuie s parcurg aceeai cale, cmpul Via nu este suficient i server-ele proxy trebuie s foloseasc cmpul Recorded Route. Aceasta din cauz ca clieni SIP pot aduga un cmp Contact care permite server-elor s le trimit rspunsurile direct i astfel nu este garantat poziia serverelor proxy pe rut tuturor cererilor. Cnd acestea rescriu cmpul Recorded Route, adaug identificatorul propriu SIP URL cu o adres de tip multicast (avnd parametrul maddr) n prima poziie a listei. Cnd server-ele proxy sunt folosite pentru rutarea mesajelor de semnalizare, modelul de apelare este asemntor cu cel de la H.323 cnd se folosesc entitile gatekeeper pentru rutare, cu excepia c mesajele SIP conin destule informaii pentru a se putea cons trui servere proxy fr stri (totui nu toate funciile de baz pot fi implementate folosind entiti fra stri, cum ar fi de exemplu facturarea, caz n care trebuie s se in sub observare mesajele schimbate i strile comunicaiei pentru a verifica coerena semnalizrii). Exist anumite servere care numite forking proxy ce trimit copii a unei cereri la diferite adrese pentru a ncerca s contacteze mai multe terminale aparinnd aceleiai persoane. Acestea nu sunt transparente i pot filtra unele rspunsuri nainte s la trimit napoi clientului. Acestea pot determina situaia n care un terminal primete copii ale aceluiai mesaj cu acelai CallID, caz n care terminalul n cauz trebuie s rspund la fiecare cerere. Server de ndrumare. Un astfel de server rspunde la o cerere INVITE cu un mesaj de tipul 3XX sau rejecteaz apelul cu un mesaj de tipul eroare client sau eroare server. Rspunsul 300 multiple choices (posibiliti multiple) poate fi folosit atunci cnd utilizator identificat prim SIP URL-ul ce se afl n cerere poate fi contactat la mai multe adrese. Aceste posibiliti sunt trecute n cmpul Contact al rspunsului. Un exemplu poate fi: Contact: sip: Teo@servici.ro,sip:Teo@acasa.ro; Rspunsul 301 moved permantely (mutat definitiv) indic c utilizatorul identificat prin URL-ul din cerere nu mai poate fi contactat la aceast adres. Clientul ar trebui s ncerce la adresa furnizat n cmpul Contact al rspunsului. Acest cmp poate conine de asemenea mai multe adrese; Rspunsul 302 moved temporarily (mutat temporar) trimite (ndrum) clientul ctre noua locaie, la fel ca rspunsurile precedente, dar pentru o perioad limitat de timp, indicat prin valoarea cmpului Expires; Rspunsul 380 alternative service (serviciu alternativ) este mai complex i poate prea redundant fa de rspunsurile precedente. Pe lng faptul c furnizeaz noua locaie n

cmpul Contact, rspunsul conine de asemenea i o descriere de sesiune n corpul mesajului ce reprezint capacitile de emisie a noi locaii. De la apelant se atept ca s trimit un mesaj INVITE la aceast nou locaie i s ofere n descrierea de sesiune coninut de mesaj nite capaciti asemntoare (posibil o copie a parametrilor SDP din rspunsul 380, cu excepia portului RTP pentru recepie). Server-ul de ndrumare poate fi folosit n conjuncie cu un registrator pentru a ndruma apelurile ctre locaia curent a utilizatorului apelat. Poate fi folosit ca i o form primitiv a unui sistem de distribuie a apelurilor. Un server de ndrumare poate fi i un mijloc de a mbuntaii scalabilitatea distribuirii apelurilor sau a server-elor agent de apel. Introdus pe ruta folosit de mesaje poate distribui apelurile la mai multe servere secundare astfel obinndu-se o ncarcare egal a acestora. Aceasta se poate realiza folosind parametru maddr in cmpul Contact astfel: <sip:adresoriginal@callcenter.com:9999;maddr=adrescentral3.callcenter.com> Prin ntoarcerea acestei linii, server-ul indic apelantului c trebuie s trimit un mesaj INVITE un mesaj cu aceeai destinaie (adresoriginal@callcenter), dar la adresa indicat de paramatrul maddr. Acest parametrul indic apelantului s sar peste procedura normal de identificare a unui server SIP corespunztor ce se ocup de domeniul din adres i s foloseasc server-ul a crui domeniu a fost furnizat cu adresa maddr. Funcionarea server-ului de ndrumare este similar cu rolul jucat de ctre gatekeeeperul H.323 n modul de lucru direct. Materialul consultat pentru realizarea acestui subcapitol a fost cartea IP telephony [2].

3.2.10.1 Localizarea utilizatorilor i mobilitatea Adresele SIP sunt numite uniform resource locators (URL). Acestea sunt defapt texte ce indic nume de utilizatori sau de server-e multimedia, cu excepia cazului n care adresele SIP folosesc adrese IP. Adresele SIP nu se refer la adresele de transport ce vor fi folosite ci la o entitate abstract. Cea mai simpl form este utilizator@main dar pot exista forme n care apar numere de telefon, porturi, nume de domeniu i adrese de IP. Aceste forme sunt prezentate n tabelul urmtor: Adres SIP obinuit

Teo@netcentre.com:1234

Domeniuutilizator.com

Nu exist partea referitoare la utilizator, portul va fi 5060 Se specific portocolul de transport Server-ul vrea sa fie contactat la aceast adres Se indic folosirea adresei de transport n locul adresei SIP

support@company.fr:2345; transport=UDP 192.190.234.3:8001

support@netcentre.net; maddr=239.255.255.1;ttl=32

+33-231759329@cybercall.com; Numr de telefon valabil n toat reeaua user=phone 0231759329;isub=10;postd= w11p11@cybercall.com; user= phone central@netcentre.net priority= high&customercode=1234 Nouvenit@reg.grupdeutilizatori. com METHOD=REGISTER Numr de telefon local cu subadresa ISDN ateapt pentru ton, formeaz numrul 11 (pauz) 11 folosind tonuri DTMF Indic folosirea antetelor extinse pentru controlarea prioritii URL-urile precedente declanau treimiterea unui mesaj de invitare; acesta iniiaz o nregistrare la registratorul grupului de utilizatori reg.grupdeutilizatori.com n cele mai multe situaii adresa SIP a unui utilizator va fi aceeai cu adresa sa de email. Cele mai multe extensi (antete, maddr, etc.) nu sunt permise n cmpurile To i From, dar pot fi folosite n cmpul Contact. SIP definete o modaliate de a localiza un terminal fizic pornind de la un nume, adic de la un URL. Aceasta se face n dou faze: n primul rnd URL-ul SIP permite teminalului ce dorete stabilirea unei legturi s localizeze server-ul SIP. Acesta va fi destinaia mesajului iniial INVITE. Acest server poate fi destinaia final a apelului; dac nu se presupune c tie adresa de transport a terminalului dorit; Dac sever-ul SIP nu este destinaia final a apelului, acesta va ndruma cererea INVITE ctre terminalul cutat. Aceasta poate fi fcut ori prin instruirea terminalului apelant s trimit o nou invitaie la alt locaie folosind rspunsul 302, ori transmind invitaia n

mod transparent la adresa de transport corespunztoare. Primul model este asemntor cu modelul H.323 de apel direct iar al doilea cu modelul de apel rutat prin gatekeeper. Pentru a gsi server-ul SIP, un terminal va folosi sistemul DNS (Domain Name Server). Orice identificator SIP URL trebuie s aib o nregistrare n acest sistem. Folosind acelai mod de lucru n care de exemplu browser-ul Internet Explorer translateaz adresele textuale n adrese IP, terminalul face rost de aceste nregistrri. Folosindu -le pe acestea poate deduce adresa de transport a server-ului. innd minte adresa server-ului sau URL-ul acestuia n loc de cele ale terminalului cu care se dorete comunicarea, este posibil mutarea terminalului apelat i chiar salvarea n memorie de tip cache a URL-urilor. Dac adresa terminalului apelat s-ar menine direct n DNS atunci ar apare probleme la salvarea n memorii de tip cache a nregistrrilor. n mod normal toate nregistrrile DNS pot fi salvate de ctre rezolvatorul DNS. Acestea expir dup valoarea n secunde exprimat de parametru TTL ce este coninut de nregistrri. De aceea dac terminalul apelat se mic, apelantul va avea nc n memorie adresa greit i apelul va eua. Singura soluie este de a pune parametrul TTL la 0 i s se fac interogri DNS atunci cnd terminalul se mic. Soluie nu foarte uoar. Pe de alt parte, server-ul SIP este foarte improbabil s se mute i meninerea adresei n nregistrri DNS nu pune nici-o problem. Server-ul este anunat despre noua locaie a terminalului i poate ndruma cererea INVITE ctre locaia corespunztoare. Un agent de apel este un serviciu care se ocup apelurile spre i de la un utilizator n locul acestuia. n telefonia tradiional acest tip de serviciu este realizat de ctre infrastuctura inteligent a operatorului sau de ctre Private Branch Echange(PBX) aflat n posesia unei companii. Un agent de apel poate realiza urmtoarele sarcini: ncearc s gseasc utilizatorul prin ndrumarea mesajelor de iniializare a apelurilor (H.323 Setup sau SIP INVITE) ctre locaiile corespunztoare sau ctre mai multe locaii simultan. Implementeaz regurile de ndrumare a apelurilor cum ar fi trimiterea apelului ctre alte locaii atunci cnd sun ocupat, atunci cnd nu se rspunde sau n mod necondiionat; Implementeaz filtrarea apelurilor folosind reguli dependente de originea apelului i/sau dependente de momentul iniierii acestuia. nregistreaz ncercrile nereuite; realizeaz orice alte sacini privind managementul apelului din partea utilizatorului.

Toate aceste funcii pot fi implementate de ctre un proxy SIP. ndrumarea simpl a apelurilor i filtrarea pot fi implementate i de ctre un server de ndrumare. Server-ele proxy SIP ofer cea mai mare flexibilitate deoarece pot alege s primeasc i s trimit mai departe toate mesajele de semnalizare i astfel s monitorizeze i s controleze toate aspectele legate de un apel. Pentru a fi capabil s folosesc toate aceste servicii un utilizator trebuie s foreze toate apelurile ce vin spre el s treac prin server-ul proxy. Cel mai bun mod de a face acest lucru este de a configura nregistrarea DNS s indice spre acest server. Agentul de apel poate fi i o caracteristic a software-ului de utilizator, aceast situaie fiind mai puin practic dect cea care presupune existena unui server proxy separat i centralizat din cauz c terminalul unui utilizator poate fi stins n orice moment i poate avea o adres IP dinamic. Prin accesul bazei de date a unui registrator, un server proxy poate rezolva toate problemele legate de mobilitetea utilizatorului sau schimbarea adresei IP dac terminalele sunt configurate s foloseasc nregistrrile dinamice. De exemplu, de fiecare dat cnd un utilizator se conecteaz la Internet folosind serviciile unui furnizor, primete o adres nou IP. Dar dac sotfware-ul SIP pe care l folosete nregistreaz aceast nou adres, proxy-ul va putea s trimit toate apelurile ctre aceast adres.

3.2.10.2 Conferina SIP poate fi folosit pentru stabilirea unei conferine. Totui acesta nu ofer nici o form de control al susccesiunii vorbitorilor n acest moment (sursa acestui material este RFC 3261 emis n Iunie 2002). O conferin de tip multicast reprezint conferina n care fluxul media este trimis folosind transmisia de tip multicast. Semnalizarea corespunztoare acestui flux poate fi transmis folosind multicast sau unicast. n cazul n care se folosete semnalizarea multi-unicast (mai multe semnalizari de tip unicast), nu exist mari diferene fa de cazul conversaiei punct la punct, cu excepia faptului c descrierile de sesiune SDP indic adrese multicast. Cnd se folosete semnalizarea multicast pentru stabilirea unei conferine, cererile SIP sunt transportate folosind UDP deoarece acesta este singurul protocol care poate folosi transportul multicast peste IP. Cererile multicast vor fi folosite mai ales pentru iniializarea unor conferine i de aceea n cmpul destinaie se va afla mai degrab numele unei

conferine dect al unei persoane. Totui, este posibil s se foloseasc o cerere multicast care s foloseasc URL-ul unei persoane n cmpul destinaie, de exemplu pentru cutri de tip multicast. Rspunsurile la o cerere SIP sunt trimise napoi ctre portul UDP care a fost folosit pentru transmisie i la aceeai adres de tip multicast. Pentru a reduce traficul pe reea i pentru a evita posibilele fluxuri de rspunsuri sincronizate, s-au fcut anumite modificri fa de cazul procedurii de invitare multi-unicast, ce includ: rspunsurile 2XX nu sunt trimise; rspunsurile 6XX sunt trimise numai dac URL-ul din cmpul destinaie este acelai cu a unui utilizator ce folosete terminalul n cauz (adic dac cererea este o interogare multicast i nu o invitaie la conferin multicast); rspunsurile sunt trimise dup o ntrziere aleatoare de 0-1 secunde. Dac toate mesajele INVITE sunt trimise de o unitate central n unicast, aceasta poate furniza un mecasnism simplu de control al vorbitorului prin trimiterea unui nou mesaj INVITE cu parametrul c avnd valoarea 0.0.0.0 (valoare zero) unui terminal pentru a-i indica c nu mai are dreptul s vorbeasc i mai trziu s-i trimit un mesaj INVITE cu parametrul c cu alt valoare dect cea nul pentru a-i indica dreptul la microfon. SIP n mod nativ suport codarea n mai multe straturi. Aceast clas de codecuri codeaz informaia media folosind mai multe fluxuri de date simultane. Un flux contine informaiile de baz (suficiente pentru o redare de calitate proast) i celelalte fluxuri avnd informaii n plus ce permit reconstruirea semnalului pentru o redare de calitate superioar. Astfel un receptor poate alege raportul calitate/band cel mai bun prin luarea deciziiei de a primi unu, dou sau mai multe fluxuri de date. Acest lucru este convenabil pentru conferinele multicast, permind tuturor receptorilor s adapteze recepia conform caracteristicilor terminalelor aflate la dispoziie, astfel transmitor nefiind obligat s trimit fluxuri modificate pentru fiecare receptor. SDP descrie un flux codat n mai multe straturi astfel: c= <adres multicast de baz>/<ttl>/<numr de adrese> De exemplu: c=IN IP4 224.2.1.1/127/3. Adresele multicast trebuie s fie continue (224.2.1.1, 224.2.1.2, 224.2.1.3). Suportul protocolului SIP pentru conferinele multi-unicast este limitat. O entitate central poate fi configurat astfel nct s funcioneze ca un element MCU din H.323 care s mixeze sau s comut fluxurile media ce intr n acest aparat. n momentul de fa singurul mod de a face comutare ar fi s se trimit o invitaie SIP cu parametrul SDP c pus pe zero deoarec acesta va semnaliza terminalului s opreasc transmisia i s reactiveze transmisia prin trimiterea unui mesaj INVITE cu parametru c nenul.

SIP furnizeaz un mod simplu i elegant de a transforma un apel punct la punct (de la A la B) ntr-o conferin (A, B i C). Persoana (de exemplu A) care dorete s invite un nou participant s ia parte la conferin trimite un mesaj INVITE i persoanei deja existente (B) i participantului invitat (C) cu parametrii noi sesiunii (cum ar fi adresa multicast i eventual un alt set de codecuri spre deosebire de adresa unicast a sesiunii existente ntre A i B) dar cu acelai CallID. Meninnd valoarea parametrului CallID se semnalizeaz participantului B c aceasta nu reprezint o invitaie la o alt sesiune ci doar se schimb parametrii sesiuni existente. Controlul apelurilor pot fi activate pe o main proxy sau registrator intr-un mod simplu prin trimiterea de mesaje de nregistrare. De exemplu un utilizator care dorete s trimit temporar apelurile, cei sunt destinate, la alt locaie trimite doar un mesaj REGISTER cu numele acestuia n cmpul To i noua locaie n cmpul Contact, avnd o valoarea dorit n cmpul Expires. Caracteristici mai complicate privind controlul apelurilor nu intr n obiectivul protocolului SIP i probabil vor fi configurate folosind alte protocoale, cum ar fi HTTP. Terminalele SIP vor fi de obicei calculatoare personale multimedia i browser-ele web reprezint interfaa perfect pentru a configura un proxy complex.

3.2.10.3 Facturarea apelurilor Prin definiie, toi participani invitai de o surs comun se afl n acelai apel SIP. Acest apel este identificat printr-un identificator unic n toat reeaua, CallID. Cu aceast definiie, oconferin (cunoscut n termeni SIP ca o sesiune multimedia) poate fi format din mai multe apeluri SIP- fiecare utilizator care a contactat direct controlerul multipunct are un CallID unic. ntr-un apel fiecare conexiune poate fi identificat prin combinaia informaiilor din cmpurile To, From i CallID. Toate conexiunile pot fi grupate ntr-o sesiune multimedia comun cu ajutorul descrieri sesiunii. n PSTN un apel este de obicei pltit de persoana cere-l iniiaz. Un proxy ce este un releu pentru semnalizrile de la un terminal poate crea bazele de date pentru facturare n care se nregistreaz momentele n care se trimit mesajele INVITE, CANCEL i BYE, precum i rspunsurile. Durata unei conexiuni se poate determina ca durata n timp ntre prima cerere INVITE acceptat i prima cerere BYE.

Pentru a fora ca semnalizarea unui utilizator s trec printr -un proxy, o cale convenabil de a face acest lucru este ca proxy-ul s controleze un firewall din reea. Astfel se micoreaz posibilitaile ca un utilizator s ocoleasc proxy-ul ce este folosit pentru facturare. n tabelul asociat figuri I.12 este prezentat baza de date completat de ctre un server proxy SIP n urma mesajelor ce au trecut prin acesta. Pe baza acestor informaii poat e afla cine a sunat, cu cine a vorbit, ce servicii s-au folosit i ct a durat convorbirea i astfel poate implementa un serviciu de facturare i de autorizare. Cu ajutorul echipamentului firewall se pot nchide apelurile celor care i-au depit creditul sau nu au dreptul de a folosi serviciile de telefonie.

Figura I.12 Facturarea cu ajutorul unui proxy Operaia Informaia de timp INVITE 200 BYE INVITE 200 BYE 15/05/2003 11:11:12 15/05/2003 11:11:23 15/05/2003 11:12:45 15/05/2003 11:16:17 15/05/2003 11:16:31 15/05/2003 11:32:15 15/05/2003 11:45:12 15/05/2003 11:45:33 15/05/2003 12:33:12

Identificatorul apelului De la 4321@192.190.12.32 4321@192.190.12.32 4321@192.190.12.32 4321@192.190.12.32 4321@192.190.12.32 4321@192.190.12.32 4321@192.190.12.32 4321@192.190.12.32 4653@192.190.12.32

Spre

Teo@home Adi@home1 Teo@home Adi@home1 Teo@home Adi@home1 Teo@home Marius@home2 Teo@home Marius@home2 Teo@home Marius@home2

Teo@home Andreea@home3 INVITE Teo@home Andreea@home3 486 Teo@home George@home4 INVITE

4653@192.190.12.32 4653@192.190.12.32

Teo@home George@home4 Teo@home George@home4

200 BYE

15/05/2003 12:33:35 15/05/2003 14:11:55

3.2.11 SIP i telefonia tradiional (RFC 3372, septembrie 2002) SIP este un protocol ce poate stabili, modifica i opri sesiuni multimedia. Aceste sesiuni includ conferine multimedia, telefonie prin internet i alte aplicaii similare. SIP este unul din protocoalele de baz folosit pentru implementarea Vocii peste IP (VoIP) Cu toate c realizarea semnalizri corespunztoare apelurilor telefonice i transportul fluxurilor media peste IP au destule avantaje fa de telefonia tradiional, o reea VoIP nu poate exista izolat de reelele de telefonie existente. Este vital ca reeaua telefonic ce folosete SIP s fie capabil s interacioneze cu PSTN. O caracteristic important a oricrei reele de telefonie SIP o reprezint transparena fa de serviciile PSTN. Aceste servicii, ca de exemplu meninerea unui apel n ateptare, numere de telefon gratuite, etc. implementate n protocoale cum ar fi Signalling System No.7 (SS7) trebuie s fie oferite de o reea SIP ntr-o manier n care diferenele s fie mici n timp ce flexibilitatea protocolului SIP s nu fie limitat. Pe de alt parte, este neces ar ca SIP s aib primitivele pentru transportul acestor servicii i pentru terminalele SIP nu numai pentru cele ce cunosc SS7. Totui, este esenial ca informaia SS7 s fie disponibil la gateway-uri, puncte de interconectare SS7-SIP, pentru a asigura transparena trsturilor ce sunt suportate n SIP. Dac e posibil, informaia SS7 trebuie s fie disponibil fr pierderi n reeaua SIP; acest lucru este necesar deoarece unele reele folosesc parametri SS7 extini pentru a transmite informaii prin aceste reele. O alt important caracteristic a reelei telefonice SIP o reprezint rutarea cererilor SIP astfel o cerere SIP ce iniializeaz un apel telefonic trebuie s conin destule informaii n antelul ei pentru a fi rutat n mod corespunztor de ctre serverele proxy prin reea. Aceasta duce la faptul c este necesar ca numrul format de ctre un utilizator trebuie luat din semnalizarea SS7 i pus n cererea SIP. RFC-ul 3372 asigur un cadru pentru integrarea semnalizrii din telefonia tradiional n mesajele SIP. Acesta asigur caracteristicile de care s-a vorbit mai devreme prin tehnici cunoscute ca ncapsulare i respectiv translatare. La gateway-urile SIP-SS7, mesajele de semnalizare din telefonia tradiional sunt ncapsulate n mesajele SIP pentru ca informaiile necesare serviciilor s nu fie pierdute n cererile SIP. Totui, intermediari ca server-ele proxy ce iau deciziile de rutare nu trebuie s li se cear s neleag mesajele SS7 i

astfel simultan anumite informaii critice sunt traslatate n cmpurile corespunztoare din antetele SIP. n timp ce SIP are toate mecanismele pentru stabilirea i oprirea apelurilor, acesta nu are nici un fel de mecanism pentru a transporta informaiile din timpul apelului pe calea de semnalizare n tipul sesiunii. Aceste informaii nu schimb starea apelurilor SIP sau parametrii sesiunilor pe care SIP le iniiaz. Un mecanism de a realiza acest lucru este de asemenea necesar. Problemele care trebuiesc depite i modul de a face acest lucru este prez entat n urmtorul tabel:

Transparena la semnalizrile SS7 Rutarea mesajelor innd cont de semnalizarea ncapsulat

ncapsularea acestora n mesajele SIP Translatarea informaiei n antetulul SIP transportul informaiilor din timpul sesiunii

Transferul semnalizrilor din timpul Folosirea metodei INFO pentru apelului

De observat c exist multe moduri de semnalizare n telefonie (SS7 ISUP:ISDN User Part, BTNUP, Q.931, MF, etc.). RFC-ul 3372 se refer numai la SS7 i intete s specifice numai comportarea numai a interfaelor ISUP-SIP. Este posibil ca pe viitor s existe documente care s se ocupe cu alte sisteme de semnalizare. RFC-ul descris n acest subcapitol introduce noiunea de SIP-T adic SIP pentru telefoane ce reprezint un set de mecanisme ce sunt folosite pentru interconectarea reelelor SIP cu cele ce folosesc SS7. Scopul acestui set de mecanisme este de a asigura codificarea informaiei transportate prin semnalizare SS7 n mesaje SIP i transparena serviciilor dincolo de punctele de interconectare PSTN-SIP. SIP-T este recomandat a fi folosit acolo unde o reea VoIP este legat de o reea PSTN. Folosind SIP-T, exist trei modele simple pentru modul cum apelurile interacioneaz cu gateway-urile. Apelurile ce sunt originare dintr-o reea PSTN pot traversa gateway-ul pentru a avea ca int un terminal SIP, cum ar fi un telefon IP. n mod asemntor, un telefon IP poate iniia un apel prin care s se poarte o conversaie cu cineva legat la o reea PSTN. Ultima posibilitate de interes din punct de vedere al protocolului SIP este aceea ca o reea IP ce folosete SIP s fie doar o reea de tranzit ntre gateway-uri. n acest caz pentru a putea interconecta reeaua IP cu PSTN trebuie ca informaia SS7 primit sa fie pstrat n cere rile

SIP la gateway-ul ce iniiaz apelul SIP i s fie refolosit aceast informaie atunci cnd la gateway-ul ce se afl la cellalt capt al apelului SIP, se reconstruiete semnalizarea PSTN. Prin ncapsularea informaiilor ISUP n semnalizarea SIP, o reea telefonic ce folosete protocolul SIP asigur pstrarea tuturor informaiilor critice SS7 atunci cnd aapelul SIP este folosit pentru a face legtura ntre dou segmente PSTN. Dac ar fi fost vorba numai de schimbul de informaii ntre gateway -uri, orice protocol pentru transportul acestora ar fi fost bun, ne fiind nevoie neaprat de SIP i de SIP T. SIP-T este folosit pentru a beneficia de avantajele utilizrii SIP: rutarea cererilor i controlul apelurilor realizate de server-ele proxy, uurina n realizarea serviciilor SIP i altele. Introducerea de informaii din mesajele ISUP primite n antetul cererilor, permite intermediarilor s considere aceste informaii atunci cnd proceseaz cererile. SIP astfel faciliteaz stabilirea de apeluri i crearea de servicii pentru reeaua IP i n acelai timp prin SIP-T asigur metodele de interconectare cu PSTN. n continuare voi detalia fluxurile mesajelor de semalizare atunci cnd avem una din situaiile prezentate mai devreme: Originea apelului PSTN, inta PSTN: gateway-ul de unde se iniiaz apelul SIP primete informaiile ISUP de la reeaua de telefonie PSTN, le introduce n mesajele SIP pe care le transmite ctre gateway-ul unde se termin apelul SIP. Acesta extrage informaiile ISUP pe care le folosete n semnalizarea ctre reeaua PSTN. Se folosete rutarea SIP pentru a determina punctul de ieire din reea i pentru a a iniia negocierea unei sesiuni media ntre capete. Mesajele schimbate sunt prezentate n figura I.13. Originea PSTN i inta apelului reeaua IP: gateway-ul ce iniiaz apelul SIP primete informaii ISUP de la PSTN i le introduce n mesaje SIP ce sunt direcionate ctre agentul SIP. Terminalul nu are nevoie de informaiile ISUP ncapsulate i le ignor. (figura I.14) Originea IP i inta apelului reeaua PSTN: un telefon SIP iniiaz apelul VoIP care este rutat de unul sau mai multe server-e proxy ctre gateway-ul corespunztor. Acesta produce din informaiile date, semnalizarea ISUP i direcioneaz apelul ctre interfaa PSTN disponibil. (figura I.14)

Figura I.13 PSTN-PSTN

Figura I.14 PSTN-IP

Figura I.15 IP-PSTN Mesajele ce sunt schimbate n reelele PSTN au urmtoarea semnificaie: IAM: Initial Address Message, mesaj trimis pentru a se indica pornirea unui apel i pentru a se cere rezervarea unei pri din linia telefonic pn la abonatul apelat, ACM Address Complete Message, trimis pentru a indica disponibilitatea pri apelate i faptul c linia a fost rezervat, ANM Answer Message, trimis atunci cnd partea apelat a ridicat receptorul, REL Release Message, indic faptul c partea apelant a nchis telefonul i a terminat convorbirea, RLC Release Complete Message, confirm nchiderea convorbirii i eliberarea liniei rezervate. Din punct de vedere funcional exist trei elemente distincte ntr-o reea VoIP ce folosete SIP i interacioneaz cu PSTN: Iniiatorul apelului SIP Terminalul ce este apelat de apelul iniiat Intermediarii ce ruteaz cererile SIP Funcionarea acestor elemente este precizat n continuare: Iniiatorul. Funciile agentului ce iniiaz apelul este de a genera cererile SIP de creare a unei sesiuni cum ar fi INVITE. Cnd un apel are originea n PSTN, un gateway reprezint un iniiator. Altfel, acesta este un terminal SIP obinuit. n orice caz, se poate observa c nu se poate anticipa tipul de element cruia apelul i este destinat, adic nu se poate ti dac terminalul dorit a fi apelat se afl legat la reeaua SIP sau la PSTN. n cazul cnd un apel i

are originea n PSTN, gateway-ul ce iniiaz apelul ia necesari pai s pstreze informaia ISUP primit intact prin ncapsularea acesteia n mesajele pe care le creaz. Acesta este trebuie s recunoasc versiunea ISUP pe care a recepionat-o i s includ aceast informaie n mesajul creat. Apoi creaz antetul cereri INVITE din parametrii ISUP primii. Aceasta poate nsemna ca n cmpul To s treac un URL care s trimit la numrul format de ctre utilizator. n alte cazuri, un telefon SIP este iniiatorul unui apel VoIP. n mod normal, telefonul trimite cererea unui proxy SIP care este responsabil pentru rutarea acesteia ctre destinaia corespunztoare. Aici nu exist nici-o informaie ISUP care s fie ncapsulat. Cu toate c apelul poate avea ca int un terminal din reeaua de telefonie clasic i trebuie generat semnalizare ISUP, terminalul nu are de unde s tie aceasta i ar fi nepotrivit ca toate terminalele s genereze informaie ISUP ncapsulat. Astfel un iniiator trebuie s genereze semnalizare SIP i s realizeze ncapsularea i modificarea formatului semnalizrii atunci cnd este posibil. Terminalul apelat n reeaua SIP. Acesta este un agent SIP standard care poate fi ori un gateway ce interacioneaz cu PSTN ori un terminal SIP. n cazul n care un apelu l are ca int un terminal din reeaua PSTN, gateway-ul de ieire se afl la captul apelului SIP. Acesta genereaz informaiile ISUP corespuztoare pentru semnalizarea prin reeaua PSTN. Valorile pentru parametrii ISUP pot fi extrase din antetul cereri SIP primite sau din informaiile ISUP ncapsulate n mesaj. n cazul n care inta unui apel este un terminal SIP, agentul server care primete cererile cu informaiile ncapsulate n mod normal nu ine cont de acestea. Intermediarii. Acestora le este ncredinat sarcina de a ruta mesajele de la unul la cellalt ctre terminalele SIP i gateway-uri. Fiecare server proxy ia o decizie n privina direciei n care o s trimit un mesaj, bazat pe mai multe cmpuri din antet. SIP -T introduce anumite consideraii n plus pentru aciune de trimitere a mesajelor care pot aduce noi caracteristici i condiii de ndeplinit pentru intermediari. Asigurarea transparenei fa de ISUP este principalul scop urmrit de SIP -T. Compabilitatea ntre variantele ISUP cunoscute de interfeele PSTN ce se afl la capetele unui apel SIP poate s influeneze transparena fat de serviciile PSTN. Din cauza aceasta server-ele proxy pot ine cont de varianta folosit n luarea deciziilor de rutare. Un alt element important ce trebuie luat n considerare atunci cnd se iau deciziile de rutare o reprezint locul unde este amplasat gateway -ul unde se termin un apel SIP. Aceast locaie trebuie s fie ct mai aproape de utilizatorul apelat.

SIP-ul definit n RFC-ul 3261 nu are mijlocele pentru a transporta informaia de control care este generat n timpul unei sesiuni. Metoda INFO ce a fost definit n RFC -ul 2976 i adugat la SIP trebuie folosit pentru transportul informaiei din timpul sesiunii.

3.2.12 Securitatea apelurilor Cererile i rspunsurile SIP conin informaii importante despre modul i coninutul comunicaiei ntre utilizatori. Corpul mesajului poate conine chei de codare pentru sesiunea ce se iniializa. De aceea SIP poate utiliza dou metode complementare de codare pentru a proteja dreptul la intimitate: Codare cap la cap: se bazeaz pe cheia de codare cunoscut de cei doi ageni ai utilizatorilor implicai n tranzacie. n mod normal, mesajul este trimis codat cu cheia public a receptorului, astfel nct numai acesta s poat citi mesajul. Toate implementrile trebuie s poat folosi codarea bazat pe PGP, dar pot folosi i alte scheme de codare. O cerere sau un rspuns SIP este codat cap la cap prin mprirea mesajului ntr-o parte care este codat i un antet mic care rmne necodat. Unele pri ale mesajului SIP, cum ar fi linia de cerere, linia de rspuns i alte cmpuri trebuie citite de server-ele proxy i de aceea nu trebuiesc codate. Toate aceste cmpuri trebuie s fie poziionate naintea celor codate. Mesajul este codat ncepnd cu primul caracter al primului cmp care este codat i pn la sfritul mesajului. Codare ntre servere: nu toate cererile sau rspunsurile SIP pot fi codate cap la cap din cauz c sunt cteva cmpuri ca To sau Via care trebuie s fie vizibile pentru server-ele proxy, astfel nct cererile s fie rutate n mod corespunztor. Pentru ca utilizatorii reelei ruvoitori s nu poat citi aceste cmpuri se aplic o codare ntre server -e. Acest tip de codare se poate aplica i cererilor sau rspunsurilor care au fost deja codate cap la cap. De observat c prin acest mod de codare server-ele proxy pot afla cine pe cine sun dar aceste informaii se pot afla i din realizarea unei analize atraficului reelei, astfel aceast tehnic aduce un grad de protecie limitat dar care merit efortul. n mod normal proxy-urile nu au voie s modifice cmpurile antetelor i corpurile mesajelor. Acestea pot, totui, s codeze mesajele nemarcate cu cheia de codare a apelatului. Proxy-urile trebuie s codeze mesajele SIP dac terminalul ce le emite nu are aceast funcie sau pentru a impune politici de securitate. Msuri de protecie trebuie luate pentru a mpiedica un atacator s modifice i s retransmit cereri i rspunsuri SIP. Aceleai msuri de codare ce se aplic pentru a asigura autenticitatea unui mesaj SIP sunt folosite i pentru a autentificarea celui care a transmis

mesajul. Totui acestea mecanisme nu asigur integritatea mesajului. Mecanismele de autentificare de la nivelul transport i de la nivelul reea pot fi folosite ntre server-e. SIP poate folosi i schemele HTTP de autentificare. Toate implementrile SIP trebuie s permit folosirea autentificrii de tip PGP. Cel mai simplu mod de autentificare include o parol trimis sub form textual ntr-o cerere repetat ce este trimis ca urmare a unui rspuns neautorizat sau unui rspuns a unui proxy ce dorete autentificare la o cererea original. Schemele mai complicate presupun trimiterea unui rspuns la cererea unei entiti ce dorete se ocup cu autentificrile, rspuns ce conine un secret comun. PGP adic Pretty Good Privacy este bazat pe modelul n care clientul i dezvluie identitatea prin trimiterea unei cereri semnat cu o cheie privat. Server-ul poate n acest fel s determine originea cereri numai dac are acces la o cheie public, de preferabil semnat de o a treia entitate de ncredere. Aceste msuri nu sunt perfecte. Chiar i cu mesajele codate, o persoan ru voitoare poate s citeasc mesajele trimise i poate introduce rspunsuri neautentificate ce modific desfurarea normal a unui apel. [2]

3.3 H.323 i SIP

3.3.1 Introducere

Date fiind cele dou protocoale de semnalizare ce se afl n competiie pentru dominarea semnalizri n cadrul telefoniei prin reelele IP, se pune problema care este mai bun? Vestea bun este c cele dou standarde par s convearg lund ideile bune unul de la cellalt. n particular versiunea 3 a standardului H.323 a adugat elemente care iau crescut performana (s-a umblat la ntrzierea n iniializarea unui apel i la procesarea fr stri pentru folosirea UDP-ului), elemente care iniial erau avantaje importante ale SIP-ului. Mai important, fiecare standard n aceeai msur permit folosirea majoritii funciilor cerute de ctre utilizatori, printe acestea aflndu-se: iniializarea apelului, nchiderea unui apel, meninerea unui apel n starea de ateptare, transferarea unui apel la alt locaie, conferina i iniializarea apelului de pe o pagin Web. Singurele diferene funcionale sunt indicarea unui apel n ateptare (care este utilizat numai n H.323), controlul apelului de ctre

o a treia persoan (de exemplu o secretar care d un telefon din partea directorului, funcie utilizat numai n SIP) i cteva funcii referitoare la conferine. n timp ce funciile ce pot fi folosite sunt asemntoare, standardul H.323 (prin intermediul protocolului H.245) furnizeaz un mecanism mai robust pentru procesul n care se schimb informaiile referitoare la capacitile terminalelor, dect ofer SIP. Totui, funcionalitatea nu este singurul punct n dezbaterea H.323 vs SIP. La fel de important sunt i calitatea serviciilor (QoS), scalabilitatea, flexibilitatea i interconectarea cu alte reele. n timp ce la capitolul funcionalitate cele dou standarde sunt similare n domeniile tocmai prezentate sunt foarte diferite. n urmtorul tabel sunt prezentate caracteristicile celor dou protocoale: Asemnri Calitatea serviciilor i managementul Durata iniializrii apelului Recuperarea pachetelor pierdute Lipsa posibilitilor de rezervare a resurselor

H.323 mai bun Tolerana la defeciuni (H.323 permite gatekeeper-i i terminale redundante ) Controlul admisiei (SIP se bazeaz pe alte protocolale pentru managementul benzii, managementul apelului i pentru controlul benzii)

SIP mai bun Detecia buclelor (folosind cmpul Via din antet buclele sunt identificate mai bine dect folosind parametrul PathValue de la H.323)

Stabilitatea i flexibilitatea

Procesarea fr stri Folosirea UDP-ului Comunicaiile ntre server-e pentru localizarea terminalelor

Localizarea terminalelor n alte domenii administrative (SIP nu definete o metod dar sugereaz folosirea DNS-ului)

Complexitatea (SIP este mai simplu) Extensibilitatea (folosirea numelor de caracteristici i de coduri organizate ntr-o structur ierarhic care pot fi

nregistrate de catre organizaia IANA reprezint o metod de extindere mai flexibil dect singurul parametru folosit pentru extensie NonStandardParam) Uurina n modificare (este mai simplu i are o metod de codare bazat pe text)

Interconectarea

Interconectarea cu reeaua PSTN (H.323 folosete mesaje de tipul Q.931 ce sunt compatibile cu standardul SS7)

3.3.2 Unde SIP este mai bun SIP este simplu. Acesta face ntr-o tranzacie ce face H.323 versiunea 1 n patru sau cinci schimburi de mesaje, fiecare dintre acestea specificate n documente ITU diferite. n plus SIP poate folosi UDP, spre deosebire de versiunile 1 i 2 ale standardului H.323 ce puteau folosi numai TCP. Combinaia acestor deosebiri a dus la timpi mult mai mici pentru iniializarea unui apel n cazul folosirii SIP. Aceast situaia a dus la modificrile aprute n versiunea 2 a standardului H.323, printre care i procedura numit Fast Connect ce scurteaz timpul necesar pentru iniializarea unui apel. n versiunile ulterioare s-a adugat i posibilitatea de a lucra cu UDP. Organizaia IETF a dobndit o mare experint n transmisia datelor n mod multicast. SIP a fost creat pentru o reea ce permite transmisia n mod multicast nu numai pentru

fluxurile media ci i pentru semnalizare. De exemplu un mesaj INVITE poate fi trimis unui grup prin transmisie de tip multicast. Acest mod de operare este folositor unei instituii ce se ocup cu rezolvarea prin telefon a unor probleme dar i unui utilizator care ncearc s gseasc pe cineva ntr-o instituie. Versiunile 1 i 2 ale H.323 trebuie s foloseasc transmisia n mod multi-unicast pentru a realiza acelai lucru. Folosirea URL-urilor ca identificatori este un lucru foarte important. La o prim privire pare s nu existe o mare diferen ntre un alias de tip e-mail de la H.323 (Teo@nume.ro) i un URL de tip SIP (sip: Teo@nume.ro). n realitate exist doar una: un alias H.323 presupune c protocolul folosit este H.323, iar SIP specific protocolul chiar n URL. Din aceast cauz un server SIP poate direciona un apel ctre un server non-SIP ntr-o manier foarte flexibil. Un terminal SIP, atunci cnd este apelat de un alt terminal SIP, poate direciona apelul ctre o pagin Web sau ctre un URL de e-mail. Procedura din SIP poate fi realizat i de ctre H.323 folosindu-se tipul identificatorilor de tip URL atunci cnd se specific o adres alias, disponibil din versiunea 2 a protocolului H.225. Dar prin aceast adugare schema identificatorilor ncepe s devin foarte complicat. Muli furnizori de servicii doresc s aib posibilitatea s marcheze unele apeluri ca fiind prioritare. Cmpul Priority din antetul SIP aduce acestuia o funcie care nu exist n H.323. Trimiterea mesajelor sub form de text poate fi si un avantaj i un dezavantaj. Avantejele sunt: metod simpl, se pot depista foarte uor greile i se pot corecta l a fel de uor i problemele de interconectare se depisteaz repede. Dezavantajul principal este acela c aceast metod de codare creaz mesaje de dimensiuni mai mari dect dac s-ar fi folosit mesaje codate binar.

3.3.3 Unde este H.323 mai bun H.323 face o distincie clar ntre tipurile de media ce pot fi folosite i tipurile de media ce sunt n mod efectiv transmise n reea. SIP nu face o asemenea distincie, terminalele prezentnd doar codecurile pe care le poate folosi la recepie i nu exist nici o procedur pentru deschiderea conexiunii media n afar de trimiterea efectiv a datelor. Aceasta pare o simplificare a semnalizrii i poate aprea ca un avantaj pentru SIP. Totui n unele cazuri, n particlar n cazul n care se implementeaz un server care va fi folosit foarte mult i resursele trebuiesc meninute sub control, acest mod de lucru poate cauza probleme deoarece fiecare

server care i prezint capacitatea de recepie trebuie s asculte un port pentru a recepiona datele. Un client H.323 trebuie s nceap procesul de ascultare doar cnd primete mesajul OpenLogicalChannel. Aceast mod de funcionare al protocolului SIP poate duce la existena a mai multor procese ce nu primesc nimic i deoarece cele mai multe codecuri implementeaz funcia de detecie a pauzelor aceste procese pot s nu primeasc nimic chiar dac conferina se desfoar n mod normal, aa c nchiderea proceselor care nu fac nimic din cauz c partenerul de conversaie a disprut este foarte greu de realizat. H.323 singur sau n combinaie cu H.332 conine elemente foarte puternice de control al conferinei. SIP nu a fost creat pentru controlul modului de desfurare al conferinei i de aceea multe din elementele necesare pentru control nu exist, nc. Mesajele H.323 ce aparin protocolului H.225, fiind preluate de la Q.931, sunt codate conform standardului Q.931. Celelalte mesaje ca i mesajele ce sunt extinderea mesajelor Q.931 sunt codate conform regulilor de codare a pachetelor (PER) folosind sintaxa abstract 1 (ANS.1). Acest mod de codare a generat foarte discuii privind complexitatea H.323-ului. Folosirea a dou codri cu reguli diferite duce la eforturi mari de programare din partea companiilor care nu au implementat standardul Q.931 i nu au un compilator ANS.1. Rezolvarea problemelor de interconectare ntre terminalele H.323 necesit monitorizarea reelelor cu programe ce cunosc metodele de codare Q.931 i PER ANS.1 i care sunt mai greu de gsit. Pornirea de la zero este dificil, dar dup ce o compania are un ANS.1 i o implementare Q.931, sunt cteva advantaje n folosirea acestei codri: unitile de date ce sunt transferate ntre terminale sunt optimizate din punct de vedere al dimensiunii (posibil) performana este mai bun. n reelele moderne dimensiunea pachetelor nu mai este o problem, dar dac H.323 va fi utilizat n reelele de telecomunicaii mobile atunci acest aspect va fi un avantaj. Performana este discutabil n cazul standardului H.323. Este adevrat c cele mai multe protocoale ce folosesc mesaje codate binar sunt foarte rapide deoarece structurile de date folosite n program pot fi trimise imediat la buffere i invers. Dar Q.931 i PER sunt foarte complexe i performana depinde mult de omplementare. n stadiul actual de dezvoltare a celor dou standarde, descoperirea entitii care se ocup de apeluri este mai bine realizat la H.323 unde un terminal poate cunoate ce gatekeeper se ocup de apeluri spre deosebire de situaia de la SIP. n orice caz, acest fapt se poate fixa foarte uor n versiunile urmtoare.

3.3.4 Interconectarea SIP - H323 Cele dou protocale se ocup cu iniierea, controlul i terminarea conversaiilor multimedia. Deoarece fiecare dintre acestea au o arhitectur separat i mesaje distincte care numai n aceste arhitecturi funcioneaz, pentru legarea unei reele SIP cu o reea H.323 este nevoie de un echipament numit gateway ce trebuie s implementeze cele dou protocoale, pentru a face schimbul de informaii ntre cele dou reele. Acest echipament poate juca urmtoarele roluri: pe partea cu reeaua H.323 joac rolul de terminal H.323 i pe partea cu reeaua SIP joac rolul de agent server sau client; pe partea cu H.323 joac rolul unui Gatekeeper iar pe partea cu SIP a unui registrator i/sau server proxy. O imagine a unei interconectri simple ntre cele dou reele este prezentat n figura urmtoare:

Figura I.16 Interconectarea reelelor SIP i H.323

Deoarece H.323 folosete n semnalizare mesaje din mai multe protocoale (de exemplu RAS, H.255 i H.245) i n mai multe etape, timpul de iniializare a apelurilor este mare n comparaie cu SIP. Dac se folosete modul de semnalizare denumit FastStart acest timp se reduce ajungnd comparativ cu cel al protocolului cu care este in competiie. Folosin d acest mod n tabelul urmtor se prezint mesajele ce sunt folosite pentru iniializarea unei sesiuni i cum sunt ele transformate din mesaje de semnalizare H.323 n mesaje SIP.

Nr. 1

Partea H.323 -> Iniializare cu FastStart

Partea SIP

Comentarii Conine informaiile despre canalele logice folosite pentru sensul invers Gatway-ul indic primirea informaiilor Conine informaiile despre porturile pentru sensul invers n format SDP

<- Call proceeding

INVITE ->

4 5 6 7 8 N N+1 <- Release N+2 N+3 -> Release complete <- Connect <- Alerting

180 Ringing <Utilizatorul a rspuns apelului

200 OK <-

ACK -> BYE <Utilizatorul a nchis

200 OK ->

Pentru deschiderea unui nou flux de date se folosesc mesajele din tabelul ce urmeaz

-> OpenLogicalChannel INVITE -> Acelai identificator de apel ca mesajul INVITE precedent dar cu valoarea cmpului Cseq incrementat. Informaia SDP coninut descrie lista modificat a canalelor media Se confirm lista modificat prin informaia SDP coninut

200 OK <-

<- OpenLogicalChannelAck 3.3.5 Concluzii

Pe pia exist echipamente ce suport H.323 sau SIP dar puine tiu sa foloseasc ambele protocoale. n prezent echipamentele ce lucreaz cu H.323 sunt mai numeroase dect cele ce folosesc SIP. n practic, vor exista companii ce vor produce echipamente ce vor folosi unul din cele dou protocoale pn va fi sigur c unul dintre acestea va disprea sau pn se vor uni ntr -un alt protocol. Dac se dorete o funcionare stabil cu alte implementri atunci se pot alege echipamente ce folosesc H.323 deoarece acest protocol este mai stabil din punct de vedere al standardelor dect SIP. Altfel, cele dou protocoale furnizeaz aceleai servicii. Singura zon n care se observ o diferen, este iniializarea conferinelor. Deoarece SIP poate fi folosit pentru a invita mai multe persoane s se alture la un apel, conferinele pot fi iniiate fr existena n mod obligatoriu a unui server pentru conferine. n practic totui, dac aceste amnunte sunt avantaje sau nu depinde de soluia implementat de vnztorul echipamentului i nu de protocoalele ce sunt folosite. Materialele din care au fost consultate pentru a realiza acest subcapitol au fost: Reele de calculatoare [1], IP telephony [2], RFC 2327 [6], RFC 2616 [7], RFC 2974 [8], RFC 3261 [9], RFC 3272 [10], Voice over IP [15]. Acestea ar putea fi consultate pentru a se aprofunda noiunile prezentate aici.

4. Vocea n VoIP Aceasta reprezint un factor important n diferenierea reelelor noi aprute ce ofer sevicii VoP (voce peste reele de pachete) dar i a echipamentelor folosite. De aceea msurarea calitii vocii ntr-un mod obiectiv, sigur i ieftin devine foarte important. Calitatea poate nsemna mai multe lucruri depinznd de punctul de vedere. Pe de o parte, calitatea vocii este un mod de a descrie i a evalua fideliatea vocii, inteligibilitatea i caracteristicile semnalului vocal analog. Pe de alt parte, calitatea vocii poate descrie performanele mecanismului de transport folosit. Reeaua PSTN tradiional a rezolvat problema calitii prin optimizarea circuitelor pentru banda folosit de voce i pentru ritmul conversaiei.Aceast reea a ajuns s furnizeze servicii de bun caliatate pentru aplicaii n timp real ce au nevoie de ntrzieri mici, jitter mic i band constant dar mic. Cu toate c PSTN nu prezint o calitate a vocii excepional, utilizatorii s-au obinuit cu acesta i compar celelalte servicii folosind PSTN ca reper.

Spre deosebire de reeaua de telefonie tradiional, reele IP au fost proiectate s ofere servicii aplicaiilor ce nu au cerine de timp real, cum ar fi transferul fiierelor sau e -mail. Aceste aplicaii creaz un trafic n rafale i uneori cer band nsemnat dar nu sunt afectate de ntrzieri sau variaia acestora. Pentru a putea folosi aplicaiile de timp real, reelele IP trebuie s aib i mecanisme care s asigure calitatea serviciilor (QoS) necesar pentru transportul datelor. Utilizatorii PSTN s-au obinuit cu o calitate foarte bun a vocii. Furniznd o calitate comparabil a serviciilor va duce la acceptarea i succesul aplicaiilor de voce prin reelele de pachete. VoIP, prin introducerea de codecuri neliniare i prin impunerea de termeni privind livrarea pachetelor unor reele ce nu au fost proiectate pentru cerine de acest gen, face ca meninerea caliti vocii dificil. Transmisia, folosind acest tip de reele, care nu pune nici o problem traficului de date care nu este n timp real poate pune probleme serioase traficului n timp real. Transmisia este afectat de: banda n timp real, ntrzierile datorate proceselor din gateway-uri, pierderea pachetelor, ntrzierile i codecurile neliniare. Multe tipuri de reele de date nu pot s asigure banda necesar pentru transportul vocii. Reele de date nu asigur o ntrziere mic i nici mcar constant. Introducerea semnalului vocal n aceste reele necesit folosirea de metode care s asigure transportul n timp real, calitatea vocii putnd avea de suferit dac aceste metode nu funcioneaz cum trebuie. Cu toate c vocea n timp real necesit o band rezonabil, necesarul efectiv este ori o band constant pentru codecurile liniare ori o band oarecare pentru codecurile cu rat mic. Cu toate c furnizorii de servicii asigur o band suficient pentru aplicaiile de voce fr a afecta traficul de date obinuit, se folosesc i tehnici de compresie n particular pentru traficul n timp real ce are ca destinaie un calculator personal. Compresia neliniar poate fi o cauz major pentru scderea caliti vocii. Reele VoIP se bazeaz pe procesele care de multe ori sunt realizate n gateway-uri pentru a prevenirea unor probleme de calitate. De exemplu, eliminarea perioadelor de linite poate preveni crearea i transmiterea de pachete pe perioadele dintre frazele vorbite. La fel, suprimatoarele de ecou sunt necesare pentru a elima ecoul atunci cnd devine perceptibil atunci cnd reeaua introduce ntrzieri. Dac procesele de acest timp nu funcioneaz cum trebuie calitatea vocii are de suferit. Aplicaiile compenseaz pierderea pachetelor prin retransmiterea pachete lor pierdute folosind TCP. Aplicaiile de date cum ar fi transferul de fiiere i e-mail sunt mai puin afectate de timpul n care aceast retransmisie are loc , dar traficul de voce n timp real nu

poate accepta aceast ntrziere. n plus VoIP folosete UDP care nu garanteaz livrarea pachetelor. Pachetele pierdute nseamn informaie pierdut. ntrzierea perceput de ctre utilizator poate fi proveni din timpul n care sistemul sau reeaua trensform semnalul analog n semnal digital, creaz pachetele, transmite, ruteaz i stocheaz ntr-un buffer un semnal de voce. Aceast ntrziere poate s creeze probleme ntr-o conversaie i poate s mreasc stricciunile provocate de alte probleme cum ar fi ecoul. Un motiv important pentru msurarea caliti vocii este dezvoltarea i folosirea codecurilor neliniare ce comprim vocea astfel nct se transmite informaia important fr a se transmite tot semnalul vocal. Cu alte cuvinte aceste codecuri conserv cum sun vocea fr a pstra toate frecvenele semnalului. n general, se poate exprima i msura calitatea vocii n funcie de asculttorul i vorbitorul ce au luat parte la conversaie. Calitatea trebuie msurat capt la capt. Adic indiferent de sisteme, aparate i metode de transmisie, acesta trebuie examinat din punctul de vedere al utilizatorului. Dar natura subiectiv a acestui tip de evaluare calitativ nsoeste orice aspect al caliti vocii. O definiie clar a calitii vocii este necesar nainte de a discuta caracteristicile i componentele acesteia. Muli factori influeneaz percepia caliti unui apel telefonic de la uurina cu care acesta este efectuat pn la calitatea sunetului din receptor. La un nivel mai ridicat calitatea unui apel este compus din calitatea serviciului, calitatea sunetului i calitatea conversaiei. Acestea sunt interdependente atunci cnd un utilizator trebuie s-i spun prerea despre calitatea unui apel. De exemplu acesta poate tolera, ignora sau poate s nu observe o calitate mai proast a sunetului atunci cnd calitatea serviciilor este foarte bun. Utilizatorii telefoanelor mobile sau cei care poart conversaii prin satelit la mare distan pot tolera sau ignora problemele de sunet din cauza avantajelor aduse de apel. Un alt exemplu este i calitatea conversaiei. Cnd exist o ntrziere perceptibil ntre frazele asculttorului i a vorbitorului, muli utilizatori percep aceast situaie ca o problem de calitate a serviciului sau a sunetului. Multe aspecte ale caliti serviciilor sunt strns legate de problemele i deciziile luate de furnizorul de servicii i mai puin legate de performana reelei i funcionarea echipamentelor de reea. Totui, calitatea sunetului i a conversaiei par stns legate de dispunerea reelei i performana acesteia. Din aceast cauz, calitatea vocii este rezultatul masurrii calitative i cantitative a caliti sunetului i a conversaiei. Calitatea vocii este afectat de trei factori principali: claritatea, ntrzierea i ecoul. Claritatea este o msur a fidelitii, lipsei distorsiunilor i inteligibiliti unui semnal de voce.

ntrzierea este timpul necesar unui semnal vocal s ajung de la vorbitor la asculttor. Ecoul este sunetul produs de vorbitor ce ajunge la urechea acestuia. n perceperea calitii un factor i afecteaz pe ceilali, utilizatorii neputnd s disting ntre diferitele efecte cauzate de reea. Distorsiunile i fidelitatea sunt nu sunt afectate de ntrziere, astfel un semnal vocal poate fi ntrziat orict i tot va suna bine la redare. Pentru ca un utilizator s perceap calitatea vocii ca acceptabil trebuie ca claritatea s fie rezonabil de bun iar ntrzierea rezonabil de scurt. Se mai observ c ecoul depinde de ntrziere i ecoul afecteaz claritatea. Claritatea descrie fidelitatea perceput i natura nedistorsionat a unui semnal de voce. De asemenea aceast mai poate fi descris i ca inteligibilitatea vocii, indicnd cantitatea de informaie care poate fi extras dintr-o conversaie. Totui este posibil ca s se neleag ce spune vorbitorul chiar dac la recepie exist o claritate proast a semnalului, cum ar fi o voce distorsionat sau greu de auzit. Claritatea i evaluarea acesteia depinde de mai muli factori. De exemplu unele benzi de frecven sunt mai importante pentru percepia claritii dect altele. Aculttorii sunt mai sensibili la distorsiunile sau atenurile ce au loc n bnda de frecven 1000- 1200 Hz dect la cele ce au loc n banda 250-800 Hz. Un alt exemplu este c frazele complete sunt mai uor de neles dect o secven de cuvinte fr nici o legtur, chiar dac fraza complet este mai distorsionat dect secvena de cuvinte. De aceea utilizatorii percep frazele complete ca avnd o calitate mai bun. ntr-un apel telefonic ce este iniiat n reeaua PSTN i are ca int un terminal dintr-o reea de pachete mai muli factori contribuie la afectarea claritaii sunetului transmis.Telefonul PSTN influeneaz prin calitatea receptorului i a microfonului, prin nivelul semnalului i prin ecoul generat ntre microfon i receptor. Reeaua PSTN folosete semnalul digital. Transformarea semnalului analog n semnal digital de multe ori afecteaz claritatea vocii. Gateway-ul ce interconecteaz reeaua PSTN cu reeaua IP afecteaz claritatea din cauza codecurilor folosite, a componentelor ce elimin perioadele de linite i a generatoarelor de zgomot. Reeaua IP, dei nu are componente de voce active, afecteaz claritatea prin tendina de a pierde pachete i de a aduga jitter livrrii de pachete. Terminalul IP afecteaz i el prin codecul folosit, prin mecanismul de eliminare a perioadelor de linite i prin calitatea microfonului i a receptorului (boxelor). Pierderea pachetelor nu este un fenomen rar n reelele IP. Pe msur ce reeua sau unele link-uri devin congestionate, bufferele din rutere ncep s nu mai primeasc pachete i acestea sunt aruncate. O alt cauz a pierderi pachetelor o reprezint schimbarea rutelor atunci cnd unele link-uri nu mai funcioneaz. Un efect similar cu pierderea pachetelor este acela

cnd un pachet este ntrziat foarte mult i ajunge prea trziu pentru a fi folosit n reconstrucia semnalului de voce. Pentru aplicaiile ce nu sunt de timp real pierderea pachetelor nu are prea mare importan. Protocoalele asigur mecanisme de retransmisie pentru a recupera pachetele pierdute. Totui n cazul aplicaiilor de timp real, pachetele trebuie s soseasc ntr-un interval bine definit de timp pentru a putea fi folosite la reconstrucia semnalului de voce. Retransmisia nu poate fi folosit n acest caz deoarece face ca vocea s devin inteligibil. Pentru a evita pierderile de pachete, sunt necesare mecanisme speciale care s minimum de band pentru aceste aplicaii. Aceste mecanisme minimizeaz pierderile de pachete i ntrzierea pentru traficul prioritar cum este vocea. Aceste mecanisme includ scheme de prioriti folosite la controlul fluxului printr-un ruter, n protrocolul MLSP sau la setarea bitului type of sevice din antetul IP. O alternativ mai dinamic pentru rezervarea de resurse este protocolul RSVP, ce permite unui terminal sau unu gateway s cear o anumit calitate a serviciului IP. Indiferent de metoda folosit exist totui o problem important. Dac se presupune c exist resurse suficiente, rezervarea i controlul acestora pe ntregul drum al apelului este foarte dificil din cauza domeniilor cu administrare distinct strbtute i din cauza tipurilor diferite de rutere ntlnite care pot oferi sau nu serviciul cerut. Un codec transform semnalul de voce analog ntr-un flux digital de bii i vice-versa. Unele codecuri folosesc i tehnici de compresie, ndeprtnd informaia redundant sau mai puin important pentru a reduce banda necesar pentru transmisie. Cu alte cuvinte, multe codecuri comprim semnalul de voce prin pstrarea numai acelor pri din semnalul de voce care sunt importante din punct de vedere al percepiei. Acest lucru nseamn pstrarea acelor pri care au cel mai mare impact din punct de vedere al modului cum urechea uman aude acel semnal, mai ales dac acele pri sunt distorsionate sau omise. Depinznd de tipul de codec folosit, partea receptoare a unei conversaii VoIP poate s nu reproduc semnalul original. Cteva codecuri, ca G.711, sunt numite liniare deoarece acestea reproduc aproape n ntregime semnalul original. Alte codecuri, ca G.729 sau G.723.1, ncearc s reproduc sunetul subiectiv auzit de urechea uman i nu semnalul original captat de microfon. Aceste codecuri sunt n general numite neliniare. Compresia este un proces ce pune n balan calitatea vocii, puterea de calcul local, ntrzierea i banda necesar pentru transmisie. Cu ct este mai mare reducerea de band necesar cu att este mai mare cererea de putere de calcul pentru o claritate perceput a semnalului. n plus cu ct este mai mare reducerea benzi necesare cu att ntrzierea produs de procesul de calcul este mai mare astfel crescnd ntrzierea global. Ali factori care

influeneaz efectul codecului asupra calitii vocii sunt lungimea pachetului, pierderea pachetelor i orice mecanism de corecie a erorilor pe care codecul l folosete el nsui. Pe lng pierderea pachetelor i codecuri muli ali factori afecteaz claritatea vocii, incluznd i zgomotul, componentele ce detecteaz dac se vorbete sau nu pe conexiune (detectoare de voce), ecoul i factori de mediu. Zgomotul, indiferent de sursa lui, poate reduce claritatea unui semnal de voce.Dac zgomotul este introdus nainte ca semnalul s fie transformat ntr-un semnal digital, codecul transform i zgomotul mpreun cu semnalul. Dac zgomotul este introdus dup ce semnalul este adus la forma analogic, acesta distorsioneaz i mai mult semnalul. Detectoarele de voce degradeaz claritatea prin tierea din greeal a unor poriuni din semnal. Vocea care ajunge napoi la vorbitor i este perceptibil n timpul conversaiei poate afecta claritatea perceput. n final, un receptor poate avea o calitate excelent dar zgomotul din camer, starea utilizatorului, cerinele acestuia precum i ali factori pot influena un utilizator s cread c calitatea audio perceput este inacceptabil. Aceti factori de mediu afecteaz metodele de testare i fac testele subiective ce folosesc oameni mai dificile. ntrzierea reprezint timpul necesar unui semnal s parcurg reeaua. n contextul telefonic ntrzierea reprezint timpul necesar ca semnalul generat la gura vorbitorului s ajung la urechea asculttorului. ntrzierea este suma ntrzierilor provocate de echipamentele de reea i de link-urile reelelei prin care trece traficul corespunztor vocii. Muli factori contribuie la ntrzierea global incluznd ntrzierea generat n reeaua PSTN, n reeaua IP i de ctre echipamentele VoIP. ntrzierea datorat transmisiei pe apelurile de distan mare este de aproximativ 250 ms atunci cnd aceasta trece printr-un satelit geostaionar i reprezint principala cauz a ntrzierilor n reeaua PSTN. n plus ntrzierile datorate comutaiei n nodurile de reea este mic n comparaie cu ntrzierea datorat transmisie. n cele mai multe cazuri ntrzierea n reelele PSTN este relativ mic i depinde n principal de distana ntre capetele apelului. ntrzierea n reelele IP este n principal datorat de stocrii n buffere, n cozi de ateptare i comutrii sau rutrii n ruterele IP. n special ntrzierea n reeaua de pachete este format din ntrzierea datorat procesului capturri pachetelor, comutri/rutri a acestora i ateptri n cozi de ateptare. ntrzierea datorat capturri pachetelor reprezint timpul necesar ce trebuie ateptat pn cnd tot pachetul este primit nainte a de fi procesat i trimis spre urmtorul ruter. Lungimea pachetului i viteza de transmisie detremin valoarea acestei ntrzieri. Folosind pachete de dimensiuni mici pe link-uri de viteze mari se poate micora ntrzierea dar

eficiena reelei ar putea scdea. ntrzierea datorat comutrii/rutrii reprezint timpul n care un ruter l folosete pentru a comuta un pachet. n acest timp echipamentul analizeaz antetul pachetului, verific tabelul de rutare i trimite pachetul ctre portul corespunztor. Aceast ntrziere depinde de arhitectura echipamentului de reea i de mrimea tabelei de rutare. Cele mai noi rutere pot face lua unele decizii de rutare prin hardware i nu prin software micornd astfel ntrzierea. Datorit multiplexrii statistice i a sosirilor asincrone a pachetelor este necesar folosirea de cozi de ateptare la porturile de intrare i de ieire din rutere. Acest fapt produce o ntrziere care este dependent de ncrcarea reelei, lungimea pachetelor i distribuia statistic a pachetelor pe porturi. Proiectarea de rutere i de link -uri de mari capaciti poate micora ntrzierea dar nu o poate elimina. Gateway-urile i terminalele contribuie i ele n mod semnificativ la ntrzierea global din cauza procesrii semnalului la ambele capete ale link-ului. n timpul necesar procesrii este inclus timpul n care codecul codeaz semnalul analogic n semnal digital i decodeaz semnalul digital ntr-unul analogic. Unele codecuri fac i o compresie a semnalului ceea ce face ca ntrzierea s creasc. n partea transmitoare, ntrzierea de pachetizare timpul necesar pentru a forma un pachet din informaia audio este un alt factor. Cu ct este mai mare pachetul cu att se ateapt mai mult pentru formarea unui pachet. Folosind pachete mici poate micora ntrzierea dar eficiena sufer deoarece este nevoie s se trimit mai multe pachete n reea fiecare avnd un antet care nu transport informaie. n partea receptoare, trebuie s se ntrzie pachetele pentru a se compensa variaiile duratelor ntre sosirile pachetelor sau pe scurt jitter. Chiar i pachetele care sunt transmise cu durate n timp constante ntre ele ajung la receptor cu durate variabile din cauza ateptrilor n cozile de ateptare i din cauza transmisiei pe ci diferite a pachetelor. Pentru a elimina efectul jitterului se folosete un buffer n care sunt puse pachetele nainte de decodare deoarece acestea necesit pentru a funciona corespunztor un fux de pachete constant fr guri. ntrzierea produs de acest buffer poate fi diminuat prin micorarea jitterul n fiecare nod i reducerea numrului de noduri din reea. Se poate optimiza i dimensiunea bufferului pentru a fi ct mai mic pentru jitterul existent. Folosind mecanismele ce fac traficul n timp real prioritar fa de celelalte fluxuri reeaua poate micora considerabil jitterul. ntrzierea nu afecteaz n mod direct calitatea vocii dar, n schimb, afecteaz caracterul conversaiei. Cei mai muli utilizatori nu observ o ntrziere mai mic de 100 de milisecunde. Cnd aceasta este ntre 100 i 300 de milisecunde, utilizatorii observ doar o mic ezitare n rspunsul partenerului de conversaie. Dup 300 de milisecunde, ntrzierea

este clar pentru utilizatori i conversaia devine din ce n ce mai dificil. n mod evident, o ntrziere mic duce la o conversaie de o calitate mai bun i la o percepie mai bun a urilizatorului asupra calitii generale a vocii. Pentru a elimina ecoul nedorit, proiectani de reea introduc componente funcionale numite suprimatoare de ecou n centralele locale, n gateway-urile VoIP i n terminalele VoIP posibil ct mai aproape de locul unde se produce ecoul. Pentru a utiliza ct mai eficient banda, reelele VoIP folosesc o funcie numit eliminarea duratelor n care nu se vorbete sau detecia vocii. Aceast funcie este realizat de un element care se afl n gateway-uri sau n terminale i care elimin pachetele corespunztoare momentelor cnd nu se vorbete. Acestea opereaz pe partea de ieire a unui gateway i se pot adapta la nivele diferite de zgomot. Deoarece conversaiile sunt de obicei, pe un termen mai lung, de tipul half-duplex folosind o astfel de funcie se poate realiza o reducere de 50% a necesarului de band pe cele dou canale folosite luate mpreun. Dei funcionarea acestora nu afecteaz claritatea, n cazul n care nu funcioneaz corect descrete n mod sigur inteligibilitatea semnalului i calitatea per ansamblu a conversaiei. La recepie, pentru ca cel ce ascult s nu cread c nu mai este nimeni pe linie n momentele n care pachetele corespunztoare momentelor de pauz au fost eliminate, exist o funcie ce genereaz un zgomot de fundal care trebuie s fie ct mai apropriat de zgomotul de fundal de la transmisie. Materialele consulate pentru a scrie acest subcapitol au fost The Quality of voice over IP [14] i Voice quality in converging telephony and IP networks [17].

II Aplicaie software 1. Prezentare general Pentru a nelege ct mai bine funcionarea protocolului de semnalizare prezentat n lucrarea de fa am realizat o aplicaie care s folosesc acest protocol pentru a iniia i termina o sesiune de comunicaie prin voce printr-o reea de date. De la nceput am impus anumite limitri. Nu s-au folosit sisteme mai complicate cum ar fi server-e proxy, server-e de redirectare, gateway-uri. Aplicaia trebuia s funcioneze numai ntr-o reea local de mici dimensiuni i de aceea am trecut cu vederea problemele legate de asigurarea calitii serviciilor (QoS). Transmisia vocii prin reea a fost ntr -un fel pe

planul doi, important fiind modul de comunicare ntre aplicaii folosind protocolul SIP. Deoarece semnalizrile se realizau pe un LAN fr alte sisteme aparinnd arhitecturii SIP, sa folosit modelul de comunicaie ntre dou terminale care i cunosc adresele de reea i comunic direct fr intervenia altor sisteme. Aplicaia este i un exemplu cum foarte uor se poate integra VoIP cu alte forme de servicii, doarece integreaz un sistem de chat cu unul de VoIP. Dezvoltarea programului s -a realizat n dou etape. Mai nti sau pus bazele comunicaiei pe baz de mesaje scrise i dup aceea s-au dezvoltat mecanismele de comunicaie prin voce. n realizarea prii de chat, obiectivele propuse au fost implementarea unei aplicaii care s permit transmiterea mesajelor scrise prin metoda multicast, s prezinte lista celor care folosesc aceast aplicaie i s permit folosirea de imagini grafice inserate n text care s exprime anumite stri emoionale (emoticoane) fr a avea o component central care s realizeze aceste lucruri. Aplicaiile discut ntre ele folosind un set de mesaje text trimise sub forma / cuvant cheie informaie. Prin acestea ele indic intrarea unui nou utilizator, trimiterea unui nou mesaj, schimbarea nickname-ului i ieirea unui utilizator. Partea care este responsabil cu implementarea VoIP a avut ca scop principal realizarea unei aplicaii care s permit asigurarea comunicaii prin protocolul SIP cu celelalte aplicaii. Au fost implementai agenii server i client care se ocup de trimiterea mesajelor, recepionarea i procesarea acestora. Transmiterea vocii s-a realizat ntr-un mod foarte simplu. Pachetela care sosesc de la placa audio sunt pur i simplu introduse i pachete UDP i trimise in reea. S-a adoptat aceast soluie deoarece s-a dorete folosirea aplicaiei ntr-o reea local de mici dimensiuni care nu este foarte mult. n acest caz rata de pierdere a pachetelor este mic i cum s-a implementat doar un singur codec, folosirea protocoalelor RTP i RTCP pentru transmisia pachetelor audio nu ar fi fcut dect s complice aplicaia, fr s aduc contribuii importante. Partea grafic a aplicaiei folosete ferestre, butoane i zone de text cu informaii despre funcionare pentru a permite o intraciune ct mai uoar cu un utilizator. Fereastra principal prezint zona unde se scriu mesajele scrise de utilizatori, unde se pot scrie me saje noi, unde se schimba numele de apelare al utilizatorului (nickname) i de unde se poate iei din conversaie. Mesajul scris de un utilizatori ajunge la toi cei care au aplicaia pornit i sunt conectai, deoarece se folosete o comunicaie multicast. Tot n aceast fereastr sunt trecute i informaii despre utilizatorii ce sunt n conversaie la un anumit moment dat. Aceste informaii cuprind numele i adresa de reea a terminalului folosit. Acestea pot fi folosite pentru a iniia o conversaie prin voce cu persoana respectiv.

Pe lng aceast fereastr principal mai sunt ferestra pentru vizualizarea unei pagini cu informaii despre modul de folosire, pentru vizualizarea mesajelor trimise i recepionate, pentru conectare, pentru vizualizarea informaiilor despre aplicaie, pentru iniierea unei sesiuni SIP i pentru terminarea unei sesiuni SIP. Aa cum s-a precizat mai devreme aceast aplicaie are posibilitatea de a nregistra mesajele trimise ntre utilizatori. Dac un utilizator ia parte la o conversaie acesta poate vizualiza mesajele trimise n cadrul acelei conversaii din momentul intrrii acestuia prin intermediul unei ferestre. Dac dorete vizualizarea mesajelor din alte zile poate citi fisierul log.txt n care sunt trecute mesajele de la prima folosire a programului. n continuare se vor prezenta pai necesari care trebuiesc fcui pentru a utiliza acest program. Apoi se vor prezenta mai detaliat modul de funcionare al programului n general i apoi pe cele dou direcii: partea de chat i partea de VoIP.

2. Modul de utilizare Dup pornirea programului apare fereastr principal ce conine elementele toate elementele necesare pentru realizarea n bune condiii a unei conversaii chat. Pentru a intra ntr-o discuie cu ali utilizatori trebuie s ca programul s fie conectat la reea. Folosind bara de meniuri se selecteaz butonul Actions ce deschide un sub domeniu i de acolo se alege butonul Connect ce va deschide o fereastr n care se scrie adresa de multicast i portul ce va fi folosit pentru comunicaia prin mesaje text i numele sub care vrea utilizatorul s fie cunoscut n conversaie. Se apas butonul i n acest moment utilizator va fi n modul conversaie dac toate informaiile au fost corecte. Succesul sau insuccesul acestei aciuni este indicat n textul din josul ferestrei principale. Tot aici se indic o posibil eroare ntlnit n realizarea aciunii dorite de utilizator. Dac n lista utilizatorilor prezentat n dreapta apare numai numele utilizatorului nseamn c programul funcioneaz dar numai el are programul de chat pornit. Schimbarea numelui cu care apare n aceast list se face folosind butonul Change Nickce este plasat n fereastra principal. Succesul sau insuccesul acestei aciuni este indicat n zona din josul ferestrei. Pentru a trimite mesaje este deajuns s se selecteze zona destinat acestui lucru, s se scrie mesajul i s se apese tasta Enter. n acest moment acest mesaj mpreun cu numele utilizatorului apar n zona de text din centrul ferestrei.

n aceast fereastr pot fi reprezentate i imagini ce indic anumite stri emoionale ale utilizatorului numite emoticoane. Pentru aceasta utilizatorul trebuie s tasteze un anumit cod format din dou sau trei caractere text. Aceste coduri specifice plus descrierea imaginii asociate sunt prezentate n continuare: fericit :) suprat(limba):p dezorientat :s nedecis :| fat (x) nu te iubesc (u) ctui (%) floare ofilit (w) messenger (m) srut (k) muzic (8) plng :'( curcubeu (r) ceas (o) pahar (c) idee (i) zi de natere (^) cael (&) soare (#) drac (6) stea (*) foarte fericit :d smecher ;) ruinat :$ da (y) biat (z) poz (p) floare (f) bere (b) email (e) surprins :o suprat :( ochelari de soare (s) nu (n) te iubesc (l) cadou (g) butur (d) liliac :[ telefon (t) adormit (s) furios :@ film (~) nger (a) pisic (@)

Deoarece zona de afiare permite vizionarea numai a mesajelor cele mai recente se permite citirea tuturor mesajelor trimise i recepionate n cadrul sesiunii curente prin intermediul ferestrei Log. Pentru a o deschide trebuie apsate butoanele View i Current Log din bara de meniuri. Pentru a vizualiza mesajele din cadrul altor conversaii trebuie s se deschid fiierul log.txt aflat n acelai director unde se afl i fiierele n java. Pentru a iniia o conversaie prin voce trebuie s se selecteze din bara de meniuri domeniul Actions subdomeniul VoiceChat care va deschide o fereastr n care se vor introduce numele utilizatorului i adresa de reea acestuia care va fi invitat s participe i o scurt descriere a motivului pentru care se realizeaz aceast invitaie. Dup apsarea butonului Dial la partea apelat va apare o fereastr care va prezenta sursa i motivul acestui apel. Dac se apas butonul Yes atunci apelul este acceptat i se poate ncepe conversaia. Dac se apas butonul No atunci partea care a iniiat apelul este informat c apelul nu se poate realiza. Conversaia se poate termina i din partea apelat i din partea apelant prin apsarea butonului Kill VoiceChat din domeniul Aciuni din bara de meniu.

Situaia apelului n toate momentele sale este prezentat n zona din josul ferestrei principale, utilizatorul putnd astfel s acioneze n cunotin de cauza. n orice moment se poate purta doar o sigur conversaie prin voce, sosirea unei invitaii noi sau trimiterea uneia va avea ca raspuns n mod automat un refuz. Menionez c cele dou aplicaii sunt independente adic se poate purta o conversaie prin voce chiar dac utilizatorul nu se afl conectat la sistemul de transmitere i recepie a mesajelor scrise dar unele informaii necesare pentru realizarea unei conversaii prin voce pot fi extrase din informaiile prezentate de program atunci cnd se afl ntr -o conversaie prin text. De exemplu dac nu se indica disponibilitatea pentru purtarea unei conversaii de tip chat prin conectare atunci nu se poate ti dac utilizatorul dorit pentru o conversaie prin voce are programul pornit. Tot prin conectare se poate afla numele i adresa de reea a utilizatorului necesare pentru iniiarea unei conversaii. Pentru ieirea din program ori se apas butonul X din dreapta sus a ferestrei principale care va deconecta programul din conversaia chat i va termina conversaia activ prin voce sau poate s apese butonul Exit din domeniul Actions din bara de meniuri moment n care se vor executa aceleai aciuni ca mai sus.

3. Descrierea claselor constituente Acest program este format dintr-o clas principal numit Client ce iniiaz celelalte clase i constriuete fereastra principal i din mai multe clase secundare. Acestea sunt n general de dou tipuri: clase folosite numai la partea grafic a aplicaiei (About, Help, Connect, VoIP, VoipT, VRing) i clase folosite n funcionarea aplicaiei (Client, ChatArea, Conectare, Conversaie, Recepie, Transmisie, UserAgentSIP, UserAgentServerSIP, UserAgentClientSIP). Pe lng acestea mai sunt prezente clase (Packet, AbsoluteLayout, AbsoluteConstraints, MesajSIP) care pot fi numite utilitare doarece sunt folosite n funcionarea celorlalte clase. Clasele AbsoluteLayout i AbsoluteConstraints sunt folosite pentru poziionarea elementelor grafice n ferestre i au fost preluate de la Sun Microsystems. Au fost introduse n pachetul Client deoarece ele nu sunt n Java 2 SDK 1.4.1 . Fiind folosite de toate clasele ce definesc ferestre, ele pot fi considerate ca fcnd parte din standard i nu au mai fost desenate n diagrama de clase. > Clasa principal o reprezint clasa numit Client care definete fereastra principal dar conine i codul ce determin modul de funcionare al ntregii aplicaii. Aceast clas pornete un fir de execuie care n funcie de anumite stri (conectare, deconectare,

conectat) se instaiaz celelate clase necesare pentru comunicaii. Din aceast clas se iniializeaz i clasa ce pornete firele de execuie ce trimit i recepioneaz pe portul SIP (ales n standard ca fiind 5060) Dac utilizatorul cere s fie conectat (posibil numai n cazul n care nu avem o conexiune stabilit) atunci aceast clas creaz o instan a unei clase ce ncearc s se conecteze, numit Conectare. n funcie de rezultatul acestei aciuni continu cu crearea unei clase ce se ocup cu conversaia, numit Conversaie, sau informeaz utilizatorul c, conexiunea nu se poate realiza. Dac utilizatorul dorete deconectarea (posibil numai n cazul n care avem o conexiune stabilit) clasa Client comand clasei Conversaie s se opreasc i cere deconectarea clasei Conectare. Mesajele ce trebuiesc trimise sunt pasate clasei Conversaie de la care primete mesajele primite de la celelate aplicaii. Aceste mesaje primite sunt pasate clasei care le afieaz pe ecran (clasa ChatArea). Metodele i atributele clasei Client pot fi vzute n figura IV.1 ( pe lng atributele artate mai sunt i referinele la celelalte clase prezentate precum i la obiectele grafice). > Clasa Conectare este folosit la conectarea i deconectarea de la reea n ambele situaii aceasta trimind celorlalte aplicaii mesaje specifice. Are metode prin care returneaz o referin la socketul de tip multicast pe care l creaz.

Metodele

argumentele

sunt

prezentate

figura

IV.2.

Figura IV.1 Clasa Client

Figura IV.2 Clasa Conectare > Clasa Conversaie se ocup cu transmiterea i primirea mesajelor, pentru aceasta folosind dou fire de execuie plasate n dou clase denumite Receptie i Transmisie. Pentru partea de transmisie se ntreine o list de mesaje pentru a exista sigurana c mesajele

nu se pierd i pentru folosirea firului de execuie numai atunci cnd sunt mesaje n ateptare n list. Clasele Recepie i Transmisie folosesc metodele clasei Conversaie pentru a prelua i pasa mesajele. Clasa Conversaie folosete la rndul ei metodele clasei Client pentru a-i da secvenele de caractere primite de la celelalte aplicaii i pentru a prelua caracterele scrise de utilizator. Mesajele i situaiile n care se schimb acestea sunt prezentate mai jos: - conectare. Se trimite din partea aplicaiei care se conecteaz mesajul /connect la care fiecare aplicaie ce primete acest mesaj rspunde cu /nick nume(adresaIP) unde nume reprezint apelativul ales de fiecare utilizator iar adresaIP reprezint adresa de reea a terminalului folosit de utilizator. - schimbarea apelativului. Aplicaia care a primit cererea de schimbare a apelati vului trimite n reea prin transmisie de tip multicast mesajul /chgnick apelativ vechi: apelativ nou dup ce n prealabil a verificat c apelativul nou nu este deja folosit n reea. - trimiterea de mesaje. Aplicaia al crui utilizator a scris un mesaj trimite mesajul /msg apelativ: mesaj. Aplicaia care primete acest mesaj tiprete mesajul primit. - deconectare. Aplicaia care primete comanda de deconectare trimite mesajul /disconnect apelativ(adresaIP) Metodele i variabilele claselor sunt prezentate n figura IV.3( n clasa Conversaie pe lng atributele artate mai sunt i referinele ctre clasele Receptie i Transmisie): > Clasa ChatArea reprezint clasa prin care se afieaz mesajele de la server nlocuindu-se aici codurile cu imagini. Din punct de vedere al implementrii aceast clas creaz o imagine care este apoi desenat n fereastra principal apelndu-se metoda paint() a acestei clase. Aici se definesc codurile i emoticoanele desenate i se face asocierea ntre ele. Deoarece ceea ce se deseneaz n fereastra principal este o imagine, funcia scroll, care se gsete la un TextArea, nu este suportat i de aceea a fost nevoie de creerea unei noi clase Log care poate afia discuia dar fr a nlocui codurile cu emoticoane i care bineneles suport funcia scroll. Clasa Packet este o clas care este folosit numai de clasa ChatArea n cadrul metodei paint() i furnizeaz informaii despre ce emoticon trebuie desenat, unde a fost gsit i cte caractere trebuie s nlocuiasc. Metodele i argumentele acestei clase precum i cele ale clasei Packet sunt prezentate n figura IV.4. > Clasa Log se ocup pe lng afiarea discuiei din sesiunea curent i cu meninerea unui fiier log.txt n care se scriu toate mesajele primite plus ora i ziua la care a fost o conectare la server. Acest fiier poate fi ters de ctre utilizator prin intermediul unui

buton pus la dispoziia acestuia. Metodele i argumentele acestei clase sunt prezentate n figura IV.5. > Help afieaz ntr-o fereastr poriuni din acest document aflat ntr-un fiier numit help.txt. > About afieaz, ntr-o fereastr, informaii despre aplicaie. > Connect definete o fereastr unde sunt amplasate cmpurile unde se introduc informaiile despre adresa de multicast, portul i apelativul utilizator. Tot n aceast fereastr se afl un buton Connect care acionat paseaz informaiile, aflate n cmpuri, clasei Client i o informeaz pe aceast c se dorete conectarea la calculatorul indicat. > VoIP definete fereastra unde sunt trecute informaiile despre utilizatorul ce va fi invitat s participe la o conversaie prin voce. Tot n acea fereastr este trecut motivul conversaiei. Atunci cnd se apas butonul Dial aceste infomaii sunt pasate clasei UserAgentClientSIP.

Figura IV.3 Clasele Conversatie, Transmisie i Recepie

Figura IV.4 Clasa Packet

Figura IV.5 Clasa ChatArea i Packet

Figura IV.6 Clasa Log

> VRing definete fereastra ce apare atunci cnd se primete din reea o invitaie la conversaie. Aceast fereastr prezint utilizatorului informaii despre cel ce l invit i motivul acestei invitaii. Dou butoane sunt puse la dispoziie pentru a alege dac acept aceast invitaie sau nu. Indiferent de alegere se apeleaz metode din clasa UserAgentServerSIP pentru a se trimite rspunsul.

> VoipT definete fereastra care apare atunci cnd un utilizator dorete s termine o conversaie. Dac se confirm terminarea conversaiei atunci se apeleaz metode care s trimit mesajul BYE pari interlocutoare. > UserAgentSIP reprezint clasa n care se pornesc firele de execuie ce trimit mesajele SIP i recepioneaz aceste mesaje. Dup o scurt procesare mesajele primite sunt trimise ori clasei UserAgentServerSIP dac sunt cereri, ori clasei UserAgentClientSIP dac sunt rspunsuri.

Figura IV.7 Clasa UserAgentSIP > MesajSIP este folosit pentru extragerea valorilor cmpurilor dintr-un mesaj SIP i pentru crearea de mesaje SIP.

Figura IV 8 Clasa UserAgentClientSIP

> UserAgentClientSIP reprezint clasa ce proceseaz rspunsurile primite de la servere prin intermediul clasei UserAgentSIP i care trimite clasei MesajSIP informaiile necesare pentru crearea de cereri SIP. Aceste cereri sunt pasate clasei UserAgentSIP. > UserAgentServerSIP este clasa ce proceseaz cererile primte de la clieni i trimite napoi raspunsuri create cu ajutorul clasei MesajSIP.

Figura IV. 9 Clasa MesajSIP

Figura IV. 10 Clasa UserAgentServerSIP > SDP reprezint clasa ce creaz i descifreaz informaiile SDP.

Figura IV.11 Clasa SDP > CapturePlayback reprezint clasa ce se ocup cu primirea informaiei audio de la placa de sunet, trimiterea acestei informaii folosind pachete UDP, recepionarea i trimiterea acesteia spre placa audio. Firele de execuie sunt pornite ori de server, ori de client iar nchiderea acestora se realizeaz de clasa care le-au pornit. Firele de execuie sunt ncapsulate n dou clase interioare acestei clase. Codecul folosit este unul dintre cele suportate de mediul Java adic frecvena de eantionare 8000Hz, cu 8 bii pe eantion, fr semn, stereo.

Figura IV. 12 Clasa CapturePlayback

Diagrama de clase este urmtoarea:

Figura IV. 13 Diagrama de clase

4. Modul de funcionare

La pornirea aplicaiei, clasa Client se ocup cu instanarea claselor Help, About, Connect i ChatArea dar i cu pornirea firului de execuie propriu. Diagrama de colaborare din figura urmtoare va prezenta acest caz:

Figura IV. 14 Digrama de colaborare n cazul: pornire execuie Dac se dorete conectarea, prin intermediul ferestrei definit de clasa Connect se aduce la cunotina clasei Client c se dorete conectarea. n acest moment n interiorul firului de execuie al clasei principale se verific dac mai exist o conexiune, caz n care aciunea se ignor. Dac nu exist connexiune atunci se instanieaz clasa Conectare, care prin crearea unui socket ctre server ncearc deschiderea unui conexiuni cu acesta. Dac aceast aciune se desfoar fr probleme se instaniaz clasa Conversaie cu fluxurile de intrare i ieire de pe socket-ul creat. La rndul ei aceast clas instaneaz dou clase care conin fiecare cte un fir de execuie ce se ocup cu unul cu recepia clasa Receptie i cellalt cu transmisia clasa Transmisie. Dac instana clasei Conectare indic c, conexiunea nu se poate realiza atuci se nchide tot procesul cu un mesaj de eroare ctre utilizator. Diagrama de colaborare pentru cazul n care procesul de conectare se desfoar fr probleme este prezentat n figura IV.15.

Figura IV. 15 Diagrama de colaborare n cazul conectrii fr probleme Dac avem o conexiune i utilizatorul scrie un mesaj sau dorete s-i schimbe nickul, comanda ajunge la instana clasei Conversaie unde este pus ntr-o list de mesaje. Din aceast list de mesaje este luat de ctre instana clasei Transmisie. Digrama de colaborare este:

Figura IV.16 Diagrama de colaborare n cazul n care se trimite un mesaj

Dup tipul mesajelor primite de ctre instana clasei Recepie putem avea urmtoarele diagrame de colaborare: cazul cnd se primete un text scris de ali utilizatori;

Figura IV. 17 Diagrama de colaborare n cazul recepionrii unui mesaj cazul cnd se primete apelativele utilizatori conectai;

Figura IV.18 Diagrama de colaborare n cazul primiri unui apelativ al unui utilizator conectat cazul n care utilizatorul dorete deconectarea;

Deconectarea poate surveni n cazul n care apar erori la citirea sau transmiterea mesajelor sau n cazul n care utilizatorul apas butonul Disconnect. Dac apare cel puin una din aceste situaii instana clasei Client trimite comanda de deconectare ctre instana clasei Conectare, oprete firele de execuie din instanele claselor Recepie i Transmisie, terge aria utilizatorilor conectai la acelai server, trimite comanda ce nchide fiierul unde se nscriau mesajele primite, terge aria unde se afieaz mesajele primite, terge cmpul Nickname i alte aciuni ce in de fereastra de afiare.

Figura IV. 19 Diagrama de colaborare n cazul n care utilizatorul comand deconectarea Pentru iniierea unei sesiuni VoIP utilizatorul trebuie s deschid fereastra definit de clasa VoIP i s scrie acolo informaiile necesare pentru identificarea pri interlocutoare i s confirme acest lucru prin apsarea butonului. Aceste informaii sunt pasate clasei UserAgentClientSIP care cu ajutorul claselor MesajSIP i SDP creaz mesajul S IP INVITE pe care l paseaz clasei UserAgentSIP mpreun cu portul i adresa unde trebuie s trimit pachetul UDP. Cealalt aplicaie primete pachetul cu ajutorul clasei UserAgentSIP care dup ce observ c este o cerere l trimite clasei UserAgentServerSIP. Aceasta cu ajutorul claselor MesajSIP i SDP decodific mesajul SIP i observnd c

reprezint o invitaie deschide fereastra construit de clasa VRing. Aici utilizatorul indic dac accept sau nu invitaie i presupunnd c accept clasa UserAgentServerSIP pornete firele de execuie din clasa CapturePlayback care ncep s primeasc pachete audio de la placa audio i le trimit spre cealalt aplicaie i trimit pachetele primite din reea spre placa audio. Clasa UserAgentServerSIP trimite prin intermediul clasei UserAgentSIP mesajul SIP OK care odat ajuns la UserAgentClientSIP determin pornirea firelor de execuie ale clasei CapturePlayback i trimiterea spre cealalt aplicaie a mesajului SIP ACK. Diagrama din figura 20 prezint succesiunea etapelor prezentate mai sus.

Figura IV. 20 Trimiterea unui mesaj INVITE

Metodele reprezentate prin cifre sunt: 1: Utilizatorul apas butonul VoiceChat care apeleaz metoda voipAction (ActionEvent) 2: show() - se afieaz fereastra; aici utilizatorul introduce informaiile i apas butonul Dial

3: sendInvite(String,String,String,String,String,InetAddress) se creaz mesajul SIP cu ajutorul claselor MesajSIP (metoda createRequest()) i SDP (metoda createMesaj()) 4: putMesaj(String,int,InetAddress) se trimite mesajul clasei UserAgentSIP 5: send(DatagramPacket) trimitere ntr-un pachet UDP 6: receive(DatagramPacket) recepionarea pachetului 7: mesajNou(String) dup ce a determinat c mesajul este o cerere acesta este trimi s clasei UserAgentServerSIP 8: show() - deschide fereastra care informeaz sosirea invitaiei 9: yesAction(ActionEvent) utilizatorul rspunde afirmativ i variabilele rspuns i click sunt trecute pe valoarea true 10: clicked(), raspunsul() se testeaz variabila click pan cnd este true (utilizatorul a apasat pe un buton) i apoi se cere rspunsul (presupunem ca accept invitaia) 11: start() se pornesc firele de execuie 12: putMesaj(String,int,InetAddress) se trimite mesajul SIP OK 13: send(DatagramPacket) 14: receive(DatagramPacket) 15: mesajNou(String) 16: start() se pornesc firele de execuie ale clasei CapturePlayback 17: putMesaj(String,int,InetAddress) se trimite mesajul SIP ACK 18: send(DatagramPacket) 19: receive(DatagramPacket) 20: mesajNou(String) Pentru terminarea unei sesiuni SIP trebuie s se apese butonul din domeniul Actions din bara de meniuri numit Kill VoiceChat. Acesta va dechide o fereastr n care se dorete confirmarea utilizatorului pentru a trimite mesajul BYE care va nchide sesiunea. Deoarece sesiunea poate fi nchis de oricare din cei doi participani adic din punctul de vedere al aplicaiei poate fi nchis ori de server-ul SIP ori de clientul SIP. Deoarece clasa CapturePlayback a fost instaniat la nivelul acestor componente, clasa VoipT ce definete i fereastra trimite ambelor clase comanda s trimit mesajul BYE. La nivelul acestor clase se decide cine a instaniat clasa CapturePlayback, o oprete i trimite n reea spre cealalt aplicaie mesajul SIP BYE. Acolo acest mesaj este pasat celor dou clase care dac au instaniat clasa de captare i redare a vocii o opresc iar dac nu au fcut acest lucru ignor mesajul. Figura 21 prezint etapele prezentate mai devreme.

Metodele reprezentate prin cifre sunt: 1: voipTAction(ActionEvent) utilizatorul apas butonul Kill VoiceChat 2: show() se afiseaz fereastra care cere confirmarea aciunii 3: sendBYE() se trimite comada de nchidere a conversaiei i de trimitere a mesajului BYE 4: sendBYE() se trimite comada de nchidere a conversaiei i de trimitere a mesajului BYE 5: putMesaj(String,int,InetAddress) se trimite mesajul dup ce a fost creat cu ajutorul claselor MesajSIP i SDP sau 7: putMesaj(String,int,InetAddress) 6: kill() se comand oprirea firelor de execuie ce se ocup cu captarea/redarea i trimiterea/recepionarea pachetelor audio sau 8: kill() 9: send(DatagramPacket) se trimite n reea pachetul 10: receive(DatagramPacket) se recepioneaz pachetul 11: mesajNou(String) se paseaz mesajul din pachetul recepionat 12: mesajNou(String) se paseaz mesajul din pachetul recepionat 13: kill() -se comand oprirea firelor de execuie ce se ocup cu captarea/redarea i trimiterea/recepionarea pachetelor audio sau 14: kill()

Figura IV. 21 Trimiterea mesajului BYE

5. Modul de configurare Importante pentru aplicaia de fa sunt porturile prin care se trimit i se recepioneaz mesajele scrise, pachetele SIP i pachetele audio. Dou dintre acestea au fost alese i integrate n implementare. Astfel mesajele SIP se trimit i se recepioneaz prin portul 5060 valoare preluat din RFC ce se ocup cu descrierea SIP. Pachetele audio se trimit i se recepioneaz prin portul 3234, valoare aleas de mine. La dispoziia utilizatorilor rmne alegerea valorii portului prin care se trimit i se recepioneaz mesajele scrise. Pentru funcionarea corect

trebuie ca portul ales s fie acelai pentru toi utilizatorii. Exist i posibilitatea s se creze camere private prin alegerea de ctre un grup a unui port diferit de cel ales de restul utilizatorilor astfel acest grup putnd trimite mesaje ntre ei fr ca restul s-le recepioneze (prin folosirea acestei aplicaii) 6. Modaliti de extindere Felul cum a fost implementat acest aplicaie i confer proprietatea de a fi extins foarte uor. Deoarece a fost creat din mai multe module unele complet independente, se poate schimba comportamentul acestei aplicaii cu puine modificri ale claselor. De exemplu partea de conversaie depinde numai de metodele ce exist n clasa Client i de cele ce exist n clasa Conversaie i o schimbare a comportamentului n timpul conversaiei schimb doar metodele din Conversaie ce apeleaz pe cele din Client. Schimbarea protocolului ce este folosit de aplicaii pentru conectare, deconectare duce numai la schimbarea clasei Conversaie deoarece numai aici se ine cont de acest protocol. De asemenea i modalitatea de afiare a mesajelor se poate schimba uor deoarece se folosete pentru acest lucru o singur metod din clasa Client i clasa ChatArea, iar modificarea acestora se poate realiza fr dificuti. Se poate realiza fr mare eforturi scrierea mesajelor aa cum sosesc ntr-un element grafic numit TextArea, dar n modul acesta nu se mai pot prezenta imaginile codificate. Se poate realiza i modificarea imaginilor ntr-un mod simplu prin nlocuirea vechilor imagini cu noile imagini n folder-ul Images, cu condiia s se pstreze aceleai denumiri. Setul de imagini se poate mbuntii, pundu-se aduga noi imagini i codurile aferente dar pentru aceasta trebuie modificate clasele Pachet unde sunt procesate codurile i ChatArea unde sunt ncrcate imaginile. O extindere necesar pentru aceast aplicaie este implementarea protocoalelor RTP i RTCP pentru transmisia pachetelor audio, pentru a respecta standardele n totalitate. Aceasta se poate realiza cu scrierea de clase asemntoare cu MesajSIP care s creeze i s proceseze mesajele protocoalelor RTP i RTCP. O alt extindere o reprezint implementarea de codecuri n plus. Aceasta depinde de ce ofer mediul Java i de ce permite placa audio din calculatorul pe care ruleaz aplicaia. Se poate realiza prin crearea unei liste nlnuite care s conin parametrii codecurilor i care s fie folosit atunci cnd se iniiaz clasa CapturePlayback. Printr-o form de indexare s va indica ce zon a listei trebuie folosit. O alt posibilitate este crearea unei clase care s se ocupe cu implementarea unui codec specific. Aici trebuie menionat c programele realizate

n Java au timpi de execuie mai mari dect programele realizate n alte limbaje i din aceast cauz ntrzierile globale produse transmisiei de voce prin reeaua de pachete sunt mai mari dect cele preconizate n teorie. Folosirea unor codecuri mai complicate va duce cu siguran la ntrzieri mult mai mari. Pentru utilizarea n condii bune ntr-o reea foarte intens folosit trebuie s se adauge mecanismele IntServ, adic aplicaia s fie capabil s trimit i s proceseze mesajele PATH i RESV prin care se poate rezerva resursele necesare transmisiei n condiii bune a vocii prin LAN. Pentru mecanismul de conversaiei prin mesaje scrise acest lucru nu e necesar deoarece nu este o aplicaie n timp real. Implementarea mecanismelor IntServ se poate realiza prin adugarea de clase care s tie s citeasc i s creeze mesajele i clase care s realizeze comunicaia prin reea. Partea de chat poate fi mbuntit prin adugarea de camere private n care s se poat discuta fr ca mesajele s ajung la cei din afara camerei. O modalitate ar putea fi introducerea n mesaj i a numelui camerei i aplicaiile s afieze mesajele primite n funcie de camera unde se afl utilizatorul i de numele camerei din mesaj.

7. Concluzii n urma testelor funcionale s-a observat c serviciile furnizate de aceast aplicaie nu sunt dependente de puterea de calcul a terminalului pe care ruleaz. Dac se folosesc un terminal cu un procesor cu frecvena de lucru de peste 1 GHz i un terminal cu un procesor cu frecvena de lucru sub 500 MHz pe care ruleaz aceast aplicaie se observ c avem aceeai calitate audio n ambele sensuri. Aceast aplicaie este o marturie n plus asupra uurinei cu care se poate intergra o aplicaie VoIP cu alte aplicaii. n cazul de fa nu a fost nevoie dect de scrierea unor clase n plus. Nu a fost nevoie deloc modificarea claselor deja existente. n dezvoltarea acestei aplicaii s-a remarcat uurina cu care protocolul SIP a fost implementat. Dup cum se va observa din listarea codului s-a lucrat numai cu siruri de caractere i operaii cu acestea, lucru foarte uor de realizat. i dimensiunea clasei este o mrturie n acest sens. Chiar dac au fost implementate numai o parte din cererile i rspunsurile SIP, totui se observ simplitatea claselor care i-au deciziile n privina acestora. Este nevoie numai de cunoaterea metodei sau a tipului cereri pentru a lua o decizie.

Calitatea serviciilor oferite depinde n mare msur (dac terminalul este unul potrivit) de serviciile oferite de reeaua pe care funcioneaz aplicaia prezentat deoarece nu s-a implementat protocoalele RTP i RTCP, mecanismele de rezervare a resurselor i codecuri de band mai mic. Dac este folosit pe o reea de mici dimensiuni cu ncrcare medie atunci calitatea serviciilor este bun. Dac avem reele de mari dimensiuni sau ncrcri mari atunci calitatea este mult mai sczut. Aa cum se observ i din codul prezentat n anexele de la fritul lucrrii, aceast aplicaie prezint o interfa care este uor de nvat i de folosit. Fiecare buton are asociat un text de tip tooltip care explic ce se va ntmpla dac va fi folosit. Desfurarea unei aciuni importante cum ar fi conectarea sau trimiterea unei invitaii este urmat cu scrierea unui mesaj explicativ n partea de jos a ferestrei principale. Erorile care apar sunt de asemenea afiate n partea de jos a ferestrei. n ferestrele unde utilizatorul trebuie s introduc informaii, fiecare cmp are asociat un tooltip care i indic sub ce form sau ce tip de informaie este cerut de program. Dac introduce o informaie necorespunztoare (de exemplu litere n loc de cifrele ce indic portul folosit) aciunea eueaz i n zona din partea de jos a programului i-se spune unde a greit. n plus toate aceste zone de introducere a informaiei sunt trecute informaii care ori sunt cele propuse spre a fi folosite (cum ar fi adresa si portul de multicast) ori dau informai n plus despre ceea ce se cere de la utilizator. Aceast aplicaie a fost un exerciiu util pentru mine deoarece m-a ajutat s nv modul cum funcioneaz i cum se poate implementa protocolul SIP.

Anexa 1 Codul aplicaiei explicat n aceast seciune voi prezenta i explica codurile unor clase importante cum ar fi ChatArea care se ocup cu partea de scriere a mesajelor i emoticoanelor, CapturePlayback care se ocup cu captarea i redarea vocii i clasele UserAgentServerSIP i UserAgentClientSIP ce proceseaz i trimit cererile i rspunsurile SIP. Restul de cod este prezentat n Anexa 2. ChatArea este responsabil cu afiarea textului primit de la server n fereastra principal a aplicaiei. Ea creaz o imagine n care pun textele plus emoticoanele primi te care apoi, prin apelarea metodei paint(Graphics g) a acestei clase, din clasa Client, aceast imagine este desenat. Prin constructor i-se precizeaz unde o s deseneze imaginea. Implementarea clasei ncepe aa:

package Client; import java.awt.*; import java.awt.geom.*; import java.awt.Graphics2D; import java.awt.image.*; import java.util.LinkedList; import java.util.StringTokenizer; import javax.swing.*;

class ChatArea extends JPanel { private boolean first; private BufferedImage bimg; private Graphics2D big; private Image angel,angry,asleep,bat,birthday,boy,cat,clock,confused; private Image cry,cup,devil,dog,dontlove,drink,email,embarrassed,gift; private Image girl,handcuffs,idea,kiss,love, messenger,movie,music,no; private Image picture,rainbow,rose,star,sun,sunnyface,telephone,undecided; private Image wiltflower,yes,happy,verryhappy,surprized,tongue,wink,sad,beer; private LinkedList mesajePrimite; private int width,heigth,x,y; n aceast seciune sunt definite imaginea ce va fi desenat (bimg), (big) o instan ce va pune la dispoziie metodele necesare pentru a desena n bimg, lista de mesaje (mesajePrimite) ce va conine mesajele date de clasa Client, zona i dimensiunile imaginii ce va fi desenate i imaginile ce vor fi puse n bimg atunci cnd se ntlnete codul unui emoticon. n continuare este scris constructorul care iniializeaz atributele de mai sus:

public ChatArea(int x,int y,int w,int h) { mesajePrimite=new LinkedList(); first=false; this.x=x; this.y=y; width=w;

heigth=h;

angel=Toolkit.getDefaultToolkit().getImage("Images/angel.gif"); angry=Toolkit.getDefaultToolkit().getImage("Images/angry.gif"); asleep=Toolkit.getDefaultToolkit().getImage("Images/asleep.gif");

wink=Toolkit.getDefaultToolkit().getImage("Images/wink.gif"); yes=Toolkit.getDefaultToolkit().getImage("Images/yes.gif");

bimg=new BufferedImage(w,h,BufferedImage.TYPE_3BYTE_BGR); big=bimg.createGraphics(); } Se observ crearea unei imagini (bimg) cu dimensiunile date prin constructor i iniializarea variabilei big cu o instana tip Graphics2D fapt ce i d dreptul de a fi folosit pentru a desena n bimg. n continuare se scrie metoda cea mai important a acestei clase, metoda care formeaz imaginea bimg i o deseneaz acolo unde i-a fost indicat prin constructor:

public void paint(Graphics g) { Se definesc variabila ce va conine secvena de caractere ce trebuie desenat i variabila ce va fi folosit ntr-un ciclu for pentru desenarea tuturor mesajelor din list.

String s=null; int cont; Se definesc variabilele ce indic de unde ncepe desenarea textului n cadrul imaginii.

int pozImgY=5;

int pozImgX=10; Deoarece s-a observat c pentru desenarea pentru prima dat a unei imagini trebuie apelat metoda drawImage(..) de dou ori s-a folosit urmtorul cod ce este rulat doar o singur dat pe parcusul vieii clasei ChatArea. Problema cu afiarea imginilor a fost observat i rezolvat pe parcursul crerii versiunilor anterioare i de atunci codul nu a mai fost schimbat. Motivul pentru care o imagine, care este folosit pentru prima oar, nu se deseneaz dect dup apelul de dou ori a metodei drawImage(..) mi este necunoscut dar cred c are legtur cu ncrcarea imaginii n memorie.

if(first==false) { big.drawImage(angel,0,0,this); big.drawImage(angry,0,0,this);

big.drawImage(wiltflower,0,0,this); big.drawImage(wink,0,0,this); big.drawImage(yes,0,0,this);

first=true; } Se alege acum culoarea de fundal i se deseneaz marginile imaginii principale:

big.setColor(Color.white); big.fillRect(0,0,width,heigth); big.setColor(Color.black); big.drawRect(1,1,width-1,heigth-1); Se scrie ciclul for care este folosit pentru a desena toate mesajele din list. Metoda dim() ntoarce dimensiunea listei, metoda get(int) preia mesajul de la poziia indicat:

for(cont=0;cont<dim();cont++) { s=get(cont); String str=null; int n; while ((lengthG(s,big))>=(width-pozImgX-6)) { n=lengthG(s,big,width,pozImgX); str=s.substring(0,n); s=s.substring(n); pozImgY=drawS(str,big,pozImgX,pozImgY,pozImgY); } if(lengthG(s,big)<(width-pozImgX-6)) { pozImgY=drawS(s,big,pozImgX,pozImgY,pozImgY); }

} Metoda lengthG(String, Graphics2D, int, int ) ntoarce numrul maxim de caractere care se pot desena dintr-un mesaj dat astfel nct s nu se depeasc limea imaginii desenate i primind ca parametrii secvena de caractere, variabila folosit pentru desenare, limea i poziia de pe axa X de unde ncepe afiarea secvenei. Ciclul while este folosit pentru a mpri mesajul dat n secvene de caractere ce pot fi desenate ntr-un singur rnd. Din ciclul while se iese numai dac lungimea secvenei de caractere rmase de desenat nu depete limea imaginii din care se scade poziia de unde se ncepe scrierea secvenei i un spaiu ales de mine egal cu 6 pentru a nu se scrie exact pn la marginea zonei de afiare. Metoda length(String s, Graphics2D) ntoarce dimensiunea grafic a secvenei , secven ce a fost dat ca parametru. Metoda drawS(String,Graphics2D,int,int,int) deseneaz secvena dat ca parametru ncepnd desenarea pe axa X din poziia indicat de primul parametru ntreg iar desenarea pe axa Y ncepe din poziia indicat de unul din ultimii parametrii i ntoarce poziia pe axa Y unde a fost desenat secvena. Dup ce se iese din ciclul while se deseneaz cea mai rmas din mesajul iniial. n continuare se scot mesaje din list dac desenarea lor se face aproape de limita de jos a imaginii desenate:

if(pozImgY>(heigth-10)) { rmv(); rmv(); rmv(); } else if(pozImgY>(heigth-20)) { rmv(); rmv(); } else if(pozImgY>(heigth-40)) { rmv(); } Se scot din ce n ce mai multe mesaje dac desenarea acestora ajunge periculos de aproape de marginea inferioar a imaginii. Metoda rmv() elimin mesaje din list. Acum se deseneaz imaginea principal, fiind i ultima instruciune din metoda paint:

g.drawImage(bimg,x,y,this); } Pentru a face redesenarea se apeleaz metoda repaint() n clasa principal metod care apeleaz aici metoda update(Graphics g) :

public void update(Graphics g) { paint(g); } n continuare se scrie metoda drawS() care deseneaz mesajul primit ca parametru desennd totodat i emoticoanele corespunztoare codului. Aceast metod verific dac

mesajul are emoticoane sau nu. Dac nu are, deseneaz direct mesajul. Dac are, deseneaz mesajul pn la primul emoticon, deseneaz imaginea emoticonului i apoi metoda se apeleaz pe ea nsi pentru mesajul de dup emoticon.

private int drawS(String s, Graphics2D big,int pX, int pY, int pY1) { int x; int nr; Image img; int temp; Packet pck=trad(s); String str; S-a nceput cu declararea unor variabile cum ar fi: x-> poziia pe axa X unde s-a gsit codul emoticonului; nr-> numarul de caractere ce constituie codul; img-> va conine imaginea emoticonului; temp-> variabil folosit pentru desenarea textului cu marginea de jos la acelai nivel cu marginea de jos a imaginii; pck-> iniializat cu instana unei clase ce are ca parametrii atribute de genul x, nr, img ; str-> variabil folosit pentru desenarea mesajului pn la emoticon. Metoda trad(String) returneaz instana unei clasei Packet dac secvena pasat ca parametru are emoticoane sau null dac nu exist emoticoane n secven.

if(pck==null) { if(pY==pY1) { pY+=15; big.drawString(s,pX,pY); return pY; } else { big.drawString(s,pX,pY1); return 0;

} } n cazul secvenei fr emoticoane textul poate fi desenat n dou variante posibile. Varianta a doua de desenare se folosete pentru afiarea textului dup ce s -a desenat o imagine a unui emoticon. n prima variant se adaug 15 (dimensiunea maxim aproximativ a unui caracter pe axa Y plus spaiul lsat ntre rnduri) deoarece dimensiunea pasat cnd se apeleaz metoda reprezint poziia unde s-a desenat ultimul rnd.

else { pY+=2; x=pck.getx(); nr=pck.getnr(); img=pck.getImg(); str=s.substring(0,x); temp=pY+img.getHeight(this); big.drawString(str,pX,temp); big.drawImage(img,(pX+lengthG(str,big)),pY,this); if((x+nr)<s.length()) { drawS(s.substring(x+nr),big,((pX+lengthG(str,big)) +img.getWidth(this)),pY-=2,temp); } return temp; }

} Observaie: dac o imgine se deseneaz n punctul A, acest punct va reprezent colul stnga sus al imaginii; dac un text se deseneaz n punctul A, acest punct va reprezenta colul stnga jos al textului. n cazul secvenei cu emoticoane poziia de unde se deseneaz imaginea se mut mai n jos cu 2 pentru ca imaginea s nu fie desenat peste litere care au elemente grafice sub marginea de jos normal a unui text (cum ar fi: g, y, j, q, etc.). Apoi se ncarc n

variabilele x, nr i img rezultatul metodei trad(), n str secvena pn la primul emoticon iar n temp locul unde va fi desenat textul (se observ c textul se va desena astfel nct marginea de jos a textului s coincid cu marginea de jos a imaginii). Dup aceste atribuiri se deseneaz textul i apoi imaginea, folosindu-se pentru poziionarea imaginii metoda lengthG(String, Graphics2D) ce ntoarce lungimea secvenei desenate. Dac mai sunt caractere se reia metoda. Se ntoarce poziia unde a fost desenat textul. Acum se scrie implementarea metodei ce ntoarce dimensiunile grafice a unei secvene de caractere:

private int lengthG(String s,Graphics2D big) { return big.getFontMetrics().stringWidth(s); } n continuare se scrie implementarea metodei ce ntoarce numrul de caractere maxim pe care a-l trebui s-l aib secvena dat ca parametru pentru a putea ncpea pe limea dat i ea ca parametru:

private int lengthG(String s,Graphics2D big,int w,int pX) { int strW=0; int i=0; Packet pck=trad(s); for(i=0;i<s.length();i++) { strW+=big.getFontMetrics().charWidth(s.charAt(i)); if(pck!=null) { if(strW>(w-pX-48)) { break; } } else

{ if(strW>(w-pX-6)) { break; } } } return i; } Aceast metod verific dac sunt emoticoane sau nu. Dac nu sunt calculeaz dimensiunea grafic a caracterelor adugnd cte o dimensiune a unui caracter i dac se ajunge aproape de margine atunci se oprete calculul i se ntoarce indexul caracterului la care s-a ajuns. Dac sunt emoticoane se urmeaz acelai algoritm dar limita este mult mai drastic deoarece trebuiesc luate n considerare i limea imaginii emoticoanelor care vor fi desenate n cadrul aceluiai mesaj. La fel i n acest caz se ntoarce indexul caracterului la care s -a ajuns. Acum se arat cum s-a implementat metoda care ntoarce o instan a clasei Packet dac s-a gsit n secvena de caractere care i s-a pasat ca argument, un cod al unui emoticon:

protected Packet trad(String s) { int x; Packet pck=new Packet(); Packet temp; if((x=s.indexOf("(a)"))!=-1) { temp=new Packet(angel,x,3); if(temp.getx()<pck.getx()) pck=temp; } if((x=s.indexOf("(A)"))!=-1) { temp=new Packet(angel,x,3); if(temp.getx()<pck.getx()) pck=temp; }

if((x=s.indexOf(":@"))!=-1) { temp=new Packet(angry,x,2); if(temp.getx()<pck.getx()) pck=temp; } if((x=s.indexOf("(s)"))!=-1) { temp=new Packet(asleep,x,3); if(temp.getx()<pck.getx()) pck=temp; } if((x=s.indexOf("(S)"))!=-1) { temp=new Packet(asleep,x,3); if(temp.getx()<pck.getx()) pck=temp; }

if((x=s.indexOf("(w)"))!=-1) { temp=new Packet(wiltflower,x,3); if(temp.getx()<pck.getx()) pck=temp; } if((x=s.indexOf("(W)"))!=-1) { temp=new Packet(wiltflower,x,3); if(temp.getx()<pck.getx()) pck=temp; } if((x=s.indexOf(";)"))!=-1) { temp=new Packet(wink,x,2); if(temp.getx()<pck.getx()) pck=temp; } if((x=s.indexOf("(y)"))!=-1)

{ temp=new Packet(yes,x,3); if(temp.getx()<pck.getx()) pck=temp; } if((x=s.indexOf("(Y)"))!=-1) { temp=new Packet(yes,x,3); if(temp.getx()<pck.getx()) pck=temp; } if(pck.getx()==100) return null; else return pck; } Se face comparaia cu 100 deoarece atunci cnd se folosete constructorul fr parametrii se iniializeaz xCaract (atribut al clasei Packet) cu 100. Se observ c se returneaz instana care are cea mai mic poziie n cadrul secvenei date, deoarece ne intereseaz primul emoticon din secven, nu primul n ordine alfabetic. Se mai observ ca aceast aplicaie suport diferite coduri pentru acelai emoticon (de exemplu imaginea nger se poate afia scriind codul (a) sau (A)). n continuare se scriu implementrile ultimelor metodelor, acestea fiind folosite pentru lucrul cu lista de mesaje:

synchronized public void put(String s) { mesajePrimite.addLast(new String(s)); }

synchronized public String rmv() { return new String((String)mesajePrimite.removeFirst()); }

synchronized public String get(int i) { return new String((String)mesajePrimite.get(i)); }

synchronized public int dim() { return mesajePrimite.size(); }

synchronized public void del() { mesajePrimite.clear(); } }

List de abrevieri VoIP Voice over IP IP Internet Protocol SIP Session Initiation Protocol QoS Quality of Service GW Gateway SDP Session Description Protocol TDM Time Divizion Multiplexing RTP Real-time Transport Protocol RTCP RTP Control Protocol RTSP Real Time Streaming Protocol ISUP ISDN User Part UDP User Datagram Packet TCP - Transmission Control Protocol IntServ Integrated Services DiffServ Differentiated Services

Bibliografie

Andew S. Tannenbaum: Reele de calculatoare, ediia a patra, editura Byblos s.r.l., 2003 Olivier Hersent, David Gurle, Jean-Pierre Petit: IP Telephony, editura Pearsons Educations Limited, 2000 RFC 768, J. Postel :User Datagram Protocol, august 1980, http://ww.ietf.org/rfc/rfc768.txt RFC 1889, Audio-Video transport Working group, H. Schulzrinne i alii: RTP: A Transport Protocol for Real-Time Applications, ianuarie 1996, http://www.ietf.org/rfc/rfc1889.txt RFC 2326, H. Schulzrinne, Columbia U. i alii: Real Time Streaming Protocol (RTSP), aprilie 1998, http://www.ietf.org/rfc/rfc2326.txt RFC 2327, M. Handley, V. Jacobson: SDP: Session Description Protocol, aprilie 1998, http://www.ietf.org/rfc/rfc2327.txt RFC 2616, R. Fielding, UC Irvine i alii: Hypertext Transfer Protocol -HTTP/1.1, iunie 1999, http://www.ietf.org/rfc/rfc2616.txt RFC 2974, M. Handley, ACIRI i alii: Session Announcement Protocol, octombrie 2000, http://www.ietf.org/rfc/rfc2974.txt RFC 3261, J. Rosenberg, Dynamicsoft, H. Schulzrinne i alii: SIP: Session Initiation Protocol, iunie 2002, http://www.ietf.org/rfc/rfc3261.txt RFC 3272, A. Vermuri, Qwest Communications, J. Peterson: Session Initiation Protocol for Telephones (SIP-T), septembrie 2002, http://www.ietf.org/rfc/rfc3272.txt Carden, Philip : Building Voice over IP, publicat pe Internet http://www.networkcomputing.com/netdesign/1109voip.html What is Internet telephony?, publicat pe Internet, http://www.iptel.org/info/ Voice over IP(VoIP), publicat pe Internet, http://www.protocols.com/papers/voip.htm Tomi Yletyinen: The Quality of voice over IP, publicat pe Internet, http://keskus.hut.fi/tutkimus/ipana/paperit/tomidt.pdf

Anshul

Kundaje

alii:

Voice

over

IP,

publicat

pe

Internet,

http://www.cs.columbia.edu/~abk2001/voip.pdf Roch H. Glitho i alii: Advanced Services Arhitectures for Internet Telephony: A critical Overview, material publicat de ctre IEEE Network Stefan Pracht i alii : Voice quality in converging telephony and IP networks, publicat pe Internet http://e-insite.net/ednmag/contents/images/47172.pdf