. Comunicarea Intr O Retea Moderna Prin Voip

Scopul lucrării

În această lucrare se va face o introducere în telefonia prin Internet prezentându-se în partea teoretică modul de funcționare a acestei tehnologi împreună cu avantajele acesteia și dezavantajele față de telefonia clasică pe care cu toții o cunoaștem. O mare atenție se va acorda protocolului de semnalizare SIP împreună cu protocoalele adiacente.

Prima Parte a lucrării reprezintă partea teoretică a acestei lucrări. Prezintă motivele pentru care se folosește 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 lucrării se prezintă o aplicație software ce combină convesațiile de tip text (“chat”) cu conversațiile de tip voce (“VoIP”). Sunt descrise caracteristicile programului, modul de funcționare și modul de utilizare.

I Introducere în VoIP

1 Prezentare generală

Telefonia prin Internet definită ca și comunicația prin voce în timp real prin rețeaua cu comutație 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 agenției ARPA (“Advanced Research Projects Agency”) implementa o infrastructură pentru comunicarea prin voce în timp real încă din decembrie 1973. Protocolul ce stă la baza implementării, “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].

Totuși 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 obișnuit o placă de sunet, un microfon, boxe. Pe lângă acestea mai este nevoie și de un software proiectat pentru transmisia și recepția vocii prin rețea care acum se găsește foarte ușor. Având în vedere răspândirea calculatoarelor și a conexiunilor la o rețea de date pe scară mondială, telefonia peste rețelele de pachete este posibilă pentru un număr foarte mare de utilizatori.

La prima vedere transmisia vocii prin rețelele de date pare o idee proastă. Deja există o rețea telefonică ce se bazează pe comutarea de circuite și care se extinde peste cele șapte continente și formează cea mai mare rețea construită vreodată de om. În plus rețele de date sunt și nepotrivite pentru transmisia vocii. Aceasta este o aplicație în timp real și necesită privilegii speciale din partea rețelei deoarece în prezent cele mai multe rețele nu asigură servicii de timp real. Totuși VoIP a găsit clienți deoarece propunea la momentul apariției 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 satisfăcătoare dacă prețul este convenabil. Astfel motto-ul “într-o piață competitivă și dezvoltată trei lucruri sunt importante: prețul, prețul și prețul” se adeverește încă o dată.

În viitor tarifele pentru apelurile la distanță se vor micșora nu din cauza VoIP, ci din cauza competiției din ce în ce mai acerbe între furnizorii de servicii. Avantajul din punctul de vedere al tarifelor se va diminua, dar experții afirmă că această tehnologie are un viitor strălucitor. Datorită multiplexărilor statistice și metodelor avansate de compresie, VoIP va fi prezenta în continuare tarife mai mici decât transmisia vocii prin rețelele bazate pe comutarea circuitelor. Alt avantaj ce impune această tehnologie pe piață îl reprezintă suportul pentru conferințe ce permite realizarea unor conversații î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 distanța dintre apelat și apelant, astfel pentru distanțe medii și mari telefonia prin Internet este mai rentabilă decât cea tradițională. Dar pe lângă prețurile mai reduse, calitatea convorbirii trebuie să fie cel puțin la aceeași nivel cu cea oferită de telefonia clasică și în plus să se asigure și alte serviciile speciale.

Transmisia vocii și a datelor pe rețeaua cu comutație de pachete reprezintă o folosire mai eficientă a rețelei decât în cazul telefoniei tradiționale unde o parte din resursele rețelei se pune la dispoziția utilizatorului pe tot parcursul convorbirii chiar dacă acesta vorbește sau nu.

Telefonia clasică oferă astăzi pe lângă 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, restricționarea 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 adevărat cu telefonia clasică.

Utilizatorii de telefonie prin Internet pot profita și de natura software a acesteia. Soluțiile software pot fi ușor extinse și integrate cu alte servicii și aplicații cum ar fi “whiteboard”, calendar electronic sau internet propriu-zis. Dezvoltarea de servicii noi necesită mult mai puține investiții în timp și bani decât dezvoltarea de servicii pentru rețeaua cu comutație de circuite.

O aplicație pentru telefonia prin Internet poate fi transmisia în timp real al facsimilelor. Calitatea transmisiilor faxurilor sunt în mod tipic afectate de întârzierile din rețea, compatibilitatea mașinilor și calitatea semnalului analogic. Pentru a trimite faxuri prin o rețea cu comutație 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ă aplicație este și mai critic fenomenul de pierdere a pachetelor decât pentru aplicațiile de voce.

Multe alte aplicații pot implementa VoIP. De exemplu, mesajele sonore pot fi pregătite utilizând un telefon și apoi livrate unei căsuțe poștale ce poate conține și voce și date folosind Internetul sau serviciile intranet. Documentele ce conțin note audio, fișierele multimedia, etc. pot ușor ajunge standarde în aplicațiile tip “Office” în viitorul apropriat.

Principalele justificări pentru dezvoltarea VoIP pot fi concentrate după cum urmează:

Preț redus. Cum s-a menționat mai sus, sunt avantaje reale pentru convorbiri pe distanțe mari, lucru de mare importanță pentru companiile ce au legături cu alte țări.

Simplificare. O rețea voce/date permite standardizarea mai ușoară și reduce necesarul de echipament.

Aplicații avansate. Beneficiile pe termen lung ale VoIP includ și suportul pentru aplicațiile multimedia și cu multiple întrebuințări, cu care sistemul telefonic actual nu poate concura.

Creșterea pieței VoIP a fost spectaculoasă în ultimii ani și se crede că această tendință va continua. Totuși, exista numeroase aspecte ce trebuiesc îmbunătățite de către dezvoltatorii de echipamente VoIP cum ar fi calitatea vocii, întârzierea și pierderea pachetelor dar și controlul apelurilor și managementul sistemelor [13].

Pentru interconectarea cu celelalte rețele de telefonie este folosit un “gateway” care în română poate fi tradus ca “convertor de interconectare” sau mai simplu poartă. În continuare am păstrat 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 rețeaua IP, un “gateway” este un server la care utilizatorul sună așa cum ar suna la server-ul unui furnizor de Internet de la modemul calculatorului. Server-ul îi va cere utilizatorului să introducă informațiile privitoare la contul folosit și numărul la care va suna, apoi va pachetiza semnalul vocal, fiecare pachet având în antet informațiile necesare care să-l trimită spre un alt “gateway” unde procesul va fi inversat și apelul va fi trimis spre un telefon obișnuit. Pe de altă parte ultimul “gateway” care este localizat cât mai aproape de centrala apelatului, formează numărul telefonului apelat și când conexiunea a fost stabilită, începe să trimită semnalul de voce al apelantului într-un sens și în celălalt sens vocea pachetizată a apelatului.

“Gateway-urile” permit ca apelurile de lungă distanță sau cele internaționale să “pară” sistemelor de taxare ale operatorilor PSTN ca și cum ar fi apeluri locale. Nu toate server-ele inițiale trimit apelurile PSTN spre Internet și nu toate server-ele finale primesc apeluri din Internet. “Gateway-urile” pot fi conectate la orice fel de rețea IP, și în cazul furnizorilor de telefonie IP comerciali acea rețea nu este Internetul public.

Mulți furnizori, totuși, Internetul public este folosit pentru o parte sau pentru tot procesul de rutare a pachetelor de voce și aceasta are implicații în calitatea apelului. Odată intrate pe Internet, pachetele sunt tratate la fel cu celelalte pachete indiferent dacă conțin text, grafice sau video. Atunci când ajung la “gateway-ul” final pachetele sunt procesate și trimise spre rețeaua PSTN.

Operatorii de “gateway-uri” preferă să plaseze echipamentele în marile centre metropolitane, unde pot fi contactați cei mai mulți abonați 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ă plătească pentru liniile de acces în rețeaua PSTN, care sunt în general aceleași linii cu cele administrate de furnizorii de Internet, astfel încât utilizatorii să se poată conecta prin conexiuni “dial-up” la ambele servicii.

Utilizatorii de telefonie IP care sunt conectați în permanență la o rețea locală nu apelează la un “gateway”, cel puțin nu în prima fază. În schimb rețeaua lor este conectată mereu la unul sau mai multe echipamente de acest tip. În rețelele de telefonie IP ce țin de o companie sau de un grup restrâns apelurile ar putea să nu treacă niciodată printr-un “gateway”.

Scenariile de folosire a telefoniei prin rețelele de pachete sunt clasificate după tipul terminalelor ce se află la capetele unui apel. Deoarece la fiecare capăt al “firului” poate fi un telefon obișnuit 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 rețea (calculatoare personale, telefoane IP, etc.). Scenariile sunt:

Terminalul apelantului: PC, terminalul apelatului: PC. Acestă situație este atractivă pentru utilizatorii privați 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 integrării serviciului de telefonie cu alte servicii Internet, ca WWW, mesagerie instantanee, e-mail, etc. . Pentru apelant costul convorbirii îl reprezintă costul conectării la Internet, costul achiziționării pachetului software care deobicei este zero, plus costurile aferente deținerii și întreținerii hardware-lui necesar.

Terminalul apelantului: PC, terminalul apelatului: telefon legat la una din rețelele non-ISDN, ISDN, GSM, …. Acest scenariu reprezintă o extensie a scenariului precedent în care cei care folosesc un PC ca telefon pot vorbi și cu utilizatorii rețelei PSTN. Este folosit un “gateway” ce convertește apelul prin Internet într-un apel PSTN. Acest gateway trebuie să fie cât mai aproape de reședința apelatului pentru ca să se minimizeze costurile conexiunii gateway-apelant. Acest scenariu este comercializat de operatorii de gateway-uri. Pentru apelantoperatorii de gateway-uri. Pentru apelant costurile inițierii convorbirii și menținerii acesteia sunt suma costului accesului la Internet, a costului deținerii software-lui care este de obicei zero, a costului cerut de operatorul gateway-ului folosit ce depinde în mare măsură de costul conexiunii gateway-utilizator apelat și a costului dețineri și întrețineri 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 fără alte aparate în plus. Apelul trebuie să treacă prin două gateway-uri: PSTN-Internet și Internet-PSTN. Această soluție este comercializată de operatorii de gateway-uri. Costurile se compun din tarifele percepute de cele două gateway-uri (tariful perceput de gateway-ul de destinație este proporțional 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 conțin tariful gateway-ului folosit și costul apelului până la acesta [12].

Indiferent de ce se află între interlocutori, o conversație telefonică între două persoane impune ca fiecare să aibă un microfon și un difuzor. În telefonul tradițional, microfonul și difuzorul sunt incluse în receptor. În telefonul analogic (pe care toți îl cunoaștem) semnalul vocal produs de microfon este trimis direct printr-un fir către centrala locală. Dacă se folosește 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 recepție. 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 cunoaște tehnicile VoIP. Indiferent de aparatul folosit, mecanismul unui apel telefonic prin Internet este același.

Deci ce se întâmplă atunci când dorim să inițiem un apel? Mai întâi, după ce am tastat un număr de telefon sau am accesat un link conținând numele interlocutorului dorit, este necesar să pornească procesul de semnalizare pentru a determina starea terminalului apelat – disponibil sau ocupat – și să stabilească conexiunea. Apoi, când conversația a început, semnalul analogic produs de microfon trebuie codat într-un format digital corespunzător transmisiei prin rețea cu comutație de pachete. Rețeaua însăși trebuie să asigure că datele produse de conversația în timp real este transportată peste mediul avut la dispoziție î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 interoperabilității cu o altă schemă multimedia, ori destinația apelului se află într-o rețea telefonică tradițională [11] .

Ținând cont de ceea ce s-a scris în paragraful de mai sus se poate emite ideea că, în mare, necesarul tehnologic al unei soluții VoIP se poate împărți î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, amănunte putându-se citi în cartea “IP telephony” [2] .

2. Transportul datelor

Semnalul analogic primit de la microfonul folosit de utilizator este eșantionat după anumiți parametri acceptați de toți interlocutorii în faza premergătoare apelului propiu-zis. În urma acestui proces se obțin datele ce trebuiesc trimise la aparatele ce participă la această conversație. Înainte să prezint protocoalele folosite pentru transferul informației voi menționa câteva din problemele care trebuie rezolvate pentru a avea o calitate bună.

2.1 Problemele transportului datelor în timp real

Cel mai răspândit sistem telefonic este astăzi cel analogic. Acest sistem folosește modulația semnalelor electrice pe un fir pentru a transporta vocea.

Deși este o tehnologie veche, transmisia analogică are multe avantaje: este simplă și este caracterizată de o întârziere a transmisiei foarte mică deoarece semnalul se propagă pe fir aproape cu viteza luminii. Este de asemenea și foarte ieftină atunci când sunt puțini utilizatori care vorbesc în același timp, și când sunt la mică distanță unii față de alții. Dar și cea mai simplă tehnologie analogică necesită o pereche de fire pentru fiecare conversație, fapt ce devine rapid nepractic și foarte costisitor. O primă îmbunătățire a acestei tehnologii a fost să se multiplexeze mai multe conversații pe același fir, folosind diferite frecvențe de transport pentru fiecare semnal. Dar și această versiune are deficiențe:

dacă nu se folosesc centrale (switchboards) manuale, comutația automată necesită numeroase mecanisme electromecanice care sunt costisitoare de cumpărat și de întreținut;

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 rețea telefonică digitală. În cele mai multe cazuri linia abonatului rămâne analogică, dar semnalul este convertit la un flux digital în prima centrală. De obicei, acest semnal are o rată de 64kb/s (un eșantion de 8 biți la fiecare 125μs).

Acum multe canale de voce pot fi multiplexate pe aceeași linie de transmisiune folosind o tehnologie numită multiplexare cu diviziune în timp (TDM). În acestă tehnologie, fluxul digital ce reprezintă o singură conversație este împărțită în blocuri (de obicei în octeți, denumite și eșantioane), și blocuri de la mai multe conversații sunt întrețesute într-o manieră round-robin în sloturile temporale ale liniei de transmisiune.

Cu această tehnologie digitală, zgomotul care se amestecă cu semnalul original nu influețează calitatea comunicației deoarece semnalele digitale pot fi refăcute. Mai mult, multiplexarea cu diviziune în timp face posibilă comutația digitală. Comutatorul trebuie să copieze conținutul unui slot temporal din transmisia de intrare în alt slot temporal din transmisia de ieșire. De aceea funcția de comutare poate fi realizată folosind calculatoare. Totuși o mică întârziere este introdusă de fiecare comutator deoarece pentru fiecare conversație un slot temporal este disponibil numai la fiecare T microsecunde, și în unele cazuri ar putea fi necesar să se aștepte până la T microsecunde pentru a copia conținutul unui slot în altul. Tinând cont că T este 125μs în cele mai multe rețele digitale, acest timp este neglijabil și întârzierea depinde în principal de timpul de propagare.

Numai în cazul în care dorește să impună un punct de vedere, un utilizator va vorbi în mod normal în numai jumătate din timpul total al conversației. Și cum înainte de a vorbi trebuie să se gândească puțin va utiliza numai 35% din timpul unei conversații normale. Dacă, acest utilizator, ar putea să apese pe un buton de fiecare dată când are ceva de spus, el va trimite spre rețea informații numai atunci când vorbește nu și când tace. Cum vom vedea mai târziu, cele mai multe tehnici folosite pentru a transforma vocea în biți de informație (numite codecuri) au acum posibilitatea să detecteze perioadele de liniște, atunci când utilizatorul nu vorbește. Cu acestă metodă, cunoscută ca detecția activități vocii (“voice activity detection”), înloc să se transmită informații, voce sau liniște la fiecare 125 microsecunde, cum se face astăzi, se poate transmite informații doar atunci când trebuie, în mod asincron.

Când este vorba de multiplexarea a mai multor conversații pe aceiași linie de transmisiune, în loc să se ocupe banda tot timpul, această bandă poate fi folosită de altcineva atunci când un anumit utilizator tace. Acest mod de multiplexare este cunoscută ca multiplexare dinamică (sau statistică).

Principalul avantaj al acestei multiplexări este că permite ca banda totală a unei linii poate fi folosită mult mai eficient, în special atunci când sunt multe conversații pe aceiași linie. Dar multiplexarea dinamică introduce incertitudinea în rețea. Tocmai am spus că în cazul TDM, o întârziere de până la T microsecunde poate fi introdusă la fiecare comutator; această întârziere este constantă pe parcursul întregii conversații. Situația este total diferită la multiplexarea dinamică: dacă linia de transmisiune este goală atunci când trebuie trimise date prin rețea, acestea vor trece imediat. Dacă, pe de altă parte, linia este ocupată, datele trebuie să aștepte până când va exista posibilitatea de a le trimite.

Acestă întârziere variabilă se numește jitter și trebuie corectată de partea ce recepționează datele. Altfel, dacă bucățile de date sunt redate imediat cum sunt primite, cea ce a spus transmițătorul mesajului poate devenii inteligibil.

Următoarea generație de telefonie va utiliza probabil multiplexarea dinamică și va mixa voce și date pe aceeași linie de transmisiune. Mai multe tehnologi sunt bune candidate pentru aceasta, ca de exemplu voce peste “Frame Relay”, voce peste ATM și bineînțeles voce peste IP. Se crede că voce peste IP este cea mai flexibilă soluție deoarece nu necesită stabilirea de canale virtuale între dispozitivele care vor comunica. Aceasta este scalabilă mai mult decât ATM sau Frame Relay în termeni de conectivitate [2].

VoIP se confruntă cu destul de multe probleme tehnice; deoarece rețelele IP existente nu au fost proiectate să servească aplicațiile în timp real adică aplicații care au limite impuse privind timpul de răspuns. Cerințele pentru voce sunt dure: pentru o comunicație în timp real de calitate bună este necesară o întârziere maximă dus-întors de 200 – 300 ms adică pe un sens întârzierea nu trebuie să depășească 100 – 150 ms. Pentru a compensa jitterul este folosit la recepție un buffer; lungimea acestui buffer influențează și el întârzierea dus-întors. De aceea jitterul trebuie să fie mic astfel încât redarea sunetului la recepție să rămână 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 bucăți din semnalul primit de la microfonului transmițătorului și astfel redarea la recepție se face cu întreruperi.) Din păcate pierderea de pachete în Internet este corelată deoarece pierderile apar în timpul congestiilor și aceste pierderi continue de pachete reduc substanțial inteligibilitatea vocii.

Voi face în continuare o prezentare mai detaliată a principalelor probleme:

pierderea pachetelor;

întârzierile;

jitterul.

2.1.1 Pierderea pachetelor

Este un lucru comun în rețelele cu comutație de pachete, deoarece pe măsură ce rutele devin congestionate, cozile de așteptare în elementele de rutare devin neîncăpătoare și nu va mai fi loc pentru alte pachete și acestea vor fi aruncate. Pierderea de pachete poate duce la degradarea calității vocii. Fiecare pachet conține între 20 – 80ms, în funcție de codecul folosit, din semnalul captat de microfon. Când sunt doar câteva pachete pierdute, creierul uman este capabil să reconstruiască zonele pierdute, dar dacă numărul pachetelor este mare vocea redată este neinteligibilă. În continuare sunt prezentate tehnicile prin care se poate rezolva problema pierderii pachetelor:

Îmbunătățirea rețelei. Deoarece fenomenul de aruncare a pachetelor este strâns legat de banda insuficientă a conexiunilor și de viteza de procesare a elementelor de rutare, îmbunătățirea rețelei poate fi o soluție pentru această problemă.

Înlocuirea cu pauze. La destinație conținutul pachetelor este redat, apărând probleme atunci când pachetele a căror informație trebuia redată nu mai sosesc fiind întârziate sau pierdute. Înlocuirea cu pauze rezolvă această problemă prin redarea de liniște în locul informației din pachetele pierdute. Din păcate, dacă rata de pierdere a pachetelor este prea mare sau pachetele sunt prea mari (adică conțin fragmente mari de semnalul captat) în semnalul redat apar frânturi din semnalul original, lucru ce deteriorează semnificativ calitatea vocii.

Înlocuirea cu zgomot. Această metodă înlocuiește zonele fără informație cu zgomot. Studiile arată că se obțin performanțe mai bune decât metoda precedentă.

Repetarea pachetelor. Redarea informației din ultimul pachet recepționat corect, atunci când un pachet lipsește este o altă metodă de a recupera din pagubele produse de pierderea de pachete.

Interpolarea pachetelor. Folosește caracteristicile vocii din pachetele învecinate pentru a estima informația audio ce s-a pierdut. Sunt câteva tehnici de interpolare și studiile în această privință au arătat că această metodă poate avea performanțe mai bune decât cele menționate mai sus.

Întrețesarea eșantioanelor audio pe mai multe pachete(“frame interleaving”). În rețelele cu comutație 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. Întrețeserea eșantioanelor audio pe mai multe pachete poate reduce acest efect. Dezavantajul multor eșantioane pentru a le întrețese.

Transmisie redundantă. Informația dintr-un pachet este în mod redundant transmisă în pachete consecutive. În cazul în care pachetul original este pierdut, acesta poate fi refăcut din pachetele următoare.

2.1.2 Întârzierea pachetelor

Întârzierile de lungă durată provoacă intrarea participanților la o conversație într-un mod de comunicație half-duplex, adică unul dintre ei vorbește și ceilalți așteaptă un timp pentru ca să fie siguri că vorbitorul a terminat ce are de zis. Dacă timpul de așteptare este ales în mod eronat, pot exista doi sau mai mulți vorbitori în acealși timp. Întârzierile de lungă durată este un efect păgubos și din cauza ecoului care face ca vorbitorul să și audă propria sa voce după un timp după ce a terminat de vorbit. Cerințele exacte în privința întârzieri 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 când vorbește, este aceptabilă pentru cele mai multe aplicații. Pe măsură ce întârzierea crește interlocutorii încep să vorbească în același timp sau se confruntă cu un ecou deranjant, adică calitatea convorbirii este foarte scăzută. Totuși, întârzieri între 150 și 400ms sunt acceptate pentru convorbiri între persoane aflate la mare distanță. Întârzierea este una din cele mai mari probleme cu care se confruntă telefonia prin Internet. În rețelele cu comutație de pachete factorii cauzatori sunt:

Întârzierea produsă de codecuri. Funcția 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 obținute cu ajutorul unor algoritmi ce au ca dezavantaj timpul de procesare destul de mare. Întârzierea este compusă din timpul necesar prelucrării eșantioanelor ce intră într-un singur pachet și din timpul necesar observării eșantioanelor următoare pentru a exploata anumite corelații ce ar putea apare. Timpul necesar decodării este de obicei jumate din timpul necesar codării deci la recepție întârzierea produsă este mai mică decât cea produsă la transmisie.

Întârzierea din cauza transmisiei. Reprezintă timpul necesar pentru a pune un pachet pe linia de transmisiune și este determinat de viteza liniei și de mărimea pachetului.

Întârzierile produse de cozile de așteptare. Acest timp pierdut reprezintă problema cea mai important introdusă de rețelele cu comutație de pachete. Depinde de numărul de pachete ce așteaptă în coadă și variază enorm de la un pachet la altul. Întârzierea produsă de cozile de așteptare este principala problemă pentru aplicațiile în timp real deoarece este o sursă pentru jitter.

Întârzierile cauzate de propagare. Reprezintă timpul necesar pentru ca semnalul să ajungă de la un punct al rețelei la celălalt și este determinată de viteza lumini. Acest timp devine important dacă distanțele între puncte este mare cum ar fi căzut legăturilor prin satelit.

2.1.3 Jitterul

