Os clientes usam o WebRTC para se comunicar com os servidores do Meet. Os clientes de referência fornecidos (C++,
TypeScript) demonstram as práticas recomendadas, e
incentivamos você a criar diretamente com base neles.
No entanto, também é possível criar clientes WebRTC totalmente personalizados que aderem aos
requisitos técnicos
da API Meet Media.
Esta página descreve os principais conceitos do WebRTC necessários para uma sessão bem-sucedida da API Meet Media.
Sinalização de oferta-resposta
O WebRTC é um framework ponto a ponto (P2P), em que os pares se comunicam por sinalização. Para iniciar uma sessão, o par de inicialização envia uma oferta de SDP para um par remoto. Essa oferta inclui os seguintes detalhes importantes:
Descrições de mídia para áudio e vídeo
As descrições de mídia indicam o que é comunicado durante as sessões P2P. Há três tipos de descrições: áudio, vídeo e dados.
Para indicar n streams de áudio, o ofertante inclui n descrições de mídia de áudio na oferta. O mesmo vale para vídeo. No entanto, haverá apenas uma descrição de mídia de dados no máximo.
Direção
Cada descrição de áudio ou vídeo descreve streams individuais do Secure Real-time Transport
Protocol (SRTP), regidos por RFC
3711. Eles são bidirecionais, permitindo que dois pares enviem e recebam mídia na mesma conexão.
Por isso, cada descrição de mídia (na oferta e na resposta) contém um dos três atributos que descrevem como o stream deve ser usado:
sendonly: envia apenas mídia do par de oferta. O par remoto não enviará mídia nesse stream.
recvonly: recebe apenas mídia do par remoto. O par de oferta não enviará mídia nesse stream.
sendrecv: os dois pares podem enviar e receber nesse stream.
Codecs
Cada descrição de mídia também especifica os codecs que um par oferece suporte. No caso da
API Meet Media, as ofertas de clientes são rejeitadas, a menos que ofereçam suporte
(pelo menos) aos codecs especificados nos requisitos
técnicos.
Handshake de DTLS
Os streams de SRTP são protegidos por um handshake inicial
Datagram Transport Layer Security ("DTLS", RFC
9147) entre os pares.
O DTLS é tradicionalmente um protocolo cliente-servidor. Durante o processo de sinalização, um par concorda em atuar como servidor, enquanto o outro atua como um par.
Como cada stream de SRTP pode ter sua própria conexão DTLS dedicada, cada descrição de mídia especifica um dos três atributos para indicar o papel do par no handshake de DTLS:
a=setup:actpass: o par de oferta é adiado para a escolha do par remoto.
a=setup:active: esse par atua como o cliente.
a=setup:passive: esse par atua como o servidor.
Descrições de mídia do aplicativo
Os canais de dados (RFC 8831) são
uma abstração do Stream Control Transmission Protocol ("SCTP", RFC
9260).
Para abrir canais de dados durante a fase de sinalização inicial, a oferta precisa conter uma descrição de mídia do aplicativo. Ao contrário das descrições de áudio e vídeo, as descrições de aplicativos não especificam direção ou codecs.
Candidatos do ICE
Os candidatos do Interactive Connectivity Establishment ("ICE", RFC
8445) de um par são uma lista de rotas que um par remoto pode usar para estabelecer uma conexão.
O produto cartesiano das listas dos dois pares, conhecido como pares de candidatos,
representa as rotas possíveis entre dois pares. Esses pares são testados para determinar a rota ideal.
Confira uma oferta com uma descrição de mídia de áudio:
Figura 1. Exemplo de oferta com uma descrição de mídia de áudio.
O par remoto responde com uma resposta de SDP que contém o mesmo número de linhas de descrição de mídia. Cada linha indica qual mídia, se houver, o par remoto envia de volta ao cliente de oferta nos streams de SRTP. O par remoto também pode rejeitar streams específicos do ofertante definindo a entrada de descrição de mídia como recvonly.
Para a API Meet Media, os clientes sempre enviam a oferta de SDP para iniciar uma conexão. O Meet nunca é o iniciador.
Esse comportamento é gerenciado internamente pelos clientes de referência
(C++, TypeScript),
mas os desenvolvedores de clientes personalizados podem usar o WebRTC's PeerConnectionInterface para
gerar uma oferta.
Para se conectar ao Meet, a oferta precisa obedecer a requisitos específicos
requisitos:
O cliente sempre precisa atuar como o cliente no handshake de DTLS. Portanto, cada descrição de mídia na oferta precisa especificar a=setup:actpass ou a=setup:active.
Cada linha de descrição de mídia precisa oferecer suporte a todos os necessários
codecs para esse tipo de mídia:
Áudio:Opus
Vídeo:VP8, VP9, AV1
Para receber áudio, a oferta precisa incluir exatamente três descrições de mídia de áudio somente de recebimento. Para fazer isso, defina transceptores no objeto de conexão de pares.
Para receber vídeo, a oferta precisa incluir de uma a três descrições de mídia de vídeo somente de recebimento. Para fazer isso, defina transceptores no objeto de conexão de pares.
A oferta sempre precisa incluir canais de dados. No mínimo, os canais session-control e media-stats precisam estar sempre abertos. Todos os canais de dados precisam ser ordered.
Confira um exemplo completo de uma oferta de SDP válida e uma resposta de SDP correspondente. Essa oferta negocia uma sessão da API Meet Media com áudio e um único stream de vídeo.
Observe que há três descrições de mídia de áudio, uma descrição de mídia de vídeo e a descrição de mídia de aplicativo necessária.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2026-05-13 UTC."],[],[]]