Videofonia është mënyra kryesore e komunikimit mes mësuesit dhe nxënësit në platformën Vimbox. Ne prej kohësh kemi braktisur Skype-un, kemi provuar disa zgjidhje të tjera dhe përfundimisht u ndalëm te kombinimi WebRTC - Janus-gateway. Për një kohë na kënaqte, por ndonjëherë disa probleme negative vazhdonin të dilnin në pah. Në fund, u krijua një drejtim i veçantë për videon.
I kërkova Kirill Rogovit, udhëheqësit të këtij drejtimi të ri, që të flasë për evolucionin e videofonisë në Skyeng, problemet e zbuluara, zgjidhjet dhe ndihmat që përfundimisht përdorëm. Shpresojmë që artikulli të jetë i dobishëm për kompanitë që gjithashtu po përpiqen të ofrojnë video përmes aplikacionit web.
Pak histori
Në verën e vitit 2017, kreu i zhvillimit të Skyeng, Sergey Safonov, paraqiti një referat në Backend Conf duke folur për si ne "braktisëm Skype-un dhe implementuam WebRTC". Ata që janë të interesuar mund të shikojnë regjistrimin e prezantimit në (~45 min), dhe këtu unë do ta përmbledh thelbin e tij.
Për shkollën Skyeng, videofonia ka qenë gjithmonë mënyra prioritare e komunikimit mësues-nxënës. Në fillim përdorëm "Skype", por ai na pengonte për një sërë arsyesh, kryesisht për shkak të mungesës së regjistrimeve dhe pamundësisë për t'u integruar direkt në aplikacionin web. Prandaj, ne bëmë disa eksperimente.
Kërkesat tona për videofoninë ishin afërsisht të tilla:
â stabiliteti;
â çmimi i ulĂ«t pĂ«r mĂ«sim;
â regjistrimi i mĂ«simeve;
â monitorimi i kush flet mĂ« shumĂ« (na intereson qĂ« nxĂ«nĂ«sit tĂ« flasin mĂ« shumĂ« se mĂ«suesi gjatĂ« mĂ«simeve);
â shkallĂ«zimi linear;
â mundĂ«sia pĂ«r tĂ« pĂ«rdorur si UDP ashtu edhe TCP.
I pari qĂ« provuam nĂ« 2013 ishte Tokbox. Ădo gjĂ« shkonte mirĂ«, por ishin shumĂ« tĂ« shtrenjta â 113 rubla pĂ«r mĂ«sim â dhe haraçonte fitimin.
Pastaj, në 2015, integuam Voximplant. Këtu kishte funksionin e nevojshëm për monitorimin e kush flet më shumë, dhe zgjidhja ishte ndjeshëm më e lirë: me regjistrimin vetëm të zërit, përfundonte në 20 rubla për mësim. Megjithatë, funksiononte vetëm përmes UDP, dhe nuk dinte të kalonte në TCP. Megjithatë, përfundimisht rreth 40% e nxënësve e përdorën atë.
Një vit më vonë, filluam të kishim klientë korporativë me kërkesat e tyre specifike. Për shembull, e gjithë duhet të funksiononte përmes shfletuesit, në kompani hapen vetëm http dhe https; dmth, asnjë "Skype" dhe UDP. Klientët korporativë = para, prandaj u kthyem te Tokbox, por problemi i çmimit nuk u zhduk.
Zgjidhja â WebRTC dhe Janus
U mor vendimi për të përdorur . Ajo përgjigjet për vendosjen e lidhjes, kodimin dhe dekodimin e rrjedhave, sinkronizimin e rrugëve dhe kontrollin e cilësisë me trajtimin e problematikave më rrjetin. Nga ana jonë, duhet të sigurojmë leximin e rrjedhave nga kamera dhe mikrofon, vizatimin e videos, menaxhimin e lidhjes, vendosjen e lidhjes WebRTC dhe transmetimin e rrjedhave për të, si dhe transmetimin e mesazheve sinjale mes klientëve për vendosjen e lidhjes (vetë WebRTC përshkruan vetëm formatin e të dhënave, por jo mekanizmin e transmetimit të tyre). Në rast se klientët janë pas NAT, WebRTC lidh STUN serverë, dhe nëse kjo nuk ndihmon, TURN serverë.
Një lidhjeje p2p e zakonshme nuk na mjafton, sepse ne duam të regjistrojmë mësimet për analizë të mëvonshme në rast ankesash. Prandaj, ne dërgojmë rrjedhat WebRTC përmes ritransmetuesit . Si rezultat, klientët nuk dinë adresat njëri-tjetrit, duke parë vetëm adresën e serverit Janus; ai gjithashtu kryen funksionet e serverit sinjalizues. Janus ka shumë funksionalitete që na nevojiten: automatikisht kalon në TCP, nëse klientit i është bllokuar UDP; di të regjistrojë rrjedhat si UDP ashtu edhe TCP; është i shkallëzueshëm; ka madje edhe një plugin të integruar për provat e echo. Në rast nevoje, automatikisht lidhen serverat STUN dhe TURN nga Twilio.
Në verën e vitit 2017, ne kishim dy servera Janus plus një server shtesë për procesimin e skedarëve të regjistruar të zërit dhe videos, për të mos ngarkuar procesorët e serverëve kryesorë. Kur lidhen, serverat Janus zgjidheshin sipas parimit çift-pak (numri i lidhjes). Në atë kohë, kjo ishte e mjaftueshme, sipas ndjenjave tona jepte rreth katër herë rezervë, përqindja e implementimit ishte rreth 80. Ndërkohë, çmimi ishte reduktuar në ~2 rubla për mësim, plus zhvillimi dhe mbështetje.
Kthimi në temën e videofonisë
Ne vazhdimisht monitorojmĂ« feedback-un nga nxĂ«nĂ«sit dhe mĂ«suesit, pĂ«r tĂ« identifikuar dhe adresuar problemet nĂ« kohĂ«. Deri nĂ« verĂ«n e vitit 2018, cilĂ«sia e lidhjes ishte nĂ« krye tĂ« ankesave. Nga njĂ«ra anĂ«, kjo tregonte se kishim pĂ«rmirĂ«suar mangĂ«sitĂ« e tjera. Nga ana tjetĂ«r, duhej tĂ« vepronim urgjentisht: nĂ« rast tĂ« ndĂ«rprerjes sĂ« njĂ« mĂ«simi, rrezikojmĂ« tĂ« humbasim vlerĂ«n e tij, ndonjĂ«herĂ« edhe koston e blerjes sĂ« paketĂ«s sĂ« ardhshme, dhe nĂ« rast tĂ« ndĂ«rprerjes sĂ« njĂ« lekcioni hyrĂ«s â pĂ«rfundimisht tĂ« humbasim njĂ« klient potencial.
NĂ« atĂ« kohĂ«, video lidhja jonĂ« ishte ende nĂ« modusin MVP. ThĂ«nĂ« mĂ« thjesht, e aktivizuam, funksionoi, e zgjatĂ«m njĂ« herĂ«, e kuptuam se si ta bĂ«nim â dhe mjaft. If it works, donât fix it. Askush nuk kishte marrĂ« pĂ«rsipĂ«r tĂ« shqyrtonte problemin e cilĂ«sisĂ« sĂ« lidhjes. Deri nĂ« gusht, u bĂ« e qartĂ« se kĂ«shtu nuk mund tĂ« vazhdohej, dhe ne filluam njĂ« drejtim tĂ« veçantĂ« pĂ«r tĂ« kuptuar se çfarĂ« nuk po funksiononte me WebRTC dhe Janus.
Ky drejtim fillimisht kishte: një zgjidhje MVP, asnjë metrikë, nuk kishte objektiva, as procese për përmirësim, dhe megjithatë 7% e mësuesve ankohej për cilësinë e lidhjes (nuk kishte të dhëna për nxënësit).
Drejtimi i ri merr përsipër punën
Komanda duket përafërsisht kështu:
- Kreu i drejtimit, gjithashtu zhvilluesi kryesor.
- QA ndihmojnë në testimin e ndryshimeve, kërkojnë mënyra të reja për të krijuar kushte të paqëndrueshme për lidhjen, raportojnë probleme nga zona e frontit.
- Analisti vazhdimisht kërkon korelacione të ndryshme në të dhënat teknike, përmirëson analizën e feedback-ut të përdoruesve, kontrollon rezultatet e eksperimentëve.
- Menaxheri i produktit ndihmon me drejtimin e përgjithshëm dhe ndarjen e burimeve për eksperimentet.
- Me programimin dhe detyrat e lidhura shpesh ndihmon një zhvillues tjetër.
PĂ«r fillim, konfiguruam njĂ« metrikĂ« relativisht tĂ« besueshme, e cila monitoronte ndryshimet nĂ« vlerĂ«simin e cilĂ«sisĂ« sĂ« lidhjes (mesatarja e ditĂ«ve, javĂ«ve, muajve). NĂ« atĂ« kohĂ«, kĂ«to ishin vlerĂ«sime nga mĂ«suesit, mĂ« vonĂ« u shtuan vlerĂ«simet nga studentĂ«t. MĂ« pas filluam tĂ« formulojmĂ« hipoteza se çfarĂ« nuk po funksiononte, t'i korrigjonim e tĂ« shikonim ndryshimet nĂ« dinamikĂ«. U shpĂ«rngulĂ«m nĂ« fruta tĂ« ultat: pĂ«r shembull, zĂ«vendĂ«suam kodekun vp8 me vp9, dhe treguesit u pĂ«rmirĂ«suan. Provoduam tĂ« eksperimentonim me konfigurimet e Janus, pĂ«r tĂ« kryer eksperimente tĂ« tjera â qĂ« nĂ« shumicĂ«n e rasteve nuk çuan asgjĂ«.
Në fazën e dytë, doli një hipotezë: WebRTC është një zgjidhje peer-to-peer, dhe ne përdorim një server në mes. Ndoshta problemi qëndron këtu? Filluam të thelloheshim dhe gjetëm deri tani përmirësimin më të rëndësishëm.
Në atë kohë, serveri zgjidhej nga rezervuari duke përdorur një algoritëm të thjeshtë: secili kishte një 'peshë' të vet, që varet nga kanali dhe fuqia, dhe ne përpiqeshim të dërgonim përdoruesin në atë, ku 'pesha' ishte më e madhe, pa marrë parasysh se ku ndodhej gjeografikisht përdoruesi. Si rezultat, një mësues nga Shën Petersburg mund të komunikonte me një nxënës nga Siberia përmes Moskës, e jo përmes serverit tonë Janus në Shën Petersburg.
Algoritmi u rishikua: tani, kur pĂ«rdoruesi hap platformĂ«n tonĂ«, ne mbledhim ping-e nga ai deri te tĂ« gjithĂ« serverĂ«t pĂ«rmes Ajax-it. GjatĂ« vendosjes sĂ« lidhjes, ne kemi zgjedhur çiftin e ping-eve (mĂ«sues-server dhe nxĂ«nĂ«s-server) me shumĂ«n mĂ« tĂ« vogĂ«l. MĂ« pak ping â mĂ« pak distanca rrjetore deri te serveri; mĂ« pak distancĂ« â mĂ« e ulĂ«t probabiliteti pĂ«r tĂ« humbur paketa; humbja e paketave â faktor ndikimi mĂ« i madh negativ nĂ« video lidhje. Pjesa negative nĂ« tri muaj ra nĂ« gjysmĂ«n e saj (pĂ«r tĂ« drejtĂ«n e vĂ«rtetĂ«s, nĂ« kĂ«tĂ« kohĂ« u zhvilluan dhe eksperimente tĂ« tjera, por ky ndoshta ka pasur mĂ« shumĂ« ndikim).
KohĂ« mĂ« parĂ« ne zbuluam njĂ« gjĂ« tjetĂ«r qĂ« Ă«shtĂ« jo shumĂ« e dukshme, por duket se Ă«shtĂ« shumĂ« e rĂ«ndĂ«sishme: nĂ« vend tĂ« njĂ« serveri tĂ« fuqishĂ«m Janus nĂ« njĂ« kanal tĂ« gjerĂ«, Ă«shtĂ« mĂ« mirĂ« tĂ« kemi dy servera mĂ« tĂ« thjeshtĂ« me kapacitet tĂ« ulĂ«t. Kjo u zbulua pasi blenĂ« servera tĂ« fuqishĂ«m me shpresĂ«n pĂ«r tĂ« akomoduar sa mĂ« shumĂ« dhoma (seanca komunikimi) njĂ«kohĂ«sisht. Serverat kanĂ« njĂ« limit kapaciteti, i cili mund tĂ« pĂ«rkthehet saktĂ«sisht nĂ« numrin e dhomave â e dimĂ« se sa mund tĂ« hapim, pĂ«r shembull, nĂ« 300 Mbit/s. Sa mĂ« shumĂ« dhoma tĂ« hapen nĂ« server, aq mĂ« pak e zgjedhim pĂ«r aktivitete tĂ« reja derisa ngarkesa tĂ« ulet. Ideja ishte qĂ«, duke blerĂ« njĂ« makinĂ« tĂ« fuqishme, do ta ngarkonim kanalin deri nĂ« maksimum, pĂ«r tĂ« arritur nĂ« fund te procesori dhe memorie, jo te kapaciteti. Por u zbulua se pas njĂ« numri tĂ« caktuar tĂ« dhomave tĂ« hapura (420), pavarĂ«sisht se ngarkimi i procesorit, memorie dhe disku ende ishte shumĂ« larg kufijve, filluan tĂ« vijnĂ« ankesa nĂ« mbĂ«shtetje. Duket se diçka bĂ«het mĂ« e keqe brenda Janus, mundĂ«sisht aty ka ndonjĂ« kufizim tjetĂ«r. Filluam tĂ« eksperimentojmĂ«, ulĂ«m limitin e kapacitetit nga 300 nĂ« 200 Mbit/s, problematikat u larguan. Tani kemi blerĂ« menjĂ«herĂ« tre servera tĂ« rinj me limite tĂ« ulĂ«ta dhe karakteristika, besojmĂ« se kjo do tĂ« çojĂ« nĂ« njĂ« pĂ«rmirĂ«sim tĂ« qĂ«ndrueshĂ«m tĂ« cilĂ«sisĂ« sĂ« lidhjes. Sigurisht, ne nuk u futĂ«m nĂ« hollĂ«sitĂ« e problemit, pasi duhej tĂ« zgjidhnim problemin urgjentisht, e jo ta bĂ«nim atĂ« nĂ« mĂ«nyrĂ« estetike; gjithashtu Janus pĂ«r ne Ă«shtĂ« njĂ« kut i zi, i shkruar nĂ« C, dhe kĂ«rkimi brenda tij Ă«shtĂ« shumĂ« i kushtueshĂ«m.
Në procesin e punës ne:
- përditësuam të gjitha varësitë që mund të përditësoheshin, si në server ashtu edhe në klient (këto ishin eksperimentime gjithashtu, duke ndjekur rezultatet);
- rregulluam të gjitha defektet e identifikuara që përfshinin raste specifike, për shembull, kur lidhja binte dhe nuk riaftësohej automatikisht;
- organizojmë shumë takime me kompani që punojnë në fushën e video komunikimit dhe janë të njohur me problemet tona: ata që transmetojnë lojra, organizojnë webinare; provuam gjithçka që na dukej e dobishme;
- kaluam një rishikim teknik të hardware-it dhe cilësisë së lidhjes nga mësuesit, të cilët kishin më shumë ankesa.
Eksperimentet e kryera dhe ndryshimet që pasuan arritën të reduktonin pakënaqësinë me lidhjen ndërmjet mësuesve nga 7.1% në janar 2018 në 2.5% në janar 2019.
ĂfarĂ« ndodh mĂ« pas
Stabilizimi i platformës sonë Vimbox është një nga projektet kryesore të kompanisë për vitin 2019. Kemi shpresa të mëdha se do të arrijmë të ruajmë dinamikën dhe të mos shohim më video komunikimin në krye të ankesa. E dimë se një pjesë e rëndësishme e këtyre ankesave është e lidhur me vonesat të kompjuterëve dhe internetit të përdoruesve, por duhet të identifikojmë këtë pjesë dhe të zgjidhim gjithçka tjetër. Gjithçka tjetër është një problem teknik, duket se duhet të dimë si të merremi me të.
Vështirësia kryesore është se ne nuk e dimë se deri në çfarë niveli mund të përmirësojmë cilësinë. Zbulimi i këtij kufiri është qëllimi ynë kryesor. Prandaj janë planifikuar dy eksperimente:
- të krahasojmë videon përmes Janus me p2p zakonshëm në kushte reale. Ky eksperiment është kryer, nuk u zbulua asnjë ndryshim statistikorisht të rëndësishëm mes zgjidhjes sonë dhe p2p;
- të vendosim shërbime (të kushtueshme) nga kompani që fitojnë ekskluzivisht nga zgjidhjet e video komunikimit dhe të krahasojmë sasinë e ankesa nga ato me ato ekzistuese.
Këto dy eksperimente do të na lejojnë të përcaktojmë një qëllim të arritshëm dhe të përqendrohemi te ai.
Përveç kësaj, ka një sërë detyrash që zgjidhen në procesin e punës:
- krijojmë një metrikë teknike të cilësisë së lidhjes në vend të komenteve subjektive;
- po bëjmë log-e më të detajuara të seancave, për analizuar më saktësisht dështimet që ndodhin, duke kuptuar kur dhe ku ndodhin ata, çfarë ngjarjesh dukshëm të lidhura ndodhin në atë moment;
- po përgatisim një test automatik të cilësisë së lidhjes para mësimit, dhe gjithashtu do t'i japim mundësinë klientit të testojë manualisht lidhjen, për të reduktuar sasinë e pakënaqësisë që shkaktohet nga hardware dhe kanali i tij;
- do të zhvillojmë dhe do të kryejmë më shumë teste të ngarkesës për video komunikimin në kushte të këqija, me humbje të paketave të ndryshueshme etj.;
- po ndryshojmë sjelljen e serverëve në rast probleme për të rritur qëndrueshmërinë në rast të dështimit;
- do të paralajmërojmë përdoruesin nëse ka ndonjë problem me lidhjen, siç e bën p.sh. 'Skype', në mënyrë që ai të kuptojë se problemi është nga ana e tij.
Që nga prilli, drejtimi i videotelefonisë bëhet një projekt tërësisht i veçantë brenda Skyeng, që merret me produktin e vet, dhe jo thjesht me një pjesë të Vimbox. Kjo do të thotë se kemi filluar të kërkojmë njerëz për . Si gjithmonë, .
Dhe, sigurisht, vazhdojmĂ« tĂ« komunikojmĂ« aktivisht me njerĂ«z dhe kompani qĂ« punojnĂ« me videotelefoninĂ«. NĂ«se dĂ«shironi tĂ« shkĂ«mbeni pĂ«rvoja me ne â do tĂ« jemi tĂ« lumtur! Komentoni, kontaktoni â do t'ju pĂ«rgjigjemi tĂ« gjithĂ«ve.
Burimi: habr.com