Jitterul reprezintă variația duratei de timp între pachetele primite la recepție. Mai poate fi definit ca variația întârzierilor la care sunt supuse pachetelor. Acest fenomen este o problemă importantă ce trebuie depășită în comunicațiile prin voce. Jitterul apare mai ales din cauza întârzierilor produse de cozile de așteptare, dar poate proveni si din faptul că pachetele pot parcurge trasee diferite. Pentru a-l compensa, la recepție, se folosește un buffer în care sunt ținute primele pachetele sosite pentru o durată de timp definită înainte ca informația conținută să fie redată. Întârzierea produsă de acest buffer se adaugă la întârzierea totală deci pentru a avea o comunicație de calitate trebuie să avem de asemenea un jitter mic. În mod ideal, dimensiunea buffer-ului este aleasă în mod dinamic în concordanță cu situația rețelei. De obicei dimensiunea buffer-ului este de 50 – 100ms.

În figura I.1 este prezentată o situație ce s-ar putea întâmpla din cauza jitter-ului. O frază rostită normal ar putea ajunge la celălalt capăt cu întreruperi.

Figura I.1 Jitter-ul

2.2 RTP (RFC 1889)

Am văzut că atunci când o rețea cu multiplexare dinamică este folosită pentru transmisia datelor în timp real, ca de exemplu vocea, jitterul trebuie luat în considerație de către 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 informațiilor 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 conferințele multimedia interactive, ca sincronizarea redării informațiilor primite, demultiplexare, identificarea tipului de mediu folosit pentru transmisie și identificarea participanților activi. Totuși, nu numai aplicațiile pentru conferințe multimedia pot beneficia de RTP, ci și stocarea de date continue, distribuția interactivă de date cu formate multimedia, simulări realizate în paralel pe mai multe terminale și aplicațiile de măsură și control pot profita de avantajele aduse de RTP.

Scopul proiectării RTP a fost obținerea unui protocol cu următoarele caracteristici:

Flexibil. RTP nu trebuie să fie limitat numai pentru conferințe 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 cât dimensiunea informațiilor propriu-zise. De exemplu pentru pachetele ce conțin 65ms de voce codată de o procedură ce oferă 4800bit/s dimensiunea informației transportate este 39 de octeți. Ipv4 introduce 20 de octeți în antet, UDP[3] încă 8 octeți și nivelul de transport alți cel puțin 8 octeți. Cu antetul RTP de 4 – 8 octeți dimensiunea antetului totală poate ajunge la 40 – 44 de octeți. Acest fapt poate sta în calea folosirii RTP pe conexiuni de mică viteză.

Internațional. Protocolul trebuie să includă codări de tipul legea A, legea μ dar și seturi de caractere non ASCII.

Eficient din punct de vedere al procesării. Și cele mai mari intervale de timp conținute î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 aceea trebuie să fie posibil să fie implementat având la dispoziție 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 decât 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ă informații isocrone prin următoarele informați incluse în antet:

Informații referitoare la tipul datelor transportate;

Informații referitoare la tipul la care au fost emise (timestamps);

Numere de secvență.

Un alt protocol, RTCP, ce este în mod obișnuit folosit împreună cu RTP, permite ajungerea la transmițător a rapoartelor privind calitatea transmisiei (mărimea jitterului, numărul de pachete pierdute, etc.) și poate transporta câteva informații privind identitatea participanților.

