Descripción general de la API de Meet Media

La API de Google Meet Media te permite acceder a contenido multimedia en tiempo real desde las conferencias de Google Meet. Esto permite una variedad de casos de uso, como apps que documentan elementos de acción, ofrecen estadísticas en tiempo real sobre la reunión actual o transmiten audio y video a una nueva superficie.

Casos de uso

Las apps registradas en la consola de Google Cloud pueden usar la API de Meet Media para conectarse a las conferencias de Meet, lo que les permite hacer lo siguiente:

  • Consumir transmisiones de video. Por ejemplo:
    • Incorpora transmisiones de video generadas en conferencias de Meet a tus propios modelos de IA.
    • Filtra transmisiones para grabaciones personalizadas.
  • Consumir transmisiones de audio. Por ejemplo:
    • Incorpora audio directamente a Gemini y crea tu propio chatbot de IA para reuniones.
    • Incorpora transmisiones de audio generadas en conferencias de Meet a tu propio servicio de transcripción.
    • Genera subtítulos en varios idiomas.
    • Crea feeds de lenguaje de señas generados por modelos a partir del audio capturado.
    • Crea tus propios modelos de eliminación de ruido para quitar el ruido de fondo y los artefactos ruidosos de la conferencia.
  • Consumir metadatos de participantes. Por ejemplo:
    • Detecta qué participantes están en la conferencia, lo que permite obtener mejores estadísticas y análisis.

Ciclo de vida de la API de Meet Media

En las siguientes imágenes, se muestra el ciclo de vida de la API de Meet Media:

  • El bot de la API de Meet Media intenta unirse al sitio web de terceros.
    Figura 1. El bot de la API de Meet Media intenta unirse al sitio web de terceros. La conexión se rechaza cuando hay cuentas de menores de edad.
  • Reuniones encriptadas y reuniones con marca de agua
    Figura 2: Las reuniones se pueden marcar como encriptadas y tener una marca de agua. La API de Meet Media no se puede conectar cuando una reunión tiene encriptación o una marca de agua.
  • Asegúrate de que el parámetro de configuración del administrador sea correcto.
    Figura 3: Asegúrate de que la configuración de administrador sea correcta.
  • Configura la reunión en Calendario.
    Figura 4: Configura la reunión en Calendario. El organizador debe otorgar permiso a la app de terceros en la configuración de Calendario; de lo contrario, se rechazará la conexión.
  • Cambio de configuración durante la llamada.
    Figura 5: Cambio de configuración durante la llamada. Si el organizador decide desactivar la configuración de la API de Meet Media durante una llamada, la conexión se detendrá.
  • El iniciador debe estar presente durante las reuniones con el cliente.
    Figura 6: Si el propietario de la reunión tiene una cuenta de consumidor (una cuenta que termina en @gmail.com), el iniciador debe estar presente para que la reunión otorgue el consentimiento; de lo contrario, se rechazará la conexión.
  • Se estableció la conexión.
    Figura 7: Una vez que se establece la conexión, el organizador, el coorganizador o cualquier participante de la misma organización que el organizador ven el diálogo de inicio.
  • Cualquier persona puede detener la API de Meet Media durante la llamada.
    Figura 8: Cualquier persona puede detener la API de Meet Media durante la llamada.

Requisitos del otorgante de consentimiento

Las apps de la API de Meet Media solo se permiten en una reunión si hay alguien en la llamada que pueda otorgar el consentimiento en nombre de la reunión.

Para reuniones de Google Workspace

Para otorgar el consentimiento en las reuniones de Google Workspace, debes pertenecer a la organización propietaria de la reunión. En la mayoría de los casos, el propietario de la reunión es el mismo que el organizador. Si el organizador o el iniciador están en la reunión y pertenecen a la organización propietaria de la reunión, se les muestra el diálogo de inicio de forma preferencial.

Para reuniones de consumidores

En el caso de las reuniones organizadas por cuentas de Gmail, el iniciador debe estar en la reunión para otorgar el consentimiento.

Términos comunes

Número de proyecto de Cloud
Un identificador int64 inmutable generado para un proyecto de Google Cloud. La consola de Google Cloud genera estos valores para cada app registrada.
Conferencia
Una instancia de una llamada generada por el servidor dentro de un espacio de reuniones. Por lo general, los usuarios consideran este caso como una sola reunión.
Canal de datos de recursos de la conferencia

En lugar de solicitar recursos a través de HTTP, como con la API de REST de Google Meet, los clientes de la API de Meet Media solicitan recursos del servidor a través de canales de datos.

Se puede abrir un canal de datos dedicado para cada tipo de recurso. Una vez abierto, el cliente puede enviar solicitudes a través del canal. Las actualizaciones de recursos se transmitirán a través del mismo canal.

Fuente contribuyente (CSRC)

Con las transmisiones de contenido multimedia virtuales, no puedes suponer que una transmisión de contenido multimedia siempre apunta al mismo participante. El valor de CSRC en el encabezado de cada paquete RTP identifica la fuente verdadera del paquete.

Meet asigna a cada participante de una conferencia un valor de CSRC único cuando se une. Este valor permanece constante hasta que se va.

Canales de datos

Los canales de datos de WebRTC permiten el intercambio de datos arbitrarios (texto, archivos, etcétera) independientemente de las transmisiones de audio y video. Los canales de datos usan la misma conexión que las transmisiones de contenido multimedia, lo que proporciona una forma eficiente de agregar intercambio de datos a las aplicaciones de WebRTC.

