次の方法で共有

通話フローのトポロジ

この記事では、Azure Communication Services の呼び出しフロー トポロジと、呼び出しトラフィックの暗号化方法について詳しく説明します。 Azure Communication Services の通話フローの概要については、「 通話ネットワークの内部」を参照してください。

バックグラウンド

ネットワークの概念

呼び出しフロー トポロジを確認する前に、この記事で使用する用語を理解しておくと役立ちます。

顧客ネットワークには、管理するネットワーク セグメントが含まれています。 顧客ネットワークには、オフィス内、オフィス、データセンター、インターネット サービス プロバイダー間の有線およびワイヤレス ネットワークが含まれる場合があります。

通常、顧客ネットワークには、組織のセキュリティ ポリシーを適用するファイアウォールまたはプロキシ サーバーを含む複数のネットワーク境界があります。 通信ソリューションの最適なパフォーマンスと品質を実現するために、 包括的なネットワーク評価 を実行することをお勧めします。

Azure Communication Services ネットワークは、Azure Communication Services をサポートするネットワークです。 Microsoft は、このネットワークを管理し、エンド カスタマーに最も近い Microsoft 所有のデータセンターで世界中に配布します。 このネットワークは、トランスポート リレー、グループ呼び出しのメディア処理、および豊富なリアルタイム メディア通信をサポートするその他のコンポーネントを担当します。

トラフィックの種類

Azure Communication Services は、主に リアルタイム メディア と シグナリングという 2 種類のトラフィックに基づいて構築されています。

リアルタイム メディアは、Real-Time トランスポート プロトコル (RTP) を介して送信されます。 このプロトコルは、オーディオ、ビデオ、および画面共有データ転送をサポートします。 このデータは、ネットワーク待機時間の問題の影響を受けます。 TCP または HTTP を使用してリアルタイム メディアを送信することもできますが、ユーザー データグラム プロトコル (UDP) をトランスポート層プロトコルとして使用して、高パフォーマンスのエンド ユーザー エクスペリエンスをサポートすることをお勧めします。 RTP 経由で送信されるメディア ペイロードは、セキュア RTP (SRTP) を介してセキュリティで保護されます。

Azure Communication Services ソリューションのユーザーは、クライアント デバイスからサービスに接続します。 シグナリングは、 これらのデバイスとサーバー間の通信を処理します。 たとえば、デバイスとサービス間 のシグナリング では、通話開始とリアルタイム チャットがサポートされます。 ほとんどのシグナリング トラフィックでは、HTTPS REST が使用されます。 一部のシナリオでは、信号トラフィック プロトコルとしてセッション開始プロトコル (SIP) を使用できます。 この種類のトラフィックは待機時間の影響を受けにくいものの、待機時間の短いシグナル通知は、エンド ユーザーエクスペリエンスを快適に提供します。

メディアの暗号化

SDK および Teams クライアントを呼び出す Azure Communication Services の通話フローは、HTTPS 経由の セッション記述プロトコル (SDP) RFC 8866 オファーと応答モデルに基づいています。 呼び出し先が着信呼び出しを受け入れると、呼び出し元と呼び出し先はセッション パラメーターに同意します。

メディア トラフィックは暗号化され、SRTP を介して呼び出し元と呼び出し先の間を流れます。SRTP は、RTP トラフィックに対する機密性、認証、およびリプレイ攻撃保護を提供する RTP のプロファイルです。 ほとんどの場合、クライアント間メディア トラフィックはクライアント間接続シグナリングを介してネゴシエートされ、クライアントからクライアントに直接移動するときに SRTP を介して暗号化されます。

SDK クライアントを呼び出す Azure Communication Services インスタンスは、データグラム トランスポート層セキュリティ (DTLS) を使用して暗号化キーを派生させます。 DTLS ハンドシェイクが完了すると、メディアは SRTP 経由でこの DTLS ネゴシエートされた暗号化キーを通過し始めます。

SDK および Teams クライアントを呼び出す Azure Communication Services インスタンスは、TURN 経由でメディア リレーに安全にアクセスするために資格情報ベースのトークンを使用します。 メディア リレーは、トランスポート層セキュリティ (TLS) のセキュリティで保護されたチャネルを介してトークンを交換します。

Azure Communication Services のオーディオ、ビデオ、ビデオの共有に参加する 2 つのエンドポイント間で行われるメディア トラフィックは、SRTP を使用してメディア ストリームを暗号化します。 暗号化キーは、TLS 1.2 と AES-256 (GCM モード) で暗号化された UDP/TCP チャネルを使用するシグナリング プロトコルを介して、2 つのエンドポイント間でネゴシエートされます。

呼び出しフローの原則

