UNIVERSITATEA “STEFAN CEL MARE’’ DIN SUCEAVA

FACULTATEA DE INGINERIE ELECTRICĂ ȘI ȘTIINȚA CALCULATOARELOR

REȚELE DE COMUNICAȚII ȘI CALCULATOARE AN II

Implementarea sistemelor
de videoconferință
HD și WebRTC

Student:

Grupa:31121a

Suceava, 2019
Cuprins

Introducere..................................................................................................................................................2
Viteza de transfer necesară unei videoconferințe.........................................................................................2
Lățimea de bandă și QoS.............................................................................................................................2
Conexiuni de rețea convergente...................................................................................................................4
Legături de rețea dedicate............................................................................................................................4
Soluții pentru eficientizarea utlizării videoconferințelor..............................................................................5
Extinderea lățimii de bandă.....................................................................................................................5
Limitarea cererii de conferințe.................................................................................................................5
Compresie și accelerare a aplicației.........................................................................................................5
Codificarea video scalabilă (SVC)..........................................................................................................5
Trafic în timp real....................................................................................................................................6
Securitate și partajarea aplicațiilor...............................................................................................................6
Conexiuni în timp real prin VPN-uri...........................................................................................................6
WebRTC.....................................................................................................................................................7
Comunicare în timp real în WebRTC..........................................................................................................8
MCU (Multipoint Control Units).............................................................................................................8
Unitate de expediere selectivă.................................................................................................................9
MESH......................................................................................................................................................9
Componentele WebRTC...........................................................................................................................10
Session Description Protocol.................................................................................................................10
Fluxul media..........................................................................................................................................10
RTCPeerConnection..............................................................................................................................10
RTCDataChannel..................................................................................................................................11
Soluții de stocare pentru comunicații în timp real (RTP)...........................................................................11
Azure Storage Table..............................................................................................................................11
OrigoDB................................................................................................................................................11
Concluzie...................................................................................................................................................12
Introducere
Utilizarea conferințelor video ca instrument cheie de comunicare are un impact semnificativ în
eficiența și productivitatea unei întreprinderi.  Conectarea rapidă dintre superiori și anagajați
dincolo de granițele geografice oferă o relație mai strânsă de lucru, economisește timp, și permite
întreprinderilor să utilizeze talentul divers din diferite părți ale lumii pe sarcini comune.
Implementarea videoconferințelor de înaltă calitate creează noi provocări pentru cei care le
implementează. Nici o dimensiune nu se potrivește tuturor atunci când vine vorba de cerințele
pentru videoconferințe.

Viteza de transfernecesară unei videoconferințe

Cea mai importantă diferență dintre tradiționala videoconferință H.323 și videoconferința HD
este creșterea cererii pentruviteza de transfer. În timp ce un video tradițional într-o conexiune de
conferință ar putea utiliza 384Kbps sau 512Kbps din lățimea de bandă necesară transportului de
date, sistemele HD pot folosi mai mult cum ar fi 4 Mbps de transport audio și video. În tabelul
de mai jos este prezentată analiza traficului în cazul unei videoconferințe tradiționale și cele HD.

Tabel 1- Ratade transmisienecesară pentru conferințele video

Lățimea de bandă Server Client

necesară Intrare Ieșire Intrare Ieșire
SD 256 256 128 128
HQ 512 512 256 256
ED 1024 1024 512 512
HD 1920 1920 1024 1024
FullHD 4096 4096 2048 2048
WQHD 8192 8192 4096 4096
UltraHD 16384 16384 8192 8192

Lățimea de bandă și QoS

