Meet Media API の概要

Google Meet Media API を使用すると、Google Meet 会議のリアルタイム メディアにアクセスできます。これにより、アクション アイテムを記録するアプリ、現在の会議に関するリアルタイムの分析情報を提供するアプリ、新しいサーフェスに音声と動画をストリーミングするアプリなど、さまざまなユースケースが可能になります。

ユースケース

Google Cloud コンソールに登録されたアプリは、Meet Media API を使用して Meet 会議に接続し、次のことを行えます。

  • 動画ストリームを使用します。
  • 音声ストリームを使用します。
  • 参加者のメタデータを使用します。

Media API のライフサイクル

次の図は、Meet Media API のライフサイクルを示しています。

  • Meet Media API ボットがサードパーティのウェブサイトに参加しようとします。
    図 1. Meet Media API bot がサードパーティのウェブサイトに参加しようとします。未成年者のアカウントが存在する場合、接続は拒否されます。
  • 暗号化された会議と透かし入りの会議。
    図 2. 会議を暗号化済みとしてマークし、透かしを入れることができます。会議に暗号化または透かしが含まれている場合、Meet Media API に接続できません。
  • 管理者設定が正しいことを確認します。
    図 3. 管理者設定が正しいことを確認してください。
  • カレンダーで会議を設定します。
    図 4. カレンダーで会議を設定します。ホストは、カレンダーの設定でサードパーティ製アプリに権限を付与する必要があります。権限が付与されていない場合、接続は拒否されます。
  • 通話中の設定変更。
    図 5. 通話中の設定変更。通話中に主催者が Meet Media API の設定をオフにすると、接続が停止します。
  • コンシューマーとの会議には、イニシエーターが参加する必要があります。
    図 6. 会議の所有者が一般ユーザー向けアカウント（末尾が @gmail.com のアカウント）を持っている場合、会議の開始者が会議に出席して同意しないと、接続は拒否されます。
  • 接続が確立されました。
    図 7. 接続が確立されると、主催者、共同主催者、または主催者と同じ組織に所属する参加者に開始ダイアログが表示されます。
  • 通話中に Meet Media API を停止できるのは、通話の参加者全員です。
    図 8. 通話中に Meet Media API を停止できるのは、誰でもです。

同意者の要件

Meet Media API アプリが会議に参加できるのは、会議の代理として同意を提供できるユーザーが通話に参加している場合のみです。

Google Workspace の会議の場合

Google Workspace の会議で同意するには、会議を所有する組織に所属している必要があります。ほとんどの場合、会議の所有者は主催者と同じです。主催者または開始者が会議に参加しており、会議を所有する組織に所属している場合、開始ダイアログが優先的に表示されます。

一般ユーザー向け会議の場合

Gmail アカウントで主催された会議の場合、同意するには、開始者が会議に参加している必要があります。

よく使用する用語

Cloud プロジェクト番号
Google Cloud プロジェクトの不変の生成済み int64 識別子。これらの値は、登録されたアプリごとに Google Cloud コンソールによって生成されます。
会議
ミーティング スペース内の通話のサーバー生成インスタンス。ユーザーは通常、このシナリオを 1 つの会議と見なします。
会議リソース データチャンネル

Google Meet REST API のように HTTP 経由でリソースをリクエストするのではなく、Meet Media API クライアントはデータチャネル経由でサーバーからリソースをリクエストします。

リソースタイプごとに専用のデータチャネルが開かれることがあります。開くと、クライアントはチャネル経由でリクエストを送信できます。リソースの更新は同じチャネルで送信されます。

Contributing Source（CSRC）

仮想メディア ストリームでは、メディア ストリームが常に同じ参加者を指しているとは限りません。各 RTP パケットのヘッダーにある CSRC 値は、パケットの実際の送信元を識別します。

Meet では、会議に参加した各参加者に一意の CSRC 値が割り当てられます。この値は、ユーザーが退出するまで一定です。

データ チャネル

WebRTC データチャネルを使用すると、音声ストリームや動画ストリームとは別に、任意のデータ（テキスト、ファイルなど）を交換できます。データチャネルはメディア ストリームと同じ接続を使用するため、WebRTC アプリケーションにデータ交換を追加する効率的な方法を提供します。

Interactive Connectivity Establishment（ICE）

接続を確立し、2 台のコンピュータがピアツーピア（P2P）ネットワーキングを介して相互に通信するための可能なルートをすべて見つけ、接続を維持するためのプロトコル。

メディア ストリーム

WebRTC メディア ストリームは、通常は音声または動画のメディアデータのフローを表します。これは、カメラやマイクなどのデバイスからキャプチャされます。これは、1 つ以上のメディア ストリーム トラックで構成されます。各トラックは、動画トラックや音声トラックなどの単一のメディアソースを表します。

