08/12/20 16:31 PM  

Network Requirements and Recommendations | RingCentral Office

« Go Back



What's New: 
(August 2020) Supernet has been added to Table 3. Please update enterprise firewall access control rules to allow this supernet for near future use.
(July 2020) Removed RingCentral Endpoint Summary Table, Updated RingCentral Video Ports on Table B.6
(May 2020) Removed Port 5097 on Table B.1. Removed Port 5096 on Table B.3
Table 6:.ringcentral.pubnubapi.com changed to ringcentral.pubnubapi.com (for newer endpoint versions)
(April 2020) Added RingCentral Video details to Table 6. RingCentral Video Domains and Destination Ports on Table B.6.
(Mar 2020) Source port numbers have been removed from the port tables in Appendix B to simplify firewall configuration.
Added .ringcentral.pubnubapi.com to Table 6, changed Appendix C. CloudFront IP Address Range for Phone Firmware Upgrades to Appendix C. Amazon CloudFront IP Address Range for Phone Firmware Upgrades. 
VLAN-A=10 has been changed to VLAN-A=10; . Corrected port 5098 to 5097 in Tables B.1 and B10.

RingCentral Office, RingCentral Contact Center, Engage Digital, and Engage Voice may be deployed independent of one another or combined. For each deployment, a particular set of network requirements and recommendations holds.

This article lists the requirements and recommendations for RingCentral Office while the ones for RingCentral Contact Center, Engage Voice, and Engage Digital are provided in other articles:

Network Requirements and Recommendations | RingCentral Contact Center
Network Requirements and Recommendations | RingCentral Engage Digital

For other Networking resources, go to Networking Requirements and Recommendations Resources.

Unified Communications Reference Architecture is now discussed in a separate article.
It is very important that you work with your IT to configure your network's settings to ensure continuous and reliable service.

To view the previous version of this document, go to RingCentral Network and Recommendations previous version 


7.1 VLANs

Appendix A. VLANs Configuration of Polycom / Poly Phones 
Appendix B. TCP/IP Port Tables  
Appendix C. Amazon CloudFront IP Address Range for Phone Firmware Upgrades


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.

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

2. Reading Guidelines

The following reading guidelines can be used:

• For Enterprise and SMB/SoHo environments, the network requirements and recommendations are stated in Sections 6 through 9.

•  Section 6 specifies the RingCentral IP Supernets, which can be used to configure QoS policies, firewall rules, and disable layer 7 functions.

•  Section 7 specifies requirements and recommendations for specific types of enterprise and wide-area networks.

•  Section 8 specifies QoS requirements.

•  Section 9 provides network-specific NAT and firewall requirements.

•  Section 10 contains a description of LAN / WAN bandwidth and capacity requirements. 

•  The appendices contain detailed information, such as VLAN configuration of Polycom / Poly phones, TCP/IP port tables, and IP Address Range for Phone Firmware upgrades.

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

3. Acronyms

Table 1 summarizes the acronyms used in this document:

Table 1. Acronyms


Access Control List


Network Address Translation


Application Layer Gateway


Network Time Protocol


Access Point


Quality of Service


Address Resolution Protocol


Real-time Protocol


Busy Lamp Appearance


Session Border Controller




Session Initiation Protocol


Class of Service


Small and Medium-sized Business


Deep Packet Inspection


Small office - Home office


Differentiated Services Code Point


Stateful Packet Inspection


Digital Subscriber Line


Secure Real-time Transport Protocol


Expedited Forwarding


Transport Control Protocol


Intrusion Detection System


User Datagram Protocol


Internet Protocol


Virtual Local Area Network


Intrusion Prevention System


Voice over IP


Internet Service Provider


Wide-Area Network


Local Area Network


Set of standards for wireless communication






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

The requirements stated in Table 2 need to be satisfied for VoIP media traffic to get optimal call 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.

Table 2. Quality of Service Network Requirements

Network Property


Link Capacity

Each link in the end-to-end path must have a capacity in each direction that is larger than the maximum number of simultaneous calls plus capacity added for other types of non-real-time traffic and growth (Section 10)


< 150 ms (of one way latency)*

Packet Loss

< 1%


< 30 ms

*https://www.itu.int/rec/T-REC-G.114-200305-I/en, Appendix II.

5. Network Readiness Assessment

The end-to-end quality of service requirements stated in Section 4 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 the 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.


6. 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.

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

• 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).

• IP Layer DSCP packet markings (Section 9.5).

7. Networks

This section covers high-level requirements and recommendations for specific types of enterprise and wide-area networks. More details are provided in the subsequent sections for network components, QoS handling, and bandwidth estimation.