Interactive Connectivity Establishment (ICE)

Un protocolo para establecer la conectividad, encontrar todas las rutas posibles para que dos computadoras se comuniquen entre sí a través de redes de igual a igual (P2P) y, luego, asegurarse de que permanezcas conectado.

Transmisión de contenido multimedia

Una transmisión de contenido multimedia de WebRTC representa un flujo de datos multimedia, por lo general, audio o video, capturado desde un dispositivo como una cámara o un micrófono. Consta de una o varias pistas de transmisión de contenido multimedia, cada una de las cuales representa una sola fuente de contenido multimedia, como una pista de video o una pista de audio.

Pista de transmisión de contenido multimedia

Consta de un flujo unidireccional único de paquetes RTP. Una pista de transmisión de contenido multimedia puede ser de audio o video, pero no ambas. Por lo general, una conexión Protocolo seguro de transporte en tiempo real (SRTP) bidireccional consta de dos pistas de transmisión de contenido multimedia, salida de par local a par remoto y entrada de par remoto a par local.

Sala de reuniones

Un lugar virtual o un objeto persistente (como una sala de reuniones) donde se lleva a cabo una conferencia. Solo se puede realizar una conferencia activa en un espacio en cualquier momento. Una sala de reuniones también ayuda a los usuarios a reunirse y encontrar recursos compartidos.

Participante

Una persona que se unió a una conferencia o que usa el Modo complementario, que mira como espectador o un dispositivo de sala conectado a una llamada. Cuando un participante se une a la conferencia, se le asigna un ID único.

Transmisiones relevantes

Existe un límite en la cantidad de transmisiones de audio virtuales y transmisiones de video virtuales que puede abrir un cliente.

Es muy posible que la cantidad de participantes en una conferencia supere este número. En estas situaciones, los servidores de Meet transmiten las transmisiones de audio y video de los participantes que se consideran "más relevantes". La relevancia se determina a partir de varias características, como el uso compartido de pantalla y la frecuencia con la que un participante habló recientemente.

Unidad de reenvío selectivo (SFU)

Una unidad de reenvío selectivo (SFU) es un componente del servidor en las conferencias de WebRTC que administra la distribución de transmisiones de contenido multimedia. Los participantes solo se conectan a la SFU, que reenvía de forma selectiva las transmisiones relevantes a otros participantes. Esto reduce el procesamiento del cliente y las necesidades de ancho de banda, lo que permite conferencias escalables.

Session Description Protocol (SDP)

El mecanismo de señalización que usa WebRTC para negociar una conexión P2P. RFC 8866 lo rige.

Respuesta SDP

La respuesta a una oferta SDP. La respuesta rechaza o acepta cualquier transmisión recibida del par remoto. También negocia qué transmisiones planea transmitir de vuelta al par que ofrece. Es importante tener en cuenta que la respuesta SDP no puede agregar transmisiones señalizadas de la oferta inicial. De forma anecdótica, si un par que ofrece señala que acepta hasta tres transmisiones de audio de su par remoto, este par remoto no puede señalar cuatro transmisiones de audio para la transmisión.

Oferta SDP

El SDP inicial en el flujo de negociación de igual a igual de oferta y respuesta. El par iniciador crea la oferta y dicta las condiciones de la sesión de igual a igual. El cliente de la API de Meet Media siempre crea la oferta y la envía a los servidores de Meet.

Por ejemplo, una oferta puede indicar la cantidad de transmisiones de audio o video que envía el oferente (o que puede recibir) y si se deben abrir canales de datos.

Fuente de sincronización (SSRC)

Un SSRC es un identificador de 32 bits que identifica de forma única una sola fuente de una transmisión de contenido multimedia dentro de una sesión RTP (Protocolo de transporte en tiempo real). En WebRTC, los SSRC se usan para distinguir entre diferentes transmisiones de contenido multimedia que provienen de diferentes participantes o incluso diferentes pistas del mismo participante (como diferentes cámaras).

RtpTransceiver

Como se detalla en RFC 8829, un transceptor es una abstracción en torno a las transmisiones RTP en una sesión de igual a igual.

Un solo transceptor se asigna a una sola descripción de contenido multimedia en el SDP y se describe en ella. Un transceptor consta de un RtpSender y un RtpReceiver.

Debido a que RTP es bidireccional, cada par tiene su propia instancia de transceptor para la misma conexión RTP. El RtpSender de un transceptor determinado para el par local se asigna al RtpReceiver de un transceptor específico en el par remoto. Lo opuesto también se cumple. El RtpSender del mismo transceptor del par remoto se asigna al RtpReceiver del par local.

Cada descripción de contenido multimedia tiene su propio transceptor dedicado. Por lo tanto, una sesión de igual a igual con varias transmisiones RTP tiene varios transceptores con varios RtpSenders y RtpReceiver para cada par.

Transmisiones de contenido multimedia virtuales

Las transmisiones de contenido multimedia virtuales son transmisiones de contenido multimedia agregadas generadas por una unidad de reenvío selectivo (SFU) en las conferencias de WebRTC. En lugar de que cada participante envíe transmisiones individuales a todos los demás, la SFU multiplexa las transmisiones de participantes seleccionadas en menos transmisiones virtuales salientes. Esto simplifica la topología de conexión y reduce la carga en los participantes, lo que permite conferencias escalables. Cada transmisión virtual puede contener contenido multimedia de varios participantes, administrado de forma dinámica por la SFU.