データチャネル

2025-06-05

注

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

データチャネル API を使用すると、オーディオとビデオの呼び出し中にリアルタイムメッセージングを実行できます。この API を使用すると、データ交換機能をアプリケーションに簡単に統合できるようになり、ユーザーにシームレスな通信エクスペリエンスが提供されます。主な機能は次のとおりです。

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

一般的なユースケース

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

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

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

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

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

重要な概念

一方向の通信

データチャネル 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 接続によってチャネルの持続性が確保されます。ただし、メッセージがエンドツーエンドで失われないことを意味するものではありません。グループ呼び出しのコンテキストでは、送信者とサーバー間のメッセージ損失の防止を示します。ピアツーピア呼び出しでは、送信側とリモートエンドポイントの間の信頼性の高い送信を示します。

注

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

優先順位

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

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

ビットレート

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

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

セッション

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

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

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

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

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

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

シーケンス番号

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

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

制限事項

メッセージサイズ

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

参加者リスト

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

レート制限

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

信頼性のあるチャネル（耐久性）：64 kbps
信頼性の低いチャネル (損失): 512 kbps
高優先度の信頼性の低いチャネル: 200 kbps

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

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

次のステップ

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

次の方法で共有

データ チャネル

一般的なユース ケース