01/17/18 19:12 PM  

Expanded Version: RingCentral Network Requirements and Recommendations

« Go Back


SummaryHow do I set up my network to get the best VoIP experience with RingCentral?
Last Modified: January 3, 2018


Appendix A. VLANs Configuration of Polycom Phones 
Appendix B. TCP/IP Port Tables
Appendix C. Endpoint Bandwidths


1. Introduction

The purpose of this document is to provide RingCentral customers with network requirements and recommendations to ensure that RingCentral cloud-based unified communication services operate properly. For the successful implementation of RingCentral services, the network requirements must be followed without reservations, while recommendations are advised to be followed.

These requirements include constraints on network capacity, quality of service, firewall configuration, and unsupported devices and configurations. Section 4 introduces the RingCentral Unified Communications Reference Architecture. This architecture can be used to understand the context of the end-to-end Quality of Service requirements (Section 5) and the network specific requirements and recommendations to meet the end-to-end requirements (Section 7 through Section 10). Section 6 describes the need to perform Network Readiness Assessment to verify and ensure that the network meets the stated requirements.

Back to Table of Contents 

2. Reading Guidelines

The following reading guidelines can be used:
• For quick reading, Sections 3 through 6 can be skipped since these sections provide contextual and background information.

• For some SMB environment routers, the Configuration Guides under the link provided in Section 8.1 on the Tested Routers can be used to configure QoS settings.

• For Enterprise and SMB/SoHo environments, the network requirements and recommendations are stated in Sections 7 through 10. Section 7 specifies the RingCentral IP Supernets, which can be used to configure QoS policies, firewall rules, and disable layer 7 functions. Section 8 provides network specific requirements including NAT and firewall requirements, Section 9 specifies QoS requirements, and Section 10 contains a method for bandwidth and capacity calculations. The appendix addresses VLAN configuration of Polycom phones.

3. Acronyms

The following acronyms are used in this document:
Access Control List
Application Layer Gateway
Network Address Translation
Access Point
Network Time Protocol
Address Resolution Protocol
Over-the-Top (over plain internet service)
Busy Lamp Appearance
Power over Ethernet
Public Switched Telephone Network
Class of Service
Quality of Service
Demilitarized Zone
Real-time Protocol
Deep Packet Inspection
Session Border Controller
Differentiated Services Code Point
Session Initiation Protocol
Digital Subscriber Line
Small and Medium-sized Business
Expedited Forwarding
Small office - Home office
High Definition
Stateful Packet Inspection
High Quality
Secure Real-time Transport Protocol
Intrusion Detection System
Transport Control Protocol
Internet Protocol
Total data traffic bandwidth for a given site
Intrusion Prevention Protocol
Total RingCentral traffic bandwidth for a given site
Internet Service Provider
User Datagram Protocol
Internet Control Message Protocol
Virtual Local Area Network
Internet Telephony Service Provider
Voice over IP
Kilobit per second
Voice Quality
Local Area Network
Wide-Area Network
Megabit per second
WiFiSet of standards for wireless communication

4. Unified Communications Reference Architecture 

This section specifies the RingCentral Reference Architecture and provides a high-level overview of types of network technologies that may be used at different places in the reference architecture, such as VLANs, Wireless networks, layer 2 WAN networks, and RingCentral CloudConnect.

4.1 - Reference Architecture Specification

The RingCentral Unified Communications Reference Architecture is illustrated below. The top of the diagram indicates a call control function, a media server function, and carrier telephony interfaces. This functionality is implemented in the RingCentral cloud. Details of this functionality are not provided because they are irrelevant for the enterprise-site requirements stated in this document. The figure provides representative sample designs of enterprise sites including smaller site illustrating SoHo environments. In terms of traffic flow, the notions of inbound and outbound are defined relative to the local enterprise network that is connected to a service provider network:
• outbound is in the direction of the service provider network.
• inbound is from the service provider network into the local enterprise network.

The functionality in the Reference Architecture is color-coded as follows:
RingCentral-provided cloud-based and onsite functionality including call controller, voice and video media servers, carrier interfaces, phones, and RingCentral soft-clients running on enterprise computers, are illustrated in orange. Note that customers sometimes retain existing desk phones from prior non-RingCentral VoIP deployments, in which case it is not designated as RingCentral provided.

Customer functionality is blue.
An enterprise network may include one or more of the following functional components:
Supports inbound and outbound packet filtering and network interfaces that can be of Ethernet, DSL, or cable modem type.

Performs IP routing and packet forwarding, and may support other functions such as layer 3 bandwidth management and ICMP related functions.

Ethernet Switch
Supports frame switching and may support additional functions such as VLANs, layer 2 port control and filtering, Power over Ethernet (PoE), and Green Ethernet.

Desktop Telephone
The phones perform two main functions:
Call Control: Phone registration and call handling (setup, forwarding, teardown, call progress indication, etc.).

Voice Signal Processing: Analog-to-digital and digital-to-analog conversion, sidetone injection, voice framing, jitter buffering, echo cancellation, speaker and microphone functionality.
A computer running RingCentral softphone or collaboration applications such as RingCentral Meetings or Glip may be connected to an Ethernet switch or WiFi network. In case a wired network is used, the computer may also be connected in series with a desk phone connected to an Ethernet switch. 
User-added image
In general, enterprise network implementations are site dependent. For example, large offices will have more advanced firewalling, routing, and switching equipment than small branch-office sites. Implementation variations at enterprise sites include the following:
One or multiple ISP WAN links may be present. In the latter case, one dedicated link could be used for VoIP service and another link for data services. Failover may be implemented between both links.

Multiple firewalls may be present, for example to demarcate a DMZ.

