Analiza comunicarii 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

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=g.bell@bell-telephone.com

c= IN IP4 132.151.1.19

b=CT:64

t=3086272736 0

k=clear:manhole cover

m=audio 3456 RTP/AVP 96

a=rtpmap:96 VDVI/8000/1

m=video 3458 RTP/AVP 31

m=aplication 32416 udp wb

a=orient:portrait

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:12ef-56ac4-235ade@home.ro)

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:teo@home.ro>). 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:home@yahoo.com>; 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:adi@bucuresti.rom-tel.com SIP/2.0

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

From: Teo<sip:Teo@craiova.rom-tel.com>;tag=3

To: Adi<sip:adi@bucuresti.rom-tel.com>

Call-ID: 662606876@cell.rom-tel.com

CSeq: 1 INVITE

Contact: <sip:Teo@craiova.cell.rom-tel.com>

Subject: Adi, vino repede.

Content-Type: application/sdp

Content-Length: ...

v=0

o=rom 53655765 2353687637 IN IP4 128.3.4.5

s= Adi, vino repede.

t=3149328600 0

c=IN IP4 cell.rom-tel.com

m=audio 3456 RTP/AVP 0 3 4

a=rtpmap:0 PCMU/8000

a=rtpmap:3 GSM/8000

a=rtpmap:4 G723/8000

S->C: SIP/2.0 100 Trying

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

From: Teo<sip:Teo@craiova.rom-tel.com>;tag=3

To: Adi<sip:adi@bucuresti.rom-tel.com> ;tag=37462311

Call-ID: 662606876@cell.rom-tel.com

CSeq: 1 INVITE

Content-Length: 0

S->C: SIP/2.0 180 Ringing

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

From: Teo<sip:Teo@craiova.rom-tel.com>;tag=3

To: Adi<sip:adi@bucuresti.rom-tel.com> ;tag=37462311

Call-ID: 662606876@cell.rom-tel.com

CSeq: 1 INVITE

Content-Length: 0

S->C: SIP/2.0 182 Queued, 2 callers ahead

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

From: Teo<sip:Teo@craiova.rom-tel.com>;tag=3

To: Adi<sip:adi@bucuresti.rom-tel.com> ;tag=37462311

Call-ID: 662606876@cell.rom-tel.com

CSeq: 1 INVITE

Content-Length: 0

S->C: SIP/2.0 182 Queued, 1 caller ahead

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

From: Teo<sip:Teo@craiova.rom-tel.com>;tag=3

To: Adi<sip:adi@bucuresti.rom-tel.com> ;tag=37462311

Call-ID: 662606876@cell.rom-tel.com

CSeq: 1 INVITE

Content-Length: 0

S->C: SIP/2.0 200 OK

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

From: Teo<sip:Teo@craiova.rom-tel.com>;tag=3

To: Adi <sip:adi@bucuresti.rom-tel.com> ;tag=37462311

Call-ID: 662606876@cell.rom-tel.com

CSeq: 1 INVITE

Contact: sip:adi@bucuresti.rom-tel.com

Content-Type: application/sdp

Content-Length: ...

v=0

o=adi 4858949 4858949 IN IP4 192.1.2.3

s=vin în 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:Teo@craiova.rom-tel.com>;tag=3

To: Adi<sip:adi@bucuresti.rom-tel.com> ;tag=37462311

Call-ID: 3298420296@cell.rom-tel.com

CSeq: 1 ACK

C->S: BYE sip:adi@ bucuresti.rom-tel.com SIP/2.0

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

From: Teo<sip:Teo@craiova.rom-tel.com>;tag=3

To: Adi <sip:adi@bucuresti.rom-tel.com> ;tag=37462311

Call-ID: 3298420296@cell.rom-tel.com

CSeq: 2 BYE

S->C: SIP/2.0 OK

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

From: Teo<sip:Teo@craiova.rom-tel.com>;tag=3

To: Adi <sip:adi@bucuresti.rom-tel.com> ;tag=37462311

Call-ID: 662606876@cell.rom-tel.com

CSeq: 2 BYE

Exemplul ilustrează folosirea 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 Teo@craiova.rom-tel.com sosite la server-ul SIP rom-tel.com vor

fi redirecţionate către Teo@saturn.rom-tel.com, portul UDP 3890.

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

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

From: <sip:Teo@craiova.rom-tel.com>;tag=19

To: sip:Teo@craiova.rom-tel.com

Call-ID: 70710@saturn.rom-tel.com

CSeq: 1 REGISTER

Contact: <sip:Teo@saturn.rom-tel.com:3890;transport=udp>

Expires: 7200

3.2.9 Modul de operare

Figura I.10. Modul de operare proxy

În figurile I.10 şi I.11 se prezintă cele două moduri în care poate lucra protocolul SIP.

Astfel 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: Teo@servici.ro,sip:Teo@acasa.ro;

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:

Teo@netcentre.com:1234 Adresă SIP obişnuită

Domeniuutilizator.com Nu există partea referitoare la utilizator,

portul va fi 5060

support@company.fr:2345;

transport=UDP

Se specifică portocolul de transport

192.190.234.3:8001 Server-ul vrea sa fie contactat la această

adresă

support@netcentre.net;

maddr=239.255.255.1;ttl=32

