Von Skype bis WebRTC: Wie wir die Videokommunikation über das Web organisiert haben

Videotelefonie ist die Hauptkommunikationsmethode zwischen Lehrern und Schülern auf der Plattform Vimbox. Wir haben Skype schon lange aufgegeben, verschiedene externe Lösungen ausprobiert und schließlich auf die Kombination WebRTC – Janus-Gateway umgestellt. Eine Zeit lang waren wir damit zufrieden, doch einige negative Aspekte traten weiterhin auf. Letztendlich wurde ein eigenes Video-Team gegründet.

Ich habe Kirill Rogovoy, den Leiter des neuen Teams, gebeten, über die Entwicklung der Videotelefonie bei Skyeng, die aufgetretenen Probleme, Lösungen und Hacks, die wir letztendlich angewendet haben, zu berichten. Wir hoffen, dass der Artikel für Unternehmen, die ebenfalls Videos über Webanwendungen erstellen, nützlich sein wird.

Ein wenig Geschichte

Im Sommer 2017 hielt der Leiter der Entwicklung von Skyeng, Sergej Safonov, einen Vortrag auf der Backend Conf, in dem er erklärte, wie wir "Skype aufgegeben und WebRTC implementiert haben". Interessierte können sich die Aufzeichnung des Vortrags hier ansehen dem Link (~45 Minuten), und hier fasse ich das Wesentliche kurz zusammen.

Für die Schule Skyeng war Videotelefonie schon immer die bevorzugte Kommunikationsmethode zwischen Lehrer und Schüler. Zunächst wurde "Skype" verwendet, aber es war aus zahlreichen Gründen völlig unzureichend, vor allem wegen des Fehlens von Protokollen und der Unmöglichkeit der Integration direkt in die Webanwendung. Deshalb führten wir verschiedene Experimente durch.

Unsere Anforderungen an die Videotelefonie waren ungefähr die folgenden:
— Stabilität;
— niedrige Kosten pro Unterrichtseinheit;
— Aufzeichnung von Unterrichtseinheiten;
— Überwachung, wer wie viel spricht (uns ist wichtig, dass die Schüler im Unterricht mehr sprechen als der Lehrer);
— lineare Skalierbarkeit;
— die Möglichkeit, sowohl UDP als auch TCP zu verwenden.

Zuerst haben wir 2013 versucht, Tokbox einzuführen. Alles war gut, aber es war sehr teuer – 113 Rubel pro Unterrichtseinheit – und fraß die Gewinne auf.

Dann haben wir 2015 Voximplant integriert. Hier gab es die für uns benötigte Funktion zur Überwachung, wer wie viel spricht, und gleichzeitig war die Lösung deutlich günstiger: Bei einer reinen Audioaufzeichnung kostete es 20 Rubel pro Unterrichtseinheit. Es funktionierte jedoch nur über UDP, ein Wechsel zu TCP war nicht möglich. Trotzdem nutzten schließlich etwa 40 % der Schüler diese Lösung.

Nach einem Jahr begannen wir, Unternehmensclients mit ihren spezifischen Anforderungen zu gewinnen. Zum Beispiel muss alles über den Browser funktionieren, in der Firma sind nur http und https offen; d.h. keine „Skypes“ und kein UDP. Unternehmensclients = Geld, also kehrten wir zu Tokbox zurück, aber das Preisproblem blieb bestehen.

Die Lösung – WebRTC und Janus

Wir haben beschlossen, eine browserbasierte Plattform für die Peer-to-Peer-Videokommunikation WebRTC. Sie ist verantwortlich für die Verbindungsherstellung, die Kodierung und Dekodierung der Streams, die Synchronisierung der Spuren und die Qualitätskontrolle mit der Verarbeitung von Netzwerkproblemen. Von unserer Seite aus müssen wir das Lesen der Streams von der Kamera und dem Mikrofon, die Videoanzeige, die Verbindungskontrolle, die Einrichtung der WebRTC-Verbindung und die Übertragung der Streams an sie sowie die Übertragung von Signalisierungsnachrichten zwischen den Clients zur Verbindungsherstellung sicherstellen (WebRTC beschreibt nur das Datenformat, nicht aber den Übertragungsmechanismus). Falls die Clients hinter einem NAT sind, verbindet WebRTC STUN-Server, falls das nicht hilft, TURN-Server.