7.1 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 the 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 so that VoIP and Video traffic for soft-clients does not reside on a dedicated VLAN. 

The following recommendations and requirements should be followed for VLAN implementations:

• The RingCentral VoIP solution must be put on a different VLAN and 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 / Poly phones can leverage VLANs is described in Appendix A.

7.2 SMB/SoHo Networks

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

• Closely follow the RingCentral network requirements in this document, including the WiFi network requirements in Section 7.3.

• If an ISP provided modem is used with a separate router, the modem is configured in passthru (also called bridge) mode, and the router is configured according to the requirements in the next sections.


7.3 WiFi 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 soft-endpoints such as desktop softphones, mobile phone applications, and RingCentral Meetings applications can be used on WiFi networks provided that QoS and configuration requirements stated in this document are followed. To maximize QoS, it must be ensured that:

a. The wired network meets the RingCentral network requirements

b. The wired network plus the WiFi leg attached to the wired network also meets the end-to-end requirements as stated in the next sections

c. The 5GHz band is used instead of the 2.4 Hz band since the former offers higher bandwidth and less interference from other equipment due to non-overlapping channels. 


7.4 Wide-Area Networks (WANs)

Many technologies exist to implement WANs, including internet, Ethernet Virtual Private Line, MPLS, and SD-WAN. Each type of network technology has its own way of supporting QoS. To ensure that the end-to-end QoS requirements and recommendations are met, it is required that:

• Every traversed WAN network segment must have sufficient quality.

• Proper mapping of prioritization tags is performed between LAN and WAN networks (Section 9.5).

8. Network Components and Services

To ensure high-quality communication service delivery, RingCentral requires that network devices and endpoints support the feature requirements and follow the recommendations stated in this section.


8.1 Enterprise Class Routers and 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.

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 jitter).

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, or be avoided. Disabling the mentioned functionality for the IP and higher layers can be limited to the RingCentral supernets listed in Section 6 by applying policy-based control. For example, WAN acceleration can be configured to pass-through mode for UDP traffic originating and destined to RingCentral.

Table 4. Functions to be Disabled for SIP Signaling and UDP Traffic to/from RingCentral




• SIP 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)
• Web Proxy operation
• 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 / Poly phones
• Dynamic ARP Inspection


• Energy Efficient Ethernet (a.k.a. Green Ethernet)
• Satellite network connections


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 advanced networking devices but could be substantial for SMB and SoHo devices.

• Enabling SIP ALG may cause signaling issues resulting in non- or partially functioning call features.

• IDS/IPS functions 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.

• Web proxies typically do not support QoS so that VoIP and video traffic may incur intermittent latency and jitter variation.

• Port filtering, such as UDP flood protection, may limit bandwidth thereby causing intermittent voice quality issues when many simultaneous calls occur.

• 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 packet loss and 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.

• Use of Auto-QoS may cause voice quality issues (such as distortions or incorrect volume levels) with older Polycom / Poly 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.

• 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.


8.3 RingCentral Soft-Client Endpoints

Computer endpoints 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 status updates.


8.4 DNS

RingCentral endpoints use several cloud-based support services:

• Provisioning and firmware update services for desk and conference phones.
• Call servers.
• Presence status.

Endpoints access these services via DNS lookup to resolve a domain name into an IP address.

For example, RingCentral endpoints rely on a DNS service to resolve the call server domain name (e.g., sip3.ringcentral.com) 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.

Note that endpoints located in different RingCentral Cloud regions will, in general, connect 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 a 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 (RingCentral Unified Communications Reference Architecture).

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 / Poly 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

For security purposes, usually, a firewall is present at the border of an enterprise network (RingCentral Unified Communications Reference Architecture). For proper operation of the RingCentral endpoints:

• A set of inbound and outbound TCP/IP firewall ports must be opened (Appendix B. TCP/IP Port Tables).

• Domains need to be whitelisted (Section 8.6.3) to allow inbound and outbound traffic transfer for supporting RingCentral cloud services.

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 6) and port tables (Appendix B).

Table 5. 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.


8.6.2 TCP/IP Ports

When using a firewall, use the tables in Appendix B to configure TCP/IP ports.


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 / Poly, Cisco, and Yealink provisioning services are located in the RingCentral supernet IP address.

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

• Softphones and mobile phones 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.  

• The port column indicates the port used after resolution of the domain name to an IP address.

