<var class="keyword">
<div style="display: inline;">
RingCentral
</div></var> Quality of Service guidelines
===========================================================================================================

The purpose of this document is to provide the information required for enterprise networks to properly deploy Quality of Service (QoS) guidelines in support of unified communication services, including voice and video communication. This document includes general network service quality guidelines, as well as information about unsupported devices and configurations, traffic classification and treatment, network connection for MS Windows, and bandwidth and network capacity.

The next sections assume familiarity with Layer 2 and Layer 3 networks, traffic prioritization techniques, and Local Area Network (LAN) and Wide-Area Network (WAN) technologies.

1. End-to-end network path performance requirements
---------------------------------------------------

When using unified communication services, you must satisfy the network voice, video, and data path requirements listed in [Table 1.1](#End-to-end-network-path-performance-requirements_table-1-1 ""). Only two-way communication is considered. One-way communication isn't typically included in the service.

|----------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------|
| **Network property** | **Two-way voice and video content**                                                                                                                                                                                                                                          | **Data Traffic**                                                                  |
| Link capacity        | Each link in the end-to-end path must have a capacity greater than the network traffic bandwidth, generated by the maximum number of simultaneous voice, video, and two-way data transfers. The capacity must also include the bandwidth required for growth. (See [Section 6](#bandwidth "") for further information on bandwidth and networking.)             ||
| Delay                | Latency should be: * \< 150ms for one-way communications * \< 300ms for two-way communications Longer latencies can occur with geosynchronous satellite links. This will delay communications but not block them. However, both parties should be aware of potential delays. | Depending on the data service, latency in seconds or longer is considered normal. |
| Packet loss          | To prevent voice signal outages, packet loss should not exceed 1%. Video may tolerate packet loss better. If voice content is embedded in video content, the requirements hold.                                                                                              | Packet loss can be mitigated by retransmission.                                   |
| Jitter               | To prevent the occurrence of robotic voice or speech content outages, jitter should not exceed 40ms.                                                                                                                                                                         | Jitter usually doesn't impact communication quality.                              |
[Table 1.1 - End-to-end network path performance requirements]

2. Network service quality techniques
-------------------------------------

Depending on the network technology used (PSTN, MPLS, Ethernet WAN/LAN, internet), traffic may be prioritized differently.

To meet the end-to-end path performance requirements ([Section 1)](#End-to-end-network-path-performance-requirements "") for traffic between <var class="keyword">
<div style="display: inline;">
RingCentral
</div></var> endpoints and cloud-based communication services, you should:

* Avoid unsupported devices and configurations ([Section 3](#Unsupported-devices-configs "")).
* Use sufficient bandwidth for every traversed LAN and WAN network segment including failover segments. Insufficient bandwidth may cause packet drops and affect real-time traffic for voice and video, as well as non-real-time traffic, including SMS, fax, and file transfers.
* Make sure traffic is properly prioritized.

2.1 Layer 3 IP packet networks

For Layer 3 IP routing packet transports over LAN and WAN networks, you may use [Differentiated Services Code Point (DSCP) traffic prioritization](#topic_3_Traffic-classification "").

* IP packets can have a DSCP field to set in IP packet headers to reflect traffic priority. Devices such as switches, IP routers, and firewalls located on a LAN must be properly configured, and WAN network devices must be configured with matching DSCP tags.
* <var class="keyword">
  <div style="display: inline;">
  RingCentral
  </div></var> endpoints properly set DSCP prioritization tags for signaling and media traffic, but the Windows OS may alter their values in the network packets sent by your computer. See [Section 5](#Prioritization-network-connections "") for instructions on how to prioritize network connections on Windows.
* The mapping of DSCP tags that traverse different types of networks (for example, an enterprise LAN and an MPLS network) must maximize service quality.
* DSCP prioritization tags must be honored to leverage tags that prioritize traffic through IP routers.

2.2 Layer 2 switched networks

For Layer 2 switched LAN and WAN networks, QoS class of service (CoS) Ethernet frame header tags may also be used to prioritize traffic. We recommend you check for sufficient bandwidth for all traffic so links and switches never saturate, and CoS tagging for traffic prioritization isn't needed.

2.3 Wide-area packet communication networks

Wide-area packet communication networks include MPLS and Ethernet WAN networks. These networks are typically implemented with bounds on end-to-end path packet loss, latency, and jitter. These network service providers (NSPs) or carriers often provide service level agreements (SLAs) to customers. If the customer's network service doesn't meet the SLA path performance requirements, the network provider applies a credit to the customer's next bill. Hence, it is in the interest of the NSP to provide a high-quality network.

2.4 Public internet

The public internet, an implementation of a Layer 3 packet network, typically doesn't guarantee network service quality. DSCP traffic prioritization tags may alter unpredictably by service provider network devices along an end-to-end path, and network routers typically don't honor prioritization. Still, several techniques can maximize network service quality.

* Relative to traffic volume, link bandwidths and router capacities have increased over time, resulting in generally improved QoS for users' video and data services
* <var class="keyword">
  <div style="display: inline;">
  RingCentral
  </div></var> has deployed data centers at strategic global locations so internet traffic to and from user devices passes through a relatively small number of routers before hitting <var class="keyword">
  <div style="display: inline;">
  RingCentral
  </div></var>'s high-bandwidth private backbone network, in which links and routers aren't shared with the internet.
* A combination of internet and private networks may minimize internet traversal.
* The <var class="keyword">
  <div style="display: inline;">
  RingCentral
  </div></var> cloud connects to internet exchange points in data centers which then connect to major internet service provider (ISP) networks. This setup minimizes packet latency by providing a more direct path.
* SD-WAN technology may improve QoS by switching to alternative traffic tunnels when traffic quality on the original tunnel is too low.
* Enterprise sites may purchase dedicated internet access (DIA) connections from their ISPs.
* Some ISPs provide QoS traffic prioritization for the real-time traffic that traverses their internet network.

2.5 Enterprise LANs

In addition to the aforementioned packet-prioritization methods, enterprise Layer 2 LANs may use one or more of these strategies.

* <var class="keyword">
  <div style="display: inline;">
  RingCentral
  </div></var>'s unified communication IP phones and applications apply voice and video DSCP traffic prioritization. Computer operating systems should be configured to not override the DSCP values of voice and video applications. This setting can be adjusted by applying a proper computer or Active Directory policy. If adjusting this setting is impossible, the network device closest to the computer can retag DSCP values to the proper prioritization level.
* At the ingress border from the internet to a local site (which is typically a firewall), traffic from <var class="keyword">
  <div style="display: inline;">
  RingCentral
  </div></var> can be retagged to the proper priority level.
* When possible, you should separate <var class="keyword">
  <div style="display: inline;">
  RingCentral
  </div></var> media and signaling traffic from other enterprise traffic. For example, IP phones can be connected to a separate LAN or a dedicated internet connection.

2.6 Public Switched Telephone Networks (PSTNs)

A PSTN transports telephony calls of equal priority to avoid the implementation of QoS traffic prioritization. These networks are designed so latency between any type of global call remains within acceptable limits.

3. Unsupported devices and configurations
-----------------------------------------

<var class="keyword">
<div style="display: inline;">
RingCentral
</div></var> advises against the use of certain devices, device settings, and network configurations for communication solutions. Incorrect settings or unsupported devices can cause problems with endpoint registration, call feature operation, and quality of voice and/or video transmission (high latency, packet loss, jitter).

For proper operation of <var class="keyword">
<div style="display: inline;">
RingEX
</div></var> services, you should disable or bypass the network device functions listed in [Table 3.1](https://support.ringcentral.com/article-v2/Quality-of-Service-Guidelines.html?brand=RingCentral&product=RingEX&language=en_US#GUID-506dd881-395e-4944-b8ca-34353d648625-en_us_table_3-1 "") on network devices, including Ethernet switches, IP routers, and firewalls. Many applied packet discards or excessive latency and jitter produced by these functions can cause intermittent or non-functioning call controls or media transport problems during voice and video communication.

By applying policy-based control to disable these functionalities, you can limit IP and higher-level changes to supernets. For example, you can configure WAN acceleration to passthru mode for UDP traffic from and to the supernets.

|-----------------|----------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **Layer**       | **Function**                                                               | **Comments**                                                                                                                                                                                                                                                    |
| Application     | SIP application layer gateway (SIP ALG), also known as SIP transformations | Enabling SIP ALG may cause signaling issues, resulting in compromised call features such as one-way audio or a lack of audio.                                                                                                                                   |
| Application     | SIP inspection                                                             | SIP inspection examines signaling packets that may cause packet discard or latency, preventing the signaling protocol from operating properly.                                                                                                                  |
| Application     | Deep packet inspection (DPI)                                               | Deep packet inspection examines the content of IP packets. The processing may exceed the acceptable latency and jitter for voice and video packets.                                                                                                             |
| Application     | Application layer access control                                           | Deep packet inspection examines the content of IP packets. Packet processing may exceed the acceptable latency and jitter for voice and video packets.                                                                                                          |
| Application     | Stateful packet inspection (SPI), also known as dynamic packet filtering   | Stateful packet inspection examines which packets can pass through a firewall. Packet processing may exceed the acceptable latency and jitter for voice and video packets.                                                                                      |
| Application     | Intrusion detection/intrusion prevention system (IDS/IPS)                  | An IDS analyzes packet and packet sequences to detect security threats. An IPS performs IDS functions and mitigates any detected threats. IDS and IPS packet processing may exceed the acceptable latency and jitter for voice and video packets.               |
| Application     | Web proxy operation                                                        | Web proxies don't typically support QoS, so any voice and video traffic that passes through them may suffer excessive latency and jitter.                                                                                                                       |
| Application     | WAN acceleration                                                           | WAN acceleration uses header compression to reduce bandwidth consumption, which can cause unacceptable jitter for voice and video packets.                                                                                                                      |
| Transport       | Port filtering                                                             | Port filtering, such as UDP flood protection, may limit bandwidth, which can cause intermittent voice and video quality issues during simultaneous calls.                                                                                                       |
| IP              | Packet-by-packet load balancing across multiple service provider links     | Packet-by-packet load-balancing across multiple communication sessions causes connectivity issues since signaling and media for a single session must originate from the same IP address.                                                                       |
| IP \& data link | Auto-QoS, when used in combination with Poly phones                        | Use of auto-QoS may cause voice quality issues, such as distortion or incorrect volume levels, with older Poly IP speakerphones and deskphones.                                                                                                                 |
| IP \& data link | Dynamic ARP inspection (DAI)                                               | Dynamic Address Resolution Protocol (ARP) inspection rejects invalid and malicious ARP packets to prevent certain types of man-in-the-middle attacks. The processing of these packets may exceed the acceptable latency and jitter for voice and video packets. |
| Physical        | Energy-efficient Ethernet (also known as Green Ethernet)                   | The Green Ethernet setting saves energy by automatically setting switch ports to low power mode after a period of inactivity. This capability may cause intermittent signaling and media traffic issues.                                                        |
| Physical        | Satellite (Ethernet over microwave) network connections                    | Satellite connections can introduce delays of more than 150ms in each direction. Depending on the satellite connection quality, delays may cause excessive jitter and packet loss.                                                                              |
[Table 3.1 - Network device functions that may impair SIP signaling and/or RTP media traffic]

Note:

* For some functionalities listed in the *Application* row of [Table 3.1](https://support.ringcentral.com/article-v2/Quality-of-Service-Guidelines.html?brand=RingCentral&product=RingEX&language=en_US#GUID-506dd881-395e-4944-b8ca-34353d648625-en_us_table_3-1 ""), packet content may traverse a separate processing engine, resulting in issues with signaling and/or media traffic. If you use small and medium businesses (SMB) devices or small office/home office (SoHo) devices, this configuration could cause problems with the quality of voice communication. You can minimize these problems by using better-performing networking devices.  

4. QoS classification and traffic treatment policies
----------------------------------------------------

VoIP and video QoS impose the strictest constraints on network communications, due to the potential for delay, packet loss, and jitter. Signaling traffic has lower QoS requirements since real-time requirements need not be met and packets can be retransmitted when lost. Other types of service traffic, such as messaging and directory services, can be processed at the lowest priority, as with non-real-time enterprise data traffic.

Sections [4.1](#topic_3_Traffic-classification "") through [4.8](#topic_3_Layer2WANinterconnection "") explain the ideal classification and treatment of communication services traffic for enterprise networks and WANs. In practice, limitations in endpoints, network devices, and/or ISP and carrier networks may limit the complete fulfillment of QoS traffic class and treatment requirements. [Section 4.4](#topic_3_Trafficclassificationmethods "") provides recommendations for handling such sub-optimal cases.

These terms refer to the direction of unified communication traffic flow:

* **Outbound traffic** is traffic directed from the enterprise or remotely deployed endpoint (phone/PC) toward the unified communications cloud service.
* **Inbound traffic** is traffic directed from the unified communications cloud service toward the enterprise or remotely deployed endpoint.

4.1 Traffic classification

Packet classification identifies and categorizes traffic into specific classes. [Table 4.1.1](https://support.ringcentral.com/article-v2/Quality-of-Service-Guidelines.html?brand=RingCentral&product=RingEX&language=en_US#GUID-506dd881-395e-4944-b8ca-34353d648625-en_us_table_4-1-1 "") lists the different traffic classes for unified communications services.

Note:

* VoIP Media requires the highest priority treatment and appears at the top of the table.
* Layer 2 includes Class of Service (CoS) frame header tagging.
* Layer 3 includes DSCP packet marking.
* The term *marking* refers to both tagging (in Layer 2) and marking (in Layer 3).
* Voice is assigned a slightly higher priority than video, since, in the presence of adverse network conditions, voice service is typically more important than video service.
* CoS is a 3-bit field in the Ethernet frame header with possible values ranging from 0 to 7.
* DSCP is a 6-bit field in the IP packet header with possible values ranging from 0 to 63.
* Network security is implemented above the IP layer, and therefore doesn't affect CoS or DSCP values.

|---------------------------------------------------------------------------------------|-----------------------|------------------------|----------|----------------------|
|                                                                                       | **Layer 2**           | **Layer 3**                                            |||
| **Traffic class**                                                                     | **CoS decimal value** | **DSCP decimal value** | **Name** | **Drop probability** |
| VoIP media - real time                                                                | 5                     | 46                     | EF       | N/A                  |
| Video media - real time                                                               | 4                     | 34                     | AF41     | Low                  |
| SIP                                                                                   | 3                     | 26                     | AF31     | Low                  |
| Transactional: * Network time service * Mobile app data sync * LDAP directory service | 2                     | 18                     | AF21     | Low                  |
| Best Effort: phone provisioning and firmware update                                   | 0                     | 0                      | BE       | Undetermined         |
[Table 4.1.1 - Traffic types and classification]

4.2 Traffic scheduling

Traffic scheduling in network devices determines how traffic from different classes is prioritized when emitted by a network device. Network devices must prioritize VoIP traffic over any other traffic types to ensure that voice-path performance requirements are met.

Video conferencing is interactive, and therefore must be separated from one-way video streaming services. The end-user experience won't be affected by traffic delays when a user watches one-way video streaming content.

4.3 Practical constraints

An ideal network configuration uses the CoS tagging and DSCP marking values from [Table 4.1.1](https://support.ringcentral.com/article-v2/Quality-of-Service-Guidelines.html?brand=RingCentral&product=RingEX&language=en_US#GUID-506dd881-395e-4944-b8ca-34353d648625-en_us_table_4-1-1 "") for the entire network path between endpoints and cloud-based servers. Using this ideal configuration is known as *honoring the markin*g. However, in practice, honoring the marking is not always possible for one or more of these reasons:

* Some network devices, such as low-end routers, don't support sufficient QoS capabilities.
* Small networks don't always manage CoS values.
* ISPs may change DSCP markings (for example, from 46 to 0) along the internet path.
* In large corporate enterprise networks, with sites that are connected to an MPLS or Metro-Ethernet network, DSCP/CoS mapping must be performed by WAN network border devices. Such mappings may not maintain the exact, optimal CoS/DSCP values in [Table 4.1.1](https://support.ringcentral.com/article-v2/Quality-of-Service-Guidelines.html?brand=RingCentral&product=RingEX&language=en_US#GUID-506dd881-395e-4944-b8ca-34353d648625-en_us_table_4-1-1 "").
* Some endpoint types do not yet mark CoS/DSCP values ([Section 4.4](#topic_3_EndpointInternetmarking "")).

[Sections 4.4](#topic_3_Trafficclassificationmethods ""), [Section 4.5](#topic_3_EndpointInternetmarking ""), and [Section 4.6](#topic_3_DSCPmarkingpolicy "") offer practical requirements and recommendations to address these constraints listed above.

The following sections offer practical requirements and recommendations to address these constraints.

4.4 Traffic classification methods

The QoS capabilities of local network devices determine which traffic classification and scheduling method can be used.

* **Multi-band classification** : Provides maximum traffic prioritization to and from cloud servers (according to [Table 4.1.1](https://support.ringcentral.com/article-v2/Quality-of-Service-Guidelines.html?brand=RingCentral&product=RingEX&language=en_US#GUID-506dd881-395e-4944-b8ca-34353d648625-en_us_table_4-1-1 "")), and provides optimal traffic delivery for five traffic types:
  * Voice
  * Video
  * Signaling
  * Transactional
  * Best Effort

* **Three traffic classes model** : Traffic to and from cloud servers is mapped according to T[able 4.4.1.](https://support.ringcentral.com/article-v2/Quality-of-Service-Guidelines.html?brand=RingCentral&product=RingEX&language=en_US#GUID-506dd881-395e-4944-b8ca-34353d648625-en_us_table_4-4-1 "")
* **Two traffic classes model** :Real-time voice and video UDP traffic, as well as SIP TCP traffic to or from cloud communication media servers, are all classified as DSCP 46. Other traffic is classified as unprioritized data traffic, and therefore has DSCP and CoS values of 0. See [Table 4.4.2](https://support.ringcentral.com/article-v2/Quality-of-Service-Guidelines.html?brand=RingCentral&product=RingEX&language=en_US#GUID-506dd881-395e-4944-b8ca-34353d648625-en_us_table_4-4-2 "").
  * Note: The *Two traffic classes* model is relatively simple to implement, and works well in most SoHo and corporate environments that use devices with limited QoS capabilities.

When feasible, configure a traffic classification model that differentiates VoIP from video and other traffic will enhance QoS functionality for an enterprise network.

|---------------------------------------------------------------------------------------------------------------------------------------------|-----------------------|------------------------|----------|----------------------|
| **Traffic class**                                                                                                                           | **CoS decimal value** | **DSCP decimal value** | **Name** | **Drop probability** |
| VoIP media - real time SIP                                                                                                                  | 5                     | 46                     | EF       | N/A                  |
| Video media - real time                                                                                                                     | 4                     | 34                     | AF41     | Low                  |
| Transactional: * Network time service * Mobile app data sync * LDAP directory service * Best Effort: phone provisioning and firmware update | 0                     | 0                      | BE       | Undetermined         |
[Table 4.4.1 - Three traffic classes model]

|---------------------------------------------------------------------------------------------------------------------------------------------|-----------------------|------------------------|----------|----------------------|
| **Traffic class**                                                                                                                           | **CoS decimal value** | **DSCP decimal value** | **Name** | **Drop probability** |
| VoIP media - real time Video media - real time SIP                                                                                          | 5                     | 46                     | EF       | N/A                  |
| Transactional: * Network time service * Mobile app data sync * LDAP directory service * Best Effort: phone provisioning and firmware update | 0                     | 0                      | BE       | Undetermined         |
[Table 4.4.2 - Two traffic classes model]

4.5 Endpoint and Internet DSCP traffic marking constraints

Endpoints, cloud media servers, and Internet Service Providers use the following types of DSCP marking:

* **Endpoints**
  * Deskphones use IP Differentiated Services Code Point 46 (Expedited Forwarding, or EF) marking for UDP media (RTP) packets. This configuration lets routers in an enterprise network prioritize VoIP media traffic over Best Effort data traffic.
  * Soft endpoints (web, desktop, and mobile clients) mark UDP media packets according to the proper priority marking. However, the operating system may reset the packets to a DSCP value of 0. To prevent packet reset, you have two options:
    * Configure an operating system policy (group policy) to override this behavior.
    * Configure the first Layer 3 device away from the soft endpoint to re-mark traffic appropriately.

* **Media servers**: Cloud media servers mark UDP media traffic as DSCP 46 (voice) or DSCP 34 (video).
* **Mobile applications** mark traffic with DSCP values according to [Table 4.1.1](https://support.ringcentral.com/article-v2/Quality-of-Service-Guidelines.html?brand=RingCentral&product=RingEX&language=en_US#GUID-506dd881-395e-4944-b8ca-34353d648625-en_us_table_4-1-1 "").
* **Internet service providers** : Internet Service Providers frequently re-mark DSCP priority values to different (lower) values. Such re-marking has the following implications:
  * **Outbound direction**: Traffic often arrives at the unified communication services cloud with improper marking.
  * **Inbound direction**: When it arrives at an enterprise site, internet traffic is typically marked incorrectly. Such traffic must be re-marked immediately by the enterprise network border device to ensure that it is forwarded with correct prioritizations within the internal network.

4.6 DSCP marking policy

This section describes traffic treatment policies for (re-)marking DSCP values in enterprise networks. When you enforce proper DSCP marking and honor QoS prioritization policies, you'll preserve assigned DSCP values and forward packets according to the priorities of the assigned value. You must implement this policy for switches, routers, and firewalls in the end-to-end communication path between endpoints and cloud-based servers.

* **Outbound direction** : If the endpoint can't mark the correct value according to the guidelines in [Section 4.4](#topic_3_Trafficclassificationmethods ""), you should re-mark endpoint traffic as close as possible to the correct DSCP value. You may use such network devices as access points, access switches, routers, and firewalls for this re-marking.
* **Inbound direction**: Re-mark traffic to the correct DSCP value as soon as it enters the enterprise network from a carrier WAN link or WiFi access point.
* **Inside the local network**: Honor the DSCP markings throughout the enterprise network for inbound and outbound traffic.
* **WAN network**: Any mapping from DSCP to CoS and back must maintain end-to-end path QoS requirements.

You must use the supernets and whitelisting tables in Sections 2 and 3 of the [network requirements document](https://support.ringcentral.com/article-v2/Network-requirements.html?brand=RingCentral&product=RingEX&language=en_US "") to define the QoS policies in inbound and outbound Access Control Lists (ACLs). You shouldn't use local subnet address ranges to define QoS policies, because any subnet changes would require modification of the policy.

Some firewall manufacturers do not support re-marking of DSCP, but may support prioritization of packet-forwarding based on source IP addresses and IP address ranges. Prioritization of packet-forwarding requires that the QoS policies described in this section must be applied to the [supernet traffic](https://support.ringcentral.com/article-v2/Network-requirements.html?brand=RingCentral&product=RingEX&language=en_US "").

4.7 Bandwidth management

Most routers support bandwidth management, which can guarantee the capacity for certain types of traffic, even under saturation conditions. If your routers support bandwidth management, we recommend that you enable this feature and set the bandwidth accordingly.

You must configure your traffic classification and policies according to the recommendations and requirements stated in [Sections 4.1](#topic_3_Traffic-classification "") through [4.4](#topic_3_Trafficclassificationmethods ""). If your traffic exceeds the configured bandwidth, your voice, video, and/or signaling packets may be prioritized over regular data packets, even though bandwidth may not be guaranteed for all calls. This data-prioritization setting depends on your router and its settings.

You must configure the committed bandwidth value of the ISP/carrier link in the edge router/firewall since the edge device cannot by itself accurately determine the ISP circuit capacity.

You should not configure the ISP/carrier burst value as the value for the committed bandwidth, as there is no guarantee that the burst value will be honored. This may result in your ISP discarding voice, video, and/or signaling traffic.

An enterprise site may produce traffic in excess of the committed bandwidth of an external network link, but ISPs/carriers typically ignore excess traffic, regardless of its type. For this reason, you must configure your enterprise edge router/firewall to drop low-priority outbound traffic. Doing so prevents your ISP/carrier from intermittently discarding voice or video media stream packets.

4.8 Layer 2 WAN interconnection

Large enterprise networks frequently rely on Layer 2 MPLS or Metro-Ethernet WAN networks to interconnect Layer 3 networks. To ensure that the end-to-end network path performance requirements detailed in Section 4 are followed, your network must meet several conditions at its ingress and egress borders:

* **Traffic class and priority matching** : Make sure that classes and CoS values follow the guidelines in [Section 4.4](#topic_3_Trafficclassificationmethods "").
* **Traffic shaping**: Ensure that the maximum Layer 3 network bandwidth for each traffic class never exceeds the WAN link capacity. You can achieve this configuration with traffic shaping, provided that the average bandwidth doesn't exceed the provisioned WAN link capacity.

If you can't meet the *Traffic class and priority matching* condition, above, you should map some Layer 3 DSCP values to a higher Layer 2 CoS value.

5. Prioritization of network connections on MS Windows
------------------------------------------------------

For soft-client endpoints with multiple wired and/or wireless network connections, traffic must use only one connection. If a Windows computer is configured to use network connections with equal priority, you may have problems with VoIP and video calls on soft clients.

To prioritize network connection on a WiFi or wired network that operates on MS Windows:

* Click the **Windows** icon at the bottom left side of the screen.
* Enter *cmd* in the search bar to open a terminal window.
* Enter *route print* in the terminal.

The terminal window output will show the metrics used for different interfaces on the computer.

To make sure that your traffic traverses the WiFi network:

* Log in as an administrator, if necessary.
* Click the **Windows** icon at the bottom left.
* Enter *Control Panel* in the search bar.
* Click **Network and Internet**.
* Click **View network status and tasks**.
* Click **Change adapter settings**.
* Select your WiFi adapter.
* Right-click, then select *Properties*.
* Click**Internet Protocol Version 4 (TCP/IPv4**).
* Click **Properties**.
* Click **Advanced**.
* Uncheck **Automatic metri**c.
* Enter *1* to give the WiFi interface the highest priority.
* Click **OK**.
* Enter *route /f* to clear the routing table entries.
* Reboot the computer to activate your new interface priority.
* Verify that the metric value is equal to *1* by entering *route print* in the terminal window.

6. Bandwidth and network capacity assessment
--------------------------------------------

There are two methods for determining the bandwidth produced by traffic on LAN and WAN links, and for determining the capacity required to carry unified communication traffic:

* The most accurate method is to determine the peak traffic load by consulting logs or network data extracted from a still-deployed legacy voice/video system.
* The other method is to perform a bandwidth- and capacity-calculation procedure.

7. Network assessment
---------------------

To validate the end-to-end path QoS requirements listed in [Section 1](#End-to-end-network-path-performance-requirements ""), you can perform a network assessment. Network assessments determine the quality of the LAN and the service provider network. There are two types of network assessments that can validate the ability of a network path to support unified communication services.

* **Snapshot network assessment**: Snapshot assessments provide an impression of network capacity and quality for both directions of VoIP and video traffic between a test site and the unified communication cloud over a time interval of a few minutes. This type of assessment can be performed by the enterprise but provides minimal insight into the end-to-end QoS over longer periods of time.
* **Comprehensive network assessment**: In a comprehensive assessment, a probe installed at the customer site tracks network data for a longer period of time (for instance, a full business week). Comprehensive assessments produce much more accurate impressions of the end-to-end quality and intermediate network hop quality in both directions. The results of the assessment may be used to identify detailed, targeted network improvement recommendations. A comprehensive assessment minimizes the likelihood of user-perceived QoS issues.

