Microsoft Teams の通話フロー

概要

この記事では、Teams がさまざまなトポロジで Microsoft 365 通話フローを使用する方法について説明します。 また、ピアツーピアのメディア 通信で使用される固有の Teams のフローについても説明します。 この記事では、これらのフロー、その目的、ネットワーク上でのフローの始端と終端について説明します。 この記事では次のことを想定しています:

• フロー X は、クラウド内の Microsoft 365 サービスと通信するために、オンプレミス クライアントによって使用されます。 顧客ネットワークから発信され、Microsoft 365 のエンドポイントとして終了します。

• フロー Y は、Microsoft 365 が依存関係を持つインターネット上のサービスと通信するために、オンプレミス クライアントによって使用されます。 これは、顧客ネットワークが始端となり、インターネット上のエンドポイントとして終端します。

この記事には、次の情報が記載されています:

• 背景。 フローが通過する可能性があるネットワーク、トラフィックの種類、顧客ネットワークから Microsoft 365 サービス エンドポイントへの接続ガイダンスなどの背景情報を提供します。 また、サード パーティのコンポーネントとの相互運用性と、Teams がメディア フローを選択するために使用する原則についても説明します。

• さまざまなトポロジにおける通話フロー。 さまざまなトポロジでの通話フローの使用を示します。 このセクションでは、各トポロジについて、サポートされるすべてのフローを列挙し、これらのフローの使用方法をいくつかのユース ケースを使って示します。 各ユース ケースについて、フローの順序と選択をフロー図を用いて示します。

• Teams と Express Route 最適化。 Express Route が最適化のために使用される場合の、これらのフローの使用方法について、単純なトポロジを使用して分かりやすく説明します。

背景

ネットワーク セグメント

顧客ネットワーク。 制御および管理するネットワーク セグメント。 このセグメントには、顧客オフィス内のすべての顧客接続 (有線またはワイヤレス、オフィス ビル間の接続、オンプレミスのデータセンターへの接続、インターネット プロバイダー、Express Route、またはその他のプライベート ピアリングへの接続) が含まれます。

通常、顧客ネットワークにはファイアウォールやプロキシ サーバーを備えた複数のネットワーク境界があり、organizationのセキュリティ ポリシーが適用され、設定して構成した特定のネットワーク トラフィックのみが許可されます。 このネットワークを管理するため、ネットワークのパフォーマンスを直接制御できます。 ネットワーク内のサイト内とネットワークから Microsoft 365 ネットワークへの両方のパフォーマンスを検証するには、ネットワーク評価を完了することをお勧めします。

インターネット。 顧客ネットワークの外部から Microsoft 365 に接続しているユーザーが使用するネットワーク全体の一部であるネットワーク セグメント。 このセグメントは、顧客ネットワークから Microsoft 365 への一部のトラフィックでも使用されます。

アクセスした、またはゲストのプライベート ネットワーク。 ユーザーとそのゲストがアクセスできるパブリック インターネットではなく、顧客ネットワークの外部にあるネットワーク セグメント。 たとえば、Teams を展開しないホーム プライベート ネットワークやエンタープライズ プライベート ネットワークなど、Teams サービスと対話するユーザーとその顧客が存在する可能性があります。

Microsoft 365。 Microsoft 365 サービスをサポートするネットワーク セグメント。 これは、ほとんどの場所で顧客ネットワークに近接したエッジで世界中に分散されています。 機能には、トランスポート リレー、会議サーバー、およびメディア プロセッサが含まれます。

Express Route (オプション)。 Microsoft 365 ネットワークへの専用のプライベート接続を提供する、ネットワーク全体の一部であるネットワーク セグメント。

トラフィックの種類

