Trabaja con la API de Meet eCDN On-Prem

En esta página, se explica cómo usar la API de la red de distribución de contenido (eCDN) de Google Meet Enterprise para las transmisiones en vivo de Google Meet.

La solución de API que se describe aquí permite a los clientes usar el conjunto completo de funciones de la eCDN de Meet sin exponer información de IP privada a Google. Puedes definir un nuevo servicio web local en tu propia red que pase un ID en lugar de la información de la dirección IP privada.

Descripción general de la eCDN de Meet

La eCDN está integrada en Meet y se inicia automáticamente durante las transmisiones en vivo después de que un administrador de Google Workspace la configura. Cuando la eCDN de Meet está activada, los usuarios de transmisiones en vivo dentro de una red local pueden compartir contenido multimedia transmitido en vivo con otros pares de la red a través del uso compartido de igual a igual (P2P). La mayoría de los dispositivos reciben el contenido multimedia transmitido en vivo de los pares cercanos y no necesitan recuperarlo de los servidores de Google. Esto reduce el ancho de banda total que usan los usuarios. Para obtener más información sobre cómo configurar y usar la eCDN de Meet, consulta Cómo organizar transmisiones en vivo numerosas.

La eCDN requiere que los usuarios de las transmisiones en vivo de Meet se ordenen en grupos de intercambio de datos. Un grupo de intercambio es un conjunto de nodos que pueden compartir contenido multimedia entre sí. Los dispositivos de un grupo de intercambio de información pueden establecer intercambio de información o se les bloquea esta función. Los dispositivos permitidos solo se pueden conectar a otros dispositivos del mismo grupo de intercambio de información. Para obtener más información sobre los grupos de intercambio de tráfico, consulta Antes de comenzar a alojar transmisiones en vivo grandes.

Cuándo usar la API

La eCDN puede formar grupos de intercambio de tráfico con varias políticas de intercambio de tráfico diferentes: random, subnet o custom rules. Este último comparte una tabla de rangos de red privada con el servidor de seguimiento de eCDN de Google para asignar las direcciones IP privadas de cada nodo de par a un grupo de intercambio de información. La política custom rules es la solución preferida y es adecuada para la mayoría de los entornos de producción.

Sin embargo, la política de custom rules requiere que compartas grandes porciones de la estructura de tu red privada con Google. Además, los usuarios individuales exponen sus direcciones IP privadas detectadas de forma local a Google cuando usan la eCDN. Es posible que los lineamientos de seguridad de algunas organizaciones no permitan compartir información de IP privada.

Desarrolla con la API de Meet eCDN On-Premises

La API de Meet eCDN On-Premises proporciona una especificación de servidor web que puedes implementar y alojar de forma local en la red de tu organización. Puedes compilar un servicio web personalizado que sea compatible con la API para realizar todas las tareas que dependen de la información de IP privada, de modo que la información no se comparta con Google.

La API abarca los dos pasos fundamentales para hacer coincidir las direcciones IP privadas que suele controlar el servidor de seguimiento de la eCDN: asignar direcciones IP privadas a un grupo de intercambio de tráfico y el intercambio de datos de oferta y respuesta del protocolo de descripción de sesión (SDP) durante la señalización de WebRTC.

Una vez que se complete el servicio web, debes configurar la Consola del administrador para usar una política de intercambio de On-premises service y, luego, incluir la URL de tu servicio web personalizado.

Requisitos

Si necesitas que se active alguno de estos requisitos para tu organización, pídele a tu administrador de Google Workspace que haga lo siguiente:

  • Cualquier servidor web que use HTTPS puede implementar esta API.

  • Usa HTTPS para evitar fallas de contenido mixto.

  • Acepta y muestra datos JSON. Usa cualquier codificación de contenido que admita tu navegador.

  • Publica extremos en una ruta /vn, en la que n es la versión de la API seleccionada. Por ejemplo, /v1/get-peering-group.

  • Los usuarios de transmisiones en vivo de Meet pueden obtener información sobre la URL de tu servicio web a través de la Consola del administrador de Google. La URL se puede configurar de forma global, por unidad organizativa o por grupo. Asegúrate de que los usuarios puedan conectarse a la instancia asignada del servicio. Para obtener más información, consulta Configura la Consola del administrador.

  • El servicio debería mostrar una respuesta en un plazo de dos segundos. De lo contrario, el cliente de la eCDN se cierra y el usuario continúa mirando el evento en vivo como un usuario normal que no usa la eCDN, lo que le niega cualquier ahorro de ancho de banda.

  • Tu servicio debe establecer los siguientes encabezados de uso compartido de recursos entre dominios (CORS):

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

