{"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\/es\/blog\/administrirovanie\/ot-skype-do-webrtc-kak-my-organizovali-videosvyaz-cherez-veb","title":{"rendered":"De Skype a WebRTC: c\u00f3mo organizamos la videocomunicaci\u00f3n a trav\u00e9s de la web","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"De<\/p>\n

La videoconferencia es el principal medio de comunicaci\u00f3n entre el profesor y el estudiante en la plataforma Vimbox. Abandonamos Skype hace tiempo, probamos varias soluciones de terceros y finalmente nos decidimos por la combinaci\u00f3n WebRTC - Janus-gateway. Durante un tiempo, todo funcion\u00f3 bien, pero algunos aspectos negativos segu\u00edan apareciendo. As\u00ed que se cre\u00f3 una direcci\u00f3n separada para el video.<\/p>\n

Le ped\u00ed a Kirill Rogovoy, el l\u00edder de esta nueva direcci\u00f3n, que hablara sobre la evoluci\u00f3n de la videoconferencia en Skyeng, los problemas encontrados, las soluciones y los parches que usamos al final. Esperamos que el art\u00edculo sea \u00fatil para las empresas que tambi\u00e9n implementan video a trav\u00e9s de aplicaciones web.<\/p>\n

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

Un poco de historia<\/h2>\n

En el verano de 2017, el jefe de desarrollo de Skyeng, Sergey Safonov, se present\u00f3 en Backend Conf para contar c\u00f3mo 'abandonamos Skype e implementamos WebRTC'. Los interesados pueden ver la grabaci\u00f3n de la ponencia por el enlace<\/a><\/noindex> (~45 min), y aqu\u00ed resumir\u00e9 brevemente su contenido.<\/p>\n

Para la escuela Skyeng, la videoconferencia siempre ha sido la forma prioritaria de comunicaci\u00f3n entre el profesor y el alumno. Al principio utilizamos 'Skype', pero no nos satisfac\u00eda en absoluto por varias razones, principalmente debido a la falta de registros y la imposibilidad de integrarlo directamente en la aplicaci\u00f3n web. Por eso hicimos varios experimentos.<\/p>\n

En realidad, nuestros requisitos para la videoconferencia eran aproximadamente los siguientes:
\n\u2014 estabilidad;
\n\u2014 bajo costo por lecci\u00f3n;
\n\u2014 grabaci\u00f3n de lecciones;
\n\u2014 seguimiento de cu\u00e1nto habla cada uno (es importante para nosotros que los estudiantes hablen m\u00e1s que el profesor durante las lecciones);
\n\u2014 escalabilidad lineal;
\n\u2014 posibilidad de usar tanto UDP como TCP.<\/p>\n

El primero en probar fue Tokbox en 2013. Todo iba bien, pero result\u00f3 ser muy caro: 113 rublos por lecci\u00f3n, lo que consum\u00eda nuestras ganancias.<\/p>\n

Luego, en 2015, integramos Voximplant. Aqu\u00ed ten\u00edamos la funci\u00f3n necesaria para rastrear cu\u00e1nto habla cada uno y, adem\u00e1s, era significativamente m\u00e1s barata: con solo grabaci\u00f3n de audio, sal\u00eda 20 rublos por lecci\u00f3n. Sin embargo, solo funcionaba a trav\u00e9s de UDP, no pod\u00eda cambiar a TCP. A pesar de eso, alrededor del 40% de los estudiantes lo utilizaron.<\/p>\n

Despu\u00e9s de un a\u00f1o, comenzamos a tener clientes corporativos con requisitos espec\u00edficos. Por ejemplo, todo debe funcionar a trav\u00e9s del navegador, en la empresa solo est\u00e1n habilitados http y https; es decir, nada de \u00abSkype\u00bb y UDP. Clientes corporativos = dinero, por lo que regresamos a Tokbox, pero el problema del precio no desapareci\u00f3.<\/p>\n

La soluci\u00f3n es WebRTC y Janus<\/h2>\n

Decidimos usar una plataforma de navegador para videoconferencias peer-to-peer WebRTC<\/a><\/noindex>. Esta se encarga de establecer la conexi\u00f3n, codificar y decodificar flujos, sincronizar pistas y controlar la calidad al manejar fallos de red. De nuestra parte, debemos asegurarnos de leer los flujos de la c\u00e1mara y el micr\u00f3fono, renderizar el video, gestionar la conexi\u00f3n, establecer la conexi\u00f3n WebRTC y transmitirle los flujos, as\u00ed como enviar mensajes de se\u00f1alizaci\u00f3n entre los clientes para establecer la conexi\u00f3n (WebRTC solo describe el formato de datos, pero no el mecanismo para su transmisi\u00f3n). En caso de que los clientes est\u00e9n detr\u00e1s de NAT, WebRTC conecta servidores STUN, y si eso no ayuda, servidores TURN.<\/p>\n

Una conexi\u00f3n p2p ordinaria no es suficiente, ya que queremos grabar las lecciones para an\u00e1lisis posteriores en caso de quejas. Por lo tanto, enviamos los flujos de WebRTC a trav\u00e9s de un retransmisor Janus Gateway de Meetecho<\/a><\/noindex>. Como resultado, los clientes no conocen las direcciones entre s\u00ed, solo ven la direcci\u00f3n del servidor Janus; este tambi\u00e9n funciona como servidor de se\u00f1alizaci\u00f3n. Janus tiene muchas caracter\u00edsticas que necesitamos: cambia autom\u00e1ticamente a TCP si el cliente tiene bloqueado UDP; puede grabar flujos tanto en UDP como en TCP; es escalable; incluso tiene un plugin incorporado para pruebas de eco. Si es necesario, se conectan autom\u00e1ticamente los servidores STUN y TURN de Twilio.<\/p>\n

En el verano de 2017 ten\u00edamos dos servidores Janus m\u00e1s un servidor adicional para procesar los archivos de audio y video crudos grabados, para no utilizar los procesadores de los principales. Al conectarse, los servidores Janus se seleccionaban por el principio par-impar (n\u00famero de conexi\u00f3n). En ese momento, esto era suficiente, ya que nos daba alrededor de cuatro veces m\u00e1s de capacidad de lo que necesit\u00e1bamos, con un porcentaje de implementaci\u00f3n de aproximadamente 80. A su vez, el costo se redujo a ~2 rublos por lecci\u00f3n, m\u00e1s desarrollo y soporte.<\/p>\n

\"De<\/p>\n

Volviendo al tema de las videoconferencias<\/h2>\n

Estamos constantemente monitorizando los comentarios de los alumnos y profesores para identificar y abordar problemas a tiempo. Para el verano de 2018, la calidad de la conexi\u00f3n se hab\u00eda consolidado como la principal queja. Por un lado, esto significaba que hab\u00edamos solucionado con \u00e9xito otras deficiencias. Por otro lado, hab\u00eda que actuar r\u00e1pidamente: al interrumpir una clase, corremos el riesgo de perder su valor, a veces junto con el coste de la siguiente compra de paquete; y al interrumpir la clase introductoria, incluso podr\u00edamos perder a un cliente potencial.<\/p>\n

En ese momento, nuestra videoconferencia segu\u00eda funcionando en modo MVP. En otras palabras, lanzamos, funcion\u00f3, escalamos una vez, entendimos c\u00f3mo hacerlo \u2014y eso fue genial. If it works, don\u2019t fix it. Nadie se ocupaba deliberadamente de la calidad de la conexi\u00f3n. Para agosto, qued\u00f3 claro que esto no pod\u00eda continuar as\u00ed, por lo que lanzamos una direcci\u00f3n especial para investigar qu\u00e9 estaba mal con WebRTC y Janus.<\/p>\n

A la entrada, esta direcci\u00f3n lleg\u00f3 con: soluci\u00f3n MVP, sin m\u00e9tricas, sin objetivos, sin procesos de mejora, y al mismo tiempo, el 7% de los profesores se quejan de la calidad de la conexi\u00f3n (no hab\u00eda datos sobre los alumnos tampoco).<\/p>\n

\"De<\/p>\n

La nueva direcci\u00f3n se pone a trabajar<\/h2>\n

El comando se ve aproximadamente as\u00ed:<\/p>\n