The Wide Area Network interface, firewall, router, and switch may be implemented as separate functions or combinations of functions. In larger deployments, functions are often implemented as individual devices. In SMB environments, functions are often combined into fewer devices. An example is an all-in-one modem or cable modem, which combines the WAN interface, firewall, router, and switch functions. An all-in-one modem may also be configured to operate in bypass mode. In bypass mode, a separate firewall and router located behind the modem may be deployed to provide more advanced firewalling and routing capabilities.

 Multiple sites may be connected into a hub-and-spoke architecture, where traffic between sites always traverses the central hub. Traffic to/from the Internet may also have to pass the central hub. For redundancy purposes, the remote spokes may have a local Internet connection.

Sites may be connected to the RingCentral cloud by one or more private CloudConnect links, see https://www.ringcentral.com/office/features/cloudconnect/overview.html.

Several levels of routers or Ethernet switches may be present. This is typically the case at large enterprise site, which often have core switches connecting to access switches. 

Sites may have various types of desk phones and softphones, depending on user needs.

Voice and video calls can be made between phones at a single enterprise site, between phones at different enterprise sites, or calls may connect to an ITSP or a PSTN gateway. The Call Controller registers the phones and handles call orchestration between various components. To support calls, the following types of connectivity must exist from endpoints in the enterprise network:
• Call control connectivity with RingCentral Call Controller
• Media path connectivity with RingCentral Media Service
• Connectivity with various types of support services such as the RingCentral provisioning service and an time service. 

4.2  - VLANs

Virtual LANs (VLANs) can be used as follows with RingCentral endpoints:
• Desk Phones and IP Speaker Phones - If VLANs are supported by network switches, then it is recommended to define a VLAN specifically for desk phones and IP speakerphones. This will keep VoIP traffic of these types of endpoints logically separate from data traffic and reduces broadcast domains. It also simplifies management of these endpoints because their IP addresses are VLAN specific.

• Soft-Clients - Computers running RingCentral soft-clients will usually run other applications as well. For this reason, the computer is normally connected to the default VLAN. Therefore, it is not possible to put VoIP and Video traffic for soft-clients on a dedicated VLAN.

The RingCentral VoIP solution must be put on a different subnet than an already deployed VoIP solution from a different vendor. Otherwise, the network routing of the existing VoIP solution may inhibit VoIP phones from reaching out to RingCentral cloud-based services. 

The way Polycom phones can leverage VLANs is described in KB 8533: VLAN Configuration of Polycom Phones.

For all types of RingCentral endpoints and independent of their VLAN assignments, UDP traffic must be prioritized on the local network according to the rules provided in Section 9.

Back to Table of Contents 

4.3 - Wireless Networks

The achievable QoS over a WiFi network depends on many factors. Chief among them are: 
• The capabilities, settings, and physical location of WiFi Access Points (APs)
• The location of users relative to APs
• The number of users connecting to an AP
• Environmental conditions such as location, addition, and migration of objects and furniture

These factors may contribute to lower quality compared to wired network implementations.

RingCentral softphones, mobile phones, and Meetings applications can be used on WiFi networks provided that QoS and configuration requirements stated in this document are followed. A best practice to ensure that the overall network quality meets the RingCentral requirements is to ensure that: 
a. The wired network (to which desk and conference phones may be connected) meets these requirements. 
b. The network including the additional WiFi leg also meets the end-to-end RingCentral requirements. 

4.4 - SMB/SoHo Networks

Small Medium Businesses and Small Office - Home Office (SMB/SoHo) networks are mostly connected to ISP cable or Digital Subscriber Line (DSL) networks. These networks may have lower quality equipment (such as all-in-one modems) than enterprise networks. Frequently, the users on SoHo networks use wireless connectivity to their modem. The combination of these factors makes it more difficult to manage the end-to-end QoS for cloud communications services. However, it is recommended to closely follow the RingCentral network requirements to maximize QoS. 

Back to Table of Contents 

4.5 - Layer 2 WANs

Layer 2 Wide-Area Networks (WANs) can be implemented in several ways:
• Between sites within an enterprise.
• To connect an enterprise site or data center to RingCentral via CloudConnect (Section 4.6)

Each Layer 2 WAN leg in the path to reach RingCentral Unified Communication Services needs to meet the end-to-end RingCentral network Requirements and Recommendations. Specific QoS requirements for supporting layer 2 WAN networks are provided in Section 9 and specially Section 9.7

Back to Table of Contents 

4.6 - CloudConnect

RingCentral CloudConnect supports the ability to implement private connectivity between a an enterprise site and the RingCentral Unified Communication Cloud. Depending on the type of CloudConnect, the enterprise/carrier layer 2 Wide-Area Network (WAN) can be extended into one or both RingCentral data centers in a cloud region. The network interface between the WAN and the RingCentral cloud must meet RingCentral’s physical and peering protocol requirements.
Table 1. CloudConnect Options
CloudConnect Option
Simplex + OTT
A CloudConnect circuit from the carrier/enterprise WAN cloud to a single RingCentral data center, with OTT backup
Georedundant + OTT
A CloudConnect circuit from the carrier/enterprise WAN cloud to each of the RingCentral data centers within a cloud region, with optional OTT backup

4.7 - Software-Defined Networks and SD-WAN Networks

A Software-Defined Network (SDN) provides the ability to consistently manage connectivity and connection parameters, such as security and QoS, between sites leveraging centralized network control. Connections can be established between sites and services in a matter of minutes to hours, which used to take days or months. SDNs are an inlay network technology in the sense that they replace or optimize current network technologies to simplify end-to-end management of connections.

