Vocea In Retele de Date

Aceasta reprezintă un factor important în diferențierea rețelelor noi apărute ce oferă servicii VoIP (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 fidelitatea 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ă calitate 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 creează 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 elimina 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 transformă semnalul analog în semnal digital, creează 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țește 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 strâns legate de dispunerea rețelei și performanța acesteia. Din această cauză, calitatea vocii este rezultatul măsură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. Ascultătorii sunt mai sensibili la distorsiunile sau atenuările ce au loc în banda 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 clarităț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țeaua sau unele link-uri devin congestionate, bufferele din rutere încep să nu mai primească pachete și acestea sunt aruncate. O altă cauză a pierderii 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 protocolul MLSP sau la setarea bitului “type of service” 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țelei 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ării 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 determină 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 utilizatorului 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 consultate pentru a scrie acest subcapitol au fost Voice Over IP Fundamentals [14] și Voice Quality in Converging Telephony and IP Networks [17].

Transportul datelor in timp real peste retele IP

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ă.

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 această 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 influenț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. Ținâ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 această metodă, cunoscută ca detecția activități vocii (“voice activity detection”), în loc să se transmită informații, voce sau liniște la fiecare 125 microsecunde, cum se face astăzi, se pot 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.

Această î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țeserea 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 acelaș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 acceptabilă 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 izocrone 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 nicio influență asupra comportării rețelei IP; acestea nu controlează în niciun fel calitatea serviciului. 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 retransmisii 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 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 făcând parte dintr-o comunicație interactivă. Printre aceste servicii sunt incluse identificarea 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 folosită 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 definită 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 identificare 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, sincronizarea 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 raportâ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 pachetele 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ă folosească 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 printr-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ă. 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 considerente 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âmpul 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). Această 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 cadrul 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 [11] ș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ții trebuie să trimită pachete RTCP, fapt ce poate crea probleme pentru conferințele pe bază de multicast de mari dimensiuni deoarece traficul RTCP va crește liniar cu creșterea numărului de participanți. Această 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 rapoartele 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 pachetele 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 conferință;

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.

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 identificator 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. Acesta este deasemenea 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 (identificatorul 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.

Raportul 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ăți 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 serverelor 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 accesul 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 eroare 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ță. Această 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ă conferință 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 infrastructura 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 acest 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 această 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 legarea 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 răspunsurilor. 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.

Informații suplimentare se regăsesc în RFC 2326 [5]

Semnalizarea.

1 Introducere.

Semnalizarea repezită 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 Telecommunications 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 protocolul 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.

2 SIP sau Protocolul de Inițiere a Sesiunii (RFC 3261).

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 Inițializare 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. Câteva dintre domeniile care suporta acest protocol sunt aplicațiile de telefonie IP și videoconferință. După cum se observă și din denumire, Protocolul de Inițializare al Sesiunii inițializează, administrează și 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 și videoconferință, însă acesta poate fi utilizat cu succes și pentru servicii de mesagerie instantanee, notificare de evenimente sau pentru administrarea altor tipuri de sesiuni de comunicare. În ceea ce privește realizarea unei legături pentru comunicație, SIP este un protocol de control care oferă servicii similare cu cele oferite de protocoalele de control existente în cazul aplicațiilor de telefonie clasică, însă realizează acest 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 privește timpul de transfer prin rețea, 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 emițător la mai mulți 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 legături SIP începe cu descoperirea unui utilizator indiferent de localizarea acestuia în rețea, pentru ca descrierea sesiunii să poată fi trimisă utilizatorului.

O caracteristică foarte importantă este dată de faptul că utilizatorul va menține același identificator, chiar dacă se va schimba locația fizică sau dispozitivul cu care acesta se conectează la rețea. Atribuirea acestui identificator unui utilizator va fi realizată de către 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 către oricare dintre terminalele care recunosc același identificator (unul, mai multe sau chiar toate).

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

2.2 SDP.

SIP folosește protocolul de descriere al sesiunii (SDP) specificat în RFC-ul 2327 din aprilie 1998 [6], 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ă descriere);

