Conceptos de la API de Meet Media

La API de Google Meet Media permite que tu app se una a una conferencia de Google Meet y consuma transmisiones de contenido multimedia en tiempo real.

Los clientes usan WebRTC para comunicarse con los servidores de Meet. Los clientes de referencia proporcionados (C++, TypeScript) demuestran prácticas recomendadas y te recomendamos que los compiles directamente.

Sin embargo, también puedes compilar clientes WebRTC completamente personalizados que cumplan con los requisitos técnicos de la API de Meet Media.

En esta página, se describen los conceptos clave de WebRTC necesarios para que se realice correctamente una sesión de la API de Meet Media.

Señalización de oferta-respuesta

WebRTC es un framework de igual a igual (P2P), en el que los pares se comunican mediante indicadores. Para iniciar una sesión, el par que inicia la sesión envía una oferta de SDP a un par remoto. Esta oferta incluye los siguientes detalles importantes:

Descripciones de contenido multimedia para audio y video

Las descripciones de contenido multimedia indican lo que se comunica durante las sesiones P2P. Existen tres tipos de descripciones: audio, video y datos.

Para indicar n transmisiones de audio, el ofertante incluye n descripciones de contenido multimedia de audio en la oferta. Lo mismo sucede con los videos. Sin embargo, solo habrá una descripción de contenido multimedia de datos como máximo.

Direccionalidad

Cada descripción de audio o video describe transmisiones individuales del protocolo seguro de transporte en tiempo real (SRTP), que se rigen por RFC 3711. Son bidireccionales, lo que permite que dos pares envíen y reciban contenido multimedia a través de la misma conexión.

Por este motivo, cada descripción de contenido multimedia (en la oferta y la respuesta) contiene uno de los siguientes tres atributos que describen cómo se debe usar la transmisión:

• sendonly: Solo envía contenido multimedia del par de ofertas. El par remoto no enviará contenido multimedia en esta transmisión.

• recvonly: Solo recibe contenido multimedia del par remoto. El par de ofertas no enviará contenido multimedia en esta transmisión.

• sendrecv: Ambos pares pueden enviar y recibir en esta transmisión.

Códecs

Cada descripción de contenido multimedia también especifica los códecs que admite un par. En el caso de la API de Meet Media, se rechazan las ofertas del cliente, a menos que admitan (al menos) los códecs especificados en los requisitos técnicos.

Protocolo de enlace DTLS

Las transmisiones de SRTP están protegidas por un protocolo de enlace inicial de seguridad de la capa de transporte de datagramas ("DTLS", RFC 9147) entre los pares. Tradicionalmente, el DTLS es un protocolo de cliente a servidor. Durante el proceso de señalización, un par acepta actuar como servidor, mientras que el otro actúa como par.

Debido a que cada flujo de SRTP puede tener su propia conexión DTLS dedicada, cada descripción de contenido multimedia especifica uno de los tres atributos para indicar el rol del par en el protocolo de enlace DTLS:

• a=setup:actpass: El par de oferta aplaza la elección del par remoto.

• a=setup:active: Este par actúa como cliente.

• a=setup:passive: Este par actúa como servidor.

Descripciones de los medios de la aplicación

Los canales de datos (RFC 8831) son una abstracción del protocolo de transmisión de control de flujo ("SCTP", RFC 9260).

Para abrir canales de datos durante la fase de señalización inicial, la oferta debe contener una descripción de contenido multimedia de la aplicación. A diferencia de las descripciones de audio y video, las descripciones de aplicaciones no especifican la dirección ni los códecs.

Candidatos de ICE

Los candidatos de establecimiento de conectividad interactiva ("ICE", RFC 8445) de un par son una lista de rutas que un par remoto puede usar para establecer una conexión.

El producto cartesiano de las listas de los dos pares, conocido como pares candidatos, representa las posibles rutas entre dos pares. Estos pares se prueban para determinar la ruta óptima.

Cómo enviar indicadores a través de la API de REST de Meet

Usa la API de REST de Meet para realizar esta señalización de oferta-respuesta. Tu app proporciona una oferta de SDP al método connectActiveConference() y recibe una respuesta de SDP a cambio.

Ejemplo de flujo de conexión

Esta es una oferta con una descripción de contenido multimedia de audio:

El par remoto responde con una respuesta SDP que contiene la misma cantidad de líneas de descripción de contenido multimedia. Cada línea indica qué contenido multimedia, si corresponde, el participante remoto envía al cliente de la oferta a través de las transmisiones de SRTP. El peer remoto también puede rechazar transmisiones específicas del ofertante configurando esa entrada de descripción de contenido multimedia en recvonly.

En el caso de la API de Meet Media, los clientes siempre envían la oferta de SDP para iniciar una conexión. Meet nunca es el iniciador.

Los clientes de referencia (C++, TypeScript) administran este comportamiento de forma interna, pero los desarrolladores de clientes personalizados pueden usar PeerConnectionInterface de WebRTC para generar una oferta.

Para conectarse a Meet, la oferta debe cumplir con los siguientes requisitos:

1. El cliente siempre debe actuar como cliente en el protocolo de enlace DTLS, por lo que cada descripción de contenido multimedia en la oferta debe especificar a=setup:actpass o a=setup:active.

2. Cada línea de descripción de contenido multimedia debe admitir todos los códecs necesarios para ese tipo de contenido:

   • Audio: Opus
   • Video: VP8, VP9, AV1

