Meet eCDN On-Prem API verwenden

Auf dieser Seite wird erläutert, wie Sie die On-Premises API des Google Meet Enterprise Content Delivery Network (eCDN) für das Livestreaming in Google Meet verwenden.

Mit der hier beschriebenen API-Lösung können Kunden den gesamten Funktionsumfang des Meet-eCDN nutzen, ohne dass private IP-Informationen an Google weitergegeben werden. Sie können einen neuen lokalen Webdienst in Ihrem eigenen Netzwerk definieren, der anstelle der Informationen zur privaten IP-Adresse eine ID übergibt.

Meet eCDN – Übersicht

eCDN ist in Meet integriert und wird während Livestreams automatisch gestartet, nachdem ein Google Workspace-Administrator es eingerichtet hat. Wenn eCDN in Meet aktiviert ist, können Livestream-Zuschauer in einem lokalen Netzwerk gestreamte Medien über eine Peer-to-Peer-Freigabe (P2P) mit anderen Nutzern im Netzwerk teilen. Die meisten Geräte empfangen die gestreamten Medien von Peers in der Nähe und müssen sie nicht von den Google-Servern abrufen. Dadurch wird die von den Zuschauern genutzte Gesamtbandbreite gesenkt. Weitere Informationen zum Einrichten und Verwenden des eCDN von Google Meet finden Sie unter Große Livestreams hosten.

Für eCDN müssen Zuschauer von Meet-Livestreams in Peering-Gruppen angeordnet werden. Eine Peering-Gruppe besteht aus einer Reihe von Knoten, die Medien miteinander teilen dürfen. Für Geräte in einer Peering-Gruppe ist das Peering entweder zulässig oder die Peering-Gruppe ist blockiert. Zugelassene Geräte können sich nur mit anderen Geräten in derselben Peering-Gruppe verbinden. Weitere Informationen zu Peering-Gruppen findest du unter Vorbereitung.

Wann sollte die API verwendet werden?

eCDN kann Peering-Gruppen mit mehreren verschiedenen Peering-Richtlinien bilden: random, subnet oder custom rules. Letzterer teilt eine Tabelle mit privaten Netzwerkbereichen mit dem eCDN-Tracker-Server von Google, um private IP-Adressen der einzelnen Peer-Knoten einer Peering-Gruppe zuzuordnen. Die custom rules-Richtlinie ist die bevorzugte Lösung und eignet sich für die meisten Produktionsumgebungen.

Gemäß der custom rules-Richtlinie müssen Sie jedoch große Teile Ihrer privaten Netzwerkstruktur für Google freigeben. Außerdem geben einzelne Nutzer ihre lokal erkannten privaten IP-Adressen an Google weiter, wenn sie eCDN verwenden. In einigen Organisationen ist die Weitergabe privater IP-Informationen aufgrund der Sicherheitsrichtlinien möglicherweise nicht zulässig.

Mit der Meet eCDN On-Premises API entwickeln

Die Meet eCDN On-Premises API bietet eine Webserver-Spezifikation, die Sie lokal im Netzwerk Ihrer Organisation implementieren und hosten können. Sie können einen benutzerdefinierten Webdienst erstellen, der mit der API kompatibel ist, um alle Aufgaben auszuführen, die von privaten IP-Informationen abhängen, damit die Informationen nicht an Google weitergegeben werden.

Die API umfasst die beiden wichtigen Schritte zum Abgleichen privater IP-Adressen, die normalerweise vom eCDN-Tracker-Server verarbeitet werden: Zuordnung privater IP-Adressen zu einer Peering-Gruppe und SDP-Angebot-Antwort-Datenaustausch (Session Description Protocol) während der WebRTC-Signalisierung.

Sobald der Webdienst fertig ist, müssen Sie die Admin-Konsole so konfigurieren, dass eine On-premises service-Peering-Richtlinie verwendet wird, und die URL Ihres benutzerdefinierten Webdienstes angeben.

Voraussetzungen