In contrast to SDN, Software-Defined Wide-Area Network (SD-WAN) is an overlay network technology build on top of already existing network infrastructures of one or more Internet Service Providers. It has similar characteristics as SDN by leveraging centralized control of connections. In addition, an SD-WAN allows dynamic steering of traffic over one or multiple service provider networks to establish the highest quality connection.

Both SDN and SD-WAN networks support delivery of RingCentral Unified Communication services provided that the network requirements stated in this document are met.

Back to Table of Contents 

5. End-to-End Quality of Service Network Requirements

The requirements stated in Table 2 need to be satisfied for VoIP media traffic to get satisfactory voice quality between RingCentral endpoints. The same requirements hold for Video over IP when using the RingCentral Meetings application since voice is embedded in the video signal. 
Network Property
Link Capacity
Each link in the end-to-end path must have a capacity in both directions that is larger than the maximum number of simultaneous calls plus capacity added for other types of non-real-time traffic and growth (see Section 10 for a calculation)
< 150 ms (in both call directions)
Packet Loss
< 1%
< 30 ms

6. Network Readiness Assessment

The end-to-end quality of service requirements stated in Section 5 can be validated by performing a network readiness assessment, which determines the quality of the local enterprise network and the Service Provider network. Two types as network readiness assessments can be performed to assess the ability of the network to support RingCentral communication services:
• Snapshot Network Readiness Assessment - This assessment leverages the Capacity Test and VoIP Quality Test tools at: Knowledge Article 1162: Testing your Internet Connection for RingCentral Service. These tools provide an impression of network capacity and quality in the outbound direction of an enterprise site to the RingCentral cloud over a time interval of a few minutes.

• Comprehensive Network Readiness Assessment - In this case a probe is installed at the enterprise site. By running this probe over a longer time interval (e.g. a full business week), a much better impression is obtained of the end-to-end quality and intermediate network hop quality in both directions of the call. Targeted network improvement recommendations can be provided based on this type of assessment.

The first type of assessment can be performed by the enterprise but provides minimal insights into the end-to-end QoS over time. The second type of network assessment, which is recommended to minimize the likelihood of user-perceived QoS issues, requires involvement of RingCentral Professional Services.

The requirements stated in the next sections must be implemented before a network assessment is performed so that any major network issues are already addressed.

7. RingCentral Supernets

The following supernets (concatenated subnets) are owned and used by RingCentral for unified communication:
Table 3. RingCentral Supernets

RingCentral uses these networks globally for call servers, media services, route announcements and auxiliary services, like telephone provisioning and network time. It is highly recommended to permit all these networks at all enterprise locations for the specific regions.

The RingCentral supernets can be used to control the following features in local enterprise network devices (see next section):

• IP Layer DSCP packet markings (Section 9.5).
• Selectively disable layer 7 device functions such as Deep Packet Inspection (Section 8.2) for UDP traffic to/from RingCentral.
• Firewall TCP/IP Ports (Section 8.6.2).

8. Network Components and Services 

RingCentral requires and recommends that an enterprise network and soft-client computers support a minimal set of features to ensure high-quality VoIP, video and communication service. For this purpose, requirements and recommendations are provided for some type of routers, DNS, NAT, etc. Unsupported or non-recommended configurations are also stated.

8.1 - Tested Routers

In general, Enterprise class routers support most of the QoS capabilities and configuration options described in the remainder of this document. 

A set of SMB class WAN routers have been validated to work properly with the RingCentral VoIP service. The list of routers that have been tested can be found at ringcentral.com/support/qos-router.html.

Back to Table of Contents 

8.2 - Unsupported Devices and Configurations

Some types of devices, device settings, and network configurations are not supported/recommended in a RingCentral Unified Communications Solution as they are known to cause continuous or intermittent voice quality issues (contributing to high latency, packet loss or severe jitter).

The following configurations are not supported or recommended for a RingCentral Communications Solution:

• Not Supported - Packet-by-packet load balancers used to route outbound VoIP traffic simultaneously across multiple WAN links.
• Not Recommended - Satellite network connections.
Load balancers are not supported because they can cause out-of-order packet arrival at the media processors in the RingCentral cloud. This can result in intermittent or continuous voice quality issues, such as interruption of audio and SIP messaging in Session Border Controllers (SBC). It can also result in inconsistent NAT TCP session states between enterprise and RingCentral equipment. 

Satellite connections introduce delays much exceeding 150 ms in each direction and, depending on the quality of the satellite connection, may also cause excessive jitter and packet loss. It depends on end-user expectations whether this is acceptable.

For proper support of RingCentral Unified Communications services, the functions listed in Table 4 may need to be disabled on IP devices (layer 3 switches, routers, firewalls), and Ethernet switches. Disabling the mentioned functionality for the IP and higher layers can be limited to the RingCentral Supernets listed in Section 7 by applying policy-based control. For example, WAN acceleration can be configured to pass-through mode for UDP traffic originating and destined to RingCentral. 
• Session Initiation Protocol Application Layer Gateway (SIP ALG), also referred to as SIP Transformations
• Deep Packet Inspection (DPI)
• Application Layer Access Control
• Stateful Packet Inspection (SPI), also called Dynamic Packet Filtering
• Intrusion Detection/Intrusion Prevention System (IDS/IPS)
• WAN Acceleration
• Port filtering
• Packet-by-packet load balancing across multiple Service Providers links
IP & Data Link
• Auto-QoS, when used in combination with Polycom phones
• Dynamic ARP Inspection
• Green Ethernet

