次の方法で共有

通話フローの基礎

  • [アーティクル]

次のセクションでは、Azure Communication Services での通話フローの概要を示します。 信号とメディアのフローは、ユーザーが行う通話の種類によって異なります。 通話の種類の例としては、一対一の VoIP、一対一の PSTN、および VoIP と PSTN で接続された参加者の組み合わせを含むグループ通話などがあります。 通話の種類を確認してください。

信号とメディアのプロトコルについて

ピアツーピアまたはグループ通話を確立する際には、2 つのプロトコル (信号用の HTTPS (REST) とメディア用の SRTP) がバックグラウンドで使用されます。

SDK 間、または SDK と Communication Services Signaling Controllers 間の信号は、HTTPS REST (TLS) を使用して処理されます。 Azure Communication Services では TLS 1.2 が使われます。 リアルタイム メディア トラフィック (RTP) の場合、ユーザー データグラム プロトコル (UDP) が優先されます。 ファイアウォールによって UDP の使用が許可されない場合、SDK は、メディア用に伝送制御プロトコル (TCP) を使用します。

さまざまなシナリオでの信号とメディアのプロトコルを確認します。

通話フローのケース

ケース 1: 2 つのデバイス間の直接接続が可能な VoIP

一対一の VoIP またはビデオ通話では、トラフィックは最も直接的なパスを優先します。 "直接パス" とは、2 つの SDK がお互いを直接参照できる場合に、直接接続を確立することを意味します。 これは、通常、2 つの SDK が同じサブネット (サブネット 192.168.1.0/24 など) に存在する場合、または 2 つのデバイスがお互いを参照できるサブネットにそれぞれ存在する (サブネット 10.10.0.0/16 および 192.168.1.0/24 の SDK が相互に到達できる) 場合に可能です。

Diagram showing a Direct VOIP call between users and Communication Services.

ケース2: デバイス間の直接接続はできないが、NAT デバイス間の接続は可能な VoIP

サブネットに配置された 2 つのデバイスが相互に到達できない (たとえば、Alice がコーヒー ショップで仕事をしていて、Bob がホーム オフィスで仕事をしている) が、NAT デバイス間の接続は可能な場合、クライアント側の SDK は NAT デバイス経由で接続を確立します。

Alice の場合、コーヒー ショップの NAT が使用され、Bob の場合、ホーム オフィスの NAT が使用されます。 Alice のデバイスは彼女の NAT の外部アドレスを送信し、Bob のデバイスも同様に送信します。 SDK は、Azure Communication Services が無料で提供している STUN (Session Traversal Utilities for NAT) サービスから外部アドレスを学習します。 Alice と Bob との間のハンドシェイクを処理するロジックは、Azure Communication Services 提供の SDK 内に組み込まれています。 (追加の構成は不要です)

Diagram showing a VOIP call which utilizes a STUN connection.

ケース 3: 直接接続も NAT 接続もできない VoIP

一方または両方のクライアント デバイスが対称 NAT の内側にある場合は、2 つの SDK 間でメディアを中継するための別のクラウド サービスが必要です。 このサービスは、TURN (Traversal Using Relays around NAT) と呼ばれ、Communication Services でも提供されています。 Communication Services の Calling SDK は、検出されたネットワーク状態に基づいて自動的に TURN サービスを使用します。 通話料金には TURN 料金が含まれています。

Diagram showing a VOIP call which utilizes a TURN connection.

ケース 4: PSTN でのグループ通話

PSTN 通話の信号とメディアの両方で、Azure Communication Services のテレフォニー リソースが使用されます。 このリソースは、他の通信事業者と相互接続されています。

PSTN メディア トラフィックは、メディア プロセッサと呼ばれるコンポーネントを介して流れます。

Diagram showing a PSTN Group Call with Communication Services.

Note

メディア処理に詳しいユーザー向けに、メディア プロセッサは (「rfc 3261 SIP: セッション開始プロトコル」で定義されており、Microsoft と通信事業者ネットワーク間の通話を処理するときにコーデックを変換できることを意味する) Back to Back User Agent でもあります。 Azure Communication Services Signaling Controller は、同じ RFC に準拠した SIP プロキシの Microsoft の実装です。

グループ通話の場合、メディアと信号は常に Azure Communication Services バックエンドを介して流れます。 すべての参加者のオーディオまたはビデオ、あるいはその両方は、メディア プロセッサ コンポーネントでミックスされます。 グループ通話のすべてのメンバーは、オーディオまたはビデオ ストリーム、あるいはその両方をメディア プロセッサに送信し、そこからミックスされたメディア ストリームが返されます。

グループ通話の既定のリアルタイム プロトコル (RTP) は、ユーザー データグラム プロトコル (UDP) です。

Note

メディア プロセッサは、Multipoint Control Unit (MCU) または Selective Forwarding Unit (SFU) として機能できます。

Diagram showing UDP media process flow within Communication Services.

ファイアウォールの制限が原因で、SDK がメディアに対して UDP を使用できない場合は、伝送制御プロトコル (TCP) の使用が試行されます。 メディア プロセッサ コンポーネントには UDP が必要であるため、このような場合、TCP を UDP に変換するために Communication Services TURN サービスがグループ通話に追加されることに注意してください。 通話料金には TURN 料金が含まれています。

Diagram showing TCP media process flow within Communication Services.

ケース 5: スケジュールされた Teams の会議に Communication Services SDK と Microsoft Teams が参加

シグナリングのフローは、シグナリング コントローラーを経由します。 メディアのフローは、メディア プロセッサを経由します。 シグナリング コントローラーとメディア プロセッサは、Communication Services と Microsoft Teams との間で共有されます。

Diagram showing Communication Services SDK and Teams Client in a scheduled Teams meeting.

ケース 6: 初期メディア

呼び出されたユーザーが特定のセッションを受け入れる前に交換されるメディア (オーディオやビデオなど) を指します。 初期メディア フローがある場合、SBC はストリーミング メディアを開始する最初のエンドポイントにラッチする必要があります。メディア フローは、候補者が指名される前に開始できます。 SBC には、IVR/ボイスメール シナリオを有効にするために、このフェーズ中に DTMF を送信するためのサポートが必要です。 SBC は、申請が完了していない場合にチェックを受けた最も優先度の高いパスを使用する必要があります。

次のステップ

通話を開始する

次のドキュメントもご覧ください。