{"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 comunicazione video tramite il web","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Da<\/p>\n

La videocomunicazione \u00e8 il principale modo di comunicare tra insegnante e studente sulla piattaforma Vimbox. Da tempo abbiamo abbandonato Skype, sperimentato diverse soluzioni di terze parti e alla fine ci siamo fermati sulla combinazione WebRTC - Janus-gateway. Per un certo periodo siamo stati soddisfatti, ma alcuni aspetti negativi continuavano a emergere. Alla fine, \u00e8 stato creato un dipartimento separato per i video.<\/p>\n

Ho chiesto a Kirill Rogovoy, il responsabile del nuovo dipartimento, di raccontare l'evoluzione della videocomunicazione in Skyeng, i problemi riscontrati, le soluzioni e i workaround che alla fine abbiamo adottato. Speriamo che l'articolo sia utile per le aziende che stanno affrontando in autonomia la video comunicazione attraverso un'app web.<\/p>\n

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

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

Nell'estate del 2017, il responsabile dello sviluppo di Skyeng, Sergey Safonov, ha partecipato al Backend Conf parlando di come abbiamo \"abbandonato Skype e implementato WebRTC\". Chi \u00e8 interessato pu\u00f2 vedere la registrazione dell'intervento su link<\/a><\/noindex> (~45 min), qui riassumer\u00f2 brevemente i punti salienti.<\/p>\n

Per la scuola Skyeng, la videocomunicazione \u00e8 sempre stata un modo prioritario di interazione tra insegnante e studente. Inizialmente utilizzavamo Skype, ma non era affatto soddisfacente per una serie di motivi, principalmente per la mancanza di log e l'impossibilit\u00e0 di integrazione direttamente nell'applicazione web. Pertanto, abbiamo condotto vari esperimenti.<\/p>\n

Le nostre esigenze per la videocomunicazione erano pi\u00f9 o meno le seguenti:
\n\u2014 stabilit\u00e0;
\n\u2014 costo ridotto per lezione;
\n\u2014 registrazione delle lezioni;
\n\u2014 monitoraggio di quanto parla ciascuno (\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

Nel 2013 abbiamo provato per primi a implementare Tokbox. Andava tutto bene, ma risultava molto costoso: 113 rubli per lezione \u2013 e riduceva i profitti.<\/p>\n

Poi, nel 2015, abbiamo integrato Voximplant. Qui c'era la funzione necessaria per monitorare quanto parlava ciascuno, e in pi\u00f9 la soluzione era significativamente pi\u00f9 economica: con solo la registrazione audio si arrivava a 20 rubli per lezione. Tuttavia, funzionava solo attraverso UDP, non era in grado di passare a TCP. Tuttavia, alla fine circa il 40% degli studenti la utilizzava.<\/p>\n

Dopo un anno abbiamo iniziato ad avere clienti aziendali con requisiti specifici. Ad esempio, tutto deve funzionare attraverso il browser, in azienda sono aperti solo http e https; ovvero, niente \u00abSkype\u00bb e UDP. Clienti aziendali = denaro, quindi siamo tornati a Tokbox, ma il problema del prezzo era ancora presente.<\/p>\n

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

Abbiamo deciso di utilizzare una piattaforma browser per videocomunicazione peer-to-peer WebRTC<\/a><\/noindex>. Si occupa dell'instaurazione della connessione, della codifica e decodifica dei flussi, della sincronizzazione delle tracce e del controllo della qualit\u00e0 trattando le problematiche di rete. Da parte nostra, dobbiamo garantire la cattura dei flussi dalla videocamera e dal microfono, il rendering video, la gestione della connessione, l'instaurazione della connessione WebRTC e la trasmissione dei flussi, oltre alla comunicazione dei messaggi di segnalazione tra i client per stabilire la connessione (WebRTC descrive solo il formato dei dati, ma non il meccanismo per la loro trasmissione). Nel caso in cui i client siano dietro un NAT, WebRTC collega i server STUN, se questo non aiuta, i server TURN.<\/p>\n

Una normale connessione p2p non \u00e8 sufficiente, poich\u00e9 vogliamo registrare le lezioni per ulteriori analisi in caso di reclami. Pertanto, inviamo 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; questo svolge anche le funzioni di server di segnalazione. Janus ha molte delle funzionalit\u00e0 di cui abbiamo bisogno: passa automaticamente a TCP se il client blocca UDP; pu\u00f2 registrare flussi sia UDP che TCP; \u00e8 scalabile; c'\u00e8 persino un plugin integrato per test di eco. Se necessario, i server STUN e TURN di Twilio si connettono automaticamente.<\/p>\n

Nell'estate del 2017 avevamo in funzione due server Janus pi\u00f9 un server aggiuntivo per l'elaborazione dei file audio e video grezzi registrati, in modo da non sovraccaricare i processori principali. Con il collegamento, i server Janus venivano selezionati in base al principio pari-dispari (numero di connessione). A quel tempo, ci\u00f2 era sufficiente e ci dava un margine di sicurezza di circa quattro volte, con un tasso di implementazione del 80%. Inoltre, il costo \u00e8 sceso a ~2 rubli per lezione, pi\u00f9 lo sviluppo e il supporto.<\/p>\n

\"Da<\/p>\n

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

Monitoriamo costantemente il feedback degli studenti e degli insegnanti per identificare e affrontare tempestivamente i problemi. Entro l'estate del 2018, la qualit\u00e0 della connessione si era consolidata al primo posto tra le lamentele. Da un lato, ci\u00f2 significava che eravamo riusciti a risolvere altre carenze. D'altro canto, era urgente fare qualcosa: in caso di un'interruzione della lezione, rischiamo di perdere il valore di essa, a volte insieme al costo dell'acquisto del pacchetto successivo, e in caso di interruzione della lezione introduttiva, potremmo addirittura perdere un cliente potenziale.<\/p>\n

A quel tempo, la videoconferenza era ancora in modalit\u00e0 MVP. In altre parole, l'abbiamo lanciata, ha funzionato, l'abbiamo scalato una volta, abbiamo capito come farlo \u2013 e cos\u00ec \u00e8 andata bene. If it works, don\u2019t fix it. Nessuno si occupava in modo specifico della questione della qualit\u00e0 della connessione. A agosto, era chiaro che non si poteva continuare cos\u00ec e abbiamo avviato un'area separata per capire cosa non andasse con WebRTC e Janus.<\/p>\n

In ingresso, questa area ricevette: soluzione MVP, nessuna metrica, nessun obiettivo, nessun processo di miglioramento, mentre il 7% degli insegnanti lamentava problemi con la qualit\u00e0 della connessione (dati sugli studenti non erano disponibili).<\/p>\n

\"Da<\/p>\n

La nuova area inizia il lavoro<\/h2>\n

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