The deadline to register with TCR has been extended. To continue or start using SMS, please register your company with TCR through your Admin Portal now to avoid delays or blocked messages. Learn more

Access, service, and grow your account from here.

Welcome to MyRingCentral

Hi, ${extension.contact.firstName}!

Account overview

Welcome to MyRingCentral

Hi, ${extension.contact.firstName}!

Home > Network and system requirements > Network requirements > Quality of service guidelines

Quality of service guidelines

1. Introduction

2. Unsupported devices and configurations

3. End-to-end network path performance requirements

4. QoS classification and traffic treatment policies

4.1 Traffic classification

4.2 Traffic scheduling

4.3 Practical constraints

4.4 Traffic classification methods

4.5 Endpoint and internet DSCP traffic marking constraints

4.6 DSCP marking policy

4.7 Bandwidth management

4.8 Layer 2 WAN interconnection

5. Prioritization of a network connection on MS Windows

6. Bandwidth and network capacity assessment

7. Network readiness assessment

1. Introduction

The purpose of this document is to provide the information that enterprise networks require to properly deploy Quality of Service (QoS) guidelines in support of unified communication services. This document includes QoS guidelines for unsupported devices and configurations, traffic classification and treatment, MS Windows, and bandwidth and network capacity.

2. Unsupported devices and configurations

RingCentral recommends against the use of certain devices, device settings, and network configurations for an MVP communication solution. Incorrect settings or unsupported devices can cause problems with endpoint registration, call feature operation, or the quality of voice and/or video transmission (e.g., high latency, packet loss, jitter). Table 2.1 lists these known conflicts.

For proper operation of MVP services, you should disable or bypass the functions listed in Table 2.1 on IP devices (Layer 3 switches, routers, firewalls) and Ethernet switches.

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

Table 2.1 - Functions that may impair SIP signaling and/or RTP media traffic
Layer	Function
Application	• SIP Application Layer Gateway (SIP ALG), also known as SIP Transformations • SIP inspection • Deep packet Inspection (DPI) • Application layer access control • Stateful Packet Inspection (SPI), also known as Dynamic packet filtering • Intrusion detection/intrusion prevention system (IDS/IPS) • Web proxy operation • WAN acceleration
Transport	• Port filtering
IP	• Packet-by-packet load balancing across multiple service provider links
IP & data link	• Auto-QoS, when used in combination with Poly phones • Dynamic ARP inspection
Physical	• Energy efficient Ethernet (also known as Green Ethernet) • Satellite (Ethernet over microwave) network connections

Note:

For some of the functionalities listed in the Application row of Table 2.1, packet content may traverse a separate processing engine, resulting in signaling and/or media traffic impairments. If you use SMB or SoHo devices, this configuration could result in substantial problems. (The effect will likely be minimal if you use advanced networking devices.).
Enabling SIP ALG may cause signaling issues that can result in nonfunctional or partially functional call features, and/or one-way audio or lack of audio.
You must disable SIP inspection, which may cause intermittent call-control or media-transport problems.
IDS/IPS functions may limit packet streams to a specific bandwidth, causing intermittent audio problems when the number of calls exceeds a certain limit.
WAN accelerators use header compression to reduce bandwidth consumption, which can cause increased jitter in VoIP traffic.
Web proxies do not typically support QoS, so any VoIP or video traffic that passes through these proxies may suffer excessive latency and jitter.
Port filtering, such as UDP flood protection, may limit bandwidth, which can cause intermittent voice-quality issues during simultaneous calls.
Packet-by-packet load balancing across multiple internet connections is not supported. Signaling and media for a single session must originate from the same IP address.
Use of Auto-QoS may cause voice-quality issues (e.g., distortion or incorrect volume levels) with older Poly speakerphones and older deskphones.
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.
Satellite connections can introduce delays greater than 150 ms in each direction. Depending on the quality of the satellite connection, such delays may cause excessive jitter and packet loss.

3 . End-to-end network path performance requirements

The network path requirements listed in Table 3.1 need to be satisfied to optimize the network path for VoIP and video media traffic when using unified communication services. For video communication, the same or slightly relaxed requirements may be imposed by network devices since video should, ideally, be transported synchronously with voice.

Table 3.1 - End-to-end network path performance requirements
Network property	Requirement
Link capacity	Each link in the end-to-end path must have symmetric (bi-directional) capacity that is greater than the network traffic bandwidth generated by the maximum number of simultaneous voice and video calls. This expanded capacity must also exceed the bandwidth required for other types of non-real-time traffic and growth. (See Section 6 for further information on bandwidth and networking.)
Delay	Latency should be < 150ms (one-way)* or < 300ms (round-trip). Longer latencies, which can occur with geosynchronous satellite links, will delay but won’t disable communications. However, both parties should be aware of potential communication delays.
Packet loss	Packet loss should not exceed 1% to prevent voice signal outages.
Jitter	Jitter should not exceed 40ms to prevent the occurrence of robotic voice or speech content outages.

*Learn more about one-way transmission delay. See especially Appendix II.

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 do not apply and packets can be retransmitted when lost. Other types of service traffic, such as messaging and directory services, can be processed more like data traffic.