Enabling these functions may result in intermittent call connectivity issues (phone registration or call feature operation) or excessive voice quality impairments (increased latency and jitter), specifically:
• For some of the functionality mentioned under Application Layer Functions), packet content may traverse a separate processing engine, which may result in the mentioned impairments. The impact may be minimal when using an advanced networking devices but could be substantial for SMB and SoHo devices.
• Any of the Application layer functions may cause signaling or UDP media quality issues. For example, IDS/IPS may limit packet streams to a certain bandwidth causing intermittent audio issues across multiple calls when the number of calls exceeds a certain volume. To reduce bandwidth, WAN accelerators use header compression to reduce traffic. For VoIP traffic, this can result in increased jitter.

• Port filtering, such as UDP flood protection, may limit bandwidth thereby causing intermittent voice quality issues when many simultaneous calls occur (see e.g. https://support.sonicwall.com/kb/sw10399).

• Packet-by-packet load balancing may cause increased jitter and out-of-order packet arrival at the receiving media processor in the RingCentral cloud. This may result in increased packet loss.

• Use of Auto-QoS may cause voice quality issues (such as distortions or incorrect volume levels) with older Polycom speakerphones and older versions of desk phones.

• Green Ethernet is used on switch ports to save energy by automatically turning them into low power mode after they have not passed traffic for some time. This may also cause intermittent signaling and media traffic issues.

8.3 - RingCentral Soft-Client Endpoints

Computers used for RingCentral soft-clients are recommended to be configured as follows:

LAN Interface Metric
The interface metric plus the route table metric of the wired network should be higher than for the wireless network, so that only one network at a time is selected. If the total metric is identical for both types of network interfaces, this may result in load-balancing across both interfaces and voice quality issues.

From MS Windows, the metrics can be viewed by opening a command prompt window (CMD) and entering netstat -rn. The Interface List indicates metrics in the left-hand column. The IPv4 Route Table shows the metric in the right-hand column. See https://superuser.com/questions/708716/set-lan-to-take-network-priority-before-wi-fi-on-windows-7 for more background.

Security Software
Cloud-based security client software may need to be disabled when this interferes with soft-client operation or presence updates.

8.4 - DNS

RingCentral endpoints use domains for example to:
• Access provisioning and firmware update services for desk and conference phones.
• Access call servers.
• Update presence status.
RingCentral endpoints leverage these cloud services based on geo-location. Therefore, a DNS lookup resolves a domain name to an IP address which depends on the geographic location and the DNS Service Provider used to perform the lookup.

After boot up, RingCentral endpoints rely on a DNS service to resolve the call server domain name (e.g., sip3.ringcentral.com) it obtained from the provisioning service to its corresponding call server address.

It is important that the domain name of the call server gets resolved to an IP address within one of the supernets that is geographically close to the physical location of endpoints. Use of a single corporate DNS (e.g., country-wide or even a single global DNS) instead of a distributed DNS to resolve domain names to local IP addresses may result in longer paths to media servers, which adversely affects voice quality.

Endpoints at different enterprise sites may be connecting to IP addresses in different supernets.

8.5 - NAT

Network Address Translation/Port Address Translation functionality (generically referred to as NAT) is applied at the border between two networks to translate between address spaces or to prevent collision of IP address spaces. More specifically, a NAT function translates the source (IP address, port number) pair of outbound packets into a public source (IP address, port number) pair and maintains table entries corresponding to this translation to allow inbound response traffic to return to the proper host in the private network. This is required, for example, when connecting: a) an enterprise IP network to the public Internet, or b) an enterprise network via a layer 2 network to RingCentral via CloudConnect (Section 4.6).

NAT is frequently implemented as part of a firewall functionality, but can also be implemented stand-alone.

For proper operation of the RingCentral endpoints, a minimum Network Address Translation time out needs to be configured. Cisco phones send a follow-up REGISTER refresh message every 4 minutes, Polycom phones every 5 minutes. As a consequence:
• NAT entry expiration timeout must be set to greater than 5 minutes to cover all RingCentral phones.

8.6 - Firewall Control

To protect an enterprise network, a firewall must be present at the border between the private enterprise network containing the RingCentral endpoints and the network service provider WAN (see Reference Architecture in Section 4). For proper operation of the RingCentral endpoints:
• A set of inbound and outbound TCP/IP firewall ports must be opened (Section 4.6).

• Domains need to be whitelisted (Section 8.6.3) to allow inbound and outbound traffic transfer for supporting that are not part of the RingCentral Supernet address space.

The ports that need to be opened and the domains that need to be whitelisted pertain to the following types of traffic and functionality: 
• Presence status indication
• Google Chrome extensions
• RingCentral APIs
• Call control (SIP signaling)
• RTP media
• Auxiliary services: Network Time Service and Directory Services
• Telephone provisioning and registration

8.6.1 - Firewall Types 

Two main types of firewall operation can be distinguished:
• Stateful Firewall – In a stateful firewall, the associated inbound TCP/IP port is automatically opened upon initiating a TCP or UDP session in the outbound direction from the private network side.

• Stateless Firewall – Session state is not maintained in the firewall; each packet transferred through the firewall is considered unrelated to any other packets that are part of the same session. This implies that, before allowing a TCP/IP session between the private and public network, the appropriate ports need to be opened first, both in the inbound and outbound direction. 

Both types of firewall operation may be configurable within the same physical firewall device. Compared to stateful firewall operation, a stateless firewall generally requires more firewall administration work and may be less secure because it is more prone to administration errors. It is therefore recommended to use a stateful firewall to support RingCentral Unified Communication Services.

The high-level firewall Access Control Configuration rules indicated in Table 5 can be used in conjunction with RingCentral supernets (Section 7) and port tables (Section 8.6.2) to configure a firewall to support RingCentral endpoints residing in the private local network.
Table 5. Additional Access Control Policies
Type of Firewall
Outbound Direction
Inbound Direction
Stateful Firewall
Allow all traffic as indicated in the port tables to all RingCentral supernets
No configuration required
Stateless Firewall
Allow all traffic as indicated in the port tables to all RingCentral supernets
Allow all traffic as indicated in the port tables in Section 8.6.2 from all supernets according to the following rules:
• Destination ports must be replaced by source ports.