Se indică folosirea adresei de transport în

locul adresei SIP

+33-231759329@cybercall.com;

user=phone

Număr de telefon valabil în toată reţeaua

0231759329;isub=10;postd=

w11p11@cybercall.com; user=

phone

Număr de telefon local cu subadresa ISDN

aşteaptă pentru ton, formează numărul 11

(pauză) 11 folosind tonuri DTMF

central@netcentre.net priority=

high&customercode=1234

Indică folosirea antetelor extinse pentru

controlarea priorităţii

Nouvenit@reg.grupdeutilizatori.

com METHOD=REGISTER

URL-urile precedente declanşau treimiterea

unui mesaj de invitare; acesta iniţiază o

înregistrare la registratorul grupului de

utilizatori reg.grupdeutilizatori.com

Î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

Identificatorul apelului De la Spre Operaţia Informaţia de timp

4321@192.190.12.32 Teo@home Adi@home1 INVITE 15/05/2003 11:11:12

4321@192.190.12.32 Teo@home Adi@home1 200 15/05/2003 11:11:23

4321@192.190.12.32 Teo@home Adi@home1 BYE 15/05/2003 11:12:45

4321@192.190.12.32 Teo@home Marius@home2 INVITE 15/05/2003 11:16:17

4321@192.190.12.32 Teo@home Marius@home2 200 15/05/2003 11:16:31

4321@192.190.12.32 Teo@home Marius@home2 BYE 15/05/2003 11:32:15

4321@192.190.12.32 Teo@home Andreea@home3 INVITE 15/05/2003 11:45:12

4321@192.190.12.32 Teo@home Andreea@home3 486 15/05/2003 11:45:33

4653@192.190.12.32 Teo@home George@home4 INVITE 15/05/2003 12:33:12

4653@192.190.12.32 Teo@home George@home4 200 15/05/2003 12:33:35

4653@192.190.12.32 Teo@home George@home4 BYE 15/05/2003 14:11:55

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:

Transparenţa la semnalizările SS7 Încapsularea acestora în mesajele SIP

Rutarea mesajelor ţinând cont de

semnalizarea încapsulată

Translatarea informaţiei în antetulul

SIP

Transferul semnalizărilor din timpul

apelului

Folosirea metodei INFO pentru

transportul informaţiilor din timpul

sesiunii

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:

Asemănări H.323 mai bun SIP mai bun

Calitatea

serviciilor

şi managementul

Durata iniţializării

apelului

Recuperarea pachetelor

pierdute

Lipsa posibilităţilor de

rezervare a resurselor

Toleranţa la defecţiuni

(H.323 permite

gatekeeper-i

şi terminale redundante )

Controlul admisiei (SIP

se bazează pe alte

protocolale pentru

managementul benzii,

managementul apelului

şi pentru controlul benzii)

Detecţia buclelor

(folosind câmpul

„Via” din antet

buclele sunt

identificate mai

bine decât folosind

parametrul

„PathValue” de la

H.323)

Stabilitatea şi

flexibilitatea

Procesarea fără stări

Folosirea UDP-ului

Comunicaţiile între

server-e pentru

localizarea terminalelor

Localizarea terminalelor

în alte

domenii administrative

(SIP nu defineşte o

metodă dar sugerează

folosirea DNS-ului)

Complexitatea (SIP

este mai simplu)

Extensibilitatea

(folosirea numelor

de

caracteristici şi de

coduri organizate

într-o structură

ierarhică care pot fi

înregistrate de catre

organizaţia IANA

reprezintă o metodă

de extindere mai

flexibilă decât

singurul parametru

folosit pentru extensie

„NonStandardParam”)

Uşurinţa în modificare

(este mai simplu şi

are o metodă de

codare bazată pe text)

Interconectarea Interconectarea cu

reţeaua PSTN (H.323

foloseşte mesaje de tipul

Q.931 ce sunt compatibile

cu standardul SS7)

3.3.2 Unde SIP este mai bun

SIP este simplu. Acesta face într-o 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

(Teo@nume.ro) şi un URL de tip SIP (sip: Teo@nume.ro). în realitate există doar una: un

alias H.323 presupune că protocolul folosit este H.323, iar SIP specifică protocolul chiar în

URL. Din această cauză un server SIP poate 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.

Nr. Partea H.323 Partea SIP Comentarii

1 -> Iniţializare cu FastStart Conţine informaţiile despre canalele

logice folosite pentru sensul invers

2 <- Call proceeding „Gatway”-ul indică primirea

informaţiilor

3 INVITE -> Conţine informaţiile despre porturile

pentru sensul invers în format

SDP

4 180 Ringing <-

5 <- Alerting

6 200 OK <- Utilizatorul a răspuns apelului

7 <- Connect

8 ACK ->

N BYE <- Utilizatorul a închis

N+1 <- Release

N+2 200 OK ->

N+3 -> Release complete

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

-> OpenLogicalChannel

INVITE -> Acelaşi identificator de apel ca mesajul

INVITE precedent dar cu valoarea

câmpului Cseq incrementată.

Informaţia SDP conţinută descrie lista

modificată a canalelor media

200 OK <- Se confirmă lista modificată prin

informaţia SDP conţinută

<- OpenLogicalChannelAck

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 :o

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

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