Meet Media API-Konzepte

Mit der Google Meet Media API kann Ihre App an einer Google Meet-Konferenz teilnehmen und Echtzeit-Medienstreams nutzen.

Clients verwenden WebRTC, um mit Meet-Servern zu kommunizieren. Die bereitgestellten Referenzclients (C++, TypeScript) veranschaulichen empfohlene Praktiken. Wir empfehlen Ihnen, direkt auf diesen aufzubauen.

Sie können aber auch vollständig benutzerdefinierte WebRTC-Clients erstellen, die den technischen Anforderungen der Meet Media API entsprechen.

Auf dieser Seite werden die wichtigsten WebRTC-Konzepte beschrieben, die für eine erfolgreiche Meet Media API-Sitzung erforderlich sind.

Signale für Angebotsantworten

WebRTC ist ein Peer-to-Peer-Framework (P2P), bei dem Peers durch Signalisierung miteinander kommunizieren. Um eine Sitzung zu starten, sendet der initiierende Peer ein SDP-Angebot an einen Remote-Peer. Dieses Angebot enthält die folgenden wichtigen Details:

Medienbeschreibungen für Audio- und Videoinhalte

Medienbeschreibungen geben an, was während P2P-Sitzungen übertragen wird. Es gibt drei Arten von Beschreibungen: Audio, Video und Daten.

Um n Audiostreams anzugeben, fügt der Anbieter n Audiomedienbeschreibungen in das Angebot ein. Dasselbe gilt für Videos. Es gibt jedoch maximal eine Datenmedienbeschreibung.

Verkehrsrichtung

Jede Audio- oder Videobeschreibung beschreibt einzelne Secure Real-time Transport Protocol (SRTP)-Streams, die von RFC 3711 verwaltet werden. Sie sind bidirektional, sodass zwei Peers Medien über dieselbe Verbindung senden und empfangen können.

Daher enthält jede Medienbeschreibung (sowohl im Angebot als auch in der Antwort) eines von drei Attributen, die beschreiben, wie der Stream verwendet werden soll:

• sendonly: Es werden nur Medien vom anbietenden Peer gesendet. Der Remote-Peer sendet keine Medien über diesen Stream.

• recvonly: Empfängt nur Medien vom Remote-Peer. Der Offering-Peer sendet keine Medien über diesen Stream.

• sendrecv: Beide Peer können über diesen Stream senden und empfangen.

Codecs

Jede Medienbeschreibung gibt auch die Codecs an, die ein Peer unterstützt. Bei der Meet Media API werden Clientangebote abgelehnt, sofern sie nicht mindestens die in den technischen Anforderungen angegebenen Codecs unterstützen.

DTLS-Handshake

SRTP-Streams werden durch einen anfänglichen Datagram Transport Layer Security-Handshake („DTLS“, RFC 9147) zwischen den Peers gesichert. DTLS ist traditionell ein Client-zu-Server-Protokoll. Während des Signalisierungsprozesses erklärt sich ein Peer bereit, als Server zu fungieren, während der andere als Peer agiert.

Da jeder SRTP-Stream eine eigene DTLS-Verbindung haben kann, gibt jede Medienbeschreibung eines der drei Attribute an, um die Rolle des Peers im DTLS-Handshake anzugeben:

• a=setup:actpass: Der Angebots-Peer überlässt die Auswahl dem Remote-Peer.

• a=setup:active: Dieser Peer fungiert als Client.

• a=setup:passive: Dieser Peer fungiert als Server.

Beschreibungen von App-Medien

Datenkanäle (RFC 8831) sind eine Abstraktion des Stream Control Transmission Protocol („SCTP“, RFC 9260).

Damit Datenkanäle während der anfänglichen Signalphase geöffnet werden können, muss das Angebot eine Anwendungsmedienbeschreibung enthalten. Im Gegensatz zu Audio- und Videobeschreibungen werden in App-Beschreibungen keine Richtung oder Codecs angegeben.

