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 Aktionspunkte 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
- Audiostreams nutzen
- Metadaten von Teilnehmern nutzen
Lebenszyklus der Meet Media API
Die folgenden Abbildungen zeigen den Lebenszyklus der Meet Media API:
-
Abbildung 1 Der Meet Media API-Bot versucht, der Website eines Drittanbieters beizutreten. Die Verbindung wird abgelehnt, wenn Konten von Minderjährigen vorhanden sind. -
Abbildung 2 Besprechungen können als verschlüsselt markiert und mit einem Wasserzeichen versehen werden. Die Meet Media API kann nicht verbunden werden, wenn eine Besprechung verschlüsselt ist oder ein Wasserzeichen hat. -
Abbildung 3. Achten Sie darauf, dass die Administratoreinstellung korrekt ist. -
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. -
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. -
Abbildung 6 Wenn der Inhaber der Besprechung ein privates Konto 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. -
Abbildung 7 Sobald die Verbindung hergestellt ist, sehen der Organisator, der Co-Organisator und alle Teilnehmer in derselben Organisation wie der Organisator den Initiierungsdialog. -
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 dann 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 über Gmail-Konten organisiert werden, muss der Initiator an der Besprechung teilnehmen, um die Einwilligung zu erteilen.
Allgemeine Begriffe
- Google 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 Media-Streams können Sie nicht davon ausgehen, dass ein Media-Stream 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 Media-Streams 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.
- Media-Stream
Ein WebRTC-Media-Stream 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 Media-Stream-Tracks, die jeweils eine einzelne Medienquelle darstellen, z. B. einen Videotrack oder einen Audiotrack.
- Media-Stream-Track
Besteht aus einem einzelnen unidirektionalen Fluss von RTP-Paketen. Ein Media-Stream-Track kann Audio oder Video sein, aber nicht beides. Eine bidirektionale Secure Real-time Transport Protocol (SRTP)-Verbindung besteht in der Regel aus zwei Media-Stream-Tracks: Egress vom lokalen zum Remote-Peer und Ingress vom Remote-Peer zum lokalen Peer.
- Konferenzraum
Ein virtueller Ort oder ein dauerhaftes Objekt (z. B. ein Konferenzraum), an dem eine Konferenz stattfindet. In einem Raum kann immer 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 oder den Companion-Modus verwendet, als Zuschauer zuschaut 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 Media-Streams 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, mit dem WebRTC eine P2P-Verbindung aushandelt.
RFC 8866regelt 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 Angebot-Antwort-Peer-to-Peer-Verhandlungsablauf. 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 Media-Streams innerhalb einer RTP-Sitzung (Real-time Transport Protocol) eindeutig identifiziert. In WebRTC werden SSRCs verwendet, um zwischen verschiedenen Media-Streams zu unterscheiden, die von verschiedenen Teilnehmern stammen, oder sogar zwischen verschiedenen Tracks desselben Teilnehmers (z. B. verschiedene Kameras).
- RtpTransceiver
Wie in
RFC 8829beschrieben, ist ein Transceiver eine Abstraktion für RTP-Streams in einer Peer-to-Peer-Sitzung.Ein einzelner Transceiver wird einer einzelnen Medienbeschreibung im SDP zugeordnet und durch diese beschrieben. Ein Transceiver besteht aus einem
RtpSenderund einemRtpReceiver.Da RTP bidirektional ist, hat jeder Peer eine eigene Transceiver-Instanz für dieselbe RTP-Verbindung. Der
RtpSendereines bestimmten Transceivers für den lokalen Peer wird demRtpReceivereines bestimmten Transceivers im Remote-Peer zugeordnet. Auch das Gegenteil kann der Fall sein. DerRtpSenderdesselben Transceivers des Remote-Peers wird demRtpReceiverdes lokalen Peers zugeordnet.Jede Medienbeschreibung hat einen eigenen Transceiver. Daher hat eine Peer-to-Peer-Sitzung mit mehreren RTP-Streams mehrere Transceiver mit mehreren
RtpSendersundRtpReceivers für jeden Peer.- Virtuelle Media-Streams
Virtuelle Media-Streams sind aggregierte Media-Streams, 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.
Weitere Informationen
Informationen zum Entwickeln eines Meet Media API-Clients finden Sie unter den Schritten in Erste Schritte.
Informationen zum Einrichten und Ausführen eines Beispiel-Referenzclients für die Meet Media API finden Sie unter Schnellstart für den C++-Referenzclient.
Eine konzeptionelle Übersicht finden Sie unter Konzepte der Meet Media API.
Weitere Informationen zu WebRTC finden Sie unter WebRTC For The Curious.
Informationen zur Entwicklung mit Google Workspace-APIs, einschließlich der Verarbeitung von Authentifizierung und Autorisierung, finden Sie unter Entwicklung in Google Workspace.