Table 6. Whitelisting of Domains and IP Addresses
EndpointCloud ServiceDomain / IP Address and Ports to be whitelisted
Domain / IP AddressPorts
RingCentral Website
Login Pagewww.ringcentral.com443
RingCentral Service WebLogin Pageservice.ringcentral.com443
RingCentral AnalyticsLogin Pageanalytics.ringcentral.com
RingCentral Analytics (Canada)Login Pageanalytics.ringcentral.ca
RingCentral Live ReportsLogin Pagelive.ringcentral.com
RingCentral Live Reports (Canada)
Login Page
Softphone ArchiverBox

It is assumed that the enterprise has already whitelisted the appropriate domains to allow access to Box

Secure File Transfer

For archiving to an enterprise SFTP server, the following SFTP client IP addresses in the RingCentral cloud need to be whitelisted:


Any of these IP addresses may dynamically be selected by the RingCentral SFTP client to connect to an enterprise SFTP server.

Telephony Client Application using the RingCentral Connect Platform APIProduction APIplatform.ringcentral.com443
Development APIplatform.devtest.ringcentral.com
RingCentral App (Glip)Glip*.glip.com443
RingCentral VideoLogin Pagev.ringcentral.com443
Media Servers*.v.ringcentral.com443
RingCentral MeetingsLogin Pagemeetings.ringcentral.com443
Login Pagewebinar.ringcentral.com443
Media Servers*.zoom.us
Desktop Softphone Application & Mobile ApplicationPresence Status, Call Log Notifications, and Voice Mail notifications*.pubnub.com
ringcentral.pubnubapi.com (for newer endpoint versions)
80 or 443
Google Chrome ExtensionLogin Pageaccount.google.com443
Chrome APIs for pluginapis.google.com
Fonts used by Google Chromefonts.gstatic.com
Hard PhoneCloudfront Firmware Update***.cloudfront.net443
Polycom / Poly Desk Phones and Conference PhonesProvisioningpp.ringcentral.com443
Firmware Updatepp.s3.ringcentral.com
Cisco Desk PhonesProvisioningcp.ringcentral.com443
Firmware Updatecp.s3.ringcentral.com
Yealink Desk PhonesProvisioningyp.ringcentral.com443
Firmware Updateyp.s3.ringcentral.com
**See Appendix C. CloudFront IP Address Range for Phone Firmware Upgrades

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 requirements are met for RingCentral Cloud-based communications services. In terms of QoS, VoIP and video impose the most severe constraints on the network because delay, packet loss, and jitter QoS requirements 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 should be classified and treated. In practice, it may only be possible to partially follow the RingCentral QoS traffic class and treatment requirements due to the limitation of endpoints, network devices, and ISP and carrier networks. Recommendations are provided to handle these sub-optimal cases as well.

• outbound is away from the enterprise site or in the direction of the service provider network.

• inbound is to the enterprise site or from the service provider network into the local enterprise network.


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 indicated, while DSCP packet marking is available 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 Class

Decimal Value

Decimal Value


Drop 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 2

Layer 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: Comprehensive 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 sufficient QoS capabilities. Examples are low-end routers.

• COS values are often not managed in small networks.

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

• In large corporate enterprise networks, with sites connected to 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.7.

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

Practical requirements and recommendations for traffic classification, DSCP marking, and a description of Layer 2 WAN interconnections are provided in the next sections to address these constraints.


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 are 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 choose to implement a variant of the dual-band classification illustrated in Table 8, 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 Class

Decimal Value

Decimal Value


Drop Probability

VoIP Media - Real Time
Video Media - Real Time SIP






• Network Time Service
• Mobile App Data Sync
• LDAP Directory Service
• Best Effort: Phone Provisioning and firmware update






Layer 2

Layer 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 (softphones, 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.

RingCentral Mobile Applications have the capability to mark traffic with a DSCP value as indicated in Table 6.

Internet Service Providers - Internet Service providers frequently remark DSCP priority values to different (lower) values, which has the following implications:

• Outbound direction: Traffic often arrives in the RingCentral cloud with improper marking.

• Inbound direction: Internet traffic may arrive to an enterprise site incorrectly marked from the internet and, therefore, needs to be remarked immediately by the enterprise network border device to ensure that it will be forwarded inside the internal network according to the right priority relative to other traffic. 

9.5 DSCP Marking Policy

This section describes traffic treatment policies for (re-)marking DSCP values in enterprise networks. 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, router, and firewalls.

2. Inbound Direction - Remark traffic to the correct DSCP value as soon as it enters the enterprise network via a carrier WAN link or WiFi Access Point.

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 (Section 6) and port tables TCP/IP port tables (Appendix B) must be used in the inbound and outbound ACLs 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 used 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 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). 

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 4) 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.


