Trabaja con la API de Meet eCDN On-Prem

En esta página, se explica cómo usar la API de red de distribución de contenido empresarial (eCDN) On-Premises de Google Meet para la transmisión 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 privada de IP 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 Meet eCDN

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 en una red local pueden compartir contenido multimedia transmitido en vivo con otros usuarios 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 dispositivos similares 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 la transmisión en vivo de Meet se ordenen en grupos de pares. Un grupo de peers es una colección de nodos que tienen permiso para compartir contenido multimedia entre sí. Los dispositivos de un grupo de vinculación pueden vincularse o no. Los dispositivos permitidos solo pueden conectarse a otros dispositivos del mismo grupo de vinculación. Para obtener más información sobre los grupos de intercambio de tráfico, consulta Antes de comenzar a transmitir en vivo eventos grandes.

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. Este último comparte una tabla de rangos de redes privadas con el servidor de seguimiento de la CDN externa de Google para asignar las direcciones IP privadas de cada nodo de par a un grupo de pares. La política de 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 localmente a Google mientras usan la eCDN. En el caso de algunas organizaciones, sus lineamientos de seguridad pueden no permitir el uso compartido de información de IP privada.

Desarrolla con la API de eCDN On-Premises para Meet

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 esta información no se comparta con Google.

La API abarca los dos pasos críticos para la correlación de direcciones IP privadas que, por lo general, maneja el servidor de seguimiento de la eCDN: correlacionar direcciones IP privadas con 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 que use una política de vinculación de On-premises service y que incluya la URL de tu servicio web personalizado.

Requisitos

Si necesitas que se activen algunos de estos requisitos para tu organización, pídele al administrador de Google Workspace que lo haga:

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

  • Usa HTTPS para evitar errores de contenido mixto.

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

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

  • Los usuarios que miran 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.

  • Tu servicio debería devolver una respuesta en un plazo de dos segundos. De lo contrario, el cliente de la eCDN se cierra y el usuario sigue mirando el evento en vivo como un usuario normal, no de 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 CDN externa realiza una llamada cada vez que intenta volver a conectarse al servidor de seguimiento de la CDN externa. Después de que un dispositivo detecta una dirección IP privada, esta debe asignarse al grupo de interconexión adecuado. Debes enviar la dirección IP privada a un servidor de tu red y resolverla manualmente en un grupo de intercambio de tráfico mediante el método get-peering-group(). En la respuesta, se muestra un ID de grupo de vinculación. Cuando se comunica con Google, se pasa el ID del 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. 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 proceder 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 Otra 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 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 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 a 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 de SDP encriptada se envía al par a través del 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 las respuestas entre los pares conectados.

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

Cómo se encriptan y desencriptan los datos de oferta y respuesta del SDP
Figura 2. Encriptar y desencriptar los datos de la oferta y la 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 de 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 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 de 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 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 puerto 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 establecer una política de peering, consulta Configura la agrupación de redes.