Eine normale p2p-Verbindung genügt uns nicht, da wir Lektionen zum späteren Analysieren im Falle von Beschwerden aufzeichnen möchten. Daher senden wir die WebRTC-Streams über einen Relais Janus Gateway von Meetecho. Dadurch wissen die Clients nicht, wo sich die anderen befinden, und sehen nur die Adresse des Janus-Servers; dieser erfüllt auch die Funktionen des Signalisierungsservers. Janus hat viele nützliche Funktionen für uns: Er wechselt automatisch zu TCP, wenn der Client UDP blockiert; kann sowohl UDP- als auch TCP-Streams aufzeichnen; ist skalierbar; hat sogar ein integriertes Plugin für Echotests. Bei Bedarf werden automatisch STUN- und TURN-Server von Twilio angeschlossen.

Im Sommer 2017 hatten wir zwei Janus-Server und einen zusätzlichen Server zur Verarbeitung der aufgezeichneten Rohdateien für Audio und Video, um die Hauptprozessoren nicht zu belasten. Bei der Verbindung wurden die Janus-Server nach dem Prinzip gerade-ungerade (Verbindungsnummer) ausgewählt. Zu diesem Zeitpunkt reichte das aus, es gab nach unserem Gefühl etwa eine vierfache Redundanz, die Implementierungsquote lag bei etwa 80. Dabei fiel der Preis auf ~2 Rubel pro Stunde, plus Entwicklung und Support.

Rückkehr zum Thema Videokommunikation

Wir überwachen ständig das Feedback von Schülern und Lehrern, um Probleme rechtzeitig zu erkennen und zu beheben. Im Sommer 2018 war die Qualität der Verbindung bei den Beschwerden ganz oben auf der Liste. Einerseits bedeutete das, dass wir andere Mängel erfolgreich behoben hatten. Andererseits mussten wir dringend etwas unternehmen: Bei einer Störung des Unterrichts riskieren wir, dessen Wert zu verlieren, manchmal zusammen mit dem Wert des Kaufs des nächsten Pakets, und bei einer Störung der Einführungssitzung – sogar potenzielle Kunden zu verlieren.

Zu diesem Zeitpunkt befand sich die Videoverbindung bei uns immer noch im MVP-Modus. Einfach gesagt, wir haben es gestartet, es funktionierte, einmal skaliert, wussten wir, wie es geht – das war es. If it works, don’t fix it. Niemand beschäftigte sich gezielt mit der Qualität der Verbindung. Im August wurde klar, dass es so nicht weitergehen konnte, und wir starteten eine separate Abteilung, um herauszufinden, was genau bei uns mit WebRTC und Janus nicht stimmte.

Diese Abteilung erhielt: Lösung MVP, keine Metriken, keine Ziele, keine Verbesserungsprozesse, während 7 % der Lehrer sich über die Qualität der Verbindung beschweren (Daten über die Schüler lagen ebenfalls nicht vor).

Die neue Abteilung nimmt die Arbeit auf

Das Team sieht ungefähr so aus:

• Abteilungsleiter, auch Hauptentwickler.
• QA hilft bei der Testung von Änderungen, sucht nach neuen Möglichkeiten zur Schaffung instabiler Verbindungsbedingungen und berichtet über Probleme aus der Front.
• Der Analyst sucht ständig nach verschiedenen Korrelationen in den technischen Daten, optimiert die Analyse des Benutzerfeedbacks und überprüft die Ergebnisse von Experimenten.
• Der Produktmanager hilft bei der allgemeinen Ausrichtung und der Bereitstellung von Ressourcen für Experimente.
• Bei der Programmierung und verwandten Aufgaben wird oft von einem zweiten Entwickler Unterstützung geleistet.

Zuerst haben wir eine bis dahin relativ zuverlässige Metrik eingerichtet, die die Veränderungen der Bewertung der Verbindungsqualität verfolgte (Durchschnitt über Tage, Wochen, Monate). Zu diesem Zeitpunkt handelte es sich um Bewertungen von Lehrern, denen später auch Bewertungen von Studenten hinzugefügt wurden. Danach begannen wir, Hypothesen über die Probleme aufzustellen, sie zu beheben und die Änderungen in der Dynamik zu beobachten. Wir gingen die einfacheren Probleme an: zum Beispiel wechselten wir den Codec von vp8 auf vp9, die Werte verbesserten sich. Wir haben versucht, mit den Einstellungen von Janus zu experimentieren und andere Experimente durchzuführen – in den meisten Fällen ohne Erfolg.

