Meet Media API – Übersicht

Mit der Google Meet Media API können Sie auf Echtzeitmedien aus Google Meet-Konferenzen zugreifen. Dadurch sind verschiedene Anwendungsfälle möglich, z. B. Apps, die Aufgaben dokumentieren, Echtzeitinformationen zur aktuellen Besprechung bieten oder Audio und Video auf eine neue Oberfläche streamen.

Anwendungsfälle

In der Google Cloud Console registrierte Apps können die Meet Media API verwenden, um eine Verbindung zu Meet-Konferenzen herzustellen. Dadurch können sie Folgendes tun:

  • Videostreams nutzen. Beispiel:
    • Videostreams, die in Meet-Konferenzen generiert werden, in eigene KI-Modelle einfließen lassen.
    • Streams für benutzerdefinierte Aufzeichnungen filtern.
  • Audiostreams nutzen. Beispiel:
    • Audio direkt in Gemini einfließen lassen und einen eigenen KI-Chatbot für Besprechungen erstellen.
    • Audiostreams, die in Meet-Konferenzen generiert werden, in einen eigenen Transkriptionsdienst einfließen lassen.
    • Untertitel in verschiedenen Sprachen generieren.
    • Aus dem erfassten Audio modellgenerierte Gebärdensprach-Feeds erstellen.
    • Eigene Modelle zur Rauschunterdrückung erstellen, um Hintergrundgeräusche und störende Artefakte aus der Konferenz zu entfernen.
  • Metadaten von Teilnehmern nutzen. Beispiel:
    • Erkennen, welche Teilnehmer an der Konferenz teilnehmen, um bessere Informationen und Analysen zu erhalten.

Lebenszyklus der Meet Media API

Die folgenden Bilder zeigen den Lebenszyklus der Meet Media API:

  • Der Meet Media API-Bot versucht, der Drittanbieter-Website beizutreten.
    Abbildung 1 Der Meet Media API-Bot versucht, der Konferenz auf der Website eines Drittanbieters beizutreten. Die Verbindung wird abgelehnt, wenn Konten von Minderjährigen vorhanden sind.
  • Verschlüsselte Videokonferenzen und Videokonferenzen mit Wasserzeichen.
    Abbildung 2 Besprechungen können als verschlüsselt gekennzeichnet und mit einem Wasserzeichen versehen werden. Die Meet Media API kann nicht verbunden werden, wenn eine Besprechung verschlüsselt ist oder ein Wasserzeichen hat.
  • Prüfen Sie, ob die Administratoreinstellung korrekt ist.
    Abbildung 3. Achten Sie darauf, dass die Administratoreinstellung korrekt ist.
  • Richten Sie die Besprechung in Google Kalender ein.
    Abbildung 4 Richten Sie die Besprechung in Google Kalender ein. Der Organisator muss der Drittanbieter-App in den Kalendereinstellungen die Berechtigung erteilen, andernfalls wird die Verbindung abgelehnt.
  • Einstellungsänderung während des Anrufs
    Abbildung 5 Eine Änderung der Einstellungen während des Anrufs. Wenn der Organisator die Einstellung für die Meet Media API während eines Anrufs deaktiviert, wird die Verbindung beendet.
  • Der Initiator muss bei Verbraucherbesprechungen anwesend sein.
    Abbildung 6 Wenn der Inhaber der Besprechung ein Privatnutzerkonto hat (ein Konto, das auf @gmail.com endet), muss der Initiator an der Besprechung teilnehmen, um die Einwilligung zu erteilen. Andernfalls wird die Verbindung abgelehnt.
  • Verbindung hergestellt.
    Abbildung 7 Sobald die Verbindung hergestellt ist, sehen der Organisator, der Co-Organisator und alle Teilnehmer in derselben Organisation wie der Organisator den Initiierungsdialog.
  • Jeder kann die Meet Media API während des Anrufs beenden.
    Abbildung 8 Jeder kann die Meet Media API während des Anrufs beenden.

Anforderungen an die Einwilligung

Apps, die die Meet Media API verwenden, dürfen nur an einer Besprechung teilnehmen, wenn jemand in dem Anruf die Einwilligung im Namen der Besprechung erteilen darf.

Für Google Workspace-Besprechungen

