La comunicazione video è il principale mezzo di comunicazione tra insegnante e studente sulla piattaforma Vimbox. Abbiamo abbandonato Skype molto tempo fa, provato diverse soluzioni di terze parti e alla fine abbiamo optato per la combinazione WebRTC - Janus-gateway. Per qualche tempo eravamo contenti di tutto, ma continuavano comunque ad emergere alcuni aspetti negativi. Di conseguenza, è stata creata una regia video separata.
Ho chiesto a Kirill Rogovoy, il capo della nuova direzione, di parlare dell'evoluzione della comunicazione video in Skyeng, dei problemi scoperti, delle soluzioni e delle stampelle che alla fine abbiamo utilizzato. Ci auguriamo che l'articolo possa essere utile alle aziende che creano video anche in autonomia tramite un'applicazione web.
Un po 'di storia
Nell'estate del 2017, il capo dello sviluppo di Skyeng, Sergey Safonov, ha parlato al Backend Conf con una storia su come abbiamo "abbandonato Skype e implementato WebRTC". Chi è interessato può visionare la registrazione del discorso su (~45 min), e qui ne delineerò brevemente l'essenza.
Per la Skyeng School, la comunicazione video è sempre stata una modalità prioritaria di comunicazione insegnante-studente. Inizialmente è stato utilizzato Skype, ma per una serie di motivi non era assolutamente soddisfacente, principalmente per la mancanza di log e l'impossibilità di integrazione diretta nell'applicazione web. Pertanto, abbiamo effettuato tutti i tipi di esperimenti.
In realtà, i nostri requisiti per la comunicazione video erano approssimativamente i seguenti:
— stabilità;
— prezzo basso per lezione;
— registrazione delle lezioni;
— monitorare chi parla quanto (per noi è importante che gli studenti parlino più del docente durante le lezioni);
— scala lineare;
- capacità di utilizzare sia UDP che TCP.
Il primo tentativo è stato quello di implementare Tokbox nel 2013. Tutto andava bene, ma si è rivelato molto costoso - 113 rubli a lezione - e ha divorato il profitto.
Poi, nel 2015, è stata integrata Voximplant. Ecco la funzione di cui avevamo bisogno per tenere traccia di chi parlava e quanto, e allo stesso tempo la soluzione era molto più economica: se si registrava solo l'audio, costava 20 rubli a lezione. Tuttavia funzionava solo tramite UDP e non poteva passare a TCP. Tuttavia, circa il 40% degli studenti ha finito per utilizzarlo.
Un anno dopo, abbiamo iniziato ad avere clienti aziendali con le loro esigenze specifiche. Ad esempio, tutto dovrebbe funzionare tramite browser: l’azienda apre solo http e https; cioè niente Skype o UDP. Clienti aziendali = soldi, quindi sono tornati a Tokbox, ma il problema del prezzo non è scomparso.
Soluzione: WebRTC e Janus
Ho deciso di usarlo . È responsabile di stabilire una connessione, codificare e decodificare flussi, sincronizzare le tracce e controllare la qualità con la gestione dei problemi di rete. Da parte nostra, dobbiamo garantire la lettura dei flussi dalla telecamera e dal microfono, la realizzazione di video, la gestione della connessione, la creazione di una connessione WebRTC e la trasmissione di flussi ad essa, nonché la trasmissione di messaggi di segnalazione tra client per stabilire una connessione (WebRTC stesso descrive solo il formato dei dati, ma non il suo meccanismo di trasferimento). Se i client sono dietro NAT, WebRTC connette i server STUN; se questo non aiuta, TURN server.
Una normale connessione p2p non ci basta, perché vogliamo registrare le lezioni per ulteriori analisi in caso di reclami. Pertanto inviamo flussi WebRTC tramite un relè . Di conseguenza, i client non conoscono gli indirizzi degli altri e vedono solo l'indirizzo del server Janus; svolge anche le funzioni di server di segnale. Janus ha molte delle funzionalità di cui abbiamo bisogno: passa automaticamente a TCP se il client ha UDP bloccato; può registrare sia flussi UDP che TCP; scalabile; C'è anche un plugin integrato per i test dell'eco. Se necessario, i server STUN e TURN di Twilio vengono collegati automaticamente.
Nell'estate del 2017 avevamo in funzione due server Janus, più un server aggiuntivo per l'elaborazione dei file audio e video grezzi registrati, in modo da non occupare i processori di quelli principali. Durante la connessione, i server Janus sono stati selezionati su base pari-dispari (numero di connessione). A quel tempo, questo era sufficiente, secondo i nostri sentimenti, dava circa quattro volte il margine di sicurezza, la percentuale di implementazione era di circa 80. Allo stesso tempo, il prezzo è stato ridotto a ~2 rubli per lezione, più sviluppo e supporto.
Ritornando al tema della videocomunicazione
Monitoriamo costantemente il feedback di studenti e insegnanti al fine di identificare e correggere i problemi in modo tempestivo. Nell’estate del 2018 la qualità delle chiamate era saldamente al primo posto tra i reclami. Da un lato ciò significa che abbiamo superato con successo altre carenze. D'altronde bisognava fare qualcosa con urgenza: se la lezione viene interrotta, si rischia di perdere il suo valore, a volte insieme al costo per l'acquisto del pacchetto successivo, e se viene interrotta la lezione introduttiva, si rischia di perdere un potenziale cliente. del tutto.
A quel tempo, la nostra comunicazione video era ancora in modalità MVP. In poche parole, l'hanno lanciato, ha funzionato, l'hanno ridimensionato una volta, hanno capito come farlo - beh, fantastico. Se funziona, non aggiustarlo. Nessuno ha affrontato deliberatamente il tema della qualità della comunicazione. Ad agosto è diventato chiaro che la situazione non poteva continuare e abbiamo avviato una direzione separata per capire cosa c'era che non andava in WebRTC e Janus.
In ingresso, questa direzione ha ricevuto: una soluzione MVP, nessuna metrica, nessun obiettivo, nessun processo di miglioramento, mentre il 7% degli insegnanti si lamenta della qualità della comunicazione (non c'erano nemmeno dati sugli studenti).
Una nuova direzione è in corso
Il comando è simile al seguente:
- Il capo del dipartimento, che è anche lo sviluppatore principale.
- Il QA aiuta a testare i cambiamenti, cerca nuovi modi per creare condizioni di comunicazione instabili e segnala i problemi in prima linea.
- L'analista cerca costantemente varie correlazioni nei dati tecnici, migliora l'analisi del feedback degli utenti e controlla i risultati degli esperimenti.
- Il product manager aiuta con la direzione generale e l'allocazione delle risorse per gli esperimenti.
- Un secondo sviluppatore spesso aiuta con la programmazione e le attività correlate.
Per cominciare, abbiamo impostato una metrica relativamente affidabile che monitorava i cambiamenti nelle valutazioni della qualità della comunicazione (media su giorni, settimane, mesi). A quel tempo, questi erano i voti degli insegnanti, a questi furono aggiunti successivamente i voti degli studenti. Quindi hanno iniziato a costruire ipotesi su cosa funzionava male, a correggerlo e a osservare i cambiamenti nelle dinamiche. Abbiamo optato per i risultati più facili: ad esempio, abbiamo sostituito il codec vp8 con vp9, le prestazioni sono migliorate. Abbiamo provato a giocare con le impostazioni di Janus e a condurre altri esperimenti: nella maggior parte dei casi non hanno portato a nulla.
Nella seconda fase è emersa un'ipotesi: WebRTC è una soluzione peer-to-peer e utilizziamo un server nel mezzo. Forse il problema sta qui? Abbiamo iniziato a scavare e finora abbiamo riscontrato il miglioramento più significativo.
In quel momento, è stato selezionato un server dal pool utilizzando un algoritmo piuttosto stupido: ognuno aveva il proprio "peso", a seconda del canale e della potenza, e abbiamo provato a inviare l'utente a quello con il "peso" maggiore, senza prestando attenzione a dove si trovava geograficamente l'utente. Di conseguenza, un insegnante di San Pietroburgo potrebbe comunicare con uno studente della Siberia attraverso Mosca e non tramite il nostro server Janus a San Pietroburgo.
L'algoritmo è stato rifatto: ora, quando un utente apre la nostra piattaforma, raccogliamo i suoi ping su tutti i server che utilizzano Ajax. Quando stabiliamo una connessione, selezioniamo la coppia di ping (server insegnante e server studente) con il numero minimo. Meno ping significa meno distanza di rete dal server; una distanza più breve significa una minore probabilità di perdere pacchetti; La perdita di pacchetti è il più grande fattore negativo nella comunicazione video. La percentuale di negatività si è dimezzata in tre mesi (a dire il vero, in questo periodo sono stati condotti altri esperimenti, ma questo quasi sicuramente ha avuto il maggiore impatto).
Recentemente abbiamo scoperto un’altra cosa non ovvia, ma apparentemente importante: invece di un potente server Janus su un canale spesso, è meglio averne due più semplici con una larghezza di banda più ridotta. Ciò è diventato chiaro dopo che abbiamo acquistato macchine potenti nella speranza di riempire quante più stanze (sessioni di comunicazione) contemporaneamente. I server hanno un limite di larghezza di banda, che possiamo tradurre con precisione nel numero di stanze: sappiamo quante possono essere aperte, ad esempio, a 300 Mbit/s. Non appena ci sono troppe stanze aperte su un server, smettiamo di sceglierlo per nuove attività finché il carico non diminuisce. L'idea era che, avendo acquistato una macchina potente, avremmo caricato al massimo il canale, in modo che alla fine sarebbe stato limitato dal processore e dalla memoria, e non dalla larghezza di banda. Ma si è scoperto che dopo un certo numero di stanze aperte (420), nonostante il carico sul processore, sulla memoria e sul disco sia ancora molto lontano dai limiti, la negatività comincia ad arrivare al supporto tecnico. A quanto pare, qualcosa sta peggiorando all'interno di Janus, forse anche lì ci sono delle restrizioni. Abbiamo iniziato a sperimentare, abbiamo abbassato il limite di larghezza di banda da 300 a 200 Mbit/s e i problemi sono scomparsi. Ora abbiamo acquistato tre nuovi server contemporaneamente con limiti e caratteristiche bassi, riteniamo che ciò porterà a un miglioramento stabile della qualità della comunicazione. Naturalmente non abbiamo cercato di capire cosa stesse succedendo lì; le nostre stampelle sono tutto. A nostra difesa diciamo che in quel momento era necessario risolvere il problema urgente il più rapidamente possibile, e non farlo magnificamente; inoltre Janus per noi è una scatola nera scritta in C, armeggiare con essa è molto costoso.
Bene, nel processo noi:
- aggiornato tutte le dipendenze che potevano essere aggiornate, sia sul server che sul client (anche questi erano esperimenti, abbiamo monitorato i risultati);
- risolti tutti i bug identificati relativi a casi specifici, ad esempio, quando la connessione si interrompeva e non veniva ripristinata automaticamente;
- Abbiamo avuto molti incontri con aziende che lavorano nel campo della videocomunicazione e che conoscono le nostre problematiche: streaming di giochi, organizzazione di webinar; abbiamo provato tutto ciò che ci sembrava utile;
- Condotto un esame tecnico dell'hardware e della qualità della comunicazione degli insegnanti, da cui proveniva la maggior parte dei reclami.
Le sperimentazioni e le successive modifiche hanno permesso di ridurre l’insoddisfazione per la comunicazione tra gli insegnanti dal 7,1% di gennaio 2018 al 2,5% di gennaio 2019.
Cosa c'è Next
La stabilizzazione della nostra piattaforma Vimbox è uno dei principali progetti dell'azienda per il 2019. Abbiamo grandi speranze di riuscire a mantenere lo slancio e di non vedere più la comunicazione video tra le principali lamentele. Comprendiamo che una parte significativa di questi reclami sono legati a ritardi nei computer e in Internet degli utenti, ma dobbiamo determinare questa parte e risolvere il resto. Tutto il resto è un problema tecnico, sembra che dovremmo essere in grado di affrontarlo.
La difficoltà principale è che non sappiamo fino a che livello sia effettivamente possibile migliorare la qualità. Scoprire questo massimale è il compito principale. Sono stati quindi programmati due esperimenti:
- confronta i video tramite Janus con il normale p2p in condizioni di combattimento. Questo esperimento è già stato effettuato, non è stata riscontrata alcuna differenza statisticamente significativa tra la nostra soluzione e p2p;
- Forniamo servizi (costosi) di aziende che guadagnano esclusivamente con soluzioni di videocomunicazione e confrontiamo la quantità di negatività da loro con quella esistente.
Questi due esperimenti ci permetteranno di identificare un obiettivo raggiungibile e focalizzarci su di esso.
Inoltre, ci sono una serie di compiti che possono essere risolti di routine:
- Creiamo una metrica tecnica della qualità della comunicazione invece di recensioni soggettive;
- Realizziamo log di sessione più dettagliati per analizzare in modo più accurato i guasti che si verificano, capire quando e dove esattamente si sono verificati e quali eventi apparentemente non correlati sono accaduti in quel momento;
- Prepariamo un test automatico di qualità della connessione prima della lezione e diamo anche al cliente la possibilità di testare manualmente la connessione per ridurre la quantità di negatività causata dal suo hardware e dal suo canale;
- svilupperemo e condurremo più test di carico della comunicazione video in condizioni sfavorevoli, con perdita di pacchetti variabile, ecc.;
- modifichiamo il comportamento dei server in caso di problemi per aumentare la tolleranza agli errori;
- Avviseremo l'utente se c'è qualcosa che non va nella sua connessione, come fa Skype, in modo che capisca che il problema è dalla sua parte.
Da aprile, la direzione della comunicazione video è diventata un vero e proprio progetto separato all'interno di Skyeng, occupandosi del proprio prodotto e non solo di una parte di Vimbox. Ciò significa che stiamo iniziando a cercare persone su . Bene, come sempre .
E, naturalmente, continuiamo a comunicare attivamente con persone e aziende che lavorano con la comunicazione video. Se vuoi scambiare esperienze con noi, saremo lieti! Commenta, mettiti in contatto: risponderemo a tutti.
Fonte: habr.com