informații de contact;

orarul de activitate.

Principalul scop al descrierii sesiunii de tip SDP este să definească o sintaxă standard pentru acest 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 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. Acestea 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 început caracterele ’m=’ și continuă cu următoarea descriere de flux sau cu sfârș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.

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” [8].

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 ca 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 emiță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 invitații un mecanism mai bun este invitarea lor explicită folosind SIP.

Mai multe detalii se pot obține consultând RFC 2974 [8]

Figura I.9 Pachetul SAP

2.4 Entitățile SIP și definiții.

SIP reprezintă standardul 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 participanț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) [9]:

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ăspundă 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 modalitate prin care să se asigure rezervare de resurse.

Din cauza naturii 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 DoS (”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 aceeaș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 aceeaș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.

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 sistemul 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.

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 întreaga durată a acestuia. Prin intermediul câmpurilor „Route”(rută) și „Record Route”(rută înregistrată) 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ă le ruteze. Acest 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ă stări ș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 protocoalelor 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 (ATM Adaptation Layer 5) 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 (Tool Command Language) sau Perl, permite găsirea și corectarea greșelilor 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ă.

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 folosesc 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âmpurile, 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 de apel; de exemplu CallID:[anonimizat]) este folosit în multe scopuri. În cadrul cererilor de înregistrare și de obținere a parametrilor unui server este folosit pentru a recunoaște răspunsurile corespunzătoare cererilor. Pentru cererile de invitare și de înregistrare este folosit și pentru a detecta copiile acestor cereri. Cererile INVITE succesive cu același CallID dar cu parametrii diferiți pot fi folosite pentru a schimba în mod dinamic parametri într-o conferință. Prima parte din identificator trebuie sa fie unică pentru fiecare gazdă iar ultima parte, un domeniu sau o adresă IP a gazdei, îl face unic în toată rețeaua. Un nou CallID trebuie generat pentru fiecare nou apel.

Cseq („Command Sequence”, de exemplu Cseq: 1234 INVITE) trebuie să existe în fiecare cerere. Este format din un număr de secvență fără semn și numele metodei. Într-un apel, numărul de secvență este incrementat cu fiecare nouă cerere (cu excepția situației în care cererea este retransmisia unei alte cereri) și are la început o valoare aleatoare. Server-ul trebuie să copieze valoarea acestui câmp în toate răspunsurile ce sunt determinate de cererea ce îl conține.

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

