Познакомьтесь с концепциями Media API

API Google Meet Media позволяет вашему приложению присоединяться к конференции Google Meet и использовать медиапотоки в реальном времени.

Клиенты используют WebRTC для связи с серверами Meet. Предоставленные эталонные клиенты ( C++ , TypeScript ) демонстрируют рекомендуемые методы, и вам рекомендуется использовать их непосредственно.

Однако вы также можете создавать полностью настраиваемые клиенты WebRTC, соответствующие техническим требованиям Meet Media API.

На этой странице описаны ключевые концепции WebRTC, необходимые для успешного сеанса API Meet Media.

Сигнализация предложения-ответа

WebRTC — это одноранговая (P2P) структура, в которой одноранговые узлы общаются, сигнализируя друг другу. Чтобы начать сеанс, инициирующий узел отправляет предложение SDP удаленному узлу. Данное предложение включает в себя следующие важные детали:

Медиа-описания для аудио и видео

Описания мультимедиа указывают, что передается во время сеансов P2P. Существует три типа описаний: аудио, видео и данные.

Чтобы указать n аудиопотоков, оферент включает в предложение n описаний аудионосителей. То же самое справедливо и для видео. Однако может быть только одно описание носителя данных .

Направленность

Каждое аудио- или видеоописание описывает отдельные потоки безопасного транспортного протокола реального времени (SRTP), регулируемые RFC 3711 . Они являются двунаправленными, что позволяет двум узлам отправлять и получать мультимедиа через одно и то же соединение.

По этой причине каждое описание мультимедиа (как в предложении, так и в ответе) содержит один из трех атрибутов, описывающих, как следует использовать поток:

• sendonly : отправляет медиа только от предлагающего узла. Удаленный узел не будет отправлять мультимедиа в этом потоке.

• recvonly : получает медиаданные только от удаленного узла. Предлагающий узел не будет отправлять мультимедиа в этом потоке.

• sendrecv : оба узла могут отправлять и получать данные в этом потоке.

Кодеки

В каждом описании мультимедиа также указаны кодеки, которые поддерживает одноранговый узел. В случае с Meet Media API предложения клиентов отклоняются, если они не поддерживают (по крайней мере) кодеки, указанные в технических требованиях .

DTLS-рукопожатие

Потоки SRTP защищены первоначальным подтверждением связи Datagram Transport Layer Security («DTLS», RFC 9147 ) между узлами. DTLS традиционно является протоколом клиент-сервер; во время процесса сигнализации один узел соглашается действовать как сервер, а другой — как узел.

Поскольку каждый поток SRTP может иметь собственное выделенное соединение DTLS, каждое описание мультимедиа указывает один из трех атрибутов, указывающих роль партнера в подтверждении связи DTLS:

• a=setup:actpass : Предлагающий узел подчиняется выбору удаленного узла.

• a=setup:active : этот узел действует как клиент.

• a=setup:passive : этот узел действует как сервер.

Описания носителей приложения

Каналы данных ( RFC 8831 ) представляют собой абстракцию протокола передачи управления потоком («SCTP», RFC 9260 ).

Чтобы открыть каналы передачи данных на начальном этапе сигнализации, предложение должно содержать описание носителя приложения . В отличие от описаний аудио и видео, в описаниях приложений не указываются направление или кодеки.

кандидаты ICE

Кандидаты для установления интерактивного соединения однорангового узла («ICE», RFC 8445 ) — это список маршрутов, которые удаленный одноранговый узел может использовать для установления соединения.

Декартово произведение списков двух узлов, известное как пары кандидатов , представляет потенциальные маршруты между двумя узлами. Эти пары тестируются для определения оптимального маршрута.

Сигнал через Meet REST API

Используйте Meet REST API для передачи сигналов « предложение-ответ» . Ваше приложение предоставляет предложение SDP методу connectActiveConference() и получает взамен ответ SDP .

Пример схемы подключения

Вот предложение с аудио-описанием:

