Utilizzare l'API Meet eCDN on-premise

Questa pagina spiega come utilizzare l'API on-premise della rete CDN (Content Delivery Network) aziendale di Google Meet per il live streaming di Google Meet.

La soluzione API descritta qui consente ai clienti di utilizzare l'intera gamma di funzionalità della CDN di Meet senza esporre a Google informazioni sull'IP privato. Puoi definire un nuovo servizio web on-premise nella tua rete che trasmette un ID anziché le informazioni sull'indirizzo IP privato.

Panoramica di Meet eCDN

L'eCDN è integrata in Meet e si avvia automaticamente durante i live streaming dopo che è stata configurata da un amministratore Google Workspace. Quando l'eCDN Meet è attiva, gli spettatori del live streaming all'interno di una rete locale possono condividere contenuti multimediali in live streaming con altre app peer della rete tramite la condivisione peer-to-peer (P2P). La maggior parte dei dispositivi riceve i contenuti multimediali in live streaming da peer nelle vicinanze e non deve recuperarli dai server di Google. In questo modo si riduce la larghezza di banda totale utilizzata dagli spettatori. Per ulteriori informazioni sulla configurazione e l'utilizzo di eCDN di Meet, consulta Hosting di live streaming di grandi dimensioni.

eCDN richiede che gli spettatori di Meet Live Streaming siano raggruppati in gruppi di peering. Un gruppo di peering è una raccolta di nodi autorizzati a condividere contenuti multimediali tra loro. I dispositivi di un gruppo di peering possono essere autorizzati a eseguire il peering o bloccati. I dispositivi consentiti possono connettersi solo ad altri dispositivi nello stesso gruppo di peering. Per ulteriori informazioni sui gruppi di peering, vedi Prima di iniziare a ospitare live streaming di grandi dimensioni.

Quando utilizzare l'API

eCDN può formare gruppi di peering utilizzando diverse norme di peering: random, subnet o custom rules. Quest'ultimo condivide una tabella di intervalli di rete privati con il server di monitoraggio eCDN di Google per mappare gli indirizzi IP privati di ogni nodo peer a un gruppo di peering. Le norme custom rules sono la soluzione preferita e sono adatte alla maggior parte degli ambienti di produzione.

Tuttavia, le norme custom rules richiedono di condividere con Google ampie porzioni della struttura della tua rete privata. Inoltre, i singoli utenti espongono a Google i propri indirizzi IP privati rilevati localmente durante l'utilizzo di eCDN. Per alcune organizzazioni, le linee guida per la sicurezza potrebbero non consentire la condivisione di informazioni sull'IP privato.

Sviluppare con l'API Meet eCDN On-Premises

L'API Meet eCDN On-Premises fornisce una specifica del server web che puoi implementare e ospitare localmente nella rete della tua organizzazione. Puoi creare un servizio web personalizzato compatibile con l'API per eseguire tutte le attività che dipendono dalle informazioni sull'IP privato, in modo che queste non vengano condivise con Google.

L'API comprende i due passaggi fondamentali per la corrispondenza degli indirizzi IP privati che in genere vengono gestiti dal server di monitoraggio eCDN: mappare gli indirizzi IP privati a un gruppo di peering e scambio di dati offerta-risposta del Session Description Protocol (SDP) durante la segnalazione WebRTC.

Una volta completato il servizio web, devi configurare la Console di amministrazione per utilizzare un criterio di peering On-premises service e includere l'URL del tuo servizio web personalizzato.

Requisiti

Se devi attivare uno di questi requisiti per la tua organizzazione, chiedi al tuo amministratore di Google Workspace:

  • Qualsiasi server web che utilizza HTTPS può implementare questa API.

  • Utilizza HTTPS per evitare errori relativi ai contenuti misti.

  • Accetta e restituisce dati JSON. Utilizza qualsiasi codifica dei contenuti supportata dal tuo browser.

  • Servi gli endpoint in una route /vn dove n è la versione dell'API selezionata. Ad esempio /v1/get-peering-group.

  • Gli spettatori di Meet Live Streaming possono scoprire l'URL del tuo servizio web tramite la Console di amministrazione Google. L'URL può essere impostato a livello globale, per unità organizzativa o per gruppo. Assicurati che gli spettatori possano connettersi all'istanza assegnata del servizio. Per ulteriori informazioni, vedi Configurare la Console di amministrazione.

  • Il servizio deve restituire una risposta entro due secondi. In caso contrario, il client eCDN si chiude e lo spettatore continua a guardare l'evento live come utente normale, non eCDN, negandogli qualsiasi risparmio di larghezza di banda.

  • Il servizio deve impostare le seguenti intestazioni CORS (Cross-Origin Resource Sharing):

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

