Videoanrufe sind die Hauptmethode für die Kommunikation von Lehrern und Schülern auf der Vimbox-Plattform. Wir haben Skype vor langer Zeit aufgegeben, verschiedene Lösungen von Drittanbietern ausprobiert und uns schließlich für eine Reihe von WebRTC-Janus-Gateways entschieden. Für eine Weile war alles in Ordnung mit uns, aber es schlichen sich immer noch einige negative Punkte heraus. Als Ergebnis wurde eine separate Videorichtung erstellt.
Ich bat Kirill Rogovoy, den Leiter der neuen Richtung, über die Entwicklung der Videokommunikation in Skyeng, die Probleme, Lösungen und Krücken zu sprechen, die wir schließlich angewendet haben. Wir hoffen, dass dieser Artikel für Unternehmen nützlich ist, die über eine Webanwendung auch selbst Videos erstellen.
Ein bisschen Geschichte
Im Sommer 2017 sprach Sergey Safonov, Leiter der Skyeng-Entwicklung, bei Backend Conf darüber, wie wir „Skype aufgegeben und WebRTC implementiert haben“. Diejenigen, die dies wünschen, können die Aufzeichnung der Aufführung anhand einer Referenz (~ 45 Minuten) sehen, aber hier werde ich kurz auf ihre Essenz eingehen.
Für Skyeng war Videokommunikation schon immer eine vorrangige Kommunikationsmethode zwischen Lehrern und Schülern. Anfangs wurde Skype verwendet, aber es war aus einer Reihe von Gründen kategorisch nicht geeignet, hauptsächlich aufgrund des Fehlens von Protokollen und der Unfähigkeit, sich direkt in die Webanwendung zu integrieren. Deshalb haben wir alle Arten von Experimenten durchgeführt.
Tatsächlich waren die Anforderungen an die Videokommunikation ungefähr folgende:
- Stabilität;
- niedriger Preis pro Lektion;
- Unterrichtsstunden aufnehmen;
- Verfolgen, wer wie viel sagt (es ist wichtig für uns, dass die Schüler im Klassenzimmer mehr sprechen als der Lehrer);
- lineare Skalierung;
- Die Fähigkeit, sowohl UDP als auch TCP zu verwenden.
Der erste im Jahr 2013 versuchte, Tokbox zu implementieren. Alles war in Ordnung, aber es stellte sich als sehr teuer heraus - 113 Rubel pro Lektion - und aß den Gewinn.
Dann wurde 2015 Voximplant integriert. Hier war die Tracking-Funktion, die wir brauchten, wer sagt, wie viel, und gleichzeitig war die Lösung viel billiger: Wenn nur Ton aufgenommen wurde, kamen 20 Rubel pro Lektion heraus. Es funktionierte jedoch nur über UDP, der Wechsel zu TCP war keine Fähigkeit. Am Ende nutzten es jedoch etwa 40% der Studenten.
Ein Jahr später tauchten Firmenkunden mit ihren spezifischen Anforderungen auf. Zum Beispiel sollte alles über einen Browser funktionieren, nur http und https sind im Unternehmen geöffnet. Das heißt, kein Skype und UDP. Firmenkunden = Geld, also kehrten sie zu Tokbox zurück, aber das Preisproblem ist nicht verschwunden.
Lösung - WebRTC und Janus
Wir haben uns entschieden, die Browserplattform für die Peer-to-Peer-Videokommunikation WebRTC zu verwenden . Sie ist verantwortlich für das Herstellen von Verbindungen, das Codieren und Decodieren von Streams, das Synchronisieren von Tracks und die Qualitätskontrolle mit der Verarbeitung von Netzwerkfehlern. Unsererseits müssen wir sicherstellen, dass die Streams von Kamera und Mikrofon gelesen, das Video gezeichnet, die Verbindung hergestellt, die WebRTC-Verbindung hergestellt und die Streams an sie übertragen werden sowie die Übertragung von Signalnachrichten zwischen Clients, um die Verbindung herzustellen (WebRTC selbst beschreibt nur das Datenformat, nicht jedoch deren Mechanismus Übertragung). Wenn sich die Clients hinter NAT befinden, verbindet WebRTC die STUN-Server. Wenn dies nicht hilft, die TURN-Server.
Die übliche P2P-Verbindung reicht uns nicht aus, da wir bei Beschwerden Lektionen zur weiteren Analyse aufzeichnen möchten. Daher senden wir WebRTC-Streams über den Janus Gateway-Repeater von Meetecho . Infolgedessen kennen die Clients die Adressen der anderen nicht und sehen nur die Adresse des Janus-Servers. Es führt auch die Funktionen eines Signalservers aus. Janus hat viele Funktionen, die wir benötigen: Es wechselt automatisch zu TCP, wenn UDP auf dem Client blockiert ist. in der Lage, Streams von UDP und TCP aufzuzeichnen; skalierbar; Es gibt sogar ein eingebautes Plugin für Echotests. Bei Bedarf werden die STUN- und TURN-Server von Twilio automatisch verbunden.
Im Sommer 2017 hatten wir zwei Janus-Server sowie einen zusätzlichen Server für die Verarbeitung aufgezeichneter Audio- und Videodateien, um die Hauptprozessoren nicht zu belegen. Bei der Verbindung wurden Janus-Server gerade und ungerade ausgewählt (Verbindungsnummer). Zu dieser Zeit war dies genug, nach unseren Einschätzungen gab es ungefähr das Vierfache der Sicherheitsmarge, der Prozentsatz der Implementierung betrug ungefähr 80. Gleichzeitig fiel der Preis auf ~ 2 Rubel pro Lektion plus Entwicklung und Support.
Kehren Sie zum Thema Videoanrufe zurück
Wir überwachen ständig das Feedback von Schülern und Lehrern, um Probleme rechtzeitig zu erkennen und zu stoppen. Bis zum Sommer 2018 war die Qualität der Kommunikation in erster Linie unter den Beschwerden zuversichtlich verankert. Dies bedeutete zum einen, dass wir uns erfolgreich mit anderen Mängeln befasst hatten. Auf der anderen Seite bestand ein dringender Bedarf, etwas zu tun: Wenn die Lektion unterbrochen wird, riskieren wir, ihre Kosten zu verlieren, manchmal zusammen mit den Kosten für den Kauf des nächsten Pakets, und wenn die Einführungsstunde verloren geht, verlieren wir den potenziellen Kunden insgesamt.
Zu diesem Zeitpunkt befand sich die Videokommunikation noch im MVP-Modus. Einfach ausgedrückt, sie haben es gestartet, es hat funktioniert, einmal skaliert und herausgefunden, wie es geht - nun, das ist schön. Wenn es funktioniert, beheben Sie es nicht. Niemand hat sich bewusst mit dem Thema Kommunikationsqualität befasst. Im August wurde klar, dass dies nicht weitergehen konnte, und wir haben einen separaten Bereich eingerichtet, um herauszufinden, was mit WebRTC und Janus los war.
Bei der Eingabe erhielt diese Richtung: MVP-Lösung, keine Metriken, keine Ziele, keine Verbesserungsprozesse, während 7% der Lehrer sich über die Qualität der Kommunikation beschweren (es gab auch keine Daten zu den Schülern).
Für die Arbeit wird eine neue Richtung eingeschlagen
Der Befehl sieht ungefähr so aus:
- Der Leiter der Regie ist der Hauptentwickler.
- QS hilft beim Testen von Änderungen, sucht nach neuen Wegen, um instabile Kommunikationsbedingungen zu schaffen, und meldet Probleme von der Front.
- Der Analyst sucht ständig nach unterschiedlichen Korrelationen in den technischen Daten, verbessert die Analyse des Benutzerfeedbacks und überprüft die Ergebnisse von Experimenten.
- Der Produktmanager hilft bei der allgemeinen Ausrichtung und Zuweisung von Ressourcen für Experimente.
- Bei der Programmierung selbst und verwandten Aufgaben hilft oft ein zweiter Entwickler.
Zunächst haben wir eine relativ zuverlässige Metrik erstellt, die Änderungen bei der Bewertung der Kommunikationsqualität (Durchschnitt nach Tagen, Wochen, Monaten) verfolgt. Zu dieser Zeit waren dies Noten von Lehrern, und weitere Noten von Schülern wurden hinzugefügt. Dann begannen sie, Hypothesen darüber aufzustellen, was nicht funktioniert, um Änderungen in der Dynamik zu korrigieren und zu untersuchen. Wir haben uns für niedrig hängende Früchte entschieden: Zum Beispiel haben wir den vp8-Codec durch vp9 ersetzt, die Leistung hat sich verbessert. Wir haben versucht, mit den Janus-Einstellungen zu spielen, andere Experimente durchzuführen - in den meisten Fällen ohne Erfolg.
In der zweiten Phase tauchte eine Hypothese auf: WebRTC ist eine Peer-to-Peer-Lösung, und wir verwenden den Server in der Mitte. Vielleicht liegt das Problem hier? Sie begannen zu graben und fanden hier die bisher bedeutendste Verbesserung.
In diesem Moment wurde der Server aus dem Pool nach einem ziemlich dummen Algorithmus ausgewählt: Jeder hatte sein eigenes "Gewicht", abhängig von Kanal und Leistung, und wir versuchten, den Benutzer zu dem zu senden, bei dem das "Gewicht" größer ist, ohne darauf zu achten, wo sich der Benutzer geografisch befindet . Infolgedessen konnte ein Lehrer aus St. Petersburg mit einem Schüler aus Sibirien über Moskau und nicht über unseren Janus-Server in St. Petersburg kommunizieren.
Der Algorithmus wurde überarbeitet: Wenn der Benutzer unsere Plattform öffnet, verwenden wir Ajax, um Pings von ihm an alle Server zu sammeln. Beim Herstellen einer Verbindung wählen wir ein Paar Pings (Lehrer-Server und Schüler-Server) mit der geringsten Anzahl aus. Weniger Ping - weniger Netzwerkentfernung zum Server; weniger Entfernung - weniger Chance, Pakete zu verlieren; Paketverlust ist der größte negative Faktor bei Videoanrufen. Der Anteil der Negativität ging innerhalb von drei Monaten zweimal zurück (fairerweise wurden zu diesem Zeitpunkt auch andere Experimente durchgeführt, von denen dieses jedoch mit ziemlicher Sicherheit am meisten betroffen war).
Kürzlich haben wir eine andere nicht offensichtliche, aber anscheinend wichtige Sache entdeckt: Anstelle eines leistungsstarken Janus-Servers auf einem dicken Kanal sind zwei einfacher mit einer Bandbreite von besser. Dies stellte sich heraus, nachdem wir leistungsstarke Maschinen gekauft hatten, in der Hoffnung, dort so viele Räume (Kommunikationssitzungen) wie möglich gleichzeitig zu füllen. Server haben eine Bandbreitenbeschränkung, die wir genau in die Anzahl der Räume umwandeln können. Wir wissen, wie viel Sie beispielsweise mit 300 Mbit / s öffnen können. Sobald zu viele Räume auf dem Server geöffnet sind, stellen wir die Auswahl für neue Aktivitäten ein, bis die Last abnimmt. Die Idee war, dass wir nach dem Kauf einer leistungsstarken Maschine den Kanal maximal laden, sodass er am Ende auf dem Prozessor und dem Speicher und nicht auf der Bandbreite ruht. Es stellte sich jedoch heraus, dass nach einer bestimmten Anzahl offener Räume (420) trotz der Tatsache, dass die Belastung des Prozessors, des Speichers und der Festplatte immer noch sehr weit von den Grenzen entfernt ist, die Negativität in den technischen Support übergeht. Anscheinend wird in Janus etwas schlimmer, vielleicht gibt es auch einige Einschränkungen. Sie begannen zu experimentieren, reduzierten die Bandbreitenbeschränkung von 300 auf 200 Mbit / s, die Probleme waren weg. Jetzt haben wir drei neue Server mit niedrigen Grenzwerten und Eigenschaften gleichzeitig gekauft. Wir glauben, dass dies zu einer stabilen Verbesserung der Kommunikationsqualität führen wird. Natürlich haben wir nicht angefangen herauszufinden, was dort los war, Krücken gehörten uns. Zu unserer Verteidigung sagen wir, dass es in diesem Moment notwendig war, das dringende Problem so schnell wie möglich zu lösen und es nicht schön zu machen; Außerdem ist Janus für uns eine Black Box, geschrieben in C, es ist sehr teuer, sich damit zu beschäftigen.
Nun, dabei haben wir:
- aktualisierte alle Abhängigkeiten, die sowohl auf dem Server als auch auf dem Client aktualisiert werden konnten (dies waren auch Experimente, gefolgt vom Ergebnis);
- Alle identifizierten Fehler in bestimmten Fällen wurden behoben, z. B. wenn die Verbindung unterbrochen und nicht automatisch wiederhergestellt wurde.
- hatte viele Treffen mit Unternehmen, die auf dem Gebiet der Videokommunikation tätig waren und mit unseren Problemen vertraut waren: Streaming-Spiele, Host-Webinare; testete alles, was uns nützlich erschien;
- führte eine technische Überprüfung des Eisens und der Qualität der Kommunikation mit den Lehrern durch, aus der die meisten Beschwerden hervorgingen.
Die Experimente und die nachfolgenden Änderungen ermöglichten es, die Unzufriedenheit mit der Kommunikation zwischen Lehrern von 7,1% im Januar 2018 auf 2,5% im Januar 2019 zu verringern.
Was weiter
Die Stabilisierung unserer Vimbox-Plattform ist eines der Hauptprojekte des Unternehmens für 2019. Wir haben große Hoffnungen, dass wir die Dynamik beibehalten und die Videokommunikation nicht mehr in den Hauptbeschwerden sehen können. Wir verstehen, dass ein erheblicher Teil dieser Beschwerden mit den Verzögerungen von Computern und dem Internet der Benutzer zusammenhängt, aber wir müssen diesen Teil bestimmen und alles andere lösen. Alles andere ist ein technisches Problem, es scheint, dass wir in der Lage sein sollten, damit umzugehen.
Die Hauptschwierigkeit besteht darin, dass wir nicht wissen, auf welchem Niveau es im Allgemeinen realistisch ist, die Qualität zu verbessern. Die Klärung dieser Obergrenze ist die Hauptaufgabe. Daher waren zwei Experimente geplant:
- Vergleichen Sie das Video über Janus mit dem regulären P2P im Kampf. Dieses Experiment wurde bereits durchgeführt, es wurde kein statistisch signifikanter Unterschied zwischen unserer Lösung und p2p gefunden;
- Wir werden (teure) Dienstleistungen von Unternehmen erbringen, die ausschließlich mit Videokommunikationslösungen verdienen, und die Anzahl der negativen von ihnen mit der bestehenden vergleichen.
Diese beiden Experimente ermöglichen es uns, ein erreichbares Ziel zu bestimmen und uns darauf zu konzentrieren.
Darüber hinaus gibt es eine Reihe von Aufgaben, die in der Arbeitsreihenfolge gelöst sind:
- Wir erstellen eine technische Metrik der Kommunikationsqualität anstelle subjektiver Überprüfungen.
- Wir erstellen detailliertere Sitzungsprotokolle, um die auftretenden Fehler genauer zu analysieren und zu verstehen, wann und wo genau sie aufgetreten sind und welche scheinbar nicht zusammenhängenden Ereignisse zu diesem Zeitpunkt stattgefunden haben.
- Wir bereiten vor dem Unterricht einen automatischen Test der Kommunikationsqualität vor und ermöglichen es dem Kunden, die Verbindung manuell zu testen, um die durch sein Eisen und seinen Kanal verursachte negative Menge zu reduzieren.
- Wir werden mehr Stresstests für die Videokommunikation unter schlechten Bedingungen mit variablem Paketverlust usw. Entwickeln und durchführen.
- Wir ändern das Verhalten von Servern bei Problemen, um die Fehlertoleranz zu erhöhen.
- Wir werden den Benutzer warnen, wenn mit der Verbindung etwas nicht stimmt, wie dies auch bei Skype der Fall ist, damit er versteht, dass das Problem auf seiner Seite liegt.
Seit April ist die Videokommunikationsrichtung ein eigenständiges Projekt innerhalb von Skyeng, das sich nicht nur mit Vimbox, sondern mit einem eigenen Produkt beschäftigt. Und das bedeutet, dass wir anfangen, nach Leuten zu suchen, die im Vollzeitmodus mit Videos arbeiten können . Nun, wie immer suchen wir viele gute Leute .
Natürlich kommunizieren wir weiterhin aktiv mit Menschen und Unternehmen, die mit Videokommunikation arbeiten. Wenn Sie Erfahrungen mit uns austauschen möchten, freuen wir uns! Kommentar, Kontakt - wir werden allen antworten.