Microsoft Teams でサービス品質 (QoS) を実装する
この記事は、Microsoft Teams でサービス品質 (QoS) を実装している管理者と IT プロフェッショナル向けです。
Microsoft Teams のサービス品質 (QoS) を使用すると、機密性の低いトラフィックよりもネットワーク遅延の影響を受けやすいリアルタイム ネットワーク トラフィックを優先できます。 たとえば、新しいアプリをダウンロードするよりも音声ストリームとビデオ ストリームを優先します (追加の 1 秒のダウンロードはそれほど目立ちません)。
QoS では、差別化されたサービス コード ポイント (DSCP) マーキングとポートベースのAccess Control Lists (ACL) を使用して、リアルタイム ストリーム内のすべてのパケットを識別、マーク、および分類します。 これにより、音声、ビデオ、および画面共有ストリームが、他の種類のトラフィックを犠牲にして優先処理を受けることができます。
何らかの形で QoS を使用しないと、音声とビデオで以下のような品質上の問題が生じる可能性があります。
ジッター – メディア パケットは異なるレートで到着します。これにより、呼び出しで単語や音節が欠落する可能性があります。
パケット損失 – パケットが破棄され、音声品質が低下し、音声がわかりにくい場合もあります。
遅延ラウンド トリップ時間 (RTT) – メディア パケットが宛先に到達するまでに長い時間がかかるため、会話中の 2 人のパーティー間で顕著な遅延が発生し、ユーザー同士が話し合うようになります。
この記事で説明する問題が発生している大規模なユーザー グループをサポートする場合は、QoS を実装する必要があります。 ユーザーが少ない小規模企業では QoS は必要ないかもしれませんが、ネットワーク遅延が発生している場合は考慮する必要があります。
これらの問題に対処する最も複雑な方法は、インターネットへの内部接続とインターネット接続の両方でデータ接続のサイズを大きくすることですが、この方法はコストが高くなることがよくあります。 QoS を使用すると、帯域幅を追加する代わりに、持っているリソースを管理できます。 品質の問題に対処するには、最初に QoS を使用してから、必要に応じて帯域幅を追加することをお勧めします。
QoS を有効にするには、組織全体に一貫性のある QoS 設定を適用する必要があります。 QoS の優先順位をサポートできないパスの部分では、通話、ビデオ、および画面共有の品質が低下する可能性があります。 すべてのユーザー PC またはデバイス、ネットワーク スイッチ、インターネットへのルーター、および Teams サービスに設定を適用する必要があります。
図 1. organizationのネットワークと Microsoft 365 または Office 365 サービスの関係
QoS の実装のチェックリスト
次のチェックリストでは、QoS を実装するために必要な手順の概要を示します。 この手順については、この記事全体で詳しく説明します。
次のガイドラインに留意してください。
- Microsoft 365 への最短パスが最適です。
- ポートを閉じると品質が低下します。
- プロキシなど、その間の障害は推奨されません。
- ポップ数を制限します:
- クライアントからネットワーク エッジ - 3 から 5 ホップ
- ISP から Microsoft ネットワーク エッジ - 3 ホップ
- Microsoft ネットワーク エッジから最終目的地 - 無関係
ファイアウォール ポートの構成については、「Office 365 URL と IP 範囲」を参照してください。
QoS キューの概要
QoS を提供するには、ネットワーク デバイスにトラフィックを分類する方法があり、音声またはビデオを他のネットワーク トラフィックと区別できる必要があります。
ネットワーク トラフィックがルーターに入ったら、トラフィックはキューに入れられます。 QoS ポリシーが構成されていない場合、1 つのキューのみが存在し、すべてのデータは同じ優先順位を持ち、先入先出法で処理されます。 つまり、音声トラフィック (遅延に非常に敏感) は、数ミリ秒の遅延が問題ではないトラフィックの背後でスタックする可能性があります。
QoS を実装するときは、Cisco のプライオリティ キューイングや Class-Based Weighted Fair Queueing (CBWFQ) などの輻輳管理機能のいずれかと、重み付けランダム早期検出 (WRED):などの輻輳回避機能を使用して、複数のキューを定義します。
図 2. QoS キューの例
わかりやすく例えると、QoS ではデータ ネットワークに仮想の "相乗り車線" を作成して、一部の種類のデータでは遅延がまったく生じない、またはほとんど生じないようにすることができます。 そのような車線を作成すると、組織ユーザーに提供するビジネス水準のエクスペリエンスを維持しながら、それらの車線の相対的なサイズを調整して、保有している接続帯域幅をより有効に管理できるようになります。
手順 1. ネットワークの準備ができていることを確認する
QoS の実装を検討している場合は、 帯域幅やその他のネットワーク要件を既に決定している必要があります。
ネットワーク全体のトラフィックの輻輳は、メディアの品質に大きな影響を与えます。 帯域幅が不足すると、パフォーマンスが低下し、ユーザー エクスペリエンスの品質低下につながります。 Teams の導入と使用がorganizationで拡大するにつれて、ネットワーク パフォーマンスを監視および管理する必要があります。 問題を特定し、QoS と選択的な帯域幅の追加を使用して調整を行うには、レポート、ユーザーごとの通話分析、通話品質ダッシュボード (CQD) の各ツールを使用します。
VPN に関する考慮事項
QoS は、呼び出し元間のすべてのリンクに実装されている場合にのみ、期待どおりに機能します。 内部ネットワークで QoS を使用し、ユーザーがリモートの場所からサインインする場合は、内部マネージド ネットワーク内でのみ優先順位を付けることができます。
リモートの場所は仮想プライベート ネットワーク (VPN) を実装することでマネージド接続を受信できますが、VPN は本質的にパケット オーバーヘッドを追加し、リアルタイム トラフィックに遅延を生み出します。 VPN 経由でリアルタイム通信トラフィックを実行しないようにすることをお勧めします。
大陸にまたがるマネージド リンクを含むグローバル organizationでは、これらのリンクの帯域幅が LAN と比較して制限されるため、QoS をお勧めします。
手順 2. QoS 実装方法を選択する
QoS を実装する方法は次のとおりです。
- ルーターでのポート ベースの DSCP (差別化されたサービス コード ポイント) のタグ付け
- クライアントが IP パケット ヘッダーに DSCP マーカーを挿入する
どちらの方法も 、DSCP マーカーに基づいています。 DSCP マーカーは、配送の緊急性と、迅速な配送のためにパッケージを並べ替える最善の方法を郵便作業者に示す郵便切手に例えることができます。 リアルタイム メディア ストリームに優先順位を付けるようにネットワークを構成すると、パケットの損失とパケットの遅延が大幅に減少します。
ルーターでのポート ベースのタグ付け
ポートベースのタグ付けを使用して、ネットワークのルーターは受信パケットを調べて、使用されるポートを決定します。 パケットが特定のポートまたはポート範囲を使用して到着した場合、ルーターはパケットを特定のメディア タイプとして識別します。 次に、ルータはそのタイプのキューにパケットを配置し、IP パケット ヘッダーに事前に設定された DSCP マークを追加して、他のデバイスがそのトラフィックタイプを認識し、キューに優先順位を付けることができます。
ポート ベースのタグ付けを実装するには、ネットワークのルーターでAccess Control Lists (ACL) を使用します。 ポートベースのタグ付けを実装する手順については、ルーターの製造元のドキュメントを参照してください。
ポートベースのタグ付けは、Windows、Mac、Linux の混在環境で動作するため、最も信頼性の高い方法です。 また、実装するのが最も簡単です。 ポートベースのタグ付けは異なるプラットフォーム間で機能しますが、クライアント マシンに到達するまでの経路全体ではなく、WAN エッジにおいてのみトラフィックがマークされるため、管理のオーバーヘッドが生じます。
クライアントが DSCP マーカーを挿入する
また、クライアント エンドポイントに IP パケット ヘッダーに DSCP マーカーを挿入するように要求することで、QoS を実装することもできます。 これを実現するには、エンドポイントの種類 (Windows、Mac、iOS、Android、Microsoft Teams Room システム) に応じて、複数の方法があります。これについては、この記事の実装セクションで説明します。
DSCP マーカーは、パケットを特定の種類のトラフィック (音声など) として識別します。 DSCP マーカーを認識するようにルーターやその他のネットワーク デバイスを構成し、トラフィックを別の優先度の高いキューに配置できます。
ベスト プラクティス
クライアント エンドポイントでの DSCP マーキングと、可能な場合はルーターのポート ベースのタグ付け ACL の組み合わせを使用することをお勧めします。 マネージド デバイス (たとえば、Intune) は、DSCP マーキングの構成を可能にする一元化されたポリシー制御の恩恵を受けます。一方、ルーター上のポートベース ACL では、クライアント側の DSCP マーキングを構成できないデバイスからのトラフィックを識別できます。
ネットワーク内のすべてのデバイスで同じ分類、マーキング、優先順位が使用されるようにすると、各トラフィックの種類で使用されるキューに割り当てられたポート範囲のサイズを変更することで、遅延、パケットの損失、ジッターを低減または排除することができます。
Teams の観点から見ると、最も重要な構成手順は、パケットの分類とマーキングです。 ただし、エンドツーエンドの QoS を成功させるには、アプリケーションの構成を基盤となるネットワークの構成に慎重に合わせる必要もあります。 QoS が完全に実装された後は、組織のニーズと実際の使用状況に基づいて、各トラフィックの種類に割り当てられたポート範囲を調整することが、継続的な管理上の課題となります。
手順 3. 各メディア タイプ用の初期ポート範囲を選択する
各種のリアルタイム ストリーミング ワークロードのポート範囲の相対サイズによって、対象ワークロードが独占的に使用できる合計帯域幅のうちの比率が決まります。 郵便サービスの類推を使用して:「エアメール」スタンプを持つ手紙は、最寄りの空港に1時間以内に撮影される可能性があります。一方、「バルクメール」とマークされた小さなパッケージは、一連のトラックで陸上を移動する前に1日待つことができます。
DSCP 値は、パケットまたはストリームに与える優先順位と、DSCP マークがクライアントによって割り当てられているか、または ACL 設定に基づいてネットワーク自体によって割り当てられているかを、対応するように構成されたネットワークに示します。 各メディア ワークロードは、独自の一意の DSCP 値と、メディアの種類ごとに使用される定義済みの個別のポート範囲を取得します。 (他のサービスではワークロードが DSCP マーキングを共有できる場合がありますが、Teams では共有されません)。他の環境には既存の QoS 戦略が組み込まれている可能性があります。これは、ネットワーク ワークロードの優先順位を決定するのに役立ちます。
推奨される初期ポート範囲
| メディア トラフィックの種類 | クライアントの送信元ポート範囲 | プロトコル | DSCP 値 | DSCP クラス |
|---|---|---|---|---|
| オーディオ | 50,000–50,019 | TCP/UDP | 46 | 完全優先転送 (EF) |
| ビデオ | 50,020–50,039 | TCP/UDP | 34 | 相対的優先転送 (AF41) |
| アプリケーション/画面共有 | 50,040–50,059 | TCP/UDP | 18 | 相対的優先転送 (AF21) |
これらの設定を使用する場合は、以下の点に注意してください。
モバイル クライアントや Teams デバイスを含むすべてのクライアントは、これらのポート範囲を使用し、これらの送信元ポート範囲を使用して実装するすべての DSCP ポリシーの影響を受けます。 動的ポートを引き続き使用するクライアントは、ブラウザーベースのクライアント (参加者を各自のブラウザーを使用して会議に参加させるクライアント) のみです。
Mac およびモバイル (iOS および Android) クライアントはこれらのソース ポート範囲を使用しますが、これらのクライアントはオーディオ (EF) とビデオおよびアプリケーション/画面共有 (AF41) にハードコーディングされた値を使用します。 これらの値を構成することはできません。
ユーザー エクスペリエンスを向上させるために、後でポート範囲を調整する必要がある場合は、ポート範囲が重なることなく、相互に隣接するようにする必要があります。
手順 4. QoS 設定を実装する
クライアントとネットワーク デバイスの QoS 設定を実装し、会議のメディア トラフィックを処理する方法を決定します。
前提条件として、Teams 管理 センターで QoS をグローバルに有効にします。 リアルタイム メディア トラフィック設定のサービス品質 (QoS) マーカーの挿入を有効にする方法の詳細については、「Teams 管理センターで QoS を構成する」を参照してください。
Windows エンドポイントの DSCP マーキングの構成については、「 Teams クライアントで QoS を実装する」を参照してください。
注意
従来の Teams から新しい Teams への移行の一環として、実行可能ファイル名が teams.exe (クラシック Teams) から ms-teams.exe (新しい Teams) に変更されました。
Mac およびモバイル (iOS および Android) クライアントは、オーディオ (EF) とビデオおよびアプリケーション/画面共有 (AF41) にハードコーディングされた値を使用します。 Teams 電話デバイスでは、オーディオ (EF) の既定値も使用されます。 ただし、これを機能させるには、Teams 管理 センターで QoS をグローバルに有効にする必要があります。 リアルタイム メディア トラフィックのサービス品質 (QoS) マーカーの挿入を有効にする方法の詳細については、「Teams 管理センターでの QoS の構成」を参照してください。
Microsoft Teams Rooms (Windows および Android) の DSCP マーキングの構成については、Teams Rooms デバイスでのサービス品質 (QoS) の構成に関するページを参照してください。
WINDOWS 10 TEAM OS を実行している Surface Hub デバイスの DSCP マーキングの構成については、「MDM プロバイダーを使用して Surface Hub を管理する」を参照してください。
ルーターの QoS の実装については、製造元のドキュメントを参照してください。
ネットワーク デバイスでの QoS の設定には、ポートベースのAccess Control Lists (ACL) の使用、QoS キューと DSCP マーキングの定義、またはこれらすべてが含まれる場合があります。
Important
これらの QoS ポリシーは、クライアントの送信元ポートと、送信元と宛先の IP アドレスを "any"として実装することをお勧めします。 これにより、内部ネットワーク上の受信と送信の両方のメディア トラフィックがキャッチされます。
手順 5. QoS の実装を検証する
QoS を有効にするには、呼び出しの両端に DSCP 値セットが存在する必要があります。 Teams クライアントによって生成されたトラフィックを分析することで、Teams のワークロード トラフィックがネットワーク内を移動するときに、DSCP 値が変更、または削除されていないことを確認できます。
可能であれば、ネットワークの出口ポイントでトラフィックをキャプチャします。 スイッチやルーターでポート ミラーリングを使用して、この問題を解決できます。
手順 6. ソース ポートを管理する
Teams の場合は、メディアの種類ごとに初期ポート範囲を選択した後 (手順 3 を参照)、必要に応じてさまざまなワークロードで使用される QoS ソース ポートを監視および調整する必要があります。 特定のメディアの種類に必要なポートが多い場合や少ない場合があります。
ポートを監視および管理する方法については、次を参照してください。
ポート範囲は調整できますが、DSCP マーキングを構成できないことに注意してください。
関連項目
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示