Sisteme Inteligente de Transport

CUPRINS

Introducere (VoIP și ITS)

Telefonia IP mai este cunoscută și sub numele de VoIP. Este o tehnologie care a început să schimbe modul în care oamenii comunică. Printre principalele beneficii ale telefoniei IP poate fi precizată micșorarea costurilor telefoniei clasice.

VoIP este acronimul de "Voice Over Internet Protocol" – denumire provenită din limba engleză. În limba română se traduce ca „transferul vocii prin intermediul protocolului internet” și se referă la posibilitatea efectuării de convorbiri telefonice între doi corespondenți, condiția fiind ca cel puțin unul dintre ei să posede o conexiune Internet. Întrucât tehnologia partajează rețeaua globală Internet și nu utilizează tehnologia clasică comutată, ca în cazul convorbirilor telefonice tradiționale, costul convorbirii este mult mai mic. Acest cost este resimțit cel mai bine atunci când vine vorba de distanțe foarte mari (exemplu: convorbiri internaționale). Persoana care inițiază apelul se poate afla în orice loc de pe glob și poate suna în orice țară din lume. Apelul poate fi făcut cu ajutorul unui calculator conectat la Internet sau cu ajutorul unor dispozitive hardware speciale pentru tehnologia Voice over IP (exemplu: telefoane sau videotelefoane VoIP, routere VoIP, etc).

În acest caz, apelantul folosește un calculator sau un telefon conectat la un dispozitiv de conversie voce/IP, iar apelatul răspunde la un telefon obișnuit. Semnalul vocal va parcurge marea parte a drumului către destinație sub formă de pachete IP în format standard, în rețeaua Internet. Ajuns aproape de apelat, semanlul este reconvertit în semnal vocal și introdus în rețeaua telefonică prin intermediul unui echipament "gateway" („poart”) sau "switch de telefonie". Dispozitivele hardware VoIP se aseamană cu telefoanele obișnuite dar realizează conversia vocii direct în pachete IP. Ele fac posibilă conectarea la Internet și efectuarea convorbirilor telefonice internaționale, fără a mai fi nevoie de ajutorul unui PC. Prețul unei convorbiri prin Internet este de câteva ori mai mic decât prețul unei convorbiri tradiționale. La cele două capete ale unei conexiuni VoIP se pot găsi telefoane obișnuite (conectate prin dispozitive speciale), PC-uri, telefoane VoIP sau fax-uri, în orice combinație.

Odată cu dezvoltarea tehnologiilor fără fir, a apărut și termenul VoWiFi (Voice over Wireless Fidelity – transmiterea vocii prin intermediul conexiunii fără fir). Acesta este o evoluție a VoIP-ului, permițând mobilitatea utilizatorului în aria de acoperire a dispozitivului ce oferă conexiunea fără fir.

Acronimul SIT (sau ITS, în limba engleză) provine de la „Sisteme Inteligente de Transport” și se referă la aplicații avansate dotate cu inteligență care încearcă să ofere servicii inovative în ceea ce privește diferitele moduri de transport și management al traficului. Sistemele inteligente de transport (Intelligent Transportation Systems) au ca scop oferirea unui ajutor utilizatorilor, informându-i despre metodele prin care pot utiliza mai eficient rețelele de transport.

Încă din anul 1700, în lume, și-au făcut apariția cinci revoluții tehnologice:

prima revoluție industrială (în care munca manuală a fost înlocuită de mașini)

a doua revoluție industrială (în care motorul cu aburi a fost utilizat pentru a alimenta cu energie diverse ansambluri)

era oțelului, electricității și a industrie grele (construirea de echipamente și bunuri în toate domeniile; dezvoltarea rețelei de energie electrică)

era petrolului, a automobilelor și a producției în masă

era informației și telecomunicațiilor (a condus la dezvoltarea rețelelor)

Aceasta din urmă, începută în anii 1970 prin inventarea microprocesorului, este una în plină desfășurare. În această perioadă, și în special în ultimii ani, domeniul telecomunicațiilor a avut un rol cheie în introducerea, dezvoltarea și integrarea de noi servicii în transporturi. Suportul de transmisiune cel mai des utilizat a fost rețeaua de comunicație de pachete, de tip Internet.

Din punctul de vedere al sistemelor inteligente de transport, necesitatea transferului de date și de voce între centrele de management al traficului este în creștere, căutându-se integrarea serviciilor și optimizarea acestora.

Ca urmare a creșterii traficului în aceste rețele, este de așteptat ca în primii ani ai decadei următoare acestea să transporte o cantitate de informație mai mare decât cea transportată în rețelele convenționale de telecomunicații.

Întrucât suportul de transmisiune prin Internet se află la un preț din ce în ce mai mic, permițând dezvoltarea de noi servicii atât între companii și clienții acestora cât și între companii și angajați, se observă o tendință în continuă creștere de adoptare a acesteia în ciuda câtorva dezavantaje ce sunt specifice rețelelor digitale cu comunicație de pachete: spre exemplu, fenomenele de congestie sau întârzierea variabilă a pachetelor ce poate afecta calitatea serviciilor ce necesită transmisiuni în timp real. Dezvoltarea rețelei Internet din punct de vedere al benzii de transmisiune nu se realizează uniform la nivel global, uneori condițiile locale necesită utilizarea unor algoritmi performanți de compresie. Deoarece toate sistemele de compresie folosite la ora actuală sunt sisteme cu pierderi (reducerea factorului calitate) s-au dezvoltat sisteme ce minimizează aceste pierderi.

Per ansamblu, la nivel European, din punct de vedere statistic, există o creștere constantă a necesității integrării noilor tipuri de comunicații prin intermediul ISP-urilor (Internet Service Provider).

Sisteme Inteligente de Transport (ITS)

Generalități

Sistemele Inteligente de Transport constituie un ansamblu de sisteme avansate ce au la bază elemente din domeniul electronic, al telecomunicațiilor și al tehnologiilor informației, care oferă un transport public și de mărfuri eficient.

Sistemele de Transport Inteligente sunt aplicate în cadrul tuturor modurilor de transport (rutier, feroviar, aerian, maritim și pe ape teritoriale) și au un impact important asupra transportului multimodal.

Sistemele Inteligente de Transport sunt promovate în țara noastră pentru:

a îmbunătăți siguranța în trafic;

a crește mobilitatea participanților;

a minimiza consecințele asupra mediului;

a asigura inter-operabilitatea și integrarea în rețelele europene de transport;

a eficientiza administrarea întregului proces de transport;

ITS este un tip de sistem în care componentele sale sunt complexe și, în același timp, puternic intercorelate. Arhitectura unui sistem ITS este un cadru de lucru în care pot fi dezvoltate serviciile și funcțiile ITS precum monitorizarea traficului, detectarea incidentelor, suportul pentru cazurile de urgență și alte funcțiuni. Arhitectura sistemului definește modul cum componentele sistemului sunt legate, lucrează împreună și precizează funcțiile sistemului întreg și ale fiecărei componente.

Arhitecturi ITS la nivel național

Scopul central al realizării cu succes a unui ITS la nivel național este stabilirea unei arhitecturi ITS unificate. Dacă arhitectura este proiectată cu minuțiozitate, ea va asigura dezvoltarea unui sistem compatibil la nivel național, care să conecteze toate modurile de transport. Arhitectura încurajează realizarea de standarde naționale, pentru a promova călătoriile între orașe și mișcarea mărfurilor la nivel național, împiedicând în același timp zonele locale sau regionale să dezvolte implementări ITS incompatibile. Arhitectura națională ITS permite agenților economici țintă să adopte elemente ITS într-o manieră și într-un cadru de timp ales de ei, permițând ca aceste elemente să fie livrate de mai mulți furnizori și servind ca bază pentru standarde care pot reduce eforturile depuse de grupurile de agenți economici țintă ce pot accelera procesul de introducere a produselor și serviciilor ITS și pot reduce riscurile întâmpinate de sectorul privat în dezvoltarea acestor produse și servicii.

Baza arhitecturii ITS o reprezintă un set de 32 servicii utilizator, definit de ISO (International Organization for Standardization). Serviciile utilizator reprezintă un spectru larg de servicii, incluzând sisteme avansate pentru vehicule, managementul transportului și servicii de plată electronică. Obiectivul programului național pentru dezvoltarea unei arhitecturi ITS este unificarea și organizarea serviciilor utilizator și promovarea standardelor care asigură aceeași funcționare a sistemului în întreaga țară.

Arhitectura ITS națională furnizează o structură comună pentru proiectarea sistemelor de tip ITS, fiecare dintre acestea fiind realizatpentru rezolvarea necesităților regionalespecifice, menționând în același timp beneficiile unei arhitecturi comune în cadrul sistemelor actuale cât și a celor planificate.

Arhitectura ITS națională definește funcțiile (controlul semnalelor de trafic, managementul autostrăzilor sau managementul incidentelor) ce trebuie să fie îndeplinite de către componente sau subsisteme, locul în care se găsesc aceste funcții (la marginea drumului, în centrul de management al traficului sau în vehicul), interfețele și fluxurile de informații dintre subsisteme, precum și cerințele de comunicații pentru fluxurile de informații (comunicații prin cablu sau radio).

Arhitectura ITS națională poate aduce beneficii pe termen scurt – economisirea de timp și bani în dezvoltarea unui proiect, de la faza de concepere până la implementarea acestuia.

Utilizarea arhitecturii ITS naționale și standardelor ITS va furniza, de asemenea, mari beneficii pe termen lung. Acestea vor aduce un câștig atât la nivel național, cât și regional și anume:

Interoperabilitate

Competiție mai bună

Posibilitate de extindere viitoare

Costuri mai mici

Integrare mai bună într-un sistem de transport

Natura deschisă, structura arhitecturii naționale ITS și utilizarea unor componente care să respecte standardele vor facilita integrarea componentelor complexe ale managementului traficului cu componentele altor sisteme ITS. O integrare mai bună a sistemelor proprii diverselor organizații va permite o partajare efectivă a informației și o utilizare mai eficientă a resurselor.

Arhitecturi și topologii Ethernet în ITS

Cu scopul de a micșora congestia pe șosele și de a salva vieți omenești, departamentele de transport investighează permanent soluții care să se axeze pe ideea de a face ca autostrăzile și șoselele să devină „mai inteligente”. Utilizând sistemele inteligente de transport (ITS), cercetătorii domeniului sunt capabili să monitorizeze și să reacționeze la problemele fluxului de trafic, să răspundă prin comunicații rapide la situații de urgență, să ofere o mai bună informare a călătorilor în privința problemelor de trafic și să eficientizeze traficul folosind aparate automate. Aplicațiile de rețea sunt critice pentru succesul soluțiilor ITS și cer abilitatea de a manevra multiple tipuri de date și cerințe de performanțe.

Conform definiției date de Cisco Systems, termenul de „Ethernet” se referă la o familie de produse destinate rețelelor locale de date ce funcționează sub incidența standardului IEEE 802.3 care definește protocolul cunoscut sub denumirea de CSMA/CD – Carrier Sense Multiple Access / Collision Detect.

Ethernet este o tehnologie inteligentă și în ceea ce privește raportul cost/eficiență și dispune bandă înaltă, întrunind cerințele realizării unei infrastructuri utile de rețea ITS.

Cerințele de performanță ale rețelelor sistemelor inteligente de transport sunt într-o creștere extrem de accelerată. Multe proiecte ITS noi utilizează monitorizarea video, care duce la creșterea lățimii de bandă la cerere, de la mii la zeci de mii de milioane de biți pe secundă. Datele care au o importanță critică coexistă pe aceeași rețea cu date de monitorizare cu prioritate scăzută, creând necesitatea optimizării lățimii de bandă. Este studiat și accesul de tip wireless (conexiune fără fir) spre a fi implementat în intersecțiile orașului. Informația este furnizată ua problemelor de trafic și să eficientizeze traficul folosind aparate automate. Aplicațiile de rețea sunt critice pentru succesul soluțiilor ITS și cer abilitatea de a manevra multiple tipuri de date și cerințe de performanțe.

Conform definiției date de Cisco Systems, termenul de „Ethernet” se referă la o familie de produse destinate rețelelor locale de date ce funcționează sub incidența standardului IEEE 802.3 care definește protocolul cunoscut sub denumirea de CSMA/CD – Carrier Sense Multiple Access / Collision Detect.

Ethernet este o tehnologie inteligentă și în ceea ce privește raportul cost/eficiență și dispune bandă înaltă, întrunind cerințele realizării unei infrastructuri utile de rețea ITS.

Cerințele de performanță ale rețelelor sistemelor inteligente de transport sunt într-o creștere extrem de accelerată. Multe proiecte ITS noi utilizează monitorizarea video, care duce la creșterea lățimii de bandă la cerere, de la mii la zeci de mii de milioane de biți pe secundă. Datele care au o importanță critică coexistă pe aceeași rețea cu date de monitorizare cu prioritate scăzută, creând necesitatea optimizării lățimii de bandă. Este studiat și accesul de tip wireless (conexiune fără fir) spre a fi implementat în intersecțiile orașului. Informația este furnizată utilizatorilor finali, incluzându-i pe utilizatorii de Internet, apărând, în acest fel, necesitatea de a partiționa logic rețeaua și de a ridica nivelul securității.

Protocolul de control al transmisiei/protocolul Internet (TCP/IP) reprezintă o soluție viabilă de tip end-to-end (capăt la capăt) pentru a întruni cerințele ce pot apărea, și ca rezultat, Ethernet se dezvoltă ca o arhitectură de bază a multor rețele ITS.

