{"id":30842,"date":"2019-10-31T21:37:44","date_gmt":"2019-10-31T18:37:44","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ot-skype-do-webrtc-kak-my-organizovali-videosvyaz-cherez-veb\/"},"modified":"2021-02-01T11:37:06","modified_gmt":"2021-02-01T09:37:06","slug":"ot-skype-do-webrtc-kak-my-organizovali-videosvyaz-cherez-veb","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/ot-skype-do-webrtc-kak-my-organizovali-videosvyaz-cherez-veb","title":{"rendered":"Da Skype a WebRTC: come abbiamo organizzato la videochiamata attraverso il web","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Da<\/p>\n

La videocomunicazione \u00e8 il principale modo di interazione tra insegnante e studente sulla piattaforma Vimbox. Abbandonando a lungo Skype, abbiamo testato diverse soluzioni esterne e alla fine ci siamo orientati su una combinazione di WebRTC e Janus-gateway. Per un certo periodo tutto ha funzionato bene, ma alcuni aspetti negativi continuavano a emergere. Alla fine, \u00e8 stato creato un settore dedicato al video.<\/p>\n

Ho chiesto a Kirill Rogovoy, il responsabile del nuovo settore, di raccontare l'evoluzione della videocomunicazione in Skyeng, i problemi riscontrati, le soluzioni e le soluzioni temporanee che abbiamo quindi applicato. Speriamo che l'articolo sia utile anche per le aziende che stanno implementando video tramite web application.<\/p>\n

<\/a><\/noindex><\/p>\n

Un po' di storia<\/h2>\n

Nell'estate del 2017, il capo dello sviluppo di Skyeng, Sergey Safonov, ha partecipato al Backend Conf parlando di come abbiamo \"abbandonato Skype e implementato WebRTC\". Chi desidera pu\u00f2 vedere la registrazione della presentazione a link<\/a><\/noindex> (~45 min), mentre qui riassumo brevemente il suo contenuto.<\/p>\n

Per la scuola Skyeng, la videochiamata \u00e8 sempre stata il modo prioritario per comunicare tra insegnante e studente. Inizialmente abbiamo utilizzato \"Skype\", ma questo non soddisfaceva affatto le nostre esigenze per diversi motivi, in particolare per la mancanza di log e l'impossibilit\u00e0 di integrazione diretta nell'applicazione web. Di conseguenza, abbiamo condotto vari esperimenti.<\/p>\n

In sostanza, i nostri requisiti per la videochiamata erano pi\u00f9 o meno i seguenti:
\n\u2014 stabilit\u00e0;
\n\u2014 basso costo per lezione;
\n\u2014 registrazione delle lezioni;
\n\u2014 monitoraggio di quanto ciascuno parla (\u00e8 importante per noi che gli studenti parlino di pi\u00f9 durante le lezioni rispetto all'insegnante);
\n\u2014 scalabilit\u00e0 lineare;
\n\u2014 possibilit\u00e0 di utilizzare sia UDP che TCP.<\/p>\n

Il primo a essere sperimentato nel 2013 \u00e8 stato Tokbox. Andava bene, ma risultava molto costoso \u2013 113 rubli per lezione \u2013 e riduceva i profitti.<\/p>\n

Poi, nel 2015, abbiamo integrato Voximplant. Qui era presente la funzione di monitoraggio richiesta, ed era anche significativamente pi\u00f9 economico: con la registrazione solo dell'audio costava 20 rubli per lezione. Tuttavia, funzionava solo tramite UDP e non sapeva passare a TCP. Nonostante ci\u00f2, circa il 40% degli studenti lo utilizzava.<\/p>\n

Dopo un anno, abbiamo iniziato ad avere clienti aziendali con requisiti specifici. Ad esempio, tutto deve funzionare tramite browser, e in azienda sono aperti solo http e https; quindi niente \u00abSkype\u00bb e UDP. Clienti aziendali = denaro, quindi siamo tornati a Tokbox, ma il problema dei costi non \u00e8 sparito.<\/p>\n

La soluzione \u00e8 WebRTC e Janus<\/h2>\n

Abbiamo deciso di utilizzare una piattaforma browser per videochiamate peer-to-peer WebRTC<\/a><\/noindex>. Essa \u00e8 responsabile della creazione della connessione, della codifica e decodifica dei flussi, della sincronizzazione delle tracce e del controllo della qualit\u00e0 con gestione delle anomalie di rete. Da parte nostra, dobbiamo garantire la lettura dei flussi da fotocamera e microfono, la visualizzazione video, la gestione della connessione, l'instaurazione della connessione WebRTC e la trasmissione dei flussi, oltre alla trasmissione dei messaggi di segnalazione tra i client per stabilire la connessione (WebRTC descrive solo il formato dei dati, non il meccanismo per la loro trasmissione). Nel caso in cui i client siano dietro NAT, WebRTC connette server STUN; se questo non aiuta, server TURN.<\/p>\n

Una connessione p2p normale non \u00e8 sufficiente, poich\u00e9 vogliamo registrare le lezioni per un'analisi futura in caso di reclami. Quindi, inoltriamo i flussi WebRTC tramite un relay. Janus Gateway di Meetecho<\/a><\/noindex>. Di conseguenza, i client non conoscono gli indirizzi l'uno dell'altro, vedendo solo l'indirizzo del server Janus; quest'ultimo funge anche da server di segnalazione. Janus ha molte funzionalit\u00e0 utili: passa automaticamente a TCP se il client ha bloccato UDP; \u00e8 in grado di registrare flussi sia UDP che TCP; \u00e8 scalabile; e ha anche un plugin incorporato per test di eco. Se necessario, i server STUN e TURN di Twilio vengono connessi automaticamente.<\/p>\n

Nell'estate del 2017 avevamo due server Janus attivi pi\u00f9 un server aggiuntivo per elaborare i file audio e video grezzi registrati, in modo da non occupare i processori dei server principali. Durante la connessione, i server Janus venivano selezionati secondo un principio di pari-dispari (numero di connessione). A quel tempo, questo era sufficiente, dando una percezione di circa quattro volte di margine di sicurezza, con una percentuale di implementazione di circa l'80. Inoltre, il costo era ridotto a ~2 rubli per lezione, pi\u00f9 lo sviluppo e la manutenzione.<\/p>\n

\"Da<\/p>\n

Ritorniamo al tema della videocomunicazione<\/h2>\n

Monitoriamo costantemente il feedback degli studenti e dei docenti per identificare tempestivamente e affrontare i problemi. Nel 2018, la qualit\u00e0 della connessione si \u00e8 attestata tra le principali lamentele. Da un lato, ci\u00f2 significava che eravamo riusciti a risolvere altri difetti. Dall'altro, c'era bisogno di agire rapidamente: se una lezione viene interrotta, rischiamo di perdere il suo valore, a volte insieme al costo dell'acquisto del pacchetto successivo, e se un incontro introduttivo viene interrotto, rischiamo di perdere un cliente potenziale.<\/p>\n

All'epoca, il nostro servizio di videoconferenza era ancora in modalit\u00e0 MVP. In parole semplici, lo abbiamo lanciato, ha funzionato, lo abbiamo scalato una volta, abbiamo capito come farlo \u2014 ecco fatto. If it works, don\u2019t fix it. Nessuno si \u00e8 concentrato specificamente sulla qualit\u00e0 della connessione. A agosto, \u00e8 diventato chiaro che non poteva continuare cos\u00ec, e abbiamo avviato un percorso separato per capire cosa non andava con WebRTC e Janus.<\/p>\n

All'inizio, questo percorso ha ricevuto: soluzione MVP, nessuna metrica, nessun obiettivo, nessun processo di miglioramento, mentre il 7% degli insegnanti lamentava problemi di qualit\u00e0 della connessione (non avevamo dati sugli studenti).<\/p>\n

\"Da<\/p>\n

Una nuova direzione viene avviata.<\/h2>\n

Il comando \u00e8 pi\u00f9 o meno cos\u00ec:<\/p>\n