メディア ストリーム トラック

RTP パケットの単一の単方向フローで構成されます。メディア ストリーム トラックは音声または動画のいずれかですが、両方ではありません。双方向の Secure Real-time Transport Protocol（SRTP）接続は通常、2 つのメディア ストリーム トラック（ローカルからリモート ピアへの下り（外向き）と、リモート ピアからローカル ピアへの上り（内向き））で構成されます。

会議スペース

会議が開催される仮想の場所または永続オブジェクト（会議室など）。1 つのスペースで同時に開催できるアクティブな会議は 1 つだけです。会議スペースは、ユーザーが会議に参加して共有リソースを見つけるのにも役立ちます。

参加者

会議に参加しているユーザー、コンパニオン モードを使用しているユーザー、閲覧者として視聴しているユーザー、通話に接続されている会議室デバイス。参加者が会議に参加すると、一意の ID が割り当てられます。

関連するストリーム

クライアントが開くことができる仮想音声ストリームと仮想動画ストリームの数には上限があります。

会議の参加者数がこの数を超えることは十分にありえます。このような状況では、Meet サーバーは「最も関連性が高い」と判断された参加者の音声ストリームと動画ストリームを送信します。関連性は、画面共有や参加者が発言したタイミングなど、さまざまな特性に基づいて判断されます。

Selective Forwarding Unit（SFU）

選択的転送ユニット（SFU）は、メディア ストリームの配信を管理する WebRTC 会議のサーバーサイド コンポーネントです。参加者は SFU にのみ接続し、SFU は関連するストリームを選択的に他の参加者に転送します。これにより、クライアントの処理と帯域幅のニーズが軽減され、スケーラブルな会議が可能になります。

セッション記述プロトコル（SDP）

WebRTC が P2P 接続をネゴシエートするために使用するシグナリング メカニズム。RFC 8866 によって管理されます。

SDP 応答

SDP オファーに対するレスポンス。回答は、リモート ピアから受信したストリームを拒否または受け入れます。また、オファリング ピアに送信するストリームをネゴシエートします。SDP 回答では、最初のオファーからシグナル ストリームを追加できないことに注意してください。たとえば、オファリング ピアがリモート ピアから最大 3 つの音声ストリームを受け入れることをシグナリングした場合、このリモート ピアは 4 つの音声ストリームを送信することをシグナリングできません。

SDP オファー

オファー / アンサーのピアツーピア ネゴシエーション フローの初期 SDP。オファーは開始ピアによって作成され、ピアツーピア セッションの条件を決定します。オファーは常に Meet Media API クライアントによって作成され、Meet サーバーに送信されます。

たとえば、オファーには、オファー側が送信（または受信可能）する音声ストリームまたは動画ストリームの数や、データチャネルを開くかどうかを示すことができます。

同期ソース（SSRC）

SSRC は、RTP（Real-time Transport Protocol）セッション内のメディア ストリームの単一ソースを一意に識別する 32 ビットの識別子です。WebRTC では、SSRC は、異なる参加者から発信された異なるメディア ストリーム、または同じ参加者の異なるトラック（異なるカメラなど）を区別するために使用されます。

RtpTransceiver

RFC 8829 で説明されているように、トランシーバはピアツーピア セッションの RTP ストリームの抽象化です。

1 つのトランシーバは、SDP の 1 つのメディア記述にマッピングされ、記述されます。トランシーバは RtpSender と RtpReceiver で構成されます。

RTP は双方向であるため、各ピアには同じ RTP 接続用の独自のトランシーバ インスタンスがあります。ローカル ピアの特定のトランシーバの RtpSender は、リモート ピアの特定のトランシーバの RtpReceiver にマッピングされます。その逆も当てはまります。リモートピアの同じトランシーバの RtpSender は、ローカルピアの RtpReceiver にマッピングされます。

各メディアの説明には、専用のトランシーバがあります。したがって、複数の RTP ストリームを含むピアツーピア セッションには、ピアごとに複数の RtpSenders と RtpReceiver を持つ複数のトランシーバがあります。

仮想メディア ストリーム

仮想メディア ストリームは、WebRTC 会議で Selective Forwarding Unit（SFU）によって生成される集約されたメディア ストリームです。各参加者が個別のストリームを他のすべての参加者に送信するのではなく、SFU は選択された参加者のストリームをより少ない送信仮想ストリームに多重化します。これにより、接続トポロジが簡素化され、参加者の負荷が軽減され、スケーラブルな会議が可能になります。各仮想ストリームには、複数の参加者のメディアを含めることができます。これは SFU によって動的に管理されます。