RTP și RTCP nu au nici-o influență asupra comportării rețelei IP; acestea nu controlează în nici-un fel calitatea seviciului. Rețeaua poate elimina, întârzia pachetele RTP sau schimba ordinea acestora, ca orice pachet IP. RTP și RTCP doar permit receptoarelor să aibă o funcționare corectă chiar dacă rețeaua produce jitter prin folosirea de buffere și să dețină mai multe informații despre rețea pentru ca măsurile de corectare corespunzătoare să fie aplicate (redundanță, codecuri cu rată scăzută, 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 întârzieri foarte mici, cum sunt comunicațiile interactive. În acest caz RTP este asociat în mod tradițional unui port UDP par iar RTCP următorului port UDP impar.

Așa cum se poate citi din RFC-ul 1889, RTP este un protocol ce asigură servicii de transport capăt la capăt al unor date cu caracteristici de timp real, cum ar fi audio sau video facând parte dintr-o comunicație interactivă. Printre aceste servicii sunt incluse indentificarea tipului datelor transportate, numerotarea pachetelor, ștampilarea cu informații de timp a pachetelor și monitorizarea livrării.

Aplicațiile folosesc în mod obișnuit RTP peste UDP pentru a beneficia de serviciile sale de multiplexare și de verificare a corectitudini informațiilor (prin suma de verificare). RTP permite și transferul datelor către destinații multiple folosind distribuția de tip multicast dacă această este furnizată de către rețeaua 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 garanții. Acesta nu garantează transportul sau transportul în secvență și nici nu presupune că rețeaua folsită este sigură și livrează pachetele în secvența în care au fost transmise. Numerele de secvență incluse în RTP permit receptorului să reconstruiască secvența în care a transmis transmițătorul.

Acest protocol este de multe ori integrat în procesele desfășurate de către o aplicație decât să fie implementat ca un strat separat. În timpul creări protocolului nu s-au specificat toate elementele pentru a se permite modificările. Pe lângă RTP o implementare completă pentru o anumită aplicație 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 câteva utilizări importante ale câmpurilor RTP:

– numărul de secvență și informația de timp. Fiecare pachet RTP conține un număr de secvență și o informație de timp. În funcție de aplicație, acestea pot fi folosite în mai multe moduri. O aplicație video, de exemplu, poate imediat deduce din informația de timp pentru ce zonă din ecran este informația dintr-un anumit pachet. Chiar dacă nu a primit pachetele care erau înaintea acestuia din cauza pierderilor sau a întârzierilor, aplicația poate folosi pachetul pentru a construi imaginea ce o descrie.

O aplicație audio nu poate folosi această informație în acest mod, deoarece nu se poate înțelege vocea cu porțiuni lipsă sau chiar cu porțiuni care nu sunt în secvența în care au fost înregistrate, dar poate folosi numărul de secvență și informația de timp pentru a controla un buffer de recepție. De exemplu, o aplicație poate decide că va păstra, într-un buffer, 100ms de voce înainte de a le reda. De fiecare dată când un nou pachet RTP va sosi, el este plasat în buffer în poziția corespunzătoare în funcție de numărul de secvență. Dacă un pachet nu ajunge la timp și încă lipsește atunci când ar trebui redat, aplicația poate să copieze informația din ultimul pachet care tocmai a fost redat și să o repete destul timp pentru ca să se ajungă la o valoare a timpului redării echivalentă cu informația de timp din următorul pachet primit, sau să folosească o schemă de interpolare definiă de codecul folosit.

– tipul informației transportate. Formatul informației de timp real transportate este nespecificată în RFC 1889 și trebuie definită ori de aplicație ori de profilul RTP folosit. Pentru a distinge dintre un format particular și altul fără a analiza conținutul pachetului, antetul RTP conține un identificator al tipului informației.

În continuare voi prezenta câteva exemple de folosire a RTP-ului:

– O simpla audio conferință. Un grup de lucru se întâlnește pentru a discuta folosind serviciile multicast ale Internetului pentru comunicații de voce. Printr-un mecanism oarecare de alocare se obține o adresă multicast și o pereche de porturi. Un port este folosit pentru datele audio și celălalt este folosit pentru pachetele de control (RTCP). Adresa de multicast și porturile sunt distribuite participanților doriți. Dacă se dorește ca această conferință să nu fie ascultată și de alți participanți nedoriți, 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ă participanților doriți.

Aplicațiile de audio conferință folosit de fiecare participant trimite date audio în bucăți mici, de exemplu, de durată 20ms. Antetul RTP și datele sunt încapsulate într-un pachet UDP. Antetul RTP indică tipul codări (ca PCM, ADPCM sau LPC) datelor din fiecare pachet pentru ca receptori să poate cunoaște tipul datelor primite iar transmițătorii să poată modifica tipul codării în timpul conferinței pentru, de exemplu, a permite recepția de către un nou participant ce este conectat printr-o legătură cu bandă mică sau pentru a reacționa la congestia rețelei.

Internetul, ca orice altă rețea de pachete, ocazional pierde și reordonează pachetele și le întârzie cu o durată variabilă de timp. Pentru a învinge aceste impedimente, antetul RTP conține informații de timp și un număr de secvență care permit receptorilor să reconstruiască secvența înregistrată de sursă, pentru ca în acest exemplu, porțiunile primite să fie redate la fiecare 20 de milisecunde. Această reconstrucție este aplicată pentru fiecare sursă de RTP ce ia parte la această conferință. Numărul de secvență poate fi de altfel folosit și la determinarea de către receptor a numărului de pachete ce au fost pierdute.

Deoarece membrii grupului pot intra sau părăsi conferința în timpul conferinței, este necesar să se știe cine participă la un moment dat și cât de bine se recepționează datele audio. Pentru acest scop fiecare instanță a aplicație audio din conferință, în mod periodic, trimite în mod multicast un raport de recepție plus numele persoanei care folosește această instanță spre portul RTCP. Raportul indică cât de bine este recepționat vorbitorul curent și poate fi folosit pentru a controla codecurile adaptive. Pe lângă numele utilizatorului și alte informații de indentificare pot fi incluse. O locație trimite pachetul RTCP BYE când părăsește conferința.

– Conferință audio și video. Dacă se folosesc în aceeași conferință ambele modalități (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 legătură la nivelul RTP între fluxurile audio și video, cu excepția că utilizatorul ce participă în ambele sesiuni trebuie să utilizeze același nume în pachetele RTCP pentru ca sesiunile să poată fi asociate.

O motivare pentru această separare o reprezintă posibilitatea ce se acordă participanților să aleagă modul de primire a datelor (numai audio, numai video sau ambele). În ciuda separării, sicronizarea redării fluxurilor audio și video poate fi realizată folosind informațiile de timp transportate în pachetele RTCP pentru cele două sesiuni.

– Mixere și translatoare. Până acum, în exemplele prezentate s-a presupus că toți participanți doresc să primească fluxurile în același format. Totuși, acest lucru nu se poate realiza întotdeauna. Să considerăm cazul în care participanții dintr-o zonă sunt legați printr-o conexiune de viteză mică de ceilalți participanți care se bucură de conexiuni de mare viteză. În loc să se impună tuturor folosirea unui codec ce produce fluxuri de calitate și bandă scăzută, un releu la nivelul RTP-ului numit mixer poate fi plasat lângă 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 conține datele rezultate pe link-ul ce duce spre zona ce o deservește 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 rapotându-se corect vorbitorul curent la receptor.

Câțiva participanți la conferință ar putea fi conectați printr-o conexiune de mare viteză dar ar putea de asemenea să nu fie direct accesibili prin multicast prin IP. De exemplu, aceștia ar putea fi în spatele unui firewall la nivel aplicație care elimină toate pachetel IP. Pentru aceste stații, folosirea unui mixer nu ar fi necesară, dar trebuie folosit alt obiect ce lucrează la nivelul RTP-ului, numit translator. Doi translatori sunt instalați de fiecare parte a firewall-ului, cel din exterior trimițând 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 proiectați pentru o gamă largă de scopuri. Un exemplu ar fi un mixer care modifică imaginile primite prin mai multe fluxuri combinându-le într-un singur flux video pentru a crea o imagine în care toți participanții sunt prezenți.

Înainte de a prezenta câmpurile ce sunt prezente într-un pachet RTP câteva definiții sunt necesare:

Sesiune RTP. O sesiune RTP reprezintă un grup de participanți ce comunică prin RTP. Fiecare participant folosește 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 folosește o transmisie multicast, toți participanții folosesc aceeași pereche de adrese multicast de nivel 4 (de transport). Fluxurile media din aceeași sesiune ar trebui să folosească același canal RTCP.

Sursă de sincronizare SSRC. Sursa unui flux RTP, identificată printr-un câmp de 32 de biți din antetul RTP. Toate pachetele RTP cu un SSRC comun au aceeași referință de timp și de sincronizare, deci un receptor grupează pachetele dupa sursa de sincronizare în vederea sincronizării. Exemplele de surse includ transmițătorul unui flux de pachete obținute 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 încât această valoare să fie unică într-o sesiune RTP. Un participant nu trebuie să folosescă același identificator pentru toate sesiunile dintr-o sesiune multimedia; legătura 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. Când un flux RTP este rezultatul unei combinări (mixări) a mai multe fluxuri, lista de SSRC-uri a fiecărui flux folosit este adăugată în antetul RTP-ului al fluxului rezultat ca CSRC. Acest flux are propriul lui SSRC.

Formatul NTP. O modalitate standard de a exprima (scrie) informația de timp din fiecare pachet, prin scrierea numărului de secunde trecute din 1 ianuarie 1900, ora 0, cu ajutorul a 32 de biți pentru partea întreagă și 32 de biți pentru partea zecimală (în cazul părții zecimale numărul este exprimat în ½^32 secunde). O formă mai compactă există cu numai 16 biți pentru partea întreagă si 16 pentru partea zecimală. Primi 16 biți ce s-au omis pot fi obținuți din ziua curentă, iar partea zecimală este pur și simplu truncată la partea cea mai semnificativă.

Pachetul RTP conține întotdeauna toate câmpurile până la lista CSRC. Această listă există numai după ce pachetul trece de un mixer. Câmpurile sunt:

2 biți sunt rezervați pentru versiunea folosită de RTP.

Un bit ce indică adăugarea de biți în plus din cosiderente de aliniere. Dacă pachetul a fost modificat (P=1), atunci ultimul octet al câmpului de indică tipul datelor transportate indică mai precis câți octeți au fost adăugați.

Un bit de extensie X indică prezența extensiilor după eventuala listă CSRC a antetului fix. Extensiile au forma prezentată în figura I.2.

Figura I.2 Extensia antetului

Câmpul de 4 biți CC indică numărul 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 aplicația folosită și numit profil RTP. A fost pus cu intenția pentru a permite semnalizarea unor evenimente importante cum ar fi marginile unui cadru în fluxul de pachete. Acel document ar putea defini și alți biți de marcaj sau specifica că nu există bit de marcaj prin modificarea numărului de biți din câmpul tipul informației transportate (sarcini).

Tipul informației transportate(PT). Are 7 biți și identifică forma informației transportate și determină interpretarea acesteia de către aplicație. Documentul amintit mai sus specifică o corespondență statică între coduri de identificare a tipului informației și diferite formate de date. În plus se pot defini alte corespondențe dinamice prin mijloace non-RTP. Un emitor RTP trimite un singur identificator de sarcină la un moment dat; acest câmp nu este destinat pentru multiplexarea a unor fluxuri media diferite. Figura I.3 prezintă o parte din identificatori statici.

Figura I.3 Identificatori statici

Numărul de secvență (16 biți). Numărul 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 inițială a numărului este aleatorie pentru a face atacurile asupra fluxurilor codate mai dificile.

Figura I.4 Pachetul RTP

Informația de timp (32 de biți). Aceasta reflectă momentul când s-a făcut eșantionarea primului octet din datele conținute î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. Rezoluția ceasului trebuie să fie suficientă pentru acuratețea dorită a sincronizării și pentru a măsura jitterul pachetelor la sosire. Frecvența ceasului este dependentă de formatul informației transportate și este specificat în mod static în documentele ce definesc profilele și corespondența 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 eșantionare, nu valoarea ceasului sistemului. Ca exemplu, pentru flux audio cu rată fixă, ceasul folosit va fi incrementat cu unu pentru fiecare perioadă de eșantionare. Dacă o aplicație audio citește blocuri acoperind 160 de perioade de eșantionare de la dispozitivulde înregistrare, valoarea informației de timp va fi mărită cu 160 pentru fiecare astfel de blocuri, indiferent dacă vor fi transmise sau elimitate din cauză că reprezintă perioade de liniște. Valoarea inițială a informației de timp este una aleatorie, la fel ca numărul de secvență. Câteva pachete RTP pot avea valori ale informației de timp egale dacă aceste sunt (teoretic) sunt generate în același timp, cum ar fi pachetele ce aparțin aceluiași cadru video. Pachetele consecutive pot fi marcate cu valori nemonotone dacă datele sunt transmise în altă ordine decât cea în care au fost înregistrate și eșantionate, ca în cazul cadrelor video interpolate MPEG (numerele de secvență sunt în continuare monotone).

SSRC (32 de biți). Câpul SSRC identifică sursa după care se face sincronizarea. Acest identificator este ales în mod aleator, cu intenția ca să nu existe doua surse de sincronizare în aceeași sesiune RTP cu același SSRC. Cu toate că probabilitatea ca acest lucru să se întâmple este mică, toate aplicațiile RTP trebuie să fie pregătite 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 apariția confuziilor.

Lista CSRC (între 0 și 15 elemente de 32 de biți fiecare). Acestă listă identifică sursele ce au contribuit la datele ce sunt conținute de pachet. Numărul surselor este dat de câmpul CC. Dacă sunt mai mult de 15 surse, numai 15 pot fi identificate. Identificatorii CSRC sunt inserați 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 câmpului CSRC, permițând astfel indicarea vorbitorului la recepție în mod corect.

Pentru un studiu aprofundat se pot consulta următoarele materiale RFC 1889[4], Rețele 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 către toți participanții unei sesiuni particulare. Pachetele de control sunt distribuite în același mod ca și pachetele de date. Fiecare pachet RTCP include un raport al transmițătorului și/sau un raport al receptorului care prezintă statistici cum ar fi numărul de pachete trimise, numărul de pachete pierdute, jitterul, întârzierea fată de ultimul raport, timpul de emisie al ultimului raport, etc, utile pentru aplicațiilor. RTCP are patru funcții separate:

Funcția principală este de a furniza feedback cu privire la calitatea distribuției de date. Informațiile primite prin această cale putând fi folosite la controlul unei codări adaptive (codec adaptiv). Experimentele folosind multiplexarea IP au arătat că feedback-ul este critic pentru diagnosticul greșelilor în distribuție. Această funcție este realizată prin folosirea a două rapoarte: raportul transmițătorului și raportul receptorului.

RTCP identifică toți participanți unei sesiuni. Acest protocol face acest lucru prin transportul unui identificator de nivel transport al fiecărei 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. Când un participant părăsește conferința este trimis un pachet RTCP BYE.

Pachetele protocolului sunt trimise pentru a îndeplini primele două funcții, de aceea rata cu care sunt trimise pachetele este de asemenea controlată. Acest control al ratei este realizat de RTCP. Numărul de participanți observat este folosit pentru determinarea valorii acestei rate. Cu cât numărul participanților este mai mare cu atât rata cu care se trimite pachete de către fiecare participant este mai mică.

A patra funcție (opțională) este de a transporta minimum de informație de control a sesiunii, pentru, ca exemplu, să se poată face identificarea participanților în interfața grafică.

Toți participanți trebuie să trimită pachete RTCP, fapt ce poate crea probleme pentru conferințele pe bază de multicast de mari dimensiuni deoarece traficul RTCP va creaște liniar cu creșterea numărului de participanți. Acceastă problemă nu există cu fluxurile RTP în conferințele audio ce folosesc suprimarea pauzelor, deoarece oameni nu vorbesc de regulă în același timp.

Deoarece numărul de participanți este cunoscut tuturor ce ascultă rapoartele RTCP, fiecare din aceștia îș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 împărțită de toți participanții. În „standarde” se stipulează că transmițătorilor activi le revine un sfert din această bandă deoarece informațiile conținute în raportele transmițătorilor sunt foarte importante pentru receptori. Cea ce rămâne se împarte între receptori.

Chiar și pentru cele mai mici sesiuni, cea mai mare rată cu care se poate transmite, de câtre un participant, un raport RTCP este unul la fiecare 5 secunde. Rata cu care se transmite este aleatorizată cu un factor de 0,5 până la 1,5 pentru a nu se crea sincronizări nedorite între rapoarte. Valoarea medie a ratei este derivată, de fiecare participant, din mărimea pachetului pe care vrea să-l trimită și din numărul de transmițători și receptori din pavhetele pe care le primește.

Sunt mai multe tipuri de pachete RTCP, unul pentru fiecare tip de informație:

SR: reprezintă raportul transmițătorului și conține informațiile de transmisie și recepție despre transmițătorii activi;

RR: reprezintă raportul receptorului și conține informațiile despre ascultătorii ce nu sunt și transmițători activi;

SDES: reprezintă descrierea sursei și conține numeroși parametrii referitori la sursă, incluzând și CNAME;

BYE: reprezintă raportul trimis atunci când un participant părăsește conferintă;

APP: prezintă funcțiile specifice unei aplicații.

Câteva pachete RTCP pot fi incluse într-un singur pachet al protocolului de transport. Fiecare mesaj RTCP conține destule informații pentru a fi decodat fără probleme dacă mai multe asemenea mesaje sunt încapsulate în același pachet UDP. Acest mod de folosire este folositor pentru a transmite eficient informația, ținând cont de dimensiunile antetului protocolului de transport.

Rapoartele receptorului și ale transmițătorului (figura I.5)

Fiecare SR („sender report”) conține trei secțiuni obligatori. Prima secțiune conține:

5 biți pentru numărul de rapoarte conținute în acest raport;

tipul pachetului, care în cazul SR-ului este 200;

lungimea acestui raport pe 16 biți și numărul de biți introduși ca umplutură pe 32 de biți;

SSRC-ul transmițătorului acestui raport. Acest indentificator se va regăsi și în pachetele RTP ce pleacă de la acesta.

A doua secțiune conține informațiile despre fluxul RTP ce este trimis de acest transmițător:

informația de timp ce conține data la care a fost trimis acest raport. Aceasta poate să fie absolută sau relativă fată de momentul începerii sesiunii.

informația de timp RTP ce reprezintă același lucru ca mai sus dar folosind regulile de la pachetele RTP;

numărul de pachete trimise de acest transmițător de la începutul sesiunii pe 16 biți. Este resetat dacă SSRC-ul este schimbat;

numărul de octeți de date ce au fost trimise de la începutul sesiunii. Aceste este de semenea resetat cănd se schimbă SSRC-ul.

Cea de-a treia secțiune conține un set de fragmente ale raportului de recepție, unul pentru fiecare sursă de care a auzit de când a trimis ultimul SR sau RR. Fiecare are același format. Acestea conțin:

SSRC (indentificatorul sursei): 32 de biți – identificatorul sursei despre care se face raportul;

rata pierderilor: 8 biți – valoarea rotunjită a raportului (pachete primite/pachete pierdute*256);

numărul total al pachetelor pierdute (24 biți) de la începutul recepției. Pachetele întârziate nu sunt numărate ca pierdute iar pachetele duplicate sunt numărate ca primite;

cel mai mare număr de secvență primit, variantă extinsă: (32 biți). Cei mai importanți 16 biți conțin numărul de cicluri ale numărului de secvență iar ultimi 16 biți conțin cel mai mare număr de secvență primit într-un pachet RTP de la sursa indicată în primul câmp;

jitterul: 32 de biți. O estimare a variației a timpului scurs între sosirile pachetelor RTP, măsurată în unități în care se măsoară și informația de timp și exprimată ca un număr întreg fără semn. Jitterul J este definit ca deviația medie a diferenței între distanțele în timp de la receptor față de cele la transmițător pentru o pachete consecutive. Așa cum este arătat în relația de mai jos, definiția este echivalentă cu diferența timpului de propagare relativ pentru cele două pachete; timpul de propagare relativ este diferența între informația de timp înscrisă în pachetul RTP și timpul indicat de ceasul receptorului atunci la momentul sosirii pachetului, măsurate în același unități. Dacă Si reprezintă informația 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 neapărat în secvență), conform formulei: J=J+(|D(i-1,i)|-J)/16. Când se emite un raport, valoarea curentă a lui J este preluată.

informația de timp conținută de ultimul raport al sursei (LSR): 32 de biți. Se folosesc cei 32 de biți din mijlocul informației de timp conținută de ultimul raport primit din partea unei surse (această formă se numește forma compactă).

întârzierea față de momentul când s-a primit ultimul raport SR (DLSR): 32 de biți. Exprimat în forma compactă (mai simplu în multipli de 1/65536s). Împreună cu LSR transmițătorul acestui ultim SR poate folosi această informație pentru a calcula timpul dus-întors.

Rapotul receptorului arată ca raportul transmițătorului, cu diferențele că valoarea câmpului ce indică tipul informației transportate (PT) este egală cu 201 și secțiunea a doua lipsește. 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 câmpul PT egal cu 202 și conține porțiuni unde se enumeră sursele (SC). Fiecare porțiune conține un SSRC sau un CSRC și o listă de informații. Fiecare element din listă este prezentat folosind formatul tip, lungime, valoare.

Următoarele tipuri există dar doar CNAME trebuie să existe:

CNAME(unic în cadrul unei sesiuni) este de forma utilizator@mașină_gazdă, adresa IP sau numele domeniului mașinii gazdă;

NAME, numele obișnuit al sursei;

EMAIL;

PHONE, numărul de telefon;

LOC, locația mașinii sursă.

În figura 6 se prezintă pachetul SDES.

BYE (figura I.7)

Pachetul RTCP BYE indică că unul sau mai multe surse indicate prin porțiuni de enumerare (SC) nu mai sunt active.

Figura I.5 Raportul transmițătorului

APP: pachetul RTCP definit de aplicație (figura I.8)

Acest pachet poate fi folosit pentru a transporta informații ce țin numai de aplicația folosită. Câmpul PT este setat la valoarea 204.

Detalii în plus se pot găsi î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 aplicație pentru controlul livrării datelor cu proprietăti 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 atât 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 mecanismelor de transport bazate pe RTP.

RTSP stabilește și controlează unul sau mai multe fluxuri sincronizate de date continue cum ar fi audio sau video. În mod normal nu transportă el însuși aceste fluxuri, cu toate că interpunerea fluxurilor media cu fluxul de control este posibilă. Cu alte cuvinte, RTSP propune un control la distanță prin rețea al server-elor multimedia.

Setul de fluxuri ce trebuiesc controlate sunt definite de o descriere a prezentării (presentation description). Formatul acestei descrieri se face într-un document ce trebuie să fie specificat la implementarea protocolului.

Nu există noțiunea de conexiune RTSP, dar serverul menține 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 către server pentru a trimite cereri RTSP sau poate folosi un protocol fără conexiune cum ar fi UDP.

Fluxurile controlate de RTSP pot folosi RTP, dar modul de funcționare al protocolului prezentat nu depinde de mecanismul de transport folosit pentru a duce datele în timp real. Protocolul este intenționat asemănător în sintaxă și mod de operare cu HTTP versiunea 1.1 [7]. HTTP adică Hypertext Transfer Protocol este un protocol de nivel aplicație pentru sistemele aflate la distanță și care comunică între ele. Este un protocol generic, fără stări. Acesta a fost folosit de către inițiativa 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 îmbunătățit protocolul prin faptul că a permis mesajelor să aibă un format asemănător cu formatul MIME (Multipurpose Internet Mail Extensions), mesaje ce conțineau informații despre datele transportate și modificatori ai semanticii mesajelor de cerere și răspuns.

Versiunea 1.1 include cerințe mai dure decât versiunea anterioară cu scopul de a furniza implementări sigure a caracteristicilor acestui protocol. HTTP asigură un set de metode și antete ce indică scopul unei cereri. Acesta este construit pe disciplina referințelor furnizate de „Uniform Resource Identifier”(URI), ca locație 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 poștă electronică din Internet definit în documentul „Multipurpose Internet Mail Extensions” (MIME). HTTP este de altfel folosit și ca protocol de comunicație între agentul utilizatorului (aplicația care rulează la cererea utilizatorului), gateway-uri sau proxy-uri și alte sisteme din Internet, incluzând și pe acelea ce suportă protocoalele FTP și SMTP. În acest mod HTTP permite acesul la resursele disponibile de la diverse aplicații.

HTTP este un protocol de tip cerere răspuns. Un client trimite o cerere către server, ce conține metoda cerută, un câmp URI, o versiune de protocol urmat de un mesaj de format asemănător cu MIME ce are în componență modificatori de sintaxă a cereri, informații despre client, și posibil conținutul mesajului pe o conexiune cu serverul. Acesta răspunde cu o linie de stare, ce include versiunea protocolului și un cod de succes sau de erore urmat de un mesaj asemănător MIME ce conține informațiile despre server, informațiile despre entitatea indicată în cerere și posibil corpul entității.

Protocolul RTSP se diferențiază de HTTP/1.1 prin următoarele aspecte:

introduce un număr de noi metode și are un identificator de protocol diferit;

un server RTSP trebuie să mențină o stare în toate cazurile, spre deosebire de natura fără stări a HTTP-ului.

și clientul și serverul pot emite cereri.

datele sunt transportate de către un alt protocol.

setul de caractere folosite în compunerea mesajelor este altul.

identificatorul resursei URI este în cadrul unei cereri întotdeauna absolut.

Aceste modificări duc la implementarea mai ușoară a unor situații în care există mai multe ierarhii de directoare pe o singură gazdă cu o singură adresă IP.

Protocolul permite următoarele operații:

– obținerea de informații de la un server. Clientul poate cere o descriere a prezentărilor prin HTTP sau altă metodă. Dacă prezentarea este trimisă în mod multicast atunci descrierea conține 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 destinația din motive de securitate.

– invitarea unui server media la o conferință. Un server media poate fi invitat la o conferință, fie pentru a reda fișiere multimedia, fie pentru a înregistra toată sau o parte din conferință. Acestă operație este foarte utilă pentru aplicațiile de învățământ la distanță.

– informarea utilizatorilor despre tipurile de date în timp real disponibile pentru o prezentare existentă deja. În special pentru prezentările în timp real, este util să se informeze pe cei care participă de către server ce tipuri de date în timp real au devenit disponibile.

Sunt necesare câteva precizări:

Prezentarea. Reprezintă unul sau mai multe fluxuri prezentate de către server clienților ca o transmisiune multimedia completă, folosind descrierea prezentării care este definită mai jos. În cele mai multe cazuri în contextul RTSP, aceasta implică controlul asupra acelor fluxuri, dar nu întotdeauna este așa.

Descrierea prezentării. O descriere a unei prezentări conține informații asupra unuia sau mai multe fluxuri media din cadrul prezentării, cum ar fi setul de codecuri folosit, adresele folosite și informații despre conținut. În alte protocoale propuse de IETF ca SDP (Session Description Protocol) folosesc termenul de sesiune pentru o prezentare în timp real. Descrierea prezentării poate avea mai multe formate, incluzând 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”. Când se folosește RTP, un flux conține toate pachetele RTP și RTCP create de o sursă într-o sesiune RTP.

Mesaj. Este unitatea de bază în comunicația RTSP.

Entitate. Reprezintă informația transferată în cadrul unui răspuns sau cereri.

Sesiunea RTSP. Reprezintă o tranzacție completă RTSP, cum ar fi vizionarea unui film. O sesiune constă de obicei în crearea de către client a unui mecanism de transport pentru fluxul media, pornirea redării și închiderea fluxului.

Protocolul RTSP are următoarele proprietăți:

Extensibil. Metode și parametri noi pot fi foarte ușor adăugați la acest protocol;

Ușor de analizat. RTSP poate analizat de către analizoarele standard HTTP sau MIME;

Sigur. RTSP reutilizează mecanismele rețelei de securitate. Toate mecanismele de autentificare folosite în HTTP sunt direct aplicabile. Se pot folosi și mecanismele de securitate ale nivelurilor transport și rețea;

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 stabilește mai multe sesiuni de control concurente cu severele ce conțin fișierele media. Sincronizarea se face la nivelul transport;

Controlează aparatele ce fac înregistrarea. Protocolul poate controla atât aparatele ce fac înregistrarea sau redarea fișierelor media cât și a aparatelor ce fac aceste funcți în mod alternativ;

Separă controlul fluxului de inițializarea conferinței. Controlul fluxului este separat de invitarea la conferință a server-elor. Singura cerință în acest caz este ca protocolul ce inițiază conferintă să furnizeze sau utilizat pentru a crea un identificator pentru conferință. În particular SIP sau H.323 pot fi utilizați pentru invitarea unui server la o conferință. Prin server se înțelege orice sistem ce dorește sau este solicitat să trimită date în timp real.

Potrivit pentru aplicațiile profesionale. RTSP furnizează o acuratețe mare, la nivelul cadrelor ce permite editarea la distanță;

Neutru din punct de vedere al descrierii prezentării. Protocolul nu impune un format de descriere și poate comunica tipul descrierii ce va fi folosit. Totuși, descrierea trebuie să aibă cel puțin un identificator al resursei adică un URI;

Permite folosirea sistemelor firewall și proxy. Protocolul poate fi manevrat cu ușurință atât de sistemele firewall la nivel aplicație cât și de cele la nivel transport. Un astfel de sistem trebuie să înțeleagă metoda SETUP pentru a deschide un canal de comunicație pentru fluxul media de pe UDP;

Folosește 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 încât 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 capacităților. 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 clienților să afișeze interfața grafică corespunzătoare. De exemplu, dacă sărirea unor porțiuni din film nu este permisă, atunci interfața grafică trebuie să fie în stare să împiedice mișcarea indicatorului de poziție în timp al filmului.

Fiecare prezentare și flux media poate fi identificată de un URL. Prezentarea în sine și proprietățile fluxurilor din care aceasta este formată sunt definite de un document ce conține descrierea prezentării. Acest document poate fi obținut de către client folosind HTTP sau alte mijloace cum ar fi poșta electronică și nu este obligatorul să fie stocat pe serverul media. În general aceast document trebuie să conțină descrierea mediilor ce formează prezentarea, incluzând și codecurile folosite, limbajul și alți parametri care permit clientului să aleagă cea mai potrivită combinație. În acestă descriere a prezentării 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 împărțite pe mai multe server-e pentru ca încărcarea acestora să fie echitabilă. Descrierea enumeră și ce metode de transport poate folosi un server.

Pe lângă parametri mediilor folosite, adresa de rețea destinație și portul trebuiesc determinați. Câteva moduri de operare pot fi distinse:

Unicast: datele audio sau video sunt transmise spre locul de unde a fost trimisă cererea RTSP, cu numărul portului ales de client. Este posibil ca datele să fie transmise pe același flux sigur ca RSTP.

Multicast cu alegerea adresei de către 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 către client: dacă server-ul trebuie să participe la o conferință deja existentă, adresa de multicast, portul și modalitatea de codare sunt precizate de descrierea conferinței.

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 recepționată de către server. Totuși, pe timpul vieții unei conexiuni, un singur flux media poate fi controlat prin cereri RTSP trimise în mod secvențial pe diferite conexiuni TCP. De aceea, server-ul trebuie să mențină o stare a sesiunii pentru a fi capabil să coreleze cererile cu un flux. Multe metode din cadrul RTSP nu contribuie la modificarea stării. Totuși următoarele joacă un rol central în definirea alocării și utilizării 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 oprește temporar un flux fără 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 conțin câmpul antet sesiune pentru a indica starea cărei sesiuni o manipulează. Serverul generează un identificator al sesiunii în răspuns la o cerere de tip SETUP.

Server-ul, după ce primește cererile cu metodele de mai sus, răspunde cu un mesaj ce conține în principal o linie de stare formată din versiunea protocolului, un cod de trei cifre ce indică clientului succesul sau insuccesul acțiunii cerute prin metoda trimisă și o frază textuală ce indică în cuvinte ce înseamnă codul. Prima cifră din cod definește clasa răspunsului. Ultimele două cifre nu au nici un rol în ierarhia raspunsurilor. Există 5 valori posibile pentru prima cifră:

1xx: răspuns informațional – răspuns primit, procesul continuă;

2xx: succes – acțiunea a fost primită cu succes, înțeleasă și acceptată;

3xx: îndrumare către alte adrese – trebuiesc luate acțiuni în plus pentru a completa cererea;

4xx: eroare de client – cererea conține 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 răspunsului pentru a fi citite și înțelese de către automate iar frazele ce le urmează sunt destinate utilizatorilor umani.

Pentru informații în plus recomand RFC 2326 [5]

3 Semnalizarea

3.1 Introducere

Semnalizarea reprezită procesul ce permite inițializarea și controlul unei conversații î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 conferințe multimedia, telefonie, învățământ la distanță și alte astfel de aplicații. Protocoalele de semnalizare peste IP sunt folosite să interconecteze clienți software și hardware prin rețele locale (LAN) sau prin Internet.

Principalele funcții ale acestui tip de protocoale sunt: căutarea unui utilizator, translația de adrese și nume, stabilirea unei conexiuni, negocierea parametrilor unui apel, schimbul parametrilor specifici aparatelor folosite în conversație, întreruperea unui apel și managementul participanților la o conversație cum ar fi invitarea de noi participanți. Alte servicii, cum ar fi securitatea, tarifarea, anunțarea sesiunilor pot fi incluse în aceste protocoale. Semnalizarea este foarte strâns legată de transmisia fluxurilor de date, dar aceasta nu face parte din semnalizare.

Astăzi două protocoale de semnalizare există pe piață: H.323 și SIP. Aceste două protocoale reprezintă două abordări diferite asupra aceleiași probleme: semnalizarea și controlul conferințelor multimedia.

H.323 este un standard „umbrelă” de la „International Telecomunications Union” (ITU) pentru comunicații multimedia peste rețele locale (LAN-uri) care nu furnizează nici un fel de garanție privind calitatea serviciilor. H.323 face parte din o serie mai mare de standarde pentru comunicații numită seria H.32x, ce conține standarde pentru conferințe multimedia peste tipuri diferite de rețele, incluzând ISDN și PSTN. Specificația 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 conferințele peste rețelele de mari dimensiuni de tipul WAN („Wide Area Networks”) și a fost aprobat în 1998. Această versiune a adăugat și specificații pentru comunicația între rețelele de pachete și cele de circuite. Versiunea 3 a fost aprobată în anul 2000 și conține specificații pentru transmisia fax-urilor peste rețelele de pachete, pentru comunicația între managerii de apeluri și pentru mecanisme mai rapide pentru stabilirea conexiunii telefonice. În curând va apare și versiunea 4. H.323 reprezintă o abordare tradițională folosind tehnicile telefoniei prin rețelele 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 puțin cunoscut decât H.323 și de aceea va fi dezbătut pe larg în următoarele pagini. SIP este un protocol mai simplu și se bazează pe protocolul HTTP. El a fost proiectat inițial pentru conferințele multimedia ce folosesc Internetul.

3.2 SIP sau Protocolul de Inițiere 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 gândit pentru a se asigura un mod avansat de control al începerii, terminării si administrării modului în care se transmit datele într-o rețea. 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 rețea si, indiferent de localizarea fizica a acestora, se pot iniția 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 Inițializare al Sesiunii inițializează, administrează si termină o sesiune de comunicație într-o rețea.

Protocolul a fost proiectat pentru facilitarea oferirii serviciilor vocale pe rețele de date. Aplicațiile 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 legături pentru comunicatie, SIP este un protocol de control care ofera servicii similare cu cele oferite de protocoalele de control existente în cazul aplicațiilor de telefonie clasică, însă realizeaza acestui lucru într-un context strâns legat de Internet.

Session Initiation Protocol face parte din arhitectura promovată de câțiva 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 anunțarea sesiunilor de comunicare de la un singur emitator la mai multi receptori, Telephony Routing over IP (TRIP) – pentru localizarea celei mai bune căi de transmisie între Internet si rețeaua de telefonie publică.

În principal SIP este destinat pentru asigurarea sesiunilor de comunicație intre utilizatori identificați prin identificatori de tip e-mail sau număr de telefon. Orice echipament care are asignat un nume de gazdă într-o rețea poate lua parte la o sesiune SIP. Procesul de creare a unei legaturi SIP începe cu descoperirea unui utilizator indiferent de localizarea acestuia în rețea, pentru ca descrierea sesiunii sa poata fi trimisă utilizatorului.

O caracteristică foarte importantă este dată de faptul că utilizatorul va menține același identificator, chiar daca se va schimba locația fizică sau dispozitivul cu care acesta se conecteaza la rețea. Atribuirea acestui identificator unui utilizator va fi realizată de catre furnizorul serviciului de conectare în rețea sau compania telefonică. In plus, identitatea unui singur utilizator poate fi reprezentată simultan de un număr de terminale conectate la rețea. În funcție de elementele logice prezente in elementele de rețea SIP, se pot trimite cereri de realizare a comunicației catre oricare dintre terminalele care recunosc acelasi identificator (unul, mai multe sau chiar toate).

Inițierea sesiunii depinde si de abilitatea parții apelate de a determina cantitatea de informatii necesare despre sesiunea în sine, astfel incât aceasta sa poată decide în ceea ce priveste participarea sau nu la comunicația care ar urma sa aibă loc. Ca urmare, un mesaj SIP include informatii despre apelant, motivul pentru care se dorește deschiderea unei sesiuni, cât de urgentă este realizarea legăturii si informații despre parametrii sesiunii de comunicare.

3.2.2 SDP

SIP folosește protocolul de descriere al sesiunii (SDP) specificat în RFC-ul 2327 din aprilie 1998, elaborat de către grupul de lucru MMUSIC. Pentru ca un receptor să poată să fie în stare să recepționeze o sesiune SIP, acesta trebuie să cunoască:

care adresă de multicast va fi folosită de către sesiune;

care va fi portul de destinație UDP;

codecurile video sau/și audio care vor fi folosite;

câteva informații despre sesiune (numele, scurtă descreiere);

informații de contact;

orarul de activitate.

Principalul scop al descrierii sesiunii de tip SDP este să definească o sintaxă standard pentru aceast tip de informație. Aceste informații pot fi livrate folosind o varietate de metode de transport, depinzând de context:

protocolul pentru anunțarea sesiunilor (SAP) pentru rețelele multicast;

protocolul pentru fluxurile de date în timp real (RTSP) pentru aplicațiile ce lucrează cu fluxuri;

SIP pentru inițializarea comunicațiilor punct la punct sau multipunct.

O descripție a unei sesiuni exprimată în format SDP este scurtă prezentare textuală a numelui și scopului unei sesiuni și informații despre mediul, protocoalele, codecurile și modul de transport ce sunt necesare pentru a decide dacă o sesiune este de interes și pentru a cunoaște ce aplicații 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 informații pentru ca un receptor să fie capabil să ia parte la o sesiune și să anunțe resursele ce vor fi folosite, elementelor de rețea ce nu participă la sesiune dar care doresc să cunoască aceste informații.

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 când se vor repeta. Aceste informații sunt sunt adevărate în întreaga rețea. Se pot de asemenea specifica modificatori de timp.

Descrierea unei sesiuni se compune din informații generale care se aplică întregii sesiuni urmate de secțiuni ce sunt specifice fiecărui format al datelor în timp real transmise. Fiecare secțiune conține 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 destinație și porturile de destinație ale fluxului multicast, indiferent dacă este trimis, recepționat 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 răspunsul la invitație ar putea conține informații similare privind locul unde apelantul să trimită fluxurile audio și video.

Sintaxa SDP: O descriere a unei sesiuni constă într-un număr 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 cărui format depinde de <tip>. În general <valoare> este ori un număr de câmpuri delimitate de un singur caracter spațiu sau un sir de caractere cu un format oarecare.

O descriere de sesiune conține o descriere la nivelul întregii sesiuni (care se aplică întregii sesiuni și tuturor fluxurilor media) și opțional mai multe descrieri la nivelul fluxurilor ce conține 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 următoarea descriere de flux sau cu sfâșitul întregii descrieri. În general, valorile conținute în descrierea de nivel sesiune sunt valabile pentru toate fluxurile cu excepția 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=[anonimizat]

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

Câmpurile individuale au următoarele sensuri și trebuie să fie în această ordine cu caracterul ’*’ indicând un câmp opțional:

v= versiunea protocolului

o= creatorul și identificatorul sesiunii

s= numele sesiunii

i=* informații despre sesiune

u=* link-ul (URI) descrierii

e=* adresă de e-mail

p=* număr de telefon

c=* informații despre modul de conectare

b=* informații despre bandă

una sau mai multe informații 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 informație de timp este formată dintr-un câmp ce incepe cu caracterul ’t’ urmat de încă câmp opțional ’r’.

t= momentul de timp când sesiunea este activă

r=* zero sau mai multe mmente de timp când se repetă sesiunea

Fiecare descriere de flux exte formată din câmpul ce are la începutul liniei caracterul ’m’ și din alte câmpuri opționale ce furnizează informații în plus:

m= numele fluxului și adresa de transport

i=* titlul fluxului

c=* informații despre modul de conectare

b=* informații despre bandă

k=* cheie de codare

a=* zero sau mai multe atribute ale fluxului

Câmpurile ’c’și ’a’ din descrierea de nivel sesiune se aplică tuturor fluxurilor cu excepția cazului în care sunt rescrise de câmpurile cu același nume din descrierile fluxurilor.

3.2.3 SAP (RFC 2974)

Acest protocol este folosit pentru a face cunoscute unui public larg, conferințele multicast și alte tipuri de sesiuni multicast. Un emițător SAP trimite în mod multicast în mod periodic pachete de informare, folosind adrese de multicast și porturi cunoscute. Un ascultător SAP află de utilizatorii vizați de transmisia multicast folosind protocolul „Multicast Scope Zone Announcement Protocol”.

Emițătorul SAP nu este conștient de prezența sau absența ascultătorilor SAP. Un anunț SAP este trimis vizând aceiași utilizatori ca și sesiunea pe care o anunță, asigurând că receptorii anunțului pot fi receptori posibili ai sesiunii anunțate.

Dacă o sesiune folosește adrese în mai multe zone administrative, este necesar ce emițătorul SAP să trimită copii identice al anunțului pentru fiecare zonă administrativă. Emițătorii SAP multiplii pot anunța aceiași sesiune, fapt ce ajută la robustețea protocolului în fața pierderii de pachete sau defectării emitătoarelor SAP. Durata de timp ce există între două anunțări a aceleiași sesiuni este aleasă astfel încât banda totală folosită de toate anunțurile unui singur grup SAP să rămână limită preconfigurată. Fiecare emițător SAP ar trebui să asculte celelalte anunțuri pentru a determina numărul total de sesiuni anunțate pentru un grup particular.

SAP conține mecanisme pentru a asigura integritatea anunțurilor de sesiuni, pentru a autentificarea originii unui anunț și pentru codarea anunțului.

Formatul pachetului SAP pentru versiunea 4 a protocolului IP este prezentată în figura 9. Câmpul 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 informația din acest pachet este comprimată. Combinația informațiilor din câmpurile identificatorul mesajului și sursa anunțului ar trebui sa furnizeze un identificator unic al anunțului care poate fi folosit pentru a identifica o versiune particulară a unei sesiuni. Acest lucru este binevenit în cazul în care se memorează anunțurile sau pentru a ignora pachetele care nu au putut fi decriptate. Deoarece acest identificator nu este garantat a fi unic, trebuiesc folosite alte metode adiționale cum ar fi verificarea lungimi pachetelor și chiar verificarea în mod periodic a conținutului pachetelor.

Anunțurile SAP pot fi autentificate folosind o semnătură digitală a informației transportate de pachet, folosind câmpul de autentificare opțional.

De asemenea acestea pot fi și codate. Totuși, acest lucru nu înseamnă că modul standard de a iniția o conferință privată într-o rețea de mari dimensiuni este prin anunțarea ei cu ajutorul pachetelor SAP codate – pentru acest scop protocolul SIP este mai util. Principala utilizare a anunțurilor SAP ar trebui să fie în rețelele de tip intranet unde pot deranja puțin utilizatori sau pentru a sesiunile foarte mari unde utilizatori sunt facturați pentru aprticiparea la conferință. Deoarece este ușor pentru un utilizator de rea credință să răspândească o cheie SAP este necesar luarea de măsuri suplimentare pentru accesul participanților la conferință.

SAP trebuie folosit pentru sesiuni de interes public unde participanți nu sunt cunoscuți în prealabil. Dacă se cunosc inviatații un mecanism mai bun este invitarea lor explicită folosind SIP.

Detalii se poat obține consultând RFC 2974 [8]

Figura I.9 Pachetul SAP

3.2.4 Entitățile SIP și definiții

SIP reprezintă satndardul IETF pentru stabilirea conexiunilor VoIP. Protocolul de Inițializare a Sesiunilor este un protocol de control la nivel aplicație (de semnalizare) pentru crearea, modificarea și închiderea sesiunilor cu unul sau mai mulți aprticipanți. Aceste sesiuni includ conferințe multimedia prin Internet, apeluri telefonice prin Internet și distribuții multimedia. Participanții într-o sesiune pot comunica prin multicast, printr-o rețea de canale unicast sau printr-o combinația a acestor două moduri.

Arhitectura SIP este similară cu aceea a protocolului HTTP. Cererile sunt generate de către client și trimise serverului. Aceste procesează cererile și trimite un răspuns clientului. O cerere și răspunsul corespunzător formează o tranzacție. 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 puține presupuneri cu privire la protocolul de transport. El însuși asigură siguranța 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 Inițializare a Sesiunilor folosește descrieri de sesiuni pentru a permite participanților punerea de acord asupra unor tipuri de media compatibile. Acest protocol sprijină mobilitatea utilizatorului prin existența funcțiilor de tip proxy și de îndrumare a răspunsurilor spre locația curentă a utilizatorului. SIP asigură următoarele faze din stabilirea și închiderea unei comunicații (RFC 3261):

Găsirea utilizatorului: determinarea terminalului care va fi folosit pentru comunicație;

Determinarea stării utilizatorului: protocolul poate determina dacă un utilizator este disponibil să răpundă la un apel sau nu;

Determinarea capacităților de comunicare: poate afla care sunt tipurile de media și proprietățile acestora, ce pot fi folosite în timpul comunicației.

Stabilirea sesiunii: anunțarea parților participante și stabilirea parametrilor la ambele capete ale sesiunii;

Managementul sesiunii: include transferul și închiderea sesiunii, modificarea parametrilor și invocarea de servicii.

Așa cum am mai spus SIP nu este un sistem de comunicație 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 privința calității 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 rețelelor de pachete și fac legătura cu rețelele cu comutație de circuite și SDP (RFC 2327) pentru descrierea sesiunilor multimedia. De aceea, SIP trebuie folosit în conjuncție cu alte protocoale pentru a furniza servicii complete utilizatorilor. Totuși, funcționarea protocolului nu depinde de nici-un protocol.

SIP nu furnizează servicii. În schimb, SIP folosește primitive care pot fi folosite pentru a implementa diferite servicii. De exemplu SIP poate localiza un utilizator și trimite la acea locație câteva 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ă aceeași primitivă este folosită pentru a trimite o fotografie a apelantului în același mod ca descrierea sesiunii, atunci un serviciu de identificare a apelantului poate fi ușor de implementat. Cum a arătat acest exemplu, o singură primitivă este folosită pentru a furniza diferite servicii.

SIP nu oferă servicii de control a conferințelor 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 iniția o sesiune care folosește un alt protocol de control al conferințelor. Deoarece mesajele SIP și sesiunile stabilite cu acestea nu pot trece prin rețele complet diferite, SIP nu poate și nu oferă nici o modaliate prin care să se asigure rezervare de resurse.

Din cauza naturi informațiilor transmise siguranța 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, protecția integrității și codarea.

Înainte de a prezenta entitățile și modul de operare al protocolului este necesar precizarea unor noțiuni:

Client: un program aplicație care trimite cereri SIP. Clienții pot sau nu pot interacționa cu un utilizator uman.

Server: Un server este un program aplicație care acceptă cereri pentru ale prelucra și trimite înapoi răspunsuri la aceste cereri.

Apel: un apel constă din toți participanții dintr-o conferință invitați de o sursă comună. Un apel SIP este identificat de către un identificator unic. Astfel, dacă un utilizator este invitat la acceași sesiune multicast de către persoane diferite, fiecare din aceste invitații este un apel unic. O conversație telefonică prin Internet punct la punct reprezintă un singur apel SIP.

Conexiune: o conexiune ce servește o conversație este identificată printr-o combinație de câmpuri: identificatorul apelului, adresele participanților și valorile câmpurilor „From”(De la) și „To”(Spre). Având aceeași identificator al apelului, cererile ce au câmpurile cu valorile „Spre” A și „De la” B aparțin aceleiași conexiuni ca și cererile ce au câmpurile cu valorile „Spre” B și „De la” A, din direcție opusă.

Sesiune: în specificația SDP o sesiune multimedia reprezintă un set de transmițători și receptori și fluxurile de date ce sunt între aceștia. O conferință multimedia este un exemplu de sesiune. După cum s-a mai spus un apelat poate fi invitat la aceeași sesiune de mai multe ori. Dacă se folosește SDP, o sesiune este definită de concatenarea numelui utilizatorului, identificatorul sesiunii, tipul rețelei, tipul adresei și elementele de adresă din câmpul „Origine” din antet.

Tranzacție SIP: are loc între un client și un server și conține toate mesajele de la prima cerere trimisă de client server-ului până la ultimul răspuns trimis de server către client. O tranzacție este identificată, într-o conexiune, de numărul de secvență „Cseq”.

Componentele arhitecturii SIP sunt:

Agentul utilizatorului: este o aplicație ce conține atât un agent client cât și un agent server. Clientul este agentul ce trimite apelurile iar serverul este cel care le primește.

Server proxy: este un program intermediar ce funcționează atât ca server cât și ca client cu scopul de a face sau retrimite cereri din partea altor clienți.

Server de îndrumare: reprezintă server-ul care acceptă o cerere SIP și asociază unui client mai multe adrese la care poate fi găsit. Spre deosebire de server-ul proxy, acesta nu trimite mesajul mai departe. În schimb, trimite noua adresă găsită clientului cerându-i acestuia să retrimită mesajul acolo.

Server de localizare: este folosit de către un server proxy sau de îndrumare pentru a obține informații despre locațiile posibile ale unui apelant.

Proxy „outbound” : este proxy-ul ce este localizat aproape de originea unei cereri. Primește toate cererile unui agent client, incluzând și acelea care nu îi sunt adresate. Proxy-ul trimite aceste cereri, după procesări locale, la adresele din antete.

Registrator: este un server ce acceptă cererile de înregistrare „REGISTER”. Monitorizează utilizatorii în interiorul domeniului de rețea asignat. Este în mod tipic pus în aceași locație cu un server proxy sau de îndrumare și poate face ca informațiile ce le deține să fie disponibile.

Acestea sunt elemente separate logic și nu sunt implementări fizice distincte. Nu este deloc un fenomen neobișnuit de a găsi servere proxy, de îndrumare și registratori care rulează în cadrul unei singure conversații.

Î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 mulți agenți SIP. Cu toate acestea, nu este exclusă nici realizarea unei comunicații directe (fără intermediari) între agenții SIP. De fapt este un fenomen de comunicație foarte normal acela în care doar prima cerere de comunicație trece prin serverele proxy, după care toate celelalte mesaje vor fi schimbate direct între agenți.

3.2.5 Modul de operare SIP

Apelanții și apelați sunt identificați prin adrese SIP. Când realizează un apel SIP, un apelant trebuie să localizeze mai întâi server-ul corespunzător și să-i trimită o cerere. Pentru a fi invitată și identificată partea apelată trebuie să aibă un nume.

SIP folosește un identificator de tip e-mail de forma utilizator@domeniu, utilizator@gazdă, utilizator@adresă IP sau număr de telefon@ „gateway” din cauză că acest mod de adresare este cel mai răspândit î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 către un server SIP. Apelantul poate afla unde să trimită cererea folosind serverele DNS. Prin realizarea unei serii de interogări DNS (Domain Name Server) de către cel ce vrea să inițieze 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 ușor transformate în informații de tip URI (Uniform Resource Identifiers) cum ar fi sip: teodor@constantin . Avantajul acestui fapt este că aceste informații pot fi ușor introduse în pagini Web, astfel încât plin apăsarea cu mouse-ul pe link-ul corespunzător inițiază un apel către acea adresă, într-un mod asemănător cu link-urile pentru trimiterea unui e-mail de genul „mail to : URL”.

Un server de rețea SIP poate trimite apelul către alte servere, ajungând într-un final la unul care știe sigur adresa IP unde utilizatorul poate fi găsit. Procesul de determinare a următorului hop se numește rutare „next hop”. Ca un rezultat al deciziilor luate în urma rutării, un server de rețea SIP poate ajunge la concluzia că la un utilizator se poate ajunge prin mai multe servere adiacente. În aceste cazuri, SIP permite unui server proxy să creeze mai multe copii dintr-o cerere recepționată și să o trimită pe mai multe căi paralele spre serverele adiacente. În condiții normale, fiecare server va genera un răspuns; SIP are reguli definite pentru concatenarea răspunsurilor și trimiterea acestora la agentul client.

Odată ce localizarea server-ului s-a încheiat, clientul poate trimite cereri către acesta. O cerere împreună cu răspunsul corespunzător formează o tranzacție SIP. Cererea poate fi trimisă prin canale TCP sigure sau prin UDP. Dacă se folosește un protocol sigur, cererea și răspunsurile dintr-o singură tranzacție SIP sunt transportate pe aceeași conexiune.

Mai multe cereri SIP de la același client către același server pot fi transmise pe aceeași conexiune sau se poate folosi câte 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 recepționează trimite răspunsul conform informației conținută în câmpul „Via” din antetul cereri. Fiecare server proxy de pe calea urmată de cerere trimite răspunsul folosind același câmp „Via”. Pentru protocoalele de datagrame, siguranța transmisiei se obține prin retransmisii.

O invitație 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 conversație. După ce apelatul a acceptat să participe, apelantul confirmă că a primit răspunsul prin trimiterea unei cereri ACK. Cererea INVITE conține o descriere a sesiunii care îi furnizează apelatului destule informații pentru a se intra în sesiune. Dacă apelatul dorește să accepte apelul, răspunde invitației prin trimiterea unui răspuns cu o descriere similară a sesiunii. După ce apelatul a acceptat să participe, apelantul confirmă că a primit răspunsul prin trimiterea unei cereri ACK.

Un apelat poate să și schimbe poziția în timp. Aceste locații pot fi în mod dinamic înregistrate la un server SIP. Când un server SIP este interogat despre poziția apelatului, acesta întoarce o listă cu posibilele locații. De fapt un server de localizare din siestemul SIP generează lista și o pasează serverului SIP.

Ar putea exista situația în care suntem nevoiți să schimbăm parametrii unei sesiuni existente. Aceasta se poate realiza prin retrimiterea cererii INVITE folosind același identificator de apel (câmpul „Call ID” același) dar cu un nou corp al mesajului. Cererea trebuie să aibă un număr de secvență „Cseq” mai mare decât cel avut de ultima cerere a clientului către server.

3.2.6 Proprietățile protocolului SIP

Este un protocol cu stări de durată mică. O sesiune în care avem o conferință sau un apel constă una sau mai multe tranzacții cerere-răspuns SIP. Fiecare dintre acestea pot parcurge rute diferite prin server-ele din rețea. Într-un apel obișnuit, cererea este de tipul INVITE și poate parcurge mai multe server-e de rețea în drumul ei până la apelat. Răspunsul la această cerere conține o adresă amănunțită care poate fi folosită de agentul client pentru a trimite cererile următoare direct către agentul server.

Deoarece server-ele de rețea SIP nu trebuie să mențină starea apelului și după ce o tranzacție s-a încheiat, acestea nu dețin informații despre apelant sau apelat. Această caracteristică facilitează scalabilitatea și siguranță unui server SIP, deoarece se poate bloca fără ca să afecteze tranzacțiile inițiate prin el. Durata și numărul stărilor menținute într-un server sunt mici în comparație cu acelea din rețeaua de telefonie clasică, unde o centrală trebuie să mențină starea unui apel pentru întreagă durată a acestuia. Totuși un server ce dorește să cunoască starea unui apel poate menține starea unui apel pe întrega durata a acestuia. Prin intermediul câmpurilor „Route”(rută) și „RecordRoute”(rută inregistrată) din antetul mesajelor SIP, fiecare proxy poate ,în mod individual, insista să fie pe calea urmată de tranzacțiile următoare. Mai mult, proxy-ul se poate răzgândi și se poate scoate de pe calea de semnalizare.

Un server de rețea SIP nu trebuie să aibă stări nici chiar pe durată tranzacțiilor. Un server proxy sau de îndrumare poate fi complet fără stări. După ce primește o cerere, acesta ori generează un răspuns ori trimite cererea mai departe și uită tot. Mesajele conțin toate informațiile necesare pentru ca un server proxy să le proceseze și să la ruteze. Aceast mod de funcționare corespunde arhitecturii bazate pe datagrame din Internet, unde pachetele conțin informații suficiente pentru a fi rutate în mod individual. În plus, un proxy cu stări poate deveni fără stări în orice moment fără a afecta modul de funcționare al protocolului. Administratorul decide în privința fiecărui apel dacă un proxy va fi cu stări sau fără. Această flexibilitate permite existența unor servere de mari dimensiuni poziționate central în rețea care sunt fără stari. Pemite și existența unor servere mai mici cu stări poziționate spre periferia rețelei.

Protocolul este neutru din punctul de vedere al protocoalelor de nivele inferioare. SIP face presupuneri minime asupra protocolalelor de transport și de nivel rețea. Nivelele inferioare pot furniza servicii ce se bazează pe pachete sau fluxuri de octeți și pot fi sau nu sigure. În contextul Internetului, SIP poate utiliza și UDP și TCP ca protocoale de transport. UDP permite aplicației să controleze mai ușor momentul trimiteri mesajelor și retransmisia acestora, să realizeze căutări paralele și să folosească transmisie în mod multicast. Ruterele pot lucra mai repede cu pachete SIP UDP. TCP permite trecerea cu ușurință prin componentele de tip „firewall” existente. Când este folosit TCP, SIP poate folosi una sau mai multe conexiuni pentru a încerca să contacteze un utilizator sau să modifice parametri unei conferințe deja existente. Cereri diferite SIP pentru același 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 Relay sau X.25. Agenții 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 folosește ca formă de codare UTF-8. Acest fapt permite o implementare ușoară în limbaje cum ar fi Java, Tcl sau Perl, permite găsirea și corectarea greșilor de programare cu ușurință și cel mai important face ca SIP să fie un protocol flexibil și extensibil. Cum SIP este folosit în principal pentru inițierea conferințelor multimedia decât 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

Așa cum am mai spus mai devreme SIP este un protocol bazat pe text. Sintaxa mesajelor și câmpurile din antet sunt identice cu specificația HHTP/1.1. Un mesaj SIP este sau o cerere sau un răspuns. O cerere este generată de un client și un răspuns este generată de un server. Mesajele cerere și răspuns 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 opțional 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 câmpurile:

linie de cerere : metoda SP identificatorul de tip URI al sursei SP Versiunea SIP CRLF

cu următoarele semnificații:

Câmpul metoda poate următoarele valori: „INVITE” | „ACK” | „OPTIONS” | „BYE” | „CANCEL” | „REGISTER” | metodă extinsă

Câmpul versiunea SIP : „SIP/2.0”

Câmpul SP: „ ” (spațiu liber)

Mesajele SIP folosește câmpurile antetului pentru a specifica diferite informații despre participanți, calea de urmat și altele. Aceste câmpuri sunt asemănătoare cu cele de la HTTP în sintaxă și semantică. Ordinea în care apar nu are în general nici-o importanță, cu excepția câmpurilor ce sunt introduse între server-e. Unele câmpuri din antet sunt folosite în toate mesajele și altele doar când sunt necesare. O aplicație ce implementează SIP nu trebuie să înțeleagă toate câpurile, dar ar fi de dorit să o poate face. Dacă un participant SIP nu înțelege un antet îl poate ignora. Numărul total de câmpuri în antetul SIP este 44 și pot fi împărțite în patru grupuri:

Câmpurile antetului general ce există și în cereri și în răspunsuri.

Câmpurile antetului corp mesaj ce definesc informația despre corpul mesajului sau dacă acesta nu este prezent atunci despre resursa identificată de cerere.

Câmpurile antetului cerere ce permit clientului să trimită informații în plus despre cerere și despre el însuși, server-ului.

Câmpurile antetului răspuns ce conțin informațiile despre server și despre accesul la resursa identificată de URI din cerere.

În cadrul antetului general se află următoarele câmpuri mai importante:

Call-ID (identificatorul apelului; de exemplu CallID:[anonimizat]) este folosit în multe scopuri. În cadrul cererilor de înregistrare și de obținere a parametrilor unui server este folosit pentru a recunoaște răspunsurile corespunzătoare cererilor. Pentru cererile de invitare și de înregistrare este folosit și pentru a detecta copiile acestor cereri.Cererile INVITE succesive cu același CallID dar cu parametrii diferiți 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ă rețeaua. 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 număr de secvență fără semn și numele metodei. Într-un apel, numărul de secvență este incrementat cu fiecare nouă cerere (cu excepția situației în care cererea este retransmisia unei alte cereri) și are la început o valoare aleatoare. Server-ul trebuie să copieze valoarea acestui câmp în toate răspunsurile ce sunt determinate de cererea ce îl conține.

From (de exemplu From: teo<sip:[anonimizat]>). Acest câmp trebuie să fie prezent în toate cererile și răspunsurile. Conține numele utilizatorului ce poate fi afișat în interfața grafică (parte ce poate să lipsească) și adresa de unde a plecat cererea. Informații în plus pot fi adăugate. Trebuie spus că acest câmp este copiat în răspunsuri și astfel câmpul From din râspuns nu-l indică pe cel ce la trimis.

To (de exemplu To: mihai<sip:[anonimizat]>; tag=287747). Acest câmp trebuie să fie prezent și în cereri și în răspunsuri și indică destinația dorită a cereri. Este copiat în răspuns. Valoarea câmpului „tag” identifică destinația în cazul în care un identificator URI SIP se indică mai multe terminale posibile. În cazul acestei situații în răspunsuri se introduce acest câmp „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). Câmpul Via este folosit pentru a înregistra ruta urmată de către o cerere, pentru a permite server-elor SIP intermediare să trimită răspunsurile pe aceeași rută. Pentru a realiza acest lucru fiecare server proxy adaugă în antet un nou câmp Via la cele existente. Receptorul unei cereri poate adăuga parametri opționali, de exeplu pentru a indica că a primit o cerere de la o adresă care nu se află în ultimul câmp Via. Folosind această informație un server proxy poate trimite răspunsul către transmițătorul original, chiar dacă pe ruta dintre ei se află un dispozitiv NAT ce translatează adresele de rețea. Când parametrul „maddr” ce indică existența unei adrese multicast este prezent în câmpul Via, răspunsul este trimis folosind o transmisie multicast la adresa specificată după „maddr” și timpul de viață este stocat în parametrul ttl. Existența acestui câmp arată că SIP a fost proiectat având în vedere problemele IP.

