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 das volle Feature-Set von Meet eCDN nutzen, ohne Google private IP-Informationen zur Verfügung zu stellen. Sie können in Ihrem eigenen Netzwerk einen neuen lokalen Webdienst definieren, der eine ID anstelle der privaten IP-Adresse weitergibt.

Übersicht über Meet eCDN

eCDN ist in Meet integriert und wird während Livestreams automatisch gestartet, nachdem es von einem Google Workspace-Administrator eingerichtet wurde. Wenn Meet eCDN aktiviert ist, können Zuschauer von Livestreams in einem lokalen Netzwerk über Peer-to-Peer-Freigabe (P2P) live gestreamte Medien mit anderen Nutzern im Netzwerk teilen. Die meisten Geräte empfangen die live gestreamten Medien von Nutzern in der Nähe und müssen sie nicht von den Google-Servern abrufen. Dadurch wird die von den 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. Zulässige 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 auf das Hosten großer Live streams.

Wann sollte die API verwendet werden?

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

Die Richtlinie custom rules erfordert jedoch, dass Sie 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 lassen die Sicherheitsrichtlinien die Weitergabe privater IP-Informationen möglicherweise nicht zu.

Mit der Meet eCDN On-Premises API entwickeln

Die Meet eCDN On-Premises API bietet eine Webserverspezifikation, 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 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 (Session Description Protocol) während der WebRTC-Signalisierung.

Nachdem 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 Voraussetzungen für Ihre Organisation aktivieren müssen, wenden Sie sich an Ihren Google Workspace-Administrator:

  • Jeder Webserver, der HTTPS verwendet, kann diese API implementieren.

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

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

  • Endpunkte unter einer /vn-Route bereitstellen, 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 abrufen. Die URL kann global, pro Organisationseinheit oder pro Gruppe festgelegt werden. Achten Sie darauf, dass 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 er keine Bandbreite einsparen kann.

  • 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, eine 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 mit der Methode get-peering-group() manuell einer Peering-Gruppe zuordnen. In der Antwort wird eine Peering-Gruppen-ID zurückgegeben. Bei der Kommunikation mit Google wird anstelle von privaten IP-Adressen die resultierende Peering-Gruppen-ID übergeben.

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

Im folgenden Codebeispiel wird gezeigt, wie Sie die Methode get-peering-group() zusammen mit der potenziellen Fehlerantwort und dem erwarteten Antworttext aufrufen:

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:
{
  "allowed": boolean,
  "result": string,
  "error": null
}

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

HTTP-Status Fehler Zulässig Ergebnis Clientreaktion
200 null wahr Nicht leerer String Der Client wird der angegebenen Peering-Gruppe zugeordnet und stellt eine Verbindung zum eCDN-Tracker-Server her.
200 null falsch Nicht leerer String Der Client wird von der angegebenen Peering-Gruppe als blockiert markiert, ist in the Meet Quality Tool (MQT) sichtbar und beendet die eCDN-Sitzung.
200 null Leerer String Der Client beendet die eCDN-Sitzung.
200 Nicht leerer String 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 Der Client beendet die eCDN-Sitzung.

Legacy-Antwortformat

Das Feld allowed war nicht Teil des Antwortformats früherer Versionen. Stattdessen wurde mit speziellen reservierten Werten für result festgelegt, ob die IP-Adresse eines Zuschauers für das Peering blockiert werden sollte:

Legacy response body:
{
  "result": string,
  "error": null,
}

In der folgenden Tabelle sind die erwarteten Antwortformate aufgeführt, wenn das Feld allowed in der Antwortnachricht nicht festgelegt ist:

HTTP-Status Fehler Ergebnis Clientreaktion
200 null Nicht leerer String Der Client sollte einer Peering-Gruppe zugeordnet werden und stellt eine Verbindung zum eCDN-Tracker-Server her.
200 null NOT_FOUND Der Client beendet die eCDN-Sitzung.
200 null BLOCKED Der Client beendet die eCDN-Sitzung.
200 Nicht leerer String 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 Der Client beendet die eCDN-Sitzung.

SDP-Angebot-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 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. Die Methode verwendet einen Schlüssel, der Google nie zur Verfügung gestellt 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 Methode decrypt-sdp(). Google leitet die Angebote und Antworten dann zwischen den verbundenen Peers weiter.

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

Wie die SDP-Offer- und -Answer-Daten verschlüsselt und entschlüsselt werden.
Abbildung 2 : SDP-Angebots- und -Antwortdaten verschlüsseln und entschlüsseln.

Im folgenden Codebeispiel wird gezeigt, wie Sie die Methode encrypt-sdp() zusammen mit der potenziellen Fehlerantwort und dem erwarteten Antworttext aufrufen:

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

Request body:
{
  "data": "SDP_DATA"
},

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

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

Im folgenden Codebeispiel wird gezeigt, wie Sie die Methode decrypt-sdp() zusammen mit der potenziellen Fehlerantwort und dem erwarteten Antworttext aufrufen:

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

Request body:
{
  "data": "ENCRYPTED_DATA_STRING"
},

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

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

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

HTTP-Status Fehler Peering-Gruppen-ID Clientreaktion
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.
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 eCDN in der Admin-Konsole so konfigurieren, dass die URL von Ihrem benutzerdefinierten Webdienst enthalten ist.

Um eCDN festzulegen, erstellen Sie eine Peering-Richtlinie mit On-premises service, um IP-Informationen manuell Peering-Gruppen zuzuordnen. 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 Netzwerk gruppieren.