通話フローのトポロジ

この記事では、Azure Communication Services における通話フローのトポロジについて説明します。 この記事では、Azure Communication Services のネットワーク概念、呼び出しトラフィックの暗号化方法について説明します。Communication Services の通話フローの概要については、「通話フローの概念に関するドキュメント」を参照してください。

背景

ネットワークの概念

通話フローのトポロジを確認する前に、このドキュメントで言及されているいくつかの用語を定義しておきましょう。

カスタマー ネットワークには、貴社が管理するネットワーク セグメントが存在します。 これには、オフィス内のワイヤード (有線) ネットワークとワイヤレス ネットワークのほか、オフィスとデータ センターとインターネット サービス プロバイダーを結ぶワイヤード ネットワークおよびワイヤレス ネットワークが含まれる場合もあります。

通常、カスタマー ネットワークにはいくつかのネットワーク境界が存在し、そこに組織のセキュリティ ポリシーを適用するプロキシ サーバーやファイアウォールが配置されます。 ご利用の通信ソリューションに最適なパフォーマンスと品質を確保するために、包括的なネットワーク評価を実施することをお勧めします。

"Communication Services ネットワーク" は、Azure Communication Services をサポートするネットワークです。 このネットワークは Microsoft によって管理されており、エンド カスタマーに最も近い Microsoft 所有のデータ センターを使用して世界中に分散されています。 トランスポートのリレー、グループ通話のメディア処理など、多彩なリアルタイム メディア通信をサポートするコンポーネントをこのネットワークが担っています。

トラフィックの種類

Communication Services の基礎となるのは、主としてリアルタイム メディアとシグナリングという 2 種類のトラフィックです。

リアルタイム メディアは、リアルタイム転送プロトコル (RTP) を使用して転送されます。 このプロトコルは、音声、動画、画面共有のデータ伝送をサポートします。 このデータは、ネットワーク待ち時間が大きな問題となります。 リアルタイム メディアの転送に TCP や HTTP を使用することもできますが、ハイパフォーマンスのエンドユーザー エクスペリエンスをサポートするために、トランスポートレイヤー プロトコルとしては UDP の使用をお勧めします。 RTP で転送されるメディア ペイロードは、SRTP を使用してセキュリティが確保されます。

Communication Services ソリューションのユーザーは、各自のクライアント デバイスからサービスに接続しています。 これらのデバイスとサーバーの間の通信処理には、シグナリングが使用されます。 たとえば通話の開始やリアルタイム チャットを支えているのは、デバイスとサービスの間のシグナリングです。 ほとんどのシグナリング トラフィックには HTTPS REST が使用されますが、一部のシナリオでは、シグナリング トラフィック プロトコルとして SIP が使用されることもあります。 このタイプのトラフィックは待ち時間がさほど問題になりませんが、低遅延のシグナリングにより、ソリューションのユーザーに快適なエンドユーザー エクスペリエンスがもたらされます。

メディアの暗号化

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

呼び出し元と呼び出し先の間のメディア トラフィックは暗号化されて流れます。これには、リアルタイム転送プロトコル (RTP) のプロファイルであり、RTP トラフィックに機密性、認証、リプレイ攻撃保護を提供するセキュア RTP (SRTP) が使われます。 ほとんどの場合、クライアント間メディア トラフィックはクライアントからサーバーへの接続シグナリングを介してネゴシエートされ、クライアントからクライアントに直接移動するときに SRTP を使用して暗号化されます。

Azure Communication Services Calling SDK は、DTLS を使って暗号化キーを派生させます。 DTLS ハンドシェイクが完了すると、この DTLS でネゴシエートされた暗号化キーを使って SRTP 経由でメディアのフローが始まります。

AZURE Communication Services Calling SDK および Teams クライアントでは、TURN 経由でメディア リレーに安全にアクセスするために資格情報ベースのトークンが使用されます。 メディア リレーにより、TLS で保護されたチャネルを介してトークンが交換されます。

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

通話フローの原則

Azure Communication Services の通話フローは 4 つの一般的な原則に支えられています。