Utilizarea lățimii de bandă este parte integrantă a calității serviciului (QoS).Trebuie să existe o
viteză de transfer de date suficientă pe fiecare legătură pentru catraficul de date să fie realizat în
timp real. Densitatea și modelele apelurilor trebuie estimate pe baza utilizării preconizate.
Destinațiile de apel sunt estimate prin cunoștințele despre afacerea și modelele de apel ale
utilizatorilor. Ca și metodă de deducerese creează o foaie de calcul care estimează cantitatea de
de date video utilizată la conferințe simultan de la fiecare locație majoră până la alte locații în
timpul cele mai aglomerate ore ale zilei în rețeaua companiei.

Tabelul 2 și Figura 1 prezintă rezultatele unui astfel de studiu. În acest exemplu, o întreprindere
cu opt birouri este conectată la un furnizor comun de servicii cu o conexiune de rețea de tip
MPLS. Este creată o foaie de calcul cu numărul convorbirilor simultane de videoconferință
pentru fiecare dintre acestea în timpul orelor aglomerate ale activității (tabelul 2). De reținut este
faptul căun birou poate fi indisponibil la o anumită oră și e posibil să nu coincidă cu ora de lucru
a unui alt birou, în funcție de fusul orar și de natura afacerii.
Tabel 2- Exemple de cereri de videoconferință HD

București Beijing Tokio Seattle Detroit New York Londra Berlin

București 0 1 1 1 1 1 1 0
 Beijing 1 0 1 1 1 1 1 0
Tokio 1 1 0 1 1 1 1 1
Seattle 1 1 1 0 1 1 1 1
Detroit 1 1 1 1 0 1 1 1
New York 1 1 1 1 1 0 1 0
Londra 1 1 1 1 1 1 0 0
Berlin 0 0 1 1 1 0 0 0
TOTAL 6 6 7 7 7 6 6 3

Numărul total de videoconferințe HD a fost înmulțit cu 1920Kbpsplus 20% din rezultatul

înmulțirii pentru a rezulta traficul de date necesar unei videoconferințe HD. Pentru acest
exemplu, legătura MPLS cu fiecare birou trebuie să fie suficient de mare pentru a sprijini aceste
niveluri de videoconferință, și să susțină simultan traficul de date din birou.
Figura 1- Viteza de transfer necesară pentru fiecare conferință în funcție de oraș

16

14

12

10

București Beijing Tokio Seattle Detroit New York Londra Berlin

Figură 1-Formula de calcul a vitezei de transfer

Componentele cheie de infrastructură ale sistemului videoconferințelor necesită o atenție

deosebită. Dacă șase videoconferințe sunt implicate într-un apel de conferință, toate cele șase au
stabilite o conexiune de transmitere full duplex de tip bridge. Conectarea la rețeaua de tip bridge
trebuie să poată susține maximul numărului de obiective care se vor desfășura în cadrul unei
conferințe simultane deapeluri video. Astfel, bridge-ul trebuie plasat în apropierea miezului de
rețea în cazul în care lățimea de bandă este mai abundentă. În plus, bridge-ul ar trebui să fie
plasat în instalația în care se află cel mai mare procent de utilizatori ai apelurilor de conferință în
scopul minimizării traficului necesar pentru a sprijini aceste apeluri de conferință ale rețelei
WAN.Fiecare client care se conectează la bridge va avea un trafic de date negociat pentru
această conferință video în funcție de lățimea de bandă. Dacă fiecare client are negociat un apel
de lățime de bandă de 1,9 Mbps și există 6 clienți, bridge-ul va fi de 1,9 Mbps x 6, adică de 11,5
Mbps. Când adăugăm lățimea de bandă suplimentară de 20% necesară pachetelor IP, se ajunge la
13,8 Mbps.
Conexiuni de rețea convergente
Conexiunile de rețea convergente sunt acele conexiuni în care atât traficul de date cât și traficul
în timp real (voce sau video) sunt suportate în același timp. Există doi parametri care trebuie luați
în considerare atunci când are loc evaluarea legăturilor WAN. În primul rând, lățimea de bandă
alocată clasei QoS care transportă video-ul ar trebui să sprijine cererea de vârf calculat și să fie
utilizată în proporție de 90%.Al doilea parametru este utilizarea totală a lățimii de bandă a
legăturii, inclusiv componentele în timp real și componentele de date. Este clar ca să se
determine înainteviteza de transfer de date necesară aplicațiilor în timp real, dar determinarea și
nevoile aplicațiilor de date sunt mult mai dificile. Aplicațiile de date depind de viteza de transfer
pentru obținerea de performanțe mai bune. Dacă lățimea de bandă a unui link este limitată la
consumul mediu al aplicațiilor de date, aplicațiile în sine încetinesc, creând frustrarea
utilizatorilor și productivitate redusă.  Implementarea unui optimizator WAN poate fi o abordare
pentru a crește eficiența de transfer de date și pentru a reduce nevoia de a utiliza o viteză de
tranfer mai mare pentru aplicațiile de date. Cu toate acestea, traficul în timp real trebuie tratat
diferit de optimizatorul WAN, astfel încât asupra traficului să fie făcute modificari minime.