Asigna direcciones IP privadas a un grupo de intercambio de tráfico

El cliente de la eCDN realiza una llamada cada vez que intenta volver a conectarse al servidor de seguimiento de la eCDN. Después de que un dispositivo detecta una dirección IP privada, esta se debe asignar al grupo de intercambio adecuado. Debes enviar la dirección IP privada a un servidor de tu red y resolverla de forma manual a un grupo de intercambio con el método get-peering-group(). En la respuesta, se muestra un ID de grupo de enrutamiento. Cuando te comunicas con Google, se pasa el ID de grupo de intercambio de tráfico resultante en lugar de las direcciones IP privadas.

Cómo se asignan las direcciones IP privadas a un grupo de intercambio
Figura 1. Asigna direcciones IP privadas a un grupo de intercambio de tráfico.

En el siguiente ejemplo de código, se muestra cómo llamar al método get-peering-group() junto con la posible respuesta de error y el cuerpo de respuesta esperado:

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

En la siguiente tabla, se muestran los formatos de respuesta esperados:

Estado de HTTP Error ID del grupo de intercambio de tráfico Reacción del cliente
200 null Cadena no vacía El cliente debe clasificarse en un grupo de intercambio de tráfico y debe conectarse al servidor de seguimiento de la eCDN.
200 NOT_FOUND null El cliente finaliza la sesión de la eCDN.
200 BLOCKED null El cliente finaliza la sesión de la eCDN.
200 Otra cadena no vacía null El cliente finaliza la sesión de la eCDN.
302 (Encontrado) El cliente sigue el redireccionamiento a la URL nueva especificada en el encabezado Location del cuerpo de la respuesta.
Cualquier otro código de estado Cualquier cadena Cualquier cadena El cliente finaliza la sesión de la eCDN.

Intercambio de datos de oferta y respuesta de SDP

Para iniciar una conexión WebRTC, los dispositivos deben intercambiar sus ofertas y respuestas de SDP, incluidos los candidatos de establecimiento de conectividad interactiva (ICE), que contienen información de IP privada. Lo hacen como parte del proceso de señalización de WebRTC.

Los clientes deben encriptar sus candidatos de ICE dentro de su red a través de la API de Meet eCDN On-Premises con el método encrypt-sdp(). El método usa una clave que nunca se expone a Google. Luego, la oferta SDP encriptada se envía al par con el servidor de seguimiento de la eCDN. Luego, el par cliente desencripta la información recibida dentro de su red con el método decrypt-sdp(). Luego, Google reenvía las ofertas y respuestas entre los pares conectados.

Una vez que se establece la conexión con la API de Meet eCDN On-Premises, la eCDN funciona de forma normal. Los pares enrutan el contenido multimedia a través de la red de intercambio habitual, y el tráfico de este contenido no pasa por la API ni la usa.

Cómo se encriptan y desencriptan los datos de la oferta y la respuesta de SDP
Figura 2. Encriptar y desencriptar los datos de oferta y respuesta de SDP

En la siguiente muestra de código, se muestra cómo llamar al método encrypt-sdp() junto con la posible respuesta de error y el cuerpo de respuesta esperado:

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

En la siguiente muestra de código, se muestra cómo llamar al método decrypt-sdp() junto con la posible respuesta de error y el cuerpo de respuesta esperado:

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

En la siguiente tabla, se muestran los formatos de respuesta esperados:

Estado de HTTP Error ID del grupo de intercambio de tráfico Reacción del cliente
200 null Cadena no vacía El cliente espera que se usen datos SDP codificados o decodificados correctamente.
200 Cualquier cadena que no esté vacía null El cliente finaliza la sesión de la eCDN.
302 (Encontrado) El cliente sigue el redireccionamiento a la URL nueva especificada en el encabezado Location del cuerpo de la respuesta.
Cualquier otro código de estado Cualquier valor Cualquier valor El cliente finaliza la sesión de la eCDN.

Configura la Consola del administrador

Para usar la API de eCDN de Meet local, debes configurar la eCDN en la Console del administrador para incluir la URL de tu servicio web personalizado.

Para configurar la eCDN, crea una política de intercambio de tráfico con On-premises service para hacer coincidir manualmente la información de IP con los grupos de intercambio de tráfico. También puedes incluir un número de puerto si no usas el 443 predeterminado. La URL debe coincidir con el siguiente formato: WEB_SERVICE.example.com:8080, donde WEB_SERVICE es el nombre de tu servicio web.

Para obtener más información sobre cómo configurar una política de intercambio de información, consulta Configura el agrupamiento de redes.