リアルタイムのメディア。 オーディオ、ビデオ、および画面共有のワークロードをサポートする RTP (リアルタイム転送プロトコル) 内にカプセル化されたデータ。 一般に、メディア トラフィックは非常に待機時間の影響を受けやすいです。 このトラフィックは、可能な限り最も直接的なパスを取得し、UDP と TCP をトランスポート層プロトコルとして使用する必要があります。これは、品質の観点から対話型リアルタイム メディアに最適なトランスポートです。 (最後の手段として、メディアは TCP/IP を使用でき、HTTP プロトコル内でもトンネリングできますが、品質への影響が悪いため推奨されません)。RTP フローは、ペイロードのみが暗号化される SRTP を使用してセキュリティで保護されます。

シグナリング。 クライアントとサーバーまたはその他のクライアントとの間の通信リンクで、アクティビティの制御 (たとえば、通話が開始された場合など) とインスタント メッセージの配信に使用されます。 ほとんどのシグナリング トラフィックでは HTTPS ベースの REST インターフェイスが使用されますが、一部のシナリオ (たとえば、Microsoft 365 とセッション ボーダー コントローラー間の接続) では SIP プロトコルが使用されます。 このトラフィックは遅延に対してあまり敏感ではありませんが、エンドポイント間に数秒を超える遅延があった場合、サービス停止や通話のタイムアウトが発生する可能性がある点にご注意ください。

Microsoft 365 への接続

Teams を使用するには、インターネットへの接続が必要です。 Teams のエンドポイントの URL と IP アドレスの範囲は、「Office 365 の URL と IP アドレスの範囲」に記載されています。 TCP ポート 80 と 443、UDP ポート 3478 (STUN)、3479 (オーディオ)、3480 (ビデオ)、3481 (共有/VBSS) へのオープン接続が必要です。

Teams のメディア フロー接続は、標準の IETF ICE (Interactive Connectivity Establishment) の手順に従って実装されます。

相互運用性の制限

サードパーティ製メディア リレー。 Teams のメディア フロー (つまり、いずれかのメディア エンドポイントが Teams である場合) は、Teams または Skype for Business のネイティブ メディア リレーのみを通過できます。 サード パーティ製メディア リレーとの相互運用性はサポートされていません。 (PSTN との境界にあるサード パーティの SBC は、RTP/RTCP ストリームを終了し、SRTP を使用してセキュリティで保護し、次ホップに中継しない必要があります)。

サードパーティの SIP プロキシ サーバー。 サードパーティの SBC および/またはゲートウェイを使用する Teams のシグナリング SIP ダイアログは、 Teams または Skype for Business のネイティブ SIP プロキシを通過する可能性があります。 サード パーティの SIP プロキシとの相互運用性はサポートされていません。

サードパーティ製 B2BUA (または SBC)。 PSTN との間の Teams メディア フローは、サードパーティ製 SBC で終了します。 ただし、Teams ネットワーク内のサードパーティー製 SBC との相互運用性 (つまり、サードパーティ製 SBC が Teams と Skype for Business の 2 つのエンドポイントの間を仲介しています) はサポートされていません。

Microsoft Teams では推奨されないテクノロジ

