次の方法で共有

データ チャネル

  • [アーティクル]

Note

このドキュメントでは、Azure Communication Services Calling SDK に存在するデータ チャネル機能について説明します。 このコンテキストのデータ チャネルは WebRTC のデータ チャネルに似ていますが、その詳細における微妙な違いを認識することが重要です。 このドキュメントでは、この SDK 内の Data Channel API を表すには Data Channel API または API という用語を使用します。 WebRTC の Data Channel API に言及する場合は、明確さと厳密さのために WebRTC Data Channel API という用語を明示的に使用します。

Data Channel API を使用すると、音声通話中およびビデオ通話中のリアルタイム メッセージングが可能になります。 この API を使用すると、データ交換機能をアプリケーションに簡単に統合できるようになり、ユーザーにシームレスな通信エクスペリエンスが提供されます。 主な特徴は次のとおりです。

  • リアルタイム メッセージング: Data Channel API を使用すると、ユーザーは進行中の音声またはビデオ通話中にメッセージを即座に送受信でき、スムーズで効率的な通信が促進されます。 グループ通話のシナリオでは、メッセージを通話内の 1 人の参加者、特定の参加者のセット、またはすべての参加者に送信できます。 この柔軟性により、グループで対話中のユーザー間のコミュニケーションとコラボレーションが強化されます。
  • 一方向通信: 双方向通信とは異なり、Data Channel API は一方向通信用に設計されています。 メッセージの送信と受信には個別のオブジェクト (送信には DataChannelSender オブジェクト、受信には DataChannelReceiver オブジェクト) が使用されます。 この分離により、グループ通話でのメッセージ管理が簡素化され、より合理化されたユーザー エクスペリエンスが可能になります。
  • バイナリ データのサポート: この API はバイナリ データの送受信をサポートするため、テキスト、画像、ファイルなどの多様なデータ型の交換が可能です。 テキスト メッセージは、送信する前にバイト バッファーへとシリアル化する必要があります。
  • 送信者オプション: Data Channel API には、送信者オブジェクトを作成するときに構成可能な 3 つのオプション (信頼性、優先度、ビットレート) が用意されています。 これらのオプションにより、さまざまなユース ケースの特定のニーズを満たすようにチャネルを構成できます。
  • セキュリティ: クライアントと他のエンドポイントの間で交換されるすべてのメッセージは暗号化されるため、ユーザーのデータのプライバシーとセキュリティが確保されます。

一般的なユース ケース

データ チャネルは、さまざまなシナリオで使用できます。 2 つの一般的なユース ケースの例を次に示します。

通話中の参加者間のメッセージング

Data Channel API を使用すると、通話参加者間でバイナリ型メッセージを送信できます。 アプリケーションで適切なシリアル化を使用することで、さまざまな目的でさまざまな種類のメッセージを配信できます。 メッセージング機能を提供する他のライブラリやサービスもあります。 それぞれ長所と短所があります。 使用シナリオに適したものを選択する必要があります。 たとえば、Data Channel API は待機時間の短い通信という利点を提供し、また、参加者リストを別途維持する必要がないため、ユーザー管理が簡素化されます。 しかし、データ チャネル機能ではメッセージの永続化は提供されません。またエンド ツー エンドでメッセージが失われないことは保証されません。 ステートフル メッセージングまたは配信の保証が必要な場合は、代替ソリューションを検討することをお勧めします。

ファイル共有

ファイル共有は、Data Channel API のもう 1 つの一般的なユース ケースです。 ピアツーピア通話シナリオでは、データ チャネル接続はピアツーピアで動作します。 このセットアップでは、ファイル転送の効率的な方法が提供されるので、ピアツーピアの直接接続を最大限に活用して速度を向上させ、待機時間を短縮できます。