ICE-Kandidaten

Die Interactive Connectivity Establishment-Kandidaten („ICE“, RFC 8445) eines Peers sind eine Liste von Routen, die ein Remote-Peer zum Herstellen einer Verbindung verwenden kann.

Das kartesische Produkt der Listen der beiden Peers, die sogenannten Kandidatenpaare, stellt die potenziellen Routen zwischen zwei Peers dar. Diese Paare werden getestet, um die optimale Route zu ermitteln.

Signale über die Meet REST API senden

Verwenden Sie die Meet REST API, um dieses Angebot-Antwort-Signal zu senden. Ihre App stellt der Methode connectActiveConference() ein SDP-Angebot zur Verfügung und erhält im Gegenzug eine SDP-Antwort.

Beispiel für einen Verbindungsablauf

Hier ist ein Angebot mit einer Beschreibung von Audiomedien:

Der Remote-Peer antwortet mit einer SDP-Antwort, die dieselbe Anzahl von Zeilen mit Medienbeschreibungen enthält. Jede Zeile gibt an, welche Medien der Remote-Peer gegebenenfalls über die SRTP-Streams an den Angebotsclient zurücksendet. Der Remote-Peer kann auch bestimmte Streams vom Anbieter ablehnen, indem er den Eintrag in der Medienbeschreibung auf recvonly setzt.

Bei der Meet Media API senden Clients immer das SDP-Angebot, um eine Verbindung herzustellen. Meet ist nie der Initiator.

Dieses Verhalten wird intern von den Referenzclients (C++, TypeScript) verwaltet. Entwickler benutzerdefinierter Clients können jedoch die PeerConnectionInterface von WebRTC verwenden, um ein Angebot zu generieren.

Damit eine Verbindung zu Google Meet hergestellt werden kann, muss das Angebot bestimmte Anforderungen erfüllen:

1. Der Client muss immer als Client im DTLS-Handshake agieren. Daher muss in jeder Medienbeschreibung im Angebot entweder a=setup:actpass oder a=setup:active angegeben werden.

2. Jede Zeile der Medienbeschreibung muss alle erforderlichen Codecs für diesen Medientyp unterstützen:

   • Audio:Opus
   • Video:VP8, VP9, AV1

3. Damit Audioinhalte empfangen werden können, muss das Angebot genau drei Beschreibungen von Audiomedien zum Empfangen enthalten. Dazu können Sie Transceiver für das Peer-Verbindungsobjekt festlegen.

   C++

   // ...
   rtc::scoped_refptr<webrtc::PeerConnectionInterface> peer_connection;
   
   for (int i = 0; i < 3; ++i) {
     webrtc::RtpTransceiverInit audio_init;
     audio_init.direction = webrtc::RtpTransceiverDirection::kRecvOnly;
     audio_init.stream_ids = {absl::StrCat("audio_stream_", i)};
   
     webrtc::RTCErrorOr<rtc::scoped_refptr<webrtc::RtpTransceiverInterface>>
       audio_result = peer_connection->AddTransceiver(
         cricket::MediaType::MEDIA_TYPE_AUDIO, audio_init);
   
     if (!audio_result.ok()) {
       return absl::InternalError(absl::StrCat("Failed to add audio transceiver: ",
                                               audio_result.error().message()));
     }
   }
   

   JavaScript

   pc = new RTCPeerConnection();
   
   // Configure client to receive audio from Meet servers.
   pc.addTransceiver('audio', {'direction':'recvonly'});
   pc.addTransceiver('audio', {'direction':'recvonly'});
   pc.addTransceiver('audio', {'direction':'recvonly'});
   