VPN ネットワーク。 メディア トラフィック (またはフロー 2') にはお勧めしません。 「Lync メディアが VPN トンネルをバイパス可能にする」で指定されているように、VPN クライアントはスプリット トンネルを使用し、外部の非 VPN ユーザーなどの Teams メディア トラフィックをルーティングする必要があります。

パケット シェーパー。 あらゆる種類のパケット スニッパー、パケット検査、またはパケット シェーパー デバイスは、Teams メディア トラフィックには推奨されず、品質が大幅に低下する可能性があります。

原則

Microsoft Teams の通話フローを理解するのに役立つ、4つの一般的な原則があります。

• Microsoft Teams 会議は、最初の参加者が参加したのと同じリージョンで Microsoft 365 によってホストされます。 (一部のトポロジでこの規則に例外がある場合は、このドキュメントで説明し、適切な呼び出しフローで示します)。

• Microsoft 365 の Teams メディア エンドポイントは、通話の種類に基づくのではなく、メディア処理のニーズに基づいて使用されます。 (たとえば、ポイントツーポイントの通話では、トランスクリプションおよび/または録音のためのメディア処理に、クラウド内のメディア エンドポイントを使用する場合がありますが、参加者が 2 人の会議ではクラウド内のメディア エンドポイントを使用しない場合があります。) ただし、ほとんどの会議では、ミキシングおよびルーティングのために、会議がホストされる場所に割り当てられているメディア エンドポイントが使用されます。 クライアントからメディア エンドポイントに送信されるメディア トラフィックは、お客様のネットワーク ファイアウォールの制限により、必要に応じて Microsoft 365 でトランスポート リレーを直接ルーティングすることも、使用することもできます。

• ピアツーピア通話のメディア トラフィックは、通話でクラウド内のメディア エンドポイントが要求されていない限り (上の原則を参照)、使用できる最も直接的なルートを使用します。 リモート ピア (クライアント) への直接のルートが優先されますが、このルートが利用できない場合は、1 つまたは複数のトランスポート リレーがトラフィックを中継します。 メディア トラフィックは、メディア品質に影響を与えるので、パケット シェーパー、VPN サーバーなどのサーバーを横断しないことをお勧めします。

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

選択されているメディア経路の詳細については、「Microsoft Teams のメディアフローを理解する-BRK4016」を参照してください。

さまざまなトポロジにおける通話フロー

Teams のトポロジ

このトポロジは、Skype for Business Server や電話システムのダイレクト ルーティングなどのオンプレミスの展開がない状態でクラウドから Teams のサービスを利用するお客様に使用されます。 さらに、Microsoft 365 へのインターフェイスは、Azure Express Route なしでインターネット経由で行われます。

図 1 - Teams のトポロジ

以下の点について留意してください。

• 図の矢印の方向は、エンタープライズ境界での接続に影響を与える通信の開始方向を反映しています。 メディアの UDP の場合、最初のパケットは逆方向に流れますが、これらのパケットは、他の方向のパケットが流れるまでブロックされる可能性があります。
• Teams は、Skype for Business Online と並行して展開されます。そのため、クライアントは "Teams/SFB ユーザー" として表示されています。

次のオプションのトポロジの詳細については、この記事の後の方で説明します。

• Skype for Business のオンプレミスの展開については、「Teams ハイブリッド トポロジ」を参照してください。
• 電話システムのダイレクト ルーティング (PSTN 接続用) については、「ダイレクト ルーティングを使用する Teams」を参照してください。
• Express Route については、「Express Route による Teams の最適化」を参照してください。

フローの説明

• フロー 2 – ユーザーが、Teams の操作の一部として顧客ネットワーク上で開始するインターネットへのフローを表します。 この種類のフローの例は、DNS とピアツーピア メディアです。
• フロー 2' – Teams のリモート モバイル ユーザーが VPN を使用して開始する顧客ネットワークへのフローを表します。
• フロー 3 – リモート モバイル Teams ユーザーによって開始された Microsoft 365 Teams エンドポイントへのフローを表します。
• フロー 4 – 顧客ネットワーク上のユーザーが Microsoft 365 Teams エンドポイントに開始するフローを表します。
• フロー 5 – Teams ユーザーと別の Teams ユーザーまたは顧客ネットワーク内の Skype for Business ユーザーの間のピアツーピア メディア フローを表します。
• フロー 6 – Teams のリモート モバイル ユーザーと別の Teams のリモート モバイル ユーザーまたは Skype for Business ユーザーの間の、インターネットを介したピアツーピア メディア フローを表します。

ユース ケース: 一対一

1 対 1 の呼び出しでは、呼び出し元が、ローカル、リレー、リフレクティブ (リレーで見られるクライアントのパブリック IP アドレス) 候補を含む IP アドレス/ポートで構成される一連の候補を取得する共通モデルを使用します。 発信者は、これらの候補を通話相手に送信します。通話を受けた相手は、同様の候補のセットを取得し、それを発信者に送信します。 STUN 接続確認メッセージは、発信者/受信者のメディア パスはどれが機能しているかを判断し、機能しているパスの中から最適のものを選択します。 その後、選択された候補のペアを使用してメディア (つまり、SRTP を介して保護された RTP/RTCP パケット) が送信されます。 トランスポート リレーは、Microsoft 365 の一部として展開されます。

ローカル IP アドレス/ポート候補または反射型候補に接続がある場合は、クライアント間 (または NAT を使用) 間の直接パスがメディアに対して選択されます。 クライアントが両方とも顧客ネットワーク上にいる場合は、ダイレクト パスが選択されるはずです。 これには、顧客ネットワーク内での UDP への直接接続が必要です。 クライアントが両方とも Nomadic Crowd のユーザーである場合、NAT/ファイアウォールによっては、メディアは直接接続を使用する可能性があります。

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

大まかな手順:

1. Teams ユーザー A が、フロー 2 経由で URL ドメイン名 (DNS) を解決します。
2. Teams ユーザー A が、フロー 4 経由で Teams トランスポート リレーでメディア リレー ポートを割り当てます。
3. Teams ユーザー A は、フロー 4 を使用して ICE 候補を含む "招待" を Microsoft 365 に送信します。
4. Microsoft 365 は、フロー 4 を使用して Teams ユーザー B に通知を送信します。
5. Teams ユーザー B が、フロー 4 経由で Teams トランスポート リレーでメディア リレー ポートを割り当てます。
6. Teams ユーザー B が、フロー 4 経由で「回答」 を ICE 候補と共に送信し、これはフロー 4 経由で Teams ユーザー A に戻されます。
7. Teams ユーザー A と Teams ユーザー B が ICE 接続テストを呼び出し、使用可能な最適なメディア パスが選択されています (さまざまなユース ケースについては、次の図を参照してください)。
8. Teams ユーザーは、フロー 4 を使用して Microsoft 365 にテレメトリを送信します。

顧客ネットワーク内:

図 2 - 顧客ネットワーク内

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

メディアは双方向です。 フロー 5 の方向は、この記事のすべてのフローの場合と同様、一方が通信を開始したことを接続の観点から示します。 このケースでは両方のエンドポイントが顧客ネットワーク内にあるため、使用されている方向を考慮する必要がありません。

顧客ネットワークから外部ユーザーへ (メディアは Teams トランスポート リレーが中継):

図 3 - 顧客ネットワークから外部ユーザーへ (メディアは Teams トランスポート リレーが中継):

手順 7 では、フロー 4、顧客ネットワークから Microsoft 365、フロー 3、リモート モバイル Teams ユーザーから Microsoft 365 までが選択されています。 これらのフローは、Microsoft 365 内の Teams トランスポート リレーによって中継されます。

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

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

図 4 - 顧客ネットワークから外部ユーザーへ (ダイレクト メディア)

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

• リモート モバイル ユーザー (Microsoft 365 経由で中継されない) を含むダイレクト メディアは省略可能です。 言い換えると、お客様はこのパスをブロックして、Microsoft 365 の Transport Relay を介してメディア パスを適用できます。

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

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

図 5 - VPN ユーザーから内部ユーザーへ (メディアは Teams トランスポート リレーが中継)

VPN と顧客ネットワークとの間のシグナリングは、フロー 2' を使用しています。 顧客ネットワークと Microsoft 365 の間のシグナリングでは、フロー 4 が使用されています。 ただし、メディアは VPN をバイパスし、Microsoft 365 の Teams メディア リレーを介してフロー 3 と 4 を使用してルーティングされます。

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

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

VPN と顧客ネットワークとの間のシグナリングは、フロー 2' を使用しています。 顧客ネットワークと Microsoft 365 の間のシグナリングでは、フロー 4 が使用されています。 ただし、メディアは VPN をバイパスし、フロー 2 (顧客ネットワークからインターネット) 経由でルーティングされます。

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

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

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

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

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

ユース ケース: Microsoft 365 トランクを介して Teams から PSTN へ

Microsoft 365 には、公衆交換電話網 (PSTN) からの通話の発信と受信を許可する電話システムがあります。 PSTN トランクが電話システムの通話プランで接続されている場合、このユース ケースに関しては特別な接続要件はありません。 (独自のオンプレミス PSTN トランクを Microsoft 365 に接続する場合は、電話システム ダイレクト ルーティングを使用できます)。

図 8 - Microsoft 365 トランクを介して Teams から PSTN へ

ユースケース: Teams 会議

オーディオ/ビデオ/画面共有 (VBSS) 会議サーバーは、Microsoft 365 の一部です。 これには顧客ネットワークから到達可能である必要があるパブリック IP アドレスが含まれ、これは、Nomadic Cloud のクライアントから到達可能である必要があります。 各クライアント/エンドポイントは、会議サーバーに接続できる必要があります。

内部クライアントは、1 対 1 の呼び出しで説明したのと同じ方法で、ローカル、リフレクティブ、リレーの候補を取得します。 クライアントは、これらの候補を招待で会議サーバーに送信します。 会議サーバーは、パブリックに到達可能な IP アドレスがあるため、リレーを使用しないため、ローカル IP アドレス候補で応答します。 クライアントと会議サーバーは、1 対 1 の呼び出しについて説明したのと同じ方法で接続をチェックします。

以下の点について留意してください。

• Teams クライアントはSkype for Business会議に参加できません。また、Skype for Businessクライアントは Teams 会議に参加できません。

• PSTN ユーザーは、会議開催者の PSTN 通話および/または会議のプロビジョニングに応じて、「ダイヤル イン」 または「ダイヤル アウト」することもできます。

• ゲストまたは顧客は、厳密な規則を使用して FW/NAT を使用して保護されるゲスト プライベート ネットワークから参加できます。

図 9 - Teams 会議

ユース ケース: Skype for Business オンプレミス とのフェデレーション

Microsoft 365 の Teams トランスポート リレーによって中継されるメディア

図 10 - Microsoft 365 で Teams トランスポート リレーによって中継されるメディア

以下の点について留意してください。

• フェデレーションは、その性質上、2 つのテナント間の通信です。 この例では、Teams を使用する テナント A は、Skype for Business オンプレミスを使用するテナント B とフェデレーションします。 テナント B も Microsoft 365 を使用している場合、Skype for Business クライアントはフロー 3 を使用して Microsoft 365 に接続します。

• フェデレーションされた Skype for Business クライアントからオンプレミスの Skype for Business サーバーへのシグナリングとメディアについては、この記事では説明しません。 ただし、わかりやすくするためにここに示します。

• Teams と Skype for Business の間のシグナリングは、ゲートウェイによりブリッジされます。

• メディアはこの場合、Teams トランスポート リレーにより、フロー 4 経由で 顧客ネットワークとリモートの Skype for Business クライアントに中継されます。

フェデレーションされたテナントの Skype for Business メディア リレーによって中継されるメディア

図 11 - フェデレーションされたテナントの Skype for Business メディア リレーによって中継されるメディア

次の点に注意してください。

• フェデレーションされた Skype for Business クライアントからオンプレミスの Skype for Business サーバーへのシグナリングとメディアについては、この記事では説明しませんが、 ただし、わかりやすくするためにここに示します。

• Teams と Skype for Business の間のシグナリングは、ゲートウェイによりブリッジされます。

• メディアはこの場合、Skype for Business オンプレミス メディア リレーにより、フロー 2 経由で顧客ネットワークに中継されます。 (Teams ユーザーからフェデレーション顧客ネットワーク内のリモート Media Relay へのトラフィックは、逆方向のトラフィックが流れ始めるまで、メディア リレーによって最初にブロックされることに注意してください。ただし、双方向フローは双方向の接続を開きます)。

直接 (ピアツーピア)

図 12 - 直接 (ピアツーピア)

Teams ハイブリッド トポロジ

このトポロジには、Skype for Business のオンプレミス展開を使用する Teams が含まれます。

図 13 - Teams ハイブリッド トポロジ

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

• Teams は、Skype for Business Online と並行して展開されます。そのため、クライアントは "Teams/SFB ユーザー" として表示されています。

その他のフロー (Teams のトポロジへの追加)

• フロー 5 A – 顧客ネットワーク内の Teams ユーザーと、顧客ネットワークのエッジにある Skype for Business オンプレミス メディア リレーとの間の、ピアツーピアのメディア フローを表します。

ユース ケース: Teams から Skype for Business へ、一対一

顧客ネットワーク内のハイブリッド

図 14 - 顧客ネットワーク内のハイブリッド

Teams と Skype for Business の間のシグナリングは、ゲートウェイによりブリッジされます。 ただし、メディアは顧客ネットワーク内で、フロー 5 経由でピアツーピアに直接ルーティングされます。

外部Skype for Business ユーザーを持つハイブリッド 顧客ネットワーク – Microsoft 365 によって中継

図 15 - 外部Skype for Business ユーザーを持つハイブリッド顧客ネットワーク - Microsoft 365 によって中継

次の点に注意してください。

• Skype for Business クライアントからオンプレミスの Skype for Business サーバーへのシグナリングとメディアについては、この記事では説明しませんが、 説明をわかりやすくするためにこれを図に示します。

• Teams と Skype for Business の間のシグナリングは、ゲートウェイによりブリッジされます。

• メディアは、 Teams トランスポート リレーを通して、フロー 4 経由で顧客ネットワークに中継されます。

ハイブリッドの顧客ネットワークから外部の Skype for Business ユーザーへ (オンプレミス エッジ により中継)

図 16 - ハイブリッドの顧客ネットワークから外部の Skype for Business ユーザーへ (オンプレミス エッジ により中継)

次の点に注意してください。

• Skype for Business クライアントからオンプレミスの Skype for Business サーバーへのシグナリングとメディアについては、この記事では説明しませんが、 説明をわかりやすくするためにこれを図に示します。

• シグナリングは、ゲートウェイによってブリッジされます。

• メディアは、Skype for Business オンプレミス エッジ内の Skype for Business メディア リレーにより、フロー 5A 経由で顧客ネットワーク内の Teams ユーザーに中継されます。

電話システムのダイレクト ルーティングを使用する Teams のトポロジ

このトポロジには、電話システムのダイレクト ルーティングを使用する Teams が含まれます。

ダイレクト ルーティングを使用すると、サポートされているオンプレミスの顧客所有のセッション ボーダー コントローラー (SBC) ハードウェア デバイスを Microsoft 365 にペアリングし、テレフォニー トランクをそのデバイスに接続することで、サード パーティの公衆交換電話網 (PSTN) サービス プロバイダーを使用できます。

このシナリオをサポートするには、顧客は、Microsoft の認定パートナーのいずれかによりダイレクト ルーティング用に認定された SBC を展開する必要があります。 SBC はベンダーが推奨するように構成し、直接 UDP トラフィックに対して Microsoft 365 からルーティング可能である必要があります。 メディアは、Teams および/または Skype for Business クライアントから SBC に直接流れることも (Teams ゲートウェイをバイパスして)、Teams ゲートウェイを通過することもできます。 トランクが Teams ゲートウェイをバイパスするように構成されている場合は、SBC との接続は ICE に基づきます。SBC では ICE-Lite がサポートされ、Teams/Skype for Business のメディア エンドポイントでは ICE フル フォームがサポートされます。

*図 17 - 電話システムのダイレクト ルーティングを使用する Teams のトポロジ

次の点に注意してください。

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

• Teams は、Skype for Business Online と並行して展開されます。そのため、クライアントは "Teams/SFB ユーザー" として表示されています。

その他のフロー (Teams のトポロジへの追加):

• フロー 4' - クラウド内の Teams メディア サーバーとオンプレミスの SBC との間の接続を確立するために使用される、Microsoft 365 から顧客ネットワークへのフローを表します。
• フロー 5B - バイパス モードでの、顧客ネットワーク内の Teams ユーザーとバイパス モードのダイレクト ルーティング SBC のメディア フローを表します。
• フロー 5C – PSTN ヘアピン コール バイパス モードでの、ダイレクト ルーティング SBC と別のダイレクト ルーティング SBC と間のメディア フローを表します。

ダイレクト ルーティングによる内部ユーザー (メディアはTeams トランスポート リレーが中継)

図 18 - ダイレクト ルーティングによる内部ユーザー (メディアは Teams トランスポート リレーが中継)

次の点に注意してください。

• SBC には、Microsoft 365 からルーティング可能なパブリック IP アドレスが必要です。

• SBC から Microsoft 365 へのシグナリングとメディア、またはその逆の場合は、フロー 4 またはフロー 4' を使用します。

• 顧客ネットワーク内のクライアントから Microsoft 365 へのシグナリングとメディアは、フロー 4 を使用します。

ダイレクト ルーティングを使用するリモート ユーザー (メディアは メディア サーバー (MP) 経由でルーティング)

図 19 - ダイレクト ルーティングを使用するリモート ユーザー (メディアはメディア サーバー (MP) 経由でルーティング)

次の点に注意してください。

• SBC には、Microsoft 365 からルーティング可能なパブリック IP アドレスが必要です。

• SBC から Microsoft 365 へのシグナリングとメディア、またはその逆の場合は、フロー 4 またはフロー 4' を使用します。

• インターネット上のクライアントから Microsoft 365 へのシグナリングとメディアは、フロー 3 を使用します。

内部ユーザーのダイレクト ルーティング (メディアはバイパス)

図 20 - 内部ユーザーのダイレクト ルーティング (メディアはバイパス)

次の点に注意してください。

• SBC には、Microsoft 365 からルーティング可能なパブリック IP アドレスが必要です。

• SBC から Microsoft 365 へのシグナリング、またはその逆の場合は、フロー 4 またはフロー 4' を使用します。

• 顧客ネットワーク内のクライアントから Microsoft 365 に通知するには、フロー 4 を使用します。

• 顧客ネットワーク内のクライアントから顧客ネットワーク内の SBC へのメディアは、フロー 5B を使用します。

ダイレクト ルーティングによるリモート ユーザー (メディアのパイパスは Teams トランスポート リレーが中継)

図 21 - ダイレクト ルーティングによるリモート ユーザー (メディアのパイパスは Teams トランスポート リレーが中継)

次の点に注意してください。

• SBC には、Microsoft 365 とインターネットからルーティングできるパブリック IP アドレスが必要です。

• SBC から Microsoft 365 へのシグナリング、またはその逆のシグナル処理では、フロー 4 またはフロー 4' が使用されます。

• インターネット上のクライアントから Microsoft 365 へのシグナリングでは、フロー 3 が使用されます。

• インターネット上のクライアントから顧客ネットワーク内の SBC へのメディアでは フロー 3 および 4 が使用されTeams トランスポート リレーにより中継されます。

ダイレクト ルーティングによるリモート ユーザー (メディアのバイパスはダイレクト)

図 22 - リモート ユーザーのダイレクト ルーティング (メディアのバイパスはダイレクト)

次の点に注意してください。

• SBC には、Microsoft 365 とインターネットからルーティングできるパブリック IP アドレスが必要です。

• SBC から Microsoft 365 へのシグナリング、またはその逆のシグナル処理では、フロー 4 またはフロー 4' が使用されます。

• インターネット上のクライアントから Microsoft 365 へのシグナリングでは、フロー 3 が使用されます。

• インターネット上のクライアントから顧客ネットワーク内の SBC へのメディアは、 フロー 2 を使用します。

ダイレクト ルーティング (メディア バイパス) – PSTN ヘアピン コール (通話の転送を原因とする)

図 23 - ダイレクト ルーティング (メディア バイパス) – PSTN ヘアピン コール (通話の転送を原因とする)

次の点に注意してください。

• SBC には、Microsoft 365 からルーティング可能なパブリック IP アドレスが必要です。

• SBC から Microsoft 365 へのシグナリング、またはその逆のシグナル処理では、フロー 4 またはフロー 4' が使用されます。

• PSTN から PSTN への通話のヘアピンが発生すると、クライアントはシグナリングおよびメディア ループに含まれなくなります。

• 顧客ネットワーク内の SBC インスタンス A から顧客ネットワーク内の SBC インスタンス B までのメディア (A と B は同じインスタンスの可能性もあります) は、フロー 5C を使用します。

ダイレクト ルーティング (Microsoft 365 経由のメディア) – 2 つのテナント間での PSTN ヘアピン呼び出し

図 24 - ダイレクト ルーティング (Microsoft 365 経由のメディア) – 2 つのテナント間での PSTN ヘアピン呼び出し

次の点に注意してください。

• SBC には、Microsoft 365 からルーティング可能なパブリック IP アドレスが必要です。

• SBC から Microsoft 365 へのシグナリング、またはその逆のシグナル処理では、フロー 4 またはフロー 4' が使用されます。

• PSTN から PSTN への通話のヘアピンが発生すると、クライアントはシグナリングおよびメディア ループに含まれなくなります。

• 顧客ネットワーク X 内の SBC インスタンス A から SBC インスタンス B へのメディアは、Microsoft 365 Media Server 経由で中継する必要があり、バイパス モードを使用できません。

Express Route による Teams の最適化

図 25 - Express Route による Teams の最適化

Express Route が正当化されて展開されているケースでは、Teams のフローはフロー 4 からフロー 1 に、またフロー 4' からフロー 1' に再ルーティングできます。 ただし、Teams アプリケーションは、フロー 4 と 4' を使用してインターネット経由の他の Microsoft 365 フローにハード依存関係があります。そのため、これらのフローをブロックしないでください。

Skype for Business のハイブリッド エッジ トラフィックは、外部ユーザーとの通信および他のテナントとのフェデレーションを行うために、Express Route ではなくインターネットにルーティングされることに注意してください。

非対称のフローを防ぐには、再ルーティングは双方向に行う必要があります。 つまり、顧客ネットワーク内のアドレスは、(最適化のために) インターネットまたは Express Route のいずれを経由してもルーティング可能ですが、両方を経由することはできません。

顧客ネットワークから外部ユーザーへ (メディアは Teams トランスポート リレーが中継):

図 26 - 顧客ネットワークから外部ユーザーへ (メディアは Teams トランスポート リレーが中継)

大まかな手順:

1. 顧客ネットワーク内の Teams ユーザーが、フロー 2 経由で URL ドメイン名 (DNS) を解決します。
2. 顧客ネットワーク内の Teams ユーザーが、フロー 1 経由で Teams トランスポート リレーでメディア リレー ポートを割り当てます。
3. 顧客ネットワーク内の Teams ユーザーは、フロー 1 を使用して ICE 候補を含む "招待" を Microsoft 365 に送信します。
4. Microsoft 365 は、フロー 3 を使用して外部の Teams ユーザーに通知を送信します。
5. Teams の外部ユーザーが、フロー 3 経由で Teams トランスポート リレーでメディア リレー ポートを割り当てます。
6. Teams の外部ユーザーが、フロー 3 経由で「回答」 を ICE 候補と共に送信し、これはフロー 1 経由で Teams ユーザー A に再び転送されます。
7. Teams ユーザー A および Teams ユーザー B が ICE 接続テストを実行してフロー 1 および フロー 3 を選択し、これらは Teams トランスポート リレーにより中継されます。
8. Teams ユーザーは、フロー 1 と 3 を使用して Microsoft 365 にテレメトリを送信します。