Encryption (de exemplu: Encryption: PGP version=2.6.2,encoding=ascii). Acest câmp indică că corpul mesajului și posibil anumite mesaje din antet sunt codate.

Antetul ce se referă la corpul mesajului conține următoarele câmpuri:

Content-Type (de exemplu Content-Type: application/sdp). Acesta descrie tipul informației 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ă numărul de octeți al corpului mesajului.

Câmpurile ce apar numai în mesajele de cerere sunt conținute în antetul cerere și au următoarea semnificație:

Accept (de exemplu Accept: application/sdp, text/html). Acest câmp opțional indică ce tipuri de informații sunt permise în răspuns. 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 câmp indică pentru cât timp înregistrarea va fi validă. Înregistratorul poate scurta această perioadă în râspunsul său. Pentru un mesaj de invitare, acest cămp poate fi folosit pentru limitarea duratei de căutare.

Priority (de exemplu Priority: emergency). Valorile posibile sunt cele indicate în RFC 2076 plus „emergency”.

Record-Route (folosit de asemenea și în mesajele de răspuns; de exemplu Record-Route: sip:centrală.home.ro;maddr=192.190.123.234;sip:facturare.firma.ro;maddr=192.194.126.23). Unele server-e proxy pot adăuga elemente noi la acest câmp dacă vor să fie pe calea urmată de semnalizări. În exemplul dat cererea a trecut printr-un proxy de facturare și apoi printr-o centrală. Asemenea entități trebuie să monitorizeze starea apelurilor pentru a-și indeplini scopul.

Subject (de exemplu Subject:’Conferință despre SIP’). Acest conține text fără 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 conține o descriere a mesajului.

ACK: cererea ACK confirmă că apelantul a primit un răspuns final la o cerere INVITE, confirmă un răspuns afirmativ.

OPTIONS: această metodă se ocupă cu informațiile privind caracteristicile participanților și află caracteristicile receptorului.

BYE: cererea BYE închide un apel sau termină o cerere de apel, putând fi trimisă și de apelant și de apelat.

CANCEL: cererea CANCEL termină o cerere de apel nerezolvată dar nu afectează apelurile ce sunt în desfășurare.

REGISTER: metoda REGISTER este folosită pentru a înregistra locația curentă a utilizatorului. Această metodă este folosită și atunci când sunt mai multe server-e SIP pe un singur calculator. În acest caz doar un singur server poate folosi portul asociat SIP.

INFO: reprezintă informația din timpul apelării 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 răspuns 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. Câmpul Content-Type trebuie să conțină tipul informației. În eemplele date tipul corpului mesajului este Sessiun Description Protocol.

După ce a primit și a interpretat mesajul, sistemul răspunde cu un mesaj de răspuns SIP. Linia de stare a acestuia este formată din versiunea SIP, codul ce indică răspunsul și o frază de motivare a răspunsului. Această frază este o descriere textuală scurtă a codului. Formatul răspunsului este arătat în continuare:

Răspuns: linie de stare

*(antet general | antet răspuns | antet al corpului mesajului)

CRLF

[corpul mesajului]

Linie de stare= versiunea SIP SP codul SP frază de motivare CRLF

Codul= Informațional | Succes | Îndrumare catre alte adrese| Eroare client | Eroare server | Eroare globală | Cod extins (3 cifre)

Fraza de motivare= text codat UTF-8, fără CR, LF

Codul este un număr întreg format din trei cifre, prima cifră indicând tipul răspunsului:

1XX : Informațional: indică că s-a primit cererea și procearea acesteia continuă. Acesta nu este un răspuns definitiv spre deosebire de restul. Exemplu: 180 RINGING (Sună).