To (de exemplu To: mihai<sip:[anonimizat]>; tag=287747). Acest câmp trebuie să fie prezent și în cereri și în răspunsuri și indică destinația dorită a cererii. 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 exemplu 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 (Ex: 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 arată că în 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 exemplul 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 servere 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 îndeplini 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 exemplele date tipul corpului mesajului este de tip S.D.P. (Session 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ă. exemplu: 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. Astfel ș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ă.

2.8 Exemple de apeluri SIP.

2.8.1 Apel propriu-zis.

În exemplul următor se vor 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 caracter italic reprezintă corpul mesajului.

C->S: INVITE sip:[anonimizat] SIP/2.0

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

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

To: Mihai<sip:[anonimizat]>

Call-ID: [anonimizat]

CSeq: 1 INVITE

Contact: <sip:[anonimizat]>

Subject: Mihai, vino repede.

Content-Type: application/sdp

Content-Length: …

v=0

o=rom 53655765 2353687637 IN IP4 128.3.4.5

s= Mihai, vino repede.

t=3149328600 0

c=IN IP4 cell.rom-tel.com

m=audio 3456 RTP/AVP 0 3 4

a=rtpmap:0 PCMU/8000

a=rtpmap:3 GSM/8000

a=rtpmap:4 G723/8000

S->C: SIP/2.0 100 Trying

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

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

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

Call-ID: [anonimizat]

CSeq: 1 INVITE

Content-Length: 0

S->C: SIP/2.0 180 Ringing

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

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

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

Call-ID: [anonimizat]

CSeq: 1 INVITE

Content-Length: 0

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

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

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

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

Call-ID: [anonimizat]

CSeq: 1 INVITE

Content-Length: 0

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

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

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

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

Call-ID: [anonimizat]

CSeq: 1 INVITE

Content-Length: 0

S->C: SIP/2.0 200 OK

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

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

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

Call-ID: [anonimizat]

CSeq: 1 INVITE

Contact: sip:[anonimizat]

Content-Type: application/sdp

Content-Length: …

v=0

o=Mihai 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:Mihai@ bucuresti.rom-tel.com SIP/2.0

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

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

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

Call-ID: [anonimizat]

CSeq: 1 ACK

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

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

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

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

Call-ID: [anonimizat]

CSeq: 2 BYE

S->C: SIP/2.0 OK

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

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

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

Call-ID: [anonimizat]

CSeq: 2 BYE

Exemplul ilustrează folosirea răspunsurilor informaționale. Aici, recepția apelului este confirmată imediat (100), apoi, după întârzieri datorate unor procesări în baza de date, se indică sunarea celuilalt participant (180) și apelul este pus într-o coadă, cu anunțări periodice ale situației. Mihai nu poate să primească decât audio PCMU și GSM. De observat că lista de codecuri ale lui Mihai poate să difere de cea a lui Teo deoarece fiecare parte trimite lista cu codecuri pe care le poate folosi la recepție. Mihai va trimite datele audio la portul 3456 al terminalului craiova.rom-tel.com, iar Teo la portul 5004 al terminalului bucuresti.rom-tel.com.

Se consideră că sesiunea media este o sesiune RTP. Astfel Mihai 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 Mihai.

2.8.2 Înregistrarea.

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

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

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

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

To: sip:[anonimizat]

Call-ID: [anonimizat]

CSeq: 1 REGISTER

Contact: <sip:[anonimizat]:3890;transport=udp>

Expires: 7200

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

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ă-i 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 servere proxy. Este de dorit ca răspunsul să parcurgă aceeași rută. De exemplu, un proxy 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 servere proxy fără stări (totuși nu toate funcțiile de bază pot fi implementate folosind entități fără 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 posibilități multiple (multiple choices) poate fi folosit atunci când utilizator identificat prim SIP URL-ul ce se află în cerere poate fi contactat la mai multe adrese. Aceste posibilități sunt trecute în câmpul „Contact” al răspunsului. Un exemplu poate fi: Contact: sip: [anonimizat], sip:[anonimizat];

Răspunsul 301 mutat definitiv (moved permanently) 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 mutat temporar (moved temporarily) î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 serviciu alternativ (alternative service) 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ătăț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 încărcare 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 parametrul „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 „gatekeeper-ul” H.323 în modul de lucru direct.

Materialul consultat pentru realizarea acestui subcapitol a fost cartea IP telephony [2].

2.10.1 Localizarea utilizatorilor și mobilitatea.

Adresele SIP sunt numite „uniform resource locators” (URL). Acestea sunt de fapt 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 mai jos:

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

SIP definește o modalitate 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 terminalului 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ă severul 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 infrastructura inteligentă a operatorului sau de către „Private Branch Exchange”(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ă regulile 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 sarcini 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ă folosească 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 mobilitatea 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ă software-ul SIP pe care îl folosește înregistrează această nouă adresă, proxy-ul va putea să trimită toate apelurile către această adresă.

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ării 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 antetul 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 [10] 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 translatate î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 mai jos:

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 interfeț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 apelul 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 serverele 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 semnalizare 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 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.15)

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 creează. Acesta trebuie să recunoască versiunea ISUP pe care a recepționat-o și să includă această informație în mesajul creat. Apoi creează 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 corespunză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. Comptabilitatea î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 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 experiență în transmisia datelor în mod multicast. SIP a fost creat pentru o rețea ce permite transmisia în mod multicast nu numai pentru fluxurile media ci și pentru semnalizare. De exemplu un mesaj INVITE poate fi trimis unui grup prin transmisie de tip multicast. Acest mod de operare este folositor unei instituții ce se ocupă cu rezolvarea prin telefon a unor probleme dar și unui utilizator care încearcă să găsească pe cineva într-o instituție. Versiunile 1 și 2 ale H.323 trebuie să folosească transmisia în mod multi-unicast pentru a realiza același lucru.

Folosirea URL-urilor ca identificatori este un lucru foarte important. La o primă privire pare să nu existe o mare diferență între un alias de tip e-mail de la H.323 ([anonimizat]) și un URL de tip SIP (sip: [anonimizat]). în realitate există doar una: un alias H.323 presupune că protocolul folosit este H.323, iar SIP specifică protocolul chiar în URL. Din această cauză un server SIP poate direcționa un apel către un server non-SIP într-o manieră foarte flexibilă. Un terminal SIP, atunci când este apelat de un alt terminal SIP, poate direcționa apelul către o pagină Web sau către un URL de e-mail.

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

Mulți furnizori de servicii doresc să aibă posibilitatea să marcheze unele apeluri ca fiind prioritare. Câmpul „Priority” din antetul SIP aduce acestuia o funcție care nu există în H.323.

Trimiterea mesajelor sub formă de text poate fi si un avantaj și un dezavantaj. Avantajele sunt: metodă simplă, se pot depista foarte ușor greșelile și se pot corecta la fel de ușor, problemele de interconectare se depistează repede. Dezavantajul principal este acela că această metodă de codare creează mesaje de dimensiuni mai mari decât dacă s-ar fi folosit mesaje codate binar.

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 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”. Acest 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 avantaje î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 implementare.

Î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.4 Interconectarea SIP – H323.

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

pe partea cu rețeaua H.323 joacă rolul de terminal H.323 și pe partea cu rețeaua SIP joacă rolul de agent server sau client;

pe partea cu H.323 joacă rolul unui Gatekeeper iar pe partea cu SIP a unui registrator și/sau server proxy.

O imagine a unei interconectări simple între cele două rețele este prezentată în figura următoare:

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

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

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

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 [11], 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.

Bibliografie selectiva

[1] http://www.informatiiprofesionale.ro/cercetare-si-dezvoltare/prezentare-voip;

[2] Olivier Hersent, David Gurle, Jean-Pierre Petit – IP Telephony, Packet-Based Multimedia Communications Systems”, Addison Wesley, 2000;

[3] Tatiana Rădulescu – Sisteme și rețele de comunicații, Ed. Tehnică, București, 1995;

[11] A. S. Tanenbaum – Rețele de calculatoare, Editura Computer Press Agora, Tg Mureș, 2004;

[13] Virgil Dobrotă – Rețele digitale în telecomunicații Ed. Mediamira, Cluj-Napoca, 2002;

[14] Voice Over IP Fundamentals http://books.google.ro/books?id=S5P7 – Xtq 7W8C&printsec= frontcover&hl=ro&source=gbs_ge_summary_r&cad=0#v=onepage&q&f=false

[16] Niculescu Grazziela – Tehnici și sisteme de comutație, Ed. Matrix Rom, București, 2001;

[17] Voice Quality in Converging Telephony and IP Networks – White Paper

[18] Recomandările ITU-T cu privire la rețelele numerice;

[19] Recomandările EUROCOM privind comutația numerică;

[20] William Stallings (2005). Cryptography and Network Security, 4th edition. Prentice Hall. ISBN 0-13-187319-3;

[21] CISCO http://www.cisco.com/web/learning/index.html

Sorina Zahan – Telefonia digitală în rețelele de telecomunicații, Ed. Albastră, Cluj-Napoca, 2002;