• 通話がホストされるリージョンは、Communication Services のグループ通話の最初の参加者によって決まる。 後ほど説明するとおり、一部のトポロジでは、このルールに例外があります。
• Communication Services の通話をサポートするために使用されるメディア エンドポイントは、メディア処理のニーズに基づいて選択され、通話への参加者の数には左右されません。 たとえば、ポイントツーポイントの通話で、文字起こしやレコーディング用のメディアを処理するためにクラウド内のメディア エンドポイントが使用されることがあります。一方、参加者 2 名の通話でも、メディア エンドポイントは使用されないことがあります。 グループ通話では、ミキシングやルーティングを目的としてメディア エンドポイントが使用されます。 このエンドポイントは、通話がホストされているリージョンに基づいて選択されます。 クライアントからメディア エンドポイントに送信されたメディア トラフィックは直接ルーティングされるほか、(カスタマー ネットワークのファイアウォール制限によって要求された場合) Azure のトランスポート リレーがトラフィックに使用されることもあります。
• ピアツーピア通話のメディア トラフィックには、利用可能な最も直接的なルートが使用される (クラウド内のメディア エンドポイントを必要としない通話の場合)。 優先されるルートは、リモート ピア (クライアント) との直接ルートです。 直接ルートを使用できない場合は、1 つまたは複数のトランスポート リレーによりトラフィックが転送されます。 メディア トラフィックは、パケット シェーパー、VPN サーバーのように、処理の遅延につながったり、エンドユーザー エクスペリエンスを低下させたりする働きをするサーバーを通過すべきではありません。
• シグナリング トラフィックは必ず、ユーザーに最も近いサーバーに向かう。

選択されるメディア パスについて詳しくは、通話フローの概念に関するドキュメントを参照してください。

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

Communication Services (インターネット)

このトポロジは、Azure 直接ルーティングなどのオンプレミス デプロイを使わず、クラウドから Communication Services を利用するお客様向けです。 このトポロジでは、Communication Services との間でやり取りされるトラフィックがインターネットを経由します。

図 1 - Communication Services のトポロジ

上の図の矢印の方向には、エンタープライズ境界での接続に影響を与える通信の開始方向が反映されています。 メディアの UDP の場合、最初のパケットが逆方向に流れる場合がありますが、もう一方向のパケットが流れるようになるまで、それらのパケットはブロックされます。

フローの説明:

• フロー 2 – ユーザーの Communication Services エクスペリエンスの一部として、カスタマー ネットワーク上のユーザーがインターネットに対して開始するフローを表します。 こうしたフローの例としては、DNS やピアツーピア メディア伝送があります。
• フロー 2' – カスタマー ネットワークへの VPN で、リモート モバイル Communication Services ユーザーが開始するフローを表します。
• フロー 3 - リモート モバイル Communication Services ユーザーが Communication Services エンドポイントに向けて開始するフローを表します。
• フロー 4 - カスタマー ネットワーク上のユーザーが Communication Services に向けて開始するフローを表します。
• フロー 5 - カスタマー ネットワーク内の Communication Services ユーザーどうしでやり取りされるピアツーピア メディア フローを表します。
• フロー 6 - リモート モバイル Communication Services ユーザーどうしがインターネット上でやり取りするピアツーピア メディア フローを表します。

ユース ケース: 1 対 1 の通話

1 対 1 の通話とは、あるユーザーが別のユーザーを直接呼び出すことです。 呼び出しを初期化するために、Calling SDK は、ローカル、リレー、リフレキシブ (リレーで見られるクライアントのパブリック IP アドレス) 候補を含む IP アドレスとポートで構成される候補のセットを取得します。 呼び出し元 SDK がこれらの候補を呼び出し先に送信すると、呼び出し先も、同様の候補のセットを取得して呼び出し元に送信します。 正常に機能している呼び出し元と呼び出し先のメディア パスが、STUN 接続チェック メッセージを使用して特定され、最適なパスが選択されます。 接続パスが確立されると、この接続を介して DTLS ハンドシェイクが実行され、セキュリティが確保されます。 DTLS ハンドシェイクの後、SRTP キーは DTLS ハンドシェイク プロセスから生成されます。 その後、選択された候補のペアを使用して、メディア (SRTP を使用して保護された RTP または RTCP パケット) が送信されます。 トランスポート リレーは、Azure Communication Services の一部として利用できます。

ローカル IP アドレスとポートの候補、またはリフレキシブ候補に接続性がある場合、クライアント間の直接パス (またはNATを使用) がメディア用に選択されます。 両方のクライアントがカスタマー ネットワークに存在する場合は、直接パスが選択されなければなりません。 そのためには、直接 UDP 接続がカスタマー ネットワーク内に存在している必要があります。 クライアントがどちらもノマド クラウド ユーザーである場合、NAT (またはファイアウォール) に応じて、メディアに直接接続を使用することができます。

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

大まかな手順:

1. Communication Services ユーザー A がフロー 2 を使用して URL のドメイン名 (DNS) を解決します。
2. ユーザー A がフロー 4 を使用して、Teams トランスポート リレーにメディア リレー ポートを割り当てます。
3. Communication Services ユーザー A がフロー 4 を使用し、ICE 候補を含む "招待状" を Communication Services に送信します。
4. Communication Services がフロー 4 を使用してユーザー B に通知します。
5. ユーザー B がフロー 4 を使用して、Teams トランスポート リレーにメディア リレー ポートを割り当てます。
6. ユーザー B がフロー 4 を使用して、ICE 候補を含む "応答" を送信します。この応答が、フロー 4 を使用してユーザー A に転送されます。
7. ユーザー A とユーザー B が ICE 接続テストを呼び出し、利用できる最適なメディア パスが選択されます (各種のユース ケースについては下の各図を参照してください)。
8. 両方のユーザーがフロー 4 を使用して Communication Services にテレメトリを送信します。