Azure Communication Services の呼び出しフローを支える 4 つの一般的な原則があります。

  • Azure Communication Services グループ呼び出しの最初の参加者によって、呼び出しがホストされるリージョンが決まります。 一部のトポロジでは、この規則には例外があります。この記事の後半で説明します。

  • Azure Communication Services 呼び出しをサポートするために使用されるメディア エンドポイントは、メディア処理のニーズに基づいて選択され、通話の参加者数の影響を受けません。

    たとえば、ポイントツーポイント通話では、クラウドのメディア エンドポイントを使用して、文字起こしや記録のためにメディアを処理できます。 2 人の参加者を含む呼び出しでは、メディア エンドポイントが使用されない場合があります。 グループ呼び出しでは、混合とルーティングの目的でメディア エンドポイントが使用されます。

    このエンドポイントは、呼び出しがホストされているリージョンに基づいて選択されます。 クライアントからメディア エンドポイントに送信されるメディア トラフィックは、直接ルーティングされる場合があります。 または、お客様のネットワーク ファイアウォール制限で必要な場合は、Azure でトランスポート リレーを使用する場合があります。

  • ピアツーピア呼び出しのメディア トラフィックは、通話にクラウド内のメディア エンドポイントが必要ないことを前提として、 使用可能な最も直接的なルートを受け取ります。

    優先ルートは、リモート ピア (クライアント) に直接送信されます。 直接ルートを使用できない場合は、1 つ以上のトランスポートリレーがトラフィックを転送します。 メディア トラフィックは、パケット シェーパーや仮想プライベート ネットワーク (VPN) サーバーのように動作するサーバーを走査したり、処理を遅らせ、エンド ユーザー エクスペリエンスを低下させる可能性があるその他の機能を実行したりしないでください。

  • 信号トラフィックは常に 、ユーザーに最も近いサーバーに送信されます。

メディア パスの詳細については、 呼び出しフローの概念ドキュメントを参照してください。

各種トポロジにおける通話フロー

Azure Communication Services (インターネット)

この呼び出しフロー トポロジの例は、Azure 直接ルーティングなど、オンプレミスのデプロイなしでクラウドから Azure Communication Services を使用しているお客様を示しています。 このトポロジでは、Azure Communication Services との間のトラフィックがインターネット経由で流れます。

インターネット経由でクラウドベースのユーザーによって開始された Azure Communication Services の呼び出しフロー トポロジを示す図。

前の図の矢印の方向は、エンタープライズ境界での接続に影響を与える初期通信の方向を反映しています。 UDP メディアの場合、最初のパケットは逆方向に流れますが、パケットが他の方向に流れるまで、これらのパケットはブロックされる可能性があります。

フローの説明

  • フロー 2: ユーザーの Azure Communication Services エクスペリエンスの一部として、顧客ネットワーク上のユーザーが開始したインターネットへのフローを表します。 これらのフローの例には、DNS とピアツーピア メディアの送信が含まれます。
  • フロー 2': 顧客ネットワークへの VPN を使用するリモート モバイル Azure Communication Services ユーザーによって開始されるフローを表します。
  • フロー 3: リモート モバイルの Azure Communication Services ユーザーが Azure Communication Services エンドポイントに対して開始したフローを表します。
  • フロー 4: 顧客ネットワーク上のユーザーが Azure Communication Services に開始したフローを表します。
  • フロー 5: 1 人の Azure Communication Services ユーザーと顧客ネットワーク内の別のユーザーとの間のピア ツー ピア メディア フローを表します。
  • フロー 6: リモート モバイル Azure Communication Services ユーザーとインターネット経由の別のリモート モバイル Azure Communication Services ユーザーとの間のピア ツー ピア メディア フローを表します。

ユース ケース: 1 対 1 の呼び出し

1 対 1 の呼び出しとは、あるユーザーが別のユーザーを直接呼び出すということです。 呼び出しを初期化するために、呼び出し元 SDK は IP アドレスとポートで構成される候補のセットを取得します。 このセットには、ローカル、リレー、リフレクティブ (リレーで見られるクライアントのパブリック IP アドレス) の候補が含まれます。 呼び出し元 SDK は、これらの候補を呼び出し先に送信します。 呼び出し先は、同様の候補のセットを受け取り、呼び出し元に送信します。

システムは、STUN 接続チェック メッセージを使用して、どの呼び出し元/呼び出し側メディア パスが動作するかを見つけ、最適な作業パスを選択します。 システムは、接続パスを確立した後、接続に対して DTLS ハンドシェイクを実行してセキュリティを確保します。 DTLS ハンドシェイクの後、システムは DTLS ハンドシェイク プロセスから SRTP キーを派生させます。 その後、選択した候補ペアを介してメディア (RTP/RTCP パケットが SRTP によって保護されます) が送信されます。 トランスポート リレーは、Azure Communication Services の一部として利用できます。