Aducerea tehnologiei la o singur[ linie comună în infrastructura rețelelor ITS este o convergență normală, completată cu faptul că rețeaua corporațiilor a fost dezvoltată cu un deceniu în urmă și se mută rapid către alte aplicații complexe actuale. Fabricanții telecomunicațiilor și rețelele ITS tind să facă din Ethernet o tehnologie de bază.

Arhitectura de comunicație

O arhitectură de comunicație definește și descrie mijloacele care asigură schimbul de informații dintre diferitele părți ale sistemului. Acest schimb de informații este realizat folosind fluxurile fizice de date descrise în arhitectura fizică. Arhitectura de comunicație definește și descrie mijloacele prin care sunt realizate fluxurile fizice de date pentru unele dintre „sistemele etalon” din arhitectura fizică ITS.

Descrierea și definirea acestor mijloace de realizare a fluxurilor fizice de date implică două elemente complementare. Primul element este asigurarea mijloacelor ce permit ca datele să fie transferate de la un punct la altul și siguranța că modul în care aceste date sunt transferate este corespunzător pentru sistem în ceea ce privește costul, alterarea informației și întârzierea ei. Cu alte cuvinte, problema este descrierea și definirea „canalelor de informa’iiȚ ce sunt necesare pentru transferul informațiilor. Al doilea element este obținerea siguranței că informația transmisă de la un capăt al „canalului de informații’ este interpretată fără erori la celălalt capăt, de recepție, al canalului.

Arhitectura de comunicații trebuie să rămână, pe cât se poate, independentă de tehnologie. Pentru realizarea acestui obiectiv, metodologia propusă în cele ce urmează este caracterizarea și analizarea fluxurilor fizice de date ale celor mai reprezentative „sisteme etalon” din arhitectura fizică ITS, pentru a fi satisfăcute cele mai reprezentative necesități de comunicație ale diferitelor interfețe ale sistemului.

Descrierea acestor necesități tipice de comunicații este prima țintă a arhitecturii de comunicație. Tehnologiile de comunicație se schimbă într-un ritm atât de rapid încât nu este posibilă oferirea unei arhitecturi bazate pe tehnologie care să fie valabilă pe termen lung. Alegerea modului de comunicație este deseori făcută prin procese complexe și după diferite etape de analiză. De fapt, alegerea modului de comunicație are, de cele mai multe ori, un mare impact asupra sistemului și asupra eficienței acestuia. În proiectarea unei arhitecturi de comunicație trebuie avute în vedere câteva probleme importante.

Primul aspect este satisfacerea necesităților sistemului într-o măsură cât mai mare.

Al doilea aspect este includerea efectivă a soluției de comunicație considerate într-un sistem existent.

Un ultim aspect, la fel de important, îl constituie problema costurilor. Costurile sunt legate de achiziția soluției, de migrarea de la o soluție veche la una nouă, de punerea în practică a soluției și de înlocuirea soluției. Aceste costuri trebuie să fie avute în vedere nu numai din punct de vedere al materialelor și serviciilor, ci și din punct de vedere al personalului implicat în toate aceste faze. Acest aspect este, de asemenea, foarte strâns legat de alegerile privind implementarea.

Standarde referitoare la comunicație sunt folosite de sistemele de tip ITS. Recent, a avut loc o creștere explozivă în utilizarea comunicațiilor și în alte sectoare, de exemplu în comerțul electronic. Sistemele de tip ITS nu trebuie să-și mai dezvolte propriile standarde de comunicație, cu excepția cazurilor în care este sigură folosirea unei infrastructuri proprii (private). Dacă se dorește utilizarea unor rețele de comunicații deja existente (ca de exemplu, folosirea în comun a liniilor de telecomunicații) atunci trebuie utilizate standarde stabilite la nivel internațional.

Folosirea rețelelor de comunicații existente poate fi privită și ca o economie, deoarece îi scutește pe proprietarii de sisteme de tip ITS și/sau pe operatorii ITS de sarcina de a furniza și întreține rețele proprii. Câteodată, aceste economii pot fi semnificative, deoarece încărcarea canalului de comunicație (lățimea benzii) impusă de date traficului ITS este mai mică decât cea impusă de alți utilizatori. Condiția este, așa cum a fost menționat mai sus, ca ITS să folosească standardele elaborate de către cei ce folosesc lățimile cele mai mari de bandă.

O privire mai atentă la necesitățile rețelelor actuale ITS fac ca beneficiile implementării ITS să fie clare.

Figura 1.1 – Exemplu de infrastructură ITS de tip Ethernet

În exemplul din Figura 1.1 este prezentată o infrastructură ITS capăt-la-capăt bazată pe IP. Aici, Ethernet este utilizat ca tehonologie de bază, conectând centru pentru operațiunile de trafic, traficul din intersecții, circuitele închise TV tradiționale (CCTV) peste rețelele de mod de transfer asincron (ATM) și datele livrate către Internet.

Aplicații practice ITS

Soluții de securitate a rețelei – sunt bazate pe criptare și tunelare (tunneling), capăt-la-capăt, conexiuni de rețea private peste rețele de tip terța-parte – cum ar fi Internet sau Extranet – și furnizând software pentru protecția wireless și sisteme pentru detecția intruziunilor. Securitatea este construită pe baze hardware, permițând o protecție solidă pentru întreaga rețea și oferind o mai bună securitate față de soluții de sine stătătoare punct-produs.

Soluții wireless – soluțiile de comunicație fără fir în rețelele de arie restrânsă (LAN) sunt integrate în mod transparent în rețelele existente ca servicii „wireless overlay” – adică servicii ce se adaugă opțional celor existente – sau prin crearea de rețele în totalitate wireless permițând mobilitate și crescând productivitatea rapid și la un cost eficient. Soluțiile wireless stabilesc standardele de implementare a serviciilor utile în transporturi la un nivel de performanță înalt, securizat și ușor de condus.

Soluțiile de comunicație IP – un sistem vast de soluții bazate pe IP – incluzând telefonia IP, comunicații unificate, video prin IP și conferințe audio, centre de contact – facilitează o mai mare angrenare și o interacțiune eficientă între angajați, parteneri și clienți și oferă fundamentul unei colaborări viabile. Soluția de telefonie IP extinde capacitatea rețelei de transport de a include serviciile de voce . Prin integrarea vocii, datelor și video, departamentele de transport pot folosi aceeași rețea utilizată la supraveghere video și pentru furnizarea de servicii telefonice pe marginea șoselei, soluțiile de telefonie IP minimizează disocierea serviciilor de comunicații în momentul apariției unui eveniment și sporește promptitudinea pentru intervenții.

Soluții optice de tip CWDM/DWDM – multiplexarea cu diviziunea lungimii de undă folosește multiple lungimi de undă de lumină pentru a transmite semnale prin fibra optică. În prezent, CW/DWDM este o componentă crucială a rețelelor optice deoarece maximizează utilitatea cablurilor de fibră optică instalată deja și oferă posibilitatea ca serviciile noi să poată fi ușor și rapid oferite pe piață peste infrastructura existentă. Un sistem de tip arhitectură deschisă permite unei varietăți semnificative de dispozitive să fie conectate, incluzând terminalele SONET, switch-uri ATM și routere IP. Tehnologia CWDM este bazată pe aceleași concepte WDM ca tehnologia DWDM. Cele două tehnologii diferă în principal de spațiile lungimilor de undă, numerele de canale și abilitatea de a amplifica semnalele în spațiul optic.

Routere pentru acces mobil – Optimizarea aplicațiilor pe vehicule devine o soluție de pionierat a felului în care vor comunica agențiile și de a împărți informațiile pe rețele wireless. Routerele pentru acces mobil proiectate pentru conectivitatea „always-on”, facilitează mobilitatea tuturor rețelelor și implicit a dispozitivelor de comunicație aflate în vehiculele în tranzit cum ar fi camioanele, vehiculele de urgență și automobilele.

Pentru managerii de proiecte, rețelele ITS trebuie să îndeplinească condiții de fiabilitate, disponibilitate și securitate. În același timp, elementele de rețea trebuie să furnizeze posibilități de înaltă inteligență care permit utilizatorilor finali să preia avantajele fluxului de informații disponibil. Rețeaua Ethernet inteligentă poate satisface aceste cerințe cu succes, tinzând să creeze o migrație către aceste platforme robuste.

Exemple de aplicații VoIP în ITS

În zilele noastre, utilizatorul de telefonie folosește telefonul pentru a realiza sau primi apeluri sau pentru a-și asculta mesajele vocale. Dar, în același timp, ar dori ca, în același terminal telefonic, să aibă integrare și facilități de navigare pe Internet, verificarea „e-mail”-ului, etc. Telefoanele clasice de astăzi nu pot furniza aceste facilități. În contrast cu toate aceste limitări, comunicațiile bazate pe Web au revoluționat modul de viață al fiecăruia dintre noi. Fiecare poate avea prin intermediul Internetului acces la servicii de date, multimedia, video, etc. Numai în ultimii ani, Internetul a generat mai multe inovații și soluții de comunicare decât rețeaua telefonică tradițională în întreaga sa existență. Următorul pas pe care trebuie să îl facem este ca același ritm de inovații să îl aplicăm și în telefonie și în modul de transmisie a vocii.

Rețelele de tip IP devin din ce în ce mai atractive pentru a fi folosite drept suport pentru transportul de voce. S-a avut în vedere pentru luarea acestei decizii mai ales prețul în continuă scădere al transportului de date. Ne aflăm așadar în fața unui pas important către convergența vocii, video și comunicațiilor de date prin Internet. S-a demonstrat fezabilitatea transportului de voce și semnalizării prin Internet, însă furnizarea de servicii publice și produse de înaltă calitate, dar mai ales convingerea și atragerea personalului de tranporturi către noua tehnologie sunt de-abia la început.

VoIP (Voice over IP) poate fi definită ca posibilitatea de a realiza apeluri telefonice și de a trimite fax-uri folosind rețeaua de date IP, cu o calitate sporită și un raport calitate/preț ridicat. Introducerea VoIP pe scară largă poate fi privită ca o fereastră deschisă pentru producătorii care se vor afla într-o continuă competiție, pentru furnizorii de servicii, care vor beneficia de sporirea volumului de trafic transportat, cât și pentru utilizatorii finali care sunt interesați de integrarea aplicațiilor de voce și date în scopul reducerii cheltuielilor.

Producătorii tehnologiei VoIP sunt conștienți că nu vor reuși să înlocuiască telefonia clasică, nici să realizeze o schimbare dramatică într-un timp foarte scurt. Scopul lor imediat ar fi acela de a reproduce calitățile oferite la momentul actual de PSTN (Public Switched Telephone Network – rețeaua publică de telefonie) la un preț semnificativ mai scăzut și de a oferi o alternativă viabilă acesteia. Prima măsură de succes pentru VoIP ar putea fi reducerea costurilor convorbirilor realizate pe distanțe mari. Ca o paralelă din punct de vedere strict al utilizatorului, telefonul IP are aceeași componență cu aceea a unui telefon convențional cu următoarele diferențe: realizează conversia semnalului analog / digital al semnalului vocal, este alimentat printr-un switch sau prin acumulator normal, fiind de fapt o formă de telefon cu baterie locală dar cu inteligență adăugată.

O altă aplicație imediată pentru telefonia IP este transmisia fax-urilor în timp real. Până acum, serviciile de transmitere de fax-uri foloseau în mod obișnuit conexiuni PSTN de dial-up, la viteze de 14,4 kbps. Calitatea transmisiilor prin intermediul acesta era afectată de întârzierea prin rețea, compatibilitatea mașinilor și calitatea semnalului analogic. Pentru trimiterea fax-urilor prin intermediul rețelelor de pachete, o unitate de interfață va trebui să realizeze pachetizarea datelor de transmis, conversia de semnalizări și protocoalele de control și să se ocupe de asigurarea transferului complet al datelor scanate. Pierderea de pachete și întârzierea punct-la-punct au o importanță negativă mult mai mare decât în aplicațiile de voce.

Majoritatea aplicațiilor pe suport VoIP sunt în timp real. Se așteaptă totuși și implementarea serviciilor de voce de tip store-and-forward. Un exemplu ar fi acela de prelucrare a mesajelor de voce local, care apoi să fie trimise către o căsuță poștală de mesaje vocale prin intermediul Internetului. Documentele însoțite de mesaje vocale, fișiere multimedia, etc. nu vor mai reprezenta un lucru ieșit din comun în viitorul apropiat folosind tehnologia VoIP.

ATMS

Sistemul avansat de management al traficului (ATMS – Advanced Traffic Management Sistem) este un sistem complet de management pentru transporturi și are la bază o infrastructură complexă, care conține senzori (pentru circulație, condiții meteo, vizibilitate, perturbații radio și electro-magnetice), aparate de fotografiat, camere de urmărire video și o rețea de transmisiuni de date (fibră optică, cablu și modem-uri) și echipamente de detecție a poziției exacte (GPS).

ATMS prezintă o arhitectură deschisă, realizată din subsisteme multiple care sunt reunite într-un ansamblu condus de dispecerul central de transport. ATMS are rolul de a furniza informații atât de control și monitorizare, cât și informații utile de călătorie, cu scopul de a reduce congestionările și aglomerările de trafic, timpul de călătorie și timpul de intervenție, în caz de accident. încă din faza de proiectare, s-a pus accent pe siguranța și eficiența mobilității în trafic, informațiile inițiale cerute de sistem incluzând: modul de circulație, itinerarul dorit de utilizatorul drumului și alegerea rutei, în funcție de timpul de drum.

ATMS optimizează rutele și garantează folosirea rețelei de drumuri la capacitate maximă. Totodată, reprezintă o combinație de mai multe servicii separate, printre care se numără următoarele proiecte refertoare la Sistemele Inteligente de Transport, existente sau planificate, precum și serviciile și funcțiile presupuse de acestea:

Controlul avansat al semafoarelor în funcție de cerințele traficului;

Sistem de control automat prin mesaje variabile și semnale de ghidare a rutei;

Sistem de supraveghere prin camere video;

Sistem electronic sofisticat de monitorizare a transportului;

Sistem de informații geografice (GIS) în care timpul este un element critic;

Sistem automat de informare în transporturi;

Sistem de avertizare prin radio a călătorilor (TARS – Travel Advisor Radio System);

Emisiuni de televiziune în direct, cu informații despre transport, difuzate prin cablu, acasă și la birou;

Internet;

Operațiuni integrate privind transportul și traficul;

Urmărirea poziției vehiculelor, pe baza tehnologiei GPS (Global Position System) și a altor tehnologii;

Managementul automat al parcărilor;

Sistem automat de detectare și de management al incidentelor;

Operațiuni de supraveghere aeriană cu facilitate de transmisie video în direct;

Integrarea automată cu sistemele de dispecerizare asistată de calculator ale poliției și pompierilor;

Suport pentru planificarea automată a transporturilor;

Sistem de comunicații sofistica bazat pe fibră optică;

Integrare cu sistemele viitoare automatizate pentru autostrăzi

Funcțiile ATMS

Sistemul de management al traficului (ATMS) este compus din subsisteme integrate multiple, controlate și monitorizate de Centrul de Management al Transporturilor (TMC – Transport Management Centre). ATMS are la bază o arhitectură deschisă, care folosește tehnologii de ultimă oră ale Sistemelor Inteligente de Transport, tehnologii ce furnizează un control, o monitorizare și informare în timp real asupra sistemelor de transport. Arhitectura deschisă promovează creșterea și integrarea de sisteme provenite de la mai muți vânzători.

Funcțiile ATMS sunt:

Control:

Sistem de semnalizare care să răspundă la cerințele traficului;

Semnalizarea variabilă a benzilor de circulație (LUS – Light Unit System);

Semnalizarea variabilă a limitelor de viteză;

Măsurarea rampelor.

Monitorizare:

Detecție (bucle inductive, microunde, vedere din mașină, etc.);

Sistem de camere video de supraveghere a traficului;

Sistem de monitorizare aeriană a traficului;

Sistem de examinare a vehiculelor (autobuze, vehicule de provincie, taxiuri, etc.);

Echipe de supraveghere a traficului;

Managementul parcărilor;

Rețea de senzori meteorologici și ai stării drumului;

Post mobil de managemen al traficului.

Informare:

Sistem de avertizare prin radio a călătorilor (Traffic Advisory Radio System- TARS);

Televiziune prin cablu;

Difuziune publică (televiziune și radio);

Internet/Intranet;

Servicii de televiziune prin satelit;

Servicii de informare asupra traficului;

Chioșcuri de informare;

Dispecerat de avertizare telefonică a călătorilor (TATS – Travel Advisory Telephone System);

Servicii de comunicație prin dispozitive la bord, telefonie celulară, paging;

Panouri cu mesaje variabile și semnale de ghidare a rutei.

Interconectarea calculatoarelor și rețelele VoIP

Integrarea comunicațiilor cu rețelele de calculatoare reprezintă o tendință modernă de integrare a serviciilor telefonice tradiționale prin migrarea către generația nouă de echipamente. Aceasta are ca scop final îmbunătățirea calităților serviciilor și reducerea costului acestora.

OSI este un model de referință ce se bazează pe o propunere dezvoltată de Organizația Internațională de Standardizare (International Standards Organization) ca un prim pas către standardizarea internațională a protocoalelor folosite pe diferite niveluri.

În modelul OSI există șapte nivele (fiecare nivel realizează servicii pentru cel aflat deasupra sa). Deoarece nu specifică serviciile și protocoalele utilizate la fiecare nivel, nu reprezintă în sine o arhitectură de rețea. Acest model explică diferența dintre cele trei concepte esențiale: Servicii, Interfețe și Protocoale – folosite și de modelul utilizat de tehnologiile actuale – TCP/IP.

Protocoalele au fost inventate după ce a fost conceput modelul de referință OSI (Figura 3.1). Ordinea respectivă semnifică faptul că modelul este destul de general și nu a fost orientat către un set specific de protocoale.

Modelul OSI

Figura 3.1 – Modelul OSI

Nivelul 1 – fizic (phisical layer)

Nivelul fizic transmite biții printr-un canal de comunicație. În momentul în care unul din capete transmite un bit de 1, acesta trebuie receptat în capătul celălalt ca un bit de 1, nu de 0.

Problemele tipice se referă la câți volți trebuie utilizați pentru a reprezenta un 1 și câți pentru un 0, dacă transmisia poate avea loc simultan în ambele sensuri, cum este stabilită conexiunea inițială și cum este întreruptă când au terminat de comunicat ambele părți, câți pini are conectorul de rețea și rolul fiecărui pin. Aceste aspecte de proiectare au o legatură strânsă cu interfețele mecanice, electrice, funcționale și procedurale, ca și cu mediul de transmisie situat sub nivelul fizic.

Nivelul 2 – legătură de date (datalink layer)

Principalul obiectiv al nivelului legătură de date este de a transforma un mijloc oarecare de transmisie într-o linie care să fie disponibilă nivelului rețea neexistând erori de transmisie nedetectate. Această sarcină se realizează prin obligarea emițătorului de a descompune datele de intrare în cadre de date, să transmită cadrele secvențial și să prelucreze cadrele de confirmare trimise înapoi de către receptor.

Nivelului fizic acceptă și transmite un flux de biți, fără să se preocupe de semnificația sau de structura lor, tocmai de aceea responsabilitatea pentru marcarea și recunoașterea delimitatorilor între cadre îi revine nivelului legătură de date. Atașarea unor șabloane speciale de biți la începutul și la sfârșitul cadrului este soluția pentru realizarea acesteia. În cazul în care șabloanele speciale de biți pot apărea accidental în datele propriu-zise, trebuie luate măsuri speciale de precauție pentru ca aceste șabloane să nu fie incorect interpretate ca delimitatori de cadre.

Apariția unui zgomot apărut pe linie poate distruge un cadru în totalitate. În acest caz, programele nivelului legătură de date de pe mașina sursă pot să retransmită cadrul. Transmiterile multiple ale aceluiași cadru introduc posibilitatea cadrelor duplicate. Un cadru duplicat poate apărea la transmisie în situația în care s-au pierdut cadrele de confirmare trimise de către receptor înapoi către emițător Rezolvarea problemelor deteriorate de cadrele deteriorate, pierdute sau duplicate revine în sarcina nivelului legătură de date. Acesta poate oferi nivelului rețea câteva clase de servicii diferite, fiecare de o calitate și un preț diferit.

O altă problemă ce poate apărea la nivelul legătură de date, dar și la nivelurile superioare este evitarea flood-ului (inundare) unui receptor lent cu date provenite de la un emițător rapid. Pentru a rezolva aceste probleme sunt necesare mecanisme de reglare a traficului care să permită emițătorului să afle cât spațiu tampon deține receptorul la momentul în care dorește să transfere informații.

Nivelul 3 – rețea (network layer)

Nivelul rețea se referă la controlul funcționării subrețelei. O problemă principală în proiectare este determinarea modului în care pachetele sunt direcționate de la sursă către destinație. Direcționarea se bazează pe tabele statistice care sunt schimbate rar.

Se pot stabili traseele la începutul fiecărei conversații. Dirijarea poate fi dinamică, traseele determinându-se pentru fiecare pachet în concordanță cu traficul curent din rețea. În cazul în care în subrețea există foarte multe pachete simultan, ele vor intra unul pe traseul celuilalt, provocându-se astfel blocări. Nivelul rețea controlează astfel de congestii.

Există o funcție de taxare a traficului înglobată în nivelul rețea, ajutând operatorii subrețelei să-și acopere costurile. Programul trebuie cel puțin să numere câte pachete, sau câte caractere, sau câți biți a trimis fiecare client pentru a calcula suma datorată de clienții rețelei.

Nivelul 4 – transport (transport layer)

Principalul rol al nivelului transport este de a accepta date de la nivelul sesiune și să le descompună dacă este necesar, în unități mai. Un alt rol important este transferul acestor unități nivelului de rețea, asigurându-se că toate fragmentele sosesc corect la celălalt capăt. Toate acestea trebuie făcute într-un mod eficient izolând nivelurile de mai sus de inevitabilele modificări aduse tehnologiilor echipamentelor.

În parametrii normali, nivelul transport creează o conexiune de rețea diferită pentru fiecare conexiune în parte cerută de nivelul sesiune. Există posibilitatea ca o conexiune de transport să necesite o productivitate mare. În cazul acesta, nivelul transport poate să creeze conexiuni de rețea multiple și să împartă datele prin conexiunile de rețea astfel încât productivitatea să fie marită. În cazul în care crearea și întreținerea unei conexiuni de rețea este costisitoare, nivelul transport poate reduce costul prin multiplexarea unor conexiuni de transport pe aceeași conexiune de rețea. Indiferent de cazuri, nivelului transport trebuie să facă multiplexarea transparentă pentru nivelul sesiune.

Un alt rol al nivelului transport este de a determin ce tip de serviciu să furnizeze nivelului sesiune și utilizatorilor rețelei. Cel mai comun tip de conexiune transport este un canal punct-la-punct fără erori ce furnizează mesajele în ordinea în care au fost trimise. Există și alte modele posibile de servicii de transport, precum transportul mesajelor individuale (nu există garanție legate de ordinea de livrare) și difuzarea mesajelor către destinații multiple. În momentul stabilirii conexiunii se determina si tipul serviciului..

Nivelul transport, spre deosebire de multiplexarea mai multor fluxuri de mesaje pe un singur canal, trebuie să se ocupe și de stabilirea sau anularea conexiunilor în rețea. Pentru acest lucru să fie posibil, este nevoie de un mecanism de stabilire a numelor, astfel încât un proces de pe o mașină oarecare să poată alege cu cine vrea să converseze. Totodată, este necesară existența unui mecanism prin care să se regleze fluxul de informații, astfel încât o gazdă care este mai rapidă să nu suprasolicite o gazdă lentă. Un asemenea mecanism se numește controlul fluxului și joacă un rol important în nivelul transport. Controlul fluxului între gazde nu este asemănător cu controlul fluxului între routere.

Nivelul 5 – sesiune (session layer)

Nivelul sesiune permite utilizatorilor de pe dispozitive diferite să stabilească sesiuni între ei. La fel ca la nivelul transport, o sesiune permite transportul obișnuit de date, dar furnizează în același timp și servicii utile în anumite aplicații.

Controlul dialogului este unul din serviciile la nivel sesiune. Sesiunile pot decide să se realizeze trafic, simultan în ambele sensuri, sau doar într-un sens odată. În cazul în care este permis traficul într-un singur sens odată, nivelul sesiune poate interveni prin evidențierea cărora le vine rândul să transmită. Un serviciu înrudit este gestionarea jetonului. În anumite protocoale este important ca cele două capete să nu încerce aceeași operație în același timp. Pentru a evita aceste situații, nivelul sesiune dispune de jetoane ce pot circula între mașini. Doar dispozitivele care au jetonul au voie să realizeze operația critică.

Sincronizarea este un alt serviciu ce aparține sesiunii. În momentul când se încearcă să se transfere între două dispozitive, în condițiile în care transferul durează mai mult decât intervalul mediu de cădere al legăturii, vor exista probleme. După fiecare eșec, transferul va trebui inițiat iarăși, în totalitate și probabil că nu va avea succes nici în încercarea următoare. Pentru a elimina această problemă, nivelul sesiune introduce în fluxul de date puncte de control, astfel încât după un eșec trebuie să se reia doar transferul datelor după ultimul punct de control.

Nivelul 6 – prezentare (presentation layer)

Nivelul prezentare, spre deosebire de nivelurile inferioare, care se ocupă doar de transferul sigur al pachetelor dintr-un capăt în altul, realizează realizează sintaxa și semantica informațiilor transmise.

Unul din rolurile nivelului prezentare este codificarea datelor într-un mod prestabilit, standard. Marea majoritatea a programelor ce sunt folosite de utilzatori, nu fac schimb de șiruri aleatoare de biți, ci fac schimb de nume de persoane, adrese, date etc.

Calculatoarele au coduri diferite pentru reprezentarea șirurilor de caractere (precum ASCII și Unicode), întregilor și asa mai departe. Pentru exista comunicare între calculatoare cu reprezentări diferite, structurile de date pot fi definite într-un mod abstract, alături de o codificiare standardizată ce va fi utilizată „pe cablu”.

Nivelul 7 – aplicație (application layer)

Nivelul aplicație conține o varietate de protocoale frecvent utilizate. De exemplu, există foarte multe tipuri de terminale incompatibile. O modalitate de a rezolva această problemă este prin definirea unui terminal virtual de rețea abstract și să se descrie editoare compatibile cu acesta. Pentru a nu exista incompatibilități atunci când se lucrează cu un tip de terminal, este necesară existența unui program prin care să se pună în corespondență funcțiile terminalului virtual de rețea și terminalul real.

Transferul fișierelor este un alt rol al nivelului aplicație. Sistemul de fișiere diferite au convenții de nume diferite, feluri diferite prin care se reprezentă liniile de text etc. Pentru a face posibil transferul unui fișier între două sisteme de fișiere diferite, trebuie rezolvate incompatibilitățile și altele de același gen. Acest rol îi revine nivelului de aplicație.

În Figura 3.2 este prezentat un exemplu de transfer al datelor folosind modelul OSI. Gazda A transferă date Gazdei B. Emițătorul furnizează datele nivelului aplicație, acesta le atașează în fața antetul aplicației, AH (există posibilitatea să fie vid) și le furnizează rezultatul nivelului de prezentare.

Figura 3.2 – Transmiterea datelor în modelul OSI

Nivelul prezentare poate să modifice acest obiect în diferite moduri și poate, eventual, să-i adauge în față un antet, furnizând rezultatul către nivelul sesiune. Este important de știut ca nivelul prezentare nu cunoaște care porțiune din datele primite de la nivelul aplicație reprezintă AH, în cazul în care acesta există, și care porțiune reprezintă datele propriu-zise ale utilizatorului.

Ideea de bază este că, deși în figură transmiterea datelor este verticală, fiecare nivel este programat ca și cum transmiterea ar fi orizontală. De exemplu, atunci când nivelul transport emițător primește un mesaj de la nivelul sesiune, el îi atașează un antet de transport și îl expediază nivelului transport destinație.

Modelul TCP/IP

Cele mai importante protocoale din suita TCP/IP sunt TCP și IP. Acest model a fost transformat în standard pentru Internet de către Secretariatul pentru Apărare al Statelor Unite și permite interconectarea rețelelor. Spre deosebire de OSI care definește șapte nivele pentru proiectarea rețelelor, modelul TCP/IP folosește doar patru din ele, după cum se poate observa și în Figura 3.3.

Figura 3.3 – Comparație OSI – TCP/IP

Întrucât aplicațiile standard sunt mereu diversificate, această parte – nivelul aplicație – este mai puțin stabilă. Familia de protocoale TCP/IP are și o parte stabilă, dată de nivelul Internet și de nivelul Transport.

În ceea ce privește nivelul gazdă la rețea (echivalentul nivelului fizic și legătura de date din modelul OSI), cel mai de jos nivel din cele patru, acesta este mai puțin dependent de TCP/IP și mai mult de driverele de rețea și cele ale plăcilor de rețea.

Din punct de vedere al unei rețele globale, orice sistem de comunicații ce are capacitatea de a transfera date este privit ca o singură rețea. Acesta este un concept fundamental pentru rețelele TCP/IP rezultat din faptul că protocoalele din familia TCP/IP tratează toate rețelele la fel.

Rolul nivelului Internet este de a transmite pachetele de la sistemul sursă la sistemul destinație, utilizând funcțiile de comutare. Cel mai cunoscut protocol de la acest nivel este IP. Rolul nivelului Transport este de a asigura comunicația între programele de aplicație iar nivelul aplicație asigură utilizatorilor o gamă largă de servicii, prin intermediul programelor de aplicații.

Nivelul 1 – gazdă la rețea (network interface)

Protocoalele de la acest nivel evoluează extrem de rapid datorită dezvoltării rapide a tehnologiilor de comunicație. Acestea din urmă introduc tipuri de legătură cu viteze din ce în ce mai mari așa încât se pot întâlni linii telefonice închiriate care lucrează la viteze de 57,5 kbps, dar și fibre optice de 1,544 Mbps. Majoritatea calculatoarelor actuale care folosesc TCP/IP în rețele locale utilizează legături Ethernet cu viteze ce ajung la 10 Mbps. Creșterea vitezelor la 100 Mbps s-a realizat odată cu apariția rețelelor FastEthernet. La nivelul „gazdă la rețea” se folosesc două protocoale pentru conectarea la Internet cu ajutorul modemului:

SLIP (Serial Line Internet Protocol). SLIP este protocolul Internet pe linie serială ce permite legături seriale asincrone. Este cel mai vechi protocol. Acesta este un standard neaprobat ce are câteva lipsuri: nu poate face corecție sau detecție a erorilor și suportă doar IP – un calculator trebuie să cunoască dinainte adresa IP a celuilalt calculator. Un utilizator obișnuit trebuie să rețină doar faptul că acest tip de legătură are nevoie de o adresă IP fixă ce trebuie primită de la ISP (frunizorul de Internet).

PPP (Point to Point Protocol). Acest protocol acoperă minusurile pe care le are protocolul SLIP (face detecția erorilor, cunoaște mai multe protocoale, permite ca adresele IP să fie stabilite în momentul conectării la Internet, oferă posibilitatea autentificării și altele) și este, oficial, un standard Internet. Protocolul punct-la-punct este extrem de folosit și pentru faptul că permite conexiuni atât pe legături seriale sincrone, cât și pe legături asincrone.

Nivelul 2 – internet

La nivelul Internet din stiva TCP/IP, se transmit pachete cu ajutorul adreselor unice, numite și adrese Internet ce sunt specifice fiecărui nod. Acest nivel este corespondentul nivelului rețea din stiva OSI. Principalul protocol este IP (Protocolul Internet) iar caracteristica de bază este că fiecare pachet se consideră ca fiind o entitate independentă de alte pachete. Tot la acest nivel se face comutarea de pachete în Internet. La acest nivel sunt îndeplinite funcții de segmentare și reasamblare a pachetelor și comutarea lor în Internet.

Alte protocoale de transmisie ce se găsesc la nivelul acesta sunt:

ICMP (Internet Control Message Protocol). Protocolul IP furnizează un serviciu fără conexiune prin care nu se garantează livrarea pachetului la destinație. Pentru a înlătura acest dezavantaj se folosesc mecanisme prin care routerele din rețea transferă informații cu privire la situațiile de funcționare (anormală, destinație ce nu poate fi accesată, îngreunarea unui router cu prea multe procese, etc.). ICMP poate fi folosit de un sistem pentru a verifica accesibilitatea altui sistem.

ARP (Address Resolution Protocol). Transmiterea unui pachet de la un dispozitiv la altul se poate realiza și dacă cele două sisteme se află în aceeași rețea fizică. Un dispozitiv sursă verifică dacă dispozitivul destinație se află în aceeași rețea fizică prin compararea adreselor IP (verifică, prin protocolul ARP, dacă IP-ul destinație este același cu propria adresă IP). Se poate spune că protocolul ARP permite unui calculator să afle adresa fizică unică (MAC) a unui alt calculator din aceeași rețea fizică dacă se cunoaște adresa IP (de rețea) a acestuia. Tabelele de translatere ARP nu sunt disponibile direct aplicațiilor sau utilizatorilor. ARP-ul menține lista corespondențelor între adresele MAC și cele IP. Ceea ce trebuie reținut despre acest protocol este că în momentul în care calculatorul sursă și cel destinație se află în aceeași rețea fizică, ARP-ul le ajută să se detecteze reciproc fără a fi nevoie de intervenția unui router.

RARP (Reverse Address Resolution Protocol). Dacă un calculator nu își cunoaște propria adresă IP, cu ajutorul RARP-ului, acesta o poate afla pe baza adresei fizice (este practic operația inversă protocolului ARP).

Nivelul 3 – transport

Acest nivel este gândit în așa fel încât să permită conversații între entitățile pereche din gazdele sursă și, respectiv destinație. Există două protocoale de transport ce sunt utilizate aplicații, alegerea unuia sau altuia depinzând de necesitățile impuse de fiecare aplicație în parte.

Cele două protocoale sunt:

UDP (User Datagram Protocol). Este un protocol nesigur, dar cu viteză de transmisie mare. El folosește datagrame pentru transferul datelor. Când este folosit protocolul UDP, comunicația este realizată prin serviciu fără conexiune (nu se stabilește un circuit între dispozitivul sursă și cel destinație), folosind IP pentru transferul mesajelor. Acest protocol nu garantează că pachetele trimise ajung la recepție fără a avea erori sau pierderi, fără a ajunge duplicate sau exact în ordinea în care au fost trimise, dar permite identificarea sistemelor sursă și destinație și oferă o viteză mult mai mare decât în cazul TCP (tocmai din cauza securității scăzute).

TCP (Transmission Control Protocol). Contrar UDP, este un protocol sigur, care oferă transferul fiabil al informațiilor între aplicațiile de pe două calculatoare care comunică între ele. Acest protocol realizează depistarea și corectarea erorilor care pot apărea la transmisie. TCP-ul de pe calculatorul sursă realizează o conexiune cu cel de pe calculatorul care recepționează, acestea negociind cantitatea de date ce va fi transmisă, ansamblul fiind cunoscut sub denumirea de circuit virtual. Acest dialog între dispozitive se numește comunicație orientată pe conexiune. TCP este o conexiune full-duplex, foarte stabilă și precisă, cu numărare de jetoane la recepție și corecție de erori. Protocolul TCP preia blocuri de pachete, pe care le separă în segmente, iar aceste segmente sunt numerotate. La destinație, protocolul TCP existent acolo va reasambla datele primite de la dispozitivul sursă și le va așeza în ordinea corespunzătoare. După trimiterea fiecărei secvențe, protocolul TCP emițător așteptă confirmarea de primire de la receptor, iar în cazul în care nu primește această confirmare, retransmite segmentul. Aceste metode de securitate îngreunează procesul și de aceea TCP-ul nu este recomandat și nu este folosit în aplicațiile pentru transferul de voce sau video. TCP-ul este folosit doar atunci când fiabilitatea este foarte strictă deoarece acest protocol, cu toate protecțiile lui, întârzie extrem de mult transmisia de date.

Nivelul 4 – aplicație (application layer)

Nivelele aflate sub nivelul aplicație sunt utile pentru a asigura transportul sigur, dar ele nu îndeplinesc o funcție anume pentru utilizatori. La nivelul acesta se regăsesc toate aplicațiile pentru utilizatori. Chiar și la aici apare sunt necesare protocoale care să permită funcționarea aplicațiilor.

Arhitectura VoIP

“Voice over IP” este o tehnologie care oferă o alternativă modului de transmisie a vocii, în special, și a altor servicii oferite de rețeaua de comutație de circuite.

VoIP a trebuit să-și facă loc pe piață, oferind cel puțin la fel de ieftin aceleași calitate a serviciilor de voce, să se integreze în sistemul de comunicație și să-și pună la punct metode de colaborare, în principal, tocmai cu rețeaua telefonică, ale cărei servicii i le concurează și cărora le oferă alternativă.

Obiectivele de realizat pentru o bună funcționare ar fi:

Controlul apelului și al semnalizărilor diferite în cele 2 rețele de transport, astfel încât utilizatorului obișnuit să-i fie indiferent pe ce suport se transmite semnalul vocal.

Intercomunicarea și interoperabilitatea echipamentelor celor 2 rețele, PSTN (Rețeaua telefonică de telefonie publică cu comutare de circuite) și rețeaua de pachete, de tip IP. Acest lucru implică folosirea unor punți (gateway), care au rolul de a realiaza trecerea de la modul diferit de trasmisie a datelor în cele 2 rețele.

Managementul sistemelor, adresarea, securitatea și permisiunea de acces care trebuie asigurate din ambele părți.

Odată cu proiectarea și implementarea de produse VoIP, au trebuit concepute și publicate o multitudine de noi standarde, cu ajutorul cărora au făcut ca sistemele VoIP să conțină mai multe plane funcționale. Aceste plane nu fac altceva decât să aducă soluții structurate transportului de voce și interoperabilității cu celelalte rețele de date.

Modulul de procesare a vocii funcționează de regulă într-un DSP (Digital Signal Processor), pregătește toate cele necesare pentru transmisia vocii în rețeaua IP. Funcțiile sale realizează eliminarea ecoului, compresia de voce, detecția pauzelor în discursul telefonic, eliminarea jitter-ului, sincronizarea ceasului și pachetizarea vocii.

Modulul de realizare a semnalizării telefonice – interacționează cu echipamentele telefonice, translatând semnalizările telefonice în schimbări de stare, folosite de către modulul de protocoale de rețea pentru stabilirea, menținerea și eliberarea conexiunilor. Schimbările de stare sunt ridicare de receptor, terminare apel, etc. Acest software suportă de regulă semnalizări E&M de tipul I, II, III, IV, V, FXO, FXS, ISDN acces de bază și acces primar.

Modulul de protocoale de rețea – procesează informațiile de semnalizare și le convertește din semnalizări specifice rețelei telefonice în protocoale de semnalizare în mod pachet, folosite la stabilirea conexiunilor în rețeaua IP (ex: Q.933). De asemenea, adaugă headere pacheteleor de voce și de semnalizare înainte de a fi transmise.

Modulul de management a rețelei – asigură interfața de gestiune a vocii, pentru menținerea și configurarea celorlalte module ale sistemului. Pachetul software este partiționat pentru a asigura o interfață bine definită către aplicația ce rulează în DSP, utilizabilă pentru mai multe aplicații și protocoale de pachetizare. DSP-ul procesează eșantioanele de voce și transmite pachetele de voce microprocesorului însoțite de header-ele generice de voce.

Microprocesorul se ocupă de transferul pachetelor și adaptarea header-elor generice în header-ele specifice protocolului de transport în timp real al pachetelor de voce (ex: Real Time Protocol – RTP). Microprocesorul realizează și procesarea informațiilor de semnalizare și le convertește din protocoalele de semnalizare telefonică în protocoale de semnalizare în rețeaua de pachete (ex: H.323).

Tipuri de conexiuni

Tehnologia VoIP a avut parte de o dezvoltare rapidă. Ea are rolul de a integra serviciile de transport de voce în rețelele de tip IP și de a realiza o bună comunicare cu rețeaua publică de telefonie PSTN. Această conexiune cu rețeaua PSTN este evidențiată și în Figura 3.4.

Figura 3.4 – Model de conexiune

În modul tradițional de funcționare al serviciilor de telefonie publică, până acum apelurile se realizau prin stabilirea unor canale virtuale de-a lungul rețelei de comutație de circuite, care erau apoi folosite pentru transmiterea vocii. Semnalul vocal urma același traseu stabilit în faza de inițializare a apelului, traseu virtual care la sfârșitul comunicației este eliminat din funcționarea sistemului.

Tehnologie VoIP oferă mai multe modalități de conexiune pentru realizarea apelului și transferului de voce. Ele pot fi:

PC–PC – legătură telefonică între 2 calculatoare echipate cu software adecvat comunicațiilor de voce în timp real și cu hardware specializat pentru comunicații de voce (placă de sunet, microfon, căști audiție). Conexiunea se poate realiza folosind numai Intranet-ul privat al companiei, sau rețeaua publică de pachete IP.

PC–Telefon – legătură telefonică între un calculator multimedia și un post telefonic obișnuit, abonat al rețelei publice. Comunicarea se face în mod pachet folosind rețeaua Intranet, ieșind apoi în rețeaua publică IP, iar apoi, prin intermediul dispozitivelor de intercomunicație (gateway), datele reprezentând vocea sunt transferate rețelei telefonice cu comutare de circuite și apoi postului telefonic dorit.

Telefon–telefon – legătură telefonică între 2 posturi telefonice normale. Diferența este că legătura de comunicație se realizează astfel încât semnalele de voce traversează o rețea publică sau privată IP și revin apoi în rețeaua telefonică, pe traseul lor către destinație.

Aceste conexiuni sunt evidențiate în Figura 3.5.

Figura 3.5 – Conexiuni punct-la-punct

Inițierea apelurilor

Calea de voce într-o conexiune VoIP este dependentă de crearea unei sesiuni RTP (Real-time Transport Protocol). Pentru realizarea unei convorbiri sunt necesare două sesiuni deoarece fiecare sesiune RTP transportă vocea unidirecțional. În Figura 3.6 este prezentat modul de formare a sesiunii RTP în timpul inițierii apelului.

Figura 3.6 – Inițierea apelului și negocierea parametrilor

Pentru o bună funcționare , crearea unei sesiuni RTP nu este îndeajuns în timpul inițierii unui apel. Punctele terminale trebuie să stabilească de comun acord o serie de parametri ce vor fi utilizați pe durata convorbirii. În caz contrar, apelul este intrerupt.

Pentru finalizarea procesului de inițiere a apelului, următorii parametrii trebuiesc stabiliți:

CODEC-uri – punctele terminale trebuie să utilizeze acelasi tip de CODEC pentru voce, sau cel puțin să recunoască opțiunea celuilalt punct terminal în ceea ce privește versiunea de codare a vocii.

Transmisie / Recepție – în funcție de aplicație, traficul de voce poate fi unidirecțional sau bidirecțional. Există cazuri în care anumite puncte terminale nu pot participa la o sesiune deoarece nu sunt capabile sa realizeze traficul de voce in ambele sensuri.

Tipul de conținut media – poate fi conținut audio, video sau date.

Rata de bit – se referă la lărgimea de bandă necesară pentru realizarea conexiunii.

Figura 3.7 – Negocierea parametrilor apelului

Administrarea și gestiunea apelurilor

Aceste funcții asigură servicii opționale ce contribuie la o mai bună administrare și mentenanță a unei rețele VoIP.

Funcția de gestiune folosește informațiile adunate în timp legate de desfășurarea apelurilor, informații reunite sub denumirea de CDR (Call Detail Records). CDR-ul este utilizat în procesul de facturare, precum și la o analiza de îmbunătățire a serviciilor în cazul unei eventuale creșteri a capacității rețelei.

Administrarea presupune următoarele procese:

Stadiul apelului în curs – este monitorizată desfășurarea apelului în timp real.

Managementul adreselor – asigură utilizatorilor diferite servicii, cum ar fi rezoluția adreselor.

Controlul accesului la rețea – asigură utilizarea resurselor rețelei

Transportul datelor și semnalizarea

Semnalul analogic primit de la microfonul folosit de utilizator este eșantionat în funcție de anumiți parametri acceptați de interlocutori î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. Pentru a avea o calitate bună, trebuiesc rezolvate anumite probleme ce vor fi menționate mai jos.

Problemele transportului datelor în timp real

Cel mai răspândit sistem telefonic este astăzi cel analogic. Acesta folosește modulația semnalelor electrice pe un fir pentru transportul vocii.

Cu toate că este o tehnologie veche, transmisia analogică are multe avantaje: este simplă și este caracterizată de o întârziere a transmisiei foarte mică întrucât semnalul se propagă pe fir cu o viteză apropiată de cea a luminii. Este de asemenea și foarte ieftină atunci când nu sunt mulți utilizatori care vorbesc în același timp, și mai ales când aceștia se află la mică distanță unii față de alții. Acest tip de transmisie este și cea mai simplă tehnologie analogică: ea necesită o pereche de fire pentru fiecare conversație, fapt ce devine rapid nepractic și costisitor. O primă îmbunătățire a acestei tehnologii a fost trecerea la multiplexarea mai multor 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 și greu 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ă.

Din cauza acestor motive, multe țări folosesc o rețea telefonică digitală. În cele mai multe cazuri linia abonatului rămâne analogică, dar semnalul, ajuns la prima cerntrală, este convertit la un flux digital. De obicei, acest semnal are o rată de 64kb/s (un eșantion de 8 biți la fiecare 125μs).

Acum, multe canale de voce pot fi multiplexate pe aceeași linie de transmisiune folosind o tehnologie numită multiplexare cu diviziune în timp (TDM). În acestă tehnologie, fluxul digital ce reprezintă o singură conversație împărțită în blocuri (de obicei în octeți, denumite și eșantioane).

Cu această tehnologie digitală, zgomotul care se amestecă cu semnalul original nu influețează calitatea comunicației întrucât semnalele digitale pot fi recreate. Mai mult, multiplexarea cu diviziune în timp facilitează comutația digitală. Comutatorul copiază conținutul unui slot temporal din transmisia de intrare în alt slot temporal din transmisia de ieșire. De aceea funcția de comutare se poate realiza cu ajutorul unor calculatoare. Totuși, o mică întârziere este introdusă de fiecare comutator deoarece pentru fiecare conversație un slot temporal este disponibil numai la fiecare T microsecunde, și în unele cazuri ar putea fi necesar să se aștepte până la T microsecunde pentru a copia conținutul unui slot în altul. Tinând cont că T reprezintă 125μs în majoritatea rețelelor digitale, acest timp poate fi neglijat iar întârzierea poate să depindă de timpul de propagare.

Numai în cazul în care un utilizator dorește să impună un punct de vedere, el 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, evitând transmiterea zgomotelor atunci când tace. Așa cum se va vedea mai târziu, cele mai multe tehnici de transformare a vocii în biți de informație (numite codecuri) au acum posibilitatea să depisteze perioadele de liniște, atunci când utilizatorul nu vorbește. Cu acestă metodă, cunoscută ca detecția activități vocii (“voice activity detection”), în loc să se transmită informații la fiecare 125 microsecunde, cum se face astăzi, se pot transmite informații doar atunci când este necesar, în mod asincron.

Când este vorba de multiplexarea mai multor conversații pe aceiași linie de transmisiune, în locul ocupării benzii pe tot intervalul de timp, această bandă poate fi folosită de o altă persoană 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 să poată fi folosită mult mai eficient, în special atunci când sunt multe conversații pe aceiași linie. Din nefericire, multiplexarea dinamică introduce incertitudine în rețea. Așa cum spuneam, în cazul TDM, o întârziere de până la T microsecunde poate fi introdusă la fiecare comutator; această întârziere este constantă de-a lungul întregii conversații. Dacă linia de transmisiune este liberă atunci când trebuie trimise date prin rețea, acestea vor trece imediat. Dacă linia este ocupată, datele trebuie să aștepte până când va exista posibilitatea trimiterii lor.

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

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

VoIP se confruntă cu destul de multe probleme tehnice; rețelele IP existente nu au fost proiectate să servească aplicațiile în timp real. Cerințele pentru voce sunt exigente: pentru o comunicație în timp real, de calitate bună, nu este permisă o întârziere dus-întors mai mare de 200 – 300 ms, ceea ce înseamnă ca pe un sens întârzierea să nu să depășească 100 – 150 ms. Pentru a compensa jitterul este folosit un buffer la recepție; 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 părți din semnalul primit de la microfonului transmițătorului și astfel apar întreruperi în redarea sunetelor la recepție. 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.

În continuare vor fi prezentate mai detaliat principalele probleme ce pot apărea:

pierderea pachetelor;

întârzierile;

jitterul.

Pierderea pachetelor

Această problemă este des întâlnită în rețelele cu comutație de pachete. 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 iar aceste noi pachete vor fi aruncate („drop”). Prin pierderea de pachete se poate ajunge la degradarea calității vocii. În funcție de codecul folosit, fiecare pachet de date conține între 20 – 80ms din semnalul captat de microfon. Când sunt puține pachete pierdute, creierul uman este capabil să reconstruiască segmentele pierdute, dar dacă numărul pachetelor este prea mare, vocea redată devine neinteligibilă. În continuare sunt prezentate tehnicile prin care se poate rezolva problema pierderii pachetelor:

Îmbunătățirea rețelei. Întrucât fenomenul de aruncare a pachetelor este se leagă strâns de banda insuficientă a conexiunilor și de viteza de procesare a elementelor de rutare, îmbunătățirea rețelei prin actualizarea software a echipamentelor sau trecerea la echipamente de generație mai nouă 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, in cazul în care rata de pierdere a pachetelor este mult prea mare sau pachetele sunt foarte mari (adică conțin fragmente mari din semnalul captat) în semnalul redat apar frânturi din semnalul original, lucru ce deteriorează semnificativ calitatea vocii.

Înlocuirea cu zgomot. Prin această metodă se înlocuiesc zonele fără informație cu zgomot obținându-se performanțe mai bune decât metoda înlocuirii cu pauze.

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. Aceasta este de asemenea una dintre cele mai uitilizate metode.

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

Transmisie redundantă. Transmisia informației dintr-un pachet se face în mod redundant prin pachete consecutive. Dacă pachetul original se pierde, acesta poate fi refăcut din pachetele următoare.

Întârzierea pachetelor

Întârzierile prelungite duc la intrarea participanților la o conversație într-un mod de comunicație half-duplex, adică unul dintre ei vorbește iar ceilalți așteaptă un timp pentru a putea fi siguri că vorbitorul a reușit să termine. În cazul în care timpul de așteptare este ales greșit, pot apărea doi sau mai mulți vorbitori simultan. Întârzierile cu durată lungă reprezintă un efect negativ și din cauza ecoului care face ca vorbitorul să își audă propria voce la scurt timp după ce a terminat de vorbit. Fiind un fenomen subiectiv, nu pot fi date cerințe exacte în ceea ce privește întârzierea, dar există anumite limite. Redarea vocii cu un decalaj mai mic de 150ms față de momentul când interlocutorul vorbește este aceptabilă pentru cele mai multe aplicații. Odată cu creșterea întârzierii, participanții la conversație încep să vorbească în același timp sau se întâmpină un ecou deranjant; calitatea convorbirii scade foarte mult. Întârzieri între 150 și 400ms sunt acceptate pentru convorbiri între persoane aflate la o distanță extrem de mare una de cealaltă. Întârzierea este una din cele mai mari probleme cu care se luptă telefonia IP. Factorii care cauzează întârzierile în rețelele cu comutație de pachete sunt:

Întârzierea produsă de codecuri. Un codec are ca funcție principală digitalizarea semnalului vocal analog, dar și realizarea unei compresii pentru reducerea necesarului de bandă. Ratele mari de compresie se pot obține cu ajutorul unor algoritmi ce au ca principal dezavantaj un timp de procesare mare. Timpul necesar prelucrării eșantioanelor ce intră într-un singur pachet și timpul necesar observării eșantioanelor următoare pentru exploatarea anumitor corelații ce pot apărea, sunt componente ale întârzierii. Durata decodării este de obicei jumate din durata codării, deci la recepție întârzierea provocată este mai mică decât cea produsă la momentul transmisiei.

Întârzierea din cauza transmisiei. Această întârziere este determinată de viteza liniei de transmisie și de mărimea pachetului.

Întârzierile produse de cozile de așteptare. Timpul pierdut în cozile de așteptare reprezintă una dintre cele mai mari probleme introdusă de rețelele cu comutație de pachete. Acest timp depinde foarte mult de numărul de pachete ce așteaptă în coadă și variază enorm de la un pachet la altul. Întârzierea aceasta este și principala problemă pentru aplicațiile în timp real deoarece este o sursă pentru jitter.

Întârzierile cauzate de propagare. Acest timp devine important doar dacă distanțele între puncte este extrem de mare – ca în cazul comunicațiilor prin satelit, întrucât propagarea se face cu viteza lunimii, deci întârzierea pe distanțe suficient de mici nu se poate lua în calcul.

Jitterul

Jitterul poate fi definit ca fiind variația duratei de timp între pachetele primite la recepție. Acesta reprezintă o problemă importantă ce trebuie eliminată din comunicațiile prin voce. Jitterul apare mai ales în urma întârzierilor produse de cozile de așteptare, dar mai poate proveni si din cauza pachetelor întrucât acestea pot ajunge la destinație pe căi diferite. Pentru a-l compensa, la primire, se folosește o coadă de așteptare, unde pachetele sosite pentru o durată de timp definită sunt ținute primele, înainte ca informația conținută să fie redată. Întârzierea produsă de acest buffer se adaugă la întârzierea totală ceea ce înseamnă că pentru a obține o comunicație de calitate trebuie să avem un jitter mic. Dimensiunea cozii de așteptare este aleasă într-un mod dinamic în concordanță cu parametrii rețelei. În general, dimensiunea unei cozi de așteptare este de 50 – 100ms.

În Figura 3.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 3.1 – Jitter

RTP (Real-time Transport Protocol)

Jitterul trebuie luat în considerare de către receptor atunci când o rețea cu multiplexare dinamică este folosită pentru transmisia datelor în timp real, ca de exemplu vocea. Ruterele sunt dispozitive cu ajutorul cărora se realizează multiplexarea dinamică și de aceea în tehnologiile voce și video peste IP trebuie să fie luat în considerare problemele cauzate de jitter.

Grupul din cadrul IETF ce se ocupă de transportul informațiilor audio și video a început lucrul la un protocol de transport în timp real în 1993. Obiectivul acestui protocol este de a oferi servicii cerute de conferințele multimedia interactive, precum sincronizarea redării informațiilor primite, demultiplexare, identificarea tipului de mediu folosit pentru transmisie și identificarea participanților activi. 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, nu numai aplicațiile pentru conferințe multimedia.

Obiectivul proiectării RTP a fost căpătarea unui protocol cu următoarele caracteristici:

Flexibil. RTP nu trebuie să fie limitat doar 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 î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 fi un impediment în folosirea 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. 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ă.

Durată foarte scurtă de implementare. În cazul în care protocolul nu are o viață îndelungată, 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 cu scopul de 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 transmiterea de date în timp real, de exemplu pentru voce și pentru video.

Un alt protocol, RTCP, ce este în mod frecvent 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 informații legate de identitatea participanților.

Influența RTP și RTCP nu se reflectă asupra comportării rețelei IP; acestea nu controlează în niciun fel calitatea seviciului. Rețeaua poate întârzia, elimina pachetele RTP sau chiar schimba ordinea acestora, ca orice pachet IP. Rolul lui RTP și RTCP este de a permite 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 cu orice protocol de transport. Dar de obicei se folosește UDP, deoarece schema de retransmisi a TCP nu este adaptată pentru datele ce trebuiesc transportate cu întârzieri foarte mici, cum sunt comunicațiile interactive. În acest caz RTP este asociat în mod tradițional unui port UDP par, iar RTCP următorului port UDP impar.

Conform RFC-ul 1889, RTP este un protocol ce asigură servicii de transport capăt la capăt al unor date cu caracteristici de timp real, cum ar fi audio sau video facând parte dintr-o comunicație interactivă. Printre aceste servicii sunt incluse indentificarea tipului datelor transportate, numerotarea pachetelor, etichetarea 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ă. Acest protocol nu furnizează nici un mecanism care să asigure transportul la timp al datelor sau alte garanții de calitate a serviciilor, dar se bazează pe serviciile nivelurilor inferioare să asigure aceste garanții. Acesta nu garantează transportul sau transportul în secvență și nici nu presupune că rețeaua folsită este sigură și livrează pachetele în ordinea î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.

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. Acestea pot fi folosite în mai multe moduri, în funcție de aplicație. Spre exemplu, o aplicație video poate imediat deduce din informația de timp pentru ce zonă din ecran este informația dintr-un anumit pachet. În cazul în care 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, o anumită porțiune de voce înainte de a reda-o. În momentul în care ajunge un nou pachet RTP, el este plasat în buffer în funcție de numărul de secvență. În cazul în care un pachet încă lipsește atunci când ar trebui redat, aplicația poate să copieze informația din ultimul pachet care tocmai a fost redat și să o repete destul timp pentru ca să se ajungă la o valoare a timpului redării echivalentă cu informația de timp din următorul pachet primit, sau să folosească o schemă de interpolare definiă de codecul folosit.

Tipul informației transportate.

Formatul informației de timp real transportate este nespecificată în RFC 1889 și trebuie definită de aplicație sau 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.

Exemple de folosire a RTP-ului:

O simplă conferință audio.

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, iar celălalt este folosit pentru pachetele de control (RTCP). Adresa de multicast și porturile sunt distribuite participanților doriț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) în cazul în care se dorește ca această conferință sa nu fie ascultată și de alți participanți nedoriți.