• Source ports must be replaced by destination ports.

Back to Table of Contents 

8.6.2 - TCP/IP Ports

When using a stateless firewall, use the tables in Appendix B to control TCP/IP ports. Note again that these tables be ignored when a stateful firewall operation is used.

8.6.3 - Whitelisting of Domains, IP Addresses, and Ports 

To allow the devices and applications indicated in Table 6 to access supporting cloud services, Fully Qualified Domains Names (FQDNs), IP addresses, and associated ports must be whitelisted:
• The Polycom, Cisco, and Yealink provisioning services are located in the RingCentral supernet IP address space.

• The Firmware Update service is located in the Amazon cloud.

• Desk phones do not use pubnub for presence status notifications.

• RingCentral Office Premium and Ultimate plans provide the ability to archive softphone messages (text, fax, and voice mail) and call recordings (automatic and on-demand) to the Box cloud (www.box.com) or to an sftp server.
Table 6. Whitelisting of Domains and IP Addresses
Device / Application
Cloud Service
Domain / IP Address and Ports to be whitelisted
Domain / IP Address
Polycom desk phones and conference phones
Firmware Update
Cisco desk phones
Firmware Update
Yealink desk phones
Firmware Update
Desktop Softphone Application & Mobile Application
Presence, Call Log Notifications, and Voice Mail notifications
80 or 443
Softphone Archiver
It is assumed that the enterprise has already whitelisted the appropriate domains to allow access to Box
IP address of the enterprise sftp server
Telephony Client Application using the RingCentral Connect Platform API
Production API
Development API
Chrome dialer plugin
Google Account
Chrome APIs for plugins
Fonts used by Google Chrome

9. QoS Classification and Traffic Treatment Policies

RingCentral traffic needs to be classified and treated properly in enterprise and service provider networks to ensure that end-to-end QoS requirement are met for RingCentral Cloud-based communications services. In terms of QoS, VoIP and video impose the most severe constraints on the network because real-time packet loss and jitter QoS requirement need to be met. 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 treated more like data traffic.

The next sections indicate how, ideally, RingCentral communication services traffic is classified and treated. In practice, it may only be possible to partially follow the RingCentral QoS traffic class and treatment requirements due to limitation of endpoints, network devices, and ISP and carrier networks. Recommendation are provided to handle these sub-optimal cases as well.

9.1 - Traffic Classification

The left side of Table 7 indicates the traffic classes that are distinguished for RingCentral communication services, where the class requiring the highest priority treatment (VoIP Media) is indicated at the top. At layer 2, Class of Service (COS) frame header tagging is used, while DSCP packet marking is used in the IP header in layer 3. In the next considerations, tagging at layer 2 and marking at layer 2 is generically called marking.
Table 7. Traffic Types and Classification
Traffic ClassCOS
Decimal Value
Decimal Value
NameDrop Probability
VoIP Media - Real Time546EFN/A
Video Media - Real Time434AF41Low
   • Network Time Service
   • Mobile App Data Sync
   • LDAP Directory Service
Best Effort: Phone Provisioning and firmware update00BEUndetermined
 Layer 2Layer 3

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 packer header with possible values ranging from 0 to 63.

NOTE: End-to-end security is implemented above the IP layer, e.g. secured VoIP media is transported as SRTP/UDP/IP (SRTP is the secure version of RTP) so that security does not affect COS and DSCP values.  

9.2 - Practical Constraints

Ideally, the COS tagging and DSCP marking values indicated in Table 7 are used across the entire network between RingCentral endpoints and cloud-based servers, and traffic is treated according to this classification, which is referred to as honoring the marking). However, in practice this is often not entirely possible because:

• Some network devices do not support extensive QoS capabilities. Examples are low-end routers.

• COS values are often not managed in small local networks.

• ISPs provide may change DSCP markings along the internet path, e.g. from DSCP 46 to 0.

• In large corporate enterprise networks with sites connected by an MPLS or Metro-Ethernet network, a DSCP to COS mapping must be performed by the WAN network border devices. This mapping may not exactly maintain the COS-DCSP values indicated in Table 7. More details are provided in Section 9.4

• Some RingCentral endpoint types do not mark COS/DCSP value yet (Section 9.4).

These constraints are accommodated in the next sections by stating practical requirements and recommendations for traffic classification, DSCP marking, and use of layer 2 WAN interconnections.  

9.3 - Traffic Classification Methods

Depending on the QoS capabilities of the local network devices, one of two traffic classification methods can be implemented to support RingCentral communication services:
• Multi-Band Classification – Traffic to and from RingCentral cloud servers is mapped according to Table 7.

• Dual-Band Classification – Realtime voice and video UDP traffic and SIP TCP traffic originating from or destined to RingCentral cloud communication media servers is all classified as DCSP 46. Other traffic is classified as unprioritized data traffic with DSCP and COS value equal to 0. The dual-band classification method is indicated in Table 8.

Multi-band classification offers the best way to handle QoS in large corporate networks and whenever the network devices support this. Dual-band classification is relatively simple to implement and works well in most SoHO and corporate environments with devices with limited QoS capabilities. In some cases, when sufficient network capacity exists, some enterprises implement a dual-band classification, where all RingCentral traffic (e.g. media, SIP, phone provisioning, and firmware update) is classified as DSCP 46. 
Table 8. Traffic Types and Classification
Traffic ClassCOS
Decimal Value
Decimal Value
NameDrop Probability
VoIP Media - Real Time
Video Media - Real Time
   • Network Time Service
   • Mobile App Data Sync
   • LDAP Directory Service
