Video-conferința este principalul mod de comunicare între profesor și student pe platforma Vimbox. Am renunțat demult la Skype, am încercat mai multe soluții externe și, în final, ne-am oprit la combinația WebRTC — Janus-gateway. O vreme, totul a fost în regulă, dar au apărut unele momente negative. În cele din urmă, a fost creată o direcție separată pentru video.
L-am rugat pe Kiril Rogovoi, liderul noii direcții, să vorbească despre evoluția video-conferințelor în Skyeng, problemele întâmpinate, soluțiile adoptate și workaround-urile pe care le-am aplicat. Sperăm că articolul va fi util pentru companiile care își desfășoară video prin aplicația web.
Puțin istorie
În vara anului 2017, șeful dezvoltării Skyeng, Serghei Safonov, a susținut o prezentare la Backend Conf despre cum am "renunțat la Skype și am implementat WebRTC". Cei interesați pot viziona înregistrarea prezentării pe (~45 min), iar aici voi rezuma esența acesteia.
Pentru școala Skyeng, video-conferința a fost întotdeauna modalitatea prioritară de comunicare dintre profesor și elev. La început, am folosit "Skype", dar acesta nu ne-a satisfăcut deloc dintr-o serie întreagă de motive, în primul rând din cauza lipsei de loguri și a imposibilității integrării directe în aplicația web. Prin urmare, am efectuat diverse experimente.
Așadar, cerințele noastre pentru video-conferință erau cam așa:
— stabilitate;
— cost redus per lecție;
— înregistrarea lecțiilor;
— monitorizarea timpului de vorbire (ne interesează ca elevii să vorbească mai mult decât profesorul în timpul lecțiilor);
— scalare liniară;
— posibilitatea de a utiliza atât UDP, cât și TCP.
Primul, în 2013, am încercat să implementăm Tokbox. Totul a fost bine, dar costurile erau foarte mari – 113 ruble pe lecție – și afecta profiturile.
Apoi, în 2015, am integrat Voximplant. Aici aveam funcția necesară de monitorizare a timpului de vorbire, iar soluția era semnificativ mai ieftină: cu condiția înregistrării doar a sunetului, costul era de 20 ruble pe lecție. Cu toate acestea, funcționa doar prin UDP și nu putea să comute pe TCP. Cu toate acestea, în cele din urmă, aproximativ 40% dintre elevi îl foloseau.
După un an, am început să avem clienți corporate cu cerințe specifice. De exemplu, totul trebuie să funcționeze prin browser, iar în companie sunt deschise doar http și https; adică, fără „Skype” și UDP. Clienții corporate = bani, așa că ne-am întors la Tokbox, dar problema prețului a rămas neschimbată.
Soluția — WebRTC și Janus
Am decis să folosim . Aceasta se ocupă de stabilirea conexiunii, codarea și decodarea fluxurilor, sincronizarea pistelor și controlul calității prin gestionarea glicurilor de rețea. Din partea noastră, trebuie să asigurăm citirea fluxurilor de la cameră și microfon, redarea video, gestionarea conexiunii, stabilirea conexiunii WebRTC și transmiterea fluxurilor către aceasta, precum și transmiterea mesajelor de semnalizare între clienți pentru stabilirea conexiunii (WebRTC descrie doar formatul datelor, dar nu și mecanismul de transmitere a acestora). În cazul în care clienții sunt în spatele unui NAT, WebRTC se conectează la serverele STUN, iar dacă asta nu ajută, la serverele TURN.
O conexiune p2p obișnuită nu este suficientă, deoarece dorim să înregistrăm lecțiile pentru analiza ulterioară în caz de plângeri. Prin urmare, trimitem fluxurile WebRTC printr-un retransmițător . Ca urmare, clienții nu cunosc adresele unii altora, văzând doar adresa serverului Janus; acesta îndeplinește și funcțiile serverului de semnalizare. Janus are o mulțime de funcții necesare: trece automat la TCP dacă UDP este blocat pentru client; poate înregistra atât fluxuri UDP, cât și TCP; se scalează; există chiar și un plugin încorporat pentru teste de ecou. Dacă este necesar, se conectează automat serverele STUN și TURN de la Twilio.
În vara anului 2017, aveam două servere Janus plus un server suplimentar pentru procesarea fișierelor brute înregistrate de audio și video, pentru a nu ocupa procesoarele principale. La conectare, serverele Janus erau selectate pe principiul par-impar (numărul de conexiune). Atunci, aceasta era suficientă, oferind un confort de aproximativ patru ori, iar procentul de implementare a fost de aproximativ 80. În același timp, prețul a scăzut la ~2 ruble pe lecție, plus dezvoltare și asistență.
Revenind la tema comunicațiilor video
Monitorizăm constant feedback-ul de la elevi și profesori pentru a identifica și a rezolva problemele la timp. Până în vara anului 2018, calitatea conexiunii s-a situat pe primul loc în rândul plângerilor. Pe de o parte, asta însemna că am reușit să remediem alte deficiențe. Pe de altă parte, trebuia să acționăm rapid: în cazul unei lecții anulate, riscăm să pierdem valoarea acesteia, uneori chiar și valoarea achiziției următorului pachet, iar în cazul unei lecții introductive anulate – putem pierde complet un client potențial.
În acel moment, videoconferința noastră se afla încă în regimul MVP. Mai simplu spus, am lansat, a funcționat, am scalat o dată, am înțeles cum se face – și a fost grozav. If it works, don’t fix it. Nimeni nu s-a ocupat în mod special de calitatea conexiunii. Până în august a devenit evident că nu mai putem continua astfel, așa că am lansat o direcție separată pentru a înțelege ce nu merge bine cu WebRTC și Janus.
La început, această direcție a primit: o soluție MVP, fără metrici, fără obiective, fără procese de îmbunătățire, în timp ce 7% dintre profesori se plâng de calitatea conexiunii (datele despre elevi nu erau disponibile).
Noua direcție își ia angajamentele
Echipa arată cam așa:
- Șeful direcției, care este și principalul dezvoltator.
- QA ajută la testarea schimbărilor, caută noi modalități de a crea condiții instabile pentru conexiune, raportează problemele de pe linia frontului.
- Analistul caută constant diverse corelații în datele tehnice, îmbunătățește analiza feedback-ului utilizatorilor, verifică rezultatele experimentelor.
- Product manager-ul ajută cu direcția generală și alocarea resurselor pentru experimente.
- La programare și sarcini conexe, adesea ajută un al doilea dezvoltator.
La început, am configurat o metrică relativ fiabilă, care monitoriza schimbările în evaluarea calității conexiunii (media pe zile, săptămâni, luni). La acel moment, acestea erau evaluări din partea profesorilor, iar ulterior au fost adăugate și evaluările din partea studenților. Apoi, am început să formulăm ipoteze despre ce nu funcționează, să corectăm și să observăm schimbările în dinamica lor. Am abordat fructele la îndemână: de exemplu, am înlocuit codec-ul vp8 cu vp9, iar indicatorii s-au îmbunătățit. Am încercat să modificăm setările Janus, să desfășurăm alte experimente – în majoritatea cazurilor neavând rezultate.
În a doua etapă a apărut ipoteza: WebRTC este o soluție peer-to-peer, iar noi folosim un server la mijloc. Poate că problema se află aici? Am început să investigăm și am descoperit aici cea mai semnificativă îmbunătățire de până acum.
În acel moment, serverul era selectat din pool printr-un algoritm destul de simplu: fiecare server avea o „greutate” proprie, în funcție de lățimea de bandă și puterea acestuia, iar noi încercam să trimitem utilizatorul pe cel cu „greutatea” mai mare, fără a lua în considerare locația geografică a utilizatorului. Astfel, un profesor din Sankt Petersburg putea comunica cu un elev din Siberia prin Moscova, și nu prin serverul nostru Janus din Sankt Petersburg.
Algoritmul a fost refăcut: acum, atunci când utilizatorul deschide platforma noastră, noi colectăm prin Ajax ping-uri de la el către toate serverele. La stabilirea conexiunii, alegem o pereche de ping-uri (profesor-server și elev-server) cu suma cea mai mică. Un ping mai mic înseamnă o distanță mai mică până la server; o distanță mai mică — o probabilitate mai mică de pierdere a pachetelor; pierderea pachetelor este cel mai mare factor negativ în comunicarea video. Proporția negativului a scăzut de două ori în trei luni (deși, în această perioadă, s-au desfășurat și alte experimente, dar acesta a influențat cu siguranță cel mai mult).
Recent, we discovered another non-obvious but seemingly important thing: instead of a single powerful Janus server on a thick channel, it's better to have two simpler ones with lower bandwidth. This became clear after we purchased powerful machines in hopes of cramming as many rooms (communication sessions) as possible at the same time. Servers have a bandwidth limit that can precisely translate into the number of rooms—we know how many can be opened, for example, on 300 Mbit/s. As soon as there are too many rooms open on the server, we stop selecting it for new sessions until the load decreases. The idea was that by purchasing a powerful machine, we would maximize the channel loading until we hit the CPU and memory, rather than the bandwidth. However, it turned out that after a certain number of opened rooms (420), despite CPU, memory, and disk usage being far from the limits, negative feedback would start arriving at tech support. Apparently, something deteriorates inside Janus, perhaps there are also limitations there. We began experimenting, reduced the bandwidth limit from 300 to 200 Mbit/s, and the problems disappeared. Now we've bought three new servers with lower limits and specifications, thinking this will lead to a stable improvement in communication quality. We didn’t dive into what the issue was; quick fixes are our approach. In our defense, we needed to solve the pressing issue as quickly as possible, rather than beautifully; additionally, Janus is a black box for us, written in C, and digging into it is very costly.
During the process, we:
- updated all dependencies that could be updated, both on the server and on the client (these were also experiments, we monitored the results);
- fixed all identified bugs related to specific cases, for example when the connection dropped and didn't recover automatically;
- held numerous meetings with companies working in the field of video communication and familiar with our problems: streaming games, hosting webinars; tested everything that seemed useful to us;
- conducted a technical review of the hardware and communication quality from teachers who received the most complaints.
Experimentele realizate și modificările ulterioare au permis reducerea nemulțumirii legate de calitatea comunicării în rândul profesorilor de la 7,1% în ianuarie 2018 la 2,5% în ianuarie 2019.
Ce urmează
Stabilizarea platformei noastre Vimbox este unul dintre cele mai importante proiecte ale companiei pentru 2019. Avem mari speranțe că vom reuși să menținem această dinamică și să nu mai vedem comunicarea video în topul plângerilor. Înțelegem că o parte semnificativă din aceste plângeri este legată de lagurile calculatoarelor și internetului utilizatorilor, dar trebuie să definim această parte și să rezolvăm restul problemelor. Restul sunt probleme tehnice, iar se pare că ar trebui să ne putem descurca cu ele.
Principalul obstacol este că nu știm la ce nivel putem îmbunătăți calitatea. Identificarea acestui plafon este sarcina principală. De aceea, au fost planificate două experimente:
- să comparăm video prin Janus cu p2p obișnuit în condiții reale. Acest experiment a fost deja realizat, fără o diferență statistic semnificativă între soluția noastră și p2p;
- vom instala servicii (costisitoare) de la companii care câștigă exclusiv din soluții de videoconferință și vom compara cantitatea de feedback negativ primit de la acestea cu ceea ce avem.
Aceste două experimente ne vor permite să definim un obiectiv realizabil și să ne concentrăm asupra acestuia.
În plus, există o serie de sarcini care sunt rezolvate în mod curent:
- creăm o metrică tehnică pentru calitatea comunicației în loc de feedback subiectiv;
- realizăm jurnale mai detaliate ale sesiunilor pentru a analiza mai precis întreruperile care au loc, înțelegând când și unde au apărut, precum și evenimentele aparent nesemnificative care s-au întâmplat în acel moment;
- pregătim un test automatizat pentru calitatea comunicației înainte de lecție, precum și vom oferi clientului posibilitatea de a testa manual comunicarea, pentru a reduce numărul de plângeri cauzate de hardware-ul și conexiunea acestuia;
- vom dezvolta și vom desfășura mai multe teste de stres pentru videoconferință în condiții proaste, cu pierderi variabile de pachete, etc.;
- vom modifica comportamentul serverelor în caz de probleme pentru a îmbunătăți reziliența;
- vom alerta utilizatorul dacă are probleme cu comunicarea, așa cum face și Skype, pentru a-l ajuta să înțeleagă că problema este de partea lui.
Începând din aprilie, direcția video devine un proiect distinct și complet în cadrul Skyeng, dedicat unui produs propriu, nu doar o parte din Vimbox. Asta înseamnă că începem să căutăm oameni pentru . Ei bine, ca de obicei .
Și, bineînțeles, continuăm să comunicăm activ cu persoanele și companiile care lucrează în domeniul videoconferințelor. Dacă doriți să împărtășiți experiența cu noi — ne-ar face plăcere! Lăsați comentarii, contactați-ne — vom răspunde tuturor.
Sursa: habr.com
