En este artículo, compartiré mi experiencia con la tecnología WebRTC y el servidor de medios Kurento durante la fase de prueba e implementación. Te diré qué problemas encontré y cómo los resolví. No hablaré sobre cómo desarrollar una aplicación desde cero, pero daré muchos enlaces útiles. Estoy seguro de que mi historia será útil para aquellos que van a trabajar con WebRTC.
Introduccion
El Sistema de Información Médica (MIS), que está siendo desarrollado por nuestra empresa, ya se ha convertido en un gran proyecto empresarial con muchos microservicios, autobuses de mensajería, clientes móviles, etc. Algunas partes del sistema deben entregarse para el desarrollo y el apoyo a organizaciones de terceros, ya que no son nuestro perfil.
El servicio de telemedicina es uno de esos módulos MIS. No había experiencia en el desarrollo de videoconferencias y el uso de WebRTC y el pedido fue delegado. Pero después de un tiempo, debido a varias circunstancias, esta compañía dejó de admitir la videoconferencia. Sin soporte, este servicio fue deshabilitado y "acumulando polvo" en el repositorio.
Y ahora es el momento de revivir este micro servicio. Se decidió intentar reiniciar Telemedicine por su cuenta. Nuestra empresa ha crecido, han aparecido más especialistas: es posible y necesario dominar nuevos temas para el desarrollo. No había estado involucrado en la transmisión de video antes, pero fue muy interesante entender y estudiar una tecnología tan prometedora como WebRTC.
Aquí hay algunos enlaces muy útiles sobre la tecnología WebRTC y el servidor Kurento que me ayudaron al principio:
Empezando
La tarea era simple: restaurar el sistema de videoconferencia existente, hacer un inventario de lo que ya se había hecho antes y, si es necesario, modificarlo de acuerdo con los deseos de los usuarios. Las primeras pruebas en máquinas virtuales y computadoras reales tuvieron éxito. Pero el despliegue del sistema en el cliente trajo muchos problemas.
Permítame recordarle que el cliente ya tiene un sistema de información médica (MIS) que cubre una gran cantidad de tareas: desde la cola electrónica, el lugar de trabajo del médico, la gestión de documentos y PACS hasta el subsistema de gestión de equipos médicos.
Cuando se hizo necesario desarrollar la funcionalidad de videoconferencia para conectar al personal médico de los centros de diagnóstico (en adelante, DC) con pacientes remotos, se establecieron dos requisitos previos:
Todas las conferencias deben registrarse y almacenarse en el servidor.
Los pacientes no deben instalar ningún programa adicional en sus dispositivos, excepto el navegador, que en la mayoría de los casos ya está preinstalado.
WebRTC funciona desde un navegador sin programas o complementos adicionales. Y Kurento puede grabar todo lo que pasa por él. Y además, este servidor de medios tiene un buen conjunto de bibliotecas listas para trabajar con su API a través de Java y JavaScript, lo que simplifica enormemente el desarrollo.
El desarrollo de la parte del servidor, o más bien su base, incluso antes de comenzar la tarea, fue transferido por el cliente a una empresa de outsourcing a una empresa de terceros. Así que había un "Servidor de gestión" (CSS), una base de servidor preparada, que obtuve para la implementación.
La idea general de interacción inicialmente se veía así:
Pero en el proceso de más trabajo, todo el sistema ha cambiado y se ha vuelto más complicado.
Primera experiencia de reanimación
Después de la implementación en una red de prueba en máquinas virtuales y en varias computadoras "en vivo", se llevaron a cabo muchas pruebas y experimentos, todo funcionó a la perfección. En consecuencia, ha llegado el momento de introducirse en una red real y funcional.
Para las pruebas, una víctima responsable en forma de médico y su lugar de trabajo fueron asignados para ayudarme. ¡Y la segunda llamada a través del microservicio de telemedicina se estrelló!
Es bueno que esto haya sucedido durante la prueba beta, y además de mí y un médico que estaba satisfecho con las aventuras, nadie vio esto.
Lo que está sucediendo y por qué no se establece la conexión fue muy difícil de entender. WebRTC no muestra fallas, solo espera a que aparezca una señal. Sin saberlo, fue muy difícil depurar de alguna manera: la parte del servidor funciona bien, Kurento está en silencio en los registros, los clientes están esperando la transmisión, pero no sucede nada.
Habr ayudó (alabado sea):
Es lamentable que no conociera estas herramientas antes.
Después de analizar los datos de registro y observar el estado de las conexiones, quedó claro que tanto los scripts del lado del servidor como del cliente carecen de reacción a los eventos en el sistema WebRTC. ¿Y dónde conseguir estos eventos?
Los desarrolladores del servidor de kurento proporcionan una biblioteca JavaScript muy conveniente para trabajar con WebRTC: kurento-utils.js.
Para comenzar rápidamente, simplemente cree un objeto:
new kurentoUtils.WebRtcPeer.WebRtcPeerRecvonly(options, callback());
Y para acceder a los eventos, es necesario redefinir los métodos internos de la biblioteca. Simplifiqué el código lo más posible para hacerlo más claro:
Hablando de certificados
Dado que el artículo trata sobre mi experiencia, compartiré información de que los navegadores modernos se han vuelto muy estrictos sobre la seguridad. Si el recurso tiene un certificado autofirmado, incluso con un permiso especial, el navegador prohíbe el acceso a los periféricos de la computadora.
Puede crear un certificado de recursos gratuitos en Internet y configurar una red local para su uso, o puede descargar Firefox versión 65 o superior. En esta versión, simplemente haga clic en el botón, que estoy de acuerdo con los riesgos de certificados autofirmados y cámaras de acceso y micrófonos.
Este camino me pareció más fácil.
Segunda prueba (ya cuidadosa)
Me pareció que el médico correría por palomitas de maíz cuando me viera en la próxima prueba. Claramente disfrutaba viéndome luchar con la tecnología moderna.
De hecho, esta actualización del sistema no fue una versión, porque no arreglé nada, ni siquiera sabía la causa de los problemas. Repito que todo funcionó perfectamente en la oficina. El código agregó reacciones a todos los eventos que generaron WebRTC y Kurento, a los que contacté, y todo esto se escribió con gran detalle en los registros. Incluso puse mis registros en archivos separados para que no se confundan con los principales en el IIA.
Junto con un médico entusiasta y un administrador del sistema cliente, probamos el sistema. Ni siquiera probaron, es decir, "torturados". Creamos videoconferencias en todos los modos posibles y desde todos los dispositivos disponibles. Otros médicos y parte del personal de la oficina remota estuvieron involucrados en este juego.
Lo principal no era verificar el sistema (no funcionaba), sino recopilar la mayor cantidad de datos posible. Como resultado, resultó que:
- Aproximadamente el 80% de los intentos de crear una videoconferencia son exitosos.
- Algunas conexiones que utilizan candidatos ICE para IPv6 no funcionan.
- De 5 operadores móviles, solo 2 funcionaron.
Todo resultó ser simple: no puedes llegar lejos solo en Google
El análisis de la información recopilada mostró que la conexión a través del servidor TURN de Google es inestable. O la carga en ellos es grande, o es solo un servidor de demostración para aquellos que recién comienzan a aprender la tecnología. Pero de hecho: fallas muy frecuentes. ¡Necesita su propio servidor TURN / STUN!
La segunda razón de las fallas son las direcciones locales IPv6. El servidor de kurento no acepta candidatos de ICE con estas direcciones. Es bueno que antes de enviar a todos los candidatos de ICE revisen el código en mis manos y acabo de filtrar IPv6.local.
El problema de los operadores móviles se resuelve, nuevamente, con su servidor TURN / STUN.
En tres de cada cinco operadores móviles, NAT es simétrico y WebRTC no puede abrirse paso. Se pueden encontrar más detalles aquí:
¿Es terrible la NAT simétrica?Es una pena que mi teléfono móvil personal funcione en una tarjeta SIM de un operador que no se molestó con la protección simétrica. Por lo tanto, mi prueba inicial no reveló este problema.
Servidor TURN / STUN
El paquete resiprocate-turn-server fue elegido como su servidor.
No eligieron durante mucho tiempo, está en el repositorio estándar de ubuntu, fácil instalación y actualizaciones automáticas. Pero no es muy conveniente trabajar con cuentas para conectarse: los inicios de sesión y las contraseñas se toman solo del archivo, por lo que debe crear una utilidad o script adicional para exportar desde la base de datos del servidor principal.
Por el momento, este archivo se genera a mano y las cuentas se distribuyen a través de un grupo de contraseñas simple. La autorización se implementa a través del servidor principal MIS, por lo que la seguridad no se ve comprometida. Pero la estructura general de todo el sistema se ve fea. Los planes para rehacer este momento.
Tercer viaje al cliente
Corrigí el código, instalé y configuré mi servidor TURN / STUN, desarrollé un grupo de contraseñas y las distribuí a los clientes al comienzo de una videoconferencia y, después de actualizar los servidores de producción, fui a un médico que ya conocía.
Funciona! ¡Hurra! Todos los inicios de la conferencia son exitosos desde todos los dispositivos y en todos los modos: el paciente desde la cuenta personal puede llamar al médico, el terapeuta durante la recepción puede llamar al diagnóstico funcional para una consulta adicional, y los propios médicos pueden organizar una videoconferencia multiusuario de diferentes sucursales de toda la ciudad.
Ya enseñado por la amarga experiencia, participamos en pruebas meticulosas con la creación artificial de situaciones de emergencia. Del tema de este artículo, destaco la necesidad de establecer un límite en el tiempo de espera de la conexión. WebRTC, junto con Kurento, esperan que la transmisión comience infinitamente y esperan que los bytes de video estén a punto de desaparecer. Tuve que configurar un temporizador para 10 segundos, lo que da un error al servidor de gestión si los bytes nunca llegaron.
Después de todas las mejoras.
Finalmente, el sistema funciona y funciona bien. Las primeras revisiones fueron enviadas por los usuarios en el campo. E inmediatamente apareció una gran cantidad de deseos y sugerencias para el diseño, funciones adicionales y otros planes para un mayor desarrollo. ¡El trabajo comenzó a hervir con renovado vigor!
Ahora la topología del sistema completo se ve así:
RESULTADOS
En conclusión, quiero decir lo siguiente:
En primer lugar, WebRTC es una tecnología excelente con grandes perspectivas, pero es muy difícil de probar y depurar. Antes de comenzar el desarrollo, es imprescindible implementar una red con todo tipo de conexiones que pueda tener el cliente. Y la depuración a través de la ventana de información del navegador no es una herramienta muy conveniente.
En segundo lugar, alabado sea Habru! Mientras trabajaba en este proyecto, encontré mucha información sobre este recurso. Todos los enlaces en este artículo conducen a él.
Se decidió abandonar el proyecto de videoconferencia de telemedicina para el soporte y desarrollo de nuestra organización; no lo externalizaremos. En el futuro, todavía hay mucho trabajo:
TODO
Estoy seguro de que mi experiencia será útil no solo para desarrolladores bajo WebRTC + Kurento, sino también para aquellos que van a comenzar a implementar proyectos igualmente complejos. Presta más atención a las pruebas en condiciones lo más cercanas posible a la realidad.
Y tenga en cuenta los riesgos de que los equipos de soporte para sus microservicios puedan "desaparecer" repentinamente; esta es una tarea muy inesperada y desagradable.