Legături de rețea dedicate

Legăturile de rețea dedicate sunt transportatoare de date în timp real. Pentru legături dedicate
exclusiv traficului vocal, sunt posibile utilizări foarte mari. Pentru traficul care include
videoconferințe, care este mai mare decât cel de voce, ar trebui respectată o limită de utilizare de
70%. Pot fi utilizate până la 80% cu viteze mari (100 Mbps și mai mare), din moment ce
numărul de fluxuri este mult mai mare și impetuozitatea unui flux individual are un impact mai
mic asupra linkului.

Soluții pentru eficientizarea utlizării videoconferințelor

Dacă analiza rețelei determină că nu există suficientă viteză de transfer a datelor pe legături
critice, întreprinderea are câteva opțiuni pentru a rezolva problema:
• Actualizarea vitezei de transfer
• Reducerea cererii de conferințe vocale sau video
• Aparate de compresie / accelerare a aplicației
• Codare video scalabilă (SVC)
Extinderea lățimii de bandă - este posibilă o actualizare a lățimii de bandă și poate fi singura
soluție dacă este disponibilă o viteză de transfer insuficientă pentru a efectua încărcarea necesară
pentru conferințele vocale sau video.

Limitarea cererii de conferințe - A doua opțiune este limitarea cererii de videoconferințe.

Acest lucru se poate face într-un număr de moduri diferit. În primul rând, lățimea de bandă
utilizată de apeluri pentru videoconferințe poate să fie limitată. O calitate video mai bună HD
poate fi obținută la 4 Mbps dar o calitate destul de bună poate fi obținută la 2 Mbps și chiar la 1
Mbps. Așa cum este precizat anterior, adoptarea profilului de calitate poate reduce nevoia de
viteză de transfer cu până la 50%.

O a doua modalitate de a reduce cererea este de a gestiona volumul apelurilor astfel încât un
număr limitat de apeluri poate apărea simultan în fiecare legătură.Gatekeeper-ul de conferință
vocală sau conferință video poate fi, de asemenea, utilizat pentru a ajuta la gestionarea utilizării
vitezei de transfer. Gatekeeper-ului îi poate fi alocat o lățime de bandă maximă disponibilă între
grupuri de puncte finale, care se referă la topologia rețelei. Gatekeeper-ul va permite numai
apeluri prin această legătură până la lățimea de bandă disponibilă în timp real alocată acelei
legături. Lățimea de bandă dată gatekeeper-ului este cantitatea maximă de trafic în timp real
permisă pe acea legătură, și nu capacitatea legăturii. Odată ce utilizarea legăturii atinge acest
maxim, gatekeeper-ul va refuza cererile de apel suplimentare.

