この記事では、Azure Communication Services の呼び出しフローについて説明します。 シグナルフローとメディア フローは、ユーザーが行っている通話の種類によって異なります。 通話の種類の例としては、1 対 1 の VoIP、1 対 1 の公衆交換電話網 (PSTN)、VoIP と PSTN に接続された参加者の組み合わせを含むグループ通話などがあります。 詳細については、「 通話の種類」を参照してください。
シグナリングとメディア プロトコル
ピア ツー ピアまたはグループ呼び出しを確立すると、2 つのプロトコルがバックグラウンドで使用されます。シグナル通知用の HTTPS (REST) とメディア用の Secure Real-Time Transport Protocol (SRTP) です。
SDK 間、または SDK と Communication Services シグナリング コントローラー間のシグナル通知は、HTTPS REST (TLS) で処理されます。 Azure Communication Services では TLS 1.2 が使用されます。 リアルタイム メディア トラフィック (RTP) の場合は、ユーザー データグラム プロトコル (UDP) をお勧めします。 ファイアウォールで UDP の使用が禁止されている場合、SDK はメディアに伝送制御プロトコル (TCP) を使用します。
さまざまなシナリオでシグナリングとメディア プロトコルを確認しましょう。
コール フロー ケース
ケース 1: 2 つのデバイス間に直接接続された VoIP
1 対 1 の VoIP またはビデオ通話では、トラフィックが最も直接的なパスを優先します。 ダイレクト パス は、2 つの SDK が互いに直接到達できる場合、直接接続を確立することを意味します。 2 つの SDK が同じサブネット (サブネット 192.168.1.0/24 など) にある場合、またはデバイスが互いに表示できるサブネット (サブネット 10.10.0.0/16 の SDK と 192.168.1.0/24 の SDK が互いに到達できる) に 2 つ存在する場合は、直接パスが可能です。
ケース 2: デバイス間で直接接続できないが、NAT デバイス間の接続が可能な VoIP
2 つのデバイスが互いに到達できないサブネットに配置されているが、ネットワーク アドレス変換 (NAT) デバイス間の接続が可能な場合、クライアント側 SDK は NAT デバイス経由で接続を確立します。 たとえば、Alice がコーヒー ショップで働き、Bob が自宅のオフィスで働いている場合などです。
Alice の場合は、コーヒー ショップの NAT であり、Bob の場合はホーム オフィスの NAT です。 Alice のデバイスは NAT の外部アドレスを送信し、Bob も同じように送信します。 SDK は、Azure Communication Services が無料で提供する NAT (STUN) サービスのセッション トラバーサル ユーティリティから外部アドレスを学習します。 Alice と Bob の間のハンドシェイクを処理するロジックは、Azure Communication Services が提供する SDK に埋め込まれています。 構成を追加する必要はありません。
ケース 3: 直接接続もNAT接続も不可能なVoIP
一方または両方のクライアント デバイスが対称 NAT の背後にある場合、2 つの SDK 間でメディアを中継するには、個別のクラウド サービスが必要です。 このサービスは、NAT (TURN) のリレーを使用したトラバーサルと呼ばれ、Azure Communication Services によっても提供されます。 Communication Services Calling SDK では、検出されたネットワーク条件に基づいて TURN サービスが自動的に使用されます。 TURN料金は通話料金に含まれています。
ケース 4: PSTN で通話をグループ化する
PSTN 通話のシグナリングとメディアの両方で、Azure Communication Services テレフォニー リソースが使用されます。 このリソースは、他の通信事業者と相互接続されています。
PSTN メディア トラフィックは、メディア プロセッサ コンポーネントを通過します。
注
また、メディア プロセッサは、 RFC 3261 SIP: セッション開始プロトコルで定義されているバック バック ユーザー エージェントでもあります。つまり、Microsoft と Carrier ネットワーク間の呼び出しを処理するときにコーデックを変換できます。 Azure Communication Services シグナリング コントローラーは、同じ RFC に従った Microsoft による SIP プロキシの実装です。
グループ呼び出しの場合、メディアとシグナリングは常に Azure Communication Services バックエンド経由で流されます。 すべての参加者のオーディオやビデオがメディア プロセッサに混在します。 グループ呼び出しのすべてのメンバーは、オーディオ ストリームとビデオ ストリームをメディア プロセッサに送信し、混合メディア ストリームを返します。
グループ呼び出しの既定のリアルタイム プロトコル (RTP) は、ユーザー データグラム プロトコル (UDP) です。
注
メディア プロセッサは、マルチポイント コントロール ユニット (MCU) または選択的転送ユニット (SFU) として機能できます。
ファイアウォールの制限により SDK がメディアに UDP を使用できない場合は、伝送制御プロトコル (TCP) の使用が試みられます。 メディア プロセッサ コンポーネントには UDP が必要であるため、この場合、Communication Services TURN サービスがグループ呼び出しに追加され、TCP が UDP に変換されます。 TURN料金は通話料金に含まれています。
ケース 5: スケジュールされた Teams 会議での Communication Services SDK とMicrosoft Teams
シグナリングは、シグナリング コントローラを通過します。 メディアはメディア プロセッサを通過します。 シグナリング コントローラーとメディア プロセッサは、Communication Services と Microsoft Teams の間で共有されます。
ケース 6: 初期メディア
呼び出し先がセッションを受け入れる前に交換される、音声や映像などのメディアを指します。 初期メディア フローの場合、セッション ボーダー コントローラー (SBC) は、ストリーミング メディアを開始する最初のエンドポイントにラッチする必要があります。メディア フローは、候補者が指名される前に開始できます。 SBC では、IVR/ボイスメール シナリオを有効にするには、このフェーズ中にデュアル トーンマルチ周波数 (DTMF) の送信をサポートする必要があります。 SBC は、申請が完了していない場合に、チェックを受ける最も優先度の高いパスを使用する必要があります。
次のステップ
関連資料
- 通話の種類の詳細
- クライアントとサーバーのアーキテクチャについて
- 通話フロー トポロジについて