Videoconferenca Ă«shtĂ« mĂ«nyra kryesore e komunikimit midis profesorĂ«ve dhe studentĂ«ve nĂ« platformĂ«n Vimbox. Ne kemi hequr dorĂ« nga Skype-i, kemi provuar disa zgjidhje tĂ« tjera dhe pĂ«rfundimisht u ndaluam te kombinimi WebRTC â Janus-gateway. PĂ«r njĂ« kohĂ« tĂ« gjatĂ« ishim tĂ« kĂ«naqur, por gjithsesi disa probleme negative vazhduan tĂ« dalin. NĂ« fund u krijua njĂ« drejtim i veçantĂ« pĂ«r videon.
Isha në kërkesë për Kirill Rogov, drejtuesi i drejtimit të ri, për të folur rreth evolucionit të videoconferencës në Skyeng, problemeve të zbuluara, zgjidhjeve dhe masave që na u desh të përdornim. Shpresojmë se ky artikull do të jetë i dobishëm për kompanitë që gjithashtu po zhvillojnë videon përmes aplikacionit web.
Pak histori
Gjatë verës 2017, kreu i zhvillimit të Skyeng, Sergey Safonov, mbajti një prezantim në Backend Conf mbi atë se si ne "heqëm dorë nga Skype dhe implementuam WebRTC". Ata që dëshirojnë mund të shikojnë regjistrimin e fjalimit në (~45 minuta), dhe këtu do të përmbledh shkurtësisht thelbin e tij.
Për shkollën Skyeng, videoconferenca ka qenë gjithmonë një mënyrë prioritare e komunikimit mes mësuesit dhe nxënësit. Fillimisht përdorej "Skype", por ai nuk na përmbushte aspak për një sërë arsyesh, në radhë të parë për mungesën e regjistrimeve dhe pamundësinë e integrimit direkt në aplikacionin web. Prandaj, ne zhvilluam eksperimente të ndryshme.
Në thelb, kërkesat tona për videoconferencën ishin diçka si kjo:
â stabilitet;
â çmim i ulĂ«t pĂ«r mĂ«sim;
â regjistrimi i mĂ«simeve;
â ndjekja e asaj qĂ« thotĂ« secili (na intereson qĂ« nxĂ«nĂ«sit tĂ« flasin mĂ« shumĂ« se mĂ«suesi gjatĂ« mĂ«simeve);
â skalan linear;
â mundĂ«sia pĂ«r tĂ« pĂ«rdorur si UDP ashtu edhe TCP.
I pari qĂ« provuam nĂ« 2013 ishte Tokbox. TĂ« gjitha ishin mirĂ«, por bĂ«hej shumĂ« e shtrenjtĂ« â 113 rubla pĂ«r mĂ«sim â dhe po hĂ«ngrin fitimin.
Pastaj, në 2015, integuam Voximplant. Këtu kishte funksionin që na duhej për të ndjekur se kush thoshte më shumë, dhe në të njëjtën kohë zgjidhja ishte ndjeshëm më e lirë: me regjistrimin e vetëm të zërit, dilte 20 rubla për mësim. Megjithatë, punonte vetëm përmes UDP, nuk dinte të kalonte në TCP. Megjithatë, përfundimisht rreth 40% e nxënësve e përdornin atë.
Pas një vit, filluam të kemi klientë korporatë me kërkesat e tyre specifike. Për shembull, gjithçka duhet të funksionojë përmes shfletuesit, në kompani janë të hapura vetëm http dhe https; domethënë, asnjë 'Skype' dhe UDP. Klientët korporatë = para, prandaj u rikthyem te Tokbox, por problemi i çmimit nuk kishte ikur.
Zgjidhja â WebRTC dhe Janus
Morrëm vendimin të përdorim . Ajo është përgjegjëse për vendosjen e lidhjes, kodimin dhe dekodimin e rrjedhave, sinkronizimin e kanaleve dhe kontrollin e cilësisë me përpunimin e problemeve të rrjetit. Nga ana jonë, ne duhet të sigurojmë leximin e rrjedhave nga kamera dhe mikrofon, vizatimin e videos, menaxhimin e lidhjes, vendosjen e lidhjes WebRTC dhe transmetimin e rrjedhave, si dhe transmetimin e mesazheve sinjalizuese ndërmjet klientëve për të vendosur lidhjen (vetë WebRTC përshkruan vetëm formatin e të dhënave, por jo mekanizmin e transmetimit të tyre). Në rast se klientët ndodhen pas NAT, WebRTC lidh serverët STUN, dhe nëse kjo nuk ndihmon, serverët TURN.
Një lidhje normale p2p nuk është e mjaftueshme për ne, sepse do të donim të regjistronim mësime për analizë të mëvonshme në rast ankesash. Prandaj dërgojmë rrjedhat WebRTC përmes një retransmetuesi . Si rezultat, klientët nuk dinë adresat e njëri-tjetrit, duke parë vetëm adresën e serverit Janus; ai gjithashtu kryen funksionet e serverit sinjalizues. Janus ka një numër veçorish të nevojshme: kalon automatikisht në TCP nëse klienti ka bllokuar UDP; mund të regjistrojë rrjedhat, si UDP ashtu edhe TCP; është i shkallëzueshëm; ka madje një plugin të integruar për teste eko. Në rast nevoje, lidhen automatikisht serverët STUN dhe TURN nga Twilio.
Në verën e vitit 2017, kishim dy servera Janus plus një server shtesë për përpunimin e skedarëve të papërpunuar të regjistruar audio dhe video, në mënyrë që të mos zënë procesorët e serverëve kryesorë. Gjatë lidhjes, serverët Janus zgjidheshin sipas parimit të çift-tek (numri i lidhjes). Në atë kohë, kjo ishte e mjaftueshme, për ndjenjat tona jepte rreth katërfishin e rezervës së sigurisë, përqindja e zbatimit ishte rreth 80. Në të njëjtën kohë, çmimi u ul në ~2 rubla për mësim, plus zhvillimi dhe mbështetja.
Rikthimi në temën e videokallëzimit
Ne kemi përgjithmonë monitoruar feedback-un nga nxënësit dhe mësuesit, për të identifikuar dhe zgjidhur problemet në kohë. Deri në verën e vitit 2018, cilësia e lidhjes ishte në vendin e parë mes ankesave. Nga njëra anë, kjo do të thoshte që kishim kaluar me sukses mangësi të tjera. Nga ana tjetër, duhej të bënim diçka menjëherë: nëse mësimi prishte, rrezikojmë të humbasim vlerën e tij, ndonjëherë së bashku me vlerën e blerjes së paketës së ardhshme, dhe nëse prishim mësimin hyrës, mund të humbasim përfundimisht një klient potencial.
Në atë kohë, videokamera jonë ishte ende në fazën MVP. Thënë ndryshe, e lanë në punë, funksionoi një herë, e skaluan atë, kuptuan si ta bënin - dhe ishte mirë. Nëse funksionon, mos e rregullo. Askush nuk u angazhua në mënyrë të drejtpërdrejtë për cilësinë e lidhjes. Deri në gusht, u bë e qartë se kjo nuk mund të vazhdojë kështu, dhe ne lanë një drejtim të veçantë për të hetuar se çfarë nuk shkon me WebRTC dhe Janus.
Ky drejtim fillestar mori: një zgjidhje MVP, pa metrika, pa qëllime, pa procese për përmirësim, ndërkohë që 7% e mësuesve ankojnë për cilësinë e lidhjes (nuk kishte të dhëna as për nxënësit).
Drejtimi i ri fillon punën
Ekipi duket afërsisht kështu:
- Përgjegjës i drejtimit, gjithashtu zhvillues 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ë për problemet nga linja e frontit.
- Analisti vazhdon të kërkojë korelata të ndryshme në të dhënat teknike, përmirëson analizën e feedback-ut të përdoruesve, kontrollon rezultatet e eksperimenteve.
- Menaxheri i produktit ndihmon me drejtimin e përgjithshëm dhe ndarjen e burimeve për eksperimente.
- Për programimin e vetë dhe detyrat e lidhura ndihmon shpesh një zhvillues tjetër.
Fillimisht u konfigurua një metrikë relativisht të besueshme, që ndiqte ndryshimet në vlerësimin e cilësisë së lidhjes (mesatarja për ditë, javë, muaj). Në atë kohë, këto ishin vlerësime nga mësuesit; më vonë u shtuan edhe vlerësimet nga studentët. Më pas filluam të ndërtonim hipoteza, çfarë nuk punonte siç duhet, të korrigjonim dhe të shihnim ndryshimet në dinamikë. Shkuam për frutat e ulëta: për shembull, zëvendësuam kodekun vp8 me vp9, treguesit u përmirësuan. Provua të luajmë me parametrat e Janus, të kryejmë eksperimente të tjera - në shumicën e rasteve pa rezultate.
Në fazën e dytë u shfaq hipoteza: WebRTC është një zgjidhje peer-to-peer, por ne përdorim një server në mes. Ndoshta problemi fshihet këtu? Filluam të hulumtojmë dhe gjetëm përmirësimin më të rëndësishëm deri tani.
NĂ« atĂ« moment, serveri ishte i zgjedhur nga pooli me njĂ« algoritĂ«m mjaft tĂ« thjeshtĂ«: secili kishte âpeshĂ«nâ e vet, e cila varet nga kanali dhe kapaciteti, 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 Petersburgu mund tĂ« komunikonte me njĂ« nxĂ«nĂ«s nga Siberia pĂ«rmes MoskĂ«s, dhe jo pĂ«rmes serverit tonĂ« Janus nĂ« ShĂ«n Petersburg.
Algoritmi u ripërdor: tani, kur përdoruesi hap platformën tonë, ne mbledhim ping nga ai deri te të gjithë serverët përmes Ajax-it. Në vendosjen e lidhjes, ne zgjedhim një çift ping-esh (mësues-server dhe nxënës-server) me shumën më të vogël. Më pak ping do të thotë më pak distancë rrjeti deri te serveri; më pak distancë do të thotë më pak mundësi për të humbur paketa; humbja e paketave është faktori më i madh negativ në komunikimin me video. Pjesa negative gjatë tre muajve ra në gjysmë (duke i dhënë të drejtë, gjatë kësaj periudhe u zhvilluan eksperimente të tjera, por ky ndoshta ndikoi më shumë).
KohĂ« mĂ« parĂ«, zbuluam njĂ« tjetĂ«r gjĂ« qĂ« nuk ishte e dukshme, por sipas dukjes ishte shumĂ« e rĂ«ndĂ«sishme: nĂ« vend tĂ« njĂ« serveri tĂ« fuqishĂ«m Janus nĂ« njĂ« kanale tĂ« gjerĂ«, Ă«shtĂ« mĂ« mirĂ« tĂ« kemi dy mĂ« tĂ« vogla me njĂ« kapacitet mĂ« tĂ« ulĂ«t. Kjo doli nĂ« pah pasi blĂ«mĂ« pikĂ«risht makina tĂ« fuqishme me shpresĂ«n pĂ«r tĂ« shtuar sa mĂ« shumĂ« dhoma (seansa komunikimi) njĂ«kohĂ«sisht. ServerĂ«t kanĂ« njĂ« kufi kapaciteti, tĂ« cilin mund ta çmojmĂ« saktĂ«sisht nĂ« numrin e dhomave â ne e dimĂ« se sa mund tĂ« hapet, pĂ«r shembull, nĂ« 300 Mbps. Sa herĂ« qĂ« nĂ« server hapen shumĂ« dhoma â ne ndalojmĂ« ta zgjedhim atĂ« pĂ«r aktivitete tĂ« reja derisa ngarkesa tĂ« zvogĂ«lohet. Ideja ishte qĂ«, duke blerĂ« njĂ« makinĂ« tĂ« fuqishme, do ta mbushnim kanalin nĂ« maksimum, pĂ«r tĂ« arritur nĂ« fund te procesori dhe kujtesa dhe jo te kapaciteti. Por u zbulua se pas njĂ« numri tĂ« caktuar dhomash tĂ« hapura (420), megjithĂ«se ngarkimi i procesorit, kujtesĂ«s dhe diskut ishte ende shumĂ« larg kufijve, filluan tĂ« vinin ankesa nĂ« shĂ«rbimin e mbĂ«shtetjes. Duket se diçka Ă«shtĂ« pĂ«rkeqĂ«suar brenda Janus, ndoshta aty ka disa kufizime. Filluam tĂ« eksperimentojmĂ«, ulĂ«m kufirin e kapacitetit nga 300 nĂ« 200 Mbps, problemet u zhdukĂ«n. Tani kemi blerĂ« menjĂ«herĂ« tre servera tĂ« rinj me kufij dhe karakteristika tĂ« ulĂ«ta, mendojmĂ« se kjo do tĂ« çojĂ« nĂ« njĂ« pĂ«rmirĂ«sim stabil tĂ« cilĂ«sisĂ« sĂ« komunikimit. Natyrisht, nuk kemi pĂ«r t'u marrĂ« me atĂ« se çfarĂ« ka ndodhur, sepse ngjitur me ne â Ă«shtĂ« gjithçka. NĂ« mbrojtje tĂ« vetes, do tĂ« themi se nĂ« atĂ« moment duhej tĂ« zgjidhnim sa mĂ« shpejt njĂ« problem urgjent dhe jo ta bĂ«nim kĂ«tĂ« bukur; pĂ«r mĂ« tepĂ«r, Janus pĂ«r ne Ă«shtĂ« njĂ« kuti e zezĂ«, e shkruar nĂ« C, dhe Ă«shtĂ« shumĂ« e shtrenjtĂ« pĂ«r tĂ« hyrĂ« brenda.
E gjithashtu, gjatë procesit ne:
- përditësuam të gjitha varësitë që mund të përditësoheshin, si në server ashtu edhe në klient (kjo gjithashtu ishte eksperimente, kemi ndjekur rezultatet);
- kemi riparuar të gjitha gabimet e identifikuara, që lidhen me raste specifike, për shembull, kur lidhja binte dhe nuk rikthehej automatikisht;
- kemi organizuar shumë takime me kompani që punojnë në fushën e videokomunikimit dhe janë të njohura me problemet tona: ata që transmetojnë lojëra, organizojnë webinare; provuam gjithçka që na dukej e dobishme;
- kemi zhvilluar një rishikim teknik të pajisjeve dhe cilësisë së komunikimit nga mësuesit, nga të cilët erdhën shumica e ankesave.
Eksperimentet e kryera dhe ndryshimet që pasuan, arritën të reduktojnë pakënaqësinë e lidhjes mes mësimdhënësve nga 7,1% në janar 2018 në 2,5% në janar 2019.
ĂfarĂ« pason
Stabilizimi i platformĂ«s tonĂ« Vimbox Ă«shtĂ« njĂ« nga projektet kryesore tĂ« kompanisĂ« pĂ«r vitin 2019. Ne kemi shpresa tĂ« mĂ«dha qĂ« tĂ« ruajmĂ« dinamikĂ«n dhe tĂ« mos shohim mĂ« videokallĂ«zimin nĂ« krye tĂ« ankesave. E kuptojmĂ« qĂ« njĂ« pjesĂ« e madhe e kĂ«tyre ankesave lidhen me vonesat e kompjuterĂ«ve dhe internetit tĂ« pĂ«rdoruesve, por duhet tĂ« pĂ«rcaktojmĂ« kĂ«tĂ« pjesĂ« dhe tĂ« zgjidhim gjithçka tjetĂ«r. Ădo gjĂ« tjetĂ«r Ă«shtĂ« njĂ« problem teknik, duket se duhet tĂ« dimĂ« ta menaxhojmĂ«.
Sfidë kryesore është se nuk dimë deri në cilin nivel është reale të përmirësojmë cilësinë. Përcaktimi i këtij kufiri është detyra kryesore. Prandaj janë planifikuar dy eksperimentet:
- të krahasojmë videon përmes Janus me p2p-në e zakonshme në kushte reale. Ky eksperiment është realizuar, nuk është gjetur ndonjë ndryshim të rëndësishëm statistikisht midis zgjidhjes sonë dhe p2p.
- do të instalojmë (shërbimet e shtrenjta) të kompanive që fitojnë ekskluzivisht nga zgjidhjet në fushën e videokallëzimit dhe do të krahasojmë sasinë e pakënaqësisë nga ato me atë që kemi aktualisht.
Këto dy eksperimente do të na lejojnë të përcaktojmë një qëllim të arritshëm dhe të përqendrohemi në të.
Për më tepër, ekzistojnë disa detyra që po zgjidhen në mënyrë operative:
- po krijojmë një metrikë teknike të cilësisë së lidhjes në vend të vlerësimeve subjektive;
- po bëjmë regjistrime më të detajuara të seancave, për të analizuar më saktë dështimet që ndodhin, për të kuptuar kur dhe ku ndodhin ato, si edhe cilat ngjarje që nuk duken të lidhura, ndodhen në atë moment;
- po përgatitim një test automatik të cilësisë së lidhjes përpara mësimit, si dhe do të japim mundësinë e testimit manual të lidhjes nga klienti, për të reduktuar numrin e pakënaqësive të shkaktuara nga pajisjet dhe kanali i tij;
- do të zhvillojmë dhe do të kryejmë më shumë teste ngarkese për videokallëzimin në kushte të këqija, me humbje të variableve të paketave etj.;
- po ndryshojmë sjelljen e serverëve në rast problemesh për të rritur qëndrueshmërinë e shërbimit;
- do të paralajmërojmë përdoruesin nëse ka ndonjë problem me lidhjen, ashtu siç bën "Skype", në mënyrë që ai të kuptojë që problemi është në anën e tij.
Që nga prilli, drejtimi i videofonisë bëhet një projekt i plotë brenda Skyeng, duke u marrë me produktin e vet, jo thjesht një pjesë e Vimbox. Kjo do të thotë që fillojmë të kërkojmë njerëz për . Siç e kemi bërë gjithmonë, .
. Po ashtu, vazhdojmë të komunikojmë aktivisht me njerëz dhe kompani që punojnë me videofoni. Nëse dëshironi të shkëmbeni përvojë me ne - do të jemi të lumtur! Komentoni, kontaktoni - do t'i përgjigjemi të gjithëve.
Burimi: habr.com