Compresia și accelerarea aplicației- Datele video sunt substanțiale, iar când lățimea de bandă
sau stocarea datelor sunt limitate, aceasta trebuie comprimată cu scopul de a maximiza reducerea
datelor, menținând în același timp calitatea. Gradul de reducere a datelor se măsoară prin
mărimea fizică a octeților care este stocată sau prin rata de biți atunci când sunt transmise datele,
însă calitatea video este măsurată prin rezoluție sau prin numărul de pixeli din fiecare
dimensiune a imaginii. AplicațiileWAN utilizează diverse trucuri atât pentru a reduce traficul de
date, cât și pentru a crește simultan performanța aplicației. Acesteautilizează compresia, cache,
terminale TCP, transformări transparente, reducerea și alte tehnici pentru a-și atinge obiectivele.

Codificarea video scalabilă (SVC)- Tehnologia SVC oferă o structura de date cu mai multe
straturi, care permite sistemelor să se adapteze rețelelor variabile pentru a îmbunătăți rezoluțiile,
rata cadrelor și calitatea fluxurilor video. SVC este o extensie la H.264. Codurile avansate de
codare video (AVC) permit o calitate video mai bună la întâlnirile de colaborare chiar dacă
condițiile de rețea sau capacitățile clientuluisunt limitate. SVC este cea mai utilă atunci când
lățimea de bandă disponibilă nu poate fi controlată în mod explicit.

Securitatea și partajarea aplicațiilor

Aplicațiile dedicate videoconferințelor pot oferi securitate prin impunerea de parole și prin
furnizarea de date criptate. Videoconferința ridică probleme de securitate a rețelei, deoarece
punctele de terminare au nevoie de acces la rețelele celorlalți pe care firewall-urile le pot bloca.
Unele instrumente de videoconferință pot găzdui mai bine firewall-urile, deoarece utilizează mai
puține porturi sau mai multe porturi comune care de obicei sunt deschise. Când securitatea
încorporată lipsește, aceasta poate fi furnizată prin alte mijloace, de exemplu prin rularea
software-ului virtual de rețea și prin oferirea unei conferințe asupra acestuia.

Software-ul pentru videoconferințe poate avea metode integrate pentru partajarea de diapozitive,
procesare de text și alte aplicații pe un computer, în timp ce dispozitivele hardware de
videoconferință permit utilizatorilor să introducă date de pe un computer o altă sursă de
informație și îl transmite ca video de înaltă rezoluție. Dacă mecanismele de partajare a
conținutului lipsesc, pot fi instalate programe software suplimentare pe computere pentru a le
furniza și se pot realiza două conexiuni, una pentru videoconferință și una pentru comunicații.

Conexiuni în timp real prin VPN-uri

Multe întreprinderi mici și mijlocii din ziua de azi au avantajul utilizării rețelelor virtuale private
(VPN) pentru a le conecta birourile distribuite geografic în întreaga lume. VPN-urile creează un
tunel de cod criptat prin internetul public. Avantajul principal al unei rețele VPN este faptul că
costul este adesea mult mai mic decât o conexiune dedicată. VPN-urile Enterprise se găsesc în
două forme, cele care conectează două birouri printr-un singur furnizor WAN și cele care
utilizează rețeaua de internet, astfel încât aceștia pot utiliza mai mult de un furnizor de servicii și
punctele asociate acestora.Traficul de date în timp real prin aceste VPN-uri este riscant deoarece
nu există de obicei o capacitate QoS oferită în conexiunea VPN. Calitatea poate fi bună atunci
când oferă un singur furnizor de servicii conectivitate la ambele capete, dar din nou fără garanții
pentru viteza de transfer. În cazul în care așteptările privind calitatea sunt ridicate, cum ar fi
sprijinul personalului de conducere la întâlniri, actualizări de vânzări, prezentarea clienților și
vizualizare altor clienți, riscul de degradare a calității și eșecul apelurilor poate fi prea mare
pentru a utiliza un VPN.