グループ通話のシナリオでも、参加者間でファイルを共有できます。 ただし、Azure Storage や Azure Files などのより優れた方法もあります。 また、空の参加者リストを設定することで、通話内のすべての参加者にファイル コンテンツをブロードキャストできます。 ただし、帯域幅の制限に加えて、グループ通話中にメッセージをブロードキャストする場合には、パケット レートや受信ビットレートからのバック プレッシャーなど、さらなる制限が課される点に注意することが重要です。

主要な概念

一方向通信

Data Channel API は、WebRTC データ チャネルでの双方向通信とは異なり、一方向通信用に設計されています。 メッセージの送信と受信には個別のオブジェクトを使用します。メッセージの送信を担う DataChannelSender オブジェクトと、メッセージの受信を担う DataChannelReceiver オブジェクトを使用します。

送信者オブジェクトと受信者オブジェクトを分離することで、グループ通話シナリオでのメッセージ処理が簡素化され、より合理化されたユーザー フレンドリなエクスペリエンスが提供されます。

チャネル

すべてのデータ チャネル メッセージは、channelId で識別される特定のチャネルに関連付けられます。 この channelId が WebRTC データ チャネルの id プロパティとは無関係であることを明確にすることが重要です。 この channelId は、制御メッセージに 1000 を使用し、画像転送に 1001 を使用するなど、さまざまなアプリケーション用途を区別するために利用できます。

channelId は DataChannelSender オブジェクトの作成時に割り当てられ、ユーザー指定により、または、未指定の場合は SDK によって決定されます。

channelId の有効範囲は 1 から 65535 です。 channelId 0 が指定されている場合、または channelId が指定されていない場合、SDK は有効な範囲内から使用可能な channelId を割り当てます。

[信頼性]

作成時に、チャネルを lossy または durable の 2 つの信頼性オプションのいずれかに構成できます。

lossy チャネルは、メッセージの順序が保証されていないことを意味し、送信が失敗したときにメッセージが警告なしに破棄される可能性があります。 一般に、より高速なデータ転送速度が得られます。

durable チャネルとは、SDK が無損失で順序付けされたメッセージ配信を保証することです。 メッセージを配信できない場合、SDK は例外をスローします。 Web SDK では、信頼性の高い SCTP 接続によってチャネルの持続性が確保されます。 ただし、これはメッセージがエンドツーエンドで失われないことを意味するものではありません。 グループ通話のコンテキストでは、送信者とサーバー間でのメッセージ損失の防止を意味します。 ピアツーピア通話では、送信者とリモート エンドポイントの間での信頼性の高い送信を意味します。

Note

現在の Web SDK 実装では、lossy と durable の両方のチャネルについて、データ転送は信頼性の高い WebRTC データ チャネル接続を介して行われます。

優先順位

作成時に、チャネルを normal または high の 2 つの優先順位オプションのいずれかに構成できます。

Web SDK の場合、優先度設定は送信側のチャネル間でのみ比較されます。 high 優先順位の付いたチャネルは、 normal 優先順位のチャネルと比較して、伝送の優先順位が高くなります。

Bitrate

チャネルを作成するときに、帯域幅の割り当てについて望ましいビットレートを指定できます。

このビットレート プロパティは、特定のユース ケースで予想される帯域幅要件を SDK に通知します。 SDK は通常、このビットレートに正確に一致させることはできませんが、要求に対応しようとします。

セッション

Data Channel API には、オープン クローズ セマンティクスに準拠したセッションの概念が導入されています。 SDK では、セッションは送信者または受信者オブジェクトに関連付けられます。

新しい channelId を使用して送信者オブジェクトを作成すると、その送信者オブジェクトはオープン状態になります。 この送信者オブジェクトで close() API が呼び出されると、セッションはクローズされ、メッセージを送信できなくなります。 同時に、送信者オブジェクトは、セッションがクローズされたことを通話の全参加者に通知します。

既存の channelId を使用して送信者オブジェクトが作成されルト、その channelId に関連付けられた既存の送信者オブジェクトはクローズされ、この新しく作成された送信者オブジェクトから送信されるすべてのメッセージは新しいセッションの一部として認識されます。