2XX : Succes: răspunsul arată că s-a primit cererea, a fost înțeleasă și acceptată. Exemplu: 200 OK.

3XX :Îndrumare către alte adrese: trebuie să se facă operații în plus pentru ca cererea să fie îndeplinită. Eemplu: 302 MOVED TEMPORARILY (mutat temporar).

4XX : Eroare client: cererea conține greșeli de sintaxă sau nu poate fi îndeplinită la acest server. Exemplu: 404 NOT FOUND (nu s-a găsit destinația dorită).

5XX : Eroare server: serverul nu poate să îndeplinească o cerere ce pare validă. Exemplu: 501 NOT IMPLEMENTED (nu este implementată acțiunea 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 adăugarea de noi coduri foarte ușor. Când un terminal mai vechi primește un răspuns ce are un cod CXX pe care nu-l cunoaște, acesta îl tratează ca fiind C00. Astefel și cele mai vechi terminale pot reacționa inteligent atunci când se confruntă cu coduri necunoscute. Acestea pot da informații adiționale utilizatorului dacă fraza de motivare este prezentă.

3.2.8 Exemple de apeluri SIP

3.2.8.1 Apel propriu-zis

În exemplul următor se va prezenta mesajele schimbate între două terminalele atunci când 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:[anonimizat] SIP/2.0

Via: SIP/2.0/UDP cell.rom-tel.com

From: Teo<sip:[anonimizat]>;tag=3

To: Adi<sip:[anonimizat]>

Call-ID: [anonimizat]

CSeq: 1 INVITE

Contact: <sip:[anonimizat]>

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:[anonimizat]>;tag=3

To: Adi<sip:[anonimizat]> ;tag=37462311

Call-ID: [anonimizat]

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:[anonimizat]>;tag=3

To: Adi<sip:[anonimizat]> ;tag=37462311

Call-ID: [anonimizat]

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:[anonimizat]>;tag=3

To: Adi<sip:[anonimizat]> ;tag=37462311

Call-ID: [anonimizat]

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:[anonimizat]>;tag=3

To: Adi<sip:[anonimizat]> ;tag=37462311

Call-ID: [anonimizat]

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:[anonimizat]>;tag=3

To: Adi <sip:[anonimizat]> ;tag=37462311

Call-ID: [anonimizat]

CSeq: 1 INVITE

Contact: sip:[anonimizat]

Content-Type: application/sdp

Content-Length: …

v=0

o=adi 4858949 4858949 IN IP4 192.1.2.3

s=vin în curând

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:[anonimizat]>;tag=3

To: Adi<sip:[anonimizat]> ;tag=37462311

Call-ID: [anonimizat]

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:[anonimizat]>;tag=3

To: Adi <sip:[anonimizat]> ;tag=37462311

Call-ID: [anonimizat]

CSeq: 2 BYE

S->C: SIP/2.0 OK

Via: SIP/2.0/UDP cell.rom-tel.com

From: Teo<sip:[anonimizat]>;tag=3

To: Adi <sip:[anonimizat]> ;tag=37462311

Call-ID: [anonimizat]

CSeq: 2 BYE

Exemplul ilustrează folosirea răspunsurilor informaționale. Aici, recepția apelului este confirmată imediat (100), apoi, după întârzieri datorate unor procesări în baza de date, se indică sunarea celuilalt participant (180) și apelul este pus într-o coadă, cu anunțări periodice ale situației. Adi nu poate să primească decât 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 recepție. Adi va trimite datele audio la portul 3456 al terminalului craiova.rom-tel.com iar Teo la portul 5004 al terminalului bucuresti.rom-tell.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ă părți au convenit asupra setului de codecuri ce vor fi folosite, Teo confirmă apelul fără a trimite o nouă descriere de sesiune (ACK). Pentru a încheia conversația, Teo trimite un mesaj BYE către Adi.

3.2.8.2 Înregistrarea

Un utilizator la mașina saturn.rom-tell.com se înregistrează prin multicast la serverul local SIP numit rom-tell.com. În exemplu, agentul utilizatorului de pe saturn se așteaptă să primească cereri SIP pe portul UDP 3890. Înregistrarea expiră peste două ore. Toate invitațiile ulterioare primite pe adresa [anonimizat] sosite la server-ul SIP rom-tel.com vor fi redirecționate către [anonimizat], portul UDP 3890.

C->S: REGISTER sip:rom-tel.com SIP/2.0

Via: SIP/2.0/UDP saturn.rom-tel.com

From: <sip:[anonimizat]>;tag=19

To: sip:[anonimizat]

Call-ID: [anonimizat]

CSeq: 1 REGISTER

Contact: <sip:[anonimizat]: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 comunicația între un server și un client se poate face direct între acestea două așa cum se prezintă în figura 11 sau prin intermediul unui „proxy” cum este prezentat în figura 10. Ultima situație este folosită atunci când se dorește tarifarea utilizatorilor pentru serviciile oferite, mesajele toate trecând prin server-ul proxy, dar și când se dorește folosirea serviciilor mai complexe [15].

Figura I.11 Modul de operare direct

3.2.10 Servicii avansate SIP

Fără 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. Același server poate implementa și alte funcții SIP cum ar fi un server proxy. Registratorul este folosit pentru a păstra locația curentă a unui utilizator.Adresa IP a unui utilizator se poate schimba în mai multe situații – este conectat printr-un furnizor de Internet ce asigură adrese dinamice, este conectat printr-o rețea LAN unde adresele se stabilesc prin DHCP (Dynamic Host Configuration Protocol) sau un utilizator ce folosește serviciul roaming. Pentru a apela acest utilizator folosind adresa lui SIP, o entitate din rețeaua SIP trebuie să mențină corespondența între adresele SIP și adresele IP. Acesta este scopul registratorului.

Pentru a facilita mobilitatea utilizatorului și pentru a evita configurarea manuală cât mai mult, SIP definește 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 putându-se descoperi registratori numai în rețeaua locală.

Acest mod de înregistrare este asemănător cu metoda de descoperire a „gatekeeper”-elor prezentată în H.323. Totuși, în H.323, „gatekeeper”-ele care doresc să preia apelul pot răspunde , permițând clientului să-l selecteze pe cel mai apropriat și să-l contacteze în mod direct mai târziu. În prezent, server-ele SIP nu pot răspunde 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 cunoaște adresa acestuia. În acest caz procedura este asemănătoare ca în cazul oricărei cereri SIP.

Starea registratorului nu este permanentă. Dacă înregistrarea nu este reactualizată aceasta va fi eliminată după o oră prin convenție (această valoare poate fi modificată cu ajutorul câmpului ‚expires’). Pentru a menține o înregistrare, un terminal trebuie să trimită mesaje de înregistrare în mod periodic. Dacă terminalul sau utilizatorul se mută și doresc să modifice parametrii înregistrării, aceștia pot elimina înregistrarea prin trimiterea unui mesaj cu valoarea câmpului ‚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 (acceptând cereri) și ca un client pe cealaltă parte (trimițând cereri). Un proxy poate trimite un mesaj fără să-i schimbe destinația finală, sau poate să-i schimbe câțiva parametrii înainte să- de-a drumul. Acesta chiar poate să trimită un răspuns generat local.

O cerere de la A către B poate fi rutată prin mai multe server-e proxy. Este de dorit ca răspunsul să parcurgă aceeași rută. De exemplu, un proy se poate ocupa de facturarea apelului sau de controlul unui firewall și trebuie să cunoască situația apelului.

Când este folosită o conexiune TCP pentru o tranzacție SIP, în mod obișnui nu sunt probleme deoarece răspunsul ajunge la celălalt capăt în mod automat datorită modului de operare al protocolului TCP. Pe de altă parte, când se folosește UDP anumite informați trebuie să existe pentru a permite receptorului unei cereri să cunoască unde să trimită răspunsul.

Deoarece protocolul SIP nu depinde de protocolul folosit, acesta conține câmpul „Via” pentru a rezolva problema de mai sus. Existența acestui câmp ajută și la evitarea buclelor deoarece fiecare proxy verifică dacă nu este deja pe lista din câmpul „Via”. În fiecare moment când un proxy SIP trimite o cerere din partea unui utilizator, acesta adaugă numele său în lista de server-e proxy străbătute de cerere. Când un proxy trimite un răspuns, realizează procesul invers și se șterge de pa acea listă.

Dacă nu numai cererile și răspunsurile ci și toate cererile trebuie să parcurgă aceeași cale, câmpul „Via” nu este suficient și server-ele proxy trebuie să folosească câmpul „Recorded Route”. Aceasta din cauză ca clienți SIP pot adăuga un câmp „Contact” care permite server-elor să le trimită răspunsurile direct și astfel nu este garantată poziția server-elor proxy pe rută tuturor cererilor. Când acestea rescriu câmpul „Recorded Route”, adaugă identificatorul propriu SIP URL cu o adresă de tip multicast (având parametrul maddr) în prima poziție a listei.

Când server-ele proxy sunt folosite pentru rutarea mesajelor de semnalizare, modelul de apelare este asemănător cu cel de la H.323 când se folosesc entitățile „gatekeeper” pentru rutare, cu excepția că mesajele SIP conțin destule informații pentru a se putea construi server-e proxy fără stări (totuși nu toate funcțiile de bază pot fi implementate folosind entități făra stări, cum ar fi de exemplu facturarea, caz în care trebuie să se țină sub observare mesajele schimbate și stările comunicației pentru a verifica coerența semnalizării).

Există anumite servere care numite „forking proxy” ce trimit copii a unei cereri la diferite adrese pentru a încerca să contacteze mai multe terminale aparținând aceleiași persoane. Acestea nu sunt transparente și pot filtra unele răspunsuri înainte să la trimită înapoi clientului. Acestea pot determina situația în care un terminal primește copii ale aceluiași mesaj cu același „CallID”, caz în care terminalul în cauză trebuie să răspundă la fiecare cerere.

Server de îndrumare. Un astfel de server răspunde la o cerere INVITE cu un mesaj de tipul 3XX sau rejectează apelul cu un mesaj de tipul eroare client sau eroare server.

Răspunsul 300 multiple choices (posibilități multiple) poate fi folosit atunci când utilizator identificat prim SIP URL-ul ce se află în cerere poate fi contactat la mai multe adrese. Aceste posibilități sunt trecute în câmpul „Contact” al răspunsului. Un exemplu poate fi: Contact: sip: [anonimizat],sip:[anonimizat];

Răspunsul 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 câmpul „Contact” al răspunsului. Acest câmp poate conține de asemenea mai multe adrese;

Răspunsul 302 moved temporarily (mutat temporar) trimite (îndrumă) clientul către noua locație, la fel ca răspunsurile precedente, dar pentru o perioadă limitată de timp, indicată prin valoarea câmpului „Expires”;

Răspunsul 380 alternative service (serviciu alternativ) este mai complex și poate părea redundant față de răspunsurile precedente. Pe lângă faptul că furnizează noua locație în câmpul „Contact”, răspunsul conține de asemenea și o descriere de sesiune în corpul mesajului ce reprezintă capacitățile de emisie a noi locații. De la apelant se așteptă ca să trimită un mesaj INVITE la această nouă locație și să ofere în descrierea de sesiune conținută de mesaj niște capacități asemănătoare (posibil o copie a parametrilor SDP din răspunsul 380, cu excepția portului RTP pentru recepție).

Server-ul de îndrumare poate fi folosit în conjuncție cu un registrator pentru a îndruma apelurile către locația curentă a utilizatorului apelat. Poate fi folosit ca și o formă primitivă a unui sistem de distribuție a apelurilor.

Un server de îndrumare poate fi și un mijloc de a îmbunătații 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 obținându-se o încarcare egală a acestora. Aceasta se poate realiza folosind parametru „maddr” in câmpul „Contact” astfel:

<sip:adresăoriginală@callcenter.com:9999;maddr=adresăcentrală3.callcenter.com>

Prin întoarcerea acestei linii, server-ul indică apelantului că trebuie să trimită un mesaj INVITE un mesaj cu aceeași destinație (adresăoriginală@callcenter), dar la adresa indicată de paramatrul „maddr”. Acest parametrul indică apelantului să sară peste procedura normală de identificare a unui server SIP corespunzător ce se ocupă de domeniul din adresă și să folosească server-ul a cărui domeniu a fost furnizat cu adresa „maddr”.

Funcționarea server-ului de îndrumare este similară cu rolul jucat de către „gatekeeeper”ul 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 excepția 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@mașină dar pot exista forme în care apar numere de telefon, porturi, nume de domeniu și adrese de IP. Aceste forme sunt prezentate în tabelul următor:

În cele mai multe situații adresa SIP a unui utilizator va fi aceeași cu adresa sa de e-mail. Cele mai multe extensi (antete, maddr, etc.) nu sunt permise în câmpurile „To” și „From”, dar pot fi folosite în câmpul „Contact”.

SIP definește 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 rând URL-ul SIP permite teminalului ce dorește stabilirea unei legături să localizeze server-ul SIP. Acesta va fi destinația mesajului inițial INVITE. Acest server poate fi destinația finală a apelului; dacă nu se presupune că știe adresa de transport a terminalului dorit;

Dacă sever-ul SIP nu este destinația finală a apelului, acesta va îndruma cererea INVITE către terminalul căutat. Aceasta poate fi făcută ori prin instruirea terminalului apelant să trimită o nouă invitație la altă locație folosind răspunsul 302, ori transmițând invitația în mod transparent la adresa de transport corespunzătoare. Primul model este asemănător cu modelul H.323 de apel direct iar al doilea cu modelul de apel rutat prin „gatekeeper”.

Pentru a găsi 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 același mod de lucru în care de exemplu browser-ul Internet Explorer translatează adresele textuale în adrese IP, terminalul face rost de aceste înregistrări. Folosindu-le pe acestea poate deduce adresa de transport a server-ului. Ținând minte adresa server-ului sau URL-ul acestuia în loc de cele ale terminalului cu care se dorește comunicarea, este posibilă mutarea terminalului apelat și chiar salvarea în memorie de tip cache a URL-urilor. Dacă adresa terminalului apelat s-ar menține direct în DNS atunci ar apare probleme la salvarea în memorii de tip cache a înregistrărilor. În mod normal toate înregistrările DNS pot fi salvate de către rezolvatorul DNS. Acestea expiră după valoarea în secunde exprimată de parametru TTL ce este conținut de înregistrări. De aceea dacă terminalul apelat se mișcă, apelantul va avea încă în memorie adresa greșită și apelul va eșua. Singura soluție este de a pune parametrul TTL la 0 și să se facă interogări DNS atunci când terminalul se mișcă. Soluție nu foarte ușoară.

Pe de altă parte, server-ul SIP este foarte improbabil să se mute și menținerea adresei în înregistrări DNS nu pune nici-o problemă. Server-ul este anunțat despre noua locație a terminalului și poate îndruma cererea INVITE către locația corespunzătoare.

Un agent de apel este un serviciu care se ocupă apelurile spre și de la un utilizator în locul acestuia. În telefonia tradițională acest tip de serviciu este realizată de către infrastuctura inteligentă a operatorului sau de către „Private Branch Echange”(PBX) aflat în posesia unei companii.

Un agent de apel poate realiza următoarele sarcini:

Încearcă să găsească utilizatorul prin îndrumarea mesajelor de inițializare a apelurilor (H.323 Setup sau SIP INVITE) către locațiile corespunzătoare sau către mai multe locații simultan.

Implementează regurile de îndrumare a apelurilor cum ar fi trimiterea apelului către alte locații atunci cănd sună ocupat, atunci când nu se răspunde sau în mod necondiționat;

Implementează filtrarea apelurilor folosind reguli dependente de originea apelului și/sau dependente de momentul inițierii acestuia.

Înregistrează încercările nereușite;

realizează orice alte sacini privind managementul apelului din partea utilizatorului.

Toate aceste funcții pot fi implementate de către un proxy SIP. Îndrumarea simplă a apelurilor și filtrarea pot fi implementate și de către 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ă forțeze 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ă situație fiind mai puțin practică decât cea care presupune existența 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ă înregistrările dinamice. De exemplu, de fiecare dată când un utilizator se conectează la Internet folosind serviciile unui furnizor, primește o adresă nouă IP. Dar dacă sotfware-ul SIP pe care îl folosește înregistrează această nouă adresă, proxy-ul va putea să trimită toate apelurile către această adresă.

3.2.10.2 Conferința

SIP poate fi folosit pentru stabilirea unei conferințe. Totuși 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ă conferința în care fluxul media este trimis folosind transmisia de tip multicast. Semnalizarea corespunzătoare acestui flux poate fi transmisă folosind multicast sau unicast.

În cazul în care se folosește semnalizarea multi-unicast (mai multe semnalizari de tip unicast), nu există mari diferențe față de cazul conversației punct la punct, cu excepția faptului că descrierile de sesiune SDP indică adrese multicast.

Când se folosește semnalizarea multicast pentru stabilirea unei conferințe, 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 inițializarea unor conferințe și de aceea în câmpul „destinație” se va afla mai degrabă numele unei conferințe decât al unei persoane. Totuși, este posibil să se folosească o cerere multicast care să folosească URL-ul unei persoane în câmpul „destinație”, de exemplu pentru căutări de tip multicast. Răspunsurile la o cerere SIP sunt trimise înapoi către portul UDP care a fost folosit pentru transmisie și la aceeași adresă de tip multicast. Pentru a reduce traficul pe rețea și pentru a evita posibilele fluxuri de răspunsuri sincronizate, s-au făcut anumite modificări față de cazul procedurii de invitare multi-unicast, ce includ:

răspunsurile 2XX nu sunt trimise;

răspunsurile 6XX sunt trimise numai dacă URL-ul din câmpul „destinație” este același cu a unui utilizator ce folosește terminalul în cauză (adică dacă cererea este o interogare multicast și nu o invitație la conferință multicast);

răspunsurile sunt trimise după o întârziere 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’ având valoarea 0.0.0.0 (valoare zero) unui terminal pentru a-i indica că nu mai are dreptul să vorbească și mai târziu să-i trimită un mesaj INVITE cu parametrul ‚c’ cu altă valoare decât cea nulă pentru a-i indica dreptul la microfon.

SIP în mod nativ suportă codarea în mai multe straturi. Această clasă de codecuri codează informația media folosind mai multe fluxuri de date simultane. Un flux contține informațiile de bază (suficiente pentru o redare de calitate proastă) și celelalte fluxuri având informații î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 conferințele multicast, permițând tuturor receptorilor să adapteze recepția conform caracteristicilor terminalelor aflate la dispoziție, astfel transmițător 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>/<număr 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 conferințele multi-unicast este limitat. O entitate centrală poate fi configurată astfel încât să funcționeze 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 invitație 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 dorește 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 același CallID. Menținând valoarea parametrului CallID se semnalizează participantului B că aceasta nu reprezintă o invitație la o altă sesiune ci doar se schimbă parametrii sesiuni existente.

Controlul apelurilor pot fi activate pe o mașină proxy sau registrator intr-un mod simplu prin trimiterea de mesaje de înregistrare. De exemplu un utilizator care dorește să trimită temporar apelurile, cei sunt destinate, la altă locație trimite doar un mesaj REGISTER cu numele acestuia în câmpul „To” și noua locație în câmpul „Contact”, având o valoarea dorită în câmpul „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ă interfața perfectă pentru a configura un proxy complex.

3.2.10.3 Facturarea apelurilor

Prin definiție, toți participanți invitați de o sursă comună se află în același apel SIP. Acest apel este identificat printr-un identificator unic în toată rețeaua, CallID. Cu această definiție, 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 combinația informațiilor din câmpurile „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 plătit de persoana cere-l inițiază. Un proxy ce este un releu pentru semnalizările 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 răspunsurile. Durata unei conexiuni se poate determina ca durata în timp între prima cerere INVITE acceptată și prima cerere BYE.

Pentru a forța 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 rețea. Astfel se micșorează posibilitațile 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 către un server proxy SIP în urma mesajelor ce au trecut prin acesta. Pe baza acestor informații poate afla cine a sunat, cu cine a vorbit, ce servicii s-au folosit și cât 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 depășit creditul sau nu au dreptul de a folosi serviciile de telefonie.

Figura I.12 Facturarea cu ajutorul unui proxy

3.2.11 SIP și telefonia tradițională (RFC 3372, septembrie 2002)

SIP este un protocol ce poate stabili, modifica și opri sesiuni multimedia. Aceste sesiuni includ conferințe multimedia, telefonie prin internet și alte aplicații similare. SIP este unul din protocoalele de bază folosit pentru implementarea „Vocii peste IP” (VoIP) Cu toate că realizarea semnalizări corespunzătoare apelurilor telefonice și transportul fluxurilor media peste IP au destule avantaje față de telefonia tradițională, o rețea VoIP nu poate exista izolată de rețelele de telefonie existente. Este vital ca rețeaua telefonică ce folosește SIP să fie capabilă să interacționeze cu PSTN.

O caracteristică importantă a oricărei rețele de telefonie SIP o reprezintă transparența față de serviciile PSTN. Aceste servicii, ca de exemplu menținerea unui apel în așteptare, numere de telefon gratuite, etc. implementate în protocoale cum ar fi „Signalling System No.7” (SS7) trebuie să fie oferite de o rețea SIP într-o manieră în care diferențele să fie mici în timp ce flexibilitatea protocolului SIP să nu fie limitată. Pe de altă parte, este necesar ca SIP să aibă primitivele pentru transportul acestor servicii și pentru terminalele SIP nu numai pentru cele ce cunosc SS7. Totuși, este esențial ca informația SS7 să fie disponibilă la „gateway”-uri, puncte de interconectare SS7-SIP, pentru a asigura transparența trăsăturilor ce sunt suportate în SIP. Dacă e posibil, informația SS7 trebuie să fie disponibilă fără pierderi în rețeaua SIP; acest lucru este necesar deoarece unele rețele folosesc parametri SS7 extinși pentru a transmite informații prin aceste rețele.

O altă importantă caracteristică a rețelei telefonice SIP o reprezintă rutarea cererilor SIP – astfel o cerere SIP ce inițializează un apel telefonic trebuie să conțină destule informații în antelul ei pentru a fi rutată în mod corespunzător de către serverele proxy prin rețea. Aceasta duce la faptul că este necesar ca numărul format de către un utilizator trebuie luat din semnalizarea SS7 și pus în cererea SIP.

RFC-ul 3372 asigură un cadru pentru integrarea semnalizării din telefonia tradițională î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 tradițională sunt încapsulate în mesajele SIP pentru ca informațiile necesare serviciilor să nu fie pierdute în cererile SIP. Totuși, intermediari ca server-ele proxy ce iau deciziile de rutare nu trebuie să li se ceară să înțeleagă mesajele SS7 și astfel simultan anumite informații critice sunt traslatate în câmpurile corespunzătoare 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 informațiile din timpul apelului pe calea de semnalizare în tipul sesiunii. Aceste informații nu schimbă starea apelurilor SIP sau parametrii sesiunilor pe care SIP le inițiază. Un mecanism de a realiza acest lucru este de asemenea necesar.

Problemele care trebuiesc depășite și modul de a face acest lucru este prezentat în următorul tabel:

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 țintește să specifice numai comportarea numai a interfațelor 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 noțiunea de SIP-T adică SIP pentru telefoane ce reprezintă un set de mecanisme ce sunt folosite pentru interconectarea rețelelor SIP cu cele ce folosesc SS7. Scopul acestui set de mecanisme este de a asigura codificarea informației transportate prin semnalizare SS7 în mesaje SIP și transparența serviciilor dincolo de punctele de interconectare PSTN-SIP. SIP-T este recomandat a fi folosit acolo unde o rețea VoIP este legată de o rețea PSTN.

Folosind SIP-T, există trei modele simple pentru modul cum apelurile interacționează cu „gateway”-urile. Apelurile ce sunt originare dintr-o rețea PSTN pot traversa „gateway”-ul pentru a avea ca țintă un terminal SIP, cum ar fi un telefon IP. În mod asemănător, un telefon IP poate iniția un apel prin care să se poarte o conversație cu cineva legat la o rețea PSTN. Ultima posibilitate de interes din punct de vedere al protocolului SIP este aceea ca o rețea IP ce folosește SIP să fie doar o rețea de tranzit între „gateway”-uri. În acest caz pentru a putea interconecta rețeaua IP cu PSTN trebuie ca informația SS7 primită sa fie păstrată în cererile SIP la „gateway”-ul ce inițiază apelul SIP și să fie refolosită această informație atunci când la „gateway”-ul ce se află la celălalt capăt al apelului SIP, se reconstruiește semnalizarea PSTN. Prin încapsularea informațiilor ISUP în semnalizarea SIP, o rețea telefonică ce folosește protocolul SIP asigură păstrarea tuturor informațiilor critice SS7 atunci când aapelul SIP este folosit pentru a face legătura între două segmente PSTN.

Dacă ar fi fost vorba numai de schimbul de informații între „gateway”-uri, orice protocol pentru transportul acestora ar fi fost bun, ne fiind nevoie neapărată de SIP și de SIP-T. SIP-T este folosit pentru a beneficia de avantajele utilizării SIP: rutarea cererilor și controlul apelurilor realizate de server-ele proxy, ușurința în realizarea serviciilor SIP și altele. Introducerea de informații din mesajele ISUP primite în antetul cererilor, permite intermediarilor să considere aceste informații atunci când procesează cererile. SIP astfel facilitează stabilirea de apeluri și crearea de servicii pentru rețeaua IP și în același timp prin SIP-T asigură metodele de interconectare cu PSTN.

În continuare voi detalia fluxurile mesajelor de semalizare atunci când avem una din situațiile prezentate mai devreme:

Originea apelului PSTN, ținta PSTN: „gateway”-ul de unde se inițiază apelul SIP primește informațiile ISUP de la rețeaua de telefonie PSTN, le introduce în mesajele SIP pe care le transmite către „gateway”-ul unde se termină apelul SIP. Acesta extrage informațiile ISUP pe care le folosește în semnalizarea către rețeaua PSTN. Se folosește rutarea SIP pentru a determina punctul de ieșire din rețea și pentru a a iniția negocierea unei sesiuni media între capete. Mesajele schimbate sunt prezentate în figura I.13.

Originea PSTN și ținta apelului rețeaua IP: „gateway”-ul ce inițiază apelul SIP primește informații ISUP de la PSTN și le introduce în mesaje SIP ce sunt direcționate către agentul SIP. Terminalul nu are nevoie de informațiile ISUP încapsulate și le ignoră. (figura I.14)

Originea IP și ținta apelului rețeaua PSTN: un telefon SIP inițiază apelul VoIP care este rutat de unul sau mai multe server-e proxy către „gateway”-ul corespunzător. Acesta produce din informațiile date, semnalizarea ISUP și direcționează apelul către interfața 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 rețelele PSTN au următoarea semnificație: IAM: Initial Address Message, mesaj trimis pentru a se indica pornirea unui apel și pentru a se cere rezervarea unei părți din linia telefonică până la abonatul apelat, ACM – Address Complete Message, trimis pentru a indica disponibilitatea părți apelate și faptul că linia a fost rezervată, ANM – Answer Message, trimis atunci când 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 funcțional există trei elemente distincte într-o rețea VoIP ce folosește SIP și interacționează cu PSTN:

Inițiatorul apelului SIP

Terminalul ce este apelat de apelul inițiat

Intermediarii ce rutează cererile SIP

Funcționarea acestor elemente este precizată în continuare:

Inițiatorul. Funcțiile agentului ce inițiază apelul este de a genera cererile SIP de creare a unei sesiuni cum ar fi INVITE. Când un apel are originea în PSTN, un „gateway” reprezintă un inițiator. Altfel, acesta este un terminal SIP obișnuit. În orice caz, se poate observa că nu se poate anticipa tipul de element căruia apelul îi este destinat, adică nu se poate ști dacă terminalul dorit a fi apelat se află legat la rețeaua SIP sau la PSTN. În cazul cănd un apel își are originea în PSTN, „gateway”-ul ce inițiază apelul ia necesari pași să păstreze informația ISUP primită intactă prin încapsularea acesteia în mesajele pe care le crează. Acesta este trebuie să recunoască versiunea ISUP pe care a recepționat-o și să includă această informație în mesajul creat. Apoi crează antetul cereri INVITE din parametrii ISUP primiți. Aceasta poate însemna ca în câmpul „To” să treacă un URL care să trimită la numărul format de către utilizator. În alte cazuri, un telefon SIP este inițiatorul unui apel VoIP. În mod normal, telefonul trimite cererea unui proxy SIP care este responsabil pentru rutarea acesteia către destinația corespunzătoare. Aici nu există nici-o informație ISUP care să fie încapsulată. Cu toate că apelul poate avea ca țintă un terminal din rețeaua 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 informație ISUP încapsulată. Astfel un inițiator trebuie să genereze semnalizare SIP și să realizeze încapsularea și modificarea formatului semnalizării atunci când este posibil.

Terminalul apelat în rețeaua SIP. Acesta este un agent SIP standard care poate fi ori un „gateway” ce interacționează cu PSTN ori un terminal SIP. În cazul în care un apelul are ca țintă un terminal din rețeaua PSTN, „gateway”-ul de ieșire se află la capătul apelului SIP. Acesta generează informațiile ISUP corespuzătoare pentru semnalizarea prin rețeaua PSTN. Valorile pentru parametrii ISUP pot fi extrase din antetul cereri SIP primite sau din informațiile ISUP încapsulate în mesaj. În cazul în care ținta unui apel este un terminal SIP, agentul server care primește cererile cu informațiile încapsulate în mod normal nu ține cont de acestea.

Intermediarii. Acestora le este încredințată sarcina de a ruta mesajele de la unul la celălalt către terminalele SIP și „gateway”-uri. Fiecare server proxy ia o decizie în privința direcției în care o să trimită un mesaj, bazată pe mai multe câmpuri din antet. SIP-T introduce anumite considerații în plus pentru acțiune de trimitere a mesajelor care pot aduce noi caracteristici și condiții de îndeplinit pentru intermediari. Asigurarea transparenței față de ISUP este principalul scop urmărit de SIP-T. Compabilitatea între variantele ISUP cunoscute de interfețele PSTN ce se află la capetele unui apel SIP poate să influențeze transparența 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 când se iau deciziile de rutare o reprezintă locul unde este amplasat „gateway”-ul unde se termină un apel SIP. Această locație trebuie să fie cât mai aproape de utilizatorul apelat.

SIP-ul definit în RFC-ul 3261 nu are mijlocele pentru a transporta informația de control care este generată în timpul unei sesiuni. Metoda INFO ce a fost definită în RFC-ul 2976 și adăugată la SIP trebuie folosită pentru transportul informației din timpul sesiunii.

3.2.12 Securitatea apelurilor

Cererile și răspunsurile SIP conțin informații importante despre modul și conținutul comunicației între utilizatori. Corpul mesajului poate conține chei de codare pentru sesiunea ce se inițializa. 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 agenți ai utilizatorilor implicați în tranzacție. În mod normal, mesajul este trimis codat cu cheia publică a receptorului, astfel încât numai acesta să poată citi mesajul. Toate implementările trebuie să poată folosi codarea bazată pe PGP, dar pot folosi și alte scheme de codare. O cerere sau un răspuns SIP este codată cap la cap prin împărțirea mesajului într-o parte care este codată și un antet mic care rămâne necodat. Unele părți ale mesajului SIP, cum ar fi linia de cerere, linia de răspuns și alte câmpuri trebuie citite de server-ele proxy și de aceea nu trebuiesc codate. Toate aceste câmpuri trebuie să fie poziționate înaintea celor codate. Mesajul este codat începând cu primul caracter al primului câmp care este codat și până la sfârșitul mesajului.

Codare între servere: nu toate cererile sau răspunsurile SIP pot fi codate cap la cap din cauză că sunt câteva câmpuri ca „To” sau „Via” care trebuie să fie vizibile pentru server-ele proxy, astfel încât cererile să fie rutate în mod corespunzător. Pentru ca utilizatorii rețelei răuvoitori să nu poată citi aceste câmpuri se aplică o codare între server-e. Acest tip de codare se poate aplica și cererilor sau răspunsurilor 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 informații se pot afla și din realizarea unei analize atraficului rețelei, astfel această tehnică aduce un grad de protecție limitat dar care merită efortul. În mod normal proxy-urile nu au voie să modifice câmpurile antetelor și corpurile mesajelor. Acestea pot, totuși, 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ă funcție sau pentru a impune politici de securitate.

Măsuri de protecție trebuie luate pentru a împiedica un atacator să modifice și să retransmită cereri și răspunsuri SIP. Aceleași măsuri de codare ce se aplică pentru a asigura autenticitatea unui mesaj SIP sunt folosite și pentru a autentificarea celui care a transmis mesajul. Totuși acestea mecanisme nu asigură integritatea mesajului. Mecanismele de autentificare de la nivelul transport și de la nivelul rețea pot fi folosite între server-e. SIP poate folosi și schemele HTTP de autentificare. Toate implementările SIP trebuie să permită folosirea autentificării 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 răspuns neautorizat sau unui răspuns a unui proxy ce dorește autentificare la o cererea originală. Schemele mai complicate presupun trimiterea unui răspuns la cererea unei entități ce dorește se ocupă cu autentificările, răspuns ce conține un secret comun.

PGP adică „Pretty Good Privacy” este bazat pe modelul în care clientul își dezvăluie 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 măsuri nu sunt perfecte. Chiar și cu mesajele codate, o persoană rău voitoare poate să citească mesajele trimise și poate introduce răspunsuri neautentificate ce modifică desfășurarea 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 competiție pentru dominarea semnalizări în cadrul telefoniei prin rețelele IP, se pune problema care este mai bun? Vestea bună este că cele două standarde par să conveargă – luând ideile bune unul de la celălalt. În particular versiunea 3 a standardului H.323 a adăugat elemente care iau crescut performanța (s-a umblat la întârzierea în inițializarea unui apel și la procesarea fără stări pentru folosirea UDP-ului), elemente care inițial erau avantaje importante ale SIP-ului.

Mai important, fiecare standard în aceeași măsură permit folosirea majorității funcțiilor cerute de către utilizatori, printe acestea aflându-se: inițializarea apelului, închiderea unui apel, menținerea unui apel în starea de așteptare, transferarea unui apel la altă locație, conferința și inițializarea apelului de pe o pagină Web. Singurele diferențe funcționale sunt indicarea unui apel în așteptare (care este utilizat numai în H.323), controlul apelului de către o a treia persoană (de exemplu o secretară care dă un telefon din partea directorului, funcție utilizată numai în SIP) și câteva funcții referitoare la conferințe. În timp ce funcțiile ce pot fi folosite sunt asemănătoare, standardul H.323 (prin intermediul protocolului H.245) furnizează un mecanism mai robust pentru procesul în care se schimbă informațiile referitoare la capacitățile terminalelor, decât oferă SIP.

Totuși, funcționalitatea 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 rețele. În timp ce la capitolul funcționalitate cele două standarde sunt similare în domeniile tocmai prezentate sunt foarte diferite. În următorul tabel sunt prezentate caracteristicile celor două protocoale:

3.3.2 Unde SIP este mai bun

SIP este simplu. Acesta face într-o tranzacție 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. Combinația acestor deosebiri a dus la timpi mult mai mici pentru inițializarea unui apel în cazul folosirii SIP. Această situația a dus la modificările apărute în versiunea 2 a standardului H.323, printre care și procedura numită „Fast Connect” ce scurtează timpul necesar pentru inițializarea unui apel. În versiunile ulterioare s-a adăugat și posibilitatea de a lucra cu UDP.

Organizația IETF a dobândit o mare experintă în transmisia datelor în mod multicast. SIP a fost creat pentru o rețea 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 instituții ce se ocupă cu rezolvarea prin telefon a unor probleme dar și unui utilizator care încearcă să găsească pe cineva într-o instituție. Versiunile 1 și 2 ale H.323 trebuie să folosească transmisia în mod multi-unicast pentru a realiza același 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 ([anonimizat]) și un URL de tip SIP (sip: [anonimizat]). î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 direcționa un apel către un server non-SIP într-o manieră foarte flexibilă. Un terminal SIP, atunci când este apelat de un alt terminal SIP, poate direcționa apelul către o pagină Web sau către un URL de e-mail.

Procedura din SIP poate fi realizată și de către H.323 folosindu-se tipul identificatorilor de tip URL atunci când se specifică o adresă alias, disponibil din versiunea 2 a protocolului H.225. Dar prin această adăugare schema identificatorilor începe să devină foarte complicată.

Mulți furnizori de servicii doresc să aibă posibilitatea să marcheze unele apeluri ca fiind prioritare. Câmpul „Priority” din antetul SIP aduce acestuia o funcție 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 ușor greșile și se pot corecta la fel de ușor și problemele de interconectare se depistează repede. Dezavantajul principal este acela că această metodă de codare crează mesaje de dimensiuni mai mari decât dacă s-ar fi folosit mesaje codate binar.

3.3.3 Unde este H.323 mai bun

H.323 face o distincție clară între tipurile de media ce pot fi folosite și tipurile de media ce sunt în mod efectiv transmise în rețea. SIP nu face o asemenea distincție, terminalele prezentând doar codecurile pe care le poate folosi la recepție și nu există nici o procedură pentru deschiderea conexiunii media în afară de trimiterea efectivă a datelor. Aceasta pare o simplificare a semnalizării și poate apărea ca un avantaj pentru SIP. Totuși în unele cazuri, în particlar în cazul în care se implementează un server care va fi folosit foarte mult și resursele trebuiesc menținute sub control, acest mod de lucru poate cauza probleme deoarece fiecare server care își prezintă capacitatea de recepție trebuie să asculte un port pentru a recepționa datele. Un client H.323 trebuie să înceapă procesul de ascultare doar când primește mesajul „OpenLogicalChannel”. Aceast mod de funcționare al protocolului SIP poate duce la existența a mai multor procese ce nu primesc nimic și deoarece cele mai multe codecuri implementează funcția de detecție a pauzelor aceste procese pot să nu primească nimic chiar dacă conferința se desfășoară în mod normal, așa că închiderea proceselor care nu fac nimic din cauză că partenerul de conversație a dispărut este foarte greu de realizat.

H.323 singur sau în combinație cu H.332 conține elemente foarte puternice de control al conferinței. SIP nu a fost creat pentru controlul modului de desfășurare al conferinței și de aceea multe din elementele necesare pentru control nu există, încă.

Mesajele H.323 ce aparțin 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 discuții privind complexitatea H.323-ului. Folosirea a două codări 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 rețelelor cu programe ce cunosc metodele de codare Q.931 și PER ANS.1 și care sunt mai greu de găsit.

Pornirea de la zero este dificilă, dar după ce o compania are un ANS.1 și o implementare Q.931, sunt câteva advantaje în folosirea acestei codări:

unitățile de date ce sunt transferate între terminale sunt optimizate din punct de vedere al dimensiunii

(posibil) performanța este mai bună.

În rețelele moderne dimensiunea pachetelor nu mai este o problemă, dar dacă H.323 va fi utilizat în rețelele de telecomunicații mobile atunci acest aspect va fi un avantaj.

Performanța este discutabilă în cazul standardului H.323. Este adevărat 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 performanța depinde mult de omplementare.

În stadiul actual de dezvoltare a celor două standarde, descoperirea entității care se ocupă de apeluri este mai bine realizată la H.323 unde un terminal poate cunoaște ce „gatekeeper” se ocupă de apeluri spre deosebire de situația de la SIP. În orice caz, acest fapt se poate fixa foarte ușor în versiunile următoare.

3.3.4 Interconectarea SIP – H323

Cele două protocale se ocupă cu inițierea, controlul și terminarea conversațiilor multimedia. Deoarece fiecare dintre acestea au o arhitectură separată și mesaje distincte care numai în aceste arhitecturi funcționează, pentru legarea unei rețele SIP cu o rețea H.323 este nevoie de un echipament numit „gateway” ce trebuie să implementeze cele două protocoale, pentru a face schimbul de informații între cele două rețele. Acest echipament poate juca următoarele roluri:

pe partea cu rețeaua H.323 joacă rolul de terminal H.323 și pe partea cu rețeaua 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 interconectări simple între cele două rețele este prezentată în figura următoare:

Figura I.16 Interconectarea rețelelor SIP și H.323

Deoarece H.323 folosește în semnalizare mesaje din mai multe protocoale (de exemplu RAS, H.255 și H.245) și în mai multe etape, timpul de inițializare a apelurilor este mare în comparație cu SIP. Dacă se folosește modul de semnalizare denumit „FastStart” acest timp se reduce ajungând comparativ cu cel al protocolului cu care este in competiție. Folosind acest mod în tabelul următor se prezintă mesajele ce sunt folosite pentru inițializarea unei sesiuni și cum sunt ele transformate din mesaje de semnalizare H.323 în mesaje SIP.

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

3.3.5 Concluzii

Pe piață există echipamente ce suportă H.323 sau SIP dar puține știu sa folosească ambele protocoale. În prezent echipamentele ce lucrează cu H.323 sunt mai numeroase decât cele ce folosesc SIP.

În practică, vor exista companii ce vor produce echipamente ce vor folosi unul din cele două protocoale până va fi sigur că unul dintre acestea va dispărea sau până se vor uni într-un alt protocol. Dacă se dorește o funcționare stabilă cu alte implementări atunci se pot alege echipamente ce folosesc H.323 deoarece acest protocol este mai stabil din punct de vedere al standardelor decât SIP. Altfel, cele două protocoale furnizează aceleași servicii. Singura zonă în care se observă o diferență, este inițializarea conferințelor. Deoarece SIP poate fi folosit pentru a invita mai multe persoane să se alăture la un apel, conferințele pot fi inițiate fără existența în mod obligatoriu a unui server pentru conferințe. În practică totuși, dacă aceste amănunte sunt avantaje sau nu depinde de soluția implementată de vânzătorul echipamentului și nu de protocoalele ce sunt folosite.

Materialele din care au fost consultate pentru a realiza acest subcapitol au fost: Rețele 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 noțiunile prezentate aici.

4. Vocea în VoIP

Aceasta reprezintă un factor important în diferențierea rețelelor noi apărute ce oferă sevicii VoP (voce peste rețele de pachete) dar și a echipamentelor folosite. De aceea măsurarea calității vocii într-un mod obiectiv, sigur și ieftin devine foarte importantă. Calitatea poate însemna mai multe lucruri depinzând 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 performanțele mecanismului de transport folosit.

Rețeaua PSTN tradițională a rezolvat problema calității prin optimizarea circuitelor pentru banda folosită de voce și pentru ritmul conversației.Această rețea a ajuns să furnizeze servicii de bună caliatate pentru aplicații în timp real ce au nevoie de întârzieri mici, jitter mic și bandă constantă dar mică. Cu toate că PSTN nu prezintă o calitate a vocii excepțională, utilizatorii s-au obișnuit cu acesta și compară celelalte servicii folosind PSTN ca reper.

Spre deosebire de rețeaua de telefonie tradițională, rețele IP au fost proiectate să ofere servicii aplicațiilor ce nu au cerințe de timp real, cum ar fi transferul fișierelor sau e-mail. Aceste aplicații crează un trafic în rafale și uneori cer bandă însemnată dar nu sunt afectate de întârzieri sau variația acestora. Pentru a putea folosi aplicațiile de timp real, rețelele IP trebuie să aibă și mecanisme care să asigure calitatea serviciilor (QoS) necesară pentru transportul datelor. Utilizatorii PSTN s-au obișnuit cu o calitate foarte bună a vocii. Furnizând o calitate comparabilă a serviciilor va duce la acceptarea și succesul aplicațiilor de voce prin rețelele de pachete.

VoIP, prin introducerea de codecuri neliniare și prin impunerea de termeni privind livrarea pachetelor unor rețele ce nu au fost proiectate pentru cerințe de acest gen, face ca menținerea calități vocii dificilă. Transmisia, folosind acest tip de rețele, 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, întârzierile datorate proceselor din “gateway”-uri, pierderea pachetelor, întârzierile și codecurile neliniare.

Multe tipuri de rețele de date nu pot să asigure banda necesară pentru transportul vocii. Rețele de date nu asigură o întârziere mică și nici măcar constantă. Introducerea semnalului vocal în aceste rețele necesită folosirea de metode care să asigure transportul în timp real, calitatea vocii putând avea de suferit dacă aceste metode nu funcționează 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 aplicațiile de voce fără a afecta traficul de date obișnuit, se folosesc și tehnici de compresie în particular pentru traficul în timp real ce are ca destinație un calculator personal. Compresia neliniară poate fi o cauză majoră pentru scăderea calități vocii.

Rețele 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 liniște poate preveni crearea și transmiterea de pachete pe perioadele dintre frazele vorbite. La fel, suprimatoarele de ecou sunt necesare pentru a elima ecoul atunci când devine perceptibil atunci când rețeaua introduce întârzieri. Dacă procesele de acest timp nu funcționează cum trebuie calitatea vocii are de suferit.

Aplicațiile compensează pierderea pachetelor prin retransmiterea pachetelor pierdute folosind TCP. Aplicațiile de date cum ar fi transferul de fișiere și e-mail sunt mai puțin afectate de timpul în care această retransmisie are loc , dar traficul de voce în timp real nu poate accepta această întârziere. În plus VoIP folosește UDP care nu garantează livrarea pachetelor. Pachetele pierdute înseamnă informație pierdută.

Întârzierea percepută de către utilizator poate fi proveni din timpul în care sistemul sau rețeaua trensformă semnalul analog în semnal digital, crează pachetele, transmite, rutează și stochează într-un buffer un semnal de voce. Această întârziere poate să creeze probleme într-o conversație și poate să mărească stricăciunile provocate de alte probleme cum ar fi ecoul.

Un motiv important pentru măsurarea calități vocii este dezvoltarea și folosirea codecurilor neliniare ce comprimă vocea astfel încât se transmite informația importantă fără a se transmite tot semnalul vocal. Cu alte cuvinte aceste codecuri conservă cum sună vocea fără a păstra toate frecvențele semnalului.

În general, se poate exprima și măsura calitatea vocii în funcție de ascultătorul și vorbitorul ce au luat parte la conversație. Calitatea trebuie măsurată capăt la capăt. 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ă însoțeste orice aspect al calități vocii.

O definiție clară a calității vocii este necesară înainte de a discuta caracteristicile și componentele acesteia. Mulți factori influențează percepția calități unui apel telefonic – de la ușurința cu care acesta este efectuat până la calitatea sunetului din receptor. La un nivel mai ridicat calitatea unui apel este compusă din calitatea serviciului, calitatea sunetului și calitatea conversației. Acestea sunt interdependente atunci când un utilizator trebuie să-și spună părerea despre calitatea unui apel. De exemplu acesta poate tolera, ignora sau poate să nu observe o calitate mai proastă a sunetului atunci când calitatea serviciilor este foarte bună. Utilizatorii telefoanelor mobile sau cei care poartă conversații prin satelit la mare distanță pot tolera sau ignora problemele de sunet din cauza avantajelor aduse de apel. Un alt exemplu este și calitatea conversației. Când există o întârziere perceptibilă între frazele ascultătorului și a vorbitorului, mulți utilizatori percep această situație ca o problemă de calitate a serviciului sau a sunetului.

Multe aspecte ale calități serviciilor sunt strâns legate de problemele și deciziile luate de furnizorul de servicii și mai puțin legate de performanța rețelei și funcționarea echipamentelor de rețea. Totuși, calitatea sunetului și a conversației par stâns legate de dispunerea rețelei și performanța acesteia. Din această cauză, calitatea vocii este rezultatul masurării calitative și cantitative a calități sunetului și a conversației.

Calitatea vocii este afectată de trei factori principali: claritatea, întârzierea și ecoul. Claritatea este o măsură a fidelității, lipsei distorsiunilor și inteligibilități unui semnal de voce. Întârzierea este timpul necesar unui semnal vocal să ajungă de la vorbitor la ascultător. Ecoul este sunetul produs de vorbitor ce ajunge la urechea acestuia. În perceperea calității un factor îi afectează pe ceilalți, utilizatorii neputând să distingă între diferitele efecte cauzate de rețea. Distorsiunile și fidelitatea sunt nu sunt afectate de întârziere, astfel un semnal vocal poate fi întârziat oricât ș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 întârzierea rezonabil de scurtă. Se mai observă că ecoul depinde de întârziere ș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, indicând cantitatea de informație care poate fi extrasă dintr-o conversație. Totuși este posibil ca să se înțeleagă ce spune vorbitorul chiar dacă la recepție există o claritate proastă a semnalului, cum ar fi o voce distorsionată sau greu de auzit. Claritatea și evaluarea acesteia depinde de mai mulți factori. De exemplu unele benzi de frecvență sunt mai importante pentru percepția clarității decât altele. Acultătorii sunt mai sensibili la distorsiunile sau atenuările ce au loc în bnda de frecvență 1000- 1200 Hz decât la cele ce au loc în banda 250-800 Hz. Un alt exemplu este că frazele complete sunt mai ușor de înțeles decât o secvență de cuvinte fără nici o legătură, chiar dacă fraza completă este mai distorsionată decât secvența de cuvinte. De aceea utilizatorii percep frazele complete ca având o calitate mai bună.

Într-un apel telefonic ce este inițiat în rețeaua PSTN și are ca țintă un terminal dintr-o rețea de pachete mai mulți factori contribuie la afectarea claritații sunetului transmis.Telefonul PSTN influențează prin calitatea receptorului și a microfonului, prin nivelul semnalului și prin ecoul generat între microfon și receptor. Rețeaua PSTN folosește semnalul digital. Transformarea semnalului analog în semnal digital de multe ori afectează claritatea vocii. “Gateway”-ul ce interconectează rețeaua PSTN cu rețeaua IP afectează claritatea din cauza codecurilor folosite, a componentelor ce elimină perioadele de liniște și a generatoarelor de zgomot. Rețeaua IP, deși nu are componente de voce active, afectează claritatea prin tendința de a pierde pachete și de a adăuga jitter livrării de pachete. Terminalul IP afectează și el prin codecul folosit, prin mecanismul de eliminare a perioadelor de liniște și prin calitatea microfonului și a receptorului (boxelor).

Pierderea pachetelor nu este un fenomen rar în rețelele IP. Pe măsură ce rețeua 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 când unele link-uri nu mai funcționează. Un efect similar cu pierderea pachetelor este acela când un pachet este întârziat foarte mult și ajunge prea târziu pentru a fi folosit în reconstrucția semnalului de voce.

Pentru aplicațiile ce nu sunt de timp real pierderea pachetelor nu are prea mare importanță. Protocoalele asigură mecanisme de retransmisie pentru a recupera pachetele pierdute. Totuși în cazul aplicațiilor de timp real, pachetele trebuie să sosească într-un interval bine definit de timp pentru a putea fi folosite la reconstrucția 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 aplicații. Aceste mecanisme minimizează pierderile de pachete și întârzierea pentru traficul prioritar cum este vocea. Aceste mecanisme includ scheme de priorități 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ă totuși 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ă străbătute și din cauza tipurilor diferite de rutere întâlnite care pot oferi sau nu serviciul cerut.

Un codec transformă semnalul de voce analog într-un flux digital de biți și vice-versa. Unele codecuri folosesc și tehnici de compresie, îndepărtând informația redundantă sau mai puțin importantă pentru a reduce banda necesară pentru transmisie. Cu alte cuvinte, multe codecuri comprimă semnalul de voce prin păstrarea numai acelor părți din semnalul de voce care sunt importante din punct de vedere al percepției. Acest lucru înseamnă păstrarea acelor părți care au cel mai mare impact din punct de vedere al modului cum urechea umană aude acel semnal, mai ales dacă acele părți sunt distorsionate sau omise. Depinzând de tipul de codec folosit, partea receptoare a unei conversații VoIP poate să nu reproducă semnalul original. Câteva 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ă, întârzierea și banda necesară pentru transmisie. Cu cât este mai mare reducerea de bandă necesară cu atât este mai mare cererea de putere de calcul pentru o claritate percepută a semnalului. În plus cu cât este mai mare reducerea benzi necesare cu atât întârzierea produsă de procesul de calcul este mai mare astfel crescând întârzierea globală. Alți factori care influențează efectul codecului asupra calității vocii sunt lungimea pachetului, pierderea pachetelor și orice mecanism de corecție a erorilor pe care codecul îl folosește el însuși.

Pe lângă pierderea pachetelor și codecuri mulți alți factori afectează claritatea vocii, incluzând și zgomotul, componentele ce detectează dacă se vorbește 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 tăierea din greșeală a unor porțiuni din semnal. Vocea care ajunge înapoi la vorbitor și este perceptibilă în timpul conversației poate afecta claritatea percepută. În final, un receptor poate avea o calitate excelentă dar zgomotul din cameră, starea utilizatorului, cerințele acestuia precum și alți factori pot influența un utilizator să creadă că calitatea audio percepută este inacceptabilă. Acești factori de mediu afectează metodele de testare și fac testele subiective ce folosesc oameni mai dificile.

Întârzierea reprezintă timpul necesar unui semnal să parcurgă rețeaua. În contextul telefonic întârzierea reprezintă timpul necesar ca semnalul generat la gura vorbitorului să ajungă la urechea ascultătorului. Întârzierea este suma întârzierilor provocate de echipamentele de rețea și de link-urile rețelelei prin care trece traficul corespunzător vocii. Mulți factori contribuie la întârzierea globală incluzând întârzierea generată în rețeaua PSTN, în rețeaua IP și de către echipamentele VoIP.

Întârzierea datorat transmisiei pe apelurile de distanță mare este de aproximativ 250 ms atunci când aceasta trece printr-un satelit geostaționar și reprezintă principala cauză a întârzierilor în rețeaua PSTN. În plus întârzierile datorate comutației în nodurile de rețea este mică în comparație cu întârzierea datorată transmisie. În cele mai multe cazuri întârzierea în rețelele PSTN este relativ mică și depinde în principal de distanța între capetele apelului.

Întârzierea în rețelele IP este în principal datorată de stocării în buffere, în cozi de așteptare și comutării sau rutării în ruterele IP. În special întârzierea în rețeaua de pachete este formată din întârzierea datorată procesului capturări pachetelor, comutări/rutări a acestora și așteptări în cozi de așteptare.

Întârzierea datorată capturări pachetelor reprezintă timpul necesar ce trebuie așteptat până cănd tot pachetul este primit înainte a de fi procesat și trimis spre următorul ruter. Lungimea pachetului și viteza de transmisie detremină valoarea acestei întârzieri. Folosind pachete de dimensiuni mici pe link-uri de viteze mari se poate micșora întârzierea dar eficiența rețelei ar putea scădea. Întârzierea datorată comutării/rutării reprezintă timpul în care un ruter îl folosește pentru a comuta un pachet. În acest timp echipamentul analizează antetul pachetului, verifică tabelul de rutare și trimite pachetul către portul corespunzător. Această întârziere depinde de arhitectura echipamentului de rețea și de mărimea tabelei de rutare. Cele mai noi rutere pot face lua unele decizii de rutare prin hardware și nu prin software micșorând astfel întârzierea. Datorită multiplexării statistice și a sosirilor asincrone a pachetelor este necesară folosirea de cozi de așteptare la porturile de intrare și de ieșire din rutere. Acest fapt produce o întârziere care este dependentă de încărcarea rețelei, lungimea pachetelor și distribuția statistică a pachetelor pe porturi. Proiectarea de rutere și de link-uri de mari capacități poate micșora întârzierea dar nu o poate elimina.

“Gateway”-urile și terminalele contribuie și ele în mod semnificativ la întârzierea globală din cauza procesării semnalului la ambele capete ale link-ului. În timpul necesar procesării 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 întârzierea să crească.

În partea transmițătoare, întârzierea de pachetizare – timpul necesar pentru a forma un pachet din informația audio – este un alt factor. Cu cât este mai mare pachetul cu atât se așteaptă mai mult pentru formarea unui pachet. Folosind pachete mici poate micșora întârzierea dar eficiența suferă deoarece este nevoie să se trimită mai multe pachete în rețea fiecare având un antet care nu transportă informație.

În partea receptoare, trebuie să se întârzie pachetele pentru a se compensa variațiile 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 așteptărilor în cozile de așteptare și din cauza transmisiei pe căi diferite a pachetelor. Pentru a elimina efectul jitterului se folosește un buffer în care sunt puse pachetele înainte de decodare deoarece acestea necesită pentru a funcționa corespunzător un fux de pachete constant fără găuri. Întârzierea produsă de acest buffer poate fi diminuată prin micșorarea jitterul în fiecare nod și reducerea numărului de noduri din rețea. Se poate optimiza și dimensiunea bufferului pentru a fi cât mai mic pentru jitterul existent. Folosind mecanismele ce fac traficul în timp real prioritar față de celelalte fluxuri rețeaua poate micșora considerabil jitterul.

Întârzierea nu afectează în mod direct calitatea vocii dar, în schimb, afectează caracterul conversației. Cei mai mulți utilizatori nu observă o întârziere mai mică de 100 de milisecunde. Când aceasta este între 100 și 300 de milisecunde, utilizatorii observă doar o mică ezitare în răspunsul partenerului de conversație. După 300 de milisecunde, întârzierea este clară pentru utilizatori și conversația devine din ce în ce mai dificilă. În mod evident, o întârziere mică duce la o conversație de o calitate mai bună și la o percepție mai bună a urilizatorului asupra calității generale a vocii.

Pentru a elimina ecoul nedorit, proiectanți de rețea introduc componente funcționale numite suprimatoare de ecou în centralele locale, în “gateway”-urile VoIP și în terminalele VoIP posibil cât mai aproape de locul unde se produce ecoul.

Pentru a utiliza cât mai eficient banda, rețelele VoIP folosesc o funcție numită eliminarea duratelor în care nu se vorbește sau detecția vocii. Această funcție este realizată de un element care se află în “gateway”-uri sau în terminale și care elimină pachetele corespunzătoare momentelor când nu se vorbește. Acestea operează pe partea de ieșire a unui “gateway” și se pot adapta la nivele diferite de zgomot. Deoarece conversațiile sunt de obicei, pe un termen mai lung, de tipul half-duplex folosind o astfel de funcție se poate realiza o reducere de 50% a necesarului de bandă pe cele două canale folosite luate împreună. Deși funcționarea acestora nu afectează claritatea, în cazul în care nu funcționează corect descrește în mod sigur inteligibilitatea semnalului și calitatea per ansamblu a conversației. La recepție, pentru ca cel ce ascultă să nu creadă că nu mai este nimeni pe linie în momentele în care pachetele corespunzătoare momentelor de pauză au fost eliminate, există o funcție ce generează un zgomot de fundal care trebuie să fie cât 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 Aplicație software

1. Prezentare generală

Pentru a înțelege cât mai bine funcționarea protocolului de semnalizare prezentat în lucrarea de față am realizat o aplicație care să folosescă acest protocol pentru a iniția și termina o sesiune de comunicație prin voce printr-o rețea de date.

De la început am impus anumite limitări. Nu s-au folosit sisteme mai complicate cum ar fi server-e proxy, server-e de redirectare, “gateway-uri”. Aplicația trebuia să funcționeze numai într-o rețea locală de mici dimensiuni și de aceea am trecut cu vederea problemele legate de asigurarea calității serviciilor (QoS). Transmisia vocii prin rețea a fost într-un fel pe planul doi, important fiind modul de comunicare între aplicații folosind protocolul SIP. Deoarece semnalizările se realizau pe un LAN fără alte sisteme aparținând arhitecturii SIP, s-a folosit modelul de comunicație între două terminale care își cunosc adresele de rețea și comunică direct fără intervenția altor sisteme.

Aplicația este și un exemplu cum foarte ușor 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 întâi sau pus bazele comunicației pe bază de mesaje scrise și după aceea s-au dezvoltat mecanismele de comunicație prin voce.

În realizarea părții de “chat”, obiectivele propuse au fost implementarea unei aplicații care să permită transmiterea mesajelor scrise prin metoda multicast, să prezinte lista celor care folosesc această aplicație și să permită folosirea de imagini grafice inserate în text care să exprime anumite stări emoționale (emoticoane) fără a avea o componentă centrală care să realizeze aceste lucruri. Aplicațiile discută între ele folosind un set de mesaje text trimise sub forma “/” ”cuvant cheie” ”informație”. Prin acestea ele indică intrarea unui nou utilizator, trimiterea unui nou mesaj, schimbarea nickname-ului și ieșirea unui utilizator.

Partea care este responsabilă cu implementarea VoIP a avut ca scop principal realizarea unei aplicații care să permită asigurarea comunicații prin protocolul SIP cu celelalte aplicații. Au fost implementați agenții server și client care se ocupă de trimiterea mesajelor, recepționarea ș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 rețea. S-a adoptat această soluție deoarece s-a dorește folosirea aplicației într-o rețea 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 făcut decât să complice aplicația, fără să aducă contribuții importante.

Partea grafică a aplicației folosește ferestre, butoane și zone de text cu informații despre funcționare pentru a permite o intracțiune cât mai ușoară cu un utilizator. Fereastra principală prezintă zona unde se scriu mesajele scrise de utilizatori, unde se pot scrie mesaje noi, unde se schimba numele de apelare al utilizatorului (nickname) și de unde se poate ieși din conversație. Mesajul scris de un utilizatori ajunge la toți cei care au aplicația pornită și sunt conectați, deoarece se folosește o comunicație multicast. Tot în această fereastră sunt trecute și informații despre utilizatorii ce sunt în conversație la un anumit moment dat. Aceste informații cuprind numele și adresa de rețea a terminalului folosit. Acestea pot fi folosite pentru a iniția o conversație prin voce cu persoana respectivă.

Pe lângă această fereastră principală mai sunt ferestra pentru vizualizarea unei pagini cu informații despre modul de folosire, pentru vizualizarea mesajelor trimise și recepționate, pentru conectare, pentru vizualizarea informațiilor despre aplicație, pentru inițierea unei sesiuni SIP și pentru terminarea unei sesiuni SIP.

Așa cum s-a precizat mai devreme această aplicație are posibilitatea de a înregistra mesajele trimise între utilizatori. Dacă un utilizator ia parte la o conversație acesta poate vizualiza mesajele trimise în cadrul acelei conversații din momentul intrării acestuia prin intermediul unei ferestre. Dacă dorește 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 pași necesari care trebuiesc făcuți pentru a utiliza acest program. Apoi se vor prezenta mai detaliat modul de funcționare al programului în general și apoi pe cele două direcții: partea de “chat” și partea de VoIP.

2. Modul de utilizare

După pornirea programului apare fereastră principală ce conține elementele toate elementele necesare pentru realizarea în bune condiții a unei conversații chat. Pentru a intra într-o discuție cu alți utilizatori trebuie să ca programul să fie conectat la rețea.

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 comunicația prin mesaje text și numele sub care vrea utilizatorul să fie cunoscut în conversație. Se apasă butonul și în acest moment utilizator va fi în modul conversație dacă toate informațiile au fost corecte. Succesul sau insuccesul acestei acțiuni este indicat în textul din josul ferestrei principale. Tot aici se indică o posibilă eroare întâlnită în realizarea acțiunii dorite de utilizator.

Dacă în lista utilizatorilor prezentată în dreapta apare numai numele utilizatorului înseamnă că programul funcționează dar numai el are programul de chat pornit.

Schimbarea numelui cu care apare în această listă se face folosind butonul “Change Nick”ce este plasat în fereastra principală. Succesul sau insuccesul acestei acțiuni 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 stări emoționale 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 🙂 foarte fericit :d surprins 😮

supărat(limba):p smecher 😉 supărat 🙁

dezorientat :s rușinat :$ ochelari de soare (s)

nedecis 😐 da (y) nu (n)

fată (x) băiat (z) te iubesc (l)

nu te iubesc (u) poză (p) cadou (g)

cătuși (%) floare (f) băutură (d)

floare ofilită (w) bere (b) liliac :[

messenger (m) email (e) telefon (t)

sărut (k) idee (i) adormit (s)

muzică (8) zi de naștere (^) furios :@

plâng :'( cațel (&) film (~)

curcubeu (r) soare (#) înger (a)

ceas (o) drac (6) pisică (@)

pahar (c) stea (*)

Deoarece zona de afișare permite vizionarea numai a mesajelor cele mai recente se permite citirea tuturor mesajelor trimise și recepționate în cadrul sesiunii curente prin intermediul ferestrei “Log”. Pentru a o deschide trebuie apăsate butoanele “View” și “Current Log” din bara de meniuri. Pentru a vizualiza mesajele din cadrul altor conversații trebuie să se deschidă fișierul log.txt aflat în același director unde se află și fișierele în java.

Pentru a iniția o conversație 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 rețea acestuia care va fi invitat să participe și o scurtă descriere a motivului pentru care se realizează această invitație. După apăsarea 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 conversația. Dacă se apasă butonul “No” atunci partea care a inițiat apelul este informată că apelul nu se poate realiza. Conversația se poate termina și din partea apelată și din partea apelantă prin apăsarea butonului “Kill VoiceChat” din domeniul “Acțiuni” din bara de meniu. Situația apelului în toate momentele sale este prezentată în zona din josul ferestrei principale, utilizatorul putând astfel să acționeze în cunoștință de cauza.

În orice moment se poate purta doar o sigură conversație prin voce, sosirea unei invitații noi sau trimiterea uneia va avea ca raspuns în mod automat un refuz.

Menționez că cele două aplicații sunt independente adică se poate purta o conversație prin voce chiar dacă utilizatorul nu se află conectat la sistemul de transmitere și recepție a mesajelor scrise dar unele informații necesare pentru realizarea unei conversații prin voce pot fi extrase din informațiile prezentate de program atunci când se află într-o conversație prin text. De exemplu dacă nu se indica disponibilitatea pentru purtarea unei conversații de tip “chat” prin conectare atunci nu se poate ști dacă utilizatorul dorit pentru o conversație prin voce are programul pornit. Tot prin conectare se poate afla numele și adresa de rețea a utilizatorului necesare pentru inițiarea unei conversații.

Pentru ieșirea din program ori se apasă butonul “X” din dreapta sus a ferestrei principale care va deconecta programul din conversația chat și va termina conversația activă prin voce sau poate să apese butonul “Exit” din domeniul “Actions” din bara de meniuri moment în care se vor executa aceleași acțiuni ca mai sus.

3. Descrierea claselor constituente

Acest program este format dintr-o clasă principală numită “Client” ce inițiază celelalte clase și constriuește fereastra principală și din mai multe clase secundare. Acestea sunt în general de două tipuri: clase folosite numai la partea grafică a aplicației („About”, „Help”, „Connect”, ”VoIP”, “VoipT”, ”VRing”) și clase folosite în funcționarea aplicației („Client”, „ChatArea”, „Conectare”, „Conversație”, „Recepție”, „Transmisie”, “UserAgentSIP”, “UserAgentServerSIP”, “UserAgentClientSIP”). Pe lângă acestea mai sunt prezente clase („Packet”, „AbsoluteLayout”, „AbsoluteConstraints”, ”MesajSIP”) care pot fi numite utilitare doarece sunt folosite în funcționarea celorlalte clase. Clasele „AbsoluteLayout” și „AbsoluteConstraints” sunt folosite pentru poziționarea 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 făcând parte din standard și nu au mai fost desenate în diagrama de clase.

> Clasa principală o reprezintă clasa numită „Client” care definește fereastra principală dar conține și codul ce determină modul de funcționare al întregii aplicații. Această clasă pornește un fir de execuție care în funcție de anumite stări (conectare, deconectare, conectat) se instațiază celelate clase necesare pentru comunicații. Din această clasă se inițializează și clasa ce pornește firele de execuție ce trimit și recepționează 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 funcție de rezultatul acestei acțiuni continuă cu crearea unei clase ce se ocupă cu conversația, numită „Conversație”, sau informează utilizatorul că, conexiunea nu se poate realiza.

Dacă utilizatorul dorește deconectarea (posibil numai în cazul în care avem o conexiune stabilită) clasa „Client” comandă clasei „Conversație” să se oprească și cere deconectarea clasei „Conectare”.

Mesajele ce trebuiesc trimise sunt pasate clasei „Conversație” de la care primește mesajele primite de la celelate aplicații. Aceste mesaje primite sunt pasate clasei care le afișează pe ecran (clasa „ChatArea”).

Metodele și atributele clasei „Client” pot fi văzute în figura IV.1 ( pe lângă atributele arătate mai sunt și referințele la celelalte clase prezentate precum și la obiectele grafice).

> Clasa „Conectare” este folosită la conectarea și deconectarea de la rețea în ambele situații aceasta trimițând celorlalte aplicații mesaje specifice. Are metode prin care returnează o referință la socketul de tip multicast pe care îl crează.

Metodele și argumentele sunt prezentate în figura IV.2.

Figura IV.1 Clasa Client

Figura IV.2 Clasa Conectare

> Clasa „Conversație” se ocupă cu transmiterea și primirea mesajelor, pentru aceasta folosind două fire de execuție plasate în două clase denumite „Receptie” și „Transmisie”. Pentru partea de transmisie se întreține o listă de mesaje pentru a exista siguranța că mesajele nu se pierd și pentru folosirea firului de execuție numai atunci când sunt mesaje în așteptare în listă. Clasele „Recepție” și „Transmisie” folosesc metodele clasei „Conversație” pentru a prelua și pasa mesajele. Clasa „Conversație ” folosește la rândul ei metodele clasei „Client” pentru a-i da secvențele de caractere primite de la celelalte aplicații și pentru a prelua caracterele scrise de utilizator.

Mesajele și situațiile în care se schimbă acestea sunt prezentate mai jos:

– conectare. Se trimite din partea aplicației care se conectează mesajul “/connect” la care fiecare aplicație ce primește acest mesaj răspunde cu “/nick nume(adresaIP)” unde nume reprezintă apelativul ales de fiecare utilizator iar adresaIP reprezintă adresa de rețea a terminalului folosit de utilizator.

– schimbarea apelativului. Aplicația care a primit cererea de schimbare a apelativului trimite în rețea 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 rețea.

– trimiterea de mesaje. Aplicația al cărui utilizator a scris un mesaj trimite mesajul “/msg apelativ: mesaj”. Aplicația care primește acest mesaj tipărește mesajul primit.

– deconectare. Aplicația care primește comanda de deconectare trimite mesajul “/disconnect apelativ(adresaIP)”

Metodele și variabilele claselor sunt prezentate în figura IV.3( în clasa „Conversație” pe lângă atributele arătate mai sunt și referințele către clasele Receptie și Transmisie):

> Clasa „ChatArea” reprezintă clasa prin care se afișează mesajele de la server înlocuindu-se aici codurile cu imagini. Din punct de vedere al implementării această clasă crează o imagine care este apoi desenată în fereastra principală apelându-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, funcția „scroll”, care se găsește la un „TextArea”, nu este suportată și de aceea a fost nevoie de creerea unei noi clase „Log” care poate afișa discuția dar fără a înlocui codurile cu emoticoane și care bineînțeles suportă funcția „scroll”. Clasa „Packet” este o clasă care este folosită numai de clasa „ChatArea” în cadrul metodei „paint()” și furnizează informații despre ce emoticon trebuie desenat, unde a fost găsit și câte 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 lângă afișarea discuției din sesiunea curentă și cu menținerea unui fișier „log.txt” în care se scriu toate mesajele primite plus ora și ziua la care a fost o conectare la server. Acest fișier poate fi șters de către utilizator prin intermediul unui buton pus la dispoziția acestuia. Metodele și argumentele acestei clase sunt prezentate în figura IV.5.

> „Help” afișează într-o fereastră porțiuni din acest document aflat într-un fișier numit „help.txt”.

> „About” afișează, într-o fereastră, informații despre aplicație.

> „Connect” definește o fereastră unde sunt amplasate câmpurile unde se introduc informațiile despre adresa de multicast, portul și apelativul utilizator. Tot în această fereastră se află un buton „Connect” care acționat pasează informațiile, aflate în câmpuri, clasei „Client” și o informează pe această că se dorește conectarea la calculatorul indicat.

> “VoIP” definește fereastra unde sunt trecute informațiile despre utilizatorul ce va fi invitat să participe la o conversație prin voce. Tot în acea fereastră este trecut motivul conversației. Atunci când se apasă butonul “Dial” aceste infomații sunt pasate clasei “UserAgentClientSIP”.

Figura IV.3 Clasele Conversatie, Transmisie și Recepție

Figura IV.4 Clasa Packet

Figura IV.5 Clasa ChatArea și Packet

Figura IV.6 Clasa Log

> “VRing” definește fereastra ce apare atunci când se primește din rețea o invitație la conversație. Această fereastră prezintă utilizatorului informații despre cel ce îl invită și motivul acestei invitații. Două butoane îî sunt puse la dispoziție pentru a alege dacă aceptă această invitație sau nu. Indiferent de alegere se apelează metode din clasa “UserAgentServerSIP” pentru a se trimite răspunsul.

> “VoipT” definește fereastra care apare atunci când un utilizator dorește să termine o conversație. Dacă se confirmă terminarea conversației atunci se apelează metode care să trimită mesajul “BYE” parți interlocutoare.

> “UserAgentSIP” reprezintă clasa în care se pornesc firele de execuție ce trimit mesajele SIP și recepționează aceste mesaje. După o scurtă procesare mesajele primite sunt trimise ori clasei “UserAgentServerSIP” dacă sunt cereri, ori clasei “UserAgentClientSIP” dacă sunt răspunsuri.

Figura IV.7 Clasa UserAgentSIP

> “MesajSIP” este folosită pentru extragerea valorilor câmpurilor dintr-un mesaj SIP și pentru crearea de mesaje SIP.

Figura IV 8 Clasa UserAgentClientSIP

> “UserAgentClientSIP” reprezintă clasa ce procesează răspunsurile primite de la servere prin intermediul clasei “UserAgentSIP” și care trimite clasei “MesajSIP” informațiile necesare pentru crearea de cereri SIP. Aceste cereri sunt pasate clasei “UserAgentSIP”.

> “UserAgentServerSIP” este clasa ce procesează cererile primte de la clienți ș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ă informațiile SDP.

Figura IV.11 Clasa SDP

> “CapturePlayback” reprezintă clasa ce se ocupă cu primirea informației audio de la placa de sunet, trimiterea acestei informații folosind pachete UDP, recepționarea și trimiterea acesteia spre placa audio. Firele de execuție sunt pornite ori de server, ori de client iar închiderea acestora se realizează de clasa care le-au pornit. Firele de execuție sunt încapsulate în două clase interioare acestei clase. Codecul folosit este unul dintre cele suportate de mediul Java adică frecvența de eșantionare 8000Hz, cu 8 biți pe eșantion, fără semn, stereo.

Figura IV. 12 Clasa CapturePlayback

Diagrama de clase este următoarea:

Figura IV. 13 Diagrama de clase

4. Modul de funcționare

La pornirea aplicației, clasa „Client” se ocupă cu instanțarea claselor „Help”, „About”, „Connect” și „ChatArea” dar și cu pornirea firului de execuție propriu. Diagrama de colaborare din figura următoare va prezenta acest caz:

Figura IV. 14 Digrama de colaborare în cazul: pornire execuție

Dacă se dorește conectarea, prin intermediul ferestrei definită de clasa „Connect” se aduce la cunoștința clasei „Client” că se dorește conectarea. În acest moment în interiorul firului de execuție al clasei principale se verifică dacă mai există o conexiune, caz în care acțiunea se ignoră. Dacă nu există connexiune atunci se instanțiează clasa „Conectare”, care prin crearea unui socket către server încearcă deschiderea unui conexiuni cu acesta. Dacă această acțiune se desfășoară fără probleme se instanțiază clasa „Conversație” cu fluxurile de intrare și ieșire de pe socket-ul creat. La rândul ei această clasă instanțează două clase care conțin fiecare câte un fir de execuție ce se ocupă cu unul cu recepția clasa “Receptie” și celălalt cu transmisia clasa “Transmisie”. Dacă instanța clasei „Conectare” indică că, conexiunea nu se poate realiza atuci se închide tot procesul cu un mesaj de eroare către utilizator.

Diagrama de colaborare pentru cazul în care procesul de conectare se desfășoară fără probleme este prezentată în figura IV.15.

Figura IV. 15 Diagrama de colaborare în cazul conectării fără probleme

Dacă avem o conexiune și utilizatorul scrie un mesaj sau dorește să-și schimbe nick-ul, comanda ajunge la instanța clasei „Conversație” unde este pus într-o listă de mesaje. Din această listă de mesaje este luat de către instanța 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 către instanța clasei „Recepție” putem avea următoarele diagrame de colaborare:

cazul când se primește un text scris de alți utilizatori;

Figura IV. 17 Diagrama de colaborare în cazul recepționării unui mesaj

cazul când se primește apelativele utilizatori conectați;

Figura IV.18 Diagrama de colaborare în cazul primiri unui apelativ al unui utilizator conectat

cazul în care utilizatorul dorește 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 puțin una din aceste situații instanța clasei „Client” trimite comanda de deconectare către instanța clasei „Conectare”, oprește firele de execuție din instanțele claselor „Recepție ” și „Transmisie”, șterge aria utilizatorilor conectați la același server, trimite comanda ce închide fișierul unde se înscriau mesajele primite, șterge aria unde se afișează mesajele primite, șterge câmpul „Nickname” și alte acțiuni ce țin de fereastra de afișare.

Figura IV. 19 Diagrama de colaborare în cazul în care utilizatorul comandă deconectarea

Pentru inițierea unei sesiuni VoIP utilizatorul trebuie să deschidă fereastra definită de clasa “VoIP” și să scrie acolo informațiile necesare pentru identificarea părți interlocutoare și să confirme acest lucru prin apăsarea butonului. Aceste informații sunt pasate clasei “UserAgentClientSIP” care cu ajutorul claselor “MesajSIP” și “SDP” crează mesajul SIP INVITE pe care îl pasează clasei “UserAgentSIP” împreună cu portul și adresa unde trebuie să trimită pachetul UDP. Cealaltă aplicație primește 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 observând că reprezintă o invitație deschide fereastra construită de clasa “VRing”. Aici utilizatorul indică dacă acceptă sau nu invitație și presupunând că acceptă clasa “UserAgentServerSIP” pornește firele de execuție din clasa “CapturePlayback” care încep să primească pachete audio de la placa audio și le trimit spre cealaltă aplicație și trimit pachetele primite din rețea spre placa audio. Clasa “UserAgentServerSIP” trimite prin intermediul clasei “UserAgentSIP” mesajul SIP OK care odată ajuns la “UserAgentClientSIP” determină pornirea firelor de execuție ale clasei “CapturePlayback” și trimiterea spre cealaltă aplicație 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 afișează fereastra; aici utilizatorul introduce informațiile ș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) – recepționarea pachetului

7: mesajNou(String) – după ce a determinat că mesajul este o cerere acesta este trimis clasei “UserAgentServerSIP”

8: show() – deschide fereastra care informează sosirea invitației

9: yesAction(ActionEvent) – utilizatorul răspunde afirmativ și variabilele “răspuns” și “click” sunt trecute pe valoarea “true”

10: clicked(), raspunsul() – se testează variabila “click” pană când este “true” (utilizatorul a apasat pe un buton) și apoi se cere răspunsul (presupunem ca acceptă invitația)

11: start() – se pornesc firele de execuție

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 execuție 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 dorește confirmarea utilizatorului pentru a trimite mesajul BYE care va închide sesiunea. Deoarece sesiunea poate fi închisă de oricare din cei doi participanți adică din punctul de vedere al aplicației poate fi închisă ori de server-ul SIP ori de clientul SIP. Deoarece clasa “CapturePlayback” a fost instanțiată la nivelul acestor componente, clasa “VoipT” ce definește și fereastra trimite ambelor clase comanda să trimită mesajul BYE. La nivelul acestor clase se decide cine a instanțiat clasa “CapturePlayback”, o oprește și trimite în rețea spre cealaltă aplicație mesajul SIP BYE. Acolo acest mesaj este pasat celor două clase care dacă au instanțiat clasa de captare și redare a vocii o opresc iar dacă nu au făcut 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 acțiunii

3: sendBYE() – se trimite comada de închidere a conversației și de trimitere a mesajului BYE

4: sendBYE() – se trimite comada de închidere a conversației ș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 execuție ce se ocupă cu captarea/redarea și trimiterea/recepționarea pachetelor audio

sau

8: kill()

9: send(DatagramPacket) – se trimite în rețea pachetul

10: receive(DatagramPacket) – se recepționează pachetul

11: mesajNou(String) – se pasează mesajul din pachetul recepționat

12: mesajNou(String) – se pasează mesajul din pachetul recepționat

13: kill() -se comandă oprirea firelor de execuție ce se ocupă cu captarea/redarea și trimiterea/recepționarea pachetelor audio

sau

14: kill()

Figura IV. 21 Trimiterea mesajului BYE

5. Modul de configurare

Importante pentru aplicația de față sunt porturile prin care se trimit și se recepționează mesajele scrise, pachetele SIP și pachetele audio. Două dintre acestea au fost alese și integrate în implementare. Astfel mesajele SIP se trimit și se recepționează prin portul 5060 valoare preluată din RFC ce se ocupă cu descrierea SIP. Pachetele audio se trimit și se recepționează prin portul 3234, valoare aleasă de mine. La dispoziția utilizatorilor rămâne alegerea valorii portului prin care se trimit și se recepționează mesajele scrise. Pentru funcționarea corectă trebuie ca portul ales să fie același pentru toți utilizatorii. Există și posibilitatea să se creze camere private prin alegerea de către un grup a unui port diferit de cel ales de restul utilizatorilor astfel acest grup putând trimite mesaje între ei fără ca restul să-le recepționeze (prin folosirea acestei aplicații)

6. Modalități de extindere

Felul cum a fost implementată acestă aplicație îi conferă proprietatea de a fi extinsă foarte ușor. Deoarece a fost creată din mai multe module unele complet independente, se poate schimba comportamentul acestei aplicații cu puține modificări ale claselor. De exemplu partea de conversație depinde numai de metodele ce există în clasa „Client” și de cele ce există în clasa „Conversație” și o schimbare a comportamentului în timpul conversației schimbă doar metodele din „Conversație” ce apelează pe cele din „Client”.

Schimbarea protocolului ce este folosit de aplicații pentru conectare, deconectare duce numai la schimbarea clasei „Conversație” deoarece numai aici se ține cont de acest protocol.

De asemenea și modalitatea de afișare a mesajelor se poate schimba ușor deoarece se folosește pentru acest lucru o singură metodă din clasa “Client” și clasa “ChatArea”, iar modificarea acestora se poate realiza fără dificutăți. Se poate realiza fără mare eforturi scrierea mesajelor așa 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 condiția să se păstreze aceleași denumiri. Setul de imagini se poate îmbunătății, puțându-se adăuga noi imagini și codurile aferente dar pentru aceasta trebuie modificate clasele “Pachet” unde sunt procesate codurile și “ChatArea” unde sunt încărcate imaginile.

O extindere necesară pentru această aplicație este implementarea protocoalelor RTP și RTCP pentru transmisia pachetelor audio, pentru a respecta standardele în totalitate. Aceasta se poate realiza cu scrierea de clase asemănătoare 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ă aplicația. Se poate realiza prin crearea unei liste înlănțuite care să conțină parametrii codecurilor și care să fie folosită atunci când se inițiază 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 menționat că programele realizate în Java au timpi de execuție mai mari decât programele realizate în alte limbaje și din această cauză întârzierile globale produse transmisiei de voce prin rețeaua de pachete sunt mai mari decât cele preconizate în teorie. Folosirea unor codecuri mai complicate va duce cu siguranță la întârzieri mult mai mari.

Pentru utilizarea în condiți bune într-o rețea foarte intens folosită trebuie să se adauge mecanismele IntServ, adică aplicația să fie capabilă să trimită și să proceseze mesajele PATH și RESV prin care se poate rezerva resursele necesare transmisiei în condiții bune a vocii prin LAN. Pentru mecanismul de conversației prin mesaje scrise acest lucru nu e necesar deoarece nu este o aplicație în timp real. Implementarea mecanismelor IntServ se poate realiza prin adăugarea de clase care să știe să citească și să creeze mesajele și clase care să realizeze comunicația prin rețea.

Partea de “chat” poate fi îmbunătățită prin adăugarea de camere private în care să se poată discuta fără ca mesajele să ajungă la cei din “afara” camerei. O modalitate ar putea fi introducerea în mesaj și a numelui camerei și aplicațiile să afișeze mesajele primite în funcție de camera unde se află utilizatorul și de numele camerei din mesaj.

7. Concluzii

În urma testelor funcționale s-a observat că serviciile furnizate de această aplicație nu sunt dependente de puterea de calcul a terminalului pe care rulează. Dacă se folosesc un terminal cu un procesor cu frecvența de lucru de peste 1 GHz și un terminal cu un procesor cu frecvența de lucru sub 500 MHz pe care rulează această aplicație se observă că avem aceeași calitate audio în ambele sensuri.

Această aplicație este o marturie în plus asupra ușurinței cu care se poate intergra o aplicație VoIP cu alte aplicații. În cazul de față nu a fost nevoie decât de scrierea unor clase în plus. Nu a fost nevoie deloc modificarea claselor deja existente.

În dezvoltarea acestei aplicații s-a remarcat ușurința cu care protocolul SIP a fost implementat. După cum se va observa din listarea codului s-a lucrat numai cu siruri de caractere și operații cu acestea, lucru foarte ușor de realizat. Și dimensiunea clasei este o mărturie în acest sens. Chiar dacă au fost implementate numai o parte din cererile și răspunsurile SIP, totuși se observă simplitatea claselor care i-au deciziile în privința acestora. Este nevoie numai de cunoașterea metodei sau a tipului cereri pentru a lua o decizie.

Calitatea serviciilor oferite depinde în mare măsură (dacă terminalul este unul potrivit) de serviciile oferite de rețeaua pe care funcționează aplicația 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 rețea de mici dimensiuni cu încărcare medie atunci calitatea serviciilor este bună. Dacă avem rețele de mari dimensiuni sau încărcări mari atunci calitatea este mult mai scăzută.

Așa cum se observă și din codul prezentat în anexele de la șfârșitul lucrării, această aplicație prezintă o interfață care este ușor de învățat și de folosit. Fiecare buton are asociat un text de tip “tooltip” care explică ce se va întâmpla dacă va fi folosit. Desfășurarea unei acțiuni importante cum ar fi conectarea sau trimiterea unei invitații este urmată cu scrierea unui mesaj explicativ în partea de jos a ferestrei principale. Erorile care apar sunt de asemenea afișate în partea de jos a ferestrei. În ferestrele unde utilizatorul trebuie să introducă informații, fiecare câmp are asociat un “tooltip” care îi indică sub ce formă sau ce tip de informație este cerută de program. Dacă introduce o informație necorespunzătoare (de exemplu litere în loc de cifrele ce indică portul folosit) acțiunea eșuează și în zona din partea de jos a programului i-se spune unde a greșit. În plus toate aceste zone de introducere a informației sunt trecute informații care ori sunt cele propuse spre a fi folosite (cum ar fi adresa si portul de multicast) ori dau informați în plus despre ceea ce se cere de la utilizator.

Această aplicație a fost un exercițiu util pentru mine deoarece m-a ajutat să învăț modul cum funcționează și cum se poate implementa protocolul SIP.

Anexa 1 Codul aplicației explicat

În această secțiune 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 răspunsurile SIP. Restul de cod este prezentat în Anexa 2.

„ChatArea” este responsabilă cu afișarea textului primit de la server în fereastra principală a aplicației. Ea crează o imagine în care pun textele plus emoticoanele primite 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 așa:

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ă secțiune sunt definite imaginea ce va fi desenată (bimg), (big) o instanță ce va pune la dispoziție metodele necesare pentru a desena în bimg, lista de mesaje (mesajePrimite) ce va conține mesajele date de clasa „Client”, zona și dimensiunile imaginii ce va fi desenate și imaginile ce vor fi puse în bimg atunci când se întâlnește codul unui emoticon. În continuare este scris constructorul care inițializează 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 inițializarea variabilei big cu o instanța 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 conține secvența 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 următorul cod ce este rulat doar o singură dată pe parcusul vieții clasei „ChatArea”. Problema cu afișarea imginilor a fost observată și rezolvată pe parcursul creării 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ă decât după apelul de două ori a metodei „drawImage(..)” îmi este necunoscut dar cred că are legătură cu încărcarea 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 poziția 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 numărul maxim de caractere care se pot desena dintr-un mesaj dat astfel încât să nu se depășească lățimea imaginii desenate și primind ca parametrii secvența de caractere, variabila folosită pentru desenare, lățimea și poziția de pe axa X de unde începe afișarea secvenței. Ciclul while este folosit pentru a împărți mesajul dat în secvențe de caractere ce pot fi desenate într-un singur rând. Din ciclul while se iese numai dacă lungimea secvenței de caractere rămase de desenat nu depășește lățimea imaginii din care se scade poziția de unde se începe scrierea secvenței și un spațiu ales de mine egal cu 6 pentru a nu se scrie exact până la marginea zonei de afișare. Metoda „length(String s, Graphics2D)” întoarce dimensiunea grafică a secvenței , secvență ce a fost dată ca parametru. Metoda „drawS(String,Graphics2D,int,int,int)” desenează secvența dată ca parametru începând desenarea pe axa X din poziția indicată de primul parametru întreg iar desenarea pe axa Y începe din poziția indicată de unul din ultimii parametrii și întoarce poziția pe axa Y unde a fost desenată secvența. După ce se iese din ciclul while se desenează cea mai rămas din mesajul inițial. Î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 instrucțiune 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 desenând totodată și emoticoanele corespunzătoare codului. Această metodă verifică dacă mesajul are emoticoane sau nu. Dacă nu are, desenează direct mesajul. Dacă are, desenează mesajul până la primul emoticon, desenează imaginea emoticonului și apoi metoda se apelează pe ea însăși 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-> poziția pe axa X unde s-a găsit codul emoticonului; nr-> numarul de caractere ce constituie codul; img-> va conține imaginea emoticonului; temp-> variabilă folosită pentru desenarea textului cu marginea de jos la același nivel cu marginea de jos a imaginii; pck-> inițializată cu instanța unei clase ce are ca parametrii atribute de genul x, nr, img ; str-> variabilă folosită pentru desenarea mesajului până la emoticon.

Metoda „trad(String)” returnează instanța unei clasei „Packet” dacă secvența 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 secvenței fără emoticoane textul poate fi desenat în două variante posibile. Varianta a doua de desenare se folosește pentru afișarea 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 spațiul lăsat între rânduri) deoarece dimensiunea pasată când se apelează metoda reprezintă poziția unde s-a desenat ultimul rând.

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;

}

}

