Wie Gruppen-Videoanrufe funktionieren: Signalisierung, Mesh und SFU-Medienserver

Ein Videoanruf zwischen zwei Personen kann direkt von einem Gerät zum anderen laufen. WebRTC sendet Kamera und Mikrofon jeder Person direkt an die andere und nimmt nur dann ein Relay, wenn eine Firewall im Weg ist, wie unser Beitrag über STUN- und TURN-Server erklärt.

Kommt eine dritte Person hinzu, funktioniert derselbe Ansatz noch. Bei einer sechsten fängt er an auseinanderzufallen: Das Bild friert ein, der Lüfter des Laptops dreht hoch, und die Person am Smartphone fliegt aus dem Anruf. Gruppenanrufe brauchen einen anderen Aufbau, und fast jede App, die sie betreibt, landet beim selben.

Dieser Beitrag geht die Bausteine durch: den Signalisierungsserver, den jeder Anruf braucht, das Mesh, das für ein paar Personen funktioniert, die zwei Arten von Medienservern und was sich bei der Verschlüsselung ändert, wenn ein Server in der Mitte sitzt.

Jeder Anruf braucht Signalisierung

Bevor Audio oder Video fließt, müssen sich die Geräte in einem Anruf einigen, wie. Jedes beschreibt, was es senden und empfangen kann, die Codecs, die Auflösungen und die Adressen, unter denen es erreichbar ist, und die andere Seite antwortet. In WebRTC heißen sie Offer, Answer und ICE-Kandidaten.

Wie sie übertragen werden, legt WebRTC nicht fest. Das bleibt Ihrer App überlassen, und der Teil, der sie überträgt, ist der Signalisierungsserver. In der Praxis ist das ein WebSocket-Server, zu dem jede Seite und jede App eine Verbindung hält, denn ein Anruf braucht mehr als den ersten Austausch:

• Klingeln. Der Anruf muss bei der angerufenen Person in jedem Tab und auf jedem Gerät klingeln, das sie geöffnet hat, und überall aufhören zu klingeln, sobald sie auf einem davon annimmt.
• Wer im Anruf ist. Alle müssen erfahren, wenn jemand beitritt oder geht, seine Kamera einschaltet oder seinen Bildschirm teilt.
• Wer beitreten darf. Am Signalisierungsserver wird ein Anruf zugelassen oder abgewiesen, also entscheidet Ihre App dort, wer wen anrufen darf und wer welchem Gruppenanruf beitritt.

Der Signalisierungsserver überträgt nur wenige Daten, aber er muss erreichbar sein, wann immer ein Anruf beginnen könnte, und er muss Ihre Nutzer kennen.

Mesh: Jeder sendet an jeden

Der einfachste Gruppenanruf ist ein Mesh. Jedes Gerät baut eine direkte Verbindung zu jedem anderen Gerät auf und sendet sein Kamerabild an jedes davon.

Bei drei Personen sendet jedes Gerät zwei Kopien seines Bildes und empfängt zwei. Das geht gut. Das Problem ist, wie es wächst:

Personen im Anruf	Kopien, die jedes Gerät sendet	Verbindungen im Anruf
3	2	3
5	4	10
8	7	28
12	11	66

Ein Kamerabild in guter Qualität wird oft mit ein bis zwei Megabit pro Sekunde gesendet. In einem Anruf zu acht müsste jedes Gerät sieben davon gleichzeitig senden, mehr, als viele Heim- und Mobilfunkanschlüsse dauerhaft hochladen können. Meist kodiert das Gerät das Bild außerdem für jede Verbindung einzeln, und genau das lässt den Lüfter hochdrehen und leert den Akku des Smartphones.

Ein Mesh passt gut für drei oder vier Personen mit ordentlichen Verbindungen, ganz ohne Server, der Medien überträgt. Darüber hinaus braucht der Anruf einen Server in der Mitte.

Die MCU: ein gemischtes Bild für alle