Um die Einwilligung in Google Workspace-Besprechungen zu erteilen, müssen Sie der Organisation angehören, die die Besprechung besitzt. In den meisten Fällen ist der Inhaber der Besprechung derselbe wie der Organisator. Wenn der Organisator oder der Initiator an der Besprechung teilnimmt und der Organisation angehört, die die Besprechung besitzt, wird ihm vorzugsweise der Startdialog angezeigt.

Für private Besprechungen

Bei Besprechungen, die von Gmail-Konten organisiert werden, muss der Initiator an der Besprechung teilnehmen, um die Einwilligung zu erteilen.

Allgemeine Begriffe

Cloud-Projektnummer
Eine unveränderliche generierte int64-Kennung für ein Google Cloud-Projekt. Diese Werte werden von der Google Cloud Console für jede registrierte App generiert.
Konferenz
Eine vom Server generierte Instanz eines Anrufs in einem Konferenz raum. Nutzer betrachten dieses Szenario in der Regel als eine einzelne Besprechung.
Datenkanal für Konferenzressourcen

Anstatt Ressourcen über HTTP anzufordern, wie bei der Google Meet REST API, fordern Meet Media API-Clients Ressourcen vom Server über Datenkanäle an.

Für jeden Ressourcentyp kann ein eigener Datenkanal geöffnet werden. Nach dem Öffnen kann der Client Anfragen über den Kanal senden. Ressourcenaktualisierungen werden über denselben Kanal übertragen.

Beitragende Quelle (Contributing Source, CSRC)

Bei virtuellen Medienstreams kann nicht davon ausgegangen werden, dass ein Medienstrom immer auf denselben Teilnehmer verweist. Der CSRC-Wert im Header jedes RTP-Pakets gibt die tatsächliche Quelle des Pakets an.

Meet weist jedem Teilnehmer einer Konferenz beim Beitritt einen eindeutigen CSRC-Wert zu. Dieser Wert bleibt konstant, bis der Teilnehmer die Konferenz verlässt.

Datenkanäle

WebRTC-Datenkanäle ermöglichen den Austausch beliebiger Daten (Text, Dateien usw.) unabhängig von Audio- und Videostreams. Datenkanäle verwenden dieselbe Verbindung wie Medienstreams und bieten so eine effiziente Möglichkeit, WebRTC-Anwendungen um den Datenaustausch zu erweitern.

Interactive Connectivity Establishment (ICE)

Ein Protokoll zum Herstellen einer Verbindung, zum Ermitteln aller möglichen Routen für die Kommunikation zwischen zwei Computern über Peer-to-Peer-Netzwerke (P2P) und zum Aufrechterhalten der Verbindung.

Medienstrom

Ein WebRTC-Medienstrom stellt einen Fluss von Mediendaten dar, in der Regel Audio oder Video, die von einem Gerät wie einer Kamera oder einem Mikrofon erfasst werden. Er besteht aus einem oder mehreren Medienstrom-Tracks, die jeweils eine einzelne Medienquelle darstellen, z. B. einen Videotrack oder einen Audiotrack.

Medienstrom-Track

Besteht aus einem einzelnen unidirektionalen Fluss von RTP-Paketen. Ein Medienstrom-Track kann Audio oder Video sein, aber nicht beides. Eine bidirektionale Secure Real-time Transport Protocol (SRTP)-Verbindung besteht in der Regel aus zwei Medienstrom-Tracks: ausgehender Traffic vom lokalen zum Remote-Peer und eingehender Traffic vom Remote-Peer zum lokalen Peer.

Konferenzraum

Ein virtueller Ort oder ein persistentes Objekt (z. B. ein Konferenzraum), in dem eine Konferenz stattfindet. In einem Raum kann jeweils nur eine aktive Konferenz stattfinden. Ein Konferenzraum hilft Nutzern auch, sich zu treffen und gemeinsam genutzte Ressourcen zu finden.

Teilnehmer

Eine Person, die an einer Konferenz teilnimmt, den Companion-Modus verwendet, als Zuschauer teilnimmt oder ein Raumgerät, das mit einem Anruf verbunden ist. Wenn ein Teilnehmer der Konferenz beitritt, wird ihm eine eindeutige ID zugewiesen.

Relevante Streams

Es gibt eine Obergrenze für die Anzahl der virtuellen Audiostreams und virtuellen Videostreams , die ein Client öffnen kann.

Es ist durchaus möglich, dass die Anzahl der Teilnehmer an einer Konferenz diese Zahl übersteigt. In diesen Fällen übertragen die Meet-Server die Audio- und Videostreams der Teilnehmer, die als „am relevantesten“ eingestuft werden. Die Relevanz wird anhand verschiedener Merkmale bestimmt, z. B. der Bildschirmfreigabe und wie lange es her ist, dass ein Teilnehmer gesprochen hat.