4. Damit Videos empfangen werden können, muss das Angebot 1–3 Beschreibungen für Videomedien zum Empfangen enthalten. Dazu können Sie Transceiver für das Peer-Verbindungsobjekt festlegen.

   C++

   // ...
   rtc::scoped_refptr<webrtc::PeerConnectionInterface> peer_connection;
   
   for (uint32_t i = 0; i < configurations.receiving_video_stream_count; ++i) {
     webrtc::RtpTransceiverInit video_init;
     video_init.direction = webrtc::RtpTransceiverDirection::kRecvOnly;
     video_init.stream_ids = {absl::StrCat("video_stream_", i)};
   
     webrtc::RTCErrorOr<rtc::scoped_refptr<webrtc::RtpTransceiverInterface>>
         video_result = peer_connection->AddTransceiver(
           cricket::MediaType::MEDIA_TYPE_VIDEO, video_init);
   
     if (!video_result.ok()) {
       return absl::InternalError(absl::StrCat("Failed to add video transceiver: ",
                                               video_result.error().message()));
     }
   }
   

   JavaScript

   pc = new RTCPeerConnection();
   
   // Configure client to receive video from Meet servers.
   pc.addTransceiver('video', {'direction':'recvonly'});
   pc.addTransceiver('video', {'direction':'recvonly'});
   pc.addTransceiver('video', {'direction':'recvonly'});
   

5. Das Angebot muss immer Datenkanäle enthalten. Die Kanäle session-control und media-stats sollten immer geöffnet sein. Alle Datenkanäle müssen ordered sein.

   C++

   // ...
   // All data channels must be ordered.
   constexpr webrtc::DataChannelInit kDataChannelConfig = {.ordered = true};
   
   rtc::scoped_refptr<webrtc::PeerConnectionInterface> peer_connection;
   
   // Signal session-control data channel.
   webrtc::RTCErrorOr<rtc::scoped_refptr<webrtc::DataChannelInterface>>
     session_create_result = peer_connection->CreateDataChannelOrError(
       "session-control", &kDataChannelConfig);
   
   if (!session_create_result.ok()) {
     return absl::InternalError(absl::StrCat("Failed to create data channel ",
                                             data_channel_label, ": ",
                                             session_create_result.error().message()));
   }
   
   // Signal media-stats data channel.
   webrtc::RTCErrorOr<rtc::scoped_refptr<webrtc::DataChannelInterface>>
     stats_create_result = peer_connection->CreateDataChannelOrError(
       "media-stats", &kDataChannelConfig);
   
   if (!stats_create_result.ok()) {
     return absl::InternalError(absl::StrCat("Failed to create data channel ",
                                             data_channel_label, ": ",
                                             stats_create_result.error().message()));
   }
   

   JavaScript

   // ...
   pc = new RTCPeerConnection();
   
   // All data channels must be ordered.
   const dataChannelConfig = {
     ordered: true,
   };
   
   // Signal session-control data channel.
   sessionControlChannel = pc.createDataChannel('session-control', dataChannelConfig);
   sessionControlChannel.onopen = () => console.log("data channel is now open");
   sessionControlChannel.onclose = () => console.log("data channel is now closed");
   sessionControlChannel.onmessage = async (e) => {
     console.log("data channel message", e.data);
   };
   
   // Signal media-stats data channel.
   mediaStatsChannel = pc.createDataChannel('media-stats', dataChannelConfig);
   mediaStatsChannel.onopen = () => console.log("data channel is now open");
   mediaStatsChannel.onclose = () => console.log("data channel is now closed");
   mediaStatsChannel.onmessage = async (e) => {
     console.log("data channel message", e.data);
   };
   

Beispiel für ein SDP-Angebot und eine SDP-Antwort

Hier ein vollständiges Beispiel für ein gültiges SDP-Angebot und eine zugehörige SDP-Antwort. Mit diesem Angebot wird eine Meet Media API-Sitzung mit Audio und einem einzelnen Videostream ausgehandelt.

Beachten Sie, dass es drei Audiomedienbeschreibungen, eine Videomedienbeschreibung und die erforderliche Anwendungsmedienbeschreibung gibt.

Weitere Informationen

• Jetzt starten