WebRTC
WebRTC este un proiect open source cu un efort de a aduce API-urile RTC dezvoltatorilor
JavaScript, permițând aplicațiilor web să suporte diferite funcții RTC precum apelarea vocală,
chat-ul video și partajarea de fișiere P2P prin intermediul browserului web . API-urile WebRTC
funcționează prin combinarea a două tehnologii, Hyper Text Markup Language (HTML) și
JavaScript.WebRTC în combinație cu alte tehnologii precum XSockets, Node.js, Vconect,
OpenCV, Kinect, Kurento și alte API-uri oferă o mulțime de atracții caracteristici și funcții,
inclusiv detectarea în timp real și recunoașterea fețelor, emoții, gesturi direct din browser. Acesta
permite aplicațiilor RTC de înaltă calitate să fie dezvoltate pentru platforme de browser,
dispozitive mobile și dispozitive IoT și să le permită tuturorcomunicarea printr-un set comun de
protocoale.

Figură 2- Browser WebRTC Figură 3- Trapezoid WebRTC

În Figura 2, există trei straturi, Web Server pe partea de sus, aplicația dezvoltată cu JavaScript /
în mediul HTML / CSS și sistemul de operare nativ în partea de jos. Aplicația se conectează la
serverul Web cu HTTP / WebSocket. HTTP este folosit pentru a trimite cererea și a primi
răspuns. Practic, este folosit pentru preluarea aplicației. WebSocket este utilizat pentru
configurarea conexiunii la WebServer și permite serverului să trimită date către aplicație.
Aplicația ajută la apelarea API WebRTC pentru a controla browserul Web și pentru a invoca
funcțiile RTC ale browserului, atunci utilizează resurse din sistemul nativ sau comunicarea cu
clientul de la distanță.

Figura 3 prezintă trapezoidul WebRTC și comunicarea în timp real în browser. În partea de jos
din stânga, browser-ul unui client stabilește o comunicare cu serverul Web folosind HTTP /
WebSockets, și același lucru pentru browserul altui client în partea de jos din dreapta. Web
serverele ajută la configurarea căii de semnalizare. Prin schimbul de informații între clienți și
prin calea de semnalizare, poate fi construită calea media. Pentru a realiza semnalizarea, un
client poate trimite informații către un anumit client la distanță. În timp ce clientul la distanță
primește informațiile și le trimite către expeditor.

Arhitectura WebRTC
Diferite arhitecturil ale WebRTC sunt discutate mai departe. Se estimează că până la sfârșitul
anului 2019, mai mult de 2 milioane de dispozitive vor utiliza WebRTC.

Figură 4- Arhitectura generală a WebRTC

MCU (Multipoint Control Units)

Unitatea de control multipunct converge de obicei toate fluxurile video și audio în unul singur
unde toți clienții sunt conectați la portul unic. În MCU serverul primește toate fluxurile de la
clienți apoi decodează și codifică din nou într-un singur flux și apoi îl trimite înapoi la clienții
respectivi. Acest lucru duce la creșterea încărcării pe server cu creșterea numărului de clienți.

Figură 5- Arhitectura MCU

Pe măsură ce numărul de clienți crește, la fel se întâmplă și cu complexitatea implementării, și
numărul acestora. Asa că în cele din urmă obținem o calitate superioară a videoclipului, în
același timp cu un cost mai ridicat în comparație cu alte arhitecturi.

Unitate de expediere selectivă

Selectarea unității de expediere, în SFU, toți clienții trimit fluxuri video diferite, codec-uri
diferite și rate de biți diferite. Serverul convertește toate acestea într-o singură entitate și trimite
asta la toți clienții conectați. În acest caz, clienții vor primi mai multe fluxuri video. SFU
utilizează codecul VP8 pentru fluxurile media care nu este acceptat de unele browsere. SFU cu
simulcast are mai multe beneficii, în acest caz clienții trimit două fluxuri media unul cu rate de
biți ridicate și celălalt cu rate de bit reduse, astfel încât serverul să poată alege bit-rate-ul în
funcție de lățimea benzii. Prin aceasta, latența poate fi scăzută