In der zweiten Phase entstand die Hypothese: WebRTC ist eine Peer-to-Peer-Lösung, und wir verwenden serielle Server. Könnte das Problem hier liegen? Wir begannen zu graben und fanden bisher die signifikanteste Verbesserung.

In diesem Moment wurde der Server aus dem Pool nach einem ziemlich simplen Algorithmus ausgewählt: Jeder hatte sein eigenes „Gewicht“, das von der Verbindung und der Leistung abhing, und wir versuchten, den Benutzer zu dem mit dem höheren „Gewicht“ zu leiten, ohne darauf zu achten, wo der Benutzer geografisch war. Infolgedessen konnte ein Lehrer aus St. Petersburg mit einem Schüler aus Sibirien über Moskau kommunizieren, anstatt über unseren Janus-Server in St. Petersburg.

Der Algorithmus wurde überarbeitet: Jetzt, wenn ein Benutzer unsere Plattform öffnet, sammeln wir mit Ajax die Ping-Zeiten zu allen Servern. Bei der Verbindungsherstellung wählen wir ein Ping-Paar (Lehrer-Server und Schüler-Server) mit der niedrigsten Summe aus. Ein niedrigerer Ping bedeutet eine geringere Netzwerklatenz zum Server; kürzere Distanzen führen zu einer geringeren Wahrscheinlichkeit von Packetverlusten; Packetverluste sind der größte negative Faktor in der Videoverbindung. Der Anteil an Problemen ist in drei Monaten auf die Hälfte gesunken (fairerweise sei erwähnt, dass in dieser Zeit auch andere Experimente durchgeführt wurden, aber dieses hatte höchstwahrscheinlich den größten Einfluss).

Kürzlich haben wir noch eine nicht offensichtliche, aber anscheinend wichtige Erkenntnis gewonnen: Anstelle eines leistungsstarken Janus-Servers auf einer dicken Leitung sind besser zwei einfachere mit einer niedrigeren Bandbreite. Das zeigte sich, nachdem wir genau leistungsstarke Maschinen gekauft hatten, in der Hoffnung, dort so viele Räume (Verbindungssitzungen) wie möglich gleichzeitig unterzubringen. Server haben ein Bandbreitenlimit, das wir genau in die Anzahl der Räume umrechnen können – wir wissen, wie viele wir beispielsweise bei 300 Mbit/s öffnen können. Sobald auf dem Server zu viele Räume geöffnet sind, hören wir auf, ihn für neue Sitzungen auszuwählen, bis die Auslastung sinkt. Die Idee war, dass wir durch den Kauf einer leistungsstarken Maschine den Kanal so weit wie möglich auslasten, um letztendlich auf den Prozessor und den Speicher zu stoßen, nicht auf die Bandbreite. Aber es stellte sich heraus, dass nach einer bestimmten Anzahl geöffneter Räume (420) trotz der Tatsache, dass die Auslastung von Prozessor, Speicher und Festplatte noch weit von den Grenzen entfernt war, negative Rückmeldungen beim Support eintrafen. Offensichtlich wird irgendetwas innerhalb von Janus schlechter, möglicherweise gibt es auch dort irgendwelche Einschränkungen. Wir begannen zu experimentieren, reduzierten das Bandbreitenlimit von 300 auf 200 Mbit/s, die Probleme verschwanden. Jetzt haben wir sofort drei neue Server mit niedrigeren Limits und Spezifikationen gekauft und denken, dass dies zu einer stabilen Verbesserung der Verbindungsqualität führen wird. Warum das so war, haben wir natürlich nicht weiter untersucht, Notlösungen sind unser Alles. Zur Verteidigung sagen wir, dass wir zu diesem Zeitpunkt das dringende Problem so schnell wie möglich lösen mussten, nicht hübsch, zumal Janus für uns eine Black Box ist, die in C geschrieben wurde, und es sehr teuer wäre, sich damit zu beschäftigen.

Nun haben wir im Prozess:

• alle Abhängigkeiten aktualisiert, die sowohl auf dem Server als auch auf dem Client aktualisiert werden konnten (das waren auch Experimente, wir haben die Ergebnisse im Auge behalten);
• alle identifizierten Bugs behoben, die spezifische Fälle betrafen, z. B. wenn die Verbindung abbrach und sich nicht automatisch wiederherstellte;
• eine Vielzahl von Treffen mit Unternehmen durchgeführt, die im Bereich Videokonferenzen arbeiten und mit unseren Problemen vertraut sind: Spiele-Streamer, Webinar-Organisatoren; alles ausprobiert, was uns nützlich erschien;
• eine technische Überprüfung der Hardware und der Verbindungsqualität bei den Lehrern durchgeführt, von denen die meisten Beschwerden kamen.

Durchgeführte Experimente und die darauf folgenden Änderungen ermöglichten es, die Unzufriedenheit mit der Verbindung unter den Lehrern von 7,1 % im Januar 2018 auf 2,5 % im Januar 2019 zu senken.

Was kommt als nächstes

Die Stabilisierung unserer Plattform Vimbox ist eines der Hauptprojekte des Unternehmens für das Jahr 2019. Wir haben große Hoffnungen, dass es uns gelingt, das Tempo beizubehalten und die Videoanrufe nicht mehr an der Spitze der Beschwerden zu sehen. Wir verstehen, dass ein erheblicher Teil dieser Beschwerden mit den Lags der Computer und Internetverbindungen der Benutzer zusammenhängt, aber wir müssen diesen Teil identifizieren und alles andere lösen. Alles andere ist ein technisches Problem, wir sollten in der Lage sein, damit umzugehen.

Die Hauptschwierigkeit besteht darin, dass wir nicht wissen, bis zu welchem Niveau die Qualität tatsächlich erhöht werden kann. Herauszufinden, wo die Obergrenze liegt, ist die Hauptaufgabe. Daher wurden zwei Experimente geplant:

1. der Vergleich von Video über Janus mit herkömmlichem P2P unter realen Bedingungen. Dieses Experiment wurde bereits durchgeführt, und es wurde kein statistisch signifikanter Unterschied zwischen unserer Lösung und P2P festgestellt;
2. wir setzen (teure) Dienste von Unternehmen ein, die ausschließlich mit Lösungen im Bereich der Videokommunikation verdienen, und vergleichen die Anzahl der negativen Rückmeldungen von ihnen mit den bestehenden.

Diese beiden Experimente werden es uns ermöglichen, ein erreichbares Ziel festzulegen und uns darauf zu konzentrieren.

Darüber hinaus gibt es eine Reihe von Aufgaben, die im Rahmen des Arbeitsprozesses gelöst werden:

• wir erstellen eine technische Metrik für die Verbindungsqualität statt subjektiver Rückmeldungen;
• wir machen detailliertere Protokolle der Sitzungen, um die aufgetretenen Ausfälle genauer zu analysieren, zu verstehen, wann und wo genau sie aufgetreten sind, sowie um zu erkennen, welche anscheinend nicht zusammenhängenden Ereignisse zu diesem Zeitpunkt stattgefunden haben;
• wir bereiten einen automatisierten Test der Verbindungsqualität vor dem Unterricht vor und geben dem Kunden auch die Möglichkeit, die Verbindung manuell zu testen, um die Anzahl der negativen Rückmeldungen, die durch seine Hardware und Verbindung verursacht werden, zu reduzieren;
• wir werden mehr Lasttests der Videokommunikation unter schlechten Bedingungen mit variabler Paketverlustrate usw. durchführen;
• wir ändern das Verhalten der Server im Falle von Problemen zur Erhöhung der Ausfallsicherheit;
• wir werden den Benutzer warnen, wenn er Probleme mit der Verbindung hat, wie es auch Skype tut, damit er versteht, dass das Problem auf seiner Seite liegt.

Ab April wird die Videoverbindung zu einem eigenständigen, vollwertigen Projekt innerhalb von Skyeng, das ein eigenes Produkt entwickelt, nicht nur ein Teil von Vimbox. Das bedeutet, dass wir beginnen, nach Leuten zu suchen für die Arbeit mit Video in Vollzeit. Wie immer suchen wir viele gute Leute.

Und natürlich kommunizieren wir weiterhin aktiv mit Menschen und Unternehmen, die im Bereich Videokonferenz tätig sind. Wenn Sie Erfahrung mit uns austauschen möchten – wir freuen uns! Kommentieren Sie, setzen Sie sich in Verbindung – wir beantworten alle.

Quelle: habr.com