Aplicațiile de conferință audio folosite 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 (precum PCM, ADPCM sau LPC) datelor din fiecare pachet pentru ca receptorii să poată cunoască ce tip de date au primit, iar transmițătorii să poată modifica modelul 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, apoi le întârzie cu o durată variabilă de timp. Pentru a învinge aceste obstacole, 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 ieși din conferință oricând în timpul conferinței, este necesar să se știe cine participă la un moment dat și calitatea recepționării datelor audio. Pentru acest scop, fiecare instanță a aplicație audio din conferință trimite periodic în mod multicast un raport de recepție și 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. Alte informații de indentificare pot fi incluse, pe lângă numele utilizatorului. O locație trimite pachetul RTCP BYE în momentul părăsirii conferinței.

Conferință audio și video.

Dacă în aceeași conferință se folosește atât audio cât ș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. La nivelul RTP, nu există nicio legătură î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.

Există posibilitatea ca participanții să aleagă modul de primire a datelor (audio, 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ții doresc să primească fluxurile în același format. Totuși, acest lucru nu se poate realiza întotdeauna. Există posibilitatea ca participanții dintr-o zonă să fie legați printr-o conexiune de viteză mică de ceilalți participanți, care au conexiuni de mare viteză. Ar fi un caz nefavorabil daca s-ar impune tuturor folosirea unui codec ce produce fluxuri de calitate și bandă scăzută, așa că se plasează un releu la nivelul RTP-ului numit mixer, 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 unicast spre un singur device sau multicast spre device-uri 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 este posibil să nu fie accesibili prin multicast. De exemplu, aceștia ar putea fi în spatele unui firewall la nivel aplicație care elimină toate pachetele IP. Pentru aceste stații, nu este necesară folosirea unui mixer, dar trebuie folosit alt obiect ce lucrează la nivelul RTP-ului, numit translator.

Este instalat un translator de fiecare parte a firewall-ului (doi în total), 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 avea o gamă largă de scopuri. Spre exemplu, 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, sunt necesare câteva definiții:

Sesiune RTP.

O sesiune RTP reprezintă un grup de participanți ce comunică prin RTP. Fiecare participant folosește două adrese de transport pentru fiecare sesiune: una pentru fluxul RTP, iar cealaltă pentru rapoartele RTCP. În cazul în care se folosește o transmisie multicast, toți participanții folosesc aceeași pereche de adrese multicast de nivel 4 (nivel 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 în vederea sincronizării, un receptor grupează pachetele după sursa de sincronizare. Exemplele de surse includ transmițătorul unui flux de pachete provenite de la o sursă de semnal, cum ar fi un microfon sau o cameră. O sursă de sincronizare își poate schimba formatul datelor trimise în timp. Identificatorul SSRC este ales astfel încât această valoare să fie unică într-o sesiune RTP. Nu trebuie să se 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, fiecare dintre acestea trebuie identificat prntr-un SSRC diferit.

Sursă contribuitoare CSRC.

În momentul în care un flux RTP este rezultatul unei combinări a mai multe fluxuri, lista de SSRC-uri a fiecărui flux folosit este adăugată în antetul RTP-ului al fluxului rezultat ca CSRC. Acest flux are propriul lui SSRC.

Formatul NTP.

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

Pachetul RTP conține întotdeauna toate câmpurile până la lista CSRC. Această listă poate exista doar 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 motive de aliniere. Dacă pachetul a fost alterat (P=1), atunci ultimul octet al câmpului de indică tipul datelor transportate indică 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 3.2.

Figura 3.2 – Extensia antetului

câmpul de 4 biți CC indică numărul de CSRC-uri așezate 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. Are rolul de 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).

Identifică forma informației transportate, determină interpretarea acesteia de către aplicație și are 7 biți. Documentul amintit mai sus specifică o legătură statică între coduri de identificare a tipului informației și diferite formate de date. În plus, se pot defini alte corespondențe dinamice prin moduri 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 3.3 prezintă o parte din identificatori statici.

Figura 3.3 – Identificatori statici

Numărul de secvență (16 biți).

Numărul de secvență este incrementat pentru fiecare pachet RTP trimis și are rolul de a detecta pierderea pachetelor și de a reface ordinea pachetelor. Valoarea inițială a numărului este aleasă aleatoriu din motive de securitate, și anume pentru a face atacurile asupra fluxurilor codate mai dificile.

Figura 3.4 – Pachetul RTP

Informația de timp (32 de biți).

Eșantionarea primului octet din datele conținute în pachet este reflectată de aceasta. Pentru a permite sincronizarea și calculul jitterului, această valoare trebuie luată de la un ceas care este incrementat monoton si linear în timp. 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 poate fi specificată în mod static în documentele ce definesc profilele și corespondența acestora cu coduri sau poate fi definit în mod dinamic pentru formate definite prin mijloace non-RTP. Dacă pachetele RTP sunt generate în mod periodic, nu se va folosi valoarea ceasului sistemului, ci se va folosi valoarea ceasului de eșantionare. Spre 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 150 de perioade de eșantionare de la dispozitivulde înregistrare, valoarea informației de timp va fi mărită cu 150 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 aleasă întâmplator, la fel ca numărul de secvență. Câteva pachete RTP pot avea valori ale informației de timp egale dacă acestea sunt (teoretic) sunt generate în același timp, cum ar fi pachetele ce aparțin aceluiași cadru video. În cazul în care datele sunt transmise în altă ordine decât cea în care au fost înregistrate și eșantionate, pachetele consecutive pot fi marcate cu valori nemonotone.

SSRC (32 de biți).

Câmpul SSRC identifică sursa după care se face sincronizarea. Acest identificator este ales întâmplător, cu intenția să nu existe două surse de sincronizare în aceeași sesiune RTP cu același SSRC. Probabilitatea ca acest lucru să se întâmple este mică. În orice caz, toate aplicațiile RTP trebuie să fie pregătite să detecteze și să rezolve aceste coliziuni. În cazul în care o sursă își schimbă adresa sursă, pentru a evita apariția confuziilor trebuie să-și schimbe și SSRC-ul.

Lista CSRC.

În această lista există între 0 si 15 elemente de 32 de biți fiecare. Acestă listă are rolul de a identifica 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, doar 15 pot fi identificate. Identificatorii CSRC sunt inserați de mixere, folosindu-se de identificatorii SSRC ai surselor contribuitoare. Spre exemplu, pentru pachetele audio identificatorii SSRC ai surselor care au fost mixate împreună pentru a crea un pachet sunt listate în cadul câmpului CSRC, permițând astfel indicarea vorbitorului la recepție în mod corect.

RTCP (Real-time Transport Control Protocol)

Protocolul pentru controlul RTP-ului se bazează pe transmisia periodică a pachetelor de control către toți participanții unei sesiuni particulare. Pachetele de date de sunt distribuite în același fel ca și pachetele de control. 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/pierdute, jitterul, întârzierea fată de ultimul raport primit, timpul de emisie al ultimului raport, etc. RTCP are patru funcții separate:

Funcția principală este pentru furnizarea feedback-ului cu privire la calitatea trimiterii de date. Informațiile primite prin această cale pot fi folosite la controlul unei codări adaptive (codec adaptiv). Cercetările legate de multiplexarea IP au arătat că feedback-ul este necesar pentru diagnosticarea 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ții unei sesiuni. Acest lucru se face posibil 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 nu este static, există posibilitatea de a se schimba într-o sesiune. Identificatorul CNAME folosit și pentru sincronizarea fluxurilor multimedia multiple. În momentul în care 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 controlată de asemenea. Acest control al ratei este realizat de RTCP. Numărul de participanți este folosit pentru determinarea valorii acestei rate. Cu cât numărul participanților este mai mare, cu atât rata cu care se trimit pachete de către fiecare participant este mai mică.

A patra funcție este opțională și are rolul de a transporta un minimum de informație de control a sesiunii, pentru ca identificarea participanților în interfața grafică sa fie posibilă.

Toți participanții trebuie să trimită pachete RTCP, fapt ce poate duce la probleme pentru conferințele pe bază de multicast de mari dimensiuni, deoarece traficul RTCP va crește în funcție de numărul de participanți. Acest impediment nu există cu fluxurile RTP în conferințele audio ce folosesc suprimarea pauzelor, deoarece oamenii nu vorbesc de regulă în același timp.

Fiecare partipant își poate controla rata cu care trimite aceste rapoarte deoarece numărul lor este cunoscut tuturor ce ascultă rapoartele RTCP. Acest fapt este folosit pentru a limita banda folosite de RTCP la o valoare rezonabilă, de obicei în jur de 5% din banda alocată sesiunii. Această bandă trebuie folosită de toți participanții. Transmițătorilor activi le revine un sfert din această bandă, deoarece informațiile conținute în rapoartele transmițătorilor sunt importante pentru receptori, iar ceea 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, câte 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 receptorii ce nu sunt și transmițători activi;

SDES: reprezintă descrierea sursei și conține numeroși parametrii referitori la sursă, printre care și CNAME;

BYE: reprezintă raportul trimis atunci când un participant pleacă din conferintă;

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

Câteva pachete RTCP pot fi incluse într-un singur pachet al protocolului de transport. Fiecare mesaj RTCP are destule informații pentru a fi decodat fără nicio problemă în cazul în care mai multe asemenea mesaje sunt încapsulate în același pachet UDP. Acest mod de utilizare este folositor pentru a transmite eficient informația, având în vedere dimensiunile antetului protocolului de transport.

Rapoartele receptorului și ale transmițătorului sunt prezentate în Figura 3.5.

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

5 biți alocați numerelor de rapoarte conținute în acest raport;

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

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

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

Cea de-a doua secțiune conține informații în legătură cu 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 de două feluri: absolută sau relativă față de momentul începerii sesiunii.

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

numărul de pachete trimise de acest transmițător de la începutul sesiunii pe 16 biți. În cazul în care se schimbă SSRC, este resetat.

numărul de octeți de date ce au fost trimise de la începutul sesiunii. Și acesta este resetat în cazul în care se schimbă SSRC-ul.

Figura 3.5 – Raportul transmițătorului

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

SSRC (indentificatorul sursei): 32 de biți – identificatorul sursei asupra căruia 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 fiind pachete pierdute, iar pachetele duplicate sunt numărate ca fiind primite;

cel mai mare număr de secvență primit, variantă extinsă: (32 biți). Primii 16 biți conțin numărul de cicluri ale numărului de secvență, iar ultimii 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 pachete consecutive. Definiția este egală cu diferența timpului de propagare relativ pentru ambele pachete; timpul de propagare relativ reprezintă 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 aceleaș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ă în felul următor: D(i,j)=(Rj-Ri)-(Sj-Si)=(Rj-Sj)-(Ri-Si). Jitterul este calculat încontinuu 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, conform formulei: J=J+(|D(i-1,i)|-J)/16. În momentul emiterii unui 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 informația de timp conținută de ultimul raport provenit din partea unei surse.

întârzierea față de momentul când s-a primit ultimul raport SR (DLSR): 32 de biți. Asociat cu LSR, transmițătorul poate calcula timpul dus-întors.

Raportul receptorului este asemănator cu raportul transmițătorului. Diferențele dintre cele două sunt 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 se poate observa în Figura 3.6.

Un pachet SDES are câmpul PT egal cu 202 și are porțiuni unde se enumeră sursele (SC). Fiecare porțiune conține un SSRC sau un CSRC și o listă cu informații. Fiecare element din listă este prezentat folosind formatul tip, lungime, valoare.

Figura 3.6 – Descrierea surselor

Există următoarele tipuri:

CNAME(unic în cadrul unei sesiuni) este de forma utilizator@mașina_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 3.6 este prezentat pachetul SDES iar în Figura 3.7 este prezentat pachetul RTCP BYE.

Pachetul RTCP BYE indică că unul sau mai multe surse (SC) nu mai sunt active.

Figura 3.7 – Pachetul BYE

APP: pachetul RTCP definit de aplicație (Figura 3.8):

Se poate folosi acest pachet pentru a transporta informații legate de aplicația folosită. Câmpul PT este setat la valoarea 204.

Detalii în plus se pot găsi în RFC 1889.

Figura 3.8 – Pachetul APP

RTSP (Real-time Transport Streaming Protocol)

Protocolul pentru fluxurile în timp real sau RTSP este un protocol de nivel aplicație ce asigură livrărea datelor cu proprietăti de timp real. RTSP având o bază extensibilă poate permite transportul controlat al datelor de timp real, precum cele audio și video. Sursele de date pot fi reprezentate atât de aparatele ce captează în momentul transmisiei cât și de datele stocate. RTSP controlează multiple sesiuni de transfer de date, pentru a furniza mijloacele prin care se aleg mijloacele de transport, precum UDP, multicast UDP sau TCP și pentru a asigura mijloacele pentru alegerea mecanismelor de transport bazate pe RTP.

RTSP se ocupă de controlul fluxurilor sincronizate de date continue, precum cele audio sau video. RTSP nu transportă el însuși aceste fluxuri, ci propune un control la distanță prin rețea al server-elor multimedia.

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

Noțiunea de conexiune RTSP nu există, dar serverul are o sesiune etichetată ce o menține cu ajutorul unui identificator. O astfel de sesiune nu este legată de conexiunea de la nivelul transport. Î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, precum UDP.

Modul de funcționare al protocolului nu depinde de mecanismul de transport folosit, pentru a transporta datele în timp real. Fluxurile controlate de RTSP pot folosi RTP. Protocolul este intenționat asemănător în sintaxă și mod de operare cu HTTP versiunea 1.1. HTTP (Hypertext Transfer Protocol) este un protocol de nivel aplicație fiind 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, așa cum este definită în RFC-ul 1495, a ajutat la îmbunătățirea protocolului prin faptul că permite mesajelor să aibă un format asemănător cu formatul MIME (Multipurpose Internet Mail Extensions), mesaje ce conțineau informații legate de datele transportate și modificatori ai semanticii mesajelor de cerere și răspuns.

Versiunea 1.1 include cerințe mai riguroase decât versiunea anterioară având scopul de a furniza implementări sigure a caracteristicilor acestui protocol. HTTP asigură un set de metode și antete ce arată scopul unei cereri. HTTP este folosit și ca protocol de comunicație între agentul utilizatorului (aplicația ce rulează la cererea utilizatorului), gateway-uri sau proxy-uri și alte sisteme din Internet. Astfel, HTTP permite acesul la resursele disponibile de la diverse aplicații.

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

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;

atât clientul cât și serverul pot emite cereri;

datele sunt transportate de către un alt protocol;

setul de caractere ce este folosit în compunerea mesajelor este altul.

Aceste modificări ajută la o 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:

se pot obține informații de la un server. Clientul poate cere o descriere a prezentărilor prin HTTP sau prin altă metodă. În cazul în care prezentarea este trimisă în mod multicast, atunci în descriere apare adresa de multicast și porturile utilizate. Dacă doar un client va primi fluxurile media prin unicast, atunci el va oferi destinația din motive de securitate.

invitarea unui server media la o conferință. Un server media poate fi invitat la o conferință, cu rolul de a reda fișiere multimedia sau pentru a înregistra conferința. Acestă metodă este foarte utilă pentru aplicațiile de învățământ la distanță.

informarea utilizatorilor în timp real despre tipurile de date disponibile pentru o prezentare existentă deja.

Sunt necesare câteva precizări:

Flux media.

Reprezintă un singur flux de date ce pot fi audio, video sau datele provenite de la un „whiteboard”. În timpul folosirii unui 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ă datele transferate în cadrul unui răspuns sau cereri.

Sesiunea RTSP.

Reprezintă o tranzacție completă RTSP. Într-o sesiune, un client crează un mecanism de transport pentru fluxul media, pornirea redării și închiderea fluxului.

Protocolul RTSP are următoarele proprietăți:

Extensibil.

Parametrii și metode noi pot fi adăugate la acest protocol;

Ușor de analizat.

RTSP poate fi analizat de către HTTP sau MIME;

Securizat.

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

Capabilitatea de lucru cu mai multe servere.

Fiecare flux media poate fi stocat pe diferite servere.În mod automat, clientul stabilește mai multe sesiuni de control cu severele ce conțin fișierele media. Sincronizarea se face la nivelul transport;

Controlează aparatele ce se ocupă cu înregistrarea.

Protocolul controlează atât aparatele ce fac înregistrarea/redarea fișierelor media, cât și a aparatelor ce fac aceste funcții în mod alternativ;

Separă controlul fluxului de inițializarea conferinței.

Controlul fluxului este separat de invitarea server-elor la conferință. SIP sau H.323 pot fi utilizați pentru trimiterea unei invitații către server la o conferință. Prin server ne referim la orice sistem ce dorește sau este solicitat să trimită date în timp real.

Adaptat pentru aplicațiile profesionale.

RTSP furnizează la nivelul cadrelor ce permit editarea la distanță o acuratețe mare.

Neutru din punct de vedere al descrierii prezentării.

Protocolul comunică tipul descrierii ce va fi folosit și nu impune un format de descriere. Ar fi indicat ca descrierea să aibă cel puțin un identificator al resursei, adică un URI;

Folosirea sistemelor firewall și proxy.

Protocolul poate fi utilizat 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;

Utilizează HTTP.

În locurile necesare, RTSP reutilizează conceptele HTTP pentru ca infrastuctura existentă să nu aibă de suferit;

Permite controlul rezonabil al server-ului.

În cazul în care un client dorește să pornească un flux de date, atunci el trebuie să aibă posibilitatea să și oprească fluxul. Server-ele nu trebuie să pornească trimiterea unui flux într-un asemenea mod încât clientul să nu fie pus în situația de a nu putea să oprească acel flux;

Negociază metoda de transport.

Clientul poate negocia metoda de transport înainte de a fi nevoit să transmită date;

Permite negocierea capacităților.

În cazul în care caracteristicile de bază nu sunt disponibile, trebuie să existe un mecanism astfel încat clientul să determine ce metode nu vor fi folosite. Aceasta permite clienților să afișeze interfața grafică corespunzătoare.

Fiecare prezentare și flux media poate fi identificată de un URL.

Prezentarea și proprietățile fluxurilor din care 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 poșta electronică și nu trebuie să fie stocat pe serverul media. În principiu, acest document trebuie să conțină descrierea mediilor ce creează prezentarea, incluzând și codecurile folosite, limbajul și alți parametri care permit clientului să aleagă cea mai potrivită combinație. În acestă descriere a prezentării, fiecare flux media controlat de RTSP este identificat printr-un URL al protocolului RTSP, care indică spre serverul ce prelucrează acel flux și poartă numele ori a fluxului ori a serverului. Mai multe fluxuri media pot fi localizate pe servere diferite; de exemplu, fluxurile audio și video pot fi împărțite pe mai multe servere pentru ca încărcarea acestora să fie echitabilă. Descrierea enumeră și ce metode de transport poate folosi un server.

În afară de parametrii mediilor folosite, adresa de rețea destinație și portul trebuiesc determinați. Se pot menționa câteva moduri de operare:

Unicast: informația audio sau video este transmisă spre locul din care a fost trimisă cererea RTSP, cu numărul portului ales de client.

Multicast cu alegerea adresei de către server: serverul stabilește atât adresa cât și portul. Aceasta este cazul tipic pentru o transmisie în timp real sau aproape de o transmisie la cerere.

Multicast cu alegerea adresei de către client: atunci când server-ul încearcă să se conecteze într-o conferință deja existentă, adresa de multicast, portul și modalitatea de codare sunt precizate în descrierea conferinței.

RTSP controlează un flux care poate fi trimis prin intermediul unui protocol separat, care nu este legat de canalul de control. Spre exemplu, datele pot fi transmise prin UDP iar controlul RTSP poate fi făcut printr-o conexiune TCP. Astfel, livrarea datelor este continuă iar serverul nu mai recepționează nicio altă cerere RTSP. Pe timpul unei conexiuni, un singur flux media va putea fi controlat prin cereri RTSP trimise secvențial pe diferite conexiuni TCP. Astfel, o stare a sesiunii este permanent menținută de către server pentru ca acesta sa fie capabil să coreleze cererile cu un flux. Cele mai multe metode din cadrul RTSP nu contribuie la schimbarea stării dar următoarele joacă un rol esențial în definirea alocării și utilizării resurselor în server: SETUP, PLAY, RECORD, PAUSE și TEARDOWN.

Metoda SETUP: serverul pornește o sesiune RTSP și alocă resurse pentru un flux. La metodele PLAY și RECORD, transmisia datelor este pornită prin metoda SETUP. În cazul metodei PAUSE, un flux este oprit temporar fără să elibereze resursele serverului iar metoda TEARDOWN eliberează resursele asociate cu fluxul media și sesiunea se încheie pe server.

Metodele care contribuie la starea unei sesiuni conțin câmpul antet sesiune pentru indicarea stării a cărei sesiuni o manipulează. Un identificator al sesiunii este generat de către server în răspuns la o cerere de tip SETUP.

După ce cererile cu metodele de mai sus ajung la server, acesta răspunde cu un mesaj ce conține o linie de stare formată din versiunea protocolului, un cod de trei cifre ce indică clientului dacă acțiunea a avut sau nu succes și o descriere a codului. Prima cifră din cod definește clasa răspunsului iar ultimele două cifre nu au niciun rol în ierarhia raspunsurilor. Există 5 valori posibile pentru prima cifră:

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

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

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

4xx: eroare de client – cererea conține erori de sintaxă și nu poate fi îndeplinită;

5xx: eroare de server – server-ul nu poate îndeplini o cerere ce pare validă.

Protocoale VoIP de semnalizare

O convorbire telefonică este formată din două părți distincte: semnalizarea (trimiterea numărului, a semnalelor de sunat, tonul de ocupat etc.) și partea de media (transmiterea efectivă a vocii sau a datelor); aceasta din urmă se realizează prin codarea semnalului cu un codec și împachetarea lui în pachete RTP (Real-time Transport Protocol). Semnalizarea se poate face cu unul din următoarele protocoale: SIP, H.323, MGCP, H.248, IMS, SCCP, T.38 (pentru fax).

Protocoalele H.323 și SIP sunt cele mai utilizate.

Protocolul H.323

H.323 este un standard pentru protocoale de comunicații, dezvoltat de ITU-T. Standardul a fost creat pentru a asigura comunicații multimedia într-o retea bazată pe comutația de pachete. Pe langă traficul de voce, este posibil și traficul de date și video. H.323 conlucrează cu rețeaua telefonica clasică (PSTN), intermediind procesele de semnalizare și control între o rețea bazată pe comutație de pachete IP și o rețea cu comutație de circuite (SCN).

Scopul inițial pentru care a fost proiectat standardul H.323 a fost acela de a oferi un mecanism de transport pentru aplicațiile multimedia într-o rețea locală (LAN – Local Area Network).

Foarte mulți producatori de echipamente și furnizori de servicii folosesc protocolul H.323 pentru aplicații de tip videoconferință, fiind în acest moment cel mai utilizat protocol de semnalizare și control al apelului într-o rețea VoIP.

Componentele H.323

Standardul H.323 descrie o serie de componete funcționale, ce pot fi grupate separat, în echipamente diferite, sau pot fi implementate într-un singur echipament cu roluri multiple.

În Figura 3.9 sunt prezentate componentele fizice ale rețelei, printre care gateway, gatekeeper, terminale și MCU (Multipoint Control Unit). Este psoibilă și folosirea unui server proxy.

Figura 3.9 – Componente H.323

Terminalul H.323

Standardul H.323 folosește conceptul de punct terminal. În acestă categorie se încadrează următoarele echipamente: telefoane IP, stații de videoconferință, gateway-uri. Un terminal H.323 asigură comunicația de voce (posibil video și date) în timp real și în ambele sensuri. Pentru funcția de inițiere a apelului, terminalul trebuie să asigure funcții specifice H.225.0.

Terminalul H.323 realizează codarea/decodarea vocii conform cu codorul G.711 (codare PCM cu 64 kbiti/s). Opțional se poate realiza codarea/decodarea vocii conform cu Rec. G.728 (16 kbiti/s), G.729 (8 kbiti/s) sau G.723.1 (5,3 kbiti/s sau 6,3 kbiti/s).

Pentru controlul conexiunilor, terminalul folosește un controller de sistem care asigură semnalizările pentru controlul apelurilor, controlul RAS precum și semnalizările de negociere a capabilităților dintre terminale privind capabilitățile de lucru (rata binară, formatul imaginii, algoritmul de codare) conform cu Rec.H.245.

Gateway

Gateway-ul H.323 (Figura 3.10) este un echipament de tip terminal reprezentând interfața pentru transmiterea vocii sau imaginii între rețeaua telefonică bazată pe comutația de circuite (SCN – Switched-Circuit Network) si reteaua bazata pe comutatia de pachete IP. Ideal, gateway-ul este transparent atât terminalului H.323 cât și terminalului din rețeaua SCN.

Figura 3.10 – Gateway

Gateway IP-către-IP

Un gateway IP-către-IP are rolul de a asigura o conexiunea eficientă din punct de vedere al costurilor între două rețele VoIP, ce aparțin unor ISP-uri diferite. Acest tip de gateway mai este cunoscut și sub denumirea de element de graniță (border element).

Reprezintă intrefața între două rețele VoIP și se ocupă de serviciile de facturare, securitate, semnalizare și controlul accesului în rețea. Pachetele pot trece prin gateway-ul IP-către-IP, mascând rețelele una față de cealaltă, sau pot ocoli gateway-ul dacă securitatea nu este prioritară.

Figura 3.11 – Gateway IP-către-IP

Figura 3.11 prezintă o situație de implementare a unui gateway IP-către-IP între două rețele. Din perspectiva rețelelor private, gateway-ul apare ca o adresă IP publică unică ce trebuie să poată fi rutabilă în interiorul rețelelor (în cazul de mai sus, adresa 12.x.x.x este rutabilă în rețelele private 10.10.x.x și 192.168.x.x). Pentru gateway-urile din rețeaua publică, toate apelurile au originea la adresa 12.x.x.x a gateway-ului IP-către-IP, neputând fi identificate cu adresa reală din rețeaua privată.

În Figura 3.11, fiecare gatekeeper controlează în mod independent câte o zonă, gatekeeper-ul cu adresa 12.10.10.11 fiind entitatea de control pentru rețeaua publică, implicit pentru gateway-ul IP-către-IP.

Gatekeeper

Este componenta care asigură controlul apelului pentru punctele terminale H.323.

Figura 3.12 – Gatekeeper

Gatekeeper-ul (Figura 3.12) se asociază unei zone H.323 și gestionează toate terminalele, gateway-urile și MCU-urile dintr-o zonă. Într-o zonă există un singur gatekeeper.

Gatekeeper-ul realizează următoarele funcții:

traducerea adresei necesare rutării apelului. Adresa terminalelor (număr, adresă e-mail, nume utilizator) este tradusă în adresa de transport IP;

controlul semnalizărilor RAS;

controlul accesului la rețea pentru terminalele H.323, Gateway și MCU;

gestionează alocarea lărgimii de bandă pentru conexiuni, ca răspuns la cererile punctelor terminale;

managementul zonei deservite de gatekeeper.

Gatekeeper este opțional într-o zonă. În cazul în care lipsește, înseamnă că acest domeniu nu este o zonă H.323. Indiferent daca este prezent, stabilirea apelului se poate face prin rutare directă, fără utilizarea gatekeeper-ului.

MCU (Multipoint Control Unit)

În Figura 3.13 sunt prezentate componentele care fac posibilă realizarea unei videoconferințe:

MC (Multipoint Controller) – asigură parametrii necesari pentru realizărea unei videoconferințe între două sau mai multe puncte terminale. MC-ul stabilește un canal de control H.245 cu fiecare dintre participanții la conferință. Prin intermediul acestuia sunt schimbate informații referitoare la tipul de conferință (centralizată/descentralizată). MC-ul este încorporat într-un punct terminal (terminal sau gateway), gatekeeper sau MCU.

MP (Multipoint Processor) – adaugă funcționalitate videoconferinței. Prelucrează semnalele audio și video pentru toti participanții. Asemănător MC-ului, MP-ul este

încorporat în MCU.

MCU – este un echipament independent, aflat sub forma unui echipament terminal, care asigură videoconferința între mai multe terminale, încorporand un MC și mai multe MP (sau niciunul).

Figura 3.13 – MCU

Desfășurarea apelurilor într-o rețea H.323

În cadrul procesului de desfășurare al apelului, fiecare protocol utilizat creează câte un canal logic pentru propriul trafic. Fiecare canal asigură traficul într-un singur sens, ceea ce înseamnă că va fi nevoie de deschiderea a două canale logice pentru ambele sensuri. În cazul în care apelul include și transfer de date de tipul T.120, cum ar fi utilizarea unei aplicații de videoconferintă, atunci protocolul T.120 va crea și controla propriul canal de comunicație. În Figura 3.14 este prezentat schimbul de mesaje între două gateway-uri, necesar la realizarea apelului. Gatekeeper-ul nu este prezent în acest exemplu. De asemenea, deși sunt prezentate două gateway-uri, desfăsurarea procesului ar fi fost aceeași dacă ambele puncte terminale ar fi fost terminale H.323.

Figura 3.14 – Desfășurarea apelurilor

În procesul descris in Figura 3.14 sunt incluși următorii pași:

Gateway-ul origine al apelului inițiază o sesiune H.225.0 către gateway-ul destinație, prin portul TCP 1720. Gateway-ul de origine poate afla adresa IP a gateway-ului destinație, apelând la un server DNS (Domain Name System) pentru a corela numele destinației cu adresa sa logică, fie din fișierul propriu de configurație.

Procesul de inițiere al apelului, ce functionează pe baza protocolului Q.931, creează un canal de semnalizare între punctele terminale.

Punctele terminale deschid un canal de comunicație nou, care să permită protocolului H.245 să îndeplinească funcția de control. Această funcție va realiza negocierea de capabilități între punctele terminale și se vor schimba informații în legatură cu proprietățile canalului logic de legătură.

Pe baza proprietăților canalului logic se vor deschide sesiuni RTP.

Cu ajutorul sesiunilor RTP, punctele terminale vor realiza schimbul de informație multimedia. De asemenea, punctele terminale își vor comunica statistici referitoare la calitatea apelului aflat în desfășurare, prin intermediul RTCP (RTP Control Protocol).

Procedura de bază pentru inițierea unui apel H.323 presupune un număr mare de procese de schimb de informație între gateway-urile sursă și destinație. Apelând la procedura Fast Connect, se va reduce numarul de procese de schimb, permițând negocierea capabilităților și a atribuțiilor canalului logic printr-un singur mesaj dus-întors între punctele terminale.

Figura 3.15 – Fast Connect

Așa cum se poate observa în Figura 3.15, procedura Fast Connect implică efectuarea următorilor pași:

Gateway-ul origine al apelului inițiază o sesiune H.225.0 către gateway-ul destinație, prin portul TCP 1720.

Procesul de inițiere al apelului, având la baza protocolului Q.931, creează un canal logic combinat, prin care se va realiza atât semnalizarea între punctele terminale precum și funcția de control specifică H.245. Negocierea capabilităților și proprietățile canalului logic sunt transmise odata cu procesul de semnalizare Q.931.

Ținând cont de proprietățile canalului logic, se vor deschide sesiunile RTP.

Punctele terminale vor realiza schimbul de informație multimedia prin intermediul sesiunilor RTP.

Avantaje și dezavantaje în utilizarea standardului H.323

Avantaje:

Identificarea apelantului (caller ID) – această funcție este oferită datorită informației preluate de la porturile FXO (Foreign eXchange Office) și semnalizarea pe canal asociat a liniei T1;

Interoperabilitate – H.323 este folosit la scară largă, conlucrând fără probleme cu aplicațiile și echipamentele mai multor producători. Deoarece toate echipamentele trebuie să suporte 13 protocoalele principale din cadrul standardului H.323, utilizarea unui echipament sau altul nu este dependentă de versiunea standardului.

Controlul detaliat al apelului – H.323 permite un control amănunțit al apelului către și dinspre gateway, cum ar fi analizarea cifrelor tastate, distribuirea traficului în mod egal pe diferitele cai de comunicație sau direcționarea pe o nouă rută a apelului.

Integrarea diferitelor tehnologii în rețea – se pot integra în rețeaua H.323 sisteme având la bază sistemul clasic de telefonie sau linii ISDN.

Suport pentru conținut media diferit – H.323 poate fi folosit pentru servicii de voce și videoconferințe, dar și pentru trafic de date.

Suport pentru protocolul de semnalizare NFAS (Non-Facility Associated Signaling) – acest protocol permite mai multor linii ISDN PRI prin intermediul unui singur canal de semnalizare de tip D, avand astfel la dispoziție mai multe canale libere.

Gatekeeper H.323 – un gateway se poate adresa unui gatekeeper pentru îndeplinirea funcțiilor de control al apelului și rezoluția adreselor.

Dezavantaje:

Configurarea – Configurarea gateway-ului este mai complicată decât în cazul protocolului MGCP deoarece presupune introducerea unui plan de numerotare. Folosirea unui gatekeeper ar reduce din complexitatea procesului de configurare.

Lipsa unui plan de numerotare centralizat – Dacă planul de numerotare necesită anumite modificări, atunci toate gateway-urile din rețea vor trebui reconfigurate. Utilizarea unui gatekeeper va ajuta într-o anumita măsură.

Supraviețuirea apelului – configurația de bază H.323 nu prezintă această funcție. Dacă se pierde legătura către gatekeeper, atunci toate apelurile vor fi întrerupte. Folosind tehnologia SRST – Survivable Remote Site Telephony, toate apelurile active vor fi reluate după ce se va restabili legătura cu gatekeeperul din zona respectivă.

Protocolul SIP (Session Initiation Protocol)

SIP a fost proiectat ca un modul în cadrul unei soluții de comunicație IP. Proiectarea modulară a protocolului a permis integrarea ușoară și folosirea altor protocoale existente. SIP folosește UDP-ul ca protocol de transport, dar, în funcție de aplicație, poate folosi și protocolul TCP. Portul SIP utilizat atât în cazul TCP cât și UDP este 5060.

Specificațiile standardului nu acoperă toate aspectele specifice desfășurării apelului, așa cum sunt descrise în standardul H.323. Scopul standardului SIP este acela de a crea, modifica și încheia sesiuni intre diferite aplicații, indiferent de tipul de conținut media sau funcția aplicației respective. Sesiunea poate consta într-o convorbire telefonică între doi sau mai mulți utilizatori, conferințe multimedia, sau sesiuni interactive de jocuri. SIP nu definește tipul de sesiune, ci doar se ocupă de managementul acesteia. Pentru acest lucru SIP îndeplineste următoarele funcții de bază:

Localizarea utilizatorilor, traducând adresa SIP a acestora în adresa IP.

Negocierea capabilităților între toți participanții la o sesiune

Modificarea parametrilor sesiunii în timpul desfășurării apelului.

Realizarea proceselor de stabilire și încheiere a apelului pentru toti participanții la sesiune.

Proprietățile protocolului SIP

Este un protocol ce are stări de durată mici. Fiecare din tranzacțiile cerere-răspuns pot parcurge rute diferite prin serverele din rețea. Într-un apel, cererea poate parcurge mai multe servere locale în drumul ei până la cel apelat. Răspunsul la această cerere conține o adresă detaliată ce poate fi folosită de agentul client în vederea trimiterii cererilor următoare direct către agentul server.

Deoarece la serverele de rețea SIP nu este necesară menținerea stării apelului după ce o tranzacție s-a încheiat, acestea nu dețin informații despre apelant sau apelat. Această caracteristică sporește securitatea unui server SIP, deoarece nu afectează tranzacțiile inițiate prin el, în cazul blocării. Numărul stărilor menținute într-un server în comparație cu acelea din rețeaua de telefonie clasică sunt mici. În rețeaua de telefonie clasică, o centrală trebuie să mențină starea unui apel pe toată durata acestuia. În cazul în care se dorește ca un server să cunoască starea unui apel poate menține starea unui apel pe întrega durata a acestuia. Cu ajutorul câmpurilor „rută” și „rută înregistrată” din antetul mesajelor SIP, fiecare proxy poate decide să fie pe traseul urmat de tranzacțiile următoare. Există posibilitatea ca proxy-ul să se răzândească și să se detașeze de pe calea de semnalizare.

Un server de rețea SIP nu este obligat să aibă stări nici măcar pe durata tranzacțiilor. Un server proxy sau de îndrumare poate fi complet fără stări. După momentul primirii unei cereri, acesta poate genera un răspuns sau poate trimite cererea mai departe. În mesaje se află toate datele necesare pentru ca un server proxy să le proceseze și să la ruteze. În plus, un proxy cu stări se poate transforma într-un proxy fără stări în orice moment, iar modul de funcționare al protocolului nu va fi afectat. Administratorul decide în privința fiecărui apel, dacă un proxy va avea stări sau nu.

Din punctul de vedere al protocoalelor de nivele inferioare, acesta este neutru. În ceea ce privește protocoalele de transport și de nivel rețea, SIP face presupuneri minime. Se pot furniza servicii ce se bazează pe pachete sau fluxuri de octeți la nivelele inferioare, servicii ce pot fi sigure sau nu. SIP, ca protocoale de transport poate folosi și UDP și TCP. Prin intermediul UDP-ului se poate permite aplicației să controleze mai ușor momentul trimiterii mesajelor și retransmiterea acestora în cazul în care este necesar, să folosească transmisie în mod multicast, să realizeze căutari paralele. Routerele pot lucra mai repede cu pachete SIP UDP. TCP permite trecerea cu ușurință prin componentele de tip „firewall” existente. Atunci când este folosit TCP în detrimentul UDP-ului, SIP pentru a încerca să contacteze un utilizator sau să modifice parametrii unei conferințe deja existente, poate folosi una sau mai multe conexiuni. În cazul în care există cereri diferite SIP pentru același apel, exista două posibilități: pot folosi conexiuni TCP diferite sau se pot folosi de una singură.

Protocolul se bazează pe text. Ca formă de codare, SIP folosește UTF-8. Datorită acestei fome de codări, se pot implementa limbaje precum Java, Perl sau Tcl, se pot găsi și corecta greșelile de programare. Toate aceste avantaje fac ca SIP să fie un protocol flexibil si extensibil. SIP este folosit mai mult pentru inițierea conferințelor multimedia și mai puțin pentru transferul datelor multimedia. Tocmai de aceea se consideră că procesarea în plus, existentă din cauza folosirii unui protocol bazat pe text nu este importantă.

Componentele SIP

SIP este un protocol de tip peer-to-peer. Elementele retelei care participa la o sesiune sunt prezentate în Figura 3.16:

Figura 3.16 – Componente SIP

Un UA (User Agent) cuprinde următoarele componente funcționale:

UAC (User Agent Client) – o aplicație client care inițiază o cerere de sesiune SIP.

UAS (User Agent Server) – o aplicație server care răspunde la cererile SIP.

Pe durata unei sesiuni, un UA va funcționa fie ca un UAC, fie ca un UAS, dar niciodată nu va îndeplini simultan ambele funcții. Funcționarea unui punct terminal ca UAC sau UAS depinde de UA-ul care a înaintat cererea. UA-ul de origine al cererii va folosi UAC, iar UA-ul destinație va folosi UAS.

Din punct de vedere al arhitecturii, componentele fizice ale rețelei SIP sunt grupate în două categorii:

1. User agents – include urmatoarele componente:

Telefoane IP – acționează ca UAC sau UAS în funcție de rolul lor în cadrul sesiunii. Pot fi aparate telefonice IP sau computere ce rulează o aplicație SIP (software phones).

Gateway – acționează ca UAC sau UAS și asigură controlul apelului pe durata sesiunii. Rolul său este de a asigura funcția de legătură dintre UA și alte tipuri de terminale.Această funcție presupune operarea cu diferite tipuri de conținut media (audio, video), dar și inițierea și încheiera apelului atât pentru rețeaua IP cât și pentru rețeaua SCN.

2. Server SIP – include următoarele componente:

Server proxy – acționează ca o componentă intermediară care recepționează cereri SIP de la un client și le trimite mai departe în numele clientului la următorul server SIP din rețea. Următorul server poate fi tot un server proxy sau un UAS. Printre funcțiile unui proxy se numără: autentificarea, autorizarea, controlul accesului la rețea, rutarea si securitatea în rețea.

Server redirect – informează un UA în legătură cu următorul element din rețea (server sau UA) cu care ar trebui să stabilească o legatură. UA va redirecționa invitația către elementul identificat de către server-ul redirect.

Server registrar – primește cereri de la UAC-uri pentru înregistrarea poziției lor curente.

Server de localizare – asigură rezoluția adreselor pentru serverele proxy și redirect.

Mecanismul folosit constă într-o bază de date cu înregistrări anterioare. Un server registrar poate fi inclus ca o subcomponentă a unui server de localizare. Serverul registrar este responsabil cu aprovizionarea bazei de date asociate serverului de localizare.

B2BUA (Back-to-back user agent) – acționează ca un server și client UA simultan. Are rolul de a încheia procesul de semnalizare în partea UA-ului apelant și inițiază semnalizarea către UA-ul apelat.

Modele SIP de inițiere a apelului

Inițierea apelului printr-o legătură directă: Atunci când UA identifică adresa punctului terminal destinație, fie analizând informațiile înregistrate în timp, fie apelând la unul din mecanismele interne, UAC poate iniția direct (într-o legătură UAC – UAS) procedurile de apel.

Stabilirea directă a apelului se desfășoară astfel:

UAC-ul origine trimite o invitație (INVITE) către UAS-ul destinație. Mesajul include descrierea UAC din perspectiva punctului terminal.

Dacă UAS-ul destinatie este de acord cu parametrii apelului, va răspunde pozitiv catre UAC-ul origine în vederea stabilirii legăturii.

UAC-ul origine trimite un mesaj ACK. În acest punct al procedurii, UAC și UAS au la dispoziție informațiile necesare pentru a stabili o sesiune RTP.

Inițierea apelului folosind un server proxy: Folosirea unui server proxy elimină problemele specifice metodei directe de stabilire a legăturii datorită centralizării funcțiilor de control și management al apelului. De asemenea, funcția de rezoluție a adreselor este realizată dinamic, oferind informații actualizate în ceea ce privește identificarea utilizatorilor. Principalul beneficiu adus UA-ului de pe urma folosirii unui server proxy este acela că procesul de comunicație cu un UA destinație este posibil fără ca UA-ul origine să fie nevoit să acumuleze și să stocheze informații legate de localizarea destinației.

Și această metodă prezintă unele dezavantaje. Odată cu introducerea unui server proxy în lanțul de comunicație va crește numărul de mesaje schimbate între participanți pe durata unei sesiuni. Totodata se creează o dependență a UA-urilor față de server-ul proxy. În cazul unei defectări a serverului, UA-urile dependente se vor afla în imposibilitatea de a putea iniția propriile sesiuni.

Atunci când se utilizează un server proxy, procedura de inițiere a apelului se desfășoară astfel:

UAC-ul origine trimite o invitație (INVITE) serverului proxy.

Dacă este necesar, serverul proxy va apela la serverul de localizare pentru a determina calea către destinație și adresa IP a acesteia.

Serverul proxy trimite invitația către UAS-ul destinație.

Dacă UAS-ul destinație consideră parametrii apelului ca fiind acceptabili, răspunde pozitiv serverului proxy în vederea continuării procedurii.

Serverul proxy răspunde UAC-ului origine.

UAC-ul origine trimite un mesaj ACK.

Serverul proxy înaintează mesajul ACK către UAS-ul destinație. În acest moment, UAC și UAS au la dispoziție informațiile necesare pentru a stabili o sesiune RTP.

Avantajele și dezavantaje ale standardului SIP

Așteptările sunt foarte mari în cazul standardului SIP. Acesta este văzut ca o platformă software ce va contribui la dezvoltarea comunicațiilor multimedia, permițând realizarea rapidă a sesiunilor de comunicații, în orice moment și în orice condiții. Totuși, SIP este deocamdată un protocol de control al apelului, cu avantajele și dezavantajele sale.

Avantaje:

SIP operează independent de tipul sesiunii, sau de conținutul media, oferindu-i flexibilitate în utilizare.

Este un standard deschis, având sprijinul mai multor producători care implementează SIP în echipamentele lor. Aplicațiile pot fi dezvoltate în concordanță cu utilizarea ulterioara a echipamentului.

Mesajele SIP sunt de tip text, făcând mai ușoară identificarea și rezolvarea eventualelor probleme.

SIP permite operarea simultană a mai multor utilizatori cu capabilități diferite. Spre exemplu, într-o conferință la care participă atât utilizatori cu capabilități video cât și utilizatori doar cu capabilități audio, cei cu capabilități video vor putea continua sesiunea folosind ambele capabilități media. Ei nu vor fi obligați să renunțe la capabilitatea video și să participe la conferința doar cu partea audio, așa cum se intampla în cazul altor protocoale.

Dezavantaje:

Procesarea mesajelor text impune o încărcătură suplimentară gateway-urilor. Router-ul trebuie să traducă textul într-un limbaj pe care îl înțelege, iar codul pentru această operație trebuie să fie inclus în sistemul de operare al echipamentului.

Aplicție practică

Pentru a demonstra funcționalitatea unui sistem de transmitere a vocii prin intermediul protocolului internet, am simulat, cu ajutorul unor echipamente și a configurărilor software, o rețea internă VoIP bazată pe următoarea schemă:

Prezentarea componentelor utilizate și rolul acestora în rețea

Server (centrala telefonică)

Pentru simularea centralei telefonice VoIP am folosit un Raspberry PI (Varianta B) cu adaptor Ethernet. Acest adaptor are un rol critic întrucât permite folosirea plăcii de dezvoltare pe post de server VoIP – lucru ușor de realizat prin instalarea software-ului specializat numit „Asterisk”. Versiunea utilizată este una adaptată special pentru Raspberry PI și se numește RasPBX. Mai exact, acest software, odată instalat, transformă sistemul într-un PBX – Private Branch Exchange.

Un sistem PBX este o rețea de telefonie privată. Acestea sunt folosite de companii pentru a permite angajaților să apeleze numere externe, de pe dispozitive diferite, beneficiind de același număr de telefon (fiecare dispozitiv având un număr/identificator intern unic, gestionat de centrală).

Client

Pentru conectarea la rețeaua de telefonie VoIP este necesară prezența componentei numită „Client”. Deși, în principiu, este vorba de dispozitive compatibile cu această tehnologie precum telefoanele sau videotelefoanele VoIP, această componentă poate avea mai multe forme:

un PC/Laptop care rulează o aplicație compatibilă tehnologiei (precum: 3CX, X-Lite, Bria, Zoiper, etc.)

un smartphone bazat pe Android, iOS, Windows Phone sau alt sistem de operare avansat

telefoane clasice (analogice) conectate prin dispozitive ce permit configurarea ca utilizator VoIP (exemplu: Grandstream HandyTone 502)

Rețea

Soluțiile de telefonie VoIP câștigă tot mai mult teren tocmai datorită răspândirii globale a rețelelor Ethernet. Pentru a crea o rețea Ethernet internă, am folosit un router TP-Link TL-WR841N ce permite și conexiune fără fir pentru facilitarea conectării dispozitivelor mobile și utilizarea acestora pe post de clienți în rețeaua de telefonie simulată în proiect.

Dispozitivele din rețea

Router Wireless TP-Link TL-WR841N:

un port WAN (pentru conectarea la rețeaua de internet)

4 port-uri LAN (pentru a facilita atașarea la rețeaua internă, prin cabluri Ethernet, a dispozitivelor)

conexiunea Wi-Fi (ce facilitează introducerea în rețea a dispozitivelor mobile)

un alimentator

un buton de pornire / oprire

un buton pentru resetare

Raspberry PI:

două porturi USB (ce pot fi utilizate pentru atașarea diverselor dispozitive externe: mouse / tastatură / etc.)

un port Ethernet

un port HDMI (pentru conectarea la un monitor)

procesor (700 Mhz, cu posibilitate de overclock până la 1000 Mhz)

RAM (512 MB)

conector miniUSB (pentru alimentare)

cititor de carduri SD

placă audio

led-uri (pentru supravegherea funcționalității)

alți conectori

Laptop:

sistem de operare: Windows

aplicație instalată (client VoIP): X-Lite

poate fi conectat prin Wi-Fi / Ethernet

card reader (pentru configurarea Asterisk)

Smartphone:

sistem de operare: Android

aplicație instalată: Zoiper

se poate conecta doar prin Wi-Fi

Router VoIP Grandstream HandyTone 502

un port WAN (pentru conectarea la rețea)

un port-uri LAN (utilizat doar pentru configurare)

un alimentator

un buton pentru resetare

două porturi (configurabile VoIP) pentru conectarea telefoanelor analogice

Configurarea rețelei de telefonie VoIP

Pasul 1: Formatare card SD

Acest lucru se realizează cu ajutorul aplicației „SD Formatter” ce poate fi descărcată de la adresa www.sdcard.org. Se fac următoarele setări:

la secțiunea „Drive”, se alege litera corespunzătoare cardului SD

din meniul „Options”, la „Format size adjustment”, opțiunea „ON”, după care se apasă butonul „Format”

operațiunea ar trebui să se încheie cu mesajul „Memory Card Format complete!”

Pasul 2: Instalare RasPBX pe cardul SD

Se descarcă imaginea „raspbx-14-02-2014.img” de pe site-ul www.raspberry-asterisk.org și cu ajutorul programului Win32DiskImager se scrie imaginea pe card:

se selectează fișierul descărcat și se apasă butonul „Write”

această etapă ar trebui să se încheie prin mesajul „Write successful.”

Pasul 3: Pornirea centralei VoIP

Se conectează cardul SD (deja configurat cu imaginea Asterisk) în slotul SD al plăcuței de dezvoltare Raspberry PI, urmând alimentarea acesteia de la priză, cu ajutorul conectorului conectorului miniUSB.

Pasul 4: Configurarea abonaților în centrala VoIP

După pornirea sistemului, interfața GUI (Graphical User Interface) a software-ului de configurare poate fi accesată cu ajutorul oricărui dispozitiv din rețea, accesând adresa http://raspbx/ sau http://raspbx.local/ dintr-un browser de internet.

Cu ajutorul unui unui nume de utilizator și a unei parole, se accesează secțiunea „FreePBX Administation”. În configurația standard, aceste credențiale sunt:

Utilizator: admin

Parolă: admin

În următoarea fereastră, din meniul „Applications” – „Extensions”, se selectează opțiunea „Generic SIP device”, apoi se apasă butonul „Submit”.

Ajunși în meniul „Add SIP Extension”, se va crea primul „utilizator al acestui sistem VoIP”, prin completarea următoarelor rubrici:

User Extension: 1001 (numărul de apelare a acestui utilizator)

Display Name: Laptop (numele utilizatorului)

Secret: abcd1234 (parola utilizatorului)

Pentru configurarea „basic”, completarea acestor câmpuri este suficientă, astfel se va finaliza operațiunea prin apăsarea butonului „Submit”. La fel se va proceda pentru crearea fiecărui utilizator în parte:

Utilizator: Laptop / Număr: 1001 / Parolă: abcd1234

Utilizator: Smartphone / Număr: 1002 / Parolă: abcd1234

Utilizator: Phone / Număr: 1003 / Parolă: abcd1234

Pasul 6: Aflarea adresei IP a serverului VoIP

Pentru a ne putea conecta la server de pe clienții VoIP este strict necesară adresa numerică a acestuia. Pentru a vedea acest IP, există mai multe variante; una dintre ele este să ne conectăm la Raspberry PI, de pe Laptop, prin SSH, cu ajutorul unui soft numit „Putty”. Secure Shell sau SSH este un protocol de rețea ce permite ca datele să fie transferate folosind un canal securizat între dispozitive.

În Putty, se bifează opțiunea „SSH”, se va scrie la rubrica „Host Name”, „raspbx” sau „raspbx.local” și se va apăsa butonul „Open”.

Odată stabilită conexiunea securizată, se va face autentificarea cu username-ul „root” și parola „raspberry”. Comanda care ajută la aflarea adresei numerice prin care Raspberry-ul se conectează la rețea este „ifconfig”. După folosirea acesteia, ni se vor afișa o serie de informații printre care se va regăsi și IP-ul căutat: 192.168.0.106

Pasul 5: Configurările necesare pe dispozitivele conectate la acest sistem VoIP

Configurare Laptop:

Acest dispozitiv, întrucât beneficiază atât de un port Ethernet, cât și de o placă ce permite conexiune fără fir, se va conecta la rețea prin oricare din aceste metode.

Pentru conectarea la serverul VoIP este nevoie de un client VoIP instalat. Acesta poate fi orice aplicație de tipul 3CX, Bria, Zoiper, etc. Pentru exemplificare va fi folosită aplicația numită X-Lite.

Din meniul „Account Settings” se va adăuga un nou cont. Rubricile importante pentru această etapă sunt:

User ID: 1001 (numărul de telefon)

Domain: 192.168.0.106 (adresa centralei VoIP)

Password: abcd1234 (parola de utilizator)

După apăsarea butonului „OK” se va observa că aplicația s-a conectat la server și că primul apel poate fi efectuat.

Configurare Smartphone:

Fiind vorba despre un Smartphone bazat pe sistemul de operare Android, voi descărca din magazinul Google Play aplicația Zoiper. La fel ca în cazul Laptop-ului, există mai mai multe variante ce pot fi utilizate ca și aplicație „client”.

Din meniul „Config” – „Accounts”, voi alege opțiunea „Add SIP account”. Rubricile care trebuie configurate, sunt:

Host: 192.168.0.106 (adresa centralei VoIP)

Username: 1002 (numărul de telefon)

Password: abcd1234 (parola de utilizator)

Operațiunea ar trebui să se încheie prin mesajul „Account is ready”

Configurare Phone:

Așa cum am precizat la început, telefonul clasic poate fi conectat la acest sistem cu ajutorul unui dispozitiv ce permite introducerea datelor de utilizator pentru a facilita conexiunea VoIP. Astfel, telefonul nefiind un echipament VoIP, nu vor fi necesare setări pentru acesta; configurarea este stric legată de router-ul VoIP folosit.

Pentru modelul Grandstream HandyTone 502, voi preciza mai întâi modul de conectare. HT 502 dispune de un port Ethernet WAN și unul LAN. Cel WAN va fi utilizat pentru conectarea cablului Ethernet ce provine din unul din porturile LAN ale routerului TP-Link. Cel de-al doilea port Ethernet de pe HT 502 (portul LAN) va fi folosit pentru a accesa interfața de configurare astfel: se va stabili conexiunea de pe un Laptop / PC la acest port și se va accesa adresa http://192.168.1.2/ cu ajutorul unui browser.

Întrucât serviciul de DHCP este activat pe rețea, routerul HT 502 va fi setat, din meniul „BASIC SETTINGS” să primească o adresă IP în mod dinamic. DHCP (prescurtat de la Dynamic Host Configuration Protocol) este un protocol de rețea prin care gazdelor (clienți DHCP) li se atribuie adrese IP și alte informații de configurare de rețea importante în mod dinamic. Astfel conexiunea cu rețeaua se efectuează într-un mod extrem de comod.

Atât în meniul „FXS PORT1” cât și în „FXS PORT2” se vor adăuga setările pentru VoIP (setările se fac pe ambele interfețe pentru a putea conecta telefonul la oricare din porturile RJ11: Phone1 sau Phone2):

SIP Server: 192.168.0.106 (adresa centralei VoIP)

SIP User ID: 1003 (numărul de telefon)

Authenticate Password: abcd1234 (parola de utilizator)

Protocolul de inițializare a sesiunii (sau SIP, din engl. Session Initiation Protocol) este un protocol de semnalizare aflat la nivelul aplicație în stiva OSI, utilizat pentru crearea, modificarea și încheierea sesiunilor între doi sau mai mulți participanți. Astfel de sesiuni includ apeluri telefonice prin Internet, sesiuni multimedia, conferințe multimedia.

Pasul 6: Verificarea configurațiilor

Pentru a verifica dacă setările au fost corect implementate (dacă toți 3 utilizatorii sunt conectați la centrală), se poate accesa din nou, cu ajutorul unui browser, de pe un Laptop/PC din rețea, adresa: http://raspbx/ sau http://raspbx.local/, se face autentificarea în secțiunea de administrare cu username-ul „admin” și parola „admin” și se observă tabelul cu statistici care indică faptul că exitsă 3 dispozitive conectate (Laptop, Smartphone și Phone).

Pasul 7: Apelarea

Apelul simulat poate fi inițiat de pe oricare din cele 3 dispozitive conectate. Se va apela de pe telefonul clasic „Phone”, pe dispozitivul „Smartphone” la numărul 1002.

În timpul apelului / convorbirii, în interfața GUI a PBX-ului, acest lucru este notificat.

Concluzii

Scopul acestei lucrări este de a demonstra utilitatea și necesitatea implementării tehnologiei VoIP în domeniul transporturilor rutiere. Pentru ca acest scop să poată fi atins, a fost necesară punctarea câtorva aspecte ce țin de generalitățile transportului rutier, modul în care este transmisă informația în rețelele de calculatoare actuale, semnalizări și protocoale Voice over IP, etc.

Primul capitol vorbește despre importanța sistemelor inteligente de transport și posibilitățile pe care integrarea serviciilor de transmitere a vocii prin protocolul internet le oferă. Urmărind aspectele prezentate se pot observa anumite beneficii aduse de noile tehnologii în cadrul serviciilor de transporturi.

În capitolul 2 au fost subliniate aspectele esențiale ce țin de conectivitatea calculatoarelor și au fost prezentate detaliat elementele ce transformă Internetul într-o soluție viabilă pentru dezvoltarea de noi tehnologii bazate pe această infrastructură.

Rolul aplicației practice este de a evidenția funcționalitatea unui astfel de sistem și ușurința implementării lui.

În ultimele două decade, nivelul dezvoltării din punct de vedere tehnologic a crescut drastic iar tendința actuală este de a se ajunge la ceea ce oamenii domeniului numesc „internetul lucrurilor”. La un astfel de nivel, fiecare obiect ce se va putea conecta la Internet, va fi conectat.

Presupunând că tehnologia va continua evoluția ascendentă în această direcție, se va ajunge în punctul în care automobilele vor avea acces nelimitat la rețea.

Astfel, existând acces permanent, din orice loc, la rețeaua globală, se pune problema dacă nu cumva va fi necesară implementarea serviciilor de transmitere a vocii prin IP la scară tot mai mare.

În aplicația practică s-a introdus, în rețeaua internă, o centrală telefonică VoIP. Dacă aceasta primește o adresă publică ea va putea fi accesată de oriunde din rețeaua globală, permițând oricărui utilizator conexiunea pe baza unui cont și a unei parole de autentificare. Pe viitor, astfel de centrale vor fi extrem de utilizate deoarece oamenii vor fi tentați să comunice printr-o infrastructură deja existentă.

În transportul rutier, de exemplu, există posibilitatea ca viitorii șoferi să poată comunica prin astfel de tehnologii unii cu alții sau chiar cu echipajele de intervenție în cazurile extreme.

În concluzie se poate spune că un sistem VoIP se adaptează cu foarte mare ușurință nu numai la cerințele exigente ale transportului rutier, ci a oricărui domeniu ce necesită transferul vocii la un cost extrem de redus, atât pe distanțe de câțiva metrii, cât și pe distanțe foarte mari – de ordinul miilor de kilometrii, datorită răspândirii Internetului la nivel global.

Bibliografie

M. Minea, F.D. Grafu, M.C. Surugiu – „Sisteme inteligente de transport”. Editura MATRIX ROM, București 2007

Dr. Ing. Florin Domnel Grafu – „Comunicații de voce și comunicații de date prin Internet Protocol (VoIP și VPN). Aplicații în Sisteme Inteligente de Transport (ITS).” Editura LUMEN, Iași 2010

http://www.its-romania.ro;

http://www.netacad.com; – Curs CCNA;

http://www.cisco.com;

RFC (Request for Comments)

http://www.ietf.org/rfc/rfc3350.txt (RFC 3350 – „RTP: A Transport Protocol for Real-Time Applications”);

http://www.ietf.org/rfc/rfc2326.txt (RFC 2326 – „Real Time Streaming Protocol (RTSP)”);

http://www.ietf.org/rfc/rfc3261.txt (RFC 3261 – „SIP: Session Initiation Protocol”)

http://www.raspberrypi.org;

http://www.raspberry-asterisk.org;

http://en.wikipedia.org/wiki/H.323 (Wikipedia).

Bibliografie

M. Minea, F.D. Grafu, M.C. Surugiu – „Sisteme inteligente de transport”. Editura MATRIX ROM, București 2007

Dr. Ing. Florin Domnel Grafu – „Comunicații de voce și comunicații de date prin Internet Protocol (VoIP și VPN). Aplicații în Sisteme Inteligente de Transport (ITS).” Editura LUMEN, Iași 2010

http://www.its-romania.ro;

http://www.netacad.com; – Curs CCNA;

http://www.cisco.com;

RFC (Request for Comments)

http://www.ietf.org/rfc/rfc3350.txt (RFC 3350 – „RTP: A Transport Protocol for Real-Time Applications”);

http://www.ietf.org/rfc/rfc2326.txt (RFC 2326 – „Real Time Streaming Protocol (RTSP)”);

http://www.ietf.org/rfc/rfc3261.txt (RFC 3261 – „SIP: Session Initiation Protocol”)

http://www.raspberrypi.org;

http://www.raspberry-asterisk.org;

http://en.wikipedia.org/wiki/H.323 (Wikipedia).