Figură 6- Arhitectura unității de expediere selectivă

Pe de altă parte, în arhitectura SFU clientul primește mai multe fluxuri media, ceea ce duce la
consumul unei viteze mai mari de transfer pentru downlink decât uplink.

MESH
Arhitectura MESH este una dintre cele mai utilizate arhitecturi din aplicațiile WebRTC. Această
arhitectură este folosită de obicei pentru conferințele multimedia la scară redusă. În această
arhitectură, fiecare client individual se conectează la alt client, iar acesta schimbă fluxurile de
date și media direct între browsere fără implicarea serverului. Acest lucru economisește o
mulțime de costuri pentru întreținerea serverului. Acestă arhitectura bazată pe lățimea de bandă
poate scala până la 10 participanți la distanță.

Figură 7- Arhitectura MESH

După cum putem vedea arhitectura MESH este cea mai potrivită atunci când un utilizator poate
stabiliți o singură conexiune la punctul final.

Componentele WebRTC
Principalul avantaj al WebRTC în comparație cu alte sisteme este că acesta include o unitatea de
conectare interactivă (ICE).

Session Description Protocol

Session Description Protocol (SDP) este un format pentru descrierea parametrilor de inițializare
a mediilor de streaming. SDP nu este responsabil pentru difuzarea mass-media, dardescrie
formatul și tipul de media dintre punctele terminale.

Fluxul media
Fluxul media din WebRTC este responsabil în principal pentru obținereadatelor media de la
clienți. Acesta este, de asemenea, responsabil pentru luarea unei intrări și ieșiri, intrarea este cea
luată de aparatul foto și de microfon, în cazul în care producția este responsabilă pentru
trimiterea fluxurilor media către obiectivele dorite. De obicei, fluxul media este generat de
browser folosind getusermedia (). getusermedia () este API-ul în fluxurile mass-media care
solicită permisiunea clientului de a avea acces pentru utilizarea camerei și microfonului de către
browser. Dacă permisiunea este acordată de client atunci getusermedia () va invoca toți ceilalți
clienți cu o valoare 1, ceea ce înseamnă că ați primit o intrare video, audio sau ecran partajat, în
cazul în care clientul refuză permisiunea pe care o va invoca va fi valoarea 0 .

RTCPeerConnection
În WebRTC, RTCPeerConnection este responsabil pentru stabilirea unei conexiuni de tip peer-
to-peer dintre browsere și, de asemenea, stabilește conexiunea de la starea de semnalizare la stare
stabilă. Arhitectura WebRTC utilizează în principal trei componente diferite, cum ar fi audio,
video și mecanisme de transport. Componenta audio conține codecuri iSAC și iLBC, în principal
codecul iSAC responsabil pentru fluxurile audio. Mecanismul video este responsabil pentru
fluxul video din WebRTC a codecului VP8. Acesta ajută în principal la îmbunătățirea calității
imaginii și a imaginii video. Mecanismul de transport constă în principal în SRTP (Secure Real
Time Protocol) responsabil pentru fluxurile de date din WebRTC.

RTCDataChannel
Fluxurile de datede la clienți din WebRTC sunt schimbate în ambele direcții. Acest schimb se
face prin mecanismul RTCDataChannel. Utilizând RTCDataChannel starea de livrare a
mesajului poate fi cunoscută. Mesajele text și partajarea de fișiere au fost terminate utilizând
RTCDataChannel. Prin aceasta ar exista o latență scăzută.

Soluții de stocare pentru comunicații în timp real (RTP)

Stocarea joacă un rol major în comunicarea în timp real. În proiectarea de stocare pentru RTC,
există mai mulți factori care trebuie luați în considerare, scalabilitatea performanțelor și
costurile. În cadrul unei conferințe când sunt distribuite câteva fișiere importante între
participanți la distanță, uneori mesaje de chat, ar trebui să poată fi arhivate chiar și după
întâlnire, deoarece există multe modalități de a utiliza baze de date pentru stocare precum
OrigoDB, Azure table storage etc.

