Praca z interfejsem eCDN w Meet na potrzeby wdrażania lokalnego

Z tej strony dowiesz się, jak korzystać z interfejsu API Google Meet Enterprise Content Delivery Network (eCDN) On-Premises do strumieniowego przesyłania danych w Google Meet.

Opisane tutaj rozwiązanie interfejsu API umożliwia klientom korzystanie z pełnego zestawu funkcji eCDN w Meet bez ujawniania Google prywatnych informacji o adresie IP. Możesz zdefiniować nową usługę internetową na potrzeby firmy w swojej sieci, która przekazuje identyfikator zamiast prywatnych informacji o adresie IP.

Omówienie eCDN w Meet

Sieć eCDN jest wbudowana w Meet i po skonfigurowaniu przez administratora Google Workspace uruchamia się automatycznie podczas transmisji na żywo. Gdy sieć eCDN w Meet jest włączona, widzowie transmisji na żywo z sieci lokalnej mogą udostępniać transmitowane na żywo multimedia innym osobom w tej sieci za pomocą udostępniania peer-to-peer (P2P). Większość urządzeń będzie otrzymywać transmitowane na żywo multimedia od osób w tej samej sieci, które znajdują się w pobliżu, i nie będzie musiało pobierać ich z serwerów Google. Zmniejsza to łączną przepustowość wykorzystywaną przez widzów. Więcej informacji o konfigurowaniu i korzystaniu z eCDN w Meet znajdziesz w artykule Hostowanie dużych transmisji na żywo.

Sieć eCDN wymaga, aby widzowie transmisji na żywo w Meet byli przydzielani do grup peer-to-peer. Grupa połączeń równorzędnych to zbiór węzłów, które mogą udostępniać sobie multimedia. Urządzenia w grupie połączeń równorzędnych mogą nawiązywać połączenia równorzędne lub mają tę możliwość zablokowaną. Dozwolone urządzenia mogą łączyć się tylko z innymi urządzeniami w tej samej grupie połączeń równorzędnych. Więcej informacji o grupach peeringowych znajdziesz w artykule Kroki do wykonania przed hostowaniem dużych transmisji na żywo.

Kiedy używać interfejsu API

Sieć eCDN może tworzyć grupy połączeń równorzędnych, korzystając z kilku różnych zasad połączenia równorzędnego: random, subnet lub custom rules. Ten drugi udostępnia tabelę zakresów prywatnych sieci z serwerem śledzącym eCDN Google, aby mapować prywatne adresy IP każdego węzła równorzędnego na grupę równorzędną. Zasady custom rules są preferowanym rozwiązaniem i są odpowiednie w większości środowisk produkcyjnych.

Jednak zgodnie z zasadami custom rules musisz udostępnić Google dużą część struktury sieci prywatnej. Dodatkowo poszczególni użytkownicy, korzystając z eCDN, udostępniają Google swoje prywatne adresy IP wykryte lokalnie. W przypadku niektórych organizacji ich wytyczne dotyczące bezpieczeństwa mogą nie zezwalać na udostępnianie prywatnych adresów IP.

Tworzenie aplikacji z interfejsem eCDN na potrzeby Meet w środowisku lokalnym

Interfejs API eCDN na potrzeby Meet w środowisku lokalnym udostępnia specyfikację serwera WWW, którą możesz zaimplementować i hostować lokalnie w sieci organizacji. Możesz utworzyć niestandardową usługę internetową, która będzie zgodna z interfejsem API, aby wykonywać wszystkie zadania zależne od prywatnych informacji IP, tak aby te informacje nie były udostępniane Google.

Interfejs API obejmuje 2 kluczowe kroki dopasowywania prywatnych adresów IP, które są zwykle obsługiwane przez serwer śledzenia eCDN: mapowanie prywatnych adresów IP na grupę równorzędną oraz wymiana danych w ramach protokołu SDP (Session Description Protocol) w formie oferty i odpowiedzi podczas sygnalizacji WebRTC.

Gdy usługa internetowa będzie gotowa, musisz skonfigurować konsolę administracyjną, aby używać zasad peeringu On-premises service i uwzględnić adres URL niestandardowej usługi internetowej.

Wymagania

Jeśli chcesz włączyć te wymagania w swojej organizacji, poproś o to administratora Google Workspace:

  • Ten interfejs API może być implementowany na dowolnym serwerze internetowym korzystającym z HTTPS.

  • Aby uniknąć problemów z treścią mieszaną, używaj protokołu HTTPS.

  • Przyjmować i zwracać dane w formacie JSON. Użyj dowolnego kodowania treści obsługiwanego przez przeglądarkę.

  • Udostępniaj punkty końcowe w ramach trasy /vn, gdzie n to wybrana wersja interfejsu API. Na przykład: /v1/get-peering-group.

  • Widzowie transmisji na żywo w Google Meet mogą dowiedzieć się o adresie URL Twojej usługi internetowej w konsoli administracyjnej Google. Adres URL można skonfigurować globalnie, w przypadku konkretnej jednostki organizacyjnej lub grupy. Zadbaj o to, aby widzowie mogli połączyć się z przypisaną instancją usługi. Więcej informacji znajdziesz w artykule Konfigurowanie konsoli administracyjnej.

  • Usługa powinna zwrócić odpowiedź w ciągu 2 sekund. W przeciwnym razie klient eCDN zostanie zamknięty, a widz będzie nadal oglądać wydarzenie na żywo jako zwykły użytkownik, nie korzystający z eCDN, co uniemożliwi mu zaoszczędzenie przepustowości.

  • Usługa musi ustawić te nagłówki CORS:

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