Die ältere Antwort ist eine Multipoint Control Unit, kurz MCU. Jedes Gerät sendet sein Bild einmal an den Server. Der Server dekodiert sie alle, setzt sie zu einem gemeinsamen Bild zusammen, kodiert es neu und sendet dieses eine Bild an jede Person.

Jedes Gerät sendet dann einen Stream und empfängt einen, was Smartphones und langsame Netze schont. Die Last wandert zum Server: Jedes Bild jedes Anrufs zu dekodieren und neu zu kodieren kostet viel Rechenleistung, das Mischen bringt Verzögerung, und alle sehen dasselbe Layout, das der Server wählt. MCUs findet man noch dort, wo ein einziges Bild gebraucht wird, etwa wenn sich eine Telefonleitung in ein Videomeeting einwählt, aber die meisten Gruppenanrufe nutzen heute die andere Art von Server.

Die SFU: einmal senden, an alle weiterleiten

Eine Selective Forwarding Unit, kurz SFU, ist der Medienserver, auf dem die meisten Gruppenanrufe laufen. Jedes Gerät sendet sein Bild einmal an die SFU, und die SFU leitet es an alle anderen im Anruf weiter, ohne es zu dekodieren.

Jedes Gerät sendet einen Stream, egal wie viele Personen im Anruf sind. Es empfängt einen Stream für jede Person, die es anzeigt, und genau hier kommt das „Selective“ ins Spiel. Da die SFU zwischen jedem Sender und jedem Empfänger sitzt, kann sie wählen, was jede Person bekommt:

• Mehrere Qualitäten von jedem Sender. Mit Simulcast sendet ein Gerät sein Bild gleichzeitig in zwei oder drei Größen, und die SFU leitet die kleine an jemanden weiter, der es als Miniatur zeigt oder eine schwache Verbindung hat, und die große an jemanden, der es im Vollbild zeigt.
• Nur was auf dem Bildschirm ist. In einem Anruf mit dreißig Personen braucht eine Seite, die neun Kacheln zeigt, die übrigen einundzwanzig Bilder nicht. Die SFU setzt ihre Weiterleitung aus, bis sie angezeigt werden.
• Wer gerade spricht. Die SFU sieht die Audiopegel aller und kann jeder Seite sagen, wer gerade spricht, sodass die Seite diese Person groß zeigen kann.
• Sprecher und Zuhörer. In einem Kurs oder auf einem Podium senden wenige Personen, und alle anderen empfangen nur. Die SFU leitet die Sprecher weiter und nimmt von den Zuhörern nichts entgegen, sodass ein Anruf auf viel mehr Personen wachsen kann, als vor der Kamera sind.

Da die SFU die Medien nie dekodiert, kann ein einziger Server sehr viele Streams weiterleiten. Ein sehr großer Anruf kann sich über mehrere SFUs erstrecken, von denen jede die Personen in ihrer Nähe bedient und die Streams an die anderen weitergibt, sodass sich Personen auf verschiedenen Kontinenten jeweils mit einem Server in ihrer Nähe verbinden.

Wenn eine Person vor allen präsentiert und das Publikum nur zuschaut, ändert sich der Aufbau erneut: Das ist ein Livestream, gemacht für ein Publikum jeder Größe, mit einem Chat daneben, den wir in Live-Streaming für Ihre App behandeln.

Verschlüsselung mit einem Server in der Mitte

Jede WebRTC-Verbindung ist verschlüsselt, sodass niemand im Netzwerk zwischen einem Gerät und dem Server den Anruf sehen oder hören kann. In einem direkten Anruf zwischen zwei Personen ist das eine Ende-zu-Ende-Verschlüsselung: Nur die beiden Geräte haben die Schlüssel.

Mit einer SFU endet die Verbindung jedes Geräts am Server. Die SFU entschlüsselt, was ankommt, und verschlüsselt es für jeden Empfänger neu, sodass der Server alles sehen und hören könnte, was er weiterleitet. Für viele Apps ist das in Ordnung. Für Arzt und Patientin, Anwältin und Mandant oder ein Team, das etwas Vertrauliches bespricht, ist es das nicht.

