04/26/18 18:01 PM  

RingCentral Network Requirements and Recommendations

« Go Back


SummaryWhat are the RingCentral Network Requirements and recommendations to improve phone call quality?
Last Modified: April 25, 2018


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.

NOTE: This condensed version contains the same requirements as the Expanded Version of RingCentral Network Requirements and Recommendations article but does not include background on the requirements, their architectural context, or bandwidth calculations.

Back to Table Contents


2. 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
  Set of standards for wireless communication

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

3.1 Tested Routers

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 Contents


3.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 2 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 (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. 
• 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.

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

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

Back to Table Contents


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

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.

3.6 Firewall Control

A firewall must be present at the border to protect the enterprise network, when using Internet connectivity with RingCentral between the private enterprise network containing the RingCentral endpoints and the network service provider WAN (see Reference Architecture in Section 4 of the Expanded Version of the RingCentral Network Requirements and Recommendations article). For proper operation of the RingCentral endpoints:
• A set of inbound and outbound TCP/IP firewall ports (Section 3.6.2) must be opened.

• Domains need to be whitelisted (Section 3.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

3.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 3 can be used in conjunction with RingCentral supernets (Section 6) and port tables (Section 5) to configure a firewall to support RingCentral endpoints residing in the private local network.
Table 3. 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.

3.6.2 TCP/IP Ports

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

3.6.3 Whitelisting of Domains, IP Addresses, and Ports 

To allow the devices and applications indicated in Table 4 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 4. 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

Back to Table Contents

4 . 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 5. 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
Back to Table Contents

5. TCP/IP Port Tables

The table below summarizes the TCP/IP source and destination port numbers that are used by traffic generated by the RingCentral endpoints. Note that the table in this section can largely be ignored if stateful firewall operation is used. The following general properties hold for the port table:
• 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.

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. 

Back to Table Contents


6. RingCentral Supernets

The following supernets (concatenated subnets) are owned and used by RingCentral for unified communication:
Table 7. 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.
Was this information helpful?

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