Observație: dacă o imgine se desenează în punctul A, acest punct va reprezentă colțul stânga sus al imaginii; dacă un text se desenează în punctul A, acest punct va reprezenta colțul stânga jos al textului. În cazul secvenței cu emoticoane poziția 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 secvența până la primul emoticon iar în temp locul unde va fi desenat textul (se observă că textul se va desena astfel încât 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 poziționarea imaginii metoda lengthG(String, Graphics2D) ce întoarce lungimea secvenței desenate. Dacă mai sunt caractere se reia metoda. Se întoarce poziția unde a fost desenat textul.

Acum se scrie implementarea metodei ce întoarce dimensiunile grafice a unei secvențe de caractere:

private int lengthG(String s,Graphics2D big)

{

return big.getFontMetrics().stringWidth(s);

}

În continuare se scrie implementarea metodei ce întoarce numărul de caractere maxim pe care a-l trebui să-l aibă secvența dată ca parametru pentru a putea încăpea pe lățimea 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 adăugând câte o dimensiune a unui caracter și dacă se ajunge aproape de margine atunci se oprește calculul și se întoarce indexul caracterului la care s-a ajuns. Dacă sunt emoticoane se urmează același algoritm dar limita este mult mai drastică deoarece trebuiesc luate în considerare și lățimea imaginii emoticoanelor care vor fi desenate în cadrul aceluiași 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 găsit în secvența 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 comparația cu 100 deoarece atunci când se folosește constructorul fără parametrii se inițializează xCaract (atribut al clasei „Packet”) cu 100. Se observă că se returnează instanța care are cea mai mică poziție în cadrul secvenței date, deoarece ne interesează primul emoticon din secvență, nu primul în ordine alfabetică. Se mai observă ca această aplicație suportă diferite coduri pentru același emoticon (de exemplu imaginea înger se poate afișa scriind codul (a) sau (A)).

În continuare se scriu implementările 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 și referințe:

Andew S. Tannenbaum: “Rețele de calculatoare”, ediția 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 alții: “RTP: A Transport Protocol for Real-Time Applications”, ianuarie 1996, http://www.ietf.org/rfc/rfc1889.txt

RFC 2326, H. Schulzrinne, Columbia U. și alții: “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 alții: “Hypertext Transfer Protocol – HTTP/1.1”, iunie 1999, http://www.ietf.org/rfc/rfc2616.txt

RFC 2974, M. Handley, ACIRI și alții: “Session Announcement Protocol”, octombrie 2000, http://www.ietf.org/rfc/rfc2974.txt

RFC 3261, J. Rosenberg, Dynamicsoft, H. Schulzrinne și alții: “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 și alții: “Voice over IP”, publicat pe Internet, http://www.cs.columbia.edu/~abk2001/voip.pdf

Roch H. Glitho și alții: “Advanced Services Arhitectures for Internet Telephony: A critical Overview”, material publicat de către IEEE Network

Stefan Pracht și alții : “Voice quality in converging telephony and IP networks”, publicat pe Internet http://e-insite.net/ednmag/contents/images/47172.pdf