Mappare gli indirizzi IP privati a un gruppo di peering

Il client eCDN effettua una chiamata ogni volta che tenta di riconnettersi al server di monitoraggio eCDN. Dopo che un dispositivo rileva un indirizzo IP privato, questo deve essere mappato al gruppo di peering corretto. Devi inviare l'indirizzo IP privato a un server sulla tua rete e risolverlo manualmente in un gruppo di peering utilizzando il metodo get-peering-group(). Nella risposta viene restituito un ID gruppo di peering. Quando comunichi con Google, viene trasmesso l'ID gruppo di peering risultante anziché gli indirizzi IP privati.

Come vengono mappati gli indirizzi IP privati a un gruppo di peering.
Figura 1. Mappatura degli indirizzi IP privati a un gruppo di peering.

Il seguente esempio di codice mostra come chiamare il metodo get-peering-group() insieme alla potenziale risposta di errore e al corpo della risposta previsto:

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

La tabella seguente mostra i formati di risposta previsti:

Stato HTTP Errore ID gruppo di peering Reazione del cliente
200 null Stringa non vuota Il client deve essere ordinato in un gruppo di peering e procede alla connessione al server di monitoraggio eCDN.
200 null NOT_FOUND Il client termina la sessione eCDN.
200 null BLOCKED Il client termina la sessione eCDN.
200 Altra stringa non vuota null Il client termina la sessione eCDN.
302 (Trovato) Il client segue il reindirizzamento al nuovo URL specificato nell'intestazione Location del corpo della risposta.
Qualsiasi altro codice di stato Qualsiasi stringa Qualsiasi stringa Il client termina la sessione eCDN.

Scambio di dati offerta/risposta SDP

Per avviare una connessione WebRTC, i dispositivi devono scambiarsi le offerte e le risposte SDP, inclusi i candidati ICE (Interactive Connectivity Establishment), che contengono informazioni sull'IP privato. Lo fanno nell'ambito della procedura di segnalazione WebRTC.

I client devono criptare i propri candidati ICE all'interno della rete tramite l'API Meet eCDN on-premise, utilizzando il metodo encrypt-sdp(). Il metodo utilizza una chiave che non viene mai esposta a Google. L'offerta SDP criptata viene quindi inviata al peer utilizzando il server di monitoraggio della eCDN. Il peer client decripta le informazioni ricevute all'interno della sua rete utilizzando il metodo decrypt-sdp(). Google inoltra poi le offerte e le risposte tra i peer connessi.

Una volta stabilita la connessione utilizzando l'API eCDN Meet on-premise, l'eCDN funziona normalmente. I peer instradano i contenuti multimediali attraverso la normale rete di peering e il traffico multimediale non passa attraverso o utilizza l'API.

Come vengono criptati e decriptati i dati di offerta e risposta SDP.
Figura 2. Crittografia e decriptazione dei dati di offerta e risposta SDP.

Il seguente esempio di codice mostra come chiamare il metodo encrypt-sdp() insieme alla potenziale risposta di errore e al corpo della risposta previsto:

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

Il seguente esempio di codice mostra come chiamare il metodo decrypt-sdp() insieme alla potenziale risposta di errore e al corpo della risposta previsto:

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

La tabella seguente mostra i formati di risposta previsti:

Stato HTTP Errore ID gruppo di peering Reazione del cliente
200 null Stringa non vuota Il client si aspetta che vengano utilizzati dati SDP codificati o decodificati correttamente.
200 Qualsiasi stringa non vuota null Il client termina la sessione eCDN.
302 (Trovato) Il client segue il reindirizzamento al nuovo URL specificato nell'intestazione Location del corpo della risposta.
Qualsiasi altro codice di stato Qualsiasi valore Qualsiasi valore Il client termina la sessione eCDN.

Configurare la Console di amministrazione

Per utilizzare l'API eCDN Meet on-premise, devi configurare l'eCDN nella Console di amministrazione in modo da includere l'URL del tuo servizio web personalizzato.

Per impostare la eCDN, crea un criterio di peering utilizzando On-premises service per abbinare manualmente le informazioni sull'IP ai gruppi di peering. Puoi anche includere un numero di porta se non utilizzi la porta predefinita 443. L'URL deve corrispondere al seguente formato: WEB_SERVICE.example.com:8080, dove WEB_SERVICE è il nome del tuo servizio web.

Per ulteriori informazioni sull'impostazione di una policy di peering, consulta Configurare il raggruppamento di reti.