Wenn Sie eine dieser Anforderungen für Ihre Organisation aktivieren möchten, wenden Sie sich an Ihren Google Workspace-Administrator:

  • Diese API kann auf jedem Webserver mit HTTPS implementiert werden.

  • Verwenden Sie HTTPS, um Fehler bei gemischten Inhalten zu vermeiden.

  • JSON-Daten akzeptieren und zurückgeben. Verwenden Sie eine beliebige Inhaltcodierung, die von Ihrem Browser unterstützt wird.

  • Stellen Sie Endpunkte unter einem Pfad vom Typ /vn bereit, wobei n die ausgewählte API-Version ist. Beispiel: /v1/get-peering-group.

  • Zuschauer von Meet-Livestreams können die URL Ihres Webdienstes über die Admin-Konsole von Google abrufen. Die URL kann global, pro Organisationseinheit oder pro Gruppe festgelegt werden. Zuschauer müssen eine Verbindung zu ihrer zugewiesenen Instanz des Dienstes herstellen können. Weitere Informationen finden Sie unter Admin-Konsole konfigurieren.

  • Ihr Dienst sollte innerhalb von zwei Sekunden eine Antwort zurückgeben. Andernfalls wird der eCDN-Client heruntergefahren und der Zuschauer sieht sich das Live-Ereignis weiterhin als normaler Nutzer ohne eCDN an. Dies verhindert Bandbreiteneinsparungen.

  • Ihr Dienst muss die folgenden CORS-Header (Cross-Origin Resource Sharing) festlegen:

    • Access-Control-Allow-Origin: meet.google.com
    • Access-Control-Allow-Headers: GET, POST, OPTIONS
    • Access-Control-Allow-Credentials: true

Private IP-Adressen einer Peering-Gruppe zuordnen

Der eCDN-Client sendet einen Aufruf jedes Mal, wenn er versucht, eine neue Verbindung zum eCDN-Tracker-Server herzustellen. Nachdem ein Gerät eine private IP-Adresse erkannt hat, muss die Adresse der richtigen Peering-Gruppe zugeordnet werden. Sie müssen die private IP-Adresse an einen Server in Ihrem Netzwerk senden und sie manuell mit der Methode get-peering-group() in eine Peering-Gruppe auflösen. In der Antwort wird eine Peering-Gruppen-ID zurückgegeben. Bei der Kommunikation mit Google wird die resultierende Peering-Gruppen-ID anstelle von privaten IP-Adressen übergeben.

So werden private IP-Adressen einer Peering-Gruppe zugeordnet.
Abbildung 1: Private IP-Adressen einer Peering-Gruppe zuordnen

Das folgende Codebeispiel zeigt, wie die Methode get-peering-group() aufgerufen wird, zusammen mit der möglichen Fehlerantwort und dem erwarteten Antworttext:

POST /v1/get-peering-group
Content-Type: application/json

Request body:
{
  "availableIPs": []{
    "format": "ipv4"|"ipv6",
    "address": "DETECTED_ADDRESS"
  }
}

Error response:
{
  "result": null,
  "error": "ERROR_MESSAGE",
}

Response body:
{
  "result": "PEERING_GROUP_ID",
  "error": null,
}

In der folgenden Tabelle sind die erwarteten Antwortformate aufgeführt:

HTTP-Status Fehler Peering-Gruppen-ID Reaktion des Kunden
200 null Nicht leerer String Der Client sollte in eine Peering-Gruppe sortiert werden und eine Verbindung zum eCDN-Tracker-Server herstellen.
200 NOT_FOUND null Der Client beendet die eCDN-Sitzung.
200 BLOCKED null Der Client beendet die eCDN-Sitzung.
200 Andere nicht leere Strings null Der Client beendet die eCDN-Sitzung.
302 (Gefunden) Der Client folgt der Weiterleitung zur neuen URL, die im Location-Header des Antworttexts angegeben ist.
Sonstige Statuscodes Beliebiger String Beliebiger String Der Client beendet die eCDN-Sitzung.

SDP-Angebots-Antwort-Datenaustausch

