Microsoft Teams でサービスの品質 (QoS) を実装するImplement Quality of Service (QoS) in Microsoft Teams

この記事では、Microsoft Teams のサービス品質 (QoS) のために組織のネットワークを準備する方法について説明します。This article will help you prepare your organization's network for Quality of Service (QoS) in Microsoft Teams. 大規模なユーザーグループをサポートしていて、次のいずれかの問題が発生している場合は、おそらく QoS を実装する必要があります。If you are supporting a large group of users and they are experiencing any of the problems mentioned below, you probably need to implement QoS. ユーザー数の少ない小規模企業は、QoS を必要としない場合もありますが、役に立ちます。A small business with few users may not need QoS, but even there it should be helpful.

QoS は、ネットワークの遅延に敏感なトラフィック (音声やビデオストリームなど) を使用して、機密度の低いトラフィック (新しいアプリのダウンロードなど) を実行することによって、(ダウンロードがあまり重要ではない) トラフィックを事前に行うことができます。QoS is a way to allow real-time network traffic (like voice or video streams) that is sensitive to network delays to "cut in line" in front of traffic that is less sensitive (like downloading a new app, where an extra second to download isn't a big deal). QoS は、リアルタイムストリーム内のすべてのパケット (Windows グループポリシーオブジェクトと、ポートベースのアクセス制御リストと呼ばれるルーティング機能を使用します) を識別してマークします。これにより、ネットワークで音声、ビデオ、画面の共有を行うことができます。ネットワーク帯域幅の専用部分。QoS identifies and marks all packets in real-time streams (using Windows Group Policy Objects and a routing feature called Port-based Access Control Lists, more about those is below) which then helps your network to give voice, video, and screen share streams a dedicated portion of network bandwidth.

QoS の形式がないと、音声とビデオで次の品質の問題が発生する可能性があります。Without some form of QoS, you might see the following quality issues in voice and video:

  • ジッター–さまざまな料金で受信するメディアパケット。通話に単語または音節が含まれていない可能性があります。Jitter – media packets arriving at different rates, which can result in missing words or syllables in calls.
  • パケット損失–パケットが破棄されたため、音声品質が低下し、音声認識が困難になることもあります。Packet loss – packets dropped, which can also result in lower voice quality and hard to understand speech.
  • 遅延ラウンドトリップ時間 (RTT) –時間がかかるメディアパケットによって、会話の2つの当事者間の間に顕著な遅延が発生し、他のユーザーが互いに話すことができます。Delayed round trip time (RTT) – media packets taking a long time to reach their destinations, which results in noticeable delays between two parties in a conversation, causing people to talk over each other.

これらの問題に対処するための最も複雑な方法は、内部とインターネットの両方でデータ接続のサイズを大きくすることです。The least complex way to address these issues is to increase the size of the data connections, both internally and out to the internet. 多くの場合、QoS はコストがかかるため、新しいリソースを追加する代わりに、リソースをより効果的に管理する手段となります。Since that is often cost-prohibitive, QoS provides a way to more effectively manage the resources you have instead of adding new resources. 品質の問題を完全に解決するには、実装で QoS を使い、必要な場合にのみ接続を追加します。To fully address quality issues you would use QoS across the implementation, then add connectivity only where absolutely necessary.

Qos を有効にするには、qos の優先順位をサポートしていないパスの任意の部分によってパフォーマンスが低下する可能性があるため、一貫した QoS 設定をエンドツーエンドで適用する必要があります (これには、すべてのユーザーの Pc、ネットワークスイッチ、ルーターが含まれます)。通話、ビデオ、画面共有の品質。For QoS to be effective, you will have to apply consistent QoS settings end to end in your organization (This includes all user PCs, network switches, and routers to the internet), because any part of the path that fails to support your QoS priorities can degrade the quality of calls, video, and screen shares.

図1組織のネットワークと Office 365 サービスの間の関係Figure 1. The relationship between an organization's networks and Office 365 services

ネットワークとサービス間の関係を示す図Illustration of the relationship between networks and services

ほとんどの場合、企業をクラウドに接続するネットワークは管理されていないネットワークとなり、QoS オプションを確実に設定することはできません。In most cases, the network connecting your enterprise to the cloud will be an unmanaged network where you won't be able to reliably set QoS options. エンドツーエンドの QoS に対応する選択肢の1つはAzure ExpressRouteですが、オンプレミスネットワークに qos を実装することをお勧めします。One choice available to address end-to-end QoS is Azure ExpressRoute, but we still recommend that you implement QoS on your on-premises network. これにより、展開中のリアルタイム通信の負荷が増大し、また、チョークのポイントが軽減されます。This will increase the quality of real-time communication workloads throughout your deployment and alleviate chokepoints.

ネットワークの準備ができていることを確認するVerify your network is ready

QoS の実装を検討している場合は、帯域幅要件とその他のネットワーク要件を既に決定しておく必要があります。If you are considering a QoS implementation, you should already have determined your bandwidth requirements and other network requirements.

ネットワーク全体でのトラフィック渋滞は、メディアの品質に大きく影響します。Traffic congestion across a network will greatly impact media quality. 帯域幅の不足は、パフォーマンスの低下を招き、ユーザーエクスペリエンスが低下します。A lack of bandwidth leads to performance degradation and a poor user experience. チームの導入と使用量が増加するにつれて、レポート、通話分析、通話品質ダッシュボードを使用して問題を特定し、QoS と選択的な帯域幅の追加機能を使って調整を行います。As Teams adoption and usage grows, use reporting, Call Analytics, and Call Quality Dashboard to identify problems and then make adjustments using QoS and selective bandwidth additions.

VPN に関する考慮事項VPN considerations

QoS は、呼び出し元間のすべてのリンクに実装されている場合にのみ動作します。QoS only works as expected when implemented on all links between callers. 内部ネットワークで QoS を使用していて、ユーザーが遠隔地からサインインしている場合は、内部の管理されたネットワーク内でのみ優先順位を付けることができます。If you use QoS on an internal network and a user signs in from a remote location, you can only prioritize within your internal, managed network. リモートの場所は仮想プライベートネットワーク (VPN) を実装することによって管理された接続を受け取ることができますが、VPN の本質的にはパケットのオーバーヘッドが追加され、リアルタイムトラフィックで遅延が発生します。Although remote locations can receive a managed connection by implementing a virtual private network (VPN), a VPN inherently adds packet overhead and creates delays in real-time traffic. VPN 経由のリアルタイム通信トラフィックを実行しないようにすることをお勧めします。We recommend that you avoid running real-time communications traffic over a VPN.

世界中の管理されたリンクを含むグローバル組織では、これらのリンクの帯域幅が LAN と比較して制限されているため、QoS を強くお勧めします。In a global organization with managed links that span continents, we strongly recommend QoS because bandwidth for those links is limited in comparison to the LAN.

QoS キューの概要Introduction to QoS queues

QoS を提供するには、ネットワークデバイスがトラフィックを分類するための手段を持っている必要があります。また、音声やビデオを他のネットワークトラフィックと区別できなければなりません。To provide QoS, network devices must have a way to classify traffic and must be able to distinguish voice or video from other network traffic.

ネットワークトラフィックがルーターに入ったら、トラフィックはキューに入れられます。When network traffic enters a router, the traffic is placed into a queue. QoS ポリシーが構成されていない場合は、1つのキューしかありません。すべてのデータは、同じ優先度で最初のデータとして扱われます。If a QoS policy isn't configured, there is only one queue, and all data is treated as first-in, first-out with the same priority. つまり、ボイストラフィック (遅延に非常に敏感) は、わずか数秒の遅延が問題となるトラフィックが遅れている可能性があります。That means voice traffic (which is very sensitive to delays) might get stuck behind traffic where a delay of a few extra milliseconds wouldn't be a problem.

QoS を実装するときは、いくつかの輻輳管理機能 (Cisco の優先キューイング、クラスベースの加重公平なキューイング、 Cbゅ qなど)、および輻輳回避機能 (加重ランダムなど) を使って複数のキューを定義します。で検出。When you implement QoS, you define multiple queues using one of several congestion management features (such as Cisco’s priority queuing and Class-Based Weighted Fair Queueing CBWFQ) and congestion avoidance features (such as weighted random early detection WRED).

図2QoS キューの例Figure 2. Examples of QoS queues

QoS キューと帯域幅区分の図Illustration of QoS queues and bandwidth division

簡単な例としては、QoS によってデータネットワーク内に仮想 "相乗りレーン" が作成されるため、データの種類によっては遅延が発生しないことがあります。A simple analogy is that QoS creates virtual “carpool lanes” in your data network so some types of data never or rarely encounter a delay. これらのレーンを作成した後は、組織のユーザーに対してビジネスレベルのエクスペリエンスを提供しながら、相対的なサイズを調整して、より効率的に接続の帯域幅を管理することができます。Once you create those lanes, you can adjust their relative size and much more effectively manage the connection bandwidth you have, while still delivering business-grade experiences for your organization's users.

QoS の実装方法を選択するSelect a QoS implementation method

ネットワークのルーターでアクセス制御リスト (Acl) を使用して、ポートベースのタグを使って QoS を実装することができます。You could implement QoS via port-based tagging, using Access Control Lists (ACLs) on your network's routers. ポートベースのタグ付けは、Windows と Mac の混合環境で動作し、実装が最も簡単な方法であるため、最も信頼できる方法です。Port-based tagging is the most reliable method because it works in mixed Windows and Mac environments and is the easiest to implement. モバイルクライアントでは、DSCP 値を使ってトラフィックをマークするメカニズムは用意されていないため、この方法が必要になります。Mobile clients don’t provide a mechanism to mark traffic by using DSCP values, so they will require this method.

この方法を使用すると、ネットワークのルーターは受信パケットを調査し、特定のポートまたはポートの範囲を使ってパケットが到着した場合は、特定のメディアの種類として識別し、それをその種類のキューに入れて、事前に定義されたDSCPマークを IP に追加します。他のデバイスがそのトラフィックの種類を認識し、キューで優先順位を付けることができるようにするためのパケットヘッダー。Using this method, your network's router examines an incoming packet, and if the packet arrived using a certain port or range of ports, it identifies it as a certain media type and puts it in the queue for that type, adding a predetermined DSCP mark to the IP Packet header so other devices can recognize its traffic type and give it priority in their queue.

これは、すべてのプラットフォームで機能しますが、WAN edge でトラフィックをマークするだけで、管理のオーバーヘッドが生じます。Although this works across platforms, it only marks traffic at the WAN edge (not all the way to the client machine) and creates management overhead. この方法を実装する手順については、ルーター製造元から提供されているドキュメントを参照してください。You should refer to the documentation provided by the router manufacturer for instructions on implementing this method.


また、グループポリシーオブジェクト (GPO) を使用して、クライアントデバイスが特定の種類のトラフィック (音声など) であることを示す DSCP マーカーを IP パケットヘッダーに挿入することで、QoS を実装することもできます。You could also implement QoS implemented by using a Group Policy Object (GPO) to direct client devices to insert a DSCP marker in IP packet headers identifying it as particular type of traffic(for example, voice). ルーターなどのネットワークデバイスでは、これを認識して、トラフィックを個別の優先度の高いキューに配置するように構成することができます。Routers and other network devices can be configured to recognize this and put the traffic in a separate, higher-priority queue.

このシナリオは完全に有効ですが、ドメインに参加している Windows クライアントに対してのみ機能します。Although this scenario is entirely valid, it will only work for domain-joined Windows clients. ドメインに参加していないデバイスでは、DSCP タグ付けは有効になりません。Any device that isn’t a domain-joined Windows client won’t be enabled for DSCP tagging. Mac OS などのクライアントでは、ハードコーディングされたタグがあり、常にトラフィックがタグ付けされます。Clients such as Mac OS have hard-coded tags and will always tag traffic.

正側では、GPO を使用して DSCP マーキングを制御することで、ドメインに参加しているすべてのコンピューターが同じ設定を受け取り、管理者だけがそれらを管理できるようになります。On the plus side, controlling the DSCP marking via GPO ensures that all domain-joined computers receive the same settings and that only an administrator can manage them. GPO を使うことができるクライアントは、元のデバイスでタグ付けされ、設定されたネットワークデバイスでは、DSCP コードによってリアルタイムストリームを認識し、適切な優先順位を付けることができます。Clients that can use GPO will be tagged on the originating device, and then configured network devices can recognize the real-time stream by the DSCP code and give it an appropriate priority.


可能であれば、エンドポイントとポートベースの Acl での DSCP マーキングをルーターで組み合わせることをお勧めします。We recommend a combination of DSCP markings at the endpoint and port-based ACLs on routers, if possible. グループポリシーオブジェクトを使用してほとんどのクライアントをキャッチし、さらにポートベースの DSCP タグを使用することで、モバイル、Mac、その他のクライアントでも QoS 処理を行うことができます (少なくとも部分的に)。Using a Group Policy object to catch the majority of clients, and also using port-based DSCP tagging will ensure that mobile, Mac, and other clients will still get QoS treatment (at least partially).

[DSCP マーキング] は、likened が配信されるまでの時間と、迅速な配信のために最適な並べ替えを行うことができるようにする郵送の頻度を示す切手にすることができます。DSCP markings can be likened to postage stamps that indicate to postal workers how urgent the delivery is and how best to sort it for speedy delivery. リアルタイムメディアストリームに優先順位を設定するようにネットワークを構成すると、紛失したパケットや遅延したパケットが大幅に減少します。Once you've configured your network to give priority to real-time media streams, lost packets and late packets should diminish greatly.

ネットワーク内のすべてのデバイスが同じ分類、マーキング、優先順位を使用している場合は、各トラフィックの種類で使用されるキューに割り当てられているポート範囲のサイズを変更することによって、遅延、破棄されたパケット、ジッタを削減または除去することができます。Once all devices in the network are using the same classifications, markings, and priorities, it’s possible to reduce or eliminate delays, dropped packets, and jitter by changing the size of the port ranges assigned to the queues used for each traffic type. Teams の観点から見ると、最も重要な構成手順は、パケットの分類とマーク付けですが、エンドツーエンドの QoS を成功させるには、基になるネットワーク構成にアプリケーションの構成を慎重に合わせる必要があります。From the Teams perspective, the most important configuration step is the classification and marking of packets, but for end-to-end QoS to be successful you also need to carefully align the application’s configuration with the underlying network configuration. QoS が完全に実装されたら、継続的な管理は、組織のニーズと実際の使用状況に基づいて、各トラフィックの種類に割り当てられたポート範囲を調整することになります。Once QoS is fully implemented, ongoing management is a question of adjusting the port ranges assigned to each traffic type based on your organization's needs and actual usage.

各メディアの種類の初期ポート範囲を選ぶChoose initial port ranges for each media type

DSCP 値は、対応して構成されたネットワークに、パケットまたはストリームを割り当てるための優先順位を示します。 DSCP マークがクライアントとネットワーク自体のどちらで割り当てられているかは、ACL 設定に基づいて判断されます。The DSCP value tells a correspondingly configured network what priority to give a packet or stream, whether the DSCP mark is assigned by clients or the network itself based on ACL settings. 各メディアワークロードは、固有の固有の DSCP 値を取得します (他のサービスによっては、ワークロードで DSCP マーキング、チームを共有することはできません)。また、各メディアの種類に対して定義され、個別のポート範囲を使うことができます。Each media workload gets its own unique DSCP value (other services might allow workloads to share a DSCP marking, Teams does not) and a defined and separate port range used for each media type. その他の環境には既存の QoS 戦略がある場合があります。これは、ネットワークワークロードの優先順位を決定するのに役立ちます。Other environments might have an existing QoS strategy in place, which will help you determine the priority of network workloads.

さまざまなリアルタイムストリーミングワークロードのポート範囲の相対サイズによって、そのワークロード専用の使用可能な帯域幅の合計の比率が設定されます。The relative size of the port ranges for different real-time streaming workloads sets the proportion of the total available bandwidth dedicated to that workload. 以前のお客様に戻るには、"Air Mail" スタンプ付きの文字が、最も近い空港から1時間以内に実行されることがあります。また、"一括メール" マークとマークされた小さいパッケージでは、1日のうち、一連のトラックで陸を通過するまで待機することができます。To return to our earlier postal analogy: a letter with an "Air Mail" stamp might get taken within an hour to the nearest airport, while a small package marked "Bulk Mail" mark can wait for a day before traveling over land on a series of trucks.

次の表は、ExpressRoute を備えた Teams の必須の DSCP マーキングと、ワークロードキューの関連ポートを示しています。The following table shows the required DSCP markings for Teams with ExpressRoute, and the associated ports for workload queues. これらの範囲は、ユーザーが自分の環境で使用する内容がわからない場合に、適切な出発点となる可能性があります。These ranges might serve as a good starting point for customers who are unsure what to use in their own environments. 詳細については、「ExpressRoute QoS の要件」をご覧ください。To learn more, read ExpressRoute QoS requirements.

推奨される初期ポート範囲Recommended initial port ranges

メディアトラフィックの種類Media traffic type クライアントのソースポートの範囲Client source port range プロトコルProtocol DSCP 値DSCP value DSCP クラスDSCP class
オーディオAudio 50000–5001950,000–50,019 TCP/UDPTCP/UDP 4646 完全優先転送 (EF)Expedited Forwarding (EF)
ビデオVideo 50020–5003950,020–50,039 TCP/UDPTCP/UDP 3434 相対的優先転送 (AF41)Assured Forwarding (AF41)
アプリケーション/画面共有Application/Screen Sharing 50040–5005950,040–50,059 TCP/UDPTCP/UDP 18 確実に転送 (AF21)Assured Forwarding (AF21)

これらの設定を使用する場合は、次の点に注意してください。Be aware of the following when you use these settings:

  • 今後、ExpressRoute の実装を計画していて、QoS を実装していない場合は、このガイダンスに従うことをお勧めします。これにより、DSCP 値が送信者と受信者と同じになるようにすることをお勧めします。If you plan to implement ExpressRoute in the future and haven’t yet implemented QoS, we recommend that you follow the guidance so that DSCP values are the same from sender to receiver.
  • モバイルクライアントやチームデバイスを含むすべてのクライアントは、これらのポート範囲を使用します。また、これらのソースポート範囲を使用する、実装するすべての DSCP ポリシーが影響を受けます。All clients, including mobile clients and Teams devices, will use these port ranges and will be affected by any DSCP policy you implement that uses these source port ranges. 動的なポートを引き続き使用するクライアントは、ブラウザーベースのクライアント (つまり、参加者がブラウザーを使って会議に参加できるクライアント) だけです。The only clients that will continue to use dynamic ports are the browser-based clients (that is, those clients that let participants join meetings by using their browsers).
  • Mac クライアントでは、同じポート範囲を使用しますが、オーディオ (EF) とビデオ (AF41) にはハードコーディングされた値も使用されます。Although the Mac client uses the same port ranges, it also uses hard-coded values for audio (EF) and video (AF41). これらの値は構成できません。These values are not configurable.
  • ユーザーエクスペリエンスを向上させるために、後でポート範囲を調整する必要がある場合は、ポート範囲を重ねて、互いに隣り合っている必要があります。If you later need to adjust the port ranges to improve user experience, the port ranges can not overlap and should be adjacent to each other.

QoS を Teams に移行するMigrate QoS to Teams

QoS タグとポート範囲など、以前に Skype for Business Online を展開した後に Teams を展開している場合、チームは既存の構成を尊重し、Skype for Business クライアントと同じポート範囲とタグ付けを使用します。If you’ve previously deployed Skype for Business Online, including QoS tagging and port ranges, and are now deploying Teams, Teams will respect the existing configuration and will use the same port ranges and tagging as the Skype for Business client. ほとんどの場合、追加の構成は必要ありません。In most cases, no additional configuration will be needed.

注意

グループポリシーによってアプリケーション名の QoS タグ付けを使用している場合は、アプリケーション名として Teams を追加する必要があります。If you're using Application Name QoS tagging via Group Policy, you must add Teams.exe as the application name.

QoS の実装手順QoS implementation steps

高レベルでは、QoS を実装するには次の手順が必要です。At a very high level, implementing QoS requires these steps:

  1. ネットワークの準備ができていることを確認するVerify your network is ready
  2. QoS の実装方法を選択するSelect a QoS implementation method
  3. 各メディアの種類の初期ポート範囲を選ぶChoose initial port ranges for each media type
  4. QoS 設定を実装します。Implement QoS settings:
    1. GPO を使ってクライアントデバイスのポート範囲とマークを設定するクライアントOn Clients using a GPO to set client device port ranges and markings

    2. ルーター (製造元のマニュアルを参照)、または他のネットワークデバイスを参照してください。On routers (see the manufacturer documentation) or other network devices. これには、ポートベースの Acl が含まれている場合や、QoS キューと DSCP マーキングのいずれかを定義している場合があります。This may include port-based ACLs or simply defining the QoS queues and DSCP markings, or all of these.

      重要

      これらの QoS ポリシーは、クライアントソースポートと、発信元と送信先の IP アドレスを "any" として実装することをお勧めします。We recommend implementing these QoS policies using the client source ports and a source and destination IP address of “any.” これにより、内部ネットワーク上の受信および送信メディアの両方のトラフィックがキャッチされます。This will catch both incoming and outgoing media traffic on the internal network.

    3. Teams 管理センターの場合On Teams Admin Center

  5. ネットワーク上のチームトラフィックを分析して、QoS の実装を検証します。Validate the QoS implementation by analyzing Teams traffic on the network.

QoS を実装する準備ができたら、次のガイドラインを念頭に置いてください。As you prepare to implement QoS, keep the following guidelines in mind:

  • Office 365 への最短のパスが最適です。The shortest path to Office 365 is best.
  • ポートを閉じると音質が低下します。Closing ports will only lead to quality degradation.
  • プロキシなどの障害物はお勧めできません。Any obstacles in-between, such as proxies, are not recommended.
  • ホップ数を制限します。Limit the number of hops:
    • クライアントとネットワークエッジ-3 ~ 5 ホップ。Client to network edge – 3 to 5 hops.
    • ISP から Microsoft ネットワークエッジ–3ホップISP to Microsoft network edge – 3 hops
    • Microsoft ネットワークエッジから最終的な送信先への関連性がないMicrosoft network edge to final destination – irrelevant

ファイアウォールのポートを構成する方法については、「 Office 365 の URL と IP 範囲」をご覧ください。For information about configuring firewall ports, go to Office 365 URLs and IP ranges.

Teams 管理センターでソースポートを管理するManaging source ports in the Teams admin center

Teams では、さまざまなワークロードによって使用される QoS ソースポートを、必要に応じて動的に管理し、調整する必要があります。In Teams, QoS source ports used by the different workloads should be actively managed, and adjusted as necessary. 各メディアの種類の初期ポート範囲を選択する」の表を参照すると、ポート範囲は調整できますが、DSCP マーキングは構成できません。Referring to the table in Choose initial port ranges for each media type, the port ranges are adjustable, but the DSCP markings are not configurable. これらの設定を実装した後は、特定のメディアの種類に必要なポートの数が増加するか、少なくなることがあります。Once you have implemented these settings, you may find that more or fewer ports are needed for a given media type. 通話分析と通話品質ダッシュボードを使用して、Teams が実装された後、定期的に、必要に応じてポート範囲を調整することを決定します。Call Analytics and Call Quality Dashboard should be used in making a decision to adjust port ranges after Teams has been implemented, and periodically as needs change.

注意

Skype for Business Online のソースポート範囲と DSCP マーキングに基づいて QoS を既に構成している場合は、同じ構成が Teams に適用され、マッピングに対するクライアントやネットワークの変更は必要ありませんが、範囲を設定する必要があります。 Teams 管理センターで、Skype For Business Online 用に構成されていたものと一致するように使用します。If you've already configured QoS based on source port ranges and DSCP markings for Skype for Business Online, the same configuration will apply to Teams and no further client or network changes to the mapping will be required, though you may have to set the ranges used in Teams Admin Center to match what was configured for Skype for Business Online.

以前にオンプレミスの Skype for Business Server を展開したことがある場合は、QoS ポリシーを再調査し、必要に応じて調整して、チームの質の高いユーザーエクスペリエンスを提供できるように、必要に応じて調整する必要があります。If you’ve previously deployed Skype for Business Server on-premises, you may need to re-examine your QoS policies and adjust them as needed to match port range settings you've verified provide a quality user experience for Teams.

QoS の実装を検証するValidate the QoS implementation

QoS を有効にするには、グループポリシーオブジェクトによって設定された DSCP 値が、通話の両端に存在している必要があります。For QoS to be effective, the DSCP value set by the Group Policy object needs to be present at both ends of a call. チームクライアントによって生成されたトラフィックを分析することで、チームの負荷トラフィックがネットワーク経由で移動したときに、DSCP 値が変更されていないこと、または除去されているかどうかを確認できます。By analyzing the traffic generated by the Teams client, you can verify that the DSCP value isn’t changed or stripped out when the Teams workload traffic traverses moves through the network.

可能であれば、ネットワークの出口ポイントでトラフィックをキャプチャします。Preferably, you capture traffic at the network egress point. スイッチまたはルータでポートミラーリングを使用して、この問題を解決することができます。You can use port mirroring on a switch or router to help with this.

ネットワークモニターを使用して DSCP 値を確認するUse Network Monitor to verify DSCP values

ネットワークモニターは、 Microsoft からダウンロードしてネットワークトラフィックを分析するためのツールです。Network Monitor is a tool you can download from Microsoft to analyze network traffic.

  1. ネットワークモニターを実行している PC で、ポートのミラーリング用に構成されているポートに接続し、パケットのキャプチャを開始します。On the PC running Network Monitor, connect to the port that has been configured for port mirroring and start capturing packets.

  2. Teams クライアントを使用して電話をかけます。Make a call by using the Teams client. 通話を切る前にメディアが確立されていることを確認します。Make sure media has been established before hanging up the call.

  3. キャプチャを停止します。Stop the capture.

  4. [表示フィルター ] フィールドで、通話を行った PC のソース IP アドレスを使用し、次の例に示すように、検索条件として DSCP 値 46 (Hex 0x2e) を定義してフィルターを絞り込みます。In the Display Filter field, use the source IP address of the PC that made the call, and refine the filter by defining DSCP value 46 (hex 0x2E) as search criteria, as shown in the following example:

    Source = = "192.168.137.201" AND DifferentiatedServicesField = = 0x2ESource == "192.168.137.201" AND IPv4.DifferentiatedServicesField == 0x2E

    [フィルターの表示] ダイアログボックスの [スクリーンショット] フィルターScreenshot filters in the Display Filter dialog box.

  5. [適用] を選択してフィルターを有効にします。Select Apply to activate the filter.

  6. [フレームの概要] ウィンドウで、最初の UDP パケットを選択します。In the Frame Summary window, select the first UDP packet.

  7. [フレームの詳細] ウィンドウで、[IPv4] リスト項目を展開し、 DSCPで始まる行の末尾の値をメモします。In the Frame Details window, expand the IPv4 list item and note the value at the end of the line that begins with DSCP.

    ![[フレームの詳細] ダイアログボックスの DSCP 設定を示すスクリーンショット。][(media/Qos-in-Teams-Image5.png "ネットワークモニター] の [フレームの詳細] ダイアログボックスで、DSCP 設定が強調表示されています。")Screenshot showing DSCP settings in the Frame Details dialog box.

この例では、DSCP 値は46に設定されています。In this example, the DSCP value is set to 46. 使用されるソースポートは50019であるため、これはボイスワークロードであることを示します。This is correct, because the source port used is 50019, which indicates that this is a voice workload.

GPO によってマーキングされている各ワークロードについて確認を繰り返します。Repeat the verification for each workload that has been marked by the GPO.

詳細情報More information

ビデオ : ネットワーク計画Video: Network Planning

Microsoft Teams 用に組織のネットワークを準備するPrepare your organization's network for Microsoft Teams

ExpressRoute の QoS 要件ExpressRoute QoS requirements