ローカル IP アドレスとポート候補、または再帰候補に接続がある場合は、クライアント間の直接パス (または NAT を使用している場合) がメディア用に選択されます。 両方のクライアントがカスタマー ネットワークに存在する場合は、直接パスが選択されなければなりません。 この選択には、顧客ネットワーク内の直接 UDP 接続が必要です。 クライアントが両方とも遊牧民のクラウド ユーザーである場合、NAT/ファイアウォールによっては、メディアが直接接続を使用する可能性があります。

1 つのクライアントが顧客ネットワーク上の内部にあり、1 つのクライアントが外部 (モバイル クラウド ユーザーなど) である場合、ローカル候補または再帰候補間の直接接続が有効になる可能性はほとんどありません。 この場合は、いずれかのクライアントからトランスポート リレー候補のいずれかを使用できます。 たとえば、内部クライアントは Azure のトランスポート リレーからリレー候補を取得し、外部クライアントは STUN/RTP/RTCP パケットをトランスポート リレーに送信できる必要があります。 もう 1 つのオプションは、内部クライアントがモバイル クラウド クライアントによって取得されたリレー候補に送信することです。 メディアには UDP 接続を強くお勧めしますが、TCP はサポートされています。

高レベルの手順

  1. Azure Communication Services ユーザー A は、Flow 2 を使用して URL ドメイン名 (DNS) を解決します。

  2. ユーザー A は、Flow 4 を使用して Teams トランスポート リレーにメディア リレー ポートを割り当てます。

  3. ユーザー A は、Flow 4 を使用して対話型接続確立 (ICE) 候補を含む 招待 を Azure Communication Services に送信します。

  4. Azure Communication Services は、Flow 4 を使用してユーザー B に通知します。

  5. ユーザー B は、Flow 4 を使用して Teams トランスポート リレーにメディア リレー ポートを割り当てます。

  6. ユーザー B は、フロー 4 を使用して ICE 候補を含む 回答 を送信します。これは、フロー 4 を使用してユーザー A に転送されます。

  7. ユーザー A とユーザー B が ICE 接続テストを呼び出すと、使用可能な最適なメディア パスが選択されます。 次の図を確認して、さまざまなユース ケースを確認します。

  8. どちらのユーザーも、Flow 4 を使用して Azure Communication Services にテレメトリを送信します。

顧客ネットワーク (イントラネット)

2 人の Azure Communication Services ユーザー間の顧客ネットワーク内のトラフィック フローを示す図。

手順 7 では、ピア ツー ピア メディア Flow 5 が選択されています。

このメディア伝送は双方向です。 フロー 5 の方向は、一方の側が接続の観点から通信を開始することを示します。 この場合、どちらのエンドポイントも顧客ネットワーク内にあるため、どちらの方向を使用するかは関係ありません。

外部ユーザーへの顧客ネットワーク (Teams トランスポート リレーによって中継されるメディア)

Azure トランスポート リレーを介した外部ユーザーとの 1 対 1 の通話フローを示す図。

手順 7 では、フロー 4 (顧客ネットワークから Azure Communication Services へ) とフロー 3 (リモート モバイル Azure Communication Services ユーザーから Azure Communication Services へ) が選択されています。

Teams トランスポート リレーは、Azure 内でこれらのフローを処理します。

このメディア伝送は双方向です。 方向は、接続の観点から通信を開始する側を示します。 この場合、これらのフローはシグナリングとメディアに使用され、異なるトランスポート プロトコルとアドレスが使用されます。

外部ユーザーへの顧客ネットワーク (ダイレクト メディア)

ダイレクト メディアを持つ外部ユーザーとの 1 対 1 の通話フローを示す図。

手順 7 では、フロー 2 (顧客ネットワークからインターネット経由でクライアントのピアへ) が選択されています。

リモート モバイル ユーザー (Azure 経由で中継されない) を使用したダイレクト メディアは省略可能です。 言い換えると、このパスをブロックして、Azure のトランスポート リレーを介してメディア パスを適用できます。

このメディア伝送は双方向です。 リモート モバイル ユーザーへのフロー 2 の方向は、一方の側が接続の観点から通信を開始することを示します。

内部ユーザーへの VPN ユーザー (Teams トランスポート リレーによって中継されるメディア)

Azure トランスポート リレー経由の内部ユーザーと VPN ユーザーの間の 1 対 1 の呼び出しフローを示す図。

顧客ネットワークへの VPN 間のシグナル通知では、Flow 2' が使用されます。 顧客ネットワークと Azure の間のシグナル通知では、Flow 4 が使用されます。 ただし、メディアは VPN をバイパスし、フロー 3 とフロー 4 を介して Azure Media Relay 経由でルーティングされます。