Удаленный узел отвечает ответом SDP, содержащим такое же количество строк описания носителя. В каждой строке указывается, какой носитель, если таковой имеется, удаленный узел отправляет обратно предлагающему клиенту через потоки SRTP. Удаленный узел может также отклонить определенные потоки от поставщика, установив для этой записи описания носителя значение recvonly .

Для Meet Media API клиенты всегда отправляют предложение SDP для инициации соединения. Meet никогда не является инициатором.

Этим поведением управляют внутренние эталонные клиенты ( C++ , TypeScript ), но разработчики пользовательских клиентов могут использовать PeerConnectionInterface WebRTC для создания предложения.

Чтобы подключиться к Meet Meet, предложение должно соответствовать определенным требованиям :

1. Клиент всегда должен действовать как клиент при подтверждении связи DTLS, поэтому в каждом описании мультимедиа в предложении должно быть указано либо a=setup:actpass , либо a=setup:active .

2. Каждая строка описания мультимедиа должна поддерживать все необходимые кодеки для этого типа мультимедиа:

   • Аудио: Opus
   • Видео: VP8 , VP9 , AV1

3. Чтобы получить аудио, предложение должно включать ровно 3 описания аудионосителей, доступных только для получения. Вы можете сделать это, установив трансиверы на объекте однорангового соединения.

   С++

   // ...
   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. Чтобы получить видео, предложение должно включать 1–3 описания видеоматериалов, предназначенных только для получения. Вы можете сделать это, установив трансиверы на объекте однорангового соединения.

   С++

   // ...
   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. Предложение всегда должно включать каналы передачи данных. Как минимум, каналы session-control и media-stats должны быть всегда открыты. Все каналы передачи данных должны быть ordered .

   С++

   // ...
   // 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);
   };
   

Пример предложения и ответа SDP

Вот полный пример действительного предложения SDP и соответствующего ответа SDP. Это предложение согласовывает сеанс Meet Media API с аудио и одним видеопотоком.

Обратите внимание, что есть три описания аудионосителей, одно описание видеоносителей и необходимое описание носителей приложения.

Связанные темы

• Начать

,

API Google Meet Media позволяет вашему приложению присоединяться к конференции Google Meet и использовать медиапотоки в реальном времени.

Клиенты используют WebRTC для связи с серверами Meet. Предоставленные эталонные клиенты ( C++ , TypeScript ) демонстрируют рекомендуемые методы, и вам рекомендуется использовать их непосредственно.

Однако вы также можете создавать полностью настраиваемые клиенты WebRTC, соответствующие техническим требованиям Meet Media API.

На этой странице описаны ключевые концепции WebRTC, необходимые для успешного сеанса API Meet Media.

Сигнализация предложения-ответа

WebRTC — это одноранговая (P2P) структура, в которой одноранговые узлы общаются, сигнализируя друг другу. Чтобы начать сеанс, инициирующий узел отправляет предложение SDP удаленному узлу. Данное предложение включает в себя следующие важные детали:

Медиа-описания для аудио и видео

Описания мультимедиа указывают, что передается во время сеансов P2P. Существует три типа описаний: аудио, видео и данные.

Чтобы указать n аудиопотоков, оферент включает в предложение n описаний аудионосителей. То же самое справедливо и для видео. Однако может быть только одно описание носителя данных .

Направленность

Каждое аудио- или видеоописание описывает отдельные потоки безопасного транспортного протокола реального времени (SRTP), регулируемые RFC 3711 . Они являются двунаправленными, что позволяет двум узлам отправлять и получать мультимедиа через одно и то же соединение.

По этой причине каждое описание мультимедиа (как в предложении, так и в ответе) содержит один из трех атрибутов, описывающих, как следует использовать поток:

• sendonly : отправляет медиа только от предлагающего узла. Удаленный узел не будет отправлять мультимедиа в этом потоке.

• recvonly : получает медиаданные только от удаленного узла. Предлагающий узел не будет отправлять мультимедиа в этом потоке.

• sendrecv : оба узла могут отправлять и получать данные в этом потоке.

Кодеки