Selective Forwarding Unit (SFU)

Eine Selective Forwarding Unit (SFU) ist eine serverseitige Komponente in WebRTC-Konferenzen, die die Verteilung von Medienstreams verwaltet. Teilnehmer stellen nur eine Verbindung zur SFU her, die relevante Streams selektiv an andere Teilnehmer weiterleitet. Dadurch werden die Clientverarbeitung und der Bandbreitenbedarf reduziert, was skalierbare Konferenzen ermöglicht.

Session Description Protocol (SDP)

Der Signalmechanismus, den WebRTC verwendet, um eine P2P-Verbindung auszuhandeln. RFC 8866 regelt es.

SDP-Antwort

Die Antwort auf ein SDP-Angebot. Die Antwort lehnt alle empfangenen Streams vom Remote-Peer ab oder akzeptiert sie. Außerdem wird ausgehandelt, welche Streams an den anbietenden Peer zurückgesendet werden sollen. Es ist wichtig zu beachten, dass der SDP-Antwort keine signalisierten Streams aus dem ursprünglichen Angebot hinzugefügt werden können. Wenn ein anbietender Peer signalisiert, dass er bis zu drei Audiostreams von seinem Remote-Peer akzeptiert, kann dieser Remote-Peer nicht vier Audiostreams zur Übertragung signalisieren.

SDP-Angebot

Das anfängliche SDP im Peer-to-Peer-Verhandlungsablauf für Angebot und Antwort. Das Angebot wird vom initiierenden Peer erstellt und legt die Bedingungen der Peer-to-Peer-Sitzung fest. Das Angebot wird immer vom Meet Media API-Client erstellt und an die Meet-Server gesendet.

Ein Angebot kann beispielsweise die Anzahl der Audio- oder Videostreams angeben, die der Anbieter sendet (oder empfangen kann), und ob Datenkanäle geöffnet werden sollen.

Synchronisierungsquelle (Synchronization Source, SSRC)

Eine SSRC ist eine 32-Bit-Kennung, die eine einzelne Quelle eines Medienstroms innerhalb einer RTP-Sitzung (Real-time Transport Protocol) eindeutig identifiziert. In WebRTC werden SSRCs verwendet, um zwischen verschiedenen Medienstreams zu unterscheiden, die von verschiedenen Teilnehmern stammen, oder sogar zwischen verschiedenen Tracks desselben Teilnehmers (z. B. verschiedene Kameras).

RtpTransceiver

Wie in RFC 8829 beschrieben, ist ein Transceiver eine Abstraktion für RTP-Streams in einer Peer-to-Peer-Sitzung.

Ein einzelner Transceiver wird durch eine einzelne Medienbeschreibung im SDP zugeordnet und beschrieben. Ein Transceiver besteht aus einem RtpSender und einem RtpReceiver.

Da RTP bidirektional ist, hat jeder Peer eine eigene Transceiver-Instanz für dieselbe RTP-Verbindung. Der RtpSender eines bestimmten Transceivers für den lokalen Peer wird dem RtpReceiver eines bestimmten Transceivers im Remote-Peer zugeordnet. Auch das Gegenteil kann der Fall sein. Der RtpSender desselben Transceivers des Remote-Peers wird dem RtpReceiver des lokalen Peers zugeordnet.

Jede Medienbeschreibung hat einen eigenen Transceiver. Daher hat eine Peer-to-Peer-Sitzung mit mehreren RTP-Streams mehrere Transceiver mit mehreren RtpSenders und RtpReceivers für jeden Peer.

Virtuelle Medienstreams

Virtuelle Medienstreams sind aggregierte Medienstreams, die von einer Selective Forwarding Unit (SFU) in WebRTC-Konferenzen generiert werden. Anstatt dass jeder Teilnehmer einzelne Streams an alle anderen sendet, multiplexiert die SFU ausgewählte Teilnehmerstreams auf weniger ausgehende virtuelle Streams. Dadurch wird die Verbindungstopologie vereinfacht und die Last für die Teilnehmer reduziert, was skalierbare Konferenzen ermöglicht. Jeder virtuelle Stream kann Medien von mehreren Teilnehmern enthalten, die dynamisch von der SFU verwaltet werden.