カスタマー ネットワーク (イントラネット)

図 2 - カスタマー ネットワーク内

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

このメディア伝送は双方向です。 フロー 5 の方向は、接続の観点から一方の側が通信を開始することを示します。 このケースでは、両方のエンドポイントがカスタマー ネットワーク内に存在するため、どちらの方向が使用されるかは問題ではありません。

カスタマー ネットワークから外部ユーザー (メディアは Teams トランスポート リレーによって中継)

図 3 - カスタマー ネットワークから外部ユーザー (メディアは Azure トランスポート リレーによって中継)

手順 7. で、フロー 4 (カスタマー ネットワークから Communication Services) とフロー 3 (リモート モバイル Communication Services ユーザーから Azure Communication Services) が選択されます。

これらのフローは、Azure 内の Teams トランスポート リレーによって中継されます。

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

カスタマー ネットワークから外部ユーザー (ダイレクト メディア)

図 4 - カスタマー ネットワークから外部ユーザー (ダイレクト メディア)

手順 7. で、フロー 2 (カスタマー ネットワークからインターネット経由でクライアントのピア) が選択されます。

リモート モバイル ユーザーとの (Azure によって中継されない) ダイレクト メディアは任意です。 つまり、Azure のトランスポート リレーを経由したメディア パスを強制的に適用するために、このパスはブロックすることができます。

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

VPN ユーザーから内部ユーザー (メディアは Teams トランスポート リレーによって中継)

図 5 - VPN ユーザーから内部ユーザー (メディアは Azure Relay によって中継)

VPN とカスタマー ネットワークとの間のシグナリングにはフロー 2* が使用されます。 カスタマー ネットワークと Azure との間のシグナリングにはフロー 4 が使用されます。 一方、メディアは VPN をバイパスし、フロー 3 とフロー 4 を使用して、Azure メディア リレー経由でルーティングされます。

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

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

VPN とカスタマー ネットワークとの間のシグナリングにはフロー 2' が使用されます。 カスタマー ネットワークと Azure との間のシグナリングにはフロー 4 が使用されています。 一方、メディアは VPN をバイパスし、カスタマー ネットワークからフロー 2 を使用してインターネットへとルーティングされます。

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

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

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

VPN ユーザーとカスタマー ネットワークとの間のシグナリングにはフロー 2* が、さらに Azure との間のシグナリングにはフロー 4 が使用されます。 一方、メディアは VPN をバイパスし、フロー 6 を使用してルーティングされます。

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

ユース ケース: Communication Services トランク経由で Communication Services クライアントから PSTN へ

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

図 8 -Communication Services ユーザーが Azure トランク経由で PSTN に接続

この場合、カスタマー ネットワークから Azure へのシグナリングとメディアにはフロー 4 が使用されます。

ユース ケース: Communication Services のグループ通話

VBSS (音声、動画、画面共有) サービスは、Azure Communication Services に含まれます。 このサービスには、カスタマー ネットワークおよびノマド クラウド クライアントから到達可能なパブリック IP アドレスが割り当てられます。 それぞれのクライアントとエンドポイントがサービスに接続できる必要があります。

内部クライアントにより、前述した 1 対 1 の通話と同じ方法で、ローカル、リフレキシブ、リレーの各候補が取得されます。 クライアントから、これらの候補者が招待状でサービスに送られます。 このサービスにはパブリックに到達可能な IP アドレスが割り当てられているため、リレーは使用されません。そのため応答には、対応するローカル IP アドレス候補が使用されます。 クライアントとサービスにより、前述した 1 対 1 の通話と同じ方法で接続性が検査されます。

図 9 - Communication Services のグループ通話

相互運用性の制限

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

SRTP を使用してセキュリティが確保された RTP/RTCP ストリームは、PSTN との境界にあるサードパーティのセッション ボーダー コントローラー (SBC) によって終了され、ネクスト ホップにリレーされません。 そのフローをネクスト ホップにリレーしたとしても、正しく解釈されないでしょう。

サードパーティの SIP プロキシ サーバー。 サードパーティの SBC やゲートウェイに対する Communication Services のシグナリング SIP ダイアログは、Microsoft ネイティブの SIP プロキシを通過できます (Teams と同様)。 サードパーティの SIP プロキシとの相互運用性はサポートされていません。

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

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

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

パケット シェーパー。 パケット スニッピング、パケット インスペクション、パケット シェーピングの各デバイスはサポートされておらず、品質が著しく低下する可能性があります。

次のステップ

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

• 通話の種類についてさらに学習する
• クライアント - サーバー アーキテクチャについて学習する