The following sections explain the ideal classification and treatment of communication services traffic for enterprise networks and WAN. 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. See below for recommendations for such sub-optimal cases.

The following 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 lists the different traffic classes for unified communications services.

Note:

The class requiring the highest priority treatment, VoIP Media, 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 case 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.
Security is implemented above the IP layer, which does not affect CoS or DSCP values.

Table 4.1.1 - Traffic types and classification
	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

4.2 Traffic scheduling

Traffic scheduling in network devices determines how the different traffic from different classes is prioritized when transmitted out of a network device. Network devices must transmit VoIP traffic before transmitting any other traffic types. This ensures that the requirements detailed in Table 2.1 are met.

Video conferencing is interactive, and therefore must be separated from one-way video streaming services. End-user experience will not be affected if traffic is delayed when a user is watching video conference content.

4.3 Practical constraints

An ideal network configuration uses the CoS tagging and DSCP marking values from Table 4.1.1 in the entire network path between endpoints and cloud-based servers. Using this ideal configuration is known as honoring the marking. However, in practice, honoring the marking is not always possible for one or more reason:

Some network devices (e.g., low-end routers) don’t support sufficient QoS capabilities.
Small networks don’t always manage CoS values.
ISPs may change DSCP markings (e.g., 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 indicated in Table 4.1.1.
Some endpoint types do not yet mark CoS/DSCP value (Section 4.4).

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

4.4 Traffic classification methods

The QoS capabilities of the local network device determines 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, 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 Table 4.4.1.
Two traffic classes model: Real-time voice and video UDP traffic, and SIP TCP traffic that originates from or is destined for cloud communication media servers, are all classified as DSCP 46. Other traffic is classified as unprioritized data traffic, with DSCP and CoS values of 0. See 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, expanding the classes to differentiate VoIP from video and other traffic will enhance QoS functionality for an enterprise network.

Table 4.4.1 - Three traffic classes model
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.2 - Two 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

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 (softphones, video client, MVP, and Google Chrome 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 a DSCP value according to 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: Internet traffic may arrive at an enterprise site incorrectly marked. That traffic must therefore be re-marked immediately by the enterprise network border device. This will ensure that traffic will be forwarded within the internal network with the correct priorities assigned to it.

4.6 DSCP marking policy

This section describes traffic treatment policies for (re-)marking DSCP values in enterprise networks. Proper DSCP marking and honoring policy is used to preserve assigned DSCP values and to forward packets according to the priority 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 does not mark the correct value using the guidelines in Section 4.4, you should re-mark endpoint traffic as close as possible to the correct DSCP value. This re-marking may occur in such network devices as access points, access switches, routers, and firewalls.
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 in both inbound and outbound directions.
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 to define the stated QoS policies in inbound and outbound 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 supernets must be used according to the QoS policy definition.

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 above. If your traffic exceeds the configured bandwidth, your voice, video, and 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 (Section 4) are followed, several conditions must be met at the ingress and egress borders of these networks:

Traffic class and priority matching: Ensure that the number of traffic classes and CoS values follow the guidelines provided in Section 4.4.
Traffic shaping: Ensure that the maximum Layer-3 network bandwidth produced for each traffic class doesn’t exceed WAN link capacity. You can achieve this configuration with traffic shaping, provided that the average bandwidth does not exceed the provisioned WAN link capacity.

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

5. Prioritization of a network connection on MS Windows

For soft-client endpoints with multiple wired and/or wireless network connections, traffic must use only one connection. If a 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:

Click Start at the bottom left of the MS Windows screen.
Type cmd in the search bar to open a terminal window.
Type route print in the terminal.

The output will show the metrics used for different interfaces on the computer. To ensure that your traffic passes the WiFi network:

Click Start at the bottom left of your screen.
Type Control Panel in the search bar.
Click Network and Internet.
Click View network status and tasks.
Click Change adapter settings.
Select the WiFi adapter.
Right-click, then select Properties.
Log in as an administrator (if necessary).
Click Internet Protocol Version 4 (TCP/IPv4).
Click Properties.
Click Advanced.
Uncheck Automatic metric.
Enter 1 to give the WiFi interface the highest priority.
Click OK.
Type route /f to clear routing table entries.
Reboot to activate your new interface priority.
Verify the metric by executing 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 use a bandwidth- and capacity-calculation procedure.

7. Network assessment

The end-to-end path QoS requirements listed in Section 3 can be validated by performing a network assessment, which determines the quality of the LAN and the service provider network. Two types of network assessments can be performed to validate the ability of a network path to support unified communication services:

Snapshot network assessment: These assessments provide an impression of network capacity and quality for each direction 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 time.
Comprehensive network assessment: In this case, a probe is installed at the local customer site. By running this probe over a longer time interval (e.g., a full business week), you can obtain a much better impression of the end-to-end quality and intermediate network hop quality in both directions. Detailed and targeted network improvement recommendations can be provided based on the results of this type of assessment. This type of assessment minimizes the likelihood of user-perceived QoS issues.