{"id":30842,"date":"2019-10-31T21:37:44","date_gmt":"2019-10-31T18:37:44","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ot-skype-do-webrtc-kak-my-organizovali-videosvyaz-cherez-veb\/"},"modified":"2021-02-01T11:37:06","modified_gmt":"2021-02-01T09:37:06","slug":"ot-skype-do-webrtc-kak-my-organizovali-videosvyaz-cherez-veb","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/ot-skype-do-webrtc-kak-my-organizovali-videosvyaz-cherez-veb","title":{"rendered":"Von Skype zu WebRTC: So haben wir die Videokommunikation \u00fcber das Web organisiert","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Von<\/p>\n

Videokommunikation ist der Hauptweg der Interaktion zwischen Lehrenden und Studierenden auf der Plattform Vimbox. Wir haben Skype bereits vor einiger Zeit aufgegeben, diverse Drittanbieter-L\u00f6sungen getestet und schlie\u00dflich auf die Kombination WebRTC \u2013 Janus-Gateway gesetzt. Eine Zeit lang waren wir mit dieser L\u00f6sung zufrieden, doch einige negative Aspekte traten weiterhin auf. Daher wurde ein eigenes Team f\u00fcr Videotechnologie ins Leben gerufen.<\/p>\n

Ich habe Kirill Rogovoy, den Leiter dieses neuen Teams, gebeten, \u00fcber die Entwicklung der Videokommunikation bei Skyeng, die entdeckten Probleme, L\u00f6sungen und die Umgehungen zu berichten, die wir letztendlich eingesetzt haben. Wir hoffen, dass dieser Artikel f\u00fcr Unternehmen, die ebenfalls Videokommunikation \u00fcber Webanwendungen implementieren, von Nutzen sein wird.<\/p>\n

<\/a><\/noindex><\/p>\n

Ein wenig Geschichte<\/h2>\n

Im Sommer 2017 hielt der Entwicklungsleiter von Skyeng, Sergey Safonov, einen Vortrag auf der Backend Conf, in dem er erl\u00e4uterte, wie wir \"Skype aufgegeben und WebRTC implementiert haben\". Interessierte k\u00f6nnen sich die Aufzeichnung des Vortrags untersehen \u00fcber diesen Link verf\u00fcgbar<\/a><\/noindex> (ca. 45 Minuten), und hier fasse ich die wesentlichen Punkte zusammen.<\/p>\n

F\u00fcr die Skyeng-Schule war Videoverbindung schon immer die bevorzugte Kommunikationsmethode zwischen Lehrer und Sch\u00fcler. Anfangs nutzten wir Skype, aber das war aus mehreren Gr\u00fcnden nicht zufriedenstellend, vor allem wegen des Fehlens von Protokollen und der Unm\u00f6glichkeit, es direkt in die Webanwendung zu integrieren. Daher haben wir verschiedene Experimente durchgef\u00fchrt.<\/p>\n

Unsere Anforderungen an die Videoverbindung waren im Grunde genommen folgende:
\n\u2014 Stabilit\u00e4t;
\n\u2014 niedrige Kosten pro Unterrichtseinheit;
\n\u2014 Aufzeichnung der Unterrichtseinheiten;
\n\u2014 Verfolgung, wer wie viel spricht (uns ist wichtig, dass die Sch\u00fcler w\u00e4hrend der Lektionen mehr sprechen als der Lehrer);
\n\u2014 lineare Skalierbarkeit;
\n\u2014 die M\u00f6glichkeit, sowohl UDP als auch TCP zu verwenden.<\/p>\n

Als erstes haben wir 2013 Tokbox getestet. Es war ganz gut, aber es war sehr teuer \u2013 113 Rubel pro Lektion \u2013 und hat unsere Gewinne geschm\u00e4lert.<\/p>\n

Dann haben wir 2015 Voximplant integriert. Hier gab es die erforderliche Funktion zur \u00dcberwachung, wer wie viel spricht, und die L\u00f6sung war deutlich g\u00fcnstiger: Bei der reinen Audioaufnahme kostete es nur 20 Rubel pro Lektion. Allerdings funktionierte es nur \u00fcber UDP und konnte nicht auf TCP umschalten. Trotzdem nutzten letztendlich rund 40 % der Sch\u00fcler dieses System.<\/p>\n

Nach einem Jahr begannen bei uns Corporate-Kunden mit spezifischen Anforderungen aufzutauchen. Zum Beispiel muss alles \u00fcber den Browser funktionieren; im Unternehmen sind nur http und https erlaubt, also keine \u201eSkypes\u201c oder UDP. Corporate-Kunden = Geld, deshalb haben wir zu Tokbox zur\u00fcckgekehrt, aber das Preisproblem besteht weiterhin.<\/p>\n

Die L\u00f6sung \u2014 WebRTC und Janus<\/h2>\n

Wir haben beschlossen, eine browserbasierte Plattform f\u00fcr Peer-to-Peer-Videokonferenzen mit WebRTC<\/a><\/noindex>. Diese ist verantwortlich f\u00fcr die Verbindungseinrichtung, die Codierung und Decodierung von Streams, die Synchronisierung der Kan\u00e4le und die Qualit\u00e4tskontrolle sowie die Verarbeitung von Netzwerkproblemen. Von unserer Seite m\u00fcssen wir den Zugriff auf Streams von Kamera und Mikrofon gew\u00e4hrleisten, das Video rendern, die Verbindung steuern, die WebRTC-Verbindung aufbauen und die Streams \u00fcbertragen sowie die Signalisierungsnachrichten zwischen den Clients austauschen, um die Verbindung herzustellen (WebRTC beschreibt nur das Datenformat, jedoch nicht den \u00dcbertragungsmechanismus). Falls sich die Clients hinter einem NAT befinden, verbindet sich WebRTC mit STUN-Servern; wenn das nicht hilft, werden TURN-Server verwendet.<\/p>\n

Eine einfache P2P-Verbindung reicht uns nicht aus, da wir die Lektionen zur sp\u00e4teren Analyse im Falle von Beschwerden aufzeichnen m\u00f6chten. Daher leiten wir die WebRTC-Streams \u00fcber einen Relaisserver. Janus Gateway von Meetecho<\/a><\/noindex>. Dadurch wissen die Kunden nicht, wo sich die anderen befinden, da sie nur die Adresse des Janus-Servers sehen, der auch die Funktionen eines Signalisierungsservers \u00fcbernimmt. Janus bietet viele n\u00fctzliche Funktionen: er wechselt automatisch zu TCP, wenn UDP beim Client blockiert ist; er kann sowohl UDP- als auch TCP-Streams aufzeichnen; er ist skalierbar; es gibt sogar ein eingebautes Plugin f\u00fcr Echo-Tests. Bei Bedarf werden automatisch STUN- und TURN-Server von Twilio verbunden.<\/p>\n

Im Sommer 2017 betrieben wir zwei Janus-Server sowie einen zus\u00e4tzlichen Server zur Verarbeitung der aufgenommenen Rohdateien von Audio und Video, um die Hauptprozessoren nicht zu belasten. Bei der Verbindung wurden die Janus-Server nach dem Prinzip gerade-ungerade (Verbindungsnummer) ausgew\u00e4hlt. Zu diesem Zeitpunkt war dies ausreichend, wir sch\u00e4tzten, dass es einen ungef\u00e4hr vierfachen Spielraum bot, und die Implementierungsquote betrug etwa 80. Gleichzeitig sank der Preis auf etwa 2 Rubel pro Lektion, zuz\u00fcglich Entwicklung und Support.<\/p>\n

\"Von<\/p>\n

Zur\u00fcck zum Thema Video\u00fcbertragung<\/h2>\n

Wir \u00fcberwachen st\u00e4ndig das Feedback von Sch\u00fclern und Lehrern, um Probleme fr\u00fchzeitig zu erkennen und zu beheben. Bis zum Sommer 2018 war die Verbindungsqualit\u00e4t ganz oben auf der Liste der Beschwerden. Einerseits bedeutete dies, dass wir andere M\u00e4ngel erfolgreich beheben konnten. Andererseits musste dringend etwas unternommen werden: Bei einer Unterrichtsst\u00f6rung riskieren wir, dessen Wert zu verlieren, manchmal sogar zusammen mit dem Preis f\u00fcr das n\u00e4chste Paket; bei einem Ausfall der Einf\u00fchrungssitzung k\u00f6nnten wir sogar einen potenziellen Kunden verlieren.<\/p>\n

Zu diesem Zeitpunkt befand sich unser Videochat weiterhin im MVP-Status. Einfach gesagt, wir haben es gestartet, es hat funktioniert, wir haben es einmal skaliert, und das war's. If it works, don\u2019t fix it. Niemand hat gezielt die Frage der Verbindungsqualit\u00e4t behandelt. Im August wurde klar, dass es so nicht weitergehen kann, und wir haben eine separate Abteilung gegr\u00fcndet, um herauszufinden, was bei unserem WebRTC und Janus nicht stimmt.<\/p>\n

Dieses neue Team erhielt: ein MVP, keine Metriken, keine Ziele, keine Verbesserungsprozesse, w\u00e4hrend 7% der Lehrer \u00fcber die Verbindungsqualit\u00e4t klagten (Daten zu den Sch\u00fclern lagen ebenfalls nicht vor).<\/p>\n

\"Von<\/p>\n

Eine neue Abteilung wird eingerichtet.<\/h2>\n

Das Team sieht folgenderma\u00dfen aus:<\/p>\n