Mapowanie prywatnych adresów IP na grupę peeringową

Klient eCDN wysyła wywołanie za każdym razem, gdy próbuje nawiązać ponowne połączenie z serwerem śledzenia eCDN. Gdy urządzenie wykryje prywatny adres IP, musi go przypisać do odpowiedniej grupy peeringu. Musisz wysłać prywatny adres IP do serwera w swojej sieci i ręcznie przetłumaczyć go na grupę równorzędną za pomocą metody get-peering-group(). W odpowiedzi zwracany jest identyfikator grupy peeringowej. Podczas komunikacji z Google zamiast prywatnych adresów IP przekazywany jest identyfikator grupy peeringowej.

Jak prywatne adresy IP są mapowane na grupę peeringową.
Rysunek 1. Mapowanie prywatnych adresów IP na grupę peeringową.

Ten przykładowy kod pokazuje, jak wywołać metodę get-peering-group(), wraz z potencjalną odpowiedzią na błąd i oczekiwanym tekstem odpowiedzi:

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,
}

Poniższa tabela przedstawia oczekiwane formaty odpowiedzi:

Stan HTTP Błąd Identyfikator grupy połączenia równorzędnego Reakcja klienta
200 brak Niepusty ciąg znaków Klient powinien zostać przypisany do grupy peeringowej i nawiązać połączenie z serwerem śledzenia eCDN.
200 NOT_FOUND brak Klient kończy sesję eCDN.
200 BLOCKED brak Klient kończy sesję eCDN.
200 Inny niepusty ciąg znaków brak Klient kończy sesję eCDN.
302 (znaleziono) Klient podąża za przekierowaniem do nowego adresu URL podanego w nagłówku Location w ciele odpowiedzi.
Inny kod stanu dowolny ciąg znaków. dowolny ciąg znaków. Klient kończy sesję eCDN.

Wymiana danych w ramach usługi SDP dotyczącej ofert i odpowiedzi

Aby zainicjować połączenie WebRTC, urządzenia muszą wymienić oferty i odpowiedzi SDP, w tym kandydatów do interakcji z usługą ICE, które zawierają prywatne informacje o adresach IP. Dzieje się tak w ramach procesu sygnalizacji WebRTC.

Klienci muszą szyfrować kandydatów ICE w swojej sieci za pomocą interfejsu API Meet eCDN On-Premises, używając metody encrypt-sdp(). Metoda używa klucza, który nigdy nie jest udostępniany Google. Zaszyfrowana oferta SDP jest następnie wysyłana do peera za pomocą serwera śledzenia eCDN. Następnie klient odszyfrowuje otrzymane informacje w swojej sieci za pomocą metody decrypt-sdp(). Następnie Google przekazuje oferty i odpowiedzi między połączonymi urządzeniami.

Po nawiązaniu połączenia za pomocą interfejsu API eCDN w Meet w środowisku lokalnym eCDN działa normalnie. Peers kieruje multimedia przez zwykłą sieć równorzędną, a ruch multimedialny nie przechodzi przez interfejs API ani z niego nie korzysta.

Sposób szyfrowania i odszyfrowywania danych oferty i odpowiedzi SDP.
Rysunek 2. szyfrowanie i odszyfrowywanie danych oferty i odpowiedzi SDP;

Poniższy przykładowy kod pokazuje, jak wywołać metodę encrypt-sdp(), wraz z potencjalną odpowiedzią z błędem i oczekiwanym tekstem odpowiedzi:

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,
}

Poniższy przykładowy kod pokazuje, jak wywołać metodę decrypt-sdp(), wraz z potencjalną odpowiedzią z błędem i oczekiwanym tekstem odpowiedzi:

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,
}

Poniższa tabela przedstawia oczekiwane formaty odpowiedzi:

Stan HTTP Błąd Identyfikator grupy połączenia równorzędnego Reakcja klienta
200 brak Niepusty ciąg znaków Klient oczekuje, że będą używane prawidłowo zakodowane lub zdekodowane dane SDP.
200 dowolny niepusty ciąg znaków, brak Klient kończy sesję eCDN.
302 (znaleziono) Klient podąża za przekierowaniem do nowego adresu URL podanego w nagłówku Location w ciele odpowiedzi.
Inny kod stanu Dowolna wartość Dowolna wartość Klient kończy sesję eCDN.

Konfigurowanie konsoli administracyjnej

Aby korzystać z interfejsu eCDN w Meet na potrzeby firmy, musisz skonfigurować eCDN w konsoli administracyjnej, aby uwzględnić adres URL niestandardowej usługi internetowej.

Aby skonfigurować eCDN, utwórz zasadę połączenia równorzędnego za pomocą On-premises service, aby ręcznie dopasować informacje o adresie IP do grup połączeń równorzędnych. Możesz też podać numer portu, jeśli nie używasz domyślnego portu 443. Adres URL powinien mieć format WEB_SERVICE.example.com:8080, gdzie WEB_SERVICE to nazwa usługi internetowej.

Więcej informacji o konfigurowaniu zasad peeringu znajdziesz w artykule Konfigurowanie grupowania sieci.