Die Lösung ist, jeden Audio- und Video-Frame ein zweites Mal zu verschlüsseln, im Gerät selbst, bevor er es verlässt, mit einem Schlüssel, den der Server nie hat. Aktuelle Browser unterstützen das über WebRTC Encoded Transforms. Die SFU sieht weiterhin, welcher Stream welcher ist, und leitet sie weiter wie zuvor, aber was sie weiterleitet, ist versiegelt. Die Schlüssel kommen von Ihrem eigenen Server, der sie nur an die Personen gibt, die in den Anruf dürfen.

Der Preis dafür: Ein Server, der die Medien nicht lesen kann, kann sie auch nicht mischen, aufzeichnen oder ihr Format ändern. Genau darum geht es.

Eine eigene SFU betreiben

Es gibt Open-Source-SFUs, und sie sind solide. Ein Team, das eine eigene betreibt, übernimmt:

• Server mit öffentlichen Adressen und offenen UDP-Ports, in den Regionen, in denen Ihre Nutzer sind, mit Bandbreite für jeden Stream, den sie weiterleiten.
• Dazu TURN-Relays, denn manche Personen erreichen die SFU trotzdem nicht direkt, genau wie bei einem Anruf zwischen zwei Personen.
• Einen Signalisierungsserver, der Ihre Nutzer kennt, ihre Geräte klingeln lässt und entscheidet, wer beitritt.
• Die Zuteilung jedes Anrufs, damit seine Personen auf einem Server in ihrer Nähe landen, der noch Platz hat, und das Verteilen eines großen Anrufs auf mehrere Server.
• Den laufenden Betrieb: Updates, Überwachung und Anrufe, die auf einen anderen Server wechseln, wenn einer ausfällt.

Nichts davon ist exotisch, aber es ist ein Dienst, den Sie am Laufen halten müssen, solange Ihre App Anrufe hat.

Wie WordPlus Cloud Gruppenanrufe betreibt

WordPlus Cloud betreibt all das für Sie, von der Signalisierung bis zu den Medienservern:

1. Signalisierung über die Verbindung, die Ihre Seiten schon haben. Dieselbe Echtzeitverbindung, über die Ihre Räume laufen und die zeigt, wer online ist, lässt einen Anruf in jedem Tab und jeder App der angerufenen Person klingeln und sagt allen in einem Gruppenanruf, wer beitritt, geht und spricht.
2. Gruppenanrufe auf unseren Medienservern, in mehreren Regionen. Jedes Gerät sendet sein Kamerabild einmal, egal wie viele Personen im Anruf sind, und für die Personen in einem Anruf gibt es keine Obergrenze.
3. Ihr Server entscheidet. Eine Regel auf Ihrem Server legt fest, wer welchem Gruppenanruf beitreten darf, wer spricht und wer nur zuhört, und wer Host ist. Hosts schalten ein Mikrofon stumm, lassen jemanden sprechen und entfernen jemanden, und Ihr Server kann dasselbe tun, ohne dass eine Seite geöffnet ist.
4. Ende-zu-Ende-Verschlüsselung, wenn Ihre Regel das sagt. Jeder Frame wird im Browser mit einem Schlüssel verschlüsselt, den Ihr Server ableitet, sodass unsere Medienserver weiterleiten, was sie nicht lesen können. Ein Anruf zwischen zwei Personen, dem eine weitere Person beitritt, wird zu einem Gruppenanruf und bleibt Ende-zu-Ende-verschlüsselt.
5. Ein Anrufbildschirm, sofort nutzbar, oder Ihr eigener. Nutzen Sie das fertige Anruffenster im Web, unter iOS und Android, oder bauen Sie Ihre eigene Oberfläche auf demselben SDK.

Das funktioniert mit Next.js, Laravel, Django und anderen Stacks über unsere SDKs, und Better Messages lässt seine Gruppenanrufe auf WordPress über dieselben Medienserver laufen. Videoanrufe und Gruppenanrufe für Ihre App zeigt, was Ihnen die SDKs bieten, und unsere Dokumentation zeigt den Code dazu, wie Anrufe funktionieren.