Best Effort: Phone Provisioning and firmware update
 Layer 2Layer 3

9.4 - Endpoint and Internet DSCP Traffic Marking Constraints

The following types of DSCP marking are applied by RingCentral endpoints, cloud media server, and Internet Service Providers:
• RingCentral Endpoints
• RingCentral desk phones use IP Differentiated Services Code Point 46 (Expedited Forwarding - EF) marking for UDP media packets. In this way, routers in an enterprise network can prioritize VoIP media traffic over best effort data traffic.

• RingCentral soft endpoints (soft phones, RingCentral Meetings, Glip, and Google Chrome clients) mark UDP media packets as DSCP 0. Other types of traffic are not marked by the endpoints yet. This implies that network devices like access switches, routers and firewalls need to remark traffic at the proper location in the outbound direction (Section 9.5).

• RingCentral Media Servers - RingCentral cloud media servers mark UDP traffic as DSCP 46.

• Internet Service Providers - Internet Service providers frequently remark DSCP priority values to different (lower) values. This has the following implications:
Outbound direction: Traffic often arrives in the RingCentral cloud with improper marking.

Inbound direction: In the inbound direction to an enterprise site, internet traffic may arrive incorrectly marked and therefore needs to be remarked to ensure that it will be forwarded inside the internal network according to the right priority relative to other traffic. Multiple internet service provider WAN links may be connected to the enterprise border device, which makes it important to remark all traffic as soon as it arrives on the border device.

9.5 - DSCP Marking Policy

This section describes traffic treatment policies for (re-)marking DSCP values in the enterprise network. The notions of inbound and outbound are defined in Section 4. The following DSCP marking and honoring (i.e. keeping the assigned DSCP value and forwarding it according to the priority of the assigned value) policy must be implemented in switches, routers and firewalls in the end-to-end communication path between RingCentral endpoints and cloud-based servers, which accommodate the DSCP marking constraints listed in Section 9.4:
1. Outbound Direction - Remark traffic to the correct DSCP value in Table 7 or Table 8) as close as possible to the endpoint if the endpoint does not mark the correct value. The remarking may occur in network devices like access points, access switches, routers and firewalls.

2. Inbound Direction - Remark traffic to the correct DSCP value as soon as it enters the network via an ISP or Carrier WAN link.

3. Inside the Local Network - Honor the DSCP markings throughout the enterprise network in both the inbound and outbound direction.

4. WAN Network - Any mapping from DCSP to COS and back needs to be performed so that end-to-end QoS requirements are maintained (Section 9.7).

The RingCentral supernets must be used in the inbound and outbound ACL to define the stated QoS policies. Local subnet address ranges should not be used 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, which also requires that the RingCentral supernets must be used in the QoS policy definition.

9.6 - Bandwidth Management Policy

Some routers support bandwidth management, which can be enabled to guarantee the capacity for certain types of traffic even under saturation conditions. If routers support bandwidth management, then it is advised to enable this feature and set the bandwidth for RingCentral traffic to the number obtained from the calculation procedure provided in Section 10. If the traffic classification and policies are configured according to the recommendations and requirements stated in prior sections and the RingCentral traffic exceeds the configured bandwidth, RingCentral traffic may still get prioritized over regular data traffic although bandwidth may not be guaranteed for all calls (depends on the router and setting).

Back to Table of Contents 

9.7 - Layer 2 WAN Interconnect Policy

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 Quality of Service Network Requirements (Section 5) are adhered to, several conditions must be met at the ingress and egress border of these networks:
• Traffic Class and Priority Matching – Ensure that the number of traffic classes and COS values in the Wide-Area Network align as much as possible with Table 7 or Table 8 (depending on the selected classification method).

• Bandwidth Matching – Ensure that the assigned average capacity for each layer 2 traffic class is larger than the maximum bandwidth for each type of traffic in the layer 3 network.

• Traffic Shaping – Ensure that the maximum Layer 3 network bandwidth produced for each traffic class does not exceed the WAN link capacity. This can be accomplished by traffic shaping provided that the average bandwidth does not exceed the provisioned WAN capacity.

If the Traffic Class and Priority Matching condition cannot be met, then some layer 3 DSCP values must be mapped to a higher COS value. The bandwidth matching condition must be followed because otherwise QoS issues of the following types may occur. Suppose that the produced voice bandwidth in the layer 3 network is 10 Mbit/s and the voice traffic capacity allocated in the WAN network is 200 kbit/s. Then, the voice quality will be very much degraded when more than a few calls are made, in case voice traffic gets a higher priority assigned than data traffic.

Back to Table of Contents 

10. Bandwidth and LAN / WAN Link Capacity Calculation

This section provides a methodology to calculate the RingCentral traffic bandwidth produced at an enterprise site and to determine the capacity needed on the LAN and ISP WAN links.
The total bandwidth generated and consumed by RingCentral endpoints for an enterprise site connected to an ISP WAN link must be calculated to determine if the local network capacity and WAN link capacity are sufficient to carry RingCentral unified communication traffic.

Table 9 provides an example of a bandwidth calculation for a single enterprise site:

• For a given enterprise site, the numbers for the Number of Endpoints, Headroom for Growth, and Simultaneous Use Factor must be manually entered for each Endpoint Category and Use Case.

• The Endpoint Type Total Bandwidth is calculated from the combination of these numbers and the Bandwidth per Endpoint. 

• The Number of Endpoints can be entered by using the Administrator tab in the RingCentral service portal. If a user has a desk phone and softphone (desktop or mobile), they are normally used one at a time and should not be double counted in the table.