В каждом описании мультимедиа также указаны кодеки, которые поддерживает одноранговый узел. В случае с Meet Media API предложения клиентов отклоняются, если они не поддерживают (по крайней мере) кодеки, указанные в технических требованиях .

DTLS-рукопожатие

Потоки SRTP защищены первоначальным подтверждением связи Datagram Transport Layer Security («DTLS», RFC 9147 ) между узлами. DTLS традиционно представляет собой протокол клиент-сервер; во время процесса сигнализации один узел соглашается действовать как сервер, а другой — как узел.

Поскольку каждый поток SRTP может иметь собственное выделенное соединение DTLS, каждое описание мультимедиа указывает один из трех атрибутов, указывающих роль партнера в подтверждении связи DTLS:

• a=setup:actpass : Предлагающий узел подчиняется выбору удаленного узла.

• a=setup:active : этот узел действует как клиент.

• a=setup:passive : этот узел действует как сервер.

Описания носителей приложения

Каналы данных ( RFC 8831 ) представляют собой абстракцию протокола передачи управления потоком («SCTP», RFC 9260 ).

Чтобы открыть каналы передачи данных на начальном этапе сигнализации, предложение должно содержать описание носителя приложения . В отличие от описаний аудио и видео, в описаниях приложений не указываются направление или кодеки.

кандидаты ICE

Кандидаты для установления интерактивного соединения однорангового узла («ICE», RFC 8445 ) — это список маршрутов, которые удаленный одноранговый узел может использовать для установления соединения.

Декартово произведение списков двух узлов, известное как пары кандидатов , представляет потенциальные маршруты между двумя узлами. Эти пары тестируются для определения оптимального маршрута.

Сигнал через Meet REST API

Используйте Meet REST API для передачи сигналов « предложение-ответ» . Ваше приложение предоставляет предложение SDP методу connectActiveConference() и получает взамен ответ SDP .

Пример схемы подключения

Вот предложение с аудио-описанием:

Удаленный узел отвечает ответом SDP, содержащим такое же количество строк описания носителя. В каждой строке указывается, какой носитель, если таковой имеется, удаленный узел отправляет обратно предлагающему клиенту через потоки SRTP. Удаленный узел может также отклонить определенные потоки от поставщика, установив для этой записи описания носителя значение recvonly .

Для Meet Media API клиенты всегда отправляют предложение SDP для инициации соединения. Meet никогда не является инициатором.

Этим поведением управляют внутренние эталонные клиенты ( C++ , TypeScript ), но разработчики пользовательских клиентов могут использовать PeerConnectionInterface WebRTC для создания предложения.

Чтобы подключиться к Meet Meet, предложение должно соответствовать определенным требованиям :

1. Клиент всегда должен действовать как клиент при подтверждении связи DTLS, поэтому в каждом описании мультимедиа в предложении должно быть указано либо a=setup:actpass , либо a=setup:active .

2. Каждая строка описания мультимедиа должна поддерживать все необходимые кодеки для этого типа мультимедиа:

   • Аудио: Opus
   • Видео: VP8 , VP9 , AV1

3. Чтобы получить аудио, предложение должно включать ровно 3 описания аудио-носителей, доступных только для получения. Вы можете сделать это, установив трансиверы на объекте однорангового соединения.

   С++

   // ...
   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. Чтобы получить видео, предложение должно включать 1–3 описания видеоносителей, предназначенных только для получения. Вы можете сделать это, установив трансиверы на объекте однорангового соединения.

   С++

   // ...
   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. Предложение всегда должно включать каналы передачи данных. Как минимум, каналы session-control и media-stats должны быть всегда открыты. Все каналы передачи данных должны быть ordered .

   С++

   // ...
   // 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);
   };
   

Пример предложения и ответа SDP

Вот полный пример действительного предложения SDP и соответствующего ответа SDP. Это предложение согласовывает сеанс Meet Media API с аудио и одним видеопотоком.

Обратите внимание, что есть три описания аудионосителей, одно описание видеоносителей и необходимое описание носителей приложения.

Связанные темы

• Начать