Познакомьтесь с концепциями Media API
Оптимизируйте свои подборки
Сохраняйте и классифицируйте контент в соответствии со своими настройками.
API Google Meet Media позволяет вашему приложению присоединяться к конференции Google Meet и получать медиапотоки в режиме реального времени.
Клиенты используют WebRTC для связи с серверами Meet. Предоставленные эталонные клиенты ( C++ , TypeScript ) демонстрируют рекомендуемые методы, и вам рекомендуется разрабатывать приложения, используя их в своих проектах.
Однако вы также можете создавать полностью настраиваемые WebRTC-клиенты, соответствующие техническим требованиям API Meet Media.
На этой странице изложены ключевые концепции WebRTC, необходимые для успешного проведения сеанса Meet Media API.
Сигнализация «предложение-ответ»
WebRTC — это пиринговая (P2P) платформа, в которой участники обмениваются сигналами. Для начала сессии инициирующий участник отправляет SDP-предложение удалённому участнику. Это предложение содержит следующие важные данные:
Описание медиафайлов для аудио и видео.
Медиаописания указывают на то, что передается во время P2P-сессий. Существует три типа описаний: аудио, видео и данные.
Для обозначения n аудиопотоков, поставщик включает в предложение n описаний аудиомедиа. То же самое относится и к видео. Однако будет максимум одно описание медиаданных .
Направленность
Каждое аудио- или видеоописание описывает отдельные потоки протокола Secure Real-time Transport Protocol (SRTP), регулируемые RFC 3711 Эти потоки являются двунаправленными, позволяя двум участникам передавать и получать медиафайлы по одному и тому же соединению.
Поэтому каждое описание медиафайла (как в предложении, так и в ответе) содержит один из трех атрибутов, описывающих способ использования потока:
sendonly : Отправляет медиафайлы только от партнера, предоставляющего медиаконтент. Удаленный партнер не будет отправлять медиафайлы по этому потоку.
recvonly : Принимает медиафайлы только от удалённого узла. Узел, предоставляющий медиафайлы, не будет отправлять их по этому потоку.
sendrecv : Оба участника могут отправлять и получать данные по этому потоку.
Кодеки
В каждом описании медиафайла также указываются кодеки, поддерживаемые партнером. В случае с API Meet Media, предложения клиентов отклоняются, если они не поддерживают (как минимум) кодеки, указанные в технических требованиях .
рукопожатие DTLS
Потоки SRTP защищены первоначальным рукопожатием в соответствии с протоколом безопасности транспортного уровня дейтаграмм (DTLS), RFC 9147 , между участниками. DTLS традиционно является протоколом «клиент-сервер»; в процессе сигнализации один участник соглашается выступать в роли сервера, а другой — в роли участника.
Поскольку каждый поток SRTP может иметь собственное выделенное DTLS-соединение, в каждом описании медиафайла указывается один из трех атрибутов, определяющих роль участника в рукопожатии DTLS:
a=setup:actpass : Удаляющий узел принимает решение в пользу удаленного узла.
a=setup:active : Этот узел выступает в роли клиента.
a=setup:passive : Этот узел выступает в роли сервера.
Описание медиафайлов приложения
Каналы данных ( RFC 8831 ) представляют собой абстракцию протокола управления потоком передачи данных («SCTP», RFC 9260 ).
Для открытия каналов передачи данных на начальном этапе сигнализации предложение должно содержать описание медиафайлов приложения . В отличие от описаний аудио- и видеофайлов, описания приложений не указывают направление или кодеки.
кандидаты ICE
Кандидаты на установление интерактивного соединения (Interactive Connectivity Establishment, ICE), RFC 8445 , представляют собой список маршрутов, которые удаленный узел может использовать для установления соединения.
Декартово произведение списков двух узлов, известное как пары-кандидаты , представляет собой потенциальные маршруты между двумя узлами. Эти пары проверяются для определения оптимального маршрута.
Удаленный узел отвечает SDP-ответом , содержащим такое же количество строк описания медиафайлов. Каждая строка указывает, какие медиафайлы, если таковые имеются, удаленный узел отправляет обратно клиенту-поставщику через потоки SRTP. Удаленный узел также может отклонять определенные потоки от поставщика, установив для этой записи описания медиафайлов значение recvonly .
При использовании Meet Media API клиенты всегда отправляют предложение SDP для установления соединения. Meet никогда не выступает в роли инициатора.
Такое поведение управляется внутренне эталонными клиентами ( C++ , TypeScript ), но разработчики пользовательских клиентов могут использовать PeerConnectionInterface WebRTC для генерации предложения.
Для подключения к Meet Meet предложение должно соответствовать определенным требованиям :
В процессе установления DTLS-соединения клиент всегда должен выступать в роли клиента, поэтому в каждом описании медиафайла в предложении необходимо указать либо a=setup:actpass , либо a=setup:active .
Каждая строка описания медиафайла должна поддерживать все необходимые кодеки для данного типа медиафайлов:
Аудио:Opus
Видео:VP8 , VP9 , AV1
Для приема аудиосообщений предложение должно содержать ровно 3 описания аудиофайлов, предназначенных только для приема. Это можно сделать, установив параметры приемопередатчиков в объекте подключения к партнеру.
Для приема видеосообщений предложение должно содержать 1–3 описания видеофайлов, предназначенных только для приема. Это можно сделать, установив параметры приемопередатчиков в объекте подключения к партнеру.
Предложение всегда должно включать каналы передачи данных. Как минимум, каналы session-control и media-stats должны быть всегда открыты. Все каналы передачи данных должны быть ordered .
Вот полный пример действительного предложения SDP и соответствующего ответа SDP. Это предложение устанавливает сеанс Meet Media API с аудиопотоком и одним видеопотоком.
Обратите внимание, что имеется три описания аудиофайлов, одно описание видеофайлов и обязательное описание приложения.
[[["Прост для понимания","easyToUnderstand","thumb-up"],["Помог мне решить мою проблему","solvedMyProblem","thumb-up"],["Другое","otherUp","thumb-up"]],[["Отсутствует нужная мне информация","missingTheInformationINeed","thumb-down"],["Слишком сложен/слишком много шагов","tooComplicatedTooManySteps","thumb-down"],["Устарел","outOfDate","thumb-down"],["Проблема с переводом текста","translationIssue","thumb-down"],["Проблемы образцов/кода","samplesCodeIssue","thumb-down"],["Другое","otherDown","thumb-down"]],["Последнее обновление: 2026-05-13 UTC."],[],[]]