3. Para recibir audio, la oferta debe incluir exactamente 3 descripciones de contenido multimedia de audio solo para recibir. Para ello, configura transceptores en el objeto de conexión de par.

   C++

   // ...
   rtc::scoped_refptr<webrtc::PeerConnectionInterface> peer_connection;
   
   for (int i = 0; i < 3; ++i) {
     webrtc::RtpTransceiverInit audio_init;
     audio_init.direction = webrtc::RtpTransceiverDirection::kRecvOnly;
     audio_init.stream_ids = {absl::StrCat("audio_stream_", i)};
   
     webrtc::RTCErrorOr<rtc::scoped_refptr<webrtc::RtpTransceiverInterface>>
       audio_result = peer_connection->AddTransceiver(
         cricket::MediaType::MEDIA_TYPE_AUDIO, audio_init);
   
     if (!audio_result.ok()) {
       return absl::InternalError(absl::StrCat("Failed to add audio transceiver: ",
                                               audio_result.error().message()));
     }
   }
   

   JavaScript

   pc = new RTCPeerConnection();
   
   // Configure client to receive audio from Meet servers.
   pc.addTransceiver('audio', {'direction':'recvonly'});
   pc.addTransceiver('audio', {'direction':'recvonly'});
   pc.addTransceiver('audio', {'direction':'recvonly'});
   

4. Para recibir videos, la oferta debe incluir entre 1 y 3 descripciones de contenido multimedia de video solo para recibir. Para ello, configura transceptores en el objeto de conexión de par.

   C++

   // ...
   rtc::scoped_refptr<webrtc::PeerConnectionInterface> peer_connection;
   
   for (uint32_t i = 0; i < configurations.receiving_video_stream_count; ++i) {
     webrtc::RtpTransceiverInit video_init;
     video_init.direction = webrtc::RtpTransceiverDirection::kRecvOnly;
     video_init.stream_ids = {absl::StrCat("video_stream_", i)};
   
     webrtc::RTCErrorOr<rtc::scoped_refptr<webrtc::RtpTransceiverInterface>>
         video_result = peer_connection->AddTransceiver(
           cricket::MediaType::MEDIA_TYPE_VIDEO, video_init);
   
     if (!video_result.ok()) {
       return absl::InternalError(absl::StrCat("Failed to add video transceiver: ",
                                               video_result.error().message()));
     }
   }
   

   JavaScript

   pc = new RTCPeerConnection();
   
   // Configure client to receive video from Meet servers.
   pc.addTransceiver('video', {'direction':'recvonly'});
   pc.addTransceiver('video', {'direction':'recvonly'});
   pc.addTransceiver('video', {'direction':'recvonly'});
   

5. La oferta siempre debe incluir canales de datos. Como mínimo, los canales session-control y media-stats siempre deben estar abiertos. Todos los canales de datos deben ser ordered.

   C++

   // ...
   // All data channels must be ordered.
   constexpr webrtc::DataChannelInit kDataChannelConfig = {.ordered = true};
   
   rtc::scoped_refptr<webrtc::PeerConnectionInterface> peer_connection;
   
   // Signal session-control data channel.
   webrtc::RTCErrorOr<rtc::scoped_refptr<webrtc::DataChannelInterface>>
     session_create_result = peer_connection->CreateDataChannelOrError(
       "session-control", &kDataChannelConfig);
   
   if (!session_create_result.ok()) {
     return absl::InternalError(absl::StrCat("Failed to create data channel ",
                                             data_channel_label, ": ",
                                             session_create_result.error().message()));
   }
   
   // Signal media-stats data channel.
   webrtc::RTCErrorOr<rtc::scoped_refptr<webrtc::DataChannelInterface>>
     stats_create_result = peer_connection->CreateDataChannelOrError(
       "media-stats", &kDataChannelConfig);
   
   if (!stats_create_result.ok()) {
     return absl::InternalError(absl::StrCat("Failed to create data channel ",
                                             data_channel_label, ": ",
                                             stats_create_result.error().message()));
   }
   

   JavaScript

   // ...
   pc = new RTCPeerConnection();
   
   // All data channels must be ordered.
   const dataChannelConfig = {
     ordered: true,
   };
   
   // Signal session-control data channel.
   sessionControlChannel = pc.createDataChannel('session-control', dataChannelConfig);
   sessionControlChannel.onopen = () => console.log("data channel is now open");
   sessionControlChannel.onclose = () => console.log("data channel is now closed");
   sessionControlChannel.onmessage = async (e) => {
     console.log("data channel message", e.data);
   };
   
   // Signal media-stats data channel.
   mediaStatsChannel = pc.createDataChannel('media-stats', dataChannelConfig);
   mediaStatsChannel.onopen = () => console.log("data channel is now open");
   mediaStatsChannel.onclose = () => console.log("data channel is now closed");
   mediaStatsChannel.onmessage = async (e) => {
     console.log("data channel message", e.data);
   };
   

Ejemplo de oferta y respuesta de SDP

Este es un ejemplo completo de una oferta de SDP válida y una respuesta de SDP coincidente. Esta oferta negocia una sesión de la API de Meet Media con audio y una sola transmisión de video.

Observa que hay tres descripciones de contenido multimedia de audio, una de contenido multimedia de video y la descripción de contenido multimedia de la aplicación obligatoria.

Temas relacionados

• Comenzar