La comunicación por vídeo es la principal forma de comunicación entre profesor y alumno en la plataforma Vimbox. Dejamos Skype hace mucho tiempo, probamos varias soluciones de terceros y finalmente nos decidimos por la combinación WebRTC - Janus-gateway. Durante algún tiempo estuvimos contentos con todo, pero aún así siguieron apareciendo algunos aspectos negativos. Como resultado, se creó una dirección de video separada.
Le pedí a Kirill Rogovoy, director de la nueva dirección, que me hablara sobre la evolución de la comunicación por vídeo en Skyeng, los problemas descubiertos, las soluciones y las muletas que finalmente utilizamos. Esperamos que el artículo sea de utilidad para empresas que también crean vídeo por su cuenta a través de una aplicación web.
Un poco de historia
En el verano de 2017, el jefe de desarrollo de Skyeng, Sergey Safonov, habló en Backend Conf con una historia sobre cómo "abandonamos Skype e implementamos WebRTC". Los interesados pueden ver la grabación del discurso en (~45 min), y aquí describiré brevemente su esencia.
Para Skyeng School, la comunicación por vídeo siempre ha sido una forma prioritaria de comunicación entre profesores y alumnos. Al principio se utilizó Skype, pero categóricamente no fue satisfactorio por varias razones, principalmente por la falta de registros y la imposibilidad de integración directamente en la aplicación web. Por eso, llevamos a cabo todo tipo de experimentos.
En realidad, nuestros requisitos para la comunicación por video eran aproximadamente los siguientes:
— estabilidad;
— precio bajo por lección;
— grabar lecciones;
— seguimiento de quién habla y cuánto (para nosotros es importante que los estudiantes hablen más que el profesor durante las lecciones);
— escala lineal;
- capacidad de utilizar tanto UDP como TCP.
El primero en intentarlo fue implementar Tokbox en 2013. Todo estuvo bien, pero resultó ser muy caro (113 rublos por lección) y se comió las ganancias.
Luego, en 2015, se integró Voximplant. Aquí estaba la función que necesitábamos para rastrear quién hablaba cuánto y, al mismo tiempo, la solución era mucho más económica: si solo se grababa audio, costaba 20 rublos por lección. Sin embargo, sólo funcionó a través de UDP y no pudo cambiar a TCP. Sin embargo, alrededor del 40% de los estudiantes terminaron usándolo.
Un año después, empezamos a tener clientes corporativos con sus propios requerimientos específicos. Por ejemplo, todo debería funcionar a través de un navegador, la empresa sólo abre http y https; es decir, sin Skype ni UDP. Clientes corporativos = dinero, entonces regresaron a Tokbox, pero el problema del precio no desapareció.
Solución: WebRTC y Janus
decidió usar . Es responsable de establecer una conexión, codificar y decodificar transmisiones, sincronizar pistas y controlar la calidad del manejo de fallas en la red. Por nuestra parte, debemos asegurarnos de leer los flujos de la cámara y el micrófono, dibujar videos, administrar la conexión, establecer una conexión WebRTC y transmitir flujos a ella, así como transmitir mensajes de señalización entre clientes para establecer una conexión (el propio WebRTC describe solo el formato de datos, pero no su mecanismo de transferencia). Si los clientes están detrás de NAT, WebRTC conecta los servidores STUN; si esto no ayuda, los servidores TURN.
Una conexión p2p normal no nos basta, porque queremos grabar las lecciones para su posterior análisis en caso de quejas. Por lo tanto, enviamos transmisiones WebRTC a través de un relé. . Como resultado, los clientes no conocen las direcciones de los demás y solo ven la dirección del servidor Janus; también realiza las funciones de un servidor de señales. Janus tiene muchas de las características que necesitamos: cambia automáticamente a TCP si el cliente tiene UDP bloqueado; puede grabar flujos UDP y TCP; escalable; Incluso hay un complemento integrado para pruebas de eco. Si es necesario, los servidores STUN y TURN de Twilio se conectan automáticamente.
En el verano de 2017, teníamos dos servidores Janus en funcionamiento, más un servidor adicional para procesar archivos de audio y vídeo sin procesar grabados, para no ocupar los procesadores de los principales. Al conectarse, los servidores de Janus se seleccionaron de forma impar o par (número de conexión). En aquel momento, esto era suficiente, según nuestra opinión, daba aproximadamente un margen de seguridad cuatro veces mayor, el porcentaje de implementación era de aproximadamente 80. Al mismo tiempo, el precio se redujo a ~2 rublos por lección, más desarrollo y soporte.
Volviendo al tema de la comunicación por vídeo.
Monitoreamos constantemente los comentarios de estudiantes y maestros para identificar y corregir problemas de manera oportuna. En el verano de 2018, la calidad de las llamadas ocupaba el primer lugar entre las quejas. Por un lado, esto significó que habíamos superado con éxito otras deficiencias. Por otro lado, era necesario hacer algo con urgencia: si se interrumpe la lección, corremos el riesgo de perder su valor, a veces junto con el costo de comprar el siguiente paquete, y si se interrumpe la lección introductoria, corremos el riesgo de perder un cliente potencial. en total.
En ese momento, nuestra comunicación por video todavía estaba en modo MVP. En pocas palabras, lo lanzaron, funcionó, lo ampliaron una vez, entendieron cómo hacerlo... bueno, genial. Si funciona, no lo arregles. Nadie abordó deliberadamente la cuestión de la calidad de la comunicación. En agosto, quedó claro que esto no podía continuar y lanzamos una dirección separada para descubrir qué estaba mal con WebRTC y Janus.
En la entrada, esta dirección recibió: una solución MVP, sin métricas, sin metas, sin procesos de mejora, mientras que el 7% de los docentes se queja de la calidad de la comunicación (tampoco hubo datos sobre los estudiantes).
Una nueva dirección está en marcha
El comando se parece a esto:
- El jefe del departamento, que también es el principal desarrollador.
- El control de calidad ayuda a probar los cambios, busca nuevas formas de crear condiciones de comunicación inestables e informa problemas desde primera línea.
- El analista busca constantemente diversas correlaciones en los datos técnicos, mejora el análisis de los comentarios de los usuarios y verifica los resultados de los experimentos.
- El gerente de producto ayuda con la dirección general y la asignación de recursos para los experimentos.
- Un segundo desarrollador suele ayudar con la programación y tareas relacionadas.
Para empezar, configuramos una métrica relativamente confiable que rastreaba los cambios en las evaluaciones de la calidad de la comunicación (promedio durante días, semanas y meses). En ese momento, estas eran calificaciones de los profesores; luego se les agregaron calificaciones de los estudiantes. Luego comenzaron a formular hipótesis sobre lo que estaba funcionando mal, a corregirlo y a observar los cambios en la dinámica. Optamos por lo más fácil: por ejemplo, reemplazamos el códec vp8 por vp9 y el rendimiento mejoró. Intentamos jugar con la configuración de Janus y realizar otros experimentos; en la mayoría de los casos no condujeron a nada.
En la segunda etapa, surgió una hipótesis: WebRTC es una solución peer-to-peer y usamos un servidor en el medio. ¿Quizás el problema esté aquí? Comenzamos a investigar y encontramos la mejora más significativa hasta el momento.
En ese momento, se seleccionó un servidor del pool mediante un algoritmo bastante estúpido: cada uno tenía su propio “peso”, dependiendo del canal y la potencia, e intentamos enviar al usuario al que tenía mayor “peso”, sin prestando atención a dónde se encontraba geográficamente el usuario. Como resultado, un profesor de San Petersburgo podría comunicarse con un estudiante de Siberia a través de Moscú y no a través de nuestro servidor Janus en San Petersburgo.
El algoritmo se ha rehecho: ahora, cuando un usuario abre nuestra plataforma, recopilamos sus pings a todos los servidores utilizando Ajax. Al establecer una conexión, seleccionamos un par de pings (profesor-servidor y alumno-servidor) con la menor cantidad. Menos ping significa menos distancia de la red hasta el servidor; una distancia más corta significa una menor probabilidad de perder paquetes; La pérdida de paquetes es el mayor factor negativo en la comunicación por vídeo. La proporción de negatividad se redujo a la mitad en tres meses (para ser justos, se llevaron a cabo otros experimentos en ese momento, pero es casi seguro que éste tuvo el mayor impacto).
Recientemente descubrimos otra cosa que no es obvia, pero aparentemente importante: en lugar de un servidor Janus potente en un canal grueso, es mejor tener dos más simples con un ancho de banda más reducido. Esto quedó claro después de que compramos máquinas potentes con la esperanza de poder llenarlas con tantas salas (sesiones de comunicación) al mismo tiempo. Los servidores tienen un límite de ancho de banda, que podemos traducir con precisión al número de habitaciones: sabemos cuántas se pueden abrir, por ejemplo, a 300 Mbit/s. En cuanto hay demasiadas salas abiertas en un servidor, dejamos de elegirlo para nuevas actividades hasta que la carga disminuya. La idea era que, habiendo comprado una máquina potente, le cargáramos el canal al máximo, para que al final quedara limitado por el procesador y la memoria, y no por el ancho de banda. Pero resultó que después de un cierto número de salas abiertas (420), a pesar de que la carga en el procesador, la memoria y el disco aún está muy lejos de los límites, la negatividad comienza a llegar al soporte técnico. Aparentemente, algo está empeorando dentro de Janus, tal vez allí también haya algunas restricciones. Empezamos a experimentar, redujimos el límite de ancho de banda de 300 a 200 Mbit/s y los problemas desaparecieron. Ahora compramos tres nuevos servidores a la vez con límites y características bajos, creemos que esto conducirá a una mejora estable en la calidad de la comunicación. Por supuesto, no intentamos descubrir qué estaba pasando allí; nuestras muletas lo son todo. En nuestra defensa, digamos que en ese momento era necesario resolver el problema urgente lo más rápido posible, y no hacerlo de manera hermosa; Además, Janus para nosotros es una caja negra escrita en C, es muy caro modificarla.
Bueno, en el proceso nosotros:
- actualizó todas las dependencias que podían actualizarse, tanto en el servidor como en el cliente (estos también fueron experimentos, monitoreamos los resultados);
- se corrigieron todos los errores identificados relacionados con casos específicos, por ejemplo, cuando la conexión se interrumpía y no se restablecía automáticamente;
- Mantuvimos muchas reuniones con empresas que trabajan en el campo de las videocomunicaciones y que conocen nuestros problemas: transmisión de juegos, organización de seminarios web; probamos todo lo que nos pareció útil;
- Se realizó una revisión técnica del hardware y la calidad de la comunicación de los docentes, de quienes provinieron la mayor cantidad de quejas.
Los experimentos y los cambios posteriores permitieron reducir la insatisfacción con la comunicación entre los docentes del 7,1% en enero de 2018 al 2,5% en enero de 2019.
¿Qué sigue
Estabilizar nuestra plataforma Vimbox es uno de los principales proyectos de la compañía para 2019. Tenemos grandes esperanzas de poder mantener el impulso y dejar de ver la comunicación por vídeo entre las principales quejas. Entendemos que una parte importante de estas quejas están relacionadas con retrasos en los ordenadores de los usuarios y en Internet, pero debemos determinar esta parte y solucionar el resto. Todo lo demás es un problema técnico, parece que deberíamos poder solucionarlo.
La principal dificultad es que no sabemos hasta qué punto es realmente posible mejorar la calidad. Descubrir este techo es la tarea principal. Por tanto, se planificaron dos experimentos:
- Compare el video a través de Janus con el p2p normal en condiciones de combate. Este experimento ya se realizó, no se encontró ninguna diferencia estadísticamente significativa entre nuestra solución y p2p;
- Ofrezcamos servicios (caros) de empresas que ganan dinero exclusivamente con soluciones de comunicación por vídeo y comparemos la cantidad de negatividad de ellas con la existente.
Estos dos experimentos nos permitirán identificar un objetivo alcanzable y centrarnos en él.
Además, hay una serie de tareas que se pueden resolver de forma rutinaria:
- Creamos una métrica técnica de calidad de la comunicación en lugar de revisiones subjetivas;
- Realizamos registros de sesiones más detallados para analizar con mayor precisión las fallas que ocurren, comprender cuándo y dónde ocurrieron exactamente y qué eventos aparentemente no relacionados tuvieron lugar en ese momento;
- Preparamos una prueba automática de calidad de la conexión antes de la lección y también le damos al cliente la oportunidad de probar manualmente la conexión para reducir la cantidad de negatividad causada por su hardware y canal;
- desarrollaremos y realizaremos más pruebas de carga de comunicaciones de vídeo en malas condiciones, con pérdida variable de paquetes, etc.;
- cambiamos el comportamiento de los servidores en caso de problemas para aumentar la tolerancia a fallos;
- Avisaremos al usuario si hay algún problema con su conexión, como hace Skype, para que entienda que el problema está de su lado.
Desde abril, la dirección de comunicación por vídeo se ha convertido en un proyecto independiente y completo dentro de Skyeng, que se ocupa de su propio producto, no solo de una parte de Vimbox. Esto significa que estamos empezando a buscar personas en . Bueno, como siempre .
Y, por supuesto, seguimos comunicándonos activamente con personas y empresas que trabajan con comunicaciones por vídeo. Si quieres intercambiar experiencias con nosotros, ¡estaremos encantados! Comenta, ponte en contacto, responderemos a todos.
Fuente: habr.com