受信者の観点からは、送信側の異なるセッションからのメッセージは、別々の受信者オブジェクトに送られます。 SDK が受信側で既存の channelId に関連付けられている新しいセッションを識別すると、新しい受信者オブジェクトが作成されます。 SDK では、古い受信者オブジェクトはクローズされません。クローズが行われるのは、1) 受信者オブジェクトが送信者からクローズの通知を受信したとき、または 2) セッションが送信者から 2 分以上メッセージを受信していない場合に行われます。

受信者オブジェクトのセッションが閉じられ、受信側に同じ channelId の新しいセッションが存在しない場合、SDK は後に同じセッションからメッセージを受信したときに新しい受信者オブジェクトを作成します。 しかし、受信側に同じ channelId の新しいセッションが存在する場合、SDK は前のセッションからの受信メッセージをすべて破棄します。

受信者オブジェクトが 2 分を超えてメッセージを受信しない場合はクローズされることを考慮して、アプリケーションが、受信者オブジェクトのアクティブな状態を維持するために定期的に送信側からキープアライブ メッセージを送信することをお勧めします。

Sequence number

シーケンス番号は、データ チャネル メッセージに含まれる 32 ビット符号なし整数であり、チャネル内におけるメッセージ順序を示しています。 この番号は送信者の観点から生成されていることに注意してください。 その結果、送信者がメッセージの送信中に受信者を変更した場合、受信者はシーケンス番号のギャップに気付く可能性があります。

たとえば、送信者が 3 つのメッセージを送信するシナリオを考えてみましょう。 最初の受信者は参加者 A と参加者 B です。1 番目のメッセージの後、送信者は受信者を参加者 B に変更し、さらに 3 番目のメッセージの前に、受信者を参加者 A に切り替えます。この場合、参加者 A はシーケンス番号 1 と 3 の 2 つのメッセージを受信します。 しかし、これはメッセージの損失を示すものではなく、送信者による受信者の変更のみを反映しています。

制限事項

メッセージ サイズ

1 つのメッセージの最大許容サイズは 32 KB です。 制限を超えるデータを送信する必要がある場合は、データを複数のメッセージに分割する必要があります。

参加者リスト

リスト内の参加者の最大数は 64 人に制限されています。 より多くの参加者を指定したい場合は、自分で参加者リストを管理する必要があります。 たとえば、50 人の参加者にメッセージを送信する場合は、受信者リストに 25 人の参加者が含まれる 2 つの異なるチャネルを作成できます。 この制限の計算では、同じ参加者識別子を持つ 2 つのエンドポイントが別個のエンティティとしてカウントされます。 代替手段として、メッセージのブロードキャストを選択することもできます。 ただし、メッセージをブロードキャストする場合は、特定の制限が適用されます。

レート制限

呼び出し元の SDK には現在、レート制限が実装されており、ネットワークで許可される場合でも、ユーザーはデータを高速で送信できなくなります。 データ チャネルの現在の帯域幅レートの最大値は次のとおりです。

  • 信頼度の高いチャンネル (Durable): 64 kbps
  • 信頼度の低いチャンネル (Lossy): 512 kbps
  • 高優先度で信頼性の低いチャネル: 200 kbps

ただし、メッセージをブロードキャストする場合、送信ビットレートの制限は動的であり、受信ビットレートによって異なります。 現在の実装では、送信ビットレートの制限は、最大送信ビットレートから受信ビットレートの 80% を引いた値として計算されます。

さらに、ブロードキャスト メッセージの送信時にはパケット レート制限も適用されます。 現在の制限は 1 秒あたり 80 パケットに設定され、メッセージ内の 1200 バイトごとを 1 パケットとしてカウントします。 これらの対策は、グループ通話の多数の参加者がメッセージをブロードキャストする場合のフラッディングを防ぐために実施されています。

次のステップ

詳細については、次の記事を参照してください。