10. RingCentral Bandwidth and Network Capacity Assessment

Two methods can be used to determine the bandwidth produced by RingCentral traffic on LAN and WAN links and their capacity required to carry RingCentral unified communication traffic.

The preferred and most accurate method is to determine the peak traffic load from logs or network data extracted from a still deployed legacy voice/video system. Alternatively, a bandwidth and capacity calculation procedure can be used (RingCentral Bandwidth and Network Capacity Assessment).

Appendix A. VLANs Configuration of Polycom / Poly Phones 

General Phone Request Process for VLAN and IP Information

A Polycom / Poly IP phone can operate on a separate Voice-tagged VLAN. The Ethernet Switch connected to the phone must be configured properly to use VLANs. A phone can retrieve its Voice VLAN information by four different methods:

LLDP – Link Layer Discovery Protocol
CDP – Cisco Discovery Protocol
DHCP – Dynamic Host Configuration Protocol
Statically configured on the phone

The following process is executed by Polycom / Poly phones to receive Voice VLAN information:

1. When the phone boots, it first sends an LLDP message to the Ethernet switch requesting a VLAN ID with the Voice VLAN ID

2. If LLDP responds with the VLAN ID, then a DHCP request for IP address and 160 Option is sent on the tagged Voice VLAN ID

3. If no LLDP response occurs, then a CDP message is sent to the switch requesting Voice VLAN ID

4. If CDP from the switch responds with Voice VLAN, a DHCP request for IP address and 160 Option is sent on the tagged Voice VLAN

5. If no CDP response is received, a DHCP request is sent on the Data VLAN for the Voice VLAN DHCP Option and IP information

DHCP Server Voice VLAN Provisioning

To configure a Voice VLAN the following items need to be provisioned on the DHCP server:

1. LLDP/CDP must be disabled on the Ethernet Switch port when using DHCP to configure the Voice VLAN.

2. DHCP Options required by the phone that must be defined in the Data VLAN Scope of the DHCP server (click to view the wireshark file) are:

• 1 Subnet Mask
• 3 Router (Default Gateway) IP Address
• 6 Domain Name Server (DNS) IP address

3. Optionally, four different DHCP options can be used to configure a Data VLAN in the DHCP Data scope.

• One of the following options may be used (sometimes an option does not work and a different one has to be selected): Options 128, 144, 157 or 191

4. The VLAN must be configured as VLAN-A=x; -- where VLAN and A must be in CAPS, x = Voice VLAN number and the semicolon behind x must be present

Example: VLAN-A=10; -- sets Voice VLAN to 10

5. Define a Voice VLAN Scope with the proper IP and Options 1, 3 and 6.

6. Optionally, the following provisioning service can be configured in Option 160 in the DHCP Voice Scope: https://pp.ringcentral.com

Phone Voice VLAN DHCP Request-Response Process

The VLAN request-response process including reboots is as follows:

1. IP Phone performs DHCP request on the Data VLAN (No VLAN tagging)
2. DHCP Server responds with option to set VLAN (Example: VLAN-A=10; -- sets Voice VLAN to 10)
3. IP Phone releases previous DHCP Data VLAN IP address
4. IP Phone reboots after receiving VLAN option
5. IP Phone requests Voice VLAN DHCP scope (with VLAN Tagged to 10)
6. DHCP Responds with new IP address for the Voice VLAN
7. Optional - Use Option 160 with Provisioning Service URL https://pp.ringcentral.com
8. Phone continues boot process
9. Phone contacts Provisioning Server on the Voice VLAN

DHCP Option for Connecting to the Provisioning Service

To use any IP phone, it must be provisioned in the RingCentral Service Portal identifying the phone’s MAC Address. Polycom / Poly phones can be obtained in two ways:

• Polycom / Poly phones purchased from RingCentral are already configured with the link https://pp.ringcentral.com pointing to the RingCentral Provisioning service. After receiving the IP address via DHCP, the phone will connect to the RingCentral Provisioning server and provision the phone appropriately.

• If the Polycom / Poly phone is not purchased from RingCentral and reused from a previous VoIP deployment, then it does not have the provisioning server configured. In that case DHCP can be used to provide the RingCentral provisioning service:

• Create DHCP Option 160 on the DHCP Server for the IP Address scope servicing the IP Phone

• Set DHCP Option 160 to an ASCII string equal to: https://pp.ringcentral.com

• Perform a factory reset of the Polycom / Poly phone via the phone display

Polycom / Poly Boot Process – Summary

The phone boot process is summarized as:

• LLDP to configure Voice VLAN – See switch manufacturer documentation on how to configure LLDP for the Voice VLAN

• CDP to configure Voice VLAN – See switch manufacturer documentation on how to configure CDP

• DHCP Option 128, 144, 157, 191 to configure Voice VLAN

• VLAN-A=10 -- to set Voice VLAN to 10, must be in CAPS and must end with a semi-colon, no white spaces

• Place option in the Data DHCP Scope

• DHCP Option 160 to configure RingCentral Provisioning Service: https://pp.ringcentral.com

• Place option in the Voice DHCP scope

• More information can be found in the PolyCom / Poly UC Software Administration Guide

Wireshark Trace of the DHCP Discovery Process

• Frame 1 – IP Phone DHCP Discover: Parameter request asking for Options 191,157,144, 128 and 160

• Frame 2 – DHCP Offer: Option 160 (Provisioning Server) and 144 (VLAN Info) being returned

• Frame 5 – IP Phone sending DHCP Release: Release of old IP address on Data VLAN

• Frame 6 – IP Phone DHCP Discover on Voice VLAN: New Discover on the Voice VLAN requesting option 160.

• Frame 7 – DHCP Offer: Option 160 for the Provisioning server

file: polycom dhcp boot process with vlan-2.pcapng


Appendix B: TCP/IP Port Tables

Port tables 1 through 9 summarize the TCP/IP destination port numbers that are used by traffic generated by the RingCentral endpoints. The following general properties hold for the port tables:

• Table B.1, B.2, B.3, and B.5: Media and Media-Secured traffic port ranges have been expanded to 20000-64999

• Table B.5 on Google Chrome Extensions and RingCentral App (Glip) Telephony has been refined and corrected to indicate traffic types more explicitly.

Table B.6 covers RingCentral Video Desktop Clients and Chrome Browser.

Table B.7, and Table B.8 cover RC Meetings Desktop and Web Clients. The previous version contained a combined table for these clients.

• The port tables are more or less organized from top to bottom according to QoS traffic prioritization, with media requiring highest priority and supporting data service traffic at the lowest priority (Section 9.1).

• 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.

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

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

• LDAP Directory Service traffic is not destined to RingCentral. The LDAP port must be opened on the firewall when the traffic traverses the public internet and a directory server resides at a different enterprise site.

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

Table B.1 -  Desk, Conference and Cordless Phone

Traffic Type


Destination Port Number




Media - Secured








5090, 5099**

Signaling - Secured



Network Time Service



LDAP Directory Service






**TCP port 5099 only needs to be opened when line sharing is used. 

Table B.2 - Desktop Softphone Application

Traffic Type


Destination Port Number




Media - Secured






Signaling - Secured



LDAP Directory Service



Provisioning and Presence Status


80 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


Destination Port Number




Media - Secured





5090 and 5091

Signaling (IPv6 client)


5093 and 5094

Signaling - Secured



Mobile App Data Sync with RingCentral backend
(e.g., call log info, presence, and voicemails)



LDAP Directory service



Provisioning and Presence Status


80 and 443


Table B.4 Glip Mobile Application

Traffic Type


Destination Port Number

Media and Signaling


80 and 443


Table B.5 Google Chrome Extension and RingCentral App (Glip) Telephony

Traffic Type


Destination Port Number







LDAP Directory Service


636 and 3269

Presence Status



Access Control




Table B.6 RingCentral Video - Desktop Client and Chrome Browser
Traffic TypeProtocolsDestination Port Numbers

Media - Secured

SRTP/UDP (default)


SRTP/TLS/TCP if UDP is not available443
Signaling - SecuredWSS/HTTPS/TLS/TCP443

See Network Requirements and Bandwidth Usage for RingCentral Video for additional technical information on RingCentral Video.

Table B.7 RingCentral Meetings - Desktop Client

Traffic Type


Destination Port Numbers



8801 and 8802

Media - Secured Signaling - Secured



Access Control


3478 and 3479


Table B.8 RingCentral Meetings - Web Client

Traffic Type


Destination Port Number

Media - Secured Signaling - Secured




Table B.9 RingCentral Meetings with Room Connector (H.323 and SIP)

Traffic Type


Destination Port Numbers




Media - Secured









Signaling - Secured






Authentication and Software Update


80, 443


Appendix C. Amazon CloudFront IP Address Range for Phone Firmware Upgrades


CloudFront Global IP List:

CloudFront Regional Edge IP List:



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.

TitleNetwork Requirements and Recommendations | RingCentral Office
URL Name9233
Was this information helpful?

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