VPN ユーザーから内部ユーザー (ダイレクト メディア)

内部ユーザーと直接メディアを使用する VPN ユーザーの間の 1 対 1 の呼び出しフローを示す図

顧客ネットワークへの VPN 間のシグナル通知では、Flow 2' が使用されます。 顧客ネットワークと Azure の間のシグナル通知では、Flow 4 が使用されます。 ただし、メディアは VPN をバイパスし、フロー 2 経由で顧客ネットワークからインターネットにルーティングされます。

このメディア伝送は双方向です。 リモート モバイル ユーザーへのフロー 2 の方向は、一方の側が接続の観点から通信を開始することを示します。

VPN ユーザーから外部ユーザー (ダイレクト メディア)

直接メディアを使用して VPN ユーザーを呼び出す外部ユーザーの 1 対 1 の通話フローを示す図。

VPN ユーザーから顧客ネットワークへのシグナル通知では、Flow 2' と Flow 4 から Azure を使用します。 ただし、メディアは VPN をバイパスし、Flow 6 経由でルーティングされます。

このメディア伝送は双方向です。 リモート モバイル ユーザーへのフロー 6 の方向は、一方の側が接続の観点から通信を開始することを示します。

ユース ケース: Azure Communication Services トランクを介して PSTN に対する Azure Communication Services クライアント

Azure Communication Services では、公衆交換電話網 (PSTN) からの通話の発信と受信を行うことができます。 PSTN トランクが Azure Communication Services によって提供される電話番号を介して接続されている場合、このユース ケースには特別な接続要件はありません。 独自のオンプレミス PSTN トランクを Azure Communication Services に接続する場合は、Azure ダイレクト ルーティングを使用できます。

Azure トランク回線を介した内部ユーザーと PSTN 参加者の間の 1 対 1 の通話を示す図。

この場合、顧客ネットワークから Azure へのシグナリングとメディアは Flow 4 を使用します。

ユース ケース: Azure Communication Services グループ呼び出し

オーディオ、ビデオ、画面共有を提供するサービスは、Azure Communication Services の一部です。 これには、顧客ネットワークと遊牧民クラウド クライアントの両方から到達できる必要があるパブリック IP アドレスがあります。 各クライアントとエンドポイントは、サービスに接続できる必要があります。

内部クライアントにより、前述した 1 対 1 の通話と同じ方法で、ローカル、リフレキシブ、リレーの各候補が取得されます。 クライアントは、これらの候補を招待でサービスに送信します。 パブリックに到達可能な IP アドレスがあるため、サービスはリレーを使用しないため、ローカル IP アドレス候補で応答します。 クライアントとサービスは、1 対 1 の呼び出しについて説明されているのと同じ方法で接続を確認します。

外部ユーザーとモバイル ユーザーの間の Azure Communication Services グループ呼び出しを示す図。

相互運用性の制限

Azure Communication Services を通過するメディアは、次のように制限されます。

  • サードパーティ セッション ボーダー コントローラー (SBC):PSTN との境界上の SBC は、SRTP を介してセキュリティで保護された RTP/RTCP ストリームを終了し、次ホップに中継しないようにする必要があります。 フローを次ホップにリレーすると、それが認識されない可能性があります。

  • サード パーティの SIP プロキシ サーバー: サードパーティの SBC やゲートウェイを使用した Azure Communication Services シグナリング SIP ダイアログは、Microsoft ネイティブ SIP プロキシ (Teams と同様) を走査する場合があります。 サードパーティの SIP プロキシとの相互運用性はサポートされていません。

  • サード パーティ B2BUA (または SBC):サードパーティの SBC は、PSTN との間でこれらの Azure Communication Services メディア フローを終了します。 Azure Communication Services ネットワーク内 (サード パーティの SBC が 2 つの Azure Communication Services エンドポイントを仲介する) 内のサード パーティの SBC との相互運用性はサポートされていません。

サポートされていないテクノロジ

  • VPN: Azure Communication Services では、VPN 経由のメディア転送はサポートされていません。 ユーザーが VPN クライアントを使用している場合は、「 Lync メディアで VPN トンネルをバイパスできるようにする」で指定されているように、クライアントは VPN 以外の接続経由でメディア トラフィックを分割してルーティングする必要があります。

    注

    タイトルは Lync を示しますが、Azure Communication Services と Teams に適用できます。

  • パケット シェーパー: パケット 切り取り、パケット検査、またはパケット シェーピングデバイスはサポートされておらず、品質が大幅に低下する可能性があります。

次のステップ

通話を始める

関連コンテンツ

  • Last updated on