• The Headroom for Growth column indicates how many extra endpoints will be activated soon after first activation of RingCentral services. It is useful to take this number into account in the calculation to ensure that network capacity is sufficient to accommodate growth.

• The Simultaneous Use Factor, a number between 0 and 1, indicates the maximum number of simultaneously used endpoints. In call center deployments, this number has to be set to 1.

• The Bandwidth per Endpoint numbers are obtained from bandwidth tables in Appendix C but are now stated in Mbps. Always the maximum number is used if transmit and receive bandwidth numbers are different. For VoIP, the bandwidths are rounded up to 0.1 Mbps.

• The RingCentral Meetings bandwidth calculation must accommodate the RingCentral Office Edition and Meeting Add-on license since it has a significant impact on the bandwidth that needs to be supported by both the LAN network and WAN link. For example, with a Large Meeting Add-on, up to 200 people could simultaneously join a RC Meetings session using video, and multiple of those sessions may be held simultaneously. The Simultaneous Use Factor must be adjusted according to the expected use cases.

• The Total Site Bandwidth due to RingCentral traffic, TS-RC-BW is calculated as the sum of the Endpoint Type Total Bandwidth numbers:
TS-RC-BW = [(Number of Endpoints) + (Headroom for Growth)] x (Simultaneous Use Factor) x (Bandwidth per Endpoint)
Table 9. Transmit and Receive Bandwidth for Single Enterprise Site
Endpoint CategoryUse CaseNumber of EndpointsHeadroom for GrowthSimultaneous Use FactorBandwidth per Endpoint (Mbps)Endpoint Type Total Bandwidth (Mbps)
Desk and Soft PhonesHard phone10000.50.15
Speaker phone500.250.10.125
Mobile phone on WiFi3010.13
RingCentral MeetingsGroup HQ video call501210
Two-party HD video call1001220
Two-party HQ video call10010.66
Group audio conference400.10.10.04
RingCentral RoomsTriple screen201612
Dual screen401416
Single screen10133
RingCentral Room ConnectorTriple screen401624
Dual screen601424
Single screen10133
 TS-RC-BW (Mbps) = 125.465

The WAN link may be shared for RingCentral and Data Traffic. In that case, the bandwidth for data traffic, TS-DATA-BW, needs to be added to the TS-RC-BW number to get the total bandwidth for the site. The TS-DATA-BW must be determined during a busy time and include headroom for data spikes and growth.

The following capacity condition must be met to ensure that the WAN link capacity is sufficient to transport RingCentral Unified Communication traffic:
(TS-RC-BW + TS-DATA-BW) < (Enterprise Site Provisioned WAN link Capacity)

If this condition is not met, then the WAN link capacity needs to be increased. The provisioned capacity is the capacity available on the WAN link. This may be lower than the physical capacity. As an example, a 1 Gbps fiber WAN link may be connecting to the enterprise but only a capacity of 100 Mbps may actually be provisioned. 

Additional capacity constraints:
• The stated capacity condition must be met for the inbound and outbound direction.

• Similar capacity conditions must be met for any of the internal LAN links and deeper in the ISP network.  

• For RingCentral CloudConnect, also the aggregate bandwidth of all sites together and the provisioned capacities of data center links and ports needs to be considered for capacity determination. 

• Bandwidth calculators for ISP WAN link connected sites and CloudConnect scenarios can be obtained upon request via email to ben.baten@ringcentral.com

Back to Table of Contents  

Appendix A. VLANs Configuration of Polycom Phones

Visit KB 8533: VLANs Configuration of Polycom Phones for more information on VLAN configuration of Polycom phones. 

Back to Table of Contents  

Appendix B. TCP/IP Port Tables

Port tables B.1 through B.8 summarize the TCP/IP source and destination port numbers that are used by traffic generated by the RingCentral endpoints. Note again that the tables in this section can largely be ignored if stateful firewall operation is used. The following general properties hold for the port tables:
• Table rows indicating Signaling/Media (without the Secured modifier) can be ignored when the customer account is configured for ‘secured signaling and media.’ Note that blocking non-secured traffic may require a longer time to troubleshoot voice quality issues.

• Table rows indicating Signaling/Media-Secured can be ignored when the customer account is configured by RingCentral Provisioning for ‘secured signaling and media.'

• Some 3rd party devices, such as the Polycom IP7000 speakerphone, do not support signaling or media encryption. They should be avoided in a deployment requiring full security.

• Media in RingCentral Meetings and Rooms indicate realtime video with embedded voice.

• The designation ‘random’ in the source port column indicates that the port number is randomly selected by the RingCentral endpoint.

• No separate ports are specified for Busy Lamp Appearance (BLA) since it uses the signaling ports and standard SIP NOTIFY packets.

