Dans cet article, je partagerai mon expérience avec la technologie WebRTC et le serveur multimédia Kurento pendant la phase de test et d'implémentation. Je vais vous dire quels problèmes j'ai rencontrés et comment je les ai résolus. Je ne parlerai pas de la façon de développer une application à partir de zéro, mais je donnerai beaucoup de liens utiles. Je suis sûr que mon histoire sera utile à ceux qui vont travailler avec WebRTC.
Présentation
Le Medical Information System (MIS), qui est développé par notre société, est déjà devenu un énorme projet d'entreprise avec de nombreux microservices, bus de messagerie, clients mobiles, etc. Certaines parties du système doivent être données pour le développement et le soutien à des organisations tierces, car elles ne sont pas notre profil.
Le service de télémédecine est l'un de ces modules MIS. Il n'y avait aucune expérience dans le développement de la vidéoconférence et l'utilisation de WebRTC et la commande a été déléguée. Mais après un certain temps, en raison de diverses circonstances, cette entreprise a cessé de prendre en charge la vidéoconférence. Sans support, ce service a été désactivé et «rassemblait la poussière» dans le référentiel.
Et maintenant, il est temps de relancer ce micro service. Il a été décidé d'essayer de redémarrer la télémédecine par eux-mêmes. Notre entreprise a grandi, plus de spécialistes sont apparus - il est possible et nécessaire de maîtriser de nouveaux sujets de développement. Je n'avais jamais été impliqué dans la transmission vidéo auparavant, mais c'était très intéressant de comprendre et d'étudier une technologie aussi prometteuse que WebRTC.
Voici quelques liens très utiles sur la technologie WebRTC et le serveur Kurento qui m'ont aidé au départ:
Pour commencer
La tâche était simple: restaurer le système de visioconférence existant, faire l'inventaire de ce qui a déjà été fait auparavant et, si nécessaire, le modifier selon les souhaits des utilisateurs. Les premiers tests sur des machines virtuelles et de vrais ordinateurs ont réussi. Mais le déploiement du système chez le client a posé beaucoup de problèmes.
Permettez-moi de vous rappeler que le client dispose déjà d'un système d'information médicale (SIG) couvrant un grand nombre de tâches: de la file d'attente électronique, du lieu de travail du médecin, de la gestion des documents et des PACS au sous-système de gestion des équipements médicaux.
Lorsqu'il est devenu nécessaire de développer la fonctionnalité de vidéoconférence pour la communication entre le personnel médical des centres de diagnostic (ci-après dénommé DC) et les patients distants, deux conditions préalables ont été fixées:
Toutes les conférences doivent être enregistrées et stockées sur le serveur.
Les patients ne doivent pas installer de programmes supplémentaires sur leurs appareils, à l'exception du navigateur, qui dans la plupart des cas est déjà préinstallé.
WebRTC fonctionne à partir d'un navigateur sans programmes ni plugins supplémentaires. Et Kurento peut enregistrer tout ce qui le traverse. De plus, ce serveur multimédia dispose d'un bon ensemble de bibliothèques prêtes à l'emploi pour travailler avec son API via Java et JavaScript, ce qui simplifie considérablement le développement.
Le développement de la partie serveur, ou plutôt de sa base, avant même que je commence la tâche, a été transféré par le client à une société d'externalisation à une société tierce. Il y avait donc un «Managing Server» (CSS) - une base de serveurs prête à l'emploi, que j'ai obtenue pour la mise en œuvre.
L'idée générale d'interaction ressemblait initialement à ceci:
Mais au cours de travaux ultérieurs, l'ensemble du système a changé et est devenu plus compliqué.
Première expérience de réanimation
Après le déploiement dans un réseau de test sur des machines virtuelles et sur plusieurs ordinateurs «live», de nombreux tests et expériences ont été réalisés - tout a parfaitement fonctionné. En conséquence, le moment est venu d'introduire dans un véritable réseau de travail.
Pour les tests, une victime responsable sous la forme d'un médecin et son lieu de travail a été affecté pour m'aider. Et le deuxième appel via le microservice de télémédecine s'est écrasé!
C'est bien que cela se soit produit pendant le test bêta, et à part moi et un médecin qui était satisfait des aventures, personne n'a vu cela.
Ce qui se passe et pourquoi la connexion n'est pas établie était très difficile à comprendre. WebRTC ne montre aucune panne - il attend juste qu'un signal apparaisse. Sans le savoir, il a été très difficile de déboguer d'une manière ou d'une autre: la partie serveur fonctionne bien, Kurento est silencieux dans les journaux, les clients attendent le flux, mais rien ne se passe.
Habr a aidé (louange à lui):
Il est regrettable que je ne connaissais pas ces outils auparavant.
Après avoir analysé les données du journal et observé l'état des connexions, il est devenu clair que les scripts côté serveur et client manquaient de réaction aux événements dans le système WebRTC. Et où trouver ces événements?
Les développeurs du serveur kurento fournissent une bibliothèque JavaScript très pratique pour travailler avec WebRTC: kurento-utils.js.
Pour démarrer rapidement, créez simplement un objet:
new kurentoUtils.WebRtcPeer.WebRtcPeerRecvonly(options, callback());
Et pour accéder aux événements, il est nécessaire de redéfinir les méthodes internes de la bibliothèque. J'ai simplifié le code autant que possible pour le rendre plus clair:
En parlant de certificats
Étant donné que l'article concerne mon expérience, je partagerai des informations selon lesquelles les navigateurs modernes sont devenus très stricts en matière de sécurité. Si la ressource possède un certificat auto-signé, même avec une autorisation spéciale, le navigateur interdit l'accès aux périphériques de l'ordinateur.
Vous pouvez créer un certificat sur des ressources gratuites sur Internet et configurer un réseau local pour son utilisation, ou vous pouvez télécharger Firefox version 65 ou supérieure. Dans cette version, cliquez simplement sur le bouton, que je suis d'accord avec les risques des certificats auto-signés et accéder aux caméras et microphones.
Cela me semblait plus facile.
Deuxième test (déjà prudent)
Il me semblait que le médecin se présenterait pour du pop-corn quand il me verrait au prochain test. Il aimait clairement me voir lutter avec la technologie moderne.
En fait, cette mise à jour du système n'était pas une version, car je n'ai rien résolu, je ne connaissais même pas la cause des problèmes. Je répète que tout fonctionnait parfaitement au bureau. Le code a ajouté des réactions à tous les événements qui ont généré WebRTC et Kurento, que j'ai contactés, et tout cela a été écrit en détail dans les journaux. J'ai même mis mes journaux dans des fichiers séparés afin qu'ils ne soient pas confondus avec les principaux de l'IIA.
En collaboration avec un médecin passionné et un administrateur système client, nous avons essayé le système. Ils n’ont même pas testé, à savoir «torturé». Nous avons créé des vidéoconférences dans tous les modes possibles et à partir de tous les appareils disponibles. D'autres médecins et une partie du personnel du bureau distant ont été impliqués dans ce match.
L'essentiel n'était pas de vérifier le système (cela ne fonctionnait pas), mais de collecter autant de données que possible. En conséquence, il s'est avéré que:
- Environ 80% des tentatives de création d'une vidéoconférence ont réussi.
- Certaines connexions utilisant des candidats ICE pour IPv6 ne fonctionnent pas.
- Sur 5 opérateurs mobiles, 2 seulement ont travaillé.
Tout s'est avéré simple - vous ne pouvez pas aller loin sur Google seul
L'analyse des informations collectées a montré que la connexion via le serveur TURN de Google est instable. Soit leur charge est importante, soit ce n'est qu'un serveur de démonstration pour ceux qui commencent tout juste à apprendre la technologie. Mais en fait: des échecs très fréquents. Besoin de votre propre serveur TURN / STUN!
La deuxième raison des échecs est les adresses IPv6.local. Le serveur kurento n'accepte pas les candidats ICE avec ces adresses. C'est bien qu'avant d'envoyer tous les candidats ICE, je passe le code entre mes mains et je filtre simplement IPv6.local.
Le problème des opérateurs mobiles est à nouveau résolu avec son serveur TURN / STUN.
Dans trois opérateurs mobiles sur cinq, le NAT est symétrique et WebRTC ne peut pas percer. Plus de détails peuvent être trouvés ici:
Le NAT symétrique est-il terrible?C'est dommage que mon téléphone portable personnel fonctionne sur la carte SIM d'un opérateur qui n'a pas pris la peine d'une protection symétrique. Par conséquent, mes tests initiaux n'ont pas révélé ce problème.
Serveur TURN / STUN
Le package resiprocate-turn-server a été choisi comme serveur.
Ils n'ont pas choisi depuis longtemps - c'est dans le référentiel ubuntu standard - une installation facile et des mises à jour automatiques. Mais il n'est pas très pratique de travailler avec des comptes pour se connecter: les identifiants et les mots de passe sont uniquement extraits du fichier, c'est pourquoi vous devez créer un utilitaire ou un script supplémentaire pour exporter à partir de la base de données du serveur principal.
Pour le moment, ce fichier est généré manuellement et les comptes sont distribués via un simple pool de mots de passe. L'autorisation est mise en œuvre via le serveur principal MIS, la sécurité n'est donc pas compromise. Mais la structure globale de l'ensemble du système semble moche. Les plans pour refaire ce moment.
Troisième voyage chez le client
J'ai corrigé le code, installé et configuré mon serveur TURN / STUN, développé un pool de mots de passe et les ai distribués aux clients au début d'une vidéoconférence et, après la mise à jour des serveurs de production, je suis allé voir un médecin que je connaissais déjà.
Ça marche! Hourra! Tous les débuts de la conférence sont réussis à partir de tous les appareils et dans tous les modes: le patient du compte personnel peut appeler le médecin, le thérapeute pendant la réception peut appeler le diagnosticien fonctionnel pour une consultation supplémentaire, et les médecins eux-mêmes peuvent organiser une vidéoconférence multi-utilisateurs à partir de différentes branches de toute la ville.
Déjà enseigné par une expérience amère, nous nous sommes engagés dans des tests minutieux avec la création artificielle de situations d'urgence. À partir du sujet de cet article, je souligne la nécessité de fixer une limite au temps d'attente de connexion. WebRTC, avec Kurento, attendent que la diffusion commence infiniment longtemps et espère que les octets vidéo sont sur le point de disparaître. J'ai dû régler une minuterie pendant 10 secondes, ce qui donne une erreur au serveur de gestion si les octets ne sont jamais arrivés.
Après toutes les améliorations
Enfin, le système fonctionne et fonctionne bien. Les premiers avis ont été envoyés par les utilisateurs sur le terrain. Et immédiatement un grand nombre de souhaits et de suggestions de conception, de fonctions supplémentaires et d'autres plans de développement ultérieur sont apparus. Le travail a commencé à bouillir avec une vigueur renouvelée!
Maintenant, la topologie du système complet ressemble à ceci:
RÉSULTATS:
En conclusion, je veux dire ce qui suit:
Premièrement, WebRTC est une excellente technologie avec de grandes perspectives, mais il est très difficile de la tester et de la déboguer. Avant de commencer le développement, il est impératif de déployer un réseau avec toutes sortes de connexions que le client peut avoir. Et le débogage via la fenêtre d'informations du navigateur n'est pas un outil très pratique.
Deuxièmement, louange à Habru! En travaillant sur ce projet, j'ai trouvé beaucoup d'informations sur cette ressource. Tous les liens de cet article y mènent.
Il a été décidé de laisser le projet de visioconférence de télémédecine pour le support et le développement de notre organisation, nous ne l'externaliserons pas. A l'avenir, il reste encore beaucoup de travail:
TOUT
Je suis sûr que mon expérience sera utile non seulement pour les développeurs sous WebRTC + Kurento, mais aussi pour ceux qui vont commencer à mettre en œuvre des projets tout aussi complexes. Faites plus attention aux tests dans des conditions aussi proches que possible de la réalité.
Et prenez en compte les risques que les équipes de support pour vos microservices puissent soudainement «disparaître» - c'est une corvée très inattendue et désagréable.