Azure Storage Table

Azure storage este un produs al Microsoft folosit în mod obișnuit pentru găzduirea,
implementarea și gestionarea aplicațiilor. Azure este una dintre cele mai inteligente soluții pentru
aplicațiile în timp real. Conturile de stocare pe azur rulează pe o nouă topologie de rețea plată și
sprijină pe deplin scalabilitatea, fără a lua în considerare modul în care sunt create.

Figură 8- Mod de funcționare prin intermediul Azure Table Storage

Din figură putem vedea că atunci când un utilizator trimite date către server, serverul va interoga
aceste date cu spațiul de stocare Azure. Datele sunt stocate sub formă de tabele din cloud. Atunci
când un utilizator încearcă să recupereze datele, serverul va prelua din nou datele din tabela de
depozitare Azure.

OrigoDB
OrigoDB este o bază de date care poate fi utilizată pentru stocarea datelor binare în timp real.
OrigoDB folosește memoria RAM ca depozitare primară în server.

Figură 9-Setarea pentru OrigoDB

OrigoDB ajută dezvoltatorii să creeze o bază de date eficientă, cu un cost redus în mai puțin
timp.
Concluzie
Soluțiile pentru videoconferințe bazate pe standarde au promisiunea de interoperabilitate, în timp
ce produsele de calitate pentru consumatori oferă acces gratuit și omniprezent la videoconferințe
pentru o gamă largă de utilizatori. Deși cerințele privind lățimea de bandă reprezintă un factor
limitator, rezoluția crescută oferită poate face ca aceste aplicații să fie deosebit de atractive
pentru clienți. Cu ajutorul WebRTC, dezvoltatorii pot scăpa de obicei cu scrierea câtorva rânduri
de JavaScript pentru care furnizorii furnizează eșantioane de coduri.

Echipele interne de dezvoltare pot gestiona acest nivel de integrare, menținând costul WebRTC
mult mai mic decât cel al soluțiilor tradiționale de videoconferință.Indiferent de modul în care te
uiți la el, WebRTC are un avantaj semnificativ față de costul soluțiilor tradiționale. WebRTC nu
are costuri de licențiere, integrarea se poate face cu abilități de dezvoltare disponibile în mod
obișnuit, iar infrastructurile pot fi închiriate la rate scăzute de abonament. WebRTC elimină
nevoia de cheltuieli mari de capital și oferă promisiunea cost redus.

Bibliografie

[1] Implementation and Performance Optimization of WebRTC Based Remote Collaboration

System, Venkesh Kandari- http://www.diva-portal.org/smash/get/diva2:948261/FULLTEXT02

[2] Research on Development and Evaluation of WebRTC Signaling based on XMPP,Chun Fan-
https://brage.bibsys.no/xmlui/bitstream/handle/11250/2456125/17685_FULLTEXT.pdf?
sequence=1

[3] Hardware and Software Requirements for Video Conferencing, Articol-

https://www.eztalks.com/video-conference/hardware-and-software-requirements-for-video-
cobferencing.html

[4]Internet-Based Videoconferencing Coder/Decoders and Tools for Telemedicine, Wei-Li Liu,

Kai Zhang, Craig Locatis,  Michael Ackerman-
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3135256/

[5]Videoconferencing Software Overview, Articol-

http://www.telehealthtechnology.org/toolkits/videoconferencing/about-this-
technology/videoconferencing-software-overview

[6] Preparing Your IP Network for High Definition Video Conferencing, Articol -
www.polycom.com/.../hd-video-conferencing-wp-enus.pdf

[7] Five Reasons to Choose WebRTC for Video Calling, Articol- https://sightcall.com/five-
reasons-choose-webrtc-video-calling/