Trabaja con la API de Meet eCDN On-Prem

En esta página, se explica cómo usar la API de Google Meet Enterprise Content Delivery Network (eCDN) On-Premises para la transmisión en vivo de Google Meet.

La solución de API que se describe aquí permite que los clientes usen 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. Con la eCDN de Meet activada, los usuarios que miran transmisiones en vivo dentro de una red local pueden compartir contenido multimedia transmitido en vivo con otros usuarios de la red a través del uso compartido de usuario a usuario (P2P). La mayoría de los dispositivos reciben el contenido multimedia transmitido en vivo de usuarios 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 Organiza grandes transmisiones en vivo.

La eCDN requiere que los usuarios de la transmisión en vivo de Meet se ordenen en grupos de intercambio de tráfico. Un grupo de intercambio de tráfico es una colección de nodos que tienen permiso para compartir contenido multimedia entre sí. Los dispositivos de un grupo de intercambio de tráfico pueden tener permiso para el intercambio de tráfico o estar bloqueados para este. Los dispositivos permitidos solo pueden conectarse a otros dispositivos del mismo grupo de intercambio de tráfico. Para obtener más información sobre los grupos de intercambio de tráfico, consulta Antes de organizar grandes transmisiones en vivo en directo.

Cuándo usar la API

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

Sin embargo, la política custom rules requiere que compartas grandes partes 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 mientras usan la eCDN. En algunas organizaciones, es posible que sus lineamientos de seguridad no permitan compartir información de IP privada.

Desarrolla con la API de eCDN On-Premises para Meet

La API de eCDN On-Premises para Meet 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 sesiones (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 tráfico 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, comunícate con el administrador de Google Workspace:

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

  • Usa HTTPS para evitar errores de contenido mixto.

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

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

  • Los usuarios de la transmisión 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 su instancia asignada del servicio. Para obtener más información, consulta Configura la Consola del administrador.

  • Tu servicio debe 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, la dirección debe asignarse al grupo de intercambio de tráfico adecuado. Debes enviar la dirección IP privada a un servidor de tu red y resolverla de forma manual en un grupo de intercambio de tráfico con el método get-peering-group(). Se muestra un ID de grupo de intercambio de tráfico en la respuesta. Cuando se comunica 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 peering
Figura 1. Asignación de 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:
{
  "allowed": boolean,
  "result": string,
  "error": null
}

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

Estado de HTTP Error Permitido Resultado Reacción del cliente
200 null verdadero Cadena no vacía El cliente se ordena en el grupo de intercambio de tráfico especificado y procede a conectarse al servidor de seguimiento de la eCDN.
200 null falso Cadena no vacía El cliente se marca como bloqueado por el grupo de intercambio de tráfico especificado, estará visible en la herramienta de calidad de Meet (MQT) y finalizará la sesión de la eCDN.
200 null Cadena vacía El cliente finaliza la sesión de la eCDN.
200 Cadena no vacía El cliente finaliza la sesión de la eCDN.
302 (Encontrado) El cliente sigue el redireccionamiento a la nueva URL especificada en el encabezado Location del cuerpo de la respuesta.
Cualquier otro código de estado El cliente finaliza la sesión de la eCDN.

Formato de respuesta heredado

El campo allowed no formaba parte del formato de respuesta de las versiones anteriores. En cambio, los valores reservados especiales para result determinarían si se bloquearía la dirección IP de un usuario para el intercambio de tráfico:

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

En la siguiente tabla, se muestran los formatos de respuesta esperados si el campo allowed no está configurado en el mensaje de respuesta:

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

Intercambio de datos de oferta y respuesta del SDP

Para iniciar una conexión WebRTC, los dispositivos deben intercambiar sus ofertas y respuestas del SDP, incluidos los candidatos de Interactive Connectivity Establishment (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 eCDN On-Premises para Meet con el método encrypt-sdp(). El método usa una clave que nunca se expone a Google. Luego, la oferta del SDP encriptada se envía al usuario con el servidor de seguimiento de la eCDN. Luego, el usuario 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 usuarios conectados.

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

Cómo se encriptan y desencriptan los datos de oferta y respuesta del SDP
Figura 2. Encriptación y desencriptación de los datos de oferta y respuesta del SDP

En el siguiente ejemplo 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"
},

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

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

En el siguiente ejemplo 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"
},

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

Response body:
{
  "result": "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 del SDP codificados o decodificados correctamente.
200 Cualquier cadena no vacía null El cliente finaliza la sesión de la eCDN.
302 (Encontrado) El cliente sigue el redireccionamiento a la nueva URL 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 On-Premises para Meet, debes configurar la eCDN en la Consola 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 de forma manual 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 tráfico, consulta Configura la agrupación de redes.