In diesem Artikel werde ich meine Erfahrungen mit der WebRTC-Technologie und dem Kurento-Medienserver während der Test- und Implementierungsphase teilen. Ich erzähle Ihnen, auf welche Probleme ich gestoßen bin und wie ich sie gelöst habe. Ich werde nicht darüber sprechen, wie man eine Anwendung von Grund auf neu entwickelt, aber ich werde viele nützliche Links geben. Ich bin mir sicher, dass meine Geschichte für diejenigen nützlich sein wird, die mit WebRTC arbeiten werden.
Einleitung
Das Medical Information System (MIS), das von unserem Unternehmen entwickelt wird, ist bereits zu einem riesigen Unternehmensprojekt mit vielen Mikrodiensten, Messaging-Bussen, mobilen Kunden usw. gewachsen. Einige Teile des Systems müssen für die Entwicklung und Unterstützung von Drittanbieterorganisationen bereitgestellt werden, da sie nicht unser Profil sind.
Der Telemedizin-Dienst ist eines dieser MIS-Module. Es gab keine Erfahrung mit der Entwicklung von Videokonferenzen und der Verwendung von WebRTC, und der Auftrag wurde delegiert. Aufgrund verschiedener Umstände wurde die Unterstützung von Videokonferenzen nach einiger Zeit eingestellt. Ohne Unterstützung wurde dieser Dienst deaktiviert und sammelt Staub im Repository.
Und jetzt ist es Zeit, diesen Mikrodienst wiederzubeleben. Es wurde beschlossen, Telemedizin selbstständig neu zu starten. Unser Unternehmen ist gewachsen, es sind mehr Spezialisten hinzugekommen - es ist möglich und notwendig, neue Themen für die Entwicklung zu beherrschen. Ich war bisher noch nicht mit der Videoübertragung befasst, aber es war sehr interessant, eine so vielversprechende Technologie wie WebRTC zu verstehen und zu studieren.
Hier sind einige sehr nützliche Links zur WebRTC-Technologie und zum Kurento-Server, die mir am Anfang geholfen haben:
Erste Schritte
Die Aufgabe war einfach: Das vorhandene Videokonferenzsystem wiederherzustellen, eine Bestandsaufnahme der bereits durchgeführten Vorgänge zu erstellen und gegebenenfalls nach den Wünschen der Benutzer zu ändern. Die ersten Tests auf virtuellen Maschinen und realen Computern waren erfolgreich. Die Bereitstellung des Systems beim Kunden brachte jedoch große Probleme mit sich.
Ich möchte Sie daran erinnern, dass der Kunde bereits über ein medizinisches Informationssystem (MIS) verfügt, das eine Vielzahl von Aufgaben abdeckt: von der elektronischen Warteschlange über den Arbeitsplatz des Arztes, Dokumentenmanagement und PACS bis hin zum Teilsystem für das Management medizinischer Geräte.
Als es notwendig wurde, Videokonferenzfunktionen zu entwickeln, um medizinisches Personal von Diagnosezentren (im Folgenden als DC bezeichnet) mit entfernten Patienten zu verbinden, wurden zwei Voraussetzungen festgelegt:
Alle Konferenzen sollten aufgezeichnet und auf dem Server gespeichert werden.
Patienten sollten keine zusätzlichen Programme auf ihren Geräten installieren, mit Ausnahme des Browsers, der in den meisten Fällen bereits vorinstalliert ist.
WebRTC funktioniert über einen Browser ohne zusätzliche Programme oder Plugins. Und Kurento kann alles aufzeichnen, was es durchläuft. Außerdem verfügt dieser Medienserver über eine Reihe vorgefertigter Bibliotheken für die Arbeit mit seiner API über Java und JavaScript, was die Entwicklung erheblich vereinfacht.
Die Entwicklung des Serverteils bzw. dessen Basis, noch bevor ich mit der Aufgabe begonnen habe, wurde vom Kunden an ein Outsourcing-Unternehmen an ein Drittunternehmen übertragen. Es gab also einen "Managing Server" (CSS) - eine fertige Serverbasis, die ich zur Implementierung bekam.
Die allgemeine Idee der Interaktion sah anfangs so aus:
Im Laufe der weiteren Arbeit hat sich das gesamte System geändert und ist komplizierter geworden.
Erste Reanimationserfahrung
Nach dem Einsatz in einem Testnetzwerk auf virtuellen Maschinen und auf mehreren "Live" -Computern wurden viele Tests und Experimente durchgeführt - alles hat einwandfrei funktioniert. Dementsprechend ist es an der Zeit, sich in ein echtes, funktionierendes Netzwerk einzufügen.
Zum Testen wurde ein verantwortliches Opfer in Form eines Arztes und seines Arbeitsplatzes beauftragt, mir zu helfen. Und der zweite Anruf über den Telemedizin-Mikrodienst stürzte ab!
Es ist gut, dass dies während des Betatests passiert ist, und außer mir und einem Arzt, der mit den Abenteuern zufrieden war, hat dies niemand gesehen.
Was passiert und warum die Verbindung nicht hergestellt wird, war sehr schwer zu verstehen. WebRTC zeigt keinen Fehler an - es wartet nur auf das Erscheinen eines Signals. Das Debuggen war unwissentlich sehr schwierig: Der Serverteil funktioniert gut, Kurento schweigt in den Protokollen, Clients warten auf den Stream, aber es passiert nichts.
Habr half (Lob sei ihm):
Es ist bedauerlich, dass ich diese Werkzeuge vorher nicht gekannt habe.
Nach der Analyse der Protokolldaten und der Überwachung des Status der Verbindungen wurde klar, dass sowohl die serverseitigen als auch die Clientskripte nicht auf Ereignisse im WebRTC-System reagierten. Und wo bekommt man diese Events?
Die Entwickler des kurento-Servers stellen eine sehr praktische JavaScript-Bibliothek für die Arbeit mit WebRTC zur Verfügung: kurento-utils.js.
Um schnell zu beginnen, erstellen Sie einfach ein Objekt:
new kurentoUtils.WebRtcPeer.WebRtcPeerRecvonly(options, callback());
Um auf Ereignisse zugreifen zu können, müssen die internen Methoden der Bibliothek neu definiert werden. Ich habe den Code so weit wie möglich vereinfacht, um ihn klarer zu machen:
Apropos Zertifikate
Da es sich bei dem Artikel um meine Erfahrungen handelt, werde ich Informationen weitergeben, die moderne Browser in Bezug auf die Sicherheit sehr streng haben. Wenn die Ressource über ein selbstsigniertes Zertifikat verfügt, untersagt der Browser auch mit besonderer Erlaubnis den Zugriff auf Computerperipheriegeräte.
Sie können ein Zertifikat für kostenlose Ressourcen im Internet erstellen und ein lokales Netzwerk für dessen Verwendung konfigurieren oder Firefox ab Version 65 herunterladen. Klicken Sie in dieser Version einfach auf die Schaltfläche, die ich mit den Risiken von selbstsignierten Zertifikaten und dem Zugriff auf Kameras und Mikrofone einverstanden bin.
Dieser Weg schien mir einfacher.
Zweiter Test (schon vorsichtig)
Es schien mir, dass der Arzt Popcorn holen würde, wenn er mich beim nächsten Test sah. Er genoss es offensichtlich, mir beim Kampf mit moderner Technologie zuzusehen.
Tatsächlich war dieses Systemupdate keine Veröffentlichung, da ich nichts behoben habe und nicht einmal die Ursache der Probleme kannte. Ich wiederhole, dass im Büro alles perfekt funktioniert hat. Die Reaktionen auf alle Ereignisse, die von WebRTC und Kurento generiert wurden und nach denen ich griff, wurden dem Code hinzugefügt, und all dies wurde sehr detailliert in die Protokolle geschrieben. Ich habe meine Protokolle sogar in separaten Dateien abgelegt, damit sie nicht mit den Hauptprotokollen in der IIA verwechselt werden.
Zusammen mit einem begeisterten Arzt und Systemadministrator des Kunden haben wir das System ausprobiert. Sie haben nicht einmal getestet, nämlich "gefoltert". Wir haben Videokonferenzen in allen möglichen Modi und auf allen verfügbaren Geräten erstellt. Andere Ärzte und ein Teil des Personals der Außenstelle waren an diesem Spiel beteiligt.
Die Hauptsache war nicht, das System zu überprüfen (es hat nicht funktioniert), sondern so viele Daten wie möglich zu sammeln. Als Ergebnis stellte sich heraus, dass:
- Ungefähr 80% der Versuche, eine Videokonferenz zu erstellen, sind erfolgreich.
- Einige Verbindungen mit ICE-Kandidaten für IPv6 funktionieren nicht.
- Von 5 Mobilfunkbetreibern arbeiteten nur 2.
Es hat sich herausgestellt, dass alles einfach ist. Mit Google allein können Sie nicht weiterkommen
Die Analyse der gesammelten Informationen hat ergeben, dass die Verbindung über den TURN-Server von Google instabil ist. Entweder ist die Last auf ihnen groß, oder es ist nur ein Demo-Server für diejenigen, die gerade erst anfangen, die Technologie zu lernen. Fakt ist aber: sehr häufige Ausfälle. Benötigen Sie Ihren eigenen TURN / STUN-Server!
Der zweite Grund für die Fehler sind die IPv6.local-Adressen. Der kurento-Server akzeptiert keine ICE-Kandidaten mit diesen Adressen. Es ist gut, dass ich vor dem Versenden aller ICE-Kandidaten den Code in meinen Händen durchgesehen habe und nur IPv6.local herausgefiltert habe.
Mit seinem TURN / STUN-Server ist das Problem der Mobilfunkbetreiber wieder gelöst.
Bei drei von fünf Mobilfunkbetreibern ist NAT symmetrisch, und WebRTC kann nicht durchbrechen. Weitere Details finden Sie hier:
Ist Symmetric NAT schrecklich?Schade, dass mein persönliches Handy mit einer SIM-Karte eines Betreibers funktioniert, der sich nicht um symmetrischen Schutz gekümmert hat. Daher haben meine ersten Tests dieses Problem nicht aufgedeckt.
TURN / STUN-Server
Das Paket resiprocate-turn-server wurde als Server ausgewählt.
Sie haben sich lange Zeit nicht dafür entschieden - es befindet sich im Standard-Ubuntu-Repository - einfache Installation und automatische Updates. Es ist jedoch nicht sehr praktisch, mit Konten zu arbeiten, um eine Verbindung herzustellen: Anmeldungen und Kennwörter werden nur aus der Datei übernommen. Aus diesem Grund müssen Sie ein zusätzliches Dienstprogramm oder Skript erstellen, um sie aus der Datenbank des Hauptservers zu exportieren.
Momentan wird diese Datei von Hand generiert und die Konten werden über einen einfachen Kennwortpool verteilt. Die Autorisierung wird über den MIS-Hauptserver implementiert, sodass die Sicherheit nicht beeinträchtigt wird. Aber die Gesamtstruktur des gesamten Systems sieht hässlich aus. Die Pläne für diesen Moment neu zu machen.
Dritte Reise zum Kunden
Ich habe den Code korrigiert, meinen TURN / STUN-Server installiert und konfiguriert, einen Pool von Passwörtern erstellt und diese zu Beginn einer Videokonferenz an die Kunden verteilt. Nach der Aktualisierung der Produktionsserver bin ich zu einem Arzt gegangen, den ich bereits kannte.
Es funktioniert Hurra! Alle Konferenzstarts sind von allen Geräten und in allen Modi erfolgreich: Der Patient aus dem persönlichen Konto kann den Arzt anrufen, der Therapeut während des Empfangs kann den Funktionsdiagnostiker zur zusätzlichen Beratung anrufen, und die Ärzte können selbst eine Mehrbenutzer-Videokonferenz aus verschiedenen Filialen aus der ganzen Stadt arrangieren.
Bereits aus bitterer Erfahrung gelernt, haben wir akribische Tests mit der künstlichen Erzeugung von Notsituationen durchgeführt. Aus dem Thema dieses Artikels hebe ich die Notwendigkeit hervor, ein Limit für die Verbindungswartezeit festzulegen. WebRTC und Kurento warten darauf, dass die Übertragung unendlich lange dauert, und hoffen, dass die Videobytes bald verfügbar sind. Ich musste einen Timer für 10 Sekunden einstellen, der dem verwaltenden Server einen Fehler anzeigt, wenn die Bytes nie angekommen sind.
Nach all den Verbesserungen
Schließlich funktioniert das System und funktioniert gut. Die ersten Bewertungen wurden von Nutzern im Feld gesendet. Und sofort tauchten eine Vielzahl von Wünschen und Vorschlägen für Design, Zusatzfunktionen und sonstige Weiterentwicklungspläne auf. Die Arbeit begann mit neuer Kraft zu kochen!
Nun sieht die vollständige Systemtopologie folgendermaßen aus:
ERGEBNISSE:
Abschließend möchte ich Folgendes sagen:
Erstens ist WebRTC eine exzellente Technologie mit guten Aussichten, aber es ist sehr schwierig, sie zu testen und zu debuggen. Bevor Sie mit der Entwicklung beginnen, müssen Sie unbedingt ein Netzwerk mit allen Arten von Verbindungen bereitstellen, über die der Client möglicherweise verfügt. Das Debuggen über das Browser-Informationsfenster ist kein besonders praktisches Tool.
Zweitens, Lob an Habru! Während der Arbeit an diesem Projekt habe ich viele Informationen zu dieser Ressource gefunden. Alle Links in diesem Artikel führen dorthin.
Es wurde beschlossen, das Videokonferenzprojekt für Telemedizin für Support und Entwicklung in unserer Organisation zu belassen, wir werden es nicht auslagern. Auch in Zukunft gibt es noch viel Arbeit:
ALLES
Ich bin mir sicher, dass meine Erfahrung nicht nur für Entwickler unter WebRTC + Kurento von Nutzen sein wird, sondern auch für diejenigen, die gleichermaßen komplexe Projekte umsetzen werden. Achten Sie mehr auf Tests unter Bedingungen, die der Realität möglichst nahe kommen.
Berücksichtigen Sie auch das Risiko, dass die Support-Teams für Ihre Microservices plötzlich „verschwinden“ - eine sehr unerwartete und unangenehme Aufgabe.