Meet eCDN On-Prem API verwenden

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

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

Meet eCDN – Übersicht

eCDN ist in Meet integriert und wird bei 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 P2P-Freigabe mit anderen Nutzern im Netzwerk teilen. Die meisten Geräte empfangen die live gestreamten Medien von Geräten in der Nähe und müssen sie nicht von den Google-Servern abrufen. Dadurch wird die von Zuschauern verwendete Gesamtbandbreite reduziert. Weitere Informationen zum Einrichten und Verwenden von Meet eCDN finden Sie unter Große Livestreams hosten.

Für eCDN müssen Zuschauer von Meet-Livestreams in Peering-Gruppen eingeteilt werden. Eine Peering-Gruppe ist eine Sammlung 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 nur eine Verbindung zu anderen Geräten in derselben Peering-Gruppe herstellen. Weitere Informationen zu Peering-Gruppen finden Sie unter Vorbereitung.

Wann sollte die API verwendet werden?

eCDN kann Peering-Gruppen mit 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 jedes Peer-Knotens 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 mit Google teilen. Außerdem geben einzelne Nutzer ihre lokal erkannten privaten IP-Adressen an Google weiter, wenn sie eCDN verwenden. Bei einigen Organisationen ist es aufgrund ihrer Sicherheitsrichtlinien möglicherweise nicht zulässig, private IP-Informationen weiterzugeben.

Mit der Meet eCDN On-Premises API entwickeln

Die Meet eCDN On-Premises API bietet eine Webspezifikation, die Sie implementieren und lokal im Netzwerk Ihrer Organisation 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. So werden die Informationen nicht an Google weitergegeben.

Die API umfasst die beiden kritischen Schritte für den Abgleich privater IP-Adressen, die normalerweise vom eCDN-Tracker-Server ausgeführt werden: Private IP-Adressen einer Peering-Gruppe zuordnen und SDP-Angebot-Antwort-Datenaustausch während der WebRTC-Signalisierung.

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

Voraussetzungen

Wenn Sie eine dieser Anforderungen für Ihre Organisation aktivieren müssen, bitten Sie Ihren Google Workspace-Administrator, Folgendes zu tun:

  • Diese API kann auf jedem Webserver implementiert werden, der HTTPS verwendet.

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

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

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

  • Zuschauer von Meet-Livestreams können die URL Ihres Webservices über die Google Admin-Konsole aufrufen. Die URL kann global, pro Organisationseinheit oder pro Gruppe festgelegt werden. Prüfe, ob Zuschauer 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-Event als normaler Nutzer ohne eCDN an, wodurch keine Bandbreite eingespart wird.

  • 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 führt jedes Mal einen Aufruf aus, wenn er versucht, die Verbindung zum eCDN-Tracker-Server wiederherzustellen. 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 mit der Methode get-peering-group() manuell 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.

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

Das folgende Codebeispiel zeigt, wie die Methode get-peering-group() aufgerufen wird, sowie die potenzielle Fehlerantwort und den 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 ID der Peering-Gruppe Clientreaktion
200 null Nicht leerer String Der Client sollte in eine Peering-Gruppe eingeordnet werden und dann eine Verbindung zum eCDN-Tracker-Server herstellen.
200 null NOT_FOUND Der Client beendet die eCDN-Sitzung.
200 null BLOCKED Der Client beendet die eCDN-Sitzung.
200 Anderer 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.
Beliebiger anderer Statuscode Beliebiger String Beliebiger String Der Client beendet die eCDN-Sitzung.

SDP-Angebot/Antwort-Datenaustausch

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

Clients müssen ihre ICE-Kandidaten in ihrem Netzwerk über die Meet eCDN On-Premises API mit der Methode encrypt-sdp() verschlüsseln. Bei der 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 in seinem Netzwerk mit der decrypt-sdp()-Methode. Google leitet die Angebote und Antworten dann zwischen den 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 weiter. Der Media-Traffic wird nicht über die API weitergeleitet oder verwendet sie.

Wie die SDP-Offer- und -Answer-Daten verschlüsselt und entschlüsselt werden.
Abbildung 2: Verschlüsseln und Entschlüsseln der SDP-Offer- und -Answer-Daten.

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 ID der Peering-Gruppe Clientreaktion
200 null Nicht leerer String Der Client erwartet, dass korrekt 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.
Beliebiger anderer Statuscode 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 Webservices 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 sollte dem folgenden Format entsprechen: 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.