• A summary port table is provided in Table B.8. If the complete set of RingCentral endpoints is deployed at a local site, then the summary table can be used for firewall configuration instead of the individual endpoint tables. 
Table B.1 -  Desk Phone
Traffic Type
Source Port Number
Destination Port Number
Media - SecuredSRTP/UDPrandom40000-49999
5090, 5099**
Signaling - Secured
Network Time Service
LDAP Directory Service
ProvisioningHTTP/TCP and HTTPS/TCPrandom443
**TCP port 5099 only needs to be opened when line sharing is used. 
Table B.2 - RingCentral Desktop Softphone Application
Traffic Type
Source Port Number
Destination Port Number
Media - Secured
4000-5000, 20000-60000
Signaling - Secured
LDAP Directory Service
Provisioning and Presence StatusHTTP/TCP and HTTPS/TCPrandom80 and 443
Table B.3 - iOS and Android Mobile Phone Application (on Wi-Fi Network)
The following is the specific ports usage, but it's recommended to open the port range 5090-5099 for UDP/TCP/TLS because new ports may be added and some ports configuration may be changed within this range.
Traffic Type
Source Port Number
Destination Port Number
MediaRTP/UDP4000-5000, 20000-6000050000-59999
Media - Secured
4000-5000, 20000-60000
5060 or random
5090 and 5091
Signaling (IPv6 client)SIP/TCP/TLSrandom5093 and 5094
Signaling - Secured
5096 and 5097
Mobile App Data Sync with RingCentral backend
(e.g., call log info, presence, and voicemails)
LDAP Directory service
Provisioning and Presence StatusHTTP/TCP and HTTPS/TCP80 and 44380 and 443
Table B.4 - Glip Mobile Application
Traffic Type
Source Port Number
Destination Port Number
Signaling and MediaHTTP/TCP and HTTPS/TCP
80 and 44380 and 443
Table B.5 -  Google Chrome Extensions
Traffic Type
Source Port Number
Destination Port Number
Signaling and (secured) Media
5060, 6182, 8080, 8083
5060, 6182, 8080, 8083
Table B.6 - RingCentral Meetings
Traffic Type
Source Port Numbers
Destination Port Numbers
MediaRTP/UDPrandom3478 and 3479
8801 and 8802
Signaling - Secured
Table B.7 - RingCentral Rooms and Room Connector (H.323 and SIP)
Traffic Type
Source Port Numbers
Destination Port Numbers
Media RTP/UDPrandom30000-59999
5060 and 5061
Signaling - Secured
The next table provides a summary of all previous tables and can be used when all RC types of endpoints are deployed.
Traffic Type
Source Port Numbers
Destination Port Numbers
MediaRTP/UDP4000-5000, 8000-8200, 20000-60000, random3478 and 3479
Media - SecuredSRTP/UDP4000-5000

30000-59999 (RingCentral Rooms)
Signaling and MediaHTTP/TCP and HTTPS/TCP
80 and 44380 and 443
5060 and 5061

8801 and 8802
5060 and 5061
5090 and 5091
5093 and 5094
8801 and 8802
Signaling - Secured
5061, 5096, and 5097
Signaling and Media for Chrome Extensions
5060, 6182, 8080, 8083*
5060, 6182, 8080, 8083
Network Time Service
Mobile App Data Sync
LDAP Directory Service
Provisioning and Presence StatusHTTP/TCP and HTTPS/TCPrandom80 and 443
*Already in Media Port range
**TCP port 5099 only needs to be opened when line sharing is used. 

Appendix C. Endpoint Bandwidths 

The next sections summarize bandwidths produced and consumed by each of the RingCentral endpoint types. The bandwidth numbers can be used to calculate the capacity needed for the LAN links and ISP WAN link. 

Appendix C.1 - VoIP Endpoint Bandwidth

Table C.1 states the bandwidth numbers for both the receive and transmit traffic of hard and softphones. As indicated, the numbers depend on the endpoints and the administrative codec settings enabled in the RingCentral cloud. The numbers include packetization and Ethernet framing.
Table C.1 - Transmit and Receive Bandwidth for Hard Phones and Soft Phones Use Cases
EndpointCodecTransmit and Receive Bandwidth (kbps)
Desk phone and IP Conference phoneG.71187
Opus60 - 80
SoftphoneOpus60 - 80
Mobile phoneOpus60 - 80

Appendix C.2 - RingCentral Meetings Bandwidth

Table C.2 states the bandwidth numbers for both the receive and transmit traffic of RingCentral Meetings. As indicated, the numbers depend on the use case. 
Table C.2 - Per Endpoint Transmit and Receive Bandwidth for RingCentral Meetings Use Cases
Use CaseMeetings Login Panel and Login Panel SettingTransmit Bandwidth (kbps)Receive Bandwidth (kbps)
Group HQ video callSettings, Video, Capture HD video not checked6002000
Two-party HD video callSettings, Video, Capture HD video checked20002000
Two-party HQ video callSettings, Video, Capture HD video not checked600600
Group audio conferenceStart without video on RingCentral Meeting60 - 8060 - 80

If a user does not join the audio portion of a RingCentral Meetings session but calls in via a separate phone connection, then no audio is transferred (transmitted/received) on the user’s computer but video is still transferred to the computer.

As indicated in Table C.3, RingCentral Office Editions offer different audio and video capacities for RingCentral Meetings sessions.
Table C.3 - RingCentral Office Editions vs RingCentral Meetings Audio and Video Capacities
RingCentral Office EditionMax. Number of Audio ParticipantsMax. Number of Video Participants
Without Large Meetings LicenseWith Large Meetings License
Standard9994100 or 200
Premium99950100 or 200
Ultimate99975100 or 200

Appendix C.3 - RingCentral Rooms Bandwidth

Table C.4 states the bandwidth numbers for both the receive and transmit traffic of RingCentral Rooms. The transmit and receive bandwidths depend on the use case. The receive bandwidth for video operation depends on the number of screens. The transmit bandwidth is always 2 Mbps because a single camera is used.
Table C.4 - Transmit and Receive Bandwidth for RingCentral Room Use Cases
Use CaseTransmit Bandwidth (kbps)Receive Bandwidth (kbps)
Triple Screen20006000
Dual Screen20004000
Single Screen20002000
Screen sharing only150 - 300150 - 300
Audio-only60 - 8060 - 80


For more information on the RingCentral Unified Communications Solutions, go to success.ringcentral.com/RCSupportPortalGuidesVideos.
NOTE: A PDF version of this document can be created by clicking the Printable View link at the top of this document and then saving it to a PDF file.

Was this information helpful?

Tell us why and what can we do to improve this information