Um eine WebRTC-Verbindung zu initiieren, müssen Geräte ihre SDP-Angebote und ‑Antworten austauschen, einschließlich ICE-Kandidaten (Interactive Connectivity Establishment), die Informationen zu privaten IP-Adressen enthalten. Dies geschieht im Rahmen des WebRTC-Signalisierungsprozesses.

Clients müssen ihre ICE-Kandidaten innerhalb ihres Netzwerks mit der encrypt-sdp()-Methode über die Meet eCDN On-Premises API verschlüsseln. Bei dieser Methode wird ein Schlüssel verwendet, der Google niemals zugänglich gemacht wird. Das verschlüsselte SDP-Angebot wird dann über den eCDN-Tracker-Server an den Peer gesendet. Der Client-Peer entschlüsselt die empfangenen Informationen dann mit der decrypt-sdp()-Methode in seinem Netzwerk. Google leitet die Angebote und Antworten dann an die verbundenen Peers weiter.

Sobald die Verbindung über die Meet eCDN On-Premises API hergestellt wurde, funktioniert das eCDN wie gewohnt. Peers leiten Medien über das übliche Peering-Netzwerk und der Medientraffic wird nicht über die API geleitet oder verwendet.

Wie die SDP-Angebots- und Antwortdaten verschlüsselt und entschlüsselt werden.
Abbildung 2: Verschlüsseln und Entschlüsseln der SDP-Angebots- und Antwortdaten.

Das folgende Codebeispiel zeigt, wie die Methode encrypt-sdp() zusammen mit der potenziellen Fehlerantwort und dem erwarteten Antworttext aufgerufen wird:

POST /v1/encrypt-sdp
Content-Type: application/json

Request body:
{
  "data": "SDP_DATA" // raw SDP data
},

Error response:
{
  "result": null,
  "error": "ERROR_MESSAGE", // error message
}

Response body:
{
  "result": "ENCRYPTED_DATA_STRING", // encrypted data as string
  "error": null,
}

Das folgende Codebeispiel zeigt, wie die Methode decrypt-sdp() zusammen mit der potenziellen Fehlerantwort und dem erwarteten Antworttext aufgerufen wird:

POST /v1/decrypt-sdp
Content-Type: application/json

Request body:
{
  "data": "ENCRYPTED_DATA_STRING", // encrypted data as string (size limit: 1 MB)
},

Error response:
{
  "result": null,
  "error": "ERROR_MESSAGE", // error message
}

Response body:
{
  "result": "SDP_DATA" // raw SDP data
  "error": null,
}

In der folgenden Tabelle sind die erwarteten Antwortformate aufgeführt:

HTTP-Status Fehler Peering-Gruppen-ID Reaktion des Kunden
200 null Nicht leerer String Der Client erwartet, dass ordnungsgemäß codierte oder decodierte SDP-Daten verwendet werden.
200 Beliebiger nicht leerer String null Der Client beendet die eCDN-Sitzung.
302 (Gefunden) Der Client folgt der Weiterleitung zur neuen URL, die im Location-Header des Antworttexts angegeben ist.
Sonstige Statuscodes Beliebiger Wert Beliebiger Wert Der Client beendet die eCDN-Sitzung.

Admin-Konsole konfigurieren

Wenn Sie die Meet eCDN On-Premises API verwenden möchten, müssen Sie das eCDN in der Admin-Konsole so konfigurieren, dass die URL Ihres benutzerdefinierten Webdienstes enthalten ist.

Um das eCDN festzulegen, erstellen Sie eine Peering-Richtlinie mit On-premises service, um IP-Informationen manuell mit Peering-Gruppen abzugleichen. Sie können auch eine Portnummer angeben, wenn Sie nicht den Standardport 443 verwenden. Die URL muss das folgende Format haben: WEB_SERVICE.example.com:8080, wobei WEB_SERVICE der Name Ihres Webdienstes ist.

Weitere Informationen zum Festlegen einer Peering-Richtlinie finden Sie unter Netzwerkgruppierung konfigurieren.